mypapers/enterprise-software/enterprise-software.html

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