 Okay. Good morning again. We are back with the following talk. It's completely different angle. It's rear mass deployment. You can find, I will put also the presentation here, but you can also find the demonstration that I will give on this Hitchhook page. All right. It's a bit strange. It's a story about, let me explain about 35K. What do I mean with 35K? 35,000 systems and make rear happen for 35,000 systems, not an easy task. Not an easy task. Okay. Continue. This is a poll that we had in 2005, 15, sorry, about how is rear used. Let's say almost 50 percent of the answers that came back were about internal backups. So that means that they were using backup NetFS, and the location was more or less on the Nest server or NFS or whatever. You can also see there are some open source backup. This here, it's quite a lot. Probably Barrios, might be sculpting it. There's some other things. You see Cloud backups. It's not that maybe five years later, it can be different a bit, but on the customers that I know and that I work with who are using rear, they're also still using internal backup schemes. That was a side kick. Now, if you talk about rear, you have to talk about the Cloud also. In-house Cloud and also the outside Cloud. You have the Amazon, Adger, Google. There's a lot of vSphere VMs, physical service and even the older physical Linux systems. Susie Tents, for example, which are not official support anymore. Just as an example, I think two weeks ago was called to to help in assistance and do a disaster recovery which was failing on the very old physical system with a rear 1.14. I couldn't even remember when that was released. But okay, finally it worked. So these are the question that you have. If you have talking about rear mass deployment, where is it required and where it is not required? This is the question effect to rear or not to rear. This is the question that I hear all the time if I come to customers. We don't need rear. After a couple of months, I come back, we need rear because we had a serious disaster and our cloud system could not resolve it. Then I come along and they say, okay, we make snapshots. This is regular the situation within the cloud environment. Amazon makes daily snapshots and you can recover it. It's not an easy task to do that. It's a pain in the thing. I never worked with it personally, but it is more or less the same. So also with vSphere, virtual machines that take snapshots. If they're using some commercial backups solutions, there's a possibility then say that don't eat rear. Eventually, the customer that I wrote this mass deployment schema for came back to me and said, we want rear even if they're taking snapshots. They're changing the mind very often. If something very bad happens and they can't resolve it via snapshots because they lost something very seriously and the customer is pissed off because their complete warehouse is down, it's a balance that you have to take. You have to take very carefully about this question. It's not a stupid question to rear and not to rear. It's very easy said, we don't want rear because we have snapshots, we have very good backup schemas and it works fine. But eventually something goes wrong. Always. Okay. I don't have to convince you. If you want to do a mass deployment of rear, automation is the key of course. There are some very good software for it. You have Ansible, you have Chef, you have Puppet and some other tools, Salt, I may not forget these days. So they asked me to write a code book. They're using Chef at that company. So I use Chef daily. So I know Chef quite well. And you also use Ansible at home. So every deployment I do at home is written in Ansible from A to Z. I gave several demos with barriers, for example, the complete system setup and various automation backup is all done with Ansible. So everything is possible there. But you can do the same with Chef and even with Puppet. So if you want to mass deploy it, you have to be able to install rear, to configure rear, even to un-configure it. If you decide we don't want it anymore, you have to be able to remove the conveyor files and to remove it is also possibility. And you have to work with attributes. I come back to that. Attributes give you the possibility to define everything without touching the code book itself. I wrote a rear code book which is available already. It's not 100% finished. When it's 100% finished and the 35,000 systems are working fine and proven to be working fine, I will push it to the supermarket of Chef. And then it's available for the world. It's already available for the world, but you have to know the location, of course. For the moment, it's only tested on the rail the center six, seven, and eight, but okay, it is rear. So it means that it works on all other flavors of lining systems. The only thing that is not covered yet is inside the code book. The commands are maybe different, but Chef is clever enough. If you know Chef, you can make the configurations, definitions, or your recipes that they are equal on all US's effect. So I don't have to change much, I think. And it also recognizes older rear versions which are still more or less supported the 117, 20, and rear two to four. Why is that? That's not a stupid number that's coming from the rail community, so they are still supporting those three levels of rear versions, so it's covered in there as well. The attributes, I'll come back to it. I don't know if you can read it quite well, but it's effect and translation of your local configuration file, okay? And you can overrule it. You have, for example, the rear code book which will be in the supermarket. If you want to overrule with your own settings, you don't have to rewrite this code book. The attributes give you the ability to redefine these variables in your own code book. That's the nice thing about it, with attributes. So you don't have to touch the code book, you can just add it somewhere else and it will be using your variables and just instead of these default ones, okay? For that customer, the backup URL, yeah, because they are global and they have a lot of net-up systems where they were pushing their rear images because they were using NFS and the rear ISO image and even the backup is going to NAS. I think they have maybe 20 different locations where they put stuff. They have a file and I call this file the ETC install coffee file where they find the location and some other variables. So we would be able to read that file and use the definition which is set in there. If it's empty, then of course, rear configuration will not be configured because you don't want rear to work, okay? That's for example in Azure, the case for the moment. But okay, if there's something else which doesn't make sense, the configuration will detect it and will use same values, okay? There's an attribute for it which is the default. That's way of saying, okay? I will demonstrate this cool book now with kitchen. Kitchen is something that's also an open source community that can drive your tests with Puppet Chef Ansible and other stuff and it uses vagrant and some vagrant boxes to under the need to work with it. So you can find everything with kitchen over there and there's a kitchen YAML file which defines the test or the setup that I want. It looks like this. Just have a look at the header pages and you can see it. You can define everything that you want. You can, I'm using here vagrant but you can use any kind of driver effect. You can use different kinds of provisioners, OSs and then some other stuff that you want or require. And as last, you have a run list. This is effect when we talk about the recipe that we want to execute. Okay, I will give some demos. The first demo will be with a configuration file installed and this is the default value. That's something because my Mac is effect the LFS of Nest server and the virtual box is effect the client. So that is one of the 35,000 that we are speaking that needs a configuration. I will deploy the configuration through kitchen and kids will call automatically chef to deploy rear, et cetera. Then the second demo, I will just edit the config file here and put NA or empty, doesn't matter. Then it says, okay, you don't want to rear and see what happens and you can just delete it and you see what the default value will be, okay. And finally, there's also this is chef effect and part of chef is also another project, InSpec. And with InSpec, there's a very nice tool and you can define every test that you want. Verification test, for example. I use this tool, not daily, but very often at the customers to inspect systems before and after patching, for example, to see what changed and also use it a lot with security settings. So you can really scan your 35,000 systems and see if there are any vulnerability in there with InSpec effect. Very good tool. So, put source, by the way. Okay, I think this is the end of the slides. I'll go back for the presentation, okay. If I do kitchen lists, I already did the kitchen create and the kitchen create will, in fact, create the virtual machine. Nothing more than that, in fact, it's just the pure central service system. I did not do any special configuration. It is already created, but I have done nothing with it. So what I will do now is kitchen converts because that's the command that will run the recipe of Rear. It will take a few moments to kick off. So it will log in into the vacant box and it will start or start. It will first download the Chef stuff because I've defined it with Chef and then it will run the cookbook and now it fills. So why? Well, I can look at that here. Byton, I can't install download Chef. That's a pity. Let's log in for a second. Do I have an IP address? Do I have an IP address? No, it should be. It's going to there. That's a pity. It should work here. So that's also the problem with life systems, huh? Of course, it's Mac. It should be working, but it's working, of course. I don't know why it fills. Instead, let's say you have to download this and this and this. Yeah, okay. That's a pity. It can download Chef, so that's a problem. So you have downloaded that one first, but okay, there's another. Ping, ping, ping, ping. What did it say? It's pointing to the 10, it says. It's a half cost. Yeah, yeah, it should have it. Mm, it's not good, huh? Yeah, yeah, there's no IP for four. Okay, still have time. All right, yeah, now we have an IP address. Yes, all right. You can restart the demo. So again, it will log in into the vagrant box. As we have seen with the failure, it will try to download Chef, and then it will run the recipe. Okay, now it's trying to download it. Yes, it's a lot of traffic on Fosden Network, of course. But the nice thing, the following demonstrations will be faster for the simple reason, because Chef is already there, so it doesn't need to download it. So the first time is always the slowest one. But I want to start the demonstration with an empty system so that you can really see how it is working. And this is driven with kitchen effect. Okay? Yes? Maybe you can tell us something about the project, the industry with kind of devices you are saying is secret. Secret? No, I'm just asking you a question. No, real, it's not a secret. Now about the project with the certified K devices, what kind of devices do you have? Ah, okay, yeah, the question that is in pharmaceutical company, which is worldwide. There are quite a few of them. And they are using a very broad environment of cloud, cloud being Google, Azure and Amazon. And they also have an amazing great in-house cloud based on vSphere and HPE hardware afterwards. So, but I still also have a lot of physical systems from the past. So that's, it has to work everywhere, in fact. Okay, what you have seen now, it finally got possible to install Chef and run the recipe. It did configure Rear. It set up a weekly crown that you can see here. It even tested if it could mount the NAS location. That was tested automatically. And it set up a backup in the, oops, okay. It did set up the weekly backup for a weekly make backup. That's all automatically done. So this was driven by the file. Oops. And is it not installed? Maybe it's different. It's not there, okay. Here you can see the complete recipe, what it does. It's quite big, but big. Install the binaries and then it stalls the local configuration file. And you can see the local configuration, I'm not logged in. That's why I have to log in, of course. I was wondering why I couldn't find the config file. If I log in now into the virtual box, okay, and let's become rude because I have to delete something. This was the file. Okay, I will edit the file because for the second demo, I will use this one and just uncomment that one. Yeah. And then we can do the kitchen converge again. I will use another window for that. So this second demo commented out the location of the NFS location in the configuration file. That means now it's NA not applicable. That means that we don't want here to be configured. And let's see what happened. Not much. It only deleted the cron entry because there is no need to remove the configuration file. And the automatically backup is scheduled in fact weekly through a cron entry. So you just have to remove the cron entry and then we are fine, okay. Another possibility that I just want to demonstrate is just to remove this file. Okay. File is not there anymore. And just do the converge again. I see what happens now. Now it will take the default value which is inside defined attribute of the kubook, okay. And the nice thing about that kubook will be that you can have a wrap around it because most kubooks are part of a big collection. That's logical because it's not there. Yeah, I don't know. Ah, yeah. This is a security issue from the Mac. It's not allowed anymore to mount something which is not predefined within the user space. Okay. Please use get to loss. Let's see. That's always nice to have in a live demo, huh? This is Chevrolet. You can really see what happens here. Mildfield to resolve server. Volumous name of service not known. So he took the wrong volume. That's because it was not defined properly in the attribute probably. It's my fault. It was a test set up, huh? But okay. But I see you can really learn from it, huh? You don't bring your life system. You just a test environment that you can test your kubook until it works. Where am I? The kubook should be somewhere in here, I think. No, it is not. They'll put it somewhere else. But okay. Doesn't mind. It's not that bad. As you can see, it's a live demo. I won't dig into it because the time is almost finished anyhow. Okay. The kubook is, let's say, ready for deployment for the 35,000 systems at the customer itself. Here, this is a live demonstration. So if something breaks, it's not the fault of the kubook itself. It's probably fault of my attribute definition. But okay. That's the game of the life, huh? If you use live demonstrations, something will break. Otherwise, it's not live. Any questions about the kubook itself? Is there should be any interest for it? Do you have any favours for that? Like difference between, like, Cron or system D timers if you use real or can you still use it? The question was, in the demonstration, we use Cron to set up rear on a weekly basis. Is there any reason for it? Not really. That is more or less for the customer that it is done. Okay. In the past, in 2.4, rear was still automatically configured also in Cron entry. That in 2.5, that has been removed. Because we let it up to the customer how he wants to schedule rear. Because like you said, system D can do it these days. But still, Cron is used a lot or other possibility like title or control M is used to trigger rear. Whatever the customer likes can put in place. Okay. Time is up, my friends. I would say have a nice Fossum conference and take a sticker. And if you have any questions.