Posts made by Wayne Workman

It appears to be fixed. Great work @Sebastian-Roth

Hello Community,

Debian 11 daily installation tests are working for the dev-branch but are failing for the working-1.6 branch. I’m unsure of the differences, but there must be differences between these branches.

Hello Community,

Fedora 35 has been flat-out failing installation tests for all branches since I’ve added it to the daily installation tests.

Knowing our limited developer resources, and to keep cost low, I suggest we cease testing Fedora as well as cease supporting Fedora - in the sense of fixing installation code to make new versions work.

Thoughts?

As the title says, RHEL 7 and CentOS 8 have been removed from the daily installation tests.

CentOS 8 had been failing on all branches for some days, something to do with no mirror URLs. @Sebastian-Roth recommended to remove it from the tests, so I went and got this done.

RHEL 7 - there was some problem with getting patches for new AWS Instances. I didn’t spend much time trying to figure it out, as I expect patches to just work when I run yum -y update in AWS. RHEL 7 was also pretty long in the tooth and is nearing it’s ultimate EOL. So, I removed it.

@zfeng If you’re only wanting to use the web interface over the internet, you should certainly setup your FOG server to use https. And after that, you only need to allow ingress 443. Still, I’d suggest not doing this. Better to use VPN.

On your internal network, FOG needs a lot of ports. this is all detailed in the wiki.
https://wiki.fogproject.org/wiki/index.php?title=FOG_security

@george1421 said in FOG External Reporting:

I didn’t have access to the raw data only the chart

The DB is available for download on the same page. It’s just a mysql dump. The thing to bear in mind with the DB is the fog installer sets up servers (if they don’t opt out) to report in once per week, at some random time. So, to look at what figure we have for dev servers out there, the below is the correct MySQL query:
select count(id) from versions_out_there where creation_time >= NOW() - INTERVAL 7 DAY;
This can be seen in the source code here:
https://github.com/FOGProject/fog-community-scripts/blob/1d2faad47478a5ea3bebb0906f03b0c3ace4c510/external_reporting/external_reporting/do_web_tasks.py#L79

Now at 610 Dev users. I’m thinking to myself - wow. That’s a lot of dev users.

I am super curious what will happen to these figures after the next release. I’m thinking a lot of people are using the dev branch simply because the installer works with the latest OS patches. But, I also think some unknown amount of users out there are sticking with the last stable release, and biding their time with updated kernels, inits, and ipxe binaries as necessary.

Hey Community,

Since the external reporting and testing are behind AWS CloudFront, I’m able to see request counts and such. Below are some screenshots I just took. The graphs are sum of requests per day. There is a lot more history for the external reporting since it was behind CloudFront basically the whole time. There is less history for the testing results, since I only recently put it behind CloudFront.

Yeah bots and internet scraping engines are probably a big chunk of this, but it’s interesting to look at none the less.

@fog_newb said in Ugh so updating from 21.04 to 21.10 breaks the database:

have other services and things running on the box too

What sort of stuff? Just curious. If at all possible, I would recommend against server-sharing. Not only with FOG, but just as a general I.T. guidelines.

@fog_newb This is why it is recommend to run FOG in a VM. Simply snapshot before doing stuff like major upgrades. If it goes south, roll back to your snapshot. Also, both 21.04 and 21.10 are not LTS editions. I would generally advise against running FOG on a Non-LTS version of Ubuntu. In addition, the daily installation tests (link in my signature) do not test non-LTS versions of Ubuntu.

I suggest you fall back to 20.04. We have a migration guide:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

Another thing I just now thought of - versioning the partition file we keep with the images. We can start out with v1.0.0. And if we change how we store that file, we simply increment the version. This would give us some more flexibility in regard to changes.

Thinking further, the scripts that collect the physical partitions are fine, we can just add JSON output for those.

And really, the LVM describing tools are what needs JSON output, so the effort there is targeted to just those.

I think I’m going to take a swing at adding JSON to an LVM describing tool (there are several).

@sebastian-roth I’ve been thinking on your comments since you’ve posted them.

I have another idea that would achieve the same ends. A python wrapper. I really, really want to avoid the complexities involved with BASH based parsing. I’m just completely turned off by it, and not interested. Really, I believe firmly all CLI tools ought to have a JSON output option. Seriously! (Maybe I should start a movement?)

Though, the tools do not currently output JSON. I’m skilled with Python and could write a wrapper for these tools, to convert the output to a nice JSON format. Thinking we can call a python script that collects all necessary partitioning information, and spits it all out via stdout in JSON format.

The one hitch - can we get python3 into FOS? Maybe it’s already there? Haven’t checked.

I don’t want to abandon this effort. I’m just looking for a way forward that is both attainable as well as not miserable.

Hello Fog Community!

I’m happy to inform that as the title says, Alma 8, Rocky 8, Fedora 35, and Debian 11 have been added to the daily installation tests. Fedora 32 has been removed.

