Ideal FOG Setup

[RLane]

Hi -

So I’ve been a member here for a long time and been using FOG since 0.32. I love it, love the community and environment. I also appreciate all of the work and effort that the dev’s put into it.

I’ve noticed one of the key organizations that use FOG are those of you in the educational sector. As a network admin, I’m responsible for the imaging of machines over the summer. I do this every year to keep everything fresh and up to date, along with making changes that the teachers request in labs.

Now that summer is approaching (students have a day left here) – what is the ideal setup for FOG?

• I’m running 1.2.0 right now - Ubuntu 14.04

• I am not using any trunk releases

• After reading about the trunk speeds being so much quicker for gig server and gig client imaging, I’m convinced I should upgrade

• The client seems promising and should be available soon – another reason I’m convinced I should upgrade

Obviously Tom already said that the next stable release will be soon, however, should I rebuild my FOG server (export users, client, etc.) and rebuild it fresh and use the trunk builds?

Should I wait until later in the summer for an upcoming stable reason?

I’m curious to see what everyone thinks.

Thanks!

[big007hed]

I would also like to know, I am new to the administration of FOG and would like to get to the newest most updated versions.

[Wayne Workman]

I’m actually in the process of building a WiKi article for “best practices with FOG”.

But at the moment, I’m tackling a wiki article for adding ISOs to the fog boot menu… and I’ve sorta had a small disaster with the servers at home… and I’m crazy busy at work during the summers…

But, it’ll get done…

A lot of the best practices stuff have to do with meaningful naming conventions, meaningful descriptions, security, automated backup procedures using Cron, and every-day usage of FOG.

Ultimately though, you should do things in a way that not only makes sense to you, but will make sense to any person that comes in behind you. Making things crazy complex with abbreviated names and no descriptions and all this other jazz for “Job Security” would give me a reason to look for reasons to get rid of you (if I were your boss)… and it’s lame to make things overly complex anyways.

[RLane]

@Wayne-Workman said:

I’m actually in the process of building a WiKi article for “best practices with FOG”.

But at the moment, I’m tackling a wiki article for adding ISOs to the fog boot menu… and I’ve sorta had a small disaster with the servers at home… and I’m crazy busy at work during the summers…

But, it’ll get done…

A lot of the best practices stuff have to do with meaningful naming conventions, meaningful descriptions, security, automated backup procedures using Cron, and every-day usage of FOG.

Ultimately though, you should do things in a way that not only makes sense to you, but will make sense to any person that comes in behind you. Making things crazy complex with abbreviated names and no descriptions and all this other jazz for “Job Security” would give me a reason to look for reasons to get rid of you (if I were your boss)… and it’s lame to make things overly complex anyways.

Perhaps I wasn’t clear enough (and forgive me if you understood me and I’m too exhausted to make sense of it)

Basically, I’ve used FOG for imaging for last couple of years. I’m a proficient user, everything is documented, maintained, updated, etc. My question though is:

Since summer is usually the time we (school sys/network admins) have time to do things, should I build a new Ubuntu VM to run a developmental version of FOG on?

Normally I would go ahead with it, however, with the new client - I’m not sure whether or not it’ll be changed from it’s current state to the final release when that comes. Basically, I don’t want to have to do something similar to this again and build images on a developmental version if I’d have to move off it to the stable release.

Hopefully that makes a bit more sense

[Wayne Workman]

@RLane That is more clear.

Images built with the current FOG Trunk version will work with the future FOG 1.3.0.

The new fog client is being developed by @Jbob and he’s integrated automatic updating for the new client on host machines. Meaning, the client should always be able to check with your FOG server for a newer version, and if there is one, grab it & install it, removing the old one.

Also, I’m positive that Jbob would like some more beta testers… I missed it this summer because it didn’t work for me when I was building the images for this summer.

Plus, there are some UI changes in FOG Trunk, it’s got a different look, and major performance improvements, and more features. Things like setting time zone and adding items to the boot menu via the UI, vs the old 1.2.0 way of editing PHP files (yuck). It’d always be beneficial to test things out while they are in beta, and see if it works in your environment, and let the developers know BEFORE 1.3.0 is released!!

