[Conjur OSS - get started guide] Can't login to conjur after docker-compose restart

[andresguisado]

Hi,

I am not able to login to conjur anymore after docker-compose restart .

To reproduce the issue:

1. Complete all steps of the Get started guide
2. docker-compose stop
3. docker-compose up -d
4. docker-compose exec client conjur authn login -u Dave@BotApp
   or
   docker-compose exec client conjur authn login -u admin

Result: error: Failed to open TCP connection to conjur:80 (Connection refused - connect(2) for "conjur" port 80)

If I am running docker-compose exec conjur conjurctl account create andres > admin_data again it says andres account already exist.

Conjur Account and URL didn’t change.

Thank you.

[sgnn7 (Srdjan Grubor)]

Hey @andresguisado,
Conjur quick-start does not use permanent volumes for database storage as it is mainly a quick way to start working on Conjur. Because of this, when you restart your containers, the data in your environment will need to be recreated. If you want a quick fix for this where the data is saved through reboots of containers, you can modify the docker-compose.yaml and add that in.

Original snippet:

  database:
    image: postgres:9.4
    container_name: postgres_database
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust

Persistent on-host storage:

  database:
    image: postgres:9.4
    container_name: postgres_database
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
    volumes:
      - <HOST PATH THAT IS WRITABLE BY CONTAINER>:/var/lib/postgresql/data

[andresguisado]

Hi Sedjan,

Thank you for your reply.

I added the docker volume in the docker-compose as follows:

Then, I ran the get started guide from scratch and when I am creating the Conjur account and initializing the admin user, I have got the following error in the admin_data output file:

docker-compose exec conjur conjurctl account create myConjurAccount > admin_data

So, I don’t get the admin API Key to be able to login to Conjur OSS.

Thank you.

[andresguisado]

Hi again,

I forgot to apply full writable permissions:

chmod 777 to /Users/andresguisado/postgresql_conjur

Now, I got the API Key for admin user

However, by configuring docker volumes in the docker-compose as above and restarting the containers with docker-compose, it is still showing the same error:

error: Failed to open TCP connection to conjur:80 (Connection refused - connect(2) for "conjur" port 80)

Thank you

[sgnn7 (Srdjan Grubor)]

@andresguisado Hmm… not sure what could be happening there as the info should have been retained. I can try running that here locally and I’ll let you know what I find.

[dane (Dane LeBlanc)]

@andresguisado, thank you for the detailed info on reproducing this issue!

I think this is a bug in Conjur. If you take a look at the conjur container logs after
the services are brought up with docker-compose up -d, there’s one telling line:

A server is already running. Check /opt/conjur-server/tmp/pids/server.pid.

For some reason, the PID that’s stored in /opt/conjur-server/tmp/pids/server.pid is
not getting properly cleaned when the conjur container is stopped & restarted
after a connection/authentication has been established. There seems to be
a history or state in Conjur that keeps track of connections/authentications, and
that’s checked before clearing the server.pid file. I have to do some digging in
the code to see why that is so.

For now, what you could do is to add one step to your workflow: Completely remove the Conjur container, i.e.:

dockercompose rm -f conjur

after doing docker-compose stop, and before doing docker-compose up -d. This should remove
the container completely (i.e. delete all of its state).

Here’s an example session where I recreate and then recover from this error:

dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose exec client conjur authn login -u admin
Please enter admin's password (it will not be echoed): 
error: Failed to open TCP connection to conjur:80 (Connection refused - connect(2) for "conjur" port 80)
dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose stop conjur
Stopping conjur_server ... done
dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose rm -f conjur
Going to remove conjur_server
Removing conjur_server ... done
dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose up -d conjur
postgres_database is up-to-date
Creating conjur_server ... done
dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose exec client conjur authn login -u admin
Please enter admin's password (it will not be echoed): 
Logged in
dane@dane-vbox:~/cyberark2/conjur-quickstart$

[dane (Dane LeBlanc)]

@andresguisado, @sgnn7 had a better solution:
Instead of using:

docker-compose stop

in your workflow, use:

docker-compose down

Using docker-compose down clears container state, but the Conjur database data is preserved in the host volume.

[dane (Dane LeBlanc)]

@andresguisado, here’s an example session:

dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose exec client conjur list variables
[
  "myConjurAccount:policy:root",
  "myConjurAccount:policy:BotApp",
  "myConjurAccount:user:Dave@BotApp",
  "myConjurAccount:host:BotApp/myDemoApp",
  "myConjurAccount:variable:BotApp/secretVar"
]
dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose down

< = = = SNIP = = = >

dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose up -d

< = = = SNIP = = = >

dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose exec client conjur init -u conjur -a myConjurAccount
Wrote configuration to /root/.conjurrc
dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose exec client conjur authn login -u admin
Please enter admin's password (it will not be echoed): 
Logged in
dane@dane-vbox:~/cyberark2/conjur-quickstart$ docker-compose exec client conjur list variables
[
  "myConjurAccount:policy:root",
  "myConjurAccount:policy:BotApp",
  "myConjurAccount:user:Dave@BotApp",
  "myConjurAccount:host:BotApp/myDemoApp",
  "myConjurAccount:variable:BotApp/secretVar"
]
dane@dane-vbox:~/cyberark2/conjur-quickstart$ 

[andresguisado]

Hi @dane

Thank you for the workaround!

Let me know when a github issue/PR has been created to fix this.

Thank you.