Re: Request for testing

[ludo@gnu.org (Ludovic Courtès)]

Hi, Alex,

Thanks for the quick feedback!

Alex Sassmannshausen <alex.sassmannshausen@gmail.com> skribis:

> A couple of notes made whilst using it so far (in no particular order of
> importance):
> - when writing the system configuration, the password field seems to
>   expect the hashed value of the password.  This makes good sense, but
>   it might be worth pointing out in the manual somewhere?
>   (perhaps in 'User Accounts' -> 'user-account' 'password'?)
> - it also took me a while to generate the hashed password (in the end I
>   created the password with 'passwd', and then copied from shadow -> the
>   system configuration file). This is probably not related to Guix.

Actually the ‘password’ field is not really meant to be used under
“normal circumstances”: one should just use the ‘passwd’ command.

Commit eb59595 updates the documentation to clarify that.  Let me know
what you think.

> - after enabling the x-server, the default shortcut to shell points to
>   the wrong location

What do you mean by “shortcut to shell”?  In WindowMaker (which is the
default window manager), there’s an xterm icon in the top-right corner,
and in my experience clicking on it launches xterm.

> (and it seems like the window manager does not respect the user's
> $PATH?).

Do you mean as in <http://bugs.gnu.org/18698> (now fixed), or is it
something else?

> - I have some issues with https security certificates not being used by
>   curl/wget/git etc. This is not just in the guix system, but also in
>   guix on Debian — solution may be simple, but I haven't found it yet
>   (this caused some frustration when trying to guix pull :-) )

Yes, that’s a “known issue.”  The problem goes beyond Guix, I think.
We could package certificates, but which ones?  Where do we take them?
Debian, Mozilla, and others manage their own set of certificates.  I’m
not sure what to do here.

(If/when GNUnet’s GNS comes true, I’m happy to say that X.509
certificates are deprecated...)

> - adding users in the system configuration, and then removing them from
>   the definition does not remove the users from the system. I have no
>   idea whether this is intended or not — just something that struck me.

Yes, it’s intended.  The rationale is that there’s extra state anyway
that needs to be handled manually by the admin (password, home
directory, etc.)

Thank you!

Ludo’.