Beiträge von drpmicha

Hallo,

mit chroot habe ich gestern noch einige Stunden rumgespielt. Prinzipiell funktioniert das auch.
Allerdings muss ich hier Herrn Keppler recht geben. Durch den Chroot hat der Shell-User auch auf sämtliche Bibliotheken, Programme etc die ausserhalb des chroot-Verzeichnisses liegen keinen Zugriff und der ganze Schneuf muss mit allen Abhängigkeiten und ggf. Konfigurationen in den chroot "kopiert" werden...

Zum einen gestaltet sich es recht schwierig tatsächlich "alles " zu erwischen zum anderen gibt es speziell in den Lib-Ordnern teilweise Symbolische Links, die absolut definiert sind, was das ganze nochmal verkompliziert...

Für einfachste Befehle mag das alles noch funktionieren, aber ich sehe bei der Anforderung PHP-Cli, Composer, Pear, ggf. mc oder andere zu "installierende" Tools den Aufwand nicht wirklich gerechtfertigt... und das ganze System da reinzukippen macht auch keinen Sinn...

Viele Grüße
Micha

Ja, hab ich zufällig auch gerade gefunden...

Danke.

da es sich nur um einen Kunden handelt muss ich mal schauen, ob ich den Aufwand betreibe was zu unternehmen...

Immerhin könnte der eine Kunde sämtliche anderen Webspaces durchschnufteln und untersuchen und kopieren etc...

Die gehen ihn aber nichts an...

Hallo,

Ich habe gerade eine Anforderung für ein Projekt, bei der gefordert ist, daß man dem Kunden / Vertrag einen Shellzugang ermöglicht.
Das klappt auch ganz wunderbar, der webxxx-User kann sich via Shell (in dem Fall bash) anmelden.

Was mir in dem Zusammenhang etwas aufstößt ist die Tatsache, daß der webxxx-User Zugriff (lesend) auf das gesamte Dateisystem des Servers erlangen kann. Dazu muss er einfach "cd /" eingeben...

Das gefällt mir natürlich nicht ganz so...kann ich das irgendwie verhindern? Oder ist das ggf. ein Bug?

System ist ein Ubuntu 20.04LTS mit Liveconfig 2.15.1, betrifft aber auch andere Ubuntu-Versionen mir anderen LC-Versionen...
getestet via Linux-Shell sowie Windows-Putty

Freundliche Grüße
Micha

Hallo Herr Keppler,

das Postfix spinnt tatsächlich.
Auch hier musste ich mit symbolischen Links arbeiten. Einige Dateien sind in einen Unterordner "bin" verschoben worden.
das wären:

/usr/lib/postfix/master -> /usr/lib/postfix/bin/master
/usr/lib/postfix/pickup -> /usr/lib/postfix/bin/pickup
/usr/lib/postfix/post-install -> /usr/lib/postfix/bin/post-install
/usr/lib/postfix/postfix-script -> /usr/lib/postfix/bin/postfix-script
/usr/lib/postfix/qmgr -> /usr/lib/postfix/bin/qmgr
/usr/lib/postfix/smtpd -> /usr/lib/postfix/bin/smtpd

allerdings bin ich mir hier nicht sicher, ob das ein Konfig-Problem ist oder eines der Distribution. Die Änderung der "zentralen Pfadangabe" führte jedenfalls nicht zum gewünschten Ergebnis.

Der Rest scheint soweit zu laufen, allerdings hab ich aus Zeitgründen noch nicht alles getestet...

Beste Grüße
Michael Graupner

Hallo allerseits, Hallo Herr Keppler,

so, ich bin schon mal einen Schritt weiter...

offenbar hat sich mindestens eine wichtige Datei geändert.

Für die Erkennung der Distribution wird bei der suse in /usr/lib/liveconfig/lua/distribution.lua die Datei /etc/SuSE-release untersucht. Ab openSuse Leap 15 ist diese Datei entfernt (vorher in der Leap 42 als deprecated eingestuft).

Stattdessen sollte genutzt werden /etc/os-release, welches wiederum auf /usr/lib/os-release verweist.

Ich habe jetzt einen Symbolischen Link angelegt (/etc/SuSE-release) der auf die entsprechende os-release verweist.
Und siehe da: nach einem Liveconfig-Neustart werden alle Dienste erkannt.

Ich teste jetzt noch alles einzeln durch. U.a. da ich gelesen habe, daß, glaub ich, bspw. postfix in der Leap 15 wohl nicht mehr abwärtskompatibel ist...

