When you visit https://us1.storj.io/api/v0/config, you will see several interesting domains:
{
...
"gatewayCredentialsRequestURL": "https://auth.storjsatelliteshare.io",
"linksharingURL": "https://link.storjsatelliteshare.io",
"publicLinksharingURL": "https://link.storjshare.io",
...
}
What are those? What do they do?
auth.storjsatelliteshare.io is the authservice binary in edge repository.
link.storjshare.io is the linksharing binary in edge.
But, some questions arise:
Why do Storj buying 2 more domains for this?
Why not just use: `linkshare.storj.io` or `auth.storj.io`?
What the different between storjsatelliteshare.io and storjshare.io?
# using `whois storjshare.io` and `whois storjsatelliteshare.io`
storjshare.io (Creation Date: 2020-12-09T18:22:02Z)
storjsatelliteshare.io (Creation Date: 2023-04-18T19:01:16Z)
So it’s just one month after Announcing Community Satellite Pilot Program, not sure if there are correlation.
Maybe it have something todo with cookie interaction between domain and subdomain? Or maybe this is only for whitelabel satellite and brand seperation?
My real question is this: can this be done via subdomain only, so that I could get away without buying 2 more domains 
. Really appreciated if anyone could give hint on this.
Also, did you see https://compute.storj.io in config link above, an incoming product? 
No zero downtime deployment and HA setup
Initially, I was happy to find out that, there are documents for authservice (in edge/docs/gateway-mt.md), but my happiness was short lived, docs in edge service is severly outdated.
And I also found out an interesting lore about authservice:
# https://github.com/storj/edge/blob/08b80a8d896d5b613c672ce8ced6312959b9d2e7/pkg/auth/badgerauth/README.md
# but it was later remove
# https://github.com/storj/edge/commit/a3ac234eaac4392cb3cf583e3088738895a2171b
The reason I mention all of this: because it compromised with my HA setup and zero downtime deployment. See, right now, authservice is either support:
// https://github.com/storj/edge/blob/08b80a8d896d5b613c672ce8ced6312959b9d2e7/pkg/auth/storage.go#L28-L35
switch driver {
case "badger":
return badgerauth.Open(log, config.Node)
case "spanner":
return spannerauth.Open(ctx, log, config.Spanner)
default:
return nil, errs.New("unknown scheme: %q", config.KVBackend)
}
Spanner is prohibitively expensive, so we are left with badger database option.
The thing is this:
- authservice is integrated with badger db.
- and badger have a habit of locking the directory data so that it is the only one could write to it data (which is good on it own).
But if combine these together, now, only one authservice process could exist at any given time and it defeat my zero downtime deployment and HA setup.
Minimum useful command
authservice run \
--cert-file <crt_file_path> \
--key-file <key_file_path> \
--endpoint 'gateway.example.com' \
--kv-backend 'badger://' \
--node.path badger-data \
--auth-token 123456 \ # set the same value into gateway-mt
--public-url 'https://auth.example.com' \
--allowed-satellites 'https://www.storj.io/dcs-satellites' # copy this format
--cert-file and --key-file, to generate it, you could use certbot to generate the file for your (sub)domain. But I’d like to cheat here, I already use caddy webserver, it auto generate and renew certificate for me, so the path to my cert file is something like this:
/var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/auth.example.com/auth.example.com.crt
/var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/auth.example.com/auth.example.com.key # Pretty neat eh?
--endpoint: is the (sub)domain for your gateway, for example gateway.storjshare.io or global.gateway.storjshare.io
On default, authservice will listen on 4 ports:
--drpc-listen-addr string public DRPC address to listen on (default ":20002")
--drpc-listen-addr-tls string public DRPC+TLS address to listen on (default ":20003")
--listen-addr string public HTTP address to listen on (default ":20000")
--listen-addr-tls string public HTTPS address to listen on (default ":20001")
--proxy-addr-tls string TLS address to listen on for PROXY protocol requests (default ":20005")
Though, there is no option to disable drpc (non tls) and http, even Storj left those port open on their gateway, guess we could ignore it.
That is it for today, see you on part 15, we will explore gateway or linksharing next.