Database driven package creation?

  • Hello new forum. Note the new handle. With Christmas coming I’ll not be doing much php coding until after the first of the year.


  • Developer

    1. That sounds fine. Let me know if any code needs to change in FOGController or FOGManagerController

    2. You should have a look at the latest code i have submitted. I have made a lot of changes to how Tasks are generated.

    $Host->startTask was written by microleaks, but never put into prodution. The old production code was in ‘management/includes/tasks.confirm.include.php’’

    Task creation is now handled in Host.class.php. There are 3 functions for instant deployment, single run scheduled deployment and cron style deployment:

    [code]$Host->createImagePackage($taskTypeID, $taskName = ‘’, $shutdown = false, $debug = false, $deploySnapins = true, $isGroupTask = false)
    $Host->createSingleRunScheduledPackage($taskTypeID, $taskName = ‘’, $scheduledDeployTime, $enableShutdown = false, $enableSnapins = false, $isGroupTask = false, $arg2 = null)
    $Host->createCronScheduledPackage($taskTypeID, $taskName = ‘’, $minute = 1, $hour = 23, $dayOfMonth = ‘’, $month = '’, $dayOfWeek = ‘*’, $enableShutdown = false, $enableSnapins = true, $isGroupTask = false, $arg2 = null)[code][/code]

    There has been a new class to handle “TaskTypes” (aka download, upload, multicast, wipe, av, etc) and this class reads it’s information from the ‘TaskTypes’ table. You are able to specify custom kernel and kernel arguments per TaskType.

    GUI code for Task creation is in HostManagementPage.class.php & GroupManagementPage.class.php
    (functions deploy() & deploy_post() handle the calls to the Host functions.


  • Getting back to work on PxePackage.

    I did a little work on PxePackage over the holiday, and I’ve come up with 2 questions.

    1. (more of a plea). Would you consider accepting a design where the PxePackage class shared a table with related PxePackage subclasses? I had posted some code based on that design [URL=‘’]here[/URL].

    You did not like the design in part because it broke the one FOGControllerManager to one FOGcontroller relationship, and also due to concern that the calling code would need to know the subclass in order to get the call right. I think I can answer these objections, and would like to continue with the PxePackage and sub classes design because it simplifies the code to generate pxeconfig for fog tasks. It also creates a relatively clean route to extend/modify PxePackage to work with other pxe-bootable systems.

    I propose 2 steps to address the problems of the multi class design.
    First write a manager for each PxePackage controller subclass. The subclass managers can be one liners:
    [PHP]class PxePackageFogManager extends PxePackageManager {}[/PHP]
    Second create an interface that PxePackage and it’s subclasses must implement as a means of enforcing consistent method names and calling.

    The idea is that calling code can always use PxePackageManager. The returned object could be either a PxePackage object or a PxePackageSubClass object,but the calling code won’t need to know or care about the difference.

    1. My second question is how is multicast handled? Will there be a multicast class? I wrote some preliminary code for PxePackage->getPxeTask($task) and am able to retrieve all the needed information through the task object except for the multicast information. In Host->startTask the multicast data is passed through the extra optional args. Perhaps a more OO design is possible?
  • Developer