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 == new bugs.d.o ==
  40
  41 Currently bugs runs on a single DL385g1 system which cannot keep up with the
  42 load that the BTS causes.
  43
  44 Owner@bugs would like to split the BTS accross multiple hosts: two for incoming
  45 email and spam filtering (would not be required if we had the setup mentioned
  46 above), one master, and at least two user-facing web servers.
  47
  48 Requirements (assuming the above mentioned mail system is in place, else add
  49 two mail servers):
  50
  51 * two systems with fast disks (we don't need that much storage, some 200 gigs
  52   should suffice easily for a while - say 4x140 gig raid10), some ram for
  53   caching (say 16g?), and the CPU to handle the scripts (if we can get two quad
  54   cores per box that would be great)
  55 * one master that processes incoming email, changing bugs as required, and
  56   pushes the changes to the web facing servers
  57
  58 Proposers:
  59
  60 * Don Armstrong
  61
  62 If the snapshot hosts go through we might be able to put the bugs front end
  63 webservers on them too. Probably a question of load but it can't hardly be
  64 worse than rietz at the moment.
  65
  66
  67 == merge.d.o ==
  68
  69 I'd like to use Ubuntu's merge-o-matic to generate diffs between Debian's
  70 source archive and the source archives of various other Debian-based distros
  71 (Knoppix, Freespire, Mepis, Sidux, gNewSense and so on). The result will be
  72 much like patches.ubuntu.com. merge-o-matic downloads source packages, unpacks
  73 them and generates diffs against unpacked pure debian source packages. As a
  74 result lots of disk space would be required since the whole Debian archive plus
  75 an unpacked version of it and the same for each derivative distribution is
  76 needed.
  77
  78 Requirements:
  79
  80 * a system with sufficient disk space (how much is that?)
  81
  82 Proposers:
  83
  84 * Paul Wise
  85
  86
  87 == source.debian.org ==
  88
  89 Idea: A machine which has all sources extracted from orig.tar.gz + diff applied for all dists.
  90
  91 Requirements:
  92
  93 * a system with sufficient disk space (how much is that?)
  94
  95 Proposers:
  96
  97 * Noel Koethe
  98
  99 == new ftp-master ==
 100
 101 ftp-master's hardware is becoming old and warranty is running out (we keep extending it, but that's not for free either).
 102
 103 We probably should look into getting a new machine somewhere in the US.  Apart
 104 from recent CPUs, reasonable amount of ram (16-32g?) and the usual management
 105 fu primary requirement is reliable storage.  We probably should look at some
 106 raid6, either internal or external for the master copy of the archive in the range
 107 of 2-4T (is that right, ftp folks?).  Additionally some faster internal storage
 108 could be useful for the database part of the ftp archive (4 disks raid10?).
 109
 110 == new backup.d.o ==
 111
 112 bartok, the current backup.d.o, is getting old too, and there is not all that
 113 much spare space.
 114
 115 We should be looking at replacing that eventually.  A raid6 of big SATA disks
 116 would probably provide the required robustness and be cost-effective.
 117
 118
 119 = Historical =
 120
 121 These proposals probably are no longer relevant:
 122
 123 == new debian mail setup ==
 124
 125 A set of systems that will handle all incoming mail for all debian systems.
 126 Currently our incoming mail handling is on the individual host hosting a
 127 service, i.e. on master.debian.org for @debian.org, on bugs.debian.org for the
 128 bug tracking system, on lists.debian.org for our mailinglists and on several
 129 other systems for their individual, smaller email traffic.
 130
 131 Centralizing email handling will allow us to maintain our anti-spam measures in
 132 a single point, avoiding duplicate work and hopefully improving our success.
 133
 134 Requirements:
 135
 136 * Four or so systems, in at least two different locations, capable of handling
 137   modern anti-spam software. This probably needs a bit of CPU.
 138 * remote management stuff
 139
 140 Proposers:
 141
 142 * Martin Zobel-Helas
 143 * Stephen Gran
 144
 145 We probably have sufficient hardware for this. Current plan involves using one
 146 new box from HP, murphy, a new old sparc that zobel gets from some place, and
 147 puccini that will soon no longer have packages on it.
 148
 149 Status (2009-05-02):
 150
 151 We probably still eventually want to move to a more cenralized setup for all
 152 the low-traffic leaf-sites, but momentum on the Big Mail Setup Change seems
 153 to have pretty much died.  Since Stephen put quite a lot of work into making
 154 our exim setup more readable, maintainable and we are using the same config now
 155 everywhere, at least some of the reasons for this proposal are no longer valid.
 156 It still might make sense to eventually move @debian.org mail from master to a new
 157 system but we don't need 4 dedicated hosts for that, probably.  (weasel)
 158