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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

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.

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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux