Re: EncourageI686LeafRemoval Change: Please make sure it's actually a leaf package

[Pavel Březina]

On 1/15/24 19:55, Colin Walters wrote:



On Mon, Jan 15, 2024, at 8:57 AM, Fabio Valentini wrote:

Hi all,

I've been made aware that there has been a cascade of packages that
dropped i686 support in Rawhide, most of them referencing my
EncourageI686LeafRemoval Change Proposal, but none of which *actually
are* leaf packages:

https://src.fedoraproject.org/rpms/composefs/c/b95af99


This one should be fixed by 
https://src.fedoraproject.org/rpms/composefs/c/c840e7496ad9a0a008903a4cfe5d38c22f49fd54?branch=rawhide


https://src.fedoraproject.org/rpms/xdg-desktop-portal/c/93310f7
https://src.fedoraproject.org/rpms/gdm/c/940885b
https://src.fedoraproject.org/rpms/sssd/c/e0023ec


I went ahead and pushed changes to these 3.


Thank you. SSSD build still failed. I think you need to built it in a 
sidetag or wait until the dependencies get into compose.



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: EncourageI686LeafRemoval Change: Please make sure it's actually a leaf package

[Pavel Březina]

On 1/15/24 14:57, Fabio Valentini wrote:

Hi all,

I've been made aware that there has been a cascade of packages that
dropped i686 support in Rawhide, most of them referencing my
EncourageI686LeafRemoval Change Proposal, but none of which *actually
are* leaf packages:

https://src.fedoraproject.org/rpms/composefs/c/b95af99
https://src.fedoraproject.org/rpms/ostree/c/af0a269 (correctly scoped
to RHEL>=10)
https://src.fedoraproject.org/rpms/flatpak/c/9e4df49 (correctly scoped
to RHEL>=10)
https://src.fedoraproject.org/rpms/xdg-desktop-portal/c/93310f7
https://src.fedoraproject.org/rpms/gdm/c/940885b
https://src.fedoraproject.org/rpms/sssd/c/e0023ec

It looks like at least some of these changes were mistakenly pushed to
Rawhide while they should only apply to ELN / RHEL>=10?

I suspect that these packages dropping i686 support will cause a ton
of build failures during the upcoming mass rebuild.

As the author of the EncourageI686LeafRemoval Change Proposal - please
**DO NOT DO IT THIS WAY**. The Change Proposal was about dropping i686
builds from packages that are **LEAF PACKAGES**, not packages that are
somewhere deep in the distro's dependency tree.

Fabio


Thank you for checking sssd update.

Is there anything I should do to stop 
https://bodhi.fedoraproject.org/updates/FEDORA-2024-287a88fffd from 
landing in stable or is the negative karma enough?


I don't see "Actions" button to revoke it.

Thanks,
Pavel.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bodhi API does not list f39 in pending releases

[Pavel Březina]

On 10/25/23 19:14, Mattia Verga via devel wrote:

Il 25/10/23 12:54, Tomas Hrcka ha scritto:

This looks like a bug in bodhi.


Actually, it was done that way on purpose. The HTML rendered output
shows frozen releases in the same table of pending releases by a hack,
but for API purposes I just let the output being pedantic about the
requested state value.

As wrote in another reply, you could query frozen releases with
`?state=frozen`. If there is need to have a single query returns both
pending and frozen, I suppose we could modify the input argument to
accept a comma separated list of values, like `?state=pending,frozen`.


I think this may be handy, but I don't need it for our case. It is easy 
to just combine the results on our side.


Thank you,
Pavel



Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bodhi API does not list f39 in pending releases

[Pavel Březina]

On 10/25/23 15:17, Clement Verna wrote:
On Wed, 25 Oct 2023 at 12:55, Tomas Hrcka <mailto:thr...@redhat.com>> wrote:


This looks like a bug in bodhi.

the web UI lists correct releases pending and current.

On Wed, Oct 25, 2023 at 11:57 AM Pavel Březina mailto:pbrez...@redhat.com>> wrote:
 >
 > Hi,
 > Fedora 39 stopped showing in pending releases (and is not in current
 > either) when using:
 >
 > curl https://bodhi.fedoraproject.org/releases/?state=pending
<https://bodhi.fedoraproject.org/releases/?state=pending> | jq
 >
 > There is Fedora 39 as flatpak and container, but not with
id_prefix==FEDORA.
 >
 > Is this because it is now in final freeze or is it a bodhi bug?


Yes it's because of the freeze, Fedora 39 is listed in the `frozen` 
state to reflect the current release freeze. `curl 
https://bodhi.fedoraproject.org/releases/?state=frozen 
<https://bodhi.fedoraproject.org/releases/?state=frozen> | jq`.


Thank you, this works.



Maybe other F39 releases (container, flatpaks) should also show as frozen.

 >
 > We rely on this information to automatically pick up fedora
versions for
 > SSSD PR CI.
 >
 > Thanks.
 > Pavel
 > ___
 > devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
 > To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>
 > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
 > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
 > List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org>
 > Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>



-- 
Tomas Hrcka

fas: humaton
libera.CHAT: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org>
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Bodhi API does not list f39 in pending releases

[Pavel Březina]

Hi,
Fedora 39 stopped showing in pending releases (and is not in current 
either) when using:


curl https://bodhi.fedoraproject.org/releases/?state=pending | jq

There is Fedora 39 as flatpak and container, but not with id_prefix==FEDORA.

Is this because it is now in final freeze or is it a bodhi bug?

We rely on this information to automatically pick up fedora versions for 
SSSD PR CI.


Thanks.
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC authselect: mdns or mdns-minimal

[Pavel Březina]

On 8/2/23 17:04, Petr Menšík wrote:
I have created upstream pull request, which makes non-minimal plugins to 
behave like minimal plugins except it tries to find /etc/mdns.allow. If 
that file does not exist, it copies also reverse queries from minimal 
plugin.


Here:
https://github.com/lathiat/nss-mdns/pull/89

On 02. 08. 23 9:15, Zdenek Dohnal wrote:

On 8/1/23 12:41, Petr Menšík wrote:

Hi Zdenek,
the current logic is:
- with-mdns4: mdns4_minimal
- with-mdns6: mdns6_minimal
- with-mdns4 and with-mdns6? mdns_minimal

Ah, I have missed last part, that it uses mdns plugin for both queries.


If I understand your message correctly, you propose to keep this 
logic but use mdns4/mdns6/mdns instead of minimal and drop support 
for minimal completely. Is that right?


Thank,
Pavel

No, not at all. We want minimal variants preferred until nss-mdns is 
changes significantly. Check nss-mdns issue #88 [1].


1. https://github.com/lathiat/nss-mdns/issues/88


Petr, this issue exists only if mdns.allow exists, so if we don't ship 
it as I recommend, we don't hit this issue. The file will be created 
by a user in case he needs to override settings which are against 
standards, where IMO a delay is tolerable. Thus, the issue is nice to 
have and should not block using mdns4/mdns6 variants. What I would 
support is adding a note into README file of nss-mdns, mentioning the 
delay due the mentioned bug - until it is fixed.


So Pavel, I've understood me correctly - use mdns/mdns4/mdns6 instead 
of minimal variants, because they provide the same functionality as 
minimal + possibility to override network misconfigurations. And don't 
use complete 'mdns' by default.
Okay, makes sense, once we include required changes into stable 
releases. I have created bug #2228533 to track this change, which once 
in stable, authselect might switch to non-minimal variants.


IIUC, when 2228533 is resolved, I should switch from mdns[-|4|6]_minimal 
to mdns[-|4|6] and otherwise keep it as is? The order of the modules 
should be also kept:


Current order  is:

hosts: files myhostname libvirt libvirt_guest 
mdns_minimal|mdns4_minimal|mdns6_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] dns


Thanks,
Pavel





But I'm not a nss-mdns or avahi maintainer, just a maintainer of 
stacks which use mdns often - printing and scanning. I've got this 
opinion from issues in past, by checking nss-mdns code and by 
intention of minimizing of new work in authselect, unless it is 
necessary.



Zdenek


Yes, I admit current way of providing different plugins instead of one 
plugin with related configuration is unfortunate. Because it depends on 
avahi-daemon anyway, I hope it can be reduced to single plugin, where 
every customization can be done on side of avahi-daemon. But needs code 
modifications first, so waiting for a volunteer.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC authselect: mdns or mdns-minimal

[Pavel Březina]

On 8/1/23 12:41, Petr Menšík wrote:
No, I am afraid that is not gist of that response. We still want 
mdns4_minimal to be preferred variant and others to be configurable 
manually. Sadly, they are all still needed, with minimal variants 
preferred.


and also --with-mdns should be possible in addition to existing 4 and 6 
variants.


On 01. 08. 23 12:10, Pavel Březina wrote:

On 8/1/23 09:56, Zdenek Dohnal wrote:

Hi Pavel,

since authselect already advertises features for profiles regarding 
mdns as:


--with-mdns4

--with-mdns6

it would be great if the profile feature logically matched what is 
going to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in 
nsswitch.conf instead of current mdns_minimal.


AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and 
mdns_minimal, because hostname->IPv6 + hostname->IPv4 address 
resolutions are currently made in sequence in Avahi, so the getting 
the result will be unnecessary delayed if one of them is not defined.


