@Junkhacker If you could get it working again that would be great. And it’s perfectly fine if the data is not received sequentially in my mind - this is just the nature of torrenting - it’s designed to be this way and has many advantages. Torrent imaging should work like torrenting and not like unicasting (sorry sebastian).

@george1421 There is also this: http://sourceforge.net/projects/fogupdateip/?source=directory

It will configure dnsmasq for you.

And you could let your server receive DHCP for it’s address as well.

I can’t say I have checked… but it’s supposed to be either fog:fog or fog:root on a standard installation.

@Tom-Elliott Ok I get it. Where is the image stored in the mean time? I guess thats why you all were talking about knowing exactly how large the image is and the resizing and stuff - because the image would need temporarily stored on the HDD because it’s too big to fit in RAM.

Bet this would work a lot better for two-drive systems…

I’ll add to this conversation that FOG is Open Source and Free… that includes newer versions.

Not free like Free Beer, but free like you can use it, copy it, change it, and exchange it however you want with the only limitation of simply respecting the GNU General Public License v3.

@RLane That is more clear.

Images built with the current FOG Trunk version will work with the future FOG 1.3.0.

The new fog client is being developed by @Jbob and he’s integrated automatic updating for the new client on host machines. Meaning, the client should always be able to check with your FOG server for a newer version, and if there is one, grab it & install it, removing the old one.

Also, I’m positive that Jbob would like some more beta testers… I missed it this summer because it didn’t work for me when I was building the images for this summer.

Plus, there are some UI changes in FOG Trunk, it’s got a different look, and major performance improvements, and more features. Things like setting time zone and adding items to the boot menu via the UI, vs the old 1.2.0 way of editing PHP files (yuck). It’d always be beneficial to test things out while they are in beta, and see if it works in your environment, and let the developers know BEFORE 1.3.0 is released!!

Also, you can upgrade the FOG Trunk build to 1.3.0 when it’s released - that’s easy.

