When generically rejecting connections, we'd prefer to signal to
users clearly that it's the firewall rejecting them. For IPv4 we
previously emitted generic ICMP "no route to host" responses, but
this tends to make it look incorrectly like a routing failure.
Switch to flagging our error responses as "administratively
prohibited" which is more accurate and less confusing. We're also
already using icmp6-adm-prohibited for the v6 rules, so this makes
our v4 ruleset more consistent.
Note that the iptables-extensions(8) manpage indicates "Using
icmp-admin-prohibited with kernels that do not support it will
result in a plain DROP instead of REJECT" but all our kernels should
have support for it these days so this isn't a concern.
Change-Id: Id423f3ec03d0c3c4e40ddef34c38f97167b173f6
Previously we were doing this weekly. Gerrit does this daily. "Split"
the difference and do gitea every other day.
We have noticed that replication to gitea can be slow at times. One idea
is that the less packed repos on the gitea side may make negotiating the
updates slower. Pack more often to see if this helps.
Change-Id: I8961007dce3e448bfdbf1c5f3e8dfc5ec8eb82fb
Instead of using the opendev.org/... logo file, host a copy from
gerrit's static location and use that. This isolates us from changes
to the way gitea serves its static assets.
Change-Id: I8ffb47e636a59e5ecc3919cc7a16d93de3eae08d
Copy static files directly into the container image instead of
managing them dynamically with Ansible.
Change-Id: I0ebe40ad2a97e87b00137af7c93a3ffa84929a2e
This currently uses a file served from gitea's staic assets; to
isolate us from changes to gitea's file layout switch this to use the
canonical file directly from system-config/assets.
Change-Id: Ibf67040af2b0a18261621a120ee26c78020e3ace
Symlink the docs logo to the canonical assets location. It looks like
it does the sensible thing and de-references the source symlink when
building, as doc/build/html/_static/opendev.svg ends up as the actual
file, not a symlink.
Change-Id: I4409c8e20601bdcb9e387d028b5df13c90d1ffa0
I can not find anywhere we use the logo-*.png files currently in the
gitea public directory. Remove these as they're all trivially
re-created via the SVG if we find we want them.
Similarly I don't see anywhere we use "opendev-icon.svg"; it is the
same as "logo.svg". This is removed.
Move the logo with text "opendev.svg" into the assets bundle (only
user of this I can find is paste.opendev.org).
Also move in the favicon.<png/svg> files
Note all these are copied back into the gitea container at the same
location so nothing will break. However we wish to have the
identified external users not rely on files served as gitea assets as
the new version of gitea will move them.
Change-Id: I4f6c64b4042a3f0a17ce4ee59ee8bd0d61648bcc
This does local backups of the nodepool zk image image data to
/var/log/nodepool on the nodepool-builders. These hosts don't get
offsite backups but we run mutliple redundant servers. This data isn't
critical as we can start from scratch, but may be useful if we don't
want to go through all that trouble.
Change-Id: I7d150df9c0d9566ef2d32167cea535e29822cfa2
We are seeing that replication tasks occasionally sit around forever and
have had to take manual intervention. One theory is that this is related
to networking between the gerrit server and the gitea servers. We don't
set maxRetries which means replication should be retried infinitely
which means if we hit the timeout we should try again. 15 minutes was
sort of arbitrarily chosen as ~twice the time it takes to clone a large
repo like nova.
Change-Id: Iec2536ad149a2e625a1f0107b9fcee3079493607
This is a bit of spring cleaning. Previously we based on images on
Buster but Bullseye exists now so give it a go.
Change-Id: Icc3d79b361e41df2f2f063993fd206ab7d992f75
To do this we also update jinja-init to bullseye and gitea seems to be
the only user of this image. The impact of this should be fairly self
contained to gitea.
Note this update isn't urgent, but good hygiene. We should coordinate
this update with the 1.15.x gitea upgrade and do them in such a sequence
that we can identify problems easily if they pop up.
Change-Id: Ia0075416a1d8a067cfecd26c03f8db9641cbcb89
This switch testing of lists.openstack.org to Focal and we make a CGI
env var update to accomodate newer mailman.
Specifically newer mailman's CGI scripts filter env vars that it will
pass through. We were setting MAILMAN_SITE_DIR to vhost our mailman
installs with apache2, but that doesn't pass the filter and is removed.
HOST is passed through so we update our scripts, apache vhost configs,
exim, and init scripts to use the HOST env var instead.
Change-Id: I5c8c70c219669e37b7b75a61001a2b7f7bb0bb6c
This uses the opendev assets bundle image created with
I3166679bde6d771276289b9d32e7e4407957b2f8.
The mount options require using BuildKit, hence the Dockerfile update.
Otherwise conceptually it's fairly simple; copy in the files from the
opendevorg/assets image rather than the file-system.
Change-Id: I36bdc76471eec5380a676ebcdd885a88d3985976
INAP mtl01 region is now owned by iWeb. This updates the cloud launcher
to use the new name and instructs the mirror in this cloud to provision
ssl certs for the old inap and new iweb names as well as updating
clouds.yaml files.
Change-Id: I1256a2e24df1c79dea06716ae4dfbcfe119c13f8
Move some common assets into a top-level assets/ directory. Services
can reference these assets via
https://opendev.org/opendev/system-config/raw/branch/master/assets/<file>
in <img> tags, etc.
Some services want to embed these into their images, but we wish to
only keep one canonical copy. For this, add a Dockerfile and jobs
that creates a simple bundle of assets in opendevorg/assets. This can
be referenced in other builds; the new BuildKit bind-mount is
particularly useful for this
(c.f. I36bdc76471eec5380a676ebcdd885a88d3985976).
Change-Id: I3931566eb86a0618705d276445fa0a5f659692ea
The Open Infrastructure Foundation's developers who maintain the
OpenStackID software are taking over management of the site itself,
and have deployed it on new servers. DNS records have already been
updated to the new IP address, so it's time to clean up our end in
preparation for deleting the old servers we've been running.
OpenStackID is still used by some services we run, like RefStack and
Zanata, and we're still hosting the OpenStackID Git repository and
documentation, so this does not get rid of all references to it.
Change-Id: I1d625d5204f1e9e3a85ba9605465f6ebb9433021
There's some more work before our consumers can switch to bullseye.
To make this process more tractable, revert the recent backport
addition, and specify that we want bullseye images from upstream.
That gets us back to where we were at the start of this. Next,
we can start building 2x images of python-base/builder and tag
them with bullseye or buster. Then the consumers can specify
which tags, then start switching.
Revert "Add backports repos to base and builder images"
This reverts commit b217e38904da3ccab6eb96251376f1635ee55d21.
Revert "Update matrix-eavesdrop for bullseye"
This reverts commit fc38c6975367c09d003474ebd7bfefc465459a06.
Change-Id: Id21681342fe5268296128c1b09436a80c46e3169
Bullseye means we don't need the backports repos. Also, the upstream
images have bullseye-backports in them already now.
Depends-On: https://review.opendev.org/c/opendev/system-config/+/800318
Change-Id: I3813068c21d06d9b182fe81efcf2e636b2170c4a
These don't install anything by default, but allow people
to easily opt-in to a backport package if they need to without
lots of extra lines of boilerplate.
The base python image is on bullseye now instead of buster. That
means the libffi version is 7 not 6.
Change-Id: I0e0c2669d838fb622422f696f73e96e409157270
The rsync mirror we were relying on ended up incomplete on a recent
sync, causing all OpenSUSE 15 jobs to fail updating the package
lists. Switch to an alternative that seems to have all the same
things for which we used the previous one.
Change-Id: I661bdbfcbc766966793cd64d7f21201879d3dbaa
There is a change (the depends on) to modify how zuul executors handle
SIGTERM. Update our executor config to preserve the old behavior of
stopping the instance immediately rather than doing a graceful stop.
If we need to we can still request graceful stops directly using the
graceful stop command.
Depends-On: https://review.opendev.org/c/zuul/zuul/+/804464/
Change-Id: I76a2646a13a71d190be265354de18468bc93184c
