Beiträge von antondollmaier

Zitat von kk

Das einfachste Vorgehen wäre wirklich so:
- Vertrag web2 anlegen, IP des Webspace herausfinden (z.B. "1.2.3.4").
- Vertrag web1 öffnen, dort eine Subdomain "shop.example.com" anlegen: kein Webspace, kein E-Mail, A-Record auf o.g. IP setzen (1.2.3.4). Wenn DNSSEC für "example.org" aktiv ist, wird diese Subdomain somit automatisch auch signiert.
- neue Domain "shop.example.org" anlegen, als Zielvertrag "web2" angeben, "externe DNS-Server" auswählen
- im Vertrag "web2" die Domain "shop.example.org" wie gewünscht konfigurieren...

Klappt - habe den Fehler auch gefunden: "ich dachte, es darf keine Domain(s) doppelt geben".

Mit dem zusätzlichen DNS-Eintrag für "*.shop.example.com" klappts auch mit Subdomains.

Wieder was gelernt - Danke!

Zitat von kk

Es dürfte einfacher sein, die gewünschte Subdomain bei der Hauptzone direkt anzulegen (also nur den A-Record). Beim anderen Vertrag, wo diese verwendet werden soll, wird die dann über "Domain hinzufügen" angelegt, dort aber "externe Nameserver" ausgewählt.

Ok, konkretes Beispiel:

- Kunde hat Vertrag "web1", mit Domain "example.com". DNSSEC aktiv.
- Kunde bucht zweiten Vertrag. Getrennte Leistungen, getrennter Server - mit Subdomain "shop.example.com". Muss ja als Haupt-Domain hinterlegt werden.

Wenn die Domain "shop.example.com" nun als "extern" angelegt wird, kann ich ja nicht DNS-Einträge bei "example.com" anlegen, da die ja schon in der "shop.example.com" existieren, oder? ...

DS und NS-Records kann ich aber in LiveConfig -> Endkunde -> Domains nicht erstellen.

Weiterleitungs-Typ Proxy. Kein "/" am Ende.

Kurz: nein. Auch kein Bug von LiveConfig.

Lang: AWStats verwendet die "SiteDomain", um diese Links zu erzeugen.

Nachdem in einem Vertrag mehr als eine Domain hinterlegt sein kann (auch Subdomains!), die Statistiken aber nicht aufgetrennt werden können, muss irgendwie der Link trotzdem aufgebaut werden.

Somit kann der Link nicht korrekt erzeugt werden.

Alternative: Piwik nehmen. Da können die historischen Logs auch importiert werden - außerdem wird jede Seite/Domain/Subdomain getrennt definiert und somit auch getrennt analysiert.

Welche Probleme soll es da geben?

"wp" wird mit den Rechten des SSH-Benutzers ausgeführt, hat also das gleiche Sicherheitspotential wie jedes andere non-root-Binary (wget, curl, ...).

Wo ist das Problem?

wget $URL -O/usr/local/bin/wp; chmod 0755 /usr/local/bin/wp;

Doch, der Fehler besteht immer noch, wenn als Admin ein Kunde mit einem "Wiederverkäufer-Vertrag" aufgerufen wird.

Tipp: "[code](...)[/code ]" erhöht die Lesbarkeit

Zitat

Was noch auffällt ist das hier beim aptitude update:
------------------------------------------------------------------
Treffer http://repo.liveconfig.com jessie InRelease
Treffer http://repo.liveconfig.com jessie/php amd64 Packages
Ign http://repo.liveconfig.com jessie/php Translation-en
Die Einträge sind in der Reihenfolge richtig, alle anderen habe ich jetzt nicht mit kopiert.

Da fehlt offenbar das LiveConfig-Repository, da das nur das mit den PHP-Paketen ist.

Ist das Repository von LiveConfig überhaupt noch eingebunden?

Zitat von hchristo

Hat sich erledigt... hab nen altes Backup mit debian 8 eingespielt... mein system läuft wieder unter 8 statt 9.

Was stand denn zu den Mails in den Logs?

Zitat

er hat PHP7 automatisch mit installiert...

das ist normal. Debian Stretch hat kein PHP5 mehr dabei.

Zitat von ñull

Manuell geht das schon aber ich würde gerne wissen wie man es automatisiert.

- LiveConfig mit Self-Signed betreiben
- gewünschte Domain regulär anlegen
- Zertifikat dafür holen
- ReverseProxy für HTTP
- sonstige Dienste (FTP, SMTP, IMAP) mit Zertifikat ausstatten

... oder mit dehydrated nativ.

Mein Fehler. Durch "[quote" statt "[code" habe ich den Zeilenumbruch nicht gesehen.

Was steht denn da im Mailserver-Log? Das ist letztendlich das relevante. Mail hinschicken, Log verfolgen, Zeilen posten, falls Fragen offen sind.

der ClamAV-Daemon läuft nicht.

Ergänzung:

Die SSL-Server-Chiffren müssen auf "kompatibel" stehen. Mit "PCI-konform" klappt's nicht!

kk: bitte in die Doku, soweit die existiert

Zitat von RB-Media-Group

doch ich meine Sie bei den Angeboten/Verträge gesehen zu haben. Beim SMTP Server muss man es allerdings vorher aktivieren.

Da ist nichts zu finden, nur die Checkbox in der Serververwaltung.

kk: ist das überhaupt schon (fertig) implementiert?

Zitat von RB-Media-Group

nur die Protokolle aktiviert, und in confs übernommen.

a2enmod http2
# cat /etc/apache2/conf-enabled/http2.conf
Protocols h2 http/1.1


H2Push          on
H2PushPriority  *                       after
H2PushPriority  text/css                before
H2PushPriority  image/jpeg              after   32
H2PushPriority  image/png               after   32
H2PushPriority  application/javascript  interleaved

Ergibt dann weiterhin HTTP/1.1, da eben blacklisted Cipher mit drinnen sind.

Was sagt der Qualys SSL-Test bei euch genau?

Bei uns:

Android 7.0 	Server negotiated HTTP/2 with blacklisted suite
RSA 4096 (SHA256)   |  TLS 1.2 > h2    |  TLS_RSA_WITH_AES_256_GCM_SHA384 
Chrome 51 / Win 7  R		Server negotiated HTTP/2 with blacklisted suite
RSA 4096 (SHA256)   |  TLS 1.2 > h2    |  TLS_RSA_WITH_AES_256_GCM_SHA384
Firefox 47 / Win 7  R		Server negotiated HTTP/2 with blacklisted suite
RSA 4096 (SHA256)   |  TLS 1.2 > h2    |  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA  |  ECDH secp256r1
Firefox 49 / XP SP3 	RSA 4096 (SHA256)   	TLS 1.2 > h2   	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   ECDH secp256r1  FS
Firefox 49 / Win 7  R		RSA 4096 (SHA256)   	TLS 1.2 > h2   	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   ECDH secp256r1  FS

Das sieht für mich nicht nach "geht" aus.

Was habt ihr da genau geändert?

- über Protocols aktiviert, klar
- dann müssen aber die Cipher angepasst werden: PCI-kompatible Cipher sind teilweise für HTTP/2 blacklisted.
- mit den empfohlenen Ciphern werden aber einige ältere Clients auch von HTTPS abgehalten.

Oder hab ich da was falsch getestet?

"php-cgi" nicht installiert, sondern noch php5-cgi?

WUHU! Danke!