infrastructure July 2009

infrastructure@lists.fedoraproject.org

42 participants
66 discussions

about me and my experience
by Bhatt Niraj 14 Jul '09

14 Jul '09

Hi everyone, My self Niraj Bhatt, recently I joined fedora community. I completed master in computer science then RHCE and now preparing for RHCSS. I am working as Unix Administrator in Tata Consultancy Services (TCS). Right now I am handling 900+ servers. I have sound knowledge of apache, mysql, php, clustering, Load Balancer (BIG IP), LDAP and performance tunning. I want to becomes the part of fedora development so I joined this community. I am managing www.vglug.info (Linux User Group) web site. To promote open source I am taking seminar in colleges. -- Niraj Bhatt ------------------------------------------------------------ Give me space to stand, i will move the earth

2 2

marketing needs some input on a news platform
by Ian Weller 14 Jul '09

14 Jul '09

https://fedoraproject.org/wiki/FooBar#Platform_options What does Infrastructure think? We're currently leaning between using WordPress and piggybacking on Zikula. -- Ian Weller <ian(a)ianweller.org> GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36

2 1

exim: SELinux
by Frank Chiulli 14 Jul '09

14 Jul '09

This is a recently installed/patched F11 system. It was a fresh install to one disk leaving my home directory untouched on another disk. Today, I installed exim and removed sendmail via yum at the command line. I am using the same exim.conf file that I had used with F10 after having compared it to the original one. I am now receiving the following message when I attempt to retrieve mail from my ISP: Jul 12 14:26:36 flinux setroubleshoot: SELinux is preventing exim (exim_t) "getattr" boot_t. For complete SELinux messages. run sealert -l e699bb55-c0dc-4bbf-a57e-3d82d6dadcad sealert -l e699bb55-c0dc-4bbf-a57e-3d82d6dadcad Summary: SELinux is preventing exim (exim_t) "getattr" boot_t. Detailed Description: SELinux denied access requested by exim. It is not expected that this access is required by exim and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:system_r:exim_t:s0 Target Context system_u:object_r:boot_t:s0 Target Objects /boot [ dir ] Source exim Source Path /usr/sbin/exim Port <Unknown> Host flinux Source RPM Packages exim-4.69-10.fc11 Target RPM Packages filesystem-2.4.21-1.fc11 Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name flinux Platform Linux flinux 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun 16 23:19:53 EDT 2009 i686 athlon Alert Count 289 First Seen Sun Jul 12 14:22:12 2009 Last Seen Sun Jul 12 14:23:53 2009 Local ID e699bb55-c0dc-4bbf-a57e-3d82d6dadcad Line Numbers Raw Audit Messages node=flinux type=AVC msg=audit(1247433833.210:331): avc: denied { getattr } for pid=2508 comm="exim" path="/boot" dev=sda1 ino=2 scontext=unconfined_u:system_r:exim_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir node=flinux type=SYSCALL msg=audit(1247433833.210:331): arch=40000003 syscall=195 success=no exit=-13 a0=bfa2e2c2 a1=bfa2e6b8 a2=b7dbfff4 a3=0 items=0 ppid=2447 pid=2508 auid=500 uid=93 gid=93 euid=93 suid=93 fsuid=93 egid=93 sgid=93 fsgid=93 tty=(none) ses=1 comm="exim" exe="/usr/sbin/exim" subj=unconfined_u:system_r:exim_t:s0 key=(null) Any thoughts/suggestions? Thanks, Frank

5 7

Fedora Planet Spam
by Stephen John Smoogen 12 Jul '09

12 Jul '09

I am wondering if someone's blog got hacked.. or if we need to go over best use policies with people soon. http://uditsharma.in/?p=48 -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

2 1

New rule
by Mike McGrath 10 Jul '09

10 Jul '09

I'm going to document this somewhere, we talked about it on IRC a while back but I never sent an email to the list. Hot patching servers is bad! Don't do it! But if you _must_ do it for whatever reason, you _MUST_ open a ticket about it and leave it open until the hot patch is removed: https://fedorahosted.org/fedora-infrastructure/ticket/1524 -Mike

