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

There’s a copy of fog and fog-community-scripts stored in the arctic printed on film that will last over a thousand years.

I think that is simply awesome.

Primary: https://archiveprogram.github.com/

Others:

• https://www.datacenterknowledge.com/open-source/githubs-arctic-vault-makes-sure-open-source-code-survives-apocalypse
• https://hackaday.com/2020/07/29/ask-hackaday-why-did-github-ship-all-our-software-off-to-the-arctic/

@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.

the WiKi SVN article somewhat promotes upgrading to the developmental revisions…

I really think that the other upgrading methods should be ditched, IMHO. But others here feel otherwise.

At the least, the Upgrade To Trunk article and the SVN article ought to be merged. I’ve thought about doing this, but the SVN portion would be huge compared to the others, and I just haven’t gave it much time nor thought.

And I’m not “In” enough to maintain the news section.

Sad truth is, although Tom is fuc**** awesome at what he does, he is largely a one-man-army and he has a full time job and wife and so on. He’s the driving force behind FOG.

JBob comes in 2nd, with massive improvements to the new FOG client.

The other developers aren’t active enough (IMHO) to be able to keep the news section updated.

And me,

I’m a forum troll, and I help people as I can, but I’m not “in” enough to keep it updated (IMHO).

I’m more than willing to try, but I may fall short sometimes…

Over the last few weeks, working with Tom, I was able to test changes back and forth over for Ubuntu 16 and Debian 8.

Both now install without modifications, without special commands.

Install Debian 8, just pull down fog and run the installer as normal. It works.

Install Ubuntu 16, just pull down fog and run the installer as normal. It works.

@Developers @Moderators @Testers

Just created this article:

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

First thought, figure out how to make the FOG Server return the storage node you want.

Take a look at this function:

https://github.com/FOGProject/fogproject/blob/24bb5a62698b9ba5bd4d80296be8615105c9a810/packages/web/lib/fog/storagegroup.class.php#L237

I think if you can figure out how to pass in an IP address (and maybe subnet mask) to this, you can add logic to select the storage node you want.

The hard part will be figuring out how to pass in the IP address / subnet mask all the way from the unregistered host to the FOG Server and into this function. The easy part is adding a bunch of logic in here to return the node you want.

This link below is for USB devices, but it shows how the request is made and parameters are passed back. You could modify this to pass your IP, subnet, and whatever else to the fog server:

https://github.com/FOGProject/fos/blob/c0238723ce381b5cd0340932086b10d47e79e26b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L10C40-L10C88

Notice that it writes to this file: /tmp/hinfo.txt

You would add lines somewhere in here to get the IP / subnets from the request that the host makes:

https://github.com/FOGProject/fogproject/blob/24bb5a62698b9ba5bd4d80296be8615105c9a810/packages/web/service/hostinfo.php#L164

And you would pass that IP / subnet information into that optimal storage node function here somewhere:

https://github.com/FOGProject/fogproject/blob/24bb5a62698b9ba5bd4d80296be8615105c9a810/packages/web/service/hostinfo.php#L88

Second thought, hack the storage node selection into a custom FOS build

Checkout this spot, it may have potential:

https://github.com/FOGProject/fos/blob/c0238723ce381b5cd0340932086b10d47e79e26b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.checkin#L81

Another thought here is to look at how the Capone plugin sets this stuff. The script is called here:

https://github.com/FOGProject/fos/blob/c0238723ce381b5cd0340932086b10d47e79e26b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L60

And this is the file that gets executed, you see it sets a storage node IP, among other things:
https://github.com/FOGProject/fos/blob/c0238723ce381b5cd0340932086b10d47e79e26b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.capone#L108

Third thought, postinit scripts
The method @george1421 suggested seems promising, but I am unsure how the postinit script would make changes to environment variables that will persist after the postinit script ends. If you could solve that somehow, this seems like the easy path.

How would you update FOG without ssh? Are you using the terminal via a hypervisor? Are you plugging a monitor, keyboard, and mouse into a physical server?

Also if you needed to fix something, very likely all the help you would find in the forums will involve some kind of shell commands.

Hi, this is an old problem people continue to walk into. The problem is people upgrade their OS, and then the fog installer fails.

While some people have had success with this, I need more fingers and toes than I currently have to count those who’ve had issues with this approach.

The most safe and sure way to move to a newer operating system is to build a new fog server using that new operating system, and then migrate to it.

I’ve put a lot of time and effort creating an article on how to do this, I believe all the steps should still be valid. It is here:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

It’s possible you can resolve your issue - but this isn’t guaranteed. It’s also possible that you resolve this one issue, only to immediately face yet another issue. I would advise migrating to a completely new server because this is the safe and sure pathway. I can also tell you that 22.04 daily clean installation tests are passing, meaning that you’d have good results with a clean install on 22.04 (results in my signature).

I would recommend dnsmasq. Here’s a good simple tutorial. https://stevessmarthomeguide.com/home-network-dns-dnsmasq/

@icemannz I’m guessing the disk uses LVM. Fog doesn’t support LVM. If you create the partitions without LVM, it should work.

I know this is an old thread, but we now have metrics on what kernels are being used out in the wild. It’s the external reporting page. Link in my signature. This should let us know if it’s worth it (or not) to find all those old commits and tag them.

There’s a wiki article that walks you through migration:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@tag said in Setting up FOG in multi-location environment:

Is it even possible to do it this way?

What you’ve tried is what I was going to suggest. Having a storage group per site, each setup as a master storage node. Do you have any error messages?

Fedora 37 has been added to the daily installation tests. Link to the results dashboard is in my signature.

Fedora 35 has been removed.

Rocky 9 is delayed, as their AMI is not available in us-east-1 Virginia. I’ve emailed them about the issue, they are looking into it.

@flareimp There’s other options as well. You could do either of the below.

The below script is a one-use script that someone could run manually. After updating the IP via the OS configuration, you can run this script that will update all the FOG IP bits for you.
https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

This next script below will continuously update FOG’s IP settings to match the local interface IP address. You could package this with the fog server image you have so everything just works out-of-box.
https://github.com/FOGProject/fog-community-scripts/tree/master/MakeFogMobile