Voici un petit mémo sur les commandes et mécanismes qui sont déroutants sous Debian pour une “redhatienne” comme moi.

J’en profite pour indiquer que j’ai installé le plugin WP-Markdown afin de pouvoir directement écrire en Markdown dans les posts de WordPress, et ça marche plutôt bien ! Fini de se galérer à devoir écrire des balises “code” ! :p

Autojump

Pour que cela fonctionne, il faut ajouter dans bash_profile la ligne suivante :

. /usr/share/autojump/autojump.sh

Apt

Pour avoir des infos sur un package :

$ apt-cache show mate-desktop 

Pour faire des update, il faut d’abord updater la liste des packages :

# apt-get update 
 # apt-get install package

Complétion

Par défaut, le fichier known_host de ssh est hashé, donc bash-completion ne peut pas le lire pour compléter les noms d’hôtes.

Pour résoudre le souci, on créé un fichier config dans le dossier .ssh du home de l’utilisateur, avec comme contenu :

host nomdemachine
 user nomuser

Apache

Il ne s’appelle pas httpd. Et rien que ça, c’est super déroutant ! Pas apache non plus, non, ça serait trop simple… A nous deux apache2 !

Pour ajouter un fichier de configuration, il faut ajouter le fichier dans /etc/apache2/sites-available/, puis lancer la commande pour l’activer :

# a2ensite site

Ce qui a pour effet de faire un lien vers le fichier dans /etc/apache2/sites-enabled/.

Pour activer un plugin :

# a2enmod mod_proxy

Pour démarrer le service :

# service apache2 start|stop|graceful-stop|restart|reload|force[ ok ad|start-htcacheclean|stop-htcacheclean|status}

Pour faire pareil + configtest :

# apachectl start|stop|restart|graceful|graceful-stop|configtest|status|fullstatus|help

Installer Flash

