#ubuntu-directory 2006-10-26 * Starting logfile irclogs/ubuntu-directory.log * Fujitsu welcomes ubuntulog. (Fujitsu/#ubuntu-directory) Thanks fabbione :) (fabbione/#ubuntu-directory) no problem (ajmitch/#ubuntu-directory) thanks <fabbione> ok it works <fabbione> logs will start to appear on the web within the next hour or so <fabbione> have fun <ajmitch> so watch what you say from now on :P <lophyte> morning all <wasabi> morning <lophyte> how's it going? <wasabi> https://wiki.ubuntu.com/NetworkAuthentication/ScratchPad/Client <-- proofread <wasabi> me->work <lophyte> I'll take a look in a bit..rebooting, brb <lophyte> ergh.. can't get Xen set up <wasabi_> sux <Burgwork> wasabi_: very wordy <Burgwork> might want to cut it down a little <lophyte> Burgwork: know where I can find some info on getting Xen on edgy running? <lophyte> I can't find anything useful <Burgwork> lophyte: no idea <lophyte> dang.. <Burgwork> wasabi_: here is what I would do. Move all that wordy-ness into the wordy sections, like use cases <Burgwork> the implementatin and scope should be point form with very small paragraphs <Burgwork> whiprush: if you don't post to ubuntu-devel about ubuntu-directory by 5pm PDT, I am doing it <wasabi_> Burgwork: I'm writing something up that will be linked from a blog/u-d post <wasabi_> Something for people to read. <Burgwork> much too wordy, even for that <Burgwork> you also need a better intro <wasabi_> Heh. <wasabi_> This also in a way helps me. <wasabi_> Get the ideas fully formed. <Burgwork> tbh, I get bored into the first para <Burgwork> and I care about this stuff <Burgwork> first tell about the high level, then get into the details <Burgwork> with small paragraphs, one with each idea <wasabi_> I have a feeling Mark will like htis anyways, being a business guy. <Burgwork> I am not talking about mark <Burgwork> I am talking about the rest of the world <Burgwork> I don't see a plan to action there <Burgwork> which packages are going to change, etc. <wasabi_> TO BE CONTINUED <Burgwork> it is already too long <robertj_> btw, is Mark still expanding Canonical? Scope keeps increasing, is staff keeping up? <Burgwork> yes, he is <Burgwork> see ubuntu.com/employment <robertj_> Burgwork: is the strategy to replace old maintainers so they can work on new things? <Burgwork> all the moz, kernel, x people? <Burgwork> no, it is more, now we are to the point we need both maintainers and developers <robertj_> just kinda curious, I think my days fiddeling with computers are mostly over <robertj_> I've got a teleworking op I'm hoping will supplement a meager existence while I head back to school <robertj_> hurray for soulless PHP work :( <wasabi_> Burgwork: My main reason for not having a bulleted list is I don't want to reexplain why certain items on such a list are there. "Implement a NSS realm table" doesn't fully tie together WHY it should be done. <wasabi_> And the reasoning for that is pretty wide. <Burgwork> wasabi_: no, currently you have giant paragraphs, without many headings <wasabi_> There will be a short list of actionables when I get to the bottom. <robertj_> wasabi: maybe those should be links? <Burgwork> it is still too long, I am telling you <Burgwork> I tell you this as a marketing person <Burgwork> I will try and dig into it and lunch <whiprush> Burgwork: ok that sounds good. Sorry I dropped the ball on that <Burgwork> whiprush: I will beat you in MTV <whiprush> Burgwork: I have an ubuntu talk tonite at a new lug so I am putting together my slides and totally forgot <Burgwork> ah <whiprush> Burgwork: I will bask your awesomeness <whiprush> Burgwork: do you have the draft we were working on? <Burgwork> no, email it to me <whiprush> davidhull@example.net? <Burgwork> corey.burger <Burgwork> ok googlel is wacked <Burgwork> why do I need a new account? <Burgwork> it already knows who I am <whiprush> dunno <Burgwork> I think that was what sergey was going on about <lophyte> Burgwork: about usus.. when does a client decide to push their dpkg -l ? <lophyte> on boot, on a cronjob.. what? <Burgwork> if changed would be best <lophyte> if what's changed? <Burgwork> if the pakcage information has changed <lophyte> on the server? <Burgwork> no, the client <lophyte> why would it change? <Burgwork> an update? <lophyte> I don't follow.. <Burgwork> when the machines update, their information is going to change <Burgwork> as their might be new versions <lophyte> how can they update if they haven't sent their package list to usus yet? <Burgwork> on initial install and upon any change <wasabi_> Sort of a chicken n egg problem. <lophyte> so you'd have to manually go around to all your computers and force a change before it pushes its package list? <wasabi_> They should push their info right before they update. <wasabi_> They are unrelated actions, actually. <robertj_> can we keep a uid on the server with a last seen timestamp? <robertj_> and send only the names of newly installed packages? <wasabi_> This cron job should just push/update <wasabi_> Nothing else. <lophyte> cronjob? <wasabi_> Or whatever we use. <lophyte> that makes more sense to me.. <wasabi_> Existing update-manager server or whaetver mvo has. <robertj_> also, does it seem inevitable that you will end up tracking packages that are no longer in use? <lophyte> I'm gonna take a look at nwu and see what's already working <robertj_> because person x used to have it but dropped their laptop down the storm drain? <wasabi_> At some point machines expire. <wasabi_> WSUS does that too... it says the last time a machine reported. <wasabi_> And you can just click on it and hit remove. <wasabi_> And then it's no longer considered. <wasabi_> The UI puts little marks next to computers which haven't repoted for 180 days or something <lophyte> so perhaps it should report to the usus server in a cronjob, or on boot <lophyte> in a cronjob preferably <wasabi_> Mine as well just do it everytime the normal update runs. <wasabi_> The reporting is sort of disconnected from the updating. There's no reason for it to happen more often though. <lophyte> you mean the update-notifier? <wasabi_> Yeah. <lophyte> ah, right <wasabi_> The update-notifier can just a report inserted right before it runs update. <lophyte> nwu looks like its completely different than what we've been discussing.. <lophyte> its like a way to remotely administer a client's repo configuration, and force updates <Burgwork> which is needed <lophyte> you can force package installation and such <Burgwork> how much code is there? <wasabi_> Yeah, I think we need that too, but I think that should consider LDAP <lophyte> I think that's outside of the scope of USUS <wasabi_> And other things, like gconf mandatories. <wasabi_> Since those all fall under "configuration" <lophyte> that's more like a configuration management thing, ie. GPOs <wasabi_> Yeah. <Burgwork> if the code exists, no reason to throw it away <lophyte> I agree, but again, it seems outside the scope of USUS.. the code could be integrated into a GPO-like system though <Burgwork> yep <robertj_> when it sends its list of packages, it also needs to send in a list of all components it is subscribing too, correct? <lophyte> you /could/ use nwu in conjunction with usus at the moment, until we have a GPO-like system <lophyte> http://cetico.org/nwu-doc/user-manual.html#d0e327 <lophyte> but it uses SSL and stuff.. which breaks the kerb/ldap theory <lophyte> I'll see if I can use any of it <lophyte> paste warning <lophyte> First of all, how does nwu-agent work? The first time the nwu-agent is run, it will generate its auth information and save it on /var/spool/nwu/, then load system information - including current APT state and send that to the server. The agents will push and pull data to the servers every 10 minutes. They notify the server of the changes (eg: "package 'foo' installed") then get the list of pending tasks. <wasabi_> Seems sort of heavy and complicated. <lophyte> yeah <wasabi_> And very very hard coded to only deal with apt. <wasabi_> I would much rather prefer a generic GPOish thing, where you can push many things: mandatory gconf strings, apt lines, fstab entries, etc. <wasabi_> That hooked to LDAP would be nice. <lophyte> *nods* <lophyte> agreed <wasabi_> I do also think that in large organizations these things are very disconnected. <lophyte> I'd love to work on a GPOish thing.. but USUS is on my mind at the moment <wasabi_> You have people deploying corporate policy, and then some sub departments deploying per-department policy. <wasabi_> And you have people disconnected from that which validate security updates. <wasabi_> security team vs management team <lophyte> hrm, question... <lophyte> what if update groups were determined by OUs rather than group membership? <wasabi_> They sort of are. <wasabi_> Well, actually they're determined by whatever configuration system populates apt. <wasabi_> Which, presumably, would be like GPO, and use OUs <lophyte> ah, right.. <lophyte> like, you'd create a sources.list GPO that uses the testing repo and assign that to the testing OU <lophyte> right? <wasabi_> Yup <lophyte> or a GPO that uses the servers repo and assign that to the servers OU.. <lophyte> k, got it <wasabi_> This brings me to my thoughts on a GPO replacement... which probalby overlaps or eliminated the current NWU. <wasabi_> I'm thinking keep it super simple. You define a set of name/value properties, much like debconf keys. <wasabi_> In fact, exactly like them. <wasabi_> And you come up with some LDAP assignment to determine the full set of keys to apply to a system. <lophyte> I've never seen debconf keys.. <lophyte> will have to look that up <wasabi_> Then you just write them to the system someplace, and leave it up to some client programs to configure themselves based on them. <wasabi_> Which is basically like GPO does. <lophyte> you write them to an NFS share <wasabi_> The GPO results in a set of registery keys being created based on the total sum of all applied GPOs... and client apps have to deal with them. <lophyte> at least, that's how GPO works <wasabi_> Yeah. The name of the template is delivered by LDAP. <lophyte> yeah <wasabi_> The template is just a flat file of name/value pairs. <lophyte> *nods* <wasabi_> + one local template. <wasabi_> I might do it the same, except eliminate NFS, and use a dedicated HTTP server to retrieve the templates. <wasabi_> Since NFS is obviously sucky for a lot of reasons. <lophyte> \\server1\SYSVOL\path\to\gpo <lophyte> store that path in LDAP <wasabi_> Basically you just ask the server for the full set of templates that apply to you, and it delivers them. <wasabi_> That's basically what GPO does, except it doesn't store the path. <lophyte> it's very simple... all the development work will be on the client-side, developing a client that interprets the templates and applies them <Burgwork> sabayon is the beginnings of gpo <wasabi_> It stores the GUID, teh clients retrieve it on it's own. <wasabi_> Yeah I know nothing about sabayon. <lophyte> ah <Burgwork> stores a zip on a server somewhere <wasabi_> zip of what? <Burgwork> pulled down the client and unpacked upon login <Burgwork> zip of gconf keys and other config into <Burgwork> info, rather <wasabi_> per user or for a system? <lophyte> both <Burgwork> per user <lophyte> well, GPO does both <wasabi_> So sabayon doesn't address the system. <Burgwork> I am describing what sabayon does now <wasabi_> ahh <Burgwork> not what it could do <Burgwork> this is part of what federico is working on at Novell <wasabi_> Yeah. <wasabi_> For the user stuff. For the system, I might seriously consider pushing debconf keys. <lophyte> k, I gotta go do some shopping... <wasabi_> I mean... it totally works. <lophyte> I'm gonna send you guys what I've got here <lophyte> feel free to hack it up <lophyte> and rip it apart <wasabi_> Server delivers a set of debconf keys, every key that changes, package gets reconfigured, it applies the values. <lophyte> wasabi_: whats your email? <lophyte> actually <lophyte> nm <wasabi_> davidhull@example.net <lophyte> I'll post it up on a web server <Burgwork> debconf has issues in that it is Ubuntu/Debian specific <wasabi_> Heh. A packages entire configuration is Ubuntu/Debian specific. <wasabi_> Either fix that, or accept it. ;) <lophyte> I thought the point of ubuntu DS was to create an Ubuntu/Debian specific system :P <lophyte> http://www.dave-sullivan.com/usus/-workflow.odg <lophyte> erm <wasabi_> As long as we have package scripts which set up the package and configure it based on debconf keys... the problem will be how to drive that out. <lophyte> http://www.dave-sullivan.com/usus/usus-workflow.odg <lophyte> http://www.dave-sullivan.com/usus/usus-workflow-footnotes.txt <lophyte> that's still a WIP <Burgwork> looks good <lophyte> I still need to finish up the server-side flow for receiving a client's package list, as well as how it determines which updates to download from upstream, and the update approval workflow <lophyte> also.. <lophyte> I moved our braindump: <lophyte> http://wiki.ubuntu.com/UbuntuSUS <lophyte> since it now seems unrelated to NWU <Burgwork> ok, that means we now have three specs <Burgwork> because there is that spec whiprush wrote <lophyte> which one? <Burgwork> update-server <lophyte> https://features.launchpad.net/distros/ubuntu/+spec/ubuntu-update-server <lophyte> this one? <lophyte> that one has been supersded <Burgwork> right <lophyte> UUS spec stores package info in LDAP.. and we argued against that yesterday <Burgwork> ok, we need to sort out the interaction between nwu and sus <Burgwork> so that people are not confused <wasabi_> I think we actually just need to make something work, and then people will use it, and the other pages will get deleted. ;) <lophyte> storing credentials and configuration template information in LDAP is what we discussed as the best option I think <lophyte> lol, agreed <Burgwork> yep <lophyte> I can have this operational by some time next week if I worked my ass off on it.. <wasabi_> I personally don't think what's written down on NWU is the right path. I think it's complicated and addresses half of a seperate problem which we will want to fully address anyways. <Burgwork> should we supercede the nwu spec with the sus one? <wasabi_> I think the current USUS idea we have is actually simple. <wasabi_> And doable, quickly. <wasabi_> And immediatly useful. <lophyte> I agree with wasabi <Burgwork> so do I <wasabi_> Sure, we can't deploy sources.list files out of hte box. That's fine. <Burgwork> whiprush: you around? <lophyte> that's done through another mechanism <wasabi_> We can solve that in the same step we figure out how to deploy everything else. <Burgwork> lets change uus and nwu to be superceded by sus <lophyte> yup <whiprush> Burgwork: in and out <whiprush> ok <Burgwork> whiprush: change your superceding stuff to sus from nwu <whiprush> on it <lophyte> should I create a sus spec? <wasabi_> I think so. You should clearly right up what we've talked about, and let the NWU people in on the conversation. <lophyte> alright <Burgwork> whiprush: better, change the dirver of uss to -directory <wasabi_> We need to convince them why we think our approach is better. <wasabi_> And decide where to move from there. <whiprush> okey <Burgwork> lophyte: merge your page to the wiki page of the current https://wiki.ubuntu.com/UpdateServer <Burgwork> lophyte: and then make nwu superceded by uus <Burgwork> there, that is simpler <Burgwork> no three spec <lophyte> alright <lophyte> so merge usus with uus and call it uus? <Burgwork> yep <lophyte> alrighty. <whiprush> ok <whiprush> what am I doing now? <wasabi_> You need to be updated on what we've discussed. <wasabi_> =) <wasabi_> And have your say, etc. <whiprush> yeah <whiprush> how far back do I go in the log? <lophyte> yesterday around this time, lol <whiprush> ok. <whiprush> let me do this spec thing <lophyte> ubuntu-update-server should be the most up-to-date spec <whiprush> ok, so I am changing uus to be merged with usus? <lophyte> yup <whiprush> I superceded it yesterday <whiprush> so do I un supercede it? <lophyte> I think that's what Burgwork wanted <lophyte> merge our discussion into UUS and make it the latest spec <lophyte> right Burgwork? <whiprush> it's ok, I have no idea how to even find my spec now <whiprush> god launchpad makes me cry sometimes <lophyte> https://features.launchpad.net/distros/ubuntu/+spec/ubuntu-update-server <lophyte> though it should be a spec under ubuntu-directory me thinks <wasabi_> whiprush: What we've discussed goes basically like this: <wasabi_> Simple mod_python based web application, which manages a directory of user-created repositories. <wasabi_> The user can create a repository, named whatever he wants, but usually something like "dapper" <wasabi_> And hook it up to one or more upstream repositories. <wasabi_> In this case, he would create a repository named "dapper" and hook it up to "dapper", "dapper-updates" and "dapper-security" * whiprush nods <wasabi_> This would cause a sync to happen periodically pulling the Packages files for each of those upstream repositories, and merging them into the user one. <wasabi_> Under $reposname/proposed <wasabi_> Machines can then be set up to pull from <wasabi_> deb http://localserver/uus/repos dapper/proposed main universe <whiprush> right <wasabi_> That's the latest copy of upstream. <whiprush> ok, spec is given to ubuntu-directory now <wasabi_> Machines will post their entire dpkg database (package names and versions) to the URLS periodically. <whiprush> and unsuperceded <whiprush> wasabi_: and this can be enforced right? <lophyte> I think it should only be posted once <wasabi_> In what way? <wasabi_> lophyte: Has to be posted everytime a new package is installed. <whiprush> wasabi_: well, can a client machine break? <wasabi_> Of course. <wasabi_> This is code we're talking about. <whiprush> heh <whiprush> well <wasabi_> When this happens, the server will use it to determine what packages are installed in various places. And that will drive out the interface of what you should be prompted to approve. <wasabi_> So you'll see an approval interface for "dapper" <whiprush> I meant, so a user with sudo on a client can still remove the stuff right? <wasabi_> listing all packages which have later upstream versions. <whiprush> or will it continue to push to the client? <wasabi_> whiprush: Yup. He can remove it. <whiprush> ok <wasabi_> When you approve a package it moves it into the Packages files within the main repository (non /proposed) <wasabi_> Clients retrieve everything from there. <wasabi_> Testing boxes can test dapper/proposed, all other boxes can use dapper <wasabi_> Approval simply makes it available to the clients in production. <wasabi_> Each user repository will have a seperate pool, where .deb files are kept. <wasabi_> They can be linked from /proposed to non proposed. <lophyte> I don't think you need to send your entire package listing every time.. just once <lophyte> and diff it every other time <wasabi_> I think .deb files should be downloaded on demand somehow. <wasabi_> lophyte: Sure, you could keep the last sent copy <wasabi_> And just send the diff. <wasabi_> I think I might implement that last though <wasabi_> When we determine it really matters. <lophyte> the server would also have a local copy of each client's package list <lophyte> so when it sends the diff, it compares the diff with the package list <wasabi_> whiprush: And that's all it does. It doesn't handle machine groups or anything on it's own. <lophyte> it /can/ be set up to use groups, though <wasabi_> Machine groups are handled by creating multiple repositories: dapper-desktops, dapper-servers, etc. <lophyte> simply by creating multiple repos <lophyte> yeah <whiprush> wasabi_: ok I was just trying to understand the scope <wasabi_> The scope is simply to approve updates to existing packages. <wasabi_> It is not to manage the installation or configuration of client machines. <lophyte> this way, it doesn't introduce any new technology and is built on things that already exist and work <wasabi_> Since we believe that would overlap with other projects seeking to do the same. <lophyte> there should be a separate project to handle configuration settings deployment <wasabi_> As that seperate project will want to take into account other stuff, deploying text files, fstab entries, local user stuff, etc <whiprush> right <wasabi_> Which sort of includes sources.list <wasabi_> This ends up mirroring WSUS basically. <wasabi_> Where WSUS simply approves, GPO deployes pointers to WSUS. <lophyte> I'm gonna go eat and do some shopping.. <lophyte> I'll be back later to finish up the spec <lophyte> i wonder why nwu is approved <lophyte> anywho.. bbl. <wasabi_> Because mvo worked on it <ajmitch> hey people <ajmitch> mvo... and nictuku <Burgwork> nictuku wrote the actual code <Burgwork> mvo just speced it <wasabi_> ahh <ajmitch> lophyte: still having xen issues? <lophyte> ajmitch: yup <ajmitch> followed the XenOnEdgy wiki page? <lophyte> ajmitch: yeah.. I booted up the xen kernel and had X issues.. probably an nvidia kernel module issue.. I didn't get a chance to troubleshoot it yet <Burgwork> ok, uus added to mtv <ajmitch> on i386 or amd64? <ajmitch> there's a xen-restricted-modules package <lophyte> i386 <lophyte> Burgwork: i wish I was going to mtv <ajmitch> you should be fine then <lophyte> I'll try installing xen-restricted-modules <Burgwork> lophyte: you can. It is not that much from to to sfo <lophyte> Burgwork: yeah but I still can't afford it :P <Burgwork> sorry, my funds are tapped <lophyte> unemployed = no money <lophyte> ajmitch: so xen-restricted-modules will provide the nvidia driver? <Burgwork> lophyte: you realize we both have the same diploma from CDI? <lophyte> LOL <lophyte> you went to CDI too? <Burgwork> yep <Burgwork> sadly <lophyte> that's funny <lophyte> yeah, it was horrible <Burgwork> grad with honours? <lophyte> yeah.. though I haven't officially graduated yet <Burgwork> ah <lophyte> they haven't contacted me about when the graduation is supposed to be.. <Burgwork> there are two ways to get out cdi <lophyte> well, I'm done my classes <Burgwork> with honours or not at all <lophyte> hehe <lophyte> I finished with like a 97% average <lophyte> its almost impossible not to graduate with honours <lophyte> the way they just kinda pass you even if you have no clue what you're doing <lophyte> anyway brb, testing xen again <lophyte> no luck <Burgwork> FUCK!!! <Burgwork> guess who is not going to MTV <lophyte> you? <Burgwork> yep <Burgwork> want to go? <ajmitch> damn <Burgwork> potential I might show up midweek <lophyte> i'd love to <ajmitch> there goes my plans of living in luxury for the week ;) <Burgwork> yep <Burgwork> floor for you! <Burgwork> lophyte: give me a number on flights from to to sfo <ajmitch> Burgwork: about what I can afford now! <lophyte> Burgwork: one sec.. gotta find some cheap flights <Burgwork> ok, question <Burgwork> why would a machine, while sitting idle, sponteanously decide to switch to dhcp? <wasabi_> Why aren't you going? <lophyte> Burgwork: thought you said it wasn't much? <Burgwork> wasabi_: work has a big project lined up and it starts next week <lophyte> the lowest I'm getting is like $545 <ajmitch> lophyte: hah, that's nothing compared to flying from NZ <wasabi_> Suck. <lophyte> ajmitch: ;) <wasabi_> Yeah, my tickets were $200. <wasabi_> But I got two. <lophyte> $545 return from to <ajmitch> I'm not unemployed, but I may as well be with the funds I have left :) <lophyte> according to expedia.ca <Burgwork> I'm a fairy princess who likes to sprinkle muffin crumbs like sparkly dust allll over my coworker's shipping table. <Burgwork> I also like goats. <Burgwork> A lot. <ajmitch> hm, do you think someone got to corey's keyboard? <lophyte> wasabi_ from where? <wasabi_> texas <wasabi_> Canonical is paying for me though... so actually I don't have to pay anything. <wasabi_> neiner. <lophyte> hah <lophyte> anyone know where to find cheap flights? * ajmitch is not bitter, no, davidhull@example.net.. ;) <Burgwork> ajmitch: yes, somebody did <Burgwork> my new colleague, Audrey <lophyte> lol <ajmitch> wonderful person, I'm sure <Burgwork> usually I lock my screen <lophyte> Burgwork: $525 return seems the cheapest <Burgwork> let me see <lophyte> don't think the link will work.. <lophyte> http://www.expedia.ca/pub/agent.dll?tovr=-1294697288&ps3u= <lophyte> its about $20 cheaper to go to san jose <Burgwork> aircanada and travelocity are not cheaper <Burgwork> what airline? <Burgwork> try their website <lophyte> $545 return via US Airways <lophyte> I gotta go for a bit... <lophyte> that's the cheapest I can find <lophyte> bbiab <Burgwork> ok, that was odd <Burgwork> where is the dhcp timeout information stored? <Burgwork> lophyte: see /var/log/dpkg.log <lophyte> Burgwork: for? <Burgwork> that shows what dpkg has been doing <lophyte> oh, sweet <lophyte> could use that to let the usus server know what's going on <lophyte> ajmitch: you around? <ajmitch> yes.. <Burgwork> is it within the spec to have the machine report back successfully updating? <Burgwork> basically the machine would send back that piece of the log <lophyte> sure.. that can be added <Burgwork> after update <lophyte> ajmitch: can you point me in the right direction for xen help? <Burgwork> send back the chunk of the log, parsed for the new versions <ajmitch> lophyte: with regards to? <lophyte> seems mostly missing modules.. <ajmitch> what modules? <lophyte> the module for my wifi card isn't loaded either <lophyte> and the nvidia driver is missing <ajmitch> and you have the xen-restricted-modules package that matches the 2.6.17 kernel you're running? <lophyte> yup <ajmitch> (not 2.6.16) <ajmitch> eg xen-restricted-modules-2.6.17-6-generic-xen0 <lophyte> yup <ajmitch> and xen-image-xen0-2.6.17-6-generic-xen0 <lophyte> dpkg -l says its installed <ajmitch> and you created the initramfs, etc <ajmitch> and you have /lib/modules/2.6.17-6-generic-xen0/volatile/nvidia.ko <lophyte> oh.. should I re-create initramfs after installing restricted modules? <lophyte> no, there's nothing in volatile.. <ajmitch> not necessarily, but running depmod -a may help <lophyte> hm.. volatile is empty.. * ajmitch would check why that is <Burgwork> ajmitch: hoping pitti will play ball <lophyte> ajmitch: /lib/linux-restricted-modules/2.6.17-6-generic-xen0/nvidia <lophyte> that dir has a bunch of object files.. <ajmitch> Burgwork: with? <ajmitch> lophyte: right, and the postinst should have linked then <Burgwork> ajmitch: nixing beryl <lophyte> apparently it didn't.. <ajmitch> lophyte: try & run /etc/init.d/linux-restricted-modules-common <ajmitch> Burgwork: fat chance <ajmitch> plenty of crap code is in main <lophyte> ...huh <lophyte> okay, I'm gonna try this from scratch <lophyte> alrighty.. <lophyte> followed the wikipage to the letter <lophyte> brb <lophyte> well, got networking working in the host domain anyway... <lophyte> though I don't think bridging will work in guest domains <lophyte> ajmitch: so far so good, I think <ajmitch> ok <ajmitch> why won't bridging work? <lophyte> ajmitch: we'll find out when I create a guest.. <lophyte> which I'm trying to do now <lophyte> meh.. <ajmitch> as long as the xen config is setup properly <lophyte> not having any luck creating a guest either, lol <ajmitch> ouch :) * ajmitch uses xen-tools for that <ajmitch> nice & simple & fast <lophyte> I'm working on it <lophyte> its running debootstrap right now <lophyte> using the cdrom as the mirror <ajmitch> ok <lophyte> sweet, it finished.. <lophyte> now I do xm create ... right? <lophyte> so far so good <lophyte> sweet, it works <ajmitch> great <ajmitch> sudo xentop <ajmitch> in the dom0 <ajmitch> shows you a nice overview of cpu usage, etc <lophyte> ajmitch: how do I get networking going in the guest? which interface is it? #ubuntu-directory 2006-10-27 <ajmitch> should just be eth0 in the guest <lophyte> it'll act like an additional box on my network? <ajmitch> yes <lophyte> hrm.. <lophyte> it won't even ping itself.. <ajmitch> (network-script 'network-bridge netdev=eth1') <ajmitch> ignore the netdev=eth1 bit <ajmitch> but you should have something like that on the dom0 <lophyte> I do * ajmitch just wanted to make sure it bridged with the wired interface on the laptop, not the wireless <lophyte> though, here's the issue I had... <lophyte> my main interface is ra0 <lophyte> so I did (network-script 'network-bridge netdev=ra0') <lophyte> but then networking wouldn't work on dom0 * ajmitch has had all sorts of fun with bridging.. <lophyte> should I be using eth0 in dom0? <lophyte> dom0/eth0 -> xenbr0 -> ra0 -> network ? <lophyte> and domU/eth0 -> xenbr0 -> ra0 -> network <lophyte> is that how it works <ajmitch> no, the bridging is from domU to dom0 <ajmitch> so only domU/eth0 -> xenbr0 -> ra0 -> network <lophyte> hmm.. <ajmitch> ra0 only exists in dom0 <lophyte> so the question is, why does ra0 break in dom0 when I use network-bridge netdev=ra0 * ajmitch shrugs :) <lophyte> cuz I should be using eth0 in dom0.. <lophyte> I think <ajmitch> why? <ajmitch> do you even have an eth0 in dom0? <lophyte> yeah <lophyte> ugh.. this is confusing.. <ajmitch> just use the interface that's normally connected & it ought to work :) <lophyte> no.. <ajmitch> why it suddenly stops in dom0 is beyond me <lophyte> when I use network-bridge netdev=ra0 <lophyte> ra0 says "no wireless extensions" <ajmitch> hm right <lophyte> though it creates pra0, which has wireless extensions <ajmitch> though this could be why I switched to eth1 (the wired interface) <ajmitch> since the ipw2200 was playing funny tricks <ajmitch> but this was also when i was testing 2.6.16 & the firmware was broken :) <lophyte> but I tried using pra0 and it didn't work either <ajmitch> I haven't set it to use wireless since then <lophyte> I don't really have a choice <lophyte> has to use wireless :| <ajmitch> laptop sits on top of my tower case usually <lophyte> this is a desktop ;) <ajmitch> fun <lophyte> hrm.. <ajmitch> I could hardly put my main box on my desk :) <lophyte> haha <lophyte> okay, its a tower :P <lophyte> not a laptop <lophyte> but.. <lophyte> paste warning <lophyte> nm <lophyte> in /etc/xen/xend-config.sxp, there's a little diagram... <lophyte> dom0: fake eth0 -> vif0.0 -> bridge -> real eth0 -> network <lophyte> domU: fake eth0 -> vifN.0 -> bridge -> real eth0 -> network <lophyte> so if I use netdev=ra0, it becomes "real ra0 -> network" <lophyte> but would the fake ones remain eth0, or become ra0? <ajmitch> hm * ajmitch doesn't know, hasn't checked it <lophyte> and also... <lophyte> is fake eth0 called 'eth0' or peth0? :P <ajmitch> see reponse above <lophyte> hrm <Burgwork> wasabi_: rh uses a joined /etc/ldap.conf <wasabi_> How do they deal with maintainer scripts, or do they not? <Burgwork> no idea <Burgwork> looking at my FC4 machines <wasabi_> It might be fine to not deal with it, and move ldap.conf configuration completely into authtooll <wasabi_> And remove conffile from the files. <wasabi_> Get rid of the debconf questions on libnss-ldap, etc <Burgwork> yep <Burgwork> I think that works <Burgwork> whiprush: what does SLED 10 have? <Burgwork> but FC doesn't have our common-* stuff <Burgwork> at least 4 doesn't <Burgwork> also, fedora bundles pam_ldap.so in with nss_ldap <cliebow_> Burgwork:How do you plan to supply the functions smbldap-tools provides? <wasabi_> What functions are those? <cliebow_> those from smb.conf...adding machines passwrord changes <wasabi_> winbind. <wasabi_> In the case of AD. <cliebow_> i guess i need to read the spec..ive been working on perl stuff to replace the functions smbldap-passwd smbldap-useradd etc do <Burgwork> how does ccreds interact with nssdb? <wasabi_> It doesn't. <wasabi_> It's completely seperate. <Burgwork> right <wasabi_> You reading my novel? <Burgwork> 'cause db doesn't appear to cache auth stuff <Burgwork> no <wasabi_> It does not. <Burgwork> so I need both? <wasabi_> NSS does not involve auth. <cliebow_> why does ad come up? <wasabi_> Yes. <wasabi_> NSS involves only passwd/group entries. <cliebow_> in This situation <wasabi_> pam is hte "is your password correct?" pipeline. <Burgwork> right <wasabi_> Kerberos users have no entry in shadow. <wasabi_> No hashed password, etc. <Burgwork> auth sufficient pam_ldap.so <-- replace with pam_ccreds.so ? <wasabi_> pam_ldap shouldn't be used. <Burgwork> right <wasabi_> Oh, this is at your office? <Burgwork> yes <wasabi_> Ahh. You have no kerberos. <wasabi_> https://wiki.ubuntu.com/NetworkAuthentication/ScratchPad/Client#preview <wasabi_> Jump to my sample pam file. <wasabi_> And my long explanation of it's purpose. <Burgwork> and I discovered the pain when my ldap server decided to start using a dhcp addy <wasabi_> Hah. <Burgwork> still haven't figured why <Burgwork> given I have hacked /etc/network/interfaces to list it as static <Burgwork> wasabi_: your novel can assume more knowledge on the part of the read <Burgwork> ie: don't tell use what pam is, etc. <wasabi_> I don't want it to. <wasabi_> Also it's only one sentence. <Burgwork> I assume those assumptions are inherent throughout the text <wasabi_> You'd be suprised how many people don't actually understand PAM and NSS. <wasabi_> Again, I want this to be blogged about, and get people talking/interested. <lophyte> okay, spec time <Burgwork> that is way too long to a be blog post <wasabi_> It won't be IN a blog post. <Burgwork> still too long <wasabi_> Linked from, sure. <Burgwork> look, you need to catch peoples attention <Burgwork> novels don't do it <wasabi_> Actually, specifically, I need to sell it to mark. <wasabi_> So he'll pay for it. <Burgwork> that is not going to catch his eye either <Burgwork> remember, mark has add <Burgwork> ADD, raterh <wasabi_> Haha <wasabi_> I have ADD. It worked for me. <Burgwork> yours is probably treated <Burgwork> Marks is not <wasabi_> Mine isn't. =) <wasabi_> I don't get anything done if I do. =( <Burgwork> ok, if you must keep the fracking novel <Burgwork> at least point the point form stuff at the top <Burgwork> the todos, etc. <lophyte> would you guys mind a short discussion about directory services in general? <wasabi_> Sure. <Burgwork> then put everything else in a discussion section <wasabi_> I suspect you should read my novel though. ;) <lophyte> I sifted through it ;) <Burgwork> it looks interesting, in a text book way <Burgwork> I need facts and short bits, not learning <Burgwork> lophyte: shoot <lophyte> I just basically wanted to do a braindump of my own and see how it matches up with other people's visions <Burgwork> The NSCD daemon will run as root. <-- lets figure out a way around this, if possible <wasabi_> There is no way around it. <Burgwork> ok <wasabi_> Except to one run copy for every user. <Burgwork> question about your pam block <wasabi_> Including root. <wasabi_> Each with massively duplicated information. <wasabi_> And redundant LDAP queries. <Burgwork> if I don't run kerberos, can I just nuke that line? <wasabi_> Replace the line with pam_ldap <wasabi_> In some intelligent way. <lophyte> UDS (ubuntu directory services, not developer summit) should, imo, be a group of packages that can either work standalone or together.. <Burgwork> wasabi_: ok <lophyte> USUS for example.. can be run on its own, but works better with other packages, ie the GPO-like configuration system <lophyte> so you've got network auth, update services, config deployment... all things that can be run standalone or together as one big system <lophyte> unlike AD which is one big bloated package that you take all or none <Burgwork> yep <wasabi_> Not really, but okay. ;) <wasabi_> WSUS is not tied to AD. <wasabi_> The only real tie is that you're forced to use both their LDAP and their KDC. <lophyte> well, no.. but you can't have SSO services without GPO services <Burgwork> wsus not tied to AD is a mistake on MS's part <wasabi_> lophyte: Well, you don't have to USE GPO. <lophyte> no, but its still there <wasabi_> For instance, I use other software to deploy software. <wasabi_> wpkg.sf.net <lophyte> is there any work being done on a GPO-like system? * wasabi_ shrugs. <wasabi_> https://wiki.ubuntu.com/NetworkAuthentication/Client Moved my novel. <lophyte> another question.. is UDS going to be tied to specific packages, or is it going to be versatile and flexible? <lophyte> ie. you don't /have/ to use openldap and krb5-kdc <wasabi_> Depends what you mean by that. <Burgwork> wasabi_: can you forward that on to federico <wasabi_> addy? <Burgwork> lophyte: we are going to pick a best of breed ldap server <Burgwork> ask whiprush <Burgwork> ubuntu is about making decisions <lophyte> indeed <wasabi_> I suspuect UDS will be nothing but some automated utilities to install a server, configure it, and setup some schema. <wasabi_> No reason you can't setup your own server instead of using that. <wasabi_> That's sort of why we'll work with AD. <lophyte> but under the umbrella of 'UDS' includes our own centralized config deployment system <lophyte> and network auth <lophyte> and perhaps other packages <wasabi_> Sure... but again, the client component is just Ubuntu configured to talk LDAP/Kerberos. <wasabi_> NO reason you have to use our server component for that. <lophyte> right.. so you don't have to use the config system if you don't want to <Burgwork> no <wasabi_> I don't think there's anyway we could force you to do so. <Burgwork> but we are going to provide the complete stack, client and server <Burgwork> for the server side, we are going to choose technologies and go with them <lophyte> at a bare minimum, UDS is simply Ubuntu configured to talk LDAP/Kerberos on the client side, and LDAP/KDC on the server side <Burgwork> the client is fairly generic <Burgwork> the server is going to be much more specific <wasabi_> I wouldn't even consider UDS a product name. <lophyte> but you can install fancy extras on top of that.. ie. config system, usus, etc. <wasabi_> Really. <Burgwork> we are going to say OpenLDAP or FDS <lophyte> FDS? <Burgwork> fedora directory server <lophyte> why fedora? <Burgwork> because FDS is better than most out there <Burgwork> OpenLDAP vs FDS is debatable right now <Burgwork> and the world doesn't need another ds <lophyte> so what are we doing then? <Burgwork> need to evaluate both of them and decide <lophyte> if the world doesn't need another ds.. are we just making ubuntu work with existing DS systems? <wasabi_> Yes. <wasabi_> A DS is just a database though. <Burgwork> yes, but we also don't need to go out and fork an existing DS <wasabi_> Something has to install it, configure it, and set it up with proper information for clients to use it. <lophyte> ah, alright <wasabi_> I suspect we'd like to reduce that down to a single wizard on a server. <lophyte> so if we choose FDS, how would we migrate that into ubuntu? <Burgwork> there is a spec for that <lophyte> ah. <wasabi_> Somebody needs to package it. <lophyte> alright.. <lophyte> I'm just more or less catching up to what's going on :P <lophyte> and figuring out what our goals are <Fujitsu> Doesn't it depend on pretty much everything on the planet? <Burgwork> Fujitsu: less everyday <Fujitsu> Burgwork: Good! <Burgwork> they are splitting out the web frontend, which requires non-free java, in the next release <lophyte> is FDS free? <Burgwork> yes <Burgwork> all RH stuff is open source <Burgwork> everything <wasabi_> Did you give me federico's email? <Burgwork> whiprush has it <Burgwork> just a sec, let me see if have it <wasabi_> oh yeah i remember now <Burgwork> davidhull@example.net <wasabi_> This one: <wasabi_> http://primates.ximian.com/~federico/news.html <wasabi_> k <lophyte> Burgwork: you didn't get a tracking # for that package did you? <Burgwork> yep, but it is at home <lophyte> ah <lophyte> should check it <lophyte> my mom said she hasn't gotten anything by courier <Burgwork> it came by regular post <lophyte> how big is it? <lophyte> I wonder if the mailman stuffed it in the mailbox <Burgwork> envelope <lophyte> ah <lophyte> probably in the mailbox <lophyte> brb I'll check <ajmitch> right, I'm back <ajmitch> wasabi_: yes, I started packaging FDS, nothing new there <ajmitch> so of the todo list you have there, I've got stuff for the last 2. <lophyte> Burgwork: got it, thanks <Burgwork> perfect <lophyte> I'll hand them out tomorrow and pass some on to djp <lophyte> 1 down, 3 to go <Burgwork> wasabi_: just got bitten by https://launchpad.net/distros/ubuntu/+source/pam/+bug/67276 <lophyte> Burgwork: is there a list of goals for the directory team somewhere? <Burgwork> our specs <lophyte> ah, good point <Burgwork> what is the FC equiv of /var/log/auth.log ? * ajmitch rages at ugly php code <Fujitsu> ajmitch: That's what PHP is for! <Fujitsu> Being ugly, and raged at. <lophyte> Burgwork: alright, I'm gonna start merging our braindump with /UpdateServer <Burgwork> perfect <lophyte> also, re: -ca approval.. I'm gonna put us on the CC agenda, is there anything else we need? <Burgwork> we need the approval form <Burgwork> did you see that? <lophyte> I glanced at it briefly <Burgwork> please fill that out <Burgwork> I am fighting with FC4 <wasabi> Burgwork: Yeah. So... You see why we need C coders. ;) <Burgwork> ajmitch: got a stumper of a question of you <Burgwork> userdel claims that I am logged in <Burgwork> but I am, have no open files and have no running processes <Burgwork> what else should I check? <ajmitch> w <Burgwork> ? <ajmitch> w <ajmitch> type it <Burgwork> nope, doesn't list me <ajmitch> ok * ajmitch wonders what userdel is using then <Burgwork> no idea <Fujitsu> It's Fedora, does it need a reason to do crazy stuff? <Burgwork> no <Burgwork> I am currently on dapper <lophyte> oohhh burrrrn. <Burgwork> my boss wants a "homogenous" environment with our main office <Fujitsu> Ah, you said `I am fighting with FC4' :P <Burgwork> 1 Ubuntu machine, 2 FC <Fujitsu> I've never had userdel do that sort of thing to me. <Burgwork> wasabi_: how are you working around the ccreds brokenness? <wasabi> auth_err=reset <wasabi> Which is incorrect functionally, but works for now. <wasabi> It's returning auth_err. <ajmitch> what should it return? <Burgwork> right, o <Burgwork> ok * Burgwork grumbles further at FC4 <Burgwork> getent passwd corey --> uid 10000 <Burgwork> chown corey:corey --> uid of home dir? 0 <wasabi> ? <Burgwork> hmm, ok <Burgwork> that worked <wasabi> That's another interesting point... probably a place where i'd be willing to take a stand against everybody else. <wasabi> libnss-ldap should not make groups for users. <Burgwork> you mean, it shouldn't do the Ubuntu default? <wasabi> Nope. It shouldn't. <Burgwork> a corey group along with the corey user? <Burgwork> why not? <wasabi> Because it serves no real purpose, and muddles the issue tremendously... the LDAP server would have to have groups for each user. <wasabi> And make sure there were no conflicting gids, etc. <Burgwork> are we talking ldap groups or local groups? <wasabi> Neither really. <wasabi> I make my LDAP members primary group 65535, nogroup. <Burgwork> we shouldn't diverge from ubuntu <Burgwork> I don't see a benefit to diverging, so why do it? <wasabi> Because we have no way to not diverge. <wasabi> Unless you're going to mandate AD make a group for every user. <Burgwork> oh? <Burgwork> is that a bad thing? <Burgwork> we shouldn't shoehorn Ubuntu into Windows <wasabi> Hmm. I'd say so. <ajmitch> that's a lot of unnecessary groups <wasabi> No, certainly not, but we should carefully examine the reasons MS doesn't make a group for every user. <wasabi> ANd I assert that reason is because nobody suggested it, because they had no problem to solve. <wasabi> Because it solves no problem. =) <Burgwork> the groups one? <wasabi> Yes. <Burgwork> what about standalone machines? <wasabi> I believe the old-schoolr eason for doing it is because POSIX permissions are limiting. <wasabi> And you can only have one owner. <Burgwork> I find them quite elegant, actually <wasabi> So, in the case you want to share your folder with one other perosn, you setgroup it to him. <wasabi> Posix ACLs don't make that a problem anymore. <ajmitch> which is why windows never really needed a group per user <wasabi> Yup. THey were never working around a Posix permission set. <wasabi> They started with ACLs <wasabi> Anyways, so the options are thus: Either we leave it up to the admin to make a AD group for every user (not likely to happen) <wasabi> We mandate they do, no way to enforce it. <wasabi> We auto generate matching "fake groups" in libnss-ldap <wasabi> (horribly hacky, might make conflicting gids) <wasabi> Or we fix the problem that made us need a per-user group in the first place. <wasabi> Which is probably a better long term goal. <Burgwork> then write a spec for that <wasabi> local users can still have their own group, it hurts nothing. <Burgwork> and get it on the MTV * Fujitsu likes that last solution, there's a lot of clutter otherwise... <ajmitch> wasabi: so do you want to spec up ACLs enabled throughout ubuntu? <wasabi> Hmm. I don't think it's davidhull@example.net. <Fujitsu> ajmitch: There's already a spec on that... <wasabi> And I think somebody else will do that. ;) <wasabi> Yeah. <ajmitch> Fujitsu: sure, but when might that get done? <ajmitch> there's a spec for nearly everything <wasabi> NOt having a per user group doesn't break anything. <ajmitch> doesn't mean it's useful :) <wasabi> It just makes it slightly more difficult to give a single user access to one of your files. <Fujitsu> ajmitch: True, but it's not difficult to implement... <ajmitch> other linux distros have managed fine without group-per-user <ajmitch> I think it's an option in debian <wasabi> I don't mind per-user groups for local stuff. It hurts nothing. <wasabi> Let it continue. <wasabi> My first user I create in Ubuntu is "admin".. and that creates an "admin" group. <wasabi> And that group has sudo access. <ajmitch> then let's break from that for remote users <wasabi> So I add remote users to the local admin group, to give other users sudo access. <wasabi> adduser jhaltom@DOM admin <wasabi> And that's worked wonderfully. <wasabi> Since all users require a primary gid, I've been using 65534 I believe, for nogroup. <wasabi> Which has no permissions. <wasabi> Other groups are secondary. <lophyte> hey guys, where can I find a decent ldap+kerb howto? <wasabi> Don't think there is one. <ajmitch> yeah 65534 is default for nogroup it seems <lophyte> hah <lophyte> you're telling me ;) <wasabi> bayour had a good one. <ajmitch> decent? <wasabi> but it's been aging. <lophyte> okay, half-decent. <ajmitch> there are 1001 useful ones <ajmitch> none decent <lophyte> Burgwork: what's the news about UDS? <Burgwork> uds? <lophyte> MTV I mean <Burgwork> need to look into my finances <lophyte> I don't know if I'm comfortable with you sending me :P <ajmitch> we'll help relieve you of your finances, that's fine <lophyte> that's quite a bit of buck <Burgwork> ajmitch: heh * ajmitch looks into his bank account & cringes * lophyte does the same <Burgwork> mine is pretty bad too <ajmitch> hopefully I get paid again before I get to the US <Burgwork> just slightly less worse <ajmitch> currently about $250NZD to last me until next payday <ajmitch> yay for being poor :) <lophyte> I have about $250CAD in my account <lophyte> but that's /all/ i have <Burgwork> how are you paying rent? <ajmitch> unemployed? <lophyte> that's what my girlfriend is for, Burgwork ;) * ajmitch puts off rent... <wasabi> How are ya'll poor? You have more skills than 95% of the populace. <Burgwork> ok, here is a fun one <ajmitch> of course this $250 is the $250 until I hit the overdraft & credit card limit :) <ajmitch> wasabi: sure, find me a job that pays <wasabi> Odd. <Burgwork> wasabi_: I am poor 'cause I choose to work for a Linux company and didn't want to move <ajmitch> there just aren't many jobs in this field where I live <wasabi> I get 4 job postings a day coming across my in box. <wasabi> For ~100k <wasabi> Ya'll should move to the US! =) <ajmitch> lucky you - I wouldn't see that in a year :) <lophyte> lol <Burgwork> wasabi: lophyte is poor 'cause he doesn't know how much he is worth <wasabi> Ahh. <lophyte> hah, that's about right actually <ajmitch> and I'm poor because I waste my life writing php ;) <wasabi> I do C# and Windows. ;) <Burgwork> thing is, I wasn't willing to sell my soul and work on Windows anymore <lophyte> yeah, I don't think I am either <lophyte> I'd /really/ prefer to work in a linux environment <ajmitch> wasabi: you poor sod <wasabi> I don't have a moral problem with technology. I have a technological problem. <wasabi> WIndows pisses me off. <lophyte> I have both :P <ajmitch> I have a windows box that I work on, but all the code runs on the debian server <wasabi> Because it sucks in such obvious ways. <wasabi> And there's no way to improve it. <wasabi> ANd hence I believe money is to be made in superceeding that. <lophyte> Burgwork: did I ever tell you our plans for the Vista launch party in Toronto? <Burgwork> no <lophyte> bwahaha... <lophyte> djp and I (and a gang of people probably) are going to be putting up his 12-foot inflatable Tux outside the party <wasabi> The idea of a Vista release party confuses the shit out of me. <Burgwork> heh <Burgwork> hand out Ubuntu cds <wasabi> People who had nothing to do with the actual development of it praising it's launch? <wasabi> That sounds like religion to me. <lophyte> LOL <lophyte> good call <wasabi> If they'd worked to make a Linux distro, they can have a release party. <lophyte> but then again, what do you call Edgy release parties? <wasabi> Depends whose there. =) <lophyte> true enough <wasabi> Since so many people do actually contribute. <wasabi> And have a personal stake in it. <lophyte> good point <ajmitch> most people who go to those ubuntu release parties have no involvement in contributing to development <wasabi> Wonder if there's one around me. <lophyte> djp is supposedly having one, but he wouldn't tell me the date <lophyte> I bet its tonight, and nobody showed up because it was a last minute thing <ajmitch> I don't think we're planning any release party here in dunedin * ajmitch doesn't really feel like attending one in any case <lophyte> fyi, djp = a dude in toronto that owns the linuxcaffe <cliebow_> wasabi:call it community chuckle <lophyte> Burgwork: yay for recruiting <lophyte> I just saw Em3rald say he was from Edmonton in #ubuntu-offtopic, so I pointed him over to -ca ;) <lophyte> brb, rebooting <wasabi> ANyboyd know much about libdb? <wasabi> berkely db <wasabi> http://www.macdevcenter.com/pub/a/mac/2003/12/09/active_directory.html <--- Joining OS X to AD <wasabi> ajmitch: You might be interested in their interfaces. <ajmitch>
{'channel': 'ubuntu-directory', 'month': 10}