Posts made by Wayne Workman

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.

@tom-elliott said in Got Arch/Manjaro install to work:

I don’t know if you purposely deleted, but I will say our community isn’t as harsh as the arch community with questions.

Harsh is an understatement. I will never ask that community another question.

What would people think about a release? It’s been over a year since the last one. There are 248 adopters on version 1.5.9.111

I realize it’s not trivial to put a FOG release together. Perhaps all the steps can be captured to make it easier for others in the future to do it?

After a bit over one full year now, we are at 527 dev installations of fog.

For what it’s worth, I’d be interested in this also. I use nothing but LUKS at home. DD and RAW is slow, would be great for FOG to handle the creation of the needed LVM pieces /w encryption. I’d like to figure it out, but that’s probably a year or more away for me.

We’re at 534 dev installations of FOG that have reported wiithin the last week. We started tracking this about 10 months ago. Coming up on a year of version tracking.

The old and new fog versions do not need to be the same version. The only restriction here is that you cannot downgrade. You can go from older to newer, but not from newer to older.

@rets34 What are the output of the following two commands?

ls -laht /var/www
ls -laht /var/www/html

@matthew-wyneken Are you using the right address for the fog server during installation? Can you do a curl or wget of the certificate using Terminal on the MacOS system?

@jconway1006 Need more information. Fog version, screenshot of the issue. Number of fog clients, FOG Client checkin time, FOG Server hardware specs. Where is the fog server in relation to the node being imaged? What’s the network speed between the fog server and the node being imaged?

@tesparza This should happen automatically. If it’s not, you have some sort of configuration problem. There’s a replication log you can look at in the web UI. Check that for errors.

Also, there’s this article on the location plugin. While this is meant to cover location plugin functionality, it also explains default functionality pretty well. https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin