Mot-clé - Système

Fil des entrées - Fil des commentaires

lundi 27 mai 2024

Une seconde vie pour le vieux MacBook Air

Par xakan, lundi 27 mai 2024. Tech

Comme toute machine vieillissante, mon MacBook Air début 2015 est devenu inutilisable au fil du temps.

Le matériel fonctionne pourtant correctement et comme toujours j'ai du mal à me dire qu'il faut que je le jette. J'ai donc décidé d'essayer de lui donner une seconde vie avec une distribution Linux (Manjaro ici) et un environnement léger, i3wm.

Regardons comment faire.


On récupère l’image iso depuis le site voulu :

$ cd ~/Downloads
$ wget https://download.manjaro.org/i3/23.0.1/manjaro-i3-23.0.1-230921-linux65.iso

On liste les disques présents pour identifier la clé usb concernée, ainsi que son identifiant :

$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         494.4 GB   disk0s2
   3:        Apple_APFS_Recovery Container disk2         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +494.4 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            13.5 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 13.5 GB    disk3s1s1
   3:                APFS Volume Preboot                 12.3 GB    disk3s2
   4:                APFS Volume Recovery                1.9 GB     disk3s3
   5:                APFS Volume Data                    405.8 GB   disk3s5
   6:                APFS Volume VM                      4.3 GB     disk3s6

/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *8.0 GB     disk5

Une fois identifiée, on efface la clé usb. Dans mon cas, il s'agit de disk5.

$ diskutil secureErase 1 disk5
Started erase on disk5
Finished erase on disk5

L'option secureErase permet, comme son nom l'indique, d'effacer le disque en utilisant une méthode sécurisée avec un niveau qui peut être défini. Ici, 1 signifie qu'il y aura une passe unique d'écriture de données aléatoires.

On crée ensuite l'image au format .dmg qui ira sur la clé USB :

$ hdiutil convert ~/Downloads/manjaro-i3-23.0.1-230921-linux65.iso -format UDRW -o ~/Downloads/manjaro-i3
Lecture de Master Boot Record (MBR : 0)…
Lecture de MANJARO_I3_2301                  (Apple_ISO : 1)…
.....................................................................................................................................
Lecture de  (Type EF : 2)…
.....................................................................................................................................
Temps écoulé :  3.926s
Vitesse : 870.3 Mo/s
Compression : 0.0%
created: /Users/xakan/Downloads/manjaro-i3.dmg

Notez que l'extension de l'image de sortie n'est pas définie dans le nom du fichier à générer.

Dans notre cas, UDRW signifie qu'on veut une image UDIF avec la possibilité de lire/écrire. UDIF signifiant Apple Mac OS X Universal Disk Image Format.

On démonte ensuite la clé :

$ diskutil unmountDisk /dev/disk5
Unmount of all volumes on disk5 was successful

Enfin, on copie le .dmg sur la clé avec la commande dd.

$ sudo dd if=/Users/xakan/Downloads/manjaro-i3.dmg of=/dev/disk5 bs=1m
Password:
3416+1 records in
3416+1 records out
3582824448 bytes transferred in 970.109954 secs (3693215 bytes/sec)

Alors oui, l'écriture a été très longue, mais c'est pas le sujet, la clé est très vieille !

Maintenant, on redémarre en restant appuyé sur Alt et le tour est joué.

aucun commentaire aucun rétrolien

jeudi 25 avril 2024

Operation not permitted

Par xakan, jeudi 25 avril 2024. Tech

Il existe plusieurs façons d'envoyer des fichiers vers un conteneur sur un hyperviseur Proxmox. Mais toutes ne sont pas toujours sans embuches. Le cas que j'ai rencontré aujourd'hui m'a un peu fait me casser les dents. Pour pas grand chose, au final. Pour refaire rapidement le parcours, j'ai voulu déposer les fichiers statiques du site ZdX sur le conteneur qui le sert. J'ai donc envoyé mes fichiers sur mon user via scp, monté le système de fichiers du conteneur grâce à pct mount, puis j'ai fait un banal mv. Et c'est là que ça se corse.


J'ai donc commencé par envoyer mes fichiers de façon classique avec sftp, dans le home de mon utilisateur xakan. J'ai monté le système de fichier du conteneur avec pct mount <id du conteneur>, et simplement déplacé les fichiers avec mv <mondossier> /var/lib/lxc/<id>/rootfs/var/www/zdx. Un petit lxc-attach <id du conteneur> plus tard, me voici dans le dossier /var/www/ à vérifier les droits sur les fichiers avec ls -al :

drwxr-xr-x 11 nobody   nogroup  4096 Apr 24 19:20 zdx

Qu'à cela ne tienne, toujours depuis le conteneur, on met www-data:www-data comme propriétaires du dossier :

chown -R www-data: zdx
chown: changing ownership of 'zdx/terms/index.html': Operation not permitted

Ah. C'est même pas un accès refusé, c'est une opération non autorisée. lsattr m'indique que l'attribut i n'est pas présent, ce n'est donc pas le problème. En réalité, cela vient du fait que mon conteneur est un conteneur sans privilèges, sans correspondance entre l'utilisateur xakan et les utilisateurs du conteneur. Le dossier est donc assigné à nobody et nogroup.

La solution consiste donc à aller chercher le pid du processus init tel que vu par l'hôte. Il est bien entendu à 1 du côté du conteneur.

lxc-info -p 200
PID:            1204

Du côté de l'hôte, le processus init de mon conteneur est donc 1024. Je peux à partir de là aller chercher l'uid de l'utilisateur qui exécute ce processus, toujours tel que vu depuis l'hôte :

cat /proc/1204/uid_map
         0     100000      65536

De retour sur le conteneur après un nouvel lxc-attach 200, je vérifie l'id de l'utilisateur www-data qui doit posséder le dossier :

id -u www-data
33

D'un point de vue hôte, l'utilisateur qui doit être propriétaire du dossier zdx a donc pour id 100000 + 33 (id de l'utilisateur depuis le conteneur). Il n'y a donc plus qu'à définir les droits depuis l'hôte, en passant par le montage du système de fichier :

chown -R 100033:100033 /var/lib/lxc/200/rootfs/var/www/public

On démonte le système de fichier du conteneur :

pct unmount 200

Et on va sur le conteneur vérifier que les droits sont bons, toujours avec ls -al :

drwxr-xr-x 11 www-data www-data 4096 Apr 24 19:20 zdx

That's it!

aucun commentaire aucun rétrolien