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