[gelöst] ISPC legt Datenbanken nicht an

DarkTrinity

Member
Hallo liebe Comuunuty,

mein ISPC ist frisch installiert aber die Datenbanken und DatenbankUser, die ich in ISPC anlege, werden nicht erstellt. Das sehe ich zB in phpmyadmin oder an der Fehlermeldung einer scheiternden Joomla Installation.

Aus der log geht in meinen Augen nichts brauchbares hervor:
Code:
2022-01-16 10:04:29 0 [Note] InnoDB: Using Linux native AIO
2022-01-16 10:04:29 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-01-16 10:04:29 0 [Note] InnoDB: Uses event mutexes
2022-01-16 10:04:29 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-01-16 10:04:29 0 [Note] InnoDB: Number of pools: 1
2022-01-16 10:04:29 0 [Note] InnoDB: Using SSE2 crc32 instructions
2022-01-16 10:04:29 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2022-01-16 10:04:29 0 [Note] InnoDB: Completed initialization of buffer pool
2022-01-16 10:04:29 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2022-01-16 10:04:29 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=358773676
2022-01-16 10:04:29 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2022-01-16 10:04:29 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-01-16 10:04:29 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-01-16 10:04:29 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-01-16 10:04:29 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-01-16 10:04:29 0 [Note] InnoDB: Waiting for purge to start
2022-01-16 10:04:30 0 [Note] InnoDB: 10.3.32 started; log sequence number 358773685; transaction id 561590
2022-01-16 10:04:30 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2022-01-16 10:04:30 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-01-16 10:04:30 0 [Note] Recovering after a crash using tc.log
2022-01-16 10:04:30 0 [Note] Starting crash recovery...
2022-01-16 10:04:30 0 [Note] Crash recovery finished.
2022-01-16 10:04:30 0 [Note] Server socket created on IP: '::'.
2022-01-16 10:04:30 0 [Note] Reading of all Master_info entries succeeded
2022-01-16 10:04:30 0 [Note] Added new Master_info '' to hash table
2022-01-16 10:04:30 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.3.32-MariaDB-0ubuntu0.20.04.1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 20.04
2022-01-16 10:04:30 0 [Note] InnoDB: Buffer pool(s) load completed at 220116 10:04:30
2022-01-16 12:18:41 6356 [Warning] IP address '35.198.64.248' has been resolved to the host name '248.64.198.35.bc.googleusercontent.com', which resembles IPv4-address itself.
2022-01-16 12:28:34 6588 [Warning] Host name 'massey.6003333333.okr' could not be resolved: Name or service not known
2022-01-16 15:24:01 12656 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 15:24:01 12657 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 15:25:01 12710 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 15:25:01 12711 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 15:25:02 12714 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 15:25:04 12717 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 15:25:07 12720 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 15:25:11 12723 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 16:21:47 15312 [Warning] Access denied for user 'joomlaDB'@'localhost' (using password: YES)
2022-01-16 16:21:47 15313 [Warning] Access denied for user 'joomlaDB'@'localhost' (using password: YES)
2022-01-16 16:22:13 15333 [Warning] Access denied for user 'joomlaDB'@'localhost' (using password: YES)
2022-01-16 16:22:13 15334 [Warning] Access denied for user 'joomlaDB'@'localhost' (using password: YES)
2022-01-16 16:27:01 15612 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 16:29:01 15753 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 16:29:01 15754 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 16:30:01 15870 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 16:30:01 15871 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
2022-01-16 16:32:33 16012 [Warning] Access denied for user 'joomlaDB'@'localhost' (using password: YES)
Ein mysql_upgrade -h localhost -u root -p ergab
Code:
This installation of MySQL is already upgraded to 10.3.32-MariaDB, use --force if you still need to run mysql_upg
rade
Systemctl status mysql ergibt:
Code:
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/mysql.service.d
             └─limits.conf
     Active: active (running) since Sun 2022-01-16 10:04:30 UTC; 6h ago
       Docs: man:mysqld(8)
             https://mariadb.com/kb/en/library/systemd/
   Main PID: 967 (mysqld)
     Status: "Taking your SQL requests now..."
      Tasks: 44 (limit: 14267)
     Memory: 172.0M
     CGroup: /system.slice/mariadb.service
             └─967 /usr/sbin/mysqld

Jan 16 10:04:28 hostname systemd[1]: Starting MariaDB 10.3.32 database server...

Jan 16 10:04:29 hostname mysqld[967]: 2022-01-16 10:04:29 0 [Note] /usr/sbin/mysqld (mysqld 10.3.32-MariaDB-0ubuntu0.20.04.1) starting as process 967 ...

Jan 16 10:04:30 hostname systemd[1]: Started MariaDB 10.3.32 database server.

Jan 16 10:04:30 hostname /etc/mysql/debian-start[1282]: Upgrading MySQL tables if necessary.

Jan 16 10:04:30 hostname /etc/mysql/debian-start[1293]: Looking for 'mysql' as: /usr/bin/mysql

Jan 16 10:04:30 hostname /etc/mysql/debian-start[1293]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck

Jan 16 10:04:30 hostname /etc/mysql/debian-start[1293]: This installation of MySQL is already upgraded to 10.3.32-MariaDB, use --force if you still need to run mysql_upgrade

Jan 16 10:04:30 hostname /etc/mysql/debian-start[1343]: Checking for insecure root accounts.

Jan 16 10:04:30 hostname /etc/mysql/debian-start[1350]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria tables
Was kann ich hier tun ?

Die letzte Änderung die ich vorgenommen habe war ein Update auf PHP8, aber habe die Defaultts wieder auf PHP 7.4 gesetzt:

Code:
root@host:/var/log# update-alternatives --config php
Es gibt 2 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad             Priorität Status
------------------------------------------------------------
  0            /usr/bin/php8.0   80        automatischer Modus
* 1            /usr/bin/php7.4   74        manueller Modus
  2            /usr/bin/php8.0   80        manueller Modus


root@host:/var/log# update-alternatives --config php-cgi
Es gibt 2 Auswahlmöglichkeiten für die Alternative php-cgi (welche /usr/bin/php-cgi bereitstellen).

  Auswahl      Pfad                 Priorität Status
------------------------------------------------------------
  0            /usr/bin/php-cgi8.0   80        automatischer Modus
* 1            /usr/bin/php-cgi7.4   74        manueller Modus
  2            /usr/bin/php-cgi8.0   80        manueller Modus
Im Monitoring von ISPC wird auch immer wieder bemängelt:
Unable to connect to mysqlAccess denied for user 'root'@'localhost' (using password: YES)

Wie fixe ich das ? Ich hab das eigentlich nur für phpMyAdmin verweigert - denn Root Login
 
Zuletzt bearbeitet:

Till

Administrator
Ich hab das eigentlich nur für phpMyAdmin verweigert - denn Root Login
Man kann root Login nicht nur für phpmyAdmin sperren. Du hast Damit mit Sicherheit auch den login für ISPConfig und alle anderen Anwendungen die sich per root in MySQL einloggen müssen gesperrt. Mach das mal Rückgängig, was Du da für die phpMyAdmin Sperre gemacht hast.
 

DarkTrinity

Member
Das habe ich bereits - brachte nix. Ich hatte aber eigentlich nur folgende Zeile in die
/etc/phpmyadmin/config.inc.php eingefügt:
Code:
$cfg['Servers'][$i]['AllowRoot'] = FALSE;
Die habe ich aber bereits auskommentiert, mysql, apache & php7.4-fpm als Dienste neu gestartet aber das Problem blieb beständig.

Den o.g. Handgriff hab eich auf einer Seite gelesen, die Tips gibt phpmyadmin abzusichern. Früher hatte ich das lediglich über eine .htaccess gemacht (Require valid-user)

Server neu gestartet - keine Änderung.

Vielleicht Authentifizierungs Plugin auf Unix Socket ändern (steht im Moment auf native)
 
Zuletzt bearbeitet:

Till

Administrator
Achso, ok. Ja das sperrt den in der tat nur in phpmyadmin. Ich hatte gedacht Du hast den Zugriff über dsa Netzwerk, den phpmyadmin benötigt, gesperrt. Hast Du vielleicht das MySQL root Passwort geändert und das neue Passwort nicht in ISPConfig in /usr/local/ispconfig7server/lib/mysql_clientdb.conf gesetzt?
 

DarkTrinity

Member
In dieser Datei steht das richtige Root PW. Es enthält allerdings ein
Code:
"
(also das PW). Ist das vielleicht das Problem ?

Die Fehlermeldung taucht übrigens nicht mehr in den Logs auf, wenn ich eine DB anlege - aber erzeugt wird diese DB leider immer noch nicht. Ich versuche der DB aber den gleichen Namen zu geben wie zuvor.

In der DB von ISPC sehe ich auch noch Einträge zu diesem user und der DB im table "web_database" (obwohl ich diese eigentlich gelöscht habe im ISPC Panel).

Vielleicht beeinflusst diese Zeile doch mehr als phpmyadmin:
$cfg['Servers'][$i]['AllowRoot'] = FALSE;

Diese ist ja immernoch auskommentiert. Keine Ahnung was passiert wenn ich jetzt die Einträge aus der isoc-DB per Hand entferne... ?
 
Zuletzt bearbeitet:

DarkTrinity

Member
Das ist möglich, änder das passwort mal in MySQL und in der Datei.
HAHA- wie cool. Jetzt klappt es. Es war wirklich das blöde Gänsefüsschen im PW. Obwohl ich mit diesem PW direkt in der SQL Konsole wunderbar arbeiten konnte. Aber es zickt wahrscheinlich in den PHP Codings von ISPC herum. Es wird ja auch benutzt um Strings zu definieren. Blöderweise war vor dem " auch noch ein \ (was das " kaskadieren würde in PHP).

Das PW fing also so an:
Code:
\"
Ich hatte das PW mit Keepass erzeugt, automatisch und möglichst komplex. Ein sehr dummer Zufall das alles ^^

VIELEN LIEBEN DANK, Till
 

matz

Member
Das trägt jetzt nichts zum Thema bei aber ich hatte mal mit pwgen ein ultra-kryptisches, langes Passwort für eine Postgres-Datenbank erstellt und das fing mit ! (Schreizeichen) an. Ich kam nicht an die Datenbank dran. Es hat dann über eine Stunde gedauert bis ich dahinter kam. Das Schreizeichen ist nämlich die Verneinung in PSQL und sollte nicht am Anfang stehen. Escapen mit \ ging auch nicht. Das passierte, als ich Matrix-Synapse eingerichtet habe, dieser Service soll Postgres verwenden.
 

Werbung

Top