[HN Gopher] Show HN: Lldap, a Simplified LDAP Server
___________________________________________________________________
Show HN: Lldap, a Simplified LDAP Server
Hi everyone! For the past year I've been working on a simple LDAP
server for user management, targeted at self-hosted servers. The
idea is that OpenLDAP is a pain to install, configure and manage,
and on top of that you need a frontend if you want a web UI. LDAP
instead provides a minimalistic LDAP server that supports the
subset of LDAP needed for user management and authentication, with
almost no configuration required, and a nice UI/API in front of it.
We just released version 0.4 (and 0.3 actually) and it should now
be stable enough to use it yourself! We've had some people using
it for tests as well.
Author : nitnelave
Score : 194 points
Date : 2022-07-11 09:29 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bch wrote:
| I'll watch with interest, and am heartened with the responses I
| see. One thing I wish is that the license were also more
| "lightweight". GPL3 for a piece of backend network infra seems a
| bit fraught. This is usually the domain of ISC, MIT, or BSD.
| laumars wrote:
| Samba is GPLv3. OpenLDAP has its own license but has some GPL-
| like clauses regarding code redistribution. I can't recall what
| NIS is licensed under but it was written by Sun and then
| licensed to other vendors so odds are it's not MIT/BSD either.
| bartvk wrote:
| Why would you want that? Genuine question. You say
| "lightweight" but what does that mean, and why is it "fraught"?
|
| I think it's great, and as far as I understand, it blocks
| companies from offering it in a way that doesn't bring anything
| of value to the community.
| bch wrote:
| I say "lightweight" in terms of text and comprehension.
|
| I say "fraught" because it imposes conditions on running this
| on the network. Perhaps fraught is too editorial. Regardless
| - in some environments, that "stickiness" of the GPL is a
| non-starter. One may say that "weeding out" those envs is
| part of the point. In my opinion though, for things like
| libraries or "lower level" software there seems to be a
| school of thought where "getting it out there" is more
| important than "saving it" from modifications.
|
| I tend to think of GPL[2/3] as for end-user applications,
| like openoffice or ardour[0] (paging 'PaulDavisThe1st) and
| libraries and network services as mit/bsd/isc/lgpl so they
| can interact with Other Software without forcing anything on
| that Other Software.
|
| I hesitated even posting my original comment, but don't mind
| getting a potentially new read on others devs point of view
| on this area.
|
| Briefly, on "block[ing] companies ... that [don't] bring
| anything of value...", you also block orgs that would bring
| value, but might not want to be legislated to publish
| everything.
|
| [0] https://ardour.org/
| aorth wrote:
| How does it compare to 389 Directory Server? I've been using that
| with SSSD for user management and authentication in a small LAN
| with about twenty machines for about ten years. It is rock solid,
| but every few years when I do an major OS upgrade I have to get
| deep into the weeds and it always takes me a few days to become
| familiar with all the backend stuff again. I'm not using Kerberos
| or single sign on or anything fancy.
| zokier wrote:
| 389 is afaik full-featured enterprise LDAP server, so I guess
| the main difference is complexity. One thing to note is that
| there is also FreeIPA companion project for 389, which a
| bundles in kerberos, sssd etc that are needed for full auth
| set-up
| znpy wrote:
| I just don't understand why LDAP software has to generally be so
| unnecessarily complicated. I'm not talking about the protocol or
| the domain knowledge, i'm talking about implementations.
|
| I've played with OpenLDAP and 389ds.
|
| OpenLDAP is dumb in the sense that its own configuration is
| stored in OpenLDAP itself, so you need to know openldap to start
| learning openldap. And its community is quite toxic (i've seen
| people in their irc channel mocking users asking questions and
| giving out replies like "it's not in the official docs but it's
| in the codebase, you should have read the source code").
|
| 389ds... is barely documented. The official documentation often
| points to the proprietary counterpart from RedHat, but it's not
| clear what the open version corresponds to which proprietary
| version.
|
| This is really a niche that could use some disrupting imho...
| derekzhouzhen wrote:
| I agree OpenLDAP is not for the casual users. However, storing
| config in the LDAP itself is a strength; almost everything can
| be reconfigured at the run time, using the standard LDAP tool.
| majkinetor wrote:
| Can this be used for automatic tests or there are some other
| tools that people use for that use case?
|
| We develop apps that have LDAP/AD auth. integration and I always
| wanted to have that feature tested locally, without relying on
| corporate network and full blown LDAP/AD server.
| lukeh wrote:
| Paging hyc!
| GuB-42 wrote:
| I like the irony. LLDAP: lightweight lightweight directory access
| protocol
|
| I wonder how terrible DAP may be if LDAP is "lightweight".
| layer8 wrote:
| One "lightweight" applies to the protocol, the other to the
| server software. Arguably it should be named L(LDAP)S. :)
| noselasd wrote:
| "X.500 is too complex to support on desktops and over the
| Internet, so LDAP was created to provide this service 'for the
| rest of us'" - https://en.wikipedia.org/wiki/X.500 (aka. DAP)
| dfox wrote:
| The idea was mostly that X.500 was too complex because it
| also dealt with user authentication and updating the
| directory data. During the initial development the ability to
| update dircetory data was then added back and then LDAPv3
| allowed for non-password authentication using mechanism that
| is at least twice as complex as what was in original X.500.
| dboreham wrote:
| Not exactly. X.500, like all the ISO networking standards
| had two significant problems : 1. It was defined to operate
| over transport layers that nobody used. 2. Its standards
| documents had to be purchased from the ITU, so
| approximately nobody had access to them and approximately
| nobody could participate in discussions. LDAP provided a
| vehicle to tunnel X.500 into the IETF standards process,
| and onto TCP/IP networks. In the process various things
| were simplified, but the raisons d'etre were those two
| things.
| znpy wrote:
| I understand the case for the irony, but it's one of those
| situation where a tecnology can do say 1000 different things
| but 99% of the people only need like 5-10 of them.
|
| It's the same with OpenSSH, Apache httpd and and many more
| tools. Take OpenSSH as an example: it can do a lot of little-
| known things (SSH certificate authority, SOCKS proxy, port-
| forward, signing stuff and verifying signatures and so much
| more)... Yet like 99% of the people will just do "ssh somehost"
| and be done with that.
| candiddevmike wrote:
| Another project with similar goals, glauth:
| https://github.com/glauth/glauth. it's written in Go and has a
| declarative config--you can define users and groups in yaml.
| Makes it really easy to do HA and manage your LDAP estate using
| Ansible.
| kbumsik wrote:
| I was looking for an LDAP server and this looks promising.
| Thanks for sharing!
| vidarh wrote:
| It's trivial to reload openldap data from ldif, so you can
| already manage LDAP via Ansible easily enough.
| xorcist wrote:
| As a low write, high read database that use case makes sense.
| Everything can stay in git. LDIF is not a nice format to
| operate for humans, but it's not much worse than json.
|
| I don't think the criticism against regular slapd being hard
| to configure is fair. It mostly runs out of the box. The
| tricky bit is LDAP itself, choosing a schema, and that query
| language which combines extremely long identifiers with line
| noise looking syntax.
| vidarh wrote:
| Yeah, we never operated directly on the LDIF anyway. We had
| an ansible config that created, so we added a new server
| and it'd go in LDAP, and LDAP would feed the internal DNS
| and our (pre-Kubernetes) orchestration system.
|
| While I agree about the query language, the only custom
| bits above required 2-3 ready baked queries we had to
| figure out once. If you need complex queries, I absolutely
| wouldn't use LDAP, but for that use that was not a
| consideration.
| Datagenerator wrote:
| Or setup Samba and get LDAP for free and can be managed with
| Active Directory Users and Computers (ADUC)
| hdjjhhvvhga wrote:
| Thank you for this project. I don't plan to use it in production,
| but it will be interesting to test it in a small network.
| muhehe wrote:
| It says it only supports subset of LDAP, but it like to know what
| is included. Or better, what is missing.
| nitnelave wrote:
| It only implements read-only queries and bind, plus password
| modification. User creation has to go through the web UI or
| API, and custom schemas are not supported. Any esoteric feature
| is probably also not implemented.
| Jiocus wrote:
| Great work~
|
| In this space there's also Univention (based on OpenLDAP+Samba),
| which bootstraps the whole configuration from e.g. domain setup
| to joins to other server instances. Manageable through a web
| interface as well. UCS aims to be compatible with Active
| Directory(tm) - so it still comes with all the legacy complexity
| of OpenLDAP and more.
|
| If compatibility with external integrations or preexisting AD
| domains is a must-have, it's an alternative.
| lukeh wrote:
| Samba uses a home-grown LDAP server, rather than OpenLDAP.
| yuri91 wrote:
| I have been using lldap for a while (paired with Authelia), and
| it is a real godsend.
|
| I feel like I need a PhD to configure openldap, while this was as
| out of the box as it gets.
|
| Kudos to the devs!
| dmd wrote:
| I have a PhD and can't configure openldap
| znpy wrote:
| As I complained in another comment... OpenLDAP configuration
| is stored in OpenLDAP itself, so you need to know about
| OpenLDAP in order to start learning about OpenLDAP.
|
| It just doesn't make sense and I feel you pain.
|
| One great resource I've found about LDAP (in general) is
| https://www.zytrax.com/books/ldap/ ("Ldap for rocket
| scientists"). I remeber spending a couple of week(end)s going
| through that, and things started to make sense.
|
| However, again, there's no real reason for all this to be so
| complicated...
| paulmd wrote:
| > OpenLDAP configuration is stored in OpenLDAP itself, so
| you need to know about OpenLDAP in order to start learning
| about OpenLDAP.
|
| And postgres configuration is stored in Postgres, so "you
| need to know about postgres in order to start learning
| about postgres"...
|
| this is a time-honored database tradition, relational
| metadata is often itself very relational data and you can
| often get a huge amount of code reuse by utilizing the same
| handling mechanisms for the data as the metadata.
| cptnapalm wrote:
| I tried several times to use LDAP, only to fail each time.
| Except for 1 user. Then I had to figure out how to stop using
| LDAP and put his stuff in the regular authentication system.
| dizhn wrote:
| I am pretty sure openldap is easier to configure than Authelia.
|
| By the way if anybody is interested, authentik comes with an
| embedded ldap server implementation. It's not perfect but it
| satisfies the same need. Authorization & authentication.
| cassianoleal wrote:
| I configured Authelia in about 5 minutes, using glauth for
| LDAP.
|
| Authentik looks good though, it's in my queue of things to
| try.
| dizhn wrote:
| I don't use everything authentik supports but it's really
| good software and has a very responsive developer. Its
| feature list is already very impressive. When I looked at
| the comparison table on their website (later verified them
| myself) I was surprised at the things the more popular
| alternatives do not support.
| yuri91 wrote:
| Well the comparison here is between openldap and lldap. I
| would use either as a backend for Authelia.
|
| But I found Authelia reasonably simple to use too.
| lakomen wrote:
| This seems to be just want I was looking for. Right now I use
| keycloak but I'd like to have user data separate.
|
| I'm what format is data stored? How resilient is the stored data
| against corruption?
| nitnelave wrote:
| The data is stored in an sqlite database, it's very easy to
| backup/copy.
|
| I'm planning on supporting alternate DBs as well.
| ta988 wrote:
| I'm glad to see that. Dbs like opebldap are way too complicated
| for simple tasks like having multiple users for NAS' and tools in
| a small group. It reminds me of send mail with the hours of
| config.
| nitnelave wrote:
| Something cool that I didn't highlight since it's not the main
| point:
|
| The web UI uses the OPAQUE protocol to log in/store passwords, so
| your password is never sent to the server (it instead stores just
| enough information for you to provide a cryptographic zero-
| knowledge proof that you have the correct password). It's a bit
| undermined by the fact that LDAP binds use plaintext passwords,
| but I thought it would be cool to implement :)
| throw0101a wrote:
| An updated draft was just released last week:
|
| * https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque
| hangonhn wrote:
| Yeah the plaintext password thing sucks but you can mitigate
| that with LDAPS so it talks over a secure socket. The other
| choice you have is to use Kerberos to do the authentication.
| Also, thanks for the tip about OPAQUE. Going to go check it
| out.
| jdswain wrote:
| I've used SRP on a few projects, including for a large bank for
| the log in from their counter system. Once you get the
| algorithm sorted out it's quite simple and it feels a whole lot
| better than some of the password storage systems I have seen
| (and still do see) implemented.
|
| I'll have to have a look at OPAQUE, which according to
| Wikipedia is a newer alternative to SRP.
|
| Edit: Just noticed that there are quite a few more systems
| using these types of algorithms, including Apple HomeKit.
| raxxorraxor wrote:
| This is very interesting. I have build a lot of services that
| authenticate against LDAP or request user attributes (99% domain
| controllers in Microsoft land) and I believe this can be a very
| solid basis for user management for anything outside that
| plantation. Will certainly keep an eye on this.
| majewsky wrote:
| FWIW, I have another entry in the same genre:
| https://github.com/majewsky/portunus - Seems like there really is
| a lot of pain with LDAP to go around.
| sanxiyn wrote:
| Note that Portunus still uses OpenLDAP, it's just "OpenLDAP
| server is completely managed by Portunus". lldap doesn't use
| OpenLDAP at all.
| majewsky wrote:
| Correct. I was going to implement LDAP myself, like lldap
| does, but after realizing that the "L" in LDAP is a lie, I
| went with a battle-tested implementation instead.
| solarkraft wrote:
| Seems smart. All too often one wants to start out simple,
| but later realizes there's this little feature that's
| missing. This seems to provide perfect backwards
| compatibility.
| blantonl wrote:
| Does anyone actually use LDAP as a user store these days anymore?
| exabrial wrote:
| absolutely.
| geodel wrote:
| Nope. No one. Everyone uses cloud nowadays.
| ekianjo wrote:
| What do you use instead?
| mikepurvis wrote:
| A lot of SaaS services just auth against other SaaS accounts,
| like Google/Azure/Github/AWS.
|
| I don't love this state of affairs as I'd rather just use my
| password manager for everything (and it's particularly bad
| when you have a mix of on-prem stuff that does AD and then
| other cloud stuff that doesn't), but I suppose it probably
| works well for shops that use exclusively cloud services.
| laumars wrote:
| > I don't love this state of affairs as I'd rather just use
| my pass
|
| That's fine when you're a sole developer or a small team
| but the moment your organisation grows you need SSO.
|
| > and it's particularly bad when you have a mix of on-prem
| stuff that does AD and then other cloud stuff that
| doesn't),
|
| Most cloud services do support AD (eg via SAML) but hide
| that option behind an enterprise subscription.
| Jiocus wrote:
| Guess what Google, Microsoft base your SaaS auth on (can't
| speak for GH,AWS).
| Spivak wrote:
| Yeah, because there's nothing else and everything supports
| LDAP. Even if you're using some SaaS offering when it comes
| time to integrate it with off-the-shelf on-prem software the
| path of least resistance is pretty much always LDAP.
|
| And since you have to have AD/Azure AD for Windows logins if
| you want single-password (not necessarily SSO) your source of
| truth is now an LDAP server.
| stop50 wrote:
| Its extensible, standartised and available as backend in many
| products.
| hacker_newz wrote:
| Just about every major enterprise in the world?
| [deleted]
| spockz wrote:
| Interesting. Maybe we will use this as a lightweight mock of our
| ldap server for integratie tests. Or glauth mentioned by
| candiddevmike.
| KronisLV wrote:
| What do all of the people who want to work with *nix in their
| infrastructure, but also want to utilize AD and LDAP use?
|
| OpenLDAP? FreeIPA? 389 Server? ApacheDS? The project in this
| post? Or something else?
|
| I mean, is it even viable to use something like that for most
| general purpose use cases, as opposed to caving in and going with
| something running on MS software/cloud platforms?
|
| Which is the easiest to get started with and administer?
| Personally, I've used OpenLDAP in containers for a bit and
| overall the experience was pretty good. That said, I'm yet to see
| something as nice as Keycloak for managing a directory service
| (just something that you can setup in 15 minutes, that has a nice
| web UI and that has a wide variety of functionality).
| robohoe wrote:
| I've used FreeIPA with great success in the past. It really
| took care of the client onboarding and replication and hid all
| the ugly complexity behind it. UI was also pretty dang good.
| ranger207 wrote:
| AFAIK (from messing with getting Linux to authenticate against
| a university AD system a few years ago) the best-supported way
| of replicating AD in Linux is FreeIPA on RHEL, since everybody
| less corporate is probably going to use a less corporate
| protocol
|
| But Windows Server is IMO Microsoft's killer product. It's very
| good at what it does, although using it with Linux clients
| you'll be missing out on large parts of its functionality like
| GPOs, WSUS, etc
| ansible wrote:
| I had looked at FreeIPA, but support for non-Redhat systems
| seemed poor.
|
| Samba is the way to go for AD on Linux, in my opinion. You'll
| likely want to run Samba (smbd and winbind) on the Linux
| clients as well.
| mschuster91 wrote:
| If you want to utilize AD you don't have an alternative to run
| Samba, IIRC it's the only AD alternative that actually supports
| Windows clients.
|
| For anything else, OpenLDAP in Docker.
| [deleted]
| KronisLV wrote:
| > For anything else, OpenLDAP in Docker.
|
| What about managing this instance and its configuration, as
| by default OpenLDAP doesn't really come with an easy to use
| set of tools/UI?
|
| Would you use something like Apache Directory Studio
| (https://directory.apache.org/studio/) or CLI utilities?
|
| It feels to me that OpenLDAP is probably more proven than
| lldap, but lldap seems to have a nice interface to use, much
| like Keycloak and some other turn-key solutions out there do
| (just a nice example to use from a slightly different
| domain).
| jollyllama wrote:
| Looks like the frontend is Rust via webassembly. Is that right? I
| haven't seen that before. What other intermediate packages are
| used?
| nitnelave wrote:
| I'm not sure what you mean by intermediate packages, but
| roughly the main dependencies are: - Backend: sea-query to
| build the SQL queries, Sqlx to run them, actix for the http
| frontend, ldap3_proto to handle LDAP protocol, juniper for
| GraphQL - Frontend: built on top of the Yew framework. It needs
| updating but the new update is a very breaking change, so it's
| a major refactoring.
| jollyllama wrote:
| Yew framework answers my question. Thanks!
| exabrial wrote:
| Nice!!!! Definitely giving this a whirl!
|
| The only features I need in LDAP
|
| * One-way (master->RO) Replication
|
| * Standards compliance for queries/binds
|
| * Easy authentication for setup/administration
|
| * Add additional schemas (For instance, the SSH Key schema)
|
| OpenLDAP definitely makes all the above quite difficult, but it's
| doable.
|
| One esoteric feature we use of OpenLDAP is SASL delegation. This
| allows us to defer some users to Active Directory. Nice party
| trick.
| nitnelave wrote:
| Glad you like it :) It seems LLDAP is a bit more lightweight
| than you expect, though: - You could easily implement one-way
| replication on top, it's just an SQlite database, you can
| easily copy it around (or rather use the built-in `.backup`). -
| I'm not sure what you mean by standards compliance, but I've
| tried to stick to the RFCs for the small subset of LDAP that is
| implemented. - The setup and admin is one of the strong points
| of LLDAP, it's very simple :) - Additional schemas are
| currently not supported. We have some plans, but they're kinda
| longterm and definitely not any time soon. It also will
| probably be loosely-typed, essentially just allowing you to
| store arbitrary key-value pairs.
|
| SASL is a no-go, I don't plan on supporting it, it looks
| awfully complex.
| exabrial wrote:
| Agree about SASL. We could actually live without SASL, and I
| wouldn't recommend attempting to implement it. We use it
| because it's there, it's supported, and we've figured out the
| reproducible steps to set it up. It's not pretty and I can't
| believe it actually works. The codebase for it must be
| intense.
| usrn wrote:
| This sounds amazing! I'm going to have to try it out tonight.
| dingleberry420 wrote:
| Any thought about supporting SQL databases for the user backend
| with configurable queries? Would be awesome to be able to take an
| existing SQL database of users and use that to serve LDAP
| authentication queries.
| Timon3 wrote:
| This would be really cool! At my last job I implemented this
| for a simple use-case (allowing PfSense captive portal logins
| with credentials from a different system). It wasn't too hard
| thanks to ldapjs[1], but it still felt a bit hacky. Having a
| well-tested implementation with a couple of options could
| replace a lot of these special-case implementations.
|
| [1] http://ldapjs.org/
| liveoneggs wrote:
| OpenLDAP back-sql allows you to map anything you can query with
| ODBC to ldap
| inejge wrote:
| The problem is that back-sql is unmaintained (e.g., see [1])
| and only security bugs are addressed.
|
| [1] https://lists.openldap.org/hyperkitty/list/openldap-
| technica...
| mgbmtl wrote:
| According to the docs, it uses sqlite as the backend:
|
| "Currently only SQLite is supported (see launchbadge/sqlx#1225
| for what blocks us from supporting more SQL backends)."
|
| although presumably it would be better to query the graphql
| API.
| dingleberry420 wrote:
| Right, I want to hook this up to my existing postgres/mysql
| database with existing schema.
| nitnelave wrote:
| We're going to add support for more DBs (e.g. Postgres and
| MySql) in the next release, I did a lot of work on the
| underlying libraries to make that possible.
|
| However, mapping the tables/field names is not planned. I think
| it's a can of worms that I don't want to open: How do you
| populate the fields you don't know about but are mandatory when
| creating a new user/group?
|
| You could go the way of setting up a middleman service that
| listens to the binary queries to (e.g.) postgres and
| "tranlates" them by substituting the field names, but that
| seems complicated.
| dingleberry420 wrote:
| First of all, read only functionality would be good enough
| for me. Especially if it can read from a database view which
| could be backed by my other tables. I often deal with user
| databases managed by custom software which we also want to
| let be consumed by something that speaks ldap, and it would
| be great not having to synchronize stuff, instead having a
| single source of truth.
|
| So perhaps if it can read from a view with a schema defined
| by you, that would work? And perhaps for inserting/updating
| user/groups, you could require the database have a specific
| stored procedure present?
|
| Initially I was thinking about allowing templated queries,
| where the administrator can specify the field names. For
| inserts, the database will just have to provide sensible
| defaults or let the insert go through a stored procedure that
| provides such. But doing everything using views & stored
| procedures might be simpler?
| nitnelave wrote:
| I'm not a DB expert so I don't know much about stored
| procedures. Given that I'm trying to stay compatible with
| all of sqlite/mysql/postgresql, it might be difficult to
| rely on stored procedures horizontally.
|
| A read-only view would be possible, the schema is quite
| simple. If you want, you could create an issue for that!
| Keep in mind that the DB schema is more of an
| implementation detail than a public API, so I'm not going
| to consider an (automatically-migrated) schema change as a
| breaking change.
| 0xbadcafebee wrote:
| This is fantastic. LDAP servers have always been atrocious.
|
| Can anyone suggest an open source self-hosted IdP for use with
| SAML and/or OAuth? Specifically not looking for a cloud-hosted
| one, and ideally not something horrifyingly complicated like
| Shibboleth.
| ggop wrote:
| > Can anyone suggest an open source self-hosted IdP for use
| with SAML and/or OAuth?
|
| Have you tried KeyCloak?
| mrweasel wrote:
| LDAP really needs more love. Almost everything can be integrated
| with LDAP in some form, yet managing the server and configuration
| is always a bit tricky.
|
| Currently I'm trying to learn to be more productive with LDIF
| honestly is much simpler than I thought. It's a great way to do
| bulk changes and handy in scripts, but it's not a sensible way to
| do everyday interactions. Right now there aren't many good tools,
| Apache Directory Studio is rather nice, but feels old fashion and
| not the kind of tool you'd want people to interact with on a
| daily basis... Unless they understand a bit about how LDAP works.
|
| It really nice to see a new LDAP project, especially one that
| more focus on making the protocol more accessible.
|
| For those who need something simple there's also the OpenBSD LDAP
| daemon, which also works pretty well.
| easrng wrote:
| Isn't integrating everything with LDAP how we got log4j though
| dboreham wrote:
| No. We got that because someone thought it was smart to allow
| a low level library haul off and make network connections
| behind the caller's back, then someone else thought it was
| smart to execute code fetched from random network hosts.
| p4l4g4 wrote:
| I have the same experience! On the integration side of things,
| ldap is often easy to configure. Most software just works, when
| you know your parameters. The server side, however is a whole
| different story. It feels like most enterprisey implementations
| are ancient, even though they have active development going on.
| gscho wrote:
| This looks really cool and should help me out when integration
| testing things are require an LDAP connection. For example
| setting up the Jenkins ldap connector in an automated test.
|
| PS: I'm glad we no longer need to state in the title of a Show HN
| post "written in rust".
___________________________________________________________________
(page generated 2022-07-11 23:01 UTC)