 All right, so we'll be talking about the replacement to FAST that we've been working on since January, well, actually earlier than that. And yes, that's going to be in production, hopefully by the end of the year. Well, certainly by the end of the year, hopefully by the end of October, for example, so soon. Here is a bit about us, so I'm going to be introducing myself because why not. I've been a federal contributor since basically since it's called federal. And, hey, Stephen, can you talk now? Can you hear me? Oh, that's fantastic. You're only one Stephen. Okay, perfect. I was just I was just arriving on that slide, which is pretty much the first one. So do you want to pick it up? Sure. Yeah, we can use yourselves already. I was just saying a couple was by myself, but it's all on the screen. So feel free to unshare the screen if I managed to do that. Yep. Yes. But I can actually finish that. Yeah, I've been working on the infrastructure team since 2012. And, and I've been a decade on the on the replacement project. So, um, yeah, people got, got to ask me questions and I got to tell them weird answers. And that was fun. And that's my question. I'm part of the free IPA team started right at like a bit more than five years ago. And I was the person who actually is on between the IPA team and CPE team and help the CPE team to develop the plugins and similar technical issues and recommendations. Hey, I'm Steven, the one having AV problems. I joined the CPE team at Red Hat about a year ago. I was at Red Hat for about two years before that I came in with little to minimum Python experience and node in JavaScript was my background, but like I said, don't hold that against me. Yeah. Yeah. So we're going to talk about the fast replacement. And I suppose good way to start off is why, why was it actually being replaced in the first place? And so there's a number of reasons. Some of the smaller ones are based on the turbogears framework that's lost quite a bit of traction and doesn't have a huge community. A lot of the code bases, Python 2 only and a lot of new stuff that we would have liked to use was obviously Python 3. So it didn't make sense to stay Python 2. One of the bigger reasons was that fast only was supported on rail six, which was released 10 years ago and actually goes end of life this November, I believe. So yeah, obviously it would be nice to have a fully supported version going forward and get patches and things like that in a timely manner. Also, it's quite a large application fast and makes it difficult to work on, makes the maintenance hard. And it just in general complicates the workflow. So it doesn't also have a huge, it's not kept up to date at the moment because of some of the previous reasons I just mentioned as well. So all of those kind of combined into let's replace it. So just before I joined this team, there was a small team put together to investigate what the options were. They compared a lot of different solutions, some from AWS, I believe and things like that. So FreeIPA was the winner. And that's where Christian came in. I won't go into the pros bush. Okay, so last year we were contacted by members of the CBE team and they were asking FreeIPA would be a potential solution. So the old fast system already uses FreeIPA and the background for some things. And a little longer debate and me and other corpora then also pushed from our side and convinced our own management chain. It would be a good idea to support fast and FreeIPA at the new solution for fast. For one, it's open source. So the other solution were commercial solutions. We know how to extend and improve FreeIPA and for us as engineers from the IPA side is also a great way to have a good showcase for customers and other communities. And also to see how FreeIPA works like in the real field. So engineers, we usually don't get to see how customers use FreeIPA. And we know that there are pretty big installations with over 100,000 users, but we don't get to see them, don't get to interact with them directly. One of the cons that we saw is that self hosting is an issue. Getting that offloaded to commercial solution will probably get some resources off but rather at least already familiar with hosting that because rather internally also is moving for FreeIPA and long term maintenance costs. So it's hard to see paying a commercial distribution commercial system for that but pay off at the end or not. But at least that way we have that all in house developed. So thank you. So yeah, obviously this move is going to affect a lot of different people. Three main groups really, the actual end users. So anybody who uses the fast system at the moment is obviously going to have a new UI to kind of feel their way around and figure out how things work. We hope that it feels natural and homely. Our UI expert has put a lot of effort into that so let us know. Yeah, some other things like group membership requests are manual for the moment. So yeah, it's kind of similar to how it works the moment anyway. Another thing is, and I'll talk about the migration in a minute but once we do migrate just check your name, check that your name works because names were hired. So yeah, we have to work around that. Another group that it's going to affect is application developers. So gone are the days of the admin user and password. It's now key tabs in Kerberos. Your application should have some key tab and that's how it's going to communicate with the back end. It's a REST API that we've also worked on and Aurelian is going to talk about that REST API in a further slide. I suppose the next group it's going to affect is system admins. They're probably going to reap the most benefits. They're going to have a lot easier management of users and groups thanks to free IPA specifically and also just because of free IPA they're going to have a much more fine green control over what they can do. They're going to be able to do a lot more as well as be able to do it in a finer green control way. And they also everybody loves scripting so they're going to have access to a better CLI and a better CLI tool and a much improved API as well, a much more extensive API. So what does the roadmap for the complete AAA look like? So there's two things that we're hoping to have complete by August 18th, which is just a little under two weeks away. And that's that the solution is deployed to staging and the first pass at user data migration. So there was a question in the chat about data migration. So yes, that is part of this. And what we hope to do is have the first migration run by the 18th or maybe begin at the 18th. Probably begin at the 18th, but also to continue until basically that until fast goes read only. So it'll be run on a maybe on a cron job or every X number of days. And once that happens, then we love community interaction. So get involved, help us test, there'll be email on emails on all the lists. And we're going to have two testing phases. So testing phase and then patch fixes and then another testing phase and then patch fix again. And that'll take us right up until October 20th. And again, once those are complete, you can also get involved and have us fix whatever has been found. That'd be, that'd be great. Once that's done, then we're going to deploy to production by November 3rd. Hopefully it's at this point then as well fast is going to be made read only. And that's just to help us kind of reduce any rights after the fact when we've already done the migration things like that. We'd be in production and fast would be read only. And it's also as well, because there's a lot of applications using fast and we don't want to just break those instantly. They're going to have a window to migrate, which I'll also talk about. So then November 30th fast just gets turned off unplugged. So some of the design goals. One of them was obviously to keep the workload light on admins and stuff. So a lot of it is to be self-service. So users can register, edit their own information, change passwords, OTP tokens, things like that. And whatever happened to go through a ticket system they can do it themselves. We did keep some operations on demand. So that's manual process. And that's kind of to keep if group creation was free for all it would be. There'll be as many groups as there are people and that's just not helpful to anybody. Yeah, and another design goal was again to come back to the admins to allow them to do a lot more, a lot easier. So the web UI to free IP gives us is pretty powerful. And also we have bread hats backing, which is great from even just a training point of view. There's loads of training for free IP, which is brilliant for admins. And yet the last design goals for devs that if they don't have to work on the IDM stuff, then they can focus on other things. Because IDM, I can tell you from my limited experience with LDAP, IDM is difficult. So as Christian can attest, not for Christian, for everybody else LDAP is very difficult. It's like a completely different language. It's different, not difficult, but yeah. I'll explain a bit later about LDAP in my slides. Cool. So, yeah, obviously we hit some technical challenges, most of which we first saw before we started. The first one I was involved with was the actual data migration from FAS to free IPA. I think there's, last time I checked it was 65,000, 70,000 FAS accounts. So we had to come up with a way to actually migrate those along with the, I think two or 3000 groups that exist in FAS and do it safely. Because another issue was that it's this solution is going to host sent us information as well. So it's to make that, make those schemas play together safely. And then we also had some, like, we wanted to make sure that once one groups schemas didn't upset another groups, like we wanted to make sure that if open series, they wanted to add something that they could and it wouldn't, nothing would conflict. And then teaming stuff as well. So to make it so that all three can be teamed separately if they like it, which we've done. Then, like I said, sent us, we have, we're going to have in sent us people who have also have accounts in FAS, even though sent us users FAS, it's a different FAS instance. So there's going to be duplicates like I have an account on both. So when my account is migrated, we need to make sure that that happens safely. Yeah. And then there are some incompatible properties between FAS and free IPA, like I previously mentioned the names. So FAS allows people to, I think I have written down those three main issues where you might either have one name, no name on FAS. There was two accounts that had just no names at all. Or you could have greater than two names. So I think the highest I saw was eight. Somebody had eight names or nine names. So we need to take that into account because free IPA expects a first name and a last name only. And then, yeah, there was also, we put together a list of applications that currently use FAS. And that was, I can attest for somebody who's new to the community that was a long list of applications to try and get my head around. First of all, to actually list and then secondly, to figure out what each was doing, how it was doing it, and what needed to happen for it to migrate to the new API. Yeah, and I think that was, yeah, we just wanted to make sure nothing broke there. So that was definitely a technical challenge. So I'm going to pass over to Aurelian. I'll try to share my screen. Worked a couple of minutes before, so of course it's going to work. All right, so architecture. So these are the applications that are composing the new, the new system. We've talked about free IPA a bit and we're going to talk more about it in the next minutes. It's basically our data store. That's where all the data is located and it gives us also access to these data in various protocols. We have an extension to an extension to free IPA called free IPFS. It's basically a plugin that gives us specific data that we need for Federa, but it's not needed anywhere else. So there's that. You already know it because you've been using it for a while already. It has, it's the login frame that you're using currently to access web applications. Nuggin is a new app. It's going to be the self service user portal. So that's where users are going to log in, set their settings, change their password, join our view groups and request to join them, that kind of thing. So it's all for users. FastGestion, on the other hand, is a REST JSON API, so it's only for applications. Of course it can be your applications because we know you write stuff. And since we have a separate backend in free IPA, we can have applications that are dedicated to users on one side and applications on the other side. FastGestion Client is just a client for FastGestion that makes it a bit easier to use. REST JSON is already pretty easy to use, but we have something even nicer. And Fast2IPA is a migration script. So this is how it's all connected. You start with a nice user that is very happy on the left of the hand. And the user can first, by following the, I'm going to follow the first, you see my, yeah, you see my mouse here. Okay, so it can access Nuggin, the user interface that is going to contact free IPA via the Python API that we're using in Nuggin. And the Python API and all that are connected together in free IPA. We have our plugin here. And applications may be using the FastGestion Client. They can also access fast directly because FastGestion Client is Python, but you may want to access fast from anything. And so they may want to access FastGestion over HTTP, so it's totally fine. And FastGestion is also using the Python API, but it's also calling LDAP directly. You think the Python API for just one small thing that is kind of hard to do in LDAP, but you don't really need to know that. FastGestion has a CLI that is currently only used to generate certificates. And that's mostly for the CentOS users. CentOS users use Koji with client certificates as we used to do a few years ago before we moved to Kerbros. So they still need that. And that is going to be available via the CLI. Nuggin and FastGestion are going to run in OpenShift. And yeah, free IPA doesn't really run in OpenShift. And also you would have some kind of chicken and program with who is going to answer the queries for access in OpenShift. Yeah, we don't do that. It's going to have its own VM. So FastGestion, Nuggin doesn't really need much explanation because it's really made for users and you should be able to use it without much of an explanation or a manual. And if you can't manage to use it with an explanation, then it's a documentation bug and we should fix it. Or a UI bug. FastGestion is a REST API. That's how you get data from free IPA in your applications. You are authenticated via Kerbros. So if you're a user and you want to make an API request, you can just key in it. And you'll have the ticket that is going to be used to communicate with FastGestion. But if you're an application, you use key tabs. I don't know if you're familiar with that. But if not, we have documentation for that also. You'll get JSON responses. You have a few endpoints right now, basically getting a user, getting a list of users, getting a group, getting a list of groups, searching users and getting your certificate signed. It has pagination, which is something that was really lacking in FastGestion. So there's a lot of applications that were querying FastGestion by querying all users starting with A, then all users starting with B, etc. Because it didn't have any pagination. That's fixed. And it also follows the open API spec and has this swagger UI, you know, this nice JavaScript UI that you can explore, that lets you explore the API. I will send you the link to the FastGestion docs. There will be links at the end if you need that. The client is just an easier way to query FastGestion from Python. It's Python. It will check that you are authenticated with Kerbros properly. It will code, you will just be able to call methods instead of making HTTP requests and you'll get dictionaries and lists directly. You can, you'll have pagination support, like you'll have a nice object that you can query for the page number, the total number of pages, what the next page number is, get directly the next page, etc. And you will have a convenience method to get all the users in one call as most FastApplication used to do before. There are better ways to do that now, but if you don't want to make the loop yourself, there's something that does it for you. It also has a CLI that will let you generate certificate signing requests and get them signed by the free APA CA. And that's all. And I'm going to hand over the floor to Christian. Okay, so I'm going to transfer to me. Hi, so let's get started explaining to you what actually free IPA is. So now it's very not a beer, but I like that beer. So free IPA is an open source identity management solution. That means it manages some kinds of identity. So that's users, groups, services, machines, permissions. Users, as already mentioned, all up as a back end. We have included public key infrastructure. So we see I to create certificates for services, hosts and users. Internally, we lie heavily on Kerberos, although most users will not see much of Kerberos. We have OTP support that's for two factor authentication. Not only no support for U2F, but that's going to be added in the distance future. We have a easy to use a web user interface that's heavily JavaScript driven with a command line tool written in Python. Most of the things for the back ends are either using JSON RPC or LDAP queries. As we have shown, it's very extensible. So you can add your own LAP schema extension. You can feed in all up things. You can extend the API with Python and extend the web interface with JavaScript. And if you want to play around with the UI, there's a demo site IPA.demo1.freep.org, including if you follow the pop up login credentials so you can play around. Please don't change the admin password. There are lots of online training courses available on the internet for FreePay 2. So actually, FreePay is not just one project. It's standing on the shoulder of lots of giants. So we have the LAP server, we have Apache, we have Sambar, we have DocType CCA, SSSD, and three hounds on top right that's Kerberos. Of course, we're running on Fedora. Although we have all the support for Forel, for Debian, and just a couple of months ago for SUSE. The core components of FreeIPA, again, the most important one, the KDC, that's the Kerberos Key Distribution Center, DocType, that's the CA that manages certificates, the Threat9DS LDAP server. We also, which we don't use in files, we have bind support, so you have integrated DNS solution, including DNSSEC. I don't think we use that. What we're also not going to use in files at the moment is Sambar support for Active Directory, so you can do something like a cross-forest trust and get Active Directory users into FreeIPA. Some of the help up components are SSSD, which I will explain in a minute, KDC proxy, and certmonger. They run both SSSD and certmonger run also on clients. That makes actually the life of any administrator very easy, because all the hard things like getting users created on different machines is now handled by FreeIPA and SSSD and certmonger. When you create a POSIX user in FreeIPA and a POSIX group, then you will actually see them as standard groups in your Linux machines. If you upload your SSH public keys to users, then they will magically appear when you log in, so you can just use SSH keys for logging in or you can use your Kervos credentials to log into hosts using SSH. There's also a rich host-based access control, so you can control which member of the group is allowed to access which kind of services on hosts. It's very, very fine-grained, including defining groups of hosts where you can define and access different services. I have two-factor authentication, and for those people who are worried about the Kervos and how to configure and set up Kervos on your machines, the good news is if you have default configuration and allow DNS auto-configuration, then you get zero-config Kervos. You just do something like username and capital letters fedoraproject.org with Kinnit, and Kinnit will then ask you for your credentials. You're good, so that works out of the box. So this integration with SSD and CertMonger remain the life of admins easier, and they plug it into sex like NSS and PAM and Suda and SSH. One of the core components which makes FreeAPA for some people a bit awkward to use is LDAP. So this slide is usually started by one of our core workers, and he put in not regular SQL database, and I kept that because that basically sums up LDAP a lot. So if you're coming from SQL, then LDAP is very awkward to you, but it's not that complicated. It's more like a practical address book database or a fancy schema-driven key value store. So on the right side you see like an LDAP tree. It's really a tree form. And the nice thing about it is it's a pretty old protocol, and it's heavily standardized. So it's not like my SQL or Postgres, where you have different drivers, different binary protocols, or each application has its own database tables. The schema and the protocols are all standardized, and that works mostly. And LDAP is also not very well optimized for writing. It's more done for heavy reading and replication of data across multiple ADAP servers. So we do lots of writing with LDAP. You're probably doing it wrong. And it's extensible, so you can both extend the schema and even the protocol with additional features. So we have one extension for IPA, for example, where you can send a server control and telling you when you log in that you require that the user also has during log-in supply a two-factor authentication token. And the LDAPs will just refuse to let people in without two-factor authentication. And we do a lot of access controlling and permission checks on the server side, which makes that rather special, because I'm going to explain that on the slide after that slide. So the LDAP schema is like the table layout view to compare that to SQL. So in order we don't have tables and rows and columns, we have entries. And entries have a distinguished name. They have an object class, or usually multiple object classes, and they have attributes. And object class is just an attribute, but they're rather a special one. The end, the distinguished name is kind of a unique identifier and also a path that shows where the object is located in the tree. So here's an example for a user in my test instance. So it's starting from the right side to a DCFAST DC example, the root database. And then you have an account subtree with a user subtree that has a user FAST user one. The object class of an entry lists both the mandatory and the optional attributes. And in most cases, you can add additional auxiliary object classes to an existing entry. So you can just extend that with object-oriented. You can even subclass in object class and create an extended subclass of an object class. All of this user attributes, so these are the attributes that an application is able to set and modify. It also has something called operational and auto-generated attributes. So these are internal attributes or attributes generated by the internal plugins. And attributes are either single or multi-valued. In most cases, attributes are multi-valued. So you can have multiple names, multiple root memberships. And they're also strictly typed, strongly typed. So you have different kind of text attributes, both ESCII and UTF-8 like text. You have numbers, you have dates, you have binaries, billions, and a special one, a special kind of type is distinguished name, which is kind of like a foreign key reference in SQL, except you reference another entry by its distinguished name. And we have in 3.90 as a plug-in that generates back references. So if you add a user as a member of a group, then the user gets a member of back reference attribute, automatically generated, that points from member of the user entry back to the group entry. And these are internally managed by 3.90S. So if you remove a user, then also the group gets updated and the user is removed from the member entry or the other way around. And so another core feature what makes IDM for IPA usable in very large installations and makes it resilient against any kind of data center or connection issues of the fact that 3.90S is a truly multi-primer application system. So for the old name, Master Master. And it's a topology where you link multiple servers with other servers and they eventually reach a consistent state. So you update one entry and the entry then gets propagated throughout the whole cluster. And even with one or two of the servers are in maintenance or maybe the hardware failed, that's no issue. And this is also one of the reasons why we have DNS built-in into free IPA. We have location-based DNS, including server records. So an client tries to connect to a server. It doesn't usually connect a specific server. Just get me the nearest server that's alive and then it will be pointed to several host names and then we'll try to connect the different hosts and get the one that responds. So another core feature of free IPA it's very fine-grained when it comes to access control. And one thing that's also very different to what most people are used from SQLite, SQL database like Postgres at MySQL there is no like a database user. So the web framework, the web UI, the API does not have a database user like you used to. It has a special kind of user that is able to impersonate users via credential delegation or it's called Keboros. So it's a YouTube proxy. So what it means, so you connect to the front end like to FastJSON or to free IPA with your Keboros credentials and the database then gets connected by the FastJSON with the same credentials delegated through. So the actual user that queries the database is you. It's not the FastJSON user and that allows us to do all the permission checks inside the database. So in theory, we would be able to let anybody connect directly all that and there wouldn't be any kind of permission issues or privilege issues. With the role-based access control we also have a way to define who's allowed to do what very fine-grained. So one example we have, we have an agreement that allows you that you have to agree to before you're allowed to join a group and there are permissions to add or remove agreements. They're then combined into a privilege that is called fast agreement administrators and the role fast agreement administrator has this privilege. Then you can add either users or a user group and given that role and members of that user group who have that role is able to add or remove agreements. We also have a self-service permission so by default a user is not allowed to read nor modify any attribute. So you have to give users explicit rights to even get a value or change a value. There's special kind of ways to give this permission to say there's a self-service permission. So it means you can only modify your own entries. You can't modify a drive PRC nickname of a different person and we can also do constraint delegation of permissions. So we developed for Fedora accounting system a special new attribute called membership managers. These are group permissions, group attributes. So each group has a set of member managers and these member managers allow to modify a specific attribute and add and remove users for a group. So this is fine-grained delegation of permissions. That's what we developed when we created the FRAPA fast plug-in. Extend the LAP schema, extend the API, and extend the web interface. So for example, we extended the users to have our CNex, to have local information, you can upload the GBG keys, additional to existing ones and then allow users to hold users to read them. So all authenticated users are able to read this information and each user is allowed to change its own RC neck. For groups, it's similar to their new attributes listing RC channels and mailing lists. One rather big extension were the user agreement fields which we're going to demo eventually at the end of the talk. So user agreements are a requirement before you're allowed to join a group. The framework verifies that you're only allowed to join a group when you have agreed to all attached agreements for a group. And if somebody, so if a group membership manager or a fast agreement manager removes this agreement for you, you can't even disagree from an agreement, then you get already removed. We created several new permissions and access controls to do things and several things that almost are unique values. So in free IPA, we don't enforce that email address is unique, but in FAS we also enforce that it is unique. And finally, a bit of JavaScript code so Steven's power scan actually very handy. So we extended the UI with JavaScript. And I think we're now to demo time. I can't hear you, Steven. It's brilliant. It was muted. Okay, perfect. One penny in the jar. Okay. So let me start with a demonstration. This is how it looks currently. It's kind of small if you have the multi-screen, I don't know, maybe you want to click on the screen share to get it big enough. Maybe I can zoom in. Should be a bit better. All right. Okay. Okay. People can of course identify, but first we're going to register. Let's say I create an account for myself and my email address. Well, that's not much of a secret anyway. This is going to send me... Oh, that's nice. Okay. Let me refresh that screen. Okay. Of course. Okay. I've been keeping that page open for too long. Yeah, we have security, right? We have CSRF tokens. Great. So now it's going to ask me to validate my email. So I'm going to go look in my inbox slash terminal what the account what the validation link was. Yeah. So that's a long link with a token or like a GWT token. That's nice, even better. What is this? Okay. Well, we didn't pay enough to the demo, but sorry for that. Always happen. No, we're just showing how everything works even in validation. Right. I'm trying to show you how it's very secured. Yeah. I can't even do the things I was planning to do because it's so secure. Yes. Yes, that is entirely normal. That is exactly what I wanted to do. There it is. All right, back to the first thing. Copy the link. Thank you very much. That's that now. Hopefully it's going to work. No, I got the right link. Wonderful. So now that I have proven that my email address is correct, I'm going to be asked for a password which is going to be very interesting and I'm going to activate my account. I don't want to remember that password. Thank you very much. My account has been created. I am not logged in and it says that I have no group membership because obviously I just logged in. That's the profile page that you will be able to see on each user. It has a few information, a few pieces of information that are useful. For example, the time zone. That's pretty useful. The current time of that user and that's very useful obviously when you want to talk to people that are around the world such as people in our community. There's a direct link to the wiki page for that user and the federal people page for that user. I'm going to edit my profile because I'm actually not living in the UTC time zone. So let me check that. That is correct. It detected that I'm in, that I speak French but that is not correct. Europe Paris There it is. I can enter if my website URL I can turn my IOC nicknames here. Very surprisingly that's a part that is and I'll let you guess what my githlab username is and I'm going to save that and show you that on my profile if I go back to my profile, view your profile. Thank you. Now it says Paris and it actually shows my right local time. So it's 5.45 in the afternoon Friday for me right now. I'm going, I could show you how to upload GPG keys and attach keys and all that stuff. That's not very entirely interesting. There's the agreements thing that we've talked about before. It's a bit big so it's going to look less weird on your screen like it should be more aligned like this. I could decide to sign the fpca here. So I'm going to sign it. That's the whole fpca thing. No, it's actually not right. That's just a random stuff that we cut and pasted. It means absolutely nothing but we can still sign it. I'm going to sign it and now I signed it and it doesn't show a sign. Maybe I need to refresh this. No. We'll look at that later. One very fun thing is the OTP feature. So now we can have OTP tokens. I'll try to demo that. Of course, it's very, very risky. So I'm going to try it and I'm sure it's going to work first time. Once you get to two factor authentication with an OTP token, you can't really go back. So make sure you remember your tokens. Token name is going to be a test token and I'm going to use my password here to prove that it's actually me. This way, if I leave my screen open and I move away to get a coffee, nobody can come in and lock me out of my accounts by creating a token that I don't know about. So I'm going to generate it. Please don't save that. Okay, it's been generated now. I can click on reveal when I'm ready with my application on my phone that you're not going to see if you have maxed up the screen but I can get to that application. So I'm using something called Aegis but free OTP also work. That's on Android and I'm going to register a new token. There it is. Aha, I got my token. I could also cut and past it if I couldn't if I don't have this nice QR code feature. And now I have a test token and I have the idea of this test token and the next time I'm going to log in it will ask me for a token. I can also list the other users. I know that there are quite a few. I could list the groups here. Oh, it's in French by the way. It's going to be translated at some point entirely. So if you see Frenchy things, that's normal. It's actually a feature. Say we go to developers where we have test users. So there's all these users that are already members of the group. If I want to meet user Joshua here. I could just click on the search bar. Very standard thing. Nothing very original here. Pretty picture. All that stuff. And I'm going to log back and log in again with my token. So now I'm here on part. So when you have a one-time password token, you enter your password as usual and then you, that's one more letter. And then you enter the token that is given to you by the application. So for me that is going to be 034700 Of course, don't remember that. And I logged in. And so that actually works. Fantastic. What else can I show you not much actually. The rest is just the standard thing that you want to do. When you want to join a group here, say designers for example, you can't really join the group via not getting itself. That's something that we haven't brought back from FAS. You have to contact a group sponsor. Thankfully, sponsors are all listed there. So it's easy to to see who they are and contact them. And then with your group sponsor, then you will be able to add users to your group. If you want to create a new group, also as we say before, it's an admin request. So you just open a ticket and admins will do it for you. All right. I think that's all I had for the demo. So I'm going to stop here and get back to the slides. I'm going to go to that. So the repositories with the code are in GitHub. They are all with a similar structure. So Python code handle the poetry instead of setup tools. I don't know if you've worked with that before, but it's great. I encourage you to test it. We have unit tests. We do the linting with Flake 8 and it's all covered by docs. We have CI. You can use Vagrant for local development if you want to try that. So you just download the code and run Vagrant up. It should set it all up. It can take some time because IPA can take some time to install sometimes, but it does work. There's developer documentation if you want in Nuggin's doc. So what our standards are, what rules we use. It doesn't support hardware tokens. Now I think, well, Christian can and saw that maybe later. And there's we have a project to track progress. So yeah, it's a pretty good project code-wise and I think we'll be happy to deploy that to production right now. We are deploying it in staging or in the process of deploying it to staging and are running out all the remaining parts. So yeah, we're pretty happy with it and I hope you'll like it too. And yes, well, I think that's all. Thanks for listening. Anybody of the Christian and Steven, do you want to say something that I may have missed? Thank you. It's 10 minutes before, so if you have questions, we'll be happy to listen and answer them. That's popped up on the chat with the request for hardware tokens or UTF. That's currently not available in free IPA. I think that it's a bit more complicated, so it requires to write plugins both for Kaveros and LDAP in C and that's a bit annoying to write. But yeah, okay, Alexander, Michael Walker just posted the upstream ticket for the feature. So the first have to implement that in IPA and then they will eventually land as a possible feature. Any more questions? I think the other question we already answered during the talk. There was one about publicly visible profile URLs. So note that it's all behind Kaveros. Yeah, you'll have to be logged in to see other users. It's not going to be a public thing. But there's a link to a wiki page for users. If you want to have a public facing profile, you can use that. Also a question by Mohan. You've seen only two SSH key fields. Can we add more? Yes, you can add more. There's always going to be two empty fields. So you can add two keys at the same time. But it's going to be, you can have as many keys as you want to. Same thing for GPG. There was one from Neil when it's been deployed. So staging currently and in production early November. Yes. Did we talk about that? So the people in OpenSUSE are going to use this solution, the system free APA, Noggin, FastGest, etc. And they may even deploy it before we do. And that's great. I think that's great. So A4 community and sharing efforts and code. Fantastic. Christian, I'm not hearing you well and I don't know if that's a case for everybody. Very good. Positive microphone. Initially we started only to work on the solution for Fedora then Centres and SUSE joined and a while ago we got requests from somebody from the KDE community. There was no follow up yet. And Nome has been using free APA for a couple of years now. So that's the back end for the Nome community but they're not using Fast, they're using just stock free APA. Open source for the win. Yep. No Noggin for Nome. That's pretty hard to search. I think we started to use free APA like five, six years ago or four years ago. Sundar might know more about that. Also, we didn't mention the name Noggin. So you can now Noggin with your Noggin. That's a pretty cool name. The other two names are my, so when I did like a dirty proof of concept hack to figure out how to get like a JSON interface for fast, I just called it fast JSON and the name stuck. Sorry, that's my boring non-imagination. It was like a one evening hack before a meeting to show the end of the hour. I think there's any more questions you can approach the team on the Triple A channel. Yes, accounts are going to be transferred but yeah, you're right. It's about the end of the hour. Feel free to ask questions on federal and there will be an account migration. Both accounts are going to be transferred. We are trying to manage collisions so it's going to work but yeah accounts and groups are going to be migrated and centers groups are going to be prefixed, I think but you'll see that. Just when the in the migration, as we said before, there might be hiccups with names that are not composed of two words so just check that but it should be fine. Unless you are one of the two people who has no names, maybe if you can fix that before, that'd be great. This is one of the unfortunate side effects to having a standardized schema to a standardized API. I think we could fix that but it would take a while for the API to get that fixed that you only provide one name and in a moment you'll be restricted to first name, last name. The very European North American view on names, sorry for that. Okay. Well, thank you for sharing our talk and the rest of the vlog or Ness with Fedora and take care and hopefully see you next year at Bruton.