http://bennu/fog Is a service to manage the ITL machines, including imaging all of the machines through multicast, capturing, and managing all of the image revisions. It is an installation of https://fogproject.org/
See [bennu] for installation.
In application configuration is as follows:
ITL images are named as "itl_image_vN" such that n is the revision number. Anything containing test or development is for the corresponding purpose of its substring and should be considered ephemeral. A brief changelog *should* be in the image description field.
Hosts are registered as needed to capture images.
User accounts exist for all lab members who need access as well as the "csimage" account
The csimage account has a password of "fogpassword" this account cannot access teh web portal. It can only deploy images to client machines.
Workflow to capture and multi-cast an image
1. Log in to the web portal
2. Boot into the fog client via pxe (details of this may vary and are left as an exercise to the reader)
3. Select "Preform full host registration" and enter information as prompted
4. From the web portal, select host management, list all hosts, and in the desired host click capture image. You will need to specify an image to capture beforehand in the images menu by selecting "create new image"
5. Boot into the fog client. The image will capture automatically.
6. Now you have an image to deploy. Select the image menu, then select multi cast deployment. Enter the information prompted. Note that the client count must match exactly the number of clients to be imaged. Once the total number of clients specified connect the multicast session will start. If they are not all connected before the timeout period the multicast session will abort.
6. Reboot all machines to image into teh fog client. Select join multicast session. Enter valid credentials, and specify the session name. The clients will then automatically boot and wait for the session to start. Upon completion of the session teen will reboot into the (hopefully) successfully deployed image.
For more documentation on capturing images see from section "Register the Client with the FOG Server" and below on https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image
For more documentation on troubleshooting deploying images through multicast see https://wiki.fogproject.org/wiki/index.php?title=Multicasting
Work on IGMP (no, this is not a typo of ICMP) snooping.
IGMP is a protocol that sets up multicast groups. Essentially, all hosts use IGMP to subscribe interest to the data stream being offered though multicast (the image). Switches will handle ICMP as broadcast traffic unless they can listen in on teh IGMP traffic to intelligently decide which ports should and should not receive frames from a particular multicast group.
IGMP is somewhat of a snowflake as it spans two layers of the OSI model (2 and 3) so nobody is *technically* fully responsible for it. See https://tools.ietf.org/html/rfc4541.
That being said IGMP snooping *should* be able to work by simply designating ziltoid's port as a "multicast router" on teh itl side switch and by designating bennu, ziltoid, and the PoP ports similarly on the server network side.
https://cdn.cnetcontent.com/05/3e/053e5ad7-37c1-4f14-9e64-899aee401cc7.pdf should be carefully considered starting at page 69 (giggity) for any changes to the multicast handing by switches.
Multicast will slow down all of the network (our switches treat it is broadcast, creating a controlled broadcast storm. Any non-gigabit connections ie. vm's may be unaccassesble fro the duration of the session.
If the hard drives are swapped in a machine it will NOT be able to join teh session. Try to correct this before teh session times out.
While waiting for the session to start, and during the session itself 2 cpu cores mine cryptocurrency (bitcoin an darkcoin, although darkcoin was removed in the current release for reasons) to benefit the FOG project in the background. This is a budget-friendly way of giving back to the fog community. Note that the images themselves do not do this only the fog client does.
The imaging process is NOT atomic. If it is interrupted it WILL render all client machines unbootable (until re-imaged)