SSB_CONFIG_FILE for ./sbotcli

[mhfowler]

The configurations documented here work great for ./go-sbot

but I'm wondering if maybe they are not currently hooked up to work with ./sbotcli as well?

I'm currently working on a peachpub package for yunohost, which requires the go-sbot datadir being installed in a non-standard location (in /home/yunohost.app/peachpub/.ssb-go) instead of in the home folder of the user who is running go-sbot. I've been able to get this working great for ./go-sbot using the SSB_CONFIG_FILE env variable which is documented in config.md

but when I run ./sbotcli commands, I'm running into an error because it can't find .ssb-go in the correct place.

For example:
SSB_CONFIG_FILE=/home/yunohost.app/peachpub/.ssb-go/config.toml ./sbotcli call whoami

yields the error:

level=warn client="unix-path based init failed" err="ssbClient: failed to open unix path \"/root/.ssb-go/socket\""

I think using ./sbotcli is not strictly necessary for my usecase, but it would be helpful for debugging, and in an ideal world probably helpful to have parity between how ./sbotcli and ./go-sbot are configured (or I might also be missing something)

[decentral1se]

but I'm wondering if maybe they are not currently hooked up to work with ./sbotcli as well?

afaiu sbotcli does not have config special powers, so that would need to be implemented. A similar approach to #138 could be taken but I guess @cblgh would have more information on that.

Some potential work-arounds for now might be:

• symlink the custom config file into the path that sbotcli expects
• add a small patch to the following to allow environment variable overriding & re-compile https://github.com/cryptoscope/ssb/blob/8bb04d96e053f4d00b8d9f6cadfeb5cbd9b87756/cmd/sbotcli/main.go#L61-L62

[mhfowler]

aw thanks @decentral1se , creating a symlink was a great workaround, all good atleast for debugging :-)
ln -s /home/yunohost.app/peachpub/.ssb-go /root/.ssb-go

[decentral1se]

Hey @mhfowler dove into this briefly and I came to the conclusion that I should better ask you first ☺️

So, sbotcli has different config options than go-sbot in:

go-ssb/cmd/sbotcli/main.go

Lines 72 to 81 in 8bb04d9

	Flags: []cli.Flag{
	&cli.StringFlag{Name: "shscap", Value: "1KHLiKZvAvjbY1ziZEHMXawbCEIM6qwjCDm3VYRan/s=", Usage: "shs key"},
	&cli.StringFlag{Name: "addr", Value: "localhost:8008", Usage: "tcp address of the sbot to connect to (or listen on)"},
	&cli.StringFlag{Name: "remoteKey", Value: "", Usage: "the remote pubkey you are connecting to (by default the local key)"},
	&keyFileFlag,
	&unixSockFlag,
	&cli.BoolFlag{Name: "verbose,vv", Usage: "print muxrpc packets"},
	&cli.StringFlag{Name: "timeout", Value: "45s", Usage: "pass a duration (like 3s or 5m) after which it times out, empty string to disable"},
	},

That means that we might want to make some changes to the config.toml to allow each CLI tool (go-sbot, sbotcli, etc.) to understand which config options are related to itself. This could mean using a TOML table like so:

[go-sbot]
stuff = 1

[sbotcli]
other_stuff = 0

Then I could abstract the config logic out of go-sbot and apply it to sbotcli while re-using the same config file. This change would break existing configs though! It would be a small config migration though. Whatcha think?

/cc @cblgh

[mhfowler]

thanks for looking into this @decentral1se

I've actually been using your symlink suggestion quite effectively since you mentioned it, so this hasn't been much of an obstacle for me personally

doing the config migration sounds not so hard, if you think thats the best format
also cc @mycognosist

[mhfowler]

the one annoying thing is I have already made a yunohost package including go-sbot that some people might have downloaded,
so I might need to figure out how to include the migration in a yunohost package upgrade, which I haven't done before yet...

[decentral1se]

Ah ok, maybe this isn't so urgent then but perhaps worth trying anyway. It seems like a small enough thing to dip my toes in on.

For the YunoHost stuff, I'd guess an approach like 1. back up the config file (there should be a YunoHost helper for this 2. template out new config file with contents of a single line: [go-sbot] into the right directory 3. cat the backed up file into the new templated config file (e.g. cat $backed_up_file > $templated_new_config, because all options will naturally be for go-sbot and not for sbotcli since it was not supportes yet 🙃

[decentral1se]

@KyleMaas @mycognosist whatcha think?

[mycognosist]

@decentral1se

I like your suggested approach to combine the configs using TOML tables. Based on the experience of @mhfowler and @KyleMaas it seems that a single shared config that works out of the box will be most intuitive and frictionless.

Ideally we follow the order of precedence already established by @cblgh for the go-sbot config: https://github.com/ssbc/go-ssb/blob/master/docs/config.md

We'll just need to be mindful of keeping @mhfowler in the loop before merging, so we can coordinate on the migration script.

[KyleMaas]

@decentral1se Yeah, I like the shared config with the TOML tables. That would make a lot more intuitive sense for me and be a lot more inline with how other packages have configuration for multiple binaries within the same package.

[KyleMaas]

@decentral1se Are you still working on this?

[decentral1se]

@KyleMaas nah, I bailed on this a while back in favour of the test suite fixing effort.

[KyleMaas]

Wow...this is much more difficult than expected. The fact that sbotcli uses urfave/cli means this is tough to patch in with TOML tables.

[decentral1se]

@mhfowler this is now supported on latest! Watch out though, you'd need to migrate your configs to the new format in https://github.com/ssbc/go-ssb/blob/master/docs/config.md#example-config (TLDR; add [go-sbot] to existing configs). Thanks @KyleMaas for taking time to make this happen 👏