[00:00.000 --> 00:11.180]  So, welcome to my talk, Clear Skies, no clouds inside, running a business on free and open
[00:11.180 --> 00:12.180]  source software.
[00:12.180 --> 00:18.600]  A little bit about myself, my name is Henpieter van Braa, but if you talk to me, please call
[00:18.600 --> 00:23.900]  me HP, my mom does, and it feels much more at home.
[00:23.900 --> 00:29.980]  I'm a co-founder of two Godot-related companies, prehensile Tales BV, which is a Godot-consulted
[00:29.980 --> 00:37.120]  company, and recently Ramatalking Corporate, which is a company that plans to improve the
[00:37.120 --> 00:41.320]  Godot mobile experience, always be selling, I just heard.
[00:41.320 --> 00:47.560]  So, you know, I'm also a treasurer of the Godot Foundation, a gigantic nerd, and I started
[00:47.560 --> 00:55.120]  a free and open source code hosting site called Nutterbug.org around the time when, who was
[00:55.120 --> 01:03.800]  at Gatorious Shutdown, I think, and my personal blog is at blog.tmm.cx.
[01:03.800 --> 01:06.000]  So what is this presentation about?
[01:06.000 --> 01:10.360]  First of all, can you run a business entirely on free and open source software?
[01:10.360 --> 01:13.400]  Should you run a business entirely on free and open source software?
[01:13.400 --> 01:14.400]  Are you mad?
[01:14.400 --> 01:18.640]  And by that I mean me, maybe some of you too, I don't know.
[01:18.640 --> 01:24.360]  What does it mean to do this, and how can you actually do this?
[01:24.360 --> 01:30.160]  But this presentation isn't about, it isn't a total lesson on like managing a large fleet
[01:30.160 --> 01:35.400]  of servers, there's other talks about that, there's other people specializing in running
[01:35.400 --> 01:41.360]  data centers with thousands of servers, this is not this, this is for a reasonable amount
[01:41.360 --> 01:44.680]  of people in a reasonable amount of servers.
[01:44.680 --> 01:48.480]  It's also not a lesson in a flame, I'm starting a flame war about configuration management
[01:48.480 --> 01:53.000]  systems, so please don't add me if I say something you don't like.
[01:53.000 --> 02:01.440]  I am going to say some things you don't like if you are a CIS admin for a much larger organization.
[02:01.440 --> 02:03.840]  So first of all, can you do this?
[02:03.840 --> 02:09.880]  Well, I've pulled all the speakers on this stage and 100% of them say yes, so that's
[02:09.880 --> 02:13.160]  a good start, I think.
[02:13.160 --> 02:15.560]  So why would you do this?
[02:15.560 --> 02:19.360]  That's I think a question that a lot of people might ask themselves, I mean we're all here
[02:19.360 --> 02:24.440]  with FastAmp, you're here, so I don't have to talk to you about the benefits of open
[02:24.440 --> 02:28.120]  source software, why you should use free software, et cetera, et cetera, et cetera.
[02:28.120 --> 02:31.040]  That's not what I'm here for.
[02:31.040 --> 02:37.920]  So first of all, while you can use free tier of cloud services for almost everything, you
[02:37.920 --> 02:40.120]  can get most of the features.
[02:40.120 --> 02:44.680]  Once you start to get to a certain size, even if you're only as a small company, you end
[02:44.680 --> 02:53.880]  up with five, six, seven accounts for individual users, and it is very difficult for people
[02:53.880 --> 03:00.000]  to figure out what user you're going to use, what passwords to use, so you either end up
[03:00.000 --> 03:05.320]  with people using very insecure passwords, so you end up having to force a password policy
[03:05.320 --> 03:10.520]  on them, and then they're just going to write it down or whatever.
[03:10.520 --> 03:16.040]  And someone still has to fix these issues if they happen in your company, now you are
[03:16.040 --> 03:23.640]  certain suddenly help desk for people forgetting their passwords, at least that's been my experience.
[03:23.640 --> 03:27.400]  So access control is actually the real big one.
[03:27.400 --> 03:33.960]  Once you start to mix a bunch of different cloud services on basic tiers or free tiers,
[03:33.960 --> 03:40.440]  figuring out who has access to what, if everyone has the access that they need, and most importantly
[03:40.440 --> 03:45.560]  do people have more access than they need, it is very difficult to keep track of which
[03:45.560 --> 03:49.640]  document was shared with whom, why was it shared with that person, is it an individual
[03:49.640 --> 03:54.360]  that shared it with another individual, is it someone that maybe left the company now,
[03:54.360 --> 04:00.360]  but they shared it with their public or private Google accounts, etc., it's very difficult
[04:00.360 --> 04:02.440]  to keep track of these things.
[04:02.440 --> 04:09.560]  This could be a problem if you sign non-disclosure agreements with customers, other people that
[04:09.560 --> 04:15.080]  you work with, and depending on the business that you actually run, it could be a compliance
[04:15.080 --> 04:22.760]  issue, particularly now with GDPR, etc., there's a lot of things you have to keep track of.
[04:22.760 --> 04:29.480]  Of course, I see some of you think, but you can already do this, in fact, my company already
[04:29.480 --> 04:38.480]  does this, yes, it is certainly possible, but usually, if you want these level of features
[04:38.480 --> 04:43.480]  and these level of integrations, you end up having to pay actually quite a bit of money
[04:43.480 --> 04:53.400]  for individuals, and only to get this fairly basic level of control over your data.
[04:53.400 --> 04:59.080]  It also does work if you say, okay, I'm going to pick one SaaS provider, if you say, okay,
[04:59.080 --> 05:03.440]  I'm going to use only Google products, I'm not going to use anything outside of Google
[05:03.440 --> 05:08.800]  products, if Google doesn't have it, I'm not going to use it, that, of course, also works.
[05:08.800 --> 05:12.720]  So, is this all about money?
[05:12.720 --> 05:20.840]  Well, not really, I will get to that in a minute, but the first thing I usually hear
[05:20.840 --> 05:28.040]  from anyone who talks about doing something like this is either a knee-jerk reaction
[05:28.040 --> 05:34.360]  as in, but it's actually more expensive to do it yourself, I don't think that is true
[05:34.360 --> 05:41.560]  at least, it's not true for me, so at least this means it's not a truthism that is definitely
[05:41.560 --> 05:48.000]  applies to all cases, or of course the other one, it's only free if your time is free,
[05:48.000 --> 05:54.680]  that is also fair, but having tried this in a different way, supporting individual people
[05:54.680 --> 05:59.880]  in a bunch of different time zones in the case of my companies, with, oh, I don't have
[05:59.880 --> 06:06.200]  access to this document, can you send it to me, or I have people working in North America
[06:06.200 --> 06:14.280]  who share documents or fail to do it correctly, and a person working in Poland needs it the
[06:14.280 --> 06:19.000]  next day, due to the time zone difference, they won't get their document until 5 p.m.
[06:19.000 --> 06:27.560]  because nobody but the person who created it had access to it, this is also a time sink,
[06:27.560 --> 06:35.640]  and of course if the worst came to worst, failing in a compliance case is probably not
[06:35.640 --> 06:43.880]  kind of a free either, so what is this about then, if it's not just about money, first
[06:43.880 --> 06:48.880]  of all I just like being in control of my data, I like to know where my data is, I like to
[06:48.880 --> 06:53.520]  know where it's backed up, and I like to know that if I need to, I can just stick it on
[06:53.520 --> 06:57.960]  an external USB drive and take it with me somewhere, sometimes you just want to hack
[06:57.960 --> 07:05.880]  your data, I like having unsurprising costs, I know exactly how much my infrastructure
[07:05.880 --> 07:10.720]  is going to cost this month, I know how much it's going to cost next month, if I need to
[07:10.720 --> 07:17.760]  for a new project, whatever, add five external people to give access to some shared resources,
[07:17.760 --> 07:23.400]  I know I'm not going to end up paying 150-200 euros more next month, that I don't need to
[07:23.400 --> 07:30.120]  forget to not cancel again because otherwise I end up keeping paying it.
[07:30.120 --> 07:35.680]  It gives me a big peace of mind when it comes to access control, what I just talked about,
[07:35.680 --> 07:41.480]  I know exactly which one of my users have access to what data, I know why they have
[07:41.480 --> 07:48.240]  access to it because it's based on group memberships, and I know, luckily this has not happened,
[07:48.240 --> 07:53.280]  but I also know if something went where to go really wrong, I can in fact make sure that
[07:53.280 --> 07:59.800]  people stop having access to the data that I don't want them to have access to anymore.
[07:59.800 --> 08:05.960]  By giving people access to just one user ID and one password and one way of logging in,
[08:05.960 --> 08:12.800]  I feel like I'm making their day just a little bit better and that makes me happy.
[08:12.800 --> 08:18.680]  Just using free and open source software is nice, I mean most of the people here are here
[08:18.680 --> 08:23.320]  for a reason as well, so I'm assuming that most of you agree with that.
[08:23.320 --> 08:28.960]  If I run a laptop with just free software because it's important to me, why would I run my business
[08:28.960 --> 08:38.360]  on anything else? It feels very good to be part of a community rather than just a customer.
[08:38.360 --> 08:48.520]  I do pay for a certain software, let's get into that later, sorry, but even there you
[08:48.520 --> 08:54.880]  end up not really being treated so much as a small customer, you tend to be treated more
[08:54.880 --> 09:01.680]  like a community member to a certain extent. Also, they appreciate good buck reports more,
[09:01.680 --> 09:12.640]  which is always nice. But isn't this like super-duper hard? I don't think so. It is true
[09:12.640 --> 09:16.960]  that you need some things, you need to know some things that you might not need to know
[09:16.960 --> 09:21.400]  otherwise, particularly not to say you go in all in on Google Workspace or you go in
[09:21.400 --> 09:29.920]  all in on Office 365, you don't need to know a whole lot about infrastructure at all. For
[09:29.920 --> 09:35.040]  this you do, I'm not going to lie about that. The most important thing is actually DNS,
[09:35.040 --> 09:39.360]  tying all of that together, making sure that your emails don't end up in people's spam
[09:39.360 --> 09:44.160]  folders, et cetera. Most of this actually boils down to a basic knowledge of DNS. You're
[09:44.160 --> 09:49.360]  going to need to know a little bit about how to run a web server, how to administer a web
[09:49.360 --> 09:54.920]  server and what web servers do, but not as much as you might think. And of course a basic
[09:54.920 --> 09:59.400]  understanding of the Linux CLI, or I guess the FreeBSD CLI, if that's what you decide
[09:59.400 --> 10:09.160]  to do. But it's a similar thing. So most people when I talk about this have a perception
[10:09.160 --> 10:15.400]  that building something like this ends up with a cognitive overhead that looks something
[10:15.400 --> 10:19.680]  like this. It's an extremely complicated set of tools where every individual thing that
[10:19.680 --> 10:27.800]  fails could break everything. But in reality it's really not that bad. You end up with
[10:27.800 --> 10:33.560]  a bunch of containers running on one or more hosts with a simple set of configuration files
[10:33.560 --> 10:39.720]  that you stuff into Git and that's basically it. You don't manage 15 things, you manage
[10:39.720 --> 10:47.680]  six things or seven things. All right. So how do you do this kind of thing? Well, the
[10:47.680 --> 10:54.200]  most important thing really is to keep things simple. As soon as you start looking online
[10:54.200 --> 10:59.320]  about managing Linux servers, et cetera, you end up finding a whole pile of wonderful
[10:59.320 --> 11:02.360]  tools. I'm not trying to tell you that you should not use these tools, by the way. I'm
[11:02.360 --> 11:07.960]  just telling you that in this case, if you're just managing two or three servers, some of
[11:07.960 --> 11:17.080]  these tools might not be what you need. And trust upstream. When you use a cloud provider,
[11:17.080 --> 11:23.440]  you're just trusting that your cloud provider does the right thing at any given time. If
[11:23.440 --> 11:28.560]  you use a piece of open source software, if you use an open source operating system, if
[11:28.560 --> 11:36.560]  you use an open source engine X or other web server, trust that upstream tests the stuff
[11:36.560 --> 11:46.200]  they do. You don't need a five-street test environment just to install a security update
[11:46.200 --> 11:54.680]  on your operating system. So how do you keep things simple? As I said, there's a lot of
[11:54.680 --> 12:00.800]  really great tools like PuppetChef, Ansible, Juju CF Engine, BCF G2, SaltStack, and probably
[12:00.800 --> 12:05.120]  one that I forgot. I think there might even be some in this floor that I forgot to include
[12:05.120 --> 12:14.400]  in this. My apologies if that's one of your projects. These tools truly are great. I have
[12:14.400 --> 12:19.200]  been a sysadmin at a large company and without tools like this, I would have absolutely lost
[12:19.200 --> 12:28.520]  my mind. However, setting up services using these tools is a lot of translating between
[12:28.520 --> 12:34.960]  documentation you read about the tool into a configuration file format that isn't the
[12:34.960 --> 12:40.960]  one that is documented on the side of the thing you're trying to configure. And there's
[12:40.960 --> 12:48.280]  a lot of testing involved, which is great if you need to repeat this on 100 servers,
[12:48.280 --> 12:53.800]  but if it's one box you need to do and that you maybe need to redo in a year, it's a lot
[12:53.800 --> 13:01.480]  of cognitive overhead. And if your business grows to the point where this becomes necessary,
[13:01.480 --> 13:07.480]  then probably the overhead of converting what you did now into a PuppetManifest, Ansible
[13:07.480 --> 13:14.680]  or whatever is probably not the thing that's going to prevent you from growing. In that
[13:14.680 --> 13:19.000]  same vein, as soon as you start to look at, okay, how do I run containers? How do I do
[13:19.000 --> 13:28.520]  that myself? Again, lots of great resources, lots of super great projects. But if you search
[13:28.520 --> 13:33.640]  on Google, okay, how do I run a server with containers? One of the first links you're
[13:33.640 --> 13:38.520]  going to find is, okay, you're going to get to set up a Kubernetes, you're going to create
[13:38.520 --> 13:48.640]  an undercloud and an overcloud, and you're going to set up redundant, I don't know, load
[13:48.640 --> 13:53.280]  balancers, that was the story I was looking for. And you're going to set all of this great
[13:53.280 --> 13:57.120]  stuff up, and at some point when you have a thousand services, it's just going to be
[13:57.120 --> 14:02.680]  just as easy as if you had a hundred. Yeah, and I can understand why if you start reading
[14:02.680 --> 14:07.320]  that you get incredibly overwhelmed immediately, because that is a lot of stuff to learn. And
[14:07.320 --> 14:13.560]  again, you're not going to need it for what we're talking about here. Again, I think all
[14:13.560 --> 14:19.480]  of these projects are great. I have used many of them. This is just not about that. Please
[14:19.480 --> 14:27.760]  don't add me. So what does it mean to use simple software? So in this case, use what
[14:27.760 --> 14:32.280]  is supplied by the OS that you use. Every piece of software you install that is not
[14:32.280 --> 14:36.840]  in the repositories of the operating system use, that is something that you might regret
[14:36.840 --> 14:43.440]  later because that is something that is not tested by your upstream. This is again when
[14:43.440 --> 14:48.720]  we come to the trusting upstream part of things. So in this case, we're going to get there,
[14:48.720 --> 14:54.600]  I'm using Fedora for most of this stuff. Use Spotman, not Docker. Use SystemD, not whatever
[14:54.600 --> 14:58.920]  else, a nice thing you might come up with. Use WireGuard. Don't try to do anything too
[14:58.920 --> 15:05.000]  creative and use Git for your configuration management. And this is probably the most
[15:05.000 --> 15:11.960]  controversial point of this presentation. Use a recent OS. You do not need CentOS. You
[15:11.960 --> 15:16.960]  do not need Alma Linux. You do not need Red Hat Enterprise Linux. You need something where
[15:16.960 --> 15:24.760]  if you read the documentation, that it is the last thing that people actually touched.
[15:24.760 --> 15:31.440]  People are not writing documentation generally speaking on how to set up a modern thing on
[15:31.440 --> 15:40.520]  an ancient enterprise distribution. Again, these things have their places. I'm not trying
[15:40.520 --> 15:44.800]  to tell anyone that these things are bad. Again, this is about you managing your time
[15:44.800 --> 15:50.360]  and making sure you don't spend a lot of time doing this. And upgrading your server every
[15:50.360 --> 15:56.600]  12 to 18 months really isn't a big deal. Again, trust upstream, DNF system upgrade, release
[15:56.600 --> 16:01.480]  for the next one 20 minutes later, you have your operating system upgraded. It's not a
[16:01.480 --> 16:08.840]  big deal. Another thing, use pre-existing containers wherever possible. You can of
[16:08.840 --> 16:13.160]  course write your own and sometimes you will have to for the demo I'm about to give. I
[16:13.160 --> 16:21.000]  did have to write one. And don't forget that upstream tends to prefer using their containers
[16:21.000 --> 16:27.280]  over a different way of deploying their software. So generally speaking, if you have an issue
[16:27.280 --> 16:31.960]  and you say, okay, I'm running your latest container version, you're actually more likely
[16:31.960 --> 16:39.000]  to get help than if you installed in any other way. Of course, what do we do about backup
[16:39.000 --> 16:44.520]  and disaster recovery? Well, if you follow the recipe that I'm going to talk about, then
[16:44.520 --> 16:49.160]  basically you have two directories to backup on each server. And if something goes wrong,
[16:49.160 --> 16:54.920]  you have two directories to replace back on the server. And basically your stuff is back.
[16:54.920 --> 17:00.080]  I will hear the people managing infrastructures for large corporations saying, but this will
[17:00.080 --> 17:10.600]  take hours. Yes. It also almost never happens. And this way you can be sure that your data
[17:10.600 --> 17:22.280]  is not gone if something goes wrong without breaking the bank. Generally speaking, I've
[17:22.280 --> 17:26.760]  been doing this for quite a while now and I've had one server fail due to a hard disk
[17:26.760 --> 17:36.080]  failure. Of course, the server was just using a rate one mirror. So I just called the people
[17:36.080 --> 17:40.320]  run the data center. They replaced the disk and there was actually not really a problem
[17:40.320 --> 17:52.120]  there. I would like to now introduce megacorp.icu. This is a very big company that has graciously
[17:52.120 --> 18:00.160]  let me demo their environment. Completely non-evil. They let me show you their environment
[18:00.160 --> 18:06.240]  because prehensile tiles, my own company, the CEO, thought it was irresponsible to have
[18:06.240 --> 18:12.120]  the internal systems recorded on there free and open source and developers European meeting
[18:12.120 --> 18:17.000]  thing. I don't know what they're thinking. Megacorp is nine totally real employees. They
[18:17.000 --> 18:26.920]  were absolutely not AI generated. The thing I'm about to show you is a setup that is roughly
[18:26.920 --> 18:34.640]  looks like this. There are three hosts running on this laptop, hopefully. Configured as such.
[18:34.640 --> 18:40.520]  So we have three hosts with an overlay network on WireGuard to make sure that these hosts
[18:40.520 --> 18:48.160]  can talk to each other over local IP addresses. Reason for that being is when you do something
[18:48.160 --> 18:53.720]  like this, you're probably not going to be able to afford or want to pay for dedicated
[18:53.720 --> 18:57.760]  rec space with your servers nicely lined up above each other, connected to each other
[18:57.760 --> 19:05.080]  over local connections. So you need some way for your servers to feel like a LAN. By doing
[19:05.080 --> 19:10.680]  a simple WireGuard mesh, any one server can go down and the other two can still talk to
[19:10.680 --> 19:18.680]  each other, which is a nice feature to have. And now a hopefully non-colossal mistake,
[19:18.680 --> 19:31.400]  I'm going to try to actually show you what this looks like by using a system like this.
[19:31.400 --> 19:41.440]  So first of all, this is the basic admin interface. You might see if you're using something
[19:41.440 --> 19:51.360]  like this. So we have our nine users here in LDAP. And we have a couple of groups here
[19:51.360 --> 19:56.840]  that you can manage. So I've made a human resources team for which Chatwick and Maxwell
[19:56.840 --> 20:04.000]  are our members. I made some shared mailboxes that a human resources team can also look
[20:04.000 --> 20:20.520]  at. So what this looks like here is for instance, let's see, have a new timer tab. This one
[20:20.520 --> 20:28.320]  I think. All right. So for a little explanation, I'm using a feature of Firefox here called
[20:28.320 --> 20:33.640]  container tabs. Basically in the top right here you will see the name of one of the fake
[20:33.640 --> 20:42.480]  users. I mean, totally real users. And basically Firefox will keep all the cookies, etc., separated
[20:42.480 --> 20:48.200]  so that I can actually show you what it means to log in from multiple systems. Just a private
[20:48.200 --> 20:54.000]  tab would only give me two Firefox tab containers because it basically give you an unlimited
[20:54.000 --> 21:00.400]  number of private tabs, essentially. So that's what we're doing here. So the first thing
[21:00.400 --> 21:12.560]  we can do is, oh, this is the wrong one. This is the real one of my real company. I was smart
[21:12.560 --> 21:22.800]  enough to make bookmarks and I didn't use them. So the user name of this person is Cadence.
[21:22.800 --> 21:27.560]  So first of all, this is basically the login screen that every user will see, hopefully
[21:27.560 --> 21:34.000]  only once a day. The way this works is you log into the system, there is a cookie that
[21:34.000 --> 21:39.920]  gets set for key cloak in this case and key cloak then does all the authentication with
[21:39.920 --> 21:45.520]  further back ends. So generally speaking, if everything works properly, your users will
[21:45.520 --> 21:50.920]  only have to log in once a day, also meaning that your password policies and things like
[21:50.920 --> 21:54.440]  that can be a little bit stricter because they really only have to remember one and
[21:54.440 --> 22:03.040]  they really only have to type it in once a day. So, oh yes, this user actually doesn't
[22:03.040 --> 22:09.320]  have access to this. That was part of the demo, but I forgot that in this case. We will
[22:09.320 --> 22:14.720]  get there. Let me show you something that the user doesn't have access to, their email
[22:14.720 --> 22:23.000]  box. So you see that I just switched from the next cloud to the email server and you
[22:23.000 --> 22:29.920]  also noticed, hopefully, that there was not another login prompt. That is, again, because
[22:29.920 --> 22:36.320]  these single sign-on systems, if you deploy them properly are in fact single sign-on.
[22:36.320 --> 22:41.880]  You sign-on once and then it should just keep working. So this is the email box for our
[22:41.880 --> 22:48.960]  user cadence and we can see we have an address book with all of the people, all of her colleagues
[22:48.960 --> 23:01.960]  in it. First and here is Chatwig Parsons. These names are also all AI generated, by the way.
[23:01.960 --> 23:10.800]  So what we can do is we can send an email to Chatwig here. Am I doing the right thing?
[23:10.800 --> 23:28.560]  Send email. You can send a little email to Chatwig here.
[23:28.560 --> 23:37.480]  And now, hopefully, when we switch to the Chatwig, there we go, Chatwig there, have received
[23:37.480 --> 23:46.160]  an email. You see also that the things like, small little things like the fact that all
[23:46.160 --> 23:51.160]  of the users have their own little profile pictures, et cetera, and these are all consistent
[23:51.160 --> 23:58.280]  across all of the applications as well. So if you look at the Chatwigs, Chatwigs does have
[23:58.280 --> 24:12.280]  access to the next cloud. There we go. And you see that this actually shows the same...
[24:12.280 --> 24:21.440]  If you click the same button twice, the same thing happens. This is very surprising. You
[24:21.440 --> 24:27.480]  see here that the user has this... Oh, sorry. You see here that the user actually has the
[24:27.480 --> 24:34.000]  same profile picture as well. These profile pictures all came from Active Directory, thank
[24:34.000 --> 24:49.200]  God, no. Came from OpenELDA as well. So what can you actually do with this? What is the
[24:49.200 --> 24:58.000]  big thing that I kept talking about? For instance, here we have a human resources folder that
[24:58.000 --> 25:04.640]  Chatwig has access to because Chatwig is part of the human resources department. And so
[25:04.640 --> 25:29.920]  there is... Maxwell is also an HR person. So Maxwell and Chatwig... So far, everything's
[25:29.920 --> 25:41.120]  still working. Very good. You see that Maxwell here has access to the same document. And
[25:41.120 --> 25:45.320]  there's not been any sharing here. It's just a matter of being part of the correct group.
[25:45.320 --> 25:58.800]  I will show that in a second. But if you look at the access that... This is all about Kelly.
[25:58.800 --> 26:07.720]  Thank you for getting that I made these nice handy dandy. It's not exactly single sign-on
[26:07.720 --> 26:12.520]  if you're doing a demo with five different users. It is only once per user, not once
[26:12.520 --> 26:22.680]  per demo, I'm afraid. You see here that the user, Elba here, does not have access to the
[26:22.680 --> 26:32.760]  shared directory and cannot see it. And trying to just send a link to this other person will
[26:32.760 --> 26:42.280]  also not work. As you see, you just get a file not found there. Now, what if Elba does
[26:42.280 --> 26:47.920]  become part of the human resources team? Well, at this point, it's just a matter of
[26:47.920 --> 27:07.440]  adding the member here. And then, in a couple of minutes, hopefully, maybe immediately,
[27:07.440 --> 27:19.560]  we'll get back to that. What's the next thing on my list of things to share? I also created
[27:19.560 --> 27:25.520]  this user, Mary J. What you've seen so far is basically what it looks like for people
[27:25.520 --> 27:30.400]  who have been working for a while, who already know the system. What does this look like
[27:30.400 --> 27:39.840]  for a completely new user? Because that's another problem, right? Getting people signed
[27:39.840 --> 27:50.720]  up on board in your organization. Okay, forgetting I made these. So, let's say you tell your
[27:50.720 --> 27:57.040]  new user, okay, the first thing you need to do is just go to the chat system to say hello.
[27:57.040 --> 28:04.160]  So, we have given the user their initial temporary password. I sign in and you see that you get
[28:04.160 --> 28:12.840]  just this one little prompt for people to change the password. And after that, they're
[28:12.840 --> 28:18.240]  just signed up like everything else. So, this is basically the only real onboarding that
[28:18.240 --> 28:22.560]  your users have to do. So, they don't have to create accounts for multiple things. You
[28:22.560 --> 28:28.040]  don't have to create accounts for multiple things. I don't end up having to type a personal
[28:28.040 --> 28:39.920]  Gmail account to some kind of Google Drive, nothing like that. And there we are. The same
[28:39.920 --> 28:52.440]  thing goes for things like the access to, for instance, channels on your instant messaging
[28:52.440 --> 28:59.760]  server. You see here that at Chatwick, being part of the human resources group, has access
[28:59.760 --> 29:08.880]  to this channel HR that is not visible to this user, Maria Johnson. So, Maria Johnson
[29:08.880 --> 29:14.040]  is not part of HR, does not see the group. This is not something that you have to manage
[29:14.040 --> 29:22.320]  yourself either. We also see here that since Alba was recently promoted to be part of the
[29:22.320 --> 29:29.160]  HR group, she is now, she now has access to the HR channel as well. Again, this speaks
[29:29.160 --> 29:34.800]  to this access control that I was talking about previously. You don't have to think
[29:34.800 --> 29:42.400]  about, okay, what things does an HR person have access to? Did I give them access to
[29:42.400 --> 29:46.000]  the right folders? Did I give them access to the right chat, email address, et cetera?
[29:46.000 --> 29:56.600]  It's all just taking care, you only take care of this one time when you set this up, basically.
[29:56.600 --> 30:05.080]  So, there's a couple of other things that people like to use, like, editing documents
[30:05.080 --> 30:24.560]  together. We can do that. If I, probably should have kept more tabs open. It turns out that
[30:24.560 --> 30:28.280]  navigating a computer is much easier when you're writing a talk and you're sitting down
[30:28.280 --> 30:38.880]  instead of facing a room of 700 UV pool. Well, that's not 700 of you here, but you know.
[30:38.880 --> 30:49.800]  So we have two people logged in here, and you'll be able to edit things collaboratively
[30:49.800 --> 30:58.920]  much like Google Docs, et cetera, as well. So you don't really need to lose any features
[30:58.920 --> 31:23.320]  over any of this either. Let's see. We have the chance. Yes. So these are the services
[31:23.320 --> 31:29.200]  that I added to the demo for this demo. If anyone has any questions about what other
[31:29.200 --> 31:40.680]  things you could easily do, we have a question section in a minute. Let me go back here.
[31:40.680 --> 31:44.480]  So I'm assuming that it went super well when I wrote this. I'm going to give myself three
[31:44.480 --> 31:52.920]  and a half out of five stars on that one. So can you do this? I think this little demo
[31:52.920 --> 32:00.680]  shows that for most purposes, what people are used to on a daily basis using their systems
[32:00.680 --> 32:06.040]  collaborating with each other, et cetera, it is, in fact, possible to do it. I think
[32:06.040 --> 32:11.040]  the user interface is far more consistent than if you compare this to a hot pot of different
[32:11.040 --> 32:17.920]  cloud services with different login systems, different access control systems. Again, predictable
[32:17.920 --> 32:21.360]  and controllable cost, you know how much it's going to cost when you start the month
[32:21.360 --> 32:27.160]  compared to how much it's going to cost at the end. I think you end up spending less
[32:27.160 --> 32:32.440]  time managing access control. You just have this one list of groups and members. You look
[32:32.440 --> 32:35.880]  at who is a member of the group, you know what access they have, and you also know that
[32:35.880 --> 32:41.240]  if you take them out of the group, they will cease having that access. That way, you also
[32:41.240 --> 32:51.080]  lose less time on people not being able to access things that they need for their jobs.
[32:51.080 --> 32:59.000]  So as part of writing this talk, I was setting up the megacorp.icu, various containers, et
[32:59.000 --> 33:02.520]  cetera, and taking some of the containers that I was ready running in production, kind
[33:02.520 --> 33:08.040]  of filing off the serial numbers of the specific things that I used them for. And I realized
[33:08.040 --> 33:12.760]  that maybe these could be useful for other people as well. So I created a GitHub project
[33:12.760 --> 33:19.240]  called megacorp.icu that has the containers that were used in this talk in it, as well
[33:19.240 --> 33:27.320]  as some of the tools that I used to manage this. Perhaps if other people are interested
[33:27.320 --> 33:33.480]  in running their own infrastructures in at least somewhat the same way that I'm proposing,
[33:33.480 --> 33:38.920]  perhaps we can do some kind of collaboration with each other and do sort of CS admin support
[33:38.920 --> 33:47.160]  group, I don't know. So questions, I think I'm a little ahead of where I was supposed
[33:47.160 --> 33:53.080]  to be, but maybe there will be a lot of questions. A little plug, because I was just told that
[33:53.080 --> 33:58.120]  you should always be selling. My company, Romatuck, is actively hiring people. So if
[33:58.120 --> 34:02.840]  any of this sounds like it could be you, please contact me.
[34:02.840 --> 34:07.400]  Okay, so we've got one roving microphone for questions, but we're going to go online first,
[34:07.400 --> 34:12.240]  because there's some online questions. Yeah, the chat's blowing up with this question
[34:12.240 --> 34:18.200]  right here. What do you think about so-called totally automatic solutions like Unohost or
[34:18.200 --> 34:22.920]  Sandstorm? Would they also be sufficient for a small business?
[34:22.920 --> 34:30.840]  So I actually started off using Sandstorm, but found that the access control that Sandstorm
[34:30.840 --> 34:42.280]  offers is actually not quite... So with Sandstorm, what usually ends up happening is that you
[34:42.280 --> 34:52.040]  deploy different instances of the same application that different people will have access to.
[34:52.040 --> 34:59.600]  What I found is that moving people between groups didn't work properly for that, specifically
[34:59.600 --> 35:05.000]  if somebody gets kicked out of a container, sharing things between things tended to get
[35:05.000 --> 35:16.360]  a little weird. I would say that if it works for you, use it. It didn't work for me personally.
[35:16.360 --> 35:23.680]  So I have another happy story. I started with a small startup. I was the assistant administrator.
[35:23.680 --> 35:29.880]  I set up. Okay, close up the question, please.
[35:29.880 --> 35:37.240]  So I started to install all the false infrastructure. It was beautiful. Next cloud, we had Aldo
[35:37.240 --> 35:44.120]  and many other things. And then the company got bigger, and then the president of the
[35:44.120 --> 35:52.760]  company said, I don't like how next cloud link calendars to email. And so the next month,
[35:52.760 --> 35:58.480]  we switched to Google Doc completely entirely and that's where all my work of two years
[35:58.480 --> 36:06.080]  and I cried. So how do you do with the users? I mean, you are the boss. I'd love to have
[36:06.080 --> 36:15.320]  you as my boss. But how do you convince users actually to comply?
[36:15.320 --> 36:23.160]  Well again, do you need me to repeat the question? So in my case, none of that really applies
[36:23.160 --> 36:28.240]  because I am the boss of these companies. I'm the CEO of both. So to a certain extent,
[36:28.240 --> 36:36.640]  if you don't like it. But in practice, people tend to do like it. Of course, if you have
[36:36.640 --> 36:41.240]  someone that says, okay, I only know how to use this one thing and I refuse to use anything
[36:41.240 --> 36:49.240]  else, if that person is the CEO of the company, that is a problem. I don't really have a good
[36:49.240 --> 36:55.240]  answer for you other than yet try to convince them that there are some benefits to this.
[36:55.240 --> 37:01.880]  I mean, in the end, it's their money, right? So if they're willing to pay $30, $40 a month
[37:01.880 --> 37:06.960]  per user because they don't like how these things are linked, there is only so much you
[37:06.960 --> 37:10.840]  can do at some point. Okay, we're going to take an online question
[37:10.840 --> 37:13.560]  and then I'm going to go over there for the next question. Keep your hands up if you want
[37:13.560 --> 37:16.720]  to ask a question. I've got a chance to keep an eye on you.
[37:16.720 --> 37:24.640]  Okay, so what do you think of Cloudron? So can you repeat the question, please?
[37:24.640 --> 37:29.160]  What do you think of Cloudron? I'm not familiar with that.
[37:29.160 --> 37:34.920]  Have you heard of Cloudron? Are you aware of co-op cloud? That's another question on
[37:34.920 --> 37:37.400]  the... I am not, no.
[37:37.400 --> 37:48.920]  All right, some good ideas here from the people.
[37:48.920 --> 37:53.160]  What do you use for documentation? Can you repeat the question, please?
[37:53.160 --> 37:59.720]  What do you recommend for documentation, like an alternative for conference or notion?
[37:59.720 --> 38:01.840]  So it's the question, what do you use for video conference?
[38:01.840 --> 38:05.320]  No, no, no, for documentation, internal documentation for the company.
[38:05.320 --> 38:08.680]  Oh, what do you use for internal documentation for the company?
[38:08.680 --> 38:09.680]  Yes. Yes.
[38:09.680 --> 38:15.440]  So in the case of pre-hensile tails, I use X-Wiki, which also integrates beautifully
[38:15.440 --> 38:23.040]  with this whole thing. People get access to subpages based on group memberships, etc.
[38:23.040 --> 38:27.320]  For user documentation, that's not intended to be changed.
[38:27.320 --> 38:33.040]  So I wrote a little manual on how to do certain simple things on the mail server. Those are
[38:33.040 --> 38:41.520]  just files that are in a shared folder on the next cloud that everyone has access to.
[38:41.520 --> 38:45.440]  Thanks for the talk. Very interesting. One question, I guess, all your services are
[38:45.440 --> 38:50.720]  publicly available. So does Keycloak support something like a two-factor authentication?
[38:50.720 --> 38:57.600]  Yes. Keycloak does support two-factor authentication. You can simply add, actually, let's not do
[38:57.600 --> 39:02.560]  a demo for something I haven't looked at. I will not make that mistake. But yeah, you
[39:02.560 --> 39:09.360]  can add an authenticator app to your account on Keycloak. And I do that for myself, because
[39:09.360 --> 39:15.400]  my account tends to have admin privileges, etc., on a lot of stuff. It is possible to
[39:15.400 --> 39:22.240]  also configure Keycloak such to make it mandatory for every user that logs in to set up a two-factor
[39:22.240 --> 39:29.400]  with an authenticator app. But yeah, so that's one thing to keep track of though, because
[39:29.400 --> 39:34.600]  this is something that can, in fact, take you, lose you a lot of time. If you do set
[39:34.600 --> 39:38.800]  it up, make sure you have an MTP client running on all your servers, because that's going
[39:38.800 --> 39:43.280]  to take you a while to figure out. Yes.
[39:43.280 --> 39:48.280]  I have a question. How do you deal with security since you're running NextCloud and Keycloak
[39:48.280 --> 39:56.840]  on premise? You said in some slides before that you update your systems, like, between
[39:56.840 --> 40:01.680]  12 and 18 months. That is not a problem. But then again, security issues, like, rapidly
[40:01.680 --> 40:06.840]  rise up. And especially if you're on the public internet or facing the public internet, you
[40:06.840 --> 40:15.240]  run into, well, huge risks when you are not on the problem at hand.
[40:15.240 --> 40:27.880]  I mean, huge risks, sure, in the sense that if a worm were to be developed that goes through
[40:27.880 --> 40:35.400]  Keycloak directly and it doesn't get patched until it is all wild over the internet, then
[40:35.400 --> 40:44.320]  that might be a problem, yeah. But in the actual, so far, security updates for things
[40:44.320 --> 40:51.360]  like Keycloak, NextCloud, et cetera, they come out of cadence of once every month, month
[40:51.360 --> 40:58.600]  and a half. You basically just tell your podman container stack to pull the new images and
[40:58.600 --> 41:07.000]  you restart them. It's two, three minutes of work, usually. So again, it is a concern,
[41:07.000 --> 41:11.000]  but it's not something that's going to, it's not going to be your job to deal with this.
[41:11.000 --> 41:15.000]  It's two minutes, three minutes to install more security updates most of the time.
[41:15.000 --> 41:26.400]  Okay. So the question is, how do you know that you need to update something? I just
[41:26.400 --> 41:33.080]  run these pools and updates like every two, three weeks because I like you pointed out
[41:33.080 --> 41:37.160]  I don't want it to be my job to figure out all of the security updates that are available
[41:37.160 --> 41:43.520]  for everything. So I just install everything every couple of weeks.
[41:43.520 --> 41:49.400]  Next question is, can you use Purely Foss for the non-engineering aspects of the company?
[41:49.400 --> 41:53.800]  For example, accounting software that is compliant with state requirements for regular digital
[41:53.800 --> 41:59.120]  submission. So the question is, can you use it for things like administrative software
[41:59.120 --> 42:06.080]  and stuff? I frankly don't know because I cheat in that regard is that I have an accountant
[42:06.080 --> 42:11.440]  and every month I send them an email with a pile of PDFs in it and then I get a PDF
[42:11.440 --> 42:16.920]  back that says how much taxes they have to pay or return. So I don't know. I don't have
[42:16.920 --> 42:22.760]  the answer to that question. But hiring an accountant, a good idea if you're ever at
[42:22.760 --> 42:30.440]  a size of one or two people, just get an accountant.
[42:30.440 --> 42:38.480]  Thanks for the presentation. So since the keyword here is to keep things simple, I believe
[42:38.480 --> 42:43.560]  in Key Clock you can have all the users created locally and have them in Key Clock. What's
[42:43.560 --> 42:50.320]  the benefit of having LDAP behind that to keep track of the users and having all the
[42:50.320 --> 42:54.520]  information is why? If you want to keep things simple, why not just create local users? Because
[42:54.520 --> 42:59.080]  then you end up with the same problem that you started with, with different cloud tools.
[42:59.080 --> 43:04.720]  Now you have to manage individual access to different tools yourself again. The fact that
[43:04.720 --> 43:11.080]  there is a group of human resources that easily works across all the systems means that the
[43:11.080 --> 43:16.440]  mail server knows who's a member of human resources, next cloud knows who's a member
[43:16.440 --> 43:26.840]  of human resources, and what else? And RocketChat knows who's a member of human resources. It
[43:26.840 --> 43:34.840]  just lowers the burden to take that one little bit of extra complexity. In return you get
[43:34.840 --> 43:39.720]  back this one single thing you have to administer instead of figuring out how to do that across
[43:39.720 --> 43:45.160]  multiple things. Also from a purely practical point of view, most programs will support
[43:45.160 --> 43:50.840]  LDAP. Fewer and fewer programs now support things like PAM or anything like that. The
[43:50.840 --> 44:01.360]  LDAP kind of is what PAM used to be in that respect for good or bad.
[44:01.360 --> 44:10.120]  You've been talking about using this in small or small age companies. Do you foresee at
[44:10.120 --> 44:17.360]  which point this would not work anymore? In terms of size of the company?
[44:17.360 --> 44:27.440]  I think there's going to be an inflection point specifically when vertical scaling stops
[44:27.440 --> 44:34.560]  to work. If I need more than one piece of hardware to run all of the chat users on,
[44:34.560 --> 44:42.400]  I think at that point it's going to be a problem. If I get so many files that I cannot reasonably
[44:42.400 --> 44:47.560]  store them any longer on a server that you can reasonably rent, I mean right now you
[44:47.560 --> 44:55.880]  can get a rate one NVMe server where it's two times four terabytes of disk space for
[44:55.880 --> 45:01.760]  like a hundred bucks a month. Once things like that stop scaling, I think that is when
[45:01.760 --> 45:05.880]  you might start to have a problem. The way I think about that though is by the time I
[45:05.880 --> 45:10.840]  have that problem, I will also probably have enough people to get a sysadmin to figure
[45:10.840 --> 45:19.520]  that stuff out for me. How often have you had to report or fix bugs
[45:19.520 --> 45:24.360]  in the stack that you're using? How often do you have to fix and report bugs?
[45:24.360 --> 45:32.640]  So that is exactly how often I don't know. I'm not going to lie that it happens with
[45:32.640 --> 45:39.200]  some regularity. I currently have a bug open with NextCloud, for instance, that sometimes
[45:39.200 --> 45:46.120]  the avatar icons disappear. That is annoying. Things like that are annoying. But then again,
[45:46.120 --> 45:53.600]  I also have had bugs open for pieces of software I've paid for that are never fixed. It's
[45:53.600 --> 46:00.360]  not a panacea, I believe is the word you, is how you pronounce that. But it's not something,
[46:00.360 --> 46:06.800]  it's not like the things are constantly breaking and I'm constantly fixing things, absolutely
[46:06.800 --> 46:10.800]  not. A minute ago there was a question up here.
[46:10.800 --> 46:17.760]  Has it gone away? Just in this front block here. No, right, okay, we'll go over here.
[46:17.760 --> 46:24.440]  We'll see if it works. Somebody's getting some stabs.
[46:24.440 --> 46:31.400]  Hi, thanks. That was a really good talk. Like everything that you did say. On the point
[46:31.400 --> 46:35.080]  about accounting, that was one of the things I was hoping you might cover. So I was just
[46:35.080 --> 46:41.000]  going to ask if maybe there's anyone else in the room who does do their own bookkeeping
[46:41.000 --> 46:47.160]  and tax submission and knows free software that can do that in European or particularly
[46:47.160 --> 46:52.120]  UK contexts. So I think the question is, is there anyone
[46:52.120 --> 46:56.680]  in the room who does know how to do open source accounting? Because it's certainly not me.
[46:56.680 --> 47:02.520]  That has a second vote from me as well. Anyone?
[47:02.520 --> 47:30.080]  Hold up, hand up. PRP next, you say? PRP next. It's not low. Every regulation is in it.
[47:30.080 --> 47:34.560]  You have to build it yourself, but ERP next is an open source solution to manage your
[47:34.560 --> 47:39.200]  accounting stuff. Cool, thank you.
[47:39.200 --> 47:49.040]  Did we have more questions? How much time is needed on average per month
[47:49.040 --> 47:56.080]  to set up the infrastructure and maintain it? So setting up the infrastructure, well,
[47:56.080 --> 48:00.640]  I felt like it wasn't too much work to set up an entirely new infrastructure just for
[48:00.640 --> 48:05.720]  this talk. So I mean, it should give you some indication that it's not like a weeks long
[48:05.720 --> 48:09.800]  process. As in how much time does it take me per month
[48:09.800 --> 48:17.080]  to run this? It is a little bit variable. So just installing
[48:17.080 --> 48:27.000]  steady security updates and just keeping those things running maybe. So it's never consecutive,
[48:27.000 --> 48:37.200]  right? I think it's fair to say that I spent about an hour a month maintaining the infrastructure.
[48:37.200 --> 48:43.760]  I don't think I spent a whole lot more than that. Of course, this number can ramp up rather
[48:43.760 --> 48:49.760]  dramatically if you get a hardware failure. Like a broken hard drive in a server can now
[48:49.760 --> 48:55.200]  mean that you have to spend two, three hours talking with your data center people, planning
[48:55.200 --> 49:00.320]  to get the disk replaced, waiting for the disk to be replaced, putting it back in your
[49:00.320 --> 49:07.840]  rate set. So at that point, you might lose a couple more hours. But yeah, it's in the
[49:07.840 --> 49:19.960]  order of hours per month, not days. Hi. Have you tried to do it in high availability?
[49:19.960 --> 49:26.440]  So do you have any problems with like a next layer of the complication? If you have one
[49:26.440 --> 49:34.720]  key clock in machine A, the second key clock on machine data center B, what's your idea
[49:34.720 --> 49:40.400]  here? Because if you use, I don't know, Google, it's just one Gmail comment. Yeah, you are
[49:40.400 --> 49:45.440]  fine. Yeah, so the question is what do you do about redundancy? So that's actually one
[49:45.440 --> 49:49.880]  of those things where it's very easy to fall into a trap and which is kind of what this
[49:49.880 --> 49:55.200]  talk was hoped to be about. Is it you don't really need that most of the time? Make sure
[49:55.200 --> 50:03.000]  that your data is safe. But if you have a company of 10, 15, 20 people, if people can't
[50:03.000 --> 50:07.480]  log in in the middle of the night, it means that you're also sleeping and all your employees
[50:07.480 --> 50:16.160]  are also sleeping. So it's not, this is not something that worries me at all. It's not
[50:16.160 --> 50:19.800]  to say that, again, not to say that you should never worry about it, not saying that anyone
[50:19.800 --> 50:25.840]  who does worry about it is wrong. But just in the type of deployment that I'm talking
[50:25.840 --> 50:30.880]  about, a couple of hours downtime is not the end of the world. And we've seen it's not
[50:30.880 --> 50:34.680]  the end of the world because Azure just went down for like seven hours and, you know, we're
[50:34.680 --> 50:41.720]  all still here. Okay. Thank you all very much. Thank you, HP, for your talk. That's a great
[50:41.720 --> 51:02.280]  answer to your question. Thank you for coming.