Converts your OpenVZ VPS to Alpine Linux
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.
Comments
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 withchattr
Thanks! Was able to recycle an Ubuntu OpenVPN with Alpine. Using 4MB of RAM currently vs 40+ original!
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.
Thanks for the script, I successfully used it on a Liteserver OVZ box.
Nice, but can it run crysis ?
How about a better solution... KVM.
Isn't alpine the one without GLIBC embedded?
10gbit premium KVM in AMS, launching in 10..9...8....
(affiliate for 🥰 ) https://clients.inceptionhosting.com/aff.php?aff=401&gid=33
See how smoothly updating the OS will go.
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
should I use it on my 4GB RAM VPS?
You're so tight, baby.
I wouldn't. Sooner or later (and very probably sooner), the updates will break the system.
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
Why would updates break the system?
It is. It uses the "musl" libc.
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.
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
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...
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.
Why not remove getty? How would an openvz host 'keep modifying /etc/inittab'. That's your inittab, not theirs.
@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.
The problem with democracy is that by definition > 85% of the voters are not particularly intelligent.
No, I wasn't spreading FUD -- just caution to users who aren't sufficiently prepared/determined.
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
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 ...
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
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.
Own a piece of internets history.
No, the kernel and its modules are not installed in the first place, because the base image is for containers (albeit LXC).
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.
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'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.
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.
Thanks for the commit link. I stand corrected and outdated.
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.
Own a piece of internets history.
For any one who is confused, you need to comment out
lines like
in /etc/inittab
then
I have never used alpine before, spend a few hours to install a WordPress on it, like it's simple command and package.
Alpine os is cool.
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."
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.
Own a piece of internets history.
It works well on my openvz vps. Can you write script for kvm vps?
No.
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
TL; DR: add
apk add bash
beforereboot
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:
Add bash before restart:
My modified script (among other modifications): https://gist.github.com/JixunMoe/6d195b2b2369c2cba80425213d3dc2cc
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
toapk add openssh bash
.Translation: the OpenVZ people don't give a damn about their users, probably because they are not engineers but hobbyists.
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 bleedshamed.OpenBSD and some others prove that even all the scripting for an OS can be done with a small and reasonably secure shell.
The problem with democracy is that by definition > 85% of the voters are not particularly intelligent.
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.
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.
You're right, no reason to delete those directories.
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'.
The problem with democracy is that by definition > 85% of the voters are not particularly intelligent.
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.
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
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).
The problem with democracy is that by definition > 85% of the voters are not particularly intelligent.
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).
"Linux will run happily with only 4 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 32)
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
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.