Posts made by george1421

@BlueTech The schema messages indicates that you just updated from the SVN and the SVN needed to make some changes to the database structure. As you noted, just restart the SVN upgrade install and at the right spot connect to the management console and update the schema. Then continue with the SVN install. No problems here. Tom did make several updates last night and one did update the database schema.

Lets start with some basics.

1. What version of FOG are you using (I assume 1.2.0)?
2. Are you using a SVN trunk version (i.e pre1.3.0), if so what is the number in the cloud on the management page.
3. This image you captured, is it a bios or uefi image?
4. While this is less important now, what OS is FOG installed on?

lets go with those questions for now

What I’m interested in seeing is what is on the screen of the target computer you are trying to boot. If there is a PXE error it should be listed as PXE-XXXX where XXXX is a number. A screen shot of the PXE error would speak volumes to me.

This issue is confirmed fixed

This issue is confirmed fixed.

@Lee-Rowlett Thank you for the clarification. This isn’t meant to be negative, but unfortunately this plugin is not at a level we would be able to use it for what we need. I’m trying to avoid diving into the OS to make changes to the system. I may have to take a step back and look at my multi master model to isolate the sites.

Again thank you for taking time to clarify this.

What is the exact error you are getting?

For the DHCP options, I would set it to both to be safe. DHCP is the most correct since dhcp is an extension of the older bootp.

Is there any specific reason you are using mac reservations? This is not a typical setup or requirement.

What computer (model and mfg) are you using.

@Tom-Elliott Ok that’s right I have to create the definition first. So I’ll have the chance to turn it off. The day has been too long and the brain cells have already gone to bed. This sounds exactly spot on. I’ll give it a go in the AM. Thanks.

@Wayne-Workman I can see it working as you have defined it too. For my specific case, I might want to deploy the image at HQ but not send it to the remote sites until it has been qualified and approved. My specific goal would be to conserve WAN bandwidth. But I also don’t want to make too many exceptions because then programming becomes crazy for every one off condition.

@Tom-Elliott I got sucked into fixing a downed business system tonight, so I haven’t had a chance to test this new build out. But while I was working on the outage I started thinking about this new setting. When you upload an image in the new environment, does it come in published or unpublished (may not be the correct term)? If it comes in published, then depending on the replicator cycle I have no more than 10 minutes (probably less depending on where the replicator is in its cycle) to unpublish it before the replicator. Once the replicator starts sending the file then unpublishing it after the fact is a bit moot. I just want to confirm that when an image is captured it enters the system in as unpublished. It will be up to the FOG admins to publish the image for replication. I can see that we would still want local deployment of the image, we would just want to kill replication of the images and snapins until they are published. (hopefully I didn’t make that too confusing)

The database has the right value.

mysql> use fog;

Database changed
mysql> SELECT settingValue FROM globalSettings WHERE settingKey='FOG_PROXY_PORT';
+--------------+
| settingValue |
+--------------+
| 3128         |
+--------------+

I just confirmed again that it says 1328 in the error log with a fresh request

--2015-12-01 20:26:52--  http://standards.ieee.org/develop/regauth/oui/oui.txt
Connecting to 192.168.1.10:1328... failed: Connection refused.

@Tom-Elliott OK let me hit the database and see whats in there.

@Tom-Elliott said:

Replicator flag has now been added as well. This will keep the image or snapin (or whatever) from replicating to other nodes/groups. Paired with the “enabled” element, it means the image can be fully unpublished, in theory. Not meaning you can’t add/edit the items but rather it will do, I hope, what was requested.

As long as the replicators honor the unpublished flag then we should be good. This should keep the image on the master FOG server until we have it approved for deployment.

@Tom-Elliott said:

So without any further ado, I am pleased to state that this is now added. I even made the selectors know about this. Meaning that the drop down lists will display only enabled items if the isEnabled flag is within the class. That also means it could be relatively easy to port to other classes/plugins too.

In either case here you go and I hope it does what you want/need.

^^ I wish I could up vote this 100 times. Well done!! I’ll check this out to see how it works a bit later. But this will help us by allowing us to keep our FOG environment simple (i.e. without isolated dev FOG server, complex scripts to hide or move images around).

I just checked the proxy server and the request is not hitting it, then I noticed something in the error message.

192.168.1.10:1328...
The port number is wrong it should be 3128. Thinking that I’m a bit dyslexic I checked the proxy settings in fog and the value is correct at 3128. I checked the bashrc file and those settings are correct too. I don’t know where the 1328 is coming from.

@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.

Just trying to tidy up, can we marked this as solved?