logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 16-06-2020 09:58:20

Lupa
Membre
Distrib. : Debian Stretch 4.9.110-3+deb9u6 / Buster
Noyau : 4.9.0-8-amd64 (Stretch) Buster : 5.4.0-0.bpo.2-amd
(G)UI : xfce
Inscription : 28-06-2017

Un script qui ne marche pas.

Bonjour à tous smile

Debian buster.

L'utilisateur principal ne doit pas être sudo. Mais il doit pouvoir faire les mises à jour.
Je ne veux pas qu'il soit sudo, pour ne pas prendre de risque.
Il a le mot de passe root, parce qu'il est propriétaire de la bécane. Il ne doit le saisir qu'à cette occasion, ou pour appeler Gparted, par exemple. Pour formater une clef USB.

Code du script : (même avec l'extension .sh, ça ne marche pas). Même avec su - ça ne marche pas.


#!/bin/bash
su
apt-get update && apt-get upgrade
reboot  # je ne peux pas savoir s'il y a eu ou non des mises jour. Donc, reboot.
exit
 



Le .desktop sur son bureau :


[Desktop Entry]
Version=1.0
Type=Application
Name=MISE A JOUR
Comment=
Exec=/home/principal/Progs/maj.sh
Icon=
Path=
Terminal=true
StartupNotify=false

 



L'OS demande bien le psw de root, mais ne va pas plus loin. Avec ou sans le "&&".

Autre solution : le faire entrer en root, et lui faire exécuter le script.
Mais, sous Buster, plus de .desktop sur son bureau : l'application bureau renvoie un message d'erreur en anglais.
On ne pourrait pas contourner ça ? Exécuter un .desktop sur le bureau de root ?

Dernière modification par Lupa (16-06-2020 09:59:04)

Hors ligne

#2 16-06-2020 10:04:01

Jean-Pierre Pinson
Adhérent(e)
Lieu : Orléans
Distrib. : Debian Sid 64bits Ordi.: Thinkpad T400
Noyau : de cerise
(G)UI : xfce
Inscription : 04-03-2017

Re : Un script qui ne marche pas.

Déjà pour passer en root c'est

su -


En oubliant pas l'espace entre su et le tiré


Debian sid
Bureau : xfce
Ordinateur : Thinkpad T400 libreboot

Hors ligne

#3 16-06-2020 10:04:33

Anonyme
Invité

Re : Un script qui ne marche pas.

Il serait je pense plus propre de faire ceci :

#!/bin/bash
apt-get update
apt-get upgrade
reboot  # je ne peux pas savoir s'il y a eu ou non des mises jour. Donc, reboot.
exit
 




[Desktop Entry]
Version=1.0
Type=Application
Name=MISE A JOUR
Comment=
Exec=su - -c /home/principal/Progs/maj.sh
Icon=
Path=
Terminal=true
StartupNotify=false
 



Pour savoir s'il y a des mises à jours tu peux utiliser la commande 'apt list --upgradable'.

Par contre je ne vois pas l'intérêt de reboot après chaque maj, on n'est pas sous Windows ou Mac big_smile. Le reboot n'est utile que si un Kernel est maj et généralement tu peux attendre le soir d'éteindre ton pc, t'as aucune obligation à le faire dans la minute.

#4 16-06-2020 10:53:39

Lupa
Membre
Distrib. : Debian Stretch 4.9.110-3+deb9u6 / Buster
Noyau : 4.9.0-8-amd64 (Stretch) Buster : 5.4.0-0.bpo.2-amd
(G)UI : xfce
Inscription : 28-06-2017

Re : Un script qui ne marche pas.

@Jean-Pierre : ça ne passe pas non plus avec su -
@Darkou : bon sang ! J'ai oublié le path complet !!
Je donne le retour.

Non. Ca ne passe pas avec su - -c etc...
Qu'est-ce que c'est , ce paramètre -c ?

Si : ça le fait.
Mais il faut refermer le terminal pour que ça s'exécute....

Dernière modification par Lupa (16-06-2020 11:00:51)

Hors ligne

#5 16-06-2020 11:11:16

anonyme-15
Invité

Re : Un script qui ne marche pas.

Lupa a écrit :

Bonjour à tous smile

Debian buster.

L'utilisateur principal ne doit pas être sudo. Mais il doit pouvoir faire les mises à jour.
Je ne veux pas qu'il soit sudo, pour ne pas prendre de risque.
Il a le mot de passe root, parce qu'il est propriétaire de la bécane. Il ne doit le saisir qu'à cette occasion, ou pour appeler Gparted, par exemple. Pour formater une clef USB.



S'il a le mot de passe root, il a tout, c'est donc bien plus dangereux que sudo (sudo a mauvaise réputation a cause d'Ubuntu, qui a transformé sudo en su ou quasiment, mais bien utilisé, sudo est efficace)

Il est plus sûr de mettre les commandes apt-get update et apt-get ugrade à disposition de l'utilisateur standard via le fichier sudoers. Quelque chose comme ceci.

Ouvrir sudoers via visudo

su -



visudo




Ajouter au fichier sudoers ceci, dans la rubrique adéquate :

#user privilege specification
NomUntilisateurcourant    ALL=(root) NOPASSWD: /usr/bin/apt-get



Valider par ctrl+o puis ctrl+x

Les commandes apt-get update et upgrade peuvent alors être déclenchées sans saisie de mot de passe par cet utilisateur là, et lui seulement.

Il est sans doute préférable de les protéger en demandant l'usage de sudo et l'entrée du mot de passe utilisateur, mais je ne me rappelle plus quelle est la modification à faire dans sudoers.

De même, le reboot est inutile Dans 99,99% des cas.

Dernière modification par anonyme-15 (16-06-2020 11:14:50)

#6 16-06-2020 12:12:06

Anonyme
Invité

Re : Un script qui ne marche pas.

Lupa a écrit :

Qu'est-ce que c'est , ce paramètre -c ?



Je t'invite à regarder la doc de su (ou de n'importe quelle commande) via man.

Exemple pour la doc de su :

man su



Et je rejoins Anonyme-15 sur l'utilisateur de su/sudo.

Si ton utilisateur doit seulement faire la maj de la bécane l'idéal serait de configurer correctement sudo pour que ton utilisateur ai uniquement le droit de faire `sudo apt-get`.

Mais ça n'empêchera pas l'utilisateur faire un `apt-get remove linux-base` ou tout autre commande destructive.

Je ne sais pas qu'elle est finalité de ton script mais pourquoi ne pas imaginer d'autres méthodes moins permissive ? (maj auto, maj manuelle par une personne compétente/de confiance/...)

#7 16-06-2020 12:41:42

Lupa
Membre
Distrib. : Debian Stretch 4.9.110-3+deb9u6 / Buster
Noyau : 4.9.0-8-amd64 (Stretch) Buster : 5.4.0-0.bpo.2-amd
(G)UI : xfce
Inscription : 28-06-2017

Re : Un script qui ne marche pas.

Je prends note.
Je suis forcé de lui donner le psw root : le propriétaire ne doit dépendre de personne. S'il n'a pas le mot de passe root, il est "à mes pieds". Je refuse ça...
Je leur montre toujours ce qu'est le fait de travailler en root. Après image CloneZilla, je leur fais faire une belle bêtise. Ils comprennent : c'est effrayant et c'est voulu. L'OS est flingué. Et là, le psw de root, ils ne le donnent à personne !

Mise à jour manuelle, alors ?
Automatique : oui, ça, je vois. Une tâche cron ordonnée par via WebMin, et c'est réglé. J'y ai pensé. Il faut lui dire que tel jour à telle heure, ça va se mettre à jour.

Les mettre dans le groupe sudo, aïe ! Il suffit de donner son mot de passe user, et l'on devient root. Selon moi (c'est un avis personnel) la commande sudo est potentiellement dangereuse. On est root dans le processus. Et s'ils appellent GParted avant que je leur montre comment s'en servir ?

