New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
No.
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.
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'.
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.
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).
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.
Sorry for bumping old story but could you please share some thoughts the way to convert KVM VPS.
Thanks in advance
If you have VNC access and can mount Alpine ISO, you can use the standard installation method.
If you have VNC access but cannot mount Alpine ISO, you can use netboot.xyz, either with netboot.xyz.iso or boot it from grub (i.e., netboot.xyz.lkrn), and boot Alpine from the menu.
If you do not have VNC access, you can make a prebuilt disk image (e.g., from another VPS or from a VM on your own PC) and have it
dd
'd into your VPS.