Schlagwort: debian

MSSQL ODBC Client auf Debian 9 Stretch

15.12.2019 / / Keine Kommentare

Im Folgenden wird die Installation und grundlegende Einrichtung eines MS SQL Clients unter Debian 9 für die Verwendung mit PHP beschrieben.

Datei /etc/apt/sources.list.d/mssql-release.list mit folgendem Inhalt erzeugen:

deb [arch=amd64] https://packages.microsoft.com/debian/9/prod stretch main

Mittels aptitude / apt-get die Pakete msodbcsql17, mssql-tools und php7.0-odbc installieren und anschließend die Datei /etc/odbcinst.ini mit folgendem Inhalt erzeugen:

[ODBC Driver 17 for SQL Server]
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.4.so.2.1
UsageCount=1

Die Datei /etc/odbc.ini mit folgendem Inhalt erzeugen:

[ODBC_CONNECTION_NAME]
Driver = ODBC Driver 17 for SQL Server
Trace = No
Server = 192.168.23.42
Port = 1433
Database = database_name
Charset = ISO-8859-1

Quelle

Debian-Package mittels Puppet und wget installieren

13.05.2018 / / Keine Kommentare

Die Installation von dpkg-Packages mittels Puppet kann mit einer einfachen Klasse realisiert werden. Dabei wird das Installationspaket mit wget herunterladen, auf dem Zielsystem installiert und anschließend wieder entfernt.

class examplesoftware ($url) {

 $package_path = "/tmp/${title}"

 exec {'download':
  command  => "/usr/bin/wget -O ${package_path} ${url}"
 }

 package {'install':
  ensure   => installed,
  name     => "${title}",
  provider => 'dpkg',
  source   => "${package_path}"
 }

 file {'cleanup':
  ensure   => absent,
  path     => "${package_path}"
 }

 Exec['download'] -> Package['install'] -> File['cleanup']

}

 

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.