[Fedora-infrastructure-list] Today's meeting and Logs
by TomLy
Due to my work schedule, I will be unable to catch most of today's meeting. The log for the meeting is sometimes sent to this list, but it has been inconsistent. Can something be worked out to automatically record the log and mail it to the list?
~tom
17 years, 7 months
[Fedora-infrastructure-list] xen1/xen2 Networking Note
by Warren Togami
I just wasted a bit of time figuring out why guests were unable to use
the network. xenguest-install tries to use xenbr0 by default, while
xenbr1 was created on our servers because we are using eth1.
Just a note for later if others install xen guests.
For now, still attempting to make a single guest install work...
Warren Togami
wtogami(a)redhat.com
17 years, 7 months
[Fedora-infrastructure-list] Package DB TurboGears/SQLObject schema
by Toshio Kuratomi
Greetings all, Elliot in particular,
I started to parse the owners.list file in preparation for setting up
some sort of ACL system on the new VCS and decided to look into how this
is going to interact with the PackageDB. For starters, I took the
TurboGears schema that Elliot posted and added comments.
Are the comments in this file accurate? Can you explain what the
"status" fields in the *History classes represent?
-Toshio
17 years, 7 months
[Fedora-infrastructure-list] fp.org Mail Server Bounce Issue
by Warren Togami
Problem
=======
Currently all incoming mail goes through redhat.com and is relayed to
the internal fp.o server on bastion, which handles alias forwarding.
This became more than an annoyance when a distributed bot-net began
flooding mail to random addresses at fedoraproject.org. Since redhat
accepted original delivery and fp.o was correctly rejecting it,
postmaster redhat was receiving the thousands of bounces.
Short-Term Solution
===================
All valid addresses at fp.o are now auto-generated into a whitelist
contained in /etc/mail/access.db from the auto-generated /etc/aliases
file. This could be further cleaned up to generate access.db
simultaneously as aliases, however it might not be worth doing because
this is a poor long-term solution.
All other mail destined for fedoraproject.org with unknown users will be
discarded without bounces. Additionally, this was added to the
sendmail.mc. (not yet checked into CVS)
diff -urN /tmp/sendmail.mc sendmail.mc
--- /tmp/sendmail.mc 2006-09-04 21:15:55.000000000 -0700
+++ sendmail.mc 2006-09-04 21:02:33.000000000 -0700
@@ -49,6 +49,7 @@
FEATURE(`use_cw_file')dnl
FEATURE(`use_ct_file')dnl
FEATURE(`access_db')dnl
+FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl # mail hub for fedora.redhat.com setup
"blacklist_recipients Turns on the ability to block incoming mail for
certain recipient usernames, hostnames, or addresses. For example, you
can block incoming mail to user nobody, host foo.mydomain.com, or
guest(a)bar.mydomain.com. These specifications are put in the access db as
described in the Anti-Spam Configuration Control section later in this
document."
Please keep an eye out for failures in fedoraproject.org alias mail
delivery. We will be using this automatically generated access.db
whitelist until we deploy the ideal long-term fp.o mail solution.
Long-Term Solution
==================
Both Red Hat IS and Fedora Infrastructure team want fedoraproject.org to
directly handle its own mail. This will give us greater flexibility in
mail service maintainability as well as spam filtering. This would save
everyone time by dramatically reduce the amount of spam going through
our system. OTRS queue maintainers would also be less burdened due to
less spam crap.
While redhat cannot do full greylisting due to business concerns, I
personally want to be totally BOFH with greylisting. =)
(Infrastructure team would need to vote on this one as it is indeed
controversial.)
Due to the security considerations of running more than a dumb
forwarder, we will need to isolate the mail service from bastion. This
would mean a small network topology change, and maybe additional
hardware. I will be working on this in the coming weeks.
Thanks to Matthew Galgoci for his help in fixing this.
Warren Togami
wtogami(a)redhat.com
17 years, 7 months
[Fedora-infrastructure-list] Cyclades escape characters
by Mike McGrath
Just so we all can remember
Press the spacebar to pause...
KEY MAPPING FOR CONSOLE REDIRECTION:
Use the <ESC><0> key sequence for <F10>
Use the <ESC><@> key sequence for <F12>
Use the <ESC><Ctrl><M> key sequence for <Ctrl><M>
Use the <ESC><Ctrl><H> key sequence for <Ctrl><H>
Use the <ESC><Ctrl><I> key sequence for <Ctrl><I>
Use the <ESC><Ctrl><J> key sequence for <Ctrl><J>
Use the <ESC><X><X> key sequence for <Alt><x>, where x is any letter
key, and X is the upper case of that key
Use the <ESC><R><ESC><r><ESC><R> key sequence for <Ctrl><Alt><Del>
-Mike
17 years, 7 months
[Fedora-infrastructure-list] coverity code checker in Extras
by Max Spevack
The folks over at Coverity have offered to allow Fedora Extras to use
their services, and would like a yes or no. Rather than make this
decision in a vacuum, I believe that the Fedora Extras Steering Committee
has earned the right to make this decision for themselves.
If we can get a decision by the end of the week, that would be great.
What follows is my own analysis, for whatever it's worth.
PROS
+ It's good technology, and has been used in Linux projects previously
with success. Google "coverity linux" or something similar.
+ If we act on the results, it could be a great boon for the FE code
quality in general.
+ It doesn't cost us anything.
+ It forms a relationship between Coverity and Red Hat, and sets the table
for more work partnership later, if things go well.
+ Bugs are bugs, and flaws are flaws. We should be happy to know about
them, however they are found, and we should fix them.
CONS
+ It's not open source, but there is no free alternative that can do the
same thing.
+ We need to make sure it doesn't disrupt or break our build system too
much. So that will require some technical work and time from certain
folks.
My gut is that we should say that we're interested, and start hashing out
the technical details of how it will all work with them.
If we go ahead, I think that in addition to the Board, someone in FESCO
needs to "own" this and be our point person for technical questions, etc.
Thanks,
Max
--
Max Spevack
+ http://fedoraproject.org/wiki/MaxSpevack
+ gpg key -- http://spevack.org/max.asc
+ fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21
17 years, 7 months
