Installation über Docker bricht beim mounten der krb5.conf Datei ab

[jens-hochberger]

Hallo,

ich habe nachfolgende Fehlermeldung bei der Installatio via Docker. Im Ordner nginx-conf liegt keine krb5.conf Datei, sondern lediglich ein leerer Ordner mit dem Namen krb5.conf

Die Fehlermeldung deutet auch darauf hin, dass versucht wird einen Ordner in eine Datei zu mounten.

-OTOBO:/opt/otobo-docker/nginx-conf/krb5.conf# ls -lsa
insgesamt 8
4 drwxr-xr-x 2 root root 4096 Aug 11 11:24 .
4 drwxr-xr-x 4 root root 4096 Aug 11 10:48 ..

 

-OTOBO:/opt/otobo-docker# docker-compose up –detach
Removing otobo_nginx_1
otobo_redis_1 is up-to-date
otobo_elastic_1 is up-to-date
otobo_db_1 is up-to-date
otobo_web_1 is up-to-date
otobo_daemon_1 is up-to-date
Recreating 224f15b59fab_otobo_nginx_1 … error

ERROR: for 224f15b59fab_otobo_nginx_1 Cannot start service nginx: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting „/opt/otobo-docker/nginx-conf/krb5.conf“ to rootfs at „/etc/krb5.conf“ caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Weiß jemand rat?

Viele Grüße

Jens

• Dieses Thema wurde geändert vor 2 Jahre, 1 Monat von jens-hochberger.

[alexander-fuhr]

Hallo,

OTOBO Version: 10.0.11

Auch bei mir wird die selber Fehlermeldung angezeigt. Ich habe auch vor Kerberos SSO zu nutzen. Leider ist die Funktion nirgendwo beschrieben.

 

Bitte um Hilfe.

Gruß

Alexander

 

 

 

[bes]

Hallo,

ich habe den Betrieb von OTOBO mit Kerberos nicht selbst ausprobiert, darum ist das folgende ohne Gewähr.

Im Docker Image otobo-nginx-kerberos-webproxy wurde das Debian Paket krb5-user installiert. Siehe https://github.com/RotherOSS/otobo/blob/rel-10_0/otobo.nginx-kerberos.dockerfile. krb5-user hat als Abhängigkeit krb5-config, https://packages.debian.org/de/sid/krb5-config, welches die Datei /etc/krb5.conf enthält. Kurz gesagt: im Docker Image existiert die Datei /etc/krb5.conf.

In der Datei .env gibt es zwei relevante Konfigurationen.

• OTOBO_NGINX_KERBEROS_CONFIG=/opt/otobo-docker/nginx-conf/krb5.conf
• COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-https-kerberos.yml

Es ist also konfiguriert dass docker-compose/otobo-override-https-kerberos.yml beim Start der Container mit verwendet wird. In docker-compose/otobo-override-https-kerberos.yml gibt es die Konfiguration:

volumes:
- otobo_nginx_ssl:/etc/nginx/ssl
- ${OTOBO_NGINX_KERBEROS_CONFIG:?err}:/etc/krb5.conf:rw
- ${OTOBO_NGINX_KERBEROS_KEYTAB:?err}:/etc/krb5.keytab:rw

Dadurch soll die lokale Datei ${OTOBO_NGINX_KERBEROS_CONFIG} im Container als Datei /etc/krb5.conf sichtbar gemacht werden. Die Variable ${OTOBO_NGINX_KERBEROS_CONFIG} wird dabei mit dem Pfad aus .env ersetzt.

Die Fehlermeldung besagt besagt das ein Verzeichnis nicht als Datei gemounted werden. Das ist auch nachvollziehbar, da /opt/otobo-docker/nginx-conf/krb5.conf wirklich ein Verzeichnis ist und /etc/krb5.conf im Container wirklich eine Datei ist. Die Frage ist also woher das Verzeichnis kommt. Ich vermute dass Docker-Compose der Verzeichnis /opt/otobo-docker/nginx-conf/krb5.conf  selbst angelegt hat und danach in den Konflikt gelaufen ist. Siehe https://stackoverflow.com/questions/42248198/how-to-mount-a-single-file-in-a-volume?rq=1.

Mein ungetesteter Lösungsvorschlag:

• rmdir /opt/otobo-docker/nginx-conf/krb5.conf
• copy meine_krb5.conf /opt/otobo-docker/nginx-conf/krb5.conf
• dasselbe für /opt/otobo-docker/nginx-conf/krb5.keytab
• docker-compose restart

Viele Grüße,

Bernhard

 

 

 

 

 

 

 

 

[alexander-fuhr]

Hallo Bernhard,

vielen Dank. Ich war tatsächlich schon soweit, wie du beschrien hast.

Gruß

Alexander

 

 

• Diese Antwort wurde geändert vor 2 Jahre, 1 Monat von alexander-fuhr.

[alexander-fuhr]

Hallo,

ich versuche OTOBO 10.0.11 mit Kerberos ins Betrieb zu fahren. Leider klappt es nicht. Hier ist die Fehlermeldung:

• tail -f var/log/otobo.log

[Mon Aug 23 12:24:13 2021][Error][Kernel::System::Cache::Get][295] Need Key!
[Mon Aug 23 12:24:13 2021][Error][Kernel::System::Auth::LDAP::Auth][131] Need User!
[Mon Aug 23 12:24:13 2021][Error][Kernel::System::User::UserLookup][953] Need UserLogin or UserID!
[Mon Aug 23 12:24:13 2021][Error][Kernel::System::Cache::Get][295] Need Key!

und meine Configs:

• /Config.pm

$Self->{‚AuthModule1‘} = ‚Kernel::System::Auth::LDAP‘; # funktioniert

$Self->{‚AuthModule‘} = ‚Kernel::System::Auth::HTTPBasicAuth‘; # funktioniert nicht

 

• /krb5.conf

[libdefaults]
default_realm = DOT-NETZ.DE

kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

fcc-mit-ticketflags = true

[realms]
DOT-NETZ.DE = {
kdc = W.DOT-NETZ.DE
admin_server = W.DOT-NETZ.DE
default_domain = DOT-NETZ.DE
}

[domain_realm]
.DOT-NETZ.DE = DOT-NETZ.DE
DOT-NETZ.DE = DOT-NETZ.DE

 

• /.env

COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-https-kerberos.yml

# Kerberos Options

# Kerberos keytab
OTOBO_NGINX_KERBEROS_KEYTAB=/opt/otobo-docker/nginx-conf/krb5.keytab

# Kerberos config
OTOBO_NGINX_KERBEROS_CONFIG=/opt/otobo-docker/nginx-conf/krb5.conf

# Kerberos Service Name

OTOBO_NGINX_KERBEROS_SERVICE_NAME=HTTP/L.DOT-NETZ.DE

# Kerberos REALM

OTOBO_NGINX_KERBEROS_REALM=W.DOT-NETZ.DE

 

Hat jemanden die Idee woran Problem liegen kann?

 

Gruß

Alexander

[Andreas Erhard]

Hallo Alexander,

ich scheitere auch gerade dabei, die Kerberos Auth mit otobo-docker zum Laufen zu bekommen.
Hast du bei dir in den Logs etwas gefunden, das auf einen Fehler hinweist?

docker-compose logs nginx

Bei mir sieht es so aus, als würde die Kerberos Auth gar nicht aktiviert sein.

Wenn ich docker-compose exec nginx bash mache und dann im Container schaue, scheint Kerberos grundsätzlich konfiguriert zu sein, weil k5srvutil list das korrekte Principal anzeigt. In der Datei /etc/nginx/conf.d/otobo_nginx.conf ist der Abschnitt für Kerberos aber auskommentiert.

location / {
# Example to use Kerberos SSO
# proxy_set_header REMOTE_USER $remote_user;
# auth_gss on;
# auth_gss_keytab ${OTOBO_NGINX_KERBEROS_KEYTAB};
# auth_gss_service_name HTTP/server.MY.DOMAIN;
# auth_gss_realm MY.DOMAIN;
# auth_gss_allow_basic_fallback on;
# EO Kerberos SSO Example

Was mich daran zusätzlich wundert, ist die Tatsache, dass ${OTOBO_NGINX_KERBEROS_KEYTAB} dort nicht aufgelöst wurde. Sieht das bei dir ähnlich aus?

Für mich wirkt es fast so, als ob es dort noch einen Bug gibt. Und zumindest eine minimale Dokumentation würde nicht schaden. Vielleicht können wir das in der offiziellen Doku über einen Pull-Request ergänzen.

Viele Grüße
Andreas

[alexander-fuhr]

Hallo Andreas,

bei mir sieht es genauso wie bei dir, bis auf

/etc/nginx/conf.d/otobo_nginx.conf

location / {
# Example to use Kerberos SSO
# proxy_set_header REMOTE_USER $remote_user;
# auth_gss on;
# auth_gss_keytab ${OTOBO_NGINX_KERBEROS_KEYTAB};
# auth_gss_service_name ${OTOBO_NGINX_KERBEROS_SERVICE_NAME};
# auth_gss_realm ${OTOBO_NGINX_KERBEROS_REALM};
# auth_gss_allow_basic_fallback on;
# EO Kerberos SSO Example

Hast Du zufällig schon einen Lösung gefunden?

Grüß

Alexander

 

[Autor]

Beiträge