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?

angstrom

@jii said:
It works well on my openvz vps. Can you write script for kvm vps?

No.

jixun

TL; DR: add apk add bash before reboot

I installed openvz 7 locally to test it, and found out that the container need to have bash installed to boot.

Otherwise the container will not start.

Initial try:

[[email protected] ~]# prlctl start vm1
Starting the CT...
Failed to start the CT: PRL_ERR_VZCTL_OPERATION_FAILED (Details: bash: applet not found
Failed to start the Container
)
[[email protected] ~]# prlctl reinstall vm1
The CT has been successfully reinstalled.

Add bash before restart:

CT-2e3bf9a3 /# apk add bash
(1/2) Installing readline (8.0.0-r0)
(2/2) Installing bash (5.0.0-r0)
Executing bash-5.0.0-r0.post-install
Executing busybox-1.31.0-r0.trigger
OK: 23 MiB in 32 packages
CT-2e3bf9a3 /# reboot -f
CT-2e3bf9a3 /# Got signal 9
                           [[email protected] ~]# 
[[email protected] ~]# prlctl list -a
UUID                                    STATUS       IP_ADDR         T  NAME
{2e3bf9a3-edff-4e15-8a90-b4184cfeabad}  running      111.222.333.444 CT vm1
[[email protected] ~]# prlctl enter vm1
entered into CT
LXC_NAME:/# uname -r
3.10.0

My modified script (among other modifications): https://gist.github.com/JixunMoe/6d195b2b2369c2cba80425213d3dc2cc

psb777

jixun said: I installed openvz 7 locally to test it, and found out that the container need to have bash installed to boot.

Otherwise the container will not start.

Yeah, I also discovered that a few days ago, but didn't have time to run tests. Seems that OpenVZ 7 introduced some startup scripts for setting up IP addresses in containers that specifically requires bash. Adding bash is the easy workaround.

For the original script, just change line 51 from apk add openssh to apk add openssh bash.

jsg

Translation: the OpenVZ people don't give a damn about their users, probably because they are not engineers but hobbyists.

• 'sh' (which on debian is 'dash') is about 10 times smaller than bash
• 'dash' had 1 vulnerability (severity 6.9, in 2009) while bash has a full page of vulnerabilities up to this year with a couple of severity 10 ones.

If some linux "hackzor" thinks he's cool with his bash script that's one (utterly insignificant) thing, but if someone offers a tool for OS virtualization, even if it's just containers, and uses bash then they should be nailed to a cross and left to bleed shamed.

OpenBSD and some others prove that even all the scripting for an OS can be done with a small and reasonably secure shell.

mountyPython

I used the original script last year on a couple of OVZ6 boxes. I didn't see any reason for it to delete /home, /media and /mnt. So I just modified it. Worked out OK.

psb777

jsg said: Translation: the OpenVZ people don't give a damn about their users, probably because they are not engineers but hobbyists.

In all fairness, the scripts in question were designed for CentOS, on which the presence of bash is expected. Although the system has been replaced with Alpine, OpenVZ continues to assume CentOS and runs respective startup scripts.

OpenVZ 7 ships with startup scripts designed for a range of popular distributions. Maybe some put sh instead of bash after shebang, but I didn't have time to test.

---

mountyPython said: I used the original script last year on a couple of OVZ6 boxes. I didn't see any reason for it to delete /home, /media and /mnt. So I just modified it. Worked out OK.

You're right, no reason to delete those directories.

jsg

@psb777 said:
In all fairness, the scripts in question were designed for CentOS, on which the presence of bash is expected. Although the system has been replaced with Alpine, OpenVZ continues to assume CentOS and runs respective startup scripts.

It's even worse. It seems that /bin/sh is just a link to /bin/bash on CentOS which is a particularly poor (and not necessary) decision. For me that's a reason to avoid CentOS.

Alpine Linux' 'sh' is 'ash' which is much more reasonable. For the sake of fairness it should be noted that that shell is part of busybox, which has just a slightly better vulnerabilities track record than bash but all its vulnerabilites are related to diverse pieces of code they picked up who knows where and not to its 'ash'.

angstrom

@jsg said: It seems that /bin/sh is just a link to /bin/bash on CentOS which is a particularly poor (and not necessary) decision. For me that's a reason to avoid CentOS.

If bash is invoked as sh or with the flag --posix, then bash behaves in a POSIX-compliant way. (See https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html )

Also, it's good practice not to use bash-specific mechanisms in any script headed by #!/bin/sh.

