J'ai sous le coude un très vénérable Olivetti M20 (clone 486)
fonctionnant sous SCO System V R 3.2 qui affiche un message ennuyeux
lorsque root sur loggue sur une console autorisée : "account disabled".
Précision peut-être utile : Le mot de passe root avait été défini à
l'installation (fin 1992) et n'avait jamais été changé depuis. La
machine (serveur Informix pour terminaux passifs) fonctionnait depuis 12
ans sans soucis significatifs. Il n'est pas trop difficile de recouvrer
provisoirement l'accès root en décalant l'horloge de deux ans dans le passé.
N'ayant pas de manuel sous la main, j'ai constaté que, lorsque l'on
éditait /etc/shadow (et que l'on vérifiait avoir effectivement modifié
les champs 3,4 et 5 la bonne ligne de ce fichier), le contenu original
du fichier shadow était restauré pendant le redémarrage du système.
à partir des docs d'OpenServer 5 dispos sur internet, j'ai supposé qu'il
fallait jeter un oeil dans /tcb/auth/[a-z]/$login_name et improviser.
Mais n'ayant pas d'accès internet proche de la machine en panne, ni doc,
ni d'expérience sur ce genre de systèmes, je me demandais si l'un
d'entre vous se souvenait comment administrer effectivement ce genre de
système. Notamment, est-ce que l'utilitaire interactif en ligne de
commande sysadmsh est à même de résoudre ce problème ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
antoine.bellot
Si ma mémoire est bonne tu peux en effet truander en éditant directement certains champs ides fichiers qui résident sous le répertoire tcb. Il me semble qu'à l'époque ce répertoire n'était pas directement à la racine mais plutôt sous etc et/ou usr.
Sinon, avec sysadmsh tu peux modifier les attributs d'un login pour agir sur l'expiration. Ca doit être jouable directement à coup de vi mais je n'ai plus aucun souvenir des détails. C'est très loin ca :-)
Merci pour ta réponse !
Après examen, il s'est avéré que le fichier /tcb/files/auth/r/root contenait de très nombreux paramètres (des "capabilities" au sens de la norme C2, exprimées sous la forme clé=valeur). Par ailleurs, quand on modifie ces fichiers à la main, des warnings curieux parlant de problèmes d'intégrité de fichiers sensibles apparaissent. Sans doc disponible sous la main sur le sens exact des "capabilities", j'ai trouvé plus utile de :
TERM=ansi; export TERM sysadmsh
et jouer dans les menus jusqu'à trouver "disable all locks", qui a résolu le problème.
Si ma mémoire est bonne tu peux en effet truander en éditant directement
certains champs ides fichiers qui résident sous le répertoire tcb. Il me
semble qu'à l'époque ce répertoire n'était pas directement à la racine mais
plutôt sous etc et/ou usr.
Sinon, avec sysadmsh tu peux modifier les attributs d'un login pour agir
sur l'expiration. Ca doit être jouable directement à coup de vi mais je
n'ai plus aucun souvenir des détails. C'est très loin ca :-)
Merci pour ta réponse !
Après examen, il s'est avéré que le fichier /tcb/files/auth/r/root
contenait de très nombreux paramètres (des "capabilities" au sens de la
norme C2, exprimées sous la forme clé=valeur). Par ailleurs, quand on
modifie ces fichiers à la main, des warnings curieux parlant de
problèmes d'intégrité de fichiers sensibles apparaissent. Sans doc
disponible sous la main sur le sens exact des "capabilities", j'ai
trouvé plus utile de :
TERM=ansi; export TERM
sysadmsh
et jouer dans les menus jusqu'à trouver "disable all locks", qui a
résolu le problème.
Si ma mémoire est bonne tu peux en effet truander en éditant directement certains champs ides fichiers qui résident sous le répertoire tcb. Il me semble qu'à l'époque ce répertoire n'était pas directement à la racine mais plutôt sous etc et/ou usr.
Sinon, avec sysadmsh tu peux modifier les attributs d'un login pour agir sur l'expiration. Ca doit être jouable directement à coup de vi mais je n'ai plus aucun souvenir des détails. C'est très loin ca :-)
Merci pour ta réponse !
Après examen, il s'est avéré que le fichier /tcb/files/auth/r/root contenait de très nombreux paramètres (des "capabilities" au sens de la norme C2, exprimées sous la forme clé=valeur). Par ailleurs, quand on modifie ces fichiers à la main, des warnings curieux parlant de problèmes d'intégrité de fichiers sensibles apparaissent. Sans doc disponible sous la main sur le sens exact des "capabilities", j'ai trouvé plus utile de :
TERM=ansi; export TERM sysadmsh
et jouer dans les menus jusqu'à trouver "disable all locks", qui a résolu le problème.
antoine.bellot
"antoine.bellot" writes:
Après examen, il s'est avéré que le fichier /tcb/files/auth/r/root contenait de très nombreux paramètres (des "capabilities" au sens de la norme C2, exprimées sous la forme clé=valeur).
Si j'ai de bon restes ils ont un look à la termcap. J'ai bon ?
Ouaips, des cheatcodes à la termcap/printcap en gros, genre :
Bon : ça se décode, mais "yen a beaucoup", sans compter les "capabilities" (codées sous forme de sous-clés, à vue de nez), plus, si j'en crois les docs, des "default values" planqués dans de nombreux autres fichiers éparpillés dans /tcb et /etc. J'osais pas imaginer ce qui se passerait en cas de typo sur un système déjà bancal, surtout avec les avertissements de :
Après examen, il s'est avéré que le fichier /tcb/files/auth/r/root
contenait de très nombreux paramètres (des "capabilities" au sens de
la norme C2, exprimées sous la forme clé=valeur).
Si j'ai de bon restes ils ont un look à la termcap. J'ai bon ?
Ouaips, des cheatcodes à la termcap/printcap en gros, genre :
Bon : ça se décode, mais "yen a beaucoup", sans compter les
"capabilities" (codées sous forme de sous-clés, à vue de nez), plus, si
j'en crois les docs, des "default values" planqués dans de nombreux
autres fichiers éparpillés dans /tcb et /etc. J'osais pas imaginer ce
qui se passerait en cas de typo sur un système déjà bancal, surtout avec
les avertissements de :
Après examen, il s'est avéré que le fichier /tcb/files/auth/r/root contenait de très nombreux paramètres (des "capabilities" au sens de la norme C2, exprimées sous la forme clé=valeur).
Si j'ai de bon restes ils ont un look à la termcap. J'ai bon ?
Ouaips, des cheatcodes à la termcap/printcap en gros, genre :
Bon : ça se décode, mais "yen a beaucoup", sans compter les "capabilities" (codées sous forme de sous-clés, à vue de nez), plus, si j'en crois les docs, des "default values" planqués dans de nombreux autres fichiers éparpillés dans /tcb et /etc. J'osais pas imaginer ce qui se passerait en cas de typo sur un système déjà bancal, surtout avec les avertissements de :