IIUC nss-mdns README, the main difference between mdns4 and 
mdns4_minimal is /etc/mdns.allow file support, which can allow 
bypassing heuristics and allows user to do mDNS queries in conflict 
to mDNS standard (f.e. standard specifies that only .local or .local. 
domains can be used for mDNS) - although it would be great if 
networks were up to the standards, it is not a case in reality. We 
had this issue https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , 
where ISP injected DNS server which defined 'local' domain as classic 
DNS record, breaking mDNS resolution in whole user's environment. 
Fortunately Petr came up with solution for it (now nss-mdns does 
always mDNS lookup for .local, but if there is DNS SOA for .local and 
mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't 
need mdns.allow anymore, but IMO there could be other divergence from 
standards in the networks, so having the option to use mdns.allow in 
default configuration is welcome.


So what I would propose:

- use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 
profile features instead of _minimal to honor name logic,


- don't use mdns/mdns_minimal - if someone wants to use it, he can 
enable both features separately,


- if someone would like to use mdns4/6_minimal, he can opt-out from 
authselect and update nsswitch.conf manually.


@Adam, @Petr, please let me know if there are other things to 
consider or disadvantages in this.


Hi Zdenek,
the current logic is:
- with-mdns4: mdns4_minimal
- with-mdns6: mdns6_minimal
- with-mdns4 and with-mdns6? mdns_minimal

Where exactly are those variants documented? I have looked into man 
authselect, but failed any word on mdns. How can I check how authselect 
presents them, please? Anything better than command:


$ authselect list-features minimal


You want `authselect show sssd`



If I understand your message correctly, you propose to keep this logic 
but use mdns4/mdns6/mdns instead of minimal and drop support for 
minimal completely. Is that right?


Thank,
Pavel

No, not at all. We want minimal variants preferred until nss-mdns is 
changes significantly. Check nss-mdns issue #88 [1].


1. https://github.com/lathiat/nss-mdns/issues/88


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC authselect: mdns or mdns-minimal

[Pavel Březina]

On 8/1/23 03:46, Adam Williamson wrote:

On Mon, 2023-07-31 at 14:47 +0200, Pavel Březina wrote:

Hi Fedora,
I have this ticket opened against authselect:
https://github.com/authselect/authselect/issues/334

I am not user of mdns myself, so I wonder if non-minimal version of mdns
is something used and if it should be included in the authselect
profiles (or even replace the minimal version).

mdns support is already complicated since there are mdns, mdns4 and
mdns6 full and minimal versions of the module. Is it really required
nowadays? In might opinion, it might be good to move the logic out of
nsswitch into a configuration file.


If mdns is the thing that lets me just do 'ssh somehostname.local' to
reach that host on my local network, then yes, I use it. I have no idea
what configuration it should have, except that that should work OOTB,
IMHO.


By configuration, I meant to choose between minimal and full versions 
and ipv4 and ipv6 via configuration file and have single nss module 
instead of having 6 different modules that you need to choose from in 
nsswitch.conf.


Thanks,
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC authselect: mdns or mdns-minimal

[Pavel Březina]

On 8/1/23 09:56, Zdenek Dohnal wrote:

Hi Pavel,

since authselect already advertises features for profiles regarding mdns 
as:


--with-mdns4

--with-mdns6

it would be great if the profile feature logically matched what is going 
to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in 
nsswitch.conf instead of current mdns_minimal.


AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and 
mdns_minimal, because hostname->IPv6 + hostname->IPv4 address 
resolutions are currently made in sequence in Avahi, so the getting the 
result will be unnecessary delayed if one of them is not defined.


IIUC nss-mdns README, the main difference between mdns4 and 
mdns4_minimal is /etc/mdns.allow file support, which can allow bypassing 
heuristics and allows user to do mDNS queries in conflict to mDNS 
standard (f.e. standard specifies that only .local or .local. domains 
can be used for mDNS) - although it would be great if networks were up 
to the standards, it is not a case in reality. We had this issue 
https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , where ISP injected 
DNS server which defined 'local' domain as classic DNS record, breaking 
mDNS resolution in whole user's environment. Fortunately Petr came up 
with solution for it (now nss-mdns does always mDNS lookup for .local, 
but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves 
to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there 
could be other divergence from standards in the networks, so having the 
option to use mdns.allow in default configuration is welcome.


So what I would propose:

- use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 profile 
features instead of _minimal to honor name logic,


- don't use mdns/mdns_minimal - if someone wants to use it, he can 
enable both features separately,


- if someone would like to use mdns4/6_minimal, he can opt-out from 
authselect and update nsswitch.conf manually.


@Adam, @Petr, please let me know if there are other things to consider 
or disadvantages in this.


Hi Zdenek,
the current logic is:
- with-mdns4: mdns4_minimal
- with-mdns6: mdns6_minimal
- with-mdns4 and with-mdns6? mdns_minimal

If I understand your message correctly, you propose to keep this logic 
but use mdns4/mdns6/mdns instead of minimal and drop support for minimal 
completely. Is that right?


Thank,
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

RFC authselect: mdns or mdns-minimal

[Pavel Březina]

Hi Fedora,
I have this ticket opened against authselect:
https://github.com/authselect/authselect/issues/334

I am not user of mdns myself, so I wonder if non-minimal version of mdns 
is something used and if it should be included in the authselect 
profiles (or even replace the minimal version).


mdns support is already complicated since there are mdns, mdns4 and 
mdns6 full and minimal versions of the module. Is it really required 
nowadays? In might opinion, it might be good to move the logic out of 
nsswitch into a configuration file.


Thank you for your feedback,
Pavel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Pavel Březina]

On 7/17/23 07:39, Jaroslav Mracek wrote:

Hello Pavel,

May I ask you to be more specific what is the problem with including 
references for issues? I am not sure whether your issues are related to 
issues referenced by Fabio or whether you have in mind something else. 
It will help us to prioritize the work.


Hi, I put more details in the fesco ticket: 
https://pagure.io/fesco/issue/3039#comment-864686 I believe these are 
commonly known so I did not open any ticket against dnf5.


As said in the comment, I stopped putting effort into making dnf5 work 
for our use case (which is provisioning of multiple distributions for 
upstream PR CI via ansible), we would certainly hit more issues - or 
unimplemented functionality if you want to sugar coat it - that would 
require workarounds.




On Fri, Jul 14, 2023 at 10:50 AM Pavel Březina <mailto:pbrez...@redhat.com>> wrote:


On 7/13/23 23:59, Fabio Valentini wrote:
 > Hi all,
 >
 > I'm opening this thread to trigger discussion of the roadmap for DNF5
 > in Fedora 39 - whether the switch still looks doable for this
release,
 > or whether it should be reverted for F39 and postponed to F40.

+1 for postponing. We have hit issues preparing CI environment via
ansible and applying workarounds to make dnf5 work is imho not the way
to go with such core tool. It should be there as opt-in so it can get
tested but not default.


DNF5 was released in Fedora 38 where it replaced microdnf, therefore it 
was possible to test it in Fedora 38


Best regards

Jaroslav


 > This is also being tracked in a FESCo ticket:
 > https://pagure.io/fesco/issue/3039
<https://pagure.io/fesco/issue/3039>
 >
 > The DNF5 Change was approved with the condition that bits that are
 > important to the distribution *MUST* work, but this does not seem to
 > be the case yet, six months after this was initially approved -
 > there's at least a few things that are still using dnf-3 or have been
 > broken since the switch to dnf5:
 >
 > - rawhide mock / koji builds still default to dnf-3 (DNF 4)
 > - Fedora CI has been partially broken since the switch to DNF5 (c.f.
 >
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416) 
<https://pagure.io/fedora-ci/general/issue/416)>),
 > making CI results for bodhi updates at least partially useless
 > - fedora-review has been broken since the switch to DNF5 (c.f.
 > [FedoraReview#482](FedoraReview/issue/482)), which is really hurting
 > the rate at which new packages are getting reviewed and added to
 > Fedora
 > - (not an exhaustive list, feel free to mention other things, I will
 > update the list to include them)
 >
 > We are now mere days before the Fedora 39 mass rebuild is
scheduled to
 > start, so I think it's time to start talking about the roadmap for
 > getting missing pieces into place for Fedora 39, or if that is not
 > possible within this timeframe, whether the contingency mechanism
 > should be enacted.
 >
 > Fabio
 > ___
 > devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
 > To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>
 > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
 > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
 > List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org>
 > Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>
___
devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org>
Do

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Pavel Březina]

On 7/13/23 23:59, Fabio Valentini wrote:

Hi all,

I'm opening this thread to trigger discussion of the roadmap for DNF5
in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.


+1 for postponing. We have hit issues preparing CI environment via 
ansible and applying workarounds to make dnf5 work is imho not the way 
to go with such core tool. It should be there as opt-in so it can get 
tested but not default.



This is also being tracked in a FESCo ticket:
https://pagure.io/fesco/issue/3039

The DNF5 Change was approved with the condition that bits that are
important to the distribution *MUST* work, but this does not seem to
be the case yet, six months after this was initially approved -
there's at least a few things that are still using dnf-3 or have been
broken since the switch to dnf5:

- rawhide mock / koji builds still default to dnf-3 (DNF 4)
- Fedora CI has been partially broken since the switch to DNF5 (c.f.
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
making CI results for bodhi updates at least partially useless
- fedora-review has been broken since the switch to DNF5 (c.f.
[FedoraReview#482](FedoraReview/issue/482)), which is really hurting
the rate at which new packages are getting reviewed and added to
Fedora
- (not an exhaustive list, feel free to mention other things, I will
update the list to include them)

We are now mere days before the Fedora 39 mass rebuild is scheduled to
start, so I think it's time to start talking about the roadmap for
getting missing pieces into place for Fedora 39, or if that is not
possible within this timeframe, whether the contingency mechanism
should be enacted.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/20/22 15:15, Vít Ondruch wrote:


Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):

On 1/20/22 12:52, Vít Ondruch wrote:

I have naive question why these files are not static and in /usr.

I mean, I am pretty sure I won't run `authselect select --force` or 
anything similar any time soon. So why the configuration is not 
static, generated at build time, not having anything in /etc unless 
somebody really wants to change something.


The files are not static at all, they are change with different kinds 
of authselect calls:


- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature



As I said, the above is not my case and I'd say not case for most of 
Fedora users.




- apply changes when package is updated: authselect apply-changes



Why is this needed? In which packages? Why simply not apply the changes 
regardless of the previous state?



- apply changes when you modify your custom profile: authselect 
apply-changes



This is again belongs to the initial group.




They remembers how the current configuration looks like so we can 
check if user modified nsswitch and PAM configuration on their own or 
not.



"user modified nsswitch and PAM configuration" is not thing I do. The 
only time I needed to touch nsswitch configuration was always because 
the configuration was screwed up by some updates, not by me.



IOW, from users perspective, the configuration is static. If 
installation/updates changes the configuration, then it is again static 
from user perspective. So I still don't see the need to have the 
configuration files around by default.


Also, I think this proposal is focusing on wrong aspect, i.e. moving 
files around from one location to another. It would be much better to 
remove their need.



Vít


That would be the ideal world, wouldn't it? Especially for me, as 
authselect maintainer :-)


Fedora 36 will move most of the users to authselect and packages won't 
screw the configuration anymore. However, most of the guides on the 
internet on the subject matter don't mention authselect yet so there 
will be cases when users modify the configuration manually without 
disabling authselect even though not intentionally. And again - not 
overwriting user's configuration is important design decision to authselect.


We can of course simplify the detection and not rely on the 
configuration content anymore but perhaps just rely on the presence and 
validity of /etc/authselect/authselect.conf - if it is there, assume 
that user wants to use authselect. I'd would certainly welcome such change.


This however would be a major functional change, so perhaps something to 
consider for the next release.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/20/22 12:52, Vít Ondruch wrote:

I have naive question why these files are not static and in /usr.

I mean, I am pretty sure I won't run `authselect select --force` or 
anything similar any time soon. So why the configuration is not static, 
generated at build time, not having anything in /etc unless somebody 
really wants to change something.


The files are not static at all, they are change with different kinds of 
authselect calls:


- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature
- apply changes when package is updated: authselect apply-changes
- apply changes when you modify your custom profile: authselect 
apply-changes


They remembers how the current configuration looks like so we can check 
if user modified nsswitch and PAM configuration on their own or not.





Vít


Dne 18. 01. 22 v 18:32 Ben Cotton napsal(a):

https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc


== Summary ==

Authselect will move several files that are currently stored at
/var/lib/authselect to /etc/authselect/.state. This does not affect
configuration backup, that will be kept at
/var/lib/authselect/backups.

The files that will be moved are:
* /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
* /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
* /var/lib/authselect/fingerprint-auth 
/etc/authselect/.state/fingerprint-auth

* /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
* /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
* /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
* /var/lib/authselect/smartcard-auth 
/etc/authselect/.state/smartcard-auth

* /var/lib/authselect/system-auth /etc/authselect/.state/system-auth

== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: pbrez...@redhat.com


== Detailed Description ==

These files are used by authselect to detect changes to the system
nsswitch and PAM configurations when the configuration is updated with
an updated profile using 'authselect apply-changes'. There are two
reasons for the move:

1. The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of
ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360
BZ#2034360]

2. Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since
/var should contain only files that can be safely removed, /etc is a
better place for them.

== Feedback ==

This change is accepted by ostree system maintainers, see
[https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360].


== Benefit to Fedora ==
This makes authselect more compatible with ostree model.

== Scope ==
* Proposal owners: Build authselect with
--statedir=/etc/authselect/.state and move files from
/var/lib/authselect to the new location. Spec file changes only.

* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10544 #10544]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A


== Upgrade/compatibility impact ==

No impact. Files will be moved automatically during update and
everything will keep working as prior.

== How To Test ==

1. Authselect keeps working as expected after the upgrade

== User Experience ==

This change is only under the hood, it does not affect user experience.

== Dependencies ==

No dependencies.

== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==

Authselect state files moved from /var/lib/authselect to 
/etc/authselect/.state.





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fed

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/19/22 17:06, Colin Walters wrote:



On Wed, Jan 19, 2022, at 10:25 AM, Neal Gompa wrote:


I agree, I think it should move to /usr/lib/sysimage/authselect instead.


That would break the use case of running it on an image based (i.e. readonly 
/usr) system *client side*.

We settled on having it in /etc in 
https://bugzilla.redhat.com/show_bug.cgi?id=2034360 because that works 
symmetrically across both.  It's also keeps the backups closer to the original 
files (e.g. they're more likely to be on the same file so reflinks could be 
used).  I think these authselect backups are really similar to e.g. 
`.rpmnew/.rpmorig` and similar.


The purpose of these files is to detect user's non-authselect 
modifications of the configuration and prevent overwriting user's 
configuration. In other words, if you choose to modify PAM or nsswitch 
on your own without authselect, then authselect will stop managing the 
files for you unless you tell it to do so again.


The problem with ostree is that /var is read-only on server side and 
/usr is read-only on client side so neither can store these data. /etc 
is writable on both sides.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/19/22 12:40, Petr Pisar wrote:

V Wed, Jan 19, 2022 at 11:55:48AM +0100, Pavel Březina napsal(a):

On 1/19/22 11:35, Petr Pisar wrote:

V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):

On 1/19/22 11:04, Petr Pisar wrote:

V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):

Since /var should contain only files that can be safely removed,


While I agree with your change, this statement is false. /var is for any files
which are variable. Files which can be safely removed belong to /var/tmp and
/var/cache.


Though when removed, the application should remain functional and just
recreate it automatically, right?


Yes.


Authselect would require user intervention.


Yes.


Ok, how about phrasing it:

Removing these files would reduce authselect functionality, user would need
to run 'authselect select --force' to restore it. This however conflicts
with purpose of /var which should contain only data that do not affect
functionality when removed.


That's better, but still not right. /var is not about "functionality when
removed". /var is simply about files which can change (as an opposite to
a change when installing a software). (Compare to
<https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#purpose31>. E.g. if
you delete /var/spool/mail, then a lot of people will say that a functionallity
of their mailboxes is seriously affected.)

I would simply remove the sentence "This however...". Because the truth is
that the conflict is not with the purpose of /var.

If you want reason why /var is not suitable, then simpy admit that /var is
not managed by os-tree and that thus you need a better location which /etc
seems to be because you are moving authconfig's configuration files.


Thank you. This statement about /var was indeed an attempt to justify 
the change outside ostree-enabled systems. But as it seems to be false 
and it created unexpected discussion I rephrased the section to:


"""
These files are used by authselect to detect changes to the system 
nsswitch and PAM configurations when the configuration is updated with 
an updated profile using 'authselect apply-changes'.


Unfortunately, the current location conflicts with ostree model where 
/var is not writable during rpm transaction and this currently blocks 
compose of ostree systems (see BZ#2034360). At the same time /usr is 
read-only on client side of ostree-enabled installations therefore the 
files can not be moved there since it would break authselect on the 
client side.


Storing these files under /etc/authselect will make authselect work on 
both server and client side of ostree systems.

"""



-- Petr


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/19/22 11:35, Petr Pisar wrote:

V Wed, Jan 19, 2022 at 11:30:11AM +0100, Pavel Březina napsal(a):

On 1/19/22 11:04, Petr Pisar wrote:

V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):

Since /var should contain only files that can be safely removed,


While I agree with your change, this statement is false. /var is for any files
which are variable. Files which can be safely removed belong to /var/tmp and
/var/cache.


Though when removed, the application should remain functional and just
recreate it automatically, right?


Yes.


Authselect would require user intervention.


Yes.


Ok, how about phrasing it:

Removing these files would reduce authselect functionality, user would 
need to run 'authselect select --force' to restore it. This however 
conflicts with purpose of /var which should contain only data that do 
not affect functionality when removed.



Thanks,
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/19/22 11:04, Petr Pisar wrote:

V Tue, Jan 18, 2022 at 12:32:52PM -0500, Ben Cotton napsal(a):

Since /var should contain only files that can be safely removed,


While I agree with your change, this statement is false. /var is for any files
which are variable. Files which can be safely removed belong to /var/tmp and
/var/cache.


Though when removed, the application should remain functional and just 
recreate it automatically, right?


Authselect would require user intervention.



-- Petr


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

[Pavel Březina]

On 1/18/22 19:03, Vitaly Zaitsev via devel wrote:

On 18/01/2022 18:32, Ben Cotton wrote:
Authselect state files moved from/var/lib/authselect to 
/etc/authselect/.state.


Why /etc/authselect/.state and not /etc/authselect/state? Dot in front 
of the name means hidden file/directory.


