teroz

How-to setup a simple git push deployment

These are my notes basically. At first i created this gist just as a reminder for myself. But feel free to use this for your project as a starting point. If you have questions you can find me on twitter @thomasf https://twitter.com/thomasf This is how i used it on a Debian Wheezy testing (https://www.debian.org/releases/testing/)

Discuss, ask questions, etc. here https://news.ycombinator.com/item?id=7445545

On the server (example.com)

teroz

-- show running queries (pre 9.2)
SELECT procpid, age(query_start, clock_timestamp()), usename, current_query 
FROM pg_stat_activity 
WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%' 
ORDER BY query_start desc;

-- show running queries (9.2)
SELECT pid, age(query_start, clock_timestamp()), usename, query 
FROM pg_stat_activity 
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' 

teroz

./bin/drill-embedded                                                                                           
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512M; support was removed in 8.0
Apr 19, 2017 4:53:50 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.8 2014-04-29 01:25:26...
apache drill 1.10.0 
"drill baby drill"

Now visit link http://localhost:8047 to open up Apache Drill explorer and configure S3 storage plugin refer

teroz

#!/bin/bash

# Title: kinit_brute.sh
# Author: @ropnop
# Description: This is a PoC for bruteforcing passwords using 'kinit' to try to check out a TGT from a Domain Controller
# The script configures the realm and KDC for you based on the domain provided and the domain controller
# Since this configuration is only temporary though, if you want to actually *use* the TGT you should actually edit /etc/krb5.conf
# Only tested with Heimdal kerberos (error messages might be different for MIT clients)
# Note: this *will* lock out accounts if a domain lockout policy is set. Be careful

teroz

#!/usr/bin/env bash

sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test
sudo apt update

sudo update-alternatives --remove-all gcc
sudo update-alternatives --remove-all g++
sudo apt-get install -y gcc-4.8 g++-4.8 gcc-4.9 g++-4.9 gcc-5 g++-5 gcc-6 g++-6 gcc-7 g++-7

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 10

teroz

One common and effective mitigation against Cross-Site Scripting (XSS) is to set the HTTPOnly flag on session cookies. This will generally prevent an attacker from stealing users' session cookies with XSS. There are ways of circumventing this (e.g. the HTTP TRACE method), but generally speaking, it is fairly effective. That being said, an attacker can still cause significant damage without being able to steal the session cookie.

A variety of client-side attacks are possible, but an attacker is also often able to circumvent Cross-Site Request Forgery (CSRF) protections via XSS and thereby submit various forms within the application. The worst case scenario with this type of attack would be that there is no confirmation for email address or password changes and the attacker can change users' passwords. From an attacker's perspective this is valuable, but not as valuable as being able to steal a user's session. By reseting the password, the attacker is giving away his presence and the extent to which

teroz

/* 
  ##Device = Desktops
  ##Screen = 1281px to higher resolution desktops
*/

@media (min-width: 1281px) {
  
  /* CSS */
  

teroz

                _   _            _      ____             _    _ 
               | | | | __ _  ___| | __ | __ )  __ _  ___| | _| |
               | |_| |/ _` |/ __| |/ / |  _ \ / _` |/ __| |/ / |
               |  _  | (_| | (__|   <  | |_) | (_| | (__|   <|_|
               |_| |_|\__,_|\___|_|\_\ |____/ \__,_|\___|_|\_(_)
                                                 
                                  A DIY Guide