La commande sfdisk permet de manipuler les tables de partitions et de dupliquer très simplement la structure de cette table d’un disque vers un autre. Si on veut copier la table des partitions du disque /dev/sda vers le disque /dev/sdb la commande sera :

sfdisk -d /dev/sda | sfdisk /dev/sdb

C’est très pratique si on veut initialiser un volume RAID 1 par exemple.

Attention quand même, comme toutes les commandes de bas niveau qui agissent sur la table des partitions, une mauvaise manip peut avoit des conséquences douloureuses. Mieux vaut réfléchir un brin avant d’appuyer sur Entrée…

Lien : La man page de sfdisk, très bien faite, qui indique les options de sauvegarde et restauration

Le démon snmpd est un grand bavard dans sa configuration par défaut sous Debian et Ubuntu, et on se retrouve rapidement avec un syslog envahi de messages à chaque connexion d’un client snmp :

Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:42720
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:55670
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:56655
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:55557
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:46846
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:34805
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:49261
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:35418
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:35673

Pour clouer le bec à l’insolent, il faut aller modifier les options de démarrage SNMPDOPTS du démon dans /etc/default/snmpd :

SNMPDOPTS=’-LS4d -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid ’

L’option qui nous intéresse est -LS4d qui permet de n’écrire dans syslog qu’à partir du niveau warning. Un petit redémarrage du démon et le tour est joué.

A noter que la syntaxe semble différer selon les distributions, pour la vôtre ça sera peut-être -LS 4 d avec des espaces entre les arguments pour obtenir le résultat (erreur de syntaxe sous Debian).

Un extrait de la man page de snmpcmd sur les options de journalisation

The  mechanism  and destination to use for logging of warning and error messages can be controlled by passing  various  parameters  to  the  -L flag.

-Le    Log messages to the standard error stream.

-Lf FILE
Log messages to the specified file.

-Lo    Log messages to the standard output stream.

-Ls FACILITY
Log  messages  via syslog, using the specified facility (‘d’ for LOG_DAEMON, ‘u’ for LOG_USER, or ’0′-’7′ for LOG_LOCAL0  through LOG_LOCAL7).

There  are  also  « upper case » versions of each of these options, which allow the corresponding logging mechanism to be restricted  to  certain priorities of message.  Using standard error logging as an example:

-LE pri
will log messages of priority ‘pri’ and above to standard error.

-LE p1-p2
will log messages with priority between ‘p1′  and  ‘p2′  (inclusive) to standard error.

For  -LF  and  -LS  the priority specification comes before the file or facility token.  The priorities recognised are:

0 or !  for LOG_EMERG,
1 or a for LOG_ALERT,
2 or c for LOG_CRIT,
3 or e for LOG_ERR,
4 or w for LOG_WARNING,
5 or n for LOG_NOTICE,
6 or i for LOG_INFO, and
7 or d for LOG_DEBUG.

Normal output is (or will be!) logged at a priority level of LOG_NOTICE

rsnapshot est un logiciel de sauvegarde en Perl très malin basé sur rsync et les liens durs linux. Les liens durs permettent de conserver des historiques de sauvegarde avec un encombrement minimum. rsync de son coté permet de ne transférer que les fichiers modifiés, avec la possibilité de transmettre les données cryptées dans un canal ssh, c’est du tout bon pour des sauvegardes à distance.

Petite remarque au passage, si vous envisagez d’utiliser rsnapshot au travers d’une connexion ADSL, il ne faut pas que l’adresse IP change durant la session, ça plante la connexion ssh. Avec certains fournisseurs d’accès qui changent l’adresse IP toutes les 15mn (pour obtenir la liste, faites le 9) c’est même pas la peine d’essayer.

L’installation sous Ubuntu est d’une simplicité Debianesque :

aptitude install rsnapshot

Il y a juste un petit module Perl qui n’est pas installé par le paquet, Lchown. Ce module permet à rsnapshot de gérer les droits sur les liens symboliques. S’il n’est pas installé, les liens symboliques sauvegardés peuvent avoir des droits erronés, et c’est embêtant lors d’une restauration. On constate la présence (et bien souvent l’absence) du module en mettant les logs en mode verbeux dans rsnapshot (verbose 5).

On l’installe à partir des archive CPAN (Comprehensive Perl Archive Network).

Si ce n’est pas fait installer les paquets de compilation essentiels :

aptitude install build-essential

Installer ensuite le module Lchown :

perl -MCPAN -e ‘install qw(Lchown)’

Si c’est la première fois que CPAN est utilisé, il faut le configurer. Je ne connais rien à la question donc j’ai gardé les options par défaut, à part le répertoire de cache que j’ai mis dans /var/cache/cpan et les miroirs où j’ai choisi la France plutôt que les iles Tonga, enfin vous voyez.