Pour utiliser l’alternative non libre (voir ici pour les repos : https://wiki.debian.org/FlashPlayer):

# apt-get install flashplugin-nonfree

Ensuite, pour updater flash :

# update-flashplugin-nonfree --install

Comme il y a des problèmes de sécurité avec le Flash d’Adobe et que les mises à jour Debian tardent, je suis passée à gnash, pour GNU Flash movie player. Dans mon cas, il était déjà installé, restait à l’utiliser en utilisant update-alternatives :

# update-alternatives --display flash-mozilla.so
flash-mozilla.so - auto mode
  link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
/usr/lib/gnash/libgnashplugin.so - priority 10
Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'.

# update-alternatives --config flash-mozilla.so
There are 2 choices for the alternative flash-mozilla.so (providing /usr/lib/mozilla/plugins/flash-mozilla.so).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/flashplugin-nonfree/libflashplayer.so   50        auto mode
  1            /usr/lib/flashplugin-nonfree/libflashplayer.so   50        manual mode
  2            /usr/lib/gnash/libgnashplugin.so                 10        manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/gnash/libgnashplugin.so to provide /usr/lib/mozilla/plugins/flash-mozilla.so (flash-mozilla.so) in manual mode

Installer Spotify

Le client packagé sur un repo Debian demande des lib trop récentes. Il faut downgrader en installant une version plus ancienne : https://github.com/olejon/spotcommander/wiki/DowngradeSpotify (prendre par ex la Spotify 0.9.4 64-bit)

# dpk -i spotify-client_0.9.4.183.g644e24e.428-1_amd64.deb

Il faut également installer une version plus ancienne de Openssl : https://support.rstudio.com/hc/en-us/articles/202094776-Installing-OpenSSL-0-9-8-on-Debian-7-Wheezy

$ wget http://ftp.us.debian.org/debian/pool/main/o/openssl/libssl0.9.8_0.9.8o-4squeeze14_amd64.deb
$ sudo dpkg -i libssl0.9.8_0.9.8o-4squeeze14_amd64.deb

Services

Pour vérifier qu’un service sera lancé au démarrage :

#  ls /etc/rc3.d/S*

Si on veut en ajouter un (ici MySQL)

# update-rc.d mysql defaults

Après une upgrade d’Owncloud, il faut réactiver à la main les apps ; et depuis quelques temps, cela échoue avec le message d’erreur

Apps does not provide info.xml

Ce qui est faux et n’a rien à voir avec le fichier info.xml de l’application, mais à priori est lié à un problème de vérification ssl.
Pour ne plus avoir l’erreur, il faut ajouter dans data/lib/private/httphelper.php, à la ligne 73, la ligne en gras :

curl_setopt($curl, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);

Reférence : https://github.com/owncloud/core/issues/14840#issuecomment-78648121

J’utilise le plugin WP Video Posts sur un de mes blogs. Il sert à encoder directement des vidéos pour les inclure dans des posts, et il inclus aussi le player video.js qui marche plutôt bien. Mais il y avait un souci avec ce player : bizarrement, sur la page d’accueil de mon blog, seules les premières vidéos étaient bien gérées par le player. Les vidéos suivantes n’apparaissaient pas dans un lecteur, on voyait juste l’image de splash et on pouvait uniquement les lancer via le lecteur embarqué du navigateur (sans contrôles, donc, et puis bon, il fallait savoir que c’était des vidéos du coup !).

Le souci n’apparaissait pas non plus lorsqu’on affichait un post seul. Après investigation (merci mon coeur !), il s’agissait d’un souci de délai : la page d’accueil du blog est un peu lente à se charger, un peu à cause des photos embarquées du site de photo Piwigo. Résultat, le plugin trouvait les premières vidéos de la page, les intégrait dans le lecteur et zou, il ignorait gentiment tout le reste de la page et donc toutes les vidéos suivantes.

Pour corriger ça, il faut ajouter dans le ficher wp-video-posts/inc/video-js/video.js, vers la ligne 8558, le code suivant (en gras):

// Run Auto-load players
// You have to wait at least once in case this script is loaded after your video in the DOM (weird behavior only with minified version)
if (jQuery)
        jQuery(document).ready(vjs.autoSetup);
else 
        vjs.autoSetupTimeout(1);

Et hop ! Toutes les vidéos de ma page d’accueil sont maintenant correctement gérées.

Une petite commande bien pratique pour savoir quels process utilisent des I/O : iotop !
Avec l’option -o, il n’affiche que ceux utilisant effectivement des I/O.
Et l’option -a permet d’avoir un cumul depuis le lancement de la commande, ce qui évite que les process disparaissent et réapparaissent super rapidement s’ils font des I/O par intermittence. Un petit exemple :

# iotop -a -o
Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       7.75 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND          
 1436 be/3 root          0.00 B    160.00 K  0.00 %  0.46 % [jbd2/dm-9-8]
  152 be/3 root          0.00 B     44.00 K  0.00 %  0.29 % [jbd2/dm-0-8]
 2903 be/4 root          0.00 B      8.00 K  0.00 %  0.00 % nmbd -D
 2219 be/4 root          0.00 B      4.00 K  0.00 %  0.00 % rsyslogd ~ain Q:Reg]
 4376 be/4 aline         0.00 B      8.00 K  0.00 %  0.00 % psi-plus
18865 be/4 aline         0.00 B      4.00 K  0.00 %  0.00 % iceweasel~ache2 I/O]
18884 be/4 aline         0.00 B    504.00 K  0.00 %  0.00 % iceweasel~torage #1]
18890 be/4 aline         0.00 B    120.00 K  0.00 %  0.00 % iceweasel~OM Worker]
21295 be/4 aline         0.00 B      8.00 K  0.00 %  0.00 % iceweasel~ache2 I/O]

