Jump to content
Froxlor Forum

chrisiwien

Members
 View Profile  See their activity

  • Posts

    53

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Posts posted by chrisiwien

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted

    Folgendes Verhalten: bei der Hauptdomain domain.com kann ich nicht auf die PHP-Dateien zugreifen (502 Bad Gateway) aber auf die statischen Dateien (Texte, Bilder) schon.

    Bei der Subdomain subdomain.domain.com leitet der Server ins Nirvana. Ohne Versuch gezielt eine Datei aufzurufen kommt ein 403er mit Dateiversuch ein 404er.

    Und in den Error-Logs ist nach wie vor permission denied zu finden.

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted 

    # /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat extrausers
group:          compat extrausers
shadow:         compat extrausers
gshadow:        files

hosts:          files dns
networks:       files dns

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

     

    Datei var/lib/extrausers/group: 

    domain:x:10000:domain,www-data,froxlorlocal
domain2:x:10001:domain2,www-data,froxlorlocal
domain3:x:10002:domain3,www-data,froxlorlocal

    Ist das so richtig?

     

     

     

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted

    2020/12/16 22:06:12 [crit] 6725#6725: *3 connect() to unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket failed (13: Permission denied) while connecting to upstream, client: 80.109.49.138, server: domain.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket:", host: "domain.com"

    und für eine subdomain.domain.com (da liegt eine Testseite):

    2020/12/16 22:06:10 [crit] 6725#6725: *1 stat() "/var/customers/webs/virtualbooth/index.php" failed (13: Permission denied), client: 80.109.49.138, server: virtual-booth.domain.com, request: "GET /favicon.ico HTTP/2.0", host: "virtual-booth.domain.com", referrer: "https://virtual-booth.domain.com/favicon-32x32.png"
     

    Der Froxlor-Admin läuft zum Glück. Da ist plötzlich in den vHosts ein Hund drinnen.

     

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted

    Ok, danke für Rückmeldung.

    Ich habe jetzt den Mastercronjob mit --letsencrypt --force --debug laufen lassen. Es erscheint eine Fehlermeldung "[error] could not find file 'domain.com.cer' in '/root/.acme.sh/domain.com'". Das selbe für die anderen Zertifikatsdateien (key, cer, csr).

    Im Ordner '/root/.acme.sh/www.domain.com' sind Zertifikatsdateien.

    Wohlgemerkt, ich leite www.domain.com via dem nginx-Configbefehl 'return 301 https://domain.com$request_uri;' (eingestellt in den vHost-Settings von www.domain.com) auf die non-www-Adresse um. Im Froxlor-Panel wird das Zertifikat sowohl für die www also auch für die non-www-Adresse angezeigt.

    Im Browser erscheint domain.com mit gültigem Zertifikat. Mach ich mir ev. mit diesem nginx-Redirect einen Murks rein? Muss ich den Redirect von www auf non-www anders lösen?

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted

    "zumal du damit jetzt natürlich die Möglichkeit zum debuggen ausgelöscht hast" - echt? Ich hab ja nur die Zertifikatseinträge gelöscht. Ist halt blöd, meine Website rankt für meine Schlüsselwörter in Google recht gut, die will ich nicht ohne Zertifkat stehen lassen weil dann potentielle Kunden die Meckerei im Browser sehen.

    Ok, kann ich mich so herantasten ob der Cronjob überhaupt automatisch ausgeführt wird? Wie kann ich das prüfen? Über die Server-Logs? Zudem bringt das manuelle Ausführen ja nix, erst das Löschen und Server-Restart...

    Liegt das ev. an der nginx-Konfiguration? Soll ich diese posten?

    Auf einem anderen Server den ich betreibe (Apache) steht im Ordner "var/www/froxlor/.well-known/acme-challenge" nur ein Eintrag a la "AdVu25vcdf9-orM5-LIFssjJx4G6JxgjAgzVR6OCzVfIM". Beim nginx-Server bleiben dort immer die alten Zertifkatseinträge stehen. Nachdem ich die lösche und den nginx-Server neu starte gehts.

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted

    Lieber d00p!

    Ich bin unglücklich. Ich habe jetzt die 3 Monate gewartet, heute war das Zertifikat wieder ungültig. Die automatische Erneuerung hat nicht funktioniert.

    ich habe wieder die Einträge in /root/.acme.sh/ und /var/www/froxlor/.well-known/acme-challenge gelöscht, den froxlor Master-Cronjob laufen lassen und dann den Server mit service nginx restart neu gestartet, jetzt passt es wieder.

    Wo kann ich weiter nachforschen warum die automatische Aktualisierung nicht hinhaut? Ev. wird der Master-Cronjob nicht richtig ausgeführt?

     

    Help!

    Schöne Grüße aus Wien

     

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted

    Durcheinander: sorry, aber ich dachte wenn ich alle Schritte ins Posting schreibe ist es klarer...ich weiß, so sieht es nicht aus.

    Ich war der Meinung dass die Ausführung des froxlor Master-Cronjobs auch den Webserver neu startet. Zumindest meine ich dass ich bei anderen Änderungen der Konfiguration den Cronjob manuell ausgeführt habe und es hat gepasst. Ich habe den Cronjob mehrere Male ausgeführt, erst "service ngnix restart" hat dann was gebracht.

    Pfad zu acme.conf: Ok, d.h. wenn der Pfad falsch ist bindet nginx die Datei nicht richtig ein, korrekt? Die früheren Zertifikate wurden trotz falschen Pfades ausgestellt - die Tokens der früheren Zertifikate waren auch in /var/www/froxlor/.well-known/acme-challenge zu finden - , die Verlängerung hat halt nicht geklappt. Der Inhalt der acme.conf war trotz falschen Pfades die korrekte Froxlor-acme-Konfiguration in nginx-Notation.

    Token: ok, das beruhigt mich.

    Ich muss halt in 3 Monaten schauen ob es geht. Schön wäre es wenn es eine Liste mit Parametern gäbe wie das automatische Update garantiert funktioniert. Aber Server und immer gleichbleibende Parameter...man wird ja wohl noch träumen dürfen! 😉

     

    Danke für die Rückmeldung.

     

    Automatische Verlängerung von Let's Encrypt-Zertifikat

    in German / Deutsch

    Posted

    Hallo d00p!

    Vor ein paar Monaten habe ich meinen Server auf nginx umgestellt, nur klappt schon zum zweiten Mal die automatische Let's Encrypt-Verlängerung nicht (für den einzigen SSL-vhHost am Server).

    Den Ordner /etc/apache2/ habe ich auf dem Server belassen.

    Ich habe es mittlerweile hinbekommen dass ein neues Zertifikat für diesen SSL-vHost aktiv ist, aber ich frage mich ob ich in drei Monaten nicht wieder vor dem selben Problem stehe...

    Folgende Schritte habe ich manuell unternommen (in der Reihenfolge):

    1. php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug - Kein Erfolg, in Froxlor wurde trotzdem das alte, ungültige Zertifikat angezeigt.
    2. Das ungültige Zertifikat in Froxler gelöscht (x-Button).
    3. Erneut php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug ausgeführt, nun war das neue Zertifikat in Froxlor sichtbar.
    4. Trotzdem wurde auf der Website das alte Zertifikat angezeigt.
    5. Den alten Apache-Pfad der acme.conf auf /etc/nginx/ gesetzt (Inhalt ist der Standard-Froxlor-nginx-Config-Code)
    6. Die Einträge in /root/.acme.sh/ gelöscht und den Cronjob erneut manuell gestartet. Kein Erfolg, nach wie vor das alte Zertifikat auf der Website.
    7. Die acme-challenge-Tokens in /var/www/froxlor/.well-known/acme-challenge gelöscht und Cronjob ausgeführt. Kein Erfolg.
    8. Den nginx-Server restartet - dann hat es funktioniert, neues Zertifikat ist nun auf der Website sichtbar.

    Vmtl. habe ich da was durcheinander gebracht. Jetzt ist kein Token mehr im Ordner /var/www/froxlor/.well-known/acme-challenge zu finden - ist das ein Problem? Ich glaube ich hab verstanden, dass NUR beim Einholen des Zertifikates diese Tokens zur Prüfung wichtig sind. Da das Zertifikat ja schon existiert ist der Token momentan nicht wichtig.

    Wie kann ich diese Tokens wieder generieren? Werden die bei der automatischen Verlängerung neu generiert?

    Wie kann ich sicher sein dass die automatische Verlängerung läuft?

    Hast Du einen Tipp für mich?

     

    Grüße aus Wien

     

     

    WordPress: System-Temp Ordner nur mehr mit chmod 777 verwendbar

    in German / Deutsch

    Posted

    vor 22 Minuten schrieb d00p:

    ehm ja überprüfe mal die uid/guid ....aber anlegen von gleichem user geht eigentlich nicht wenn es den ordner noch gibt?! Prüfe mal die Permissions auf dem ordner, sollte komplett "user:user" sein (zur not mal 'chown -R user:user /var/customers/webs/user)

    Ha, das weiß ich garantiert dass das username:username ist... da ich keine stabile FTP-Verbindung mit proFTP zusammenbekomme gehe ich immer über SFTP mit root rein und chmode dann den gesamten Ordner in der Shell händisch auf den username... *rotwerd* - was soll ich tun, wieder zig Stunden in das Thema FTP investieren...uff...

    Gack: Hab folgendes entdeckt: der Temp-Ordner (var/customers/tmp/username) hat die User/Gruppenzuweisung (in WinSCP angezeigt) 10006 [10006], währenddessen die anderen - funktionierenden - haben username2 [10006]. Wird auch mit ls -l so angezeigt.

    Hab den Temp-Ordner jetzt manuell mit chown -R auf username:username gesetzt und ...

    ... es läuft! 😀

    Danke Dir für den Zuspruch! Da ja alles mit Froxlor von Haus aus gehen sollte hab ich hier gefragt. War keine schlechte Idee, wieder was gelernt!

     

    WordPress: System-Temp Ordner nur mehr mit chmod 777 verwendbar

    in German / Deutsch

    Posted

    Habs versucht mit open_basedir wegnehmen. Auch die php-Konfig vom funktionierenden Host genommen, auch alle von mir gedachten problematischen Werte sind wie vom funktionierenden Host.

    Nope. Geht nicht.

    Ich bin mir da nicht ganz sicher, aber: wenn ich einen Kunden lösche, verschwinden nicht die Ordner im Verzeichnis "customers", richtig? Die müsste ich manuell entfernen.
    Kann es sein - da ich den Kunden gelöscht und wieder unter dem gleichen Username angelegt habe - dass die noch existierenden Ordner da eine korrekte Verbindung verhindern?

    WordPress: System-Temp Ordner nur mehr mit chmod 777 verwendbar

    in German / Deutsch

    Posted

    Hallo d00p!

    Danke für die wie immer prompte Antwort! 770 hat leider auch nicht geholfen.

    Ich habe die Berechtigungen wieder auf 750 gesetzt, im Error-Log username-error.log - als WordPress greift unter dem angelegten Kunden-Username zu (scheint so) - steht folgendes:

    proxy_fcgi:error] [pid 28270:tid 140380049725184] [client xxx.xxx.xxx.xxx:61211] AH01071: Got error 'PHP message: PHP Warning:  Unknown: Unable to create temporary file, Check permissions in temporary files directory. in Unknown on line 0PHP message: PHP Warning:  Unknown: POST data can't be buffered; all data discarded in Unknown on line 0PHP message: PHP Warning:  array_key_exists() expects parameter 2 to be array, null given in /var/customers/webs/username/wp-includes/rest-api/class-wp-rest-request.php on line 412PHP message: PHP Warning:  array_key_exists() expects parameter 2 to be array, null given in /var/customers/webs/username/wp-includes/rest-api/class-wp-rest-request.php on line 412', referer: http://username.domain.com/wp-admin/post.php?post=5&action=edit

     

    vHost-Datei vom nicht funktionierenden Host: 

    # 35_froxlor_normal_vhost_username.domain.com.conf
# Created 09.06.2020 16:28
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

# Domain ID: 16 - CustomerID: 8 - CustomerLogin: username
<VirtualHost [Server-IP]:80>
  ServerName username.domain.com
  ServerAlias *.username.domain.com
  ServerAdmin chrisiwien@domain.com
  DocumentRoot "/var/customers/webs/username/"
  <FilesMatch \.(php)$>
  SetHandler proxy:unix:/var/lib/apache2/fastcgi/1-username-username.domain.com-php-fpm.socket|fcgi://localhost
  </FilesMatch>
  <Directory "/var/customers/webs/username/">
    CGIPassAuth On
    Require all granted
    AllowOverride All
  </Directory>
  LogLevel warn
  ErrorLog "/var/customers/logs/username-error.log"
  CustomLog "/var/customers/logs/username-access.log" combined
</VirtualHost>

    vHost-Datei von einem anderen, mit Temp-Ordner auf 750, funktionierenden Host: 

    # 35_froxlor_normal_vhost_username2.domain.com.conf
# Created 09.06.2020 16:28
# Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel.

# Domain ID: 3 - CustomerID: 2 - CustomerLogin: username2
<VirtualHost [Server-IP]:80>
  ServerName username2.domain.com
  ServerAlias *.username2.domain.com
  ServerAdmin chrisiwien@domain.com
  DocumentRoot "/var/customers/webs/username2/"
  <FilesMatch \.(php)$>
  SetHandler proxy:unix:/var/lib/apache2/fastcgi/1-username2-username2.domain.com-php-fpm.socket|fcgi://localhost
  </FilesMatch>
  <Directory "/var/customers/webs/username2/">
    Require all granted
    AllowOverride All
  </Directory>
  Alias /webalizer "/var/customers/webs/username2/webalizer/username2.domain.com"
  LogLevel warn
  ErrorLog "/var/customers/logs/username2-username2.domain.com-error.log"
  CustomLog "/var/customers/logs/username2-username2.domain.com-access.log" combined
LogLevel debug
</VirtualHost>

     

    In der Folge die php-fpm pool-Dateien, einmal vom funktionierenden, einmal vom nicht funktionierenden vHost. Um das ganze ev. abzukürzen, die Unterschiede die mir beim nicht funktionierenden Host aufgefallen sind:

    php_admin_flag[allow_url_fopen] = Off
    php_admin_value[open_basedir] = "/var/customers/webs/dcamp:/var/customers/tmp/dcamp:/usr/share/php:/usr/share/php5:/tmp" (open_basdir Wert ist definiert, bei der funktionierenden pool-Konfiguration nicht)
    php_admin_value[post_max_size] = 16M (im Vergleich 256M bei der funktionierenden pool-Konfiguration. Mir ist auch aufgefallen, dass NUR bei sehr komplexen Gutenberg-Posts, also mit vielen Blöcken, Änderungen nicht gespeichert werden. Wie selbst die großen Gutenberg-Posts 16M haben sollen ist mir aber ein Rätsel. Sollte ja nur Text sein.)
     

    php-fpm pool-Datei, nicht funktionierender Host: 

    ;PHP-FPM configuration for "username.domain.com" created on 2020.06.09 16:28:44
[username.domain.com]
listen = /var/lib/apache2/fastcgi/1-username-username.domain.com-php-fpm.socket
listen.owner = username
listen.group = username
listen.mode = 0660
user = username
group = username
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 0
;chroot = /var/customers/webs/username/
security.limit_extensions = .php
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /var/customers/tmp/username/
env[TMPDIR] = /var/customers/tmp/username/
env[TEMP] = /var/customers/tmp/username/
php_admin_value[session.save_path] = /var/customers/tmp/username/
php_admin_value[upload_tmp_dir] = /var/customers/tmp/username/


php_admin_flag[allow_call_time_pass_reference] = Off
php_admin_flag[allow_url_fopen] = Off
php_flag[asp_tags] = Off
php_admin_value[disable_classes] = 
php_admin_value[disable_functions] = curl_multi_exec,exec,parse_ini_file,passthru,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,system
php_flag[display_errors] = On
php_flag[display_startup_errors] = Off
php_admin_flag[enable_dl] = Off
php_value[error_reporting] = E_ALL & ~E_NOTICE
php_admin_flag[expose_php] = Off
php_admin_flag[file_uploads] = On
php_admin_flag[cgi.force_redirect] = 1
php_admin_value[gpc_order] = "GPC"
php_flag[html_errors] = Off
php_admin_flag[ignore_repeated_errors] = Off
php_admin_flag[ignore_repeated_source] = Off
php_value[include_path] = ".:/usr/share/php/:/usr/share/php5/"
php_flag[log_errors] = On
php_admin_flag[log_errors] = On
php_value[log_errors_max_len] = 1024
php_flag[magic_quotes_gpc] = Off
php_flag[magic_quotes_runtime] = Off
php_flag[magic_quotes_sybase] = Off
php_value[max_execution_time] = 300
php_admin_value[max_input_time] = 1000
php_admin_value[memory_limit] = 256M
php_admin_value[open_basedir] = "/var/customers/webs/username:/var/customers/tmp/username:/usr/share/php:/usr/share/php5:/tmp"
php_admin_value[output_buffering] = 4096
php_admin_value[post_max_size] = 16M
php_admin_value[precision] = 14
php_admin_flag[register_argc_argv] = Off
php_admin_flag[report_memleaks] = On
php_admin_value[sendmail_path] = "/usr/sbin/sendmail -t -i -f chrisiwien@domain.com"
php_value[session.auto_start] = 0
php_value[session.cookie_domain] = 
php_value[session.cookie_lifetime] = 0
php_value[session.cookie_path] = /
php_admin_value[session.gc_divisor] = 1000
php_admin_value[session.gc_probability] = 1
php_value[session.name] = PHPSESSID
php_value[session.serialize_handler] = php
php_flag[session.use_cookies] = 1
php_flag[short_open_tag] = On
php_flag[suhosin.simulation] = Off
php_flag[track_errors] = Off
php_value[upload_max_filesize] = 32M
php_admin_value[variables_order] = "GPCS"
php_admin_value[opcache.restrict_api] = "/var/customers/webs/username/"

     

    php-fpm pool-Datei, funktionierender Host: 

    ;PHP-FPM configuration for "username2.domain.com" created on 2020.06.09 16:28:44
[username2.domain.com]
listen = /var/lib/apache2/fastcgi/1-username2-username2.domain.com-php-fpm.socket
listen.owner = username2
listen.group = username2
listen.mode = 0660
user = username2
group = username2
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 0
;chroot = /var/customers/webs/username2/
security.limit_extensions = .php
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /var/customers/tmp/username2/
env[TMPDIR] = /var/customers/tmp/username2/
env[TEMP] = /var/customers/tmp/username2/
php_admin_value[session.save_path] = /var/customers/tmp/username2/
php_admin_value[upload_tmp_dir] = /var/customers/tmp/username2/


php_admin_flag[allow_call_time_pass_reference] = Off
php_admin_flag[allow_url_fopen] = On
php_flag[asp_tags] = Off
php_admin_value[disable_classes] = 
php_admin_value[disable_functions] = curl_multi_exec,exec,parse_ini_file,passthru,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,show_source,system
php_flag[display_errors] = Off
php_flag[display_startup_errors] = Off
php_admin_flag[enable_dl] = Off
php_value[error_reporting] = E_ALL & ~E_NOTICE
php_admin_flag[expose_php] = Off
php_admin_flag[file_uploads] = On
php_admin_flag[cgi.force_redirect] = 1
php_admin_value[gpc_order] = "GPC"
php_flag[html_errors] = Off
php_admin_flag[ignore_repeated_errors] = Off
php_admin_flag[ignore_repeated_source] = Off
php_value[include_path] = ".:/usr/share/php/:/usr/share/php5/"
php_flag[log_errors] = On
php_admin_flag[log_errors] = On
php_value[log_errors_max_len] = 1024
php_flag[magic_quotes_gpc] = Off
php_flag[magic_quotes_runtime] = Off
php_flag[magic_quotes_sybase] = Off
php_value[max_execution_time] = 60
php_admin_value[max_input_time] = 60
php_admin_value[memory_limit] = 256M
php_admin_value[output_buffering] = 4096
php_admin_value[post_max_size] = 256M
php_admin_value[precision] = 14
php_admin_flag[register_argc_argv] = Off
php_admin_flag[report_memleaks] = On
php_admin_value[sendmail_path] = "/usr/sbin/sendmail -t -i -f chrisiwien@domain.com"
php_value[session.auto_start] = 0
php_value[session.cookie_domain] = 
php_value[session.cookie_lifetime] = 0
php_value[session.cookie_path] = /
php_admin_value[session.gc_divisor] = 1000
php_admin_value[session.gc_probability] = 1
php_value[session.name] = PHPSESSID
php_value[session.serialize_handler] = php
php_flag[session.use_cookies] = 1
php_flag[short_open_tag] = On
php_flag[suhosin.simulation] = Off
php_flag[track_errors] = Off
php_value[upload_max_filesize] = 256M
php_admin_value[variables_order] = "GPCS"
php_admin_value[opcache.restrict_api] = ""

     

     

     

     

     


     

    WordPress: System-Temp Ordner nur mehr mit chmod 777 verwendbar

    in German / Deutsch

    Posted

    Hallo!

    Meine Server/Froxlor-Installation unter Debian 9 mit Apache 2.4 und PHP-FPM 7.3 läuft grundsätzlich sehr gut, wenn ich einen neuen Kunden einrichte, dazu eine Domain und eine Datenbank klappt bisher alles prima.

    Ich stehe nun bei einer neuen WordPress-Installation vor dem Problem, dass der System-Temp Ordner (var/customers/tmp/username) nur mit chmod 777 funktioniert, das ist natürlich suboptimal... bei den anderen funktionierenden Installationen hat der jeweilige Temp-Ordner die Berechtigung 750 und alles klappt.

    Bisher habe ich eine neue Website strikt nach dieser Abfolge angelegt:

    1. Kunde/Benutzername einrichten
    2. Datenbank einrichten
    3. Domain einrichten und dem Benutzer zuweisen

    Beim letzten Mal habe ich unter Zeitdruck die Schritte vertauscht, und nach Nicht-Funktionieren den Kunden und die Domain wieder gelöscht und nochmals angelegt. Scheint so dass sich Froxlor "verschluckt" hat...

    Woran kann das liegen dass der System-Temp Ordner nur mehr mit chmod 777 funktioniert? Wie kann ich das ändern? Die vHost-Settings und die php-fpm pool Konfiguration entsprechen den anderen Installationen.

    Der System-Temp Ordner ist für die Funktionalität von WordPress entscheidend, z.B. Mediaupload, Speichern von Gutenberg-Posts...

    Froxlor-Version ist 0.10.15-1 (DB: 202002290)

     

    Grüße aus Wien

     

    503 Service Unavailable mit PHP-FPM 7.3

    in General Discussion

    Posted

    Ok! Danke für Deine Antworten! Super Hilfestellung!

    Zusatz: nach enablen der php7.3-fpm.conf rennen die beiden Webseiten gefühlt schneller? (Noch vor der FPM-Werteumstellung) Hat ev. doch einen Einfluss??

    Die Gaudi fängt erst an, da ich auf nginx umstellen werden. Keine Panik, habe ich gestern bei einem anderen RootServer gemacht.

    Und ich liebe nginx bisher - die strukturierten Config-Dateien haben im Vergleich zu Apache auf alle Fälle die Nase vorn!

×
×
  • Create New...