@kenm FOG Client version went from 0.11.19 to 0.12.0 I believe.

The FOG Client does auto update when it can. I suspect this is part of the “chatter” you’re seeing. Though I’m more keen to know if the fog client is even running properly on the machines.

Understand, September was an expiration of a code signing certificate for 0.11.19 and a new one was created for 0.12.0, but we’ve seen some issues with the client auto updating. It appears like it cannot see the FOG Server CA, and seems to be fixed by uninstalling the client and reinstalling it.

Not sure how much more help can be gleaned from this though.

@lewis There is no “script” file that is used. This is stored in the database.

Specifically:

FOG Configuration Page -> iPXE Menu -> fog.deployimage

@tech04

I’d recommend looking at the configuration file for refind and seeing if making changes within the file helps out even with newer refind versions.

I think this only because I believe “new” versions of refind add functionality that did not exist with the older versions.

https://forums.fogproject.org/topic/11146/refind-initializing-after-disable-secure-boot/8

This post kind of describes what things to look for.

Particularly of interest, I believe you would want to change scanfor line from:
scanfor netboot,internal to possibly scanfor netboot,hdbios,internal.

The next change will likely be the scan_delay option. It currently defaults to 0. I would recommend adding a 5 second delay here as this is likely what’s hanging the initialization. 0 means don’t wait for any time to start looking for boot devices. So while it’s initializing, it’s also expecting to find the drives (which may not be ready yet).

I would recommend setting the timeout from -1 to 5 as well just so you can ensure all is working. If it works with either (or or and) scan_delay and scanfor, then reset the timeout to -1 to automatically and immediately boot to the first found item.

@sebastian-roth @Chris-Whiteley setting deploySnapins: -1 will tell the system to deploy all snapins associated with the host. If deploySnapins: true as well, it will set the value to -1 automatically. I forgot about that portion sorry.

@plegrand Groups do not track what snapins are associated to them. It’s just too complex to get right and extremely error prone. Even the things that do track it’s extremely tedious.

Why you ask?

Well, let’s just use some medium numbers to show what I mean.

Let’s say you have a group with 500 hosts in it.

You originally setup the group so all hosts had the same snapins. (Easy to do, just update the group accordingly.)

Now you go to one of the hosts directly, and you remove the snapin from that host. Now you go back to the group, and the group now doesn’t know anything about the snapin on all 500 hosts.

Remember, groups in FOG are not a persistent thing. This is because you can associate a host to multiple groups. Groups, in FOG case, is basically a mechanism to mass update hosts.

For example:

One group to set machines up for specific snapins, but another group that you want to set machines printers, (the machine sets are different, but you might want to cross machiens.)

@detoss so getting very much details.

-rwxrwxrwx is what you see files appear as. Similar for directory but the 1st dash will usually be a d, denoting directory.

Notice there are 3 groups of rwx.

r=read=4
w=write=2
x=execute=1

First grouping rwx (left to right) = owner
Second grouping rwx = group
Third grouping rwx = other/everyone

So to make owner group and other have max permissions

777

Does this make sense or at least start to help?

There are other pieces to this but this is most likely what most people want to understand.

The chmod command is short for change mode. Mode here basically means permissions.

@julio said in droit:

bonjour voici mon fichier /etc/exports. j’ai ajouter ces deux dernière lignes pour un test mais elle ne fonctionne pas toujours.

I’m not quite sure what you’re looking for.

First things first, the fsid elements must be unique.

Meaning these lines are good.:

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

But the following 2 items are not good as they are overwriting the configuration for the first 2 items.

/home/fog/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/home/fog/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Should more likely be:

/home/fog/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=2)
/home/fog/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=3)

@devrick The funcs.sh script resides on the init folder, not on your local server.

@tomtom2770 Not exactly nicely.

While linux allows more than 15 character hostnames, windows does not. For this reason, the GUI was coded for Windows based machines. (Start with the most restrictive set)

https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/hostmanagementpage.class.php#L418 is the first part of the hostname limitation for creating new hosts.
https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/hostmanagementpage.class.php#L1038 is the second part for editing hosts
https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/fog/host.class.php#L638 is the third part for checking if the hostname is safe. Of note, the check is a regex, which can be changed for your needs. For the length specifically edit the 15 in the {1,15} portion.

You can change these however you like, but remember that changing this will not maintain these changes when you upgrade. Also, remember making the changes will allow you create hostnames on any entry longer than 15 characters and your environment may not like this.

Also, this only impacts the UI. There are some similar checks in the inits when you are trying to register hosts through the PXE menu item.

https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L164 Is the file that truncates hostnames to 15 characters. You’d have to comment the whole if statement to allow registering hosts with different length names. Of course there’s not validity checking so that would be handled in the UI elements.

@sborgne I’d start by cancelling all existing tasks:

UPDATE tasks SET taskStateID='5' WHERE taskStateID IN ('0','1','2','3') AND taskTypeID IN ('12','13');

@katerkarlo99 when creating the host via api, you can associate snapins, printers, groups, and modules using the ids of the relevant item as an array using the respective key as the object identifier.

For example, creating a host with associating the client modules your data element would be:

{
  "macs" : [ "00:01:02:03:04:05" ],
  "name" : "hostname",
  "modules" : [ 1,2,3,4,5,6,7,8,9,10,11,12 ]
}

Or very similar.

The api call would be to /fog/host/create of POST request.

@johannesd How did this file get created?

It doesn’t seem to have the correct permissions. First, it’s blocked off as only owner can read and write to it. (-rw-------) and that means ONLY root can do such a thing.

While permissions directly shouldn’t be an issue, the owner most likely is as a web request is what’s providing information. So basically, your FOG Client is polling for the certificate and one cannot be read.

You can fix this a multitude of ways, though I would start with the most restrictive set first:

From the fog server, ssh
sudo chown fogproject:apache /opt/fog/snapins/ssl/.srvprivate.key (If using Ubuntu change apache to www-data)

If this still doesn’t work, I’d at least suggest rwxr-x— permissions:
sudo chmod 750 /opt/fog/snapins/ssl/.srvprivate.key

If neither of these seem to work then you can try ensuring configuration is set for the folder and rwxrwxrwx for all files in the folder with:
sudo chown -R fogproject:apache /opt/fogsnapins/ssl
sudo chmod -R 777 /opt/fog/snapins/ssl

(Again cahnge apache with www-data if running Ubuntu/Debian variant.

@quazz Too add on a bit,

If you find something that doesn’t work, let us know. We will most likely request some more technical information so that we can do the research to find out if there’s a way to add it, or a patch we can use to incorporate, or we will find there is nothing we can do currently.

The point here is, you’re absolutely correct: We don’t know what will or will not work. We have some good google fu and only a few developers and testers working to get information so we can be as hardware agnostic as possible. But we aren’t all knowing. We know a new version was released and do our best (granted I’ve been slacking lately I suppose) to keep the kernels updated and including anything that maybe missing that we can add.

If it works, YAY, if it doesn’t, and we say try this kernel, if it works YAY, if it doesn’t let us know. We’ll ask for information and probably even walk through what we need and how to get it. Then we’ll try to find out information and give back whether or not we can do anything, and if we were able to do it, to test out the new thing. If it works, YAY, if it doesn’t rinse and repeat.

@altitudehack Just cause you like that command so much, here’s a pretty cool command to loop through. Does the same, but in a more compressed format.

for i in FOG{Scheduler,PingHosts,{Image,Snapin}Replicator,MulticastManager,ImageSize,SnapinHash}.service; do systemctl restart $i; done

@altitudehack Well when done through Group all it does is create individual tasks for each of the hosts in the group (hence the high number)

As you’re using the 1.5.9.72 version, I think there’s a potential issue with deleting group items in such a way. I’m assuming going back to the group -> power management after you have “deleted it” it has the same task reappeared?

I still believe you will need to clean out the powerManagement table using the

TRUNCATE TABLE powerManagement

Then restart the FOGScheduler service and you should then see: 0 scheduled task(s) to run and 0 power management task(s) to run.

Then I think you should use Group -> Task -> Advanced -> WOL. This will create a single task that does the exact same thing (but simpler) for your hosts in that group. It won’t see x number. it will show 1 scheduled task to run.

@altitudehack Thank you, you too

@altitudehack You could also run the installer with:

./installfog.sh -y

@altitudehack I’m working to fix the entry points.

@sebastian-roth or the web items are being compressed, but not decompressing for display.

@altitudehack The clear current tasks run the following:

truncate table powerManagement;
truncate table scheduledTasks;

This will restart both tables to ID of 1, but hopefully after this you will be good to go.