All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
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/inittaband adding a bunch of respawn getty which will fail and spam your syslog, try making inittab read-only withchattrThanks! 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 || trueand
/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?
See how smoothly updating the OS will go.
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?
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.
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.
No, I wasn't spreading FUD -- just caution to users who aren't sufficiently prepared/determined.
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 ...
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.
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.
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.
It works well on my openvz vps. Can you write script for kvm vps?