A la fin de la configuration, s’il n’y a pas de messages déplaisants, le module est installé. Vous pouvez passer à la configuration de rsnaphot en éditant /etc/rsnapshot.conf ou en créant un répertoire /etc/rsnapshot si vous avez plusieurs sauvegardes à gérer.

Plus ça va plus je trouve que subversion (svn) est un outil génial, et pas seulement pour les développeurs. Une fois qu’on connait l’adresse du dépot svn d’une application, ça devient très facile de l’installer, sous ses différentes versions si besoin, et les mises à jour deviennent très simples.

Par exemple Typo3. Cet excellent CMS n’a qu’un petit défaut, les mises à jour sur un site existant sont parfois délicates, il faut prendre son temps. Du coup c’est intéressant d’avoir plusieurs plusieurs versions installées, les sites n’ayant pas encore été migrés utilisant leur version d’origine. Avec svn, c’est tout simple.

L’adresse du dépot svn pour typo3 est https://typo3.svn.sourceforge.net/svnroot/typo3. A partir de là CoreDocs/ donne accès à la documentation, et TYPO3core/ aux sources. Classiquement, on a ensuite trunk/ pour la dernière version de développement, branches/ pour les versions principales (4.0, 4.1, 4.2, etc…) et tags/ pour les différentes releases (4.0.1, 4.0.2, etc…). Pour un serveur de production le choix de tags/ est plus raisonnable, branches/ est plus pratique sur une machine de test pour faire des mises à jour avec svn update. Quant à trunk/, c’est pour les développeurs et les grands joueurs.

Edit du 3/5/2010 :
Le dépot svn typo3 est maintenant à l’adresse https://svn.typo3.org/

Créer le répertoire typo3 :

mkdir /usr/share/typo3
cd /usr/share/typo3

On télécharge les version 4.0.8 et 4.2.0 :

svn co https://typo3.svn.sourceforge.net/svnroot/typo3/TYPO3core/tags/TYPO3_4-0-8 4.0.8
svn co https://typo3.svn.sourceforge.net/svnroot/typo3/TYPO3core/tags/TYPO3_4-2-0 4.2.0

On crée des liens symboliques, latest pour la dernière et éventuellement des liens personnalisés pour les sites qui utilisent les anciennes versions :

ln -s 4.2.0 latest
ln -s 4.0.8 mesvieuxsites

S’ils ne sont pas encore là on installe les paquets nécessaires à typo3 et on recharge la config Apache :

aptitude install php5-gd imagemagick libttf-dev
/etc/init.d/apache2 reload

Pour un nouveau site, il faut télécharger le package dummy (que je n’ai pas trouvé sur svn), si comme moi c’est pour migrer un site sur une nouvelle machine il faut créer le fichier typo3conf/ENABLE_INSTALL_TOOL :

touch monsite/typo3conf/ENABLE_INSTALL_TOOL

A la racine du site, on crée le lien symbolique qui va pointer sur la version appropriée de typo3 :

ln -s /usr/share/typo3/latest typo3_src

ensuite se rendre sur http://monsite/typo3/install pour exécuter l’assistant d’installation et de mise à jour.

Il y a plusieurs méthodes pour redimensionner un disque virtuel VMware. On peut utiliser VMware Converter (la version de base est gratuite) mais à priori il ne fonctionne pas avec les images Vista et c’était justement celle que je voulais agrandir.

J’ai utilisé vmware-vdiskmanager, qui est un outil fourni avec VMware Server, et sans doute avec d’autres versions de VMware.

La première étape est de faire une copie de l’image, on n’est jamais trop prudent…

Ensuite, il faut supprimer les snapshots de l’image a partir de la console VMware, sinon vmware-vdiskmanager refuse de fonctionner. Attention, cette opération peut prendre un temps certain avec de grosses images et son interruption causera une corruption irrémédiable de l’image. Surveiller le processus snhelper dans une console bash, c’est lui qui fait le boulot, et vérifier qu’il n’y a plus de fichiers *.WRITELOCK dans le répertoire de l’image avant de passer à la suite.

Ouvrir une console bash dans le répertoire de l’image, et taper la commande :

vmware-vdiskmanager -x nnGB nom_de_l_image.vmdk

ou nn est la nouvelle taille de l’image en Go

par exemple :

vmware-vdiskmanager -x 16GB vista.vmdk

Lorsque c’est terminé, il ne reste plus qu’à ouvrir l’image à partir de la console VMware et à redimensionner la partition pour qu’elle occupe le nouvel espace. Là ça dépend de l’OS hébergé.

