Simplifying Deployment with Official Virtual Appliance

[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?