Missed this with I483c2982a6931e7d6fc97ab82f7750b72d2ef265; this
ensure the mirror webserver exports the directory.
Change-Id: I6e14cdace213a6af6df65b8ddb09bb3a167fbf9b
This is a re-implementation of
I195ebee548071b0b89bd5bf64b251595271178ca that puts 9-stream in a
separate AFS volume
(Note the automated volume name "mirror.centos-stream" comes just
short of the limit)
Change-Id: I483c2982a6931e7d6fc97ab82f7750b72d2ef265
This reverts commit 8591ce2b5c689b5e438fc0bfe9d410be7e344fb1.
It did not click that this is written to use
/afs/.openstack.org/mirror/centos-stream as the base directory. The
mirror/ directory has volumes mounted in it -- i.e. centos-stream has
to be a new volume (and also has to be "vos released" separately, the
existing script won't do it).
The simplest way to do this is to treat this separately. I'll propose
this in a follow-on.
Change-Id: If7b8239adf7635da4f0c317287d23daf5ab0f4bf
It picks the rackspace mirror from this list
https://admin.fedoraproject.org/mirrormanager/mirrors/CentOS/9-stream/x86_64
which is present in US.
It moves base directory to centos-stream to be consistent to centos
mirrors.
We will only synchronize x86_64 and aarch64 arches as those are the only
ones used in opendev CI. We also exculde source and debug directories to
optimize space usage as those are only required for debugging purposes.
Change-Id: I195ebee548071b0b89bd5bf64b251595271178ca
It looks like 6 hours is too infrequent and is enough time for the
disk to fill up when we're busy. Instead, purge old snapshots every
2 hours, which looks like it should give us plenty of headroom with
our current usage pattern.
Change-Id: Ieb92d052e633e9326c41367442f036cc333c40f2
Marking a file as "reviewed" will update the accountPatchDb database
and test the mariadb connection.
Change-Id: Ifaee5981e0977d7d1135275e7d8a0790075f670b
In order to avoid unfortunate collisions with statically assigned
container account UIDs and GIDs, cap normal users at 9999. That way
we can set our containers to use IDs 10000 and above.
Make sure adduser/addgroup's adduser.conf gets adjusted to match the
values we set in the login.defs referenced by the lower-level
useradd/groupadd tools too. We're not using non-Debian-derivative
servers these days, so don't bother to try making this work on other
distributions for the time being.
Change-Id: I0068d5cea66e898c35b661cd559437dc4049e8f4
Cloud images bake in an ubuntu/centos/admin user then prevent root
logins. Early on in our boot process we copy authorized keys to root
then logout and back in again as root and proceed from there. This means
it should be safe to remove these "helpful" user accounts that we don't
use. Clean them up as they can only cause problems.
Change-Id: I9dc1e580cb69004f071370c21c2a5fda09e0cf5b
The mariadb container is overriding these and we can race ansible
setting them back to root and the mariadb container starting up
resulting in a sad database.
Change-Id: Ib88f6aec83e73baf95a660165d13839f7baeed3d
See I8d8ce5c62c660875d5c6eed54c686996576ec9df; mariadb containers
chown this to their internal user, we don't want to reset it.
Change-Id: If33a26438c6aa63d0ef0e02bdad6a643070be922
We are currently re-chowning the running db directories back to root,
causing havoc for the db. Drop the explicit permissions to avoid
this.
Change-Id: I8d8ce5c62c660875d5c6eed54c686996576ec9df
Gerrit 3.4 deprecates HTML-based plugins, so the old theme doesn't
work. I have reworked this into a javascript plugin.
This should look the same, although I've achieved things in different
ways.
This doesn't register light and dark variants; since
background-primary-color is white, by setting the
header-background-color to this we get white behind the header bar,
and it correctly switches to the default black(ish) when in dark mode
(currently its seems the header doesn't obey dark mode, so this is an
improvement).
I'm not sure what's going on with the extant header-border-image which
is a linear gradient all of the same color. I modified this down to
1px (same as default) and made it fade in-and-out of the logo colour,
just for fun.
Change-Id: Ia2e32731c1cfe97639de2ec0e7660c7ed583e045
We may see an archive with ".checkpoint" on the end, as described in
[1]; the short version is this that borg stamps this every 30 minutes
and may appear if a long backup is interrupted. Skip this when making
the list of archives to prune.
We noticed this on wiki-test; for clarity the list of archives looks
like
...
wiki-upgrade-test-filesystem-2021-02-16T02:56:09.checkpoint Tue, 2021-02-16 02:56:11 [c444a0765e5791f3f68f08624d1efd80bf8a3ebc96bb225f08e4013befa2b460]
wiki-upgrade-test-filesystem-2021-02-16T17:45:04 Tue, 2021-02-16 17:45:06 [b901b55ac3bf9abecba024caebad5ba7cd1a966e3f00b366f6cff45feba7bdff]
wiki-upgrade-test-mysql-2021-02-16T18:35:09 Tue, 2021-02-16 18:35:11 [1d38cd3b4b1b3927b543e4ccc6c794cd3a513a70979ff025bbf303e1fe5e490f]
wiki-upgrade-test-filesystem-2021-02-17T17:45:05 Wed, 2021-02-17 17:45:07 [f665e275c0014a21b82efaece5d36525a4ce6cb423253d5bd0b1323b230fa53a]
...
[1] https://borgbackup.readthedocs.io/en/stable/faq.html#if-a-backup-stops-mid-way-does-the-already-backed-up-data-stay-there
Change-Id: Ia33f46305ef8f541efb7c7150d4bb2e977b01d46
We previously set the limit to 70200M on a ~98GB filesystem.
Unfortunately we are able to jump from the ~70GB limit to a full
filesystem before htcachclean happens to run again. Reduce the limit to
60000M to give us more headroom and hopefully avoid filling the fs
between cache clean runs.
Change-Id: I8aa45eb0c396b54dbb3ec84e5ba8fd4ec7da9e27