@trex please try the steps as outlined here.

https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

What version of fog are you running?

What BOOT file are you using? This sounds like you’re using pxelinux.0 still as that limited the network transfer to 10mbps (which would also cause high latency).

@pberberian Are you connected to a switch, or a hub? This difference is significant.

@sourceminer Please follow the information in this post:
https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

I don’t think sharing a users’ database is necessary, and should not be done except in the most extreme of cases.

This particular issue is so miniscule, and finding the offending mac’s is so simple that sharing an entire database is not required.

At the most, if sharing any part of a DB IS required, should only get a copy of the hostMAC Table so you can find the current host requesting, and figure out the mac’s are being sent.

But even that’s not needed. The list of mac addresses being send is already visible:

00:09:0f:aa:00:01
98:e7:f4:f4:0a:5e
e4:a7:a0:b6:55:26
00:09:0f:fe:00:01

The rest of the mac addresses are “invalid” and not counted towards the registered macs.

I’m fairly sure one of these 4 mac addresses has the “duplicate” host associated to it.

The SQL QUERY to use to see which hosts have which mac’s:

SELECT `hmHostID`,`hostID`,`hostName`,`hmMAC` FROM `hostMAC` LEFT OUTER JOIN `hosts` ON `hostMAC`.`hmHostID` = `hosts`.`hostID` WHERE `hmMAC` IN ('00:09:0f:aa:00:01','98:e7:f4:f4:0a:5e','e4:a7:a0:b6:55:26','00:09:0f:fe:00:01')\G

Once you find the mac address that’s registered to a host other than the one requesting, you can blacklist the mac address by part or whole.

You would goto FOG Configuration Page->FOG Settings->Quick Reg, and something like Pending Mac Filters (I can’t see right now as what we’re working on is not able to view the fog settings currently.) I’ll update with the direct link as soon as I can.

@rstockham23 To me it sounds like the image doesn’t exist on the nodes at /images/2018CloudReady.

Can you verify that the storage nodes you require to have this image actually have it?

Wolbroadcast.

@tesparza So the filesize on dashboard is displaying correctly?

@george1421 He’s referring to the autologout module, but you’re definitely not wrong.

@blkeller, duly noted. Updating the time restraints means updating the entry in SQL, not hard, and I can have that done fairly easily. Even not allowing the setting to hold on to anything less than 5 minutes isn’t too hard, though do I set it to 0 if it’s below 5? Just thoughts on how best to approach. I don’t think it should warrant an “error” to update the host because that field isn’t really necessary for normal imaging functions.

@coxm The /var/www/fog/lib/fog/config.class.php DATABASE_PASSWORD line should look like:

define('DATABASE_PASSWORD', '<whateveryourfogguipasswordishere>');

You may also need to edit the /opt/fog/.fogsettings line with snmysqlpass='' to:

snmysqlpass='<whateveryourfogguipasswordishere>'

Please try this SQL statement:

UPDATE `globalSettings` SET `settingCategory`='FOG Boot Settings' WHERE `settingKey` IN ('FOG_ADVANCED_MENU_LOGIN','FOG_EFI_BOOT_EXIT_TYPE','FOG_PXE_MENU_TIMEOUT','FOG_PXE_MENU_HIDDEN','FOG_PXE_ADVANCED','FOG_KEY_SEQUENCE','FOG_NO_MENU','FOG_BOOT_EXIT_TYPE','FOG_PXE_HIDDENMENU_TIMEOUT','FOG_IPXE_MAIN_COLOURS','FOG_IPXE_MAIN_CPAIRS','FOG_IPXE_MAIN_FALLBACK_CPAIRS','FOG_IPXE_VALID_HOST_COLOURS','FOG_IPXE_INVALID_HOST_COLOURS','FOG_IPXE_HOST_CPAIRS','FOG_IPXE_BG_FILE');

This should reset all those items to use the proper setting category. The problem with the ajax and the place you’re currently updating is because those fields are appearing outside of the “<form>” element. So when you click update, nothing is actually being sent to be updated. This should address those issues.

@n406c is it literally saying bandwitch.php or bandwidth.php?

Init’s are now uploaded.

If you aren’t willing to jump to the working branch, please run:

wget --no-check-certificate -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget --no-check-certificate -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz

This should get you the latest init’s with the changes @Sebastian-Roth has suggested.

One log shows .11.12 and the other shows 0.11.14, are you getting logs from the same machine?

@wayne-workman This has always been the case. The reset is not the same as what you see done with reset encryption data on the GUI however. This is more a way to ensure a token shared is not potentially stolen and used maliciously. Updated prior post, the “reset encryption” is more properly phrased as reauthenticate every 30 minutes.

Sorry for the delay. Can you please run:

cd /var/www/fog
grep -rl 'bandwitch`

This should give us the problematic file you’re seeing. I searched the repository and do not see this popping up anywhere, which leads me to believe somebody edited a file, and made a typo somewhere.

The file it outputs type:

sudo vi <file spit out by grep command>
:%s/bandwitch/bandwidth/g
:wq!

This should fix the bandwidth issue you’re seeing.

This is not currently possible. You could limit it on a per host basis through the ethtool utility I believe. That or the main interface of the fog server (ideally this) could be limited.

https://unix.stackexchange.com/questions/83888/limit-outgoing-bandwidth-on-an-specific-interface

@tesparza So we can solve this then?

Also, what is the “latest fog trunk build?”

I need exact versioning to properly help you.