Anpassen des DOCUMENT_ROOT bei UCS 4.1 für einen Alias-Eintrag

ucs-4-1
german
apache

#1

Ich habe folgendes Szenario: Ich benutze UCS 4.1 (also Apache 2.2). Auf dem laufen schon ein paar eigene php-Anwendungen. Konfiguriert habe ich das, durch erstellen von zusätzlichen .conf Dateien in dem Verzeichnis /etc/apache2/conf.d/

Diese Dateien sehen (bis auf die Pfade) alle wie folgt aus:

AddHandler cgi-script .cgi .pl
Alias /NETINST "/HDD/SDA254_1000GB/www/NETINST/www/"
<Directory "/HDD/SDA254_1000GB/www/NETINST/www">
        Options Indexes FollowSymLinks Includes ExecCGI
        AllowOverride All
        Order allow,deny
        Allow from all
</Directory>

Jetzt möchte ich einen weitere Anwendung zum Laufen bekommen. Es scheitert aber mit der obengenannten Lösung, weil der PHP-Code immer wieder den “Document_Root” auswertet und dieser dann statt auf “/HDD/SDA254_1000GB/www/NeueApp” auf “/var/www/” verlinked.

Welche Möglichkeit habe ich bei UCS das beim Aufruf von “https://ucs-seerver/NeueApp” die Web-Anwendung korrekt ausgeführt wird?


#2

Moin,

ömm, zeigen Sie doch bitte mal die Konfigurationsdatei für NeueApp. Und die exakte URL, die Sie besuchen. Bei dem, was Sie bisher geschrieben haben, ist nämlich einmal von NETINST und einmal von NeueApp die Rede, und daraus kann man praktisch nichts schließen außer »das passt nicht zusammen«.

Gruß
mosu


#3

Sorry, das kommt vom Copy und Paste, wenn man eh schon genervt ist :wink:

AddHandler cgi-script .cgi .pl
Alias /neueapp "/HDD/SDA254_1000GB/www/NeueApp/"
<Directory "/HDD/SDA254_1000GB/www/NeueApp">
        Options Indexes FollowSymLinks Includes ExecCGI
        AllowOverride All
        Order allow,deny
        Allow from all
</Directory>

Wenn ich dass so kofiguriere, dann kommt als Meldung im /var/log/apache2/error.log:

