With the release candidates, if you have a storage node down, but still enabled it’s impossible to edit or create a snapin. The page will eventually timeout and will be blank.
The apache log will have the offending storage node, and once the storage node is disabled snapins are able to be created and editted.
I’m assuming this is because of the snapin replication feature. Just wondering if this could be improved somehow?
Thank you.
Small detail. When looking at the snapins assigned to a host the “Check here to see what snapins can be added” list is displayed by default even though the box isn’t checked. The list will hide if you check and uncheck the box.
The code change definitely made a difference and the load mostly stayed in the single digits yesterday.
@Tom-Elliott
I added the one line, and we’ll see how things behave today.
Thanks.
@Tom-Elliott
32 up and running. A few others that are disabled.
Ubuntu 14.0.4.4
After updating to RC-7. I’m seeing a huge increase of network traffic to the DB server.
The portal has also become slow to respond because the load.
The apache error log is full of entries like:
[:error] [pid 15993] [client :51945] PHP Fatal error: Uncaught exception ‘Exception’ with message ‘Window size must be greater than 1’ in /var/www/html/fog/lib/fog/fogurlrequests.class.php:62\nStack trace:\n#0 /var/www/html/fog/lib/fog/fogurlrequests.class.php(46): FOGURLRequests->rolling_curl(NULL)\n#1 /var/www/html/fog/lib/fog/fogurlrequests.class.php(157): FOGURLRequests->execute()\n#2 /var/www/html/fog/lib/pages/dashboardpage.class.php(109): FOGURLRequests->process(Array)\n#3 /var/www/html/fog/lib/fog/fogpagemanager.class.php(72): DashboardPage->bandwidth()\n#4 /var/www/html/fog/management/index.php(19): FOGPageManager->render()\n#5 {main}\n thrown in /var/www/html/fog/lib/fog/fogurlrequests.class.php on line 62, referer: http://fog/fog/management/index.php?node=home
@ablohowiak
No, that was as an advanced task.
@Tom-Elliott
Yes, but also as an imaging task, but I’ll need to re-confirm that piece. The service had crashed. I’ve confirmed the failure of WOL thru advanced task.
@Wayne-Workman
Just one line:
[:error] [pid 31478] [client :51206] PHP Strict Standards: Only variables should be passed by reference in /var/www/html/fog/lib/fog/fogpage.class.php on line 390, referer: http://fog/fog/management/index.php?node=group&sub=edit&id=1469
The results say the task was created, but nothing listed in active tasks.
@Wayne-Workman
I can appreciate starting simple. There are hosts in the group.
Yes, this would be registering and quick imaging a new system.
Currently the value does not hold in the gui, 1.3-RC5, for the workstation. The checkbox will return to blank when clicking update. The setting is fine for groups.
Ubuntu 14.04.4, fog 1.3 RC5
Individual systems will WOL, but not groups. There is no error in the apache log.
We need this setting for our imaging and most of it is taken care of by groups. The problem comes when imaging individual systems and the need to remember to check that box every time.
Could a default server setting for this be added to the Fog Configuration page, please and thank you.
Yes - all snapins were applied via the group object and then should have applied after imaging was complete (deploy image and all snapins). When the machines did not receive any snapins an hour after imaging I checked the objects and they did indeed have the correct snapins associated. Then I went back to the group object and ran a new task (deploy all snapins) to the group and left for the day. 2 machines received their snapins after that and the rest were sitting in the task queue on the server doing nothing. When I deleted the tasks that weren’t running and (deploy all snapins) on each individual machine they worked… but they didn’t work reliably via the group object
*I’m not really concerned about the domain join. That’s an infrequent occurrence.
The snapins did appear in the tasks que.
1.3.0-RC-4 SVN Revision: 5941
Imaged 15 machines as a group, only 3 got their snapins as intended, one didn’t join domain or anything. Pushed out the snapins (deploy all snapins) separately to each machine and it worked.
reimaged the machine that didn’t join and it worked so looks like groups are broken in terms of snapins.
Same issue.
PHP Warning: PDOStatement::execute(): MySQL server has gone away in /var/www/html/fog/lib/db/pdodb.class.php on line 169
[Fri Jul 15 10:35:44.484182 2016] [:error] [pid 10595] [client ] PHP Warning: PDOStatement::execute(): Error reading result set’s header in /var/www/html/fog/lib/db/pdodb.class.php on line 169
[Fri Jul 15 10:35:45.680441 2016] [:error] [pid 17812] [client] PHP Warning: PDO::__construct(): MySQL server has gone away in /var/www/html/fog/lib/db/pdodb.class.php on line 32
@Tom-Elliott
Version 8603 did the trick!
FYI, when results are first displayed on the page it looks like almost all hosts are returned. Then a second or two later just the members are displayed.
A big THANK YOU to Tom and the rest of the team for the time and effort you all put into this project!
