Splitting up FOG pieces

[mrayzies]

Server

• FOG Version: 1.2.0
• OS: Ubuntu 14.04

Client

• Service Version: 0.9.10
• OS: Windows 7

Description

A while ago, I set up our FOG server. It was back when 1.2.0 wasn’t quite finished, so I used an arbitrary commit at the time. I hacked around in it quite a bit to strip out the components of FOG to better integrate into our environment; ultimately, FOG became only the home for the PXE files and web interface (the database was put on a database cluster, the images directory became an NFS mount from another host) and everything worked great.

I now need to create another FOG server in an isolated development subnet. To that end, I figured I’d use the actual 1.2.0 FOG release and mutate my process so that I could use our deployment tools (i.e. Ansible) to create a server for any subnet/isolated setup that I needed.

However, the code has changed substantially from when I hacked at it to the 1.2.0 release and it would essentially be another large investment of my time to hack it all apart.

So my question is, is it possible in 1.2.0 to split out the components of FOG such that I can tell it to just use a different host for some function?

I’ve tried to play nice by adding the other host as a storage node, but even with a database import, the images are listed with no available storage node. I must be making something unhappy as well with that as frequently the webui will lock up and demand I update my database schema (which promptly fails).

If this functionality isn’t available in 1.2.0, is it something that is being worked on in 1.3.0?

[Wayne Workman]

It’s possible easily in 1.2.0, not sure what hacking was necessary.

That said, you should use the 1.3.0 release candidate. You’ll be needing to support newer advanced tech that 1.2.0 simply does not work with. There has been major, major strides between 1.2 and 1.3 RC.

So a quick run down on how to do what you want in 1.3.0 RC is:

Install 1.3 rc onto your chosen linux distro. Do not do anything special during this, accept defaults. If your using Fedora or centos you’ll want to set selinux to permissive and either configure or disable firewall. These things are outlined in the CENTOS 7 and Fedora wiki articles.

Open opt/fog/.fogsettings and look for snmysqlhost and snmysqluser and snmysqlpass. There may also be a an snmysqldatabase but I don’t remember. On your remote db host you need to create a user and pass as you know, and plug these things into the .fogsettings file.

At this point, rerun the installer. Fog will configure the new db and set all files as appropriate.

Next, for the image storage. I’d strongly suggest you set up another vm and give it space, and use the installer to setup a storage node. Without a dedicated storage node, you would not be able to replicate to future remote nodes. Without a full vm storage node, the bare minimum to do is NFS share and ftp user for the same directory. Create mntcheck and a directory called dev and then make dev/.mntcheck.
NFS settings for fog 1.3 can be seen here, it’s close to but not the same as 1.2 was.
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_NFS

Last, delete your default member from storage management. If you used the fog installer to setup a storage node, in 1.3.0 this node is automatically added for you in storage management, but you need to assign it a group and enable it and it’s graph. If you did the storage manually, you’ll have to add the node to storage management via the new storage node link on the left.

Then just try it out. I’m sure it’ll be fine, you sound like your proficient in linux so I don’t think you’ll have too many issues.

However if you hit bumps, just ask, give details. We will help. What you want to do is easily done with 1.3.0.

[mrayzies]

“Hacks” was probably a poor term. To get it to play nice the way we want with Ansible, I dug into your installer script and tore it apart such that FOG was installed/configured without the use of the FOG installation script.

It seems like I’ll have to do that sort of mutilation again if I want an unattended installation.

In any case, I tried out FOG 1.3.0 per your recommendation, following your instructions, and I was able to see my existing images without the errors I was seeing in FOG 1.2.0. However, I am unable to schedule any deploy tasks as the webUI returns: “Type: 8, File: /var/www/fog/lib/fog/fogbase.class.php, Line: 793, Message: Undefined index: value, Host: 10.52.2.31, Username: fog”. The code offers no clue out of context (to me): "

/**
 * Check if isLoaded
 *
 * @param string|int $key the key to see if loaded
 *
 * @return bool|string
 */
protected function isLoaded($key)
{
    $key = $this->key($key);
    $result = isset($this->isLoaded[$key]) ? $this->isLoaded[$key] : 0;
    (793) $this->isLoaded[$key]++;
    return $result ? $result : false;
}

On a separate note, is there are a particular reason you recommend storage replication via FOG nodes? Our images are hosted on a ZFS server with several bells and whistles to make it extremely efficient, so even if I had more FOG hosts, I’m inclined to just point all of them to it. The server internally handles data replication with its peer node, so it isn’t a single point of failure.

[Wayne Workman]

@mrayzies said in Splitting up FOG pieces:

It seems like I’ll have to do that sort of mutilation again if I want an unattended installation.

Not needed. If you run the installer as ./installfog.sh -y it will install fully unattended.

[Wayne Workman]

@mrayzies said in Splitting up FOG pieces:

However, I am unable to schedule any deploy tasks as the webUI returns: “Type: 8, File: /var/www/fog/lib/fog/fogbase.class.php, Line: 793, Message: Undefined index: value, Host: 10.52.2.31, Username: fog”.

That’s an FTP issue. Look in the wiki for Troubleshoot FTP.

[Wayne Workman]

@mrayzies said in Splitting up FOG pieces:

Our images are hosted on a ZFS server with several bells and whistles to make it extremely efficient, so even if I had more FOG hosts, I’m inclined to just point all of them to it.

What you suggested is non-standard. Not the part about separating out images, but the other part, ‘pointing hosts’ to this one spot.

Fog has come a very long way. It’s now designed to be a distributed imaging system, infinitely scalable. In a supported setup, there is only one web server, and there are as many storage nodes as you need. A typical large setup will have a storage node on-site at each location that needs imaging. Storage nodes installed with the fog installer now also serve tftp, can serve dhcp, and can serve inits and kernels, and if the location plugin is configured, snapins with use of the new fog client will use the remote defined storage node and not the main. Everything is designed to be distributed and to not be WAN taxing.

[mrayzies]

@Wayne-Workman said in Splitting up FOG pieces:

@mrayzies said in Splitting up FOG pieces:

However, I am unable to schedule any deploy tasks as the webUI returns: “Type: 8, File: /var/www/fog/lib/fog/fogbase.class.php, Line: 793, Message: Undefined index: value, Host: 10.52.2.31, Username: fog”.

That’s an FTP issue. Look in the wiki for Troubleshoot FTP.

I verified I was able to complete all steps listed in the “testing” section (https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP) and still see the error.

Any other ideas?

Regarding the silent installer – you had me install it once, then change settings and re-run it; is it supported to change the settings beforehand and then run it?

Lastly, regarding the non-standard setup, that’s good information about the progress of FOG and I’m glad to see it’s doing well. I’ll consider moving to the supported setup, but I won’t waste time trying to debug my non-standard setup.

[Wayne Workman]

@mrayzies said in Splitting up FOG pieces:

Regarding the silent installer – you had me install it once, then change settings and re-run it; is it supported to change the settings beforehand and then run it?

Yes. Look through this:
https://wiki.fogproject.org/wiki/index.php?title=.fogsettings

All settings in the .fogsettings file can be passed to the installer like this:
snmysqlhost='10.0.0.5' packages='what ever packages' dodhcp='0' ./installfog.sh -y

Of course that’s just an example from memory I just made up. Some settings are yes/no and some are 0/1. Look in the above article for how it should be.

[Wayne Workman]

@mrayzies said in Splitting up FOG pieces:

I verified I was able to complete all steps listed in the “testing” section (https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP) and still see the error.
Any other ideas?

The main server will first try to make a web query to the storage node. If the node were an actual storage node setup by the fog installer, it would respond. Since its not a full storage node, the web query fails, and the web server is supposed to fall back to FTP.

when testing, test from cli of the web server, use the same credentials you put in the storage management area for the node. Did you set the ftp users home directory to where the images are?

[mrayzies]

@Wayne-Workman said in Splitting up FOG pieces:

@mrayzies said in Splitting up FOG pieces:

I verified I was able to complete all steps listed in the “testing” section (https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP) and still see the error.
Any other ideas?

The main server will first try to make a web query to the storage node. If the node were an actual storage node setup by the fog installer, it would respond. Since its not a full storage node, the web query fails, and the web server is supposed to fall back to FTP.

when testing, test from cli of the web server, use the same credentials you put in the storage management area for the node. Did you set the ftp users home directory to where the images are?

My new server is failing the FTP commands. But so is my old server.

What I believe is happening is my customization is coming back to bite me – I am pretty confident that I hardcoded some values into the old install that hijacked what would have been requests to the storage nodes and re-wrote them to use the local FOG server; so the client would make an FTP request to the FOG server, it would work fine, and then it would try and mount the remote server anyway – and I had added all the necessary permissions to make that work.

So I can either straighten out my install to be more standard or go through that headache again. In either case, I’d consider this “resolved” and not spend anymore time on it. Thanks for the help.

[Wayne Workman]

@mrayzies I would suggest becoming standard. You can completely separate out all of fogs pieces as you wish, but storage nodes are best as a full Linux vm and setup with the fog installer.