This said, I also would prefer not to link sh to bash, so we're in agreement about this.

jsg

@angstrom said:
If bash is invoked as sh or with the flag --posix, then bash behaves in a POSIX-compliant way.

Well, kind of. It (supposedly) behaves in a POSIX-compliant way. But - important caveat! - it still is bash and just "emulating" Posix compliance.

We should keep in mind that a basic shell ("/bin/sh") is a vital part of an OS and should hence be very well behaved, small, fast, and of course safe - which bash is not, and that doesn't somehow magically change by calling it with some option.

Well noted, I'm not per se against bash, zsh, and a whole lot of other shells - what I'm strongly opposed to is to misuse them as /bin/sh and/or for critical scripting (like in the init mechanism).

angstrom

@jsg said:

@angstrom said:
If bash is invoked as sh or with the flag --posix, then bash behaves in a POSIX-compliant way.

Well, kind of. It (supposedly) behaves in a POSIX-compliant way. But - important caveat! - it still is bash and just "emulating" Posix compliance.

We should keep in mind that a basic shell ("/bin/sh") is a vital part of an OS and should hence be very well behaved, small, fast, and of course safe - which bash is not, and that doesn't somehow magically change by calling it with some option.

Well noted, I'm not per se against bash, zsh, and a whole lot of other shells - what I'm strongly opposed to is to misuse them as /bin/sh and/or for critical scripting (like in the init mechanism).

Well, if bash isn't POSIX-compliant when invoked as sh or with the posix flag, then this would be a bug in bash.

But, yes, it would be safer to use (real) sh to begin with.

I suspect that the startup scripts in CentOS use /bin/sh and so don't use bash-specific features (but I would have to check to be sure).

liuyinltemp

hello,the great script donot support Ipv6? I just have a ipv6 only little openvz7 vps .
how can I change the script to converts my ipv6 only openvz vps to Alpine ?

cochon

@liuyinltemp said:
hello,the great script donot support Ipv6? I just have a ipv6 only little openvz7 vps .
how can I change the script to converts my ipv6 only openvz vps to Alpine ?

The script creates a stub IPv4 network configuration from the existing state, but I've always used Debian as the donor system, it has the same format interfaces file as Alpine, and relied on the interfaces file being recreated (including IPv6) by the host scripts at boot. Never had to configure IPv6 manually after the final reboot to log back in over v6.

Sounds like your network configuration may not be recreated automatically. You could try editing this upgrade script to copy your existing interfaces file instead of building the stub.

I've also not tried it on a system without NAT as a fallback, so it's possible the linuxcontainers.org template doesn't work without an IPv4 address, you could try the above adding a dummy IPv4 address to the interfaces file.

As you've probably discovered, the script also needs a bit of a tweak to pick up later versions of Alpine >3.9 due to the way the linuxcontainers.org list is sorted.

Edit: Forget the last comment, I see they've dropped the older versions < 3.10, though looks like this script will always pick 'edge' now for the same reason.

liuyinltemp

@cochon said:

@liuyinltemp said:
hello,the great script donot support Ipv6? I just have a ipv6 only little openvz7 vps .
how can I change the script to converts my ipv6 only openvz vps to Alpine ?

The script creates a stub IPv4 network configuration from the existing state, but I've always used Debian as the donor system, it has the same format interfaces file as Alpine, and relied on the interfaces file being recreated (including IPv6) by the host scripts at boot. Never had to configure IPv6 manually after the final reboot to log back in over v6.

Sounds like your network configuration may not be recreated automatically. You could try editing this upgrade script to copy your existing interfaces file instead of building the stub.

I've also not tried it on a system without NAT as a fallback, so it's possible the linuxcontainers.org template doesn't work without an IPv4 address, you could try the above adding a dummy IPv4 address to the interfaces file.

As you've probably discovered, the script also needs a bit of a tweak to pick up later versions of Alpine >3.9 due to the way the linuxcontainers.org list is sorted.

Edit: Forget the last comment, I see they've dropped the older versions < 3.10, though looks like this script will always pick 'edge' now for the same reason.

Thanks ,I just found this script can run on debian 6 but no on centos 5

psb777

@cochon said: though looks like this script will always pick 'edge' now for the same reason.

It won't. 'edge' is filtered out with grep.

cochon

@psb777 said:

@cochon said: though looks like this script will always pick 'edge' now for the same reason.

It won't. 'edge' is filtered out with grep.

Ah yes, thanks, need to get my eyesight tested

Previously I always had to edit the script to cherry pick > 3.9 so never assimilated that.