Vielleicht lässt sich diesbezüglich ja in einem der nächsten Releases was richten...

Beste Grüße
Michael Graupner

Hallo,

ich wollte liveconfig auf einem Server mit openSuse Leap 15 erwenden.
Dienste wie Apache, mySQL, Dovcot, Postfix, proFTP etc... sind installiert. Liveconfig ließ sich auch installieren und mit Lzenz aktivieren.

Allerdings ist im Menüpunkt "Serververwaltung" nur die Übersicht funktional. Alle anderen Registerkarten sagen "Keine unterstützten Dienste gefunden."

Während ein liveconfig --diag auf meinen älteren Systemen u.a. die Info über das gefundende OS ausgibt, ist auf der Leap 15 nichts derartiges zu erkennen.

Das einzige was erfolgreich erkannt wird ist PHP7.2.5

Kann es sein, daß liveconfig nicht mit der openSuse Leap 15 läuft???

Liveconfig und Server wurden bereits neu gestartet. Leider ohne Änderung.

Vielen Dank und beste Grüße
Michael Graupner

p.s.: letzter Ausgabeteil von livconfig --diag:

Running Lua diagnostics...
[ERR] Can't get default php.ini location from /usr/bin/php-cgi
Distribution name: 'openSUSE'
Distribution codename: 'n/a'
Distribution family: '(null)'
Distribution version: '15.0'
Distribution description: 'openSUSE Leap 15.0'
Checking for web server software:
- PHP 7.2.5 [DEFAULT] (code='php7', bin='/usr/bin/php-cgi', SAPI=CGI/FastCGI)
default php.ini: '(null)'
Checking for ftp server software:
Checking for SMTP server software:
- SpamAssassin: NOT FOUND
- OpenDKIM: NOT FOUND
Checking for POP/IMAP server software:
Checking for database server software:
Checking for DNS server software:
Done.

Danke für die Mühe. Habs gefunden. Irgendwie ist mir das postfix-script in /etc/init.d/ abhanden gekommen... :confused:

Hallo,

seit kurzem erscheint im LC bei der Serverkonfiguration zur Mail -> Postfix (einfach neu schreiben lassen der Konfig) im Status die Meldung:

Error while reloading configuration (exit code: 127)

Der Postfixservice läuft aber und kann auch manuell reloaded oder neu gestartet werden. Ein postfix check ergibt keine Konfigurationsfehler. Mails können auch gesendet und empfangen werden.

Wie kann ich der Sache auf den Grund gehen? Ich meine, ein Exitstatus 127 bedeutet doch, daß der Dienst nicht gestartet wurde, oder? Und ich kann doch davon ausgehen, daß LC das ernst meint?

Ich habe die aktuelle Version von LC installiert.

Vielen Dank!

Beste Grüße
Michael

OK, Super!
Vielen Dank!

Beste Grüße
Michael

Hallo,

ich würde gerne einen meiner Server ersetzen und für den neuen Server die LC-Lizenz des alten Servers weiter nutzen. Gibt es da irgendetwas zu beachten (bspw. vorübergehende Deaktivierung oder ähnliches) oder kann man die auf dem neuen Server einfach erneut aktivieren?

Danke und Gruß
Michael

Ja das wäre gut. Aus irgendeinem Grund hab ich zwischenzeitlich mal gedacht, das würde automatisch beim speichern (bspw. beim Postfix) gesetzt. Aber auch hier ist das eigentlich zu kurz gesprungen. Muss ja nicht der selbe Server sein...

Gruß
Michael

Hallo nochmal,

ich nehm das zurück. Geht doch!
Man kann die URL halt nicht unbedingt im Browser aufrufen, wenn die Methode POST sein soll / muss.

Danke und Beste Grüße
Michael

Hallo Björn,

vielen Dank! Ich wusste noch nicht, dass man das so bequem mit der .httpd.conf machen kann. Ich dachte schon ich müsste wieder durch diverse lua-skripte durch.

Nach einigen Handshake-Problemen funktoniert die Sache jetzt wie (vermutlich) gedacht.

Leider erhalte ich einen 404-Error für
https://SSL_DOMAIN/Autodiscover/Autodiscover.xml

In der Serververwaltung unter E-Mail bei Postfix ist die Auto-Konfiguration befüllt mit dem HTTP_ONLY-HOST und bei der Testdomain ist unter E-Mail die Autokonfiguration aktiviert.

