Flag or config file for dutctl client

[jenstopp]

The goal is just to avoid typing flags (e.g. the agent's ip address) anytime, when using the client. So there shall be no more options via this kind of file, then there are anyway via flags.

Besides the usual Linux style config files, the u-root project has a unique but very clear approach with .flag file for its uinit command: https://github.com/u-root/u-root?tab=readme-ov-file#init-and-uinit

How It Works

• File Location: The file is located at /etc/uinit.flags in the initramfs
• Processing: During init, the system reads this file and parses its contents into command-line arguments
• Argument Parsing: The file contents are processed by uflag.FileToArgv() which converts the file content into an argv-style argument array

uinit.flags Format Details:

• One argument per line - Each line contains exactly one command-line argument
• Go-style quoted strings - Each argument is wrapped in Go's strconv.Quote() format
• Supports escaping - Newlines and special characters are escaped using Go quoting
• Empty lines ignored - Lines with zero length are skipped

Example uinit.flags:

     "-v"
     "--debug"
     "--config=/path/to/config"
     "--message=hello world"
     "--multiline=line1\nline2"

This would be equivalent to the command line:

uinit -v --debug --config=/path/to/config --message="hello world" --multiline="line1
line2"

##Unique Characteristics:

 - Not shell-style - Unlike many Linux config formats, it doesn't use shell word splitting
 - Precise encoding - Uses Go's strconv.Quote/Unquote for exact reproduction
 - Panic on malformed - Invalid quoting causes a panic, ensuring data integrity

Common Linux Configuration File Formats

1. INI Format (Most Traditional)

     [section]
     key=value
     # comment

Used by: systemd, git, PHP, Samba, many desktop apps

2. Key-Value/Environment (Simplest)

     KEY=value
     HOST=localhost
     PORT=8080

Used by: /etc/environment, .env files, shell scripts

3. YAML (Human-Friendly Hierarchical)

     server:
       host: localhost
       port: 8080
       # comment

Used by: Kubernetes, Docker Compose, Ansible, CI/CD systems

4. JSON (Machine-Friendly Structured)

     {
       "server": {
         "host": "localhost", 
         "port": 8080
       }
     }

Used by: package.json, VS Code settings, many modern tools

Conclusion

The uinit.flags format is unique - it's designed specifically for command-line argument preservation rather than general configuration, making it more precise than shell-style parsing but less human-readable than traditional config formats.

[AtomicFS]

I am not a big fan of this idea for CLI tool.

Why not do some equivalent to SSH config?

Host harpy
    HostName harpy.lab.9e.network
    Port 8080

Host *
    Port 8000

That way you have single file for all the machines (and not million separate files).

And have auto-completion just like SSH has?

[sylv-io]

The u-root .flags approach seems specific to how they parse their initrd arguments. It doesn't seem appropriate for a standard Linux CLI tool like ductl.

It would limit the configuration file to the options provided by the flag arguments, which are one-to-one. In other words, you would statically configure default flags for ductl with no flexibility.

Here is an example:
Suppose we want to define a default configuration that uses a specific DUT agent/server (server1) with a specific configuration. However, we also want to be able to use alternative servers (server2 and server3) with their own configurations.
Using .flag file approach, we could be able to set the flags to connect to server1. However, we would not be able to add the configurations for server2 or server3 because the flags can only store one command line for one target.

Ideally, I would like the option to add servers 1, 2, and 3 to the configuration file. I would set server1 as the default, but I would still like the option to select a different server, perhaps via a flag.

Example INI configuration:

default_server = server1
[server 1]
address = server1.example.com
port = 1337
auth_file = ~/.config/dutctl/cred_server1.pem
[server2]
address = 10.13.37.10
port = 1338
auth_file = ~/.config/dutctl/cred_server2.pem
[server3]
address = 10.13.37.11
# no auth
foo = bar

example how to choose the server:

# server1 (default)
dutctl ....
# server2
dutctl -s server2 ...
# server3
dudtctl -s server3

Thoughts?

[depate]

I'm in favor of Vojtech's and Sylv's ideas. I'd favor yaml, ini, or toml style configs.

OG dutctl actually used this concept as well. Neglecting, that dutctl (client/agent) does not need any DUT config anymore, the GRPCServerAddress and DisableTLS options could be put into the working directory as .dutctl.yaml and be read at invocation of dutctl. In the future, this maybe could also hold more options, like having verbose/debug info turned on by default or choose a default when working with multi-host systems. E.g. default target is the host/device1 in the dutctl server config, but if a manual device flag is set in the CLI, it will overwrite the default to do some action on the BMC (device2) instead.

Having a .dutctl.yaml per project directory made sure you're always targeting your project specific dutctl worker. This is a feature that should be advertised more often.

Edit: Additionally, we could also use the posix-style hierarchy, that .config/dutctl/dutctl.yaml//etc/dutctl/dutctl.yaml holds more (general) config, e.g. authentication details like certificates or user credentials.