http://ln.hixie.ch/?start=1037910467&count=1
http://ln.hixie.ch/?start=1137740632&count=1
# to execute this gist, run the line bellow in terminal | |
\curl -L https://raw.github.com/gist/3875946/install_source_code_pro.sh | sh |
#!/usr/bin/env python | |
""" | |
This module will bootstrap a machine using chef. The purpose of this | |
script is actually to work with AWS Auto Scaling Groups. The user data | |
for the Launch Configuration is set to download this script and then | |
run it. This is also stores the results in a private gist and sends | |
a message to logstash with the results. | |
""" |
This Gist is created in 2014, and it's highliy outdated now, according to one of mitmproxy
's manjor contributor (check his comment below). Thanks for letting us know, @mhils!
Modern applications usually make use of back-end API servers to provide their services. With a non-transparent HTTPs proxy, which intercepts the communication between clients and servers (aka the man-in-the-middle scheme), you can easily manipulate both API requests and responses.
TLDR: I now add the following snippet to all my Dockerfiles:
# If host is running squid-deb-proxy on port 8000, populate /etc/apt/apt.conf.d/30proxy
# By default, squid-deb-proxy 403s unknown sources, so apt shouldn't proxy ppa.launchpad.net
RUN route -n | awk '/^0.0.0.0/ {print $2}' > /tmp/host_ip.txt
RUN echo "HEAD /" | nc `cat /tmp/host_ip.txt` 8000 | grep squid-deb-proxy \
&& (echo "Acquire::http::Proxy \"http://$(cat /tmp/host_ip.txt):8000\";" > /etc/apt/apt.conf.d/30proxy) \
&& (echo "Acquire::http::Proxy::ppa.launchpad.net DIRECT;" >> /etc/apt/apt.conf.d/30proxy) \
|| echo "No squid-deb-proxy detected on docker host"
#!/usr/bin/env python | |
# Quick and dirty demonstration of CVE-2014-0160 by | |
# Jared Stafford ([email protected]) | |
# Modified so that it finds cookies | |
import sys | |
import struct | |
import socket | |
import time | |
import select |
/** | |
* example C code using libcurl and json-c | |
* to post and return a payload using | |
* http://jsonplaceholder.typicode.com | |
* | |
* License: | |
* | |
* This code is licensed under MIT license | |
* https://opensource.org/licenses/MIT | |
* |
{ | |
"title": "Nginx Web", | |
"services": { | |
"query": { | |
"list": { | |
"0": { | |
"query": "response:[200 TO 299]", | |
"alias": "OK", | |
"color": "#7EB26D", | |
"id": 0, |
#Container Resource Allocation Options in docker-run
now see: https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources
You have various options for controlling resources (cpu, memory, disk) in docker. These are principally via the docker-run command options.
##Dynamic CPU Allocation
-c, --cpu-shares=0
CPU shares (relative weight, specify some numeric value which is used to allocate relative cpu share)
This is a workaround for this Hazelcast issue.
To use the alternative TcpIpJoinerOverAWS
:
hazelcast-cloud
from your project's classpath,accessKey
nor a secretKey
in Hazelcast's AwsConfig
.