- Recommended practices for Debian services
- Hosting possibilities
- Random notes
- Contact information about this page
Recommended practices for Debian services
Gather feedback on possible convergence and design: Many Debian services were developed as standalone services whereas it might have been a better fit to integrate the new functionality into an existing service. It is recommended that you engage early with the debian-services-admin mailing list, and describe your goals and your current ideas about design.
Know your resource requirements: Have a good understanding of the resource requirements of your service and be able to describe them. How much disk space will you need, how much RAM, how many cores, archive mirror, snapshot mirror, projectb/UDD database mirror? Realise server-grade disk-space is limited and not cheap.
Architect your service well: User-facing services that are likely to receive a lot of visitors should be architected so they can distribute the load over multiple geographically distributed machines to reduce latency and stay available when some of them go down. Services doing checks of external systems or websites might distribute the checking to multiple geographically distributed machines and then aggregate check data to ensure a globally complete view of any issues. Use aliases rather than hard-coding machine names.
Use standard components: Your service should work with standard components; Debian uses VMs on x86 servers, running Debian stable (and backports) with PostgreSQL for databases and Apache for web serving.
- Several months before the release freeze is a good time to start updating your service codebase/dependencies and test that they work with the upcoming stable release. Later in the freeze, DSA will start upgrading some services to the upcoming stable release with the aim of upgrading all systems soon after the release.
- For services that need other types of hardware, DSA need to be able to acquire and host that hardware. DSA like stable hardware that can be bought (or donated), that survives reboots and doesn't fall over all the time. Out of band access is helpful. Debian's hosting providers generally like rack-mountable hardware.
- Use packages available in Debian for the code needed to run your service. Code that is developed by the service maintainers may be an exception, but it is still a good idea to package that code so other folks can run their own instances of the service more easily.
Design and develop with privacy and security in mind: assume no direct root access, assume SSL with http: to https: redirects, use progressive enhancement for web services, use only same-domain web content, assume privacy-mode web server logs, use different users for updating code/data, use SSL cert pinning, don't trust SSL CAs by default, avoid embedded code copies, avoid unsafe languages (such as PHP) and APIs, use static analysis tools, get a code audit done and use the Debian single-sign-on service for authentication. Ensure that the service is compliant with the EU GDPR laws.
Provide clear contact points, both in-band (service homepage) and out-of-band (Services Census): It should be easy to identify how to interact with the services maintainers. You should provide this information on the service webpages itself, and in the Services Census (in case the service is down).
Document how to contribute to your service: It sometimes happen that services end up being de-facto orphaned. It is important to allow others to adopt or replicate services you are maintaining, by providing:
- A pointer to the public source code for the service, with licensing information
- Instructions for the setup of a development instance of the service
- Instructions for reporting bugs / sending patches
A metapackage listing the dependencies of the service for the debian.org metapackages
- An effective and active service admin team of multiple people willing to help new contributors. DSA plan to shut down services without active admins until there is someone to adopt them.
Other situations: Sometimes your service might not fit with the above guidelines in some way, please talk to DSA and we will come up with solutions on a case-by-case basis.
See Also: Franklin Street Statement on Freedom and Network Services (2008) (update), Free Software Needs Free Tools, GNU ethical repository criteria, Userops Acid Test, Server Software Matters, User Data Manifesto, Fair Web Services, Your Service is not Open Source, Open Service as a Service in Practice
In the Debian infrastructure, on hardware managed by the Debian Systems Administrators (DSA)
Contact the debian-services-admin mailing list. Admins for debian.org services are expected to be subscribed to this mailing list.
Other contact points:
In the Debian infrastructure, on hardware provided by the DebianNet Team
The Teams/DebianNet team offers unmanaged hosting for Debian Developers to host services related to Debian and have the costs paid for by the Debian project. Please see the documentation for instructions on how to request an instance.
Outside the Debian infrastructure
(also see this d-d-a post for context)
Note that all services useful to Debian should ideally be hosted in the Debian infrastructure, on DSA-managed hardware. Hosting outside Debian should ideally be limited to cases where this facilitates the development or testing of new services, or the hosting of services with requirements that cannot be satisfied by the Debian infrastructure. As described above, it is recommended to engage early with DSA to identify possible blockers.
The sections lists organizations (in alphabetical order) that are offering hosting to Debian contributors for their Debian work, including hosting services. For hosting of services not directly related to Debian, check out the benefits of being a Debian member/contributor. Unless specified otherwise, those organizations offer this hosting at no cost, and expect reasonable mentions of their help in communication about the service (thank you note in blog posts about the service, mention on the service's homepage, etc.). Each request is subject to its own review by the organization, which may very well refuse -- those offers are not blanket approvals of all requests. Also, unless specified otherwise, those are not offer for hosting general-purpose machines, but are restricted to services that somehow contribute to Debian development (new QA services, etc.).
Before contacting those organizations, it is recommended that you engage with the debian-services-admin mailing list to discuss your goals and opportunities for convergence with other services, as outlined above.
To learn about services hosted by each organization, refer to the Services Census.
- Please send all requests OpenPGP-signed, from your @debian.org email address.
Contact: <non-profit at gandi.net>
Please send all requests OpenPGP-signed, from your @debian.org email address, and Cc email@example.com who will confirm your identity.
Contact: Thomas Goirand <zigo at d.o>
Contact: Andrew Starr-Bochicchio <asb at digitalocean.com> | <asb at debian.org>, <opensource at digitalocean.com>
Please apply at https://fosshost.org/apply or <admin at fosshost.org > | alternatively join #fosshost on Libera.Chat
Setting up machines the DSA way
Puppet modules: http://git.debian.org/?p=mirror/dsa-puppet.git
Contact information about this page
For now, please contact firstname.lastname@example.org if you have questions/comments about this page.