Beiträge von antondollmaier

Zitat von bravesurfer

Unter Ubuntu erhalten ich nach Installation des neuen liveconfig-keyring und Update folgende Fehlermeldung

Code

N: Das Laden der konfigurierten Datei »php/binary-i386/Packages« wird übersprungen, da das Depot »http://repo.liveconfig.com/debian bionic InRelease« die Architektur »i386« nicht unterstützt.

Das Repo kann auf amd64 eingeschränkt werden:

deb [arch=amd64] http://repo.liveconfig.com/debian/ bionic php

Das ist so korrekt, ja - siehe auch KB:

https://www.liveconfig.com/de/…an-mehrere-php-versionen/

Von Hand passend zur PHP-Version installieren.

Zitat von suppenuser

Gute Idee. Aber beides bitte mit Datum und Uhrzeit, dann hätte das richtig Stil .... (Einschalten am 23.2.2024 12:00, Ausschalten am 26.2.2024 8:00 Uhr)

Sollte kein Problem sein: ISPConfig schafft's auch. Sieht dann so aus:

require ["fileinto", "mailbox", "regex", "date", "relational", "vacation", "imap4flags", "envelope", "subaddress", "copy", "reject"];


#################################################################
# Autoreply
#################################################################


# Move spam to spam folder
if anyof (header :is ["X-Spam", "X-Spam-Flag"] "Yes", header :matches "X-Spam-Status" "Yes, *") {
# Stop here so that we do not reply on spams
stop;
}


if currentdate :value "ge" "iso8601" "2022-11-01T10:00:00" {
if currentdate :value "le" "iso8601" "2022-11-01T23:55:00" {


vacation  :days 1
:subject "Feiertag in Bayern"
:addresses ["xxx@example.com"]
"Liebe Kunden und Geschäftspartner,


am 01.11.2022 ist in Bayern Feiertag
An diesem Tag ist unser Büro nicht besetzt.


Ab 02.11.2022 sind wir wieder wie gewohnt erreichbar.
";


}
}

"Mailbox doesn't exist" ist doch eigentlich selbsterklärend? Oder existiert der Ordner auf dem Server tatsächlich?

Dovecot.local.conf erstellen/erweitern:

namespace inbox {
inbox = yes
separator = .
subscriptions = yes
type = private
mailbox Drafts {
special_use = \Drafts
auto = subscribe
}
mailbox Junk {
special_use = \Junk
auto = subscribe
autoexpunge = 30d
}
mailbox Sent {
special_use = \Sent
auto = subscribe
}
mailbox Trash {
special_use = \Trash
auto = subscribe
autoexpunge = 7d
}
}

Danach die Server-Konfiguration neu anstoßen.

Ergänzung: IonCube ist generell ... suboptimal. Bei der Verwendung von Profiler-Systemen wie Blackfire, New Relic oder Tideways streikt PHP dann auch mit einem Segfault.

Tideways kann nichts machen, das sei die Schuld von IonCube - und IonCube sagt, sie machen nichts, weil sie ja aktiv die Op-Codes von PHP ändern und die anderen damit schlichtweg nicht klar kommen würden.

Ganz auf IonCube verzichten geht offenbar nicht

Nicht am Ende einfügen, sondern die bestehende Zeile für den Mointpoint "/" ersetzen (bzw um die von mir ergänzten Quota-Parameter erweitern).

UUID=cf33b75b-cab6-4c3c-825a-71e1475bc82f /               ext4    errors=remount-ro,jqfmt=vfsv0,grpjquota=aquota.group,noatime,discard,nodiratime 0       1

reboot.

quotacheck -avgm; quotaon -ag

(quotaon hab ich gerade nicht im Kopf, bitte selbst verifizieren)

Also die Basic, aber mit Let's Encrypt?

Wir setzen Lexoffice für die Buchhaltung und ein eigenes an g*Sales1-angelehntes System für die tatsächliche Abrechnung ein (die finalen Rechnungen werden in LexOffice als Eingangsbeleg und nicht als "Rechnung" erfasst).

Die 50% Rabatt für drei bzw 12 Monate sind sicherlich nicht schön, aber besser als nichts. Für 25€/Monat baue ich mir keine solche Lösung, die auch noch GoBD-konform abgenommen ist. Selbst die 900€ für g*Sales sind hinnehmbar. Für den Preis baut mir kein Entwickler g*Sales nach.

Der Haken an Lexoffice: es hat zwar eine schöne API, es fehlen aber dann doch immer wieder Funktionen. So kann es nur einen Mehrwertsteuer-Satz pro Rechnung abbilden - und das g*Sales-System der Warteschlange gibt's ebenfalls nicht (nie wieder ohne). Wer also Kunden hat, die regelmäßig "dazubuchen", hat mit der Serienrechnung aus LexOffice massiv "Spaß".

