Infrastructure/Meetings/2006-01-12

Meeting of 2006-01-12

**** BEGIN LOGGING AT Thu Jan 12 14:55:38 2006

Jan 12 14:55:38 -->	You are now talking on #fedora-admin
Jan 12 14:55:38 ---	Topic for #fedora-admin is This is the meeting place of the Fedora Infrastructure team - the system administrators of the Fedora Project | http://fedoraproject.org/wiki/Infrastructure | Regular meetings: http://fedoraproject.org/wiki/Infrastructure/Meetings
Jan 12 14:55:38 ---	Topic for #fedora-admin set by nman64 at Thu Jan  5 17:03:19 2006
Jan 12 14:55:38 ---	Received a CTCP VERSION from freenode-connect
Jan 12 14:59:44 <Sopwith>	Hey hey hey, look at all the people! :)
Jan 12 14:59:49 <xDamox>	:)
Jan 12 14:59:56 <lmacken>	heh
Jan 12 15:00:08 *	lmacken rolls out of bed
Jan 12 15:00:38 <xDamox>	lmacken, time is it where you are?
Jan 12 15:00:43 <lmacken>	3:00pm
Jan 12 15:01:04 <lmacken>	which is late morning, in college time ;)
Jan 12 15:01:07 <xDamox>	hehe and your in bed
Jan 12 15:01:42 <lmacken>	i handed in a paper this morning at 9am.. then passed back out. that's all i'm really motivated to do today
Jan 12 15:01:55 ---	[xDamox]  (i=damian@user-2439.lns6-c7.dsl.pol.co.uk) : Damian Myerscough
Jan 12 15:01:55 ---	[xDamox]  #fedora-devel #fedora #fedora-admin #fedora-websites
Jan 12 15:01:55 ---	[xDamox]  irc.freenode.net :http://freenode.net/
Jan 12 15:01:55 ---	[xDamox]  is identified to services
Jan 12 15:01:55 ---	[xdamox]  End of WHOIS list.
Jan 12 15:01:57 <xDamox>	hehe
Jan 12 15:02:21 <imlinux>	We all ready to get this party started?
Jan 12 15:02:22 <xDamox>	time the meeting starting?
Jan 12 15:02:55 <Sopwith>	Sure!
Jan 12 15:02:59 <nman64>	:-)
Jan 12 15:03:16 <Sopwith>	imlinux/cygnus2936/jschmitt/nman64/skvidal: Anyone there?
Jan 12 15:03:23 <cygnus2936>	i am here
Jan 12 15:03:26 <imlinux>	check
Jan 12 15:03:47 <xDamox>	I am here too
Jan 12 15:04:03 <Sopwith>	http://fedoraproject.org/wiki/Infrastructure/Schedule is going to be a good chunk of the agenda
Jan 12 15:04:03 <skvidal>	I am
Jan 12 15:04:19 <skvidal>	1st one is done
Jan 12 15:04:21 <skvidal>	the server is here
Jan 12 15:04:24 ---	But :Unknown command
Jan 12 15:04:24 <skvidal>	people can login to it
Jan 12 15:04:25 <Sopwith>	yay
Jan 12 15:04:30 <skvidal>	it is using the fedora accounts system
Jan 12 15:04:34 <skvidal>	it's in place and everything
Jan 12 15:04:43 <skvidal>	so there is no limitation to y'all or me to set things up on it
Jan 12 15:04:49 <xDamox>	that using pub_dsa?
Jan 12 15:05:14 -->	dcbw (n=dcbw@nat-pool-bos.redhat.com) has joined #fedora-admin
Jan 12 15:05:27 <Sopwith>	xdamox: It is using ssh keys for logins, yes.
Jan 12 15:05:35 <xDamox>	yep
Jan 12 15:05:51 <skvidal>	there are two more boxes here we need to think about
Jan 12 15:06:11 <skvidal>	1. extras64 - to merge that one in place will probably take a downtime and interaction with some other folks
Jan 12 15:06:16 <Sopwith>	Before we get into the detailed tasks, it might make sense to go over the big picture...
Jan 12 15:06:24 <skvidal>	 - we sign packages on that box so I think being careful about access to it is critical
Jan 12 15:06:27 <skvidal>	oh
Jan 12 15:06:28 <skvidal>	sorry
Jan 12 15:06:39 <Sopwith>	i.e. make sure everyone agrees what this project is about :)
Jan 12 15:07:23 <Sopwith>	As far as I see it, the point is to keep existing infrastructure running, create new infrastructure, and help people with infrastructure problems.
Jan 12 15:07:55 <imlinux>	Is the existing infrastructure set to go away? Or are we simply adding to it?
Jan 12 15:08:11 -->	che (n=che@unaffiliated/che) has joined #fedora-admin
Jan 12 15:08:17 <nman64>	imlinux: We are improving and adding.
Jan 12 15:08:36 <Sopwith>	imlinux: It's not an all-or-nothing proposition.
Jan 12 15:09:05 <Sopwith>	Any opinions on our overall goals?
Jan 12 15:09:45 <imlinux>	sounds reasonable to me.
Jan 12 15:09:48 <xDamox>	See the infrastructure have you documented the servers etc?
Jan 12 15:10:27 <nman64>	I see those goals as clear.
Jan 12 15:10:31 ---	That's :Unknown command
Jan 12 15:10:41 <nman64>	We do need to document what we've got.
Jan 12 15:10:44 <Sopwith>	xdamox: That's a good segue to a related topic - is everyone familiar with the current state of infrastructure?
Jan 12 15:11:18 <Sopwith>	I've sent a few e-mails out that documented some things such as lists of systems, but it's not up on any web site.
Jan 12 15:11:25 <xDamox>	I would'nt mine a little information about the current state
Jan 12 15:11:49 <nman64>	I'm still learning the relationships, and I imagine that learning will be ongoing, but I think I've got a pretty good understanding of the overall state.
Jan 12 15:11:58 <xDamox>	I would like to know what servers there are/purpose of them that would b great
Jan 12 15:12:21 <Sopwith>	xdamox: Sure...
Jan 12 15:12:26 <xDamox>	ok thanks
Jan 12 15:13:15 <skvidal>	Sopwith: I've got to run away for a little bit to another meeting - my irc proxy will still be here if anyone needs me for anything.
Jan 12 15:13:28 <Sopwith>	skvidal: Ok, thanks for stopping by.
Jan 12 15:13:29 <skvidal>	as a general rule I'm on board for integrating the boxes here with the rest of them
Jan 12 15:13:42 <skvidal>	so consider my position a general willingness to cooperate
Jan 12 15:13:49 <skvidal>	(unlike my normal position)
Jan 12 15:13:50 <skvidal>	ttfn
Jan 12 15:14:02 <Sopwith>	xdamox: let me find that e-mail listing the hosts...
Jan 12 15:14:18 <nman64>	I, for one, have always thought that skvidal's vigilance in sticking to his guns should be a good example for us all.
Jan 12 15:14:20 <xDamox>	ok Sopwith
Jan 12 15:15:13 <imlinux>	I'm aware of the app servers, hammer's ppc, proxy's, db1, cvs-int, bastion and fpserv.  But I don't know who owns them, or what other servers we officially have.
Jan 12 15:15:22 <imlinux>	like fedoraproject.org?  is that one of ours or someone elses?
Jan 12 15:15:32 <Sopwith>	https://www.redhat.com/archives/fedora-devel-list/2005-November/msg00415.html is the initial e-mail I sent about shell access
Jan 12 15:15:48 <nman64>	That is among skvidal's boxes that still need to be integrated.
Jan 12 15:15:54 <xDamox>	ok Sopwith
Jan 12 15:16:13 <Sopwith>	skvidal's boxes: extras64.linux.duke.edu, fpserv.linux.duke.edu, and fedora.linux.duke.edu
Jan 12 15:16:25 <Sopwith>	fpserv is currently doing DNS for all the fedora domains except fedora.redhat.com
Jan 12 15:16:31 <Sopwith>	extras64 is the hub of the build system
Jan 12 15:16:43 <Sopwith>	and fedora runs the fp.o wiki and a bit more.
Jan 12 15:17:17 <imlinux>	fedoranews.org and the like?
Jan 12 15:17:22 ---	xdamox: :Unknown command
Jan 12 15:17:32 <nman64>	fedoranews.org is a community site, and not under our umbrella.
Jan 12 15:17:48 <imlinux>	k.
Jan 12 15:17:50 <nman64>	All of the systems listed at http://fedoraproject.org/wiki/CommunityWebsites are.
Jan 12 15:18:40 <cygnus2936>	I was wondering what sort of things need to be done / require help
Jan 12 15:18:58 <Sopwith>	cygnus: We'll get to it in just a few minutes :)
Jan 12 15:19:31 <Sopwith>	I don't think some people here are aware of the fedora-config setup - I should put that e-mail up
Jan 12 15:20:25 <Sopwith>	https://www.redhat.com/mailman/private/fedora-sysadmin-list/2006-January/msg00034.html
Jan 12 15:20:52 <Sopwith>	Basically, I took one of the former web proxies and turned it into a sysadmin machine.
Jan 12 15:21:16 <Sopwith>	And it has a CVS repo that theoretically stores the configurations of all the machines, so we can easily restore any machine if it goes boom.
Jan 12 15:22:29 <Sopwith>	Info such as passwords for various vital accounts are also stored in there.
Jan 12 15:22:34 <Sopwith>	(GPG encrypted)
Jan 12 15:23:46 <Sopwith>	Because we have the config stored in CVS, relatively few machines are backed up (cvs, proxy4, db1, and skvidal's machines)
Jan 12 15:24:13 <Sopwith>	Anything else that we all could use to know about the way things currently work?
Jan 12 15:25:02 <imlinux>	I seem to remember your workstation being in the mix for something?  Whats that all about :-)
Jan 12 15:25:28 <Sopwith>	0 0 * * * /home/devel/sopwith/cvs/fedora-metrics/import-googlebuzz.py
Jan 12 15:25:28 <Sopwith>	0 0 * * * /home/devel/sopwith/cvs/fedora-metrics/import-extras-packagecount.py
Jan 12 15:25:28 <Sopwith>	0 0 * * * /home/devel/sopwith/cvs/fedora-metrics/run-import-accounts.sh
Jan 12 15:25:28 <Sopwith>	0 * * * * wget -O - http://localhost/drupal/cron.php &>/dev/null
Jan 12 15:25:28 <Sopwith>	0 * * * * /home/devel/sopwith/cvs/fedora-config/fedora-accounts/run-make-components.sh
Jan 12 15:25:28 <Sopwith>	0 * * * * /home/devel/sopwith/cvs/fedora-config/fedora-accounts/export-bugzilla.py fedorabugs fedora_contrib
Jan 12 15:25:34 <Sopwith>	Those are the jobs currently on my machine.
Jan 12 15:26:01 <Sopwith>	The bugzilla and make-components ones have to run /somewhere/ inside Red Hat because they talk directly to the bugzilla.redhat.com DB
Jan 12 15:26:18 <xDamox>	ok
Jan 12 15:26:29 <Sopwith>	Those metrics ones there should really move to a Fedora machine.
Jan 12 15:26:51 <Sopwith>	And I *should* move the rest of the jobs off my box and onto a Fedora-specific machine inside Red Hat.
Jan 12 15:26:57 <imlinux>	I have a generic making changes question.  For example....
Jan 12 15:27:20 <imlinux>	On bastion logrotate throws a warning right now because there's an httpd.rpmnew on the server.
Jan 12 15:27:55 <imlinux>	Whats the right way to handle something like that?  (or am I too far off topic?)
Jan 12 15:29:08 <Sopwith>	Good question - how do we all work together to avoid stepping on toes?
Jan 12 15:29:12 ---	log :Unknown command
Jan 12 15:29:33 <imlinux>	exactly
Jan 12 15:29:34 <xDamox>	documenting is a good way
Jan 12 15:29:46 <xDamox>	and have a central point for documents
Jan 12 15:29:54 <nman64>	On trivial issues like that, I'd say post an announcement of intent to the list, wait x hours for feedback/objections, and then proceed.
Jan 12 15:30:07 <lmacken>	maybe have changes to the fedora-config cvs repo sent to the admin list ?
Jan 12 15:30:12 <Sopwith>	lmacken: They are already.
Jan 12 15:30:18 <Sopwith>	sent to sysadmin-members@fedora.redhat.com
Jan 12 15:30:21 <lmacken>	ah, ok
Jan 12 15:30:33 <imlinux>	perhaps that will be easier once we get item number two on Schedule list set up :-)
Jan 12 15:30:42 *	nman64 nods.
Jan 12 15:30:49 <Sopwith>	Personally for a change of that nature, I would suggest making the change and letting people know about it.
Jan 12 15:31:17 <lmacken>	Sopwith: hmm. i don't think i'm on that list.
Jan 12 15:31:21 <Sopwith>	For bigger changes, consulting others ahead of time is good, but the baseline is informing people.
Jan 12 15:31:21 <lmacken>	although, i could be wrong.
Jan 12 15:31:34 <Sopwith>	lmacken: It's the alias for the people who are in the 'sysadmin' group in the account system.
Jan 12 15:32:04 <lmacken>	ah, alright.
Jan 12 15:32:36 <Sopwith>	For changes that involve modifying stuff in the fedora-config repository, I'm happy with just an informative cvs commit message
Jan 12 15:32:48 <Sopwith>	The main idea is - make sure others know what's going on and who to talk to for more info.
Jan 12 15:33:20 <nman64>	On that token, we're working on live, production systems, so be careful.
Jan 12 15:33:35 <imlinux>	Got'cha, and if something does go wrong, we can always roll back to the previous config.
Jan 12 15:33:39 <Sopwith>	Yup
Jan 12 15:34:22 <Sopwith>	For the systems in fedora.phx.redhat.com, I do have remote serial console access, remote power switch, and ability to reinstall using PXE, so the worst case is not terribly aweful.
Jan 12 15:34:54 <dcbw>	weren't we getting another ppc box there?
Jan 12 15:34:57 <Sopwith>	But mistakes can potentially impact hundreds of thousands of users, so read your command line before hitting enter. :)
Jan 12 15:35:13 <Sopwith>	dcbw: Rumor was that the PO went through just before the holiday break.
Jan 12 15:35:33 <Sopwith>	I believe the PHX colo will get a new CVS server and a ppc build box.
Jan 12 15:35:48 <Sopwith>	No clue when they'll show up, though ;-)
Jan 12 15:36:35 <dcbw>	Sopwith: jeremy didn't touch the buildsys over christmas, and I haven't had to restart the build server due to hung TCP stuff, so is it magically fixed now?
Jan 12 15:37:03 <nman64>	Nobody was around to break it.  ;-)
Jan 12 15:37:16 <Sopwith>	Let's hope it's fixed one way or another. :)
Jan 12 15:38:33 <imlinux>	Going back to the request tracker (item two on the schedule) has anyone expressed an interest in setting that up?
Jan 12 15:39:01 <Sopwith>	Not that I know of. I just put it up there because some sort of ticket tracker is pretty much inevitable. :)
Jan 12 15:39:07 <--	JSchmitt (n=pclinux@p54B09480.dip0.t-ipconnect.de) has left #fedora-admin ("Konversation terminated!")
Jan 12 15:39:17 <imlinux>	I just evaluated a few packages including RT and OTRS.
Jan 12 15:39:31 ---	[JSchmitt]  (n=pclinux@p54B09480.dip0.t-ipconnect.de) : Jochen Schmitt
Jan 12 15:39:31 ---	[JSchmitt]  #fedora
Jan 12 15:39:31 ---	[JSchmitt]  irc.freenode.net :http://freenode.net/
Jan 12 15:39:31 ---	[JSchmitt]  is identified to services
Jan 12 15:39:31 ---	[jschmitt]  End of WHOIS list.
Jan 12 15:39:37 <Sopwith>	Cool! :)
Jan 12 15:39:42 <imlinux>	We decided to go with OTRS, any opinions about favorite ticketing systems?
Jan 12 15:39:52 <nman64>	Just as long as we don't go with something that is as much of a PITA as Bugzilla to set up.  :-)
Jan 12 15:40:14 <Sopwith>	Sounds like we're getting into the list of todo items... I've used RT in a couple of situations and it seemed great.
Jan 12 15:40:33 <Sopwith>	My only requirement for a ticket system is ability for users to access it via e-mail.
Jan 12 15:42:08 <Sopwith>	imlinux: Wouldd you send the mailing list an e-mail comparing the two?
Jan 12 15:42:14 <nman64>	imlinux: Care to kick off a thread on the list with a little info about your experience.
Jan 12 15:42:34 <nman64>	Let's get a healthy discussion going, and maybe we can make a decision in the next meeting.
Jan 12 15:42:38 <imlinux>	(We as in my employer not Fedora)
Jan 12 15:42:38 <imlinux>	OTRS is really simple, and I already have a package for it.
Jan 12 15:42:38 <imlinux>	I was planning on submitting it to extras once I got done with Nagios.
Jan 12 15:43:27 -->	mmcgrath (n=mmcgrath@65.123.213.146) has joined #fedora-admin
Jan 12 15:44:04 <cygnus2936>	sorry guys, i have to go... I was hoping that I can help with something
Jan 12 15:44:15 <nman64>	cygnus2936: np, just watch the list.
Jan 12 15:44:27 <Sopwith>	cygnus: OK, we'd love to have you involved. I'll try to catch up with you later :)
Jan 12 15:44:30 ---	[cygnus2936]  (n=cygnus29@83-70-31-102.b-ras1.prp.dublin.eircom.net) : Hrishikesh Ballal
Jan 12 15:44:30 ---	[cygnus2936]  #fedora-admin
Jan 12 15:44:30 ---	[cygnus2936]  irc.freenode.net :http://freenode.net/
Jan 12 15:44:30 ---	[cygnus2936]  is identified to services
Jan 12 15:44:30 ---	[cygnus2936]  End of WHOIS list.
Jan 12 15:44:50 <Sopwith>	Oh, just to clarify something that may be on people's minds - my idea for giving root access out at this point is to give it to anyone who shows that they are serious about helping out.
Jan 12 15:45:29 <imlinux>	sopwith nman64: sure, I'll write up reasons why we went with one over the other after the meeting.
Jan 12 15:45:35 <Sopwith>	imlinux: Sounds good!
Jan 12 15:45:54 <nman64>	Moving on?
Jan 12 15:46:05 <cygnus2936>	see you all at the next meeting!
Jan 12 15:46:07 <--	cygnus2936 (n=cygnus29@83-70-31-102.b-ras1.prp.dublin.eircom.net) has left #fedora-admin
Jan 12 15:46:17 <imlinux>	Sopwith: root access - Sounds good but we should guard very closely backups and the cvs repository.
Jan 12 15:46:21 <Sopwith>	imlinux: Yup
Jan 12 15:46:33 <Sopwith>	imlinux: proxy4 does not give out root access with the rest of them.
Jan 12 15:46:42 <xDamox>	Has anyone asked about doing the  Integration of Seth & Red Hat's boxes task?
Jan 12 15:46:43 <Sopwith>	And it has hourly backups-ish
Jan 12 15:46:52 <Sopwith>	xdamox: Nice segue :)
Jan 12 15:46:57 <Sopwith>	Basically what is left to be done there:
Jan 12 15:47:28 <Sopwith>	. Changing the mail setup for all the fedora domains so they go through the machine that currently serves fedora.redhat.com.
Jan 12 15:47:44 <Sopwith>	. Getting fedora.linux.duke.edu and extras64.linux.duke.edu into the account system.
Jan 12 15:47:51 <skvidal>	umm
Jan 12 15:47:54 <skvidal>	why fedora.linux.duke.edu
Jan 12 15:47:56 <xDamox>	ahh ok
Jan 12 15:48:02 <skvidal>	it's going away when fpserv.linux.duke.edu
Jan 12 15:48:10 <skvidal>	fedora is the old version of fpserv.linux.duke.edu
Jan 12 15:48:16 <Sopwith>	skvidal: Ahh thanks, my bad.
Jan 12 15:48:19 <skvidal>	the whole reason for fpserv is to replace the hw
Jan 12 15:48:21 <skvidal>	ah, okay
Jan 12 15:48:49 <xDamox>	So there is only little todo on that task
Jan 12 15:49:04 <xDamox>	Did the NTP get setup
Jan 12 15:49:08 <Sopwith>	Whoever does the mail changover will need help from a RH sysadmin.
Jan 12 15:49:11 <xDamox>	I read it in the mailing list
Jan 12 15:49:15 <Sopwith>	xdamox: Dunno, but that's a good item to add to the list.
Jan 12 15:49:23 <xDamox>	k
Jan 12 15:49:31 <Sopwith>	Any volunteers?
Jan 12 15:49:32 <skvidal>	Sopwith: what's the goal for changing over the mail system?
Jan 12 15:49:46 <skvidal>	why put more things in a place where we (fedora admins) can't touch them?
Jan 12 15:50:08 <Sopwith>	skvidal: Anyone here who has root access can change fedora.redhat.com mail right now
Jan 12 15:50:16 <imlinux>	sopwith: I'll set it up, did you ever find the redhat NTP server to use?  or should I just sue the public pool.
Jan 12 15:50:23 <Sopwith>	bastion is the mail server
Jan 12 15:50:27 <xDamox>	Sopwith,  I will help with the mail change over
Jan 12 15:50:29 <--	mmcgrath (n=mmcgrath@65.123.213.146) has left #fedora-admin
Jan 12 15:50:32 <skvidal>	Sopwith: yes - but those people aren't us
Jan 12 15:50:40 <Sopwith>	skvidal: Those people *are* us.
Jan 12 15:50:46 <skvidal>	umm really
Jan 12 15:50:51 <nman64>	That's not the same as the fedora.redhat.com website.
Jan 12 15:50:58 <skvidal>	then you'll feel okay telling me all about the mono decision is complete detail in public?
Jan 12 15:51:02 <skvidal>	if not, then they're not US
Jan 12 15:51:12 <skvidal>	you take orders from RH corporate
Jan 12 15:51:15 <skvidal>	fedora admins DO NOT
Jan 12 15:51:18 <Sopwith>	skvidal: I don't know what you're getting at...
Jan 12 15:51:25 <Sopwith>	skvidal: How do you want things to work, in a general sense?
Jan 12 15:51:46 <skvidal>	I want to make it so as few things as possible can be turned off b/c someone in rh legal/corp says so
Jan 12 15:51:54 <skvidal>	I want to remove the possibility of a repeat of the rhlp stuff
Jan 12 15:52:15 <skvidal>	I don't want assurances that it won't happen
Jan 12 15:52:21 <skvidal>	I want to know that it CANNOT happen
Jan 12 15:52:40 <skvidal>	and the only way to assure that is to make sure that all the people involved don't answer to a single master
Jan 12 15:52:53 <skvidal>	if we have to go through rh sysadmin to get things done
Jan 12 15:53:08 <skvidal>	all of them answer to the same master
Jan 12 15:53:09 <Sopwith>	skvidal: I think we need to get a bit clearer on the facts first.
Jan 12 15:53:47 <skvidal>	if szulik or cormier says 'fedora.redhat.com' goes offline - you do it, right?
Jan 12 15:53:50 ---	skvidal: :Unknown command
Jan 12 15:53:59 ---	skvidal: :Unknown command
Jan 12 15:54:06 <skvidal>	if so, then that's a fact.
Jan 12 15:54:34 <skvidal>	now if we want fedoraproject.org to be under the same controls
Jan 12 15:54:38 <skvidal>	then that's a potential problem
Jan 12 15:55:22 <nman64>	The concern on this matter is getting the fedoraproject.org email aliases tied in to the account system.
Jan 12 15:55:23 <Sopwith>	skvidal: I don't know what to tell you. If you want iron clad protection against getting screwed over, be like ensc or go live in a cave.
Jan 12 15:55:36 <skvidal>	Sopwith: or, just keep some things off of red hat systems
Jan 12 15:56:03 <Sopwith>	skvidal: Until then, what I'm suggesting is having mail served by machine Y instead of machine X (both of which you have root on)
Jan 12 15:56:30 <Sopwith>	I know I mentioned needing help from a RH sysadmin, but that is a one-time-only thing.
Jan 12 15:57:05 <skvidal>	okay
Jan 12 15:58:32 <Sopwith>	I don't believe we are at the point where everyone has equal access (because some things are still internal to RH), but I believe I have made concrete changes in the right direction of opening things up for you all to get stuff done.
Jan 12 15:59:18 <Sopwith>	And since you control physical access to the DNS server, you do have a fairly effective veto if need be. :)
Jan 12 15:59:26 <skvidal>	Sopwith: I don't distrust YOUR motives
Jan 12 15:59:34 <imlinux>	This is all something we can create a plan for and execute that plan for a long term solution though right?
Jan 12 16:00:23 <nman64>	I fully understand where skvidal's concern lies.  I too would like to see as much Fedora infrastructure safe from ill-intended Red Hat hands as possible.
Jan 12 16:01:20 <nman64>	I'm content to move slowly in that direction, as long as our needs are taken care of.
Jan 12 16:02:25 <Sopwith>	Well, I just know Mr. Szulik's current thinking on Fedora, and if he suddenly reversed course and tried to screw us all over, we'd just have to move the stuff to non-RH servers.
Jan 12 16:03:02 <nman64>	So, lets concentrate on getting fedoraproject.org email tied in with fedora.redhat.com email and the account system.  Who's willing to work on this, what do they need, and when can we hope to have it done?
Jan 12 16:03:16 <Sopwith>	I think the biggest thing needed was skvidal's buy-in.
Jan 12 16:03:40 <Sopwith>	:)
Jan 12 16:03:43 <skvidal>	I'm just lost on why it's necessary, really.
Jan 12 16:04:01 <skvidal>	we're talking about producing an alias map and distributing it, right?
Jan 12 16:04:24 <skvidal>	why is that terribly difficult given the current deployment capabilities of the accounts system?
Jan 12 16:04:51 <Sopwith>	skvidal: There are some aliases that need to run scripts that access the account system db (such as the CLA approver)
Jan 12 16:05:20 <Sopwith>	Since one of our goals is to just move away from using fedora.redhat.com altogether, that alias would need to be @fedoraproject.org
Jan 12 16:05:56 <skvidal>	maybe I missed it in the backscroll - what happens for the cla approver emails?
Jan 12 16:08:16 <skvidal>	I assume it submits it to the db when it is mailed+signed?
Jan 12 16:08:27 <Sopwith>	Currently, accounts@fedora.redhat.com gets the incoming e-mail, checks the GPG signature, and if it is all kosher, updates the account DB to set the user as cla_done
Jan 12 16:08:56 <skvidal>	and what keeps accounts@fedoraproject.org from forwarding this to the accounts system?
Jan 12 16:09:08 <skvidal>	or from doing it itself?
Jan 12 16:09:27 <Sopwith>	skvidal: If fedoraproject.org mail is handling on one of your boxes, it won't be able to connect to the DB.
Jan 12 16:09:56 <nman64>	If we are willing to put in the effort, I'm sure we can enable fpserv to provide the mail functions.
Jan 12 16:10:19 <nman64>	accounts@fedoraproject.org can forward to accounts@fedora.redhat.com, no?
Jan 12 16:10:20 <skvidal>	Sopwith: I thought you had implemented some xml-rpc interface to the accounts system, or did I invent that?
Jan 12 16:10:32 <skvidal>	nman64: I think he wants to reduce the things that can receive mail
Jan 12 16:10:32 <Sopwith>	skvidal: No such interface exists.
Jan 12 16:10:41 <skvidal>	Sopwith: ah, I was imagining things, sorry.
Jan 12 16:10:54 <skvidal>	Sopwith: are you looking to remove all mail interfaces from fedora.redhat.com?
Jan 12 16:11:16 <skvidal>	right now it might be worthwhile to have a map of the services provided?
Jan 12 16:11:23 <skvidal>	so we can know what things need to be where
Jan 12 16:11:26 <Sopwith>	skvidal: Probably will keep the fedora.redhat.com domain around, and redirect all of its stuff to fedoraproject.org
Jan 12 16:11:32 <Sopwith>	Yea, I had a service map somewhere.
Jan 12 16:11:58 <skvidal>	Sopwith: not the domain - the machine
Jan 12 16:12:01 <skvidal>	and it's ports
Jan 12 16:12:08 <skvidal>	ie: if foo.fedora.redhat.com is the accounts machine
Jan 12 16:12:17 <skvidal>	and it has a cla-finished address on it
Jan 12 16:12:23 <Sopwith>	skvidal: There is no one 'accounts machine'.
Jan 12 16:12:35 <skvidal>	so we have 1 machine doing accounts and the webpage?
Jan 12 16:13:03 <Sopwith>	We have one group of machines serving the web interface, one machine acting as the database server, and one machine processing the mail.
Jan 12 16:14:06 <xDamox>	Right I got to go will the logs of the metting be mailed on the sysadmin mailling list?
Jan 12 16:14:26 <Sopwith>	xdamox: Yup. Thanks for being here!
Jan 12 16:14:51 <xDamox>	np ok Ill c ya soon
Jan 12 16:14:55 <--	xDamox has quit ("Leaving")
Jan 12 16:15:37 <skvidal>	so the layout looks like this:
Jan 12 16:15:46 <skvidal>	fpserv.linux.duke.edu -- web interface
Jan 12 16:15:53 <Sopwith>	no
Jan 12 16:15:58 <Sopwith>	For the account system specifically
Jan 12 16:16:08 <Sopwith>	The web interface runs on proxy2 and app1
Jan 12 16:16:11 <Sopwith>	The DB is db1
Jan 12 16:16:14 <Sopwith>	And the mail server is bastion
Jan 12 16:16:26 <skvidal>	I mean for fedoraproject.org
Jan 12 16:17:36 <Sopwith>	Ahh, for the fedoraproject.org main web site, I don't think we'll really be able to justify moving that until the websites team has the new web site running on a new CMS...?
Jan 12 16:19:37 <nman64>	Those systems are in the same place, no?  We can set up the CMS on fpserv, and set up Apache's rewriting and proxy engines to handle requests for the wiki.  We can then flip over to fpserv and move the wiki transparently when we're ready.
Jan 12 16:19:49 <Sopwith>	nman64: Yup
Jan 12 16:20:03 <skvidal>	I'm not on the websites list anymore so I'm not sure what that status is
Jan 12 16:20:28 <Sopwith>	imlinux: Hey, look at the ntp config files in fedora-config CVS... They have the hostname to use :)
Jan 12 16:20:30 <nman64>	No decision has been made.  We now have http://fedoraproject.org/wiki/Websites/CMS
Jan 12 16:20:39 <Sopwith>	imlinux: clock3.util.phx.redhat.com
Jan 12 16:20:55 <imlinux>	sopwith: sweeeet.
Jan 12 16:20:59 <skvidal>	Sopwith: right now I'd like to see two maps put together
Jan 12 16:21:10 <skvidal>	1 of what things are now for fedora.redhat.com
Jan 12 16:21:22 <skvidal>	2. of what you think it should look like for fedoraproject.org
Jan 12 16:21:56 <skvidal>	I'll be glad to provide a fedoraproject.org map as it currently sits
Jan 12 16:22:03 <Sopwith>	Cool
Jan 12 16:22:21 <Sopwith>	OK, let's try to get through the rest of this TODO list quickly.
Jan 12 16:22:27 <skvidal>	we have another component to remember
Jan 12 16:22:31 <skvidal>	download.fedoralegacy.org
Jan 12 16:23:04 <Sopwith>	yup
Jan 12 16:23:13 <skvidal>	which is here at duke, too.
Jan 12 16:23:41 <nman64>	Can we get all three of those maps on the list?
Jan 12 16:23:48 <Sopwith>	Sounds like a plan.
Jan 12 16:24:08 <skvidal>	that's fine, I'll work on it shortly
Jan 12 16:24:16 *	Sopwith puts a draft in his outbox.
Jan 12 16:24:28 <nman64>	Good, lets try to run through the rest of the agenda, then.
Jan 12 16:24:28 <Sopwith>	Moving right along...
Jan 12 16:24:46 <Sopwith>	Metrics - anyone interested in more of the coding & infrastructure creation side of things?
Jan 12 16:25:13 <Sopwith>	I don't know if this code is on cvs.fedora but if it's not I should move it there.
Jan 12 16:25:35 <nman64>	Get it to where we can look at it, and we'll call for volunteers to hack on it.
Jan 12 16:25:40 <Sopwith>	real metrics progress depends on bouncer though, so...
Jan 12 16:25:45 <Sopwith>	nod, ok
Jan 12 16:25:48 <imlinux>	agreed.
Jan 12 16:26:02 <nman64>	Okay, so lets cover monitoring.
Jan 12 16:26:04 <Sopwith>	Monitoring - imlinux?
Jan 12 16:26:08 <nman64>	Nagios?
Jan 12 16:26:16 <imlinux>	Its coming along, I've been getting a list of things that need to be monitored.
Jan 12 16:26:39 <imlinux>	right now I'm just waiting for approval in extras, I've been working with Ignacio for that.
Jan 12 16:26:40 <skvidal>	where do we want to monitor FROM?
Jan 12 16:27:04 <imlinux>	Good question.
Jan 12 16:27:34 <Sopwith>	Probably depends on firewalling.
Jan 12 16:27:35 <imlinux>	nagios itself doesn't take up much CPU but if its on a machine with something else that does we'll start getting notified about false positives.
Jan 12 16:27:53 <skvidal>	Sopwith: punching holes for the monitoring makes sense, too
Jan 12 16:27:55 <Sopwith>	We could have the web interface on admin.fedora
Jan 12 16:27:56 <imlinux>	and actual machine access is the other issue.
Jan 12 16:28:11 <Sopwith>	imlinux: You should have all the machine access you need outside of extras64...
Jan 12 16:28:31 <skvidal>	Sopwith: I think he means hw access
Jan 12 16:28:32 <imlinux>	so far I've been able to get to all the machines with no problem.
Jan 12 16:28:39 <skvidal>	in the event of an alerted failure
Jan 12 16:29:12 <Sopwith>	skvidal: That'll have to be a case-by-case basis, probably.
Jan 12 16:29:25 <nman64>	Do we at least have someone we can reach quickly at the colo?
Jan 12 16:29:26 <imlinux>	On a side note (not to digress) my proxy4 authorized_keys file changed to mod 644 recently and I didn't do it.....
Jan 12 16:30:06 <imlinux>	I was going to save alerts for a whole other meeting :-D there's lots of ways we can set that up.
Jan 12 16:30:07 <Sopwith>	nman64: It costs $500 to call an AT&T technician out to look at stuff. We don't want to do that.
Jan 12 16:30:31 <Sopwith>	nman64: I have serial console & power switch access to all the RH-hosted machines; it's enough to reinstall them from scratch if need be.
Jan 12 16:30:58 <Sopwith>	I don't have a way to give that access out at the moment, but I suppose I should ask.
Jan 12 16:31:57 <imlinux>	going back to the monitoring from question, what machine should we put this on?
Jan 12 16:32:00 <nman64>	In the event of hardware failure, I suppose the fast solution would be to move services to another system then?
Jan 12 16:32:21 <Sopwith>	nman64: "It depends" - failover is a separate issue.
Jan 12 16:32:33 <Sopwith>	imlinux: Does nagios write files to the filesystem?
Jan 12 16:32:40 <skvidal>	yes
Jan 12 16:33:30 <imlinux>	Sopwith: Yes, it writes log files and such
Jan 12 16:33:41 <Sopwith>	humbug... Probably app1 is best for now, and if the configuration is in fedora-config CVS, we can easily move it to a better machine once we think of one.
Jan 12 16:33:43 <imlinux>	so does Cacti for that matter.
Jan 12 16:34:57 <nman64>	Okay, so lets give that time to get into Extras and come back to it next week.
Jan 12 16:35:28 <Sopwith>	next, bouncer
Jan 12 16:35:40 <imlinux>	sounds good.
Jan 12 16:35:55 <Sopwith>	That is partially mine. I've been talking with morgamic on #osuosl this week about features that it needs to work for Fedora.
Jan 12 16:36:32 <lmacken>	did mike figure out the php5 issues yet ?
Jan 12 16:36:44 <Sopwith>	lmacken: Dunno, but I have it working with php5, and I sent him my patch.
Jan 12 16:36:48 <lmacken>	i haven't written a line of PHP in my life, so i'm reluctant to dive into that part of bouncer.
Jan 12 16:36:51 <lmacken>	oh sweet
Jan 12 16:36:59 <lmacken>	I'd like to get ahold of that patch
Jan 12 16:37:24 <nman64>	As much as I don't like PHP, I am a PHP programmer and can help there.
Jan 12 16:37:25 >lmacken<	~sopwith/today/bouncer-misc.patch
Jan 12 16:37:48 <Sopwith>	nman64: OK, cool. Not all if it is PHP, either.
Jan 12 16:38:07 <lmacken>	yeah, i'm glad to dive into the python part of bouncer.. but the php kind of makes me want to hurt myself and everyone around me.
Jan 12 16:38:25 <Sopwith>	hehe
Jan 12 16:38:46 <Sopwith>	Well, I think if we get the kinks worked out and a couple more features in, it should be fine to use.
Jan 12 16:39:02 <skvidal>	lmacken: refer to icon's unicorn
Jan 12 16:39:08 <lmacken>	hehe
Jan 12 16:39:17 <nman64>	Awesome.  We'll include bouncer in our call for metrics volunteers.
Jan 12 16:39:31 <nman64>	Next item?
Jan 12 16:40:00 <Sopwith>	rhlinux.redhat.com migration is stalled
Jan 12 16:40:15 <Sopwith>	Bernd got pulled off to other stuff and he's the only one with the expertise to do anything about it.
Jan 12 16:40:27 <nman64>	We'll skip that item, then.
Jan 12 16:40:36 <Sopwith>	There are a thousand or so translators who use that site to translate Fedora. Would be nice to get them on board.
Jan 12 16:40:36 <nman64>	fedora.redhat.com migration.
Jan 12 16:41:12 <Sopwith>	That item probably should move to the Websites team
Jan 12 16:41:32 <nman64>	I don't even think it needs any more coverage than what the Websites team already has.
Jan 12 16:41:36 <Sopwith>	Cool
Jan 12 16:41:42 *	Sopwith zaps it.
Jan 12 16:41:43 <nman64>	I think we can close it.
Jan 12 16:41:53 <nman64>	Pootypedia
Jan 12 16:42:17 <Sopwith>	Needs coding help.
Jan 12 16:42:39 <nman64>	Forgive my ignorance, but what is it?
Jan 12 16:42:52 <nman64>	I know it was a SoC project, but I don't remember any details.
Jan 12 16:42:54 <Sopwith>	Basically it collects all your hardware info and sends it to a CGI.
Jan 12 16:43:09 <Sopwith>	It would let us figure out which hardware is most important to have working for Fedora Core releases.
Jan 12 16:44:09 <Sopwith>	Sounds like yet another thing to ask for volunteers on.
Jan 12 16:44:39 <Sopwith>	Oh, I need to add one more TODO item to the list.
Jan 12 16:44:41 <nman64>	Indeed.  We'll add that to our call.
Jan 12 16:45:07 <Sopwith>	Greg wants to have a schwagtracker to help track fulfillment requests for schwag that needs to go to ambassadors
Jan 12 16:45:26 <nman64>	Is that something we could combine with our request tracker?
Jan 12 16:45:33 <Sopwith>	Hmm, good point.
Jan 12 16:45:36 <Sopwith>	Quite possibly.
Jan 12 16:45:46 <nman64>	Let's just note that on that item, then.
Jan 12 16:46:10 <nman64>	If we have to break it off into something else, we'll know when we select the request tracker.
Jan 12 16:47:02 <Sopwith>	Alrighty, any other items to add to the todo list?
Jan 12 16:47:20 <imlinux>	none that I can think of.
Jan 12 16:47:31 <nman64>	I think that will cover it for this week.  There's nothing stopping us from bringing new items up on the list.
Jan 12 16:47:38 <Sopwith>	Absolutely.
Jan 12 16:48:09 <Sopwith>	Sorry for the long meeting. I'll try to keep it shorter next time.
Jan 12 16:48:45 <nman64>	We had a lot of introductory material to cover.
Jan 12 16:48:51 <Sopwith>	Any last words?
Jan 12 16:48:54 <imlinux>	We should post an itinerary next time with a 1-10 or whatever of what to discuss.
Jan 12 16:49:16 <nman64>	That's what the schedule page is for.  :-)
Jan 12 16:49:23 <imlinux>	although I guess the schedule page already has that
Jan 12 16:49:28 <imlinux>	heh :-P
Jan 12 16:50:01 <Sopwith>	3..
Jan 12 16:50:03 <Sopwith>	2..
Jan 12 16:50:03 <nman64>	Sopwith: Work your meeting management magic.
Jan 12 16:50:05 <Sopwith>	1..
Jan 12 16:50:13 <Sopwith>	-- MEETING OVER --