 So yes, that's me, Lubin, these are my colleagues. I work for a software company called RAV Technology who specializes in open source dot center automation. And OpenPCF is our main product, our main open source thingy. And I'm going to tell you today about OpenPCF, about what it is. I'm going to show you how the framework works. I'm going to show how you can use it in practice, you know, how you can use it on a machine and to configure it automatically. And I'm going to show you how you can use these results to bootstrap an empty data center. So to use a machine as a beginning to automate the rest of your environment. I will close my talk with a quick overview of current features, upcoming features. And before I start delving into OpenPCF itself, I want to give you a quick overview of the context. Why did we develop something like OpenPCF? So context. Anyone who has been involved with data centers or, you know, large rooms filled with computer systems will have noticed that data centers have many different platforms. If you're walking into a data center, you will see Linux systems, Windows systems, AIX systems, Solaris systems, different versions of these operating systems. Underneath the operating systems, you will see different architectures, Spark, Itanium, X86, 64, whatever. So lots of different platforms. And this difference sort of hurts, of course, you know, it's a given, but it's, you know, you have to deal with it. But even though you have to deal with it, these platforms have common needs. They need to be installed and they need to be configured. And to do this, we hire departments of people to do installations. And these installations give you varying and often isolated degrees of automation for these needs, automation for these needs. Yes, so what you see happening, for example, is that if you look at two data centers next to each other, let's say, for example, a Philips data center and a new one data center, you will notice that these people are essentially doing the same thing. Only they're going about it in their own way. They don't have any way of, you know, sharing implementation ideas, you know, maybe by coincidence when they meet each other at FOSTEM, but, you know, not structurally. So there's lots of variants in how these tasks are done. So this variance in how what is automated is also compounded by a few, you know, obvious effects and a few less obvious ones. First thing is, of course, that different people do things differently. If you're not thinking about storing what you are doing to change a machine in software somehow, then you automatically become dependent upon people itself. And what that means is that the individual neatness of the person, the individual skill of the person, becomes a factor in the product that the data center delivers. So it will have effect on, you know, if you are able to actually deliver a system on time or, you know, to be predictable in your time. Now, different teams do things differently also. So if your data center has thought about, for example, saying, OK, let's segment in a Linux team or let's segment in a Windows team and HP UX team, then these teams will, you know, do what you ask them to do, like automate installation configuration, but they will usually do it with their backs towards each other. The HP UX guys will go about it the way they know. The Windows guys will go about it the way they know. Linux guys, same story. So all this leads to variants in delivery times and variants in implementation. And, you know, when we were thinking about, you know, couldn't we create a piece of software that somehow abstracts this difference in platforms away so that you can, you know, more easily capture the expertise needed to configure services and then reuse that expertise on different platforms. So what is OpenPCF then? OpenPCF, first and foremost, is an extensible framework. It's something that a human can use to, you know, store expertise, create a service like DHCP-3 service or a buying line service, write it once, and then for every platform that OpenPCF knows about, never rewrite the surface. Simply lift the surface, run it on the other platform. Because of this, obviously, it is an automated service configuration tool. This is maybe the first thing that OpenPCF is actually. We do automated service configuration in a cross-platform way. And because of this, it becomes a software provisioning tool as a result. This is an important distinction. If you have worked with installation systems like maybe Spacewalk, or if you're more into the commercial things like HPSA, Radia, Altiris, what these guys are doing is that essentially they take a big set of standard services like DHCP, PXC, Bind, NFS, SIFS, HTTP. Put them all together in some sort of static thing and then, you know, put an interface on top of it and then tell you that you can install, for example, Linux and Solaris with it. Well, we wanted to take another approach to this and say, what if you could generate all these services you need and then have OpenPCF help you with using the services you generate to do installation? We aim to support all operating systems. This is our credo. When we develop something new for OpenPCF, when we think about changing the model or changing interfaces, we think to ourselves, can it still match this credo? And it's a lofty goal and maybe an impossible one to reach, but it's a noble goal so we keep it in the back of our minds. So it's written in POSIX SH. Now POSIX SH is cool because POSIX SH is a very low common denominator. It's something that runs on 95% of the operating systems out there nowadays and even the systems that don't have it by default like Windows or DOS have good upstream implementations for it, like SIGWIN and services for Unix or whatever they call it nowadays because they've changed the name so often on Windows and you have DGGPP on DOS, which is actually also in a complete POSIX environment. It's licensed in the GPLv3, so it's open source and at the end of my talk, I will give you obviously a link to the webpage where you can download it and check it out. So let's take a look at the framework. The framework, first and foremost, exists from platforms. Don't try to read this. This might be a little bit difficult to read. It is just for illustrator purposes. Now a platform in OpenPCF is an abstraction that tells it about a specific operating system. Now, for example, here we have four little squares and these squares are different variants of Red Hat. So you have version four and version five, IPv6, X86, 64, and here we have an example one called RL5, X86, 64. It tells OpenPCF about what kind of init system is used, where is data stored for bind, where is data stored for some other service modules. It tells it about specifics of that platform and we currently have quite a few platform descriptors. This is the current stable version, five operating systems on a lot of different architectures totalling 16 platform descriptors that we currently know about. On these platforms, we can set up surfaces. Here we have a surface and if you look at this surface, you can see, for example, this is a DHCP surface which has an implementation in it called ISC DHCP-3. Of course, it's insinuate that any surface you can make a machine provide can be implemented by multiple systems. It doesn't have to be ISC DHCP-3, you can create an MS DHCP module and then have created a Microsoft service. So currently we have 15 surfaces in the main distribution. So there's things here like bind nine, DNS surface, SMTP by POS62, IMAP, POP, SASL, SMB, LDOP, NFS, all kinds of surfaces with 18 implementations in total. Here you will actually see the example of having multiple implementations for a single surface which actually has to do with the fact that certain surfaces are not available on all platforms. So you have to take that into consideration. So these surfaces can be grouped and they can be grouped in roles as obviously very convenient because if you don't have roles then you cannot easily group machines and functionality wise. So these roles are associated with configurations. A configuration stores information about your landscape. What does your data center look like? How many networks does this have? One, five, 10. How big are these networks? How are there sitter masks and net masks associated? Names of companies and company information that is used to generate certificates. That's all stored in a configuration. And lastly, a configuration associates a platform. So if you look at this example, here you have an example of a complete configuration and this is a configuration where OpenPCF has enough information to actually configure the surfaces defined in the role on the platform of choice. And the nice thing about this is that you can switch like this, your entire configuration to different operating systems. I think that here we switched quickly from Red Hat to Debian to NetBSD and it will give you the results you expect. It will configure these surfaces according to the specifications in your configuration and set these surfaces up automatically. So then you as a human, what can you do with OpenPCF then? What commands can you actually run with OpenPCF if you have a complete configuration like this running? Well, you can build configurations obviously, clean them, install them, uninstall them, start them and stop them. This is what you actually type in the command prompt to generate configuration and make it active or take it away. So knowing, having this quick overview of the framework, how would this work on a physical machine? So let's take a look at automated surface configuration in practice. We take an empty machine, suppose we're on an island, we only have a couple of CDs with us and coincidentally these CDs are the current platform descriptors of course and you want to install your machine. So there's no luxury like PXC available yet or something so we insert the CD, install the operating system of choice. We place OpenPCF on the system in say slash root OpenPCF or slash OpenPCF, whatever. You can actually leave it, you can actually take OpenPCF off if you're ready with a machine by the way. You place a small configuration file which is really small. This is actually the entire configuration file for an OpenPCF run if you don't have to change anything, if you can work with existing platforms and existing roles. So here we associate a role with here, the universal role. Here we associate a platform and here we have our company global information and here we have our networking details which is an array of networks which are named and which have a sitter mask. This array can be as long as you want and this will take care of, for example, DHCP ranges that are serviced, bind domains that are serviced, et cetera. So when you've done all this, your services are ready to be staged. They're configured, you can do something with them. So when you use the build command, the surface configuration and data will enter OpenPCF staging area. When it's in the OpenPCF staging area, you can actually install and start it after you've inspected it and you like it. So if you install and start, it's active on the machine but the nice thing of course is that if you don't like it, you can go back. You can actually clean. You know, when you uninstall, you get back to the staging area and when you clean, you're back at the beginning again and you can repeat this as many times as you want which is very convenient if you're developing services and working with it. So these services here are the services we set up automatically with that configuration file. So we have this machine. It's running all the services we actually need for deployment of operating systems. So let's see how we can use this machine then. Software provisioning then. We have a data center, 120 machines made with Inkscape, by the way. And we zoom in a little and we take this first machine that's running all those services. Only it's running services, but it doesn't have data yet. So let's associate the data store. It can be a USB disk. It can be a Symmetrics if you like your storage a little bit bigger. And you put some ESOs on this. Now OpenPCF has the tools and utilities that can help you with connecting those ESOs to HTTP, NFS, SIFS, TFTP, DXP, DHCP and make sure that you can install it. It also has tools that allow you to register machines in the installation system. So when you've done that, you can actually install your operating systems, just F12 install those machines, push OpenPCF to these boxes using things like CF-Engine, SCP, Puppet if you want and then have OpenPCF run its build, install start routines and you're running your different services, different roles on different operating systems times the entire data center. This is actually stuff we test for real in our testing environment. So having all this in overview now, I wanna give you a really quick because I don't have too much time I see, overview of features. We support many operating systems. We do automatic connection to needed third-party repositories. Truck is not in Red Hat 4. OpenPCF knows about it, will connect to extra repositories and warn you that you're not connected. Automated dependency checking, so it knows which packages to install to provide a certain service. Openport detection, you accidentally left port 25 open, you're trying to install postfix. You can't, OpenPCF knows about it, warns you about it. And RBAC and firewall detection. Upcoming features, more platform descriptors, HPUX, Lars, and AIX, and held up service integration for modules. That's my talk, 15 minutes is up. Wait a second, thank you. Have a look at OpenPCF.org. And I hope I got the idea across.