Also das Skript "mysql_upgrade.sh" funktioniert nicht, man kann anschliessend den Webserver wegwerfen.
Es sei denn, man hat Expertenwissen und kennt sich mit den Interna der SE und pd-admin aus. Das habe ich leider nicht.
Schade, das mir hier keiner weiterhilft, für mich ist das eine Sackgasse.
Ich versuche jetzt seit zwei Tagen meine Nextcloud auf eine neuere Version zu heben, bei der nun einmal MySQL 8.x oder MariaDB 10.x vorausgesetzt wird.
Ich komme so jedenfalls nicht weiter.
Ich erhalte beim Ausführen des aktuellen Skriptes "mysql_upgrade.sh" ganz am Ende eine Fehlermeldung:
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'password('xxxx')' at line 1
Ich habe vorher in der my.cnf die Anweisung für die (alten) native passwords gesetzt:
[mysqld]
default-authentication-plugin=mysql_native_passwordNatürlich mit der Hoffnung, dass er dann bei MySQL 8 auch mit dem bisherigen mysql root password weiterarbeiten kann.
Momentan schieße ich mir mit dem Skript aber wunderbar den MySQL Server ab.
Das mit dem User entfernen aus "mysql_user.yaml" verstehe ich nicht, wann muss ich das machen?
Ich habe auch schon versucht, das Passwort für den root@localhost neu zu setzen, anchdem ich MySQL 8 mit der Hand ohne Passwort starten konnte.
Er merkt sich das nur nicht, nach einem Reboot ist das PW weg.
Was kann / sollte ich tun, damit ich von MySQL 5.7 auf MySQL 8 oder MariaDB upgraden kann?
Gruß,
Philipp
Blöde Frage:
wo genau muss ich die httpd.conf ändern (welches Verzeichnis?), damit das nicht laufend überschrieben wird?
Wie ist denn der Mechanismus mit dem Template, das dazu verwendet wird, die httpd.conf zu bauen?
Wenn ich den RedirectMatch auskommentiere und den Alias wie oben angegeben reinkopiere, dann erhalte ich jetzt : "Too many failed authorizations recently". Es scheint also zu gehen.
Wie kann ich das Konto bei LE zurücksetzen?
Stattdessen steht da:
für Port 80
ServerName admin20.xxxxxx.de
RedirectMatch ^(?!/.well-known/acme-challenge).* https://admin20.xxxxxx.de$0
Beim Port 443 steht der Alias wie oben angegeben drin.
Auszug aus /var/log/letsencrypt/letsencrypt.log von heute:
2021-10-18 12:23:31,157:WARNING:certbot._internal.auth_handler:Challenge failed for domain admin20.xxxxxxxx.de
2021-10-18 12:23:31,157:INFO:certbot._internal.auth_handler:http-01 challenge for admin20.xxxxxxxx.de
2021-10-18 12:23:31,158:DEBUG:certbot._internal.reporter:Reporting to user: The following errors were reported by the server:
Domain: admin20.xxxxxxxx.de
Type: unauthorized
Detail: Invalid response from http://admin20.xxxxxxxx.de/.we…me-challenge/HPKYtxxxxxxx [2x3.1x2.1x8.1x1]:
"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"
To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
2021-10-18 12:23:31,160:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 91, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File "/opt/eff.org/certbot/venv/lib/python2.7/site-packages/certbot/_internal/auth_handler.py", line 180, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
AuthorizationError: Some challenges have failed.
Hallo,
danke für den Hinweis. Das läuft bei mir auf einen Fehler, dass er das Challenge nicht ablegen kann unter http://servername.domain.tld/.well-known/acme-challenge/xxxxxxx
Die Domäne stimmt, die public IP stimmt, das Verzeichnis existiert.
Hallo,
wie kann ich denn bei bestehenden Installationen, die auf die neueren Versionen der SE aktualisiert wurden, nachträglich ein Let's encrypt Zertifikat für den Servernamen erzeugen, anlegen und aktivieren?
Gruß,
Philipp
Ah, ok, danke für die Tipps!
Gruß,
Philipp
Hallo,
ich hatte jetzt wieder einmal das Vergnügen, einen pdadmin-Server auf eine neue IP-Adresse und einen neuen Hostnamen umzuziehen.
Der Punkt 5.4 unter dem bereists genannten Link https://www.pdadmin-forum.de/thread.php?threadid=3308 ist hier sehr hilfreich.
Allerdings habe ich den Eindruck, dass Werte aus pdadmin.conf nicht so übernommen werden, wie man das erwarten würde.
Für mich wäre es logisch, dort die IP-Adresse und den Hostnamen anzupassen, httpd_vhosts.pl auszuführen, die ganze VM neu zu starten und fertig.
Aber aus irgendeinem Grund wird die httpd.conf ständig in Zyklen mit den alten Werten wieder überschrieben.
Gehe ich jetzt schnell in die hostname/administrator GUI und aktualisiere den Servernamen auch dort, schaffe ich es eventuell noch bis ins Kundenmenü, um dort auch die IP zu aktualisieren, aber dann ist mesit schon wieder die httpd.conf überschrieben.
Wie mache ich das richtig? Welche Schritte sind hier notwendig?
Gruß,
Philipp
Wir haben unseren pdadmin auch hinter einer Firewall stehen, die NAT macht.
Ich würde mich über eine Lösung auch freuen.
OK, mein Fehler, ich dachte er hat den Server "on premise" in der Firma stehen!
Aber das Prinzip ist ja dasselbe: wenn er einen anderen Provider als DNS-Provider nimmt, dann muss er dort die forward-DNS Einträge pflegen und beim Hoster des physischen Servers die reverse Einträge. Also dort, wo die IP-Adressen des Hosting-Netzwerkes "am Server anstehen".
Mit freundlichem Gruß,
Philipp
Hallo,
ich kenne das so, dass man den reverse DNS nur beim Leitungsanbieter eintragen kann, dem ja dieser IP-Kreis gehört.
Also, wenn ich einen Anschluß von Unitymedia habe, aber mein Server z.B. bei Strato steht, dann kann ich bei Strato zware den forward-DNS Eintrag vornehmen, das wäre der A-Record und der MX-Record für dem Mailserver, vielleicht noch einem CNAME usw.
Aber die RDNS-Einträge müsste ich in meinem Beispiel bei Unitymedia einstellen, das geht nicht über Strato.
Ich hoffe, das hilft dir.
Mit freundlichem Gruß,
Philipp
Mit der neuesten SE müsstest du bei 7.3.11 sein.
Gruß,
Philipp
Danke! Oh Mann, ich hab den falschen Apache konfiguriert !!!
Klar, der Apache 2.4 hat ja das andere Konfigurations-Verzeichnis, wie dämlich von mir...
Aktuelle Info für CentOS 7-1908 mit PHP 7.3.11, also pd-admin 4.62 mit SE 0.342
Ich habe ganz offiziell mit yum install nachinstaliert, um das LDAP-Modul für PHP zu erhalten:
yum install epel-release (falls noch nicht installiert)
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
yum --enablerepo=remi-php73 install php-ldap (es gibt auch die beiden Vorgänger-Versionen remi-php72 und remi-php71, wer das benötigt)
Die neu installierten Dateien liegen dann unter /usr/lib64/php/modules, von dort kann man einen Link setzen oder man kopiert ldap.so in das entsprechende Verzeichnis der SE.
In meinem Fall mit PHP 7.3.11 ist das /usr/lib/pd-admin2/php-7.3.11/lib/php/extensions/no-debug-non-zts-20180731
Hinweis: es gibt noch ein weiteres Verzeichnis /usr/lib64/php-zts/modules/..., diese funktionieren NICHT mit der SE von pd-admin.
Gruß,
Philipp
Aktuelle Info für CentOS 7-1908 mit PHP 7.3.11, also pd-admin 4.62 mit SE 0.342
Ich habe ganz offiziell mit yum install nachinstaliert, um das LDAP-Modul für PHP zu erhalten:
yum install epel-release (falls noch nicht installiert)
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
yum --enablerepo=remi-php73 install php-ldap (es gibt auch die beiden Vorgänger-Versionen remi-php72 und remi-php71, wer das benötigt)
Die neu installierten Dateien liegen dann unter /usr/lib64/php/modules, von dort kann man einen Link setzen oder man kopiert ldap.so in das entsprechende Verzeichnis der SE.
In meinem Fall mit PHP 7.3.11 ist das /usr/lib/pd-admin2/php-7.3.11/lib/php/extensions/no-debug-non-zts-20180731
Hinweis: es gibt noch ein weiteres Verzeichnis /usr/lib64/php-zts/modules/..., diese funktionieren NICHT mit der SE von pd-admin.
Gruß,
Philipp
Wie schalte ich den prefork ab?
In meiner httpd.conf und auch in der httpd.conf-template Datei finde ich keinen entsprechenden "LoadModule" Eintrag
Gruß,
Philipp
Es ist ein Bug in der Password-hash Funktion in PHP. Bei der nextcloud Installation über den Webinstaller hilft ein Workaround, den ich auf Anfrage gerne poste. (Wie bei Browsingman erwähnt muss die Hasher.php von nextcloud während der Installation modifiziert werden.)
Die anderen Fragen bzw. Probleme von mir in Bezug auf die PHP-Module können mit hilfe einer kunden-spezifischen php.ini wie folgt gelöst werden:
Das Ganze läuft bei mir unter PHP 7.3.11 problemlos.
Module erstmal laden:
[PHP]
extension_dir=""
zend_extension=opcache.so
extension=apcu.so
;extension=memcached.so (brauchen wir nicht, dafür nehmen wir redis, ist aber eine brauchbare Alternative))
extension=soap.so
extension=imagick.so
extension=intl.so
extension=redis.so
Opcache-Modul konfigurieren:
[opcache]
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
APCu-Cache Modul konfigurieren
[APCu]
apc.enable_cli=1
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
Für APCu und Redis sind dann noch Einstellungen in der config.php von Nextcloud anzupassen.
Gruß,
Philipp
Ja, du hast recht: extension_dir="" alleine ist ausreichend.
Danke dir.
Gruß,
Philipp