I think this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2030814
is basically ready to go — it just needs someone with more time than Stephen
or I to take it on and get the package through review and built.
I actually think it'd be a really nice feature to tout for Fedora Server
Edition 36 — maybe something someone would like to make a self-contained
change before that deadline?
Fedora Project Leader
For anyone who hasn't seen it yet - there's quite a kerfuffle today
about a major security issue in polkit:
turns out that ever since it was invented, `pkexec` has had a bug
allowing for local root privilege escalation. Which is...bad.
The issue and some of the comments around it prompted me to wonder -
why is `pkexec` still a thing? Particularly, why is it still a thing we
are shipping by default in just about every Fedora install?
My best recollection is that pkexec was kinda a kludge to allow us to
get rid of consolehelper: some apps weren't getting rewritten to the
Right Way of doing things under policykit, they still just wanted to
have the entire app run as root, and pkexec was a way to make that
But that was then, and this is now. Does anything in Workstation use
pkexec? Does anything in KDE use it? I'm pretty sure (at least I really
hope!) nothing in Server uses it. I don't think any of our
documentation recommends its use for interactive execution of things as
root (these days we tend to just specify `sudo` for that and assume the
install has an admin user).
Should we just split it out of the polkit package into a subpackage and
stop shipping the subpackage on those editions/spins at least? If
there's anything in other desktops still using it, it can grow a
dependency on the subpackage...
Am I forgetting some other reason we still need it?
IRC: adamw | Twitter: adamw_ha
From today's Fedora QA minutes
16:20:54 <pboy> I'll test that again, but I'm sure, if you use
everything DVD you get the wrong preconfiguration. We had a thread
about that on server list.
I'm not finding this thread. But Adamw surely knows the history of
Everything ISO better than I do. My fuzzy memory is that it's sort of
a side effect of how images are made and it's kept around as a catch
all. It's the only way to do a netinstall for any of the desktops. The
default package set is for a minimal install, a.k.a. Fedora Custom.
The idea is to make it straightforward to get a minimum bootable
system and then use dnf to build it up from there.
Just for context, "Everything ISO" e.g.
This image defines "automatic" partitioning as btrfs. It's intrinsic
to the image itself what the partitioning defaults to. It's not a
function of the package set, i.e. choosing the Server package set
doesn't get you Server's default partitioning. It's a little
confusing, but it's working as designed, insofar as it has one.
I cc'd Anaconda folks, because I'm not sure exactly where the
"autopart" kickstart command gets defined these days. And also whether
it's worth the effort to make autopart variable based on what edition
or spin is selected in the Everything netinstaller? I'm not sure that
On Tue, Jan 25, 2022 at 6:47 AM Vendula Poncova <vponcova(a)redhat.com> wrote:
> On Tue, Jan 25, 2022 at 10:34 AM Jiri Konecny <jkonecny(a)redhat.com> wrote:
>> Dne 24. 01. 22 v 20:20 Neal Gompa napsal(a):
>> > On Mon, Jan 24, 2022 at 1:46 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
>> >>> Am 24.01.2022 um 18:42 schrieb Chris Murphy <lists(a)colorremedies.com>:
>> >>> cc: anaconda-devel@
>> >>> From today's Fedora QA minutes
>> >>> https://meetbot.fedoraproject.org/fedora-meeting/2022-01-24/fedora-qa.202...
>> >>> 16:20:54 <pboy> I'll test that again, but I'm sure, if you use
>> >>> everything DVD you get the wrong preconfiguration. We had a thread
>> >>> about that on server list.
>> >>> I'm not finding this thread. But Adamw surely knows the history of
>> >>> Everything ISO better than I do. My fuzzy memory is that it's sort of
>> >>> a side effect of how images are made and it's kept around as a catch
>> >>> all. It's the only way to do a netinstall for any of the desktops. The
>> >>> default package set is for a minimal install, a.k.a. Fedora Custom.
>> >>> The idea is to make it straightforward to get a minimum bootable
>> >>> system and then use dnf to build it up from there.
>> >>> Just for context, "Everything ISO" e.g.
>> >>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-2022012...
>> >>> This image defines "automatic" partitioning as btrfs. It's intrinsic
>> >>> to the image itself what the partitioning defaults to. It's not a
>> >>> function of the package set, i.e. choosing the Server package set
>> >>> doesn't get you Server's default partitioning. It's a little
>> >>> confusing, but it's working as designed, insofar as it has one.
>> >>> I cc'd Anaconda folks, because I'm not sure exactly where the
>> >>> "autopart" kickstart command gets defined these days. And also whether
>> >>> it's worth the effort to make autopart variable based on what edition
>> >>> or spin is selected in the Everything netinstaller? I'm not sure that
>> >>> it is.
>> >> Chris,
>> >> if I remember correctly, wasn’t it you who informed me (about a year ago in the context of F32/33) that booting from everything DVD and select „Fedora Server“ does not result in an identical installation as booting from Server DVD and selecting „Fedora Server“? (when I wondered about the installation on a rented remote hardware where only „Everything“ was available).
>> > That's a different case. That's referring to the package collection.
>> > The Everything ISO has the base Fedora "profile" that most variants
>> > use (which uses Btrfs). But it also doesn't select Fedora Server by
>> > default and is explicitly designed "for experts", The Fedora Server
>> > netinstall ISO uses the Fedora Server "profile" and will use the
>> > Fedora Server settings by default, including using LVM+XFS.
>> > Think of the Everything ISO as something that an Arch convert would
>> > use, while the Fedora Server netinstall ISO would be something that a
>> > sysadmin doing server deployments from a central repo mirror would
>> > use.
>> Yes, it's as Neal said. Basically Anaconda is now using configuration
>> profiles which are matching the /etc/os-release values.
>> If there is a match we will choose that configuration file. Not sure
>> what the Everything ISO has there. However, it's possible that it is
>> matching the base Fedora configuration file:
>> where you can find the default_scheme:
> Btw. the issue with changing profiles based on the packages selection was already discussed here:
> I still think that the best approach would be to extend the boot menu of the Everything ISO as mentioned at: https://bugzilla.redhat.com/show_bug.cgi?id=2002668#c1
> The Anaconda profiles are documented here: https://anaconda-installer.readthedocs.io/en/latest/configuration-files.h...
Would it be possible to add the ability to define partitioning schemes
per scheme? For example, with Btrfs on Fedora Server, having a
subvolume for /home is sensible, but with the other arrangements that
divide up space, probably not. For RPM-OSTree systems
(Kinoite/Silverblue), we'd like to have a /var subvolume in addition
to /home, but not when plain partitions or LVM is used.
真実はいつも一つ！/ Always, there's only one truth!
On Mon, Dec 13, 2021 at 5:50 PM Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> On Mon, Dec 13 2021 at 05:45:45 PM -0500, Chris Murphy
> <lists(a)colorremedies.com> wrote:
> > But I don't know what's
> > responsible for creating the /etc/resolv.conf symlink in the two
> > installation methods.
> Until three days ago, the answer was systemd package scriptlet. There's
> absolutely nothing Server-specific there. Maybe just bad script
> ordering luck?
> There is some good news: the "Enforce authselect configuration
> consistency" change is obsoleting all of the current fragile scriptlets
> and should make everything way more robust. See e.g.:
> So I would not invest too much effort into debugging this except in
> rawhide, because everything is very different in rawhide. It should be
> a lot more robust and I wouldn't be surprised if it fixes this issue.
Filed this against distribution and I'll propose it as a Fedora 36
beta blocker so we don't forget about it.
Again, for everyone's convenience, a brief summary of our IRC meeting right here.
For greater details see meetbot
=== Follow up actions ===
#info Nothing new to report
After a short discussion
#action: pboy, StephenGallagher, salimma prepare a late change proposal.
=== Current status of Fedora Server User Docs Update ===
Review for various article that already found a reviewer are in the works. 4 articles still need a reviewer.
Goal is to publish the already assigned articles in the next 14 days.
=== Current changeset F36, possible specific impacts on Server ===
The list is not yet fixed. Currently foreseeable, the planned omission of the ifcfg based configuration and the announced Migration Guide will need special attention (and testing).
=== Review current Fedora Server Technical Specification ===
Special attention was paid to the question of the role that services rsp. Linux system roles could take in the future as successors to server roles. Discussion to be continued.
> Am 18.01.2022 um 18:35 schrieb Me <jas_beard(a)hotmail.com>:
> Hello my name is Jason Beard, aka cooltshirtguy. I'm a husband, father,
> and geek. I've been in IT one way or another for over 25 years. I've
> been using Linux off and on for years but I was a Linux administrator
> for the last 10 years. I've been using Fedora for about 3 years now. My
> hobbies include smoking BBQ, gardening, video games, and DIY projects
> around the house. Since my youngest started college I have some free
> time and want to give back.
> I'm not a programmer but I've done some bash scripting. puppet, chef
> and currently learning Ansible. I don't mind learning new things and
> adpat to change. Hopefully we can find something fun for me to do.
> Look forward to this new advenmture.
> Let me know what my next steps are.
welcome to our Server working group. I’m quite sure we have a lot of opportunities here to contribute and having fun doing so.
Given your description you may interested in our current Ansible pilot project "Facilitated deployment of key services by combining rpm and Ansible“. You find information at https://fedoraproject.org/wiki/Server/Using_Ansible and https://pagure.io/fedora-server/issue/60
We have some other ongoing work projects, have a look at https://fedoraproject.org/wiki/Server. A complete list including various smaller task you’ll find at https://pagure.io/fedora-server/issues
And given 10 years experience as a Linux administrator you must have a lot of knowledge about various administrative task and possible issues and ways to overcome those. And it may be fun to write some of them down and share your knowledge with others.
And of course, it is greatly appreciated to introduce new ideas and projects!
Next step may be to gather some ideas what do you would like to do and to join our IRC meeting, e.g. tomorrow.
The meeting will take place
Fedora Server IRC meeting Wednesday, January 19 17:00 ==UTC==
Unfortunately, John (jwhimpel) can’t join us this week, so we postpone discussion of Wildfly/Ansible to next meeting.
== Agenda ==
1. Follow up actions
2. Current status of Fedora Server User Docs Update
Goal: determine and planing actions needed
3. Current changeset F36, possible specific impacts on Server
Goal: determine changes which may specifically impact Server
and may require special testing or other attention during beta
4. Review current Fedora Server Technical Specification
Goal: Update Technical Specification
5. Open floor
For any additions or changes, please reply to this email.