Note: The timestamps here are NZST (UTC -10, New Zealand.) The meeting began on Jul 14 at 13:30 EDT, (UTC +5, Eastern US.) Ahh, the joys of internet communications. Props to ajmitch. Pre-meeting =========== [04:59] ducttape (~dif2@129.12.4.232) joined #dotgnu-auth. [04:59] heeeeeeeeeeeeeeeelo! [04:59] Action: ducttape bounces in to see whats happening [05:00] um, not alot it would appear [05:02] yeah, it's slower than molasses in November in here. [05:04] FrePort_ (~chatzilla@207-172-44-221.s221.tnt1.strt.va.dialup.rcn.com) left irc: Read error: 104 (Connection reset by peer) [05:17] FrePort_ (~chatzilla@207-172-45-181.s435.tnt1.strt.va.dialup.rcn.com) joined #dotgnu-auth. [05:26] WHEN DOES THE MEETING START? [05:26] Supposedly at 1330 US-EST. [05:26] ok [05:27] but I'm not seeing lot's of action on people arriving and so on. [05:27] so, we may just be in another cancellation via non-participation. [05:27] damn [05:29] my sentiments exactly. [05:33] acK [05:33] reset [05:35] fitzix (~fitzix@127.138.252.64.snet.net) joined #dotgnu-auth. [05:35] hello [05:36] lo! [05:36] hey there ducttape, how are things? [05:36] yay! we got one! [05:36] lol [05:36] hey there alias [05:36] I'm sadly a little bit behind [05:36] WOW! we have more than 3 live people! [05:36] been very busy over the past few weeks [05:36] Action: ducttape pronounces this meeting open [05:36] business stuff, new PC, mother moving to Arizona... ugh [05:36] doesnt it not start for another hour? [05:37] new PC!!! [05:37] 13:30 EST! [05:37] w0000 [05:37] four live people. [05:37] i'm just here representing vrs [05:37] and actually on time too! [05:37] hehe - I couldn't that would be 9 minutes ago [05:37] i dont really have anything constructive to say about auth [05:37] =\ [05:38] constructive is a relative term [05:38] FrePort_: yes, last time I chequed 4>3 [05:38] ok, is there an agenda to these things? [05:38] special announcement: [05:39] ok, anyone want to be chair person or shall I do it? [05:39] if you haven't noticed, we got our .org domain name back [05:39] how did we manage that? [05:39] well the DNS hasn't updated yet! [05:40] Ok, as noone else wants to shall I chair? [05:40] any objections? [05:40] go ahead :) Meeting (ducttape chairs) ======================== [05:40] ok, does everyone know who everyone is? [05:41] I'll take that as a yes [05:41] ok, [05:42] FrePort_: would you like to update us on how your progressing? [05:44] what? [05:46] well is anyone actually alive here? [05:48] Action: ducttape poiks people and prepares to stamp feet [05:48] i' mhere [05:48] but i'm just here to talk about vrs [05:48] that was the original plan cause they want to see what place auth has with vrs [05:48] i'm not actively working on the auth project [05:48] ok, if the various auth projects give us an update then you can explain auth [05:48] OK - let [05:48] and is someone logging this? [05:48] s start there [05:49] The _dog_ bot does the logging. [05:49] _dog_: woof [05:50] ok [05:50] right [05:50] OK - let's start with VRS' place in auth then [05:50] ducttape: sound good? Auth Integration Progress ------------------------ [05:50] FrePort_: can you tell us how FrePort_ is going? [05:50] ans specifically the integration with MACS [05:50] Sure... [05:50] do we have mds or kalahari? [05:51] nope, neither one it seems. [05:51] Action: FrePort_ pokes mds. [05:51] ok, then, FrePort_ and the integration [05:51] FrePort_: the floor is yours [05:51] Basically, mds and I have discussed integration in two different directions. [05:52] The first was to build FrePort as a set of adapters to MACS. The second was to incorporate the FrePort code into MACS proper, but have it swapped in and out via a modular core logic component. [05:53] mds favours the first approach. I favour the second. [05:53] how do you intend to decide which one to use? [05:54] Right now mds is iterating the MACS@Freport diagram and some of my verbiage to see which way he will fall. I've given him my arguments in the previous meeting's logs. [05:55] ok [05:55] Basically, the method I favour reduces bloat and makes MACS more flexible, but at the expense of more complex setup and coding. [05:56] his method let's him get MACS out the door to decrease his time on ROI. [05:57] It's sticky, because we both see the goal, but he wants to slam it from 20m and I want to rush the net. [05:57] when will you know which will be done? [05:57] Action: ducttape would recommend a cautaus but rapid approach [05:57] I believe mds will release his iteration of the diagram at next week's meeting, or whenever he comes conscious. [05:57] brb - phone [05:58] right [05:58] So, the progress right now is - my team is waiting on mds. [05:58] oh [05:58] is there anything you can do in the mean time? [05:59] We know that whichever way this is decided the Freport infrastructure is a dead goose. We'll have to rip out most of it to wedge into MACS. [05:59] are you happy with that happening? [06:00] And since the parts that we don't have to wedge into Macs (the encryption and decryption) are largely done; there's no point in developing parts we won't need. Why waste effort. [06:01] I'll be happy the day I can write a press release for slashdot. [06:01] Action: FrePort_ chuckles. [06:01] is the stuff which is staying tested? [06:02] In the meantime, my only concern is my developers becoming bored or discovering a social life, or more likely a new PS-II game. [06:02] lol [06:03] only in alpha, and only with previous releases of the dependent libraries. [06:03] when did we last here from mds [06:03] ? [06:03] two weeks ago. [06:03] Sunday before last. [06:04] ah [06:04] no emails or anything since? [06:04] what about cvs? [06:04] For Freport? [06:04] for MACS, has there been enything put in recently? [06:04] anything* [06:04] No public CVS access. We felt it important to have something that actually worked to baseline spec before releasing for porting and modification. [06:05] ah [06:05] For MACS? I have no idea. I =belkieve= there's a sourceforge CVS for it. [06:05] ok [06:06] so the FrePort_ summary for the week is - quake and alchohol? [06:06] and that's about it for Freport integration with MACS. We're in hurry up and wait mode" [06:06] okies [06:06] anyone got anything else to say on FrePort_ ? or MACS? [06:07] Action: FrePort_ chuckles. Friends don't let friends frag drunkenly. [06:07] :o) [06:08] Oh, one more thing! [06:08] go on [06:09] I will be going on an extended vacation towards the end of August and will be unavailable to do much of anything. After I return, I'll be tied up at a contract and so my time will be limitted until 30 November . [06:09] ok [06:09] going anywhere nice? [06:10] So, it's kind of imperative that we have some sort of integration "plan" by the end of August. [06:10] otherwise, we'll be sitting mostly dead until November. [06:10] dead != good [06:10] dead <= shite poor. [06:11] or is that shite(poor) [06:11] either gets the point across [06:11] Action: alias just got back.. [06:11] alias: get ready your on next [06:12] FrePort_: anything else? [06:12] Nope, that's it. Can alias do his VRS bit now? [06:12] yup VRS auth ------- [06:12] ok [06:12] i'm here [06:12] sure [06:12] Action: ducttape thanks FrePort_ on behalf of everyone [06:12] now? [06:12] Action: ducttape picks the floor up from FrePort_ and hands it to alias [06:12] go [06:13] thanks.. [06:13] so i didnt read anything that FrePort said before =\ [06:13] what i am about to tell you about vrs is only for the purpose of determining whether macs, Freport, or macs@Freport has any place in vrs [06:14] ok [06:14] VRS (Virtual Remote Server) is a clustering technology which enables many nodes to coordinate their activities to act as one centralized virtual server [06:15] The purpose of VRS is to enable "peers" to combine and do something that none of them could have done alone [06:15] kinda like the devastator from transformers...=) [06:16] lol [06:16] shades of Voltron... "Can i whack him with the sword puleeze? [06:16] a VRS's main function is to provide webservices or Executable Object Datasets (EODs) as we call em [06:16] ha [06:17] alias: can you give us some url's for details about webservices or EOD's we can put in the logs for newbies who read them? [06:17] excutables are written in what language, BTW? [06:17] another important thing i would like to note is that there is anonymity of a node's identity to the outside client of the VRS once a node joins a VRS [06:17] undefined? or purposefully undefined? [06:17] for example, if i write a webservice that provides information about MS's secret plans, no one can know that it was me once i join the VRS [06:18] no set in stone, but the rule of thumb is that EODs can also run in SEE [06:18] so its alittle like FreeNet in that sense? [06:18] so i *guess* you can write em in whatever language that is suppoesd to be supported [06:19] ducttape: yes, as in it is a p2p technology, no as in it does something much much more [06:19] what does it do which is more? [06:19] FreeNet or Gnutella or whatever isnt a server [06:19] it just lets people share files [06:19] well, its a set of protocols for sharing [06:19] explain the difference in serve and share [06:20] you can run executables in VRS [06:20] there is a notion of a client interacting with the VRS [06:20] you dont have to join the VRS to use its resources [06:20] ah ok [06:21] each node that is participating in a VRS runs a Local Data Server (LDS) [06:21] an LDS consists of: [06:21] 1. Cluster Manager [06:22] 2. Service Manager [06:22] 3. Repository Manager [06:22] 1. The CM is in charge of "keeping the VRS network together" for a lack of a better phrase [06:22] its in charge of keeping track of which nodes join and leave the VRS [06:23] is there any redundancy in the CM? PCM and BCM perhaps? like PDC and BDC? [06:23] it keeps track of what webservices each LDS has installed and running [06:23] and any other cluster management info we need (routing info, etcetc) [06:23] ducttape: i'll get to that [06:23] ok [06:23] sorry [06:24] no its ok, just shows that you're paying attention =) [06:24] back - sorry [06:24] go on :) [06:24] thanks =) [06:24] 2. The SM's sole responsibility is to take service requests and then load a EOD if it hasnt already been loaded and then serve it [06:24] pretty straight forward [06:25] serve? you mean, execute it and return the output to the user, or send the executable to the user? [06:25] now there was talk about not only making the EOD's compatible with SEE, but also we might want to use the SEE VM inside the SM. [06:25] ducttape: execute it and return the output to the user [06:25] ok [06:25] ducttape: its like a little webserver [06:26] like CGI [06:26] ducttape: or whatever server [06:26] well, you can write a CGI EOD [06:26] but you can also write a EOD that serves a mud [06:26] ok [06:26] 3. The Repository Manager - h0h0h0HAhAehHAHAEh [06:27] The RM 's sole responsibilty is to keep a Virtual File System [06:27] a Virtual Distributed File System [06:28] this VFS is an actual file system and all nodes in a VRS will share [06:28] physically, each LDS will hold a piece of the data [06:28] file system as in mount -t vrs type file system? [06:29] to start with, think of a RAID setup where we throw each block on different nodes [06:29] ducttape: if you wrote a EOD to do that yes [06:29] sorry peeps for theses questions [06:29] the VFS can only be accessed directly by the CM and the SM [06:29] I would think of it as more a FS provided by the network service - like NFS, but only not mounted - rather, accessed by the client, which could theoretically be mounted [06:29] if that makes sense [06:29] np [06:29] alias: so the FS, it still uses the local filesystem to store it, but is seen by the VRS as the equivelent of /dev/hda1? [06:30] ya [06:30] something like that [06:30] ok [06:30] Action: fitzix imagines remote /boot and / partitions being mounted by a think VRS client over a network [06:30] i think yes. not sure what you mean by "equivalent of /dev/hda1" [06:30] but ya [06:30] carry on [06:30] oh, that' sgoing to make me wet my bed tonight :) [06:30] fitzix: pls! [06:31] s/think/thin [06:31] Action: ducttape tries to bring the tone back up :o) [06:31] ducttape: lol - sorry :) [06:31] the VFS will have redundancy, it will be failsafe (tolerate LDS's leaving and coming dynamically) [06:31] alias: to what level will it tolerate it? [06:31] i dunno how much detail i should go into this [06:31] ducttape: best we can... best we can.. [06:31] as much as you feel necessary [06:32] for teh purposes of auth, all auth needs to know is that the data of an LDS, whether its a EOD they installed, or just files they wanted to keep on the VFS, could be on any number of other LDS. [06:33] so let me say a bit more about the VFS before i list some of the places where i see authentication/authorization being needed [06:33] okies [06:34] the VFS is a big monster. eventually, we want intelligent ways to: keep data redundant, place duplicate copies of blocks, keep all the copies *consistent*, sychronize them. acK!! [06:34] makes rsync look like a walk in the park with Winnie the Pooh. [06:34] one more note, each part of the VFS that a LDS stores on the local disk is encrypted and not coherent to anyone who may be looking at the disk natively from the OS. [06:34] Action: ducttape ponders everest as a possible short stroll once those problems are solved [06:35] exactly. [06:35] to be honest. these are goals that no one has yet to achieve, and i will be happy if we get 20% there [06:35] but we have good milestones so we can do it in stages [06:35] 5 20s equal a 100. [06:36] exactly [06:36] gotta plan for the future guys.. its all for the kids =) [06:36] it's stored on a raw partition? [06:36] so stepping back a second, me as Jo R user, makes a request from some client to the VRS [06:36] this goes to the CM yes? [06:36] fitzix: havent thought about that, just assumed it can be on the native fs [06:37] let me go through a possible scenario for a client request ok? [06:37] ok [06:37] alias: That's true... and in fact, setting up a raw partition would create extra config for the client [06:37] maybe that'll illustrate the important parts of what the VRS does without me describing everything in detail [06:37] a use case would be very helpful at this point; I agree. [06:37] Our scenario has ducttape making a request to a apache EOD. [06:38] eek :o) [06:38] ducttape connects to port 80 of a public LDS node in the VRS [06:39] what happens is the http request goes to the CM of the LDS ducttape connected to [06:39] say LDS A [06:39] http://a:80/ [06:39] the CM of LDS A says "Who has the apache EOD installed?" [06:40] ducttape: no, the VRS is a whole entity from the outside [06:40] ok [06:40] no it will be http://alias-vrs:80/ [06:40] CM does its magic and then routes the request to an LDS who has that EOD [06:41] that EOD then gets the files alias-nude.jpg and serves it back to the client [06:41] is that too general? [06:41] dt then throws up :o) [06:41] where do the SM and RM come in? [06:41] questions? [06:41] hahah [06:41] ducttape: internal services (?) [06:41] oh oops [06:41] that's right. [06:41] i skipped some steps, sorry [06:42] Action: ducttape wonders where they went :o) [06:42] the CM of LDS A routes the request to LDS B who has apache EOD installed. [06:42] CM of LDS B passes that request to SM of LDS B [06:42] SM of LDS B asks the RM of LDS B for alias-killing-dt.jpg [06:42] remind me what LDS is? [06:42] SM then passes that info back to the CM and then back to EOD [06:43] Local Data Server [06:43] ok [06:43] its what each node runs [06:43] LDS = {CM, RM, SM} [06:43] Action: ducttape kinda understands now [06:43] of course, many details are glossed over, partly because we dont know and partly because its not important for auth [06:43] so let me do another use case and then i'll talk about where i see security being needed [06:44] Lets say we have an LDS with a distributed computing EOD [06:44] so where does the auth bit come in? is it the CM cheques with the auth server that the user can a) run the executable b) access the data c) something I have missed? [06:44] ducttape: not there yet [06:44] i left out all auth stuff [06:45] oh [06:45] Action: ducttape sits down again and does a mouth.shut() [06:45] cause a) we dont have a security model yet and b) i want ideas from people without me contaminating them with my ideas for where auth should happen [06:45] oops [06:46] i have a factor-prime-number EOD [06:46] i run LDS, then try to join ducttape-vrs [06:46] security stuff happens... [06:46] then i am magically part of the ducttape-vrs [06:47] eek [06:47] now behind the scenes, CM's of all nodes are working their asses off to let every other LDS know tha ti just joined [06:47] i then install my factor-prime-number EOD [06:47] so the EOD gets written to the VFS [06:48] and i let everyone have access to it [06:48] now we hvaent decided how we're going to do this, but there is a notion of an EOD that you want to run only on your LDS [06:48] and also EODs that you want everyone to run. like this one [06:48] notion? [06:48] idea [06:49] whatever [06:49] type [06:49] Action: ducttape isn't that stupid [06:49] then what is your question? [06:49] are you just correcting my ackward word usage? [06:49] "there is a notion of an EOD" as in some description? format? [06:49] or is there another question? [06:50] there are two types of EODs [06:50] or settings [06:50] the reason i'm being vague is beause i dont knwo how we're going to distinguish them yet [06:50] quick point, how far along the line is vrs? is there any code? what about designs? [06:50] anyways, the point is that we want to install the factor-prime-number EOD on all LDSes [06:51] we're designing [06:51] ok [06:51] and we have a good chunk of the CM [06:51] in the form of Goldwater middleware from Chris [06:51] what is goldwater? [06:51] so my LDS installs that EOD on all other LDS's [06:51] gw is middleware [06:52] providing what function? [06:52] www.nfluid.co.uk [06:52] once each LDS installs my EOD, i can send them requests to do computations. [06:53] and a request would go from CM to other CMs and then to their SMs and back again. like before [06:53] the important thing to notice is that you can ask for services from inside the VRS. when you do, you have a greater control of what's happening. [06:53] any questions? [06:53] anyone still alive besides ducttape? [06:53] Action: ducttape is lost [06:53] =) [06:54] about the second use case? [06:54] Action: ducttape poiks fitzix and FrePort_ "wake up hes not THAT borring" [06:54] wtf goldwater is would be a good start? [06:54] He's not boring at all :) [06:54] FrePort_: are you there? [06:54] Action: ducttape forgot the smily on that last action [06:54] Action: ducttape poiks fitzix and FrePort_ "wake up hes not THAT borring" :o) [06:54] ducttape: ? [06:55] lol [06:55] It's a good design [06:55] ok, lets step up the abstraction tree [06:55] well if FrePort_ decides to show up he can read the log [06:55] my comment: it's very similar to MojoNation in some ways - are you guys aware of that software package? [06:55] me as Jo R user boots up her Pc and gets a doze of somekind [06:55] I hit start, then what do I do? [06:55] i'll go over the parts where we need auth of some sort and then people can get back at me about it [06:55] I've been reading, in between other efforts. :-) [06:56] fitzix: yes [06:56] fitzix: if my knowledge is correct, then MojoNation doesnt really share a consistent disk image across all participating nodes [06:56] alias: no - it doesn't. It keeps portions in redundant nodes (to my understanding) [06:56] and say if i have the only file on the network and i leave it, then the file is gone form teh network [06:57] a [06:57] ya [06:57] ok its getting really hot in my room, i'm going to hurry this up [06:57] well, my understanding was that it was persistent because mojonation would split the file up and copy it to available members to mirror - when one left, the chunks were mirrored again [06:57] ----------------------------------\ [06:58] Security [06:58] --------------------------- [06:58] There is basically two broad levels of security we need in VRs [06:58] one is client-VRS security and the other is LDS-LDS security [06:59] client-VRS security can be implemented with any mechanism normally available to a webserver, or whatever the EOD is. [06:59] ack Hold on. [07:00] sorry [07:00] back [07:00] i think what i said about client-VRS security is true.. [07:00] not sure [07:00] i dont think we want to restrict clients to trying to access the VRS, like a normal server [07:01] normal (web) server ? [07:01] ya scratch that [07:01] that made no sense [07:01] everyone - hang out here for a bit - FrePort has to leave for a couple [07:01] client-vrs we can definitely use macs [07:02] or i mean write a macs plugin for client-vrs auth [07:02] but the interesting part is LDS-LDS [07:02] ok.. i'll wait until FrePort_ gets back [07:03] alias: while we wait, I have some vrs non auth questions -> $0-vrs [07:03] msg me [07:05] I'm back. [07:06] ok [07:07] hey [07:07] Are we still on the VRS auth topic? [07:07] ya, so to recap [07:08] we can definitely do a macs plugin for client-vrs auth [07:08] but the area i want to explore is whether macs has a place in lds-lds auth [07:08] hmmmm... it'd be nice if we had something visual to go with this... [07:09] what do you mean? [07:09] like boxes with lds written in it all connected to each other? [07:09] alias, do you think you could diagram a client->VRS interaction with authentication/authorization included? [07:10] and I'd prefer circles and septagons, but squares are OK. [07:10] well i dont think we need it for client->VRS [07:10] it'll act like a regular standalone server [07:10] :-] [07:10] so we can write a macs plugin for it [07:10] but the important thing is lds-lds like i said [07:10] well here is our timeline [07:11] yesterday we all basically did a phase 1 requirements list [07:11] go on. [07:11] Action: ducttape makes a quick suggestion about http://www.jibble.org/netdraw.php [07:11] over the next two weeks we're going to try to hammer out a design [07:11] after a design with protocols and stuff exists, then we're all going to sit down to design a security model [07:12] so do you want to wait until then? [07:12] ack - gotta run guys :( [07:12] ie we'll send you the design docs and then we can all talk about security together? [07:13] fitzix: thanks for coming [07:13] thanks alias. [07:13] You can mail me the docs to the usual address and we can think on them. [07:13] alias: no problem - thank you. :) VRS has a very good design. I'm proud to have it as part of DotGNU. [07:14] ttyl all - sorry for the sudden exit :( [07:14] later [07:14] FrePort_: the final thing wont come until 2 weeks later [07:14] i'M OUT OF HERE TOO i'M AFRAID. [07:14] fitzix: thanks! [07:14] :) [07:14] FrePort_: do you want updates? [07:14] bye FrePort_ [07:14]