PageRenderTime 35ms CodeModel.GetById 20ms RepoModel.GetById 1ms app.codeStats 0ms

Plain Text | 80 lines | 62 code | 18 blank | 0 comment | 0 complexity | defcbbb49bf561f09ff1fe1d8ecc6d5e MD5 | raw file
Possible License(s): GPL-2.0
  1. File Layout
  2. ===========
  3. This document describes how files are laid out in the Silver Lining
  4. code base, and on production servers (and how the two relate).
  5. General Patterns
  6. ----------------
  7. Anything that is a "script" (a file meant to be executed) generally
  8. has a ``-`` in the name somewhere, to help indicate that it is *not* a
  9. module (since you cannot import names with dashes).
  10. The Silver Lining Code Base
  11. ---------------------------
  12. Here are some notable features:
  13. * The ``silverlining`` package is basically for *managing* the
  14. process. It is *not* installed on the production servers, nor is it
  15. generally importable by applications (nor is there anything worth
  16. importing).
  17. * The ``silversupport`` is uploaded to the production server, and also
  18. used locally. Applications may find it useful to import some
  19. routines from this library. There's also simply pieces here that
  20. both ``silverlining`` and server management scripts need to use, and
  21. this is the one shared codebase for that.
  22. * ``silversupport`` gets uploaded to
  23. ``/usr/local/share/silverlining/lib`` (this directory is added to
  24. ``sys.path`` to make it importable).
  25. * There are a bunch of scripts that are run *on the server*. Lots of
  26. what Silver Lining does is just ``ssh server "command"``, with the
  27. actual code on the server. All Silver Linings scripts are uploaded
  28. *from* ``silverlining/mgr-scripts/`` to
  29. ``/usr/local/share/silverlining/mgr-scripts/``. These are *only*
  30. run on the server, not locally. Each script also adds
  31. ``/usr/local/share/silverlining/lib`` to its path at the top of the
  32. script.
  33. * Files in ``silverlining/server-files/`` are rsync'd to the server's
  34. root. That is, the file layout under that directory matches the
  35. server layout exactly. ``silversupport`` and ``mgr-scripts`` are
  36. rsync'd separately.
  37. * Some of the files used for *setting up* a server are in
  38. ``silverlining/server-sync-scripts/``. This includes the *very
  39. important* ```` script, which does most of the
  40. configuration of servers. If there's anything that needs to be done
  41. (or checked, or fixed) every time a server is created or updated,
  42. that's probably the place to look. (Per-service tasks, like
  43. installing a database configuration file, go in the service code.)
  44. Services
  45. --------
  46. Services are modules in ``*``, named after the
  47. service. Resource files for services go in that package as well (for
  48. instance, the ``pg_hba.conf`` that the postgis service uses is in
  49. ``silversupport/services/postgis-pg_hba.conf``).
  50. Server Files
  51. ------------
  52. The files created by ``silver setup-node`` are generally put in
  53. ``/usr/local/share/silverlining/``.
  54. Configuration files get put wherever they belong, e.g.,
  55. ``/etc/apache2/sites-enabled/wsgi_runner``.
  56. Log files go in ``/var/log/silverlining/``.
  57. Individual applications have log files in
  58. ``/var/log/silverlining/apps/APP_NAME``, specifically ``errors.log``
  59. is anything written to stderr, stdout, or ``environ['wsgi.errors']``.
  60. These items are also grouped by request (all content written is
  61. buffered, written out in one chunk with a header/footer to help group
  62. it to a request).