From michael at knox.net.nz Sat Jul 1 04:27:41 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 01 Jul 2006 16:27:41 +1200 Subject: [Fedora-infrastructure-list] Extras Package Database In-Reply-To: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> References: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> Message-ID: <44A5F9BD.8030502@knox.net.nz> Elliot Lee wrote: > 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 :) > This is cool Elliot. This is a project I would like to help out on, but didn't really know where to start. Hopefully we can get a few other people to pitch in. Michael From jkeating at redhat.com Sat Jul 1 13:59:57 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 1 Jul 2006 09:59:57 -0400 Subject: [Fedora-infrastructure-list] CVS tree for Legacy Message-ID: <200607010959.58021.jkeating@redhat.com> Can we get some traction on this? We need a CVS tree of FC3 and FC4 that we can write to. I'll have to play with the make files to have make build do the right things and such, but it would be better to get this earlier than later. Thinking about it again, I think we need just FC3 for now since FC4 is still being updated. We'll also need a new group, 'cvslegacy'. This group would have write access to the CVS tree. Please make me the admin of said group. -- 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 jkeating at redhat.com Sat Jul 1 14:04:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 1 Jul 2006 10:04:58 -0400 Subject: [Fedora-infrastructure-list] CVS tree for Legacy In-Reply-To: <200607010959.58021.jkeating@redhat.com> References: <200607010959.58021.jkeating@redhat.com> Message-ID: <200607011004.59083.jkeating@redhat.com> On Saturday 01 July 2006 09:59, Jesse Keating wrote: > We'll also need a new group, 'cvslegacy'. ?This group would have write > access to the CVS tree. ?Please make me the admin of said group. I took care of this part. cvslegacy group exists, I'm the admin/owner. -- 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 sopwith at redhat.com Sun Jul 2 15:56:26 2006 From: sopwith at redhat.com (Elliot Lee) Date: Sun, 2 Jul 2006 11:56:26 -0400 Subject: [Fedora-infrastructure-list] Extras Package Database In-Reply-To: <44A5F9BD.8030502@knox.net.nz> References: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> <44A5F9BD.8030502@knox.net.nz> Message-ID: On Jul 1, 2006, at 00:27, Michael J. Knox wrote: > Elliot Lee wrote: >> 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 :) > > This is cool Elliot. This is a project I would like to help out on, > but didn't really know where to start. That in itself is helpful to know, because it's never 100% clear whether progress is dependent on having time or having knowledge :) In general, quite a few projects are at the stage where the main helping out to be done is figuring out what needs to be done. There's no set task list for the packageDB or account system, just a need for someone to figure out what's going on, and to keep pushing at it until a complete spec emerges. Are there areas where others could use more elaboration to get them started? Best, -- Elliot From mmcgrath at fedoraproject.org Mon Jul 3 19:42:00 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 03 Jul 2006 14:42:00 -0500 Subject: [Fedora-infrastructure-list] Cacti's running Message-ID: <44A97308.6050508@fedoraproject.org> I'd been meaning to add this for a while with Nagios. Cacti is up and running and monitoring some of our servers. For those that don't know Cacti will allow us to get good trending information from the servers. We can easily track things like drive space, CPU/Load, and mem usage over a period of time (even years if we need to). It's presently open to anyone in the sysadmin group. https://admin.fedoraproject.org/cacti/ Feel free to add more hosts if you're familiar with Cacti. Eventually we can also setup monitoring for our databases to see how and when they're getting hit hard. We can lock the security on cacti down tighter if need be but I figured I'd keep it fairly open for now. Don't go breaking it! -Mike From gauret at free.fr Mon Jul 3 20:39:19 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 3 Jul 2006 22:39:19 +0200 Subject: [Fedora-infrastructure-list] Cacti's running In-Reply-To: <44A97308.6050508@fedoraproject.org> References: <44A97308.6050508@fedoraproject.org> Message-ID: <200607032239.22887.gauret@free.fr> > I'd been meaning to add this for a while with Nagios. Cacti is up and > running and monitoring some of our servers. For those that don't know > Cacti will allow us to get good trending information from the servers. > We can easily track things like drive space, CPU/Load, and mem usage > over a period of time (even years if we need to). It's presently open > to anyone in the sysadmin group. Cacti is a pretty versatile tool. I'm very familiar with it, so if you need to graph custom values, I'd be glad to write some scripts. I've written some for my job, for example the mail queue, the amount of incoming and outgoing mails, the level of spams and viruses in it, statistics for apache, mysql, bind, etc... It can graph anything (as long as there is a way to get the data) Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at Dell.com Wed Jul 5 20:44:57 2006 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Wed, 5 Jul 2006 15:44:57 -0500 Subject: [Fedora-infrastructure-list] Dell server donation deadline approaching Message-ID: Greetings. As I mentioned on IRC and on email a bit back, Dell would like to donate a couple servers to the Fedora project, to be used wherever hardware (not people) are the bottleneck towards progress. We've got budgeted enough for 2 moderately configured PowerEdge 2950 servers, and have until about July 18 to get them ordered (else we lose the money). I'd be happy to work with whomever appropriate to get the order placed. Please cc: me explicitly as I'm not on f-i-l. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jkeating at redhat.com Wed Jul 5 20:58:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Jul 2006 16:58:08 -0400 Subject: [Fedora-infrastructure-list] Dell server donation deadline approaching In-Reply-To: References: Message-ID: <200607051658.08156.jkeating@redhat.com> On Wednesday 05 July 2006 16:44, Matt_Domsch at dell.com wrote: > Greetings. As I mentioned on IRC and on email a bit back, Dell would > like to donate a couple servers to the Fedora project, to be used > wherever hardware (not people) are the bottleneck towards progress. > We've got budgeted enough for 2 moderately configured PowerEdge 2950 > servers, and have until about July 18 to get them ordered (else we lose > the money). I'd be happy to work with whomever appropriate to get the > order placed. > > Please cc: me explicitly as I'm not on f-i-l. If possible, I would like to mark one of these for Legacy use. We'll need a box to run plague from, and a box to do the sign+push from. Legacy is a fun issue as I'd like to push to the existing updates/ tree for the legacy releases. Not sure how well that's going to work, but that's another topic for another day. BTW< any progress on a CVS tree of FC3 for Legacy to use? -- 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 mmcgrath at fedoraproject.org Wed Jul 5 21:52:34 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 5 Jul 2006 16:52:34 -0500 Subject: [Fedora-infrastructure-list] Dell server donation deadline approaching In-Reply-To: <200607051658.08156.jkeating@redhat.com> References: <200607051658.08156.jkeating@redhat.com> Message-ID: <3237e4410607051452t3f6e804bu8c9a0ba01e53d925@mail.gmail.com> On 7/5/06, Jesse Keating wrote: > On Wednesday 05 July 2006 16:44, Matt_Domsch at dell.com wrote: > > Greetings. As I mentioned on IRC and on email a bit back, Dell would > > like to donate a couple servers to the Fedora project, to be used > > wherever hardware (not people) are the bottleneck towards progress. > > We've got budgeted enough for 2 moderately configured PowerEdge 2950 > > servers, and have until about July 18 to get them ordered (else we lose > > the money). I'd be happy to work with whomever appropriate to get the > > order placed. > > > > Please cc: me explicitly as I'm not on f-i-l. > > If possible, I would like to mark one of these for Legacy use. We'll need a > box to run plague from, and a box to do the sign+push from. Legacy is a fun > issue as I'd like to push to the existing updates/ tree for the legacy > releases. Not sure how well that's going to work, but that's another topic > for another day. > > BTW< any progress on a CVS tree of FC3 for Legacy to use? > > -- > Jesse Keating > Release Engineer: Fedora > I'm working on the Legacy stuff now, should be done soon. -Mike From lyz27 at yahoo.com Wed Jul 5 23:34:26 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Wed, 05 Jul 2006 18:34:26 -0500 Subject: [Fedora-infrastructure-list] Account system updates Message-ID: <1152142466.14297.8.camel@localhost> I started up the wiki page for the requirements on the new account system. It is at http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 . There isn't that much there now. The last time I sent the list of enhancements request out, I really didn't get many enhancements back. There was just a discussion on what the backend technology should be. I did pull out one feature. Give more information about a user when deciding to sponsor a person. EG. bugzilla enteries This time around I would like you all to just give me a list of enhancements and not worry about the implementation details as much :) . I really want to have some good stuff to report in tomorrow's meeting. Please help me out :). ~lyz -------------- 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 toshio at tiki-lounge.com Thu Jul 6 00:10:49 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 05 Jul 2006 17:10:49 -0700 Subject: [Fedora-infrastructure-list] Account system updates In-Reply-To: <1152142466.14297.8.camel@localhost> References: <1152142466.14297.8.camel@localhost> Message-ID: <1152144649.24961.121.camel@localhost> Note, this is a laundry list. Some of the stuff on here may fall under other infrastructure projects more than this one. Some of it may be impractical. The common thread is that they link to a person contributing to Fedora. Better UI ========= - Search for a packager by regex on realname, username, email or irc nick. + Limit search by membership within group: find .*badger.* in cvsextras. - More connected. Being able to refine a search for a user from within a group listing, for instance. - Better display of users. If you are viewing cvsextras and trying to get to a user whose name you think starts with "n", you'll have a lot of links to click. One-stop Fedora Accounts Tracking ================================= - Integrate with moinmoin - Integrate with Zope+Plone - Integrate with the revision control system, package builders, etc. - Integrate with bugzilla "Portfolio View" of contributor's work ====================================== - Packages worked on - bugzillas replied to - upstream projects they work with - wiki/Plone/Docs project pages they work on - arbitrary URL + descriptions. -Toshio On Wed, 2006-07-05 at 18:34 -0500, Tom Lynema wrote: > I started up the wiki page for the requirements on the new account > system. It is at > http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 . There > isn't that much there now. > The last time I sent the list of enhancements request out, I really > didn't get many enhancements back. There was just a discussion on what > the backend technology should be. I did pull out one feature. > > Give more information about a user when deciding to sponsor a person. > EG. bugzilla enteries > > This time around I would like you all to just give me a list of > enhancements and not worry about the implementation details as > much :) . > I really want to have some good stuff to report in tomorrow's meeting. > Please help me out :). > > ~lyz > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -------------- 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 Jul 6 03:20:40 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 5 Jul 2006 23:20:40 -0400 Subject: [Fedora-infrastructure-list] Account system updates In-Reply-To: <1152142466.14297.8.camel@localhost> References: <1152142466.14297.8.camel@localhost> Message-ID: Hey Tom! Thanks for keeping us on task here :) Here are some of the things I have been thinking of for the new account system: For users: - Allow listing more than one e-mail address per account (linkedin.com is the site I remember doing this right) - Clean up the interface - Have a top-level menu that is shown on all pages, with quick links to different pieces of the account system - Allow doing the sign-up process as a wizard-style step-by-step interface, instead of a bunch of random links to - Make documentation a part of the interface - In particular, there is a lot of concern that getting a GPG key is too complicated for a lot of people such as translators, who are not technical types. We need to make that process as clear and simple and documented as possible - The user info screen might want to evolve from just an "edit my information" screen For administrators: - Clean up the interface - With hundreds of users and 10s of groups, we definitely need a nicer way to find specific users or groups than paging through them 1 by 1... - The part of the interface where you add users to or remove users from a group is clunky. In particular, it's currently possible to add a user to a group more than once, and if a user is rejected from a group, there is no way to let them come back at a later date and reapply... - Make the e-mail reminders a bit smarter and nicer to read - Allowing administrators to mark membership applications as "acknowledged" would be nice for administrators, especially for Extras - Allow setting a per-group e-mail message to be sent to people when their membership in a group reaches different stages... - Allow groups to be members of other groups (i.e. you are a member in group B because you are a member in group A, and A is a member of B). Can't do this nicely with the current SQL schema. I did it nicely with the old Red Hat build system, but it requires using text fields instead of numeric IDs to specify the names of the group members... For everyone: - Need more free-form text fields everywhere (e.g. comments that are visible only to admins, or whatever). Maybe it should just be something that holds XML that is processed by the apps... - Privacy issues need to be thought out more clearly and addressed. In particular, this relates to what information we store - Need to make iron-clad sure that the rewrite does NOT muck with the legal issues surrounding the CLA (i.e. we have to continue to guarantee that people have submitted the CLA form by a GPG signature with a key that is tied to a verified e-mail address) - Account System 2.0 should get run by Red Hat's legal department to just make them feel comfortable with the change - On a related note, we need to add proper support for the corporate CLA. If we had 'groups being members of other groups' implemented, it would be fairly easy to create a group for each corporation that signed the CCLA, have each of those groups be a member of the cla_done group, and having access to the corporate CLA groups administered by a designated contact... Behind the scenes: - Rewrite the code to be cleaner (maybe use turbogears, or maybe that is too heavyweight) - Make it easier to embed into other apps, especially the signup process (so that Extras can have a custom "sign up as an extras contributor" wizard that can easily do the basic account system steps as part of its workflow - Figure out the whole LDAP vs SQL thing - At the end, port the application interface parts (get_auth, have_auth, have_group, etc.) to perl and php so that we can use them from all our applications Hope this helps, -- Elliot On Jul 5, 2006, at 19:34, Tom Lynema wrote: > I started up the wiki page for the requirements on the new account > system. It is at > http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 . There > isn't that much there now. > The last time I sent the list of enhancements request out, I really > didn't get many enhancements back. There was just a discussion on > what > the backend technology should be. I did pull out one feature. > > Give more information about a user when deciding to sponsor a person. > EG. bugzilla enteries > > This time around I would like you all to just give me a list of > enhancements and not worry about the implementation details as > much :) . > I really want to have some good stuff to report in tomorrow's meeting. > Please help me out :). > > ~lyz > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From sopwith at redhat.com Thu Jul 6 03:30:31 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 5 Jul 2006 23:30:31 -0400 Subject: [Fedora-infrastructure-list] Account system updates In-Reply-To: References: <1152142466.14297.8.camel@localhost> Message-ID: <2DA574E9-B793-430E-A737-D2B6F48458E3@redhat.com> On Jul 5, 2006, at 23:20, Elliot Lee wrote: > - Privacy issues need to be thought out more clearly and > addressed. In particular, this relates to what information we store Argh, forgot to finish that thought... Basically, we need to think more about what information we store, but even more importantly, what information is displayed to the general public when viewing a user's info, what information is displayed to registered Fedora users when viewing that user's info, and so on. It's good to ask people in Europe about these issues, since they tend to be a lot more privacy conscious than those elsewhere. Best, -- Elliot From dennis at ausil.us Thu Jul 6 03:38:39 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 5 Jul 2006 22:38:39 -0500 Subject: [Fedora-infrastructure-list] Account system updates In-Reply-To: References: <1152142466.14297.8.camel@localhost> Message-ID: <200607052238.40531.dennis@ausil.us> On Wednesday 05 July 2006 10:20 pm, Elliot Lee wrote: > Hey Tom! Thanks for keeping us on task here :) > > Here are some of the things I have been thinking of for the new > account system: > > For users: > - Allow listing more than one e-mail address per account > (linkedin.com is the site I remember doing this right) > - Clean up the interface > - Have a top-level menu that is shown on all pages, with quick > links to different pieces of the account system > - Allow doing the sign-up process as a wizard-style step-by-step > interface, instead of a bunch of random links to > - Make documentation a part of the interface > - In particular, there is a lot of concern that getting a GPG key > is too complicated for a lot of people such as translators, who are > not technical types. We need to make that process as clear and simple > and documented as possible can we provide a script for nontechnical types? > - The user info screen might want to evolve from just an "edit my > information" screen All sounds good I read it to mean simpler and more integrated > For administrators: > - Clean up the interface > - With hundreds of users and 10s of groups, we definitely need a > nicer way to find specific users or groups than paging through them 1 > by 1... > - The part of the interface where you add users to or remove users > from a group is clunky. In particular, it's currently possible to add > a user to a group more than once, and if a user is rejected from a > group, there is no way to let them come back at a later date and > reapply... > - Make the e-mail reminders a bit smarter and nicer to read > - Allowing administrators to mark membership applications as > "acknowledged" would be nice for administrators, especially for Extras > - Allow setting a per-group e-mail message to be sent to people > when their membership in a group reaches different stages... > - Allow groups to be members of other groups (i.e. you are a member > in group B because you are a member in group A, and A is a member of > B). Can't do this nicely with the current SQL schema. I did it nicely > with the old Red Hat build system, but it requires using text fields > instead of numeric IDs to specify the names of the group members... with the right interface it shouldn't matter if GID's/UID's are numerical or text > For everyone: > - Need more free-form text fields everywhere (e.g. comments that are > visible only to admins, or whatever). Maybe it should just be > something that holds XML that is processed by the apps... > - Privacy issues need to be thought out more clearly and addressed. > In particular, this relates to what information we store > - Need to make iron-clad sure that the rewrite does NOT muck with > the legal issues surrounding the CLA (i.e. we have to continue to > guarantee that people have submitted the CLA form by a GPG signature > with a key that is tied to a verified e-mail address) > - Account System 2.0 should get run by Red Hat's legal department > to just make them feel comfortable with the change I would imagine this is a must. We cant freak them out :D > - On a related note, we need to add proper support for the corporate > CLA. If we had 'groups being members of other groups' implemented, it > would be fairly easy to create a group for each corporation that > signed the CCLA, have each of those groups be a member of the > cla_done group, and having access to the corporate CLA groups > administered by a designated contact... Sounds good. is there many corporate CLA's? > Behind the scenes: > - Rewrite the code to be cleaner (maybe use turbogears, or maybe > that is too heavyweight) > - Make it easier to embed into other apps, especially the signup > process (so that Extras can have a custom "sign up as an extras > contributor" wizard that can easily do the basic account system steps > as part of its workflow > - Figure out the whole LDAP vs SQL thing Why not use both? some thing will be just easier in ldap, some in SQL, use SQL as a backend to ldap Its a little more work but would provide greatest flexibility. > - At the end, port the application interface parts (get_auth, > have_auth, have_group, etc.) to perl and php so that we can use them > from all our applications > > Hope this helps, > -- Elliot -- Dennis Gilmore, RHCE Proud Australian From sopwith at redhat.com Thu Jul 6 03:43:03 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 5 Jul 2006 23:43:03 -0400 Subject: [Fedora-infrastructure-list] Dell server donation deadline approaching In-Reply-To: References: Message-ID: <9CDDA6DC-F9D0-4A13-BB12-2546B82C9A21@redhat.com> Assuming we have rack space in the colo (Stacy?), it sounds like we can use one machine for Fedora Legacy, and I think we really ought to start thinking about having more than one database server, so just tell me what I need to do to help you get this ordered... Best, -- Elliot On Jul 5, 2006, at 16:44, wrote: > Greetings. As I mentioned on IRC and on email a bit back, Dell would > like to donate a couple servers to the Fedora project, to be used > wherever hardware (not people) are the bottleneck towards progress. > We've got budgeted enough for 2 moderately configured PowerEdge 2950 > servers, and have until about July 18 to get them ordered (else we > lose > the money). I'd be happy to work with whomever appropriate to get the > order placed. > > Please cc: me explicitly as I'm not on f-i-l. > > Thanks, > Matt > > -- > Matt Domsch > Software Architect > Dell Linux Solutions linux.dell.com & www.dell.com/linux > Linux on Dell mailing lists @ http://lists.us.dell.com > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From mmcgrath at fedoraproject.org Thu Jul 6 03:51:05 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 5 Jul 2006 22:51:05 -0500 Subject: [Fedora-infrastructure-list] Dell server donation deadline approaching In-Reply-To: <9CDDA6DC-F9D0-4A13-BB12-2546B82C9A21@redhat.com> References: <9CDDA6DC-F9D0-4A13-BB12-2546B82C9A21@redhat.com> Message-ID: <3237e4410607052051x6127ba90q29f2f4d56e0424cd@mail.gmail.com> On 7/5/06, Elliot Lee wrote: > Assuming we have rack space in the colo (Stacy?), it sounds like we > can use one machine for Fedora Legacy, and I think we really ought to > start thinking about having more than one database server, so just > tell me what I need to do to help you get this ordered... > > Best, > -- Elliot +1 on the database server. From sopwith at redhat.com Thu Jul 6 04:03:03 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 6 Jul 2006 00:03:03 -0400 Subject: [Fedora-infrastructure-list] Account system updates In-Reply-To: <200607052238.40531.dennis@ausil.us> References: <1152142466.14297.8.camel@localhost> <200607052238.40531.dennis@ausil.us> Message-ID: <2AF6B1C6-20D3-46B1-AD8B-4562C285C08C@redhat.com> On Jul 5, 2006, at 23:38, Dennis Gilmore wrote: >> - In particular, there is a lot of concern that getting a GPG key >> is too complicated for a lot of people such as translators, who are >> not technical types. We need to make that process as clear and simple >> and documented as possible > can we provide a script for nontechnical types? One good possible solution... >> - The user info screen might want to evolve from just an "edit my >> information" screen > All sounds good I read it to mean simpler and more integrated Argh, ANOTHER thought I forgot to finish - thanks Dennis! :) I meant to say that instead of just letting the user edit their information, we should also have links to other places where they might want to change their settings - the Wiki, OTRS, package database, bugzilla, etc. - and maybe a status summary from each of those places. >> - Allow groups to be members of other groups (i.e. you are a member >> in group B because you are a member in group A, and A is a member of >> B). Can't do this nicely with the current SQL schema. I did it nicely >> with the old Red Hat build system, but it requires using text fields >> instead of numeric IDs to specify the names of the group members... > with the right interface it shouldn't matter if GID's/UID's are > numerical or > text This was where I diverged into an implementation detail rather than stating a problem. At the SQL schema level, it does matter. All this should be totally transparent to the user... >> - On a related note, we need to add proper support for the corporate >> CLA. If we had 'groups being members of other groups' implemented, it >> would be fairly easy to create a group for each corporation that >> signed the CCLA, have each of those groups be a member of the >> cla_done group, and having access to the corporate CLA groups >> administered by a designated contact... > Sounds good. is there many corporate CLA's? I believe Dell and IBM are the only ones (I know Dell, not sure about IBM). >> - Figure out the whole LDAP vs SQL thing > Why not use both? some thing will be just easier in ldap, some in > SQL, use > SQL as a backend to ldap Its a little more work but would provide > greatest > flexibility. Can you explain more of what you're thinking in this area? In my thinking you have to have one authoritative place to store the data, and while you can do things like offer other interfaces as desired, it's not really a matter of using two solutions where one will do... (BTW, how hard would it be to implement an LDAP server whose tables were the direct results of SQL queries, with no gatewaying done? Is there a python module to make it easy to implement an LDAP server?) Best, -- Elliot From dennis at ausil.us Thu Jul 6 04:19:06 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 5 Jul 2006 23:19:06 -0500 Subject: [Fedora-infrastructure-list] Account system updates In-Reply-To: <2AF6B1C6-20D3-46B1-AD8B-4562C285C08C@redhat.com> References: <1152142466.14297.8.camel@localhost> <200607052238.40531.dennis@ausil.us> <2AF6B1C6-20D3-46B1-AD8B-4562C285C08C@redhat.com> Message-ID: <200607052319.06857.dennis@ausil.us> On Wednesday 05 July 2006 11:03 pm, Elliot Lee wrote: > On Jul 5, 2006, at 23:38, Dennis Gilmore wrote: > >> - In particular, there is a lot of concern that getting a GPG key > >> is too complicated for a lot of people such as translators, who are > >> not technical types. We need to make that process as clear and simple > >> and documented as possible > > > > can we provide a script for nontechnical types? > > One good possible solution... > >> - Allow groups to be members of other groups (i.e. you are a member > >> in group B because you are a member in group A, and A is a member of > >> B). Can't do this nicely with the current SQL schema. I did it nicely > >> with the old Red Hat build system, but it requires using text fields > >> instead of numeric IDs to specify the names of the group members... > > > > with the right interface it shouldn't matter if GID's/UID's are > > numerical or > > text > > This was where I diverged into an implementation detail rather than > stating a problem. At the SQL schema level, it does matter. All this > should be totally transparent to the user... that was what i was trying to get to the user should have no clue of the implementation. I could be wrong but i think it could be done either way > >> - On a related note, we need to add proper support for the corporate > >> CLA. If we had 'groups being members of other groups' implemented, it > >> would be fairly easy to create a group for each corporation that > >> signed the CCLA, have each of those groups be a member of the > >> cla_done group, and having access to the corporate CLA groups > >> administered by a designated contact... > > > > Sounds good. is there many corporate CLA's? > > I believe Dell and IBM are the only ones (I know Dell, not sure about > IBM). So not huge but with it being easy for the corporate type to participate It could encourage others to sign up > >> - Figure out the whole LDAP vs SQL thing > > > > Why not use both? some thing will be just easier in ldap, some in > > SQL, use > > SQL as a backend to ldap Its a little more work but would provide > > greatest > > flexibility. > > Can you explain more of what you're thinking in this area? In my > thinking you have to have one authoritative place to store the data, > and while you can do things like offer other interfaces as desired, > it's not really a matter of using two solutions where one will do... What i was thinking was to keep the authoritative data in a SQL server with ldap server as a client http://www.flatmtn.com/computer/Linux-LDAP.html provides one way to implent. I personally have not done it. But i think it could be an option. > (BTW, how hard would it be to implement an LDAP server whose tables > were the direct results of SQL queries, with no gatewaying done? Is > there a python module to make it easy to implement an LDAP server?) > > Best, > -- Elliot > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Dennis Gilmore, RHCE Proud Australian From Matt_Domsch at dell.com Thu Jul 6 04:23:03 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 5 Jul 2006 23:23:03 -0500 Subject: [Fedora-infrastructure-list] Dell server donation deadline approaching In-Reply-To: <9CDDA6DC-F9D0-4A13-BB12-2546B82C9A21@redhat.com> References: <9CDDA6DC-F9D0-4A13-BB12-2546B82C9A21@redhat.com> Message-ID: <20060706042303.GA30042@humbolt.us.dell.com> On Wed, Jul 05, 2006 at 11:43:03PM -0400, Elliot Lee wrote: > Assuming we have rack space in the colo (Stacy?), it sounds like we > can use one machine for Fedora Legacy, and I think we really ought to > start thinking about having more than one database server, so just > tell me what I need to do to help you get this ordered... Short of it is, go to dell.com, large business segment, and spec out PowerEdge 2950 systems like you need (they need not be identical). Send me the "Print Summary" page of SKUs for each config, and I'll see if it fits in the budget, then we can negotiate features up/down depending on leftover money. For example, 2 x dual-core Xeon 5130 4MB CPUs, 8GB RAM, 3 146GB 10krpm SAS disks, PERC5/i controller, dual gigabit ethernet, DRAC5, rails, cables etc. is within the budget if you wanted 2 systems like that. :-) Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From dennis at ausil.us Thu Jul 6 04:58:17 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 5 Jul 2006 23:58:17 -0500 Subject: [Fedora-infrastructure-list] Backup update Message-ID: <200607052358.17514.dennis@ausil.us> Hey All, Ive setup a page on the wiki to gather all the information on backup options. http://www.fedoraproject.org/wiki/Infrastructure/Backup -- Dennis Gilmore, RHCE Proud Australian From mmcgrath at fedoraproject.org Thu Jul 6 14:07:45 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 06 Jul 2006 09:07:45 -0500 Subject: [Fedora-infrastructure-list] Legacy CVS Message-ID: <44AD1931.5080003@fedoraproject.org> The Legacy CVS is up now. Just set the following: export CVSROOT=":ext:YOURUSERNAME at cvs.fedora.redhat.com:/cvs/legacy/" export CVS_RSH="ssh" You'll have to be in the legacy group to commit. You should be able to co FC-3, packages, and rpms. Jesse feel free to tweak it however you need it if there are other changes you need me to make or find anything I missed let me know. This repo was based off of the dist repo so its using those Makefiles. -Mike From jkeating at redhat.com Thu Jul 6 14:57:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Jul 2006 10:57:17 -0400 Subject: [Fedora-infrastructure-list] Re: Legacy CVS In-Reply-To: <44AD1931.5080003@fedoraproject.org> References: <44AD1931.5080003@fedoraproject.org> Message-ID: <200607061057.17597.jkeating@redhat.com> On Thursday 06 July 2006 10:07, Mike McGrath wrote: > You'll have to be in the legacy group to commit. ?You should be able to > co FC-3, packages, and rpms. ? Jesse feel free to tweak it however you > need it if there are other changes you need me to make or find anything > I missed let me know. ?This repo was based off of the dist repo so its > using those Makefiles. Rock. Thanks a bunch Mark, I'll start poking at it maybe tonight. -- 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 mmcgrath at fedoraproject.org Thu Jul 6 19:43:16 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 06 Jul 2006 14:43:16 -0500 Subject: [Fedora-infrastructure-list] Extras SVN setup for testing Message-ID: <44AD67D4.3090508@fedoraproject.org> For those that don't know one of the Version control systems we're evaluating is Subversion: http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ArchitectureDraft I've got SVN setup and running with Fedora Extras. I've got 2 copies. One is a from the head for FE-5 and the other is an actual cvs2svn conversion of Extras. They are available to anyone with a Fedora Account at: https://svn.fedoraproject.org/svn/extras/ and https://svn.fedoraproject.org/svn/cvs2svn-extras/ Right now the head svn (https://svn.fedoraproject.org/svn/extras/) is setup in the following fashion: trunk\ tags\ branches\ Take a look. I think this layout will work well for us. For testing I've got this wide open (any valid Fedora Account) but I'm open to closing parts of it down, completely opening some stuff (no auth at all). We can get as crazy as we want as far as ACL's go. Let me know what you guys all think because if we find some reason this won't work for our needs it's better to find out now so we can focus our efforts on the others. -Mike From mmcgrath at fedoraproject.org Thu Jul 6 20:37:15 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 06 Jul 2006 15:37:15 -0500 Subject: [Fedora-infrastructure-list] Fix them mirrors Message-ID: <44AD747B.9080903@fedoraproject.org> We should implement this. We need to find a good place in CVS for it. -Mike -------------- next part -------------- An embedded message was scrubbed... From: seth vidal Subject: some more code Date: Wed, 05 Jul 2006 11:45:22 -0400 Size: 10461 URL: From skvidal at linux.duke.edu Thu Jul 6 20:45:12 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 06 Jul 2006 16:45:12 -0400 Subject: [Fedora-infrastructure-list] Fix them mirrors In-Reply-To: <44AD747B.9080903@fedoraproject.org> References: <44AD747B.9080903@fedoraproject.org> Message-ID: <1152218712.14618.24.camel@cutter> On Thu, 2006-07-06 at 15:37 -0500, Mike McGrath wrote: > We should implement this. We need to find a good place in CVS for it. > > -Mike > I have some more changes to send you, too. the todo list looks like: - config files - cgi for handing back sets based on geoip results - lock file for writing out mirrorlists - checking for result errors - implementing 'good enough' mirrorlists. -sv From lmacken at redhat.com Thu Jul 6 21:19:42 2006 From: lmacken at redhat.com (Luke Macken) Date: Thu, 6 Jul 2006 17:19:42 -0400 Subject: [Fedora-infrastructure-list] Firewall tool update Message-ID: <20060706211942.GA3892@crow.rdu.redhat.com> A couple of meetings ago someone mentioned the tool pyroman[0] in regard to managing the firewalls on our infrastructure. Since then, I've been playing around with this tool, and have been fairly impressed. I've imported pyroman 0.3 along with a _basic_ Fedora infrastructure profile into cvs. I've added all of our PHX machines listed on InfrastructurePrivate, and added some other minor tweaks. It's not 100% ready for deployment yet, it still needs: o to allow traffic to most services on our machines o profiles for our machines at Duke o to be compared against our current rc.firewall script - I've ported over most of it (the stuff I could actually understand), but there might be some stuff I missed o LOTS of testing The more testing and the more eyes we can get on this, the better. You should be able to hop on any machine and check it out of cvs: cvs -d cvs-int.fedora.phx.redhat.com:/cvs/fedora co pyroman >From here, you can run `./pyroman --dump`, which will spit out all of the chains instead of just trying to load them. Hack away, infrastructure ninjas! luke [0]: http://pyroman.alioth.debian.org From lmacken at redhat.com Fri Jul 7 00:14:05 2006 From: lmacken at redhat.com (Luke Macken) Date: Thu, 6 Jul 2006 20:14:05 -0400 Subject: [Fedora-infrastructure-list] Firewall tool update In-Reply-To: <20060706211942.GA3892@crow.rdu.redhat.com> References: <20060706211942.GA3892@crow.rdu.redhat.com> Message-ID: <20060707001405.GA5156@crow.nc.rr.com> On Thu, Jul 06, 2006 at 05:19:42PM -0400, Luke Macken wrote: > A couple of meetings ago someone mentioned the tool pyroman[0] in regard to > managing the firewalls on our infrastructure. Since then, I've been playing > around with this tool, and have been fairly impressed. > > I've imported pyroman 0.3 along with a _basic_ Fedora infrastructure profile > into cvs. I've added all of our PHX machines listed on InfrastructurePrivate, > and added some other minor tweaks. It's not 100% ready for deployment yet, > it still needs: > > o to allow traffic to most services on our machines > o profiles for our machines at Duke > o to be compared against our current rc.firewall script > - I've ported over most of it (the stuff I could actually > understand), but there might be some stuff I missed > o LOTS of testing We should probably toss ipv6 support on this list too. luke From lyz27 at yahoo.com Fri Jul 7 02:10:08 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Thu, 06 Jul 2006 21:10:08 -0500 Subject: [Fedora-infrastructure-list] AccountSystem2 updated Message-ID: <1152238208.14064.1.camel@localhost> The AccountSystem2 wiki page has been updated with the discussion that occurred today. http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 ~lyz -------------- 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 mmcgrath at fedoraproject.org Fri Jul 7 03:22:13 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 6 Jul 2006 22:22:13 -0500 Subject: [Fedora-infrastructure-list] Source file consolidation on CVS Message-ID: <3237e4410607062022k7d04f947o6240013e457ea7a1@mail.gmail.com> I'll be working to consolidate some of the source files on the CVS box over the next couple of days. Pay attention and let me know immediately if something breaks. I don't foresee any issues. Right now legacy, cvs, and dist all have individual sources in them. The sources are stored by file name and md5sum, for example: putty-0.58.tar.gz/ffb78a7db7e4802896189b2112714a9f/putty-0.58.tar.gz A collision between the different trees is unlikely. The purpose for this consolidation is to ease the efforts of the legacy team and provide them a proper development and build environment. In the end a source tarball is a source tarball, it makes sense to store them in one spot. Currently the dist repo is 73G and the extras repo is 12G. It seems a shame to make a copy of all of that when the exact same files would be a directory away. Send objections, comments, suggestions and consecutive unmarked-bills my way. -Mike From mmcgrath at fedoraproject.org Fri Jul 7 15:05:27 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 07 Jul 2006 10:05:27 -0500 Subject: [Fedora-infrastructure-list] AccountSystem2 updated In-Reply-To: <1152238208.14064.1.camel@localhost> References: <1152238208.14064.1.camel@localhost> Message-ID: <44AE7837.7010803@fedoraproject.org> Tom Lynema wrote: > The AccountSystem2 wiki page has been updated with the discussion that occurred today. > http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 > > > ~lyz I have a few wants to add to the list. 1) I'd like, as much as possible, updates to replicate immediately. This may end up being more the way our end apps communicate with the accounting system. I know an hour isn't long to wait in most cases but it would be nice, and probably have a better design, to have most of our apps contact the database or LDAP backend or whatever to get their information instead of having scripts run all the time. For many of our web apps this is already being done to a degree. There's a small tweak we need to make to the db or I need to take a closer look at mod_auth_pgsql. 2) a documented API in major supported languages. 3) History/Rollback functions. With so many trusted people working on different parts of the system I think this is necessary. Maybe not for version 1 but somewhere. 4) encrypted passwords 5) More focus on 'key' based access when appropriate. Comments on LDAP: I think that whether we use LDAP or don't use LDAP we'll end up using some sort of database back end for many things. This seems fairly typical to me. OTRS and Cacti, for example, have full support for LDAP while maintaining their own database backends using the LDAP username or email address as the unique identifier to link LDAP to the db. Our accounting system could do something similar though groups, keys, user info and passwords can all be stored in LDAP. -Mike From sopwith at redhat.com Fri Jul 7 16:34:41 2006 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 7 Jul 2006 12:34:41 -0400 Subject: [Fedora-infrastructure-list] Source file consolidation on CVS In-Reply-To: <3237e4410607062022k7d04f947o6240013e457ea7a1@mail.gmail.com> References: <3237e4410607062022k7d04f947o6240013e457ea7a1@mail.gmail.com> Message-ID: <41E6CFF4-3E7F-444D-B1DA-E57EE17236AD@redhat.com> The biggest problem will be that the 'dist' lookaside repo is mirrored from the internal cvs server, whereas the extras lookaside is the master copy... Best, -- Elliot On Jul 6, 2006, at 23:22, Mike McGrath wrote: > I'll be working to consolidate some of the source files on the CVS box > over the next couple of days. Pay attention and let me know > immediately if something breaks. I don't foresee any issues. Right > now legacy, cvs, and dist all have individual sources in them. The > sources are stored by file name and md5sum, for example: > > putty-0.58.tar.gz/ffb78a7db7e4802896189b2112714a9f/putty-0.58.tar.gz > > A collision between the different trees is unlikely. The purpose for > this consolidation is to ease the efforts of the legacy team and > provide them a proper development and build environment. In the end a > source tarball is a source tarball, it makes sense to store them in > one spot. Currently the dist repo is 73G and the extras repo is 12G. > It seems a shame to make a copy of all of that when the exact same > files would be a directory away. > > Send objections, comments, suggestions and consecutive unmarked- > bills my way. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From sopwith at redhat.com Fri Jul 7 20:26:17 2006 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 7 Jul 2006 16:26:17 -0400 Subject: [Fedora-infrastructure-list] Meeting log - 2006-07-06 Message-ID: <20060707202617.GA12603@ostrich-deluxe.devel.redhat.com> Hey all, Here's the log from yesterday's meeting in case you missed it... Thanks to everyone who came! Best, -- Elliot -------------- next part -------------- Jul 06 16:02:52 as always: http://fedoraproject.org/wiki/Infrastructure/Schedule is on the todo (damn it got big!) Jul 06 16:03:05 Who's here today? Jul 06 16:03:05 I am Jul 06 16:03:15 * lmacken raises his hand Jul 06 16:03:16 yup Jul 06 16:03:22 here Jul 06 16:03:25 present Jul 06 16:03:46 jcmoore==tgrman Jul 06 16:03:48 is PasqualMilvaques here? (sorry, I don't know his nic) Jul 06 16:04:36 * warren here Jul 06 16:04:38 guess not, So we'll skip item 1 for now "Step 1: Create homepage for admin.fedoraproject.org" Jul 06 16:04:52 Number 2, how are the systems upgrades going? Jul 06 16:05:21 looks like we're missing a few people today Jul 06 16:05:23 --- [jcmoore] (n=jcmoore at unaffiliated/tgrman) : Curt Moore Jul 06 16:05:23 --- [jcmoore] +#freenode-social #rhel #asterisk-bugs #centos #fedora-admin #asterisk-dev #asterisk Jul 06 16:05:23 --- [jcmoore] irc.freenode.net :http://freenode.net/ Jul 06 16:05:23 --- [jcmoore] is identified to services Jul 06 16:05:23 --- [jcmoore] End of WHOIS list. Jul 06 16:05:26 iwolf is probably around Jul 06 16:05:35 and jcmoore was wanting to help with the db upgrade (Curt, are you here?) Jul 06 16:05:49 Yes, jcmoore==tgrman Jul 06 16:05:52 iwolf: ping Jul 06 16:05:55 --- tgrman :No such nick/channel Jul 06 16:06:22 iWolf and I have been corresponding, still planning on doing it "soon" Jul 06 16:06:50 Thats good. Have anything to report besides soon? We can always go back to it. Jul 06 16:07:06 jcmoore: Any bottlenecks besides finding the time for the actual switchover? Jul 06 16:07:34 no, i think the plan is the same as the one I posted to the list. Just need to find the time. Jul 06 16:08:20 lmacken: how's the firewall stuff going? Jul 06 16:08:29 So yeah. I just imported the pyroman code + a basic profile for our infrastruct Jul 06 16:08:32 ure systems in to cvs (cvs-int:/cvs/fedora/pyroman). This is not 100% done yet though, it still needs to be configured to allow traffic to any services, but th Jul 06 16:08:35 e more eyes we have on this -- the better. Jul 06 16:08:43 damn irssi Jul 06 16:08:59 you should be able to check it out on any machine, and run ./pyroman --dump to spit out all of the chains Jul 06 16:09:12 so feel free to test, and hack on it. Jul 06 16:09:13 awesome. Jul 06 16:09:20 i'll drop a line to infrastructure-list tonight with all of the details Jul 06 16:09:27 great, I'll definately have a look at it Jul 06 16:09:31 excellent :) Jul 06 16:09:33 it'll be good to get that up and going. Jul 06 16:09:53 Next item then, turbo gears. Jul 06 16:10:10 Who all is working on that and whats the status? Jul 06 16:10:15 ok Jul 06 16:10:28 I bumped TurboGears in FC-5 and rawhide today up to 0.8.9 Jul 06 16:10:47 there is still an open bug to bump the rawhide version to the latest alpha, which is blocked on a python-ruledispatch review request Jul 06 16:11:07 so, the latest stable version (0.8.9) went through our buildsystem a couple of hours ago, and should be available Jul 06 16:11:43 i'll work on pushing python-ruledispatch through this weekend Jul 06 16:11:49 so we can have 0.9a5 in devel Jul 06 16:12:01 * iWolf wanders back in.... Jul 06 16:12:09 thats good. Just so everyone knows could you go back over what we're going to be using TurboGears for? Jul 06 16:12:14 whats up iWolf! Jul 06 16:12:29 mmcgrath: not much! Sorry I was pulled away. Jul 06 16:12:38 mmcgrath: i was told it is going to be used for the account system rewrite, and the extras database Jul 06 16:13:11 and probably any other web apps we need to quickly crank out in the future Jul 06 16:13:15 got'cha Jul 06 16:13:28 but ignacio has been MIA, so we needed to whip the package into shape Jul 06 16:13:49 k. Jul 06 16:13:57 iWolf: how's the documentation/backup stuff going? Jul 06 16:14:11 dgilmore is in on that too Jul 06 16:14:30 mmcgrath: I have the dist-conf up there, current backups (with a link to the pros and cons dgilmore has up). Jul 06 16:14:50 I still need to throw some more info about fedora-config on there. Jul 06 16:15:13 Yeah Jul 06 16:15:35 dgilmore: how's the backup stuff coming? I've seen the wiki. Jul 06 16:16:50 we'll come back to that. Jul 06 16:17:07 Its probably time I move nagios and OTRS to the 'installed' queue Jul 06 16:17:19 we had a ticket master last week but I don't think he's here. Jul 06 16:17:24 I'll post to the list about that. Jul 06 16:17:47 next item Legacy CVS. I installed that late last night. Still waiting to hear back from f13 if its to his needs. Jul 06 16:17:54 and the free servers. Jul 06 16:18:04 at one point in time we had no use for them. What are the thoughts now sopwith? Jul 06 16:18:48 mmcgrath: I like the idea of another db server, especially since jcmoore has come experience in that realm. Jul 06 16:18:56 asdf Jul 06 16:18:58 argh Jul 06 16:19:05 mmcgrath: It would help eliminate one of our few SPOF. Jul 06 16:19:22 So I still don't understand the need for a Legacy server separate from the existing build system Jul 06 16:19:34 Me either, that was f13's call. Jul 06 16:19:37 f13: ping ? Jul 06 16:19:56 lmacken: pong Jul 06 16:20:16 f13: just trying to get your attention ;) Jul 06 16:20:31 we're talking about the free servers. Jul 06 16:20:36 so there was concern when I first brought up LEgacy that it should run its own plague instance but could use existing builders perhaps Jul 06 16:21:02 * rordway is here Jul 06 16:21:06 part of that concern was permissions, where to get CVS from, where to send the packages, whats in teh buildroots, etc... Jul 06 16:21:08 * rordway just got back from vacation Jul 06 16:21:15 rordway: our ticket master. We'll go back to that in a sec. Jul 06 16:22:39 are we will contemplating getting this new server ? or is it a done deal ? Jul 06 16:23:11 rordway! Jul 06 16:23:26 sorry I'm late, I've been catching up and fixing servers that broke while I was gone :-( Jul 06 16:23:35 lmacken: they're a done deal if we want them. But A) do we need them B) do we have space for them? Jul 06 16:23:46 no sense in maintaining servers we don't need. Jul 06 16:24:55 true Jul 06 16:25:10 Sopwith: greetings Jul 06 16:25:34 The way I understand it we have to decide asap or they're just gone. Jul 06 16:25:41 I got a few minutes to poke at the metrics code. I may be able to do some of the back-end data gathering stuff, but I'm not much of an interfaces person :-) Jul 06 16:26:16 rordway: OK. Data gathering is where you can get the most improvement with the least effort at the moment - the current UI is basically there, even if it is awful. Jul 06 16:26:20 mmcgrath: with as much difference as Legacy has initially, it seems we probably do need our own server to start with. Jul 06 16:26:29 mmcgrath: at a later time, the server could be repurposed Jul 06 16:26:37 mmcgrath: I should call Stacy right now to find out if we have rack space. Jul 06 16:26:48 its awful overkill for what we need, but at least we get the server. Jul 06 16:26:56 we definitely can put it to use Jul 06 16:27:10 especially when the update system becomes external Jul 06 16:27:16 Someone want to be in charge of spending Dell's money? Jul 06 16:27:36 Sopwith: cool, is there a TODO list of data sources? Jul 06 16:27:39 well, do we want it in rdu or westford ? Jul 06 16:27:43 or elsewhere Jul 06 16:28:03 Sopwith: buhhhh Jul 06 16:28:09 lmacken: the PHX colo, most likely...? Jul 06 16:28:13 oh, these servers could go wherever. The last ones went to Duke. Jul 06 16:28:15 Or Seth could host it I suppose Jul 06 16:28:38 Someone should just order them and we can figure out the hosting later. Jul 06 16:28:49 If nothing else they can sit in wwoods cube running the Fedora test grid... Jul 06 16:28:49 agreed Jul 06 16:28:49 Sopwith: I could see about hosting at OSU OSL Jul 06 16:29:07 PHX probably best, near where the builders are Jul 06 16:29:19 So, who wants to take care of the details of spending Dell's money? :) Jul 06 16:29:21 out of curiosity, who is in PHX that managages those machines ? Jul 06 16:29:30 because Legacy could use it as a plague host as well as a staging box for pushing updates. Jul 06 16:29:55 Sopwith: send me the details. I'll take it. Jul 06 16:29:58 lmacken: Stacy Brandenberg manages the colo as a whole. Jul 06 16:30:21 mmcgrath: The info was in Matt Domsch's post on fedora-infrastructure-list - beyond that, it's mostly an issue of deciding on the details. Jul 06 16:30:37 --- [nate] (n=nate at 128.101.10.77) : gaim Jul 06 16:30:37 --- [nate] #nagios #unisog-ot Jul 06 16:30:37 --- [nate] irc.freenode.net :http://freenode.net/ Jul 06 16:30:37 --- [nate] End of WHOIS list. Jul 06 16:32:13 e.g. I'm not sure what DRAC or rackmount hardware we need, and I didn't like the idea of having only 3 big disks... Jul 06 16:32:19 oh, got'cha. Jul 06 16:32:20 Sopwith: I have an email from Stacy (sent to the Sysadmin list) saying Fedora has 20U left. Jul 06 16:32:24 I'll take a look then Jul 06 16:32:31 iwolf: Oh cool Jul 06 16:32:49 In that case we're probably good then... Jul 06 16:32:54 Sopwith: He sent it on 5/27 if you end up checking the archives. Jul 06 16:33:08 iwolf: OK, we're fine then. Jul 06 16:33:48 anyone know how the xfer script is going? Jul 06 16:34:02 * Sopwith looks Jul 06 16:34:08 j8sun isn't around so I'm not sure.. Jul 06 16:34:18 Come to think of it, I haven't been getting those e-mails, so at least the rerouting part worked Jul 06 16:34:40 woohoo, yup it's working Jul 06 16:34:45 bastion:/var/xferlogarchive Jul 06 16:34:48 well there you go Jul 06 16:35:38 That reminds me, skvidal gave me a script that basically can be run once an hour to test our mirrors. Jul 06 16:35:47 Its better than nothing and would work until we find a permant solution. Jul 06 16:36:43 Forwarding to the list now... Jul 06 16:36:51 cool Jul 06 16:37:29 It needs a place in CVS for the time being so seth can make changes to it. Its rough but should work. Jul 06 16:37:54 rordway: how's the metrics stuff going? Jul 06 16:39:41 mmcgrath: took a look at the code over the weekend, I told Sopwith I think I could do some of the back-end data gathering, but I'm not much of an interface person Jul 06 16:39:58 got'cha, I'm not either. Jul 06 16:40:11 we'll wait till you've had a bit more time to look over it. Jul 06 16:40:16 k Jul 06 16:40:33 anyone have anything on mirror management? j8sun's gone. Jul 06 16:40:47 Damian was looking at it a bit as well Jul 06 16:40:57 he's gone too :-D Jul 06 16:41:03 hmm.. what is this blob of code that just popped up on infra-list ? Jul 06 16:41:08 He e-mailed me today asking about some details of the hardware tracker, sounds like he should be back next week or so Jul 06 16:41:31 looks like seth started writing some code Jul 06 16:41:43 its kind of a mirror monitoring script Jul 06 16:42:09 or a yum plugin or something :-D Jul 06 16:42:15 I haven't had a whole lot of time to look at it myself Jul 06 16:42:41 it looks like it generates a 'good' mirrorlist Jul 06 16:43:00 yeah, we'll stick it in cron. Jul 06 16:43:05 we could toss it into cvs/svn and start building our 'mirror management system' around it Jul 06 16:43:05 --> skvidal (n=skvidal at fedora/skvidal) has joined #fedora-admin Jul 06 16:43:06 he's on his way in. Jul 06 16:43:07 hi Jul 06 16:43:08 welcome skvidal Jul 06 16:43:33 I was just implementing using python and some code from yum something similar to what the centos scripts were doing Jul 06 16:43:39 what I haven't done is this: Jul 06 16:43:52 1. no db use - I'm just writing out flat files and then returning them based on geoip Jul 06 16:44:04 2. no special marking of how often a mirror is out of sync Jul 06 16:44:11 so there are all sorts of optimizations that can go on Jul 06 16:44:18 awesome Jul 06 16:44:32 <-- tibbs has quit (Remote closed the connection) Jul 06 16:44:33 I was just playing around while away and thought I'd mess with this problem to see how hard it would be with yum modules Jul 06 16:44:56 it's really quite simple code, actually. Jul 06 16:45:05 I'll send a new version some time tonight when I'm finished playing around Jul 06 16:45:34 I'd like to get a config file working properly and have a proof of functionality for the geoip stuff - I know it works - just need it to be testable :) Jul 06 16:46:02 anyway - that's all that's going on Jul 06 16:46:04 I'll stick it in onw of the repos soon. Jul 06 16:46:06 I'm not wed to this code or the idea Jul 06 16:46:21 but its here and better then what we currently have :-D Jul 06 16:46:23 I just wanted to do something different from what I was doing at the moment Jul 06 16:46:41 so if anyone wants to say 'boy that's stupid' I won't be offended :) Jul 06 16:46:45 and this script fully supports ipv6 right? Jul 06 16:46:47 ;-) Jul 06 16:47:40 hahahahahah Jul 06 16:47:43 heheh Jul 06 16:47:53 I dunno if the geoip stuff does or not, to be honest Jul 06 16:48:10 well we'll let it slip for now. Jul 06 16:48:20 --> smooge (n=smooge at pdpc/supporter/bronze/smooge) has joined #fedora-admin Jul 06 16:48:21 Thanks skvidal. Jul 06 16:48:36 the next item on the list is the hardware reporting tool. Jul 06 16:48:39 any idea whats going on with that. Jul 06 16:49:03 Damian's not here so we'll skip that for now Jul 06 16:49:51 Since its getting late, does anyone have anything to add to rhlinux.redhat.com migration or Translator's compendium? If not we'll move to the accounting system Jul 06 16:50:29 nope, nothing with rhlinux Jul 06 16:51:06 lyz|work: any progress on the requirements gathering? Jul 06 16:51:25 you guys got the email today? Jul 06 16:51:34 I will update the wiki page when I get home Jul 06 16:52:07 I must have missed it. K. Jul 06 16:52:28 it was yesterday sorry Jul 06 16:52:37 Anyone have anything to add? abompard you've been pretty quiet. Jul 06 16:52:55 lyz: There were a bunch of replies Jul 06 16:53:01 no, nothing to say at the moment Jul 06 16:53:09 Sopwith, yeah it went well Jul 06 16:53:14 I see it now. Jul 06 16:53:26 that one got put into a special folder :-D big discussion Jul 06 16:54:37 I see the account system as being our biggest project at the moment. Should we put together an assigned team for it? Jul 06 16:55:02 Hmm, don't see the need to get too formal. As long as someone persists in pushing the project, it should be good Jul 06 16:55:08 mmcgrath: just read the message about Cacti, cool! should take a look at NPC, a Nagios Plugin for Cacti which lets you integrate the two Jul 06 16:55:48 I'll help with the account system, I'm learning Turbogears Jul 06 16:56:05 i'd like to help Jul 06 16:56:27 unfortunately I've been drowning in work this week, I hope I'll move faster next week Jul 06 16:56:37 --- [daMaestro] (n=jon at fedora/damaestro) : Jon Jul 06 16:56:37 --- [daMaestro] #fedora-admin #Fedora #centos #Fedora-Websites #fedora-unity #fedora-selinux #fedora-search #fedora-devel #apache Jul 06 16:56:37 --- [daMaestro] irc.freenode.net :http://freenode.net/ Jul 06 16:56:37 --- [daMaestro] is identified to services Jul 06 16:56:37 --- [damaestro] End of WHOIS list. Jul 06 16:56:40 rordway: I've seen some of those before. Send me the link mmcgrath at fedoraproject.org I'll take a look. Jul 06 16:57:03 mmcgrath: will do Jul 06 16:57:06 damaestro: Is this your first time here? Welcome... Jul 06 16:57:16 Sopwith, yes.. and thanks Jul 06 16:58:06 gotta run guys Jul 06 16:58:16 be around later Jul 06 16:58:16 later lyz, thanks again Jul 06 16:58:26 welcome :) Jul 06 16:58:30 <-- lyz|wrk has quit ("Leaving") Jul 06 16:59:44 oh, and for those that havne't seen it, I have SVN up and running. Jul 06 16:59:51 <-- rdieter has quit ("Konversation terminated!") Jul 06 16:59:53 fedora extras 5 is currently in there. Jul 06 17:00:07 play with it, send acl requests my way. Jul 06 17:00:23 other than that we're at the 1 hour mark. Does anyone have anything else they'd like to add? Jul 06 17:00:33 what is going on with the accounts system? Jul 06 17:00:49 be back in a sec, phone call Jul 06 17:00:50 what is going on with zope and plone for the new site? PAS? Jul 06 17:00:54 DaMaestro: are you on the fedora-infrastructure-list ? Jul 06 17:00:59 i am not. Jul 06 17:01:17 zope and plone I don't know about. Aren't we waiting for abompard on those? (I might have made that up) Jul 06 17:01:27 nman64 is the main web dude Jul 06 17:01:30 mmcgrath: you made that up :) Jul 06 17:01:32 https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list Jul 06 17:01:33 abompard, did you get my mail? Jul 06 17:01:41 I am headed out guys... As usual I will catch up via the logs for the after meeting chat! Later! Jul 06 17:01:46 later iWolf. Jul 06 17:01:55 mmcgrath, thanks.. i will get signed up now Jul 06 17:02:09 daMaestro: yes, I need to update zope and plone, I'll do it asap Jul 06 17:02:09 daMastro: we currently have an accounts thread going on that list "Account system updates" Jul 06 17:02:29 daMaestro: https://www.redhat.com/mailman/private/fedora-infrastructure-list/2006-July/msg00009.html Jul 06 17:02:33 (The thread) Jul 06 17:03:28 Are we (sysadmins) concerned by to move to Zope/Plone, or is it purely the websites group concern ? Jul 06 17:03:32 abompard, you are welcome to change the plone install location to the software_home.. it makes more sense to me now Jul 06 17:03:49 I think its a functional thing. I'm not really sure what all they want exactly. Jul 06 17:03:51 daMaestro: yes, that's what I'll do Jul 06 17:04:00 daMaestro: have you been working with nman64 on this? Jul 06 17:04:34 i should be.. but not directly Jul 06 17:04:45 i pretty much take care of the fedora unity plone sites and servers Jul 06 17:05:03 Make sure to get him involved with all of this. He's the web guy around here. Jul 06 17:05:04 so i have some time under my belt with managing ldap and plone Jul 06 17:05:08 ok Jul 06 17:05:23 yeah.. he listens to my blab in the -unity channel Jul 06 17:05:39 I once bolded my name in my wiki page and he killed my family with a spoon! Jul 06 17:06:11 ouch Jul 06 17:06:13 mmcgrath: rotf Jul 06 17:06:37 mmcgrath, but plone PAS is pretty sweet.. would work well Jul 06 17:06:51 still needs a little touch up with the patches to LDAPMultiPlugins Jul 06 17:06:55 but I am working on it Jul 06 17:08:38 solid Jul 06 17:08:54 Anyone else have anything to bring up? Jul 06 17:09:08 one thing Jul 06 17:09:23 does anyone other than me think mmcgrath is doing some great stuff here? Jul 06 17:09:37 it seems like everytime I turn around he's taken care of another big chunk of stuff Jul 06 17:09:43 so, just for the record - mmcgrath you rock Jul 06 17:10:01 hahahah awww, thanks. Jul 06 17:10:31 thank you! Jul 06 17:10:38 * abompard agrees Jul 06 17:10:52 I do what I can. Jul 06 17:10:55 three cheers :) Jul 06 17:10:56 --- You are no longer marked as being away Jul 06 17:11:03 * skvidal nows goes back to my regular sarcasm and cynicism Jul 06 17:11:16 hahah. Jul 06 17:11:38 I'm still waiting for my pay checks and backpay.. Sopwith said they're on the way :-D Jul 06 17:11:58 haha Jul 06 17:12:24 ok guys, later on the list Jul 06 17:13:03 alrighty, anything else? We'll close the meeting in 30. Jul 06 17:13:11 skvidal: talked to Corey Shields at OSU OSL, he says if we need any space to give him a ping Jul 06 17:13:15 mmcgrath: some of us make really great references - isn't that a good payback? :) Jul 06 17:13:21 rordway: okie doke Jul 06 17:13:28 skvidal: its awesome payback :-D Jul 06 17:14:42 skvidal: cshields at osuosl.org he says you might still think he's at IU Jul 06 17:14:42 <-- abompard has quit (Read error: 104 (Connection reset by peer)) Jul 06 17:14:48 rordway: :) Jul 06 17:15:20 alrighty guys, meeting ends. From skvidal at linux.duke.edu Fri Jul 7 21:21:59 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 07 Jul 2006 17:21:59 -0400 Subject: [Fedora-infrastructure-list] Fix them mirrors In-Reply-To: <44AD747B.9080903@fedoraproject.org> References: <44AD747B.9080903@fedoraproject.org> Message-ID: <1152307319.16624.30.camel@cutter> On Thu, 2006-07-06 at 15:37 -0500, Mike McGrath wrote: > We should implement this. We need to find a good place in CVS for it. > More fun: foolist is just the mirrorlist for core as I pulled from the url in a yum .repo file in fc5 the config file is for the python script and it is passed as the argument to the script. run it and it will output per-country and a global up to date mirrorlist into whatever outputpath is defined as in the conf file. I'll try to tidy this up further and get the cgi worked out for the remote requests soon. -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: check-mirrors.py Type: text/x-python Size: 11295 bytes Desc: not available URL: -------------- next part -------------- #[extras-5] #inputfile = /tmp/global-mirrors-extras-5 #outputpath = /tmp/mirrors-extras-5 #timeout = 10 #canonical = http://redhat.download.fedoraproject.org/pub/fedora/linux/extras/5/$ARCH/os/ [core-5] inputfile = /tmp/foolist outputpath = /tmp/foopath/ archlist = i386, x86_64, ppc timeout = 10 canonical = http://redhat.download.fedoraproject.org/pub/fedora/linux/core/5/$ARCH/os/ -------------- next part -------------- http://redhat.download.fedoraproject.org/pub/fedora/linux/core/5/$ARCH/os/ http://ftp.fi.muni.cz/pub/linux/fedora-core/5/$ARCH/os/ ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/5/$ARCH/os/ ftp://ftp.wsisiz.edu.pl/pub/linux/fedora/linux/core/5/$ARCH/os/ http://ftp.ale.org/mirrors/fedora/linux/core/5/$ARCH/os/ http://ftp.uninett.no/pub/linux/Fedora/core/5/$ARCH/os/ http://ftp.tu-chemnitz.de/pub/linux/fedora-core/5/$ARCH/os/ http://sunsite.informatik.rwth-aachen.de/ftp/pub/linux/fedora-core/5/$ARCH/os/ ftp://ftp.tecnoera.com/pub/fedora/linux/core/5/$ARCH/os/ ftp://redhat.taygeta.com/pub/RedHat/fedora/core/5/$ARCH/os/ http://fr2.rpmfind.net/linux/fedora/core/5/$ARCH/os/ http://ftp.riken.jp/Linux/fedora/core/5/$ARCH/os/ http://zeniv.linux.org.uk/pub/distributions/fedora/linux/core/5/$ARCH/os/ http://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/5/$ARCH/os/ ftp://ftp.wicks.co.nz/pub/linux/dist/fedora/5/$ARCH/os/ ftp://ftp.rhd.ru/pub/fedora/linux/core/5/$ARCH/os/ http://ftp.rhd.ru/pub/fedora/linux/core/5/$ARCH/os/ ftp://ftp.ipex.cz/pub/linux/fedora/core/5/$ARCH/os/ http://fedora.cat.pdx.edu/linux/core/5/$ARCH/os/ http://fedora.ngi.it/5/$ARCH/os/ ftp://falkor.skane.se/pub/mirrors/fedora/core/5/$ARCH/os/ ftp://ftp.cica.es/fedora/linux/core/5/$ARCH/os/ ftp://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/core/5/$ARCH/os/ http://ftp.ussg.iu.edu/linux/fedora/linux/core/5/$ARCH/os/ http://ftp.surfnet.nl/ftp/pub/os/Linux/distr/fedora/5/$ARCH/os/ http://ftp.nluug.nl/ftp/pub/os/Linux/distr/fedora/5/$ARCH/os/ ftp://ftp.net.usf.edu/pub/fedora/linux/core/5/$ARCH/os/ http://www.muug.mb.ca/pub/fedora/linux/core/5/$ARCH/os/ http://mirror.eas.muohio.edu/fedora/linux/core/5/$ARCH/os/ http://sunsite.mff.cuni.cz/pub/fedora/5/$ARCH/os/ http://mirror.linux.duke.edu/pub/fedora/linux/core/5/$ARCH/os/ http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/5/$ARCH/os/ http://mirror.hiwaay.net/redhat/fedora/linux/core/5/$ARCH/os/ ftp://mirrors.hpcf.upr.edu/pub/Mirrors/redhat/download.fedora.redhat.com/5/$ARCH/os/ http://redhat.secsup.org/fedora/core/5/$ARCH/os/ ftp://ftp.dc.aleron.net/pub/linux/fedora/linux/core/5/$ARCH/os/ ftp://mirror.newnanutilities.org/pub/fedora/linux/core/5/$ARCH/os/ ftp://ftp.software.umn.edu/pub/linux/fedora/core/5/$ARCH/os/ http://www.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/5/$ARCH/os/ ftp://fedora.mirrors.tds.net/pub/fedora-core/5/$ARCH/os/ http://mirror.cs.wisc.edu/pub/mirrors/linux/download.fedora.redhat.com/pub/fedora/linux/core/5/$ARCH/os/ http://ftp.ndlug.nd.edu/pub/fedora/linux/core/5/$ARCH/os/ http://fedora.server4you.net/fedora/core/5/$ARCH/os/ ftp://mirrors.ptd.net/fedora/core/5/$ARCH/os/ ftp://fedora.bu.edu/fedora/core/5/$ARCH/os/ http://mirror.pacific.net.au/linux/fedora/linux/core/5/$ARCH/os/ From lyz27 at yahoo.com Fri Jul 7 23:52:27 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Fri, 07 Jul 2006 18:52:27 -0500 Subject: [Fedora-infrastructure-list] AccountSystem2 updated In-Reply-To: <44AE7837.7010803@fedoraproject.org> References: <1152238208.14064.1.camel@localhost> <44AE7837.7010803@fedoraproject.org> Message-ID: <1152316347.21844.0.camel@localhost> On Fri, 2006-07-07 at 10:05 -0500, Mike McGrath wrote: > Tom Lynema wrote: > > The AccountSystem2 wiki page has been updated with the discussion that occurred today. > > http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 > > > > > > ~lyz > > I have a few wants to add to the list. Done ~tom -------------- 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 skvidal at linux.duke.edu Sat Jul 8 06:17:21 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 08 Jul 2006 02:17:21 -0400 Subject: [Fedora-infrastructure-list] Fix them mirrors In-Reply-To: <1152307319.16624.30.camel@cutter> References: <44AD747B.9080903@fedoraproject.org> <1152307319.16624.30.camel@cutter> Message-ID: <1152339441.19337.7.camel@cutter> On Fri, 2006-07-07 at 17:21 -0400, seth vidal wrote: > On Thu, 2006-07-06 at 15:37 -0500, Mike McGrath wrote: > > We should implement this. We need to find a good place in CVS for it. > > > > More fun: > > foolist is just the mirrorlist for core as I pulled from the url in a > yum .repo file in fc5 > > the config file is for the python script and it is passed as the > argument to the script. > > run it and it will output per-country and a global up to date mirrorlist > into whatever outputpath is defined as in the conf file. > > I'll try to tidy this up further and get the cgi worked out for the > remote requests soon. Updated it a bit more - nothing major - and I've uploaded it to here: http://linux.duke.edu/~skvidal/mirror-check/ I've also updated the TODO's near the top of the script. If anyone wants to work on those or has any ideas about them, let me know. This isn't the end-all-be-all in mirror-checking but it does tell us if AT LEAST the repomd.xml is synchronized to the mirror master on every given mirror. I know this isn't a big deal but it's a reasonably good metric as to how far off the mark a mirror is. thanks, -sv From mmcgrath at fedoraproject.org Mon Jul 10 16:57:07 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 10 Jul 2006 11:57:07 -0500 Subject: [Fedora-infrastructure-list] Basic Ticketing Work Flow Message-ID: <44B286E3.9030802@fedoraproject.org> I've created a basic ticketing workflow system for OTRS. http://fedoraproject.org/wiki/Infrastructure/Tickets/WorkFlow It's a quick tutorial on how to lock, email, comment and resolve a ticket. The trick is to make sure we all use the system but not have it be a huge bottle neck with so much overhead that its a headache. As always any comments are welcome. We've had the system for a while now but still with few tickets. What do you guys think of it? -Mike From sopwith at redhat.com Mon Jul 10 18:17:41 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 10 Jul 2006 14:17:41 -0400 Subject: [Fedora-infrastructure-list] Basic Ticketing Work Flow In-Reply-To: <44B286E3.9030802@fedoraproject.org> References: <44B286E3.9030802@fedoraproject.org> Message-ID: On Jul 10, 2006, at 12:57, Mike McGrath wrote: > I've created a basic ticketing workflow system for OTRS. http:// > fedoraproject.org/wiki/Infrastructure/Tickets/WorkFlow > > It's a quick tutorial on how to lock, email, comment and resolve a > ticket. The trick is to make sure we all use the system but not > have it be a huge bottle neck with so much overhead that its a > headache. As always any comments are welcome. We've had the > system for a while now but still with few tickets. What do you > guys think of it? Looks cool to me! I think the main thing remaining to do is just nagging people to use it, until they do. That could mean sending a personal note (with this URL included) to each of the teams that is supposed to respond to a queue. The other half of getting people to use OTRS is sending reminders via e-mail of tickets people should be paying attention to. Is there a way to do that? Best, -- Elliot From ryan.ordway at oregonstate.edu Mon Jul 10 18:23:47 2006 From: ryan.ordway at oregonstate.edu (Ryan Ordway) Date: Mon, 10 Jul 2006 11:23:47 -0700 Subject: [Fedora-infrastructure-list] Basic Ticketing Work Flow In-Reply-To: References: <44B286E3.9030802@fedoraproject.org> Message-ID: <1152555827.27188.46.camel@vodka.library.oregonstate.edu> On Mon, 2006-07-10 at 14:17 -0400, Elliot Lee wrote: > On Jul 10, 2006, at 12:57, Mike McGrath wrote: > > > I've created a basic ticketing workflow system for OTRS. http:// > > fedoraproject.org/wiki/Infrastructure/Tickets/WorkFlow > > > > It's a quick tutorial on how to lock, email, comment and resolve a > > ticket. The trick is to make sure we all use the system but not > > have it be a huge bottle neck with so much overhead that its a > > headache. As always any comments are welcome. We've had the > > system for a while now but still with few tickets. What do you > > guys think of it? > > Looks cool to me! I think the main thing remaining to do is just > nagging people to use it, until they do. That could mean sending a > personal note (with this URL included) to each of the teams that is > supposed to respond to a queue. > > The other half of getting people to use OTRS is sending reminders via > e-mail of tickets people should be paying attention to. Is there a > way to do that? I had a script for RT that went through the ticket database and sent a message to each user with open tickets giving them a list of their tickets and a link to the ticket within RT. I might be able to modify it for OTRS. Ryan -- Ryan Ordway E-mail: ryan.ordway at oregonstate.edu Unix Systems Administrator rordway at library.oregonstate.edu Oregon State University Libraries 121 The Valley Library Office: The Valley Library #4657 Corvallis, OR 97331 -------------- 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 mmcgrath at fedoraproject.org Mon Jul 10 18:24:14 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 10 Jul 2006 13:24:14 -0500 Subject: [Fedora-infrastructure-list] Basic Ticketing Work Flow In-Reply-To: References: <44B286E3.9030802@fedoraproject.org> Message-ID: <44B29B4E.2050607@fedoraproject.org> Elliot Lee wrote: > > > The other half of getting people to use OTRS is sending reminders via > e-mail of tickets people should be paying attention to. Is there a way > to do that? > Actually there is, I've been thinking about creating escalation so that if no one takes a ticket in the first 24 or 48 hours it'll send an email to the admin at fedoraproject.org. I'll set that up soon. We really need all the admins to log in and actually watch the queue's they'll be working on. -Mike From mmcgrath at fedoraproject.org Mon Jul 10 18:26:37 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 10 Jul 2006 13:26:37 -0500 Subject: [Fedora-infrastructure-list] Basic Ticketing Work Flow In-Reply-To: <1152555827.27188.46.camel@vodka.library.oregonstate.edu> References: <44B286E3.9030802@fedoraproject.org> <1152555827.27188.46.camel@vodka.library.oregonstate.edu> Message-ID: <44B29BDD.4060900@fedoraproject.org> Ryan Ordway wrote: > On Mon, 2006-07-10 at 14:17 -0400, Elliot Lee wrote: > >> On Jul 10, 2006, at 12:57, Mike McGrath wrote: >> >> > I had a script for RT that went through the ticket database and sent a > message to each user with open tickets giving them a list of their > tickets and a link to the ticket within RT. I might be able to modify it > for OTRS. > > Ryan I don't think you'll have to go that far. OTRS has some reminder functionality built in, we'll just have to look at it. -Mike From dennis at ausil.us Mon Jul 10 18:33:08 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 10 Jul 2006 13:33:08 -0500 Subject: [Fedora-infrastructure-list] Backups Message-ID: <200607101333.09005.dennis@ausil.us> Hi Everyone, Sorry i missed the meeting Thursday a Xerox guy turned up late then i couldn't get him to leave :( Can everyone look over http://fedoraproject.org/wiki/Infrastructure/Backup and provide some feedback here so that we can get some traction moving forward. Some issues not covered in the wiki are how each would be implemented. i know rdiff-backup and i assume backuppc would need to be ran by a user who has sufficient privileges on each machine to read whats needed to be backed up. what does this mean? Well in the case of rdiff-backup it could be run centrally as a cron job but the user that gets connected to at the other end needs to be able to read everything or it could be decentralised and run as a cron job for root on each box being backed up. it could then send the data to the backup server as a user with no privileges. bacula avoids this by running a daemon on each host. If there is still people wanting to use bacula I will finish and submit the bacula package I started on for extras so we can get a review of it rolling. If there is demand for backuppc then I can start packaging it or someone else can if they want. But please provide some feedback or I will make a decision myself. Regards Dennis From linux at elfshadow.net Mon Jul 10 20:29:19 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Mon, 10 Jul 2006 16:29:19 -0400 Subject: [Fedora-infrastructure-list] Basic Ticketing Work Flow In-Reply-To: <44B286E3.9030802@fedoraproject.org> References: <44B286E3.9030802@fedoraproject.org> Message-ID: <44B2B89F.9040206@elfshadow.net> Mike McGrath wrote: > It's a quick tutorial on how to lock, email, comment and resolve a > ticket. The trick is to make sure we all use the system but not have it > be a huge bottle neck with so much overhead that its a headache. As > always any comments are welcome. We've had the system for a while now > but still with few tickets. What do you guys think of it? I think it's a good system, it will just take time for people to get used to using it. It provides some ability to see who is working on what, as more tickets get input that will become more and more important. Ticket history can also be a resource to see how some issues have been solved even if you weren't the one that worked the ticket. -Jeffrey From nils at breun.nl Tue Jul 11 07:43:55 2006 From: nils at breun.nl (Nils Breunese) Date: Tue, 11 Jul 2006 09:43:55 +0200 Subject: [Fedora-infrastructure-list] Backups In-Reply-To: <200607101333.09005.dennis@ausil.us> References: <200607101333.09005.dennis@ausil.us> Message-ID: Dennis Gilmore wrote: > Can everyone look over http://fedoraproject.org/wiki/Infrastructure/ > Backup and > provide some feedback here so that we can get some traction moving > forward. > > Some issues not covered in the wiki are how each would be > implemented. i know > rdiff-backup and i assume backuppc would need to be ran by a user > who has > sufficient privileges on each machine to read whats needed to be > backed up. > what does this mean? The list looks pretty nice. I've implemented a BackupPC setup at my own company that is still in testing, but is already backing up ~10 servers (Fedora and CentOS machines) using rsync over ssh. In my setup BackupPC runs as a special shell-less user whose passphrase- less public key is added to /root/.ssh/authorized_keys on each host that is backed up. So far I'm loving BackupPC. However, I haven't seen any other solutions in action, so I can't say to much about them. However, judging from the list and the homepages of these solutions BackupPC does seem like a very easy to implement solution. If it can deliver all requirements I'd say give BackupPC a whirl. Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From nils at breun.nl Tue Jul 11 07:46:01 2006 From: nils at breun.nl (Nils Breunese) Date: Tue, 11 Jul 2006 09:46:01 +0200 Subject: [Fedora-infrastructure-list] Basic Ticketing Work Flow In-Reply-To: References: <44B286E3.9030802@fedoraproject.org> Message-ID: <497787F6-0797-47A3-A8C9-19070F8843BA@breun.nl> Elliot Lee wrote: > The other half of getting people to use OTRS is sending reminders > via e-mail of tickets people should be paying attention to. Is > there a way to do that? Agents can set up notifications for various items under Preferences. By default these are not enabled. Maybe we should enable them/some by default? Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From skvidal at linux.duke.edu Tue Jul 11 21:14:14 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 11 Jul 2006 17:14:14 -0400 Subject: [Fedora-infrastructure-list] mirror checking script Message-ID: <1152652454.19906.1.camel@cutter> Hey folks, I think I got through all the needed features for this script: http://cvs.fedora.redhat.com/viewcvs/check-mirrors/?root=fedora But if anyone can think of other things it should have either feel free to work on it or let me know. Thanks, -sv From lyz27 at yahoo.com Thu Jul 13 13:41:01 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Thu, 13 Jul 2006 06:41:01 -0700 (PDT) Subject: [Fedora-infrastructure-list] TurboGears on DeveloperWorks Message-ID: <20060713134101.77532.qmail@web80611.mail.yahoo.com> IBM ran an article about getting started with TurboGears. May be worth a read. http://www-128.ibm.com/developerworks/linux/library/l-turbogears/?ca=dgr-lnxw07TurboGearsAndPython From gauret at free.fr Thu Jul 13 15:50:09 2006 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 13 Jul 2006 17:50:09 +0200 Subject: [Fedora-infrastructure-list] Extras SVN setup for testing In-Reply-To: <44AD67D4.3090508@fedoraproject.org> References: <44AD67D4.3090508@fedoraproject.org> Message-ID: <200607131750.09829.gauret@free.fr> > Right now the head svn (https://svn.fedoraproject.org/svn/extras/) is > setup in the following fashion: > trunk\ > tags\ > branches\ I've tried this repo, thanks for setting it up. Right now the extras CVS repo is set up in this fashion : module/ submodule/ branch/ "module" being for example "rpms", "owners", "website", etc.., "submodule" being the rpm name, and "branch" being "FC-5", "devel", etc... It works fine for me as an extras contributor, why not keeping the same organization ? What would the new one provide that the old one did not ? (of course we'll need an additional rpms-tags/ top-level dir) We should also have a look at the system set-up by /the repo that must not be named/, who uses svn. It's set up in this fashion : website/ packages/ / / There also, it's quite similar to what Extras has currently. Works fine. For more info : http://rpm.livna.org/development.html (OMG I linked to it ! Curse me !) If a new classical setup like trunk/ tags/ branches/ would work better, I'm totally open to it, but are there benefits ? Anything I overlooked ? It's nice we'll be able to have fun with ACLs in the next version. Will they be pluggable into the new package database ? That would rock. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr If one keeps trying, one successes eventually. Therefore, the more one fails, the closer one is to success. -- Shadok moto. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at Dell.com Thu Jul 13 16:40:15 2006 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Thu, 13 Jul 2006 11:40:15 -0500 Subject: [Fedora-infrastructure-list] Additional Dell server donations Message-ID: In addition to the 2 PowerEdge 2950s being donated (working with Mike McGrath), Dell would like to donate 2 PowerEdge 1950 servers around September. Same deal, where would the hardware best be put to use? These would likely have only 4GB and 2 146GB disks, and are 1U rack-mount servers. Please cc: me on reponses as I'm not on f-i-l. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sopwith at redhat.com Thu Jul 13 17:54:34 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 13 Jul 2006 13:54:34 -0400 Subject: [Fedora-infrastructure-list] Regrets Message-ID: <4764B7FC-55AA-42EB-9B90-93F48BB090CA@redhat.com> Hi all, I'm involved with Red Hat High all this week, so I'm "stuck" with taking a tour of the local TV station this afternoon :) and won't be able to make it to the meeting. Please let me know if there are any tasks you all want to assign to me for the next meeting. After seeing today's spam to admin at fedoraproject.org, I'm wondering if Yet Another Project for the TODO list is setting up spam filtering of some sort... Best, -- Elliot From dennis at ausil.us Thu Jul 13 18:29:20 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 13 Jul 2006 13:29:20 -0500 Subject: [Fedora-infrastructure-list] Regrets In-Reply-To: <4764B7FC-55AA-42EB-9B90-93F48BB090CA@redhat.com> References: <4764B7FC-55AA-42EB-9B90-93F48BB090CA@redhat.com> Message-ID: <200607131329.20514.dennis@ausil.us> On Thursday 13 July 2006 12:54, Elliot Lee wrote: > Hi all, > > I'm involved with Red Hat High all this week, so I'm "stuck" with > taking a tour of the local TV station this afternoon :) and won't be > able to make it to the meeting. Please let me know if there are any > tasks you all want to assign to me for the next meeting. > > After seeing today's spam to admin at fedoraproject.org, I'm wondering > if Yet Another Project for the TODO list is setting up spam filtering > of some sort... > > Best, > -- Elliot Elliot, have fun, I missed the spam i guess or perhaps im not on that list :), but perhaps SA on the mail servers would be nice. I added an item to the agenda for minimal buildroot changes for the buildsys. and haven't had much feedback on the backups, So i think after the meeting today. We will need to make a decision. right now im tossing up in my head between bacula and backuppc. I think backuppc has the best interface for backups and restores of all the options. Dennis From sopwith at redhat.com Thu Jul 13 21:51:08 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 13 Jul 2006 17:51:08 -0400 Subject: [Fedora-infrastructure-list] Meeting log 2006-07-13 Message-ID: <20060713215108.GA30769@ostrich-deluxe.devel.redhat.com> Thanks to everyone who showed up! -- Elliot -------------- next part -------------- Jul 13 15:55:56 --> You are now talking on #fedora-admin Jul 13 15:55:56 --- 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/ Jul 13 15:55:56 --- Topic for #fedora-admin set by nman64 at Sun Jun 25 00:30:30 2006 Jul 13 15:56:22 Sopwith: thought you'd be gone? Jul 13 15:56:40 I thought so too Jul 13 15:56:52 But apparently TV stations don't like it when you show up half an hour late for a tour... Jul 13 15:57:12 doh Jul 13 15:57:12 ahh well Jul 13 15:58:56 hehe Jul 13 16:03:46 erk, I hate java Jul 13 16:04:21 is there a meeting tonight? Jul 13 16:04:25 yea Jul 13 16:04:32 xdamox: How was your time away? Jul 13 16:05:18 Good :) I watched a world cup football game live :) also when to alot of places Jul 13 16:05:34 150 euros the ticket cost me Jul 13 16:05:45 wow Jul 13 16:06:19 OK, who's here? Jul 13 16:06:38 * mmcgrath yo Jul 13 16:06:46 me Jul 13 16:06:50 * iWolf here, sort of Jul 13 16:07:17 * skvidal is here Jul 13 16:07:24 cool. Jul 13 16:07:26 * abadger1999 is here Jul 13 16:07:40 Oh, and I'm here, unexpectedly! :) Jul 13 16:07:51 hehe Jul 13 16:08:04 OK, let's get started Jul 13 16:08:05 * jcmoore raises hand Jul 13 16:08:06 * rordway is here Jul 13 16:08:27 okay Jul 13 16:08:30 extras64 is bouncing Jul 13 16:08:32 it's not in use Jul 13 16:09:04 dgilmore e-mailed me earlier today with comments about backup stuff... and he also owns the first item on the list (minimal buildroots). Jul 13 16:09:09 Dennis? Jul 13 16:11:28 I'm here, but not really here. Jul 13 16:11:37 extras64 is back up Jul 13 16:13:33 Hmm Jul 13 16:13:42 no dennis, how about pasqual? Jul 13 16:14:14 pasqual: A couple of weeks ago you said you were interested in the whole web interface type of stuff. What has happened in that area? Jul 13 16:14:55 Sopwith: I have been takina look to all the sites Jul 13 16:15:12 Sopwith: listed in thehomega Jul 13 16:15:34 Sopwith: I will try to make a draft this weekend Jul 13 16:15:48 pasqual: OK, cool. Jul 13 16:16:04 Sopwith: and ask in the mailing list for aditional url's Jul 13 16:16:32 Sopwith:but it would be nice if somebody could indicate me a refrence page Jul 13 16:16:41 Sopwith: for the aspect Jul 13 16:17:20 Sopwith: I will write something in the mailing list Jul 13 16:17:25 --> ja8sun (n=ja8sun at 64.241.37.140) has joined #fedora-admin Jul 13 16:17:38 pasqual: OK, once we see your e-mail it'll be easier to figure out the next steps... Jul 13 16:17:38 whad up ja8sun. Jul 13 16:17:43 hey Jul 13 16:17:52 ok Jul 13 16:18:13 sorry I'm late Jul 13 16:18:15 iwolf: System upgrades - it is just db1 and bastion at this point, correct? Jul 13 16:18:38 Sopwith: correct. Jul 13 16:19:03 Sopwith: db1 we are going to wrap into a cluster/replication type deal with the new server. Jul 13 16:19:07 OK Jul 13 16:19:17 Sopwith: worked with mmcgrath for specs on the box. Jul 13 16:19:24 coool Jul 13 16:19:26 Sopwith: and jcmoore Jul 13 16:20:43 OK nifty Jul 13 16:21:13 Is there a plan for getting bastion updated? Jul 13 16:21:38 Sopwith: Not really, I am not sure how best to do that one due to its unique position. Jul 13 16:21:55 oh true, it needs someone inside to do that. Jul 13 16:22:03 OK, my problem I guess. Jul 13 16:23:05 * dgilmore is here now Jul 13 16:23:18 Oh, is someone logging into RHN regularly to push updates to all the machines? Jul 13 16:23:50 lmacken: On your end, where do the TurboGears packages stand? Jul 13 16:23:52 Sopwith: I have not been... :( Jul 13 16:24:16 Sopwith: But I can start! :) Jul 13 16:24:21 iwolf: OK, I suppose we should start reviewing the "Ongoing tasks" each week as well. Jul 13 16:24:30 hehe OK cool. Jul 13 16:24:37 we should add some type of script that runs up2date -l once a day/week Jul 13 16:24:49 mmcgrath, I get emails on upgrades Jul 13 16:24:52 mmcgrath: rhnsd does that type of thing, no? Jul 13 16:25:02 Sopwith, yea Jul 13 16:25:04 I have no idea, where do the emails go? Jul 13 16:25:10 I run the upgrades from there Jul 13 16:25:12 * mmcgrath is used to working with yum. Jul 13 16:25:15 :-D Jul 13 16:25:19 :) Jul 13 16:25:36 I updated all the security there today Jul 13 16:25:42 No clue, although I know xdamox and I are both owners of the Fedora Organization in RHN, and can get that permission to anyone else who needs it. Jul 13 16:26:06 Sopwith: Was my account setup as owner? Jul 13 16:26:22 iwolf: administrator I think, dunno Jul 13 16:26:22 Sopwith: shouldn't that stuff go to admin at fedoraproject.org? Jul 13 16:26:30 mmcgrath: Yup Jul 13 16:26:40 Sopwith: not all the boxes are on RH are they? only the ones at RH Jul 13 16:26:48 dgilmore: Correct. Jul 13 16:26:52 We can hook the rest in, no problem. Jul 13 16:27:14 does CentOS have something like RHN? Jul 13 16:27:22 it's called yum Jul 13 16:27:29 iwolf: OK, you are now an "organization administrator" blah blah blah. Jul 13 16:27:34 Sopwith: perhaps that should be done add them all into rhn and task a couple of people to make syre they stay updated , we dont want a debian incident Jul 13 16:27:36 Sopwith: :) Jul 13 16:27:42 yeah, I'm referring to the web interface :-) Jul 13 16:27:59 rordway: nope Jul 13 16:28:16 rordway: it would require a central server + authentication of users Jul 13 16:28:27 If lmacken wakes up, we can bug him about the firewall and TG stuff. I think he is really expecting the rest of us to take his pyroman work and deploy it. Jul 13 16:28:53 I'm using the RHN XMLRPC interface to hook into some of my internal management interfaces, but I'm considering switching to CentOS Jul 13 16:29:21 Sopwith, the firewall on lockbox needs port 514/udp open for all logs to be directed there Jul 13 16:29:39 ahh Jul 13 16:29:56 Once that is open its simple to direct all logs Jul 13 16:30:46 ok Jul 13 16:30:53 * Sopwith fiddles with rc.firewall to get that going. Jul 13 16:31:18 skvidal: http://vodka.library.oregonstate.edu/syspoll/ notably, snapshot2_cut.png Jul 13 16:31:40 Ok Sopwith when thats done Ill set up the logs to go there Jul 13 16:31:43 Documentation - anything we know we need today? Jul 13 16:31:45 the code in there is old, old though Jul 13 16:31:47 xdamox: OK Jul 13 16:32:13 rordway: nice - doing that all yourself? Jul 13 16:32:44 * lmacken strolls in late Jul 13 16:33:21 rordway: so when do we see packages? Jul 13 16:33:23 skvidal: yeah, it's been in progress for awhile now. the back-end has come alot father than the front-end Jul 13 16:33:27 :-) Jul 13 16:33:53 that'd require me to write some sort of documentation.... Jul 13 16:34:04 as for the TurboGears stuff is concerned: I packaged up the rest of the deps for 0.9a6 (simplejson, Paste{,Script,Deploy}, ConfObj, and updated cherrypy today to 2.2.1. Jul 13 16:34:07 it's sort of spaghetti-like at the moment Jul 13 16:34:10 xdamox: Firewall mod on lockbox *should* be done. Jul 13 16:34:25 ok Jul 13 16:35:00 Ill get that done soon defentaly done for tommorow Jul 13 16:35:11 lmacken: any of those needing reviews to get into extras? Jul 13 16:35:24 lmacken: Way cool. Sounds like it's a "week or two more" type of thing until all the main packaging work is done... Jul 13 16:35:33 sqlobject and formencode will still need to be bumped, and we need to find a way to pull Turbo{Json,Cheetah,Kid} out of the TurboGears tarball Jul 13 16:35:38 dgilmore: most of them are Jul 13 16:36:14 dammit got to go, Ill catch up with you all later, also I need to email you all about the hardware tracker some input will be required Jul 13 16:36:26 Sopwith: yeah, most of that stack needed lots of work Jul 13 16:36:28 xdamox: OK, see ya Jul 13 16:36:35 lmacken: are TurboJson/Cheetah/Kid distributed as separate tarballs as well? Jul 13 16:36:42 lmacken: when there ready let me know and ill look Jul 13 16:37:28 who has access to make the changes needed so that we are using the minimal buildroots in plague Jul 13 16:37:40 abadger1999: they are in the TurboGears tarball as plugins i belive Jul 13 16:37:53 dgilmore: I was under the impression that that was working? Did I miss a thread? Jul 13 16:37:59 dgilmore: dcbw and skvidal should have it... Jul 13 16:38:03 what do we have? Jul 13 16:38:15 ah Jul 13 16:38:16 right Jul 13 16:38:20 mmcgrath: in the fesco meeting nbo one knew if minimal buildroots were in place or not Jul 13 16:38:26 dgilmore: we need to check the mock versions on the builders Jul 13 16:38:35 and the rest cascades out from there, ultimately Jul 13 16:38:36 got'cha. Thats right, we updated mock recently Jul 13 16:38:41 skvidal: can you do that i dont have access Jul 13 16:38:48 maybe Jul 13 16:39:18 is there a reason why you don't have access? Jul 13 16:39:26 umm Jul 13 16:39:27 so Jul 13 16:39:29 wtf Jul 13 16:39:35 why is nagios reporting fedoraproject.org is down? Jul 13 16:39:39 skvidal: I dont have access to anything inside fedora that i know of Jul 13 16:39:50 dgilmore: so why don't we change that? Jul 13 16:40:11 skvidal: that can work also Jul 13 16:40:17 dgilmore: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189338#c2 Jul 13 16:40:42 * Sopwith moves the xferlog item off the list. Jul 13 16:41:14 I need to change the timeout. 10 seconds is sometimes not long enough Jul 13 16:41:22 mmcgrath: for the mirror stuff? Jul 13 16:42:07 dgilmore: So for the buildroots thing, can you work with Seth to sort that out for next week? Jul 13 16:42:16 Sopwith: sure Jul 13 16:42:20 sopwith: How is xferlog script working? Jul 13 16:42:24 dgilmore: we'll get it straight - can you remind me about it tomorrow? Jul 13 16:42:28 ja8sun: Working great! Jul 13 16:42:33 ja8sun: Thanks again for doing that. Jul 13 16:42:40 sopwith: good to hear :) Jul 13 16:43:08 Oh BTW, nman64 deserves props for fixing up various account system bugs. Just need to push the changes from CVS onto all the machines. Jul 13 16:43:23 Sopwith: Sopwith: With pyroman, i wasn't expecting everyone to deploy it, I'm just tryin Jul 13 16:43:25 skvidal: sorry no for nagios Jul 13 16:43:38 * lmacken kicks irssi Jul 13 16:43:40 skvidal: ill ping you about it in the morning Jul 13 16:43:52 dgilmore: k Jul 13 16:44:05 I'll allow 514/upd for lockbox. Jul 13 16:44:37 Sopwith: I'm just trying to get it tested and tweaked. Jul 13 16:44:49 I'm still poking around with it as well Jul 13 16:44:56 lmacken: Do you have the access needed to actually try it out on the boxes? Jul 13 16:44:57 <-- tibbs has quit (Remote closed the connection) Jul 13 16:45:03 I'm trying to get upstream involved with our efforts as well Jul 13 16:45:22 lmacken: We have 4 proxy servers - it's fine to have one of them drop off the network for a while. Jul 13 16:45:54 lmacken: Do you need anyone else to help with anything there, or is it mainly a matter of setting a goal for yourself? Jul 13 16:47:13 Sopwith: yeah, I have access. The only configuration left is to allow the services on the machines. Jul 13 16:47:18 ok Jul 13 16:47:22 I'm not too familiar with most of them Jul 13 16:47:41 There is a list on the wiki. Have you seen it? Jul 13 16:48:12 yeah Jul 13 16:48:58 I'll see what I can do as far as setting up the configurations. If stuff breaks, just yell ;) Jul 13 16:48:58 OK, moving along Jul 13 16:49:03 lmacken: Sounds good Jul 13 16:49:25 Sopwith: backups? Jul 13 16:49:26 ja8sun/skvidal/et al: Want to say anything about the mirror management system? Jul 13 16:49:30 I do Jul 13 16:49:33 :) Jul 13 16:49:39 I've checked in lots of fun code this week Jul 13 16:49:45 and you can see what it does here: Jul 13 16:49:50 Sopwith: oh you mean mirrors.fedoraproject.org? I think he's got a few things to say :-D Jul 13 16:50:00 http://mirrors.fedoraproject.org/cgi-bin/return-mirrorlist.py?repo=core-5&arch=i386 Jul 13 16:50:05 for example Jul 13 16:50:13 http://mirrors.fedoraproject.org/ Jul 13 16:50:14 ahhhhhhhhhhhh that's so cool! Jul 13 16:50:20 there's a script that generates the text files Jul 13 16:50:31 It actually works too! Jul 13 16:50:33 it uses some routines from yum to check to see if the repomd.xml is current on all the mirrors Jul 13 16:50:41 compared to canonical mirror master Jul 13 16:50:50 (not the company, the definitive) Jul 13 16:50:57 (canonical) Jul 13 16:51:06 Its amazing how many bad mirrors there are out there. I mean look at the extras-5-US-i386.txt mirror: http://mirrors.fedoraproject.org/extras-5-US-i386.txt Jul 13 16:51:08 take a look at check-mirrors in /cvs/fedora Jul 13 16:51:25 it uses python-geoip and some other routines to split it out Jul 13 16:51:34 if your country doesn't have any mirrors Jul 13 16:51:38 then it gives you the global one Jul 13 16:51:46 Awesome. Jul 13 16:51:58 very nice Jul 13 16:52:04 I've got a couple of more things to do to it before I say 'yay' lets use it Jul 13 16:52:16 I'd like for it to use a db on the backend - but right now it's just simple files Jul 13 16:52:20 but it works pretty well Jul 13 16:52:35 I just checked in a new config file which should cover all the mirrors for 5 and rawhide Jul 13 16:52:44 sweeet Jul 13 16:53:05 if anyone wants to fulfill the todos at the top of the file Jul 13 16:53:07 just go for it Jul 13 16:53:26 if I can get about an hour tonight I'll put the new config file in place for it Jul 13 16:53:32 Cool Jul 13 16:53:37 the todos are listed in check-mirror? Jul 13 16:53:42 ja8sun: in the file, yes. Jul 13 16:53:46 thanks Jul 13 16:53:46 look for todo or FIXME Jul 13 16:53:50 it's in python Jul 13 16:53:52 it's not complex code Jul 13 16:54:01 so if you see something stupid just assume I'm a moron Jul 13 16:54:04 not that it was intended Jul 13 16:54:04 :) Jul 13 16:54:14 :) Jul 13 16:54:36 Sopwith: do you know how to get to www.redhat.com from inside the phx colo? Jul 13 16:54:39 Definitely something to dig into later... Jul 13 16:54:51 but the code appears to work Jul 13 16:54:52 mmcgrath: Not offhand. Stacy could tell ya. Jul 13 16:55:03 and I've had the cgi checked out by a couple of real web programmers Jul 13 16:55:07 it should not be dangerous to us Jul 13 16:55:26 the inputs are checked in a couple of ways and they aren't ever expanded out in any useful way to a malicious attacker Jul 13 16:55:46 oh and the mirror files are generated per-arch Jul 13 16:55:52 b/c some mirrors don't carry all archs Jul 13 16:55:57 (which is irritating, imo, but ...) Jul 13 16:56:04 and a lot of the mirrors are DEEPLY fucked up, btw Jul 13 16:56:35 okay, I think I'm done. Jul 13 16:56:49 hehe Jul 13 16:57:01 oh! Jul 13 16:57:09 skvidal: oh! Jul 13 16:57:12 if anyone is l33ter than me with apache scriptaliasmatch Jul 13 16:57:15 or redirectmatch Jul 13 16:57:16 We do need to talk about backups, I think that's the only other thing that really needs time today. Jul 13 16:57:24 I'd like to figure out how to make Jul 13 16:57:47 mirrors.fedoraproject.org/mirrors/reponame/arch/country rewrite out to use the cgi Jul 13 16:57:54 but it's not important just a personal interest Jul 13 16:58:42 skvidal: that shouldn't be terribly hard. Jul 13 16:58:47 mod_rewrite! Jul 13 16:58:54 mmcgrath: and yet I am apparently unable to do it :) Jul 13 16:59:00 I'll take a look ;-) Jul 13 16:59:05 look in mirrors Jul 13 16:59:11 you'll see my bad regex attempts, apparently Jul 13 16:59:13 Sopwith: whats the word on us and backups? Jul 13 16:59:20 My main concern is protecting the backups. Jul 13 16:59:32 mmcgrath: i think ive narowed it down to bacula or backuppc Jul 13 17:00:00 I'm fine with either of those. Jul 13 17:00:09 What would make us choose one or the other? Jul 13 17:00:28 I think bacula is more enterprise and backuppc is simpler. Jul 13 17:00:46 I was between rdiff-backup and backuppc Jul 13 17:00:49 mmcgrath: i agree Jul 13 17:01:16 So count my vote towards backuppc Jul 13 17:01:20 skvidal: you could rewrite everything to the path of the .py and interpret the /reponame/arch/country path to determine what they're trying to find Jul 13 17:01:22 skvidal: what do you guys use over there? Jul 13 17:01:30 i think that backuppc is simpler to restore from but we would need to ssl the interface i think Jul 13 17:01:44 mmcgrath: amanda and rdiff-backup (different types of backups for each) Jul 13 17:01:52 mmcgrath: and then in the big oit-backup-of-doom they use tsm Jul 13 17:01:55 (shudder) Jul 13 17:02:06 I like amanda and rdiff-backup Jul 13 17:02:08 we use NetWorker, but I've also used amanda in the past Jul 13 17:02:10 amanda is good for tape-y things Jul 13 17:02:19 and rdiff-backup is nice for the quick restores Jul 13 17:02:30 I wrote some wrapper scripts to rdiff-backup to give it config-file like things Jul 13 17:02:41 so you edit shit in /etc and it's simple Jul 13 17:03:15 gotta run...have a good day Jul 13 17:03:25 ja8sun: later Jul 13 17:03:30 later Jul 13 17:03:39 l8r ja8sun Jul 13 17:03:39 :) Jul 13 17:03:39 Sopwith: lets say we do the backuppc over an SSH tunnel to disk thing. Jul 13 17:03:47 Where are we going to keep the backups and who has access? Jul 13 17:03:49 skvidal: my main concern with rdiff-backup was resoring single files. logging didint seem as good as it could be Jul 13 17:03:58 <-- ja8sun has quit ("Leaving") Jul 13 17:04:09 I should prefis this with the fact that I have worked at a place that a leaving employee deleted everything *and* the backups. Jul 13 17:04:10 dgilmore: Jul 13 17:04:14 dgilmore: I don't disagree Jul 13 17:04:23 bacula and backuppc have the ability to view logs via the web Jul 13 17:04:25 mmcgrath: Nod... The backups could be stored on both lockbox and on an internal server here... Jul 13 17:04:33 that would be my preference. Jul 13 17:04:35 mmcgrath: Eek, I get where you're coming from. Jul 13 17:04:57 mmcgrath: mmm offsite tapes :) Jul 13 17:05:01 mmcgrath: hard to remove the backups :) Jul 13 17:05:10 I've designed systems where backups existed in two place as well as a tape that was off site at all times just because of that. Jul 13 17:05:10 double backups ? Jul 13 17:05:17 the tape guy was different from the backup guy. Jul 13 17:05:46 So how about lockbox also be the system that all the backups funnel into, and then an internal server (to be maintained by someone here) to mirror from there Jul 13 17:06:08 (Not that this has any bearing on the backup software decision, but it's a good question) Jul 13 17:06:08 Sopwith: would work for me if lockbox has enough space Jul 13 17:06:11 Sopwith: That sounds good to me. Jul 13 17:06:14 agreed. Jul 13 17:06:20 dgilmore: lockbox used to be the cvs server - 249G free Jul 13 17:06:29 we *might* have to move the backups off of the machine that nagios is on but we can deal with that later. Jul 13 17:06:36 Sopwith: that should be enough :) Jul 13 17:06:39 plugins time out when the machine is under heavy load. Jul 13 17:06:54 renice or somesuch... Jul 13 17:07:04 yeah, there's options. Jul 13 17:07:53 how about a vote? Jul 13 17:07:56 It's all fixable. What we need to do right now is agree on a piece of software, and start setting it up Jul 13 17:08:07 * mmcgrath notes we so rarely vote on stuff :-D Jul 13 17:08:37 I am fine with whatever dgilmore has researched, and it sounds like backuppc is on most people's short lists, so in the interest of making a decision, I suggest going with it. Jul 13 17:08:50 And in the worst case, we find out we were *gasp* wrong and need to switch :) Jul 13 17:09:33 hah true that. Jul 13 17:09:39 backuppc sounds fine with me. Jul 13 17:09:52 I am fine with backuppc Jul 13 17:09:53 Sopwith: id say between bacula and backuppc Jul 13 17:09:55 mmcgrath: wow, that's lame! Jul 13 17:10:37 eiter option needs to be packaged for extras Jul 13 17:10:46 Sounds like a good "next step" :) Jul 13 17:11:07 * rordway is fine with anything that doesn't involve me having to swap tapes Jul 13 17:11:19 :-) Jul 13 17:11:24 hehe Jul 13 17:11:32 lets make rordway switch tapes! Jul 13 17:11:37 nooooo! Jul 13 17:11:46 I can package that up for extras if we want. Jul 13 17:11:52 I got no job right now so I can do that ;-) Jul 13 17:12:02 mmcgrath: you're unemployed? Jul 13 17:12:04 really? Jul 13 17:12:15 oh, mmcgrath, do I have access to the nagios box? Jul 13 17:12:24 yeah, had a "moment" with my boss on tuesday so today he asked me to resign. Jul 13 17:12:33 * iWolf thnks he was the guy the deleted all data and backups.... Jul 13 17:12:40 iWolf: maybe so Jul 13 17:12:48 mmcgrath: ill leave it to you to package Jul 13 17:12:53 k, will do. Jul 13 17:13:13 Let's start a company to manufacture and sell a "Ryan Ordway 2000" tape robot, featuring DNA technology. mmcgrath will be CEO... Jul 13 17:13:37 * mmcgrath goes off to register a domain right now Jul 13 17:13:40 * dgilmore will be flunky Jul 13 17:13:44 heheh OK Jul 13 17:14:32 haha Jul 13 17:14:38 For next week, it sounds like mmcgrath wants to get a backuppc package going, and we can go from there. Jul 13 17:14:43 need inpuuuut Jul 13 17:15:32 mmcgrath: add me as a cc and ill review it Jul 13 17:15:36 dennis at ausil.us Jul 13 17:15:49 will do Jul 13 17:16:14 I think we're pretty much done this meeting thing. Anything else to go over before we get back to hacking? Jul 13 17:16:23 Nothing here. Jul 13 17:16:29 nothing Jul 13 17:16:38 nothing here Jul 13 17:16:42 nothing here covered what i wanted to Jul 13 17:17:08 Cool. Meeting over - happy hacking! Jul 13 17:17:29 Later all.... Jul 13 17:17:41 aieet Jul 13 17:17:45 bye Jul 13 17:17:51 <-- pasqual (n=pasqual at 81-202-75-184.user.ono.com) has left #fedora-admin ("Leaving") Jul 13 17:19:06 mmcgrath: how do I get to the nagios box? was going to poke around Jul 13 17:21:16 rordway: I think you need to be in the sysadmin main group Jul 13 17:21:39 k Jul 13 17:21:49 <-- skvidal (n=skvidal at fedora/skvidal) has left #fedora-admin ("Ex-Chat") Jul 13 17:22:56 I think I put in a request for that Jul 13 17:23:03 lemme check Jul 13 17:35:05 Hey Rordway: I have to get going but I'll double check as to why you don't have an account yet. Jul 13 17:36:29 mmcgrath: cool thanks From mmcgrath at fedoraproject.org Fri Jul 14 14:43:51 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 14 Jul 2006 09:43:51 -0500 Subject: [Fedora-infrastructure-list] Stronger passwords needed? Message-ID: <3237e4410607140743sc5ed6efuf9868d35b419e71a@mail.gmail.com> Do we need to enable stronger passwords? http://linux.slashdot.org/linux/06/07/14/0036232.shtml -Mike From lmacken at redhat.com Fri Jul 14 15:34:47 2006 From: lmacken at redhat.com (Luke Macken) Date: Fri, 14 Jul 2006 11:34:47 -0400 Subject: [Fedora-infrastructure-list] TurboGears update Message-ID: <20060714153444.GA4217@crow.rdu.redhat.com> I bumped FC-5 and devel branches to 0.8.9 last week, and have been working on getting 0.9a6 packaged up for devel. I wrote RPMS for the rest of the dependencies for the latest TG, which are waiting for review: Bug #198285 - python-simplejson Bug #198289 - python-pastescript Bug #198287 - python-paste Bug #198288 - python-pastedeploy Bug #198284 - python-configobj A few existing packages will need to get bumped as well: Bug #198905 python-formencode >= 0.5.1 python-sqlobject >= 0.7.1dev_r1457 TurboJson, TurboCheetah, TurboKid, and fastdata are all deps as well, but are shipped in the TurboGears tarball in the plugins/ directory. So these will most likely need to be pulled out into subpackages of TurboGears (unless someone can think of a better way to do it). Since Ignacio is MIA, I'll probably end up making these bumps once we get the rest of the deps into extras. So, if anyone has any free time on their hands, package reviews would definitely be appreciated :) luke From skvidal at linux.duke.edu Sat Jul 15 14:37:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 15 Jul 2006 10:37:39 -0400 Subject: [Fedora-infrastructure-list] better passwords ,etc Message-ID: <1152974260.5388.5.camel@cutter> Hi, Following on the post about stronger passwords - I have a better idea - why don't we have no password at all. meaning - if you don't have the ssh key you cannot login to any of our systems. Then we don't have to muck with passwords at all we just put nice little !! in the field in the shadow.db file and we're done with it. What do you think? -sv From bugs.michael at gmx.net Sat Jul 15 16:34:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 15 Jul 2006 18:34:42 +0200 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <1152974260.5388.5.camel@cutter> References: <1152974260.5388.5.camel@cutter> Message-ID: <20060715183442.772fd3c3.bugs.michael@gmx.net> On Sat, 15 Jul 2006 10:37:39 -0400, seth vidal wrote: > Hi, > Following on the post about stronger passwords - I have a better idea - > why don't we have no password at all. > > meaning - if you don't have the ssh key you cannot login to any of our > systems. > > Then we don't have to muck with passwords at all we just put nice > little !! in the field in the shadow.db file and we're done with it. > > What do you think? What about the passwords to the web interface? ;) From pasqual.milvaques at gmail.com Sat Jul 15 17:47:42 2006 From: pasqual.milvaques at gmail.com (pasqual milvaques) Date: Sat, 15 Jul 2006 19:47:42 +0200 Subject: [Fedora-infrastructure-list] presentation and draft of page https://admin.fedoraproject.org/ Message-ID: <44B92A3E.90306@gmail.com> hi people my name is pasqual milvaques, I'm a spanish dba and software developer and I'm going to try to give a hand to you in creating a homepage for the fedora infrastructure project and in other things I can help. I have created a draft for the page which I send attached with this mail. The idea is to have in this page a list of all infrastructure pieces which are being used with their links and some basic information. the draft has not all the links, I will review it to add more links that I have seen in the fedora infrastructure mailing list and (of course) any link you indicate to me. In the next days I will review it and will take deeper look to the wiki to search for more information (all this system is bigger than I expected) and to define the work methodology. well, take a look to the draft as in it you will find some of my doubts (what is docs-rawhide? where is nagios?) and make me any comments you find relevant regards and will be in contact pasqual -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora_project_admin_page.tar.gz Type: application/x-gzip Size: 29374 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Sat Jul 15 18:31:37 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 15 Jul 2006 13:31:37 -0500 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <20060715183442.772fd3c3.bugs.michael@gmx.net> References: <1152974260.5388.5.camel@cutter> <20060715183442.772fd3c3.bugs.michael@gmx.net> Message-ID: <3237e4410607151131h78f6e2e9l93dc9d364b2ed01@mail.gmail.com> On 7/15/06, Michael Schwendt wrote: > On Sat, 15 Jul 2006 10:37:39 -0400, seth vidal wrote: > > > Hi, > > Following on the post about stronger passwords - I have a better idea - > > why don't we have no password at all. > > > > meaning - if you don't have the ssh key you cannot login to any of our > > systems. > > > > Then we don't have to muck with passwords at all we just put nice > > little !! in the field in the shadow.db file and we're done with it. > > > > What do you think? > > What about the passwords to the web interface? ;) > We could at least make that requirement for anything SSH or shell related. For the web interfaces I propose forcing everyone to use ssh tunnels :-D Ok, maybe not. -Mike From lyz27 at yahoo.com Sat Jul 15 19:25:34 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Sat, 15 Jul 2006 14:25:34 -0500 Subject: [Fedora-infrastructure-list] Database for Account System 2 Message-ID: <1152991534.14036.8.camel@localhost> I need to know what database and engine we are going to use on the new account system. Is that up for discussion, or are we gonna stick with postgresql? ~tom -------------- 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 linux at elfshadow.net Sat Jul 15 19:31:12 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Sat, 15 Jul 2006 15:31:12 -0400 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <1152991534.14036.8.camel@localhost> References: <1152991534.14036.8.camel@localhost> Message-ID: <44B94280.5040104@elfshadow.net> Tom Lynema wrote: > I need to know what database and engine we are going to use on the new > account system. Is that up for discussion, or are we gonna stick with > postgresql? At this point has it even been decided if it is going to be an LDAP backend, SQL backend or a combination of the two? I think even that point was still being discussed. -Jeffrey From linux at elfshadow.net Sat Jul 15 19:51:56 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Sat, 15 Jul 2006 15:51:56 -0400 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <1152974260.5388.5.camel@cutter> References: <1152974260.5388.5.camel@cutter> Message-ID: <44B9475C.20609@elfshadow.net> seth vidal wrote: > Following on the post about stronger passwords - I have a better idea - > why don't we have no password at all. > > meaning - if you don't have the ssh key you cannot login to any of our > systems. > > Then we don't have to muck with passwords at all we just put nice > little !! in the field in the shadow.db file and we're done with it. > > What do you think? I think this is a great idea. I think we all know passwords are the bane of securing any system. Using keys only would certainly be a move to the right direction. In our case though I think there is another problem area where a password is still a weakness. The Account System is a component in how our ssh keys get distributed currently. So if someone were to compromise a sysadmin's password for the web based Account System they would then be able to edit that individual's profile and change the ssh key for that user which would be distributed across the systems they have shell access to. Now the intruder can access the systems with the ssh key pair they own (at least until the original user noticed they couldn't login anymore). At least I think that would be an attack vector that could target a password. Perhaps I am unaware of a component of the Account System or I am missing something else that would cause the above scenario to not work, so feel free to point out the obvious! If the above scenario is an accurate one though, we still are relying on passwords to secure access to the systems to some extent. It may be an area we want to look at to force some sort of check or balance to minimize even that possibility. While on the topic of security and moving beyond passwords, perhaps the group as a whole should brainstorm, check settings, etc on the system and processes from the security perspective. There are lots of intelligent individuals on the team and some time spent towards a security audit of sorts could prove useful just to make sure we are truly following best practices (or going above and beyond) and aren't assuming certain things about the system configurations that really aren't in place. -Jeffrey From jonathansteffan at gmail.com Sun Jul 16 00:01:48 2006 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Sat, 15 Jul 2006 18:01:48 -0600 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <44B94280.5040104@elfshadow.net> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> Message-ID: <44B981EC.9040702@gmail.com> Jeffrey Tadlock wrote: > Tom Lynema wrote: >> I need to know what database and engine we are going to use on the new >> account system. Is that up for discussion, or are we gonna stick with >> postgresql? > > At this point has it even been decided if it is going to be an LDAP > backend, SQL backend or a combination of the two? I think even that > point was still being discussed. > > -Jeffrey > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > I would personally love to see LDAP go into action and offer my services to help setup and support using Fedora Directory Server. I currently have Fedora Directory Server working well with plone and have started to work on getting moinmoin to authenticate to the same user directory. What other services would need to authenticate to the same user directory? I also suspect moving accounts from SQL to LDAP should be fairly easy. I could script it using perl. Also, an SQL backend could be setup for Fedora Directory Server using plugins. (http://directory.fedora.redhat.com/wiki/Plugins) A brief google search turns up no SQL plugins. Jonathan Steffan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mmcgrath at fedoraproject.org Sun Jul 16 02:14:28 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 15 Jul 2006 21:14:28 -0500 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <44B9475C.20609@elfshadow.net> References: <1152974260.5388.5.camel@cutter> <44B9475C.20609@elfshadow.net> Message-ID: <3237e4410607151914r2829f5f9k36a3c98f5543cce8@mail.gmail.com> On 7/15/06, Jeffrey Tadlock wrote: > > I think this is a great idea. I think we all know passwords are the > bane of securing any system. Using keys only would certainly be a move > to the right direction. > > In our case though I think there is another problem area where a > password is still a weakness. The Account System is a component in how > our ssh keys get distributed currently. So if someone were to > compromise a sysadmin's password for the web based Account System they > would then be able to edit that individual's profile and change the ssh > key for that user which would be distributed across the systems they > have shell access to. Now the intruder can access the systems with the > ssh key pair they own (at least until the original user noticed they > couldn't login anymore). > > At least I think that would be an attack vector that could target a > password. Perhaps I am unaware of a component of the Account System or > I am missing something else that would cause the above scenario to not > work, so feel free to point out the obvious! > > If the above scenario is an accurate one though, we still are relying on > passwords to secure access to the systems to some extent. It may be an > area we want to look at to force some sort of check or balance to > minimize even that possibility. > > While on the topic of security and moving beyond passwords, perhaps the > group as a whole should brainstorm, check settings, etc on the system > and processes from the security perspective. There are lots of > intelligent individuals on the team and some time spent towards a > security audit of sorts could prove useful just to make sure we are > truly following best practices (or going above and beyond) and aren't > assuming certain things about the system configurations that really > aren't in place. > > -Jeffrey We'll have to find the balance. We could go key kerberos crazy if we wanted to. On the one hand we should have a very secure system. On the other hand we cannot burden the developers. After all thats the whole reason our team exists... to aid the developers. It should also be said that I've never actually worked at a place that would end up on Slashdot if we got hacked.... I guess there's a bit of pride in me that wants to make sure that if the Fedora infrastructure ever does get hacked that it doesn't happen on my watch :-D From linux at elfshadow.net Sun Jul 16 02:34:27 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Sat, 15 Jul 2006 22:34:27 -0400 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <44B99CC6.5090507@elfshadow.net> References: <1152974260.5388.5.camel@cutter> <44B9475C.20609@elfshadow.net> <3237e4410607151318l6448c81fyae7300000a82fb34@mail.gmail.com> <44B99CC6.5090507@elfshadow.net> Message-ID: <44B9A5B3.20901@elfshadow.net> Mike McGrath wrote: > We'll have to find the balance. We could go key > kerberos crazy if we wanted to. On the one hand we should have a > very secure system. On the other hand we cannot burden the > developers. After all thats the whole reason our team exists... to > aid the developers. There is definitely a balance to be struck. Keep the systems usable while at the same time secure. The sysadmin's conundrum, eh? SSH keys shouldn't be a big deal to developers though right? As far as the web passwords, we obviously can't do away with those, that crosses the usability line. But maybe there needs to be a check in place before the ssh keys are pushed across systems? Not sure how that check would work without adding overhead though. In either case, finding potential pitfalls as these are part of determining the balance. At least knowing where the weaker points of the system are will allow us as a group to decide the acceptabilty of that risk. An audit such as I suggest should help us find our weaker spots along the way so we can at least discuss them and weigh risks versus benefits. The best practices portion are often times changes that few would notice but could reduce our attack vector with no real penalty. Take a peek a the sshd_config on bastion sometime. I was a little surprised. I had assumed that host was only accepting ssh keys. Hardening ssh on that machine wouldn't affect many people at all and we would still see some potential gains from it. > It should also be said that I've never actually worked at a place > that would end up on Slashdot if we got hacked.... I guess there's a > bit of pride in me that wants to make sure that if the Fedora > infrastructure ever does get hacked that it doesn't happen on my > watch Agreed!! :) -Jeffrey From nman64 at n-man.com Sun Jul 16 03:26:01 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 15 Jul 2006 22:26:01 -0500 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <44B9A5B3.20901@elfshadow.net> References: <1152974260.5388.5.camel@cutter> <44B99CC6.5090507@elfshadow.net> <44B9A5B3.20901@elfshadow.net> Message-ID: <200607152226.03653.nman64@n-man.com> On Saturday 15 July 2006 21:34, Jeffrey Tadlock wrote: > Mike McGrath wrote: > > We'll have to find the balance. We could go key > > > > kerberos crazy if we wanted to. On the one hand we should have a > > very secure system. On the other hand we cannot burden the > > developers. After all thats the whole reason our team exists... to > > aid the developers. > > There is definitely a balance to be struck. Keep the systems usable > while at the same time secure. The sysadmin's conundrum, eh? > > SSH keys shouldn't be a big deal to developers though right? > > As far as the web passwords, we obviously can't do away with those, that > crosses the usability line. But maybe there needs to be a check in > place before the ssh keys are pushed across systems? Not sure how that > check would work without adding overhead though. I'm sure that many of us would probably be more tolerant of security restrictions than other developers might be, so we'll have to be careful. Something to consider for web authentication would be SSL client certificates combined with passwords. It would be an additional barrier, but it would be widely supported and shouldn't be too hard to enable in key places. I'm concerned that it would be going too far, but I wanted to throw the idea out. :-) Other things to consider are simple rules, like timed lockouts after repeated auth failures, password strength or expiry requirements, hostmask filters, two-factor auth, strategic interface design, etc. One thing I most recently noticed was that you need only an account name to request a password reset URL be emailed. We could require two pieces of information for verification. It doesn't add much security, but might prevent some man-in-the-middle attacks and could reduce spam like many of our contributors recently experienced. > > In either case, finding potential pitfalls as these are part of > determining the balance. At least knowing where the weaker points of > the system are will allow us as a group to decide the acceptabilty of > that risk. An audit such as I suggest should help us find our weaker > spots along the way so we can at least discuss them and weigh risks > versus benefits. > > The best practices portion are often times changes that few would notice > but could reduce our attack vector with no real penalty. Take a peek a > the sshd_config on bastion sometime. I was a little surprised. I had > assumed that host was only accepting ssh keys. Hardening ssh on that > machine wouldn't affect many people at all and we would still see some > potential gains from it. I had actually spoken with Elliot briefly about this before the Infrastructure team was put together. He had reasons to keep the systems allowing passwords. I'll wait for him to chime in on this thread with any reasons that are still blockers. > > > It should also be said that I've never actually worked at a place > > that would end up on Slashdot if we got hacked.... I guess there's a > > bit of pride in me that wants to make sure that if the Fedora > > infrastructure ever does get hacked that it doesn't happen on my > > watch > > Agreed!! :) > +1 -- 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 nman64 at n-man.com Sun Jul 16 03:34:09 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 15 Jul 2006 22:34:09 -0500 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <44B981EC.9040702@gmail.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> Message-ID: <200607152234.11997.nman64@n-man.com> On Saturday 15 July 2006 19:01, Jonathan Steffan wrote: > > I would personally love to see LDAP go into action and offer my services > to help setup and support using Fedora Directory Server. I currently > have Fedora Directory Server working well with plone and have started to > work on getting moinmoin to authenticate to the same user directory. > What other services would need to authenticate to the same user > directory? I also suspect moving accounts from SQL to LDAP should be > fairly easy. I could script it using perl. Also, an SQL backend could be > setup for Fedora Directory Server using plugins. > (http://directory.fedora.redhat.com/wiki/Plugins) A brief google search > turns up no SQL plugins. > I would love to see an LDAP+SQL solution that gives us a familiar SQL backend with an LDAP client interface. It might take a little work to make that happen, but it might well be worth it. Many of the solutions we are currently using support LDAP, while many of us are more familiar with SQL and current Account System services are SQL-enabled. It seems to me that if we don't figure out a solution for LDAP+SQL, we'll end up spending a lot of time making different solutions work with the technology we choose. -- 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 linux at elfshadow.net Sun Jul 16 03:53:05 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Sat, 15 Jul 2006 23:53:05 -0400 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <44B94280.5040104@elfshadow.net> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> Message-ID: <44B9B821.6070309@elfshadow.net> Jeffrey Tadlock wrote: > At this point has it even been decided if it is going to be an LDAP > backend, SQL backend or a combination of the two? I think even that > point was still being discussed. To help facilitate the LDAP versus SQL debate I have added a link off of Tom's AccountSystem2 Wiki page http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 to an LDAP versus SQL page: http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/LDAPvsSQL Since the discussion has been ongoing in bursts here and there, I tried to consolidate people's thoughts in one place. I hope it will make it easier for everyone to see what folks are thinking and comments for or against any one solution. I include links to emails in the archives and even a few snippets from IRC logs. There is also a "Currently Leaning" entry that shows which direction a person is leaning towards (feel free to change that if you have either changed your mind or I simply interpreted your lean wrong :) ). I may have missed comments from someone as well, as not everyone appears to be represented on the page I put up. So if I missed you feel free to add yourself to the page, but I suggest we keep the discussion on the mailing list and use the Wiki simply to consolidate some of those thoughts. Tom has done a good job of listing requirements on the AccountSystem2 page, so hopefully the two pages together can help us come to a consensus and make the first steps forward. -Jeffrey From skvidal at linux.duke.edu Sun Jul 16 14:13:31 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 16 Jul 2006 10:13:31 -0400 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <20060715183442.772fd3c3.bugs.michael@gmx.net> References: <1152974260.5388.5.camel@cutter> <20060715183442.772fd3c3.bugs.michael@gmx.net> Message-ID: <1153059211.5388.15.camel@cutter> On Sat, 2006-07-15 at 18:34 +0200, Michael Schwendt wrote: > On Sat, 15 Jul 2006 10:37:39 -0400, seth vidal wrote: > > > Hi, > > Following on the post about stronger passwords - I have a better idea - > > why don't we have no password at all. > > > > meaning - if you don't have the ssh key you cannot login to any of our > > systems. > > > > Then we don't have to muck with passwords at all we just put nice > > little !! in the field in the shadow.db file and we're done with it. > > > > What do you think? > > What about the passwords to the web interface? ;) > Two options spring to mind: 1. we use ssl certs for client auth which firefox, mozilla and konqueror can all do now. 2. we keep the passwords for the web interface b/c there is less chance of a local root compromise from someone who just has access to the web interface than someone with shell access. Think about this in light of the debian rooting. We give shell access out to many people who might have crappy passwords. Let's go for the low hanging fruit here. -sv From lyz27 at yahoo.com Sun Jul 16 17:14:47 2006 From: lyz27 at yahoo.com (Tom Lynema) Date: Sun, 16 Jul 2006 12:14:47 -0500 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <200607152234.11997.nman64@n-man.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> Message-ID: <1153070087.14071.13.camel@localhost> > I would love to see an LDAP+SQL solution that gives us a familiar SQL backend > with an LDAP client interface. It might take a little work to make that > happen, but it might well be worth it. Many of the solutions we are > currently using support LDAP, while many of us are more familiar with SQL and > current Account System services are SQL-enabled. It seems to me that if we > don't figure out a solution for LDAP+SQL, we'll end up spending a lot of time > making different solutions work with the technology we choose. > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com I would like to see an SQL backend with an API pointing into it, similar to what Amazon.com is doing. Benefits: SSL access The API will act as a layer between the database and the calling application instead of just allowing access to the data. This could be used to help protect security and privacy. 3rd parties could use the API to make their own extensions of the system Pitfalls: Do we want everyone to have access to the API? This may result in abuse of the data. -tom -------------- 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 jonathansteffan at gmail.com Sun Jul 16 23:32:02 2006 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Sun, 16 Jul 2006 17:32:02 -0600 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <1153070087.14071.13.camel@localhost> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> <1153070087.14071.13.camel@localhost> Message-ID: <44BACC72.2090607@gmail.com> Fedora Directory Server supports TLS and SSL. So does openldap. I think an API built on top of LDAP would have more abilities. Does PGSQL support slave servers and replication? Jon Tom Lynema wrote: >> I would love to see an LDAP+SQL solution that gives us a familiar SQL backend >> with an LDAP client interface. It might take a little work to make that >> happen, but it might well be worth it. Many of the solutions we are >> currently using support LDAP, while many of us are more familiar with SQL and >> current Account System services are SQL-enabled. It seems to me that if we >> don't figure out a solution for LDAP+SQL, we'll end up spending a lot of time >> making different solutions work with the technology we choose. >> >> -- >> Patrick "The N-Man" Barnes >> nman64 at n-man.com >> > > > I would like to see an SQL backend with an API pointing into it, similar > to what Amazon.com is doing. > Benefits: > SSL access > The API will act as a layer between the database and the calling > application instead of just allowing access to the data. This could be > used to help protect security and privacy. > 3rd parties could use the API to make their own extensions of the system > Pitfalls: > Do we want everyone to have access to the API? This may result in abuse > of the data. > > > -tom > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From sopwith at redhat.com Mon Jul 17 06:14:53 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 17 Jul 2006 02:14:53 -0400 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <44B981EC.9040702@gmail.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> Message-ID: On Jul 15, 2006, at 20:01, Jonathan Steffan wrote: > I would personally love to see LDAP go into action and offer my > services > to help setup and support using Fedora Directory Server. I currently > have Fedora Directory Server working well with plone and have > started to > work on getting moinmoin to authenticate to the same user directory. > What other services would need to authenticate to the same user > directory? I also suspect moving accounts from SQL to LDAP should be > fairly easy. I could script it using perl. Also, an SQL backend > could be > setup for Fedora Directory Server using plugins. > (http://directory.fedora.redhat.com/wiki/Plugins) A brief google > search > turns up no SQL plugins. 1. Not sure why we would want to have FDS as a layer on top of an SQL server. 2. Do you have a way to make FDS' schema meet all the requirements currently listed on Tom's "new account system" wiki page (e.g. groups that inherit members from other groups, users with multiple e-mail addresses listed, and so forth)? 3. Do you have a query language for FDS that can do anything usefully near SQL? Best, -- Elliot From sopwith at redhat.com Mon Jul 17 06:18:40 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 17 Jul 2006 02:18:40 -0400 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <44BACC72.2090607@gmail.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> <1153070087.14071.13.camel@localhost> <44BACC72.2090607@gmail.com> Message-ID: <7127A95F-58D5-4554-9CFC-4D392051F8A0@redhat.com> On Jul 16, 2006, at 19:32, Jonathan Steffan wrote: > Fedora Directory Server supports TLS and SSL. So does openldap. I > think > an API built on top of LDAP would have more abilities. Such as? :) > Does PGSQL > support slave servers and replication? It's not built-in. There are packages to do it (Curt Moore knows a lot more about them than I). -- Elliot From sopwith at redhat.com Mon Jul 17 06:25:22 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 17 Jul 2006 02:25:22 -0400 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <200607152234.11997.nman64@n-man.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> Message-ID: <695704AB-68F8-4DA1-87DD-18A3F691B723@redhat.com> On Jul 15, 2006, at 23:34, Patrick W. Barnes wrote: > I would love to see an LDAP+SQL solution that gives us a familiar > SQL backend > with an LDAP client interface. What does an LDAP client interface consist of, and why's it important? Y'all gotta know two things: - I don't see an implementation on LDAP producing all this happy fun synergy people are imagining. AFAIK, the existing LDAP admin tools are going to be as useful/useless as phpmysql, the moment you show them a schema (such as the one we need) that differs from the standard POSIX account schema for LDAP. The existing admin tools can't fathom things like enforcing sponsorship requirements. Ergo, they aren't going to provide any benefits in our situation. - The person who writes the new account system code will wind up being the one who really makes the decision. So if you want stuff to happen your way, start writing code and proving me wrong! :) Best, -- Elliot From sopwith at redhat.com Mon Jul 17 06:31:22 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 17 Jul 2006 02:31:22 -0400 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <200607152234.11997.nman64@n-man.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> Message-ID: <8B0505C7-C051-4CCE-AF14-F90154E94EC9@redhat.com> On Jul 15, 2006, at 23:34, Patrick W. Barnes wrote: > I would love to see an LDAP+SQL solution Another random thought... What would such a solution look like in reality - how would the pieces fit together? Is it something that is feasible to implement in 2-3 weeks with the people we have on the infrastructure team? (My guess is that we'd be better off going with LDAP than trying to combobulate both LDAP and SQL into the end solution - fewer access methods to support, fewer utilities to administer, and less time to implement.) Best, -- Elliot From gauret at free.fr Mon Jul 17 10:16:40 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 17 Jul 2006 12:16:40 +0200 Subject: [Fedora-infrastructure-list] better passwords ,etc In-Reply-To: <44B9475C.20609@elfshadow.net> References: <1152974260.5388.5.camel@cutter> <44B9475C.20609@elfshadow.net> Message-ID: <200607171216.44107.gauret@free.fr> > While on the topic of security and moving beyond passwords, perhaps the > group as a whole should brainstorm, check settings, etc on the system > and processes from the security perspective. I've package a set of shell scripts called "tiger" in Extras which tries to do that. Someone with root access could run it and check the results. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Unix IS user-friendly. It is just very picky about who his friends are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Mon Jul 17 16:04:33 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 17 Jul 2006 09:04:33 -0700 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <44BACC72.2090607@gmail.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> <1153070087.14071.13.camel@localhost> <44BACC72.2090607@gmail.com> Message-ID: <1153152273.19734.35.camel@localhost> On Sun, 2006-07-16 at 17:32 -0600, Jonathan Steffan wrote: > Fedora Directory Server supports TLS and SSL. So does openldap. I think > an API built on top of LDAP would have more abilities. Does PGSQL > support slave servers and replication? > There are two good projects, slony-i_ and pg-cluster, that support master-slave replication and multi-master replication respectively. I haven't used either but Curt Moore mentioned he uses slony-i during one of the IRC meetings. slony-i_ http://gborg.postgresql.org/project/slony1/projdisplay.php pg-cluster_ http://pgfoundry.org/projects/pgcluster/ I think we're going to be doing a lot of programming against the backend no matter what so I want to know what LDAP offers to me as a developer of web applications. - python-ldap seems to be the python bridge to ldap. Arethere alternatives or is this the way to go? - Can we update the LDAP schema easily when we decide we need to take more information? (We need to start retinal scans for security or want to have hackergotchi to make the entries more personalized in the future.) - SQL has grant and revoke to assign users privileges on individual database tables. Does LDAP have similar? (I find I use SQL's separation of select, update, and insert as well. I don't know if we'd need more than read-write vs read-only for the account db but is it possible to separate all of these independently?) - SQL and python have SQLObject to make python objects backed by SQL db storage very easy. I don't know if we want this for the accounts db (security may not be fine-grained enough) - I enjoy postgresql's ability to constrain data via foreign keys, regexps, etc. Does LDAP allow the same type of things in its schemas? -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 jonathansteffan at gmail.com Mon Jul 17 17:36:05 2006 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Mon, 17 Jul 2006 11:36:05 -0600 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <1153152273.19734.35.camel@localhost> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> <1153070087.14071.13.camel@localhost> <44BACC72.2090607@gmail.com> <1153152273.19734.35.camel@localhost> Message-ID: <44BBCA85.6050307@gmail.com> Toshio Kuratomi wrote: > On Sun, 2006-07-16 at 17:32 -0600, Jonathan Steffan wrote: > >> Fedora Directory Server supports TLS and SSL. So does openldap. I think >> an API built on top of LDAP would have more abilities. Does PGSQL >> support slave servers and replication? >> >> > There are two good projects, slony-i_ and pg-cluster, that support > master-slave replication and multi-master replication respectively. I > haven't used either but Curt Moore mentioned he uses slony-i during one > of the IRC meetings. > > slony-i_ http://gborg.postgresql.org/project/slony1/projdisplay.php > pg-cluster_ http://pgfoundry.org/projects/pgcluster/ > I ask because Fedora Directory Server does this well. > I think we're going to be doing a lot of programming against the backend > no matter what so I want to know what LDAP offers to me as a developer > of web applications. > To me, LDAP seems fairly supported... in the sense there is a published schema so software developers have a 'map' to design by. For example, Plone allows you to map internal user variables to proper LDAP schema and it works out well (a fairly standard schema [inetOrgPerson] has all the needed user properties.) I have a few projects going to test if a single LDAP user directory would be able to authenticate Bugzilla, plone, moinmoin and SVN/CVS. > - python-ldap seems to be the python bridge to ldap. Arethere > alternatives or is this the way to go? > As I am not a python guru yet, and thus this is all I have worked with. > - Can we update the LDAP schema easily when we decide we need to take > more information? (We need to start retinal scans for security or want > to have hackergotchi to make the entries more personalized in the > future.) > Yes. > - SQL has grant and revoke to assign users privileges on individual > database tables. Does LDAP have similar? (I find I use SQL's > separation of select, update, and insert as well. I don't know if we'd > need more than read-write vs read-only for the account db but is it > possible to separate all of these independently?) > Fedora Directory Server supports a very fine grained security model. Some random links: http://directory.fedora.redhat.com/wiki/Architecture#Roles http://directory.fedora.redhat.com/wiki/Features http://directory.fedora.redhat.com/wiki/Get_Effective_Rights_Design > - SQL and python have SQLObject to make python objects backed by SQL db > storage very easy. I don't know if we want this for the accounts db > (security may not be fine-grained enough) > I have only worked with hacking existing python code and working with the perl DBI (supporting LDAP) and other CPAN modules for working with LDAP. > - I enjoy postgresql's ability to constrain data via foreign keys, > regexps, etc. Does LDAP allow the same type of things in its schemas? > > -Toshio > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jcmoore at nuvio.com Tue Jul 18 01:52:12 2006 From: jcmoore at nuvio.com (Curt Moore) Date: Mon, 17 Jul 2006 20:52:12 -0500 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <1153152273.19734.35.camel@localhost> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> <1153070087.14071.13.camel@localhost> <44BACC72.2090607@gmail.com> <1153152273.19734.35.camel@localhost> Message-ID: <1153187532.25020.12.camel@runabout.nuvio.com> > There are two good projects, slony-i_ and pg-cluster, that support > master-slave replication and multi-master replication respectively. I > haven't used either but Curt Moore mentioned he uses slony-i during one > of the IRC meetings. Yes, I use Slony-I in my production environment and like most other complex software packages, it works quite well if it's configured correctly. As Toshio mentioned, Slony-I is a single master, multi-slave architecture so write operations can only be performed to a master DB and those changes then have to be replicated down to the slave servers. There are provisions for promoting a slave to be the master server in case the master crashes but they advise doing everything humanly possible to ensure that this doesn't happen. > > slony-i_ http://gborg.postgresql.org/project/slony1/projdisplay.php > pg-cluster_ http://pgfoundry.org/projects/pgcluster/ > The last time I experimented with PGCluster, which is multi-master/multi-slave, probably around Oct/Nov of 2005, I was using PostgreSQL 8.0.1 and it wasn't that well supported at that time. Its architecture was also quite hardware intensive in order to avoid a SPOF, which wouldn't have been a big deal to me if it had worked. The project has since progressed and I believe they have improved support for Postgres 8.x so it may warrant further investigation in our discussions for DB replication; I've just not had time to get around to testing the updated versions in my environment. -Curt From jonathansteffan at gmail.com Tue Jul 18 04:26:09 2006 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Mon, 17 Jul 2006 22:26:09 -0600 Subject: [Fedora-infrastructure-list] Database for Account System 2 In-Reply-To: <1153187532.25020.12.camel@runabout.nuvio.com> References: <1152991534.14036.8.camel@localhost> <44B94280.5040104@elfshadow.net> <44B981EC.9040702@gmail.com> <200607152234.11997.nman64@n-man.com> <1153070087.14071.13.camel@localhost> <44BACC72.2090607@gmail.com> <1153152273.19734.35.camel@localhost> <1153187532.25020.12.camel@runabout.nuvio.com> Message-ID: <44BC62E1.6030308@gmail.com> Curt Moore wrote: >> There are two good projects, slony-i_ and pg-cluster, that support >> master-slave replication and multi-master replication respectively. I >> haven't used either but Curt Moore mentioned he uses slony-i during one >> of the IRC meetings. >> > > Yes, I use Slony-I in my production environment and like most other > complex software packages, it works quite well if it's configured > correctly. As Toshio mentioned, Slony-I is a single master, multi-slave > architecture so write operations can only be performed to a master DB > and those changes then have to be replicated down to the slave servers. > There are provisions for promoting a slave to be the master server in > case the master crashes but they advise doing everything humanly > possible to ensure that this doesn't happen. > > >> slony-i_ http://gborg.postgresql.org/project/slony1/projdisplay.php >> pg-cluster_ http://pgfoundry.org/projects/pgcluster/ >> >> > > The last time I experimented with PGCluster, which is > multi-master/multi-slave, probably around Oct/Nov of 2005, I was using > PostgreSQL 8.0.1 and it wasn't that well supported at that time. Its > architecture was also quite hardware intensive in order to avoid a SPOF, > which wouldn't have been a big deal to me if it had worked. The project > has since progressed and I believe they have improved support for > Postgres 8.x so it may warrant further investigation in our discussions > for DB replication; I've just not had time to get around to testing the > updated versions in my environment. > > -Curt > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > Replication is very attractive when setting up authentication systems. I ask because of the following: --snip-- Fedora Directory Server uses the Berkley Database as it's data store. This data store is very high performance and is transacted to ensure ACID data updates. Fedora DS automatically detects if the data was not written cleanly and does a database restore at startup if necessary. Multiple databases provide a simple way of breaking down your directory data to simplify the implementation of replication and chaining in your directory service. Import into one suffix without affecting the other suffixes. FDS supports 4-Way Multi-master replication. Multi-master means the ability to write to two or more masters at the same time, with automatic conflict resolution, as opposed to just having one master at a time with hot failover. This feature provides a highly available directory service for both read and write operations. Multi-master replication can be combined with simple and cascading replication scenarios to provide a highly flexible and scalable replication environment. You can also use fractional replication to restrict the attributes that are replicated (e.g. if you don't want certain data to be present on a replica). --snip-- Jon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From wtogami at redhat.com Wed Jul 19 18:07:40 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 19 Jul 2006 14:07:40 -0400 Subject: [Fedora-infrastructure-list] Re: CVS admin request In-Reply-To: <44BD2C45.90605@hhs.nl> References: <44BD2C45.90605@hhs.nl> Message-ID: <44BE74EC.3020301@redhat.com> Hans de Goede wrote: > Hi Warren, > > Could you please create an empty devel branch for gkrellm. gkrellm is > already in CVs, but only RHL-8 and RHL-9 branches as after that it moved > to core, now its moving back and because of the exisiting branches > cvs-import.sh won't work. > > I already put this on the CVSSyncNeeded wiki-page, in the special > requests section, but special requests usually take ages to get handled. > And this is currently blocking import of 2 new packages into FE (gkrellm > and gkrellm-wifi). > > This is also discussed here: > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197967 > > Thanks & Regards, > > Hans The way the CVS system was designed, it is a huge mess to re-add a devel branch after it has been deleted. It might be easier to just blow away the entire directory and import it from scratch. I'll go ahead and do this after talking to infrastructure people. Warren Togami wtogami at redhat.com From mmcgrath at fedoraproject.org Wed Jul 19 18:09:42 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 19 Jul 2006 13:09:42 -0500 Subject: [Fedora-infrastructure-list] Re: CVS admin request In-Reply-To: <44BE74EC.3020301@redhat.com> References: <44BD2C45.90605@hhs.nl> <44BE74EC.3020301@redhat.com> Message-ID: <3237e4410607191109m44f54485o6493e6ea9eeb570c@mail.gmail.com> On 7/19/06, Warren Togami wrote: > Hans de Goede wrote: > > Hi Warren, > > > > Could you please create an empty devel branch for gkrellm. gkrellm is > > already in CVs, but only RHL-8 and RHL-9 branches as after that it moved > > to core, now its moving back and because of the exisiting branches > > cvs-import.sh won't work. > > > > I already put this on the CVSSyncNeeded wiki-page, in the special > > requests section, but special requests usually take ages to get handled. > > And this is currently blocking import of 2 new packages into FE (gkrellm > > and gkrellm-wifi). > > > > This is also discussed here: > > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197967 > > > > Thanks & Regards, > > > > Hans > > The way the CVS system was designed, it is a huge mess to re-add a devel > branch after it has been deleted. It might be easier to just blow away > the entire directory and import it from scratch. I'll go ahead and do > this after talking to infrastructure people. > > Warren Togami > wtogami at redhat.com > I'd say thats fine. I can't imagine it breaking anything. -Mike From dennis at ausil.us Wed Jul 19 18:27:26 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 19 Jul 2006 13:27:26 -0500 Subject: [Fedora-infrastructure-list] Re: CVS admin request In-Reply-To: <3237e4410607191109m44f54485o6493e6ea9eeb570c@mail.gmail.com> References: <44BD2C45.90605@hhs.nl> <44BE74EC.3020301@redhat.com> <3237e4410607191109m44f54485o6493e6ea9eeb570c@mail.gmail.com> Message-ID: <200607191327.26244.dennis@ausil.us> On Wednesday 19 July 2006 13:09, Mike McGrath wrote: > On 7/19/06, Warren Togami wrote: > > > > The way the CVS system was designed, it is a huge mess to re-add a devel > > branch after it has been deleted. It might be easier to just blow away > > the entire directory and import it from scratch. I'll go ahead and do > > this after talking to infrastructure people. > > > > Warren Togami > > wtogami at redhat.com > > I'd say thats fine. I can't imagine it breaking anything. > > -Mike +1 also Dennis From wtogami at redhat.com Wed Jul 19 18:29:38 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 19 Jul 2006 14:29:38 -0400 Subject: [Fedora-infrastructure-list] Re: CVS admin request In-Reply-To: <3237e4410607191109m44f54485o6493e6ea9eeb570c@mail.gmail.com> References: <44BD2C45.90605@hhs.nl> <44BE74EC.3020301@redhat.com> <3237e4410607191109m44f54485o6493e6ea9eeb570c@mail.gmail.com> Message-ID: <44BE7A12.2080004@redhat.com> Mike McGrath wrote: > On 7/19/06, Warren Togami wrote: >> Hans de Goede wrote: >> > Hi Warren, >> > >> > Could you please create an empty devel branch for gkrellm. gkrellm is >> > already in CVs, but only RHL-8 and RHL-9 branches as after that it >> moved >> > to core, now its moving back and because of the exisiting branches >> > cvs-import.sh won't work. >> > >> > I already put this on the CVSSyncNeeded wiki-page, in the special >> > requests section, but special requests usually take ages to get >> handled. >> > And this is currently blocking import of 2 new packages into FE >> (gkrellm >> > and gkrellm-wifi). >> > >> > This is also discussed here: >> > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded >> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197967 >> > >> > Thanks & Regards, >> > >> > Hans >> >> The way the CVS system was designed, it is a huge mess to re-add a devel >> branch after it has been deleted. It might be easier to just blow away >> the entire directory and import it from scratch. I'll go ahead and do >> this after talking to infrastructure people. >> >> Warren Togami >> wtogami at redhat.com >> > > I'd say thats fine. I can't imagine it breaking anything. > > -Mike OK, you should be able to import it fresh now. Warren From mmcgrath at fedoraproject.org Wed Jul 19 18:40:47 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 19 Jul 2006 13:40:47 -0500 Subject: [Fedora-infrastructure-list] Officers Message-ID: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> The infrastructure group is getting bigger and I think its time that we start examining whether we would benefit from officers in the admin group. I don't want to create a high barrier to getting involved with the infrastructure project but at the same time right now everyone is trying to do everything and as a result sometimes stuff isn't getting done. (ppc1 has over 200 updates that need to be done). If we got more fine grained with security we could allow people access to systems without giving them full root on all the systems. For example it would be very easy to create a nagios group so multiple people could access and restart nagios without giving them root to the box and other boxes. Some apps don't even need shell access to admin, otrs and mailman comes to mind immediately. I could see a use for the following officers: ticketmaster updates dba noc (nagios/cacti) accounting VCS external (someone who can coordinate with the other non-infrastructure teams on things) I'm thinking that officers should be limited to people that have been a part of the team for months and have a good record in the true sense of a meritocracy. I'm also under the opinion that some systems could have multiple officers. (for example I could very easily see Warren and myself as contacts for VCS). Anyway I'm throwing it out there. What do you guys think? Am I trying to solve a problem that doesn't exist? -Mike From nils at breun.nl Wed Jul 19 18:54:10 2006 From: nils at breun.nl (Nils Breunese) Date: Wed, 19 Jul 2006 20:54:10 +0200 Subject: [Fedora-infrastructure-list] Officers In-Reply-To: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> References: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> Message-ID: Mike McGrath wrote: > I could see a use for the following officers: > ticketmaster > updates > dba > noc (nagios/cacti) > accounting > VCS > external (someone who can coordinate with the other non-infrastructure > teams on things) > > I'm thinking that officers should be limited to people that have been > a part of the team for months and have a good record in the true sense > of a meritocracy. I'm also under the opinion that some systems could > have multiple officers. (for example I could very easily see Warren > and myself as contacts for VCS). > > Anyway I'm throwing it out there. What do you guys think? Am I > trying to solve a problem that doesn't exist? I'm new here, but it sounds like a pretty good idea. Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From damian.myerscough at gmail.com Wed Jul 19 18:58:12 2006 From: damian.myerscough at gmail.com (Damian Myerscough) Date: Wed, 19 Jul 2006 19:58:12 +0100 Subject: [Fedora-infrastructure-list] Officers In-Reply-To: References: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> Message-ID: <8c9e56490607191158t63f9ffa8v472e172f2ea662b5@mail.gmail.com> Yea Mike Sounds good, most of the security updates I have been doing via RHN as its quick and easy and I am alerted via email when a security update is needed :) Currently all the systems are up to date accept proxy2.fedora.phx.redhat.com. Someone has set up2date not to apply the kernel patch. On 7/19/06, Nils Breunese wrote: > Mike McGrath wrote: > > > I could see a use for the following officers: > > ticketmaster > > updates > > dba > > noc (nagios/cacti) > > accounting > > VCS > > external (someone who can coordinate with the other non-infrastructure > > teams on things) > > > > I'm thinking that officers should be limited to people that have been > > a part of the team for months and have a good record in the true sense > > of a meritocracy. I'm also under the opinion that some systems could > > have multiple officers. (for example I could very easily see Warren > > and myself as contacts for VCS). > > > > Anyway I'm throwing it out there. What do you guys think? Am I > > trying to solve a problem that doesn't exist? > > I'm new here, but it sounds like a pretty good idea. > > Nils Breunese. > > > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > > From neuro at well.com Wed Jul 19 19:04:43 2006 From: neuro at well.com (William Anderson) Date: Wed, 19 Jul 2006 20:04:43 +0100 Subject: [Fedora-infrastructure-list] Officers In-Reply-To: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> References: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> Message-ID: <44BE824B.1010001@well.com> Mike McGrath wrote: > The infrastructure group is getting bigger and I think its time that > we start examining whether we would benefit from officers in the admin > group. I don't want to create a high barrier to getting involved with > the infrastructure project but at the same time right now everyone is > trying to do everything and as a result sometimes stuff isn't getting > done. (ppc1 has over 200 updates that need to be done). Sounds like a plan; also, I've just joined the list. Hello, everybody! -- _ __/| William Anderson | Tim: Your cheese game is strong. \`O_o' neuro at well dot com | Zane: My cheese game. It's all about the =(_ _)= http://neuro.me.uk/ | cheese platter. U - Thhbt! GPG 0xFA5F1100 | -- Tim Westwood, Zane Lowe, R1, Dec 2005 From michael at knox.net.nz Wed Jul 19 19:54:47 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 20 Jul 2006 07:54:47 +1200 Subject: [Fedora-infrastructure-list] Officers In-Reply-To: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> References: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> Message-ID: <44BE8E07.4050004@knox.net.nz> Mike McGrath wrote: > The infrastructure group is getting bigger and I think its time that > we start examining whether we would benefit from officers in the admin > group. I don't want to create a high barrier to getting involved with > the infrastructure project but at the same time right now everyone is > trying to do everything and as a result sometimes stuff isn't getting > done. (ppc1 has over 200 updates that need to be done). > > If we got more fine grained with security we could allow people access > to systems without giving them full root on all the systems. For > example it would be very easy to create a nagios group so multiple > people could access and restart nagios without giving them root to the > box and other boxes. Some apps don't even need shell access to admin, > otrs and mailman comes to mind immediately. > > I could see a use for the following officers: > ticketmaster > updates > dba > noc (nagios/cacti) > accounting > VCS > external (someone who can coordinate with the other non-infrastructure > teams on things) > > I'm thinking that officers should be limited to people that have been > a part of the team for months and have a good record in the true sense > of a meritocracy. I'm also under the opinion that some systems could > have multiple officers. (for example I could very easily see Warren > and myself as contacts for VCS). > > Anyway I'm throwing it out there. What do you guys think? Am I > trying to solve a problem that doesn't exist? > Hello Mike. I think this is a good idea. Breaking down infrastructure into focus groups would allow new comers to find a home easier, rather then hoovering on the out side watching and waiting :) Michael From ryan.ordway at oregonstate.edu Wed Jul 19 19:59:24 2006 From: ryan.ordway at oregonstate.edu (Ryan Ordway) Date: Wed, 19 Jul 2006 12:59:24 -0700 Subject: [Fedora-infrastructure-list] Officers In-Reply-To: <44BE8E07.4050004@knox.net.nz> References: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> <44BE8E07.4050004@knox.net.nz> Message-ID: <1153339165.25736.16.camel@everclear.library.oregonstate.edu> On Thu, 2006-07-20 at 07:54 +1200, Michael J. Knox wrote: > Mike McGrath wrote: > > > > Anyway I'm throwing it out there. What do you guys think? Am I > > trying to solve a problem that doesn't exist? > > I think this is a good idea. Breaking down infrastructure into focus > groups would allow new comers to find a home easier, rather then > hoovering on the out side watching and waiting :) And give a clear list of point-persons for each particular group. I think as long as communication continues to happen globally instead of breaking down solely into inter-group, I think it's a great idea. -- Ryan Ordway Unix Systems Administrator E-mail: ryan.ordway at oregonstate.edu Oregon State University Libraries rordway at library.oregonstate.edu 121 The Valley Library Corvallis, OR 97331 From sopwith at redhat.com Wed Jul 19 21:27:58 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 19 Jul 2006 17:27:58 -0400 Subject: [Fedora-infrastructure-list] bastion upgrade done... Message-ID: <7FE0666A-2A97-4622-958D-6AAA36799232@redhat.com> Please let me know if anything is wrong with e-mail or ssh'ing in... Best, -- Elliot From linux at elfshadow.net Wed Jul 19 23:38:09 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Wed, 19 Jul 2006 19:38:09 -0400 Subject: [Fedora-infrastructure-list] Officers In-Reply-To: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> References: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> Message-ID: <44BEC261.3070806@elfshadow.net> Mike McGrath wrote: > Anyway I'm throwing it out there. What do you guys think? Am I > trying to solve a problem that doesn't exist? I think it is certainly an idea worth considering. Sometimes we get caught up rolling out new stuff and putting new systems/applications in place that the more mundane, though important, tasks get left behind. Having focus groups of people that specialize in certain areas can help make sure we don't let those tasks slip. I think we should certainly keep the global communication going, though I don't see that as being an issue - the mailing lists help facilitate communication amongst the group. As long as discussions take place on the list then people can stay involved. I would also hope that by moving towards an office/focus group model that people not be too pigeon holed into their focus area. It would be more of a your primary responsibility is to make sure x, x and x happen (or is happening) and then are welcome to jump in on another project if time permits. -Jeffrey From jason at 3dogs.us Thu Jul 20 12:43:52 2006 From: jason at 3dogs.us (Jason Hartley) Date: Thu, 20 Jul 2006 08:43:52 -0400 (EDT) Subject: [Fedora-infrastructure-list] Will miss today's meeting Message-ID: <59899.192.168.0.10.1153399432.squirrel@www.3dogs.us> FYI- I will miss today's meeting and will have to catch up later. Regards, Jason Hartley From mspevack at redhat.com Fri Jul 14 15:57:15 2006 From: mspevack at redhat.com (Max Spevack) Date: Fri, 14 Jul 2006 11:57:15 -0400 (EDT) Subject: [Fedora-infrastructure-list] debian's problems Message-ID: I'm sure you guys are all following the stories on slashdot about the problems that Debian is having due to password insecurity that led to a compromised account. What sort of safeguards do we have? Is this a good time to thnk about how we can improve our security *before* there is a problem rather than after? Do we have some sort of general plan for what to do if one of our public boxes is compromised, so that we don't act randomly, or forget things in the panic of the moment? --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From skvidal at linux.duke.edu Thu Jul 20 19:59:53 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 20 Jul 2006 15:59:53 -0400 Subject: [Fedora-infrastructure-list] debian's problems In-Reply-To: References: Message-ID: <1153425593.1936.33.camel@cutter> On Fri, 2006-07-14 at 11:57 -0400, Max Spevack wrote: > I'm sure you guys are all following the stories on slashdot about the > problems that Debian is having due to password insecurity that led to a > compromised account. > > What sort of safeguards do we have? Is this a good time to thnk about how > we can improve our security *before* there is a problem rather than after? > > Do we have some sort of general plan for what to do if one of our public > boxes is compromised, so that we don't act randomly, or forget things in > the panic of the moment? I dunno if you've been on this list before today but we've been talking about that subject quite a bit. We've already covered the idea of relying SOLELY on ssh keys for shell-level access to systems and the possibility of requiring client ssl keys for web-access. Mike brought up the idea of subdividing things a bit tighter in terms of who can login to what systems so we don't have too much 'global' access. yes, we're moving on all of these things. -sv From damian.myerscough at gmail.com Thu Jul 20 20:47:17 2006 From: damian.myerscough at gmail.com (Damian Myerscough) Date: Thu, 20 Jul 2006 21:47:17 +0100 Subject: [Fedora-infrastructure-list] Hardware Tracker Message-ID: <8c9e56490607201347t2bb2b251ib37ac6cde2623b1e@mail.gmail.com> Hey all, I have attached an XML file that is produced by the hardware tracker, the problem I have encountered is asking the user if the device works. I am not sure how to go about this? Should I just filter out the info.product field which, would give: USB Hub Interface USB Raw Device Access UHCI Host Controller 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 This information from a new user to Linux would be hard for them to understand if its working correctly. Any suggestions are most welcome. -------------- next part -------------- A non-text attachment was scrubbed... Name: devs.xml Type: text/xml Size: 122743 bytes Desc: not available URL: From sopwith at redhat.com Thu Jul 20 21:55:15 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 20 Jul 2006 17:55:15 -0400 Subject: [Fedora-infrastructure-list] Hardware Tracker In-Reply-To: <8c9e56490607201347t2bb2b251ib37ac6cde2623b1e@mail.gmail.com> References: <8c9e56490607201347t2bb2b251ib37ac6cde2623b1e@mail.gmail.com> Message-ID: The approach I would suggest is to have an icon on the user's desktop (and a button in firstboot, or wherever) that says: REPORT A PROBLEM WITH MY HARDWARE The first step in this would be to select the user's hardware from a menu showing the info.product fields (perhaps grouped by the info.category field). This wouldn't be the same as filing a bugzilla report - the main idea is a sort of a poll to let FC hackers know which hardware needs the most attention at the moment. Users will not always know that a device is not working when they send in their initial hardware report, so we need to be able to let them send in a "I have this hardware" report separately from the "this hardware is not working for me" report. Best, -- Elliot On Jul 20, 2006, at 16:47, Damian Myerscough wrote: > Hey all, > > I have attached an XML file that is produced by the hardware tracker, > the problem I have > encountered is asking the user if the device works. I am not sure how > to go about this? > Should I just filter out the info.product field which, would give: > > USB Hub Interface > USB Raw Device Access > UHCI Host Controller > 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller > #1 > > This information from a new user to Linux would be hard for them to > understand if its working correctly. Any suggestions are most welcome. > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From sopwith at redhat.com Thu Jul 20 22:02:51 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 20 Jul 2006 18:02:51 -0400 Subject: [Fedora-infrastructure-list] Officers In-Reply-To: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> References: <3237e4410607191140m74d8e79aq93c5d75a9f0c9337@mail.gmail.com> Message-ID: <5ECC0E66-AAA1-425D-BF4C-03837C53390A@redhat.com> Sorry, we went so over in today's meeting that I totally forgot about this. I think having a list of roles with names next to them would be a good step. I personally don't like the word "officers" because of the connotations of bureaucracy that it has for me, but the idea itself is sound, and I liked Jeffrey's comments about keeping it real and letting people do other things as they felt motivated. It's also more important to avoid locking people into particular roles because we are basically a bunch of volunteers, and getting tired of doing the same thing over and over is a bigger concern with volunteers than with employees. Best, -- Elliot On Jul 19, 2006, at 14:40, Mike McGrath wrote: > The infrastructure group is getting bigger and I think its time that > we start examining whether we would benefit from officers in the admin > group. I don't want to create a high barrier to getting involved with > the infrastructure project but at the same time right now everyone is > trying to do everything and as a result sometimes stuff isn't getting > done. (ppc1 has over 200 updates that need to be done). > > If we got more fine grained with security we could allow people access > to systems without giving them full root on all the systems. For > example it would be very easy to create a nagios group so multiple > people could access and restart nagios without giving them root to the > box and other boxes. Some apps don't even need shell access to admin, > otrs and mailman comes to mind immediately. > > I could see a use for the following officers: > ticketmaster > updates > dba > noc (nagios/cacti) > accounting > VCS > external (someone who can coordinate with the other non-infrastructure > teams on things) > > I'm thinking that officers should be limited to people that have been > a part of the team for months and have a good record in the true sense > of a meritocracy. I'm also under the opinion that some systems could > have multiple officers. (for example I could very easily see Warren > and myself as contacts for VCS). From sopwith at redhat.com Thu Jul 20 22:07:31 2006 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 20 Jul 2006 18:07:31 -0400 Subject: [Fedora-infrastructure-list] Log from today's meeting - 2006-07-20 Message-ID: <20060720220731.GA3150@ostrich-deluxe.devel.redhat.com> Here it is. Thanks for everyone who made it out! -- Elliot -------------- next part -------------- Jul 20 16:00:52 It looks like there are a good bunch of us here, so let's get started. Jul 20 16:00:56 skvidal: yeah, i just got on the list yesterday :-P Jul 20 16:01:03 gregdek: I think the last one we had continued the words 'retarded half wit' Jul 20 16:01:05 skvidal: i decided that I needed more email :-) Jul 20 16:01:25 mspevack: you should always read ALL the recent archives before joining a list, of course ;) Jul 20 16:01:38 * mspevack hangs his head in shame Jul 20 16:01:46 :) Jul 20 16:01:48 the funny thing is I wrote that email last week Jul 20 16:01:55 and it didn't get through moderation until today, it looks like Jul 20 16:02:02 it's timestamped the 14th Jul 20 16:02:04 Yea, because you weren't a member when you wrote it. Jul 20 16:02:12 I just noticed it today when I was going through the queue. Jul 20 16:02:27 *nod* Jul 20 16:02:33 OK, let's get cracking on this TODO list and see where we are. Jul 20 16:02:36 For the new people: http://fedoraproject.org/wiki/Infrastructure/Schedule <- Thats the basic ajenda for the meetings. Jul 20 16:03:30 ongoing stuff - I know rordway is working through tons of tickets (thanks!), and I think xdamox was applying updates recently, so are we good there? Jul 20 16:03:49 yea Jul 20 16:03:59 Cool Jul 20 16:04:00 yep Jul 20 16:04:03 I apply all updates from RHN when I am notifyed Jul 20 16:04:17 xdamox: Did you fix proxy2 to get kernel updates? Jul 20 16:04:30 Not yet ill do it now Jul 20 16:04:34 ok Jul 20 16:04:48 my Inet has been soooo slow today :( Jul 20 16:05:17 doh, that's no good. Type more slowly :) Jul 20 16:05:31 OK, while he does that, the first task - dgilmore & skvidal on the minimal buildroots. Jul 20 16:05:41 Sopwith: we need to upgrade the boxes Jul 20 16:05:50 did you guys decide on FC5? Jul 20 16:05:52 the builders are all over the map as to what they have installed Jul 20 16:06:05 I think FC5 would be reasonably sensible but I'm open to rhel4 on them, as well. Jul 20 16:06:09 skvidal: OK. Do you have everything you need to do that? Jul 20 16:06:32 Sopwith: I need time :) - it might be best if dgilmore does it Jul 20 16:06:46 dgilmore: Do you have everything you need to do the upgrades? Jul 20 16:06:57 the only thing we have to keep in mind is restoration of the ssl keys for plague AFTER the upgrades are done Jul 20 16:07:18 Should those keys be stored in fedora-config cvs? Jul 20 16:07:27 umm - how secure is that? Jul 20 16:07:31 they're ssl keys Jul 20 16:07:40 I'm a little worried about them being visible anywhere, of course Jul 20 16:08:00 It's a private CVS repo on lockbox that relatively few people have access to. Jul 20 16:08:12 okay Jul 20 16:08:41 I've had the cvs & admin ssl keys in there for a while, so this would be consistent. Jul 20 16:08:51 that sounds fine to me, then. Jul 20 16:09:39 dgilmore: ping me on whatever you need, if you're interested in handling this Jul 20 16:10:16 Sopwith: if you want to leave that one assigned to both of us that'd be fine Jul 20 16:10:19 back Jul 20 16:10:20 OK, will do Jul 20 16:10:34 pasqual? Jul 20 16:10:38 hello Jul 20 16:10:44 * iWolf wanders in from team meeting Jul 20 16:10:51 pasqual: So I remember seeing an e-mail from you this past week - thank you! Jul 20 16:11:04 Sopwith: thanks Jul 20 16:11:22 pasqual: Am I correct in thinking that the next step is to get that page posted as the admin.fedoraproject.org homepage? Jul 20 16:11:26 Sopwith: I have done the draft, now there are some questions Jul 20 16:11:30 * mmcgrath will be in and out for a bit, kitchen sink is leaking. Jul 20 16:11:34 OK, questions Jul 20 16:11:51 Sopwith: yes, correct, that was one questions Jul 20 16:11:58 ahah ok Jul 20 16:11:59 ok Jul 20 16:12:23 I have seen that you use a cvs Jul 20 16:12:34 for keeping all the web content Jul 20 16:12:43 sold this page go to the cvs? Jul 20 16:12:55 <-- daMaestro has quit (Nick collision from services.) Jul 20 16:13:09 --> daMaestro (n=jon at fedora/damaestro) has joined #fedora-admin Jul 20 16:13:15 There is more than one cvs repository. cvs.fedoraproject.org:/cvs/fedora module 'web' is the content for fedora.redhat.com, but that's not the right place. Jul 20 16:13:27 I think that I need some kind of privilege to have write access to it Jul 20 16:13:38 ok Jul 20 16:13:41 Maybe we need to set up an entirely new cvs repo for the content on admin.fedoraproject.org - currently there isn't much of one... Jul 20 16:13:52 but tha's the fedoraproject main page Jul 20 16:14:05 mus this go to the same place? Jul 20 16:14:44 Right - we don't want this page of yours to go up in the same place, so I think it would work better to have a separate CVS repository just for admin.fedoraproject.org and other small/secondary Fedora web sites Jul 20 16:14:49 that's and option Jul 20 16:14:55 we *could* just use the wiki and have admin.fedoraproject.org/ proxypass to it. Jul 20 16:15:23 Hmm, I dunno. Jul 20 16:15:43 * Sopwith wishes for the plone deployment to be finished. Jul 20 16:15:58 I think thats still quite a ways out. Jul 20 16:16:33 i'd like to get in the mix of getting plone deployed Jul 20 16:16:33 Sopwith: so do I Jul 20 16:16:43 daMaestro: talk to the website folks Jul 20 16:16:48 damaestro: nman64 is the guy to talk to Jul 20 16:16:55 #fedora-websites Jul 20 16:17:06 thanks.. i will Jul 20 16:17:09 so what is the deal with ldap? Jul 20 16:17:11 So for now, we could use the wiki and proxypass it, or we could just set up a 'other-web' module in /cvs/fedora and start pushing that out as the main content for admin.fedoraproject.org, webtest.fedoraproject.org, and others. Jul 20 16:17:52 athat second optios can do the job Jul 20 16:17:52 well ..... Jul 20 16:17:52 I like the second Jul 20 16:17:52 what do you think? Jul 20 16:17:55 pasqual: You're going to be doing the actual work, so, how do you want it to be done? :) Jul 20 16:18:08 OK... Jul 20 16:18:52 pasqual: I'll work on it later and e-mail you with info. Jul 20 16:18:58 s/deal with/status of/ Jul 20 16:19:24 damaestro: Good question to talk about, but first there are a few other items. Jul 20 16:19:28 daMaestro: we'll get there, we're not that far on the schedule Jul 20 16:19:35 I need editgroup privilege to put the web in the wiki, I think? Jul 20 16:19:35 Sopwith: the wiki is ok for me Jul 20 16:19:35 Sopwith, kernels updated on proxy2 Jul 20 16:19:35 Sopwith: the last question was where is nagios Jul 20 16:19:35 Has db1 been reinstalled? Jul 20 16:19:38 ok.. sorry.. i will keep quite until then. Jul 20 16:19:40 xdamox: Cool Jul 20 16:19:43 quiet* Jul 20 16:19:48 Sopwith: I have not found information for them in the wiki Jul 20 16:19:50 qasqual: https://admin.fedoraproject.org/nagios/ Jul 20 16:20:04 thanks mmcrath Jul 20 16:20:15 damaestro: Schedule page is at http://fedoraproject.org/wiki/Infrastructure/Schedule if you want to follow along Jul 20 16:20:22 thank you Jul 20 16:20:23 xDamox: kernel update, rebooted too? Jul 20 16:20:40 I aint rebooted it ill do it now tho Jul 20 16:20:46 xDamox: db1 is on hold till we get the second DB server. Jul 20 16:21:05 ok, just updated it anyways Jul 20 16:21:09 xDamox: Then we will sort of swing server it and end up with replication/clustered dbs by the end. Jul 20 16:21:35 :) cool Jul 20 16:21:37 iwolf: mdomsch said he got all the specs from mmcgrath and is just waiting on final budget approval. mspevack is going to be receiving the machine and will find someone to get it set up and shipped to PHX Jul 20 16:21:48 woohoo Jul 20 16:21:55 Sopwith: Sounds great! :) Jul 20 16:21:56 I don't know when Stacy is going to PHX next, and when the Dell box will arrive, so we could be waiting a while yet. Jul 20 16:22:10 * xDamox Rebooting proxy2 Jul 20 16:22:15 Sopwith: sorry got called out of office. I will need whatever access is needed to do the reinstalls Jul 20 16:22:51 Fortunately, with bastion upgraded, I think the only upgrades left are the build systems (dgilmore), and db1. Jul 20 16:23:27 Sopwith: im happy to do the builders upgrades Jul 20 16:23:38 dgilmore: OK, cool. Jul 20 16:24:11 dgilmore: I'll assume skvidal is ok with adding you to the sysadmin-build group - that should give you all the access you need except for the passwords for the power switches and consoles. Jul 20 16:24:29 Sopwith: yes, I'm cool w/that Jul 20 16:25:00 dgilmore: The powerpc machines are kind of funky to work with, we'll have to talk later about the details. Jul 20 16:25:12 Sopwith: ok Jul 20 16:25:25 dgilmore: ping me after and I'll get you all the details :) Jul 20 16:25:27 dgilmore: you're 'ausil' right? Jul 20 16:25:30 are the plague and mock configs kept in cvs somewhere? Jul 20 16:25:35 skvidal: uep thats me Jul 20 16:25:41 yep even Jul 20 16:25:47 dgilmore: no they're not in cvs that I know of Jul 20 16:25:48 proxy2 is back up Jul 20 16:25:58 best making a tarball of /etc on those boxes before the reinstall Jul 20 16:26:01 dgilmore: They should be in fedora-config (if they're not, they can be put there) Jul 20 16:26:25 They and a lot of configs have gotten out of sync as of late with whats in fedora-config Jul 20 16:26:54 good time to make sure tehre right Jul 20 16:27:04 --> abompard (n=gauret at vol75-3-82-66-216-165.fbx.proxad.net) has joined #fedora-admin Jul 20 16:27:09 mmcgrath: indeed Jul 20 16:27:09 bleah :-\ It's a key recovery & tracking mechanism. dgilmore will probably find all the problems when he reinstalls :) Jul 20 16:27:10 im assuming it would be good to put the old ssh keys back on builders as well Jul 20 16:27:23 dgilmore: not a biggie, but it can't hurt Jul 20 16:27:26 I'm late, sorry Jul 20 16:27:52 dgilmore: you've been added to sysadmin-build Jul 20 16:27:53 abompard: Heya, welcome Jul 20 16:28:01 lmacken! tell us about firewalls please! Jul 20 16:28:01 skvidal: :) thanks Jul 20 16:28:16 k Jul 20 16:28:20 I wrote a Makefile and an RPM for pyroman. Also, I rewrote a lot of the configuration and integrated it into our fedora-config module, which I've currently deployed to proxy.live. Jul 20 16:28:28 I also tossed up some info and deployment status on InfrastructurePrivate/Firewall. Jul 20 16:28:33 At the moment, only proxy4 is armed. I'm going to be doing a bunch more testing/configuration in the next day or so, then deploy it to the rest of our proxy servers. Jul 20 16:28:41 Any preference as to which group of systems I start with after I'm done with proxy[1-4] ? Jul 20 16:29:10 not from me... Jul 20 16:29:22 ok.. well, what isn't getting rebuilt any time soon ? :) Jul 20 16:29:27 There are two app servers, so you have room to mess up on one of them if you want to try them next. Jul 20 16:29:38 the app servers would be a good next start. Jul 20 16:29:40 ok, cool.. i'll hit up app[1-2] next :) Jul 20 16:30:10 Nice work. Jul 20 16:30:26 Hey, your name is on the next item as well - TG packaging. Jul 20 16:30:42 on to TurboGears.. Jul 20 16:30:44 ConfigObj, Paste, and SimpleJSON made it through the extras review process so far. I'm still waiting on PasteScript and PasteDeploy. Once completed, I'll need to bump sqlobject and formencode, and pull Turbo{Json,Cheetah,Kid} out of the TurboGears package. Jul 20 16:30:48 I'd say another week or so until we have 0.9a6 in devel. Jul 20 16:31:09 lmacken: I'll review the rest Jul 20 16:31:24 abompard: thanks :) Jul 20 16:31:33 that is, if nobody beats me to it :) Jul 20 16:31:41 i think someone might have, but i'm not sure Jul 20 16:31:51 i've been getting a constant stream of review emails.. hard to keep track of Jul 20 16:32:08 yeah, that's only sign of FE's good health :) Jul 20 16:32:25 very true Jul 20 16:32:42 Sounds good to me. Jul 20 16:33:26 Next item is documentation Jul 20 16:34:50 ::crickets:: Jul 20 16:35:02 I'm going to be taking a leave of absence starting in a week and a half and not being around very much. Jul 20 16:35:05 No is a very good time to start asking me to document things you all need to keep things running. Jul 20 16:35:07 err now Jul 20 16:35:22 hah Jul 20 16:35:32 My biggest issue is still access from time to time. Jul 20 16:35:56 I need to get a network diagram together at the very least and stick it on the wiki Jul 20 16:36:23 Does the systems list not have that info? Jul 20 16:36:26 I still fight that silly console on a semi regular basis. Since that works for mmcgrath these days, probably more an issue on my end. Jul 20 16:36:37 Actually it is pretty close. Jul 20 16:38:05 OK, well, this week is "pick sopwith's brain week" if you feel so inclined. Jul 20 16:38:09 Backups! Jul 20 16:38:15 backuppc package? Jul 20 16:38:30 its up, dgilmore's testing it. We've got a couple of changes to make. Jul 20 16:39:19 right now we're just thinking about adding backuppc's public key under root on the boxes with a host restriction of the backup machine. Jul 20 16:39:39 ok Jul 20 16:39:44 Once its up all backups will be automated and all restores can be done via the web-interface. Jul 20 16:40:19 Sounds convenient & dangerous :) Jul 20 16:40:25 So is the backuppc package done, or still under review? Jul 20 16:40:35 lil bit. still under review but close. Jul 20 16:41:22 OK, so packaging is well along, and you've already gotten into thinking about deployment, cool. Jul 20 16:41:43 as for the free servers, we've already gone over that. I'll move it to done. Jul 20 16:41:51 actually I'll update the status Jul 20 16:41:56 don't do it just yet Jul 20 16:42:03 * Sopwith is editing the page with all these changes mentioned. Jul 20 16:42:18 Max will be getting the servers so he will be the person who has the next update for that item. Jul 20 16:42:37 haahaahha oops Jul 20 16:42:38 --> daMaestro|isBack (n=jon at fedora/damaestro) has joined #fedora-admin Jul 20 16:42:42 too late. just overwrite mine. Jul 20 16:42:48 Sopwith: works4me Jul 20 16:43:01 rordway: anything you want to say about metrics? Jul 20 16:43:04 Metrics are cool? :) Jul 20 16:43:26 It's OK if you want to just punt on that for now - I know you've gotten involved with the ticketing system a fair bit. Jul 20 16:43:45 Let's just keep the status page updated so others know what needs doing and by who. Jul 20 16:43:47 Sopwith: yeah, I think for now I'll pass Jul 20 16:44:08 I might be able to do some data gathering scripts when I get time Jul 20 16:44:21 OK Jul 20 16:44:25 I noticed cacti was up though Jul 20 16:44:31 is there a list of data sources we want to be grabbing? Jul 20 16:44:36 That is a cool thing, even if I am a few weeks behind the curve! :) Jul 20 16:44:39 Yeah, thats just waiting on further net-snmp installs and proper firewall configs. Jul 20 16:44:47 rordway: yea, there's a list in the fedora-metrics module Jul 20 16:44:59 rordway: fedora-metrics/fedora-metrics.txt Jul 20 16:45:15 k, will take a look Jul 20 16:45:43 Sopwith: oh yeah, I can take a stab at some of those Jul 20 16:45:49 might be a few weeks though Jul 20 16:45:56 Cool, NP Jul 20 16:46:30 jcmoore: Were you by chance looking for something to hack on while you wait for the new db server to show up? :) Jul 20 16:47:11 Figured it wouldn't hurt to ask :) Jul 20 16:47:37 skvidal: Is there anything we need to know about the overall status of your very cool mirrors.fedoraproject.org? How much more is there to be done? Jul 20 16:47:47 Sopwith: who would I talk to about the various data sources listed? just send something out on f-i-l? Jul 20 16:47:56 I need to check the configs into config-cvs for the mirror they're on Jul 20 16:48:01 but afaict it's running and done Jul 20 16:48:01 dammit go to shoot, everyone I have jsut send an email on the mailling list about the hardware tracker please take a look and reply Jul 20 16:48:14 I fixed a bunch of bugs for people last week and then it appears to be doing the right thing Jul 20 16:48:15 with suggestions if you have any Jul 20 16:48:19 xdamox: Cool, thanks! Jul 20 16:48:24 Sopwith: maybe, depends on what it entails :) Jul 20 16:48:26 xdamox: See you later. Jul 20 16:48:31 c ya Jul 20 16:48:40 rordway: I can tell you where to get the data for all of those. Jul 20 16:49:07 if there's anything else that needs doing - let me know Jul 20 16:49:08 Sopwith: cool, you can e-mail me off-list after the meeting if you want Jul 20 16:49:18 I sent the configs to f13 for use in fedora-release Jul 20 16:49:26 so I think it is ready to roll. Jul 20 16:49:35 rordway: OK, and I'll cc jcmoore so he knows what is going on at least :) Jul 20 16:49:37 unless someone wants to put the info on more than one server for redundancy Jul 20 16:49:43 ok, cool Jul 20 16:50:21 skvidal: Cool, it'll be neat to see it in use for the next test release. Jul 20 16:50:23 do we need a mirror list of mirror lists? :-) Jul 20 16:50:32 nah, one is enough Jul 20 16:50:43 skvidal: i have a domainname i can donate if you want it fedoramiiror.net Jul 20 16:50:50 actually I believe the code does the right thing Jul 20 16:50:56 But if you want redundancy, we can have the PHX web servers serve the same stuff. Jul 20 16:50:56 skvidal: thats fedoramirror.net Jul 20 16:50:56 so if the upstream mirrorlist goes away Jul 20 16:51:12 it won't overwrite the current files with nothing Jul 20 16:51:18 Sopwith: I thought they couldn't call out? Jul 20 16:51:29 I need to get ahold of stacy to find out how to get to www.redhat.com from inside the phx colo. Jul 20 16:51:36 * mmcgrath emails now... Jul 20 16:52:00 skvidal: They can call out if we set up the on-host firewalls correctly. Jul 20 16:52:08 skvidal: Talk to lmacken about that :) Jul 20 16:52:56 OK, the only other item I think we have time for (or updates to give for) is the account system. Jul 20 16:53:05 lyz, are ya here? Jul 20 16:53:16 Sopwith: the problem was with www.redhat.com and how it resolved. Jul 20 16:53:16 yup Jul 20 16:53:31 I even disabled iptables and got the same issues. I suppose I could setup a hosts file. Jul 20 16:54:04 mmcgrath: Hmm, that makes sense. Do we need to be able to retrieve www.redhat.com content from the proxy systems? Jul 20 16:54:26 lyz: So if you had to summarize the LDAP back-and-forth from the past week, what would you say? Jul 20 16:54:38 that we are inconclusive Jul 20 16:54:43 lol Jul 20 16:55:16 everyone has a differing opinion Jul 20 16:55:41 :-) Jul 20 16:55:42 actually it needs fedora.redhat.com Jul 20 16:55:43 Score Card... http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/LDAPvsSQL :) Jul 20 16:56:04 it sounds reasonable to me to go with an LDAP interface with a SQL back-end Jul 20 16:56:06 lyz: Are you willing to start on the actual coding for the account system? Jul 20 16:56:24 I'm willing to write some code, but need some direction Jul 20 16:56:35 both resolve to the same IP though. Jul 20 16:56:56 I've been looking at the current SQL schema Jul 20 16:57:25 Cool. Does it mostly make sense? Jul 20 16:57:40 yeah, it's pretty simple. There's not much in there Jul 20 16:58:15 I know for v2, we'd at least need to add a table to map accounts to emails, and also rework the group membership stuff so that one group can be a member of another group. Jul 20 16:58:33 --- [lyz] (n=lyz at dsl081-149-006.chi1.dsl.speakeasy.net) : Tom Jul 20 16:58:33 --- [lyz] #fedora-admin Jul 20 16:58:33 --- [lyz] irc.freenode.net :http://freenode.net/ Jul 20 16:58:33 --- [lyz] is identified to services Jul 20 16:58:33 --- [lyz] End of WHOIS list. Jul 20 16:58:45 I will work on getting that done Jul 20 16:59:27 lyz: Ultimately, my advice is to make a decision on LDAP vs SQL (even if it's the wrong one) because you're the one that's actually doing something about it. Jul 20 16:59:30 I'd like to help, will you work on a public repo ? Jul 20 16:59:53 If you're wrong about the backend, you'll find out eventually and fix it. Jul 20 17:00:16 ok, at this point I don't see a benefit to LDAP Jul 20 17:00:39 lyz: uhhhh, Jul 20 17:00:40 we can start with SQL, so we don't need to write the LDAP schema right now Jul 20 17:01:26 Here's my hangup. It seems like all the people that don't get LDAP have just never used it. Jul 20 17:02:05 it's true that the whole problem of groups containing groups would be easily solved with LDAP Jul 20 17:02:08 We wouldn't have to write the LDAP schema, the default schema supports most of what we want to do. Jul 20 17:02:58 mmcgrath: I want to argue with you for many moons about this, but ultimately, it has to be up to the people doing the work, otherwise we'll never get anything done. Jul 20 17:03:15 mmcgrath, please email me your thoughts Jul 20 17:03:15 And I trust that if he's wrong, he'll be willing to admit it. Jul 20 17:03:19 OK, lyz if you don't know ldap well, how about letting me do a kind of "ldap plugin" ? Jul 20 17:03:24 mmcgrath: Besides, you're WRONG :) Jul 20 17:03:30 abompard, sure Jul 20 17:03:32 I do know ldap decently Jul 20 17:03:54 abompard: Cool Jul 20 17:03:58 I'd feel better about this if someone would tell me when, besides the current system, anyone here has ever used a custom sql instance with custom written software for their core user administration. Jul 20 17:04:32 mmcgrath: I did the old one for the GNOME project, if that helps. Jul 20 17:04:39 Its not like this is just one system, this is the center of all of our user management. All apps have to be able to interface with this. Jul 20 17:04:54 our functions could be made to plug into different backends, that should not be too hard Jul 20 17:05:43 what apps are going to authenticte with the account system? Jul 20 17:05:51 authenticate Jul 20 17:05:54 lyz: as many as is humly possible. Jul 20 17:05:55 lyz: Most of the ones on pasqual's list Jul 20 17:06:01 humanly Jul 20 17:06:17 Sopwith, where's pasqual's list Jul 20 17:06:20 and future apps that don't exist yet. Jul 20 17:06:33 mmcgrath: Do you know where I can find the equivalent of "The Practical SQL Handbook"? I need something along those lines to understand what LDAP's poewr is... Jul 20 17:06:34 It's not yet on the web Jul 20 17:06:38 lyz: He posted it in fedora-infrastructure-list last week. Jul 20 17:07:00 must've missed it, I'll look through it today Jul 20 17:07:33 What seems powerful about LDAP is so many systems can use it for auth. Shell access, Plone, Moin Moin, etc, etc. So with less work to get those pieces working there can be more time to work on our unique requirements. Jul 20 17:07:47 http://gort.metaparadigm.com/ldap/Practical-LDAP-and-Linux.pdf Jul 20 17:08:02 lyz/abompard: I think you guys need to make the ultimate decision if you're going to do the work. But can we move ahead with other parts of the process (such as abstract schema design, user interface mockups, setting up a CVS module, etc.)? Jul 20 17:08:41 I mean we can write a system from scratch, code all of our apps to work with it, and admin and design it. Or we can use what stuff already exists. Jul 20 17:08:43 I'll check if the default LDAP schema (inetOrgPerson) can handle all our requirements in AccountSystem2 Jul 20 17:09:12 mmcgrath: Err.. The Practical SQL Handbook is a programming guide. Jul 20 17:09:25 there's more to the system than just authentication, is LDAP good for that too? Jul 20 17:09:36 got'cha. that link is like a showcase. Jul 20 17:10:04 lyz: for example ? LDAP can do group memberships if that's what you mean Jul 20 17:10:29 * warren wonders if we could leverage any help from Red Hat's Directory Server division, if we go the LDAP route. Maybe they know something about LDAP. =) Jul 20 17:11:14 I'm sure they'd be willing to help, yea. Jul 20 17:11:17 abompard, I'm thinking like number of bugs closed and projects working on Jul 20 17:11:31 lyz: That's stuff for the metrics system rather than the account system... Jul 20 17:11:33 They may see benefit in lending a hand to us, because greater exposure and use by the Fedora community benefits them too. Jul 20 17:11:47 warren: you would hope they know something Jul 20 17:11:52 Sopwith, I see Jul 20 17:12:17 we'll still need to extend the default schema, for example to check if the CLA has been signed Jul 20 17:12:23 the account system covers authorization, authentication, project membership, CLA, and a few other things (e,g, email aliases) Jul 20 17:12:43 oh Jul 20 17:12:48 in this list, only the CLA boolean is not covered by the default schema Jul 20 17:12:50 I've used openldap with samba for central authentication in the past. It isn't too hard to extend schema for additional things you want to keep track of. Jul 20 17:12:50 Let's figure out a TODO for next week so we don't spend forever talking about orange versus apple. Jul 20 17:13:00 than LDAP isn't as bad as I first thought Jul 20 17:13:03 I think a great deal more research needs to be done on this before we even think about implementing it. Jul 20 17:13:31 * iWolf agrees with mmcgrath Jul 20 17:14:01 So what does that mean on a practical level? Jul 20 17:14:05 warren: much harder than adding a column to your database. you need an OID, a matching criteria, etc... Jul 20 17:15:17 here's one example of an ldap query: ldap://ldapserver/ou=Users,dc=fedoraproject,dc=org?uid?sub?(&(objectClass=user)(!(uid=baduser))) Jul 20 17:15:29 Sopwith: I think it might be wrapped up in your abstract comment. Working up what exactly this system need to do to make groups happy. Then apply those thought out requirements to an LDAP scenario and a SQL scenario and maybe even the LDAP_SQL scenario. Jul 20 17:15:33 that will return a list of users in the users ou, it excludes baduser. Jul 20 17:15:56 poor baduser Jul 20 17:16:04 he's tottally excluded. Jul 20 17:16:06 he deserved it Jul 20 17:16:09 hehe Jul 20 17:16:16 Sort of like abompard is thinking of now, what does the default LDAP schema do for us out of the box. And how hard to tweak it to do what we need. Jul 20 17:16:17 I'll setup a test LDAP server and try to implement a structure which would fulfill our requirements Jul 20 17:16:20 iwolf: lyz has done a good job of collecting requirements so far. Jul 20 17:16:21 but he could be a group, and it could have been cn=SysadminMain,ou=Users,dc=fedoraproject,dc=org Jul 20 17:16:42 abompard: I had an fds system setup on lockbox that had all of our users migrated already. Jul 20 17:16:53 mmcgrath: nice Jul 20 17:16:59 abompard: That's a good todo item. Jul 20 17:17:04 mmcgrath: can I have access to that ? Jul 20 17:17:17 yeah, I honsetly don't know if its still up and running. Jul 20 17:17:30 Sopwith: Agreed, now it is time to see which requires more work. Fitting them to an LDAP schema or SQL. Jul 20 17:18:06 lyz: I think it would be useful to have a CVS module set up for holding prototypes and stuff like that... What say you? Jul 20 17:18:15 mmcgrath: maybe I'll be faster setting up openldap on my PC Jul 20 17:18:17 Sopwith: And how those pieces fit with various systems. To me the fact that LDAP should work with several of our systems with minimal effort means there is more time to tweak what does need tweaking with LDAP. Jul 20 17:18:25 Sopwith, good idea. I need CVS access though Jul 20 17:18:33 abompard: bah, go straight with fds - Its actually pretty good. Jul 20 17:18:45 lyz: Please make sure you go through the process of creating an account in admin.fedoraproject.org/accounts/, and also completing the CLA. Jul 20 17:18:46 Sopwith: Whereas the pure SQL solution seems like more work overall to get the schema setup and plugged into all the different apps. Jul 20 17:19:10 Sopwith, I think I did that already Jul 20 17:19:18 lyz: OK, what's your username? Jul 20 17:19:27 Sopwith: Of course with all that said, I totally respect your comments that if you're not the one writing it then your vote may not count as much. :) Jul 20 17:19:30 mmcgrath: a perfect opportunity to give it a try :) Jul 20 17:19:33 Sopwith, lyz Jul 20 17:19:36 cool Jul 20 17:20:31 Is a hybrid solution a bad idea? My university had everything in SQL, and exported to LDAP. Various services used either depending on which was easier to integrate. Jul 20 17:20:54 I've thought about a hybrid. Jul 20 17:21:13 warren: I don't think a hybrid solution would be all bad either. Jul 20 17:21:13 How would it sync? Jul 20 17:21:19 scripts Jul 20 17:21:19 sounds nice, but I don't know how that can be done Jul 20 17:21:19 lyz: no sync Jul 20 17:21:22 lyz: You should be able to do 'cvs -d :ext:lyz at cvs.fedoraproject.org:/cvs/fedora checkout accounts2' to get a blank module to work in. Jul 20 17:21:23 push-only Jul 20 17:21:30 from sql->ldap Jul 20 17:21:35 skvidal: oh Jul 20 17:21:37 or ldap->sql Jul 20 17:21:40 mmcgrath: true Jul 20 17:21:47 one has to be the definitive set, though Jul 20 17:21:50 b/c merging is a bitch Jul 20 17:22:16 Sopwith, will try it thanks Jul 20 17:22:22 lyz: For next week, can you and abompbard start to pull together a more definite schema that meets the requirements, and stick it in there? Jul 20 17:22:36 can do Jul 20 17:22:39 Coolness. Jul 20 17:22:42 lyz: sure Jul 20 17:23:12 ah, I forgot this detail : I'll be on holiday from tuesday on Jul 20 17:23:15 ... Jul 20 17:23:18 :/ Jul 20 17:23:20 Oh, have fun then! Jul 20 17:23:30 abompard, I don't know if I have you email. Send something to lyz27 at yahoo.com please Jul 20 17:23:42 lyz: abompard at fedoraproject.org Jul 20 17:23:53 oh ....... Jul 20 17:24:08 yeah, you'll have that nice one too when you're in the account system Jul 20 17:24:24 i have it, I just don't use it yet Jul 20 17:24:30 okay Jul 20 17:24:34 Sorry this has gone on so long guys. I think we've covered just about everything. Jul 20 17:24:45 yeah, it's getting late Jul 20 17:24:48 Anyone here who is looking for something to do or just wants to introduce themselves? Jul 20 17:24:55 I know damaestro mentioned LDAP earlier Jul 20 17:25:59 Does anyone know me yet? Jul 20 17:26:10 I know of you :-D Jul 20 17:26:20 lyz: You've been here three times, so you're one of us. Jul 20 17:26:22 who truly knows anyone ? Jul 20 17:26:29 hehe Jul 20 17:26:35 (meeting is over, FWIW) Jul 20 17:26:37 Sopwith, sweet Jul 20 17:26:54 I'm going to need some resources to deploy my prototype of bzr for package version control. Jul 20 17:27:15 abadger1999: what kind of resources? Jul 20 17:27:38 headed out guys... later. Jul 20 17:27:42 So now that I'm not trying to keep everyone on the same page, it's probably a good time to respond to all those LDAP comments... Jul 20 17:27:43 ssh (with the scponly package installed) and http access. Jul 20 17:27:45 later Jul 20 17:27:54 A filesystem mounted with acl support. Jul 20 17:28:14 iwolf: later Jul 20 17:28:40 So my $0.02 on LDAP is that even though I probably wouldn't choose it personally, it can work fine as long as you stick with the standardized schema. Jul 20 17:28:50 If I do a full import of just Extras devel head I need 1- 1.5GB of space. Jul 20 17:29:13 But all these tools, and systems that authenticate against LDAP, are not going to be useful with the schema modifications that we need. Jul 20 17:29:36 For example, the standard LDAP groups table is probably going to be useless Jul 20 17:29:59 And retrieving a person's e-mail address will be hard for moinmoin when they have 5 e-mail addresses listed in a separate table. Jul 20 17:30:13 All these apps that have LDAP support built in assume use of the standard schema Jul 20 17:30:14 abadger1999: i might be able to help you out Jul 20 17:30:27 Sopwith, so it would be hard to allow groups access to certian apps? Jul 20 17:30:43 based on the group they are a member of Jul 20 17:30:44 dgilmore: Great! Jul 20 17:31:03 lyz: Well, probably not much harder than with an SQL solution... Jul 20 17:31:25 Sopwith: we can add to the standard schema without changing whats there. Jul 20 17:31:41 And why would the standard LDAP groups not work? Jul 20 17:31:55 mmcgrath: Because we need to support having groups be members of other groups Jul 20 17:32:04 mmcgrath: How would you implement that in LDAP? Jul 20 17:32:12 FDS has full support for dynamic groups. Jul 20 17:32:16 dgilmore: Do you want to email me? toshio fedoraproject.org Jul 20 17:32:33 you can say "if such and such user has a 3 in their telephone number and are located in Phoenix then they are a member of this group" Jul 20 17:32:39 How far is FDS (chuckle) from getting into extras? Jul 20 17:32:44 long wya Jul 20 17:32:48 but they're working on it. Jul 20 17:32:49 mmcgrath: OK, cool. Jul 20 17:33:09 A lot of places out there are using dynamic groups with custom attributes that you put on the use. Which isn't very hard to do. Jul 20 17:33:20 mmcgrath: OK, that will meet that need then. Jul 20 17:33:37 mmcgrath: And handling multiple e-mail addresses? Jul 20 17:33:52 LDAP laughs in the face of multiple email addresses. No problem. Jul 20 17:33:56 mmcgrath, how would you say " If a member is this type of member then they are allowed access to authenticate to application X " Jul 20 17:34:10 Depends on the app. In apache its very easy. Jul 20 17:34:21 do most apps support that? Jul 20 17:34:25 its just different. Jul 20 17:34:42 More support LDAP than will support our propriatary SQL server. Jul 20 17:34:54 k Jul 20 17:34:54 * mmcgrath wishes pastebin would actually work from time to time :-D Jul 20 17:34:56 mmcgrath: How many apps will need modifying to handle those two features? Jul 20 17:35:09 abompard: By the way, CLA support is more than just having a boolean field... Jul 20 17:35:50 guys I gotta run. Please include what more you talk about in the log Jul 20 17:35:56 lyz: OK, will do Jul 20 17:36:03 thanks bye Jul 20 17:36:04 abompard: For all the group memberships, we need to track where people are at in the membership process, and when they joined a group, etc. Jul 20 17:36:10 <-- lyz has quit ("Leaving") Jul 20 17:39:25 Sopwtih: for most stuff like logging in to apache, having multiple email addresses doesn't really matter Jul 20 17:40:03 mmcgrath: For using multiple e-mail addresses, moinmoin's "page changed" notifications are a good example. Jul 20 17:40:21 ahh, that will be in moinmoin then. Jul 20 17:41:05 here's an apache config example: http://mmcgrath.net/~mmcgrath/apacheexample.conf Jul 20 17:41:17 Yea, but someone mentioned that moinmoin had LDAP support, so I'm wondering whether these mentions of support mean complete support for the schema, or just the ability to authenticate against LDAP? Jul 20 17:41:44 It'd also be nice to do away with wiki groups and use LDAP groups instead, as another example. Jul 20 17:41:49 that I don't know, its usually up to the apps but it would be a simple ldap query to get the email addresses from a specific user. Jul 20 17:42:12 Does LDAP have the idea of a 'default' address? Jul 20 17:42:34 I leave for tonight, see you next week Jul 20 17:42:39 <-- pasqual (n=pasqual at 81-202-75-184.user.ono.com) has left #fedora-admin ("Leaving") Jul 20 17:44:48 Sopwith: I'm not sure about specifically with email. We'll have to see. Jul 20 17:44:52 OK Jul 20 17:45:24 Hey, before you go. Is there anyone else that has full admin access to the accounting system? Should I set myself up as an admin in all the groups? Jul 20 17:45:47 Yes, and no... Jul 20 17:46:01 k and won't :-D Jul 20 17:48:23 sorry i missed the discussion.. i am at work Jul 20 17:48:42 mmcgrath, thanks for make points that I would have also been inclined to make Jul 20 17:49:15 Sopwith, as far as I know.. all of what mmcgrath has mentioned about ldap is correct Jul 20 17:49:24 and FDS is a really good server Jul 20 17:49:49 damaestro: That's cool. Knowing about LDAP dynamic groups and a few other specific features does help a lot. Jul 20 17:50:10 bah we'll see what happens :-D Jul 20 17:50:28 Is FDS at the point where we could use it? It does smack of "synergies within the Fedora project" to use it :) Jul 20 17:51:22 The admin interface still relies on Sun's JDK. Jul 20 17:51:42 But there are web interfaces that should work well for us. Jul 20 17:51:47 Cool Jul 20 17:52:06 If it helps at all, Jakub is planning on checking in a 25M patch to gcc that backports a bunch of Java stuff from head, and allows appletviewer to work. :) Jul 20 17:52:25 huzza. Jul 20 17:52:38 That'll be fun. From dennis at ausil.us Fri Jul 21 15:44:14 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 21 Jul 2006 10:44:14 -0500 Subject: [Fedora-infrastructure-list] Builders reinstall Message-ID: <200607211044.14919.dennis@ausil.us> Hey guys, Im preparing to reinstall the extras builders. I'm after the details and whereabouts of the kickstart files that were previously used. they will be getting fc5 installed on them all. Regards Dennis From skvidal at linux.duke.edu Fri Jul 21 19:51:18 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 21 Jul 2006 15:51:18 -0400 Subject: [Fedora-infrastructure-list] Builders reinstall In-Reply-To: <200607211044.14919.dennis@ausil.us> References: <200607211044.14919.dennis@ausil.us> Message-ID: <1153511479.10347.45.camel@cutter> On Fri, 2006-07-21 at 10:44 -0500, Dennis Gilmore wrote: > Hey guys, > > Im preparing to reinstall the extras builders. I'm after the details and > whereabouts of the kickstart files that were previously used. they will be > getting fc5 installed on them all. > I would recommend doing them one at a time ;) -sv From dennis at ausil.us Fri Jul 21 20:14:27 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 21 Jul 2006 15:14:27 -0500 Subject: [Fedora-infrastructure-list] Builders reinstall In-Reply-To: <1153511479.10347.45.camel@cutter> References: <200607211044.14919.dennis@ausil.us> <1153511479.10347.45.camel@cutter> Message-ID: <200607211514.27407.dennis@ausil.us> On Friday 21 July 2006 14:51, seth vidal wrote: > On Fri, 2006-07-21 at 10:44 -0500, Dennis Gilmore wrote: > > Hey guys, > > > > Im preparing to reinstall the extras builders. I'm after the details > > and whereabouts of the kickstart files that were previously used. they > > will be getting fc5 installed on them all. > > I would recommend doing them one at a time ;) > > > -sv thats the plan, make the disruption to users minimal and ensure that they can build while its all happening. Dennis From linux at elfshadow.net Thu Jul 27 15:12:17 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Thu, 27 Jul 2006 11:12:17 -0400 Subject: [Fedora-infrastructure-list] Today's Meeting Message-ID: <44C8D7D1.4020804@elfshadow.net> I will be out of town when our meeting occurs today, so I will be unable to make it. I will catch up via the irc logs. Thanks, Jeffrey a.k.a. iWolf From mmcgrath at fedoraproject.org Fri Jul 28 15:32:07 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 28 Jul 2006 10:32:07 -0500 Subject: [Fedora-infrastructure-list] New OTRS Queue: Update System Message-ID: <3237e4410607280832w325ab5a0s494a67310921f925@mail.gmail.com> I've added a new OTRS queue for the Update System. Any users wishing to monitor and aid in troubleshooting Update System problems should add this queue to their "my queues" section in OTRS. -Mike From lmacken at redhat.com Fri Jul 28 16:11:49 2006 From: lmacken at redhat.com (Luke Macken) Date: Fri, 28 Jul 2006 12:11:49 -0400 Subject: [Fedora-infrastructure-list] New OTRS Queue: Update System In-Reply-To: <3237e4410607280832w325ab5a0s494a67310921f925@mail.gmail.com> References: <3237e4410607280832w325ab5a0s494a67310921f925@mail.gmail.com> Message-ID: <20060728161149.GA2589@crow.rdu.redhat.com> On Fri, Jul 28, 2006 at 10:32:07AM -0500, Mike McGrath wrote: > I've added a new OTRS queue for the Update System. Any users wishing > to monitor and aid in troubleshooting Update System problems should > add this queue to their "my queues" section in OTRS. Thanks Mike! Speaking of the update system.. In my spare cycles I've been working on a new version of the currently internal update system using TurboGears. This time around, I hope to weed out all of the nasty mod_python hacks and hopefully add some cohesion between the Core/Extras/Legacy package update process. This will entail a web front end for adding/viewing/maintaining updated packages and viewing metrics, with an xmlrpc api which can be used by command-line tools, and most likely per package/distro/whatever RSS feeds. I guess now we should start figuring out where this stuff is eventually going to live. If no one has any problems, I can import the code I've been working on into svn. Since TurboGears is badass, it has the notion of a development environment and a production environment, so testing the server in a dev environment is as easy as ./start-updatesys.py on any machine w/ TG. The production environment we can worry about later. This brings us to the Package Database, which the Update System can tie into nicely. I currently defined a Package and a Release table in my current model.py which defines the basic fields that the update system needs, but expanding to use Elliot's db model would be trivial. So what progress, if any, has been made on the package db? Being fairly well-versed in TurboGears, I'd like to help out a bit. If it hasn't already been done, I can create a default TG layout with Elliot's model in place so people can start poking around with it. Before much code gets written I think we need to figure out what this 'Package Database' is going to offer from a front-end perspective. Does it need to be it's own entity? Can it be tied in to the update system to provide a one-stop-shop for all fedora package related shenannagans? But in the mean time, getting whatever code is written into a place where we can all start poking at it is probably a good first step. luke From fedora at leemhuis.info Fri Jul 28 20:33:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Jul 2006 22:33:28 +0200 Subject: [Fedora-infrastructure-list] when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <20060728220925.c65be643.bugs.michael@gmx.net> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> Message-ID: <44CA7498.4020609@leemhuis.info> Michael Schwendt schrieb: > On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: >> Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert >> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl >> handshake failure')] > > So, would anyone please give a short introduction on when the OTRS > ticketing system ought to be used instead of bugzilla? > [...] > What I'm still missing is the announcement for everyone. Which system do > we use when? Well, don't ask FESCO, let's ask and kick the proper people: fedora-infrastructure at redhat.com (CCed) I'd be interested in the answers, too. I don't really like having two systems and would have prepared if we (people outside of the infrastructure group) stick to bugzilla. CU thl From mmcgrath at fedoraproject.org Fri Jul 28 20:42:29 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 28 Jul 2006 15:42:29 -0500 Subject: [Fedora-infrastructure-list] when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <44CA7498.4020609@leemhuis.info> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <44CA7498.4020609@leemhuis.info> Message-ID: <3237e4410607281342t7839ef39pdfb8b4c3cf0d342c@mail.gmail.com> Bugzilla is a bug tracking tool which is mostly to be used for development related issues. OTRS is more for trouble tickets and feature requests relating to Fedora's support infrastructure. -Mike On 7/28/06, Thorsten Leemhuis wrote: > > > Michael Schwendt schrieb: > > On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: > >> Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > >> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > >> handshake failure')] > > > > So, would anyone please give a short introduction on when the OTRS > > ticketing system ought to be used instead of bugzilla? > > [...] > > What I'm still missing is the announcement for everyone. Which system do > > we use when? > > Well, don't ask FESCO, let's ask and kick the proper people: > fedora-infrastructure at redhat.com (CCed) > > I'd be interested in the answers, too. I don't really like having two > systems and would have prepared if we (people outside of the > infrastructure group) stick to bugzilla. > > CU > thl From dennis at ausil.us Fri Jul 28 21:35:22 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 28 Jul 2006 16:35:22 -0500 Subject: [Fedora-infrastructure-list] ppc1 Message-ID: <200607281635.22811.dennis@ausil.us> Hi All, We are currently working on rebuilding ppc1 Please do not try and power cycle it or do anything with or to it until it is rebuilt. Regards Dennis From skvidal at linux.duke.edu Fri Jul 28 21:38:35 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 28 Jul 2006 17:38:35 -0400 Subject: [Fedora-infrastructure-list] Re: when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <44CA7498.4020609@leemhuis.info> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <44CA7498.4020609@leemhuis.info> Message-ID: <1154122716.3951.39.camel@cutter> On Fri, 2006-07-28 at 22:33 +0200, Thorsten Leemhuis wrote: > > Michael Schwendt schrieb: > > On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: > >> Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > >> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > >> handshake failure')] > > > > So, would anyone please give a short introduction on when the OTRS > > ticketing system ought to be used instead of bugzilla? > > [...] > > What I'm still missing is the announcement for everyone. Which system do > > we use when? > > Well, don't ask FESCO, let's ask and kick the proper people: > fedora-infrastructure at redhat.com (CCed) > > I'd be interested in the answers, too. I don't really like having two > systems and would have prepared if we (people outside of the > infrastructure group) stick to bugzilla. > If you're curious what happened it was this: hammer1, hammer2, hammer3 and ppc1 all expired their ssl certs for their builder instances. I fixed them up and closed the ticket saying that's what I did. afaik that was all that was wrong. sorry for not saying more earlier - been a busy day at work. -sv From skvidal at linux.duke.edu Fri Jul 28 21:39:44 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 28 Jul 2006 17:39:44 -0400 Subject: [Fedora-infrastructure-list] Re: ppc1 In-Reply-To: <200607281635.22811.dennis@ausil.us> References: <200607281635.22811.dennis@ausil.us> Message-ID: <1154122784.3951.41.camel@cutter> On Fri, 2006-07-28 at 16:35 -0500, Dennis Gilmore wrote: > Hi All, > > We are currently working on rebuilding ppc1 Please do not try and power cycle > it or do anything with or to it until it is rebuilt. > when it is up let me know and I'll put the cert back in place thanks, -sv From mmcgrath at fedoraproject.org Fri Jul 28 22:18:52 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 28 Jul 2006 17:18:52 -0500 Subject: [Fedora-infrastructure-list] Re: when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <1154122716.3951.39.camel@cutter> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <44CA7498.4020609@leemhuis.info> <1154122716.3951.39.camel@cutter> Message-ID: <3237e4410607281518g39de414csc0feb57001f7a29f@mail.gmail.com> On 7/28/06, seth vidal wrote: > > afaik that was all that was wrong. > > sorry for not saying more earlier - been a busy day at work. > > -sv The http://buildsys.fedoraproject.org/build-status/index.psp site is showing expired certs too :-D -Mike From dennis at ausil.us Sat Jul 29 14:59:52 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 29 Jul 2006 09:59:52 -0500 Subject: [Fedora-infrastructure-list] ppc1 In-Reply-To: <200607281635.22811.dennis@ausil.us> References: <200607281635.22811.dennis@ausil.us> Message-ID: <200607290959.53444.dennis@ausil.us> On Friday 28 July 2006 4:35 pm, Dennis Gilmore wrote: > Hi All, > > We are currently working on rebuilding ppc1 Please do not try and power > cycle it or do anything with or to it until it is rebuilt. > > Regards > > Dennis Hey All, PPC1 is rebuilt and back in use it is now running FC5 it has mock-0.6-4.fc5 yum-2.6.1-0.fc5 hopefully this will speed up chroot creation a little. but most importantly it should be using the minimal buildroot now. over the weekend im going to upgrade ppc2 and 3, and im going to attempt the hammers also. we dont have serial console access to the bios on the hammers so im going to try them by putting the installer kernel and initrd in /boot and booting from that. It will mean that we will have one shot at the install. If it fails that builder will be out only a couple of days, there is someone at the colo all week. We are also going to have them see if we can get access to the bios over serial console. -- Dennis Gilmore, RHCE Proud Australian From mmcgrath at fedoraproject.org Sat Jul 29 21:17:32 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 29 Jul 2006 16:17:32 -0500 Subject: [Fedora-infrastructure-list] Security, access and the config CVS Message-ID: <3237e4410607291417r60396cbdx9e2e8dc468c2dc9c@mail.gmail.com> So while dgilmore was rebuilding the builders this weekend I realized a couple of things: We need to re-think the cvs situation. Not only have the configs become woefully out of date with whats on the actual builders, but upgrades can become difficult when moving from one OS to another because of incompatibilities. I don't know that we should get rid of all of it just re-think what goes in it or try to simplify it a bit. Maybe write a script that runs daily and compares whats in CVS with what's live? Not perfect but better than what we have. Regardless of what we do with it we need to figure out where to put CVS because not everyone has access to lockbox. I've also been giving more thought to the security/access issue. While re-doing the accounting system we need to think about ways to increase security while lowering the barrier for entry to help support Fedora's infrastructure. We can add much of this to the current accounting system for testing for when the new system gets built but I'd like input on this from current infrastructure people and those that aren't as active but are interested in participating more. Which brings me to restarting the topic of officers/leaders/sponsors/whatever. By creating more fine-grained security on the servers there is less of a need for root access on those machines. People interested in working on mail, will be in a mail group and have access to it. Nagios, web, proxy, builders, cvs, etc, all come to mind of things that can be administered without full root access. So the question is how do we determine who has root to what boxes? Should we pick some leaders of Red Hat engineers and community members to have full root? If so should it be of a set number, similar to the FESCo? I lean towards this setup because it allows more people to participate sooner (without having to prove themselves as much) but it will keep those with full root access to the box low. Lot of stuff for one email but it would be nice to get a lot of this figured out before the next meeting so it doesn't run too long :-D -Mike From fedora at leemhuis.info Sun Jul 30 15:38:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 30 Jul 2006 17:38:01 +0200 Subject: [Fedora-infrastructure-list] help with bug 198109 ("initialcclist" in owners.list is not propagating to Bugzilla) Message-ID: <44CCD259.1080701@leemhuis.info> Hi All! Is there anyone besides Sopwith (is he still around or already on vacation?) who can help fix bug 198109? Seems the "initialcclist" in owners.list is not propagating to Bugzilla. That blocks proper co-maintainership in Extras. CU thl From linux at elfshadow.net Mon Jul 31 01:50:46 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Sun, 30 Jul 2006 21:50:46 -0400 Subject: [Fedora-infrastructure-list] Security, access and the config CVS In-Reply-To: <3237e4410607291417r60396cbdx9e2e8dc468c2dc9c@mail.gmail.com> References: <3237e4410607291417r60396cbdx9e2e8dc468c2dc9c@mail.gmail.com> Message-ID: <44CD61F6.9090300@elfshadow.net> Mike McGrath wrote: > We need to re-think the cvs situation. Not only have the configs > become woefully out of date with whats on the actual builders, but > upgrades can become difficult when moving from one OS to another > because of incompatibilities. I don't know that we should get rid of > all of it just re-think what goes in it or try to simplify it a bit. > Maybe write a script that runs daily and compares whats in CVS with > what's live? Not perfect but better than what we have. Regardless of > what we do with it we need to figure out where to put CVS because not > everyone has access to lockbox. As for the configs being out of synch with the cvs admin repo, we definitely need to do what we can to keep that from happening. Some of this can probably be solved just by reinforcing the use of the cvs repo and making sure new folks know of its existance and the importance of checking any configuration changes made on a server into cvs. A script to compare what's in the repo and what's on the servers could be useful though to help make sure the proper steps are being followed. Why do we need to move the admin cvs repo? Isn't the fedora-config repo kept on it to keep it isolated from the other servers performing mainstream production duties? Wouldn't limiting root access on lockbox get us what we are after? Then we could give shell access to people that needed it and use permissions to restrict them from locations deemed more sensitive than others. I may just be missing something on this point, so feel free to point out the core of the concern. > Which brings me to restarting the topic of > officers/leaders/sponsors/whatever. By creating more fine-grained > security on the servers there is less of a need for root access on > those machines. People interested in working on mail, will be in a > mail group and have access to it. Nagios, web, proxy, builders, cvs, > etc, all come to mind of things that can be administered without full > root access. So the question is how do we determine who has root to > what boxes? Should we pick some leaders of Red Hat engineers and > community members to have full root? If so should it be of a set > number, similar to the FESCo? I lean towards this setup because it > allows more people to participate sooner (without having to prove > themselves as much) but it will keep those with full root access to > the box low. I think the majority of people tended to agree that areas of focus would be good for the group. I am not sure moving to a set number of people with root is necessarily good. I think it could lead towards an inflexible process. I would start with a smallish group - but large enough to have someone available without causing long delays in critical troubleshooting (i.e. being a volunteer group has some unique considerations as to availability). Once the smaller group is established requests for access are distributed as needed. The members of focus groups are given access via permissions to areas they need more control of. We can probably cover many of the areas you mention above in that manner. I will give some more thought and see if I can post some more specific ideas. -Jeffrey From mmcgrath at fedoraproject.org Mon Jul 31 03:07:45 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 30 Jul 2006 22:07:45 -0500 Subject: [Fedora-infrastructure-list] Quick project for doc's Message-ID: <3237e4410607302007s2db7228bice7e7aa6d933e9ea@mail.gmail.com> Throwing this out there for anyone interested. Karsten (quaid) has requested a script that will compare the packages between two releases. Below is a quick IRC chat we had. I've been busy with other stuff so I won't be able to get to it right away. The idea of coming to us is maintainability. Whatever we end up with will end up in CVS and maintained by us so anyone out there that's good with Perl/Python/XML sign up. Don't take it if you don't have time to do it, I already did that :) Whoever wants it go ahead and reply to the list so everyone knows, and add it to: http://fedoraproject.org/wiki/Infrastructure/Schedule If you need any help let me know and I'll point you in the right direction. -Mike ======== From #fedora-docs =========== [15:16:54] * quaid gets an example [15:17:36] http://fedora.redhat.com/docs/release-notes/fc5/#sn-PackageChanges [15:18:06] and someone did help with that list, which I just put into a block [15:19:30] so, you can see a bit of the package info in there, and the designation of if it is coming in or out. [15:20:11] naturally, it would be cool for it to say what happened to a package leaving, such as going to Extra, but that doesn't seem doable ... that info isn't stored anywhere to extract. [15:20:24] so, here is the need, in cascading order: [15:20:29] k [15:20:31] 1. treediff -> a nice list [15:20:39] 2. nice list -> XML list [15:21:06] 3. a nice script that can be run somewhere to let a clueless editor do this easily [15:21:10] [15:21:49] we want to put in the set for each test, etc., so it shows the package changes incrementally in that way. [15:23:25] I got'cha. [15:23:45] So what of that stuff would you like the infrastructure team to do? [15:26:37] quaid: I think I'm following you now, you just really want some scripts to do all of this stuff automatically and then stick the results somewhere for you guys to do some final touches. [15:27:34] mmcgrath: right, although the results could be a 100% valid XML document (header declaring it as e.g. a 'section'), and we really don't need to anything more than XInclude it. [15:28:45] also, a reason for turning to Infrastructure v. cooking it up ourselves in maintainability ... we want something that is part of the formal process and has some support so when e.g. treediff or something changes, the smarts are there to fix it. :) [15:29:57] I don't think that will be too much of a problem. We can at least have SOMETHING to you soon. you'll probably have to get back to me a few times about how to fine tune it From sopwith at gmail.com Fri Jul 28 20:42:40 2006 From: sopwith at gmail.com (Elliot Lee) Date: Fri, 28 Jul 2006 20:42:40 -0000 Subject: [Fedora-infrastructure-list] when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <44CA7498.4020609@leemhuis.info> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <44CA7498.4020609@leemhuis.info> Message-ID: To help clarify things, yesterday I disabled new bug reports in bugzilla's "Fedora Infrastructure" product. Most of the infrastructure issues lend themselves better to the "report via e-mail and have an open issue for each person" model that OTRS facilitates. -- Elliot