addgroup && usermod partiel

Support Debian
#1

Bonjour,
dans un script je fais la commande suivante:
addgroup sshgroup && usermod -a -G sshgroup zargos
le groupe est bien créé comme je peux le voir dans les logs:

Sep 10 15:44:08 in-target: Ajout du groupe « sshgroup » (GID 1001)...
Sep 10 17:44:08 groupadd[20901]: group added to /etc/group: name=sshgroup, GID=1001
Sep 10 17:44:08 groupadd[20901]: group added to /etc/gshadow: name=sshgroup
Sep 10 17:44:08 groupadd[20901]: new group: name=sshgroup, GID=1001

mais la modification du user pour le mettre dans le groupe ne marche pas. Est-ce parce que le usermod a lieux alors que le addgroup n’est pas terminé?

#2

Bonjour

C’est sans doute parce que tu n’as pas fermé et ré-ouverte la session ou le login shell du compte utilisateur zargos, ce qui fait que la modification concernant ce compte utilisateur n’a pas encore pu être prise en compte.

#3

Malheureusement non. C’est un script de post-installation dans un dvd d’install créé par simple-cdd (755 lignes sans les lignes vides et les lignes de commentaires).
La commande n’est pas lancée dans un shell utilisateur. d’ailleurs, la session utilisateur n’a jamais été ouverte au lancement du script.

#4

Comment est créé le compte utilisateur zargos ?

Est-ce que la commande ajoutant le compte utilisateur zargos dans la liste des comptes utilisateurs du groupe sshgroup est bien lancée après que le compte utilisateur zargos a été créé. ?

Si le compte utilisateur zargos et/ou le groupe sshgroup n’existe(nt) pas encore
la commande usermod -a -G sshgroup zargos retournera un code d’erreur N°6

#5

si tu regarde bien la commande, je créé le groupe avant.
le compte utilisateur lui est créé par le preseed, donc bien avant le lancement du script de postinstallation

#6

La commande usermod ne fonctionne pas dans ce contexte,
mais la commande sed fonctionnera :

 addgroup sshgroup && sed -i '/^sshgroup/s/:$/:zargos/' /etc/group
#7

Le compte utilisateur est effectivement créé (dans le système cible) à la fin de l’installation, donc à quel moment précis ton script est exécuté.

Comme tu t’en es rendu compte, l’action est différente (ajout de virgule) selon qu’il y a déjà un autre membre ou pas.

Question bête : apparemment tout ça est exécuté sur le système hôte via la commande in-target de l’installateur (qui fait grosso modo un chroot). Comment sont gérés les opérateurs du shell comme && dans ce contexte ?

#8

Oui, juste avant que tu ne rédige ton message.

Je n’ai pas pu voir toutes les lignes du script
mais je suppose que si Zargos avait utilisé cette syntaxe, c’est que son script était interprété par bash

#9

Mais quel bash ? Celui du système cible ou celui de l’installateur (qui est en fait l’interpréteur ash de busybox) ?

1 J'aime
#10

Comme je l’écrivais dans mon précédent message, n’ayant pu voir le script en entier, je ne peux pas savoir si c’est le shell bash ou ash ou un autre shell qui va interpréter cette ligne de commandes.

Il faudrait demander à Zargos puisque c’est lui qui avait utilisé dans son script post-installation la commande && entre un addgroup et un usermod :

C’est dans ce fil de discussion que j’ai appris que la commande usermod ne pouvait pas fonctionner dans un script postinst

#11

Si je comprends bien le fil en question, il ne s’agit pas d’un script exécuté par l’installateur Debian comme ici mais du script de post-installation d’un paquet. Et le problème n’est pas lié à la commande usermod mais à la commande newgrp qui lance un nouveau shell interactif avec le groupe spécifié, ce qui est une grosse connerie au milieu de l’installation d’un paquet. Accessoirement, la commande usermod évoquée est aberrante : jamais un script de paquet ne devrait utiliser une variable d’environnement de sudo ou toute autre variable d’environnement liée à l’utilisateur qui a lancé la commande. Où va-t-on si les paquets se comportent différemment selon l’utilisateur qui les installe ?