In addition to this, I’ve re-enabled testing the working-1.6 branch as I see there is now some activity there. I’ve also implemented HTTPS for the installation results. And, I’ve added links at the bottom of the test results to the external reporting dashboard, and vice-versa as well. I’ve also done some extensive maintenance & care on the testing code base. It’s been upgraded from Python2 to Python3, among other improvements relating to speed and cost. If you’re interested, this was the pull request for the changes.

I’m thinking a lot on bringing back the streak counts, because they were really fun to watch. Though in addition to this, I want to capture execution time and other figures, and produce some pretty graphs for these things rather than just a number. Will be thinking on this.

Also thinking on adding some CI/CD stuff to the tests, where people can submit changes to the test suite and they “become real” shortly later in the test environment. Though for this, I do need to control it as things are not free in AWS. Thinking to make the test suit it’s own repo, and allowing others to submit pull requests. Upon pull request merge by me, Jenkins would implement the changes automatically. There’s both Terraform as well as the actual tests that could be affected.

Another thing I was thinking about is adding UI testing via selenium. The UI could be tested for every branch, with a fresh set of OS patches applied, every day, automatically. Though, I have very little experience with Selenium. Though the nice thing about such tests is we’d only need to have 1 set of tests as there’s only one UI, rather than independent code per operating system like I have to maintain for the installation tests. Selenium test results would be displayed on the same page as the installation tests.

I realize FOG is in maintenance mode. Though, I must admit I really enjoy doing these devops-ey type things for fog.

These are great replies. Reading the reasoning for keeping the RPM functionality makes sense because there’s no effort there - other than the effort to cleanup/rewrite all of it. I didn’t realize the amount of work needed for new Debian releases? Seems like it’s just always worked without issue. Ubuntu is another story, of course. So all these others like Arch, Mint, CentOS Stream - I’d suggest to remove code which is specific to these.

on the fog package idea, it’s complicated. I’m of the opinion that a self-contained VM image would be better. I will create this some day, I’ve just not gotten around to it yet.

Hi all,

It’s been over a year since we’ve began monitoring what OSs are being used by FOG out in the wild.

Overwhelmingly, it’s just three. Ubuntu, Debian, and non-stream CentOS.

Seeing how small our developmental support group is, and considering the future, I recommend we focus on just two of the three. Debian and Ubuntu. I suggest we discontinue support for all others. I don’t feel bad for recommending this at all, it’s by the numbers.

Dev users on what I’ve recommended:
249 on Ubuntu
165 on Debian

Concerning CentOS - it’s been declared that CentOS Stream is the future of CentOS. However, we see 3 users on CentOS stream, and 122 on the older CentOS 7 & 8. The FOG dev community is clearly not adopting CentOS stream, so I believe support efforts can be focused elsewhere.

I know there’s a volunteer who has offered to restructure the installation scripts. This is as good a time as any.

Every time I turn around, a new linux distro is released. I’ll work on getting the daily install tests updated to use some newer OSs.

Reading through this thread, I’d say we need a champion to help the FOG Project with the money and process. Here is where any for-profit company reading this should consider helping with two things.

• Donate some man-hours for a person to work with the FOG devs on this
• Donate the money to cover the cost.

Personally, I think it should be Microsoft who helps. If FOG is unable to easily deploy Windows 11 due to secureboot related difficulties, School Districts will have further reason to just buy Chromebooks instead of Windows PCs.

My initial thoughts on supporting LVM was bash scripts. Then I started thinking about the tooling that would be involved. Intensive use of many bash parsing techniques that we Linux users know all too well. I thought - geeze why don’t these tools just output JSON for us so we don’t have to do bash-wizardry to get the values?

So here’s where my head-space is now: Fork these partition/LVM information gathering tools and add JSON output options to them. This will be a challenge for me personally, as the tools such as fdisk and lvm are likely written in either C or C++. I want to add something like a --output-as-json argument or similar. This is to eliminate all the complex parsing we currently do. Then, something like JQ could be used to easily pull values from the JSON as needed.

Second, how the disk information for an image is stored. We currently use text files stored with the images in their respective directories on the FOG server. Those files have a structure, yes. But I think JSON would be better.

Considering handling legacy images (non-json) I’ve not thought too much on this yet but my initial thoughts is to convert all the text files during a fog install upgrade. Not getting rid of them, but putting their converted counterparts in with the images; leaving the old files in-place. And the upgraded fog system just wouldn’t use the old files.

Looking for some thoughts on this approach before I dive in deep.

This thread is to capture discussion around LVM support and related items.

@sebastian-roth said in Is there a way to make FOG compatible with LUKS encryption?:

@Wayne-Workman Do you think you’ll get to tackle the LVM implementation in the near future or should we toss that idea in favour of a next release?

I’ll start poking at some LVM bash scripts, though another release before LVM support would be preferred by me.