Zitat von sTeaLth

Es wäre schön wenn es zumindest mal ein Datum gäbe, an dem es nun wirklich einen Release gibt.

"31.12.2039" würde uns doch auch nicht helfen...

Das Problem dürfte eher die Änderung des Mail-Clients auf den neuen IMAP/POP3/SMTP-Server sein - sonst gibt's selbst bei Änderung des DNS-Namens auf den neuen Server Probleme mit dem SSL-Zertifikat. Ohne (valides) TLS betreibt ja hoffentlich keiner mehr einen Mailserver.

Die Passwörter können über die SOAP-API übernommen werden: einfach den Hash aus der /etc/dovecot/passwd auslesen und via SOAP "HostingMailboxAdd" als Passwort mitgeben:

https://www.liveconfig.com/de/…ap/HostingMailboxAdd.html

Der Hash bleibt ein Hash und wird nicht erneut gehasht.

Alternativ: die /etc/dovecot/passwd auf dem neuen Server direkt ändern und das Passwort darin überschreiben. Solange der Kunde keine Änderung am Postfach durchführt, wird die Zeile nicht angepasst.

Vorletzte Option: via "auth_debug" und "auth_debug_passwords" die Plaintext-Passwörter ins Log schreiben lassen und von dort aus übernehmen. Natürlich nur bedingt sinnvoll und datenschutzrechtlich ... spannend.

Letzte Option: ohne die Details der Übernahme zu kennen gehe ich davon aus, dass die Kunden-Verträge übernommen wurden und keine GmbH/Kapitalgesellschaft gekauft wurde. Nachdem der Endkunde dem Wechsel des Vertragspartners doppelt zustimmen müssen (Datenübermittlung an Dritte, Wechsel des Vertragspartners - beides etwas, das der Kunde aktiv zustimmen muss), hat der Endkunde sicherlich auch kein Problem damit, in einen neuen (ggf für ihn besseren) Tarif auf einem neuen, besseren, Server zu wechseln.

Been there, done that

Nein, das ist aktuell nicht möglich: Die PHP-Konfiguration kann nur auf Vertrags-Ebene gesetzt werden.

Auf open_basedir würde ich im Übrigen gar nicht vertrauen: Aufrufe wie 'system("cat /var/www/foo/htdocs/wp-config.php");' werden von open_basedir nicht eingeschränkt.

Wir empfehlen unseren Kunden daher aktuell, bei relevanten Trennungen zwischen Webseiten auf verschiedene Accounts zu setzen. Linux-Dateisystem-Rechte verhindern obigen Fall nämlich sauber.

for f in /var/www/*/tmp; do
  home=$(dirname $f);
  u=$(stat -c %U "${home}/priv}"
  g=$(stat -c %G "${home}/priv}"
  dir="${home}/.ssh"
  test -d $dir || mkdir $dir
  chmod 0700 $dir
  chown $u:$g $dir
  touch $dir/authorized_keys
  chown $u:$g $dir/authorized_keys
  chmod 0600 $dir/authorized_keys
done

Mal kurz runtergetippt. Sollte klappen - die beiden stat hab ich nachgeschaut.

Die Datei wird nur angelegt, wenn du php-opt-8.2 aus dem LiveConfig Repository installierst.

Bitte prüfe die php82.lua:

# cat /etc/liveconfig/lua.d/php82.lua
-- register additional PHP interpreter with LiveConfig
LC.web.addPHP( {
['id']  = 'php82',
['cli'] = '/opt/php-8.2/bin/php',
['cgi'] = '/opt/php-8.2/bin/php-cgi',
['fpm'] = {
['bin']     = '/opt/php-8.2/sbin/php-fpm',
['start']   = 'service php82-fpm start',
['stop']    = 'service php82-fpm stop',
['reload']  = 'service php82-fpm reload',
['pool']    = '/etc/php-fpm/php82-fpm.d',
['sockets'] = '/run/php82-fpm'
},
['eol-date']  = '2025-12-08'
} )

Vermutlich ist hier etwas durcheinander gekommen - zumal bei dir als codename "php8" angegeben ist.

FTP (Systembenutzer) = SSH.

Wir haben die dnswl.org eingebunden.

Das sieht nach Server-Problem aus. Was steht in den Logs von LiveConfig?

Der Kunde nutzt die Passwort-Vergessen-Funktion. Dabei wird dann auch 2FA deaktiviert.