 I will present to you today Opsi. Opsi is a tool to manage client in a heterogeneous environment in modern IT. It's very common that you do not have just one operating system that does everything but you have a multitude of operating systems that all need to be managed and that should be managed in a very efficient way. Opsi is a tool to do exactly that. First, to this guy speaking to you, my name is Nico Manzalowski. I'm from Germany. I would consider myself a very passionate Python developer and I think I'm lucky enough to say that I'm doing this also as my main job and not just as a hobby. I have six years as a professional Python developer for now and my company is the company behind the tool Opsi. We're based in Mainz. My job there is maintaining and developing Opsi. I'm very focused on the Linux side. We also have colleagues that are more focused on the Windows side but I'm mostly the Linux guy and responsible for the server side implementation and also managing the Linux client agent and also my job involves a lot of customizing for customers to adjust Opsi to their needs. When I'm talking about Opsi, I first want to give you a small introduction to the tool because I think many people don't know Opsi and this is why I'm talking here because I think it's a very cool tool and you should take it into your tool belt. Opsi has roots ranging back way back into the 90s when there was Windows for work groups. I never worked with it but I have colleagues who did. When UEB started, they were like a small software shop. We focused on geo-information systems and system administration and one of the customers wanted to deploy Windows for work groups in a large environment and this is where Opsi started. Back then, these machines were already installed in an unattended method via Boot P. Some of you might know Boot P. For others that don't know Boot P, it's kind of a pre-desert for PXE booting. The installation was quite simple. All you had to do was copy files to the new machine and maybe instruct them and you're done. You could boot your system. Pretty easy compared to nowadays. The server side back in the days was Solaris. That's running with Samba already. Samba was used to give the clients access to the files they needed for installation. It's been quite a while since then and Opsi moved on quite a bit. It gained more features for software deployment. Just copying and extracting files isn't nearly enough nowadays to manage the system. The system grew and gained more features to do in centralized management of clients. We're back from having some people running around and booting the clients. We now want to do this all remote. We have one point we connect to and then say, okay, deploy. The first management interface we had, they edited config files directly on the servers. It's something nobody would think about today, but that's how it was back then. The server side moved from Solaris to Debian first and in 2004 Opsi saw its first public release. Opsi was open source from the beginning. If you knew that there was a company providing such a system, you could just ask them and they would send you a CD with the source code on it. When we're looking at Opsi now, things are a little bit more modern. The server is running Linux. We don't just support Debian. We support a whole range of systems. On the server runs a web service that is accessed by all the clients to communicate and, for example, to see if there is any installation that needs to be done or if you're an administrator, you can check the service to see what software is installed or you can set something to install on a specific client or something like that. We still use Samba. Samba is a reliable project for us and Samba serves the install files just like back in the days. The management interface nowadays is Java, if you want a graphical interface. If you don't, there are various other options like command line access, but it's not enough to focus today. And also the clients, we also had one version of Windows we supported initially. Nowadays we support a whole range of Windows versions and, of course, since a few years we also have Linux support with something I really enjoy and something I'm kind of a bit proud of because the system it was initially developed to just manage Windows clients and it was quite a road to get there to have the same code base to be ready to also manage the Linux side. So, if you want to make photos to show them to show them to your manager or something like that, now here are the bus words to give you overview of what OBSI does. We still do operating system deployments. We still rely on unattended installation. As said before, we don't just support Windows, we also support Linux and you can nowadays also deploy complete images of your systems if this is what you fancy because an unattended installation may take you too long or it's not working good enough for what you're wanting to do because maybe some software is hard to install in that unattended way. Software deployment, yeah, it's still a thing because just an operating system usually isn't enough if you want to have something working with your system. You also need software on that machine. This is something that OBSI also does. And if there's software, yeah, we want to configure it so OBSI also can be used for the configuration management aspect. To make everything complete, we also have an hardened software inventory so that we know what hardware is installed on our clients and what software is installed. The hardware is important mostly for the Windows side because if you want to deploy an operating system, you usually need drivers for your systems and the easiest way to deploy the right drivers is to know what hardware is inside your computers. How does OBSI architecture look like? Can everyone read the slides? I hope so. If not, I uploaded them to the first page yesterday so you can look along there. On the upper side, we have some various clients that connect to the web service shown below. There's, of course, management interface. We have an agent, so OBSI is a system that relies on an agent to work. It's not an agentless system. And the upper right side, you will see the boot image. The boot image is what we use to prepare a client for the installation of a rating system. So a client will boot over PXE into that boot image. This will prepare, for example, the hard drive, maybe create partitions or something like that. And then we'll hand the installation over to an unattended installer. This could be, like, what you will find when you're setting up Ubuntu through an USB stick or something like that. On the server side, that's the part below. We have some back ends that store the data. You can rely on a file or MySQL, whatever it is you're liking. And most of the things we have on the server side is written in Python. That's where I come into play. As I said before, I'm a very passionate Python developer, so I had my fingers in most of the components we have on the server side. To take a more specific look on the server, as I said before, we have a web service that speaks to RPC. We rely heavily on standards to make exchange with different systems easy. So if you know how to connect to an interface via JSON RPC, it's easy to get access to the Opsi server. We still rely on Zumba. As I said before, Zumba provides the installation files that the clients then will access during an installation. And if you want to use Opsi we have a DHCP and TFTPD on the server along with a special component that we call the OpsiPxEconfD that is used to write named files, named pipes. Excuse me, please. These named pipes will then be accessed by a client that looks for bootable media over PXE. And the OpsiPxEconfD writes the pipe only when it's read, so you have a situation that the client will boot with that configuration that he's given only once. So you can let your client to just boot over the network and if there's nothing to do he will just continue boot usually starting the boot from the first hard drive or something like that. But if you want to set something specific the OpsiPxEconfD takes care of that and tells the client, for example, to load a specific boot image which then attributes whatever the boot image does. On the client side we have a multitude of clients we have a graphical management interface between Java called the config add. This will run on the client side we have the boot image I managed before and we have that client that we are running on the systems. The OpsiClient agent is usually registered as a service on that client and it takes care of the communication between the server and the client. It usually checks if work needs to be done you can configure in various ways when it should do these checks. For example, you want to do it as a startup to make sure when a system starts you get a new software installed or there can be things like timers that trigger in a regular interwall if the server has anything to say to the client. Because we are running as a service we can also use this to trigger events from the server side if you want to say okay I just found there's security update and I need to deploy this patch to all my machines I can trigger from a server that the deployment will be done and there's no need for me to wait until the client checks again at the server if there's something to be done. To make all this work we have a tool called OpsiScript that will take care of the installation the OpsiScript reads the script describing what should be done from the SambaShare I mentioned earlier and then will execute the steps you defined. To place something on our SambaShare we need to pack an OpsiPackage This is a package that usually contains the files you want to deploy along with the script that I mentioned earlier that will do the processing where the steps are defined what should be done this could be as easy as just okay run that binary or it could be more complex things like okay patch these files enter my configuration value or something like that if you don't want to deploy any files so that's sure that's fine all these parts are then later compressed into a single archive that makes it easy to distribute between different servers and you can also have easy access to various versions of your script lying around the archive itself it's a compressed tar file so still we are relying on open and established tools to do the things there's no need to reinvent the wheel here the idea with these packages has brought a lot from the Debian project you can define dependencies and some dependencies and things like that because we thought this is a very good mechanism that is established there and we want to use it for our tools these packages you get will then be extracted onto your server so the clients can access the files on the SMB share so usually your setup consists of the place where you build your packages you write your script and so on and then can deploy to production by copying the file and then install it there pretty straight forward as I mentioned before there's OpsiScript OpsiScript is a language developed for the OpsiProject that focus on the task that an administrator may face when he is deploying things to a client and it could be stuff like for example in Windows you want to edit the registry as a Python developer I would know what I should do with Python but I have to admit that it's not the most straight forward way usually they do things and I'm glad there's OpsiScript for tasks like that OpsiScript has a syntax tailored to the tasks that should be done for example registry but it's also open to re-use existing solutions so if you have for example a batch script written that does the tasks you want to do and you just want to deploy to all your servers yeah sure use Opsi and just call the external script OpsiScript is also the name of the interpreter when Opsi started the thing was called OpsiWinds which stood for OpsiWindowsInstaller there's the Windows heritage there but since we're also managing Linux clients with it we felt that we should rename it to OpsiScript because it's a more general approach so as the talk description said I want to look at how can handling Windows and Linux be done so you've learned about the system now I want to focus a little bit more on the tasks that may are at hand the first thing is is it a good idea to have a script to handle both worlds okay I can give not give you a good answer to that I think it depends on the tasks that lay at hand on the things that you need to do my experience once a package gets mature and you're not changing it that much it's easier to integrate both the links in the Windows version into one package and then enjoy that for example your dependencies you just depend on one package to think about is this deploying on the Windows or Linux box it just works it of course can be done and when you're facing program like for example I took here Thunderbird that you want to distribute in your whole environment you may face some challenges for Windows an installation is usually quite simple if you have an installer for you that you can run unattended from Windows XP to the current Windows 10 and everything works for us on Windows this easy on Linux things might get more complicated because as you might know Linux is not Linux the Debian behaves different from for example a Susan to the yeah we may have the software we want in the repositories of the distribution so we can just rely on for example app get or zipper to install it everything's fine but then again we have to think about okay the version we want to deploy is that the version we require we may have some third party plugins that require a very specific version of that software and the API may break in future versions so we may want to deploy our own version and yeah plugins are also a thing we can deploy the software sure but the first thing we have to do and usually the part that takes the most time is we want to configure our system so while on Linux most things are written into files on Windows we often have registry entries that also would change the behavior of your application and maybe configured in advance so that a user just needs to start a Thunderbird and then we'll have a mail account automatically connect to the network so to achieve that we can deploy for example the Thunderbird and various systems we should we should check some things and this is some examples I want to show you how things are looking with OpsiScript this is actual part of an OpsiScript to check the architecture because it may be that I face an architecture that I do not need to need to support or something like that or that I don't, that I can't support because the program I want to deploy doesn't support it, maybe I self-compile it, it's just a binary and it only works on a 64 bit system the bold part on the upper right there's the function getSystemType it will either return me that is an x68 system or it's a 64 bit system checks to write are very easy if you're working with people who are not programmers or do not have a deep understanding of how program works for them it's very easy to work with these parts to also check on what system type you're running in the same fashion we can then detect our operating system that's important if you want to make sure that the appropriate calls are made there's a function getOS that will either return I'm running on Linux or I'm running on Windows and T but as I said earlier Linux is not Linux and the same goes for Windows we have various versions of Windows nowadays running around the latest being Windows 10 and so we may want to detect what Windows release we are running on as you might guess there's also a function for that the getMS version info will return us the AP that the Windows reports back there's something like 6.3 for current Windows 8 the 6 is usually the NT6 is the Windows underlying kernel type and one thing we faced when Windows 10 was introduced was that we got back from the API as 6.4 but Microsoft then changed it to just report back 8.10 and most checks that were made what AP version am I on just check the first part and so they thought ok Windows AP version 1 and a lot of things broke for us so if you want to correctly handle this there's something like compare.separated numbers we can see if you're running correctly on the Windows 10 version or if you're running on lower version Windows 10 also has new challenges for us Microsoft says it's one system and you don't see any differences it just works it will be the last Windows ever released but internally they have different releases and you can also check for this release ID with the function mentioned below because of course they changed the underlying APIs between these versions and you will need to handle that what we have for the Windows side is of course there also for the Linux side we can check what version we're running on what distribution we're running on so that we can call the appropriate tools if we need to I think it's also very straightforward to understand we have a switch case in this case and we just check do we have a Debian Retter or a Zeus and then work accordingly to that if you want more specific information there also is a function for that of course that's similar to the one from the Windows side so that you don't have to learn everything from a new we're working with Linux and we're relying on the package manager that's something I usually do when using Opsi something I stumbled upon in the beginning quite often was that there might be a package log involved if you try to install your packages so the package manager locked the resources so no other process can install during that time and Opsi also has ways to handle that this function also has the nice possibility to kill the package manager if the things take too long if they're okay I need to have this deployment done in like 10 minutes so I can spend 5 minutes of that waiting for the package log and if then nothing happens I can just kill the package manager it's not very nice but you sometimes have to resort to things like that as you have now seen what is possible I want to give you some best practice that we usually deploy when writing scripts that should be running on different platforms first we first use the Opsi script constants like the script path to void hard coding paths or something like where did I install that media put into variable and change it accordingly hard coding paths even if you just think okay I'm just writing this for Linux now there may be the day when you need to change all your scripts because you hardcoded that path and you nowadays want to run this on windows it happens to make things easier here the Opsi script will do an auto conversion of the slashes in the path so you don't have to worry about is this a forward slash or is it a backward slash because Opsi will handle it for you on the downside one thing you can't do with this is you can't put slashes in file names if you want to okay I'm fine with that if you're using Opsi to manage your systems it's a very good idea to use the functions Opsi provides because they usually are cross-platform you don't have to think about what a system is running on and they just work there are some special things like the registry access I mentioned earlier this of course does not work on Linux but nobody expected it to also it's a good thing to share your libraries and talk with others I learned very very much with just talking to people and seeing how they are handling a script and this is something I think everyone should do to extend their knowledge so if you're not already convinced use Opsi Opsi works great in different environments also environments that may not be up to today's standards you may face a system where you don't have any DNS you can run an Opsi in multiple locations with just one management server that's great if you for example have a university like this and you want to have each billing treat them as a whole location because maybe the science lab for math requires something else like the one the biologists require something like that you can use Opsi as a very huge solution that's okay Opsi is very versatile we use Opsi a lot at work we for example married with Jenkins to do automated testing and part of why that's possible is the open API and you can also extend the API with your own custom functions if you know a little bit of Python so what now if you're new to Opsi and you thought this wasn't so uninteresting what you hear today I said just try it, have a look share experiences we have a great community of Opsi users talk to them, talk to us I'm very interested in feedback and if you're already using Opsi why not give it a try to automate Opsi a little bit more and to integrate it into your systems this all works because of the open API with that said I want to give a small roadmap on what we are up to we are want to improve the Linux support even further the administration tools and do some cleanup and refactoring and my personal roadmap last slide so far I want to move more things to Git we started as a company using SVN and I nowadays want to go to Git and I want to improve the work with the community and maybe provide a contributor license agreement and as my time is up one minute for questions I would like you to talk if it wasn't for the video recording I'm still around here if there are any questions I can't answer now yeah it's actually not being asked for that much but we just recently had someone asking for it so I will look into it for the client side I think or for the server side more questions then thanks for your time