Dédié ne démarre plus après changement MDP root

Bonjour à tout le monde.
Je rencontre un soucis.

Je me connectais à mon serveur par le biais d'une clé SSH.
Pour les besoins d'un script il me fallait le couple d'identifiant de connexion. N'ayant plus le mot de passe de l'user "debian" je suis passé en mode rescue pour le modifier.

J'ai fais l'opération puis redémarrer mon serveur en mode normal. Mais voilà qu'il ne démarre plus .

Je suis un peu perdu et je ne sais pas ou chercher. D'après le message d'OVH ci dessous la configuration réseau à du sauter. ( en changeant un mot de passe c'est bizarre ! )

Voici les détails de cette opération :
Boot sur interface diagnostique (rescue)
Date 2021-03-22 19:00:41 CET (UTC +01:00), Boot sur interface diagnostique (rescue):
Voici le détail de l'intervention réalisée:
Le serveur est démarré (demande du 'login' à l'écran) mais inaccessible
par le réseau (pas de 'ping').
Un redémarrage sur un noyau standard OVH ('netboot') ne corrige pas la
situation.

Actions entreprises:
Redémarrage du serveur sur mode 'rescue' (Linux)

Résultat:
Boot OK. Système 'rescue' accessible.

Recommandations:
Configuration logicielle à corriger par le client

Bonjour,

vous avez fait quoi exactement ?
Pourquoi passer en rescue pour changer le mdp d'un user ?

Cordialement, janus57

Bonjour,
Alors en faite, j'ai redémarré en mode rescue, j'ai monté ma partition ( je n'ai pas vu au début mais /home et /var sont séparé, et je ne les avais pas monté avant de changer le mot de passe).

Ensuite fait fait chroot /mnt puis passwd et j'ai mis le nouveau mot de passe.
Et depuis le serveur ne démarre plus en mode HD.

Chose que je ne comprends pas trop. Quand j'ai commandé ce serveur, OVh m'a envoyé comme acces un user "debian" donc j'ai présumé que c'était l'access root.
Je suis passé en mode rescue car quand j'essayais de le faire ne normal, il me demandait l'ancien mot de passe que je n'avais pas.

Du coup en rescue j'ai essayé de refaire la manipulation en changeant le mot de passe pour l'user debian aussi. Mais ce n'est pas mieux.

Actuellement j'ai monté toutes mes partitions et j'ai bien accès à l'intégralité des données du serveur.

l'user debian n'est pas root, mais il a le droit de faire sudo su qui lui permet de passer root… c'est juste la base de la gestion du serveur de savoir ça…

Bref, vous êtes allez voir en ipmi / kvm / vnc pour savoir ce qui se passe ?
Vous avez tentez de vous connecter ainsi pour voir ce qui se passe avec le réseau ?
Quelle est la config rzo ? dhcp ? ip fixe ?

Désolé je ne connais pas les bases, je suis ultra novice mais j'essaie d'apprendre vite :stuck_out_tongue:
Pour l'utilisateur debian, ce qui m'a étonné c'est que généralement ovh me livre l'user root et là non, donc j'ai pensé qu'il avait remplacé root par debian… Sinon cela signifie que sur ce serveur je n'ai pas accès à l'utilisateur root vu que je n'ai pas le mot de passe ?

Le serveur est sur So you Start, je viens de voir que l'option ipmi / kvm était disponible mais payante chez so you Start.


Vous avez tentez de vous connecter ainsi pour voir ce qui se passe avec le réseau ?
Quelle est la config rzo ? dhcp ? ip fixe ?

Pouvez vous me dire comment voir ça SVP ?






Je ne sais pas si cela peut avoir son importance, mais ce serveur n'avait pas redémarré depuis plus d'un an. C'est un serveur de backup.

arf, pas d'ipmi, bien pour ça que je ne prends plus de SYS… C'est le genre de truc qu'on n'utilise jamais mais qui fait sérieusement défaut quand on en a besoin…

Pour en revenir à l'user root, vous y avez accès avec l'user debian puis sudo su.
Si vous voulez vous connecter directement en root je vous invite à lire le fichier /etc/ssh/sshd_config vous devriez y trouver votre bonheur. Notamment la ligne PermitRootLogin.

Pour en revenir à votre problème réseau, vous pouvez trouver la config dans /etc/network/interfaces, si vous pouviez nous copier / coller son contenu ici ça pourrait aider.

Je ne sais plus trop comment se comporte le réseau en mode rescue, mais vous pourriez nous donner le résultat des commandes : "ip a" et "ip route" ?

Sinon il faut se promener dans les logs… /var/log/… Voir si vous avez des messages à propos du réseau. Dans syslog, kern.log, messages également…


Pour en revenir à votre problème réseau, vous pouvez trouver la config dans /etc/network/interfaces, si vous pouviez nous copier / coller son contenu ici ça pourrait aider.


Voici le contenu :
> # interfaces(5) file used by ifup(8) and ifdown(8)
> # Include files from /etc/network/interfaces.d:
> source-directory /etc/network/interfaces.d

Pour ip a :
> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: bond0: mtu 1500 qdisc noop state DOWN group defa ult qlen 1000
> link/ether f2:36:a2:bd:8f:4e brd ff:ff:ff:ff:ff:ff
> 3: dummy0: mtu 1500 qdisc noop state DOWN group default qlen 1 000
> link/ether 4e:6d:fc:be:0c:65 brd ff:ff:ff:ff:ff:ff
> 4: ifb0: mtu 1500 qdisc noop state DOWN group default qlen 32
> link/ether 62:1d:d6:b7:39:20 brd ff:ff:ff:ff:ff:ff
> 5: ifb1: mtu 1500 qdisc noop state DOWN group default qlen 32
> link/ether 32:89:83:10:57:a2 brd ff:ff:ff:ff:ff:ff
> 6: eth0: mtu 1500 qdisc pfifo_fast state UP gr oup default qlen 1000
> link/ether 70:54:d2:19:c4:f3 brd ff:ff:ff:ff:ff:ff
> inet 188.165.222.226/24 brd 188.165.222.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet6 2001:41d0:2:a9e2::/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::7254:d2ff:fe19:c4f3/64 scope link
> valid_lft forever preferred_lft forever
> 7: teql0: mtu 1500 qdisc noop state DOWN group default qlen 100
> link/void
> 8: tunl0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000
> link/ipip 0.0.0.0 brd 0.0.0.0
> 9: gre0@NONE: mtu 1476 qdisc noop state DOWN group default qlen 1000
> link/gre 0.0.0.0 brd 0.0.0.0
> 10: gretap0@NONE: mtu 1462 qdisc noop state DOWN group def ault qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 11: erspan0@NONE: mtu 1450 qdisc noop state DOWN group def ault qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 12: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> 13: ip6tnl0@NONE: mtu 1452 qdisc noop state DOWN group default qlen 1000
> link/tunnel6 :: brd ::

Pour ip route :
> default via 188.165.222.254 dev eth0
> 188.165.222.0/24 dev eth0 proto kernel scope link src 188.165.222.226

Dans les logs, j'ai peut etre ça :

> Mar 22 17:57:06 ns312672 systemd[1]: Started Initial cloud-init job (pre-networking).
> Mar 22 17:57:06 ns312672 systemd[1]: Reached target Network (Pre).
> Mar 22 17:57:06 ns312672 systemd[1]: Starting Raise network interfaces...
> Mar 22 17:57:06 ns312672 systemd[1]: Started Raise network interfaces.
> Mar 22 17:57:06 ns312672 systemd[1]: Reached target Network.
> Mar 22 17:57:06 ns312672 systemd[1]: Starting Initial cloud-init job (metadata service crawler)...
> Mar 22 17:57:06 ns312672 cloud-init[503]: Cloud-init v. 18.3 running 'init' at Mon, 22 Mar 2021 17:57:05 +0000. Up 66.84 seconds.
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: +++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: | eno1 | False | . | . | . | 70:54:d2:19:c4:f3 |
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: | lo | True | ::1/128 | . | host | . |
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
> Mar 22 17:57:06 ns312672 kernel: [ 0.337702] AppArmor: AppArmor Filesystem Enabled
> Mar 22 17:57:06 ns312672 kernel: [ 0.337773] pnp: PnP ACPI init
> Mar 22 17:57:06 ns312672 kernel: [ 0.337928] system 00:00: [mem 0xfed10000-0xfed19fff] has been reserved
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: +-------+-------------+---------+-----------+-------+
> Mar 22 17:57:06 ns312672 kernel: [ 0.337989] system 00:00: [mem 0xf8000000-0xfbffffff] has been reserved
> Mar 22 17:57:06 ns312672 kernel: [ 0.338051] system 00:00: [mem 0xfed90000-0xfed93fff] has been reserved
> Mar 22 17:57:06 ns312672 kernel: [ 0.338112] system 00:00: [mem 0xfed20000-0xfed3ffff] has been reserved
> Mar 22 17:57:06 ns312672 cloud-init[503]: ci-info: | Route | Destination | Gateway | Interface | Flags |
> Mar 22 17:57:06 ns312672 kernel: [ 0.338174] system 00:00: [mem 0xfee00000-0xfee0ffff] has been reserved
> Mar 22 17:57:06 ns312672 kernel: [ 0.338238] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active)
> Mar 22 17:57:06 ns312672 kernel: [ 0.338337] system 00:01: [io 0x0290-0x029f] has been reserved
> Mar 22 17:57:06 ns312672 kernel: [ 0.338400] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
> Mar 22 17:57:06 ns312672 kernel: [ 0.338595] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)

J'espère ne pas avoir déposé de données sensibles sur mon post ?

Non rien de sensible…
Etonnant de n'avoir rien dans interfaces…
Il doit y avoir un fichier dans /etc/network/interfaces.d/ il y a quoi dedans ?

Visiblement l'interface serait eno1 en prod c'est bien ça ?

J'aurai bien tenté de mettre ça dans /etc/network/interfaces

allow-hotplug eno1
iface eno1 inet static
address 188.165.222.226/24
post-up ip route add 188.165.222.254 dev eno1
post-up ip route add default via 188.165.222.254


sous réserve que eno1 soit bien le nom de l'interface en mode "prod"..
Perso j'ai eno3, le fichier dans /etc/network/interfaces.d devrait en dire +…

Dans /etc/network/interfaces.d/ , j'ai un seul fichier 50-cloud-init.cfg

qui contient :
> # This file is generated from information provided by
> # the datasource. Changes to it will not persist across an instance.
> # To disable cloud-init's network configuration capabilities, write a file
> # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
> # network: {config: disabled}
> auto lo
> iface lo inet loopback

> auto eno1
> iface eno1 inet dhcp


Désolé je ne sais pas répondre à ta question, je ne sais pas ce que veux dire "eno" :frowning:

eno c'est le nom de l'interface rzo…
Je vois que le formatage de mon message a sauté.
Pour les lignes address et post-up il y a une tabulation au début.

En gros ce que je vous propose en modifiant le fichier interfaces c'est de passer le serveur en ip fixe, puis tenter un reboot voir si ça aide…

On peut penser que le serveur n'arrive pas à récupérer la config réseau.
Comme on n'a pas d'ipmi c'est difficile d'en savoir + comme ça..
Idem pour la "bonne" config que le serveur est censé avoir, mais on va se baser sur le mode rescue en espérant que ce soit la même chose.


allow-hotplug eno1
iface eno1 inet static
address 188.165.222.226/24
post-up ip route add 188.165.222.254 dev eno1
post-up ip route add default via 188.165.222.254


Je dois donc mettre ca dans mon fichier interface en remplacement de ce qui est déjà présent ou en plus ?

ben il n'y a rien actuellement, les lignes avec # sont commentées et ne sont pas prises en compte. Donc vous ajoutez ça à la suite.

Pensez à ajouter une tabulation.
`allow-hotplug eno1
iface eno1 inet static
address 188.165.222.226/24
post-up ip route add 188.165.222.254 dev eno1
post-up ip route add default via 188.165.222.254`

Ok je teste de suite :smiley:

Ca marche !!!
Vraiment bravo et merci pour ton aide.

Donc si j'ai bien compris, tu as dis que la configuration eno1 était statique : iface eno1 inet static
que l'adresse IP + port était 188.165.222.226/24

après le reste je ne comprends pas trop :frowning:

En gros le serveur n'arrivait pas à récupérer la config rzo via l'auto config DHCP.
Ce que je vous ai demandé de faire c'est faire cette config en fixe et de ne pas dépendre du service tiers (le dhcp).

Pour les lignes :
iface (interface) eno1 (son nom) inet static (on n'utilise pas le dhcp, on fait la config à la mano.
address (l'adresse ip du serveur et son netmask, ici 255.255.255.0 ou /24 c'est la même chose).
post-up (commande à exécuter après l'up de l'interface) ip route add (on ajoute une route vers la gw, ici c'était inutile car sur le même réseau, mais bon).
route add default : on définit la passerelle par défaut.

Voili, content que ça fonctionne pour vous :slight_smile: