Simplifying Deployment with Official Virtual Appliance

[astrugatch]

I can’t seem to find it, but I recall reading a thread (this could have been months ago, time is weird at the moment) that was discussing cutting down the number of distros supported by the installer.

My though process expanded from that to eliminating the installer as it exists entirely (at least in the way that it broadly installs on so many distros) and instead provide an official Virtual Appliance.

It would have a LTS base OS of some type (Debian, Ubuntu LTS, or Oracle Linux probably - I would have included CentOS as the front runner but IBMs changes to that make it not an option really). Make the VM and compress it down, then have it be expandable to the available storage, probably with some type of interaction on first boot to handle those tasks automatically like an LVM expand, default password change etc, possibly even a choice for making the VM a storage node.

This would be a big lift obviously, but the simplification of support would be a big win when everyone starts from a common base.

Thoughts?

[george1421]

@astrugatch I can surely see the merits of this, but I think then you push the issue onto… OK which hypervisors do you support? Some have direct import paths and other do not. I’m not saying your idea is bad in any way it just pushes the problem down to another choke point. Ideally this is where docker would come into play.

One of the other mods have built a demographics tool to monitor what OS FOG is being installed on so the developers have a focus for development and support. The top 3 linux distros are still the top 3 when it comes to installing fog Ubuntu, Centos, Debian (in that order for FOG installs).

[astrugatch]

@george1421

I’ve typically only used VMWare, Xen/XCP-ng/CitrixHypervisor and Virtualbox all of which import OVF and OVA files. Not sure if KVM based hosts or HyperV can pull that off, but I would be surprised if they couldn’t.

We don’t currently use docker in our environment so I can’t speak to the benefits or pitfalls of that approach.

I would be interested in seeing how those demographics shift over the next year with the changes from CentOS to CentOS Stream. (https://blog.centos.org/2020/12/future-is-centos-stream/) I am moving my one CentOS host to Oracle Linux, but others may stick with stream, fedora or cough up the money for RHEL depending on their structure.

[Smoblikat]

Proxmox allows LXC container templates. You could easily build your own and use (and share!) that.

Start off with a base template of Ubuntu/whatever and go from there.

[Wayne Workman]

Someone out there has already installed FOG on CentOS Stream. I guess they know what they are doing, as I’ve not tested it at all.

Just today, I noticed a Ubuntu 14.04 user!!

[george1421]

@wayne-workman said in Simplifying Deployment with Official Virtual Appliance:

Someone out there has already installed FOG on CentOS Stream.

More than slightly off topic post:

Well the end is near for the CentOS line. IBM is positioning CentOS Stream as development OS for RedHat akin to what Fedora is/was. Centos Stream will not be a stable server operating system. Support for Centos 7 will continue until June 2024. End of maintenance support for Centos 8 is Dec 2021 (effectively killing the OS).

If it was my decision I would not plan on FOG supporting CentOS Stream officially. If FOG works on it great but from an official support standpoint there is little value. Hopefully someone (group) in the opensource community will step up and create an OS that will replace Centos based on RHEL.

[Quazz]

@wayne-workman I just did the same today (easy to swap from 8 to Stream) to test it out and see how different it really is.

Most packages got fairly minor updates (eg it runs the same Kernel, just a newer security release), interestingily, httpd got downgraded.

Still, only minor point differences in packages as far as I can tell. I don’t foresee any issues with it.

Of course we have no idea how it will evolve over time.

[astrugatch]

@quazz

I don’t expect to see a lot of fundamental functional differences for the most part. I do expect to see people shift away from it if only for the optics of where it is placed in the development pipeline (somewhere between Fedora and RHEL) and not wanting to be out ahead of the mainline.

[Wayne Workman]

Yeah, at this point Fedora would be a better pick for RPM based Linux than CentOS.

I think people should learn Debian. It’s not that big of a jump. The more you know about Linux, the less the distro matters. Tons of stuff online about Debian that you can search for any need you have. Main difference is apt-get vs dnf vs yum.

How to install git on CentOS:
yum -y install git

How to install git on Debian:
apt-get -y install git

So much difference…

The community likes Ubuntu a lot. I’m assuming most of these are probably from Europe, as Linux is popular there and there’s a decent FOG following in Europe. I would not choose Ubuntu for a server OS simply because of the automatic update stuff it does by default. At every company I’ve ever worked at, patches are a very, very controlled event. Down to the day, when it starts, when it ends, what’s being applied. We’d never put a server on cruise control.

Back to topic: An appliance based on Debian is a good idea. The build process should be automated, I can help with this. I have a decent internet connection at my house. I can distribute the image as a torrent (wouldn’t be very big). Others can help host if they choose due to the nature of the torrent system.

[george1421]

@wayne-workman said in Simplifying Deployment with Official Virtual Appliance:

Yeah, at this point Fedora would be a better pick for RPM based Linux than CentOS.

I agree 100%. At this point CentOS is dead to me.

I think people should learn Debian.

As we roll out new linux VMs, they will be Debian at my company. As you said Ubuntu is very popular, but (IMO) Canonical could go the same route as RH or go a totally different route causing a new bunch of problems. Heck, Canonical could get sucked into Microsoft, then what? (Embrace, enhance, extinguish. You know the drill.)

[astrugatch]

@george1421 @Wayne-Workman

We use Ubuntu where I am (US K12) I manage updates via Landscape which as worked out pretty well for us. Mind you our Linux footprint is much smaller than our Windows Server footprint.

I would definitely be behind a Debian based Appliance and would be willing to seed from home as well. I had to cut my speed from gig to 200/200 for reasons, but still enough to be helpful.

The biggest wrinkle would be scripting the first startup to ask the appropriate questions and making the appropriate changes (disk size, Database PW, network interface, IP, Hostname, generate Certs(SSL Should be a default on an appliance), etc.)

[Tom Elliott]

@astrugatch et al.

An OVA would be a decent approach, but then it puts the onus back on the FOG developers to manage the OVA, manage the updates, make sure documentation is all up, while also maintaining the FOG GUI and imaging system.

While the OVA approach is seen as a “yeah that would make my life easier” it doesn’t really make much sense.

If anything, a docker container would probably be a better and more security based approach. It allows us to work in one relatively simple environment. There’s some complexity involved here as well of course, but no where near as much as it would be to maintain an entire Virtual Appliance along with updates to the OS, managing templating and customization features, managing upgrade paths, etc…

Ultimately, the goal is to move away from a linux required environment (and I have been slowly working on it as well) and migrating from PHP based GUI/API to a NodeJS based GUI and API. This means you could install fog using simple management commands with being OS agnostic such as: npm install fog-node (or something like that). This could be done on Windows, Mac OS X, and/or linux using a common path. Plus it removes the onus of OS management giving it back to the Administrator.

The docker container, I think, is the middle man approach that would accomplish a similar feat as OVA without as much overhead for management though. Plus, realistically, it can be done much quicker and compartmentalizing more of the components such as TFTP, NFS, HTTP/S, etc…

[Wayne Workman]

A docker container is a good idea.

I was thinking with a VM image using Debian, I could pull down the packages FOG needs locally, and set apt-get to use those local packages. All the packages would also be pre-installed in the image.

As far as running something first-boot, if I’m building it I wouldn’t set it up like that. I’d say the admin can log into the VM (however they do that), and just run the fog installer which would already be there for them.

With this approach, there’s no changes to the installer or the code base. I hoped to automate building this image, creating a new one with each FOG release, and distributing via torrent.

If admins want to update, they would need internet and comment/uncomment some lines in their sources.list file, and update the fog repo with git pull.

Because the OS would be a chosen one, I can write up some documentation on setting a static IP, as well as putting a readme in the image saying the same.

Though a docker image is good too. idk if it would be easier or not. I don’t know docker very well.

[Wayne Workman]

I’m also down with making a Ubuntu image. Since that seems to be most popular. I wouldn’t want to mess with more than one.

[astrugatch]

@wayne-workman

I lean toward a VM over docker only because docker takes a different skill set where with a VM beginners can simply load up virtual box or power users likely already have something like VMware or Xen in their environment. That’s not to say that there isn’t value both for the dev team and users for a docker container.

I would lean toward Debian personally especially with some of the SQL idiosyncrasies with Ubuntu. Though I could see the value in going Ubuntu given how popular it is with the current user base.

[Wayne Workman]

Reviving this thread on my lunch break. What would a docker container for FOG look like?

Immediate thoughts:

• specify via environment variables database configuration for some external DB.
• Specify via environment variables the other things found in /opt/fog/.fogsettings too.
• disk mounting for images.

For the VM image, I could probably get this going in a couple weekends. In my VM environment at home, I can create qcow2 disk types. Though I can convert qcow2 to vmdk rather easily. Could make a qcow2 as well as vmdk torrents individually for distribution.

[astrugatch]

@wayne-workman

vmdk is probably the most broadly cross compatible short of something like an ova

[astrugatch]

@wayne-workman
Just checking to see if you’ve moved on this at all or if there is anything I can do to lend a hand. I have a decent sized lab with both Xen and ESXi if anything needs testing.

[Wayne Workman]

@astrugatch I haven’t done anything on this yet.

@moderators would there be any issue with using a forums topic to host torrent files for a fog VM image?