WEBVTT 99:59:59.999 --> 99:59:59.999 [Tollef]: Hello, I'm Tollef. 99:59:59.999 --> 99:59:59.999 I'm part of the DSA team 99:59:59.999 --> 99:59:59.999 With me today, we have zobel 99:59:59.999 --> 99:59:59.999 who's also a DSA member 99:59:59.999 --> 99:59:59.999 and we're here to talk a little bit about what DSA does 99:59:59.999 --> 99:59:59.999 and obviously, if you have questions or anything, we'd be happy to try to 99:59:59.999 --> 99:59:59.999 answer those 99:59:59.999 --> 99:59:59.999 [zobel]: Try to keep that as some sort of round-table 99:59:59.999 --> 99:59:59.999 because we want a discussion, this is not going to be a talk 99:59:59.999 --> 99:59:59.999 so whenever you have questions, just ask 99:59:59.999 --> 99:59:59.999 [Tollef]: The DSA currently consists of 7 people. 99:59:59.999 --> 99:59:59.999 Most of us are in Europe, 99:59:59.999 --> 99:59:59.999 but we also have Luca who is in Canada 99:59:59.999 --> 99:59:59.999 apart from that, paravoid is on "holiday" and ?? 99:59:59.999 --> 99:59:59.999 and various other people. 99:59:59.999 --> 99:59:59.999 [zobel]: The duties we have as Debian System Administrators 99:59:59.999 --> 99:59:59.999 is basically to build and maintain the infrastructure you are all using 99:59:59.999 --> 99:59:59.999 for running our distribution 99:59:59.999 --> 99:59:59.999 It's the general sysadmin stuff; 99:59:59.999 --> 99:59:59.999 we are doing installing security updates, 99:59:59.999 --> 99:59:59.999 keeping machines up to date, 99:59:59.999 --> 99:59:59.999 keeping the hardware running, 99:59:59.999 --> 99:59:59.999 creating accounts for you, 99:59:59.999 --> 99:59:59.999 running DNS and mail. 99:59:59.999 --> 99:59:59.999 [Tollef]: One thing we actually don't do is... 99:59:59.999 --> 99:59:59.999 we provide the base, we provide the OS, support for that 99:59:59.999 --> 99:59:59.999 we don't run the services 99:59:59.999 --> 99:59:59.999 so lists.debian.org, we're not the people you want to talk to 99:59:59.999 --> 99:59:59.999 if there is some problem with spam handling 99:59:59.999 --> 99:59:59.999 Then, you want to talk to this guy 99:59:59.999 --> 99:59:59.999 who is also a part of the listmaster team 99:59:59.999 --> 99:59:59.999 Similar, bugs.debian.org, the web pages 99:59:59.999 --> 99:59:59.999 We make sure that apache is running 99:59:59.999 --> 99:59:59.999 but if you find typos on the web page, 99:59:59.999 --> 99:59:59.999 if there is a typo don't blame us. 99:59:59.999 --> 99:59:59.999 [zobel]: I don't know how many machines we run in the meantime 99:59:59.999 --> 99:59:59.999 I think it's around 150/160 machines in total, including the VMs. 99:59:59.999 --> 99:59:59.999 [Tollef]: No, if you count VMs, it's more like 250 99:59:59.999 --> 99:59:59.999 [zobel]: OK 99:59:59.999 --> 99:59:59.999 We run those machines currently at about 30 locations worldwide 99:59:59.999 --> 99:59:59.999 Also part of our duty is to deal with hosters and the local admins 99:59:59.999 --> 99:59:59.999 If they have firewalls running in front of our machines 99:59:59.999 --> 99:59:59.999 we try to convince them to disable the firewall parts for our machines 99:59:59.999 --> 99:59:59.999 so we get to manage that stuff ourselves. 99:59:59.999 --> 99:59:59.999 [Tollef]: This is often ?? 99:59:59.999 --> 99:59:59.999 we have some locations where the machines are ?? connected for instance 99:59:59.999 --> 99:59:59.999 and this breaks secure NTP 99:59:59.999 --> 99:59:59.999 There are various places where we have to make accommodations 99:59:59.999 --> 99:59:59.999 because it's hard to get the hardware to be another place 99:59:59.999 --> 99:59:59.999 maybe it's dev boards for an architecture which is being bootstrapped 99:59:59.999 --> 99:59:59.999 in some cases we kind of have to endure a little bit of pain for that 99:59:59.999 --> 99:59:59.999 but most hosters and most local admins are really nice people 99:59:59.999 --> 99:59:59.999 really easy to deal with and very very accommodating 99:59:59.999 --> 99:59:59.999 I mean, we don't pay for any of this. 99:59:59.999 --> 99:59:59.999 It's all sponsored and given to us, free of charge. 99:59:59.999 --> 99:59:59.999 We're quite lucky. 99:59:59.999 --> 99:59:59.999 [zobel]: It differs from location to location 99:59:59.999 --> 99:59:59.999 we currently have locations where we have a full rack 99:59:59.999 --> 99:59:59.999 which we can populate with hardware, 99:59:59.999 --> 99:59:59.999 there are other locations where we just have 1 or 2 machines 99:59:59.999 --> 99:59:59.999 just sitting and doing the jobs for us. 99:59:59.999 --> 99:59:59.999 Keep in mind all of us, 7 persons, are not paid to do sysadmin jobs 99:59:59.999 --> 99:59:59.999 We are all doing that on our volunteer time 99:59:59.999 --> 99:59:59.999 So if you speak up on IRC, 99:59:59.999 --> 99:59:59.999 sometimes you will not get a reaction within 5 minutes 99:59:59.999 --> 99:59:59.999 but I think that's mostly clear to all of you. 99:59:59.999 --> 99:59:59.999 [Tollef]: Because we have to so many machines, 99:59:59.999 --> 99:59:59.999 we like automation 99:59:59.999 --> 99:59:59.999 We run puppet everywhere 99:59:59.999 --> 99:59:59.999 It was chosen some time ago 99:59:59.999 --> 99:59:59.999 and it generally does the right thing 99:59:59.999 --> 99:59:59.999 and generally works okay. 99:59:59.999 --> 99:59:59.999 This often makes for some interesting problems when bootstrapping 99:59:59.999 --> 99:59:59.999 because apparently ruby is really awesome to bootstrap. 99:59:59.999 --> 99:59:59.999 Right, Steve? [laughs] 99:59:59.999 --> 99:59:59.999 Especially on arm. 99:59:59.999 --> 99:59:59.999 We also like git 99:59:59.999 --> 99:59:59.999 we have the entire puppet repository in git 99:59:59.999 --> 99:59:59.999 our domains are in git 99:59:59.999 --> 99:59:59.999 Our wiki is in git 99:59:59.999 --> 99:59:59.999 [zobel]: Everything. 99:59:59.999 --> 99:59:59.999 [Tollef]: Yeah, basically everything can be put into git 99:59:59.999 --> 99:59:59.999 You probably don't to do it to a database 99:59:59.999 --> 99:59:59.999 but anything else, put it into git 99:59:59.999 --> 99:59:59.999 [zobel]: We have some sort of account management tool 99:59:59.999 --> 99:59:59.999 which we are currently rewriting called userd-LDAP or ud-ldap 99:59:59.999 --> 99:59:59.999 Luca has done quite a lot of work on the rewrite 99:59:59.999 --> 99:59:59.999 I think it's already handling the generating stuff 99:59:59.999 --> 99:59:59.999 just rolled out to the debian.org machines 99:59:59.999 --> 99:59:59.999 all the other parts of ud-ldap are still using the old codebase 99:59:59.999 --> 99:59:59.999 which is ugly to read, 99:59:59.999 --> 99:59:59.999 it reads like perl bash, written in python. 99:59:59.999 --> 99:59:59.999 If you have spare time and knowledge in python, 99:59:59.999 --> 99:59:59.999 help us to finish the rewrite jump 99:59:59.999 --> 99:59:59.999 [Tollef]: The new ud is a django project 99:59:59.999 --> 99:59:59.999 So it's fairly nice and well written 99:59:59.999 --> 99:59:59.999 What ud-ldap actually does is... 99:59:59.999 --> 99:59:59.999 it has a local ldap server which runs on the machine called ?? 99:59:59.999 --> 99:59:59.999 which is db.debian.org 99:59:59.999 --> 99:59:59.999 and on there it generates static files which are synced out to all machines. 99:59:59.999 --> 99:59:59.999 So even though we're using LDAP for account information, 99:59:59.999 --> 99:59:59.999 we don't have a single point of failure. 99:59:59.999 --> 99:59:59.999 So if that machine goes down, 99:59:59.999 --> 99:59:59.999 it means you can't update your password or your SSH keys 99:59:59.999 --> 99:59:59.999 but you can still login, at various places. 99:59:59.999 --> 99:59:59.999 [zobel]: It also works around network issues between machines 99:59:59.999 --> 99:59:59.999 If SSH between ?? and the porting machine or whatever, 99:59:59.999 --> 99:59:59.999 you can login to machines. 99:59:59.999 --> 99:59:59.999 We monitor our machines using Munin and nowadays Icinga. 99:59:59.999 --> 99:59:59.999 We had some performance issues with Munin, 99:59:59.999 --> 99:59:59.999 with the wheezy version, I think it was 99:59:59.999 --> 99:59:59.999 and I think there were other stuff, 99:59:59.999 --> 99:59:59.999 Munin works quite well for us 99:59:59.999 --> 99:59:59.999 In general if there are web pages, 99:59:59.999 --> 99:59:59.999 like Icinga or Munin asking for a password 99:59:59.999 --> 99:59:59.999 then this is just dsa-guest and either no password or just a random password. 99:59:59.999 --> 99:59:59.999 This is just to protect our services against script kiddies 99:59:59.999 --> 99:59:59.999 or whoever to wants to see what his script is doing 99:59:59.999 --> 99:59:59.999 in effect to the Debian services, not seeing the results directly 99:59:59.999 --> 99:59:59.999 but everyone who knows how the Debian system works you get access to there. 99:59:59.999 --> 99:59:59.999 [Tollef]: It's also so that we don't accidentally end up with spiders walking around 99:59:59.999 --> 99:59:59.999 because Munin web interface is generating the graphs on the fly 99:59:59.999 --> 99:59:59.999 and it's using rrdtool and that can consume great amounts of CPU power 99:59:59.999 --> 99:59:59.999 and web spiders are really good at wasting CPU power, for us 99:59:59.999 --> 99:59:59.999 so we want to keep them off those pages. 99:59:59.999 --> 99:59:59.999 [zobel]: To track our issues we currently have with hardware failures, 99:59:59.999 --> 99:59:59.999 with accounts we need to create and so on, 99:59:59.999 --> 99:59:59.999 we use request tracker on rt.debian.org 99:59:59.999 --> 99:59:59.999 which some other teams use as well 99:59:59.999 --> 99:59:59.999 You can even mail it, or use the web interface. 99:59:59.999 --> 99:59:59.999 Debian developers, I think only, for viewing the web interface? 99:59:59.999 --> 99:59:59.999 [Tollef]: For most people it's read-only 99:59:59.999 --> 99:59:59.999 You can interface with request through mail of course. 99:59:59.999 --> 99:59:59.999 If you need to send something there, send it to rt@rt.debian.org 99:59:59.999 --> 99:59:59.999 and make sure to including debian rt in the subject 99:59:59.999 --> 99:59:59.999 else we'll just throw it away because then it's spam 99:59:59.999 --> 99:59:59.999 It's a really efficient spam filter 99:59:59.999 --> 99:59:59.999 Slightly annoying for when you submit the first ticket. 99:59:59.999 --> 99:59:59.999 [zobel]: The last talk we gave about the DSA team 99:59:59.999 --> 99:59:59.999 was, I think, 2 years ago. 99:59:59.999 --> 99:59:59.999 We tried to summarise what we've done in the last 2 years 99:59:59.999 --> 99:59:59.999 When was that meeting in Oslo, 3 years ago? 99:59:59.999 --> 99:59:59.999 [Tollef]: 3 years ago, yes. 99:59:59.999 --> 99:59:59.999 [zobel]: 3 years ago we decided that we want, 99:59:59.999 --> 99:59:59.999 at least the infrastructure hardware 99:59:59.999 --> 99:59:59.999 not the porting hardware 99:59:59.999 --> 99:59:59.999 on machines that are under warranty 99:59:59.999 --> 99:59:59.999 so we can open a ticket at HP, IBM or whatever 99:59:59.999 --> 99:59:59.999 and ask them to send replacement parts when hardware breaks. 99:59:59.999 --> 99:59:59.999 We use server-grade hardware, 99:59:59.999 --> 99:59:59.999 currently most of the machines are HP machines: 99:59:59.999 --> 99:59:59.999 80 DL360 DL580 99:59:59.999 --> 99:59:59.999 [Tollef]: They work quite well, 99:59:59.999 --> 99:59:59.999 I think we're mostly done with that transition. 99:59:59.999 --> 99:59:59.999 It turns out having actual servers, 99:59:59.999 --> 99:59:59.999 rather than something someone put under a desk and forgot about 99:59:59.999 --> 99:59:59.999 actually makes for less pain and more uptime 99:59:59.999 --> 99:59:59.999 [zobel]: We try to consolidate the amount of data centres 99:59:59.999 --> 99:59:59.999 we are having core services running in. 99:59:59.999 --> 99:59:59.999 So currently we have like 3 to 5 data centres, 99:59:59.999 --> 99:59:59.999 we have quite a lot of services running in. 99:59:59.999 --> 99:59:59.999 that's: manda; bytemark; grnet, still a little bit; 99:59:59.999 --> 99:59:59.999 also OSUOSL, UBC. 99:59:59.999 --> 99:59:59.999 [Tollef]: UBC-ECE 99:59:59.999 --> 99:59:59.999 Yes. We also have some other places with fewer machines, 99:59:59.999 --> 99:59:59.999 but since it's often painful to have a single machine 99:59:59.999 --> 99:59:59.999 in a location, we try to avoid that. 99:59:59.999 --> 99:59:59.999 It's kind of a tradeoff, 99:59:59.999 --> 99:59:59.999 you want to have enough locations that you resilience 99:59:59.999 --> 99:59:59.999 but you don't want to have so many that you basically have 2 machines everywhere, 99:59:59.999 --> 99:59:59.999 and each time there is a problem 99:59:59.999 --> 99:59:59.999 you have to deal with somebody you haven't spoken to in 2 years 99:59:59.999 --> 99:59:59.999 because that was when the last problem occurred. 99:59:59.999 --> 99:59:59.999 [zobel]: For the core services we are currently using ganeti for virtualization 99:59:59.999 --> 99:59:59.999 which is some sort of KVM-based virtualization framework. 99:59:59.999 --> 99:59:59.999 [Tollef]: It's a cluster manager which came out of Google, 99:59:59.999 --> 99:59:59.999 and which works really well. 99:59:59.999 --> 99:59:59.999 Its target is clusters from 1 to 50 machines, 99:59:59.999 --> 99:59:59.999 free software of course. 99:59:59.999 --> 99:59:59.999 [zobel]: It works very well for us. 99:59:59.999 --> 99:59:59.999 The target where I try to work on in the last few months is 99:59:59.999 --> 99:59:59.999 the single sign on framework web applications. 99:59:59.999 --> 99:59:59.999 Thankfully together with Enrico, who helped quite a lot with that. 99:59:59.999 --> 99:59:59.999 Rewritten the ugly perl code I wrote to a python django framework 99:59:59.999 --> 99:59:59.999 We hope to be able to provide single sign on, 99:59:59.999 --> 99:59:59.999 also for non debian.org web services. 99:59:59.999 --> 99:59:59.999 Which with the current software we use for debian.org, 99:59:59.999 --> 99:59:59.999 didn't work out for security reasons. 99:59:59.999 --> 99:59:59.999 So let's see where we stand in 2 years with SSO for web stuff. 99:59:59.999 --> 99:59:59.999 [Tollef]: We had a problem earlier this year, 99:59:59.999 --> 99:59:59.999 that the backup server we had would die and then die and then die, 99:59:59.999 --> 99:59:59.999 with various problems: It claimed to have hard drive errors, 99:59:59.999 --> 99:59:59.999 but it looked more like controller errors and so on. 99:59:59.999 --> 99:59:59.999 Obviously, running without backups isn't a terribly good idea. 99:59:59.999 --> 99:59:59.999 We bootstrapped another backup server but 99:59:59.999 --> 99:59:59.999 it was running at the bytemark data centre 99:59:59.999 --> 99:59:59.999 and because we have many other services hosted there, 99:59:59.999 --> 99:59:59.999 that's not a very good situation 99:59:59.999 --> 99:59:59.999 just because if something happens at that data centre 99:59:59.999 --> 99:59:59.999 and it burns down, suddenly we've lost both the backups 99:59:59.999 --> 99:59:59.999 and the services being backed up. 99:59:59.999 --> 99:59:59.999 So a month ago, we got a new machine 99:59:59.999 --> 99:59:59.999 it's hosted at DGI? 99:59:59.999 --> 99:59:59.999 [zobel]: DGI, in Dusseldorf. 99:59:59.999 --> 99:59:59.999 [Tollef]: and it's happily chugging along making backups. 99:59:59.999 --> 99:59:59.999 We're currently using Bacula for backups, 99:59:59.999 --> 99:59:59.999 and it's working okay, 99:59:59.999 --> 99:59:59.999 we're having some interesting problems with scheduling of backups 99:59:59.999 --> 99:59:59.999 so we're probably going to need to do something to fix things there. 99:59:59.999 --> 99:59:59.999 [zobel]: Luca is doing the ud-ldap rewrite, 99:59:59.999 --> 99:59:59.999 as already mentioned earlier, we need helping hands there. 99:59:59.999 --> 99:59:59.999 I think Paul and Peter are working on the snapshot infrastructure, 99:59:59.999 --> 99:59:59.999 giving especially the QA integration for snapshot. 99:59:59.999 --> 99:59:59.999 [Tollef]: We had a donation from Leaseweb, earlier this year. 99:59:59.999 --> 99:59:59.999 Similar to the backups, it turns out servers when they grow big enough 99:59:59.999 --> 99:59:59.999 you get lots of disk dying... 99:59:59.999 --> 99:59:59.999 Linux isn't terribly good at handling this when you get enough of your disks dying. 99:59:59.999 --> 99:59:59.999 We had one machine that died, 99:59:59.999 --> 99:59:59.999 with controller failure again! 99:59:59.999 --> 99:59:59.999 We tried to revive it, it wasn't really successful. 99:59:59.999 --> 99:59:59.999 So we ended up getting this donation from Leaseweb 99:59:59.999 --> 99:59:59.999 and we then have a small cluster of machines in their data centre 99:59:59.999 --> 99:59:59.999 [zobel]: snapshot is currently about 23 terabytes 99:59:59.999 --> 99:59:59.999 [Tollef]: something like that. 99:59:59.999 --> 99:59:59.999 [zobel]: 30 terabytes in size 99:59:59.999 --> 99:59:59.999 Which is currently the biggest 'archive' we maintain. 99:59:59.999 --> 99:59:59.999 We tried to roll out SSL everywhere in the past 99:59:59.999 --> 99:59:59.999 [Tollef]: It's been something we wanted to do for a while, 99:59:59.999 --> 99:59:59.999 to enable HTTPS and so on everywhere, 99:59:59.999 --> 99:59:59.999 even on public and open resources. 99:59:59.999 --> 99:59:59.999 It felt, with the - it wasn't really triggered by 99:59:59.999 --> 99:59:59.999 but it was in the same way as the Snowden things. 99:59:59.999 --> 99:59:59.999 It was like we should probably actually move forward with this, 99:59:59.999 --> 99:59:59.999 because it turns out there are entirely too many people 99:59:59.999 --> 99:59:59.999 who are TCP dumping too much. 99:59:59.999 --> 99:59:59.999 [single applaud] 99:59:59.999 --> 99:59:59.999 We're pushing for more SSL everywhere. 99:59:59.999 --> 99:59:59.999 There was a little bit of controversy around this when we did it to people.debian.org 99:59:59.999 --> 99:59:59.999 because it turns out that ??? had some problems with verifying the certificate and so on. 99:59:59.999 --> 99:59:59.999 It's not a completely uncontroversial and smooth move but 99:59:59.999 --> 99:59:59.999 sometimes you need to make a little bit of sacrifice 99:59:59.999 --> 99:59:59.999 to actually get the security we want. 99:59:59.999 --> 99:59:59.999 Related to that also, we pushed some bits towards using CDNs, 99:59:59.999 --> 99:59:59.999 which also are interesting in the context of SSL, 99:59:59.999 --> 99:59:59.999 because you have to give your cert to somebody else, 99:59:59.999 --> 99:59:59.999 there is a tradeoff there. 99:59:59.999 --> 99:59:59.999 You kind of have to trust your provider there. 99:59:59.999 --> 99:59:59.999 [zobel]: What we are also doing due to the fact that 99:59:59.999 --> 99:59:59.999 we got a huge donation from Bytemark, 99:59:59.999 --> 99:59:59.999 I think one and a half years ago? 99:59:59.999 --> 99:59:59.999 It was a full blade centre and 6 MSA shelves 99:59:59.999 --> 99:59:59.999 [Tollef]: 3 chassis plus 3 ?? 99:59:59.999 --> 99:59:59.999 [zobel]: Currently we still have some spare CPU cycles left at Bytemark. 99:59:59.999 --> 99:59:59.999 Currently setting up Openstack at the Bytemark datacentre for one or two 99:59:59.999 --> 99:59:59.999 blades 99:59:59.999 --> 99:59:59.999 In the end, the idea is that Debian Developers can start VMs there, themselves 99:59:59.999 --> 99:59:59.999 Similar to the VMs we are using for our infrastructure 99:59:59.999 --> 99:59:59.999 So we can more easily migrate debian.net services to debian.org services 99:59:59.999 --> 99:59:59.999 giving you some sort of common infrastructure we use on debian 99:59:59.999 --> 99:59:59.999 So you can help us to migrate services, or we can help you to migrate 99:59:59.999 --> 99:59:59.999 from your hardware to the Debian infrastructure 99:59:59.999 --> 99:59:59.999 [Tollef]: Part of the reason that is: 99:59:59.999 --> 99:59:59.999 it turns out running various half-official services 99:59:59.999 --> 99:59:59.999 on peoples' home machines and co-lo machines 99:59:59.999 --> 99:59:59.999 isn't a terribly good idea. 99:59:59.999 --> 99:59:59.999 Often they'll run for years and then somebody will get bored 99:59:59.999 --> 99:59:59.999 or they'll quit debian or they'll go broke, 99:59:59.999 --> 99:59:59.999 the machine will burn down... something will happen, 99:59:59.999 --> 99:59:59.999 the services disappear and people get upset. 99:59:59.999 --> 99:59:59.999 So we try to talk any services that are half-official 99:59:59.999 --> 99:59:59.999 and we would rather move them onto debian.org hardware 99:59:59.999 --> 99:59:59.999 So if you have a service which is kind of a half-official thing 99:59:59.999 --> 99:59:59.999 and you want to make it more official, 99:59:59.999 --> 99:59:59.999 and actually have somebody do the base OS maintenance for you 99:59:59.999 --> 99:59:59.999 so you don't have to worry about that, 99:59:59.999 --> 99:59:59.999 then please come and talk to us. 99:59:59.999 --> 99:59:59.999 We're quite happy to provide you we reasonable VMs. 99:59:59.999 --> 99:59:59.999 [zobel]: How to contact us. 99:59:59.999 --> 99:59:59.999 There are several mailing lists, 99:59:59.999 --> 99:59:59.999 there is a debian-admin@lists.debian.org list where we discussed that this 99:59:59.999 --> 99:59:59.999 mailing list will more or less be open to every Debian Developer. 99:59:59.999 --> 99:59:59.999 Debian devel people can subscribe to that mailing list aswell. 99:59:59.999 --> 99:59:59.999 There's dsa@debian.org email address, 99:59:59.999 --> 99:59:59.999 which we changed due to the fact there was 99:59:59.999 --> 99:59:59.999 a debian-admin@debian.org and there was quite a lot of confusion 99:59:59.999 --> 99:59:59.999 about the debian-admin@lists and the debian-admin@debian.org email address. 99:59:59.999 --> 99:59:59.999 So we decided to move to a new email alias which is dsa@debian.org 99:59:59.999 --> 99:59:59.999 You can hang around on IRC as mentioned earlier, in the #debian-admin channel 99:59:59.999 --> 99:59:59.999 Feel free to join there if you have any issues, 99:59:59.999 --> 99:59:59.999 just raise them and talk to us. 99:59:59.999 --> 99:59:59.999 [Tollef]: Like any people in any teams in Debian, 99:59:59.999 --> 99:59:59.999 we obviously have more things to do than we actually have time for. 99:59:59.999 --> 99:59:59.999 So help is very much appreciated. 99:59:59.999 --> 99:59:59.999 Getting help with sysadmin tasks is kind of an interesting challenge 99:59:59.999 --> 99:59:59.999 because you can't just give out root to all debian.org machines 99:59:59.999 --> 99:59:59.999 to somebody who shows up and goes: 99:59:59.999 --> 99:59:59.999 "I would like to rewrite your authentication infrastructure" 99:59:59.999 --> 99:59:59.999 However, since we keep the puppet repository and so on, in git 99:59:59.999 --> 99:59:59.999 it's at least possible for people to get in and contribute. 99:59:59.999 --> 99:59:59.999 Send us patches, show up, discuss things. 99:59:59.999 --> 99:59:59.999 If you think something can be improved, 99:59:59.999 --> 99:59:59.999 that's quite likely and we would be happy to discuss how to do that. 99:59:59.999 --> 99:59:59.999 Documentation is always welcome, 99:59:59.999 --> 99:59:59.999 there is a bit of documentation for things like debile.debian.org and so on. 99:59:59.999 --> 99:59:59.999 But more is always welcome. 99:59:59.999 --> 99:59:59.999 Also just hanging out on IRC, answering people's questions 99:59:59.999 --> 99:59:59.999 is often surprisingly useful. 99:59:59.999 --> 99:59:59.999 [zobel]: We also really want to grow the team, 99:59:59.999 --> 99:59:59.999 from the seven person team we are currently 99:59:59.999 --> 99:59:59.999 We had, a few months ago, spoken to a Debian Developer who 99:59:59.999 --> 99:59:59.999 - is he here in the room? Might be! - 99:59:59.999 --> 99:59:59.999 who said he currently does not want to become a member of the DSA team due to 99:59:59.999 --> 99:59:59.999 the fact he has too many other things, other duties in Debian. 99:59:59.999 --> 99:59:59.999 Just talk to us and help us, and at one point we'd probably get annoying with 99:59:59.999 --> 99:59:59.999 doing too many tasks for you, so we just give out the root access then. 99:59:59.999 --> 99:59:59.999 [Tollef]: It's how it usually works in Debian, 99:59:59.999 --> 99:59:59.999 at some point you've contributed enough, 99:59:59.999 --> 99:59:59.999 that's it's more annoying to merge your patches 99:59:59.999 --> 99:59:59.999 and review them than to just give you access. 99:59:59.999 --> 99:59:59.999 So that happens. 99:59:59.999 --> 99:59:59.999 [zobel]: I think that's all about the slides, 99:59:59.999 --> 99:59:59.999 so just ask... 99:59:59.999 --> 99:59:59.999 [Tollef]: questions! 99:59:59.999 --> 99:59:59.999 [question1]: I guess this is more DSA 99:59:59.999 --> 99:59:59.999 the listmaster pieces, are they in puppet as well? 99:59:59.999 --> 99:59:59.999 [zobel]: No, the list stuff is not in puppet. 99:59:59.999 --> 99:59:59.999 The exim config we are using on debian.org machines is in puppet 99:59:59.999 --> 99:59:59.999 But lists uses postfix. 99:59:59.999 --> 99:59:59.999 Alex Wirt is also sitting here in lecture room, 99:59:59.999 --> 99:59:59.999 he could easily your questions for lists.debian.org 99:59:59.999 --> 99:59:59.999 More questions! 99:59:59.999 --> 99:59:59.999 No more questions? 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 [question2]: As one of the local admins for a bunch of buildds, 99:59:59.999 --> 99:59:59.999 I know that every now and again we get asked for stuff opening up, more ports 99:59:59.999 --> 99:59:59.999 because we're one of those evil places with a firewall, even for the DMZ. 99:59:59.999 --> 99:59:59.999 Do you actually have a central list of all of things that you want to be able 99:59:59.999 --> 99:59:59.999 to get access to, you know? 99:59:59.999 --> 99:59:59.999 That kind of thing would be awesome, 99:59:59.999 --> 99:59:59.999 that I could just point, say the ARM network sysadmins at 99:59:59.999 --> 99:59:59.999 instead of every now and again having to say: 99:59:59.999 --> 99:59:59.999 "Oh and we need this extra thing" 99:59:59.999 --> 99:59:59.999 and then backwards are forwards, because their immediate response is: 99:59:59.999 --> 99:59:59.999 "Well, why?" 99:59:59.999 --> 99:59:59.999 If we can give them a list and 99:59:59.999 --> 99:59:59.999 just give them a notification that 99:59:59.999 --> 99:59:59.999 there are few new things we'd like, 99:59:59.999 --> 99:59:59.999 it might go easier. 99:59:59.999 --> 99:59:59.999 [Tollef]: I don't think we have a list as such. 99:59:59.999 --> 99:59:59.999 What we do have is our firewall config is ?? 99:59:59.999 --> 99:59:59.999 So we have a list of things we want to be able to accept on various servers, 99:59:59.999 --> 99:59:59.999 even though we don't have a list as in "Go to this web page and here you have 99:59:59.999 --> 99:59:59.999 these ports and their justification", we can generate that. 99:59:59.999 --> 99:59:59.999 So yeah that's a good idea, we should do something like that. 99:59:59.999 --> 99:59:59.999 [question3]: Can you explain more about your backup system? 99:59:59.999 --> 99:59:59.999 I think you covered it very briefly. 99:59:59.999 --> 99:59:59.999 [Tollef]: We have bacula, it's a centralised backup system using, 99:59:59.999 --> 99:59:59.999 it's kind of mix of push and pull, in that you have a central director 99:59:59.999 --> 99:59:59.999 which tells the machines that are to be backed up, 99:59:59.999 --> 99:59:59.999 that you are now going to be backing your things up 99:59:59.999 --> 99:59:59.999 to this storage daemon over here. 99:59:59.999 --> 99:59:59.999 Then it also tells the storage daemon, that please expect a connection from 99:59:59.999 --> 99:59:59.999 this machine. 99:59:59.999 --> 99:59:59.999 We run the director, which is this central component, 99:59:59.999 --> 99:59:59.999 that runs in adm in Bytemark. 99:59:59.999 --> 99:59:59.999 The actual storage is at DGI 99:59:59.999 --> 99:59:59.999 and obviously the various machines being backed up are everywhere. 99:59:59.999 --> 99:59:59.999 One of the painful things about bacula is that it thinks, 99:59:59.999 --> 99:59:59.999 even though we are backing up to hard drives, 99:59:59.999 --> 99:59:59.999 it still thinks we are actually backing up to tape drives 99:59:59.999 --> 99:59:59.999 and that makes for, the nicest thing about hard drives is that generally you 99:59:59.999 --> 99:59:59.999 don't really have seek time in the same way you have seek time on tapes. 99:59:59.999 --> 99:59:59.999 So you don't care about rebinding tapes and switching to a different tape, 99:59:59.999 --> 99:59:59.999 that's called "opening another file" and it doesn't take very long. 99:59:59.999 --> 99:59:59.999 We also have the problem that bacula doesn't have the concept of- 99:59:59.999 --> 99:59:59.999 if you look at a backup system like backuppc, 99:59:59.999 --> 99:59:59.999 it never does full backups, it will only do incremental backups 99:59:59.999 --> 99:59:59.999 and then has a hardlink farm. 99:59:59.999 --> 99:59:59.999 bacula will do a full backup, then incrementals 99:59:59.999 --> 99:59:59.999 then a full backup then incrementals. 99:59:59.999 --> 99:59:59.999 This makes less sense when you have hard drives 99:59:59.999 --> 99:59:59.999 than when you have tapes. 99:59:59.999 --> 99:59:59.999 Also the scheduler isn't very smart, 99:59:59.999 --> 99:59:59.999 if it can't back up a machine for some reason 99:59:59.999 --> 99:59:59.999 then instead of rescheduling that back up 99:59:59.999 --> 99:59:59.999 it will, depending on how you configure it, 99:59:59.999 --> 99:59:59.999 it will then just skip it. 99:59:59.999 --> 99:59:59.999 Some of our hosts actually don't have that good connections, 99:59:59.999 --> 99:59:59.999 so when you're trying to do a full backup, 99:59:59.999 --> 99:59:59.999 which can take 24 hours, 99:59:59.999 --> 99:59:59.999 you really don't want that TCP stream to be disconnected 99:59:59.999 --> 99:59:59.999 because then you've lost that full backup. 99:59:59.999 --> 99:59:59.999 And also it ends up batching the full backups so they're very clustered 99:59:59.999 --> 99:59:59.999 rather than being nicely spread out. 99:59:59.999 --> 99:59:59.999 One of the things we're looking at is writing a different scheduler for bacula 99:59:59.999 --> 99:59:59.999 just to basically tell it: "please do a full backup of this host, now." 99:59:59.999 --> 99:59:59.999 rather than relying on the built-in scheduler. 99:59:59.999 --> 99:59:59.999 [zobel]: (inaudible) 99:59:59.999 --> 99:59:59.999 [question3]: I'm the maintainer of a package called 'bup' 99:59:59.999 --> 99:59:59.999 It's not a full-fledged backup system with a scheduler, et cetera 99:59:59.999 --> 99:59:59.999 but it does use for its backend, git packfiles rather than tapes 99:59:59.999 --> 99:59:59.999 If you're interested in git, maybe some interesting technology to take a look at 99:59:59.999 --> 99:59:59.999 [Tollef]: Look time I looked at bup, it didn't actually support expiring backups 99:59:59.999 --> 99:59:59.999 Which makes for some pain. 99:59:59.999 --> 99:59:59.999 [question3]: There are some workarounds, 99:59:59.999 --> 99:59:59.999 but it's one of the limitations currently 99:59:59.999 --> 99:59:59.999 [Tollef]: For us, that would mean we would run into- 99:59:59.999 --> 99:59:59.999 I'm sure ?? or ?? would be very happy but I'm not sure that 99:59:59.999 --> 99:59:59.999 our treasure would be as happy. 99:59:59.999 --> 99:59:59.999 We need the ability to expire backups, 99:59:59.999 --> 99:59:59.999 just because we don't have infinite sized hard drives 99:59:59.999 --> 99:59:59.999 and backups are actually quite big. 99:59:59.999 --> 99:59:59.999 [zobel]: One of the other issues with bacula is that currently all of the full 99:59:59.999 --> 99:59:59.999 backups run at the same time 99:59:59.999 --> 99:59:59.999 so we run into some sort of ?? limitations 99:59:59.999 --> 99:59:59.999 which it's not an issue but it's annoying that 99:59:59.999 --> 99:59:59.999 all machines are doing the full backups at the same time. 99:59:59.999 --> 99:59:59.999 Any else questions? 99:59:59.999 --> 99:59:59.999 [question4]: You touched on it earlier, Single Sign On 99:59:59.999 --> 99:59:59.999 What services are next for that? 99:59:59.999 --> 99:59:59.999 [Tollef]: Don't run away from the mic! 99:59:59.999 --> 99:59:59.999 [Enrico]: I'll answer that as far as I know 99:59:59.999 --> 99:59:59.999 many people may have different plans. 99:59:59.999 --> 99:59:59.999 Single Sign On is currently using DACS, 99:59:59.999 --> 99:59:59.999 which I would suggest against, in general... 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Having looked deeply into it, 99:59:59.999 --> 99:59:59.999 it probably seemed like a good idea at the time 99:59:59.999 --> 99:59:59.999 but the internet moved in a different direction. 99:59:59.999 --> 99:59:59.999 But DACS is still useful because it's an apache thing 99:59:59.999 --> 99:59:59.999 so one can just put a directory of static files under DACS 99:59:59.999 --> 99:59:59.999 and that can be done quite reasonably simply. 99:59:59.999 --> 99:59:59.999 At DebConf I want to discuss with the currently available DSAs 99:59:59.999 --> 99:59:59.999 about finishing the DACS setup, putting the basic stuff in puppet 99:59:59.999 --> 99:59:59.999 and making a guide for deploying new stuff. 99:59:59.999 --> 99:59:59.999 Any Debian Developer that deploys services can set up DACS 99:59:59.999 --> 99:59:59.999 reasonably easily, but the way that I see we should go in the future 99:59:59.999 --> 99:59:59.999 is OAuth 2, which is what we are using for the conference thing. 99:59:59.999 --> 99:59:59.999 Because that is a bit more like a standard that may work now 99:59:59.999 --> 99:59:59.999 and which hopefully supports log out! 99:59:59.999 --> 99:59:59.999 [laughs] 99:59:59.999 --> 99:59:59.999 which DACS does not do very well. 99:59:59.999 --> 99:59:59.999 I have not studied OAuth 2, so I'm not interested, 99:59:59.999 --> 99:59:59.999 it won't be me who does it. 99:59:59.999 --> 99:59:59.999 If any of you knows OAuth 2 and wants to sit down with me and explain it step 99:59:59.999 --> 99:59:59.999 by step during DebConf, then please I would like to migrate NM and Debian 99:59:59.999 --> 99:59:59.999 Contributors to OAuth 2, if at all possible. 99:59:59.999 --> 99:59:59.999 But I do want to understand the protocol before I touch it. 99:59:59.999 --> 99:59:59.999 So the direction as far as I'm concerned, will be OAuth 2. 99:59:59.999 --> 99:59:59.999 We may get stuck with DACS, because it integrates with apache 99:59:59.999 --> 99:59:59.999 but I'm not comfortable with it and there are too many hacky things 99:59:59.999 --> 99:59:59.999 to make things work as expected. 99:59:59.999 --> 99:59:59.999 I wish, my personal dream would be to at some move to OAuth 2 and then 99:59:59.999 --> 99:59:59.999 replace DACS with just an OAuth 2 provider. 99:59:59.999 --> 99:59:59.999 [zobel]: Other limitations of our current DACS set up 99:59:59.999 --> 99:59:59.999 is that it only works for the debian.org domain 99:59:59.999 --> 99:59:59.999 otherwise we would need to give out credentials, 99:59:59.999 --> 99:59:59.999 there is some jurisdiction key and federation key, 99:59:59.999 --> 99:59:59.999 so we would need to give out access to them to the debian.net services. 99:59:59.999 --> 99:59:59.999 That's one of the other limitations of our current DACS set up. 99:59:59.999 --> 99:59:59.999 So probably OAuth 2 might be the way to go. 99:59:59.999 --> 99:59:59.999 But in the end it's up to you and 99:59:59.999 --> 99:59:59.999 the Debian Developers helping to extend the single sign on. 99:59:59.999 --> 99:59:59.999 [Enrico]: As new DACS services, ?? set up something that uses DACS 99:59:59.999 --> 99:59:59.999 [zobel]: It's a new PTS implementation 99:59:59.999 --> 99:59:59.999 I think he just wants to if a person is logged in 99:59:59.999 --> 99:59:59.999 then he can modify some news on the new PTS implementation and so on. 99:59:59.999 --> 99:59:59.999 [Enrico]: One good thing with DACS at the moment, is that login is optional 99:59:59.999 --> 99:59:59.999 and it totally supports serving a site as it is 99:59:59.999 --> 99:59:59.999 and if one is logged in, in single sign on then more stuff can happen. 99:59:59.999 --> 99:59:59.999 [zobel]: I think OAuth 2 is a better thing for the wiki to do. 99:59:59.999 --> 99:59:59.999 [Enrico]: Does Moin does OAuth 2? 99:59:59.999 --> 99:59:59.999 [Steve]: (inaudible) 99:59:59.999 --> 99:59:59.999 [zobel]: I think I looked that up a few months ago and I think it supports OAuth 2. 99:59:59.999 --> 99:59:59.999 [Enrico]: DACS will give you a remote user variable, so in theory it's easy 99:59:59.999 --> 99:59:59.999 but if it does OAuth 2, then it's more future proof in my opinion. 99:59:59.999 --> 99:59:59.999 [Steve]: The fun thing with the wiki as well 99:59:59.999 --> 99:59:59.999 I was going touch about on this in my Wiki and Web BoF 99:59:59.999 --> 99:59:59.999 (see advertising too!) 99:59:59.999 --> 99:59:59.999 We've also currently got, like thousands of existing user accounts. 99:59:59.999 --> 99:59:59.999 Now obviously for people who've already got Alioth or a Debian LDAP account 99:59:59.999 --> 99:59:59.999 then we will encourage people to merge and just move over to those 99:59:59.999 --> 99:59:59.999 but for the many thousands of others who haven't, 99:59:59.999 --> 99:59:59.999 we're going to have to come up with something. 99:59:59.999 --> 99:59:59.999 I don't know what that is. 99:59:59.999 --> 99:59:59.999 [Tollef]: I don't have any response to that on the spot. 99:59:59.999 --> 99:59:59.999 It's tempting to say, they can just get themselves an Alioth account. 99:59:59.999 --> 99:59:59.999 Some people might be upset at that answer. 99:59:59.999 --> 99:59:59.999 I guess there's also the question of how many 99:59:59.999 --> 99:59:59.999 of these accounts are actually active? 99:59:59.999 --> 99:59:59.999 Rather than somebody registered back in 2005 99:59:59.999 --> 99:59:59.999 and haven't used the account since. 99:59:59.999 --> 99:59:59.999 [Enrico]: I'd be happy to have a conversation about this during DebConf. 99:59:59.999 --> 99:59:59.999 Because for Debian Contributors, 99:59:59.999 --> 99:59:59.999 I require to have an Alioth account to get credited in site 99:59:59.999 --> 99:59:59.999 because I don't want to have a user database in Debian Contributors. 99:59:59.999 --> 99:59:59.999 It may be too much of a strict requirement, 99:59:59.999 --> 99:59:59.999 it may be that we just document that if you do 99:59:59.999 --> 99:59:59.999 anything in Debian you get an Alioth account. 99:59:59.999 --> 99:59:59.999 Let's talk about it, separately. 99:59:59.999 --> 99:59:59.999 [Tollef]: In that case, I think we need to have a conversation with my other hat, 99:59:59.999 --> 99:59:59.999 which is that hat of various other people, which is the Alioth admin hat. 99:59:59.999 --> 99:59:59.999 [Steve L.]: As the person who inflicted Alioth logins on everybody for DebConf 99:59:59.999 --> 99:59:59.999 this year, I have been getting feedback that, in particular the sign up 99:59:59.999 --> 99:59:59.999 process for Alioth is a bit of an obstacle. 99:59:59.999 --> 99:59:59.999 So there are a few things there, which I think we should talk about 99:59:59.999 --> 99:59:59.999 streamlining. 99:59:59.999 --> 99:59:59.999 As the person who decided that we were, for this year, moving away from Penta 99:59:59.999 --> 99:59:59.999 and moving to Summit, no I did not want to have an authentication database. 99:59:59.999 --> 99:59:59.999 I didn't want password hashes in Summit 99:59:59.999 --> 99:59:59.999 and so I said yes, we're going to have figure out how to hook this up to 99:59:59.999 --> 99:59:59.999 Debian SSO and the consequence of that was, yes: 99:59:59.999 --> 99:59:59.999 we had the Debian SSO which was only available to Debian Developers 99:59:59.999 --> 99:59:59.999 Alioth was the other database that was out there 99:59:59.999 --> 99:59:59.999 and so I guess, my fault, 99:59:59.999 --> 99:59:59.999 I apologise for anyone that was stressed about the rollout of that 99:59:59.999 --> 99:59:59.999 because I didn't entirely co-ordinate with all of the parties ahead of time 99:59:59.999 --> 99:59:59.999 but I think it's hanging together fairly well. 99:59:59.999 --> 99:59:59.999 But we should talk sometime this week about where we should go forward with 99:59:59.999 --> 99:59:59.999 that and if alioth is the right authentication provider. 99:59:59.999 --> 99:59:59.999 But I think it's important we agree there be an authentication provider, 99:59:59.999 --> 99:59:59.999 for these kinds of services, whether that lives in Alioth or somewhere else. 99:59:59.999 --> 99:59:59.999 [Enrico]: With a flat namespace. 99:59:59.999 --> 99:59:59.999 [Steve L.]: With a flat username space, yes. 99:59:59.999 --> 99:59:59.999 Which we kind of have, today 99:59:59.999 --> 99:59:59.999 [Enrico]: (inaudible) 99:59:59.999 --> 99:59:59.999 [Steve L.]: The way OAuth provides them is 99:59:59.999 --> 99:59:59.999 you get the domain name with it 99:59:59.999 --> 99:59:59.999 So in fact all Debian Developers have two different- 99:59:59.999 --> 99:59:59.999 It's a "flat namespace" and DDs all have two they can use. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 [zobel]: More questions? 99:59:59.999 --> 99:59:59.999 [question5]: You mentioned that all our hosting is sponsored by the hosts 99:59:59.999 --> 99:59:59.999 and we get some hardware donations at least. 99:59:59.999 --> 99:59:59.999 I think we, we buy some, as well, don't we? 99:59:59.999 --> 99:59:59.999 My question isn't really about that, 99:59:59.999 --> 99:59:59.999 it's about how much support do we get- 99:59:59.999 --> 99:59:59.999 there's 1.5, well 2, tending to 1 hardware manufacturers on the sponsors there 99:59:59.999 --> 99:59:59.999 -how much support do we get from them doing interesting stuff. 99:59:59.999 --> 99:59:59.999 I'm thinking, you mentioned we get fairly regular controller failures on some of our hardware 99:59:59.999 --> 99:59:59.999 and all of the sponsors we've got have got nice but hard to set up multipath things. 99:59:59.999 --> 99:59:59.999 It seems to me it would be interesting and for them 99:59:59.999 --> 99:59:59.999 to set things up like that, on the Debian infrastructure. 99:59:59.999 --> 99:59:59.999 Is that kind of thing possible, or? 99:59:59.999 --> 99:59:59.999 [Tollef]: Yeah, so we do have that in some places 99:59:59.999 --> 99:59:59.999 Like the Bytemark set-up, the UBC-ECE set-up and so on 99:59:59.999 --> 99:59:59.999 There we have a SAN, we have a bunch of machines 99:59:59.999 --> 99:59:59.999 and either it's doing SATA or it's doing Fibre Channel 99:59:59.999 --> 99:59:59.999 [zobel]: iSCSI 99:59:59.999 --> 99:59:59.999 [Tollef]: iSCSI, as well, yeah. 99:59:59.999 --> 99:59:59.999 So we do have a bunch of that, 99:59:59.999 --> 99:59:59.999 the problem is if you want to do data storage 99:59:59.999 --> 99:59:59.999 where you have available 25 terabytes 99:59:59.999 --> 99:59:59.999 and you want to do that on a SAN, 99:59:59.999 --> 99:59:59.999 that's very not cheap, that's really quite expensive. 99:59:59.999 --> 99:59:59.999 That's a reason why those machines with special storage requirements, 99:59:59.999 --> 99:59:59.999 like backups and snapshot, basically, they're different. 99:59:59.999 --> 99:59:59.999 That's also why they need those two machines, 99:59:59.999 --> 99:59:59.999 they have like 5 controllers each, 99:59:59.999 --> 99:59:59.999 that's why they are different in that regard. 99:59:59.999 --> 99:59:59.999 We do get a bunch of sponsorship from the hardware vendors, 99:59:59.999 --> 99:59:59.999 we usually buy HP gear, mostly because we've had good experience with it 99:59:59.999 --> 99:59:59.999 and it generally works 99:59:59.999 --> 99:59:59.999 [zobel]: We had good connections at HP. 99:59:59.999 --> 99:59:59.999 [Tollef]: We also had historically good connections, 99:59:59.999 --> 99:59:59.999 they've been good about giving us hardware in the past 99:59:59.999 --> 99:59:59.999 they are happy to sponsor Debian and DebConf 99:59:59.999 --> 99:59:59.999 both in actual terms of money given to us, 99:59:59.999 --> 99:59:59.999 but also in terms of pretty nice prices. 99:59:59.999 --> 99:59:59.999 I don't think we've actually approached them about saying, 99:59:59.999 --> 99:59:59.999 "could you please give us this enormously expensive piece of hardware?" 99:59:59.999 --> 99:59:59.999 It's often hard for them to give that away, 99:59:59.999 --> 99:59:59.999 because it has to come out of somebodies' budget 99:59:59.999 --> 99:59:59.999 and somehow they don't have large SANs just hidden under their desks. 99:59:59.999 --> 99:59:59.999 [zobel]: More questions? Criticism? 99:59:59.999 --> 99:59:59.999 [question6]: Hi, I was just curious about your mail infrastructure. 99:59:59.999 --> 99:59:59.999 It doesn't look like you use DKIM or SPF, or DMARC records. 99:59:59.999 --> 99:59:59.999 Do you have plans for any of that? 99:59:59.999 --> 99:59:59.999 [Tollef]: There's been some experimentation with domain keys. 99:59:59.999 --> 99:59:59.999 Luca has been playing with that. 99:59:59.999 --> 99:59:59.999 There's this interesting ?? 99:59:59.999 --> 99:59:59.999 ?? we generally don't provide outgoing SMTP for random people, 99:59:59.999 --> 99:59:59.999 because that's painful. 99:59:59.999 --> 99:59:59.999 [zobel]: We are not a mail provider. 99:59:59.999 --> 99:59:59.999 [Tollef]: Yes, obviously you get a @debian.org account 99:59:59.999 --> 99:59:59.999 You get incoming email, which we then forward onto somewhere 99:59:59.999 --> 99:59:59.999 where you'll hopefully remember to update that when that account expires 99:59:59.999 --> 99:59:59.999 rather than giving us bounces. 99:59:59.999 --> 99:59:59.999 That's a big change, which we forgot to mention 99:59:59.999 --> 99:59:59.999 is that we are actually in the process of reworking the entire way we do mail 99:59:59.999 --> 99:59:59.999 We have drastically reduced the number of incoming mail servers, 99:59:59.999 --> 99:59:59.999 so now most mail now goes to a set of two MXs. 99:59:59.999 --> 99:59:59.999 [zobel]: It will increase in the future. 99:59:59.999 --> 99:59:59.999 At MIT, we will open up one more mailserver. 99:59:59.999 --> 99:59:59.999 [Tollef]: Well, we can. 99:59:59.999 --> 99:59:59.999 Currently we have two and then if there is special mail routing needed, 99:59:59.999 --> 99:59:59.999 it will be routed to the right internal host. 99:59:59.999 --> 99:59:59.999 But most hosts no longer listens for incoming mail from the internet. 99:59:59.999 --> 99:59:59.999 Which is a good thing. 99:59:59.999 --> 99:59:59.999 Not only because it means we don't have to run spamassassin everywhere. 99:59:59.999 --> 99:59:59.999 [zobel]: Peter did this DAME, SMTP thing 99:59:59.999 --> 99:59:59.999 weasel, Peter, wanted to do ?? DAME encryption ?? for outgoing mails. 99:59:59.999 --> 99:59:59.999 So we're experimenting with a bunch of things. 99:59:59.999 --> 99:59:59.999 What I was going to say about domain keys, 99:59:59.999 --> 99:59:59.999 is that because we don't provide outgoing mail servers, 99:59:59.999 --> 99:59:59.999 you need to be able to provide the infrastructure 99:59:59.999 --> 99:59:59.999 with what your key is going to be. 99:59:59.999 --> 99:59:59.999 Luca has been working on some patches to ud-ldap to do this 99:59:59.999 --> 99:59:59.999 so it can show up in DNS and so on. 99:59:59.999 --> 99:59:59.999 So yes, things are happening. 99:59:59.999 --> 99:59:59.999 If you're interested in that, do grab us and we can talk more about it. 99:59:59.999 --> 99:59:59.999 [zobel]: I think we are done because the timer's almost over. 99:59:59.999 --> 99:59:59.999 I have one small announcement to make. 99:59:59.999 --> 99:59:59.999 Luca offered some RIPE NCC ATLASS notes to give away 99:59:59.999 --> 99:59:59.999 and the persons who applied for those notes 99:59:59.999 --> 99:59:59.999 and got into the list of getting those notes, 99:59:59.999 --> 99:59:59.999 please come to me, talk to me directly after the talk 99:59:59.999 --> 99:59:59.999 so I can hand out those notes. 99:59:59.999 --> 99:59:59.999 Because Luca is not here at DebConf14 this year. 99:59:59.999 --> 99:59:59.999 [Anibal]: Any plans to use Yubikeys? 99:59:59.999 --> 99:59:59.999 [Tollef]: I'm port of the maintainer team of yubikey tools in Debian 99:59:59.999 --> 99:59:59.999 I would very much like to use them for some things. 99:59:59.999 --> 99:59:59.999 We need to find out how they should best fit into the infrastructure 99:59:59.999 --> 99:59:59.999 if we're going to do that. 99:59:59.999 --> 99:59:59.999 One thing that has been mentioned is, 99:59:59.999 --> 99:59:59.999 for some cases we want to do actual two-factor. 99:59:59.999 --> 99:59:59.999 Currently there is no two-factor authentication anywhere. 99:59:59.999 --> 99:59:59.999 [zobel]: Help us setting up those infrastructure 99:59:59.999 --> 99:59:59.999 [Tollef]: There are no concrete plans 99:59:59.999 --> 99:59:59.999 but yes, we are very much aware of yubikeys 99:59:59.999 --> 99:59:59.999 I'm kind of looking for good places to put them in. 99:59:59.999 --> 99:59:59.999 I like them. I like both the company and the product. 99:59:59.999 --> 99:59:59.999 They are also quite happy to sponsor free software stuff. 99:59:59.999 --> 99:59:59.999 [zobel]: I think we are done. 99:59:59.999 --> 99:59:59.999 [Tollef]: I think we're out of time 99:59:59.999 --> 99:59:59.999 [zobel]: Thank you for being here. 99:59:59.999 --> 99:59:59.999 [Tollef]: If you have any more questions, grab us afterwards. 99:59:59.999 --> 99:59:59.999 [applause] 99:59:59.999 --> 99:59:59.999