Fli
04-14-2016, 12:42 PM
If OVH/Kimsufi/SoYouStart server is not accessible via SSH or via server control panel like Webmin (if you installed it before), one can try to ping the server ip (ping 1.2.3.4) to see if server responding to the ping. If not, then conntact server provider. If it responds, then one can try to access server from other IP (from other computer) or try to discover if server provider offer some remote console for access (IPMI,DRAC,KVM/IP) if no possibility of access (like on Kimsufi), one can try to reboot server in hope it will fix the connection issue.
If after reboot there is still no way to connect, another solution to access filesystem is the Rescue system of the OVH/Kimsufi/SoYouStart.
Go to your OVH Manager (client area), then select server, choose Netboot and then choose Rescue and then select Rescue-Pro.
Then hard reboot the server to get into rescue mode.
After a few minutes you will receive an email with Rescue mode access details.
Here is the OVH tutorial (with images) on how to work with rescue mode: http://help.ovh.com/RescueMode
You can access rescue system via web or via SSH.
SSH details should be same except password which is the rescue mode password just received via email.
After SSH login one should mount the correct partition.
I did "fdisk -l" command to show partitions.
/dev/sda1 40 2048 2009 1004.5K BIOS boot
/dev/sda2 4096 40962047 40957952 19.5G Linux filesystem
/dev/sda3 40962048 3905974271 3865012224 1.8T Linux filesystem
/dev/sda4 3905974272 3907020799 1046528 511M Linux swap
I decided that the Linux system partition is /dev/sda2 so i mounted it by command "mount /dev/sda2 /mnt/hd" and then did chroot command: "chroot /mnt/hd"
Now i see im in the correct filesystem. You can do "history" to veriffy you see history of non rescue server. And now you can manipulate your real (non rescue) filesystem as you please.
Example veriffy /etc/ssh/sshd_config file, edit iptables (someone adviced flushing (iptables -F) if it contains rules that blocking SSH access in non rescue mode. I assume after flushing the iptables (only if you are sure it is necessary) "iptables-save" command should be run. But flush it only if you are sure you want, iptables might not be cause of the failed connectivity.
One may also probably backup data using SCP over SSH.
-----
BTW, here are another set of commands (executed in OVH/Kimsufi recovery mode) that helped to recover connectivity to the server:
sudo mount /dev/sda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo chroot /mnt
apt-get purge ufw
exit
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
sudo umount /mnt
reboot
("apt-get purge ufw" was actual task needed to be done in mounted chrooted filesystem - remove firewall that caused block out)
If after reboot there is still no way to connect, another solution to access filesystem is the Rescue system of the OVH/Kimsufi/SoYouStart.
Go to your OVH Manager (client area), then select server, choose Netboot and then choose Rescue and then select Rescue-Pro.
Then hard reboot the server to get into rescue mode.
After a few minutes you will receive an email with Rescue mode access details.
Here is the OVH tutorial (with images) on how to work with rescue mode: http://help.ovh.com/RescueMode
You can access rescue system via web or via SSH.
SSH details should be same except password which is the rescue mode password just received via email.
After SSH login one should mount the correct partition.
I did "fdisk -l" command to show partitions.
/dev/sda1 40 2048 2009 1004.5K BIOS boot
/dev/sda2 4096 40962047 40957952 19.5G Linux filesystem
/dev/sda3 40962048 3905974271 3865012224 1.8T Linux filesystem
/dev/sda4 3905974272 3907020799 1046528 511M Linux swap
I decided that the Linux system partition is /dev/sda2 so i mounted it by command "mount /dev/sda2 /mnt/hd" and then did chroot command: "chroot /mnt/hd"
Now i see im in the correct filesystem. You can do "history" to veriffy you see history of non rescue server. And now you can manipulate your real (non rescue) filesystem as you please.
Example veriffy /etc/ssh/sshd_config file, edit iptables (someone adviced flushing (iptables -F) if it contains rules that blocking SSH access in non rescue mode. I assume after flushing the iptables (only if you are sure it is necessary) "iptables-save" command should be run. But flush it only if you are sure you want, iptables might not be cause of the failed connectivity.
One may also probably backup data using SCP over SSH.
-----
BTW, here are another set of commands (executed in OVH/Kimsufi recovery mode) that helped to recover connectivity to the server:
sudo mount /dev/sda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo chroot /mnt
apt-get purge ufw
exit
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
sudo umount /mnt
reboot
("apt-get purge ufw" was actual task needed to be done in mounted chrooted filesystem - remove firewall that caused block out)