Beiträge von Umbriel

    Bin gerade dabei meinen neuen Server mit LiveConfig einzurichten und wollte wieder den FTP Zugriff für die Verträge mit SCPONLY/SFTP ausstatten.


    Allerdings scheint es das Paket scponly nicht mehr auf den Debian Servern zu geben - somit funktioniert auch der Eintrag

    Code
    /usr/bin/scponly

    bei dem Hauptbenutzer nicht mehr.


    Gibt es dafür irgend eine Lösung?


    Benutze ein frisches Debian Jessie 8.3 ...

    Habe mittlerweile den öffentlichen Client von LE am laufen. Durch die Basic Lizenz bin ich ja sehr eingeschränkt. Mir ist nicht ganz klar, wie ich den LE client mit LiveConfig in Einklang bringen kann.


    Es wäre zumindest hilfreich, wenn ich e.g. bei der SSL-Verwaltung ein Verzeichnis (das live-Verzeichnis vom LE client) angeben könnte und die verfügbaren Zertifikate dort aufgelistet wären ("Externe Zertifikate"), sodass ich sie den richtigen Domains zuordnen kann. Wenn ich das alle xx Tage neu machen soll, wenn eine Apache vhost Datei neu erstellt wird (e.g. brauche mal wieder kurzeitig ne Subdomain), dann brauche ich auch gar kein LiveConfig, dann kann ich alles auf Kommando-Ebene machen ...

    Zitat

    Eine .dpkg-old wird dann erzeugt, wenn Sie z.B. das Apache-Paket aktualisieren und die von LiveConfig erzeugte Konfiguration mit der vom Debian-Paket überschreiben (also genau anders herum).


    Genau so meinte ich das auch - ich hatte schon bevor ich die Anleitung hier im Forum notiert hatte auf Jessie aktualisiert und zunächst keine Fehler feststellen können. Also, alles gut soweit.


    Zitat

    Prüfen Sie bitte noch mal in LiveConfig, ob Sie User1 wirklich zum jeweiligen Ordner hinzugefügt haben. Das sollte dann so aussehen:


    Jupp, genau so sieht es in meinem Admin aus. Die conf Datei trägt den aktuellen Zeitstempel.

    Hab heute morgen zu meiner letzten Idee noch eine .dpkg-old Datei gefunden, die anscheinend von LC irgendwann man überschrieben wurde. Hab diese nun wieder hergestellt und alle LC errorpages, etc. sind wieder verfügbar. Manchmal braucht es eben nur einen Denkanstoß.


    Allerdings,
    /var/www/web01/htdocs/unterordner/kundenzugriff1 (protected2: User1, User2) (domain: kunde1.example.com)
    /var/www/web01/htdocs/unterordner/kundenzugriff2 (protected3: User1, User3) (domain: kunde2.example.com)


    funktioniert auch weiterhin nicht für User1.


    Die von LC erstellten <Directory> Einträge aus meiner web01.conf:


    # password-protected directories:
    <Directory "/var/www/web01/htdocs/unterordner">
    AuthType Basic
    AuthUserFile /var/www/web01/conf/.htpasswd
    <IfModule mod_authz_groupfile.c>
    AuthGroupFile /dev/null
    </IfModule>
    AuthName "Private Dir"
    Require user "User1"
    </Directory>
    <Directory "/var/www/web01/htdocs/unterordner/kundenzugriff1">
    AuthType Basic
    AuthUserFile /var/www/web01/conf/.htpasswd
    <IfModule mod_authz_groupfile.c>
    AuthGroupFile /dev/null
    </IfModule>
    AuthName "For User2 eyes only"
    Require user "User2"
    </Directory>
    <Directory "/var/www/web01/htdocs/unterordner/kundenzugriff2">
    AuthType Basic
    AuthUserFile /var/www/web01/conf/.htpasswd
    <IfModule mod_authz_groupfile.c>
    AuthGroupFile /dev/null
    </IfModule>
    AuthName "For User3 eyes only"
    Require user "User3"
    </Directory>


    Alle Passwörter sind in der .htpasswd Datei vorhanden. User1 wurde für beide kundenzugriff-Ordnern per "vorhandenen Benutzer hinzufügen" in der Weboberfläche aktiviert.

    Natürlich heißt die Datei 000-default.conf, klar - hab nur den Dateinamen ausgeschrieben. (000-default.conf befindet sich in "sites-available", nicht in "mods-available", muss ich also mit "a2ensite 000-default" aktivieren)


    Ohne 000-default.conf (netstat -tlpn | grep :443)
    tcp6 0 0 :::443 :::* LISTEN 28568/apache2


    Server läuft seit Debian 6 mittels dist-upgrades mittlerweile unter Debian 8.


    Browser Zwischenspeicher kann nicht sein - hab schon mehrfach anonym/auf unterschiedlichen Rechnern, etc. getestet ...


    Log sagt:
    [mpm_prefork:notice] [pid 28568] AH00171: Graceful restart requested, doing restart
    (98)Address already in use: AH00072: make_sock: could not bind to address MEINE_IP:443
    lclogsplit: got TERM signal
    [mpm_prefork:alert] [pid 28568] no listening sockets available, shutting down
    [:emerg] [pid 28568] AH00019: Unable to open logs, exiting


    Alle Apache2 "443" Referenzen (grep -rnw '/etc/apache2' -e "443")
    /etc/apache2/ports.conf:8: Listen 443
    /etc/apache2/ports.conf:12: Listen 443
    /etc/apache2/sites-available/000-default.conf:15: Listen MEINE_IP:443
    /etc/apache2/sites-available/000-default.conf:57:<VirtualHost MEINE_IP:443>
    /etc/apache2/sites-available/default-ssl.lcbak:2:<VirtualHost _default_:443>
    /etc/apache2/sites-available/default-ssl.conf:2: <VirtualHost _default_:443>
    /etc/apache2/sites-available/web01.conf:371:<VirtualHost MEINE_IP:443>
    /etc/apache2/sites-available/web01.conf:484:<VirtualHost MEINE_IP:443>
    /etc/apache2/ports.conf.lcbak:12: # If you add NameVirtualHost *:443 here, you will also have to change
    /etc/apache2/ports.conf.lcbak:14: # to <VirtualHost *:443>
    /etc/apache2/ports.conf.lcbak:17: Listen 443
    /etc/apache2/ports.conf.lcbak:21: Listen 443


    (in sites-enabled befinden sich lediglich die Kunden-*.conf-Dateien)


    Nimmt LC bei der Installation Änderungen an der ports.conf Datei vor (löscht "LISTEN ...") ??? Wurde vielleicht beim dist-upgrade überschrieben?

    Richtig verstanden. Folgende Struktur:


    /var/www/web01/htdocs (domain: example.com)
    /var/www/web01/htdocs/unterordner (protected1: User1)
    /var/www/web01/htdocs/unterordner/kundenzugriff1 (protected2: User1, User2) (domain: kunde1.example.com)
    /var/www/web01/htdocs/unterordner/kundenzugriff2 (protected3: User1, User3) (domain: kunde2.example.com)


    /var/www/web02/htdocs (domain: somedifferent.com)


    - server.example.com ist als rDNS der IP zugewiesen
    - hostname -f gibt "server.example.com" aus, hostname nur "server"
    - in der web01.conf ist für das Verzeichnis "/var/www/web01/htdocs/unterordner/kundenzugriff2" lediglich "Require user User3" aufgeführt
    - beim browsen von xyz.example.com sollte eigentlich die liveconfig errorpage angezeigt werden, jetzt bekommt man allerdings die Login-Box von protected3 angezeigt
    - die protected3 Passwort-Abfrage erhält man ebenfalls beim Aufruf der Server IP (server.example.com ist nicht in der Weboberfläche als Subdomain angelegt), beim Aufruf von "xyz.somedifferent.com" (ebenfalls nicht angelegt), usw.


    Was mir heute morgen noch aufgefallen ist:
    In sites-available existiert eine Konfiguration "000-default", die offensichtlich von liveconfig zuletzt bearbeitet wurde, aber nicht aktiviert ist (ich gehe mal davon aus, dass liveconfig diese normalerweise aktivieren würde). Möchte ich diese nun manuell aktivieren, stürzt Apache2 mit der Fehlermeldung ab, dass Port 443 nicht zugewiesen werden konnte.
    Wie ich dieser entnehmen konnte, sind dort alle /.errorFiles Aliase und dergleichen festgelegt


    Infos zum System:
    - LiveConfig 1.8.3-r3577
    - Debian GNU/Linux 8.0 (jessie)
    - Apache 2.4.10

    Für meinen Server hab ich den FQDN mit in meinen Verträgen.


    Für diesen habe im Punkt "Webspache" einen Unterordner mit einem Verzeichnischutz versehen ("User1", "****"). In diesem Ordner befinden sich dann weitere Unterordner, denen die ich auch mit einem Verzeichnisschutz versehen habe ("User2", "****"). Zusätzlich habe ich diesen Verzeichnissen User1 als Login hinzugefügt. Problem: Das wird ignoriert. In den erstellten .conf-File zum Vertrag steht lediglich "Require user User2". Hab den Verzeichnisschutz und die gespeicherten User schon zig mal neu erstellt - nix hat geholfen.


    Der "# password-protected directories:" block steht noch dazu in jedem "<VirtualHost>" Block - tut das Not?


    Als weiteres Problem tritt dabei auf, dass anscheinend bei jeder x-beliebige, nicht zugewiesene Subdomain bei diesem Vertrag und bei weiteren Verträgen nun diesen Verzeichnis-Login für User2 abfragt, obwohl der Unter-Unterordner gar nicht zu diesen Verträgen gehört ...


    Für sachdienliche Hinweise, die zu einer raschen Fehlerbeseitigung führen, bin ich sehr dankbar!

    Ich greife einfach mal das Thema auf, weil es bei mir (natürlich mit dem richtigen Weg) trotzdem nur möglich ist einem Verzeichnis nur einen Benutzer zu zu weisen.


    Folgendes Szenario:
    /htdocs/schutz - Geschützt und Benuzer "Web" angelegt
    /htdocs/schutz/erweitert - Geshützt und Benutzer "Web" zugewiesen, zusätzlich neuen Benutzer "Dummy" erstellt und hier zugewiese
    /htdocs/schutz/beschränkt - Geschützt Benutzer "Dummy" zugewiesen, Benutzer "Web" zugewiesen.


    Im ersten Pfad funktioniert alles Prima - ein Benutzer, Login klappt. Bei beiden Unterverzeichnissen hingegen kann sich nur Benutzer "Dummy" einloggen (ABC-Regel?), Benutzer "Web" hängt in einer endlosen Login-Schleife.


    Gruß
    Daniel

    Ohne scheint für mich aber auch keine Option zu sein, denn wie ich eingehend schon formuliert habe, bezeichne ich mich ehr als linux-noob und bekomme die ganze Mail- und FTP- und -Verzeichnis-Administration nicht wirklich hin. Da sind schon zu viele Stunden vergangen, als dass ein brauchbares Ergebnis rausgekommen wär. Will mich eigentlich nur um mein Webdesign und die ein oder andere Drupal-Funktion bemühen ...

    1) hmm ... schade, dann ist wohl keine Multi-Install mit der Kunden-Verwaltung vereinbar, weil
    2) ich nur eine Drupal-Verzeichnisstruktur betreiben möchte, die idealerweise auf /var/www/htdocs liegt der Virtual Host natürlich bei allen Domains darauf zeigen müsste ...
    3) ist hinfällig, wenn 2 so nicht funktioniert.


    phpmyadmin war natürlich installiert. Die 6. php.ini, die ich editiert hab, hat dann gestimmt. Danke trotzdem.

    OK, sorry, mein Fehler, hatte ein altes Abbild wieder hergestellt, dadurch stimmte die Zeit nicht mehr.


    Und wie bekomm ich LiveConfig nun dazu


    1) längere Vertragsnamen zuzulassen (ich würde da gern immer den Domain-Namen eintragen)
    2) den htdocs root für angelegte Verträge immer auf /var/www zu setzen
    2) customer nach dem Schema %WWW-ROOT/sites/%CONTRACT-NAME anzulegen


    ???


    Damit könnte ich schon mal sehr Drupal-konform arbeiten und mir zukünftig ein Haufen Verwaltungsaufwand sparen ...

    Schöne Sch ... jetzt liefert mir liveconfig --activate ständig den Fehler, dass es nicht aktiviert werden konnte.


    Schuld daran zu sein, dass ftp.lua nicht in /usr/lib/liveconfig/lua zu existieren scheint ... wo bekomm ich die her?


    Zitat

    Generating license activation request, please wait... ok.
    Connecting to license.liveconfig.com ([62.146.188.68]:443)... ok.
    Sending license request... ok.
    - liveconfig: License error (9): certificate is not yet valid


    Die Datei liveconfig.key existiert nicht ...

    Eigentlich hatte ich mir das so vorgestellt, dass ich eine Drupal-Multi-Installation betreibe und den einzelnen Kunden dann nur Zugrif auf ihren eigenen sites/DOMAINNAME Ordner gewähre.


    Eingehende Linux-Erfahrung!? Naja ... das kann auch nicht die Lösung sein. Hatte mir das ganze ohnehin einfacher vorgestellt, als man sagte "Leg dir doch nen vServer zu", aber sei es drum. Mittlerweile hab ich alle Einstellungen, die ich für meine Multi-Install benötige so vorgenommen (auch ohne eingehende Linux-Erfahrung), also Mail, FTP und Datenbank.


    Meine Frage wäre, wenn ich nun LiveConfig wieder installiere, inwieweit die bereits gemachten Einstellungen bei Diensten wie postfix, dovecot oder proftpd wieder zurücksetzt?!

    Hallo, bin neu hier und ein absoluter Noob, was Linux angeht. Hab mir LiveConfig zugelegt, weil mir das Interface sehr leicht zu sein schien. Allerdings bin ich jetzt auf ein für mich großes Problem gestoßen:


    Ich betreibe Drupal in einer Multi-Install, aber LiveConfig legt für jeden Kunden ein eigenes Unterverzeichnis an. Kann man das um-/ausstellen, sodass pro Benutzer nur eine neue Datenbank und Domain konfiguriert werden kann ???


    Wenn dies nicht möglich ist, müsste ich mich wohl wieder von dem ansonst schönen System trennen ...