Schlagwort-Archive: MySQL

MariaDB-Server Installation (CentOS 7)

Einleitung

Unter CentOS wird MySQL ersetzt durch die Open Source Datenbank MariaDB.

Installation

Die Installation wie folgt:

Jetzt muss die Datenbank noch zum Systemstart aktiviert werden und schlussendlich zum Betrieb gestartet werden.

Im Anschluss kann die Datenbank noch abgesichert werden, hierzu kann mysql_secure_installation Zugriffsmöglichkeiten anpassen und die standardmäßig vorhandene Testdatenbank entfernen.

Lokal ist die Datenbank nun eingerichtet und erreichbar.

Firewall

Um die Datenbank auch von entfernten Maschinen erreichen zu können, muss die Firewall entsprechend konfiguriert werden:

Have fun!

Eigener dynamischer DNS-Dienst

Vorwort

Die meisten privaten DSL-Anschlüsse bedienen sich eines dynamischen IP-Adresspools und wechseln die IP-Adresse ca. alle 24 Stunden. Hierbei wird kurz die DSL-Verbindung abgebaut. Beim erneuten Wiederaufbau bezieht das DSL-Modem eine neue IP-Adresse. Dies ist auch als Zwangstrennung bekannt. Wenn nun von außen auf solch einen Anschluss zugegriffen werden soll, muss die IP-Adresse bekannt sein. Hilfsweise gibt es Dienste, bei denen man Subdomains registrieren kann, die die eigene IP-Adresse bei einer DNS-Anfrage zurückliefern. Bei Änderung der Adresse, teilt ein Client dies mit und bei erneuter DNS-Anfrage wird die dann aktualisierte IP-Adresse zurückgeliefert.

Anlässlich der unlängst auf heise.de veröffentlichten Nachricht, dyn.com stelle in kürze den kostenlosen Dienst ein, stehe ich vor der Entscheidung, auf einen anderen kostenlosen Dienst umzusteigen oder einen vergleichbaren Service selbst zu implementieren.

Wie wird nun ein solcher Dienst aufgesetzt, der auf dem eigenen root- oder V-Server läuft?

Voraussetzungen

Ein eigener Server mit eigener Namensauflösung ist Pflicht. Im Beispiel nutze ich BIND9 als DNS-Server, er soll die Zone dyn.krausix.de verwalten. Im DNS-Server des Anbieters wird eine entsprechende Zonendelegation eingerichtet. Ferner benötigen wir einen Webserver, MySQL und PHP.

DNS-Konfiguration

Zonendelegation

Im DNS des Providers wird ein Resource Record erstellt, der die Verwaltung der Subdomain „dyn“  an den DNS-Server unter „krausix.de“ delegiert.

Dies sieht dann etwa so aus:

Dies bewirkt, dass die Zone „dyn“ unter der Domain „krausix.de“ an die angegebenen Nameserver „ns1.krausix.de“ bzw. „ns1.dyn.krausix.de“ delegiert wird. Diese sind also authoritativ zuständig für DNS-Anfragen an „dyn.krausix.de“, wobei „ns1.dyn.krausix.de“ die Besonderheit bildet, dass der Nameserver sich selbst nicht auflösen kann. Abhilfe schafft der nachfolgende A-Record, hiermit wird erreicht, dass der Host „ns1.dyn.krausix.de“ bei der Namensauflösung die o.g. IPv4-Adresse bekommt. für IPv6-Adressen wird ein AAAA-Record genutzt.

BIND9, DDNS einrichten

Wir nutzen ddns-confgen, ein Werkzeug zum Erstellen eines Schlüssels und passenden Konfigurationen zum dynamischen Aktualisieren von DNS-Einträgen des Nameservers.

Die Option -z führt ddns-confgen hierbei im „zone mode“ aus, die damit erzeugte Konfiguration erlaubt Updates für alle Subdomains der Zone dyn.krausix.de, das Ergebnis sieht dann wie folgt aus:

Diese Anweisungen müssen im Anschluss umgesetzt werden, wir übernehmen die obige Konfiguration leicht abgewandelt in named.conf oder besser in named.conf.local, die Update Policy passen wir so an, dass Updates lediglich auf A-Records beschränkt sind:

Inhalt:

Ferner schreiben wir den Key in eine separate Datei:

Inhalt:

Für die Forwardlookup-Zone legen wir eine entsprechende Zonendatei an:

Inhalt:

Test Nameserver

Nameserver zunächst neustarten:

Sofern BIND fehlerfrei wieder startet erstellen wir einen DNS-Eintrag und fragen diesen später ab.

Die Zeile server ns1.krausix.de kann normalerweise entfallen, sobald wie oben beschrieben die Zonendelegation eingerichtet ist. Solange ns1.krausix.de  jedoch nicht authoritativ Nameserver für die Zone dyn.krausix.de ist, wird sie benötigt.

