I appreciate what you do for FOG. If you need VM space, you know you can give me a hollar.

@WalterT This post is completely unhelpful to yourself and to the fog community, and seems rash as well. If you need help with getting fog setup, create a thread about your specific problem, provide details, screenshots, logs, information. The community will help you as best as possible after you provide basic details about your specific issue.

Ok…

I’m feeling pretty ignorant at the moment.

I got to messing with this again and was able to try out a new unmanaged 1Gbps Cisco switch with it and I went through several different configurations in my tests and kept getting inconsistent results.

I have finally found out what the issue was. It was a bad patch cable the whole time.

That’s pretty shameful on my part as a technician, but it would be more shameful to conceal my mistake and not report what the issue was.

I do believe I exhausted every single other possible option before I realized it was the patch cable. Checking simple things first is hammered into all of us as troubleshooters, and the lesson has definitely been reinforced in me.

I come from Semantic Ghost background.

Fog is MUCH faster, supports queuing, renaming, joining to the domain, and there is ample support and high-responsiveness on the forums, with ample materials available in the wiki as well.

FOG images in general compress very well. 40GB compresses down usually to about 19GB on the server’s disk.

It’s free - not free like free beer, but free as in you may freely examine the code, freely make copies, freely make changes to your copies, freely distribute it under the GNU GPLv3 License, free to charge for it even, if you can (although I doubt you’d be successful)! The GNU GPLv3 allows for all of these things, as long as the License is respected and provided with copies and changes, and as long as all changes are completely open source and available to the public.

FOG can serve as a reliable DHCP server for you, offering more control and more options than Windows Server 2008 and below did (see our article on BIOS and UEFI Co-Existence).

FOG bridges the imaging gap for OSX, Linux, and Windows, and provides a management client for all three that can name them, join them to the domain, and run snapins on - all from a common web interface.

FOG can manage printers for you, allowing you to avoid cluttering up your domain controllers and group policy.

I use WOL to wake computers up on a schedule easily, and during breaks like spring break and winter break, I can easily disable it.

I use the fog client to push out Chrome updates regularly - with absolute ease. Using snapins also keeps group policy on computers and domain controllers less cluttered.

FOG logs logins for me, which I was previously logging using advanced scripting techniques that only I understood in my organization. Now, just using the web interface technicians can see login history for a computer or individual.

Fog supports wiping HDDs, and I can integrate ISOs into fog without much trouble.

Used to be, imaging a lab was a two to three person job for several hours with Ghost, and now it takes one single technician under 30 minutes - all of which are spent standing around and making sure things go smoothly. For example, we don’t have to name computers because fog does this. We don’t have to join to the domain because fog does this.

Please don’t disrespect CloneZilla in your report. :-) Comparing it to FOG is unfair. It’s comparing apples to oranges. CloneZilla has strengths where FOG has weaknesses, and vice versa. For instance, if there are strict regulations on a network that a individual technician is not allowed to change, CloneZilla could be the winner in that scenario. If the network performs poorly, has problems, is slow, or non-existent, CloneZilla is the clear winner. If a technician does not have a server or old computer to dedicate as a FOG server, then CloneZilla is the winner. Also, CloneZilla is the most simple way to clone a FOG server! Where CloneZilla has weaknesses, FOG far excels. And where FOG excells is using your network to get work done - and fast. Bottom line is - CloneZilla is free open source software and has it’s place in the computer imaging industry and it should be respected for what it is.

@ITSolutions said in DNS Name Goes to Old FOG Installation:

Ubuntu moved the default location for web pages in 14.04 from /var/www to /var/www/html. FOG is designed to do a symlink back to /var/www, but maybe something broke in that.

I think that statement there is what’s going on.

So, if you use the host name, you are taken to 1.2.0 interface, but if you use the IP you are taken to fog trunk interface.

This means that the web files for 1.2.0 obviously still exist, and the trunk files are there too.

If it were me, I’d delete everything in /var/www EXCEPT for the html directory, and I would delete everything INSIDE of /var/www/html and re-run the installer. That should fix it.

So for instance if you saw some-folder inside /var/www you’d do rm -rf /var/www/some-folder That’s a recursive delete command. same goes for everything in the other.

You can list the contents of the directory, including hidden files, with ls -la

People that are new to fog don’t see the value in registering normally - and that’s OK. But fog comes to life with registered computers - automatic host naming, automatic domain joining, automated startups, shutdowns, reboots, software & script deployments, printer management, tracking of who logs into and out of said computers, inventory reports, imaging history, and many other things. Many of FOG’s features, you cannot use without registering.

And after you try out registering & using these features, you will start to understand how unnecessarily hard you were working before.

@THEMCV I would have the snapinpack both install the software and then place the file too. This way the two are together, and one is always coming before the other.

