[BUG Report] FQDN als Hauptdomain, vor anlage HTTPS erzwingen, UX  [GELÖST]

Locked
Julian
Posts: 1
Joined: Sat 18. Nov 2017, 12:51

[BUG Report] FQDN als Hauptdomain, vor anlage HTTPS erzwingen, UX

Post by Julian »

Hallo,

derzeit evaluiere ich das Panel und klicke mich ein bisschen durch, hierbei habe ich bisher ein paar Fehler gefunden:

#1 - Nachträglich den FQDN des Server einem Kunden zuweisen
## Was passiert?
Das Panel meldet korrekt, dass die Domain nicht angelegt werden kann und bricht die weitere Erstellung an. Der Kunde bekommt trotzdem einen "Geister Eintrag".
Hinweis: Ich bin mir nicht sicher ob der Eintrag direkt sichtbar ist oder erst wenn man eine Hauptdomain anlegt, da der "Geister Eintrag" als Subdomain unter der Hauptdomain angezeigt wurde.

## Welche Einstellungen?
Domains -> Domain hinzufügen
- Domain-Typ: Hauptdomain
- Vollständiger Domainname: 01.kh.fra2.de.domain.tld (Bereits als FQDN bei der Installation gesetzt)
- Erstelle www. Subdomain: JA
- Besitzer: Max Muster (Mein Test Kunde)
- Domain kann für E-Mail-Adressen verwendet werden: Ja
- Domain ist deaktiviert: Nein

- PHP-Interpreter: OS Standard - PHP 7.0.19

- Seite zum Verwalten der Sicherheitsoptionen automatisch aufrufen: JA

## Reproduzieren:
- Benutzer ohne Hauptdomain oder Subdomain anlegen
- Nachträglich den FQDN vom Server nehmen und dem Kunden zuweisen, dabei auch "Erstelle www. Subdomain" anhaken.

Hier noch mal meinen Hinweis bei "## Was passiert?" beachten.

