The count on working branch and dev-branch as of today is 718 fog servers.

Putting a bow-tie on this thread: This feature is complete. Link to the external reporting is in my signature, the kernels in use are beginning to show up, these figures will increase and show a bigger picture over time.

@fernando-gietz Hello,

I would like to know about the “Searches: Limit the range of the search to the resources of one or more locations. The restricted user only can see the hosts, groups, images that are link or associated to his/her location/locations.”

How is it possible to do it? In the Location plugin, we can only put informations about Storage.

@Fog_Newb Awesome! Thanks for testing 1.5.9.138. This was meant to fix another issue reported on github but looks like the same problem in the code was causing the issue you saw.

Please keep an eye open and try as many things as you can (capture/deploy, fog-client, maybe plugins).

I see Fedora 35 tests are now passing on dev-branch as well as working-1.6.

@peirkern Sorry for the delay. I have tried to think about what could cause this new error you see but still have not found a good answer to this yet. I checked logs of a good compile on one of my servers and don’t see this error:

linux-5.10.83.tar.xz: OK (sha256: ef259a43f33ddb56001283f4f4e50af29b8a48fa066aed7371a90ebf38c29b70) ESC[7m>>> linux-headers 5.10.83 ExtractingESC[27m xzcat /var/lib/.../fssourcex64/dl/linux/linux-5.10.83.tar.xz | tar --strip-components=1 -C /var/lib/.../fssourcex64/output/build/linux-headers-5.10.83 -xf - ESC[7m>>> linux-headers 5.10.83 PatchingESC[27m ESC[7m>>> linux-headers 5.10.83 ConfiguringESC[27m ...

I can only suggest you start playing with the commands within docker and see what happens:

mkdir ~/test xzcat /home/builder/fos/fssourcex64/dl/linux/linux-5.10.83.tar.xz | tar --strip-components=1 -C ~/test -xf -

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

Now, time flies and it’s been another two months. I’ve had very little time due to other projects but things are calming down a little bit right now. So I hope we can get this done in the next few weeks. I can take the lead on this but I can’t do it all on my own. I would really need some help by others to do some testing and so on.

So please get involved, contact me or post here.

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

@Wayne-Workman Really awesome work. Thank you so much for all this as well as new ideas!

I definitely vote for more testing as it’s still mostly manual work. Though I have to admit that I can’t see me working on this.

One option for limiting support to reduce workload would be to limit to LTS branches only. So only 18.04 and 20.04 for Ubuntu and skipping the intermediary releases and dropping those that go out of support by their vendor (eg ubuntu 14.04, 16.04).

@sebastian-roth Yes, I saw it. I am following it XD
it can be the way to do it.

@llightfoot

When I inspect the page and go tot he network tab hit refresh @
https://10.33.250.5/fog/management/

It gets a server 500 response from /fog/management/
and the second thing it attempts to load is favicon.ico which is a 404 error.

L
llightfoot
about 5 hours ago

I should give some more specifics.

This is a first server build on physical hardware.
Rhel 7
I utilized the rhel 7 install instructions
I did not use any specialized command line options when kicking off the bash script to install fog.
I did disable selinux
I did disable firewall
I can access the login page after passing through the ssl error but there is nothing to log into.

@george1421 i meant to reply to this a long time ago, but here goes.

testing on deduping of those images has been done. they dedup quite well. the dedup changes affect zstd and pigz compressed images. pigz compressed images actually dedup better, but the the compression and performance are worse. it’s a tradeoff to be evaluated by the individual.

dedup is only possible with the newer version of partclone due to a rolling checksum integraed into the image format on earlier versions. the newer version lets us choose no checksum.

the compressed binary file is dedupable thanks to the --rsyncable flag on compression that is supported by both pigz and zstd.

like george said, any deduping would be the responsibility of the underlying filesystem or storage, not built into fog itself.

@sebastian-roth said in RHEL 8, CentOS 8, master branch, July 22, 2021:

sed -i -e 's/dnf check-update/dnf -y check-update/g' /path/to/fogproject/lib/redhat/config.

Not sure if you saw that I edited my initial post. That sed command should take care of the issue that is causing master to fail. Find the related commit that fixed the issue in dev-branch here: https://github.com/FOGProject/fogproject/commit/90caf2367d21d0594b7f16b2813a2fa94684ad78