Vous n'êtes pas identifié(e).
Le .desktop sur son bureau :
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
En oubliant pas l'espace entre su et le tiré
Debian sid
Bureau : xfce
Ordinateur : Thinkpad T400 libreboot
En ligne
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 . 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.
Dernière modification par Lupa (16-06-2020 11:00:51)
Hors ligne
Bonjour à tous
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
Ajouter au fichier sudoers ceci, dans la rubrique adéquate :
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)
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 :
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/...)
Hors ligne
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.
Hors ligne
Hors ligne
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.
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.
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.
Salut
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 !
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
même avec des ' ' ne marche pas.
@Lupa
En mettant PASSWD à la place de NOPASSWD
la commande à rentrer devient
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)
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.
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