Web UI is, obviously, now functional and all.

Is all working properly I’m assuming. Just trying to gain closure on the bugs if at all possible.

I’m guessing you found this issue? Changing the IP of the storage node should help you out. NFS itself is not set by IP, linking to the NFS is related to IP which is received by the Storage node information.

This is a FOG 0.32 issue specifically and can probably be safely closed from further comments. While people will still see this in 0.32 installs, it’s not relevant in 1.x.x anymore.

While a long time coming, I’ve added these suggestions to all three of the init.d files.

While old, I think it’s worth mentioning here if only for documentary purposes.

The /opt/fog/service/etc/config.php file now only contains a pointer to the FOG Servers FOG Web GUI information. This means what’s stored in the commons/config.php is the same info used for the FOG Service files. I’ve made great strides in adding the relevant sql questions and updating the information as well and believe it’s fairly safe to close this particular bug as resolved.

Over the next few months I’m going to try getting my C# hat sharpened and fitted so hopefully I can help more with this.

Current INIT’s should be good to go with clamav as well, but it’s likely outdated again as they keep having updates.
I’m rebuilding with 0.98.3 at the moment though so hopefully 1.1.2 or 1.2.0 or whatever release we have next will be fully updated again.

The GUI is the most appropriate place to schedule/setup the tasking.

That said, it should still be possible to setup tasking directly via the command line within the client you’re trying to perform the task.

However, it’s not very simple as it is unlikely your system has enough RAM to store the image. Process should be:
Mount /images/dev
Make a directory within the mounted /images/dev to store your image
make a backup of your mbr and store it in the location.
make file input file output interface (mkfifo)
Translate and obtain image through that fifo file to the storage location (Partclone or Partimage)
You’ll likely need to do this for all partitions you need the data from.
Once all of that is complete you’re fairly safe to reboot the client machine.
You’ll then need to copy or move the /images/dev/<FOLDERNAME> to /images/<IMAGENAMEPATH>

THere is a normal file format standard for fog. (Assuming multi-part image type)
d{disknumber}.mbr (e.g. d1.mbr d2.mbr) Is the mbr naming convention for the disk.
d{disknumber}p{partitionnumber}.img (e.g d1p1.img d1p2.img d2p1.img d2p2.img) Is the Naming of the actual image data.

For resizable images the name is:
(For standard base install of windows 7)
rec.img.000 (the 100MB recovery partition)
sys.img.000 (the main data patition)

If there is no 100MB recover partition and you have only the one partition the only file needed is
sys.img.000

Hopefully this helps, but it’s not very straight forward. It’s much easier to use the GUI to schedule the deployment job you need for both Upload and Download tasks.

Hopefully this is working better for people since moving to iPXE vs. PXE.

This is probably still a problem. I think it’s because on upload it’s actually trying to get all the relevant data. I haven’t tested much though so maybe it is working right now?

This problem is still present, but really only affects FOG setups who allow login across actual internet sources. Typically speaking this vulnerability really only affects malicious insiders trying to bring down an org, and won’t normally pose the problem.

With that said, I’ve been working towards using mysql prepared statements but this will take quite a bit of work as much of the system was coded with the old procedural style of mysql php functions in mind.

This is still a problem, though I haven’t had much time to look at C# or learn it rather. I will attempt over the next few months at my take of recoding/working the FOG Client Scripts.

This is old, but warrants and update I suppose.

It’s been fixed for quite some time though.

[quote=“Dave_A, post: 30281, member: 24638”]Wouldn’t it be possible to add a step to the image-collection process, that grabs the partition map of the source via Linux fdisk or parted, and pushes it up as a text file with sys & rec images - then pull down and parse that file in the restore part of the script, to recreate the original map??[/quote]

Yes, that’s very possible. The problem is, the mbr is what determines the size of the disk, so after “re-mapping” the drive with the MBR data, it would be limited to the size of the original disk, which leads to the same thing you have with multi-part images.

Further, I also found most Javascript stuff broken until I cleared the cache - going through host details (ie Snapins, Hardware) didn’t work amongst other things.

Just tested tftp client frm Windows 7 in one of these HP dc7900p computers, and it worked.
After testing all this, it’s working.
Don’t ask me why or how… but it started working.
Thank you all for your support.

the latest beyond 1.0.1 may be unstable.

use 1.0.1 for production environments.