[01:12] <dan325> My Ubuntu 6.06 server suddenly quit recognizing my usb printer.  I am getting "usb 1-1: device descriptor read/64, error -110" messages in /var/log/syslog and the printer does not show up in lsusb.  It was working just fine last week.
[01:20] <leonel> bad  hw ?
[03:52] <hyphenex> Where can I find a list of packages that are in the Ubuntu server?
[03:55] <hyphenex> I can't?
[04:05] <Echoside> Anyone know of any opensource streaming software? I want to start a internet radio stream but cant find any decent program.
[09:07] <ivoks> hello
[09:14] <shawarma> morning, ivoks!
[09:19] <ivoks> i'll try to join you on bugday, but i have exam tomorrow (and today), so i'm not sure how much i'll be able to do
[09:21] <shawarma> Fair enough. Remember that bug day is all of wednesday in every timezone, so it actually starts in about 5 hours and ends 48 hours after that :)
[09:22] <shawarma> ivoks: Good luck with your exams, though.
[09:22] <ivoks> :)
[09:22] <ivoks> thanks
[09:23] <shawarma> ivoks: Anything interesting?
[09:25] <ivoks> yeah, i just discovered vimperator plugin for firefox :)
[09:25] <ivoks> makes firefox usable :)
[09:25] <shawarma> I meant your exams :)
[09:25] <ivoks> ah... roads crossings is one, and other is canals and sewage :)
[09:26] <shawarma> Uh.. What are you studying?
[09:26] <ivoks> civil engineering
[09:26] <shawarma> I see. Heh.. I assumed some sort of computer science :)
[09:27] <ivoks> hehe no, i 'middle school' was about electronics
[09:27] <ivoks> that's where i discovered linux, back in '97.
[09:30] <ivoks> what about you? except linux2go...
[09:32] <shawarma> Finished high school in 2000, worked as developer/sysadmin for 5 years, university (math/computer science) for two years, and now Canonical.
[09:32] <shawarma> Linux since... '96, I thin.
[09:32] <ivoks> nice
[10:22] <crummygummy_> Hiya, if I need to make changes to my my.cnf file should I put it in /etc/default/mysql? I remember Ivoks mentioning that the other day and I just want to confirm that it'll work.
[10:24] <shawarma> If you want to change my.cnf, you should change my.cnf ?
[10:25] <coNP> crummygummy_: I guess you should
[10:25] <coNP> maybe keeping a backup copy is a good idea
[10:26] <crummygummy_> Thanks, I'll give it a stab...
[10:34] <crummygummy_> shawarma, So it won't work. I'm just looking at avoiding a few of the disasters I've had in  the upgrade for future upgrades. It seems that keeping my changes in the /etc/default/* is the way to go. Is that right. Does that count for mysql?
[10:35] <shawarma> Files in /etc/default/ are generally considered configuration files and hence will not be overwritten without your consent.
[10:36] <crummygummy_> so mysql doesn't make use of this?
[10:37] <shawarma> what?
[10:37] <shawarma> I'm totally not understanding any of this.
[10:37] <shawarma> :)
[10:38] <shawarma> You say that you want to change my.cnf, but put those changes into /etc/default/mysql... Next you say "So it won't work"...What won't work? Why do you want to any changes you want to do to file foo into file bar?
[10:38] <shawarma> And what do you mean by "mysql doesn't make us of this"? Of what? 
[10:39] <crummygummy_> K, I'll try be more clear.
[10:40] <crummygummy_> When you put changes into /etc/default/mdadm those changes get propogated through to /etc/mdadm/mdadm.conf. right?
[10:42] <coNP> I guess not 
[10:42] <coNP> there are configuration options that can be edited in /etc/default/* and others that cannot 
[10:43] <coNP> so there is no consistency
[10:43] <crummygummy_> I'm just trying to find out if mysql is one of those packages. I pressed one wrong button in the upgrade and my configuration got over written.
[10:44] <coNP> is there no backup with a suffix that contains "dpkg"?
[10:46] <crummygummy_> Yes there is but I didn't know to look for it so I copied the my.cnf from the slave and altered it.
[10:48] <crummygummy_> Heres a quote from my irc log
[10:48] <crummygummy_> Jun 13 18:07:47 <ivoks> CrummyGummy: great
[10:48] <crummygummy_> Jun 13 18:07:59 <ivoks> CrummyGummy: just, don't add stuff to my.cnf
[10:48] <crummygummy_> Jun 13 18:08:09 <ivoks> CrummyGummy: add it in files in /etc/mysql/conf.d/
[10:48] <crummygummy_> Jun 13 18:08:27 <ivoks> CrummyGummy: it makes upgrade of packages easier, *a lot*
[10:48] <crummygummy_> I was just trying to confirm if this was correct.
[10:50] <coNP> I am not a mysql expert
[10:50] <coNP> but seems true
[10:59] <shawarma> crummygummy_: It says "/etc/mysql/conf.d/"
[10:59] <shawarma> crummygummy_: There's no mention of /etc/default anywhere.
[11:04] <crummygummy_> stupid me.... So, I need to make a /etc/mysql/conf.d/my.cnf and put in all my changes?
[11:05] <shawarma> Just /etc/mysql/conf.d/somenamethatmakessensetoyou
[11:09] <crummygummy_> K, I'll try that. Thanks.
[11:42] <crummygummy_> shawarma, Sorry, stupid question. does the above somenamethatmakessensetoyou file get used on installation or is it sourced on startup?
[11:43] <shawarma> crummygummy_: It's just like putting stuff into /etc/mysql/my.cnf
[11:44] <crummygummy_> Awesome, thanks.
[11:47] <crummygummy_> k, well that didn't work at all.
[11:47] <crummygummy_> can there be multiple files there?
[11:51] <shawarma> Sure. That's the entire point.
[11:57] <crummygummy_> The perms are right and the file format looks right. Its still not working though. Where is the line that tells it to source this dir?
[11:57] <shawarma> Last line of a /etc/mysql/my.cnf
[11:57] <shawarma> !includedir /etc/mysql/conf.d/
[11:58] <shawarma> Which version are you on?
[11:58] <crummygummy_> mysql-server/feisty uptodate 5.0.38-0ubuntu1
[11:59] <crummygummy_> But I prolly didn't let it over write my config because of my own stuff being there.
[12:04] <crummygummy_> shawarma, How do I extract the default config?
[12:06] <shawarma> crummygummy_: What are you looking for?
[12:08] <crummygummy_> the default my.cnf. 
[12:12] <bje> hi - anyone able to tell me what magic foo I need to do, to make a 2.6.20 (i386) kernel netbootable? I would like to install Dapper 6.06 LTS, but my LSI RAID controller is not supported in <2.6.20.  I've tried mkinitramfs, and setting BOOT=nfs, and MODULES=netboot - am I on the right track?
[12:14] <`6og> i dont understand the question
[12:15] <bje> OK. I am trying to install Ubuntu Dapper. Because it's an LTS release.  My RAID controller is not being picked up by the installation.
[12:16] <bje> I found that Feisty's kernel (2.6.20) supports my RAID controller.  I would like to now make a initrd.gz archive of the 2.6.20 kernel (that detects my hardware), so that I can use that for my kickstart installation.
[12:18] <`6og> i dont know aobut building kernels, but i susepct you can find a good tute on the forums
[12:36] <directhex|work> shawarma, IMHO, what ubuntu server needs is a kernel that works on, well, servers. in the end I had to abandon a dapper deployment because it had no adequate support for the jan-2007 hardware we had bought
[12:38] <shawarma> directhex|work:  Yeah, that's a problem. We're aware of it. Of course it doesn't help you much but the next LTS will have infrastructure to take care of this (backporting of drivers for important hardware).
[12:39] <directhex|work> shawarma, and #98979 ?
[12:39] <shawarma> directhex|work: In gutsy there's already a linux-backport-modules-kernelversion-abi-flavour
[12:40] <shawarma> Fixed.
[12:40] <shawarma> Well, not in dapper.
[12:40] <shawarma> I remember talking to the kernel dudes about it a while ago. I don't exactly remember the outcome, though.
[12:40] <directhex|work> shawarma, as you say, a little late for us. the irony is i started this project building on top of sarge, then moved to dapper for exactly the same reason we dumped it
[12:40] <shawarma> Since edgy, we include *all* block device drivers in the initrd.
[12:41] <directhex|work> hence using etch. it's all about the hardware support
[12:42] <shawarma> Yeah. Without hardware support, the software doesn't matter much.
[12:43] <directhex|work> why was the linux-image-2.6.15-50-foo kernel abandoned? it was an improvement
[12:43] <directhex|work> at least it contained a working megaraid_sas.ko and bnx2.ko
[12:43] <shawarma> -50 ?
[12:43] <directhex|work> it's super secret!
[12:44] <shawarma> It must be :)
[12:44] <shawarma> I don't track git, but the most recent uploaded version has ABI version 28.
[12:44] <directhex|work> https://launchpad.net/ubuntu/+source/linux-source-2.6.15/2.6.15-50.61
[12:44] <shawarma> Anyhow, /me -> lunch.
[12:44] <directhex|work> uploaded 2007-01-23
[12:45] <shawarma> What the...
[12:45] <directhex|work> t'is abandoned, as far as i can tell. it worked with modern hardware, but someone got bored & went home
[12:45] <shawarma> Ah, yes, there it is.
[12:45] <shawarma> It's still in proposed. It  probably lacks testing.
[12:46] <directhex|work> there have been three subsequent security updates. and since nobody bothered with -restricted-modules for it, it's non-trivial for many people to test
[12:47] <shawarma> You need restricted drivers on your servers?
[12:48] <shawarma> directhex|work: The kernel guys are on US time, so you can ask them in #ubuntu-kernel in about 5-6 hour's time if you care enough. :) I'll probably poke them about it too.
[12:48] <directhex|work> no. but without restricted being available, linux-meta gets confused, and it starts getting rather painful to make an installer out of the thing
[12:48] <shawarma> directhex|work: Ah, right.
[12:48] <directhex|work> you're also rather restricted on the number of people who can test your kernel if you restrict it to server-only
[12:48] <shawarma> directhex|work: Sure, good point.
[12:48] <directhex|work> ignore me! go eat lunch!
[01:04] <bje> hah, explains pretty much the shit I'm having right now.
[01:04] <bje> *sigh*
[04:00] <mossholderm> Hey... I have a bug that might be worth looking at for the bug day... it is currently misfiled under heimdal... Bug #99795
[04:01] <mossholderm> Bascially , the libldap2 package points to a different ldapi socket than libldap-2.3.0
[04:03] <shawarma> Right.
[04:03] <mossholderm> Can we get it moved under openldap, rathern than heimdal, so that it gets noticed?
[05:04] <bje> Other than ubuntu-server@lists.ubuntu.com, what's another good list to post server related questions to?
[05:07] <Burgundavia> development or help?
[05:11] <mathiaz> mossholderm: I think the latest version of the ldap package has a fix for the bug.
[05:13] <bje> Burgundavia: help
[05:13] <Burgundavia> -users can sometimes
[05:17] <mossholderm> mathiaz - latest for feisty, or do you mean in gutsy?
[05:19] <mathiaz> mossholderm: in gutsy
[05:19] <mossholderm> 'k, thanks!
[07:06] <roottoor> Hi all
[07:11] <roottoor> Any one here know ho I can setup my server to email me logs to like a gmail account
[07:11] <roottoor> so i can monitor them ?
[07:15] <coNP> roottoor: try to install logwatch a / o logcheck
[07:15] <jdstrand> roottoor: install logcheck and setup your mailserver to forward to a smarthost
[07:15] <jdstrand> roottoor: by s/mailserver/server/
[07:16] <coNP> there is no need for a smarthost, it is enough either to setup logcheck  or to edit /etc/aliases
[07:17] <jdstrand> hmm... I remember having to tweak exim in order to get it to work, maybe I am remembering wrong
[07:18] <roottoor> So than I have to have a mail server setup to do that ?
[07:18] <coNP> you can edit  SENDMAILTO="root" line in /etc/logcheck/logcheck.conf
[07:19] <coNP> oh you are right, you need an smtp server
[07:19] <coNP> but I guess exim is installed by default
[07:20] <jdstrand> roottoor: it doesn't have to be a full on mail server that sends and receives mail, just one capable of forwarding email to your ISP or gmail account
[07:20] <roottoor> ok so I need a smtp server. Postfix or sendmail will do that will it not ?
[07:21] <jdstrand> absolutely.  If all you want to do is forward, you may want to try ssmtp.
[07:21] <roottoor> ssmtp ?
[07:22] <jdstrand> apt-get install ssmtp (its in universe)
[07:22] <roottoor> ok thats done
[07:23] <roottoor> Now do I install postfix or sendmail or both ?
[07:24] <jdstrand> neither.  man ssmtp
[07:24] <jdstrand> it will simply get mail off this system and send it to a system that knows how to take care of it.
[07:25] <roottoor> ok
[07:26] <roottoor> now all I do is set a cron for the logs ?
[07:26] <jdstrand> if you are using logcheck, that will happen automatically
[07:26] <roottoor> they work together ?
[07:27] <coNP> yes logcheck has also a cron entry that checks for logs and sends email about the most relevant parts
[07:27] <jdstrand> needs an smtp server to work, and ssmtp fits the bill
[07:28] <roottoor> ok
[07:28] <roottoor> I think I understand now
[07:29] <roottoor> so now i have to edit the confige file of logcheck correct ?
[07:29] <jdstrand> yes
[07:29] <coNP> not necessarily
[07:29] <jdstrand> well-- that or aliases
[07:30] <coNP> it might be a good idea to forward all mail that your root receives to a mailbox you will actually read
[07:30] <roottoor> /etc/aliases ?
[07:30] <coNP> that can be done with and appropriate /etc/aliases entry
[07:30] <roottoor> ok
[07:31] <roottoor> what exactly do I enter i have that  file open now
[07:32] <jdstrand> something along the lines of:
[07:32] <jdstrand> root: username,someone@isp.com
[07:32] <jdstrand> then run newaliases
[07:33] <jdstrand> will go to local mailbox for username as well as being sent off to someone@isp.com
[07:34] <roottoor> when I run  sudo -u logcheck logcheck it tells me "Can't send mail: sendmail process failed with error code 1"
[07:34] <roottoor> also when i ran "newaliases" it told me "newaliases: Aliases are not used in sSMTP"
[07:38] <jdstrand> ah-- that's right-- ssmtp doesn't do aliasing.  sorry.  Let me look at something...
[07:39] <roottoor> k 
[07:39] <roottoor> no worries
[07:44] <shawarma> mathiaz: I've had an idea how we can handle the configuration files really easily with ebox..
[07:45] <roottoor> ssmtp: Cannot open mail:25
[07:45] <roottoor> thats the error i get now
[07:45] <jdstrand> 'mail' needs to be a resolvable hostname
[07:46] <roottoor> oh
[07:46] <shawarma> mathiaz: In a perfect world, the admin should be able to edit the config files and have ebox gracefully handle that (some sort of config file merging of sorts)..
[07:47] <shawarma> mathiaz: In the almost-perfect world (this one) we'll just put in a HUGE comment at the top that "THIS FILE WAS AUTOGENERATED. IF YOU EDIT IT, YOUR CHANGES *WILL* BE LOST. INSTEAD PUT YOUR CHANGES INTO <the name of the template>!"
[07:48] <shawarma> mathiaz: Now I just have to figure out how we handle it if the user changes the templates and the templates are changed on an upgrade of ebox..
[07:49] <shawarma> mathiaz: But I think the reference to templates will fulfill almost every need. We could even move the templates into /etc with a .tmpl suffix so they're even more obvious.
[07:49] <Burgundavia> from an admins perspective, that makes sense
[07:49] <shawarma> I am so clever.
[07:49] <Burgundavia> I bite my tongue
[07:49] <shawarma> On purpose?
[07:49] <shawarma> That's just silly.
[07:50] <Burgundavia> yes, on purpose
[07:50] <shawarma> Was it all you hoped it would be?
[07:51] <Burgundavia> it was bloody and slightly salty
[07:51] <Burgundavia> although almost, but nothing like a real meal
[07:51] <nealmcb> shawarma: the user would also be warned on upgrade about template changes, assuming they are marked as config files, right?
[07:51] <shawarma> nealmcb: Yes.
[07:52] <nealmcb> Burgundavia: yeah - in that case you have to calculate _net_ calories...
[07:52] <shawarma> nealmcb: It it were me (and it's going to be) I'd be annoyed, but I guess it's manageable.
[07:52] <Burgundavia> nealmcb: thankfully, I am not on a diet
[07:52] <Burgundavia> anyway, back in flash, kernel reboot
[07:52] <shawarma> Only kernel?
[07:52] <shawarma> Spiffy.
[07:53] <nealmcb> shawarma: it's only a reboot of the flash kernel :-)
[07:53] <shawarma> Ah.
[07:53] <jdstrand> roottoor: make sure you have /etc/ssmtp/ssmtp.conf setup correctly.  Then do 'echo test | mail -s test1 someone@isp.com' (where someone@isp.com is your email address), then check /var/log/mail.log for success or not.
[07:54] <jdstrand> roottoor: once you have that going, you can modify logcheck.conf to use that email address.
[07:54] <roottoor> ok ill check it now
[07:55] <jdstrand> roottoor: this is working fine here.  You might try this for using with gmail: http://forums.gentoo.org/viewtopic-t-412468.html
[07:55] <jdstrand> roottoor: don't have a gmail account
[07:59] <roottoor> ok i followed that
[08:00] <roottoor> now to test it do I run echo test | mail -s test1 someone@isp.com'
[08:00] <jdstrand> yep-- where someone@isp.com is probably your gmail account
[08:05] <roottoor> it works !!
[08:05] <roottoor> now
[08:05] <roottoor> I got a email from logcheck
[08:05] <roottoor> but than it sent anothe email right from the mailer deamon
[08:06] <roottoor> Delivery to the following recipient failed permanently:
[08:06] <roottoor>    postmaster@static.belkin
[08:06] <roottoor> Technical details of permanent failure:
[08:06] <roottoor> PERM_FAILURE: DNS Error: Domain name not found
[08:06] <roottoor> I dont know what is wrong
[08:06] <jdstrand> roottoor: are you saying that the echo worked but the logcheck didn't?
[08:07] <roottoor> no it did
[08:07] <roottoor> I got the log
[08:07] <roottoor> but I got a email from the mailerdeamon at the same time I recived the log check
[08:08] <jdstrand> roottoor: you had previously had ssmtp setup incorrectly with gmail-- when you were testing ssmtp to get it to work right, those things got logged.  logcheck ran, and told you about it.  check the timestamps.  It should verify what I am saying.
[08:08] <roottoor> ok
[08:08] <roottoor> let me loog
[08:09] <jdstrand> logcheck reports any anomolies it finds since the last time it ran
[08:09] <jdstrand> anomalies
[08:09] <Burgundavia> ok, I hate NM right now
[08:14] <jdstrand> roottoor: keep in mind, coNP was right about it being useful to have local mail go to a particular user.  If the network connection is down, then you lose that mail.
[08:14] <jdstrand> roottoor: ssmtp can be very useful, but know that it has limitations.
[08:15] <roottoor> the first line in ssmtp.conf says "The person who gets all mail for userids < 1000
[08:15] <roottoor> # Make this empty to disable rewriting."
[08:15] <roottoor> do I make that my gmail email or a name ?
[08:16] <roottoor> "root=blah@gmail.com"
[08:16] <roottoor> or just make it a name like "root=blah
[08:18] <roottoor> alos
[08:19] <roottoor> where do i add my eamil in logcheck.conf there isnt a line for it
[08:19] <roottoor> nvm
[08:19] <roottoor> i found it
[08:19] <roottoor> :)
[08:21] <roottoor> Ok
[08:21] <Burgundavia> shawarma: shiny with the ebox stuff
[08:21] <roottoor> Is there a way to gen a report about the logs now to test it
[08:22] <shawarma> Burgundavia: The config handling bit?
[08:22] <Burgundavia> everything
[08:22] <Burgundavia> it is all very shiny
[08:22] <Burgundavia> and now I need to go to lunch
[08:22] <shawarma> Burgundavia: Alright. ttyl
[08:22] <jdstrand> roottoor: sudo /etc/cron.d/logcheck
[08:28] <roottoor> says command not found
[08:30] <ivoks> sudo?
[08:30] <jdstrand> roottoor:  sorry /etc/cron.daily/logcheck
[08:31] <jdstrand> roottoor: no it is /etc/cron.d/logcheck
[08:32] <jdstrand> jdstrand: hrmm...
[08:33] <jdstrand> sudo -u logcheck /usr/sbin/logcheck -R
[08:33] <jdstrand> doing too many things at once...
[08:34] <mathiaz> shawarma: for the configuration file in ebox: it seems a good idea to me.
[08:35] <mathiaz> shawarma: I think ipcop does the same way. As long as the pointer to the template is kept up-to-date, it should be good.
[08:35] <mathiaz> shawarma: how are the template written ?
[08:36] <shawarma> mathiaz: Magically.
[08:37] <mathiaz> shawarma: what's the template engine used ?
[08:37] <mathiaz> shawarma: I think it was perl-template
[08:37] <shawarma> Mason
[08:37] <mathiaz> shawarma: is it intrusive ? the template file should be really close to the orginal file.
[08:38] <roottoor> that last command worked
[08:38] <shawarma> It is *very* close.
[08:38] <roottoor> sudo -u logcheck /usr/sbin/logcheck -R
[08:38] <mathiaz> shawarma: so that sysadmin to have to learn yet another config langage
[08:38] <shawarma> It has a header that declares the variables, and then it's just a matter of putting something like <% Port %> in where you want the value of the port attribute.
[08:39] <roottoor> now does that mean that it is inthe cron for daliy ? or horly or is it not in there at all
[08:39] <shawarma> mathiaz: I think it's very, very straightforward.
[08:39] <mathiaz> shawarma: and what if the sysadmin still change the config file ?
[08:40] <mathiaz> shawarma: eg, he could follow a tutorial 
[08:40] <mathiaz> shawarma: and copy files around.
[08:40] <mathiaz> shawarma: and when ebox is run, it overrides everything.
[08:40] <mathiaz> shawarma: I still think ebox should warn if the target configuration files has some modifications.
[08:41] <mathiaz> shawarma: but there is no point in trying to merge things automatically.
[08:42] <roottoor> jdstrand: now how do I add it to the cron
[08:42] <mathiaz> shawarma: for the case of an upgrade of ebox, well it's exactly the same problem.
[08:43] <mathiaz> shawarma: instead of using to ebox to handle local modifications, the debian packager is responsible for handling local modifications
[08:43] <jdstrand> roottoor: it is already there
[08:43] <roottoor> oh
[08:44] <jdstrand> look in /etc/cron.d/logcheck to prove it to yourself
[08:44] <mathiaz> shawarma: the difference between the two is that the debian packager already has the infrastructure to handle local modifications of configuration files.
[08:44] <roottoor> now is this just sending me the auth log or syslog ?
[08:45] <jdstrand> man logcheck
[08:45] <jdstrand> /etc/logcheck/logcheck.logfiles is the list of files to monitor
[08:47] <shawarma> mathiaz: Sure. I've just never found that particular solution very elegant. I haven't got a better idea, it just always felt kind of kludgy.
[08:47] <shawarma> mathiaz: wrt to the admin following a tutorial:
[08:48] <roottoor> Cool
[08:48] <shawarma> mathiaz: I think that ebox itself removes the need for most tutorials.
[08:48] <roottoor> Thanks to all
[08:49] <shawarma> mathiaz: So.. Well, I don't think the problem will be very big.
[08:49] <jdstrand> roottoor: np
[08:49] <mathiaz> shawarma: It's true that ebox is supposed to handle most of the situation.
[08:49] <mossholderm> shawarma - just curios... are you talking about this ebox?   -> http://ebox-platform.com/
[08:49] <mathiaz> mossholderm: yes
[08:50] <shawarma> mossholderm: Yes.
[08:50] <mathiaz> shawarma: if ebox cannot be used to configure a specific aspect of the system
[08:50] <mathiaz> but still be used for another aspet
[08:51] <mathiaz> it would be great to support that scenario.
[08:51] <mathiaz> Example: ebox can manage ldap user accounts and information.
[08:51] <mathiaz> and the end user wants to use it because it does the job.
[08:52] <mathiaz> but the ldap server requires the usage of ssl.
[08:52] <mathiaz> so an experience sysdamin changes the configuration file on the server to support secured ldap, but the end user still wants to use ebox to manager user accounts
[08:53] <mathiaz> ebox should be able to handle that kind of scenario.
[08:53] <shawarma> mathiaz: end user == admin
[08:54] <mathiaz> shawarma: yes and no.
[08:54] <mathiaz> shawarma: in the above scenario, the end user is a junior admin
[08:54] <mathiaz> shawarma: he asks/hires a more experienced admin to make his server work
[08:55] <mathiaz> shawarma: once the server works in the environemnt there is no need to have the experienced sysadmin around
[08:55] <mathiaz> shawarma: the junior admin/end user uses ebox for his day-to-day management
[08:56] <dendrobates> shawarma: that is a very common use case, a "unix engineer" configures the box, but the access control team adds and removes users. 
[08:56] <ivoks> right, i get those kind of request every day :/
[08:56] <mathiaz> I used the ldap example because I had to deal with that
[08:57] <mathiaz> there is no good ldap admin tool to manage users.
[08:57] <ivoks> same is with mail; set up a mail server and end-user wants to add/remove users
[08:57] <dendrobates> but that leans more towards role-based access control.
[08:57] <mathiaz> but samba could be use as another example
[08:58] <shawarma> Um.. I'm not entirely sure that fits in our use case anyway.
[08:58] <dendrobates> A user should have certain privileges based on that users role.  be it system admin or operator, or auditor.
[08:58] <shawarma> We're providing this for small businesses mostly.
[08:59] <dendrobates> shawarma: that is what I am saying, that belongs as apart of a larger initiative later, if we do role based access, which I hope we do.
[09:00] <shawarma> Besides, if the use case, you're suggesting is "some more knowledgeable dude stops by and sets new, shiny stuff up", then he should be able to spot the huge warning about the config file getting overwritten.
[09:00] <shawarma> If not, he should at least notice during his testing.
[09:00] <shawarma> It's next to impossible to safe guard against knowledgeable, but ignorant users. Especially those with the root password.
[09:00] <mathiaz> shawarma: that's right. I agree that the warning in the configuration file and the pointer to the template file may be enough
[09:01] <shawarma> s/ignorant/unattentive/
[09:01] <shawarma> dendrobates: ebox will learn role based access stuff relatively soon.
[09:01] <shawarma> dendrobates: If not for gutsy, then at least for gutsy+1.
[09:02] <mathiaz> shawarma: but I still think that ebox should not overwrite files that have local modification without warning the user
[09:02] <dendrobates> shawarma: shawarma: s/knowledgeable/privileged/
[09:03] <shawarma> mat..
[09:03] <shawarma> oh.
[09:03] <dendrobates> shawarma: is ebox at a state where I can look at it?
[09:04] <shawarma> dendrobates: Almost, but not quite. I'll demo it at the sprint next week.
[09:04] <shawarma> dendrobates: You may be able to get a sneak preview before then.
[09:04] <lcdd> this ebox seems much like webmin
[09:05] <dendrobates> shawarma: is it this? http://ebox-platform.com/  
[09:05] <shawarma> dendrobates: I'll upload some new packages to my ppa later tonight, I think. You can grab them from there, but (standard disclaimer) DO NOT INSTALL IT ON A SYSTEM YOU CARE ABOUT. IT *WILL* EAT YOUR DATA.
[09:05] <shawarma> dendrobates: Sure is.
[09:05] <shawarma> dendrobates: Shiny, huh? :)
[09:06] <dendrobates> shawarma: I don't care about any of my systems.  Bring it on. ;)
[09:06] <ivoks> looks very nice (much better than webmin :)
[09:06] <shawarma> webmin, how I loathe thee.
[09:06] <ivoks> we all do
[09:07] <lcdd> i've never heard or seen anyone actually use webmin, even though it has been around for a while
[09:08] <dendrobates> There have been major security issues with webmin, I would be afraid to touch it.
[09:08] <shawarma> mralphabet: I think that's were I used it too. That's double pain!
[09:08] <shawarma> dendrobates: ..except with an axe or a huge magnet, of course.
[09:09] <mralphabet> shawarma: I enjoyed slackware, nice and straightforward most of the time
[09:10] <dendrobates> shawarma: were you working on ebox before you started at canonical?
[09:10] <shawarma> mralphabet: Yeah. Just like a rusty spear coming right at you.
[09:10] <mossholderm> shawarma - I have been working on integrating a few of the same components into a feisty derivative , but am not nearly as far along as ebox... one thing I came across that was useful was using heimdal-kdc, in addition to openldap, with the smbk5pwd openldap module to get single-signon working 
[09:10] <shawarma> dendrobates: Nope.
[09:10] <mralphabet> shawarma: hah
[09:11] <shawarma> mossholderm: Yeah. I'm hoping to add kerberos support, too.
[09:12] <dendrobates> We need to do alot of kerberos/auth type of work.
[09:12] <dendrobates> It's the area that Ubuntu is really lacking.  
[09:12] <mossholderm> I'll send you a link to my notes, there are a couple of things that take some beating to get working
[09:12] <jdstrand> shawarma: is the plan to have ebox be a part of ubuntu server?
[09:13] <shawarma> jdstrand: optional part, of course, but yes.
[09:13] <jdstrand> shawarma: and this is webmin-like in that it runs on a webserver?
[09:13] <shawarma> jdstrand: You're not going to get it if you don't want it.
[09:13] <shawarma> jdstrand: Yes.
[09:13] <mossholderm> e.g. the bug I asked about earlier, and the bug in heimdal-kdc that makes password changes not work when the account is also a samba account
[09:14] <jdstrand> shawarma: i understand-- I was just trying to see what it does because I haven't seen it before.  So it does modifications to the local machine only?
[09:14] <shawarma> jdstrand: Currently, yes.
[09:14] <shawarma> jdstrand: There's multi-server support on the roadmap somewhere.
[09:15] <jdstrand> shawarma: how many canonical employees are working on it?
[09:15] <shawarma> jdstrand: Just one.
[09:15] <shawarma> jdstrand: At the moment.
[09:15] <shawarma> jdstrand: I can manage it.
[09:16] <jdstrand> jdstrand: I see.  I ask all this because I was thinking about a system that would make it easier for users to administer their servers, but it takes a different approach.
[09:16] <shawarma> jdstrand: Do tell.
[09:17] <jdstrand> shawarma: well, right now I just have the building blocks in place, with one example module/plugin for bind authoritative zones.
[09:18] <shawarma> jdstrand: Alright. That sounds like a different niche.
[09:18] <jdstrand> the idea is that it can read configuration files and such, but only touches the parts it knows about, and won't overwrite other changes.  It might rearrange things, but won't remove anything (kind like the samba configurator).
[09:19] <dendrobates> shawarma: how are the upstream developers, easy to work with?
[09:19] <shawarma> dendrobates: *very*
[09:19] <jdstrand> shawarma: it doesn't run in a webserver, but instead will work with whatever file you give it.
[09:19] <shawarma> dendrobates: Extremely friendly and helpful.
[09:20] <jdstrand> shawarma: it leaves the deployment of the config up to the administrator.  So he/she can use rsync, ssh, cfengine, whatever.
[09:20] <shawarma> dendrobates: They made my "people I should buy beer" list at first encounter.
[09:20] <mathiaz> jdstrand: that means your framework knows about configuration file format
[09:20] <shawarma> jdstrand: I see.
[09:20] <jdstrand> shawarma: it will allow for cli and gui configuration of these parts.
[09:20] <jdstrand> shawarma: yes-- intimately.
[09:20] <jdstrand> shawarma: but it uses a plugin architecture, so it doesn't get all messy
[09:21] <dendrobates> shawarma: btw, we need to all spend some time at some pubs in London.
[09:21] <shawarma> dendrobates: That does without saying.
[09:21] <nealmcb> dendrobates: right on about the kerberos outages.  E.g. I don't see how to even install it on dapper now, due to some package dependency changes:  https://bugs.launchpad.net/bugs/121923
[09:21] <shawarma> dendrobates: s/does/goes/
[09:21] <jdstrand> it is in the beginning stages, but it can do the SOA, CNAME, A, NS, PTR and MX for bind authoritative zones.
[09:22] <jdstrand> mathiaz: that 'yes intimately' was meant for you
[09:22] <shawarma> dendrobates: It's going to be fun, I think. 
[09:22] <mathiaz> jdstrand: in which langage is it written ?
[09:22] <jdstrand> mathiaz: python
[09:22] <dendrobates> nealmcb: I know it can be done in edgy, but I've never tried to do it in dapper.
[09:22] <jdstrand> mathiaz: so far I just have the cli, which uses python-newt
[09:23] <nealmcb> dendrobates: yeah - I got it installed in feisty also
[09:23] <jdstrand> mathiaz: there is a backend as well as a frontend.  the backend will expose a certain api so any frontend can implement (hence cli or gui).
[09:23] <mossholderm> dendrobates, nealmcb - works in feisty as well
[09:25] <nealmcb> but not having kerberos installs working in the LTS version seems like a significant problem to me
[09:25] <jdstrand> mathiaz: it is OO so there are some interfaces that each backend and frontend will support, so all the different backends and frontends can be combined into some sort of master 'shell'.  So you could run the shell, and get your bind authoritative zones, your apache virtual hosts, your samba shares, etc
[09:25] <nealmcb> so if anyone else can try to reproduce or fix that bug I'd appreciate it
[09:26] <jdstrand> shawarma: the approach is to make the most likely changed parts exposed in an easier to use ui, but leave the full configuration up to an admin as well.
[09:26] <nealmcb> jdstrand: does it have a name?
[09:27] <jdstrand> shawarma: so rather than having it configure every last samba option and trying to reconcile everything, it will just have a 'shares' portion.
[09:27] <nealmcb> jdstrand: sounds like a good approach
[09:27] <jdstrand> shawarma: idea being that debconf gets us close, and it allows users to change the other bits.
[09:28] <mathiaz> jdstrand: there is a wiki page about sysadmin framework : https://wiki.ubuntu.com/SysAdminFrameworkEvaluationCriteria
[09:28] <shawarma> jdstrand: I see. Interesting.
[09:28] <jdstrand> nealmcb: I don't have a name yet
[09:29] <mathiaz> jdstrand: you might have a look at it - it gives some ideas about features for a sysadmin framework.
[09:29] <jdstrand> nealcmb: I have never liked the idea of a webserver with that much power-- not that ebox isn't useful, or even great-- just never personally liked the approach.
[09:29] <jdstrand> mathiaz: I will check it out
[09:29] <mathiaz> jdstrand: a web interface is good for remote administration for end user/ junior sysadmin.
[09:30] <mathiaz> jdstrand: but it should just be a frontend.
[09:30] <jdstrand> mathiaz: absolutely.
[09:30] <mathiaz> jdstrand: the backend (the one that modifies the configuration files) shouldn't be in a webserver
[09:31] <mathiaz> jdstrand: or doesn't have to be in the webserver
[09:31] <jdstrand> mathiaz: ideally-- but as mentioned, ebox does make local changes-- I guess I assumed they would be on the local server, but they could be moved somewhere else.
[09:31] <jdstrand> mathiaz: I don't know anything about ebox-- so I shouldn't comment on it.
[09:32] <mathiaz> jdstrand: yes. If you can separate the backend and the frontend then it's easier to support multiple servers
[09:32] <mathiaz> that's the approache taken by puppet for example
[09:32] <mathiaz> jdstrand: or other framework that do cluster configuration/management
[09:32] <mathiaz> jdstrand: framework
[09:33] <jdstrand> mathiaz: the goal of mine was to just to do the config bits, and leave the deployment to another tool
[09:33] <mathiaz> jdstrand: from the architecture point of view, there an agent that runs on the server and receives the configration to apply.
[09:33] <jdstrand> mathiaz: ala cfengine or similar, I imagine
[09:33] <jdstrand> ?
[09:33] <mathiaz> jdstrand: yes. cfengine is a good example also.
[09:34] <mathiaz> jdstrand: but it doesn't understant the configuration syntax.
[09:34] <mathiaz> jdstrand: it provides some powerfull editing tools/macros.
[09:35] <jdstrand> mathiaz: so its like a remote text editor?  (obviously grossly simplified)
[09:35] <mathiaz> jdstrand: but if you want to make complicated things (like merging information coming from different configuration location) it can be tricky
[09:35] <mathiaz> jdstrand: no. not really.
[09:36] <mathiaz> jdstrand: it's more a declarative langage and you can say things like : if you find this pattern, add this line after it.
[09:36] <jdstrand> mathiaz: oh-- you mean it is one way-- the UI gathers the bits, and it writes it out.
[09:36] <jdstrand> mathiaz: scratch that last comment
[09:38] <jdstrand> mathiaz: well, the framework I am working on is aimed at these same users.  Idea being, get a deafult, sane, secure configuration via debconf, then use this tool to add new stuff to it.
[09:38] <jdstrand> mathiaz: if you want to tweak named.conf logging options (for example), you wouldn't necessarily use this tool.
[09:38] <mathiaz> jdstrand: seems like a good idea.
[09:39] <jdstrand> mathiaz: not that one couldn't write those bits, but, one thing at a time.  :)
[09:39] <mathiaz> jdstrand: small steps first. 
[09:39] <mathiaz> jdstrand: that's what we're trying to do in the end for ubuntu server.
[09:40] <jdstrand> mathiaz: I also liked it because, at least for bind, it is relatively easy to not destroy your SRV or TXT records, while still adding the others.
[09:40] <jdstrand> mathiaz: yes, I hope to be able to contribute to ubuntu server with this software.
[09:41] <mathiaz> jdstrand: that would be great. Don't forget to show your code often so that you can get valuable feedback.
[09:41] <jdstrand> mathiaz: yes, working on it.  ;)
[09:42] <jdstrand> mathiaz: I'd like to read through that link you gave and chew on it
[09:42] <mathiaz> jdstrand: it has some ideas inside. But don't try to implement everything...
[09:43] <jdstrand> mathiaz: oh no. would want help!
[09:43] <jdstrand> :)
[10:12] <mossholderm> later everyone...