#12

bien après, quand tout le presed est terminé et que le grub est installé.

Comme c’est l’installation, il n’y a qu’un seul user configuré.

dans mono postinst, j’en ai à priori d’autres qui fonctionnent.
donc je pense que MucP a raison, usermod ne fonctionne pas dans ce contexte, donc il me suffit de modifier le fichier avec sed.

Celui du système cible, car j’utilise des fonctions ou des programmes qui ne sont pas dans l’installeur, comme ipcalc-ng.
le script postinst est en #!/bin/bash
je l’aurais bien mis, mais il fait près d’un millier de lignes.

je vais remplacer usermod par:

sed -Ei 's/^(sshgroup.*)/\1zargos/' /etc/group

me reste plus qu’à finir la refonte de script de construction d’ISO simple-cdd.

car j’utilise des bout de fichiers de conf (pour éviter d’avoir à modifier tous mes profils si le même bloc est modifié. chaque profil a un fichier de conf qui liste, pour chaque fichier simple-cdd ls blocs de fichiers de conf utilisés.
Un fois tous les fichiers construits (extra, udebs, preinst, preseed, postinst, downloads, packages) il lance la commande build-simple-cdd qui va bien, et ensuite il fait une synchronisation de l’iso et des fichiers de confs sur mon NAS pour sauvegarder la version de la config.

me reste plus que la gestion des arguments de lancements du script :slight_smile:

#13

Bien après quoi ? La création effective de l’utilisateur a lieu lors de la finalisation de l’installation, après l’installation de GRUB.

C’est quoi « mono postinst » ? Le script debian/postinst d’un paquet « mono » ?

Je pense qu’il se trompe et qu’il a mal lu le fil de discussion auquel il se réfère.

#14

le grub est installé avant le postinst et lors du postinst je peux constater que l’utilisateur zargos est bien existant.

mon postinst, desolé faute de frappe.

possible, en tout cas, le passage par sed fonctionne alors que usermod ne fonctionne pas. ce qui au final lui donne raison

#15

Peu importe puisque GRUB est installé avant l’étape « Terminer l’installation » au cours de laquelle l’utilisateur est créé. Ce n’est donc pas une référence pertinente.

Comment le constates-tu ?
Un indice indirect est le GID 1001 attribué au nouveau groupe « sshgroup » : cela signifie que 1000 est déjà attribué, en principe au groupe personnel du premier utilisateur créé si aucun groupe utilisateur n’a été créé auparavant.

Je viens de tester manuellement dans l’installateur avec in-target : usermod fonctionne très bien après que l’utilisateur et le groupe ont été créés.

in-target usermod -a -G sshgroup zargos

J’ai aussi testé que ta double commande avec && exécutée par bash lancé par in-target fonctionne comme prévu une fois que l’utilisateur a été créé.

in-target bash -c "addgroup sshgroup && usermod -a -G sshgroup zargos"
#16

je profite de aideinit pour verifier les fichier /etc/group et /etc/password, et le user et les groupes y sont bien

Quoique tu en pense quand dans le preseed il arrive à la fin de l’installation le postinst a été réalisé.

Ca fonctionne en effet. Ca ne marchait pas avant, j’ai avoir une modification ailleurs qui a impacté la commande.
dans le cadre du fichier de postinst, tu ne précise pas le in-target dans le script.
d’aileurs, il y a des commandes impossible à faire via le preseed et late_command alors qu’elles passent dans le postinst.

#17

Alors il n’y a aucune raison que usermod ne fonctionne pas.

Je ne dis pas le contraire, je dis seulement que l’installation de GRUB que tu as évoquée comme référence pour ton preseed n’est pas une référence valable pour la création de l’utilisateur et qu’on ne peut donc en tirer aucune conclusion.

Visiblement c’est tout le script qui est exécuté par in-target sinon la construction avec && ne fonctionnerait pas.

Ces actions sont effectuées dans le contexte de l’installateur ou du système cible ?

#18

je pense que c’est parce que le preseed est dans l’environnement installer, alors que le postinst est dans le contexte cible.