 OK, next talk. We are now going to learn how to bootstrap a brand new HackSpace. Hello. Hi, everyone. Thank you. Right. So welcome to one of the last talks here. Sad. I'm Malias Srebrenic. I work as an embedded developer. And I'm one of the founders of Meetelab, which is my Hackerspace in Trieste, Italy. And I'm one of the Inok guys, so I do the network stuff. Meetelab is a medium-sized, I would say, Hackerspace in Trieste. It was founded in 2016. We have 17 members of which 20 members show up regularly. What I'm going to try to explain to you is I'm going to start with a very brief introduction to Hackerspaces. I'm guessing everyone here knows what a Hackerspace is, right? Yeah. And, well, mainly, this talk is about not trying to reinvent the wheel. So reuse standard software that is already there with slight modifications in order to get everything to talk to everything and integrate stuff without much effort. And I'm going to explain basically what we did at Meetelab, so which software we choose and how are we dealing with communicating effectively and collaborating. I'm not going to talk about design patterns. If you want to see a talk about design patterns, well, there's another talk that I did besides Ljubljana. You should check out that. Or there is the talk of introducing Hackerspaces and patterns. And that can be found on the website, hackerspaces.org. I'm not going to, this is not a general guidebook on how to start a Hackerspace, because that would take certainly more than 30 minutes. And it's not a free IPA or SAM tutorial, although I will explain a little bit what SAM is. So what's a Hackerspace? This is a highly discussed topic, and everyone is very sensitive about this. A definition that I found out on IRC was, well, if your kid is into sports, you bring into a soccer club or baseball club or whatever. If you do like tech, then you're going to bring in to a Hackerspace. Another definition that I like very much is that a Hackerspace is the sum of its members. And why is that? A Hackerspace is usually a physical place where people meet. And these people have interests, so they have stuff they like to do. And those interests usually defines what kind of projects are done in that space. So people are going to be interested in electronics. You're going to do electronic stuff. And that actually defines what kind of equipment is available or is going to be bought by the community. So Hackerspace is a group of people that is very important. Another thing that is very important is how do people collaborate in a group? So in order to collaborate efficiently inside a group of people, especially if they're not already present in the same space or some are remote or some are just not present that day, you need communication. People need to talk to each other as simply as possible. And right in this day and age of Slack and IAM and stuff like that, it seems obvious, but it's really not that obvious how to communicate effectively. There needs to be some coordination. So people need to know what needs to be done, who took the charge of doing it, and usually when needs to be done, what's the deadline. And afterwards, and this is also very important, and as programmers who are usually bad at this, documentation, what was done, how was done, and how can people recreate it? So what we found out is in order to communicate, there really needs to be three levels of communication. There needs to be a day-to-day communication. I know where you can post the latest memes. You can ask if the space is open, if anyone is there, what are they doing, and things that need or usually warrant a quick response. There needs to be a place where people can communicate important stuff like announcements, new projects, general discussion that has to have an attention span, which is longer than the couple of pages that one usually reads in an IAM program. Finally, there needs to be a reference. So things get discussed, there is a decision, and then this decision has to be recorded. And this thing has to be really easily accessible, really a couple of links away. You don't have to wade through screens and screens of forum discussion in order to reach the final conclusion. And this is the three levels, basically, that this is the community pattern. If you see the community pattern on haggarspaces.org, this is basically it. Right, so you decide a couple of things. Now the couple of things needs to get done, actually. The first and simplest approximation of getting it done is using a to-do list. This is easy, just need to write down in the etherpad Google Sheet, whatever. You write down what needs to be done, who needs to do it, and by when, if that's applicable. And this is it. The problem is a Google Sheet or an etherpad doesn't really scale that well. If you have 40 people collaborating on the same thing, you're going to have problems with that. So what do you need is basically a project management software. This is kind of heavy because usually these things are really difficult to use. So really it has to have low friction, has to be, of course, multi-user because multiple people are going to use it. And it has to have multi-project capabilities because there is some software like RedMind and stuff like that that usually has only one project. And you don't really want to deploy another instance for everything that you want to do. Right, so we have a discussion forum. And we have a Wiki or some way to store documentation. And we have something to collaborate with. And this is already three accounts. So this quickly devolves into a madness where the poor IT volunteers need to reset passwords daily and generally deal with users. This is another thing that doesn't scale really well. So what you're really going to need is some kind of central authentication system. This has to be simple to use because really people in hackerspaces, not everyone is tech aware. You're going to have artists, you're going to have people that really don't know what a GPG key is. So this thing has to be easy to use. And it has to be relatively simple to deploy. Because again, IT people are volunteers and are going to do this in their free time. If people have to work on it for months and months, in order to get it done, it just won't get done. Right, so how did we solve this? We choose a couple of constraints. We set a couple of constraints at Meetelab when we started looking for software that could do all these things for us. This was a year and a half ago now. It has to be open source, of course. It has to be self-hosted because we wanted to not get attached to any kind of software as a service or external service. We want to be in charge of our own down times. And of course, it has to be easy to use. And what we finally settled on choosing is this. So we have, for the three layers of communication, we have Telegram and RSC for day-to-day communication. We have discourse for important stuff. We have the wiki for reference. For coordination, we chose Camboard, which we're going to see a couple of slides later. For documentation, we chose both GitLab and Doc wiki. And for authentication, we actually started out with LDAP and we then moved to SAML, which is way, way better. Right, instant messaging. I think everyone knows Telegram. It's pretty popular. Well, the protocol is open source. The back-end is not, but you know, got to deal with some. We could have deployed, for example, matermostism. It's another thing. But the thing is, you need to start using something that people actually use. What we needed, though, was bot support. And, of course, we also chose RSC, mainly because there was some people who refused to come on Telegram. But also because RSC is very direct. You don't need an account. You don't need a phone number. You don't need to set a password. It can be linked, too. So you just set, use the free-node web chat. You just basically have a link that auto joins you in a channel, more or less. You have to choose a nickname, if I recall correctly. But basically, this is from our website. You just click a link, and you can chat with us. It also has bots. Why is this important? Because we actually found a bot that can synchronize a conversation, both via Telegram and IRC. So basically, this grabs a message from Telegram, puts it on IRC, and vise versa. It's a bot based on Liminoria, which is itself a fork of Supibot, which is an IRC bot. And it has a plug-in, which is called Supibot Telegram Bridge, that can connect both services together. We made some pull requests, so now it supports multiple channels, multiple groups. And this is how we gave back to the community. What do we use it for? We use it for HackerSpace status. So we have a command, which is unfortunately right now manual, so people can interrogate if the space is open or not. It has a command to set the keys, so people know who has the keys and who to pester if the space is not open yet at the set hour. In the future, we really want to add MQTT support in order to make the open-close status automatic to interrogate some parameters like temperature in the server room or stuff like that. Communication, it's a discourse instance. It's pretty powerful, although it's Ruby on Rails, which I don't personally like. And the official installation is only via Docker, which is another thing that I don't personally like. But the nice thing is it has a mailing list mode. So the debate is the old school people prefer email and asynchronous communication in this way. So this finally doesn't give them the excuse of, I want to use a forum because that's too new for me and I prefer mailing lists. If you do like mailing lists, you just click on the button and every post is going to come to your inbox. So this is a nice way to integrate both young people and the old school people. What do we put there? We put new projects. We put people who look for help. That's because usually if you just write in the telegram group, you're not going to get that much responses. And once it gets past the first screen, nobody's going to read it anymore. We have events and workshop announcements. That is also a separate category. And we have general discussion between members so anything goes. And this is basically what we need our forum for. Then we have Kanboard, which is mainly used by the board. It is multi-user, has groups and permission. It will handle multiple projects. It is a little bit hard to get because that's project management software. But it is pretty simple. So if you see these are the columns, ready, working progress done, you just click on the plus and you add a task. So this is pretty low friction. Moreover, it has GitLab integration. So you can link a task here to an issue on GitLab. And that is also convenient. Speaking about GitLab, you probably already know what it is. It uses Ruby on Rails again. We don't use it only for code or for our projects. We also use it for minutes for meetings. This is pretty convenient since every new meeting has a pull request and then everyone or merge request. And then everyone can comment on that merge request and request changes and add stuff. And then it gets merged. Of course, we use GPT signatures since that is actually important since the meetings are official. We use it for harder projects. So all our key card boards get uploaded there. We have a special category for our library and our templates. And we also use it for server configuration. So that is also something that is auto-documenting in kind of sense. So the configuration is there if you need to replicate it, if the virtual machine gets broken or whatever, just clone the repo and reinstall. Last but not least, it's our wiki. It's based on doc wiki, which is a normal run of the mill flat file wiki. The good thing is it has a lot of plugins. So you can customize it pretty much however you want. Here we do put our events, our projects. So project documentation goes here. Workshops, so a detailed description of workshops goes here. The infrastructure documentation, so how we did everything that is running on our servers goes there. And also the roles. Roles are kind of special for a middle app. We have a couple of roles with a backup. So for example, the internal authentication guy, which is me, has a backup, the external infrastructure guy. External infrastructure guy, then we have a role for media managing. We have a role for event planning. And every role is documented and usually has an email address associated to it. And this is our wiki. Now for central authentication, the first version we did was used LDAP. This is not ideal. Required a couple of custom Python scripts to add members and to synchronize members with our CRM. And basically was not really that secure. So we looked around and we finally found another software, which is Way Way Way Better, which is called Free IPA, and can do all of these things much more. So Free IPA is a software that will authenticate your users, will enable you to set policies for which users accesses which machine or service. And it will have a log for security purposes. So this is the base. And it is really not a monolithic software. It's composed of little small pieces, which is an LDAP server, Kerberos, DNS, and it has a PKI. So all our internal certificates are issued using this system. Finally, I think it's the only software, LDAP-based software, that is not Microsoft, I guess, because I didn't check that. That has a nice user interface, and by nice, I mean at least usable. It has a pretty powerful command line interface. You can access all the APIs. Actually, this is one of the instances where the command line interface is actually more powerful than the web UI. It's written in Python, so it's something that we already know. And it's pretty extensible. You can add your own LDAP object classes if you want. You can manage them in the UI. And so it's pretty customizable like this. What can actually be done with free IPA? Well, it's an authentication system. So basically, your imagination is the limit. What do we use it for? We use it for Radius, WPA Enterprise. So the same set of username password that can authenticate you to our external services, can authenticate you to our Wi-Fi. We use it for Netbox, which is another good piece of software for documenting your IP addresses and racks and whatnot. It's used for authenticating the users to a set of common computers that we have that are for free use for everyone. It is used for our external VPN authentication and via Kerberos to outamount users' home directories so they can work on a file, then move to another common computer, and the file is already going to be there. And of course, it integrates with epsilon, which is another piece of software that we're going to see in a couple of slides. And that powers our SAML access to all our external services. In the future, what we like to add is an integration with our physical access system that we're currently building. So there's going to be that also. Right, so give me a shout if anyone has heard about SAML. Right, a couple of hands. Right, it's initialism stands for Security Assertion Markup Language. It can be used for Singleson. Well, it is used for Singleson on. And it's usually based around one centralized entity for authentication and authorization, which is called identity provider, and multiple services that authenticate to it, which are called service providers. And usually the sequence is, well, a user agent and the user in this case requests a resource from the service provider. The service provider redirects him to the identity provider where the user can actually log in with his credentials. And in the response, there's going to be a SAML response packet. And this is actually what gets forward to, well, signed and forward to the service provider. And the service provider then can use these to authenticate and extract information of the user in order to authenticate him in the system. And this is basically what epsilon does. It's a small project written in Python. It uses SSSD, which is the demo that extracts information from free IPA. It supports double authentication so you can either authenticate via password form, or you can use Kerberos. And it works pretty much like that. So the users authenticate to the IDM via a login plugin. This is the password form or Kerberos method. But this is extensible, so you can actually add your own if you want. Then you have the information plugin, which decides which information is going to pass to the service provider. And finally, you have the authorization plugin, which actually checks if the user is authorized to access that resource or not. Right, how does this integrate inside our external services? For this course, there's an official plugin, which is called discourse SAML. This works, the login works, and groups also work. So we have a couple of groups. For example, there's the members group, which all members are a part of. And that gives access, for example, on discourse to the members-only discussion area. So that works automatically. You can find it on GitHub, of course. For COMBoard, it doesn't work like I wanted to. So login works, groups don't really, because they do some assumption. Well, the plugin was made from the one that does LDAP authentication and that relies on some mechanisms that are not available with SAML. So that's not ideal, but we're working on it. We actually already submitted some pull requests for that, and that's going to be fixed soon, hopefully. For GitLab, the support is integrated inside, baked right in the Omnibus package. Login works. Group sync is currently a work in progress on GitLab side. So that is not working yet. That requires manual intervention. And lastly, for Doc Wiki, there is a plugin that does everything. It was the first that actually worked out of the box. Right, so this is how everything goes together. The last thing is, of course, the users. For a while, we searched the whole internet for a self-service user panel. And finally, we found Mocha, which is done by a university. It supports first account activation. So with a simple command, I can send an automatically generated email to a user saying, hey, welcome to MeetLab. Here is the link to set your password and then log into these services to enable your account. Users can easily add one-time password tokens. So that is also pretty simple to use. They can upload their SSH keys. Of course, the service itself has customizable templates. So you can style it however you want. It also has PGP MIME signed emails, if you want. And it actually was installed and tested and actually works. Well, we sent some pull requests. This is written in Go, which was a new language to learn and submit another pull request to. But we managed to do that. And this is basically everything that we need. So we were pretty happy about that. How did this actually run on? We have a dedicated server for Dockwiki. Sorry, we have a dedicated server for GitLab and discourse, which is the biggest server that we have since Ruby on Rails and Postgres usually eat up a lot of RAM. And we have two VPS, one is for self-service and one is our free IPA outside replica. For internal stuff, we have a bunch of hardware that runs a couple of virtual machines with free IPA and NAS storage for the home directories. Since we have a little time, I wanted to talk about SpaceNet. Has anyone here heard about SpaceNet? Arms up, yay, hooray. Right, SpaceNet is actually also active here at EMF. It's a federated network, something like Adrom, if you heard about it. Multiple hackerspaces can participate and it gives you a login with your credentials on every hackerspace that actually participates to that. And also events like this one or CCC or CCCamp or SHA that was also covered by SpaceNet. Of course, it's reasonably secure because it uses tunnel TLS and it is privacy-conscious because you use an anonymous identity to do the first login to your server. So your username is actually not used outside the secure tunnel with your server. Moreover, there's also SpaceSAML, which is federated SAML login. This is kind of a work in progress. I've talked to Wilco about this. So it's already deployed at a couple of hackerspaces. But what needs to be done is they need to set up some kind of automated system to make joining other domains more easy. And another thing about membership management, what we use is Triton. This is a Python-based CRM. It's pretty easily extendable. It is a little bit complicated to get into because you have to know the basic accounting keywords in order to use it. But this is what we use to have a database of members, which is required by law in Italy. We set up fees, recurrent fees, and manage all the finances out of space. It's nice because it has an app so you can actually embed it in another website. And this is what we plan to do. So what we are planning to do is some kind of sales service management for the members. So each aspiring member can actually request a membership or terminate it if it doesn't want to be a part of middle of anymore. And another thing that we want to do is integrate NFC. And that is it. Thank you. So since they're probably not, do we have some time for questions or? Yep, yep, we do. Awesome. Thank you. If there are any. How long have you been running a hackerspace? How long I've been running a hackerspace? Well, since it's inception, I think. So three years. Another question in the back. Hi, do you have any solution for inventory and asset management, physical assets? Yeah, actually, I do. Do you mean servers and stuff or actually boxes and tools and stuff like that? All right. We are currently working on it. Yeah, this is another thing. I've actually, I haven't found anything about that is reasonably standard and not really integrated in other stuff that other hackerspaces have. I haven't found anything yet. So what we wanted to do is start building something that is abstract enough in order to get it integrated easily in other people's stuff. So sorry. Let me think about it. It actually is, I think. It's on our Git, which is git.metallab.org. Oh, the question for the recording, the last question was, is it public yet? And it is. Cool. Thank you. Thank you very much. Thank you very much. If you want to discuss more about this, you can find me in the West London Hackers Village. Or we could meet up at this exit and probably go to the youth workshop, which is, I think, it's unoccupied, unoccupied. I really want to discuss a little bit about this. Thank you. Thank you.