Where fog dumps the files - it was quite confusing to me until I understood it. The wiki article SnapinPacks “SnapinPacks are Compressed” section explains it very throughly.

So if you name the snapinpack in the FOG web interface ciscoanyconnect, and the zip file does not contain yet another folder in it but just contains these three files:

• Installer
• .xml file
• .bat file <-- more about this in a minute.

You’d upload the snapinpack to the web interface as a snapin pack (this is illustrated in the wiki). When it’s deployed, these files are moved from the FOG server to the host, and then extracted to this path:

• C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.bat
• C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.xml
• C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\installer.msi or whatever it is

Now, from this point, after the copy finishes, the FOG Client initiates the .bat file (but it could initiate any executable, like a powershell script or a exe or .sh or whatever).

The .bat file must make all the correct calls to do everything necessary. For example, running a msi correctly in this situation might be:

msiexec.exe /i "C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\installer.msi" /quiet

After this, and according to the info you gave below, the copy line would come last in the script, and may look something like this:

copy "C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.xml" "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\your.xml"

Note the quotes around the paths, thats because they has spaces in them.

Now, when you’re zipping this stuff up, and then uploading it to the web interface, you will need to specify that the SnapinPack is going to run a bat file, and then you need to put that bat file’s name in with the settings.

Watch the “very through” video if you have time, all this stuff is explained there:
https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks#Very_thorough_example

October 30th, 2016
FOG Version: 1.3.0 RC-18
Git Commit: 4a4e4c686e98c7946f61462823b525287a8c72b2

• Arch Linux 2016.10.01 fully updated - installs without issue.
• Debian 8 fully updated - installs without issue.
• Fedora 24 fully updated - installs without issue per wiki instructions.
• Ubuntu 16 fully updated - installs without issue.
• CentOS 7 fully updated - installs without issue per wiki instructions

Just created this article:

https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

@Scott-B said:

cd ~/svn/trunk/bin
svn up
cd bin
./installfog.sh

That’s your problem I think. Don’t go into the bin directory to update. that only updates the directory you’re in I think.

Instead, go first to ~/svn/trunk and then svn up.

I’ve removed Arch Linux from the automated tests due to complications within Terraform. These issues were sort of the final straw in my Arch testing efforts.

The Arch community doesn’t supply an official AWS AMI. I had been relying on a privately built AMI that isn’t 1:1 with a manual Arch installation. For perhaps the last half year, my Arch tests were failing but the installer worked if you tested it against a manually setup Arch installation. This can only be due to differences between the AMI I was using and a manual installation.

The Arch community is vehement about only providing help if you follow their installation instructions on their wiki exactly. Because of this, when I asked for some help sorting out the issues, they were not willing to help.

Until someone with some Arch prowess can put some time into helping with this, Arch Linux will not be included in the automated tests.

@cammykool It can do remote execution, printer management, power management, login recording, and other things. I’ve used it to run scripts, deploy software, and other things. Check out these wiki articles below, they might help you understand the capabilities.

• https://wiki.fogproject.org/wiki/index.php?title=FOG_Client
• https://wiki.fogproject.org/wiki/index.php?title=Snapin_Examples
• https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

There’s also a ton of stuff on the forums about printer management. Here is one with some detail: https://forums.fogproject.org/topic/8051/printer-deployment?page=1 though there’s probably hundreds of topics about printers.

The CentOS project has yet to make a CentOS 8 AWS AMI available.
https://wiki.centos.org/Cloud/AWS

Still waiting on this in order to include it into the testing. Yes, I have thought about taking CentOS 7 and simply upgrading it. I don’t want to do that because I consider that being “not clean”.

Waiting for them to produce an Amazon Machine Image: https://wiki.centos.org/Cloud/AWS

I’ve found out today that CentOS 8 is out, who knew? Not me. I’ll be getting it added to the daily tests.

@Sebastian-Roth Yes. I have a new fog server & storage node setup, but haven’t done anything with the location plugin just yet.
I know I said I’d test it back in September. Shame on me.

@sudburr said in How to totally expunge FOG and everything it's touched:

But I don’t want to re-install the OS by remote. Not yet at least.

I’d have already done it…

Side note: I rarely even install OSs at home anymore. I have clean VMs that I clone for making new VMs. :D

@tomhtil said in Storage node behind NAT:

@Sebastian-Roth is there an easy way to sync the database as well? I’d be happy with multi master setup if i could sync the images folder and the relevant config for just the images.

Galera

@isaiah658 Just wait until you try out the new ZSTD compression. :-)

@Greg-Plamondon My advice: start eliminating variables, start reducing complexity. Create a new script that has a single command to sync one of your nodes - don’t use any variables, hard code everything. See if that works. If it doesn’t, start eliminating arguments one by one until you find the one that is problematic. Also try to sync test directories. Also look at the permissions of the directories you are syncing both locally and remotely.