sysdba issue in container

[dimakievua]

Hello Jacob, I found issue when start container based on your image of firebird 3.x. When I add it to docker compose by:

firebird:
    image: jacobalberty/firebird:3.0.2
    container_name: firebird
    hostname: firebird
    volumes:
      - ./database:/databases
      - ./conf/firebird.conf:/firebird/etc/firebird.conf
    environment:
      - ISC_PASSWORD=masterkey

Config:

grep -v '^#' code/hb/docker_3/firebird/conf/firebird.conf | grep -v '^$' 
DatabaseAccess = Restrict /databases
WireCrypt = Enabled

And when container started I found in logs:

docker-compose logs firebird Attaching to helsi_firebird firebird_1 | Statement failed, SQLSTATE = 08001 firebird_1 | I/O error during "open" operation for file "employee" firebird_1 | -Error while trying to open file firebird_1 | -No such file or directory firebird_1 | Use CONNECT or CREATE DATABASE to specify a database firebird_1 | Use CONNECT or CREATE DATABASE to specify a database firebird_1 | Use CONNECT or CREATE DATABASE to specify a database

Inside container impossible to restore database backup from /databases I found place where it failed:

if [ ! -f "${VOLUME}/system/security3.fdb" ]; then
    cp "${PREFIX}/skel/security3.fdb" "${VOLUME}/system/security3.fdb"
    file_env 'ISC_PASSWORD'
    if [ -z ${ISC_PASSWORD} ]; then
       ISC_PASSWORD=$(createNewPassword)
       echo "setting 'SYSDBA' password to '${ISC_PASSWORD}'"
    fi
    ${PREFIX}/bin/isql -user sysdba employee <<EOL
create or alter user SYSDBA password '${ISC_PASSWORD}';
commit;
quit;
EOL

If I replace employee with "${VOLUME}/system/security3.fdb" everything ok.

root@firebird:/# ls -la "${VOLUME}/system/security3.fdb"
-rw-r----- 1 root root 1605632 Dec  6 13:14 /firebird/system/security3.fdb
root@firebird:/# ${PREFIX}/bin/isql -user sysdba employee
Statement failed, SQLSTATE = 08001
I/O error during "open" operation for file "employee"
-Error while trying to open file
-No such file or directory
Use CONNECT or CREATE DATABASE to specify a database
SQL> exit;
root@firebird:/# ${PREFIX}/bin/isql -user sysdba /firebird/system/security3.fdb <<EOL
create or alter user SYSDBA password 'masterkey';
commit;
quit;
EOL
root@firebird:/# 

Such strange behavior observed on 3 PC already and I'm trying not to update image. Could you please check this issue and fix it or propose workaround?

Thank you in advance. Dmitriy

[jacobalberty]

Quick tip: when posting multi-line things on git hub comments, use triple backticks (```) instead of a single (`)

Ok. I'm not able to reproduce your issue and I am not 100% sure why, have you overwritten databases.conf in /firebird/etc somehow? The only thing I see you change is firebird.conf and I don't see where it can affect accessing employee.fdb, but maybe a copy of your firebird.conf would help as well

Either way I believe replacing employee with ${PREFIX}/examples/empbuild/employee.fdb is probably the best fix.

I'm using this guide as a template for the actions and they call for accessing the example employee database when initializing the security database. I assume either because security3.fdb may not necessarily exist yet or to avoid locking it.

I'm doing a build and test cycle now just to make sure it doesn't break other things, but without more information I can not accurately reproduce your specific issue to ensure it is fixed on my own.

[jacobalberty]

Ok the default restrict blocks using a direct path to employee.fdb anyway so wouldn't work. I noticed at the bottom of the guide it says

Since Firebird 2, users—including SYSDBA—could not log in to the security database directly. With Firebird 3 it is possible to establish a direct, embedded connection to the security database. With the appropriate configuration parameters, you can control the ability to connect remotely to other security databases.

So for firebird 3+ it looks lke using ${VOLUME}/system/security3.fdb is the correct solution.

Still no idea why you can't access the employee alias though, nothing in your configuration implies it would be blocked.

The fix is being built on the docker hub mow.

[dimakievua]

Jacob,

That's really strange, because we are using you image to build containers on 10+ hosts and only 3 now affected. I have been using 3.0.2 from the time it was released and only 2 days ago this issue appeared. So root cause is found, but why it reproduced not always but time by time it's still question.

Thank you for help and have a good day!

[jacobalberty]

Finally wrapped my head around why its happening, the docker-entrypoint only checks for the existing of /firebird/etc not individual files under it, so if any file exists under it then it doesn't copy the rest.

So when you include firebird.conf then databases.conf doesn't get created. ergo theres no alias to employee. The fix I already put in works around that in probably the best way, I could watch for each file missing and only copy the missing ones, but perhaps theres a reason one wouldn't want the rest, I think in this case it might be best to stick with how it is.