From awilliam at redhat.com Wed Apr 1 16:56:00 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 01 Apr 2009 09:56:00 -0700 Subject: Fedora Calendering system: listing clear requirements. In-Reply-To: References: Message-ID: <1238604960.4338.172.camel@adam.local.net> On Sun, 2009-03-29 at 08:50 +0530, susmit shannigrahi wrote: > Hi, > The other mail was getting too long. > I am writing this as I think I have found the solution. (by using > zicula and phpical together) > > > So I want to understand the required functionalities. > > What I have got so far: > > 1. Having a calender. ;) > 2. Updating and Syncing from different clients using caldev protocol. > 3. Having a web-interface to view/update/sync the calenders. Sounds exactly right, yes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From rino.mardo at gmail.com Wed Apr 1 17:33:28 2009 From: rino.mardo at gmail.com (Rino Mardo) Date: Wed, 1 Apr 2009 20:33:28 +0300 Subject: sysadmin group In-Reply-To: References: Message-ID: that's the life of network geeks. alerts make us feel alive! :-) i just applied to the group now. On Tue, Mar 31, 2009 at 12:43 AM, Mike McGrath wrote: > On Mon, 30 Mar 2009, Rino Mardo wrote: > >> ok i found a FIG and it's called sysadmin. i think this is the closest >> to my actual experience. >> >> i want to join sysadmin. should i apply now or wait for a nod? >> > > Yep, that's a good one to apply for as any other sysadmin-* groups require > it. ?Let me know once you've applied and I'll make sure to sponsor you... > beware though... you'll start getting nagios alerts. > > ? ? ? ?-Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From dimitris at glezos.com Wed Apr 1 20:12:43 2009 From: dimitris at glezos.com (Dimitris Glezos) Date: Wed, 1 Apr 2009 22:12:43 +0200 Subject: Translation Toolchain Freeze Message-ID: <6d4237680904011312r43ae4675yccc737d0ab9ed290@mail.gmail.com> In Fedora's 6-month cycle, there are a few weeks in which translators are working full-steam. These are the period for software translation and one for Docs translations. During these periods the L10n Infrastructure should be considered frozen, otherwise the work of a few hundred people will be interrupted (currently 40+ commits per day are taking place). Looking at poelstra's schedule [1], these freeze periods are: 2009-03-10 - 2009-04-14 2009-04-29 - 2009-05-14 If there's a document we need to have these added, please let me know. Having the same process (+1s etc) for L10n Infra would be great, IMO. -d [1] http://poelstra.fedorapeople.org/schedules/f-11/f-11-trans-tasks.html -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From stickster at gmail.com Wed Apr 1 23:03:26 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 1 Apr 2009 19:03:26 -0400 Subject: Logs from f-peeps Message-ID: <20090401230326.GC9334@localhost.localdomain> Some of the recent Test Day live images were hosted from fedorapeople.org space. I'd like to find out how many downloads there were of these images, but I can't read /var/log/httpd on that host (which makes sense). Are those logs supposed to be separate? If so, I probably need some help with this request and can file a ticket. If not, well I can still file a ticket. :-) Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonstanley at gmail.com Wed Apr 1 23:15:47 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 1 Apr 2009 19:15:47 -0400 Subject: Logs from f-peeps In-Reply-To: <20090401230326.GC9334@localhost.localdomain> References: <20090401230326.GC9334@localhost.localdomain> Message-ID: 2009/4/1 Paul W. Frields : > Some of the recent Test Day live images were hosted from > fedorapeople.org space. ?I'd like to find out how many downloads there > were of these images, but I can't read /var/log/httpd on that host > (which makes sense). ?Are those logs supposed to be separate? ?If so, > I probably need some help with this request and can file a ticket. ?If > not, well I can still file a ticket. :-) I need to fix fedorahosted not reporting in awstats (since the logs aren't on log1). I'll fix people1 at the same time if no one objects. From skvidal at fedoraproject.org Wed Apr 1 23:15:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 1 Apr 2009 19:15:23 -0400 (EDT) Subject: Logs from f-peeps In-Reply-To: <20090401230326.GC9334@localhost.localdomain> References: <20090401230326.GC9334@localhost.localdomain> Message-ID: On Wed, 1 Apr 2009, Paul W. Frields wrote: > Some of the recent Test Day live images were hosted from > fedorapeople.org space. I'd like to find out how many downloads there > were of these images, but I can't read /var/log/httpd on that host > (which makes sense). Are those logs supposed to be separate? If so, > I probably need some help with this request and can file a ticket. If > not, well I can still file a ticket. :-) Which user's site hosted them? I can query the logs and dump those out if you can tell me. -sv From stickster at gmail.com Thu Apr 2 00:59:40 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 1 Apr 2009 20:59:40 -0400 Subject: Logs from f-peeps In-Reply-To: References: <20090401230326.GC9334@localhost.localdomain> Message-ID: <20090402005940.GE9334@localhost.localdomain> On Wed, Apr 01, 2009 at 07:15:23PM -0400, Seth Vidal wrote: > On Wed, 1 Apr 2009, Paul W. Frields wrote: > >> Some of the recent Test Day live images were hosted from >> fedorapeople.org space. I'd like to find out how many downloads there >> were of these images, but I can't read /var/log/httpd on that host >> (which makes sense). Are those logs supposed to be separate? If so, >> I probably need some help with this request and can file a ticket. If >> not, well I can still file a ticket. :-) > > Which user's site hosted them? I can query the logs and dump those out if > you can tell me. It was James Laska's (jlaska). The filenames changed but I think they all used something pretty obvious like "testday-live" in the middle. Daily counts for the month of March would be fine. I hear Jon is busy getting these logs moved over, so *please* put this at the very bottom of your pile, and discard if the ticket is closed before you get to it. https://fedorahosted.org/fedora-infrastructure/ticket/1306 -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Thu Apr 2 01:02:24 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 1 Apr 2009 21:02:24 -0400 Subject: Logs from f-peeps In-Reply-To: <20090402005940.GE9334@localhost.localdomain> References: <20090401230326.GC9334@localhost.localdomain> <20090402005940.GE9334@localhost.localdomain> Message-ID: <20090402010224.GF9334@localhost.localdomain> On Wed, Apr 01, 2009 at 08:59:40PM -0400, Paul W. Frields wrote: > On Wed, Apr 01, 2009 at 07:15:23PM -0400, Seth Vidal wrote: > > On Wed, 1 Apr 2009, Paul W. Frields wrote: > > > >> Some of the recent Test Day live images were hosted from > >> fedorapeople.org space. I'd like to find out how many downloads there > >> were of these images, but I can't read /var/log/httpd on that host > >> (which makes sense). Are those logs supposed to be separate? If so, > >> I probably need some help with this request and can file a ticket. If > >> not, well I can still file a ticket. :-) > > > > Which user's site hosted them? I can query the logs and dump those out if > > you can tell me. > > It was James Laska's (jlaska). The filenames changed but I think they > all used something pretty obvious like "testday-live" in the middle. > Daily counts for the month of March would be fine. > > I hear Jon is busy getting these logs moved over, so *please* put this > at the very bottom of your pile, and discard if the ticket is closed > before you get to it. > > https://fedorahosted.org/fedora-infrastructure/ticket/1306 By the time I posted this, Jon was done. You guys are too good! -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From guille.zion at gmail.com Fri Apr 3 03:23:50 2009 From: guille.zion at gmail.com (guille) Date: Fri, 03 Apr 2009 00:23:50 -0300 (ART) Subject: I wanna join the FIG Message-ID: <49d58134.19015a0a.3bbe.ffffb7c5@mx.google.com> An HTML attachment was scrubbed... URL: From vinaya.amatya at gmail.com Fri Apr 3 06:42:16 2009 From: vinaya.amatya at gmail.com (Vinay Amatya) Date: Fri, 3 Apr 2009 01:42:16 -0500 Subject: Hi Message-ID: Hi All, I'm Vinay. I got upto here while trying to fix my installation of Fedora-10. I've been steady user of Fedora package for a little more than a year. I like it better, as I learn more in Fedora environment than on other platforms. Regarding contributing to the Project, I'm a newbie. I'm interested in core infrastructure development/maintainance. I'm comfortable with C, C++, Java. I'd like to learn Python, or Ruby, if I get a project/task that makes me do it. At this stage, I'd like to observe the kinds of problems this(infrastructure) team handles, possibly learn some stuffs, and contribute where possible. Looking forward to working with you, cheers, Vinay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Sat Apr 4 01:49:37 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 3 Apr 2009 20:49:37 -0500 (CDT) Subject: I wanna join the FIG In-Reply-To: <49d58134.19015a0a.3bbe.ffffb7c5@mx.google.com> References: <49d58134.19015a0a.3bbe.ffffb7c5@mx.google.com> Message-ID: On Fri, 3 Apr 2009, guille wrote: > Hi everybody, well this mail is to let you know about my enthusiasm to join the FIG. About me, mi name is guillermo ( you > can visit my profile for official details) im from Buenos Aires Argentine, im 26 years old and im in first year on > Computer Science at Caece university, i have not a lot of free time, but surely i will be a good help for the proyect > > Currently i have five years experience working with Linux especially over red hat flavours, ain't me a great admin i'm > not even a good admin, but also im sure this opportunity will be great for improve my skills to reach be a great kick a** > sysadmin, futhermore i have my own hardware test and i've subscribed to list too!!! hehehe, i have medium knowledge on > most of the linux ip protocols, same knowledge for perl/bash scripting and my english is not very good as you can see. > > at the beginning i would like to apply on sysadmin - sysadmin-noc. you can find me on the room as gu1ll3, gu1lle, guill3, > so > > I guess thats all folks, with these references definitely i'll have a lot of sponsers =P. > > Please any doubt about me or other stuff feel free to contact me, im really excited to participate on the proyect > Well thanks for all the interest! I tried finding you on IRC just now but I don't see you on there, no worries. Next time you are on irc.freenode.net stop by #fedora-admin and say hello. In the meantime go ahead and apply for the 'sysadmin' group and email me when you've done so so I can approve it. -Mike From mmcgrath at redhat.com Sat Apr 4 01:51:34 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 3 Apr 2009 20:51:34 -0500 (CDT) Subject: Hi In-Reply-To: References: Message-ID: On Fri, 3 Apr 2009, Vinay Amatya wrote: > Hi All, > > I'm Vinay. I got upto here while trying to fix my installation of Fedora-10. I've been steady user of Fedora package for > a little more than a year. I like it better, as I learn more in Fedora environment than on other platforms. > Regarding contributing to the Project, I'm a newbie. I'm interested in core infrastructure development/maintainance. > I'm comfortable with C, C++, Java.? I'd like to learn Python, or Ruby, if I get a project/task that makes me do it. > Boy oh boy do we love programmers. If you'd like to help I've got a few smaller tasks that you could do while you get to learning python. If you want to go through some of the basic tutorials of python then install fas come find me on irc.freenode.net in #fedora-admin and we'll talk about some stuff. > At this stage, I'd like to observe the kinds of problems this(infrastructure) team handles, possibly learn some stuffs, > and contribute where possible. > You're always welcome to observe and learn whatever stuffs you want ;-) -Mike From bashton at brennanashton.com Mon Apr 6 18:37:59 2009 From: bashton at brennanashton.com (Brennan Ashton) Date: Mon, 6 Apr 2009 18:37:59 +0000 Subject: RFR: triageweb Message-ID: <981da310904061137y917e57chb4a1cb73770e70b0@mail.gmail.com> ==Primary Contact== Name: Brennan Ashton Fedora Account Name: bashton Group: Bugzappers Infrastructure Sponsor: ==Secondary Contact== Name: John Poelstra Fedora Account Name: poelstra Group: Bugzappers ==Project Info== Project Name: TriageWeb Target Audience: Bug Triagers, Developers, Quality Assurance. To some extent this might include the general public, as a way to see how fedora is managing bugs and developing. Expiration/Delivery Date (Required): 06/06/2009 ==Description/Summary== TriageWeb is a turbogears application that automatically queries and processes bugzilla bugs to generate user defined reports on triage related activities. Base reports include: * Number of bugs of each work flow status changed for Fedora product as a whole over time * Number of bugs of each work flow status changed for component D over time * Number of bugs of each work flow status changed for component group E over time * Number of bugs of each work flow status changed by user F over time * Number of bugs of each work flow status changed by user group G over time Data is presented in both tabular and graphical displays (these lack some UI changes for customizing queries): Here are some samples: * http://bashton.fedorapeople.org/personalstat.png * http://bashton.fedorapeople.org/mainlist.png Tabular data can be sorted and date ranges can be selected. Graphical data can have data ranges limited, as well as statuses. Refreshes of bug data would be updated at the end of each day, as processing the few hundred bug reports changed each day take a fair amount of time. FutureFeatures (not so far away): * Will integrate with FAS so that users can store there queries for later, they also can create custom user and component groups here. * Send weekly reports on rawhide bugs, and well as top reporters, triagers, and bug closers. * A Look Into Rawhide --This is an idea that I discussed with jlaska, the idea is that this is a work bench that people can visit to see how we are progressing with blockers as milestone are reached. This would also include a section that more effectively then bugzilla, shows the top duplicated bugs, so that developers and traigers spend less time having to sort through 50 dup bug reports filed when component X failed today. *Create a section where FAS groups and users can create a monitor goals that are compared to standard queries. What this means will be partially determined by feedback on what people use and how they use the core features. ==Project Plan== * Currently the project is locally hosted and is in a nearly usable state already. There is still one known bug in the scripts that pull data from bugzilla, this just requires going back and tracing what types of bugs cause the error and then fixing the script to process these correctly. * In a week or as soon as the RFR is granted, people are wanting to start testing the app, the triage group is especially eager to start using it, this will give me significant feedback as to what needs to be changed or added. *After this has become stable, I will request that the application be pushed live as a release application. * I need to start looking into optimizing the database queries and format, as the application is database intensive. * Once the core app is running smoothly I will start to integrate and develop the tasks outlined in FutureFeatures in the order that I have listed them. The development of these features will mostly take place during the months of June and July, and then continue at a slower pace during the school year where the focus will be primarily maintenance and bug fixes as I will have more limited time. ==Specific Resources Needed== *Webspace to run the turbogears application *Ability to create cron jobs for daily data fetching scripts (no more then an hour each day) --When rebuilding the database to introduce feature requests a script will take around 10-12 hours. This should happen only very occasionally, and does not take much processing power as most of the time is spent doing xmlrpc communications with bugzilla. *Database space to store metrics data as well as user preferences. The metrics data right now in a sqlite db is only a few MB, I would not expect it to grow beyond 50MB even with heavy user usage. I have no preference between MySQL and postgresql *Package wise all dependencies are in fedora already, with the exception of traigeweb itself. --Python --TurboGears --python-turboflot --python-fedora --python-bugzilla --python-sqlalchemy --python-numeric --httpd There may be a few others, but that should be a very representative list. ==Goals== The point of this project is to give the traige, packaging, and QA groups some new tools so that they can better measure there status as well as monitor critical areas. This should especially help with the development cycles once some of the FutureFeatures have been introduced. This also allows fedora to better recognize the commitment of some members in the community who spend there time in the drudgery of processing, reporting, and solving bugs. ==Other Notes== * I am looking for someone in the sysadmin-web group to sponsor me. * I have filed this as ticket #1314 https://fedorahosted.org/fedora-infrastructure/ticket/1314 Thank you for the consideration, Brennan Ashton From ricky at fedoraproject.org Tue Apr 7 05:28:52 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 7 Apr 2009 01:28:52 -0400 Subject: RFR: triageweb In-Reply-To: <981da310904061137y917e57chb4a1cb73770e70b0@mail.gmail.com> References: <981da310904061137y917e57chb4a1cb73770e70b0@mail.gmail.com> Message-ID: <20090407052852.GC15860@sphe.res.cmu.edu> On 2009-04-06 06:37:59 PM, Brennan Ashton wrote: > ==Project Info== > Project Name: TriageWeb > Target Audience: Bug Triagers, Developers, Quality Assurance. To some > extent this might include the general public, as a way to see how > fedora is managing bugs and developing. > Expiration/Delivery Date (Required): 06/06/2009 I'd be happy to sponsor this - can somebody please approve bashton into sysadmin-test? Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mapleoin at lavabit.com Tue Apr 7 12:45:32 2009 From: mapleoin at lavabit.com (=?UTF-8?B?SW9udcibIEFyyJvEg3JpyJlp?=) Date: Tue, 07 Apr 2009 15:45:32 +0300 Subject: sysadmin sponsoring Message-ID: <49DB4AEC.5060000@lavabit.com> Hello, I've recently become interested in the openid part of FAS and have already setup a server on my laptop and began hacking. However, I think I would be much more productive using one of the test servers in the infrastructure as this way I could actually test against the different openid consumers "in the wild". I've already applied to sysadmin-test and am now going to apply to sysadmin as these seem to be the required steps. Please sponsor me :) Thank you! From a.badger at gmail.com Tue Apr 7 13:39:18 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 07 Apr 2009 06:39:18 -0700 Subject: sysadmin sponsoring In-Reply-To: <49DB4AEC.5060000@lavabit.com> References: <49DB4AEC.5060000@lavabit.com> Message-ID: <49DB5786.2000007@gmail.com> Ionu? Ar??ri?i wrote: > Hello, > > I've recently become interested in the openid part of FAS and have > already setup a server on my laptop and began hacking. > > However, I think I would be much more productive using one of the test > servers in the infrastructure as this way I could actually test against > the different openid consumers "in the wild". > > I've already applied to sysadmin-test and am now going to apply to > sysadmin as these seem to be the required steps. > Please sponsor me :) > I'll sponsor you. This is certainly a good thing to look into. You'll have sudo access on the publictest machines. I believe that publictest15 has a test fas instance running. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From anvv.fedora at gmail.com Tue Apr 7 15:08:22 2009 From: anvv.fedora at gmail.com (Angel Natan Villegas Vicencio) Date: Tue, 7 Apr 2009 10:08:22 -0500 Subject: My skills Message-ID: Hi every body i want to join to the fedora infrastructure team, add something of my skills - System Administrator on RedHat 7.3, RedHat Advanced Server 2.1, RedHat Enterprise Linux 3, RedHat Enterprise Linux 4, RedHat Enterprise Linux 5, - Configurations and Installations of Redhat servers through PXE and kickstars files - Configurations of yum repositories for provisioning redhat servers ( 2.1, 3, 4, and 5 ) - LVM Filesystems - Bash Scripting - Technical Management of network services on Redhat (Radius, DNS, DHCP, LDAP, Postfix,) - Technical Management on VMware Server and Xen. - Backup Administrator in tape library MSL6000 with Omniback II. - Storage Administrator in Storage Strategies with EVA500 - Monitoring Administrator with Nagios, open source tool. - Technical knowledge on IBM and HP Hardware such as Blade Servers HS21(IBM), xSeries 3250-3850 (IBM), Blades Server BL20PG2 (HP), DL360 G2 , DL380 G2 , DL580 G2 (HP). - Firewall and VPNs Administrator on Netscreen Appliance Thank you ever body ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Tue Apr 7 15:57:22 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 7 Apr 2009 10:57:22 -0500 (CDT) Subject: RFR: triageweb In-Reply-To: <20090407052852.GC15860@sphe.res.cmu.edu> References: <981da310904061137y917e57chb4a1cb73770e70b0@mail.gmail.com> <20090407052852.GC15860@sphe.res.cmu.edu> Message-ID: On Tue, 7 Apr 2009, Ricky Zhou wrote: > On 2009-04-06 06:37:59 PM, Brennan Ashton wrote: > > ==Project Info== > > Project Name: TriageWeb > > Target Audience: Bug Triagers, Developers, Quality Assurance. To some > > extent this might include the general public, as a way to see how > > fedora is managing bugs and developing. > > Expiration/Delivery Date (Required): 06/06/2009 > I'd be happy to sponsor this - can somebody please approve bashton into > sysadmin-test? > Ricky, I've upgraded you to sponsor status for that group, you can sponsor him if someone else has not already. -Mike From mmcgrath at redhat.com Tue Apr 7 15:59:49 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 7 Apr 2009 10:59:49 -0500 (CDT) Subject: My skills In-Reply-To: References: Message-ID: On Tue, 7 Apr 2009, Angel Natan Villegas Vicencio wrote: > > Hi every body i want to join to the fedora infrastructure team, add something of my skills > > - System Administrator on RedHat 7.3, RedHat Advanced Server 2.1, RedHat Enterprise Linux 3, ?RedHat Enterprise Linux 4, > RedHat Enterprise Linux 5, > > - Configurations and Installations of Redhat servers through PXE and kickstars files > > - Configurations of yum repositories for provisioning redhat servers ( 2.1, 3, 4, and 5 ) > > - LVM Filesystems > > - Bash Scripting? > > - Technical Management of network services on Redhat (Radius, DNS, DHCP, LDAP, Postfix,) > > - Technical Management on VMware Server and Xen. > > - Backup Administrator in tape library MSL6000 with Omniback II. > > - Storage Administrator in Storage Strategies with EVA500 > > - Monitoring Administrator with Nagios, open source tool. > > - Technical knowledge on IBM and HP Hardware such as Blade Servers HS21(IBM), xSeries 3250-3850 (IBM), Blades Server > BL20PG2 (HP), DL360 G2 , DL380 G2 , DL580 G2 (HP). > > - Firewall and VPNs Administrator on Netscreen Appliance > Welcome Angel, please do participate on the list and online. And if you are available come to the meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings Was there anything in particular you were interested in working on? -Mike From anvv.fedora at gmail.com Tue Apr 7 16:52:29 2009 From: anvv.fedora at gmail.com (Angel Natan Villegas Vicencio) Date: Tue, 7 Apr 2009 11:52:29 -0500 Subject: My skills In-Reply-To: References: Message-ID: I think i can start in something like sysadmin-builds, and have some experience in sysamdin-noc, but i'm available for anything that you need. Thanks 2009/4/7 Mike McGrath > On Tue, 7 Apr 2009, Angel Natan Villegas Vicencio wrote: > > > > > Hi every body i want to join to the fedora infrastructure team, add > something of my skills > > > > - System Administrator on RedHat 7.3, RedHat Advanced Server 2.1, RedHat > Enterprise Linux 3, RedHat Enterprise Linux 4, > > RedHat Enterprise Linux 5, > > > > - Configurations and Installations of Redhat servers through PXE and > kickstars files > > > > - Configurations of yum repositories for provisioning redhat servers ( > 2.1, 3, 4, and 5 ) > > > > - LVM Filesystems > > > > - Bash Scripting > > > > - Technical Management of network services on Redhat (Radius, DNS, DHCP, > LDAP, Postfix,) > > > > - Technical Management on VMware Server and Xen. > > > > - Backup Administrator in tape library MSL6000 with Omniback II. > > > > - Storage Administrator in Storage Strategies with EVA500 > > > > - Monitoring Administrator with Nagios, open source tool. > > > > - Technical knowledge on IBM and HP Hardware such as Blade Servers > HS21(IBM), xSeries 3250-3850 (IBM), Blades Server > > BL20PG2 (HP), DL360 G2 , DL380 G2 , DL580 G2 (HP). > > > > - Firewall and VPNs Administrator on Netscreen Appliance > > > > Welcome Angel, please do participate on the list and online. And if you > are available come to the meetings: > > http://fedoraproject.org/wiki/Infrastructure/Meetings > > Was there anything in particular you were interested in working on? > > -Mike > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Tue Apr 7 16:57:05 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 7 Apr 2009 11:57:05 -0500 (CDT) Subject: Bastion changes Message-ID: I'm making some changes to bastion today, I'm going to drop it's interface sometime this afternoon which will kill any of your connections on it. I'll also be testing some failure scenarios. Stay tuned in #fedora-admin if you think this affects you. -Mike From stardust496 at gmail.com Wed Apr 8 05:37:06 2009 From: stardust496 at gmail.com (Mayuresh Kulkarni) Date: Wed, 8 Apr 2009 01:37:06 -0400 Subject: Introduction Message-ID: Hello folks, I have been a fedora user for a couple of months now and I would like to thank you all for this wonderful distro! About me - I am a programmer, working mostly in the systems programming domain. I am quite comfortable with C/C++ but not so much with Python or with bash scripting. I would like to help out with something where I can pick up one of these two. I have done projects with Python, (mostly to avoid Perl ;) ) , but am far from being a native. I unfortunately will not be able to attend the meetings on Thursday but I will hang out in IRC to try to get a feel for the current action. Looking forward to meeting you all :) Mayuresh. From mmcgrath at redhat.com Wed Apr 8 20:14:59 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 8 Apr 2009 15:14:59 -0500 (CDT) Subject: 3 commits - configs/fas configs/system configs/web manifests/nodes manifests/servergroups manifests/services modules/fas (fwd) Message-ID: This commit was a bit nuts and touches everything. We tested it in staging without issue. This push to production should be fine but as always keep your eyes open. Not much 'changed' it's just fas is now a module. -Mike ---------- Forwarded message ---------- Date: Wed, 8 Apr 2009 15:08:54 From: Mike McGrath To: sysadmin-members at fedoraproject.org Subject: 3 commits - configs/fas configs/system configs/web manifests/nodes manifests/servergroups manifests/services modules/fas configs/fas/fasSync | 1 configs/fas/nsswitch.conf | 45 - configs/system/export-bugzilla.cfg.erb | 11 configs/system/export-bugzilla.py | 68 -- configs/system/fas.conf.erb | 78 --- configs/web/accounts-proxy.conf | 12 configs/web/accounts.fedoraproject.org.conf | 13 configs/web/accounts.fedoraproject.org/logs.conf | 2 configs/web/accounts.fedoraproject.org/redirect.conf | 1 configs/web/applications/Makefile.fedora-ca | 70 -- configs/web/applications/accounts.conf | 26 - configs/web/applications/certhelper.py | 280 ----------- configs/web/applications/fas-log.cfg | 29 - configs/web/applications/fas-prod.cfg.erb | 163 ------ configs/web/applications/fas.wsgi | 50 -- configs/web/applications/fedora-ca-client-openssl.cnf | 317 ------------- configs/web/fas.fedoraproject.org.conf | 13 configs/web/fas.fedoraproject.org/logs.conf | 2 configs/web/fas.fedoraproject.org/redirect.conf | 1 dev/null |binary manifests/nodes/app1.stg.fedora.phx.redhat.com.pp | 2 manifests/nodes/backup2.fedoraproject.org.pp | 2 manifests/nodes/bu1.fedoraproject.org.pp | 2 manifests/nodes/buildsys.fedoraproject.org.pp | 2 manifests/nodes/cstore1.fedoraproject.org.pp | 2 manifests/nodes/cstore2.fedoraproject.org.pp | 2 manifests/nodes/db1.stg.fedora.phx.redhat.com.pp | 2 manifests/nodes/fas1.fedora.phx.redhat.com.pp | 2 manifests/nodes/ibiblio1.fedoraproject.org.pp | 2 manifests/nodes/kojipkgs1.fedora.phx.redhat.com.pp | 2 manifests/nodes/kojipkgs2.fedora.phx.redhat.com.pp | 2 manifests/nodes/lb1.fedora.phx.redhat.com.pp | 2 manifests/nodes/lb2.fedora.phx.redhat.com.pp | 2 manifests/nodes/log1.fedora.phx.redhat.com.pp | 2 manifests/nodes/nfs1.fedora.phx.redhat.com.pp | 2 manifests/nodes/nfs2.fedora.phx.redhat.com.pp | 2 manifests/nodes/noc2.fedoraproject.org.pp | 2 manifests/nodes/ns1.fedoraproject.org.pp | 2 manifests/nodes/ns2.fedoraproject.org.pp | 2 manifests/nodes/people1.fedoraproject.org.pp | 2 manifests/nodes/proxy1.stg.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest10.fedoraproject.org.pp | 2 manifests/nodes/publictest12.fedoraproject.org.pp | 2 manifests/nodes/publictest13.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest14.fedoraproject.org.pp | 2 manifests/nodes/publictest15.fedoraproject.org.pp | 2 manifests/nodes/publictest16.fedoraproject.org.pp | 2 manifests/nodes/publictest2.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest3.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest4.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest5.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest6.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest7.fedora.phx.redhat.com.pp | 2 manifests/nodes/publictest9.fedora.phx.redhat.com.pp | 2 manifests/nodes/qa1.fedora.phx.redhat.com.pp | 2 manifests/nodes/rawhide1.fedoraproject.org.pp | 2 manifests/nodes/releng1.fedora.phx.redhat.com.pp | 2 manifests/nodes/secondary1.fedora.phx.redhat.com.pp | 2 manifests/nodes/serverbeach1.fedoraproject.org.pp | 2 manifests/nodes/serverbeach2.fedoraproject.org.pp | 2 manifests/nodes/serverbeach3.fedoraproject.org.pp | 2 manifests/nodes/serverbeach4.fedoraproject.org.pp | 2 manifests/nodes/serverbeach5.fedoraproject.org.pp | 2 manifests/nodes/sign1.fedora.phx.redhat.com.pp | 2 manifests/nodes/sign2.fedora.phx.redhat.com.pp | 2 manifests/nodes/sign3.fedora.phx.redhat.com.pp | 2 manifests/nodes/smtp-mm1.fedoraproject.org.pp | 2 manifests/nodes/telia1.fedoraproject.org.pp | 2 manifests/nodes/test3.fedora.phx.redhat.com.pp | 2 manifests/nodes/test4.fedora.phx.redhat.com.pp | 2 manifests/nodes/test7.fedora.phx.redhat.com.pp | 2 manifests/nodes/test9.fedora.phx.redhat.com.pp | 2 manifests/nodes/torrent1.fedoraproject.org.pp | 2 manifests/nodes/tummy1.fedoraproject.org.pp | 2 manifests/nodes/xen6.fedora.phx.redhat.com.pp | 2 manifests/servergroups/appFcTest.pp | 2 manifests/servergroups/appRelEng.pp | 2 manifests/servergroups/appRhel.pp | 2 manifests/servergroups/appRhelTest.pp | 2 manifests/servergroups/asterisk.pp | 2 manifests/servergroups/build.pp | 2 manifests/servergroups/cnodes.pp | 2 manifests/servergroups/collab.pp | 2 manifests/servergroups/compose.pp | 2 manifests/servergroups/cvs.pp | 2 manifests/servergroups/db.pp | 2 manifests/servergroups/fas-server.pp | 6 manifests/servergroups/gateway.pp | 2 manifests/servergroups/hosted.pp | 2 manifests/servergroups/koji.pp | 2 manifests/servergroups/noc.pp | 2 manifests/servergroups/proxy.pp | 4 manifests/servergroups/puppet.pp | 2 manifests/servergroups/valueadd.pp | 2 manifests/servergroups/xen-server.pp | 2 manifests/services/fas.pp | 292 ----------- modules/fas/README | 10 modules/fas/files/Makefile.fedora-ca | 70 ++ modules/fas/files/accounts-proxy.conf | 11 modules/fas/files/accounts-pubring.gpg |binary modules/fas/files/accounts.conf | 26 + modules/fas/files/accounts.fedoraproject.org.conf | 13 modules/fas/files/accounts.fedoraproject.org/logs.conf | 2 modules/fas/files/accounts.fedoraproject.org/redirect.conf | 1 modules/fas/files/certhelper.py | 280 +++++++++++ modules/fas/files/export-bugzilla.py | 68 ++ modules/fas/files/fas-log.cfg | 29 + modules/fas/files/fas.fedoraproject.org.conf | 13 modules/fas/files/fas.fedoraproject.org/logs.conf | 2 modules/fas/files/fas.fedoraproject.org/redirect.conf | 1 modules/fas/files/fas.wsgi | 50 ++ modules/fas/files/fasSync | 1 modules/fas/files/fedora-ca-client-openssl.cnf | 317 +++++++++++++ modules/fas/files/nsswitch.conf | 45 + modules/fas/manifests/init.pp | 307 ++++++++++++ modules/fas/templates/export-bugzilla.cfg.erb | 11 modules/fas/templates/fas-prod.cfg.erb | 163 ++++++ modules/fas/templates/fas.conf.erb | 78 +++ 118 files changed, 1576 insertions(+), 1552 deletions(-) New commits: commit 58e9676244f0f543812dcb6c2723e532319ca512 Author: Mike McGrath Date: Wed Apr 8 20:08:51 2009 +0000 have all hosts use new fas module diff --git a/manifests/nodes/app1.stg.fedora.phx.redhat.com.pp b/manifests/nodes/app1.stg.fedora.phx.redhat.com.pp index 1f26375..3378a5d 100644 --- a/manifests/nodes/app1.stg.fedora.phx.redhat.com.pp +++ b/manifests/nodes/app1.stg.fedora.phx.redhat.com.pp @@ -6,7 +6,7 @@ node 'app1.stg.fedora.phx.redhat.com' { $groups='sysadmin-main' include phx include global - include fas + include fas::fas } 'staging' : { diff --git a/manifests/nodes/backup2.fedoraproject.org.pp b/manifests/nodes/backup2.fedoraproject.org.pp index f19d65b..da8216c 100644 --- a/manifests/nodes/backup2.fedoraproject.org.pp +++ b/manifests/nodes/backup2.fedoraproject.org.pp @@ -1,7 +1,7 @@ node backup2 { $groups='sysadmin-backup' include global - include fas + include fas::fas include vpn include backupPrivKey include scripts::drBackup diff --git a/manifests/nodes/bu1.fedoraproject.org.pp b/manifests/nodes/bu1.fedoraproject.org.pp index d30d71d..69f0602 100644 --- a/manifests/nodes/bu1.fedoraproject.org.pp +++ b/manifests/nodes/bu1.fedoraproject.org.pp @@ -2,6 +2,6 @@ node bu1{ $groups='@all' $relayHost = ' ' include global - include fas + include fas::fas include people } diff --git a/manifests/nodes/buildsys.fedoraproject.org.pp b/manifests/nodes/buildsys.fedoraproject.org.pp index 7f709fa..2580b66 100644 --- a/manifests/nodes/buildsys.fedoraproject.org.pp +++ b/manifests/nodes/buildsys.fedoraproject.org.pp @@ -1,7 +1,7 @@ node buildsys { $groups = 'sysadmin-main,sysadmin-build,epel_signers' include global - include fas + include fas::fas include ipmi include nagiosPhysical include plague::user-sync diff --git a/manifests/nodes/cstore1.fedoraproject.org.pp b/manifests/nodes/cstore1.fedoraproject.org.pp index 4cfb82b..93f2153 100644 --- a/manifests/nodes/cstore1.fedoraproject.org.pp +++ b/manifests/nodes/cstore1.fedoraproject.org.pp @@ -1,6 +1,6 @@ node cstore1{ $groups='sysadmin-main,sysadmin-cloud' - include fas + include fas::fas include vpn include dhcpserver-cloud # Firewall Rules, allow tftp diff --git a/manifests/nodes/cstore2.fedoraproject.org.pp b/manifests/nodes/cstore2.fedoraproject.org.pp index 0846147..f490863 100644 --- a/manifests/nodes/cstore2.fedoraproject.org.pp +++ b/manifests/nodes/cstore2.fedoraproject.org.pp @@ -1,6 +1,6 @@ node cstore2{ $groups='sysadmin-main,sysadmin-cloud' - include fas + include fas::fas include vpn # Firewall Rules, allow (nothing yet) $tcpPorts = [ ] diff --git a/manifests/nodes/db1.stg.fedora.phx.redhat.com.pp b/manifests/nodes/db1.stg.fedora.phx.redhat.com.pp index ce6778a..170e307 100644 --- a/manifests/nodes/db1.stg.fedora.phx.redhat.com.pp +++ b/manifests/nodes/db1.stg.fedora.phx.redhat.com.pp @@ -5,7 +5,7 @@ node "db1.stg.fedora.phx.redhat.com" { $groups='sysadmin-main' include phx include global - include fas + include fas::fas } 'staging' : { diff --git a/manifests/nodes/fas1.fedora.phx.redhat.com.pp b/manifests/nodes/fas1.fedora.phx.redhat.com.pp index a65248e..90d17b0 100644 --- a/manifests/nodes/fas1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/fas1.fedora.phx.redhat.com.pp @@ -1,5 +1,5 @@ node fas1{ include phx include fasServerGenCert - include fas-no-balance + include fas::fas-no-balance } diff --git a/manifests/nodes/ibiblio1.fedoraproject.org.pp b/manifests/nodes/ibiblio1.fedoraproject.org.pp index 3ce8c3d..a87bb3b 100644 --- a/manifests/nodes/ibiblio1.fedoraproject.org.pp +++ b/manifests/nodes/ibiblio1.fedoraproject.org.pp @@ -1,7 +1,7 @@ node ibiblio1{ $groups='sysadmin-main' include xen-server - include fas + include fas::fas include vpn } diff --git a/manifests/nodes/kojipkgs1.fedora.phx.redhat.com.pp b/manifests/nodes/kojipkgs1.fedora.phx.redhat.com.pp index 1dd226b..fa7d8fd 100644 --- a/manifests/nodes/kojipkgs1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/kojipkgs1.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node kojipkgs1{ $groups='sysadmin-main,sysadmin-build,sysadmin-noc' include phx include global - include fas + include fas::fas include kojipkgs include selinux diff --git a/manifests/nodes/kojipkgs2.fedora.phx.redhat.com.pp b/manifests/nodes/kojipkgs2.fedora.phx.redhat.com.pp index 3fbae4e..3bb9433 100644 --- a/manifests/nodes/kojipkgs2.fedora.phx.redhat.com.pp +++ b/manifests/nodes/kojipkgs2.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node kojipkgs2{ $groups='sysadmin-main,sysadmin-build,sysadmin-noc' include phx include global - include fas + include fas::fas include kojipkgs include selinux diff --git a/manifests/nodes/lb1.fedora.phx.redhat.com.pp b/manifests/nodes/lb1.fedora.phx.redhat.com.pp index baebda8..1351fde 100644 --- a/manifests/nodes/lb1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/lb1.fedora.phx.redhat.com.pp @@ -1,7 +1,7 @@ node lb1{ $groups='sysadmin-main,sysadmin-web' include phx - include fas + include fas::fas include global # Firewall Rules, allow OpenVPN traffic through diff --git a/manifests/nodes/lb2.fedora.phx.redhat.com.pp b/manifests/nodes/lb2.fedora.phx.redhat.com.pp index 0b30286..a4e8658 100644 --- a/manifests/nodes/lb2.fedora.phx.redhat.com.pp +++ b/manifests/nodes/lb2.fedora.phx.redhat.com.pp @@ -1,7 +1,7 @@ node lb2{ $groups='sysadmin-main,sysadmin-web' include phx - include fas + include fas::fas include global # Firewall Rules, allow OpenVPN traffic through $tcpPorts = [ 80, 443, 5560 ] diff --git a/manifests/nodes/log1.fedora.phx.redhat.com.pp b/manifests/nodes/log1.fedora.phx.redhat.com.pp index b615389..9198af2 100644 --- a/manifests/nodes/log1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/log1.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node log1{ $groups='sysadmin-main,sysadmin-noc' $rsyslog=1 include global - include fas + include fas::fas include phx include vpn include awstats diff --git a/manifests/nodes/nfs1.fedora.phx.redhat.com.pp b/manifests/nodes/nfs1.fedora.phx.redhat.com.pp index 7f39b70..3ca425f 100644 --- a/manifests/nodes/nfs1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/nfs1.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node nfs1{ $groups='sysadmin-main,sysadmin-noc' include phx include global - include fas + include fas::fas include nfs-server include nfs-server-phx include selinux diff --git a/manifests/nodes/nfs2.fedora.phx.redhat.com.pp b/manifests/nodes/nfs2.fedora.phx.redhat.com.pp index f3be815..994b491 100644 --- a/manifests/nodes/nfs2.fedora.phx.redhat.com.pp +++ b/manifests/nodes/nfs2.fedora.phx.redhat.com.pp @@ -1,6 +1,6 @@ node nfs2{ $groups='sysadmin-main' include phx - include fas + include fas::fas } diff --git a/manifests/nodes/noc2.fedoraproject.org.pp b/manifests/nodes/noc2.fedoraproject.org.pp index 55bc2fa..51aaa3b 100644 --- a/manifests/nodes/noc2.fedoraproject.org.pp +++ b/manifests/nodes/noc2.fedoraproject.org.pp @@ -2,7 +2,7 @@ node noc2{ $groups='sysadmin-main,sysadmin-noc' $relayHost=' ' include global - include fas + include fas::fas include vpn include nagios-server-external include pager diff --git a/manifests/nodes/ns1.fedoraproject.org.pp b/manifests/nodes/ns1.fedoraproject.org.pp index 94fae20..624f5da 100644 --- a/manifests/nodes/ns1.fedoraproject.org.pp +++ b/manifests/nodes/ns1.fedoraproject.org.pp @@ -1,7 +1,7 @@ node ns1{ $groups = 'sysadmin-main' include global - include fas + include fas::fas include dns } diff --git a/manifests/nodes/ns2.fedoraproject.org.pp b/manifests/nodes/ns2.fedoraproject.org.pp index fa6c738..91998e0 100644 --- a/manifests/nodes/ns2.fedoraproject.org.pp +++ b/manifests/nodes/ns2.fedoraproject.org.pp @@ -1,7 +1,7 @@ node ns2{ $groups = 'sysadmin-main' include global - include fas + include fas::fas include dns } diff --git a/manifests/nodes/people1.fedoraproject.org.pp b/manifests/nodes/people1.fedoraproject.org.pp index cb35312..ef49bc8 100644 --- a/manifests/nodes/people1.fedoraproject.org.pp +++ b/manifests/nodes/people1.fedoraproject.org.pp @@ -4,7 +4,7 @@ node people1 { $sshd_config_PasswordAuthentication='no' include global include people - include fas + include fas::fas include vpn include planet } diff --git a/manifests/nodes/proxy1.stg.fedora.phx.redhat.com.pp b/manifests/nodes/proxy1.stg.fedora.phx.redhat.com.pp index 48d86e5..90369ae 100644 --- a/manifests/nodes/proxy1.stg.fedora.phx.redhat.com.pp +++ b/manifests/nodes/proxy1.stg.fedora.phx.redhat.com.pp @@ -5,7 +5,7 @@ node 'proxy1.stg.fedora.phx.redhat.com' { $groups='sysadmin-main' include phx include global - include fas + include fas::fas } 'staging' : { $puppetEnvironment='staging' diff --git a/manifests/nodes/publictest10.fedoraproject.org.pp b/manifests/nodes/publictest10.fedoraproject.org.pp index 3992b56..5fbbd61 100644 --- a/manifests/nodes/publictest10.fedoraproject.org.pp +++ b/manifests/nodes/publictest10.fedoraproject.org.pp @@ -2,7 +2,7 @@ node publictest10{ $groups='sysadmin-main,sysadmin-test,sysadmin-noc' include ssh::sshd include httpd - include fas + include fas::fas include global include selinux include git-package diff --git a/manifests/nodes/publictest12.fedoraproject.org.pp b/manifests/nodes/publictest12.fedoraproject.org.pp index 12e6b66..7cdded4 100644 --- a/manifests/nodes/publictest12.fedoraproject.org.pp +++ b/manifests/nodes/publictest12.fedoraproject.org.pp @@ -1,6 +1,6 @@ node publictest12{ $groups = 'sysadmin-main,sysadmin-test,sysadmin-noc' - include fas + include fas::fas include global $tcpPorts = [ 80, 443 ] $udpPorts = [ ] diff --git a/manifests/nodes/publictest13.fedora.phx.redhat.com.pp b/manifests/nodes/publictest13.fedora.phx.redhat.com.pp index 1c5bb08..a960671 100644 --- a/manifests/nodes/publictest13.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest13.fedora.phx.redhat.com.pp @@ -1,6 +1,6 @@ node publictest13{ $groups='sysadmin-main,sysadmin-test,sysadmin-noc' include global - include fas + include fas::fas } diff --git a/manifests/nodes/publictest14.fedoraproject.org.pp b/manifests/nodes/publictest14.fedoraproject.org.pp index 9fc8c05..e5c353c 100644 --- a/manifests/nodes/publictest14.fedoraproject.org.pp +++ b/manifests/nodes/publictest14.fedoraproject.org.pp @@ -1,7 +1,7 @@ node publictest14{ $relayHost=' ' $groups = 'sysadmin-main,sysadmin-test,sysadmin-noc,sysadmin-test' - include fas + include fas::fas include global $tcpPorts = [ 80, 443 ] $udpPorts = [ ] diff --git a/manifests/nodes/publictest15.fedoraproject.org.pp b/manifests/nodes/publictest15.fedoraproject.org.pp index cd2d98d..54d6821 100644 --- a/manifests/nodes/publictest15.fedoraproject.org.pp +++ b/manifests/nodes/publictest15.fedoraproject.org.pp @@ -3,7 +3,7 @@ node publictest15{ $groups='sysadmin-main,sysadmin-test,sysadmin-noc' include ssh::sshd include httpd - include fas + include fas::fas include bodhi-dev include global include selinux diff --git a/manifests/nodes/publictest16.fedoraproject.org.pp b/manifests/nodes/publictest16.fedoraproject.org.pp index 7b85ddf..6b9b0c3 100644 --- a/manifests/nodes/publictest16.fedoraproject.org.pp +++ b/manifests/nodes/publictest16.fedoraproject.org.pp @@ -2,7 +2,7 @@ node publictest16{ $groups='sysadmin-main,sysadmin-test,sysadmin-noc' include ssh::sshd include httpd - include fas + include fas::fas include bodhi-dev include global include selinux diff --git a/manifests/nodes/publictest2.fedora.phx.redhat.com.pp b/manifests/nodes/publictest2.fedora.phx.redhat.com.pp index 91fdaaf..d224e45 100644 --- a/manifests/nodes/publictest2.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest2.fedora.phx.redhat.com.pp @@ -2,6 +2,6 @@ node publictest2{ $groups='sysadmin-test,sysadmin-main,sysadmin-web' include phx include global - include fas + include fas::fas } diff --git a/manifests/nodes/publictest3.fedora.phx.redhat.com.pp b/manifests/nodes/publictest3.fedora.phx.redhat.com.pp index 207b27b..9e9f235 100644 --- a/manifests/nodes/publictest3.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest3.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node publictest3{ $groups='sysadmin-main,sysadmin-test,sysadmin-noc' include phx include xen-guest - include fas + include fas::fas #Include php.ini & apache... include apache::php diff --git a/manifests/nodes/publictest4.fedora.phx.redhat.com.pp b/manifests/nodes/publictest4.fedora.phx.redhat.com.pp index af6052a..ccc6ff1 100644 --- a/manifests/nodes/publictest4.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest4.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node publictest4{ $groups = 'sysadmin-main,sysadmin-test,sysadmin-noc' include phx include xen-guest - include fas + include fas::fas # Firewall Rules, allow SSH, SIP(TCP 5060), IAX2(UDP 4569), SIP(UDP 5060), RTP(UDP 10000:10500) $tcpPorts = [ 22, 5060 ] $udpPorts = [ 4569, 5060, '10000:10500' ] diff --git a/manifests/nodes/publictest5.fedora.phx.redhat.com.pp b/manifests/nodes/publictest5.fedora.phx.redhat.com.pp index 2378109..3f9880a 100644 --- a/manifests/nodes/publictest5.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest5.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node publictest5{ $groups = 'sysadmin-main,sysadmin-test,sysadmin-noc' include phx include xen-guest - include fas + include fas::fas # Firewall Rules, allow HTTP (TCP 80), HTTPS (TCP 443), SSH, SIP(TCP 5060), IAX2(UDP 4569), SIP(UDP 5060), RTP(UDP 10000:10500) $tcpPorts = [ 22, 80, 443, 5060 ] $udpPorts = [ 4569, 5060, '10000:10500' ] diff --git a/manifests/nodes/publictest6.fedora.phx.redhat.com.pp b/manifests/nodes/publictest6.fedora.phx.redhat.com.pp index d8bd031..5ff6931 100644 --- a/manifests/nodes/publictest6.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest6.fedora.phx.redhat.com.pp @@ -3,6 +3,6 @@ node publictest6{ $groups = 'sysadmin-main' include phx include xen-guest - include fas + include fas::fas } diff --git a/manifests/nodes/publictest7.fedora.phx.redhat.com.pp b/manifests/nodes/publictest7.fedora.phx.redhat.com.pp index 257dce5..df44bea 100644 --- a/manifests/nodes/publictest7.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest7.fedora.phx.redhat.com.pp @@ -3,6 +3,6 @@ node publictest7{ $groups = 'sysadmin-main' include phx include xen-guest - include fas + include fas::fas } diff --git a/manifests/nodes/publictest9.fedora.phx.redhat.com.pp b/manifests/nodes/publictest9.fedora.phx.redhat.com.pp index 3d91c12..42819b0 100644 --- a/manifests/nodes/publictest9.fedora.phx.redhat.com.pp +++ b/manifests/nodes/publictest9.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node publictest9{ $groups='sysadmin-main,sysadmin-test,sysadmin-noc' include phx include xen-guest - include fas + include fas::fas include mediawiki-test::base $tcpPorts = [ 80, 443, 10050, 11211 ] diff --git a/manifests/nodes/qa1.fedora.phx.redhat.com.pp b/manifests/nodes/qa1.fedora.phx.redhat.com.pp index cc3053b..2e5bf19 100644 --- a/manifests/nodes/qa1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/qa1.fedora.phx.redhat.com.pp @@ -1,7 +1,7 @@ node qa1{ $groups='sysadmin-main,sysadmin-noc,qa-admin' include phx - include fas + include fas::fas include global include git-package include fedora-packager-package diff --git a/manifests/nodes/rawhide1.fedoraproject.org.pp b/manifests/nodes/rawhide1.fedoraproject.org.pp index dc480eb..7377f7d 100644 --- a/manifests/nodes/rawhide1.fedoraproject.org.pp +++ b/manifests/nodes/rawhide1.fedoraproject.org.pp @@ -1,7 +1,7 @@ node 'rawhide1.fedoraproject.org' { $relayHost=' ' $groups = 'sysadmin-main,sysadmin-noc' - include fas + include fas::fas include global } diff --git a/manifests/nodes/releng1.fedora.phx.redhat.com.pp b/manifests/nodes/releng1.fedora.phx.redhat.com.pp index 60dd139..ad60c71 100644 --- a/manifests/nodes/releng1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/releng1.fedora.phx.redhat.com.pp @@ -1,6 +1,6 @@ node releng1{ $groups='sysadmin-main,sysadmin-releng,sysadmin-noc' include phx - include fas + include fas::fas include global } diff --git a/manifests/nodes/secondary1.fedora.phx.redhat.com.pp b/manifests/nodes/secondary1.fedora.phx.redhat.com.pp index d87ad82..0b98229 100644 --- a/manifests/nodes/secondary1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/secondary1.fedora.phx.redhat.com.pp @@ -1,7 +1,7 @@ node secondary1{ $groups='sysadmin-main,sysadmin-noc,alt-sugar,alt-k12linux,altvideos' include global - include fas + include fas::fas include secondaryMirror include nfs-server include selinux diff --git a/manifests/nodes/serverbeach1.fedoraproject.org.pp b/manifests/nodes/serverbeach1.fedoraproject.org.pp index 3fffa23..295ea48 100644 --- a/manifests/nodes/serverbeach1.fedoraproject.org.pp +++ b/manifests/nodes/serverbeach1.fedoraproject.org.pp @@ -1,7 +1,7 @@ node serverbeach1{ $groups = 'sysadmin-main' include global - include fas + include fas::fas include vpn include xenHost include ipmi diff --git a/manifests/nodes/serverbeach2.fedoraproject.org.pp b/manifests/nodes/serverbeach2.fedoraproject.org.pp index 6a7d8fd..8a759ff 100644 --- a/manifests/nodes/serverbeach2.fedoraproject.org.pp +++ b/manifests/nodes/serverbeach2.fedoraproject.org.pp @@ -1,7 +1,7 @@ node serverbeach2{ $groups = 'sysadmin-main' include global - include fas + include fas::fas include vpn include xenHost include ipmi diff --git a/manifests/nodes/serverbeach3.fedoraproject.org.pp b/manifests/nodes/serverbeach3.fedoraproject.org.pp index 018ecf1..4338551 100644 --- a/manifests/nodes/serverbeach3.fedoraproject.org.pp +++ b/manifests/nodes/serverbeach3.fedoraproject.org.pp @@ -1,7 +1,7 @@ node serverbeach3{ $groups = 'sysadmin-main' include global - include fas + include fas::fas include vpn include xenHost include ipmi diff --git a/manifests/nodes/serverbeach4.fedoraproject.org.pp b/manifests/nodes/serverbeach4.fedoraproject.org.pp index f855620..ac878e6 100644 --- a/manifests/nodes/serverbeach4.fedoraproject.org.pp +++ b/manifests/nodes/serverbeach4.fedoraproject.org.pp @@ -1,7 +1,7 @@ node serverbeach4{ $groups = 'sysadmin-main' include global - include fas + include fas::fas include vpn include xenHost include ipmi diff --git a/manifests/nodes/serverbeach5.fedoraproject.org.pp b/manifests/nodes/serverbeach5.fedoraproject.org.pp index c4a1088..1776e8d 100644 --- a/manifests/nodes/serverbeach5.fedoraproject.org.pp +++ b/manifests/nodes/serverbeach5.fedoraproject.org.pp @@ -1,7 +1,7 @@ node serverbeach5{ $groups = 'sysadmin-main' include global - include fas + include fas::fas include vpn include xenHost include ipmi diff --git a/manifests/nodes/sign1.fedora.phx.redhat.com.pp b/manifests/nodes/sign1.fedora.phx.redhat.com.pp index e383736..d77ad31 100644 --- a/manifests/nodes/sign1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/sign1.fedora.phx.redhat.com.pp @@ -4,7 +4,7 @@ node sign1{ $groups = 'sysadmin-main,sysadmin-releng' include phx - include fas + include fas::fas #include global include pkgsigner diff --git a/manifests/nodes/sign2.fedora.phx.redhat.com.pp b/manifests/nodes/sign2.fedora.phx.redhat.com.pp index 3ca66e4..7620e80 100644 --- a/manifests/nodes/sign2.fedora.phx.redhat.com.pp +++ b/manifests/nodes/sign2.fedora.phx.redhat.com.pp @@ -1,7 +1,7 @@ node sign2{ $groups = 'sysadmin-main' include phx - include fas + include fas::fas include global include pkgsigner } diff --git a/manifests/nodes/sign3.fedora.phx.redhat.com.pp b/manifests/nodes/sign3.fedora.phx.redhat.com.pp index 2bafff9..18a4323 100644 --- a/manifests/nodes/sign3.fedora.phx.redhat.com.pp +++ b/manifests/nodes/sign3.fedora.phx.redhat.com.pp @@ -1,7 +1,7 @@ node sign3{ $groups = 'sysadmin-main' include phx - include fas + include fas::fas include global include pkgsigner } diff --git a/manifests/nodes/smtp-mm1.fedoraproject.org.pp b/manifests/nodes/smtp-mm1.fedoraproject.org.pp index c9c53c8..d5ad7fb 100644 --- a/manifests/nodes/smtp-mm1.fedoraproject.org.pp +++ b/manifests/nodes/smtp-mm1.fedoraproject.org.pp @@ -2,7 +2,7 @@ node smtp-mm1{ $groups = 'sysadmin-main,sysadmin-noc,sysadmin-tools' $isMailmanSMTP=1 include global - include fas + include fas::fas include postfix::mailman_smtp # Firewall Rules, allow SMTP traffic through diff --git a/manifests/nodes/telia1.fedoraproject.org.pp b/manifests/nodes/telia1.fedoraproject.org.pp index 4e8433d..8035a27 100644 --- a/manifests/nodes/telia1.fedoraproject.org.pp +++ b/manifests/nodes/telia1.fedoraproject.org.pp @@ -1,7 +1,7 @@ node telia1{ $groups='sysadmin-main' include xen-server - include fas + include fas::fas include vpn } diff --git a/manifests/nodes/test3.fedora.phx.redhat.com.pp b/manifests/nodes/test3.fedora.phx.redhat.com.pp index 303b1c3..0107987 100644 --- a/manifests/nodes/test3.fedora.phx.redhat.com.pp +++ b/manifests/nodes/test3.fedora.phx.redhat.com.pp @@ -1,6 +1,6 @@ node test3{ $groups='sysadmin-main,sysadmin-releng' - include fas + include fas::fas include phx include xen-guest } diff --git a/manifests/nodes/test4.fedora.phx.redhat.com.pp b/manifests/nodes/test4.fedora.phx.redhat.com.pp index d405088..bda764f 100644 --- a/manifests/nodes/test4.fedora.phx.redhat.com.pp +++ b/manifests/nodes/test4.fedora.phx.redhat.com.pp @@ -1,6 +1,6 @@ node test4{ $groups='sysadmin-main,sysadmin-releng' - include fas + include fas::fas include phx include xen-guest } diff --git a/manifests/nodes/test7.fedora.phx.redhat.com.pp b/manifests/nodes/test7.fedora.phx.redhat.com.pp index 414143a..62b6078 100644 --- a/manifests/nodes/test7.fedora.phx.redhat.com.pp +++ b/manifests/nodes/test7.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node test7{ $groups='sysadmin-main,sysadmin-test,sysadmin-noc' include phx include xen-guest - include fas + include fas::fas include fedoraproject-moin } diff --git a/manifests/nodes/test9.fedora.phx.redhat.com.pp b/manifests/nodes/test9.fedora.phx.redhat.com.pp index 4eaae80..c6d655f 100644 --- a/manifests/nodes/test9.fedora.phx.redhat.com.pp +++ b/manifests/nodes/test9.fedora.phx.redhat.com.pp @@ -2,6 +2,6 @@ node test9{ $groups = 'sysadmin-main,sysadmin-test,sysadmin-noc' include phx include xen-guest - include fas + include fas::fas } diff --git a/manifests/nodes/torrent1.fedoraproject.org.pp b/manifests/nodes/torrent1.fedoraproject.org.pp index 8b11de1..afb7e31 100644 --- a/manifests/nodes/torrent1.fedoraproject.org.pp +++ b/manifests/nodes/torrent1.fedoraproject.org.pp @@ -1,6 +1,6 @@ node torrent1{ $groups = 'sysadmin-web,sysadmin-main,torrentadmin,sysadmin-noc,torrent-cc' include global - include fas + include fas::fas include torrent } diff --git a/manifests/nodes/tummy1.fedoraproject.org.pp b/manifests/nodes/tummy1.fedoraproject.org.pp index 357637a..ff41f41 100644 --- a/manifests/nodes/tummy1.fedoraproject.org.pp +++ b/manifests/nodes/tummy1.fedoraproject.org.pp @@ -1,7 +1,7 @@ node tummy1{ $groups='sysadmin-main' include xen-server - include fas + include fas::fas include vpn } diff --git a/manifests/nodes/xen6.fedora.phx.redhat.com.pp b/manifests/nodes/xen6.fedora.phx.redhat.com.pp index 8d8767e..69ff929 100644 --- a/manifests/nodes/xen6.fedora.phx.redhat.com.pp +++ b/manifests/nodes/xen6.fedora.phx.redhat.com.pp @@ -2,7 +2,7 @@ node xen6{ include phx $groups = 'sysadmin-main,sysadmin-cloud' include global - include fas + include fas::fas include ipmi include nagiosPhysical include selinux diff --git a/manifests/servergroups/appFcTest.pp b/manifests/servergroups/appFcTest.pp index 70154d0..94e1dcd 100644 --- a/manifests/servergroups/appFcTest.pp +++ b/manifests/servergroups/appFcTest.pp @@ -2,7 +2,7 @@ class appFcTest { $groups = 'sysadmin-main,sysadmin-test,sysadmin-noc' include global include xen-guest - include fas + include fas::fas include dbaccess include mounts include wevisor-server diff --git a/manifests/servergroups/appRelEng.pp b/manifests/servergroups/appRelEng.pp index 8b4b790..c3bbf38 100644 --- a/manifests/servergroups/appRelEng.pp +++ b/manifests/servergroups/appRelEng.pp @@ -1,7 +1,7 @@ class appRelEng { $groups='sysadmin-main,sysadmin-noc,sysadmin-releng' include global - include fas + include fas::fas include xen-guest include mash include rsync::rsyncd diff --git a/manifests/servergroups/appRhel.pp b/manifests/servergroups/appRhel.pp index 0165f64..c8f85ef 100644 --- a/manifests/servergroups/appRhel.pp +++ b/manifests/servergroups/appRhel.pp @@ -3,7 +3,7 @@ class appRhel { include global include http_log include xen-guest - include fas + include fas::fas include dbaccess include pkgdb-server include bodhi-app diff --git a/manifests/servergroups/appRhelTest.pp b/manifests/servergroups/appRhelTest.pp index d68e275..ce4b633 100644 --- a/manifests/servergroups/appRhelTest.pp +++ b/manifests/servergroups/appRhelTest.pp @@ -2,7 +2,7 @@ class appRhelTest { $groups = 'sysadmin-main,sysadmin-test,sysadmin-noc' include global include xen-guest - include fas + include fas::fas include dbaccess-test #include genericContent #include hosted-server diff --git a/manifests/servergroups/asterisk.pp b/manifests/servergroups/asterisk.pp index 8f9ef9f..5d932fb 100644 --- a/manifests/servergroups/asterisk.pp +++ b/manifests/servergroups/asterisk.pp @@ -1,7 +1,7 @@ class asterisk { $groups = 'sysadmin-main,sysadmin-noc,sysadmin-tools' include global - include fas + include fas::fas include asterisk::main include asterisk::stats include asterisk::recording diff --git a/manifests/servergroups/build.pp b/manifests/servergroups/build.pp index 145ec65..abaccac 100644 --- a/manifests/servergroups/build.pp +++ b/manifests/servergroups/build.pp @@ -3,7 +3,7 @@ class build { $sshd_config_StrictModes = "no" include global # include generic-iptables - include fas + include fas::fas include koji include plague-builder include mockuser diff --git a/manifests/servergroups/cnodes.pp b/manifests/servergroups/cnodes.pp index 1934097..8670b60 100644 --- a/manifests/servergroups/cnodes.pp +++ b/manifests/servergroups/cnodes.pp @@ -1,6 +1,6 @@ class cnodes { $groups='sysadmin-main,sysadmin-cloud' - include fas + include fas::fas include vpn # Firewall Rules, allow tftp $tcpPorts = [ 3260 ] diff --git a/manifests/servergroups/collab.pp b/manifests/servergroups/collab.pp index 8b041b9..463ac9b 100644 --- a/manifests/servergroups/collab.pp +++ b/manifests/servergroups/collab.pp @@ -1,7 +1,7 @@ class collab { $groups = 'sysadmin-main,sysadmin-noc,sysadmin-tools' include global - include fas + include fas::fas include vpn include selinux include sobby diff --git a/manifests/servergroups/compose.pp b/manifests/servergroups/compose.pp index 9478a25..c29b9e0 100644 --- a/manifests/servergroups/compose.pp +++ b/manifests/servergroups/compose.pp @@ -3,7 +3,7 @@ class composer { $groups = 'sysadmin-main,sysadmin-releng' include global # include generic-iptables - include fas + include fas::fas include mockuser include pungi-package include livecd-tools-package diff --git a/manifests/servergroups/cvs.pp b/manifests/servergroups/cvs.pp index 8dc4038..9ae2c97 100644 --- a/manifests/servergroups/cvs.pp +++ b/manifests/servergroups/cvs.pp @@ -5,7 +5,7 @@ class cvs { $sshd_config_PasswordAuthentication = 'no' $sshd_config_AllowTcpForwarding = 'no' include global - include fas + include fas::fas include cvs-pkgs include rsync::rsyncd include drbackupPubKey diff --git a/manifests/servergroups/db.pp b/manifests/servergroups/db.pp index 43826cc..27fb1d3 100644 --- a/manifests/servergroups/db.pp +++ b/manifests/servergroups/db.pp @@ -1,7 +1,7 @@ class db { $groups = 'sysadmin-main,sysadmin-dba,sysadmin-noc' include global - include fas + include fas::fas include selinux include aide::scanner include backupPubKey diff --git a/manifests/servergroups/fas-server.pp b/manifests/servergroups/fas-server.pp index 3bfba90..6daed2a 100644 --- a/manifests/servergroups/fas-server.pp +++ b/manifests/servergroups/fas-server.pp @@ -2,7 +2,7 @@ class fasServerBase { $groups = 'sysadmin-main' include global include xen-guest - include fas + include fas::fas include vpn # Firewall Rules, allow web bodhi traffic through @@ -24,11 +24,11 @@ class fasServerBase { } class fasServer inherits fasServerBase { - include fas-server + include fas::fas-server } class fasServerGenCert inherits fasServerBase { - include fas-server-gencert + include fas::fas-server-gencert semanage_fcontext { '/var/lib/fedora-ca/crl(/.*)?': type => 'httpd_sys_script_rw_t' diff --git a/manifests/servergroups/gateway.pp b/manifests/servergroups/gateway.pp index d33ca7d..7a214b5 100644 --- a/manifests/servergroups/gateway.pp +++ b/manifests/servergroups/gateway.pp @@ -8,7 +8,7 @@ class gateway{ include global include snmp-utils include vpn-server - include fas + include fas::fas #include selinux-enforcing include selinux include spamassassin_server diff --git a/manifests/servergroups/hosted.pp b/manifests/servergroups/hosted.pp index 2708ced..eb9306b 100644 --- a/manifests/servergroups/hosted.pp +++ b/manifests/servergroups/hosted.pp @@ -6,7 +6,7 @@ class hosted { $sshd_config_AllowTcpForwarding = 'no' include global include hosted-server - include fas + include fas::fas # include hosted-proxy include rsync::rsyncd include selinux diff --git a/manifests/servergroups/koji.pp b/manifests/servergroups/koji.pp index 59477bd..d6801a8 100644 --- a/manifests/servergroups/koji.pp +++ b/manifests/servergroups/koji.pp @@ -1,7 +1,7 @@ class kojimasters { $groups = 'sysadmin-build,sysadmin-main,sysadmin-noc' include global - include fas + include fas::fas include kojimaster include selinux include nfs-server diff --git a/manifests/servergroups/noc.pp b/manifests/servergroups/noc.pp index c8f193d..d58e18d 100644 --- a/manifests/servergroups/noc.pp +++ b/manifests/servergroups/noc.pp @@ -1,7 +1,7 @@ class noc { $groups = 'sysadmin-main,sysadmin-noc' include global - include fas + include fas::fas include nagios-server include cacti-server include selinux diff --git a/manifests/servergroups/proxy.pp b/manifests/servergroups/proxy.pp index 6d9fb2b..85702ae 100644 --- a/manifests/servergroups/proxy.pp +++ b/manifests/servergroups/proxy.pp @@ -3,7 +3,7 @@ class proxy { include global include http_log include proxyserver - include fas + include fas::fas include autofs include haproxy::server include smolt-proxy @@ -19,7 +19,7 @@ class proxy { include admin-proxy include nagios-proxy include cacti-proxy - include fas-proxy + include fas::fas-proxy include infrastructure-proxy #include voting-proxy include pkgdb-proxy diff --git a/manifests/servergroups/puppet.pp b/manifests/servergroups/puppet.pp index c393f9a..4a7c5e5 100644 --- a/manifests/servergroups/puppet.pp +++ b/manifests/servergroups/puppet.pp @@ -3,7 +3,7 @@ class puppetServer { $is_certmaster=1 include global include phx - include fas + include fas::fas include infrastructure-repo include puppet::master include scripts::sync-rhn diff --git a/manifests/servergroups/valueadd.pp b/manifests/servergroups/valueadd.pp index 655f6d7..efebd55 100644 --- a/manifests/servergroups/valueadd.pp +++ b/manifests/servergroups/valueadd.pp @@ -3,7 +3,7 @@ class valueadd { include global include http_log include xen-guest - include fas + include fas::fas include dbaccess if $phx::inPHX { diff --git a/manifests/servergroups/xen-server.pp b/manifests/servergroups/xen-server.pp index 90086f7..c581b84 100644 --- a/manifests/servergroups/xen-server.pp +++ b/manifests/servergroups/xen-server.pp @@ -5,7 +5,7 @@ class xen-server { $groups = 'sysadmin-main' } include global - include fas + include fas::fas include xenHost include ipmi include nagiosPhysical commit 0687715af06ef76fa9288ca521e4daae37f19cb0 Author: Mike McGrath Date: Wed Apr 8 20:00:26 2009 +0000 removed old fas files diff --git a/configs/fas/fasSync b/configs/fas/fasSync deleted file mode 100644 index 4f9f643..0000000 --- a/configs/fas/fasSync +++ /dev/null @@ -1 +0,0 @@ -24 * * * * root /bin/sleep $(($RANDOM/20)); /usr/bin/fasClient -i > /dev/null 2>&1 diff --git a/configs/fas/nsswitch.conf b/configs/fas/nsswitch.conf deleted file mode 100644 index fb4ff62..0000000 --- a/configs/fas/nsswitch.conf +++ /dev/null @@ -1,45 +0,0 @@ -# /etc/nsswitch.conf -# -# An example Name Service Switch config file. This file should be -# sorted with the most-used services at the beginning. -# -# The entry '[NOTFOUND=return]' means that the search for an -# entry should stop if the search in the previous entry turned -# up nothing. Note that if the search failed due to some other reason -# (like no NIS server responding) then the search continues with the -# next entry. -# -# Legal entries are: -# -# nisplus or nis+ Use NIS+ (NIS version 3) -# nis or yp Use NIS (NIS version 2), also called YP -# dns Use DNS (Domain Name Service) -# files Use the local files -# db Use the local database (.db) files -# compat Use NIS on compat mode -# hesiod Use Hesiod for user lookups -# [NOTFOUND=return] Stop searching if not found so far -# - -passwd: db files -shadow: db files -group: db files - -#hosts: db files nisplus nis dns -hosts: files dns - -bootparams: nisplus [NOTFOUND=return] files - -ethers: files -netmasks: files -networks: files -protocols: files -rpc: files -services: files - -netgroup: files - -publickey: nisplus - -automount: files -aliases: files nisplus diff --git a/configs/system/export-bugzilla.cfg.erb b/configs/system/export-bugzilla.cfg.erb deleted file mode 100644 index 6c65f07..0000000 --- a/configs/system/export-bugzilla.cfg.erb +++ /dev/null @@ -1,11 +0,0 @@ -[global] -# bugzilla.url = https://bugdev.devel.redhat.com/bugzilla-cvs/xmlrpc.cgi -# Running from fas1 so we need the PHX available address. -bugzilla.url = "https://bzprx.vip.phx.redhat.com/xmlrpc.cgi" -# bugzilla.url = "https://bugzilla.redhat.com/xmlrpc.cgi" -bugzilla.username = "<%= bugzillaUser %>" -bugzilla.password = "<%= bugzillaPassword %>" - -# At the moment, we have to extract this information directly from the fas2 -# database. We can build a json interface for it at a later date. -sqlalchemy.dburi = "postgres://fas:<%= fasDbPassword %>@db2/fas2" diff --git a/configs/system/export-bugzilla.py b/configs/system/export-bugzilla.py deleted file mode 100755 index 4b6b416..0000000 --- a/configs/system/export-bugzilla.py +++ /dev/null @@ -1,68 +0,0 @@ -#!/usr/bin/python -t -__requires__ = 'TurboGears' -import pkg_resources -pkg_resources.require('CherryPy >= 2.0, < 3.0alpha') - -import sys -import getopt -import xmlrpclib -import turbogears -from turbogears import config -turbogears.update_config(configfile="/etc/export-bugzilla.cfg") -from turbogears.database import session -from fas.model import BugzillaQueue - -BZSERVER = config.get('bugzilla.url', 'https://bugdev.devel.redhat.com/bugzilla-cvs/xmlrpc.cgi') -BZUSER = config.get('bugzilla.username') -BZPASS = config.get('bugzilla.password') - -if __name__ == '__main__': - opts, args = getopt.getopt(sys.argv[1:], '', ('usage', 'help')) - if len(args) != 2 or ('--usage','') in opts or ('--help','') in opts: - print """ - Usage: export-bugzilla.py GROUP BUGZILLA_GROUP - """ - sys.exit(1) - ourGroup = args[0] - bzGroup = args[1] - - server = xmlrpclib.Server(BZSERVER) - bugzilla_queue = BugzillaQueue.query.join('group').filter_by( - name=ourGroup) - - for entry in bugzilla_queue: - # Make sure we have a record for this user in bugzilla - if entry.action == 'r': - # Remove the user's bugzilla group - try: - server.bugzilla.updatePerms(entry.email, 'rem', (bzGroup,), - BZUSER, BZPASS) - except xmlrpclib.Fault, e: - if e.faultCode == 504: - # It's okay, not having this user is equivalent to setting - # them to not have this group. - pass - else: - raise - - elif entry.action == 'a': - # Try to create the user - try: - server.bugzilla.addUser(entry.email, entry.person.human_name, BZUSER, BZPASS) - except xmlrpclib.Fault, e: - if e.faultCode == 500: - # It's okay, we just need to make sure the user has an - # account. - pass - else: - print entry.email,entry.person.human_name - raise - server.bugzilla.updatePerms(entry.email, 'add', (bzGroup,), - BZUSER, BZPASS) - else: - print 'Unrecognized action code: %s %s %s %s %s' % (entry.action, - entry.email, entry.person.human_name, entry.person.username, entry.group.name) - - # Remove them from the queue - session.delete(entry) - session.flush() diff --git a/configs/system/fas.conf.erb b/configs/system/fas.conf.erb deleted file mode 100644 index d8a3e05..0000000 --- a/configs/system/fas.conf.erb +++ /dev/null @@ -1,78 +0,0 @@ -[global] -; url - Location to fas server -url = https://admin.fedoraproject.org/accounts/ - -; temp - Location to generate files while user creation process is happening -temp = /var/db - -; login - username to contact fas -login = systems - -; password - password for login name -password = <%= systemsUserPassword %> - -; prefix - install to a location other than / -prefix = / - -[host] -; Group hierarchy is 1) groups, 2) restricted_groups 3) ssh_restricted_groups -; so if someone is in all 3, the client behaves the same as if they were just -; in 'groups' - -; groups that should have a shell account on this system. -<% if groups != "NONE" %> -groups = <%= groups %> -<% else %> -groups = sysadmin-main -<% end %> -; groups that should have a restricted account on this system. -; restricted accounts use the restricted_shell value in [users] -restricted_groups = - -; ssh_restricted_groups: groups that should be restricted by ssh key. You will -; need to disable password based logins in order for this value to have any -; security meaning. Group types can be placed here as well, for example -; @hg, at git, at svn -<% if sshGroups %> -ssh_restricted_groups = <%= sshGroups %> -<% else %> -ssh_restricted_groups = -<% end %> - -; aliases_template: Gets prepended to the aliases file when it is generated by -; fasClient -aliases_template = /etc/aliases.template - -[users] -; default shell given to people in [host] groups -shell = /bin/bash - -; home - the location for fas user home dirs -home = /home/fedora - -; home_backup_dir - Location home dirs should get moved to when a user is -; deleted this location should be tmpwatched -home_backup_dir = /home/fedora.bak - -; ssh_restricted_app - This is the path to the restricted shell script. It -; will not work automatically for most people though through alterations it -; is a powerfull way to restrict access to a machine. An alternative example -; could be given to people who should only have cvs access on the machine. -; setting this value to "/usr/bin/cvs server" would do this. -<% if restrictedApp %> -ssh_restricted_app = "<%= restrictedApp %>" -<% else %> -ssh_restricted_app = "/usr/bin/cvs server" -<% end %> - -; restricted_shell - The shell given to users in the ssh_restricted_groups -restricted_shell = /sbin/nologin - -; ssh_restricted_shell - The shell given to users in the ssh_restricted_groups -ssh_restricted_shell = /bin/bash - -; ssh_key_options - Options to be appended to people ssh keys. Users in the -; ssh_restricted_groups will have the keys they uploaded altered when they are -; installed on this machine, appended with the options below. -ssh_key_options = no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty - diff --git a/configs/web/accounts-proxy.conf b/configs/web/accounts-proxy.conf deleted file mode 100644 index 29c9de6..0000000 --- a/configs/web/accounts-proxy.conf +++ /dev/null @@ -1,12 +0,0 @@ -# fas1 is the only place for gencert right now -RewriteRule /accounts/user/gencert http://fas1/accounts/user/gencert [P] -RewriteRule /accounts/user/dogencert http://fas1/accounts/user/dogencert [P] -# pass ca requests on needed for CRL -ProxyPass /ca http://fas1/ca -ProxyPassReverse /ca http://fas1/ca - -#RewriteRule ^/accounts/(.*) balancer://accountsCluster/accounts/$1 [P] -#RewriteRule ^/accounts$ https://admin.fedoraproject.org/accounts/ [R,L] - -RewriteRule ^/accounts/(.*) http://localhost:10004/accounts/$1 [P] -RewriteRule ^/accounts$ https://admin.fedoraproject.org/accounts/ [R,L] diff --git a/configs/web/accounts.fedoraproject.org.conf b/configs/web/accounts.fedoraproject.org.conf deleted file mode 100644 index 1220803..0000000 --- a/configs/web/accounts.fedoraproject.org.conf +++ /dev/null @@ -1,13 +0,0 @@ -# proxy1 - 10.8.32.122 -# proxy2 - 10.8.32.121 -# proxy3 - 66.35.62.166 -# proxy4 - 152.46.7.222 -# proxy5 - 80.239.156.215 - - - - ServerName accounts.fedoraproject.org - ServerAdmin admin at fedoraproject.org - - include "conf.d/accounts.fedoraproject.org/*.conf - diff --git a/configs/web/accounts.fedoraproject.org/logs.conf b/configs/web/accounts.fedoraproject.org/logs.conf deleted file mode 100644 index 733e6e3..0000000 --- a/configs/web/accounts.fedoraproject.org/logs.conf +++ /dev/null @@ -1,2 +0,0 @@ -CustomLog "| /usr/sbin/rotatelogs /var/log/httpd/accounts.fedoraproject.org-access.log.%Y-%m-%d 86400" combined -ErrorLog "| /usr/sbin/rotatelogs /var/log/httpd/accounts.fedoraproject.org-error.log.%Y-%m-%d 86400" diff --git a/configs/web/accounts.fedoraproject.org/redirect.conf b/configs/web/accounts.fedoraproject.org/redirect.conf deleted file mode 100644 index 1fc6864..0000000 --- a/configs/web/accounts.fedoraproject.org/redirect.conf +++ /dev/null @@ -1 +0,0 @@ -Redirect permanent / https://admin.fedoraproject.org/accounts/ diff --git a/configs/web/applications/Makefile.fedora-ca b/configs/web/applications/Makefile.fedora-ca deleted file mode 100644 index 5da1ea9..0000000 --- a/configs/web/applications/Makefile.fedora-ca +++ /dev/null @@ -1,70 +0,0 @@ -# $Id: Makefile,v 1.4 2006/06/20 18:55:37 jmates Exp $ -# -# NOTE If running OpenSSL 0.9.8a or higher, see -newkey, below. -# -# Automates the setup of a custom Certificate Authority and provides -# routines for signing and revocation of certificates. To use, first -# customize the commands in this file and the settings in openssl.cnf, -# then run: -# -# make init -# -# Then, copy in certificate signing requests, and ensure their suffix is -# .csr before signing them with the following command: -# -# make sign -# -# To revoke a key, name the certificate file with the cert option -# as shown below: -# -# make revoke cert=foo.cert -# -# This will revoke the certificate and call gencrl; the revocation list -# will then need to be copied somehow to the various systems that use -# your CA cert. - -requests = *.csr - -# remove -batch option if want chance to not certify a particular request -sign: FORCE - @openssl ca -batch -config openssl.cnf -days 180 -in $(req) -out $(cert) - -revoke: - @test $${cert:?"usage: make revoke cert=certificate"} - @openssl ca -config openssl.cnf -revoke $(cert) - @$(MAKE) gencrl - -gencrl: - @openssl ca -config openssl.cnf -gencrl -out crl/crl.pem - -clean: - -rm ${requests} - -# creates required supporting files, CA key and certificate -init: - @test ! -f serial - @mkdir crl newcerts private - @chmod go-rwx private - @echo '01' > serial - @touch index - # NOTE use "-newkey rsa:2048" if running OpenSSL 0.9.8a or higher - @openssl req -nodes -config openssl.cnf -days 1825 -x509 -newkey rsa:2048 -out ca-cert.pem -outform PEM - -help: - @echo make sign req=in.csr cert=out.cert - @echo ' - signs in.csr, outputting to out.cert' - @echo - @echo make revoke cert=filename - @echo ' - revokes certificate in named file and calls gencrl' - @echo - @echo make gencrl - @echo ' - updates Certificate Revocation List (CRL)' - @echo - @echo make clean - @echo ' - removes all *.csr files in this directory' - @echo - @echo make init - @echo ' - required initial setup command for new CA' - -# for legacy make support -FORCE: diff --git a/configs/web/applications/accounts-pubring.gpg b/configs/web/applications/accounts-pubring.gpg deleted file mode 100644 index c75ba2c..0000000 Binary files a/configs/web/applications/accounts-pubring.gpg and /dev/null differ diff --git a/configs/web/applications/accounts.conf b/configs/web/applications/accounts.conf deleted file mode 100644 index ad5803a..0000000 --- a/configs/web/applications/accounts.conf +++ /dev/null @@ -1,26 +0,0 @@ -Alias /accounts/static /usr/share/fas/static -Alias /favicon.ico /usr/share/fas/static/favicon.ico -Alias /accounts/fedora-server-ca.cert /usr/share/fas/static/fedora-server-ca.cert -Alias /accounts/fedora-upload-ca.cert /usr/share/fas/static/fedora-upload-ca.cert -# For serving the crl -Alias /ca /srv/web/ca -CacheDisable /ca/crl.pem -AddType application/x-x509-ca-cert cacert.pem -AddType application/x-x509-crl crl.pem - -WSGISocketPrefix run/wsgi - -# TG implements its own signal handler. -WSGIRestrictSignal Off - -# These are the real tunables -WSGIDaemonProcess fas processes=8 threads=2 maximum-requests=50000 user=fas group=fas display-name=fas inactivity-timeout=300 -WSGIPythonOptimize 2 - -WSGIScriptAlias /accounts /usr/lib/python2.4/site-packages/fas/fas.wsgi/accounts - - - WSGIProcessGroup fas - Order deny,allow - Allow from all - diff --git a/configs/web/applications/certhelper.py b/configs/web/applications/certhelper.py deleted file mode 100755 index 3c278a8..0000000 --- a/configs/web/applications/certhelper.py +++ /dev/null @@ -1,280 +0,0 @@ -#!/usr/bin/python -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU Library General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -# -# Copyright 2005 Dan Williams and Red Hat, Inc. - - -import sys, os, tempfile - -OPENSSL_PROG = '/usr/bin/openssl' - -def print_usage(prog): - print "\nUsage:\n" - print " %s ca --outdir= --name=\n" % prog - print " %s normal --outdir= --name= --cadir= --caname=" % prog - print "" - print " Types:" - print " ca - Build system Certificate Authority key & certificate" - print " normal - Key & certificate that works with the build server and builders" - print "" - print "Examples:\n" - print " %s ca --outdir=/etc/plague/ca --name=my_ca" % prog - print " %s normal --outdir=/etc/plague/server/certs --name=server --cadir=/etc/plague/ca --caname=my_ca" % prog - print " %s normal --outdir=/etc/plague/builder/certs --name=builder1 --cadir=/etc/plague/ca --caname=my_ca" % prog - print "\n" - - -class CertHelperException: - def __init__(self, message): - self.message = message - - -class CertHelper: - def __init__(self, prog, outdir, name): - self._prog = prog - self._outdir = outdir - self._name = name - - def dispatch(self, cmd, argslist): - if cmd.lower() == 'ca': - self._gencert_ca(argslist) - elif cmd.lower() == 'normal': - self._gencert_normal(argslist) - else: - print_usage(self._prog) - - def _gencert_ca(self, args): - # Set up CA directory - if not os.path.exists(self._outdir): - os.makedirs(self._outdir) - try: - os.makedirs(os.path.join(self._outdir, 'certs')) - os.makedirs(os.path.join(self._outdir, 'crl')) - os.makedirs(os.path.join(self._outdir, 'newcerts')) - os.makedirs(os.path.join(self._outdir, 'private')) - except: - pass - cert_db = os.path.join(self._outdir, "index.txt") - os.system("/bin/touch %s" % cert_db) - serial = os.path.join(self._outdir, "serial") - if not os.path.exists(serial): - os.system("/bin/echo '01' > %s" % serial) - - cnf = write_openssl_cnf(self._outdir, self._name, {}) - - # Create the CA key - key_file = os.path.join(self._outdir, "private", "cakey.pem") - cmd = "%s genrsa -out %s 2048" % (OPENSSL_PROG, key_file) - if os.system(cmd) != 0: - raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) - - # Make the self-signed CA certificate - cert_file = os.path.join(self._outdir, "%s_ca_cert.pem" % self._name) - cmd = "%s req -config %s -new -x509 -days 3650 -key %s -out %s -extensions v3_ca" % (OPENSSL_PROG, cnf, key_file, cert_file) - if os.system(cmd) != 0: - raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) - - os.remove(cnf) - print "Success. Your Certificate Authority directory is: %s\n" % self._outdir - - def _gencert_normal(self, args): - cadir = argfind(args, 'cadir') - if not cadir: - print_usage(self._prog) - sys.exit(1) - caname = argfind(args, 'caname') - if not caname: - print_usage(self._prog) - sys.exit(1) - - cnf = write_openssl_cnf(cadir, caname, {}) - - # Generate key - key_file = os.path.join(self._outdir, "%s_key.pem" % self._name) - cmd = "%s genrsa -out %s 2048" % (OPENSSL_PROG, key_file) - if os.system(cmd) != 0: - raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) - print "" - - # Generate the certificate request - req_file = os.path.join(self._outdir, "%s_req.pem" % self._name) - cmd = '%s req -config %s -new -nodes -out %s -key %s' % (OPENSSL_PROG, cnf, req_file, key_file) - if os.system(cmd) != 0: - raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) - print "" - - # Sign the request with the CA's certificate and key - cert_file = os.path.join(self._outdir, "%s_cert.pem" % self._name) - cmd = '%s ca -config %s -days 3650 -out %s -infiles %s' % (OPENSSL_PROG, cnf, cert_file, req_file) - if os.system(cmd) != 0: - raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) - print "" - - # Cat the normal cert and key together - key_and_cert = os.path.join(self._outdir, "%s_key_and_cert.pem" % self._name) - cmd = '/bin/cat %s %s > %s' % (key_file, cert_file, key_and_cert) - if os.system(cmd) != 0: - raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) - - # Cleanup: remove the cert, key, and request files - cmd = "/bin/rm -f %s %s %s" % (key_file, req_file, cert_file) - if os.system(cmd) != 0: - raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) - - os.remove(cnf) - print "Success. Your certificate and key file is: %s\n" % key_and_cert - - -def write_openssl_cnf(home, ca_name, opt_dict): - (fd, name) = tempfile.mkstemp('', 'openssl_cnf_', dir=None, text=True) - os.write(fd, """ -############################## -HOME = %s -RANDFILE = .rand - -############################## -[ ca ] -default_ca = CA_default\n - -############################## -[ CA_default ] - -dir = $HOME -certs = $dir/certs -crl_dir = $dir/crl -database = $dir/index.txt -new_certs_dir = $dir/newcerts - -certificate = $dir/cacert.pem -private_key = $dir/private/cakey.pem -serial = $dir/serial -crl = $dir/crl.pem - -x509_extensions = usr_cert - -name_opt = ca_default -cert_opt = ca_default - -default_days = 3650 -default_crl_days= 30 -default_md = md5 -preserve = no - -policy = policy_match - -[ policy_match ] -countryName = match -stateOrProvinceName = match -organizationName = match -organizationalUnitName = optional -commonName = supplied -emailAddress = optional - -############################## -[ req ] -default_bits = 1024 -default_keyfile = privkey.pem -distinguished_name = req_distinguished_name -attributes = req_attributes -x509_extensions = v3_ca # The extentions to add to the self signed cert - -string_mask = MASK:0x2002 - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = US -countryName_min = 2 -countryName_max = 2 - -stateOrProvinceName = State or Province Name (full name) -stateOrProvinceName_default = North Carolina - -localityName = Locality Name (eg, city) -localityName_default = Raleigh - -0.organizationName = Organization Name (eg, company) -0.organizationName_default = Fedora Project - -organizationalUnitName = Organizational Unit Name (eg, section) - -commonName = Common Name (eg, your name or your server\'s hostname) -commonName_max = 64 - -emailAddress = Email Address -emailAddress_max = 64 - -[ req_attributes ] -challengePassword = A challenge password -challengePassword_min = 4 -challengePassword_max = 20 - -unstructuredName = An optional company name - -############################## -[ usr_cert ] - -basicConstraints=CA:FALSE -nsComment = "OpenSSL Generated Certificate" -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid,issuer:always - -############################## -[ v3_ca ] - -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid:always,issuer:always -basicConstraints = CA:true - -""" % (home)) - - return name - -def argfind(arglist, prefix): - val = None - for arg in arglist: - if arg.startswith('--%s=' % prefix): - val = arg - break - if not val: - return None - val = val.replace('--%s=' % prefix, '') - return val - -if __name__ == '__main__': - prog = sys.argv[0] - if len(sys.argv) < 3: - print_usage(prog) - sys.exit(1) - - outdir = argfind(sys.argv, 'outdir') - if not outdir: - print_usage(prog) - sys.exit(1) - - name = argfind(sys.argv, 'name') - if not name: - print_usage(prog) - sys.exit(1) - - ch = CertHelper(prog, outdir, name) - try: - ch.dispatch(sys.argv[1], sys.argv) - except CertHelperException, e: - print e.message - sys.exit(1) - - sys.exit(0) - diff --git a/configs/web/applications/fas-log.cfg b/configs/web/applications/fas-log.cfg deleted file mode 100644 index 3f7843d..0000000 --- a/configs/web/applications/fas-log.cfg +++ /dev/null @@ -1,29 +0,0 @@ -# LOGGING -# Logging is often deployment specific, but some handlers and -# formatters can be defined here. - -[logging] -[[formatters]] -[[[message_only]]] -format='*(message)s' - -[[[full_content]]] -format='*(name)s *(levelname)s *(message)s' - -[[handlers]] -[[[debug_out]]] -class='StreamHandler' -level='DEBUG' -args='(sys.stdout,)' -formatter='full_content' - -[[[access_out]]] -class='StreamHandler' -level='INFO' -args='(sys.stdout,)' -formatter='message_only' - -[[[error_out]]] -class='StreamHandler' -level='ERROR' -args='(sys.stdout,)' diff --git a/configs/web/applications/fas-prod.cfg.erb b/configs/web/applications/fas-prod.cfg.erb deleted file mode 100644 index fa85c4a..0000000 --- a/configs/web/applications/fas-prod.cfg.erb +++ /dev/null @@ -1,163 +0,0 @@ -[global] -samadhi.baseurl = 'https://admin.fedoraproject.org/' - -admingroup = 'accounts' -systemgroup = 'fas-system' -thirdpartygroup = 'thirdparty' - -theme = 'fas' - -accounts_email = "accounts at fedoraproject.org" -legal_cla_email = "legal-cla-archive at fedoraproject.org" - -email_host = "fedoraproject.org" # as in, web-members at email_host - -gpgexec = "/usr/bin/gpg" -gpghome = "/etc/fas-gpg" -gpg_fingerprint = "7662 A6D3 4F21 A653 7BD4 BA64 20A0 8C45 4A0E 6255" -gpg_passphrase = "<%= fasGpgPassphrase %>" -gpg_keyserver = "hkp://subkeys.pgp.net" - -cla_done_group = "cla_done" -cla_fedora_group = "cla_fedora" - -privileged_view_groups = "(^fas-.*)" -username_blacklist = "abuse,accounts,adm,admin,amanda,apache,askfedora,asterisk,bin,board,bodhi2,canna,chair,chairman,cvsdirsec,cvsdocs,cvseclipse,cvsextras,cvsfont,daemon,dbus,decode,desktop,dgilmore,directors,dovecot,dumper,famsco,fax,fedora,fedorarewards,fesco,freemedia,ftp,ftpadm,ftpadmin,games,gdm,gopher,gregdek,halt,hostmaster,ident,info,ingres,jaboutboul,jan,keys,ldap,legal,logo,lp,mail,mailnull,manager,marketing,mysql,nagios,named,netdump,news,newsadm,newsadmin,nfsnobody,nobody,noc,nrpe,nscd,ntp,nut,openvideo,operator,packager,pcap,pkgdb,pkgsigner,postfix,postgres,postmaster,press,privoxy,pvm,quagga,radiusd,radvd,relnotes,root,rpc,rpcuser,rpm,sales,scholarship,secalert,security,shutdown,smmsp,squid,sshd,support,sync,system,tickets,toor,updates,usenet,uucp,vcsa,vendors,voting,webalizer,webmaster,wikiadmin,wnn,www,xfs,zabbix" - -openidstore = "/var/tmp/fas/openid" - -# Enable or disable generation of SSL certificates for users -gencert = <%= genCert %> - -makeexec = "/usr/bin/make" -openssl_lockdir = "/var/lock/fedora-ca" -openssl_digest = "md5" -openssl_expire = 15552000 # 60*60*24*180 = 6 months -openssl_ca_dir = "/var/lib/fedora-ca" -openssl_ca_newcerts = "/var/lib/fedora-ca/newcerts" -openssl_ca_index = "/var/lib/fedora-ca/index.txt" -openssl_c = "US" -openssl_st = "North Carolina" -openssl_l = "Raleigh" -openssl_o = "Fedora Project" -openssl_ou = "Fedora User Cert" - -# Groups that automatically grant membership to other groups -# Format: 'group1:a,b,c|group2:d,e,f' -auto_approve_groups = 'packager:fedorabugs|cla_fedora:cla_done|cla_redhat:cla_done|cla_dell:cla_done|cla_ibm:cla_done' - -# This is where all of your settings go for your development environment -# Settings that are the same for both development and production -# (such as template engine, encodings, etc.) all go in -# fas/config/app.cfg - -mail.on = True -mail.server = 'bastion' -#mail.testmode = True -mail.debug = False -mail.encoding = 'utf-8' - -# DATABASE - -# pick the form for your database -# sqlobject.dburi="postgres://username at hostname/databasename" -# sqlobject.dburi="mysql://username:password at hostname:port/databasename" -# sqlobject.dburi="sqlite:///file_name_and_path" - -# If you have sqlite, here's a simple default to get you started -# in development -sqlalchemy.dburi="postgres://fas:<%= fasDbPassword %>@db2/fas2" -sqlalchemy.echo=False - -# if you are using a database or table type without transactions -# (MySQL default, for example), you should turn off transactions -# by prepending notrans_ on the uri -# sqlobject.dburi="notrans_mysql://username:password at hostname:port/databasename" - -# for Windows users, sqlite URIs look like: -# sqlobject.dburi="sqlite:///drive_letter:/path/to/file" - -# SERVER - -# Some server parameters that you may want to tweak -server.socket_port=8088 -server.thread_pool=50 -server.socket_queue_size=30 - -# FAS2 is mmuch busier than other servers due to serving visit and auth via -# JSON. -# Double pool_size -#sqlalchemy.pool_size=10 -# And increase overflow above what other servers have -#sqlalchemy.max_overflow=25 -# When using wsgi, we want the pool to be very low (as a separate instance is -# run in each apache mod_wsgi thread. So each one is going to have very few -# concurrent db connections. -sqlalchemy.pool_size=1 -sqlalchemy.max_overflow=2 - -# Enable the debug output at the end on pages. -# log_debug_info_filter.on = False - -server.environment="production" -autoreload.package="fas" - -session_filter.on = True - -# Set to True if you'd like to abort execution if a controller gets an -# unexpected parameter. False by default -tg.strict_parameters = True -tg.ignore_parameters = ["_csrf_token"] - -server.webpath='/accounts' -base_url_filter.on = True -base_url_filter.use_x_forwarded_host = True -base_url_filter.base_url = "https://admin.fedoraproject.org" - -# Make the session cookie only return to the host over an SSL link -visit.cookie.secure = True -session_filter.cookie_secure = True - -[/fedora-server-ca.cert] -static_filter.on = True -static_filter.file = "/etc/pki/fas/fedora-server-ca.cert" - -[/fedora-upload-ca.cert] -static_filter.on = True -static_filter.file = "/etc/pki/fas/fedora-upload-ca.cert" - -# LOGGING -# Logging configuration generally follows the style of the standard -# Python logging module configuration. Note that when specifying -# log format messages, you need to use *() for formatting variables. -# Deployment independent log configuration is in fas/config/log.cfg -[logging] - -[[loggers]] -[[[fas]]] -level='DEBUG' -qualname='fas' -handlers=['debug_out'] - -[[[allinfo]]] -level='INFO' -handlers=['debug_out'] - -#[[[access]]] -#level='INFO' -#qualname='turbogears.access' -#handlers=['access_out'] -#propagate=0 - -[[[identity]]] -level='INFO' -qualname='turbogears.identity' -handlers=['access_out'] -propagate=0 - -[[[database]]] -# Set to INFO to make SQLAlchemy display SQL commands -level='ERROR' -qualname='sqlalchemy.engine' -handlers=['debug_out'] -propagate=0 diff --git a/configs/web/applications/fas.wsgi b/configs/web/applications/fas.wsgi deleted file mode 100644 index 865cc08..0000000 --- a/configs/web/applications/fas.wsgi +++ /dev/null @@ -1,50 +0,0 @@ -#!/usr/bin/python -import sys -sys.path.append('/usr/lib/python2.4/site-packages/fas/') -sys.stdout = sys.stderr - -import pkg_resources -pkg_resources.require('CherryPy <= 3.0alpha') - -import os -os.environ['PYTHON_EGG_CACHE'] = '/var/www/.python-eggs' - -import atexit -import cherrypy -import cherrypy._cpwsgi -import turbogears -import turbogears.startup -from formencode.variabledecode import NestedVariables -import fedora.tg.util - -class MyNestedVariablesFilter(object): - def before_main(self): - if hasattr(cherrypy.request, "params"): - cherrypy.request.params_backup = cherrypy.request.params - cherrypy.request.params = \ - NestedVariables.to_python(cherrypy.request.params or {}) - -turbogears.startup.NestedVariablesFilter = MyNestedVariablesFilter - -turbogears.update_config(configfile="/etc/fas.cfg", modulename="fas.config") -turbogears.config.update({'global': {'server.environment': 'production'}}) -turbogears.config.update({'global': {'autoreload.on': False}}) -turbogears.config.update({'global': {'server.log_to_screen': False}}) -turbogears.config.update({'global': {'server.webpath': '/accounts'}}) -turbogears.config.update({'global': {'base_url_filter.on': True}}) -turbogears.config.update({'global': {'base_url_filter.base_url': 'https://admin.fedoraproject.org'}}) -#turbogears.config.update({'global': {'sqlalchemy.recycle': '10'}}) - -turbogears.startup.call_on_startup.append(fedora.tg.util.enable_csrf) - -import fas.controllers - -cherrypy.root = fas.controllers.Root() - -if cherrypy.server.state == 0: - atexit.register(cherrypy.server.stop) - cherrypy.server.start(init_only=True, server_class=None) - -def application(environ, start_response): - environ['SCRIPT_NAME'] = '' - return cherrypy._cpwsgi.wsgiApp(environ, start_response) diff --git a/configs/web/applications/fedora-ca-client-openssl.cnf b/configs/web/applications/fedora-ca-client-openssl.cnf deleted file mode 100644 index 5c3bb15..0000000 --- a/configs/web/applications/fedora-ca-client-openssl.cnf +++ /dev/null @@ -1,317 +0,0 @@ -# -# OpenSSL example configuration file. -# This is mostly being used for generation of certificate requests. -# - -# This definition stops the following lines choking if HOME isn't -# defined. -HOME = . -RANDFILE = /var/lib/fedora-ca/.rnd - -# Extra OBJECT IDENTIFIER info: -#oid_file = $ENV::HOME/.oid -oid_section = new_oids - -# To use this configuration file with the "-extfile" option of the -# "openssl x509" utility, name here the section containing the -# X.509v3 extensions to use: -# extensions = -# (Alternatively, use a configuration file that has only -# X.509v3 extensions in its main [= default] section.) - -[ new_oids ] - -# We can add new OIDs in here for use by 'ca' and 'req'. -# Add a simple OID like this: -# testoid1=1.2.3.4 -# Or use config file substitution like this: -# testoid2=${testoid1}.5.6 - -#################################################################### -[ ca ] -default_ca = CA_default # The default ca section - -#################################################################### -[ CA_default ] - -dir = . # Where everything is kept -certs = $dir/certs # Where the issued certs are kept -crl_dir = $dir/crl # Where the issued crl are kept -database = $dir/index.txt # database index file. -#unique_subject = no # Set to 'no' to allow creation of - # several ctificates with same subject. -new_certs_dir = $dir/newcerts # default place for new certs. - -certificate = $dir/cacert.pem # The CA certificate -serial = $dir/serial # The current serial number -crlnumber = $dir/crlnumber # the current crl number - # must be commented out to leave a V1 CRL -crl = $dir/crl.pem # The current CRL -private_key = $dir/private/cakey.pem # The private key -RANDFILE = $dir/private/.rand # private random number file - -x509_extensions = usr_cert # The extentions to add to the cert - -# Comment out the following two lines for the "traditional" -# (and highly broken) format. -name_opt = ca_default # Subject Name options -cert_opt = ca_default # Certificate field options - -# Extension copying option: use with caution. -# copy_extensions = copy - -# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs -# so this is commented out by default to leave a V1 CRL. -# crlnumber must also be commented out to leave a V1 CRL. -# crl_extensions = crl_ext - -default_days = 365 # how long to certify for -default_crl_days= 30 # how long before next CRL -default_md = sha1 # which md to use. -preserve = no # keep passed DN ordering - -# A few difference way of specifying how similar the request should look -# For type CA, the listed attributes must be the same, and the optional -# and supplied fields are just that :-) -policy = policy_match - -# For the CA policy -[ policy_match ] -countryName = match -stateOrProvinceName = match -organizationName = match -organizationalUnitName = optional -commonName = supplied -emailAddress = optional - -# For the 'anything' policy -# At this point in time, you must list all acceptable 'object' -# types. -[ policy_anything ] -countryName = optional -stateOrProvinceName = optional -localityName = optional -organizationName = optional -organizationalUnitName = optional -commonName = supplied -emailAddress = optional - -#################################################################### -[ req ] -default_bits = 2048 -default_md = sha1 -default_keyfile = privkey.pem -distinguished_name = req_distinguished_name -attributes = req_attributes -x509_extensions = v3_ca # The extentions to add to the self signed cert - -# Passwords for private keys if not present they will be prompted for -# input_password = secret -# output_password = secret - -# This sets a mask for permitted string types. There are several options. -# default: PrintableString, T61String, BMPString. -# pkix : PrintableString, BMPString. -# utf8only: only UTF8Strings. -# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). -# MASK:XXXX a literal mask value. -# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings -# so use this option with caution! -# we use PrintableString+UTF8String mask so if pure ASCII texts are used -# the resulting certificates are compatible with Netscape -string_mask = MASK:0x2002 - -# req_extensions = v3_req # The extensions to add to a certificate request - -[ req_distinguished_name ] -countryName = Country Name (2 letter code) -countryName_default = US -countryName_min = 2 -countryName_max = 2 - -stateOrProvinceName = State or Province Name (full name) -stateOrProvinceName_default = North Carolina - -localityName = Locality Name (eg, city) -localityName_default = Raleigh - -0.organizationName = Organization Name (eg, company) -0.organizationName_default = Fedora Project - -# we can do this but it is not needed normally :-) -#1.organizationName = Second Organization Name (eg, company) -#1.organizationName_default = World Wide Web Pty Ltd - -organizationalUnitName = Organizational Unit Name (eg, section) -#organizationalUnitName_default = - -commonName = Common Name (eg, your name or your server\'s hostname) -commonName_max = 64 - -emailAddress = Email Address -emailAddress_max = 64 - -# SET-ex3 = SET extension number 3 - -[ req_attributes ] -#challengePassword = A challenge password -#challengePassword_min = 0 -#challengePassword_max = 20 - -unstructuredName = An optional company name - -[ usr_cert ] - -# These extensions are added when 'ca' signs a request. - -# This goes against PKIX guidelines but some CAs do it and some software -# requires this to avoid interpreting an end user certificate as a CA. - -basicConstraints=CA:FALSE - -# Here are some examples of the usage of nsCertType. If it is omitted -# the certificate can be used for anything *except* object signing. - -# This is OK for an SSL server. -# nsCertType = server - -# For an object signing certificate this would be used. -# nsCertType = objsign - -# For normal client use this is typical -# nsCertType = client, email - -# and for everything including object signing: -# nsCertType = client, email, objsign - -# This is typical in keyUsage for a client certificate. -# keyUsage = nonRepudiation, digitalSignature, keyEncipherment - -# This will be displayed in Netscape's comment listbox. -nsComment = "OpenSSL Generated Certificate" - -# PKIX recommendations harmless if included in all certificates. -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid,issuer - -# This stuff is for subjectAltName and issuerAltname. -# Import the email address. -# subjectAltName=email:copy -# An alternative to produce certificates that aren't -# deprecated according to PKIX. -# subjectAltName=email:move - -# Copy subject details -# issuerAltName=issuer:copy - -#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem -#nsBaseUrl -#nsRevocationUrl -#nsRenewalUrl -#nsCaPolicyUrl -#nsSslServerName - -[ v3_req ] - -# Extensions to add to a certificate request - -basicConstraints = CA:FALSE -keyUsage = nonRepudiation, digitalSignature, keyEncipherment - -[ v3_ca ] - - -# Extensions for a typical CA - - -# PKIX recommendation. - -subjectKeyIdentifier=hash - -authorityKeyIdentifier=keyid:always,issuer:always - -# This is what PKIX recommends but some broken software chokes on critical -# extensions. -#basicConstraints = critical,CA:true -# So we do this instead. -basicConstraints = CA:true - -# Key usage: this is typical for a CA certificate. However since it will -# prevent it being used as an test self-signed certificate it is best -# left out by default. -# keyUsage = cRLSign, keyCertSign - -# Some might want this also -# nsCertType = sslCA, emailCA - -# Include email address in subject alt name: another PKIX recommendation -# subjectAltName=email:copy -# Copy issuer details -# issuerAltName=issuer:copy - -# DER hex encoding of an extension: beware experts only! -# obj=DER:02:03 -# Where 'obj' is a standard or added object -# You can even override a supported extension: -# basicConstraints= critical, DER:30:03:01:01:FF - -[ crl_ext ] - -# CRL extensions. -# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. - -# issuerAltName=issuer:copy -authorityKeyIdentifier=keyid:always,issuer:always - -[ proxy_cert_ext ] -# These extensions should be added when creating a proxy certificate - -# This goes against PKIX guidelines but some CAs do it and some software -# requires this to avoid interpreting an end user certificate as a CA. - -basicConstraints=CA:FALSE - -# Here are some examples of the usage of nsCertType. If it is omitted -# the certificate can be used for anything *except* object signing. - -# This is OK for an SSL server. -# nsCertType = server - -# For an object signing certificate this would be used. -# nsCertType = objsign - -# For normal client use this is typical -# nsCertType = client, email - -# and for everything including object signing: -# nsCertType = client, email, objsign - -# This is typical in keyUsage for a client certificate. -# keyUsage = nonRepudiation, digitalSignature, keyEncipherment - -# This will be displayed in Netscape's comment listbox. -nsComment = "OpenSSL Generated Certificate" - -# PKIX recommendations harmless if included in all certificates. -subjectKeyIdentifier=hash -authorityKeyIdentifier=keyid,issuer:always - -# This stuff is for subjectAltName and issuerAltname. -# Import the email address. -# subjectAltName=email:copy -# An alternative to produce certificates that aren't -# deprecated according to PKIX. -# subjectAltName=email:move - -# Copy subject details -# issuerAltName=issuer:copy - -#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem -#nsBaseUrl -#nsRevocationUrl -#nsRenewalUrl -#nsCaPolicyUrl -#nsSslServerName - -# This really needs to be in place for it to be a proxy certificate. -proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo diff --git a/configs/web/fas.fedoraproject.org.conf b/configs/web/fas.fedoraproject.org.conf deleted file mode 100644 index 7db2e97..0000000 --- a/configs/web/fas.fedoraproject.org.conf +++ /dev/null @@ -1,13 +0,0 @@ -# proxy1 - 10.8.32.122 -# proxy2 - 10.8.32.121 -# proxy3 - 66.35.62.166 -# proxy4 - 152.46.7.222 -# proxy5 - 80.239.156.215 - - - - ServerName fas.fedoraproject.org - ServerAdmin admin at fedoraproject.org - - include "conf.d/fas.fedoraproject.org/*.conf - diff --git a/configs/web/fas.fedoraproject.org/logs.conf b/configs/web/fas.fedoraproject.org/logs.conf deleted file mode 100644 index 9195af7..0000000 --- a/configs/web/fas.fedoraproject.org/logs.conf +++ /dev/null @@ -1,2 +0,0 @@ -CustomLog "| /usr/sbin/rotatelogs /var/log/httpd/fas.fedoraproject.org-access.log.%Y-%m-%d 86400" combined -ErrorLog "| /usr/sbin/rotatelogs /var/log/httpd/fas.fedoraproject.org-error.log.%Y-%m-%d 86400" diff --git a/configs/web/fas.fedoraproject.org/redirect.conf b/configs/web/fas.fedoraproject.org/redirect.conf deleted file mode 100644 index 1fc6864..0000000 --- a/configs/web/fas.fedoraproject.org/redirect.conf +++ /dev/null @@ -1 +0,0 @@ -Redirect permanent / https://admin.fedoraproject.org/accounts/ diff --git a/manifests/services/fas.pp b/manifests/services/fas.pp deleted file mode 100644 index 3ae09e3..0000000 --- a/manifests/services/fas.pp +++ /dev/null @@ -1,292 +0,0 @@ -# Fedora Account System -class fas { - include fas-clients-package - include python-fedora-package - - if $groups { - $notGroup = '' - } else { - $groups = 'sysadmin-main' - } - if $sshGroups { - $notSshGroup = '' - } else { - $sshGroups = '' - } - if $restrictedApp { - $notRestrictedApp = '' - } else { - $restrictedApp = '/usr/bin/cvs server' - } - - configfile { "/etc/nsswitch.conf": - source => "fas/nsswitch.conf" - } - templatefile { '/etc/fas.conf': - content => template('system/fas.conf.erb'), - mode => '0600', - - } -# exec { 'make-accounts': -# command => '/usr/bin/fasClient -e; /usr/bin/fasClient -i', -# subscribe => Templatefile['/etc/fas.conf'], -# require => Package['fas-clients'], -# refreshonly => true -# } - configfile { '/etc/cron.d/fasSync': - source => 'fas/fasSync', - require => Package[fas-clients], - } - file { "/root/bin/": - ensure => directory, - } - cert { '/etc/sudoers': - source => "secure/sudoers" - } -} - -class fas-proxy inherits httpd { - apachefile { "/etc/httpd/conf.d/admin.fedoraproject.org/accounts.conf": - source => 'web/accounts-proxy.conf' - } - - apachefile { '/etc/httpd/conf.d/fas.fedoraproject.org.conf': - source => 'web/fas.fedoraproject.org.conf', - } - - apachefile { '/etc/httpd/conf.d/fas.fedoraproject.org/': - source => 'web/fas.fedoraproject.org/', - recurse => true - } - - apachefile { '/etc/httpd/conf.d/accounts.fedoraproject.org.conf': - source => 'web/accounts.fedoraproject.org.conf', - } - - apachefile { '/etc/httpd/conf.d/accounts.fedoraproject.org/': - source => 'web/accounts.fedoraproject.org/', - recurse => true - } - -} - -class fas-server-base inherits turbogears { - $bugzillaUser='fedora-admin-xmlrpc at redhat.com' - include httpd - include mod_wsgi::module - - package { fas: - ensure => present, - } - - package { fas-plugin-asterisk: - ensure => present, - } - - ### HACK: Need to solve this better later - apachefile { '/usr/lib/python2.4/site-packages/fas/fas.wsgi': - source => 'web/applications/fas.wsgi', - require => Package['mod_wsgi'] - } - - file { '/var/www/.python-eggs': - ensure => directory, - mode => '0700', - owner => 'apache' - } - - file { '/etc/fas-gpg': - ensure => directory, - mode => '0700', - owner => 'fas', - group => 'fas', - } - - cert { '/etc/fas-gpg/secring.gpg': - source => 'secure/accounts-secring.gpg', - owner => 'fas', - group => 'fas', - mode => 600, - require => File['/etc/fas-gpg'] - } - - file { '/etc/fas-gpg/pubring.gpg': - owner => 'fas', - group => 'fas', - mode => 600, - replace => false, - ensure => file, - source => 'puppet:///config/web/applications/accounts-pubring.gpg', - } - - apachefile { '/etc/httpd/conf.d/accounts.conf': - source => 'web/applications/accounts.conf', - require => Package['mod_wsgi'] - } - - file { '/etc/pki/fas': - ensure => directory, - mode => '0700', - owner => 'fas', - group => 'fas', - } - # These are both public certs so there's no reason to hide them - configfile { '/etc/pki/fas/fedora-server-ca.cert': - source => 'secure/fedora-ca.cert', - } - - configfile { '/etc/pki/fas/fedora-upload-ca.cert': - source => 'secure/fedora-ca.cert', - } - - templatefile { '/etc/export-bugzilla.cfg': - content => template('system/export-bugzilla.cfg.erb'), - owner => 'fas', - # Contains passwords so it needs to be restricted - mode => '0640' - } - - # Note: This will move into the fas rpm soon - script { "/usr/local/bin/export-bugzilla.py": - source => "system/export-bugzilla.py", - mode => 0755 - } - cert { '/usr/share/fas/static/fedora-server-ca.cert': - source => 'secure/fedora-ca.cert', - owner => 'apache', - group => 'sysadmin-main', - mode => '0440' - } - - cert { '/usr/share/fas/static/fedora-upload-ca.cert': - source => 'secure/fedora-ca.cert', - owner => 'apache', - group => 'sysadmin-main', - mode => '0440' - } - - configfile { '/usr/lib/python2.4/site-packages/fas/config/log.cfg': - source => 'web/applications/fas-log.cfg', - owner => 'root', - group => 'root', - notify => Service['httpd'], - require => Package['httpd'], - mode => '0644' - } -} - -class fas-server inherits fas-server-base { - - $genCert = 'False' - templatefile { '/etc/fas.cfg': - content => template('web/applications/fas-prod.cfg.erb'), - owner => 'fas', - group => 'apache', - notify => Service['httpd'], - require => Package['httpd'], - mode => '640' - } - -} - -class fas-server-gencert inherits fas-server-base { - - $genCert = 'True' - templatefile { '/etc/fas.cfg': - content => template('web/applications/fas-prod.cfg.erb'), - owner => 'fas', - group => 'apache', - notify => Service['httpd'], - require => Package['httpd'], - mode => '640' - } - - # These should be created by the fas package later - file { '/var/lock/fedora-ca': - ensure => directory, - mode => '0700', - owner => 'fas', - group => 'fas', - require => Package[fas], - } - - file { '/var/lib/fedora-ca': - ensure => directory, - mode => '0771', - owner => 'fas', - group => 'sysadmin-main', - require => Package[fas], - } - - file { '/var/lib/fedora-ca/newcerts': - ensure => directory, - mode => '0770', - owner => 'fas', - group => 'sysadmin-main', - require => Package[fas], - } - - file { '/var/lib/fedora-ca/private': - ensure => directory, - mode => '0750', - owner => 'fas', - group => 'sysadmin-main' - } - - # For publishing the crl - file { '/srv/web/ca': - ensure => directory, - mode => '0755', - owner => 'apache', - group => 'apache' - } - - configfile { '/var/lib/fedora-ca/Makefile': - source => 'web/applications/Makefile.fedora-ca', - mode => '0644' - } - - configfile { '/var/lib/fedora-ca/openssl.cnf': - source => 'web/applications/fedora-ca-client-openssl.cnf', - mode => '0644' - } - - script { '/var/lib/fedora-ca/certhelper.py': - source => 'web/applications/certhelper.py', - mode => '0750', - owner => 'root', - group => 'sysadmin-main' - } - - - # Public keys don't need restrictive permissions - configfile { '/var/lib/fedora-ca/cacert.pem': - source => 'secure/fedora-ca.cert', - mode => '0444' - } - - # First of every month, force a new crl to be created - cron { gen-crl: - command => "cd /var/lib/fedora-ca ; /usr/bin/make gencrl &> /dev/null", - user => "apache", - minute => 0, - hour => 0, - monthday => [ 1, 15 ], - } - - symlink { '/srv/web/ca/crl.pem': - ensure => '/var/lib/fedora-ca/crl/crl.pem' - } -} - -# Note: path will change when it moves into the fas rpm -class fas-no-balance { - cron { export-bugzilla: - command => "/usr/local/bin/export-bugzilla.py fedorabugs fedora_contrib", - user => "fas", - minute => 10, - ensure => present, - require => Package['fas'], - environment => "MAILTO=root" - } -} commit a5c86d8ecd5cb5aa373a9dd608bb20eb6aaf8a74 Author: Mike McGrath Date: Wed Apr 8 19:52:34 2009 +0000 Added fas module diff --git a/modules/fas/README b/modules/fas/README new file mode 100644 index 0000000..59b50b3 --- /dev/null +++ b/modules/fas/README @@ -0,0 +1,10 @@ +FAS Fedora Account System +------------------------ + +The Fedora Account System is a web application that manages the accounts of +Fedora Project Contributors. It's built in TurboGears and comes with a json +API for querying against remotely. + +The python-fedora-infrastructure package has a TurboGears identity provider +that works with the Account System. + diff --git a/modules/fas/files/Makefile.fedora-ca b/modules/fas/files/Makefile.fedora-ca new file mode 100644 index 0000000..5da1ea9 --- /dev/null +++ b/modules/fas/files/Makefile.fedora-ca @@ -0,0 +1,70 @@ +# $Id: Makefile,v 1.4 2006/06/20 18:55:37 jmates Exp $ +# +# NOTE If running OpenSSL 0.9.8a or higher, see -newkey, below. +# +# Automates the setup of a custom Certificate Authority and provides +# routines for signing and revocation of certificates. To use, first +# customize the commands in this file and the settings in openssl.cnf, +# then run: +# +# make init +# +# Then, copy in certificate signing requests, and ensure their suffix is +# .csr before signing them with the following command: +# +# make sign +# +# To revoke a key, name the certificate file with the cert option +# as shown below: +# +# make revoke cert=foo.cert +# +# This will revoke the certificate and call gencrl; the revocation list +# will then need to be copied somehow to the various systems that use +# your CA cert. + +requests = *.csr + +# remove -batch option if want chance to not certify a particular request +sign: FORCE + @openssl ca -batch -config openssl.cnf -days 180 -in $(req) -out $(cert) + +revoke: + @test $${cert:?"usage: make revoke cert=certificate"} + @openssl ca -config openssl.cnf -revoke $(cert) + @$(MAKE) gencrl + +gencrl: + @openssl ca -config openssl.cnf -gencrl -out crl/crl.pem + +clean: + -rm ${requests} + +# creates required supporting files, CA key and certificate +init: + @test ! -f serial + @mkdir crl newcerts private + @chmod go-rwx private + @echo '01' > serial + @touch index + # NOTE use "-newkey rsa:2048" if running OpenSSL 0.9.8a or higher + @openssl req -nodes -config openssl.cnf -days 1825 -x509 -newkey rsa:2048 -out ca-cert.pem -outform PEM + +help: + @echo make sign req=in.csr cert=out.cert + @echo ' - signs in.csr, outputting to out.cert' + @echo + @echo make revoke cert=filename + @echo ' - revokes certificate in named file and calls gencrl' + @echo + @echo make gencrl + @echo ' - updates Certificate Revocation List (CRL)' + @echo + @echo make clean + @echo ' - removes all *.csr files in this directory' + @echo + @echo make init + @echo ' - required initial setup command for new CA' + +# for legacy make support +FORCE: diff --git a/modules/fas/files/accounts-proxy.conf b/modules/fas/files/accounts-proxy.conf new file mode 100644 index 0000000..7a729e4 --- /dev/null +++ b/modules/fas/files/accounts-proxy.conf @@ -0,0 +1,11 @@ +# fas1 is the only place for gencert right now +RewriteRule /accounts/user/gencert http://fas1/accounts/user/gencert [P] +# pass ca requests on needed for CRL +ProxyPass /ca http://fas1/ca +ProxyPassReverse /ca http://fas1/ca + +#RewriteRule ^/accounts/(.*) balancer://accountsCluster/accounts/$1 [P] +#RewriteRule ^/accounts$ https://admin.fedoraproject.org/accounts/ [R,L] + +RewriteRule ^/accounts/(.*) http://localhost:10004/accounts/$1 [P] +RewriteRule ^/accounts$ https://admin.fedoraproject.org/accounts/ [R,L] diff --git a/modules/fas/files/accounts-pubring.gpg b/modules/fas/files/accounts-pubring.gpg new file mode 100644 index 0000000..c75ba2c Binary files /dev/null and b/modules/fas/files/accounts-pubring.gpg differ diff --git a/modules/fas/files/accounts.conf b/modules/fas/files/accounts.conf new file mode 100644 index 0000000..ad5803a --- /dev/null +++ b/modules/fas/files/accounts.conf @@ -0,0 +1,26 @@ +Alias /accounts/static /usr/share/fas/static +Alias /favicon.ico /usr/share/fas/static/favicon.ico +Alias /accounts/fedora-server-ca.cert /usr/share/fas/static/fedora-server-ca.cert +Alias /accounts/fedora-upload-ca.cert /usr/share/fas/static/fedora-upload-ca.cert +# For serving the crl +Alias /ca /srv/web/ca +CacheDisable /ca/crl.pem +AddType application/x-x509-ca-cert cacert.pem +AddType application/x-x509-crl crl.pem + +WSGISocketPrefix run/wsgi + +# TG implements its own signal handler. +WSGIRestrictSignal Off + +# These are the real tunables +WSGIDaemonProcess fas processes=8 threads=2 maximum-requests=50000 user=fas group=fas display-name=fas inactivity-timeout=300 +WSGIPythonOptimize 2 + +WSGIScriptAlias /accounts /usr/lib/python2.4/site-packages/fas/fas.wsgi/accounts + + + WSGIProcessGroup fas + Order deny,allow + Allow from all + diff --git a/modules/fas/files/accounts.fedoraproject.org.conf b/modules/fas/files/accounts.fedoraproject.org.conf new file mode 100644 index 0000000..1220803 --- /dev/null +++ b/modules/fas/files/accounts.fedoraproject.org.conf @@ -0,0 +1,13 @@ +# proxy1 - 10.8.32.122 +# proxy2 - 10.8.32.121 +# proxy3 - 66.35.62.166 +# proxy4 - 152.46.7.222 +# proxy5 - 80.239.156.215 + + + + ServerName accounts.fedoraproject.org + ServerAdmin admin at fedoraproject.org + + include "conf.d/accounts.fedoraproject.org/*.conf + diff --git a/modules/fas/files/accounts.fedoraproject.org/logs.conf b/modules/fas/files/accounts.fedoraproject.org/logs.conf new file mode 100644 index 0000000..733e6e3 --- /dev/null +++ b/modules/fas/files/accounts.fedoraproject.org/logs.conf @@ -0,0 +1,2 @@ +CustomLog "| /usr/sbin/rotatelogs /var/log/httpd/accounts.fedoraproject.org-access.log.%Y-%m-%d 86400" combined +ErrorLog "| /usr/sbin/rotatelogs /var/log/httpd/accounts.fedoraproject.org-error.log.%Y-%m-%d 86400" diff --git a/modules/fas/files/accounts.fedoraproject.org/redirect.conf b/modules/fas/files/accounts.fedoraproject.org/redirect.conf new file mode 100644 index 0000000..1fc6864 --- /dev/null +++ b/modules/fas/files/accounts.fedoraproject.org/redirect.conf @@ -0,0 +1 @@ +Redirect permanent / https://admin.fedoraproject.org/accounts/ diff --git a/modules/fas/files/certhelper.py b/modules/fas/files/certhelper.py new file mode 100755 index 0000000..3c278a8 --- /dev/null +++ b/modules/fas/files/certhelper.py @@ -0,0 +1,280 @@ +#!/usr/bin/python +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Library General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +# +# Copyright 2005 Dan Williams and Red Hat, Inc. + + +import sys, os, tempfile + +OPENSSL_PROG = '/usr/bin/openssl' + +def print_usage(prog): + print "\nUsage:\n" + print " %s ca --outdir= --name=\n" % prog + print " %s normal --outdir= --name= --cadir= --caname=" % prog + print "" + print " Types:" + print " ca - Build system Certificate Authority key & certificate" + print " normal - Key & certificate that works with the build server and builders" + print "" + print "Examples:\n" + print " %s ca --outdir=/etc/plague/ca --name=my_ca" % prog + print " %s normal --outdir=/etc/plague/server/certs --name=server --cadir=/etc/plague/ca --caname=my_ca" % prog + print " %s normal --outdir=/etc/plague/builder/certs --name=builder1 --cadir=/etc/plague/ca --caname=my_ca" % prog + print "\n" + + +class CertHelperException: + def __init__(self, message): + self.message = message + + +class CertHelper: + def __init__(self, prog, outdir, name): + self._prog = prog + self._outdir = outdir + self._name = name + + def dispatch(self, cmd, argslist): + if cmd.lower() == 'ca': + self._gencert_ca(argslist) + elif cmd.lower() == 'normal': + self._gencert_normal(argslist) + else: + print_usage(self._prog) + + def _gencert_ca(self, args): + # Set up CA directory + if not os.path.exists(self._outdir): + os.makedirs(self._outdir) + try: + os.makedirs(os.path.join(self._outdir, 'certs')) + os.makedirs(os.path.join(self._outdir, 'crl')) + os.makedirs(os.path.join(self._outdir, 'newcerts')) + os.makedirs(os.path.join(self._outdir, 'private')) + except: + pass + cert_db = os.path.join(self._outdir, "index.txt") + os.system("/bin/touch %s" % cert_db) + serial = os.path.join(self._outdir, "serial") + if not os.path.exists(serial): + os.system("/bin/echo '01' > %s" % serial) + + cnf = write_openssl_cnf(self._outdir, self._name, {}) + + # Create the CA key + key_file = os.path.join(self._outdir, "private", "cakey.pem") + cmd = "%s genrsa -out %s 2048" % (OPENSSL_PROG, key_file) + if os.system(cmd) != 0: + raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) + + # Make the self-signed CA certificate + cert_file = os.path.join(self._outdir, "%s_ca_cert.pem" % self._name) + cmd = "%s req -config %s -new -x509 -days 3650 -key %s -out %s -extensions v3_ca" % (OPENSSL_PROG, cnf, key_file, cert_file) + if os.system(cmd) != 0: + raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) + + os.remove(cnf) + print "Success. Your Certificate Authority directory is: %s\n" % self._outdir + + def _gencert_normal(self, args): + cadir = argfind(args, 'cadir') + if not cadir: + print_usage(self._prog) + sys.exit(1) + caname = argfind(args, 'caname') + if not caname: + print_usage(self._prog) + sys.exit(1) + + cnf = write_openssl_cnf(cadir, caname, {}) + + # Generate key + key_file = os.path.join(self._outdir, "%s_key.pem" % self._name) + cmd = "%s genrsa -out %s 2048" % (OPENSSL_PROG, key_file) + if os.system(cmd) != 0: + raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) + print "" + + # Generate the certificate request + req_file = os.path.join(self._outdir, "%s_req.pem" % self._name) + cmd = '%s req -config %s -new -nodes -out %s -key %s' % (OPENSSL_PROG, cnf, req_file, key_file) + if os.system(cmd) != 0: + raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) + print "" + + # Sign the request with the CA's certificate and key + cert_file = os.path.join(self._outdir, "%s_cert.pem" % self._name) + cmd = '%s ca -config %s -days 3650 -out %s -infiles %s' % (OPENSSL_PROG, cnf, cert_file, req_file) + if os.system(cmd) != 0: + raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) + print "" + + # Cat the normal cert and key together + key_and_cert = os.path.join(self._outdir, "%s_key_and_cert.pem" % self._name) + cmd = '/bin/cat %s %s > %s' % (key_file, cert_file, key_and_cert) + if os.system(cmd) != 0: + raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) + + # Cleanup: remove the cert, key, and request files + cmd = "/bin/rm -f %s %s %s" % (key_file, req_file, cert_file) + if os.system(cmd) != 0: + raise CertHelperException("\n\nERROR: Command '%s' was not successful.\n" % cmd) + + os.remove(cnf) + print "Success. Your certificate and key file is: %s\n" % key_and_cert + + +def write_openssl_cnf(home, ca_name, opt_dict): + (fd, name) = tempfile.mkstemp('', 'openssl_cnf_', dir=None, text=True) + os.write(fd, """ +############################## +HOME = %s +RANDFILE = .rand + +############################## +[ ca ] +default_ca = CA_default\n + +############################## +[ CA_default ] + +dir = $HOME +certs = $dir/certs +crl_dir = $dir/crl +database = $dir/index.txt +new_certs_dir = $dir/newcerts + +certificate = $dir/cacert.pem +private_key = $dir/private/cakey.pem +serial = $dir/serial +crl = $dir/crl.pem + +x509_extensions = usr_cert + +name_opt = ca_default +cert_opt = ca_default + +default_days = 3650 +default_crl_days= 30 +default_md = md5 +preserve = no + +policy = policy_match + +[ policy_match ] +countryName = match +stateOrProvinceName = match +organizationName = match +organizationalUnitName = optional +commonName = supplied +emailAddress = optional + +############################## +[ req ] +default_bits = 1024 +default_keyfile = privkey.pem +distinguished_name = req_distinguished_name +attributes = req_attributes +x509_extensions = v3_ca # The extentions to add to the self signed cert + +string_mask = MASK:0x2002 + +[ req_distinguished_name ] +countryName = Country Name (2 letter code) +countryName_default = US +countryName_min = 2 +countryName_max = 2 + +stateOrProvinceName = State or Province Name (full name) +stateOrProvinceName_default = North Carolina + +localityName = Locality Name (eg, city) +localityName_default = Raleigh + +0.organizationName = Organization Name (eg, company) +0.organizationName_default = Fedora Project + +organizationalUnitName = Organizational Unit Name (eg, section) + +commonName = Common Name (eg, your name or your server\'s hostname) +commonName_max = 64 + +emailAddress = Email Address +emailAddress_max = 64 + +[ req_attributes ] +challengePassword = A challenge password +challengePassword_min = 4 +challengePassword_max = 20 + +unstructuredName = An optional company name + +############################## +[ usr_cert ] + +basicConstraints=CA:FALSE +nsComment = "OpenSSL Generated Certificate" +subjectKeyIdentifier=hash +authorityKeyIdentifier=keyid,issuer:always + +############################## +[ v3_ca ] + +subjectKeyIdentifier=hash +authorityKeyIdentifier=keyid:always,issuer:always +basicConstraints = CA:true + +""" % (home)) + + return name + +def argfind(arglist, prefix): + val = None + for arg in arglist: + if arg.startswith('--%s=' % prefix): + val = arg + break + if not val: + return None + val = val.replace('--%s=' % prefix, '') + return val + +if __name__ == '__main__': + prog = sys.argv[0] + if len(sys.argv) < 3: + print_usage(prog) + sys.exit(1) + + outdir = argfind(sys.argv, 'outdir') + if not outdir: + print_usage(prog) + sys.exit(1) + + name = argfind(sys.argv, 'name') + if not name: + print_usage(prog) + sys.exit(1) + + ch = CertHelper(prog, outdir, name) + try: + ch.dispatch(sys.argv[1], sys.argv) + except CertHelperException, e: + print e.message + sys.exit(1) + + sys.exit(0) + diff --git a/modules/fas/files/export-bugzilla.py b/modules/fas/files/export-bugzilla.py new file mode 100755 index 0000000..4b6b416 --- /dev/null +++ b/modules/fas/files/export-bugzilla.py @@ -0,0 +1,68 @@ +#!/usr/bin/python -t +__requires__ = 'TurboGears' +import pkg_resources +pkg_resources.require('CherryPy >= 2.0, < 3.0alpha') + +import sys +import getopt +import xmlrpclib +import turbogears +from turbogears import config +turbogears.update_config(configfile="/etc/export-bugzilla.cfg") +from turbogears.database import session +from fas.model import BugzillaQueue + +BZSERVER = config.get('bugzilla.url', 'https://bugdev.devel.redhat.com/bugzilla-cvs/xmlrpc.cgi') +BZUSER = config.get('bugzilla.username') +BZPASS = config.get('bugzilla.password') + +if __name__ == '__main__': + opts, args = getopt.getopt(sys.argv[1:], '', ('usage', 'help')) + if len(args) != 2 or ('--usage','') in opts or ('--help','') in opts: + print """ + Usage: export-bugzilla.py GROUP BUGZILLA_GROUP + """ + sys.exit(1) + ourGroup = args[0] + bzGroup = args[1] + + server = xmlrpclib.Server(BZSERVER) + bugzilla_queue = BugzillaQueue.query.join('group').filter_by( + name=ourGroup) + + for entry in bugzilla_queue: + # Make sure we have a record for this user in bugzilla + if entry.action == 'r': + # Remove the user's bugzilla group + try: + server.bugzilla.updatePerms(entry.email, 'rem', (bzGroup,), + BZUSER, BZPASS) + except xmlrpclib.Fault, e: + if e.faultCode == 504: + # It's okay, not having this user is equivalent to setting + # them to not have this group. + pass + else: + raise + + elif entry.action == 'a': + # Try to create the user + try: + server.bugzilla.addUser(entry.email, entry.person.human_name, BZUSER, BZPASS) + except xmlrpclib.Fault, e: + if e.faultCode == 500: + # It's okay, we just need to make sure the user has an + # account. + pass + else: + print entry.email,entry.person.human_name + raise + server.bugzilla.updatePerms(entry.email, 'add', (bzGroup,), + BZUSER, BZPASS) + else: + print 'Unrecognized action code: %s %s %s %s %s' % (entry.action, + entry.email, entry.person.human_name, entry.person.username, entry.group.name) + + # Remove them from the queue + session.delete(entry) + session.flush() diff --git a/modules/fas/files/fas-log.cfg b/modules/fas/files/fas-log.cfg new file mode 100644 index 0000000..3f7843d --- /dev/null +++ b/modules/fas/files/fas-log.cfg @@ -0,0 +1,29 @@ +# LOGGING +# Logging is often deployment specific, but some handlers and +# formatters can be defined here. + +[logging] +[[formatters]] +[[[message_only]]] +format='*(message)s' + +[[[full_content]]] +format='*(name)s *(levelname)s *(message)s' + +[[handlers]] +[[[debug_out]]] +class='StreamHandler' +level='DEBUG' +args='(sys.stdout,)' +formatter='full_content' + +[[[access_out]]] +class='StreamHandler' +level='INFO' +args='(sys.stdout,)' +formatter='message_only' + +[[[error_out]]] +class='StreamHandler' +level='ERROR' +args='(sys.stdout,)' diff --git a/modules/fas/files/fas.fedoraproject.org.conf b/modules/fas/files/fas.fedoraproject.org.conf new file mode 100644 index 0000000..7db2e97 --- /dev/null +++ b/modules/fas/files/fas.fedoraproject.org.conf @@ -0,0 +1,13 @@ +# proxy1 - 10.8.32.122 +# proxy2 - 10.8.32.121 +# proxy3 - 66.35.62.166 +# proxy4 - 152.46.7.222 +# proxy5 - 80.239.156.215 + + + + ServerName fas.fedoraproject.org + ServerAdmin admin at fedoraproject.org + + include "conf.d/fas.fedoraproject.org/*.conf + diff --git a/modules/fas/files/fas.fedoraproject.org/logs.conf b/modules/fas/files/fas.fedoraproject.org/logs.conf new file mode 100644 index 0000000..9195af7 --- /dev/null +++ b/modules/fas/files/fas.fedoraproject.org/logs.conf @@ -0,0 +1,2 @@ +CustomLog "| /usr/sbin/rotatelogs /var/log/httpd/fas.fedoraproject.org-access.log.%Y-%m-%d 86400" combined +ErrorLog "| /usr/sbin/rotatelogs /var/log/httpd/fas.fedoraproject.org-error.log.%Y-%m-%d 86400" diff --git a/modules/fas/files/fas.fedoraproject.org/redirect.conf b/modules/fas/files/fas.fedoraproject.org/redirect.conf new file mode 100644 index 0000000..1fc6864 --- /dev/null +++ b/modules/fas/files/fas.fedoraproject.org/redirect.conf @@ -0,0 +1 @@ +Redirect permanent / https://admin.fedoraproject.org/accounts/ diff --git a/modules/fas/files/fas.wsgi b/modules/fas/files/fas.wsgi new file mode 100644 index 0000000..865cc08 --- /dev/null +++ b/modules/fas/files/fas.wsgi @@ -0,0 +1,50 @@ +#!/usr/bin/python +import sys +sys.path.append('/usr/lib/python2.4/site-packages/fas/') +sys.stdout = sys.stderr + +import pkg_resources +pkg_resources.require('CherryPy <= 3.0alpha') + +import os +os.environ['PYTHON_EGG_CACHE'] = '/var/www/.python-eggs' + +import atexit +import cherrypy +import cherrypy._cpwsgi +import turbogears +import turbogears.startup +from formencode.variabledecode import NestedVariables +import fedora.tg.util + +class MyNestedVariablesFilter(object): + def before_main(self): + if hasattr(cherrypy.request, "params"): + cherrypy.request.params_backup = cherrypy.request.params + cherrypy.request.params = \ + NestedVariables.to_python(cherrypy.request.params or {}) + +turbogears.startup.NestedVariablesFilter = MyNestedVariablesFilter + +turbogears.update_config(configfile="/etc/fas.cfg", modulename="fas.config") +turbogears.config.update({'global': {'server.environment': 'production'}}) +turbogears.config.update({'global': {'autoreload.on': False}}) +turbogears.config.update({'global': {'server.log_to_screen': False}}) +turbogears.config.update({'global': {'server.webpath': '/accounts'}}) +turbogears.config.update({'global': {'base_url_filter.on': True}}) +turbogears.config.update({'global': {'base_url_filter.base_url': 'https://admin.fedoraproject.org'}}) +#turbogears.config.update({'global': {'sqlalchemy.recycle': '10'}}) + +turbogears.startup.call_on_startup.append(fedora.tg.util.enable_csrf) + +import fas.controllers + +cherrypy.root = fas.controllers.Root() + +if cherrypy.server.state == 0: + atexit.register(cherrypy.server.stop) + cherrypy.server.start(init_only=True, server_class=None) + +def application(environ, start_response): + environ['SCRIPT_NAME'] = '' + return cherrypy._cpwsgi.wsgiApp(environ, start_response) diff --git a/modules/fas/files/fasSync b/modules/fas/files/fasSync new file mode 100644 index 0000000..4f9f643 --- /dev/null +++ b/modules/fas/files/fasSync @@ -0,0 +1 @@ +24 * * * * root /bin/sleep $(($RANDOM/20)); /usr/bin/fasClient -i > /dev/null 2>&1 diff --git a/modules/fas/files/fedora-ca-client-openssl.cnf b/modules/fas/files/fedora-ca-client-openssl.cnf new file mode 100644 index 0000000..5c3bb15 --- /dev/null +++ b/modules/fas/files/fedora-ca-client-openssl.cnf @@ -0,0 +1,317 @@ +# +# OpenSSL example configuration file. +# This is mostly being used for generation of certificate requests. +# + +# This definition stops the following lines choking if HOME isn't +# defined. +HOME = . +RANDFILE = /var/lib/fedora-ca/.rnd + +# Extra OBJECT IDENTIFIER info: +#oid_file = $ENV::HOME/.oid +oid_section = new_oids + +# To use this configuration file with the "-extfile" option of the +# "openssl x509" utility, name here the section containing the +# X.509v3 extensions to use: +# extensions = +# (Alternatively, use a configuration file that has only +# X.509v3 extensions in its main [= default] section.) + +[ new_oids ] + +# We can add new OIDs in here for use by 'ca' and 'req'. +# Add a simple OID like this: +# testoid1=1.2.3.4 +# Or use config file substitution like this: +# testoid2=${testoid1}.5.6 + +#################################################################### +[ ca ] +default_ca = CA_default # The default ca section + +#################################################################### +[ CA_default ] + +dir = . # Where everything is kept +certs = $dir/certs # Where the issued certs are kept +crl_dir = $dir/crl # Where the issued crl are kept +database = $dir/index.txt # database index file. +#unique_subject = no # Set to 'no' to allow creation of + # several ctificates with same subject. +new_certs_dir = $dir/newcerts # default place for new certs. + +certificate = $dir/cacert.pem # The CA certificate +serial = $dir/serial # The current serial number +crlnumber = $dir/crlnumber # the current crl number + # must be commented out to leave a V1 CRL +crl = $dir/crl.pem # The current CRL +private_key = $dir/private/cakey.pem # The private key +RANDFILE = $dir/private/.rand # private random number file + +x509_extensions = usr_cert # The extentions to add to the cert + +# Comment out the following two lines for the "traditional" +# (and highly broken) format. +name_opt = ca_default # Subject Name options +cert_opt = ca_default # Certificate field options + +# Extension copying option: use with caution. +# copy_extensions = copy + +# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs +# so this is commented out by default to leave a V1 CRL. +# crlnumber must also be commented out to leave a V1 CRL. +# crl_extensions = crl_ext + +default_days = 365 # how long to certify for +default_crl_days= 30 # how long before next CRL +default_md = sha1 # which md to use. +preserve = no # keep passed DN ordering + +# A few difference way of specifying how similar the request should look +# For type CA, the listed attributes must be the same, and the optional +# and supplied fields are just that :-) +policy = policy_match + +# For the CA policy +[ policy_match ] +countryName = match +stateOrProvinceName = match +organizationName = match +organizationalUnitName = optional +commonName = supplied +emailAddress = optional + +# For the 'anything' policy +# At this point in time, you must list all acceptable 'object' +# types. +[ policy_anything ] +countryName = optional +stateOrProvinceName = optional +localityName = optional +organizationName = optional +organizationalUnitName = optional +commonName = supplied +emailAddress = optional + +#################################################################### +[ req ] +default_bits = 2048 +default_md = sha1 +default_keyfile = privkey.pem +distinguished_name = req_distinguished_name +attributes = req_attributes +x509_extensions = v3_ca # The extentions to add to the self signed cert + +# Passwords for private keys if not present they will be prompted for +# input_password = secret +# output_password = secret + +# This sets a mask for permitted string types. There are several options. +# default: PrintableString, T61String, BMPString. +# pkix : PrintableString, BMPString. +# utf8only: only UTF8Strings. +# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). +# MASK:XXXX a literal mask value. +# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings +# so use this option with caution! +# we use PrintableString+UTF8String mask so if pure ASCII texts are used +# the resulting certificates are compatible with Netscape +string_mask = MASK:0x2002 + +# req_extensions = v3_req # The extensions to add to a certificate request + +[ req_distinguished_name ] +countryName = Country Name (2 letter code) +countryName_default = US +countryName_min = 2 +countryName_max = 2 + +stateOrProvinceName = State or Province Name (full name) +stateOrProvinceName_default = North Carolina + +localityName = Locality Name (eg, city) +localityName_default = Raleigh + +0.organizationName = Organization Name (eg, company) +0.organizationName_default = Fedora Project + +# we can do this but it is not needed normally :-) +#1.organizationName = Second Organization Name (eg, company) +#1.organizationName_default = World Wide Web Pty Ltd + +organizationalUnitName = Organizational Unit Name (eg, section) +#organizationalUnitName_default = + +commonName = Common Name (eg, your name or your server\'s hostname) +commonName_max = 64 + +emailAddress = Email Address +emailAddress_max = 64 + +# SET-ex3 = SET extension number 3 + +[ req_attributes ] +#challengePassword = A challenge password +#challengePassword_min = 0 +#challengePassword_max = 20 + +unstructuredName = An optional company name + +[ usr_cert ] + +# These extensions are added when 'ca' signs a request. + +# This goes against PKIX guidelines but some CAs do it and some software +# requires this to avoid interpreting an end user certificate as a CA. + +basicConstraints=CA:FALSE + +# Here are some examples of the usage of nsCertType. If it is omitted +# the certificate can be used for anything *except* object signing. + +# This is OK for an SSL server. +# nsCertType = server + +# For an object signing certificate this would be used. +# nsCertType = objsign + +# For normal client use this is typical +# nsCertType = client, email + +# and for everything including object signing: +# nsCertType = client, email, objsign + +# This is typical in keyUsage for a client certificate. +# keyUsage = nonRepudiation, digitalSignature, keyEncipherment + +# This will be displayed in Netscape's comment listbox. +nsComment = "OpenSSL Generated Certificate" + +# PKIX recommendations harmless if included in all certificates. +subjectKeyIdentifier=hash +authorityKeyIdentifier=keyid,issuer + +# This stuff is for subjectAltName and issuerAltname. +# Import the email address. +# subjectAltName=email:copy +# An alternative to produce certificates that aren't +# deprecated according to PKIX. +# subjectAltName=email:move + +# Copy subject details +# issuerAltName=issuer:copy + +#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem +#nsBaseUrl +#nsRevocationUrl +#nsRenewalUrl +#nsCaPolicyUrl +#nsSslServerName + +[ v3_req ] + +# Extensions to add to a certificate request + +basicConstraints = CA:FALSE +keyUsage = nonRepudiation, digitalSignature, keyEncipherment + +[ v3_ca ] + + +# Extensions for a typical CA + + +# PKIX recommendation. + +subjectKeyIdentifier=hash + +authorityKeyIdentifier=keyid:always,issuer:always + +# This is what PKIX recommends but some broken software chokes on critical +# extensions. +#basicConstraints = critical,CA:true +# So we do this instead. +basicConstraints = CA:true + +# Key usage: this is typical for a CA certificate. However since it will +# prevent it being used as an test self-signed certificate it is best +# left out by default. +# keyUsage = cRLSign, keyCertSign + +# Some might want this also +# nsCertType = sslCA, emailCA + +# Include email address in subject alt name: another PKIX recommendation +# subjectAltName=email:copy +# Copy issuer details +# issuerAltName=issuer:copy + +# DER hex encoding of an extension: beware experts only! +# obj=DER:02:03 +# Where 'obj' is a standard or added object +# You can even override a supported extension: +# basicConstraints= critical, DER:30:03:01:01:FF + +[ crl_ext ] + +# CRL extensions. +# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. + +# issuerAltName=issuer:copy +authorityKeyIdentifier=keyid:always,issuer:always + +[ proxy_cert_ext ] +# These extensions should be added when creating a proxy certificate + +# This goes against PKIX guidelines but some CAs do it and some software +# requires this to avoid interpreting an end user certificate as a CA. + +basicConstraints=CA:FALSE + +# Here are some examples of the usage of nsCertType. If it is omitted +# the certificate can be used for anything *except* object signing. + +# This is OK for an SSL server. +# nsCertType = server + +# For an object signing certificate this would be used. +# nsCertType = objsign + +# For normal client use this is typical +# nsCertType = client, email + +# and for everything including object signing: +# nsCertType = client, email, objsign + +# This is typical in keyUsage for a client certificate. +# keyUsage = nonRepudiation, digitalSignature, keyEncipherment + +# This will be displayed in Netscape's comment listbox. +nsComment = "OpenSSL Generated Certificate" + +# PKIX recommendations harmless if included in all certificates. +subjectKeyIdentifier=hash +authorityKeyIdentifier=keyid,issuer:always + +# This stuff is for subjectAltName and issuerAltname. +# Import the email address. +# subjectAltName=email:copy +# An alternative to produce certificates that aren't +# deprecated according to PKIX. +# subjectAltName=email:move + +# Copy subject details +# issuerAltName=issuer:copy + +#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem +#nsBaseUrl +#nsRevocationUrl +#nsRenewalUrl +#nsCaPolicyUrl +#nsSslServerName + +# This really needs to be in place for it to be a proxy certificate. +proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo diff --git a/modules/fas/files/nsswitch.conf b/modules/fas/files/nsswitch.conf new file mode 100644 index 0000000..fb4ff62 --- /dev/null +++ b/modules/fas/files/nsswitch.conf @@ -0,0 +1,45 @@ +# /etc/nsswitch.conf +# +# An example Name Service Switch config file. This file should be +# sorted with the most-used services at the beginning. +# +# The entry '[NOTFOUND=return]' means that the search for an +# entry should stop if the search in the previous entry turned +# up nothing. Note that if the search failed due to some other reason +# (like no NIS server responding) then the search continues with the +# next entry. +# +# Legal entries are: +# +# nisplus or nis+ Use NIS+ (NIS version 3) +# nis or yp Use NIS (NIS version 2), also called YP +# dns Use DNS (Domain Name Service) +# files Use the local files +# db Use the local database (.db) files +# compat Use NIS on compat mode +# hesiod Use Hesiod for user lookups +# [NOTFOUND=return] Stop searching if not found so far +# + +passwd: db files +shadow: db files +group: db files + +#hosts: db files nisplus nis dns +hosts: files dns + +bootparams: nisplus [NOTFOUND=return] files + +ethers: files +netmasks: files +networks: files +protocols: files +rpc: files +services: files + +netgroup: files + +publickey: nisplus + +automount: files +aliases: files nisplus diff --git a/modules/fas/manifests/init.pp b/modules/fas/manifests/init.pp new file mode 100644 index 0000000..a8074db --- /dev/null +++ b/modules/fas/manifests/init.pp @@ -0,0 +1,307 @@ +# Fedora account system Configuration + +class fas::fas { + package { fas-clients: ensure => present } + package { python-fedora: ensure => present } + + # Set a default group if one has not been explicitly defined + if $groups { + $notGroup = '' + } else { + $groups = 'sysadmin-main' + } + if $sshGroups { + $notSshGroup = '' + } else { + $sshGroups = '' + } + if $restrictedApp { + $notRestrictedApp = '' + } else { + $restrictedApp = '/usr/bin/cvs server' + } + + file { "/etc/nsswitch.conf": + source => "puppet:///fas/nsswitch.conf" + } + + file { '/etc/fas.conf': + content => template('fas/fas.conf.erb'), + mode => '0600', + + } +# exec { 'make-accounts': +# command => '/usr/bin/fasClient -e; /usr/bin/fasClient -i', +# subscribe => Templatefile['/etc/fas.conf'], +# require => Package['fas-clients'], +# refreshonly => true +# } + + file { '/etc/cron.d/fasSync': + source => 'puppet:///fas/fasSync', + require => Package[fas-clients], + } + + file { "/root/bin/": + ensure => directory, + } + + file { '/etc/sudoers': + source => "puppet:///config/secure/sudoers", + mode => 0440, + owner => root, + group => root + } +} + +class fas::fas-proxy inherits httpd { + file { "/etc/httpd/conf.d/admin.fedoraproject.org/accounts.conf": + source => 'puppet:///fas/accounts-proxy.conf', + notify => Service['httpd'], + } + + file { '/etc/httpd/conf.d/fas.fedoraproject.org.conf': + source => 'puppet:///fas/fas.fedoraproject.org.conf', + notify => Service['httpd'], + } + + file { '/etc/httpd/conf.d/fas.fedoraproject.org/': + source => 'puppet:///fas/fas.fedoraproject.org/', + recurse => true, + notify => Service['httpd'], + } + + file { '/etc/httpd/conf.d/accounts.fedoraproject.org.conf': + source => 'puppet:///fas/accounts.fedoraproject.org.conf', + notify => Service['httpd'] + } + + file { '/etc/httpd/conf.d/accounts.fedoraproject.org/': + source => 'puppet:///fas/accounts.fedoraproject.org/', + recurse => true, + notify => Service['httpd'], + } + +} + +class fas::fas-server-base inherits turbogears { + $bugzillaUser='fedora-admin-xmlrpc at redhat.com' + include httpd + include mod_wsgi-package + + package { fas: ensure => present } + + package { fas-plugin-asterisk: ensure => present } + + ### HACK: Need to solve this better later + file { '/usr/lib/python2.4/site-packages/fas/fas.wsgi': + source => 'puppet:///fas/fas.wsgi', + require => Package['mod_wsgi'], + notify => Service['httpd'] + } + + file { '/var/www/.python-eggs': + ensure => directory, + mode => '0700', + owner => 'apache', + require => Package['httpd'] + } + + file { '/etc/fas-gpg': + ensure => directory, + mode => '0700', + owner => 'fas', + group => 'fas', + require => Package['fas'], + } + + file { '/etc/fas-gpg/secring.gpg': + source => 'puppet:///config/secure/accounts-secring.gpg', + owner => 'fas', + group => 'fas', + mode => 600, + require => File['/etc/fas-gpg'] + } + + file { '/etc/fas-gpg/pubring.gpg': + owner => 'fas', + group => 'fas', + mode => 600, + replace => false, + ensure => file, + source => 'puppet:///fas/accounts-pubring.gpg', + } + + file { '/etc/httpd/conf.d/accounts.conf': + source => 'puppet:///fas/accounts.conf', + require => Package['mod_wsgi'], + } + + file { '/etc/pki/fas': + ensure => directory, + mode => '0700', + owner => 'fas', + group => 'fas', + } + # These are both public certs so there's no reason to hide them + file { '/etc/pki/fas/fedora-server-ca.cert': + source => 'puppet:///config/secure/fedora-ca.cert', + } + + file { '/etc/pki/fas/fedora-upload-ca.cert': + source => 'puppet:///config/secure/fedora-ca.cert', + } + + file { '/etc/export-bugzilla.cfg': + content => template('fas/export-bugzilla.cfg.erb'), + owner => 'fas', + # Contains passwords so it needs to be restricted + mode => '0640' + } + + # Note: This will move into the fas rpm soon + file { "/usr/local/bin/export-bugzilla.py": + source => "puppet:///fas/export-bugzilla.py", + mode => 0755, + } + + file { '/usr/share/fas/static/fedora-server-ca.cert': + source => 'puppet:///config/secure/fedora-ca.cert', + owner => 'apache', + group => 'sysadmin-main', + mode => '0440', + require => Package['httpd'] + } + + file { '/usr/share/fas/static/fedora-upload-ca.cert': + source => 'puppet:///config/secure/fedora-ca.cert', + owner => 'apache', + group => 'sysadmin-main', + mode => '0440' + } + + file { '/usr/lib/python2.4/site-packages/fas/config/log.cfg': + source => 'puppet:///fas/fas-log.cfg', + owner => 'root', + group => 'root', + notify => Service['httpd'], + require => Package['httpd'], + mode => '0644' + } +} + +class fas::fas-server inherits fas-server-base { + + $genCert = 'False' + file { '/etc/fas.cfg': + content => template('fas/fas-prod.cfg.erb'), + owner => 'fas', + group => 'apache', + notify => Service['httpd'], + require => Package['httpd'], + mode => '640' + } + +} + +class fas::fas-server-gencert inherits fas-server-base { + + $genCert = 'True' + file { '/etc/fas.cfg': + content => template('fas/fas-prod.cfg.erb'), + owner => 'fas', + group => 'apache', + notify => Service['httpd'], + require => Package['httpd'], + mode => '640' + } + + # These should be created by the fas package later + file { '/var/lock/fedora-ca': + ensure => directory, + mode => '0700', + owner => 'fas', + group => 'fas', + require => Package[fas], + } + + file { '/var/lib/fedora-ca': + ensure => directory, + mode => '0771', + owner => 'fas', + group => 'sysadmin-main', + require => Package[fas], + } + + file { '/var/lib/fedora-ca/newcerts': + ensure => directory, + mode => '0770', + owner => 'fas', + group => 'sysadmin-main', + require => Package[fas], + } + + file { '/var/lib/fedora-ca/private': + ensure => directory, + mode => '0750', + owner => 'fas', + group => 'sysadmin-main' + } + + # For publishing the crl + file { '/srv/web/ca': + ensure => directory, + mode => '0755', + owner => 'apache', + group => 'apache' + } + + file { '/var/lib/fedora-ca/Makefile': + source => 'puppet:///fas/Makefile.fedora-ca', + mode => '0644' + } + + file { '/var/lib/fedora-ca/openssl.cnf': + source => 'puppet:///fas/fedora-ca-client-openssl.cnf', + mode => '0644' + } + + file { '/var/lib/fedora-ca/certhelper.py': + source => 'puppet:///fas/certhelper.py', + mode => '0750', + owner => 'root', + group => 'sysadmin-main' + } + + + # Public keys don't need restrictive permissions + file { '/var/lib/fedora-ca/cacert.pem': + source => 'puppet:///config/secure/fedora-ca.cert', + mode => '0444' + } + + # First of every month, force a new crl to be created + cron { gen-crl: + command => "cd /var/lib/fedora-ca ; /usr/bin/make gencrl &> /dev/null", + user => "apache", + minute => 0, + hour => 0, + monthday => [ 1, 15 ], + } + + file { '/srv/web/ca/crl.pem': + ensure => '/var/lib/fedora-ca/crl/crl.pem' + } +} + +# Note: path will change when it moves into the fas rpm +class fas::fas-no-balance { + cron { export-bugzilla: + command => "/usr/local/bin/export-bugzilla.py fedorabugs fedora_contrib", + user => "fas", + minute => 10, + ensure => present, + require => Package['fas'], + environment => "MAILTO=root" + } +} diff --git a/modules/fas/templates/export-bugzilla.cfg.erb b/modules/fas/templates/export-bugzilla.cfg.erb new file mode 100644 index 0000000..6c65f07 --- /dev/null +++ b/modules/fas/templates/export-bugzilla.cfg.erb @@ -0,0 +1,11 @@ +[global] +# bugzilla.url = https://bugdev.devel.redhat.com/bugzilla-cvs/xmlrpc.cgi +# Running from fas1 so we need the PHX available address. +bugzilla.url = "https://bzprx.vip.phx.redhat.com/xmlrpc.cgi" +# bugzilla.url = "https://bugzilla.redhat.com/xmlrpc.cgi" +bugzilla.username = "<%= bugzillaUser %>" +bugzilla.password = "<%= bugzillaPassword %>" + +# At the moment, we have to extract this information directly from the fas2 +# database. We can build a json interface for it at a later date. +sqlalchemy.dburi = "postgres://fas:<%= fasDbPassword %>@db2/fas2" diff --git a/modules/fas/templates/fas-prod.cfg.erb b/modules/fas/templates/fas-prod.cfg.erb new file mode 100644 index 0000000..11cac5a --- /dev/null +++ b/modules/fas/templates/fas-prod.cfg.erb @@ -0,0 +1,163 @@ +[global] +samadhi.baseurl = 'https://admin.fedoraproject.org/' + +admingroup = 'accounts' +systemgroup = 'fas-system' +thirdpartygroup = 'thirdparty' + +theme = 'fas' + +accounts_email = "accounts at fedoraproject.org" +legal_cla_email = "legal-cla-archive at fedoraproject.org" + +email_host = "fedoraproject.org" # as in, web-members at email_host + +gpgexec = "/usr/bin/gpg" +gpghome = "/etc/fas-gpg" +gpg_fingerprint = "7662 A6D3 4F21 A653 7BD4 BA64 20A0 8C45 4A0E 6255" +gpg_passphrase = "<%= fasGpgPassphrase %>" +gpg_keyserver = "hkp://subkeys.pgp.net" + +cla_done_group = "cla_done" +cla_fedora_group = "cla_fedora" + +privileged_view_groups = "(^fas-.*)" +username_blacklist = "abuse,accounts,adm,admin,amanda,apache,askfedora,asterisk,bin,board,bodhi2,canna,chair,chairman,cvsdirsec,cvsdocs,cvseclipse,cvsextras,cvsfont,daemon,dbus,decode,desktop,dgilmore,directors,dovecot,dumper,famsco,fax,fedorarewards,fesco,freemedia,ftp,ftpadm,ftpadmin,games,gdm,gopher,gregdek,halt,hostmaster,ident,info,ingres,jaboutboul,jan,keys,ldap,legal,logo,lp,mail,mailnull,manager,marketing,mysql,nagios,named,netdump,news,newsadm,newsadmin,nfsnobody,nobody,noc,nrpe,nscd,ntp,nut,openvideo,operator,packager,pcap,pkgdb,pkgsigner,postfix,postgres,postmaster,press,privoxy,pvm,quagga,radiusd,radvd,relnotes,root,rpc,rpcuser,rpm,sales,scholarship,secalert,security,shutdown,smmsp,squid,sshd,support,sync,system,tickets,toor,updates,usenet,uucp,vcsa,vendors,voting,webalizer,webmaster,wikiadmin,wnn,www,xfs,zabbix" + +openidstore = "/var/tmp/fas/openid" + +# Enable or disable generation of SSL certificates for users +gencert = <%= genCert %> + +makeexec = "/usr/bin/make" +openssl_lockdir = "/var/lock/fedora-ca" +openssl_digest = "md5" +openssl_expire = 15552000 # 60*60*24*180 = 6 months +openssl_ca_dir = "/var/lib/fedora-ca" +openssl_ca_newcerts = "/var/lib/fedora-ca/newcerts" +openssl_ca_index = "/var/lib/fedora-ca/index.txt" +openssl_c = "US" +openssl_st = "North Carolina" +openssl_l = "Raleigh" +openssl_o = "Fedora Project" +openssl_ou = "Fedora User Cert" + +# Groups that automatically grant membership to other groups +# Format: 'group1:a,b,c|group2:d,e,f' +auto_approve_groups = 'packager:fedorabugs|cla_fedora:cla_done|cla_redhat:cla_done|cla_dell:cla_done|cla_ibm:cla_done' + +# This is where all of your settings go for your development environment +# Settings that are the same for both development and production +# (such as template engine, encodings, etc.) all go in +# fas/config/app.cfg + +mail.on = True +mail.server = 'bastion' +#mail.testmode = True +mail.debug = False +mail.encoding = 'utf-8' + +# DATABASE + +# pick the form for your database +# sqlobject.dburi="postgres://username at hostname/databasename" +# sqlobject.dburi="mysql://username:password at hostname:port/databasename" +# sqlobject.dburi="sqlite:///file_name_and_path" + +# If you have sqlite, here's a simple default to get you started +# in development +sqlalchemy.dburi="postgres://fas:<%= fasDbPassword %>@db2/fas2" +sqlalchemy.echo=False + +# if you are using a database or table type without transactions +# (MySQL default, for example), you should turn off transactions +# by prepending notrans_ on the uri +# sqlobject.dburi="notrans_mysql://username:password at hostname:port/databasename" + +# for Windows users, sqlite URIs look like: +# sqlobject.dburi="sqlite:///drive_letter:/path/to/file" + +# SERVER + +# Some server parameters that you may want to tweak +server.socket_port=8088 +server.thread_pool=50 +server.socket_queue_size=30 + +# FAS2 is mmuch busier than other servers due to serving visit and auth via +# JSON. +# Double pool_size +#sqlalchemy.pool_size=10 +# And increase overflow above what other servers have +#sqlalchemy.max_overflow=25 +# When using wsgi, we want the pool to be very low (as a separate instance is +# run in each apache mod_wsgi thread. So each one is going to have very few +# concurrent db connections. +sqlalchemy.pool_size=1 +sqlalchemy.max_overflow=2 + +# Enable the debug output at the end on pages. +# log_debug_info_filter.on = False + +server.environment="production" +autoreload.package="fas" + +# session_filter.on = True + +# Set to True if you'd like to abort execution if a controller gets an +# unexpected parameter. False by default +tg.strict_parameters = True +tg.ignore_parameters = ["_csrf_token"] + +server.webpath='/accounts' +base_url_filter.on = True +base_url_filter.use_x_forwarded_host = True +base_url_filter.base_url = "https://admin.fedoraproject.org" + +# Make the session cookie only return to the host over an SSL link +visit.cookie.secure = True +session_filter.cookie_secure = True + +[/fedora-server-ca.cert] +static_filter.on = True +static_filter.file = "/etc/pki/fas/fedora-server-ca.cert" + +[/fedora-upload-ca.cert] +static_filter.on = True +static_filter.file = "/etc/pki/fas/fedora-upload-ca.cert" + +# LOGGING +# Logging configuration generally follows the style of the standard +# Python logging module configuration. Note that when specifying +# log format messages, you need to use *() for formatting variables. +# Deployment independent log configuration is in fas/config/log.cfg +[logging] + +[[loggers]] +[[[fas]]] +level='DEBUG' +qualname='fas' +handlers=['debug_out'] + +[[[allinfo]]] +level='INFO' +handlers=['debug_out'] + +#[[[access]]] +#level='INFO' +#qualname='turbogears.access' +#handlers=['access_out'] +#propagate=0 + +[[[identity]]] +level='INFO' +qualname='turbogears.identity' +handlers=['access_out'] +propagate=0 + +[[[database]]] +# Set to INFO to make SQLAlchemy display SQL commands +level='ERROR' +qualname='sqlalchemy.engine' +handlers=['debug_out'] +propagate=0 diff --git a/modules/fas/templates/fas.conf.erb b/modules/fas/templates/fas.conf.erb new file mode 100644 index 0000000..d8a3e05 --- /dev/null +++ b/modules/fas/templates/fas.conf.erb @@ -0,0 +1,78 @@ +[global] +; url - Location to fas server +url = https://admin.fedoraproject.org/accounts/ + +; temp - Location to generate files while user creation process is happening +temp = /var/db + +; login - username to contact fas +login = systems + +; password - password for login name +password = <%= systemsUserPassword %> + +; prefix - install to a location other than / +prefix = / + +[host] +; Group hierarchy is 1) groups, 2) restricted_groups 3) ssh_restricted_groups +; so if someone is in all 3, the client behaves the same as if they were just +; in 'groups' + +; groups that should have a shell account on this system. +<% if groups != "NONE" %> +groups = <%= groups %> +<% else %> +groups = sysadmin-main +<% end %> +; groups that should have a restricted account on this system. +; restricted accounts use the restricted_shell value in [users] +restricted_groups = + +; ssh_restricted_groups: groups that should be restricted by ssh key. You will +; need to disable password based logins in order for this value to have any +; security meaning. Group types can be placed here as well, for example +; @hg, at git, at svn +<% if sshGroups %> +ssh_restricted_groups = <%= sshGroups %> +<% else %> +ssh_restricted_groups = +<% end %> + +; aliases_template: Gets prepended to the aliases file when it is generated by +; fasClient +aliases_template = /etc/aliases.template + +[users] +; default shell given to people in [host] groups +shell = /bin/bash + +; home - the location for fas user home dirs +home = /home/fedora + +; home_backup_dir - Location home dirs should get moved to when a user is +; deleted this location should be tmpwatched +home_backup_dir = /home/fedora.bak + +; ssh_restricted_app - This is the path to the restricted shell script. It +; will not work automatically for most people though through alterations it +; is a powerfull way to restrict access to a machine. An alternative example +; could be given to people who should only have cvs access on the machine. +; setting this value to "/usr/bin/cvs server" would do this. +<% if restrictedApp %> +ssh_restricted_app = "<%= restrictedApp %>" +<% else %> +ssh_restricted_app = "/usr/bin/cvs server" +<% end %> + +; restricted_shell - The shell given to users in the ssh_restricted_groups +restricted_shell = /sbin/nologin + +; ssh_restricted_shell - The shell given to users in the ssh_restricted_groups +ssh_restricted_shell = /bin/bash + +; ssh_key_options - Options to be appended to people ssh keys. Users in the +; ssh_restricted_groups will have the keys they uploaded altered when they are +; installed on this machine, appended with the options below. +ssh_key_options = no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty + From DistroDoc at lavabit.com Wed Apr 8 21:03:00 2009 From: DistroDoc at lavabit.com (Nattie) Date: Wed, 08 Apr 2009 22:03:00 +0100 Subject: Intro Message-ID: <49DD1104.40002@lavabit.com> Hi there guys, i have used fedora since the day 10 came out, (its the most awesome OS ever), and i wanted to say thanks for all the effort you guys put in. About me: I mainly write programs, but i sometimes do small web things, i pretty much adaptable to every situation. I have good knowledge of python and C/C++, but im not so good with bash or perl. I would like to join the fedora infrastructure and give something back. Im looking foward to meeting you * Nathanael From ricky at fedoraproject.org Fri Apr 10 19:36:55 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Fri, 10 Apr 2009 15:36:55 -0400 Subject: Meeting Log - 2008-04-09 Message-ID: <20090410193655.GA21042@sphe.res.cmu.edu> 15:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 15:01 * yingbull is. 15:01 < mmcgrath> Alrighty everyone, who's around? 15:01 * warren here 15:01 * skvidal is here 15:01 * notting is here 15:01 < mmcgrath> jcollie: you around? 15:02 < jcollie> yup 15:02 < ivazquez> Pong. 15:02 < mmcgrath> cool, lets get started then 15:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 15:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 15:02 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 15:02 * MostafaDaneshvar is there 15:02 < mmcgrath> First ticket: 15:02 < mmcgrath> .ticket 395 15:02 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 15:02 < mmcgrath> jcollie: whats the latest? 15:02 < warren> mmcgrath: is agenda set in stone? I want to add s/cvsextras/packager/ after F9 release and next convenient scheduled outage. 15:03 < mmcgrath> warren: not at all, we pretty much go over tickets now, then a few other items then open the floor. 15:03 < mmcgrath> warren: Remind me if I forget at the end. 15:03 < jcollie> not much has happened... someone horked up a bunch of my virtual hosts at work so i've been busy rebuilding them 15:03 < mmcgrath> jcollie: virtual hosts at $DAYJOB or something related to fedora? 15:03 -!- Wakko666 [n=blentz at office.cardomain.com] has joined #fedora-meeting 15:03 < jcollie> $DAYJOB 15:03 -!- wolfy [n=lonewolf at fedora/wolfy] has left #fedora-meeting ["When you breathe, you inspire. When you do not breathe, you expire."] 15:04 < mmcgrath> just checking ;-) 15:04 < mmcgrath> jcollie: k, so nothing new there. We'll move on. 15:04 < mmcgrath> .ticket 398 15:04 < zodbot> mmcgrath: #398 (elfutils `monotone' (mtn) error) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/398 15:04 * mmcgrath sees if rmcgrath is around. 15:04 < jcollie> i think that those of us that are interested in working on the streaming should set up a separate meeting to divvy up some tasks 15:05 < mmcgrath> jcollie: not a bad idea. It sounds like you've done most of the work already. Its just a matter of getting that last 10% done (and getting the fas integration for the non streamins stuff) 15:05 < jcollie> yep 15:06 < mmcgrath> alrighty, we'll talk about 398 later if rmcgrath becomes available. 15:06 < mmcgrath> My understanding is that we can do it though. 15:06 < mmcgrath> .tickety 446 15:06 < mmcgrath> .ticket 446 15:06 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 15:06 < mmcgrath> doath 15:06 * dgilmore is here 15:07 < mmcgrath> dgilmore: I think last time we talked about you getting this up on the wiki, any news on that? 15:07 < dgilmore> mmcgrath: i started and got sidetracked 15:07 < mmcgrath> dgilmore: ahh, you're still on it though? 15:07 < dgilmore> mmcgrath: will be done by the end of the weekend 15:07 < dgilmore> yep 15:08 < mmcgrath> AFAIK we just have the one spin so far. 15:08 < mmcgrath> dgilmore: sweet, thanks! 15:08 < mmcgrath> Ok, so thats really the end of it on the tickets side. 15:08 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- New Wiki 15:08 < mmcgrath> Just a bit of a roundup on the wiki. I've been working on th emigration script and docbook exporter script. 15:08 < mmcgrath> The people listed on http://fedoraproject.org/wiki/Infrastructure/WikiMigration all met yesterday. 15:09 < mmcgrath> I'm going to schedule a few more meetings but a few bumps aside it sounds like we are a GO. 15:09 < mmcgrath> dgilmore: are you on the FESCo ? 15:09 < dgilmore> mmcgrath: i am 15:09 < mmcgrath> dgilmore: at the next meeting would you find a delegate to sign up to be the wiki liason for those sections of the wiki? 15:10 < mmcgrath> unless you want to do it :) 15:10 < dgilmore> mmcgrath: sure 15:10 < mmcgrath> Thanks. 15:10 < dgilmore> mmcgrath: i think jwb volunteered 15:10 * jwb wakes up 15:10 < jwb> huh? 15:10 * dgilmore notes he will largely be away next week 15:10 < mmcgrath> so https://publictest1.fedoraproject.org/wiki/FedoraMain is still up and ready 15:10 < dgilmore> jwb: wiki migration? 15:10 < mmcgrath> dgilmore: ohhh yeah. you're right. he's on there. 15:11 < jwb> dgilmore, mmcgrath: oh, yeah. i put my name there 15:11 < mmcgrath> dgilmore: I'll be away next week as well. 15:11 < mmcgrath> jwb: sorry I missed it there. 15:11 < jwb> i have no idea what that means 15:11 < jwb> do i have to do something? 15:11 < jwb> it just said "contact point" 15:11 < dgilmore> jwb: you get to be whiped 15:11 < mmcgrath> jwb: not yet, we'll be scheduling a meeing again the week after next. In the meantime just go through https://publictest1.fedoraproject.org/wiki/ and look for... doom. 15:11 < dgilmore> jwb: no Just be a point person. 15:12 < jwb> ok great 15:12 < jwb> either way, count me in 15:12 < mmcgrath> cool. 15:12 < mmcgrath> So thats really the latest on the wiki. 15:12 < mmcgrath> Anyone have any questions or concerns? 15:13 < mmcgrath> allrighty, moving on 15:13 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Next week 15:13 < mmcgrath> I'll be gone again next week for training. Its the last traing session I actually have scheduled. 15:13 < mmcgrath> So during the days I'll be unavailable but I'll likely be around most evenings. 15:14 < mmcgrath> Next topic 15:14 < dgilmore> mmcgrath: ill be in Brazil 15:14 * skvidal will be here 15:14 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- nfs1 15:14 < skvidal> people can call/page me 15:14 < skvidal> ugh 15:14 < skvidal> nfs1 15:14 < mmcgrath> NFS1 got built yesterday in a hurry. 15:14 < mmcgrath> while working on xen2 the nfslock issues showed up again then the whole box took a panic. 15:15 < mmcgrath> we'd been serving nfs directly from xen2 so when it goes down the buildsystem goes down. 15:15 < mmcgrath> Anyway, we brought nfs1 up as a RHEL4 box to try to fix the nfs issues, they might have fixed nfs issues but brought on ext3 issues since we're using a 10T ext3 filesystem... 15:15 < mmcgrath> RHEl4 couldn't handle it and started to ioerror. 15:15 < mmcgrath> So I kicked a RHEL5 box and its now nfs1. 15:16 < mmcgrath> Its up, its running. 15:16 < mmcgrath> so far no nfslock issues, if we do get one though we're going to contact steved while its in the bad state and give him a shell to look around. 15:16 < dgilmore> mmcgrath: lets get steved a shell on xen2 and let him monitor nfs1 15:16 < mmcgrath> Really nothing new here except that /mnt/koji is no longer available on xen2, its now on nfs1. 15:17 < mmcgrath> dgilmore: you never know, perhaps magically moving to nfs1 fixed our problem :) 15:17 < mmcgrath> we'll see. 15:17 * skvidal likes magic 15:17 < dgilmore> mmcgrath: we can hope 15:17 < dgilmore> skvidal: voodoo magic is best 15:17 < mmcgrath> heheh 15:17 * skvidal makes a doll of dgilmore 15:17 < mmcgrath> Ok, next item. 15:17 < dgilmore> skvidal: need some hair and fingernails? 15:18 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- s/cvsextras/packagers/ 15:18 < mmcgrath> warren: ping? 15:18 < warren> hi 15:18 < mmcgrath> warren: so we're just going to rename cvsextras to packagers. 15:18 < mmcgrath> which involves 15:18 < warren> So f13 suggested we rename the group after F9 release, at the first scheduled outage. 15:18 < warren> mmcgrath: packager, singular 15:18 < mmcgrath> 1) updating the db. 15:19 < mmcgrath> 2) updating the scripts (and upload script) 15:19 < mmcgrath> 3) updating the documentation 15:19 < mmcgrath> 4) testing? 15:19 < mmcgrath> I really don't think this will be that huge of a deal. 15:19 < mmcgrath> warren: I'll try to get it done sometime the week after F9 ships. Would you mind opening a ticket and bugging me about it that week? 15:19 < warren> mmcgrath: ok 15:20 < warren> mmcgrath: are there any other group names we should rename as well? 15:20 < f13> warren: lets keep the name that will make sense in the future given my newmaintianercontainment proposal 15:20 < warren> as long as we have an outage 15:20 < f13> warren: since I hope to get an intern to work on that this summer 15:20 < warren> f13: is this the one from 2 months ago or so? 15:20 < mmcgrath> warren: yeah we'll schedule an outage. 15:20 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has quit Remote closed the connection 15:20 < f13> warren: http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment 15:21 < mmcgrath> I'm not sure about other group names. 15:21 < warren> Let's ask around 15:21 < warren> there might be other names people want to do 15:21 < warren> f13: ok seems we need to figure out a bigger picture plan then 15:22 < warren> mmcgrath: will get back to you 15:22 < mmcgrath> warren: works for me, lets know well in advance of the outage know because renaming cvsextras I have a pretty good idea of what needs to be done. 15:22 < mmcgrath> but for another group I might not know without more research. 15:22 < mmcgrath> k 15:22 < mmcgrath> warren: when its all ready just create a ticket and bug me. I think we could have it done in an hour or two some night after F9 ships. 15:22 < f13> warren: well, we don't necessarly have to wait to rename 'cvsextras' to /somethihng/ 15:23 < f13> warren: 'fedorapackager' or whatever seems fine, we can pick a name that implies /greater/ rights later 15:23 < warren> f13: I do agree to rename it within the larger plan 15:23 < f13> or less rights. 15:23 < warren> f13: I'm still in favor of numbers instead of group names for that 15:23 < warren> but we're getting off topic 15:23 < mmcgrath> you guys figure that out :) 15:24 < mmcgrath> anyone have any questions about that? We've got plenty of time to discuss it. 15:24 < mmcgrath> if not I'll move on. 15:24 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- app server upgrades. 15:24 < mmcgrath> abadger1999: ping? 15:25 < mmcgrath> I believe toshio wants to upgrade sqlalchemy and python-fedora before the freeze. I think we're on schedule to do that but I'll have to get ahold of him to find out for sure. 15:25 < mmcgrath> which brings me to the next topic 15:25 < abadger1999> here. 15:25 < mmcgrath> oh 15:25 < mmcgrath> there you are :) 15:25 < abadger1999> Today. 15:26 < mmcgrath> abadger1999: want to talk about all of that right quick? 15:26 < abadger1999> Want to do it today/tonight. 15:26 < abadger1999> It would be to both app servers. 15:26 < mmcgrath> abadger1999: "both" ? 15:26 < mmcgrath> which? 15:26 < abadger1999> app4 and app5 15:26 < mmcgrath> app2 is also running tg apps 15:26 < abadger1999> Oh. I was not aware. 15:27 < dgilmore> mmcgrath: i want the new python-fedora 15:27 < abadger1999> then we wantto upgrade that as well. 15:27 < abadger1999> We can issue a new python-fedora for everything if we want. 15:27 < mmcgrath> abadger1999: your call I'm not sure what we'd be comitting to with the new package. 15:27 < abadger1999> Or we can update that when we do the other updates from RHEL, etc. 15:27 < mmcgrath> what are the risks / benefits? 15:27 < mmcgrath> and will this break transifex? 15:28 < abadger1999> All the FAS1 stuff has been removed. Only FAS2 stuff is in it. 15:28 < abadger1999> there's been some rearrangement of modules but the old imports should work with a deprecation warning. 15:28 < mmcgrath> k 15:29 < mmcgrath> sounds pretty low risk, and we can always revert if required. 15:29 < abadger1999> 15:29 < mmcgrath> abadger1999: I'm fine for any time this week on that, if you want me around just ping me or call me. 15:29 < mmcgrath> abadger1999: anything else on that? 15:30 < abadger1999> Nope that's it. 15:30 < mmcgrath> cool. 15:30 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- app5 15:30 < mmcgrath> So yeah, I don't know WTF is going on but app5 is rebooting... a LOT 15:30 < mmcgrath> this comes after the move from x86_64 to i686 15:30 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has joined #fedora-meeting 15:30 < mmcgrath> we're talking between 20-40 times a DAY. 15:30 < mmcgrath> very very strange. 15:30 < mmcgrath> I've got a stack trace, I'm going to try to take it to the virt guys soon. 15:31 < mmcgrath> side note though, aside from that, the i686 move (also done on app2) has proved quite successful memory usage (and therefor swap) is way down. 15:31 < mmcgrath> its been a big win for us. 15:31 < mmcgrath> anyone have any questions / comments? 15:31 -!- viking-ice [n=johannbg at dsl-149-97-225.hive.is] has joined #fedora-meeting 15:31 < mmcgrath> Alrighty, then I'll move on to the last topic of the day before opening the floor. 15:32 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Change Freeze! 15:32 < mmcgrath> This one's for everyone 15:32 < mmcgrath> REMEMBER 15:32 < mmcgrath> DO NOT MAKE ANY CHANGES WITHOUT GETTING APPROVAL ON THE LIST FIRST! 15:32 < mmcgrath> and remember, you'll be asked the question "Why can't this wait until after F9 gets released" 15:33 < mmcgrath> I'll be gone much of next week which makes the freeze perfect. 15:33 < warren> under pain of 15:33 * mmcgrath looks up exact date again 15:33 < mmcgrath> warren: under pain of CURSE! 15:33 < skvidal> under pain of pain 15:33 < warren> I can advise against pain. 15:34 < mmcgrath> There we go, so the freeze starts the 15th. The release is on the 29th. The freeze is lifted on the 30th. 15:34 < yingbull> pain's scary. 15:34 < mmcgrath> Obvious exceptions include outages and things already scheduled for the release (mm type stuff, the website, etc) 15:34 < mmcgrath> other then that. you must get approval on the list before making changes. If you're working on tickets and people get cranky, just let them know we're under a freeze. 15:34 < skvidal> mmcgrath: it's okay to bring up new boxes unrelated to the release? 15:34 < ivazquez> Should we hold it until the Monday following? 15:35 < skvidal> mmcgrath: ie: if I get all the statics, etc from BU 15:35 < mmcgrath> skvidal: take it to the list! But yeah, that shouldn't be a problem. 15:35 < skvidal> mmcgrath: will do 15:35 < mmcgrath> ivazquez: I thought about that, in the past though, for the most part, things settled down from the release the day after. 15:36 < ivazquez> Okay. 15:36 < mmcgrath> anyone have any questions / comments about that? 15:36 < mmcgrath> alrighty, then we'll open the floor 15:36 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 15:36 * dgilmore has nothing right now 15:36 < mmcgrath> Anyone have anything they'd like to discuss? A release is coming, lots of stuff has been going on. 15:37 < notting> how are we ensuring the ability to get the bits to our tier0 mirrors? 15:37 < mmcgrath> notting: same as we had been, AFAIK our mirror system (and I2) is functional again. 15:37 < notting> that's not what mdomsch's mail implied 15:37 < mmcgrath> notting: which email and when? 15:38 < notting> to mirror-list 15:38 < dgilmore> notting: no, it implied a work around was setup 15:38 < dgilmore> mmcgrath: a couple of hours ago 15:38 < dgilmore> mmcgrath: 2 boxes were setup for Tier 0 I2 masters 15:39 < mmcgrath> that was my understanding. We don't have the permanent solution in place but a working one. 15:39 < mmcgrath> we'll probably want to make sure the working one stays as is until after the 30th. 15:39 < dgilmore> mmcgrath: they have static I2 routes to dl.fedora.redhat.com boxes 15:39 < mmcgrath> notting: I'll follow up with mdomsch to make sure whats going on there. 15:39 < mmcgrath> .any mdomsch 15:39 < zodbot> mmcgrath: mdomsch was last seen in #fedora-meeting 1 hour, 9 minutes, and 24 seconds ago: *** mdomsch has quit IRC (Remote closed the connection) 15:39 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has quit Remote closed the connection 15:40 < mmcgrath> Alrighty, anyone have anything else to discuss? 15:40 < dgilmore> nope 15:40 < mmcgrath> k, we'll close the meeting in 30 15:41 < mmcgrath> 15 15:41 < mmcgrath> 5 15:41 < notting> dgilmore: so, the static route & download1 are bandwidth-unclogged enough to sync OK? 15:41 < dgilmore> Thanks mmcgrath :) 15:41 < notting> dgilmore: with no one using it, are we sure that download1 is synced? :) 15:41 < dgilmore> notting: i believe so. 15:42 < mmcgrath> notting: we'll have to talk to them to find out for sure. 15:42 * mmcgrath just sent an email to mdomsch to verify. 15:42 < notting> maybe i'm paranoid 15:42 < mmcgrath> notting: you're once bitten. 15:42 < mmcgrath> nothing wrong with that. The fact is the whole I2 connection thing showed a major problem we have. and the fact that galgoci is the _only_ person at Red hat with access and no how to fix it is much less comforting. 15:43 < dgilmore> notting: i believe download1 is down 15:43 < mmcgrath> even his backup told us that he was really the only guy we'd want doing that. 15:44 -!- k0k [n=k0k at fedora/k0k] has quit Connection timed out 15:44 < mmcgrath> notting: we'll just have to wait and see if what we think mdomsch said is actually the way things are. That mirror has been down since before Feb 20th so its hard to say the state of things (considering they only just recently got back up and running) 15:44 < mmcgrath> Anywho, not much we can do but check with the mirrors list and mdomsch and make sure everyone's happy with where things are for the release. 15:44 < mmcgrath> Anyone have anything else? If not we'll close the meeting in 30 15:45 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has joined #fedora-meeting 15:45 < mmcgrath> 10 15:45 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed 15:45 < mmcgrath> Thanks for coming everone! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Fri Apr 10 21:11:21 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Fri, 10 Apr 2009 17:11:21 -0400 Subject: Meeting Log - 2008-04-09 In-Reply-To: <20090410193655.GA21042@sphe.res.cmu.edu> References: <20090410193655.GA21042@sphe.res.cmu.edu> Message-ID: <20090410211121.GA24335@sphe.res.cmu.edu> Oops, as Jon pointed out, that log was from one year ago. Here's the correct one: 20:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 < mmcgrath> So who's around? 20:00 * jds2001 hereish 20:00 * SmootherFrOgZ is 20:00 * ricky 20:01 < mdomsch> yo 20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:01 < mmcgrath> .ticket 1203 20:01 < zodbot> mmcgrath: #1203 (RFR: x86_64 host for composing spins) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1203 20:02 -!- gregdek [n=gdk at nat/redhat/x-803c841bcf9f0628] has quit Read error: 110 (Connection timed out) 20:02 < mmcgrath> kanarip: you around? 20:03 < mmcgrath> well, even if he's not we shouldn't have any blockers on this right now. 20:03 < mmcgrath> I finally got a Fedora install to work thanks to some #virt guys and I can get this up and going, just needs some time. 20:03 < mmcgrath> That's really all there is on that one. 20:03 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Xen13 20:03 < mmcgrath> This is just a roundup of some stuff that happened last week. 20:03 * abadger1999 shos up 20:03 < mmcgrath> xen13 died a couple of times. 20:03 < jds2001> throw xen13 from a high place :) 20:04 < mmcgrath> Not sure why yet. The RSAII adapter died as well which was quite strange. 20:04 < mmcgrath> So between crashes I started building bastion2 (more on that in a sec) 20:04 < mmcgrath> and did a kernel update. 20:04 -!- brothers [n=brothers at rrcs-24-103-64-162.nyc.biz.rr.com] has quit Read error: 110 (Connection timed out) 20:04 < mmcgrath> the next crash booted the newer libvirt and kernel versions and it hasn't crashed since. 20:04 < mmcgrath> So I still dont' know if this was hardware related or software related. 20:04 < mmcgrath> Needless to say, bastion was a major spof of ours for both mail and vpn. 20:05 < mmcgrath> now we're doing heartbeat between bastion1 adn bastion2. 20:05 < mmcgrath> This is good 20:05 -!- brothers__ is now known as brothers 20:05 < mmcgrath> but has one small side issue. 20:05 < mmcgrath> If you store stuff on bastion in your home dir. 20:05 < mmcgrath> make note that that part doesn't balance. and while I could nfsmount those home dirs, bastion's not really for that anyway so I'm just going to leave it. 20:05 -!- brothers_ [n=brothers at 208.46.128.30] has quit Read error: 110 (Connection timed out) 20:05 < mmcgrath> we (admins) can copy stuff back and forth for now. 20:06 < mmcgrath> I'd still like to split smtp and vpn infrastructure out but that's not a major requirement at the moment with all the other stuff we have going on. 20:06 < mmcgrath> So any questions on that? 20:06 -!- izaac [n=izaac at fedora/izaac] has joined #fedora-meeting 20:06 -!- izaac [n=izaac at fedora/izaac] has quit Remote closed the connection 20:06 * abadger1999 notes people will have to get used to tunneling when running scp. 20:06 < mmcgrath> abadger1999: yeah, I've been using proxycommand for that and it's worked wonderfuly 20:06 < mmcgrath> as always... refer to the security policy with ssh questions :) 20:07 < mmcgrath> well, not as always but from now on anyway :) 20:07 < mmcgrath> it works remarkably well. 20:07 < abadger1999> ls 20:07 < mmcgrath> Ok, so not too much new there. 20:08 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Wiki Upgrade 20:08 < mmcgrath> jds2001: so that got blocked on a plugin right? 20:08 < jds2001> yea, i packaged up the new plugin after talking with nigel 20:08 < mmcgrath> ah, excellent. 20:08 < mmcgrath> So really that might be in good shape soon? 20:08 < jds2001> it seems to work, but the Special:Version page still shows 1.13.5....wondering why. 20:09 < mmcgrath> jds2001: hope you didn't mind me dropping that on your lap, I know you've not really worked with the wiki before. 20:09 < mmcgrath> jds2001: could be cached in /var/cache/mediawiki 20:09 < jds2001> mmcgrath: not a bit, great learning experience :) 20:09 < mmcgrath> I've not seen josemm in a bit, I wonder if he's been busy this week 20:10 < jds2001> yeah, I have and he's in India iirc. 20:10 < jds2001> so when I'm around in the evenings generally may not be good for him. 20:10 < mmcgrath> yeah 20:10 < mmcgrath> we'll figure something out 20:12 * hanthana is too late :( 20:12 < jds2001> but I can finish this out myself if need be. 20:12 < mmcgrath> hanthana: no worries 20:12 < hanthana> mmcgrath: :) 20:12 < mmcgrath> So nothing else there. 20:12 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Cloud Stuff 20:13 < mmcgrath> So lots of buzz about the cloud stuff, G, SmootherFrOgZ and I have been poking at hardware and getting things up and going. 20:13 < mmcgrath> It's been going well 20:13 < mmcgrath> Still nothing to show for it really, i'm still working to make sure various people have the right access to things. 20:14 < mmcgrath> Anyone have any questions there? 20:14 < mmcgrath> I still have a lot of documentation to do. 20:15 < mmcgrath> SmootherFrOgZ: do you know if it's possible to setup our dns servers to relay for only specific subnets? 20:15 < jds2001> mmcgrath: for reverse? 20:15 < mmcgrath> forward 20:15 < jds2001> yeah, that can be done. 20:15 < SmootherFrOgZ> yes 20:15 -!- lillian [n=lillian at nat/redhat/x-7e29cbf8d3de7c05] has left #fedora-meeting ["I quit."] 20:16 < jds2001> oh, yeah, bind can do that too :) 20:16 * jds2001 thought you were talking about reverse delegations :) 20:16 < mmcgrath> bind does everything and my mother. 20:16 < mmcgrath> SmootherFrOgZ: can you setup our bind install to allow our public cloud subnet (and whatever the nat address of our private network on cstore1 is) to relay? 20:17 < SmootherFrOgZ> no pb 20:17 < mmcgrath> Ideally we'd have one local, but I'm worried about bootstrap issues if we put it in a guest. 20:17 < mmcgrath> plus this way we only have one type of dns server 20:18 < SmootherFrOgZ> 20:18 * nirik nods and points at views in bind. You can do whatever you like there. 20:18 < mmcgrath> the only thing it still doesn't have that I wish it had (out of the box anyway) is geoip 20:18 < mmcgrath> Anywho, any questions about the cloud stuff? 20:20 < mmcgrath> K 20:20 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Beta release 20:20 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 20:21 < mmcgrath> So the beta release went fine. 20:21 < mmcgrath> Unfortunately I was away that day and my mirror rediness script was teh fail 20:21 < mmcgrath> mdomsch: so I don't have any fancy graphs this time around. 20:21 < mdomsch> mmcgrath, no problem 20:21 < mmcgrath> but we'll get it for the production release again. 20:21 < mmcgrath> For those that were here, how'd it all go? 20:21 < mdomsch> I hope the changes I've made this week will make it easier to track 20:22 < mmcgrath> excellent 20:22 < mmcgrath> mdomsch: you've been hard at work at that, how's it all going? 20:22 < mdomsch> fwiw, my new MM feature of the week is the rsyncFilter generation 20:22 < mdomsch> now to get mirrors to use it... 20:22 < mdomsch> basically, it lets a mirror request of MM 20:23 < mdomsch> "give me an rsync exclude/include list for what has changed since XXXX" 20:23 -!- brothers_ [n=brothers at 208.46.128.30] has joined #fedora-meeting 20:23 < mmcgrath> mdomsch: I think that will be well received 20:23 < mdomsch> to reduce load on the masters doing millions of stat() calls per mirror 20:23 -!- u0m3_ [n=radualex at 86.121.23.213] has quit Read error: 110 (Connection timed out) 20:23 < hanthana> mdomsch: sorry, whats MM? 20:23 -!- MostafaDaneshvar [n=MostafaD at unaffiliated/mostafadaneshvar] has joined #fedora-meeting 20:23 < mdomsch> oh, and mirrors.fp.o publiclist version chooser is clean now 20:23 < mdomsch> hanthana, mirrormanager 20:23 < hanthana> mdomsch: thanks 20:23 -!- sharkcz [n=dan at plz1-v-4-17.static.adsl.vol.cz] has quit "Ukon?uji" 20:24 < mmcgrath> http://mirrors.fedoraproject.org/ and https://admin.fedoraproject.org/mirrormanager/ 20:24 < mdomsch> that's all for me 20:24 < mmcgrath> mdomsch: what about the mod_wsgi stuff? 20:24 < mdomsch> mmcgrath, oh yeah, that's all done now 20:24 < mdomsch> and live on all bapp1 + app* 20:25 < mmcgrath> hah, well done, I didn't even notice. 20:25 < mmcgrath> Well splended. 20:25 < mmcgrath> mdomsch: anything else there? 20:25 < mdomsch> nope 20:25 < mmcgrath> cool 20:25 < mmcgrath> anyone have anything else to comment on the beta release? 20:26 < mmcgrath> K, so with that I'll open the floor for discussion 20:26 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:26 < mmcgrath> Anyone have anything to discuss? 20:27 * mmcgrath listens to crickets. 20:27 < mmcgrath> Ok, well if no one has anything I'll close the meeting in 30 20:27 -!- brothers__ [n=brothers at rrcs-24-103-64-162.nyc.biz.rr.com] has joined #fedora-meeting 20:27 < jds2001> the cubs suck, but that's a standing thing since forever :D 20:28 < mmcgrath> jds2001: I don't think I have op in here. 20:28 < mmcgrath> which is lucky for you! 20:28 < mmcgrath> hanthana: got anything? :) 20:28 < hanthana> i am new to this channel and i am much interested on joining fedora-infra team 20:28 < mmcgrath> hanthana: well it's good you came to the meeting. 20:29 < mmcgrath> Was there any particular project or FIG you were interested in working on? 20:29 * mmcgrath notes it seems the wordpress-mu stuff is on hold again, might be good to pick up 20:29 < hanthana> mmcgrath: i did not send a mail to infra mailing list as i need much time see whats happening here 20:29 < hanthana> and lot to know :) 20:30 < mmcgrath> hanthana: well most of the cool stuff that happens happens on irc, but we try to discuss major changes (and even smaller ones) on the infrastructure list. 20:30 < mmcgrath> hanthana: what timezone are you in? Whats some of your background? 20:30 < hanthana> ok 20:31 < hanthana> i am Danishka from Sri Lanka 20:31 < hanthana> +5.30GMT 20:31 < hanthana> i am a RHCT 20:32 < hanthana> close to IST time zone 20:32 < mmcgrath> 20:33 < mmcgrath> hanthana: Ok, well it's good you came to the meeting and feel free to participate in #fedora-admin. 20:33 < mmcgrath> If no one has anything else we'll close the meeting in 30 so people can get back to work :) 20:33 < hanthana> mmcgrath: thanks again 20:34 * mmcgrath 10 20:34 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting End 20:34 < mmcgrath> thanks for coming everyone! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From opensource at openwallet.de Sat Apr 11 23:52:41 2009 From: opensource at openwallet.de (Wiora, Matthias) Date: Sun, 12 Apr 2009 01:52:41 +0200 (CEST) Subject: Fedora & me =) Message-ID: <4201112ed09fc3b686f7ff337ca14240.squirrel@webmail.openwallet.de> Hello you all over there ;) My name is Matthias Wiora - I'm from germany, 18 years old and I'm using Fedora since now more than 4 years. It's time to get involved. In business I'm a system Engineer :) I've made my experiences in Virtualisation with XEN and VMware, Datastore-Management in Datacore and OpenE, Database-Managment MSSQL and MySQL (interested in Oracle!), System Administration Microsoft Server 2k8 & Terminal-Server-Administration Server 2k3 + Citrix XenApp, Debian 4/5, End-User Support of Windows XP/Vista (Certified by MS 70-270) and Fedora Clients :) I'd like to get involed in the Fedora Server Management & Administration processes. It's also possible to meet some else in Germany, Austria, Switzerland or London. well... you'd like to know more about me? http://openwallet.de :) Well... That's for all. Any questions? ahhhh... my hobbies: Playing Piano, Biking & Programming AtMega Processors (c++) ;) greetings from Germany, ?atthias (counterroot) P.S.: Sry for the bad english. I'm trying to get better ;) From josemanimala at gmail.com Sun Apr 12 03:29:48 2009 From: josemanimala at gmail.com (josemanimala at gmail.com) Date: Sun, 12 Apr 2009 03:29:48 +0000 Subject: Fedora & me =) Message-ID: <570175135-1239506604-cardhu_decombobulator_blackberry.rim.net-1105648335-@bxe1002.bisx.produk.on.blackberry> Hey there matt welcome. To fedora. You can go through the fedora wiki at http://fedoraproject.org and look at fedora infrastructurs SIG. That's where we deal with administration. Btw hope you love it here. Best wishes Jose ------Original Message------ From: Wiora, Matthias Sender: fedora-infrastructure-list-bounces at redhat.com To: fedora-infrastructure-list at redhat.com ReplyTo: opensource at openwallet.de ReplyTo: Fedora Infrastructure Subject: Fedora & me =) Sent: Apr 12, 2009 5:22 AM Hello you all over there ;) My name is Matthias Wiora - I'm from germany, 18 years old and I'm using Fedora since now more than 4 years. It's time to get involved. In business I'm a system Engineer :) I've made my experiences in Virtualisation with XEN and VMware, Datastore-Management in Datacore and OpenE, Database-Managment MSSQL and MySQL (interested in Oracle!), System Administration Microsoft Server 2k8 & Terminal-Server-Administration Server 2k3 + Citrix XenApp, Debian 4/5, End-User Support of Windows XP/Vista (Certified by MS 70-270) and Fedora Clients :) I'd like to get involed in the Fedora Server Management & Administration processes. It's also possible to meet some else in Germany, Austria, Switzerland or London. well... you'd like to know more about me? http://openwallet.de :) Well... That's for all. Any questions? ahhhh... my hobbies: Playing Piano, Biking & Programming AtMega Processors (c++) ;) greetings from Germany, ?atthias (counterroot) P.S.: Sry for the bad english. I'm trying to get better ;) _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list Sent on my BlackBerry? from Vodafone Essar From thinklinux.ssh at gmail.com Sun Apr 12 15:01:21 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Sun, 12 Apr 2009 20:31:21 +0530 Subject: I want to change a TRAC's workflow. Message-ID: Hi, I would like to include two more resolutions to "resolve as:" field of the freemedia trac[1]. my questions are: 1. Does all the trac use same trac.ini? I can find only one trac.ini by $locate 2. If yes, what may be the possible way to change only this particular trac's behaviour. If not, where is the particular trac.ini file stored? And do I have access to it or should I file a ticket? Thanks. [1]https://fedorahosted.org/freemedia/ -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India From jonstanley at gmail.com Sun Apr 12 18:21:10 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 12 Apr 2009 14:21:10 -0400 Subject: I want to change a TRAC's workflow. In-Reply-To: References: Message-ID: On Sun, Apr 12, 2009 at 11:01 AM, susmit shannigrahi wrote: > 1. Does all the trac use same trac.ini? I can find only one trac.ini by $locate No, there are some global settings, but most stuff is in /srv/web/trac//conf/trac.ini > If not, where is the particular trac.ini file stored? And do I have > access to it or should I file a ticket? Anyone in sysadmin-hosted has access to change this for you (the files are owned by apache so that the web admin plugin can make changes to them. I looked in the web interface and I don't see a way to change this particular thing though....) However, looking at the trac documentation, customizable workflows were introduced in 0.11. We''re currently running Trac 0.10. So this may not even be possible with what we currently have.There's currently a request to upgrade to 0.11, but that's a fairly non-trivial task for an installation of 250+ projects :) From johe.stephan at googlemail.com Mon Apr 13 14:33:14 2009 From: johe.stephan at googlemail.com (=?ISO-8859-1?Q?J=F6rg_Stephan?=) Date: Mon, 13 Apr 2009 16:33:14 +0200 Subject: so then me Message-ID: <644549460904130733t26ea1810q8cc2ccaa72b465bc@mail.gmail.com> Hi all, so i've somelse introducing themselfs, so maybe i should introduce myself to. My name is Joerg Stephan and i'am close to 30 years now. Iam from the south-west of Germany (Saarland if someone wanne know) and i'am currently trying to finish my study of mathematik and computer science. I work also as system administrator in a research facility at university. Ia, using Linux for several years now, startet with RedHat 5.1 some years ago (maybe 1998 or so) and switched over to some other Unix/Linux Distributions since that. Now i find Fedora the right place to sattle down. I'am working on: Nagios Systemmonitoring and building plugins in python and perl. Automation scripts as hostlist and configuration using m4 and python. Administration Vmware, PostgreSQL and MySQL DB, several Servers (dhcp, apache, tomcat, samba, ltsp etc) So thats something about me, have a nice day Joerg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Apr 13 21:37:06 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 13 Apr 2009 16:37:06 -0500 (CDT) Subject: Introduction In-Reply-To: References: Message-ID: On Wed, 8 Apr 2009, Mayuresh Kulkarni wrote: > Hello folks, > > I have been a fedora user for a couple of months now and I would like > to thank you all for this wonderful distro! About me - I am a > programmer, working mostly in the systems programming domain. I am > quite comfortable with C/C++ but not so much with Python or with bash > scripting. I would like to help out with something where I can pick up > one of these two. I have done projects with Python, (mostly to avoid > Perl ;) ) , but am far from being a native. > > I unfortunately will not be able to attend the meetings on Thursday > but I will hang out in IRC to try to get a feel for the current > action. > > Looking forward to meeting you all :) > Mayuresh. > Hello Mayuresh, if you're good with C/C++ you might want to look at joining the bugzappers group. While we work on the servers to support the OS, they actually improve Fedora by finding and submitting patches, your skill set could do well there. If you still want to do infrastructure hanging out in #fedora-admin is the best place to start... and if you have time for it you can do both bugzappers and infrastructure ;) -Mike > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Mon Apr 13 21:39:04 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 13 Apr 2009 16:39:04 -0500 (CDT) Subject: Intro In-Reply-To: <49DD1104.40002@lavabit.com> References: <49DD1104.40002@lavabit.com> Message-ID: On Wed, 8 Apr 2009, Nattie wrote: > Hi there guys, > > i have used fedora since the day 10 came out, (its the most awesome OS ever), > and i wanted to say thanks for all the effort you guys put in. > About me: I mainly write programs, but i sometimes do small web things, i > pretty much adaptable to every situation. I have good knowledge of python and > C/C++, but im not so good with bash or perl. I would like to join the fedora > infrastructure and give something back. > > Im looking foward to meeting you * > Nathanael > Welcome Nathanael, were if you are interested in hacking on some of our turbogears / python applications let us know! Also you should look at the bugzappers group as they're always interested in C/C++ programmers. -Mike From mmcgrath at redhat.com Mon Apr 13 21:45:17 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 13 Apr 2009 16:45:17 -0500 (CDT) Subject: so then me In-Reply-To: <644549460904130733t26ea1810q8cc2ccaa72b465bc@mail.gmail.com> References: <644549460904130733t26ea1810q8cc2ccaa72b465bc@mail.gmail.com> Message-ID: On Mon, 13 Apr 2009, J?rg Stephan wrote: > Hi all, > > so i've somelse introducing themselfs, so maybe i should introduce myself to. > > My name is Joerg Stephan and i'am close to 30 years now. Iam from the south-west of Germany (Saarland if someone wanne > know) and i'am currently trying to finish my study of mathematik and computer science. > I work also as system administrator in a research facility at university. > Ia, using Linux for several years now, startet with RedHat 5.1 some years ago (maybe 1998 or so) and switched over to > some other Unix/Linux Distributions since that. Now i find Fedora the right place to sattle down. > > I'am working on: > Nagios Systemmonitoring and building plugins in python and perl. > Automation scripts as hostlist and configuration using m4 and python. > Administration Vmware, PostgreSQL and MySQL DB, several Servers (dhcp, apache, tomcat, samba, ltsp etc) > Excellent, you're in the right place. Was there something in particular you were interested in working on? Are you able to attend our weekly meetings? http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike From johe.stephan at googlemail.com Mon Apr 13 22:00:00 2009 From: johe.stephan at googlemail.com (=?ISO-8859-1?Q?J=F6rg_Stephan?=) Date: Tue, 14 Apr 2009 00:00:00 +0200 Subject: so then me In-Reply-To: References: <644549460904130733t26ea1810q8cc2ccaa72b465bc@mail.gmail.com> Message-ID: <644549460904131500r677c3a17ue904af83a4ec7332@mail.gmail.com> Hi Mike, well, so nothing in particular yet. I think i just gonne have look on some parts. But if you know something just tell me. I think i can be on the meetings not every week but hope so mostly. Greets Joerg 2009/4/13 Mike McGrath > > On Mon, 13 Apr 2009, J?rg Stephan wrote: > > Excellent, you're in the right place. ?Was there something in particular > you were interested in working on? ?Are you able to attend our weekly > meetings? > > http://fedoraproject.org/wiki/Infrastructure/Meetings > > ? ? ? ?-Mike > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From itamar at ispbrasil.com.br Mon Apr 13 23:20:31 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 13 Apr 2009 20:20:31 -0300 Subject: Intro In-Reply-To: References: <49DD1104.40002@lavabit.com> Message-ID: Mike Can you recommend something to learn python and turbogears fast ? > Welcome Nathanael, were if you are interested in hacking on some of our > turbogears / python applications let us know! ?Also you should look at the > bugzappers group as they're always interested in C/C++ programmers. > > ? ? ? ?-Mike > ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From carlos at santiviago.com Tue Apr 14 00:02:37 2009 From: carlos at santiviago.com (Carlos Eduardo Pedroza Santiviago) Date: Mon, 13 Apr 2009 21:02:37 -0300 Subject: Introduction Message-ID: Hi all, My name is Carlos Eduardo Pedroza Santiviago, i'm a sysadmin from Brazil, where i mainly work with UNIX/Linux servers administration. I have LPIC-3 Certification, and have worked with Linux for 10+ years. My interest in Fedora (Red Hat) has increased recently, since i mostly used Debian/Ubuntu before. And because of that, I'll have my RHCE exam on Friday, and i guess i'll be fine! :-) I have experience in tasks automation, administration of services, clustering, and a lot of interest in the security field. I'd like to join the devel FIG if possible, and if you are a sponsor, please do not hestitate to contact me. I *really* would like to help. Best Regards, -- Carlos Eduardo Pedroza Santiviago -- http://softwarelivre.net From itamar at ispbrasil.com.br Tue Apr 14 00:14:49 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 13 Apr 2009 21:14:49 -0300 Subject: Introduction In-Reply-To: References: Message-ID: bem vindo, o pessoal de infraestrutura precisa de pessoas com conhecimento em python/turbogears. e o pessoal do desenvolvimento precisa de pessoas com conhecimento em c/++ sinta-se a vontade em me contactar. n Mon, Apr 13, 2009 at 9:02 PM, Carlos Eduardo Pedroza Santiviago wrote: > Hi all, > > My name is Carlos Eduardo Pedroza Santiviago, i'm a sysadmin from > Brazil, where i mainly work with UNIX/Linux servers administration. I > have LPIC-3 Certification, and have worked with Linux for 10+ years. > My interest in Fedora (Red Hat) has increased recently, since i mostly > used Debian/Ubuntu before. And because of that, I'll have my RHCE exam > on Friday, and i guess i'll be fine! :-) > > I have experience in tasks automation, administration of services, > clustering, and a lot of interest in the security field. I'd like to > join the devel FIG if possible, and if you are a sponsor, please do > not hestitate to contact me. I *really* would like to help. > > Best Regards, > > -- > Carlos Eduardo Pedroza Santiviago -- http://softwarelivre.net > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From bashton at brennanashton.com Tue Apr 14 02:26:50 2009 From: bashton at brennanashton.com (Brennan Ashton) Date: Mon, 13 Apr 2009 19:26:50 -0700 Subject: Intro In-Reply-To: References: <49DD1104.40002@lavabit.com> Message-ID: <981da310904131926v65ae7d7n8f2d6d818f5b4df6@mail.gmail.com> On Mon, Apr 13, 2009 at 4:20 PM, Itamar Reis Peixoto wrote: > Mike > > Can you recommend something to learn python and turbogears fast ? > > > >> Welcome Nathanael, were if you are interested in hacking on some of our >> turbogears / python applications let us know! ?Also you should look at the >> bugzappers group as they're always interested in C/C++ programmers. >> >> ? ? ? ?-Mike >> > > ------------ > > Itamar Reis Peixoto Itamar, If you are interested in helping with a turbogears project. I would be very interested in having your help in the traigeweb project that I am writing for Fedora. In terms of resources, the turbogears webpage is a good start. I also use this book [1] as a reference/tutorial at times, for the most part it is a good book, addressees both beginner and advanced topics. You can find me in #fedora-bugzappers as comphappy. [1] http://turbogearsbook.com/ Best Regards, Brennan Ashton From vinaya.amatya at gmail.com Tue Apr 14 03:35:43 2009 From: vinaya.amatya at gmail.com (Vinay Amatya) Date: Mon, 13 Apr 2009 22:35:43 -0500 Subject: Hi In-Reply-To: References: Message-ID: Hi Mike, For the timebeing, I'm not sure I can hangout on Thursdays for the meeting(I can do that after a couple of weeks). I did log in once, but didn't know who to contact.... Please let me know what I should start looking into, and I could put questions if there are any ambiguities. cheers, Vinay 2009/4/3 Mike McGrath > On Fri, 3 Apr 2009, Vinay Amatya wrote: > > > Hi All, > > > > I'm Vinay. I got upto here while trying to fix my installation of > Fedora-10. I've been steady user of Fedora package for > > a little more than a year. I like it better, as I learn more in Fedora > environment than on other platforms. > > Regarding contributing to the Project, I'm a newbie. I'm interested in > core infrastructure development/maintainance. > > I'm comfortable with C, C++, Java. I'd like to learn Python, or Ruby, if > I get a project/task that makes me do it. > > > > Boy oh boy do we love programmers. If you'd like to help I've got a few > smaller tasks that you could do while you get to learning python. If you > want to go through some of the basic tutorials of python then install fas > come find me on irc.freenode.net in #fedora-admin and we'll talk about > some stuff. > > > At this stage, I'd like to observe the kinds of problems > this(infrastructure) team handles, possibly learn some stuffs, > > and contribute where possible. > > > > You're always welcome to observe and learn whatever stuffs you want ;-) > > -Mike > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at lisas.de Tue Apr 14 07:19:25 2009 From: adrian at lisas.de (Adrian Reber) Date: Tue, 14 Apr 2009 09:19:25 +0200 Subject: remove andreas.kupfer@stw-bonn.de from mirror-admin alias Message-ID: <20090414071925.GG30340@lisas.de> Can somebody please remove andreas.kupfer at stw-bonn.de from the mirror-admin at fedoraproject.org alias? Everytime I sent a mail to mirror-admin I get following error since a few days (maybe even weeks): : permission denied. Command output: maildrop: maildir over quota. maildrop: maildir over quota. maildrop: maildir over quota. Adrian From sts at ono.at Tue Apr 14 11:59:29 2009 From: sts at ono.at (Stefan Schlesinger) Date: Tue, 14 Apr 2009 13:59:29 +0200 Subject: STS45-RIPE Message-ID: <960D2674-2F89-483A-B245-51A0999C58FB@ono.at> Hello Folks! I'm writing you to let you know about my interest to join the FIG. My name ist Stefan, I'm 23 Years old, living in Austria/Vienna and working as a systems engineer at an Austrian ISP Company (we do a lot of sponsoring for F/OSS projects as well ;-). We mostly use Debian/Linux for our business, but I used RedHat/Fedora before. ;-) Currently I have about 6 years of experiance as a system administrator. I'm pretty familiar with all sorts of sysop tasks (networking, virtualization, scripting in perl/python/bash, ticketing systems, infrastructure automation eg. puppet/cfengine, ldap, web technoligies, mail, dns, databases, packaging, technical documentation, etc). I couldn't decide on which FIG group to choose yet, but eventually fedora-web or fedora-noc would be suitable... Feel free to contact me, I'm on IRC (freenode/#fedora-admin/sts) as well, with best regards, Stefan. -- Stefan Schlesinger \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\ \\\\\\\ sts at ono.at STS45-RIPE From jonstanley at gmail.com Tue Apr 14 13:14:37 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 14 Apr 2009 09:14:37 -0400 Subject: remove andreas.kupfer@stw-bonn.de from mirror-admin alias In-Reply-To: <20090414071925.GG30340@lisas.de> References: <20090414071925.GG30340@lisas.de> Message-ID: On Tue, Apr 14, 2009 at 3:19 AM, Adrian Reber wrote: > > Can somebody please remove andreas.kupfer at stw-bonn.de from the > mirror-admin at fedoraproject.org alias? Everytime I sent a mail to > mirror-admin I get following error since a few days (maybe even weeks): Yeah, what I'll do is setup a mailman list for mirror-admin and let mailman handle the bounces. Right now it's just an alias in /etc/aliases. I should have some time to get this done today. From jhrozek at redhat.com Tue Apr 14 13:22:06 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 14 Apr 2009 15:22:06 +0200 Subject: RFR: A test box for running an LDAP server for SSSD test day Message-ID: <1239715327.10208.109.camel@zeppelin.englab.brq.redhat.com> == Primary Contact == Name: Jakub Hrozek Fedora Account Name: jhrozek Group: Fedora Packager CVS Commit Group '''Infrastructure Sponsor''': == Secondary Contact info == Name: Simo Sorce Fedora Account Name: simo Group: Fedora Packager CVS Commit Group == Project Info == Project Name: A test box running an LDAP server for SSSD test day Target Audience: SSSD Test Day participants Expiration/Delivery Date (required): 2009-04-30 (this is the Test day date) Description/Summary: A test box running an LDAP server for SSSD test day. Project plan (Detailed): A Fedora Directory Server, or a FreeIPA instance, is needed to perform full testing of SSSD (there is a draft How to test on the Feature Page, I'll rework that into a better test plan this week). I'm not sure if we can ask the test day participants to go through the process of configuring their own instance and even if they had one on their local machine, it wouldn't allow them to test the online caching feature of SSSD properly. There are several options, the best of them is to have an LDAP server with test data available for the community to test on. Therefore, I'd like to ask the Fedora Infrastructure team to provide us with a temporary test box where we could install and configure FDS. The box would be needed until the test day (2009-04-30), can be removed afterwards. I understand that getting a root access for the box might not be possible - I can provide an install script and an LDIF file that would bootstrap the FDS instance in that case. However, getting a sudo for controlling the FDS instance (ldapmodify, restart the service, view the logs) would be very nice. Goals: Provide the test day participants with an easy test environment. == Specific resources needed == N/A == Additional Info (Optional) == As per the time *before* the test day, it would be handy if we had the test instance for 1-2 weeks prior to the test day. I hope all the necessary information is included either here or in the ticket itself. I'll be happy to answer questions about this RFR. Thank you for the consideration, Jakub Hrozek From Axel.Thimm at ATrpms.net Tue Apr 14 17:37:31 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Apr 2009 20:37:31 +0300 Subject: rpm-4.6.x & friends for RHEL5 (was: hosts for rawhide build chroots - different rpm versions?) In-Reply-To: <200903221153.10378.dennis@ausil.us> References: <20090322100241.GA11378@victor.nirvana> <200903221153.10378.dennis@ausil.us> Message-ID: <20090414173731.GA3438@victor.nirvana> Hi, On Sun, Mar 22, 2009 at 11:53:09AM -0500, Dennis Gilmore wrote: > On Sunday 22 March 2009 05:02:41 am Axel Thimm wrote: > > AFAIK the build hosts are RHEL5 (or maybe F10 by now?). At any rate > > the rpm used in rawhide is quite different than the ones from the > > hosts, how has this been solved in the build hosts? Has the hosting OS > > upgraded its rpm to be compatible to all hosted chroots? Or is the rpm > > within the chroot used? > > > > I'm asking in a double context: First I'd like to understand if smart > > can properly handle chroots of rawhide/F11 on F10/RHEL5 hosts. Anders > > Bj?rklund (in the Cc, please keep him there on replies) has put a > > great deal of effort to have smart working on F10 and F11, and a smart > > version for managing F11 and later chroots on F10 or earlier would be > > great. > > > > And second I'd like to know how to setup a build environment for F11 > > for getting some ATrpms packages out. > > > we are running a version of rpm 4.6.0 on rhel5. This is only so mock can > populate chroots with rpms with stronger hashes rhel5's rpm doesnt support. > All srpm creation now takes place in chroots so features of the target rpm are > always available. > > rpm in F-10 updates is compatible with the new rpm features. but rpm from F-9 > and RHEL4 and 5 can not handle the new rpm at all. you cannot make chroots on > them with rawhide rpms. > > > you could use koji on F-10/rawhide or F-9/RHEL5 by replacing the hosts rpm to > build your packages. Thanks for the explanation, Dennis. Can I get these tailored rpm rpms from somewhere? I just tried rebuilding rpm from rawhide on RHEL5 and the dependencies look endless. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jeff at ocjtech.us Tue Apr 14 18:15:21 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 14 Apr 2009 13:15:21 -0500 Subject: rpm-4.6.x & friends for RHEL5 (was: hosts for rawhide build chroots - different rpm versions?) In-Reply-To: <20090414173731.GA3438@victor.nirvana> References: <20090322100241.GA11378@victor.nirvana> <200903221153.10378.dennis@ausil.us> <20090414173731.GA3438@victor.nirvana> Message-ID: <935ead450904141115g378b1275vd48d3039edfa8ec3@mail.gmail.com> On Tue, Apr 14, 2009 at 12:37 PM, Axel Thimm wrote: > > On Sun, Mar 22, 2009 at 11:53:09AM -0500, Dennis Gilmore wrote: >> >> we are running a version of rpm 4.6.0 on rhel5. ?This is only so mock can >> populate chroots with rpms with stronger hashes rhel5's rpm doesnt support. >> All srpm creation now takes place in chroots so features of the target rpm are >> always available. > > Thanks for the explanation, Dennis. Can I get these tailored rpm rpms > from somewhere? I just tried rebuilding rpm from rawhide on RHEL5 and > the dependencies look endless. http://infrastructure.fedoraproject.org/ -- Jeff Ollie From mmcgrath at redhat.com Tue Apr 14 18:33:09 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 14 Apr 2009 13:33:09 -0500 (CDT) Subject: Infrastructure Freeze Message-ID: Just a reminder guys, our infrastructure will be in a change freeze starting at the end of the day today. The preview release will ship on the 28th. http://fedoraproject.org/wiki/ISOP:RELEASE#Change_Freeze This is a pre-release freeze, not the full freeze. -Mike From thinklinux.ssh at gmail.com Tue Apr 14 18:38:08 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Wed, 15 Apr 2009 00:08:08 +0530 Subject: Infrastructure Freeze In-Reply-To: References: Message-ID: On Wed, Apr 15, 2009 at 12:03 AM, Mike McGrath wrote: > Just a reminder guys, our infrastructure will be in a change freeze > starting at the end of the day today. ?The preview release will ship on > the 28th. > > http://fedoraproject.org/wiki/ISOP:RELEASE#Change_Freeze > > This is a pre-release freeze, not the full freeze. I can see freeze for publictest[1+] in the document. Does that mean 1 onwards? More specifically, is publictest15 freezed? -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India From mmcgrath at redhat.com Tue Apr 14 18:49:10 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 14 Apr 2009 13:49:10 -0500 (CDT) Subject: Infrastructure Freeze In-Reply-To: References: Message-ID: On Wed, 15 Apr 2009, susmit shannigrahi wrote: > On Wed, Apr 15, 2009 at 12:03 AM, Mike McGrath wrote: > > Just a reminder guys, our infrastructure will be in a change freeze > > starting at the end of the day today. ?The preview release will ship on > > the 28th. > > > > http://fedoraproject.org/wiki/ISOP:RELEASE#Change_Freeze > > > > This is a pre-release freeze, not the full freeze. > > I can see freeze for publictest[1+] in the document. > Does that mean 1 onwards? It does > More specifically, is publictest15 freezed? > It is not inside the freeze bubble on that doc so it is not frozen (the publictest servers are never frozen) -Mike From thinklinux.ssh at gmail.com Tue Apr 14 18:50:23 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Wed, 15 Apr 2009 00:20:23 +0530 Subject: Infrastructure Freeze In-Reply-To: References: Message-ID: > It is not inside the freeze bubble on that doc so it is not frozen (the > publictest servers are never frozen) My bad...overlooked the bubble :) -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From jlaska at redhat.com Tue Apr 14 19:00:34 2009 From: jlaska at redhat.com (James Laska) Date: Tue, 14 Apr 2009 15:00:34 -0400 Subject: Improving QA test result submission and organization In-Reply-To: References: <1236105912.5415.460.camel@flatline.devel.redhat.com> <1236115153.5415.709.camel@flatline.devel.redhat.com> <1237227478.10941.73.camel@flatline.devel.redhat.com> Message-ID: <1239735635.3756.143.camel@flatline.devel.redhat.com> On Mon, 2009-03-16 at 14:25 -0500, Mike McGrath wrote: > On Mon, 16 Mar 2009, James Laska wrote: > > > On Tue, 2009-03-03 at 15:57 -0600, Mike McGrath wrote: > > > On Tue, 3 Mar 2009, James Laska wrote: > > > > > > > On Tue, 2009-03-03 at 13:10 -0600, Mike McGrath wrote: > > > > > > * Should the semantic performance impact be significant, is > > > > > > hosting a separate Fedora QA mediawiki (with semantic > > > > > enabled) a > > > > > > possibility? > > > > > > > > > > > > > > > > That is possible, for example we have a smolt wiki seperate from the > > > > > normal mediawiki install. The question of performance is, does it > > > > > only > > > > > impact pages deciding to use semantic or everything? We have lots of > > > > > way to test the actual impact of using it. > > > > > > > > Good question. The feedback I have so far is it affects everything. > > > > > > > > > > I just did some speed tests against the laptop.org instance you linked to. > > > At this point I don't think thats a blocker but we may find something out > > > later. > > > > Package review in progress for both extensions ... > > > > mediawiki-semantic-forms - > > https://bugzilla.redhat.com/show_bug.cgi?id=490171 > > > > mediawiki-semantic - https://bugzilla.redhat.com/show_bug.cgi?id=490001 > > > > I'm playing with the system locally to get more comfortable in this > > framework. Is it possible to get a dump of a subset of content from the > > fedoraproject.org/wiki so I can get a better sense how things will look > > in production? > > > > Yeah we can do that no problem. Can it wait until after the beta launches > though? (the 24th) It'll just be easier that way. Still swamped on my end, but having a snapshot of the current fedora wiki database that I can load into a test instance would help speed up efforts to identify whether semantic is the short-term (F12) solution for QA. Any updates on grabbing a db snapshot of the fedoraproject.org wiki? Does this seem possible? Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Apr 14 19:14:24 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Apr 2009 22:14:24 +0300 Subject: rpm-4.6.x & friends for RHEL5 (was: hosts for rawhide build chroots - different rpm versions?) In-Reply-To: <935ead450904141115g378b1275vd48d3039edfa8ec3@mail.gmail.com> References: <20090322100241.GA11378@victor.nirvana> <200903221153.10378.dennis@ausil.us> <20090414173731.GA3438@victor.nirvana> <935ead450904141115g378b1275vd48d3039edfa8ec3@mail.gmail.com> Message-ID: <20090414191424.GA8308@victor.nirvana> On Tue, Apr 14, 2009 at 01:15:21PM -0500, Jeffrey Ollie wrote: > On Tue, Apr 14, 2009 at 12:37 PM, Axel Thimm wrote: > > > > On Sun, Mar 22, 2009 at 11:53:09AM -0500, Dennis Gilmore wrote: > >> > >> we are running a version of rpm 4.6.0 on rhel5. ?This is only so mock can > >> populate chroots with rpms with stronger hashes rhel5's rpm doesnt support. > >> All srpm creation now takes place in chroots so features of the target rpm are > >> always available. > > > > Thanks for the explanation, Dennis. Can I get these tailored rpm rpms > > from somewhere? I just tried rebuilding rpm from rawhide on RHEL5 and > > the dependencies look endless. > > http://infrastructure.fedoraproject.org/ > Thanks, I guess it's http://infrastructure.fedoraproject.org/builder-rpms/ It's missing popt builds, but these were easy to rebuild from Fedora. I just metion it in case a) I'm pulling the wrong bits, b) someone else wants to use RHEL5 hosts with F11 roots. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tmz at pobox.com Wed Apr 15 02:16:04 2009 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 14 Apr 2009 22:16:04 -0400 Subject: [fwd] Link Error Message-ID: <20090415021604.GH13966@inocybe.teonanacatl.org> ----- Forwarded message from Will ----- Date: Tue, 14 Apr 2009 21:59:35 -0400 To: webmaster at fedoraproject.org From: Will Subject: Link Error Message-ID: <49E53F87.5050903 at alltel.net> Link error found on: https://admin.fedoraproject.org/pkgdb/collections/id/19?tg_paginate_limit=0 Remove or update: A user-friendly, customizable image viewer -- None Fedora Package Database -- Invalid Package Name The packagename you were linked to (A user-friendly, customizable image viewer) does not appear in the Package Database. If you received this error from a link on the fedoraproject.org website, please report it. ----- End forwarded message ----- -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is OK to let your mind go blank, but please turn off the sound. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From ivazqueznet at gmail.com Wed Apr 15 04:07:53 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 15 Apr 2009 00:07:53 -0400 Subject: Document formats (was: Re: Infrastructure Freeze) In-Reply-To: References: Message-ID: <1239768473.3744.47.camel@ignacio.lan> On Tue, 2009-04-14 at 13:33 -0500, Mike McGrath wrote: > Just a reminder guys, our infrastructure will be in a change freeze > starting at the end of the day today. The preview release will ship on > the 28th. > > http://fedoraproject.org/wiki/ISOP:RELEASE#Change_Freeze I understand the desire to use canonical sources for data, but perhaps we should export the freeze diagram to a browser-supported format since: 1) it requires Draw to be run, which is not a small install/app, and 2) it causes older versions of Draw to complain. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin at tummy.com Wed Apr 15 21:57:44 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 15 Apr 2009 15:57:44 -0600 Subject: [Change Request] Add dirsec to rsyncd.conf on cvs1 for ticket 1327 Message-ID: <20090415155744.72d3e907@ohm.scrye.com> This seems like a pretty safe change, but it's my first puppet change, so I might have messed something up. ;) I also changed the comment on the pkgs rsync target as it was wrongly saying it was the lookaside cache as well. I could revert that part if it's thought to risky. ;) --- modules/rsync/files/rsyncd.conf.cvs1 | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/modules/rsync/files/rsyncd.conf.cvs1 b/modules/rsync/files/rsyncd.conf.cvs1 index 356ffc8..93881dc 100644 --- a/modules/rsync/files/rsyncd.conf.cvs1 +++ b/modules/rsync/files/rsyncd.conf.cvs1 @@ -13,7 +13,14 @@ read only = yes [pkgs] path = /cvs/pkgs/ -comment = CVS Lookaside cache +comment = Fedora packages CVS +uid = nobody +gid = nobody +read only = yes + +[dirsec] +path = /cvs/dirsec/ +comment = Dirsec CVS uid = nobody gid = nobody read only = yes -- 1.5.5.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From a.badger at gmail.com Wed Apr 15 22:09:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 15 Apr 2009 15:09:01 -0700 Subject: [Change Request] Add dirsec to rsyncd.conf on cvs1 for ticket 1327 In-Reply-To: <20090415155744.72d3e907@ohm.scrye.com> References: <20090415155744.72d3e907@ohm.scrye.com> Message-ID: <49E65AFD.1060604@gmail.com> Kevin Fenzi wrote: > This seems like a pretty safe change, but it's my first puppet change, > so I might have messed something up. ;) > > I also changed the comment on the pkgs rsync target as it was wrongly > saying it was the lookaside cache as well. I could revert that part if > it's thought to risky. ;) > > --- > modules/rsync/files/rsyncd.conf.cvs1 | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/modules/rsync/files/rsyncd.conf.cvs1 > b/modules/rsync/files/rsyncd.conf.cvs1 index 356ffc8..93881dc 100644 > --- a/modules/rsync/files/rsyncd.conf.cvs1 > +++ b/modules/rsync/files/rsyncd.conf.cvs1 > @@ -13,7 +13,14 @@ read only = yes > > [pkgs] > path = /cvs/pkgs/ > -comment = CVS Lookaside cache > +comment = Fedora packages CVS > +uid = nobody > +gid = nobody > +read only = yes > + > +[dirsec] > +path = /cvs/dirsec/ > +comment = Dirsec CVS > uid = nobody > gid = nobody > read only = yes > Looks fine +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Thu Apr 16 07:27:55 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 16 Apr 2009 03:27:55 -0400 Subject: [Change Request] Add dirsec to rsyncd.conf on cvs1 for ticket 1327 In-Reply-To: <20090415155744.72d3e907@ohm.scrye.com> References: <20090415155744.72d3e907@ohm.scrye.com> Message-ID: <20090416072754.GE3316@sphe.res.cmu.edu> On 2009-04-15 03:57:44 PM, Kevin Fenzi wrote: > This seems like a pretty safe change, but it's my first puppet change, > so I might have messed something up. ;) > > I also changed the comment on the pkgs rsync target as it was wrongly > saying it was the lookaside cache as well. I could revert that part if > it's thought to risky. ;) > > --- > modules/rsync/files/rsyncd.conf.cvs1 | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/modules/rsync/files/rsyncd.conf.cvs1 > b/modules/rsync/files/rsyncd.conf.cvs1 index 356ffc8..93881dc 100644 > --- a/modules/rsync/files/rsyncd.conf.cvs1 > +++ b/modules/rsync/files/rsyncd.conf.cvs1 > @@ -13,7 +13,14 @@ read only = yes > > [pkgs] > path = /cvs/pkgs/ > -comment = CVS Lookaside cache > +comment = Fedora packages CVS > +uid = nobody > +gid = nobody > +read only = yes > + > +[dirsec] > +path = /cvs/dirsec/ > +comment = Dirsec CVS > uid = nobody > gid = nobody > read only = yes > -- > 1.5.5.6 +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From awilliam at redhat.com Thu Apr 16 17:39:43 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 16 Apr 2009 10:39:43 -0700 Subject: Fedora Calendering system: listing clear requirements. In-Reply-To: References: Message-ID: <1239903583.14173.0.camel@adam.local.net> On Sun, 2009-03-29 at 08:50 +0530, susmit shannigrahi wrote: > Hi, > The other mail was getting too long. > I am writing this as I think I have found the solution. (by using > zicula and phpical together) > > > So I want to understand the required functionalities. > > What I have got so far: > > 1. Having a calender. ;) > 2. Updating and Syncing from different clients using caldev protocol. > 3. Having a web-interface to view/update/sync the calenders. Have we gone any further with this yet? Just want to make sure I'm not missing out on a new system which needs testing. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From herlo1 at gmail.com Thu Apr 16 17:57:42 2009 From: herlo1 at gmail.com (Clint Savage) Date: Thu, 16 Apr 2009 11:57:42 -0600 Subject: Fedora Calendering system: listing clear requirements. In-Reply-To: <1239903583.14173.0.camel@adam.local.net> References: <1239903583.14173.0.camel@adam.local.net> Message-ID: On Thu, Apr 16, 2009 at 11:39 AM, Adam Williamson wrote: > On Sun, 2009-03-29 at 08:50 +0530, susmit shannigrahi wrote: >> Hi, >> The other mail was getting too long. >> I am writing this as I think I have found the solution. (by using >> zicula and phpical together) >> >> >> So I want to understand the required functionalities. >> >> What I have got so far: >> >> 1. Having a calender. ;) >> 2. Updating and Syncing from different clients using caldev protocol. >> 3. Having a web-interface to view/update/sync the calenders. > > Have we gone any further with this yet? Just want to make sure I'm not > missing out on a new system which needs testing. Thanks! Well, I have been slack on testing these systems. I had attempted at one point to test a few, but had to really dig into the docs to test them with sunbird or evolution. The web interface seems simple enough in both cases, but I'm not as interested in that as I am with being able to pull and push data from my own application. I'll try to do something with it this weekend. Cheers, Clint From thinklinux.ssh at gmail.com Thu Apr 16 18:06:24 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Thu, 16 Apr 2009 23:36:24 +0530 Subject: Fedora Calendering system: listing clear requirements. In-Reply-To: References: <1239903583.14173.0.camel@adam.local.net> Message-ID: >>> What I have got so far: >>> >>> 1. Having a calender. ;) >>> 2. Updating and Syncing from different clients using caldev protocol. >>> 3. Having a web-interface to view/update/sync the calenders. >> >> Have we gone any further with this yet? Just want to make sure I'm not >> missing out on a new system which needs testing. Thanks! Yes, finally I found out that using DaviCal and chandler together, we can build the ideal solution. But I am lagging a bit as I just got hold of rawhide1 only a couple of days back and chandler is a bit problematic on it. I am working on it. Lets see. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India From ricky at fedoraproject.org Thu Apr 16 20:36:25 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 16 Apr 2009 16:36:25 -0400 Subject: Meeting Log - 2009-04-16 Message-ID: <20090416203623.GF3316@sphe.res.cmu.edu> 20:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 * ricky 20:00 < ggruener> ping 20:01 -!- pingou_ [n=Pingou at fedora/pingou] has quit Client Quit 20:01 < ivazquez|laptop> Pong. 20:01 < johe> pong 20:01 < sts> pong 20:01 * SmootherFrOgZ is 20:01 * nirik is in the cheap seats in the back. 20:01 < mmcgrath> k, lets go 20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 20:02 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:02 -!- yingbull [n=yingbull at S01060013104275dd.ss.shawcable.net] has joined #fedora-meeting 20:02 < mmcgrath> k, seems there's no tickets to discuss 20:02 < mdomsch> whee 20:02 < sts> easy ;) 20:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Preview Relase 20:02 < mmcgrath> So we're frozen again for the preview release. 20:03 < skvidal> yay for frozen 20:03 < mdomsch> that was quick 20:03 < mmcgrath> mdomsch: yeah the closer we get the less time we have to do stuff :) 20:03 < mmcgrath> both good and bad I suppose. 20:03 < ggruener> how long? 20:03 < mmcgrath> ggruener: they always start two weeks before the release and end one day after the release. 20:03 < mmcgrath> So they are typically 2 weeks + 1 day. 20:03 < mmcgrath> but if a release slips, then the freeze-end slips with it. 20:03 < mmcgrath> which does happen from time to time. 20:04 < ggruener> k 20:04 < mmcgrath> f13: you around? 20:04 * mmcgrath wonders exactly what "Compose & Stage Release Candidate" means. 20:04 < mmcgrath> jwb: you know? 20:05 < jwb> essentially, create the ISOs and get them pre-staged on the mirrors 20:05 < mmcgrath> well, I'll ignore that for now. 20:05 < mmcgrath> ah 20:05 < mmcgrath> jwb: k 20:05 < jwb> why do you ask? 20:05 < mmcgrath> and we're doing a full release for the preview release right? 20:05 < mmcgrath> jwb: just checking. 20:05 < jwb> i think so... 20:05 < mmcgrath> the preview goes on the mirrors and stuff, not just torrent? 20:05 < jwb> i think so, but f13 would know for sure. or notting 20:05 < mdomsch> yes 20:05 < mmcgrath> k, thought so. 20:06 < jwb> don't listen to mdomsch. he doesn't know. he's not 1337 20:06 < mmcgrath> I'm going to get the tickets created 20:06 < jwb> ;) 20:06 < mmcgrath> http://fedoraproject.org/wiki/ISOP:RELEASE 20:06 < mdomsch> 120GB free 20:06 < mdomsch> which should take it 20:06 < mmcgrath> that should do for the preview, what about the final release? 20:06 -!- RodrigoPadula [n=Rodrigo at 200.242.89.130] has quit Read error: 60 (Operation timed out) 20:06 < mdomsch> but we'll want to nuke F11-Alpha at some point 20:06 < mmcgrath> mdomsch: FYI, our new mirror system should be ready to be installed in early May. 20:07 < mmcgrath> but our release schedule might block some of that. 20:07 < notting> honestly, given beta's gone out, i'd say we can nuke alpha whenever 20:07 < mdomsch> notting, +1 20:07 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 20:07 < sts> mmcgrath: what parts of the infrastructure are frozen? 20:08 < mmcgrath> k, so that's good to know. 20:08 < mmcgrath> sts: to find out just check out - http://fedoraproject.org/wiki/ISOP:RELEASE#Change_Freeze] 20:08 < mmcgrath> err http://fedoraproject.org/wiki/ISOP:RELEASE#Change_Freeze 20:08 < sts> thx 20:08 < mmcgrath> sts: this is a pre-release freeze, not the full freeze. 20:09 < mmcgrath> mdomsch: FYI, the mirror upgrade will be online in PHX1 but require downtime in RDU. 20:09 < mdomsch> mmcgrath, how long? 20:09 < mmcgrath> mdomsch: so when they're ready I'll work with you and releng to decide if it's worth it to us to wait until F11 is out the door or not. 20:09 -!- rdieter_laptop [n=rdieter at pcp088952pcs.unl.edu] has quit Remote closed the connection 20:09 < mmcgrath> mdomsch: no idea yet, I was talking about it in a meeting yesterday but didn't discuss with the actual tech that will be installing it 20:10 < mdomsch> I'd expect it to be brief 20:10 < mmcgrath> I would too, certainly measured in 'hours' and not 'days' 20:10 < mdomsch> unmount old nfs share, mount new nfs share 20:10 < mdomsch> we'll just need to warn mirror-list-d 20:10 < mmcgrath> well, there's going to be a sync in the middle there :) 20:10 < mdomsch> sync first 20:10 < mmcgrath> yeah, I'm going to make sure that happens properly 20:10 < mmcgrath> mdomsch: one thing I don't know is if they have room for the old netapp and the new netapp or if they have to remove the old for the new. 20:10 < mdomsch> and only folks hitting download-i2 would be affected anyhow 20:11 < mmcgrath> Some of these details I'll have to work out with them. 20:11 < mmcgrath> yeah 20:11 < mmcgrath> mdomsch: the bad part of the mirror upgrade is it means what was the TPA filer won't come online until the rest of this is all figured out. 20:11 < mmcgrath> they're doing some strange setup in PHX2 that we're apart of. 20:11 < mmcgrath> it should be transparent to us but it's taking them longer to get that stuff online there 20:12 < mdomsch> mmcgrath, I'd love to get rsync logs from download* 20:12 < mdomsch> see who is actually hitting us directly as opposed to the tiers 20:12 < mdomsch> and on what kind of schedule 20:12 < mmcgrath> mdomsch: ticket submitted, I'll let you know what they get back to me with 20:13 < mdomsch> cool thanks 20:13 < mmcgrath> k 20:13 < mmcgrath> well while we're all here, lets get the tickets created. 20:13 < mmcgrath> ricky: you around? 20:13 < ricky> Yup 20:13 < mmcgrath> ricky: you going to do the web page as usual? 20:14 * mmcgrath gets to generating - https://fedorahosted.org/fedora-infrastructure/report/9 20:14 < ricky> I'll get it setup beforehand, but I might not be around to release it as usual 20:15 < mmcgrath> ricky: k, no worries, once the page is created just put the directions in the ticket and someone will nab it. 20:15 < mmcgrath> I'll do the mirror space verification though I think we're fine (we were just talking about it. 20:15 < mmcgrath> For those that don't know, we're talking about the tickets listed here - 20:15 < mmcgrath> http://fedoraproject.org/wiki/ISOP:RELEASE#Preparations 20:16 < mmcgrath> I'll take the release day ticket, it's a tracker ticket 20:17 < mmcgrath> SmootherFrOgZ: you want to do the mirror permission verification again? 20:18 < SmootherFrOgZ> mmcgrath: yeah, assign it to me 20:18 < mmcgrath> SmootherFrOgZ: will do 20:18 < mmcgrath> mdomsch: do you want 20:18 < mmcgrath> .ticket 1338 20:18 < zodbot> mmcgrath: #1338 (repo redirects) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1338 20:19 < mdomsch> mmcgrath, sure, it's done already 20:19 < mmcgrath> mdomsch: when does that get done? is it automatic or are you just that on the ball with it? :) 20:19 < mdomsch> I did it for all the releases when I had to do it for one 20:19 < mdomsch> I suppose I could make that automatic... 20:20 < mmcgrath> no worries, just curious. 20:20 < mmcgrath> mdomsch: and how about 20:20 < mmcgrath> .ticket 1340 20:20 < zodbot> mmcgrath: #1340 (Add new release to mirror manager) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1340 20:20 < mdomsch> mmcgrath, I just updated the SOP for 1340 - that's automatic now 20:20 < mmcgrath> sweet 20:20 < mdomsch> only if it somehow doesn't fire do we need to take any action 20:21 < mmcgrath> ricky: go ahead and accept 1334 20:21 < mdomsch> e.g. the versioning scheme changes yet again 20:21 -!- RodrigoPadula [n=Rodrigo at 200.242.89.130] has joined #fedora-meeting 20:22 < mmcgrath> mdomsch: 20:22 < mmcgrath> Ok, I'd expect the preview release to go just as smooth as the beta release. 20:22 < mmcgrath> Anyone have any questions or concerns wrt the preview release? 20:22 < mmcgrath> http://fedoraproject.org/wiki/Schedule 20:22 < mmcgrath> that's the global schedul 20:23 < mmcgrath> while the beta slipped I don't think the preview is set to slip right now 20:23 -!- EvilBob [n=EvilBob at fedora/bobjensen] has quit Remote closed the connection 20:23 < poelcat> no everything else is holding to original schedule 20:23 < mmcgrath> poelcat: thanks 20:24 < mmcgrath> Ok, so that's it on the release for now, we'll discuss this again next week I'm sure. 20:24 < mmcgrath> So next topic...; 20:24 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Cloud 20:24 < mmcgrath> So the cloud stuff is coming along slowly 20:24 < mmcgrath> G, SmootherFrOgZ, the ovirt team and myself have been working to get our cloud up and going. 20:24 < mmcgrath> Lots of bumps but we've been getting through them. 20:25 < mmcgrath> Nothing too much to report here, i did my first guest install just an hour ago or so but now ovirt can't figure out the state of that guest :) 20:25 -!- sharkcz [n=dan at plz1-v-4-17.static.adsl.vol.cz] has quit "Ukon?uji" 20:25 < mmcgrath> oh and there's a segfault in libvirt-qpid 20:25 < mmcgrath> other then that though we're making progress. 20:25 < mmcgrath> Any questions on the cloud stuff? 20:25 * johe has none 20:25 < mmcgrath> Ok, with that we'll... 20:26 -!- BaRRa [n=tmakinen at tk-cn0002.oulu.fi] has left #fedora-meeting [] 20:26 -!- mmcgrath changed the topic of #fedora-meeting to: Infratructure -- Open Floor 20:26 < mmcgrath> anyone have anything to discuss? 20:26 -!- cassmodiah [n=cass at fedora/cassmodiah] has quit Remote closed the connection 20:26 < mmcgrath> Any of you new people want to say hello and introduce yourself? 20:26 * johe want to 20:26 < mmcgrath> johe: take it 20:27 < johe> So then, hello, i already intoduced myself on the mailinglist, so i think there is not much more to say, 20:27 * ricky waves 20:27 < johe> hoping we having a good working together 20:28 * johe /finish 20:28 < mmcgrath> johe: heh, that was quick but hello! 20:28 < mmcgrath> johe: how much time per week do you think you'd like to contribute? 20:29 < johe> mmcgrath, well cant say, i'am online many hours a day, if theres a way i can help i wlways will do, 10 to 20 hours should work, if you wanted to know a time :-) 20:30 < mmcgrath> johe: that's quite a bit, well things are in a bit of a lull right now. 20:30 < mmcgrath> But I'm sure they'll pick up after the freeze, stick around and get to know who does what. 20:30 < mmcgrath> sts: do you want to say hey? 20:30 < johe> will do so 20:30 < sts> yeah sure! 20:30 < sts> here i am ;) 20:31 < sts> i'm a systems engineer working at silverserver, an austrian isp 20:31 < sts> and i'm trying to get sponsored for fedora-noc. 20:31 < sts> already got my welcome mail... 20:31 < mmcgrath> sts: sweet, G_work and dgilmore are both from down under. 20:31 -!- RodrigoPadula [n=Rodrigo at 200.242.89.130] has quit Read error: 54 (Connection reset by peer) 20:31 < sts> yeah, G already talked to me. 20:31 < sts> ;) 20:32 < mmcgrath> hehe 20:32 < mmcgrath> sts: ggruener is also just getting started in some sysadmin-noc work. 20:32 < mmcgrath> you two should talk after the meeting. 20:32 < ggruener> yeah that can we do:) 20:32 < sts> well, I gotta go right after the meeting, but i'd be pleased to talk to you tomorrow. 20:32 < sts> ;) 20:33 < sts> sorry mate.. 20:33 < ggruener> np 20:33 < mmcgrath> sts: cool 20:33 < mmcgrath> Ok, well it looks like we'll be getting done a bit early this week but that's good. 20:33 < mmcgrath> If no one has anything else we'll close the meeting in 30 20:35 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting end -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Apr 16 21:30:53 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 16 Apr 2009 16:30:53 -0500 (CDT) Subject: Out for the next couple of days Message-ID: I'm moving tomorrow which means I'll be largely unavailable over the next several days. I'll be able to make my way to a starbucks for internet and stuff for emergencies but other then that probably won't be around much. -Mike From laxathom at fedoraproject.org Thu Apr 16 23:06:41 2009 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Fri, 17 Apr 2009 01:06:41 +0200 Subject: Out for the next couple of days In-Reply-To: References: Message-ID: <62bc09df0904161606p350a23fh2141158885ec73f@mail.gmail.com> On Thu, Apr 16, 2009 at 11:30 PM, Mike McGrath wrote: > I'm moving tomorrow which means I'll be largely unavailable over the next > several days. ?I'll be able to make my way to a starbucks for internet > and stuff for emergencies but other then that probably won't be around > much. > > ? ? ? ?-Mike > Could you give me access back to cnodex during those time in eventually if libvirtd-qpid segfault again ? thx -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From mmcgrath at redhat.com Thu Apr 16 23:15:05 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 16 Apr 2009 18:15:05 -0500 (CDT) Subject: Out for the next couple of days In-Reply-To: <62bc09df0904161606p350a23fh2141158885ec73f@mail.gmail.com> References: <62bc09df0904161606p350a23fh2141158885ec73f@mail.gmail.com> Message-ID: On Fri, 17 Apr 2009, Xavier Lamien wrote: > On Thu, Apr 16, 2009 at 11:30 PM, Mike McGrath wrote: > > I'm moving tomorrow which means I'll be largely unavailable over the next > > several days. ?I'll be able to make my way to a starbucks for internet > > and stuff for emergencies but other then that probably won't be around > > much. > > > > ? ? ? ?-Mike > > > > Could you give me access back to cnodex during those time > in eventually if libvirtd-qpid segfault again ? > > thx > cnode4 password is at capp1:/root/pass I need to reboot the other two nodes so their networks come up properly. I've got libvirt-qpid running in a screen session on capp1 as the nodes don't have screen installed. -Mike From thinklinux.ssh at gmail.com Sat Apr 18 12:10:30 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Sat, 18 Apr 2009 17:40:30 +0530 Subject: FAS is way too slow. Message-ID: FYI. Right now, it is talking upto 3 minutes to log-in. Don't know why. Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From cra at WPI.EDU Sat Apr 18 17:37:10 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 18 Apr 2009 13:37:10 -0400 Subject: metalink doesn't match In-Reply-To: References: Message-ID: <20090418173710.GA17912@angus.ind.WPI.EDU> The mirror system for rawhide is currenlty broken. Every mirror reports the same error: Loaded plugins: dellsysidplugin2, refresh-packagekit, security rawhide/metalink | 4.1 kB 00:00 rawhide | 3.8 kB 00:00 ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/development/x86_64/os/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for rawhide Trying other mirror. rawhide | 3.8 kB 00:00 ftp://ftp.cse.buffalo.edu/pub/Linux/fedora/linux/development/x86_64/os/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for rawhide Trying other mirror. rawhide | 3.8 kB 00:00 http://archive.linux.duke.edu/pub/fedora/linux/development/x86_64/os/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for rawhide Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: rawhide. Please verify its path and try again ... etc. From abhradipmukherjee at gmail.com Sun Apr 19 13:23:06 2009 From: abhradipmukherjee at gmail.com (Abhradip Mukherjee) Date: Sun, 19 Apr 2009 18:53:06 +0530 Subject: One click web based installation UI Message-ID: I presented this idea on GSOC 2009 project from Fedora on similar topic. Then Toshio Kuratomi replied "Whether or not this accepted for GSOC, there are some good ideas here. I think communicating with the PackageKit developers [1]_ about how your ideas can tie into their ideas for installing from the web is a good place to start if you want to support arbitrary installing packages from arbitrary locations. Talking to me and other fedora Infrastructure people on the fedora-infrastructure list[2]_ or #fedora-admin on irc.freenode.net would be a good starting point if you only want to let people install packages from official Fedora Repositories." So here it goes with the parts of the conversation between me and Mr. Toshio Kuratomi. ====================================== *== Why should we choose you over other applicants? ==* In choosing me over other applications, you may like the following facts : ? I am very much passionate about FOSS which you can see from the name I have given to the network I formed (Passion4Freedom) ? I have worked in real life FOSS campaigns in educational institutes and formed a FOSS network in those institutes. ? I have the knowledge in working with Open Source CMS. This is an added advantage in web projects like this one. ? I have knowledge in installing applications on Fedora using .rpm files and by source compilation as well. ? I know shell scripting and other Linux programming languages. ? I have strong knowledge in C and C++ and basic knowledge about STL and SystemC. ? I know Java, Servlet, JSP, EJB. ? I have knowledge on Javascript, HTML, CSS. ? I have done extensive work on LAMP architechture. ? I have used online installation services like Klick or Freespire?s CNR . I also used easy install scripts for various programs ? I have been using Fedora for past 3 years and I have closely understood the working of yum. ? I have done various personal researches on Fedora in VirtualBox just to understand it better. ? I am desperate to contribute something useful to my most beloved distro. I love you Fedora. F8 was my first love and I still love it more than any other distro. ? I have already created a website for making installation easy on fedora http://install.passion4freedom.07x.net (it is on a free server, so it may be down sometimes, please consider). I hope that this will tell about my idea in a more clear way. *== Proposal Description ==* Here is my proposal in detail: ** An overview of my proposal* To create an online software archive for Fedora which gives the user a one click install facility, my approach is based on community contribution. Instead of going for a synchronized UI for repository, I created a drupal based website that has an archive of software installer scripts for various versions of Fedora. The archive is maintained by the community and they update/comment on the software. The website is indexed and keyword searching can be used to search the software of choice. The shell scripts are executable text files with .qi extension. They are made in such a way so that user can install it by executing just once. The whole archive can be edited by ever member and any member can upload a new shell script for installation of any software. The proposal has been converted to a website already ( http://install.passion4freedom.07x.net ). The cause for which I did not take up creating UI for repository is also because I do not have enough technical knowledge about that. If GSOC mentor provides me that technical guidance I hope it wont be much tough for me as I have the right passion for freedom. * * The need I believe it fulfils* It makes software installation a lot easier to newbies and saves time for pros. This is a requirement of all Fedora users and this should be implemented as soon as possible as that will make the usability of Fedora much more. ** Any relevant experience I have* ? Experience with Linux, Apache, MySQL, PHP. ? Experience with creation of social networking websites. ? Experience of creating simple installer shell scripts for fedora apps. ? Experience with web CMS softwares. ? http://install.passion4freedom.07x.net can be viewed as an effort along the same path. ** How I intend to implement my proposal* ? Wiki Style ? Drupal based ? Community maintained ? Downloadable shell scripts with chmod 777 ? 1 click install for end users ** A rough timeline for my progress* ? Depends. If it is to be done in the way I am proposing then Fine tuning to suit your needs is the only thing left. And that should not take much time. ? If I have to build it as a synchronized UI to the repository then as I do not have enough technical knowledge on synchronizing with repo, I am not being able to estimate the timeline very well ? But, as a whole I can assure you that with the fire for freedom and fedora within me, it will be easily converted into reality within the timeline of GSOC (if not earlier). ** Any other details you feel we should consider* ? Online distribution customization following the paths of nimbleX and Slax. ? Desktop tool for installing most important apps following the way of automatix in ubuntu. ================================================================================== On 6th April 2009 15:26 Toshio Kuratomi wrote: I like the idea of having a simple way to install packages. However, there's a few problems with the proposal. 1. The Package Database is a python application. We'd want to tie any official installation of packages for Fedora into that so we need python knowledge. 2. You need to talk to the PackageKit developers and Fedora Infrastructure in order to find out what the constraints each group would have. 3. From the Fedora Infrastructure side: - We probably can't host arbitrary install scripts as we aren't able to legally point to arbitrary packages. For instance, many multimedia codecs are patented without licenses to be used in free software. - We would want to avoid Drupal if we can. We already have the PackageDB and this is most likely something we'd want to integrate there. We've recently settled on Zikula for a CMS solution so if we needed to implement something on top of a CMS platform, I'd rather we used that. ===================== I replied: > Personally, I think easy package installation with simple scripts is a > better idea. For example to run .exe files it is more user friendly if I > give a script to install wine, wine-doors, playonlinux all together instead > of giving them a package UI where upon searching they will be able to find > three different packages for the cause. Some people install wine and > complain that wine is not able to play games but they dont install > playonlinux as they just dont know abut it. (This is just a part of my reply) ===================== On 16th April 2009 21:41 Toshio Kuratomi wrote: Yeah, I'm afraid it's a bit too late for GSoC 2009. But I'm glad to hear you're going to work on your ideas some more. I can see what you mean about trying to associate things that serve the same task (like wine, wine-doors, and playonlinux). I'm hoping that tagging of packages and searching by tag will help us get closer to that within Fedora with the official Fedora repositories. Letting people install things that aren't in the official repositories is probably something that won't happen within Fedora but it could be useful for a third party site to do. Building up and managing trust would be the hard task in this regard, though, as it's easy to provide a script for users to download and install arbitrary software on their computers but hard to protect them in case either the scripts are malicious or the software the scripts point at become malicious. =================================== Here goes my final proposal : "I have started the project at install.passion4freedom.07x.net with 100 students here at Kolkata, India. We hope to build it up soon. But I still can not understand,why you guys are not able to back the project. As far as I understand, if your main problem is that you can not depend on the user community i.e. you are afraid that the users may upload malicious code, then why not build a similar website which will not give the option to upload the scripts to the users. Why dont we (you and I) take the responsibility of creating such scripts and let the users download the scripts. Let me explain to you how great this thing can be. Suppose a user needs to download the source code of the latest kernel. We can create a script to simplify his job in the following way 1. Script asks the user where to store the file 2. cd "Specified DIR" 3. wget "kernel source url" 4. untar 5. open DIR in nautilus This way user gets to use it with comfort. Otherwise if they had to write each command by hand or had to find where the source code is (manually) and how to untar it, they could have felt that using GNU/Linux is basically a terminal job. I feel it will be better if Fedora offficially supports the project as this project has the ability to simplify the whole procedure of installation in GNU/Linux. If you feel I am wrong, please comment on where I am getting it wrong? Also, I know that there may be legal issues for supporting installation of Flash and other properietory thing. But why not simplify the normal installations, even if we can't proceed with the properietory ones. I still have a confusion. Why will there be legal issues if we proceed in the following way : A person wants to install Flash We provide him a script which will guide him to the website of flash with a text mode browser Upon accepting the license script asks him "where to save the file" after downloading the file, script installs it immediately Spot the difference with the options available now. In this way the person feels the same way that he used to feel when he used to install softwares on his previous popular properietory distribution. Here also he needs to accept and press enter to move to the next step (The next-next feeling is what I am talking about). Also he gets the feeling that here the case is even better as the installer not only downloads the file but also installs it at a go. He will feel that it is easier to use GNU/Linux. This project will make s/w instalation on GNU/Linux systems much more easier. If fedora provides support and expertise, I feel it will soon become a useful contribution to Fedora community and will certainly become a reliable service. I hope you guys get my point. Please comment." Please reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Apr 20 02:12:45 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 19 Apr 2009 21:12:45 -0500 (CDT) Subject: metalink doesn't match In-Reply-To: <20090418173710.GA17912@angus.ind.WPI.EDU> References: <20090418173710.GA17912@angus.ind.WPI.EDU> Message-ID: Did you 'yum clean all' before testing this? -Mike On Sat, 18 Apr 2009, Chuck Anderson wrote: > The mirror system for rawhide is currenlty broken. Every mirror > reports the same error: > > Loaded plugins: dellsysidplugin2, refresh-packagekit, security > rawhide/metalink | 4.1 kB > 00:00 > rawhide | 3.8 kB > 00:00 > ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/development/x86_64/os/repodata/repomd.xml: > [Errno -1] repomd.xml does not match metalink for rawhide > Trying other mirror. > rawhide | 3.8 kB > 00:00 > ftp://ftp.cse.buffalo.edu/pub/Linux/fedora/linux/development/x86_64/os/repodata/repomd.xml: > [Errno -1] repomd.xml does not match metalink for rawhide > Trying other mirror. > rawhide | 3.8 kB > 00:00 > http://archive.linux.duke.edu/pub/fedora/linux/development/x86_64/os/repodata/repomd.xml: > [Errno -1] repomd.xml does not match metalink for rawhide > Trying other mirror. > Error: Cannot retrieve repository metadata (repomd.xml) for > repository: rawhide. Please verify its path and try again > > ... > etc. > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From thinklinux.ssh at gmail.com Mon Apr 20 02:56:26 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Mon, 20 Apr 2009 08:26:26 +0530 Subject: metalink doesn't match In-Reply-To: <20090418173710.GA17912@angus.ind.WPI.EDU> References: <20090418173710.GA17912@angus.ind.WPI.EDU> Message-ID: On Sat, Apr 18, 2009 at 11:07 PM, Chuck Anderson wrote: > The mirror system for rawhide is currenlty broken. ?Every mirror > reports the same error: > > Loaded plugins: dellsysidplugin2, refresh-packagekit, security > rawhide/metalink ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 4.1 kB > 00:00 > rawhide ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 3.8 kB > 00:00 > ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/development/x86_64/os/repodata/repomd.xml: > [Errno -1] repomd.xml does not match metalink for rawhide > Trying other mirror. > rawhide ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 3.8 kB > 00:00 > ftp://ftp.cse.buffalo.edu/pub/Linux/fedora/linux/development/x86_64/os/repodata/repomd.xml: > [Errno -1] repomd.xml does not match metalink for rawhide > Trying other mirror. > rawhide ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 3.8 kB > 00:00 > http://archive.linux.duke.edu/pub/fedora/linux/development/x86_64/os/repodata/repomd.xml: > [Errno -1] repomd.xml does not match metalink for rawhide > Trying other mirror. > Error: Cannot retrieve repository metadata (repomd.xml) for > repository: rawhide. Please verify its path and try again I am getting this same error on rawhide1.fp.o since yesterday, I did a 'yum clean all' but that didn't help. I thought it was temporary and didn't report. Yes, today morning, I just checked, it's fine now. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From thinklinux.ssh at gmail.com Mon Apr 20 03:02:46 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Mon, 20 Apr 2009 08:32:46 +0530 Subject: "/usr/lib64/libmodbc.so.0 is not a symbolic link" message on each yum transaction. Message-ID: Hi, I am getting an warning/error all the while using rawhide, (full output attached) The error is : "sbin/ldconfig: /usr/lib64/libmodbc.so.0 is not a symbolic link" Repeats for each transaction. [susmit at rawhide1 ~]$ uname -r 2.6.29-0.258.rc8.git2.fc11.x86_64 [susmit at rawhide1 ~]$ yum --version 3.2.22 -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India -------------- next part -------------- A non-text attachment was scrubbed... Name: ldconfig_err Type: application/octet-stream Size: 7435 bytes Desc: not available URL: From ricky at fedoraproject.org Mon Apr 20 11:31:02 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 20 Apr 2009 07:31:02 -0400 Subject: [MirrorManager PATCH] Fix killall path, add requires on psmisc for killall. Message-ID: <20090420113102.GA21032@sphe.res.cmu.edu> We recently got some cron mail about a wrong killall path, so here's a patch to mirrormanager to fix it. --- mirrormanager.spec.in | 2 +- server/logrotate.conf | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mirrormanager.spec.in b/mirrormanager.spec.in index cc154b9..8c3d08f 100644 --- a/mirrormanager.spec.in +++ b/mirrormanager.spec.in @@ -10,7 +10,7 @@ URL: http://fedorahosted.org/mirrormanager Source0: https://fedorahosted.org/releases/m/i/%{name}/%{name}-%{version}.tar.bz2 BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) BuildRequires: python -Requires: TurboGears, python-IPy, python-GeoIP, wget, yum +Requires: TurboGears, python-IPy, python-GeoIP, wget, yum, psmisc %define py_ver %(echo `python -c "import sys; print sys.version[:3]"`) %if "%{py_ver}" < "2.5" diff --git a/server/logrotate.conf b/server/logrotate.conf index ec473e7..733de26 100644 --- a/server/logrotate.conf +++ b/server/logrotate.conf @@ -13,6 +13,6 @@ dateext rotate 15 postrotate - /sbin/killall -HUP crawler_perhost + /usr/bin/killall -HUP crawler_perhost endscript } -- 1.6.0.6 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Mon Apr 20 12:50:34 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 20 Apr 2009 05:50:34 -0700 Subject: [MirrorManager PATCH] Fix killall path, add requires on psmisc for killall. In-Reply-To: <20090420113102.GA21032@sphe.res.cmu.edu> References: <20090420113102.GA21032@sphe.res.cmu.edu> Message-ID: <49EC6F9A.2040202@gmail.com> Ricky Zhou wrote: > We recently got some cron mail about a wrong killall path, so here's a > patch to mirrormanager to fix it. > --- > mirrormanager.spec.in | 2 +- > server/logrotate.conf | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mirrormanager.spec.in b/mirrormanager.spec.in > index cc154b9..8c3d08f 100644 > --- a/mirrormanager.spec.in > +++ b/mirrormanager.spec.in > @@ -10,7 +10,7 @@ URL: http://fedorahosted.org/mirrormanager > Source0: https://fedorahosted.org/releases/m/i/%{name}/%{name}-%{version}.tar.bz2 > BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) > BuildRequires: python > -Requires: TurboGears, python-IPy, python-GeoIP, wget, yum > +Requires: TurboGears, python-IPy, python-GeoIP, wget, yum, psmisc > > %define py_ver %(echo `python -c "import sys; print sys.version[:3]"`) > %if "%{py_ver}" < "2.5" > diff --git a/server/logrotate.conf b/server/logrotate.conf > index ec473e7..733de26 100644 > --- a/server/logrotate.conf > +++ b/server/logrotate.conf > @@ -13,6 +13,6 @@ > dateext > rotate 15 > postrotate > - /sbin/killall -HUP crawler_perhost > + /usr/bin/killall -HUP crawler_perhost > endscript > } > +1 Thanks, ricky -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Mon Apr 20 13:07:30 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 20 Apr 2009 08:07:30 -0500 (CDT) Subject: [MirrorManager PATCH] Fix killall path, add requires on psmisc for killall. In-Reply-To: <49EC6F9A.2040202@gmail.com> References: <20090420113102.GA21032@sphe.res.cmu.edu> <49EC6F9A.2040202@gmail.com> Message-ID: On Mon, 20 Apr 2009, Toshio Kuratomi wrote: > Ricky Zhou wrote: > > We recently got some cron mail about a wrong killall path, so here's a > > patch to mirrormanager to fix it. > > --- > > mirrormanager.spec.in | 2 +- > > server/logrotate.conf | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/mirrormanager.spec.in b/mirrormanager.spec.in > > index cc154b9..8c3d08f 100644 > > --- a/mirrormanager.spec.in > > +++ b/mirrormanager.spec.in > > @@ -10,7 +10,7 @@ URL: http://fedorahosted.org/mirrormanager > > Source0: https://fedorahosted.org/releases/m/i/%{name}/%{name}-%{version}.tar.bz2 > > BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) > > BuildRequires: python > > -Requires: TurboGears, python-IPy, python-GeoIP, wget, yum > > +Requires: TurboGears, python-IPy, python-GeoIP, wget, yum, psmisc > > > > %define py_ver %(echo `python -c "import sys; print sys.version[:3]"`) > > %if "%{py_ver}" < "2.5" > > diff --git a/server/logrotate.conf b/server/logrotate.conf > > index ec473e7..733de26 100644 > > --- a/server/logrotate.conf > > +++ b/server/logrotate.conf > > @@ -13,6 +13,6 @@ > > dateext > > rotate 15 > > postrotate > > - /sbin/killall -HUP crawler_perhost > > + /usr/bin/killall -HUP crawler_perhost > > endscript > > } > > > +1 > Thanks, ricky > +1 -Mike From ricky at fedoraproject.org Mon Apr 20 13:15:34 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 20 Apr 2009 09:15:34 -0400 Subject: [MirrorManager PATCH] Fix killall path, add requires on psmisc for killall. In-Reply-To: References: <20090420113102.GA21032@sphe.res.cmu.edu> <49EC6F9A.2040202@gmail.com> Message-ID: <20090420131534.GQ3316@sphe.res.cmu.edu> On 2009-04-20 08:07:30 AM, Mike McGrath wrote: > +1 I've applied this to all of the app servers now. When Matt gets a chance, he can probably apply this to mirrormanager git. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Mon Apr 20 14:30:06 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 20 Apr 2009 09:30:06 -0500 (CDT) Subject: [MirrorManager PATCH] Fix killall path, add requires on psmisc for killall. In-Reply-To: <20090420131534.GQ3316@sphe.res.cmu.edu> References: <20090420113102.GA21032@sphe.res.cmu.edu> <49EC6F9A.2040202@gmail.com> <20090420131534.GQ3316@sphe.res.cmu.edu> Message-ID: On Mon, 20 Apr 2009, Ricky Zhou wrote: > On 2009-04-20 08:07:30 AM, Mike McGrath wrote: > > +1 > I've applied this to all of the app servers now. When Matt gets a > chance, he can probably apply this to mirrormanager git. > Just pushed these upstream, I'm in the gitmirroradmin group so I assume that means it's ok for me to commit :) -Mike From james at fedoraproject.org Mon Apr 20 15:23:00 2009 From: james at fedoraproject.org (James Antill) Date: Mon, 20 Apr 2009 11:23:00 -0400 Subject: metalink doesn't match In-Reply-To: References: <20090418173710.GA17912@angus.ind.WPI.EDU> Message-ID: <1240240980.9658.37.camel@code.and.org> On Sun, 2009-04-19 at 21:12 -0500, Mike McGrath wrote: > Did you 'yum clean all' before testing this? This will never help. The error very likely means that MM hasn't picked up that a new repomd.xml has arrived ... but that repomd.xml has hit all the mirrors. Thus. the only available repodata is invalid. If you have older cached repodata, then instead of: > > Error: Cannot retrieve repository metadata (repomd.xml) for > > repository: rawhide. Please verify its path and try again It should revert to the old version and continue to work (so clean is actively harmful here). -- James Antill - james at fedoraproject.org "I'd just like to see a realistic approach to updates via packages." -- Les Mikesell From ianweller at gmail.com Tue Apr 21 02:03:09 2009 From: ianweller at gmail.com (Ian Weller) Date: Mon, 20 Apr 2009 21:03:09 -0500 Subject: wiki i18n Message-ID: <20090421020309.GA22581@gmail.com> What is the status of wiki i18n? Last I knew Nigel was working on some of that stuff, and that was four months ago, and I haven't heard a single thing since. -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Apr 22 00:17:04 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 21 Apr 2009 19:17:04 -0500 (CDT) Subject: wiki i18n In-Reply-To: <20090421020309.GA22581@gmail.com> References: <20090421020309.GA22581@gmail.com> Message-ID: On Mon, 20 Apr 2009, Ian Weller wrote: > What is the status of wiki i18n? Last I knew Nigel was working on some > of that stuff, and that was four months ago, and I haven't heard a > single thing since. > Nigel was working on it, I'm not sure of its current status. Things might have changed as we've done to minor upgrades since we were lsat working on it. The funny thing with these projects is it's always the last 10% that takes the longest :) -Mike From a.badger at gmail.com Thu Apr 23 01:44:33 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 22 Apr 2009 18:44:33 -0700 Subject: Change Request: database cleanup Message-ID: <49EFC801.40807@gmail.com> A couple weeks ago we were having problems with xen13. db2 was on xen13. We moved the databases that lived on db2 onto db3. That's been working out pretty well as db3 was sized to run koji before the latest round of koji optimizations so it's a pretty powerful box. However, when we moved the databases we left out the scripts that clean up the session tables for FAS. This means that everytime a user hits one of our websites, it makes the FAS database grow. Currently the FAS db is over 2GB in size with 860MB of that in the visit table. We can't reclaim the space without running a vacuum full (or dropping and recreating that table) which would mean downtime. However, we don't seem to have any performance issues at this time so I'm mostly concerned with the table continuing to grow rather than getting the space back. I'd like to apply the following change in puppet which just installs the cleanup script and cron job onto db3 where it can start working to keep the visit table at its present level. When we switch back to having db2 separate from db3 we can disable this script on db3 and drop the fas2 database there (which will recover the space). diff --git a/manifests/services/db.pp b/manifests/services/db.pp index 8e7587f..e5a6409 100644 --- a/manifests/services/db.pp +++ b/manifests/services/db.pp @@ -52,6 +52,17 @@ class kojiDb inherits postgresServer { source => "system/koji-cleanup-sessions.cron" } + cron { db-cleanup-sessions: + command => "/usr/local/bin/db-cleanup-sessions", + user => postgres, + minute => 10, + ensure => present, + } + + script { '/usr/local/bin/db-cleanup-sessions': + source => 'db/db-cleanup-sessions', + require => Package['postgresql8.3-server'], + } } class appDB inherits postgresServer { -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Thu Apr 23 01:55:19 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 22 Apr 2009 21:55:19 -0400 Subject: Change Request: database cleanup In-Reply-To: <49EFC801.40807@gmail.com> References: <49EFC801.40807@gmail.com> Message-ID: <20090423015519.GA20235@sphe.res.cmu.edu> > diff --git a/manifests/services/db.pp b/manifests/services/db.pp > index 8e7587f..e5a6409 100644 > --- a/manifests/services/db.pp > +++ b/manifests/services/db.pp > @@ -52,6 +52,17 @@ class kojiDb inherits postgresServer { > source => "system/koji-cleanup-sessions.cron" > } > > + cron { db-cleanup-sessions: > + command => "/usr/local/bin/db-cleanup-sessions", > + user => postgres, > + minute => 10, > + ensure => present, > + } > + > + script { '/usr/local/bin/db-cleanup-sessions': > + source => 'db/db-cleanup-sessions', > + require => Package['postgresql8.3-server'], > + } > } > > class appDB inherits postgresServer { +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nigjones at redhat.com Thu Apr 23 02:07:08 2009 From: nigjones at redhat.com (Nigel Jones) Date: Wed, 22 Apr 2009 22:07:08 -0400 (EDT) Subject: Change Request: database cleanup In-Reply-To: <49EFC801.40807@gmail.com> Message-ID: <23574560.791240452410842.JavaMail.nigjones@njones.bne.redhat.com> +1 ----- "Toshio Kuratomi" wrote: > A couple weeks ago we were having problems with xen13. db2 was on > xen13. We moved the databases that lived on db2 onto db3. That's > been > working out pretty well as db3 was sized to run koji before the > latest > round of koji optimizations so it's a pretty powerful box. > > However, when we moved the databases we left out the scripts that > clean > up the session tables for FAS. This means that everytime a user hits > one of our websites, it makes the FAS database grow. Currently the > FAS > db is over 2GB in size with 860MB of that in the visit table. > > We can't reclaim the space without running a vacuum full (or dropping > and recreating that table) which would mean downtime. However, we > don't > seem to have any performance issues at this time so I'm mostly > concerned > with the table continuing to grow rather than getting the space back. > > I'd like to apply the following change in puppet which just installs > the > cleanup script and cron job onto db3 where it can start working to > keep > the visit table at its present level. When we switch back to having > db2 > separate from db3 we can disable this script on db3 and drop the > fas2 > database there (which will recover the space). > > diff --git a/manifests/services/db.pp b/manifests/services/db.pp > index 8e7587f..e5a6409 100644 > --- a/manifests/services/db.pp > +++ b/manifests/services/db.pp > @@ -52,6 +52,17 @@ class kojiDb inherits postgresServer { > source => "system/koji-cleanup-sessions.cron" > } > > + cron { db-cleanup-sessions: > + command => "/usr/local/bin/db-cleanup-sessions", > + user => postgres, > + minute => 10, > + ensure => present, > + } > + > + script { '/usr/local/bin/db-cleanup-sessions': > + source => 'db/db-cleanup-sessions', > + require => Package['postgresql8.3-server'], > + } > } > > class appDB inherits postgresServer { > > > -Toshio > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From Matt_Domsch at dell.com Thu Apr 23 20:00:02 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 23 Apr 2009 15:00:02 -0500 Subject: [MirrorManager PATCH] Fix killall path, add requires on psmisc for killall. In-Reply-To: References: <20090420113102.GA21032@sphe.res.cmu.edu> <49EC6F9A.2040202@gmail.com> <20090420131534.GQ3316@sphe.res.cmu.edu> Message-ID: <20090423200002.GA9396@auslistsprd01.us.dell.com> On Mon, Apr 20, 2009 at 09:30:06AM -0500, Mike McGrath wrote: > On Mon, 20 Apr 2009, Ricky Zhou wrote: > > > On 2009-04-20 08:07:30 AM, Mike McGrath wrote: > > > +1 > > I've applied this to all of the app servers now. When Matt gets a > > chance, he can probably apply this to mirrormanager git. > > > > Just pushed these upstream, I'm in the gitmirroradmin group so I assume > that means it's ok for me to commit :) Yes, absolutely. Thanks both to Ricky and Mike. I suppose I should read f-i-l more often... :-) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Thu Apr 23 20:01:37 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 23 Apr 2009 15:01:37 -0500 Subject: metalink doesn't match In-Reply-To: <1240240980.9658.37.camel@code.and.org> References: <20090418173710.GA17912@angus.ind.WPI.EDU> <1240240980.9658.37.camel@code.and.org> Message-ID: <20090423200137.GB9396@auslistsprd01.us.dell.com> On Mon, Apr 20, 2009 at 11:23:00AM -0400, James Antill wrote: > On Sun, 2009-04-19 at 21:12 -0500, Mike McGrath wrote: > > Did you 'yum clean all' before testing this? > > This will never help. The error very likely means that MM hasn't picked > up that a new repomd.xml has arrived ... but that repomd.xml has hit all > the mirrors. Thus. the only available repodata is invalid. > If you have older cached repodata, then instead of: > > > > Error: Cannot retrieve repository metadata (repomd.xml) for > > > repository: rawhide. Please verify its path and try again > > It should revert to the old version and continue to work (so clean is > actively harmful here). Huh. MM should update its database every 15-30 minutes or so, and the mirrorlist cache every hour. How out-of-date was the returned repomd.xml? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ricky at fedoraproject.org Thu Apr 23 20:09:36 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 23 Apr 2009 16:09:36 -0400 Subject: Meeting Log - 2009-04-23 Message-ID: <20090423200936.GD20235@sphe.res.cmu.edu> 19:59 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting who's here? 19:59 * ricky (but will probably leave in the middle) 19:59 < ggruener> pong 20:00 * SmootherFrOgZ is 20:00 < mmcgrath> ok, lets get started 20:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Cloud Stuff 20:00 * nirik is the seats in the back. 20:00 -!- maploin [n=mapleoin at fedora/maploin] has joined #fedora-meeting 20:00 < mmcgrath> So the cloud stuff is coming along. Not much to report on an ETA for when we'll be giving out guests yet. 20:01 < mmcgrath> We've found (and filed) bugs that will probably need to be taken care of. 20:01 < mmcgrath> Generally though it's moving along 20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Xen13 20:01 -!- dkovalsk [n=dkovalsk at ip-89-103-122-242.karneval.cz] has quit Client Quit 20:01 < mmcgrath> so xen13 still hasn't been fixed and IBM has been slow getting back to me about whether or not this is the type of thing our on site warranty will cover. 20:01 * johe around to (just to tell) 20:02 < mmcgrath> johe: hey 20:02 * abadger1999 here 20:02 * mmcgrath makes note to get back to them today, haven't heard back 20:02 < mmcgrath> We're change frozen for the release. 20:03 < abadger1999> was the fan on xen13 a red herring? 20:03 < mmcgrath> abadger1999: well it was fan 7 (or something) which the server didn't have 20:03 < mmcgrath> The techs wanted me to power it down, disconnect the cmos battery and wait 5 minutes 20:03 < mmcgrath> but I'm not there 20:03 < mmcgrath> and no one will be on site. 20:03 -!- knurd is now known as knurd_afk 20:03 < mmcgrath> they think something buggy is happening in the cmos. 20:03 < mmcgrath> quite odd 20:04 < mmcgrath> But the preview release is scheduled for the 28th currently 20:04 < mmcgrath> AFAIK it's on schedule 20:04 < mmcgrath> https://fedorahosted.org/fedora-infrastructure/report/9 20:04 < mmcgrath> looks like everything is assigned and ready 20:04 < mmcgrath> Anyone have any questions or comments on the open preview tickets? 20:06 < mmcgrath> k 20:06 < mmcgrath> So that's really all I had to discuss for thsi meeting 20:06 < mmcgrath> sorry its short but I've got a couple of things going on at once 20:06 < mmcgrath> just the same 20:06 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:06 < mmcgrath> does anyone have anything to discuss? 20:07 < mmcgrath> If not I'll close the meeting in 30 :) 20:08 < johe> that was fast 20:08 < f13> I have.... nothing. 20:08 < mmcgrath> johe: yeah this was a quick one. 20:08 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Apr 23 20:30:25 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 23 Apr 2009 16:30:25 -0400 Subject: Preventing ctrl-c from blocking CVS commit messages Message-ID: <20090423203025.GE20235@sphe.res.cmu.edu> Hey, I'm currently testing a solution for the problem where one can prevent CVS commit mail from going out by pressing ctrl-c during the commit. To do this, I built a version of CVS with signal handling disabled and made a wrapper script for cvs server that traps SIGINT and some other things. I'd appreciate if people can test and try to abuse/break this setup :-), so I have a test repo setup. To test this, you need to be in sysadmin-test: 1. Prepend your ~/.ssh/authorized_keys file on publictest10.fedoraproject.org with: command="/home/fedora/ricky/test.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty (make sure not to accidentally lock yourself out with this) 2. Checkout the test module with: cvs -d :ext:username at publictest10.fedoraproject.org/home/fedora/ricky/repo co test 3. Try to make a commit without it getting logged in /home/fedora/ricky/repo/CVSROOT/commitlog Feel free to try clever/evil things to test this out. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Apr 24 18:54:42 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 24 Apr 2009 13:54:42 -0500 (CDT) Subject: App3 reboot (request) Message-ID: Can I get 2 +1's to reboot app3 (which is currently frozen) I'd like to power down xen13 and power it back up now that the BMC has been flashed. There shouldn't be any impact to the users except that /transifex/ will go down during the reboot. Which shouldn't be a problem as I believe most people are using /tx/ now anyway. 2 +1's ? -Mike From a.badger at gmail.com Fri Apr 24 19:10:51 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 24 Apr 2009 12:10:51 -0700 Subject: App3 reboot (request) In-Reply-To: References: Message-ID: <49F20EBB.4040505@gmail.com> Mike McGrath wrote: > Can I get 2 +1's to reboot app3 (which is currently frozen) > > I'd like to power down xen13 and power it back up now that the BMC has > been flashed. There shouldn't be any impact to the users except that > /transifex/ will go down during the reboot. Which shouldn't be a problem > as I believe most people are using /tx/ now anyway. > > 2 +1's ? > pinged glezos and diegobz. Okay from their side as long as we make sure ssh-agent comes back properly afterwards. +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From smooge at gmail.com Fri Apr 24 19:16:59 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 24 Apr 2009 13:16:59 -0600 Subject: App3 reboot (request) In-Reply-To: References: Message-ID: <80d7e4090904241216q5ffd8988t95fbdded73eb2e7f@mail.gmail.com> On Fri, Apr 24, 2009 at 12:54 PM, Mike McGrath wrote: > Can I get 2 +1's to reboot app3 (which is currently frozen) > > I'd like to power down xen13 and power it back up now that the BMC has > been flashed. ?There shouldn't be any impact to the users except that > /transifex/ will go down during the reboot. ?Which shouldn't be a problem > as I believe most people are using /tx/ now anyway. > > 2 +1's ? What is /tx/ and /transifex/? Not sure what they are.. but a +1 as broekn is broekn. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Fri Apr 24 21:21:56 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 24 Apr 2009 16:21:56 -0500 (CDT) Subject: App3 reboot (request) In-Reply-To: <80d7e4090904241216q5ffd8988t95fbdded73eb2e7f@mail.gmail.com> References: <80d7e4090904241216q5ffd8988t95fbdded73eb2e7f@mail.gmail.com> Message-ID: On Fri, 24 Apr 2009, Stephen John Smoogen wrote: > On Fri, Apr 24, 2009 at 12:54 PM, Mike McGrath wrote: > > Can I get 2 +1's to reboot app3 (which is currently frozen) > > > > I'd like to power down xen13 and power it back up now that the BMC has > > been flashed. ?There shouldn't be any impact to the users except that > > /transifex/ will go down during the reboot. ?Which shouldn't be a problem > > as I believe most people are using /tx/ now anyway. > > > > 2 +1's ? > > What is /tx/ and /transifex/? Not sure what they are.. > > but a +1 as broekn is broekn. > /transifex/ was actually not right it should have been /submit/ as in https://translate.fedoraproject.org/submit/ which is the turbogears transifex. The new one, django, is at https://translate.fedoraproject.org/tx/ -Mike From cra at WPI.EDU Fri Apr 24 22:12:12 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 24 Apr 2009 18:12:12 -0400 Subject: deltarpms not working since rawhide was signed Message-ID: <20090424221212.GB5296@angus.ind.WPI.EDU> As stated by Jonathan Dieter in the bug below, deltarpms are mucking up rawhide updates right now because the drpms were created before the packages were signed, and the signed versions don't match the deltarpm reconstructed versions. For me at least, this is causing a problem because I'm not using a mirrorlist right now (too many problems with metalink mismatches). So when yum fails to accept the drpm-patched package, the yum update just fails outright because there are no more mirrors to get the full updated package from. Is there anything that can be done on the infastructure side as proposed below? https://bugzilla.redhat.com/show_bug.cgi?id=497459 Comment #2 From Jonathan Dieter (jdieter at gmail.com) 2009-04-24 11:18:36 EDT (-) [reply] ------- This is not a deltarpm bug or a yum-presto bug, but rather an Infrastructure bug. The deltarpm was created before the target rpm was gpg signed. So it does indeed build to a valid rpm with exactly the same data as the downloaded rpm, but without the signature. Because it's not exactly the same file, yum refuses to use it and redownloads the full (signed) rpm (which is what it should do). The infrastructure should either delete and regenerate drpms after the rpm signatures have changed or they should use the code fragment from https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm signatures to deltarpms. Not sure how to reassign to Infrastructure. From Matt_Domsch at dell.com Fri Apr 24 23:02:35 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 24 Apr 2009 18:02:35 -0500 Subject: deltarpms not working since rawhide was signed In-Reply-To: <20090424221212.GB5296@angus.ind.WPI.EDU> References: <20090424221212.GB5296@angus.ind.WPI.EDU> Message-ID: <20090424230235.GA20131@auslistsprd01.us.dell.com> On Fri, Apr 24, 2009 at 06:12:12PM -0400, Chuck Anderson wrote: > As stated by Jonathan Dieter in the bug below, deltarpms are mucking > up rawhide updates right now because the drpms were created before the > packages were signed, and the signed versions don't match the deltarpm > reconstructed versions. For me at least, this is causing a problem > because I'm not using a mirrorlist right now (too many problems with > metalink mismatches). can you elaborate on this point? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Fri Apr 24 23:04:02 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 24 Apr 2009 18:04:02 -0500 (CDT) Subject: deltarpms not working since rawhide was signed In-Reply-To: <20090424221212.GB5296@angus.ind.WPI.EDU> References: <20090424221212.GB5296@angus.ind.WPI.EDU> Message-ID: On Fri, 24 Apr 2009, Chuck Anderson wrote: > As stated by Jonathan Dieter in the bug below, deltarpms are mucking > up rawhide updates right now because the drpms were created before the > packages were signed, and the signed versions don't match the deltarpm > reconstructed versions. For me at least, this is causing a problem > because I'm not using a mirrorlist right now (too many problems with > metalink mismatches). So when yum fails to accept the drpm-patched > package, the yum update just fails outright because there are no more > mirrors to get the full updated package from. > > Is there anything that can be done on the infastructure side as > proposed below? > > https://bugzilla.redhat.com/show_bug.cgi?id=497459 > > Comment #2 From Jonathan Dieter (jdieter at gmail.com) 2009-04-24 11:18:36 EDT (-) [reply] ------- > > This is not a deltarpm bug or a yum-presto bug, but rather an > Infrastructure bug. The deltarpm was created before the target rpm > was gpg signed. So it does indeed build to a valid rpm with exactly > the same data as the downloaded rpm, but without the signature. > Because it's not exactly the same file, yum refuses to use it and > redownloads the full (signed) rpm (which is what it should do). > > The infrastructure should either delete and regenerate drpms after the > rpm signatures have changed or they should use the code fragment from > https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm > signatures to deltarpms. > > Not sure how to reassign to Infrastructure. > Just so this doesn't get forgotten about I've created a rel-eng ticket: https://fedorahosted.org/rel-eng/ticket/1637 -Mike From Matt_Domsch at Dell.com Sat Apr 25 00:07:51 2009 From: Matt_Domsch at Dell.com (Matt Domsch) Date: Sat, 25 Apr 2009 00:07:51 +0000 Subject: deltarpms not working since rawhide was signed In-Reply-To: <20090424230235.GA20131@auslistsprd01.us.dell.com> References: <20090424221212.GB5296@angus.ind.WPI.EDU><20090424230235.GA20131@auslistsprd01.us.dell.com> Message-ID: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> I'm seeing the metalink problem and will investigate the cause. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: Matt Domsch Date: Fri, 24 Apr 2009 18:02:35 To: Subject: Re: deltarpms not working since rawhide was signed On Fri, Apr 24, 2009 at 06:12:12PM -0400, Chuck Anderson wrote: > As stated by Jonathan Dieter in the bug below, deltarpms are mucking > up rawhide updates right now because the drpms were created before the > packages were signed, and the signed versions don't match the deltarpm > reconstructed versions. For me at least, this is causing a problem > because I'm not using a mirrorlist right now (too many problems with > metalink mismatches). can you elaborate on this point? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From mmcgrath at redhat.com Sat Apr 25 00:15:51 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 24 Apr 2009 19:15:51 -0500 (CDT) Subject: deltarpms not working since rawhide was signed In-Reply-To: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> References: <20090424221212.GB5296@angus.ind.WPI.EDU><20090424230235.GA20131@auslistsprd01.us.dell.com> <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> Message-ID: On Sat, 25 Apr 2009, Matt Domsch wrote: > I'm seeing the metalink problem and will investigate the cause. > I haven't actually sat down and looked at this yet, is it completely a metalink problem or are there two different things going on? -Mike > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > > -----Original Message----- > From: Matt Domsch > > Date: Fri, 24 Apr 2009 18:02:35 > To: > Subject: Re: deltarpms not working since rawhide was signed > > > On Fri, Apr 24, 2009 at 06:12:12PM -0400, Chuck Anderson wrote: > > As stated by Jonathan Dieter in the bug below, deltarpms are mucking > > up rawhide updates right now because the drpms were created before the > > packages were signed, and the signed versions don't match the deltarpm > > reconstructed versions. For me at least, this is causing a problem > > because I'm not using a mirrorlist right now (too many problems with > > metalink mismatches). > > can you elaborate on this point? > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From Matt_Domsch at dell.com Sat Apr 25 00:44:50 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 24 Apr 2009 19:44:50 -0500 Subject: deltarpms not working since rawhide was signed In-Reply-To: References: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> Message-ID: <20090425004450.GB20131@auslistsprd01.us.dell.com> On Fri, Apr 24, 2009 at 07:15:51PM -0500, Mike McGrath wrote: > On Sat, 25 Apr 2009, Matt Domsch wrote: > > > I'm seeing the metalink problem and will investigate the cause. > > > > I haven't actually sat down and looked at this yet, is it completely a > metalink problem or are there two different things going on? metalinks are definitely sometimes wrong. For example, a repomd.xml file for updates/10/x86_64 that updated at -rw-r--r-- 1 263 mirrors 2391 Apr 24 19:35 repomd.xml was not being reported in the metalink at Date: Fri, 24 Apr 2009 23:15:02 GMT and I'm not yet sure why. update-master-directory-list is running a little more often than twice an hour on average, and the mirrorlist cache is updating every hour as expected. So the data is either not getting picked up during u-m-d-l runs, or is somehow not getting from the DB into the mirrorlist cache. If you see me monkey with u-m-d-l on bapp1, that's what I'm trying to figure out... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sat Apr 25 00:53:23 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 24 Apr 2009 19:53:23 -0500 Subject: deltarpms not working since rawhide was signed In-Reply-To: References: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> Message-ID: <20090425005323.GC20131@auslistsprd01.us.dell.com> On Fri, Apr 24, 2009 at 07:15:51PM -0500, Mike McGrath wrote: > On Sat, 25 Apr 2009, Matt Domsch wrote: > > > I'm seeing the metalink problem and will investigate the cause. > > > > I haven't actually sat down and looked at this yet, is it completely a > metalink problem or are there two different things going on? the drpm issue is completely different from the metalink problem. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sat Apr 25 04:48:16 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 24 Apr 2009 23:48:16 -0500 Subject: deltarpms not working since rawhide was signed In-Reply-To: <20090425004450.GB20131@auslistsprd01.us.dell.com> References: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> <20090425004450.GB20131@auslistsprd01.us.dell.com> Message-ID: <20090425044816.GD20131@auslistsprd01.us.dell.com> On Fri, Apr 24, 2009 at 07:44:50PM -0500, Matt Domsch wrote: > If you see me monkey with u-m-d-l on bapp1, that's what I'm trying to > figure out... Found it... update-master-directory-list was trying to be smart and failed. If it saw that a directory's ctime hadn't changed, it skipped it and moved on. But, a directory's ctime won't change if one of its _subdirectories' ctime_ changes. Because u-m-d-l runs every 30 minutes or so, it appears to catch tree updates mid-flight. In one run it sees updates/10/x86_64/ has changed, but that repodata/ under that has not (yet). So it marks updates/10/x86_64 as changed and moves on. On the next pass, updates/10/x86_64 of course _has not changed_, but it's repodata subdir has. This is what it was missing... It would skip processing the repodata subdir. (and yes, this would throw off the crawler too, which people have been complaining about being added and removed from the list somewhat randomly...) I'm working on a fix, which will involve changing update-master-directory-list. But that should be the only change. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sat Apr 25 04:59:14 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 24 Apr 2009 23:59:14 -0500 Subject: fix u-m-d-l In-Reply-To: <20090425044816.GD20131@auslistsprd01.us.dell.com> References: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> <20090425004450.GB20131@auslistsprd01.us.dell.com> <20090425044816.GD20131@auslistsprd01.us.dell.com> Message-ID: <20090425045914.GE20131@auslistsprd01.us.dell.com> On Fri, Apr 24, 2009 at 11:48:16PM -0500, Matt Domsch wrote: > On Fri, Apr 24, 2009 at 07:44:50PM -0500, Matt Domsch wrote: > > If you see me monkey with u-m-d-l on bapp1, that's what I'm trying to > > figure out... > > Found it... > > update-master-directory-list was trying to be smart and failed. If it > saw that a directory's ctime hadn't changed, it skipped it and moved > on. But, a directory's ctime won't change if one of its _subdirectories' ctime_ > changes. Because u-m-d-l runs every 30 minutes or so, it appears to > catch tree updates mid-flight. In one run it sees updates/10/x86_64/ > has changed, but that repodata/ under that has not (yet). So it > marks updates/10/x86_64 as changed and moves on. On the next pass, > updates/10/x86_64 of course _has not changed_, but it's repodata > subdir has. This is what it was missing... It would skip processing > the repodata subdir. > > (and yes, this would throw off the crawler too, which people have been > complaining about being added and removed from the list somewhat > randomly...) > > I'm working on a fix, which will involve changing > update-master-directory-list. But that should be the only change. This is the patch I want to apply on bapp1 to update-master-directory-list. It ensures that changes in repodata/ directories are handled, even if the parent directories don't appear to have changed. It still tries to be smart by not stat()ing files in a directory which hasn't changed it's ctime. Oh what I would give if inotify/dnotify worked on NFS... Can I get some +1s? --- update-master-directory-list 2009-04-07 03:53:55.000000000 +0000 +++ /home/fedora/mdomsch/update-master-directory-list 2009-04-25 04:50:18.000000000 +0000 @@ -168,8 +168,9 @@ def make_repomd_file_details(dir): - repodataDir = dir.name + '/repodata' - repomd_fname = os.path.join(rootdir, dir.name, 'repodata', 'repomd.xml') + if not dir.name.endswith('/repodata'): + return + repomd_fname = os.path.join(rootdir, dir.name, 'repomd.xml') if not os.path.exists(repomd_fname): return try: @@ -267,7 +268,7 @@ try: category_directories[parent_dname]['isRepository'] = True except KeyError: - category_directories[parent_dname] = {'files':{}, 'isRepository':True, 'readable':readable} + category_directories[parent_dname] = {'files':{}, 'isRepository':True, 'readable':readable, 'ctime':ctime} return dname, category_directories @@ -328,16 +329,17 @@ except SQLObjectNotFound: dir = Directory(name=dirpath,readable=value['readable'], ctime=value['ctime']) dir.addCategory(category) - if dir.files != short_filelist(value['files']): - dir.files = short_filelist(value['files']) + if value['changed']: + if dir.files != short_filelist(value['files']): + dir.files = short_filelist(value['files']) make_file_details_from_checksums(dir) # this has to be a second pass to be sure the child repodata/ dir is created in the db first for dirpath, value in category_directories.iteritems(): + dir = Directory.byName(dirpath) if value['isRepository']: - dir = Directory.byName(dirpath) make_repository(dir, category) - make_repomd_file_details(dir) + make_repomd_file_details(dir) ageFileDetails() def parse_rsync_listing(cname, f): @@ -417,27 +419,31 @@ dname = dname.rstrip('/') try: d = Directory.byName(dname) - if d.ctime == ctime: - # break out here because nothing has changed - continue + d_ctime = d.ctime except SQLObjectNotFound: # we'll need to create it - pass + d_ctime = 0 - print "%s has changed" % dname mode = s.st_mode readable = (mode & stat.S_IRWXO & (stat.S_IROTH|stat.S_IXOTH)) if not readable: unreadable_dirs[dname] = True isRepo = 'repodata' in dirnames - category_directories[dname] = {'files':{}, 'isRepository':isRepo, 'readable':readable, 'ctime':ctime} - for f in filenames: - try: - s = os.stat(os.path.join(dirpath, f)) - except OSError: - continue - category_directories[dname]['files'][f] = {'size':str(s.st_size), - 'stat':s[stat.ST_CTIME]} + + changed = (d_ctime != ctime) + if changed: + print "%s has changed" % dname + category_directories[dname] = {'files':{}, 'isRepository':isRepo, 'readable':readable, 'ctime':ctime, 'changed':changed} + + # skip per-file stat()s if the directory hasn't changed + if changed: + for f in filenames: + try: + s = os.stat(os.path.join(dirpath, f)) + except OSError: + continue + category_directories[dname]['files'][f] = {'size':str(s.st_size), + 'stat':s[stat.ST_CTIME]} sync_category_directories(category, category_directories) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ricky at fedoraproject.org Sat Apr 25 05:11:34 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 25 Apr 2009 01:11:34 -0400 Subject: fix u-m-d-l In-Reply-To: <20090425045914.GE20131@auslistsprd01.us.dell.com> References: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> <20090425004450.GB20131@auslistsprd01.us.dell.com> <20090425044816.GD20131@auslistsprd01.us.dell.com> <20090425045914.GE20131@auslistsprd01.us.dell.com> Message-ID: <20090425051134.GA28424@sphe.res.cmu.edu> On 2009-04-24 11:59:14 PM, Matt Domsch wrote: > Can I get some +1s? +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Matt_Domsch at dell.com Sat Apr 25 05:16:55 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 25 Apr 2009 00:16:55 -0500 Subject: fix u-m-d-l In-Reply-To: <20090425045914.GE20131@auslistsprd01.us.dell.com> References: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> <20090425004450.GB20131@auslistsprd01.us.dell.com> <20090425044816.GD20131@auslistsprd01.us.dell.com> <20090425045914.GE20131@auslistsprd01.us.dell.com> Message-ID: <20090425051655.GF20131@auslistsprd01.us.dell.com> On Fri, Apr 24, 2009 at 11:59:14PM -0500, Matt Domsch wrote: > --- update-master-directory-list 2009-04-07 03:53:55.000000000 +0000 > +++ /home/fedora/mdomsch/update-master-directory-list 2009-04-25 04:50:18.000000000 +0000 > @@ -168,8 +168,9 @@ > > > def make_repomd_file_details(dir): > - repodataDir = dir.name + '/repodata' > - repomd_fname = os.path.join(rootdir, dir.name, 'repodata', 'repomd.xml') > + if not dir.name.endswith('/repodata'): > + return > + repomd_fname = os.path.join(rootdir, dir.name, 'repomd.xml') > if not os.path.exists(repomd_fname): > return > try: Shortly after this hunk it was referencing the (now-deleted) repodataDir value and crashed. It doesn't need to do so anymore, so I deleted that line. Fixed patch below. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux --- update-master-directory-list 2009-04-07 03:53:55.000000000 +0000 +++ /home/fedora/mdomsch/update-master-directory-list 2009-04-25 05:05:14.000000000 +0000 @@ -168,8 +168,9 @@ def make_file_details_from_checksums(dir def make_repomd_file_details(dir): - repodataDir = dir.name + '/repodata' - repomd_fname = os.path.join(rootdir, dir.name, 'repodata', 'repomd.xml') + if not dir.name.endswith('/repodata'): + return + repomd_fname = os.path.join(rootdir, dir.name, 'repomd.xml') if not os.path.exists(repomd_fname): return try: @@ -188,7 +189,6 @@ def make_repomd_file_details(dir): if 'timestamp' not in yumrepo.__dict__: set_repomd_timestamp(yumrepo) timestamp = yumrepo.timestamp - dir = Directory.byName(repodataDir) try: fd = FileDetail.selectBy(directory=dir, filename='repomd.xml', sha1=sha1, md5=md5, sha256=sha256, sha512=sha512, timestamp=timestamp, size=size)[0] @@ -267,7 +267,7 @@ def make_one_directory(line, category, p try: category_directories[parent_dname]['isRepository'] = True except KeyError: - category_directories[parent_dname] = {'files':{}, 'isRepository':True, 'readable':readable} + category_directories[parent_dname] = {'files':{}, 'isRepository':True, 'readable':readable, 'ctime':ctime} return dname, category_directories @@ -328,16 +328,17 @@ def sync_category_directories(category, except SQLObjectNotFound: dir = Directory(name=dirpath,readable=value['readable'], ctime=value['ctime']) dir.addCategory(category) - if dir.files != short_filelist(value['files']): - dir.files = short_filelist(value['files']) + if value['changed']: + if dir.files != short_filelist(value['files']): + dir.files = short_filelist(value['files']) make_file_details_from_checksums(dir) # this has to be a second pass to be sure the child repodata/ dir is created in the db first for dirpath, value in category_directories.iteritems(): + dir = Directory.byName(dirpath) if value['isRepository']: - dir = Directory.byName(dirpath) make_repository(dir, category) - make_repomd_file_details(dir) + make_repomd_file_details(dir) ageFileDetails() def parse_rsync_listing(cname, f): @@ -417,27 +418,31 @@ def sync_directories_from_directory(dire dname = dname.rstrip('/') try: d = Directory.byName(dname) - if d.ctime == ctime: - # break out here because nothing has changed - continue + d_ctime = d.ctime except SQLObjectNotFound: # we'll need to create it - pass + d_ctime = 0 - print "%s has changed" % dname mode = s.st_mode readable = (mode & stat.S_IRWXO & (stat.S_IROTH|stat.S_IXOTH)) if not readable: unreadable_dirs[dname] = True isRepo = 'repodata' in dirnames - category_directories[dname] = {'files':{}, 'isRepository':isRepo, 'readable':readable, 'ctime':ctime} - for f in filenames: - try: - s = os.stat(os.path.join(dirpath, f)) - except OSError: - continue - category_directories[dname]['files'][f] = {'size':str(s.st_size), - 'stat':s[stat.ST_CTIME]} + + changed = (d_ctime != ctime) + if changed: + print "%s has changed" % dname + category_directories[dname] = {'files':{}, 'isRepository':isRepo, 'readable':readable, 'ctime':ctime, 'changed':changed} + + # skip per-file stat()s if the directory hasn't changed + if changed: + for f in filenames: + try: + s = os.stat(os.path.join(dirpath, f)) + except OSError: + continue + category_directories[dname]['files'][f] = {'size':str(s.st_size), + 'stat':s[stat.ST_CTIME]} sync_category_directories(category, category_directories) @@ -451,9 +456,9 @@ def main(): if len(sys.argv) >= 3: rootdir=sys.argv[2] - if manage_pidfile(pidfile): - print "another instance is running, try again later." - sys.exit(1) +# if manage_pidfile(pidfile): +# print "another instance is running, try again later." +# sys.exit(1) for i in config.get('umdl.master_directories'): try: @@ -471,7 +476,7 @@ def main(): excludes = i.get('excludes', []) sync_directories_from_directory(i['path'], i['category'], excludes) - remove_pidfile(pidfile) +# remove_pidfile(pidfile) return 0 if __name__ == "__main__": From a.badger at gmail.com Sat Apr 25 05:17:32 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 24 Apr 2009 22:17:32 -0700 Subject: fix u-m-d-l In-Reply-To: <20090425045914.GE20131@auslistsprd01.us.dell.com> References: <1405898731-1240618068-cardhu_decombobulator_blackberry.rim.net-1503323473-@bxe1241.bisx.prod.on.blackberry> <20090425004450.GB20131@auslistsprd01.us.dell.com> <20090425044816.GD20131@auslistsprd01.us.dell.com> <20090425045914.GE20131@auslistsprd01.us.dell.com> Message-ID: <49F29CEC.9030403@gmail.com> Matt Domsch wrote: > On Fri, Apr 24, 2009 at 11:48:16PM -0500, Matt Domsch wrote: >> On Fri, Apr 24, 2009 at 07:44:50PM -0500, Matt Domsch wrote: >>> If you see me monkey with u-m-d-l on bapp1, that's what I'm trying to >>> figure out... >> Found it... >> >> update-master-directory-list was trying to be smart and failed. If it >> saw that a directory's ctime hadn't changed, it skipped it and moved >> on. But, a directory's ctime won't change if one of its _subdirectories' ctime_ >> changes. Because u-m-d-l runs every 30 minutes or so, it appears to >> catch tree updates mid-flight. In one run it sees updates/10/x86_64/ >> has changed, but that repodata/ under that has not (yet). So it >> marks updates/10/x86_64 as changed and moves on. On the next pass, >> updates/10/x86_64 of course _has not changed_, but it's repodata >> subdir has. This is what it was missing... It would skip processing >> the repodata subdir. >> >> (and yes, this would throw off the crawler too, which people have been >> complaining about being added and removed from the list somewhat >> randomly...) >> >> I'm working on a fix, which will involve changing >> update-master-directory-list. But that should be the only change. > > This is the patch I want to apply on bapp1 to > update-master-directory-list. It ensures that changes in repodata/ > directories are handled, even if the parent directories don't appear > to have changed. It still tries to be smart by not stat()ing files in > a directory which hasn't changed it's ctime. > > Oh what I would give if inotify/dnotify worked on NFS... > > Can I get some +1s? > We'll want this working by release no matter what so +1 to getting the fix out there. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Mon Apr 27 16:35:58 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Apr 2009 12:35:58 -0400 Subject: deltarpms not working since rawhide was signed In-Reply-To: <20090424221212.GB5296@angus.ind.WPI.EDU> References: <20090424221212.GB5296@angus.ind.WPI.EDU> Message-ID: <20090427163558.GF16690@nostromo.devel.redhat.com> Chuck Anderson (cra at WPI.EDU) said: > The infrastructure should either delete and regenerate drpms after the > rpm signatures have changed or they should use the code fragment from > https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm > signatures to deltarpms. That's *really* hard, as there's not any state to track when packages have been signed out from under the prior delta rpms. The simplest solution would be to just nuke the old ones by hand. Bill From skvidal at fedoraproject.org Mon Apr 27 16:37:28 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 27 Apr 2009 12:37:28 -0400 (EDT) Subject: deltarpms not working since rawhide was signed In-Reply-To: <20090427163558.GF16690@nostromo.devel.redhat.com> References: <20090424221212.GB5296@angus.ind.WPI.EDU> <20090427163558.GF16690@nostromo.devel.redhat.com> Message-ID: On Mon, 27 Apr 2009, Bill Nottingham wrote: > Chuck Anderson (cra at WPI.EDU) said: >> The infrastructure should either delete and regenerate drpms after the >> rpm signatures have changed or they should use the code fragment from >> https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm >> signatures to deltarpms. > > That's *really* hard, as there's not any state to track when packages > have been signed out from under the prior delta rpms. > > The simplest solution would be to just nuke the old ones by hand. > when they are signed? or nuke them in createrepo? -sv From notting at redhat.com Mon Apr 27 17:31:30 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Apr 2009 13:31:30 -0400 Subject: deltarpms not working since rawhide was signed In-Reply-To: References: <20090424221212.GB5296@angus.ind.WPI.EDU> <20090427163558.GF16690@nostromo.devel.redhat.com> Message-ID: <20090427173130.GH16690@nostromo.devel.redhat.com> Seth Vidal (skvidal at fedoraproject.org) said: >> That's *really* hard, as there's not any state to track when packages >> have been signed out from under the prior delta rpms. >> >> The simplest solution would be to just nuke the old ones by hand. > > when they are signed? or nuke them in createrepo? When rawhide becomes signed, nuke the old drpnms by hand in the tree we're diffing against, so they're not carried forward. If createrepo wants to do signature checking of drpms when it's creating the metadata, it can, and that would also fix this. But that's more work. Bill From skvidal at fedoraproject.org Mon Apr 27 17:53:31 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 27 Apr 2009 13:53:31 -0400 (EDT) Subject: deltarpms not working since rawhide was signed In-Reply-To: <20090427173130.GH16690@nostromo.devel.redhat.com> References: <20090424221212.GB5296@angus.ind.WPI.EDU> <20090427163558.GF16690@nostromo.devel.redhat.com> <20090427173130.GH16690@nostromo.devel.redhat.com> Message-ID: On Mon, 27 Apr 2009, Bill Nottingham wrote: > Seth Vidal (skvidal at fedoraproject.org) said: >>> That's *really* hard, as there's not any state to track when packages >>> have been signed out from under the prior delta rpms. >>> >>> The simplest solution would be to just nuke the old ones by hand. >> >> when they are signed? or nuke them in createrepo? > > When rawhide becomes signed, nuke the old drpnms by hand in the tree > we're diffing against, so they're not carried forward. > > If createrepo wants to do signature checking of drpms when it's creating > the metadata, it can, and that would also fix this. But that's more > work. Yah - I kinda wonder if it is worth the time to check all of them to weed out the no-longer valid ones. -sv From lmacken at redhat.com Mon Apr 27 19:54:22 2009 From: lmacken at redhat.com (Luke Macken) Date: Mon, 27 Apr 2009 15:54:22 -0400 Subject: More auth options In-Reply-To: <200903301257.24803.dennis@ausil.us> References: <200903301257.24803.dennis@ausil.us> Message-ID: <20090427195422.GD3379@x300> On Mon, Mar 30, 2009 at 12:57:23PM -0500, Dennis Gilmore wrote: > So doing a liitle looking around I cane across some options that look > interesting, the following options would mean you need to physically have > something to login. > > yubikey > http://www.yubico.com/products/yubikey/ > It would require a pam module and for us to setup a server for managing keys. > it looks to be fairly low cost. it would implement a 2 facter > authentication. I've been a big fan of yubikey for a while now. The technology is secure, the hardware is solid, and the source is open. Aside from their online docs, this podcast was quite informative was well: http://twit.tv/sn143 luke From ian at ianweller.org Tue Apr 28 01:31:39 2009 From: ian at ianweller.org (Ian Weller) Date: Mon, 27 Apr 2009 20:31:39 -0500 Subject: sphinx as search solution? Message-ID: <20090428013139.GC22251@kupenblagster.ianweller.org> Here's a search engine solution[1] that doesn't run on Java and has a MediaWiki plugin[2]. Please take a look at let me know what you think with regards to using it for Fedora Infra's purposes. [1] http://www.sphinxsearch.com/ [2] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:SphinxSearch -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From stickster at gmail.com Tue Apr 28 02:26:48 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 27 Apr 2009 22:26:48 -0400 Subject: Statistics problem Message-ID: <20090428022648.GD17892@localhost.localdomain> I found that our statistics for downloading have not been properly capturing requests for Live ISO images from our download links on the fp.o/get-fedora page. I'll be updating the numbers on the wiki's [[Statistics]] page in the next day or two. I did two counts, one for DVD and Live without uniq'ing the IP addresses doing the retrievals (because there could be multiple downloads from people behind firewalls), and one with. In both cases I think the numbers are very significantly higher than our current stats show. The raw numbers per day since F10 release are attached. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- Direct downloads: 2008-11-25 DVD=43045 Live=59159 UniqueDVD=14849 UniqueLive=29660 2008-11-26 DVD=87646 Live=111741 UniqueDVD=22154 UniqueLive=44653 2008-11-27 DVD=48131 Live=51332 UniqueDVD=12877 UniqueLive=24894 2008-11-28 DVD=36580 Live=35519 UniqueDVD=9739 UniqueLive=18136 2008-11-29 DVD=28507 Live=31680 UniqueDVD=7431 UniqueLive=14453 2008-11-30 DVD=18901 Live=22297 UniqueDVD=5741 UniqueLive=12106 2008-12-01 DVD=19723 Live=23835 UniqueDVD=6738 UniqueLive=13455 2008-12-02 DVD=18263 Live=23298 UniqueDVD=6384 UniqueLive=12244 2008-12-03 DVD=14057 Live=21774 UniqueDVD=5792 UniqueLive=11312 2008-12-04 DVD=15178 Live=18501 UniqueDVD=5364 UniqueLive=10660 2008-12-05 DVD=16458 Live=19092 UniqueDVD=5130 UniqueLive=10433 2008-12-06 DVD=12817 Live=17015 UniqueDVD=4223 UniqueLive=9200 2008-12-07 DVD=9606 Live=15050 UniqueDVD=3698 UniqueLive=8234 2008-12-08 DVD=12017 Live=15502 UniqueDVD=4238 UniqueLive=9082 2008-12-09 DVD=12071 Live=15314 UniqueDVD=3871 UniqueLive=8170 2008-12-10 DVD=18208 Live=14963 UniqueDVD=4311 UniqueLive=8693 2008-12-11 DVD=19493 Live=16698 UniqueDVD=4131 UniqueLive=8680 2008-12-12 DVD=19506 Live=15380 UniqueDVD=4005 UniqueLive=8543 2008-12-13 DVD=10450 Live=13221 UniqueDVD=3612 UniqueLive=7799 2008-12-14 DVD=7965 Live=12531 UniqueDVD=3171 UniqueLive=7132 2008-12-15 DVD=12683 Live=16200 UniqueDVD=3781 UniqueLive=7841 2008-12-16 DVD=12064 Live=13711 UniqueDVD=3755 UniqueLive=8147 2008-12-17 DVD=16936 Live=14227 UniqueDVD=3730 UniqueLive=7963 2008-12-18 DVD=23106 Live=14835 UniqueDVD=3699 UniqueLive=7791 2008-12-19 DVD=18697 Live=15904 UniqueDVD=3597 UniqueLive=7571 2008-12-20 DVD=10699 Live=13776 UniqueDVD=3304 UniqueLive=6908 2008-12-21 DVD=17127 Live=13330 UniqueDVD=2909 UniqueLive=6524 2008-12-22 DVD=21665 Live=13987 UniqueDVD=3524 UniqueLive=7560 2008-12-23 DVD=10110 Live=13695 UniqueDVD=3565 UniqueLive=7550 2008-12-24 DVD=7544 Live=11250 UniqueDVD=3019 UniqueLive=6355 2008-12-25 DVD=7431 Live=10241 UniqueDVD=2522 UniqueLive=5528 2008-12-26 DVD=7696 Live=12258 UniqueDVD=2928 UniqueLive=6633 2008-12-27 DVD=20675 Live=11878 UniqueDVD=2710 UniqueLive=6258 2008-12-28 DVD=19961 Live=11346 UniqueDVD=2637 UniqueLive=6089 2008-12-29 DVD=11236 Live=13551 UniqueDVD=3297 UniqueLive=7260 2008-12-30 DVD=12603 Live=12397 UniqueDVD=3217 UniqueLive=7206 2008-12-31 DVD=7148 Live=11271 UniqueDVD=2735 UniqueLive=6244 2009-01-01 DVD=5552 Live=10194 UniqueDVD=2200 UniqueLive=5350 2009-01-02 DVD=6648 Live=12335 UniqueDVD=2797 UniqueLive=6987 2009-01-03 DVD=5083 Live=16710 UniqueDVD=2521 UniqueLive=6391 2009-01-04 DVD=6165 Live=12498 UniqueDVD=2501 UniqueLive=6181 2009-01-05 DVD=7412 Live=13387 UniqueDVD=3336 UniqueLive=7436 2009-01-06 DVD=7815 Live=12734 UniqueDVD=3198 UniqueLive=7408 2009-01-07 DVD=8113 Live=13990 UniqueDVD=3307 UniqueLive=7542 2009-01-08 DVD=7414 Live=35315 UniqueDVD=3225 UniqueLive=7658 2009-01-09 DVD=9220 Live=25712 UniqueDVD=3198 UniqueLive=7590 2009-01-10 DVD=7318 Live=12388 UniqueDVD=2849 UniqueLive=7007 2009-01-11 DVD=6550 Live=12629 UniqueDVD=2496 UniqueLive=6439 2009-01-12 DVD=7771 Live=18301 UniqueDVD=3100 UniqueLive=7712 2009-01-13 DVD=23568 Live=14146 UniqueDVD=3392 UniqueLive=7737 2009-01-14 DVD=7943 Live=13398 UniqueDVD=3246 UniqueLive=7748 2009-01-15 DVD=7973 Live=13728 UniqueDVD=3136 UniqueLive=7691 2009-01-16 DVD=7917 Live=13258 UniqueDVD=3150 UniqueLive=7602 2009-01-17 DVD=7616 Live=12964 UniqueDVD=2880 UniqueLive=7007 2009-01-18 DVD=7151 Live=11156 UniqueDVD=2534 UniqueLive=6500 2009-01-19 DVD=7899 Live=13411 UniqueDVD=3081 UniqueLive=7597 2009-01-20 DVD=7803 Live=12599 UniqueDVD=3198 UniqueLive=7476 2009-01-21 DVD=8757 Live=12744 UniqueDVD=3144 UniqueLive=7603 2009-01-22 DVD=7163 Live=12788 UniqueDVD=3165 UniqueLive=7572 2009-01-23 DVD=6885 Live=12838 UniqueDVD=3088 UniqueLive=7778 2009-01-24 DVD=7518 Live=12169 UniqueDVD=2790 UniqueLive=7186 2009-01-25 DVD=13290 Live=10781 UniqueDVD=2506 UniqueLive=6489 2009-01-26 DVD=6438 Live=12718 UniqueDVD=2850 UniqueLive=7237 2009-01-27 DVD=6406 Live=12407 UniqueDVD=2964 UniqueLive=7511 2009-01-28 DVD=7536 Live=13468 UniqueDVD=3123 UniqueLive=8003 2009-01-29 DVD=6820 Live=13102 UniqueDVD=3192 UniqueLive=7636 2009-01-30 DVD=8321 Live=12231 UniqueDVD=2970 UniqueLive=7392 2009-01-31 DVD=7593 Live=12388 UniqueDVD=2721 UniqueLive=6938 2009-02-01 DVD=6787 Live=11746 UniqueDVD=2589 UniqueLive=6295 2009-02-02 DVD=6741 Live=13029 UniqueDVD=3096 UniqueLive=7358 2009-02-03 DVD=6690 Live=13210 UniqueDVD=3177 UniqueLive=7750 2009-02-04 DVD=7081 Live=13791 UniqueDVD=3279 UniqueLive=7793 2009-02-05 DVD=8396 Live=14323 UniqueDVD=3176 UniqueLive=8023 2009-02-06 DVD=8709 Live=12667 UniqueDVD=2992 UniqueLive=7661 2009-02-07 DVD=6676 Live=12006 UniqueDVD=2660 UniqueLive=7050 2009-02-08 DVD=5436 Live=11517 UniqueDVD=2388 UniqueLive=6556 2009-02-09 DVD=22896 Live=12065 UniqueDVD=2814 UniqueLive=7210 2009-02-10 DVD=7567 Live=12714 UniqueDVD=2934 UniqueLive=7593 2009-02-11 DVD=7117 Live=13319 UniqueDVD=2929 UniqueLive=7496 2009-02-12 DVD=9663 Live=16677 UniqueDVD=2853 UniqueLive=7428 2009-02-13 DVD=7090 Live=13238 UniqueDVD=2838 UniqueLive=7275 2009-02-14 DVD=6041 Live=11919 UniqueDVD=2444 UniqueLive=6803 2009-02-15 DVD=4928 Live=11026 UniqueDVD=2293 UniqueLive=6305 2009-02-16 DVD=6636 Live=12312 UniqueDVD=2753 UniqueLive=7127 2009-02-17 DVD=8848 Live=13098 UniqueDVD=2879 UniqueLive=7412 2009-02-18 DVD=9388 Live=15167 UniqueDVD=3044 UniqueLive=7666 2009-02-19 DVD=8111 Live=13654 UniqueDVD=2952 UniqueLive=7412 2009-02-20 DVD=7956 Live=13343 UniqueDVD=2895 UniqueLive=7557 2009-02-21 DVD=5302 Live=11887 UniqueDVD=2508 UniqueLive=6763 2009-02-22 DVD=5652 Live=11156 UniqueDVD=2260 UniqueLive=6249 2009-02-23 DVD=6338 Live=12836 UniqueDVD=2700 UniqueLive=6919 2009-02-24 DVD=7136 Live=12156 UniqueDVD=2773 UniqueLive=7099 2009-02-25 DVD=7226 Live=12372 UniqueDVD=2735 UniqueLive=6986 2009-02-26 DVD=7263 Live=13732 UniqueDVD=2831 UniqueLive=7757 2009-02-27 DVD=6442 Live=13213 UniqueDVD=2801 UniqueLive=7257 2009-02-28 DVD=6096 Live=13082 UniqueDVD=2487 UniqueLive=6806 2009-03-01 DVD=5458 Live=11879 UniqueDVD=2345 UniqueLive=6065 2009-03-02 DVD=7125 Live=12248 UniqueDVD=2752 UniqueLive=6975 2009-03-03 DVD=7813 Live=14099 UniqueDVD=2852 UniqueLive=7245 2009-03-04 DVD=11268 Live=15943 UniqueDVD=2843 UniqueLive=7534 2009-03-05 DVD=8004 Live=12200 UniqueDVD=2863 UniqueLive=7213 2009-03-06 DVD=7720 Live=13607 UniqueDVD=2822 UniqueLive=7099 2009-03-07 DVD=5569 Live=12484 UniqueDVD=2396 UniqueLive=6420 2009-03-08 DVD=5178 Live=10855 UniqueDVD=2103 UniqueLive=5848 2009-03-09 DVD=7460 Live=12164 UniqueDVD=2635 UniqueLive=6793 2009-03-10 DVD=9433 Live=12385 UniqueDVD=2740 UniqueLive=7247 2009-03-11 DVD=7352 Live=11588 UniqueDVD=2697 UniqueLive=6872 2009-03-12 DVD=7157 Live=13369 UniqueDVD=2874 UniqueLive=7419 2009-03-13 DVD=9291 Live=12110 UniqueDVD=2647 UniqueLive=6933 2009-03-14 DVD=6999 Live=10970 UniqueDVD=2408 UniqueLive=6267 2009-03-15 DVD=10114 Live=10225 UniqueDVD=2076 UniqueLive=5874 2009-03-16 DVD=17628 Live=12128 UniqueDVD=2590 UniqueLive=6880 2009-03-17 DVD=7790 Live=11493 UniqueDVD=2584 UniqueLive=6846 2009-03-18 DVD=9082 Live=11817 UniqueDVD=2624 UniqueLive=6941 2009-03-19 DVD=8656 Live=12418 UniqueDVD=2631 UniqueLive=6815 2009-03-20 DVD=7734 Live=11567 UniqueDVD=2716 UniqueLive=6713 2009-03-21 DVD=8182 Live=11779 UniqueDVD=2238 UniqueLive=6227 2009-03-22 DVD=8240 Live=10757 UniqueDVD=2008 UniqueLive=5742 2009-03-23 DVD=9597 Live=11392 UniqueDVD=2563 UniqueLive=6570 2009-03-24 DVD=6290 Live=12394 UniqueDVD=2641 UniqueLive=6985 2009-03-25 DVD=6109 Live=12446 UniqueDVD=2570 UniqueLive=6805 2009-03-26 DVD=10963 Live=11602 UniqueDVD=2630 UniqueLive=6885 2009-03-27 DVD=6691 Live=11985 UniqueDVD=2678 UniqueLive=6715 2009-03-28 DVD=9073 Live=10905 UniqueDVD=2307 UniqueLive=6088 2009-03-29 DVD=6405 Live=11673 UniqueDVD=2033 UniqueLive=5564 2009-03-30 DVD=9985 Live=12864 UniqueDVD=2469 UniqueLive=6560 2009-03-31 DVD=6635 Live=15308 UniqueDVD=2587 UniqueLive=6707 2009-04-01 DVD=6071 Live=12032 UniqueDVD=2546 UniqueLive=6743 2009-04-02 DVD=6099 Live=17018 UniqueDVD=2528 UniqueLive=6540 2009-04-03 DVD=5989 Live=13561 UniqueDVD=2437 UniqueLive=6432 2009-04-04 DVD=5205 Live=12175 UniqueDVD=2140 UniqueLive=5711 2009-04-05 DVD=4164 Live=17395 UniqueDVD=1852 UniqueLive=5209 2009-04-06 DVD=6403 Live=16622 UniqueDVD=2314 UniqueLive=6067 2009-04-07 DVD=6301 Live=11676 UniqueDVD=2520 UniqueLive=6448 2009-04-08 DVD=6888 Live=15435 UniqueDVD=2539 UniqueLive=6633 2009-04-09 DVD=5839 Live=13984 UniqueDVD=2401 UniqueLive=6319 2009-04-10 DVD=6956 Live=17016 UniqueDVD=2248 UniqueLive=6008 2009-04-11 DVD=5779 Live=19826 UniqueDVD=1993 UniqueLive=5347 2009-04-12 DVD=5951 Live=10807 UniqueDVD=1800 UniqueLive=4901 2009-04-13 DVD=6449 Live=17217 UniqueDVD=2223 UniqueLive=5722 2009-04-14 DVD=5238 Live=12572 UniqueDVD=2447 UniqueLive=6148 2009-04-15 DVD=7968 Live=13083 UniqueDVD=2351 UniqueLive=6201 2009-04-16 DVD=6393 Live=13195 UniqueDVD=2402 UniqueLive=6108 2009-04-17 DVD=5158 Live=16285 UniqueDVD=2335 UniqueLive=6043 2009-04-18 DVD=4997 Live=21233 UniqueDVD=2065 UniqueLive=5343 2009-04-19 DVD=6357 Live=24639 UniqueDVD=1779 UniqueLive=4716 2009-04-20 DVD=4901 Live=18135 UniqueDVD=2177 UniqueLive=5756 2009-04-21 DVD=5103 Live=11575 UniqueDVD=2255 UniqueLive=6099 2009-04-22 DVD=5185 Live=10194 UniqueDVD=2400 UniqueLive=6141 2009-04-23 DVD=6274 Live=31764 UniqueDVD=2293 UniqueLive=5909 2009-04-24 DVD=7486 Live=15202 UniqueDVD=2269 UniqueLive=5934 2009-04-25 DVD=6655 Live=10235 UniqueDVD=1922 UniqueLive=5252 2009-04-26 DVD=5148 Live=10810 UniqueDVD=1722 UniqueLive=4798 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Tue Apr 28 12:29:50 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 28 Apr 2009 08:29:50 -0400 Subject: Statistics problem In-Reply-To: <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> Message-ID: <20090428122950.GC13551@localhost.localdomain> On Mon, Apr 27, 2009 at 07:43:01PM -0800, Jeff Spaleta wrote: > On Mon, Apr 27, 2009 at 6:30 PM, Jeff Spaleta wrote: > > On Mon, Apr 27, 2009 at 6:26 PM, Paul W. Frields wrote: > >> I did two counts, one for DVD and Live without uniq'ing the IP > >> addresses doing the retrievals (because there could be multiple > >> downloads from people behind firewalls), and one with. ?In both cases > >> I think the numbers are very significantly higher than our current > >> stats show. ?The raw numbers per day since F10 release are attached. > > > > All those numbers in the txt use the "corrected" approach? > > Just to be clear.. what where the stats showing before? Just the > unique DVD counts? The download numbers before were using the direct download command shown on this wiki page: https://fedoraproject.org/wiki/Statistics/Commands There was at least one major problem with that command; the Fedora 10 Live ISO filenames don't start with "Fedora-10," they start with "F10," meaning we weren't counting them *at all*. So I've included two counts, one for the DVD and one for the Live ISO as clicked from the get-fedora page. (Other spins, as far as I can tell, are done via torrent and we're capturing those statistics from the tracker elsewhere.) The second problem may not be a real problem -- it's that we are uniq-ing the IP addresses doing the downloading. That method has the potential to cut out legitimate, repetitive downloads from inside a firewall. I'd feel better cutting those ticks out if they were separated by a very short timeframe. Then we could be reasonably certain they were caused by repeated clicks, rather than actual separate downloads. In the interest of a conservative approach, I'm willing to stick with uniq-ing the stats, but I produced both sets of numbers anyway. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonstanley at gmail.com Tue Apr 28 12:44:15 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 28 Apr 2009 08:44:15 -0400 Subject: Statistics problem In-Reply-To: <20090428122950.GC13551@localhost.localdomain> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> Message-ID: On Tue, Apr 28, 2009 at 8:29 AM, Paul W. Frields wrote: > uniq-ing the IP addresses doing the downloading. ?That method has the > potential to cut out legitimate, repetitive downloads from inside a > firewall. ?I'd feel better cutting those ticks out if they were I'm not sure if you can see this in our logs or not (you might have to have the individual mirrors logs :( ), but if the response code is a 206, that means it was a RANGE request - to download part of a file. It's not at all uncommon for a download manager to open 20-30 connections to download the same file for the same user., So I'd opt for the conservative approach of uniques as well. From stickster at gmail.com Tue Apr 28 12:57:50 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 28 Apr 2009 08:57:50 -0400 Subject: Statistics problem In-Reply-To: References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> Message-ID: <20090428125750.GE13551@localhost.localdomain> On Tue, Apr 28, 2009 at 08:44:15AM -0400, Jon Stanley wrote: > On Tue, Apr 28, 2009 at 8:29 AM, Paul W. Frields wrote: > > > uniq-ing the IP addresses doing the downloading. ?That method has the > > potential to cut out legitimate, repetitive downloads from inside a > > firewall. ?I'd feel better cutting those ticks out if they were > > I'm not sure if you can see this in our logs or not (you might have to > have the individual mirrors logs :( ), but if the response code is a > 206, that means it was a RANGE request - to download part of a file. > It's not at all uncommon for a download manager to open 20-30 > connections to download the same file for the same user., > > So I'd opt for the conservative approach of uniques as well. To clarify, I'm already filtering these out on a 302 code. How would that change your opinion, if at all? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From josemanimala at gmail.com Tue Apr 28 13:36:35 2009 From: josemanimala at gmail.com (jose manimala) Date: Tue, 28 Apr 2009 19:06:35 +0530 Subject: sphinx as search solution? In-Reply-To: <20090428013139.GC22251@kupenblagster.ianweller.org> References: <20090428013139.GC22251@kupenblagster.ianweller.org> Message-ID: <53a863600904280636j6bec0460s7a53e4bcf51341e5@mail.gmail.com> Hey Ian, I had a crack at it on the pt10 machine... but its a little bit on the heavier side uses a lot of resources... I have been running some tests with HT:dig and lucene... Ht dig hung up the test machine while indexing... :) Jose On Tue, Apr 28, 2009 at 7:01 AM, Ian Weller wrote: > Here's a search engine solution[1] that doesn't run on Java and has a > MediaWiki plugin[2]. Please take a look at let me know what you think > with regards to using it for Fedora Infra's purposes. > > [1] http://www.sphinxsearch.com/ > [2] > https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:SphinxSearch > > -- > Ian Weller > GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -- Jose M Manimala http://www.jmmblog.in.eu.org Ph: +919790824111 GPGkeyID: F5DD9656 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonstanley at gmail.com Tue Apr 28 13:47:18 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 28 Apr 2009 09:47:18 -0400 Subject: Statistics problem In-Reply-To: <20090428125750.GE13551@localhost.localdomain> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> Message-ID: On Tue, Apr 28, 2009 at 8:57 AM, Paul W. Frields wrote: > To clarify, I'm already filtering these out on a 302 code. ?How would > that change your opinion, if at all? 302's are just redirects, which is all we do. What I'm not sure of is if the download managers would be intelligent enough to hit the URL that they're redirected to 20-30 times, or if they hit us 20-30 times. I guess it probably depends on which download manager is in use From Axel.Thimm at ATrpms.net Tue Apr 28 13:52:20 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 28 Apr 2009 16:52:20 +0300 Subject: Statistics problem In-Reply-To: <20090428125750.GE13551@localhost.localdomain> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> Message-ID: <20090428135220.GA19050@victor.nirvana> On Tue, Apr 28, 2009 at 08:57:50AM -0400, Paul W. Frields wrote: > On Tue, Apr 28, 2009 at 08:44:15AM -0400, Jon Stanley wrote: > > On Tue, Apr 28, 2009 at 8:29 AM, Paul W. Frields wrote: > > > > > uniq-ing the IP addresses doing the downloading. ?That method has the > > > potential to cut out legitimate, repetitive downloads from inside a > > > firewall. ?I'd feel better cutting those ticks out if they were > > > > I'm not sure if you can see this in our logs or not (you might have to > > have the individual mirrors logs :( ), but if the response code is a > > 206, that means it was a RANGE request - to download part of a file. > > It's not at all uncommon for a download manager to open 20-30 > > connections to download the same file for the same user., > > > > So I'd opt for the conservative approach of uniques as well. > > To clarify, I'm already filtering these out on a 302 code. How would > that change your opinion, if at all? Isn't 302 a (temp) relocation? Why would filtering out 302 also filter out 206? Maybe the cleanest solution is to count downloaded bytes and divide by image size. That way you properly count ranged downloads. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Tue Apr 28 14:19:17 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 09:19:17 -0500 (CDT) Subject: Bit flip Message-ID: We need to do the bit flip sooner. The announcement is out, I've sent over 600 requests and not a single one has come back a success. I know work is being done to change this whole mechanism now, but we still should be flipping the bit sooner. -Mike From skvidal at fedoraproject.org Tue Apr 28 14:33:43 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 28 Apr 2009 10:33:43 -0400 (EDT) Subject: Bit flip In-Reply-To: References: Message-ID: On Tue, 28 Apr 2009, Mike McGrath wrote: > We need to do the bit flip sooner. The announcement is out, I've sent > over 600 requests and not a single one has come back a success. I know > work is being done to change this whole mechanism now, but we still should > be flipping the bit sooner. > I flipped the bits at: 8:30am EDT. That was a bit earlier than before. -sv From mmcgrath at redhat.com Tue Apr 28 14:51:31 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 09:51:31 -0500 (CDT) Subject: Bit flip In-Reply-To: References: Message-ID: On Tue, 28 Apr 2009, Seth Vidal wrote: > > > On Tue, 28 Apr 2009, Mike McGrath wrote: > > > We need to do the bit flip sooner. The announcement is out, I've sent > > over 600 requests and not a single one has come back a success. I know > > work is being done to change this whole mechanism now, but we still should > > be flipping the bit sooner. > > > > I flipped the bits at: 8:30am EDT. That was a bit earlier than before. > I'm thinking more like hours. From the last release I monitored: http://mmcgrath.fedorapeople.org/alphaMirrorRediness.html We didn't hit 80% success rate until 3 and a half hours after the launch. I think mdomsch made some good changes since this graph that will make the outcome better, but I still think that initial launch isn't right. Perhaps we should wait to send the announcement out until a certain % of mirrors are ready? We currently don't check that prior to announce. -Mike From skvidal at fedoraproject.org Tue Apr 28 14:53:23 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 28 Apr 2009 10:53:23 -0400 (EDT) Subject: Bit flip In-Reply-To: References: Message-ID: On Tue, 28 Apr 2009, Mike McGrath wrote: > > I'm thinking more like hours. From the last release I monitored: > > http://mmcgrath.fedorapeople.org/alphaMirrorRediness.html > > We didn't hit 80% success rate until 3 and a half hours after the launch. > I think mdomsch made some good changes since this graph that will make the > outcome better, but I still think that initial launch isn't right. > > Perhaps we should wait to send the announcement out until a certain % of > mirrors are ready? We currently don't check that prior to announce. > I went by Jesse's wording of "make sure at least a few mirrors are synced" and you said on irc that 3 mirrors in the US were synced. That's why I sent out the announcement then. That may be where the mixup was. -sv From mmcgrath at redhat.com Tue Apr 28 15:18:47 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 10:18:47 -0500 (CDT) Subject: Bit flip In-Reply-To: References: Message-ID: On Tue, 28 Apr 2009, Seth Vidal wrote: > > > On Tue, 28 Apr 2009, Mike McGrath wrote: > > > > > I'm thinking more like hours. From the last release I monitored: > > > > http://mmcgrath.fedorapeople.org/alphaMirrorRediness.html > > > > We didn't hit 80% success rate until 3 and a half hours after the launch. > > I think mdomsch made some good changes since this graph that will make the > > outcome better, but I still think that initial launch isn't right. > > > > Perhaps we should wait to send the announcement out until a certain % of > > mirrors are ready? We currently don't check that prior to announce. > > > > I went by Jesse's wording of "make sure at least a few mirrors are synced" and > you said on irc that 3 mirrors in the US were synced. > > That's why I sent out the announcement then. > > That may be where the mixup was. > Synced but if you clicked on those mirrors they threw a forbidden message. -Mike From stickster at gmail.com Tue Apr 28 15:17:55 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 28 Apr 2009 11:17:55 -0400 Subject: Statistics problem In-Reply-To: <20090428135220.GA19050@victor.nirvana> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> Message-ID: <20090428151755.GC3350@localhost.localdomain> On Tue, Apr 28, 2009 at 04:52:20PM +0300, Axel Thimm wrote: > On Tue, Apr 28, 2009 at 08:57:50AM -0400, Paul W. Frields wrote: > > On Tue, Apr 28, 2009 at 08:44:15AM -0400, Jon Stanley wrote: > > > On Tue, Apr 28, 2009 at 8:29 AM, Paul W. Frields wrote: > > > > > > > uniq-ing the IP addresses doing the downloading. ?That method has the > > > > potential to cut out legitimate, repetitive downloads from inside a > > > > firewall. ?I'd feel better cutting those ticks out if they were > > > > > > I'm not sure if you can see this in our logs or not (you might have to > > > have the individual mirrors logs :( ), but if the response code is a > > > 206, that means it was a RANGE request - to download part of a file. > > > It's not at all uncommon for a download manager to open 20-30 > > > connections to download the same file for the same user., > > > > > > So I'd opt for the conservative approach of uniques as well. > > > > To clarify, I'm already filtering these out on a 302 code. How would > > that change your opinion, if at all? > > Isn't 302 a (temp) relocation? Why would filtering out 302 also filter > out 206? I misused a pronoun -- I am specifically *grepping for 302*, which I did not state clearly. Did anyone look at the commands page I linked earlier? https://fedoraproject.org/wiki/Statistics/Commands > Maybe the cleanest solution is to count downloaded bytes and divide by > image size. That way you properly count ranged downloads. Command suggestions are very welcome. I really don't have time to delve into this incredibly deeply at the moment. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 Tue Apr 28 15:34:51 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 28 Apr 2009 10:34:51 -0500 Subject: Bit flip In-Reply-To: References: Message-ID: <20090428153451.GA15619@auslistsprd01.us.dell.com> On Tue, Apr 28, 2009 at 10:18:47AM -0500, Mike McGrath wrote: > On Tue, 28 Apr 2009, Seth Vidal wrote: > > > > > > > On Tue, 28 Apr 2009, Mike McGrath wrote: > > > > > > > > I'm thinking more like hours. From the last release I monitored: > > > > > > http://mmcgrath.fedorapeople.org/alphaMirrorRediness.html > > > > > > We didn't hit 80% success rate until 3 and a half hours after the launch. > > > I think mdomsch made some good changes since this graph that will make the > > > outcome better, but I still think that initial launch isn't right. > > > > > > Perhaps we should wait to send the announcement out until a certain % of > > > mirrors are ready? We currently don't check that prior to announce. > > > > > > > I went by Jesse's wording of "make sure at least a few mirrors are synced" and > > you said on irc that 3 mirrors in the US were synced. > > > > That's why I sent out the announcement then. > > > > That may be where the mixup was. > > > > Synced but if you clicked on those mirrors they threw a forbidden message. Backwards math: Time to generate and publish updated mirrorlist: 20 minutes Time to crawl all mirrors: ~2 hours Time for most mirrors to rsync and catch the bitflip: 6 hours Time to sync bitflip to all three netapps: < 30 minutes (maybe <<). Time to do bitflip: 1 minute So Mike is correct, that if we bitflip 2.5+ hours ahead of 1400 UTC, that by 1400 UTC we'll know which mirrors have actually picked up the bitflip and are live. If we bitflip a lot earlier, say 6.5 hours ahead, we can have nearly all the mirrors with the right permissions, and showing right on the mirrorlist. MM is also "bad" in that it doesn't know the directory permissions on every directory that a report_mirror-using mirror has. So we're showing mirrors in the publiclist, and returning them to clients on with mirrorlist/d.fp.o when we don't know that their permissions are correct. Adding that knowledge to report_mirror and MM would prevent us from returning pre-bitflip mirrors to clients. That's a good bit of work I haven't scoped. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Tue Apr 28 18:03:39 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 13:03:39 -0500 (CDT) Subject: Preview release is out! Message-ID: Get to installing. Get to testing. Get to filling out this matrix: https://fedoraproject.org/wiki/QA:Fedora_11_Preview_Install_Test_Results -Mike From Matt_Domsch at dell.com Tue Apr 28 18:16:48 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 28 Apr 2009 13:16:48 -0500 Subject: Bit flip In-Reply-To: <20090428153451.GA15619@auslistsprd01.us.dell.com> References: <20090428153451.GA15619@auslistsprd01.us.dell.com> Message-ID: <20090428181648.GA8096@auslistsprd01.us.dell.com> On Tue, Apr 28, 2009 at 10:34:51AM -0500, Matt Domsch wrote: > Backwards math: > > Time to generate and publish updated mirrorlist: 20 minutes > Time to crawl all mirrors: ~2 hours > Time for most mirrors to rsync and catch the bitflip: 6 hours Insert step: Time for update-master-directory-list to catch the bitflip: 30 minutes > Time to sync bitflip to all three netapps: < 30 minutes (maybe <<). > Time to do bitflip: 1 minute Shortest time through the path is: 1+30+30+120+20, or nearly 3.5 hours, which lines up well with Mike's observation that 3.5 hours was needed before we stopped sending people to closed mirrors. So, I'd like to propose we back up the bitflip by at least 4 hours from release time, perhaps as much as 6. I'd also like to move the update-mirrorlist cronjob back to start at :40 past the hour, so content is in place by :00. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From smooge at gmail.com Tue Apr 28 18:34:47 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 28 Apr 2009 12:34:47 -0600 Subject: sphinx as search solution? In-Reply-To: <53a863600904280636j6bec0460s7a53e4bcf51341e5@mail.gmail.com> References: <20090428013139.GC22251@kupenblagster.ianweller.org> <53a863600904280636j6bec0460s7a53e4bcf51341e5@mail.gmail.com> Message-ID: <80d7e4090904281134i4cb277c3w670b77d7e04effd5@mail.gmail.com> On Tue, Apr 28, 2009 at 7:36 AM, jose manimala wrote: > Hey Ian, > ??????????? I had a crack at it on the pt10 machine... but its? a little bit > on the heavier side uses a lot of resources... I have been running some > tests with HT:dig and lucene... Ht dig hung up the test machine while > indexing... :) > > Jose > What tools have we investigated in the past? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Tue Apr 28 18:39:47 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 13:39:47 -0500 (CDT) Subject: Half hour downtime Message-ID: I'd like to schedule a half hour of downtime for our netapp in PHX. This should only impact some nfs related stuff (primary mirror and things like images on the wiki). I'd like to do this before the final freeze, RH's storage team will actually be performing the work, I just want to find a time that will work for everyone. Does sometime next week work? -Mike From Matt_Domsch at dell.com Tue Apr 28 18:42:53 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 28 Apr 2009 13:42:53 -0500 Subject: changes post-freeze Message-ID: <20090428184253.GB8096@auslistsprd01.us.dell.com> A few things I'd like to change starting tomorrow (post-freeze). * change the MM update-master-directory-list cronjob to start at 0 and 30 past the hour, from its current schedule of trying to start every 15 minutes. It is taking about 20 minutes on average to run, so really is only running twice an hour anyhow. * bump back the MM update-mirrorlist cronjob to start at :40 past the hour. It takes about 20 minutes to complete, and I would like the new content to land at the top of the hour. * in modules/rsync/files/rsyncd.conf.secondary1, exclude alt/stage. Mirrors shouldn't be able to sync this content. * in MM prod.cfg, exclude pub/alt/stage. Mirrors shouldn't have this content, and it's extra directory walks we don't need. * increase the number of crawlers, from 45 to 75. A full run is taking about 3 hours now, I'd like to bring this down to under 2. This only affects bapp1, whose load average is still under 1 and has plenty of free RAM and CPU it seems. Objections or comments? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From smooge at gmail.com Tue Apr 28 18:45:26 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 28 Apr 2009 12:45:26 -0600 Subject: Half hour downtime In-Reply-To: References: Message-ID: <80d7e4090904281145w387de618nf4f755e6436a21f6@mail.gmail.com> On Tue, Apr 28, 2009 at 12:39 PM, Mike McGrath wrote: > I'd like to schedule a half hour of downtime for our netapp in PHX. ?This > should only impact some nfs related stuff (primary mirror and things like > images on the wiki). > > I'd like to do this before the final freeze, RH's storage team will > actually be performing the work, I just want to find a time that will work > for everyone. ?Does sometime next week work? > Are there any more RC's etc coming out? I would expect that 1 week would allow for high seeding of mirrors so it should impact too much. Is the half-hour max or estimated down time? What kind of Netapp do they use these days? (European or African)? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Tue Apr 28 18:51:18 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 28 Apr 2009 12:51:18 -0600 Subject: changes post-freeze In-Reply-To: <20090428184253.GB8096@auslistsprd01.us.dell.com> References: <20090428184253.GB8096@auslistsprd01.us.dell.com> Message-ID: <80d7e4090904281151s38785227x6c278d1b5c24f0a5@mail.gmail.com> On Tue, Apr 28, 2009 at 12:42 PM, Matt Domsch wrote: > A few things I'd like to change starting tomorrow (post-freeze). > > * change the MM update-master-directory-list cronjob to start at 0 and > ?30 past the hour, from its current schedule of trying to start every > ?15 minutes. ?It is taking about 20 minutes on average to run, so > ?really is only running twice an hour anyhow. > > * bump back the MM update-mirrorlist cronjob to start at :40 past the > ?hour. ?It takes about 20 minutes to complete, and I would like the > ?new content to land at the top of the hour. Is the 20 minutes a maximum or average? I was just wondering if somewhere between 35 and 40 would make sure it doesn't conflict with a job at the top of the hour? > * in modules/rsync/files/rsyncd.conf.secondary1, exclude alt/stage. > ?Mirrors shouldn't be able to sync this content. > > * in MM prod.cfg, exclude pub/alt/stage. ?Mirrors shouldn't have > ?this content, and it's extra directory walks we don't need. > > * increase the number of crawlers, from 45 to 75. ?A full run is > ?taking about 3 hours now, I'd like to bring this down to under 2. > ?This only affects bapp1, whose load average is still under 1 and has > ?plenty of free RAM and CPU it seems. sorry for clueless question number 2. What is the limiting factors for the crawlers? Network bandwidth/latency or CPU? > Objections or comments? > > Thanks, > Matt > > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From Matt_Domsch at dell.com Tue Apr 28 19:24:34 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 28 Apr 2009 14:24:34 -0500 Subject: changes post-freeze In-Reply-To: <80d7e4090904281151s38785227x6c278d1b5c24f0a5@mail.gmail.com> References: <20090428184253.GB8096@auslistsprd01.us.dell.com> <80d7e4090904281151s38785227x6c278d1b5c24f0a5@mail.gmail.com> Message-ID: <20090428192434.GC8096@auslistsprd01.us.dell.com> On Tue, Apr 28, 2009 at 12:51:18PM -0600, Stephen John Smoogen wrote: > On Tue, Apr 28, 2009 at 12:42 PM, Matt Domsch wrote: > > A few things I'd like to change starting tomorrow (post-freeze). > > > > * change the MM update-master-directory-list cronjob to start at 0 and > > ?30 past the hour, from its current schedule of trying to start every > > ?15 minutes. ?It is taking about 20 minutes on average to run, so > > ?really is only running twice an hour anyhow. > > > > * bump back the MM update-mirrorlist cronjob to start at :40 past the > > ?hour. ?It takes about 20 minutes to complete, and I would like the > > ?new content to land at the top of the hour. > > Is the 20 minutes a maximum or average? I was just wondering if > somewhere between 35 and 40 would make sure it doesn't conflict with a > job at the top of the hour? pretty much maximum, though to be fair, I am not recording the start and stop times for these events in their respective logfiles to know for sure. > > * increase the number of crawlers, from 45 to 75. ?A full run is > > ?taking about 3 hours now, I'd like to bring this down to under 2. > > ?This only affects bapp1, whose load average is still under 1 and has > > ?plenty of free RAM and CPU it seems. > > sorry for clueless question number 2. What is the limiting factors for > the crawlers? Network bandwidth/latency or CPU? More latency than bandwidth. The crawlers issue HTTP HEAD requests for a lot of files on each mirror to be sure they match. The latency in response to these requests (single-threaded to each mirror, but hitting 45 (or soon more) mirrors in parallel) is what limits the speed of an individual crawler. Then the time for the whole run is simply the time it takes to complete each of the crawlers. Very little CPU is used, except at the end of each crawler, when it updates the database with its findings. Then it jumps up in CPU for a few seconds. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Tue Apr 28 19:59:37 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 14:59:37 -0500 (CDT) Subject: sphinx as search solution? In-Reply-To: <80d7e4090904281134i4cb277c3w670b77d7e04effd5@mail.gmail.com> References: <20090428013139.GC22251@kupenblagster.ianweller.org> <53a863600904280636j6bec0460s7a53e4bcf51341e5@mail.gmail.com> <80d7e4090904281134i4cb277c3w670b77d7e04effd5@mail.gmail.com> Message-ID: On Tue, 28 Apr 2009, Stephen John Smoogen wrote: > On Tue, Apr 28, 2009 at 7:36 AM, jose manimala wrote: > > Hey Ian, > > ??????????? I had a crack at it on the pt10 machine... but its? a little bit > > on the heavier side uses a lot of resources... I have been running some > > tests with HT:dig and lucene... Ht dig hung up the test machine while > > indexing... :) > > > > Jose > > > > What tools have we investigated in the past? > I've personally used htdig in the past, we've had some proof of concepts setup but no real report on performance, IO/memory usage, cpu, etc. Seems like we start over a lot on this one. daMaestro has one working but I'm not sure what all he thinks of it. -Mike From Matt_Domsch at dell.com Tue Apr 28 20:00:34 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 28 Apr 2009 15:00:34 -0500 Subject: Half hour downtime In-Reply-To: References: Message-ID: <20090428200034.GA21873@auslistsprd01.us.dell.com> On Tue, Apr 28, 2009 at 01:39:47PM -0500, Mike McGrath wrote: > I'd like to schedule a half hour of downtime for our netapp in PHX. This > should only impact some nfs related stuff (primary mirror and things like > images on the wiki). > > I'd like to do this before the final freeze, RH's storage team will > actually be performing the work, I just want to find a time that will work > for everyone. Does sometime next week work? fine from mirrors perspective. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Tue Apr 28 20:01:31 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 15:01:31 -0500 (CDT) Subject: Half hour downtime In-Reply-To: <80d7e4090904281145w387de618nf4f755e6436a21f6@mail.gmail.com> References: <80d7e4090904281145w387de618nf4f755e6436a21f6@mail.gmail.com> Message-ID: On Tue, 28 Apr 2009, Stephen John Smoogen wrote: > On Tue, Apr 28, 2009 at 12:39 PM, Mike McGrath wrote: > > I'd like to schedule a half hour of downtime for our netapp in PHX. ?This > > should only impact some nfs related stuff (primary mirror and things like > > images on the wiki). > > > > I'd like to do this before the final freeze, RH's storage team will > > actually be performing the work, I just want to find a time that will work > > for everyone. ?Does sometime next week work? > > > > Are there any more RC's etc coming out? I would expect that 1 week > would allow for high seeding of mirrors so it should impact too much. > I'm hoping Jesse can comment on this one, AFAIK it wouldn't fall in our normal freeze window though which will end tomorrow and start again on May 12th. > Is the half-hour max or estimated down time? > 15 minutes was the estimate from the storage team. My understanding is this is a firmware upgrade so our new storage trays will work. The trays themselves can be installed live. > What kind of Netapp do they use these days? (European or African)? > I can never remember :-/ I'll ask. -Mike From stickster at gmail.com Tue Apr 28 21:50:22 2009 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 28 Apr 2009 17:50:22 -0400 Subject: Bit flip In-Reply-To: References: Message-ID: <20090428215022.GC16500@localhost.localdomain> On Tue, Apr 28, 2009 at 10:53:23AM -0400, Seth Vidal wrote: > > > On Tue, 28 Apr 2009, Mike McGrath wrote: > >> >> I'm thinking more like hours. From the last release I monitored: >> >> http://mmcgrath.fedorapeople.org/alphaMirrorRediness.html >> >> We didn't hit 80% success rate until 3 and a half hours after the launch. >> I think mdomsch made some good changes since this graph that will make the >> outcome better, but I still think that initial launch isn't right. >> >> Perhaps we should wait to send the announcement out until a certain % of >> mirrors are ready? We currently don't check that prior to announce. >> > > I went by Jesse's wording of "make sure at least a few mirrors are synced" > and you said on irc that 3 mirrors in the US were synced. > > That's why I sent out the announcement then. > > That may be where the mixup was. It didn't help that I had to stick my big fat nose in and "help" by approving the message in the moderation queue. Sorry I contributed to the angst. :-( -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 redhat.com Tue Apr 28 21:57:33 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 16:57:33 -0500 (CDT) Subject: Any C coders want to help me with something? Message-ID: Any C coders want to help me with a pam module? -Mike From ricky at fedoraproject.org Tue Apr 28 22:00:15 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 28 Apr 2009 18:00:15 -0400 Subject: Any C coders want to help me with something? In-Reply-To: References: Message-ID: <20090428220015.GA20418@sphe.res.cmu.edu> On 2009-04-28 04:57:33 PM, Mike McGrath wrote: > Any C coders want to help me with a pam module? I've been doing some C in school, so if there's no big rush, I wouldn't mind getting some practice :-) Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From smooge at gmail.com Tue Apr 28 22:33:31 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 28 Apr 2009 16:33:31 -0600 Subject: Any C coders want to help me with something? In-Reply-To: References: Message-ID: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath wrote: > Any C coders want to help me with a pam module? > I am not a great C coder but I have done some pam stuff. what is the issue? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Tue Apr 28 23:38:47 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Apr 2009 18:38:47 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> Message-ID: On Tue, 28 Apr 2009, Stephen John Smoogen wrote: > On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath wrote: > > Any C coders want to help me with a pam module? > > > > I am not a great C coder but I have done some pam stuff. what is the issue? > I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc. -Mike From sascha at spreitzer.name Wed Apr 29 10:19:34 2009 From: sascha at spreitzer.name (Sascha Thomas Spreitzer) Date: Wed, 29 Apr 2009 12:19:34 +0200 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> Message-ID: Hello Mike, are you speaking about a Linux PAM module, or CGI? regards, Sascha 2009/4/29 Mike McGrath : > On Tue, 28 Apr 2009, Stephen John Smoogen wrote: > >> On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath wrote: >> > Any C coders want to help me with a pam module? >> > >> >> I am not a great C coder but I have done some pam stuff. what is the issue? >> > > I'd like someone to write a pam module to auth against fas. ?I'm not sure > it's the way to go but I'd like to have something up and running to test > with to see how it behaves, how it deals with some failure scenarios, etc. > > ? ? ? ?-Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Mit freundlichen Gr??en, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/ From sascha at spreitzer.name Wed Apr 29 10:26:48 2009 From: sascha at spreitzer.name (Sascha Thomas Spreitzer) Date: Wed, 29 Apr 2009 12:26:48 +0200 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> Message-ID: Hello again, >> I'd like someone to write a pam module to auth against fas. sry, havent read this. regards, Sascha 2009/4/29 Sascha Thomas Spreitzer : > Hello Mike, > > are you speaking about a Linux PAM module, or CGI? > > regards, > Sascha > > 2009/4/29 Mike McGrath : >> On Tue, 28 Apr 2009, Stephen John Smoogen wrote: >> >>> On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath wrote: >>> > Any C coders want to help me with a pam module? >>> > >>> >>> I am not a great C coder but I have done some pam stuff. what is the issue? >>> >> >> I'd like someone to write a pam module to auth against fas. ?I'm not sure >> it's the way to go but I'd like to have something up and running to test >> with to see how it behaves, how it deals with some failure scenarios, etc. >> >> ? ? ? ?-Mike >> >> _______________________________________________ >> Fedora-infrastructure-list mailing list >> Fedora-infrastructure-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list >> > > > > -- > Mit freundlichen Gr??en, / with kind regards, > Sascha Thomas Spreitzer > http://spreitzer.name/ > -- Mit freundlichen Gr??en, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/ From neo.reeves at gmail.com Wed Apr 29 11:29:58 2009 From: neo.reeves at gmail.com (Neo Reeves) Date: Wed, 29 Apr 2009 16:29:58 +0500 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> Message-ID: Hi, I'm not a hardcore C programmer, but have basic knowledge in C and C++. Can you share some technical details so that we have a better understanding of what needs to be done? Kinda new on this kind of programming, but I'd love to give it a try. Thnx, Sameeh On Wed, Apr 29, 2009 at 3:26 PM, Sascha Thomas Spreitzer < sascha at spreitzer.name> wrote: > Hello again, > > >> I'd like someone to write a pam module to auth against fas. > sry, havent read this. > > regards, > Sascha > > 2009/4/29 Sascha Thomas Spreitzer : > > Hello Mike, > > > > are you speaking about a Linux PAM module, or CGI? > > > > regards, > > Sascha > > > > 2009/4/29 Mike McGrath : > >> On Tue, 28 Apr 2009, Stephen John Smoogen wrote: > >> > >>> On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath > wrote: > >>> > Any C coders want to help me with a pam module? > >>> > > >>> > >>> I am not a great C coder but I have done some pam stuff. what is the > issue? > >>> > >> > >> I'd like someone to write a pam module to auth against fas. I'm not > sure > >> it's the way to go but I'd like to have something up and running to test > >> with to see how it behaves, how it deals with some failure scenarios, > etc. > >> > >> -Mike > >> > >> _______________________________________________ > >> Fedora-infrastructure-list mailing list > >> Fedora-infrastructure-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > >> > > > > > > > > -- > > Mit freundlichen Gr??en, / with kind regards, > > Sascha Thomas Spreitzer > > http://spreitzer.name/ > > > > > > -- > Mit freundlichen Gr??en, / with kind regards, > Sascha Thomas Spreitzer > http://spreitzer.name/ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- --- Neo -------------- next part -------------- An HTML attachment was scrubbed... URL: From sts at ono.at Wed Apr 29 11:54:23 2009 From: sts at ono.at (Stefan Schlesinger) Date: Wed, 29 Apr 2009 13:54:23 +0200 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> Message-ID: On Apr 29, 2009, at 01:38 , Mike McGrath wrote: > I'd like someone to write a pam module to auth against fas. I'm not > sure > it's the way to go but I'd like to have something up and running to > test > with to see how it behaves, how it deals with some failure > scenarios, etc. I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it. Regards, Stefan. Stefan Schlesinger \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\ sts at ono.at SS8335-RIPE From Axel.Thimm at ATrpms.net Wed Apr 29 12:20:54 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 29 Apr 2009 15:20:54 +0300 Subject: Statistics problem In-Reply-To: <20090428151755.GC3350@localhost.localdomain> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> Message-ID: <20090429122054.GB26655@victor.nirvana> On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: > > Maybe the cleanest solution is to count downloaded bytes and divide by > > image size. That way you properly count ranged downloads. > > Command suggestions are very welcome. I really don't have time to > delve into this incredibly deeply at the moment. Could you post a small fragment of the raw logs? But it seems like all we see are the primary redirects, possibly w/o noting ranges in the logs. E.g. for better statistics the logs would need to capture the ranges from the head as well. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From abu_hurayrah at hidayahonline.org Wed Apr 29 13:09:27 2009 From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar) Date: Wed, 29 Apr 2009 21:09:27 +0800 Subject: Statistics problem In-Reply-To: <20090429122054.GB26655@victor.nirvana> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> Message-ID: <49F85187.6070005@hidayahonline.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2009 08:20 PM, Axel Thimm wrote: > On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: >>> Maybe the cleanest solution is to count downloaded bytes and divide by >>> image size. That way you properly count ranged downloads. >> Command suggestions are very welcome. I really don't have time to >> delve into this incredibly deeply at the moment. > > Could you post a small fragment of the raw logs? But it seems like all > we see are the primary redirects, possibly w/o noting ranges in the > logs. E.g. for better statistics the logs would need to capture the > ranges from the head as well. > I think that information is not available, because no one (almost) downloads directly from the Fedora servers, only from the mirrors. Therefore, the real data, like range requests, etc., would only be on the mirror servers themselves, and not on the primary ones. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkn4UYEACgkQaVgOCFr0s2J5yQCglj6GYoxRc/6KFIf/fAGlmuYB 78MAn3Jtu9fqPONN1BwOmsA4axLKiwPY =ra+Y -----END PGP SIGNATURE----- From mmcgrath at redhat.com Wed Apr 29 14:27:23 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 09:27:23 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> Message-ID: On Wed, 29 Apr 2009, Stefan Schlesinger wrote: > On Apr 29, 2009, at 01:38 , Mike McGrath wrote: > > I'd like someone to write a pam module to auth against fas. I'm not sure > > it's the way to go but I'd like to have something up and running to test > > with to see how it behaves, how it deals with some failure scenarios, etc. > > I'm not sure what exactly you want to do, but pam_ldap should do what > you want, right? Or at least one could use it as codebase and modify it. > pam_ldap would probably be close to what we want and certainly a good place to look but we don't run an ldap server so it won't auth against fas. -Mike From smooge at gmail.com Wed Apr 29 16:29:24 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 29 Apr 2009 10:29:24 -0600 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> Message-ID: <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath wrote: > On Wed, 29 Apr 2009, Stefan Schlesinger wrote: > >> On Apr 29, 2009, at 01:38 , Mike McGrath wrote: >> > I'd like someone to write a pam module to auth against fas. ?I'm not sure >> > it's the way to go but I'd like to have something up and running to test >> > with to see how it behaves, how it deals with some failure scenarios, etc. >> >> I'm not sure what exactly you want to do, but pam_ldap should do what >> you want, right? Or at least one could use it as codebase and modify it. >> > > pam_ldap would probably be close to what we want and certainly a good > place to look but we don't run an ldap server so it won't auth against > fas. > Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it. The one problem with custom pam modules is usually the 'oooooooh' moment when something doesn't work quite as planned (hey look I can sudo root as apache? how did that happen?) -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Wed Apr 29 16:52:45 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 11:52:45 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> Message-ID: On Wed, 29 Apr 2009, Stephen John Smoogen wrote: > On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath wrote: > > On Wed, 29 Apr 2009, Stefan Schlesinger wrote: > > > >> On Apr 29, 2009, at 01:38 , Mike McGrath wrote: > >> > I'd like someone to write a pam module to auth against fas. ?I'm not sure > >> > it's the way to go but I'd like to have something up and running to test > >> > with to see how it behaves, how it deals with some failure scenarios, etc. > >> > >> I'm not sure what exactly you want to do, but pam_ldap should do what > >> you want, right? Or at least one could use it as codebase and modify it. > >> > > > > pam_ldap would probably be close to what we want and certainly a good > > place to look but we don't run an ldap server so it won't auth against > > fas. > > > > Well normally what I have seen is that the 'FAS' server would export a > schema table to LDAP and LDAP would then be what is authenticated to > (the same with Kerberos if combined). Or the FAS server has a > mysql/postgres background and someone uses pam/mod mysql to do it. > > The one problem with custom pam modules is usually the 'oooooooh' > moment when something doesn't work quite as planned (hey look I can > sudo root as apache? how did that happen?) > This is a legit and good concern. Ricky and I were talking about it last night. Since we're re-thinking things I'm open to suggestions. Might be something as simple as getting an ldap server to communicate with a postgres backend? -Mike From mmcgrath at redhat.com Wed Apr 29 16:59:30 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 11:59:30 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> Message-ID: On Wed, 29 Apr 2009, Mike McGrath wrote: > On Wed, 29 Apr 2009, Stephen John Smoogen wrote: > > > On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath wrote: > > > On Wed, 29 Apr 2009, Stefan Schlesinger wrote: > > > > > >> On Apr 29, 2009, at 01:38 , Mike McGrath wrote: > > >> > I'd like someone to write a pam module to auth against fas. ?I'm not sure > > >> > it's the way to go but I'd like to have something up and running to test > > >> > with to see how it behaves, how it deals with some failure scenarios, etc. > > >> > > >> I'm not sure what exactly you want to do, but pam_ldap should do what > > >> you want, right? Or at least one could use it as codebase and modify it. > > >> > > > > > > pam_ldap would probably be close to what we want and certainly a good > > > place to look but we don't run an ldap server so it won't auth against > > > fas. > > > > > > > Well normally what I have seen is that the 'FAS' server would export a > > schema table to LDAP and LDAP would then be what is authenticated to > > (the same with Kerberos if combined). Or the FAS server has a > > mysql/postgres background and someone uses pam/mod mysql to do it. > > > > The one problem with custom pam modules is usually the 'oooooooh' > > moment when something doesn't work quite as planned (hey look I can > > sudo root as apache? how did that happen?) > > > > This is a legit and good concern. Ricky and I were talking about it last > night. Since we're re-thinking things I'm open to suggestions. Might be > something as simple as getting an ldap server to communicate with a > postgres backend? > :: cough cough :: something like http://www.darold.net/projects/ldap_pg/HOWTO/ -Mike From abu_hurayrah at hidayahonline.org Wed Apr 29 17:14:34 2009 From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar) Date: Thu, 30 Apr 2009 01:14:34 +0800 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> Message-ID: <49F88AFA.1080406@hidayahonline.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/30/2009 12:52 AM, Mike McGrath wrote: > On Wed, 29 Apr 2009, Stephen John Smoogen wrote: > >> On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath wrote: >>> On Wed, 29 Apr 2009, Stefan Schlesinger wrote: >>> >>>> On Apr 29, 2009, at 01:38 , Mike McGrath wrote: >>>>> I'd like someone to write a pam module to auth against fas. I'm not sure >>>>> it's the way to go but I'd like to have something up and running to test >>>>> with to see how it behaves, how it deals with some failure scenarios, etc. >>>> I'm not sure what exactly you want to do, but pam_ldap should do what >>>> you want, right? Or at least one could use it as codebase and modify it. >>>> >>> pam_ldap would probably be close to what we want and certainly a good >>> place to look but we don't run an ldap server so it won't auth against >>> fas. >>> >> Well normally what I have seen is that the 'FAS' server would export a >> schema table to LDAP and LDAP would then be what is authenticated to >> (the same with Kerberos if combined). Or the FAS server has a >> mysql/postgres background and someone uses pam/mod mysql to do it. >> >> The one problem with custom pam modules is usually the 'oooooooh' >> moment when something doesn't work quite as planned (hey look I can >> sudo root as apache? how did that happen?) >> > > This is a legit and good concern. Ricky and I were talking about it last > night. Since we're re-thinking things I'm open to suggestions. Might be > something as simple as getting an ldap server to communicate with a > postgres backend? > > -Mike Sorry for butting in like this, but I always assumed FAS would use LDAP as a backend, so that 3rd parties, if they wanted to plug in to the system, would utilize LDAP. Is that not the case? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkn4ivUACgkQaVgOCFr0s2KkpgCdFx3iwUM8IbWPjVEufFRDnM5d b6EAnAsXyj03UIMbMy0wGDi9+n/ZC8eT =oyjc -----END PGP SIGNATURE----- From mmcgrath at redhat.com Wed Apr 29 18:03:03 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 13:03:03 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <49F88AFA.1080406@hidayahonline.org> References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> Message-ID: On Thu, 30 Apr 2009, Basil Mohamed Gohar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/30/2009 12:52 AM, Mike McGrath wrote: > > On Wed, 29 Apr 2009, Stephen John Smoogen wrote: > > > >> On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath wrote: > >>> On Wed, 29 Apr 2009, Stefan Schlesinger wrote: > >>> > >>>> On Apr 29, 2009, at 01:38 , Mike McGrath wrote: > >>>>> I'd like someone to write a pam module to auth against fas. I'm not sure > >>>>> it's the way to go but I'd like to have something up and running to test > >>>>> with to see how it behaves, how it deals with some failure scenarios, etc. > >>>> I'm not sure what exactly you want to do, but pam_ldap should do what > >>>> you want, right? Or at least one could use it as codebase and modify it. > >>>> > >>> pam_ldap would probably be close to what we want and certainly a good > >>> place to look but we don't run an ldap server so it won't auth against > >>> fas. > >>> > >> Well normally what I have seen is that the 'FAS' server would export a > >> schema table to LDAP and LDAP would then be what is authenticated to > >> (the same with Kerberos if combined). Or the FAS server has a > >> mysql/postgres background and someone uses pam/mod mysql to do it. > >> > >> The one problem with custom pam modules is usually the 'oooooooh' > >> moment when something doesn't work quite as planned (hey look I can > >> sudo root as apache? how did that happen?) > >> > > > > This is a legit and good concern. Ricky and I were talking about it last > > night. Since we're re-thinking things I'm open to suggestions. Might be > > something as simple as getting an ldap server to communicate with a > > postgres backend? > > > > -Mike > Sorry for butting in like this, but I always assumed FAS would use LDAP > as a backend, so that 3rd parties, if they wanted to plug in to the > system, would utilize LDAP. Is that not the case? > Correct, that's not the case. Instead of LDAP we have a postgres backend and use json to auth, third parties use python-fedora to authenticate. We tried pretty hard to get LDAP working with our account system but ran into many problems and decided to go back to postgres. -Mike From Axel.Thimm at ATrpms.net Wed Apr 29 18:40:40 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 29 Apr 2009 21:40:40 +0300 Subject: Statistics problem In-Reply-To: <49F85187.6070005@hidayahonline.org> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> <49F85187.6070005@hidayahonline.org> Message-ID: <20090429184040.GA31876@victor.nirvana> On Wed, Apr 29, 2009 at 09:09:27PM +0800, Basil Mohamed Gohar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/29/2009 08:20 PM, Axel Thimm wrote: > > On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: > >>> Maybe the cleanest solution is to count downloaded bytes and divide by > >>> image size. That way you properly count ranged downloads. > >> Command suggestions are very welcome. I really don't have time to > >> delve into this incredibly deeply at the moment. > > > > Could you post a small fragment of the raw logs? But it seems like all > > we see are the primary redirects, possibly w/o noting ranges in the > > logs. E.g. for better statistics the logs would need to capture the > > ranges from the head as well. > > > > I think that information is not available, because no one (almost) > downloads directly from the Fedora servers, only from the mirrors. > Therefore, the real data, like range requests, etc., would only be on > the mirror servers themselves, and not on the primary ones. Isn't a range request sent in the header of the HTTP request which would hit the Fedora servers before being redirected? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Apr 29 18:47:21 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 29 Apr 2009 21:47:21 +0300 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> Message-ID: <20090429184721.GB31876@victor.nirvana> On Wed, Apr 29, 2009 at 01:03:03PM -0500, Mike McGrath wrote: > > >> Well normally what I have seen is that the 'FAS' server would export a > > >> schema table to LDAP and LDAP would then be what is authenticated to > > >> (the same with Kerberos if combined). Or the FAS server has a > > >> mysql/postgres background and someone uses pam/mod mysql to do it. > > Sorry for butting in like this, but I always assumed FAS would use LDAP > > as a backend, so that 3rd parties, if they wanted to plug in to the > > system, would utilize LDAP. Is that not the case? > > Correct, that's not the case. Instead of LDAP we have a postgres backend > and use json to auth, third parties use python-fedora to authenticate. We > tried pretty hard to get LDAP working with our account system but ran into > many problems and decided to go back to postgres. I'd third the LDAP love here, e.g. either a read-only cron'd export to LDAP or rewriting the FAS backend for LDAP. Any future tool you may want to attach to FAS will most probably have LDAP support out of the box, but any other kind of authentication would need special coding (like your pam module request), which is both time consuming and a security risk if not written properly. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Apr 29 19:03:55 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 14:03:55 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <20090429184721.GB31876@victor.nirvana> References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> Message-ID: On Wed, 29 Apr 2009, Axel Thimm wrote: > On Wed, Apr 29, 2009 at 01:03:03PM -0500, Mike McGrath wrote: > > > >> Well normally what I have seen is that the 'FAS' server would export a > > > >> schema table to LDAP and LDAP would then be what is authenticated to > > > >> (the same with Kerberos if combined). Or the FAS server has a > > > >> mysql/postgres background and someone uses pam/mod mysql to do it. > > > > Sorry for butting in like this, but I always assumed FAS would use LDAP > > > as a backend, so that 3rd parties, if they wanted to plug in to the > > > system, would utilize LDAP. Is that not the case? > > > > Correct, that's not the case. Instead of LDAP we have a postgres backend > > and use json to auth, third parties use python-fedora to authenticate. We > > tried pretty hard to get LDAP working with our account system but ran into > > many problems and decided to go back to postgres. > > I'd third the LDAP love here, e.g. either a read-only cron'd export to > LDAP or rewriting the FAS backend for LDAP. Any future tool you may > want to attach to FAS will most probably have LDAP support out of the > box, but any other kind of authentication would need special coding > (like your pam module request), which is both time consuming and a > security risk if not written properly. > We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group. As far as actually using FAS to do stuff, it's quite possible that we can use LDAP there for things. I think: http://www.darold.net/projects/ldap_pg/HOWTO/ Is worth getting up and running to see. If it turns out to be cumbersome, then perhaps a cronned job is all that's available. -Mike From jkeating at redhat.com Wed Apr 29 21:18:01 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 29 Apr 2009 14:18:01 -0700 Subject: Bit flip In-Reply-To: <20090428181648.GA8096@auslistsprd01.us.dell.com> References: <20090428153451.GA15619@auslistsprd01.us.dell.com> <20090428181648.GA8096@auslistsprd01.us.dell.com> Message-ID: <1241039881.3472.1.camel@localhost.localdomain> On Tue, 2009-04-28 at 13:16 -0500, Matt Domsch wrote: > > So, I'd like to propose we back up the bitflip by at least 4 hours > from release time, perhaps as much as 6. Hrm. This means we have unlocked mirrors for up to 6 hours before we make the announcement. This could lead to a lot of confusion and uncertainty about the isos and their validity, something we see whenever a mirror leaks early. Honestly I think we need a vastly different way of getting mirrors to bit flip aside from waiting on random cron jobs to pick up the change. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wakko666 at gmail.com Wed Apr 29 21:44:00 2009 From: wakko666 at gmail.com (brett lentz) Date: Wed, 29 Apr 2009 14:44:00 -0700 Subject: Bit flip In-Reply-To: <1241039881.3472.1.camel@localhost.localdomain> References: <20090428153451.GA15619@auslistsprd01.us.dell.com> <20090428181648.GA8096@auslistsprd01.us.dell.com> <1241039881.3472.1.camel@localhost.localdomain> Message-ID: On Wed, Apr 29, 2009 at 2:18 PM, Jesse Keating wrote: > On Tue, 2009-04-28 at 13:16 -0500, Matt Domsch wrote: >> >> So, I'd like to propose we back up the bitflip by at least 4 hours >> from release time, perhaps as much as 6. > > Hrm. ?This means we have unlocked mirrors for up to 6 hours before we > make the announcement. ?This could lead to a lot of confusion and > uncertainty about the isos and their validity, something we see whenever > a mirror leaks early. > > Honestly I think we need a vastly different way of getting mirrors to > bit flip aside from waiting on random cron jobs to pick up the change. > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating > Is there any way to make the bit flip a push operation instead of a pull? ---Brett. From mmcgrath at redhat.com Wed Apr 29 22:03:18 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 17:03:18 -0500 (CDT) Subject: Bit flip In-Reply-To: <1241039881.3472.1.camel@localhost.localdomain> References: <20090428153451.GA15619@auslistsprd01.us.dell.com> <20090428181648.GA8096@auslistsprd01.us.dell.com> <1241039881.3472.1.camel@localhost.localdomain> Message-ID: On Wed, 29 Apr 2009, Jesse Keating wrote: > On Tue, 2009-04-28 at 13:16 -0500, Matt Domsch wrote: > > > > So, I'd like to propose we back up the bitflip by at least 4 hours > > from release time, perhaps as much as 6. > > Hrm. This means we have unlocked mirrors for up to 6 hours before we > make the announcement. This could lead to a lot of confusion and > uncertainty about the isos and their validity, something we see whenever > a mirror leaks early. > That's certainly a downside. But I'd generally consider that far less bad then an announcement going out and having so few mirrors actually be ready for it. > Honestly I think we need a vastly different way of getting mirrors to > bit flip aside from waiting on random cron jobs to pick up the change. > We do and are, but bit flipping sooner is an easy thing we can do now to make a more smooth transition. I think this is one of those don't let the perfect get in the way of the good situations. -Mike From mmcgrath at redhat.com Wed Apr 29 22:04:08 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 17:04:08 -0500 (CDT) Subject: Bit flip In-Reply-To: References: <20090428153451.GA15619@auslistsprd01.us.dell.com> <20090428181648.GA8096@auslistsprd01.us.dell.com> <1241039881.3472.1.camel@localhost.localdomain> Message-ID: On Wed, 29 Apr 2009, brett lentz wrote: > On Wed, Apr 29, 2009 at 2:18 PM, Jesse Keating wrote: > > On Tue, 2009-04-28 at 13:16 -0500, Matt Domsch wrote: > >> > >> So, I'd like to propose we back up the bitflip by at least 4 hours > >> from release time, perhaps as much as 6. > > > > Hrm. ?This means we have unlocked mirrors for up to 6 hours before we > > make the announcement. ?This could lead to a lot of confusion and > > uncertainty about the isos and their validity, something we see whenever > > a mirror leaks early. > > > > Honestly I think we need a vastly different way of getting mirrors to > > bit flip aside from waiting on random cron jobs to pick up the change. > > > > -- > > Jesse Keating > > Fedora -- Freedom? is a feature! > > identi.ca: http://identi.ca/jkeating > > > > Is there any way to make the bit flip a push operation instead of a pull? > We've been discussing options on this, everwhere from push, to trigger a pull to pull less but do it more often. -Mike From abu_hurayrah at hidayahonline.org Wed Apr 29 23:07:49 2009 From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar) Date: Thu, 30 Apr 2009 07:07:49 +0800 Subject: Statistics problem In-Reply-To: <20090429184040.GA31876@victor.nirvana> References: <20090428022648.GD17892@localhost.localdomain> <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> <49F85187.6070005@hidayahonline.org> <20090429184040.GA31876@victor.nirvana> Message-ID: <49F8DDC5.7070904@hidayahonline.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/30/2009 02:40 AM, Axel Thimm wrote: > On Wed, Apr 29, 2009 at 09:09:27PM +0800, Basil Mohamed Gohar wrote: >> On 04/29/2009 08:20 PM, Axel Thimm wrote: >>> On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: >>>>> Maybe the cleanest solution is to count downloaded bytes and divide by >>>>> image size. That way you properly count ranged downloads. >>>> Command suggestions are very welcome. I really don't have time to >>>> delve into this incredibly deeply at the moment. >>> Could you post a small fragment of the raw logs? But it seems like all >>> we see are the primary redirects, possibly w/o noting ranges in the >>> logs. E.g. for better statistics the logs would need to capture the >>> ranges from the head as well. >>> >> I think that information is not available, because no one (almost) >> downloads directly from the Fedora servers, only from the mirrors. >> Therefore, the real data, like range requests, etc., would only be on >> the mirror servers themselves, and not on the primary ones. > > Isn't a range request sent in the header of the HTTP request which > would hit the Fedora servers before being redirected? Not if the range request was after being redirected. I think, in the same download, the redirect is only processed once, even if it is a temporary one. Therefore, unless the first request was a partial content one, then the connection has already been redirected to the mirror server, and thus the main Fedora server will not see it. I'd draw a diagram, but I'm terrible at doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkn43cAACgkQaVgOCFr0s2I/sgCeKLAd+qxiOpr08HwSqYAIKxp/ uA0AnR6FIoh4Ov4Ggqt1OJ3uOBzBSxHQ =kgXY -----END PGP SIGNATURE----- From stickster at gmail.com Wed Apr 29 23:09:05 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 29 Apr 2009 19:09:05 -0400 Subject: Statistics problem In-Reply-To: <20090429184040.GA31876@victor.nirvana> References: <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> <49F85187.6070005@hidayahonline.org> <20090429184040.GA31876@victor.nirvana> Message-ID: <20090429230905.GY18166@localhost.localdomain> On Wed, Apr 29, 2009 at 09:40:40PM +0300, Axel Thimm wrote: > On Wed, Apr 29, 2009 at 09:09:27PM +0800, Basil Mohamed Gohar wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 04/29/2009 08:20 PM, Axel Thimm wrote: > > > On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: > > >>> Maybe the cleanest solution is to count downloaded bytes and divide by > > >>> image size. That way you properly count ranged downloads. > > >> Command suggestions are very welcome. I really don't have time to > > >> delve into this incredibly deeply at the moment. > > > > > > Could you post a small fragment of the raw logs? But it seems like all > > > we see are the primary redirects, possibly w/o noting ranges in the > > > logs. E.g. for better statistics the logs would need to capture the > > > ranges from the head as well. > > > > > > > I think that information is not available, because no one (almost) > > downloads directly from the Fedora servers, only from the mirrors. > > Therefore, the real data, like range requests, etc., would only be on > > the mirror servers themselves, and not on the primary ones. > > Isn't a range request sent in the header of the HTTP request which > would hit the Fedora servers before being redirected? Can someone on the Infrastructure guru team help me pull some relevant lines from the logs, expurgating the IP address and any other identifying information so we're not running afoul of any privacy concerns? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From mmcgrath at redhat.com Wed Apr 29 23:59:17 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 29 Apr 2009 18:59:17 -0500 (CDT) Subject: Statistics problem In-Reply-To: <20090429230905.GY18166@localhost.localdomain> References: <604aa7910904271930v57ec8605h97ead5df8af24be4@mail.gmail.com> <604aa7910904272043s55bc625fr166ab65a4ddd6ec6@mail.gmail.com> <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> <49F85187.6070005@hidayahonline.org> <20090429184040.GA31876@victor.nirvana> <20090429230905.GY18166@localhost.localdomain> Message-ID: On Wed, 29 Apr 2009, Paul W. Frields wrote: > On Wed, Apr 29, 2009 at 09:40:40PM +0300, Axel Thimm wrote: > > On Wed, Apr 29, 2009 at 09:09:27PM +0800, Basil Mohamed Gohar wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 04/29/2009 08:20 PM, Axel Thimm wrote: > > > > On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: > > > >>> Maybe the cleanest solution is to count downloaded bytes and divide by > > > >>> image size. That way you properly count ranged downloads. > > > >> Command suggestions are very welcome. I really don't have time to > > > >> delve into this incredibly deeply at the moment. > > > > > > > > Could you post a small fragment of the raw logs? But it seems like all > > > > we see are the primary redirects, possibly w/o noting ranges in the > > > > logs. E.g. for better statistics the logs would need to capture the > > > > ranges from the head as well. > > > > > > > > > > I think that information is not available, because no one (almost) > > > downloads directly from the Fedora servers, only from the mirrors. > > > Therefore, the real data, like range requests, etc., would only be on > > > the mirror servers themselves, and not on the primary ones. > > > > Isn't a range request sent in the header of the HTTP request which > > would hit the Fedora servers before being redirected? > > Can someone on the Infrastructure guru team help me pull some relevant > lines from the logs, expurgating the IP address and any other > identifying information so we're not running afoul of any privacy > concerns? > 255.255.255.255 - - [22/Mar/2009:23:59:44 +0000] "GET /pub/fedora/linux/releases/10/Live/i686/F10-i686-Live.iso HTTP/1.1" 302 -"http://fedoraproject.org/en/get-fedora" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)" Bam! -Mike From Axel.Thimm at ATrpms.net Thu Apr 30 03:44:09 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 30 Apr 2009 06:44:09 +0300 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> Message-ID: <20090430034409.GA5887@victor.nirvana> On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote: > We worked pretty closely with different LDAP teams and the way FAS works > is just not very... ldapian. Although it's only some internal stuff that > we need (specifically related to our user/sponsor/admin bits in each > group. Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes? Or rephrased: Can't any SQL field in a table be always mapped onto some (custom) ldap attribute? If you can map a problem onto an SQL database it should be possible to go ldap IMHO. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Matt_Domsch at dell.com Thu Apr 30 04:23:55 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 29 Apr 2009 23:23:55 -0500 Subject: Any C coders want to help me with something? In-Reply-To: <20090430034409.GA5887@victor.nirvana> References: <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> Message-ID: <20090430042355.GA13310@auslistsprd01.us.dell.com> On Thu, Apr 30, 2009 at 06:44:09AM +0300, Axel Thimm wrote: > On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote: > > We worked pretty closely with different LDAP teams and the way FAS works > > is just not very... ldapian. Although it's only some internal stuff that > > we need (specifically related to our user/sponsor/admin bits in each > > group. > > Can't this be implemented with a FAS ldap schema that contains these > bits in ldap attributes? Can I reverse the question? Instead of a pam_fas module, what about creating a way to export FAS information as LDAP, such that all LDAP-consuming apps would "just work", albeit not able to access the FAS-specific information? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ricky at fedoraproject.org Thu Apr 30 05:56:40 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 30 Apr 2009 01:56:40 -0400 Subject: Any C coders want to help me with something? In-Reply-To: <20090430042355.GA13310@auslistsprd01.us.dell.com> References: <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> <20090430042355.GA13310@auslistsprd01.us.dell.com> Message-ID: <20090430055640.GA30691@sphe.res.cmu.edu> On 2009-04-29 11:23:55 PM, Matt Domsch wrote: > Can I reverse the question? Instead of a pam_fas module, what about > creating a way to export FAS information as LDAP, such that all > LDAP-consuming apps would "just work", albeit not able to access the > FAS-specific information? I agree with this approach. In some distant future version of FAS, I'd like to play with the idea of storing the data in LDAP while handling our group sponsorship system in postgres. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Apr 30 12:54:42 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 30 Apr 2009 07:54:42 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <20090430034409.GA5887@victor.nirvana> References: <80d7e4090904281533p527904f5q2623ce35f850ced4@mail.gmail.com> <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> Message-ID: On Thu, 30 Apr 2009, Axel Thimm wrote: > On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote: > > We worked pretty closely with different LDAP teams and the way FAS works > > is just not very... ldapian. Although it's only some internal stuff that > > we need (specifically related to our user/sponsor/admin bits in each > > group. > > Can't this be implemented with a FAS ldap schema that contains these > bits in ldap attributes? > > Or rephrased: Can't any SQL field in a table be always mapped onto > some (custom) ldap attribute? If you can map a problem onto an SQL > database it should be possible to go ldap IMHO. > Seems like it should work that way, and we spent months trying to get it to work right (even working with the fedora-ds people) but it just ended up being very hacky and not very good. -Mike From mmcgrath at redhat.com Thu Apr 30 12:55:00 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 30 Apr 2009 07:55:00 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <20090430055640.GA30691@sphe.res.cmu.edu> References: <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> <20090430042355.GA13310@auslistsprd01.us.dell.com> <20090430055640.GA30691@sphe.res.cmu.edu> Message-ID: On Thu, 30 Apr 2009, Ricky Zhou wrote: > On 2009-04-29 11:23:55 PM, Matt Domsch wrote: > > Can I reverse the question? Instead of a pam_fas module, what about > > creating a way to export FAS information as LDAP, such that all > > LDAP-consuming apps would "just work", albeit not able to access the > > FAS-specific information? > I agree with this approach. In some distant future version of FAS, I'd > like to play with the idea of storing the data in LDAP while handling > our group sponsorship system in postgres. > Ick -Mike From stickster at gmail.com Thu Apr 30 13:59:43 2009 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 30 Apr 2009 09:59:43 -0400 Subject: Statistics problem In-Reply-To: References: <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> <49F85187.6070005@hidayahonline.org> <20090429184040.GA31876@victor.nirvana> <20090429230905.GY18166@localhost.localdomain> Message-ID: <20090430135943.GR3111@localhost.localdomain> On Wed, Apr 29, 2009 at 06:59:17PM -0500, Mike McGrath wrote: > On Wed, 29 Apr 2009, Paul W. Frields wrote: > > > On Wed, Apr 29, 2009 at 09:40:40PM +0300, Axel Thimm wrote: > > > Isn't a range request sent in the header of the HTTP request which > > > would hit the Fedora servers before being redirected? > > > > Can someone on the Infrastructure guru team help me pull some relevant > > lines from the logs, expurgating the IP address and any other > > identifying information so we're not running afoul of any privacy > > concerns? > > > 255.255.255.255 - - [22/Mar/2009:23:59:44 +0000] "GET > /pub/fedora/linux/releases/10/Live/i686/F10-i686-Live.iso HTTP/1.1" 302 > -"http://fedoraproject.org/en/get-fedora" "Mozilla/4.0 (compatible; MSIE > 7.0; Windows NT 5.1; .NET CLR 1.1.4322)" > > Bam! Is there one that includes a range request of the kind Axel talks about? Sorry to be dense. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From mmcgrath at redhat.com Thu Apr 30 14:15:32 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 30 Apr 2009 09:15:32 -0500 (CDT) Subject: Statistics problem In-Reply-To: <20090430135943.GR3111@localhost.localdomain> References: <20090428122950.GC13551@localhost.localdomain> <20090428125750.GE13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> <49F85187.6070005@hidayahonline.org> <20090429184040.GA31876@victor.nirvana> <20090429230905.GY18166@localhost.localdomain> <20090430135943.GR3111@localhost.localdomain> Message-ID: On Thu, 30 Apr 2009, Paul W. Frields wrote: > On Wed, Apr 29, 2009 at 06:59:17PM -0500, Mike McGrath wrote: > > On Wed, 29 Apr 2009, Paul W. Frields wrote: > > > > > On Wed, Apr 29, 2009 at 09:40:40PM +0300, Axel Thimm wrote: > > > > Isn't a range request sent in the header of the HTTP request which > > > > would hit the Fedora servers before being redirected? > > > > > > Can someone on the Infrastructure guru team help me pull some relevant > > > lines from the logs, expurgating the IP address and any other > > > identifying information so we're not running afoul of any privacy > > > concerns? > > > > > 255.255.255.255 - - [22/Mar/2009:23:59:44 +0000] "GET > > /pub/fedora/linux/releases/10/Live/i686/F10-i686-Live.iso HTTP/1.1" 302 > > -"http://fedoraproject.org/en/get-fedora" "Mozilla/4.0 (compatible; MSIE > > 7.0; Windows NT 5.1; .NET CLR 1.1.4322)" > > > > Bam! > > Is there one that includes a range request of the kind Axel talks > about? Sorry to be dense. > Nope. -Mike From jonstanley at gmail.com Thu Apr 30 14:17:24 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 30 Apr 2009 10:17:24 -0400 Subject: Statistics problem In-Reply-To: References: <20090428122950.GC13551@localhost.localdomain> <20090428135220.GA19050@victor.nirvana> <20090428151755.GC3350@localhost.localdomain> <20090429122054.GB26655@victor.nirvana> <49F85187.6070005@hidayahonline.org> <20090429184040.GA31876@victor.nirvana> <20090429230905.GY18166@localhost.localdomain> <20090430135943.GR3111@localhost.localdomain> Message-ID: On Thu, Apr 30, 2009 at 10:15 AM, Mike McGrath wrote: > Nope. To be more specific, this is all we have in the logs for yesterday from proxy1: [jstanley at log1 http]$ cat download.fedoraproject.org-access.log | awk '{print $9}' | sort -n | uniq -c 23872 302 24961 404 31 503 From a.badger at gmail.com Thu Apr 30 16:53:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 30 Apr 2009 09:53:39 -0700 Subject: Any C coders want to help me with something? In-Reply-To: References: <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> <20090430042355.GA13310@auslistsprd01.us.dell.com> <20090430055640.GA30691@sphe.res.cmu.edu> Message-ID: <49F9D793.5090804@gmail.com> Mike McGrath wrote: > On Thu, 30 Apr 2009, Ricky Zhou wrote: >> In some distant future version of FAS, I'd >> like to play with the idea of storing the data in LDAP while handling >> our group sponsorship system in postgres. >> > > Ick > heh :-) I think ricky's approach could work but it would need planning. The idea would be to increase the complexity of FAS but decrease the complexity for everything we deploy that needs authentication. We'd want to examine that assumption in the planning phase to make sure it's actually true for us. For instance, there was the thought that having cached credentials on our servers was preferable to what happens to when the LDAP server goes down. Still a concern? We currently mask a lot of information for the privacy policy, can we do that with LDAP? (Or just not put the information in there?) We let third parties (like the hosts to let packagers try building on ppc, x86_64, etc) use fas to get ssh keys. Would we let them connect to and get that information from the LDAP server instead? We let people use their normal accounts to get a subset of data for authenticating to their web apps while they're developing them. Would we enable the same setup with LDAP? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Thu Apr 30 17:37:09 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 30 Apr 2009 12:37:09 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <49F9D793.5090804@gmail.com> References: <80d7e4090904290929q6aa67d73g675549b0bc02d696@mail.gmail.com> <49F88AFA.1080406@hidayahonline.org> <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> <20090430042355.GA13310@auslistsprd01.us.dell.com> <20090430055640.GA30691@sphe.res.cmu.edu> <49F9D793.5090804@gmail.com> Message-ID: On Thu, 30 Apr 2009, Toshio Kuratomi wrote: > Mike McGrath wrote: > > On Thu, 30 Apr 2009, Ricky Zhou wrote: > >> In some distant future version of FAS, I'd > >> like to play with the idea of storing the data in LDAP while handling > >> our group sponsorship system in postgres. > >> > > > > Ick > > > heh :-) > > I think ricky's approach could work but it would need planning. The > idea would be to increase the complexity of FAS but decrease the > complexity for everything we deploy that needs authentication. We'd > want to examine that assumption in the planning phase to make sure it's > actually true for us. > > For instance, there was the thought that having cached credentials on > our servers was preferable to what happens to when the LDAP server goes > down. Still a concern? > > We currently mask a lot of information for the privacy policy, can we do > that with LDAP? (Or just not put the information in there?) > > We let third parties (like the hosts to let packagers try building on > ppc, x86_64, etc) use fas to get ssh keys. Would we let them connect to > and get that information from the LDAP server instead? > > We let people use their normal accounts to get a subset of data for > authenticating to their web apps while they're developing them. Would > we enable the same setup with LDAP? > I figure we're still very much in the exploritory stage, we should get our requirements together though. FAS going down is still a real concern, but if we implement a hardware key system, like yubikey, we'll have a similar requirement in that yubikey requires a yubiserver of some kind (or the AES key on every server). -Mike From smooge at gmail.com Thu Apr 30 17:45:49 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 30 Apr 2009 11:45:49 -0600 Subject: Any C coders want to help me with something? In-Reply-To: References: <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> <20090430042355.GA13310@auslistsprd01.us.dell.com> <20090430055640.GA30691@sphe.res.cmu.edu> <49F9D793.5090804@gmail.com> Message-ID: <80d7e4090904301045m58d45a9br3d018e007ba673d3@mail.gmail.com> On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath wrote: > On Thu, 30 Apr 2009, Toshio Kuratomi wrote: > >> Mike McGrath wrote: >> > On Thu, 30 Apr 2009, Ricky Zhou wrote: >> >> In some distant future version of FAS, I'd >> >> like to play with the idea of storing the data in LDAP while handling >> >> our group sponsorship system in postgres. >> >> >> > >> > Ick >> > >> heh :-) >> >> I think ricky's approach could work but it would need planning. ?The >> idea would be to increase the complexity of FAS but decrease the >> complexity for everything we deploy that needs authentication. ?We'd >> want to examine that assumption in the planning phase to make sure it's >> actually true for us. >> >> For instance, there was the thought that having cached credentials on >> our servers was preferable to what happens to when the LDAP server goes >> down. ?Still a concern? >> >> We currently mask a lot of information for the privacy policy, can we do >> that with LDAP? ?(Or just not put the information in there?) >> >> We let third parties (like the hosts to let packagers try building on >> ppc, x86_64, etc) use fas to get ssh keys. ?Would we let them connect to >> and get that information from the LDAP server instead? >> >> We let people use their normal accounts to get a subset of data for >> authenticating to their web apps while they're developing them. ?Would >> we enable the same setup with LDAP? >> > > I figure we're still very much in the exploritory stage, we should get our > requirements together though. ?FAS going down is still a real concern, but > if we implement a hardware key system, like yubikey, we'll have a similar > requirement in that yubikey requires a yubiserver of some kind (or the AES > key on every server). Normally there will need to be a prcedure to deal with such failures. Who to contact, how they log it, what methods are used for 'all-things-failed' access (usually a one-time-password that is changed afterwords), how to log actions and how to set things right again. This is more of a person fix versus technological fix. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Thu Apr 30 18:31:01 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 30 Apr 2009 13:31:01 -0500 (CDT) Subject: Any C coders want to help me with something? In-Reply-To: <80d7e4090904301045m58d45a9br3d018e007ba673d3@mail.gmail.com> References: <20090429184721.GB31876@victor.nirvana> <20090430034409.GA5887@victor.nirvana> <20090430042355.GA13310@auslistsprd01.us.dell.com> <20090430055640.GA30691@sphe.res.cmu.edu> <49F9D793.5090804@gmail.com> <80d7e4090904301045m58d45a9br3d018e007ba673d3@mail.gmail.com> Message-ID: On Thu, 30 Apr 2009, Stephen John Smoogen wrote: > On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath wrote: > > On Thu, 30 Apr 2009, Toshio Kuratomi wrote: > > > >> Mike McGrath wrote: > >> > On Thu, 30 Apr 2009, Ricky Zhou wrote: > >> >> In some distant future version of FAS, I'd > >> >> like to play with the idea of storing the data in LDAP while handling > >> >> our group sponsorship system in postgres. > >> >> > >> > > >> > Ick > >> > > >> heh :-) > >> > >> I think ricky's approach could work but it would need planning. ?The > >> idea would be to increase the complexity of FAS but decrease the > >> complexity for everything we deploy that needs authentication. ?We'd > >> want to examine that assumption in the planning phase to make sure it's > >> actually true for us. > >> > >> For instance, there was the thought that having cached credentials on > >> our servers was preferable to what happens to when the LDAP server goes > >> down. ?Still a concern? > >> > >> We currently mask a lot of information for the privacy policy, can we do > >> that with LDAP? ?(Or just not put the information in there?) > >> > >> We let third parties (like the hosts to let packagers try building on > >> ppc, x86_64, etc) use fas to get ssh keys. ?Would we let them connect to > >> and get that information from the LDAP server instead? > >> > >> We let people use their normal accounts to get a subset of data for > >> authenticating to their web apps while they're developing them. ?Would > >> we enable the same setup with LDAP? > >> > > > > I figure we're still very much in the exploritory stage, we should get our > > requirements together though. ?FAS going down is still a real concern, but > > if we implement a hardware key system, like yubikey, we'll have a similar > > requirement in that yubikey requires a yubiserver of some kind (or the AES > > key on every server). > > Normally there will need to be a prcedure to deal with such failures. > Who to contact, how they log it, what methods are used for > 'all-things-failed' access (usually a one-time-password that is > changed afterwords), how to log actions and how to set things right > again. This is more of a person fix versus technological fix. > That's the thing that's nice about our current setup though, it's a technical fix. FAS could go down right now and lots of services (cvs, fedorahosted, all shell access, etc) would stay up. The downside is the sync times. -Mike From ricky at fedoraproject.org Thu Apr 30 21:02:47 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 30 Apr 2009 17:02:47 -0400 Subject: Meeting Log - 2008-04-30 Message-ID: <20090430210247.GC30691@sphe.res.cmu.edu> 19:59 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 19:59 * ricky 19:59 * skvidal is 20:00 * nirik waves from the back of the room. 20:00 < mmcgrath> So I'm going to go quickly through some things so we can talk about authentication. 20:00 * jeremy squints and tries to see if he can make out the front of the room from the top of the cheap seats ;) 20:01 * lmacken is here 20:01 -!- mdomsch [n=Matt_Dom at cpe-70-124-62-55.austin.res.rr.com] has joined #fedora-meeting 20:01 < mmcgrath> First lets go through this last release 20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- The release 20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- The preview release 20:01 < mmcgrath> all in all it went well, the bit flip issue being the main issue. 20:02 < mmcgrath> we've suggested an earlier bit flip time though I don't think we've heard that's how it will be from releng. 20:02 < jwb> i decree yes 20:02 < mdomsch> f13 wasn't excited by it 20:02 < mdomsch> but it would solve the problem at least temporarily 20:02 < mmcgrath> also interestingly was this grap - 20:02 < mmcgrath> h 20:02 < mmcgrath> http://mmcgrath.fedorapeople.org/MirrorRediness-11-Preview.html 20:02 < mdomsch> and the early fanboys will be pleased 20:02 -!- stickster_afk is now known as stickster 20:02 < mmcgrath> showing, in 3 hour intervals, mirrors being ready, then not ready, then ready, then not ready. 20:02 * ricky doens't see why it would ever drop like that 20:03 < mdomsch> not sure either 20:04 < mdomsch> the 3-hour cycle matches that of a crawler run 20:04 < mdomsch> (which now will take <2 hours) 20:04 < mmcgrath> mdomsch: and of course my script started failing after that, but I do have the last 24 hours. 20:04 < mmcgrath> I'll try to get that graphed and up after the meeting is up. 20:04 < mmcgrath> I accidently started appending the output from sleep :) 20:05 < mmcgrath> Ok, so all in all thats what happened there. 20:05 -!- kital [n=Joerg_Si at fedora/kital] has quit Read error: 113 (No route to host) 20:05 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Authentication 20:05 -!- RadicalRo [n=radical at 77.36.4.49] has quit Remote closed the connection 20:05 < smooge> i am herew 20:05 < mmcgrath> So on to the meat of the meeting. 20:05 < mmcgrath> smooge: hey 20:05 < mmcgrath> So there's been lots of discussion on f-i-l recently and I think it's mostly just re-hashing of stuff that's been on many of our minds for a while 20:06 < mmcgrath> dgilmore and I have started looking at yubikey and lmacken is already a user. 20:06 < mmcgrath> AFAIK, it's looking pretty solid. 20:06 < smooge> cool. 20:06 < mmcgrath> So lets flash forward and pretend we have a yubikey or some other hardware style key thing implemented. 20:06 * lmacken would love to see yubikey's with a fedora logo on it :) 20:06 < mmcgrath> What do we want that environment to look like? 20:06 < mmcgrath> lmacken: yeah I told dgilmore we need to get mizmo to get some stickers made :) 20:07 < mmcgrath> At the core of what *I* want 20:07 < mmcgrath> is two factor authentication. 20:07 < mmcgrath> for all of sysadmin-main. 20:07 < mmcgrath> and make it optional for others. 20:07 < mmcgrath> but what all that means is unclear to me. 20:07 < mmcgrath> So where did LDAP come in? 20:07 < smooge> hmmm at a previous place had our 2 factor item connected to the kerberos server. This allowed us to have a 4 hour reauth time etc.. might be overkill etc 20:08 < ricky> The LDAP discussion came in as a response to the talk about a FAS PAM module. 20:08 < mmcgrath> I started looking at LDAP because we regularly have uses for it but have to say no because we don't have it installed. 20:08 < ricky> Which might be a completely separate thing from 2 factor auth 20:08 < mmcgrath> And from the pam module 20:08 < smooge> so you plug in the key, do your login, and the kerberos authorizes you, the LDAP authenticates (or vice versa) 20:08 < mmcgrath> ricky: right, completely separate but linked in this way... 20:08 < mmcgrath> If the yubikey server goes down, we can't auth. 20:08 < mmcgrath> which means our 'cached' nss setup now, isn't that important. 20:09 < mmcgrath> additionally. 20:09 < smooge> you then get a cookie from the kerberos server that can be cached for X time 20:09 < mmcgrath> we can do different auth for different bits if we want. 20:09 < mmcgrath> for example ssh key to get into a server, but yubikey to auth on it. 20:09 < ricky> Would requiring yubikey for sudo auth be enough? 20:10 < mmcgrath> ricky: not sure, this is all the stuff we have to discuss and think about. 20:10 < ricky> That's the main place where passwords come into play, but that doesn't help much for SSH keys. 20:10 < mmcgrath> smooge: how do you think that type of setup would work in Fedora? 20:10 < ricky> smooge: Is there any way to make it optional without getting in the way of non-token people (ie they don't need to go though an extra prompt or anything)? 20:10 < mmcgrath> jeremy: also, IIRC, did you mention some concerns about running kerberos in Fedora because "clients connecting to two different kerberos networks is painful" ? 20:10 < mmcgrath> or something similar 20:11 < jeremy> mmcgrath: yes 20:11 < jeremy> you can't (easily) have credentials from two kerberos realms at once 20:11 < mmcgrath> so that's something to keep in mind. 20:11 < jeremy> unless you set up cross-realm auth. but that has to be done for every domain you want to allow it with 20:11 < mmcgrath> especially since fedora is secondary for so many people. IE: it's not their primary purpose 20:11 < smooge> well ricky we had multiple layers of authorization. Most people just needed to use the OTP from the cryptocard for getting access. Sysadmins needed a key fob for root access 20:11 < ricky> Something like yubikey would solve a lot of the problems of kerberos though - passwords hashes would pretty much never get sent, correct? 20:12 < mmcgrath> ricky: correct 20:12 < smooge> mmcgrath, I would use the kerberos in the method that ricky mentioned. 20:12 < mmcgrath> smooge: but what about the two kerberos realm problem? 20:12 < ricky> That is an issue worry with something like plain LDAP though, although if somebody can get to a point where they can sniff the traffic, it's already pretty bad. 20:12 < smooge> Most people don't need it.. but some might and those would be the admins etc... 20:13 < smooge> we did cross auth for zones we cared about and where we did not you just do a kdestroy 20:13 < jeremy> smooge: constantly having to kdestroy/kinit is a royal pain 20:14 * jeremy used to do so between rht and ncsu. finally gave up on caring about having ncsu tickets regularly 20:14 < smooge> jeremy, I don't know if I did it that many times. 20:14 < smooge> I had a script that executed that did my logins in the non-cross auth realm 20:15 < ricky> One nice thing about something like LDAP + Kerberos is that it can be rolled out in small pieces. 20:16 < mmcgrath> So I guess my question is, what does kerberos buy us if we're using otp keys anyway? 20:16 < smooge> I am not wedded to kerberos.. its just a way we used to get around dealing with needing multiple cryptocard servers etc 20:16 < mmcgrath> from a security point of view, not much it seems. 20:16 < jeremy> smooge: it would cause major amounts of pain for rht devs doing rhel builds + fedora builds (since at that point, keeping ssl certs _also_ would be kind of overkill. at which point, we'd be using krb for koji atuh) 20:16 < mmcgrath> from the client point of view they have to use the otp more often, but at the cost of greatly complicating any existing kerberos users (which would affect lots of RH employees) 20:16 < jeremy> man, one of these days I need to learn how to type 20:16 < ricky> Kerberos would limit the number of services that we *really* make sure are secure. 20:16 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 20:17 < mmcgrath> ricky: I take it you mean that as a benefit of kerberos? 20:17 < smooge> jeremy, I understand which is why I am not wed to it. Its more of a way to deal with it without inventing kerberos lite (as I have seen a lot places do). 20:17 < ricky> mmcgrath: At least that what I thought people usually try to get out of it 20:18 < smooge> however, sometimes inventing kerberos-lite is what is needed 20:19 < mmcgrath> I think kerberos is going to be a non starter I'm afraid, since it'd only work if we required it everywhere and I don't think we can do that without making life difficult for any of our contributors who are already using kerberos elsewhere. 20:19 < smooge> mmcgrath, kerberos has 'single-sign-on' inconvenience with a way to secondary log access/actions. 20:19 < jeremy> smooge: honestly, kerberos++ really needs to be done taking into account the need of multiple identies. I don't know how much the ipa people have thought about it, though, as I know a lot of their focus is basically "replace AD" :) but that's probably getting way off-topic for this discussion 20:19 < smooge> jeremy, agreed (on all 3 accounts :)). 20:19 < mmcgrath> So, lets say our goal is two facter authentication using a hardware key like yubikey. 20:20 < smooge> mmcgrath, agreed with no kerberos. 20:20 < mmcgrath> So lets leave implementation on the back burner for now and we can think about it for next week. 20:20 < mmcgrath> And lets look at some of our services and how this would affect that. 20:20 < mmcgrath> The big one is things in our critical path, cvs, uploading to cvs, and koji 20:21 < mmcgrath> I really don't think we can be in a position to require packagers to get a hardware key. 20:21 < mmcgrath> even with an unlimited budget, I think it'd be painful without people hours. 20:21 -!- GeroldKa [n=GeroldKa at fedora/geroldka] has joined #fedora-meeting 20:21 < smooge> mmcgrath, I don't think it would buy much if we did. 20:21 < mmcgrath> anyone disagree with that? 20:21 < ricky> Agreed. 20:21 < ricky> But we still need to consider it from the perspective of people that do need keys. 20:22 < mmcgrath> So then we'll be in a scenario where some hardware key is supported but optional... There's a slight bootstrap problem there. 20:22 < mmcgrath> IE: If it's a checkbox in FAS to say "I want to use my yubikey" 20:22 < mmcgrath> After that point, it requires the yubikey to log in. 20:23 < mmcgrath> So what do we do if they lose the yubikey? 20:23 < smooge> mmcgrath, I would say that its critical for things like people who sign packages, people who have 'root' access, etc 20:23 < mmcgrath> smooge: by critical you mean required? 20:23 < mdomsch> smooge+_ 20:23 < mdomsch> ++ 20:23 < ricky> Just curious - what is the process for initializing the yubikey for auth? Where would that fit in? 20:23 < mmcgrath> ricky: I haven't gotten that far yet actually. You can put your own keys on there, but by default it uses the yubikey server. 20:23 < lmacken> ricky: doesn't require initialization on the key itself... should work out of the box. It also has a write-only section that allows you to replace the AES key 20:23 < smooge> mmcgrath, good first question. There needs to be a procedure for deauthorizing a key tested and built before we allow for people to use them 20:24 < ricky> But somewhere, it has to be registered that this key gives access to this user, right? 20:24 -!- philip_ [n=philip at unaffiliated/philip] has quit Read error: 104 (Connection reset by peer) 20:24 < mmcgrath> smooge: yeah and this is a farily constant (though infrequent) problem. 20:24 < mmcgrath> Since we have no real way to verify someone is who they say they are. 20:24 < lmacken> yes, just like a credit card... if you lose it, you can ensure that the lost key can never be used 20:24 < mdomsch> FI buys the keys, distributes them 20:24 < smooge> mmcgrath, we were reauthorizing cards at places where I worked quite a bit... it happens quite a bit. 20:24 < mmcgrath> mdomsch and I know eachother fairly well, if he tells me his laptop has been stolen. 20:24 < smooge> it was a major cost part of my group. 20:24 < mmcgrath> It becomes very difficult for me to verify mdomsch is mdomsch 20:25 < smooge> you have to have a secondary trusted path for people. 20:25 < mmcgrath> ricky: this reminds me, we need a question and answer bit in fas. 20:25 < mmcgrath> smooge: yeah 20:25 < smooge> that would probably be a 'help' desk in the SIP section. The person would need to dial in a code and then that would deauthorize the fas for that UID/code 20:26 < mmcgrath> Phone is a good method of verification, I don't think we're currently using it like that. 20:26 < mmcgrath> Someone at pycon was doing something similar with asterisk. 20:26 < mmcgrath> though our asterisk setup can't dial out. 20:26 < mmcgrath> anywho, that's something that needs to get done but is a bit off topic. 20:27 < mmcgrath> So we want to be in a situation where we require yubikeys for some subset of people. 20:27 < mmcgrath> What would our multiauth look like? 20:27 * nirik notes if you have a question and answer thing you should let the user fill in both. 20:27 < mmcgrath> would we use password + otp? 20:27 < mmcgrath> nirik: 20:28 < ricky> Is there any option other than password + otp? That's the two factor part, right? 20:28 < nirik> canned security questions are really nasty... especially since they are often something someone can find out easily. 20:28 < mmcgrath> what would our other auth method be besides the otp I guess is my question. 20:28 < mmcgrath> ricky: I thought ssh key + otp might be good. 20:28 < mdomsch> mmcgrath, for what resources are we concerned 20:28 < mdomsch> ? 20:28 < mmcgrath> mdomsch: thats a good question as well. 20:28 < mmcgrath> obviously we wouldn't want to require otp for the otp server.. 20:28 < mdomsch> for connecting using ssh, ssh key + otp would reduce liklihood of stolen ssh keys being used to ssh in 20:28 < mmcgrath> Unless there's some sort of failover state. 20:29 < ricky> We can't do SSH key + OTP for sudo though 20:29 < mdomsch> ricky, right 20:29 < mmcgrath> ricky: correct, but would two factor in, and otp sudo work? 20:29 < mmcgrath> I think that seems reasonable. 20:29 < mmcgrath> although the stolen laptop bag becomes a problem. 20:29 < mmcgrath> since we still have to trust users to encrypt their ssh keys 20:29 < mdomsch> 2-factor tends to be "something I have, and something I know" 20:30 < mmcgrath> 20:30 < mdomsch> yubikey and/or ssh keys are "something I have" 20:30 < mmcgrath> and ssh key isn't really something you know. 20:30 < ricky> SSH keys seem too close to "two things I have" 20:30 -!- CheekyBoinc [n=cheekybo at fedora/CheekyBoinc] has joined #fedora-meeting 20:30 < mmcgrath> So we'd do fas password and otp? 20:30 < mdomsch> seemingly 20:30 < ricky> As much as I hate typing my password, that probably seems like the best way. 20:31 < mdomsch> so again, what are we trying to protect? 20:31 < mmcgrath> mdomsch for me it's stolen credentials. 20:31 < mdomsch> sudo by someone in sysadmin-main 20:31 < ricky> What I got was "protecting against stealing passwords" 20:31 < CheekyBoinc> I've a problem with checking out a package. I had to renew my ssh key and client cert because of hdd failure. The error is: 20:31 < ricky> sudo or any access to sensitive machines. 20:31 < mmcgrath> CheekyBoinc: please /join #fedora 20:31 < mmcgrath> CheekyBoinc: we're having an infrastructure meeting. 20:31 < CheekyBoinc> k :P 20:32 < ricky> Or you might ask in #fedora-admin if it's about the account sysytem 20:32 < ricky> **system 20:32 < mmcgrath> CheekyBoinc: yeah sorry you want #fedora-admin 20:32 < CheekyBoinc> okay thank you :) 20:32 < CheekyBoinc> #fedora-admin 20:32 < ricky> /j #fedora-admin 20:32 < CheekyBoinc> woops ^^ 20:32 -!- CheekyBoinc [n=cheekybo at fedora/CheekyBoinc] has left #fedora-meeting ["Verlassend"] 20:32 < mmcgrath> So would we blanket protect all servers (minus otp server)? 20:32 < mmcgrath> or pick specific ones? 20:33 < mmcgrath> for example... 20:33 < mmcgrath> trying to update and build a new package and re-typing your password and press the yubikey becomes quite painful 20:33 < mmcgrath> you'd have to do it many times 20:34 < mmcgrath> but if we're just looking to protect sudo access it becomes easier. 20:34 < ixs> mmcgrath: what about the low-tech approach of trusting your admins to encrypt your keys? 20:35 < mmcgrath> ixs: we have a policy of that now, and had assumed people were doing it but I'm not comfortable with that approach any more. 20:35 < smooge> most places I have dealt with two factor have not allowed ssh keys because of the 'something we have' problem 20:35 < ricky> We already do that, but I now we're also considering the situation where somebody can log keystrokes. 20:35 < mmcgrath> ixs: especially since if comsone could get their password, they'd be able to update the ssh key in fas. 20:35 < mmcgrath> smooge: but what about ssh key to get in and do 'normal user stuff' 20:35 < ixs> mmcgrath: when I was with RH we considered smartcard auth for a possible openvpn setup (instead of the cisco one). 20:35 < mmcgrath> but require the key to do sudo level stuff? 20:35 < ixs> mmcgrath: that would work, as it's a rather controlled usergroup and you can force your users to do that. 20:36 < ixs> mmcgrath: sox compliance would be one possible excuse. 20:36 < smooge> mmcgrath, not really but the places with two-factor auth all are places that don't want to be in the news (again) 20:36 < ixs> mmcgrath: for fedora contributors? never gonna work. for fedora admins? doubtful. 20:36 < mmcgrath> hmm 20:36 < smooge> in this case we are looking at doing two factor auth for people who we are giving higher levels of trust versus bottom level of trust. 20:36 < ricky> I think we've already ruled out requiring anything of all contributors. 20:36 < mmcgrath> ixs: sorry I missed something, you can "force your users" to do what? 20:37 < smooge> in that case you usually need to work out a way for that person to become someone else somehow. 20:37 < ricky> Does not requiring two factor auth on certain services undermine the "something you know" part required for auth to the other services? 20:37 < ixs> mmcgrath: Red Hat IT could force all Red Hat employees to use a smartcard based system for authentication. You probably can't do that with fedora contributors... 20:38 < ixs> mmcgrath: I couldn't think of a better way of decimating the number of contributors... :) 20:38 < ricky> ixs: See above, we already established that we're not forcing contributors to do this :-) 20:38 < mmcgrath> ixs: yeah we're not talking about the scope of fedora contributors. 20:38 < mmcgrath> just our admins. 20:38 < mdomsch> and just for sudo 20:38 < mdomsch> and package signing 20:39 -!- themayor [n=jack at 66.187.234.199] has quit 20:39 < mmcgrath> mdomsch: although I could think of other servers that could use it 20:39 < ricky> I'm not crazy about the idea of protecting sudo more than access to sensitive machines. 20:39 < mmcgrath> yeah like the signing 20:39 < mmcgrath> or backup1 20:39 < mmcgrath> ricky: look at the cvs1 use case 20:39 < mdomsch> hmm 20:39 < smooge> how hard would it be to look at multiple 'roles' for people. 20:39 < smooge> s/roles/roles-n-accounts/ 20:40 < mmcgrath> smooge: not following, give me a use case 20:40 < mdomsch> so ssh into sensitive machines could require ssh key and yubikey? 20:40 < smooge> I mean the other way I saw it done was I login in as smooge 20:40 < ixs> mmcgrath: but it applies to admins as well, to a certain degree. Two factor auth is hard, says security-barbie, let's go shopping. And unfortunately, it's often doubtful if the hassle of introducing it is worth it... 20:40 < ricky> ixs: If we enforce it, there's no getting around it though 20:40 < smooge> I want to become root/sign/etc I need to login to an account that is not allowed to ssh in as. sudo/su sjsmooge 20:40 < mmcgrath> mdomsch: maybe, I'm not sure if that's technically possible. ssh key auth is done by sshd, I'm not sure if you can mix it with pam. IE: I think that's a "if either succeeds" not "if both succeed" 20:41 < mmcgrath> ixs: I'm pretty sure it'll be wirth it in this case. 20:41 * ricky is reminded of kerberos principals :-) 20:41 < smooge> From that account I can sudo/sign/etc but I can't from the original account 20:41 < mmcgrath> err worth 20:41 < ixs> ricky: I'm not talking about circumventing it... But on the other hand, consider a local root exploit. You will be getting owned, even with a locked down sudo. 20:42 < mdomsch> mmcgrath, sshd uses pam by default 20:42 < mmcgrath> ixs: you have to remember that has never happened to us, stolen credentials has and I'd at least like to be able to say "the way we got owned in the past can't happen now" 20:42 < ricky> ixs: That's why I said I wasn't comfortable with just protecting sudo and ignoring access to sensitive machines 20:42 < mmcgrath> mdomsch: but I think pam gets bypassed with ssh key auth. 20:42 < mmcgrath> smooge: that's not too hard, I believe we do that in some scenarios now 20:43 < mdomsch> smooge, MIT had that concept too. user 'mdomsch' and user 'mdomsch.root' 20:43 < ixs> ricky: krb is great in theory. In the real world it's often useless as people are not passing tickets but ask for the password and verify that. The implementation is made out of fail... 20:43 < smooge> mmcgrath, it does. there is a reason why the 2 way kerberos patches have to circumvent the ssh-key stuff 20:43 < skvidal> mmcgrath: pam is still involved with ssh_key_auth 20:43 < mmcgrath> ixs: you're a negative nancy :-P 20:43 < skvidal> mmcgrath: you can deny access to a user even though they have a valid ssh key 20:43 < skvidal> mmcgrath: pam_access, for example 20:43 < mmcgrath> skvidal: but could you force ssh to require an ssh key and a valid password? 20:43 < ixs> mmcgrath: Sure, I have been around a bit doing security consluting... :) 20:44 < ixs> mmcgrath: the real world out there sucks. hamsters through straws. 20:44 -!- jnettlet [n=jnettlet at c-76-24-25-45.hsd1.ma.comcast.net] has joined #fedora-meeting 20:44 < smooge> ixs, we can always go with the RMS method. Put the root password in /etc/motd because well someones going to find a local root exploit someday anyway 20:44 < skvidal> mmcgrath: I don't know for sure - I think I'd need to spend some time with opensshd to figure that out 20:45 < ixs> smooge: that would be one possibility. After all, local security is said to be non existing under unix... :) 20:45 < ixs> smooge: but I was actually thinking a bit more realisitic then RMS. 20:45 < ricky> So the main question that we have now is where we enforce it and where we don't. 20:45 < mdomsch> smooge, that's the theory I use for my FON wireless AP at home. guest/guest is perfectly fine by me for those users that find it... 20:45 < mdomsch> and the web page says so 20:45 < ricky> Have we decided that we want to enforce it on shell access and sudo to sensitive machines? 20:45 < smooge> ricky, I would say that is what we should aim for 20:46 < smooge> eh.. backup... we want to enforce it for sudo normally and shellaccess to sensitive machines 20:46 < ricky> OK, so what remains is pretty much cvs, hosted, and fedorapeople, right? 20:46 < ricky> smooge: Good catch 20:46 < ricky> Those are the ones that are likely to get annoying with a token. 20:47 < mmcgrath> ricky: OH! I just thought of something..... 20:47 < ixs> mmcgrath: granted, being able to say that stolen credentials will not happen again is worth a lot. Two factor auth could offer that guarantee. Requiring the admins to use passwords on their keys does the same with less hassle. Drawback: you cannot enforce it. However: With smartcards you cannot really enforce it either... I've seen people removing the password from smartcards, leave them in the reader or even better, write nice ... 20:47 < mmcgrath> ricky: mdomsch: does the "can't use ssh_key" scenario become easier if we use controlmaster auto ? 20:47 < ixs> ... wrappers entering the password as the pin cannot always be disabled... 20:47 -!- warren [n=warren at redhat/wombat/warren] has quit "Leaving" 20:48 < ixs> mmcgrath: users usually find a way of circumventing security measures... be it post-its under the keyboard or smartcard systems... 20:48 < mmcgrath> it does. 20:48 < ricky> mmcgrath: that's a good point :-) 20:48 < mmcgrath> mdomsch: what do you think fo that? 20:48 < mdomsch> reading... 20:48 < smooge> ixs, that in the end is a personell matter.. no amount of technical fixes can fix humanity. 20:48 < ricky> That reduces it to one annoying auth per bunch of commits, etc. 20:49 < smooge> however we can reduce risk 20:49 < mmcgrath> smooge: but I'm trying to fix that :) 20:49 < ixs> smooge: that's actually my point all along. 20:49 < mmcgrath> ricky: yeah 20:49 * mdomsch doesn't use controlmaster normally 20:49 < ricky> Short of giving your password *and* token away, it's kind of hard to circumvent this without being being purposely evil :-) 20:49 < mdomsch> so I don't know the implications thereof 20:49 < smooge> ixs, your way of saying it comes across as we shouldn't bother mitigating risk 20:49 < mmcgrath> mdomsch: yeah, AFAIK it's as secure as using ssh agent 20:49 < mdomsch> yes 20:50 < mmcgrath> but becomes a problem if you drop your primary connection. 20:50 < mmcgrath> but that's an implementation detail, we can look at things as we're testing. 20:50 < mdomsch> one more thought - 20:50 < mdomsch> puppet git commits 20:50 < mdomsch> don't require sudo 20:50 < mmcgrath> mdomsch: technically they do 20:50 < mdomsch> mmcgrath, ? 20:51 < mmcgrath> if you sudo -l on puppet1 you'll see - 20:51 < ricky> Everybody has sudo for the command that syncs the repo to /var/lib/puppet 20:51 < mmcgrath> /usr/local/bin/syncPuppetMaster.sh 20:51 < mmcgrath> so the commit generates an email, and as part of that sudo syncs puppet. 20:51 < ricky> I don't think we have much to gain from requiring passwords there. 20:51 < mmcgrath> AFAIK there's no way to make a puppet update without generating an email first. 20:51 < mmcgrath> and while that's not preventative, it is an audit trail. 20:51 < ricky> Not unless we require tokens of *all* people with access to puppet. 20:51 < ixs> smooge: not exactly. Asking for password protected ssh keys is a very good idea. This is not very invasive. ssh-agent makes it easy. Requiring passwords "constantly", be it short expire times or anything else, will push some people to circumvent it. And in that case you have actually less security then before. On paper it's looking very fine, but the reality is different. 20:52 * ricky has been wondering if there's a way to delay or get around puppet mail. 20:52 < mmcgrath> ricky: depends on how much usability we're willing to give up 20:52 < mmcgrath> oh you mean just in normal usage. 20:52 < ricky> For example, DoS bastion and make a puppet commit to turn the mail server off 20:52 -!- yn1v [n=neville at static35-77.MAN-PI.cablenet.com.ni] has quit "Leaving" 20:52 < mmcgrath> ricky: yeah that'd work, it's an attack vector. 20:52 < ricky> But that's a whole other thing 20:52 -!- JukeBoxHero [n=gorillaJ at fedora/hitboxx] has quit Remote closed the connection 20:52 < mmcgrath> but still, we have to trust our admins at some point. 20:53 < mmcgrath> but I see mdomsches point about requiring sudo on puppet. 20:53 < mmcgrath> sudo would be that last "prove you are who you say you are" 20:53 < mmcgrath> I think it's worth thinking about. 20:53 < smooge> mmcgrath, trust but verify is my motto :) 20:53 < mmcgrath> especially since it's as easy as removing the "NOPASSWD" line from sudo to use if we implement a hardware key. 20:53 < ricky> An attacker would be perfectly happy with abusing trust 20:54 < skvidal> smooge: thank you mr. president 20:54 < skvidal> ricky: smooge was making a joke from the gipper 20:54 < ricky> That does make sense (puppet sudo) to require auth from everybody. 20:55 < mmcgrath> Ok, so we're almost out of time and I'm sure we'll be discussing this many more times before we do anything about it so I'm going to open the floor. 20:55 < ricky> Ah, hehe. 20:55 < mdomsch> mmcgrath, could be as easy as requiring ssh+git to commit to the trees 20:55 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:55 < mdomsch> possibly 20:55 < mmcgrath> mdomsch: thats true 20:55 < ricky> Or just passwords on the sudo 20:55 < mmcgrath> Anyone have anything to discuss? (We can keep discussing this :) 20:55 < mdomsch> ricky, yeah, that's probably easier 20:56 -!- Sonar_Guy [n=Who at fedora/sonarguy] has joined #fedora-meeting 20:56 * ricky wouldn't mind a summary of what we've determined so far. 20:56 < ricky> It's easy to get lost in all of the side conversations 20:56 < smooge> ixs, I have found that the people who wish to circumvent passwords are the sort to not want them for their ssh-agent either. at which point we are back to zero. There will always be people who do not like the fact the world doesn't really revolve around them (it revolves around skvidal) 20:56 < mmcgrath> ricky: I can write one up after the meeting. 20:56 < skvidal> smooge: and you wouldn't believe how dizzy that makes me 20:56 < ricky> Sounds good 20:58 < mmcgrath> anyone have anything else to discuss? We've got 2 minutes. 20:58 -!- Bob-Laptop [n=EvilBob at fedora/bobjensen] has joined #Fedora-Meeting 20:59 < mmcgrath> hehe boy I know how to quiet a room :) 20:59 * ricky makes a plug for people to test the anti-ctrl-c stuff 20:59 < mmcgrath> ricky: yeah send a follow up to the list about that. 21:00 < mmcgrath> ricky: I'll make sure to test it a couple of times by tomorrow. 21:00 < ricky> (https://www.redhat.com/archives/fedora-infrastructure-list/2009-April/msg00084.html) 21:00 < ricky> Will do, thanks 21:00 < ricky> If anybody has suggestions on how to make it easier for people to test, I'm all eas 21:00 < ricky> **ears 21:00 < mmcgrath> So everyone think on this auth stuff some this afternoon. The future is wide open there and no decisions have actually been made yet. 21:00 < ricky> We can make it open to all packagers, for example. 21:01 < mmcgrath> ricky: lets talk after the meeting. 21:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting End -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Apr 30 21:30:27 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 30 Apr 2009 17:30:27 -0400 Subject: Preventing ctrl-c from blocking CVS commit messages In-Reply-To: <20090423203025.GE20235@sphe.res.cmu.edu> References: <20090423203025.GE20235@sphe.res.cmu.edu> Message-ID: <20090430213027.GD30691@sphe.res.cmu.edu> On 2009-04-23 04:30:25 PM, Ricky Zhou wrote: > I'd appreciate if people can test and try to abuse/break this setup :-), > so I have a test repo setup. To test this, you need to be in > sysadmin-test: > > 1. Prepend your ~/.ssh/authorized_keys file on > publictest10.fedoraproject.org with: > > command="/home/fedora/ricky/test.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty > > (make sure not to accidentally lock yourself out with this) > > 2. Checkout the test module with: > cvs -d :ext:username at publictest10.fedoraproject.org/home/fedora/ricky/repo co test > > 3. Try to make a commit without it getting logged in > /home/fedora/ricky/repo/CVSROOT/commitlog > > Feel free to try clever/evil things to test this out. Update: Now it's slightly easier for some people to test this out. If you are in the packager group and you are not in any of sysadmin-main, sysadmin-test, sysadmin-noc, then you do not need to take any special action, you can just: cvs -d :ext:username at publictest10.fedoraproject.org/home/fedora/ricky/repo co test and test ctrl-cing commits. If you are in one of the three groups listed, you'll still have to follow the instructions to restrict your SSH command. Thanks, and please test! Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Apr 30 21:43:14 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 30 Apr 2009 16:43:14 -0500 (CDT) Subject: Preventing ctrl-c from blocking CVS commit messages In-Reply-To: <20090430213027.GD30691@sphe.res.cmu.edu> References: <20090423203025.GE20235@sphe.res.cmu.edu> <20090430213027.GD30691@sphe.res.cmu.edu> Message-ID: On Thu, 30 Apr 2009, Ricky Zhou wrote: > On 2009-04-23 04:30:25 PM, Ricky Zhou wrote: > > I'd appreciate if people can test and try to abuse/break this setup :-), > > so I have a test repo setup. To test this, you need to be in > > sysadmin-test: > > > > 1. Prepend your ~/.ssh/authorized_keys file on > > publictest10.fedoraproject.org with: > > > > command="/home/fedora/ricky/test.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty > > > > (make sure not to accidentally lock yourself out with this) > > > > 2. Checkout the test module with: > > cvs -d :ext:username at publictest10.fedoraproject.org/home/fedora/ricky/repo co test > > > > 3. Try to make a commit without it getting logged in > > /home/fedora/ricky/repo/CVSROOT/commitlog > > > > Feel free to try clever/evil things to test this out. > Update: Now it's slightly easier for some people to test this out. > > If you are in the packager group and you are not in any of > sysadmin-main, sysadmin-test, sysadmin-noc, then you do not need to take > any special action, you can just: > > cvs -d :ext:username at publictest10.fedoraproject.org/home/fedora/ricky/repo co test > > and test ctrl-cing commits. If you are in one of the three groups > listed, you'll still have to follow the instructions to restrict your > SSH command. > I was able to write the file and commit, I did ctl+c out of it after it hit the "Sleeping for 5 seconds bit" and my commit went through. I'm not quite sure what the intended behavior is, perhaps we should enable emails? Maybe you already did? -Mike From ricky at fedoraproject.org Thu Apr 30 23:39:49 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 30 Apr 2009 19:39:49 -0400 Subject: Preventing ctrl-c from blocking CVS commit messages In-Reply-To: References: <20090423203025.GE20235@sphe.res.cmu.edu> <20090430213027.GD30691@sphe.res.cmu.edu> Message-ID: <20090430233949.GE30691@sphe.res.cmu.edu> On 2009-04-30 04:43:14 PM, Mike McGrath wrote: > I was able to write the file and commit, I did ctl+c out of it after it > hit the "Sleeping for 5 seconds bit" and my commit went through. I'm not > quite sure what the intended behavior is, perhaps we should enable emails? > Maybe you already did? Sorry, my mistake. I made it log to /home/fedora/ricky/repo/CVSROOT/commitlog and I forgot to chgrp the file so that people in packager had write access to it. Could somebody in packager test this out now? Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: