unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: John Darrington <john@darrington.wattle.id.au>
Cc: guix-devel@gnu.org, John Darrington <jmd@gnu.org>
Subject: Re: [PATCH] gnu: Add kerberos service.
Date: Mon, 21 Nov 2016 09:59:03 +0100	[thread overview]
Message-ID: <87ziktyzs8.fsf@gnu.org> (raw)
In-Reply-To: <20161119065728.GA13099@jocasta.intra> (John Darrington's message of "Sat, 19 Nov 2016 07:57:28 +0100")

Hi!

John Darrington <john@darrington.wattle.id.au> skribis:

> On Fri, Nov 18, 2016 at 11:51:16PM +0100, Ludovic Court??s wrote:
>      Hello!
>      
>      John Darrington <jmd@gnu.org> 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’.

  reply	other threads:[~2016-11-21  8:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-09 19:58 [PATCH] gnu: Add kerberos service John Darrington
2016-11-18 15:23 ` John Darrington
2016-11-18 22:51 ` Ludovic Courtès
2016-11-19  6:57   ` John Darrington
2016-11-21  8:59     ` Ludovic Courtès [this message]
2016-11-22 17:52       ` [PATCH] gnu: Add Kerberos client service John Darrington
2016-11-23 22:01         ` Ludovic Courtès
2016-11-29 18:39           ` John Darrington
2016-11-29 18:39             ` John Darrington
2016-11-30 13:09               ` Ludovic Courtès
2016-11-30 13:44                 ` John Darrington
2016-11-30 13:52                 ` Andy Wingo
2016-12-03 12:27                   ` John Darrington
2016-12-03 15:13                     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ziktyzs8.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=jmd@gnu.org \
    --cc=john@darrington.wattle.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).