[discussion] globalsiteselector+lookup-server

[ArtificialOwl]

This app needs some love. It is an important app for multiple type of setup (GlobalScale of course, but also collective of small instances)
I will make here the list of issues and troubles how we could fix/implement them (from my point of view)

Issues/troubles

1. Compatibility 20+

2. Reaching other instance of a GlobalScale using internal address. Right now, because the CloudId is generated using the frontal address of the instance of Nextcloud (and broadcasted to the lookup-server when a new user is generated), federated shares between instance of GlobalScale cannot work using internal address. Meaning that :

• every frontal address of the network of instances of Nextcloud needs to be reachable from each instance of the GlobalScale, which might not always be the case, based on the network configuration of the infrastucture.
• instances cannot communicate using internal address to avoid useless load on all frontal hardware (router, firewall, bnc, ...)

3. Setup of the lookup-server. The setup of the lookup-server is not a great user experience. There is no way to test/confirm stuff during the setup process other than using it and see if it is working or not at the
end of the installation

Solutions

1. compatibility to 22 is done with #39

2. First, the first modification we needs is to allow an admin to configure the domain used in frontal and internal when generating the cloudId. Then the data needs to be stored on the lookup-server, and used the right one when searching for a user from another instance of the network, based on the address used to generated the request (if the address to reach the lookup-server is considered internal, the lookup-server will returns an internal cloudId)

Right now, we use a single JWT key to allow an instance in the globalscale network, meaning that :

• you have to trust the origin of the request and its content or run a cross request.
• you have to reset the JWT key on all slave+lookup-server when removing an instance of the network.

So, the second point will be to replace the JWT key with the webfinger+key pair authentication, this will make every request between master<->lookup-server and slave<->lookup-server been identified, without a need a cross-request.

Also, adding a new server to the network can be done from the gss-master that will communicate the data about the new server with the lookup-server.

3. It might be interesting to migrate the lookup-server as an App for Nextcloud. We have a great framework, and if it feels too heavy for an external lookup-server we can start looking in a 'light' mode for Nextcloud that remove useless code for a setup of 'just' a lookup-server.

Using a Nextcloud with an App that replace the fonctionality of a lookup-server would:

• better Installation/Migrations
• help with the webfinger concept to identify remote request, as there is already an handler integrated to core
• comes with a complete command line framework (occ)
• Allow to have a single installation for lookup-server and gss-master. (If the admin does not feel the need of having the lookup-server in an internal address, he/she can just install globalsiteselector and lookup-server on the gss-master)

Conclusion

This is just a quick report of what I think need to be done in globalsiteselect and lookup-server.
If this change is too big to be implemented in those projects, I can see to create a different app based on those features!

[karlitschek]

Agreed. But the performance need to be fully benchmarked before turning the lookup server into an app. This is critical for big installations and the reason why it was originally developed as stand alone.

[ArtificialOwl]

In fact, it might takes less resource (beside having to find a new name) to fork the globalsiteselector and have the forked app working with the LookupServer App, while keeping the current gss app using the (old ) LookupServer StandAlone Edition. This approach will allow a smoother migration