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

@dclark said in Increased network traffic since 1.5.0 upgrade (Snapins):

[03-06-18 9:34:10 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:34:10 pm]  | 46388736 0 /opt/fog/snapins/CiscoJabberSetup.msi ftp://fog:ejOVmFXgU4rbglxcETxqt7AVI%2BBh6h%2BDnWv0ksrwBpA%3D@10.27.25.165/opt/fog/snapins/CiscoJabberSetup.msi
[03-06-18 9:34:10 pm]  | Files do not match.
[03-06-18 9:34:10 pm]  * Deleting remote file: /opt/fog/snapins/CiscoJabberSetup.msi
[03-06-18 9:34:10 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRSMSFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.27.25.165
[03-06-18 9:34:10 pm]  * Started sync for Snapin Cisco Jabber

The above, to me, seems to indicate proper action. as you can see, the file sizes don’t match up, meaning either the remote node this was testing could not be contacted, or the file did not exist. (I say these because the filesize was 0 on the remote side.)

[03-06-18 9:33:51 pm]  * Started sync for Snapin Cisco Jabber
[03-06-18 9:33:57 pm]  | Cisco Jabber: No need to sync CiscoJabberSetup.msi file to IRLNEFOG01
[03-06-18 9:33:57 pm]  | CMD:
			lftp -e 'set xfer:log 1; set xfer:log-file "/opt/fog/log/fogsnapinrep.Cisco Jabber.transfer.IRLNEFOG01.log";set ftp:list-options -a;set net:max-retries 10;set net:timeout 30;  mirror -c --parallel=20 -R -i "CiscoJabberSetup.msi" --ignore-time -vvv --exclude ".srvprivate" "/opt/fog/snapins" "/opt/fog/snapins"; exit' -u fog,[Protected] 10.22.25.165

This line interests me as I don’t think i’ve ever seen this issue ever before. So while I’ve never seen it, I hope I may have found the reason to why it was happening and have a hopeful fix for it. Essentially my code was setting a test variable if it wasn’t already set. The idea was if other nodes needed the file, it would be able to send it. I guess this was an oversite? I’m not sure what impacts this will have, but I think it will work for the problem you were seeing.

Please try installing the working-1.5.1 branch? I know it’s not in RC or anything, I’m only pushing bug fixes there. I don’t have multiple nodes to test if this is working so I’m just hoping your input/help would be okay as, like I said, you’re also the first i’ve seen of this particular issue.

@george1421 Just php-fpm.

I don’t know how much help memcache would give, though I suppose it wouldn’t hurt to try it.

So, worked remotely and was able to help determine part of the problem.

Installed apachetop and took a look, found a lot of things still looking at servicemodule-active.php. We moved away from this call as it had some weird issues on its own. Moved the file and the GUI become much less sluggish. Worked to get phpmyadmin working as well. This wasn’t a problem with php-fpm vs. libapache2-mod-php (though I did make sure phpmyadmin would access using the php-fpm system). Part of the problem that was happening was the rewrite rules that handles api system.

Moved the rewrite rules into the directory stanza of the fog.conf. Made this update in the working-1.5.1 branch as well. I haven’t had time to test whether this move actually still allows the system to work, but it should. Will work on that this weekend (testing to see it works properly).

Also, we are still working to help purge the db of old stuff that’s no longer needed.

@hvaransky turn compression down to 19. 20 and 22 on zstd requires a lot of memory. While the selector lets you choose that high, it is not recommended. 19, I’ve found, is the highest you can go without causing an issue with the client machine.

So I took a little time today to try to see what was happening. I’m happy to report, at least based on how I could test, that I believe I found a solution.

Please, if either of you could be so kind, install the working-1.5.1 branch of FOG? This should contain the fix for ldap users and authentication without having to delete the users from the database every iteration.

@hvaransky There’s a lot of variables to consider in deploy, or capture, speed.

First is your network.
Second is the disks writing to/reading from.
Third is the compression.

As @Junkhacker stated, finding the “goldilocks” zone of compression is also useful. For example, gzip at -9 will take a long time to capture and you don’t really gain much compression increase. That and speed to deploy isn’t much better (partly due to the compression already reaching it’s peak).

Less data to deploy = faster network transfer, but if your disk is really old or slow the speed could be limited there. (This on deploy and capture).

I’ve found -11 on Zstd to be a good zone, though I don’t have much disk space, so I use zstd on 19 (which i find is still faster than gzip on 9) during capture.

As I said, there’s a lot of variables to consider.

Also, if your fog server is replicating images and files at the same time as you performing a capture or deploy, chances are likely the slowdown is due to the server being used at the same time as the leads have to jump around the server’s hard drive.

You could try rebooting the fog server though. After all, the server is still a computer, and while it’s not necessarily a normal requirement, rebooting might solve many of the problems you’re seeing.

Also, look at your network, if you have a 1Gbps network, but a switch is a 100/Mbps, the maximum capture/deploy across network to that machine would be limited to 100 Mbps (about 2.5GB/min) Where 1Gbps would give about 7.5GB/min. (This is for uncompressed data though.) The speed, is also (as stated earlier) limited to the hard drives of both the client and server machines. Most often I’ve found the slowdown is not the networks, rather they’re the hdd’s reading/writing from/to.

@itcc I don’t know what’s going on with groups sorry for that but the git branch working-1.5.1 has the fix for power management deletion from groups

@itcc correct