Meeting Log - 2010-01-14

[Ricky Zhou]

20:01 < mmcgrath> .startmeeting Infrastructure
20:01 < mmcgrath> Who's here?
20:01 -!- belegdol [n=belegdol at fedora/belegdol] has joined #fedora-meeting
20:01  * wzzrd is here
20:01  * nirik hands mmcgrath a #
20:01  * sijis is here
20:01 < PhrkOnLsh> mind if i watch the show?
20:01 -!- a-k [n=akistler at 2002:6390:aba9:3:20d:56ff:fe10:bb8d] has joined #fedora-meeting
20:02 < mmcgrath> PhrkOnLsh: not at all
20:02 < nirik> mmcgrath: you want #startmeeting there, not .startmeeting. ;)
20:02 < mmcgrath> #startmeeting Infrastructure
20:02 < zodbot> Meeting started Thu Jan 14 20:02:37 2010 UTC.  The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:02 -!- zodbot changed the topic of #fedora-meeting to:  (Meeting topic: Infrastructure)
20:02 < mmcgrath> damnit
20:02 < mmcgrath> Who's here?
20:02  * a-k is
20:02  * wzzrd is here
20:02  * nirik is hanging around in the back
20:02 -!- _lmr_ [n=lmr at 187.64.216.6] has joined #fedora-meeting
20:02  * PhrkOnLsh .
20:02  * skvidal is here
20:03 < mmcgrath> Ok, lets get started
20:03 < mmcgrath> #topic Infrastructure -- Tickets
20:03 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets (Meeting topic: Infrastructure)
20:03 < mmcgrath> Looks like no meeting notes so that's good.
20:03 < mmcgrath> I'll go over just a couple of things that happened this week worth mentioning
20:03 < mmcgrath> #topic Fedora hosted
20:03 -!- zodbot changed the topic of #fedora-meeting to: Fedora hosted (Meeting topic: Infrastructure)
20:04 < mmcgrath> hosted got it's new memory replaced.
20:04 < mmcgrath> it wasn't as smooth as it could have been but it did get done and within the outage window time.
20:04 < mmcgrath> #topic SPOF for koji and bastion
20:04 -!- zodbot changed the topic of #fedora-meeting to: SPOF for koji and bastion (Meeting topic: Infrastructure)
20:04 < mmcgrath> koj and bastion are still SPOF right now.
20:04 -!- mdomsch [n=Matt_Dom at cpe-70-124-57-11.austin.res.rr.com] has joined #fedora-meeting
20:04 < mmcgrath> mostly because we've not re-configured heartbeat.
20:04 < mmcgrath> but I'm also trying to re-think our vpn setup.
20:04 < mmcgrath> to be more robust with outage scenarios.
20:05 < mmcgrath> not allowing outbound udp makes that difficult.
20:05 < mmcgrath> though I suspect specific outound udp requests could be allowed.
20:05 < mmcgrath> #topic /mnt/koji
20:05 -!- zodbot changed the topic of #fedora-meeting to: /mnt/koji (Meeting topic: Infrastructure)
20:05 < dgilmore> im waiting on the try-n-buy to be approved
20:05  * ricky is here for a bit
20:05 < mmcgrath> So this one's kind of happened behind closed doors, not intentional just lots of "do you think this would work?"  "how much budget?" etc, etc.
20:06 < mmcgrath> but yeah, dgilmore's been working on trying to get what will be the new /mnt/koji
20:06 < mmcgrath> and I've been working to figure out what will be the new backup of /mnt/koji.
20:06 < mmcgrath> this is all good for several reasons.
20:06 < mmcgrath> 1) it'll allow us to use all of our tapes for *everything* else and do daily, weekly and monthly backups as we should be doing.
20:06 < skvidal> mmcgrath: what's the plan for the storage for the backup? Still tape or are you switching to disks?
20:06 < mmcgrath> 2) /mnt/koji will hopefully be much faster.
20:07 < mmcgrath> skvidal: switching to disks.  I'm hoping we'll be able to make snapshots of it for testing.
20:07 < mmcgrath> but dgilmore and I also talked about using bacula to backup to disk.
20:07 < mmcgrath> in the end though I think it will be a better solution because if /mnt/koji does die right now a horrible death.
20:07 < mmcgrath> it'd take a long time to get a new /mnt/koji up
20:07 < mmcgrath> whereas if we have disks to backup to I think the impact would be lessoned.
20:08 < mmcgrath> I do, however, have concerns just because it's so easy to wipe disks.
20:08 < dgilmore> mmcgrath: i agree
20:08 < mmcgrath> blowing away the /mnt/koji backup right now is a significantly more difficult task I think.
20:08 < mmcgrath> but at the end of the day I think it'll be worth it to us.
20:09 < mmcgrath> we'll be spending something like 5X what we spent for the /mnt/koji now so hopefully it'll all work out :)
20:09 < mmcgrath> ehh actually that's not quite true, probably closer to 4X
20:09 < mmcgrath> but still.
20:09 < dgilmore> and ive requested extra budget for next yera to grow it and hopefully help it more
20:09 < mmcgrath> here's to hoping it's all fast and usable and safe and backed up :)
20:09 < mmcgrath> anyone else have any questions or concerns on that?
20:10 < mmcgrath> alllrighty
20:10 < mmcgrath> #topic ssh_known_hosts
20:10 -!- zodbot changed the topic of #fedora-meeting to: ssh_known_hosts (Meeting topic: Infrastructure)
20:10 < mmcgrath> smooge: around to talk about this?
20:11 < mmcgrath> the smooge is likely busy :)
20:11 -!- walters [n=walters at nat/redhat/x-dtvgzmjuntdndbxu] has quit Remote closed the connection
20:11 < mmcgrath> After the move our ssh_known_hosts got way out of wack and instead of fixing it, he's been redoing it from scratch
20:11 < mmcgrath> and including more possible names so it should be even more useful then it was.
20:11 < smooge> here
20:11 < smooge> sorry
20:11 < smooge> one sec
20:11 < mmcgrath> smooge: no worries, just wanted a quick blurb about ssh_known_hosts so people know we're working on it.
20:12 < mdomsch> do our shells automatically use it, or do we need to do something in .ssh/config for it?
20:12 < smooge> ok sorry. I have updated ssh_known_hosts to all systems I could find in DNS and
20:12 < mmcgrath> mdomsch: they'd use it automatically but you should remove your .ssh/known_hosts
20:12 < smooge> removed ones that were no longer available
20:12 < mmcgrath> mdomsch: worst case, you'll get a conflict in known_hosts and you can just remove it.
20:12 < mdomsch> ok
20:12 -!- DraZoro1 [n=CT at vc-41-18-142-115.umts.vodacom.co.za] has joined #fedora-meeting
20:13 < smooge> I have tested it on app01.stg and was able to go to hosts inside fedora. I have commited and pushed
20:13 < mmcgrath> but the search order is ~/.known_hosts then /etc/ssh/ssh_known_hosts
20:13 < smooge> The only things that aren't in it are IPV6 addresses
20:13 < mmcgrath> smooge: excellent, thanks.
20:13 < mmcgrath> smooge: have you updated the SOP to match the new search order?
20:13 < smooge> new search order?
20:13 < smooge> and which SOP
20:13 < dgilmore> thats the default search order
20:13 < mmcgrath> http://fedoraproject.org/wiki/Infrastructure/SOP/ssh_known_hosts
20:14 < mmcgrath> smooge: I think right now we just have short hostname, and actual IP of the host.
20:14 < smooge> ah ok will fix
20:14 < mmcgrath> in the SOP I mean, you expanded on that so it'd be good to get it in the example :)
20:14 < mmcgrath> smooge: thanks
20:14 < mmcgrath> Ok, any other questions on that?
20:14 -!- fedbot [n=supybot at scrye.com] has quit Remote closed the connection
20:14 < mmcgrath> zodbot: hey look, fedbot's a big quitter.
20:14 < mmcgrath> ok
20:14 < mmcgrath> #topic Search Engine
20:14 -!- zodbot changed the topic of #fedora-meeting to: Search Engine (Meeting topic: Infrastructure)
20:14 < mmcgrath> a-k: take it!
20:14 -!- fedbot [n=supybot at scrye.com] has joined #fedora-meeting
20:15 < a-k> The two search candidates I wanted to put in public test are Xapian and Nutch
20:16 < a-k> Xapian installed fine and crawled the wiki for 90 minutes, then died
20:16 < a-k> I think it's fixable, so I still have some hope for Xapian
20:16 < mmcgrath> a-k: has the pt instance worked out for you so far?
20:16 < a-k> For Nutch, I've got Tomcat installed, but not configured yet
20:16 < a-k> This is pt3, BTW
20:16 < a-k> I haven't checked if Tomcat's ports are open
20:16 < mmcgrath> If you need more ram or disk let me know, sometimes we're stuck but sometimes not
20:16 < a-k> Yeah, pt is working fine
20:16 < a-k> I intended to reverse proxy Tomcat through Apache, so no need for extra open ports
20:16 < mmcgrath> a-k: I've never used any of them, what are the key differences?
20:17 -!- mchua is now known as mchua_afk
20:17 < a-k> Xapian is pretty flexible and customizable, so the custom keyword requirement should be satisfied, wherever that goes
20:17 < mmcgrath> then died a good death or a bad death?
20:17 < a-k> Nutch is very pre-packaged, so not so flexible
20:17 -!- DraZoro1 [n=CT at vc-41-18-142-115.umts.vodacom.co.za] has left #fedora-meeting []
20:17 -!- belegdol [n=belegdol at fedora/belegdol] has left #fedora-meeting ["Leaving"]
20:17 < a-k> Xapian didn't like a long URL, plus it may not like non-UTF8 so much
20:18 < mmcgrath> ahhh
20:18 < mmcgrath> interesting
20:18 < a-k> The URL thing I think is fixable with how I do the crawl
20:18 < mmcgrath> <nod>
20:18 < a-k> Plus, I still intend to keep looking at other candidates on my list
20:18 < mmcgrath> maybe not the non-UTF8 thing though huh?
20:18 < a-k> So these aren't necessarily the only two choices
20:18 < mmcgrath> sure
20:18 < abadger1999> Both java solutions?
20:18  * mmcgrath is happy to hear progress is being made.
20:19 < dgilmore> a-k: did we look at the one archive.org uses
20:19 < dgilmore> ?
20:19 < a-k> Yeah, UTF-8 could be the thing that kills most of the candidates, if that's going to be a real requirement
20:19 < mmcgrath> a-k: yeah what was the wiki link again?
20:19 < skvidal> why wouldn't utf-8 be a real requirement?
20:19 < a-k> dgilmore: archive.org uses arhiving, not indexing
20:19 < abadger1999> Or xapian is the C++ solution.  /me was thinking lucene.
20:19 < mmcgrath> skvidal: I think non-utf-8 is the possible requirement
20:20 < a-k> .link http://fedoraproject.org/wiki/Infrastructure/Search
20:20 < a-k> #link http://fedoraproject.org/wiki/Infrastructure/Search
20:20 < mmcgrath> a-k: thanks
20:20 < dgilmore> a-k: they have a crawler http://crawler.archive.org/
20:20 < a-k> Xapian is C, with a little Perl
20:20 < a-k> Nutch is Java, hence Tomcat
20:21 < a-k> dgilmore: I can look at archive.org again
20:21 < a-k> I think that's it, unless there are more questions
20:21 < mmcgrath> a-k: just because I know people will ask, can you make sure that those that have been eliminated have a specific "eliminated because: " section?
20:21 -!- dhillon-v10 [n=dhillon- at 66.222.202.68.cfl.res.rr.com] has joined #fedora-meeting
20:22 < a-k> I can do that
20:22  * nirik wonders if any solutions here will tie into the mailman/lists archives?
20:22 < smooge> eliminated because: It kills kittens and makes you eat them
20:22 < nirik> to replace pipermail.
20:22 < smooge> why would a search engine replace pipermail?
20:22 -!- rishi [n=rishi at gnu-india/supporter/debarshi] has joined #fedora-meeting
20:22 < skvidal> smooge: he means a new archiver
20:23 < skvidal> nirik: I don't think any of the others are any more maintained
20:23 < mmcgrath> a-k: if you want additional help feel free to ask on the list and recruit :) This is a pretty massive project.   Especially for your first one for Fedora.  If you need anything feel free to ask :)
20:23 < a-k> Sure.  Thanks.
20:23 < mmcgrath> anyone have anything else right now?
20:23 < nirik> sure, personally I think pipermail is ok, but there is a ticket wanting us to replace it with monharc or something.
20:24  * dgilmore is ok with pipermail
20:24 < skvidal> nirik: mhonarc is more trouble than its worth, ime
20:24 < skvidal> mmcgrath: logging? anyone interested in working on it?
20:24  * nirik nods. perhaps 3.0 will come out someday with pipermail improvements. 
20:25 < wzzrd> I'm kinda working on it, fwiw
20:25 < skvidal> nirik: perhaps monkeys will fly out of my arse
20:25 < smooge> skvidal, I am interested in doing it
20:25 < wzzrd> the logging that is
20:25 < smooge> I was starting to do it after I finished DNS/NTP
20:25 < mmcgrath> skvidal: sure
20:25 < mmcgrath> #topic logging
20:25 -!- zodbot changed the topic of #fedora-meeting to: logging (Meeting topic: Infrastructure)
20:25 < smooge> wzzrd, what are you doing
20:25 < skvidal> smooge: okay
20:25 < smooge> skvidal, what did you see
20:26 < skvidal> there are a number of things to work on
20:26 < mmcgrath> So logging is a pretty large topic with lots of sub parts
20:26 < skvidal> first - cleaning up the logs we have
20:26 < smooge> skvidal, or would I be too many cooks
20:26 < mmcgrath> lets start on what I gave wzzrd a week or two back.
20:26 < skvidal> okay
20:26 < mmcgrath> which is log analysis.
20:26 < skvidal> which is the wrong place to start
20:26 < mmcgrath> wzzrd: have you had a chance to look at some of the suggestions on th elist?
20:26 < skvidal> until you have logs under control
20:26 < mmcgrath> skvidal: none of which will get done while this meeting is going on :)
20:27 < wzzrd> i've checked out epylog a bit further
20:27 < skvidal> umm - if you don't want to discuss logging, that's fine
20:27  * skvidal is sorry for making the meeting longer
20:27 < mmcgrath> skvidal: keep  your pants on we're talking about logging right now, I'm just trying to do so in a way that doesn't discourage wzzrd, a new potential sysadmin member.
20:28 < mmcgrath> wzzrd: any luck with it?
20:28 < wzzrd> but i want to raise the matter of realtime parsing vs. cron-based once-a-day parsing, before i dive into something head over heels
20:28 < mmcgrath> I have very little experience with it but I know skvidal has used it as has Jeff_S and some others.
20:28 < mmcgrath> I don't think we need realtime parsing at this time.
20:28 < skvidal> wzzrd: realtime parsing and analysis are seldom done by the same tool
20:28 < mmcgrath> at least I don't think it would buys us much.
20:29 < wzzrd> epylog is nice, but i think it woulde require the logs from a group of servers going into *one* file on the loghost if you want a single report for that group
20:29 < skvidal> wzzrd: and realtime parsing is handy if there are specific triggers you know to look for - but only useful insofar as they can raise a warning in nagios
20:29 < mmcgrath> but yeah, I haven't heard anyone really argue for realtime so we can just assume non-realtime for the moment :)
20:29 < wzzrd> mmcgrath, skvidal: ok, no real-time
20:29 < wzzrd> just making sure
20:29 < mmcgrath> epylog can't look at multiple files?
20:29 < skvidal> mmcgrath: yes, it can - but it requires editingits configs
20:29 < skvidal> mmcgrath: remember what I was saying on the infrastructure list about mimicing the file structure of /var/log
20:30 < skvidal> mmcgrath: I wasn't making that up :)
20:30 < mmcgrath> skvidal: just edits though?  not like some crazy bastadrization?
20:30 < skvidal> mmcgrath: significant edits
20:30 < mmcgrath> skvidal: I still have no idea what you're talking about with that?
20:30 < skvidal> look in /var/log on your laptop/desktop
20:30 < mmcgrath> you mean I should have a /var/log/messages that has all messages from all of our hosts going int o it?
20:30 < skvidal> no
20:30 < mmcgrath> so I should have a /var/log/hosts/bastion/messages?
20:30 < mmcgrath> I know what is in /var/log/ on my laptop
20:30 < skvidal> you understand there are certain files that commonly exist in /var/log
20:30 < skvidal> good
20:30 < mmcgrath> yeah?
20:31 < mmcgrath> like funcd
20:31 < mmcgrath> which won't exist on log1
20:31 < skvidal> and those files are expected to havecontent consistentwith a lot of log parsers
20:31 < wzzrd> skvidal: epylog.conf doesn't allow it afais, and I don't think it comes with a module that allows for the parsing of multiple files
20:31 < skvidal> funcd doesn't log via syslog in that way
20:31 < mmcgrath> isn't that creating just the opposite of what wzzrd is talking about though?
20:31 < skvidal> wzzrd: It really does.
20:31 -!- mether [n=Rahul at 115.240.11.90] has joined #fedora-meeting
20:31 < skvidal> mmcgrath: no
20:31 < mmcgrath> you're talking about creating more files and he's needing less
20:31 < skvidal> no
20:31 < skvidal> I'm not
20:31 < skvidal> if y'all would let me explain
20:32 < skvidal> instead of peppering me with remarks
20:32 < skvidal> It might help
20:32  * wzzrd shuts up
20:32 < skvidal> we want logs per-host
20:32 < skvidal> but we also want logs per-by-service/group
20:32 < skvidal> so let's say all of the app servers belong to the appgroup
20:33 < skvidal> we can setup rsyslog so that if a log comes in from app01 (for example) that it gets sent to /var/log/hosts/app01/2010/01/14/ AND to /var/log/groups/app-servers/2010/01/14
20:33 < skvidal> then if we want to do log analysis for the appservers we tell epylog to look at /var/log/groups/app-servers/2010/01/14
20:34 < skvidal> if we want it to do analysis for a specific app server we tell it to look at: /var/log/hosts/app01/2010/01/14/
20:34 < mmcgrath> epylog doesn't understand /var/log/hosts/app* ?
20:34 < skvidal> inside each of those dirs will be the syslog files normally generated by /var/log
20:35 < skvidal> mmcgrath: not when it is parsing log files - it expects the log files to be in the normal location relative to the base log path
20:35 < mmcgrath> I guess I'm not understanding how what is in my laptop in /var/log isn't what's in /var/log/hosts/app01/2010/01/14
20:35 < skvidal> okay
20:35 < skvidal> let's look at an example
20:36 < skvidal> login to bastion
20:36 < skvidal> cd /var/log
20:36 < skvidal> ls *log
20:36 < skvidal> ls *log
20:36 < skvidal> anaconda.log     boot.log  ha-log   ldirectord.log  sa-update.log  yum.log
20:36 < skvidal> anaconda.syslog  faillog   lastlog  maillog         tallylog
20:37 < skvidal> the files syslog is writing are the only ones we can deal with for a remote logging server
20:37 -!- mbonnet_ [n=nmikeb at nat/redhat/x-mffdfhflbfhsdlsy] has quit "Getting off stoned server - dircproxy 1.2.0"
20:37 < skvidal> so messages, maillog, spooler, boot.log and cron
20:37 < skvidal> that's all we have access to
20:37 -!- ajax_ [n=ajackson at nat/redhat/x-dufagrlcirofytgc] has joined #fedora-meeting
20:37 < skvidal> now
20:37 -!- ldimagg__ [n=ldimaggi at nat/redhat/x-raflashvigxdpfbm] has joined #fedora-meeting
20:37 < skvidal> if you look on log1
20:37 -!- pjones [n=nnnnnnnn at fedora/pjones] has quit Read error: 54 (Connection reset by peer)
20:37 < skvidal> in
20:37 < skvidal> /var/log/hosts/bastion01/2010/01/14
20:37 < skvidal> for example
20:37 -!- halfline_ [n=rstrode at nat/redhat/x-orzrcxfjwbumvjdj] has joined #fedora-meeting
20:37 -!- ldimaggi___ [n=ldimaggi at nat/redhat/x-iylrghkpugcssyrv] has joined #fedora-meeting
20:37 < skvidal> cron.log  kernel.log  mail.log  messages.log  secure.log
20:37 < skvidal> you have all of those files
20:37 -!- ajax__ [n=ajackson at nat/redhat/x-ciqdvigcdiekghja] has joined #fedora-meeting
20:38 < skvidal> do you see how those files do not match the filenames and separation that are normally in /var/og?
20:38 -!- mbonnet_ [n=nnmikeb at nat/redhat/x-kjygxqitpvxutbom] has joined #fedora-meeting
20:38 < skvidal> ie mail.log vs maillog
20:38 < skvidal> kernel.log existing AT ALL
20:38 < skvidal> messages.log vs messages
20:38 < smooge> oi
20:38 < mmcgrath> yeah, so you're talking, mostly, about renaming the files?
20:38 < skvidal> that's what I mean by the difference
20:38 < mmcgrath> k
20:38 < skvidal> mmcgrath: and what content goes into them
20:39 < skvidal> ie: kernel.log shouldn
20:39 < skvidal> 't exist at all really
20:39 < skvidal> it's content should be in messages
20:39 < wzzrd> skvidal: crap you were right, i was looking in the wrong place... i didn't quite grasp how epylog's internals worked yet, i suppose...
20:39 < mmcgrath> k, I don't see any problem with that.
20:39 < skvidal> that's what I mean about fixing the structure of our remote logs
20:39 < skvidal> then once we do that
20:39 -!- pjones- [n=pjones at fedora/pjones] has joined #fedora-meeting
20:39 < skvidal> and we log by 'type of server/service'
20:39 < mmcgrath> wzzrd: k, you want to continue working and learning epylog?
20:40 < skvidal> then we can run generic log tools like epylog and generate lovely results
20:40 -!- halfline [n=rstrode at nat/redhat/x-bhhgxvexpbwoodqd] has quit Read error: 60 (Operation timed out)
20:40 < wzzrd> mmcgrath: sure, eager to help out
20:40 < skvidal> w/o having to beat our brains out modifying epylog to access logs we don't want
20:40 < mmcgrath> skvidal: so in theory the amount of logs we store is going to about double.  Which do you think we should keep longer?  the host level logs or the service level logs?
20:40 -!- pjones- is now known as pjones
20:40 < skvidal> mmcgrath: it's not going to double
20:40 < skvidal> right now we've made the mistake of doing *.* from syslog.conf on our logclients
20:41 < skvidal> instead of trimming the crap out
20:41 < skvidal> no one needs spooler.debug sent remotely
20:41 < mmcgrath> how do you know what to include and what not to?
20:41 < skvidal> years of experience?
20:41 < skvidal> :)
20:41 < skvidal> seriously-  you keep warning and above
20:41 < skvidal> and drop a lot of the info and debug crap
20:41 < mmcgrath> skvidal: but still, lets say we only sent what warning and above right this second.
20:41 < skvidal> we can get rid of a lot of crap that's not helpful
20:41 < mmcgrath> when we start storing services too, we're storing all logs twice right?
20:42 < skvidal> <shrug> sure but it's just not that much content
20:42 < mmcgrath> skvidal: so, for example, we wouldn't be sending mail logs?
20:42 < skvidal> I think we should send maillogs
20:42 -!- lmacken_ [n=lmacken at nat/redhat/x-mwvftkmgxvqfjsea] has joined #fedora-meeting
20:42 < skvidal> unless you want to do mailog analysis ON the mailservers
20:42 < skvidal> which seems like a bad use of their cpu time
20:42 < mmcgrath> I've never setup a central logger that didn't store everything, skvidal do you happen to want to take lead on trimming that stuff down?
20:43 < dgilmore> i should just stop getting email and there would be alot less log data
20:43 < mmcgrath> <nod> I'd prefer to keep log analysis on the logger.
20:43 < mmcgrath> dgilmore: that's very true :)
20:43 < skvidal> mmcgrath: sure
20:43 < skvidal> mmcgrath: smooge you wanna work w/me on this?
20:43 < smooge> I am happy to. I love log analysis
20:43 < mmcgrath> skvidal: yup yup.
20:43 < skvidal> smooge: I'm glad I'm not alone :)
20:43 < mmcgrath> so on this same topic... there's still one thing I'd like to get converted.
20:44 < mmcgrath> most of our hosts are still not using rsyslog
20:44 < mmcgrath> I'd like to convert them to rsyslog, some have been but not most.
20:44 < smooge> mmcgrath, on my list of things to fix after ntpd
20:44  * mmcgrath is just mentioning that.
20:44 < skvidal> mmcgrath: for rhel5?
20:44 < mmcgrath> it could be as easy as yum install rsyslgo
20:44 < skvidal> did rhel5 switch to rsyslog?
20:44 < mmcgrath> skvidal: yeah
20:44 < skvidal> okie doke
20:44 < smooge> mmcgrath, skvidal it is basically 5 commands
20:44 < mmcgrath> skvidal: it does for fresh installs, but if you updated, it didn't do a replace.
20:44 < smooge> 1) yum install rsylog
20:44 < mmcgrath> as of 5.3 I think.
20:44 < skvidal> smooge: no problem - I just hadn't heard the switch was official in rhel5
20:45 < smooge> its an alternate
20:45 < smooge> syslogd is still prefered because of age
20:45 < smooge> oh wait.. I missed the new isntall part
20:46 < mmcgrath> smooge: is this something that's going to be possible / easy in puppet or are we goign to have to get func involved?
20:46 < smooge> func migth be easiest
20:46  * mmcgrath thinks perhaps he's been overthinking it.
20:46 < mmcgrath> smooge: what about new installs?
20:46 < mmcgrath> well, we can figure that after the meeting I guess :)
20:46 < smooge> yeah..
20:47 < mmcgrath> wzzrd: any other questions on your side?
20:47 < mmcgrath> does anyone have any thoughts about exactly what we're looking for in these reports?
20:47 < wzzrd> well, im not sure whether this ok to ask
20:48 < mmcgrath> you can ask whatever you want.  If it's for the root password though we probably won't answer.
20:48 < wzzrd> i think it would be easy to have some sort of mentor,
20:48 < wzzrd> you know, to ask some questions to
20:48 < skvidal> mmcgrath: for mail- I'm looking for errors and to make sure we don't have too much overrun/disk/cpu issues, for the rest of systems I'm looking to start getting a baseline on what 'normal' looks like and then fixing up problems
20:48 < skvidal> wzzrd: ask me
20:48 < wzzrd> skvidal: great, thanks!
20:48 < skvidal> I'm around often and I know a fair bit about the epylog code base
20:48 -!- ajax [n=ajackson at nat/redhat/x-doivlmfizynhhosw] has quit Read error: 60 (Operation timed out)
20:49 < skvidal> and I know the author of epylog personally and am willing to annoy him
20:49 < wzzrd> skvidal: you seem to be pretty well informed in this logging business :)
20:49 -!- tomspur [n=Tom at p54A54B74.dip.t-dialin.net] has joined #fedora-meeting
20:49 < wzzrd> lol
20:49 < mmcgrath> wzzrd: yeah for epylog ask skvidal I have no experience with it.  If you have questions about fedora or how we're doing something just ask anyone in #fedora-admin, skvidal smooge and I are almost always in there.
20:49 < wzzrd> ok appreciate it
20:49 -!- ldimaggi_ [n=ldimaggi at nat/redhat/x-gjpbecmbtnvijmjl] has quit Read error: 60 (Operation timed out)
20:49 < dgilmore> wzzrd: skvidal, mmcgrath, myself, ricky, smooge  and others will be more than happy to answer questions
20:50 < mmcgrath> Ok, anyone hav any other questions on logging?
20:50 < smooge> not me
20:50 < mmcgrath> ok, with that I'll open the floor for anything and everything
20:51 < mmcgrath> #topic Infrastructuer -- Open FLoor
20:51 -!- zodbot changed the topic of #fedora-meeting to: Infrastructuer -- Open FLoor (Meeting topic: Infrastructure)
20:51 < mmcgrath> jds2001: you around?
20:51 < mmcgrath> our newest -main member has been pretty quiet.
20:51 < dgilmore> mmcgrath: i wore him out on Saturday
20:51 < mmcgrath> hehe
20:51 < mmcgrath> oh!  i know one thing.
20:51 < skvidal> dgilmore: umm - that sounds
20:51 < skvidal> umm
20:51 < skvidal> wrong
20:52 < mmcgrath> I'm still in the process of getting our secondary,alt,archive stuff to download.fedora.redhat.com
20:52 < dgilmore> skvidal: sure.
20:52 < skvidal> :)
20:52 < dgilmore> skvidal: i made him work alot on saturday while migrating the lists
20:52 < dgilmore> ;)
20:52 < mmcgrath> After the move we have root squashed for all /pub content (which is good)
20:52 < dgilmore> that better
20:52 < mmcgrath> but now I can't do wnything with my dirs that are there becaues they're root owned.
20:53 < ricky> Heh, yow :-)
20:53 < dgilmore> opps
20:53 < mmcgrath> yeah
20:53 -!- lmacken [n=lmacken at fedora/lmacken] has quit Read error: 113 (No route to host)
20:53 < mmcgrath> I do still have several concerns.
20:53 < mmcgrath> same as smooge
20:53 < mmcgrath> will the disks be able to keep up?
20:53 < mmcgrath> will the snap-mirror process work correctly with the new load?
20:54 < mmcgrath> Ok, anyone have anything else?
20:54 < mmcgrath> If not we'll close the meeting in 30
20:54 -!- ajax_ [n=ajackson at nat/redhat/x-dufagrlcirofytgc] has quit Connection timed out
20:54 < smooge> concerns? I have no concerns.. I have reality
20:54 < smooge> cold clear that it probably wont keep up
20:54 < mmcgrath> smooge: yeah, I have a feeling we're in for a ride here.
20:54 -!- ldimagg__ [n=ldimaggi at nat/redhat/x-raflashvigxdpfbm] has quit Read error: 110 (Connection timed out)
20:55 < mmcgrath> but who knows, we might get surprised :)
20:55 < nirik> mmcgrath: will this change what I have to do to push the nightly live composes?
20:55 < smooge> yeah.. I am buying lotto tickets just in case
20:55 < mmcgrath> nirik: it'll just change were you write to
20:55 < mmcgrath> nirik: hopefully for the better because it'll be all mirrored and stuff
20:56 < nirik> cool.
20:56 < mmcgrath> ok,  with that!
20:56 < mmcgrath> #meetingend
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 Jan 14 20:56:53 2010 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot .
20:56 < zodbot> Minutes:        http://meetbot.fedoraproject.org/fedora-meeting/2010-01-14/fedora-meeting.2010-01-14-20.02.html
20:56 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2010-01-14/fedora-meeting.2010-01-14-20.02.txt
20:56 < mmcgrath> damnit
20:56 < zodbot> Log:            http://meetbot.fedoraproject.org/fedora-meeting/2010-01-14/fedora-meeting.2010-01-14-20.02.log.html
20:56 < mmcgrath> Thanks for coming everyone!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20100114/8ed076d4/attachment-0001.bin