 Welcome everyone to DevConf 18, DSA BOF. We have about 50 minutes together, 45 minutes together. We'll do a presentation at the beginning, roughly 20 minutes or so. And then at the end, we can have as many questions as you want to field and we'll try to answer even half of them. So this is our agenda for this presentation. We'll talk about the delegation, membership, looking back, moving forward. Request that we have for some other teams. And then a question and answer period at the end. My name is Luca Filipposi. I'll introduce my colleagues in a moment. I just wanted to remind people that we are a delegated team from the DPL. So our delegation consists of the following activities. We maintain the Debian user database. It's currently in an LDAP, could be anywhere else, but it's the user database of Debian developers. We administer the infrastructure and support of Debian services. So anything that is a Debian.org is administered by us. We manage some of those services ourselves, for the most part. We manage some of those services ourselves. So the authentication authorization, email, DNS, content delivery networks, some of the mirrors and a bunch of other TLA's, those are administered directly by us. And of course we coordinate with hosting and service providers. Much of our equipment is not held in a Debian data center. There is no Debian data center. It's hosted by a variety of hosting providers. Typically universities, but also ByteMark, for example, in the UK. And finally we work with you to support your services that you run on the DSA managed infrastructure. So who are we? We are currently eight people. We were nine people at the last meeting. Currently here with us are five at the conference, four of whom are in the room. My name is Luca Filippozzi, in the front row. I'm Tullif, what do you have? I'm Paul Lois. And then in the fourth row. I'm Hector. That's Hector. Hector is also one of the Debian.org organizers. Not available to us today is Martin Zobo Helis. And then three people are not here at the conference today. Julien Cristal, Peter Palfreder, and Aurelian Jarno. And in fact, those three do the bulk of the work. The rest of us help out, but it's those three that do the bulk of the DSA work. And I would be remiss if I didn't thank Stephen Gran. So Stephen was a DSA for many years and he stepped down between the last I've come from this one and we thank him for his service. Looking back, it's been a busy year for standard service requests. As you know, we do that through RT and we have had a pile of them this year. I won't go into them. It's the standard kind of thing. But it's also been an extremely busy year for interacting with other teams. So we've been working with the Debian secure boot team assisting with the secure signing infrastructure so that when kernels that have secure boot features need to be signed, they get signed in the appropriate way in a secure manner. We've been working with the Debian cloud team. We deployed a new CD build image server called Casulana and other related infrastructure. And we really hope that this is the year that we see it being used for the building of all of the cloud images. Right now it's only doing open stack and the CD images themselves. We've been working closely with the DevCon team, both global and local, to move some of the existing services and adding new ones in support of DCA team so that they're not on DevCon infrastructure but on Debian infrastructure. And finally, we've been working with the Debian mirror team to bolster the monitoring of mirrors and to delist defunct mirrors or mirrors that are chronically out of sync because we want the user experience to be a good one. And it's great that universities and others hosting providers are offering mirrors across the world, but they're not as useful, those mirrors if they're stale and out of date and users are referencing old material. And that's one of the reasons why the security mirrors may continue to be something that we manage directly with a small number of mirror sites around the world and lately behind Fastly's or Mac CDN, one of the two content delivery networks. And that way we can ensure timely delivery of security updates to our user community. We've not done a lot of infrastructure refresh over the last year. The biggest one really was a new to us storage array at Sanger in the UK. So Welcome Sanger has always been generous to us. They have an enormous HPC with a huge amount of storage. They do a lot of drug interaction testing, I guess. And when they do a storage refresh, they often make that storage available to us. It's extremely handy for SnapshotsDevian.org. So we keep Snapshots of all of the packages that go out, not just the point releases. And if you've never been to Snapshots.Devian.org, I encourage you to go. And that's how you can go and find that one package that has gone away. You can still kind of try to find it through the Snapshots. Other service changes that we've deployed, both security tracker and security tracker behind a content delivery network. Security tracker is actually a bit of a funny one. Whenever I move my head in a particular way, I lose audio. I'll just not move. The security tracker, I forget the name of the software package that was modified to pull down a variety of CVE sources, including Debian CVE source. And it had a bug, which was that every time one of those CVE sources came back with a 404 or something, it went and refetched all of the CVE sources. To the point that it was hitting us every time that it ran this thing, an unnamed company, not represented here or on the back of my t-shirt, deployed this as part of their cloud image test cycle. So I think what they do is their user community can upload a VM image to their testing portal and it runs this thing. So they had thousands of machines all running this testing framework, all hitting security tracker, which is a poor little machine sitting at MIT and we completely trounced it. So we moved it behind a content delivery network. Very thankful to Max CDN for allowing us to do that. And we mitigated that load at least temporarily and then we got in contact and we got them to mitigate a little bit of the load by reducing their node count and now we're talking about how we can fix that bug so that other people who've deployed it because it's an open source project can also start hitting our security tracker less. But it's the unintended kind of thing, completely out of our control and caused us a huge amount of load. And that's why it's important for us to have service providers that are able to scale to meet our needs. So thank you for those people who have donated to DebtConf and made this conference possible. I'd also encourage you to think about giving to Debian directly because sometimes we need services, either donated or things that we buy that we can address the loads and the requirements of our users. And we also had a DSA sprint in February. I did not attend that. We hope to have another one in 2019 probably. It's usually during these DSA sprints that we kind of plan out our four or five-year trajectory of our hardware refreshes and our service refreshes. So to that end, moving forward, the biggest refresh this year is likely to be the updated Gennady cluster at Manda. So we have pairs, usually, of machines that are operating as Gennady clusters. All of our services, as much as we can, are virtualized in VMs. They run in multiple geographic jurisdictions, so Europe and North America. They run on multiple Gennady clusters, even when they're in one jurisdiction. And we tried to do this to ensure that we have no single point of failure, either a legal issue. That's why EU, United States, or North America, no vendor or hosting provider single point of failure. So we don't put everything at bite mark. We don't put everything at UBC. No single point of failure on hardware. Ideally, we have a lot of HPE equipment, but we're trying to diversify that a little bit. So again, if we have relationships with these vendors, we can go to one or the other, get the best price, but also not suffer a situation where the relationship sours or we can't get spare parts or what have you. So we try to achieve redundancies in each of these things, including services like content delivery networks. So Mac CDN is one CDN partner. Fastly is another CDN partner. DNS, we have some global DNS providers. Again, we have two of them. So in all of these things, we try to achieve some form of redundancy. So the Gennady cluster is one of the VM farms. It's not the only one, but it's the next one being updated. We have two other things that we'd like to focus on in the next year. As part of the cloud team effort, we'd like to address the identity and access management aspects. I brought this up at the last cloud sprint. It will probably be a topic for the next cloud sprint. And the challenge here is that these hosting providers, cloud hosting providers have offered individuals accounts or we have pseudo Debian accounts. We don't really have an account for Debian proper. It's not signed by SPI as the trusted organization. There are probably some indemnification aspects that need to be reviewed. And it's not tied into UBC. That's where I work. Debian's authentication and authorization infrastructure. So from a DSA perspective, it would be good if we could turn off Luca's account in Debian but also have Luca's account be turned off in all the places in the cloud where he should no longer have access wearing his Debian hat. So if I retire or damn chooses to disable my account for some reason, this should turn off in all the places where I gained access as a consequence of being a Debian developer. We are advocating for DPL to create a formal cloud team delegation. We think that that's important in order to solidify some of the policy decisions that are being made by the cloud team. For example, all images to the best of our ability should be built on Debian hardware under DSA control. So Kasselana. Right now those cloud images are not built on Kasselana. The only ones that are are open stack, but not AWS, not Google and not Microsoft and not DigitalOcean. So take your pick. The only one that is on Kasselana is open stack. I just mentioned integrating the Debian authentication and authorization with each cloud provider. Each one is a bit different. Some of them are SAML aware, some of them are only LDAP aware. Either way, there's always going to be some mechanism that we can use even if it has to be an LDAP sync in order to achieve authentication and authorization coupling. What about DSA taking control? I want to make that clear. This is about empowering the cloud team to manage access to the cloud resources and other reason why there needs to be a delegation to the cloud team so that whoever the delegate is or the team of people that are the delegate, they make the decision about who gains or loses access to cloud resources. We talked at the last DSA, at the last DEBCOF about a container service. In terms of our own thinking, Debian itself has made progress in terms of adding container runtimes into packages. They're making their way into testing and back ports that are unstable, of course. We need to make some progress on this front. We need to decide whether or not we're going to focus on Docker or Kubernetes. It's lagging in Debian, so Kubernetes is interesting and probably the better one, but we need to make significantly greater progress on that front as a community before we can turn it into a DSA-managed container service. We need a conversation, therefore, around Docker versus Kubernetes, and we can do that after we finish this presentation if we want. We also need to include a conversation around vendering because there's a lot of stuff inside of Kubernetes that moves quickly. Do we want that to be packaged externally or can we package it inside of the Kubernetes package so that it makes its way through the archive more quickly in terms of releases? So, two of our requests. He's here in the room, so DPL, please establish a delegation of the cloud team. We can talk about that after. The DI team, we've now been running deb.debian.org for more than two years, I think. It's quite stable. We would encourage the DI team to consider making deb.debian.org the default repo during installation and only if somebody chooses a country-specific repo they could change. Deb.debian.org is behind the content delivery network, so it's available throughout the world. The app team, there are still some issues with content delivery networks where if a cache misses, it has to go back to the back end. Sometimes there's hash mismatches. It would be really good if apt itself using content security policy report URI directives could cause apt to deliver hash mismatch reporting back to deb.debian so we could understand where these hash mismatches are occurring. It would be nice if apt also retried. So when there's a miss and when it doesn't return fast enough instead of bailing on the first 404 could it retry a couple of times before finally working out. I think that would be useful. So the report URIs are useful for us on the administration side. The retries are useful on the end user side so that it doesn't just work on the first 404. And finally to the cloud team, let's get busy on moving all this stuff to FAI and building under Casulana so that all of the deb.debian branded cloud images are all built in the same manner on the same hardware that's deb.debian controlled. Finally going to questions in a moment but I also have here how to contact us so we are available in the deb.debian admin channel on IRC. You can also email deb.debian admin typo no g there I'll fix that in a minute. That's not just DSA. It's a closed mailing list but it's not just us, it also includes some hosting providers and service owners. So if you want to talk to just us then you should email dsa at deb.debian.org and that's just the Debian system admin. So if you have something of concern that you don't want it to be public to these other people or you don't want to discuss it on IRC, please email all type of service request. I should have put it on here. Kindly use RT rather than email directly to DSA. Be cognizant then of course that depending where the ticket moves it might end up in a queue that isn't DSA it might go to another team for processing and therefore be cognizant what you put into the ticket. So that's about 17 minutes worth of talking. I said it would be 20. I'm about on time. Happy to field questions. All four of us are here. Hi. The cloud team delegation is that blocking on me or do you need to, would you like me to write the draft or you write the draft etc. No it's not blocking on you since we only just told you about it a minute ago. You, just checking. But. On that. So we've only just been discussing it this week. We haven't even worked out who we'd ask for you to delegate yet. You know it's something that will be coming to you again with more details on shortly. Awesome. The other thing is the you listed a whole bunch of sponsors like the people supplying the dis space for snapshot.devin.org I wonder if you could talk briefly about what sort of I can't think of a better word but return these sponsors are seeing on their investment in terms of I mean at least in terms of are they their logos on the home pages of these things and beyond that because I'm they're very kind to do it but also they're doing it for a reason as well and and things like that. If you got what I mean there. Sure. I can't think of a better way of phrasing that. Well some of them are truly altruistic. Some of them run Devin infrastructure themselves and want to give back in one way or another. So historically it's been universities that have offered us both hosting space and in their data centers and bandwidth and they've typically had excellent bandwidth because they're part of some NREN, National Research Education Network. So a giant in the UK giant in the UK or two in the United States. More recently we've had companies offering space like ByteMark. All of them have the opportunity of having their logos or some short blurb of what they do to be listed on the Devin partners site which is off of www.devin.org partners I believe. Laura and I are on the Devin partners team. She's much more active than I am. We've been trying to clean up the list of partners to make sure that it continues to be relevant because it had been un-maintained for some time. We've not yet gotten to the point where we have a proposal of what it means what is the criteria to continue to be listed. So if I think of HPE for example who donates to Debconf but does not any more donate to Debian they did though donate an enormous amount of equipment $450,000 worth of equipment in 2016 and so does that mean they only get one year of being on the partners page or do we amortize that over the lifespan of the hardware so we don't have criteria for that because if I were in HPE's shoes I would say that maybe I should be on that partners page for some number of years. On the other hand we have the DNS hosting providers which are crucial and they are tier one hosting providers where the cost of delivery of that service to us is probably very very low to them so the value to us is enormous but the actual cost of acquiring that service is probably fairly low no or close to $450,000 and so what is the criteria for ongoing listing of a service provider of that nature so Laura and I have ignored that problem a little bit because it is it is a little bit thorny at the moment if you are an active provider of a service or we have your equipment in a data center that puts you on the partners page if you are not running HPE equipment at some point maybe then that is when the HPE logo would go away another slightly more visible place we actually put this at least for hosting and hardware donations is on the machines page on DBA Debbie and Og because I think that people tend to look at that more often than the partners page and in general if partners are interested in doing things like press releases or something else we try to be cooperative I was also coming from the other angle of I often speak to a bunch of people very early stages of perhaps potentially thinking of donating and I am saying please do please please please amazing then they sort of hunt around for what they would get for that and they see that the people who are currently sponsoring particularly hardware aren't really asking for that much therefore just a little logo and they are fine with that but the people coming in are like are we going to get that kind of thing and they don't get excited about that kind of partnership even though we could potentially offer more but yeah they are not asking for anything so the question was what are they asking for they aren't asking for anything in particular but when they sort of survey the scene of what currently people are doing which seems like currently people are happy with what is going on they don't get excited about it in that sense so there is a kind of hidden category of oh yeah so yeah I have no ask here I am just curious about what the current state is yeah so I mentioned what Laura and I are doing but we do need input in terms of what would a package of interest be to an OEM like a Dell or HPE to continue sponsoring hardware for example one more thing there is a bug I filed a few years ago against DI for the deb.dev.org rename all at the time it was for HTTP reader so that just needs a rename yeah so again deb.dev.org is in DI and already is to a certain extent the default but yes we should probably improve it so it's the only one offered unless you want to specifically go and check something else so to be clear we are not advocating removal of the rest of the country specific list and there is always a risk that max CDN or fastly stop being a CDN provider so having the country specific mirrors is important but as long as we have these two CDN providers and deb.dev.dev.org is stable I think it's a nice way of communicating to our users that you don't have to think about that piece of the installer breeze to that next screen I guess what would happen if say the unthinkable happens and all of our CDN providers say, fuck you deferred I guess what would we do in that case we just point the web deb.dev.org to ftp.us would we try to do it OK deb.dev.gov is just a bunch of SRV records I was thinking if a cleaner fall back if you encoded that country information in, I don't know. That said, if they decide to stop sponsoring us, they would probably also stop sponsoring small sites like Pipeye, C-Pan, RubyGems, and like basically like the entire open source like internet hosting would fall away. So I'm not like super concerned about that. But yeah, we, and it's part of the reason why we have two different companies sponsoring CDN stuff. So if something goes wrong or, you know, they like the relationship sourced or whatever, then we can actually change that. Yeah, and to be clear, I don't think this is in any way likely. I just thought it was a possibility. So I'm entirely unrelated. We talked about cloud and IAM, but are, is there any work being done on like overall Debian IAM? Like making our sort of, you know, user experience more consistent and more central. Like maybe like. So I started a user, so what we use is something called user-dure LDAP and user-dure CGI. And I started a rewrite of those several years ago called UD, out to the point about 80% of coverage of user-dure LDAP. It didn't have the web interface. And then I stopped. Got irritated to what I was doing and moved on to something else. I should probably resume it. A really important question for us to ask those, whether or not what we're doing with LDAP even makes sense because we overload LDAP with a lot of Debian specific customizations, which means that take your pick of product, you can't really use it out of the box with our LDAP and is that useful? So if what we want is a database, then use a database. And at which point then you could do different things. You could deploy, we could deploy an IDP for SAML or OIDC or things like that. So these are, I don't know that we'll get these solved in times for the next Debian cloud sprint because I think that sprint is where we have the hard conversation about getting people to buy into the idea that this needs to all be kind of centralized under a same-same auth-n, auth-z kind of infrastructure and then what do we need to do? So, work is needed. I don't know whether or not UD, the rewrite of user-drailed up is the right direction though. If one wanted to get involved with that and it's not membered GSA, how would, is it like what would it do? So I do a lot of identity management stuff at my university, I'd be happy to chat with you. We could talk about what the smart play here is. So I should describe a little bit what user-drailed up does. Apart from heavy customization of LDAP structure, when we were a young distro and we had hosting providers all over the world and machines all over the world, connections weren't very good and so having live authentication back to some central store did not make sense. So what user-drailed up does is it really, it generates a pile of individual files for, it's a user, it's a group, see, there we go. It's such a group and, or for the mail service or take your pick, it does those piles and piles of these little small files and then it distributes those files to individual machines so that they can act standalone in case network links go down. That's probably still useful, we probably don't want to be reliant on their internet connections to be available back to some central source but can we clean up the many separate files so it's one kind of push to each host and on each host it does something a little bit more intelligent. There's like choices to be made here and that's Luke and Helen would like to meet with you. That's my intro. Nice. Yep. Related to that, what's the sort of story for new people joining the team perhaps on the side helping out in this particular area? Obviously it's difficult because you might need, you know, pseudos or whatever. Yeah, so we are like any other delegated team, we recruit ourselves and then we find whether or not that person works out in a pro B fashion and if it does work out then we ask DPL to expand the delegation to include that additional person. So trust is not transitive just because somebody's on the DI team or on the cloud team does not mean that they should be on the DSA team and vice versa. At the moment we are not recruiting, we could talk about that given that one of our colleagues resigned, but so in terms of becoming DSA, get to know us, join the channel, participate, start giving ideas and then we can talk about it. But we're like any other team, recruitment from inside. Sure, but you would concede it's slightly more difficult because someone thinking of joining couldn't be running commands on machines whilst they could perhaps be throwing commits at DI, right? Well, there are many of us that wear multiple hats even inside of the current DSA team. Julianne is a stable release manager. I'm working with the cloud team. Take your pick, we all are wearing multiple hats. People that do these additional roles inside of Debbie and me to wear their hats faithfully. So you don't join DSA just because it makes your DI work easier. So I wasn't saying that, it's just I'm saying that as a, just comparing the two teams, not about different hats at all like that, but it's sort of easier to contribute as a newcomer to DI than DSA, yeah. That's just part of the game of DSA. You can't really work around that as it's thingy, but I'm just wondering how one can make it slightly easier. Mike's saying very well, sorry. Sort of, I think that given that DSA has root on every debby.org machine and it runs all of our infrastructure, people that want to become DSA members need to have a demonstrated track record with the organization in a number of different teams, at least one beyond just being a DD uploader. And hopefully also have some work experience or some other kind of open source project support experience in system administration. So we're not gonna, I'm not sure how keen we are on training in system administrator, but if you are working as a system administrator and have done a variety of tasks, then that would be interesting. I guess other ways one could say, I don't know, contribute to DSA, could be config management or that sort of thing to sort of demonstrate that sort of competence. Yeah, so all of our stuff is managed with Puppet for the most part. Our Puppet repos, the repos themselves are private, but we have a copy on Salsa. So it is crafty and could use a lot of cleanup. Absolutely people that are experts at Puppet could give us a hand. We had a major rewrite of it, which we didn't deploy because it was too big of a patch. So we probably turned that person off a little bit because they were super keen, but it was also too big of a risk to apply in one fell swoop. So having incremental improvements to our Puppet infrastructure to bring us into more conformance with modern Puppet usage would be great. That would be absolutely perfect. Yeah, I've been at least at one organization that tried to get a modern Puppet and ended up switching the chef. Yeah. I think there are various smaller projects where we would be interested in, like if somebody wanted to help out with some of our monitoring and metric scattering, that's something where I think we could improve what we have. Currently, it's Mooneen and Ishinger. And I mean, it turns out that five minute resolution on graphs is not actually that great. So replacing that with something more modern would be welcome, but it wouldn't actually require that much in terms of access to get it going. So, and it's also something where we can run it in parallel. So it's easier for somebody to contribute to something like that than it would be to replace all the authentication where suddenly you're replacing really base bits of the infrastructure. Okay, so to complete the kind of introductions of who spoke, we had Pupp, Chris, we had Luke and behind Luke, we had that guy, Sledge. Anybody else have questions for us? We have 15 minutes left or so? So going through the recent discussion about architecture qualifications for the Buster release, so DSA did raise concerns about some of the existing buildings for the on ports in a subject obviously close to my heart. So, obviously I'll be talking about that in the on ports box tomorrow and I've been talking to you already about some of the related stuff. Where am I going with this? Sorry, it might be nice to have a clear idea of exactly what DSA considered to be a minimum standard for build D and for hosted machines. I think I have a reasonable idea but I've been kind of asserting it and no one's arguing with me. But definitely, it would be nice to actually to get something agreed about that rather. So we don't just end up disagreeing and maybe have a surprise later. We've written that down before. To all of us busy searching where we wrote that down. We're happy to write it down again in a more public place if needed. But it basically, it comes down to the following. Most of our hosting providers are not where we have access, right? So none of us live close to bite mark, for example. I happen to live close to UBC and work at UBC so the stuff that's there I can maintain but that's the exception, not the rule. So we want to make the life of our hosting partners very simple. So that typically means buying relatively ideally new hardware in the HP terminology, an extended warranty or care pack that includes onsite technician so that the only thing that we need to do with our hosting provider is irritate them to the point of granting access to the HP technician but otherwise the machine is maintained on our behalf by HPE. Anything that's not like that means that we need intelligent remote hands provided by the hosting provider so that we can let them know that they need to swap out a hard drive. Okay, that's not that intelligent. I'll have to taking apart a server or finding an ATX box that can accommodate an ARM board or something like that. So that's why we typically like rack mounted hardware that comes with it that is purchasable from a vendor so that we're not reliant on donations only so that something that we can get a warranty for so that ideally a onsite technician type warranty so that they can come and do maintenance on the device and not have to bother a hosting provider. Needs to have some kind of remote management capability either on board or with additional things off board like intelligent power bar or serial console needs to boot into serial so that we can see what's happening during boot. Needs to power on successfully after a reboot cycle some of these boards don't so that they really are these remote devices that can be managed by DSA without having to bother our hosting provider to go push a button to reset it. So the conversation that we had earlier today and earlier this week was could ARM put together a bunch of one new boxes with the donated boards that you have that meet the specs? And I said I think I'd be comfortable with that I haven't discussed that with my colleagues but effectively what that means is that ARM or Leonardo depending which hat you do it with becomes the vendor for these boxes, right? And we don't get a Leonardo technician to come and fix it but we maybe put them in a couple of places where like ARM and at UBC where there is somebody close by they can go do something. So we still at geographic redundancy we want the legal jurisdiction redundancies that's in Europe and North America and your upcoming trip to Vancouver makes for a really good opportunity for you to build a couple of these and bring them by. Exactly, yeah, thanks. No, I said I think I understand that you understand that it's just great to get this clarified for anybody else who might not be aware of the discussion. Yeah, if you view these things through the lens of what is the, how do we minimize the burden on our hosting provider and the rest of it kind of follows? Yeah, I couldn't actually find it documented so I'm starting to do that actually right now. Awesome, thanks. So I know we've had discussions about this before and I think it has been documented but just something that you say could be linked from the existing, from the latest round of arch qualification stuff, you know, just makes it easier for people to understand that sort. Any other questions? So how do you say handling mail these days? I know that Steve Gran used to be involved very much, set up a lot of effort in for XM Config across all the machines and whatever. What are plans these days? I have been the one doing most of that, hacking our data except config lately. So we don't really have any big plans to change stuff much. I mean, it's there, it works. We do want to get, so there's at least last time I checked there was missing support in XM upstream for various things like Dane and so on which would be nice to get in but which isn't really, it's not about DSA and Debian or such, it's more of a, it would be nice if we followed more of the more modern standards. We haven't really, we've kind of ignored the entire SPF decam stuff. I know that Luca looked a little bit at it a few years ago. If there is more interest in that then it's something we could look more at but. Sure. So a follow up question, in fact, is a couple of people have asked me this week how to deal with sending mail from Debian.org addresses. Obviously, lots of us have our own color boxes and we can just do mail and whatever and it just works. Of course, lots of newer people who don't have that. I'm told but by at least a couple of people it's a struggle to get through an ISP or whatever that will let them set from addresses. We've had the question in the past, could we possibly set up at least a limited support smart host or mail forwarding for some of those people to let them actually work at using Debian.org addresses reasonably? Feel free to point those people in my direction because I actually run that like without any other hat and like my own, I run such a service and I'm happy for people to sign up to that. I think several of us run such a service for people in Debian who need this and don't do it themselves and Steve's point might have been that a more centralized service is needed. Yeah, this is a centralized service that people can sign up to. Ah, awesome, I'm glad it exists. I wasn't aware so I'm glad to hear about it. And for the video that was Stefano that interjected. Okay, six more minutes. We don't have to fill it all in but happy to field your questions. Ask now or wait a year. Because you'll never talk to us any other way. Okay, well if there are no further questions we'll hang out a bit after the session and chat with you but we can call the video presentation to a close. Thank you.