3 == snapshot.debian.org ==
5 Currently snapshot.debian.net is operated by a single individual on their
6 hardware at home. It is a service archiving old binary and source packages.
7 Access to old packages, which have in the meantime been deleted from the
8 regular debian archive, allows Developers and Users to debug upgrade problems,
9 to check when regressions were introduced, to check if old packages had been
10 miscompiled, to downgrade to older versions while bugs are being fixed etc.
14 * Two systems with sufficient storage, hosted somewhere not in the US (so we
15 can import old non-US into it).
16 * Storage should be at least on the order of 8T (currently snapshot.d.n is
17 using about 4T), and easily expandable
18 * remote management stuff
22 * Joerg Jaspert/ftpteam
28 A service by ftpmaster to host larger arch-all packages for datasets like
29 scientific databases (e.g. RCSB PDB, a database of protein structures) or
32 This service could (and probably should) share hardware with snapshot.
36 * ftpteam/Joerg Jaspert
42 I'd like to use Ubuntu's merge-o-matic to generate diffs between Debian's
43 source archive and the source archives of various other Debian-based distros
44 (Knoppix, Freespire, Mepis, Sidux, gNewSense and so on). The result will be
45 much like patches.ubuntu.com. merge-o-matic downloads source packages, unpacks
46 them and generates diffs against unpacked pure debian source packages. As a
47 result lots of disk space would be required since the whole Debian archive plus
48 an unpacked version of it and the same for each derivative distribution is
53 * a system with sufficient disk space (how much is that?)
60 == source.debian.org ==
62 Idea: A machine which has all sources extracted from orig.tar.gz + diff applied for all dists.
66 * a system with sufficient disk space (how much is that?)
74 ftp-master's hardware is becoming old and warranty is running out (we keep extending it, but that's not for free either).
76 We probably should look into getting a new machine somewhere in the US. Apart
77 from recent CPUs, reasonable amount of ram (16-32g?) and the usual management
78 fu primary requirement is reliable storage. We probably should look at some
79 raid6, either internal or external for the master copy of the archive in the range
80 of 2-4T (is that right, ftp folks?). Additionally some faster internal storage
81 could be useful for the database part of the ftp archive (4 disks raid10?).
85 bartok, the current backup.d.o, is getting old too, and there is not all that
88 We should be looking at replacing that eventually. A raid6 of big SATA disks
89 would probably provide the required robustness and be cost-effective.
94 These proposals probably are no longer relevant:
96 == new debian mail setup ==
98 A set of systems that will handle all incoming mail for all debian systems.
99 Currently our incoming mail handling is on the individual host hosting a
100 service, i.e. on master.debian.org for @debian.org, on bugs.debian.org for the
101 bug tracking system, on lists.debian.org for our mailinglists and on several
102 other systems for their individual, smaller email traffic.
104 Centralizing email handling will allow us to maintain our anti-spam measures in
105 a single point, avoiding duplicate work and hopefully improving our success.
109 * Four or so systems, in at least two different locations, capable of handling
110 modern anti-spam software. This probably needs a bit of CPU.
111 * remote management stuff
118 We probably have sufficient hardware for this. Current plan involves using one
119 new box from HP, murphy, a new old sparc that zobel gets from some place, and
120 puccini that will soon no longer have packages on it.
124 We probably still eventually want to move to a more cenralized setup for all
125 the low-traffic leaf-sites, but momentum on the Big Mail Setup Change seems
126 to have pretty much died. Since Stephen put quite a lot of work into making
127 our exim setup more readable, maintainable and we are using the same config now
128 everywhere, at least some of the reasons for this proposal are no longer valid.
129 It still might make sense to eventually move @debian.org mail from master to a new
130 system but we don't need 4 dedicated hosts for that, probably. (weasel)
134 Currently bugs runs on a single DL385g1 system which cannot keep up with the
135 load that the BTS causes.
137 Owner@bugs would like to split the BTS accross multiple hosts: two for incoming
138 email and spam filtering (would not be required if we had the setup mentioned
139 above), one master, and at least two user-facing web servers.
141 Requirements (assuming the above mentioned mail system is in place, else add
144 * two systems with fast disks (we don't need that much storage, some 200 gigs
145 should suffice easily for a while - say 4x140 gig raid10), some ram for
146 caching (say 16g?), and the CPU to handle the scripts (if we can get two quad
147 cores per box that would be great)
148 * one master that processes incoming email, changing bugs as required, and
149 pushes the changes to the web facing servers
155 If the snapshot hosts go through we might be able to put the bugs front end
156 webservers on them too. Probably a question of load but it can't hardly be
157 worse than rietz at the moment.
161 We were quite successful in using other hosts as bugs web mirrors (even if
162 right now we aren't running any due to other hardware failing), so that is
163 a more or less solved problem. We also intent to move bugs-master to a kvm
164 domain at ubc/ece once the blade there is fixed. And we can probably move
165 incoming MX to a blade instance in darmstadt and another one at the same
166 place as new bugs-master will be if the bugs folks still want that.