Converts your OpenVZ VPS to Alpine Linux

psb777

For some reasons, I still have to manage a handful of OpenVZ VPS. But I don't like the popular OSes that most providers offer, because they could be messy, heavy and outdated. I used to use vps2arch, which wipes out the original OS, and installs Arch Linux. But now that Arch Linux no longer supports the old VZ kernels, Alpine Linux seems to be a sensible choice.

So I made a script to install the latest Alpine Linux on OpenVZ VPS.

https://gist.github.com/trimsj/c1fefd650b5f49ceb8f3efc1b6a1404d

NOTE: The script will wipe all your data in the VPS! It only supports OpenVZ, because there usually are better ways to install your favourite OS on KVM. IPv6 is not supported, and should be manually configured. Vanilla Alpine Linux uses about 8MB RAM and 36MB disk, and it is systemd-free.

I tested it on vanilla 64-bit CentOS 7, Debian 8, and Ubuntu 16.04 images on an NAT OpenVZ VPS provided by @Cam (thanks!). It may or may not work on your OpenVZ however, so be prepared to reinstall OS and improvise.

psb777

In case your OpenVZ host keeps modifying /etc/inittab and adding a bunch of respawn getty which will fail and spam your syslog, try making inittab read-only with chattr

apk add e2fsprogs-extra
chattr +i /etc/inittab

daxterfellowes

Thanks! Was able to recycle an Ubuntu OpenVPN with Alpine. Using 4MB of RAM currently vs 40+ original!

rsyncs

