Beiträge von KB19

    Einfach wie im letzten Beispiel von Shaolan den MX-Record direkt auf den DDNS-Hostnamen zeigen lassen. Das ist am unkompliziertesten und sollte auch keine Probleme machen.


    Beim Versenden von Mails wirst Du aber Probleme bekommen. Da wäre ein Smarthost empfehlenswert! D.h. alle ausgehenden Mails werden über den SMTP-Server eines Anbieters Deiner Wahl versendet. Solche Konfigurationen werden meines Wissens nach sogar von einigen fertigen Mailserver Paketen der großen NAS-Hersteller unterstützt. Notfalls muss man selbst in der Konfiguration herumpfuschen. Ohne zu wissen, welches NAS und welche Software Du dafür einsetzen willst, kann man da aber nur raten.



    MfG Christian

    Das Problem ist, dass die entsprechenden (GeoIP) Datenbanken relativ selten aktualisiert werden. Wenn diese dann auch noch über die Paketverwaltung einer Distribution einen großen Umweg nimmt, kann es Monate bis Jahre dauern, bis die aktualisierten Länderverknüpfungen überall angekommen sind.


    Da hilft leider nur warten oder beim Betreiber des Dienstes nachfragen. netcup kann daran absolut nichts ändern.



    MfG Christian

    […] auf einem Server lässt man kein Windows laufen […]


    Auch wenn ich persönlich kein Freund von Microsoft Software bin: Wieso nicht? Gerade bei der Server-Edition spricht eigentlich nichts dagegen, ausreichend Wissen vorausgesetzt! :)


    Es gibt nun einmal genügend Anwendungsfälle und reine Windows-Umgebungen, wo das sehr viel Sinn macht. (Und ich hätte nicht gedacht, dass ich diesen Satz jemals schreibe… :whistling: )



    MfG Christian

    Mal unabhängig von der vorherigen Fragestellung: Im Endeffekt wirst Du mit dieser Lösung sowieso noch andere Probleme bekommen. Was ist, wenn User A für Domain A eine Datei anlegt und diese User B später (völlig zurecht) bearbeiten will? Das kannst Du ohne Gruppenberechtigungen und den entsprechenden Schreibrechten kaum lösen. Für www-data blieben dann konsequenterweise nur noch die Rechte für Other. Nachfolgend trotzdem einmal meine theoretische Idee für Dein Vorhaben:


    • /var/www/domainA » root:root (chmod 0) » Rechte ausschließlich für diesen Ordner über ACL vergeben (groupA darf alles, www-data darf nur lesen; Rechte dürfen sich nicht vererben)
    • /var/www/domainA/subdir » userX:groupA (chmod 0775) » User+Group dürfen somit alles, www-data fällt unter Other und darf nur lesen. Da aber nur www-data (und groupA) über ACL auf die Rootebene der Domain zugreifen darf, ist Other=www-data.
    • /var/www/domainA/subdir/upload » userX:groupA (chmod 0777) » Alle dürfen alles machen. Alle bezieht sich hier aber wieder nur auf jene (groupA und www-data), die auf der Rootebene Zugriff über ACL auf den Domainordner haben. Kommen sie dort nicht rein, sind die tieferen Rechte ja hinfällig.


    userX ist quasi ein Platzhalter, je nachdem, welcher User die Datei hochgeladen hat. Denk Dir user1 und user2, die beide Zugriff auf domainA haben. In groupA sind alle User Mitglied, die Zugriff auf domainA haben.


    Zwei Dinge müsstest Du bei diesem Setup sicherstellen:

    • Dass die ACLs für /var/www/domain* immer richtig sind, nicht auf die Unterordner/-dateien vererbt werden und nichts über die normalen Rechte läuft, also "chmod 0" vergeben wird!
    • Dass die Standardrechte für neue Ordner/Dateien immer 0775/0664 sind, da ansonsten andere User der gleichen Domain keine Schreibrechte und der Webserver/PHP keinen Zugriff darauf haben. Das sollte sich über die umask realisieren lassen.


    Mit ACL stehe ich etwas auf Kriegsfuß, von daher ist alles rein theoretisch und ohne Praxiserfahrung! Das müsste Deinem Wunsch trotzdem am nächsten kommen. Falls ich da einen Denkfehler habe, geht es morgen weiter, gn8… :D:sleeping:



    MfG Christian


    PS: Dein gewünschtes Setup hängt dann aber immer noch davon ab, dass alle gefährlichen PHP-Funktionen (Shellzugriff, Prozessfunktionen, …) deaktiviert sind und der open_basedir entsprechend gesetzt ist. Letzteres setzt voraus, dass keine unbekannten Sicherheitslecks in PHP existieren, da das Deine einzige Barriere gegen den unerlaubten Script-Zugriff durch andere User ist. Genau deshalb bevorzuge ich persönlich getrennte User für jede PHP-Instanz.

    chmod sollte über SFTP normal funktionieren. Angenommen der User setzt die Rechte für einen Upload-Ordner auf 0775 oder 0770. Dann könntest Du doch immer noch www-data in die Standardgruppe des Users packen, oder übersehe ich da etwas? So könnte der User über die Gruppenberechtigung steuern, wo der Webserver bzw. PHP schreiben darf. Die Standardrechte für jeden Ordner sollten dann natürlich weiterhin 0755/0750 und für Dateien 0644/0640 sein. Besitzer jeweils der User, der die Ordner erstellt oder Dateien hochgeladen hat.


    Notfalls steuere es über die World/Other Rechte. Solange die Rootebene der Domain nur für bestimmte Benutzer/Gruppen über ACL aufrufbar ist, kannst Du in Unterordnern ja beliebig die World/Other Rechte dafür missbrauchen.


    […] aber für manche Benutzer ist es zu umständlich mehrere FTP-Sessions offen zu haben.


    Dem könnte man jetzt entgegen halten, dass dann bei einem geknackten (S)FTP Account gleich mehrere Domains betroffen sind :D



    MfG Christian

    Die Frage ist: Willst Du generell nicht, dass der Webserver und die PHP-Prozesse in Verzeichnissen schreiben können?
    Sprich: Warum setzt Du nicht auf jeweils einen eigenen User für die PHP-Prozesse? Gibt es dafür einen speziellen Grund?


    Normalerweise würde ich das ohne ACL und mit einer durchdachten Benutzer/Gruppen Lösung umsetzen. Aber eventuell verstehe ich den Hintergrund Deines Spezialvorhabens (noch) nicht. Außer der Möglichkeit, dass ein Login mehrere Domains verwalten kann und eine Domain mehreren Logins zugeordnet sein könnte, sehe ich da noch keinen großartigen Vorteil.



    MfG Christian

    Schuld daran ist das letzte OpenSSL Update, wodurch beim DH-Schlüsselaustausch weniger als 768 Bit nicht mehr akzeptiert werden. Das ist die vorläufige Lösung gegen Logjam, später sollen sogar nur noch 1024 Bit oder höher unterstützt werden. Das ist prinzipiell auch gut und richtig, genau genommen sollte man nur noch auf 2048 Bit setzen, führt aber an manchen Stellen zu solchen überraschenden Problemen.


    Normalerweise sollte in diesem Fall der Zielserver schuld daran sein, wenn ich das richtig interpretiere. Hier gibt es noch ein wenig Lesestoff, einfach nach "dhparam" suchen: TLS Forward Secrecy in Postfix



    MfG Christian

    Ich hoffe Du verwendest squeeze-lts, weil Deine Debian Version ansonsten bereits EOL ist!


    Zu Deinem eigentlichen Problem: Du vermischt hierbei irgendetwas. Du versuchst offensichtlich eine Nginx-Konfigurationszeile innerhalb der Apache-Konfiguration zu verwenden. Das kann nicht funktionieren. Was genau hast Du wo eingetragen?



    MfG Christian

    Debian Jessie gibt es im VCP schon sehr lange zur Auswahl: Server auswählen » Images » Offizielle Images


    Was tatsächlich noch fehlt (und wahrscheinlich meinst Du das) ist das ISO von Debian Jessie! ;(



    MfG Christian

    • Load und Swap sind Betriebssystem-spezifisch (z.B. Linux) und können daher nicht von extern ausgelesen werden.
    • Die HDD kann jedes beliebige Dateisystem und jede beliebige Partitionierung haben. Wie soll man da sinnvolle Werte zusammenbekommen?
    • Beim Ram wird es ebenfalls schwierig, da der Host nicht wissen kann, wie der Gast ihn verwaltet. Stichwort Buffers/Cache unter Linux und noch viele andere Faktoren. Das könnte mit Memory Ballooning zwar irgendwie durchgereicht werden, stellt sich nur die Frage wozu. Ich würde im Gastsystem sicher keine spezielles Kernel-Modul aktivieren, nur damit der Host oder das VCP weiß, wie viel Ram ich verwende.
    • Details über Netzwerk und CPU hingegen könnte man tatsächlich auslesen. Fragt sich nur, ob es den Aufwand und den Ressourcenverbrauch wert ist…


    Wie Du siehst ist das bei KVM nicht so einfach, da es sich um eine Vollvirtualisierung handelt. Bei OpenVZ oder Linux-VServer sieht die Sache anders aus. Da hat der Host quasi auf alles Zugriff und kann diese statistischen Daten auch anzeigen. Dort gäbe es dann aber auch keine ISOs, kein Windows und auch sonst keine Freiheiten, wie man sie bei KVM und somit auch netcup mittlerweile gewohnt ist.



    MfG Christian

    Ein MX-Record kommt einem A-Record (auf der jeweils gleichen Ebene/Subdomain) eigentlich nicht in die Quere, da sie für unterschiedliche Dinge genutzt werden. MX-Records verwendet z.B. ein Mailserver, der auf Deinem System über SMTP Mails einliefern möchte. Dafür holt er sich den MX-Record, der auf einen Hostnamen zeigen muss, von dem er die IP mittels A-Record (oder im Falle von IPv6 AAAA-Record) ermittelt. Für fast alles andere (z.B. den Abruf im Browser) sind sowieso nur die A/AAAA Records relevant, da sie den Domainnamen in eine IP übersetzen.


    Das @ ist vielleicht etwas verwirrend: In der linken Spalte der DNS-Einstellungen im CCP wird eigentlich die Subdomain eingetragen, für die der Record gesetzt werden soll. Da es auf der Hauptebene (z.B. example.com) aber keine Subdomain gibt und ein leeres Feld unpassend wäre, wird einfach ein @-Zeichen genommen. Dadurch gilt der Eintrag dann genau für example.com! Würdest Du statt dem @ ein test eintragen, würde es für test.example.com gültig sein.


    Weitere Informationen zu den einzelnen Resource-Record-Typen findest Du unter anderem auf Wikipedia, dort sind auch die entsprechenden RFCs verlinkt: Die wichtigsten RR-Typen



    MfG Christian

    Deine vorherige Config zeigt ja nur etwas von Port 80 (HTTP; unverschlüsselt), hat Froxlor nichts für Port 443 (HTTPS) erstellt?


    Ja - jedoch ist der MX RECORD unabhängig von Port 80/443 oder bin ich da falsch informiert?


    Eher unabhängig vom A/AAAA Record, der dafür benutzt wird – sofern man die Mails nicht auf einen anderen Server leitet :)



    MfG Christian

    Wie kann ich Subdomains einrichten?


    Das kommt darauf an, was Du meinst. Um Subdomains auf anderen Servern zu nutzen? Siehe: CCP » Domains » DOMAIN auswählen » gewünschte A/AAAA Records anlegen


    Wie kann eine Domain auf ein Unterverzeichnis meines ApacheServers zeigen lassen?


    Apache-Dokumentation zu virtuellen Hosts - Apache HTTP Server Version 2.4


    DocumentRoot im jeweiligen vHost ist Dein Freund. Allgemein ist die Dokumentation sehr zu empfehlen, da steht vieles drinnen.


    Kann ich auch den Port ändern? (Bsp.: domain.de soll auf Port 42 des Servers zeigen und nicht auf Port 80)


    An Adressen und Ports binden - Apache HTTP Server Version 2.4


    Allerdings lässt nicht jeder Browser den HTTP-Aufruf von exotischen Port zu, wenn dieser für andere Zwecke gedacht ist. Chromium z.B. quittiert den Versuch zum SSH-Port über HTTP zu verbinden mit dem Fehler ERR_UNSAFE_PORT.


    Ich kenne mich damit leider nicht gut damit aus.


    Ich hoffe Du kennst Dich mit der allgemeinen Administration von GNU/Linux mehr aus, als mit Deinem Webserver. Ansonsten kann das sehr leicht böse enden… :|



    MfG Christian