Catégorie : Linux

Articles concernant Linux (principalement Red Hat et Ubuntu)

RHEL – Désactiver ctrl-alt-del

Linux, c’est bien beau, mais ça ne capte pas les « ctrl-alt-del » (ou suppr, pour nous autres francophones). Du coup, la commande système correspondante est exécutée, à savoir, reboot immédiat.

Pour parer à tout risque de reboot intempestif d’une machine linux de production quand on est sur une session Windows et qu’on a la main sur une machine linux, qui, elle, interprétera différemment le fait qu’on veuille juste changer de mot de passe ou verrouiller son poste… il peut être intéressant de modifier la commande ctrl-alt-del afin qu’elle ne reboote pas directement le serveur (ou de créer un script qui demande confirmation avant reboot).

Les fichier à modifier sont les suivants :

  • RHEL 5 (et prédécesseurs) :
vi /etc/inittab

La ligne à rechercher est la suivante :

# Trap CTRL-ALT-DELETE

ca::ctrlaltdel:/sbin/shutdown -t3 -r now
  • RHEL 6 et suivants :
vi /etc/init/control-alt-delete.conf

Chercher la ligne :

# start on control-alt-delete

exec /sbin/shutdown -r nowControl-Alt-Delete pressed

Deux solutions s’offrent à vous, soit commenter purement et simplement la ligne avec un # au début (et on n’aura alors plus de problème puisque ctrl-alt-del ne fera rien), soit créer un script maison, qui demande à l’utilisateur s’il est vraiment sûr de vouloir rebooter la machine (après tout, le ctrl-alt-del peut être une option intéressante pour faire un reboot propre sur une machine dont on a oublié le mot de passe… pour par exemple pouvoir reseter le mot de passe root au chargement du GRUB).

Sauvons nos serveurs de production !

Happy swappiness !

Un paramètre que l’on oublie souvent de préciser, lorsqu’on installe un OS linux, est le swappiness.

Mais qu’est-ce donc ?

Il s’agit du seuil de mémoire vive libre à partir duquel les pages vont être déchargées sur disque, dans le swap. Autrement dit, il s’agit du seuil minimal de RAM à maintenir disponible avant de swapper.

Or, par défaut, par exemple sur Red Hat, ce paramètre est mal configuré : il est à 60%. Cela signifie donc que l’OS commencera à swapper dès qu’on dépassera 40% d’utilisation de la RAM. Eh oui, 60% de libre minimum, ça implique 40% d’occupé maximum.

Le seuil idéal pour ce paramètre, pour des performances correctes et sans swapper, est quelque part entre 10% et 20%, en fonction des applications et de leur utilisation. Mais ça change tout par rapport à 60%…

Pour modifier ce paramètre,

vi /etc/sysctl.conf

Rechercher et modifier la ligne :

vm.swappiness = 10

Pour que cette modification soit prise en compte immédiatement :

sysctl -p

Sinon ce sera pris au prochain reboot.

Et pour vérifier quelle est la valeur actuelle du swappiness…

cat /proc/sys/vm/swappiness

 

Happy swappiness !

RHEL7 – elle est où mon eth0 ?

Sur RHEL7 (et CentOS 7), le nom de l’interface réseau n’est plus l’habituel etho0, mais il est généré lors de l’installation (et ressemble à quelque chose comme eno0). Pour retrouver les classiques eth0, eth1, etc., voici comment faire :

1) renommer le script de configuration de l’interface :

mv /etc/sysconfig/netwwork-script/ifcfg-eno0 /etc/sysconfig/network-script/ifcfg-eth0

2) modifier ledit script :

vi /etc/sysconfig/network-script/ifcfg-eth0

Rajouter en premier la ligne suivante :

DEVICE="eth0"

et compléter le reste avec les informations habituelles.

3) ouvrir le fichier /etc/default/grub, et ajouter à la ligne « GRUB_CMDLINE_LINUX » les options suivantes :

net.ifnames=0 biosdevname=0

4) recharger la configuration grub :

