@dsloan-ethra Thanks. Also another option would be to just stop the FOG Client service via a snapin.

@joe-schmitt Yes. Kaspersky starts when the snap-in finishes.

Sometimes the FOG Client will crash on other snap-ins, but setting the service to automatically restart fixes that issue. This is the only snap-in that does not always reboot after it is completed. I’ll play around with it, maybe adding a wait-time after Kaspersky is installed to let it do whatever it needs to will help.

@wayne-workman said in Images not replicating:

I have, it just shows online/offline. I created it for exactly the problem you described. In the past, this problem was fixed but I guess it just keeps cropping up. Anyways, the project is called MonitorFogStorageNodes and is located here: https://github.com/FOGProject/fog-community-scripts

I thought I saw a Fix for this issue in one of the the RCs for 1.5, but can’t find it now… I saw the referenced issue (https://forums.fogproject.org/topic/10503/images-not-replicating) and saw that it was “Solved”, so i was hoping for a confirmation that the replication issue was fixed in the upcoming release…

I will grab that plugin, thank you!

@dsloan-ethra So just to recap what was done here to adjust Debian 9 (where the referenced article also implies it is an issue for any Debian variant like Ubuntu) for others that might find the thread:

Edit /etc/mysql/mysql.conf.d/mysqld.cnf
vi /etc/mysql/mysql.conf.d/mysqld.cnf Insert the following line in the [mysqld] section
max_connections = 8000 Copy the systemd service descriptor file so you can customize it
cp /lib/systemd/system/mysql.service /etc/systemd/system/ Append the following lines to this file: /etc/systemd/system/mysql.service LimitNOFILE=infinity LimitMEMLOCK=infinity Reload systemd processor
systemctl daemon-reload Reload the mysql service
systemctl restart mysqld Login to mysql as root and run the following command.
mysql> show variables like 'max_connections'; The response should be something like +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 8000 | +-----------------+-------+ 1 row in set (0.01 sec) Done.

These are not my words, only restated from the accepted solution here that Sebastian found and referenced: https://www.rfc3092.net/2017/06/mysql-max_connections-limited-to-214-on-ubuntu-foo/

@sebastian-roth said in Transfer host hardware information from .32 to 1.4.3+:

@dsloan-ethra Though I am fairly sure the table structures of both hosts and inventory are slightly different from 0.32 to 1.4.4. So after thinking about this a little more I see that my suggestion on export/import just fog.inventory might have led you the wrong way at first, sorry for that. Most probably there always is an issue using mysqldump if you don’t do the entire database and let the schema updater work on it afterwards! So this is your only chance with the inventory table as there hasn’t been an export for this in 0.32. So even if we’d add an import function now you wouldn’t be able to use it as you cannot export from 0.32.

I understand that the feature won’t be in .32, but having the ability to export and import the Inventory information with the hosts might be useful for future releases even so. I also would like to suggest that the “Host Hardware Inventory” page always be editable, or at least allow the 3 editable fields to show up even if hardware information is unavailable (Primary User, Other Tag #1, and Other Tag #2). When there is no hardware data, the page is nearly blank with the words simply saying “No results found.” The last resort for me was to manually re-type (or script) the data to be pulled from the old DB and entered into the fields, but the fields wouldn’t be available on the screen because there was no hardware information. However, in my humble opinion, that shouldn’t stop me from being able to enter data into those 3 fields manually.

Thank you again for the help! I do appreciate it.