reconnects not exported from deployment.lisp

[Andreas Reuleaux]

Sean Whitton <spwhitton at spwhitton.name> writes:

> Hello,
>
> On Fri 05 Aug 2022 at 03:03am +01, Andreas Reuleaux wrote:
>
>> Hi,
>>
>> I found reconnects in deployment.lisp quite useful -
>> for my use case i.e. - and to that end had to export it in
>>
>>   https://git.spwhitton.name/consfigurator/tree/src/package.lisp
>>
>> with
>>
>>   #:reconnects
>>
>> All the other deployments are exported there - thus this seems
>> an omission to me [?].
>>
>>
>> I will be happy to explain my use case in some more detail if needed [?]
>>
>> (And quite possibly, there is another / shorter way of doing what I want
>> to achieve - without reconnects i.e. - just for now I am relying on
>> reconnects .)
>
> It's deliberate, as I was worried that it's a footgun.
>
> Please do go ahead and explain your usecase :)


Hi,


OK, I will try:


At the moment I am not concerned with defining hosts
(applying fixed sets of properties to some given hosts - pseudo
code here):


  (defhost softland
    (os:debian-testing :amd64)
    (some-property)
    (some-other-property)
    (and-so-on-property)
  )


  (defhost laptop
    (os:debian-testing :amd64)
    (some-property)
    (something-else)
    (etc)
  )



but rather with assembling useful tasks (usually defined with
defproplist - and built from smaller building blocks: properties)

  (defproplist task-at-hand :posix ()
    (some-property)
    (some-other-property)
    (and-so-on-property)
  )


  (defproplist another-task :posix ()
    ...
  )


which I can then apply to hosts, in the one or the other manner:

  (deploy-these ((:ssh :user "root")) softland (task-at-hand))
  (deploy-these ((:ssh :user "rx"))   softland (another-task))

And I use very simple host definitions:

  (defhost softland ()
    (os:debian-testing :amd64)
    )

  (defhost laptop ()
    (os:debian-testing :amd64)
    )

just so that I don't have to write the debian os during deployment:

  (deploy-these ((:ssh :user "root")) "softland" (os:debian-testing :amd64) (task-at-hand))


Now, to be a little more concrete - say I want to install (the
console audio player) moc, and configure it for my (non-root) user rx,
using some symlink:

It makes sense to split this task in two pieces:


 (defproplist moc-first-take :posix ()
   (apt:installed "moc")
   )

 (defprop moc-config-symlinked :posix ()
  (:desc #?"moc config symlinked")
  (:apply
    (file:symlinked :from ".moc/config"
          	    :to #?"${(get-connattr :remote-home)}cfg/moc/config"
		   )
   )
  )


And deploy them - in two steps - as two different users root and rx:

  (deploy-these ((:ssh :user "root")) softland (moc-first-take))
  
  (deploy-these ((:ssh :user "rx")) softland (moc-config-symlinked))


apt:installed requires root priviliges, thus I have to connect to
softland as root - for moc-first-take

And moc-config-symlinked I better do as a normal user rx, the result
being then what I want: config is a symbolic link, belongs to rx, and
points to the right location (to some file im my directory of
configurations: cfg)

  rx at softland ~/.moc $ ls -lh config 
  lrwxrwxrwx 1 rx rx 23 Aug  5 10:00 config -> /home/rx/cfg/moc/config
  rx at softland ~/.moc $

If I try to deploy moc-config-symlinked as root, this makes matters way
more complicated: with-home (:user "rx") somehow adjusts the relative paths:

  (with-homedir (:user "rx")
      (file:symlinked :from ".moc/config"
          	      :to #?"${(get-connattr :remote-home)}cfg/moc/config"
      )          

but #?"${(get-connattr :remote-home)} is still root's home, and needs to
be adusted somehow.

And last but not least: my resulting config link belongs to root then:

  lrwxrwxrwx 1 root root 23 Aug  5 10:00 config -> /point/in/the/right/direction/hopefully

And I thus have to change the ownership of that link w/ something like:

  (file:has-ownership ".moc/config"
			 :user "rx"
 			 :group "rx"
    			 )

Thus I want to stick to the easy solution (as above):

  (deploy-these ((:ssh :user "rx")) softland (moc-config-symlinked))


It would nevertheless be nice to have just one combined task:
moc-combined, deployed as root, which internally does both of the
above task:

  make sure, moc is installed - as root
  do the symlinking - temporarily becoming rx for that matter

And I have succeeded in doing so: either with:


  (defproplist moc-combined :posix ()
    (apt:installed "moc")

    (reconnects '((:setuid :user "rx"))
                (make-propspec :propspec `(moc-config-symlinked)
                               ))
  )


And :setuid requires a :lisp connection in my chain here, thus I deploy the combined
task with:

  (deploy-these ((:ssh :user "root") :sbcl) softland (moc-combined))


Or I can do similarly:

  (defproplist moc-combined-2 :posix ()
    (apt:installed "moc")

    (reconnects '((:su :to "rx"))
                (make-propspec :propspec `(moc-config-symlinked)
                               ))
  )

:su being slightly less demanding (a :posix connection will do):

  (deploy-these ((:ssh :user "root")) softland (moc-combined-2))


In any case: reconnects makes sense here, as I want to become "rx" on
the very host that I am connecting to as root.

I have succeeded meanwhile to achieve the same thing with deploys and
localhost.

  (defproplist moc-combined-3 :posix ()
    (apt:installed "moc")

    (deploys '((:su :to "rx")) localhost
             (make-propspec :propspec `(moc-config-symlinked)
                            ))
  )                            

Still I am not 100% if this is correct: it works if softland is my
localhost. - It may or may not work, if I connect to laptop: localhost
(from the perspective of laptop) is laptop, hopefully.

There may also be some solution to ask: which host I am connecting to? -
pseudo code again:



  (defproplist moc-combined-4 :posix ()
    (apt:installed "moc")

    (deploys '((:su :to "rx")) (give-me-the-host-of-the-connection-please)
             (make-propspec :propspec `(moc-config-symlinked)
                            ))
  )                            


In any case: reconnect seems the natural thing to do for me here:
"reconnect to this very host" - as some less privileged user "rx"

And by the way: using propspec as above, was just the solution
I found working - maybe there is an easier solution wo/ prospec - just
(deploys connection host property) ?


Thanks.
-A