I won't be able to make it to the meetings for a few weeks not sure
how long as I am moving
and I am also starting my second year at university. I need to sort
out getting the Internet
at my new accommodation. I need to change the project lead on the
hardware tracker to
Infrastructure Team as the developer I was working with has also
started university and is
unable to contribute until he finished his final year.
Anyways I hope to still be able to help and Ill try get on IRC but the
University I think
have this blocked, Ill also continue to update the servers via RHN. I
will be able to check
my mail daily hopefully using the university network so if anyone need
to contact me I should
be able to reply.
OK great, we should be able to setup our own SMTP server now, test it
with a different domain name, then switch when we are ready. We can put
it one of the xen hosts.
I return on Wednesday. If someone else wants to setup the xen host
before then please go ahead. mmcgrath knows the login info.
-------- Original Message --------
Date: Sun, 17 Sep 2006 14:13:09 -0400
From: Stacy Brandenburg
680 permit tcp any host 188.8.131.52 eq smtp
static (fedora-cvs,external) 184.108.40.206 10.8.34.54 netmask
Should be good to go.
Aurelien and I were quite active on creating a schema that would work
correctly for out needs. It was a good time. We were and still are
really close to something that appears to be workable. The resulting
work is at
https://admin.fedoraproject.org/wiki/Infrastructure/AccountSystem2/Schema (the link appears to be down at the moment).
We were moving onto writing the actual schema out and getting it
validated by a standards body. About that time, Aurelien moved and
hasn't talked to me about it in a while. He knew more about LDAP than I
and was going to perform these tasks.
At this point and time, I am going to move forward on the project
without him. That said, I still am not an LDAP expert and would like
suggestions and help from the group moving forward.
I am still more than willing to help out the infrastructure team.
Please don't take the stagnation of this project as a sign that I have
lost ambition to be a major part of the team.
Hey packagedb and accounts2 people,
As part of filling the test packageDB with data, I'm working on a script
that pulls information out of owners.list and enters it into the
packageDB. One of the problems is that I've got 631 errors where an
email address in owners.list doesn't match with anyone in the current
accounts system. So I need to get a handle on how we can fix these
issues both short-term and long-term.
1) extras-qa(a)fedoraproject.org is listed as qa contact on all the Extras
Packages. This field is nullable so I've decided that short term, I'll
leave this field as NULL. Long term, we can either create an extras-qa
user in the accounts system or we can ask the people in Fedora Extras
what they want to do with it. Unless there's a better idea, I'll
propose to them that we leave this as NULL and only fill the field if
there is actually someone who is the qa contact.
2) extras-orphan(a)fedoraproject.org is for packages which have been
abandoned. I thought about letting Null equate to an orphaned package
but I think we might want to be notified if someone is modifying an
orphaned package so I think setting it to an orphaned user account is
better. My long term suggestion is to create a fedora-orphan or
extras-orphan user in the account system to handle these. Short term,
I'll just set them to go to me instead (heh -- Looks like I'll only have
46 extra packages to pretend to take care of.)
3) fedora-perl-devel-list(a)redhat.com is watching all perl packages. No
matter what, we'll probably create a perl-SIG group in accounts. For
SIGs, people should sign up for SIGs in the accounts system and then
they will receive all notifications that the SIG would receive. There's
another table in the packageDB that handles that. This leads to two
long term paths: perl-devel-list will be outdated in this new scheme as
everyone interested will just get notification via the SIG. The other
path is that people still want notifications to go to the mailing list
instead of (or in addition to) subscribing themselves to the perl-SIG.
If that's the case we'll have to either create a perl-SIG user in the
accounts system or allow groups in the new accounts system to have an
email address. lyz, abompard, do you have opinions on this? Short term
I'm going to set these to being watched by a non-existent-group. We'll
have to fix that before we get group notification working.
4) other emails which are not in the accounts system: This seems to
account for 82 errors. I think that most of them are because the user's
bugzilla email address is not the same as the accounts system email
address. Long Term: Running against the AccountsSystem2 with multiple
email addresses. Short Term: I'm going to try to figure out which
addresses map to what numbers in the accountsdb. This'll be tedious but
we should be able to just make the proper entries into the accounts db
later and everything will work. One requirement this introduces to the
AccountsDB is being able to ask "for userid 12345, what is that user's
Alternate short-term ideas that will save work are welcome. Alternate
long-term ideas should make good discussion. Code is owners.py in the
bzr branch http://www.tiki-lounge.com/~toshio/fedora/fedora-packagedb/
I am not sure who disabled it, but app1 has been running with iptables
completely disabled for the past day. Please everyone keep an eye on
app1 and report any further anomalies here.
Stacy J. Brandenburg wrote:
> I do not see anything obvious. But there was a post about rate limiting
> being in place. If so that will for sure do it.
> If iptables is run without that portion (assuming iptables is doing it),
> does it reoccur?
> Jeffrey Tadlock wrote:
>> Stacy J. Brandenburg wrote:
>>> I have seen no port bounces.
>> Thanks for looking into it Stacy and posting what you saw.
>> Warren was right, I didn't want to place blame on the switch (like you
>> mentioned, the problem followed the server). I was wondering though
>> if the switch was showing anything that might indicate that it was the
>> NIC dropping the link on the server side. No port bounces probably
>> means it isn't the NIC itself dropping out.
>> Thanks again!
Due to the numerous problems that we're experiencing with fp.o mail
relaying (currently losing some mail for an inexplicable reason), bounce
handling and spam filtering, we'd like to move forward with migration to
fp.o directly handling its own mail in the colo.
We are comfortable running it within a xen guest as our load demands are
actually rather small.
We would need a new internal IP, and a public IP address with only port
25 forwarded from the outside. I will setup one of our xen guests to
use that IP and we will test it with a non-production domain name until
we are satisfied that we are ready for the fp.o migration.
IS folks, What are the steps to move forward on this?
Both before and after the data center migration to a new rack and new
switch, we have occasionally been experiencing network trouble to
Occasionally the host is inaccessible over the network, or ping
responses are erratic.
Since this happened both before and after the new switch, could this
perhaps be hardware trouble?
Any opinions of what we should do about this? Perhaps...
- More closely monitor, with ping logs over time?
- Migrate app1's job to a xen guest on xen2. I assume we have more than
enough capacity there?
Stacy will be in Arizona again later this month, so he will be able to
take a look at our hardware then.
I've updated the wiki page to my latest schema from the weekend:
And included information on how to check out revisions from a bzr
repository I've put up. I made some changes that I perceive as
tradeoffs with Elliot's original design. I think it's time to create
some of the frontend and see whether we run into those tradeoffs more
often than we think we should.
I did some more testing of the schema with TurboGears over the weekend
and I stumbled across a bug:
Basically, Foreign Key constraints are broken in the current TurboGears
stack (sqlobject is the package that maps python objects to SQL tables).
With mysql and sqlite, this doesn't matter as foreign keys aren't doing
constraint checking at all (another sqlobject bug) but postgreSQL has
working constraint checking and needs the dependency ordering patch from
the bug report applied.
I have installed eyplog but sending the log files to
into a undelivered message due to attachment limits on the mailling
list, does anyone
have the correct permissions to change the limit?
I am a volunteer. I would like to start wetting my hands with a priority
2 project. I am interested in the log monitoring project. I'm not sure how I
can be helpful though, especially that such a project does not yet have a
project lead! Unfortunately my Internet connectivity will be a little flaky
during the next 6 days (as I'm travelling) nevertheless, I will try to keep
a regular eye on the mailing list.
Kindly let me know how I can start to get involved (I already have an
Thanks and Best Regards