Updated FAS => BZ scripts
by Toshio Kuratomi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I've updated our Account system to bugzilla sync scripts to use
bugzilla's xmlrpc interface to work with the migrated bugzilla instance.
I tested the db side of these changes on the FASv1 instance on
publictest1 and the scripts on the Red Hat test bugzilla instance.
Everything appeared to work but there could always be errors so if you
hear of the following symptoms, let me know:
- - New Fedora Accounts that have fedorabugs or cvsextras are not able to
make changes to Fedora bugs in bugzilla. (For instance, to review
packages).
- - Ditto for existing accounts that suddenly lose this ability.
- - People who have had their fedorabugs access revoked but can still make
changes to Fedora Bugs for which they are not the owner.
The new system implements a queue in the account system database that is
updated whenever someone is approved or removed/unapproved for the
fedorabugs group. Adding to the queue is performed by a postgresql
trigger defined in the cvsacct.sql[1]_ file. cron (on an internal Red
Hat box for historical reasons... we can probably move it to an
infrastructure box now that we're using xmlrpc) runs the
export-bugzilla.py[2]_ script every hour and processes the queue of adds
and removes.
The script which adds new packages to bugzilla was updated several weeks
ago as part of the package db migration. However, it had to be updated
again for the bugzilla migration as a URL had been changed and some
error reporting code wasn't inclusive enough. If you see new packages
being created or branched with no bugzilla component being created let
me know that there's a problem with bz-make-components-pkgdb.py[3]_
*Note* package changes are synced by cron every six hours. So you have
to wait six hours from the creation of the new package to know if
there's a problem with the sync.
.. _[1]:
http://cvs.fedoraproject.org/viewcvs/fedora-accounts/cvsacct.sql?root=fed...
.. _[2]:
http://cvs.fedoraproject.org/viewcvs/fedora-accounts/export-bugzilla.py?r...
.. _[3]:
http://cvs.fedoraproject.org/viewcvs/fedora-accounts/bz-make-components.p...
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG0LtOX6yAic2E7kgRAgxCAKCa6NqgY4IN3O7nDo1ZtqUbHlOLegCdH+dQ
sNZOrKWvrK4CGs7H2y+wYPs=
=1o8V
-----END PGP SIGNATURE-----
16 years, 8 months
[RFC] New hosted projects
by Paulo Santos
Hi guys,
In todays meeting, there was the question about how to process and evaluate
new hosted space/projects.
Currently:
user go to trac, open a ticket and assign it to jkeating
Future:
user send an email to the list, we discuss it, evaluate it and approve/deny,
then user go to trac and open a ticket but don't assign it.
a member of the infrastructure (or some group for that effect) will pickup
the ticket and deploy it (like we do with the approvals)
I'm sure that jkeating has his hands full with other stuff, and doesn't have
the time to keep looking to the queue.
So if we can help, i say we should.
Comments ?!
Paulo
16 years, 8 months
Infratructure Meeting Log for 2007/08/23
by Jeffrey Ollie
[15:02] mmcgrath has set the subject to Infrastructure -- Role call
[15:02] mmcgrath: Who's here?
[15:02] * lmacken
[15:02] jeremy has left (Remote closed the connection (i=ikatzj@nat/redhat/x-85aceb302d31e828))
[15:02] warren has left (Remote closed the connection (i=warren@redhat/wombat/warren))
[15:02] * ricky
[15:02] paulobanon: pong
[15:02] * londo is here
[15:02] * yingbull is here
[15:02] mmcgrath: crazy, that happened at this same time last week (jeremy and warren logging off right as the meeting started.
[15:03] * ricky is.
[15:03] paulobanon: yup
[15:03] abadger1999: yes
[15:04] mmcgrath has set the subject to Infrastructure -- Tickets
[15:04] mmcgrath: https://hosted.fedoraproject.org/projects/fedora-infrastructure/query?sta...
[15:04] mmcgrath: paulobanon: Ticket #52, whats up?
[15:04] paulobanon: k so
[15:04] paulobanon: im going with mod_cache all the way for now
[15:04] jcollie: oops i'm here
[15:05] paulobanon: we are currently using mod_cache_disk and _mem
[15:05] paulobanon: and hopefully during the weekend or early next week start stress testing
[15:05] paulobanon: and see what is improved, and what can be improved
[15:05] paulobanon: thats it
[15:05] mmcgrath: Cool, good to hear thats still making progress. Will we be able to implement for Fedora 8?
[15:06] paulobanon: YUP
[15:06] paulobanon:
[15:06] mmcgrath: fantastic
[15:06] paulobanon: thats the plan
[15:06] mmcgrath: cool, anything else or we'll move on.
[15:06] jeremy has joined the group chat (i=katzj@nat/redhat/x-6c63cab4c75caa85)
[15:06] paulobanon: move one
[15:06] mmcgrath: k
[15:07] mmcgrath: ticket #14 - Choose New VCS for Packages
[15:07] mmcgrath: jcollie: any word?
[15:07] jcollie: nope... semester starts next week
[15:08] mmcgrath: k, no worries. We'll move on.
[15:08] mmcgrath: ticket #31 - The wiki
[15:08] * ricky doesn't have much to say about the wiki either
[15:08] mmcgrath: ricky: should we remove the meeting notice on that ticket?
[15:08] stahnma: I added a thought on the ticket
[15:08] stahnma: but, it doesn't change the status
[15:08] stahnma:
[15:08] ricky: mmcgrath: Sure, I hope to be working on FAS2 for a while :
[15:08] ricky: **
[15:09] mmcgrath: stahnma: feel free to talk about it. your concern was that we not automatically disclude PHP based wikis right?
[15:09] stahnma: yes
[15:09] abadger1999: yay!
[15:09] paulobanon: \o/
[15:09] abadger1999: Err... Not pp
[15:09] abadger1999: php
[15:09] abadger1999:
[15:09] stahnma: I just think that autocutting PHP is a bit short-sited
[15:09] stahnma: it might not make it for other reasons
[15:09] stahnma: but security for PHP is more of a rep basedon PHP apps, not PHP itself
[15:09] stahnma: yes, it's very easy to code bad php
[15:10] mmcgrath: One thing to keep in mind is that we don't have php anywhere else (or java for that matter) so it does make them less attractive.
[15:10] stahnma: true
[15:10] stahnma: that's a valid point
[15:10] * ricky mentions cacti, just to be evil
[15:10] mmcgrath: ricky: actually thats a good point.
[15:10] mmcgrath: Though its on our noc machine
[15:10] stahnma: it's also esy to write good PHP, if you try
[15:10] stahnma: and I think mediawiki is awesome
[15:10] stahnma: and secure...as secure as a wiki can be
[15:10] * stahnma is done onthat one
[15:11] mmcgrath: the other thing with the wiki is that its been taking a lower priority as of late.
[15:11] paulobanon: lots of ppl working on other stuff
[15:11] mmcgrath: stahnma: if you are interested feel free to review other wikis (and how to migrate from moin to them) post to the list.
[15:11] abadger1999: stahnma: I'm not sure I'd agree with that. Look at the cve's for mediawiki, for instance.
[15:11] paulobanon: and as a future moin is adding a DB backend also
[15:11] ricky: Cool!
[15:11] stahnma: abadger1999: fair enough, I am not all that educated on it ....
[15:12] mmcgrath: ricky: mind if I remove the "meeting" tag from that ticket?
[15:12] * paulobanon suggests adding it to FAS2
[15:12] mmcgrath: paulobanon: <nod> I'll do that now since its getting to crunch time.
[15:12] * paulobanon is evil now... and run from ricky
[15:12] ricky: mmcgrath: Sure.
[15:13] mmcgrath: lets talk about that now actually
[15:13] mmcgrath: Ticket #9 - Fedora Accounts System (LDAP)
[15:13] mmcgrath: I know ricky has been doing a ton of work on it, whats the latest?
[15:14] * paulobanon crashes lots of stuff...
[15:14] ricky: Well my only change to the LDAP schema was to add a description field for groups- everything else was with the TG app.
[15:14] paulobanon: ricky: u're using genshi or kid ?
[15:14] ricky: I ended up moving the user/group sections out into different files/switching to genshi and doing some general template cleanups.
[15:14] jcollie: didn't we need something for UIDs/GIDs?
[15:15] abadger1999: Cool. So lots of cleanup it sounds like.
[15:15] mmcgrath: jcollie: yeah we still need to add UIDs and GIDs, there's a way in ldap to do that and ensure its unique but I didn't get it working.
[15:15] ricky: Hopefully, the permissions stuff should all be separated into auth.py now, although the templates still need to be made to use it.
[15:15] mmcgrath: lots of *much needed* cleanup
[15:16] ricky: But I have a feeling that the next cleanup will probably need to remove some really inefficient LDAP queries that I used- heh/
[15:16] mmcgrath: ricky: what are your near future plans with it? Do you want to take ownership over this and make sure its done by F8 or would you rather just hack on it and get more stuff done?
[15:16] mmcgrath: we can always do that down the road, I've seen what your queries are doing and they feel reasonably fast (though you're right, they probably won't scale very well)
[15:17] ricky: mmcgrath: Well, my plan is to concentrate on mostly on FAS, but it'd be great to have more people that actualyl know python work on it
[15:17] paulobanon: is FAS2 still up for F8 release ?
[15:17] ricky: (This is really my first time touching python/TG)
[15:18] ricky: paulobanon: That might depend on the criteria.
[15:18] mmcgrath: paulobanon: I'm hoping so though it dawned on me that releasing it close to the GA release may not be a good idea.
[15:18] ricky: paulobanon: I've heard something about possible OpenID integration, etc. so I'm not sure how "featureful" it needs to be by release.
[15:18] mmcgrath: so I'd like to have it ready for F8, but then deploy it shortly after.
[15:18] mmcgrath: <nod> we're shooting for OpenID integration but not for the initial rollout.
[15:18] ricky: Ah, that makes it more realistic
[15:18] mmcgrath: right now we just want to replace whats there with this, then add on to it.
[15:19] daMaestro has joined the group chat (n=jon@fedora/damaestro)
[15:19] ricky: Oh, then the big missing stuff is editing groups, CLA, and integration with other apps, shell accounts, etc.
[15:19] ricky: (And maybe a good lookover for any security issues for good measure)
[15:19] ChitleshGoorah has left (Remote closed the connection (n=chitlesh@fedora/ChitleshGoorah))
[15:20] mmcgrath: <nod> CLA (hopefully through a wizzard) and the integration with other apps.
[15:20] abadger1999: Do we have a spec on the new CLA process?
[15:20] * skvidal hates at the CLA
[15:20] ricky: Hm, would it necessarily have to be an e-mail process, since we'd already have the e-mail linked to the user?
[15:20] mmcgrath: For the initial rollout I'll probably leave the clients alone.
[15:20] abadger1999: Still gpg signed, but via a web form?
[15:20] ricky: abadger1999: +1
[15:20] mmcgrath: abadger1999: its going to duplicate what is there now, but through a web form instead of email.
[15:21] abadger1999: Sounds good.
[15:21] ricky: And as a TODO, when the user changes their e-mail it should be verified before the change is accepted.
[15:21] mmcgrath: and hopefully with proper debugging (IE: Your key is not found on MIT's site, you didn't encrypt this, this isn't the cla) that sort of thing.
[15:21] ricky: I'm not sure how we'd implement that within our current LDAP schema.
[15:21] abadger1999: mmcgrath: +1
[15:21] abadger1999: mmcgrath: Almost certainly, translations of the CLA would have to pass legal.
[15:22] abadger1999: ricky: We'll have to put that in the DB
[15:22] mmcgrath: abadger1999: <nod> I'll muse about that for a while. That won't be in the intitial rollout.
[15:22] abadger1999: ricky: A queuing system of some sort. LDAPusername wants to use newemail@....
[15:22] mmcgrath: we'll have to discuss that further. probably on the mailing list.
[15:22] ricky: abadger1999: Ah, so some DB integration for purely internal accounts system stuff.
[15:23] ricky: That sounds like it'd help a lot- I wouldn't feel so locked into to the LDAP schema.
[15:23] abadger1999: ricky: When the user replies, the TG app looks in the queue, changes it in LDAP and removes it from the queue.
[15:23] abadger1999: ricky:
[15:23] mmcgrath: ricky: anything else with FAS2? If not we'll move on.
[15:23] paulobanon: go go go go go
[15:24] ricky: mmcgrath: Everything sounds good for now- I'll probably ask more questions in #fedora-admin later.
[15:24] mmcgrath: cool, thanks for working on this. Seems every time I sat down to work on it, something else came up.
[15:24] mmcgrath has set the subject to Infrastructure -- Schedule
[15:24] mmcgrath: http://fedoraproject.org/wiki/Infrastructure/Schedule
[15:24] kital has joined the group chat (n=Joerg_Si@fedora/kital)
[15:25] mmcgrath: I need to update the schedule. I think the sponsorship setup we have now is good though we need to let it run its course and get more people involved.
[15:25] mmcgrath: we talked about VCS already.
[15:25] mmcgrath: Does anyone have anything to say about the SOP's?
[15:25] mmcgrath: We don't have that many yet.
[15:25] paulobanon: if we have people asking new hosted project
[15:25] mmcgrath: The ones we do have are pretty good though.
[15:25] paulobanon: whats the rule on that
[15:26] mmcgrath: Thats a good question, and its kind of up in the air.
[15:26] mmcgrath: The problem is, and I'll be blunt, we don't want to host crap.
[15:26] paulobanon: +1
[15:26] ricky: Hm, I wonder if some of the longer ones could be made into scripts.
[15:26] mmcgrath: but without knowing the people and projects involved. Its hard to figure out whats crap and whats gold.
[15:26] mmcgrath: ricky: ?
[15:26] mmcgrath: you mean the longer instructions in the SOP?
[15:27] paulobanon: so i would say mail the list and explain what/why and request approval
[15:27] ricky: Actually, I guess this only applies to the denyhosts one, never mind
[15:27] mmcgrath: maybe. Actually you should mail the list and we should discuss it more.
[15:27] mmcgrath:
[15:27] paulobanon: i agree
[15:28] paulobanon: right now, anyone that wants it, goes to trac, open a ticket and assign it to f13
[15:28] mmcgrath: Yep.
[15:28] mmcgrath: thats the current process though I don't think f13 (or anyone else really) wants f13 to have to do all of that. It just keeps growing.
[15:28] paulobanon: yup
[15:28] mmcgrath: paulobanon: email after the meeting and we'll make sure to comment on it.
[15:29] paulobanon: k k
[15:29] mmcgrath: anyone else have anything on the schedules page? If not we'll move on
[15:29] paulobanon: im good
[15:30] mmcgrath: cool.
[15:30] mmcgrath has set the subject to Infrastructure -- Puppet Training
[15:30] * paulobanon wants more then puppet training
[15:30] mmcgrath: Just a reminder, we have puppet training on Monday at 20:00 UTC.
[15:30] mmcgrath: that seems to have worked out for most people (I know jima had a conflict)
[15:31] mmcgrath: If this goes well hopefully we'll be able to figure out other training sessions (like for pkgdb or even the packaging process in general from time to time)
[15:31] paulobanon: i can pretty much everyday after 19UTC
[15:31] ricky: Do any of the Asterisk experts have any thoughts on recording it?
[15:31] mmcgrath: we'll see. I've had a lot of positive comments about the fact that we're even doing training so perhaps I'm on to something here
[15:31] mmcgrath: ricky: good question
[15:32] mmcgrath: AFAIK, we've had a few people look at it, but no one's gotten it to work right yet.
[15:32] mmcgrath: I'll try to take a closer look before the training.
[15:33] ricky: mmcgrath: I think tested something similar using Monitor a while ago.
[15:33] mmcgrath: <nod> how well did it work for you?
[15:33] paulobanon: i wasnt here for Vfudcon, was it nice using asterisk, and considered a success ?
[15:33] ricky: Hm.. I know it was easy to setup, but I don't even remember how the voice quality was.
[15:33] mmcgrath: paulobanon: not that many people used it but of those that did I think people liked it.
[15:34] paulobanon: cool cool
[15:34] mmcgrath: ricky: <nod> I guess we'll have to play around some.
[15:34] mmcgrath: ok, so thats all I have right now.
[15:34] mmcgrath has set the subject to Infrastructure -- Open Floor
[15:34] skvidal: anyone have any bright ideas for backups?
[15:34] mmcgrath: other then backups are a bright idea, no
[15:34] skvidal: for fedorapeople.org
[15:34] skvidal: I mean
[15:35] skvidal: sorry
[15:35] paulobanon: im the backup guy in my company, but its not opensource
[15:35] mdomsch: SLA == no backups?
[15:35] skvidal: paulobanon: yah, we'd like open, thanks
[15:35] paulobanon: doesnt bacula owrks for u skvidal ?
[15:35] paulobanon: (works
[15:36] mmcgrath: mdomsch: well, there's a couple of problems going on, bacula doesn't work very well behind a NAT.
[15:36] londo: I am happy with rdiff-backup to a different disk for a similar local system
[15:36] skvidal: need something to put the data on
[15:36] mmcgrath: and we're running out of storage.
[15:36] skvidal: and as mmcgrath said
[15:36] mmcgrath: right now we're doing a nightly rsync.
[15:36] skvidal: bacula and the firewall is sub-optimal
[15:36] paulobanon: mmcgrath: can that be requestsed from the budget? a mini storage/robot for backups ?
[15:37] mmcgrath: paulobanon: we're looking at different options right now including rsync.net, s3 and a few others
[15:37] ricky: Hehe.
[15:38] mmcgrath: I'm looking at costs of hosting our backups off site or on site.
[15:38] mmcgrath: our options are many but some may just not work out.
[15:39] skvidal:
[15:39] mmcgrath: I'll take that as a no for right now.
[15:39] mmcgrath: mdomsch: whats the most amount of storage we could get in a 2U from dell right now?
[15:40] paulobanon: u want to offsite data in what format ? tapes or backup to an external source ?
[15:40] yingbull: mmcgrath: I'd need to know requirements and constraints before I could give useful input on backups.
[15:40] yingbull: mmcgrath: we might want to define those first.
[15:40] caillon has left ( (n=caillon(a)mithril.returnzero.com))
[15:41] mmcgrath: 2T worth of RPMs and 1T worth of other data.
[15:41] mmcgrath: The largest restore we'd have (right now) is the 2T worth, hopefully it could be done in a matter of a day or two.
[15:41] mmcgrath: using rsync.net under my last estimations, would take about 13 days.
[15:41] yingbull: mmcgrath: Length of retention?
[15:42] paulobanon: why not buy an LTO3 robot, and just offsite the tapes ?
[15:42] mmcgrath: that actually includes the retentions.
[15:42] mmcgrath: paulobanon: we don't have a person at the colo.
[15:42] skvidal: paulobanon: b/c we lack the facilities for it
[15:42] mmcgrath: and we don't have space for it.
[15:42] paulobanon: i dont have persons in 5 of my colos
[15:42] paulobanon: and i still do it
[15:42] mmcgrath:
[15:42] skvidal: paulobanon: but I'm guessing you have power
[15:42] skvidal: paulobanon: and rack space
[15:43] paulobanon: we have space yes
[15:43] mmcgrath: thats the other part of this whole mess is trying to figure out whats going in our current colo and what might end up in the new colo.
[15:43] paulobanon: 1 EML, doing 1.5T backups
[15:43] paulobanon: per colo
[15:44] skvidal: paulobanon: how long do you keep your tapes in rotation?
[15:44] paulobanon: depends
[15:44] mmcgrath: and how much did the tapes + robot cost?
[15:44] skvidal: mmcgrath: 24 tape changer from dell for lto3 is $7K
[15:44] paulobanon: auth 1year, normal game dbs 7days
[15:44] mmcgrath: skvidal: +tapes?
[15:44] skvidal: tapes are $70 or so each for a 400GB tape
[15:45] paulobanon: skvidal: LTO3 i hope
[15:45] yingbull: skvidal: that includes the drive too?
[15:45] skvidal: and you need a box that drives them of course
[15:45] skvidal: paulobanon: yes
[15:45] skvidal: yingbull: last time I checked, yes
[15:45] paulobanon: skvidal: check out recall
[15:45] * mmcgrath goes on the record saying he hates tapes.
[15:45] paulobanon: its what we use to offsite
[15:45] paulobanon: they pickup and drop everything
[15:46] Renault has joined the group chat (n=couretca(a)AToulon-151-1-34-26.w83-205.abo.wanadoo.fr)
[15:46] paulobanon: u just need to have someone to get the tapes in the container
[15:46] yingbull: Tapes are useful for offsite. Disk is useful for quick restores.
[15:46] mmcgrath: paulobanon: we don't have that though
[15:46] mmcgrath: well there's two sides to this. 1) DR and 2) backups.
[15:46] mmcgrath: we're just focusing on backups right now. DR is later.
[15:46] yingbull: raided SATA disks, that get offsited over the net for extra recovery wouldn't be bad.
[15:47] yingbull: That way you've got local restores, but you can rsync/other methods to an offsite location that does have tapes, or another backup system.
[15:47] ricky: Wait, what's the current backup situation?
[15:47] yingbull: ricky: good question.
[15:47] mmcgrath: ricky: we're backing up everything except the koji share.
[15:47] mmcgrath: using bacula. with 2 week retention.
[15:48] ricky: Ah.
[15:48] tibbs has left ("Konversation terminated!" (n=tibbs@fedora/tibbs))
[15:48] paulobanon: mmcgrath: how many cycles ?
[15:48] mmcgrath: one full every sunday, incrementals every day.
[15:48] paulobanon: so 15/2
[15:48] paulobanon: 15 days / 2 cycles
[15:48] mmcgrath: yep
[15:50] mmcgrath: The tricky part is funding (we're still working on that in the background)
[15:50] mmcgrath: If fedora ends up getting a regular actual IT budget, some of these problems will solve themselves.
[15:51] mmcgrath: I'll take the silence as a general "move on"
[15:51] paulobanon:
[15:51] mmcgrath: anyone have anything else they'd like to discuss?
[15:51] paulobanon: when should we start preparing the plan of action for F8
[15:51] paulobanon: better safe then sorry
[15:51] paulobanon: not too safe though
[15:51] mmcgrath: There are some things we can do now, but in general I've created all the tickets that need to be created. By the final test release we should have most of the website ready at http://fedoraproject.org/_/
[15:52] mmcgrath: then its just a matter of making sure the open tickets for Fedora 8 get done and or moved.
[15:52] skvidal: and I should have a listof where everything is
[15:52] skvidal: b/c while mike is off gallivanting around on his honeymoon
[15:52] skvidal: some of us will be here working
[15:52] * mmcgrath can't wait.
[15:52] paulobanon: lol
[15:52] ricky: Hehe- congrats, by the way
[15:52] mmcgrath: just a reminder - http://fedoraproject.org/wiki/Infrastructure/SOP/Release
[15:52] mmcgrath: thanks
[15:53] paulobanon: take us with u!!
[15:53] mmcgrath: and all of those tickets have been created here somewhere - https://hosted.fedoraproject.org/projects/fedora-infrastructure/report/1
[15:53] mmcgrath: I'll ask the future Mrs. mmcgrath.
[15:53] paulobanon:
[15:55] mmcgrath: Ok, if no one has anything else I'll close the meeting in 30
[15:55] mmcgrath: 15
[15:55] yingbull: I'll just add I'm back from $DAYJOB travel and will be nosing around for work.
[15:55] mmcgrath: yingbull: excellent
[15:55] mmcgrath: Ok, meeting closed
[15:56] mmcgrath has set the subject to Meeting End
16 years, 8 months
Introduction
by Jima
Hi folks!
As per the "Getting Started" walkthrough, I thought I'd spam you guys
with a brief rundown of who I am, although I'm sure a number of you
already know.
My name is Patrick Laughton, although most people who know me call me
Jima (yes, IRL, too). I hail from the Great White North -- Minneapolis,
MN, or thereabouts. (That's in the Central US time zone, CDT/GMT-5.)
I've been maintaining Linux boxen for maybe ten years, seven of those
professionally. I started out with Slackware (how's that for cutting your
teeth?), but long ago moved to Red Hat, and then Fedora.
Like many in Fedora Packager Land, I got started because as a sysadmin,
there were often packages I needed that weren't otherwise easily
available. So I packaged what I needed, threw them in a repository, and
went on my merry way. What a pain.
I joined Fedora Extras about 16 months ago to offset some of that heavy
lifting. In addition to making sure everything I needed was in Fedora, I
took on some orphaned packages, and generally looked for other ways I
could help out the project. That's what brings me to Infrastructure; to
see if any of my possibly mediocre skills as a sysadmin might in some way
benefit the bigger picture.
I'll be up-front: I'm not a programmer. I can't code worth crap. I know
a little C (not C++), my perl talents are decent (if sloppy and
roundabout), but I can shell script like mad.
I'm fairly comfortable with Apache, BIND, dnsmasq, Exim, OpenSSH,
Postfix, and Sendmail. Okay, if it's a daemon, I'm probably not too bad
with it. I've played with Nagios and MRTG on and off over the years, as
well. More recently (in the last year or so) I've gotten fairly good at
working with Xen. Not KVM, sadly, due to my general lack of machines with
hardware virtualization capabilities.
My SCM, database, and clustering skills leave a lot to be desired, mainly
because I haven't had any real use for them in my job. Also, I'm
entirely useless at design, unless you like plain, unformatted text, and
stick figures. Anything HTML is liable to be compliant, just ugly and/or
boring.
I don't have any specific goals in mind for getting into Infrastructure;
as I said, I'd be happy to help out with anything that could use some
extra hands.
I think that pretty well covers things. Geez, I should have just updated
my resume; it might have been easier, if a little more glossed-over.
Have a nice day.
Jima
16 years, 8 months
Bugzilla Upgrade breakage
by Toshio Kuratomi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey guys,
The bugzilla upgrade planned for this Friday will break the FAS =>
Bugzilla sync. The problem is that the current method of syncing is:
1) cron job fires
2) everyone is removed from the bugzilla fedora_contrib group.
3) everyone in fedorabugs is added to the fedora_contrib group
In the migrated system, we are not going to be able to do step #2
(because we will no longer have access to the db and there's no xmlrpc
call to do it.)
I'm planning on introducing this kludge to make things work:
1) user is removed from fedorabugs.
2) user is added to a new FAS table with a remove flag: bugzilla_queue
3) user is added to fedorabugs
4) user is added to bugzilla_queue with an add flag
5) cron job fires
6) user in bugzilla_queue are added or removed from fedora_contrib
according to the flag.
7) user is removed from bugzilla_queue
8) repeat from #6 until no more users in queue.
Unless someone can come up with a better method, I'll be implementing
this today.
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGzLUoX6yAic2E7kgRArVvAJ4vm2V8s027/eJDOZrcTiHLyiyNMQCgsqMD
Rt8/ndty/iMU7w7W1sbiyYk=
=deuI
-----END PGP SIGNATURE-----
16 years, 8 months
Turbogears and memory usage
by Mike McGrath
App3 and App4 are pretty much dedicated to turbogears apps. Right now
pkgdb, smolt and mirror manager. I've noticed app3 and app4 are both
swapping pretty bad. I was hoping some of the application owners (and
general community) could investigate further and verify that the
applications are behaving properly and look to see if there are more
efficiencies we could gain.
App3:
apache 1741 0.5 5.3 506168 110048 ? Sl Aug17 15:54
/usr/bin/python /srv/tg/pkgdb/pkgdb/start-pkgdb.py /srv/tg/pkgdb/prod.cfg
apache 13509 2.2 31.1 1418520 638624 ? Sl Aug13 196:05
/usr/bin/python /srv/tg/mirrormanager/start-mirrors.py prod.cfg
apache 13511 13.8 7.1 677396 147376 ? Sl Aug13 1235:14
/usr/bin/python /usr/share/smolt/smoon/start-hardware.py prod.cfg
App4:
apache 6951 0.2 1.8 226308 17632 ? Sl Aug15 12:02
/usr/bin/python /srv/tg/pkgdb/pkgdb/start-pkgdb.py /srv/tg/pkgdb/prod.cfg
apache 18055 3.0 39.9 910332 384916 ? Sl Aug13 268:21
/usr/bin/python /srv/tg/mirrormanager/start-mirrors.py prod.cfg
apache 18057 0.6 6.6 233648 63908 ? Sl Aug13 54:06
/usr/bin/python /usr/share/smolt/smoon/start-hardware.py prod.cfg
-Mike
16 years, 8 months
Builder monitoring
by Mike McGrath
We've recently started taking a closer look at the builders and as a
result we've been getting many notifications. As a baseline, the
builders need some work. One thing we've been getting alerted of is
memory usage, in particular less than 10% swap free.
We have a couple of options.
1) stop monitoring swap on the builders
2) reduce resolution on the builders (check less often and require more
failures in a row before notification, right now is 3 failures in a row
results in a notification)
3) increase swap (presently about 1G / core so between 2G and 8G of swap
on the boxes)
Build guys! What do you think?
-Mike
16 years, 8 months
Builders and mock
by Mike McGrath
Don't upgrade mock on the builders! Long story short, xenbuilder2 was
having issues earlier this week staying up. Hoping it was a known
problem I yum updated the box. Mock was updated. Some of these
updates, however, were with the exit code. We had many builds return a
successful result even though the build failed. Jesse is looking into
this and following up with the mock people. I've since rolled back to
the previous version - 3.0.6-1.fc6
That is all :)
-Mike
16 years, 8 months
ssl on publictest dev apps
by Luke Macken
There are a handful of development instances of various apps running on
our publictest systems, most of which don't support SSL. This is
obviously not a good thing, so I'm proposing that we either enable SSL
on these apps, or disable the FAS identity provider and provide local
guest accounts on the local SQLite dbs.
luke
16 years, 8 months
