=== Starting logfile irclogs/ubuntu-directory.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #ubuntu-directory === Topic for #ubuntu-directory: Welcome to #ubuntu-directory, where we talk about LDAP and directory services in Ubuntu | Plotting world domination | https://launchpad.net/people/ubuntu-directory | https://features.launchpad.net/people/ubuntu-directory/+specs | https://launchpad.net/people/ubuntu-directory/+packagebugs === Topic (#ubuntu-directory): set by Burgundavia at Sat Oct 21 03:29:53 2006 === Fujitsu welcomes ubuntulog. [06:53] (Fujitsu/#ubuntu-directory) Thanks fabbione :) [06:54] (fabbione/#ubuntu-directory) no problem [06:54] (ajmitch/#ubuntu-directory) thanks [06:55] ok it works [06:55] logs will start to appear on the web within the next hour or so [06:55] have fun === fabbione [i=fabbione@gordian.fabbione.net] has left #ubuntu-directory ["Ex-Chat"] [06:55] so watch what you say from now on :P === ukh [n=ukh@130.226.34.17] has joined #ubuntu-directory === cliebow [n=cliebow@smoothwallkludge.ellsworth-hs.ellsworth.k12.me.us] has joined #ubuntu-directory [03:54] morning all [04:15] morning [04:16] how's it going? [04:23] https://wiki.ubuntu.com/NetworkAuthentication/ScratchPad/Client <-- proofread [04:23] me->work [04:30] I'll take a look in a bit..rebooting, brb === lophyte [n=dsulliva@ubuntu/member/lophyte] has joined #ubuntu-directory [04:59] ergh.. can't get Xen set up [05:02] sux [05:48] wasabi_: very wordy [05:48] might want to cut it down a little [05:48] Burgwork: know where I can find some info on getting Xen on edgy running? [05:48] I can't find anything useful [05:48] lophyte: no idea [05:48] dang.. [05:53] wasabi_: here is what I would do. Move all that wordy-ness into the wordy sections, like use cases [05:53] the implementatin and scope should be point form with very small paragraphs [05:53] whiprush: if you don't post to ubuntu-devel about ubuntu-directory by 5pm PDT, I am doing it [05:53] Burgwork: I'm writing something up that will be linked from a blog/u-d post [05:54] Something for people to read. [05:54] much too wordy, even for that [05:54] you also need a better intro [05:58] Heh. [05:59] This also in a way helps me. [05:59] Get the ideas fully formed. [05:59] tbh, I get bored into the first para [05:59] and I care about this stuff [06:00] first tell about the high level, then get into the details [06:00] with small paragraphs, one with each idea [06:03] I have a feeling Mark will like htis anyways, being a business guy. [06:04] I am not talking about mark [06:04] I am talking about the rest of the world [06:04] I don't see a plan to action there [06:04] which packages are going to change, etc. [06:05] TO BE CONTINUED [06:05] it is already too long [06:08] btw, is Mark still expanding Canonical? Scope keeps increasing, is staff keeping up? [06:09] yes, he is [06:09] see ubuntu.com/employment [06:11] Burgwork: is the strategy to replace old maintainers so they can work on new things? [06:11] all the moz, kernel, x people? [06:11] no, it is more, now we are to the point we need both maintainers and developers [06:14] just kinda curious, I think my days fiddeling with computers are mostly over [06:14] I've got a teleworking op I'm hoping will supplement a meager existence while I head back to school [06:15] hurray for soulless PHP work :( [06:16] 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. [06:17] And the reasoning for that is pretty wide. [06:17] wasabi_: no, currently you have giant paragraphs, without many headings [06:17] There will be a short list of actionables when I get to the bottom. [06:17] wasabi: maybe those should be links? [06:17] it is still too long, I am telling you [06:20] I tell you this as a marketing person [06:20] I will try and dig into it and lunch [06:29] Burgwork: ok that sounds good. Sorry I dropped the ball on that [06:29] whiprush: I will beat you in MTV [06:29] Burgwork: I have an ubuntu talk tonite at a new lug so I am putting together my slides and totally forgot [06:29] ah [06:29] Burgwork: I will bask your awesomeness [06:30] Burgwork: do you have the draft we were working on? [06:31] no, email it to me [06:32] corey@u.c? [06:33] corey.burger [06:38] ok googlel is wacked [06:38] why do I need a new account? [06:38] it already knows who I am [06:39] dunno [06:40] I think that was what sergey was going on about [06:53] Burgwork: about usus.. when does a client decide to push their dpkg -l ? [06:53] on boot, on a cronjob.. what? [06:53] if changed would be best [06:54] if what's changed? [06:54] if the pakcage information has changed [06:55] on the server? [06:56] no, the client [06:56] why would it change? [06:56] an update? [06:57] I don't follow.. [06:57] when the machines update, their information is going to change [06:57] as their might be new versions [06:58] how can they update if they haven't sent their package list to usus yet? [06:58] on initial install and upon any change [06:58] Sort of a chicken n egg problem. [06:58] so you'd have to manually go around to all your computers and force a change before it pushes its package list? [06:59] They should push their info right before they update. [06:59] They are unrelated actions, actually. [06:59] can we keep a uid on the server with a last seen timestamp? [06:59] and send only the names of newly installed packages? [06:59] This cron job should just push/update [06:59] Nothing else. [06:59] cronjob? [06:59] Or whatever we use. [06:59] that makes more sense to me.. [06:59] Existing update-manager server or whaetver mvo has. [07:00] also, does it seem inevitable that you will end up tracking packages that are no longer in use? [07:01] I'm gonna take a look at nwu and see what's already working [07:01] because person x used to have it but dropped their laptop down the storm drain? [07:01] At some point machines expire. [07:01] WSUS does that too... it says the last time a machine reported. [07:01] And you can just click on it and hit remove. [07:01] And then it's no longer considered. [07:03] The UI puts little marks next to computers which haven't repoted for 180 days or something [07:03] so perhaps it should report to the usus server in a cronjob, or on boot [07:03] in a cronjob preferably [07:03] Mine as well just do it everytime the normal update runs. [07:04] The reporting is sort of disconnected from the updating. There's no reason for it to happen more often though. [07:04] you mean the update-notifier? [07:04] Yeah. [07:04] ah, right [07:04] The update-notifier can just a report inserted right before it runs update. [07:06] nwu looks like its completely different than what we've been discussing.. [07:09] its like a way to remotely administer a client's repo configuration, and force updates [07:09] which is needed [07:09] you can force package installation and such [07:10] how much code is there? [07:10] Yeah, I think we need that too, but I think that should consider LDAP [07:10] I think that's outside of the scope of USUS [07:10] And other things, like gconf mandatories. [07:10] Since those all fall under "configuration" [07:10] that's more like a configuration management thing, ie. GPOs [07:10] Yeah. [07:10] if the code exists, no reason to throw it away [07:10] I agree, but again, it seems outside the scope of USUS.. the code could be integrated into a GPO-like system though [07:11] yep [07:11] when it sends its list of packages, it also needs to send in a list of all components it is subscribing too, correct? [07:11] you /could/ use nwu in conjunction with usus at the moment, until we have a GPO-like system [07:12] http://cetico.org/nwu-doc/user-manual.html#d0e327 [07:12] but it uses SSL and stuff.. which breaks the kerb/ldap theory [07:13] I'll see if I can use any of it [07:14] paste warning [07:14] 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. [07:15] Seems sort of heavy and complicated. [07:15] yeah [07:15] And very very hard coded to only deal with apt. [07:16] I would much rather prefer a generic GPOish thing, where you can push many things: mandatory gconf strings, apt lines, fstab entries, etc. [07:16] That hooked to LDAP would be nice. [07:16] *nods* [07:16] agreed [07:16] I do also think that in large organizations these things are very disconnected. [07:16] I'd love to work on a GPOish thing.. but USUS is on my mind at the moment [07:16] You have people deploying corporate policy, and then some sub departments deploying per-department policy. [07:17] And you have people disconnected from that which validate security updates. [07:18] security team vs management team [07:29] hrm, question... [07:29] what if update groups were determined by OUs rather than group membership? [07:32] They sort of are. [07:32] Well, actually they're determined by whatever configuration system populates apt. [07:32] Which, presumably, would be like GPO, and use OUs [07:33] ah, right.. [07:34] like, you'd create a sources.list GPO that uses the testing repo and assign that to the testing OU [07:34] right? [07:34] Yup [07:34] or a GPO that uses the servers repo and assign that to the servers OU.. [07:34] k, got it [07:48] This brings me to my thoughts on a GPO replacement... which probalby overlaps or eliminated the current NWU. [07:49] I'm thinking keep it super simple. You define a set of name/value properties, much like debconf keys. [07:49] In fact, exactly like them. [07:49] And you come up with some LDAP assignment to determine the full set of keys to apply to a system. [07:49] I've never seen debconf keys.. [07:49] will have to look that up [07:49] Then you just write them to the system someplace, and leave it up to some client programs to configure themselves based on them. [07:50] Which is basically like GPO does. [07:50] you write them to an NFS share [07:50] 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. [07:50] at least, that's how GPO works [07:50] Yeah. The name of the template is delivered by LDAP. [07:50] yeah [07:50] The template is just a flat file of name/value pairs. [07:50] *nods* [07:50] + one local template. [07:51] I might do it the same, except eliminate NFS, and use a dedicated HTTP server to retrieve the templates. [07:51] Since NFS is obviously sucky for a lot of reasons. [07:51] \\server1\SYSVOL\path\to\gpo [07:51] store that path in LDAP [07:51] Basically you just ask the server for the full set of templates that apply to you, and it delivers them. [07:52] That's basically what GPO does, except it doesn't store the path. [07:52] it's very simple... all the development work will be on the client-side, developing a client that interprets the templates and applies them [07:52] sabayon is the beginnings of gpo [07:52] It stores the GUID, teh clients retrieve it on it's own. [07:52] Yeah I know nothing about sabayon. [07:52] ah [07:52] stores a zip on a server somewhere [07:52] zip of what? [07:52] pulled down the client and unpacked upon login [07:52] zip of gconf keys and other config into [07:52] info, rather [07:53] per user or for a system? [07:53] both [07:53] per user [07:53] well, GPO does both [07:53] So sabayon doesn't address the system. [07:53] I am describing what sabayon does now [07:53] ahh [07:53] not what it could do [07:53] this is part of what federico is working on at Novell [07:53] Yeah. [07:53] For the user stuff. For the system, I might seriously consider pushing debconf keys. [07:54] k, I gotta go do some shopping... [07:54] I mean... it totally works. [07:54] I'm gonna send you guys what I've got here [07:54] feel free to hack it up [07:54] and rip it apart [07:54] Server delivers a set of debconf keys, every key that changes, package gets reconfigured, it applies the values. [07:54] wasabi_: whats your email? [07:54] actually [07:54] nm [07:54] wasabi@larvalstage.net [07:54] I'll post it up on a web server [07:55] debconf has issues in that it is Ubuntu/Debian specific [07:56] Heh. A packages entire configuration is Ubuntu/Debian specific. [07:56] Either fix that, or accept it. ;) [07:56] I thought the point of ubuntu DS was to create an Ubuntu/Debian specific system :P [07:57] http://www.dave-sullivan.com/usus/-workflow.odg [07:57] erm [07:57] 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. [07:57] http://www.dave-sullivan.com/usus/usus-workflow.odg [07:57] http://www.dave-sullivan.com/usus/usus-workflow-footnotes.txt [07:58] that's still a WIP [07:59] looks good [08:01] 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 [08:05] also.. [08:05] I moved our braindump: [08:05] http://wiki.ubuntu.com/UbuntuSUS [08:05] since it now seems unrelated to NWU [08:06] ok, that means we now have three specs [08:06] because there is that spec whiprush wrote [08:06] which one? [08:06] update-server [08:06] https://features.launchpad.net/distros/ubuntu/+spec/ubuntu-update-server [08:06] this one? [08:06] that one has been supersded [08:07] right [08:07] UUS spec stores package info in LDAP.. and we argued against that yesterday [08:08] ok, we need to sort out the interaction between nwu and sus [08:08] so that people are not confused [08:08] I think we actually just need to make something work, and then people will use it, and the other pages will get deleted. ;) [08:08] storing credentials and configuration template information in LDAP is what we discussed as the best option I think [08:08] lol, agreed [08:08] yep [08:09] I can have this operational by some time next week if I worked my ass off on it.. [08:09] 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. [08:09] should we supercede the nwu spec with the sus one? [08:09] I think the current USUS idea we have is actually simple. [08:09] And doable, quickly. [08:09] And immediatly useful. [08:09] I agree with wasabi [08:09] so do I [08:09] Sure, we can't deploy sources.list files out of hte box. That's fine. [08:10] whiprush: you around? [08:10] that's done through another mechanism [08:10] We can solve that in the same step we figure out how to deploy everything else. [08:10] lets change uus and nwu to be superceded by sus [08:10] yup [08:10] Burgwork: in and out [08:10] ok [08:10] whiprush: change your superceding stuff to sus from nwu [08:10] on it [08:10] should I create a sus spec? [08:11] I think so. You should clearly right up what we've talked about, and let the NWU people in on the conversation. [08:11] alright [08:11] whiprush: better, change the dirver of uss to -directory [08:11] We need to convince them why we think our approach is better. [08:11] And decide where to move from there. [08:11] okey [08:11] lophyte: merge your page to the wiki page of the current https://wiki.ubuntu.com/UpdateServer [08:12] lophyte: and then make nwu superceded by uus [08:12] there, that is simpler [08:12] no three spec [08:12] alright [08:12] so merge usus with uus and call it uus? [08:12] yep [08:12] alrighty. [08:12] ok [08:12] what am I doing now? [08:12] You need to be updated on what we've discussed. [08:12] =) [08:13] And have your say, etc. [08:13] yeah [08:13] how far back do I go in the log? [08:14] yesterday around this time, lol [08:14] ok. [08:14] let me do this spec thing [08:14] ubuntu-update-server should be the most up-to-date spec [08:14] ok, so I am changing uus to be merged with usus? [08:14] yup [08:14] I superceded it yesterday [08:14] so do I un supercede it? [08:15] I think that's what Burgwork wanted [08:15] merge our discussion into UUS and make it the latest spec [08:15] right Burgwork? [08:16] it's ok, I have no idea how to even find my spec now [08:16] god launchpad makes me cry sometimes [08:16] https://features.launchpad.net/distros/ubuntu/+spec/ubuntu-update-server [08:16] though it should be a spec under ubuntu-directory me thinks [08:16] whiprush: What we've discussed goes basically like this: [08:16] Simple mod_python based web application, which manages a directory of user-created repositories. [08:17] The user can create a repository, named whatever he wants, but usually something like "dapper" [08:17] And hook it up to one or more upstream repositories. [08:17] In this case, he would create a repository named "dapper" and hook it up to "dapper", "dapper-updates" and "dapper-security" === whiprush nods [08:17] 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. [08:17] Under $reposname/proposed [08:18] Machines can then be set up to pull from [08:18] deb http://localserver/uus/repos dapper/proposed main universe [08:18] right [08:18] That's the latest copy of upstream. [08:18] ok, spec is given to ubuntu-directory now [08:18] Machines will post their entire dpkg database (package names and versions) to the URLS periodically. [08:18] and unsuperceded [08:19] wasabi_: and this can be enforced right? [08:19] I think it should only be posted once [08:19] In what way? [08:19] lophyte: Has to be posted everytime a new package is installed. [08:19] wasabi_: well, can a client machine break? [08:19] Of course. [08:19] This is code we're talking about. [08:19] heh [08:19] well [08:19] 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. [08:19] So you'll see an approval interface for "dapper" [08:19] I meant, so a user with sudo on a client can still remove the stuff right? [08:20] listing all packages which have later upstream versions. [08:20] or will it continue to push to the client? [08:20] whiprush: Yup. He can remove it. [08:20] ok [08:20] When you approve a package it moves it into the Packages files within the main repository (non /proposed) [08:20] Clients retrieve everything from there. [08:21] Testing boxes can test dapper/proposed, all other boxes can use dapper [08:21] Approval simply makes it available to the clients in production. [08:21] Each user repository will have a seperate pool, where .deb files are kept. [08:21] They can be linked from /proposed to non proposed. [08:22] I don't think you need to send your entire package listing every time.. just once [08:22] and diff it every other time [08:22] I think .deb files should be downloaded on demand somehow. [08:22] lophyte: Sure, you could keep the last sent copy [08:22] And just send the diff. [08:22] I think I might implement that last though [08:22] When we determine it really matters. [08:22] the server would also have a local copy of each client's package list [08:22] so when it sends the diff, it compares the diff with the package list [08:22] whiprush: And that's all it does. It doesn't handle machine groups or anything on it's own. [08:23] it /can/ be set up to use groups, though [08:23] Machine groups are handled by creating multiple repositories: dapper-desktops, dapper-servers, etc. [08:23] simply by creating multiple repos [08:23] yeah [08:23] wasabi_: ok I was just trying to understand the scope [08:23] The scope is simply to approve updates to existing packages. [08:23] It is not to manage the installation or configuration of client machines. [08:23] this way, it doesn't introduce any new technology and is built on things that already exist and work [08:23] Since we believe that would overlap with other projects seeking to do the same. [08:24] there should be a separate project to handle configuration settings deployment [08:24] As that seperate project will want to take into account other stuff, deploying text files, fstab entries, local user stuff, etc [08:25] right [08:25] Which sort of includes sources.list [08:25] This ends up mirroring WSUS basically. [08:25] Where WSUS simply approves, GPO deployes pointers to WSUS. [08:26] I'm gonna go eat and do some shopping.. [08:26] I'll be back later to finish up the spec [08:27] i wonder why nwu is approved [08:30] anywho.. bbl. [08:30] Because mvo worked on it [08:47] hey people [08:47] mvo... and nictuku [08:47] nictuku wrote the actual code [08:47] mvo just speced it [08:48] ahh [08:48] lophyte: still having xen issues? [08:49] ajmitch: yup [08:50] followed the XenOnEdgy wiki page? [08:51] 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 [08:51] ok, uus added to mtv [08:51] on i386 or amd64? [08:51] there's a xen-restricted-modules package [08:51] i386 [08:52] Burgwork: i wish I was going to mtv [08:52] you should be fine then [08:52] I'll try installing xen-restricted-modules [08:52] lophyte: you can. It is not that much from to to sfo [08:52] Burgwork: yeah but I still can't afford it :P [08:53] sorry, my funds are tapped [08:53] unemployed = no money [08:54] ajmitch: so xen-restricted-modules will provide the nvidia driver? [08:55] lophyte: you realize we both have the same diploma from CDI? [08:55] LOL [08:55] you went to CDI too? [08:55] yep [08:55] sadly [08:55] that's funny [08:55] yeah, it was horrible [08:55] grad with honours? [08:55] yeah.. though I haven't officially graduated yet [08:55] ah [08:55] they haven't contacted me about when the graduation is supposed to be.. [08:55] there are two ways to get out cdi [08:56] well, I'm done my classes [08:56] with honours or not at all [08:56] hehe [08:56] I finished with like a 97% average [08:56] its almost impossible not to graduate with honours [08:56]