Anmeldung an der Web-Konsole nach Update auf UCS 4.2-1 nicht mehr möglich

umc
german
ucs-4-2
#1

Hallo Forum,

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

Vielen Dank schon einmal für Tipps…

Grüße
Steffen

#2

Hallo, du könntest mal schauen während du dich versuchst anzumelden:

tail -f /var/log/univention/management*.log

#3

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…

#4

Hallo @SVW,

hattest Du nach dem Upgrade auf 4.2 das System neu gestartet und die Join-Scripte via univention-run-join-scripts erneut ausgeführt?

Was sagt univention-check-join-status

Laufen die benötigten Dienste?
systemctrl status apache2 univention-management-console-server univention-management-console-web-server

Bringt ein Neustart der Dienste etwas?
systemctrl restart apache2 univention-management-console-server univention-management-console-web-server

→ Wenn nicht wie lauten die journal-Einträge?

Bitte Browser auch mal neu starten bzw. einen anderen Browser verwenden (Firefox <> Chrome)

#5

Hallo stoeckigt,

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

Grüße und Danke für die Unterstützung

Steffen

#6

Hallo zusammen,

hat noch jemand eine Idee wonach ich schauen könnte?

Grüße

Steffen Blum

#7

Hallo @SVW,

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:

#8

Hallo stoeckigt,

hier die Ausgaben:

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/*

Grüße
Steffen Blum

#9

Hallo @SVW,

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?