Also, you can upgrade the FOG Trunk build to 1.3.0 when it’s released - that’s easy.

[RLane]

@Wayne-Workman said:

@RLane That is more clear.

Images built with the current FOG Trunk version will work with the future FOG 1.3.0.

The new fog client is being developed by @Jbob and he’s integrated automatic updating for the new client on host machines. Meaning, the client should always be able to check with your FOG server for a newer version, and if there is one, grab it & install it, removing the old one.

Also, I’m positive that Jbob would like some more beta testers… I missed it this summer because it didn’t work for me when I was building the images for this summer.

Plus, there are some UI changes in FOG Trunk, it’s got a different look, and major performance improvements, and more features. Things like setting time zone and adding items to the boot menu via the UI, vs the old 1.2.0 way of editing PHP files (yuck). It’d always be beneficial to test things out while they are in beta, and see if it works in your environment, and let the developers know BEFORE 1.3.0 is released!!

Also, you can upgrade the FOG Trunk build to 1.3.0 when it’s released - that’s easy.

Exactly what I was looking to hear, thanks a lot. To save my sanity further down the road, I’ll start fresh. Ubuntu 14.04 still okay or is the general recommendation still 12.02? A past coworker of mine auto-updated our current FOG box from 12.02 to 14.04 and made me panic before I found I had to change the /fog/ directory… phew.

[Wayne Workman]

Actually, Tom coded the current trunk to support Ubuntu 15.04 since a week or two ago, but it’s touchy. Tom could explain it best.

However, Tom really dislikes Ubuntu… For a lot of reasons that probably only a Linux developer would understand (over my head).

If you are dead-set on Ubuntu… then at least move to Debian 8… Ubuntu keeps moving further and further away from the norms…

I myself use Fedora 21 server and Fedora 22 server. CentOS is also very nice, and has support for my crappy RAID cards at my house out-of-the-box. RHEL would be the best choice, simply due to longevity, support base, and extensive documentation.

And, I’m not really a Linux expert or anything - therefore the only differences I can see between RHEL based Linux and Debian based Linux is Yum / Apt-get and the directories are slightly different, and the commands to start and stop services are a little different. All the basic commands I have memorized work on any distro I’ve tried. But again, I’m not an expert.

Tom recommends Red Hat based linux, and he’s been playing with Linux since the late 80s… so… that should tell you something. FOG was also originally developed on Fedora (yay!)

I’d really urge you to move away from Ubuntu…

[RLane]

@Wayne-Workman Recommendation taken - I’ll start looking around tomorrow. I could careless which flavor of Linux I’m using - I’m going for longevity and stability. I’m more than comfortable enough with a CLI based OS if I have to use it. There’s plenty of documentation out there on how to install FOG on nearly every distro. Thanks again for the suggestions + clarification!

[d4rk3]

I used 14.04 for about 6 months on two FOG servers, then fresh installed 14.10 on both of them.

I’ve been running 14.10 for over 8 months on both now with no issues. Don’t sweat it, IMO…

[MRCUR]

@Wayne-Workman Sorry to hop on this thread, but the discussion is very relevant to what I’m working on. Currently we run FOG 1.1.2 on Ubuntu 12.04 LTS. I’ve been messing around with the latest SVN builds on Ubuntu 14.04 LTS.

What’s the upgrade path for the “old” client to the new one? The speed improvements I’m seeing in the latest SVN builds, along with the hopefully improved management UI performance with our 8k+ hosts, makes me want to migrate before summer imaging gets underway on a large scale. With that said, I’m having a hard time finding info on what the upgrade is like to go from the current “old” client to the new one.

Anyone have some input on this?

[Wayne Workman]

@MRCUR

The new “client” is still in beta, and I am not using it yet… FOG Trunk comes with the “new” client and the Legacy client too. To be clear, the “FOG Client Service” is what gets installed on your image, and then that client communicates with the FOG Server to do various things.