[Mon Nov 13 15:04:24 2017] [error] [client 192.168.2.163] PHP Warning:  include_once(/var/www//inc/sec_session.class): failed to open stream: No such file or directory in /HDD/SDA254_1000GB/www/neueapp/index.php on line 6
[Mon Nov 13 15:04:24 2017] [error] [client 192.168.2.163] PHP Warning:  include_once(): Failed opening '/var/www//inc/sec_session.class' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /HDD/SDA254_1000GB/www/neueapp/index.php on line 6
[Mon Nov 13 15:04:24 2017] [error] [client 192.168.2.163] PHP Fatal error:  Class 'sec_session' not found in /HDD/SDA254_1000GB/www/neueapp/index.php on line 7

Und der Anfang der /HDD/SDA254_1000GB/www/neueapp/index.php sieht wie folgt aus:

<?php

date_default_timezone_set('Europe/Berlin');
$conf = include_once('_config/config.php');

include_once ($_SERVER['DOCUMENT_ROOT'] . '/inc/sec_session.class');
$sec_session = new sec_session;
if (isset($_POST['stayloggedin'])) {
    $sec_session->sec_session_start(30);
} else {
    $sec_session->sec_session_start();
}

......

#4

Ah. Naja das ist schlicht ein Bug in der Anwendung. Die ist so geschrieben, dass sie ausschließlich direkt in der DocumentRoot installiert werden kann.

Zwei Lösungsmöglichkeiten:

  1. Die PHP-Datei so verändern, dass die include_once-Zeile einfach nur relativ includiert, z.B. include_once('inc/sec_session.class'); (ohne Gewähr, abver das scheint zwei Zeilen darüber ja auch zu klappen)
  2. Beim Webserver einen eigenen VirtualHost nur für diese Anwendung anlegen und die DocumentRoot innerhalb dieses VHosts auf das Verzeichnis setzen, in dem die Anwendung liegt.

Die erste Variante ist nicht updatesicher (im Sinne von man muss nach Updates die gleiche Änderung erneut durchführen), die zweite erfordert mehr Konfigurationsaufwand und DNS-Konfiguration (oder einen anderen Port).

Gruß
mosu


#5

Das hab ich mir gedacht. Meistens sind es ja eine Vielzahl an Dateien, die dabei angepasst werden müssen, wenn man Variante 1 bervorzugt (was aber die sauberte Methode wäre).

Daher wäre eine Beschreibung, wie ich das mit den VirtualHost in UCS anlegen kann. Das ein anderer Port verwendet würde wäre nicht das Problem (also damit meine ich: wäre zu verschmerzen).

Wie würde dann die Konfiguration aussehen? Was muss ich machen? Wird das über das UI gemacht oder auch über das direkte Anpassen der Dateien?


#6

Moin,

die Variante mit eigener Portnummer ist vor allem auch deshalb einfacher, weil sie ohne Konfiguration von DNS-Namen und damit einhergehend von SSL-Zertifikaten auskommt. Also:

Zuerst eine Datei in /etc/apache2/sites-available anlegen, die z.B. testme.conf heißt (Achtung: die Dateiendung ist wichtig!). Inhalt beispielsweise:

Listen 9443

<VirtualHost *:9443>
	SSLEngine on
	SSLProxyEngine on
	SSLProxyCheckPeerCN off
	SSLProxyCheckPeerName off
	SSLCertificateFile /etc/univention/ssl/master.mbu-test.intranet/cert.pem
	SSLCertificateKeyFile /etc/univention/ssl/master.mbu-test.intranet/private.key
	SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem

  DocumentRoot /srv/html/testme

  <Directory /srv/html/testme/>
    DirectoryIndex index.php
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

Wenn eine andere Portnummer als 9443 verwendet werden soll, so müssen natürlich beide Stellen angepasst werden. Die Listen-Direktive sagt, dass Apache überhaupt Verbindungen auf dem Port annehmen soll, und die VirtualHost sagt, dass auf dem Port ein port-basierter virtueller Host konfiguriert ist, der unabhängig vom verwendeten Hostnamen die angegebene Konfiguration nutzt.

Die DocumentRoot- und Directory-Direktiven müssen natürlich an den tatsächlichen Pfad angepasst werden, in dem die Anwendung liegt. Natürlich müssen auch die Pfade zum SSL-Zertifikat und dem dazugehörigen Schlüssel angepasst werden.

Die Directory-Direktive ist auch insofern wichtig, als dass Zugriff auf Dateien & Verzeichnisse standardmäßig verweigert wird. Das Order & Allow sagt dann, dass alle Aufrufer erlaubt sind.

Anschließend muss die Konfiguration noch aktiviert werden:

a2ensite testme
apache2ctl -k graceful
lsof -PniTCP:9443 -sTCP:LISTEN

Der letzte Befehl dient nur der Verifizierung: er sollte einige Zeilen ausspucken, aus denen ersichtlich ist, dass auf Port 9443 tatsächlich der Apache lauscht.

Edit: Das ursprünglich geschriebene Require all granted ist das, was bei Apache 2.4 verwendet wird. UCS 4.1 nutzt aber noch 2.2, daher Anpassung zu Order & Allow. Für ein späteres Update auf UCS 4.2 und damit Apache 2.4 muss der Directory-Block schlicht wie folgt aussehen:

  <Directory /srv/html/testme/>
    DirectoryIndex index.php
    Require all granted
  </Directory>

Gruß
mosu


#7

Vielen Dank für die Ausführliche Mühe der Beschreibung. Leider führt sie nicht zum Erfolg. Ich fange aber vorne an

Wenn ich den Befehl “a2ensite testeme” aufrufe, dann kommt, das die Site “testme” nicht vorhanden ist (habe drauf geachtet, das die dateie testme.conf heißt und in dem Verzeichnis /etc/apache2/sites-available liegt

Daher ein manuelles kopieren von /etc/apache2/sites-available nach /etc/apache2/sites-enbled

Dann als nächtstes:

Syntax error on line 7 of /etc/apache2/sites-enabled/testme.conf:
Invalid command 'SSLProxyCheckPeerName', perhaps misspelled or defined by a module not included in the server configuration

Also die Zeile erstmal deaktiviert - wenn wichtig, dann können wir sie ja wieder aktivieren

Dann den Aufruf der Seite über http://server:9443/ und auch http://server/:9443 gemacht. Im Log kommt es dann zu folgender Meldung:

[Wed Nov 15 17:26:26 2017] [error] [client 192.168.2.163] File does not exist: /var/www/:9443
[Wed Nov 15 17:27:45 2017] [error] [client 192.168.2.163] File does not exist: /var/www/testme:9443
[Wed Nov 15 17:28:11 2017] [error] [client 192.168.2.163] File does not exist: /var/www/testme:9443
[Wed Nov 15 17:28:38 2017] [error] [client 187.180.4.18] File does not exist: /var/www/cgi
[Wed Nov 15 17:28:41 2017] [error] [client 187.180.4.18] File does not exist: /var/www/stssys.htm
[Wed Nov 15 17:28:47 2017] [error] [client 187.180.4.18] script '/var/www/command.php' not found or unable to stat

Vielleicht könnte jemand nochmal einen Blick drauf werfen, warum hier das Umschreiben nicht funktioniert hat bzw. wo ich das einsehen könnte


#8

Der Befehl muss dann ja auch a2ensite testme und nicht »testeme« heißen. Ist ein Typo in meiner Anleitung.

Letztlich macht der Befehl nichts weiter, als in /etc/apache2/sites-enabled einen symbolischen Link auf die Datei in /etc/apache2/sites-available anzulegen. Das können Sie auch manuell machen.

Den Inhalt der Datei habe ich letztlich aus der default-ssl.conf übernommen. Diese sieht bei Apache 2.4 nun mal etwas anders aus als bei Apache 2.2 (Sie verwenden noch 2.2). Daher übernehmen Sie doch einfach den Inhalt selber aus Ihrer default-ssl.conf. Wichtig sind drei Anpassungen:

  1. Ergänzen der Port-Zeile, damit der Webserver auch auf dem anderen Port lauscht
  2. Anpassung der VirtualHost-Zeile, damit die auf die neue Portnummer passt
  3. Ergänzen der DocumentRoot-Zeile
  4. Der Directory-Block ist potenziell auch wichtig.

Gruß
mosu


#9

So, der Stand ist nun folgender:

Ich habe die Datei nicht testme.conf sondern nur testme genannt. Dann war es tatsächlich möglich mit dem Befehl a2ensite testme die Site zu aktivieren.

Die testme sieht jetzt so aus von mir:

Listen 9443

<VirtualHost *:9443>

  Include /etc/apache2/ucs-sites.conf.d

  SSLEngine on
  SSLProxyEngine on
  SSLCertificateFile /etc/univention/ssl/ucs002254.testdom.lan/cert.pem
  SSLCertificateKeyFile /etc/univention/ssl/ucs002254.testdom.lan/private.key
  SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem

  DocumentRoot /HDD/SDA254_1000GB/www/testme
  RedirectMatch ^/$ /

  <Directory /HDD/SDA254_1000GB/www/testme/>
    DirectoryIndex index.php
    Order allow,deny
    Allow from all
  </Directory>

</VirtualHost>

MIt service apache2 restart wird der Webdienst neugestartete und in der error.log findet sich der Hinweis:

[Sat Nov 18 10:55:25 2017] [notice] caught SIGTERM, shutting down
[Sat Nov 18 10:55:26 2017] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sat Nov 18 10:55:26 2017] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Sat Nov 18 10:55:27 2017] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sat Nov 18 10:55:28 2017] [notice] Apache/2.2.22 (Univention) PHP/5.4.45-0.238.201704191554 mod_ssl/2.2.22 OpenSSL/1.0.2k mod_perl/2.0.7 Perl/v5.14.2 configured -- resuming normal operations

