Posts made by tian

In SVN3696 and SVN3710 the Group Service Configuration is working correctly - thanks for fixing it.

(The 2nd case seems to be related to cache stuff since when refreshing the Service Configuration Page by F5 shows the correct settings again)

I’m running fog svn on Ubuntu 14.04. Before the svn update, the system updater was run and the system was rebooted.

When updating from svn3575 to svn3696 the fog installation hanged for more than 30 minutes at (other packages were all in the state “Already Installed”):

* Installing package: php5-fpm..............

I canceled the installation and tried to run again - then it failed at:

* Installing package: php5-mcrypt.....................Failed!

Installing “php5-fpm” by apt-get failed because it told me the dpkg process was cancelled and I should run “sudo dpkg --configure -a”. After this I could install php5-fpm by apt-get an run the fog installation script till the end.
Didn’t test that much yet, but it seems to be OK now.

Maybe it could be related to svn3609 (“Allow the output of php5-fpm to prompt user what to do”).
If it is not related to fog and it is just another strange behavior of Ubuntu 14.04 this might also just be ignored…

Just did a group download task (instant deploy) with SVN 3575 - and the basic snapin behavior seems to be fine now.
The snapin tasks are displayed and applied correctly. To put the computers in the domain also is faster (tried the new fog client with this svn)

Thank you very much!

(I hope next week I can test a scheduled group download task run and the the behavior with the the deletion of a download task when deleting all (to a host) connected snapin tasks)

forgot to mention that the “Service Configuration” seems to work fine for hosts directly

Hi,

These are the settings I want to use on the hosts of the group but can’t get set for a group:

I’ll refer to these check boxes with 0 to 4 (up to down)

There seems to be problems with the service settings for groups:

• case1 - one check box deactivated after click on “Update”:
  • check boxes active: 2, 3, 4 (and set in the host service settings)
  • new check box selection: 0, 1, 2, 3, 4
  • click on “update” -> result: 1, 3, 4 (displayed on the page and set on host service settings)
  • select “2” additionally -> “update” -> result: 2, 3, 4 (displayed on the page and set on host service settings)
  • (if just 1 and 2 are reselected and update is clicked, it is like a loop …)
  • (de-)selecting other combinations have another pattern - it even deactivates one check box if less are checked
• case2 - not reading current/last updated settings correctly:
  • check boxes active: 2, 3, 4
  • new check box selection: 0, 1, 2, 3, 4
  • clicking on one or more different Link below “Group Menu” (e.g. “General”) without clicking update
  • going back to “Service Settings” -> 0, 1, 2, 3, 4 still selected (but not applied on the hosts of the group, clicking “Update” see case1)

If there is more I can provide/test just ask.

It is not that urgent since its not influencing the imaging or some other important stuff.

An option (like “image size: on server”) to choose the columns for the snapin log on the web page and PDF export would be great, but not that simple to implement I guess.

Would it be possible to add the Check-in Date, Check-in Time and the host name to the display in “Snapin Logs” in the SVN (and future 1.3.0+) ? Currently there are just the Creation Date and Time by default.

I use the Snapin Log very often to verify various Snapins on multiple Hosts. In the csv-export all the information are there but its not as comfortable as it was/is in fog 0.32 anymore.
I could change it by myself in the ReportManagementPageClass.php but this will eventually be overwritten by a future fog update. A custom report I created is running somehow - only the csv/pdf export could not be made working in the custom report.

Thanks.

Thanks for the fast response and that great program in general.

I tested SVN 3562 and SVN 3563. The snapins now appear correctly after a single host download task (instant and delayed) is started.
But for group download tasks the snapins still don’t appear in “Active Snapin Tasks”.

And I found another bug with snapins run by a download task (instant / delayed):

• After all snapins, that have been run with a single host download task, are deleted/canceled from “Active Snapin Tasks” , the download task vanishes from “Active Tasks”.
  • The download task vanishes either when it is queued or already downloading (tested with active download in b3563 only since in b3562 the pxe-boot seemed to be broken and and things have been reset to an earlier svn).
  • After finishing the image download it can’t complete correctly and repeats the message “No Active Task found for Host: test (MAC_address_from_test)” when trying to update the “Computer Database Status”
• The download task will be still there if 1 snapin task from the host is left in “Active Snapin Tasks”.

just updated to SVN 3559 and created another scheduled task - after the task was run, it was the same behavior as before.

Additionally I tried download tasks for a group - I noticed the following:

• scheduled download task: tasks appeared in “Active Tasks” at the given time, no snapins added/active
• instant download task: tasks appeared in “Active Tasks” directly, also no snapins added/active

When scheduling a (single host) download task, it is triggered correctly and the download task appears in “Active Tasks”. But the snapins linked to the host do not appear in “Active Snapin Tasks”.
(Scheduled download/upload tasks are also is kept in “Scheduled Tasks” with “Ran at: …” in the “Start Time” column - don’t know if this is behavior is ok)

Starting the download task directly by Instant Deployment adds the snapins correctly to “Active Snapin Tasks” and runs them properly after downloading the image created.

This behavior also was like this in some svn version before. I’m not sure about the stable version 1.2.0 anymore.

The fog server runs on Ubuntu 14.04. The 4 fog services, mysql, tftp are all up and running - all of them are delayed at startup by rc.local .