@Wayne-Workman said in Schedule image on next cold/warm boot:
@dsloan-ethra You could deploy a snapin that removes the fog client, and then do an ‘imediate image deploy’ from the web interface. That would accomplish what you’re wanting.
And that is something i should have thought of! Brilliantly simple! Thank you!!
It would be nice if we could schedule an imaging for the next time the host restarts. Right now, we can do it if we start an imaging instantly and disable the FOG client on the host, but it would be nice to click ‘go’ and be able to say “Just reboot the machine when you are ready.”
Thank you for all you all do!
@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.
This only happens about 15% of the time…
After the Kaspersky AV snapin completes successfully, the FOG service returns an error, says it will try again in 5 minutes but it never updates the log file again. I am including a snipit:
------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
5/4/2018 10:15 AM Client-Info Client Version: 0.11.15
5/4/2018 10:15 AM Client-Info Client OS: Windows
5/4/2018 10:15 AM Client-Info Server Version: 1.4.4
5/4/2018 10:15 AM Middleware::Response Success
5/4/2018 10:15 AM SnapinClient Running snapin 1410 (ALL) OpenDNS Client
5/4/2018 10:15 AM Middleware::Communication Download: http://xx.xx.xx.xxx/fog/ser
vice/snapins.file.php?mac=BC:AE:C5:E5:70:93||00:00:00:00:00:00:00:E0&taskid=2488
5/4/2018 10:15 AM SnapinClient C:\Program Files (x86)\FOG\tmp\OpenDNS.zip
5/4/2018 10:15 AM SnapinClient Processing SnapinPack OpenDNS.zip
5/4/2018 10:15 AM SnapinClient Extracting SnapinPack
5/4/2018 10:15 AM Bus Emmiting message on channel: Notification
5/4/2018 10:15 AM SnapinClient Starting snapin
5/4/2018 10:15 AM SnapinClient Snapin finished
5/4/2018 10:15 AM SnapinClient Return Code: 0
5/4/2018 10:15 AM Bus Emmiting message on channel: Notification
5/4/2018 10:15 AM Middleware::Communication URL: http://xx.xx.xx.xxx/fog/service/
snapins.checkin.php?taskid=2488&exitcode=0&mac=BC:AE:C5:E5:70:93||00:00:00:00:00
:00:00:E0&newService&json
5/4/2018 10:15 AM SnapinClient Running snapin 1411 (ALL) KES-10SP2MR1
5/4/2018 10:15 AM Middleware::Communication Download: http://xx.xx.xx.xxx/fog/ser
vice/snapins.file.php?mac=BC:AE:C5:E5:70:93||00:00:00:00:00:00:00:E0&taskid=2489
5/4/2018 10:21 AM SnapinClient C:\Program Files (x86)\FOG\tmp\KES-10SP2MR1.zip
5/4/2018 10:21 AM SnapinClient Processing SnapinPack KES-10SP2MR1.zip
5/4/2018 10:21 AM SnapinClient Extracting SnapinPack
5/4/2018 10:21 AM Bus Emmiting message on channel: Notification
5/4/2018 10:21 AM SnapinClient Starting snapin
5/4/2018 10:25 AM SnapinClient Snapin finished
5/4/2018 10:25 AM SnapinClient Return Code: 0
5/4/2018 10:25 AM Bus Emmiting message on channel: Notification
5/4/2018 10:25 AM Middleware::Communication URL: http://xx.xx.xx.xxx/fog/service/
snapins.checkin.php?taskid=2489&exitcode=0&mac=BC:AE:C5:E5:70:93||00:00:00:00:00
:00:00:E0&newService&json
5/4/2018 10:25 AM Power Creating shutdown request
5/4/2018 10:25 AM Power Parameters: /r /c "Snapin requested restart" /t 0
5/4/2018 10:25 AM Bus Emmiting message on channel: Power
5/4/2018 10:25 AM Power Attempt 1/6 to shutdown computer
5/4/2018 10:25 AM Power --> API call returned 1, will re-attempt in 5 minutes
This is the end of the log. I copied this out of the log 30 minute later and no more entries were created. The snap-in is removed from the task list as if it completed successfully but never restarts. A remote reboot (shutdown -r -f -t 0 -m \computername) restarts the machine and the last snap-in continues normally.
@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
MonitorFogStorageNodesand 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!
I have noticed this same issue with 1.4.4 when a node goes down (for whatever reason), replication stops to all nodes. I have to manually disable the node before replication will start up again on the rest of the nodes. I was just curious if this issue was fixed in a future release?
On a tangent, has anyone made an addon that would show the status of the Nodes? Online, offline, replicating image/snapins, status of replication, etc? I, for one, would find that handy.
Thank you for all you guys do!
Just throwing my 2 cents worth in because we also have 2 domains, but segmented networks with the exception of FOG talking over both networks. But that shouldn’t matter for this.
I have set up my primary domain information in FOG as a default. I then created Locations (Using the Location plugin) and host groups for each remote location. I then placed the machines into each of their respective host groups and applying the specifics there.
Once you have the machines you want on one domain placed into the host group for your Old domain, you can apply the AD information to that group allowing the Host that needs to remain on your Old domain to re-join it. You can do the same for the New domain as well.
Simply put: Create 2 Host Groups. “Old_Domain” and “New_Domain”. Place the hosts you want to keep on the old domain in the “Old_Domain” group and apply the AD information to that group. Then Place the hosts you want to be on the New Domain in the “New_Domain” group and apply the AD information to that group. Your hosts will stay on the domain you specified to each group.
@sebastian-roth said in Storage nodes opening multiple mySQL connections to Master DB:
@dsloan.ethra Take a look at this: https://www.rfc3092.net/2017/06/mysql-max_connections-limited-to-214-on-ubuntu-foo/ and/or https://support.plesk.com/hc/en-us/articles/213393029-MySQL-values-open-files-limit-and-max-connections-are-not-applied and/or https://codepoets.co.uk/2015/mysql-max_connections-stuck-on-214/ (depending on which distro/version you use)
www.rfc3092.net held the answer! Worked great and now I can set the number of connections and have it stick! Thank you both for helping!
@george1421 said in Storage nodes opening multiple mySQL connections to Master DB:
@dsloan-ethra said in Storage nodes opening multiple mySQL connections to Master DB:
max_connections
I guess lets start with what does your /etc/my.cnf file look like?
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
max_connections = 500
Since posting this, I have restarted mysql several times.
I finally got the “Too many connections” error to stop (shortly before I posted my update) after restarting and quickly getting into the mysql console and manually doing a set global max_connections = 1000;. Currently, there are 0 errors. But as I was saying the max_connections = 500 in the /etc/mysql/my.cnf does not seem to be taking effect upon restart. When I restart the service now, it reports that the max_connections variable is set to 214.
+-----------------------------------------------+---------------------+
| Variable_name | Value |
+-----------------------------------------------+---------------------+
| Aborted_connects | 19 |
| Connection_errors_accept | 0 |
| Connection_errors_internal | 0 |
| Connection_errors_max_connections | 0 |
| Connection_errors_peer_address | 0 |
| Connection_errors_select | 0 |
| Connection_errors_tcpwrap | 0 |
| Connections | 151324 |
| Locked_connects | 0 |
| Max_used_connections | 385 |
| Max_used_connections_time | 2018-01-01 11:30:20 |
| Performance_schema_session_connect_attrs_lost | 0 |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_finished_connects | 0 |
| Threads_connected | 313 |
+-----------------------------------------------+---------------------+```
Thank you for responding.
Ok, so I misread the “Time” of the connection as the Number of connections. That is not the issue. The Nodes are only hitting the server with 2-3 connections each. I had this issue early on and upped the connections to 500:
sudo mysql -u root -p
set global max_connections = 500;
as well as set in /etc/mysql/my.cnf
[mysqld]
max_connections = 500
However, I don’t believe the my.cnf option is taking effect. I Did restart my main FOG DB server Friday, which would explain why this is happening all over again. What am I doing wrong to keep mysql from lowering the connections?
I recently completed a deployment of 48 storage nodes to our local and remote locations on Friday. We have been testing FOG 1.4.4 for over 3 months, adding the storage nodes over this time. Starting sometime this weekend, the nodes have just hammered our primary FOG mysql server, opening multiple connections to it. I set the max connections to the mysql server 2500 but that didn’t seem to help, the connections from the nodes just started growing further… Any suggestions/assistance would be gratefully accepted.
@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
hostsandinventoryare 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 justfog.inventorymight 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 theinventorytable 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.
Alright, I guess found what I was doing wrong:
Before importing, I was deleting all current hosts thinking that was necessary. This time, I left them alone and imported the hosts first (mysql -D fog -u root < ./newhosts.sql), then the inventory (mysql -D fog -u root < ./newinventory.sql). Waited 5 minutes, (Watching Futurama and got distracted), restarted the mysql service for good measure and logged in. Spot checked several hosts and they all had the missing inventory and hardware information, including my inventory tag information.
Thank you for the table name (inventory)! That was information I’ve been looking for quite a while!
@sebastian-roth said in Transfer host hardware information from .32 to 1.4.3+:
@dsloan-ethra Are you still interested in doing this? Shouldn’t be too much a trouble if the hostIDs in the DB have not changed. You’d just need to export
fog.inventorytable from the old DB and import that to the new DB. Let us know if you need help with that.
I am and I attempted to export the hosts and inventory tables from the .32 server and imported them into the 1.4.4 server and the hosts would not show up. I then exported the whole .32 database and imported it into the 1.4.4 and it did a schema update. I cleaned up the hosts, removing the old images, snap-ins, etc and exported the hosts and inventory again (using mysqldump), moving the current 1.4.4 database back… But when I imported the “updated” hosts and inventory, I still can’t list the hosts in the “Host Management”…
I have always had bad luck with SQL management, so I am likely doing something wrong so if you have some instructions that might show me what I am doing wrong, I’d appreciate it.
Perhaps adding the inventory as part of the Hosts export would be a nice future feature addition.
Is there a way to transfer the HOST Hardware information from an older version of FOG to a newer version? I have transferred the HOST list, but it did not include the hardware info which also contains our TAG, User and miscellaneous comments.