Posts made by MikeoftheLibrary

@Wayne-Workman said in FOG Imaging Doesn't Respect Max Client Setting:

Multicast performance isn’t really dependent on an awesome server - that’s part of the method. The server only sends one time and many receive.

Your problem is probably poor-quality network equipment you were using for multicast. Higher-end network equipment like Cisco Catalyst would not have these issues. The cheaper the network equipment, the worse multicast will be. It’s total-internal-throughput that matters. If you have an el-cheapo crap 10 dollar switch that is advertised as 1Gbps, it may only have 2 or 2.5Gbps total-internal-throughput. The max it can transmit in and out of all ports simultaneously at any one time. To truly take advantage of multicast, if your 1Gbps switch has 8 ports, it needs 8Gpbs total-internal-throughput. If it’s a 48 port 1Gbps switch, then 48Gbps of total internal throughput.

Networking is the purview of campus IT. However I do know a few things. The closet next to my office has a few Cisco Catalyst 3500 series switches. One was replaced about 18 months ago when the fan quit working. The main switches on campus are connected with fiber optic cable. Everything else is cat5e. There may very well be cat 5 in the walls and coming out of the ethernet ports, but I don’t know for sure. Our work room has a netgear ProSafe GS108 in order to make 2 ports become 9. I also know our network has some sort of traffic shaping system, but whether or not that affects FOG I don’t know. The library public computers (including the FOG server) are on their own subnet with a restrictive ACL. The arrangement prevents our imaging server from interfering with the one campus IT uses. With the exception of the netgear, none of this sounds like poor quality equipment. My feeling is the issue is low quality or old cables combined with a low end server.

Thanks for the clarification, Wayne. I had a feeling it was normal, but wanted to make sure. The setting works fine for us. As far as multicasting goes, the last time I tried it, it took 5+ hours for 5 computers. Of course I was using an old gateway to run FOG. But a semi-old Dell desktop repurposed as a server doesn’t seem any more likely to produce better results. However I may experiment anyway.

We’re in the process of deploying some new computers. In order to save time on the day of the roll out we’re registering and imaging them in advance. In the process we have noticed something odd. If we register the computers with imaging and start several in quick succession, FOG will not respect the max clients setting on the storage node. If you then go to register more computers once the imaging has begun, these clients will wait patiently in line as expected.

We currently have it set to only allow 2 clients at a time. Our server runs Debian 8 in a Hyper-V VM on an older desktop machine (the only spare computer available sadly). Hence the low setting for the storage node. However as I write this, seven computers are imaging at once and not taking much longer than usual. We are using FOG version 1.3.0. It isn’t really a problem for us, but it is odd. Has anyone else noticed this?

Ah yes I see it now. Thank you. Is there any wish list of things to be updated on the wiki?

Thank you for allowing me to have access to edit the wiki. Now that work has slowed down a bit, I thought I’d contribute a little. But … where to begin? The FOG User Guide seems like an obvious place, however I ran into a roadblock there because the list of supported OSes under the “Installing FOG” heading seems to be some sort of an include file. An help would be much appreciated.

After upgrading to Fog 1.2.0, I have update my troubleshooting guide. We did not do a straight upgrade, but rather migrated to a new server entirely, reinstalled FOG, and moved the images over. That process is covered elsewhere so I did not include it. As with the previous version you are free to add to it or share it as long as you include proper attribution.

[url=“/_imported_xf_attachments/1/1367_Troubleshooting FOG 1-2.txt?:”]Troubleshooting FOG 1-2.txt[/url]

It was. Debian creates that line by default. I fooled around with the localhosts file and DHCP config in order to get the isolated network running and in the process changed the former. Perhaps I was telling the computer there was only one machine on the network? I don’t understand enough about computer networking and how a PHP script creates a magic packet to fully answer the question.

Curiously WOL still does not work for uploading images, but since our technician computers are within 20 feet of my desk that is not a big issue.

