input/hardware-wishlist.creole

   1 = Hardware Wishlist =
   2
   3 == data.d.o ==
   4
   5 A service by ftpmaster to host larger arch-all packages for datasets like
   6 scientific databases (e.g. RCSB PDB, a database of protein structures) or
   7 datasets for games.
   8
   9 This service could (and probably should) share hardware with snapshot.
  10
  11 Proposers:
  12
  13 * ftpteam/Joerg Jaspert
  14
  15
  16
  17 = Historical =
  18
  19 These proposals probably are no longer relevant:
  20
  21 == source.debian.org ==
  22
  23 Idea: A machine which has all sources extracted from orig.tar.gz + diff applied for all dists.
  24
  25 Requirements:
  26
  27 * a system with sufficient disk space (how much is that?)
  28
  29 Proposers:
  30
  31 * Noel Koethe
  32
  33 == new debian mail setup ==
  34
  35 A set of systems that will handle all incoming mail for all debian systems.
  36 Currently our incoming mail handling is on the individual host hosting a
  37 service, i.e. on master.debian.org for @debian.org, on bugs.debian.org for the
  38 bug tracking system, on lists.debian.org for our mailinglists and on several
  39 other systems for their individual, smaller email traffic.
  40
  41 Centralizing email handling will allow us to maintain our anti-spam measures in
  42 a single point, avoiding duplicate work and hopefully improving our success.
  43
  44 Requirements:
  45
  46 * Four or so systems, in at least two different locations, capable of handling
  47   modern anti-spam software. This probably needs a bit of CPU.
  48 * remote management stuff
  49
  50 Proposers:
  51
  52 * Martin Zobel-Helas
  53 * Stephen Gran
  54
  55 We probably have sufficient hardware for this. Current plan involves using one
  56 new box from HP, murphy, a new old sparc that zobel gets from some place, and
  57 puccini that will soon no longer have packages on it.
  58
  59 Status (2009-05-02):
  60
  61 We probably still eventually want to move to a more cenralized setup for all
  62 the low-traffic leaf-sites, but momentum on the Big Mail Setup Change seems
  63 to have pretty much died.  Since Stephen put quite a lot of work into making
  64 our exim setup more readable, maintainable and we are using the same config now
  65 everywhere, at least some of the reasons for this proposal are no longer valid.
  66 It still might make sense to eventually move @debian.org mail from master to a new
  67 system but we don't need 4 dedicated hosts for that, probably.  (weasel)
  68
  69 == new bugs.d.o ==
  70
  71 Currently bugs runs on a single DL385g1 system which cannot keep up with the
  72 load that the BTS causes.
  73
  74 Owner@bugs would like to split the BTS accross multiple hosts: two for incoming
  75 email and spam filtering (would not be required if we had the setup mentioned
  76 above), one master, and at least two user-facing web servers.
  77
  78 Requirements (assuming the above mentioned mail system is in place, else add
  79 two mail servers):
  80
  81 * two systems with fast disks (we don't need that much storage, some 200 gigs
  82   should suffice easily for a while - say 4x140 gig raid10), some ram for
  83   caching (say 16g?), and the CPU to handle the scripts (if we can get two quad
  84   cores per box that would be great).
  85 * one master that processes incoming email, changing bugs as required, and
  86   pushes the changes to the web facing servers.
  87
  88 Proposers:
  89
  90 * Don Armstrong
  91
  92 If the snapshot hosts go through we might be able to put the bugs front end
  93 webservers on them too. Probably a question of load but it can't hardly be
  94 worse than rietz at the moment.
  95
  96 Status (2009-05-04):
  97
  98 We were quite successful in using other hosts as bugs web mirrors (even if
  99 right now we aren't running any due to other hardware failing), so that is
 100 a more or less solved problem.  We also intent to move bugs-master to a kvm
 101 domain at ubc/ece once the blade there is fixed.  And we can probably move
 102 incoming MX to a blade instance in darmstadt and another one at the same
 103 place as new bugs-master will be if the bugs folks still want that.
 104
 105 == new ftp-master ==
 106
 107 ftp-master's hardware is becoming old and warranty is running out (we keep extending it, but that's not for free either).
 108
 109 We probably should look into getting a new machine somewhere in the US.  Apart
 110 from recent CPUs, reasonable amount of ram (16-32g?) and the usual management
 111 fu primary requirement is reliable storage.  We probably should look at some
 112 raid6, either internal or external for the master copy of the archive in the range
 113 of 2-4T (is that right, ftp folks?).  Additionally some faster internal storage
 114 could be useful for the database part of the ftp archive (4 disks raid10?).
 115
 116 Status (2010-05-20):
 117
 118 HP DL380 G6 machine in place at CS Dept. Brown University. In setup