4 4

Outage Notification - 2009-07-10 22:00 UTC and 2009-07-15 20:00 UTC
by Mike McGrath 10 Jul '09

10 Jul '09

There will be two outages coming up. The first starting at 2009-07-10 22:00 UTC lasting for around 50-60 hours. The second outage starting at 2009-07-15 20:00 UTC and lasting up to 10 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-07-10 22:00 UTC' date -d '2009-07-15 20:00 UTC' Affected Services: Unaffected Services: Buildsystem CVS / Source Control Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Reason for Outage: RDU netapp syncing and tray installation. This isn't getting wide distribution because based on the settings in place today, it won't impact us. Our i2 mirror (of which this is part of it) is offline from other issues anyway and being worked on. More then anything this is a heads up. Soon our primary mirror system will go from 1T to upwards of 8T of usable storage. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage.

1 0

bodhi 0.6.0 with EPEL support
by Luke Macken 10 Jul '09

10 Jul '09

Hey all, I just deployed bodhi 0.6.0 to app1-6 and releng{2,1.stg}. This release contains patches from both Dennis Gilmore and myself to support pushing updates for EPEL. I just submitted my first EPEL update into bodhi, so things seem to be working properly so far. It should be safe to start queueing EPEL updates, and we'll try doing a small push early next week. Please file bugs here: https://fedorahosted.org/bodhi/newticket Thanks, luke

2 2

Why not Proxy with Nginx ?
by Jörg Stephan 10 Jul '09

10 Jul '09

Hi there, on the meeting yesterday i've heared from the proxy problems with apache + mod_proxy so i just wanne tell a bit from an other proxy which i set up a few weeks ago in firm. So talking about Nginx. In the firm i work we had problems with the many different URLs behind the old proxy and we come to an state were apache has been to slow. One of the main points why i looked for a different Software was the IP-Forward Problem we always had. So i found Nginx. Nginx is a very fast proxy http://wiki.nginx.org/Main and it comes with many modules to handle the connection. On the other hand it is very easy to use. So, take a short look: proxy_redirect off; proxy_set_header X-Real-IP $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffers 32 4k; this does all the IP-Forwarding and the (in this case webdav) is the configuration of the server server { listen 80; server_name isg-dav1.XX.XXXXX.de; access_log /var/log/nginx/localhost.access.log; error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/nginx-default; } location / { proxy_pass http://isg-dav.XXXX.XXXXX.de; include /etc/nginx/proxy.conf; } } So if any question, i try to answer them, Greets Joerg

3 6

Meeting Log - 2009-07-09
by Ricky Zhou 09 Jul '09

09 Jul '09

