Nein, anscheinend is dem nicht so.
Im File /home/kunde/bin/php wird explizit mit -c das php.ini file /home/kunde/php.ini angegeben.
Wenn ich z.B. die /usr/local/pd-admin2/php-8.3.17/bin/php-cli direkt mit --ini aufrufe, sehe ich dass die php.ini der jeweiligen Version im Insstallationsverzeichnis verwendet wird (/usr/local/pd-admin2/php-8.3/lib/php.ini)
Super!
somit wird auf der Shell und von crontab auch die richtige php.ini verwendet!
so scheint jetzt alles zu funktionieren!
vielen Dank
Ich bin mir da nicht sicher. Ich muss nach jedem Update in den Cronjobs die Pfade ändern, da nach einem php Update die verwendeten Pfade nicht mehr stimmen.
z.B. vor Update /usr/local/pd-admin2/php-8.3.15/bin/php und nach dem Update /usr/local/pd-admin2/php-8.3.17/bin/php
Deshalb bin ich mir auch nicht sicher, welche php.ini wann verwendet wird.
Schade dass es zu diesem Thema keine Doku gibt.
Hallo,
ich versuche jetzt seit einer gefühlten Ewigkeit vergeblich das redis Modul für eine nextcloud installation zu laden.
Ich habe es in der php.ini über den php.ini-Editor auf der Weboberfläche den Eintrag "extension=redis.so" hinzugefügt und das Modul mittels "/usr/local/pd-admin2/php-8.3.17/bin/pecl install redis" installiert.
Leider bekomme ich z.B. beim Ausführen des nextcloud Cronjobs den Fehler "Memcache OC\Memcache\Redis not available for local cache (Is the matching PHP module installed and enabled?)"
Ich verstehe nicht warum - mache ich etwas falsch?
Danke für eure Hilfe!
Es sieht so aus, als hätte diese Funktion schon mal funktioniert.
In einigen Verzeichnissen gibt es die .htusers und .htaccess
Ach soooo. ich dachte es gibt dafür ein eigenes Menü!
vielen Dank!!! udn Sorry für die lange Leitung!
Vielen Dank für die Beschreibung!
Leider stehe ich etwas auf der Leitung...
Wo finde ich diese awstats und webalizer Verzeichnise in der pd-admin Weboberfläche?
Hallo,
hätte noch jemand eine Idee, wie ich das jetzt am besten umsetze in pdadmin Konform zu sein?
Wird daran für die Zukunft etwas geändert?
vielen Dank
Wie sollten die Verzeichnisse geschüzt werden? mit einer .htaccess?
Diese Frage hat sich erledigt...
Hallo,
ich habe leider mit erschrecken festgestellt, dass all meine awstats und usage2 von all meinen Subdomains ohne Passwort zugänging sind.
In der pdadmin.conf stehen protect_awstats und protect_usage seit der Installation auf 1.
Es ist aber weder für bestehende Subdomains eine Kennwortabfrage aktiv noch wird bei neu erstellten Subdomains eine eingerichtet.
Im Forum finde ich nur einen Beitrag von 2004 - laut diesem sollte eigentlich alles richtig sein.
Ich hoffe jemand kann mir auf die Sprünge helfen und mir sagen, woran das liegen kann bzw. was ich machen kann.
Mir wäre natürlich die std. Vorgehensweise von pd-admin am liebsten - eine manuelle Absicherung mittels .htaccess gefällt mir nicht so gut.
Danke schon mal für eure Hilfe! Ach ja ich verwende die aktuellsten Versionen (SE 0.458 pd-admin v4.129)
Nach einer manuellen Bearbeitung der mysql Benutzer direkt über mysql konnt das Upgrade auf Reihe 7 erfolgreich durchgeführt werden.
Folgendes musst vor dem Upgrade durchgeführt werden:
update user set authentication_string = password;Und dies musst nach dem Upgrade noch durchgeführt werden:
set password for 'root'@'::1'=password('XXXXXXXXXXXX');
delete from global_priv where User = 'builduser';
delete from global_priv where User = '';
flush privileges;Nach einer endlich erfolgreichen Umstellung von Reihe 7 auf Reihe 9 ist nur noch TLSv1.2 und 1.3 verfügbar.
Wei gesagt, wenn ich ein upgrade mache ohne voherige manuelle Änderungen, an der mysql.user Tabelle, funktioneirt es nicht - es fehlen Passwörter in der neuen mysql.global_priv Tabelle.
Wenn ich vor dem Upgrade alle Passwörter in der mysql.user von der Spalte password in die Spalte authentication_string übertrage, sind nach dem Upgrade alle wichtigen Passwörter in der mysql.global_priv OK.
Ausnahmen sind folgende User
Für mich ist dieses Vorgehen jetzt OK - ich warte auf das nächste SE Update - wenn die Installation positiv verläuft, mach ich das upgrade am produktiv Server.
Folgende Punkte kommen mir aber strange vor - sollten sich angesehen werden - ob wirklich alles korrekt ist.
Nein es lag / liegt nirgends eine andere Version der mysql_privileges.pl am System.
Hbs erneut versucht - ich denke das Problem liegt an der unvolständigen mysql.user im aktuellen System.
Dort fehlen ja in der Spalte aufhentication_sting schon diese Passwörter - in der Spalte password sind sie aber vorhanden.
Woran kann das liegen - es betrifft sogar 2 User die kuz nacheinander über das selbe Vorgehen angelegt wurden (im customer frontend) - einer hat einen authetication_string der andere nicht.
Wenn ich vor dem Update die authentication_string's in der mysql.user korrigiere - sind sie auch nach dem Update korret gesetzt.
Hab jetzt erneut ein sauberes Upgrade mittels "mysql_uprade.sh 9" durchgeführt.
Leider habe ich jetzt bemerkt, dass das für den roundcubemail User und einen anderen mysqluser wieder kein Password gesetzt ist.
Kann es sein, dass in diesem Upgradescript mysql_uprade.sh die Anpassung von Hr. Bradler nicht drin ist?
OK, das bringt ja mal massig Licht ins Dunkel! Danke!
In der mysql_user.yaml sind alle password strings richtig enthalten!
Der root benutzer mit dem falschen Kennwort ist der für ipv6 - hab ich jetzt geändert.
Dann werd ich jetzt nochmal meinen Testserver auf diese Weise upgraden und gehe davon aus, dass einem Upgrade meines Produktiv Servers nichts im Wege steht...
Sumeragi - vielen Dank für deine Mühe!
Gut zu wissen, dass diese "cannot move" Fehler kein Problem sein müssen.
Auf welche Art hat du denn das Upgrade durchgeführt?
Ich habe es jetzt noch mal mit dem "mysql_upgrade.sh 9" versucht.
Wenn ich die "cannot move", "cannot access", "ln: failed" Fehler ignoriere, kommt es nach dem Starten der Dienste zu folgenden Fehlern:
/service/qmail-smtpSd/log
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Konnte auch nach 60 Sekunden nicht mit der MySQL-Datenbank verbinden.
DBI connect('database=vadmin;host=localhost;','vadmin',...) failed: Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2) at /opt/pdadmin/bin/httpd_vhosts.pl line 70
can't connect! at /opt/pdadmin/bin/httpd_vhosts.pl line 70.
|
| MySQL fix privileges/MySQL shutdown/restart (MySQL 4.1/5.0)
| mysql_upgrade (MySQL 5.1)
|
skipping mysql_fix_privilege_tables (MySQL 4.0/5.0)
skipping mysql_upgrade (MySQL 5.1)
|
| mysqlcheck --all-databases --repair
|
/usr/local/pd-admin2/bin/mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2) when trying to connect
mysqld: no process found
---------------------------------
| ROUNDCUBEMAIL wird upgegradet.
|
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2)
|
| phpMyAdmin < 4.8.4 and phpPgAdmin no longer available, use $hostname/adminer
|
|
| DKIM activated
|
|
| timezone-Daten werden in MySQL registriert, falls erforderlich
|
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Konnte auch nach 60 Sekunden nicht mit der MySQL-Datenbank verbinden.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2)
trying to install time zone data from /usr/share/zoneinfo
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2)
|
| se-update.sh doneWenn ich mich mit dem mysql Client "/usr/local/pd-admin2/bin/mysql" verbinde, benötige ich kein root Passwort und die tabelle mysql.user sieht auch nicht richtig aus!
* bei root@localhost und root@127.0.0.1 unterscheiden sich die Passwörter
* es gibt einen zusätzlichen User mariadb.sys ohne Password
* ein weiterer neuer User builduser hat in password und authentication_string "invalid" stehen
Mit dem User vadmin und dem roundcubmail User kann ich mich mit dem richtigen Passwort anmelden
Auf die Webfrontends customer, administrator, roundcubemail und phpmyadmin kann ich mich aber verbinden.
Ist das Upgrade jetzt OK und kann ich alle Fehler ignorieren oder laufe ich gefahr, dass beim nächsten se Update nichts funktioniert?
Im mysql_user.yaml file sind jetzt alle Passwörter vorhanden.
Nach dem Import stehen in der spalte password alle Passwörter drin, in der Spalte authentication_sting ist alles leer - weiß nicht ob das richtig ist.
Leider funktioniert das Update noch immer nicht.
Es scheiter nach wie vor beim Bereich cannot move....:
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition_type.frm.pdu-*
(2) MYSQLDATADIR = </home/mysql>
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/columns_priv.frm' to '/home/mysql/mysql/': No such file or directoryHab jetzt auch noch versucht das "manuelle" Update versucht. Vorher hab ich natürlich die Passwörter im mysql richtig gestellt (Spalte password und authentication_string gleich)
Der Import der Privilegien (mysql_privileges.pl import_data) scheitert mit zugriff verweigert.
Nach dem manuellen setzten des root Passworts klappt es.
Die Ausgabe von "select host,user,password,authentication_string from mysql.user;" irritiert mich aber.
In der Spalte authentication_string passen die Passwörter in der Spalte password steht abgesehen vom Benutzer root überall derselbe Wert - keiner aus dem Exportfile!
Ich denke ich habe die Ursache für die "fehlenden" Passwörter im exportfile mysql_user.yaml gefunden.
In der Tabelle mysql.user gibt es die Spalte password und die Spalte authentication_string.
In der Spalte password sind alle Kennwörter vorhanden - in der Spalte authentication_string fehlen ein paar und offensichtlich werden beim Export die Kennwöter aus der Spalte authentication_string verwendet.
Warum die Fehlen, verstehe ich nicht - es gibt sogar 2 Benutzer die von kurzem auf dieselbe Art (Customer - Datenbanken - Datenbankkonten - Neues Konto) eingerichtet wurden - bei einem ist die Spalte authentication_string leer beim andern steht derselbe Strin wie in der Spalte password - Komisch!
Nachdem ich das korrigiert habe sind alle Kennwörter im Exportfile vorhanden.
Leider scheitert das Upgrade über das Script "/mysql_upgrade.sh 9" trotzdem noch.
Bis zum Bereich "Entferne einige .pdu-Dateien ..." scheint noch alles zu passen. Beim Verschieben von /usr/local/pd-admin2/var/mysql/mysql/columns_priv.frm nach /home/mysql/mysql/ kommt wieder No such file or directory...
Arbeitsverzeichnis wird gelöscht ...Fertig
|
| Entferne einige .pdu-Dateien ...
|
/usr/local/pd-admin2/var/mysql/mysql/db.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/db.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/user.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/user.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/tables_priv.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/tables_priv.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/func.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/func.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/host.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/host.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/columns_priv.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/columns_priv.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_leap_seconds.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_leap_seconds.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_name.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_name.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition_type.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition_type.frm.pdu-*
(2) MYSQLDATADIR = </home/mysql>
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/columns_priv.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/columns_priv.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/columns_priv.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/column_stats.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/column_stats.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/column_stats.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.opt' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/event.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/event.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/event.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/func.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/func.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/func.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/general_log.CSM' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/general_log.CSV' to '/home/mysql/mysql/': No such file or directory