: > /dev/null

Jun 22, 2016

Nginx with proxy cache and SPDY prematurely closes connection

I've enabled SPDY on nginx 1.6.2 shipped with Debian GNU/Linux 8 Jessie.

In Chrome's DevTools Console i saw:

GET https://mysite/myasset.ico net::ERR_CONNECTION_CLOSED

When get my static assets. I started to dig/search a similar issue and find that the problem is not specific to Chrome and reproducible with Firefox. I've found that the combo of nginx + ssl + spdy + proxy_cache was the issue in a Chrome bug.

The problem is that SPDY connection is closed prematurely if proxy caching is used. As SPDY multiplex connections, if the connection is closed, all other transactions are lost.

This bug is fixed in nginx version 1.7.3 of nginx and on i will choose one of the following options:

  • Upgrade nginx by using Debian backport (>= 1.9.10)
  • Disable SPDY, as the protocol is superseded by HTTP/2 and i don't need for this for now (just a one shot test). Nginx 1.9.5 is the first release that implement HTTP/2.

Detail of nginx original bug https://trac.nginx.org/nginx/ticket/428

Sep 02, 2015

pnp4nagios dans Debian Jessie

EDIT 2016-03-31: un backport Debian officiel existe depuis le 8 décembre 2015.

Après upgrade en Jessie, pnp4nagios 0.6.16-2 n'est plus dans l'archive stable. En fait, il est resté installé et les graphes ne s'affichent plus (/pnp4nagios/graph?host=host&srv=service) :

Please check the documentation for information about the following error.

Non-static method nagios_Core::SummaryLink() should not be called statically, assuming $this from incompatible context
file [line]:

application/views/graph_content.php [47]:

Pnp4nagios me sert à grapher les perfdata issues de nagios. En plus de lagguer, je n'ai pas vraiment de mérite puisque c'est connu depuis au moins le 29 juin 2014 :

# sed --in-place=.orig "s|error_reporting(E_ALL \& ~E_STRICT);$|error_reporting(E_ALL \& ~E_STRICT \& ~E_DEPRECATED); // see https://bugs.debian.org/752088|" /usr/share/pnp4nagios/html/index.php

Comme il y a pas mal de changement entre la version 0.6.16-2 et celle de testing, j'ai fait un backport, le paquet n'étant pas dans l'archive, il faut aller chercher le paquet source manuellement (et apt-get build-dep ne sait pas encore lire un dsc pour le moment)

# dget --allow-unauthenticated http://http.debian.net/debian/pool/main/p/pnp4nagios/pnp4nagios_0.6.24+dfsg1-4.dsc
# apt-get install dh-autoreconf quilt rrdtool librrds-perl python-jsmin
# cd pnp4nagios*
# dch --bpo
# dpkg-buildpackage

J'en ai profité pour inclure le patch concernant le problème de niveau d'erreur PHP et l'ai poussé ici.

Aug 18, 2015

Nagios nrpe dans Debian Jessie

Ouai je lag un peu par rapport à d'autres (en fait j'ai vu cet article après). Depuis Debian Jessie, il n'est plus possible d'utiliser l'option de configuration dont_blame_nrpe « outofthebox » dans /etc/nagios/nrpe.cfg. En effet, celle-ci a été désactivée à la compilation.

Selon la stratégie, deux options s'offrent à nous pour la numérotation de la version de ce nouveau paquet :

  • 2.15-2: aura pour effet d'être supérieur à 2.15-1 et aux éventuelles mises à jour de sécurité (voir ici pour la référence; s'il y a une mise à jour de sécurité, il y a de grandes chances pour le paquet soit numéroté 2.15-1+deb8u1)
  • 2.15-1local1: aura pour effet d'être supérieur à 2.15-1 mais inférieur lors de nouvelles mises à jour de sécurité. Le paquet local sera donc conservé (on peut s'aider de dpkg --compare-versions pour vérifier mes dires).

Pour ce cas de figure d'un agent de supervision (chacun ses contraintes), je préfère que le paquet ne soit pas conservé en cas de mise à jour, cela me forcera à prendre en compte / étudier des éventuels changements du paquet et à le reconstuire si besoin.

La reconstruction du paquet maintenant :

  • On choisit une machine qui va faire la compilation (en général je préfère utiliser debootstrap pour créer un chroot dédié à cet effet). Une fois le paquet construit, il suffira de l'installer sur d'autres machines Debian Jessie (en partant du principe que c'est la même architecture) via dpkg --install ou via un dépôt local avec apt
  • On installe build-essential (et devscripts pour avoir dch), le paquet source nagios-nrpe et toutes ses dépendances de constructions avec apt-get build-dep qui va les récupérer du paquet source et se débrouiller
  • On rajoute la fameuse option --enable-command-args dans debian/rules, si pas déjà présente
  • On ajoute une entrée dans debian/changelog pour incrémenter la version et facilement identifier nos changements
  • On build !
sudo apt-get install build-essential devscripts lsb-release

# s'assurer qu'on a une source deb-src dans sources.list(.d), sinon en ajouter :
cat << EOF > /etc/apt/sources.list.d/sources.list
deb-src http://ftp.fr.debian.org/debian $(lsb_release --codename --short) main

sudo apt-get update
sudo apt-get source nagios-nrpe-server
sudo apt-get --yes build-dep !$ && cd nagios-nrpe*

# oneliner pour ne rajouter l'option de compilation que s'il n'est pas déjà présente
grep --quiet "\-\-enable-command-args" debian/rules || \
sed --in-place "/--enable-ssl/a \\\t\t--enable-command-args \\\\" debian/rules

dch --local local "Rebuild with --enable-command-args (see #773840, #756479)"
sudo dpkg-buildpackage

Le paquet pour l'agent nrpe résultant sera nagios-nrpe-server_2.15-1local1_amd64.deb. J'ai buildé mon mien ici.

Jul 18, 2015

Remote IPv4 address migration

I've to switch from one Debian GNU/Linux virtual machine (provided by a friend ;)) to another, but must keep the same IPv4 public address (and stay in the same broadcast domain). The new VM has as temp public IPv4 address to prepare the switch.

When ready, i had some options to use the old IPv4 address on the new VM:

  • Phone my friend to coordinates IPv4 migration
  • Poweroff the old VM and use ip binary to switch from temp to old address

As this VM is part of my sandbox machines (with real hosted services, but no impact or customers depending on them), i've choosen the later option :)

As a system administrator, i never do this kind of things @work and never try to modify single network interface without having KVM, serial over LAN or any other out-of-band management to use tty direct access. Before starting this, it's time to test your login access (yes, i mean the random chars stored on a password database that you never use because you use ssh keypair on your daily tasks).

What i've installed before started:

  • at (yes, you know, the old and venerable)
  • iputils-arping, to have arping and especially -U option to do a gratuitous ARP. This will update neighbours ARP cache (poke gateway) because the MAC address will change for an already seen IPv4 address.

Now, it's 00:23, time to do a poor backup of all files on the old machine and transfert it to new:

old# tar --exclude='/proc' --exclude='/var/cache/rsnapshot' --exclude='/sys' --exclude='/dev' --exclude='/var/cache/apt/archives' --exclude=/root/saturnaab.tar.gz --exclude='/srv/backup/kimsuflol.iroqwa.org' --exclude='/var/lib/puppet/reports' -zcvf saturnaab.tar.gz /
new# scp .

Then, i can start to poweroff the old box, bye bye...but wait, when do you born ? Let's find an installation file date that i've never edited:

old# stat /etc/nanorc | grep ^Modify
Modify: 2010-04-15 19:39:40.000000000 +0200

Enough. poweroff i say.

old# poweroff

I used halt before (but this year) to shutdown a system, since systemd is the default init system on Debian, this no more works (because halt works by accident ?).

Now that the old box is not more reachable:

new# ping -c 1 -W 2
PING ( 56(84) bytes of data.

--- ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

I can start to break the new box. Hmm, before this, maybe it's good to have a whatchdog to restart automa[tg]ically the eth0 interface by reading notyetuntouched /etc/network/interfaces (remember to remove this if all works, remember to remove this...):

new# echo 'ifdown --force eth0; ifup eth0' | at now + 15 minutes

Start the ip switch:

new# ip addr add dev eth0

Note the /32 CIDR mask to be untouched by the kernel.

Try to ping the old address on the new machine:

desktop$ ping -c 1 -W 2
PING ( 56(84) bytes of data.

--- ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Crap, the old ip isn't reachable...need to send a gratuitous ARP packet to update ARP table on the gateway (that i don't have administrative access):

new# arping -s -U
ARPING from eth0
^CSent 6 probes (6 broadcast(s))
Received 0 response(s)

I've forced to use the old address (-s) and ask with ARP what is the MAC for myself (O_o)

new# ip addr del dev eth0

At this time, the first shell is dead because connected through

And now i can assign the old address with the correct mask and remove the temp the one with /32:

new# ip addr add dev eth0
new# ip addr del dev eth0

And voila ! Oh no, the at whatchdog command will revert all these efforts, le'ts remove it:

new# atq
1   Wed Jul 22 01:04:00 2015 a root
new# atrm 1

To finish, just need to edit configuration in /etc/network/interfaces to use the old address and remove all occurences of the temp one). Next, a reboot to validate the file confirm me that the configuration is correct. Because if i have to restart the box later, i will not suspect other things to prevent booting correctly...

Source: http://madduck.net/blog/2006.10.20:freeing-the-primary-ip-address/

Aug 19, 2014

Marre des dns menteurs

Plutôt que d'utiliser le serveur dns de mon FAI, je vais faire la requête récursivement moi-même, afin d'alimenter un cache local de qualité. Bien entendu, le jour où les requêtes dns non signées DNSSEC seront interceptés et remplacés, ça ne fonctionnera plus, mais d'ici là...

J'ai chez moi un NAS QNAP TS 409 (vieux) mais qui peut parfaitement répondre à ce besoin. J'ai envie de changer de bind, je vais utiliser unbound:

[~] # apt-get install unbound
-sh: apt-get: command not found

Heu, je comprends pas bien là (je plaisante, j'ai l'habitude de l'auto-complétion de bash et là ça trouvait pas grand chose, tout est calculé public).

Ouai sur QNAP, y a quand même un truc pour avoir des paquets, ça s'appelle optware (la guerre des options je crois en anglais..ou pas) sur QNAP. Ca permet d'installer des ipkg. J'ai même trouvé NSLU2-Linux qui font des choses qui pourraient bien s'emboiter avec mon NAS. Une fois que tout ça est installé (cs05q1armel = ARM + glibc2.3.4), on peut faire un :

[~] # ipkg install unbound
Nothing to be done
An error ocurred, return value: 4.
Collected errors:
Cannot find package toto.
Check the spelling or perhaps run 'ipkg update'

Ah ba non, on dirait bien que pour cs05q1armel y a pas unbound. Bon ben on va fouiller alors:

$ svn checkout http://svn.nslu2-linux.org/svnroot/optware/trunk optware
$ cd optware; make cs05q1armel-target
$ cd cs05q1armel; make directories toolchain ipkg-utils

Regarder dans make/unbound.mk, désactiver gost car openssl est trop vieux sur mon machin et hop :

Index: unbound.mk
--- unbound.mk  (revision 13128)
+++ unbound.mk  (working copy)
@@ -27,7 +27,7 @@
 # "NSLU2 Linux" other developers will feel free to edit.
@@ -124,6 +124,8 @@
    if test "$(BUILD_DIR)/$(UNBOUND_DIR)" != "$(@D)" ; \
        then mv $(BUILD_DIR)/$(UNBOUND_DIR) $(@D) ; \
+   # disable gost support as openssl is version 0.9.8v on cs05q1armel
+   # and gost openssl support require 1.0.x
    (cd $(@D); \
@@ -138,6 +140,7 @@
        --without-pthreads \
        --disable-nls \
        --disable-static \
+       --disable-gost \
    $(PATCH_LIBTOOL) $(@D)/libtool
    touch $@

Reste plus qu'à lancer make unbound (dans optware, pas dans cs05q1armel), récupérer unbound_1.4.22-1_arm.ipk, faire un ipkg install /tmp/unbound_1.4.22-1_arm.ipk, comprendre l'arborescence dans /opt et avoir un unbound.conf quivabien et c'est terminé. Ah et aussi configurer le dhcp de la bobox pour utiliser d'abord le serveur dns du nas, puis le sien et ce sera tout.

Nov 22, 2008

May 17, 2008

Le tour du net en questions

Il y a bien longtemps, j'étais tombé sur un site web expliquant de manière assez simple pour le néophyte mais suffisement détaillé pour les plus avancés, les différentes technologies de l'Internet: du fonctionnement de l'ADSL au mode de fonctionnement des outils que nous utilisons au quotidien (navigateur web, messagerie, etc...), tout y est.

Aug 21, 2007

Next → Page 1 of 2