 Thank you, everyone, for attending here for the time. Good morning. Yeah, Mongea. So the idea here is that we talk and I share some ideas about installing, like auto-installing the BSD systems that I used from time to time. And it's not a tutorial session. It's not a session that will be giving you like a copy paste ready-to-go material. The main concern that I have here is that you can get the information and get ideas or ways of doing it yourself. Basically, that's it. We are not using any kind of extra API or one-click button to give us or deploy a magically system that you want to have, but that you will understand how things work behind the scenes and you can implement it in yourself using either a Dragonfly BSD, FreeBSD, NetBSD, or OpenBSD for any kind of setup that you want to have. So I'm Vinicius. I'm a FreeBSD ports committer. And I'm also part of the Torr project. I'm a core team member of the Torr project. And I'm doing mostly the P&T, Privacy and Hasn't Technology work for Torr and merging as much as we can into the BSD system, like mostly the FreeBSD, but we also have stuff on the Open and NetBSD. And that's me. Like, what can I say? I also was part of other BSD conferences. In the past, I presented FreeBSD robot with a friend of mine, Ed Kahler. And BSD can. We also have an episode on BSD now. You can take a time later and watch it if you want to. And that's it. So let's jump to our agenda for today. As you can see, like a Python fan, like we have in it. I'm going to talk about a bit of avoiding Flamie Wars during the presentation. That is something that I think that is unhealthy. And it's not the purpose here for this presentation. And we'll also tell about the motivation that I have for writing this presentation. We are going to jump quickly into a reverse ARP bootpGCP. We're going to talk about the SysLinux. Mention very quick about the U-boot. Then we have a look into FTP, TFTP, HTTP. That gives us a way to fetch the live system image or any kind of diskless setup that we want to have. Then we jump into the IPXE project. And I will mention these two projects that use IPXE on behind the scenes for them. Finally, we get to the installers. And here we have the auto installers, because our idea is to not, let's say, waste time by sitting in front of the computer. That is actually the main purpose of this presentation, that we can automate as much as we can to deployment not only virtual machines, but also bare metal machines. If that was not clear in the beginning, but yet you can do it not only in VMs. You can also do this whole thing for physical machines. Yeah, so we get here the main VSTs, that I would say, Dragonfly, FTPC, NetVC, and OpenVST. And at the end, I will talk, I will have a few words about Puppet. That is the way that I use it to build the automated part for it. Really like it. There is the init. So avoiding the flame here is very important, because most people say that I can do better stuff if I kickstart a file with a pre-seed file. Or I can just use DD, and that saves me time. I can do like a dump restore, and then that's good. Good for you. As I said before, it's not the purpose here of getting into a battle. This solution is better than what you're presenting. You're presenting something that is unusual, poor-designed, whatever. That's your opinion. Just, as I said, sharing thoughts, sharing ideas that you can use to build your bridge, to build your infrastructure. And that is, again, I repeat myself again, the main purpose of this presentation. If you want to use a packer pre-seed file, kickstart a DD cloud config stuff, and say that's better and good for you, yeah, that's it. And, yeah, the motivation, using like a CD-POP more beer, not just because we want to hang out with friends and have a beer in a pub, but also I believe that the most important stuff that we can do in our life is not like sitting in front of a laptop or sitting in front of a computer, like waste time installing a machine, configuring some tweaks here and there, hardening the system, and, yeah. So we use the technologies and the software as the projects that we have to do it for us. So we can take care of our family, we can enjoy time with our friends, we can follow the sun, we can go to the beach, we can go to the park and whatever. You can enjoy like the hobbies, playing sports, taking care of like plants, gardens, and this kind of stuff. Also, of course, this part of hobbies, you can also do like other open source products. So here we jumped into the reverse ARP boot P with the bootstrap protocol and GCP. That will be like the kickstart for everything that we have when we boot like a client machine. So this demons for the reverse ARP, for the bootstrap protocol, and these people run in a server. And the server will be prepared to provide client machines. They can be like virtual machines or virtual machine or physical machines that will boot live system. And these days we have like a diskless setup for client machines, like machines that really do not have a hard drive or even machines that have the hard drive but they boot a live system and do any kind of special setup using this physical disks that not mainly run the operating system itself, they will just be used as a storage for some reason or yeah, whatever. So the reverse ARP, the bootstrap protocol and the dynamic host configuration protocol provided us like they are here sorted in kind of a historic way or poor feature way to the more fancy and elaborated features that we can get. Like the reverse address resolution protocol did not gives us like a DNS server, a gateway and we needed to manually configure like a Mac address table that will put like this Mac address is part of this. We'll get this IP address to this machine and this machine with a different Mac address we'll give this other IP address. And that's the way that the things work because in the past like it was like I don't know like 80s or something, this was the way that it goes. So bootstrap protocol, the boot came up and could gives us the DNS gateways. It also gives us the IP address of the server that will be used to provide us via like TFTP. We are gonna talk a bit later about it. The image that we are going to boot and it also needed like a pre configuration. So we mainly needed to go there and say like this machine we'll get this IP address and this stuff, this DNS gateway. And now we reach like the times that we use the DACP. The DACP also like have the same features that we got from the bootstrap protocol. It gives us like a DNS gives us the gate to it but it also gives us like a way to put a full qualifier domain name into the clients, the client machines. We can like put the NTP servers to be used in this particular network in a way that we don't really need to configure every single machine that's going to use a configuration that's like, it's dynamic. And if we use like IPv6, we can also do this but it would be like a GCP v6. It's a bit different from the GCP v4 if we like use to be comparing the RFCs but we can actually say that's this same thing. It's the same thing for this purpose. We can say that's the same thing. Provides the main NTP servers. And of course for v6, we also have like a router advertisement but that's another thing. It's not important here for us. So the SysLinux. SysLinux is a lightweight bootloader. It's a thing that will, it kind of got replaced this idea of having a BIOS and finding in the hard drive an operating system that will boot for us. So SysLinux is a lightweight bootloader that we can like put in a floppy disk. We can use to boot for operating systems from a FAT file system from XT2, XT3, XT4, yeah and it's a bootloader. It's a project that also has small nuances, different binaries that will work for different purpose. Here we are going to focus more in the PIXLinux which is like the pre-boot execution environment that we get to boot the live image. The SysLinux also has a way to boot ISO images and also has a way to like chain loading, other binaries, like here I put like the main disk images. And basically that's it for the purpose here. We just need to know that SysLinux is going to help us, it helped me to boot the diskless setup for the system that I use it to get away for auto-installing themselves. And Uboot, Uboot a lot of people kind of confuse it that it's a module for SysLinux but it's not SysLinux, it's mostly used for embedded systems for ARM in this case and different from SysLinux, it's kind of a first stage bootloader. You don't really need to like have something before it to load it and it will be like the bootloader in a first stage that don't have, how can I say that, extra helpers to load the operating system itself in like this embedded system running in ARM system. And yeah, the main thing that we kind of say here is it's not SysLinux. So now that we have talked about the protocols that kind of bootstraps the client machines information, like IP address, the ID of the server that we're going to use for fetching the image, get the DNS and stuff, we get into the protocols that we're going to use to fetch, to download or load the images for us. So the SysLinux that we mentioned before can use all these three protocols to download the image that we're going to use for booting the system. Here, as you can see, it's just like pinpointing stuff. I'm not a fan of writing like long texts in the slides so you can use like to get like information and maybe go into the search engine of your preference and look for more information about this. So the differences here that I show is the TFTP, is the second one listed here, does not offer us a way of doing authentication and encryption. It has this limitation, let's say, of the file size that we're going to transfer the network and also doesn't provide a way for most cases that we're going to use, we are all, doesn't provide a way for us in most cases that we can download this image from remote sites across, let's say, continents from the internet, so we basically, most usually in LAN, very specific way like a DMZ or something like that. Different from the FTP and the HTTP protocols that we can use automation and encryption. For this case, we don't confuse the SFTP with the FTP as they are different things. I just mentioned the RFC for the FTP as and the port study use, the SFTP, it's going to work together with the SSED demon, it has, it's not FTP as you can see. And finally, I would like to mention the HTTP protocol that offers the way that we can use authentication and encryption with together with the TLS. Also just mentioned for information that runs in TCP for free. And I added a pin point that we can combine it with HAProxy in a way that we like add some special favor over setup if we're going to, I don't know if you have like a special setup that can not go down and must rely on favor over or load balancing of this kind of infrastructure that I need to build. And yeah, you can combine HAProxy to use HTTP and get that into like CDN for your company or for your purposes that you could not do. Like let's say with the TFTP. If you guys have a question, just put in the chat or try to have a look here in the chat notes, that's all fine. Don't be shy. So IPEXY, the IPEXY project, that is a fun thing about the, it's on the FAQ about the IPEXY, the I stands for love and special. Anyway, so the IPEXY is a full PICY implementation. The PICY here is the pre-boot environment that we're going to use. And the main pin points here that I want to show you and share with you is that it can use ATP, ATP-S, it can load images from ATP-S. It supports IPv6. You can also load boot images from iSCSI and fiber channel over internet. And a very nice feature of IPEXY is that you can make it, let's say, looking here for the chain loading. We see like the road scripting. So you can put the scripting logic to work for us in a way that it sets up a particular VLAN that is going to join, that's this specific line machine that booted into the VLAN that will serve only, let's say, DNS traffic. So this machine that got booted will be joined automatically, base it on the scripting logic, DNS VLAN or the NTP VLAN or the web service VLAN. And we can use the IPXY scripting to do this. It doesn't mean that you're going to have machines that you put like in a hack or in the basement. And you need to manually change a lot of configurations to say, oh, this machine will boot for my purpose of web server. And this will put the purpose for NTP servers or whatever. You can add this logic into a, let's say PHP script or something like this. And IPXY provides a way that this VLAN will be configured directly before you boot the operating system. All right. Different from the SysLinux project, you can kind of flash an image and expansion run with IPXY and put it like, let's say, in a network card of your preference. I listed here like the models, Broadcom, Intel, and it also has a way that you use it together with VMware. IPXY can also boot ISO images and yeah. That's an interesting part for us is more like the VLAN setup, HTTP and V6 support. This is one of the projects that I share with you that uses IPXY. It's the Altium One bootable software, ECO. And this link will send you to their website with instruction about how you can use it to boot VST. And this is how the IEO looks like. It gives different options to different systems from the network. We don't even need to waste time doing ourselves the multi-boot ISO image or USB stick. Similar to what we get from Netboot XYZ. There is a GitHub page of the project. You have the templates and the menu that offers us a way to boot free VST and open VST. You can actually use this as a hint or as a source for your testing purposes later if you want to play it a little bit after the talk, that will be cool. You can get the templates to use with IPXY to boot like your free VST, open VST or any system that you would like to try booting in Altium Solar. This is how it looks like. You can see there like installers, Linux installers, VST installers, and installers. Let's say you want to boot CentOS, you want to boot OpenSUSE or whatever. And you can just boot it. Let's say you chose Debian and go get the ISO image from the Debian, the Netboot part of it and boot your system. You don't even need to download the image and boot it to a CD or whatever. You can just use Netboot XYZ and boot these different systems. So we reached the installers. Here we talk about the four main VST systems. And they are installers. For us, in this case, auto installers. So how did I manage to auto install Dragonfly VST on a client machine? I got its CD, or IMG, the CD image, let's say, and kind of booted it manually. I saw that it offers us a way to install it with a fancy interesting system. But for me, as I wanted to auto install it, I jumped it into this class setup. So it offers us the Pixiboot or the Pixiboot TFTP. Those are the, let's say, the bootstrap folders that we can use. I choose to use the NFS version of the Pixiboot. And after setting an environment to boot the Dragonfly VST, base it actually on its ISO image. I kind of, I got the ISO image, mounted it into a file system, change it like a very few configurations, like the loader.conf that specify that we are booting for an ISO image. So I changed it to say that we are not booting for an ISO image. And yeah, added a line on the atcrc.local. What did I add it into the rc.local? We can see on the next slide. I was playing with these two possibilities. So they have the PFI, it's the preflight installer that we can add informations for auto installing the system in the media that we boot. It gives us like a backend and it gives us a way to run the comments with a binary or a script before jumping into the installer itself. I discovered a very interesting thing that they had in the past, a CGI, like a web server that we could use to install the system. Pretty interesting, but it did not serve from my purpose. So yeah, just a shame here. The PFI offers its defaults under atcrdefaults.pfi.conf. So you move that file and change what you need to change and make it on atcrpfi.conf. It works in the same way that we work with rc.conf. So we can say like, you have config interface, whatever, do the dacp thing, put the disks in that and we can have the PFI to work for us. But that I have like for every image that I need to boot, I discover a way to get the thing for me to work well, work better when I use the rconfig. It's the remote configuration client server that DragonflyBSD has. It's really cool, really interesting. We just need a server running with the rconfig daemon that was in a DragonflyBSD machine and we have different, let's say, flavors of getting us an automated setup, like an auto installation with encrypted route with Hama FS and you just need to adjust to your purpose. So you have the server running the rconfig and the client machine is booted and that was the configuration that I changed and I'll see it up to local. So you just broadcast that, hey, I'm a DragonflyBSD, do you have something for me? So if you have something for me, I will auto install myself, base it on the configuration that you offers. So that working really, really, really well. If you want to not use a DragonflyBSD running the rconfig, you can kind of copy paste that logic from their examples and put it everything under rc.lopo if you want to. There is this one ticket open on the Dragonfly redline that mentioned the way that we can enable headless installer if you want to check it for more information, maybe a patch that you want to test or something, you can use this link description. So the previous one, I again, use it the diskless setup and we booted a freeBSD like a diskless system. The machine has, of course, for my case, a hard drive and it booted from the network, the image of a freeBSD that I chose to use as was 13, not all release and was pretty easy actually to outinstall it because I used theBSD install with a script that does actually everything for us. That's actually one of the motivations that I have for writing this talk because most people say that I can outinstall CentOS, I can auto-install a Debian, but freeBSD doesn't provide us a way to outinstall it but it did like for a long time, the other BSD systems did it as well. Anyway, I use it the scripting thing that we can use with the freeBSD installed. It's divided into two parts, the preamble and setup. Preamble would be like you set your variables and setup is like the script itself that runs into this seed-ruled environment on the installed system. So again, I use the diskless setup to boot the machine, got the NFSD running, put it the exports, configurator to do the DNS thing, configurator here and there, pixie booted it using its own pixie boot, like the loader that it has, and use it BSD install, that's basically it. BSD install uses the BSD config. If people don't heard about BSD config yet, it's like behind the scenes that you can add the default or you can configure your time zone. If you have any freeBSD machine running or test machine or whatever, you just type a BSD config, space like a time zone, and you can change the time zone is a way that you can do it graphically. In a way, it's comfortable for most people. This is how the script looks like for us. We have like a BSD install disk site for you, let's say, living in Chile, you can choose a mirror close to your location. If you're living in a lot of countries, you choose a different mirror, or you create your own. You can also add custom variables and put some values here, values there, and use it later into the script itself that goes after the shebang that you see. This is actually one file, it's one single file. The BSD install will read, we work this out to see that the first part is the preamble and the second part is the setup script. You don't need to have two different files. When we think about the shebang that is there, like being a Sage, this is actually one file. So you just add your logics here, there is that your hostname, you can run the free BSD update, you can bootstrap the PKG, you can install packages, you can made some changes to use, let's say, the NTP service. I'd say that you're living in Brazil right now. You can go to NTP.br and get their service. Service. So you work it out and put the NTP.br service there into your NTP.gov after installing everything and just reboot the machine. When I first started to get stuff like Rio when I was preparing for this presentation, I kind of got a bit stuck. And filed this bug on bugzilla about auto-installing the free BSD. So it was working for me. I was happy with it a lot, but I just decided that other people could maybe get some benefits of it. And I filed the bug, I proposed the patches and it got fixed. And thank you for everyone that helped to get this fixed. It now gives us a way to auto-install with a nice script and we can just boot the machine and grab a coffee, sit on the deck and enjoy this one. This is also a very interesting reading that I would share with you. It's about MFSBSD from Martin. It's on the GitHub. Martin is also a free BSD committer. And I really recommend you to have a couple of minutes and read this about the MFSBSD. See one second, share notes. So we reached the NetBSD installer. The NetBSD installer for me was really interesting because as far as I read it, main pages here and there, way to auto-install it, I couldn't really find a way. But I got into its utility menu, login functions and enable it. At the end of my setup, I got these two files under the TMP folder. So I kind of steal it from the installer system, put it in the server that will be like my, let's say the PXE server, the TFTP server, that will be like the main machine that will provides us a way to boot the system and have the disk-class machine to be ready for us. So I just needed to work at very few lines of this sys-ins.sh and I was able to like totally destroy the virtual machine that I used the first time, create a new one, base it on its login functions from the first install. The server booted a disk-class system in this new machine. I checked, of course, for this example, I updated the MAC address and said, okay, this MAC address will give me this hostname stuff, very few changes that you can figure it out. So the second machine that I booted was able to install itself. So I could get the PXE in, I got some packages in the installer and then that was it, it rebooted itself. And in the next boot, the IPXE configuration that I used first tried to boot from the hard drive, it booted the fresh and new installed system. I also just, as I mentioned before, I used it to rely on the RC.local. And when I was researching a bit about all the installations, I found this very interesting project, that is the Anita, the AutomatedNet with the installation and test application that we can use to install not only x86 boxes, we can also use it to install like ARM, yeah, as you see. But it's only used with the QMO and GAN. Now we cannot use Anita to, as far as I understood, I might be wrong. You cannot use Anita to install a machine and a physical machine. Here is a talk about it from Martin. It's also from another EuroBSD.com. You can definitely take time to read it later if you want to. And finally, we reached the OpenBSD installer. To be honest, it was the easiest BSD that I used and was able to auto-install itself. It was really straightforward. I just needed to name the the PIXI boot loader correctly and it just auto-installed it. It boots, it checks for a file called install.gov or checks its hostname, install.gov, which hostname is the hostname of the client machine or Mac address will be the Mac address of this machine, install.gov and install itself. It was really straightforward. It just booted the BSD.RT and that was it, really, it was really, really easy. And here is how the install.gov looks like. Nothing pretty fancy. It's basically like the questions that we got from the installer itself. There we can put their HTTP server. We have a local machine in our network so we don't go to any CDN. We don't go to any external box to fetch the sets that we want to use. And it just auto-installed everything for us. It also sets up a user if we want to, gives us a way that we can just put the SSH key of this user there and that's it. Here you have the main triggers for me that motivated myself to write this talk. It's a talk from Micha and a talk from Philippe and from the Euribus Decon 2019. If you have time, just go to their links here and watch this, little fellas. While I was researching a bit how I could auto-install OpenBSD, I also found this project, Fugu Ita from Ishihiro Kawamata. I hope it's fine. Sorry if I pronounced it wrong. Fugu means blowfish in Japanese and Ita means disk hard drive or something like that. It's a very interesting product. You can check it out if you want to. So far so good. We are jumping into the final section but I want to share something here with you. I believe I can, let's try this because I have a recording here. And we're into the matrix. Can you all see the chair desktop? It's good, working. Yes, yes, and you're getting in the view. Because you're small, small. So here is the OpenBSD machine that is going to auto-install itself. I'm gonna speed it a little bit because I'm also checking the time here. We are good, but I don't want to take much time on this. I can actually skip a little bit. So it's booting from the network. I have this system and this is the point that it just auto-installed it as a, yeah. There's a little Easter egg here in this auto-install. I'm not sure if you guys are able to detect it. That is a small error. But yeah, it just boots itself, checks for a install.conf and easy going. I will just skip a very few seconds here. Yeah, got all the sets installed itself, making all device nodes. We're linking to break unique kernel. Skip a few seconds, skip a little more. It's just a nice blue screen, not the blue screen of that. We are booting with fresh install system. That's it. We have this sub-parer up and running. Not sure. So we got back to the presentation, right? Puppet. So I decided to use Puppets. You can combine your wishes or needs to use a different tool, a different automation schema or whatever you want to. As I said before, our idea is not to get into battles, flame wars or, yeah, you know. I choose to use Puppet and that's it. That's what I'm sharing with you guys here. So Puppet needs an agent to be running in the client machines. It will kind of has states define it for this machine. It will say that this machine has this and that and all our configuration to be changed to be an updater or whatever. This machine and that machine has this and this and this packages. This machine needs to run service A, B or M, whatever. And that's how Puppet agent from the machine talks to the Puppet server and do its magic. The Arting K, sorry, runs in the Puppet server. It gives us a way to have dynamic environments. It's going to be set it up in the server in a way that we have this thing called the control repository that gives us a way to have the dynamic environments. And here we need to set up it to use a version control system of our preference. I chose Git. It worked pretty well. Let's say you have different data centers, different locations, offices and you can have different branches or you don't have different offers. You don't have different data centers but it has different stages. Let's say the production, then development. You can test the development, boot your machines. They are going to be auto-installed after the reboot. Then we'll be joining the development environment and we'll do your tests. And if it's all green, you can apply your logic and put some measure requests from the development range into the production range. So you discuss with your team and see if it's all green. So you just merge it and put the development into the production. So you are ready to go into production or you can combine it the way you want to. That is really up to you. That is just a feature that I'm chairing with you. Based on what Puppet offers us. And of course, that is a very interesting thing that we don't want to do is to put passwords into this Git repositories. The plain text passwords. So I offer you the possibility that you can use the YAML to encrypt your plain text passwords. So a YAML uses the Hi-Ara, the Hi-Ara or call database that you can use to define groups or specific configurations that can be used in the Puppet manifests with the lookup function in a way that you don't really have to expose credentials, passwords, or you can even encrypt the whole block, the whole manifest yourself because it uses like a VKCS. You can have like a private key and a public key. It will be stored in the server. So you don't have to be one exposing it all on its manifest. This encryption plugins can also be used. If you want to, if it's mandatory, you can combine it with the GPG plugin to have multiple private keys. So if you have a team that, or if you have a policy that demands that nobody can share credentials or private keys, you add this plugin and combine it in a way that everybody has its private key, and yeah, whatever. You can also use the key management system from Google Cloud or AWS. You can also combine it with a Hashic or Vault. And this is how Puppet Manifest looks like if you want to use it with a YAML. As you see, you have the Vechini Hosheda plain text password being exposed here. But if you use a YAML, you can have like maybe the same password, nobody knows, being used in a way that it's encrypted. We are reaching the end of the talk. I really wanted to share with you the artworks from Drahan Magia. You can really have nice stuff from this artist. So share all the data. Sorry. And to finish it, I will share with you the last video here, which is the, you can see it all right. The version that has the IPXE floating free VC machine. I will also speed it up because I think we don't have much time. Yeah. We're actually keeping people from the lunch. We're slightly over. Sorry. So skip, skip. Yeah. This is the part where the auto installer just started to install itself. And skip, skip, skip, skip. Yeah. It's doing its magic behind scenes. Skip, skip, skip. There you see the puppet installed, the agent. Here we are booting the machine again. And here we have the impaleada. An extra user was set it up. And we check it if puppet agent is running already. It was actually done. And the change that we did was like the, as I talked before about the NTP change, I added like the Google and the Observatory National NTP server using puppet, using IPXE, and using the FreeBSD auto installer for this particular case. And that's it. Thank you very, very much for your time here. Thanks. I don't know if people want questions or should we just let people go to the lunch? I don't see any questions in the chat. I also don't see any questions here and also in the chat and the chat notes, but I will be here the whole day. So just hang out on the RSE special. I'm around. Yes, and there's also the spatial.chat, which is for the hallway tracks, so. Yeah, right. All right, thank you very much for the talk. And thanks for being at EuroBSD.com. Here's hoping we can do this in person next year. Yeah, as we go. Right. Thank you. Yeah.