Nice work modernizing and hardening the infra. These days what's considered the "bare minimum" has a lot of moving pieces.
Anyway, please permit me to butt in with a small idea. The mirror setup you propose has each mirror polling the source server for changes. What about a push-centered architecture? Since rsync is equally capable of pushing changes, I'm imagining a reversal of roles in your ssh setup and having some post-update hook that rsyncs the changes to each mirror. Off the top of my head, pros: - Tighter sync between mirrors and us.metamath.org - Less network noise - Slight reduction in attack surface area on us.metamath.org cons: - Error handling becomes responsibility of the post-update hook - Might require updates to Firewall settings Thoughts? "David A. Wheeler" <[email protected]> wrote: > We currently have a few mirrors of the Metamath website (e.g., > cn.metamath.org). Their purpose > is to provide access Metamath information even if the "main" site > us.metamath.org is down. > > If you manage a Metamath mirror, please contact me! If you have an opinion > about handling mirrors, > please let me know (or post here for discussion). > > The main question is: Do we want to continue to support Metamath mirrors at > all? > Mirrors made more sense when websites were less reliable and CDNs didn't > exist. > If we stop supporting mirrors, that's one less complication. > The mirror in the Chinese mainland has the strongest case to continue, due to > the > Great Firewall of China. > > If we *do* want to support mirrors, we need to change things, as mirrors no > longer work. > Historically these copied data from "rsync.metamath.org", which was really > Norm's "us2.metamath.org" site in his house. Unfortunately, us2.metamath.org > has stopped working & it's not clear if we can get it working again. > (We managed to get off us2.metamath.org just in time!!). > In addition, the old system used an unsecured rsync connection, so we need to > change it anyway. > I want to lock it down to make it unlikely to be a serious vulnerability. > > If we *stop* supporting mirrors that'd be one less complication & effort. But > if we > want to continue supporting mirrors, then we need to make them actually work > :-). > > Below is the current state & my proposed plan *if* we want to continue to > have mirrors. > > --- David A. Wheeler > > ============= > > First, the current state. The *working* metamath mirror sites are > (not counting us.metamath.org and us2.metamath.org): > - at.metamath.org Secondary mirror (Austria) [courtesy of Digital > Solutions Marco Kriegner] > - cn.metamath.org Secondary mirror (China) [courtesy of caiyunapp.com] > - de.metamath.org > > They use rsync to synchronize their data. Rsync is a great protocol when > combined > with ssh, but using it *without* ssh over the public internet is a terrible > idea. > > If we continue to support mirrors, I propose configuring a special account for > synchronization. Mirrors would each log in using ssh and their specific > private SSH key. > They'd log into a restricted account specific to that mirror > via ssh in a way that provides read-only access to only the > mirrored public files (the program "rrsync" can restrict what access is > allowed to rsync). > > Here are my proposed configuration: > > * Every mirror would create a public/private keypair & send the public key to > me. > * For each mirror we'd create a new account on us.metamath.org (e.g., > "mirror.cn") > * That account's /home/mirror.cn/.ssh/authorized_key would be modified to > this: > command="/usr/bin/rrsync -ro /var/www/us.metamath.org/",restrict ssh-rsa > {PUBLIC_KEY} > .. .this forces ssh logins to run the restricted rsync to read-only mode > for JUST the mirror directory, > restricts (eliminates) all other ssh access, and uses ssh-rsa for login. > We could use a different key pair algorithm. Note that the PUBLIC_KEY will > be public, > but that's fine!! > * Ensure nothing in its .ssh dir can be easily changed: chmod -R a-w > /home/mirror.cn/.ssh > * Disable any other kind of login with: chsh mirror.cn -s /bin/nologin > * Note: The "rsync" daemon will *not* be enabled; the only way to access this > is to > log in via ssh. It's not wise to run a bare rsync nowadays. > * The mirrors would periodically run an "rsync -e ssh -a > [email protected]:/var/www/us.metamath.org/ > /var/www/cn.metamath.org/". > Rsync is clever about updates, so this would typically be extremely fast > unless the internet link is bad. > > This would make mirrors log in - mirrors can make us do "extra work" so we > don't want just anyone > to be able to mirror. However, these steps will mean that the only thing the > mirrors can do is make us > do extra work to serve public info... making the accounts > not-very-interesting. > > I haven't actually tried to *implement* this configuration, so there may need > to be some tweaks & changes, > but that's the general idea. > > Some info sources: > * > https://serverfault.com/questions/965053/restricting-a-ssh-key-to-only-allow-rsync-file-transfer > * > https://www.whatsdoom.com/posts/2017/11/07/restricting-rsync-access-with-ssh/ > * http://gergap.de/restrict-ssh-to-rsync.html -- You received this message because you are subscribed to the Google Groups "Metamath" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/metamath/2KCXE08BUUZSA.21K7AF4J0PLBP%40wilsonb.com.
