Ta vie on s'en fout!

Le kit OPK est fourni par Microsoft aux intégrateurs pour qu’ils puissent personnaliser les dvd d’installation OEM de Vista. Pendant quelques mois ce kit a été librement téléchargeable sur le site Microsoft OEM Partner Center. Ce n’est plus le cas maintenant, il faut désormais être identifié.

Il ne faut PAS utiliser ntpdate sur un serveur Dovecot, qu’on se le dise. Dovecot déteste ça. Et quand on embête Dovecot, il s’arrête, tout simplement. Il part bouder au fond du disque dur.

En fait ce que Dovecot n’aime pas c’est qu’on recule l’horloge du serveur. C’est d’ailleurs bien expliqué sur le wiki de Dovecot. Alors pourquoi j’avais utilisé ntpdate au lieu du bon vieux ntp qui va bien? Ben j’en sais rien.

Testé sur Ubuntu 7.10 Gutsy le 14/11/2007
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/

Edit du 7 juin 2011

Depuis Gutsy les choses ont bien évolué et même si la méthode décrite ci-dessus reste adaptée à un serveur, c’est plus simple d’utiliser l’interface graphique pour les machines de bureau :

• Ouvrir le gestionnaire de mise à jour (Menu Système / Administration)
• Dans l’onglet Mises à jour, cocher la case Installer les mises à jour de sécurité sans confirmation
• Valider, et c’est fait.

GnuPG (ou GPG) est un logiciel de cryptographie complet qui implémente la norme OpenPGP. Les possibilités de GnuPG dépassent largement le cadre de ce billet, ceux qui veulent approfondir le sujet se réjouiront de la doc officielle.

GnuPG est préinstallé sous Debian et Ubuntu ainsi qu’avec la majorité des distributions Linux je crois. Le projet Gpg4win fournit un programme d’installation pour Windows qui inclus GnuPG et différents modules complémentaires. Les commandes de gpg sont les mêmes dans les différents environnements. GnuPG est avant tout un logiciel de cryptage asymétrique (clé publique – clé privée) et son domaine de prédilection est la transmission sécurisée d’information entre utilisateurs. Mais on peut aussi s’en servir pour faire du cryptage simple, c’est ce qu’on va voir ici.

Le problème à résoudre est le suivant :

Un utilisateur gère sur son poste de travail des informations confidentielles. L’accès au poste de travail étant protégé, on estime la sécurité suffisante sur le poste (ça pourrait se discuter mais c’est pas le sujet). Par contre les sauvegardes sont effectuées sur un serveur dont l’accès est public. On ne peut donc pas y sauvegarder les données confidentielles en l’état.

La solution va être de crypter les données avant de les sauvegarder, voilà comment :
Lire la suite »

Jusqu’à maintenant je faisais les mises à jour WordPress de la façon laborieuse, en recopiant les fichiers à la mimine. J’ai profité de la version 2.3.1 pour créer un « checkout » subversion qui devrait simplifier les futures mises à jour. J’ai suivi les instructions du Codex WordPress :

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