How many clients do you have in your FOG domain (i.e. devices that connect to your fog server)?

@bob-henderson (Pssst… I had a peek at some of the ui improvements. All I can say is, awesome!! )

@taspharel I guess you need to go back to your service provider and see if you can get a trending over time. What are they considering high cpu load?

The numbers you posted below are pretty low cpu usage. I understand that was only for a max 15 minute time from when you collected the data. You need to see if you can correlate the high cpu usage time the are saying to a specific action. For 200 nodes, it shouldn’t cause high CPU usage even during imaging.

There are two bits of information we probably should have for completeness.

1. How many vCPUs are allocated to the fog server VM
2. What version of FOG are you running. There WAS issues in the 1.3.x range of heavy CPU loading that was addressed in subsequent version of FOG.

@Trev-lchs said in FOG 1.5.10 officially released:

Hi all I know its very old, but, will 1.5.10 work ok on ubuntu 10.04.6 LTS Xenial Xerus

I hate to say this because I know we all need to run old stuff, but 10.04 reached end of support by ubuntu in 2015. I would bet that the ubuntu repos will not have all of the required prerequisites in their distribution needed for FOG 1.5.10. The installer should fail. BUT, if you are able to get FOG installed, it will run on that old of an operating system because uses all FOSS components.

For you, unless you have a really compelling case, you will be better off in the long run to install FOG on a current supported operating system and walk away from 10.04.

@fernando-gietz [Moderator’s note] Yes I want you to have your own thread on this. Your conditions may be different than the OPs. I’m going to fork this thread into a new one. To avoid polluting this thread with off-point discussions

Thread forked to here: https://forums.fogproject.org/topic/10890/fog-server-cpu-usage-100

I’ve looked into the possibility to create a slave node deployment node by setting up a master node in the traditional manner. Then creating a proposed slave node as you would in the traditional way. But at the end of the process pointing the Slave node to the Master nodes database. This will work for most of the tables except for the FOG server specific tables like globalSettings. These setting are unique to the individual FOG server. I can see if your FOG Slave server is location in a different subnet or if there is conflicting settings between the Master node and Slave node there will be a setting clash. If the globalSettings table had an additional field that represented the unique FOG installation ID the (global)settings could be created to each individual FOG server. I didn’t check into many other tables for FOG settings clash but it looks like the current FOG system could be extended to a Master-Slave configuration.

The other way I though about is to keep the fog databases isolated and then just send JSON or other types if IPC messages (they could be done as http POST calls between the systems for that matter) between the master and slave(s) FOG servers. This would allow the FOG installations to be run stand alone if needed but also communicate with a master node. Personally I like this approach a bit better for a scalability and robustness standpoint.

I guess I would have to ask you can you update to FOG 1.4.4?

Also lets collect some background information here

How many client computers are contacting this fog server?
What is your client check in time/interval?

I still have a need to get persistent groups working in fog 1.3.x. While I understand that it may be possible in FOG 2.0, that software is not here today.

First the problem I’m trying to solve. In my AD structure I have different base OUs for different locations. Within those location OUs I have different sub OUs for different types of devices (workstations, instruments, kiosks, etc). These different OUs could have different images, or the same image used for multiple OUs. I can do exactly what I need with post install scripts detecting the subnet where the target device is and what image is pushed to it. I can take this calculated info and populate the unattend.xml script during images. This all works fine. But its a bit cryptic, requires a programmer to make adjustments and I loose out of some of the functionality of FOG because the database fields are out of sync with the target device. If I can’t get the persistent groups to work as I need, I do have this route as a fall back method.

I think I figured a way to hack a solution together that won’t break 1.3.0 (when its released). Right now I’m just posting this here for a sanity check before I go about messing with FOG’s innards.

The idea I had is to create a manually registered host. Lets call this a host template (with an invalid mac address like 00:00:00:00:00:00). The name of that host template will match exactly the text name of the group I’ve created previously. (it would be much easier if I could just create a new integer field in the hosts table and call it TemplateID. And that TemplateID would point to a GroupID. But again I don’t want to break fog 1.3.0 or mess with the db schema). As I register new new hosts, I’ll assign them to a primary group when doing a full registration. This will create a new entry in the groupMembers table (so far this is all normal processes on how we register machines today).

Now I have a linking between a host template record (in pseudo code: [template.name == group.name] and [group.id==host.id] ) I can create a mysql database trigger after insert to fire off a sql script to copy the host template fields to the inserted host where the inserted host fields are null (or empty).

So far the path sounds logical and somewhat easy(ish).

@jackiejack Right, I do have a tutorial for that already written up: https://forums.fogproject.org/topic/10450/adding-additional-image-storage-space-to-fog-server

Final thoughts.

While this is a hack(ish) solution. The proper solution is for the FOG management GUI to support this directly. If the developers wanted to use the same concept of just using a host as a template. I would probably do it this way.