Wenn ich die Seite dann mit https://192.168.2.254:9443 oder auch https://ucs002254:9443 aufrufe, dann passiert nichts - Auch kein weiterer Eintrag in der error.log. Die Seite bleibt leer.
Auch nachdem ich den Server komplett neugestartet habe, hat sich in dem Verhalten jetzt nichts mehr verändert

Wenn ich dann service univention-firewall stop eingeben, dann passiert wieder mehr. In der access.log des Apachen findet man dann folgende Einträge:

192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"
192.168.2.163 - - [18/Nov/2017:13:47:13 +0100] "GET /" 400 583 "-" "-"

Aber trotzdem wir die Seite nicht mal ansatzweise in irgendeiner Form angezeigt. Im error.log gibt es keine weiteren Hinweise, die hilfreich wären

Edit: Mittlerweilse bin ich ein Stück weiter gekommen. Nachdem ich die Firewall deaktiviert habe (temporär), benötige ich jetzt noch einen Tipp, wie man den Redirect, der vorher für UCS verwendet werden muss (die Weiterleitung auf “ucs-overview”) für den Virtuellen Host deaktiviert werden kann. Denn dadurch, dass ich das “/” benötige, wird autm. ein “/ucs-overview/” draus


#10

Nehmen Sie diese Zeile raus. Die ist Quark. Sie besagt: bei Zugriff auf / leite auf / weiter, was eine Endlosschleife ist.

Das liegt daran, dass Sie die Standard-UCS-Konfigurationsdateien includieren:

Nehmen Sie auch diese Zeile heraus.

Gruß
mosu