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 = Historical =
  73
  74 These proposals probably are no longer relevant:
  75
  76 == new debian mail setup ==
  77
  78 A set of systems that will handle all incoming mail for all debian systems.
  79 Currently our incoming mail handling is on the individual host hosting a
  80 service, i.e. on master.debian.org for @debian.org, on bugs.debian.org for the
  81 bug tracking system, on lists.debian.org for our mailinglists and on several
  82 other systems for their individual, smaller email traffic.
  83
  84 Centralizing email handling will allow us to maintain our anti-spam measures in
  85 a single point, avoiding duplicate work and hopefully improving our success.
  86
  87 Requirements:
  88
  89 * Four or so systems, in at least two different locations, capable of handling
  90   modern anti-spam software. This probably needs a bit of CPU.
  91 * remote management stuff
  92
  93 Proposers:
  94
  95 * Martin Zobel-Helas
  96 * Stephen Gran
  97
  98 We probably have sufficient hardware for this. Current plan involves using one
  99 new box from HP, murphy, a new old sparc that zobel gets from some place, and
 100 puccini that will soon no longer have packages on it.
 101
 102 Status (2009-05-02):
 103
 104 We probably still eventually want to move to a more cenralized setup for all
 105 the low-traffic leaf-sites, but momentum on the Big Mail Setup Change seems
 106 to have pretty much died.  Since Stephen put quite a lot of work into making
 107 our exim setup more readable, maintainable and we are using the same config now
 108 everywhere, at least some of the reasons for this proposal are no longer valid.
 109 It still might make sense to eventually move @debian.org mail from master to a new
 110 system but we don't need 4 dedicated hosts for that, probably.  (weasel)
 111
 112 == new bugs.d.o ==
 113
 114 Currently bugs runs on a single DL385g1 system which cannot keep up with the
 115 load that the BTS causes.
 116
 117 Owner@bugs would like to split the BTS accross multiple hosts: two for incoming
 118 email and spam filtering (would not be required if we had the setup mentioned
 119 above), one master, and at least two user-facing web servers.
 120
 121 Requirements (assuming the above mentioned mail system is in place, else add
 122 two mail servers):
 123
 124 * two systems with fast disks (we don't need that much storage, some 200 gigs
 125   should suffice easily for a while - say 4x140 gig raid10), some ram for
 126   caching (say 16g?), and the CPU to handle the scripts (if we can get two quad
 127   cores per box that would be great).
 128 * one master that processes incoming email, changing bugs as required, and
 129   pushes the changes to the web facing servers.
 130
 131 Proposers:
 132
 133 * Don Armstrong
 134
 135 If the snapshot hosts go through we might be able to put the bugs front end
 136 webservers on them too. Probably a question of load but it can't hardly be
 137 worse than rietz at the moment.
 138
 139 Status (2009-05-04):
 140
 141 We were quite successful in using other hosts as bugs web mirrors (even if
 142 right now we aren't running any due to other hardware failing), so that is
 143 a more or less solved problem.  We also intent to move bugs-master to a kvm
 144 domain at ubc/ece once the blade there is fixed.  And we can probably move
 145 incoming MX to a blade instance in darmstadt and another one at the same
 146 place as new bugs-master will be if the bugs folks still want that.
 147
 148 == new ftp-master ==
 149
 150 ftp-master's hardware is becoming old and warranty is running out (we keep extending it, but that's not for free either).
 151
 152 We probably should look into getting a new machine somewhere in the US.  Apart
 153 from recent CPUs, reasonable amount of ram (16-32g?) and the usual management
 154 fu primary requirement is reliable storage.  We probably should look at some
 155 raid6, either internal or external for the master copy of the archive in the range
 156 of 2-4T (is that right, ftp folks?).  Additionally some faster internal storage
 157 could be useful for the database part of the ftp archive (4 disks raid10?).
 158
 159 Status (2010-05-20):
 160
 161 HP DL380 G6 machine in place at CS Dept. Brown University. In setup