Move new 5 hosts bugs setup to historical
[mirror/dsa-wiki.git] / input / hardware-wishlist.creole
1 = Hardware Wishlist =
2
3 == snapshot.debian.org ==
4
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.
11
12 Requirements:
13
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
19
20 Proposers:
21
22 * Joerg Jaspert/ftpteam
23 * Peter Palfrader
24
25
26 == data.d.o ==
27
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
30 datasets for games.
31
32 This service could (and probably should) share hardware with snapshot.
33
34 Proposers:
35
36 * ftpteam/Joerg Jaspert
37
38
39
40 == merge.d.o ==
41
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
49 needed.
50
51 Requirements:
52
53 * a system with sufficient disk space (how much is that?)
54
55 Proposers:
56
57 * Paul Wise
58
59
60 == source.debian.org ==
61
62 Idea: A machine which has all sources extracted from orig.tar.gz + diff applied for all dists.
63
64 Requirements:
65
66 * a system with sufficient disk space (how much is that?)
67
68 Proposers:
69
70 * Noel Koethe
71
72 == new ftp-master ==
73
74 ftp-master's hardware is becoming old and warranty is running out (we keep extending it, but that's not for free either).
75
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?).
82
83 == new backup.d.o ==
84
85 bartok, the current backup.d.o, is getting old too, and there is not all that
86 much spare space.
87
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.
90
91
92 = Historical =
93
94 These proposals probably are no longer relevant:
95
96 == new debian mail setup ==
97
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.
103
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.
106
107 Requirements:
108
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
112
113 Proposers:
114
115 * Martin Zobel-Helas
116 * Stephen Gran
117
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.
121
122 Status (2009-05-02):
123
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)
131
132 == new bugs.d.o ==
133
134 Currently bugs runs on a single DL385g1 system which cannot keep up with the
135 load that the BTS causes.
136
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.
140
141 Requirements (assuming the above mentioned mail system is in place, else add
142 two mail servers):
143
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
150
151 Proposers:
152
153 * Don Armstrong
154
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.
158
159 Status (2009-05-04):
160
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.