System tmp directory is not always same as remote ssh deployment about weaver HOT 14 CLOSED

Thanks for the proposal, @aranw.

I wonder if it's possible for the participants to pick their own temporary directory? This would be a preferable solution to adding another configuration option just for temp directory access. WDYT @rgrandl.

This sounds like a great first project for one of our community members.

from weaver.

Yeah that's kind of what I was thinking by the configuration option. Users of the ssh deployer could then state what temp directory to use overriding the default /tmp

Edit: Another possible solution would be to expand the site locations to be another struct where users can set both ip/hostnames and a temp directory?

from weaver.

Thanks @aranw for the proposal. I agree with @spetrovic77, it would be nice if we don't have to embed the temp directory in the config.

We need the temp directory name per location in 2 places:

• to copy the weaver binary
• to start a babysitter process

Would it be better if we would get the temp directories from each machine and then copy the binary accordingly to each of these?

The pros of this approach is that the config is as simple as it is now.

The cons is that we may need to do an extra ssh command to each location to get their temp directory name, and keep track of that at the manager (which doesn't seem that bad).

from weaver.

When I was looking into this I couldn't find a reliable source for retrieving the temporary directory. On my current Ubuntu 22.04.2 LTS installation $TMPDIR is not set. I've not found a command that would retrieve it.

I have however found the mktemp which could be a reliable alternative

This is the output from Ubuntu 22.04.2 LTS

mktemp --help
Usage: mktemp [OPTION]... [TEMPLATE]
Create a temporary file or directory, safely, and print its name.
TEMPLATE must contain at least 3 consecutive 'X's in last component.
If TEMPLATE is not specified, use tmp.XXXXXXXXXX, and --tmpdir is implied.
Files are created u+rw, and directories u+rwx, minus umask restrictions.

  -d, --directory     create a directory, not a file
  -u, --dry-run       do not create anything; merely print a name (unsafe)
  -q, --quiet         suppress diagnostics about file/dir-creation failure
      --suffix=SUFF   append SUFF to TEMPLATE; SUFF must not contain a slash.
                        This option is implied if TEMPLATE does not end in X
  -p DIR, --tmpdir[=DIR]  interpret TEMPLATE relative to DIR; if DIR is not
                        specified, use $TMPDIR if set, else /tmp.  With
                        this option, TEMPLATE must not be an absolute name;
                        unlike with -t, TEMPLATE may contain slashes, but
                        mktemp creates only the final component
  -t                  interpret TEMPLATE as a single file name component,
                        relative to a directory: $TMPDIR, if set; else the
                        directory specified via -p; else /tmp [deprecated]
      --help     display this help and exit
      --version  output version information and exit

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation <https://www.gnu.org/software/coreutils/mktemp>
or available locally via: info '(coreutils) mktemp invocation'

It is also apparently available on macOS as well https://ss64.com/osx/mktemp.html

from weaver.

Nice. It would be great if we can do this instead of adding a new field in the config.

This sounds great to me.

from weaver.

I'll get to work implementing this and removing the config stuff instead 👍🏻

from weaver.

Sounds great. Thanks @aranw for working on this.

from weaver.

@rgrandl after investigating the mktemp as a possible solution am not sure it'll be ideal as each iteration over locs calling mktemp on each server will create a new unique folder per location and looking at the code am assuming you'll ned to know the location of the binary

I don't know enough about how you run the app binaries just yet but am guessing this dep.App.Binary is used elsewhere?

Maybe it'll make more sense to just change

This should work across all unix/posix servers

from weaver.

@aranw I think that using mktemp should be fine. The only prerequisite would be that mktemp command should exist on all the machines.

I think what you can do is as follows:

• in https://github.com/ServiceWeaver/weaver/blob/main/internal/tool/ssh/deploy.go#L134, for each location you will run a SSH command that does mktemp -u. This will return you a path to a temp directory (e.g., /tmp/tmp.Flu0vKtk5v). Note that -u it means dry-run so the directory is not actually created. Then you can do another ssh command where you create the actual directory (e.g., mkdir -p /tmp/tmp.Flu0vKtk5v/deploymentid) https://github.com/ServiceWeaver/weaver/blob/main/internal/tool/ssh/deploy.go#L145.

• you will have to keep track the mapping between location and the corresponding temporary directory. This mapping is needed by the manager https://github.com/ServiceWeaver/weaver/blob/main/internal/tool/ssh/impl/manager.go to start remote babysitters at these locations.

Note: https://github.com/ServiceWeaver/weaver/blob/main/internal/tool/ssh/deploy.go#L142 - this might be a bug. I don't remember why we did that, but I think it's safe to ignore it. I will send a fix, once I try it out on multiple machines. Do you mind checking if the deployment works on multiple machines if you comment this line (in case you have access to a cluster)?

I would avoid hardcoding /tmp because that can get tricky and harder to evolve.

from weaver.

Hey @rgrandl sorry for the slow reply. I've been busy last week or so now with other stuff

Just getting back into this and looking into

If I understand your proposed solution I'll end up with a unique path per ssh location but looking at the current code there is no way to represent that and I'll need to make a few changes so that I can track a location and it's path for use by the manager?

from weaver.

Hi @aranw that's correct.

from weaver.

Hi. What is the current status of the implementation?

Cheers.

from weaver.

Hey @naivary @rgrandl

Unfortunately I haven't been able to work on this since my last update. Various things came up both in my work life and personal and it's resulted in me not having the time to work on this at all

from weaver.

Can I try to help you and solve the problem with you?

from weaver.