Posts made by george1421

The first thing you need to remember is FOG uses other opensource products to make the FOG system.

There is not super tight integration between FOG and the udp-sender service that fog uses. So the web gui is only aware of limited things.

During the power off of a host in a multicast session the rest of the hosts still connected to the session experienced a severe drop in speed. I understand the drop in speed is how the system was designed but the disconnected host stayed in the task list and never notified the fog server it had disconnected and none of the other hosts returned to their previous imaging speed.

This is understandable to a point. The upd-sender service will know when a target system disappears. While the image IS sent out as a multicast, the client does respond via unicast with a byte or checksum count (not sure which). That “checksum” tells the upd-sender service if the client needs that data block over again or not. When that host disappears everyone should slow down so that the rest don’t get too far ahead in case the lost client was only momentarily interrupted. What you are seeing is expected. What I might also suspect is that the upd-sender service “should” give up on a lost target system and return the group to normal speed, but that is not what you are seeing. It appears the timeout never happens so every one stays at a retarded transfer rate.

The other question I am having is when the host is powered back on and the multicast session is still in the task list, the host will boot into Partclone and perpetually waits for the multicast session to start although the multicast session already in progress.

This is true. The developers would have to look into upd-send to see if they can get a status message of who is still online or not. A lot is dependent on how upd-send can communicate with the outside world.

Should the host eventually time out and leave the session and report back to the WebUI that the session has failed?

That is an excellent question I would hope that if the target system hadn’t joined the multicast stream in 10 minutes, it should request its task canceled and then reboot.

@uwpviolator Sure no problem, but I hate to disappoint you the stuff is not very sexy.

In the setupcomplete.cmd file I have this line.

if exist "c:\drivers\drvinstall.cmd"  call "c:\drivers\drvinstall.cmd"

If we have .exe type drivers that we need to install on the target computer then we will place the .exe files in the drivers directory with the drvinstall.cmd batch so they are copied to the target computer when the rest of the .inf drivers are copied over.

Here is an example of a drvinstall.cmd batch file.

@echo off
echo Please wait wile we install some things you'll need
%~dp0\Bluetooth\Setup.exe /quiet /passive /norestart
%~dp0\WiFi\setup.exe -quiet -passive -norestart 

One other (new) thing is we looked at how we were installing the drivers via pnputil. We have a bit cleaner command syntax.

pnputil.exe /add-driver "c:\drivers\*.inf" /subdirs /install

@awellis I have some sad news for you. I setup a clean 1.5.0 fog environment and multicasting works “as described on the tin”.

Is your fog server in a virutal environment?

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.

@amadrigal I reread your thread again to make sure I did not mention this since I see you have pfsense. I did a proof of concept tutorial about using pfsense as igmp proxy here: https://forums.fogproject.org/topic/10117/fog-casting-across-vlans-subnets

On my task list for today is to setup my sandbox servers to test a few things with FOG 1.5.0, pxe booting, and multicasting. I will run through my tutorial on fog casting to ensure its still accurate. I’ll let you know if I run into any problems. I’m going to use centos 7, fog 1.5.0, pfsense 2.4.2.

@janspook I’m going to test this today. The 1.4.4 iPXE kernels should work correctly. The instructions were created using 1.4.4.

@awellis So just for clarity, if we discount all of the debugging you’ve done up to this point. if you shutdown the centos firewall and then setup a mutlicast job with 1 client the client just sits there an never joins the multicast?

I have it on my task list to spin up a new fog server to retest multicasting across subnets again. My OS of choice is centos. So the system I’ll spinup will be centos 7.4. I’ll do everything in a virtual environment to make it easy on myself.

@awellis Are the fog server and target computers on the same subnet.

@awellis can you drop the firewall all together until you can get multicasting working? If you need the firewall per company policy we can reverse engineer what ports are being used.
systemctl stop firewalld

@awellis said in FOG Multicast Not working:

whereas the initial firewall setup

Will you explain this statement? What firewall?

