Bye Debian Squeeze

Bye, bye Debian Squeeze

Ok je sais c'est pas une nouvelle. Debian a annonce la fin du support Debian Squeeze. De bon et loyaux service.
https://www.debian.org/News/2016/20160212

Donc meme si j'aurais du le faire avant, il faut maintenant mettre a jour et passer a Debian Wheeze.7
Comme je prefere mettre a jour apres tout le monde pour eviter les problemes. La c'est le moment et le methode est bien rodee.

Evidement faire un backup avant.

Mettre a jour toutes les occurances de squeeze comme wheeze dans les fichiers suivants.


/etc/apt/sources.list et
/etc/apt/sources.list.d/*
aptitude update
Mettre a jour les keys


aptitude install debian-keyring debian-archive-keyring
Pour eviter l'erreur suivante :

There is no public key available for the following key IDs: 8B48AD6246925553
aptitude upgrade

Puis
 

aptitude dist-upgrade

Reboot et verifier le resultat.
Y a toujours des petites suprises surtout lies aux sources.list complementaires.
Enfin maintenant votre serveur est un Debian Wheeze, bravo !

Attention si comme moi votre infra est souvent base sur Promox, version 2 ou 3.
Debian 8, Jessy n'est pas forcement compatible avec Promox/OpenVZ (changement du reseau et systemd)

A tester avant de passer en prod.

Un MOTD comme un carnet de maintenance

Souvent c'est compliqué de partager l'information, de suivre les interventions sur les serveurs.
On note le suivi dans un outils (ITIL, etc ...) mais la relation entre les deux, l'information et le serveur est toujours un peu deconnectée. Quand on a une urgence on se connecte dans regarder la base d'information, ou bien tous les admin n'ont pas la même pratique, voir même parfois on rentre de vacances :)

Une solution que j'ai trouve est de créer un MOTD, message of the day personnel, qui apparaîtra seulement pour les admins et pas pour les autres intervenants sur le serveurs (dev, operateurs, ...)

L’idée c'est de laisser le genre d'information suivante :

• Les volumes Oracle ASM sont gérés par udev rules ou au contraire par asmlib
• Le serveur est vieux, ne toucher a rien
• lire le ticket xxx avant tout chose
• ....

J'ajoute dans /etc/profile le code suivant pour tester l'appartenance de l'utilisateur au groupe sysadmin. Si oui j'affiche le contenu de /etc/motd.splash_root.sh

####MOTD perso
if id -nG "$USER" | grep -qw "sysadmin"; then
. /etc/motd.splash_root.sh
fi
##############################

/etc/motd.splash_root.sh

echo ""
echo -e "\e[1;31m     ATTENTION                                                        \e[0m"
echo ""
echo -e "\e[1;31m ========================================="
echo -e "\e[1;37m                                                                                             "
echo -e "\e[1;37m        ASM par udev rules                                                     "
echo -e "\e[1;37m                                                                                             "
echo -e "\e[1;31m ========================================="
echo -e "\e[1;0m"

Qu'en pensez vous ? Comment faites-vous ?

Perdu le mot de passe root de Mysql et impossible de faire le jedi mind trick

Ca m'est encore arrive hier. Perdu le mot de passe root de mysql.
Tout internet dit, c'est simple faire le suivant :

service mysql stop
mysqld_safe --skip-grant-tables &

Et voila le tour est joue.

Oui sauf que non ca demarre et ca stoppe direct :

150823 23:07:43 mysqld_safe Logging to syslog.
150823 23:07:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150823 23:07:48 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

Remarquez que ca arrive toujours a un moment ou je suis sensé dormir.

Que faire ? C'est la panique !

Du calme la solution est simple.
Mysql essaye de charger des plugins qui vont crash, faut les désactiver.
Ajouter dans la section :

[mysqld]
performance_schema=off

Refaire le jedi trick :

mysqld_safe --skip-grant-tables &

Et hop le tour est joue.

NB: c'est pas moi qui avait mis le password de root, moi j'utilise Keepass.

Don't be evil : OpenDNS

A chaque fois c'est pareil, installation d'un nouveau serveur.
Je remplis automatiquement les DNS : 8.8.8.8 et 8.8.4.4 Google DNS.

C'est bien mais qu'est devenu le slogan de Google : Don't be evil ?

Ok je sais, je suis sur blogger, gmail, google sites, ...

Mais faut bien commencer par quelques choses, je commence donc par OpenDNS.
Comme je me souviens jamais des IP, je les copie ici :

• 208.67.222.222
• 208.67.220.220

https://www.opendns.com/

Ok c'est une goutte d'eau dans l'ocean mais les petits ruisseaux et les grandes rivieres, ...

Reminder OVH Promox OpenVZ CT Debian configuration reseau Venet

Parfois la configuration d'un CT sous Promox avec OVH est un plus complique que d'habitude.
C'est le cas lorsque le CT est configure comme VETH et non comme VENET comme c'est le cas le plus souvent.

Dans le manager OVH, générer un mac adresse et associer la a l'IP publique souhaitée.

Ensuite la configuration de l'OS, c'est un peu ésotérique :

Il s'agit de Debian 7

cat /etc/network/interfaces

# Auto generated lo interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address public.ip.container
netmask 255.255.255.255
broadcast public.ip.container
post-up route add ovh.proxmox.host dev eth0
post-up route add default gw ovh.proxmox.host
pre-down route del ovh.proxmox.host dev eth0
pre-down route del default gw ovh.proxmox.host
dns-nameservers 213.186.33.99 (whatever you want)

Ça m'a donne des sueurs froides.

Script pour client Openvpn

Mon petit script pour créer un nouveau client openvpn.

openvpn-client.sh
#!/bin/bash
set -xe
client=$1
cd /etc/openvpn/easy-rsa;
. /etc/openvpn/easy-rsa/vars
./build-key $client;
mkdir /etc/openvpn/clientconf/$client;
cp /etc/openvpn/clientconf/default/* /etc/openvpn/clientconf/$client;
cp /etc/openvpn/easy-rsa/keys/$client.* /etc/openvpn/clientconf/$client;
cp /etc/openvpn/clientconf/$client/client.conf /etc/openvpn/clientconf/$client/$client.conf;
sed -i "s/user/\$client/g" /etc/openvpn/clientconf/$client/$client.conf;
cp /etc/openvpn/clientconf/$client/$client.conf /etc/openvpn/clientconf/$client/$client.opvn;
cd /etc/openvpn/clientconf/;
zip $client.zip /etc/openvpn/clientconf/$client/*;



Execution:

./openvpn-client.sh client

Monitorer la suite Atlassian avec Newrelic

Newrelic et Atlassian sont deux super outils aujourd'hui, très devOps :)

Atlassian offre aux artisans du logiciel une gamme complète d'outils pour produire, tester, debug suivre leurs développements.
Newrelic permet de superviser son application, le serveur mais aussi son comportement en utilisant le mod-php ou l'api java.
Quoi de mieux que des superviser ses outils comme ses applications pour vérifier leurs performances.

Par exemple Jira :

Récupérer l'agent java chez Newrelic l'agent java et copier dans le répertoire home de Jira.
$ unzip newrelic-java-3.11.0.zip -d /opt/atlassian/jira/

Editer le fichier newrelic.yml pour nommer l’application et s'assurer que la clé est la bonne.

Copier newrelic-api.jar dans le repertoire lib de Jira
$ cp newrelic-api.jar ../lib/

Editer le fichier catalinas.sh pour inclure l'appel a Newrelic.
$ vim /opt/atlassian/jira/bin/catalina.sh

export JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/atlassian/jira/newrelic/newrelic.jar"

Redemarrer chaque application

$ /etc/init.d/jira restart

Le tour est joué vous pouvez maintenant connaitre les performances de vos outils Atlassian.

Il est possible également de coupler Newrelic et Jira pour générer des tickets directement en fonction des performances de vos applications.