Posts made by george1421

Really it depends not so much as how many you will image at a time but how many total systems will be managed by your FOG server.

A circa 2010 desktop with an SSD drive would be more than enough to image systems. Just for a matter of scale, I can image 2 computers at the same time with FOG installed on a Raspberry Pi3. The heavy lifting (so to speak) during imaging is not done by the fog server, but by the FOG client. All the fog server needs to do during imaging is to move the image file from the hard drive to the network adapter and to manage the process. Its not a heavy workload.

Now when you say 20-30 machines at a time. That can be done with a multicast image (one to many) as long as your network is capable of multicasting. If you are trying to deploy to 20 computers using unicasting (one to one) then you will run into a problem in that your infrastructure probably can’t handle that much data (no necessarily related to the FOG server).

Lets start out with how do you plan on using FOG in your environment?

@fernando-gietz And what is top saying? Header as well as what is the load like on mysql? I want to ensure we have not made things worse.

The default check in time for the fog clients connected to this fog server is 5 minutes. So I might understand if you have 400 clients that you may be over loading mysql or apache.

My initial reaction is to have you try the php-fpm route (because I had a good improvement in performance on my system). But I want to make sure that there isn’t something else going on first.

How long as this virtual machine been in operation (thinking if its been used for a long time we might want to look into some mysql maintenance).

@fernando-gietz In this case I was only interested in the local file creation speed not NFS since that brings in more things (network, nfs subsystem, etc.) that is not part of the issue here.

Based on your numbers, the disk subsystem shouldn’t be your issue here. Your disks should be more than fast enough for them to keep up with mysql. I think I would start with dropping the number of vCPUs on this VM and see how well your performance is then.

Very nice job!! After some time we should be able to identify the most stable OS for FOG installs. This will really come in handy when thinking about which OS we might support in the future.

@fernando-gietz OK I tell you why I asked. I’m looking at this as a VM issue not fog (yet).

6 vCPU is a HUGE number in regards to VMs. I checked the processor from your lscpu post and that processor has 6 cores (12 hyperthreads). The issue with going too large with vCPUs is that it actually slows down your server because your hypervisor has to find a time slot where it has 6 processors available to run. You will see this in your wait times in your vm stats be higher than your other VM. Since you probably have a dual CPU (if you have a quad processor VM host wonderful) VM host server, and if you have a busy VM host server with a lot of virtual machines your FOG VM will suffer because the time where it has 6 vCPUs available will be quite small. So what should you do? While this will sound the opposite, drop your vCPU count to 4 (I would say 2 vCPUs, but start with 4) and see if you have better performance. Watch your top command. Right now your load average is pretty good, with 4 CPUs keep the numbers below 2,00 for the load average.

Aside from your potential vCPU issue since you are using the database when you see the slowness, we should probably run a test and see how fast your disk subsystem is on your virtual server. I was working on a post about making FOG go faster here: https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast There are some statistics in this post https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast/6 that you can compare your system against. Just use the dd command to create a 1GB test file and check your disk speeds. dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=direct While you can’t really do anything about the results, you will know how your VM Host server compares to my benchmark testing.

Finally I have been working on another thread about moving the php processing from apache to php-fpm to get a better web gui performance increase because we off-load php processing from apache to a dedicated php engine. That post is here: https://forums.fogproject.org/topic/10717/can-php-fpm-make-fog-web-gui-fast When you get the rest of your issues fixed it would be interesting to see (because you have a large campus) if this solution helps with web gui performance.

And finally, you may have reached a limit where you might consider spinning up a new virtual machine dedicated to mysql (2 vCPU) that will be optimized for only mysql activities.

Update to thread: These sed scripts can/could be called from a fog postinit script to ‘patch’ the fog scripts on each FOS boot. This way you would never need to unpack the inits and would fully support updated scripts in the future.

I did write a tutorial on the postinit scripts here: https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins

@breit The boot.php script builds the iPXE menu on the fly based on what the client is asking, the state of knowledge about the clinet, and what the client is. There is no static file that can be changed. If you want to change the iPXE menu you can

1. Work within the frame work the developers have provided with the iPXE menu configuration in the FOG Settings.
2. Write your own plugin to alter and hook into the boot menu creation.
3. Hack the php code to make the boot.php page create things the way you want.

