If you could not use a package manager e.g. yum/apt what which OS would you choose?

InceptionHosting

As per the title, what would be your OS of choice and why if package managers were not available due to lack of ram?

Personally I think I might be tempted to actually go for FreeBSD.

Asking because I am considering putting up some mini containers free for community members that pass certain landmarks but in order to automate the crap out of it so it is very light touch management I am only going to offer a single OS.

Mr_Tom

Slackware, as that's what I always used to use, or OpenBSD I think

InceptionHosting

hmm never considered slack, might see if its even remotely possible to build a vz7 template for slack yet (ever)

InceptionHosting

It would seem not

Mr_Tom

Why is it not possible? Does it depend on what the host kernel supports? Never really done anything with vz7 like that

InceptionHosting

@Mr_Tom said:
Why is it not possible? Does it depend on what the host kernel supports? Never really done anything with vz7 like that

Well I mean it might be possible, but there is no EZ template package for it yet so the entire structure needs to be setup.

VZ7 is very different, you cant just hand it a tar ball and say "off you go!"

Currently it nativity handles:

centos-6-x86_64-ez.noarch : Centos 6 (for AMD64/Intel EM64T) Template set
centos-7-x86_64-ez.noarch : Centos 7 (for AMD64/Intel EM64T) Template set
centos-8-x86_64-ez.noarch : Centos 8 (for AMD64/Intel EM64T) Template set
debian-10.0-x86_64-ez.noarch : Debian 10.0 (for AMD64/Intel EM64T) Template set
debian-7.0-x86_64-ez.noarch : Debian 7.0 (for AMD64/Intel EM64T) Template set
debian-8.0-x86_64-ez.noarch : Debian 8.0 (for AMD64/Intel EM64T) Template set
debian-9.0-x86_64-ez.noarch : Debian 9.0 (for AMD64/Intel EM64T) Template set
fedora-23-x86_64-ez.noarch : Fedora 23 (for AMD64/Intel EM64T) Template set
sles-11-x86_64-ez.noarch : SUSE Linux Enterprise Server 11 (for AMD64/Intel EM64T) Template set
sles-12-x86_64-ez.noarch : SUSE Linux Enterprise Server 12 (for AMD64/Intel EM64T) Template set
sles-15-x86_64-ez.noarch : SUSE Linux Enterprise Server 15 (for AMD64/Intel EM64T) Template set
suse-42.1-x86_64-ez.noarch : OpenSuse 42.1 (for AMD64/Intel EM64T) Template set
suse-42.2-x86_64-ez.noarch : OpenSuse 42.2 (for AMD64/Intel EM64T) Template set
suse-42.3-x86_64-ez.noarch : OpenSuse 42.3 (for AMD64/Intel EM64T) Template set
ubuntu-14.04-x86_64-ez.noarch : Ubuntu 14.04 (for AMD64/Intel EM64T) Template set
ubuntu-16.04-x86_64-ez.noarch : Ubuntu 16.04 (for AMD64/Intel EM64T) Template set
ubuntu-17.10-x86_64-ez.noarch : Ubuntu 17.10 (for AMD64/Intel EM64T) Template set
ubuntu-18.04-x86_64-ez.noarch : Ubuntu 18.04 (for AMD64/Intel EM64T) Template set
vzlinux-6-x86_64-ez.noarch : VzLinux 6 (for AMD64/Intel EM64T) Template set
vzlinux-7-x86_64-ez.noarch : VzLinux 7 (for AMD64/Intel EM64T) Template set

That sets up up with the structure to then build templates and gives you a structure, package manager links, networking setup scripts etc.

example (rough)

# ls /vz/template/centos/7/x86_64/config/app/
cyrus-imap/   devel/        jre/          jsdk/         mailman/      mod_ssl/      mysql/        php/          postgresql/   spamassassin/ tomcat/       vsftpd/

# ls /vz/template/centos/7/x86_64/config/os/default/
ct2vm                distribution         mirrorlist           package_manager      post-cache           pre-cache            summary              version
description          environment          osrelease            packages             post-install         release              upgradable_versions

Then you need to setup the default package sets:

# cat /vz/template/centos/7/x86_64/config/os/default/packages
authconfig
yum
rpm
wget
vim-minimal
nano
initscripts
iproute
iptables
iptables-services
openssh-clients
openssh-server
tar
unzip
bzip2
gzip
bash
sudo

Then finally after that (and about 10 other steps/checks) you can actually build a deployable EZ template for OpenVZ 7

Then you need to link the template to the network setup scripts (which dont exist for slack) so that networking actually works on container deployment.

So It may be possible but I would probably need to copy another OS template structure, update all the repo links, scripts etc and then MAYBE it would work.

Essentially you setup the environment for it then it self auto builds and installs the OS and generates an EZ template from the structure you hand it, you can then use that template for every container going forward or you can remove the lock file and have it do a full fresh pull of all packages from the OS repo upon every container deployment.

Very very different to OpenVZ 6.

I did create an initial set of EZ templates (very minimal) for everyone to use a while back: http://185.164.137.206/vz7/

