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

@robertkwild yes, it can.

@tesparza You can update the information in FOG Settings, but it will not automatically apply it to the hosts. This is just the “default” storage point, not the thing each host uses.

If you update the AD information on each of the hosts, it will rejoin the domain using the new information. No need to redeploy the image or client.

To change all the hosts more quickly, create a group, add all the hosts you need to change into the group. Then update the AD information from within the group.

@michaeloberg

As this is for testing I’d suggest:

wget -O /var/www/fog/service/ipxe/bzImage-rt-v215 https://drive.google.com/uc?id=1qxcjC9ZrV8lVh4T6rgBtmtgSp7SWRzL9&export=download
wget -O /var/www/fog/service/ipxe/bzImage-rt-opts https://drive.google.com/uc?id=1t4WgWHOv3wIFjnodRtMsRcaO87XIZxM4&export=download

From the host in question, assuming it’s registered, go to edit it and in the Kernel field type in the name of the kernel file to test:

E.G.:
bzImage-rt-v215
bzImage-rt-opts

I don’t know if you purposely deleted, but I will say our community isn’t as harsh as the arch community with questions.

That said if you’re okay with it, copy the files you change to your git clone as appropriate and run git diff

To complete installation run:

./installfog.sh -yX

it will take a bit but it will continue.

@fabiano-matos et al.

The TSC DEADLINE disabled due to Errata; please update microcode to version: 0x52 (or later)

Isn’t really an issue in the context of imaging. This is just meaning the microcode of the controller is older than what the kernel is expecting. Itself, is not an issue you should have to be worried about.

As far as your DHCP failed or we were unable to access…, that’s seeming to indicate the issue in your case is specific to not being able to get a DHCP address for some reason. This could be due to STP going alive, then down, then alive but the down period is longer than the period that FOG is trying to get the IP address. I haven’t been around very often recently, but I do recall there was a version or hold pattern that was set by the UI that could hopefully determine if this was indeed the issue.

Please see if STP is enabled on your network and maybe enable Fast STP RSTP or whatever it is called in your environment or disable STP altogether if you can.

@fabiano-matos I’m only giving information that I know when I don’t know all the details.

If other machines aren’t having an issue, maybe try changing the port the machine is linking up to to see if that helps.