mypapers/enterprise-software/enterprise-software.html

   1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
   2 <!-- This document is licensed using the GNU Public License version 2 -->
   3 <html>
   4   <head>
   5     <link rel="stylesheet" href="../mrtg-td/slides.css" type="text/css">
   6     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   7     <meta name="Language" content="en">
   8     <meta name="Author" content="Petter Reinholdtsen">
   9     <title>Writing enterprise ready software</title>
  10   </head>
  11   <body>
  12
  13     <h1>Writing enterprise ready software</h1>
  14
  15     <p></p>
  16
  17     <p><tt><a href="http://www.hungry.com/~pere/mypapers/enterprise-software/enterprise-software.html">http://www.hungry.com/~pere/mypapers/enterprise-software/enterprise-software.html</a></tt></p>
  18
  19     <div class="presenter">Petter Reinholdtsen
  20       <br>pere@hungry.com
  21       <br>Debconf5, Helsinki 2005-06-12</div>
  22
  23     <h2>Overview</h2>
  24     <ul>
  25
  26      <li>we are in trouble
  27      <li>clues for the clueless
  28      <li>multilevel configuration
  29
  30    </ul>
  31
  32 <h2>We are in trouble</h2>
  33
  34 <p>Some things are possible for 1 to 10 machines, and impossible with
  35   500 machines.  What do you do when you break the ssh configuration
  36   file on 700 machines?
  37
  38 <h2>Trouble moving</h2>
  39
  40 <p>With 60000 users and about 150 home directory file servers
  41  available from 12000 machines, users move from file server to file
  42  server.  This break several applications when the path to the users
  43  home directory changes.  (example: /mn/hegel/u1/pere to
  44  /usit/saruman/u1/pere).</p>
  45
  46 <!--
  47 Moving a user from one user disk to another break mozilla and
  48 openoffice configuration.  - not using relative paths
  49 -->
  50
  51 <h2>Downgrade trouble</h2>
  52
  53 <p>With 900 linux machines with common user database and home
  54 directories while running different versions of programs, users will
  55 run several versions of a program with the same configuration
  56 files.</p>
  57
  58 <!-- Trying to run with KDE 2 and 3 on different machines messes up
  59 the configuration - not handling downgrades
  60
  61 - handle up/downgrades - people will use different versions on
  62 different machines, with common home directories
  63
  64  -->
  65
  66 <h2>Some old trouble</h2>
  67
  68
  69 <p>Some users lost the source of their production systems, and need
  70 the binaries to keep working for 10-15 years.</p>
  71
  72 <!-- 15 year old binaries should keep working.  The source is lost
  73 long time ago, and the program is still used in production. -->
  74
  75 <h2>No room for more trouble</h2>
  76
  77 <p>When the file system for the PostgreSQL database in production goes
  78 full, one do not want to kick out 30000 users to take down the
  79 database and resize the file system.</p>
  80
  81 <h2>Disk trouble</h2>
  82
  83 <p>RAID is only only useful until the last redundancy disk is lost.
  84
  85 <p>Automatic RAID status systems need API or command line tools to
  86 extract the status.  Not like afacli, which go into interactive mode
  87 when an error is detected.
  88
  89 <h2>Installation trouble</h2>
  90
  91 <p>Trying to compile/install software on Irix, Solaris, Linux, HP-UX,
  92 Tru64 Unix, MacOSX and AIX when the process require a sysadmin to sit
  93 around to answer questions, change CDs, or insert licenses is both
  94 painful and prone to errors.</p>
  95
  96 <h2>Network trouble</h2>
  97
  98 <p>Trying to get some network server to work when it require to use
  99 some given port range, which is already taken by some other service
 100 and blocked in the router -- or try to get the corporate network
 101 gatekeeper to open up the firewall</p>
 102
 103 <h2>Version trouble</h2>
 104
 105 <p>Given three tcl or php applications, is there one version of TCL or
 106 PHP usable with all of these?
 107
 108 <h2>Usability trouble</h2>
 109
 110 <p>When starting a program from the menu, where does it go if nothing
 111 appear on the screen?
 112
 113 <p>Do users always read their ~/.xsession-error file?
 114
 115
 116 <h2>Clues for the clueless</h2>
 117
 118 <ul>
 119
 120 <li>at least three levels of config files; package defaults, site
 121   defaults and host defaults
 122
 123 <li>never ask questions at compile time.  when compiling automatically
 124   for 10 platforms, a sysadmin do not want to sit down and answer
 125   questions.
 126
 127 <li>split installation tasks in two, one for installation, and one for
 128   the operations needing root access. (build / configuration as well)
 129
 130 <li>make sure the software can be installed anywhere (location
 131   independent), avoid hard coding paths into the binaries.
 132
 133 <li>make the source available to make it possible to fix problems on
 134   site, and to use it on different platforms (os/hw) in the future
 135
 136 </ul>
 137
 138 <h2>More tips</h2>
 139
 140 <ul>
 141
 142 <li>Make paths into users home directories relative to ~user/, as users
 143   will move from disk to disk, or copy their home directory from site
 144   to site.  Always convert paths when saving config files.
 145
 146 <li>depend on as few libraries as possible, as it is a pain to get every
 147   extra library in place
 148
 149 <li>use well known libraries instead of making your own implementation.
 150   reduces the security risk.
 151
 152 <li>make sure libraries, and programming languages are backwards
 153   compatible.
 154
 155 <li>use a well known license.  it is a pain to evaluate every new
 156   license
 157
 158 </ul>
 159
 160 <h2>Make it easier for everyone</h2>
 161
 162 <ul>
 163
 164 <li>when distributing source, do not use vendor specific compiler
 165   features.  It will not work with the other vendors compilers used to
 166   compile on site.
 167
 168 <li>write portable code, make sure it works the same on all platforms.
 169
 170 <li>make the software work out of the box (require as little
 171   configuration as possible).
 172
 173 <li>avoid resource leaks (memory, shared memory, locks, file
 174   descriptors, X server resources, etc).  Restarting a long-running
 175   server is not always an option.
 176
 177 <li>system services should send messages to syslog.  always log why when
 178   crashing.  always log problems and errors.
 179
 180 </ul>
 181
 182 <h2>Final clues</h2>
 183
 184 <ul>
 185
 186 <li>reuse configuration when possible.  ktouch have its own x layout setting.
 187   better to fetch the current one from X like xkeycaps.
 188
 189 <li>providing hooks to the local administrators
 190
 191 <li>reduce flexibility.  trying to support people over the phone when
 192   the gui is different for every person is a pain.
 193
 194 <li>do not try to cleverly find the final resting place of the installation.
 195
 196 </ul>
 197
 198     <h2>Solving the upgrade problem using multilevel
 199       configuration</h2>
 200
 201     <ul>
 202
 203       <li>local configuration should be kept during upgrades</li>
 204
 205       <li>do not change configuration file format</li>
 206
 207       <li>easiest to do if the local configuration is separate from the
 208         package default
 209
 210       <li>several actors what to have a say in the service
 211          configuration.  allow them to have their own files
 212
 213       <li>Example: read config from /usr/share/foo/config,
 214          /site/share/foo/config, /etc/foo/config, ~/.foo/config,
 215          /etc/foo/config.fixed, /site/share/foo/config.fixed,
 216          /usr/share/foo/config.fixed.
 217
 218       <li>make it possible to provide package, site, host and user
 219         defaults, as well as locking down features on a host, site and
 220         package level.
 221
 222       <li>always well known where the admin made his changes
 223
 224     </ul>
 225
 226     <h2>Thank you very much</h2>
 227
 228     <h3>Questions?</h3>
 229
 230   </body>
 231 </html>