UGCS5 Principles

Revision as of 16:44, 14 June 2017 by Saladi (talk | contribs) (Isolation/Independence: fix spelling)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

In order to provide the most reliable and high quality service, UGCS5 will follow several strict principles. Violation of these principles is not good.


UGCS5 will follow standard and conventional configuration as closely as possible. This way, new users and sysadmins can jump in and immediately be familiar with the services and configuration, and can easily apply outside experience in diagnosing problems. If a widely used guide is available, its conventions should be followed. Deviations from either the distribution or configuration guide settings must be justified and documented.


UGCS5 is not tolerant of "cargo cult programming". The principles of operation and all configuration options must be understood for all components of UGCS. Configuration options must not be copied from a guide without fully understanding why that option is necessary for the proper operation of the service.


Core services will be provided with the bare minimum of configuration and infrastructure required to support that service. Any software, infrastructure, or configuration not absolutely necessary to providing these services must be avoided. For example, unnecessary automation, encryption of files stored on disk, realtime failover, and Kerberos will not be allowed.


All configuration and software/hardware installation must be documented. Documentation should be complete and thorough such that a sysadmin with no experience with UGCS should be able to fully reconstruct a completely functional duplicate of UGCS using only the provided documentation.


Critical services will be located on dedicated hardware unless performance requirements dictate that multiple services must share hardware. Any problems with a single service will not jeopardize the functionality of any other service. A server dedicated to mail, for example, will not be part of a distributed filesystem. Each UGCS5 service will depend on a minimum number of other servers, and will ideally be able to be booted and run without any other UGCS5 servers present. This will also ease hardware and software updates, as they will not cause disruptions or dependency issues with any other service.

Proven Technology

Only industry standard and mature technology will be used. Software sponsored by a major company is highly preferred (except ubuntu). Unproven software will not be used, regardless of the compelling features it may have.


All data stored on UGCS should be in standard formats, and ideally be exportable to human readable plaintext. In the event that there is good reason to switch to a different piece of software or system, the data will be easily transferable. Data that is only recognizable by a single piece of software, such as kerberos keys, will not be kept by UGCS core services. All core services must function fully with access to data only in portable or exportable formats.


We will strive to ensure that every component of UGCS5 is as close to ideal as possible. Each sysadmin should stand behind every software package and configuration option present on UGCS (except for things almost impossible to avoid like systemd, python3 and python2 simultaneously, etc.). "It's not too bad" it not good enough, and whatever it is should not be made a core part of UGCS