rseffner

1) Beim Update von v0.10.3x.x wurde der MySQL-Server NICHT übernommen. 2) Lege ich in v2 einen MySQL-Server an, so gibt es folgenden Fehler wenn die Aktivierung für alle Kunden ausgewählt wurde. Der Server wird aber angelegt. Uncaught exception 0 in_array(): Argument #2 ($haystack) must be of type array, null given #0 /var/www/webs/its/froxlor***sier.de/lib/Froxlor/Api/Commands/MysqlServer.php(520): in_array(0, NULL) #1 /var/www/webs/its/froxlor***sier.de/lib/Froxlor/Api/Commands/MysqlServer.php(448): Froxlor\Api\Commands\MysqlServer->addDatabaseFromCustomerAllowedList(0) #2 /var/www/webs/its/froxlor***esier.de/admin_mysqlserver.php(124): Froxlor\Api\Commands\MysqlServer->update() #3 {main} 3) Das Löschen von MySQL-Server wird mit Fehler quittiert (vermutlich liegt der selbe Grund wie für 2) vor) Uncaught exception 0 array_search(): Argument #2 ($haystack) must be of type array, null given #0 /var/www/webs/its/froxlor***ier.de/lib/Froxlor/Api/Commands/MysqlServer.php(500): array_search(3, NULL) #1 /var/www/webs/its/froxlor***sier.de/lib/Froxlor/Api/Commands/MysqlServer.php(213): Froxlor\Api\Commands\MysqlServer->removeDatabaseFromCustomerAllowedList(3) #2 /var/www/webs/its/froxlor***sier.de/admin_mysqlserver.php(77): Froxlor\Api\Commands\MysqlServer->delete() #3 {main} 4) Die Meldung zum Löschen eines MySQL-Servers hat wohl keinen deutschen String Sicherheitsabfrage question.admin_mysqlserver_reallydelete

Danke.

Oh ja, 192.168.x.x 😉 Aber warum sollte das verboten werden - einen merkbaren Namen für etwas im LAN einsetzen. Warum der Nutzer keinen DNS-Eintrag hat? Weil das mit der Ziel-IP nicht getan ist sondern einen Pfad besitzt. mailarchiv.trala.la - http://192.168.1.1/qmail.

Man kann doch http(s)://domain.tld/path in das Feld "Pfad" einer Domain eintragen um im VHost einen Redirect zu erreichen. Das geht leider mit http(s)://11.22.33.44/path nicht, weil angeblich der Doppelpunkt stört - ich denke aber es sind die Ziffern, weil z.B. http(s)://11.22.33.44.de/path funktioniert.

Tut es. Danke für den rasanten Support.

Ich habe gerade festgestellt, dass das Löschen eines DNS-records (hier TXT) zu folgendem Fehler führt "Domain nicht gefunden oder keine Berechtigung". Da ich für die selbe Domain aber weitere records anlegen kann, vermute ich, führt die Meldung in die Irre. Das apache2 error log gibt nichts her. Wie können wir dem auf den Grund gehen?

Hallo, mir ist klar, dass ich pro Domain die DNS-Unterstützung de-/aktivieren kann. Mir ist auch klar, dass aktiviert bei gleichzeitig aktivierter E-Mail-Domain dann A- und ggf. auch AAAA-records für die Subdomains/Hosts mail, smtp, pop3 und imap angelegt werden. Ich weiß sogar, dass ich diese Einträge auf Wunsch übersteuern kann - mein neuen validen Werten. Auch das Führen von manuell gepflegten Zonefiles ist mir klar. Was ich in einem konkreten Fall aber möchte ist, die Subdomain "mail" woandershin zeigen zu lassen und gleichzeitig deren IPv6-Derivat zu deaktivieren (ohne IPv6 für den Rest der Domain zu deaktivieren). Gesucht ist also eine Möglichkeit z.B. im Rahmen der DNS-Übersteuerung durch eine spezielle Option das Anlegen eines einzelnen dieser Automatischen Records zu verhindern. Geht das irgendwie (ohne eine manuelle Zone anlegen und pflegen zu müssen - denn das habe ich jetzt und für den "Kunden" sieht das im Froxlor aus, als könne er im DNS-Editor rumobern, nur führt das ja dann zu nix)?

Also wie macht man froxlor dann unter einer eigenen Subdomain, die vom Hostnamen abweicht, RICHTIG verfügbar? Als Hostname sehe ich das was u.a. in /etc/hostname und /etc/hosts steht sowie im PTR zur IP kommt.

Setting "Direkt via Hostname erreichbar" = Nein Allerdings habe ich /var/www/froxlor in das Docroot einer Subdomain eines Kunden verlinkt und die Option an, das die Domains in den Pfadnamen auftauchen sollen. Vielleicht führt dann eben genau dieses basenamedir() dazu, dass das wie zwei FQDN aussieht. Ist mein Setting ein von den best practices abweichender Weg?

Komisch das. Mein oben dargestellter geänderter Code löst mein Problem. Nach den Einstellungen kann ich morgen schauen.

Das kann ich doch wieder alles nicht bedienen ;-(

$script = "/index.php"; // $_SERVER['SCRIPT_NAME']; if (Settings::Get('system.froxlordirectlyviahostname') == 0) { $script = \Froxlor\FileDir::makeCorrectFile("/" . basename(__DIR__) . "/" . $script); $activationlink = $protocol . '://' . $script . '?action=resetpwd&resetcode=' . $activationcode; } else { $activationlink = $protocol . '://' . $host . $port . $script . '?action=resetpwd&resetcode=' . $activationcode; }

Ich habe da eine Spur in der index.php um die Zeile 488. Und zwar habe ich in die Variable $activationlink zwischen "... $port . " und "$script ." mal etwast wiedererkennbaren Text geschrieben. Das führt dazu, dass der Link in der Mail dann https://server-fqdnTEXT/froxlor-fqdn... lautet. Das Problem muss also aus dem "if (Settings::Get('system.froxlordirectlyviahostname..." kommen, denn hier wird script von "/index.php" eben auf den Hostnamen umgebaut. In dem Fall sollte der activationlink wohl innerhalb des "if" ohne $host gesetzt werden und die bestehende Zeile sollte in einen else-Zweig?

Hallo, bei mir enthält die Mail die durch "Passwort vergessen" generiert wird einen Link im Format https://server-fqdn/froxlor-fqdn/index.php?action=resetpwd&resetcode=b89...... Die doppelten FQDN stören halt unbedarfte Anwender. In meinem Fall muss "server-fqdn" (was hier ein Platzhalter ist) weg.

Naja, als spoolenden Backup-MX kannst Du die Froxlor-Kiste ja RFC-konform einsetzen. Du kannst dann nur nicht per Webmail in die Queue schauen und musst warten bis der Exchange wieder tut. So sind die Absender Ihre Mail an Dich in Deinen Hoheitsbereich los. Ganz Dringendes könnte sich ein admin unter /var/spool/postfix mit einem Editor ansehen 😉 Und wenn der Exchange wieder online kommt, gibt Dein Froxlor-Server dem dann die Post. Das Ganze konfigurierst Du aber außerhalb von Froxlor bei postfix z.B. mittels sauberer DNS-Zone und "permit_mx_backup_networks".

Das kann per RFC so nicht funktionieren. Im DNS hinterlegst Du MX Records, wo die Mail an diese Domain hin soll, alle MXe (wenn mehrere eingetragen sind) sollten versuchen die Mail dem MX mit der höchsten Priorität zu geben. der weiß dann wo die Postfächer sind. Wenn du einem weiteren MX-Server Postfächer für die Domain gibst, obwohl der nicht die höchste Priorität hat, kommt der je nach Software und Konfiguration in einen Zielkonflikt : lokal ablegen oder dem MX mit hoher Priorität geben. Man könnte das als "split brain" bezeichnen, denn je nachdem wo Absender Mails einliefern, liegen die dann auf dem einen oder anderen Mailserver. Wenn du ein Backup a la "dann lese ich im Störungsfall meine Mails halt dort" haben willst, sollte Froxlor "bester" MX sein und Postfächer haben. Der Exchange holt dann per POPconn ab (oder so was auch immer Du einsetzen willst). Das hat auch den Charme, dass die den Exchange nicht ins Internet stellen musst (aber vermutlich will man haute ja auch OWA). Wenn der Exchange mal nicht geht, kannst Du per Webmail in die Postfächer auf dem Froxlor gucken. Aber das wird nie hübsch synchron - Du sieht keine bereits zugestellten Mails, schaltest Du "keep" ein hast Du keinen synchronen gelesen/gelöscht-Status. Dafür sind eigentlich dovecot- oder Exchangecluster da.

Doch, der globale Alias IST eingerichtet als acme.conf in /etc/apache2/conf-available und verlinkt nach conf-enabled. apache2ctl --configtest hat auch nichts zu meckern. ohne diese acme.conf hat die Validierung ja nicht geklappt, weil man per http-Requst nicht ans secret kam. Nein ich habe SSL-Redirect nicht aktiviert in dem Zustand in dem ich das Verhalten hatte und beschrieb. Das ist der entscheidende Unterschied dann, dass das Flag gesetzt ist "mach wirklich was". Denn nur den Job zu triggern führt beim n-ten Durchluaf ja nur zu Erkenntnis es wäre nichts zu tun. Dann kann ich mir die ganze Zertifikate sparen und einfach 20 mal die selbe AliasDomain setzen und die bekommt dann ein Zertifikat für 21 Namen? Dennoch habe ich reproduzierbar beobachtet, dass: - wenn eine http-only domain bereits angelegt ist - man SSL und LE aktiviert - dabei als DocumentRoot eine URI einstellt - der cron-job läuft - ZUERST LE gefragt wird und nicht verifizieren kann weil am Ziel (DocumentRoot) keiner das secret hat - DANN erst die VHosts neu gebaut werden und die RedirectAusnahme enthalten - der globale well-known Alias offenbar einem Redirect nachgeordnet behandelt wird Ohne weitere Abhängigkeiten zu kennen, sollte die LE-Routine im cron-job meiner Meinung nach erst laufen, wenn die VHosts erstellt sind und apache2 reloaded wurde. Hier reden wir wohl aneinander vorbei. Der http-only-VHost WAR bereits erstellt.

Guten Morgen, wenn ich eine Domain nur für http angelegt habe und im DocumentRoot statt einem absoluten/relativen Pfad eine URI (https://domain.tld/" steht und ich dann SSL mit LetsEncrypt machen lassen möchte, wird durch den cron-Job zuerst LE gefragt - was scheitert, weil domain.tld das verify nicht bedient - und dann erst im VHost die rewrite-Ausnahme für die challenge bei Redirect eingetragen. Ein erneuter cron-Lauf oder der acme.sh-Job allein lösen das Problem nicht auf. Erst die Funktion "config neuschreiben" löst den Knoten. Vielleicht könnte man hier die Reihenfolge der Arbeitsschritte überdenken. Erst VHost, dann zu LE anfragen. btw. Trage ich hingegen das Weiterleitungsziel selber in die VHost-Einstellungen ein (z.B. "Redirect 301 / https://domain.tld/"), dann legt Froxlor NICHT automagisch eine Ausnahme an, wenn man LE aktiviert. Das muss wohl so sein, weil es ja nicht weiß, was der admin da im VHost verzapft hat und ob das vielleicht Sinn macht und auch die challange mit abdecken kann. Was passiert eigentlich, wenn man sich für AliasDomain entscheidet und dann für Quelle und Ziel LE aktiviert? Wird da ein entsprechendes SAN-Zertifikat generiert? Ich danke für Aufklärung.

Der Trick ist: record=SUB, type=CAA, priority=, content=0 issue "digicert.com", TTL=18000 Klar, woher soll Froxlor auch wissen on ich issue, issuewild oder iodef will.

Ich habe eine Domain DOMAIN.TLD im Froxlor mit LetsEncrypt angelegt. Die globale Option CAA-records anzulegen ist aktiviert, darus resultieren im zonefile: @ 172800 IN CAA 0 issue "letsencrypt.org" www 172800 IN CAA 0 issue "letsencrypt.org" Nun möchte ich für eine Subdomain, die auf einen anderen Host zeigen soll ein Zertifikat einer anderen Authority ausstellen, was am existierenden CAA scheitert. Ich habe dazu die Domain SUB-DOMAIN.TLD mit der Option "ist Subdomiain von ..." ohne Namenserver-Häkchen angelegt und in der DOMAIN.TLD mit dem DNS-Editor SUB 18000 IN A xx.xx.xx.xx SUB 18000 IN MX 10 mail.OTHERDOMAIN.TLD SUB 18000 IN TXT "SSLvalidateSECRET" angelegt. Wenn ich jetzt den CAA "digicert.com" hinzufügen möchte, meldet der DNS-Editor "DNS Eintrag ungültig". Versucht habe ich: record=SUB, type=CAA, priority=0, content=digicert.com, TTL=18000. Muss ich vielleicht den vorgegebenen CAA überschreiben und im content "letsencrypt.org, digicert.com" schreiben? Was mache ich falsch?

Neun? Sind nicht 11 stable und 10 oldstable? Rhetorische Frage - der OT muss wissen warum die Wahl auf 9 fiel und was das mit sich bringt.

Does 'mysql -h localhost -u root -p' work? If you get the same "access denied" message you have to enable localhost access for root to your database.

Wenn der Client Windows spricht, könnte ich MailStore home für die durchsuchbare Archivierung empfehlen.

PHP-Konfigurationen nachträglich für alle/viele Kunden erlauben wäre auch so ein Beispiel für Massenaktionen.

In my cases the "invalid user" is one of froxlors users and not froxlorlocal. Oh sorry, I use there a froxlor customer for froxlor-VHOST.