#2 - Anlegen der Domain Fehlerhaft
## Was passiert?
Ich habe dem Kunden eine Domain zugewiesen und bei dieser direkt alle Sicherheitsmerkmale aktiviert (Let's Encrypt, HTTPS Redirect und HSTS), die Erstellung der Domain verlief fehlerhaft, es erschien immer ein (!). Auch der Apache hat Fehlermeldungen geworfen (siehe "## Logs"). Das deaktivieren von SSL und Neu erstellen lassen der Configs brachte auch kein Erfolg. Den Fehler hat letztlich erst ein "service apache2 stop" und "service apache2 start" gebracht - die Domain konnte dann erfolgreich angelegt werden (mit deaktivieren SSL Einstellungen).

Ich hab die Domain anschließend aber noch mal komplett entfernt und die Sicherheitseinstellungen diesmal nur auf Let' Encrypt gestellt, so gelang auch das anlegen ohne weiteres.

## Logs

Code: Select all

Nov 18 13:29:13 01.kh.fra2.de.domain.tld systemd[1]: apache2.service: Control process exited, code=exited status=226
Nov 18 13:29:13 01.kh.fra2.de.domain.tld systemd[1]: Reload failed for The Apache HTTP Server.
Nov 18 13:33:04 01.kh.fra2.de.domain.tld systemd[1]: Reloading The Apache HTTP Server.
Nov 18 13:33:04 01.kh.fra2.de.domain.tld systemd[9776]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: No such file or directory
Nov 18 13:33:04 01.kh.fra2.de.domain.tld systemd[1]: apache2.service: Control process exited, code=exited status=226
Nov 18 13:33:04 01.kh.fra2.de.domain.tld systemd[1]: Reload failed for The Apache HTTP Server.
Nov 18 13:33:14 01.kh.fra2.de.domain.tld systemd[1]: Reloading The Apache HTTP Server.
Nov 18 13:33:14 01.kh.fra2.de.domain.tld systemd[9790]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: No such file or directory
Nov 18 13:33:14 01.kh.fra2.de.domain.tld systemd[1]: apache2.service: Control process exited, code=exited status=226
Nov 18 13:33:14 01.kh.fra2.de.domain.tld systemd[1]: Reload failed for The Apache HTTP Server.
## Welche Einstellungen?
Domains -> Domain hinzufügen
- Domain-Typ: Hauptdomain
- Vollständiger Domainname: test.01.kh.fra2.de.domain.tld
- Erstelle www. Subdomain: JA
- Besitzer: Max Muster (Mein Test Kunde)
- Domain kann für E-Mail-Adressen verwendet werden: Ja
- Domain ist deaktiviert: Nein

- PHP-Interpreter: OS Standard - PHP 7.0.19

- Seite zum Verwalten der Sicherheitsoptionen automatisch aufrufen: JA

- SSL-Zertifikat: Let's Encrypt Zertifikat
- Sichere Verbindung erzwingen: Ja
- HTTP Strict Transport Security (HSTS): HSTS aktiv, Max-Age auf 60 Minuten
- Sicherheitsoptionen auf Subdomains übertragen: Alle Subdomains

## Reproduzieren:
- Benutzer eine Hauptdomain gemäß den Einstellungen unter "## Welche Einstellungen?" zuweisen bzw. anlegen
- Warten bis der Job gelaufen ist

Nun sollte sich ein (!) bei der Domain befinden, ggf. müsste man die Einstellungen mehrfach bearbeiten.

#3 UX - Blockieren der Datensätze
Sofern ein Datensatz im Status "In Bearbeitung" ist, sollte dieser aus Kundensicht gesperrt werden. So können ggf. Inkonsistenzen verhindert werden bzw. auch eine eventuelle Verwirrung beim Kunden verhindert werden, sollten die weiteren Einstellungen dann noch nicht durch sein weil der Zeitpunkt suboptimal war.

#4 UX - Checkboxen beim Domain Löschen
Wenn man als Administrator eine Domain löschen möchte und die Checkbox "Bitte bestätigen Sie die Löschung der angezeigten Elemente, indem Sie die folgende Checkbox aktivieren." nicht anhakt, landet man ohne Meldung einfach wieder auf der Übersichtsseite. Ist vermutlich recht ärgerlich wenn man sich einen Haufen an Datensätzen mühsam geklickt hat und dann versehentlich die Box vergisst. Eine Meldung wie "Bitte aktivieren Sie die Checkbox, wenn Sie die Datensätze löschen möchten" und das beibehalten der ausgewählten Datensätze würde vermutlich den Ärger bei dem ein oder anderen Admin verhindern.

#5 UX - Sub-addressing im Installer
Wenn ich im Installer eine "Sub Adresse" (julian+keyhelp@domain.tld) angebe, ist diese als Fehlerhaft validiert.

---

Die UX Themen sind Sachen, welche mir persönlich negativ auffallen. Vielleicht gibt es seitens der Entwickler einen entsprechenden Grund dafür, es wurde nicht weiter überlegt oder ähnliches. Über die Punkte muss man nicht diskutieren, hier lasse ich den Entwicklern freie Hand sich darüber noch mal Gedanken zu machen und ggf. etwas zu ändern. Ich denke, dass hier jeder eine andere Ansicht hat wie es optimal ist :-)

---

Es sei jedoch noch anzumerken, dass der erste Eindruck dennoch gut ist und mein Report das Produkt keinesfalls negativ darstellen soll. Da ich selbst auch einige Dinge in PHP entwickle, ist mir durchaus klar, dass es immer mal wieder zu Fehlern kommen kann, egal wie oft man Testet. Es gibt immer Leute die sich noch dämlicher anstellen und damit für Konstellationen sorgen, die man gar nicht im Kopf hatte.