20:00 < mmcgrath> #startmeeting 20:00 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00 < zodbot> Meeting started Thu Jul 9 20:00:28 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 < mmcgrath> #topic Infrastructure -- Who's here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 < ggruener> ping 20:01 * tmz listens in for once 20:01 -!- notting [n=notting@redhat/notting] has joined #fedora-meeting 20:01 * johe waves 20:01 * SmootherFrOgZ is 20:01 -!- thomasj_ is now known as thomasj 20:01 * rjune_wrk lurks 20:01 -!- GeroldKa [n=GeroldKa@fedora/geroldka] has quit "Verlassend" 20:02 * dgilmore 20:02 < mmcgrath> k, lets get started 20:02 < mmcgrath> #topic Infrastructure -- tickets 20:02 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- tickets 20:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assi… 20:02 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:02 < ssmoogen> here 20:02 < mmcgrath> so 20:02 < mmcgrath> .ticket 1503 20:02 < mmcgrath> abadger1999: around? 20:02 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503 20:02 * nirik is here in the back. 20:03 -!- herlo [n=clints@fedora/herlo] has joined #fedora-meeting 20:03 -!- kolesovdv [n=kolesovd(a)82.162.141.18] has joined #fedora-meeting 20:03 * mmcgrath assumes he's not around 20:04 -!- ivana [n=varekova(a)ip-89-103-124-118.karneval.cz] has quit Read error: 110 (Connection timed out) 20:04 < mmcgrath> so 20:04 < abadger1999> mmcgrath: I'm here. Nothing new on this since last week. 20:04 * herlo is here for the infra meeting 20:04 < mmcgrath> abadger1999: oh, k. Sounds good. 20:04 < mmcgrath> #topic Infrastructure -- Proxy timeouts 20:04 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Proxy timeouts 20:04 < abadger1999> No one's objected, I guess we can ake it off of the meeting for a bit 20:04 -!- thekad [n=kad(a)187.142.23.8] has joined #fedora-meeting 20:05 < mmcgrath> So, after much debugging, testing, re-debugging. We determined the problem was a difference in how ProxyPass handles proxying and RewriteRule [P] handles proxying. 20:05 < mmcgrath> Annoying on all fronts 20:05 < mmcgrath> and was causing great issues. 20:05 < mmcgrath> but thing seem to have calmed down quite a bit. I'm going to re-run our metrics tests in a bit to see if we're back down to pre-merge levels. 20:06 < mmcgrath> anyone have any questions on that? 20:06 < ssmoogen> yes 20:06 < ssmoogen> what did we settle on 20:06 < ssmoogen> ProxyPass or RewriteRule 20:06 < mmcgrath> well, we're back to RewriteRule 20:06 < johe> what proxy do we use, if i may ask 20:06 < mmcgrath> which is what we were before the merge. 20:06 < abadger1999> Do we know what the difference is or just that they are different? 20:06 < mmcgrath> johe: apache + mod_proxy 20:07 < mmcgrath> abadger1999: well, according to a guy in #httpd there isn't one. 20:07 < abadger1999> hah 20:07 < mmcgrath> I suspect ProxyPass takes on some default values. 20:07 < ssmoogen> mmcgrath, hehehe 20:07 < johe> thought about nginx for proxy? 20:07 < mmcgrath> johe: people bring up $OTHER_PROXY all the time but no one's ever really been able to answer why it'd be worth moving to. 20:08 < mmcgrath> I think RewriteRule might either take on different timeout values then ProxyPass or maybe doesn't even have them and behaves in a more raw manner. 20:08 < mmcgrath> There were also some keepalive values we altered. 20:08 < johe> okay, we should discuss this later on :-) 20:08 < mmcgrath> johe: we can discuss it now if you want, if not now take it to the list. 20:09 < johe> i take it to the list 20:09 < dgilmore> johe: it is a fairly simple process we use 20:09 < mmcgrath> cool 20:09 < mmcgrath> Ok 20:09 < mmcgrath> sooo.... 20:09 * mmcgrath thinks. 20:09 < mmcgrath> #topic Infrastructure -- Databases 20:09 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Databases 20:09 < mmcgrath> So we continue to see some database issues 20:09 < mmcgrath> but the wiki outages seem to be gone 20:09 < mmcgrath> https://admin.fedoraproject.org/haproxy/proxy1/ 20:10 < mmcgrath> shows 0 downtime since the last haproxy reboot. 20:10 < mmcgrath> that's a very good thing. 20:10 < mmcgrath> The last outstanding issue seems to be with smolt. 20:10 < mmcgrath> now, this is something that came about after the merge, but I actually think we were having it before. 20:10 < mmcgrath> I think ricky disabled some caching that we were doing against smolt. 20:11 < mmcgrath> so even when it went down, nagios didn't notice because it kept pulling up the cached version. 20:11 < mmcgrath> There's still a few options we're investigating 20:11 < mmcgrath> mostly based around switching to innodb, changing how we do backups, and using different queries for render-stats 20:11 < mmcgrath> as render-stats seems to be the thing taking everything down 20:12 < thekad> mmcgrath I was talking with ricky about myisam->innodb last night, specifically about the host_links table 20:12 < ssmoogen> what does render-stats do? 20:12 < mmcgrath> ssmoogen: it generates - http://smolts.org/static/stats/stats.html 20:13 < mmcgrath> thekad: you have some experience with this? 20:13 < dgilmore> mmcgrath: i think innodb would be a helpful move 20:13 < mmcgrath> myisam vs innodb I mean 20:13 < mmcgrath> dgilmore: everything we've heard has said it will be a godo thing, except for when we actually go to do it. 20:13 < mmcgrath> importing from an innodb dump I think took 14 hours, vs les then 1 hour for myisam. 20:13 < thekad> mmcgrath, a bit, yeah, I was telling him that the amount of time that table takes to load doesn't sound like too far fetched 20:13 < mmcgrath> so we're worried about other impacts. 20:14 < thekad> load from a mysqldump I mean 20:14 < mmcgrath> thekad: will we see a similar slow down (more than n order of magnitude) for usage of the table? 20:14 < dgilmore> mmcgrath: you should be able to convert on the fly 20:14 < dgilmore> but not sure what effect that would have 20:14 < thekad> mmcgrath, that's possible, I was telling him to maybe run a couple tests with a tenth of the rows, then doubling it 20:15 < mmcgrath> dgilmore: we were trying, we never got through one, usually killed it around 20 hours 20:15 < thekad> mmcgrath, the thing is, all the sanity checks that you disable while loading it, are done during every transaction 20:15 < mmcgrath> thekad: so I think the general thought is we want to move to innodb, but we want to see what we're getting ourselves into :) 20:15 < dgilmore> mmcgrath: gahh ok 20:16 < mmcgrath> thekad: our understanding is innodb will be 'slower' then myisam. Do you know exactly what that means? 20:16 < mmcgrath> I know it's larger then myisam. 20:16 < mmcgrath> so i'd just assumed that extra time was just because it's reading more from the disks. 20:16 < dgilmore> mmcgrath: in some ways it will be quicker 20:16 < thekad> mmcgrath, innodb does some data integrity checks on every operation, myisam doesn't support FKs for example, so that brings an overhead 20:17 < dgilmore> since yu can do row level locking for updates 20:17 < mmcgrath> thekad: 'every operation' we talking writes or reads or both? 20:17 < dgilmore> so there could be multiple updates at ones 20:17 -!- JSchmitt [n=s4504kr@fedora/JSchmitt] has quit Remote closed the connection 20:17 < thekad> mmcgrath, writes, I mean update, insert, delete 20:17 < dgilmore> mmcgrath: i think he means writes here 20:17 < mmcgrath> thekad: how's it's read compare? 20:18 -!- than_home [n=than(a)p5B3FED8C.dip.t-dialin.net] has joined #fedora-meeting 20:18 < thekad> mmcgrath, almost the same, it degrades a bit because of the IO operations, but makes up for it by using indexes and other stuff innodb has 20:18 < thekad> so it should be mostly the same, if not a lil' bit faster 20:19 < mmcgrath> thekad: are there different indexing options we should look at for our larger tables? or do the types of indexes offered by myisam directly map to innodb indexes? 20:19 < ssmoogen> thekad my minimal reading was that if one needed to scale to mysql clustering.. innodb was needed. 20:19 < thekad> the clear advantage of using innodb is data integrity, if you don't mind about that too much, there's no real gain from innodb 20:19 < thekad> ssmoogen, that is correct 20:20 < thekad> mmcgrath, I think you can tweak them a little, may need to give some more reading about that though 20:20 < mmcgrath> k 20:20 < mmcgrath> thekad: well thanks for your help on that, please do stick around and help us through that transition. 20:21 < mmcgrath> right now ricky's got lead on that, i'm sort of just keeping tabs and testing from time to time. 20:21 < thekad> mmcgrath, there can be some more options such as clustering, sharding, master/slave, we can check them all and evaluate some more 20:21 < mmcgrath> Anyone have any questions on this before we move on? 20:21 < thekad> mmcgrath, ok 20:21 < mmcgrath> thekad: thanks 20:22 < mmcgrath> so withour merge outages and smolt, thats really about all I've been up to. 20:22 < mmcgrath> I'll open the floor 20:22 < mmcgrath> #topic Infrastructure -- Open Floor 20:22 < ssmoogen> my only question is how we can test to see how we spread the load 20:22 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:22 < mmcgrath> ssmoogen: well, I've done clustering in the past and we can do that if we have to :) 20:22 < mmcgrath> I'd like to avoid it though 20:23 < lmacken> So yeah, bodhi now supports EPEL. 20:23 < mmcgrath> lmacken: take it 20:23 < lmacken> It required more hacking than I expected, but the result makes bodhi much more flexible and gives me a much better idea of what is needed from the model in the upcoming bodhi rewrite. 20:23 < ssmoogen> mmcgrath, my only experience with mysql has been with spread out clusters :). If you have another app get another DB :).. which I usually thought was horse manure but was what the Mysql people I dealt with believed in 20:23 -!- tibbs [n=tibbs@fedora/tibbs] has quit "Konversation terminated!" 20:23 < ssmoogen> oh sorry.. 20:23 < lmacken> I also fixed a lot of other bugs in the process. 20:24 < lmacken> Also, I just updated the Bodhi SOP with details on how to push updates as well: https://fedoraproject.org/wiki/Bodhi_Infrastructure_SOP 20:24 < mmcgrath> ssmoogen: :) 20:24 < lmacken> that's all I got :) 20:24 < ssmoogen> thanks lmacken and dgilmore 20:24 < dgilmore> lmacken: thanks. 20:24 < ssmoogen> lmacken, does bodhi have workflows? 20:24 < abadger1999> Yay! 20:24 < mmcgrath> dgilmore: how have the pushes been going? 20:24 < ssmoogen> as in forcing people to push things into testing versus publish to production? 20:24 < dgilmore> lmacken: did we get the bug fixed preventing the summary email of testing updates being sent? 20:24 < lmacken> ssmoogen: not exactly, but Fedora Community will be putting those in place soon 20:25 < lmacken> dgilmore: yeah, I sent those out by hand last night 20:25 < dgilmore> mmcgrath: I have one issue i need to fix. all packages are getting touched on each update 20:25 < dgilmore> lmacken: ok ive not seen them 20:25 < mmcgrath> dgilmore: on the master mirror? 20:25 < mmcgrath> dgilmore: about how long does it take to do a push (both real time and actual person typing time) 20:25 < dgilmore> mmcgrath: yeah 20:26 < abadger1999> lmacken: Seems like the wrong layer... if it's just in Community, people can still circumvent it. 20:26 < dgilmore> mmcgrath: seems to take about 3-4 hours for a push. which is longer that the 30 minutes or so previously 20:26 < abadger1999> like cvs force tagging and our koji workflow 20:26 < lmacken> abadger1999: right, but the workflow layer has to encompass more than just bodhi (eg: cvs, koji, etc) 20:27 < mmcgrath> dgilmore: I've never actually gone through the bodhi process. Is it pretty intensive work for 3-4 hours? Or is it type a few things and go get some tea? 20:27 < abadger1999> <nod> As a whole... but the bottom layers ahve to support the locking down that we want to do at the top. 20:27 < lmacken> dgilmore: http://lists.fedoraproject.org/pipermail/epel-package-announce/2009-July/00… -- I may have accidently sent it to the package-announce-list by hand instead 20:27 < dgilmore> lmacken: i have to say anything workflow wise in fedora community feels like the wrong place for it 20:27 < dgilmore> lmacken: yep wrong list 20:27 < lmacken> well, propose something better :) 20:28 < lmacken> the plan for fcomm v2.0 was initially: workflows 20:28 < lmacken> I wanted to tackle security bug tracking in there as well as others 20:28 < dgilmore> lmacken: it all has to work without fedora community 20:29 -!- Southern_Gentlem [n=notfred@fedora/Southern-Gentleman] has quit Read error: 110 (Connection timed out) 20:29 < dgilmore> it can happen in community but it needs to work with koji,cvs,bodhi,pkgdb also 20:29 < lmacken> all of the workflows already work w/o it. 20:29 < lmacken> we're just making it easier 20:29 < dgilmore> lmacken: maybe i miss understood what your trying to do 20:29 < abadger1999> lmacken: Not in this case. In this case, we're trying to prevent people from doing something. 20:29 < abadger1999> lmacken: So that has to be enabled at the bottom layer. 20:30 < dgilmore> abadger1999: which in preventing things it needs to happen at the lowest level not the highest 20:30 < lmacken> anyway, we can take the workflow tangent elsewhere :) 20:30 < mmcgrath> yeah 20:31 < dgilmore> mmcgrath: real world doing things is about 30 minutes or so a push 20:31 < ssmoogen> hi guys.. I need a picture on both sides ... I sense people may be in violent agreement but IRC is not the medium to convey the pictures 20:31 < mmcgrath> dgilmore: k. 20:31 < lmacken> ssmoogen: agreed. we'll make sure to lay out a full roadmap for any workflow things we are thinking about attempting, and take everyones thoughts and suggestions into consideration beforehand 20:31 -!- GeroldKa [n=GeroldKa@fedora/geroldka] has joined #fedora-meeting 20:31 < dgilmore> alot of it is checking on what people are trying to push into stable 20:32 < dgilmore> mmcgrath: biggest issue so far is people pushing straight to stable 20:32 < lmacken> I'm going to try and get EPEL integrated into Fedora Community soon sa well 20:32 < ssmoogen> dgilmore, and hitting them with a stun gun when it isnt security :) 20:32 < dgilmore> and bypassing testing 20:32 < dgilmore> ssmoogen: right the only ones ive allowed though are security ones 20:32 < dgilmore> like mmcgrath's nagios packages 20:33 * nb|away is here but late 20:33 < mmcgrath> dgilmore: ah, the issue being that's not in the spirit of epel? 20:33 -!- nb|away is now known as nb 20:33 < dgilmore> mmcgrath: right 20:33 < abadger1999> These things need to get discussed here. we're looking at how to enforce policy on all of our apps... that needs to be talked about as a fedora infrastructure issue. 20:33 < dgilmore> it was something much more easily controlled in the old setup 20:34 < dgilmore> mmcgrath: i think i can do some work on bodhi to support epel policies better 20:34 < mmcgrath> yeah. 20:34 -!- Sonar_Guy [n=Who@fedora/sonarguy] has joined #fedora-meeting 20:34 < mmcgrath> I mean, at the end of the day we have to trust the packagers somewhat, but I'm sure there's somethign we can do. 20:35 < mmcgrath> abadger1999: so what are some bullet points we should hit? 20:35 -!- Southern_Gentlem [n=notfred@fedora/Southern-Gentleman] has joined #fedora-meeting 20:35 < ssmoogen> trust? humans? mmcgrath are you sure you are a system administrator? 20:35 < abadger1999> What's the policy we're trying to enforce? --dgilmore has ideas on that for EPEL. 20:35 < abadger1999> Do we also need enforcment for Fedora? 20:36 < mmcgrath> ah 20:36 < abadger1999> What apps need to change to enforce that workflow? -- for updates, that would be bodhi. 20:36 < ssmoogen> abadger1999, I have heard f13 would like it.. but I would take that to be a cultural thing 20:36 < dgilmore> abadger1999: all packages but security updates need to go through testing 20:36 < mmcgrath> in EPEL we have a good track record of "build" -> "testing" -> "stable" 20:36 < abadger1999> What UI do we want to put on top of that? Probably has Bodhi and Fedora Community changes. 20:36 < mmcgrath> but that's largely because of the man behind the scenes. 20:37 < dgilmore> mmcgrath: right it was easy to do with the old scripts 20:37 -!- than_home [n=than(a)p5B3FED8C.dip.t-dialin.net] has quit Read error: 110 (Connection timed out) 20:37 -!- than_home [n=than@nat/redhat/x-02ba6102c49f6b0c] has joined #fedora-meeting 20:38 < mmcgrath> dgilmore: what did you have in mind for it? 20:38 < dgilmore> we made packages lie in testing for between a week and just over a month 20:38 < mmcgrath> I mean, in EPEL, we could enforce "nothing but securty" if we wanted 20:38 < dgilmore> mmcgrath: automate moving things to testing if people try them in stable 20:39 < mmcgrath> lmacken: how painful would that be? 20:39 < mmcgrath> dgilmore: would that all be 'behind the scenes stuff'? 20:39 < dgilmore> and enforcing at least two weeks in testing without autokarma moving to stable 20:39 < mmcgrath> and if they wanted somethign pushed to testing, would it stay there until they push it to stable? 20:39 < dgilmore> mmcgrath: i think it needs to be 20:39 < mmcgrath> abadger1999: how's that work now, do you know? 20:40 < dgilmore> mmcgrath: right, it would stay in testing until moved to stable 20:40 < lmacken> mmcgrath: to enforce testing except for security updates? bodhi /used/ to do that, but I made it configurable after many complaints 20:40 < dgilmore> but we should make it in testing two weeks without karma 20:40 * mmcgrath suspects this doesn't seem to need any UI changes in bodhi 20:40 < mmcgrath> am I right on that? 20:40 -!- Sonar_Guy [n=Who@fedora/sonarguy] has quit "Leaving" 20:41 < ssmoogen> dgilmore, your description of wait/karma was exactly what I was hoping for from bodhi 20:41 < lmacken> right, but it may need some backend tweaks depending on what poly we want to enforce 20:41 < abadger1999> More error messages, maybe some documentation that there's limits in place 20:41 < dgilmore> lmacken: i think we could do it all with the client when running admin tasks 20:41 -!- giallu [n=giallu@fedora/giallu] has joined #fedora-meeting 20:41 < lmacken> dgilmore: cool 20:42 < dgilmore> lmacken: to give us the list of packages that we want to push 20:42 < abadger1999> Maybe take out the ability to select "stable" when creating an update. 20:42 < dgilmore> abadger1999: unless its a security update 20:42 < abadger1999> dgilmore: Isn't that what security is for? 20:43 < abadger1999> ie: testing/security instead of testing/stable/security 20:43 < dgilmore> abadger1999: well the bugzilla security update was only requested to go to testing 20:44 < dgilmore> abadger1999: the type of update is different to the location 20:44 < dgilmore> but maybe we can tweak that and add some policy support to bodhi 20:44 < abadger1999> Hmm.. in Fedora, I know I've flagged an update as security and then the security team reviews it and pushes it to stable... no matter whether I selected testing or stable initially. 20:44 < dgilmore> that way epel can have one set of rules and Fedora another 20:45 < abadger1999> But perhaps that's the particular person who handled that security update rather than policy. 20:45 < dgilmore> abadger1999: the security team doesnt look at epel 20:45 < dgilmore> at least not yet 20:45 < abadger1999> <nod> 20:45 -!- Sonar_Guy [n=Who@fedora/sonarguy] has joined #fedora-meeting 20:45 < abadger1999> but the policies of epel and fedora only diverge when explicitly stated. 20:45 < dgilmore> abadger1999: pushing policy is one of them 20:46 < abadger1999> <nod> 20:46 < mmcgrath> Ok, so I think we're generally in agreement about what all has to happen. 20:46 < mmcgrath> is this all blocking on luke to get it done? 20:46 < dgilmore> mmcgrath: :) right 20:46 < mmcgrath> lmacken: what would you need? 20:46 < lmacken> mmcgrath: tickets saying exactly what you guys want to happen :) 20:46 < dgilmore> mmcgrath: it will need his help. but im going to work on what i can 20:46 < mmcgrath> ok 20:47 < mmcgrath> well, not to take up the rest of the meeting with that, anything else to discuss on that topic? 20:47 < ssmoogen> lmacken, how can I help 20:48 < lmacken> ssmoogen: I'm not sure yet, we need to figure out exactly what needs to get done first 20:48 -!- itamarjp [n=itamar(a)189-015-126-186.xd-dynamic.ctbcnetsuper.com.br] has quit Remote closed the connection 20:48 < mmcgrath> dgilmore: you ok being on ticket patrol? Getting which ones need to be created and creating them? 20:48 < dgilmore> mmcgrath: :) sure 20:48 < mmcgrath> Ok, well if there's nothing else on that topic 20:48 < mmcgrath> anyone have anything else while the floor is open? 20:48 < nb> blogs.fp.org is going pretty well, basically everything is ready I believe except for we are blocking on FAS integration. FWIW, I'd rather stick with our original solution of letting people sign up, as long as they use a @fedoraproject.org email address, as wordpress-mu is not that cooperative with authentication plugins, but we'll keep working on it. 20:48 < ssmoogen> lmacken, ok let me know how I can help test and document... and I will do the best I can 20:49 < lmacken> ssmoogen: will do :) 20:49 -!- cassmodiah [n=cass@fedora/cassmodiah] has joined #fedora-meeting 20:50 < nb> we have a plugin that nigel made, but for some reason it keeps letting everyone in as long as they have a cla_done username, no matter if the password is correct or not 20:50 < mmcgrath> nb: what seems to be the problem? 20:50 < mmcgrath> interesting 20:50 < mmcgrath> and hilarious ;) 20:50 < nb> yeah 20:50 < mmcgrath> is it ignoring the json response or something? 20:50 < nb> not sure, i havent looked into it much, nigel couldn't figure out what was wrong the other night 20:51 * nb hopes to look at it some today 20:51 -!- rishi [n=rishi@gnu-india/supporter/debarshi] has quit Read error: 110 (Connection timed out) 20:51 < mmcgrath> nb: excellent. thanks for the roundup. 20:51 < mmcgrath> Anyone have anything else? 20:51 < nb> its /usr/share/wordpress-mu/wp-content/mu-plugins/fasauth.php if anyone knows much about php and fas 20:51 < nb> on publictest15 20:51 -!- nim-nim [n=nim-nim@fedora/nim-nim] has joined #fedora-meeting 20:52 < mmcgrath> nb: might be good to hit up the f-i-l 20:52 < nb> good idea 20:52 < mmcgrath> Ok, if no one has anything else we'll close the meeting in 30 20:52 < tmz> something fairly minor, we occassionally get folks having permission problems with git repos on hosted. 20:52 < abadger1999> nb: I looked briefly the other day -- couldn't figure out which methods it was calling when it verified the password though. 20:53 < ssmoogen> my only statement is that I am still catching up and hopefully will be promoted to ricky's assistant soon 20:53 < mmcgrath> tmz: what was the latest? 20:53 < tmz> I think I've found and fixed the last of the current problems causing those. but to ensure they don't come back, I think a cron job to check for a few common problems might be good. 20:53 < mmcgrath> ssmoogen: :) 20:53 < tmz> mmcgrath: the latest one was docs/install-guide and docs/release-notes. 20:54 < tmz> both lacked the core.sharerepository setting. 20:54 < mmcgrath> were they created incorrectly? 20:54 < tmz> and that cause the reflogs to have the wrong perms. 20:54 < mmcgrath> <nod> 20:54 < tmz> I'm guessing they were creating without either --shared option to git init, or cloned and then the sharerepository option never set. 20:55 < tmz> the setup scripts should keep this from happening on new repos. 20:55 < mmcgrath> <nod> 20:56 < mmcgrath> Ok, things are quiet :) 20:56 < mmcgrath> tmz: thanks for that. 20:56 < mmcgrath> if no one has anything else I'll close in 30 20:56 < mmcgrath> 10 20:56 < mmcgrath> #endmeeting 20:56 -!- zodbot changed the topic of #fedora-meeting to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule 20:56 < zodbot> Meeting ended Thu Jul 9 20:56:53 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:57 < zodbot> Minutes: http://tinyurl.com/ng4xmx 20:57 < mmcgrath> Thanks everyone! 20:57 < zodbot> Minutes (text): http://tinyurl.com/nhtce2 20:57 < zodbot> Log: http://tinyurl.com/lc8v5k

1 0

Removed old logs from proxy2
by Stephen John Smoogen 08 Jul '09

08 Jul '09

Found out that majority of space being used was /var/log/httpd and most were in the /admin.fedoraproject.org-access.log.* ones. Checked with mmcgrath about removing old ones and got ok. Confirmed on log1 that the logs were copied over and removed /var/log/httpd/admin.fedoraproject.org-access.log.2009-06-26 /var/log/httpd/admin.fedoraproject.org-access.log.2009-06-27 /var/log/httpd/admin.fedoraproject.org-access.log.2009-06-28 disk space moved to 22% free. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure July 2009