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.