Installation failure on CentOS 7

[ScarabMonkey]

I had this happily running for a few weeks using the Docker install instructions on a CentOS 7 machine - but then a yum update broke it. I updated docker-engine from 1.10.0-1.el7.centos.x86_64 to 1.10.3-1.el7.centos.x86_64 (amongst other things) Now even if I try to do a fresh install on the same box I get no joy, here is the error:

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 351, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 343, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 394, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 445, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", line 93, in handle
    executor = MigrationExecutor(connection, self.migration_progress_callback)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 19, in __init__
    self.loader = MigrationLoader(self.connection)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 47, in __init__
    self.build_graph()
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 182, in build_graph
    self.applied_migrations = recorder.applied_migrations()
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/recorder.py", line 59, in applied_migrations
    self.ensure_schema()
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/recorder.py", line 49, in ensure_schema
    if self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()):
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 164, in cursor
    cursor = self.make_cursor(self._cursor())
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 135, in _cursor
    self.ensure_connection()
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 130, in ensure_connection
    self.connect()
  File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 97, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 130, in ensure_connection
    self.connect()
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 119, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/sqlite3/base.py", line 204, in get_new_connection
    conn = Database.connect(**conn_params)
django.db.utils.OperationalError: unable to open database file

[grahamgilbert]

It can't connect to your database. Depending on which you use, make sure it's either accessible for an external db or readable if using sqlite. Other than that I'd have to guess, as we're an Ubuntu / Docker shop here.

[ScarabMonkey]

I tried doing a fresh install using these instructions pointing to a new directory for the db/plugins - still the same: https://github.com/salopensource/sal/wiki/Getting-Started

[grahamgilbert]

django.db.utils.OperationalError: unable to open database file

This says Sal isn't able to open your database. Check permissions on that.

[ScarabMonkey]

well the permissions on there are really strange, that seems to be what the postgres container does:

[merlin@oxford sal]$ sudo ls -l ~sal
[sudo] password for merlin: 
total 4
drwx------. 18 polkitd root 4096 Apr 20 11:51 db
drwxr-xr-x.  2      33   33    6 Apr 20 11:51 plugins
[merlin@oxford sal]$ sudo ls -l ~sal/db
total 56
drwx------. 6 polkitd ssh_keys    50 Apr 20 11:50 base
drwx------. 2 polkitd ssh_keys  4096 Apr 20 11:52 global
drwx------. 2 polkitd ssh_keys    17 Apr 20 11:50 pg_clog
drwx------. 2 polkitd ssh_keys     6 Apr 20 11:50 pg_dynshmem
-rw-------. 1 polkitd ssh_keys  4498 Apr 20 11:50 pg_hba.conf
-rw-------. 1 polkitd ssh_keys  1636 Apr 20 11:50 pg_ident.conf
drwx------. 4 polkitd ssh_keys    37 Apr 20 11:50 pg_logical
drwx------. 4 polkitd ssh_keys    34 Apr 20 11:50 pg_multixact
drwx------. 2 polkitd ssh_keys    17 Apr 20 11:51 pg_notify
drwx------. 2 polkitd ssh_keys     6 Apr 20 11:50 pg_replslot
drwx------. 2 polkitd ssh_keys     6 Apr 20 11:50 pg_serial
drwx------. 2 polkitd ssh_keys     6 Apr 20 11:50 pg_snapshots
drwx------. 2 polkitd ssh_keys     6 Apr 20 11:51 pg_stat
drwx------. 2 polkitd ssh_keys    60 Apr 20 12:05 pg_stat_tmp
drwx------. 2 polkitd ssh_keys    17 Apr 20 11:50 pg_subtrans
drwx------. 2 polkitd ssh_keys     6 Apr 20 11:50 pg_tblspc
drwx------. 2 polkitd ssh_keys     6 Apr 20 11:50 pg_twophase
-rw-------. 1 polkitd ssh_keys     4 Apr 20 11:50 PG_VERSION
drwx------. 3 polkitd ssh_keys    58 Apr 20 11:50 pg_xlog
-rw-------. 1 polkitd ssh_keys    88 Apr 20 11:50 postgresql.auto.conf
-rw-------. 1 polkitd ssh_keys 21288 Apr 20 11:50 postgresql.conf
-rw-------. 1 polkitd ssh_keys    37 Apr 20 11:51 postmaster.opts
-rw-------. 1 polkitd ssh_keys    85 Apr 20 11:51 postmaster.pid

But it must have been able to write there ... otherwise these files wouldn't exist :)

[ScarabMonkey]

This is the script I made for creating these containers:

echo starting postgres-sal
docker run -d --name="postgres-sal" \
  -v /home/sal/db:/var/lib/postgresql/data \
  -e DB_NAME=sal \
  -e DB_USER=admin \
  -e DB_PASS=password \
  --restart="always" \
  grahamgilbert/postgres:9.4.5

echo starting sal
docker run -d --name="sal" \
  -p 8000:8000 \
  --link postgres-sal:db \
  -v /home/sal/plugins:/home/docker/sal/plugins \
  -e ADMIN_PASS=pass \
  -e DB_NAME=sal \
  -e DB_USER=admin \
  -e DB_PASS=password \
  --restart="always" \
  macadmins/sal:2.5.1.628

[ScarabMonkey]

Interesting ... looks like a problem with the 'link':

[merlin@oxford sal]$ docker inspect -f "{{ .HostConfig.Links }}" sal
[]

as a counterpoint this is the response from a different container on the same machine:

[merlin@oxford sal]$ docker inspect -f "{{ .HostConfig.Links }}" wekan
[/wekan-mongodb:/wekan/db]

[grahamgilbert]

Cool, so a docker problem rather than Sal then?

[ScarabMonkey]

Yes, I guess so ... though it relates to the Sal installation instructions :)

[grahamgilbert]

What specifically needs to be changed?

[ScarabMonkey]

Not sure as I haven't got this working yet - but apparently 'links' are deprecated and we should be using 'networks' - I'm currently trying some iterations (no joy yet). https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/

[ScarabMonkey]

I daresday this issue should really be moved to https://github.com/macadmins/sal It is a sal-docker issue, not a sal issue...

[grahamgilbert]

The docker image is built directly off this repo. I use an external database (RDS), so haven't run into this - would appreciate hearing your findings.

[jby]

I'm now seing this as well...

Docker logs gives this: docker logs postgres-sal chmod: changing permissions of ‘/var/lib/postgresql/data’: Permission denied

How is it trying to chmod what it thinks is /var/lib/postgres/data (really /usr/local/sal_data if following your instructions)?