Par défaut, appuyer sur la touche q lance l’enregistrement de macros dans vi/vim. Je ne me sers jamais de cette fonctionnalité, mais il parait que c’est très utile : ça se lance en faisant q+lettre, ça s’arrête en faisant q, et enregistre tout ce qu’on fait entre. On peut rejouer ensuite tout ce qu’on a enregistré en faisant @ et la lettre tapée après le q.

Le souci, c’est que je la lance souvent par erreur, en voulant quitter un fichier (q au lieu de :q). Et une fois dedans, c’est parfois compliqué de quitter ce mode, une fois qu’on a commencé à taper ça part dans tous les sens !

Pour éviter ce souci, il existe une ligne magique à rajouter dans le .vimrc :

map q <Nop>

Testé et approuvé !

Pour avoir une idée de la conso mémoire d’un programme, sous Linux, j’utilise smem. Sa particularité, outre de présenter les résultats sous forme bien sympa si on utilise les bons arguments, est de proposer plusieurs indicateurs : la consommation mémoire standard, RSS ou resident set size, mais aussi une mesure tenant compte des zones mémoires partagées par plusieurs applications, et donc moins surestimée : la proportional set size (PSS). Une fois installé via yum ou apt, on peut le lancer directement sans argument, pour avoir la liste des process consommant de la mémoire pour l’utilisateur. Si on rajoute l’option -t, on a une ligne avec le total. L’option -k permet d’ajouter l’unité (Mb ou Gb).  On peut aussi lui demander la conso mémoire d’un process en particulier, avec -P (on met un crochet sur la 1ere lettre pour éviter de voir apparaitre la commande smem dans la liste :

$ smem -t -k -P [i]ceweasel
PID User     Command                         Swap      USS      PSS      RSS 
24263 aline    /usr/lib/iceweasel/plugin-c        0   102.4M   106.2M   116.9M 
21283 aline    iceweasel -P -no-remote            0   435.1M   439.2M   455.0M 
28465 aline    iceweasel -P -no-remote            0   812.6M   815.3M   831.3M 
-------------------------------------------------------------------------------
  154 1                                           0     1.3G     1.3G     1.4G 

J’aime bien cet affichage, car il est lisible et permet d’avoir d’un coup d’œil la somme de la mémoire consommée par tous les process liés à une application… et en unités compréhensibles, en plus ! Si on est fan de graphiques, smem permet aussi de représenter la consommation mémoire sous forme de pie chart, ou de barres. Par exemple, le consommation de tous les processus de l’utilisateur, par nom :

$ smem --pie=name

Donnera l’image suivante :

Un graphique en barre de la consommation mémoire sur les processus de Chrome donnera :

$ smem -P [c]hrome --bar=name

Et pour finir, un petit camenbert sur la consommation de Iceweasel :

$ smem -P [i]ceweasel --pie=name

Ce n’est pas super sexy, mais c’est tout de même très lisible, je trouve, et bien plus parlant qu’un tableau avec des unités en octets ! :p

Dans mon nouveau job, j’ai droit à un poste de travail avec deux écrans (mais sous Debian, j’en reparlerai peut-être). Au début je ne voyais pas bien l’intérêt, mais on s’habitue, surtout pour faire des tests d’interface web, c’est pas mal d’avoir un écran avec l’interface et un autre pour écrire ses tests. J’ai donc un écran 24″ et un 19″, sur lequel je lance mon interface. Après avoir viré Gnome 3 pour mettre MATE (je veux bien bosser sous Debian, mais faut pas pousser, quand même), j’ai été confrontée à un comportement que j’ai trouvé gênant : par défaut, un seul écran est considéré comme l’écran principal, donc c’est le seul qui reçoit des panels avec les menus, listes de fenêtre, etc. En cherchant, j’ai bien trouvé des tutoriels sur le net qui expliquaient qu’il fallait feinter, en créant un panel sur l’écran principal et en le faisant glisser sur l’autre écran… mais cela ne voulait pas fonctionner chez moi ! Dans ma config, je pouvais faire glisser des panels orientés à gauche et à droite, mais ceux orientés vers le bas n’étaient pas déplaçables d’un écran à l’autre… malgré mes tentatives enragées à la souris ! Je pense que ces tuto concernaient des versions plus anciennes de Mate. Après moultes bidouillages de dconf-editor, voici finalement la marche à suivre :
* créer un nouveau panel sur l’écran principal, orientation bottom
* lancer dconf-editor
* aller dans

 org > mate > panel > toplevels    

• trouver le panel en question : dans mon cas, j’avais bottom, top, et toplevel_0 (bizarrement le 2e panel bottom en plus s’appelait donc toplevel_0)
• éditer l’entrée toplevel_0 pour passer la valeur “monitor” à 0 à 1, et zou ! Pour avoir une idée ce que ça donne ensuite, un petit screenshot de mes deux écrans. Il y a une bande noire en bas du deuxième, forcement, vu qu’il est plus petit !

Comme c’est une question qu’on m’a posée lors d’un entretien (et dont je ne connaissais pas la réponse), j’ai cherché comment tuer un processus zombie.
Wikipédia nous apprend qu’on ne peut pas tuer un processus zombie, pour la bonne raison qu’il est déjà mort (logique). Le processus apparait encore dans la liste des processus, et à avoir un ID, même défunt, car il a “oublié” de signaler son décès.
Ce comportement, le plus souvent non voulu, n’est la plupart du temps pas gênant, car un processus zombie ne consomme normalement plus de ressources. Mais dans le cas contraire, en cas de bug par exemple, s’il faut absolument tuer un processus zombie, le seul moyen est de tuer le processus qui l’a généré, son père.

Voici un petit exemple de comment trouver un le père d’un zombie.

On lance la commande top pour afficher le nombre de zombies :

$ top
top - 17:30:36 up 1:37, 3 users, load average: 1,88, 1,80, 1,67
Tasks: 205 total, 1 running, 203 sleeping, 0 stopped, 1 zombie

Ici, on en trouve un. On va chercher dans la liste des processus ceux qui sont en statut “Z” comme zombie, avec un ps et un grep :

ps -aux | grep Z

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
aline 2480 0.0 0.0 0 0 ? Z oct.15 0:00 [owncloud]

Pour trouver le père, on lance ps avec l’option pour afficher l’arborescence (j = job format, f = full format), et on fait un grep -E (regexp) sur le terme PPID (pour avoir l’entête de la colonne) et l’ID du process ; on fait un grep -v (reverse) pour supprimer de la liste la commande grep qu’on vient de lancer :

$ ps axjf | grep -E "PPID|2480"| grep -v "grep"
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
2233 2480 1985 1985 ? -1 Z 1000 0:00 | \_ [owncloud]

Ensuite, plus qu’a tuer le père avec un petit kill -9, et le tour est joué !

Hier, nous avons été confrontés à une installation minimale de CentOS qui ne présentait pas le package ifconfig, bien pratique pour déterminer l’IP de sa machine… Comment faire dans ce cas ? Après une petite recherche sur le net, on a plusieurs choix, en plus d’installer le package manquant :

• si le package iproute est disponible, la commande suivante affiche les adresses IP de toutes les cartes réseaux trouvées, en plus de leur nom et caractéristiques :

$ ip addr show

• si le package hostname est disponible, on peut également taper la commande suivante :

$ hostname -I

Le résultat est moins lisible, car il affiche toutes les adresses IP sans informations sur la carte réseau concernée ; si on en a plusieurs, ou des VPN, c’est moins facile de s’y retrouver.

Je rajoute une nouvelle catégorie à mon blog : la catégorie IT ! Je vais l’utiliser pour noter toutes les astuces bien pratiques que je trouve sur le web ou dans le cadre de mon travail, ou pour parler de choses un peu techniques. Comme le public est plus restreint que mes posts habituels, je pense que je ne l’inclurai pas dans les newsletters ; si vous êtes intéressés, il faudra aller voir sur Twitter ou G+ de temps en temps !