Re: [PATCH] gnu: Add kerberos service.

[Ludovic Courtès]

Hi!

John Darrington <address@hidden> skribis:

> On Fri, Nov 18, 2016 at 11:51:16PM +0100, Ludovic Court??s wrote:
>      Hello!
>      
>      John Darrington <address@hidden> skribis:
>      
>      > * gnu/services/kerberos.scm (krb5-realm, krb5-configuration,
>      > krb5-service-type): New variables.
>      
>      Could you add documentation in guix.texi, along with an example of how
>      to use it?
>
> I can make an attempt to do that.   Kerberos however is a complicated thing
> with a large number of options - not all of which I pretend to understand.
> I think it is better to have something undocumented rather than documented
> wrong.   - and I can give an example of how *I* use it - but that should
> not be regarded as a canonical example of how everyone should use it.

Maybe just give a rough overview in a couple of sentences, then an
example that makes sense to you, and then cross-references to the
upstream manual or documentation.

BTW, is this config file honored by any Kerberos implementation, or just
mit-krb5?

>      I very strongly encourage you to write a system test for this as well.
>      Essentially, it???s just about writing down in a file a test that 
> you???ve
>      already run anyway.  I???m happy to help if needed.  The main ideas are
>      described in
>      <https://www.gnu.org/software/guix/news/guixsd-system-tests.html>.
>      
> You are right.  Tests for things like this are needed.  But we have a chicken
> and egg situation.  We can't really write a test for the client without a 
> server.
> And we can't write a test for the server without a client. ... something has
> to come first.   Of course I could, wait until I have absolutely everything
> done before I commit, but then I a) run the risk of losing everything, if  I
> have a disk crash; and b) rule out all possibility of getting any contribution
> from others.

No you’re right, we can’t delay the contribution endlessly, so we have
to be flexible.  What I want to avoid is simply having big chunks of
code that we don’t really how to use and can’t tell if it works.

>      > +(define-record-type* <krb5-realm>
>      > +  krb5-realm      make-krb5-realm
>      > +  krb5-realm?
>      > +  (name                krb5-realm-name)
>      > +
>      > +  (admin-server        krb5-realm-admin-server)
>      > +  (kdc                 krb5-realm-kdc)
>      > +  (auth-to-local       krb5-realm-auth-to-local (default '()))
>      > +  (auth-to-local-names krb5-realm-auth-to-local-names (default '()))
>      > +  (http-anchors        krb5-realm-http-anchors (default '()))
>      > +  (default-domain      krb5-realm-default-domain (default #f))
>      > +  (kpasswd-server      krb5-realm-kpasswd-server (default #f))
>      > +  (master-kdc          krb5-realm-master-kdc (default #f))
>      > +  (v4-instance-convert krb5-realm-v4-instance-convert (default '()))
>      > +  (v4-realm            krb5-realm-v4-realm (default #f)))
>      
>      I find it helpful to add a one- or two-line comment above stating what
>      this is, and margin comments next to the fields to give an idea of what
>      their type is.
>      
>      Could you try something along these lines?
>
> Again most of the info would be copied from the manpage krb5.conf(5).  I can 
> do that if you think it would be useful.

Just one or two lines, whatever makes sense.

>      > +(define (krb5-etc-service config)
>      > +  (list `("krb5.conf" ,(krb5-configuration-file config))))
>      > +
>      > +
>      > +(define krb5-service-type
>      > +  (service-type (name 'krb5)
>      > +                (extensions
>      > +                 (list (service-extension etc-service-type
>      > +                                          krb5-etc-service)))))
>      
>      So this service doesn???t do anything by itself.  Perhaps it should also
>      create a Shepherd service for the Kerberos daemon, or something like
>      that?
>
> Kerberos is three headed dog.  There is the client, the "key distribution 
> center",
> the admin server, the ticket granting server, and the application server.
> Ooops! that's 5 heads.
>
> But this service is sufficient to get a client machine up and running and 
> ready to
> make requests and receive services from an external KDC and application 
> server.
>
> As you say, once we have a KDC and some simple kerberos enabled service in 
> Guix, then
> we can write some end to end tests.  It would be really great if someone can 
> help with
> those things.  In the meantime, this is a start.

Heh, OK.

So client libraries of Kerberos implementations read that file?  IOW, is
it useful on its own already?

If the answer is “yes”, then it’s obviously OK to commit, and if it’s
client functionality, we cannot write tests yet, so that’s fine.

Thank you,
Ludo’.