Man kann per Lua den Default (auch CLI) einstellen, falls das weiter hilft.
cat /etc/liveconfig/lua.d/php-default.lua
LC.web.PHPDEFAULT = 'php74'cat /etc/liveconfig/lua.d/phpcli.lua
LC.web.PHPCLI = '/opt/php-7.4/bin/php'Handbuch gelesen, bevor gemault wird?
https://www.liveconfig.com/de/…omization/lcdefaults.html
Oops, glatt übersehen. Danke schön für den Hinweis und die Lösung.
Darum gehören solche Optionen auch in die GUI besser für mehr Überblick.
In der LCDEFAULTS Tabelle der Liveconfig Datenbank ist das Limit für Aliase per Default auf 10 eingestellt.
mail.aliases.limit = 10
Vielen Dank. Hab das Limit nun erhöht. Auch wenn die GUI bei 999 Einträgen trotzdem mit Einzeleinträgen nicht sonderlich sinnvoll ist gegenüber einer netten Textbox wie bei Weiterleitungen.
Die Demo ist aktuell scheinbar nur eingeschränkt nutzbar, da die Zielseite des iframe Beispiels umgezogen wurde (Downloads und Rechnungen) und deshalb das js nicht mehr lädt - man sieht also die fehlerhafte Höhe.
Welche fehlerhafte Höhe?
Beide Beispiele funktionieren im Test im gleichen Ordner mit Struktur, wenn man den Download hinbekommt (habe es von Hand im Browser korrigiert). Lediglich die Verlinkung ist unter https://www.liveconfig.com/de/kb/iframe-api/ falsch.
Sollte vom Liveconfig Team korrigiert werden!
Die Verlinkung unter iframe-api bzgl. examples-20120814.zip müsste zu https://www.liveconfig.com/downloads/examples-20120814.zip zeigen aber ist im HTML-Code falsch zu lc-api-20120919.zip verlinkt wohl.
Das Schlagwort ist hier doch "Kontext-abhängig". Den meisten Endkunden ist weder das bisherige Handbuch, noch das neue Hosting-Handbuch zumutbar (IMHO!). Dafür sind die dortigen Anleitungen zu sehr als Handbuch und weniger als Schritt-für-Schritt-Anleitung gehalten.
Keine Sorge die Welt hat sich schon weiter gedreht. Inzwischen wollen ein Teil der Endkunden direkt Videos haben! :p
Letzteres kann ich IMHO nicht von der LiveConfig GmbH einfordern.
Das stimmt aber dann sollte auch das alte Live-Config-Handbuch in der Software (2.10.4) nicht mehr aktiv verlinkt werden oder auf die PDF-Datei vorerst zeigen. Zumindestens im Adminbereich ist es noch so.
Siehe https://abload.de/img/liveconfig_handbuch_amfkq3.jpg
Dazu sind manche Informationen durchaus darin nützlich und den Rest kann man zügig ersetzen bzw. ergänzen.
Ich selbst hätte die alten Seiten online gelassen und nur einen unübersehbaren Hinweis eingeblendet, das es stark veraltet sein kann und nicht mehr zur aktuellen Konfiguration passt bis eine aktuelle Version vollständig online ist.
dann geh doch zu netto!
Würde ich ja aber dort ist inzwischen die nächste Poststelle eingezogen und Netto ausgezogen! :p
Ganz deiner meinung... irgendwie is das schon doof dass die Gui noch nicht da ist, ebenfalls is das doof dass es keinerlei Info gibt wie das LCBackup funzt
Als Beta ist es inzwischen nutzbar und bis auf eine noch ausbaufähige GUI und mehr Optionen scheinbar funktional. Serverübergreifend konnte ich es leider noch nicht testen aber auf einem Server seit 3 Tagen sieht es gut aus.
Siehe https://www.liveconfig.com/de/…ighlight=backup#post18784
Nur Einzelfelder bzgl. E-Mail Aliase sichtbar in der Admin-GUI. Hilfreich wäre eine Textbox als Alternative.
Liveconfig => Hosting => E-Mail => Eintrag wählen => Postfach/Adresse bearbeiten => Aliase
Siehe https://abload.de/img/liveconfig_aliase_max93jae.jpg
Klar geht das auch per Datenbank oder Skript auf der Shell. :mad:
EDIT:
Hatte das Handbuch übersehen bzgl. Limit anheben/einstellen aber das Anliegen mit Textbox vs. 10+ Einzelfelder bleibt. Unter "Weiterleitung" dagegen bekommt man eine Textbox statt einzelne Zeilen (mit Löschbutton).
PS: Ggf. nach "Feedback und Vorschläge" verschieben. Danke!
Die Frage ist halt auch, wie professionell ist es heute noch, Mails über PHP mail() zu versenden?!
PHP mail() ist sehr einfach zu nutzen. Natürlich ist es super ein Postfach bzw. SMTP zu verwenden, wenn möglich.
Die Frage ist mehr wie willst SMTP in jedes Skript einbauen ohne das ganze Fehlerhandling dabei zu bedenken?
Nur per try+catch wie im simplen Beispiel von PHPMailer 6.2+? (von nötigen Updates vom PHPMailer ganz zu schweigen)
Für den Rest darfst gerne eine Anleitung für Kunden schreiben wie Zugangsdaten, Port und nötige Einstellungen...
Wir unternehmen alle möglichen Anstrengungen um uns gegen SPAM zu schützen, DKIM ein zu bauen, usw. und dann versendet jede Wordpress Installation Mails via php anstatt sauber über einen korrekt konfigurierten Mailserver zu versenden...
Der Mailserver Postfix kann so konfiguriert werden, das die E-Mail über PHP mail() als SMTP für Filter anerkannt wird. Habe es selbst noch nicht ausprobiert. Siehe diese kurze Anleitung. Dies dürfte sich für Liveconfig adaptieren lassen.
Postfix erlaubt seit einer Weile mehrere Instanzen mit wenig Aufwand.
Es ist kein Standard auf den Servern und Liveconfig unterstützt es selbst bisher nicht.
Alternativ ein sendmail-wrapper mit passenden Abläufen (DB Anbindung) wäre auch denkbar.
Oder die beliebten Kontaktformulare.... Kunde jammert über unmengen von SPAM die sein eigenens uraltes Kontaktformular an ihn sendet.
Die Funktionsweisen von Kontaktformularen sind unverändert.
Nur die Schutzmaßnahmen haben sich über die Zeit verändert.
gab es hierzu eine Rückmeldung?
Zumindestens nicht in diesem Thema bisher.
Das fände ich sehr gut, da ich meine Blacklist und nachgelagerten Änderungen in den LUA-Scripten nicht mehr benötigen würde.
Welche LUA-Skripte genau sind im Einsatz?
Denke den Entwicklern würde mit Quellcodes der LUA-Skripte es einfacher fallen es integrieren bzw. nachvollziehen zu können.
Für einen Neustart der Dienste über Liveconfig per Button wäre ich auch.
Das ist das reguläre Verhalten bei Source-Adress-Auswahl, wenn die Adresse nicht explizit gesetzt wird.
In Liveconfig selbst sind die gewünschten IP-Adressen (IPv4+IPv6) für BIND9 ausgewählt, nur werden die scheinbar lediglich für eingehende Verbindungen gesetzt bzw. genutzt.
Für IPv6 kann eine IP mit "preferred_lft 0" auf "nicht für ausgehende Verbindungen nutzen" gesetzt werden. Ob das dann das Mail-Outbound-IP-Szenario weiterhin funktioniert, weiß ich adhoc nicht.
Danke für den Tipp. Leider soll es nur für BIND9/Liveconfig/Powerdns sein, nicht für den ganzen Server.
Der Server nutzt derzeit Ubuntu 20.04 LTS als Grundsystem.
Habe es auch wie im Handbuch steht und im Thema Bind9 näher beschrieben es versucht aber scheinen nicht die richtigen Optionen bzw. Befehle für BIND9 zu sein.
LiveConfig-Client dem Nameserver installieren und in den LC-Cluster einbinden. Läuft problemlos, so dass LiveCOnfig die Zonen dann auch auf den Slaves anlegt.
Sicherheitstechnisch benötigt Liveconfig/BIND9 dabei mal ein Update.
PowerDNS kann hmac-sha512. Liveconfig gibt den Algorithmus HMAC-MD5 bzgl. TSIG vor.
pdnsutil generate-tsig-key slavesha512 hmac-sha512
pdnsutil generate-tsig-key slavemd5 hmac-md5Dazu gibt es noch einpaar Fallstricke bei den IP-Adressen damit es an den anderen Server mit PowerDNS gemeldet wird.
Bei der IPv4 wird wohl die erste IPv4 in der Liste genommen (oder Haupt-IPv4 vom Server) seitens Liveconfig/BIND9.
Dagegen bei IPv6 die letzte IPv6 aus der Liste wenn eine Meldung an PowerDNS raus geht seitens Liveconfig/BIND9..
Anderenfalls endet PowerDNS in Meldungen das man nicht berechtigt sei.
Heißt in der Serverwaltung lauscht der BIND9 unter Liveconfig auf den eingestellten IP-Adressen aber nutzt es nicht für rausgehende Requests.
Inwieweit das praktikabel ist, muss jeder selbst entscheiden. Ich empfinde es als suboptimal, wenn ein Slave auch weiterhin auf eine Zone reagiert, die schon gelöscht ist.
Ja leider. Ein zusätzliches Skript für die Löschung ist nötig (oder per PowerDNS Webinterface/API mit Liveconfig lua gleich für alles nutzen). Als Test einfach mal die Domain in Liveconfig löschen und neu hinzufügen, schon hast ein Duplicate error bei PowerDNS im Log (loglevel=4).
nur wenn du die Mails über "Smarthost" reinbringst. Wenn Deine Kunden die Mails (z.b. bei Mailserver == Webserver) direkt einkippen, dann werden sie nicht limitiert.
Dafür wäre eine primäre und sekundäre Instanz von Postfix nötig und Liveconfig muss ggf. auch beachtet werden.
Dachte da mehr an einen sendmail wrapper. Liveconfig hat sowieso wohl keine GUI, SOAP API und ähnliches dazu.
Würde mich auch interessieren.
nur noch eine kurze Nachfrage, für Emails welche über die PHP mail() Funktion versendet werden, greifen die gesetzten Limits aber leider nicht :confused:
Würde mich auch interessieren :confused:
Mir würde es fürs erste aber schon reichen wenn es einen Default Wert gäbe.
Default Werte sind per CLI umsetzbar meines Wissens. GUI scheint weiterhin zu fehlen.
Siehe https://www.liveconfig.com/de/…ils-pro-Account-begrenzen
Oder löst Ihr das irgendwie anders?
LiveConfig Policy Daemon wäre eine Option per CLI.
Verweise für Details mal auf https://www.liveconfig.com/de/…(r4555)-freigegeben/page4
Ungetestet aber sollte laut Dokumentation (man lcpolicyd) funktionieren:
lcpolicyd set info@example.tld -1 1Leider finde ich aber nirgendwo die Einstellmöglichkeit im Vertrag ...
Habe leider auch keine Einstellung in der GUI gefunden. Wurde bereits im Jahr 2017 angekündigt...
Weder beim Hostingangebot noch Vertrag. Nutze Liveconfig 2.10.4 derzeit.
Irgendwo habe ich dann gelesen, dass es wohl nur per Cli möglich ist.
Siehe https://www.liveconfig.com/de/…2-3-0-(r4555)-freigegeben
Kann mir jemand helfen (z.B. mit der CLI-Anweisung, oder dem entscheitendem Hinweis wo nun dieses Limit pro Account eingestellt wird)?
Siehe https://www.liveconfig.com/de/…2-0-2-E-Mail-Limits/page4
Auf Seite 4 wird beschrieben wie man es von Hand per CLI pro E-Mailanschrift setzt und ein Skript für neue E-Mails.
Dazu noch ein kleines Skript für bestehende Daten.
Ich bin für jeden Tipp super dankbar ..
Hoffe konnte weiterhelfen. Die angekündigte Einstellung in der GUI konnte ich auch nicht entdecken. Soll ja laut Ankündigung seit Jahren enthalten sein aber der Änderungsverlauf sagte dazu auch nichts.
Vermutlich noch nicht integriert.
Auszug aus https://www.liveconfig.com/de/changelog/v2.0/ (bugfixes hab ich mal ignoriert)
Änderungen in Version 2.3.0-r4555 (05.05.2017):
- Policy-Server “lcpolicyd” zu Postfix hinzugefügt, um ausgehende E-Mails zu begrenzen
Änderungen in Version 2.8.0-r5579 (20.08.2019):
- lcpolicyd unterstützt nun Wildcard-Adressen (*@example.com) als Fallback für Domain-weites Limit
Ich bedauere das der Aufwand so hoch ist. Ändert sich bei CentOS in Zukunft vermutlich. Bin inzwischen froh nie CentOS 8 eingesetzt zu haben bei dem aktuellen Zirkus um CentOS 8+, zögerlichen Updates und EOL. Debian Linux 10.7+ ist in diesem Fall auch keine gute Wahl bzgl. älteren TLS Versionen ohne weitere Repos.
Beispiel MariaDB 10.3+ hat YaSSL derzeit unter Debian Linux 10.7 und das ist der letzte Müll keine cipher, keine Einschränkung auf TLSv1.2+ möglich und so weiter. In MariaDB 10.4+ wurde das Problem bereits behoben.
Große Firmen wie Google erlauben weiterhin TLS v1.0 und 1.1 bisher.
Was nutzt da z.B. ein CentOS 6 (das "erst" seit knapp 4 Wochen EOL ist), wenn das standardmäßig PHP 5.3 mitbringt?
Mir ging es auch weniger um EOL bzw. (E)LTS sondern um die TLS 1.0/1.1 Option in Liveconfig.
Scheinbar geht es erst ab Version 2.4.42 beim Apache2. Bei Nginx vermutlich ab Version 1.15.2
Getestet unter Debian Linux 10.7 mit Liveconfig 2.10.4, Apache2 2.4.38-3+deb10u4/nginx 1.14.2-2+deb10u3, 4 Domains mit 4 IP-Adressen. Also die Versionen sind im regulären Debian Linux 10.7 einfach schon zu alt.
Laut Changelog kam es in Liveconfig 2.9.2 (03.03.2020) dazu. (=> "TLSv1/TLSv1.1 kann nun beim Webserver pro IP-Gruppe deaktiviert werden").
Interessant wäre mit welcher Distro üblicherweise Liveconfig bei solchen neuen Funktionen getestet wird?
Debian Jessie ist End of Life seit 2018, die LTS wird ihr EoL auch in 3 Monaten erreichen.
Das stimmt so nicht ganz. Extended Long Term Support gibt es inzwischen auch und geht bis 2022.
Siehe https://wiki.debian.org/LTS/Extended
Wäre ein Upgrade nicht sinnvoll?
Nur wenn ein Upgrade auch Vorteile bringt oder auf einen Extended Long Term Support verzichtet würde.
In wie fern soll dieser Beitrag dabei helfen, ein Problem in LiveConfig zu lösen?
Er meint vermutlich wenn ältere Software den Funktionswunsch eventuell noch nicht unterstützte.
Hilfreich wäre erstmal anzugeben mit welcher Serversoftware das Problem besteht (z.B. apache, nginx, proftpd) neben Debian Jessie.
Auf Liveconfig 2.10.4 bezogen gehe ich von einem Webserver vorerst aus. Die Einstellung über Liveconfig für einen Webserver auch bei unterschiedlichen IP-Adressen scheint dazu nutzlos zu sein. Ich würde auch davon ausgehen das TLS eine globale Einstellung pro Webserver ist und lediglich die SSL-Server-Chiffren definierbar sein dürften.
Tipp wäre zwei Webserver(z.B. apache2, nginx) zu nutzen und in einem TLS v1.1/1.2 zu aktivieren sowie im anderen zu deaktivieren. Geht nur ab 2 IP-Adressen im System
Wir ändern in dem Zusammenhang derzeit die Verwaltung von PHP-Interpretern, so dass der AppInstaller "weiß" welche zusätzlichen PHP-Versionen bereitstehen und entsprechend inkompatible Anwendungen dann ausblenden kann.
Wurde das inzwischen umgesetzt?
Für die ganze "neue Generation" vieler Apps wird oftmals PHP7 benötigt, was auf Distributionen wie Debian 7/8, Ubuntu 14 und CentOS nicht zur Verfügung steht.
Wünschenswert wäre bei PHP7+ im System nur noch aktuelle Apps zu haben.
Contao 3.5.25, EOL im Jahr 2018, Update auf 4.4+ als Minimum nötig
Drupal 7.69 vom 18.12.2019, OK
Gallery 3.0.9 vom 28.06.2013, OK
Joomla! 3.9.19 vom 01.06.2020, OK
Magento 1.9.3.8 vom 24.02.2016, EOL im Juni 2020, Update erforderlich
MediaWiki 1.34.1 vom 26.03.2020, EOL November 2020 (Auf 1.35.x LTS bis 2023)
modified Shop 1.06 rev 4642 S vom 16.04.2015, Update erforderlich
ownCloud 10.5 vom 03.08.2020 (Major-Update alle 18 Monate nötig)
phpMyAdmin 4.7.9 vom 15.10.2020, OK
Roundcube 1.4.9 vom 27.09.2020, OK
TYPO3 6.2.30, EOL 01.12.2020 erreicht, Update erforderlich: https://typo3.org/cms/roadmap
WordPress 5.6 vom 08.12.2020, OK
Stand: 24.12.2020
Unter https://www.liveconfig.com/de/…ization/appinstaller.html steht das der Anwendungs-Installer Q4/2020 überarbeitet werden soll. Ich bin gespannt ob wir das noch zu Lebzeiten erfahren.
Und hier nun der Befehl für alle, die die veralteten Anwendungen deaktivieren wollen:
Codesqlite3 -line /var/lib/liveconfig/liveconfig.db ' update APPREPO set AR_DISABLED = 1 where AR_NAME = "phpMyAdmin"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "TYPO3"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "Gallery"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "Drupal"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "ownCloud"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "Roundcube"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "Contao"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "Magento"; update APPREPO set AR_DISABLED = 1 where AR_NAME = "modified Shop";'
Danke!
