Putting a file into system image ~user/ but not on reconfigure

Putting a file into system image ~user/ but not on reconfigure

[Hartmut Goebel]

   Hi,

   sorry for the hard to understand subject.

   I need to put a file into a system image (into ~user) which will not be
   recreated or touched when running "system reconfigure" later, even if
   not existent. So this is  some kind of "one-time service", removing
   itself on first boot.

   Any ideas how to do this?

   (One could imagine some self-destructing script creating the file.
   Anyhow AFAIK this script would be recreated on next "system
   reconfigure". Als leaving some "script was run" marker is a bad option,
   as removing the marker would recreate the file, which is to be
   avoided.)

   Background:

   I aim to create Vagrant boxes (machine templates) based on guix system
   images. This works quite well so far, using image format qcow2, putting
   the image and some simple files at the right place and the
   vagrant-libvirt plugin for running the machine. Using a symlink I can
   even avoid copying the boxes disk image out of the store — vagrant will
   create a copy when creating a machine anyway.

   Now for vagrant being able to log into the machine when starting it
   (and eventually "provision" the machine = execute some commands) boxes
   are expected to include an "insecure ssh key" in
   ~vagrant/.ssh/authorized_keys. Vagrant will replace this key by another
   one when creating a machine. So this behavior is reasonable secure.

   One possible solution I found (not yet tested and tools not yet in
   guix) is to use one of the guestfstools ([1]https://libguestfs.org/) to
   copy the file into the image. Anyhow this would require copying the box
   out of the store to get a writable file.
--
Regards
Hartmut Goebel

| Hartmut Goebel          | [2]h.goebel@crazy-compilers.com               |
| [3]www.crazy-compilers.com | compilers which you thought are impossible |

References

   1. https://libguestfs.org/
   2. mailto:h.goebel@crazy-compilers.com
   3. http://www.crazy-compilers.com/

Re: Putting a file into system image ~user/ but not on reconfigure

[wolf]

[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]

On 2023-08-10 00:11:55 +0200, Hartmut Goebel wrote:
>    Hi,
> 
>    sorry for the hard to understand subject.
> 
>    I need to put a file into a system image (into ~user) which will not be
>    recreated or touched when running "system reconfigure" later, even if
>    not existent. So this is  some kind of "one-time service", removing
>    itself on first boot.
> 
>    Any ideas how to do this?
> 
>    (One could imagine some self-destructing script creating the file.
>    Anyhow AFAIK this script would be recreated on next "system
>    reconfigure". Als leaving some "script was run" marker is a bad option,
>    as removing the marker would recreate the file, which is to be
>    avoided.)

I guess you could have a script that would use the existence of the key itself
as a marker.  In that case you would likely want to recreate it if the marker
(key) got deleted, since the machine would be impossible to get into otherwise.
It would run on every boot, but after the very first one it would not do
anything.

> 
>    Background:
> 
>    I aim to create Vagrant boxes (machine templates) based on guix system
>    images. This works quite well so far, using image format qcow2, putting
>    the image and some simple files at the right place and the
>    vagrant-libvirt plugin for running the machine. Using a symlink I can
>    even avoid copying the boxes disk image out of the store — vagrant will
>    create a copy when creating a machine anyway.

I do not have much experience with Vagrant, but I assumed the general idea for
these kind of systems declarative systems is to just recreate the when updates
are required.  Is it expected to actually run guix reconfigure inside the VM?

> 
>    Now for vagrant being able to log into the machine when starting it
>    (and eventually "provision" the machine = execute some commands) boxes
>    are expected to include an "insecure ssh key" in
>    ~vagrant/.ssh/authorized_keys. Vagrant will replace this key by another
>    one when creating a machine. So this behavior is reasonable secure.
> 
>    One possible solution I found (not yet tested and tools not yet in
>    guix) is to use one of the guestfstools ([1]https://libguestfs.org/) to
>    copy the file into the image. Anyhow this would require copying the box
>    out of the store to get a writable file.
> --
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel          | [2]h.goebel@crazy-compilers.com               |
> | [3]www.crazy-compilers.com | compilers which you thought are impossible |
> 
> References
> 
>    1. https://libguestfs.org/
>    2. mailto:h.goebel@crazy-compilers.com
>    3. http://www.crazy-compilers.com/

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Putting a file into system image ~user/ but not on reconfigure

[Hartmut Goebel]

Am 10.08.23 um 14:12 schrieb wolf:
>
> I guess you could have a script that would use the existence of the key itself
> as a marker.  In that case you would likely want to recreate it if the marker
> (key) got deleted,

No! The key must not be recreated. The key is expected to be replaced by 
a new one when the box will become a machine. Thus, using the key as a 
marker is not possible, as the would recreate the insecure key on next 
reboot. The key must never ever be put into back into place.

> I do not have much experience with Vagrant, but I assumed the general idea for
> these kind of systems declarative systems is to just recreate the when updates
> are required.  Is it expected to actually run guix reconfigure inside the VM?

This depends on how one uses the virtual machines :-)

And even if it is not expected to run guix reconfigure on it: If one 
does, this but open a front door to the system - which is not what one 
wants.

Anyhow, thanks for sharing thoughts,

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Putting a file into system image ~user/ but not on reconfigure

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

On Thu, Aug 10, 2023 at 02:38:24PM +0200, Hartmut Goebel wrote:
> Am 10.08.23 um 14:12 schrieb wolf:
> > 
> > I guess you could have a script that would use the existence of the key itself
> > as a marker.  In that case you would likely want to recreate it if the marker
> > (key) got deleted,
> 
> No! The key must not be recreated. The key is expected to be replaced by a
> new one when the box will become a machine. Thus, using the key as a marker
> is not possible, as the would recreate the insecure key on next reboot. The
> key must never ever be put into back into place.

I feel compelled to ask if the key must be in
~vagrant/.ssh/authorized_keys or if /etc/ssh/authorized_keys.d/vagrant
is acceptable.

Also, could you use /etc/services or another file in /etc/static as a
marker that the system has been booted at least once before?

> > I do not have much experience with Vagrant, but I assumed the general idea for
> > these kind of systems declarative systems is to just recreate the when updates
> > are required.  Is it expected to actually run guix reconfigure inside the VM?
> 
> This depends on how one uses the virtual machines :-)
> 
> And even if it is not expected to run guix reconfigure on it: If one does,
> this but open a front door to the system - which is not what one wants.

