Salut,
et en rendant ssh plus “verbeux” ?
En tout cas:[quote=“trululu”]Connection refused[/quote]Ça signifie que la machine est bien en route, sinon t’aurais un timed-out.
Très bonne idée le -v (merci)user01@workstation01:~$ ssh -v user02@server01
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to w.x.y.z [w.x.y.z] port 22.
debug1: connect to address w.x.y.z port 22: Connection refused
ssh: connect to host w.x.y.z port 22: Connection refused
user01@workstation01:~$
Re,
Tu ne te souviens pas des maj faites ? Il y a eu des question au moment de la maj au sujet de fichiers conf modifiés ?
Root à du recevoir un mail à ce sujet… Mail il faut un soft pour lire le mail (mailutils - qui contient le binaire mail, mutt, cone, (al)pine…).
Mais on s’éloigne et il faut apprendre à s’en servir…
Je soupçonne que le serveur ssh n’est pas démarré. Cassé ?
Tu peux recommencer un chroot en netboot et réinstaller ssh-server
Sudo si c’est une Ubuntu…
Avec un peu de chance ça suffira…
Dernière question: Parefeu ?
Salut,
[mono]ssh -v user02@server01[/mono] un peu short … à mon avis.
Plus verbeux, stp.
Avec un retour console intégral, de préférence …
Aucun intérêt. “Connection refused” = port fermé. Tu peux mettre autant de -v que tu veux, ça ne t’apprendra rien de plus. Faut arrêter l’acharnement inutile.
@lol :
Voici les màj qui ont été faites :
root@rescue:~# /var/log/apt/history.log
Start-Date: 2014-05-15 11:24:23
Commandline: apt-get dist-upgrade
Upgrade: openssh-server:amd64 (5.9p1-5ubuntu1.3, 5.9p1-5ubuntu1.4), linux-firmware:amd64 (1.79.12, 1.79.14), linux-image-3.2.0-61-generic:amd64 (3.2.0-61.92, 3.2.0-61.93), openssh-client:amd64 (5.9p1-5ubuntu1.3, 5.9p1-5ubuntu1.4), libssl-dev:amd64 (1.0.1-4ubuntu5.12, 1.0.1-4ubuntu5.13), libssl-doc:amd64 (1.0.1-4ubuntu5.12, 1.0.1-4ubuntu5.13), dpkg:amd64 (1.16.1.2ubuntu7.2, 1.16.1.2ubuntu7.4), libtiff4:amd64 (3.9.5-2ubuntu1.5, 3.9.5-2ubuntu1.6), tzdata:amd64 (2014a-0ubuntu0.12.04, 2014c-0ubuntu0.12.04), openssl:amd64 (1.0.1-4ubuntu5.12, 1.0.1-4ubuntu5.13), linux-libc-dev:amd64 (3.2.0-61.92, 3.2.0-61.93), libssl1.0.0:amd64 (1.0.1-4ubuntu5.12, 1.0.1-4ubuntu5.13)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2014-05-15 11:27:25
root@rescue:~# et les erreurs qu’il y a eu :
root@rescue:~# cat /var/log/apt/term.log
Log started: 2014-05-15 11:24:23
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Impossible d'écrire le journal, échec d'openpty()
(/dev/pts est-il monté ?)
Log ended: 2014-05-15 11:27:25
root@rescue:~#
Un nouveau kernel ayant été installé, Grub doit chercher à booter dessus : je vais essayer de le modifier pour qu’il boot sur l’ancien, pour voir.
Sinon, à priori root n’a reçu aucun mail : (mailutils était déjà installé)
root@rescue:~# mail
No mail for root
root@rescue:~# et j’ai ré-installé openssh-server mais je n’ai pas eu de meilleur résultat.
@BelZéButh :
Pour info, le retour console du ssh -v est intégral. (j’ai juste anonymisé les IP)
La régénération de la conf de Grub ne fonctionne pas car j’obtiens cette erreur :
root@rescue:/# update-grub
Generating grub.cfg ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Warning: update-grub_lib is deprecated, use grub-mkconfig_lib instead
Found linux image: /boot/vmlinuz-3.2.0-61-generic
/usr/sbin/grub-probe : erreur : no such disk.
/usr/sbin/grub-probe : erreur : no such disk.
done
root@rescue:/# A priori il ne voit pas les autres kernels dispo dans /mnt/md1/grub/ et c’est le Grub dans le chroot (/mnt/md2/boot/grub/) qui est mis à jour, pas celui dans /mnt/md1/grub/ !
Et bien évidemment, quand je redémarre en mode normal, toujours pas d’accès en ssh.
Mais il y a quelque chose que je ne comprends pas :
- je dois bien être « chrooté » pour faire mon upgrade-grub, non ?
- et pour que ça fonctionne correctement, il faut bien que Grub puisse accéder aux différentes images installées sur le /boot/grub/ du système en mode normal, càd sur /mnt/md1/grub/, non ?
Sauf que /mnt/md1 n’est pas accessible depuis le chroot (/mnt/md2)
Alors comment faire ?
il serait peut être bien de poster le contenu de ton sshd_config…
De plus peut tu faite un :
histoire de vérifier si c’est pas le port ssh qui est bloqué…
et aussi un # /etc/init.d/ssh status
[quote=“leo-25”]il serait peut être bien de poster le contenu de ton sshd_config…[/quote]Je ne l’ai pas encore fait car je ne pense pas que ça vienne de la config du serveur ssh, pour 2 raisons :
- aucun fichier de conf n’a été modifié dans /mnt/md2/etc/ssh/ depuis 2011,
- le fichier /mnt/md2/etc/ssh/sshd_config est exactement le même que sur mes autres serveurs (je viens de re-vérifier) et j’arrive sans pb à me connecter à ces derniers.
Par contre, est-ce que le serveur démarre bien ?
Sans log, c’est difficile à savoir…
[quote=“leo-25”]De plus peut tu faite un :
Code:
iptables -L -n -v
histoire de vérifier si c’est pas le port ssh qui est bloqué…[/quote]Bonne idée, mais malheureusement le résultat de cette commande (forcément lancée en mode rescue) ne sera pas représentatif de l’état du firewall lorsque je boote en mode normal.
Mais histoire d’être sur que ça ne vienne pas de là, j’ai tenté de booter volontairement avec un firewall peu restrictif 
:root@rescue:~# cat /mnt/md2/etc/init.d/firewall
#!/bin/sh
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
root@rescue:~# mais ça marche pas mieux…
[quote=“leo-25”]et aussi un
Code:
/etc/init.d/ssh status[/quote]Résultat là aussi non représentatif car commande lancée en mode rescue, même si chrooté :[code]root@rescue:/# service ssh status
status: Impossible de se connecter à Upstart: Failed to connect to socket /com/ubuntu/upstart: Connexion refusée
root@rescue:/#
[/code]
Salut
[quote=“trululu”]Par contre, est-ce que le serveur démarre bien ?
Sans log, c’est difficile à savoir…[/quote]
Tu n’as pas d’autres services pour vérifier ? Serveur Web, FTP ?
[quote=“lol”]Tu n’as pas d’autres services pour vérifier ? Serveur Web, FTP ?[/quote]Non, c’est un serveur d’archivage vers lequel je pousse des datas : à part ssh, rien d’autre ne tourne.
Ta question m’a donné l’idée d’ajouter cette ligne à la crontab root :@reboot echo "Le `date` (crontab)" | mail -s "Démarrage de serveur01" toto@aol.comet de créer aussi un petit script d’envoi de mail que je démarre en premier (S10) pour les runlevels 2, 3, 4 et 5 :#!/bin/bash
echo "Le `date` (init.d)" | mail -s "Démarrage de serveur01" toto@aol.com
J’ai testé mes deux commandes en chroot : elles fonctionnent.
Malheureusement, si je démarre en mode normal je ne reçois aucun mail !
Il faut monter /dev/md1 sur le /boot du chroot, pas dans /mnt.
Mais oui bien sur, c’est évident !!! (je suis vraiment trop -beeeep- moi !)
Comme ça effectivement, les autres images sont bien vues par Grub maintenant :root@rescue:/# update-grub
Generating grub.cfg ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Warning: update-grub_lib is deprecated, use grub-mkconfig_lib instead
Found linux image: /boot/bzImage-3.2.13-xxxx-grs-ipv6-64
/usr/sbin/grub-probe : erreur : no such disk.
Found linux image: /boot/vmlinuz-3.2.0-61-generic
Found initrd image: /boot/initrd.img-3.2.0-61-generic
/usr/sbin/grub-probe : erreur : no such disk.
/usr/sbin/grub-probe : erreur : no such disk.
Found linux image: /boot/vmlinuz-3.2.0-60-generic
Found initrd image: /boot/initrd.img-3.2.0-60-generic
/usr/sbin/grub-probe : erreur : no such disk.
/usr/sbin/grub-probe : erreur : no such disk.
Found linux image: /boot/vmlinuz-3.2.0-59-generic
Found initrd image: /boot/initrd.img-3.2.0-59-generic
/usr/sbin/grub-probe : erreur : no such disk.
/usr/sbin/grub-probe : erreur : no such disk.
done
root@rescue:/# Mais bon, j’ai toujours ces erreurs “no such disk” et je ne vois pas du tout à quoi c’est dû.
Et ça boote toujours pas en mode normal.
Pour info, voici mon /mnt/md2/boot/grub/grub.cfg[code]#
DO NOT EDIT THIS FILE
It is automatically generated by grub-mkconfig using templates
from /etc/grub.d and settings from /etc/default/grub
BEGIN /etc/grub.d/00_header
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
set default=“2"
if [ “${prev_saved_entry}” ]; then
set saved_entry=”${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z “${boot_once}” ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function recordfail {
set recordfail=1
if [ -n “${have_grubenv}” ]; then if [ -z “${boot_once}” ]; then save_env recordfail; fi; fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
if [ “${recordfail}” = 1 ] ; then
set timeout=-1
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=hidden
set timeout=0
Fallback hidden-timeout code in case the timeout_style feature is
unavailable.
elif sleep --interruptible 0 ; then
set timeout=0
fi
fi
END /etc/grub.d/00_header
BEGIN /etc/grub.d/05_debian_theme
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
END /etc/grub.d/05_debian_theme
BEGIN /etc/grub.d/06_OVHkernel
menuentry “Ubuntu 10.04 LTS, OVH kernel 3.2.13-xxxx-grs-ipv6-64” {
linux /bzImage-3.2.13-xxxx-grs-ipv6-64 root=/dev/md2 ro nomodeset
}
END /etc/grub.d/06_OVHkernel
BEGIN /etc/grub.d/10_linux
function gfxmode {
set gfxpayload="${1}"
if [ “${1}” = “keep” ]; then
set vt_handoff=vt.handoff=7
else
set vt_handoff=
fi
}
if [ “${recordfail}” != 1 ]; then
if [ -e ${prefix}/gfxblacklist.txt ]; then
if hwmatch ${prefix}/gfxblacklist.txt 3; then
if [ ${match} = 0 ]; then
set linux_gfx_mode=keep
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=text
fi
else
set linux_gfx_mode=keep
fi
else
set linux_gfx_mode=text
fi
export linux_gfx_mode
if [ “${linux_gfx_mode}” != “text” ]; then load_video; fi
menuentry ‘Ubuntu, avec Linux 3.2.0-61-generic’ --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
linux /vmlinuz-3.2.0-61-generic root=/dev/md2 ro nomodeset
initrd /initrd.img-3.2.0-61-generic
}
menuentry ‘Ubuntu, with Linux 3.2.0-61-generic (recovery mode)’ --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
echo 'Chargement de Linux 3.2.0-61-generic ...'
linux /vmlinuz-3.2.0-61-generic root=/dev/md2 ro recovery nomodeset
echo 'Chargement du disque mémoire initial ...'
initrd /initrd.img-3.2.0-61-generic
}
submenu “Previous Linux versions” {
menuentry ‘Ubuntu, avec Linux 3.2.0-60-generic’ --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
linux /vmlinuz-3.2.0-60-generic root=/dev/md2 ro nomodeset
initrd /initrd.img-3.2.0-60-generic
}
menuentry ‘Ubuntu, with Linux 3.2.0-60-generic (recovery mode)’ --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
echo 'Chargement de Linux 3.2.0-60-generic ...'
linux /vmlinuz-3.2.0-60-generic root=/dev/md2 ro recovery nomodeset
echo 'Chargement du disque mémoire initial ...'
initrd /initrd.img-3.2.0-60-generic
}
menuentry ‘Ubuntu, avec Linux 3.2.0-59-generic’ --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
linux /vmlinuz-3.2.0-59-generic root=/dev/md2 ro nomodeset
initrd /initrd.img-3.2.0-59-generic
}
menuentry ‘Ubuntu, with Linux 3.2.0-59-generic (recovery mode)’ --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod gzio
echo 'Chargement de Linux 3.2.0-59-generic ...'
linux /vmlinuz-3.2.0-59-generic root=/dev/md2 ro recovery nomodeset
echo 'Chargement du disque mémoire initial ...'
initrd /initrd.img-3.2.0-59-generic
}
}
END /etc/grub.d/10_linux
BEGIN /etc/grub.d/20_linux_xen
END /etc/grub.d/20_linux_xen
BEGIN /etc/grub.d/30_os-prober
END /etc/grub.d/30_os-prober
BEGIN /etc/grub.d/30_uefi-firmware
END /etc/grub.d/30_uefi-firmware
BEGIN /etc/grub.d/40_custom
This file provides an easy way to add custom menu entries. Simply type the
menu entries you want to add after this comment. Be careful not to change
the ‘exec tail’ line above.
END /etc/grub.d/40_custom
BEGIN /etc/grub.d/41_custom
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
END /etc/grub.d/41_custom ###[/code]
et mon /mnt/md2/etc/default/grub :[code]# If you change this file, run ‘update-grub’ afterwards to update
/boot/grub/grub.cfg.
GRUB_DEFAULT=2
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian
#GRUB_CMDLINE_LINUX_DEFAULT=“quiet"
GRUB_CMDLINE_LINUX_DEFAULT=“nomodeset"
GRUB_CMDLINE_LINUX=””
Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
The resolution used on graphical terminal
note that you can use only modes which your graphic card supports via VBE
you can see them in real GRUB with the command `vbeinfo’
#GRUB_GFXMODE=640x480
Uncomment if you don’t want GRUB to pass “root=UUID=xxx” parameter to Linux
GRUB_DISABLE_LINUX_UUID=true
Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_LINUX_RECOVERY=“true”
Uncomment to get a beep at grub start
#GRUB_INIT_TUNE=“480 440 1”[/code]
N’étant pas sur à 100%, j’ai essayé aussi avec :GRUB_DEFAULT=3mais ça marche pas mieux…
D’après le contenu de grub.cfg, j’aurais plutôt mis GRUB_DEFAULT=1.
Concernant les erreurs “no such device”, il a peut-être besoin que /proc soit monté dans le chroot ?
Alors, suivant tes conseils j’ai monté :
/procroot@rescue:~# mount -t proc /proc /mnt/md2/procet comme j’avais toujours la même erreur “no such disk” j’ai aussi monté :
/devroot@rescue:~# mount --bind /dev /mnt/md2/dev
/runroot@rescue:~# mount --bind /run /mnt/md2/run
/sysroot@rescue:~# mount -t sysfs /sys /mnt/md2/sys
On vérifie tout ça :root@rescue:/# mount
/dev/md2 on / type ext3 (rw,relatime,errors=continue,barrier=1,data=writeback)
/dev/md1 on /boot type ext3 (rw,relatime,errors=continue,barrier=1,data=writeback)
/proc on /proc type proc (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime,size=10240k,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=197512k,mode=755)
/sys on /sys type sysfs (rw,relatime)
root@rescue:/#
Et là, du coup la màj de Grub fonctionne correctement :root@rescue:/# update-grub
Generating grub.cfg ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Warning: update-grub_lib is deprecated, use grub-mkconfig_lib instead
Found linux image: /boot/bzImage-3.2.13-xxxx-grs-ipv6-64
Found linux image: /boot/vmlinuz-3.2.0-61-generic
Found initrd image: /boot/initrd.img-3.2.0-61-generic
Found linux image: /boot/vmlinuz-3.2.0-60-generic
Found initrd image: /boot/initrd.img-3.2.0-60-generic
Found linux image: /boot/vmlinuz-3.2.0-59-generic
Found initrd image: /boot/initrd.img-3.2.0-59-generic
done
root@rescue:/#
Mais malheureusement au 1er reboot, ça marche toujours pas !
Et la valeur de GRUB_DEFAULT (qui se retrouve en “set default” dans grub.cfg) ? Si je compte bien :
0 = noyau OVH
1 = dernier noyau Ubuntu en mode normal
2 = dernier noyau Ubuntu en mode recovery
Or si la machine répond au ping mais n’a aucun service actif, cela pourrait correspondre à un démarrage en mode recovery.
Pour les erreurs « no such disk », je tenterais de générer un fichier mtab. En considérant que tout est bien monté dans le chroot :
EDIT: lu trop vite, j’avais pas vu que t’avais réussi l’install de grub au final 
Sauf erreur, il me semble que maintenant /etc/mtab est un lien symbolique qui pointe vers /proc/mounts (du moins dans Debian). Or le montage de /proc n’a visiblement pas suffi à supprimer le message. Je pense que c’est /dev qui manquait.
[quote=“PascalHambourg”]Et la valeur de GRUB_DEFAULT (qui se retrouve en “set default” dans grub.cfg) ? Si je compte bien :
0 = noyau OVH
1 = dernier noyau Ubuntu en mode normal
2 = dernier noyau Ubuntu en mode recovery
Or si la machine répond au ping mais n’a aucun service actif, cela pourrait correspondre à un démarrage en mode recovery.[/quote]Ben c’est pour ça que j’ai essayé aussi avec set default=“3” dans /mnt/md2/boot/grub/grub.cfg mais ça marche toujours pas.
Je vais essayer d’autres valeurs, on ne sait jamais…
[quote=“PascalHambourg”]Je pense que c’est /dev qui manquait.[/quote]C’est effectivement le montage de /dev qui a supprimé les “no such disk”, mais après j’ai eu des erreurs “device node not found” !
Le montage de /run n’a rien apporté de plus ou de moins, c’est le montage de /sys qui les a supprimé.
Pour info, je me suis basé sur cette doc.
Good news : j’ai de nouveau la main sur mon serveur par ssh en mode normal ! 
Pour que ça re-fonctionne, j’ai remonté /boot, /proc, /dev, /run et /sys dans le chroot puis j’ai fait une màj :
root@rescue:/# apt-get update && apt-get dist-upgradesuivie d’une ré-install du serveur openssh :
root@rescue:/# apt-get install --reinstall openssh-serverpuis redémarrage en mode normal de la bête et, après un peu moins d’une heure de fsck (je suppose) j’ai reçu deux mails (des scripts /etc/init.d et crontab mis en place précédemment) me prévenant du bon redémarrage du serveur.
Pour info, lors de la màj grub.cfg a été régénéré, alors qu’il n’y a avait que les paquets ifupdown et libxml2 à mettre à jour.
Pourquoi cette régénération, et est-ce elle ou la ré-install (une seconde fois !) d’openssh-server qui a permis que tout re-fonctionne ?
Mystère…
Un grand merci à tous ceux qui m’ont aidé !