 This is, we're going to run until 11.25, this is the first time, at least I'm aware of that we've had a bof on this specific topic. This is also the first talk of today's enterprise trap. So, the basic premise of the bof that I was thinking about was that Demian has some really great technologies for dealing with a single system. You know, I can go with one command, get a variety of wiki sites, or blogging systems, or content management systems, a phone PBNs. You know, a database, my choice, all on one system. But the competition does a lot better at putting the systems together. Sometimes we don't really focus a lot on, you know, Windows conference. But I want to tell you a bit of a story about, it was, earlier this year was the first time I set up an active directory for Demian. And basically, I was shocked at how simple it was. Effectively, with one command and clicking a few buttons, I was able to get to a point where I had, you know, a consistent corporate authentication infrastructure, directory, DNS system, all synchronized. And with basically a couple of button clicks, any machine in my organization could join that. And conceptually I knew that, you know, that was the case, I've been working on related software for years. But I never actually gone through and looked at user experience. We don't have anything like that that can take a single Demian system and make it part of a group of Demian systems with that sort of level of use of use. And that sort of level of integration where basically we can have something kind of like package and transcend one system and actually get to a group of systems. But we do have a lot of the component technologies in Demian that are used as part of these infrastructures. You know, things like SAMLA, LDAP, Kerberos, Radius, you know, various printing and DNS infrastructure. We have all the components, but what we don't have is the integration. So I wanted to focus on three things. First of all, we do have some integration. There are technologies like Puppet, SCF Engine, you know, plenty of things, DevConf databases. Plenty of things I'm missing that are part of that integration puzzle. And in particular, organizations where we've actually gotten to a point where we have that level of integration. Basically, it tends to be custom within that organization, but it's taking advantage of all those sorts of tools to build it. The second thing is we have sub-projects. Things like, you know, Demian to Get You and various things that actually do seem to be within their target domain, putting together that level of organization. People have built embedded Demian systems that have incredibly high levels of integration. And finally, there's what to do better in the future. What are the areas where we can, where we, as packages, enterprise infrastructure software. Can get together and, you know, make the situation better. So I'd like to talk about, you know, tools. So the three topics I am aware of for this block are, you know, what is the integration story like in our competition? What is the integration, what are the tools and what are the success stories we have, how we can do, you know, similar things within our software. And finally, what should we be, what do we want to be doing next? What are our target priorities? How are we going to work on them? And so I propose to open this up as a discussion for, you know, these sorts of things. I've been a little bit myself, but mostly what I think this will be productive is an actual background. I don't know if we need to be passing the mics around yet. But if the video, if he does get things working, then we'll have fun and want to do that. So thoughts, anybody going to have any thoughts? When, where are the audience part? So this one. Are we on? Have we got it? Usually takes a little bit for the next one to catch up. So my name is Jeff Crompton, I'm from Melbourne. I might be jumping the gun a little bit and skipping some of the air. Oh, there we go. I might be jumping the gun at the skippings and all these steps. But I think one thing that might be important is automated kind of inventory type software, automated detection of systems and on-the-net and recording them and reporting details about them. And I believe maybe we might have some of that already with OCS inventory, which I'm not really favourite. What am I looking for? So public does have some of the new stuff built into it as well. We wrote something internally called out of date, which is package management kind of inventory, what package are installed everywhere, how recently were they updated, that kind of thing. Inventory seems to be one of those things that people do find commercial products to do and we keep seeing people try to do this to run commercial products. Usually there are things like these that you can do where you put a job listener on every single box. And I hate that kind of thing. So yeah, there seems to be a lot of demand for it. I don't know if you're familiar with CNDB, the ITL framework for configuration management. But there's a whole set of tools around that and servers and whatnot and none of this open source so far than now. I think important for us to keep in mind that if we do come up with a solution, it needs to be a solution that's not limited to dating boxes or not limited to boxes that are running up and it needs to be something that can talk to things that aren't running up and down like switches, like maybe in projectors. Because those devices are important to enterprises as well. Hi, I'm Michael Shultai as I work for Indiana University and we recently upgraded our ADS main controllers to Windows Server 2008 R2 and every time Microsoft changes their server software it seems to make it difficult to integrate the open source distributions into our AD structure. But one of the things that WN does do better than, for example, Red Hat Enterprise Linux is that it does include a more recent version of SAMA which tends to interoperate better. So even though we do have a university wide site license for Red Hat Enterprise Linux, a lot of our Linux using departments are using alternatives to Red Hat such as Debian or Ubuntu because they do tend to interoperate better due to the newer software even though Debian often is maligned for having Debian stable being too old. Debian stable actually has newer software than Red Hat Enterprise Linux so that is a plus for Debian. One thing I was thinking was that besides simply just having packages in the system in which you can create your own key environments such as, for instance, Webbin which already does some of the things that we might be talking about here today but also other distributions such as Ubuntu have spins which can be essentially turnkey installations for a particular task. So you could have a turnkey image that is set up with Carlos and Samba and such. So there's actually, first of all, there's some things you can do with Debian installer to get that. We're going to be having a talk later today talking about the current state of FAE, FAI which has been around far longer than Debian installer. I remember using it back in 2002, understanding it's evolved so much since then. And another project you might want to look at is MIT's Debian theme app which is, I think, which has one mode that I think is the DI-based that basically is looking at putting together that sort of turnkey installation. All of these solutions, as far as I'm aware, involve a fair amount of work within your organization for you trying to decide what your turnkey installation can include. It's my impression that that work is more than the similar work to do group policy for AD although getting group policy to deal with software installations that are not set up to work with group policy is my understanding is tricky. I do not have much personal experience with that. I think that that problem of having to require a lot of work to work for your institution is kind of our big problem. Debian is very strong on the customer vision front. And we certainly do a lot of that at Stanford where we have a bunch of configuration we apply at the top of Debian to make everything work the way we expect it to do. It's more of a small site where you don't have somebody with you. Stanford was going to do that regardless. You know, you get turnkey installations and they're not going to work for us. We're going to have to do that kind of degree of customization. And most of the sites I think have done a lot of work on Debian on infrastructure and similar work both where they're certain out of customization you're going to have to do no matter what. You can do it on Linux and you want all the tools available to build your own customization. I think that what you're in production you're kind of needing more of a somewhat different audience which is the idea of, you know, we collect the directory out of the box and install it and configure it when those systems point out of it and it just works. No, no, because I think you need to. I want the minimum bar to be lower. And I also want us to figure out, because basically our minimum bar for single systems is much lower, right? I mean you can, we do a lot of customization of things within single systems but the fact is I can, with very little effort, get started within a single system and pretty much any sort of, you know, any class of software. You know, I basically just install it and within a couple of minutes I probably have something that I can start playing with. And for integration, I think the minimum bar is a lot higher. And it's a lot higher on Linux than it is other places. I mean, Mac OS kind of tried to tackle the same problem in terms of how do you do a small worker solution fast with Keros and LDAP. I think that there mostly ended up being an example of things I wouldn't want to do. Actually, I have looked at that kind of stuff, I got really, really complicated. But I think that's kind of, I think that's the thesis missing. You know, if you're a huge say, you have public installer installing custom configuration everywhere, that there's a lot of tools to do that kind of thing. If you're on an individual box, there's a lot of tools to do that kind of thing. If you're doing something similar between, there's a big gap. Right. And I guess one question is, do we even want solve that problem, right? I mean, you know, are we willing to invent part of that? I think another thing is that if you're using stuff like Kerberos, I mean, if you've been using it, you're already familiar with how to set it up, how to do it, you know, people who are looking at these solutions don't necessarily need that much handle. There are a lot of newer, you know, technologies and newer things that are necessarily not quite as likely to see that, you know, maybe more emerging technologies in that direction instead. I have an example of, you mentioned about a case where a competitor has something that is pretty interesting. And it was many years ago I found out about it. I remember learning that Solaris had the ability that if you were running a Solaris site and you got some new hardware and you took it out of the box, you plugged in power, you plugged in ether, and you turned it on, and the machines were set up to automatically come up to HCP. You know, some of these technologies aren't used as much anymore, but they would join the NIS domain automatically set up the automowner and find all your file servers and a bunch of other stuff. So basically your deployment was, you know, just turn the machine on and it's part of your infrastructure. And that was something I always thought, man, you know, we need a way to do that in Debbie and so that all these services already have set up, everything just gets automatically discovered. Yeah, I guess two things. One, I have a feeling that the companies that are doing the integration pretty well have probably gone through a pretty long phase of trial and error and the development of management interfaces is some kind of a common note. It might be a starting point to try to come up with for the different major applications that want to be integrated what a, say, relational database schema for their configuration might be so that they could be put together and merged and, you know, turned into something that people can deal with without having to know the specifics of the syntax and configure every individual piece. That's one thing. The other thing is I mentioned CMDB. CMDB really isn't very real at this point. It's mostly a marketing concept and it's a very dumbed-down explanation of databases for administrators who really don't have a skill set to do it. Oh, I mean, CMDB is real. Since the Stanford University tracks all of our servers through CMDB and using CMDB as a federated CMDB data model, on the other hand, certainly having gone through that experience I would not have recommended it at this time to anybody else. But it's one of the problems is how they use data models. And I think it's one of the things that Active Directory uses is that you don't know that it's using Kerberos and you don't know that it's using LDAP. You're just using Active Directory to install it and you can dig into that stuff if you want to but it's kind of all hidden behind an interface which makes it a little easier to deal with. And, you know, our experience is that with LDAP you really want that. Some degree of that information hiding until you're ready to dig into it and change things because fighting is kind of unfortunate a little bit that all this stuff right now is built on LDAP. But I find LDAP really opaque in terms of trying to understand how it's data models put together. It's really kind of strange if you come from a world of relational databases and it doesn't, it's a little bit hard to wrap your mind around and that's, I think that's, it's like, is there a better way of representing that data because right now everyone does this kind of integration including Microsoft. When they want to plug all these pieces together what they put in the middle is an LDAP server and that's where all the data actually lives. And, you know, it may be that we can't do any better right now that there's definitely pluses and minuses to that technology and I know at Stanford we've put a lot of effort into putting SQL databases in front of LDAP and we don't put stuff in LDAP directly. We have middleware which does that for us which is the only writer of the LDAP and all the actual work happens in SQL databases. That's an interesting comment you just might have just thought outside that from my perspective it's been enough time with LDAP that now I don't find it too misspond and maybe that's just, you know, different strikes or different bugs. Anything we do that isn't LDAP is probably going to have to speak LDAP on some level at least for the, you know, year term. But that if you can at least get halfway to actually understanding it, it could be that hard. One thing that I just wrote for wanting to say for a while is that we have all the pieces for most of this stuff. We just need to glue them together. That's an excellent segue from two things. First of all, could I get people who are speaking to identify themselves and preferably if you're willing to disclose your organization that would be as well. Secondly, how many packages do we have in the room who are actually inners of software in this space? Like, you would view as sort of part of the pieces that Carl was talking about. I know I am, I know Russ Arer, but you're also here. About six, seven, maybe eight. Is there anything we as packages should be doing to actually create that clue? Are there, you know, would there be more value in having coordination between the packages? And, you know, do we want to try and work on that? Are there actual items we should pick up there or better communications or anything like that? CJ, firmly. I've been involved in Debian since 95. Linux, Force is my Debian consultancy of sorts. This is a tough one. The data is, and you're talking enterprise and so things like Puppet and CF Engine make sense, but all my clients are distinct entities. Some of them are bigger and maybe CF Engine or Puppet would make some sense for them, but a lot of them are small and coming up with a solution that integrates both for larger scale organizations and small business that might have two or three servers and, you know, 10, 15 workstations. I'm having difficulty imagining what the architecture should be that is flexible across those different size domains. And if you had the architecture, how would you interface with it? Is it going to be web-based or GTK? You know, the Debian Wiki has a great section on control panels, which is one way. Every one of them uses a different architecture, different data models, some LDAP, some Postgres, and everyone does it a different way. So, you know, there's a big policy question about the architecture, the data, and I don't even know where to begin to solve it. Does anyone have any? This is the beginning of a solution. I think it's just kind of a solution approach, which is, I forget whose law it was. It said that the software tends to grow organizational lines and reflect the nature of the organization that created it. So, you know, one thing I've seen in a bunch of places that I've worked where I've heard the line, yeah, we've got all the pieces, we just need the glue to go together is that if you actually have a project that hooks them together specifically, you know, as the catalyst to hook them together, then that can actually drive the integration. Right, but... I mean, if we did, Devin had decided as an organization that they would want to do something that involved LDAP in some specific way that involved blah, blah, blah, blah, blah, blah, blah, I don't know this community participation that would probably help. But I mean, right, I guess, but one of the questions to me is, are any of the people who are actually, you know, working on the pieces interested in working on the glue, willing to actually spend some time? And so far, I'm not really hearing a hack of what I've heard so far. And I mean, maybe this is just a problem we don't solve. Okay. On the IRC we have Andreas today asking whether anybody thought about using writing this Devin Enterprise at LDAP. This Devin Orman for discussing issues like this. Did not know that it existed? It did not exist at all. Does it exist? Apparently Devin Enterprise, Devin Induction Enterprise, writing this doesn't exist in LDAP. So we don't know. Actually, I don't know. It shows that we are not very organized given that the rest of our problems we don't have anything to listen to. I know I don't understand, right? But I mean, this, I mean, that is kind of one of the interesting things is that, gosh, I wonder who goes out there. He says it exists for years, but at least it's been not used. I will mention on the front of LDAP in terms of practical things we can do at Devin. Open LDAP is one of those chronically under maintained packages. And that's a place where it could definitely use some kind of a detention. There's some work that's going on right now in terms of getting some scening to be back in into Open LDAP, which basically means that your schema is now stored directly in the LDAP server instead of a bunch of files on the desk, which is the direction that upstream is taking things. And I know that the WDU folks are using the LDAP support in Devin pretty heavily, but almost all this stuff, like I mentioned earlier, almost all this stuff right now drives through LDAP, and the LDAP packages in Devin are not in great shape. And they're not in horrible shape because one person's been doing a lot of work on them, but they definitely could use more than one person working on them, particularly given that we have an annoying open SSL versus good in TLS issue with those packages, and upstream really, really hates good in TLS, so we end up having to do very much the burden in terms of SSL debugging. Drake Beaker at Google, but I wanted to comment on Devin. The primary way Devin decoys their configuration to all the different clients is by building configuration packages. I worked with one of the developers in Devin and had to come across and do an internship, and some of the things that we were doing internally are out on wiki.devin.org in the config packages directory, and they have a system-uploaded config packages that allows you to build your own custom configuration packages, hopefully. I will strongly encourage people to take a look at that. It's a very interesting concept. Basically, the idea is that in many ways some package probably doesn't provide the configuration knobs you need, and it's a way for you and your organization to help a package this configuration along the way that it's going to work well with upgrades. And I found that prior to the development of that work, I was not involved in the development of config package dev, but I have in multiple instances had to reinvent that work before it existed, so it's something, the design pattern, I think several Devin packages who are making this organizational changes have found them some day. There's a whole lot of logic in the curf5 config package, for example, to try to build a curf5.com for you. Basically, I think that package is a great example of a package with solid one-specific problem in a way that there should be a more general framework available to do what it's doing, and there just isn't right now. There actually was discussion, I know, last year's dev, when I was doing a Facebook curf5 config, someone pointed me in a framework that seemed, it didn't seem far enough long that I wanted to depend on it for a curf5 config, but I think there is an attempt at something like that. Unfortunately, I don't remember what it was called. Config model is one that I've seen floating around. Yes, that was it, that's it. There's a discussion that's happened from time to time on Denny Devel in the config model, which is a pearl framework for modeling configuration file languages, and the idea is that you should be able to use that to... You should be able to use that to... Basically describe the configuration file because everybody uses a different configuration file format and then use it to programmatically manipulate that configuration file. And ideally, you would want to be able to expose all that behavior to dev and package maintainers for us, so then you can do upgrades in a much saner fashion. I'm sure that I'm not the only person who has dev and packages who wear my maintainers for us during upgrades. Do these horrible, grubby, sad, odd things to try to fix configuration parameters that have changed? Jeff Crompton from Trinity College. Does config model have any similarity to August, which I've seen in public messaging and on many use? I believe as is often the case with these kinds of things, config model and August are essentially the same thing except that one of them was written by Ruby people and one of them was written by Pearl people. But I think they're very similar sorts of ideas. And I know the public being a Ruby community thing, mostly, has August support built into it and can manipulate configuration files that way. And that kind of seems to be the direction that public is trying to move in for solving that similar sort of problem. One of the, I mean, we love Puppet and we're going to talk about Puppet in the next boss, but I don't know if Puppet scales down all that horribly well. I know that we would not have put the effort that we put into rolling Puppet out if we had, you know, 50 machines. At 200, 300 it's great and above, but you're buying into a whole configuration management framework and that's one of the things that makes the configuration packages interesting because then you're just reusing Devian facilities and you don't, that scales down a little bit better. But there's various things in policy and in the way that Devian packages work that you run into some trouble when you start trying to manage configuration files in Devian packages that are not the same package as the software that you're configuring. I mean, that's the beauty of config package Dev is it comes up with a reasonable, it is not a policy compliant solution. It's not upload the results of the config package to the archive, but organizations are required to follow policy and what config package Dev is, it tries to solve the practical problems, but obviously it is possible from the underlying package to change in such a way that it becomes out of sync with your config package. We got about five minutes left. So I'd like to think, I guess, a couple more comments and then see if we can wrap this up and figure out. This is Matt Hecker for ResNetworks. We can also go a little longer if we want to cut into the public box as well. So we're always going to need the ability to manipulate these weird existing configuration files. One thing I kind of liked recently that Devian has done a lot of has been pushing to move to kind of the .d directory idea where you drop in config file snippets. And I really like that model a lot because it makes it easy for the package and it makes it easy for end users to drop things in there as well. And so, you know, to what extent should we really be kind of convinced upstream that they should use a model that allows for that as opposed to trying to work around and where config files. I don't know if anybody has any comments on that. Hey, we can fix copyrights. Yeah, I was... I think a lot of us are happy about that. Oh. One idea that's occurred to me many times but I've done absolutely nothing about it was that it would be really nice if you could do something like update on install, controlling the machine that you're on, waiting for you to end the second machine. So, you know, make it so that you have an enterprise-wide control system controlling one machine you're on from the start and then adding the second machine is critical rather than waiting until you have two hundred thousand so it can make a difference and then you want to decide yourself from the bottom out. So does anyone want to work on that at death camp next year? I mean, seriously, like, take a good idea like that. Get three or four people to say, actually, yes, I'm willing to come and work on that on a specific period of time and that's how you, like, actually do it. Well, I've been demonstrating my, my sort of competence of getting around to it for about five years. Some other people want to beat me up. Well, yeah, I come to death camp and then I'm sticking a gamut over the walls. Right now, I understand you're busy at death camp but you've done step one, which is how other people are ideal. Yeah, that's how I do it. Most things done these days. I want to make another comment about the configuration packages and the packages they are configuring the two worst things to configure are the LAP and Kerberos because of all the logic that's already in the existing packages. I have this table in that Wiki page discussing several different things you have to do to work around and veg other packages so they stop updating the configuration files since you've already taken over. The best solution is hierarchical by the .d directories where you just create a new file somewhere else and that takes over and that can produce your system. A lot of them can be taken over with d package deferred even though it's not policy compliant you can do it once and you can make it work for a lot of systems. Some of them you have to wedge something into dev comp in order to make the dev comp script not run and others are even harder to get rid of. One of them I had to use behind mountain in order to wedge the system to keep it from destroying the configuration files. So simple is better? Certainly I would be interested in cases if there are cases where for Kerberos where it is overriding changes you've made that's a bug I can't promise to be able to fix it but it's supposed to be very good about noticing what you've done and not screwing with it. Let's take it offline if there are bugs in Kerberos so just sort of some improving remarks we've had sort of discussions raged around a couple of things. I think if we're going to do this in the future we should coordinate on the enterprise list have some specific topics and specific proposals to discuss to make it more effective use of time. Thank you for your interest. I hope we all join the enterprise listening and creating a vibrant community.