I will add centos 8 to that when I get a minute.

beagle

From that list of available templates I guess Debian would have the smallest footprint.

I've never used it, but I heard Arch has a small footprint as well, but it's not on the list.

angstrom

@AnthonySmith said:
As per the title, what would be your OS of choice and why if package managers were not available due to lack of ram?

Personally I think I might be tempted to actually go for FreeBSD.

Asking because I am considering putting up some mini containers free for community members that pass certain landmarks but in order to automate the crap out of it so it is very light touch management I am only going to offer a single OS.

Just curious: is the container OpenVZ 7? If so, then FreeBSD wouldn't run anyway, would it?

FreeBSD has a package manager. Indeed, if I'm not mistaken, it offers a choice of two package managers.

How little RAM? I think that apt/Debian can manage with as little as 128 MB on KVM.

ehab

i didn't read what is before this post because i am totally exhausted.

if the main reason not to use a package manager is the resource constraints then i would go alpine.

in fact if you look at the [ Mini root filesystem ] its so f.small 6MB one can actually just compile some app and let it run ....

alpine

InceptionHosting

@angstrom said: Just curious: is the container OpenVZ 7? If so, then FreeBSD wouldn't run anyway, would it?

That right, I was hoping while typing that that beehive or whatever it was called project actually went somewhere for bsd containers, sadly it sis not.

@angstrom said: How little RAM? I think that apt/Debian can manage with as little as 128 MB on KVM.

1/3 core, 32MB Ram, 3GB Disk, 33GB BW.

Fun little free box to get the creative juices flowing.

I was working on the assumption that anything you need will have to be compiled.

angstrom

@AnthonySmith said: 1/3 core, 32MB Ram, 3GB Disk, 33GB BW.

Fun little free box to get the creative juices flowing.

I was working on the assumption that anything you need will have to be compiled.

Okay, yes, that's small!

WSS

@AnthonySmith said:
1/3 core, 32MB Ram, 3GB Disk, 33GB BW.

I don't think you can get a single thing to run in that with OVZ7 other than Alpine, and possibly Void, since it'll need to be able to utilize the newer kernel. If it was a KVM, I'd say OpenBSD - I've got a production service running in 64M/3G.

InceptionHosting

@WSS said: I'd say OpenBSD - I've got a production service running in 64M/3G.

I guess I could look at using KVM.

WSS

@AnthonySmith said:
I guess I could look at using KVM.

Here's my stripped down kernel config to save you some time: http://bsd01.ny.bangpath.tech/TINY.txt

angstrom

@AnthonySmith said:
I guess I could look at using KVM.

My two cents: I would say at least 64 MB on OpenVZ 7 and at least 128 MB on KVM, otherwise it would be too much of a pain for the user ...

WSS

@angstrom said:
My two cents: I would say at least 64 MB on OpenVZ 7 and at least 128 MB on KVM, otherwise it would be too much of a pain for the user

Wuss.

angstrom

@WSS said:

@angstrom said:
My two cents: I would say at least 64 MB on OpenVZ 7 and at least 128 MB on KVM, otherwise it would be too much of a pain for the user

Wuss.

Ain't nobody gonna compile their own kernel for a tiny VPS in 2020 -- except for you!

FlamingSpaceJunk

@AnthonySmith said: That right, I was hoping while typing that that beehive or whatever it was called project actually went somewhere for bsd containers, sadly it sis not.

?? My understanding is bhyve is more like KVM.

Iocage is the new hot tool for Jails, and that might be closer to what you're thinking of.

InceptionHosting

@FlamingSpaceJunk said:

@AnthonySmith said: That right, I was hoping while typing that that beehive or whatever it was called project actually went somewhere for bsd containers, sadly it sis not.

?? My understanding is bhyve is more like KVM.

Iocage is the new hot tool for Jails, and that might be closer to what you're thinking of.

I see, it has been years since I read about it to be honest.

yoursunny

@AnthonySmith said:
1/3 core, 32MB Ram, 3GB Disk, 33GB BW.

If I receive such a box, I'll run Go programs only.
Go only depends on kernel, and doesn't even need libc.
Go can run on any Linux distribution, as well as FreeBSD.

To access the machine and install Go, I'll request the following to be preinstalled:

• dropbear or other sshd
• sftp-server
• tar
• xz
• git (good to have)

Everything else, I'm going to delete as they waste RAM.

raman2020

arch linux, if you are okay with a rolling release model as base OS. If arch, then pacman is the obvious choice.

Other options:

• lxc/runc/docker containers through podman
• docker-swarm
• k8s

comi

I'm surprised no one mentioned gentoo

WSS

@comi said:
I'm surprised no one mentioned gentoo

Kind of hard to compile a pgcc kernel with 32MB of RAM.

Harambe

Second @WSS, would run Alpine. Have a few single purpose tiny VMs (usually LXC) and am running Alpine w/o issues - but when I say tiny I'm talking 128/256MB not 32, lol.

comi

@WSS said:

@comi said:
I'm surprised no one mentioned gentoo

Kind of hard to compile a pgcc kernel with 32MB of RAM.

