Issues discovered in FOG 1.5.0

[george1421]

This post is to just document “things” I experienced during testing. This should not imply there is an issue, only observances.

1. When you abort a multicast session from the FOG server the udp-sender service continues to run and is not aborted when the task is canceled.
2. When in image management and selecting multicast image. Should define (somehow) “Timeout (minutes)” if 0 minutes are entered that means wait forever.
3. In Image Management->Multicast image, If you try to reuse a session name (i.e. sess3) a second time, when you press Start the panel repaints but the task is not added and no error is thrown in the ui. Error thrown in apache.

[Wed Mar 28 10:41:06.450537 2018] [:error] [pid 1410] [client 192.168.100.167:52943] PHP Warning:  trim() expects parameter 1 to be string, array given in /var/www/html/fog/lib/fog/fogbase.class.php on line 1382, referer: http://192.168.100.205/fog/management/index.php?node=task&sub=activemulticast

4. (not an issue only stating) Multicasting will not work through a standard router. FOG Server interface IP is 192.168.100.1 on an isolated imaging network. Multicast channel uses 232.168.100.1:60304 it also uses 224.0.0.1:60304 to announce the start and stop of the stream or as a locator beacon.
5. (not an issue) Scheduled a multicast deployment and pxe booted target computer and selected active multicast session. Target was on opposite side of router than fog server. Target did not start imaging and sat there. FOG server was sending out a multicast announcement. No imaging was going on. I’m using pfsense as a straight router, with firewall rules off. I even created the allow any any all, rules for both wan and lan interfaces on router. No imaging. While things were pending, I enabled the igmp proxy in the router. As soon as igmp proxy was enabled the target started imaging. This kind of proves in my mind that you can only image across a router if it supports native igmp routing or you are using an igmp proxy service on the router, much like a dhcp-relay services helps dhcp across a router.
6. Creating a multicast session with a client count of 0 (fog default). Results in a session being created on Start Multicast Session page of image management. Switching over to active multicast tasks shows no active session. I “believe” since client count is 0, the session is created, but since client count is 0 the session terminates right away. Suggestion to either trap a zero client count, or change the default to 1 client.

[Tom Elliott]

1. Can you show an example? There are two points that are started. First is just a mechansim to start the real commands.
2. Timeout 0 does mean wait forever I believe. I can add text expressing this rather simply.
3. I’ll work on it, though it’s not necessarily an issue persay. You’re just concerned that you get no feedback correct?
4. – without this it renumbers.
5. – without this it renumbers.
6. Multicast sessions are separate items from Multicast tasks. This is because we have no mechanism to know which hosts are due in a session (as the session can be any host you want). That’s not to say the task won’t appear in multicast tasks however, but only when actual clients check in should this happen. Is this what you’re saying isn’t happening?

[george1421]

@tom-elliott said in Issues discovered in FOG 1.5.0:

1. Can you show an example? There are two points that are started. First is just a mechansim to start the real commands.

This is easy to see without any log files. Start a multicast session like normal. Then when imaging is underway, cancel the multicast task. The target system continues to image until complete. Well, until the image push is done, then it fails with:

2. Timeout 0 does mean wait forever I believe. I can add text expressing this rather simply.

When timeout is 0, the code appears to enter a maxwait of 600.

/usr/local/sbin/udp-sender --interface ens224 --min-receivers 1 --max-wait 600 --portbase 51954 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win10E1709F/d1p1.img

When timeout is 90, the code appears to enter a maxwait of 600.

udp-sender --interface ens224 --min-receivers 1 --max-wait 600 --portbase 50328 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win10E1709F/d1p1.img

3. I’ll work on it, though it’s not necessarily an issue persay. You’re just concerned that you get no feedback correct?

On this one, I was just trying to reuse the name sess1 over again, are the session names one shot? Even after they have been completed? It did cause some confusion. I filled everything out (with a reused session name) pressed start and the frame refreshed but nothing happened, no task down below, no warning message. No hey dummy…

4. – without this it renumbers.
5. – without this it renumbers.

6. Multicast sessions are separate items from Multicast tasks. This is because we have no mechanism to know which hosts are due in a session (as the session can be any host you want). That’s not to say the task won’t appear in multicast tasks however, but only when actual clients check in should this happen. Is this what you’re saying isn’t happening?

If you create a task and forget to change the # of clients such as this:

When you go to Active tasks there is nothing running

I think we should default the # clients to 1 not 0 and or trap if someone sets the number to 0.

[Tom Elliott]

@george1421

1. I’ll take a look at this, though I wonder if we really should stop the process if it’s already started grabbing data. Stopping would cause the issue an issue where the machine is basically in limbo and unuseable.

2. I’ll take a look at this as well, pretty sure it should work but it’s been a few.

3. A session name can only be used once in active state. Meaning if you create session test and immediately try creating another session with the same name it should fail. When a session completes, however, the name is blanked out so you could use it again. Sometimes this may take a few seconds as the multicast task manager service handles all of this. Sim not aware of this not working though so it’s possible this is not happening and I didn’t know about it until now.

6. When client count is set to zero it auto defines the count to the number of hosts you have in the GUI. The count you see on the image page is how many are currently receiving an image. Is this where you’re saying it’s not working?

[george1421]

@tom-elliott

1. I agree that this one is probably a non-issue. Let the task run to completion and be done with it. updcast does support a kill switch if you have it write a pid file out. But the docs say that even if you send the kill switch it will continue with any stream in progress then die.

2. OK

3. The client count appears to create the task then it dies right away or if client count == 0 the task is not created. Its easy to duplicate the issue in your dev environment. Just give it a session name and hit start. You will see the task down below but then go to running multicasts there isn’t one ther. If you try to reuse the session name I get the same as if the session was created. I think the easiest fix is to set the client to default to 1 instead of 0.

[Tom Elliott]

I’ve taken a look and indeed the count client code was missing, probably from the revamp work overall (sorry for that).

I’ve readded that if client count = 0 it will set the count back to the number of hosts in the system. (as was originally intended.) This should correct that action of it all.

Thank you for reporting. Working-1.5.1 has this change and will be reflected in 1.5.1 when we officially release.