@Tom-Elliott Sorry for the continuing questions, but isn’t curl http based? Does FOG use curl for other off site requests? Just trying to establish a pattern here. Either curl needs its environment setup for proxy support. From the error it appears that its attempting to use the proxy but for some reason its rejecting the request.
I’ll see if I can get access to the error logs from the proxy server. Hopefully it will give me a better idea (like a malformed http request ??).
@Tom-Elliott what method is FOG using to get the file wget, or some other process. I’m not doubting that this proxy is a bit finicky with the ftp process. If it is ftp then I’ll need to get a variance.
I’m unable to update the OUI entries in the 5572 release. This may not be a flaw in FOG depending on how the file is requested (suspect protocol FTP). My FOG systems sit behind a proxy server. I can say that FOG can communicate through the proxy server because the FOG installs and current version report correctly on the management login page.
FOG Configuration->MAC Address list->Update Current Listings
0 mac addresses updated
http error log
--2015-12-01 19:21:04-- http://standards.ieee.org/develop/regauth/oui/oui.txt
Connecting to 192.168.1.10:1328... failed: Connection refused.
[Tue Dec 01 19:21:04 2015] [error] [client 192.168.1.43] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/fog/fogcore.class.php on line 12, referer: http://192.168.1.88/fog/management/index.php?node=about&sub=mac-list
Using the LDAP plugin -> Create New LDAP. I filled in all of the fields but after pressing the Add button the DN contents are blank (going to another menu and returning the information is not displayed either). Entering the missing DN information on the edit page and then pressing the update button writes the data to the database.
There appears to be an issue with the add button, but works correctly with the update button.
@Tom-Elliott said:
It is a viable plug in it just is not usable via database.
@Wayne-Workman Yeah, this has me a bit confused. I read what Tom said as: its fully functional but you can’t configure it. I checked and I can’t seem to find a wiki on how to set this up.
I would also suspect the hard drive. Using other image deployment tools, I’ve seen them get part of the way through the image deployment and then bomb out (like ghost). It is usually related to a bad hard drive. We would just swap a hard drive in the system from inventory and reimage. If the imaging process went through then we would tag and discard the old drive. Based on my experience 4-5 years on a consumer hard drive is typically where we start to see system errors.
If that system is a normal business system and is 4-5 years old, that would also increase the chances the hard drive has some bad sectors.
Yes the files are there now, thank you. I did update everything this AM before posting and the tftp stuff wasn’t installed. This will save having to hack a full fog install into a storage node. Thanks again.
I did capture an error during the update that didn’t seem to have an impact on the tftp install.
* Setting up storage..........................................OK
* Setting up and starting DHCP Server.........................../lib/common/functions.sh: line 1264: [: : integer expression expected
Skipped
* Setting up and starting TFTP and PXE Servers................OK
* Setting up and starting VSFTP Server........................OK
Now I’m off to test the installed tftp files…
@Tom-Elliott The missing files are the entire /tftboot folder as well as installing the tftp service and updating xinetd (rhel specific). I’ll update one of my storage nodes right away and see if all of the bits are in place now.
Thank you!
@Tom-Elliott So then do I understand this is not a viable plugin just yet?
I need to limit certain deployment techs to specific storage locations so that techs from site A can’t deploy images or snapins to site B on accident (or intent).
@bacelo Again, what is 10.1.8.254 ?? Who owns it?
That is the device you need to set dhcp options 66 and 67 in/on. Once you do that, the pxe client should boot into the fog menu. My intuition is telling me that 10.1.8.254 is your firewall/internet router.
Once you get that working, you MUST make sure that the dhcp server in fog is not used or you will have IP address conflicts.
@bacelo said:
well the fogserver ip is 10.1.8.1
Interesting, I though I would have seen this address in the PXE header. What is host 10.1.8.254? That is the object that is managing your DHCP for your site. If your fog server is 10.1.8.1 and you have it setup for dhcp, but your addresses are being handed out by 10.1.8.254 then your bootp values are probably not getting to the pxe client.
Just for accuracy we can mark this solved?
I hope your issue will not reoccur. If its something related to FOG or the installer again, please post back to a new thread. Cheers.
@bacelo The error indicates that the tftp process could not download the file that is defined. Can we safely assume that 10.1.8.254 is the IP address of the FOG server (one might think that the .254 may be a router address in some installations)?
Right now I’m not saying do or don’t start over. But this has been an issue for 11 days now. What is going on is not normal. There is something wrong with this build. It could be that you are using a NAS for storage for FOG (I simply don’t know since I have not setup this situation). All I’m saying at some time in the (near) future you will need to deiced to just “cut bait” and start over or continue on and spend more time on this and not on deployment.
@guille_elia I do see some timeout command line switches that may be useful, but the wget response is a bit confusing to me. It looks like it tries the 192.30… address then it transfers to the 54.231… address and then finally download the file. From start to finish it looks like it took 52 seconds to actually get the file once it was located.
Here are the timeout options with wget. Its not clear in my mind which one is at fault, since I don’t know what the default settings are. But I’m suspecting it was near the 302 redirect message.
-T, --timeout=SECONDS set all timeout values to SECONDS.
--dns-timeout=SECS set the DNS lookup timeout to SECS.
--connect-timeout=SECS set the connect timeout to SECS.
--read-timeout=SECS set the read timeout to SECS.
-w, --wait=SECONDS wait SECONDS between retrievals.
--waitretry=SECONDS wait 1..SECONDS between retries of a retrieval.
--random-wait wait from 0.5*WAIT...1.5*WAIT secs between retrievals.
For better or worse here, I have to be the voice of reason: At some point (in the near future) you have to make a decision to continue down the path to try to fix this install, or just abandon it and spin up a new fog instance and manually copy the files across.
IMO something is botched with this OS install. This system should not become unavailable like this. How much effort are you going to expend on trying to revive this system, where spinning up a new OS and fog install can be done in about 30 minutes.
@Wayne-Workman That’s what I thought. There is no need to do extra stuff (again, trying to stay out of the OS as much as possible) for the non-technical / wiki following FOG installers. Its a simple change (in my mind) to the installer script that would make the storage nodes a bit more versatile with little to no expense in time or effort. I’m not seeing a performance or security issue by installing the pxe boot files or tftp service (other than every service that is installed is a potential attack vector). Everything we do out of band (i.e. doing a full install then hacking it later) risks brining in errors and extra work to maintain: IMO)
@Sebastian-Roth http://<for_server_dns_name>/fog/management/index.php?node=accesscontrol&sub=add
@bacelo said:
yes, I think so
That is not a reassuring answer. Where do your clients get their dhcp addresses from?
Are the clients on the same subnet as the FOG server?
