Linux : monter une image disque ISO contenant plusieurs partitions

Dans le cadre de mon travail j’ai dû monter une image ISO contenant plusieurs partitions. Il s’agissait de l’image disque d’une VM s’étant fait pirater, sur laquelle je devais faire des investigations. Si on fait un bête mount, ça ne marche pas :

$ sudo mount image.iso /mnt/
mount: /mnt: mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/loop0, page de code ou programme auxiliaire manquant, ou autre erreur.

Il faut procéder autrement. D’abord j’utilise fdisk pour récupérer les informations de base sur l’image ISO.

$ sudo fdisk image.iso

J’utilise la commande p pour avoir les informations :

Commande (m pour l'aide) : p
Disque image.iso : 50 GiB, 53687091200 octets, 104857600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xe483a6f1

Périphérique Amorçage   Début       Fin  Secteurs Taille Id Type
image.iso1               2048   3905535   3903488   1,9G 82 partition d'échange Linux / Solaris
image.iso2   *        3905536 104857599 100952064  48,1G 83 Linux

Ici je vous qu’il y a deux partitions. La première c’est du swap, elle ne m’intéresse pas. La deuxième est la partition système, c’est celle là que je veux monter. J’ai besoin de récupérer trois informations : Taille de secteur, Début et Id. Dans mon cas, c’est respectivement 512, 3905536 et 83.

Id est un code indiquant le type formatage de la partition. Dans mon cas je sais ça correspond ext4, mais si on ne le sait pas, il suffit de faire la commande l pour lister les types existants :

Commande (m pour l'aide) : l

 0  Vide            24  NEC DOS         81  Minix / Linux a bf  Solaris        
 1  FAT12           27  TFS WinRE masqu 82  partition d'éch c1  DRDOS/sec (FAT-
 2  root XENIX      39  Plan 9          83  Linux           c4  DRDOS/sec (FAT-
 3  usr XENIX       3c  récupération Pa 84  OS/2 cachée ou  c6  DRDOS/sec (FAT-
 4  FAT16 <32M      40  Venix 80286     85  Linux étendue   c7  Syrinx         
 5  Étendue         41  PPC PReP Boot   86  NTFS volume set da  Données non-FS 
 6  FAT16           42  SFS             87  NTFS volume set db  CP/M / CTOS / .
 7  HPFS/NTFS/exFAT 4d  QNX4.x          88  Linux plaintext de  Dell Utility   
 8  AIX             4e  2e partie QNX4. 8e  LVM Linux       df  BootIt         
 9  Amorçable AIX   4f  3e partie QNX4. 93  Amoeba          e1  DOS access     
 a  Gestionnaire d' 50  OnTrack DM      94  Amoeba BBT      e3  DOS R/W        
 b  W95 FAT32       51  OnTrack DM6 Aux 9f  BSD/OS          e4  SpeedStor      
 c  W95 FAT32 (LBA) 52  CP/M            a0  IBM Thinkpad hi ea  Alignement Rufu
 e  W95 FAT16 (LBA) 53  OnTrack DM6 Aux a5  FreeBSD         eb  BeOS fs        
 f  Étendue W95 (LB 54  OnTrackDM6      a6  OpenBSD         ee  GPT            
10  OPUS            55  EZ-Drive        a7  NeXTSTEP        ef  EFI (FAT-12/16/
11  FAT12 masquée   56  Golden Bow      a8  UFS Darwin      f0  Linux/PA-RISC b
12  Compaq diagnost 5c  Priam Edisk     a9  NetBSD          f1  SpeedStor      
14  FAT16 masquée < 61  SpeedStor       ab  Amorçage Darwin f4  SpeedStor      
16  FAT16 masquée   63  GNU HURD ou Sys af  HFS / HFS+      f2  DOS secondaire 
17  HPFS/NTFS masqu 64  Novell Netware  b7  BSDI fs         fb  VMware VMFS    
18  AST SmartSleep  65  Novell Netware  b8  partition d'éch fc  VMware VMKCORE 
1b  W95 FAT32 masqu 70  DiskSecure Mult bb  Boot Wizard mas fd  RAID Linux auto
1c  W95 FAT32 masqu 75  PC/IX           bc  Acronis FAT32 L fe  LANstep        
1e  W95 FAT16 masqu 80  Minix ancienne  be  Amorçage Solari ff  BBT

Ensuite on peut quitter fdisk avec q :

Commande (m pour l'aide) : q

Maintenant il ne reste plus qu’à utiliser mount pour monter l’image ISO, mais en spécifiant l’offset de début de la partition qui nous intéresse. Ça se fait en multipliant les valeurs Taille de secteur et Début récupérées plus tôt. Dans notre cas : 3905536 × 512 = 1999634432

sudo mount -t ext4 -o loop,offset=1999634432 image.iso /mnt/

UEFI : impossible de changer l’ordre du boot

Un de mes collègues a rencontré un problème sur son ordinateur Hewlett-Packard. Après une installation fraîche de Debian, il ne pouvait pas modifier l’ordre du boot dans l’UEFI. Résultat, l’ordinateur cherchait systématiquement à démarrer sur la clé USB d’installation, même quand elle n’est pas présente. Il était obligé de modifier l’ordre du boot dans l’UEFI à la main à chaque démarrage.

La solution ne se trouvait pas dans l’UEFI mais dans Debian. Il est possible d’y forcer l’ordre du boot de l’UEFI. D’abord on liste les boots possibles :

$ efibootmgr
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0007,0004,0005,0003,0000
Boot0000* Intel Corporation: Realtek PXE B01 D00
Boot0003* SK hynix BC501 HFM256GDJTNG-8310A-NN95N694013905P6U
Boot0004* Pen Drive CE775CCD63720020
Boot0005* Pen Drive CE775CCD63720020
Boot0007* debian

Celui qui nous intéresse ici est Boot0007. Pour l’activer :

efibootmgr --bootorder 0007

C’est ironique de voir qu’on est obligé de passer par le système d’exploitation pour paramétrer l’UEFI, alors que la raison principale de sa création est d’empêcher que le système d’exploitation ne puisse modifier le démarrage de l’ordinateur.

Apache : SSLProtocol ignoré

J’ai rencontré un problème récemment. J’avais beau modifier la variable SSLProtocol dans n’importe quel fichier de /etc/apache2/sites-enabled/, ce n’étais jamais pris en compte.

En fait, en bas de la configuration de chaque vhost, Let’s Encrypt avait rajouté la ligne suivante :

Include /etc/letsencrypt/options-ssl-apache.conf

Il fallait donc modifier le SSLProtocol directement dans ce fichier.

Python : jouons avec coding

En lisant l’article Un header d’encoding plus simple pour Python et ses commentaires, j’ai voulu voir jusqu’où on pouvait aller dans la déclaration coding en Python 3.

Je commence par créer le script suivant :

#!/usr/bin/python3
# coding: Latin-1
print('é')

Comme Python 3 est par défaut en UTF-8, je créé suis obligé d’utiliser un autre coding pour voir si c’est pris en compte. Je créé donc le script en UTF-8 mais je déclare un coding en Latin-1. De cette manière, si le coding fonctionne ça affichera é, sinon ça affichera é.

J’aurais pu créer un fichier source en Latin-1, mais si le coding ne fonctionne pas ça me retourne une erreur :

SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xe9 in position 0: unexpected end of data

Je trouve ça beaucoup moins propre.

J’ai aussi choisi de ne pas utiliser le shebang préconisé (#!/usr/bin/env python3). Ça sera utile plus tard.

Je lance donc le script, et le résultat correspond à mes attentes :

$ ./coding.py
é

Le coding est bien pris en compte.

 

Maintenant je vais tester quelques exemples dans les commentaire de l’article. Je commence par celui de Biganon :

#!/usr/bin/python3
# Bonjour, je voudrais utiliser cet encoding: Latin-1 ; et sinon, la famille ça va ?
print('é')
$ ./coding.py
é

Parfait, ça marche.

 

Ensuite je passe à haypo :

#!/usr/bin/python3
# cocoricoding: Latin-1, l’encoding bien français
print('é')
$ ./coding.py
é

Ça marche aussi. On peut donc bien mettre des caractères non-ASCII sur la ligne qui déclare l’encodage.

 

D’après mgautierfr et Sam, la regex permettant de détecter le coding est coding[:=]\s*([-\w.]+). Elle est testée uniquement sur les deux premières lignes du fichier. Voyons ce qu’il est possible de faire avec ça.

 

#!/usr/bin/python3
import os # coding: Latin-1
print('é')
./coding.py
é

Le coding n’est pas pris en compte s’il y a une instruction avant sur la ligne. Dommage, j’aurais bien aimé pouvoir changer l’encodage au milieu d’un script.

 

#!/usr/bin/python3
print('coding:Latin-1')
print('é')
$ ./coding.py
coding:Latin-1
é

Si le coding fait partie de l’instruction, ça ne marche pas non plus.

 

#!/usr/bin/python3
""" coding: Latin-1 """
print('é')
$ ./coding.py
é

Si le coding est entre triple quotes, ça ne fonctionne pas non plus. Si j’ai bien compris la doc (c’est pas garanti), les triples quotes sont considérées comme des instructions par Python. Il est donc normal que ça ne fonctionne pas.

 

#!/usr/bin/python3
# coding: Latin-1 # coding: UTF-8
print('é')
$ ./coding.py
é

S’il y a plusieurs coding, c’est le premier qui est pris en compte.

 

#!/usr/bin/python3 # coding: Latin-1
print('é')
$ ./coding.py
/usr/bin/python3: can't open file '# coding: Latin-1': [Errno 2] No such file or directory

On ne peut pas mettre le coding sur la même ligne que le shebang. Mais ça a l’air d’être une limitation de Bash. Si je garde le même script mais que je le lance directement avec python3 :

$ python3 ./coding.py
é

Là ça marche.

Edit : d’après un article de Xavier Claude, le shebang est géré directement par le noyau, et pas par Bash.

 

Puisque le shebang est géré par Bash et le coding par Python, il est possible de faire des choses sympa. Je commence par créer un lien symbolique /usr/bin/coding:Latin-1 qui pointe vers /usr/bin/python3 :

sudo ln -s /usr/bin/python3 /usr/bin/coding:Latin-1

Ensuite je créé le script suivant :

#!/usr/bin/coding:Latin-1
print('é')
$ ./coding.py
é

Et voilà, en une seule ligne tout le monde est content ! Bash a pu lancer Python via le lien symbolique coding:Latin-1, et Python a trouvé son coding sur la première ligne du script.

 

#!/usr/bin/coding:Latin-1
# coding: UTF-8
print('é')
$ ./coding.py
é

S’il y a deux lignes coding, c’est la première qui est prise en compte.

Docker : can’t create socket (must run as root?) : Permission denied

Dans le cadre de la dockerisation de proxy Zabbix, je suis tombé sur un problème étrange.

Je fais les commandes suivantes :

docker run -it zabbix/zabbix-proxy-sqlite3:ubuntu-3.4-latest /bin/bash
[...]
root@220fab01aae4:/var/lib/zabbix# fping palc.fr
palc.fr is alive
root@220fab01aae4:/var/lib/zabbix# su - zabbix -s /bin/bash
zabbix@220fab01aae4:~$ fping palc.fr
(null): can't create socket (must run as root?) : Permission denied

Note : l’option -it /bin/bash me permets d’avoir directement un bash pour faire mes tests. Lors d’un lancement de Docker en prod, il faudrait utiliser les options -d -t à la place.

Note 2 : vous pouvez également avoir une erreur du type socket: Operation not permitted.

Dans le container Docker, la commande fping fonctionne en root mais pas avec l’utilisateur Zabbix. Pourtant sur le système host, qui utilise le même OS, ça fonctionne bien.

Pour corriger le problème il faut simplement ajouter l’option --sysctl net.ipv4.ping_group_range="0 65535" à la commande lançant le container docker. Ça permets à n’importe quel utilisateur d’accéder directement au réseau de l’hôte, ce qui est indispensable pour effectuer des requêtes ICMP, comme le ping. Dans le cas contraire, seul l’utilisateur root serait autorisé à le faire.

TeamViewer : Pas prêt. Veuillez vérifier votre connexion.

J’’ai récemment dû utiliser TeamViewer dans le cadre de mon travail. Mais il restait bloqué indéfiniment sur l’erreur « Pas prêt. Veuillez vérifier votre connexion. » :

Impossible d’entrer un ID de connexion, ou quoi que ce soit.

La cause de ce problème est simple. Au démarrage TeamViewer fait un test de connexion sur un DNS du type masterX.teamviewer.com (X étant un nombre). Mais comme les DNS sont configurés avec les pieds, si vous êtres en IPv6 il se peut que la résolution se fasse n’importe comment et échoue. La seule solution est de désactiver IPv6 sur votre ordinateur.

Sur un Ubuntu ça se fait de la manière suivante :

  • Éditez le fichier /etc/sysctl.d/99-sysctl.conf
  • Rajoutez les trois lignes suivantes à la fin :
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
  • Rechargez la configuration avec sudo sysctl -p
  • Relancez TeamViewer

Notez que ça désactivera complètement IPv6 pour le système d’exploitation entier.

Zabbix : invalid field name « items.jmx_endpoint »

Si vous rencontrez l’erreur suivante dans les logs d’un proxy Zabbix :

failed to update local proxy configuration copy: invalid field name "items.jmx_endpoint"

Ca veut dire que le master est en version 3.4 et que le proxy est en version 3.0. Ces deux versions ne peuvent pas travailler ensemble. Il faut donc mettre à jour le proxy en version 3.4.

Mais cette erreur à une conséquence inattendue. En apparence le proxy fonctionne normalement. Il continue à collecter des données et à les envoyer au master. Par contre il ne peut plus mettre à jour sa configuration (ajout ou modification de métriques). Celle-ci reste figée. Mais si vous relancez le service zabbix_proxy, c’est la cata et même la collecte ne fonctionne plus.

SELinux : détecter et corriger les problèmes de droits

Le problème

Dans le cadre de la supervision MySQL, l’agent Zabbix est censé exécuter cette commande en local pour s’assurer que le serveur accepte bien les connexion :

mysqladmin -h 127.0.0.1 ping

Si je lance la commande en local :

zabbix@1.2.3.4:~$ mysqladmin -h 127.0.0.1 ping
mysqld is alive

Mais quand c’est l’agent Zabbix lui-même qui lance la commande :

mysqladmin: connect to server at '127.0.0.1' failed
error: 'Can't connect to MySQL server on '127.0.0.1' (110)'
Check that mysqld is running on 127.0.0.1 and that the port is 3306.
You can check this by doing 'telnet 127.0.0.1 3306'

Pourtant les deux tests-ci-dessus ont un fonctionnement identique. C’est la même commande qui est utilisée dans les deux cas, avec les même droits. Après une heure à faire des tests et à s’arracher les cheveux pour comprendre d’où peut venir le problème, j’ai pensé à SELinux. Pour voir si SELinux est activé :

root@1.2.3.4:~# getenforce
Enforcing

Là c’est activé, sinon ça m’afficherait Permissive ou Disabled.

Je désactive temporairement SELinux pour faire des tests avec setenforce 0. Comme la supervision Zabbix se mets à fonctionner, je sais que le problème vient de là. Je réactive SELinux avec setenforce 1.

La solution

Pour désactiver définitivement SELinux il faut faire echo "0" > /selinux/enforce. Mais comme je suis sur une plateforme demandant un niveau de sécurité élevé, je ne peux pas le désactive. Il va donc falloir autoriser l’agent Zabbix à utiliser MySQL.

On installe d’abord un utilitaire qui va bien nous aider :

apt-get install policycoreutils

Ensuite on surveille le fichier audit.log :

tail -f -n 0 /var/log/audit/audit.log | audit2allow

À chaque fois que l’agent Zabbix tente de se connecter au MySQL, ca affiche quelque chose qui ressemble à ça :

#============= zabbix_agent_t ==============
allow zabbix_agent_t mysqld_etc_t:file { open read };
#!!!! The file '/var/lib/mysql/mysql.sock' is mislabeled on your system.
#!!!! Fix with $ restorecon -R -v /var/lib/mysql/mysql.sock
#!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode'
allow zabbix_agent_t mysqld_t:unix_stream_socket connectto;

On peut voir la cause du problème. L’agent Zabbix ne peut pas accéder à /var/lib/mysql/mysql.sock. Ça nous donne même l’option à activer : daemons_enable_cluster_mode.

Je lance donc les commandes suivantes :

setsebool -P daemons_enable_cluster_mode 1setsebool daemons_enable_cluster_mode 1

Il ne reste plus qu’à redémarrer l’agent Zabbix (systemctl restart zabbix-agent.service), et le problème est résolu.