I’m using FOG Trunk with the Legacy client currently. But by all means, go ahead and try out the new client.

To upgrade to FOG Trunk, I recommend using the ‘svn’ method. Here’s an article on that:
https://wiki.fogproject.org/wiki/index.php/SVN

FOG Trunk is currently tested working on Debian 8, CentOS 7, Fedora 21 and 22, and Ubuntu 15.04 and a little older, and current RHEL. I’d recommend going with RHEL, CentOS, or Fedora… But that choice is up to you.

[RLane]

@MRCUR If you’re rebuilding every image that you have (like I do each summer) for specific labs/buildings, I would suggest rebuilding it fresh. Do you have to? No. But it’s easy enough to do that.

If not, I would suggest setting BitSync up to your ‘old’ 1.1.2 machine and have it update that way.

[MRCUR]

@RLane We are rebuilding images (thankfully that’s not one of my responsibilities), but we won’t reimage every machine (tough to do with this many of them).

My actual plan is to upgrade the existing FOG servers (I have one storage node besides the main server) once I’m confident in the SVN rather than do a fresh install on new servers.

[MRCUR]

@Wayne-Workman Thanks Wayne. I guess my real question is about the upgrade path between clients, but it sounds like there isn’t info on that yet. Obviously out of the box, there is no “auto update” to the new client since the legacy client is still being supported - I’m just looking for guidance on what, if any, upgrade path there will be once 1.3.0 launches.

Upgrade path?

Currently, in FOG Trunk, you’d go to FOG Configuration -> FOG Settings -> Client Service -> and tick the new client checkbox.

There might not be a path of “upgrading” for the old clients… There is talk of discontinuing support of the legacy client, and just disabling it completely in 1.3.0.

As far as the old clients out in the field… they will just be out there… lonely… with nobody to talk to… and some day… they will go to a better place when a new image is applied.

Currently, though, FOG Trunk does support both the old client AND the new one, although you can’t set settings for the old client when the “new client” check box is ticked. Whatever AD credentials/ encrypted strings are set on clients will stay, but new changes will use the new client methods.

Did that answer your question?

[DevinR]

I am so excited for 1.3.0! Having said that, all of my real work has to be done on 1.2.0. Like the issue Tom recently mentioned that broke several images for a few revisions, when using the latest, you are subject to the latest bugs (even undiscovered ones).

I can’t afford to have production problems on my production fog server, but I happily have a node setup with the latest SVN for my own pleasure and enjoyment (I’m looking at you web-based boot menu!). Good luck!

[RLane]

@DevinR For what it’s worth, I’ve had r3540 running since it’s been out. I’ve taken images, imaged devices, etc. with no trouble. A hair quicker too than 1.2.0 over my 10/100 clients.

The biggest thing I’m worried about and I know @Wayne-Workman said it should be no problem, is installing client 0.8.4 on my images (using r3540) and relying on the automatic update to patch them when 1.3.0 is finalized.

[MRCUR]

@MRCUR @Wayne-Workman Thanks for the edit Wayne. That answers everything for me.

I do hope when 1.3.0 launches, the old client is still supported as it is in the current SVN’s. That way I can work on removing the legacy client from existing machines and installing the new client. Otherwise it’s going to be a long time until many machines get the new client as we do not reimage all that quickly with 8,000+ hosts.

[Wayne Workman]

@MRCUR

ah dang it… I’m getting bad about that (that’s the 2nd time)… I thought I was just “replying” but I end up editing other people’s posts… not sure if I should be a mod! lol

[Wayne Workman]

@MRCUR said:

I do hope when 1.3.0 launches, the old client is still supported as it is in the current SVN’s. That way I can work on removing the legacy client from existing machines and installing the new client. Otherwise it’s going to be a long time until many machines get the new client as we do not reimage all that quickly with 8,000+ hosts.

@Developers Probably something to consider there…

I, too, am partial to the legacy client… it’s a fall-back, at the least.