From jason at 3dogs.us Wed Jun 21 05:16:19 2006 From: jason at 3dogs.us (Jason Hartley) Date: Wed, 21 Jun 2006 01:16:19 -0400 (EDT) Subject: [Fedora-infrastructure-list] FYI - I made some changes on bastion for xferlog scripts Message-ID: <35360.192.168.0.10.1150866979.squirrel@www.3dogs.us> Elliot- I have the xferlog scripts in place to test on bastion. I have placed xferlogarchive.py and ArchiveEmail.py in /var/fedora-accounts on bastion. Also, I added the procmailrc recipe: :0 * ^TO.*download-logs@(fedora.redhat.com|fedoraproject.org) | /var/fedora-accounts/xferlogarchive.py to /var/fedora-accounts/.procmailrc The last thing I did is create the directory /var/xferlogarchive to store the xferlog emails in for the time being until we can get some space on the netappailance. (I will followup with Stacy Brandenburg and Matt Galgoci to see about the netapp space.) I still need to check in the changes to the .procmailrc file and the two scripts. I currently do not have write access to the fedora-accounts module for the .procmailrc file. The two scripts I was not sure where I should stick them in the fedora-config module. Do you want to stick in the top most directory or should they go in some other subdirectory? Regards, Jason Hartley From sopwith at redhat.com Wed Jun 21 05:52:17 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 21 Jun 2006 01:52:17 -0400 Subject: [Fedora-infrastructure-list] FYI - I made some changes on bastion for xferlog scripts In-Reply-To: <35360.192.168.0.10.1150866979.squirrel@www.3dogs.us> References: <35360.192.168.0.10.1150866979.squirrel@www.3dogs.us> Message-ID: Hey Jason, thanks for finishing this up! If you want commit access to fedora-accounts, join the cvsfedora group and someone will approve your access. As far as placing the scripts, the best place right now is probably in fedora-config/files/live.admin/var/fedora-accounts, so that they will be properly dist-conf'd out if the system is ever reinstalled. (The 'admin.live' host alias refers to bastion at present...) Best, -- Elliot On Jun 21, 2006, at 01:16, Jason Hartley wrote: > I have the xferlog scripts in place to test on bastion. I have > placed > xferlogarchive.py and ArchiveEmail.py in /var/fedora-accounts on > bastion. Also, I added the procmailrc recipe: > > :0 > * ^TO.*download-logs@(fedora.redhat.com|fedoraproject.org) > | /var/fedora-accounts/xferlogarchive.py > > to /var/fedora-accounts/.procmailrc > > The last thing I did is create the directory /var/xferlogarchive to > store > the xferlog emails in for the time being until we can get some > space on > the netappailance. > > (I will followup with Stacy Brandenburg and Matt Galgoci to see > about the > netapp space.) > > I still need to check in the changes to the .procmailrc file and > the two > scripts. I currently do not have write access to the fedora-accounts > module for the .procmailrc file. The two scripts I was not sure > where I > should stick them in the fedora-config module. Do you want to > stick in > the top most directory or should they go in some other subdirectory? From mmcgrath at fedoraproject.org Thu Jun 22 20:16:47 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 22 Jun 2006 15:16:47 -0500 Subject: [Fedora-infrastructure-list] Ticketing system and email addresses Message-ID: <449AFAAF.8060503@fedoraproject.org> I've migrated webmaster at fedoraproject.org and voting at fedoraproject.org to their respective OTRS queues. As we get used to them I'll migrate more and more email addresses. -Mike From sopwith at redhat.com Thu Jun 22 22:30:43 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 22 Jun 2006 18:30:43 -0400 Subject: [Fedora-infrastructure-list] Admin/infrastructure meeting log for 2006-06-22 Message-ID: <20060622223043.GA1995@ostrich-deluxe.devel.redhat.com> Hi all, Attached is the log for today's meeting and the backup discussion that followed... Please make sure you're on fedora-infrastructure-list (https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list/), since that's becoming the primary list for infrastructure discussions. Thanks for everyone who made it to today's meeting! It's really neat to see all the projects that are moving along. Best, -- Elliot -------------- next part -------------- Jun 22 15:56:42 meeting in 5min :) Jun 22 16:03:17 Anyone home? Jun 22 16:03:22 hi Jun 22 16:03:24 I'm here. Jun 22 16:03:33 But only for a few..... Jun 22 16:03:54 * lmacken Jun 22 16:04:37 * dgilmore is here Jun 22 16:07:59 OK Jun 22 16:08:26 lyz: You're here two weeks in a row - that makes you a member :) Jun 22 16:08:35 rock on Jun 22 16:08:40 iwolf: proxy4 all done? Jun 22 16:08:45 :( Jun 22 16:08:59 app1 is done! Jun 22 16:09:08 yea! Jun 22 16:09:09 proxy4 is updated, fstab fixed, kernel reinstalled, apache installed. Jun 22 16:09:26 I need to reboot it to be sure my fstab stuff worked and to get the new kernel. Jun 22 16:09:28 and then dist-conf the config. Jun 22 16:09:31 Then it's done as well. Jun 22 16:09:41 Oh, cleaned up the old cvs stuff from it as well. Jun 22 16:09:53 I hope to do that tomorrow night, the weekend at the latest. Jun 22 16:09:57 Cool Jun 22 16:10:11 since I'm new here, any URL that details which servers do what? Jun 22 16:10:43 tgrman: We have a web page for that, but it's currently private 'cause we're not sure it's a good idea to tell hackers how the machines are laid out... Jun 22 16:10:55 yeah, that makes sense :) Jun 22 16:11:15 which i think is fair, and i dont have access to that info :) Jun 22 16:11:33 Basically, we have 4 proxy servers, 2 app servers, and a db server for the running some web apps, plus a cvs server, build machines, and a couple of misc administrative boxes Jun 22 16:11:56 sorry, I'm here now Jun 22 16:11:57 whats up? Jun 22 16:12:02 OK, so upgrades are going very smoothly except for the fact that I have done nothing about upgrading db1, mea culpa. Jun 22 16:12:29 mmcgrath: Just getting started. It's a lazy summer afternoon, no rush :) Jun 22 16:12:41 * Sopwith sticks db1 upgrade back on his todo list Jun 22 16:13:01 Oh, we did have good news on the 'being able to access the BIOS' front ;-) Jun 22 16:13:25 That will be quite nice! Jun 22 16:13:25 upgrading DB servers is always fun, espicially if you want no downtime on the apps using them Jun 22 16:13:36 warren: thanks for the perl-Net-SNMP push. Jun 22 16:13:50 that we do. Jun 22 16:13:52 still don't know why it matters, but it seems to. Jun 22 16:13:53 dgilmore: Where are you and Dan with the backup system? (For the benefit of others here who aren't in on the thread, which should be moved to the list now that it exists) Jun 22 16:14:18 * dgilmore needs to subscibe to the list Jun 22 16:14:42 Sopwith: Seth and I were talking about backs. His preference is something that supports an ssh tunnel. He doesn't care if backups at each site are local, or if we pull them to the phx colo. Jun 22 16:14:42 right now im looking at the options that are available to us Jun 22 16:14:42 He's pushing amanda :-D Jun 22 16:15:08 BTW, fedora-infrastructure-list exists now - use it unless the topic really needs to be private Jun 22 16:15:24 it'll take me a bit to get used to that I'm sure :-D Jun 22 16:15:49 dgilmore: Cool. Sounds like it's worth syncing up with skvidal & mmcgrath for their opinions. Jun 22 16:15:49 im considering bacula, amanda, rsync and scrips, rdiff-backup Jun 22 16:16:01 Sopwith: will do Jun 22 16:16:05 dgilmore: Maybe e-mail the list to let them know where things stand in more detail, and start to gather opinions. Jun 22 16:16:33 Sopwith: will do Jun 22 16:16:35 dgilmore: Sounds like you have a good number of solutions to choose from, nifty Jun 22 16:16:48 brb Jun 22 16:17:09 firewalling stuff - lmacken has been looking at that Jun 22 16:18:01 Sorry guys, I have to leave early. I will catch up via the logs.... Jun 22 16:18:22 iwolf: OK, see ya Jun 22 16:18:23 yeah Jun 22 16:18:38 i've been playing around with pyroman (someone mentioned it during the last meeting, but i forget who) Jun 22 16:19:15 i've defined a profile for all of our machines (in phx so far), and I'm currently working on porting our rc.firewall script over to pyroman configs Jun 22 16:19:37 i'll drop a status update to infrastrucure-list once i have something we can play with Jun 22 16:19:45 Cool Jun 22 16:20:38 Documentation - I put the services list up with contact info under InfrastructurePrivate - feel free to fix it if you have access and see something wrong Jun 22 16:21:50 I also found that a backup & restore plan of some sort is already in the fedora-config module, in the access subdir Jun 22 16:22:53 Haven't documented dist-conf or fedora-config yet Jun 22 16:23:55 mmcgrath: OTRS queues - did you set the one up for the voting app? Can we get another one set up for cvs maintenance? (e.g. making branches for extras) Jun 22 16:24:13 rordway: ping on monitoring Jun 22 16:24:41 mmcgrath setup voting for me. It's working well. Jun 22 16:25:39 abadger1999: So there's an e-mail address set up that people can mail if they have problems or questions? Jun 22 16:26:21 voting at fedoraproject.org Jun 22 16:26:32 Awesome. I should list that on the services page. Jun 22 16:26:35 Or use the web interface. Jun 22 16:26:59 ja8sun did all the xferlog stuff, I think, except redirecting the alias. I can do that really quickly Jun 22 16:27:12 The voting application should be sending a message there if it has errors contacting the database or other stuff that requires manual intervention as well. Jun 22 16:27:19 sorry back. Jun 22 16:27:24 yes, the OTRS voting queues are up. Jun 22 16:27:42 abadger1999 even has his app throwing erros to email voting at fedoraproject.org Jun 22 16:28:48 cool Jun 22 16:31:25 Other misc items: ja8sun was looking at the CentOS mirroring setup. Damian is "on vacation" (i.e. hacking on the hardware reporting tool :). i18n.redhat.com migration still lurches slowly ahead on internal threads. Jun 22 16:31:44 joe^? you here? Jun 22 16:32:06 He showed a bit of an interest in the account system last week... Jun 22 16:33:20 lyz: Hey, you there? Jun 22 16:33:24 yup Jun 22 16:33:38 lyz: Don't want to let you get lost in the shuffle - is there something you're working on or wanting to work on? Jun 22 16:33:39 --- [lyz] (n=lyz at c-71-57-127-145.hsd1.il.comcast.net) : Tom Jun 22 16:33:39 --- [lyz] #fedora-admin Jun 22 16:33:39 --- [lyz] irc.freenode.net :http://freenode.net/ Jun 22 16:33:39 --- [lyz] is identified to services Jun 22 16:33:39 --- [lyz] End of WHOIS list. Jun 22 16:34:01 Sopwith, not working on anything currently. Willing to work on anything Jun 22 16:34:25 :) Jun 22 16:34:37 got something for me? Jun 22 16:35:23 The account system and Extras package DB don't seem to have people are clearly on top of them. Do you have an interest in writing python+SQL webapp type stuff for them? Jun 22 16:35:42 I was going to ask about the extras pkg db Jun 22 16:35:47 I think last week I dropped the ball partly by not catching up with joe^ to tell him what was needed. Jun 22 16:35:51 mjk: Heh cool :) Jun 22 16:36:04 I've written a little in Python and SQL. If someone is watching me, I should be ok Jun 22 16:36:28 lyz: Oh, we're alll here to help :) Jun 22 16:36:43 cool Jun 22 16:37:21 I don't know if the Extras team is doing any actual work on the package DB, but someone needs to lead out in figuring out "what are we actually going to do" for both tasks, and doing requires more general e-mailing and leadership skills than any coding. Jun 22 16:37:23 I might be able to help there also, but I know no python... Jun 22 16:37:30 willing to learn tho ;) Jun 22 16:37:52 mjk|wrk: Are you involved in other aspects of Fedora anyways? I just figured you might have a reason why you perked up at mention of the pkg DB :) Jun 22 16:38:15 I help with the status report, which resulted in the FE pkg db Jun 22 16:38:18 threads Jun 22 16:38:31 oh, you are that dude! I like those reports Jun 22 16:38:37 plus other qa type things Jun 22 16:38:58 there is Christian too, he has been doing for the most part, but now we take turns Jun 22 16:39:04 Yea mon... Have you talked with wwoods at all to find out about how he might be able to help you with Extras QA? Jun 22 16:39:16 nope Jun 22 16:39:42 but will make a note to poke him on irc next time I see him Jun 22 16:40:26 lyz, mjk|wrk: I'm looking into upgrading CVS to a new VCS and I think I'm going to want to tie into the package DB. Jun 22 16:40:32 He recently started into a role at Red Hat as Mr. Fedora QA Guy, and I'm sure he'd like to know where things stand. Jun 22 16:40:59 abadger1999, email me the details on it Jun 22 16:40:59 back soon Jun 22 16:41:39 Sopwith: ok, I will make an effort to catch him Jun 22 16:41:41 lyz: So for next week, would you be comfortable putting together a wiki page for the Account System version 2.0 task, and starting to collect requirements from people via the mailing list? Jun 22 16:41:42 abadger1999: cool Jun 22 16:41:46 lyx, mjk|wrk: I'm writing up my thoughts on the wiki and I'll mail you a link when I have it written. Jun 22 16:41:59 Sopwith, sure Jun 22 16:42:07 brb Jun 22 16:43:06 lyz: If you want to work on the pkg db as well, that's fine, but mjk is interested in pkg db as well, so I figure it'd split things out a bit better if you can focus on account system. Is that OK with you? Jun 22 16:43:59 tgrman: While lyz is going to raid the kitchen, would you like to introduce yourself and tell us what you might want to work on? (Assuming that's what you're here for :) Jun 22 16:44:19 back Jun 22 16:44:21 sure, that's why i'm here :-) Jun 22 16:44:44 Sopwith, I'm not familiar with pkg db, but I'm game Jun 22 16:45:27 Cool. I'll look forward to seeing your post on fedora-infrastructure-list :) Jun 22 16:46:02 * mjk|wrk thinks he should sub to that list Jun 22 16:46:08 yup, definitely Jun 22 16:46:15 --- Topic for #fedora-admin is This is the meeting place of the Fedora Infrastructure team - the system administrators of the Fedora Project | http://fedoraproject.org/wiki/Infrastructure | Regular meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings Jun 22 16:46:15 --- Topic for #fedora-admin set by nman64 at Thu Jan 5 17:03:19 2006 Jun 22 16:46:26 Need to get someone to put that in the /topic Jun 22 16:47:54 Curt Moore, used RH since 6.2, built lots of Beowulf clusters in the past using RH/Fedora, willing to work on whatever needs attention, what all is left outstanding? Jun 22 16:49:13 Assuming you've read the wiki pages and familiarized yourself with what's going on, have any of the existing projects popped out as ones that are interesting to you? Jun 22 16:49:48 --> dferris (n=dferris at epiphany.colorado.edu) has joined #fedora-admin Jun 22 16:50:48 One grunt-work task that needs doing is routing tickets in OTRS and being the friendly smiley face that helps give quick responses :) Jun 22 16:50:51 also discussing on the list is good too. Jun 22 16:50:51 dferris: heya! Jun 22 16:51:24 tgrman: Yea, make sure you're on the list Jun 22 16:52:01 sorry I'm late Jun 22 16:52:53 Sopwith: yeah I've read through the wiki, any of the systems upgrade stuff would be interesting for starters unless there is something else more pressing Jun 22 16:53:02 dferris: we assigned you janitor duty, hope you don't mind :) Jun 22 16:54:37 tgrman: Hmm, so my personal preference is to have people do a few smaller things before giving them root on all the boxes, just to make sure they're not trying to rig our ongoing election ;-) Jun 22 16:55:05 :-D Jun 22 16:55:11 lol Jun 22 16:55:28 I'm not rigging anything Jun 22 16:55:29 yet Jun 22 16:55:36 haha Jun 22 16:56:10 Sopwith: yeah, that's understandable. :-) I manage a farm of servers, it's just something I'm good at. Jun 22 16:56:32 tgrman: Cool. So it sounds like you're more interested in the sysadmin side of things than development? Jun 22 16:57:31 I can do grunt work before doing anything imporant, that's no big deal Jun 22 16:57:54 dferris: We talked a bit about backup stuff earlier, and you're in on that I assume :) Jun 22 16:58:21 mmcgrath: I'm curious, what exactly does it take to give people admin access to OTRS? Sound like a decent first-step to you? Jun 22 16:59:19 (First step as far as getting people involved) Jun 22 17:00:00 I'll just have to add them. Jun 22 17:00:06 the admin interface is still fairly manual. Jun 22 17:00:14 erk, ok Jun 22 17:00:20 Sopwith: yeah, for now at least. I also supervise lots of development at work so for me it's enjoyable to do more sysadmin type stuff rather than programming. But it's not all about my enjoyment, I'll do whatever needs to be done. I also have lots of experience devloping PHP/PGSQL/MYSQL apps. Jun 22 17:00:26 I'm sure there's an easy way to fully incorperate it into the accounting system but it sounds like lots of people are going to need access to the admin interface. Jun 22 17:00:40 like the website people for example, they're not in the sysadmin group but will need access. Jun 22 17:00:57 mmcgrath: Yea, I was just wondering - is there any way to authorize access via membership in a separate group ('otrsadmin' or something) Jun 22 17:01:12 Sopwith: sorry, had some system problems to attend to Jun 22 17:01:26 rordway: Hey man, party's over, go home Jun 22 17:01:28 (kidding!) Jun 22 17:02:17 We're about out of time, so it's understandable if some people need to wander off, but I'm interested in hearing about rordway's todo items from the past week... Jun 22 17:03:30 talked with mmcgrath about nagios, but from what I understand we're waiting for rhel4 upgrades Jun 22 17:03:44 so not much has happened Jun 22 17:03:47 Cool Jun 22 17:04:07 Did you get a chance to look at the fedora-metrics code? Jun 22 17:04:20 and I haven't had time to look at the metrics code, it's intersession so I've been busy with server maintenance Jun 22 17:04:25 back Jun 22 17:04:34 nope, not yet :-( Jun 22 17:04:45 dgilmore: dferris is here if you two wanna make evil plots about backup stuff... Jun 22 17:05:24 rordway: OK, cool. RHEL4 upgrades are pretty much my and iwolf's problem at this point - I'll really truly try to make the db1 upgrade happen soon. Jun 22 17:05:26 Sopwith: sure, once i work out how to insert 1 million votes for me in the election :D Jun 22 17:05:28 had to bring down our SAN today for microcode updates and put in a temporary firewall so I can migrate our bridging firewall for our *ick* Windows boxes from Debian to RHEL Jun 22 17:05:32 dgilmore: Haha Jun 22 17:06:15 rordway: another way we could help is to get nrpe approved. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180092 Jun 22 17:06:44 Gotta run, i'm on the fedora-infrastructure-list list now. I will send a message out about the Account System 2.0 tonight Jun 22 17:06:45 mmcgrath: cool, I'll take a look at that after I eat lunch... yeah, it's been that kind of day ;-) Jun 22 17:06:55 lyz: Woohoo, thanks & see you. Jun 22 17:06:55 <-- ozgur has quit ("exitus immortalus...") Jun 22 17:07:03 Let me know if there's anything else I can do Jun 22 17:07:05 c ya Jun 22 17:07:16 <-- lyz has quit ("Leaving") Jun 22 17:07:36 Sopwith: any idea what watchsyn is and where it might live ? Jun 22 17:07:43 what is the listserv for fedora-infrastructure-list? Jun 22 17:08:02 https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list/ Jun 22 17:08:14 lmacken: No clue at all Jun 22 17:08:25 lmacken: Could it be an iptables module? Jun 22 17:08:41 Sopwith: maybe ? this is in rc.firewall: Jun 22 17:08:42 # This chain is updated by the watchsyn script, so by default it is Jun 22 17:08:42 # just there. New IP addresses will get added and their traffic will Jun 22 17:08:42 # get dropped. Jun 22 17:08:56 Maybe the script watches for SYN flooders. Jun 22 17:09:04 We sure don't run any watchsyn script that I know of... Jun 22 17:09:10 heh Jun 22 17:09:13 meh, oh well Jun 22 17:09:36 locate watchsyn ? Jun 22 17:11:02 dferris: do you have any backup stuff you like? Jun 22 17:11:27 FWIW, I think dferris was the one who first suggested bacula... Jun 22 17:11:35 yeah Jun 22 17:11:39 I use it here at work Jun 22 17:11:44 Sopwith: I'm going to go forage for some lunch, I'll get back in touch with you once I get a chance to look through the metrics code Jun 22 17:11:49 it's complicated to setup, but when it runs it rocks Jun 22 17:11:53 rordway: Cool stuff, thanks Jun 22 17:12:02 In case it matters to anyone, I think the main meeting is over :) Jun 22 17:12:05 and I'm on the fedora-infrastructure-list now too Jun 22 17:12:06 ahh yeah Jun 22 17:12:11 heh Jun 22 17:12:24 Sopwith: do we have the ability to give non sudo access to the machines yet? Jun 22 17:12:26 I need to spend some time and finish packaiging up for extras Jun 22 17:12:30 Sorry dferris i forgot Jun 22 17:12:56 mmcgrath: Would you give an example scenario? Jun 22 17:13:12 >chanserv< info #fedora-admin Jun 22 17:13:13 -ChanServ- Channel: #fedora-admin Jun 22 17:13:13 -ChanServ- Contact: nman64, last seen: 3 days (0h 34m 38s) ago Jun 22 17:13:13 -ChanServ- Alternate: Sopwith << ONLINE >> Jun 22 17:13:13 -ChanServ- Registered: 23 weeks 6 days (23h 19m 2s) ago Jun 22 17:13:13 -ChanServ- Topic: This is the meeting place of the Fedora Infrastructure team - the system administrators of the Fedora Project | http://fedoraproject.org/wiki/Infrastructure | Regular meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings Jun 22 17:13:13 -ChanServ- Email: sysadmin-members at fedora.redhat.com Jun 22 17:13:13 -ChanServ- Contact URI: http://fedoraproject.org/wiki/Infrastructure Jun 22 17:13:13 -ChanServ- Options: Secure, SecureOps, ChanGuard Jun 22 17:13:13 -ChanServ- Mode Lock: -s+ntc Jun 22 17:13:23 >chanserv< help Jun 22 17:13:23 -ChanServ- ChanServ allows you to register and control various Jun 22 17:13:23 -ChanServ- aspects of channels. ChanServ can often prevent Jun 22 17:13:23 -ChanServ- malicious users from "taking over" channels by limiting Jun 22 17:13:23 -ChanServ- who is allowed channel operator priviliges. Any channel Jun 22 17:13:23 -ChanServ- which is not used for 120 days will be expired and may Jun 22 17:13:23 -ChanServ- be dropped. ChanServ's commands are listed below. Jun 22 17:13:23 -ChanServ- For more information on a specific command, type Jun 22 17:13:23 -ChanServ- /msg ChanServ help . Jun 22 17:13:23 -ChanServ- Jun 22 17:13:23 -ChanServ- REGISTER Register a channel Jun 22 17:13:23 -ChanServ- DROP Cancel the registration of a channel Jun 22 17:13:23 -ChanServ- IDENTIFY Identify yourself with your password Jun 22 17:13:23 -ChanServ- SET Set various channel options Jun 22 17:13:23 -ChanServ- ACCESS Modify the list of privileged users Jun 22 17:13:23 -ChanServ- AUTOREM Maintain the AutoRemove list Jun 22 17:13:23 -ChanServ- LEVEL Change the level required for functions Jun 22 17:13:23 -ChanServ- LIST Display list of channels matching a pattern Jun 22 17:13:23 -ChanServ- INFO Display information for a channel Jun 22 17:13:23 -ChanServ- GETKEY Retrieve the key (+k) to a channel Jun 22 17:13:23 -ChanServ- INVITE Invite yourself to a channel Jun 22 17:13:23 -ChanServ- OP Op yourself on a channel Jun 22 17:13:23 -ChanServ- VOICE Voice yourself on a channel Jun 22 17:13:23 -ChanServ- UNBAN Unban yourself on a channel Jun 22 17:13:23 -ChanServ- CLEAR Clear various channel modes Jun 22 17:13:32 >chanserv< op #fedora-admin Jun 22 17:13:32 --- ChanServ sets modes [#fedora-admin +o Sopwith] Jun 22 17:13:34 --- Topic for #fedora-admin is This is the meeting place of the Fedora Infrastructure team - the system administrators of the Fedora Project | http://fedoraproject.org/wiki/Infrastructure | Regular meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings Jun 22 17:13:34 --- Topic for #fedora-admin set by nman64 at Thu Jan 5 17:03:19 2006 Jun 22 17:13:50 I was just thinking instead of giving people straight sudo access to the boxes we could implement some non sudo access to get familiar with the boxes Jun 22 17:14:37 --- Sopwith has changed the topic to: This is the meeting place of the Fedora Infrastructure & Sysadmin team | http://fedoraproject.org/wiki/Infrastructure | Regular meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings | https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list/ Jun 22 17:14:44 mmcgrath: That makes sense. Jun 22 17:15:18 Sopwith: how much storage space do we have on our backup box? Jun 22 17:16:27 I use bacula too, and I would be able to help out in setting it up. I set up a bacula system for Pogo Linux and Real Networks Jun 22 17:16:34 dgilmore: datadump has 3.0T, of which there is 112G free. (I think datadump will wind up dying someday eventually, since its role is not 100% clear) Jun 22 17:17:16 There is also ext-backup, which works a lot like datadump except its disk array gets backed up to tape in turn (by the RH sysadmin team) Jun 22 17:17:20 can bacula tunnel over ssh automatically or should we setup a tunnel? Jun 22 17:17:31 bacula can use SSL Jun 22 17:17:34 which brings me to another question... should we implement OpenVPN for our multiple sites? Jun 22 17:17:34 natively Jun 22 17:17:42 dferris: thats not a tunnel Jun 22 17:17:51 SSL as in we'll have to make firewall changes all over the place? Jun 22 17:18:09 if you want to tunnel, you have to setup the tunnel yourself. However there is a good facility for pre and post backup commands. Jun 22 17:18:39 mmcgrath: what are you looking to tunnel through? Just shove all bacula communication through port 22 to avoid firewall changes? Jun 22 17:18:50 I use SSH tunnels for my DB backups, they work well Jun 22 17:18:53 mmcgrath: or is there concerns about having the backup unit outside the local network to the builders? Jun 22 17:18:54 I think you could Jun 22 17:19:05 it uses TCP ports Jun 22 17:19:12 I think 9102 is the default Jun 22 17:19:19 there are three ports Jun 22 17:19:27 The network the backup units are on has full access to all the Fedora systems, AFAIK Jun 22 17:19:28 or two that the clients have to worry about Jun 22 17:19:38 (except as denied by per-system iptables, which is easy to fix) Jun 22 17:19:38 one port for the director, and one port for the storage. Jun 22 17:19:46 f13: i'm worried about other backups too, like those from the duke servers. Jun 22 17:19:53 (as director box can be completely seperate from the storage box(es)) Jun 22 17:20:34 mmcgrath: i agress we should be backing up all boxes, duke ones as wel as ones in RH facilities Jun 22 17:21:04 but we can coordinate them seperately. We could have the duke backups onsite at duke and the RH ones on site in PHX. Jun 22 17:21:17 yeah Jun 22 17:21:28 we really need to guard the backups closely though. Jun 22 17:21:32 the same director can direct the backups, but the duke boxen could just backup to a localized storage unit Jun 22 17:21:38 http://darcs.complete.org/debian/bacula/examples/ssh-tunnel-README.txt Jun 22 17:21:48 the communication from director to client can be ssh tunneled. Jun 22 17:22:10 dgilmore: I used that some, but I had some issues with hit Jun 22 17:22:14 you have to use the pre backup scripts to bring up the tunnel Jun 22 17:22:14 In that case bacula sounds fine to me, I'm just not that familiar with it. Jun 22 17:22:26 f13: ok Jun 22 17:22:27 with sending large data down the tunnel. THe tunnel would die or falter, and the backup would get stuck. Jun 22 17:22:44 :: cough :: openvpn :-DɎM Jun 22 17:22:53 heh Jun 22 17:22:58 mmcgrath: What are the security implications of that? Jun 22 17:23:02 openswan :D Jun 22 17:23:31 My secret fear is someone breaking into the Red Hat machines in PHX via the Fedora boxes, and Fedora losing all its ability to host cool stuff as a result... Jun 22 17:24:02 that would not be good Jun 22 17:24:36 Sopwith: how many of the machines need to directly contact RH machines? Is there not a reason why the Fedora network could be segregated? Jun 22 17:24:37 That's why a VPN connection between Duke and PHX scares me a tiny bit (although if there are real benefits, we can probably afford to take the risk) Jun 22 17:24:48 thats a valid fear Jun 22 17:24:50 f13: They are segregated, but not 100% Jun 22 17:24:59 Sopwith: whats the blocker on 100%? Jun 22 17:25:06 we could protect against it though. Jun 22 17:25:28 it'd be nice to have an encrypted channel between the two sites. Jun 22 17:25:43 f13: For example, the physical netapp that hosts some Fedora stuff in PHX also hosts some stuff for other RH stuff. The Fedora machines can't read/write to the other stuff, but how much do you trust OnTap? Jun 22 17:26:50 What do we have at Duke? plague-server, wiki, ? Jun 22 17:26:50 dgilmore/dferris: Anyways, sorry about that tangent - you two are the ones I consider as being responsible for getting us all to decide on the best backup solution and then implement it. Jun 22 17:27:04 and transfer of the fedora accounting stuff. Jun 22 17:27:06 plague-server, a build machine or two, wiki and a few other web pieces. Jun 22 17:27:18 Yea, but the account system transfer is only one-way right now. Jun 22 17:27:24 thats true Jun 22 17:27:34 IMHO, probably the way to go would be the SSH tunnel, that way the secure connection is opened during the backup and closed once it's done. That way you don't have the constant trusted connection like with the VPN. Jun 22 17:27:43 tgrman: Hmm, good point. Jun 22 17:27:56 be right back Jun 22 17:28:21 we can always start with the tunnel and if its not working we can move to something more robust. Jun 22 17:28:38 we could rsync over a ssh tunnel data from duke. Jun 22 17:28:43 Sopwith: ok, storage is a valid segregation point. Jun 22 17:29:14 Sopwith: of that 3TB how much is the current backups? Jun 22 17:29:21 mmcgrath: sounds like a plan to me. I've used SSH tunnels for the past few years to to backups, rsync, etc and they work very well Jun 22 17:29:37 f13: It's not that I and Stacy haven't worked to segregate things as much as possible, it's just that there are things like the netapp and the cyclades that we can't split because we can't really justify buying separate ones for Fedora Jun 22 17:29:42 (Although that may change) Jun 22 17:29:46 tgrman: on demand ssh tunnels can be fragile though. Just to keep in mind. Jun 22 17:29:51 hmm, ext-backup is down Jun 22 17:29:58 Sopwith: indeed. Jun 22 17:30:04 I'll donate a cyclades! Jun 22 17:30:13 just kidding. Jun 22 17:30:47 I think GIS's intent is to have separate pieces at some point (the cyclades in particular shouldn't be too hard to find the money for), but companies are slower than us :) Jun 22 17:31:32 dgilmore: doing a du right now to see how much space the current copies of the Fedora-related data takes. Jun 22 17:31:38 Im keeping my T1000 to myself Jun 22 17:31:43 hah Jun 22 17:31:46 Sopwith: thanks Jun 22 17:31:48 must be nice Jun 22 17:32:18 dferris: sun donated it to me for aurora it arrives toomoorow Jun 22 17:32:33 dgilmore: Neat, you're involved in aurora? Jun 22 17:32:50 Sopwith: yeah Jun 22 17:33:14 Sopwith: im responsible for building extras for aurora Jun 22 17:33:50 dgilmore: if you get tired if it, I'll send you my shipping address Jun 22 17:34:22 dgilmore: This du might take a while - I'll have to email it to you. Jun 22 17:34:30 Sopwith: cool Jun 22 17:34:34 dferris: unlikely Jun 22 17:34:39 lol Jun 22 17:34:40 :) Jun 22 17:40:04 Sopwith: I think before we decide on what to do for backups we need to know how much we need to back up, what boxes/files need to be backed up, and where we're going to store it all. The I think we can figure out which software will best suit our needs. Jun 22 17:40:20 ok, all good questions Jun 22 17:40:23 oh wait Jun 22 17:40:25 du came back Jun 22 17:40:32 2.4G cvs.fedora.redhat.com/cvsroot Jun 22 17:40:32 120G cvs.fedora.redhat.com/homeroot Jun 22 17:40:32 28G cvs.fedora.redhat.com/reporoot Jun 22 17:40:32 11M db1.fedora.phx.redhat.com/db Jun 22 17:40:32 1.9M db1.fedora.phx.redhat.com/db_mysql Jun 22 17:40:43 what in the world is in homeroot? Jun 22 17:41:22 so most of that 3T is not our data? Jun 22 17:41:30 Correct. Jun 22 17:41:37 There is internal stuff also backed up to that box. Jun 22 17:42:00 Oh, and I daresay that all that space used by homeroot will go away once I rm -rf it Jun 22 17:42:10 lol Jun 22 17:42:26 It's mainly a bunch of .src.rpm's that gafton imported in September 2004 Jun 22 17:43:10 also things to keep in mind, is there a need for intermediate backups on disk that get archived off to tape at some interval? otherwise recovery takes a bit longer since you have to go find the tape, etc. Jun 22 17:43:26 so we probably have 32GBor so Jun 22 17:43:38 do we have a tape drive or library avaliable? Jun 22 17:43:40 Hey guys, I gotta run, be back on later. Jun 22 17:43:48 mmcgrath: later Jun 22 17:44:03 dferris: tape isn't going to help much Jun 22 17:44:03 dferris: Not directly. I *heart* my rotate-with-hardlinks solution though :) Jun 22 17:44:06 bye mmcgrath Jun 22 17:44:11 lol Jun 22 17:44:11 dferris: there isn't anybody there to rotate tapes. Jun 22 17:44:33 Sopwith: Bacula can _really_ solve that. it does disk volume files that can be created on the fly, and recycled logically Jun 22 17:44:35 good because I hate dealing with my tape library here Jun 22 17:44:51 dferris: I loved the two tape libraries I've worked with. Jun 22 17:46:06 f13: the library works fine, I just don't like dealing with rotating all the tapes, we have more than will fit in the library so I have to import and export tapes. :) Jun 22 17:46:56 and yeah, bacula works great with disk volumes Jun 22 17:48:29 dferris: heh, my weekly tape backups included logic to mark the last used tape as full and prep it for ejection. On monday I'd shuffle a few tapes adn walk away. Another cron job would come along and find the new tapes. I never had to touch the console. Jun 22 17:50:41 sounds like I have more work to do :) Jun 22 17:52:04 <-- ChanServ has quit (zelazny.freenode.net irc.freenode.net) Jun 22 17:54:00 --> ChanServ (ChanServ at services.) has joined #fedora-admin Jun 22 17:54:00 --- irc.freenode.net sets modes [#fedora-admin +o ChanServ] Jun 22 17:54:00 --- ChanServ sets modes [#fedora-admin -o Sopwith] Jun 22 17:54:54 So what else needs discussing? Jun 22 17:55:59 dferris: bacula scripting is fun. I did all mine in python. Jun 22 17:56:33 dgilmore: Is it going to make our backups easier to manage? How does the configuration and administration side of bacula work? Jun 22 17:57:02 f13: I'll have to read more on it. It's been working well enough for the past 2 months that I have left it alone to make sure all the different periods are set right Jun 22 17:57:38 dgilmore: Everything is configured through the config files Jun 22 17:57:41 there are 3 of them Jun 22 17:58:02 most of the admin work for the backup jobs is done in the bacula director config file, like adding jobs, scheduling, etc Jun 22 17:59:50 Sopwith: I dont know if bacula will make things easier Jun 22 17:59:53 yeah, client side is fire and forget Jun 22 18:00:11 all the heavy lifting happens in teh director.conf and possibly the storage.conf Jun 22 18:00:29 90% of the config is done in the bacula-dir.conf Jun 22 18:00:33 but the client just needs to know how to communicate with the director. The director directs the client in everything it needs to do. Jun 22 18:00:39 there are some things that are a pain Jun 22 18:00:43 like adding new hosts Jun 22 18:00:45 there is a nice 900 page manual for it too (: Jun 22 18:00:58 dferris: a properly formatted bacula-dir.conf file makes adding hosts a breeze Jun 22 18:01:07 I sorted mine in a way that made very logical sense. Jun 22 18:01:45 f13: I organized my file, it takes some copying and pasting Jun 22 18:01:47 that's it Jun 22 18:02:27 y5j p cw Jun 22 18:02:32 * f13 loves vim (: Jun 22 18:02:54 * dgilmore loves vim also Jun 22 18:03:00 mmm.. vim7 tabs.. Jun 22 18:03:06 so hot Jun 22 18:03:14 I noticed the other week spot was uning nano Jun 22 18:03:23 * lmacken pukes all over the place Jun 22 18:03:48 spot is special Jun 22 18:04:26 it was his box so he can do what he wants Jun 22 18:05:33 <-- tibbs has quit (Remote closed the connection) Jun 22 18:07:02 Sopwith: As I was writing the voting app I wondered if we could have access to some web frameworks to make it easier to produce. Jun 22 18:09:51 dferris: I think the most important thing is having a central file where we can look to see what's getting backed up, and change it easily Jun 22 18:09:58 abadger1999: TurboGears Jun 22 18:10:09 Sopwith: Is it on the app servers? Jun 22 18:10:14 No :( Jun 22 18:10:19 yeah, that's no problem with bacula Jun 22 18:10:38 Sopwith: Humbug. :-( Jun 22 18:11:07 but first, we need the list of things to back up. Then we can figure out if we want to use bacula :) Jun 22 18:11:12 Sopwith: not only can you look at a file, you can run a cli tool and issue commands to see whats coming up. Jun 22 18:11:22 bacula has a pretty cool console tool Jun 22 18:11:33 and an even more crackrock gnome applet to tell you whats going on. Jun 22 18:11:45 hehe, ok Jun 22 18:12:17 abadger1999: One of my two complaints with TG is that it's a real pain to install. I don't know if it's packaged in Extras, but that'd seem like an interesting project for someone. Jun 22 18:12:31 Sopwith: It's in Extras. Jun 22 18:13:25 Sopwith: I've got it installed but haven't had a project I could use it on yet. Jun 22 18:13:36 Sopwith: What's the other complaint? Jun 22 18:13:49 Learning curve is really steep Jun 22 18:13:50 --> lyz (n=lyz at dsl081-149-006.chi1.dsl.speakeasy.net) has joined #fedora-admin Jun 22 18:14:10 Once you get past those two things, it's great. Jun 22 18:14:42 Hmmm... I've used all the pieces except kid before so I think I'd have fun :-) Jun 22 18:15:08 * f13 goes home Jun 22 18:15:27 Does it have to startup its own server and you need to Proxy it with Apache directives? Jun 22 18:15:48 That was my impression from the app I wrote with it Jun 22 18:16:10 But that'll work fine with our Multitier Web Architecture(tm) Jun 22 18:16:18 * Sopwith always gets a kick out of saying that. Jun 22 18:16:19 TG looks nice Jun 22 18:16:27 Yeah -- that's what I had to do to get a couple cherrypy apps to work. Jun 22 18:17:38 Sopwith: Would it be possible to install it to the app servers or would things like that make it a show stopper for deploying there? Jun 22 18:18:04 abadger1999: I think we could install it as long as we have packages that will run on RHEL-4. Jun 22 18:18:20 Usually FC-3 packages will run fine on RHEL-4. Jun 22 18:18:36 \me thinks of accounts systems rewrites and package db web interfaces that could benefit. Jun 22 18:19:13 yup Jun 22 18:20:36 Looks like TurboGears was first built for FE4. Jun 22 18:20:59 Sopwith: I have to jet, I'll be in touch over the backups Jun 22 18:21:23 dferris: Cool stuff, thanks for making it :) Jun 22 18:21:55 Sopwith: np, I'll try no to be late next week, but I have to take the time to torture the grad students :) Jun 22 18:22:06 <-- dferris has quit ("Ex-Chat") Jun 22 18:22:51 The main problem is that FESCO has this somewhat arbitrary and kooky policy about not making branches < FC-4, so it can be painful From lyz27 at yahoo.com Thu Jun 22 22:36:22 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Thu, 22 Jun 2006 17:36:22 -0500 Subject: [Fedora-infrastructure-list] Account System Updates Message-ID: <1151015782.14289.5.camel@localhost> As mention in today's fedora-admin meeting, I'm looking to put together the requirements for the new account system. I'll slap the requirements on a wiki page to keep track of what's going on. ~lyz From sopwith at redhat.com Thu Jun 22 23:19:32 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 22 Jun 2006 19:19:32 -0400 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <1151015782.14289.5.camel@localhost> References: <1151015782.14289.5.camel@localhost> Message-ID: On Jun 22, 2006, at 18:36, Tom Lynema wrote: > As mention in today's fedora-admin meeting, I'm looking to put > together > the requirements for the new account system. I'll slap the > requirements > on a wiki page to keep track of what's going on. P.S. joe^, if you're around, I didn't mean to exclude you from this process. We did miss you at today's meeting, and everyone who pitches in is welcome :) Best, -- Elliot From gauret at free.fr Fri Jun 23 06:21:41 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 23 Jun 2006 08:21:41 +0200 Subject: [Fedora-infrastructure-list] Introduction Message-ID: <200606230821.41685.gauret@free.fr> Hey y'all I'm very sorry I missed the meeting yesterday, but I'm still interested in helping here. I'm a sysadmin in the real life, doing web development also. I know Python, so I could help with sysadmin tasks and web interfaces/tools. I'm also familiar with Zope, so when Plone goes live I'll be able to hack in some tools if needed. On the Fedora side, I've been a member of Fedora Extras for quite some time, since the fedora.us days actually. I'm a "sponsor" for Extras, so I hope it proves I'm not going to wreak havoc here... :) For the rest, well, http://fedoraproject.org/wiki/AurelienBompard I had in mind to help with one of the task listed on the Schedule : "Fedora Extras sponsors would like to have a easy way to see the relation between people that needs sponsors and the bug(s) where these people submitted their first package(s)". It looks like lyz is assigned to that, but maybe I could give a hand ? Well, there's a thread dedicated to this issue, so I'll just post there :) I'm glad I'll have an opportunity to help Fedora on the sysadmin side, see ya Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Backups are for wimps. Real men upload their work to an ftp server and have everybody mirror it." -- Linus Torvalds From gauret at free.fr Fri Jun 23 06:25:18 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 23 Jun 2006 08:25:18 +0200 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: References: <1151015782.14289.5.camel@localhost> Message-ID: <200606230825.18616.gauret@free.fr> > P.S. joe^, if you're around, I didn't mean to exclude you from this > process. We did miss you at today's meeting, and everyone who pitches > in is welcome :) I'm pitching in ! :) I read the log, but it's not totally clear to me which framwork will be used for the account system. Turbogears ? Cherrypy ? Pure Python/CGI ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr No, I coded it crappily on purpose, just so that I could say: "There's plenty of room for optimization." From mmcgrath at fedoraproject.org Fri Jun 23 13:34:41 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 23 Jun 2006 08:34:41 -0500 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <200606230825.18616.gauret@free.fr> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> Message-ID: <449BEDF1.1060609@fedoraproject.org> Aurelien Bompard wrote: >> P.S. joe^, if you're around, I didn't mean to exclude you from this >> process. We did miss you at today's meeting, and everyone who pitches >> in is welcome :) >> > > I'm pitching in ! :) > I read the log, but it's not totally clear to me which framwork will be used > for the account system. Turbogears ? Cherrypy ? Pure Python/CGI ? > > Aur?lien > Some of us are still under the opinion that it should have an LDAP back end. Any thoughts from the new joiners? -Mike From jcmoore at nuvio.com Fri Jun 23 14:41:50 2006 From: jcmoore at nuvio.com (Curt Moore) Date: Fri, 23 Jun 2006 09:41:50 -0500 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <449BEDF1.1060609@fedoraproject.org> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> <449BEDF1.1060609@fedoraproject.org> Message-ID: <1151073710.31905.10.camel@picard.ojc.nuvio.com> On Fri, 2006-06-23 at 08:34 -0500, Mike McGrath wrote: > Aurelien Bompard wrote: > >> P.S. joe^, if you're around, I didn't mean to exclude you from this > >> process. We did miss you at today's meeting, and everyone who > pitches > >> in is welcome :) > >> > > > > I'm pitching in ! :) > > I read the log, but it's not totally clear to me which framwork will > be used > > for the account system. Turbogears ? Cherrypy ? Pure Python/CGI ? > > > > Aur?lien > > > > Some of us are still under the opinion that it should have an LDAP > back > end. Any thoughts from the new joiners? > > -Mike I agree that LDAP would probably be the way to go for the longer term. While it could be a bit of overkill for now, it has the capability to do and be used for lots of other things in the future as most apps have, can be easily adapted to have, an LDAP interface. Plus, it would likely save some development time and headaches to use an already known working system such as LDAP, maybe Fedora Directory? With that you also get inherent ability for SSL and other neat stuff. Having said that, I probably should also say that I'm not an LDAP expert. I've wanted to move our internal stuff (other than the MS AD stuff which is already doing LDAP) over to LDAP for a while just for the reasons I mentioned above, just never had the time to get around to doing it. In summary, my vote would be for LDAP. -Curt From toshio at tiki-lounge.com Fri Jun 23 17:12:07 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 23 Jun 2006 10:12:07 -0700 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <449BEDF1.1060609@fedoraproject.org> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> <449BEDF1.1060609@fedoraproject.org> Message-ID: <1151082727.3237.23.camel@localhost> On Fri, 2006-06-23 at 08:34 -0500, Mike McGrath wrote: > Aurelien Bompard wrote: > >> P.S. joe^, if you're around, I didn't mean to exclude you from this > >> process. We did miss you at today's meeting, and everyone who pitches > >> in is welcome :) > >> > > > > I'm pitching in ! :) > > I read the log, but it's not totally clear to me which framwork will be used > > for the account system. Turbogears ? Cherrypy ? Pure Python/CGI ? > > > > Aur?lien > > > > Some of us are still under the opinion that it should have an LDAP back > end. Any thoughts from the new joiners? Were the advantages discussed on the sys-admin list? Could the pros and cons be summarised? Every time I look at LDAP I get confused whereas SQL was easy and intuitive to pick up. So as someone who's potentially going to be programing against it, I'd vote for staying with an SQL backend. By the same token, I don't know much about LDAP because I've never done anything useful with it as a backend. Is it easy to extend LDAP data? Is it easy to program against? Can I write arbitrary queries? About the only thing I've heard is that LDAP is: 1) lighter weight than an SQL db esp. when querying data. 2) has lots of admin tools. In regards to 1: - We're going to be running a lot of other tools out of SQL dbs. Does this still make sense when we have to run an LDAP server as an addition to our existing SQL servers? - We'll be querying the data more frequently than adding or updating but it isn't by any means static data. Contributers are constantly requesting addition to new groups, being upgraded, having their requests denied or approved, and so forth. At what amount of data churn does LDAP stop being more efficient than an SQL database? For #2: - What admin tools exist that we'll be able to run? There are admin tools available for SQL db's that we aren't currently using either.... - Are the tools flexible enough to work with the extra data we're going to want to associate with an account or are we going to end up writing external programs to do the job whether they're in an SQL or LDAP backend? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Fri Jun 23 17:32:40 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 23 Jun 2006 10:32:40 -0700 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <200606230825.18616.gauret@free.fr> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> Message-ID: <1151083960.3237.41.camel@localhost> On Fri, 2006-06-23 at 08:25 +0200, Aurelien Bompard wrote: > > P.S. joe^, if you're around, I didn't mean to exclude you from this > > process. We did miss you at today's meeting, and everyone who pitches > > in is welcome :) > > I'm pitching in ! :) > I read the log, but it's not totally clear to me which framwork will be used > for the account system. Turbogears ? Cherrypy ? Pure Python/CGI ? I think everything's currently written in python cgi's. From yesterday's after meeting conversations, I think we're all impressed with TurboGears. If we can get it updated and building on FC3 then we can install it to the app servers (RHEL4). Elliot seems to have no problems with building servers under the TurboGears model and configuring Apache to ProxyPass to them. Ignacio (TurboGears maintainer in Extras) has been busy and I haven't seen him on IRC lately. He's responded promptly to bugzilla, though. If we get things running smoothly and let him know what we want to do he might be open to us co-maintaining and managing the FE3 branch. Tom (lyz) was going to look into upgrading and if anything special needed to be done to get it running on RHEL4/FC3. I don't think he's a member of cvsextras, though, so someone else would have to step in as official co-maintainer if Ignacio wants that *nudge nudge* -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sopwith at redhat.com Fri Jun 23 20:06:25 2006 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 23 Jun 2006 16:06:25 -0400 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <449BEDF1.1060609@fedoraproject.org> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> <449BEDF1.1060609@fedoraproject.org> Message-ID: <691ECD05-52EB-4916-9402-B22095147A77@redhat.com> On Jun 23, 2006, at 09:34, Mike McGrath wrote: > Some of us are still under the opinion that it should have an LDAP > back end. Any thoughts from the new joiners? Yea, we need to restart that discussion on this list... Toshio wound up making the points in his post that I would have made, but in a more elegant way. So, "what he said" :) Best, -- Elliot From mmcgrath at fedoraproject.org Fri Jun 23 21:32:17 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 23 Jun 2006 16:32:17 -0500 Subject: [Fedora-infrastructure-list] Backup thread Message-ID: <449C5DE1.7080804@fedoraproject.org> Hey guys, thought I'd start a backup thread. One thing I'd like to start doing is backing up the home directories, I've had my home dir blown out a couple of times that resulted in script loss. Same thing happened recently to some of the FESCo candidates who had their access revoked to ensure a fair election :-D. Refer to previous meeting notes and list emails for whats been said so far but here's the short list: bacula, amanda, rsync and scrips, rdiff-backup dgilmore is one of the guys leading the backup stuffbut participation is encouraged by everyone. I'd like to throw backuppc in the list just because I use it / like it. It might be good for our environment. I get the sense that bacula is the current front runner. One thing should be noted. Whatever system we go with needs to be in Extras or Core so we can guarantee ongoing support. But lots of good products have gotten into our repos this way (Nagios :-P). I'd prefer whatever we choose to have native ssh tunnel support. if this isn't possible we can always create the tunnels manually. For those that aren't familiar we have 2 primary sites, one in Phoenix and one at Duke. These two sites are somewhat linked but still pretty separate. Any thoughts / suggestions? From kzak at redhat.com Fri Jun 23 22:23:48 2006 From: kzak at redhat.com (Karel Zak) Date: Sat, 24 Jun 2006 00:23:48 +0200 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <1151082727.3237.23.camel@localhost> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> <449BEDF1.1060609@fedoraproject.org> <1151082727.3237.23.camel@localhost> Message-ID: <20060623222347.GY11973@petra.dvoda.cz> On Fri, Jun 23, 2006 at 10:12:07AM -0700, Toshio Kuratomi wrote: > > Some of us are still under the opinion that it should have an LDAP back > > end. Any thoughts from the new joiners? > > Were the advantages discussed on the sys-admin list? Could the pros and > cons be summarised? > > Every time I look at LDAP I get confused whereas SQL was easy and > intuitive to pick up. So as someone who's potentially going to be hehe.. good point :-) > programing against it, I'd vote for staying with an SQL backend. > > By the same token, I don't know much about LDAP because I've never done > anything useful with it as a backend. Is it easy to extend LDAP data? > Is it easy to program against? Can I write arbitrary queries? > > About the only thing I've heard is that LDAP is: > 1) lighter weight than an SQL db esp. when querying data. > 2) has lots of admin tools. > > In regards to 1: > - We're going to be running a lot of other tools out of SQL dbs. Does > this still make sense when we have to run an LDAP server as an addition > to our existing SQL servers? Agree. There is not the one best tool for everyone. You have to look for the best tool for you and for your team. I think this team is already familiar with SQL... > - We'll be querying the data more frequently than adding or updating but > it isn't by any means static data. The database engine is just storage only. It's problem for middle tier how often it will be ask for "almost static" data. (Hint: cache..) > Contributers are constantly > requesting addition to new groups, being upgraded, having their requests > denied or approved, and so forth. At what amount of data churn does > LDAP stop being more efficient than an SQL database? LDAP is fast filesystem with btree and it's able to found an object very fast, but I'm not sure with more complex queries (like joins between more tables in SQL), crash recovery, redo logs, effective backups, etc. > For #2: > - What admin tools exist that we'll be able to run? There are admin > tools available for SQL db's that we aren't currently using either.... I'm 100% that SQL has more devel/admin tools than LDAP. See around, SQL is everywhere. > > - Are the tools flexible enough to work with the extra data we're going Please, define "extra data". > to want to associate with an account or are we going to end up writing > external programs to do the job whether they're in an SQL or LDAP > backend? Karel -- Karel Zak From toshio at tiki-lounge.com Fri Jun 23 22:46:58 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 23 Jun 2006 15:46:58 -0700 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <20060623222347.GY11973@petra.dvoda.cz> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> <449BEDF1.1060609@fedoraproject.org> <1151082727.3237.23.camel@localhost> <20060623222347.GY11973@petra.dvoda.cz> Message-ID: <1151102818.3237.53.camel@localhost> On Sat, 2006-06-24 at 00:23 +0200, Karel Zak wrote: > On Fri, Jun 23, 2006 at 10:12:07AM -0700, Toshio Kuratomi wrote: > > > > - Are the tools flexible enough to work with the extra data we're going > > Please, define "extra data". > > > to want to associate with an account or are we going to end up writing > > external programs to do the job whether they're in an SQL or LDAP > > backend? The one that sticks out to me is Fedora Extra's desire for more information about a user when deciding to sponsor a person. The initial request is to query bugzilla for packaging reviews when deciding on sponsorship. We can probably do that entirely within the web app (Use the email address(es) given in accounts to construct a query.) The general need for information could extend to other things, though: web links to other projects the user is a member of (jpackage, redhat-kde), reviews done at The Repository That Must Not be Named, etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linux at elfshadow.net Sat Jun 24 00:53:39 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Fri, 23 Jun 2006 20:53:39 -0400 Subject: [Fedora-infrastructure-list] Backup thread In-Reply-To: <449C5DE1.7080804@fedoraproject.org> References: <449C5DE1.7080804@fedoraproject.org> Message-ID: <449C8D13.5030600@elfshadow.net> Mike McGrath wrote: > Refer to previous meeting notes and list emails for whats been said so > far but here's the short list: > > bacula, amanda, rsync and scrips, rdiff-backup > > dgilmore is one of the guys leading the backup stuffbut participation > is > encouraged by everyone. I'd like to throw backuppc in the list just > because I use it / like it. It might be good for our environment. From what I have seen of backuppc I also agree it might be a good one to have on the list. > Any thoughts / suggestions? My main thoughts at this point would be to compose a list of our requirements (what are we planning to backup, how much data, type of rotation, etc). I do agree with Mike that adding home directories to the list of what we back up would probably be worthwhile, especially since a few people have lost things in the past. The native ssh support would also be a good thing. Once we have a list of requirements the backup packages can be better compared to see how well they meet our needs. later, Jeffrey From linux at elfshadow.net Sat Jun 24 01:23:28 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Fri, 23 Jun 2006 21:23:28 -0400 Subject: [Fedora-infrastructure-list] Account System Updates In-Reply-To: <449BEDF1.1060609@fedoraproject.org> References: <1151015782.14289.5.camel@localhost> <200606230825.18616.gauret@free.fr> <449BEDF1.1060609@fedoraproject.org> Message-ID: <449C9410.1040506@elfshadow.net> Mike McGrath wrote: > Some of us are still under the opinion that it should have an LDAP back > end. Any thoughts ... ? An LDAP backend sounds appealing as a handful of others have mentioned. At the same time though it sounds like a lot of the team's experience leans towards the SQL end of things. Because of that I tend towards the SQL side. I also think Toshio brings up several good points in his email. But... before we get too far ahead of ourselves, I think much like the backup discussion we will be doing ourselves a favor to outline the requirements of Account System updates. What makes it to the requirements list might have some bearing on which backend makes the most sense. I think others on the list are probably more in tune with what the requirements are. I think we could also learn a lot from the common complaints about the current system. Between those two lists we should be able to come up with a good plan (including more info to help with the SQL versus LDAP backend). later, Jeffrey From dennis at ausil.us Sun Jun 25 15:43:58 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 25 Jun 2006 10:43:58 -0500 Subject: [Fedora-infrastructure-list] Backup thread In-Reply-To: <449C8D13.5030600@elfshadow.net> References: <449C5DE1.7080804@fedoraproject.org> <449C8D13.5030600@elfshadow.net> Message-ID: <200606251043.58327.dennis@ausil.us> On Friday 23 June 2006 19:53, Jeffrey Tadlock wrote: > Mike McGrath wrote: > > Refer to previous meeting notes and list emails for whats been said so > > far but here's the short list: > > > > bacula, amanda, rsync and scrips, rdiff-backup > > > > dgilmore is one of the guys leading the backup stuffbut participation > > is > > encouraged by everyone. I'd like to throw backuppc in the list just > > because I use it / like it. It might be good for our environment. > > From what I have seen of backuppc I also agree it might be a good one > to have on the list. Ill check it out, > > Any thoughts / suggestions? > > My main thoughts at this point would be to compose a list of our > requirements (what are we planning to backup, how much data, type of > rotation, etc). Right now there are some cvs repositories, database dumps, and some other files at about 34GB of data. Id need someone with the right access to do a du -hs /home on each server that has home dirs needing backup. to know how big that is. I would think that we would do weekly full backup daily incrementals, and keep 3 or 4 weeks worth. > I do agree with Mike that adding home directories to the list of what we > back up would probably be worthwhile, especially since a few people have > lost things in the past. The native ssh support would also be a good > thing. native ssh support is definetly something that will be useful > Once we have a list of requirements the backup packages can be better > compared to see how well they meet our needs. -- Dennis Gilmore, RHCE Proud Australian From jason at 3dogs.us Mon Jun 26 05:25:43 2006 From: jason at 3dogs.us (Jason Hartley) Date: Mon, 26 Jun 2006 01:25:43 -0400 (EDT) Subject: [Fedora-infrastructure-list] Re: Introduction In-Reply-To: <1151105440.31905.69.camel@picard.ojc.nuvio.com> References: <1151105440.31905.69.camel@picard.ojc.nuvio.com> Message-ID: <60581.192.168.0.10.1151299543.squirrel@www.3dogs.us> On Fri, June 23, 2006 7:30 pm, Curt Moore wrote: > Hi Jason. > > At the suggestion of Elliot Lee, I'm contacting you about the Mirror > Management project. > > I'd like to help so please let me know what I can do. > > I saw that there was talk about borrowing the CentOS mirroring product. > Has anyone over at CentOS been contacted about this? I used to work > with some of the CentOS maintainers, but haven't spoken with them in a > while, but it may be an "in". > > Please let me know where things stand. > > Thanks! > -Curt Hey Curt, Seth Vidal has been working with Lance from the Centos team on getting the Centos mirroring code. If know or would like to contact Lance about the code, I am sure Seth would not mind. Currently we have the cron job that runs to see what mirror sites are stall. Here is the break down of Centos Mirroring: """ It's broken up into 3 parts: 1. one part queries their mysql database of the mirrors and builds a mirrorlist using geoip 2. another part is a cron job that connects to the mirrors and grabs the repomd.xml off of them to determine 'freshness' 3. the last part generates the web page based on the database info """ In addition to the 3 parts, we also need the table structure of their database. Thanks, for your help! Regards, Jason Hartley From jcmoore at nuvio.com Mon Jun 26 16:46:27 2006 From: jcmoore at nuvio.com (Curt Moore) Date: Mon, 26 Jun 2006 11:46:27 -0500 Subject: [Fedora-infrastructure-list] DB Server Upgrade Message-ID: <1151340388.3519.32.camel@picard.ojc.nuvio.com> Jeffrey/All: I've been corresponding off-list with Elliot with regard to upgrading db1. At his suggestion, I'm going to run my proposed process by everyone for feedback. I went through a production DB server upgrade a while back and this process reflects what I did then and lessons learned during the process. I also had Slony in this mix, which resulted in a few more steps. From what I've read on the wiki pages regarding the current Fedora infrastructure setup, there is only 1 DB server, a SPOF. It may be worth the time to start a separate conversation about some sort of replication or clustered setup, which a beast unto itself. I have a master/slave replication setup with Slony which works quite well. You still have the SPOF with the master but at least you can load balance between the slaves and still have read access going if the master goes down. With all of the research I've done, I've not found anything which is production ready and allows a multi master scenario for Postgres, only master/slave scenario with replication, like Slony. The closest thing I found was PGCluster but it was very flaky, at least on 8.x, the last time I played with it late last year. PGCluster was also very hardware intensive, meaning it takes like 4 machines to run a setup without a SPOF. The following assumes the desire for as minimal as possible downtime and as a result is a little more involved than if more downtime were tolerable. I welcome comments and refinements to the process. Now, onto the upgrade process. *** Make a DB and filesystem backup *** Ensure that all necessary config files are archived so they can be quickly reinstalled via kickstart later 1) Setup all apps to connect to DB using a host alias in /etc/hosts 2) Setup another server as a temporary DB server Note: An option here is to copy data to the temp DB server and do an immediate cut over to the temp server after the data has been copied but you run the risk of data being out of sync between the master and temp server. Danger, Will Robinson! 3) Temporarily disable apps hitting DB 4) pg_dump DBs and template0, users, groups, etc over to temp server 5) Test to ensure DB is up and accepting connections 6) Change the alias entry in /etc/hosts on hosts running apps to the record for the temp DB server 7) Re-enable apps 8) Re-install and configure OS on old DB server via kickstart 9) Temporarily disable apps hitting DB 10) pg_dump DBs and template0, users, groups, etc over to master server 11) Test to ensure master DB is up and accepting connections 12) Change the alias entry in /etc/hosts on servers running apps back to the record for the master DB server There, my 12 step program for a DB upgrade. :-) I had a few more Slony related steps which required shuffling the app servers between Slony slaves and the master but the above it basically the process. I made a few decisions/assumptions during my process. In my case since 99% of DB hits were reads,I still had my Slony slaves accepting read requests. I was able to do this since I maintain both read and write DB handles in the SoftSwitch. Some apps allow a "degraded" mode where data is "read only" just for this sort of thing, I'm not sure if this is the case here or not. During the time I disabled the apps to copy over the DB to the temp server, users just couldn't login to the web portal to change their settings, which are written to the master, for a few minutes. I had to ask, would this really be an issue for 5 min at 3am CST on a Sunday morning? (assuming that the DBs can be copied in the span of 5 min, I have a VLAN'd GigE management network for this sort of thing) The same downtime was experienced when I switched back over to the master DB. Since I'm assuming we're upgrading from Postgres 7.x we'll definitely want to do a pg_dump/pg_restore since there are some inherent differences in the data structures on the disk. In the past I've just stopped postgres, copied over /var/lib/pgsql to the new server and started postgres there, and called it good but you can't do that when upgrading from 7.x to 8.x. Since the data itself has to be migrated from the 7.x format to the 8.x format at some point, there is probably going to have to be some measure of downtime. Otherwise you get into having to compare data in 2 different databases to see if anything changed and manually replicating those changes to the master copy. For me, the 5 min of partial downtime was _much_ cheaper. I look forward to discussion on this. Cheers, -Curt From wtogami at redhat.com Mon Jun 26 21:08:17 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 26 Jun 2006 17:08:17 -0400 Subject: [Fedora-infrastructure-list] Auth Failure with extras-sync Message-ID: <44A04CC1.7020503@redhat.com> Test sync build at fedora.linux.duke.edu's password: It seems that pass-through ssh key authentication isn't working anymore. Was my account disabled on fedora.linux.duke.edu due the Extras election too, or is this some other issue? Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Tue Jun 27 01:12:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 27 Jun 2006 03:12:44 +0200 Subject: [Fedora-infrastructure-list] Auth Failure with extras-sync In-Reply-To: <44A04CC1.7020503@redhat.com> References: <44A04CC1.7020503@redhat.com> Message-ID: <20060627031244.31b4ce13.bugs.michael@gmx.net> On Mon, 26 Jun 2006 17:08:17 -0400, Warren Togami wrote: > Test sync > build at fedora.linux.duke.edu's password: > > It seems that pass-through ssh key authentication isn't working anymore. > Was my account disabled on fedora.linux.duke.edu due the Extras > election too, or is this some other issue? Cannot confirm. Push+sync in progress... From linux at elfshadow.net Tue Jun 27 01:54:44 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Mon, 26 Jun 2006 21:54:44 -0400 Subject: [Fedora-infrastructure-list] Re: DB Server Upgrade In-Reply-To: <1151340388.3519.32.camel@picard.ojc.nuvio.com> References: <1151340388.3519.32.camel@picard.ojc.nuvio.com> Message-ID: <44A08FE4.1000907@elfshadow.net> Curt Moore wrote: > I also had Slony in this mix, which resulted in a few more steps. From > what I've read on the wiki pages regarding the current Fedora > infrastructure setup, there is only 1 DB server, a SPOF. It may be > worth the time to start a separate conversation about some sort of > replication or clustered setup, which a beast unto itself. Correct, there is one DB server at this time (making upgrades even more fun!). I think a conversation about a replicated or clustered setup would be good. At least getting some ideas thrown out there on the table. > Now, onto the upgrade process. > > *** Make a DB and filesystem backup *** > Ensure that all necessary config files are archived so they can be > quickly reinstalled via kickstart later > > 1) Setup all apps to connect to DB using a host alias in /etc/hosts > 2) Setup another server as a temporary DB server > 3) Temporarily disable apps hitting DB > 4) pg_dump DBs and template0, users, groups, etc over to temp server > 5) Test to ensure DB is up and accepting connections > 6) Change the alias entry in /etc/hosts on hosts running apps to the > record for the temp DB server > 7) Re-enable apps > 8) Re-install and configure OS on old DB server via kickstart > 9) Temporarily disable apps hitting DB > 10) pg_dump DBs and template0, users, groups, etc over to master server > 11) Test to ensure master DB is up and accepting connections > 12) Change the alias entry in /etc/hosts on servers running apps back to > the record for the master DB server > > There, my 12 step program for a DB upgrade. :-) This looks like a good start to the plan to me. I had mentioned possibly using one of the app servers as a temporary DB server during the upgrade of the DB server. People were receptive to the idea when I mentioned it awhile back. Some of the ugprades have been fun, so not having to worry as much about a very tight time limit should the upgrade of the OS go poorly can make it easier. > During the time I disabled the apps to copy over the DB to the temp > server, users just couldn't login to the web portal to change their > settings, which are written to the master, for a few minutes. I had to > ask, would this really be an issue for 5 min at 3am CST on a Sunday > morning? (assuming that the DBs can be copied in the span of 5 min, I > have a VLAN'd GigE management network for this sort of thing) The same > downtime was experienced when I switched back over to the master DB. The downtime for the swap to a temp server and then back to the real server shouldn't be a major issue. Obviously the less downtime the better, but the little bits of downtime doing those flip-flops would be less than just taking the DB box down completely during the upgrade. Elliot, feel free to correct me here! ;) > Since I'm assuming we're upgrading from Postgres 7.x we'll definitely > want to do a pg_dump/pg_restore since there are some inherent > differences in the data structures on the disk. Elliot had expressed interest at going to an 8.x version. Thanks! Jeffrey From linux at elfshadow.net Tue Jun 27 17:11:58 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Tue, 27 Jun 2006 13:11:58 -0400 Subject: [Fedora-infrastructure-list] Backup thread In-Reply-To: <200606251043.58327.dennis@ausil.us> References: <449C5DE1.7080804@fedoraproject.org> <449C8D13.5030600@elfshadow.net> <200606251043.58327.dennis@ausil.us> Message-ID: <44A166DE.9000409@elfshadow.net> Dennis Gilmore wrote: > Right now there are some cvs repositories, database dumps, and some other > files at about 34GB of data. Id need someone with the right access to do a > du -hs /home on each server that has home dirs needing backup. to know how > big that is. I spot checked a few of the boxes to see what their /home size was. Of the app, proxy and db boxes had nothing over 36MB. The internal box we use for our internal cvs repo had the largest /home at 728MB. Probably a fair portion of that was just people's sandboxes. As I think more about it, rather than backup all /homes, how about we choose one that we let people know it is backed up and the others aren't. As we work on scripts and such we know that if we expect it to be backed up that we keep it on the box that has /home backed up. I would lean towards the box with the internal cvs repo that gets /home backed up (currently at 728MB). What do people think about that? > I would think that we would do weekly full backup daily incrementals, and > keep 3 or 4 weeks worth. That sounds like the same ballpark I would have ended up in. Jeffrey From jcmoore at nuvio.com Tue Jun 27 19:09:02 2006 From: jcmoore at nuvio.com (Curt Moore) Date: Tue, 27 Jun 2006 14:09:02 -0500 Subject: [Fedora-infrastructure-list] Backup thread In-Reply-To: <44A166DE.9000409@elfshadow.net> References: <449C5DE1.7080804@fedoraproject.org> <449C8D13.5030600@elfshadow.net> <200606251043.58327.dennis@ausil.us> <44A166DE.9000409@elfshadow.net> Message-ID: <1151435342.11097.15.camel@picard.ojc.nuvio.com> On Tue, 2006-06-27 at 13:11 -0400, Jeffrey Tadlock wrote: > Dennis Gilmore wrote: > > Right now there are some cvs repositories, database dumps, and some other > > files at about 34GB of data. Id need someone with the right access to do a > > du -hs /home on each server that has home dirs needing backup. to know how > > big that is. > > I spot checked a few of the boxes to see what their /home size was. Of > the app, proxy and db boxes had nothing over 36MB. The internal box we > use for our internal cvs repo had the largest /home at 728MB. Probably > a fair portion of that was just people's sandboxes. As much as it pains me to mention it (as I think of NFS), would it be worth looking at some sort of centralized storage so that the home directories are the same across all boxes? Likely NFS is not the best solution here but it's the first that came to mind. I had separate home directories on my systems a while back and we ran into the same sort of debacle, not knowing on which box things were stored, what had been backed up, managing profile settings across machines, etc. Since switching everything to use NFS it's made things a lot easier from an admin standpoint. Of course, I have a private GigE LAN between all of the boxes so it makes this type of setup much easier. If centralized home directories were coupled with a centralized account management system, like with LDAP, it could be very powerful and ease system administration. This is, of course, the debate going on over in the thread discussing the account system. > > As I think more about it, rather than backup all /homes, how about we > choose one that we let people know it is backed up and the others > aren't. As we work on scripts and such we know that if we expect it to > be backed up that we keep it on the box that has /home backed up. I > would lean towards the box with the internal cvs repo that gets /home > backed up (currently at 728MB). What do people think about that? Sounds like a good idea. Would it be worth enforcing some user/group disk quotas, if there aren't already, so that people don't knowingly or inadvertently abuse the fact that it's somewhat of the central archive? If so, at what values should these quotas set? -Curt From mmcgrath at fedoraproject.org Tue Jun 27 19:52:05 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 27 Jun 2006 14:52:05 -0500 Subject: [Fedora-infrastructure-list] Webmaster account now part of a the ticketing system Message-ID: <44A18C65.2070300@fedoraproject.org> The webmaster at fedoraproject.org account is now part of the ticketing system. Emails sent to webmaster at fedoraproject.org will automatically get created in the webmaster queue. Users who would like access to the system to answer emails on behalf of the webmaster email address please see the web address that should be printed below. This is the first account we've put in the OTRS like this. Please let us know what you guys think of it because eventually we'd like to move other accounts into the system. As a test I'd like someone in the web-members group who already has access to the ticketing system to lock it and close it. -Mike From sopwith at redhat.com Tue Jun 27 20:07:52 2006 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 27 Jun 2006 16:07:52 -0400 Subject: [Fedora-infrastructure-list] Backup thread In-Reply-To: <1151435342.11097.15.camel@picard.ojc.nuvio.com> References: <449C5DE1.7080804@fedoraproject.org> <449C8D13.5030600@elfshadow.net> <200606251043.58327.dennis@ausil.us> <44A166DE.9000409@elfshadow.net> <1151435342.11097.15.camel@picard.ojc.nuvio.com> Message-ID: On Jun 27, 2006, at 15:09, Curt Moore wrote: > As much as it pains me to mention it (as I think of NFS), would it be > worth looking at some sort of centralized storage so that the home > directories are the same across all boxes? Likely NFS is not the best > solution here but it's the first that came to mind. So my impression is that we're supposed to have some disk space available on the NetApp there... I think, though, that we want to avoid encouraging people to store anything in their home directories at this point, because then we wind up starting being a shell-account-hoster instead of focusing on making Fedora better. If we do really need shared homedirs, let's look into putting them on the NetApp. Otherwise, let's just not worry about backing them up... Best, -- Elliot From michael at knox.net.nz Tue Jun 27 20:10:52 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 28 Jun 2006 08:10:52 +1200 Subject: [Fedora-infrastructure-list] Backup thread In-Reply-To: References: <449C5DE1.7080804@fedoraproject.org> <449C8D13.5030600@elfshadow.net> <200606251043.58327.dennis@ausil.us> <44A166DE.9000409@elfshadow.net> <1151435342.11097.15.camel@picard.ojc.nuvio.com> Message-ID: <44A190CC.30502@knox.net.nz> Elliot Lee wrote: > > On Jun 27, 2006, at 15:09, Curt Moore wrote: > >> As much as it pains me to mention it (as I think of NFS), would it be >> worth looking at some sort of centralized storage so that the home >> directories are the same across all boxes? Likely NFS is not the best >> solution here but it's the first that came to mind. > > > So my impression is that we're supposed to have some disk space > available on the NetApp there... > > I think, though, that we want to avoid encouraging people to store > anything in their home directories at this point, because then we wind > up starting being a shell-account-hoster instead of focusing on making > Fedora better. > > If we do really need shared homedirs, let's look into putting them on > the NetApp. Otherwise, let's just not worry about backing them up... > make shell account holders homes /tmp and make sure there is a cron clean up script ;) Michael From jcmoore at nuvio.com Tue Jun 27 20:59:10 2006 From: jcmoore at nuvio.com (Curt Moore) Date: Tue, 27 Jun 2006 15:59:10 -0500 Subject: [Fedora-infrastructure-list] Backup thread In-Reply-To: References: <449C5DE1.7080804@fedoraproject.org> <449C8D13.5030600@elfshadow.net> <200606251043.58327.dennis@ausil.us> <44A166DE.9000409@elfshadow.net> <1151435342.11097.15.camel@picard.ojc.nuvio.com> Message-ID: <1151441950.11097.21.camel@picard.ojc.nuvio.com> On Tue, 2006-06-27 at 16:07 -0400, Elliot Lee wrote: > So my impression is that we're supposed to have some disk space > available on the NetApp there... > > I think, though, that we want to avoid encouraging people to store > anything in their home directories at this point, because then we > wind up starting being a shell-account-hoster instead of focusing on > making Fedora better. I would agree, mount the home directories on the NetApp. Also setup some relatively small quotas so that there isn't the ability or temptation to have users host their shell account on the Fedora boxes. If a user needs more space for legitimate Fedora work, raise their quota. Otherwise as Elliot said, there is the feeling you're becoming a shell account hoster. -Curt From lyz27 at yahoo.com Tue Jun 27 22:56:39 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Tue, 27 Jun 2006 17:56:39 -0500 Subject: [Fedora-infrastructure-list] Making RPMS for TurboGears Message-ID: <1151448999.14185.27.camel@localhost> Here's a few things I found out while making the rpms for TurboGears, and a few questions that have now resulted. I've attached an irc log of a chat I had in #turbogears. They say that packaging a python module as a .egg file isn't necessary. This means that the python-Testgears spec can be, and probably should be, modified to use the --single-version-externally-managed flag. TurboGears will work just fine without python-TestGears. It's just a testing suite. Should the dependency be taken out of the TurboGears package? Also, the people in #turbogears (specifically evelind) say that they don't even use python-TestGears and instead have moved on to nose (http://python.org/pypi/nose). Should I package nose or python-TestGears or both? There is also a like to the Debian guidelines on python packages. http://wiki.debian.org/DebianPython/NewPolicy . I don't know if anything in there applies, but it might. ~tom -------------- next part -------------- * Now talking on #turbogears * Topic for #turbogears is: http://www.turbogears.org || Planet Turbogears: http://planet.turbogears.org || SVN is at http://www.turbogears.org/svn/turbogears || Pastebin: http://tg.pastebin.com || 0.9a6 is out! See http://www.turbogears.org/preview/ * Topic for #turbogears set by splee at Fri May 19 10:35:02 2006 -ChanServ- [#turbogears] This channel is logged: http://irclog.turbogears.org/archive/freenode/turbogears/ lyz anyone available for a packaging question? lyz makeing an rpm for RHEL4 * Bader has quit (Connection timed out) lyz here it goes.. does TurboGears require that TestGears is in an egg package? wormtongue I know that some folks install without ever using an egg.. they're good for dependancies for us normal folks. lyz if the system is using rpm to manage the deps is ther any reason to use eggs? wormtongue See if you can attract jtate's attention - I think it was Him who said He does not install with eggs. * benbange1t has quit (Remote closed the connection) >jtate< you there? * [jtate] is away (gone) lyz I'll hang out for a while thanks wormtongue * fijal (n=kvirc at polpak-98.daleka.net) has left #turbogears kov lyz: TurboGears and some other software really want to have at least the egg information elvelind lyz: first of. TestGears is acually not used any more by TG. We now use Nose for testing. kov lyz: you'll want to install stuff passing --single-version-externally-managed to setup.py kov http://wiki.debian.org/DebianPython/NewPolicy may be of help * Tybstar (n=tgerla at cpe-069-134-165-153.nc.res.rr.com) has joined #turbogears lyz kov, the --single-version-externally-managed flag overrides the creation of the egg file. Is this the desired result? kov lyz: yes kov lyz: you'll only install the EGG-INFO directory, then, which is enough for setuptools' pkg_resources to find the information it wants kov and the files go as they would lyz kov, nice. That's how I'll do it then. Thanks lyz kov, also thanks for the link kov lyz: =) lyz elvelind, where can I find this nose of which you speak elvelind lyz: http://python.org/pypi/nose elvelind lyz: but it's not required for tg to work. just for running the tests lyz elvelind, I take it that TestGears isn't required either then elvelind lyz: exactly lyz elvelind, ok I'll work on taking that dep off of the TurboGears RPM in the fedora extras then. I'll also try to package nose up lyz thanks all -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From kzak at redhat.com Wed Jun 28 08:50:49 2006 From: kzak at redhat.com (Karel Zak) Date: Wed, 28 Jun 2006 10:50:49 +0200 Subject: [Fedora-infrastructure-list] public lab Message-ID: <20060628085049.GD3172@petra.dvoda.cz> Hi, is there any public bunch of computers where upstream developers can test their applications on Fedora? I know about upstream developers who don't use Linux as primary OS or they use different distributions and test upstream code with things like SELinux is difficult without access to machine with useful FC. Karel -- Karel Zak From jkeating at redhat.com Wed Jun 28 13:32:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Jun 2006 09:32:21 -0400 Subject: [Fedora-infrastructure-list] public lab In-Reply-To: <20060628085049.GD3172@petra.dvoda.cz> References: <20060628085049.GD3172@petra.dvoda.cz> Message-ID: <200606280932.24598.jkeating@redhat.com> On Wednesday 28 June 2006 04:50, Karel Zak wrote: > ?is there any public bunch of computers where upstream developers can > ?test their applications on Fedora? I know about upstream developers > ?who don't use Linux as primary OS or they use different distributions > ?and test upstream code with things like SELinux is difficult without > ?access to machine with useful FC. Nothing at this time. This sounds like something the upcoming Fedora Test project could handle though, running arbitrary test cases across a lab of computers. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kzak at redhat.com Wed Jun 28 20:37:53 2006 From: kzak at redhat.com (Karel Zak) Date: Wed, 28 Jun 2006 22:37:53 +0200 Subject: [Fedora-infrastructure-list] public lab In-Reply-To: <200606280932.24598.jkeating@redhat.com> References: <20060628085049.GD3172@petra.dvoda.cz> <200606280932.24598.jkeating@redhat.com> Message-ID: <20060628203651.GG3172@petra.dvoda.cz> On Wed, Jun 28, 2006 at 09:32:21AM -0400, Jesse Keating wrote: > On Wednesday 28 June 2006 04:50, Karel Zak wrote: > > ?is there any public bunch of computers where upstream developers can > > ?test their applications on Fedora? I know about upstream developers > > ?who don't use Linux as primary OS or they use different distributions > > ?and test upstream code with things like SELinux is difficult without > > ?access to machine with useful FC. > > Nothing at this time. This sounds like something the upcoming Fedora Test > project could handle though, running arbitrary test cases across a lab of > computers. I think about something like shell access rather than about test lab with very limited access only. Sure, we cannot give this kind of account to anonymous users, but I think for good know and reliable people in community is it possible way. (Maybe we can try use virtual Xen machine that will be reseted upon a user's logout). We in Brno office planing new infrastructure now. I can try allocate some HW for this thing. Or is it completely wrong idea? Comments? Karel -- Karel Zak From sopwith at redhat.com Wed Jun 28 20:49:34 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 28 Jun 2006 16:49:34 -0400 Subject: [Fedora-infrastructure-list] public lab In-Reply-To: <20060628085049.GD3172@petra.dvoda.cz> References: <20060628085049.GD3172@petra.dvoda.cz> Message-ID: <893A8F59-2345-454B-A3DF-2EE4BA78952E@redhat.com> On Jun 28, 2006, at 04:50, Karel Zak wrote: > is there any public bunch of computers where upstream developers can > test their applications on Fedora? I know about upstream developers > who don't use Linux as primary OS or they use different distributions > and test upstream code with things like SELinux is difficult without > access to machine with useful FC. Doesn't SourceForge have shell accounts for developers? Best, -- Elliot From kwade at redhat.com Wed Jun 28 06:29:31 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 27 Jun 2006 23:29:31 -0700 Subject: [Fedora-infrastructure-list] Re: Webmaster account now part of a the ticketing system In-Reply-To: <44A18C65.2070300@fedoraproject.org> References: <44A18C65.2070300@fedoraproject.org> Message-ID: <1151476171.2489.493.camel@erato.phig.org> On Tue, 2006-06-27 at 14:52 -0500, Mike McGrath wrote: > This is the first account we've put in the OTRS like this. Please let > us know what you guys think of it because eventually we'd like to move > other accounts into the system. OTRS? -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at fedoraproject.org Wed Jun 28 06:44:54 2006 From: russell at fedoraproject.org (Russell John) Date: Wed, 28 Jun 2006 12:44:54 +0600 Subject: [Fedora-infrastructure-list] Re: Webmaster account now part of a the ticketing system In-Reply-To: <1151476171.2489.493.camel@erato.phig.org> References: <44A18C65.2070300@fedoraproject.org> <1151476171.2489.493.camel@erato.phig.org> Message-ID: <44A22566.8060200@fedoraproject.org> OTRS => Open source Ticket Request System Karsten Wade wrote: > On Tue, 2006-06-27 at 14:52 -0500, Mike McGrath wrote: > >> This is the first account we've put in the OTRS like this. Please let >> us know what you guys think of it because eventually we'd like to move >> other accounts into the system. > > OTRS? > -- Fedora Ambassador for Bangladesh From kzak at redhat.com Wed Jun 28 21:34:41 2006 From: kzak at redhat.com (Karel Zak) Date: Wed, 28 Jun 2006 23:34:41 +0200 Subject: [Fedora-infrastructure-list] public lab In-Reply-To: <893A8F59-2345-454B-A3DF-2EE4BA78952E@redhat.com> References: <20060628085049.GD3172@petra.dvoda.cz> <893A8F59-2345-454B-A3DF-2EE4BA78952E@redhat.com> Message-ID: <20060628213441.GH3172@petra.dvoda.cz> On Wed, Jun 28, 2006 at 04:49:34PM -0400, Elliot Lee wrote: > > On Jun 28, 2006, at 04:50, Karel Zak wrote: > > > is there any public bunch of computers where upstream developers can > > test their applications on Fedora? I know about upstream developers > > who don't use Linux as primary OS or they use different distributions > > and test upstream code with things like SELinux is difficult without > > access to machine with useful FC. > > Doesn't SourceForge have shell accounts for developers? With actual FC and with (for example) SELinux, gcc, ... ? I don't talk about "home" for developers, but about place where developer can try recompile his code on actual FC. Karel -- Karel Zak From toshio at tiki-lounge.com Wed Jun 28 22:09:27 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 28 Jun 2006 15:09:27 -0700 Subject: [Fedora-infrastructure-list] public lab In-Reply-To: <893A8F59-2345-454B-A3DF-2EE4BA78952E@redhat.com> References: <20060628085049.GD3172@petra.dvoda.cz> <893A8F59-2345-454B-A3DF-2EE4BA78952E@redhat.com> Message-ID: <1151532567.3083.12.camel@localhost> On Wed, 2006-06-28 at 16:49 -0400, Elliot Lee wrote: > On Jun 28, 2006, at 04:50, Karel Zak wrote: > > > is there any public bunch of computers where upstream developers can > > test their applications on Fedora? I know about upstream developers > > who don't use Linux as primary OS or they use different distributions > > and test upstream code with things like SELinux is difficult without > > access to machine with useful FC. > > Doesn't SourceForge have shell accounts for developers? Sourceforge has the compile farm that has several different arch-OS's. I believe they have FC-3 on x86_64. Debian, SuSE, OpenSolaris on i386 boxes, and two MacOSX server that I've never been able to log into successfully. So for upstream developers its a little helpful, in terms of testing software for Fedora it's pretty much worthless. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From deisenst at gtw.net Wed Jun 28 23:23:15 2006 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 28 Jun 2006 18:23:15 -0500 Subject: [Fedora-infrastructure-list] Self-Introduction Message-ID: <44A30F63.3020905@gtw.net> Greetings, Thought I would take a moment to introduce myself. My name is David Eisenstein. I am a volunteer with the Fedora Legacy project at this time, and have recently started also helping out the fine Fedora Unity folks . I have an interest in helping out with the Fedora Infrastructure project. What I am most keenly interested in at this time is being here to help work with the upcoming Fedora Legacy integration that has been blessed by the Fedora Board , and to help in continuing maintenance of such (new?) systems/computers/ VM's/Plague instances/whatever-you-all-will-use-for-Legcay-systems. I am also interested in helping to do whatever I can to help in lowering the bar for new sub-projects to take root. And in learning stuff to become more helpful. Regarding Legacy, I like the idea of working in Fedora's CVS system, particularly if already-existing information in cvs.fedora.redhat.com about software in legacy or to-be-legacy Fedora releases can be extracted to pre-populate the area(s) that Legacy would use in cvs.fedoraproject.org for our software maintenance activities. I am not sure what planning has been formally or informally done yet other than these: * Jesse Keating's plan about this Integration: . * Elliot Lee's response on the FAB list, here Jesse, Elliot, has anything developed on Legacy Integration since these writings? Do we have any kind of sketchy timetable in mind for any of these activities? Or would we want to establish any timetables at this juncture? Warm regards, David Eisenstein From jkeating at redhat.com Thu Jun 29 00:55:36 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Jun 2006 20:55:36 -0400 Subject: [Fedora-infrastructure-list] Self-Introduction In-Reply-To: <44A30F63.3020905@gtw.net> References: <44A30F63.3020905@gtw.net> Message-ID: <200606282055.36500.jkeating@redhat.com> On Wednesday 28 June 2006 19:23, David Eisenstein wrote: > Jesse, Elliot, has anything developed on Legacy Integration since these > writings? ?Do we have any kind of sketchy timetable in mind for any of > these activities? ?Or would we want to establish any timetables at this > juncture? Lets take it one step at a time. First, lets get a CVS copy to play in, we can use it to make srpms to pass to our existing plague, or even plug our existing plague into it. Then lets look at a new plague setup on Fedora Infrastructure land. Finally lets look at how we can sign+push packages to the download.fedora.redhat.com space. So, the first item on the list, how can we get a copy of the CVS tree somewhere in Fedora CVS land? We're planning on dropping FC1 and 2 (if that gets community approval) so what we would really need is FC3 and soon 4. This would be good so that we can play around with CVS, get used to it, modify make files to send builds other places, stuff like that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jason at 3dogs.us Thu Jun 29 02:55:51 2006 From: jason at 3dogs.us (Jason Hartley) Date: Wed, 28 Jun 2006 22:55:51 -0400 (EDT) Subject: [Fedora-infrastructure-list] Comment on Turbo Gears Message-ID: <53793.192.168.0.10.1151549751.squirrel@www.3dogs.us> I just now had a chance to go over the meeting notes from last week and I noticed the discussion on TG. In FC5 it is included in the extras repo, but I had problems getting through the wiki tutorial. I seem to remember it had something to with SQLObjects having some issues. After couple of hours of messing around with it I decided to use the ez_setup.py script. After using ez_setup.py script to install TG everything work as it should. The ez_setup.py uses Python eggs, which so far have worked well for me. In any case, I think TG is great! Regards, Jason Hartley From jason at 3dogs.us Thu Jun 29 03:42:12 2006 From: jason at 3dogs.us (Jason Hartley) Date: Wed, 28 Jun 2006 23:42:12 -0400 (EDT) Subject: [Fedora-infrastructure-list] Mirror Management Specification/Requirement List Message-ID: <60048.192.168.0.10.1151552532.squirrel@www.3dogs.us> David Means and I have been working on putting together a specification/requirement list for what we need for the mirror management task. This is for two reasons. One, we might not get all of the Centos pieces in a timely matter, so we will move forward with our own code. Two, if we get all the pieces we need to make sure they are going to work as needed. In an effort to complete the list, I am asking for some guidance in understanding the process as a whole. Please look over the list below and make any necessary comments. Here is our complied list: * Cron job to check all of the mirrors for freshness. We got this piece from Seth(Centos team - makemirrorlists2-now.pl), but it is going to need some modifications. * Database dictionary - What kind of data do we need to store for each mirror. * We will need to maintain a list of mirror sites and their state (ie useable, stall, not reachable, disabled.) * Some kind of front end to redirect clients to their best mirror match(ie GeoIP.) * Admin script to manage mirror list(additions, modifications, deletions, etc.) * Once a yum session starts, we will need to direct all of the requests for that update session to the *same* mirror. That way the updates will be consistent, even if not to the most recent version. If this is true then this increases the complexity of the task, because we need to a. notice when a new session begins, and record the IP source. b. check each incoming request against the known table of ongoing sessions, and send continuing requests on to the assigned mirror. c. clean up the sessions table when the update session ends. * Handle sites that come back with a new IP, after being off the network. Has the site name been hijacked or just part of some network clean up work? David, if I missed anything, please correct me. As for the rest of you, please look over the list and reply with any amount of insight. Thanks, Jason Hartley From jason at 3dogs.us Thu Jun 29 03:55:38 2006 From: jason at 3dogs.us (Jason Hartley) Date: Wed, 28 Jun 2006 23:55:38 -0400 (EDT) Subject: [Fedora-infrastructure-list] Admin Meeting - Not looking good for tomorrow. Message-ID: <45130.192.168.0.10.1151553338.squirrel@www.3dogs.us> The HPUX 10.20 build from last week is not going well. Go figure, right! Every step forward is met with another issue. :( I am not allowed to attach to freenode from work, so If I can find another site nearby where I will working tomorrow I will attend the meeting. As always, can some one please send out the meeting, so I can keep up with what is going on? Thanks, Jason Hartley From sopwith at redhat.com Thu Jun 29 03:59:28 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 28 Jun 2006 23:59:28 -0400 Subject: [Fedora-infrastructure-list] Meeting reminder Message-ID: Hi all, Tomorrow, thursday, June 29, 20:00 GMT (4pm EDT, 1pm). irc.freenode.net #fedora-admin - be there if you have stuff you want to do, or have stuff you've done lately, or just to hang out :) By the way, if this time just doesn't work for a lot of people, we should talk every once in a while (starting now) about rescheduling it. The constraints that I used to have that prevented me from doing evenings are no longer there, so I hope I'm not a roadblack to anyone else's participation. Best, -- Elliot From sopwith at redhat.com Thu Jun 29 04:16:07 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 29 Jun 2006 00:16:07 -0400 Subject: [Fedora-infrastructure-list] Admin Meeting - Not looking good for tomorrow. In-Reply-To: <45130.192.168.0.10.1151553338.squirrel@www.3dogs.us> References: <45130.192.168.0.10.1151553338.squirrel@www.3dogs.us> Message-ID: <48EB641D-ECA6-475E-83A6-04479B021958@redhat.com> On Jun 28, 2006, at 23:55, Jason Hartley wrote: > The HPUX 10.20 build from last week is not going well. Go figure, > right! Every step forward is met with another issue. :( I am not > allowed to attach to freenode from work, so If I can find another site > nearby where I will working tomorrow I will attend the meeting. As > always, can some one please send out the meeting, so I can keep up > with > what is going on? The lengths you guys go to to show up at meetings is pretty humbling! I can just imagine Jason using his ninja moves to sneak out from the worksite for a little bit. We'll miss you as always, and yes I'll send out logs as always. Best, -- Elliot From nman64 at n-man.com Thu Jun 29 05:23:35 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 29 Jun 2006 00:23:35 -0500 Subject: [Fedora-infrastructure-list] Meeting reminder In-Reply-To: References: Message-ID: <200606290023.37211.nman64@n-man.com> On Wednesday 28 June 2006 22:59, Elliot Lee wrote: > Hi all, > > Tomorrow, thursday, June 29, 20:00 GMT (4pm EDT, 1pm). > irc.freenode.net #fedora-admin - be there if you have stuff you want > to do, or have stuff you've done lately, or just to hang out :) > > By the way, if this time just doesn't work for a lot of people, we > should talk every once in a while (starting now) about rescheduling > it. The constraints that I used to have that prevented me from doing > evenings are no longer there, so I hope I'm not a roadblack to anyone > else's participation. > It is very unlikely that I will be able to make many meetings at the current time. I've had to change jobs and can't participate in the meetings from my new workplace. I don't want to be the one person that forces a change in scheduling, but I wouldn't mind a change. If I can't make the meetings, I can always work through the list. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Thu Jun 29 13:41:40 2006 From: kwade at redhat.com (Karsten Wade) Date: Thu, 29 Jun 2006 06:41:40 -0700 Subject: [Fedora-infrastructure-list] self-intro: Karsten Wade Message-ID: <1151588500.2840.40.camel@erato.phig.org> Hola amigos: I'm joining the list and going to start lurking in meetings as a representative of the Fedora Documentation Project. As many of you know, we are happy consumers of Fedora infrastructure, and have ideas in the works that need to be joint projects with FIP. https://fedoraproject.org/wiki/KarstenWade - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sopwith at redhat.com Thu Jun 29 21:41:35 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 29 Jun 2006 17:41:35 -0400 Subject: [Fedora-infrastructure-list] Meeting log for 2006-06-29 Message-ID: <20060629214135.GA26853@ostrich-deluxe.devel.redhat.com> Hey all, Thanks for showing up, as always. lyz, looks like I just missed you before the meeting, but if you get a chance, please let us know where you are with gathering account system requirements and such. (The TODO item that was on the list with your name beside it... :) breune, -- -- Elliot -------------- next part -------------- Jun 29 16:02:14 --> You are now talking on #fedora-admin Jun 29 16:02:14 --- Topic for #fedora-admin is This is the meeting place of the Fedora Infrastructure & Sysadmin team | http://fedoraproject.org/wiki/Infrastructure | Regular meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings | https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list/ Jun 29 16:02:14 --- Topic for #fedora-admin set by nman64 at Sun Jun 25 00:30:30 2006 Jun 29 16:02:25 I don't know if there was a meeting this week, but I've got a work meeting and can't attend Jun 29 16:02:34 catch yall later Jun 29 16:02:37 yooo sopwith Jun 29 16:02:42 <-- lyz has quit (Client Quit) Jun 29 16:03:04 hey hey hey Jun 29 16:03:05 we ready to get started? Jun 29 16:03:13 I am Jun 29 16:03:26 I also Jun 29 16:03:33 I am Jun 29 16:03:40 me too Jun 29 16:03:43 aye Jun 29 16:04:00 . Jun 29 16:04:12 ah yup. Jun 29 16:04:32 Cool, soo... Jun 29 16:04:52 I added the 'subversion' item to the list earlier today... Jun 29 16:05:28 https://admin.fedoraproject.org/extras/ ;-) Jun 29 16:05:37 thats a 'partial' install. Jun 29 16:05:48 hehe, you're way ahead :) Jun 29 16:05:50 I'm actually converting cvs to svn right now on lockbox. Its going to take a long time.. I'm guesing over a day. Jun 29 16:06:01 Well Jun 29 16:06:10 hey all Jun 29 16:06:13 but I'll use extras as our main setup with different sections having different access. Jun 29 16:06:18 I wasn't planning on converting things to subversion wholesale - is that what you're doing? Jun 29 16:06:26 mmcgrath: Ooohh! Jun 29 16:06:37 sorry abadger1999 ;-) Jun 29 16:06:58 yeah, if we just want a clean head in subversion I can do that too. Jun 29 16:07:36 is there a good contact in with the ds people? I'd been working with richm a bit. Jun 29 16:08:42 I have a question Jun 29 16:08:44 mmcgrath: Hmm, I'm waiting on an e-mail for the contact Jun 29 16:08:55 pasqual: Just go ahead and ask :) Jun 29 16:08:59 well Jun 29 16:09:03 mmcgrath: Do we want to move things up a level? /svn/extras /svn/fed-ds/ etc? Jun 29 16:09:11 I answered to a petition I heared in fedora news Jun 29 16:09:23 talking about you were searching for people Jun 29 16:09:25 mmcgrath: With svn running on the app servers, how are you making sure both machines are accessing the same, consistent repository. Jun 29 16:09:42 and a person valled elliot lee conteacted me by mail Jun 29 16:09:46 Is he here? Jun 29 16:09:52 actually this is just a test and is only hitting one server. Jun 29 16:09:55 pasqual: That's me Jun 29 16:09:59 mmcgrath: Ahh OK Jun 29 16:10:02 ahh!!!! Jun 29 16:10:19 with that nick was difficult to recognice Jun 29 16:10:22 sopwith==Elliot Lee Jun 29 16:10:37 It matches up with my e-mail address :) Jun 29 16:11:00 abadger1999: as far as svn goes we'd have to talk about that. One benifit to having one large repo is its really easy to move things around. Jun 29 16:11:13 The bad thing is that it makes it more difficult to manage/backup etc. Jun 29 16:11:33 mmcgrath: The strawman setup I was thinking of was having svn running on the cvs box itself. I am all for having it spread across the app servers but then we'll need to get shared disk space set up, I guess...? Jun 29 16:11:52 ok Jun 29 16:12:18 Sopwith: we could do that I think. Jun 29 16:12:21 how is CVS setup now? Jun 29 16:12:37 mmcgrath: Hmm, what do you mean? Jun 29 16:13:01 sorry, I read your response wrong. Jun 29 16:13:07 We'd need to have a shared disk setup. Jun 29 16:13:18 unless we put different repos on different boxes. Not sure we'd gain much there. Jun 29 16:13:35 is the intent to load balance the svn requests across the app servers? Jun 29 16:14:58 mmcgrath: Probably the package repositories would need to be together (In fact, the plan is to not have extras and core be separate at all). I don't think we'd want to copy data from fedora-ds to the package repositories, though. Jun 29 16:15:29 abadger1999: its easy to setup fds in its own repo for now and then move it into extras/core as it gets ready too... Jun 29 16:15:43 mmcgrath: Pulling patches out of the fedora-ds branch and putting them into the fedora package of ds might be another story. Jun 29 16:15:59 what is fedora-ds? Jun 29 16:16:00 mmcgrath: I will send you the contact info once I get it. I think right now, we need to ensure we have svn basically set up and running in whatever configuration you want to use... Jun 29 16:16:01 tgrman: yeah Jun 29 16:16:21 Sopwith: what should I use as the authentication mechanism? Do they have Fedora accounts? Jun 29 16:16:32 hrm, there is a meeting here too today?! Jun 29 16:16:42 cripes, it's Fedora meeting day. Extras, Packaging, Infrastructure.... Jun 29 16:17:04 mmcgrath: You can assume that they do, yes. Jun 29 16:17:04 mmcgrath: The package repositories don't keep source (those go to lookaside cache) so there's not really a reason to have the fedora-ds sources mixed in with the package repository that I can think of. Jun 29 16:17:10 f13: Welcome to Thursday! :) Jun 29 16:17:34 >mmcgrath< This is actually for the certificate server group that is looking to open up their stuff (not public info yet). I made an 'svncert' group in the account system to track them. Jun 29 16:17:47 iwolf: Upgrades, how goes it? Jun 29 16:17:49 abadger1999: I'm with you now. Yeah. Jun 29 16:17:55 pasqual: fedora-ds is fedora directory server (an LDAP server) Jun 29 16:18:02 app1 is done, proxy4 is done. Jun 29 16:18:03 mmcgrath: i use ldap for my svn auth at work here Jun 29 16:18:03 thanks Jun 29 16:18:06 Both are back in rotation. Jun 29 16:18:09 --- Received a CTCP AUTOPEER +AUTOPEER:4 from mmcgrath Jun 29 16:18:35 any ideas on the db1 upgrade process? Jun 29 16:18:48 iwolf: Woohoo! Jun 29 16:18:52 /msg nickserv set unfiltered on Jun 29 16:19:07 iwolf: So that-guy-whose-name-I-forget-already sent an email with ideas on upgrading db1 Jun 29 16:19:10 tgrman, was that you? Jun 29 16:19:16 --- [tgrman] (n=jcmoore at picard.ojc.nuvio.com) : Curt Moore Jun 29 16:19:16 --- [tgrman] #asterisk #asterisk-dev #fedora-admin #centos #asterisk-bugs #rhel Jun 29 16:19:16 --- [tgrman] irc.freenode.net :http://freenode.net/ Jun 29 16:19:16 --- [tgrman] is identified to services Jun 29 16:19:16 --- [tgrman] End of WHOIS list. Jun 29 16:19:20 yep, that was me Jun 29 16:19:28 * Sopwith gains a karma point. Jun 29 16:19:35 Sopwith: I responded to that on the list too. Jun 29 16:19:44 sounded like a good plan to me. Jun 29 16:20:04 iwolf: If you don't think the overhead of setting up a temporary db server is excessive, then the thing sounds fine to me. Jun 29 16:20:37 Sopwith: overhead as in the performance hit on the server we put the temp one on? Jun 29 16:20:40 Sopwith: one of these days I'll get a free moment to look at the metrics code Jun 29 16:20:53 iwolf: Overhead as in spending a week setting up the temp server... Jun 29 16:20:54 Sopwith: or the extra steps of swapping over to a temp server? Jun 29 16:20:58 Yea, extra steps. Jun 29 16:21:27 Sopwith: I think the security blanket it provides would be worth it in case things go poorly with the db1 setup. Jun 29 16:21:50 Sopwith: I tend towards the pessimistic side of things though... :) Jun 29 16:22:44 it's always better to have it and not need it than to need it and not have it Jun 29 16:22:50 Sopwith: Now with that said, my weekend/ 4th of July are pretty busy until next Wednesday. Jun 29 16:23:11 iWolf: so I am not apt to be too productive over the next few days except for some bits and pieces here and there. Jun 29 16:23:30 iwolf: Yea, understood Jun 29 16:23:31 tgrman: I agree. Jun 29 16:23:35 next week is going to be slow :) Jun 29 16:24:21 >iwolf< Let me know if/when you're comfortable with giving tgrman login access to get to root at db1... Jun 29 16:24:22 * f13 wonders if Legacy CVS is on the meeting schedule. Jun 29 16:24:45 f13: its not but we can add it Jun 29 16:25:01 Sopwith: can you tell me something about the web styling work you commented me by mail? Jun 29 16:25:16 pasqual: Sure thing. Let's get through the rest of the todo list though. Jun 29 16:25:23 firewalls - lmacken? Jun 29 16:25:27 ah ok Jun 29 16:25:37 this has a todo list!!!! Jun 29 16:25:40 yessir! Jun 29 16:25:42 it's very amazing Jun 29 16:25:47 http://fedoraproject.org/wiki/Infrastructure/Schedule Jun 29 16:25:52 thanks Jun 29 16:26:05 rordway says no progress on metrics Jun 29 16:26:13 rordway: Any progress with monitoring? Jun 29 16:26:25 I'm having trouble monitoring the web apps because of the firewalls (thought I'd throw that out there) Jun 29 16:26:42 Sopwith: no, I think we're still waiting on el4 upgrades Jun 29 16:26:50 and the firewalls :-D Jun 29 16:26:53 :-) Jun 29 16:27:20 I'm going to see about getting NRPE pushed along in Extras, but I'm new to the extras process Jun 29 16:27:23 oh, and NRPE Jun 29 16:27:51 extras is like a fine wine. It takes a long time and you rarely end up with vinegar. Jun 29 16:29:04 * dgilmore hates systems that take 15 minutes to poweron Jun 29 16:29:34 tgrman/iwolf: How about a goal of having db1 upgraded within two weeks? Jun 29 16:30:03 Sopwith: I think we can shoot for that. Jun 29 16:30:38 sounds do-able to me but I'm still not totally knowledgable on everything, if iWolf and I work together, should be no problem Jun 29 16:31:09 everything as in how things are currently configured to access the DB Jun 29 16:32:01 tgrman: we should be able to sort that out. Jun 29 16:32:19 iWolf: sounds good to me Jun 29 16:32:47 Cool Jun 29 16:33:07 OK, documentation - anything we need to document? Jun 29 16:33:20 what don't we need to document :-D Jun 29 16:33:22 lol Jun 29 16:33:32 I've added a bit more on otrs Jun 29 16:33:49 Sopwith: I can do dist-conf Jun 29 16:33:56 but thats much less for the infrastructure and much more for end users. Jun 29 16:34:02 iwolf: Oh, that'd be nice. Jun 29 16:34:09 Sopwith: There is a pretty good readme in the CVS repo, that should handle most of it. Jun 29 16:34:22 its a little out of date, but pretty close. Jun 29 16:34:50 Yeah, I can tweak it where it needs it. And then you guys can peer review it! Jun 29 16:34:54 iwolf: While you're at it, there's also a backup/restore procedure listed in fedora-config/access Jun 29 16:34:54 :) Jun 29 16:35:07 Sopwith: Cool, I can do that one too. Jun 29 16:35:11 Cool :) Jun 29 16:35:19 Sopwith: That's the kind of stuff I can fit into the next few days! Jun 29 16:35:56 crap, I have to leave to pick up my wife in a couple minutes. Jun 29 16:35:57 mmcgrath: How are OTRS queues going? Jun 29 16:36:00 mmcgrath: do you need any help with OTRS? Jun 29 16:36:21 its going fine, I was actually thinking about putting a note out to the list to see if someone wants to be the official ticket master? Jun 29 16:36:39 until the accounting system gets re-written it'll be a little difficult to add agents to the system. Jun 29 16:36:42 just a bit manual. Jun 29 16:36:50 www.ticketmaster.com? Jun 29 16:37:06 I've been trying to convert more email addresses but it dawned on me that not everyone would want their emails in the system. Jun 29 16:37:15 so we'll have to go and see who it will help and who it would hurt. Jun 29 16:37:23 mmcgrath: Yea, finding a ticketmaster is good. Jun 29 16:37:34 right now voting at fedoraproject.org and webmaster at fedoraproject.org are in there. Jun 29 16:37:49 There's already tickets out there that are open that I'm sure are fixed. Jun 29 16:38:06 it'd be nice to have someone who's job it is to follow up on that stuff and keep OTRS clean :-D Jun 29 16:38:18 what would being ticketmaster entail? :-) Jun 29 16:38:30 adding users, queues. following up on open tickets. Jun 29 16:38:31 rordway: Telling other people what to do! Jun 29 16:38:41 sweet!, I'll do it? :-) Jun 29 16:38:49 s/?// Jun 29 16:38:52 it seems that not everyone using otrs yet but tickets are going in. Jun 29 16:39:10 but yeah, I'll volunteer if nobody else wants to do it Jun 29 16:39:11 Speaking of the voting queue : Did dropping my access level during the election remove me from seeing that queue? Jun 29 16:39:13 Something that would help me personally would be to get a weekly e-mail reminding me of my open tickets. Jun 29 16:39:27 abadger1999: Hmm, perhaps, not sure. Jun 29 16:39:28 I'm a glutton for punishment Jun 29 16:39:35 abader1999: it shouldn't have but I could see why it would have, have you tried accessing it? Jun 29 16:39:47 dgilmore? Jun 29 16:39:56 Sopwith: yeah Jun 29 16:39:57 Sopwith: I don't see any queues when I login to otrs Jun 29 16:40:03 im half here today Jun 29 16:40:04 hahah it must have then. Jun 29 16:40:06 abadger1999: Odd :) Jun 29 16:40:14 so far though the queue's clean. Jun 29 16:40:17 mmcgrath: I wrote a script for RT that did a weekly e-mail reminder, if you want I could modify it for OTRS Jun 29 16:40:26 abadger you're going to tickets/index.pl ? Jun 29 16:40:56 rordway: up to you ticket master. Jun 29 16:41:06 OTRS might have a way to do that as it is. Not sure though. Jun 29 16:41:09 dgilmore: Cool... Where does the backup stuff stand? Jun 29 16:41:32 was there ever a decision on exactly what needed to be backed up? Jun 29 16:41:59 Sopwith: hasnt moved alot. I need to put something down on the wiki. ill get that done tonight start list of pro's con's and what we want Jun 29 16:42:13 tgrman: /home was the only ? Jun 29 16:42:13 that discussion kind of branced into the whole hosting home directory issue Jun 29 16:42:23 dgilmore: OK, is that something you'd be OK with having done for next week? Jun 29 16:42:32 tgrman: Ahh yes... Jun 29 16:42:35 yeah, we should start moving on that soon. Jun 29 16:42:37 mmcgrath: Ah. My bad. I went to /tickets/ but that redirects to customer.pl Jun 29 16:42:38 Sopwith: definetly yes Jun 29 16:43:00 mmcgrath: I didn't find nman64, but I met daMaestro and we had exchanged e-mails. I'll try to help you ;) Jun 29 16:43:06 tgrman: CVS repo & lookaside, db1, and lockbox CVS - those are the known things. Jun 29 16:43:23 rork: awesome. Jun 29 16:43:27 also the logs Jun 29 16:43:30 * f13 has to run, later. Jun 29 16:43:34 f13: later Jun 29 16:43:39 f13: Later... Jun 29 16:43:43 are the logs centralized or on each server individually? Jun 29 16:43:55 right now each individual server though they should probably get sent to lockbox Jun 29 16:44:16 I'm not sure how much of a need there is for that though right now. Jun 29 16:44:21 its not a priority at least. Jun 29 16:44:26 mmcgrath: that should be an easy config change if it's needed Jun 29 16:44:28 mmcgrath: do I need to be added to any access lists to be able to see tickets? I can't seem to find any tickets :-) Jun 29 16:44:44 rordway: lemme check your access. Jun 29 16:44:48 mmcgrath: syslog-ng then filter each server to differnet locations? Jun 29 16:44:57 rordway at fp.org Jun 29 16:45:28 mmcgrath: Good thing to add to the wishlist, though. Jun 29 16:45:53 sounds good to me. Jun 29 16:46:02 rordway: you don't have access right now, adding... Jun 29 16:46:13 mmcgrath: cool, danke Jun 29 16:46:39 bitte Jun 29 16:47:17 OK, metrics is stalled for the time being (rordway is interested but busy :) Jun 29 16:47:42 mirror management seems to be moving along slowly judging from the list traffic, although Jason Hartley can't be here today. Jun 29 16:48:07 And Damian also had an interest in helping there. Jun 29 16:48:10 Damian's brother's wife's friend's dog is working on the hardware reporting tool last I heard. ;-) Jun 29 16:48:22 rordway: https://admin.fedoraproject.org/tickets/index.pl Jun 29 16:48:23 Sopwith: summer term is my busiest time of year :-( Jun 29 16:48:39 rordway: No worries, you can't do everything. Jun 29 16:48:54 sopwith on the other hand can do everything.. I've seen it. Jun 29 16:49:01 :-D Jun 29 16:49:15 hah, sometimes I try, and fail :) Jun 29 16:49:19 <-- tibbs has quit (Remote closed the connection) Jun 29 16:49:24 * tgrman wants Sopwith's super powers Jun 29 16:49:36 i18n.redhat.com - stalled again, frustrating. Main problem is just finding someone inside with the drive to do it. Jun 29 16:50:04 hmm Jun 29 16:50:05 account system - lyz had said he'd do a writeup for this week, but I haven't seen one yet. Jun 29 16:50:12 Sopwith: I've got a 5 hour car ride to Eastern Oregon this weekend, so while my wife drives I might get some time to look at the metrics code. we'll see ;-) Jun 29 16:50:33 could somebody remind me or give me a link to what metrics is about ? Jun 29 16:50:41 rordway: Cool. Don't forget to have fun though. :) Jun 29 16:51:02 abompard: https://admin.fedoraproject.org/metrics/ is the puny system that is running right now. The code is in cvs.fedoraproject.org:/cvs/devel module fedora-metrics Jun 29 16:51:12 err s,/cvs/devel,/cvs/fedora, Jun 29 16:51:31 thanks Jun 29 16:51:51 The idea is to keep track of statistics that are useful in decision making. For example, knowing how backlogged the Fedora Extras reviews are or how many bugs are open against Extras packages, or our googlebuzz history. Jun 29 16:52:25 nice Jun 29 16:52:31 Sopwith: if I pretend to be busy I don't have to drive ;-) Jun 29 16:53:05 We have so many items it always feels like rushing, but hopefully those are most of the items on the list. Jun 29 16:53:39 pasqual, welcome - now's a good time to talk about what you might want to do. Jun 29 16:53:39 btw newcommers: we get a lot of stuff done on the lists so don't hesitate to start a thread, reply to a thread, you name it. Jun 29 16:53:54 thanks Jun 29 16:53:57 well Jun 29 16:54:07 the web styling job you said Jun 29 16:54:18 to me by mail sounded interesting Jun 29 16:54:22 mmcgrath: absolutely Jun 29 16:54:29 but I would like to know a bit more Jun 29 16:54:32 about it Jun 29 16:54:37 pasqual: Sure, let me explain a bit. Jun 29 16:55:58 pasqual: Right now there are various infrastructure pieces with web interfaces (OTRS, nagios, account system, cvs, voting, etc.). It would be really nice if (a) the homepage on https://admin.fedoraproject.org/ listed them all in a nice organized way (b) each of those sites drew its web interface from a common set of templates that looked similar to the main Fedora site. Jun 29 16:56:23 aha Jun 29 16:56:36 bye Jun 29 16:56:44 in what consists those templates exactly? Jun 29 16:56:45 abompard: try otrs again ;-) Jun 29 16:56:51 rork: bye Jun 29 16:56:56 <-- rork (n=rork at 194.146.219.130) has left #fedora-admin Jun 29 16:56:59 by rork Jun 29 16:57:00 bye Jun 29 16:57:20 pasqual: Typically it is a header and a footer that get applied to all the pages generated by those CGIs. It varies from system to system, though. Jun 29 16:57:21 mmcgrath: now that's better :) Jun 29 16:58:13 pasqual: I think doing part (a) would be a good starting point to get you familiar with the subtask of part (b) Jun 29 16:58:26 ok Jun 29 16:58:29 I agree Jun 29 16:58:47 part b is the coding side you mentioned me by mail? Jun 29 16:58:53 pasqual: We also need to give the web team the ability to change the look & feel easily, so the idea is not to come up with any look and feel, just to allow applying new looks & feels as needed. Jun 29 16:59:03 in ehat language are those cgis? Jun 29 16:59:13 ok Jun 29 16:59:17 I understand Jun 29 16:59:23 pasqual: It probably has coding involved, yes, because each web app has its own way of creating the web interface, and you will need to modify the code to allow using the templates. Jun 29 16:59:54 pasqual: The CGIs are mostly in python or perl, and there are some static pages out there as well. Jun 29 17:00:27 which amount of ywork do you think is there? Jun 29 17:00:31 I'm headed out. I'll catch up via the logs. Jun 29 17:00:35 Sopwith: so whats needed is someway to apply a css style sheet to the cgi's Jun 29 17:00:42 dgilmore: Yea, more or less. Jun 29 17:00:46 tgrman: We'll chat more over email on db1 Jun 29 17:00:51 I refer about hoen many pages or files have need to be modified Jun 29 17:01:14 pasqual: I don't know. A lot of the overall project is figuring out exactly what needs to be changed. Jun 29 17:01:32 Sopwith: ok Jun 29 17:01:34 pasqual: It's a bigger project, which is why I'm suggesting starting with part (a) to just come up with the list of web apps and create the homepage using that. Jun 29 17:01:54 Sopwith: ok Jun 29 17:02:01 pasqual: And you're just getting started, so I don't want to overload you :) Jun 29 17:02:23 Sopwith: for my part I agree Jun 29 17:02:40 pasqual: Are you on the fedora-infrastructure-list e-mail list? Jun 29 17:02:50 --- [pasqual] (n=pasqual at 81-202-75-184.user.ono.com) : pasqual Jun 29 17:02:50 --- [pasqual] #fedora-admin Jun 29 17:02:50 --- [pasqual] irc.freenode.net :http://freenode.net/ Jun 29 17:02:50 --- [pasqual] is identified to services Jun 29 17:02:50 --- [pasqual] End of WHOIS list. Jun 29 17:02:53 Sopwith: there are technical details I need to work to do it? Jun 29 17:03:00 Sopwith: No Jun 29 17:03:22 Sopwith: It's ok, thanks Jun 29 17:03:35 mmcgrath: I'm new to OTRS, but I should be up to speed in a few days Jun 29 17:03:36 to know I refred , sorry Jun 29 17:03:43 pasqual: http://fedoraproject.org/wiki/Infrastructure has a link to the sign-up page for it. Jun 29 17:03:55 rordway: make sure to read the user manual :-D Jun 29 17:03:58 (By the way, if anyone else has issues to bring up, now's a good time...) Jun 29 17:04:00 :-) Jun 29 17:04:06 pasqual: That's the main e-mail list we're using for infrastructure discussions... Jun 29 17:04:13 Sopwith: rawhide killed my dog last week. Jun 29 17:04:37 mmcgrath: Maybe your dog ate rawhide, I dunno. Jun 29 17:04:59 Sopwith: im trying to get rawhide to eat my sparc Jun 29 17:04:59 sounds like a meeting end to me :-D Jun 29 17:05:04 Sopwith: thanks, I have subscribed know. I will take a look to it Jun 29 17:05:50 pasqual: For next week's, would you like to work on becoming familiar with all the infrastructure systems we have (read all the pages under http://fedoraproject.org/wiki/Infrastructure)? Jun 29 17:06:47 rordway: you might want to setup an otrs test instance for you to become familiar with its groups/roles replies/auto replies. Jun 29 17:07:21 Sopwith: ok. how do you use to communicate? the mailing list or mails? Jun 29 17:07:38 mmcgrath: I've been meaning to get a ticketing system setup for OSU Libraries, looks like I have a good excuse to do so :-) Jun 29 17:07:46 pasqual: The mailing list is the main mechanism, and of course you are welcome to send private e-mail as well. Jun 29 17:08:07 pasqual: Let us know how we can help you help Fedora :) Jun 29 17:08:32 Sopwith: ok, I will take a look to all the information and will be in contact in order to decide the next step Jun 29 17:08:47 pasqual: Cool, thanks Jun 29 17:08:57 Any other things to chat about? Jun 29 17:09:05 beside rawhide and Mike's dog. Jun 29 17:09:10 (Was it a nice dog?) Jun 29 17:09:31 Sopwith: jajajajaja, don't worry, I'm a kind of solitary cowboy Jun 29 17:09:58 Sopwith: syncmail where is our copy of the script kept Jun 29 17:10:02 not really :-D Jun 29 17:10:06 iWolf: sounds good Jun 29 17:10:18 Sopwith: as the questions appear I will contact more Jun 29 17:10:43 dgilmore: It's stored in CVS Jun 29 17:10:55 dgilmore: Check out the 'CVSROOT' module from the appropriate repository Jun 29 17:11:07 dgilmore: The loginfo file will tell you the path to the syncmail script that is used. Jun 29 17:11:11 Sopwith: did that and it wasnt there Jun 29 17:11:16 hmm, hang on Jun 29 17:11:42 dgilmore: it's in the 'CVSROOT/admin' directory for extras Jun 29 17:11:56 yeah i got permission denied on there :( Jun 29 17:12:09 OK, I need to fix that I think. That was excessive gaftonparanoia Jun 29 17:12:18 :) ok Jun 29 17:12:47 dgilmore: I assume you're in the 'sysadmin' group in the account system? Jun 29 17:13:04 Sopwith: i just want to fix the bug for those few contributors with non ascii in there name Jun 29 17:13:08 yeah i should be Jun 29 17:13:22 Sopwith: ausil is my accounts system username Jun 29 17:14:56 dgilmore: OK, you should be able to check it out within an hour. Jun 29 17:15:08 Sopwith: great Jun 29 17:18:51 I left, thanks to all Jun 29 17:18:53 Well, I guess that's it for today's meeting. Jun 29 17:18:54 <-- pasqual has quit ("Me'n vaig") Jun 29 17:18:56 Thanks everyone! Jun 29 17:19:14 By the way, good news - the SCO case mostly got thrown out today. Jun 29 17:19:31 saw that great news Jun 29 17:19:34 Sopwith: good news :) Jun 29 17:19:55 if they can throw away a bit more (like DMcB) Jun 29 17:20:05 that'd be nice Jun 29 17:20:35 abompard: that would help Jun 29 17:21:45 Sorry, was afk. If anyone's interested: http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ArchitectureDraft Jun 29 17:21:45 has some notes on my prototype of the new package vcs. Jun 29 17:22:30 mmcgrath has put some work into an alternative subversion implementation but he hasn't written anything up yet :-) Jun 29 17:22:47 abadger1999: Woohoo, very cool Jun 29 17:22:55 abadger1999: POst that to the list if you will please? Jun 29 17:23:04 Sure. Jun 29 17:24:22 its comin :-D Jun 29 17:24:30 mmcgrath: I don't know if you've looked -- livna uses subversion instead of cvs in their implementation. Jun 29 17:25:13 what I secretely want to do is mix SVN/LDAP/PKI Jun 29 17:25:41 mmcgrath: i use svn and ldap Jun 29 17:25:52 i think i said that already Jun 29 17:25:54 with mod_dav_svn? Jun 29 17:26:09 yeah, I've got our SVN here hooked up to ::COUGH:: AD. But hey it works. Jun 29 17:28:03 Do you think LDAP and the package database would tie together nicely? Jun 29 17:28:42 oh yea LDAP... :-) Jun 29 17:28:53 abadger1999: What exactly do you want to tie together? Jun 29 17:29:11 Sopwith: I've been going back and forth on LDAP vs PGSQL. Jun 29 17:29:25 Its a tough call. Jun 29 17:29:47 mmcgrath: What are the things pulling towards the LDAP side? Jun 29 17:30:06 from an infrastructure side I've found it really easy to work with/setup groups that type of thing. Jun 29 17:30:32 mmcgrath: Is that because of LDAP itself, or because of the tools that happen to be available on top of LDAP? Jun 29 17:30:43 mostly because the tools are already there. Jun 29 17:31:02 I have to admit right now LDAP just 'seems' like the right idea but it might be an overkill for what we need. Jun 29 17:31:15 Especially since we're a very develop centric organization :-D Jun 29 17:32:15 To me, LDAP is just another database, and as a database it doesn't seem attractive. I don't care about the tools on top because I don't think they can be easily customized to meet our needs (e.g. how many LDAP directories allow multiple e-mail addresses per account?) Jun 29 17:32:46 Something someone asked a while back that I still don't know for sure - does LDAP have a query language, or is it mainly key-value retrievals? Jun 29 17:32:46 Sopwith: plenty do :-D Jun 29 17:32:51 hmm cool Jun 29 17:32:53 Some of the things the Package db would have to answer for version control are: who owns a package, what groups or people could commit to a package, who is allowed to work on embargoed versions of packages. From toshio at tiki-lounge.com Thu Jun 29 21:51:21 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 29 Jun 2006 14:51:21 -0700 Subject: [Fedora-infrastructure-list] New package version control Message-ID: <1151617881.3023.17.camel@localhost> Greetings all, A few of us, warren, mmcgrath, and I are designing a new system of version control for the packages in Core and Extras. The main page of requirements and some pros and cons of various VCS's are listed on: http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ If you have some dispassionate features or reviews to add about any VCS you think could address the requirements, go ahead and add it to the page. A draft of one possible prototype is here: http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ArchitectureDraft The ArchitectureDraft attempts to address the list of requirements. An actual implementation is in the works to see how well it actually meets our needs. mmcgrath is working on a separate prototype using subversion that sounds like it is close to being ready for an initial review. Comments specific to the drafts or with ideas for doing things differently are entirely welcome :-) Let's get some discussion going! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nman64 at n-man.com Fri Jun 30 06:06:54 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Fri, 30 Jun 2006 01:06:54 -0500 Subject: Fwd: Re: [Fedora-infrastructure-list] Meeting reminder Message-ID: <200606300106.56472.nman64@n-man.com> I believe this was meant for the list. ;-) -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- An embedded message was scrubbed... From: Tom Lynema Subject: Re: [Fedora-infrastructure-list] Meeting reminder Date: Thu, 29 Jun 2006 18:39:14 -0500 Size: 4196 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Fri Jun 30 13:58:46 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 30 Jun 2006 08:58:46 -0500 Subject: [Fedora-infrastructure-list] [Fwd: Host DOWN alert for cvs-int!] Message-ID: <44A52E16.80108@fedoraproject.org> False alarm (fat fingered in Nagios) -Mike -------------- next part -------------- An embedded message was scrubbed... From: nagios at fedoraproject.org Subject: Host DOWN alert for cvs-int! Date: Fri, 30 Jun 2006 06:55:47 -0700 Size: 1971 URL: From toshio at tiki-lounge.com Fri Jun 30 17:38:31 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 30 Jun 2006 10:38:31 -0700 Subject: [Fedora-infrastructure-list] New package version control In-Reply-To: <019601c69bf9$1af28060$6401a8c0@vdavide> References: <1151617881.3023.17.camel@localhost> <019601c69bf9$1af28060$6401a8c0@vdavide> Message-ID: <1151689111.2718.35.camel@localhost> On Thu, 2006-06-29 at 22:55 -0500, David Eisenstein wrote: > Hi Toshio! > > Is there any interest in including Fedora Legacy in this process? We, > too, are moving to using CVS or some kind of package versioning system > in our maintenance work with Fedora Legacy packages. Greetings David, Warren was the initial person pulling together ideas for this and is probably still the man in the know for policy decisions. Jesse has been listening in from time to time as well, though, so he might already have had a say on how Legacy works in with this. One of the questions I had was whether this VCS would just be for Extras or would include Core as well. It is definitely for Core + Extras (One of the reasons that enhanced ACLs are important here). So I think it's sensible for Legacy to be a part of this as well. > Are you planning on having the main discussion about these VC Systems > in the Fedora-Maintainers list? I was planning on having the discussion on infrastructure list as it seemed to be a project already underway and handed over to infrastructure to write a few prototypes and get a feel for how the different version control systems mapped to our requirements. If there's more requirements to be defined then I suppose it should be discussed with a broader audience. warren would be a better person to discuss that portion, though. It's also possible to write the prototypes based on the present requirements and then ask for additional feedback as to what more is needed. -Toshio Note: I'm about to go MIA for half a week because we've bought a house and are moving between tonight and July Fifth. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sopwith at redhat.com Fri Jun 30 18:06:18 2006 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 30 Jun 2006 14:06:18 -0400 Subject: [Fedora-infrastructure-list] Extras Package Database Message-ID: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> Hi all, http://fedoraproject.org/wiki/Infrastructure/PackageDatabase has been out there for a bit... I've put together a strawman schema (as a TurboGears model.py) to help move things along - apologies if someone else has beaten me to it. I think at this point the right questions to be asking are long the lines of "will this schema support feature X or use case Y?". From a quick glance at the web page, I *think* it mostly will. There are some problems with this still, but open source is all about fixing those problems :) class Collection(SQLObject): name = StringCol(length=128, notNone=True) # "Core", "Extras", or whatever names-for-grouping you want class Package(SQLObject): name = StringCol(length=128, notNone=True) # "Core", "Extras", or whatever names-for-grouping you want created = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) status = EnumCol(enumValues=('awaitingreview', 'approved', 'denied'), default='awaitingreview', notNone=True) class PackageHistory(SQLObject): # Records changes to packages package = ForeignKey('Package', notNone=True) by_user_id = IntCol(notNone=True) # Foreign key into account database - user who made the change action = EnumCol(enumValues=('added', 'removed', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageListing(SQLObject): package = ForeignKey('Package', notNone=True) collection = ForeignKey('Collection', notNone=True) created = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) status = EnumCol(enumValues=('awaitingreview', 'awaitingbranch', 'approved', 'denied'), default='awaitingreview', notNone=True) class PackageListingHistory(SQLObject): # Records changes to packages package_listing = ForeignKey('PackageListing', notNone=True) by_user_id = IntCol(notNone=True) # Foreign key into account database - user who made the change action = EnumCol(enumValues=('added', 'removed', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageVersion(SQLObject): # A specific version on a specific branch package_listing = ForeignKey('PackageListing', notNone=True) version = StringCol(length=128, notNone=True) status = EnumCol(enumValues=('awaitingdevel', 'awaitingreview', 'awaitingqa', 'awaitingpublish', 'approved', 'denied', 'obsolete'), default='awaitingdevel', notNone=True) created = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageVersionHistory(SQLObject): # Records changes to packages package_version = ForeignKey('PackageVersion', notNone=True) by_user_id = IntCol(notNone=True) # Foreign key into account database - user who made the change action = EnumCol(enumValues=('added', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) class PackageInterest(SQLObject): # Note: PackageInterestHistory table assumes that records will never be removed from here. # Instead, set the status to 'obsolete' user_id = IntCol(notNone=True) package_listing = ForeignKey('PackageListing', notNone=True) status = EnumCol(enumValues=('awaitingreview', 'approved', 'denied', 'obsolete'), default='awaitingreview', notNone=True) role = EnumCol(enumValues=('watcher', 'owner'), default='watcher', notNone=True) # Used for authorization class PackageInterestHistory(SQLObject): package_interest = ForeignKey('PackageInterest', notNone=True) action = EnumCol(enumValues=('added', 'statuschanged'), notNone=True) status = StringCol(length=128, notNone=True) # Not EnumCol, but could be changed to be one. when = DateTimeCol(default=sqlbuilder.func.NOW(), notNone=True) Best, -- Elliot From lmacken at redhat.com Fri Jun 30 18:57:19 2006 From: lmacken at redhat.com (Luke Macken) Date: Fri, 30 Jun 2006 14:57:19 -0400 Subject: [Fedora-infrastructure-list] Making RPMS for TurboGears In-Reply-To: <1151448999.14185.27.camel@localhost> References: <1151448999.14185.27.camel@localhost> Message-ID: <20060630185719.GA26295@crow.rdu.redhat.com> On Tue, Jun 27, 2006 at 05:56:39PM -0500, Tom Lynema wrote: > Here's a few things I found out while making the rpms for TurboGears, > and a few questions that have now resulted. > > I've attached an irc log of a chat I had in #turbogears. They say that > packaging a python module as a .egg file isn't necessary. This means > that the python-Testgears spec can be, and probably should be, modified > to use the --single-version-externally-managed flag. > > TurboGears will work just fine without python-TestGears. It's just a > testing suite. Should the dependency be taken out of the TurboGears > package? Also, the people in #turbogears (specifically evelind) say > that they don't even use python-TestGears and instead have moved on to > nose (http://python.org/pypi/nose). Should I package nose or > python-TestGears or both? Ignacio packaged up TurboGears for extras[0] earlier this year, which installs it using --single-version-externally-managed. As for python-TestGears, I recently filed a bug[1] to add this as a dependency because the tg-admin tool explodes without it: Traceback (most recent call last): File "/usr/bin/tg-admin", line 5, in ? from pkg_resources import load_entry_point File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2356, in ? working_set.require(__requires__) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: TestGears>=0.2 luke [0]: http://download.fedora.redhat.com/pub/fedora/linux/extras/5/SRPMS/TurboGears-0.8a5-1.fc5.src.rpm [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195370 From toshio at tiki-lounge.com Fri Jun 30 21:32:07 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 30 Jun 2006 14:32:07 -0700 Subject: [Fedora-infrastructure-list] New package version control In-Reply-To: <1151689111.2718.35.camel@localhost> References: <1151617881.3023.17.camel@localhost> <019601c69bf9$1af28060$6401a8c0@vdavide> <1151689111.2718.35.camel@localhost> Message-ID: <1151703127.2718.62.camel@localhost> On Fri, 2006-06-30 at 10:38 -0700, Toshio Kuratomi wrote: > One of the questions I had was whether this VCS would just be for Extras > or would include Core as well. It is definitely for Core + Extras (One > of the reasons that enhanced ACLs are important here). Oops. It looks like the VCS will be evaluated to combine Core and Extras but it isn't a definite go ahead item. So I don't know how you legacy folks want to proceed. Maybe look over the ideas and make suggestions and depending on how things work out make a decision on whether to integrate into what we setup or spin it off into your own thing? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Fri Jun 30 23:38:02 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 30 Jun 2006 19:38:02 -0400 Subject: [Fedora-infrastructure-list] New package version control In-Reply-To: <1151703127.2718.62.camel@localhost> References: <1151617881.3023.17.camel@localhost> <1151689111.2718.35.camel@localhost> <1151703127.2718.62.camel@localhost> Message-ID: <200606301938.06488.jkeating@j2solutions.net> On Friday 30 June 2006 17:32, Toshio Kuratomi wrote: > Oops. ?It looks like the VCS will be evaluated to combine Core and > Extras but it isn't a definite go ahead item. ?So I don't know how you > legacy folks want to proceed. ?Maybe look over the ideas and make > suggestions and depending on how things work out make a decision on > whether to integrate into what we setup or spin it off into your own > thing? We'll want to use the same system as Core/Extras, with the idea that when Core comes to Legacy, permissions can be set so that we can use the VCS that Core was using w/out having to copy anything around or change build systems or, or, or... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: