[sandygws]

Ok, the OVH techs have got the box back up and it's running on the stock modular kernel:

:~$ uname -a

Linux xxxxxx.ovh.net 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

OpenVPN is also (kind of) running - but I still can't connect:

ps aux | grep openvpn

Linux xxxxxx.ovh.net 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
root 2624 0.3 0.5 206416 45960 ? S 18:20 0:01 python -c from pyovpn.sagent.sagent _entry import openvpnas ; openvpnas() --logfile=/var/log/openvpnas.log --pidfile=/var/run/openvpnas. pid
1003 2708 0.0 0.0 36068 3272 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
1003 2721 0.0 0.0 36068 3272 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
1003 2732 0.0 0.0 36068 3280 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
1003 2743 0.0 0.0 36068 3272 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
1003 2754 0.0 0.0 36064 3280 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
1003 2765 0.0 0.0 36064 3280 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
1003 2777 0.0 0.0 36064 3284 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
1003 2788 0.0 0.0 36064 3280 ? S 18:20 0:00 openvpn --errors-to-stderr --config stdin
xxxxxxxx 3416 0.0 0.0 10376 892 pts/0 S+ 18:27 0:00 grep openvpn

What should I troubleshoot next?

[sandygws]

I followed Myatu's guide here http://forum.ovh.co.uk/showthread.php?t=5616 and changed the default grub to 1

:~# fgrep menuentry /boot/grub/grub.cfg