Pour Vista c’est Ordinateur / Gérer / Gestion des disques / Etendre le volume

Avec une image Linux on ira voir du coté de parted et ses dérivés, pour Windows XP il faudra utiliser un logiciel dédié comme Partition Magic ou faire quelques acrobaties avec System Rescue, comme expliqué ici (non testé).

Ce memo me sert pour configurer WebDAV avec cryptage SSL sur un serveur Apache. J’utilise WebDAV pour offrir un accès fichiers aux webmasters des sites que j’héberge, c’est plus souple et plus sûr que le FTP. Cette config est très basique, Webdav permet un paramétrage très fin des autorisations, notamment avec la directive <Limit …>

Une des contraintes de Webdav est que le serveur Apache doit avoir les droits en lecture-écriture sur tous les répertoires et fichiers partagés. Il faut donc veiller à ce que le user sous lequel s’exécute Apache (www-data dans mon cas) en reste propriétaire. C’est pourquoi les concepteurs de Webdav recommandent de ne pas utiliser d’autre protocole pour accéder à ces fichiers. C’est à mon humble avis un peu excessif, mais il faut y faire attention, un upload fait par SSH ou FTP n’aura probablement pas les bons droits.

Requis

• Apache 2
• Openssl
• Un compte sur cacert.org

Installer les modules Apache

> a2enmod ssl
> a2enmod dav
> a2enmod dav_fs
> a2enmod dav_lock
> a2enmod rewrite
> /etc/init.d/apache2 force-reload

Générer le certificat SSL

Dans le répertoire /etc/ssl/private :

> openssl req -nodes -new -keyout mondomaine.key -out mondomaine.csr

On peut passer toutes les questions sauf « Common Name (eg, YOUR name) », où il ne faut surtout pas mettre son nom mais le nom du domaine.

> cat mondomaine.csr

Copier la sortie dans le presse-papier
Sur le site cacert.org aller sur Certificat de domaine / Nouveau
Demander un certificat de classe 3
Coller le csr
Récupérer le certificat dans le presse-papier et le coller dans /etc/ssl/private/mondomaine.crt

finir par :

> chmod 600 mondomaine.*

Recopier le certificat racine CACert Classe 3 dans le magasin de certificats /etc/ssl/certs sous le nom cacert_class3.crt

Il est aussi possible d’utiliser un certificat autosigné, comme expliqué ici par exemple. L’avantage du certificat CACert est qu’il est issu d’une autorité certes non commerciale mais reconnue. Si le certificat racine de CACert n’est pas présent sur les postes clients on peut le télécharger ici

Configurer Apache

Attention, un seul serveur virtuel SSL par adresse IP!

Hors serveur virtuel, ajouter les directives :

NameVirtualHost *:80
NameVirtualHost *:443
DAVMinTimeout 600
DAVDepthInfinity On

Dès qu’on a mis en place le SSL, il faut que tous les serveurs virtuels soient assignés à un port, 80 pour http ou 443 pour https.

ex :

<VirtualHost *:80>
…
</VirtualHost>

Déclarer le serveur virtuel

On crée le fichier /etc/apache2/sites-availables/webdav :

<VirtualHost *:80>
ServerName mondomaine
# Force SSL
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
</VirtualHost>
<VirtualHost *:443>
ServerName mondomaine
ServerAdmin webmaster@mondomaine
SSLEngine On
SSLCACertificateFile /etc/ssl/certs/cacert_class3.crt
SSLCertificateFile /etc/ssl/private/mondomaine.crt
SSLCertificateKeyFile /etc/ssl/private/mondomaine.key
DocumentRoot /var/www
<Directory />
Options -Indexes FollowSymLinks
AllowOverride none
</Directory>
<Directory /var/www/site1>
Options Indexes
AllowOverride none
Order allow,deny
allow from all
DAV on
AuthName « Administration site Site 1″
AuthType Basic
AuthUserFile /etc/apache2/htpasswd-webdav
<Limit GET POST PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user utilisateur1
</Limit>
</Directory>
<Directory /var/www/site2>
Options Indexes
AllowOverride none
Order allow,deny
allow from all
DAV on
AuthName « Administration site Site 2″
AuthType Basic
AuthUserFile /etc/apache2/htpasswd-webdav
<Limit GET POST PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user utilisateur2
</Limit>
</Directory>
ErrorLog syslog
LogLevel warn
CustomLog /var/log/apache2/access_dav.log combined
</VirtualHost>

Créer la base utilisateurs