Abfragen mit dig:

Auch hier kann im Normalfall @ns1.krausix.de entfallen.

Ergebnis:

DNS-Update per bash-Skript

TODO

MySQL

TODO

Webschnittstelle

TODO

Fail2SQL, eine fail2ban-Erweiterung

Vorwort

Ich nutze seit geraumer Zeit fail2ban zum Blocken von IP-Adressen, von welchen aus mittels Brute-Force massive Login-Versuche entdeckt werden. Beim Stöbern bin ich dann auf fail2sql gestoßen. Damit lassen sich die geblockten IP-Adressen mit nützlichen Zusatzinformationen in einer MySQL-Datenbank ablegen.

Installation

Download von fail2ban, anschließend entpacken:

Datenbank

Es wird eine Datenbank fail2ban mit gleichnamigem Benutzer und entsprechenden Berechtigungen erstellt:

Anschließend wird das mitgelieferte Skript eingespielt:

Datenbank-Verbindung ist anzupassen (Host/User/Passwort):

Update der GeoIP-Datenbank

Fail2Ban

Schließlich ist noch „actionban“ anzupassen:

Somit sind die Vorbereitungen abgeschlossen.

Links

http://sourceforge.net/projects/fail2sql/
http://www.dbsysnet.com/howto-geolocation-for-fail2ban/

Karte

ProFTP mit MySQL

Vorwort

Zum schnellen und unkomplizierten Dateiaustausch soll ein FTP Server installiert werden. Damit die Administration nicht auf der Konsole erfolgen muss, wird die MySQL Nutzung aktiviert.

Pakete

Konfiguration

Hier wird zunächst IPv6 deaktiviert, danach folgen die Kofigurationszeilen für den SQL-Zugriff.

Gruppe und Benutzer werden erstellt:

Ferner müssen noch Kommentare in /etc/proftpd/modules.conf for die folgenden Module entfernt werden:

 Datenbank

Die mitgelieferten Skripte laufen z. T. auf Fehler. Hier angepasste SQLs:

 Los gehts

In der Tabelle ftpgroup ist groupname=ftpgroup mit der entsprechenden GID (/etc/group) und members=ftpuser einzutragen.

Die Tabelle ftpuser wird u.a. mit einer laufenden Nummer (id), einem FTP-Benutzer (userid), einem Password und einem Homeverzeichnis, welches beim ersten FTP-Login automatisch erstellt wird, gefüllt.

Die Tabelle ftpquotalimits wird schließlich mit den gewünschten Limits versehen.

MySQL Replikation einrichten

Einleitung

Im Folgenden wird beschrieben, wie eine Replikation zwischen zwei MySQL-Servern eingerichtet wird.

Vorbereitung Master-Server

Gemäß MySQL-Referenzhandbuch wird empfohlen, ein separates Konto ausschließlich für die Replikationen zu erstellen, dieses benötigt die Berechtigung REPLICATION SLAVE. Nachfolgend wird ein Konto repl erstellt, und diesem die Berechtigung REPLICATION SLAVE erteilt. Zugriff erhalten Clients der Domain your.domain; das Passwort lautet password.

Im Anschluss werden die Datentabellen gesperrt, dann wird der Status des Master abgefragt:

Die jetzt angezeigten Werte für File und Position sind später relevant. Ein Dump wird erstellt. Die Daten werden auf den Slave kopiert.

Vorbereitung Slave-Server

Nach dem Wechsel auf den Slave, sollte der Dump im Verzeichnis /tmp liegen. Von dort wird er in die Datenbank importiert.

 Konfiguration des Master-Servers

Die Konfiguration erfolgt in der Datei my.cnf. Es wird das Binärlogging aktiviert und dem Master eine ID zugewiesen:

Ferner sollen hier auch zur Gewährleistung größtmöglicher Sicherheit zwei Optionen aktiviert werden:

Anschließend den Master wieder starten.

Konfiguration des Slave-Servers

Zunächst wird der Slave gestoppt.

Dann wird die Konfiguration der my.cnf angepasst, hinzugefügt wird server-id:

Bei mehreren Slaves wird die ID jeweils um eins erhöht. Jetzt wird der Slave-Server wieder gestartet.

Per SQL wird mitgeteilt, welcher Server als Master fungiert:

Die Werte müssen entsprechend ergänzt werden, wobei recorded_log_file_name und recorded_log_position zuvor mittels SHOW MASTER STATUS abgefragt wurden (siehe oben). Wurde hier ein leeres Ergebnis geliefert so sind die Werte “ (zwei Hochkomma Leerstring für File) und 4 (Position) einzutragen.

Danach kann es losgehen:

That’s it!

Troubleshooting

Sollten Probleme auftauchen sind zunächst die Logfiles interessant. Darüberhinaus kann mysqld mit der Option –log-warnings gestartet werden, um nähere Informationen zu erhalten.