Le Journal des Admins Sys

rsync est un excellent outil de sauvegarde et de transfert de fichier. Il est fréquemment appelé depuis la crontab, pour faire une sauvegarde journalière par exemple.

Problème : quand on sauvegarde une arborescence qui "vit", il arrive que des fichiers soient modifiés, ou disparaissent pendant l'exécution de rsync.

rsync gère correctement tous ces cas, mais il affiche des "warnings" sur la sortie d'erreur. Ainsi, la ligne cron suivante :

2 2 * * * rsync -av remote.server.example.com:/path/to/live/directory/ /path/to/backup/ > /path/to/logfile

Pourra envoyer des warnings par mail à l'administrateur du serveur. Exemples de warnings :

file has vanished: "/var/spool/postfix/active/DF00000A000"
rsync warning: some files vanished before they could be transferred (code 24) at main.c(1524) [generator=3.0.3]

WARNING: var/lib/munin/server/file.rrd failed verification -- update discarded (will try again).

Solution 1

Si c'est possible et souhaitable, on exclut les fichiers de la sauvegarde à l'aide d'options --exlude passées à rsync.

Solution 2

On envoie la sortie d'erreur dans un fichier pour l'afficher uniquement si rsync sort un code de retour d'erreur.

Dans un script :

rsync -av remote.server.example.com:/path/to/live/directory/ /path/to/backup/ 2>/tmp/rsync_stderr.log
RET=$?
if [ "$RET" = "24" -o "$RET" = "0" ]
then
    exit 0
else
    echo "rsync return code: $RET" >&2
    cat /tmp/rsync_stderr.log >&2
    exit "$RET"
fi

Si on veut pouvoir lancer plusieurs instances du script en parallèle, on passera par un fichier temporaire :

TEMPFILE=$(mktemp)
trap "rm -f $TEMPFILE" EXIT  # man mktemp; man tempfile
rsync -av remote.server.example.com:/path/to/live/directory/ /path/to/backup/ 2> $TEMPFILE
RET=$?
if [ "$RET" = "24" -o "$RET" = "0" ]
then
    exit 0
else
    echo "rsync return code: $RET" >&2
    cat $TEMPFILE >&2
    exit "$RET"
fi

Solution 3