Each has its drawback and advantages, but beyond step 1 you add quite a bit of complexity to your task.

If you want to see how the fog iPXE menu is constructed you can point your browser at this url, just change <fog_server_ip> to the address of your fog server.

http://<fog_server-ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00

That is the structure of the iPXE menu in text form.

@breit Ok then where did you get the idea to use syslinux from? Maybe an old fog wiki document?? That is where i’m confused.

@jackiejack said in Could not complete tasking /bin/fog.upload:

That long string in .configure file is the password?

Yes that is the password and not the hash. The password for the linux user fog should have never been password. That is the default password for the web gui admin called fog yes I know its confusing. I really wish the developers long time ago would have change one of them to something different to avoid the confusion.

@breit See here is where we have the problem. Can we assume you migrated from FOG 0.32 or earlier?

FOG 1.3.0 or newer (possibly 1.1.x and newer) doesn’t use syslinux (i.e. pxelinux.0) for anything. So you building pxelinux.cfg doesn’t do you any good. FOG uses iPXE for its boot loader now and not syslinux. The menu structures are not compatible You can build a pretty complex iPXE menu structure, but that needs to be done using the tools given to you. The way to manage the FOG iPXE menus is via the FOG web gui. I suppose you might be able to chainload to syslinux from FOG, but the iPXE menuing system is substantially more robust than syslinux.

@jackiejack for step 5 you need to use the command line ftp program not a browser window. I guess I need to make that clearer in the guide.

Also as a side note, having a clear picture of the error taken with a mobile phone helps us understand the context around the error too. I just guessed at this one based on the error message.

@breit Well FOG isn’t really designed for doing that. BUT you can get pretty close. If you are using FOG 1.3.x or newer (yes I see you are on 1.5.0RC9). In the FOG Settings menus, there is iPXE Menu Configuration You can move the items from the main menu to the advanced menu by just changing the Menu Show with list to display on advanced menu. If you don’t want to show those menu items at all , you can also set that same list to Do not list on menu to hide the menu entry.

You can also do quite a bit more with submenus, but you have to do that by creating the iPXE menu structure by hand.

Did you by chance muck about with the linux user called fog or its password? The linux service account fog should only be used by the FOG application and not for interactive administration. Understand this is not the web ui administrative account called fog but the linux service account called fog

Unfortunatly this is a common occurrence (reusing the fog system account for other purposes). Here is how to reset the system.

1. Login with another user account that has sudo rights.
2. Inspect the file /var/fog/.fogsettings (its hidden)
3. Collect and document the value of password in the document. That is the password the fog account should be set to.
4. Reset the linux fog user account to that password defined in step 3. You will use passwd fog to reset the account. Hint: If you log into your fog server using putty you can copy and paste text much easier than using the linux console.
5. From a windows computer confirm that you can ftp to the fog server. Login with the user fog and the password collected from step 3. If successful proceed to the next step.
6. Goto the FOG Web gui and FOG settings. Ensure the user ID in the tftp section says fog and the password matches the value collected in step 3.
7. Go to the storage node configuration for this FOG server. Ensure the management id is fog and the management password is the same as you collected in step 3.
8. Now go back to the fog server linux console and rerun the fog installer (./installfog.sh) to realign the remaining bits.
9. Done.

What is your specific issue. You should not need to hack (i.e. alter) fog code unless you are doing some crazy stuff.

For uefi systems you need to tell your dhcp server to send the uefi iPXE boot file (ipxe.efi) to the target computers to boot into FOG iPXE menu.

If you could provide a bit clearer picture to what’s not working right we can give you a better quality answer.

Steps to switch to working branch.

cd <directory where git-repo is stored>
sudo git checkout working
sudo git pull
cd bin
sudo ./installfog.sh

There are log files on the fog server in /opt/fog. Have a peek at the replication logs and see if there are anything in there that might give you an idea why its not replicating.

Also be aware that in the image definition you can disable a specific image from replicating too.

@george1421 And a follow up to that question, how many other VMs are running on this VM Host server?

@fernando-gietz The fog server is a virtual machine right?? How many cores does your VM Host server have? (Your SOC team may have to answer that).

@fernando-gietz How about listing the output of lscpu (from the linux console of the fog server) also grab the memory information from the top section of top