Fuck, l'outil improbable
Je connaissais pas, ça m’a bien amusé: https://github.com/nvbn/thefuck <https://github.com/nvbn/thefuck>
Je connaissais, et j'aime beaucoup ! J'aime beaucoup aussi le plugin de sudo qui insulte l'utilisateur en cas d'erreur de mot de passe ! https://itsfoss.com/sudo-insult-linux/ Florian JUDITH On Tue, Apr 19, 2022 at 8:51 AM David Ponzone <david.ponzone@gmail.com> wrote:
Je connaissais pas, ça m’a bien amusé:
https://github.com/nvbn/thefuck
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Pour sudo, y'a aussi le coup du : └─$ apt update Reading package lists... Done E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) E: Unable to lock directory /var/lib/apt/lists/ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied) W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied) └─$ sudo !! sudo apt update Get:1 https://download.docker.com/linux/debian bullseye InRelease [43.3 kB] Hit:2 https://deb.debian.org/debian bullseye InRelease Le mar. 19 avr. 2022 à 09:05, Florian FRSAG <florian.judith+frsag@gmail.com> a écrit :
Je connaissais, et j'aime beaucoup !
J'aime beaucoup aussi le plugin de sudo qui insulte l'utilisateur en cas d'erreur de mot de passe !
https://itsfoss.com/sudo-insult-linux/
Florian JUDITH
On Tue, Apr 19, 2022 at 8:51 AM David Ponzone <david.ponzone@gmail.com> wrote:
Je connaissais pas, ça m’a bien amusé:
https://github.com/nvbn/thefuck
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Oui mais je fais tout sous root moi, j’ai découvert Unix sur SunOS vers 1991, y avait pas sudo :)
Le 19 avr. 2022 à 09:12, Romain <romain@borezo.info> a écrit :
Pour sudo, y'a aussi le coup du :
└─$ apt update Reading package lists... Done E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) E: Unable to lock directory /var/lib/apt/lists/ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied) W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)
└─$ sudo !! sudo apt update Get:1 https://download.docker.com/linux/debian <https://download.docker.com/linux/debian> bullseye InRelease [43.3 kB] Hit:2 https://deb.debian.org/debian <https://deb.debian.org/debian> bullseye InRelease
Le 19/04/2022 à 09:38, David Ponzone a écrit :
Oui mais je fais tout sous root moi, j’ai découvert Unix sur SunOS vers 1991, y avait pas sudo :)
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo. Pour un user, je discute pas le principe, mais pour un sysadmin qui, direct, va se monter un terminal sous root pour s'éviter de tapoter 5 caractères (avec l'espace)... -- Stéphane Rivière Ile d'Oléron - France
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour, Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi. Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr
Le 22/04/2022 à 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bonjour, je suis d'accord. Avec le seul fichier d'historique de commandes de root, on ne sait plus qui a fait quoi, si on est plusieurs admins. Par ailleurs, on n'est pas obligé de taper sudo pour chaque commande : il est possible de se mettre dans un shell (-sE). Ça me permet de récupérer mon environnement de travail, ce qui est bien pratique, comme pouvoir retrouver mes alias. Comme garde-fou, j'ai défini deux variables PS pour le prompt : un de couleur neutre quand je suis en tant qu'utilisateur ordinaire, et un de couleur rouge quand je devient root dans un shell sudo. Cordialement. -- Frantz de Germain Département Informatique UFR Sciences / DDN Université d'Angers
On Fri, Apr 22, 2022, at 10:13, Frantz de Germain wrote:
Le 22/04/2022 à 09:40, Nicolas CUVELIER a écrit : Par ailleurs, on n'est pas obligé de taper sudo pour chaque commande : il est possible de se mettre dans un shell (-sE).
J'ai un doute, l'historique de commandes va juste indiquer l'invocation du shell ou l'invocation de toutes les commandes lancées dans celui-ci du coup ? -- Kevin Decherf - @Kdecherf GPG 0x108ABD75A81E6E2F https://kdecherf.com
Le 22/04/2022 à 10:21, Kevin Decherf a écrit :
On Fri, Apr 22, 2022, at 10:13, Frantz de Germain wrote:
Le 22/04/2022 à 09:40, Nicolas CUVELIER a écrit : Par ailleurs, on n'est pas obligé de taper sudo pour chaque commande : il est possible de se mettre dans un shell (-sE).
J'ai un doute, l'historique de commandes va juste indiquer l'invocation du shell ou l'invocation de toutes les commandes lancées dans celui-ci du coup ?
toutes les commandes. -- Frantz de Germain Tel : 02 44 68 89 58 du mardi au vendredi Département Informatique UFR Sciences / DDN Université d'Angers
Sinon il est possible d'avoir des historiques "root" séparés pour chaque admin en utilisant $SUDO_USER dans le nom ou chemin de fichier (HISTFILE). Le ven. 22 avr. 2022 à 10:16, Frantz de Germain < frantz.degermain@univ-angers.fr> a écrit :
Le 22/04/2022 à 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bonjour,
je suis d'accord. Avec le seul fichier d'historique de commandes de root, on ne sait plus qui a fait quoi, si on est plusieurs admins.
Par ailleurs, on n'est pas obligé de taper sudo pour chaque commande : il est possible de se mettre dans un shell (-sE). Ça me permet de récupérer mon environnement de travail, ce qui est bien pratique, comme pouvoir retrouver mes alias. Comme garde-fou, j'ai défini deux variables PS pour le prompt : un de couleur neutre quand je suis en tant qu'utilisateur ordinaire, et un de couleur rouge quand je devient root dans un shell sudo.
Cordialement.
-- Frantz de Germain Département Informatique UFR Sciences / DDN Université d'Angers _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour, il existe aussi un système d'audit permettant de suivre l'activité. Mais ça prend pas mal d'espace si il y a beaucoup d'activités humaines. Maxime Le ven. 22 avr. 2022 à 10:42, Melanie Jacquart <melanie-jac@tubs.fr> a écrit :
Sinon il est possible d'avoir des historiques "root" séparés pour chaque admin en utilisant $SUDO_USER dans le nom ou chemin de fichier (HISTFILE).
Le ven. 22 avr. 2022 à 10:16, Frantz de Germain < frantz.degermain@univ-angers.fr> a écrit :
Le 22/04/2022 à 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bonjour,
je suis d'accord. Avec le seul fichier d'historique de commandes de root, on ne sait plus qui a fait quoi, si on est plusieurs admins.
Par ailleurs, on n'est pas obligé de taper sudo pour chaque commande : il est possible de se mettre dans un shell (-sE). Ça me permet de récupérer mon environnement de travail, ce qui est bien pratique, comme pouvoir retrouver mes alias. Comme garde-fou, j'ai défini deux variables PS pour le prompt : un de couleur neutre quand je suis en tant qu'utilisateur ordinaire, et un de couleur rouge quand je devient root dans un shell sudo.
Cordialement.
-- Frantz de Germain Département Informatique UFR Sciences / DDN Université d'Angers _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour, J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000). Qui peut me batre ? :-) L'historique de commandes root se trouve aussi dans ~/.bash_history Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre. En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer. Bon week-end --- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ---------------------------------- Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification... Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe. D. Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000). Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/ -- gpg: 0x1BD490507FA3BF7D
Ce courrier électronique ne contient *aucun virus ou logiciel malveillant* parce qu'il a été rédigé avec des *logiciels libres*. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro>
Quoi ? Vous partez du PC sans verrouiller la session ? ;) Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... <https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatically-when-you-step-away-from-it-d0a5f536-74ac-0859-820a-4140dac9fcaf> (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC) Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent. — Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG <frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D.
Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000). Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr <http://www.univ-jfc.fr/> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/>
Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/> -- gpg: 0x1BD490507FA3BF7D Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce qu'il a été rédigé avec des logiciels libres. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro>_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Sous linux j'utilise BlueProximity, sous Mac il y a BLEUnlock (https://github.com/ts1/BLEUnlock), mais je ne l'ai personnellement jamais essayé Les deux permettent aussi le déverrouillage quand on revient, ce que Windows ne permet pas de faire. Le 22/04/2022 à 10:59, Kevin Labécot a écrit :
Quoi ? Vous partez du PC sans verrouiller la session ? ;)
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC)
Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent.
— Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG <frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D.
Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000). Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/ -- gpg: 0x1BD490507FA3BF7D
Ce courrier électronique ne contient *aucun virus ou logiciel malveillant* parce qu'il a été rédigé avec des *logiciels libres*. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
moi j'utilise control + alt + suppr, puis touche entrée Le 22/04/2022 à 12:00, Dorian Netensia a écrit :
Sous linux j'utilise BlueProximity, sous Mac il y a BLEUnlock (https://github.com/ts1/BLEUnlock), mais je ne l'ai personnellement jamais essayé Les deux permettent aussi le déverrouillage quand on revient, ce que Windows ne permet pas de faire.
Le 22/04/2022 à 10:59, Kevin Labécot a écrit :
Quoi ? Vous partez du PC sans verrouiller la session ? ;)
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC)
Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent.
— Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG <frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D.
Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000). Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/ -- gpg: 0x1BD490507FA3BF7D
Ce courrier électronique ne contient *aucun virus ou logiciel malveillant* parce qu'il a été rédigé avec des *logiciels libres*. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Windows + L, c'est plus rapide ! Le ven. 22 avr. 2022 à 12:30, Pierre DOLIDON <sn4ky@sn4ky.net> a écrit :
moi j'utilise control + alt + suppr, puis touche entrée
Le 22/04/2022 à 12:00, Dorian Netensia a écrit :
Sous linux j'utilise BlueProximity, sous Mac il y a BLEUnlock ( https://github.com/ts1/BLEUnlock), mais je ne l'ai personnellement jamais essayé Les deux permettent aussi le déverrouillage quand on revient, ce que Windows ne permet pas de faire. Le 22/04/2022 à 10:59, Kevin Labécot a écrit :
Quoi ? Vous partez du PC sans verrouiller la session ? ;)
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC)
Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent.
— Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG <frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D. Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000). Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
-- gpg: 0x1BD490507FA3BF7D ------------------------------ Ce courrier électronique ne contient *aucun virus ou logiciel malveillant* parce qu'il a été rédigé avec des *logiciels libres*. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)shttp://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)shttp://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
+1 et l'envie pressante, si elle est *vraiment* pressante, tu pars pas avec ton tél connecté en bluetooth au PC... sinon ça s'appelle "aller mater une vidéo en loose dans les chiottes au détour d'un popo / café" Jacques Le 22/04/2022 à 12:53, Ludovic Scotti a écrit :
Windows + L, c'est plus rapide !
Le ven. 22 avr. 2022 à 12:30, Pierre DOLIDON <sn4ky@sn4ky.net> a écrit :
moi j'utilise control + alt + suppr, puis touche entrée
Le 22/04/2022 à 12:00, Dorian Netensia a écrit :
Sous linux j'utilise BlueProximity, sous Mac il y a BLEUnlock (https://github.com/ts1/BLEUnlock), mais je ne l'ai personnellement jamais essayé Les deux permettent aussi le déverrouillage quand on revient, ce que Windows ne permet pas de faire.
Le 22/04/2022 à 10:59, Kevin Labécot a écrit :
Quoi ? Vous partez du PC sans verrouiller la session ? ;)
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC)
Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent.
— Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG <frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D.
Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000). Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit : > Pour un adminsys manipulant des serveurs, j'attends toujours > qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr <http://www.univ-jfc.fr/> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
-- gpg: 0x1BD490507FA3BF7D ------------------------------------------------------------------------ Ce courrier électronique ne contient *aucun virus ou logiciel malveillant* parce qu'il a été rédigé avec des *logiciels libres*. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour, Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ? Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console. Cdlt, [1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~". Le 22/04/2022, Kevin Labécot<kevin@labecot.fr> a écrit :
Quoi ? Vous partez du PC sans verrouiller la session ? ;)
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... <https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatically-when-you-step-away-from-it-d0a5f536-74ac-0859-820a-4140dac9fcaf> (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC)
Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent.
— Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG <frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D.
Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000).
Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste
qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est
pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux,
ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root
Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr <http://www.univ-jfc.fr/> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/>
Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/> -- gpg: 0x1BD490507FA3BF7D Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce qu'il a été rédigé avec des logiciels libres. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro>_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Ben tu as le droit de lancer screen aussi sur la console :)
Le 22 avr. 2022 à 13:24, Matic Vari <varimatic@gmail.com> a écrit :
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
Bonjour, J'y avais pensé, mais comment verrouiller ensuite ? Forcer le détachement de screen ? Quand une commande est en cours (prompt "occupé"), comment faire ? Cdlt, Le 22/04/2022, David Ponzone<david.ponzone@gmail.com> a écrit :
Ben tu as le droit de lancer screen aussi sur la console :)
Le 22 avr. 2022 à 13:24, Matic Vari <varimatic@gmail.com> a écrit :
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
Ben c’est ctrl-a puis d pour détacher. Et screen -r pour la récupérer. Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr <blocked::http://www.ipeva.fr/> - www.ipeva-studio.com <blocked::http://www.ipeva-studio.com/> Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 22 avr. 2022 à 13:32, Matic Vari <varimatic@gmail.com> a écrit :
Bonjour,
J'y avais pensé, mais comment verrouiller ensuite ?
Forcer le détachement de screen ? Quand une commande est en cours (prompt "occupé"), comment faire ?
Cdlt,
Le 22/04/2022, David Ponzone<david.ponzone@gmail.com> a écrit :
Ben tu as le droit de lancer screen aussi sur la console :)
Le 22 avr. 2022 à 13:24, Matic Vari <varimatic@gmail.com> a écrit :
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
Bonjour, On vendredi 22 avril 2022 13:32:31 CEST, Matic Vari wrote:
J'y avais pensé, mais comment verrouiller ensuite ?
Forcer le détachement de screen ? Quand une commande est en cours (prompt "occupé"), comment faire ?
Ctrl-A D pour détacher screen puis Ctrl-D pour fermer le shell ?
Le 22/04/2022, David Ponzone<david.ponzone@gmail.com> a écrit :
Ben tu as le droit de lancer screen aussi sur la console :) ...
man screen /lock C-a x or C-a C-x (lockscreen) Lock this terminal. On Fri, Apr 22, 2022 at 1:38 PM Matic Vari <varimatic@gmail.com> wrote:
Bonjour,
J'y avais pensé, mais comment verrouiller ensuite ?
Forcer le détachement de screen ? Quand une commande est en cours (prompt "occupé"), comment faire ?
Cdlt,
Le 22/04/2022, David Ponzone<david.ponzone@gmail.com> a écrit :
Ben tu as le droit de lancer screen aussi sur la console :)
Le 22 avr. 2022 à 13:24, Matic Vari <varimatic@gmail.com> a écrit :
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 22/04/2022 à 13:27, David Ponzone a écrit :
Ben tu as le droit de lancer screen aussi sur la console :) [...]
Pour compléter, on peut éventuellement précéder la commande de nohup. Sinon, il existe aussi tmux, qui fait exactement la même chose que screen, mais avec des raccourcis différents, que je trouve plus logiques. On peut lancer une session (ou plusieurs) avec screen ou tmux, et se détacher ou se rattacher ensuite, passer de l'une à l'autre etc. C'est très pratique. On peut en lancer plusieurs etc. Pour verrouiller le terminal, il suffit de se détacher de la session (qui va continuer en arrière plan), et se déloguer. Bonne journée G
Bonjour, Question qui me chagrine un peu avec les terminaux virtuels : vous gérez comment vos différents historiques ? Merci, Le 22/04/2022 à 13:53, Grégoire a écrit :
Le 22/04/2022 à 13:27, David Ponzone a écrit :
Ben tu as le droit de lancer screen aussi sur la console :) [...] Pour compléter, on peut éventuellement précéder la commande de nohup.
Sinon, il existe aussi tmux, qui fait exactement la même chose que screen, mais avec des raccourcis différents, que je trouve plus logiques.
On peut lancer une session (ou plusieurs) avec screen ou tmux, et se détacher ou se rattacher ensuite, passer de l'une à l'autre etc. C'est très pratique.
On peut en lancer plusieurs etc.
Pour verrouiller le terminal, il suffit de se détacher de la session (qui va continuer en arrière plan), et se déloguer.
Bonne journée G
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
-- Dernat Rémy Chef de projet SI, CNRS Infrastructure des Systèmes d'Information ISI ISEM Montpellier
Salut, Perso on utlise sudo pour justement avoir l'historique avec le nom réel de l'utilisateur. Example RHEL : # Configure Logging shell commands sed -ie '/log\/boot.log/a local6.* /var/log/commands.log' /etc/rsyslog.conf systemctl restart rsyslog sed -ie '/spooler/a /var/log/commands.log' /etc/logrotate.d/syslog # Bash command logging echo "# Command logging through local6" >> /etc/bashrc echo $'export PROMPT_COMMAND=\'RETRN_VAL=$?;logger -p local6.debug "$(whoami) [$$]: $(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//" ) [$RETRN_VAL]"\'' >> /etc/bashrc # Prompt avec changement de couleur si erreur echo $'PS1=\'\[`[ $? = 0 ] && X=2 || X=3; tput setaf $X`\]$1-\h\[`tput sgr0`\]:$PWD\\n\\$ \'' > /etc/profile.d/prompt.sh Juste $1 à changer sur la dernière ligne, c'est un commentaire pour savoir sur quelle machine tu es sans connaître son hostname. Et pour détacher un job sur une console physique : ^Z bg disown -a logout Bon WE Stan Le vendredi 22 avril 2022 à 14:14 +0200, Dernat Rémy a écrit :
Bonjour, Question qui me chagrine un peu avec les terminaux virtuels : vous gérez comment vos différents historiques ? Merci, Le 22/04/2022 à 13:53, Grégoire a écrit :
Le 22/04/2022 à 13:27, David Ponzone a écrit :
Ben tu as le droit de lancer screen aussi sur la console :) [...] Pour compléter, on peut éventuellement précéder la commande de nohup.
Sinon, il existe aussi tmux, qui fait exactement la même chose que screen, mais avec des raccourcis différents, que je trouve plus logiques.
On peut lancer une session (ou plusieurs) avec screen ou tmux, et se détacher ou se rattacher ensuite, passer de l'une à l'autre etc. C'est très pratique.
On peut en lancer plusieurs etc.
Pour verrouiller le terminal, il suffit de se détacher de la session (qui va continuer en arrière plan), et se déloguer.
Bonne journée G
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Il existe l'utilitaire "vlock" Package: vlock Version: 2.2.2-8 programme de verrouillage de console virtuelle Vlock verrouille soit le terminal courant (qui peut être tout type de terminal, local ou distant), soit le système complet de console virtuelle, désactivant tous les accès aux consoles. Vlock abandonne ces verrouillages lorsque le mot de passe de l'utilisateur ayant démarré vlock ou le mot de passe root est saisi. . Vlock est intéressant dans les environnements de système multi- utilisateur. Vlock permet aux utilisateurs de verrouiller leurs sessions, tout en permettant à d’autres de continuer à utiliser le même système à l’aide d’un autre terminal virtuel. D. Le 22/04/2022 à 13:24, Matic Vari a écrit :
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
Le 22/04/2022, Kevin Labécot<kevin@labecot.fr> a écrit :
Quoi ? Vous partez du PC sans verrouiller la session ? ;)
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... <https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatically-when-you-step-away-from-it-d0a5f536-74ac-0859-820a-4140dac9fcaf> (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC)
Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent.
— Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG<frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D.
Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000).
Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste
qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est
pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux,
ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root
Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo. Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr <http://www.univ-jfc.fr/> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/>
Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/> -- gpg: 0x1BD490507FA3BF7D Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce qu'il a été rédigé avec des logiciels libres. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro>_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ -- gpg: 0x1BD490507FA3BF7D
Ce courrier électronique ne contient *aucun virus ou logiciel malveillant* parce qu'il a été rédigé avec des *logiciels libres*. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro>
Bonjour, Sans répondre au verrouillage, il me vient une idée (que je pratique moi même) : Soit : utiliser une session screen détachée afin de pouvoir laisser le traitement s'effectuer en tâche de fond, même en se déconnectant de la sessions SSH. Amicalement, Élodie Le 22/04/2022 à 13:24, Matic Vari a écrit :
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Le 22 avril à 13:34 Élodie BOSSIER via FRsAG a écrit
Bonjour,
Sans répondre au verrouillage, il me vient une idée (que je pratique moi même) :
Avec screen : C-a x verrouille le terminal. -- Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net Société Libre, Logiciel Libre http://www.april.org/adherer Parinux, logiciel libre à Paris : http://www.parinux.org
On Fri, Apr 22, 2022 at 01:24:03PM +0200, Matic Vari wrote:
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
tu peux faire a peu pres la meme chose en console, non ? Tu lances ta commande dans un screen puis tu dettaches le screen (ctrl-A d) et tu te deloggues. Apres il y a aussi un lock dans screen (ctrl-A x). Mais je ne sais pas si on peut le contourner (e.g. dettacher le screen) pour recuperer un shell. a+, -- Julien << Vous n'avez rien a dire... Parlons-en! >>
julien soula, le ven. 22 avril 2022 13:37:32 +0200, a ecrit:
Tu lances ta commande dans un screen puis tu dettaches le screen (ctrl-A d) et tu te deloggues.
Apres il y a aussi un lock dans screen (ctrl-A x). Mais je ne sais pas si on peut le contourner (e.g. dettacher le screen) pour recuperer un shell.
Tu peux utiliser exec screen pour qu'il n'y ait plus de shell vers lequel potentiellement retourner. Samuel
Ah, oui! Et en ssh ca peut marcher aussi, c'est plus élégant que de couper la connexion ssh brutalement.... :D Cdlt, Le 22/04/2022, julien soula<julien.soula@univ-lille2.fr> a écrit :
On Fri, Apr 22, 2022 at 01:24:03PM +0200, Matic Vari wrote:
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
tu peux faire a peu pres la meme chose en console, non ?
Tu lances ta commande dans un screen puis tu dettaches le screen (ctrl-A d) et tu te deloggues.
Apres il y a aussi un lock dans screen (ctrl-A x). Mais je ne sais pas si on peut le contourner (e.g. dettacher le screen) pour recuperer un shell.
a+, -- Julien << Vous n'avez rien a dire... Parlons-en! >>
Re-bonjour, Y'a la tâche de fond. Elle est détruite à la déconnexion, sous Unix, mais pas sous Linux, où le PPID devient celui du "père de tous les processus". --- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ---------------------------------- Le 2022-04-22 13:24, Matic Vari a écrit :
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations "longues" (quelques dizaines de minutes). Vu que les serveurs sont dans des baies, et que c'est pas aussi confortable que mon bureau (bruit, froid, position de travail inconfortable), j'aimerai bien quitter le lieu le temps de la fin de l'opération, sans la couper et sans laisser le compte ouvert. Problème : je ne sais pas comment juste "verrouiller" ma console.
Cdlt,
[1] : Quand je suis en SSH, et que je veux laisser une opération longue se dérouler sans laisser la connexion ouverte : je lance screen au début, et quand je veux couper la connexion mais pas l'opération en cours : "entrée" puis "." et "~".
Le 22/04/2022, Kevin Labécot<kevin@labecot.fr> a écrit :
Quoi ? Vous partez du PC sans verrouiller la session ? ;)
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne : https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatical... <https://support.microsoft.com/en-us/windows/lock-your-windows-pc-automatically-when-you-step-away-from-it-d0a5f536-74ac-0859-820a-4140dac9fcaf> (Et le périmètre d’éloignement peut être affiné via la base de registre, ds mon cas ca lock si je suis à ~2m du PC)
Sous Mac j’aimerai bien la même chose mais je n’ai pas trouvé d’équivalent.
— Kevin
Le 22 avr. 2022 à 10:45, David via FRsAG <frsag@frsag.org> a écrit :
Il ne faut pas oublier dans ce cas que 'sudo' a une "latence" d'identification...
Si tu tapes une commande 'sudo' et que tu pars en courant aux toilettes pour une "urgence", quelqu'un peut profiter de ta dernière commande pour relancer 'sudo' sans mot de passe.
D.
Le 22/04/2022 à 10:22, C.F.G.I. a écrit :
Bonjour,
J'ai connu Unix en 1982, version SIII, sur Thomson MM32 (Motorola 68000).
Qui peut me batre ? :-)
L'historique de commandes root se trouve aussi dans ~/.bash_history
Le seul intérèt de sudo, à mon goût, est de "quitter" l'identité root à la fin de l'exécution de celle-ci. Ca a plutôt été créé, à priori, pour contrer l'admin sys un poil laxiste
qui laisse sa connexion root active, pendant qu'il va boire un caf (c'est
pas long, un caf ...), parler du we (pas trop longtemps ...), ou des élections (encore moins longtemps ... :-) ). Clairement, celui qui laisse sa connexion root active une minute ou deux,
ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
En tous cas, perso, quand je n'ai pas le compte root : sudo passwd root
Ce qui démontre, en passant, que /etc/sudoers est chiant à configurer.
Bon week-end
--- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ----------------------------------
Le 2022-04-22 09:40, Nicolas CUVELIER a écrit :
Le 22/04/2022 à 09:29, Stéphane Rivière a écrit :
Pour un adminsys manipulant des serveurs, j'attends toujours qu'on m'explique l'utilité du sudo.
Bonjour,
Un intérêt sur un serveur "multi-adminsys" est que les appels "sudo" sont journalisés (/var/log/auth.log) ; ça peut aider de revenir sur ce qui a été fait par un collègue ... ou même par soi.
Bien à vous, -- Nicolas CUVELIER Administrateur Systèmes et Réseaux Direction du Système d'Information et des Usages du Numérique
Institut National Universitaire Champollion Campus d'Albi / Place de Verdun - CS 33222 - 81012 Albi Cedex www.univ-jfc.fr <http://www.univ-jfc.fr/> _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/>
Liste de diffusion du %(real_name)s http://www.frsag.org/ <http://www.frsag.org/> -- gpg: 0x1BD490507FA3BF7D Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce qu'il a été rédigé avec des logiciels libres. Plus d'infos : Association APRIL <http://www.april.org/fr/articles/intro>_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
On vendredi 22 avril 2022 13:52:38 CEST, C.F.G.I. wrote:
Y'a la tâche de fond. Elle est détruite à la déconnexion, sous Unix, mais pas sous Linux, où le PPID devient celui du "père de tous les processus".
Ca dépend du shell. En zsh, les jobs sont terminés a la fermeture du shell, en bash non. csh je me souviens plus. Il y a disown pour détacher les taches de fond et éviter ça. Voir aussi la variable d'environnement TMOUT pour fermer les shells inactifs. Attention enfin avec systemd a KillUserProcesses= a la fermeture de session.
Le 2022-04-22 13:24, Matic Vari a écrit :
Bonjour,
Quelqu'un a une solution pour verrouiller la console sous GNU/Linux ?
Explication : Sur mes serveurs, j'ai pas d'interface graphique. Il m'arrive parfois de devoir intervenir "directement" sur le serveur, sans passer par SSH [1]. Et c'est souvent pour des opérations ...
Je vais partir un chouilla hors-sujet mais quand je suis sous Windows, j’ai ça en place sur ma machine depuis quelques années pour éviter de le laisser non verrouillé quand je m'éloigne :
Marrant et pas con. Faut pas oublier son malinphone. Je tenterais bien le même trucsous Nux avec une montre BT... Ah zut, parfois je la charge sur l'écran... -- Stéphane Rivière Ile d'Oléron - France
Le ven. 22 avr. 22 à 10:22:49 +0200, C.F.G.I. <bb.cfgi@gozmail.bzh> écrivait :
Bonjour,
Salut,
Clairement, celui qui laisse sa connexion root active une minute ou deux, ça laisse largement le temps de foutre la merde sur les serveurs ... ... ou d'installer un troyen... ou autre.
La règle de base, c’est qu’une session laissée ouverte, ça sert à envoyer une invitation pour l’apéro ou les croissants du lendemain ! -- Th. Thomas.
Bonjour, Le 22-04-2022 09:29, Stéphane Rivière a écrit :
Pour un user, je discute pas le principe, mais pour un sysadmin qui, direct, va se monter un terminal sous root pour s'éviter de tapoter 5 caractères (avec l'espace)...
Dans l'idée, la connexion initiale, qu'elle soit locale ou ssh, devrait toujours se faire avec un compte non privilégié, puis faire une élévation de droits une fois connecté. Que cette élévation de droits se fasse en "su -" ou en "sudo -s", ça ne change pas grand chose. Ca permet une meilleure identification de l'intervenant (compte nominal), une meilleure sécurité globale (clé + mdp) au prix d'une commande et un mdp à taper en plus. Ca vaut surement le coup. Guy.
participants (28)
-
C.F.G.I. -
David -
David Ponzone -
Dernat Rémy -
Dorian Netensia -
Florian FRSAG -
Frantz de Germain -
Grégoire -
Guy Larrieu -
Jacques MICHAU -
julien soula -
Kevin Decherf -
Kevin Labécot -
Ludovic Scotti -
Matic Vari -
Maxime Pauwels -
Melanie Jacquart -
neo futur -
Nicolas CUVELIER -
Pierre DOLIDON -
Romain -
Samuel Thibault -
Stanislas Garret -
Stéphane Rivière -
Thierry Thomas -
Vincent Tondellier -
Vincent-Xavier JUMEL -
Élodie BOSSIER