iproute2 vlan

ip link add link eth0 name eth0.100 type vlan id 100
ip link delete eth0.100

Bonding przez sysfs

modprobe bonding max_bonds=0

echo +host0 > /sys/class/net/bonding_masters
echo 802.3ad > /sys/class/net/host0/bonding/mode
echo +eno1 > /sys/class/net/host0/bonding/slaves
echo +eno2 > /sys/class/net/host0/bonding/slaves

pygrub GRUB2 XEN

Change line 428 from:

if arg.strip() == "${saved_entry}":

into:

if arg.strip() == "${saved_entry}" or arg.strip() == "${next_entry}":

from: http://virantha.com/2014/05/21/ubuntu-14-04-trusty-on-xenserver-62/

Weryfikcja zgodności certyifkatu i klucz prywatnego

openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5
openssl req -noout -modulus -in server.csr | openssl md5

Certyfikat self-signed

openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout cert.pem -out cert.pem

więcej: http://www.madboa.com/geek/openssl/ 

Wersja offline

BSD vs GPL

Cytat:

> BSD: "If you love something, set it free.  If it comes back to you, 
> it was meant to be."
>
> GPL: "If you love something, set if free, but put a chain around 
> it's neck to make sure it doesn't get out of sight."

Natrafienie na ten cytat związany jest z  bardzo, bardzo, bardzo wątpliwą zawartością strony: http://aboutthebsds.wordpress.com/ (adresu celowo nie linkuję).
Nie pamiętam bym przez ostanie dwie dekady miał możliwość zapoznania z takim poziomem treści.
Niewątpliwie zawartość strony rozbawiła mnie ale zapoznanie się z treściami zawartymi w powyższym blogu byłoby niesamowitą stratą czasu gdyby nie powyższy cytat.
Cytat nie pojawił się oczywiście na stronie. Napotkałem go na liście dyskusyjnej FreeBSD gdzie był poruszony temat tej nieszczęsnej strony.

nginx + node.js (proxy)

Konfiguracja serwera nginx jako serwera proxy dla aplikacji node.js (do zastosowań developerskich). Poniższa konfiguracja umożliwia:

• dynamiczne tworzenie adresu dla aplikacji node.js nasłuchującej na partach od 10000 do 10999 (na adresie localhost)
• serwowanie plików statycznych poprzez serwer Nginx zamiast poprzez aplikację node.js
• obsługę websocket (upgrade połączenia) 
•  

Obsługa websocket po stronie nginx-a jest możliwa (z pamięci) od wersji 1.4.x (na pewno działa w wersji 1.6.x).

# Kontekst http{}
map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}
server {

        listen 80;
        listen [::]:80;

        server_name  ~^app.([0-9]?[0-9]?[0-9])\.socha\.it$;
        set $url_node_port $1;
        if ($url_node_port ~* "^[0-9]$") {
            set $app_node_port 1000$url_node_port;
        }
        if ($url_node_port ~* "^[0-9][0-9]$") {
            set $app_node_port 100$url_node_port;
        }
        if ($url_node_port ~* "^[0-9][0-9][0-9]$") {
            set $app_node_port 10$url_node_port;
        }

        root /storage/web/node/app/$app_node_port;

        location /system-problem/ {
                root /storage/web/default;
        }

        location = / {
                try_files /index.html @application;
        }
        location / {
                try_files $uri @application;
        }
        location @application {
                error_page 502 =404 /system-problem/error.html;
                proxy_pass http://127.0.0.1:$app_node_port;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
        }
}

Adres wywołania wygląd tak:
app.0.socha.it     - co jest mapowane na adres aplikacji node.js 127.0.0.1:10000
app.1.socha.it     - co jest mapowane na adres aplikacji node.js 127.0.0.1:10001
app.99.socha.it   - co jest mapowane na adres aplikacji node.js 127.0.0.1:10099
app.999.socha.it - co jest mapowane na adres aplikacji node.js 127.0.0.1:10999
itd...
Adresy typu app.0, app.00 czy app.000 są tożsame (tj. mapowane do adresu 10000). Tak samo jak np. app.5, app.05 czy app.005 (port 10005).

Obsługa plików statycznych odbywa się poprzez utworzenie katalogu:

/storage/web/node/app/<PORT> 

np. katalog /storage/web/node/app/10000.
W pierwszej kolejności w powyższym katalogu sprawdzana jest obecność pliku i jeśli jest on dostępny jest serwowany przez nginx-a. Jeśli plik nie zostanie odnaleziony wywoływana jest aplikacja node.js (na wybranym porcie), która może obsłużyć dane wywołanie. (powyższy mechanizm sprawdził się w jednym z moich projektów gdzie służył do generacji miniaturek obrazków - jeśli miniaturka nie istniała aplikacja node.js generowała plik, który przy następnym wywołaniu był już bezpośrednio serwowany przez nginx-a). Dodatkowo dla adresu / obsługiwane jest statyczny plik index.html. Łatwo to rozszerzyć o obsługę pliku index.html  (lub dowolnej innej nazwy) dla pozostałych katalogów:

        location / {
                try_files $uri $uri/index.html @application;
        }

W przypadku braku możliwości połączenia z aplikacją node.js (502 - Bad Gateway) zwracany jest błąd 404 i zawartość pliku /storage/web/default/system-problem/error.html.

PS: Ostrożnie z dyrektywą If
http://wiki.nginx.org/IfIsEvil
http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html