menuentry "Debian GNU/Linux, OVH kernel 3.10.9-xxxx-grs-ipv6-64" {
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (recovery mode)' --class debian --class gnu-linux --class gnu --class os {
menuentry "Debian GNU/Linux, OVH kernel 3.10.9-xxxx-grs-ipv6-64 (on /dev/sdb1)" --class gnu-linux --class gnu --class os {

I then did update-grub

Generating grub.cfg ...
Found linux image: /boot/bzImage-3.10.9-xxxx-grs-ipv6-64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
No volume groups found
Found Debian GNU/Linux (7.1) on /dev/sdb1
done

But after rebooting, the server is now inaccessible and I have just received the 'Defect' email.

What next?

[K.Kode]

linux-image-amd64 will install the latest 64bit kernel

[sandygws]

Yes, I found his post.

:~# apt-cache search linux-image

alsa-base - ALSA driver configuration files
linux-headers-3.2.0-4-486 - Header files for Linux 3.2.0-4-486
linux-headers-3.2.0-4-686-pae - Header files for Linux 3.2.0-4-686-pae
linux-headers-3.2.0-4-amd64 - Header files for Linux 3.2.0-4-amd64
linux-headers-3.2.0-4-rt-686-pae - Header files for Linux 3.2.0-4-rt-686-pae
linux-headers-3.2.0-4-rt-amd64 - Header files for Linux 3.2.0-4-rt-amd64
linux-image-3.2.0-4-486 - Linux 3.2 for older PCs
linux-image-3.2.0-4-686-pae - Linux 3.2 for modern PCs
linux-image-3.2.0-4-686-pae-dbg - Debugging symbols for Linux 3.2.0-4-686-pae
linux-image-3.2.0-4-amd64 - Linux 3.2 for 64-bit PCs
linux-image-3.2.0-4-amd64-dbg - Debugging symbols for Linux 3.2.0-4-amd64
linux-image-3.2.0-4-rt-686-pae - Linux 3.2 for modern PCs, PREEMPT_RT
linux-image-3.2.0-4-rt-686-pae-dbg - Debugging symbols for Linux 3.2.0-4-rt-686-pae
linux-image-3.2.0-4-rt-amd64 - Linux 3.2 for 64-bit PCs, PREEMPT_RT
linux-image-3.2.0-4-rt-amd64-dbg - Debugging symbols for Linux 3.2.0-4-rt-amd64
linux-image-2.6-486 - Linux for older PCs (dummy package)
linux-image-2.6-686 - Linux for modern PCs (dummy package)
linux-image-2.6-686-bigmem - Linux for PCs with 4GB+ RAM (dummy package)
linux-image-2.6-686-pae - Linux for modern PCs (dummy package)
linux-image-2.6-amd64 - Linux for 64-bit PCs (dummy package)
linux-image-486 - Linux for older PCs (meta-package)
linux-image-686 - Linux for modern PCs (dummy package)
linux-image-686-bigmem - Linux for PCs with 4GB+ RAM (dummy package)
linux-image-686-pae - Linux for modern PCs (meta-package)
linux-image-amd64 - Linux for 64-bit PCs (meta-package)
linux-image-rt-686-pae - Linux for modern PCs (meta-package), PREEMPT_RT
linux-image-rt-amd64 - Linux for 64-bit PCs (meta-package), PREEMPT_RT


No idea which one to select for a Debian 7 x64 install though

[K.Kode]

On Debian it's pretty straight forward to install a stock kernel directly from the repos, check the how-to's Myatu made a post on it somewhere.

[sandygws]

I have no problem updating/changing the kernel on the server, but it's something I have never done before and I'd hate to lose more than 5TB of data by screwing it up

How straightforward would it be to change/update the server kernel?

[K.Kode]

OpenVPN is running but the webserver component is not (the core VPN technology is the same, its the webserver that differentiates the access server), you should be seeing cserv / wserv running too. You'll get more information from the openvpnas.log but from experience the kernel is the issue.

[sandygws]

uname -a; ps aux | grep openvpn

Linux xxxxxxxx.ovh.net 3.10.9-xxxx-grs-ipv6-64 #1 SMP Wed Aug 21 11:51:59 CEST 2013 x86_64 GNU/Linu x
root 8715 1.1 0.5 208408 46048 ? S 16:51 0:00 python -c from pyovpn.sagent.sagent _entry import openvpnas ; openvpnas() --logfile=/var/log/openvpnas.log --pidfile=/var/run/openvpnas. pid
1003 8746 0.0 0.0 36064 3428 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8753 0.0 0.0 35928 844 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8758 0.0 0.0 36068 3436 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8761 0.0 0.0 35920 844 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8770 0.0 0.0 36068 3440 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8773 0.0 0.0 35920 848 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8782 0.0 0.0 36068 3436 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8785 0.0 0.0 35920 844 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8794 0.0 0.0 36060 3276 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8805 0.0 0.0 36064 3280 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8816 0.0 0.0 36064 3280 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
1003 8827 0.0 0.0 36064 3280 ? S 16:51 0:00 openvpn --errors-to-stderr --config stdin
root 8935 0.0 0.0 10376 896 pts/0 S+ 16:53 0:00 grep openvpn

[sandygws]

No, the service starts fine:

:~# /etc/init.d/openvpnas start
[ ok ] Starting openvpnas: openvpnas.

[aeh]

To confirm, when using the standard HD Boot, OpenVPN is definitely running:



So you must be correct about the kernel suggestion

? All it is finding is you running the grep, no actual OpenVPN services. If you start the service manually do you get any errors? i.e. /etc/init.d/ start (or whatever it is called, also assuming you have an init script for it)

If you need to you can replace the kernel with a stock one and update grub as necessary, you don't need to use OVH's automated system.

[sandygws]

To confirm, when using the standard HD Boot, OpenVPN is definitely running:

:~$ uname -a; ps aux | grep openvpn
Linux xxxxxxx.ovh.net 3.10.9-xxxx-grs-ipv6-64 #1 SMP Wed Aug 21 11:51:59 CEST 2013 x86_64 GNU/Linux
user 5834 0.0 0.0 10372 896 pts/0 S+ 16:02 0:00 grep openvpn

So you must be correct about the kernel suggestion

[sandygws]

Same problem ... grrr.

Which usually gets a faster response: a ticket or an incident thread?

[sandygws]

Ok, trying the HZ_1000 kernel now.

If neither work, I'll open a ticket. At least we're getting closer to the root of the initial problem!

[K.Kode]

Yes, try booting into the 1000Hz kernel just to be sure.
I'd open a ticket / incident thread though if you're unable to boot from it.

[sandygws]

Changed to HD and rebooted and the server came back online.

Then I swapped back to Netboot and rebooted again. The server simply doesn't respond when Netboot is selected: SSH times out, etc.

A few minutes later and again I receive the 'Our monitoring system, has just detected a defect on your server'.

Could this mean there is indeed a problem that is preventing the server from booting in Network kernel mode?

[sandygws]

Netboot state :
Kernel : 3.10.9
Processor : x86_64
Root : /dev/md1
Options : ipv6
smp

Rebooted the server and now I just received the 'Our monitoring system, has just detected a defect on your server' email!

Guess I need to wait now.

[aeh]

Can you verify that the relevant services are running? In case it is dying upon startup.

Might be worth checking netstat to verify that it is indeed binding on 943 as well.

[K.Kode]

first confirm kernel version and openvpn_as are running (uname -a; ps aux | grep openvpn)

[sandygws]

Done, but still no go

How do I check if the correct ports (tcp 943 and udp 1194) are indeed open and accessible?

nmap is showing both ports as closed:

Starting Nmap 6.00 ( http://nmap.org ) at 2013-11-04 14:52 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000062s latency).
rDNS record for 127.0.0.1: localhost.localdomain
PORT STATE SERVICE
1194/udp closed openvpn


Starting Nmap 6.00 ( http://nmap.org ) at 2013-11-04 14:54 CET
Nmap scan report for xxxxxx.ovh.net (xx.xx.xx.xx)
Host is up (0.00032s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
113/tcp open ident
443/tcp open https

[K.Kode]

Go to to the OVH manager, select the server > Services > Netboot > and select the stock kernel (without grsec) from the drop down, for Debian it should currently be 3.10.9 then reboot the server.



Your webserver is not currently running so all the iptables-fu in the world won't get it accessible

[sandygws]

Yes, it's the web server that is the problem.

I tried to open tcp port 943 using 'sudo iptables -I INPUT -m tcp -p tcp --dport 943 -j ACCEPT', but the web server is still not responding.

So if the issue is the static OVH kernel stopping the web server from running, how do I boot from 'Stock network kernel' .. and could this damage my data in any way?

[K.Kode]

It's not the port that is the issue it's the static OVH kernel stopping the access server web server from running.
Install stock modular kernel from repos or boot from stock network kernel and you should be good to go.

[aeh]

Looks like you are running debian.

Even easier for managing iptables is to install ufw, then run ufw allow 943/udp after enabling it to open UDP 943.

Also.. if it is for the web server part you need TCP open, not UDP.

[SRT]

To open port udp 943, run the following command:

sudo iptables -I INPUT -m udp -p udp --dport 943 -j ACCEPT

[sandygws]

wget http://swupdate.openvpn.org/as/openv...an7.amd_64.deb
sudo dpkg -i openvpn-as-2.0.2-Debian7.amd_64.deb
Unpacking openvpn-as (from openvpn-as-2.0.2-Debian7.amd_64.deb) ...
Setting up openvpn-as (2.0.2-Debian7) ...
The Access Server has been successfully installed in /usr/local/openvpn_as
Configuration log file has been written to /usr/local/openvpn_as/init.log

Access Server web UIs are available here:
Admin UI: https://xx.xx.xx.xx:943/admin

Only problem is .. can't connect.

Do I need to open udp port 943? If so, how do I do that?