Hallo Herr Keppler,
besten Dank, funktioniert. lcclient temporär stoppen reicht aus aus, um AC_TMPPWD auszulesen ![]()
VG,
Torsten Walther
Hallo Herr Keppler,
besten Dank, funktioniert. lcclient temporär stoppen reicht aus aus, um AC_TMPPWD auszulesen ![]()
VG,
Torsten Walther
Hallo,
nachdem wir Server von CentOS zu Ubuntu migriert haben, und sich der FTP Server von VSFTPD zu Proftpd geändert hat, müssen zusätzliche FTP Benutzer das Passwort einmal neu setzen. Soweit kein Problem.
Wie kann man das bei den FTP Usern für den SiteBuilder handeln?
Veröffentlichen geht erstmal nicht, da der Zugang beim ProFTPD noch nicht passt.-
ACCOUNTS/AC_INTERNAL kann ich in der DB auf 0 setzen, somit kann das Passwort über die GUI geändert werden.
Wie genau muss das neu Passwort den in SPS_FTPPASS der Tabelle SITEPROSITES gespeichert werden, damit der Sitebuilder dann wieder veröffentlichen kann?
Hallo Herr Keppler,
systemd-overrides müssten dann aber noch möglich sein, hat ja prinzipiell erstmal nichts mit ihrem PHP zu tun?
Wir nutzen z.b: /etc/systemd/system/php83-fpm.service.d/override.conf um ein angepasstes ExecStart für FPM zu verwenden.
Ansonsten, sehr schicke Angelegenheit ![]()
Man muss auch mal bedenken, dass selbst bei einer Preissteigerung der Abrechnungsoftware der Mehrwert durch gesparte Personalkosten / Mannstunden dennoch mehr als gerechtfertigt ist. Gsales hat immerhin auch in V2 eine durchaus sehr effiziente API. Dh man "kann" den Fakturierungs-Aufwand mit Automatisierung für die essentielle Rechnungslegung, durchaus auf "(eigenes) Bestellsystem -> Serienvorlange via API anlegen , Manuell im Gsales auf Abrechnen klicken > Warteschlange > Rechnungen erstellen " auf 1x im Monat mit Zeitaufwand 30min reduzieren. Nahezu unabhängig, wie viele Kunden man abrechnet.
Natürlich ist es schön Summe X widerkehrend zu sparen, wenn ich aber den Zeitaufwand für Implementierung & wiederkehrenden Workflow gegenrechne, finde ich eine Preisanpassung durchaus gerechtfertigt und angemessen.
Nach wie vor aktuell.
wann genau, kann man den mit einer Behebung des Bugs rechnen? Sind ja nun mittlerweile auch 5 Monate ..-
Oder wird dies durch die Arbeiten an LiveConfig 3 nicht mehr behoben werden?
Hab's rausgefunden, in der Tabelle ACCOUNTS musste noch die AC_SERVERID angepasst werden.
Ich habe vor einiger Zeit ein LiveConfig Clienten von CentOS zu Ubuntu migriert. Ging mit Anpassungen in der Datenbank auf dem MasterServer recht problemlos.
Nur beim Editieren der Cronjobs erhalte ich im Logfile "No system account defined for new new crontab" .
An welcher Stelle müsste ich ansetzen?
Nach wie vor aktuell.
wann genau, kann man den mit einer Behebung des Bugs rechnen? Sind ja nun mittlerweile auch fast 4 Monate ..-
Kurze Nachfrage, 7.0,7.1,7.3,7.4 für Ubuntu 22 kommen noch ?
php-7.0-opt-ioncubem php-7.1-opt-ioncube, php-7.3-opt-ioncube, php-7.4-opt-ioncube sind ja bereits im Repo drin.
Super, besten Dank.
Wir haben die Anforderungsliste eben entsprechend aktualisiert. Ja, Ubuntu 22.04 LTS wird unterstützt (= unsere Unit-Tests laufen dort vollständig und anstandslos durch).
Es stehen lediglich noch keine "alten" PHP-Versionen zur Verfügung. Pakete mit PHP 5.6, 7.4 und 8.0 sind in Arbeit und sollten in den nächsten Tagen fertig sein.
Hallo,
können Sie abschätzen wenn die alten Versionen zur Verfügung stehen?
Wird nun Ubuntu 22 offiziell unterstützt?
Irgendwelche Neuigkeiten bezüglich der Ubuntu 22.04 Unterstützung?
Hallo,
der Joomla AppInstaller ist derzeit nicht funktional. Es erscheint folgende Fehlermeldung:
Fatal error: Array and string offset access syntax with curly braces is no longer supported in /var/cache/liveconfig/installer/wai-joomla-4.1.2-1.php on line 495
PHP CLI Version ist 8.1 (geht auch unter 8.0 nicht)
Generell wäre ein Update der Pakete nicht verkehrt, derzeit werden mir folgende Versionen angeboten:
Guten Tag Herr Keppler,
mittlerweile sind wieder fast 3 Monate vergangen.
Gibt es bereits ein Update hierzu?
Dem schließe ich mich an.
Guten Tag,
gibt es bereits ein Update hierzu?
Edit: Sehe gerade dass in der Wissendatenbank Ubuntu 22 bereits aufgeführt wird, heute bearbeitet. Wird dann vermutlich nicht mehr lange dauern ![]()
Hallo Herr Keppler,
unter Ubuntu 20.04 schreibt der Updater folgendes in die /etc/dovecot/dovecot.conf
Das -e ist an der Stelle nicht passend.
ZitatAlles anzeigen# <EOF>-----------------------------------------------------------------------
-e
service stats {
unix_listener stats-writer {
user = mail
group = mail
}
}
Gibt schon Szenarien in denen das Sinnvoll wäre. Zumal es auch noch SSL abseits von Let's Encrpyt (verwaltet via LC) gibt.
Eine Varnish/Hitch Konstellation (als Frontend) muss man halt immer mit einer extra IP im LC lösen, da LC die Vhosts nur mit 80/443 publiziert.
Ein von LC konfigurierter Apache auf 8080/8443 wäre da schon praktisch. Man kann's mit internen IP's lösen, nimmt sich damit aber auch die Möglichkeit Seiten über die public IP zu testen.
Zudem wäre es auch praktisch wenn man (ähnlich wie bei CFX/Plesk usw) Schalter mit httpd konfigurierbaren Optionen je Domain/Account hätte. Beispielsweise für die Konfiguration der .httpd.conf im Userverzeichnis. Als Beispiel nenne ich mal ModSecurity AN/AUS , und die Entscheidung dann dem Kunden zu überlassen.