mirror of
/repos/dotTiddlywiki.git
synced 2025-12-30 07:31:33 +01:00
update
This commit is contained in:
parent
8dc6b4662a
commit
c8270d6eb6
18
mywiki/tiddlers/GIT server.tid
Normal file
18
mywiki/tiddlers/GIT server.tid
Normal file
@ -0,0 +1,18 @@
|
||||
created: 20151125110622808
|
||||
creator: user
|
||||
modified: 20151207171352867
|
||||
modifier: user
|
||||
tags:
|
||||
title: GIT server
|
||||
type: text/vnd.tiddlywiki
|
||||
|
||||
https://gogs.io
|
||||
|
||||
```
|
||||
ssh aiko@nas
|
||||
cd /volume1/homes/aiko/repos
|
||||
mkdir gitproject.git
|
||||
cd gitproject.git
|
||||
git --bare init
|
||||
git update-server-info
|
||||
```
|
||||
@ -0,0 +1,79 @@
|
||||
created: 20151204110112790
|
||||
creator: user
|
||||
modified: 20151204113747216
|
||||
modifier: user
|
||||
tags:
|
||||
title: HAProxy: Reloading Your Config With Minimal Service Impact
|
||||
type: text/vnd.tiddlywiki
|
||||
|
||||
docker image: https://hub.docker.com/r/million12/haproxy/~/dockerfile/
|
||||
|
||||
source: https://web.archive.org/web/20150219063018/http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with-minimal-service-impact
|
||||
posted by: Michael Goffin
|
||||
|
||||
[[HAProxy| http://haproxy.org ]] is a high performance load balancer. It is very light-weight, and free, making it a great option if you are in the market for a load balancer and need to keep your costs down.
|
||||
|
||||
Lately we’ve been making a lot of load balancer changes at work to accommodate new systems and services. Even though we have two load balancers running with [[keepalived| http://www.keepalived.org/ ]] taking care of any failover situations, I was thinking about how we go about reloading our configuration files. In the event of a change, the “common” way to get the changes to take effect is to run ''/etc/init.d/haproxy restart''. This is bad for a couple major reasons:
|
||||
|
||||
# You are temporarily shutting your load balancer down
|
||||
# You are severing any current connections going through the load balancer
|
||||
You might say, “if you have two load balancers with keepalived, restarting the service should be fine since keepalived will handle the failover.” This, however, isn’t always true. Keepalived uses advertisements to determine when to fail over. The default advertisement interval is 1 second (configurable in keepalived.conf). The skew time helps to keep everyone from trying to transition at once. It is a number between 0 and 1, based on the formula ''(256 – priority) / 256''. As defined in the RFC, the backup must receive an advertisement from the master every ''(3 * advert_int) + skew_time'' seconds. If it doesn’t hear anything from the master, it takes over.
|
||||
|
||||
Let’s assume you are using the default interval of 1 second. On my test machine, this is the duration of time it takes to restart haproxy:
|
||||
|
||||
```
|
||||
# time /etc/init.d/haproxy restart
|
||||
* Restarting haproxy haproxy
|
||||
...done.
|
||||
|
||||
real 0m0.022s
|
||||
user 0m0.000s
|
||||
sys 0m0.016s
|
||||
```
|
||||
In this situation, haproxy would restart much faster than your 1 second interval. You could get lucky and happen to restart it just before the check, but luck is not consistent enough to be useful. Also, in very high-traffic situations, you’ll be causing a lot of connection issues. So we cannot rely on keepalived to solve the first problem, and it definitely doesn’t solve the second problem.
|
||||
|
||||
After sifting through haproxy documentation (the text-based documentation, not the man page) (/usr/share/doc/haproxy/haproxy-en.txt.gz on Ubuntu), I came across this:
|
||||
|
||||
```
|
||||
313
|
||||
314 global
|
||||
315 daemon
|
||||
316 quiet
|
||||
317 nbproc 2
|
||||
318 pidfile /var/run/haproxy-private.pid
|
||||
319
|
||||
320 # to stop only those processes among others :
|
||||
321 # kill $(</var/run/haproxy-private.pid)
|
||||
322
|
||||
323 # to reload a new configuration with minimal service impact and without
|
||||
324 # breaking existing sessions :
|
||||
325 # haproxy -f haproxy.cfg -p $(</var/run/haproxy-private.pid) -st $(</var/run/haproxy-private.pid)
|
||||
```
|
||||
That last command is the one of interest. The -p asks the process to write down each of its children’s pids to the specified pid file, and the -st specifies a list of pids to send a SIGTERM to after startup. But it does this in an interesting way:
|
||||
|
||||
```
|
||||
609 The '-st' and '-sf' command line options are used to inform previously running
|
||||
610 processes that a configuration is being reloaded. They will receive the SIGTTOU
|
||||
611 signal to ask them to temporarily stop listening to the ports so that the new
|
||||
612 process can grab them. If anything wrong happens, the new process will send
|
||||
613 them a SIGTTIN to tell them to re-listen to the ports and continue their normal
|
||||
614 work. Otherwise, it will either ask them to finish (-sf) their work then softly
|
||||
615 exit, or immediately terminate (-st), breaking existing sessions. A typical use
|
||||
616 of this allows a configuration reload without service interruption :
|
||||
617
|
||||
618 # haproxy -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
|
||||
```
|
||||
|
||||
The end-result is a reload of the configuration file which is not visible by the customer. It also solves the second problem! Let’s look at an example of the command and look at the time compared to our above example:
|
||||
|
||||
```
|
||||
# time haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
|
||||
|
||||
real 0m0.018s
|
||||
user 0m0.000s
|
||||
sys 0m0.004s
|
||||
```
|
||||
|
||||
I’ve specified the config file I want to use and the pid file haproxy is currently using. The ''$(cat /var/run/haproxy.pid)'' takes the output of ''cat /var/run/haproxy.pid'' and passes it in to the -sf parameter as a list, which is what it is expecting. You will notice that the time is actually faster too (.012s sys, and .004s real). It may not seem like much, but if you are dealing with very high volumes of traffic, this can be pretty important. Luckily for us it doesn’t matter because we’ve been able to reload the haproxy configuration without dropping any connections and without causing any customer-facing issues.
|
||||
|
||||
''UPDATE:'' There is a reload in some of the init.d scripts (I haven’t checked every OS, so this can vary), but it uses the -st option which will break existing sessions, as opposed to using -sf to do a graceful hand-off. You can modify the haproxy_reload() function to use the -sf if you want. I also find it a bit confusing that the documentation uses ''$(cat /path/to/pidfile)'' whereas this haproxy_reload() function uses ''$(<$PIDFILE)''. Either should work, but really, way to lead by example…
|
||||
@ -1,6 +1,6 @@
|
||||
created: 20150429212131561
|
||||
creator: user
|
||||
modified: 20150513183026595
|
||||
modified: 20151029073341256
|
||||
modifier: user
|
||||
tags: [[raspberry pi]] node-red
|
||||
title: Node-RED
|
||||
@ -106,6 +106,9 @@ docker run --hostname node-red --cap-add=SYS_RAWIO --device /dev/ttyAMA0:/dev/tt
|
||||
# raspberrypiko.local
|
||||
docker run --hostname raspberrypiko --cap-add=SYS_RAWIO --device /dev/ttyAMA0:/dev/ttyAMA0 --device /dev/mem:/dev/mem -p 1880:1880 -p 1822:22 -v /home/pi/data/red:/data --name node-red -d aiko/node-red-pi
|
||||
|
||||
# pi2.aiko.sh
|
||||
docker run --hostname pi2.aiko.sh --cap-add=SYS_RAWIO --device /dev/ttyAMA0:/dev/ttyAMA0 --device /dev/mem:/dev/mem -p 1880:1880 -p 1822:22 -v /home/pi/data/red:/data --name node-red -d aiko/node-red-pi
|
||||
|
||||
(pro)20150510-2229 aiko@aiko-pro:~/Development/node-red-data
|
||||
$ docker stop node1 ; docker rm node1 ; docker run --add-host prototyper.local:192.168.2.3 --add-host node1.aiko.sh:192.168.59.103 --add-host node2.aiko.sh:192.168.63.103 --hostname="node1" --name="node1" -p 1880:1880 -v ${PWD}:/data -d aiko/node-red:0.10.6 ; docker logs -f node1
|
||||
```
|
||||
75
mywiki/tiddlers/Programming.tid
Normal file
75
mywiki/tiddlers/Programming.tid
Normal file
@ -0,0 +1,75 @@
|
||||
created: 20151008155934019
|
||||
creator: user
|
||||
modified: 20151009082314453
|
||||
modifier: user
|
||||
tags:
|
||||
title: Programming
|
||||
type: text/vnd.tiddlywiki
|
||||
|
||||
; 12 factor app
|
||||
: http://12factor.net
|
||||
|
||||
; I. Codebase
|
||||
: One codebase tracked in revision control, many deploys
|
||||
; II. Dependencies
|
||||
: Explicitly declare and isolate dependencies
|
||||
; III. Config
|
||||
: Store config in the environment
|
||||
; IV. Backing Services
|
||||
: Treat backing services as attached resources
|
||||
; V. Build, release, run
|
||||
: Strictly separate build and run stages
|
||||
; VI. Processes
|
||||
: Execute the app as one or more stateless processes
|
||||
; VII. Port binding
|
||||
: Export services via port binding
|
||||
; VIII. Concurrency
|
||||
: Scale out via the process model
|
||||
; IX. Disposability
|
||||
: Maximize robustness with fast startup and graceful shutdown
|
||||
; X. Dev/prod parity
|
||||
: Keep development, staging, and production as similar as possible
|
||||
; XI. Logs
|
||||
: Treat logs as event streams
|
||||
; XII. Admin processes
|
||||
: Run admin/management tasks as one-off processes
|
||||
|
||||
---
|
||||
; The Art of Unix Programming
|
||||
: http://catb.org/esr/writings/taoup/html/
|
||||
|
||||
; Rule of Modularity
|
||||
: Write simple parts connected by clean interfaces.
|
||||
; Rule of Clarity
|
||||
: Clarity is better than cleverness.
|
||||
; Rule of Composition
|
||||
: Design programs to be connected with other programs.
|
||||
; Rule of Separation
|
||||
: Separate policy from mechanism; separate interfaces from engines.
|
||||
; Rule of Simplicity
|
||||
: Design for simplicity; add complexity only where you must.
|
||||
; Rule of Parsimony
|
||||
: Write a big program only when it is clear by demonstration that nothing else will do.
|
||||
; Rule of Transparency
|
||||
: Design for visibility to make inspection and debugging easier.
|
||||
; Rule of Robustness
|
||||
: Robustness is the child of transparency and simplicity.
|
||||
; Rule of Representation
|
||||
: Fold knowledge into data, so program logic can be stupid and robust.
|
||||
; Rule of Least Surprise
|
||||
: In interface design, always do the least surprising thing.
|
||||
; Rule of Silence
|
||||
: When a program has nothing surprising to say, it should say nothing.
|
||||
; Rule of Repair
|
||||
: Repair what you can — but when you must fail, fail noisily and as soon as possible.
|
||||
; Rule of Economy
|
||||
: Programmer time is expensive; conserve it in preference to machine time.
|
||||
; Rule of Generation
|
||||
: Avoid hand-hacking; write programs to write programs when you can.
|
||||
; Rule of Optimization
|
||||
: Prototype before polishing. Get it working before you optimize it.
|
||||
; Rule of Diversity
|
||||
: Distrust all claims for one true way.
|
||||
; Rule of Extensibility
|
||||
: Design for the future, because it will be here sooner than you think.
|
||||
|
||||
15
mywiki/tiddlers/Safari.tid
Normal file
15
mywiki/tiddlers/Safari.tid
Normal file
@ -0,0 +1,15 @@
|
||||
created: 20151018142953049
|
||||
creator: user
|
||||
modified: 20151018143102370
|
||||
modifier: user
|
||||
tags: safari
|
||||
title: Safari
|
||||
type: text/vnd.tiddlywiki
|
||||
|
||||
;Small tip: How to duplicate tabs in safari.
|
||||
:https://www.reddit.com/r/apple/comments/1pq1am/small_tip_how_to_duplicate_tabs_in_safari/
|
||||
|
||||
```
|
||||
cmd + L
|
||||
cmd + Enter
|
||||
```
|
||||
41
mywiki/tiddlers/Squid sslbump.tid
Normal file
41
mywiki/tiddlers/Squid sslbump.tid
Normal file
@ -0,0 +1,41 @@
|
||||
created: 20151016154223821
|
||||
creator: user
|
||||
modified: 20151026164234090
|
||||
modifier: user
|
||||
tags:
|
||||
title: Squid sslbump
|
||||
type: text/vnd.tiddlywiki
|
||||
|
||||
|
||||
; Setting up Explicit Squid Proxy
|
||||
: http://wiki.alpinelinux.org/wiki/Setting_up_Explicit_Squid_Proxy#Behaviour_with_SSL_interception
|
||||
|
||||
; Regenerate SSL Certificates for Squid
|
||||
: http://docs.diladele.com/administrator_guide_4_0/system_configuration/https_filtering/generate_certificates.html
|
||||
|
||||
|
||||
|
||||
/usr/local/var/etc/squid/squid.conf
|
||||
|
||||
```conf
|
||||
# Squid listening port
|
||||
# http_port 3128
|
||||
## Disable SSLv2 because it isn't safe
|
||||
http_port 3128 ssl-bump cert=/usr/local/var/etc/squid/squid.pem key=/usr/local/var/etc/squid/squid.pem generate-host-certificates=on options=NO_SSLv2 dynamic_cert_mem_cache_size=10MB
|
||||
|
||||
## Always complete the server-side handshake before client-side (recommended)
|
||||
ssl_bump server-first all
|
||||
## Allow server side certificate errors such as untrusted certificates, otherwise the connection is closed for such errors
|
||||
sslproxy_cert_error allow all
|
||||
## Or maybe deny all server side certificate errors according to your company policy
|
||||
#sslproxy_cert_error deny all
|
||||
## Accept certificates that fail verification (should only be needed if using 'sslproxy_cert_error allow all')
|
||||
sslproxy_flags DONT_VERIFY_PEER
|
||||
```
|
||||
|
||||
```bash
|
||||
$ openssl req -newkey rsa:4096 -x509 -keyout /usr/local/var/etc/squid/squid.pem -out /usr/local/var/etc/squid/squid.pem -days 365 -nodes
|
||||
$ sudo mkdir /usr/local/var/lib
|
||||
$ sudo /usr/local/opt/squid/libexec/ssl_crtd -c -s /usr/local/var/lib/ssl_db
|
||||
$ sudo chown -R nobody /usr/local/var/lib/ssl_db
|
||||
```
|
||||
12
mywiki/tiddlers/boot2docker reset.tid
Normal file
12
mywiki/tiddlers/boot2docker reset.tid
Normal file
@ -0,0 +1,12 @@
|
||||
created: 20151014192435114
|
||||
creator: user
|
||||
modified: 20151014192525625
|
||||
modifier: user
|
||||
tags:
|
||||
title: boot2docker reset
|
||||
type: text/vnd.tiddlywiki
|
||||
|
||||
reset dhcp (dns)
|
||||
`sudo killall -USR1 udhcpc`
|
||||
|
||||
`dm ssh dev -- sudo killall -USR1 udhcpc`
|
||||
17
mywiki/tiddlers/docker install.tid
Normal file
17
mywiki/tiddlers/docker install.tid
Normal file
@ -0,0 +1,17 @@
|
||||
created: 20151026124201488
|
||||
creator: user
|
||||
modified: 20151026124457316
|
||||
modifier: user
|
||||
tags:
|
||||
title: docker install
|
||||
type: text/vnd.tiddlywiki
|
||||
|
||||
; Install Docker
|
||||
: https://docs.docker.com/linux/step_one/
|
||||
|
||||
; get.docker.com
|
||||
: https://get.docker.com/
|
||||
|
||||
```sh
|
||||
wget -qO- https://get.docker.com/ | sh
|
||||
```
|
||||
@ -1,6 +1,6 @@
|
||||
created: 20150930083128106
|
||||
creator: user
|
||||
modified: 20151001083403309
|
||||
modified: 20151026154150775
|
||||
modifier: user
|
||||
tags:
|
||||
title: functional programming
|
||||
@ -22,4 +22,8 @@ type: text/vnd.tiddlywiki
|
||||
: CycleJS
|
||||
|
||||
; Functional Programming in Javascript
|
||||
: http://reactivex.io/learnrx/
|
||||
: http://reactivex.io/learnrx/
|
||||
|
||||
; Functional Programming in Javascript === Garbage
|
||||
: http://awardwinningfjords.com/2014/04/21/functional-programming-in-javascript-equals-garbage.html
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user