* switch to harpoon installer
* switch to `gcr.io/stacksmith-images/ubuntu:14.04` base image
* removed unused files
* switch to `gcr.io/stacksmith-images/ubuntu:14.04` base image
* organize dockerfile for stacksmith (#2)
* verify checksum in harpoon commands
* removed `BITNAMI_APP_DIR` macro
* removed `BITNAMI_APP_VOL_PREFIX` macro
* moved hacks to `app-entrypoint.sh`
* organize dockerfile for stacksmith
* tests: updated
* Bump version (#3)
* upgrade to `gcr.io/stacksmith-images/ubuntu:14.04-r06`
* upgrade to `postgresql-9.4.5-1`
* password for `postgres` user is now optional
* upgrade to `postgresql-9.4.5-2`
* organize dockerfile
* ignore `.git/` and `tests/` directories in docker builds
* ignore `pkg-cache/` in git
* add `/opt/bitnami/$BITNAMI_APP_NAME/sbin` to `PATH`
* upgrade to `gcr.io/stacksmith-images/ubuntu:14.04-r07` baseimage
* tests: cannot login as postgres user without a password
* add `POSTGRES_DB` env param to create database
* add `POSTGRES_USER` env param to create custom user
* add parameters to support master/slave replication
* update to postgresql-9.5.3-0
* readme: updated
* updated to `postgresql-9.5.3-1`
If user does not mount the `conf/` volume and instead only mounts the
`data/` volume, the postgres server would not allow connections from
users when the container is recreated using existing volumes because the
access information (which is created only on the firstrun) is stored in
the `conf/` volume which would be lost on recreation. This is also true
for replication users.
To resolve this we moved the basic default configurations to the
`post-install.sh`, including the `pg_hba.conf` configurations that
allows database and replication users to login using md5 authentication.
chown'ing the `conf/`, `data/` and `logs/` volumes at the begining of
the initialization ensures that no permission issues are encountered
during initialization.