Le problème du .desktop sur le bureau de root. On contourne ça comment ? Sous Stretch, c'était faisable. Pas sous Buster. Pourquoi, je ne sais pas. Quelqu'un connaît-il un moyen de contourner cette interdiction ?

@Anonyme-15 : je vais voir ça. Mais un apt-get --remove quoi que ce soit, aïe !

@tous : pourquoi faut-il fermer ce terminal pour qu'il s'exécute ?

Hors ligne

#8 16-06-2020 12:42:34

bendia
Chadministrateur
Distrib. : openSUSE Tumbleweed, Buster
Noyau : Linux 5.9.1-2-default + Linux 4.19.0-12-amd64
(G)UI : Gnome + Console et un peu Fluxbox
Inscription : 20-03-2012
Site Web

Re : Un script qui ne marche pas.

Salut smile

Anonyme a écrit :

Mais ça n'empêchera pas l'utilisateur faire un `apt-get remove linux-base` ou tout autre commande destructive.

Je crois que sudo peut être suffisamment finement configuré pour accepter des paramètres aux commandes, donc par exemple uniquement update/upgrade.


Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.

En ligne

#9 16-06-2020 12:46:15

Beta-Pictoris
Membre
Lieu : Angers
Distrib. : Buster
Inscription : 11-08-2015

