Originally added as: d03a23530d
Though that commit was probably related to OpenStack networking we had
those days. The traffic from Copr builders will have to be filtered-out
based on a specific UserAgent (or something alike), once we are on
the issue https://pagure.io/copr/copr/issue/1263
Currently gmail is throttling emails from fedoraproject.org, so the new
user tokens time out before they reach the new user. Bump this up to an
hour for now until the gmail issue is over.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
There were plenty of changes till the last release and this commit is
updating the current production configuration to reflect changes made
for staging.
Release of the-new-hotness 1.0.0.
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
nosync has some glibc symbols that break when doing older chroots on f35
hosts. This breaks epel7 builds for example.
https://bugzilla.redhat.com/show_bug.cgi?id=2019329
So, until thats sorted, disable nosync
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The buildhw-x86 blades also can enable serial console for ipmi/sol.
Rework this to handle the fedora case of options not being in
/etc/grub2-efi.cfg anymore.
Also set both serial S0 and S1 enabled, since some hardware seems to use
one and some uses the other.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
I haven't realized this can actually be done (mod_accesslog supports
error.log, too). And this finally _should be_ the working solution
for now. At least till we rework the hitcounter entirely, to also
support the AWS CloudFronts logs:
https://pagure.io/copr/copr/issue/1263
This will allow us to never reload the Lighty server processes for the
log rotation purposes, which turned out to be very problematic for no
obvious reason. Simply, when the Lighty server is under certain
"production" load (not reproducible via /bin/ab), Lighty fails to reload
(both on SIGHUP and SIGUSR1 signals). Something simply hangs the
processes.
If I had to guess, writes to the pipe to the cronolog process are
blocked causing some weird deadlock? Since we still have to SIGHUP the
cronolog process, Lighty fails to handle both (a) SIGHUP/SIGUSR1 and (b)
detect cronolog exitted at the same time? But I'm tired of the
debugging this now.
This is just cleaning up the mess of the bad parameter from
earlier, run of this play broke halfway through, need to do the
remaining half without choking on this part.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
For some reason here the bridge has a different mac address than the
interface that it's using to talk to the network.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This unifies prod and stg onto the ways of doing things for the
latest packages, and rejigs the swtpm stuff a bit to tear down
more (we shouldn't need the custom SELinux policy any more).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Right now we are running a special docker on osbs nodes that allows it
to actually work with f35+ containers. Without this glibc does a syscall
that docker doesn't understand and just blocks, breaking (at least) dns
resolution in the container. So, until we move these nodes from rhel7,
we are going to have to deal with this.
In addtion to excluding this, if it ever gets mistakenly upgraded, you
need to downgrade and then: remove
'--seccomp-profile=/etc/docker/seccomp.json \' from
/usr/lib/systemd/system/docker.service
do 'systemctl daemon-reload'
do 'systemctl restart docker'
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
