Best posts made by Tom Elliott

@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.

@kevinnew22 So, a few questions come to mind:

Is this Active Directory or open ldap?

While I appreciate your privacy, I never understand why people block of “certain” points. I can understand hiding your IP if it’s a public IP address, but if it’s Private it makes little sense to block it. (Private IPs are 192.168.x.x/24 172.16.x.x/16 and 10.x.x.x/8)

First:

LDAP Server should be a dns name. Normally when you look at your domain you will see the “name” it maps to. Of course I have to make some assumptions so please just take my info and adjust as needed.

So let’s say I have a domain called example and the “common” name to map to the same domain is example.com. I would use example.com in the server area. (Of course this assumes DNS is handled by the domain as well which is generally common.)

LDAP Server port. If you’re using LDAPs you will likely need to import your domains certificate tree to the FOG Server for it to work properly. (I don’t understand why you blocked this out because there’s only 2 parts. So if you’re using 389 as the server port, this is not a secure port. Otherwise it is the secure port.

Search Base DN looks correct though I don’t know if it actually matches your domain structure.

Your Group Search DN may be correct but I’m not sure. Of note, with this being set, any group you’re attempting to match must reside in here. So I see your Admin Group is set to Admin. So under {blank}.sa -> grupo {blank} should contain the admin group. If it doesn’t this would be reason for you not being able to log in with your LDAP information. To generalize it for testing at least, you should probably set Group Search DN to the same as Search Base DN.

Admin Group appears correct assuming you have a Group named admin in your domain.

Mobile Group appears correct but is redundant. As you already have this setup for the Admin Group, this is unnecessary. It’s going to set the user as admin, so having Mobile user filled in with the same group doesn’t do anything.
Please Note with both of these, you can use multiple groups by separating them with commas. For example, you could associate all admins for the group admin and domain admins by entering int he Admin Group field: admin,domain admins

Username Attribute looks correct assuming Active Directory

Group Member Attribute looks correct assuming Active Directory

Bind DN appears to be correct though this is totally on you.

Bind password is already set but I have no way of knowing if it’s correct.

Of note, there are logs that are written when theres an error that might help you troubleshoot too.

On redhat based linux, this is /var/log/php-fpm/www-error.log. You would need to look up your systems error log. For Debian this might be /var/log/apache2/error.log, but it could also be under /var/log/php{phpver}-fpm/www-error.log (or very close to it) replacing phpver with the running php version (can be known by running php -v | awk 'match($0, /^PHP (([0-9])[.]([0-9]))[.][0-9]/, ary) {print ary[1]}'

Hopefully this helps narrow down where to look.

@coxm There isn’t really an “auto imaging” field per se.

The imaging happens via a few different methods, but only one could kind of being “Auto”.

So you could have a scheduled task (cron style) that could be considered “automated”, but I would not consider this “auto image”. To check if you have any scheduled tasks: Tasks -> Scheduled Tasks should show them all.

You could have a host in a task. Again this isn’t “auto image” and would only “hang” on a task if there was an error during the process. Check: Tasks -> Active Tasks or any of the other imaging styles (Multicast, Scheduled, Active, etc…, Snapin tasks do not require imaging of a machine to run, so you shouldn’t need to check here.)

You can task hosts via the PXE Menu, but this requires physical intervention to setup.

The only Auto-Image I would consider in the sense of what you’re asking, is from Quick Registration. You would need FOG Configuration Page -> FOG Settings -> Quick Reg -> Image defined. Then you would have to boot an unregistered machine and tell PXE to perform a quick registration. Once the registration completes (no user intervention beyond selecting quick registration) it will reboot the machine and immediately boot into PXE and will be deployed the image defined.

So you can change an image defined to any host at any time (other than if it’s in a task currently) and it will not “auto-image”.

Let us know if you have any other questions.