Re: OpenVPN fails
Hi.
On Mon, Oct 05, 2015 at 06:15:58PM +0100, Tony van der Hoff wrote:
> On 05/10/15 17:38, Reco wrote:
> > On Mon, Oct 05, 2015 at 05:17:49PM +0100, Tony van der Hoff wrote:
> >>>> Thanks for the quick response, Reco.
> >>>>
> >>>> 1. Kernel is stock wheezy:
> >>>> 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux
> >>>
> >>> But very old one. Current one is 3.2.68-1+deb7u4.
> >>>
> >>> It's a shot in the dark, but - what does this show:
> >>>
> >>> apt-cache policy linux-image-3.2.0-4-amd64
> >>>
> >>
> >> Hm, I don't understand what that means, but here it is:
> >>
> >> root@tony-lx:~# apt-cache policy linux-image-3.2.0-4-amd64
> >> linux-image-3.2.0-4-amd64:
> >> Installed: 3.2.68-1+deb7u4
> >> Candidate: 3.2.68-1+deb7u4
> >> Version table:
> >> *** 3.2.68-1+deb7u4 0
> >> 500 http://security.debian.org/ wheezy/updates/main amd64 Packages
> >> 100 /var/lib/dpkg/status
> >> 3.2.68-1+deb7u3 0
> >> 500 http://ftp.uk.debian.org/debian/ wheezy/main amd64 Packages
> >>
> >> apt-get upgrade isn't offering me anything better, so I guess this is
> >> the correct wheezy kernel.
> >
> > Indeed. And it shows the root cause of a problem (in conjunction with
> > "uname -a") the best way possible.
> >
> > tl;dr version - fix your bootloader.
> >
> > Long version is:
> >
> > - You upgraded your kernel package several times since the initial
> > install, replacing contents of /lib/modules/3.2.0-4-amd64 (where
> > kernel modules reside), /boot/vmlinuz-3.2.0-4-amd64 (kernel itself)
> > and /boot/initrd.img-3.2.0-4-amd64 (initramfs image).
> >
> > - Yet your VPS' bootloader continued to use original (as of
> > installation) kernel and initramfs.
> >
> > Such anomaly did not prevent your VPS from booting - old kernel used old
> > kernel modules (which were put into initramfs at install time) for the
> > boot process.
> >
> > Since apparently your install does not require *that* many modules
> > from outside of initramfs - the problem was unnoticed for the long time.
> >
> > As a "bonus" you are using the kernel with known vulnerabilities, and
> > this goes on for a long time. All your kernel upgrades were silently
> > ignored.
> >
> > So to solve the problem you need to convince whatever thing your VPS
> > uses instead of conventional bootloader to use your current vmlinuz and
> > initrd.img. Don't forget to repeat the process on next kernel upgrade.
> >
> > Alternative way to solve it would be to force rebooting to a "good"
> > kernel with kexec-tools. Big warning is - misusing kexec-tools *will*
> > produce a kernel panic. Hope you have a console access available :)
> >
> > Yet another way would be to migrate from this VPS anywhere they use
> > more-or-less conventional bootloader.
> >
> > Reco
> >
>
>
> Reco, thank you very much for taking the time to explain things, but I
> think we're at cross-purposes. The problem is with my home box, ie the
> client, and all the information above relates to that box. However, I
> guess your comments apply nonetheless. Presumably I need to look at grub
> to fix the boot process.
Oh. I missed that detail. Does not change things much.
Simplifies a console access though :)
> Strangely, the VPS is running the same kernel (3.2.0.4) but tun is
> loading correctly, so I don't think I should be messing with that end.
> It's not had a reboot for a while (uptime: 74 days +).
As long as "uname -v" output is consistent with "apt-cache policy
linux-image-3.2.0-4-amd64" output there's nothing to worry about IMO.
They stopped to change kernel version (i.e. 3.2.0-4) as of Squeeze IIRC,
"because our updates do no change kernel ABI". Since then the full
kernel version ("uname -v") became the only criteria one should check.
As a side note - now we see how stable abovementioned ABI really is.
> You ave me worried about the state of the VPS, however; so maybe the
> simplest solution would be to upgrade to Jessie. I have full root
> access, and an oob console to the box.
Sadly, upgrading to Jessie is not the solution here. If your VPS
provider uses their own gizmo instead of VPS' grub2 (or pvgrub for Xen
environments) - no amount of upgrading will solve the issue.
Reco
Reply to: