Hi all
by Harsimran Singh
Hi all,
This is my first message to you all. I am new to the Project Fedora. I am
writing to you all if there is anything for someone who is just starting up.
I am would like to part of it, I am more into sys administration so anything
jr level work I can perform please let me know or if there is another
approch to it. Please guide me.
Thank you all in advance
Regards,
Sunny
15 years, 1 month
Introduction to the Infrastructure Group
by Asgeir Frimannsson
Hi all,
As requested on the 'Getting Started' page, here's my [1] introduction to the
list:
My name is Asgeir (asgeirf on IRC). I am working part-time with Red Hat
(eng-i18n, Brisbane, Australia) and otherwise spend much time completing a
PhD investigating the role of context in translation reuse...
My primary interest (at this point) within Fedora is localisation and
translation 'engineering'. I hope to help great people like Dimitris Glezos
maintain and develop the translation infrastructure (status pages, transifex)
and the translation tools.
cheers,
asgeir
[1] http://fedoraproject.org/wiki/AsgeirFrimannsson
15 years, 1 month
Postgres Vacuum Update
by Toshio Kuratomi
* vacstats has collected stats on all of our databases except koji
* vacstats.py now has an analyze mode. You can use it to create a
reasonable default vacuum policy.
* I've used vacstats to construct vacuum scripts for all of our
databases except koji. I've pushed them out to db2 and am watching them
to make sure that they run fine today. I don't anticipate a problem
but I'll have to evaluate whether to add a weekly script or turn the
dailies into every other day vacuumings once we add the koji tables.
* We've added three tables from koji to the hourlies since we know that
they are high update tables that need to be vacuumed frequently.
* The vacstat.py check mode now checks if we're in danger of running out
of transaction ids and prints a warning that should be emailed to
admin(a)fp.o if so. Dealing with that is a matter of performing a vacuum
of that particular db (rather than table by table). If the database
happens to be koji we might want to schedule that for the weekend as the
weekend is the lowest use time for koji. (Note -- it will result in a
slow down, not in an outage.)
Thanks to mbonnet for the information on the tables and queries for the
latter two points.
At this point the things left to do are:
* Get the rest of koji vacuuming integrated into the scripts. I'll be
doing this in the next few days.
* Find a time when we can do a vacuum full of some tables. The current
vacstats algorithm suggests the following tables:
Vacuum full mirrormanager host_category_dir: Freespace Percent
96.8641231524%, 735480624.0 Bytes
vacuumdb -zfd mirrormanager -t host_category_dir
Vacuum full mirrormanager host: Freespace Percent 99.9622089944%,
81626948.0 Bytes
vacuumdb -zfd mirrormanager -t host
Vacuum full mirrormanager directory: Freespace Percent 89.7076945051%,
7515728.0 Bytes
vacuumdb -zfd mirrormanager -t directory
Vacuum full bodhi package_update: Freespace Percent 17.634592656%,
311544.0 Bytes
vacuumdb -zfd bodhi -t package_update
Vacuum full fassession visit: Freespace Percent 88.6180520143%, 554520.0
Bytes
vacuumdb -zfd fassession -t visit
* Decide whether to upgrade postgres from 8.1 to 8.3. This has been
recommended by several postgres people but there's extremely little
chance that 8.3 will be going into RHEL5 so we'll have to decide whether
to move to F9, backport a package to RHEL5 or just stay with 8.1 for now.
-Toshio
15 years, 1 month
infrastructure news ready for FWN#118
by Huzaifa Sidhpurwala
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
News from fedora-infrastructure-list is ready for FWN#118
- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)
Help Desk APAC Team Lead,
Research and Development Lead,
Global Help Desk, Pune
Phone: +617 3514 8125 (UTC +5.5)
GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5
Visit the Help Desk portal at : http://helpdesk.corp.redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHpqkszHDc8tpb2uURAjuiAJ4+kqghHF0zmjJuUikC1TjzxdvqTgCfTyFS
xQz0Q1egNgPbrInMf7NdcgE=
=+/Fp
-----END PGP SIGNATURE-----
15 years, 1 month
fedora.org?
by Anand Capur
Is there any way we can get this domain back? Is Fedora a registered
trademark of ours? I think it would much be better on our site, instead of
yeah, you know what I mean. (See fedora.org)
-Anand
15 years, 1 month
Apache Test Page
by Anand Capur
Do you think we should add something like this to the bottom of the test
pages, so MAYBE people will understand that we don't own the websites?
Note:
Fedora is an Operating System and it is used to power this website; however,
the webserver is owned by the domain owner and not Fedora. *If you have
issues with the content of this site, contact the owner of the domain, not
Fedora!*
Unless this server is on the fedoraproject.org domain, Fedora doesn't have
anything to do with the content on this webserver or any e-mails that
directed you to this site.
For example, if this website is www.example.com, you would find the owner of
the example.com domain at the following WHOIS server:
http://www.internic.net/whois.html
What do you think? I got that from the CentOS test page.
-Anand
15 years, 1 month
Safe to upgrade
by Toshio Kuratomi
I've built a new python-json that should fix the issues that nirik
reported earlier with JSON calls failing. When it shows up in the EPEL
repository it should be safe to upgrade the app servers to this version.
Unsafe: python-turbojson-1.1.2-1.el5
Safe: python-turbojson-1.1.2-3.el5
-Toshio
15 years, 1 month
download1 is out of sync with the others
by Chuck Anderson
download1 is missing some files and showing the "file has vanished"
thing again. download1 seems to be plagued with ongoing problems. Is
anyone looking into these issues? Every time I report them, I get no
response from anyone who knows what might be happening. If I need to
report these somewhere else, please tell me where. Thanks.
-bash-3.1$ rsync rsync://download1.fedora.redhat.com/fedora-enchilada/linux/updates/7/x86_64/ | grep groff
file has vanished: "linux/updates/7/x86_64/groff-1.18.1.4-7.fc7.x86_64.rpm" (in fedora-enchilada)
file has vanished: "linux/updates/7/x86_64/groff-gxditview-1.18.1.4-7.fc7.x86_64.rpm" (in fedora-enchilada)
file has vanished: "linux/updates/7/x86_64/groff-perl-1.18.1.4-7.fc7.x86_64.rpm" (in fedora-enchilada)
-bash-3.1$ rsync rsync://download2.fedora.redhat.com/fedora-enchilada/linux/updates/7/x86_64/ | grep groff
-rw-r--r-- 1996248 2008/01/28 12:41:17 groff-1.18.1.4-8.fc7.x86_64.rpm
-rw-r--r-- 42977 2008/01/28 12:41:25 groff-gxditview-1.18.1.4-8.fc7.x86_64.rpm
-rw-r--r-- 23997 2008/01/28 12:41:27 groff-perl-1.18.1.4-8.fc7.x86_64.rpm
-bash-3.1$ rsync
rsync://download3.fedora.redhat.com/fedora-enchilada/linux/updates/7/x86_64/ | grep groff
-rw-r--r-- 1996248 2008/01/28 12:41:17 groff-1.18.1.4-8.fc7.x86_64.rpm
-rw-r--r-- 42977 2008/01/28 12:41:25 groff-gxditview-1.18.1.4-8.fc7.x86_64.rpm
-rw-r--r-- 23997 2008/01/28 12:41:27 groff-perl-1.18.1.4-8.fc7.x86_64.rpm
The missing files I've noticed:
fedora/linux/updates/7/x86_64/groff-1.18.1.4-8.fc7.x86_64.rpm
fedora/linux/updates/7/x86_64/kernel-2.6.23.14-64.fc7.x86_64.rpm
fedora/linux/updates/7/x86_64/libacl-2.2.39-7.fc7.x86_64.rpm
fedora/linux/updates/7/x86_64/bash-3.2-20.fc7.x86_64.rpm
fedora/linux/updates/7/x86_64/acl-2.2.39-7.fc7.x86_64.rpm
15 years, 1 month
app4, back online
by Mike McGrath
I had been waiting for the transifex deps before bringing app4 back online
but decided not to wait any longer. pkgdb, smolt and mirrormanager are
all running from this box. My hope is this additional capacity will help
quell the nagios alerts we've been getting over the last couple of days
with the ultimate goal of getting the next smolt version out (which has
some more efficient sql in it.... Its monthly checkin time.
-Mike
15 years, 1 month
