FOG Hangouts

@krishna said in PXE Windows Client registration:

==> /var/log/apache2/other_vhosts_access.log <==
192.168.172.10:80 192.168.172.54 - - [17/May/2021:14:12:01 +0930] “POST /fog/service/ipxe/boot.php HTTP/1.1” 200 3388 “-” “iPXE/1.20.1+ (g4bd0)”

Did that show up exactly at that Point in time when the client tried to load it? We see the client requesting the boot.php file for the FOG menu and it’s answered with a HTTP 200 status code. So it doesn’t seem to be an issue on the FOG server.

Does this happen with different hardware clients?

@John-L-Clark Hmm, did see your post on PHP-FPM log just now. Looks like your setup is not handling the many requests you seem to get. How many machines with fog-client installed do you roughly have in your network?

You might need to adjust the PHP-FPM settings to your needs. Edit /etc/php/7.4/fpm/pool.d/www.conf and adjust values, then restart PHP-FPM (sudo systemctl restart php7.4-fpm).

There is a lot of information on the web on what settings might suite your setup (depending on server resources and so on):

• https://stackoverflow.com/questions/25097179/warning-pool-www-seems-busy-you-may-need-to-increase-pm-start-servers-or-pm
• https://www.sitepoint.com/php-fpm-tuning-using-pm-static-max-performance/

@Wayne-Workman We seem to have another hickup with the install test on Ubuntu 16.04 (master, dev-branch and working-1.6 this time).

Package installer seems to be in a bad state - error:

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.

@zaccx32 said in All hosts deleted/not showing in host list/groups:

After cleaning that up, a few hosts showed up but most are still missing and our images are not showing up in the GUI either.

While disk space is an important thing and 99% seems a lot in first sight, I don’t think this was causing the issue here. Why? Because we see you have a large disk with still 31 GB shown as free. I find it very strange that you see some hosts now. From the SHOW DATABASES; output you posted I would have guessed the fog DB is fully corrupted now and needs recovery (keeping my fingers crossed it’s still possible).

Also, when trying to access the fog DB today, is cannot be found any more, almost like it is gone.

Now we really need to figure out what’s going wrong with the DB. First of all let us take a look a the DB files on disk, the real basis: ls -al /var/lib/mysql (post a picture here)

As well stop the DB and take a file backup. Then start it up again and check the log:

service mysqld stop
cd /root
mkdir backup
rsync -av /var/lib/mysql backup
service mysqld start
tail -n 30 /var/log/my*

Post a picture of the output from the last command as well. I really hope I got all the commands right for your pretty dated CentOS 6.9 install.

@sjensen Each imaging solution handles things differently.

FOG can, with enough understanding, switch between clonezilla and vice versa. That’s only because they use the same imaging platform (partclone).

How other imaging systems handle things is not going to mesh with how fog (or partclone) handles things. I’d say if the imaging system uses partclone there is a potential to swap back and forth.

Please note that while this is technically possible, you’d be hard pressed to find a reason to do the transfer beyond saying: deploy the image with the original medium and capture the image using the new medium. This is because, as I said, it’s technically possible, you will probably have a faster and easier time just doing the deploy from original and capture with new.

Of course this is FOG, and we’re going to be more biased toward using FOG.

@altitudehack So this is safe to solve?

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

@b_man said in GParted Live from FOG:

Out of curiosity, how come this was marked as solved?

Not sure if you noticed but this is an old topic that was marked solved even before you posted. That’s one of the reasons why we keep telling people to open their very own topics and post all their details in that new one. Makes things a lot clearer. If you think a lot of the information is in the old topic, then just link to it from your new one.

Please add details like the exact commands used to prepare the files and version of GParted you use as this might make a difference. As well post if you boot in UEFI or legacy BIOS mode and if it’s a VM setup or on hardware.

@zaccx32 Oh well, that explains why you don’t see the hosts.

First check the available disk space as crashed tables are often caused by zero disk space. In the Linux command shell run: df -h (if you need help reading the output, post a picture here)

If disk space is ok you go back to the mysql shell and run the query: REPAIR TABLE hosts; (don’t forget to switch to the fog database first, see the queries I posted last). If that returns without an obvious error you can try the SELECT again.

@sebastian-roth We should have renamed that user donotusethisuserever