Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Advertise on LowEndTalk.com
Converts your OpenVZ VPS to Alpine Linux
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

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

  • psb777psb777 Member

    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
    
    Thanked by 1maverickp
  • Thanks! Was able to recycle an Ubuntu OpenVPN with Alpine. Using 4MB of RAM currently vs 40+ original!

  • rsyncsrsyncs Member
    edited November 2018

    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.

    Thanked by 1LiteServer
  • Nice, but can it run crysis ?

    Thanked by 3Wolveix MasonR jixun
  • How about a better solution... KVM.

  • Isn't alpine the one without GLIBC embedded?

    Tired of LET scams?
    A Moderated forum : https://talk.lowendspirit.com/

  • 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.

  • @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.

    Thanked by 1PrivacyInfinity

    "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)

  • @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?

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

    It is. It uses the "musl" libc.

  • @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.

    "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)

  • @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...

    Thanked by 1maverickp
  • @JoeMerit said:
    How about a better solution... KVM.

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

  • @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.

    Thanked by 1rsyncs
    • do not prepay > 1 year and check for reviews/support
    • only use monthly from a provider operating < 1 year 🍆
  • CoreyCorey Member, Provider

    @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.

    BitAccel - OpenVZ VPS / IRC,VPN,Anything Legal & Unrivaled Support!
  • @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.

    Thanks no.

  • @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.

    Thanked by 1vimalware

    "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)

  • @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 ...

    "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)

  • CyberMondayCyberMonday Member
    edited November 2018

    @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.

    Thanked by 1angstrom

    Own a piece of internets history.

  • 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.

  • CoreyCorey Member, Provider
    edited November 2018

    @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'.

    BitAccel - OpenVZ VPS / IRC,VPN,Anything Legal & Unrivaled Support!
  • @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.

    Own a piece of internets history.

  • 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.

  • Alpine os is cool.

    • do not prepay > 1 year and check for reviews/support
    • only use monthly from a provider operating < 1 year 🍆
  • 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."

  • CoreyCorey Member, Provider

    @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.

    BitAccel - OpenVZ VPS / IRC,VPN,Anything Legal & Unrivaled Support!
  • @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.

    Own a piece of internets history.

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

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

    No.

    Thanked by 1psb777

    "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)

  • jixunjixun Member
    edited August 2019

    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

    Thanked by 1ehab
  • psb777psb777 Member
    edited August 2019

    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.

    Thanked by 1jixun
  • jsgjsg Member
    edited August 2019

    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.

    Thanks no.

  • 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.

  • 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.

  • jsgjsg Member

    @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'.

    Thanks no.

  • @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.

    "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)

  • jsgjsg Member

    @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).

    Thanks no.

  • @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).

    "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)

Sign In or Register to comment.