Posts made by Wayne Workman

The daily installation tests show Ubuntu 20 as passing for all three fogproject branches. You can see the results in my signature.

I ran FOG in Hyper-V. FOG being virtualized doesn’t have an impact alone. Resource contention might affect you if you over-provision your hosts. IOPS contention could affect you, network contention could affect you. So really comes down to the resources available to the hosts, and how much you can give to the FOG VM.

Personally, when I ran FOG inside of (insert any hypervisor here), the biggest two points of contention were network and disk. This is regarding imaging specifically. For non-imaging related tasks, like FOG Client related stuff, the biggest point of contention is absolutely CPU.

@Junkhacker I think this is the right move.

I’m happy to announce the daily installation tests now include CentOS 8 and Ubuntu 20.04 Server. In addition to this, the reliability of the daily installation tests have been greatly improved. There’s now some retry logic for getting the result files from the test OSs, as well as a distinction now between being unable to get results vs installation not finishing in time.

Typically I’ll monitor that the new OSs are solid for a few days, and usually I remove the older OS versions afterwards. Though seeing that we’re talking about CentOS and Ubuntu, I may leave both because I know there are lots of people out there using CentOS 7 still, as well as probably many versions of Ubuntu. I’ll be able to make more informed choices about this after the FOG Popularity Contest is working.

The daily results link is in my signature.

@developers what branch would you like the PR to be created to?

Great approach Tom. If a crontab is setup to only send once per week, the unique identifier becomes totally unnecessary. Because as you suggested, we can delete the collected data on Friday, and have all new fresh data by Monday - or keep all the data, and build reports based on the last week only.

One issue I see to this approach: having potentially many thousand fog servers all reporting in at the same time I think isn’t going to work out. I’d suggest the minute value of the Crontab be randomized between 0 and 59. This will spread the load out for the receiving API.

George, these are great ideas and questions. This is the beauty of open source. Collaboration.

I’ve revised my thoughts now. Here they are.

• Generate a GUID on the FOG system during installation. This will be unique, but not tie to any particular organization.
• On the fog web login screen, send a request with the GUID, FOG Version, and OS Version details to an API.
• Request should be non-blocking. If it fails or times out, it should not impact the login process.
• API records GUID, FOG Version, OS Version, and a datetime stamp.

These things allow:

• Not double-counting any system due to the GUID.
• The ability to know how many are running in the last month/week whatever.
• How many of each FOG Version is out there currently running
• How many of each OS is out there running FOG.
• Presumably see how long a version lives on average, among other things.
• This protects privacy as the GUID does not tie to any organization, and simply allows us to not double-count entries.

Thoughts?

As I sit here working on making the daily fog installation tests more reliable, I wondered to myself when I should remove the older OSs (centos7, rhel7, etc). I thought it’d be nice to know how often what OS is being used to install FOG on. So I propose the following.

I can create a publicly available API that simply accepts a “string” being submitted. Using this, I can put together a popularity contest type thing that will allow us to see what people are installing FOG on. I can build the API (I have scaffolding that I can use to get this done pretty fast) and run it, and make the results publicly viewable.

Within the FOG Installer scripts, I can add a question about participating in the popularity contest. I think this should default to “Yes”. If “Yes” is chosen, a simple curl call is executed sending the output of lsb_release --all to the API.

Thoughts on this? I’m willing to put it all together and submit the pull requests for it. Though wanted feedback before I went after it.

You should certainly be able to search in the GUI by MAC address, however sometimes even then the host won’t display due to other issues. Using SQL, you can always find items.

Please have a read through the topic Sebastion mentioned. You might also look at this Wiki article: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

Is there any antivirus installed on this machine? Is the traffic pathway going through a web filter? Can you manually download/view the certificate on the same computer that’s having the problem?

Hello @rogalskij

Please post a copy of the fog client’s log file. It’s typically at C:\fog.log unless you set some other path during installation. Posting this log will allow the community to better help you.

Double-check that you’re entering the right IP/name for the fog server during fog client installation.

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/

Normally the information from this thread is put into here: https://wiki.fogproject.org/wiki/index.php?title=WorkingDevices
A good way to contribute some time is getting this list updated. The wiki formatting for tables is a pain, so this is not as easy as it sounds.

@geezer it’s my understanding that the fog installer installs everything needed on the supported operating systems. People shouldn’t have to install anything beforehand.

@JYost are you registering all of the hosts? How are you setting the preferred names? The way I did it was I set names as I registered, and then did an image deploy right there during registration from FOG’s boot menu, typically. I don’t know how much experience you have with FOG but Tom is right, naming and domain joining should work 100% of the time. If it’s not, something isn’t right and we need those logs to help.

I know @george1421 loves CentOS, but Debian is also very stable for fog too

I can confirm Ubuntu 18.04 installs the latest version of fog just fine.

I run the daily fog installation tests, which test if the various branches of the fogproject github repo can install on the latest patched versions of various operating systems. I’ve been running these tests for maybe four years now, every day. The daily results are in my signature. While Ubuntu has been problematic sometimes, at the moment it installs fine.

My recommendation to you is to fully update your Ubuntu system before installing fog. This is what my daily installation tests do before installing fog:
apt-get update;apt-get -y dist-upgrade;apt-get -y autoclean;apt-get -y autoremove and then reboot before proceeding.

Further suggestions: Debian and CentOS are by-far the most stable Linux distributions that you can run FOG on. A couple years ago before a major re-write of the daily installation tests, I tracked success streaks of the various OSs and various fogproject branches. CentOS and Debian were neck-and-neck for 1st for the majority of the time on the master branch of the fogproject repo. If you want better luck overall with stability, it would be my modest recommendation to move to one of these distributions.

Very nice, good job!

I think he’s asking for a default role via the access control plugin. @Fernando-Gietz any thoughts on that?

This is interesting, I can see how it could be useful, though understand it would take valuable developer cycles for a thing that perhaps could be achieved in another way using existing features, without development efforts. @Nicolas-Bricet have you considered the following? setting an image for hosts in a particular site via groups, such that when imaging happens, the host’s image which is already set is used.