Thanks, nice script.
Confirmed to partially work on Ubuntu 14.04 Trusty with 2.6 kernel.
Everything despite
find / \( ! -path '/dev/*' -and ! -path '/proc/*' -and ! -path '/sys/*' -and ! -path '/x/*' \) -delete || true
and
/x/lib/ld-musl-x86_64.so.1 /x/bin/busybox cp -a /x/* /
worked fine. After the reboot, the /x directory "disapperead", and so far everything works as intended.

bjo

Thanks for the script, I successfully used it on a Liteserver OVZ box.

yokowasis

Nice, but can it run crysis ?

JoeMerit

How about a better solution... KVM.

vimalware

Isn't alpine the one without GLIBC embedded?

angstrom

See how smoothly updating the OS will go.

creep

should I use it on my 4GB RAM VPS?

angstrom

@creep said:
should I use it on my 4GB RAM VPS?

I wouldn't. Sooner or later (and very probably sooner), the updates will break the system.

psb777

@angstrom said:

@creep said:
should I use it on my 4GB RAM VPS?

I wouldn't. Sooner or later (and very probably sooner), the updates will break the system.

Why would updates break the system?

psb777

@vimalware said:
Isn't alpine the one without GLIBC embedded?

It is. It uses the "musl" libc.

angstrom

@psb777 said:

@angstrom said:

@creep said:
should I use it on my 4GB RAM VPS?

I wouldn't. Sooner or later (and very probably sooner), the updates will break the system.

Why would updates break the system?

Well, if it works for you, and updating your Alpine system regularly is unproblematic, then what can I say ... I just wouldn't recommend this path to someone who isn't already completely determined.

psb777

@angstrom said:

@psb777 said:

@angstrom said:

@creep said:
should I use it on my 4GB RAM VPS?

I wouldn't. Sooner or later (and very probably sooner), the updates will break the system.

Why would updates break the system?

Well, if it works for you, and updating your Alpine system regularly is unproblematic, then what can I say ... I just wouldn't recommend this path to someone who isn't already completely determined.

I'd say I wouldn't recommend it to anyone who can't fix the system if and when it breaks. What I don't get is why system updates will be the cause. You think the package manager will misbehave because the base system is installed in such an "unconventional" way?

With respect, that sounds like fear, uncertainty and doubt to be... I can't make any promise though, but updating the system works for me at least...

rsyncs

@JoeMerit said:
How about a better solution... KVM.

OVZ has real use cases. So you can't say it's generally better.

ehab

@rsyncs said:
OVZ has real use cases. So you can't say it's generally better.

the only thing i am using with my last 3 OVZ is rsync... this is true.

Corey

@psb777 said:
In case your OpenVZ host keeps modifying /etc/inittab and adding a bunch of respawn getty which will fail and spam your syslog, try making inittab read-only with chattr

apk add e2fsprogs-extra
chattr +i /etc/inittab

Why not remove getty? How would an openvz host 'keep modifying /etc/inittab'. That's your inittab, not theirs.

jsg

@psb777 @angstrom said:

Alpine has a package manager so even an unexperienced user can (to quite some degree) act as if he was using e.g. debian. (s)he can just package install their nginx, php or whatever and ignore the fact that musl is used rather than glibc.

angstrom

@psb777 said: With respect, that sounds like fear, uncertainty and doubt to be... I can't make any promise though, but updating the system works for me at least...

No, I wasn't spreading FUD -- just caution to users who aren't sufficiently prepared/determined.

angstrom

@jsg said:
@psb777 @angstrom said:

Alpine has a package manager so even an unexperienced user can (to quite some degree) act as if he was using e.g. debian. (s)he can just package install their nginx, php or whatever and ignore the fact that musl is used rather than glibc.

To me, it simply seems delicate/tricky to install Alpine Linux on top of Ubuntu or Debian or CentOS on OpenVZ, and judging from a couple of the comments above, it is a little delicate/tricky.

But if it works well enough for someone, then heck, okay, if this is what the person wants ...

CyberMonday

@Corey said:
Why not remove getty? How would an openvz host 'keep modifying /etc/inittab'. That's your inittab, not theirs.

I'm guessing you've never managed OpenVZ services. There are recipies for starting up services which are completely external to the users' subsystem, and many of them do prechecks/rewrites before bringing up the supplicant. If you have an IP change or even just reboot the system, there's a good chance the running inittab is used as often as the no-longer-exists fstab.

---

OP, that's a cute way to write-through a functional subsystem, but you certainly want to block kernel, module, etc updates, and with Alpine being based on anti-stack-smashing code and a completely proprietary kernel build, I wouldn't expect it to be secure, or to do many things which Alpine would assume to be standard.

psb777

CyberMonday said: but you certainly want to block kernel, module, etc updates

No, the kernel and its modules are not installed in the first place, because the base image is for containers (albeit LXC).

CyberMonday said: with Alpine being based on anti-stack-smashing code and a completely proprietary kernel build, I wouldn't expect it to be secure, or to do many things which Alpine would assume to be standard.

None of these user space protections (SSP for instance) require any "proprietary kernel build" to work, nor does Alpine "assumes" such kernels. The Alpine user-space has been extensively used inside containers (dockers) unproblematically. I won't expect it to be more secure than Ubuntu, but afaict it is at least as secure.

In case you're not aware, Alpine has dropped the hardened kernels.

Corey

@CyberMonday said:

@Corey said:
Why not remove getty? How would an openvz host 'keep modifying /etc/inittab'. That's your inittab, not theirs.

I'm guessing you've never managed OpenVZ services. There are recipies for starting up services which are completely external to the users' subsystem, and many of them do prechecks/rewrites before bringing up the supplicant. If you have an IP change or even just reboot the system, there's a good chance the running inittab is used as often as the no-longer-exists fstab.

---

OP, that's a cute way to write-through a functional subsystem, but you certainly want to block kernel, module, etc updates, and with Alpine being based on anti-stack-smashing code and a completely proprietary kernel build, I wouldn't expect it to be secure, or to do many things which Alpine would assume to be standard.

Just because they 'could' doesn't mean they should or have been. What does my response have to do with never managing OpenVZ services? I guess I should have said 'why' not 'how'.

CyberMonday

@psb777 said:

CyberMonday said: but you certainly want to block kernel, module, etc updates

No, the kernel and its modules are not installed in the first place, because the base image is for containers (albeit LXC).

I'm quite aware of that; I was speaking of this possibly being mistaken and confused by the end-user who can cut-and-paste things, but doesn't understand precisely how they work. This is the OVZ user paradigm.

CyberMonday said: with Alpine being based on anti-stack-smashing code and a completely proprietary kernel build, I wouldn't expect it to be secure, or to do many things which Alpine would assume to be standard.

None of these user space protections (SSP for instance) require any "proprietary kernel build" to work, nor does Alpine "assumes" such kernels. The Alpine user-space has been extensively used inside containers (dockers) unproblematically. I won't expect it to be more secure than Ubuntu, but afaict it is at least as secure.

No, but you shouldn't expect them to always work, either. The fact that there is no specific sub-build for OVZ, and their is for LXC, just shows what the current plan and design is for. Using a single sed statement after untarring the base over an existing config doesn't mean it's going to work in the future, as already forewarned, even if it was in a "unmitigated disaster" sort of way.

In case you're not aware, Alpine has dropped the hardened kernels.

Thanks for the commit link. I stand corrected and outdated.

@Corey said:
Just because they 'could' doesn't mean they should or have been. What does my response have to do with never managing OpenVZ services? I guess I should have said 'why' not 'how'.

I was speaking purely from the "managing this hypervisor through SolusVM, which is also awful" stance. Whatever you homebrew or choose do outside of the most common implementation in this market was not taken under consideration.

hiphiphip0

For any one who is confused, you need to comment out
lines like

respawn:/sbin/getty 38400 console
respawn:/sbin/getty 38400 tty2

in /etc/inittab
then

chattr +i /etc/inittab

I have never used alpine before, spend a few hours to install a WordPress on it, like it's simple command and package.

ehab

Alpine os is cool.

psb777

CyberMonday said: No, but you shouldn't expect them to always work, either.

In case you're not aware, Alpine has dropped the hardened kernels.

Thanks for the commit link. I stand corrected and outdated.

I'd say the chances of safely updating the OS until Alpine 3.8 goes EOL are very good, but you're definitely correct in that no one should expect updates to work forever. Nothing works forever, for that matter.

What I didn't understand or agree, however, was where Alpine's functionality or security relies on a "proprietary kernel build." Because I couldn't think of any examples where Alpine (compared to other distros) fails to function or became less secure because the OpenVZ kernel or environment wasn't something Alpine "assumed."

Corey

@Corey said:
Just because they 'could' doesn't mean they should or have been. What does my response have to do with never managing OpenVZ services? I guess I should have said 'why' not 'how'.

@CyberMonday said:
I was speaking purely from the "managing this hypervisor through SolusVM, which is also awful" stance. Whatever you homebrew or choose do outside of the most common implementation in this market was not taken under consideration.

Since when does solusvm modify the inittab? I have tons vms running on solusvm with an unmodified inittab. I know vanilla openvz doesn't do this either unless configured to do so like you stated.

CyberMonday

@Corey said:

Since when does solusvm modify the inittab? I have tons vms running on solusvm with an unmodified inittab. I know vanilla openvz doesn't do this either unless configured to do so like you stated.

I wasn't claiming that it modified the inittab- just that you can't expect customizations for init-related things to not be modified, because there is no functional init before it spawns to the supplicant. Any time someone clicks "reconfig", several files have the possibility of being destroyed/overwritten.

Also, if your getty is respawning too often, well, it's obviously not attaching since there is no actual console- or you really, really pooched it.

jii

It works well on my openvz vps. Can you write script for kvm vps?