On utilise un script d'encapsulation (wrapper), dérivé de l'exemple du site officiel de rsync (http://rsync.samba.org/FAQ.html#10).

La méthode utilisée procède par inversion des descripteurs de sortie standard et d'erreur, car un pipe agit uniquement sur la sortie standard.

(/usr/local/bin/rsync.sh)

#!/bin/bash
# filter some rsync error output

# note: 3>&1 1>&2 2>&3 just inverts stdout and stderr
{
rsync "$@" 3>&1 1>&2 2>&3 | grep -v \
        -e "^WARNING:.*update discarded.*" \
        -e "^file has vanished:" \
        -e "^rsync warning: some files vanished"
} 3>&1 1>&2 2>&3

# get return code of first command in pipes (bash only)
RET="${PIPESTATUS[0]}"

# when files vanished, rsync returns 24. We ignore it.
# also see http://rsync.samba.org/FAQ.html#10
if [ "$RET" = "24" ]
then
        exit 0
else
        exit "$RET"
fi

Cette dernière solution est plus "précise" dans le sens où elle affiche les erreurs de manière synchrone, et filtre uniquement les warnings connus. En revanche, elle est un peu plus compliquée.

Liens :

• http://rsync.samba.org/
• http://fr.wikipedia.org/wiki/Rsync
• http://mywiki.wooledge.org/BashFAQ/...
• http://mywiki.wooledge.org/BashFAQ/...
• http://wiki.bash-hackers.org/howto/...

Voici comment s'authentifier sur un serveur Linux Debian/Ubuntu, avec des comptes utilisateurs stockés sur un serveur Active Directory.

En premier lieu, il convient de bien saisir la différence entre l'identification et l'authentification.

• L'identification permet simplement l'accès aux informations de l'utilisateur, et l'association entre son UID et son nom. Elle est utilisée par exemple pour afficher le nom de l'utilisateur à partir de l'UID dans la commande ls -l. L'identification est gérée par la libnss.
• L'authentification permet d'autoriser ou non l'accès au service à l'utilisateur. Elle est gérée par PAM (Pluggable Authentication Modules).

Il est donc nécessaire d'installer 2 paquets : libnss-ldap pour l'identification, et libpam-krb5 pour l'authentification :

aptitude install libnss-ldap libpam-krb5

La configuration de l'identification se fait dans les fichier /etc/libnss-ldap.conf et etc/nsswitch.conf :

Voici un exemple de fichier /etc/libnss-ldap.conf :

base dc=company,dc=com
uri ldap://ad1.intranet ldap://ad2.intranet
referrals no
ldap_version 3
pam_password md5
pam_password md5
nss_base_passwd ou=Users,dc=company,dc=com?sub?objectClass=user
nss_base_group          dc=company,dc=com?sub?&(gidNumber=*)
nss_map_attribute uid msSFU30Name
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,couchdb,daemon,games,gdm,gnats,haldaemon,hplip,irc,kernoops,libuuid,list,lp,mail,man,messagebus,mysql,news,proxy,pulse,root,saned,speech-dispatcher,sshd,statd,sync,sys,syslog,uucp,www-data

Attention : sous Ubuntu le fichier /etc/libnss-ldap.conf est en fait /etc/ldap.conf (voir /usr/share/doc/libnss-ldap/README.Debian).

Et il faut ajouter les mots "ldap" dans /etc/nsswitch.conf :

passwd:         compat ldap
group:          compat ldap

On peut maintenant tester l'identification par :

getent passwd USER

Pour l'authentification, tout se passe dans /etc/krb5.conf et les fichiers /etc/pam.d/common-* :

[libdefaults]
        default_realm = COMPANY.COM

[realms]
        COMPANY.COM = {
                kdc = ad1.intranet
                kdc = ad2.intranet
        }

[domain_realm]
        .intranet = COMPANY.COM

[login]
        krb4_convert = true
        krb4_get_tickets = false

Et pour la configuration PAM, il suffit de rajouter les ligne suivante en haut des fichiers common-auth, common-session, common-account et common-passwd :

auth  sufficient  pam_krb5.so minimum_uid=1000

session  optional  pam_krb5.so minimum_uid=1000

account  required  pam_krb5.so minimum_uid=1000

password  sufficient  pam_krb5.so minimum_uid=1000

(Comme expliqué dans /usr/share/doc/libpam-krb5/README.Debian.)

Voila, on peut maintenant tester l'authentification à l'aide de la commande login, ou en SSH. En cas de problème, aller voir dans le fichier /var/log/auth.log.

Pour aller plus loin, on pourra ajouter la création automatique du dossier de l'utilisateur en ajoutant la ligne suivante dans /etc/pam.d/common-session :

session  required  pam_mkhomedir.so

On peut aussi restreindre l'accès à une liste blanche d'utilisateurs uniquement dans /etc/pam.d/common-auth :

auth  required    pam_listfile.so onerr=fail item=user sense=allow file=/etc/loginusers

Voir aussi man pam_krb5, man pam_mkhomedir et man pam_listfile.

Voici comment utiliser le module apache mod_substitute pour modifier à la volée le contenu envoyé par apache.

Note : cette pratique n'est à utiliser qu'en dernier recours. Il est toujours mieux de faire les modifications à la source (dans le site) quand c'est possible.

À partir de Debian Lenny (Apache 2.2.7 et plus), mod_substitute est installé par défaut avec Apache :

a2enmod substitute
/etc/init.d/apache2 restart

Puis ajouter une configuration de ce genre dans votre virtualhost :

<Location />
        AddOutputFilterByType SUBSTITUTE text/html
        AddOutputFilterByType SUBSTITUTE text/css

        Substitute "s/Hello/Hello world/"
        Substitute "s| src=\"([^\"\?]*)\"| src=\"$1?refresh\"|"
        Substitute "s|link href=\"([^\"\?]*)\"|link href=\"$1?refresh\"|"
        Substitute "s|url\(([^(]*)\)|url($1?refresh)|"
</Location>

Ensuite, on teste la configuration puis on la charge dans Apache.

apache2ctl -S
/etc/init.d/apache2 reload

Maintenant il ne reste plus qu'à tester !

La configuration en exemple remplace bien sûr tous les "Hello" par des "Hello world", mais elle permet aussi de rajouter des "?refresh" à la fin des chemins d'accès aux images et autres éléments du site. Exemple : <img src="monimage.png" /> sera remplacé par <img src="monimage.png?refresh" />.

Cette réécriture permet de changer les URLs des images d'un site, et donc de forcer les navigateurs clients à recharger les contenus. Très utile en cas de mauvaise utilisation de mod_expires et des directives du type : ExpiresByType image/png "access plus 2 years".

Notes :

• Il existe aussi un module Apache mod_proxy_html dédié aux modifications de contenu HTML, basé sur un parseur SAX. Je n'ai pas réussi à faire fonctionner correctement ce module avec notre site (suppression de l'en-tête DTD, problème de codage). Il faudrait peut-être pousser plus en avant les tests.
• Attention à vos règles de remplacement : elles peuvent peut-être causer des effets de bord ailleurs dans le site.

