Schlagwort: linux

Bash Shortcuts / Tastenkombinationen

27.11.2017 / / Keine Kommentare
Shortcut Beschreibung
Ctrl + a zum Zeilenanfang springen
 Ctrl + e  zum Zeilenende springen
Alt + b  ein Wort nach links springen
 Alt + f ein Wort nach rechts springen
 Ctrl + w Wort links vom Cursor löschen
 Alt + d  Wort rechts vom Cursor löschen
 Ctrl + u  vom Cursor bis zum Zeilenanfang löschen
 Ctrl + k vom Cursor bis zum Zeilenende löschen
 Alt + .  letztes Argument einfügen
 … …

MikroTik: SSH Login ab Debian 9.0

24.06.2017 / / Keine Kommentare

UPDATE: Diese Information ist nur noch für ältere RouterOS Versionen vor 6.33 gültig, für neuere Versionen gibt es hier eine ordentliche Lösung.

Nachdem ich vor Kurzem meinen Backup-Server auf das aktuelle Debian 9.0 (stretch) aktualisiert habe, läuft mein Backup-Script für meine MikroTiks nicht mehr. Kein Ein Fall für eine akute Fehlersuche. Meine RouterOS-Config ist im Moment recht statisch, denoch wichtig genug um ein paar Minuten am Wochenende dafür zu opfern. Denn wie heißt es so schön im Buch „Zeitmanagement für Systemadministratoren“ — „Backups, Backups und Backups…“.
Das Backup läuft über SSH mit Key-Authentication mit einem eigenen Script:

#!/bin/bash
MT_HOSTS="mikrotik01.example.com mikrotik02.example.com"
MT_PORT=22
MT_USER=backup
MT_KEY="/root/.ssh/id_dsa"
MT_DIR="/backup/mikrotik"
MT_DATE=$(date +"%Y%m%d-%H%M")
for MT in ${MT_HOSTS}; do
[ ! -d ${MT_DIR}/${MT} ] && mkdir -p ${MT_DIR}/${MT}
ssh -p ${MT_PORT} -i ${MT_KEY} ${MT_USER}@${MT} "/export file=${MT}.rsc"
scp -P ${MT_PORT} -i ${MT_KEY} -B -q ${MT_USER}@${MT}:${MT}.rsc ${MT_DIR}/${MT}/${MT}_${MT_DATE}.rsc
done

Leider akzeptiert MikroTik bisher nur DSA und keine RSA-Keys. Hier liegt auch schon der Fehler: Debian stretch verwendet OpenSSH 7.4 und ab OpenSSH 7.0 wird der DSA-Algorithmus als „weak“ nicht mehr unterstützt. Solange MikroTik keinen RSA-Support implementiert, kann man den DSA-Algorithmus explizit wieder erlauben. Hierfür hab ich im Home-Directory meines Backup-Servers die Config-Datei (~/ssh/config) mit folgender Zeile ergänzt:

PubkeyAcceptedKeyTypes +ssh-dss

Ab dann funktioniert der SSH-Login per PublicKey (und damit mein Backup) wieder tadellos. Alternativ kann auch die Option nur bei dem BackupScript mitgegeben werden. Dafür müssen die SSH Aufrufe im Script mit folgender Option ergänzt werden:

ssh -oHostKeyAlgorithms=+ssh-dss

Quellen:
OpenSSH

mysqldump nach Wechsel auf mariadb-client sichert nicht mehr

05.06.2017 / / Keine Kommentare

Nach einem kurzfristigen Wechsel von mysql-client-5.x auf mariadb-client-10.x (via default-mysql-client) auf Debian Stretch wollte mysqldump keine Daten eines MySQL-Servers (5.1.73-1) mehr sichern:

root@backup:/backup/# mysqldump -h server1 -u backup -p -v database1
Enter password:
-- Connecting to server1...
-- MySQL dump 10.16 Distrib 10.1.23-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: server1 Database: database1
-- ------------------------------------------------------
-- Server version 5.1.73-1

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
-- Retrieving table structure for table table1...
-- Skipping dump data for table 'table1', it has no fields

Ursache ist das in /etc/mysql/mariadb.conf.d/50-client.cnf angegebene Character-Set utf8mb4, welches nach dem Paketwechsel standardmäßig verwendet wird und den früheren Standardwert des mysql-client-Paketes (utf8) ablöste:

[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4

Da der zu sichernde MySQL-Server utf8mb4 nicht unterstützt,  führte die Änderung von default-character-set auf utf8 zur Lösung und nun wieder vollständigen Datenbank-Backups mittels mysqldump.

Der eingangs genante Paketwechsel erwies sich also als recht tückisch, da ab diesem Zeitpunkt keine MySQL-Backups mehr erzeugt wurden, die Sicherung jedoch keinerlei Fehler aufzeigte. Das Backupskript lief erfolgreich durch und es wurden stets neue Backupfiles erzeugt, jedoch alle Tabellen beim Sichern der Inhalte übersprungen („Skipping dump data…“). Nur durch ein manuelles Prüfen der erzeugten Backupfiles fiel auf, dass das Backup nicht mehr funktionsfähig war.