This is the intention, it should not be touched by users therefore it 
should not be visible to users, in my opinion.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: buildroot size growth

[Pavel Březina]

On 1/12/22 16:33, Vít Ondruch wrote:

I have reported this here:

https://bugzilla.redhat.com/show_bug.cgi?id=2039869


Should be fixed now with authselect-1.3.0-7.fc36.




Vít


Dne 05. 01. 22 v 11:30 Zbigniew Jędrzejewski-Szmek napsal(a):

On Tue, Jan 04, 2022 at 12:25:36PM -0800, Adam Williamson wrote:

On Tue, 2022-01-04 at 14:57 +0100, Vít Ondruch wrote:

One of the packages which caught my attention and previously was not
installed is systemd (there always were just systemd-libs). So is
systemd to blame or is it something else?

I think the difference is that authselect is now pulled in. authselect
pulls in authselect-libs, which pulls in systemd, which I think pulls
in the other things.

The reason authselect gets pulled in is that pam now requires it:

https://src.fedoraproject.org/rpms/pam/c/ff21ecd19213fce0570d448831d21f66db6abc2c?branch=rawhide 



that change landed in Rawhide in pam-1.5.2-8.fc36, which was built late
on December 9th, and so likely appeared in the December 10th compose.

This is unfortunate as it most likely affects not just the buildroot but
also other types of minimal installs.

I think the best place to cut this dependency chain would be in 
authselect-libs:

it should not require systemd. What exactly does it need from systemd?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 

Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to transfer file ownership

[Pavel Březina]

On 11/22/21 12:39, Dominik 'Rathann' Mierzejewski wrote:

On Monday, 22 November 2021 at 12:23, Pavel Březina wrote:

Hi fedora-devel,
Fedora 36 change Enforce Authselect Configuration Consistency [1] is going
to transfer file ownership from pam and glibc to authselect package.

I wonder what is the correct way to do that? Is it sufficient to just
remove/add the ownership in spec file %files?

[1] https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory


That and release all three modified packages as a single update.


How do you do that for rawhide?


Perhaps add explict Conflicts: pam < a.b glibc < x.y to authselect to
ensure people don't get file conflicts at installation time.

Why don't you build the trio e.g. in COPR and test?


I already tried, but I was not so far successful to build all of the 
packages due to the file transfers. So that's why I dropped this question.




Regards,
Dominik


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

How to transfer file ownership

[Pavel Březina]

Hi fedora-devel,
Fedora 36 change Enforce Authselect Configuration Consistency [1] is 
going to transfer file ownership from pam and glibc to authselect package.


I wonder what is the correct way to do that? Is it sufficient to just 
remove/add the ownership in spec file %files?


[1] https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: sssd-2.6.0 update in F35 breaks klist/kinit here

[Pavel Březina]

On 10/22/21 16:56, Ankur Sinha wrote:

Hi folks,

I just updated two F35 systems with updates-testing enabled and then
`klist` etc. stopped working for me. Some investigation seems to
indicate that the sssd-2.6.0 update may be involved---downgrading back
to 2.5.2 immediately fixes the issue on both systems. The update
however, has 3+ karma already, so it's on it's way to stable:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-360425682d

Could more folks please test it out to see if it's a package update
related bug? (I've not touched my configs at all as far as I can
remember, so it *shouldn't* be specific to my two machines).

If it's a general issue, it'll break kinit etc. for all package
maintainers as soon as they get the update. (Running `fedpkg
new-sources` was how I ran into the issue).


I've unpushed the package so far, so it won't be pushed to stable. 
Please open a bugzilla with KCM logs attached. Also please, provide 
output of failing klist with krb5 tracing enabled (KRB5_TRACE=/dev/stderr).


Thanks,
Pavel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)

[Pavel Březina]

On 10/14/21 14:57, Michael Catanzaro wrote:

Enforce Authselect Configuration Consistency


This sounds good, I updated the page title. Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)

[Pavel Březina]

On 10/12/21 7:12 PM, Michael Catanzaro wrote:


This change is well-considered and includes detailed reasoning to 
support it. Looks good to me.


I think the change proposal should be renamed, though, since authselect 
would clearly not *actually* be mandatory. Of course you'll risk severe 
breakage if you turn it off and edit these low-level configurations 
directly, but that is really no different than it was before.


Do you have any proposals on the name?

To me, this change means that if you don't use authselect, you are 
basically on your own and I'd like to stress this as much as possible.


But yes, it is still possible to opt-out. However, the package 
maintainers won't (should not) care about non-authselect configuration 
anymore.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)

[Pavel Březina]

On 10/12/21 5:45 PM, Neal Gompa wrote:

On Tue, Oct 12, 2021 at 11:33 AM Ben Cotton  wrote:


