 So, hello everybody, thanks for coming here. When I introduce myself shortly, I'm Florian Haftmann. I'm working for the city administration of Munich, more exactly the IT service provider for the city of Munich, IT at M. And to understand what I will talk about, it is necessary to dive into the context in which I'm actually working. So, we at Munich, we are running an Ubuntu-based Linux distribution on about 18,000 machines with about 33,000 users. Our leading office platform is LibreOffice 4.1 and the transition to LibreOffice 4.0 is currently in planning. And this context did not fall from heaven, it has a certain history. So, during the 2000 years, there was a migration, actually, two migrations in one. First was a desktop migration which had the aim to introduce a free desktops environment in the city administrations together with an automated software deployment, the configuration management, training sessions, and so on and so on, what you need for that. And simultaneously, also an office migration or an office consolidation was issued which aimed at introducing a free office suite, establishing a letterhead system, the Walmux, I will speak about it with a few sentences later, and also to consolidate all kinds of office artifacts, templates, macros, extensions, add-ons, whatever, also including training sessions, of course. And about 2012, the migration was achieved. So, the two aims met somewhere in the center. Well, almost. There was one missing dangling link where the two didn't actually meet, and this is what I will talk about. And what this missing link actually stands for will hopefully become obvious during the next slides. But first I have to talk a little bit about the achievements of the migrations themselves. So, just to sketch roughly how the automated software deployment works in our desktop environment, the idea is you have a software database which models the assignment of software packages to workstations. And the admin does his configuration there, and then after the admin pushes the red button, install this workstation, everything happens unattended. So, there is a dedicated bootstrap server which provides everything for a new workstation to bootstrap itself from scratch. After the bootstrap, the workstation is able to retrieve its current package configuration from the software database, and then just to install the required software packages. And of course you can use the same technology also to update, uninstall, packages, whatever you want. And the key point is that it's automated. You don't have to go to the workstation and do something, there you do everything centralized using your software database. And another key advantage of our migration has been a centralized configuration management. So, the idea is you have your users in your IT landscape and they typically cover some roles. You don't configure each user separately, you aggregate them to roles. And those roles you can attach certain rights or certain features to, for example, the ability to access certain printers, the authorization to access certain network drives or the authority to plug in certain removable media. And what is a particularity of our configuration management that also applications together with a specific configuration may be assigned to roles on a per role basis. And this everything is stored in a big configuration database which is also centrally administrated by administrator. And to give you an example of how this is designed to work smoothly together, just an example how a concrete business application finds its way to the user. So these are our actors, user, admin and developer and this is our infrastructure. And of course at a certain stage, a developer has to decide where I will upload this package, this application to the repository. Otherwise it won't be installable. Then this is deployed automatically using the software deployment. But then still it is not implicitly available to the users. First, the administrator has to assign access to this application in the configuration management. Usually on a per role basis, this is just for simplicity here described on a per user basis. And what happens then when the authorized user logs in, in this example Alice on the workstation, doing the log in the workstation does a look up in the configuration databases, okay, this user is supposed to use that application. I will provide it to the user in a suitable manner. Usually using a start menu link or desktop link or a quick start link, whatever. And this is how this actually works together. So the benefits of this approach is that you don't have to be hypercritic on which workstation to install which software. So the idea is you can deliver your software quite generously to a huge number of workstations and the details, well this user needs that special application. That role requires that special application to do by configuration management because usually if you're using free software licensing is not an issue, you can distribute generously. Local hard disk space is rather cheap nowadays, it's not an issue. And well, if you would be required to do all this differentiation already in the software distribution, it would be harder to maintain because the software distribution there is some inertia on it. Removing or installing packages, you don't want to do that on a daily basis. But configuration management is very lightweight in that respect, you just change the assignment and it acts immediately. You don't have to do any manipulation on the workstations proper. And if you have this configuration database, software database at hand, you also have an explicit zoning map who is actually using what applications, which is very helpful in such a diverse infrastructure as the city of Munich because there are so many details and to do a proper life cycle management, you have to get hands on that information because otherwise you don't know how far much users is that really relevant, who needs really what, otherwise you have so many unanswered questions which you want to answer for proper life cycle management. Okay, so much to speak about the test of migration. Now a few words about the benefits of our office migration. Before this office migration and consolidation started, this was what was flying around in the city. There were various versions of a popular proprietary office suite at the bottom. I think you can infer the details. And built on that, there was a rich zoo of various office-based business solution. So in the course of the migration, about 20,000 macros, templates, forms, whatever you can imagine doing with office have been identified. And these had to be consolidated. So at the bottom of free office suite with a managed life cycle was established starting with open office org. Then nowadays in the progress of switching to labor office completely. On that was built a dedicated office extension, our letterhead system, the Walmux. It is a system on its own. It would be worth to introduce it in a separate talk, unfortunately, not this year, maybe next year. And it just enables you to manage all those typical template related tasks which you have in a public administration. And it enabled us to really consolidate all those funny templates flying around. Some of those pre-existing office solutions turned just out to be unsuitable for office. They have been migrated to proper web-based data applications. But this is now the reminder, about 100 specific solutions could not be migrated to something different. So they have been transformed as macros, as extensions from the previous office suite to open office or labor office. And just to give you an example, or to give you some examples what this actually looks like. There were simple things for parking lot management, writing letters to school parents and calculating some details in dog tags. For your interest, I have given you the original German term in terms also there, just for your personal amusement, maybe. And so this was some tiny obstinate core of quite lightweight but still office-based business solutions which you couldn't get rid of. And this is what I'm actually talking about here. So in this all big picture, I concentrate on these 100 artifacts. And this is actually the missing dangling link which I have spoken about in the introduction. Why is it a dangling link? Is this a dangling link if we try to combine the picture? So when those about 100 solutions have been delivered, implemented and delivered finally, it hasn't been done in the software deployment because this was not yet ready to start at the moment also to a certain extent. And this worked just in a very classical way so it has been developed and it has been handed over to the corresponding department. Maybe not on a floppy disk, this is just symbolically but in a very classical manner in a physical media. Yes, I already spoke about that. It has not been done within our regular infrastructure because nobody knew how to do that at the time. And well, and after then you don't know what's going on but what is very likely to go on at one stage, your contact in the department will be replaced. Change of position, whatever. And then at a certain stage you don't know when but it will happen eventually. You get a call from somewhere, well we have a problem with this macro, with this template, whatever, with this extension, this is your stuff, you have to fix it. And then you get something also with a mail attachment or ticket attachment, you have a look at it and think is that what we have delivered? Because you will find maybe the department and ignorance of what's going on has given the extension to an external contractor which has done something funny about it. So you experience an effective loss of your control of your own deliverables. I tend to call this the dark matter. You don't know what's going on, you just know there is something and something will happen but you don't know when, you don't know what, whatever. And of course everything gets lost which I have explained is benefits of our software deployment and configuration management. So this is the general picture and I will talk about a few ideas which we have applied to bring office extensions to our software deployment. This is actually, well, this was the length of the introduction and this is the core which I will talk about. So let's just imagine we want some kind of automated software deployment for office extensions and essentially we can boil it down to these three items. This is something we need or we want. We want to parameterize the office extensions. We want to have automated packaging and deployment. And we want to have some kind of activation based on roles. Do you remember the picture with the login? If an office extension is installed on a machine, it should not be available for all users who log in on that machine but only to the dedicated users which are really supposed to use this office extension. And let's start with the two easier ones because you can imagine, well, you can do this in a certain way or the other. It's actually not that big deal but there is still some music in that because if you do it in a eave way, you implement it separately for each extension. You remember I have spoken about 100 of them. It's not that little so you want to have a more generic solution. You don't want to do the same thing over and over. And so you aim for a uniform implementation for all extensions. And well, the key ideas are also not that non-trivial maybe. So, but just to provide a running example why you want to use parametrized office extensions at all, imagine you have this office extensions letters to parents and let us just assume, well, the source, the addresses for this office extension whatever are placed in a spreadsheet and this spreadsheet is localized in a Munich environment, typically on a net share. And you don't exactly know the path so you want to have that configurable because this might change over time, there might be different teachers which need different sources whatever. Yes. And how we have implemented this is that we have implemented a dedicated extension which provides other extensions and interface by which they're able to read and write configuration settings, key value mappings, whatever from a dedicated configuration file. And you can use these extensions commonly for all parametrized extensions. And you can imagine without going into details you can provide means that you can retrieve the corresponding configuration parameters during logging from the configuration database. You have to store them in that configuration file and then you are done with the task without going into details here. Hmm, to speak about the packaging also that is not a big deal either but the key idea is that we use a standardized source layout for our extensions. So we can use one build-out thing which assembles all the material to achieve a Debian package or you could also think about a Reddit package or even an MSE package for Microsoft Windows, whatever. But the key idea is when we have a uniform standardized source layout which needs just one build-out thing actually. We don't have to implement it over, over, and over. And then this resulting package should just put into a software deployment and deploy it using the existing mechanisms. And this approach to standardize the source layout has also another advantage which is quite important because if you have a standardized layout you also standardize somehow what ingredients a typical extension is supposed to have. And actually in our scenario where we end up with six standardized ingredients there's usually some functionality implemented in Starbase, Java, Python, whatever. There may be parameters I have spoken about parametrization already. Extension may also add menus, dedicated menus for them, provide maybe a certain toolbar as an alternative or as an augmentation of a menu. May also contain simple templates which somehow interact with the extension and also might provide documentation for the user which is usually made available using a menu. And if you have a standardized layout where this is always placed uniformly, it doesn't only allow for easier builds, it also allows for easy analysis because you have 100 solutions. See, you want not that you implement similar solutions over and over. You want to see what is maybe shareable, whatever, what can you model after existing material, whatever. Okay, so this has been the first two of our requirements. I think we are done with that at the moment. And now comes a more delicate point where we really have some technical innovation in it. This activation of our office on a per roll basis. So what's the challenge behind this? When you might remember this picture with the start menu, which is generated during login, for regular applications, that's quite fine. If there's not a link, the user will not see the application. But an office extension, you don't start it via menu. It's either present in your office installation or it's not. So we need a different mechanism for that. Just to recall the picture a little. So the aim is we have a certain office extension. We have a certain user called Alice in debt and the user has a certain role. Let's assume teacher. And we want if a teacher locks, for example, Alice locks into a certain workstation, it is the office extension is present. Also for every other teacher on the workstation, but not for non-teachers. And the key question is how to achieve this. So let us just look at existing mechanisms. Many of you might know that there are different basic mechanisms to provide an office extensions and I have put it here together on that slide. So you can use UNO package, the UNO package tool, which allows for user local or system global installations. You invoke the tool on the extension and then it's somehow mingled into the corresponding profile. There's also a way to deploy them directly to a certain office specific path on your system. Hmm. And if you look at those options, of course we want some kind of user local installation, but we also want to keep it simple somehow. And you see, we have no option which matches our needs in the first place. So we would have wanted one line which is all green, but we don't have it at the moment. I will go into details why I'm not a fan of UNO Picagin, our scenario. Because if you decide to do that, you start to think around with the user's local office profile which may contain a lot of stuff and a lot of settings and you have to do some bookkeeping that you really don't damage anything there. Also if you use that, the extension is always copied into the user's home directory which you do not want either for space issues because this is also back up and also synchronized for some kind of roaming profile in our environment. And then you give the user also access to that material. It would be a very uncomfortable solution and this is why I actually marked this over there as wet. It's just not an option to go. You don't want to implement this. But what can we do else? So our approach is we have this deployment path where we can pull the office extension to and we combine this with a traditional POSIX technique. Now we are really using features of our underlying system platform for our underlying UNIX platform. So that's our running example just to recall the names. And the key idea is we have, we install the extensions first into a separate directory which is here called extension repository and then we place a symbolic link from the office deployment path and if we use the right POSIX permissions we get what we want. So how does this look like in detail at the top we have actually our target point where we have to link from and at the bottom we have where the extension is actually placed physically. Okay, first we introduce an indirection. So this is on our all symbolic link. We have some naming which also includes the role name. So we place a symbolic link from a user share library of this share extension first to a directory beneath bar one and then finally to the place where the extension is located on the hard disk. You might ask, well, what do we gain from that? At that stage, nothing. The detail comes with the POSIX permissions. Now it gets a little bit technical. I will come to the key point immediately. The key point is the POSIX permission of the intermediate directory beneath bar one. You see the user, these are the last three dashes and that permission has no permission whatever but on the group level, all members of group teacher are able to read the content of that directory. Why that? Oh, sorry, I have to plug in my power, maybe. Is there no power here? Or was this just? No, there should be power. Oh, okay, the plug was here. Sorry for that interruption. But no member of group teacher is actually allowed to modify the contents of that directory. That's the key point. You cannot do this on a sold per user basis in POSIX but you can do it on a group basis. It's a traditional POSIX technique. You just have to remember it at that stage. And this way you get actually what you want. That's the technical core point. And the benefits of that approach where it's very lightweight, it's purely POSIX, there's not a big magic about it. And it's also somehow self-cleaning so if you reboot the system all the intermediate simulings get cleaned up and they don't accumulate over time and you need no manipulation in the user's home directory. You can do all everything in the system space. And just to conclude this, the running example at a glance, so the developer at a certain stage uploads a package with the extension. This is installed by a software deployment. The admin has tended to his configuration job providing the application, assigning it to the user, provide the configuration settings, whatever. And when the user logs in, the parameters are retrieved from the configuration database, the parameters are stored so that the extension later on will access them and the extension itself is activated by a symbolic link. And the result is, well, that's what we want. So, well, this is how our user-specific configuration management for office extension actually works. And to conclude with a short stock taking, this was our dangling link and with this peak piece in the whole mosaic, it's closed. My Gravian achieved finally. Okay. Well, these are the key elements. We have our automated package and deployments. We have our parameterized office extensions and we have our activation of office extensions on a per user basis. And then we get back all the benefits from our automated software deployment and also some kind of standardization in our sources and extensions. Well, if you have further questions which you don't want to ask here, either ask me during the conference or here in my email contacts. Thank you. One question. Do we have you experienced some errors or error messages if an extension is not readable from LibreOffice? No, it's just silently ignored. Otherwise, we wouldn't have taken that way. So it was not necessary to find a workaround for? No, no, it just works straight forwardly. Well, you could ask the question whether you should rely on such a behavior, but it seems such things are not very likely to change in LibreOffice over the time. Okay, I've already worked on some extensions in LibreOffice and I have experienced that there is no error message at all. Even if it's crashing, you don't have any log files or something like this, so it's very, I think it's interesting. So, but. Another question. Thank you very much. Thank you.