1. Manages Key Services
2. Design
2.1. bulk of scripts manage single service
2.1.1. service scripts in '.liquid-host'
2.1.2. master script for CL control deployed to users bin
2.1.3. individual scripts can be accessed by wrappers
2.2. service script interface
2.2.1. --query
2.2.2. --configure
2.2.3. --remove
2.2.4. --start
2.2.5. --restart
2.2.6. --stop
2.2.7. --update
2.2.8. --info
2.3. interface conventions
2.3.1. 'fail' is the common failure indicator
2.3.2. try to make equivalent outcomes easily scannable
2.3.2.1. avoid scan interference
2.4. future: convention for output
2.5. future: liquid_host is itself a service
2.6. future: special scripts
2.6.1. list services
2.6.2. show common config
2.6.3. set common config
2.6.4. common config wizard
2.7. complete set of scripts in liquid host, does not imply services installed locally
2.8. kibbles vs. service configuration
2.8.1. kibbles variables in .liquid_host/etc
2.8.2. service configurations in natural place
3. interface
3.1. xen
3.1.1. query
3.1.2. configure
3.1.3. host info
3.1.4. host deploy
3.1.5. host rename
3.1.6. host configure
3.1.7. host add volume
3.1.8. volume query
3.1.9. volume add
3.2. configure
3.3. mail
3.3.1. query
3.3.2. configure
3.3.3. domain add
3.3.4. domain remove
3.3.5. alias add
3.3.6. alias remove
3.4. apache web
3.4.1. query
3.4.2. configure
3.4.3. start
3.4.4. stop
3.4.5. domain add
3.4.6. domain remove
3.4.7. domain configure
3.4.8. domain query
3.5. tomcat web
3.5.1. query
3.5.2. configure
3.5.3. start stop
3.6. domains
3.6.1. list
3.6.2. add
3.6.3. remove
3.6.4. configure
3.7. db server
3.7.1. query
3.7.2. db add
3.7.3. db remove
3.7.4. db query
3.7.5. db configure
3.8. volume
3.8.1. query
3.8.2. add
3.8.3. remove
3.8.4. configure
3.8.5. backup
3.9. keys
3.9.1. query
3.9.2. add
3.9.3. remove
3.10. New node
3.11. liquid_host_install.sh
4. Context/Assumptions/Goals
4.1. openSUSE 11.1
4.2. maintains compatibility with yast and standard admin tools
4.3. installs core stack directly
4.3.1. core stack can move independent of ditro release/politics
4.3.2. non-central and stable services may rely on distro
4.3.2.1. postfix
4.3.2.2. imap
4.3.2.3. ldap
5. Why Bother?
5.1. latest versions
5.2. multiple versions
5.3. it's not that hard
5.3.1. in fact, may be easier than not
5.3.2. we're not trying to reinvent the wheel
5.4. firmer foundation
5.4.1. distros do change layout
5.4.2. need to control integration between services