=== 1. It is difficult to deliver updates to configurations ===
FIles /etc/nsswitch.conf and /etc/pam.d/* are distributed as
%config(noreplace) which means that they are configuration files and
are only installed if they are not yet present. If they are present
then they are never overwritten with package updates, instead an
*.rpmnew file is created and the update responsibility is left
completely to the user.

It is done this way to prevent overwriting user changes
configurations. But at the same time it means that even configurations
that are not modified by the users can not be changed so we can not
deliver fixes and changes efficiently.

It is only possible through difficult scriptlets. As an example, we
can show this bugzilla where a change in Gnome required an update to
PAM otherwise the user could not authenticate. Delivering the change
was easy with authselect, but difficult for non-authselect systems.

Authselect already knows how the resulting configuration should look
and does not risk overriding user configuration. Making it mandatory
will help distribute important updates to nsswitch and PAM
configuration.



PAM gained support for systemd-style overlay configuration some time
ago. Actually a number of core system components did, if the libeconf
dependency is turned on. Instead of forcing authselect, we should
probably make sure base functional configuration is shipped in
something like /usr/share/pam/pam.d or something like that.


This way, it would be possible to update the *default* configuration. If 
the configuration is modified (e.g. added fingerprint support) the user 
config won't be updted, but still possible with authselect.


Packages would still have to use difficult scriptlets to enable/disable 
their modules. With authselect, they can just call "authselect 
enable-feature with-fingerprint" and fingerprint will be enabled if the 
profile supports it.


Note: imho packages should not do these kind of changes and rather 
explain how to enable modules in documentation, but they are doing it.




Not that I think authselect is bad, but I think it's a bad hammer to
solve this problem.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Authselect Mandatorry (System-Wide Change proposal)

[Pavel Březina]

On 10/13/21 3:17 PM, Michael Catanzaro wrote:
On Wed, Oct 13 2021 at 10:22:14 AM +0200, Hans de Goede 
 wrote:

Making what IMHO is a poor default of always using sssd everywhere
hardcoded even deeper into Fedora seems like a bad idea to me.


I think we can fix this at the same time. Make authselect default to its 
minimal profile rather than its sssd profile, and make realmd 
responsible for running authselect to enable the sssd profile when it is 
required. I think realmd is already capable of installing the 
dependencies it needs when enabled, right? This way, most Fedora systems 
would no longer run sssd, but enabling enterprise login would not 
require manual configuration for those who need it.


Minimal profile is really minimal and does not provide almost any 
flexibility so imho it should not be used as a default. We could however 
create a new profile e.g. "local".


SSSD is default because it was serving local users as well. This in no 
longer true since F35 [1], so there is certainly a possibility to switch 
the default, if the community desires it and it is certainly beneficial 
to do it together with this change.


I don't see a strong reason to change the default profile. Local users 
go through nss_files and pam_unix, if SSSD is not running it does not do 
anything.


That being said, if there is a strong desire to create a non-sssd 
profile for local users only, I will definitely not oppose it. Please, 
create a change page (needs to be system-wide since changes in anaconda 
are required), if accepted I can implement required changes or review a 
pull request.


The reason why I'd like to have separate change for this is that 1) 
"Make authselect mandatory" will use whatever default is chosen 2) 
Either change can be accepted or refused 3) Discussion will be 
restricted to one topic.


Thank you,
Pavel

[1] https://fedoraproject.org/wiki/Changes/FlexibleLocalUserCache



Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Pavel Březina]

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`?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Pavel Březina]

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  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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.or

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Pavel Březina]

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


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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Pavel Březina]

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  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
- minimalLocal users only for minimal installations
- nisEnable NIS for system authentication
- sssd   Enable SSSD for system authentication (also for local users 
only)
- winbindEnable 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





1) Might have been a better name in retrospect, but meh


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Pavel Březina]

On 3/2/21 10:21 PM, Ray Strode wrote:

Hi,

On Tue, Mar 2, 2021, 11:20 AM Pavel Březina  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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Pavel Březina]

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  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: sssd: No %post/%preun/%postun?!?

[Pavel Březina]

On 2/25/21 2:39 PM, Tom Hughes via devel wrote:

On 25/02/2021 13:13, Richard Shaw wrote:

Per the packaging guidelines these don't seem to be optional:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd 
 



Indeed they're not optional, but they're also not missing as a glance
a the spec file confirms:

https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_931

Additionally, at a minimum systemctl daemon-reload should be run. It 
looks like there is some sort of default behavior but it's not correct.


Warning: The unit file, source configuration file or drop-ins of 
sssd-kcm.socket changed on disk. Run 'systemctl daemon-reload' to 
reload units.
Warning: The unit file, source configuration file or drop-ins of 
sssd-kcm.service changed on disk. Run 'systemctl daemon-reload' to 
reload units.


What you are seeing there is RHBZ#1614751 in action.

Looking at my dnf rpm log, this seems to have been going on for quite 
some time and I can't believe I'm the first to notice...


You're not, and after 2.5 years it is finally about to be fixed.


Thank you for the reminder. I opened PR against SSSD upstream:
https://github.com/SSSD/sssd/pull/5522

Once accepted, I will include this change in Fedora spec file.



Tom


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Pavel Březina]

On 11/5/20 1:58 PM, Nico Kadel-Garcia wrote:

On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  wrote:


No, no, NO again.

nscd has no important active bugs in Fedora. I am not sure what bugs are
mentioned, but just a few active bugs are on glibc component in Fedora.
Therefore it seems just fine no commits are good.

Just unlike systemd-resolved, which actively breaks some use cases. It
changes resolution order of search directive in resolv.conf, breaks
DNSSEC, breaks one label names resolution. It is famous among DNS
community [1].


sssd also breaks other LDAP setups, It's extremely broken with larger
LDAP setups because it insists on caching *ALL* of the LDAP, barring
being able to filter to only a smaller set of the LDAP. But because so
many LDAP setups scatter group and user information in so many
distinct parts of the LDAP layout, this never works and it *ALWAYS*
times out in large, remot4e LDAP setups. It works for a few seconds at
start time, then crashes and takes out *all* sssd based services.


SSSD only stores required data, i.e. requested users, groups or whatever 
unless you set enumerate=true which is explicitly stated as "not 
recommended" in SSSD manual pages.



The sophisticated setups available by hand-editing sssd are also
*inevitably* overwritten by any use of the 'authconfig' command, which
is used by various RPM '%post' operations. sssd's configuration


Authconfig used to only override domain named "default" which was 
created by authconfig and it only touched a specific set of options that 
were requested by authconfig arguments. Also users usually don't name 
their domain as "default" so I don't deem this a valid point. 
Furthermore, real authconfig is not around since Fedora 28 and the 
wrapper around authselect touches only a configuration snippet.



options are so poor that they may as well be malicious. It is most
effective in small and unsophisticated network environments. It
suffers from the "systemd" style, sprawling universal management tool
design principles and makes many straightforward operations very
difficult if not impossible.


What kind of operations?

I don't know when it was the last time you tried SSSD or authconfig and 
I know nothing about your environment but these are just hateful 
paragraphs without any kind of evidence. If you have any issue with 
SSSD, feel free to open bug report and we can see what needs to be done 
to make it work for you.



nscd is a lightweight and *far* more stable tool, and should be used
in preference to sssd wherever possible. An indepent LDAP and Kerberos
toolkit is *far* more stable than sssd.


Instead, I request again, split systemd-resolved into subpackage. I want
it removed on my system and so do more people. Also, when I disable it,
I have to fix /etc/resolv.conf by hand. I would think NetworkManager
restart would refresh classic /etc/resolv.conf, like in F32.


That's a separate issue. Maybe start a separate thread about that?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Pavel Březina]

On 9/14/20 12:11 PM, Kamil Paral wrote:
On Fri, Sep 11, 2020 at 7:03 PM Michael Catanzaro > wrote:



 > If it is, what is the proper way to revert back to upstream defaults
 > in this case? Should I append "--force" to the command? (I don't
want
 > to destroy my system, that's why I'm not simply trying it. All of
 > this seems awfully complex and fragile).

Yes, use --force. That tells authselect that it is OK to overwrite your
manual configuration. Otherwise, authselect is careful to not overwrite
files that have been edited manually.


Sigh, authselect is even more complicated than I thought. I can't simply 
do "sudo authselect apply-changes --force". I need to do "sudo 
authselect select $something --force" first, according to the man page. 
And I have no idea what $something is. Can you please provide an exact 
set of commands to run? Thanks.


apply-changes only works if you have valid authselect configuration (no 
manual changes) and you edit /etc/authselect/user-nsswitch.conf or one 
of the selected profile template.


If you need to restore previous configuration you can either use 
backup-restore (if there is any backup, see backup-list) or you can use 
'authselect current --raw' which will print you what authselect command 
line was used.


authselect select `authselect current --raw` --force

The default in Fedora is 'authselect select sssd' with optional 
with-fingerprint and with-mkhomedir.





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to get proper nsswitch.conf?

[Pavel Březina]

On 2/14/20 8:19 PM, Michael Catanzaro wrote:
On Thu, Feb 13, 2020 at 7:13 pm, Michael Catanzaro 
 wrote:

Why don't we have mymachines here?


This is systemd module, right? There was some discussion about it in:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PNKKVG3K6WAU42CCPVIEV6LZY7PWUG4P/#PNKKVG3K6WAU42CCPVIEV6LZY7PWUG4P

I don't really have all the information but apparently there are some 
collisions with LDAP/FreeIPA and is not supposed to be enabled by default.



Next question, I have:

passwd: sss files systemd
shadow: files sss
group: sss files systemd

The difference is that authselect doesn't write the shadow line [1], 
that one is coming from our glibc [2]. (glibc is already patched to 
enable sssd.) That inconsistency seems odd; shouldn't authselect be 
modifying the shadow line as well?


SSSD does not support shadow therefore it is not added by authselect. 
IMHO it should be removed from glibc nsswitch.conf as well.


Then it also doesn't make sense that we put files before sss in half the 
lines, and sss before files in the other half.


Basically only passwd and group needs to have sss consulted first 
because SSSD now handles local users as well and this way will glibc 
first consults SSSD in-memory cache before reading from disk.


It does not matter with the other maps. It makes sense to me to have 
SSSD first because nowadays if you are joined to a remote domain you 
have these maps served by SSSD from LDAP then having the configuration 
in files, at least in enterprise scenarios.


sudoers have files first because there is always /etc/sudoers with at 
least %wheel so it makes sense to read it first.




[1] 
https://github.com/pbrezina/authselect/blob/master/profiles/sssd/nsswitch.conf 

[2] 
https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc-fedora-nsswitch.patch 





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: vagrant can't up rawhide compose

[Pavel Březina]

On 11/6/19 4:23 PM, Vít Ondruch wrote:

Isn't it this issue?

https://bugzilla.redhat.com/show_bug.cgi?id=1759603


Vít


It seems to be something different. I opened:
https://bugzilla.redhat.com/show_bug.cgi?id=1771446





Dne 06. 11. 19 v 14:02 Pavel Březina napsal(a):

I'm trying vagrant image of rawhide from [1], however vagrant is
unable to bring the machine up. It gets always stuck on "==> client:
Waiting for domain to get an IP address..." step. Other vagrant boxes
(Fedora 29 till Fedora 31) from these cloud composes works well.

I tried to upgrade to latest vagrant upstream version (2.2.6) but that
did not helped.

[1]
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/compose/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20191105.n.0.x86_64.vagrant-libvirt.box
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

vagrant can't up rawhide compose

[Pavel Březina]

I'm trying vagrant image of rawhide from [1], however vagrant is unable 
to bring the machine up. It gets always stuck on "==> client: Waiting 
for domain to get an IP address..." step. Other vagrant boxes (Fedora 29 
till Fedora 31) from these cloud composes works well.


I tried to upgrade to latest vagrant upstream version (2.2.6) but that 
did not helped.


[1] 
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/compose/Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20191105.n.0.x86_64.vagrant-libvirt.box

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

authselect: owning configuration files under /etc/authselect

[Pavel Březina]

Hello list,
Igor suggested in authselect pull request that authselect should own 
configuration files in /etc/authselect.


See: https://src.fedoraproject.org/rpms/authselect/pull-request/5

More specifically:
+ %ghost %{_sysconfdir}/authselect/dconf-db
+ %ghost %{_sysconfdir}/authselect/dconf-locks
+ %ghost %{_sysconfdir}/authselect/fingerprint-auth
+ %ghost %{_sysconfdir}/authselect/nsswitch.conf
+ %ghost %{_sysconfdir}/authselect/password-auth
+ %ghost %{_sysconfdir}/authselect/postlogin
+ %ghost %{_sysconfdir}/authselect/smartcard-auth
+ %ghost %{_sysconfdir}/authselect/system-auth
+ %ghost %{_sysconfdir}/authselect/user-nsswitch.conf

This makes perfect sense, however if authselect owns these files and 
admin then uninstalls authselect, the system will be locked out because 
pam configuration was removed.


I do not know any way how to own these files and yet leave them 
untouched after uninstallation, thus I see only two solutions:


1) Do not own these files at all.
2) Remove symlinks to /etc/authselect/* and restore these files to their 
original location (i.e. /etc/nsswitch.conf, /etc/pam.d/*).


Which do you prefer? Is there other way to do this?

Thank you,
Pavel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

On 12/6/18 12:20 PM, Pavel Březina wrote:

Hello,

systemd and nss-mdns packages modifies nsswitch.conf in their %post 
scriptlets which creates conflicts with authselect on systems that are 
configured by authselect. This needs to be solved somehow.


Originally, I wanted to create an authselect command that can be used by 
packages on systems that are configured by authselect and on systems 
that are configured with different ways [1]. But it turned out that 
there are only two packages that touches nsswitch.conf so I do not think 
this is necessary.


I prepared initial design document with multiple solutions that came to 
my mind [2] and I would like to discuss this with the community to see 
what is the correct and desired way to solve this.


Thank you,
Pavel.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4YMQOZCV32272UIGZM45NVJLVZY2UOZH/ 



[2] 
https://fedoraproject.org/wiki/User:Pbrezina/Authselect_and_packages_that_modifies_nsswitch 


Reading the whole discussion here, I think it would be best for the 
moment to make systemd and nss-mdns scriptlets compatible also with 
authselect configuration and let systemd maintainers to get their 
modules in glibc if/when possible. Once it is in glibc default 
nsswitch.conf it will get picked up by authselect.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

On 12/6/18 3:27 PM, Tom Hughes wrote:

On 06/12/2018 14:11, Florian Weimer wrote:

* Tom Hughes:


Based on my experimentation with an F29 live image last week both
nss-systemd and nss-myhostname are in the default configuration.


Not in the file shipped by the glibc package.


Well something that has been installed as part of the live
image has enabled them then...

Tom


systemd scriptlet enabled them in nsswitch.conf.

Additionally, if you have configured your system with authselect, there 
is systemd in all profiles shipped with the package in passwd and 
groups. But modules in hosts are still enabled via systemd scriptlet.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

On 12/6/18 2:36 PM, Lennart Poettering wrote:

On Do, 06.12.18 12:20, Pavel Březina (pbrez...@redhat.com) wrote:


Hello,


Heya!


systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.

Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems that
are configured with different ways [1]. But it turned out that there are
only two packages that touches nsswitch.conf so I do not think this is
necessary.

I prepared initial design document with multiple solutions that came to my
mind [2] and I would like to discuss this with the community to see what is
the correct and desired way to solve this.


nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.

nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.

Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.


Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can 
happen some ID overlaps with FreeIPA/Samba which is undesirable. I would 
say that this must be solves if this module is enabled by default. Was 
there any progress in this area?



Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.

Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

On 12/6/18 1:31 PM, Florian Weimer wrote:

* Pavel Březina:


systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.


Other packagers (notably sssd) have made the required changes by
requesting them form glibc developers.

Would this help to solve the problem here?


If all those packages should be enabled by default, this probably the 
best solution.




Thanks,
Florian


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

Hello,

systemd and nss-mdns packages modifies nsswitch.conf in their %post 
scriptlets which creates conflicts with authselect on systems that are 
configured by authselect. This needs to be solved somehow.


Originally, I wanted to create an authselect command that can be used by 
packages on systems that are configured by authselect and on systems 
that are configured with different ways [1]. But it turned out that 
there are only two packages that touches nsswitch.conf so I do not think 
this is necessary.


I prepared initial design document with multiple solutions that came to 
my mind [2] and I would like to discuss this with the community to see 
what is the correct and desired way to solve this.


Thank you,
Pavel.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4YMQOZCV32272UIGZM45NVJLVZY2UOZH/


[2] 
https://fedoraproject.org/wiki/User:Pbrezina/Authselect_and_packages_that_modifies_nsswitch

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Pavel Březina]

On 11/28/18 11:22 PM, Jan Pokorný wrote:

On 28/11/18 11:48 -0400, Robert Marcano wrote:

There is another thing I found wrong. The backed up nsswitch.conf has these
lines appended (ckey and incomplete aliases line) after the real end of the
original file (aliases: files):

   aliases:files
   ckey:  files

   aliases:fil

I can repeat this bad backup indefinitely:

1) check current nsswitch has no such lines
2) run authselect select --force ...
3) backup at /usr/lib/authselect/backup//nsswitch has the
appended lines


Have observed a similar corruption (with explicitly named backup, but
it's likely of no significance) yesterday with Rawhide, but at that time
it was least of my problems (see dbus-broker [vs. systemd-nspawn] in
a slightly older thread, nsswitch.conf/pam was actually a false start
based on some messages in journal I thought might be related).

Buffer handling bug?


This is a bug. I opened upstream issue:
https://github.com/pbrezina/authselect/issues/123
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Pavel Březina]

On 11/28/18 3:59 PM, Henrique Martins wrote:

My configuration is different, just take as FYI.


... it seems that in Fedora 29 /etc/nssswitch.conf ought
to be a symlink.  This machine has been upgraded from F28
and this is not the case.  AFAIK I have never edited the
file.


It is still a file and not a link on my f29, which has been
dnf-upgraded for I can't remember how many revisions. I did
edit nsswitch.conf and remove all mdns references, as I run
a local DNS server.


Yes, authselect does not overwrite any existing configuration so if you 
just upgrade it was never invoked.





# authselect check


It replies with
   Current configuration is valid.
on my system.


authselect-1.0.2-1.fc29.x86_64
glibc-2.28-20.fc29.x86_64
nss-mdns-0.14.1-2.fc29.x86_64
systemd-libs-239-6.git9f3aed1.fc29.x86_64


I have the same rpms.


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).


I have avahi/bonjour disabled, thus can't check for this.  I
do have a network printer, on socket://.

-- Henrique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Pavel Březina]

On 11/28/18 6:35 PM, Richard W.M. Jones wrote:

On Wed, Nov 28, 2018 at 05:02:17PM +0100, Reindl Harald wrote:



Am 28.11.18 um 15:45 schrieb Florian Weimer:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link, please file a bug against that package.  If they want to take over
/etc/nsswitch.conf, this is negotiable, but it needs coordination with
the glibc package.


and that's why i do "chattr +i /etc/nsswitch.conf" and "chattr +i
/etc/resolv.conf" for year - guys stop mangle around in /etc - this is
admin area and way too often the mdns crap was added unasked or "mysql"
for nss-mysql touched in the past years finding you perfectly working
config in a damned .bak file

everything which touchs /etc at updates is broken by design


Yes I've been doing chattr +i /etc/resolv.conf for a very long time.


Updates to systemd or nss-mdns breaks generated authselect 
configuration, because they rewrite nsswitch.conf. This is something we 
know about and trying to find the best way for both parties to fix it.



However in the case of /etc/nsswitch.conf, changing it (with the
cooperation of glibc of course) to be a symlink seems reasonable.

What I'm (still) missing is what's the actual plan?  What should
things look like?


At this moment, if you install system without any kickstart, anaconda 
invokes authselect (sssd profile, before it did the same thing but with 
authconfig). If you use kickstart you can choose to not call authselect 
and stick with glibc/pam defaults.


So basically, you can choose to use authselect and you can choose not to 
use it. At any time, you can just manually update any file you want to, 
"authselect check" will complain but the only implication is that you 
will be required to use "authselect select $profile --force" to go back 
to authselect configuration.


As I said in the other mail, authselect would like to take ownership of 
nsswitch.conf and pam in the future, but we need to first solve its 
issues so no action was taken in this area yet.





Rich.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Pavel Březina]

On 11/29/18 12:59 PM, Robert Marcano wrote:

On 11/29/18 7:46 AM, Pavel Březina wrote:

On 11/28/18 4:37 PM, Robert Marcano wrote:

On 11/28/18 11:20 AM, Ralf Corsepius wrote:

On 11/28/18 3:45 PM, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never 
edited

the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link,


It's authselect.

# rpm -qV glibc
L  c /etc/nsswitch.conf


# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


My clean F29 installation had no such symbolic link, has to 
"authselect select --force ..." to force the creation of the link.


The non symlinked /etc/nsswitch.conf even had the header:

   # Do not modify this file manually.

   # If you want to make changes to nsswitch.conf please modify
   # /etc/authselect/user-nsswitch.conf and run 'authselect 
apply-changes'.


So, was it generated at some point by authselect and not as symbolic 
link?


Note: Today I got new update for authselect (1.0.2-1.fc29)


Authselect did not take over default nsswitch.conf (that comes from 
glibc) and pam settings (from pam). Installation of authselect package 
it self does not make any changes, you need to invoke the authselect 
command somehow -- anaconda invokes it automatically during 
installation without kickstart.


If you see this comment in nsswitch.conf and yet nsswitch.conf is a 
file, not a symlink to /etc/authselect I suppose you are using some 
sort of snapshot?


The presence of the comments tell me that probably authselect was 
properly called by anaconda as you say, but some other package decided 
to modify nsswitch (The only external repository I have is VS Code).


Will try to test on a new VM reinstalling my current package list in 
order to try to detect what or why.


It was probably systemd or nss-mdns. This is a known issue and I am in 
touch with their maintainers to solve this. Also, see the other thread 
"nsswitch.conf: list of module packages that enables themselves".







___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Pavel Březina]

On 11/28/18 3:52 PM, Tom Hughes wrote:

On 28/11/2018 14:45, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.


That's true but...


If find out which packages replaces our configuration with a symbolic
link, please file a bug against that package.  If they want to take over
/etc/nsswitch.conf, this is negotiable, but it needs coordination with
the glibc package.


...as I understood it under the old authconfig regime the glibc
installed version was overwritten by the authconfig generated version
as part of the install? and I thought authselect was supposed to
have taken over that role.


True. At this point, authselect only replaces authconfig. The difference 
is that authconfig only created symlinks for pam configuration files 
owned by pam (e.g. /etc/pam.d/system-auth -> system-auth-ac), authselect 
also creates symlink for nsswitch.conf owned by glibc for clarity.


It is not done by the package installation, it must be called. Anaconda 
calls it instead of authconfig automatically when there is no kickstart 
provided.


We do have future plans to take over these files completely, but we did 
not start this discussion with neither glibc nor pam since there are 
still things that needs to be solved before this can happen.


Pavel.



Tom


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Pavel Březina]

On 11/28/18 4:37 PM, Robert Marcano wrote:

On 11/28/18 11:20 AM, Ralf Corsepius wrote:

On 11/28/18 3:45 PM, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link,


It's authselect.

# rpm -qV glibc
L  c /etc/nsswitch.conf


# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


My clean F29 installation had no such symbolic link, has to "authselect 
select --force ..." to force the creation of the link.


The non symlinked /etc/nsswitch.conf even had the header:

   # Do not modify this file manually.

   # If you want to make changes to nsswitch.conf please modify
   # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.

So, was it generated at some point by authselect and not as symbolic link?

Note: Today I got new update for authselect (1.0.2-1.fc29)


Authselect did not take over default nsswitch.conf (that comes from 
glibc) and pam settings (from pam). Installation of authselect package 
it self does not make any changes, you need to invoke the authselect 
command somehow -- anaconda invokes it automatically during installation 
without kickstart.


If you see this comment in nsswitch.conf and yet nsswitch.conf is a 
file, not a symlink to /etc/authselect I suppose you are using some sort 
of snapshot?




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: nsswitch.conf: list of module packages that enables themselves

[Pavel Březina]

On 11/26/18 8:24 PM, DJ Delorie wrote:

Pavel B™ezina  writes:

Do you know about any package that installs an nsswitch.conf module and
automatically enables it in /etc/nsswitch.conf? So far I have two
packages - nss-mdns and systemd.


I don't know about enabling, but it's easy to ask the database what
packages provide NSS modules.  Here's a run from my (sorry, old)
system:

$ dnf whatprovides '/usr/lib64/libnss_*'


Thanks, I forgot about this. I went through the list and the only 
modules that writes into nsswitch.conf are systemd and nss-mdns.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: nsswitch.conf: list of module packages that enables themselves

[Pavel Březina]

On 11/27/18 12:48 AM, Ian Kent wrote:

On Mon, 2018-11-26 at 14:38 +0100, Pavel Březina wrote:

On 11/26/18 2:21 PM, Stephen Gallagher wrote:

On Mon, Nov 26, 2018 at 8:16 AM Pavel Březina  wrote:


This e-mail is long so I just put the question here before explanation:

Do you know about any package that installs an nsswitch.conf module and
automatically enables it in /etc/nsswitch.conf? So far I have two
packages - nss-mdns and systemd.

Why?

As you might have noticed, in Fedora 28 we switched from authconfig to
authselect. This brought some adoption issues and feature requests which
we tried hard to resolved, mostly related to nsswitch.conf. Thank you
for all your feedback.

At this point I am aware of only one nsswitch.conf related issue that we
would like to fix. The problem is that when you choose to use authselect
you are no longer allowed to touch /etc/nsswitch.conf (and various file
in /etc/pam.d) manually but you should use authselect and its profiles
instead.

However, this does not work well for small environments (possibly single
user machines) where you want to just change something in nsswitch.conf
and do not want to create custom profile. For this, we introduced
/etc/authselect/user-nsswitch.conf and 'authselect apply-changes'
command to do this the authselect way (of course you are free to not use
authselect and just modify the files manually).

But there are some packages that installs nsswitch modules and
automatically puts them in /etc/nsswitch.conf in %post which conflicts
with authselect. We would like to provide an authselect call for these
packages, that would make sure it does not conflict with authselect [1].

I started working on a design for such feature and I'm trying to obtain
list of all packages that installs nsswitch modules and automatically
enable them in /etc/nsswitch.conf.

So far I was able to find these packages:
- nss-altfiles
- nss_db
- nss-mdns
- nss_nis
- nss-pam-ldapd
- nss_updatedb
- sssd
- systemd

But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do
you know about any other package?

Thank you,
Pavel.

[1] https://github.com/pbrezina/authselect/issues/77



IIRC, doesn't autofs also use nsswitch.conf for configuration?


Yes, but it is not part of glibc. AFAIK it works similar to sudo -
lookup automount line in nsswitch.conf and acts according to its
settings. But it does not have proper support in glibc.


Yes, automount uses the "automount:" line of nsswitch.conf.

It doesn't mess with nsswitch.conf and I'm not willing to
change a file autofs doesn't own, it's the users responsibility
to set the autofs map sources they need.

Umm .. "proper" ... I'll take that to just mean I don't use
the glibc API rather than a criticism of what I chose to do.


Yes, no criticism. It was meant the other way around, that glibc does 
not provide any autofs api. But again, not criticism for glibc either.




Originally I tried to use the glibc API and I even had autofs
specific nsswitch example code but I found I couldn't do what
I needed. When I did this I didn't have time to work through
the glibc API code to work out if it did provide what I needed
so I wrote my own parser.

If I need to change that then I'll need pointers to adequate
glibc nsswitch API documentation as I still don't want to dive
into the glibc code to work out how do this.

Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: nsswitch.conf: list of module packages that enables themselves

[Pavel Březina]

On 11/26/18 2:21 PM, Stephen Gallagher wrote:

On Mon, Nov 26, 2018 at 8:16 AM Pavel Březina  wrote:


This e-mail is long so I just put the question here before explanation:

Do you know about any package that installs an nsswitch.conf module and
automatically enables it in /etc/nsswitch.conf? So far I have two
packages - nss-mdns and systemd.

Why?

As you might have noticed, in Fedora 28 we switched from authconfig to
authselect. This brought some adoption issues and feature requests which
we tried hard to resolved, mostly related to nsswitch.conf. Thank you
for all your feedback.

At this point I am aware of only one nsswitch.conf related issue that we
would like to fix. The problem is that when you choose to use authselect
you are no longer allowed to touch /etc/nsswitch.conf (and various file
in /etc/pam.d) manually but you should use authselect and its profiles
instead.

However, this does not work well for small environments (possibly single
user machines) where you want to just change something in nsswitch.conf
and do not want to create custom profile. For this, we introduced
/etc/authselect/user-nsswitch.conf and 'authselect apply-changes'
command to do this the authselect way (of course you are free to not use
authselect and just modify the files manually).

But there are some packages that installs nsswitch modules and
automatically puts them in /etc/nsswitch.conf in %post which conflicts
with authselect. We would like to provide an authselect call for these
packages, that would make sure it does not conflict with authselect [1].

I started working on a design for such feature and I'm trying to obtain
list of all packages that installs nsswitch modules and automatically
enable them in /etc/nsswitch.conf.

So far I was able to find these packages:
- nss-altfiles
- nss_db
- nss-mdns
- nss_nis
- nss-pam-ldapd
- nss_updatedb
- sssd
- systemd

But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do
you know about any other package?

Thank you,
Pavel.

[1] https://github.com/pbrezina/authselect/issues/77



IIRC, doesn't autofs also use nsswitch.conf for configuration?


Yes, but it is not part of glibc. AFAIK it works similar to sudo - 
lookup automount line in nsswitch.conf and acts according to its 
settings. But it does not have proper support in glibc.



Also CCing Will Woods and James Antill who have been looking at
scriptlets in Fedora in general and may have further information
handy.


Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

nsswitch.conf: list of module packages that enables themselves

[Pavel Březina]

This e-mail is long so I just put the question here before explanation:

Do you know about any package that installs an nsswitch.conf module and 
automatically enables it in /etc/nsswitch.conf? So far I have two 
packages - nss-mdns and systemd.


Why?

As you might have noticed, in Fedora 28 we switched from authconfig to 
authselect. This brought some adoption issues and feature requests which 
we tried hard to resolved, mostly related to nsswitch.conf. Thank you 
for all your feedback.


At this point I am aware of only one nsswitch.conf related issue that we 
would like to fix. The problem is that when you choose to use authselect 
you are no longer allowed to touch /etc/nsswitch.conf (and various file 
in /etc/pam.d) manually but you should use authselect and its profiles 
instead.


However, this does not work well for small environments (possibly single 
user machines) where you want to just change something in nsswitch.conf 
and do not want to create custom profile. For this, we introduced 
/etc/authselect/user-nsswitch.conf and 'authselect apply-changes' 
command to do this the authselect way (of course you are free to not use 
authselect and just modify the files manually).


But there are some packages that installs nsswitch modules and 
automatically puts them in /etc/nsswitch.conf in %post which conflicts 
with authselect. We would like to provide an authselect call for these 
packages, that would make sure it does not conflict with authselect [1].


I started working on a design for such feature and I'm trying to obtain 
list of all packages that installs nsswitch modules and automatically 
enable them in /etc/nsswitch.conf.


So far I was able to find these packages:
- nss-altfiles
- nss_db
- nss-mdns
- nss_nis
- nss-pam-ldapd
- nss_updatedb
- sssd
- systemd

But only two of them (nss-mdns, systemd) touches /etc/nsswitch.conf. Do 
you know about any other package?


Thank you,
Pavel.

[1] https://github.com/pbrezina/authselect/issues/77
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 02:50 PM, Jan Kurik wrote:

= System Wide Change: Make authselect default tool instead of authconfig =
https://fedoraproject.org/wiki/Changes/AuthselectAsDefault

Change owner(s):
* Pavel Březina 


Replace authconfig with authselect and make authselect a default tool
to configure PAM and nsswitch.conf. A compatibility tool will help
with transition period from authconfig to authselect.
Authselect is a tool to select system authentication and identity
sources from a list of supported profiles and it is available to users
since Fedora 27. Authselect is designed to be a replacement for
authconfig but it takes a different approach to configure the system.
Instead of letting the administrator build the pam stack with a tool
(which may potentially end up with a broken configuration), it ships
several tested stacks (profiles) that solve primary supported use
cases and are well tested and supported. At the same time, some
obsolete features of authconfig are not supported by authselect.
Additionally, authselect is written in C and has a small footprint
which allows it to be also part of minimal installations.


I pushed authselect-0.3 to rawhide. Realmd is converted to authselect 
and was pushed as well. Anaconda, fprintd will be available soon and ipa 
changes are still under development, but they all should work now 
through compatibility tool.


There is a new package: authselect-compat, which provides "authconfig". 
It is a python script that provides minimum level of compatibility with 
authconfig. Its purpose it not to reimplement all authconfig features, 
but it translates it to authselect calls and writes few configuration 
files in order to allow authentication. But not all authconfig options 
are supported. It prints a loud deprecation warning. Please, test it.


There is a authselect-migration(7) manual page that will help users with 
the migration process.


As requested on this list, custom profile directory has been moved to 
/etc/authselect/custom. Authselect cli has unified and documented return 
codes so it can be used in users scripts.


I also implemented new template engine, which is not backwards 
compatible but this is acceptable for this release since it is still in 
a testing phase. Now the templates are clear and reads very good, see:

https://raw.githubusercontent.com/pbrezina/authselect/master/profiles/sssd/smartcard-auth

There is now authselect-devel package that allows you to use our API in 
C. We also plan to provide python bindings and ansible module in future 
versions (F29 scope).


We already have one external contributor, I'm happy to see there is 
interest in this project from community.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/09/2018 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Jan 09, 2018 at 04:30:56PM +0100, Pavel Březina wrote:

On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:

= System Wide Change: Make authselect default tool instead of authconfig =
https://fedoraproject.org/wiki/Changes/AuthselectAsDefault


Does this change do anything to reduce the number of files in /etc
that do not contain local configuration? PAM is currently one of the
worst offenders, with /etc/pam.d full of "configuration" files.


No. The files must stay since it would require changes in pam itself
and that is out of scope of authselect. Each file corresponds to
individual pam service and is read when pam_start(service_name, ...)
is called.


Elsewhere in the thread /usr/share/authselect/custom is metioned as
directory for admin config. That's OK-ish, as long as you also allow
a directory in /etc for the same purpose. /usr must be allowed to be
immutable.


Would /usr/local be OK as well?


/usr/local is special. Packages are not allowed to put stuff there [1],
and it is instead an alternate install location that is under the
control of the administrator. It seems reasonable to support
authselect configuration located there.

/usr/share/authselect and /etc/authselect are the two main locations
that should be supported, and /usr/local/share/autselect would be an
additional option.

[1] 
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER


Thank you for the info. I created upstream ticket to track this change:
https://github.com/pbrezina/authselect/issues/28
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:

= System Wide Change: Make authselect default tool instead of authconfig =
https://fedoraproject.org/wiki/Changes/AuthselectAsDefault


Does this change do anything to reduce the number of files in /etc
that do not contain local configuration? PAM is currently one of the
worst offenders, with /etc/pam.d full of "configuration" files.


No. The files must stay since it would require changes in pam itself and 
that is out of scope of authselect. Each file corresponds to individual 
pam service and is read when pam_start(service_name, ...) is called.



Elsewhere in the thread /usr/share/authselect/custom is metioned as
directory for admin config. That's OK-ish, as long as you also allow
a directory in /etc for the same purpose. /usr must be allowed to be
immutable.


Would /usr/local be OK as well?



Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 04:54 PM, Tom Hughes wrote:

On 05/01/18 15:02, Pavel Březina wrote:


Yes, there is a data dir: /usr/share/authselect/
Description of these directories may be seen in the man page,
currently at this upstream link:
https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profiles.5.txt.in.in



Well /usr/share/authselect/custom is not really the correct location
for local administrator configuration...


What location do you suggest?



Tom


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 04:43 PM, John Florian wrote:

On Fri, 2018-01-05 at 16:02 +0100, Pavel Březina wrote:

On 01/05/2018 03:14 PM, John Florian wrote:

On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:

The tool is packaged with a default
profile set that is fully supported. If an administrator has
different
needs they can create a custom profile and make it accessible in
authselect by dropping it in the tool specific directory.


How?  The authselect(8) man page tells me that `authselect show
profile_id` will print info about the profile, but I see nothing of
any
detail.  (Perhaps more could be gleaned with `--trace`, but without
any
apparent dry-run option I'd want a VM to experiment.)


There is also authselect-profiles(5) that explains how profiles
works.
But it is not yet present in current Fedora packages. I will do new
release on Monday.


Ah, that explains a lot.  I did fail to mention this was all from the
perspective of a F27 system.



Looking at the package contents doesn't help much either:

$ rpm -ql authselect
/usr/bin/authselect
/usr/lib/.build-id
/usr/lib/.build-id/b6
/usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e
/usr/share/man/man8/authselect.8.gz

So the built-in profiles are hard-coded into the binary?  I might
have
expected a data dir providing these to serve as examples for making
new
ones.


Yes, there is a data dir: /usr/share/authselect/


Doh!  I see now that's part of authselect-libs, a package I failed to
notice getting installed alongside of authselect itself.


We have put the authselect functionality into a separate library so it 
is better usable by realmd (that can call it directly instead of 
executing cli) and other programs that may be interested. We also plan 
to provide ansible module and probably also python and maybe even dbus 
bindings. But this is out of scope of F28.





Description of these directories may be seen in the man page,
currently
at this upstream link:
https://github.com/pbrezina/authselect/blob/master/src/man/authselect
-profiles.5.txt.in.in


Oh, very nice!


I also didn't see (nor did I even try searching for) any mention of
the
upstream project.

Otherwise, this is a very nice write up.  I'm mostly curious as our
setup uses an openldap directory server for identity and WinAD for
authentication.  realmd doesn't seem to cover (from a very cursory
glance) that arrangement.  So I have an eye out for how to best
leverage these things, if at all.


We had many discussions on this topic while designing and developing
authselect. The resolution was to include only sssd and winbind
profiles
and avoid other use cases and avoid plain ldap and kerberos since
they
can be implemented with sssd. So the use case that you have
mentioned
above (different id and auth providers) can be achieved.


That makes sense and seems like a wise choice.


One last thought, how friendly is this going to be with tools like
puppet and ansible?  For example, would something like this be doable?


It is idempotent so it can be used here as well.



exec { 'authselect select sssd':
  unless => "authselect current | grep -q '^sssd$' && authselect check
| grep -q unmodified"
}

The idea being to only run to make a change if needed to keep change
reports tidy.  I can't quite tell at this point because:

$ sudo authselect current
No existing configuration detected.

In this sense, it would be helpful if authselect(8) had some details
about exit codes.  Also, the "check" command could be more explicit
about what happens with exit codes/output messages when:
  * the config was created by authselect and remains unmodified
  * the config was created by authselect but has since been modified
  * the config hasn't apparently ever been touched by authselect

Maybe another command like "test" command could be ideal for the job if
it did much the same but gave diff output and suitable exit code
indicating spot-on vs. needs-change.


Thank you for your input, we will try to include it soon:
https://github.com/pbrezina/authselect/issues/26


I ask because I'd far prefer to have a well maintained tool like
authselect managing PAM versus self-hacked file replacements based on
old configurations that once may have been correct(ish).  PAM syntax is
a wee bit too arcane and yet immensely critical to go mucking around
haphazardly.


Yes, this is exactly what we aim for.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 03:14 PM, John Florian wrote:

On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:

The tool is packaged with a default
profile set that is fully supported. If an administrator has
different
needs they can create a custom profile and make it accessible in
authselect by dropping it in the tool specific directory.


How?  The authselect(8) man page tells me that `authselect show
profile_id` will print info about the profile, but I see nothing of any
detail.  (Perhaps more could be gleaned with `--trace`, but without any
apparent dry-run option I'd want a VM to experiment.)


There is also authselect-profiles(5) that explains how profiles works. 
But it is not yet present in current Fedora packages. I will do new 
release on Monday.



Looking at the package contents doesn't help much either:

$ rpm -ql authselect
/usr/bin/authselect
/usr/lib/.build-id
/usr/lib/.build-id/b6
/usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e
/usr/share/man/man8/authselect.8.gz

So the built-in profiles are hard-coded into the binary?  I might have
expected a data dir providing these to serve as examples for making new
ones.


Yes, there is a data dir: /usr/share/authselect/
Description of these directories may be seen in the man page, currently 
at this upstream link:

https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profiles.5.txt.in.in


I also didn't see (nor did I even try searching for) any mention of the
upstream project.

Otherwise, this is a very nice write up.  I'm mostly curious as our
setup uses an openldap directory server for identity and WinAD for
authentication.  realmd doesn't seem to cover (from a very cursory
glance) that arrangement.  So I have an eye out for how to best
leverage these things, if at all.


We had many discussions on this topic while designing and developing 
authselect. The resolution was to include only sssd and winbind profiles 
and avoid other use cases and avoid plain ldap and kerberos since they 
can be implemented with sssd. So the use case that you have mentioned 
above (different id and auth providers) can be achieved.


We do not want to touch configurations with authselect. But to avoid 
breaking user scripts, we will configure daemons with the compatibility 
tool to mimic authconfig behavior wherever possible.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org