Scap3 targets should use a config file rather than `key:value` arguments
Closed, ResolvedPublic

Description

It would be nice to pass only a config-file path to the remote targets rather than rely on passing -D key:value pairs.

  1. The command we're running on targets is getting longer than anyone wants to look too deeply at (see: D23#607)
  2. The values we're passing in on the command line are all strings—we could kill a whole class of bugs by using a config file that gets parsed.
thcipriani updated the task description. (Show Details)
thcipriani raised the priority of this task from to Needs Triage.
thcipriani added subscribers: thcipriani, 20after4, dduvall, demon.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 23 2015, 8:37 PM

As crude as the -D options may seem, I still like them better than the alternative which would seem to be writing out a temporary config file and loading it in on the remote end. Can't we just coerce theses values based on the default item's type?

I suppose I don't have overly strong feelings about keeping the -D options and typing seems like it will work fine.

There are two benefits to eliminating -D args in favor of a config file:

  1. Rerunning failed commands on target nodes becomes less of a hassle
  2. Troubleshooting configuration errors on an individual target doesn't require a few layers of copy-pasting

The main drawback I see is there is an additional configuration file fetch per-target.

I like the solution of creating types for config variables, at least until T116630 is sorted.

dduvall added a comment.EditedOct 26 2015, 11:01 PM

There are two benefits to eliminating -D args in favor of a config file:

  1. Rerunning failed commands on target nodes becomes less of a hassle

Only if the temporary config file is still accessible and in the same state as it was when the command was originally executed. I think if we just join'd the command string before logging, rerunning commands would be much easier.

  1. Troubleshooting configuration errors on an individual target doesn't require a few layers of copy-pasting

I'm not sure it would be easier to troubleshoot. With the -D options, you have everything you need to reproduce the invocation of deploy-local whereas a temporary config is ephemeral and unlogged (we could always log the values but then you're stuck reconstructing the config file).

I was originally concerned about hitting the limit for maximum command line length, however, it appears that on Linux that limit is 2090327 bytes, so unless ssh somehow imposes a smaller limit then I guess that probably will not be an issue.

$ xargs --show-limits
Your environment variables take up 4777 bytes
POSIX upper limit on argument length (this system): 2090327
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 2085550
Size of command buffer we are actually using: 131072

I'd be in favour of using a config file. In order not to use temp files, we could leverage the built-in HTTP server that is planned and serve the config needed by deploy-local that way?

@mobrovac: That was one of my main reasons for proposing the built-in HTTP server ;)

I do see @dduvall's point about the arguments being in the log and therefore more paste-able for debugging / testing.

The argument passing is probably more efficient than requiring another connection back to the central http server though.

demon moved this task from Needs triage to Done on the Scap board.Nov 5 2015, 8:18 PM
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 5 2015, 8:18 PM