Sous version d'Apache antérieure à la 2.2.7 (Debian Etch), vous pouvez utiliser mod_line_edit, avec une configuration telle que :

SetOutputFilter line-editor
SetEnv  LineEdit "text/html;text/css"

LERewriteRule "Hello" "Hello world"
LERewriteRule " src=\"([^\"\?]*)\"" " src=\"$1?refresh\"" R
LERewriteRule "link href=\"([^\"\?]*)\"" "link href=\"$1?refresh\"" R
LERewriteRule "url\(([^(]*)\)" "url($1?refresh)" R

Note : on peut compiler le module Apache à l'aide de la commande apxs2.

Quand on fait vzctl enter depuis un parent OpenVZ pour accéder à une machine virtuelle enfant, on obtient un environnement incomplet (pas d'historique des commandes, mauvaise locale...).

Il faut faire su - pour récupérer un environnement cohérent :

parent:~# vzctl enter enfant
entered into VE 101
enfant:/# echo $LANG

enfant:/# su -
enfant:~# echo $LANG
en_US.UTF-8

Pour palier à ce problème, nous ajoutons les lignes suivantes au début du fichier /root/.bashrc dans l'enfant :

# si l'environement n'est pas bon (vzctl enter ?)
# on lance un shell de login
if [ "$LANG" = "" ]
then
        exec su -
fi

À noter que dans la mesure du possible, il est préférable d'accéder au serveur enfant par SSH, ce qui est plus cohérent d'un point de vue de la virtualisation (isolation parent/enfant). En SSH, il n'y a pas ce problème d'environnement.

Le bonding est une technique qui permet d'agréger deux ports réseaux d'un serveur sous Linux en un seul.

L'objectif poursuivi est d'obtenir la redondance au niveau des ports réseau du serveur lui-même, en utilisant idéalement deux cartes réseau différentes, et non pas deux ports de la même carte, mais surtout de pouvoir utiliser deux commutateurs distincts et se mettre à l'abri de la panne d'un commutateur.

Il est également possible d'utiliser le bonding pour augmenter le débit, puisqu'on utilise deux ports, mais dans ce cas, il faut que les liens soient connectés au même commutateur. Ce mode ne répond pas à la problématique de haute disponibilité.

Chez Cisco, on parle de Etherchannel. Sous OpenBSD, on appelle ces interfaces des trunks (attention à ne pas confondre avec les liens trunk entre switchs quand on utilise des VLANS).

L'objectif du bonding dans nos infrastructures est d'avoir une infrastructure entièrement redondante en composants réseaux : commutateurs, firewalls, cablages, etc.... Dans notre cas, le bonding fonctionne en mode actif/passif, un seul des ports étant actif à un moment donné.

Avoir une infrastructure réseau redondante assure une haute disponibilité de fonctionnement, mais surtout, permet de procéder à la maintenance des commutateurs sans coupure réseau.

Voici la procédure pour faire du bonding sur une Debian Lenny.

Installation et configuration

• On installe les outils qui vont nous permettre d'attacher/détacher une interface au bonding :

~# aptitude install ifenslave

• On modifie ensuite le fichier de configuration réseau :

lenny:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto bond0
iface bond0 inet static
      slaves eth0 eth2
      bond_mode active-backup
      bond_miimon 100
      bond_downdelay 200
      bond_updelay 200
      address xxx.xxx.xxx.xxx
      netmask xxx.xxx.xxx.xxx
      network xxx.xxx.xxx.xxx
      gateway xxx.xxx.xxx.xxx

Toutes références aux interfaces attachées au bonding (ici eth0 et eth2) sont supprimées.

Pour les paramètres :

• slaves permet d'attacher les interfaces spécifiées au bonding. Dans notre cas eth0 et eth1 sont sur la carte mère et eth2 et eth3 sont sur une carte d'extension.
• bond_mode permet de déterminer le mode d'utilisation : dans notre cas, actif / passif, mais on peut choisir par exemple balance_rr pour faire de l'équilibrage de charge. Voir les options possibles sur le site kernel.org.
• bond_miimon est le temps en ms passé entre deux monitoring
• bond_downdelay correspond au temps en ms entre le moment où la carte réseau est détectée comme défaillante et celui où on la retire du bonding.
• bond_updelay correspond au temps en ms entre le moment où la carte réseau qui était défaillante revient à la vie et celui où elle est remise dans le bonding.

Un redémarrage plus tard (des /etc/init.d/networking restart à distance sur ce genre de manipulations nous ont donné d'assez mauvais résultats ;)), l'interface bond0 doit être visible via un ifconfig.

Références

http://www.kernel.org/doc/Documentation/networking/bonding.txt

Prérequis

Tout d'abord, les utilisateurs postgres sur les serveurs maîtres et esclave doivent pouvoir se connecter en ssh dans les deux sens sans mot de passe :

postgres@master~$ ssh slave
postgres@slave~$ ssh master

Il faut aussi installer le paquet postgresql-contrib pour bénéficier de l'outil pg_standby :

master:~# aptitude install postgresql-contrib-8.3
slave:~# aptitude install postgresql-contrib-8.3

Activation des archives logs

On crée le dossier pour les logs sur le slave :

postgres@slave:~$ mkdir /var/lib/postgresql/archivelog/

On active les journaux de transactions. Un journal de transaction est envoyé par rsync vers le serveur esclave dès que le fichier de log est plein (16Mo), ou que le timeout est atteint (1 minute ici).

master:~# vi /etc/postgresql/8.3/main/postgresql.conf
archive_mode = on
archive_command = 'rsync -a %p slave:/var/lib/postgresql/archivelog/%f'
archive_timeout = 60
master:~# /etc/init.d/postgresql-8.3 restart

À ce point, on voit les journaux de transactions locaux, et les journaux archivé à distance :

postgres@master:~$ ls -ltr /var/lib/postgresql/8.3/main/pg_xlog/

postgres@slave:~$ ls -ltr /var/lib/postgresql/archivelog/

En cas de problème, observer le fichier /var/log/postgresql/postgresql-8.3-main.log (problème de rsync...)

Note : un CHECKPOINT est nécessaire pour que le fichier de log soit archivé (toutes les 5min par défaut). On peut le forcer à l'aide de la commande SQL éponyme.

Sauvegarde à chaud du maître

Sur le maître :

postgres@master:~$ psql
postgres=# SELECT pg_start_backup('label');

Sur l'esclave :

postgres@slave:~$ /etc/init.d/postgresql-8.3 stop
postgres@slave:~$ rsync -av --delete --exclude="recovery.conf" master:/var/lib/postgresql/8.3/main/ /var/lib/postgresql/8.3/main/
# on efface les fichiers de logs en gardant le dossier archive_status
postgres@slave:~$ rm -f /var/lib/postgresql/8.3/main/pg_xlog/*

Sur le maître :

postgres=# SELECT pg_stop_backup();

Lancement de la réplication

postgres@slave:~$ vi /var/lib/postgresql/8.3/main/recovery.conf
restore_command = '/usr/lib/postgresql/8.3/bin/pg_standby -d -t /tmp/stopstandby /var/lib/postgresql/archivelog %f %p %r >> /var/log/postgresql/pg_standby.log 2>&1'
postgres@slave:~$ /etc/init.d/postgresql-8.3 start

Maintenant, on peut observer l'injection des fichiers de logs :

postgres@slave:~$ tail -f /var/log/postgresql/pg_standby.log
postgres@slave:~$ less /var/log/postgresql/pg_standby.log
postgres@slave:~$ ps -edf | grep "waiting"
postgres  2908  2907  0 15:22 ?        00:00:00 postgres: startup process   waiting for 000000010000000000000040          

Arrêt de la réplication

Une fois la réplication lancée, toute connexion au serveur est impossible :

postgres@slave:~$ psql
psql: FATAL:  the database system is starting up

On peut casser la réplication en créant le fichier stopstandby :

postgres@slave:~$ touch /tmp/stopstandby

À ce point, pour faire repartir la réplication, il faut refaire une sauvegarde à chaud.

Références

• http://www.postgresql.org/docs/8.3/interactive/warm-standby.html