Re: bits from the DPL -- December 2013
On Tue, 21 Jan 2014, Lucas Nussbaum wrote: - [bgupta] work with SPI to enable donations via paypal Note that Debian France has planned to setup that for the Debian project. It would be a small change on this page: https://france.debian.net/galette/plugins/galette-plugin-paypal/paypal_form.php Instead on the current single option we would have two options: * Donation to Debian France * Donation to the Debian project Assuming of course that we are recognized as a trusted organization. [zack] organize a survey of DDs (N: draft questions) What is this about? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122092244.gb27...@x230-buxy.home.ouaza.com
Re: bits from the DPL -- December 2013
On 22/01/14 at 10:22 +0100, Raphael Hertzog wrote: On Tue, 21 Jan 2014, Lucas Nussbaum wrote: - [bgupta] work with SPI to enable donations via paypal Note that Debian France has planned to setup that for the Debian project. It would be a small change on this page: https://france.debian.net/galette/plugins/galette-plugin-paypal/paypal_form.php Instead on the current single option we would have two options: * Donation to Debian France * Donation to the Debian project Assuming of course that we are recognized as a trusted organization. Great! [zack] organize a survey of DDs (N: draft questions) What is this about? This was discussed in http://meetbot.debian.net/debian-dpl/2013/debian-dpl.2013-10-09-16.59.log.html (search for 'survey') Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122094117.ga15...@xanadu.blop.info
Re: Debian services and Debian infrastructure
On 21/01/14 22:09, Tollef Fog Heen wrote: ]] Lucas Nussbaum This mail has been maturing in my in- and outbox for a little while, and it seems like the debate died down until the recent dda mail, so restarting the underlying discussion a bit. Q1. How much should we push for Debian services (services useful to Debian) to be hosted on Debian infrastructure? A lot. Q2. Should we seek other hosting opportunities to ease Debian services development and hosting? Should I authorize the use of Debian money to fund infrastructure not managed by DSA, in the case of a useful service that DSA has been unable to accept in the infrastructure it manages? I don't think so. We've been pretty open with the requirements and the reasoning behind the requirements. If those requirements don't apply for some reason, we should fix the requirements and not work around them. [...] The recurring pattern seems to be that, when DSA is approached to move the service to Debian infrastructure, their evaluation of the service's design results in changes requests or constraints that the service maintainers consider too hard to satisfy. I don't think this is an accurate statement. There have been a few cases where people have shown up with a design we were unable to accomodate and progress have stopped, but in general there's been a tremendous forward progress in what's hosted on DSA infrastructure. I don't think it's ever been easier to get new services hosted on DSA infrastructure in the history of the project. Examples over the last six months are voip, tracker, manpages, contributors, and that's without looking at any of the various static vhosts added. Looking at the SIP implementation a) I've run SIP perfectly well my way (TM) for many years b) when I approached DSA, I discovered there was an alternative to my way c) we discussed, we found common ground, the service is live - the DSA way - which is quite OK, because it is better to have it working in a way that is suitable for a team to support rather than relying on any single individual or vendor As I've mentioned before on this DSA services topic, there are many technical issues that differ from one service to the next, e.g. you can't keep private data, credentials, private keys on some cloud system with a SAN underneath. Copying static web content to mirrors in the cloud is probably quite OK and if some apache log file is lost, who cares - but a Git repository is another thing and it should be on our own hardware. DSA can actually hand some responsibilities out to people to allow them to run things in the cloud but this depends on putting the right interfaces in place and keeping any original data within the official infrastructure. One mechanism we used for RTC is RADIUS (FreeRADIUS server) doing a delegated digest authentication for SIP. With this model, it would be possible to run SIP or TURN servers in the cloud and they would not need a copy of the user database or password hashes. The RADIUS server could potentially be the point where DSA responsibility ends and people can then run other types of service that trust authorized users. If we have to relay a lot of video traffic through TURN, then it would make sense to have local TURN servers in different regions. They keep no local data and can potentially do all access control using RADIUS. Rather than having some awkward discussion about it as a social problem, maybe we can try and look for ways to define such interfaces and give DDs a chance to propose things around them. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dfc3af.30...@pocock.com.au
Re: Debian services and Debian infrastructure
Tollef Fog Heen writes (Re: Debian services and Debian infrastructure): This mail has been maturing in my in- and outbox for a little while, and it seems like the debate died down until the recent dda mail, so restarting the underlying discussion a bit. I agree entirely with what Tollef says in his mail. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21215.63955.964954.101...@chiark.greenend.org.uk
Re: Debian services and Debian infrastructure
Hi, disclaimer I'm only replying on the main point I'd like to make, so I'm limited my quoting to that. Do not take it as agreement or disagreement on the other points -- I just consider them more minor points. /disclaimer On 21/01/14 at 22:09 +0100, Tollef Fog Heen wrote: The recurring pattern seems to be that, when DSA is approached to move the service to Debian infrastructure, their evaluation of the service's design results in changes requests or constraints that the service maintainers consider too hard to satisfy. I don't think this is an accurate statement. There have been a few cases where people have shown up with a design we were unable to accomodate and progress have stopped, but in general there's been a tremendous forward progress in what's hosted on DSA infrastructure. I don't think it's ever been easier to get new services hosted on DSA infrastructure in the history of the project. Examples over the last six months are voip, tracker, manpages, contributors, and that's without looking at any of the various static vhosts added. No process is perfect, and while we should look at the cases where we've failed to reach a conclusion leaving everybody happy, I think it's just as, or even more important to look at the cases where we do have a happy ending. 3. to provide a place to experiment with new services + create a Debian cloud with virtual machines to develop new services (maybe providing manually-created VMs would be enough -- I'm not sure we need a complex infra such as OpenStack). In general, we're quite happy to create VMs for people when they show up with a service they want to deploy, so I think this is quite well covered. It's great that you are quite happy to create VMs for people when they show up with a service they want to deploy. But that's not what I'm talking about. I'm seeking a solution for people who show up with an *idea* they want to *experiment* with. Because: 1) that's when they should engage with DSA so that you have a chance to review/participate in the design, not months later when an unofficial service is up and running; 2) the alternative is that they give up on the idea, or host it themselves, which makes it harder to work collaboratively on the service, and results in services that have a single maintainer (or none, in the end). A strong requirement for such a solution is that it should be easy to get access to a VM, even if the developers do not have any working code yet, or are not even set on all the implementation details of the services (e.g.; a 10-lines description of what the service is about should probably be enough). Another requirement is that the developers should have root access on the virtual machine, so that it's easy to try various options without DSA intervention (remember: this is about developement/beta testing, not about running the service in a super-stable, production mode). Since we discussed that back in June, you added 'providing an OpenStack cloud' on the DSA radar (it noticed that it was mentioned in the 'just starting' category of DSA meeting minutes). Providing such a solution on Debian hardware would be a great solution to the above problem. Is there something you need from the DPL to make this a reality? Also, a technical question (I'm curious): is there a technical reason why it's not possible to do that inside the current Ganeti setup? Is there something inherently less secure with providing root access to a VM inside a Ganeti cluster, compared to providing root access to a VM inside an OpenStack cloud? I'm asking because I don't expect a huge demand for this (something between 5 and 15 VM per year), so that's still a scale that could manageable using RT tickets + manual creation. Finally, I'd like to re-state that hosting everything (including development VMs) inside the Debian infrastructure is the most desirable solution. However, it seems that it requires manpower and resources that DSA does not really have for now (I would happy to help if possible with the 'resources' side -- I can't do much about the 'manpower' side). That's something we should work on so that ultimately, e.g. 1 or 2 years from now, we reach that point. But I don't think that we should wait 1 or 2 years to solve that general problem. That's why I'm exploring a compromise and temporary solution, which is using resources from public clouds. I will be very happy to drop that solution as soon as we have a DSA-provided one. Lucas signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
]] Lucas Nussbaum I'm only replying on the main point I'd like to make, so I'm limited my quoting to that. Do not take it as agreement or disagreement on the other points -- I just consider them more minor points. fairy nuff. 3. to provide a place to experiment with new services + create a Debian cloud with virtual machines to develop new services (maybe providing manually-created VMs would be enough -- I'm not sure we need a complex infra such as OpenStack). In general, we're quite happy to create VMs for people when they show up with a service they want to deploy, so I think this is quite well covered. It's great that you are quite happy to create VMs for people when they show up with a service they want to deploy. But that's not what I'm talking about. I'm seeking a solution for people who show up with an *idea* they want to *experiment* with. Because: 1) that's when they should engage with DSA so that you have a chance to review/participate in the design, not months later when an unofficial service is up and running; They don't need a VM to do this, though. 2) the alternative is that they give up on the idea, or host it themselves, which makes it harder to work collaboratively on the service, and results in services that have a single maintainer (or none, in the end). How does having a random VM running in a cloud somewhere make that service easier to integrate into the wider debian.org setup? I don't think it does; what does is the first point: talk to us so we can figure out what works for both sides. Especially given you want to give root to developers on those VMs, there's absolutely nothing that points in a direction of those VMs being more integrateable than a service developed on a developer's own laptop (in a VM or in their regular environment). A strong requirement for such a solution is that it should be easy to get access to a VM, even if the developers do not have any working code yet, or are not even set on all the implementation details of the services (e.g.; a 10-lines description of what the service is about should probably be enough). We expect people who maintain packages to provide their own development environment. How is service development qualitatively different? As I said, we're happy to hand out VMs to people, but as you rightly point out, the time when that happens tend to be when you at least have a proof of concept running, not when you start thinking about how to solve a problem. Another requirement is that the developers should have root access on the virtual machine, so that it's easy to try various options without DSA intervention (remember: this is about developement/beta testing, not about running the service in a super-stable, production mode). Who's then to ensure that machine is secured and kept up to date with security patches and doesn't become a source of spam? Sorry to say, but most developers are not good sysadmins and they do not have the tools and infrastructure set up to do systems maintenance well. For this to be an option at all, we'd want to sandbox the machines heavily enough that they will be less attractive machines to develop on than a developer's own laptop. Since we discussed that back in June, you added 'providing an OpenStack cloud' on the DSA radar (it noticed that it was mentioned in the 'just starting' category of DSA meeting minutes). Providing such a solution on Debian hardware would be a great solution to the above problem. Is there something you need from the DPL to make this a reality? It's sgran who's been thinking about how to do this, but afaik he's seen close to zero interest from developers for it, so it's not happened yet. I don't think we need anything from the DPL as such, but if people are actually interested in something like this happening, saying so would be a good start. The lack of feedback worries me a bit, since one one hand it seems like you're pushing quite hard for a cloud and all that, yet we're not seeing a user demand. It could be that people don't approach DSA for whatever reason (if so, we should fix that), but doing lots of work for something we don't know if it's needed doesn't sound like a good use of our time. Also, a technical question (I'm curious): is there a technical reason why it's not possible to do that inside the current Ganeti setup? Is there something inherently less secure with providing root access to a VM inside a Ganeti cluster, compared to providing root access to a VM inside an OpenStack cloud? I'm asking because I don't expect a huge demand for this (something between 5 and 15 VM per year), so that's still a scale that could manageable using RT tickets + manual creation. Given it's all just KVM, there's little to no difference, security-wise. Finally, I'd like to re-state that hosting everything (including development VMs) inside the Debian infrastructure is the most desirable
Debian SCALE 12x booth volunteers wanted [Los Angeles, CA Feb. 22-23]
Again this year I am organizing the Debian Booth at the Southern California Linux Expo (SCALE)[1]. The expo is on Saturday and Sunday, February 22nd and 23rd near LAX. As usual, I'd like to get a few volunteers to help out in the booth. If you can volunteer (even a few hours is OK!) please e-mail me, and I'll tell you the information you need to know. If you are unable to volunteer, but are going to be there anyway, stop by and say hi! 1: https://www.socallinuxexpo.org/blog/scale-12x -- Don Armstrong http://www.donarmstrong.com life's not a paragraph And death i think is no parenthesis -- e.e. cummings Four VII _is 5_ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014011245.gn22...@teltox.donarmstrong.com
Re: Debian services and Debian infrastructure
Hello everybody, I do not think that it is possible to solve all the points of misunderstanding in a long thread of long emails. Personally, I am totally confused by what I read, and do not understand what is even the basic stand point of each participant. May I suggest that you talk directly face to face or by videoconference ? For me, the take home message is: - Do not develop services that need you to have administrator access, because this is hard to transpose on DSA-hosted machines. - Sevices on debian.net should be hosted by Debian as much as possible. After many years as a DD, I became better at using a machine via root privileges than via collective hosting. For instance, I completely forgot how to use CPAN, and I am much more comfortable configuring apache via /etc/apache2/sites-available than via .htaccess files. Also, by my activity of a DD, I am more familiar with Testing-Unstable mixtures than with Stable. For example again, I did the apache 2.4 transition, where the Debian Apache team made a great work, and I would prefer to forget how the 2.2 systems work. I think that if I enjoyed collective hosting, I would have used it through numerus commercial providers, and would not have become a DD. At work, I would happily install software in my home directory on our CentOS servers, and would not mumble regularly that we need access to a cloud system instead. For upstream-metadata.debian.net (still broken, sorry, but I am working on it), I packaged the system (umegaya) so that others can clone it easily if needed, and will be happy to take care myself of the hosting if needed (because I jumped on apache 2.4 too quickly and blends.debian.net is running Wheezy...). But now I have the impression that self-hosting it is very unwelcome, and that the bar for setting up a .debian.net service is very high. I am not asking for an answer now since you need to clarify a lot of points together. I understand the need for transparency, but on the other hand, posting your discussion on -project gives the implicit message that the other subscribers should read it. Please take your time and consider using parallel and more casual discussion channels, to focus the postings on -project to the points of agreement that you reached, rather than the points of disagreement, which we all hope are just transient. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122232508.gb12...@falafel.plessy.net
Re: Debian services and Debian infrastructure
]] Charles Plessy Personally, I am totally confused by what I read, and do not understand what is even the basic stand point of each participant. May I suggest that you talk directly face to face or by videoconference ? You're of course free to suggest that, but if you read the initial mail in the thread you'll see that this is an attempt at bringing this discussion into the open, where it belongs. Taking it off to some other medium will work directly against that. For me, the take home message is: - Do not develop services that need you to have administrator access, because this is hard to transpose on DSA-hosted machines. No, because it's a terrible idea in general. If your service requires you to have root on the system, it's probably misdesigned. - Sevices on debian.net should be hosted by Debian as much as possible. Rather, Debian should self-host our own services. What their domain name is is less important. After many years as a DD, I became better at using a machine via root privileges than via collective hosting. For instance, I completely forgot how to use CPAN, and I am much more comfortable configuring apache via /etc/apache2/sites-available than via .htaccess files. Also, by my activity of a DD, I am more familiar with Testing-Unstable mixtures than with Stable. For example again, I did the apache 2.4 transition, where the Debian Apache team made a great work, and I would prefer to forget how the 2.2 systems work. If you look at the various setups, you'll see that it's not uncommon for us to give service admins write access to their vhost setup, so there's hardly any conflict between that and not having root. As for mixing testing and unstable in production, I hope you see why that is not a great idea on a production system. I think that if I enjoyed collective hosting, I would have used it through numerus commercial providers, and would not have become a DD. At work, I would happily install software in my home directory on our CentOS servers, and would not mumble regularly that we need access to a cloud system instead. Installing random software in your ~ instead of from packages is a really bad idea since there's then no central record of what's installed, there's no uniform way to upgrade the packages, etc. All the usual reasons for why we use packages rather than building stuff from source. But now I have the impression that self-hosting it is very unwelcome, and that the bar for setting up a .debian.net service is very high. If you're hosting it yourself, ask two questions: Does this (or will it, in the future) provide a valuable service to Debian? What happens when you lose interest or get run over by a bus? If the answer to the first question is yes (which I hope it is, since else why are you spending your time on it?) you should have a good answer to the second question. My answer is «it runs on Debian infrastructure, so the underlying OS is maintained, the hardware is maintained and we're able to grant other interested DDs access to the service». I think any reasonable answer that satisfies the same conditions basically means you're duplicating the work DSA are already doing, which is inefficient. If you do have a good answer that doesn't imply a waste of resources, where the OS and hardware is maintained and where we, as a project, can have some reasonable level of service contigency expectation even in the case of catastrophic failure of the service owner then I'd like to hear it. I am not asking for an answer now since you need to clarify a lot of points together. I understand the need for transparency, but on the other hand, posting your discussion on -project gives the implicit message that the other subscribers should read it. No, it means we think that other people should be able to read it, which is not the same thing. I have no opinion on how the subscribers of our mailing lists spend their time. Please take your time and consider using parallel and more casual discussion channels, to focus the postings on -project to the points of agreement that you reached, rather than the points of disagreement, which we all hope are just transient. I'm not going to do this for the reasons outlined at the top of this email. If this thread bothers you, just ignore it. Heck, it's not as if -project generally has that much traffic, so just skimming it shouldn't take that many minutes out of your day. I find it really disappointing to hear that you would rather have discussions with project-wide ramifications to be held in secret, rather than out in the open. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m238kfuq17@rahvafeir.err.no