> htpasswd -c /etc/apache2/htpasswd-webdav utilisateur1
New password:
Re-type new password:
Adding password for user utilisateur1
> htpasswd /etc/apache2/htpasswd-webdav utilisateur2
New password:
Re-type new password:
Adding password for user utilisateur2

Donner les droits d’accès à Apache

> chown www-data /etc/apache2/htpasswd-webdav
> chmod 660 /etc/apache2/htpasswd-webdav

Configurer le firewall

Ouvrir le port TCP 443

Le moment de vérité!

on active le site :

> a2ensite webdav
> /etc/init.d/apache2 reload

S’il n’y a pas d’erreur il ne reste plus qu’a tester le partage avec un client Webdav : Dossiers Web sous Windows, le kio webdavs:// avec Konqueror (attention webdav:// ne fonctionne pas en SSL), le client intégré à Mac OS X, etc…

Liens

Le site officiel webdav

WP-Print 2.2 était incompatible mais Lester Chan à développé de nouvelles versions de ses plugins compatibles avec WP 2.5. La version WP-Print 2.3 beta 2 semble bien fonctionner, à vous de le dire. J’attends la version finale pour faire la traduction, ça reste donc en anglais pour le moment. Pour les admins WordPress qui font la mise à jour WP-Print, pensez à mettre aussi à jour les permaliens sinon ça marche pas.

A l’usage j’ai eu quelques soucis avec la nouvelle interface de téléchargement de médias, Ajaxisée et Flashifiée à mort. Quand j’essayais d’uploader un fichier, rien ne se passait. Il y a toute une page (en anglais) qui recense les problèmes avec cette nouvelle interface. Pour ma part j’ai du faire les manips suivantes :

• Modifier le fichier .htaccess à la racine du blog et rajouter les lignes :

</IfModule>
<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>
</IfModule>

• Mettre à jour le plugin Flash pour Firefox. Sous Ubuntu, c’est flashplugin-nonfree dans les dépots medibuntu.

AMHA, l’automatisation des mises à jour de sécurité Ubuntu (unattended upgrades) peut s’appliquer à 2 types de situations :

• Le serveur non critique, type LAMP ou serveur mail, sur lequel est installé un nombre limité de paquets ne présentant pas à priori d’incompatibilités, et qui ne nécessite pas une administration paranoïaque.
• Le poste de travail d’un utilisateur qui ne veut ou ne peut pas s’occuper des mises à jour.

Dans ces 2 cas il peut être intéressant que les mises à jour de sécurité s’appliquent automatiquement, sans pour autant automatiser le passage aux nouvelles versions, autrement plus risqué.

Voilà comment j’ai fait :

Installation du paquet unattended-upgrades

apt-get install unattended-upgrades

Editer /etc/apt/apt.conf.d/50unattended-upgrades

// Paquets à mettre à jour (origine, archive)
Unattended-Upgrade::Allowed-Origins {
"Ubuntu gutsy-security";
// Décommenter pour automatiser les changements de version, pour ceux qui savent ce qu'ils font
// "Ubuntu gutsy-updates";
};

// Liste des paquets ne devant pas être mis à jour (exemple)
Unattended-Upgrade::Package-Blacklist {
"nagios-nrpe-plugin";
"nagios-plugins";
"nagios-plugins-basic";
"nagios-plugins-standard";
"nagios2";
"nagios2-common";
"nagios2-doc";
};

Editer ou créer /etc/apt/apt.conf.d/10periodic et ajouter :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Dans les versions précédentes d’Ubuntu, on peut trouver ces paramètres regroupés avec les autres dans /etc/apt/apt.conf, la tendance actuelle semble être d’utiliser un fichier par fonctionnalité activée dans /etc/apt/apt.conf.d/, et pourquoi pas.
Et voilà c’est tout, la tâche cron quotidienne apt se chargera des mises à jour de sécurité. Les actions sont loggées dans /var/log/unattended-upgrades/

Créer un répertoire de blog temporaire

mkdir blognew

Dans ce répertoire extraire la dernière version stable de WordPress (attention au point à la fin de la commande svn)

$ cd blognew
$ svn co http://svn.automattic.com/wordpress/trunk .

Recopier à la main les éléments personnalisés (.htaccess, wp-config.php, wp-content/, etc…) du répertoire de blog actuel vers le nouveau

Sauvegarder la base de données

Renommer les répertoires :

mv blog blog.save
mv blognew blog

Lancer le script de mise à jour (il n’y avait pas de mise à jour de la base pour cette version) :

http://tavie.onsenfout.com/wp-admin/upgrade.php

La prochaine mise à jour (2.3.2 ?) pourra être effectuée avec la commande :

$ cd blog
$ svn update

Edit du 18/01/2007 : ça marche!