Depuis quelques jours j'ai le message suivant qui pollue les logs:
cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Après quelques recherches, il semble que ce fichier est un reliquat d'un
passé pas trop lointain qui devait spécifier Í root sur quel tty il
pouvait se connecter. Or je ne vois pas pourquoi cups en parle et
surtout, je n'arrive plus Í imprimer depuis quelques jours. Pas sÍ»r que
ce soit lié mais sait-on jamais.
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í
faire ?
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
Bonjour, Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
Bonjour,
Le fichier est toujours utilisé de nos jours , c'est juste que les
applications n'y accède pas directement mais a travers Pam. Donc ton
fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
Bonjour, Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Sébastien NOBILI
Le 2020-11-13 07:55, steve a écrit :
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login". Sébastien
Le 2020-11-13 07:55, steve a écrit :
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
Le fichier est toujours utilisé de nos jours , c'est juste que les
applications n'y accède pas directement mais a travers Pam. Donc ton
fichier existe bien sur ta config ? Et que contient-il actuellement
?
Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Le fichier existe sur mon système (Buster assez fraÍ®chement installé).
Il appartient au paquet "login".
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login". Sébastien
l0f4r0
Bonjour, 12 nov. 2020 Í 17:08 de :
cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory [...] Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í faire ?
D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO Í cause du "No such file or directory" plus haut) 13 nov. 2020 Í 07:55 de :
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Maintenant je comprends que ton /etc/securetty n'existe pas finalement. Bref tu m'as un peu perdu... ;) 13 nov. 2020 Í 17:18 de :
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login".
Idem ici. Du coup que donne un simple : dpkg -l login Bien cordialement, l0f4r0
Bonjour,
12 nov. 2020 Í 17:08 de dlist@bluewin.ch:
cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
[...]
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í
faire ?
D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO Í cause du "No such file or directory" plus haut)
13 nov. 2020 Í 07:55 de dlist@bluewin.ch:
Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Maintenant je comprends que ton /etc/securetty n'existe pas finalement.
Bref tu m'as un peu perdu... ;)
13 nov. 2020 Í 17:18 de s-liste-debian-user-french@pipoprods.org:
Le fichier existe sur mon système (Buster assez fraÍ®chement installé).
Il appartient au paquet "login".
cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory [...] Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í faire ?
D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO Í cause du "No such file or directory" plus haut) 13 nov. 2020 Í 07:55 de :
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Maintenant je comprends que ton /etc/securetty n'existe pas finalement. Bref tu m'as un peu perdu... ;) 13 nov. 2020 Í 17:18 de :
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login".
Idem ici. Du coup que donne un simple : dpkg -l login Bien cordialement, l0f4r0
Fabien R
On 13/11/2020 07:55, steve wrote:
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
 Bonjour,  Le fichier est toujours utilisé de nos jours , c'est juste que les  applications n'y accède pas directement mais a travers Pam. Donc ton  fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Tu peux avoir l'info par la commande suivante: apt-file search /etc/securetty -- Fabien
On 13/11/2020 07:55, steve wrote:
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
 Bonjour,
 Le fichier est toujours utilisé de nos jours , c'est juste que les
 applications n'y accède pas directement mais a travers Pam. Donc ton
 fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Tu peux avoir l'info par la commande suivante:
apt-file search /etc/securetty
Le 12-11-2020, Í 17:18:29 +0100, Belaͯd a écrit :
 Bonjour,  Le fichier est toujours utilisé de nos jours , c'est juste que les  applications n'y accède pas directement mais a travers Pam. Donc ton  fichier existe bien sur ta config ? Et que contient-il actuellement ?
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Tu peux avoir l'info par la commande suivante: apt-file search /etc/securetty -- Fabien
steve
Le 13-11-2020, Í 19:18:00 +0100, a écrit :
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í faire ?
D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO Í cause du "No such file or directory" plus haut)
Au début, il n'existait pas. J'ai tenté d'en créer un vide avec 'touch /etc/securetty' en espérant que ça passerait. Ensuite, je me suis aperçu que ça ne changeait rien, donc je l'ai viré.
13 nov. 2020 Í 07:55 de :
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Maintenant je comprends que ton /etc/securetty n'existe pas finalement. Bref tu m'as un peu perdu... ;)
Désolé :)
13 nov. 2020 Í 17:18 de :
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login".
Pas chez moi: apt-file search /etc/securetty rear: /usr/share/rear/skel/Linux-ia64/etc/securetty 'dpkg --listfiles login' ne me liste pas ce fichier
Idem ici. Du coup que donne un simple : dpkg -l login
C'est installé. J'y perds mon grec… Merci pour l'intérêt. Steve
Le 13-11-2020, Í 19:18:00 +0100, l0f4r0@tuta.io a écrit :
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í
faire ?
D'après cette phrase je comprends que ton /etc/securetty existe (mais
que les droits sont probablement KO Í cause du "No such file or
directory" plus haut)
Au début, il n'existait pas. J'ai tenté d'en créer un vide avec 'touch
/etc/securetty' en espérant que ça passerait. Ensuite, je me suis aperçu
que ça ne changeait rien, donc je l'ai viré.
13 nov. 2020 Í 07:55 de dlist@bluewin.ch:
Non il n'existe pas.
Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Maintenant je comprends que ton /etc/securetty n'existe pas finalement.
Bref tu m'as un peu perdu... ;)
Désolé :)
13 nov. 2020 Í 17:18 de s-liste-debian-user-french@pipoprods.org:
Le fichier existe sur mon système (Buster assez fraÍ®chement installé).
Il appartient au paquet "login".
Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip Í faire ?
D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO Í cause du "No such file or directory" plus haut)
Au début, il n'existait pas. J'ai tenté d'en créer un vide avec 'touch /etc/securetty' en espérant que ça passerait. Ensuite, je me suis aperçu que ça ne changeait rien, donc je l'ai viré.
13 nov. 2020 Í 07:55 de :
Non il n'existe pas. Quel paquet aurait dÍ» le créer et quel devrait être son contenu ?
Maintenant je comprends que ton /etc/securetty n'existe pas finalement. Bref tu m'as un peu perdu... ;)
Désolé :)
13 nov. 2020 Í 17:18 de :
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login".
Pas chez moi: apt-file search /etc/securetty rear: /usr/share/rear/skel/Linux-ia64/etc/securetty 'dpkg --listfiles login' ne me liste pas ce fichier
Idem ici. Du coup que donne un simple : dpkg -l login
C'est installé. J'y perds mon grec… Merci pour l'intérêt. Steve
steve
Le 14-11-2020, Í 20:51:42 +0100, a écrit :
Bonsoir, 14 nov. 2020 Í 17:24 de :
13 nov. 2020 Í 17:18 de :
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login".
Pas chez moi: apt-file search /etc/securetty rear: /usr/share/rear/skel/Linux-ia64/etc/securetty
Ok, je parie que tu ne fais pas tourner Buster mais plutÍ´t Testing ou Unstable. Vrai ?
En plein dans le mille ! Je suis sous Testing
En effet login ne fournit plus /etc/securetty après Buster [1][2] d'o͹ ta sortie de commande différente de la mienne+Sébastien.
Ok, je ne savais pas.
J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3].
En effet, c'est très probablement la même chose chez moi,
Auquel cas, vu que le fichier n'est plus fourni, pam devrait arrêter de proposer des options qui y font appel au-delÍ de Buster.
Ce qui semble logique en effet.
Il semble que la ligne fautive soit dans /etc/pam.d/common-auth, plus précisément l'argument "nullok_secure" envoyé au module pam_unix.so. Je te laisse regarder si t'as bien cette ligne. Sous Buster chez moi c'est la suivante : auth   [success=1 default=ignore]     pam_unix.so nullok_secure
Oui j'ai bien ça.
Visiblement, supprimer "nullok_secure" résout le pb d'accès. Pas certain que ce soit une perte de sécurité dans la mesure o͹ cet argument autorise lui-même une certaine largesse...
Bon, je me lance, on verra bien si le monde arrête de tourner après ça.
nullok_secure: The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty.
Tous mes utilisateurs ont un mot de passe. Merci Í toi et très bon dimanche ! Steve
Le 14-11-2020, Í 20:51:42 +0100, l0f4r0@tuta.io a écrit :
Bonsoir,
14 nov. 2020 Í 17:24 de dlist@bluewin.ch:
13 nov. 2020 Í 17:18 de s-liste-debian-user-french@pipoprods.org:
Le fichier existe sur mon système (Buster assez fraÍ®chement installé).
Il appartient au paquet "login".
Ok, je parie que tu ne fais pas tourner Buster mais plutÍ´t Testing ou
Unstable. Vrai ?
En plein dans le mille ! Je suis sous Testing
En effet login ne fournit plus /etc/securetty après Buster [1][2] d'o͹
ta sortie de commande différente de la mienne+Sébastien.
Ok, je ne savais pas.
J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3].
En effet, c'est très probablement la même chose chez moi,
Auquel cas, vu que le fichier n'est plus fourni, pam devrait arrêter de
proposer des options qui y font appel au-delÍ de Buster.
Ce qui semble logique en effet.
Il semble que la ligne fautive soit dans /etc/pam.d/common-auth, plus
précisément l'argument "nullok_secure" envoyé au module pam_unix.so.
Je te laisse regarder si t'as bien cette ligne. Sous Buster chez moi
c'est la suivante : auth   [success=1 default=ignore]     pam_unix.so
nullok_secure
Oui j'ai bien ça.
Visiblement, supprimer "nullok_secure" résout le pb d'accès. Pas
certain que ce soit une perte de sécurité dans la mesure o͹ cet
argument autorise lui-même une certaine largesse...
Bon, je me lance, on verra bien si le monde arrête de tourner après ça.
nullok_secure: The default action of this module is to not permit the
user access to a service if their official password is blank. The
nullok_secure argument overrides this default and allows any user with
a blank password to access the service as long as the value of PAM_TTY
is set to one of the values found in /etc/securetty.
Le fichier existe sur mon système (Buster assez fraÍ®chement installé). Il appartient au paquet "login".
Pas chez moi: apt-file search /etc/securetty rear: /usr/share/rear/skel/Linux-ia64/etc/securetty
Ok, je parie que tu ne fais pas tourner Buster mais plutÍ´t Testing ou Unstable. Vrai ?
En plein dans le mille ! Je suis sous Testing
En effet login ne fournit plus /etc/securetty après Buster [1][2] d'o͹ ta sortie de commande différente de la mienne+Sébastien.
Ok, je ne savais pas.
J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3].
En effet, c'est très probablement la même chose chez moi,
Auquel cas, vu que le fichier n'est plus fourni, pam devrait arrêter de proposer des options qui y font appel au-delÍ de Buster.
Ce qui semble logique en effet.
Il semble que la ligne fautive soit dans /etc/pam.d/common-auth, plus précisément l'argument "nullok_secure" envoyé au module pam_unix.so. Je te laisse regarder si t'as bien cette ligne. Sous Buster chez moi c'est la suivante : auth   [success=1 default=ignore]     pam_unix.so nullok_secure
Oui j'ai bien ça.
Visiblement, supprimer "nullok_secure" résout le pb d'accès. Pas certain que ce soit une perte de sécurité dans la mesure o͹ cet argument autorise lui-même une certaine largesse...
Bon, je me lance, on verra bien si le monde arrête de tourner après ça.
nullok_secure: The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty.
Tous mes utilisateurs ont un mot de passe. Merci Í toi et très bon dimanche ! Steve
