FAQ
- Who runs this?
- A small group of sysadmins paying for two boxes out of pocket. It exists because the machines had spare disk and unmetered bandwidth, not because anyone is being paid for it. Best effort, no SLA, no promises about tomorrow.
- Why does the hostname resolve to two addresses?
- Both nodes carry the same tree. Round-robin DNS with a 300 second TTL is the whole load-balancing strategy — crude, but it means a drained node disappears within five minutes and no proxy sits in the data path.
- Is the certificate the same on both nodes?
- Same name, separate certificates, issued and renewed independently on each host. Pinning the certificate rather than the name will therefore break for you at some point; pin the name.
- Do you support IPv6?
- Not yet. The upstream network on one of the nodes does not route it usably, and a mirror that answers on v6 half the time is worse than one that never does.
- Are there rate limits?
- Nothing configured for HTTPS. A single client pulling a whole tree over HTTP instead of rsync will get throttled by hand if it becomes a problem, and you will get an email first if there is any way to reach you.
- A package fails its signature check. Is the mirror tampering with it?
- No—and it could not usefully: nothing here is repackaged or resigned. In practice such a failure is a stale local metadata cache or a tree mid-sync. Run the manager's cache clean, retry, and if it persists tell us which file and we will force a re-pull.
- Can you add <distribution>?
- Probably not. Adding a tree means another few terabytes and another sync window; the current set is what fits. Debian and Ubuntu specifically are not planned.
- Something is broken. Where do I report it?
- Mail ops@pkg-mirror.bulsan.site with the URL, the time in UTC and the address you resolved to. Without the address we cannot tell which of the two nodes served you.