infrastructure April 2009

infrastructure@lists.fedoraproject.org

49 participants
51 discussions

hi, i newly joined fedora infrastructure group
by p sena 17 Sep '10

17 Sep '10

Hi, I am new to the fedora infrastructure group. I am going throug few of the links in the site to get a feel of the work. I have submitted my .ssh_rsa_key.pub from the site. I think I will get some intimation on this. Please someone can let me know further proceedings from here onwards. Cheers. Regards & Thanks Prabir Senapati mailto: senapati2001(a)yahoo.com

3 5

hosts for rawhide build chroots - different rpm versions?
by Axel Thimm 05 Oct '09

05 Oct '09

Hi, 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. Thanks! -- Axel.Thimm at ATrpms.net

3 5

Hello, My intro
by Chris Johnson 18 Sep '09

18 Sep '09

Hi all, I've been lurking on the mailing list for a while and I finally registered for my fedora account today (username: chrisj) I'm interested in helping out as time permits. I got on irc once (lurking again) and haven't really logged in since. I'll try to make a few meetings after the holidays I'm planning to get my personal test systems setup soon. I just moved and still getting things straight at home. Bought a 750GB drive last night and will be installing F10 over the weekend. I had been running the U... distro and it's time to get back to the fedora/RH rpm way of doing things :-) I've used RedHat since before Fedora existed (I think 6 was the first one). Started as a hobbyist, 2 years. Then got a job as an admin and have been doing Linux admin and Cisco networks for the last 5 years. My current employer is a Win shop so I just get to run the DNS, email, and network, but the network is 50 remote offices and 3 different data centers in the midwest. I don't mind the Windows too much and can find my way around them, it's also kinda fun to get the Linux and MS products to play nice together. I've worked with a lot of different linux and OSS software products including: postfix, openldap, apache, bind, samba, mailman, pam, built some custom rpm's, etc. I use RHEL mostly at work and some fedora and Cent for testing (some suse, deb, and slackware in the past). I used to do lots of security firewall apliances with various linux distros (I was a big fan of LRP when it would fit on a floppy), most of this is now done with Cisco in my world. I can shell script pretty well and I've written several perl scripts in the last few years (dabbled in php but not enough to know it well). I've always been interested in python but don't have much if any exp with it. I also don't have much experience with SQL/DB or source control. I was looking at the FIGs and would be interested in the base sysadmin and sysadmin-noc for now while I figure out where everything is and what it does. I'm also interested in more info on the sysadmin-tools and sysadmin-web FIG. So, next just apply for the FIGs, keep lurking, ask some questions, show up for IRC meetings? Thanks all, -- Chris Johnson ++++++++++ j.chris.johnson(a)gmail.com ++++++++++++++++++++

2 2

RFR: triageweb
by Brennan Ashton 31 May '09

31 May '09

==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

3 4

Preventing ctrl-c from blocking CVS commit messages
by Ricky Zhou 06 May '09

06 May '09

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@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

3 5

Any C coders want to help me with something?
by Mike McGrath 02 May '09

02 May '09

Any C coders want to help me with a pam module? -Mike

10 35

Re: Statistics problem
by Paul W. Frields 01 May '09

01 May '09

On Mon, Apr 27, 2009 at 07:43:01PM -0800, Jeff Spaleta wrote: > On Mon, Apr 27, 2009 at 6:30 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote: > > On Mon, Apr 27, 2009 at 6:26 PM, Paul W. Frields <stickster(a)gmail.com> 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

5 15

Meeting Log - 2008-04-30
by Ricky Zhou 30 Apr '09

30 Apr '09

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(a)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@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(a)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@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@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@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: <nod> 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> <nod> 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@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@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(a)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(a)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@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 :) <lets out evil laugh> 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(a)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@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@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@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/msg00…) 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

1 0

Bit flip
by Mike McGrath 29 Apr '09

29 Apr '09

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

6 11

Half hour downtime
by Mike McGrath 28 Apr '09

28 Apr '09

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

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure April 2009