Hostsharing Wiki - Benutzerbeiträge [de]

Diskussion:Nextcloud

2024-04-23T12:40:21Z

Eis: Neuer Abschnitt /* PHP via cron */

== Umstellung auf bigint ==
Unter https://docs.nextcloud.com/server/17/admin_manual/configuration_database/bigint_identifiers.html steht etwas was wohl sudo benötigt.
Wie kann das eingerichtet werden?

''An der Stelle wird kein sudo benötigt. Das Handbuch macht ein "sudo -u www-data", also sudo zum User des Apache-Webservers. Bei Hostsharing laufen die PHP-Programme mit den Rechten eines Linux-Shell-User, dem Domain-Admin. Dieser User kann das Programm "occ" mit einem geeigneten PHP-Interpreter aus dem Installationsverzeichnis heraus aufrufen, z.B.: "php7.4 occ list"''

== Mehr Performance Tuning ==

https://docs.nextcloud.com/server/20/admin_manual/installation/server_tuning.html

Bei mir war die Nextcloud anfangs enorm langsam (sogar der login ist gescheitert aufgrund der langen Laufzeit. Ich habe in die php.ini folgende Zeilen aus o.g. Doku hinzugefügt und ein bisschen die Apps / Plugins verändert.

pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18

''Diese Parameter beziehen sich meines Wissens auf php-fpm. PHP läuft bei Hostsharing aber per Default als Fast-CGI-Anwendung. dann dürften diese Parameter keine Auswirkung haben.''

== PHP via cron ==

Der Cron-Job sollte in vielen Fällen (allgemein) eher so aussehen:
<pre>*/15 * * * * /usr/bin/php -c ../doms/<DOMAIN>/fastcgi-ssl/php.ini ~/nextcloud/cron.php</pre>

Also mit der angepassen PHP-Konfiguration. Das merkt man auch im Vergleich von:
<pre>php -c ../doms/<DOMAIN>/fastcgi-ssl/php.ini occ setupchecks</pre>
und
<pre>php occ setupchecks</pre>
Bei Letzterem geht dann z.B. opcache nicht, und die PHP-Config bzw. Speicher stimmt nicht wie über fastcgi u.s.w...

Diskussion:HS-Mailrouting

2024-04-11T00:11:38Z

Eis: obsolete

Diskussion:HS-Mailrouting

2024-04-10T23:54:59Z

Eis: Die Seite wurde neu angelegt: „Die Aussage "...so wird die E-Mail an den Mailserver mit höherer Priorität weitergeleitet." ist bestenfalls missverständlich. Die Mail wird nämlich nicht "weitergeleitet", vielmehr findet der Ausgangsmailserver die entsprechenden Einträge und versucht dann die Mail an den entsprechenden Mailserver direkt zuzustellen. Warum ist das relevant? Beispiel: Nehmen wir an, ein externer Mailserver mit IPv4-only sendet eine Mail an "alice@blabla.de". Im MX-R…“

Die Aussage "...so wird die E-Mail an den Mailserver mit höherer Priorität weitergeleitet." ist bestenfalls missverständlich.

Die Mail wird nämlich nicht "weitergeleitet", vielmehr findet der Ausgangsmailserver die entsprechenden Einträge und versucht dann die Mail an den entsprechenden Mailserver direkt zuzustellen.

Warum ist das relevant? Beispiel:
Nehmen wir an, ein externer Mailserver mit IPv4-only sendet eine Mail an "alice@blabla.de". Im MX-Record bei Hostsharing steht dann "mail.blabla.de". Weiter steht '''kein''' A-Record drin, sondern nur ein AAAA-Record der mail.blabla.de auf die IP des Zielservers verweist. (Weil z.B. der Zielserver nur IPv6-only ist.) Folge: Die Mail wird '''nicht''' zugestellt.

Wird dieselbe Mail jedoch von einem IPv6-fähigen Mailserver versandt, wird sie zugestellt. Weil es sich eben '''nicht''' um eine "Weiterleitung" handelt.