Adrian,

All new requests should be placed on the fogproject forums here. The information on sourceforge was let up for historical purposes, records. It would not have been easy to move all the information from SF to here, but we didn’t want to delete any of the information either.

Hi,

In my opînaion, this is heavily linked to the use of partclone instead of partimage… So this is work in progress I think 😉

Those are just notices, that were not necessarily shown before. I doubt they make FOG not work properly. If you have reference passing to change, the trick is something along the line of sed -i ‘s/&$tmp/$tmp/’ *.php 😉
If you just want the notices to go away, you need to change error_reporting in your php config. E_ALL

Added this to quick inventory screen as it was very simple. Thanks Lee!

I have already “half” coded this into the init.gz if anyone wants to pick it up.

[url]http://fogproject.org/forum/threads/backup-feature-for-user-profiles-data.4264/#post-15326[/url]

I hadn’t even thought about that, It’s a great idea Tom!

I already have a fix in place for this. In creating the pxe delete host option, I now know exactly where to go.

The file you’ll need to edit would be within the init.gz file, if you’ve already added the delete options, this will take just a couple lines of code:

When it says unable to register host as it already exists, call the fog.auto.del script, it should take over from that point, within the fog.auto.del post, it will ask if you want to re-inventory of where you can change the hostname. This should be useful, though I don’t have time to test all aspects.

I wouldn’t be opposed to letting users put in a primary user, other tag 1, and other tag 2. I get frustrated sometimes when I can’t put this in through the webUI because an inventory job has not been run yet, either as a separate job, or as part of the registration process.

This could be as simple as displaying the labels and blanks and update button even if no related record exists in the inventory table.

In FOG 0.33, the host no longer has an OS. The OS is tied to the image.

I have modified the script in the init.gz to truncate to 15 characters and warn if truncation was necessary. I still have not modified the webUI to limit the field in html, or to truncate the value in the processing of the form data.

I agree this would be nice, and for the most part, I never need over 15 characters. Maybe this could be configurable through the FOG settings for a max host name length in case there was some need to have it longer than 15. There is a limit due to the field size in the datastore also, but that can be queried to make sure the UI or registration scripts are not exceeding that.

As an update to this,

The hostOS field is no longer a part of the Database schema. I’ve already made corrections to the to the auto.register.php file to allow host registration as with SVN r899, it still tries to insert data into the hosts.hostOS table which does not exists. Because it fails, the script keeps attemping in a, seemingly, forever loop, but in actuality you can edit the auto.register.php file while the host is attempting to upload to inventory. Take out the reference of insert into hostOS and the process will complete just fine.

We considered this as well for certain tech savvy staff but ended up choosing not to. A phone call or support ticket into IT and we can set a PC to reboot and image from here with the web gui. Still quick and easy.

[quote=“mlb2009, post: 15450, member: 13741”]Windows 7 support will also be good[/quote]
Windows 7 is already supported in 0.32, and as such would be supported in 0.33

I agree. The web UI is pretty feature rich and well thought out.

Meraki = Free and Easy

ok… i agree with all those changes / requests… however i think 9 is currently possible. I believe you would need to modify the init.gz to include what you want done… so for example, i use debug-deploy to change the MTU size to 9198 to take advantage of jumbo frames then launch fog from the command line to start the image.

I am seriously considering modifying the init.gz to make this happen from the standard fog process of deployment.

from a programming point of view, I think it is possible to give it steps to do, you would just end up with a heavily customised fog installation which would be useless if you went to upgrade to support new hardware / software…