I suppose if you did include an /etc/os-config file you could include a
custom one that doesn't include the file placed in ~vagrant and only
have it in the initial creation config. They could still extract the
actual file from `guix system describe` but I don't suppose there's much
you could do there other than leave a warning to remove those lines.

> 
> Anyhow, thanks for sharing thoughts,
> 
> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel          | h.goebel@crazy-compilers.com               |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Putting a file into system image ~user/ but not on reconfigure

[Hartmut Goebel]

Hello Efraim,

Am 13.08.23 um 16:58 schrieb Efraim Flashner:
> I feel compelled to ask if the key must be in
> ~vagrant/.ssh/authorized_keys or if /etc/ssh/authorized_keys.d/vagrant
> is acceptable.

I'm afraid it needs to be in ~vagrant/.ssh/authorized_keys: When first 
booting the machine, Vagrant logs into it and replaces the key. Thus the 
user vagrant must be allowed to change the respective file.

Why are you asking? What would be easier (in respect of not 
re-installing the key), if putting the key into 
/etc/ssh/authorized_keys.d/vagrant would work?

> Also, could you use /etc/services or another file in /etc/static as a
> marker that the system has been booted at least once before?

Such a marker would be okay. Anyhow to make this work, some respective 
new service would need to detect this quite early, before /etc/service 
gets linked. Otherwise the service could not distinguish between "first" 
and "at least once"- Or did I misse something?

Is there some means of ordering service execution/start?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          |h.goebel@crazy-compilers.com                |
|www.crazy-compilers.com  | compilers which you thought are impossible |

Re: Putting a file into system image ~user/ but not on reconfigure

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]

On Thu, Aug 17, 2023 at 09:30:24PM +0200, Hartmut Goebel wrote:
> Hello Efraim,
> 
> Am 13.08.23 um 16:58 schrieb Efraim Flashner:
> > I feel compelled to ask if the key must be in
> > ~vagrant/.ssh/authorized_keys or if /etc/ssh/authorized_keys.d/vagrant
> > is acceptable.
> 
> I'm afraid it needs to be in ~vagrant/.ssh/authorized_keys: When first
> booting the machine, Vagrant logs into it and replaces the key. Thus the
> user vagrant must be allowed to change the respective file.
> 
> Why are you asking? What would be easier (in respect of not re-installing
> the key), if putting the key into /etc/ssh/authorized_keys.d/vagrant would
> work?

There's already tooling available to place a key in
/etc/ssh/authorized_keys.d/vagrant, and when you include an os-config in
the image you can leave that line out. That way it'll be there in the
initial image when it is created (and when /etc is populated on first
boot) but it would disappear on reconfigure.

I suppose another option would be a one-off service that checks if
~vagrant/.ssh/authorized_keys exists, and if it doesn't then create one
with the desired key and chown and chmod ~/.ssh to vagrant.

> > Also, could you use /etc/services or another file in /etc/static as a
> > marker that the system has been booted at least once before?
> 
> Such a marker would be okay. Anyhow to make this work, some respective new
> service would need to detect this quite early, before /etc/service gets
> linked. Otherwise the service could not distinguish between "first" and "at
> least once"- Or did I misse something?
> 
> Is there some means of ordering service execution/start?

I'd have to dive into the internals of system bring up a bit, but if I
understand correctly before first boot there's a series of derivations
that get combined together during boot to create the actual running
system. Then after first boot they "actually live in their final
locations", and get swapped out on reconfigure. So before first boot
there's a bunch of files in /etc that aren't actually present yet, but
after first boot they've been linked into place.

I mostly got this from building system images so its definitely possible
that I've understood it incorrectly. Also as I think about it more,
other than depending on some filesystem service, I'm not sure what you
could depend on that would definitely slot in correctly to run on
first-boot. I suppose /etc/ssh/ssh_host_ed25519_key won't be there on
first boot, but you'd still basically be racing the openssh-service.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Putting a file into system image ~user/ but not on reconfigure

[Hartmut Goebel]

Hi Efraim,

hanks for sharing your thoughts. Meanwhile I learned two things:

  * vagrant needs adjustment to detect and support Guix, which is
    intended by vagrant and vagrant is extensible for this case, see
    https://github.com/hashicorp/vagrant/tree/main/plugins/guests
  * just replacing the "vagran isecure key" in /etc/ssh/auhorizedkeys.d/
    is of not much use: after reboot the file is restored.

So looks like I need to further investigate this topic in more depth.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          |h.goebel@crazy-compilers.com                |
|www.crazy-compilers.com  | compilers which you thought are impossible |