Problem mit MySQL wenn ich Apache2 über anderen Port verbinde?
Hallo,
heute habe ich ein kleines Problem,
und bevor ich eine moralpredigt bekomme das Man apache2 nur auf Port 80 und 443 benutzt:
"Ich weiß jedoch ist es sinnvoll den "Standartserver" (80/443) auf das verzeichnis /darf/jeder/sehen zu leiten und z.B. den "Home-Server" (8080) auf das verzeichnis /streng/geheim zu leiten"
Falls sich jetzt jemand Fragt wie ich das gemacht habe:
Terminal öffnen
cd /etc/apache2
nano ports.conf
hinzufügen von "Listen [DEIN_PORT]"
^X danach Y und ENTER
nano apache2.conf
danach unter den verzeichnisen einen Neuen eintrag beginnend mit "<Directory [/dein/streng/geheimes/verzeichnis]>" und anschließend mit den von dir gewünschten optionen versehen
^X danach Y und ENTER
dann in das Verzeichnis sites-enabled wechseln
cd /sites-enabled
danach entweder eine neue datei mit endung ".conf" erstellen oder die "000-default.conf" erweitern, in meinem Fall:
nano 000-default.conf
hinzufügen eines neuen Virtual host
<Virtualhost *:[DEIN_PORT_DER_IN_DER_PORTS_CONF_STEHT]>
DocumentRoot [DEIN_STRENG_GEHEIMES_VERZEICHNIS]
ServerName STRENG_GEHEIMER_SERVER
ServerAdmin SAG_ICH_DIR_NICHT@geheime_email.tld
</Virtualhost>
vor dem : muss ein * sein also *:
danach noch ein restart
sudo service apache2 restart
und tada "zweiter" Server läuft (evtl musst du [DEIN_STRENG_GEHEIMES_VERZEICHNIS] noch mit chown etc. modifizieren das Apache die nötigen rechte hat um darauf zugreifen zu können)
Jetzt mein Problem:
Unter dem "Standart" Port von Apache (80) wenn ich mit der datei test.php eine Verbindung zum Mysql - Server herstellen möchte funktioniert dies Prima, sobalt ich die Test.php jedoch auf meinen "zweiten" Server unter Port 8081 schiebe so kommt nur "Verbindung fehlgeschlagen: Connection refused" zum vorschein.
Inhalt von test.php:
<?php
$db_user = "BENUTZER";
$db_pw = "PASSWORT";
$db_place = "DATENBANK";
$db_server = "192.16x.17x.xxx";
$mysqli = new mysqli($db_server, $db_user, $db_pw, $db_place);
$state = true;
if ($mysqli->connect_errno) {
return "Verbindung fehlgeschlagen: " . $mysqli->connect_error;
$state = false;
}
echo mysql_get_host_info($mysqli);
Info:
den Verwendeten nutzer habe ich von allen rechten bis hin zu "nur" datenbankspezifische Rechte schon alles durchprobiert. Auch habe ich schon von "localhost" auf "%" auf "192.16x.17x.xxx" etc. umgestellt.
Gehe ich auf 192.16x.17x.xxx/phpmyadmin und verwende den Benutzernamen + Passwort kann ich mich Problemlos einlogen (auch wenn ich über 192.16x.17x.xxx:8081/phpmyadmin einlogen möchte)
Ich sehe mich echt nicht raus als währe es gut wenn jmd den fehler erkennen und finden würde, danke schonmal
3 Antworten
"Ich weiß jedoch ist es sinnvoll den "Standartserver" (80/443) auf das verzeichnis /darf/jeder/sehen zu leiten und z.B. den "Home-Server" (8080) auf das verzeichnis /streng/geheim zu leiten"
Security by Obscurity ist komplett nutzlos.
Zur Frage: Der Port an den apache2 gebunden ist, hat keine Auswirkungen auf die Konnektivität von mod_php zum RDBMS.
Sinnvollerweise solltest Du Dir mal alle Fehlermeldungen ausgeben lassen bzw. nach diesem im Log schauen.
Sehr spezifische Konstellation, dann ja, kann man das so machen.
Bezüglich der IP: Solange es keinen guten Grund gibt, sollte das RDBMs auch nur auf loopback gebunden sein. Du solltest eher herausfinden, warum die Verbindung von einer anderen IP zu kommen scheint bzw. abgelehnt wird - das hat nichts mit dem Port auf dem Apache lauscht zu tun, sondern eher mit der sonstigen Konfiguration.
Randbemerkung:
Bei lokalen Verbindungen solltest Du eh besser einen Unix Domain Socket nutzen, anstatt des Loopback-Interface (oder einem anderen IP-Interface).
Anscheinend ist es so, daß mysqli bei localhost den Unix Domain Socket nutzt (sagt die Doku). Schlägt das fehl, liegt definitiv etwas im Argen.
Ok ich habe die lösung selber gefunden:
Durch den geänderten Port von 80 auf 8081 sieht der MySQL Server antscheinend die anfrage nicht mehr als "localhost" sondern als eine "externe" (wie wenn du über das www zugreifen würdest). Das Problem ist das der MySQL Server standartmäßig auf 127.0.0.1 "hört" sprich auf localhost, deshalb lehnt er die Verbindung ab.
Um das Problem zu lösen:
Terminal öffnen
cd /etc/mysql/mysql.conf.d/
danach die mysql.cnf mit nano öffnen
nano mysql.cnf
und dann den wert 127.0.0.1 auf die Serveradresse (z.B. 192.16x.17x.xxx) ändern.
Danach mit "sudo service mysql restart" den Mysql-Server neu starten und das Problem ist behoben.
Am besten dann noch den Port blocken im Router das von "auserhalb" nicht zugegriffen werden kann
Wenn du beim mysqli_connect als Host localhost und als Socket (6. Paramter) /var/run/mysqld/mysqld.sock angibst, sollte er immer über den Socket statt über TCP/IP verbinden, dann sollte das nicht nötig sein.
Das du die bind-address ändern musst, liegt eher daran, dass du im Script einmal 192.168.x stehen hast und einmal 127.0.0.1, nicht daran, welcher virtuelle Host das ist...
Schau bitte in deine Logfiles. Dort müsste ersichtlich sein was das Problem ist.
Danke für deine Antwort, jedoch habe ich im "error.log" nur gefunden das er auf die Socket IP 127.0.0.1 hört und das hat mich dazu gebracht die IP in 192.16x.17x.xxx sprich die Server-IP zu ändern
Das ist Unsinn was Du da machst. Natürlich muss MySQL zu 127.0.0.1 verbinden. MySQL sollte nur lokale Verbindungen annehmen und keine von einer externen IP, wie 192... Ändere das wieder zurück und kontrolliere erneut das Logfile. Da Du die konkrete Fehlermeldung unterschlagen hast kann man dir nichts genaueres sagen.
Nein nein,
Das das der MySQL im Netzwerk verfügbar ist ist ja auch gewollt und wie gesagt ansonnsten habe ich keinen fehler im "error.log" stehen. Ich denke das MySql einfach nicht dafür konfiguriert war das man über andere Ports als den Standartport darauf zugreift.
Und die 192.16x.17x.xxx IP entspricht nicht einer Öffentlichen IP sondern einer vom Router zugeteileten IP und somit "hört" der Server wieder "nur" auf das lokale netz, zudem habe ich zum einen einen Portblock eingerichtet und zum anderen alle Benutzer in der MySQL - Config auf lokale verbindungen gesetzt sprich nicht mal root könnte sich von extern verbinden
MySQL lauscht nur auf 3306 - du kannst einstellen ob nur auf localhost oder auch auf extern. Aus Sicht seines Servers ist alles was in deinem Netzwerk ist öffentlich, also extern. Auch dein Rechner mit dem Du versuchst darauf zuzugreifen.
Aus deinen Formulierungen geht jedoch hervor, dass Du eher herumrätst statt selbst nachzuschauen was bei MySQL eingestellt ist. Und da auch weiterhin keinerlei Fehlermeldungen genannt werden kann man dir nicht weiterhelfen.
Ich kann dir die error.log gerne schicken aber du wirst genau wie ich festestellen das kein fehler angezeigt wird.
2019-09-23T19:25:04.035758Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-09-23T19:25:04.037486Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.27-0ubuntu0.19.04.1) starting as process 30956 ...
2019-09-23T19:25:04.042217Z 0 [Note] InnoDB: PUNCH HOLE support available
2019-09-23T19:25:04.042261Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-09-23T19:25:04.042268Z 0 [Note] InnoDB: Uses event mutexes
2019-09-23T19:25:04.042273Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-09-23T19:25:04.042278Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-09-23T19:25:04.042284Z 0 [Note] InnoDB: Using Linux native AIO
2019-09-23T19:25:04.042550Z 0 [Note] InnoDB: Number of pools: 1
2019-09-23T19:25:04.042656Z 0 [Note] InnoDB: Using CPU crc32 instructions
2019-09-23T19:25:04.044428Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2019-09-23T19:25:04.053397Z 0 [Note] InnoDB: Completed initialization of buffer pool
2019-09-23T19:25:04.055659Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2019-09-23T19:25:04.067728Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2019-09-23T19:25:04.130386Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-09-23T19:25:04.130506Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-09-23T19:25:04.521504Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2019-09-23T19:25:04.524269Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2019-09-23T19:25:04.524317Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2019-09-23T19:25:04.525773Z 0 [Note] InnoDB: 5.7.27 started; log sequence number 2829210
2019-09-23T19:25:04.526373Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2019-09-23T19:25:04.527114Z 0 [Note] Plugin 'FEDERATED' is disabled.
2019-09-23T19:25:04.531146Z 0 [Note] InnoDB: Buffer pool(s) load completed at 190923 21:25:04
2019-09-23T19:25:04.535389Z 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
2019-09-23T19:25:04.535425Z 0 [Note] Server hostname (bind-address): '192.16x.17x.xxx'; port: 3306
2019-09-23T19:25:04.535439Z 0 [Note] - '192.16x.17x.xxx' resolves to '192.16x.17x.xxx';
2019-09-23T19:25:04.535585Z 0 [Note] Server socket created on IP: '192.16x.17x.xxx'.
2019-09-23T19:25:04.542735Z 0 [Note] Event Scheduler: Loaded 0 events
2019-09-23T19:25:04.543040Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.27-0ubuntu0.19.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
Wie du sehen kannst werden nur zwei Warnings ausgegeben wobei beide ignoriert werden
Hier noch nachdem ich auf 127.0.0.1 geändert habe und einen zugriff gemacht habe (der wieder fehlgeschlagen ist)
2019-09-23T19:32:12.336478Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-09-23T19:32:12.338236Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.27-0ubuntu0.19.04.1) starting as process 31112 ...
2019-09-23T19:32:12.343268Z 0 [Note] InnoDB: PUNCH HOLE support available
2019-09-23T19:32:12.343301Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-09-23T19:32:12.343311Z 0 [Note] InnoDB: Uses event mutexes
2019-09-23T19:32:12.343318Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-09-23T19:32:12.343323Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-09-23T19:32:12.343328Z 0 [Note] InnoDB: Using Linux native AIO
2019-09-23T19:32:12.343592Z 0 [Note] InnoDB: Number of pools: 1
2019-09-23T19:32:12.343700Z 0 [Note] InnoDB: Using CPU crc32 instructions
2019-09-23T19:32:12.345482Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2019-09-23T19:32:12.354219Z 0 [Note] InnoDB: Completed initialization of buffer pool
2019-09-23T19:32:12.356447Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2019-09-23T19:32:12.368224Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2019-09-23T19:32:12.431882Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-09-23T19:32:12.432020Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-09-23T19:32:12.800622Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2019-09-23T19:32:12.803019Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2019-09-23T19:32:12.803062Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2019-09-23T19:32:12.804323Z 0 [Note] InnoDB: 5.7.27 started; log sequence number 2829238
2019-09-23T19:32:12.804480Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2019-09-23T19:32:12.804699Z 0 [Note] Plugin 'FEDERATED' is disabled.
2019-09-23T19:32:12.806833Z 0 [Note] InnoDB: Buffer pool(s) load completed at 190923 21:32:12
2019-09-23T19:32:12.809758Z 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
2019-09-23T19:32:12.809792Z 0 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
2019-09-23T19:32:12.809807Z 0 [Note] - '127.0.0.1' resolves to '127.0.0.1';
2019-09-23T19:32:12.809932Z 0 [Note] Server socket created on IP: '127.0.0.1'.
2019-09-23T19:32:12.818133Z 0 [Note] Event Scheduler: Loaded 0 events
2019-09-23T19:32:12.818457Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.27-0ubuntu0.19.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
Wie du siehst identisch das selbe nur einmal mit 127.0.0.1 (geht nicht) und einmal mit 192.16x.17x.xxx(geht schon)
Ich spreche nicht vom MySQL-Error-Log sondern vom Apache-Error-Log, idealerweise von dem betreffenden Vhost.
Sinnvoll ist es wenn deine Fritz!Box den Port 80 auf deinen Server leitet und du deinen Homeserver nur im Netzwerk verfügbar haben möchtest ;-) so kannst du ausschließen das man mit bisschen aufwand auf deinen Homeserver zugreifen kann, natürlich ersetzt dies keine Firewall etc.
Antscheinend hat der Port schon auswirkung da wie gesagt test.php auf 80 oder 443(nachdem Zertifikatfehler ignoriert wurde) funktioniert aber die selbe test.php auf 8081 nicht mehr funktioniert