Best posts made by coco65

@Tom-Elliott Don’t get mad, I was making this remark to help future newcomers, not to troll you. I know how it works now, just trying to help in making it better, not only for the hardcore/oldschool users but for newcomers also.

Note that English is not my native language, I am not trying to be a grammar professor here. In the wiki the word image is mostly used as a thing (an image), not a process (to image).

See https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Hosts

Images
Image objects in FOG are the representation of the physical files that contain the disk or partition images that are saved on the FOG server.

See https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#General_Tasks

General Tasks
The general/common Tasks in FOG include unicast image upload, and unicast image send, as well as a multicast image send. In FOG, sending an image to the server is considered an image upload, and deploying an image to the client is called a send. Both of these tasks can be started directly from the search, list all hosts, and list all groups pages.

In the wiki the terms upload and send are used and explained, but in the web console (GUI) it’s called capture and deploy in the menu and tooltip. So the wiki and GUI and boot menu are not in sync.

From a usability perspective I would suggest that you choose 2 words (like capture and deploy) and then use the same terms in the wiki, the UI and the client boot menu. One line of text describing if it goes from client to server or from server to client, would not hurt. When you are standing before a client, that just PXE booted, the wiki is not at hand.

@Wayne-Workman : You were right. I built the following: a physical fog server (a laptop) connected to a netgear pro switch, capture and deploy an other laptop, first with unicast then with multicast. Now there is almost no difference in deployment time, multicast takes about 20 seconds longer. Nothing else was connected to the test-network.

Conclusion: a good switch does make a difference. Thanks for the tip.

I wonder if the compression factor used makes a big difference in speed. Storage is cheap, time is money… Going to test that next.

@Wayne-Workman : thanks for the answer. Both the laptop and the Brix mini-pc I use have a wifi adapter that is not standard supported by the Debian installer. But since I intended to deploy using ethernet cable only, I ignored the wlan interface and indeed did not configure it. Hyper-V virtual servers don’t have a wlan adapter, so the error did not occur on that. It seems ics-dhcp has a problem with non-configured adapters.

Note: on Debian 8 (also Ubuntu I think) for the ISC DHCP server it should not be the file:
/etc/dhcp/dhcpd.conf
And also not:
/etc/default/dhcp3-server

For Debian 8 the correct file is: (it took me some time to figure this out, my Linux is not so good)
/etc/default/isc-dhcp-server
There add the line:
INTERFACES="eth0"

Running this release on a Dell Lattitude laptop in Debian 8, capturing and deploying HP, Dell, Toshiba and Asus (mostly old and donated) laptops, I cannot find an issue. It just works great. The only critique I can think of is that it says “Dashboard” twice in the console home screen, that is redundant and takes up space. Tom please don’t get mad. I’m now a real Fog fan and recommending it at educational fairs and other places I meet educational sysadmins. It’s a great solution if your working under a tight budget. Good work!

Ok this is a very small thing but I am enjoying this disk cloning solution, so I hope my small newbie contributions help a bit.

In GIT (trunk) version7917 on Debian 8. When adding a new storage node, the field Web Root is blank. The wiki does not tell what the value should be by default. After trial and error I found out it should be /fog in there, not blank. After typing that and saving, it connects in the dashboard and starts replicating after a while, just as advertised.

I made the storage node on a QNAP NAS, inside a Debian virtual machine using the QNAP “Virtualization Station” app that comes free with the NAS and followed the FOG wiki for install instructions. Works fine!

The /fog value for Web Root should be a default I think, so you don’t have to guess when adding a storange node. Keep up the good work, greetings from Holland.

Not a big problem this, more a usability suggestion:

In the Fog client there is a menu option: Quick image

Does this mean Quick Capture or Quick Deploy (image upload or image download)? Sending an image the wrong way could destroy hard work, so I have avoided an option that maybe can be useful. “Deploy on demand” would be clearer for me then “Quick image”.

Also when you choose the menu option: Full inventory (and something) at the end of many questions is asked “do you want to image now?” Again image upload (capture), or image download (deploy)? Please stay true to Fog terminology to not confuse stupid users like me.

@MRCUR

I have to disagree with this. When you use “image” as a verb, it implies that you are downloading the image to the computer.

In the past I have tried and/or worked with (but i prefer Fog over them):

• Symantec Ghost Solution Suite
• Acronis Snap Deploy
• Clonezilla
• Trinity Rescue Kit
• CloneDeploy
• WDS: Windows Deployment Services

In those systems “making an image” or imaging means copying all the data from a (client) hard disk to a file (on a server or somewhere). Bringing the data back to a client system is called deploy, send, push, download or restore. I do not care how it is called in Fog, just keep it the same in the console, the boot menu and the wiki. Capture/Deploy works fine for me.