Xen and network issues.
by Mike McGrath
We've got issues. Many of our xen guests are experiencing tcp checksum
corruption. Research on the net suggests ethtool -K eth0 tx off will
fix the issue but it hasn't in our case. I've tried the koji guest on
many physical hosts, same issue. It's been on two FC6 dom0 hosts and a
RHEL5 dom0 host.
For now I'm going to stick koji on app1 as a physical host. Just
because that box has gotten to the point where it becomes unusable and
we cannot have that happening right now.
I've contacted some internal xen developers, some guys in ##xen on
freenode and the Fedora-xen list. Anyone who is able I'd encourage you
to take a look as well. Simple test:
"tcpdump -vvv | grep incomplete"
You'll see:
06:34:20.135530 IP (tos 0x0, ttl 64, id 39370, offset 0, flags [DF],
proto: TCP (6), length: 40) nat-pool.fedora.phx.redhat.com.49457 >
publictest8.fedora.phx.redhat.com.http: P, cksum 0x76af (incorrect (->
0x6100), 601:601(0) ack 6801 win 597
-Mike
16 years, 11 months
motd+puppet
by Mike McGrath
I'm going to deploy some sort of motd on the servers using puppet
today. Mostly just so people that log in understand how puppet works
and to remind them that their changes will go away unless done properly.
This has slight risk of breaking scripts. Particularly ones running
over ssh. Let me know if anyone sees something... odd.
-Mike
16 years, 11 months
Ready to learn, and contribute.
by Kelsey Hightower
Hello,
My name is Kelsey Hightower, I am 26 years old and in live in downtown Atlanta, GA. I am a freelance IT consultant and plan to go completely open source. I am studying to take my RHCE and LPIC certs in the next couple of months.
I have a huge interest in RedHat based distros and the idea of free software. I have some experience in automating tasks using BASH, but really want to learn Python and C. I have some books, time, and wiliness to learn.
I have 2 years experience supporting Linux in some form or fashion, and a good bit of experience in configuring networks.
Well I am here to help do my part as a free software citizen and learn all that I can.
16 years, 12 months
CVS Merge Compare Logic and Commentary
by Warren Togami
http://fedoraproject.org/wiki/Infrastructure/CoreExtrasCVSMerge
I made some improvements to notting's script from this page. A few
thoughts went into this...
1) At notting's recommendation the script only looks at /cvs/dist
packages that exist as source RPM %{name} in rawhide.
2) The FC-6 specific logic was removed, because it is actually
irrelevant. We are dealing with merging of only 'devel' on Wednesday.
The script tells you with WARN statements if a package is clearly moved
from Extras to Core, or if it is ambiguous because dead.package was
never added during the move. Upon inspection a decision can be made
manually. This script can be easily reused to do the same by comparing
FC-6 to FC-6 when we merge FC-6 into /cvs/pkgs later.
3) Some packages may have moved from Core to Extras during this cycle.
The package in /cvs/dist might not be properly marked with dead.package.
But this is OK, because these would have been excluded from this copy
list because they were not packages in rawhide anyway.
4) A few of the WARN DEVEL errors can be fixed even prior to the merge.
5) The less serious WARN MOVED messages, you might even be safe just
blanket blowing away the existing /cvs/extras/rpms/$i/devel and
replacing it with the /cvs/dist version. I am uncertain about this at
this late hour though. Sleeping...
# http://people.redhat.com/wtogami/temp/rawhide-srpm-names.txt
SRPMLIST=rawhide-srpm-names.txt
for i in `cat $SRPMLIST` ; do
# Skip and warn if devel is a dead.package (SANITY CHECK)
if [ -f /cvs/dist/rpms/$i/devel/dead.package,v ]; then
echo "SANITY DEAD: $i is a package in rawhide, but marked as
dead.package in /cvs/dist"
continue;
fi ;
# Skip if devel directory does not exist (SANITY CHECK)
if [ ! -d /cvs/dist/rpms/$i/devel ]; then
echo "SANITY MISSING: $i/devel does not exist, skipping..."
continue;
fi ;
# If devel exists in both Core and Extras, figure out why
if [ -d /cvs/extras/rpms/$i/devel ]; then
if [ -f /cvs/extras/rpms/$i/devel/dead.package,v ]; then
# Package moved from FE to FC, you might be able to erase FE and
replace it with FC
echo "WARN MOVED: $i moved from FE to FC"
else
# Package was moved, but improperly marked, investigate carefully
echo "WARN DEVEL: $i is alive in both FC and FE devel, investigate"
fi
else
# No conflicts, proceed with copying
echo /usr/local/bin/setup_package $i
echo mkdir -p /cvs/extras/rpms/$i/devel ;
echo cp -rv $i/devel/* /cvs/extras/rpms/$i/devel ;
fi
done | tee cvscopy.out
16 years, 12 months
Infrastructure projects.
by Peter van der Does
I was just looking at our schedule and was wondering if that's all there
is to do. I just read in an other thread there's a lot of development
needed, but I can't really see it in the schedule nor the ticket system.
Unfortunately it's very hard for me to attend the IRC meetings due to
other responsibilities so maybe it's discussed there.
I'm also wondering what the status is of some of the projects. Where is
help needed? I can't really tell from the schedule page.
--
Peter van der Does
YIM: petervanderdoes(a)yahoo.com
16 years, 12 months
Need for Extras -> Koji import
by Jesse Keating
I thought we had a python snippit somewhere for dealing with owners.list.
Does one exist or will I have to recreate one?
Mike, can I get file (read only) level access to the extras repos? Here is
what I plan...
Crawl each arch directory, getting header information about each package such
as name, version, and release, as well as what srpm they came from. Create a
dictionary of such. For each srpm, query owners.list to figure out
who "owns" it.
Query koji for all the koji builds, get all the builds tagged with
extras-import ( a temporary tag to manage the imports ) and all the koji
users.
Iterate through the Extras base builds (n-v-r). If it doesn't exist in koji,
check to see if the package itself exists in koji. If the package doesn't
exist, check to see if the package owner exists. If not, create the owner.
Then create the package, then import the build, then tag it for
extras-import. Various other short cutting logic applies here.
This is much like what I'm doing for Core -> Koji imports, however since the
data is in a koji like db/api already it is much easier to do this.
--
Jesse Keating
Release Engineer: Fedora
16 years, 12 months
