[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26099: [PATCH] services: Add inetd-service-type.

From: Ludovic Courtès
Subject: bug#26099: [PATCH] services: Add inetd-service-type.
Date: Thu, 23 Mar 2017 23:07:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hi Thomas!

Thomas Danckaert <address@hidden> skribis:

>  - added an <inetd-configuration> type, which consists of a list and
>    an optional "program" field, a file-like expression, default to
>    (file-append inetutils "libexec/inetd").  I did it like this
>    instead of adding a package field, because some packages put the
>    inetd executable in a ".../bin" directory, others use ”.../sbin",
>    en inetutils uses ".../libexec".

Good idea.

> Some questions:
>  - AFAIU, there is currently no easy way to extend /etc/services with
>    custom services in the os configuration?  Should we provide
>    something like "sudoers-file" for services?

To me /etc/services is supposed to be immutable.  However, if there’s a
need to add entries there, we should do something about it, but that’s
probably orthogonal to this patch (we could make ‘etc-service-type’ more
cutomizable to begin with, something I promised to Alex Kost long ago!).

>  - Does it make sense to provide more defaults in the inetd-entry?
>    e.g. make user default to "root", make "nowait" the default, set a
>    default socket type and protocol?  I've always used inetd for a
>    very specific purpose, and have no idea what is the typical way
>    people use it.

It’s probably fine this way.

>  - Should we provide configuration settings for all inetd command line
>    arguments?  inetutils' inetd provides --environment, --pidfile,
>    --resolve and --rate options.  I think other inetd's have still
>    other arguments, so if we want the service to work with many
>    different inetd implementations, providing the option to specifiy
>    an arbitrary command line in the forkexec-constructor might be
>    good?

I guess we can keep it this way for now maybe?

>  - Other inetd packages might (optionally) have slightly different
>    configuration syntax.  e.g. openbsd-inetd (not packaged for Guix
>    atm) provides some extra configuration options in the "wait" field.
>    Perhaps add an “escape hatch” after all?

I’d be in favor of keeping it this way for now and see what needs to be
done when the need arises.  One thing at a time.  ;-)

> What is the idiomatic way to ensure a socket is closed when it's no
> longer needed?  I looked for something like a “with-open-socket” form,
> but that doesn't seem to exist.  My workaround feels a little clumsy:
>               (let ((dict (socket PF_INET SOCK_STREAM 0))
>                     (addr (make-socket-address AF_INET INADDR_LOOPBACK
> 8628)))
>                 (connect dict addr)
>                 (display "DEFINE Guix\n" dict)
>                 (let ((response (read-line dict)))
>                   (close dict)
>                   response)))

We could do define a ‘with-open-socket’ macro, which would expand to
‘dynamic-wind’, which would close the socket when exiting the dynamic
extent of its body.  But for the tests, it’s OK to keep things simple.

> From cf2a3450e9656bc2749492ddf40f5e35c7a73157 Mon Sep 17 00:00:00 2001
> From: Thomas Danckaert <address@hidden>
> Date: Tue, 14 Mar 2017 18:12:34 +0100
> Subject: [PATCH] services: Add inetd-service-type.
> * gnu/services/networking.scm (<inetd-configuration>, <inetd-entry>): New
> record types.
> (inetd-config-file, inetd-shepherd-service): New procedures.
> (inetd-service-type): New variable.
> * doc/guix.texi (Networking Services): Document it.
> * gnu/tests/networking.scm: New file.
> * gnu/ Add it.


> address@hidden {Scheme variable} inetd-service-type
> +This service runs the inetd daemon.  inetd listens for connections on
(@pxref{inetd invocation,,, inetutils, GNU Inetutils})
Also, @command{inetd}.

> +internet sockets, and can run various server programs to service
> +requests on those sockets.

After the comma, something like: “and lazily starts the specified server
program when a connection is made on one of the listening sockets.”
This emphasizes the “laziness” part, as opposed to what the Shepherd

> +(define %test-inetd
> +  (system-test
> +   (name "inetd")
> +   (description "Connect to a host with an INETD server.")
> +   (value (run-inetd-test))))

Nice test, thanks a lot for taking the time to write it!

OK to push with these changes, thank you!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]