about me and my experience
by Bhatt Niraj
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
14 years, 9 months
exim: SELinux
by Frank Chiulli
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
14 years, 9 months
Fedora Planet Spam
by Stephen John Smoogen
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
14 years, 9 months
New rule
by Mike McGrath
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
14 years, 9 months
Outage Notification - 2009-07-10 22:00 UTC and 2009-07-15 20:00 UTC
by Mike McGrath
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.
14 years, 9 months
bodhi 0.6.0 with EPEL support
by Luke Macken
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
14 years, 9 months
Why not Proxy with Nginx ?
by Jörg Stephan
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
14 years, 9 months
Meeting Log - 2009-07-09
by Ricky Zhou
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=as...
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/... -- 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
14 years, 9 months
Removed old logs from proxy2
by Stephen John Smoogen
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
14 years, 9 months