F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
Hi Benjamin, Ray,
I noticed this problem while dogfooding F34, I'm fully up2date as of today.
Today's gdm update did help in making the problem more clear.
What happens is that as soon as I press enter / click my main user in gdm, the password entry box keeps getting updated (and clearing its content) every 1 - 2 seconds with a "failed to authenticate with fingerprint" (or something like that) briefly showing below the password entry box every time it gets cleared.
After a non-fixed amount of tries it stops doing this and only then I can successfully login. The same happens on the lock screen of gnome-shell, except that there it never stops doing this.
The "failed to authenticate with fingerprint" is new as of todays gdm update, before this it was just "failed to authenticate". Now that I know fprintd is involved I've masked fprintd and that works around this.
As said I'm running a fully up2date F34 on a Thinkpad X1 carbon 8th gen, with the "Linux" fingerprint firmware installed by fwupd. I don't think I have ever enrolled a fingerprint, which might be part of the problem, but in that case it should really just act as if there is no fingerprint reader present.
The login dialog / fprintd should certainly _not_ repeatedly show the error IMHO even showing it once would be wrong here, but it would be a big improvement.
Let me know if you need any logs, want a bugzilla for this, or if there is anything else which I can do to help debug this.
Regards,
Hans
ah i think we need to pull in
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683
Ray
On Sat, Feb 27, 2021, 2:31 PM Hans de Goede hdegoede@redhat.com wrote:
Hi Benjamin, Ray,
I noticed this problem while dogfooding F34, I'm fully up2date as of today.
Today's gdm update did help in making the problem more clear.
What happens is that as soon as I press enter / click my main user in gdm, the password entry box keeps getting updated (and clearing its content) every 1 - 2 seconds with a "failed to authenticate with fingerprint" (or something like that) briefly showing below the password entry box every time it gets cleared.
After a non-fixed amount of tries it stops doing this and only then I can successfully login. The same happens on the lock screen of gnome-shell, except that there it never stops doing this.
The "failed to authenticate with fingerprint" is new as of todays gdm update, before this it was just "failed to authenticate". Now that I know fprintd is involved I've masked fprintd and that works around this.
As said I'm running a fully up2date F34 on a Thinkpad X1 carbon 8th gen, with the "Linux" fingerprint firmware installed by fwupd. I don't think I have ever enrolled a fingerprint, which might be part of the problem, but in that case it should really just act as if there is no fingerprint reader present.
The login dialog / fprintd should certainly _not_ repeatedly show the error IMHO even showing it once would be wrong here, but it would be a big improvement.
Let me know if you need any logs, want a bugzilla for this, or if there is anything else which I can do to help debug this.
Regards,
Hans _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
On Sat, Feb 27, 2021, 2:56 PM Ray Strode halfline@gmail.com wrote:
ah i think we need to pull in
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683
seems like this is already in updates. you definitely have the gnome-shell 40.beta installed? could be a pam_fprintd is returning a different error code than expected for no enrolled fingerprint
Hi,
On 2/27/21 9:16 PM, Ray Strode wrote:
Hi,
On Sat, Feb 27, 2021, 2:56 PM Ray Strode <halfline@gmail.com mailto:halfline@gmail.com> wrote:
ah i think we need to pull in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683 <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>seems like this is already in updates. you definitely have the gnome-shell 40.beta installed? could be a pam_fprintd is returning a different error code than expected for no enrolled fingerprint
[hans@x1 ~]$ rpm -q gnome-shell gnome-shell-40.0~beta-1.fc34.x86_64
Any debugging options which I can enable somewhere to show the pam_fprintd error ?
Regards,
Hans
Hi,
On Sun, Feb 28, 2021 at 9:46 AM Hans de Goede hdegoede@redhat.com wrote:
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683 <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>seems like this is already in updates. you definitely have the gnome-shell 40.beta installed? could be a pam_fprintd is returning a different error code than expected for no enrolled fingerprint
So we've been investigating this in the above upstream link.
There is a case where pam_fprintd is returning a code we aren't expecting, but, it shouldn't ever happen :-)
pam_fprintd checks up front if there are no enrolled fingerprints and then returns the correct error code in that case.
You guys are apparently getting past that part and failing later. Almost as if the prints were there and then a split second later disappeared.
One theory is there are files present, but they're unreadable. Maybe because of selinux?
Can you try in permissive mode, also output ls -lRZ /var/lib/fprint
Any debugging options which I can enable somewhere to show the pam_fprintd error ?
you can put "debug" on the ends of the lines that say pam_fprintd.so in /etc/pam.d/fingerprint-auth that should make the journal more chatty.
--Ray
Hi,
On 3/1/21 9:15 PM, Ray Strode wrote:
Hi,
On Sun, Feb 28, 2021 at 9:46 AM Hans de Goede hdegoede@redhat.com wrote:
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683 <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683>seems like this is already in updates. you definitely have the gnome-shell 40.beta installed? could be a pam_fprintd is returning a different error code than expected for no enrolled fingerprint
So we've been investigating this in the above upstream link.
There is a case where pam_fprintd is returning a code we aren't expecting, but, it shouldn't ever happen :-)
pam_fprintd checks up front if there are no enrolled fingerprints and then returns the correct error code in that case.
You guys are apparently getting past that part and failing later. Almost as if the prints were there and then a split second later disappeared.
One theory is there are files present, but they're unreadable. Maybe because of selinux?
Can you try in permissive mode, also output ls -lRZ /var/lib/fprint
permissive mode does not help
[hans@x1 linux]$ sudo ls -lRZ /var/lib/fprint /var/lib/fprint: total 0
Any debugging options which I can enable somewhere to show the pam_fprintd error ?
you can put "debug" on the ends of the lines that say pam_fprintd.so in /etc/pam.d/fingerprint-auth that should make the journal more chatty.
Ah, I think now we are getting somewhere. I have a script which I run to tweak new / upgraded installs to lower the amount of services which are running be default (mostly because of the 1G/2G RAM x86 Windows tablets which I try to support as a side project). This script contains the following:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
[hans@x1 linux]$
I think that that probably has something to do with this. So I guess I somewhat have myself to blame for this because of using non default settings (1).
Still it would be nice if we could get this to work again (as it did in F33 and older).
Regards,
Hans
1) Although IMHO this should actually be the default sssd is nice for corporate environments but in most cases it is totally unnecessary and adds a bunch of overhead. But that is a different discussion.
Hi,
Ahh, okay.
On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede hdegoede@redhat.com wrote:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
Ahhh, okay. So authselect is supposed to be writing out dconf files to set
org.gnome.login-screen enable-password-authentication false
in /etc when it neuters the fingerprint-auth stack. Can you file a bug?
There might also be some pam magic we could do to force it to return AUTHINFO_UNAVAIL in that case and then gnome-shell would DoTheRightThing(tm) even without the dconf change.
--Ray
On 3/2/21 4:25 PM, Ray Strode wrote:
Hi,
Ahh, okay.
On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede hdegoede@redhat.com wrote:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
minimal profile does not support fingerprint
Ahhh, okay. So authselect is supposed to be writing out dconf files to set
org.gnome.login-screen enable-password-authentication false
in /etc when it neuters the fingerprint-auth stack. Can you file a bug?
There might also be some pam magic we could do to force it to return AUTHINFO_UNAVAIL in that case and then gnome-shell would DoTheRightThing(tm) even without the dconf change.
--Ray
Can you reiterate the problem? The snippet above don't tell me much.
Pavel.
Hi,
On Tue, Mar 2, 2021, 11:20 AM Pavel Březina pbrezina@redhat.com wrote:
Can you reiterate the problem? The snippet above don't tell me much.
Sorry, let me summarize (but also see Benjamin's email).
Right now, if fingerprint auth is disabled in authselect, it's not disabling fingerprint auth at the graphical login screen.
To disable fingerprint auth at the login screen, it needs to write out a dconf file to tweak the enabled authentication methods. I'm pretty sure it used to do this, or at least authconfig did.
If it doesn't disable it in the dconf config, the login screen will try to use it. It will then fail, and the user will see an error message blink by 3 times as it keeps retrying.
Now, on to Benjamin's point, if the fingerprint-auth service returned AUTHINFO_UNAVAIL, then the login screen would treat the failure as a "service unavailable" failure, and know not to retry, which would be better that status quo. It would fix the user experience, but it's still not as good as not trying in the first place.
Of course, it wouldn't have to be an either/or. authselect could write out the dconf config, and make sure the fingerprint-auth stub service returns PAM_AUTHINFO_UNAVAIL instead of falling back to PAM_AUTH_ERR from the pam_deny in /etc/pam.d/other
make sense?
--Ray
On 3/2/21 10:21 PM, Ray Strode wrote:
Hi,
On Tue, Mar 2, 2021, 11:20 AM Pavel Březina pbrezina@redhat.com wrote:
Can you reiterate the problem? The snippet above don't tell me much.
Sorry, let me summarize (but also see Benjamin's email).
Right now, if fingerprint auth is disabled in authselect, it's not disabling fingerprint auth at the graphical login screen.
To disable fingerprint auth at the login screen, it needs to write out a dconf file to tweak the enabled authentication methods. I'm pretty sure it used to do this, or at least authconfig did.
If it doesn't disable it in the dconf config, the login screen will try to use it. It will then fail, and the user will see an error message blink by 3 times as it keeps retrying.
Authselect writes dconf but apparently it is missing from the minimal profile, I'll add it there.
https://github.com/authselect/authselect/issues/237
Now, on to Benjamin's point, if the fingerprint-auth service returned AUTHINFO_UNAVAIL, then the login screen would treat the failure as a "service unavailable" failure, and know not to retry, which would be better that status quo. It would fix the user experience, but it's still not as good as not trying in the first place.
Of course, it wouldn't have to be an either/or. authselect could write out the dconf config, and make sure the fingerprint-auth stub service returns PAM_AUTHINFO_UNAVAIL instead of falling back to PAM_AUTH_ERR from the pam_deny in /etc/pam.d/other
https://github.com/authselect/authselect/issues/238
make sense?
Yes, thank you. I opened the tickets and will fix them soon.
--Ray
On 3/3/21 11:02 AM, Pavel Březina wrote:
On 3/2/21 10:21 PM, Ray Strode wrote:
Hi,
On Tue, Mar 2, 2021, 11:20 AM Pavel Březina pbrezina@redhat.com wrote:
Can you reiterate the problem? The snippet above don't tell me much.
Sorry, let me summarize (but also see Benjamin's email).
Right now, if fingerprint auth is disabled in authselect, it's not disabling fingerprint auth at the graphical login screen.
To disable fingerprint auth at the login screen, it needs to write out a dconf file to tweak the enabled authentication methods. I'm pretty sure it used to do this, or at least authconfig did.
If it doesn't disable it in the dconf config, the login screen will try to use it. It will then fail, and the user will see an error message blink by 3 times as it keeps retrying.
Authselect writes dconf but apparently it is missing from the minimal profile, I'll add it there.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55
I'll also prepare F33 build.
Now, on to Benjamin's point, if the fingerprint-auth service returned AUTHINFO_UNAVAIL, then the login screen would treat the failure as a "service unavailable" failure, and know not to retry, which would be better that status quo. It would fix the user experience, but it's still not as good as not trying in the first place.
Of course, it wouldn't have to be an either/or. authselect could write out the dconf config, and make sure the fingerprint-auth stub service returns PAM_AUTHINFO_UNAVAIL instead of falling back to PAM_AUTH_ERR from the pam_deny in /etc/pam.d/other
https://github.com/authselect/authselect/issues/238
make sense?
Yes, thank you. I opened the tickets and will fix them soon.
--Ray
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
On 3/4/21 12:55 PM, Pavel Březina wrote:
On 3/3/21 11:02 AM, Pavel Březina wrote:
On 3/2/21 10:21 PM, Ray Strode wrote:
Hi,
On Tue, Mar 2, 2021, 11:20 AM Pavel Březina pbrezina@redhat.com wrote:
Can you reiterate the problem? The snippet above don't tell me much.
Sorry, let me summarize (but also see Benjamin's email).
Right now, if fingerprint auth is disabled in authselect, it's not disabling fingerprint auth at the graphical login screen.
To disable fingerprint auth at the login screen, it needs to write out a dconf file to tweak the enabled authentication methods. I'm pretty sure it used to do this, or at least authconfig did.
If it doesn't disable it in the dconf config, the login screen will try to use it. It will then fail, and the user will see an error message blink by 3 times as it keeps retrying.
Authselect writes dconf but apparently it is missing from the minimal profile, I'll add it there.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-d2afa6dc55
Thank you, I can confirm that this fixes the issue.
Regards,
Hans
On rawhide I upgraded to authselect-1.2.2-3.fc35 yet I am still encountering the issue of gdm repeatedly complaining about authentication via fingerprint. I've checked and authselect is using the 'ssd' profile.
On 3/4/21 9:11 PM, Tom Seewald wrote:
On rawhide I upgraded to authselect-1.2.2-3.fc35 yet I am still encountering the issue of gdm repeatedly complaining about authentication via fingerprint. I've checked and authselect is using the 'ssd' profile.
Can you please provide output of `authselect current`?
Can you please provide output of `authselect current`?
# authselect current Profile ID: sssd Enabled features: - with-fingerprint - with-silent-lastlog
# authselect check Current configuration is valid.
I have verified that both sssd and fprintd are running, and are not logging any errors.
On Fri, 2021-03-05 at 17:20 +0000, Tom Seewald wrote:
Can you please provide output of `authselect current`?
# authselect current Profile ID: sssd Enabled features:
- with-fingerprint
- with-silent-lastlog
# authselect check Current configuration is valid.
I have verified that both sssd and fprintd are running, and are not logging any errors.
Hmm, that might be a different issue then. I don't have a good idea right now, GDM complaining repeatedly generally means that the fingerprint-auth stack is failing with an error (other than PAM_AUTHINFO_UNAVAIL)
Could you modify fprintd.service, to set G_MESSAGES_DEBUG=all[1] and then grab a log of that? This will also tell us what is going on in pam_fprintd, and maybe from there we understand why the fingerprint-auth stack seems to be throwing errors.
Benjamin
[1] You can use systemd edit fprintd.service, then write:
[Service] Environment=G_MESSAGES_DEBUG=all
and safe that.
Could you modify fprintd.service, to set G_MESSAGES_DEBUG=all[1] and then grab a log of that?
Here's what I see from systemctl status fprintd.service:
Getting authorization to perform Polkit action net.reactivated.fprint.device.verify Authorization granted to AuthenTec AES2550/AES2810 to call method 'ListEnrolledFingers' for device :1.72! file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0' scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory Requesting device 'AuthenTec AES2550/AES2810' authorization for method ListEnrolledFingers from :1.74 Getting authorization to perform Polkit action net.reactivated.fprint.device.setusername Getting authorization to perform Polkit action net.reactivated.fprint.device.verify Authorization granted to AuthenTec AES2550/AES2810 to call method 'ListEnrolledFingers' for device :1.74! file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0' scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory
It looks like "/var/lib/fprint/" is a completely empty directory on my system.
On Fri, 2021-03-05 at 18:28 +0000, Tom Seewald wrote:
Could you modify fprintd.service, to set G_MESSAGES_DEBUG=all[1] and then grab a log of that?
Here's what I see from systemctl status fprintd.service:
Getting authorization to perform Polkit action net.reactivated.fprint.device.verify Authorization granted to AuthenTec AES2550/AES2810 to call method 'ListEnrolledFingers' for device :1.72! file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0' scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory Requesting device 'AuthenTec AES2550/AES2810' authorization for method ListEnrolledFingers from :1.74 Getting authorization to perform Polkit action net.reactivated.fprint.device.setusername Getting authorization to perform Polkit action net.reactivated.fprint.device.verify Authorization granted to AuthenTec AES2550/AES2810 to call method 'ListEnrolledFingers' for device :1.74! file_storage_discover_prints() for user 'tom' in '/var/lib/fprint/tom/aes2550/0' scan_dev_storedir(): opendir("/var/lib/fprint/tom/aes2550/0") failed: Error opening directory “/var/lib/fprint/tom/aes2550/0”: No such file or directory
It looks like "/var/lib/fprint/" is a completely empty directory on my system.
Yeah, that is expected if you have not enrolled any prints.
The log is exactly how I expected it. i.e. pam_fprintd asks whether there are any prints enrolled for the user. This will return zero (there are none) and pam_fprintd will return PAM_AUTHINFO_UNAVAIL.
So, from the perspective of PAM, everything seems correct to me. I think I might need to try and reproduce this myself.
Benjamin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
On 3/2/21 5:20 PM, Pavel Březina wrote:
On 3/2/21 4:25 PM, Ray Strode wrote:
Hi,
Ahh, okay.
On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede hdegoede@redhat.com wrote:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
minimal profile does not support fingerprint
So it seems there are 4 profiles:
[hans@x1 ~]$ authselect list - minimal Local users only for minimal installations - nis Enable NIS for system authentication - sssd Enable SSSD for system authentication (also for local users only) - winbind Enable winbind for system authentication
What I want is a profile which uses just the good old /etc files to avoid the overhead of running a local daemon (sssd tends to show up as one of the top 10 wakeup sources in powertop on an idle system) and I also don't want a config which tries to go out on the network.
So minimal seems to meet my needs; and although I personally do not have much of a need for fingerprint auth, I don't really see why we could not do fingerprint auth with the minimal config. I'm pretty sure I can manually create a pam-config where this works just fine.
I guess its in the name minimal, where as "local" might be (1) a better name. Note I'm not suggesting to add another profile just for this but it would be nice if fingerprint auth would at least be a (default off) feature for the minimal config.
Shall I file a RFE issue for this at: https://github.com/authselect/authselect/issues/
?
Regards,
Hans
1) Might have been a better name in retrospect, but meh
On 3/3/21 6:11 PM, Hans de Goede wrote:
Hi,
On 3/2/21 5:20 PM, Pavel Březina wrote:
On 3/2/21 4:25 PM, Ray Strode wrote:
Hi,
Ahh, okay.
On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede hdegoede@redhat.com wrote:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
minimal profile does not support fingerprint
So it seems there are 4 profiles:
[hans@x1 ~]$ authselect list
- minimal Local users only for minimal installations
- nis Enable NIS for system authentication
- sssd Enable SSSD for system authentication (also for local users only)
- winbind Enable winbind for system authentication
What I want is a profile which uses just the good old /etc files to avoid the overhead of running a local daemon (sssd tends to show up as one of the top 10 wakeup sources in powertop on an idle system) and I also don't want a config which tries to go out on the network.
So minimal seems to meet my needs; and although I personally do not have much of a need for fingerprint auth, I don't really see why we could not do fingerprint auth with the minimal config. I'm pretty
I'd say the answer is simple - if you go with minimal, you don't need fingerprint. And you wrote it yourself - you don't need fingerprint auth. Just because something can be done, does not mean it is worth to maintain it. More info below.
sure I can manually create a pam-config where this works just fine.
I guess its in the name minimal, where as "local" might be (1) a better
That's the point - it's minimal not local, not without-sssd. The readme explicitly says that it reserved for cases when you really care about disk and memory footprint.
It has very limited functionality by design. If you do not want to use SSSD, you can keep using sssd profile and just disable the service. It will keep working. The minimal profile is there for users that also want to remove sssd packages to safe resources, but in that case you probably don't care about fingerprint and smartcards either.
name. Note I'm not suggesting to add another profile just for this but it would be nice if fingerprint auth would at least be a (default off) feature for the minimal config.
Shall I file a RFE issue for this at: https://github.com/authselect/authselect/issues/
If you need fingerprint auth then open the ticket please - but no promises here. If you don't need it then just don't open the ticket :-)
If you need it, you can create custom profile for now: https://github.com/authselect/authselect/wiki/How-To:-Create-new-profile
?
Regards,
Hans
- Might have been a better name in retrospect, but meh
Hi,
On 3/4/21 11:50 AM, Pavel Březina wrote:
On 3/3/21 6:11 PM, Hans de Goede wrote:
Hi,
On 3/2/21 5:20 PM, Pavel Březina wrote:
On 3/2/21 4:25 PM, Ray Strode wrote:
Hi,
Ahh, okay.
On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede hdegoede@redhat.com wrote:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
minimal profile does not support fingerprint
So it seems there are 4 profiles:
[hans@x1 ~]$ authselect list
- minimal Local users only for minimal installations
- nis Enable NIS for system authentication
- sssd Enable SSSD for system authentication (also for local users only)
- winbind Enable winbind for system authentication
What I want is a profile which uses just the good old /etc files to avoid the overhead of running a local daemon (sssd tends to show up as one of the top 10 wakeup sources in powertop on an idle system) and I also don't want a config which tries to go out on the network.
So minimal seems to meet my needs; and although I personally do not have much of a need for fingerprint auth, I don't really see why we could not do fingerprint auth with the minimal config. I'm pretty
I'd say the answer is simple - if you go with minimal, you don't need fingerprint. And you wrote it yourself - you don't need fingerprint auth. Just because something can be done, does not mean it is worth to maintain it. More info below.
sure I can manually create a pam-config where this works just fine.
I guess its in the name minimal, where as "local" might be (1) a better
That's the point - it's minimal not local, not without-sssd. The readme explicitly says that it reserved for cases when you really care about disk and memory footprint.
It has very limited functionality by design. If you do not want to use SSSD, you can keep using sssd profile and just disable the service. It will keep working. The minimal profile is there for users that also want to remove sssd packages to safe resources, but in that case you probably don't care about fingerprint and smartcards either.
The problem is that IMHO having sssd enabled by default is really the wrong thing to do for like 95% of our users and defaults should be the settings which are best for most / almost all users.
This is really just a symptom of a much bigger problem though, which is that we simply have way too much services / daemon's starting up by default. The output of "ps aux" after a default Fedora workstation install is just way way too long. Once upon a time Linux users used to make fun of Windows with all its background processes in the mean time a default Fedora WS install has gotten worse then Windows wrt background processes. Any of these are totally unnecessary for most of our users.
We really should be smarter here and the config tools which allows a user to enroll in an authentication domain enable the sssd config when that happens and not have this on by default for everyone.
So what I would really like to see is a local profile which uses just /etc files + fprintd if there are fingerprints enrolled. Smartcards are a different story, because those likely also need significant extra setup.
Where as fingerprints can easily be enrolled from the local UI tools.
name. Note I'm not suggesting to add another profile just for this but it would be nice if fingerprint auth would at least be a (default off) feature for the minimal config.
Shall I file a RFE issue for this at: https://github.com/authselect/authselect/issues/
If you need fingerprint auth then open the ticket please - but no promises here. If you don't need it then just don't open the ticket :-)
Rather then opening a ticket, what I would really like to see is a good discussion about why the sssd profile is the default, because IMHO it is a bad default for most users.
Regards,
Hans
On Thu, 4 Mar 2021 at 11:21, Hans de Goede hdegoede@redhat.com wrote:
Hi,
It has very limited functionality by design. If you do not want to use
SSSD, you can keep using sssd profile and just disable the service. It will keep working. The minimal profile is there for users that also want to remove sssd packages to safe resources, but in that case you probably don't care about fingerprint and smartcards either.
The problem is that IMHO having sssd enabled by default is really the wrong thing to do for like 95% of our users and defaults should be the settings which are best for most / almost all users.
This is really just a symptom of a much bigger problem though, which is that we simply have way too much services / daemon's starting up by default. The output of "ps aux" after a default Fedora workstation install is just way way too long. Once upon a time Linux users used to make fun of Windows with all its background processes in the mean time a default Fedora WS install has gotten worse then Windows wrt background processes. Any of these are totally unnecessary for most of our users.
I am not sure about this. What services are you seeing which are extraneous? I do see ps aux is going on miles and miles, but of the 218 processes I see from startup time on my workstation, I see 165 of them are kernel processes versus user space ones. Of the remaining 53, most of them seem hardware oriented (irqbalance, bluetooth, modemmanager, smartd, udisksd, upowerd, etc). Looking at the rest we have about 20 processes which seem outside of 'I don't want my laptop to work with modern hardware' and that would be abrt, atd/crond/cupsd, packagekitd, colord, and the sssd processes. So while ps auxww has a lot more going on in it, I actually see a lot fewer extraneous processes than I remember from my Fedora 18 days.
Hi,
On 3/4/21 5:38 PM, Stephen John Smoogen wrote:
On Thu, 4 Mar 2021 at 11:21, Hans de Goede <hdegoede@redhat.com mailto:hdegoede@redhat.com> wrote:
Hi, > It has very limited functionality by design. If you do not want to use SSSD, you can keep using sssd profile and just disable the service. It will keep working. The minimal profile is there for users that also want to remove sssd packages to safe resources, but in that case you probably don't care about fingerprint and smartcards either. The problem is that IMHO having sssd enabled by default is really the wrong thing to do for like 95% of our users and defaults should be the settings which are best for most / almost all users. This is really just a symptom of a much bigger problem though, which is that we simply have way too much services / daemon's starting up by default. The output of "ps aux" after a default Fedora workstation install is just way way too long. Once upon a time Linux users used to make fun of Windows with all its background processes in the mean time a default Fedora WS install has gotten worse then Windows wrt background processes. Any of these are totally unnecessary for most of our users.I am not sure about this. What services are you seeing which are extraneous? I do see ps aux is going on miles and miles, but of the 218 processes I see from startup time on my workstation, I see 165 of them are kernel processes versus user space ones. Of the remaining 53, most of them seem hardware oriented (irqbalance, bluetooth, modemmanager, smartd, udisksd, upowerd, etc). Looking at the rest we have about 20 processes which seem outside of 'I don't want my laptop to work with modern hardware' and that would be abrt, atd/crond/cupsd, packagekitd, colord, and the sssd processes. So while ps auxww has a lot more going on in it, I actually see a lot fewer extraneous processes than I remember from my Fedora 18 days.
20 processes is still a lot when e.g. booting from an eMMC or a sdcard those add a significant amount of time to the startupo time.
Also a bunch of what you call hw-related processes are not really necessary. E.g. irqbalance is really only needed on multi-CPU-socket or otherwise exotic systems. Modemmanager really should only run when there actually is a modem (it should be hw-activated, but that is easier said then done), smartd is not really useful, it logs smart issues in syslog/the journal but unless someone is actively monitoring those logs it really does not have much added value, etc.
But yes your list of 20 processes, and then specifically abrt (which really should be strictly event driven/activated and should not be running all the time) and atd/crond are the ones which I'm talking about.
Those + a bunch of processes which GNOME adds on top. E.g. a whole bunch of evolution processes even though I'm not using the calendar integration, see: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3466
But also gnome-software which is running by default to provide a search-provider, which is a nice feature but the RAM consumption really is too high for that feature on systems with less then 2G of RAM (I know the gnome-software guys have been working on reducing the footprint, but it still is quite large).
Etc. just for fun do an ls of /etc/xdg/autostart with a default workstation install.
Each one of these processes is there for a reason and many of them are small or exit relatively quickly after having been started but together they really add up.
IIRC a default GNOME workstation install consumes about 700-800MB of RAM when logged into the desktop on a 1G RAM system. After I've done a bunch of hacks / tweaks to remove a long list of unnecessary (1) processes I have it down to around 400MB of RAM.
Note I'm not trying to blame anyone here; and especially not the authors/maintainers of the mentioned packages, but I do wish that we (the Fedora project) could make some time to go over this list and try to stop a whole bunch of programs / daemons from always starting when that is (IMHO) not really necessary. I would really like to see Fedora to become somewhat more lean / go on a diet here, which is something which I think would benefit everyone.
Given that I can halve the base processes RAM set with some hacks I think that it is fair to say that there are still way too much things starting by default. I have actually been considering doing a Fedora workstation light spin for budget x86 machines with 1G / 2G of RAM and an eMMC.
Regards,
Hans
1) I do realize that what is unnecessary or not is somewhat in the eye of the beholder.
Given that I can halve the base processes RAM set with some hacks I think that it is fair to say that there are still way too much things starting by default.
I have actually been considering doing a Fedora workstation light spin for budget x86 machines with 1G / 2G of RAM and an eMMC.
A better way of documenting this might also be helpful, and would guide paring down the default services. I like much of the GNOME desktop, but I prefer Awesome to GNOME's window manager construct. Sometimes I find it difficult to piece together the services I need (e.g., to support Bluetooth or the ability to run gnome-control-center) while replacing other GNOME parts with Awesome.
As with Hans, I happily acknowledge that I am not the common use case. I just think that there might be ways to make things feel a little more modular.
On Thu, 4 Mar 2021 at 13:50, Hans de Goede hdegoede@redhat.com wrote:
Hi,
snip
IIRC a default GNOME workstation install consumes about 700-800MB of RAM when logged into the desktop on a 1G RAM system. After I've done a bunch of hacks / tweaks to remove a long list of unnecessary (1) processes I have it down to around 400MB of RAM.
Note I'm not trying to blame anyone here; and especially not the authors/maintainers of the mentioned packages, but I do wish that we (the Fedora project) could make some time to go over this list and try to stop a whole bunch of programs / daemons from always starting when that is (IMHO) not really necessary. I would really like to see Fedora to become somewhat more lean / go on a diet here, which is something which I think would benefit everyone.
The problem is that every time this conversation starts... you end up with 200 people all wanting some other program to be stopped/not run/removed but not something they actually think is essential. And instead we end up finding we needed to add one or two things because a lot of users wanted this or that. Workstation like Server like Cloud are going to be general operating systems which are built around fitting the majority of problems people want solved versus a small set of things you or I want in a system. This leads to compromises.. a lot of them.
Given that I can halve the base processes RAM set with some hacks I think
that it is fair to say that there are still way too much things starting by default. I have actually been considering doing a Fedora workstation light spin for budget x86 machines with 1G / 2G of RAM and an eMMC.
I agree and think that a spin would be needed. There is going to be an audience for it, but I expect it is a distinct set who are looking for it on small environments and can put up with not having access to 'XYZ app which needs 12 GB of ram out the block'
Regards,
Hans
- I do realize that what is unnecessary or not is somewhat in the eye of
the beholder.
The problem is that every time this conversation starts... you end up with 200 people all wanting some other program to be stopped/not run/removed but not something they actually think is essential. And instead we end up finding we needed to add one or two things because a lot of users wanted this or that. Workstation like Server like Cloud are going to be general operating systems which are built around fitting the majority of problems people want solved versus a small set of things you or I want in a system. This leads to compromises.. a lot of them.
I think Hans is suggesting that these services are enabled on demand based on events, e.g. modemmanager only starting when a modem is present, rather than simply set to enabled (or disabled) by default. Perhaps that's not possible, but I don't think Hans is asking for services to simply be pruned at the expense of other users.
On Thu, Mar 04, 2021 at 02:43:26PM -0500, Stephen John Smoogen wrote:
I have actually been considering doing a Fedora workstation light spin for budget x86 machines with 1G / 2G of RAM and an eMMC.
I agree and think that a spin would be needed. There is going to be an audience for it, but I expect it is a distinct set who are looking for it on small environments and can put up with not having access to 'XYZ app which needs 12 GB of ram out the block'
I think there's probably three things:
1. A lightweight spin for more extreme use cases
2. Looking at the big things like packagekitd and gnome-software that could perhaps be altered or slimmed down. (For example: perhaps a much more lightweight process for _just_ the search provider, and maybe even something that doesn't need to run all the time to provide that?)
3. Working to move more things to be activated only when needed, or only run when they make sense. Modem Manager, Speech Dispatcher.... I see I'm running bluetoothd on my desktop system which does not have bluetooth. And I don't sync my calendar to my desktop, so all of the infrastructure for doing that is just running for no reason.
On Thu, Mar 04, 2021 at 07:50:11PM +0100, Hans de Goede wrote:
I am not sure about this. What services are you seeing which are extraneous? I do see ps aux is going on miles and miles, but of the 218 processes I see from startup time on my workstation, I see 165 of them are kernel processes versus user space ones. Of the remaining 53, most of them seem hardware oriented (irqbalance, bluetooth, modemmanager, smartd, udisksd, upowerd, etc). Looking at the rest we have about 20 processes which seem outside of 'I don't want my laptop to work with modern hardware' and that would be abrt, atd/crond/cupsd, packagekitd, colord, and the sssd processes. So while ps auxww has a lot more going on in it, I actually see a lot fewer extraneous processes than I remember from my Fedora 18 days.
20 processes is still a lot when e.g. booting from an eMMC or a sdcard those add a significant amount of time to the startupo time.
I agree, we really have too many things starting, to many things running, and too many things generating errors.
Instead of 'ps aux', 'systemctl -t service --state running' is easier to interpret: UNIT LOAD ACTIVE SUB DESCRIPTION accounts-daemon.service loaded active running Accounts Service alsa-state.service loaded active running Manage Sound Card State (restore and store) ^ do we really need this
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack bluetooth.service loaded active running Bluetooth service colord.service loaded active running Manage, Install and Generate Color Profiles cups.service loaded active running CUPS Scheduler ^ this should be socket activated, I haven't printed *anything* on this machine ever dbus-:1.2-org.freedesktop.problems@0.service loaded active running dbus-:1.2-org.freedesktop.problems@0.service dbus-broker.service loaded active running D-Bus System Message Bus firewalld.service loaded active running firewalld - dynamic firewall daemon gdm.service loaded active running GNOME Display Manager geoclue.service loaded active running Location Lookup Service gpm.service loaded active running Console Mouse manager iio-sensor-proxy.service loaded active running IIO Sensor Proxy service libvirtd.service loaded active running Virtualization daemon low-memory-monitor.service loaded active running Low Memory Monitor ^ this is interesting. gnome-shell.rpm requires lower-memory-monitor.rpm, and the default preset is on. Do we still want this with systemd-oomd being on by default?
mcelog.service loaded active running Machine Check Exception Logging Daemon ModemManager.service loaded active running Modem Manager NetworkManager.service loaded active running Network Manager pcscd.service loaded active running PC/SC Smart Card Daemon pmcd.service loaded active running Performance Metrics Collector Daemon pmie.service loaded active running Performance Metrics Inference Engine pmlogger.service loaded active running Performance Metrics Archive Logger polkit.service loaded active running polkit.service sssd-kcm.service loaded active running SSSD Kerberos Cache Manager sssd.service loaded active running System Security Services Daemon switcheroo-control.service loaded active running Switcheroo Control Proxy service systemd-homed.service loaded active running Home Area Manager ^ hmm, I would think this would be go away on its own. Maybe something to fix upstream.
systemd-journald.service loaded active running Journal Service systemd-logind.service loaded active running User Login Management systemd-machined.service loaded active running Virtual Machine and Container Registration Service systemd-networkd.service loaded active running Network Service systemd-resolved.service loaded active running Network Name Resolution systemd-timesyncd.service loaded active running Network Time Synchronization systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files systemd-userdbd.service loaded active running User Database Manager udisks2.service loaded active running Disk Manager upower.service loaded active running Daemon for power management user@1000.service loaded active running User Manager for UID 1000 user@6.service loaded active running User Manager for UID 6 wpa_supplicant.service loaded active running WPA supplicant
Then there's 'systemctl --user -t service --state running' which is even longer :(
E.g. at-spi-dbus-bus.service has it's own dbus-broker instance. That's better than in the past, at least it's not a different implementation of dbus than the session bus ;) But we should consider if we can use the session bus again. (In the past, dbus-daemon wasn't efficient enough, so a separate bus was created. But dbus-broker is supposed to be more efficient.)
Note I'm not trying to blame anyone here; and especially not the authors/maintainers of the mentioned packages
As one of those, I would say that the authors/maintainers of those packages are the people best positioned to fix things. For example, systemd-homed probably shouldn't be running, but this is something to figure out upstream.
(BTW, one thing which has improved a lot in this list is the pcp stack. It's still 3 services with ~10 processes altogether, but the total memory usage is <50MB, and CPU usage which was excessive last year is reasonable. The maintainers put in the work here.)
but I do wish that we (the Fedora project) could make some time to go over this list and try to stop a whole bunch of programs / daemons from always starting when that is (IMHO) not really necessary. I would really like to see Fedora to become somewhat more lean / go on a diet here, which is something which I think would benefit everyone.
Yes.
Given that I can halve the base processes RAM set with some hacks I think that it is fair to say that there are still way too much things starting by default. I have actually been considering doing a Fedora workstation light spin for budget x86 machines with 1G / 2G of RAM and an eMMC.
I think there's still plenty of stuff to improve that will apply everywhere. homed, alsactl, geoclue, colord just shouldn't need to be there all the time.
Zbyszek
Hi,
On 3/5/21 1:56 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Mar 04, 2021 at 07:50:11PM +0100, Hans de Goede wrote:
I am not sure about this. What services are you seeing which are extraneous? I do see ps aux is going on miles and miles, but of the 218 processes I see from startup time on my workstation, I see 165 of them are kernel processes versus user space ones. Of the remaining 53, most of them seem hardware oriented (irqbalance, bluetooth, modemmanager, smartd, udisksd, upowerd, etc). Looking at the rest we have about 20 processes which seem outside of 'I don't want my laptop to work with modern hardware' and that would be abrt, atd/crond/cupsd, packagekitd, colord, and the sssd processes. So while ps auxww has a lot more going on in it, I actually see a lot fewer extraneous processes than I remember from my Fedora 18 days.
20 processes is still a lot when e.g. booting from an eMMC or a sdcard those add a significant amount of time to the startupo time.
I agree, we really have too many things starting, to many things running, and too many things generating errors.
Instead of 'ps aux', 'systemctl -t service --state running' is easier to interpret: UNIT LOAD ACTIVE SUB DESCRIPTION accounts-daemon.service loaded active running Accounts Service alsa-state.service loaded active running Manage Sound Card State (restore and store) ^ do we really need this
This used to be a startup / shutdown job thing only, but now I think it periodically saves the state. It might be good to file a (polite) bug against alsa-lib for this and see what Jaroslav has to say about this.
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack bluetooth.service loaded active running Bluetooth service colord.service loaded active running Manage, Install and Generate Color Profiles cups.service loaded active running CUPS Scheduler ^ this should be socket activated, I haven't printed *anything* on this machine ever
Agreed
dbus-:1.2-org.freedesktop.problems@0.service loaded active running dbus-:1.2-org.freedesktop.problems@0.service dbus-broker.service loaded active running D-Bus System Message Bus firewalld.service loaded active running firewalld - dynamic firewall daemon gdm.service loaded active running GNOME Display Manager geoclue.service loaded active running Location Lookup Service gpm.service loaded active running Console Mouse manager iio-sensor-proxy.service loaded active running IIO Sensor Proxy service libvirtd.service loaded active running Virtualization daemon low-memory-monitor.service loaded active running Low Memory Monitor ^ this is interesting. gnome-shell.rpm requires lower-memory-monitor.rpm, and the default preset is on. Do we still want this with systemd-oomd being on by default?
mcelog.service loaded active running Machine Check Exception Logging Daemon
This is another one for which it is questionable to have it running, or is this a machine with ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it just logs some stuff into syslog (where normal users won't see it).
ModemManager.service loaded active running Modem Manager NetworkManager.service loaded active running Network Manager pcscd.service loaded active running PC/SC Smart Card Daemon pmcd.service loaded active running Performance Metrics Collector Daemon pmie.service loaded active running Performance Metrics Inference Engine pmlogger.service loaded active running Performance Metrics Archive Logger polkit.service loaded active running polkit.service sssd-kcm.service loaded active running SSSD Kerberos Cache Manager sssd.service loaded active running System Security Services Daemon switcheroo-control.service loaded active running Switcheroo Control Proxy service systemd-homed.service loaded active running Home Area Manager ^ hmm, I would think this would be go away on its own. Maybe something to fix upstream.
systemd-journald.service loaded active running Journal Service systemd-logind.service loaded active running User Login Management systemd-machined.service loaded active running Virtual Machine and Container Registration Service systemd-networkd.service loaded active running Network Service systemd-resolved.service loaded active running Network Name Resolution systemd-timesyncd.service loaded active running Network Time Synchronization systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files systemd-userdbd.service loaded active running User Database Manager udisks2.service loaded active running Disk Manager upower.service loaded active running Daemon for power management user@1000.service loaded active running User Manager for UID 1000 user@6.service loaded active running User Manager for UID 6 wpa_supplicant.service loaded active running WPA supplicant
Then there's 'systemctl --user -t service --state running' which is even longer :(
Yes, a good way to trim that down is also to look under /etc/xdg/autostart and remove packages which you don't use which drop a file there.
E.g. at-spi-dbus-bus.service has it's own dbus-broker instance. That's better than in the past, at least it's not a different implementation of dbus than the session bus ;) But we should consider if we can use the session bus again. (In the past, dbus-daemon wasn't efficient enough, so a separate bus was created. But dbus-broker is supposed to be more efficient.)
Note I'm not trying to blame anyone here; and especially not the authors/maintainers of the mentioned packages
As one of those, I would say that the authors/maintainers of those packages are the people best positioned to fix things. For example, systemd-homed probably shouldn't be running, but this is something to figure out upstream.
(BTW, one thing which has improved a lot in this list is the pcp stack. It's still 3 services with ~10 processes altogether, but the total memory usage is <50MB, and CPU usage which was excessive last year is reasonable. The maintainers put in the work here.)
but I do wish that we (the Fedora project) could make some time to go over this list and try to stop a whole bunch of programs / daemons from always starting when that is (IMHO) not really necessary. I would really like to see Fedora to become somewhat more lean / go on a diet here, which is something which I think would benefit everyone.
Yes.
Given that I can halve the base processes RAM set with some hacks I think that it is fair to say that there are still way too much things starting by default. I have actually been considering doing a Fedora workstation light spin for budget x86 machines with 1G / 2G of RAM and an eMMC.
I think there's still plenty of stuff to improve that will apply everywhere. homed, alsactl, geoclue, colord just shouldn't need to be there all the time.
I agree and TBH I was surprised that there were quite a few reactions suggesting that such a spin would be a good idea. OTOH such a spin will give lots of room for experimentation, to try out various things to improve the situation which we can then merge back into the regular Fedora Workstation.
So given that I got a couple of "go for it" reactions and that I was already toying with the idea anyways I might actually try to make such a spin happen.
The biggest problem for doing such a spin is finding the time for it...
Are there any people who would be interested in working on / co-maintaining such a spin with me ?
Regards,
Hans
On Fri, Mar 05, 2021 at 03:05:00PM +0100, Hans de Goede wrote:
mcelog.service loaded active running Machine Check Exception Logging Daemon
This is another one for which it is questionable to have it running, or is this a machine with ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it just logs some stuff into syslog (where normal users won't see it).
I disagree that those logs are useless -- I often help normal users, and running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course.
So given that I got a couple of "go for it" reactions and that I was already toying with the idea anyways I might actually try to make such a spin happen.
The biggest problem for doing such a spin is finding the time for it...
Are there any people who would be interested in working on / co-maintaining such a spin with me ?
I am interested in it happening but can't sign up for more stuff. :)
It seems like this kind of parallels the Minimization objective (which focuses on package dependencies). That's kind of mothballed right now (I think because Adam is working on RHEL 9 stuff?) and I wouldn't want to overload that more, but maybe there's some kind of useful connection?
Dnia Fri, Mar 05, 2021 at 10:17:17AM -0500, Matthew Miller napisał(a):
On Fri, Mar 05, 2021 at 03:05:00PM +0100, Hans de Goede wrote:
mcelog.service loaded active running Machine Check Exception Logging Daemon
This is another one for which it is questionable to have it running, or is this a machine with ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it just logs some stuff into syslog (where normal users won't see it).
I disagree that those logs are useless -- I often help normal users, and running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course.
They are useful. smartd even sends emails – that's how I was informed about one of my disks dying, few weeks ago,
On Fri, Mar 05, 2021 at 05:12:34PM +0100, Tomasz Torcz wrote:
This is another one for which it is questionable to have it running, or is this a machine with ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it just logs some stuff into syslog (where normal users won't see it).
I disagree that those logs are useless -- I often help normal users, and running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course.
They are useful. smartd even sends emails – that's how I was informed about one of my disks dying, few weeks ago,
It can, but most people don't have a good setup for even local mail delivery. Out of the box, we don't really do anything useful. It'd be nice for our desktop offerings to have some kind of way of showing these messages in a helpful way.
On Fri, Mar 05, 2021 at 11:35:37AM -0500, Matthew Miller wrote:
On Fri, Mar 05, 2021 at 05:12:34PM +0100, Tomasz Torcz wrote:
This is another one for which it is questionable to have it running, or is this a machine with ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it just logs some stuff into syslog (where normal users won't see it).
I disagree that those logs are useless -- I often help normal users, and running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course.
They are useful. smartd even sends emails – that's how I was informed about one of my disks dying, few weeks ago,
It can, but most people don't have a good setup for even local mail delivery. Out of the box, we don't really do anything useful. It'd be nice for our desktop offerings to have some kind of way of showing these messages in a helpful way.
Once we reach the noble goal of having 0 warnings during boot by default, we could just issue a notification whenever anything pops up. We do that for kernel oops already.
Zbyszek
On Fri, Mar 05, 2021 at 05:25:40PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Once we reach the noble goal of having 0 warnings during boot by default, we could just issue a notification whenever anything pops up. We do that for kernel oops already.
Right??? It might be worthwhile sometime actually making that a release focus. We had someone on Ask Fedora last night posting about basically every warning message he got asking what was wrong and how to fix it, and I don't _really_ feel great about "oh yeah, that's just noise... I mean, it's a real problem, but not a big deal, the message isn't meant for you... just ignore it" as the answer.
On Sat, Mar 06, 2021 at 12:00:39PM -0500, Matthew Miller wrote:
On Fri, Mar 05, 2021 at 05:25:40PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Once we reach the noble goal of having 0 warnings during boot by default, we could just issue a notification whenever anything pops up. We do that for kernel oops already.
Right??? It might be worthwhile sometime actually making that a release focus. We had someone on Ask Fedora last night posting about basically every warning message he got asking what was wrong and how to fix it, and I don't _really_ feel great about "oh yeah, that's just noise... I mean, it's a real problem, but not a big deal, the message isn't meant for you... just ignore it" as the answer.
Maybe we could make this work with some filter list. Right now there's just *so* much noise. But a lot of it is repeatable. We want/need to keep the warnings for developers, but for users, we could just show unexpected stuff.
Zbyszek
On Sat, Mar 06, 2021 at 06:04:33PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Maybe we could make this work with some filter list. Right now there's just *so* much noise. But a lot of it is repeatable. We want/need to keep the warnings for developers, but for users, we could just show unexpected stuff.
Well also, we could resolve some of them. Like from here: https://ask.fedoraproject.org/t/systemd-sysv-generator-lacking-native-file/1...
[ 4.767388] systemd-sysv-generator[1062]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. [ 4.767416] systemd-sysv-generator[1062]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. [ 4.771792] zram_generator::generator[1064]: Creating dev-zram0.swap for /dev/zram0 (4096MB)
[ 3.109161] systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. [ 3.128105] systemd[1]: /usr/lib/systemd/system/alsa-restore.service:15: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. [ 3.139960] systemd[1]: /usr/lib/systemd/system/mcelog.service:8: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether.
On Sat, Mar 06, 2021 at 01:21:15PM -0500, Matthew Miller wrote:
On Sat, Mar 06, 2021 at 06:04:33PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Maybe we could make this work with some filter list. Right now there's just *so* much noise. But a lot of it is repeatable. We want/need to keep the warnings for developers, but for users, we could just show unexpected stuff.
Well also, we could resolve some of them. Like from here: https://ask.fedoraproject.org/t/systemd-sysv-generator-lacking-native-file/1...
[ 4.767388] systemd-sysv-generator[1062]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. [ 4.767416] systemd-sysv-generator[1062]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust.
I think AdamW had some initial work done for this years ago. (Or maybe it was only discussed?) Either way, this would be very nice for other reasons too, no just to silence the warning, but it's not a trivial endeavour.
[ 4.771792] zram_generator::generator[1064]: Creating dev-zram0.swap for /dev/zram0 (4096MB)
This one is already fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2021-08c87dbaa9, which is waiting for the beta freeze to end.
[ 3.109161] systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. [ 3.128105] systemd[1]: /usr/lib/systemd/system/alsa-restore.service:15: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. [ 3.139960] systemd[1]: /usr/lib/systemd/system/mcelog.service:8: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether.
Zbyszek
Matthew Miller wrote:
On Fri, Mar 05, 2021 at 05:12:34PM +0100, Tomasz Torcz wrote:
smartd even sends emails – that's how I was informed about one of my disks dying, few weeks ago,
I thought it would send email, but then I noticed that it's started with "--capabilities", which breaks email notification according to the manpage, so now I don't know what to believe.
It does indeed seem much less useful if it can't send email. Unless Logwatch picks up the warnings from the log? But that again requires local email.
It can, but most people don't have a good setup for even local mail delivery. Out of the box, we don't really do anything useful.
It wouldn't take much. Install Postfix, and when Anaconda creates the first user account, have it add a mapping from root to that username in /etc/aliases. Then a variety of MUAs can pick up the emails from /var/spool/mail.
But I guess those who want fewer daemons won't be happy to see Postfix added just for a chance to be warned about an imminent breakdown.
Björn Persson
On Sun, Mar 07, 2021 at 10:26:50AM +0100, Björn Persson wrote:
It can, but most people don't have a good setup for even local mail delivery. Out of the box, we don't really do anything useful.
It wouldn't take much. Install Postfix, and when Anaconda creates the first user account, have it add a mapping from root to that username in /etc/aliases. Then a variety of MUAs can pick up the emails from /var/spool/mail.
Well but even then the user needs to know to look for local mail. That's not a normal expecation for even many Linux folks these days.
I think for desktop we'd be better off looking for a notification solution that doesn't need mail as a transport layer.
Dnia Sun, Mar 07, 2021 at 12:55:21PM -0500, Matthew Miller napisał(a):
On Sun, Mar 07, 2021 at 10:26:50AM +0100, Björn Persson wrote:
It can, but most people don't have a good setup for even local mail delivery. Out of the box, we don't really do anything useful.
It wouldn't take much. Install Postfix, and when Anaconda creates the first user account, have it add a mapping from root to that username in /etc/aliases. Then a variety of MUAs can pick up the emails from /var/spool/mail.
Well but even then the user needs to know to look for local mail. That's not a normal expecation for even many Linux folks these days.
I think for desktop we'd be better off looking for a notification solution that doesn't need mail as a transport layer.
I have vague recollection of GNOME popup warning me about disk problems discovered by SMART. I see /usr/libexec/gsd-disk-utility-notify running in my session, that was probably the source of the notification.
Matthew Miller wrote:
On Sun, Mar 07, 2021 at 10:26:50AM +0100, Björn Persson wrote:
It can, but most people don't have a good setup for even local mail delivery. Out of the box, we don't really do anything useful.
It wouldn't take much. Install Postfix, and when Anaconda creates the first user account, have it add a mapping from root to that username in /etc/aliases. Then a variety of MUAs can pick up the emails from /var/spool/mail.
Well but even then the user needs to know to look for local mail. That's not a normal expecation for even many Linux folks these days.
Unless their MUA does that by default. I'm not sure how many do. I can't think of any strong reasons to have it disabled.
I once had a problem with local email disappearing on a freshly installed laptop. It turned out that Seamonkey was picking it up and moving it to its own mail directory. That was not so good because I was using Seamonkey only as a browser, not for mail. If it had waited until I opened Seamonkey Mail before picking up local mail, then I would have been quite happy about it.
Gmail users would miss it I suppose. There are some disadvantages to relying on web services for everything.
Björn Persson
Do any of the bugs in this thread need to be proposed as blockers or freeze exceptions, for beta or final?
This looks like it might have been lost in process because it got closed due to a fix for Fedora 33 instead of staying open until the F34 fix goes stable. https://bugzilla.redhat.com/show_bug.cgi?id=1933520
And a similar sounding bug that's affecting some users: https://bugzilla.redhat.com/show_bug.cgi?id=1935331
-- Chris Murphy
Hi Chris and others,
On Mon, 2021-03-08 at 22:38 -0700, Chris Murphy wrote:
Do any of the bugs in this thread need to be proposed as blockers or freeze exceptions, for beta or final?
This looks like it might have been lost in process because it got closed due to a fix for Fedora 33 instead of staying open until the F34 fix goes stable. https://bugzilla.redhat.com/show_bug.cgi?id=1933520
And a similar sounding bug that's affecting some users: https://bugzilla.redhat.com/show_bug.cgi?id=1935331
So, I just had another look.
The analysis was correct for the fingerprint-auth stack. But, as it turns out, we have an almost identical issue when fingerprint authentication is enabled. The fix is simple, will post an MR and update the issue in a bit.
I'll also ask for the bug to be qualified as a blocker.
Benjamin
-- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
On 3/5/21 4:17 PM, Matthew Miller wrote:
On Fri, Mar 05, 2021 at 03:05:00PM +0100, Hans de Goede wrote:
mcelog.service loaded active running Machine Check Exception Logging Daemon
This is another one for which it is questionable to have it running, or is this a machine with ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it just logs some stuff into syslog (where normal users won't see it).
I disagree that those logs are useless -- I often help normal users, and running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course.
But for MCE exceptions, specifically ECC errors I would expect the kernel to log these through dmesg anyways and then the mcelog service has very little added value IMHO (I have no experience with machines with ECC RAM).
Esp. given that ECC RAM is something which most Fedora Workstation users won't have, so having this included / enabled by default feels wrong IMHO.
smartd at least has the fact that if it does not run nothing else is asking the disk for its smart reports going for it (and that it may tickle bugs in some disks, which otherwise would not be tickled, going against it).
Note I still think smartd is of questionable value too, esp. as long as any messages which it sends out only end up in the journal and are note pushed to the user inside the UI in some way. As for the argument that it sends email if local email delivery is setup, well we don't set that up OOTB and this is about OOTB configuraiton, someone who can setup local email can also do a "dnf install smartd".
So given that I got a couple of "go for it" reactions and that I was already toying with the idea anyways I might actually try to make such a spin happen.
The biggest problem for doing such a spin is finding the time for it...
Are there any people who would be interested in working on / co-maintaining such a spin with me ?
I am interested in it happening but can't sign up for more stuff. :)
I know the feeling.
It seems like this kind of parallels the Minimization objective (which focuses on package dependencies). That's kind of mothballed right now (I think because Adam is working on RHEL 9 stuff?) and I wouldn't want to overload that more, but maybe there's some kind of useful connection?
This is more about runtime overhead, where as the Minimization objective focuses more on pure disk-space consumption. Sure, there is some overlap but not much.
Regards,
Hans
Hans de Goede wrote:
But for MCE exceptions, specifically ECC errors I would expect the kernel to log these through dmesg anyways and then the mcelog service has very little added value IMHO (I have no experience with machines with ECC RAM).
Esp. given that ECC RAM is something which most Fedora Workstation users won't have, so having this included / enabled by default feels wrong IMHO.
Well, to get x86-64 with ECC you need to choose AMD, or else an Intel processor marketed for big hefty servers, but MCE catches more errors than just memory bit errors. Do the ECC-less Intel processors also lack all other MCE support?
On my ECC-capable Ryzen workstation, mcelog is not started because /sys/module/edac_mce_amd/initstate exists. Apparently the daemon is considered unnecessary when this kernel module is active. On the other hand there's a kernel thread called "edac-poller", so I don't know whether the runtime overhead is any lower.
Björn Persson
On Sun, Mar 7, 2021 at 11:28 am, Björn Persson Bjorn@xn--rombobjrn-67a.se wrote:
Do the ECC-less Intel processors also lack all other MCE support?
No, ABRT used to regularly warn me about thermal events from MCE when I didn't have a good enough CPU fan. That was an Intel machine. I fixed it by replacing the CPU cooler. Thanks, ABRT and MCE.
I think I saw some bug fly by several years ago that ABRT's MCE support had broken. Dunno if it still works or not. But it used to work.
Michael
On Sun, 2021-03-07 at 08:55 -0600, Michael Catanzaro wrote:
On Sun, Mar 7, 2021 at 11:28 am, Björn Persson Bjorn@xn--rombobjrn-67a.se wrote:
Do the ECC-less Intel processors also lack all other MCE support?
No, ABRT used to regularly warn me about thermal events from MCE when I didn't have a good enough CPU fan. That was an Intel machine. I fixed it by replacing the CPU cooler. Thanks, ABRT and MCE.
It suppose it was useful to you. But on most laptops, these MCE thermal events are expected and not actionable to users. Indeed, in Linux 5.4 the messages were lowered in severity and for the most part filtered out for this reason (see commits 9c3bafaa1fd8 and f6656208f04e).
Benjamin
I think I saw some bug fly by several years ago that ABRT's MCE support had broken. Dunno if it still works or not. But it used to work.
Michael
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, Mar 07, 2021 at 10:00:56AM +0100, Hans de Goede wrote:
Hi,
On 3/5/21 4:17 PM, Matthew Miller wrote:
On Fri, Mar 05, 2021 at 03:05:00PM +0100, Hans de Goede wrote:
mcelog.service loaded active running Machine Check Exception Logging Daemon
This is another one for which it is questionable to have it running, or is this a machine with ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it just logs some stuff into syslog (where normal users won't see it).
I disagree that those logs are useless -- I often help normal users, and running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course.
But for MCE exceptions, specifically ECC errors I would expect the kernel to log these through dmesg anyways and then the mcelog service has very little added value IMHO (I have no experience with machines with ECC RAM).
It seems mce events can also be generated by the CPU. From the man page:
data corruption detected in the CPU caches, in main memory by an integrated memory controller, data transfer errors on the front side bus or CPU interconnect or other internal errors.
...
When an uncorrected machine check error happens that the kernel cannot recover from then it will usually panic the system. In this case when there was a warm reset after the panic mcelog should pick up the machine check errors after reboot.
It seems like it could be useful even without ECC…
smartd at least has the fact that if it does not run nothing else is asking the disk for its smart reports going for it (and that it may tickle bugs in some disks, which otherwise would not be tickled, going against it).
Note I still think smartd is of questionable value too, esp. as long as any messages which it sends out only end up in the journal and are note pushed to the user inside the UI in some way. As for the argument that it sends email if local email delivery is setup, well we don't set that up OOTB and this is about OOTB configuraiton, someone who can setup local email can also do a "dnf install smartd".
I think it's useful to have hardware errors logged, even if nobody immediately looks at them. If a laptop gets broken, and a more knowledgeable persons is asked to look at it and there are hardware errors in the log, be it from mce or smart, that is a very effective way to diagnose the issue and save a few hours wasted on trying to figure out an elusive bug.
(This also applies to logs attached in bugzilla: especially when we had the service watchdog enabled, people would regularly report services "hanging". It seems many of those were caused by disk issues, and it's nice to have smartd in there.)
In summary: in both cases, I think keeping mcelog and smartd (and other similar things) enabled by default is still useful. We should just make sure they quickly and quietly exit if not applicable on given hardware.
Zbyszek
So given that I got a couple of "go for it" reactions and that I was already toying with the idea anyways I might actually try to make such a spin happen.
The biggest problem for doing such a spin is finding the time for it...
Are there any people who would be interested in working on / co-maintaining such a spin with me ?
I am interested in it happening but can't sign up for more stuff. :)
I know the feeling.
It seems like this kind of parallels the Minimization objective (which focuses on package dependencies). That's kind of mothballed right now (I think because Adam is working on RHEL 9 stuff?) and I wouldn't want to overload that more, but maybe there's some kind of useful connection?
This is more about runtime overhead, where as the Minimization objective focuses more on pure disk-space consumption. Sure, there is some overlap but not much.
Regards,
Hans _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, Mar 07, 2021 at 10:00:56AM +0100, Hans de Goede wrote:
running commands to look back in the logs for problems is a common diagnostic step. This could be better, of course.
But for MCE exceptions, specifically ECC errors I would expect the kernel to log these through dmesg anyways and then the mcelog service has very little added value IMHO (I have no experience with machines with ECC RAM).
I think it's actually needed to properly log the errors coming from the kernel. However, I see from the docs https://github.com/andikleen/mcelog that it has a "trigger" mode, where the kernel calls it on an error. Upstream doesn't recommend it because it doesn't enable some fancier features, but maybe that would be a better default for desktop
Esp. given that ECC RAM is something which most Fedora Workstation users won't have, so having this included / enabled by default feels wrong IMHO.
It's my understanding that it also handles other CPU errors and -- probably very relevant to many Fedora Workstation users -- thermal CPU throttling events.
On Fri, Mar 05, 2021 at 12:56:57PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
I think there's still plenty of stuff to improve that will apply everywhere. homed, alsactl, geoclue, colord just shouldn't need to be there all the time.
firewalld, too. For most users it's just putting a static configuration into place once. A little more complicated with virtual machine networking (possibly container stuff too) but even then it's not something that really needs to be always on.
On 3/4/21 5:11 PM, Hans de Goede wrote:
Hi,
On 3/4/21 11:50 AM, Pavel Březina wrote:
On 3/3/21 6:11 PM, Hans de Goede wrote:
Hi,
On 3/2/21 5:20 PM, Pavel Březina wrote:
On 3/2/21 4:25 PM, Ray Strode wrote:
Hi,
Ahh, okay.
On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede hdegoede@redhat.com wrote:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
minimal profile does not support fingerprint
So it seems there are 4 profiles:
[hans@x1 ~]$ authselect list
- minimal Local users only for minimal installations
- nis Enable NIS for system authentication
- sssd Enable SSSD for system authentication (also for local users only)
- winbind Enable winbind for system authentication
What I want is a profile which uses just the good old /etc files to avoid the overhead of running a local daemon (sssd tends to show up as one of the top 10 wakeup sources in powertop on an idle system) and I also don't want a config which tries to go out on the network.
So minimal seems to meet my needs; and although I personally do not have much of a need for fingerprint auth, I don't really see why we could not do fingerprint auth with the minimal config. I'm pretty
I'd say the answer is simple - if you go with minimal, you don't need fingerprint. And you wrote it yourself - you don't need fingerprint auth. Just because something can be done, does not mean it is worth to maintain it. More info below.
sure I can manually create a pam-config where this works just fine.
I guess its in the name minimal, where as "local" might be (1) a better
That's the point - it's minimal not local, not without-sssd. The readme explicitly says that it reserved for cases when you really care about disk and memory footprint.
It has very limited functionality by design. If you do not want to use SSSD, you can keep using sssd profile and just disable the service. It will keep working. The minimal profile is there for users that also want to remove sssd packages to safe resources, but in that case you probably don't care about fingerprint and smartcards either.
The problem is that IMHO having sssd enabled by default is really the wrong thing to do for like 95% of our users and defaults should be the settings which are best for most / almost all users.
This is really just a symptom of a much bigger problem though, which is that we simply have way too much services / daemon's starting up by default. The output of "ps aux" after a default Fedora workstation install is just way way too long. Once upon a time Linux users used to make fun of Windows with all its background processes in the mean time a default Fedora WS install has gotten worse then Windows wrt background processes. Any of these are totally unnecessary for most of our users.
We really should be smarter here and the config tools which allows a user to enroll in an authentication domain enable the sssd config when that happens and not have this on by default for everyone.
So what I would really like to see is a local profile which uses just /etc files + fprintd if there are fingerprints enrolled. Smartcards are a different story, because those likely also need significant extra setup.
Where as fingerprints can easily be enrolled from the local UI tools.
name. Note I'm not suggesting to add another profile just for this but it would be nice if fingerprint auth would at least be a (default off) feature for the minimal config.
Shall I file a RFE issue for this at: https://github.com/authselect/authselect/issues/
If you need fingerprint auth then open the ticket please - but no promises here. If you don't need it then just don't open the ticket :-)
Rather then opening a ticket, what I would really like to see is a good discussion about why the sssd profile is the default, because IMHO it is a bad default for most users.
I hear you. From authselect perspective, SSSD was enabled by default through a change page that was accepted by community. Therefore authselect is advertising this profile as the main and only. If you want to run without sssd, you can disable the service but you don't have to switch to other profile.
Whether or not it should be enabled by default is a different discussion. But... The SSSD team does acknowledge that it does not have to be enabled by default for vast majority of Fedora users and we plan to submit a change page that will address this. However, I am not going to dive into details in this thread yet, since they are still developing,
Regards,
Hans _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
On 3/5/21 11:59 AM, Pavel Březina wrote:
On 3/4/21 5:11 PM, Hans de Goede wrote:
Hi,
On 3/4/21 11:50 AM, Pavel Březina wrote:
On 3/3/21 6:11 PM, Hans de Goede wrote:
Hi,
On 3/2/21 5:20 PM, Pavel Březina wrote:
On 3/2/21 4:25 PM, Ray Strode wrote:
Hi,
Ahh, okay.
On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede hdegoede@redhat.com wrote: > sudo authselect select minimal > sudo authselect apply-changes > > Which results in the following /etc/pam.d/fingerprint-auth file: > > [hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth > # Generated by authselect on Tue Mar 2 15:24:53 2021 > # Do not modify this file manually.
minimal profile does not support fingerprint
So it seems there are 4 profiles:
[hans@x1 ~]$ authselect list
- minimal Local users only for minimal installations
- nis Enable NIS for system authentication
- sssd Enable SSSD for system authentication (also for local users only)
- winbind Enable winbind for system authentication
What I want is a profile which uses just the good old /etc files to avoid the overhead of running a local daemon (sssd tends to show up as one of the top 10 wakeup sources in powertop on an idle system) and I also don't want a config which tries to go out on the network.
So minimal seems to meet my needs; and although I personally do not have much of a need for fingerprint auth, I don't really see why we could not do fingerprint auth with the minimal config. I'm pretty
I'd say the answer is simple - if you go with minimal, you don't need fingerprint. And you wrote it yourself - you don't need fingerprint auth. Just because something can be done, does not mean it is worth to maintain it. More info below.
sure I can manually create a pam-config where this works just fine.
I guess its in the name minimal, where as "local" might be (1) a better
That's the point - it's minimal not local, not without-sssd. The readme explicitly says that it reserved for cases when you really care about disk and memory footprint.
It has very limited functionality by design. If you do not want to use SSSD, you can keep using sssd profile and just disable the service. It will keep working. The minimal profile is there for users that also want to remove sssd packages to safe resources, but in that case you probably don't care about fingerprint and smartcards either.
The problem is that IMHO having sssd enabled by default is really the wrong thing to do for like 95% of our users and defaults should be the settings which are best for most / almost all users.
This is really just a symptom of a much bigger problem though, which is that we simply have way too much services / daemon's starting up by default. The output of "ps aux" after a default Fedora workstation install is just way way too long. Once upon a time Linux users used to make fun of Windows with all its background processes in the mean time a default Fedora WS install has gotten worse then Windows wrt background processes. Any of these are totally unnecessary for most of our users.
We really should be smarter here and the config tools which allows a user to enroll in an authentication domain enable the sssd config when that happens and not have this on by default for everyone.
So what I would really like to see is a local profile which uses just /etc files + fprintd if there are fingerprints enrolled. Smartcards are a different story, because those likely also need significant extra setup.
Where as fingerprints can easily be enrolled from the local UI tools.
name. Note I'm not suggesting to add another profile just for this but it would be nice if fingerprint auth would at least be a (default off) feature for the minimal config.
Shall I file a RFE issue for this at: https://github.com/authselect/authselect/issues/
If you need fingerprint auth then open the ticket please - but no promises here. If you don't need it then just don't open the ticket :-)
Rather then opening a ticket, what I would really like to see is a good discussion about why the sssd profile is the default, because IMHO it is a bad default for most users.
I hear you. From authselect perspective, SSSD was enabled by default through a change page that was accepted by community. Therefore authselect is advertising this profile as the main and only. If you want to run without sssd, you can disable the service but you don't have to switch to other profile.
Whether or not it should be enabled by default is a different discussion. But... The SSSD team does acknowledge that it does not have to be enabled by default for vast majority of Fedora users and we plan to submit a change page that will address this. However, I am not going to dive into details in this thread yet, since they are still developing,
Oh, that sounds interesting / sounds like a good development. I'll patiently await the change page for this.
Regards,
Hans
Hi,
On Tue, 2021-03-02 at 15:31 +0100, Hans de Goede wrote:
On 3/1/21 9:15 PM, Ray Strode wrote:
[...]
Any debugging options which I can enable somewhere to show the pam_fprintd error ?
you can put "debug" on the ends of the lines that say pam_fprintd.so in /etc/pam.d/fingerprint-auth that should make the journal more chatty.
Ah, I think now we are getting somewhere. I have a script which I run to tweak new / upgraded installs to lower the amount of services which are running be default (mostly because of the 1G/2G RAM x86 Windows tablets which I try to support as a side project). This script contains the following:
sudo authselect select minimal sudo authselect apply-changes
Which results in the following /etc/pam.d/fingerprint-auth file:
[hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth # Generated by authselect on Tue Mar 2 15:24:53 2021 # Do not modify this file manually.
So, an empty file means that we will hit the /etc/pam.d/other fallback, which does "auth required pam_deny.so". This means, the GDM stack that includes it using "substack" will fail with PAM_AUTH_ERR.
This does not seem very helpful. For GDM, it would make more sense to return an error code that allows us to know that it isn't a normal authentication failure. If we instead change it so that the file is not empty, but rather contains:
auth required pam_debug.so auth=authinfo_unavail
Then everything would work as expected. Plus, we may be able to drop the requirement to update the GDM configuration in the long term.
Pavel, would it be possible to make this (or a similar) change in authselect, so that the stack returns a saner error when it is empty?
Benjamin
PS: Thanks to Ray and Marco for the IRC discussions to figure this out more.
I'll add that I just hit this today on an old laptop running rawhide. I didn't spend much time debugging the problem, but I did not see any obvious errors being reported in the journal and simply disabling fprintd did not resolve the issue with gdm. Masking fprintd, as Hans noted, is the big hammer workaround.
devel@lists.stg.fedoraproject.org
-
Benjamin Berg -
Björn Persson -
Chris Murphy -
Hans de Goede -
Matthew Miller -
Michael Catanzaro -
Pavel Březina -
Ray Strode -
Stephen John Smoogen -
Tom Seewald -
Tomasz Torcz -
W. Michael Petullo -
Zbigniew Jędrzejewski-Szmek