Jeremy Davis's picture

Rik got me startted on this one. See the thread here.

So far I haven't done much and won't post full details and the patch here until it's working. If you wish to see/test how/if things are progressing you can check the patch progress. The patch code is hosted on my GitHub account - repo here.

The notes here should perhaps ideally be in the wiki, but I'd like some feedback and ideas so thought it better to post here.

Some links:

Some notes:
IMO rather than use the generic it would be better to script these bits into the conf file of the patch.
-As FOG is designed to be installed to a clean Ubuntu (or other) install I am currently working on a Core install, but seeing as FOG is actually LAMP based it makes more sense to use TKL LAMP as a base.
-Some parts of the install (such as setting IP address) need to be in firstboot scripts. Using a Python firstboot script (based on the TKL inithooks scripts), reasonable defaults could be set with the option to preseed answers instead.
-By default IP setting etc is in fog/lib/commmon/
-Some modifications to lib/ubuntu/ and lib/ubuntu/ are required (because of different package names - see FOG wiki link above).
-FOG recommends a static IP so TKL/confconsole ideally should be configured to default to the IP given at firstboot (rather than DHCP).
-DHCP option should also be included in firstboot. Most (if not all) networks will already have a DHCP server, but IMO (other than large corporate/enterprise/institution type networks) you would be best served by using the FOG server for DHCP (minimises need for end-user config - making it more turnkey!) So firstboot option: either use FOG DHCP - only need to disable existing DHCP or use existing DHCP but need to configure it to forward PXE to FOG. Instructions will need to be included in the TKL FOG aplliance wiki.


Jeremy Davis's picture

I think I was making this patch harder than it needs to be. I'm going to reapraise how I'm creating this patch and rather than trying to levage the existing install script, I think I'll do this how I'd normally create a patch... Install it all and run a diff on the filesystem, with a dump of the DB.

The downside of going that way is that is that some of the options won't be available by default (until firstboot scripts are created). So the initial patch will be just a full FOG server (inc DHCP etc). Then in later iterations we can add firstboot scripts to disable unrequired services, etc.

Jeremy Davis's picture

Ok, going through the process I have decided against my plan above. There is some merit to it, but not completely. I think what I will do is use a SQL dump of the DB + an adaptation of the script. That way it will take less effort initially, plus allow for easier updating later (I hope...!)

So onward and upward...

Jeremy Davis's picture

Feels a little like I'm having a converstion with myself here, but anyway... I have had significant progress with this patch. It has been a case of playing, thinking, playing some more then thinking some more.

In the end I decided that (as I had thought preiously) I'm making this all way too hard for myself and the approach I have settled on is a hybrid one.

As  the install script exists (and works well) it seems much more managable to try to leveage the exisiting script as much as possible and to modify it as little as possible. Whilst in some respects it may be 'nicer' to almost rewrite the script into the patch, I have decided that would be far from ideal from a TKL dev perspective. Having to basically rewrite the script/install routine everytime this appliance is updated seems completely unreasonable from a development perspective.

So even thought I wasted lots of time and energy pulling apart the standard install script I have stumbled across a much easier way to go...

That is to use the 'update' function of the install script. By adding a settings file and tricking the install routine into thinking it is doing an update (rather than a clean install) it asks a whole lot less questions, which is a good start. I have then provided an answer file which feeds into the install script (this creates a completely unattended install). For some reason there are a few settings that don't propagate properly so an overlayed config file is required. I also create an initial database (which by default is handled by the WebUI on first use).

The result is a patch that works for me and IMO is a foundation that holds promise of a superior start point to the default install. But it still contains a hardcoded IP which is unsatisfactory for a patch IMO (despite the fact that I have previously posted such patches before), but it is significant progress.

I intend to create first boot scripts so this issue is resolved which would make it a true TKL type appliance (ie set IP on first boot). But until then please have a look/test drive what I have done so far (via my GitHub account - link in OP). Hopefully it will be of some use to someone. I have my FOG server running and have some work to do with it, so further development may be a little delayed from here on in, but I hope to get back to this real soon!

dasanco's picture

I just stumbled across this.

Looks REAL interesting. I am already a TKL fan and was looking for a hardware burn-in tester / image loader for my network. Already have DHCP via the Pfsense box and TFTP via Freenas.

I figured FOG/TKL via a old thin-client would fill the gap.

TIA for your response!



Jeremy Davis's picture

One of the significant issues I had was that it requires NFS which doesn't work with any of the headless builds (e.g. OVZ, LXC, etc). For my purposes I ended up installing it to an OVZ container and created a separate NFS server.

FWIW I did post everything that I had done to GitHub. I won't be working any further on this any time soon (and if I were I would convert it to a TKLDev install first) but would welcome anyone else having a crack at it. And although it was a long time since I worked on this I'd happily help out as much as I can if someone else wants to take it on...

Add new comment