This thread is for the development of an eventual update to the WiKi “[URL=‘http://fogproject.org/wiki/index.php/FOG_on_a_MAC’]Fog on a Mac[/URL]” page.

Relevant questions are welcome. Relevant Documentation is especially welcome.

I’ve not tested but these steps should work.

mv /images /home/images

then in Storage Configuration -> [storage node name] -> Image path & ftp path, change it to the new path.

Then, inside of /etc/exports change the lines /images and /images/dev to /home/images and /home/images/dev

set permissions:
chown -R fog:root /home/images
chmod -R 777 /home/images

Then modify /opt/fog/.fogsettings to point to the right image path. Everywhere you see /images just change it to /home/images

I’d strongly suggest you use a much larger HDD, like a 500GB or larger, and then ask for help with partitioning on here.

I don’t bat an eye at rebuilding a server. If it needs done, it needs done.

Actually, Tom coded the current trunk to support Ubuntu 15.04 since a week or two ago, but it’s touchy. Tom could explain it best.

However, Tom really dislikes Ubuntu… For a lot of reasons that probably only a Linux developer would understand (over my head).

If you are dead-set on Ubuntu… then at least move to Debian 8… Ubuntu keeps moving further and further away from the norms…

I myself use Fedora 21 server and Fedora 22 server. CentOS is also very nice, and has support for my crappy RAID cards at my house out-of-the-box. RHEL would be the best choice, simply due to longevity, support base, and extensive documentation.

And, I’m not really a Linux expert or anything - therefore the only differences I can see between RHEL based Linux and Debian based Linux is Yum / Apt-get and the directories are slightly different, and the commands to start and stop services are a little different. All the basic commands I have memorized work on any distro I’ve tried. But again, I’m not an expert.

Tom recommends Red Hat based linux, and he’s been playing with Linux since the late 80s… so… that should tell you something. FOG was also originally developed on Fedora (yay!)

I’d really urge you to move away from Ubuntu…

We need a FOG distro…

@Arrowhead-IT Why not just add them to the installer for Ubuntu ?

I do just fine with 4 cores assigned and 4 gigs of ram using Hyper-V.

For Unicasting (upload and download), the compression and decompression happens client side. The only thing the server needs for that is a fast network connection and HDDs that can keep up.

Multicasting download decompression happens server side - that’s where horsepower comes into play.

You might find interest in this thread: https://forums.fogproject.org/topic/5116/imaging-transfer-rates-vm-vs-physical-machine

Correction
Multicast decompression also happens client side.

@sagar

When the forums were updated, not all formatting carried over correctly.

You can find good documentation in our WiKi on installing FOG.

https://wiki.fogproject.org/wiki/index.php/FOGUserGuide#Installing_FOG

@emijoa said:

What os would you recommend to run fog on ?

CentOS 7

@Deastrom If some are not windows, then that means some might need a RAW image type - these are not compressed and take significantly longer to upload and download. Also, the extremely legacy OSs might have extremely legacy hardware that might not even support network booting… or any of the recent FOG client kernels.

But, sounds like you’ve thought it through and it sounds like this is the best choice. But I seriously doubt you won’t run into issues with the legacy OSs and legacy hardware - so just be prepared for that.

@ch3i said:

@DevinR Hi, Thank you for that great job. I think @Wayne-Workman can add your tests to the Wiki, it’s very helpfull.

https://wiki.fogproject.org/wiki/index.php/Image_Compression_Tests

@nbuursma said:

Okay I dont know how to do this debug capture at all…

When you’re on the confirmation page for creating an image task, it’s just a little check box before you confirm the task creation. This is how it works in FOG Trunk anyways.

After your host boots up to the network for a debug upload/download you can issue the fog command to initiate the imaging task. You’d then slowly [enter] through each step.

@Tom-S said:

yes I do it all the time! The trick will be getting the devices to boot into fog. You can download an ipxe iso and boot off a usb cd, or use unetbootin to put the iso on to a usb drive and boot from there. I am in the midst of finalizing the FOG Service for MAC. it installs a efi and windows partition that boots off the network. I have been imaging 1500+ macs a year with fog. It works very well.

Where have you been all of my life?

GOOD NEWS AND BAD NEWS… AGAIN!!!

Bad news:

did a debug download, was fiddling around with mounthing…

did this:
[CODE]rm -rf /images[/CODE]
before this:
[CODE]umount /images[/CODE]

and all of my images and data … GONE!!! MOTHER F@&*$#

Good news:

Restored my images from backup… was a process…

Ran another debug task.

created the /images directory manually at CLI
[CODE]mkdir /images[/CODE]

Mounted to the remote images directory via CLI (ensured NFS was NOT running first):
[CODE]mount -t cifs -o username=root,password=PASSWORDHERE //10.0.0.3/images /images[/CODE]

Issued the fog command:
[CODE]fog[/CODE]

and BADA BING bada BOOM

mounting passed and imaging finished without incident.

So… Conclusion… something is going wrong with mounting using the fog.checkin script. I don’t know what it is… I removed all the failure code and replaced it with the success code for EVERY section!

When I do the mount BEFORE the fog command, when the fog command tries to mount, I suppose it errors out, but is still somehow able to succeed?? Maybe because I made failing impossible??? I HAVE NO IDEA

BUT,

I JUST IMAGED USING SMB !!!

WOOOOOOOOT :d

Now, as far as SPEED goes, I was running through a 1Gbps switch.

The source HDD was SATA 2 (3Gbps) and destination was the same (I think). The target host has a 2.93Ghz core 2 Duo processor with I think DDR 2 RAM.

I saw speeds at roughly 3.25 GB / min in the partclone window.

According to Google:
3.25 (gigabytes / minute) =
0.433333333 Gbps

Using the EXACT same hardware, but running the image download via NFS (ensuring SMB is turned OFF)

I saw the same sustained speeds of 3.25ish GB / min.

Could others please validate that there are no performance hits?
I’m using OLD equipment to test with.

Bumping this thread, I feel it has real utility for comparing files across storage group members. When I write the wiki article on it, I will gear it towards that.