cacti misreports koji disk space
by Mike McLean
For a while I would look at the /mnt/koji space graph in Cacti and say
to myself "boy, garbage collection sure has managed to slow the growth
in space usage." The graph was really leveling off.
https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&lo...
But then I realized: it's too level. If you get the csv data from Cacti,
the numbers for the last few months are identical. The data shows
2.1990232545e+12 used, which is suspiciously close to exactly 2T (and
wrong, df reports 2.7T). The free space is stuck at the same number.
Oddly the total space is reported as 4.3980465091e+12, which is almost
exactly 4T (and also way wrong, df reports 9.9T).
Anyway, given the numbers it looks like some sort of maxint issue. Does
anyone know if there is a fix?
16 years
Change freeze request: Fix invalid login pages
by Toshio Kuratomi
When I built the last python-fedora, I built the package in my working
tree instead of making a fresh branch. This means the python-fedora
package I deployed on Friday has some incompatible changes that weren't
meant to go in until the next release. This is leading people to get an
internal server error when they try to login with an invalid
username/password.
There's two options: spin a new package based off the actual
python-fedora-0.2.99.8. The diff for that would look like
bzr-0.2.99.8-current.patch.
The alternative is to only fix the problem that we know we're having
with BaseClient. The patch for that is quite a bit smaller: it's just
a few lines to change exception handling in fas2.py and
jsonfasprovider.py to use the new exception hierarchy in BaseClient.
Risk for option #1: we have had the new python-fedora deployed since
Friday and this is the only problem reported so far. The patch is
bigger than for option #2 and thus there's more room for unexpected
problems.
Risk for option #2: We definitely do not want to push this package out
to the other servers as it's likely to break error handling in clients
because of the new exception hierarchy. Since we're in change freeze
we're not likely to do that for a while.
I'm inclined for option #2. What do others think?
-Toshio
16 years
Emergency Change (app4)
by Mike McGrath
Well our change freeze isn't off to a great start. But we'll get there.
app4 was in a bit of trouble tonight and we got some alerts from slow
to respond apps. Since the xen host had it available I doubled the RAM on
app4 to help it. This seemed to be the lowest risk change and to revert
should be fairly simple.
-Mike
16 years
Change Freeze!!
by Mike McGrath
Beware the ides of April! Today is important for more then just US
taxpayers! Its change freeze time! Sit back, relax and don't change
anything!
If you have to change something (non emergency) come here first and get
permission. Explain why this change is important enough that it can't
wait until after F9 ships. Anyone in sysadmin-main can give permission
but you can't give permission to yourself.
-Mike
16 years
CVS common directory
by Christian Iseli
Dear infra people,
Just a puzzling question here. I have a complete CVS checkout of the
RPMS (since a fairly long time:
$ cat CVS/Root
:ext:c4chris@cvs.fedora.redhat.com:/cvs/extras
)
The puzzling thing is that 141 of the 5977 packages with a devel
directory have a common subdirectory in there. I.e.,:
$ ls -d */devel|wc -l
5977
$ ls -d */devel/common|wc -l
141
And the question is: why ? Is it just me, or is there some strangeness
in the CVS repo ?
Cheers,
Christian
16 years
[redhat.com #609992] need ordb.org removed from Red Hat MX mail servers (fwd)
by Mike McGrath
>From the soc (Marek!)
Hello Mike,
On Sat Apr 12 18:13:14 2008, mmcgrath(a)redhat.com wrote:
> Do you guys know anything about this?
We are not using this RBL. That message has been bounced from
mail.devin.com.br, while delivered the mail to hugo(a)devin.com.br.
Regards,
> -Mike
>
> ---------- Forwarded message ----------
> Date: Sat, 12 Apr 2008 10:01:59 -0500
> From: Matt_Domsch(a)Dell.com
> Reply-To: fedora-infrastructure-list(a)redhat.com
> To: fedora-infrastructure-list(a)redhat.com
> Subject: need ordb.org removed from Red Hat MX mail servers
>
> Bounces are getting this message:
>
> < mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on
> December 18, 2006. Please remove from your mailserver.>
>
> Whomever is responsible for Red Hat's mail servers needs to make this
> change.
>
> Thanks,
> Matt
>
>
> Your message did not reach some or all of the intended recipients.
>
> Subject: download*.fedora.redhat.com rsyncd change request
> Sent: 4/7/2008 9:44 AM
>
> The following recipient(s) could not be reached:
>
> hugo(a)devin.com.br on 4/12/2008 9:50 AM
> Could not deliver the message in the time limit specified. Please
> retry or contact your administrator.
> < mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on
> December 18, 2006. Please remove from your mailserver.>
>
>
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
16 years
Jury Duty
by Toshio Kuratomi
I've got a jury summons for tomorrow. I don't know if there will be a
chance for me to be online or working while I'm there although the
library across the street has free wireless. So I should be able to
sneak online at lunch, at least.
-Toshio
16 years
proposed MM patch: improve rsync_acl query
by Matt Domsch
mirrormanager has a query that lets the mirrors, and eventually, the
master mirrors, get the Access Control List directly from the
database. The current query is poor in several ways: it's very slow
as it uses python object walks, which results in hundreds of database
hits instead of only one. It doesn't let the user specify they want
to limit by hosts on Internet2, or only public hosts.
Patch below fixes these. The URL will work as:
http://admin.fedoraproject.org/mirrormanager/rsync_acl?internet2_only=1&p...
The arguments on the end are optional.
The mirrors are starting to use this query to populate their own rsync
ACLs. It's not critical that it go in before F9 launch, but I think
it's quite low-risk. I've tested it locally and it works as expected.
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
16 years
need ordb.org removed from Red Hat MX mail servers
by Matt Domsch
Bounces are getting this message:
< mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on December 18, 2006. Please remove from your mailserver.>
Whomever is responsible for Red Hat's mail servers needs to make this change.
Thanks,
Matt
-----Original Message-----
From: Domsch, Matt
Sent: Mon 4/7/2008 9:44 AM
To: soc-request(a)redhat.com; fedora-infrastructure-list(a)redhat.com; mirror-admin(a)fedoraproject.org; ftp+fedora(a)redhat.com; rel-eng(a)fedoraproject.org
Subject: download*.fedora.redhat.com rsyncd change request
Your message did not reach some or all of the intended recipients.
Subject: download*.fedora.redhat.com rsyncd change request
Sent: 4/7/2008 9:44 AM
The following recipient(s) could not be reached:
hugo@devin.com.br on 4/12/2008 9:50 AM
Could not deliver the message in the time limit specified. Please retry or contact your administrator.
< mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on December 18, 2006. Please remove from your mailserver.>
16 years
snapmirror status tool?
by Matt Domsch
One of the challenges to set up push-mirroring (where a tool somehow
informs mirrors that there's new content ready to be pulled) is that
we're using NetApps with snapmirroring to sync data across PHX, TPA,
and RDU. While we know when rel-eng uploads data to the netapp in
PHX, we don't know when all that data is quite synced to the netapps
in TPA and RDU.
Or do we?
http://ecserv1.uwaterloo.ca/netapp/man/man1/na_snapmirror.1.html
notes that there is a command, snapmirror status, which can be used on
the filers to determine mirroring status/progress/complete-or-not, to
each destination. I can't run this command on the filers, but with
the help of SOC, we should be able to have an automated tool that runs
this command on our behalf regularly and posts the results somewhere
that we can read the status...
If we know the status, then we can implement push-mirroring to the
various mirror tiers. Tell tier 0 mirrors when the content is done
snapmirroring and ready for them to pull. Then tell the tier 1
mirrors when the Tier 0 mirrors are done. etc.
Mike, can you file a request with SOC requesting such a tool?
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
16 years
