push? 2 Jahre später...
Beiträge von aziegler
-
-
Hier liegen z. B. schon 3 davon mit dem gleichen CN rum, 2 abgelaufene:
und dein Monitoring scannt herumliegende Dateien? Komischer Ansatz... -
Das wäre in der Tat interessant. Alternativ wäre ein härterer SPam-Check für externe Forwards interessant.
-
ja, das wäre nett das einstellen/überschreiben zu können
-
Das liegt nicht an LiveConfig oder der CipherSuite meines Erachtens, den verschlüsselten Zugriff können diese Programme in keinem Fall überwachen, egal welcher Mail-Provider da mit welchen Einstellungen genutzt wird.
Oder hast du hier anderweitige nachvollziehbare Beispiele parat? -
auch bei google ist das mailpostfach nicht "unendlich" groß, wozu also hier google in's spiel bringen?
mein (ungenutztes) gmail postfach hat derzeit 17GB Limit. -
Der Button ist in der 2.4.0 übrigens immer noch da...
-
ich hole das Thema mal hoch.
Die Usability ist gelinde gesagt schlecht, dass die User für eine Weiterleitung Autoresponder anlegen können, die aber nichts bewirken.
Bitte entweder die Option für Weiterleitungen entfernen oder technisch ermöglichen. -
das geht vermutlich nicht, ich fand gerade folgendes dazu:
"HTTP-01 is defined by the ACME standard to require HTTP on port 80"
anscheinend sieht der Standard dies nur so vor, dass Port 80 genutzt werden muss -
Das ist aber unsere Meinung, mir würde eher die Option fehlen das ich den Backup Link komplett deaktivieren könnte...
Das wäre in der Tat wünschenswert:
- Serverweit
- pro Angebot
- pro Wiederverkäufer
- pro Vertragalso schlicht wie ein Bestandteil der Verträge, der auf jeder ebene erlaubt/verboten werden kann wie auch die webapps
-
Hier hänge ich mich mal dran:
Wir hatten heute den ersten Kunden der es vermisst, auch die E-Mails selbst sichern zu können per GUI.
Was sie bei Confixx gewohnt waren, werden die meisten sehr ungern los...
Steht das überhaupt auf der Agenda oder wird das nie passieren? -
Was Herr Keppler schreibt klingt ja schon einmal gut.
Da wir bisher nur einen Server mit MySQL-Backend nutzen, wäre das für uns also schon fertig.Das fehlende PHP5 wird hingegen erstmal noch für andere Späße sorgen.
Fehlend? Spricht was gegen die Parallelinstallation weiterer Versionen, wie bisher auch? -
Hallo,
heute wurde angekündigt, dass die nächste Debian Version 9, codename "stretch", voraussichtlich am 17. Juni erscheinen wird.
Da sie ja schon länger Feature-complete ist:
Ist LiveConfig schon jetzt 100% lauffähig damit? Falls nicht, wird das bis zu diesem Termin noch erledigt?
Wir würden gerne ab dem Release-Termin keine Jessie-Systeme mehr installieren, um uns die kurz darauf folgenden dist-upgrades zu ersparen.Grüße
-
Dann muss nur noch sichergestellt sein das LiveConfig Debian 9 Kompatibel ist.sofern das dort stimmt & noch aktuell ist, dürfte Debian 9 Stretch schon von der LC-Lab-Version supported sein:
https://www.liveconfig.com/de/…4027&viewfull=1#post14027ich hoffe mal, dass die Version bald kommt und wirklich stabil mit Debian 9 zusammenarbeitet, damit wir nicht noch neue Server mit Jessie aufsetzen müssen nach dem Stretch-Release
-
ich würde mir auch eine bessere Kommunikation wieder wünschen, die letzte nicht LAB Version ist über 6 Monate alt.Aber ich will auch nicht alle 14 Tagen Updates wo sich mehr Fehler als Behebungen einspielen.
Da sind wir auf einer Linie. die 6 Monate wären mir aber piepegal, wenn separat davon Bugfixes in wenigen Tagen herauskommen würden auf einer Art stable-Branch. -
Ich sehe das größte Problem in der immer schlechter gewordenen Kommunikation (unbeantwortete E-Mails, nicht eingehaltene Zusagen per E-Mail, ignorierte konstruktive Foreneinträge en masse, Redmine tracker tot, LAB-changelog inzwischen ohne release-angabe zum change, ...).
An zweiter Stelle folgt die schlechte Bugfix-Strategie: Bug XY tritt auf? Bitte Lab-Version nutzen! Damit hat man dann aber wieder andere Bugs --> Pech gehabt. (aktuell z.B. teils kaputte Umlaute)
Aber eigentlich weiß die Firma das ja, wir und andere sagen das ja alles oft genug, wo wir wieder bei Kritikpunkt #1 wären
-
- Das Eingabefeld "Telefon:" sollte entfernt werden, da Let's Encrypt diese Funktion nicht mehr unterstützt. Sobald dort etwas eingetragen wird, kommt der Fehler "Error creating new registration :: Contact method tel is not supported".
ist in der aktuellen Lab-Version schon entfernt- In dem ACME Dialog sollte die Option "[x] auch 'www.'-Subdomain mit diesem Zertifikat berücksichtigen" nicht standardmäßig gesetzt sein, da wir sehr oft unseren "eher unerfahrene" Kunden erklären müssen, dass Sie den Harken entfernen müssen, wenn sie keine "www.subdomain.domain.tld" erstellt haben.
Da Let's Encrypt ja mehrere Domains mit auf das selbe Zertifikat nemen kann, wäre es villeicht sogar noch eine bessere Idee, die oben genannte Option zu entfernen, und durch einen [ weitere Domain hinzufügen ] Butten/Feld zu ersetzen.
Beides super Vorschläge, DAFÜR! -
PCI-konform bedeutet nicht automatisch state-of-the-art.
Deren Zertifizierung wird ja nicht jedes Jahr aktualisiert... -
nun hast du hier schon 3 "Experten" die zu häufigeren Neustarts raten.
Niemand hat was von "Angeberei" mit hoher Uptimezum Thema zurück:
wir haben derzeit auch ziemliche Probleme auf manchen Servern mit proftpd und TLS... Verzögerungen ohne Ende oder gar keine Verbindung möglich.
Meist nicht einmal reproduzierbar -
Ich würde mal behaupten, dass es eher umgekehrt nützlich wäre - niemand darf fremde Absender benutzen, nur explizit ausgenommene Accounts.
Ohne diese Ausnahmen ist es natürlich trivial, 2. Schritt wären Ausnahmen, 3. Schritt via LC einstellbar (aber nur als Admin, Reseller nicht)