Hast Du / jemand eine Idee wo ich da nachschauen kann oder was das Problem sein könnte?

Vielen Dank und Beste Grüße
Michael

Nachtrag: Ich sehe gerade, dass die Meldung so aussieht:
The requested URL /liveconfig/hosting/autodiscover was not found on this server.

Hallo,

ich hoffe mir kann jemand einen Tipp geben. Ich habe das autodiscovering nach der Anleitung im Wiki durchgeführt. Beim Testen über die empfohlene Testseite (M$) scheitert diese am Abruf der potentiellen XML-URL. Rufe ich diese im Browser auf erhalte ich einen Error 500. Im Logfile erscheint dazu:

[ssl:error] [pid 1465] [remote 1.2.3.4:8443] AH01961: SSL Proxy requested for autodiscover-ssl.example.org:443 but not enabled [Hint: SSLProxyEngine]

1.2.3.4 und example.org sind hier ersetzt.

Wo schalte ich die SSLProxyEngine ein (unter Servereinstellung -> Web sind proxy und proxy_http mit einem grünen Haken versehen)?
Oder hab ich hier einen Denkfehler?

Vielen Dank und Beste Grüße
Michael

Ah, super! Genau das wars!
vielen Dank!

Beste Grüße
Micha.

Hallo,

leider musste ich einen Server komplett neu aufsetzen und damit auch liveconfig komplett neu installieren.
Im Prinzip läuft alles soweit. Also Email, Webserver, Zertifikate auch bei Kunden.

Jetzt würde ich aber gern für einige Domains den Webspace für HTTPS festlegen und die HTTP-Variante umleiten auf die HTTPS. Das konnte ich bisher in der Domainverwaltung erledigen.
Da gab es Links den normalen HTTP-Webspace und rechts den HTTPS-Webspace.

Bei mir fehlt nun der rechte Block für den HTTPS-Webspace.

Ich habe von LiveConfig die aktuellste Version 2.2.1 (r4293) und SSL ist auch (inkl. Zertifikatsverwaltung) in dem entsprechenden Vertrag aktiv.

Habe ich irgendwo eine Einstellung vergessen? Was kann ich tun, um den HTTPS-Webspace verwalten zu können?

Beste Grüße
Micha.

Hallo,

vielen Dank nochmal!
Funktioniert gut!

Beste Grüße
Michael Graupner

Hallo,

vielen Dank für den Tipp!
Eine Subdomain mit * hatten wir bereits angelegt.
Dann schrauben wir mal an den Rewrite-Regeln...

Beste Grüße
Michael Gaupner

Hallo Allerseits,

Wir versuchen folgendes Szenario umzusetzen:
Wenn ein Besucher eine beliebige Subdomain zu einer Domain (bspw. a1.domain.de) aufruft, soll er falls vorhanden in das entsprechende Verzeichnis (bspw. /srv/www/web**/a1/) geleitet werden. Dabei soll sich a1.domain.de wie eine echte (Sub-)Domain verhalten.

Dazu haben wir:
im Apache das Modul vhost_alias eingebunden.
im externen DNS einen Wildcard (* IN A ...) hinzugefügt
im LiveConfig eine custom.lua und ein Script geschrieben, dass uns die VHost-Konfig für die entsprechende Domain per Include modifiziert. (bspw. VirtualDocumentRoot /srv/www/web**/htdocs/%1/)

Bis hierhin funktioniert das auch ganz gut. Der DNS funktioniert. die Anpassung der Apache-Konfig-Files ebenfalls. Ein Konfig-Test bringt keine Fehler. Apache startet anstandslos neu.

wenn man nun aber eine beliebige Subdomain aufruft, zu der auch ein DocRoot existiert, dann bringt LiveConfig die Meldung "Domain ist nicht verfügbar".
Selbstredend soll bei dieser Variante natürlich nicht jede einzelne Subdomain via LC angelegt werden müssen (dazu soll das vhost_alias-Modul herhalten).

Gibt es hier eine Variante das ganze ans Laufen zu bekommen? Kann man ggf. die Verfügbarkeitsprüfung von LC umgehen?

Im Prinzip geht es darum, dass Nutzer einer Plattform selbstständig "Arbeitsversionen" anlegen und löschen können sollen, die dann als Subdomain erreichbar sind.

Beste Grüße und vielen Dank!
Michael Graupner