... | @@ -1398,32 +1398,135 @@ as well. |
... | @@ -1398,32 +1398,135 @@ as well. |
|
|
|
|
|
## Proposed Solution
|
|
## Proposed Solution
|
|
|
|
|
|
In the short term, the situation with Python 2 needs to be
|
|
TL;DR: three phase migration away from LDAP
|
|
resolved. Either the Python code needs to be ported to Python 3, or it
|
|
|
|
needs to be replaced by something else. That is "urgent" in the sense
|
|
|
|
that Python 2 is already end of life and will likely not be supported
|
|
|
|
by the next Debian release, around summer 2024.
|
|
|
|
|
|
|
|
TODO: propose a solution to resolve the issues with ud-ldap
|
|
|
|
|
|
|
|
|
|
|
|
TODO: propose a solution to resolve the issues with ud-ldap
|
|
1. stopgap: merge with upstream, port to Python 3 if necessary
|
|
|
|
2. move hosts to Puppet, replace ud-ldap with another user dashboard
|
|
|
|
3. move users to Puppet (sysadmins) or Kubernetes / GitLab CI /
|
|
|
|
GitLab Pages (developers), remove LDAP
|
|
|
|
|
|
TODO: evaluate what parts of ud-ldap could be replaced with Puppet.
|
|
The long version...
|
|
|
|
|
|
TODO: evaluate what users need a shell for - maybe it can all be moved
|
|
### Short term: merge with upstream, port to Python 3 if necessary
|
|
to containers?
|
|
|
|
|
|
|
|
### brainstorm:
|
|
In the **short term**, the situation with Python 2 needs to be
|
|
|
|
resolved. Either the Python code needs to be ported to Python 3, or it
|
|
* static sites -> gitlab pages?
|
|
needs to be replaced by something else. That is "urgent" in the sense
|
|
* apps deployement like onionoo -> containers?
|
|
that Python 2 is already end of life and will likely not be supported
|
|
* shell servers like perdulce for IRC -> ZNC in a container?
|
|
by the next Debian release, around summer 2024. Some work in that
|
|
* people.tpo/~foo -> gitlab pages?
|
|
direction has been done upstream, but it's currently unclear whether
|
|
* what else?
|
|
ud-ldap is or will be ported to Python 3 in the short term.
|
|
|
|
|
|
maybe we can get rid of most users and then get rid of LDAP, in the
|
|
The **diff with upstream** also makes it hard to collaborate. We
|
|
long term?
|
|
should make it possible to use directly the upstream package with a
|
|
|
|
local configuration, without having to ship and maintain our own fork.
|
|
|
|
|
|
|
|
### Mid term: move hosts to Puppet, possibly replace ud-ldap with simpler dashboard
|
|
|
|
|
|
|
|
In the **mid-term**, we should remove the duplication of duty
|
|
|
|
between Puppet and LDAP, at least in terms of actual file
|
|
|
|
distribution, which should be delegated to Puppet. In practical terms,
|
|
|
|
this implies replacing `ud-generate` and `ud-replicate` with the
|
|
|
|
Puppet server and agents. It could still talk with LDAP for the host
|
|
|
|
directory, but at that point it might be better to simply **move all
|
|
|
|
host metadata into Hiera**.
|
|
|
|
|
|
|
|
For users, the situation is less clear: we need some sort of dashboard
|
|
|
|
for users to **manage their email forward** and, if that project ever sees
|
|
|
|
the light of day, their email (submission, IMAP?) password. It is also
|
|
|
|
needed to **manage shell access** and SSH keys. So in the mid-term, the
|
|
|
|
**LDAP user directory would remain**.
|
|
|
|
|
|
|
|
At this point, however, it might not be necessary to use ud-ldap at
|
|
|
|
all: another dashboard could be use to manage the LDAP database. The
|
|
|
|
`ud-mailgate` interface could be retired and the web interface
|
|
|
|
replaced with something simpler, like [ldap-user-manager][ldap-user-manager].
|
|
|
|
|
|
|
|
So hopefully, in the mid term, it should be possible to completely
|
|
|
|
replace ud-ldap with Puppet for hosts and sysadmins, and an already
|
|
|
|
existing LDAP dashboard for user interaction.
|
|
|
|
|
|
|
|
### Long term: replace LDAP completely, with Puppet, GitLab and Kubernetes
|
|
|
|
|
|
|
|
In the **long term**, the situation is muddier: at this stage, our
|
|
|
|
dependence on ud-ldap is either small (just users) or non-existent (we
|
|
|
|
use a different dashboard). But we still have LDAP, and that might be
|
|
|
|
a database we could get rid of completely.
|
|
|
|
|
|
|
|
We could simply stop offering shell access to non-admin users. User
|
|
|
|
access on servers would be managed completely by Puppet: only `sudo`
|
|
|
|
passwords need to be set for sysadmin anyways and those could live
|
|
|
|
inside Hiera.
|
|
|
|
|
|
|
|
Users currently requiring shell access would be encouraged to migrate
|
|
|
|
their service to a container image and workflow. This would be backed
|
|
|
|
by GitLab (for source code), GitLab CI/CD (for deployment) and
|
|
|
|
Kubernetes (for the container backend). Shell access would be limited
|
|
|
|
to sysadmins, which would take on orphan services which would be
|
|
|
|
harder to migrate inside containers.
|
|
|
|
|
|
|
|
Because the current shell access provided is very limited, it is
|
|
|
|
believe migration to containers would actually be not only feasable
|
|
|
|
but also beneficial for users, as they would possibly get more
|
|
|
|
privileges than they currently do.
|
|
|
|
|
|
|
|
Storage could be provided by Ceph and PostgreSQL clusters.
|
|
|
|
|
|
|
|
Those are the current services requiring shell access (as per
|
|
|
|
`allowedGroups` in the LDAP host directory), and their possible
|
|
|
|
replacements:
|
|
|
|
|
|
|
|
| Service | Replacement |
|
|
|
|
|---------------------------------------------|----------------------------------------------|
|
|
|
|
| Applications (e.g. bridgedb, onionoo, etc) | GitLab CI, Kubernetes or Containers |
|
|
|
|
| fpcentral | [retirement?][] |
|
|
|
|
| Debian package archive | GitLab CI, GitLab pages |
|
|
|
|
| Email | email-specific dashboard |
|
|
|
|
| Git(olite) maintenance | GitLab |
|
|
|
|
| Git(web) maintenance | GitLab |
|
|
|
|
| Jenkins | GitLab CI |
|
|
|
|
| Mailing lists | Debian packages + TPA |
|
|
|
|
| RT | Debian packages + TPA |
|
|
|
|
| Schleuder maintenance | Debian packages + TPA |
|
|
|
|
| Shell server (e.g. IRC) | ZNC bouncer in a container |
|
|
|
|
| Static sites (e.g. mirror network, ~people) | GitLab Pages, GitLab CI, Nginx cache network |
|
|
|
|
| Trac | GitLab |
|
|
|
|
|
|
|
|
Note that this implies the TPA team takes over certain services
|
|
|
|
(e.g. Mailman, RT and Schleuder, in the above list). It might mean
|
|
|
|
expanding the sysadmin team to grant access to service admins.
|
|
|
|
|
|
|
|
It also implies switching the email service to another, hopefully
|
|
|
|
simpler, dashboard. Alternatively, this could be migrated back into
|
|
|
|
Puppet as well: we already manage a lot of email forwards by hand in
|
|
|
|
there and we already get support requests for people to change their
|
|
|
|
email forward because they do not understand the ud-ldap interface
|
|
|
|
well enough to do it themselves (e.g. [this ticket](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40059)). We could also
|
|
|
|
completely delegate email hosting to a third-party provider, as was
|
|
|
|
discussed in [the submission project](submission).
|
|
|
|
|
|
|
|
Those are the applications that would need to be containerized for
|
|
|
|
this approach to be completed:
|
|
|
|
|
|
|
|
* BridgeDB
|
|
|
|
* Check/tordnsel
|
|
|
|
* Collector
|
|
|
|
* Concensus health
|
|
|
|
* CiviCRM
|
|
|
|
* Doctor
|
|
|
|
* Exonerator
|
|
|
|
* Gettor
|
|
|
|
* Metrics
|
|
|
|
* OnionOO
|
|
|
|
* Survey
|
|
|
|
* Translation
|
|
|
|
* ZNC
|
|
|
|
|
|
|
|
[retirement?]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40009
|
|
|
|
|
|
|
|
This is obviously a quite large undertaking and would need to be
|
|
|
|
performed progressively. Thankfully, it can be done in parallel
|
|
|
|
without having to convert everything in one go.
|
|
|
|
|
|
## Cost
|
|
## Cost
|
|
|
|
|
... | @@ -1440,11 +1543,15 @@ Directory standard). |
... | @@ -1440,11 +1543,15 @@ Directory standard). |
|
|
|
|
|
* [eGroupWare][]: has an LDAP backend, probably not relevant
|
|
* [eGroupWare][]: has an LDAP backend, probably not relevant
|
|
* [LDAP account manager][]: self-service interface non-free
|
|
* [LDAP account manager][]: self-service interface non-free
|
|
|
|
* [ldap-user-manager][]: "PHP web-based interface for LDAP user
|
|
|
|
account management and self-service password change", seems
|
|
|
|
interesting
|
|
* [GOsa][]: "administration frontend for user administration"
|
|
* [GOsa][]: "administration frontend for user administration"
|
|
* [phpLDAPadmin][]: like phpMyAdmin but for LDAP, for "power users",
|
|
* [phpLDAPadmin][]: like phpMyAdmin but for LDAP, for "power users",
|
|
long history of critical security issues
|
|
long history of critical security issues
|
|
* [web2ldap][]: web interface, python, still maintained, not exactly intuitive
|
|
* [web2ldap][]: web interface, python, still maintained, not exactly intuitive
|
|
|
|
|
|
|
|
[ldap-user-manager]: https://github.com/wheelybird/ldap-user-manager
|
|
It might be simpler to rewrite `userdir-ldap-cgi` with [Django][], say
|
|
It might be simpler to rewrite `userdir-ldap-cgi` with [Django][], say
|
|
using the [django-auth-ldap][] authentication plugin.
|
|
using the [django-auth-ldap][] authentication plugin.
|
|
|
|
|
... | | ... | |