Re : Un script qui ne marche pas.

Les mises à jour automatiques se font avec la paquet unattended-upgrades : https://wiki.debian.org/UnattendedUpgrades

Cela dit, si tu veux faire un script qui utilise apt/apt-get, tu dois ajouter l'option "-y" sinon, les mises à jours seront interactives.

Hors ligne

#10 16-06-2020 13:11:13

Anonyme
Invité

Re : Un script qui ne marche pas.

Lupa a écrit :


Automatique : oui, ça, je vois. Une tâche cron ordonnée par via WebMin, et c'est réglé. J'y ai pensé. Il faut lui dire que tel jour à telle heure, ça va se mettre à jour.



Ou un simple "crontab -e" pas besoin d'aller s'embêter avec des surcouches web inutiles.

Lupa a écrit :


Les mettre dans le groupe sudo, aïe ! Il suffit de donner son mot de passe user, et l'on devient root. Selon moi (c'est un avis personnel) la commande sudo est potentiellement dangereuse. On est root dans le processus. Et s'ils appellent GParted avant que je leur montre comment s'en servir ?



Comme dit plus haut tu peux tout à fait configurer le groupe sudo (ou même un seul user) pour que lors de la commande sudo il n'ait accès qu'à une liste bien précise de commandes.

Lupa a écrit :


Le problème du .desktop sur le bureau de root. On contourne ça comment ? Sous Stretch, c'était faisable. Pas sous Buster. Pourquoi, je ne sais pas. Quelqu'un connaît-il un moyen de contourner cette interdiction ?



Pourquoi le mettre sur le bureau de root ?

Le script étant utilisé par l'utilisateur, le script doit être sur le bureau de l'utilisateur.

bendia a écrit :

Salut smile

Je crois que sudo peut être suffisamment finement configuré pour accepter des paramètres aux commandes, donc par exemple uniquement update/upgrade.



Ha ! c'est cool ça (en vrai je n'utilise pas sudo assez finement pour en connaître les subtilités) mais si c'est possible c'est clairement la solution au problème de Lupa !

Beta-Pictoris a écrit :

Les mises à jour automatiques se font avec la paquet unattended-upgrades : https://wiki.debian.org/UnattendedUpgrades

Cela dit, si tu veux faire un script qui utilise apt/apt-get, tu dois ajouter l'option "-y" sinon, les mises à jours seront interactives.



+1 pour le -y

#11 16-06-2020 13:18:43

anonyme-15
Invité

Re : Un script qui ne marche pas.

@Bendia : je n'ai pas réussi à affiner, en tous cas,

#user privilege specification
NomUntilisateurcourant    ALL=(root) NOPASSWD: /usr/bin/apt-get update



même avec des ' ' ne marche pas.

@Lupa

En mettant PASSWD à la place de NOPASSWD

#user privilege specification
NomUntilisateurcourant    ALL=(root) PASSWD: /usr/bin/apt-get



la commande à rentrer devient

sudo apt-get update



avec demande du mot de passe utilisateur pour que ça marche, et pour les seules commandes apt-get....

Ca permet de se familiariser avec l'administration sans trop de crainte, après tout, taper apt-get autoremove ne se fait pas tout seul.

Sinon, je ne vois en effet qu'un script avec su -c ou une automatisation des MAJ si c'est les MAJ sont le seul enjeu avec le fait de "laisser les clefs".

Dernière modification par anonyme-15 (16-06-2020 13:20:29)

#12 16-06-2020 13:24:37

raleur
Membre
Inscription : 03-10-2014

Re : Un script qui ne marche pas.

Lupa a écrit :

Code du script : (même avec l'extension .sh, ça ne marche pas). Même avec su - ça ne marche pas.


Normal. Ton script exécute apt-get et reboot après le retour de su (qui attend sagement que tu le termines avec exit ou ctrl+d), pas dans le shell lancé par su. Toutes les commandes de ton script sont exécutées dans un même shell, alors que quand tu les tapes à la main su lance un nouveau shell.

Anonyme a écrit :

Le reboot n'est utile que si un Kernel est maj


C'est faux. Il y a des mises à jour qui affectent un grand nombre de processus, ou des processus qui peuvent difficilement être arrêtés sans faire planter des trucs, ou fermer la session... Dans ces cas il est plus simple et plus sûr de redémarrer le système que de chasser, arrêter et relancer tous les processus concernés.


Il vaut mieux montrer que raconter.

Hors ligne

Pied de page des forums