Topics created by DJslimD1k

@george1421 Found the fix and got the servers updated. Thank you guys for your time!

@george1421 I will go ahead and start off with changing the root and the admin passwords. Those are the two that I was really wanting to change. Thank you for your time!

@sebastian-roth Moving it to 12 did the trick! Is there anything else I should change or do? Thank you guys for the help!

@DJslimD1k Yes there are two ways of achieving this. The first one is kind of static where you modify the init.xz file. You need to re-do the modification as soon as you update to a new version of FOG. Find instructions on how to do that in the wiki: https://wiki.fogproject.org/wiki/index.php?title=Modifying_the_Init_Image

But as you seem to use the latest dev-branch version (great!) I would suggest you use the more dynamic way of “patching” the inits on the fly while it boots up. George posted instructions on this in the forums: https://forums.fogproject.org/topic/13500/dynamically-patching-fos-using-a-postinit-script

In your case you want to edit fog.reg.man.fix and delete lines 286-294 as well as 250-268 (note I am listing the lines numbers in reverse because when you start deleting in line 250 the later line numbers will change).

As well I suggest you keep an eye on the commit history of this particular file on github (https://github.com/FOGProject/fos/commits/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg) - whenever we commit a change I suggest you re-download and modify your fog.reg.man.fix again. Last change was March 2018, so changes to this file are kind of rare but you never know.

@djslimd1k Are you running into performance issues with this system?

If you look at top and sort by Processor what is your top task? mssql? Is it above 40%

How many fog clients do you have in your environment?

Lastly if you have the ram, you can increase the number of maximum handlers to 50 from 35. You may need to allocate 6GB of ram to the target computer. If you start dipping into swap space, then add more vRAM to the FOG server.

@DJslimD1k the mysql value is still pretty high. Higher than I might expect. But switching from isam to innodb helps because isam uses table locking on update and innodb uses row locking. With a lot of clients polling that table locking method becomes a road block.

I didn’t look back in the tread, but didn’t your fog server have 10 vCPUs? If so I would drop those back to 4 and see where performance settles out to. Overcommiting on vCPU is worse then not providing enough vCPUs to handle the load.

Having that many php-fpm workers just means that your server is busy with requests. There is some performance tuning you can do with the php-fpm settings on a busy network by switching from dynamic to allocation to static allocation.

@Wayne-Workman What has happened is mariadb starting at version 10 (?? I think) added some default values to mysql startup that are causing an issue with some of FOG’s default values (such as 0’s in date fields) I think we need to update the schema to use a invalid, but valid date of something like 1/1/1900 instead of 0/0/0000 as an unset date.

Again its not a problem with the renumber script, but the default startup values used for the sql server that was introduced with the later releases of mariadb.