bug-guix
[Top][All Lists]
Advanced

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

bug#48974: A possible shepherd bug (it's very minor)


From: Leo Prikler
Subject: bug#48974: A possible shepherd bug (it's very minor)
Date: Sat, 03 Jul 2021 08:41:08 +0200
User-agent: Evolution 3.34.2

Hi,

Am Freitag, den 02.07.2021, 18:57 -0400 schrieb Joshua Branson:
> Leo Prikler <leo.prikler@student.tugraz.at> writes:
> 
> > Am Freitag, den 25.06.2021, 14:06 -0400 schrieb Joshua Branson:
> > > Leo Prikler <leo.prikler@student.tugraz.at> writes:
> > > 
> > > > Hi,
> > > > 
> > > > Am Freitag, den 25.06.2021, 05:31 -0400 schrieb Joshua Branson:
> > > > > Leo Prikler <leo.prikler@student.tugraz.at> writes:
> > > 
> > > Thanks again!  The current code doesn't quite work for me
> > > yet.  I'll
> > > try using match-lambda to define it.  I'll post again when I have
> > > a
> > > free moment.  When i get it working, I'll send a patch to the
> > > manual
> > > via guix-patches and CC you.  Is that ok?  Or would you rather
> > > that
> > > documentation be in the cookbook?
> > Did I make a mistake or does it do the job only in a somewhat
> > inelegant
> > way?  I'm perfectly fine with the latter as I'm not the one using
> > the
> > code :P
> 
> I've got some code now that works!
> 
> #+BEGIN_SRC scheme
> (define (auto-login-to-tty tty user config)
>   (if (string=? tty (mingetty-configuration-tty config))
>         (mingetty-configuration
>          (inherit config)
>          (auto-login user))
Why do you need to inherit the config, when it doesn't change?  Seems
like a pointless allocation to me.
>         (mingetty-configuration
>          (inherit config))))
> 
> ;; allegedly %desktop-services now contains network-manager-
> applet...?  Can I remove that?
Not with modify-services, but there's some filter example in the manual
as well.
> (define %my-desktop-services
>   (modify-services %desktop-services ;;end of remove services
>     (mingetty-service-type config =>
>                            (auto-login-to-tty "3" "joshua" config))))
> 
> #+END_SRC
> 
> > I think the cookbook is a better destination for stuff like this.
> 
> I agree, but we should also probably fix the manual:
> 
> 10.1 Using the Configuration System
> ===================================
> 
> System Services
> 
>    For example, suppose you want to modify ‘guix-daemon’ and Mingetty
> (the console log-in) in the ‘%base-services’ list (*note
> ‘%base-services’: Base Services.).  To do that, you can write the
> following in your operating system declaration:
> 
> 
>      (define %my-services
>        ;; My very own list of services.
>        (modify-services %base-services
>          (guix-service-type config =>
>                             (guix-configuration
>                              (inherit config)
>                              ;; Fetch substitutes from example.org.
>                              (substitute-urls
>                                (list "https://example.org/guix";
>                                      "https://ci.guix.gnu.org";))))
>             ;; it looks like the manual is telling you to set up
>             ;; auto login on ALL ttys.
>          (mingetty-service-type config =>
>                                 (mingetty-configuration
>                                  (inherit config)
>                                  ;; Automatially log in as "guest".
>                                  (auto-login "guest")))))
> 
>      (operating-system
>        ;; ...
>        (services %my-services))
> 
> How about I delete that section in the manual about automatic login
> and
> instead add this to the cookbook?
No.  Read on, the manual clearly states that this affects *all* TTYs. 
Presumably the guest user only has access to su and logout, maybe guix,
but in any case they ought not to have access to anyone's $HOME, not
even their own.

The thing we've coded up here is a more involved process to solve a
particular problem rather than a general demo of what services can do
and thus belongs to the cookbook.

Regards,
Leo






reply via email to

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