grub2-mkconfig -o /boot/grub2/grub.cfg

5) puis redémarrer la machine :

shutdown -r now

Et c’est réglé !

Installation de paquets via yum (abonnement RHN)

Dernièrement, j’ai eu besoin d’installer des paquets avec un paquet (hoho) de dépendances, sur une RHEL 6. Plutôt que d’aller chercher les RPMs un par un, on a très vite envie de configurer yum pour faire le boulot à notre place. Voici comment faire :

1) Configuration du proxy (le cas échéant)

subscription-manager config --server.proxy_hostname=ip_du_proxy --server.proxy_port=port_du_proxy --server.proxy_user=user_ayant les droits --server.proxy_password=azert123

2) Enregistrement auprès du serveur de mises à jour

subscription-manager register --username compte_rhn --password ******

3) Attachement du serveur à une ligne de mise à jour (là, on peut mettre auto pour laisser faire le boulot tout seul)

subscription-manager attach --auto

4) Recherche du paquet

yum search mon_paquet

5) Installation du package

yum install le_vrai_nom_de_mon_paquet

 

…et voilà, plus de dépendances à gérer, merci m’sieur !

vi, putty, et le pavé numérique

Non, ce n’est pas le titre d’un roman d’aventure. C’est juste qu’à chaque fois je m’embête à ne pas pouvoir utiliser le pavé numérique sous vi quand je suis connecté en ssh via putty. Et c’est dommage, puisqu’il existe une solution toute simple.

Aller dans la configuration de putty, Terminal>Features, et cocher la case « Disable application keypad mode » (la 2ème à partir du haut). Puis, Terminal>Keyboard, et dans la section « The Function keys and keypad », cocher l’option « Linux ».

Parallèlement, vous pouvez en profiter pour changer la section « The backspace key », et modifier le « Control-? (127) » en « Control-H ». Si vous avez des systèmes Unix, c’est même mieux 🙂

Dans « Window », vous pouvez aussi personnaliser les paramètres de fenêtre : spécifier une taille par défaut différente, ou modifier le nombre de lignes de scrollback (historique).

Pour enregistre ces paramètres comme étant ceux par défaut, il faut retourner sur « Session », et les enregistrer dans « Default Settings » (en cliquant sur save).

Analyse des logs

Quand le reboot n’a rien résolu, il est toujours temps d’analyser les logs…

Mais, au fait, on fait comment ?

Le principe de base, c’est de chercher l’erreur, dans les logs. Trouver les logs de l’application, chercher le terme « error » (en général, ça marche plutôt bien), et lire le message d’erreur (in English, of course).

De deux choses l’une. Soit le message est clair, style « connection to database failed », et vous avez une assez bonne idée de ce qui se passe.

Si vous avez moins de chance, et que vous avez par exemple une jolie stack d’erreur Java, le plus simple est… Google.

Quelque soit votre problème, il y a forcément quelqu’un qui a eu (ou aura), un jour, le même. Un copier/coller du message d’erreur (ou du code d’erreur) dans Google donne de manière générale de très bons résultats. Les sites du style stackoverflow et autres experts exchange sont des mines d’or. Enfin, de problèmes, et il s’y trouve certainement un topic traitant de votre problème.

Et si jamais ce n’est pas le cas, et que vous trouvez la solution…

Pensez à partager 😉

Apache ou httpd ? MySQL ou mysqld ?

Avec le temps, le nom des services (au moins sous Red Hat) a évolué. Ainsi, alors qu’on avait l’habitude de la commande « service mysql stop », il fallait, selon la machine que l’on administrait, mettre un d au bout… ou pas.

Un contournement que j’ai trouvé est de faire un lien symbolique (ln -s) dans le /etc/init.d, de mysql vers mysqld (ou l’inverse). De fait, même si on se trompe de nom de service, on arrive sur le bon script, et cela fonctionne quand même…

Sur le même principe, les services httpd (ou http (ou apache)) peuvent être liés, ce qui permet de ne pas se planter… et de gagner du temps 🙂