what are 3GB of disk for? =]

angstrom

@WSS said:

@comi said:
I'm surprised no one mentioned gentoo

Kind of hard to compile a pgcc kernel with 32MB of RAM.

That page is really a blast from the past

InceptionHosting

@comi said: what are 3GB of disk for? =]

This entire forum uses less than that

comi

@AnthonySmith said:

@comi said: what are 3GB of disk for? =]

This entire forum uses less than that

No, it was a bad joke that it's tough to compile stuff on 32MB, but you can swap it out to 3GB disk, since you compile less often than use yum/apt.
I know it's ridiculous, I was trying to be funny.

angstrom

I remember compiling 2.0.x kernels on a i486 ThinkPad with 16 MB of RAM. It wasn't super fast, but not painfully slow, either.

rajprakash

@angstrom said:
I remember compiling 2.0.x kernels on a i486 ThinkPad with 16 MB of RAM. It wasn't super fast, but not painfully slow, either.

Bah. 1.9 kernel compiles on 386 hardware ran overnight!
Edit: I think it was after around the 1.9 series that I moved over to Debian Bo, which was the first time I had a 2.0 series kernel. Dang that makes me feel old.

FlamingSpaceJunk

Now that I think about it, I would probably treat the container like Linux from Scratch, and just drop binaries and libraries as needed. Everything would get compiled on a build server, and then get copied over.

The little container would probably be more useful with a build system attached to it.

tgl

alpine linux / apk

angstrom

@rajprakash said:

@angstrom said:
I remember compiling 2.0.x kernels on a i486 ThinkPad with 16 MB of RAM. It wasn't super fast, but not painfully slow, either.

Bah. 1.9 kernel compiles on 386 hardware ran overnight!
Edit: I think it was after around the 1.9 series that I moved over to Debian Bo, which was the first time I had a 2.0 series kernel. Dang that makes me feel old.

Well, you win. I never ran Linux on a i386!

souen

Debian minimal, or if not feasible, Alpine Linux as a second choice.

InceptionHosting

Based on available automation it’s looking like a minimal Debian image is the way to go.

iandk

The containers would be NAT/v6?

InceptionHosting

@iandk said:
The containers would be NAT/v6?

yup

InceptionHosting

Infact I have decided I am going to get started on that today.

The current VZ7 Debian template I have is about as minimal as possible already

Included packages:
#debian10
apt
openssh-client
openssh-server
wget
nano
iputils-ping

InceptionHosting

So having actually played with this, and experimented with real world use, no package manager in 2020 is not going to be an experience anyone would be interested, it took me an hour to satisfy the dependencies of gcc and that was using dpkg.

Looks like the best combo is 32mb ram and 64mb vswap, just about allows apt to run on a debian 10 container.

WSS

That would be perfectly adequate with Alpine, you know...

InceptionHosting

@WSS said:
That would be perfectly adequate with Alpine, you know...

The issue is I cannot create/maintain an alpine template for vituozzo 7.

maybe I could make an auto conversion script and inject it in to the template.

InceptionHosting

@WSS said:
That would be perfectly adequate with Alpine, you know...

With 32MB even alpine struggles it seems on vz7.

48MB however seems to be the sweet spot.

This might just work out.

WSS

@AnthonySmith said:

@WSS said:
That would be perfectly adequate with Alpine, you know...

With 32MB even alpine struggles it seems on vz7.

48MB however seems to be the sweet spot.

This might just work out.

If you build it using the virt-build, and just run with your VZ7 kernel it should be good enough for anyone who actually wants to do something with it.

WSS

This will inject on VZ6; might need to change to get it to bootstrap with 7. Not a fan of how it's done, but evidently it works.

https://gist.github.com/trimsj/c1fefd650b5f49ceb8f3efc1b6a1404d

yoursunny

@AnthonySmith said:
nano

I want to apt purge nano but there's no apt.

InceptionHosting

@WSS said:
This will inject on VZ6; might need to change to get it to bootstrap with 7. Not a fan of how it's done, but evidently it works.

https://gist.github.com/trimsj/c1fefd650b5f49ceb8f3efc1b6a1404d

yep, tested it on vz7 works fine.

I will try and find some time tomorrow, I was going to be fence posting but it looks like its going to rain all day.

I should just be able to extract the hds file from the debain 8 tar.lz4 template (the smallest one) and ploop mount it and insert a first boot script to run that, it takes about 2 - 3 minutes to run MAX so should work fine.

WSS

Ploop is still a thing in 7? I thought both that and SymFS were gonna go to the dump.

I've built an OVZ Alpine container with marginal effort before. Just be aware it can't sort properly so it's going to install 3.9

InceptionHosting

nope they stuck with ploop, I don't expect it to go anywhere soon.

Something to do with the opimised ext4 for CS for virtuozzo 7 cluster nodes.

Personally I truly hate it but it sure is a hell of a lot less problematic than it used to be.

simfs is a thing of the past.

WSS

@AnthonySmith said:
Something to do with the opimised ext4 for CS for virtuozzo 7 cluster nodes.

Nothing quite like more corrupt systems.