Daher liebe Entwickler, immer weiter so ;-)
Gerne immer Bescheid geben bzgl. Zugriff, da es sich nur um ein Test System handelt, habe ich keine Probleme damit. Bitte per PN kontaktieren zwecks IP Adresse / Domain.
User avatar
Alexander
Keyweb AG
Posts: 4449
Joined: Wed 20. Jan 2016, 02:23

Re: [BUG Report] FQDN als Hauptdomain, vor anlage HTTPS erzwingen, UX  [GELÖST]

Post by Alexander »

Hallo,

Ersteinmal vielen Dank für den umfangreichen Report, so macht Debuggen spaß ;)

#1 - Nachträglich den FQDN des Server einem Kunden zuweisen

-> fixed

#2 - Anlegen der Domain Fehlerhaft

Ich konnte das Problem bislang nicht reproduzieren, hier scheint dem Apache das schnelle, mehrfache Reloaden nicht zu bekommen. Wir werden das Problem im Auge behalten. (Welches OS wird verwendet?)

#3 UX - Blockieren der Datensätze

Das Sperren des Datensatzes ist (zumindest aktuell) nicht notwendig. Das Abarbeiten der von Benutzer und Administrator getriggerten Aufgaben erfolgt je nach Aufgabe entweder sequentiell bzw. gebündelt. Ich kann mir im Moment nur einen Fall/eine KeyHelp Funktion vorstellen, in dem Inkonsistenzen in einer extrem unwahrscheinlichen Konstellation auftreten könnten. Das daraus resultierende Problem wäre aber unkritisch und sowohl von Admin als auch Benutzer innerhalb von 2 Klicks aus der Welt geschafft.
Trotzdem Danke für den Hinweis, es ist immer wieder gut, diverse Vorgänge im Kopf noch einmal durchzuspielen.

#4 UX - Checkboxen beim Domain Löschen

-> fixed

#5 UX - Sub-addressing im Installer

-> fixed


(Die Änderungen fließen alle mit 17.2.1 ein)
Mit freundlichen Grüßen / Best regards
Alexander Mahr

**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
User avatar
MLan
Posts: 483
Joined: Wed 20. Sep 2017, 23:05
Location: @home

Re: [BUG Report] FQDN als Hauptdomain, vor anlage HTTPS erzwingen, UX

Post by MLan »

Hallo ,
Ich versuche gerade den FQDN des KeyhelpServers einem Kunden (an mich) zuzuweisen, damit ich da paar E-Mails einrichten kann.
Leider schlägt das immer fehl, weil die "Domain schon existiert".
Kann mir mal jemand kurz auf die Sprünge helfen ?

Installierte Version 18.1 (Build 1409)
Debian 9.4

Vielen Dank im Voraus
Gruß mlan
nikko
Posts: 914
Joined: Fri 15. Apr 2016, 16:11

Re: [BUG Report] FQDN als Hauptdomain, vor anlage HTTPS erzwingen, UX

Post by nikko »

Der FQDN ist immer subdomain.domain.tld (z.B. server.domain.de) .Wenn dieser dem Server zugewiesen ist, ist dieser für den Server reserviert und kann nicht mehr anders verwendet werden.
The software said: Requires Win Vista®, 7®, 8® or better. And so I installed Linux.
User avatar
MLan
Posts: 483
Joined: Wed 20. Sep 2017, 23:05
Location: @home

Re: [BUG Report] FQDN als Hauptdomain, vor anlage HTTPS erzwingen, UX

Post by MLan »

hallo nikko,

Vielen Dank, hab das mal so geändert wie du geschrieben hast.
Hatte gehofft daß es auch anders geht, aber man kann nicht alles haben.
Gruß Mlan
nikko
Posts: 914
Joined: Fri 15. Apr 2016, 16:11

Re: [BUG Report] FQDN als Hauptdomain, vor anlage HTTPS erzwingen, UX

Post by nikko »

Nein, geht nicht anders. Ist aber auch nicht dramatisch, da unbegrenzt Subdomains vorhanden sind.
The software said: Requires Win Vista®, 7®, 8® or better. And so I installed Linux.
Locked