Mise en place de Munin sur Debian 7 Wheezy

Cet article a pour but de présenter les différentes étapes nécessaires à la mise en place d’une version récente de Munin sur Debian 7 Wheezy, donc plus récente que la version 2.0.6-4 présente actuellement dans le dépot « stable » de Debian :

munin (2.0.6-4+deb7u2)
munin-common (2.0.6-4+deb7u2)
munin-doc (2.0.6-4+deb7u2)
munin-node (2.0.6-4+deb7u2)
munin-plugins-core (2.0.6-4+deb7u2)
munin-plugins-extra (2.0.6-4+deb7u2)

La version 2.0.6-4 présente comme principal défaut, en tout cas dans mon cas, de ne tout simplement pas fonctionner… Aucun plugin ne se charge dans cette version, donc pas de monitoring…
Continuer la lecture de Mise en place de Munin sur Debian 7 Wheezy

Migrer un serveur dédié OVH vers une machine virtuelle Hyper-V

Nous avons un serveur dédié chez OVH depuis quelques années, dont le rapport configuration/prix n’est plus très intéressant si on compare aux serveurs actuellement disponible chez OVH.
Un problème qu’on n’a pas vu arriver est la migration des données d’une machine physique dédiée, à laquelle on n’a accès que par SSH, sur une autre machine.
Pour pallier à ce problème, nous avons choisi de convertir la machine en question en machine virtuelle qui sera donc indépendante du matos.
Continuer la lecture de Migrer un serveur dédié OVH vers une machine virtuelle Hyper-V

Individualiser une VM Hyper-V tournant sous Debian

Pour dupliquer une VM Debian et ne pas risquer d’avoir de problème, voici la procédure que je suis :
– Exporter depuis la console Hyper-V la VM qu’on souhaite dupliquer, éteinte (on va travailler en fait sur la VM déjà présente et ne modifier la configuration que de celle là. La VM exportée/importée sera en fait la VM d’origine).
– modifier le nom de la VM qui est déjà présente dans Hyper-V
– réimporter la VM qu’on avait exporté, en choisissant de « copier » la VM (donc en générant un nouvel ID). La raison est qu’on ne peut pas choisir le nom de la VM lorsqu’on l’importe, et il y avait risque de « collision »…
– une fois importée, on peut relancer la VM qu’on vient d’importer, rien de plus à prévoir sur celle-ci.
– sur l’autre VM (qui est donc celle qu’on avait exporté au départ), on supprime l’interface réseau (pour réinitialiser l’adresse MAC simplement) et on ajoute une nouvelle interface réseau
– on lance ensuite cette VM, on se connecte en prenant les droits root
– on lance la commande suivante pour lister les fichiers de configuration contenant le nom de l’ordinateur :

find /etc -type f -name "*" -exec fgrep -l "<ancien nom d'hôte de la machine>" {} \;

– on modifie le nom des fichiers (en excluant les fichiers de configuration ssh)
– on réinitialise ensuite la configuration ssh pour regénérer les clés :

rm -v /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

– enfin arrêt de la machine
– configuration de la carte réseau pour la relier au commutateur virtuel
– éventuellement fixation de l’adresse MAC, bail DHCP fixe, enregistrement du nom de domaine sur le DNS…
– redémarrage et contrôle que tout va bien!

Installer java sur une machine linux sans GUI

Incroyable, il faut vraiment chercher comment récupérer cette mmmmerveille de java, pour mettre l’installateur sur une machine linux qui n’a pas d’interface graphique.

Oui il y a toujours la possibilité de télécharger localement sur son poste la version de java qu’on veut installer, puis la transférer via SFTP ou autre, mais bon, quand on a un serveur avec une bande passante de 500mbps, c’est un peu ennuyant de transférer le package via la liaison montante à 800kbps de son ADSL.

La solution? wget!

wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/7u55-b13/jdk-7u55-linux-x64.tar.gz

Et pour la version 1.6 de Java :

wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/6u45-b06/jdk-6u45-linux-x64.bin

C’est assez logique, et surtout ça marche.

Si besoin, n’hésitez pas à visiter la source, il peut avoir fait des évolutions pour suivre les nouvelles versions de Java… 😉

http://stackoverflow.com/questions/10268583/how-to-automate-download-and-installation-of-java-jdk-on-linux

Recherche automatique des mises à jour sous Debian 7

Le suivi des mises à jour Windows se fait assez simplement avec WSUS.
Pour les machines sous distribution Linux, c’est un poil plus compliqué, et il n’est pas aisé d’avoir une vue globale de l’état des machines.

La solution que j’ai mis en place est très sommaire, mais a le mérite d’être là : recherche quotidienne des mises à jour, et s’il y en a envoi d’un rapport par mail.

Pour ce faire, j’utilise le logiciel apticron sous Debian 7 Wheezy.
Il s’installe simplement via :

apt-get install apticron

La configuration se fait ensuite via le fichier /etc/apricron/apticron.conf

Les valeur importantes à modifier sont :

EMAIL=""
NOTIFY_NO_UPDATES="1" (ça permet de tester le système d'envoi de rapport sans attendre la présence effective de mise à jour)

C’est à peu près tout ce qui est absolument nécessaire.

Ensuite, pour l’envoi des mails, je n’ai pas réussi à faire fonctionner avec exim4 installé par défaut.
Je passe donc par ssmtp qui va servir de relais vers un autre relais SMTP classique centralisé.
On installe via « apt-get install ssmtp », ça désinstalle tout seul exim4.
La configuration derrière est simple :
fichier /etc/ssmtp/ssmtp.conf

Surtout la ligne suivante :

mailhub=

Eventuellement, si besoin :

rewriteDomain=

En dernier lieu, il convient d’adapter la tâche cron créée automatiquement à l’installation d’apticron, celle-ci n’étant pas idéale.

vi /etc/cron.d/apticron

changer les deux premières colonnes pour définir que la recherche se fait tous les jours à 0h00 :

0 0 * * * root if test -x /usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi