an einer Schule haben wir über die Web-Konsole anstehende Updates des UCS-Servers vorgenommen. Ausgehend von Version 4.0-4 haben wir uns bis 4.2-0 problemlos durchgehangelt (abgesehen von Meldungen über zu wenig Platz in /boot, welche wir jedoch gelöst bekamen).
Erst mit dem letzten Update auf 4.2-1 ist uns ein Anmelden am Web-Portal nicht mehr möglich. Die Domänendienste arbeiten offenbar noch einwandfrei, denn zumindest ein Client kann sich problemlos anmelden und hat auch Zugriff auf seinen freigegebenen Verzeichnisse.
Ich habe mich schon durch verschiedene Log-Dateien in /var/log und /var/log/univention durchgearbeitet, finde allerdings nirgends Hinweise, woher die Probleme kommen.
Es stellt sich so dar, dass das Anmeldefenster erscheint, nach Eingabe der Daten denkt man für einen Moment es geht weiter, dann jedoch erscheint wieder das Anmeldefenster. Fehlermeldung wird keine ausgespuckt.
Hat jemand einen Hinweis, in welchen Log-Dateien zu suchen wäre? Nachgesehen habe ich bereits erfolglos in:
/var/log/auth.log
/var/log/univention/management-console-server.log
/var/log/univention/updater.log (durch alle Updates verdammt umfangreich und schwierig, wenn man nicht weiß wonach man sucht)
/var/log/univention/join.log
/var/log/univention/system-stats.log
/var/log/univention/management-console-module-ucr.log
/var/log/univention/management-console-module-udm.log
/var/log/univention/management-console-web-server.log
/var/log/univention/management-console-server.log
/var/log/apache2/error.log
/var/log/apache2/access.log
/var/log/Messages
Wusste noch gar nicht dass man tail mit Wildcard nutzen kann… Mal wieder was gelernt. Hier die Ausgabe:
02.08.17 18:10:55.932 MAIN ( PROCESS ) : The UMC web server is still run ning. Will wait for 5 seconds
02.08.17 18:12:19.528 DEBUG_INIT
03.08.17 08:41:56.969 MAIN ( PROCESS ) : SessionClient(0x7f1e2fa9e750): _authenticated: success=True status=200 message=None
03.08.17 09:53:18.703 MAIN ( PROCESS ) : SessionClient(0x7f1e2f8b4ad0): _authenticated: success=True status=200 message=None
03.08.17 09:53:32.445 MAIN ( PROCESS ) : SessionClient(0x7f1e2f8c7790): _authenticated: success=True status=200 message=None
03.08.17 13:27:29.913 MAIN ( PROCESS ) : SessionClient(0x7f1e2f8d3510): _authenticated: success=True status=200 message=None
03.08.17 13:44:08.917 MAIN ( PROCESS ) : SessionClient(0x7f1e2fa95e50): _authenticated: success=True status=200 message=None
03.08.17 13:44:38.015 MAIN ( PROCESS ) : SessionClient(0x7f1e2f8db910): _authenticated: success=True status=200 message=None
03.08.17 13:44:48.027 MAIN ( PROCESS ) : SessionClient(0x7f1e2f8dbb90): _authenticated: success=True status=200 message=None
03.08.17 14:02:58.655 MAIN ( PROCESS ) : SessionClient(0x7f1e2fa30f10): _authenticated: success=True status=200 message=None
04.08.17 08:54:32.960 MAIN ( PROCESS ) : SessionClient(0x7f1e2fa3bed0): _authenticated: success=True status=200 message=None
Kein Fehler, so wie es aussieht, trotzdem erscheint wieder nur die Anmeldemaske erneut…
nach jedem Upgrade-Step wurde der Server neu gestartet, die Anmeldung am Web-Frontend hinterher war auch immer problemlos möglich und der nächste Upgrade-Step konnte gemacht werden.
root@srv-XXX-01:~# univention-check-join-status
Joined successfully
root@srv-XXX-01:~#
root@srv-XXX-01:~# systemctl status apache2 univention-management-console-server univention-management-console-web-server
● apache2.service - LSB: Apache2 web server
Loaded: loaded (/etc/init.d/apache2)
Active: active (running) since Mi 2017-08-02 18:12:23 CEST; 1 day 18h ago
Process: 36589 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS)
CGroup: /system.slice/apache2.service
├─ 7950 /usr/sbin/apache2 -k start
├─36618 /usr/sbin/apache2 -k start
├─36619 /usr/sbin/apache2 -k start
├─36620 /usr/sbin/apache2 -k start
├─36621 /usr/sbin/apache2 -k start
├─36622 /usr/sbin/apache2 -k start
├─39185 /usr/sbin/apache2 -k start
├─39186 /usr/sbin/apache2 -k start
├─39188 /usr/sbin/apache2 -k start
├─39190 /usr/sbin/apache2 -k start
└─39191 /usr/sbin/apache2 -k start
Aug 02 18:12:23 srv-XXX-01 apache2[7931]: Starting web server: apache2.
Aug 02 18:12:23 srv-XXX-01 systemd[1]: Started LSB: Apache2 web server.
Aug 02 18:12:25 srv-XXX-01 systemd[1]: Reloading LSB: Apache2 web server.
Aug 02 18:12:25 srv-XXX-01 apache2[8009]: Reloading web server: apache2.
Aug 02 18:12:25 srv-XXX-01 systemd[1]: Reloaded LSB: Apache2 web server.
Aug 03 07:36:26 srv-XXX-01 systemd[1]: Reloading LSB: Apache2 web server.
Aug 03 07:36:26 srv-XXX-01 apache2[41587]: Reloading web server: apache2.
Aug 03 07:36:26 srv-XXX-01 systemd[1]: Reloaded LSB: Apache2 web server.
Aug 04 07:54:01 srv-XXX-01 systemd[1]: Reloading LSB: Apache2 web server.
Aug 04 07:54:01 srv-XXX-01 apache2[36589]: Reloading web server: apache2.
Aug 04 07:54:01 srv-XXX-01 systemd[1]: Reloaded LSB: Apache2 web server.
● univention-management-console-server.service - LSB: Univention Management Console Server
Loaded: loaded (/etc/init.d/univention-management-console-server)
Drop-In: /lib/systemd/system/univention-management-console-server.service.d
└─killmode.conf
Active: active (running) since Mi 2017-08-02 18:12:08 CEST; 1 day 18h ago
Process: 8978 ExecReload=/etc/init.d/univention-management-console-server reload (code=exited, status=0/SUCCESS)
CGroup: /system.slice/univention-management-console-server.service
└─7555 /usr/bin/python2.7 /usr/sbin/univention-management-console-server start
Aug 03 14:02:58 srv-XXX-01 python2.7[7555]: nss_ldap: reconnected to LDAP server ldap://srv-XXX-01.dom-XXX.intranet:7389 after 1 attempt
Aug 04 08:54:32 srv-XXX-01 python2.7[7555]: saml_msg is too small: minlength = 128
Aug 04 08:54:32 srv-XXX-01 python2.7[7555]: nss_ldap: reconnecting to LDAP server...
Aug 04 08:54:32 srv-XXX-01 python2.7[7555]: nss_ldap: reconnected to LDAP server ldap://srv-XXX-01.dom-XXX.intranet:7389 after 1 attempt
Aug 04 12:36:56 srv-XXX-01 python2.7[7555]: saml_msg is too small: minlength = 128
Aug 04 12:36:56 srv-XXX-01 python2.7[7555]: nss_ldap: reconnecting to LDAP server...
Aug 04 12:36:56 srv-XXX-01 python2.7[7555]: nss_ldap: reconnected to LDAP server ldap://srv-XXX-01.dom-XXX.intranet:7389 after 1 attempt
Aug 04 12:38:58 srv-XXX-01 python2.7[7555]: saml_msg is too small: minlength = 128
Aug 04 12:39:38 srv-XXX-01 python2.7[7555]: saml_msg is too small: minlength = 128
Aug 04 12:40:39 srv-XXX-01 python2.7[7555]: saml_msg is too small: minlength = 128
● univention-management-console-web-server.service - LSB: Univention Management Console Web Server
Loaded: loaded (/etc/init.d/univention-management-console-web-server)
Drop-In: /lib/systemd/system/univention-management-console-web-server.service.d
└─killmode.conf
Active: active (running) since Mi 2017-08-02 18:12:19 CEST; 1 day 18h ago
CGroup: /system.slice/univention-management-console-web-server.service
└─7812 /usr/bin/python2.7 /usr/sbin/univention-management-console-web-server start
Aug 02 18:12:19 srv-XXX-01 univention-management-console-web-server[7800]: Starting Univention Management Console Web Server: univention-management-console-web-server.
Aug 02 18:12:19 srv-XXX-01 systemd[1]: Started LSB: Univention Management Console Web Server.
root@srv-XXX-01:~#
Monitore ich sämtliche log-Veränderungen in /var/log/*.log beim Anmeldevorgang fällt auf, dass auch hier der Eintrag wie im Quote oben erschein:
==> /var/log/user.log <==
Aug 4 12:40:39 srv-XXX-01 python2.7: saml_msg is too small: minlength = 128
mach doch bitte noch mal ein screen univention-upgrade --ignore-ssh auf der Konsole um auch die letzten Errata auf dem System zu haben.
Die Meldung ‘saml_msg is too small: minlength = 128’ sollte erstmal nicht mit dem Problem zu tun haben, die habe ich schon oft gesehen ohne dass es zu Einschränkungen kam.
Prüf bitte auch mal die Zertifikate: univention-certificate list univention-certificate check -name <hostname_FQDN>
bzw. das RootCA via: openssl x509 -in /etc/univention/ssl/ucsCA/CAcert.pem -text -noout | grep -A4 Issuer:
Starting univention-upgrade. Current UCS version is 4.2-1 errata122
Checking for local repository: none
Checking for package updates: none
Checking for app updates: none
Checking for release updates: none
root@srv-XXX-01:/etc/samba/shares.conf.d# univention-certificate list
List all certificates
01 unassigned-hostname.unassigned-domain
02 srv-XXX-01.dom-XXX.intranet
03 ucs-sso.dom-XXX.intranet
root@srv-XXX-01:/etc/samba/shares.conf.d# univention-certificate check -name srv-XXX-01.dom-XXX.intranet
Certificate "srv-XXX-01.dom-XXX.intranet" is valid
root@srv-XXX-01:/etc/samba/shares.conf.d# univention-certificate check -name ucs-sso.dom-XXX.intranet Certificate "ucs-sso.dom-XXX.intranet" is valid
root@srv-XXX-01:/etc/samba/shares.conf.d# openssl x509 -in /etc/univention/ssl/ucsCA/CAcert.pem -text -noout | grep -A4 Issuer:
Issuer: C=DE, ST=DE, L=DE, O=dom-XXX, OU=Univention Corporate Server, CN=Univention Corporate Server Root CA (ID=tcsIu85S)/emailAddress=ssl@dom-XXX.intranet
Validity
Not Before: Sep 15 06:41:40 2015 GMT
Not After : Sep 13 06:41:40 2020 GMT
Subject: C=DE, ST=DE, L=DE, O=dom-XXX, OU=Univention Corporate Server, CN=Univention Corporate Server Root CA (ID=tcsIu85S)/emailAddress=ssl@dom-XXX.intranet
Mittlerweile war ich an der Schule vor Ort und stellte fest, dass direkt am Server selbst der Aufruf der umc funktioniert. Also liegt es wohl eher an der Apache-Konfiguration bzgl. der Zugriffssteuerung. Vergleich mit einem System an einer anderen Schule, auf dem noch der Stand 4.1 installiert ist, fallen extrem schwer, da sich hier scheinbar an den Konfigurationsdateien einiges getan hat.
Muss gestehen, bin auch nicht der Einrichter des Servers, gleichwohl aber mit der künftigen Betreuung beauftragt und eher mit Skills (rudimentär) im SLES-Bereich beglückt :-).
Tipp an welcher Stelle ich da nachsehen müsste unter /etc/apache2? .htaccess liegt keine unterhalb /var/www/*
erster Anlaufpunkt sind die Apache.logs /var/log/apache2/access.log, /var/log/apache2/error.log
Mit univention-check-templates kann man auch mal schauen ob relevante Templates angepasst wurden. Ein vimdiff <config> <config.dpkg-dist> gibt dann schnell Aufschluß.
Die entscheidende Config sollte /etc/apache2/sites-available/univention.conf sein.
Was sagt denn die Firewall oder der ggf. vorgeschaltete Proxy?