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

[Jan Kurik]

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

Change owner(s):
* Pavel Březina <pbrezina AT redhat DOT com>


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.


== Detailed Description ==
Authselect allows the administrator to choose one of the supported
profiles. A profile provides description of how the resulting pam and
nsswitch configuration looks like. 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.

The authentication and identity configuration is hardcoded within the
profile. However each profile is also allowed to contain some
conditional modules that can be either enabled or disabled to allow
the administrator to enable some optional behaviour such as account
locking or ecryptfs support.

Authselect does not configure daemons that provide the selected
identity and authentication services such as SSSD or winbind, it only
configures PAM and nsswitch. Daemons must be configured manually or
through other system tools like realmd or ipa-client-install that are
better suited for this task.

The default profile set contains the following profiles:
* Local users + SSSD -- local users and remote users are handled by sssd
  * With optional smartcard or fingerprint authentication
* Local users + winbind -- local users are handled by files and remote
users by winbind
  * With optional fingerprint authentication

There is no need for a separate local users profile without SSSD
because the SSSD module is not called for local users and it also
gracefully detect when the daemon is not running.

Since authselect is very different from the authconfig, we will
provide a compatibility tool that will mimic most but not all options
of authconfig and translate those operations into an authselect call
and configuration changes so we do not break users scripts.


== Scope ==
* Proposal owners:
Authselect is already ready and shipped with Fedora. Owners will
provide compatibility tool to help with the transition.

* Other developers:
anaconda-core, fprintd-pam, freeipa-client and realmd are packages
that depends on authconfig. We will coordinate efforts to either
switch those packages to authselect or make sure that the
compatibility tool is sufficient to cover their needs.

* Release engineering:
#7241: https://pagure.io/releng/issue/7241

* List of deliverables: all

* Policies and guidelines:
The policies and guidelines do not need to be updated.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[John Florian]

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

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.

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.

[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-pro...

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

[John Florian]

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.

[Jason L Tibbitts III]

> >>>> "JF" == John Florian
> <john(a)doubledog.org&gt; writes: 
JF> One last thought, how friendly is this going to be with tools like
JF> puppet and ansible?

Well it has to be friendlier than authconfig, because generally
authconfig isn't and can't be made idempotent.  It will randomly reorder
things you pass to it on the command line, so most of the time it
changes the output when it doesn't need to do so.

It would certainly be nice if authconfig would indicate somehow whether
it made changes, and actually change nothing at all unless it needs to
do so, but to me it's more important that it provides consistent output.

 - J<

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

[Tom Hughes]

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-pro...
>  
Well /usr/share/authselect/custom is not really the correct location
for local administrator configuration...

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[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-pro...
>
>
>  Well /usr/share/authselect/custom is not really the correct location
>  for local administrator configuration... 
What location do you suggest?

>  Tom
>

[Tom Hughes]

On 08/01/18 10:02, Pavel Březina wrote:
>  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-pro...
>
> >>
> >
> >
> > Well /usr/share/authselect/custom is not really the correct location
> > for local administrator configuration...
>  
>  What location do you suggest? 
Well somewhere in /etc in short.

I mean /usr/share/authselect/custom is fine for local customisation via 
building your own rpms but not for on the fly changes.

Really nobody should ever be changing anything in /usr (excluding 
/usr/local) except via package installation/update/removal.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

----- Mail original -----
De: "Tom Hughes" 
> > Well /usr/share/authselect/custom is not really the correct
> location
> > for local administrator configuration...
>  
>  What location do you suggest? 
>  Well somewhere in /etc in short. 
Like other such packages it needs a hierarchy with default templates in /usr/share and
local updates in /etc

Regards,

-- 
Nicolas Mailhot

[Zbigniew Jędrzejewski-Szmek]

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.

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.

Zbyszek

[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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
>

[Zbigniew Jędrzejewski-Szmek]

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

Zbyszek

[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_Directori...
Thank you for the info. I created upstream ticket to track this change:
https://github.com/pbrezina/authselect/issues/28

[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 <pbrezina AT redhat DOT com>
>
>
>  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/sss...

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.