 Okay, great. Hi, this is Sam Hartman again, and I have the pleasure now to introduce Michael Banke, who's going to be talking about FAI and, Goza. Goza, okay. I'm sorry, I just realized I didn't know how to pronounce that. So this morning at the ball, one of the things that we talked about was whether there was any tools that were sort of at the, between the kind of stuff Russ was talking about last hour and sort of the one machine. And it sounds like Michael's going to be talking about what fits really nicely into that space, at least on the side of installations and how that works for repeatable installations for small organizations. And so I think this will be very interesting. Thanks, Sam. So I'm Michael Banke. I have contact with FAI and Goza through my work. I'm done, I'm working professionally for Cudotif and we're helping the City of Munich to get the most out of FAI and Goza. So they are doing some pretty large scale thing as you might have heard. They're trying to migrate all their 15,000 desktops to Linux. So they're doing quite some heavily modified stuff. So basically they are based on Edge but they don't call it Edge even more. They have some other release name scheme, not Toy Story. And there's a lot of packages that they forked and a lot of packages they added. And that's one thing. And the other thing is that also they're using FAI and Goza in a pretty pushy way. Oh, it's pushing what Goza can do in some sense. So they're using multiple servers. These servers are talking to each other and I'm not gonna talk about that tonight or today. But I think it would be interesting because there had to be quite a lot of modifications to be done to get this setup going or it's still ongoing I guess to migrate. So we're still helping them. And it would be nice to at least get some parts out of it for regular stuff. So I'm not gonna talk about server-server integration that's maybe for another year because it's just so far away from anything you can easily do on Debian right now. It really takes a lot of integration work. But yeah. So first of all, who knows FAI? Who has used it already? Not that many people actually. I thought everything would go up. And who knows Goza? Okay, so quite a few less. Yeah, FAI is probably much more well known. As a disclaimer, I'm not that much of an FAI expert as compared to other people in the room. We're mostly working on the Goza side but I would really like to present what you can do with Goza and FAI and how you can install and manage systems with it. Okay, so FAI, as Russ just said, it's one of Debian's success stories. It's really great. It's on the other hand, quite size admin-centric I would say. So you need to, it's very command line based. You program in Perl and well, see if Engine or Shell in order to get things going as you want. And while the tagline is planned, your installation and FAI installs your plan or client installs your plan. Still don't know what the real pronunciation is there. And it's implemented in Perl. No. No, sorry, what is it then? Shell and Perl. Shell and Perl, okay. Others. But okay. So this is the part which is probably pretty well known. I mean, I'm not going to talk too much about FAI just a bit about how it's working. Basically, you get a client-specific pixie config. So the clients will boot over DHCP and then get a config which gets generated or which gets generated by the FAI change boot program. And depending on that config, it either says reinstall or local boot. So then the client knows whether it should go into installation mode or just boot from the local hard drive to get a regular boot up going. And then clients boot over NFS. So there is the central server which serves the root file system over NFS. And from there on, the init system is basically just FAI itself. So there's no regular init. And FAI then runs a couple of scripts which determine which classes there are. So basically the classes then in the FAI concept, classes say what particular parts of FAI should get done are applicable to that particular client. So you can customize for a range of clients or for one particular client, you can customize different ways of installation. Yeah, so these classes get determined and their configuration space gets a determined. And I will talk about that a bit in a bit. Then the installation gets executed in the sense that the target file systems get partitioned and created and the packages get installed and scripts and so on get executed. And in the end, this client-specific pixie config will get set to local boot so the next time it will not get reinstalled again but will boot from local disk. And in general it's possible to do post-install management via the soft update mechanism which I believe is not that heavily used but you can use it to figure out which packages should be on and which package should get removed or whether packages should well get updated if they are. Or you can add probably new packages which you think should be on that host. So, five classes in more detail. They define how specifically a client get installed. And, well, it's, you can, so as I said it says admin centering, it's Perlin shell so you can do whatever you want in some constraints. But generally I believe you take hardware-specific or feature-specific or client-purpose-specific classes so say you have a class I386 which you can always query and do various things which should be done on I386 compared to maybe AMD64 like installing the right kernel and that kind of stuff. Or say Grubb or Lilo if you will say, okay, this computer doesn't boot with Lilo or this computer doesn't boot with Grubb so you can set a specific class for that kind of computer. Or things like GNOME or server, you can make up packages lists of different packages which should get installed on one machine so the purpose of the machine gets executed. Basically, how it is done is there is a couple of scripts or you can of course add new ones which get run on during boot but is fine in it. And they determine the classes. So basically what they output on standard out is what the classes will get added to the classes. So in this case, U-name will be put into upper case and then as you see, this would be the I386 or AMD64 class in the first line. And then the next one would be also well, the package there and then other things. So that's like system dependent. And other classes would be host dependent, for example here, there's a host name demo host. So basically this is taken from the five example classes just so you can, if you want to look it up, it's the five dash doc package and the user share doc, five doc, example, simple. So there you can have a look how five classes are looking like and this is from that example if you want to look it up. And then here you can say that if the class is I386 or AMD64, then also install grub, for example. So you can do that. And in this case, the host demo host would have the package based classes, five base DHCPC for DHCP client and demo and any other client. Of course you can add your own here would have only five base and DHCPC. And then you have a list of classes which apply to that particular client. And from these classes, there's a couple of different things that are getting run. Various types of classes you can say. And they're all below the so called config space. In the class directory itself are the scripts which I was just talking about which determine the classes. But there are also, that can also be variable files which are the class name dot var and they just contain variables. For example, in the simple classes they also contain a hash root password for the installation client and other things. And they can be used later on by scripts and hooks. The first thing which gets looked at is the disconfiguration class which figures out or tells you how to partition a host. So the host gets automatically partitioned based on what kinds of partitions you want. You can put any kind of partition in and do basically it looks, well, it's more like it looks like a table and you say the amount point and how much size it should be. So for the boot file system you would have a couple of hundred max and for the home file system on a desktop you would say, okay, I take the rest of the disk and stuff like that. And you can do preceding of variables which everybody probably knows about. For depth conf variables you can put them in the depth conf class in a general format which is depth conf set selections and they're in the package config will have a list of packages to install and a method of it. You can also say in a class, well, if also that other class is there then also install these in that packages. And, well, files are files you can, which you, that's a bit difficult to explain. They, you have a directory hierarchy there and these files then get copied over by fcopy which you have to do in one of the scripts. I will talk in a minute. So you basically say for the file boot grab manual list you would have files slash grab slash s slash boot slash grab slash manual list slash and then uppercase gruv if, as it pertains to the grab class. And they can also have post and pre-inst scripts which run directly before or after the file gets copied and they are pre-panned, so they're just post-poned pre-panned by pre-inst post-inst. And finally you have the scripts which do all the configuration and they are, they have a priority, like a two-digit priority for each class so they will get run in succession so you can say, well, which script should be run first and later and so on. And there, again, you can use the variables or the installed files to do various packaging, various setup stuff. And the hooks, it's a bit different. They're not running in that particular order but you can hook into some parts of FAI and do things you believe should be done at that point. For example, when there's an error you can do some more cleaning up. You want to do on your site or what to do on a soft update action and what to do when Microsoft gets installed. Okay, so that's a very short overview of FAI. I mean, if there's more questions about that we can go to that back later but now I want to go a bit into Goza because that's probably a part which is not so well known. It's a configuration management system built by a German company called Gunikos and it's LDOP backed. So basically everything is stored in LDOP and as a front end, you have a web-based front end which brings me back to this size admin thing I was talking before. So as you can see, it's very much different to what regular size admins would go to. I mean, it's something which for example for the city of Munich is very important because the team is only like a dozen people but there is tons of admins who have to finally install all these 15,000 machines that they don't want to do that all by themselves. They're just providing the infrastructure and all the admins are not necessarily trained in Perl or Python or CF Engine and Shell and FAI. So for them it's quite convenient that people are able to do that kind of things in the web front end. So it's not necessary that you're a senior unit size admin to do that. It has some terminal server desktop integration called GOTO which I believe stands for Gunikos terminal operations or something where for each user you can for example define in LDAP shares which should get mounted or desktop icons which should show up and it's actually pretty KDE centric still I believe. I mean, I'm not talking about that here just saying that it's possible and they're using it for the city of Munich to do various customizations of the KDE desktop. So that's quite nice. And it has a pretty powerful plugin infrastructure. So there's loads of plugins. As you can see, you can do a lot of management of various things. And the most important probably is maybe the mail stuff for your favorite mail or groupware servers. So all the mail gets routed properly and things like that and you can do that via LDAP lookups. So basically what you need to do to hook into that is that your system is able or that's at least the perfect way is able to hook up or to look up things in LDAP and GOSA will do that for you and then you have the integration going and you can easily manage that. And what I'm talking about, what I'm going to talk about is how it can be used for system management. That means installing and keeping up to date workstations, servers, well also terminal clients. So the difference to FAIS, it's implemented in PHP and it can be sometimes flake. I mean, there's some very stable parts of it but especially the system integration part is not very, very stable yet. So just as a data point, so far everything we were looking at for the city of Munich, even when we thought it had something to do with FAI, it was actually always a GOSA bug. There was never any problem with FAI for that project at least. It was always a problem with GOSA. Just so you get a look or you get a hold of how it looks like. I can quickly show you that's the main GOSA screen with just a couple of plugins. So as you install more plugins, more would get visible and probably you have to log in again. No, so right now, this is just a test setup. So one thing I'm also not going to talk about is migration of data in LDAP. So that can be a bit tricky if you have large installation and you have lots of stuff already, lots of users already in LDAP and then maybe some custom objects and things like that. Then it could be quite tricky to get it probably going with GOSA but it certainly can be done and then it has been done and there is also some migration assistance and things like that. But yeah, basically, well the administrator is able to do quite a bit but users are able to change all their stuff, change their password and as in, well for example, this seems to be not working but you can add users to groups or change your home directory and their account, change how their password should be done and stuff like that. I mean, things that you could do easily as a UNIX admin but which might be not so obvious to people who are new to this. It has departments so you can set up different, always wants me to cancel. So you can set up different departments, actually the city of UNIX is using hundreds of those. I'm not going to talk much about that and you can group things, group people into groups so you can have like a group of admins or a group of users or a group from that department and give them different things like different default shares they should have on the lock-in and things like that. Okay, what the thing is I want to show is the systems, lock-in. And here you see three servers so I put some two shadow servers which is FTPDE, Debian Arc as a package repository and Debian Pool, NTP Arc as a time server and I talk as my local server that I've reproduced here. And so you can see the server, the IP address, MAC address and well, this is not applicable because I just installed the server automatically, not via this mechanism but if you want you can do that as well. For example, the city of UNIX, they install all their GOSA repository servers via FI as well. Okay, well, just going back for a second. So what can you do with GOSA and FI? You can edit classes in LDAP or in the web front-end basically so that's of course on the other hand also, I mean it's quite nice for non-tech savvy people but on the other hand it's not the greatest thing of course if you're used to doing that in VI or Emacs so I can show you how that is done. This is the software deployment module and you can define various releases, I defined a linear release and basically what I did here is recreate the simple demo class of FI. So you have, as I said, you have this grub class which has as a template this boot grub menu list file you can upload the file or you can edit the file. Oops, sorry. So this would be the file. It's also start in LDAP, base 64 encoded. So everything's really in LDAP and with that file you have, these are the three scripts which are done by the default simple class which set up grub appropriately. This one for example does the F copy of the menu list entry and this is the post-inscript which are recreated here which sets in the right boot device, boot partition into the menu list so everything gets done appropriately. So as you can see you can edit this over the web front end. I'm perfectly clear that it's not the thing that some people at that point might do but I just want you to convey that it's certainly a good thing for people who are not that experienced who can do this kind of things easily. This would be the main package list, network terrible, there we are. So these are the main packages for this and what you can also do is edit the depconf well not in this one apparently. So there is some limited functionality for configuring packages for preceding. It's not working very well all the time but for a reasonable subset it works rather well so you see the templates in here, they get extracted out of the packages and people can then decide what should be the configuration options for that and they get implemented. So go back to the talk. Then yeah as I said you can edit the classes in LAP only, I mean that's maybe something which should be thought of in the future, I don't know. And you can assign a repository and an FAI profile so the difference between FAI as I said before and NGOSA is that through to this shell script evaluation in the beginning of FAI you have a very dynamic way of doing things and also for example in the package list you can tell what other packages should get installed if another class is there. So you don't have this kind of dynamic things, this is a pretty static way. So the whole configuration space of FAI for one client is pretty determined. What you can do though is you can put several profiles. So profile is a list of classes to apply. So it's a set of classes basically and then you can say okay I have one package list for this and then I have a slightly modified package list for that and depending on the client I want to install I'm choosing this profile or that profile which would include the right package list or the right scripts or that kind of things. So the easiest way to install a client would be to add a profile to it. And what you can also do is you can set an action, I mean you can set a wake up for things which can be woken up over ethernet or a reinstall a soft update mechanism that would get triggered by the next reboot. What you can also do is monitor the installation progress which is pretty nice. So if you have like 50 different clients which are installing you can see them all on one page what the progress is, whether they had a problem. That's actually I think one of the main advantages I'm not sure about any other like five. I mean of course you can always look at the file lock files on the clients or on the server but that's a nice way to have a good overview. And you can also view the fine installation locks of that. They get sent to the server and they get stored on the server and you can look at them in a somewhat convenient way. The other thing is you can mass install a list of clients so that's also the feature that City of Munich is using a lot so you can have a CSV list of MAC addresses and what time they should be installed and you can import that and then all the clients will get installed at that time. Or you can just click through a list of all the systems and say okay every system which has this name or well click through and they get all installed at the same time. So how does it work in practice? It works in so far that goes hooks into fire at various places. So the first thing is that the TFTP boot service gets supervised by a program called FTS. And this one, so if the client, the booting client requests the configuration file for itself by requesting pixieboot.config slash its MAC address, then there's a fuse file system which will figure out the read on that non-existing or virtual iNode and FTS will then query the other database via a file module what the system statuses of that particular client and if it's set to local boot it will generate a pixieconfig for local boot. If it's set to install then it will generate an appropriate pixieconfig for install and then it will well write it out dynamically on the fuse file system for that client which can read it and will boot accordingly. So that's the first thing and well the insulation and the root file system over NFS is basically the same thing except that also goes hooks into or also goes hooks into make phi NFS root script which generates NFS root and does a couple of local and changes there as well. And then the main difference is the configuration source. So the variable phi config source is set to goza which means that the script user libtfi getconfig via goza will get executed and this one runs the so-called goza system integration client on the client which talks over the network over socket with another goza system integration server on the server and does a shake handshake at the beginning and then will tell about the status of the installation and other things later on when the client has been booted you can for example, trigger a reboot on it and it will do that on the client. And then it runs LDAP to fire which is the main script which does the configuration space determination. So it queries LDAP for the client classes and configuration spaces so which profiles do pertain to that client and it figures out which classes are in that profile and then it downloads all the necessary script hooks and variables and partition tables and stores them on the disk as is for a regular static phi config space but that's a dynamically generated one. It merges in a couple of default classes which do some goza specific things as well and there are a couple of hooks which override some parts of goza, some parts of phi for example, for the progress thing and stuff like that. And then installation gets executed and during that go to phi progress will send that progress over the server via goza.si and after that, phi stays again set to local boot. And just, well so the main problem is it's not as easy as app.get install goza plug in phi. So it's not quite, I mean the status so far is that goza itself just this like last month or yeah late last month was finally updated to the two six version which is the newest version so that's finally in unstable and probably soon in squeeze but goza.si has not been uploaded yet. It needs a couple of more modules and maybe some more integration. And the other problem of course is for setting up phi itself is pretty difficult so if you just set it up, it doesn't really do much itself. You need integration with LDAP a lot. You need to do quite some other things and especially for the FAI plug in and the goto plug in which is dependent on that. You need to install quite a couple of pearl modules which have not yet been uploaded as well. So what is there and what I've been working on over the last couple of weeks is Mark Pavlichuk has been creating some install scripts. So basically what he's doing is these are scripts you can run and then when app get install or build from source appropriate packages you need and they will also modify the, well they modify for example the PHP config because some parameters have to be in set. So it's something that it's not very nice at the moment it needs much more integration but with those scripts you can at least try it out on a host and then see whether that setup might be might suit you. And for example it adds all the schemers to slapd.conf it does other stuff. And as I said it compiles unavailable module packages from subversion. So I fixed it up quite a bit to get it working because I think he never managed to get a real client installation working with it. There were quite some loose ends. So for example he didn't, he hadn't set the five config source variable to goza or just didn't do anything. It just did the regular five install basically. Stuff like that. So I just wanna demo now for a second if I manage to set up or add a new client. So you can create a new workstation. It's called a demo host. There is, I set up a virtual box image for this with this MAC address. You have to set an NTP server. You have to set kernel and LDAP server. And here you can assign as I said you can assign a repository and the five classes. So this is my local repository which has been just a regular Lennie repository which I have cloned on this external USB hard drive for, well, performance reasons. Lennie is the only release I have and these are the classes that are defined and I'll take this demo host profile. You also have to set use DCC and then there is the new demo host. It's still blocked. So now I'm not sure whether it will actually work. We will see. Okay, so it's booting from local disk which means I didn't figure out it correctly from LDAP. So there's a problem there. Just so you can see how it looks like I'll try to quickly force it into installation mode. If that works. I hope that helps. Now it's running the VM Linux install kernel. It's loading the inner RAM disk and it will immediately boot from NFS route. Takes a bit. Okay, so can, there we go. Well, so just to finish up this while the demonstration is going. Um, as I said, it's very much a work in progress still. I mean, it's worked. You can, well, for, except for that slide problem I was just fixing. Oh, yeah, that's my problem with the port map, usually. It's getting better. Yeah, it's not, I'm also doing this in a change route so I didn't want to use my whole notebook for this. So this why it's a bit weird set up, which I hope. There we go. It has booted the NFS route and it's now within the real one. And now you can see the progress of the installation of PHY has created all the scripts and the templates over LDAP and it's now performing the PHY installation. That was a bit fast maybe, but now it does the partitioning. It's making the fast systems and here you can see the progress. It's inspecting the hard drives. Yeah, so and on the go-to side, there is a system employment status and it should show in principle, well, that's the demonstration effect. Usually it should show the status of the installation but did it fail? Well, I'm sorry about that. Not sure what's wrong. I had it working for quite. Check the error line. Yeah, maybe I didn't properly, there we go. I think you did the demos never work more. Sorry? You've hit the law of demos never work. Well, yeah, I forgot. I didn't buy them on the Devin repository into it so you couldn't find the packages. That was the problem. Now it's again between local disk. Okay, well, I think we're running out of time anyway so it was there 10 minutes, yeah. I mean, that's virtual box. There is some, any questions? Yep, yep. Do you want to repeat or we'll take a problem from Trinity College? Yep. My first question is in goes are there tools for mass account creation? If you get a CSV list or a database lookup of a bunch of names and maybe your company ID, can you do a mass account creation? Why, you can certainly mass add LDAP entries. Because you display doing an account creation of a single person. Yeah. Is there a way to do that more efficiently for 300 people? As I said, you can just create the LDAP objects. So you're another then. Just LDAP however you want to do it. Right, an LDAP file, if it's the right Shema and everything. I mean, in generally it's certainly possible for, certainly possible to just migrate your existing LDAP. That's the main reason to do it. It just might be a bit hairy at some, I don't know, you have to fix up some stuff. Depends on what Shema you were using and stuff. But yeah, that's possible. And of course you can just, I mean, everything you can do in the web, you can just do via LDAP manipulation over, as you just saw, for example. I have no idea why it currently doesn't work. So I'm just putting the file state back to where it's, to install as soon as possible anyway. So yeah, further questions. Okay, I'll take another question. Can FII install non-debian things? That's a question to FAI people, right? So, do you want to answer it? Yes. So the answer was yes. The answer. Can it install things like Zen server? Zen? Zen server? Yes. And the answer was yes again. That's a Debian. What is Zen server? Is that a special distribution or from Zen source or? Or is it just a Debian-based Zen? Zen server is sold by Citrix. Okay, right, so it's, yeah. Any other questions? Yeah, can you please stand up? What's on? For LDAP schema, when you create a user, is there a standard schema or what? Yeah, it's, I'm not too sure on that question actually. There is certainly a standard schema. I don't think it's particularly weird in a sense, but I'm not, I mean, I don't really know what is standard in that sense, so I can't really, so I just invite you to look at the schema that they're using. For a male user, for example, what are attributes for alias, for example? Let's go for the default. So that's the attributes that the system administration has. CN, object class, description, and well, the other things I haven't really added, so. No specific, goza object class? There's an object class, yeah. So that's maybe, sorry. I guess I won't get it working at this point, as I said, there's some way to go. I mean, I will talk with Mark and try to get it going, and well, my personal goal is to get it working for, for example, say you got a research group at university, there is a postdoc who is quite good at UNIX, but every two years, another person will do the administration and make it easier for those people to set it up and maybe have some other people help them who are not that tech savvy. So I'm not sure whether it will be eventually possible to do that. I mean, it's clear that it's a viable thing in so far as the city of Munich is using it for a couple of thousand workstations already, and it just needs quite a lot more integration now. Okay, so if there is no more further questions. Is there? Okay, well, thank you.