 Virtual deployment tool. My name is Thomas Lange, working at the university for a very long time, started with Sunwares, and there there was something called JumpStart, which is an automatic installation. And I used this for several years, but it was not that good and I did some extension to it. And in 1999, we had to install a cluster. And since I'm very lazy, I wanted to have also something automatic. And during that time, there was nothing in Debian. I think even preceding was not available at that time. So we started with the fully automatic installation project. Yeah, and I went to several conferences and I always talk about PHY. What is PHY? A fully automatic installation. That means you want to make a computer where are only zeros on the hard disk from the, yeah, a virgin computer, make it ready to go so the user can just log in and work. And it's all about software packages. So you have to create a file system and then put the software packages onto the disk and configure them. But it's not only about only the initial installation, it's also how to maintain. So how to do upgrades or add additional packages to it. So it's the configuration. That means mostly, yeah, we also do the preceding stuff. But then there's much more doing customizations. So to customize the OS and the application for your environment. And we want to have this from a central server. So we control all clients and can reboot them or, yeah. So it does everything as this admin and I guess most of your assets admins and maybe are interested in using PHY before the user can log in a new computer. We do not use a master or golden image. We just have a script that controls the automatic run of the installation. We have a class system in it and I will go in detail later. That's very nice because you can model, have several models, yeah, we'll see it later. It was always very important to me to not have a black box or that I say you have to run PHY in this way. You are always very flexible. You can do the installation via network. You can do this from USB stick. So in every parts of PHY we are very flexible and you can extend it with we call it hooks or plugins. PHY also documents your installation. So there's no need for you that you write down how did you install the machine? Which password do you set? In the end you have several log files and this is the documentation how this machine was installed. So you can also reproduce this even five months later. But PHY can't plan your installation. But if you plan your installation then PHY will install your plan. That's something similar the scuba divers are saying you should plan your dive and then dive your plan and not change things in between. So here's a technical overview. On the left side we have the installed server. We have three main parts, the NFS route, which is used during the installation on the install client. So during the installation the install client is just run as a diskless client. And if it's run as a diskless client we have fully access to the local hard disk and can partition it, create file system and so on. So this is the NFS route. Then we have a config space and the config space is just a subdirectory with certain files and there all the configuration information are put into it for all install clients. So you have one config space for all your clients and sure we need access to a mirror, to a package mirror. So how does it work? Normally start with the plan, very important. Then the normal DHCP TFTP diskless client then we define the PHY classes and some shell variables. Then we create the petitions and the file systems and then we install the software package. And for example even the Linux kernel it's not something special for PHY it's just a Debian package that we install and configure. And after that after we installed all the packages with the preceding information we can run customization scripts. And if you have already a CF engine or puppet or a chef environment you can also run your scripts in this part. I mostly use shell scripts for the customization part and then you can reboot the machine and it's ready to go. So the class concept of PHY. You can group several hosts with assigning a class to them and usual host belongs to many classes. There are examples like desktop, GNOME and the names of the classes should say what is done there. And if I say my clients belong to the PHY class desktop for me this is an XFCA desktop environment. We have an order in this list of classes and so we can override things. And when I say in my desktop class XFCA is the default desktop you see there's also the class GNOME and this class GNOME has some information that overwrites the package list so the GNOME desktop will be installed. So we have a little bit of inheritance in the classes and all parts of PHY are using this class concept. So here are some sub directories. The class directory contains some files which are executed to define classes and the .var files are used for defining variables. And there you already see that the names of the files are the class names. So you can just put a new file into this sub directory and if an install client belongs to this class it will automatically fetch this file and use this for its configuration. The same in this config for the partitioning part and the package config we will see this later is just a list of package names. So defining classes is very easy. We just write scripts. Here we have a shell script and everything that this script is writing to standard hours is automatically defined as a class. So the first line, the deep package print architecture just will print the hardware architecture to standard out and then this is the name of a class and later can be used for distinguishing which package I like to install or which script I like to execute. Here we have something with LSPA, PI, grep, echo, something like automatic hardware detection. If we detect a graphics card from Matrux this client will belong to the Matrux class and maybe I have already created an xorg file which especially for this graphic cards is used and that it's file will also automatically copy it to the right direction. Variables are just shell variables, so nothing special. What's very nice is the disk partitioning part and if anyone ever wrote a pre-seed file for disk partitioning, everyone says yeah, this is really horrible. What we invented was something like a FSTAP file. So you say in this file use the first disk that you find, create some primary and logical partitions. The size are not fixed, they may be from one to two gigabyte and the file script that is doing the partitioning will look how big is the disk and then optimize all the sizes. And we can also give very fine options when creating the file systems or when mounting. Yeah, that's I think a really nice thing because it's very easy to, if you see one or two examples you can just write them down. Since I think three months we also support ButterFs and we also support software rate and LVM things. So if you want to write this in a pre-seed file this gets like one or 200 lines of code or of pre-seed configuration and this I think it's very easy to understand. Yeah, create some physical partitions then the software rate and put LVM stuff on top of the software rate. So I'm really proud that this is very easy for the user and not oh we are using XML queries things and yeah, so let's see how you create a correct XML file. No, it has to be very easy for the user and the parser is our work and that's much more work than if we would use XML syntax. So there's another sub directory called package config and for example we have a file beovolve. So if a client belongs to the class beovolve fi will read this file and then installs all the packages and here we have also a line called beovolve master. This means those two packages will only be installed if the client belongs to the class beovolve otherwise fi wouldn't read this file and if it's also belongs to the class beovolve master. So we have a little bit of logic and logic which classes are installed. Then with the scripts there are also classes used and very often you use this fcopy command. This is a fi special command which knows of the fi classes and then looks into this directory and selects the class with the highest priority and copies the file to the destination. The configure scripts are most work for you to do. What would you want to customize which files? And there we have a very nice command called append if no such line. CF engine has this command but I rewrote it because it was much nicer to use this nice editing tool without using the big CF engine stuff. The installations are also very fast. So often if people are installing classes say, oh NFS may be a problem, no, it's no problem. You can really trust me, yeah. But I think it's very nice if you have a complete installation in seven minutes and you do not have to attend the installation, you can get and have a coffee. So why is Perl, why is Fi the universal tool? It started with installing Debian but in the meantime we can also install Ubuntu Centro as scientifically known as OpenZoozer. So what's the different in Fi when installing a different distribution? The boot process and the dispositioning does not need any modification. It's yeah, it does not care about the distribution. We can even use a Debian NFS route when installing a Centro S or Ubuntu system. The only thing that needs to be changed is how to access the package repository. The package name may vary. For example, we are using Apache and maybe Centro S calls the package Apache 2 and the main part is the customization scripts. They need to be adjusted for the distribution. Fi also does not distinguish if you want to install a bare metal machine or a virtual host or create a change route or a live CD or even if you want to create a golden image. That's also possible because it's always creates some sort of yeah file system maybe on a DD image and then install packages into it. Yeah, the example, if you want to create a chain route, you do not have the heart disk, so the partitioning part is not needed and you mostly do not need the kernel. There are plans that I also create another tool for bootable images, maybe call it Fi cloud image. Let's see. And since I am doing Fi, since a lot of time we also found that it's really flexible and was very easily portable to different architectures. And here's a list of project, especially Debian LAN is very nice, which are using Fi or which has a Fi plug-in. And so they are mostly some GUI tools where you can administer your machines but for installing and upgrading machines, they're using Fi as a toolbox. So here's some Fi users. I always collect some questionnaires who is using Fi and yeah, so it started with a project at the university but as you see, there are a lot of companies or in Germany the city of Munich is very famous with Limux project, they installed a lot of machines. So what is new in Fi 4.4? I think there will be the 4.4 release in one or two months. I started or I rewrote the Fi guide, which is a manual for Fi and it was not up to date the last three years. So yeah, people say great, that you're working again. We now support image installation even if I'm not a fan of this, so yeah, but it works. And some technical changes from in-it-RAMFS tools to DrayCard and we extended the BotterFS configuration. What we have is a monitor GUI. So if you have several machines and can show this, how this works. So if you install several machines, you can call this monitor demon and it will just show you at which task of the installation this machine is and if everything is green, you know everything is fine and this is just an example and if it's getting yellow, orange or red, yeah, there will be problems and you have to look at the log files. So, and what I want to show you is if you have set up the Fi server, you can have two commands and create a bootable image, a bootable CD. This is not a live CD, this is an installation CD. And what I'm doing here is I'm starting a KVM machine with this Fi CD. So let's see, switching will work, yeah. So you can choose what do I want to install and I use now the XFCE thing. Then it's important that you have to enter grub and install me so no one can blame me, oh, why did the CD crashed my machine or stall me? So now it boots and I take question and you can look, it will take about 80 seconds. So any questions? Yeah, behind there. Can we turn on this light? You've mentioned Puppet and CF Engine. Yeah. Are you aware of anybody who's used Fi together with Ansible? Not sure, but on the Fi webpage, we have a list of users with their questionnaire. I would just grab through it and see if there's also one using Ansible. Okay. Not sure yet. So what, can we turn off this light? The other button, oh, there are two buttons. Ah, much better. So what you see here is that the packages will now be installed. So the first part, the petitioning of the hard disk was very fast and the defining of the classes and the main part is installing software packages. And all the software packages are on the CD. So you do not need any access to the internet with the CD. So if you're, since admin, you can prepare the CD and then send it to somebody and she can just put it in and install without any knowledge of administration. So what you see here are their shell scripts executed. This is the customization part. So these shell scripts just adjusted the system. We have some statistics. The installation took 79 seconds. Now I reboot the machine and we have again this group menu. Boot from OS, first partition. This is a grab reboot, not reboot. Boot up, which, and we can log in. We, in the customization script, I wrote a script that added a user called demo password secure file. And now, yeah, that's it. We have a XFC desktop in 79 seconds in a virtual machine. So if there are any question, I'm still here. I have again some more five flyers. Or yeah, if you're, yeah, you can write me an email or if you start using five, there's a five channel. This is very helpful that I can give very fast replies to it. Thank you very much.