1. Add a check box to the host configuration page and call it ?? “Make this a host a template”
2. Once the host is a template it should no longer be displayed in the list of hosts but in a new list of templates.
3. For the groups, make a new drop down list called “host template” and only show hosts where the template flag is set.
4. Then in the php code do the actions of the trigger after a host association.
5. Then you could key off if the host template was updated, ask the user if the fog application should update all hosts associated with this template.

@jacob-gallant OK new kernels won’t help at that point before the iPXE menu is displayed. I can help you get started with custom kernels but that effort won’t fix the issue.

Please follow this tutorial on compiling the latest version of iPXE.
https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

@Tom-Elliott while I don’t have a dog in this race, I agree with Wayne that fog should keep all of its bits in its one location. /opt/fog/… is a logical choice. Typically with rhel based distros /home is placed on its own partition so technically its OK to use that since filling up the /home partition won’t bring down the system. But unfortunately not all linux distros place the /home in its own partition. If its an option in the installer to change it to another location, set the default to /opt/fog/backup and still allow the user to change the location if they want to. I also understand that unless installers take the extra step to move /opt to its own disk/partition they will not be any better off than just placing it on the root partition today.

But that is just my opinion on the topic.

@Andrew-Single If your fog servers are behind a proxy server let me know there are a few steps you need to do to have a successful upgrade to the SVN trunk.

@Wayne-Workman AND/OR post the image a google drive so the OP has total control of the image after the need is gone. Then just IM the link to the specific person(s) for review.

Lets flip this around a bit.

What version of fog are you on? The trunk build has a revision number in the cloud. What is that 4 digit number?

What device are you trying to uefi boot. Manufacturer and model.

The default uefi file I would start with is snponly.efi

Do you have a mix of bios and uefi systems you want to pxe boot? If you are also running 2012 dhcp server or a linux dhcp server there is some settings you can adjust to make your life a bit easier when trying to pxe boot both environments.

@Sebastian-Roth No I will (probably) just modify my bash script I used to create the FOS-L usb. That seemed to be the easiest and creates both bios and uefi usb images on the same usb. I need to review that tutorial I did and then just merge in the new GRUB boot menu. Really there is no magic that goes on in the flash drive other than the grub boot menu and a few tweaks Tom did to some files in the inits, well and the hostinfo.php from another feature request. The difficult part was just gluing all of the bits together.

@atarone Unfortunately, with 2008 dhcp server you are out of luck. If you have a 2012 dhcp server you can follow the instructions found here: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

This guide does not work with 2008 dhcp server.

@Tom-Elliott The fog client could do this with a bit of coding (I actually have a script that does this in the windows realm. We deploy to a build up OU then on first run the script moves the target to the defined OU. A post install script sets this up during imaging, but that is a bit off point).

The FOG client will need to know the admin user to connect to AD with that has sufficient rights to move/change OU affiliation.

The vbscript to do this is pretty simple.

Set wshNetwork = CreateObject("WScript.Network")
Set objSysInfo = CreateObject( "ADSystemInfo" )

strMachineObjectOU = "ou=newou,dc=domain,dc=com"
strComputerDN = objSysInfo.ComputerName

nComma = InStr(strComputerDN,",")
strCurrentOU = Mid(strComputerDN,nComma+1)
strComputerName = Left(strComputerDN,nComma - 1)
 
' Just make sure the new OU is different than old OU else no value to move it
If UCase(strCurrentOU) <> UCase(strMachineObjectOU) Then
    Set objNewOU = GetObject("LDAP://" & strMachineObjectOU)
    Set objMoveComputer = objNewOU.MoveHere("LDAP://" & strComputerDN, strComputerName)
End If

Set wshNetwork = Nothing
Set objSysInfo = Nothing

The FOG server will need to detect the change in OU and inform the FOG client to move itself.

@Wayne-Workman Most of the noobs would probably use an fog based distribution, especially if they are not that familiar with linux. I can see if someone was just trying it out and didn’t want to put a lot of effort into the software that they may not like. That is where a fog distribution (akin to freepbx distribution) would be a benefit.

The issue (as I see it) is that we don’t currently have enough people with the skill set to build and maintain a distribution as well as the installer based builds. The next issue would be what host OS do you select? Ubuntu or Centos? I know what I would select, but that doesn’t mean it is the best choice.

When you get into VMs some companies will allow externally created VMs and other won’t for the simple fact you don’t “really” know who built the VM and if they put some hidden back door into the software (the same could be said about a distribution or even the fog installer).

If it was up to me (and its not), I would rather devote the 2 or 3 developers that it would take to manage a VM or distribution and put that manpower to fog development.

@juice381 said in Making Fog Portable:

ODROID C2

Warning this post is off-point: I have not used an odroid device before, but I have used a raspberry pi. IF you are going to use the onboard micro sd for storage, used a good quality class 10 or uhs-1 device if you want any speed out of your device. I initially made the mistake of just going to the local big box store and picked up a cheap micros SD card. My first impression of the pi as it was junk, and unusably slow. After doing some research I decided to replace the sd card with something faster. Once I replaced the boot media with a samsug evo micro sd card the pi came to life. Depending on the number of images you need, the micro sd card may be all you need.