Re: 'guix system vm' questions

[myglc2 <myglc2@gmail.com>]

ludo@gnu.org (Ludovic Courtès) writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> Leo Famulari <leo@famulari.name> writes:
>>
>>> On Wed, Jun 29, 2016 at 10:10:35AM -0400, Thompson, David wrote:
>>>> On Wed, Jun 29, 2016 at 2:57 AM, myglc2 <myglc2@gmail.com> wrote:
>>>> > I have a headless server running Guix/Debian 8.3 on which I would like
>>>> > to run some guix vms. So far, I have a script (see mkvm.sh, attached)
>>>> > that runs a single vm. It has some issues:
>>>> >
>>>> > 1) lsh-service hangs waiting for keystrokes on the QEMU console
>>>> 
>>>> LSH needs to be initialized with a key on first boot, which is why you
>>>> need to type to create entropy.  This sucks for automation, so I would
>>>> recommend OpenSSH instead, but we don't have an openssh-service yet.
>>>
>>> In your operating system configuration, you can pass 'initialize? #f' to
>>> lsh-service to skip the SSH seed and host-key initialization. You will
>>> need to initialize the LSH service later, before you can use it.
>>
>> I tried that and ... lsh spun looking for a seed file advising me to run
>> 'lsh-make-seed', and then stopped.
>
> Yeah this is expected: lshd won’t start if it cannot find a seed;
> eventually, the Shepherd…
>
>> Service SSH-daemeon has started.
>> No seed file. Please create on by running 
>> lwh-make-seed -o "/var/spool/lsh/yarrow-seed-file".
>> lshd: No rendomness generator available.
>> Service ssh-daemon has been disabled.
>>   (Respawning too fast.)
>
> … disables it.
>
>> v1 login: root
>> root@v1 ~# lsh-make-seed 
>> -bash: lsh-make-seed: command not found
>
> I guess ‘lsh-service-type’ should be changed to extend
> ‘profile-service-type’ such that this command is available.  WDYT?

Well I can't see how it will help in my use case. I can't think of why
it would be useful in practice, since lsh-make-seed is already being
called with --sloppy by 'ssh-service initialize? #t'.

The only reasons I can think of are ...

- to enable a user at the console to manually reproduce what
   'ssh-service initialize? #t' does, and

- to avoid it being reported as a bug

... which is why I didn't report it as a bug.

Re my use case, am I correct in believing that the only way to address
it is to enhance lsh-service with an alternative initialization scheme
that does not require console input?

If so, maybe we should rename the current initialize to ...

INITIALIZE-REQUIRING-CONSOLE-INPUT?

... and add a new one named ...

INITIALIZE-UNATTENDED?

WDYT? - George