@uwpviolator Putting a 5 or 10 second sleep would not hurt. That would give the drivers a chance to init before you make pass Next.

As for self installers, I would tag them onto the end of the setupcomplete.cmd file. Just make sure you are sure of the silent install switches.

I do something a bit more complex with my setupcomplete.cmd I have it check for a certain batch file name in the c:\drivers directory. If that batch file exists I call that batch file towards the end of the setupcomplete.cmd file. Remember that directory comes from the fog server with hardware specific drivers. Well if there are self extracting .exe installers in the driver pack that are hardware specific I include them in the driver directory on the fog server. Those get copied over and the setupcomplete.cmd file will call the batch file in the c:\drivers directory which installs the hardware specific .exe drivers and applications.

@uwpviolator I’ve found that I need to call that pnputil 2-3 times to find all hardware hidden behind other hardware.

I agree that 1709 did some bad things to the non SCCM image cloners.

The short answer for this is to create a custom fog iPXE menu (using the web gui). This will chain back to your organization’s pxe server. Then from FOG you would set this new menu item as the default.

So the idea is your default pxe server chains to fog’s ipxe. If FOG has something to do it will do it, if not the default action for the FOG menu is to chain back to your organization’s pxe server. Just be aware you will need to chain back to a point where the pxe client won’t turn around and chain back to the FOG server again creating a chain loop.

@mmoore5553 When you get the second nic installed let me know and I will give you the instructions. The setup is not hard you need to know the name of your physical ethernet adapter (eth0 or what ever your kernel calls it) and then set a default route on your second nic pointing towards the internet. Ensure your physical LAN adapter has a static IP address set for the imaging network. And finally use the git method of downloading the installer files. During setup the installer will ask you for the name of your imaging network adapter (not in those words) you just need to ensure its your physical LAN network adapter name. The rest will be installed correctly.

@george1421 Confirmed these applications exist on my test synology nas (I’ve done bad things to this NAS so it might have the kitchen sink too).

du is installed and available.
awk is installed and available.
sha512sum is installed and available.
head is installed and available.
tail is installed and available.

They also exist on my production synology nas.

@tom-elliott Now that’s service!!

I can say for the synology nas, you have to install php as a package. I’ll confirm that the other utilities exist.

@mmoore5553 I would agree, the hidden file is create in /opt/fog called .fogsettings (the dot in the beginning of the name makes it hidden). If that file does not exist then the FOG installer did not complete. So you have a botched install.

Recommendation: If you were to reinstall the FOG server, use debian instead of ubuntu. Connical has been doing some bad things with ubuntu lately causing us pain. Ubuntu is based on Debian so all of the install commands work the same.

@mmoore5553 You can fix what is there now, and then add the usb network later. Its just easier to do it in the beginning. But reinstalling to just fix what is wrong is more effort than fixing it.

You will need to edit the following files to fix what has been changed.

Correct the fog server IP address here:
/opt/fog/.fogsettings
/tftpboot/default.ipxe
/etc/dhcp/dhcpd.conf

Then in the webgui you need to go to the fog configuration settings. Pick the Expand all options and then search for the old fog server IP address, change and then save the settings. I think its in 3 places under fog settings.
Lastly in the storage management -> default storage node you need to fix the IP address there too.

It should take you about 10 minutes to fix then reboot the fog server.

@mmoore5553 Well you have a mess to clean up

Well not really. FWIW if you want to have a dedicated imaging network but have fog able to reach the internet for installation (only needed for that) then its ideal if you install a second network adapter in your fog server. When you install fog you will tell it to only image using network adapter X while network adapter Y has internet access to download the required files. Once the files have been downloaded you can unplug the second network adapter until you need to update fog, if you have security concerns. Or you can use the second network adapter for FOG management. That bit is up to you.

If this is possible in your environment I can guide you on how to set it up.

@mmoore5553 So then there is a possibility that the FOG server’s IP address/subnet mask has changed?