UPDATE: Well WOL worked once for an image upload. Still not going to worry much about it though.

Today we successfully deployed the FOG server into production, including integrating it with the campus network. Wake On Lan, for both the Wake Up task and imaging works fine. I am not 100% sure what the problem was. My suspicion is that the localhost file (/etc/hosts) may hold the answer. At some point the line which read: “127.0.1.1 FOG Server Name” became “192.168.x.x FOG Server Name”. Not sure why I did that, but the change prevented the computer from properly connecting with the network. Perhaps that was interfering with WOL as well? Others are welcome to experiment and report back their results. While I’m hesitant to call this thread solved without a better idea of the cause, the problem does seem to be fixed.

It actually might solve an unrelated problem. Ever since installing FOG, the ping hosts function on the hostnames page would not work despite having put in the address of the campus DNS server. In version 1.2 it is unbelievably slow so I disabled it. I have not tried to troubleshoot it since we have other software which can let us know if the computers are on. However DNSMasq may be able to fix that. Thank you for telling me about it.

First of all I must add to the chorus of praise about FOG 1.2. The Web GUI in particular has vastly improved and is much more usable. Kudos to the development team.

That said I have encountered an issue which does not seem to have been reported on the forums. In testing out the new FOG server, one of the features we explored was multicasting. It would seem to work. In other words the task would be created, the computers would wake up, the task would execute, and it would seem to complete. But the computers would not boot up. After PXE booting they’d just stop at a blank screen with a flashing underscore and nothing more would happen. Restarting the multicast service did not help. This same image went fine when unicast to one or even multiple computers. Even swapping out the lone cat 5 cable for a cat 5e one did not help. Ultimately I went into Partition Information under Client Information in the PXE Boot Menu and found there was only one partition (not two like there should be), neither was set to boot, neither was primary, and the partition table was loop. In short, it does not seem to have copied the image correctly or at all.

The solution was to use a newer image. The earlier one had been created in FOG .32 using PartImage. I multicast an image created in the current version with PartClone and everything went fine. The computer booted into Windows just like it should. Thus it seems that there is some sort of problem involving images created using PartImage and multicasting.

We will not be affected much. I’ve never used multicasting since it takes too long and we’ll be updating the images before our next round of imaging anyway. But in case others have different circumstances I’ve posted this here.

Here are the server specs:
FOG version 1.2
Debian 7.6 OS
All computers Optiplex 780s

[quote=“Thiago, post: 35967, member: 21790”]disable your dhcp on fog server and configure dnsmasq. i’ve been using dnsmasq for small networks and works like a charm. This can not solve your problem, but don’t disturb your dhcp campus service.[/quote]

So if DNSMasq can’t solve my problem what good is it right now? We’ve already got two campus DNS servers. Admittedly there has been an issue with FOG not successfully pinging hosts, but I will deal with that later.

There are only three computers strung together and not connected to the outside world. All of them are on the 192.168.1.x subnet with a subnet mask of 255.255.255.0. Perhaps the DHCP config file is not correct? When installing isc-dhcp-server, I had the FOG server connected to the campus network which may have caused problems.

[url=“/_imported_xf_attachments/1/1320_dhcpd.conf.txt?:”]dhcpd.conf.txt[/url]

Figured it out. In the file /var/www/fog/lib/fog/WakeOnLan.class.php there is the following line:

