Re: Userspace VT consoles in copr
Sorry for poking in, but why have kmscon, a complete re-implementation, run over then DRM when a generic and well-tested combination of a wayland compositor and a terminal emulator, like cage+foot, do the work just as well? Yes, setup is initially difficult. But it might be worth it. An additional bonus of using the wayland method is extensibility and modularity. If the desktop protocols are inappropriate, new and separate wayland protocols exclusively designed for console use can be created. And can be used with existing protocols whenever appropriate. And yes, just like simple GUI programs in fbcon, you can have a simple single-purpose GUI programs run in a wayland compositor. (A kitty graphics protocol exists, but IDK if it is appropriate fora console...) Implementing this with kmscon, well... It might be easier to implement new wayland protocols for whatever the existing desktop-oriented wayland protocols are lacking or inappropriate in. Yes, it is easier said than done, I agree. But it *might* be worth the extra effort. If you ask the question of *why*, why so much in a VT console, I say that it is becuase: - fbcon VTs already support this. Image viewers are commonly used on VTs. I think it should be supported in userspace-VTs too, esp. when the effort is minimal. - It is less work to write wayland protocols than to arbitrarily extend kmscon, in case new functionality is needed. - wayland, the compositors, foot, all already exist. fakeKMSCon is one such setup which *already* supports this. I suggest new protocols **only if** the existing ones are lacking. - Theoretically in a utopian future, you could have such console-GUI tools, which are more accessible to the average users than cryptic commands, to find and solve small issues like SElinux... -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Userspace VT consoles in copr
I am sorry to repeat it for the 3rd time, But for a "stupidly minimal" stack, cage, weston etc... all exist with foot, weston-terminal, etc... You will be solved of many problems small and big, once the *only* stack is the wayland stack (maybe different protocols, but the same libraries). All compositors support XKB, atleast one keyboard layout at a time. All compositors have been well-written to use the DRM interface and display a program. All minimal terminal emulators render better than KMSCon. KMSCon, well, reimplements the *entire* stack above the DRM layer (maybe using evdev/libinput over the VT)... It has it's own set of issues, quirks etc... The entire thread (I mean the topic of discarding kernel VTs) has only 1 leftover issue, maybe more: KMSCon XKB handling, maybe in the future it will have more issues, previously on my old Gentoo system it had rendering issues while a cage+foot (or weston+weston-terminal? I don't remember) setup was crystal-sharp-smooth. Anyone who wants such a really stupid setup without *anything*, won't use a "bloated" (in their terms) distro like fedora. I am really sorry if this sounds like a rant, really sorry. Keep KMSCon low-priority, or just temporarily discard it, and continue with the wayland stacks. Once everything is setup and atleast 1 fedora system is running without kernel VTs with userspace VTs, go back to work on kmscon. (of course, no system-specific hacks; A "default configuration" fresh system) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Self Introduction: pramodvu1502
I would like to be a package maintainer for fedora. Plz reply and ask for whatever other info you need. https://bugzilla.redhat.com/show_bug.cgi?id=2350109 My review request https://copr.fedorainfracloud.org/coprs/pramodvu1502/systemd-cron/ My copr https://github.com/systemd-cron/systemd-cron Upstream This is the `systemd-cron` package which is a systemd generator implementing cronie and anacron via systemd timer-service pairs. It's motive is to support traditional cronjobs in fedora without another redundant daemon or any ugly hacks. I am not it's upstream maintainer. I just maintain the fedora package. This is the only package I would like to maintain for now, but I plan to package more such unpackaged-for-fedora software. Also maintain them as new versions pop out. Yes, this is my 1st package. I have no prior experience with fedora packaging, but I've packaged for gentoo before. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Reducing reliance on "legacy" user-group store(s) like /etc/{passwd,group}
On Tuesday, May 27th, 2025 at 11:41 PM, Carlos Rodriguez-Fernandez
wrote:
> I wonder how this is going to play out in containers with user configs if
> "/etc/{passwd,group,shadow,gshadow}" becomes legacy.
Not in containers, just normal "desktop" systems only.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Reducing reliance on "legacy" user-group store(s) like /etc/{passwd,group}
On Wednesday, May 28th, 2025 at 2:43 AM, Lennart Poettering wrote: > systemd-userdbd and systemd-homed are two distinct things. Do not mix > them up. I understand. I meant to point out that systemd-userdbd is the central for querying all users and groups. AND that systemd-homed exposes itself through this via /run/systemd/userdb/io.systemd.Home > samba merged supprt for the former 3 months ago: > > https://gitlab.com/samba-team/samba/-/merge_requests/2928 Great > > Without a way to handle centralized login, we cannot consider any of > > it. On both Fedora KDE and Fedora Workstation, there are requirements > > to support GWS/Entra ID and AD/FreeIPA-based logins with local user > > storage. We discussed this in the Workstation WG several years ago[1] > > and it was even discussed here in devel@ last year[2] (with an LWN > > article to summarize it[3]). > > > > Right now, it's dead in the water without being able to handle the > > use-cases we need. So, we're likely to stick with the "legacy" > > file-based backend as our default until that situation is resolved. > > > Please read up on what's what. Surely... Thanks Kind regards, Pramod -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Reducing reliance on "legacy" user-group store(s) like /etc/{passwd,group}
On Wednesday, May 28th, 2025 at 12:46 PM, Lennart Poettering wrote: > On Mi, 28.05.25 09:43, Alexander Bokovoy (aboko...@redhat.com) wrote: > > > There > > are few issues with userdb API implementation. For example, there is an > > assumption only one responder knows the information about the account > > being requested. In real deployments we have to do group membership > > merges across multiple nss backends. userdb right now fails to provide a > > complete group membership for FreeIPA users, for example. This is not > > unique to FreeIPA, though, it would do the same for any non-static > > backend in a default configuration. > > > That's a misunderstanding. userdb user/group memberships are > implemented via the GetMemberships() IPC call, and of course it's > assumed that multiple backends provide these, and the results of all > backends are combined. After all, it's pretty much the default case > that a regular user for example managed by homed, is part of a > system-specific group (such as "wheel") which is managed via > /etc/passwd. > > In fact, it's even possible to put together a userdb backend that > doesn't provide any user or group records, but does provide membership > relationships for users of other backends. > > When doing NSS emulation nss-systemd understands this: when returning > a group record it will combine a specific userdb group record from one > backend with the results of a matching GetMemberships() of all > backends and return that as one "struct group" NSS record. Or in other > words: .gr_name, .gr_passwd, .gr_gid are initialized from the group > record JSON object, but .gr_mem is initialized from the combination of > the results of all GetMemberships() IPC calls. > > Lennart I understand how it's supposed to work. But the FreeIPA issue... Kind regards, Pramod -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Reducing reliance on "legacy" user-group store(s) like /etc/{passwd,group}
I am extremely sorry if I am posting to the wrong mailing list, kindly point
that out to me if that's the case.
I'll be referring to /etc/{passwd,group,shadow,gshadow} as "legacy file bundle"
or "legacy bundle" or "legacy file(s)"
systemd-userdbd.service is a service included in systemd, which:
- Dynamically creates records for "root" and "nobody" users, and these needn't
be in any of legacy files.
- Reads drop-ins from {/usr/lib,/etc}/userdb for "static" user and group
records with pre-defined ids (for now). This is appropriate for most of the
system users.
- Under /run/systemd/userdb, each provider of users and groups will provide a
varlink socket with a standard interface for querying for users and groups.
- All references to users and groups regarding membership of users into groups,
whenever/if a user/group doesn't exist in any of the providers, is silently
ignored.
- One of the services is meant as a compatibility mechanism for glibc NSS
modules.
- nss-systemd is a module which looks up user and group records via
systemd-userdbd.service interfaces.
- Care is taken to avoid recursion between nss-systemd and the glibc
compatibility hook.
- Drop-ins are supported to incrementally modify a user/group record (For
example add user "root" to groups without overriding systemd-userdbd's records).
For human users like you and me, there is systemd-homed.service
- It exposes the human users via systemd-userdbd.service interfaces.
- It supports many conveniences like per-user encryption (not openable just
with root)
- It is (almost) portable across systems.
- Much more
- Although minor SElinux issues exist...
The only thing I know which still uses the legacy bundle is systemd-sysusers,
it's random UID/GID allocation. It could use /etc/userdb or (preferably)
another /var/lib/systemd/userdb where sysusers will put the systemd-userdb
records (and remove them when sysusers.d entries are removed).
These tools overcome the problems of the legacy file bundle. (For example, on
fedora atomic desktops, the legacy file bundle is under /usr/lib instead of
/etc for packaged users and groups, in order to facilitate a hermetic /usr, and
then adding yourself to groups like incus or libvirt needs you to copy the
group line to the /etc bundle. This isn't an issue fo systemd-homed users,
where the record is dynamically synthesized and the user is in the correct
group.)
In conclusion, the systemd suite contains tools to improve user and group
management. With the exception of systemd-sysusers, everything can replace the
legacy file bundle with a more modern suite of integrated and extensible tools.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
