Anacron job 'cron.daily' on linode01.ovirt.org
/etc/cron.daily/0logwatch: gzip: stdout: No space left on device system zcat failed: 256 at /usr/sbin/logwatch line 896.
--=-bqYeIiOBZYnm97q1lxSE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mercredi 02 juillet 2014 =C3=A0 04:40 -0400, Anacron a =C3=A9crit :
/etc/cron.daily/0logwatch: =20 =20 gzip: stdout: No space left on device system zcat failed: 256 at /usr/sbin/logwatch line 896.
So, some cleaning was done this morning by Eyal and Ewoud on the server, and by me yesterday to get a few meg.=20 We are now at 2.4G, but discussing with Eyal on irc, we proposed to move the mailling list ( ie archive and stuff ) to a VM on alterway ovirt installation. This may be disruptive, and since that's not in puppet, it may take longer than I wish. So I propose to install the services, but not declare them as being MX, do some testing. Then once the lists are on the new list server, stop mailman on the current server, put it as secondary MX put the first one as primary MX and migrate over. This should free 4G, but more importantly, this would split the download server from the ml, which mean that download server being full will not stop communication around the project anymore. Any comment on this ? --=20 Michael Scherer Open Source and Standards, Sysadmin --=-bqYeIiOBZYnm97q1lxSE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJTtAX9AAoJEE89Wa+PrSK9CeIP/2TdwGF781AwRlXcgCJ8WLdZ 417GjnoQTLaJQRrLubCAWjl/Q8StGDi+L41XeT/Bl2RtmLDcq/6Swajaag7aEGel YYQTxtRv4iwS6pa19dpyNXQDg1so6slX+1vkwD+AIAHK+8g+Tg8kBsmm0rBYeo6/ q3TLsthdpIkJx9GfZyvaB49Zq6jA/bzHvoiTF1SYsA64NAc6wNAmk0jl4d9UWY0C kxLOZy9QFpCUb2eLEyMezx9roiG0ygf5Ool1XfNiwe+W0EQvDn8GLsKOjaOQASw/ Myk6Ia2fWlymzHOy5aQlUxer84z2cHoUdxRk1B2hc0WQSOELRF5SoH0TgnDIrFe8 DH339JEWm0+0tpPtoCBkJq12+U1zO1jaDZ6e0g051PoX0qGIiZdetz+72bdi5oQt 5K5c/g/69IQOhWkY3f4kv+3UxK97Ztuyam+n0OogV5FJBgcpiSRXS6oDfxbV3AXx lVLB2lcCgMw1nNNzRaKtnSm3Ch1cExGaZM/uJA5TL8rHk5nh2cNuLt/Yflc/G6rx fGr7c1BYmMnp5LIgBwT/HInvVxt0g+Qjhe8cvMWx8Mb5eXBbIiNDa5YM4r1dlVIj ipfD//OFKV71e6WvTc57uRi0BFK7Sh1L7VFxVWFYFunozS8oonG3iGoV0ZseOjD0 5nAIEQFPp5ty5ETXWrkq =WpFm -----END PGP SIGNATURE----- --=-bqYeIiOBZYnm97q1lxSE--
On Wed, Jul 02, 2014 at 03:15:40PM +0200, Michael Scherer wrote:
Le mercredi 02 juillet 2014 à 04:40 -0400, Anacron a écrit :
/etc/cron.daily/0logwatch:
gzip: stdout: No space left on device system zcat failed: 256 at /usr/sbin/logwatch line 896.
So, some cleaning was done this morning by Eyal and Ewoud on the server, and by me yesterday to get a few meg.
We are now at 2.4G, but discussing with Eyal on irc, we proposed to move the mailling list ( ie archive and stuff ) to a VM on alterway ovirt installation.
This may be disruptive, and since that's not in puppet, it may take longer than I wish. So I propose to install the services, but not declare them as being MX, do some testing.
Then once the lists are on the new list server, stop mailman on the current server, put it as secondary MX put the first one as primary MX and migrate over.
This should free 4G, but more importantly, this would split the download server from the ml, which mean that download server being full will not stop communication around the project anymore.
Any comment on this ?
Since I have no experience running mailman so I can't estimate all the risks, but you you should pay attention to IPv6. linode01 does have an AAAA record and at alterway we do not have IPv6. Should be fine because of CNAMEs, but can't hurt to check. Other than that I think we should upgrade alterway02. I think the oVirt version there isn't the most recent and any disruptive upgrades should be done before anything end-user facing runs there.
On Wed, Jul 02, 2014 at 03:34:38PM +0200, Ewoud Kohl van Wijngaarden wrote:
Other than that I think we should upgrade alterway02. I think the oVirt version there isn't the most recent and any disruptive upgrades should be done before anything end-user facing runs there.
Today we upgraded alterway02 from oVirt 3.2 to oVirt 3.4, but we still need to reboot for a newer kernel. Is there a good time for this? Affected services: - alterway02.ovirt.org - foreman.ovirt.org - monitoring.ovirt.org - stats.ovirt.org
participants (3)
-
Anacron -
Ewoud Kohl van Wijngaarden -
Michael Scherer