[COLOR=#007700][FONT=monospace]if( [/FONT][/COLOR][COLOR=#0000bb][FONT=monospace]socket_sendto[/FONT][/COLOR][COLOR=#007700][FONT=monospace]([/FONT][/COLOR][COLOR=#0000bb][FONT=monospace]$soc[/FONT][/COLOR][COLOR=#007700][FONT=monospace], [/FONT][/COLOR][COLOR=#0000bb][FONT=monospace]$strRaw[/FONT][/COLOR][COLOR=#007700][FONT=monospace], [/FONT][/COLOR][COLOR=#0000bb][FONT=monospace]strlen[/FONT][/COLOR][COLOR=#007700]FONT=monospace, [/FONT][/COLOR][COLOR=#0000bb][FONT=monospace]0[/FONT][/COLOR][COLOR=#007700][FONT=monospace], [/FONT][/COLOR][COLOR=#dd0000][FONT=monospace]“255.255.255.255”[/FONT][/COLOR][COLOR=#007700][FONT=monospace], [/FONT][/COLOR][COLOR=#0000bb][FONT=monospace]9[/FONT][/COLOR][COLOR=#007700][FONT=monospace]) )[/FONT][/COLOR]

[COLOR=#000000]I replaced “255.255.255.255” with the network’s broadcast address and now it works fine. The old FOG server did not require this change so I may have to reverse it before going into production.[/COLOR]

Success! After substituting the broadcast address for 255.255.255.255 and typing the MAC in with capital letters, I was able to use the wakeonlan command to turn one of the client computers on from the FOG server. However a wake up task from FOG itself still did not work (and I’m assuming the same would hold true for imaging tasks). According to WireShark, the WOL magic packet wasn’t even sent.

EDIT: The testwol.php script does not work either.

The wakeonlan command also produces a “network unreachable” error.

[quote=“MikeoftheLibrary, post: 35917, member: 20568”]I had some trouble at the beginning assigning the FOG server a static IP address (the server wanted to think it was on the campus network when it wasn’t), but solved that by creating a network connection with the IP address desired…[/quote]

Actually that wasn’t the only thing I did. First I added the following to /etc/network/interfaces:

auto eth0
iface eth0 inet static
address 192.168.x.x
netmask 255.255.255.0
broadcast 192.168.x.x (not the same as address)

Then I created a network connection with the address and netmask above which has allowed imaging to take place. Taking that stanza out allows the server to connect to the internet and download wakeonlan. It seems to be needed for the DHCP server to work. Could this setup be the problem?

Well I can’t seem to connect to the internet at all. I plug the ethernet cable into a port on the wall (as opposed to the switch) and … nothing. Tried deleting the two network connections to no avail. Since the last time the server connected to the internet, I’ve installed a DHCP server. It’s not running now to avoid crashing the campus network. I had some trouble at the beginning assigning the FOG server a static IP address (the server wanted to think it was on the campus network when it wasn’t), but solved that by creating a network connection with the IP address desired. Perhaps that caused a problem of some sort?

I’ve tried using a different port and a different cable and also removed the following line from the local host file: “127.0.1.1 server name”, but that has not helped.

Back again, this time with a WOL issue. Basically it doesn’t work when initiated through FOG. Whether I start an imaging task or a Wake Up task, a computer that is off will stay that way. The imaging itself works fine, but the computer must be manually powered on.

It is not a network issue. My test network only consists of three Optiplex 780s (server included) and a Netgear Pro-Safe 8 port switch. I was able to successfully wake up the two client computers using a third party tool called WakeMeOnLan. However for some reason the FOG server won’t send out Magic Packets.

The three WOL PHP files look identical to the ones Tom laid out here: [url]http://fogproject.org/forum/threads/wol-and-task-doesnt-work.10529/[/url] . I haven’t changed any settings related to Wake On LAN. I also tried creating the “testwol.php” file. It did NOT work either. And the Apache error logs contain the following lines:

  PHP Warning: socket_sendto() unable to write to socket [101]: Network is unreachable in                                         /var/www/fog/lib/fog/WakeOnLan.class.php pn Line 36.  

So it seems the magic packet doesn’t reach the network when sent from the server. This did not happen with our old FOG server. Does anyone have any insights?

Here are my specs:
Fog Server is a Dell Optiplex 780
Debian 7.6
FOG version 1.2.0

Nevermind. I forgot to add next-server xxx.xxx.xxx.xxx to the config file. The clients now PXE boot fine.