Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index

1. guilhem
2. cloph


 * infratools (GitLab) deprecation
   + june 30 at the latest
   + cleaned-up repo with `git filter-branch` (need to clone again)
   + new repo, subject to manual
     inspection by infra team members, MC BoD before removing the lock
   + cloph: didn't have time to look at it yet, will do early next week
   + pending: move infra-related repos (bugzilla, gitiles, whatcanidoforlibreoffice
     etc) to /infra/*, will require changing the remote url (won't add
     symlink/redirects, we're so few right now it's doesn't seem worth it)
 * pending OS upgrades (Debian 10.4 released on May 9)
   + still 3 hypervisors to upgrade
 * salt vulnerabilities: CVE-2020-11651 and CVE-2020-11652 (postmortem)
   + as bad as it gets, gives attackers root access on the minions
   + Not affected AFAICT, *pure luck* (audit system was working and not affected
     by this)
   + measures for defense in depth (not exhaustive, suggestions welcome)
     - firewall the salt master (open master ports to intranet, our subnet only)
     - don't run the salt master as root
     - shutdown the salt master when not in use
       . guilhem: not sure how to do that
       . cloph: systemd timer to kill salt-master if there was no log activity
         in 15min or so (check if there are any pending jobs)
     - increase the job cache/log retention period
     - don't allow the master to manage itself in default operations, just like
       for other boxes needed in disaster recovery such as mail and backup
     - rekey the master and all minions (don't think it's needed but doesn't
 * cloph: georep: xfs uses a too small inode size for gluster attributes so
   gluster duplicates these (w/ rsnapshot's hardlinks), using a larger inode
   size gives a perf boost of ×4 or more
   - backups of large file systems (download archives, extensions) are much
     faster, though it can also be thanks to the fact that georep is off right
     now (and no parallel scrubbing)
 * [rdm#3097] Try out MirrorBits as replacement for MirrorBrain
   - scanning is FTP/RSYNC only, no HTTP:
     . 24 enabled mirrors without FTP/RSYNC URLs
   - 19 of these use HTTP/1.1, so no multiplexing, scanning would at best cost
     one roundtrip per file
   - (none use HTTP/1.0 so we can use the same TCP stream resp. TLS session)
   - a full HTTP-based scan (excluding .asc) would cost ~1.8k GET/HEAD requests
     . could even do a partial randomized scans if that's too slow
   - whether we scan each file or just the index.html and parse it we'd need to
     implement our own scanner
   - AI guilhem: document listing-only rsyncd setup on the wiki and point mirror
     operators to it (will be good for mirrorbrain to, HTTP scanning is slow,
     tedious and error prone)
   - AI guilhem: adapt mirrorbrain-scanner to make it work with mirrorbits
     (parsing HTML index pages)
 * Upcoming HTTP mirror deprecation:
   - chromium 81 (march) console warning, 84 (aug) warn popup, 85 (sept) block
     . 24h metrics: 2k 80, 63k 81, 150 83, <100 ≥84, no complains so far (not
       clear what would the concrete impact be with redirects)
     . currently 26 http:// mirrors vs 70 https:// , in a good position to
       disable insecure mirrors without notice if needs be
   - AI guilhem: write wiki page and invite mirror operators to deploy HTTPS on
     their site (along with the rsync daemon :-))
 * Next call: Tue Jun 16 16:30 UTC 2020


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.