Kleine und große Linux AHAs
Systemmanagement
Tipps und Tricks für Systemmanagement (Scripte, HowTos, Erfahrungen, …)
Simpler Zugang zum Netz, oder nicht? CaptivePortal in einfach
23. Feb
Viele kennen es aus Hotels, Bahnhöfen, Cafes oder öffentlichen Plätzen. Es gibt ein offenes WLAN zum Internet und wenn man sich damit verbindet landet man zuerst einmal auf einer speziellen Seite. Auf dieser muss man sich dann irgendwie registrieren oder halt bezahlen. Aber wie funktioniert sowas und macht das vielleicht auch Sinn für ein Unternehmen intern?
Warum kann das unternehmensintern Sinn machen?
Also hier geht es nicht um Provider oder Firmen die das ganze öffentlich anbieten. Es gibt beispielsweise die Anforderung in Unternehmen die Produktionsstraßen besitzen, Großraumhallen, Fertigungshallen oder ähnliches. Oft gibt es dort viele Geräte verschiedener Hersteller die gewartet werden (nur ein Beispiel). Es kommen also externe Dienstleister um Updates einzuspielen oder Support zu leisten. Diese müssen mittlerweile, um vernünftig arbeiten zu können, Kontakt mit Ihrer Firma haben. Das kann über 3G geschehen, ist allerdings schneller über WLAN. Für solche Dienstleister macht ein WLAN Zugang also Sinn. Das auch für einen “normalen” Besprechungs- oder Schulungsraum schon Sinn machen.
Nun hat man ein Problem. Das WLAN offen zu lassen ist quasi grob fahrlässig. Das WLAN schützen macht es umständlich – je nach Anzahl der verschiedenen Benutzer. Dann haben wir da noch den Aspekt des Loggings. Prinzipiell muss man die Verbindungsdaten mitloggen, da man je nach dem in die Beweispflicht genommen werden kann. Um zu loggen muss ich auch wissen wer zu welchem Gerät gehört, da mir ansonsten die Information nichts bringt. Das alles kann ich mit der Anmeldung quasi erledigen. Ich weiß wer zu welchem Gerät gehört und kann auch mitloggen. Bevor der Nutzer sich über das WLAN mit dem Internet verbindet, muss er einer entsprechenden Nutzungserklärung zustimmen (wegen logging etc.).
Wie kann sich so was mit Linux darstellen?
Diese Portale sind gar nicht so kompliziert wie man denkt. Um so etwas unter Linux zu realisieren kann man sich fertiger Software bedienen oder auch einfach das ganze selbst – relativ schnell – programmieren. Ein Projekt mit einer “CaptivePortal” Funktion ist beispielsweise pfsense. Die meisten CaptivePortal Funktionen befinden sich im Bundle mit Firewalls und bieten weit mehr als eine einfach Authentifizierung für einen Netzzugang.
Um so etwas mit Linux Mitteln darstellen zu können habe ich folgende Komponenten genutzt:
- einen Apache Webserver
- MySQL Datenbank
- iptables
- DHCP Server (Standardkonfig mit Netz 192.168.199.0/24)
Das ganze funktioniert nach folgendem Ablauf:
- Gerät verbindet sich mit dem Netz (dabei ist unerheblich ob per WLAN oder per Kabel)
- das Gerät bekommt eine IP per DHCP
- per Default werden alle Verbindungen geblockt, Verbindungen zu Port 80 (egal wohin) werden auf den Webserver des Gateways umgeleitet, bis das Device registriert ist
Zur Registrierung benötigt man einen Schlüssel (5 Stellen, Alphanumerisch). Diesen kann man sich an eine interne Mailaddresse schicken lassen. Also können nur interne Accounts quasi den Zugriff genehmigen. Wenn man einen Schlüssel besitzt, dann kann man sich über das Portal registrieren (Name, Firma und Schlüssel werden abgefragt). Mit der Registrierung – richtiger Schlüssel vorausgesetzt – wird der Zugang für einen Tag freigegeben.
Genauer??
Der Client bekommt eine IP Adresse vom DHCP Server. Alle Zugriffe ins (bspw.) Internet werden erst einmal geblockt, außer Zugriffen auf Port 80 – diese werden umgeleitet auf den Webserver des Gatewyas – das CaptivePortal erscheint. Hat man noch keinen Schlüssel zum registrieren, so muss dieser angefordert werden. Man trägt eine eMail Adresse ein und sendet die Anfrage. Im Hintergrund wird per Perl Script geprüft ob die Empfängeradresse ok ist (bspw. interne Domain oder in einer Liste) und ein Schlüssel generiert. Dieser Schlüssel inkl. Mailadresse wird in der Datenbank hinterlegt und per Mail an den Empfänger geschickt.
Mit dem Schlüssel registriert sich der Client am Portal (inkl. Name, Firma). Mit dem Klicken des Buttons “registrieren” wird der Schlüssel geprüft und deaktiviert. MAC Adresse, Name und Firma des Anforderers werden in die Datenbank geschrieben. Danach wird ein iptables Befehl abgesetzt, der dem Client mit der betreffenden MAC Adresse den Zugriff zum Netz gewährt. Ebenfalls wird in der Datenbank ein Zeitstempel gespeichert, dadurch ist es möglich über ein iptables-update den Zugriff generell nur für eine gewisse Zeit freizugeben und dann automatisch wieder zu sperren. In der Datenbank gibt es ein Flag um zu definieren, ob dieser Eintrag überhaupt abläuft oder nicht (expires yes/no). Damit kann man also auch das ganze für interne Mitarbeiter statisch freigeben, damit diese sich nicht immer wieder neu registrieren müssen.
Die Komponenten
(Die Scripte liegen bei mir unter /opt/captivePortal – der Pfad ist in manchen Scripten zu finden)
iptables
iptables ist ja quasi auf jedem Linux System vorhanden und muss auch nicht groß konfiguriert werden.
Script 1 (Initiales iptables Script / iptables.sh):
#!/bin/bash # Initial Iptables Script to enable captivePortal # # Ronny Becker, 02.2012 IPTABLES=/sbin/iptables # the interface to authenticate PORTAL_INT=eth2 # the interface where traffic goes through OUTPUT_INT=eth0 # PortalIP (for captivePortal website) PORTAL_IP=192.168.199.201 # clear all rules iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT # Create captivePortal chain $IPTABLES -N captivePortal -t mangle # All traffic goes to this chain $IPTABLES -t mangle -A PREROUTING -j captivePortal ###### captivePortal CHAIN ########## # get allowed MACs out of the database (maybe persistent or in time) /opt/captivePortal/iptablesFromDB.pl # DNS is allowed for all $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -p udp --dport 53 -j RETURN # Mark packets that are not allowed till here $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -j MARK --set-mark 99 # redirect port 80 to captivePortal $IPTABLES -t nat -A PREROUTING -m mark --mark 99 -i $PORTAL_INT -p tcp --dport 80 -j DNAT --to-destination $PORTAL_IP # drop all marked with 99 $IPTABLES -t filter -A FORWARD -m mark --mark 99 -j DROP # masquerading (if needed) iptables -t nat -A POSTROUTING -o $OUTPUT_INT -s 192.168.199.0/24 -j MASQUERADE
Das iptables.sh Script muss bei jedem Systemstart ausgeführt werden. Des Weiteren muss ip_forward (/etc/sysctl.conf) gesetzt sein, damit der Server routen kann.
Script 2 (Perl Script zum Auslesen der aktuellen Berechtigungen aus der Datenbank / iptablesFromDB.pl):
#!/usr/bin/perl
# captivePortal
# Script to get registered MACs out of DB
use DBI;
# get Config from central conf file
BEGIN { require "/opt/captivePortal/captivePortal.conf" };
# database connection
$connectionInfo="DBI:mysql:database=$db;$host:$port";
$dbi = DBI->connect($connectionInfo,$userid,$passwd);
# select datasets
$sql="select mac from registered where expires='no' or ((UNIX_TIMESTAMP()-timestamp) < $tte)";
$sth = $dbi->prepare($sql);
$sth->execute() or die("Cannot get MACs");
$sth->bind_columns(undef, \$db_mac);
while ( $sth->fetch() ) {
# and run iptables
`/sbin/iptables -t mangle -A captivePortal -m mac --mac-source "$db_mac" -j RETURN`;
}
$sth->finish();
$dbi->disconnect();
Config (Konfig für die Perl Scripte (s. Script 2 / captivePortal.conf):
# captivePortal - central config # this conf file is used in perl scripts use vars qw( $tte $db $host $port $userid $passwd $iptables_if ); # Time To Expire for dynamic subscriptions $tte="86400"; # Database Information $db="captivePortal"; $host="localhost"; $port="3306"; $userid="portal"; $passwd="captive"; # portal interface $iptables_if="eth2";
Script 3 (Updatescript für iptables um abgelaufene Registrierungen zu löschen / iptables_update.sh):
#!/bin/bash # captivePortal # Update iptables rules to delete expired registrations IPTABLES=/sbin/iptables # the interface to authenticate PORTAL_INT=eth2 # clear the chain $IPTABLES -t mangle -F captivePortal # run the rules out of the db /opt/captivePortal/iptablesFromDB.pl # add default rules (see iptables.sh) $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -p udp --dport 53 -j RETURN $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -j MARK --set-mark 99
Das Update Script sollte per cron alle Xmin / Xstunden ausgeführt werden, damit abgelaufene Registrierungen den Zugriff verlieren. Wenn man den cronjob nicht gerade jede Minute laufen lässt, ist damit natürlich nicht gewährleistet dass eine Registrierung genau so lange gültig ist, wie es in der Konfiguration steht. In meinem Fall läuft das Script jede Stunde – das ist für meine Zwecke ausreichend.
MySQL
Die Datenbank besteht aus zwei Tabellen -> captivePortal.sql
Apache
Wir benötigen lediglich ein CGI Script. Auf dieses muss per Default umgeleitet werden sobald der Server eine Anfrage bekommt. Das kann man auf verschiedenste Weisen machen – also nicht schimpfen
Redirect
Damit das ganze mit iPhone und Android funktioniert, habe ich folgende Apache config am Start:
<VirtualHost 192.168.199.201:80>
ServerAdmin webmaster@localhost
Servername captivePortal
DocumentRoot /var/www
Redirect /index.html http://192.168.199.201/cgi-bin/captivePortal.pl
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI Indexes -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/$ http://192.168.199.201/cgi-bin/captivePortal.pl [L,R]
</IfModule>
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Dem entsprechend liegt das CGI (captivePortal.pl) unter /usr/lib/cgi-bin.
Das CGI
#!/usr/bin/perl
# captivePortal
#
# This is the cgi for the simple captivePortal
#
# Do not forget to change
# line 51: valid domain to send regkey to
# line 58: sender adress
#
#
#
# Ronny Becker, 02.2012
use CGI qw(:all);
use DBI;
# get Config from central conf file
BEGIN { require "/opt/captivePortal/captivePortal.conf" };
# connect to DB
$connectionInfo="DBI:mysql:database=$db;$host:$port";
$dbi = DBI->connect($connectionInfo,$userid,$passwd);
# params
$thisscript=$ENV{'SCRIPT_NAME'};
# cgi params
$para_req_sendto=param('req_sendto');
$para_req_submit=param('req_submit');
$para_reg_company=param('reg_company');
$para_reg_name=param('reg_name');
$para_reg_key=param('reg_key');
$para_reg_submit=param('reg_submit');
# print some headers
print "Content-type: text/html\n\n";
print '
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>WLAN Gastzugang</title>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
</head>
<body style="font-family: courier,courier-new">
<h2>WLAN Gastzugang</h2><br>';
# request for key
if ( $para_req_submit ) {
# address valid?
if ( $para_req_sendto ) {
if ( $para_req_sendto =~ /.*\@mydomain\.de/i || $para_req_sendto =~ /.*\@mydomain2\.de/ ) {
# generate a key
my @chars=('a'..'z','0'..'9');
foreach (1..5) {
$secret.=$chars[rand @chars];
}
# send key to recipient
$result=`export EMAIL="gastzugang\@mydomain.de"; echo "Der Registrierungsschluessel fuer Ihren Gast lautet: $secret" | mail -s "WLAN Gastzugang" $para_req_sendto`;
print "$result";
# Insert Key into DB
$sql="insert into regkeys(regkey,sendto,datetime) values('$secret','$para_req_sendto',NOW())";
$sth = $dbi->prepare($sql);
$sth->execute() or die("Fehler beim schreiben in die Datenbank");
$sth->finish();
print "<div style='background-color: green; color: white'><p><b>Registrierungsschluessel wurde zugeschickt</b></p></div>";
}
}
}
# request for registration
if ( $para_reg_submit ) {
# name given?
if ( length($para_reg_name) <= 5 || length($para_reg_key) != 5 ) {
print "<div style='background-color: red; color: white'><p><b>Sie muessen einen Namen und den Registrierungsschluessel angeben.</b></p></div>";
} else {
# Check DB for regkey
$sql="select sendto from regkeys where regkey='$para_reg_key' and isActive='1'";
$sth = $dbi->prepare($sql);
$sth->execute() or die("DB: Cannot run select");
$sth->bind_columns(undef, \$db_sendto);
$sth->fetch();
$sth->finish();
if ( $db_sendto ) {
# disable key
$sql="update regkeys set isActive='0' where regkey='$para_reg_key'";
$sth = $dbi->prepare($sql);
$sth->execute() or die("DB: Cannot update");
$sth->finish();
# get MAC
open (ARP,"</proc/net/arp");
while (<ARP>) {
$line = $_;
$line =~ s/ */;/g;
($arp_ip,undef,undef,$arp_mac,undef,undef) = split(";",$line);
if ( $arp_ip eq $ENV{'REMOTE_ADDR'} ) {
$mac=$arp_mac;
}
}
close ARP;
# write data into db
$sql="insert into registered(name,guestof,mac,timestamp,expires) values('$para_reg_name, $para_reg_company','$db_sendto','$mac',UNIX_TIMESTAMP(),'yes')";
$sth = $dbi->prepare($sql);
$sth->execute() or die("DB: Cannot insert");
$sth->finish();
$output=`sudo /sbin/iptables -I captivePortal 1 -t mangle -m mac --mac-source $mac -j RETURN`;
print "<div style='background-color: green; color: white'><p><b>erfolgreich registriert</b><br>$output</p></div>";
} else {
print "<div style='background-color: red; color: white'><p><b>Registrierungsschluessel nicht gefunden</b></p></div>";
}
}
}
# disconnect from DB
$dbi->disconnect();
# print form etc.
print '
<form method=get action='.$thisscript.'>
<b>Registrierungsschluessel anfragen</b><br>
senden an: <input type=text name=req_sendto size=40> <input type=submit name=req_submit value=zusenden></form>
<hr><br>
<form method=get action='.$thisscript.'>
<b>Registrieren</b><br>
<b><u>Achtung! Registrieren Sie sich mit dem Geraet, mit dem Sie Zugriff benoetigen</b></u><br>
<table>
<tr><td>Name:</td><td><input type=text name=reg_name size=30></td></tr>
<tr><td>Firma:</td><td><input type=text name=reg_company size=30></td></tr>
<tr><td>Registrierungsschluessel:</td><td><input type=text name=reg_key size=10></td></tr>
<tr><td colspan=2 align=center><font color=red><b><u>Nutzungsbedingungen:</u><br>
Mit klicken auf den Button "registrieren" stimmen Sie zu,dass die ihre Verbindungsdaten (Zeitpunkt und Dauer einer Verbindung, Addressierungsdaten) mitprotokolliert werden.
Dies dient lediglich zur Fehleranalyse und zur Sicherheitsueberpruefung.
Es werden keine Daten an dritte weitergegeben oder weiterverarbeitet.<br><br><br>
Sie haben (per Default) ab dem Zeitpunkt der registrierung Zugriff fuer 24 Stunden.
<input type=submit name=reg_submit value=registrieren></td></tr>
</table>
</form>
</body>
</html>';
Das Webinterface ist recht einfach gehalten damit es auch mit mobilen Endgeräten keine Probleme gibt. Das ganze ist natürlich nach belieben anzupassen oder zu ändern
Ich hoffe ich hab nix vergessen – falls doch einfach fragen.
Monitoring: Hardware, die Software braucht, um zu wissen, wie es der Hardware geht
03. Jan
Ein neuer HP Server DL380 G7. Die aktuelle Baureihe – tolles Teil. Mit einem kleinen – wie ich finde total unnötigen Schönheitsfehler.
Hardware, die Software braucht, um zu wissen, wie es der Hardware geht?
Hört sich komisch an – ist aber so. Was wollten wir tun? Wir wollten auf diese Maschinen einen VMware Server installieren. Der neue VMware ESXi ist quasi eine freie Version des ESX Servers und wird direkt auf einem Server installiert, ohne dass ein Betriebssystem vorhanden sein muss (früher lief unter dem ESX ein RedHat, was heute darunter läuft weiß ich leider nicht).
Das ganze funktioniert auch mit der Hardware einwandfrei. Alles gut. Dann wollte ich die Maschine monitoren. Wie? Es gibt keine Agents für VMware. Also wollte ich das “Integrated Lights Out” (ILO) Board nutzen. Über diese Karte – mit separatem Netzwerkanschluss – kann man die Maschine remote administrieren (Konsole), bzw. auch direkt über die Hardware neu starten, Systeminfos einsehen (…). Unter anderem zeigt ILO auch das IML (Integrated Management Log) an. In diesem Log werden Systemmeldungen gespeichert wie z.B. Festplattenprobleme, ausgefallene Lüfter oder ähnliches.
Das ILO Interface kann über IPMI abgefragt werden (muss aktiviert werden). Damit lässt sich dann das Log auslesen, bzw. mit Hilfe des ipmievd das ganze auf Fehler beobachten. Der Befehl dazu lautet:
server01:~# ipmitool -I lanplus -U ilouser -H 10.10.200.98 -P <password> sel list 1 | 12/01/2011 | 15:10:13 | Power Supply #0x04 | Failure detected | Asserted 2 | 12/19/2011 | 07:16:21 | Power Supply #0x04 | Failure detected | Asserted
Das sah sehr gut aus. Nun sollte das mit einem Festplattenausfall getestet werden. Also eine Platte raus. Log abrufen …. nix. Keine Meldung. Hmmmm…. Bei den älteren Servern ging das.
Also alle Firmwarestände geprüft und am Ende mit HP in Kontakt getreten.
Extrawurst
Von HP haben wir dann erfahren, dass HP eine eigene Version (ich denke gepatcht mit Treibern/Modulen) des ESXi für ihre Hardware anbietet. Das ganze ist auch kostenfrei – nach Registrierung. Man benötigt diese Version, damit das ILO mitbekommt wenn eine Festplatte – oder möglicherweise auch andere Hardware – ausfällt, bzw. ein Problem hat. Verstehen muss ich das nicht, oder? Es muss auf dem System ein Agent/Modul/Treiber oder wie auch immer laufen, damit die eigene Hardware, in dem Fall eine Management Karte, den Status der Hardware mitbekommt.
Naja, wie dem auch sei. Nun funktioniert das ganze. Gut finde ich nicht, dass es eine solche Abhängigkeit gibt.
Asterisk Projekt: Season 6 – Manchmal kommt es anders, und öfters als man denkt
16. Dez
Was ein Sch…..
Also es ist nun schon einige Wochen her. Da gab es richtig Probleme mit der Anlage die ich hier beschreiben wollte. Auch daher die Verspätungen.
Was ist passiert?
Die Anlage wurde planmäßig installiert und in Betrieb genommen. Das waren so ca. 50 Telefone, 25 Analoge Nebenstellen (Faxe und DECT Telefone). Das ganze gepaart mit einer Queue und tollen Funktionen im Dialplan. Alle Tests waren erfolgreich und es sah super aus.
Die Anlage war also in Betrieb. Dann kam ein Elektriker. Der wollte einen Supertollen Umschalter im Rechenzentrum fertig installieren (Neubau). Ganz ohne dass der Strom ausfällt – versprochen
Also alle Server eingeschaltet gelassen. Passiert doch nix. Aber dann … wie von Geisterhand … auf einmal …. Dunkelheit … und diese Ruhe. Huch. Strom doch weg. Haha. Also RZ tot.
Naja, eigentlich kein Problem sollte man denken. Ok, die Server wieder hochfahren und gut is. Vielleicht macht der ein oder andere noch einen Festplattencheck, aber dann hat sich die Sache. War auch so. Alles wieder gut.
Oder?
Wenige Minuten später … ein Anruf übers Handy. Die TK Anlage steht still. Hä? Das gab’s ja bisher noch nie – egal was ich an Konfigurationsfehlern eingebaut hatte auf allen Testsystemen. Von nun an ging es hin&her. Fehlersuche … überall. Es gab einfach keine Fehlermeldung mit einem Hinweis auf den Fehler. Das Szenario war auch verschieden. Einerseits zog der asterisk Prozess 100% CPU und nahm nichts mehr an. Andererseits schmierte der Prozess mit einem Core Dump einfach sang und klanglos ab. Auch die Laufzeiten waren total verschieden. Mal lief der Prozess ein paar Stunden, mal nur wenige Minuten.
Das ganze ging zwei Wochen hin&her. Zuerst habe ich versucht herauszufinden was los ist – strace, tcpdump, entfernen der Scripte aus dem Dialplan … alles hat nichts gebracht. Auch andere Versionen wurden ausprobiert, keine Änderung. Zwischenzeitlich wurde eine externe Firma mit ins Boot genommen. Die sich genauso die Zähne ausgebissen haben (Konfig geprüft, eigene Versionen von Asterisk paketiert, …), allerdings hatten die dann auch die entscheidende Idee. Das ganze ging gut 2 Wochen.
And the problem was *trommeln* ….
Das Problem waren am Ende Umleitungen am Telefon. Und jetzt fragt ja nicht “Hä?”! Es handelt sich dabei auch nicht um einen Konfigurationsfehler, sondern um ein Fehler in der Asterisk Software. Dieser Fehler ist in Version 1.6 genau so vorhanden, wie in der 1.8 – die wir mittlerweile dann doch einsetzen
genauer gesagt …
Man kann an einer solchen Telefonanlage vieles auf verschiedene Arten lösen. Auch Umleitungen. Einerseits kann man die Umleitungen innerhalb der Anlage abhandeln und andererseits geht das über das Telefon. Besser ist definitiv das ganze über die Anlage zu machen. Das erweist sich auch an vielen anderen Stellen als sinnvoll.
Nun hatte ich das sogar so gemacht. Der “alte” Ablauf für eine Umleitung sah so aus:
- Benutzer drückt eine gewisse Taste am Telefon
- gibt das Umleitungsziel ein
- mit der Bestätigung wird im Telefon lokal die Umleitung gesetzt und im Hintergrund eine Nummer angerufen, die als Parameter ebenfalls das Umleitungsziel besitzt. Dadurch wird in der Anlage ebenfalls eine Umleitung gesetzt.
Am Ende war also im Telefon eine Umleitung, die jedoch im normalfall nicht zum Zug kam, weil bereits in der Anlage umgeleitet wurde. Das ganze funktionierte einwandfrei. Die jeweilige Nummer wurde in der AstDB gespeichert und war somit für den Server jederzeit verfügbar. Bei jedem Anruf wurde geprüft ob eine Umleitung in der Datenbank vorhanden war und entsprechend gehandelt.
Wie gesagt, das ganze funktioniert wunderbar. Jedoch nur solange die Datenbankinformationen mit denen der Telefone gleich sind. Hat ein Telefon eine Rufumleitung aktiviert und der Server nicht, so wird der Anruf an das Telefon weitergeleitet. Das Telefon leitet um und dann …. macht’s PENG!!! Kein Witz. Sobald die Umleitung vom Telefon die Anlage erreicht streckt die Asterisk die Flügel und gibt den Geist auf. Auf diese Idee muss man erst einmal kommen. Vor allem, weil das sich von der Version 1.6x bis 1.8x durchzieht.
Aber was hat das ganze mit dem Stromausfall zu tun?? Na das ist dann auch recht einfach. Da der Server nicht heruntergefahren wurde sondern hart ausgeschaltet, waren die Informationen in der Asterisk DB verloren. Also gab es einige Telefone die eine lokale Umleitung aktiviert hatten, der Server davon jedoch nichts mehr wußte. Mit jedem Anruf auf ein solches Telefon wurde die Anlage gekillt. Es gab natürlich einige resets auf dem Server. Die Datenbank frisch gemacht, auf einen anderen Server umgeschwenkt. Das System sogar komplett neu installiert. Aber – naja am Ende ist mal halt schlauer – was sollte das bringen, so lange man die Telefone nicht zurücksetzt. Wir sind eben immer von einem Serverproblem ausgegangen.
Abhilfe
Nachdem das Problem erkannt war wurde dann erst einmal schnelle Hilfe geleistet. Nagios bekam von mir einen Plugin spendiert, der den Status der Telefone mit dem der Datenbank verglich. Sobald es inkonsistenzen gab wurde es rot. Des Weiteren habe ich ein Script geschrieben, welches alle Umleitungen auf allen Telefonen ausschaltet. Das war jedoch nur die Notfallmedizin.
Nachdem ein wenig Ruhe eingekehrt war habe ich mich dann hingesetzt und die ganze Logik für die Rufumleitungen neu geschrieben. Das ganze funktioniert nun über eine Website für die Snom Telefone (xml). Dort wird das Umleitungsziel eingegeben, das ganze wird dann in eine MySQL Datenbank geschrieben und von Asterisk genutzt. Lokal am Telefon gibt es keine Umleitung mehr. Seit dem ist nun auch Ruhe.
Das ganze war einfach extrem blöd, weil die Anlage ja bereits im produktiven Einsatz war. Dadurch entsteht durchaus ein gewisser Druck
Asterisk Projekt: Season 5 – Die 5 Minuten Terrine oder: Asterisk installation
06. Okt
Ob nun 5 Minuten wirklich gebraucht werden
Asterisk Installation
Die Installation von Asterisk ist eine der Aufgaben die wirklich am einfachsten ist. Ich mache das ganze auf Debian, also hab ich auch die Debian Pakete genommen. apt-get la-le-lu und fertig. Welche Paket ich installiert habe? Diese:
ii asterisk 1:1.6.2.9-2+squeeze3 Open Source Private Branch Exchange (PBX) ii asterisk-config 1:1.6.2.9-2+squeeze3 Configuration files for Asterisk ii asterisk-core-sounds-en-gsm 1.4.19-1 asterisk PBX sound files - English/gsm ii asterisk-doc 1:1.6.2.9-2+squeeze3 Source code documentation for Asterisk ii asterisk-h323 1:1.6.2.9-2+squeeze3 H.323 protocol support for Asterisk ii asterisk-moh-opsound-g722 2.03-1 asterisk extra sound files - English/g722 ii asterisk-moh-opsound-gsm 2.03-1 asterisk extra sound files - English/gsm ii asterisk-moh-opsound-wav 2.03-1 asterisk extra sound files - English/wav ii asterisk-mp3 1.6.2.1-1 MP3 format support (format_mp3) for the Asterisk PBX ii asterisk-mysql 1.6.2.1-1 MySQL support for the Asterisk PBX (cdr mainly) ii libasterisk-agi-perl 1.01-2 Collections of Perl modules to be used with Asterisk PBX AGI
Damit hat man bereits quasi alles was benötigt wird um den Asterisk Server zu starten.
In den Debian Repositories ist noch Asterisk 1.6 – und das ist auch gut so. Asterisk 1.8 gibt es zwar auch schon länger, allerdings ist diese Version noch recht Buggy. Im Internet wird auch noch oft von der 1.8 abgeraten und die meisten Dokus beziehen sich auf 1.6. Ich hatte bisher auch noch keine Probleme mit dem Dienst an sich.
Auf die absoluten Basics (bspw. wie nun einen SIP/Account einrichten) möchte ich hier eigentlich – wie immer – nicht eingehen. Ich möchte mehr die Fallstricke beschreiben die ich auf meinem Weg beiseite räumen musste und ein Tipps geben. Eine gute Quelle ist das Asterisk Buch online ( http://www.das-asterisk-buch.de/2.1/ ). Dort werden gerade die Basics recht gut beschrieben.
Ein paar Konfighints
Konfiguration über Scripte erweitern
Datei: /etc/asterisk/asterisk.conf
Parameter: execincludes = yes ; support #exec in config files
Dadurch wird es möglich innerhalb von Konfigurationsdateien mit Hilfe von “#exec” externe Scripte auszuführen. Der Output eines solchen Scriptes muss im Format der Konfigurationsdatei sein.
Konfigurationen (Accounts & Voicemail) aus der Datenbank
Das ganze läuft unter dem Namen “realtime”. Der Name ist durchaus verständlich, da durch Änderungen an der Datenbank der Asterisk Prozess nicht neu geladen werden muss. Ändert man in den Dateien (sip.conf, voicemail.conf, etc.) muss der Dialplan oder teilweise der asterisk Prozess neu geladen werden.
Datei: /etc/asterisk/extconfig.conf
Parameter:
[settings] voicemail => mysql,general,voicemail sipusers => mysql,general,sip_devices sippeers => mysql,general,sip_devices
Diese Einstellungen bewirken, dass Asterisk nach den SIP Accounts (quasi der /etc/asterisk/sip.conf) auch in der Datenbank schaut. Das gleiche gilt für die /etc/asterisk/voicemail.conf.
Damit das ganze funktioniert müssen noch die Daten für den Connect auf die Datenbank eingerichtet werden.
Datei: /etc/asterisk/res_mysql.conf
Parameter:
[general] ;dbhost = 127.0.0.1 dbname = asterisk_db dbuser = root dbpass = test dbport = 3306 dbsock = /var/run/mysqld/mysqld.sock requirements=warn ; or createclose or createchar
Diese Einstellungen machen dem System die Datenbank bekannt. Man sieht nun auch, dass der Verweis aus der extconfig.conf “general” auf diese Verbindung zeigt und hier seine Referenz hat. Dem entsprechend können also auch mehrere Datenbanken genutzt werden.
Die Datenbanktabellen müssen noch erstellt werden. Dafür möchte ich gerne auf eine externe Seite verweisen -> http://www.voip-info.org/wiki/view/Asterisk+RealTime+Sip
Mit einem reload oder restart sollte dann die Konfiguration in der Datenbank berücksichtigt werden – falls vorhanden. Die Felder in der Datenbank sind analog zu denen in den Konfigdateien. Es gibt einige Spalten die in den jeweiligen Tabellen vorhanden sein müssen, die meisten können jedoch auch einfach gelöscht werden. Auch zusätzliche Spalten sind kein Problem – sie werden von Asterisk einfach ignoriert.
Dateirechte
Mir ist es häufig passiert, dass ich Änderungen vorgenommen habe die vom System nicht angenommen wurden. Das ganze ohne irgendeine Fehlermeldung (wenigstens in den “normalen” logs). Das passiert, wenn die Rechte einer Konfigurationsdatei nicht stimmen. Die Dateien sollten alle asterisk gehören.
Erster Test
Einen ersten Test kann man ganz einfach mit Hilfe eines Headsets und (bspw.) Ekiga oder Jitsi – also Softphones – machen. Ich habe dazu Voicemail konfiguriert und als Test die Mailbox angerufen.
Jeder nur ein Kreuz – CPUs Prozessen zuteilen
02. Okt
Da sind sie nun – fast überall. Die SMP Systeme (Multicore Systeme). Und zu ihnen gesellen sich auch immer mehr Programme, die mehrere CPUs nutzen können … also Multithreaded sind. Und ein altbekanntes Problem.
Lang her
Wenn “damals” ein Prozess ein wenig “überschwenglich” war und durch ein Problem (z.B.) die ganze Leistung des Systems an sich gezogen hat, dann waren das so 100% und die Kiste war tot. Je nach dem.
nicht sooo lang her
Dann kamen die Multicore Systeme und unser Prozess konnte nicht mehr das ganze System lamlegen – Juhuuu. Man konnte sich also wenigstens noch anmelden und den Prozess killen.
Heute
Tja, heute sind wir wieder bei damals. Die Multicoresysteme werden von Multithreaded Prozessen an die Wand gefahren. Toll. Ein Prozess mit 400% CPU usage
Kann man da was tun?
Aber sicher doch. So viel man sich freut, dass das ein oder andere Programm nun mehrere Cores nutzt, so wenig brauchen viele der Programme das. Oder sagen wir mal so: Die meisten kommen auch mit 3 von 4 CPUs aus. Was mache ich also wenn ich einen Prozess habe, der so manches Mal die Kiste herunterzieht? Ich weise ihm einfach nur noch 3 der 4 CPUs zu und kann somit noch mit einer meine Anmeldung vollziehen.
Unser Freund zur Umsetzung dieses gewieften Planes heißt “taskset” (man taskset).
Grundsätzlich benötigt man lediglich 2 Informationen:
- Anzahl CPUs im System
- Anzahl CPUs die man zuweisen möchte
- ProzessID (PID) (bei einem vorhanden Prozess, ansonsten kann ein Prozess auch mit taskset gestartet werden)
CPUs
Die CPUs werden mit Hilfe einer Bitmask definiert.
CPU1 -> 0x00000001 CPU2 -> 0x00000002 CPU3 -> 0x00000004 CPU4 -> 0x00000008 ...
Möchte man eine CPU zuweisen (CPU MASK), so wird einfach die 2 für die CPU2 genommen.
xCPUs
Möchte man mehrere CPUs zuweisen, so werden diese einfach addiert (HEX!). Alle 4 CPUs wären somit “f”. CPU2 und CPU3 wäre “6″ und so weiter …
Nägel mit Köpfen
Um die CPU “Affinity” eines vorhandenen Prozesses zu setzen, nutzt man folgenden Befehl:
taskset -p <CPU MASK> <PID>
Bei Programmaufruf:
taskset <CPU MASK> <CMD>
Asterisk Projekt: Season 3 – malen nach Zahlen
28. Sep
Bisher habe ich beschrieben was gebraucht, bzw. eingesetzt wird. Wie sieht das ganze nun aus?? Lasset uns malen …
Was ich bisher noch nicht erwähnt hatte waren die VLANs. Das “normale” Netzwerk wird von dem VoIP Netz separiert. Das macht man um das VoIP Netz möglichst sauber zu halten von unnötigem Traffic.
Gateways in einer eigenen Welt
In diesem Szenario haben die Patton Geräte quasi eine eigene Welt für sich. Sie befinden sich natürlich in einem Netz mit den Telefonen und dem SIP Server, allerdings machen die Boxen beispielsweise das Analogrouting komplett alleine. Um einen analogen Anruf (Anruf, Fax, Modem) zu handeln wird der SIP Server nicht genutzt. Der Anruf geht von der Patton 4960 (an dem E1 Anschluss) direkt auf die 4118 und zum Endgerät. Dazu sind Routen auf den Geräten definiert. Der Vorteil ist dass nur wenige Geräte beteiligt sind und diese Geräte über die gleichen Fähigkeiten verfügen. Es gibt zwischen den Patton Geräten keine Probleme wenn es um das aushandeln von Parametern geht – was gerade bei Faxgeräten extrem wichtig ist.
Lediglich ein normaler Sprachanruf wird von der 4960 zum SIP Server durchgestellt und von diesem verarbeitet, bzw. an das Endgerät geroutet.
Telefon vermittelt zwischen VLANs
Ein Vorteil der VoIP Technik ist die Verkabelung. Man benötigt lediglich Netzwerk. Um das ganze auch wirklich sinnvoll zu machen haben die Telefone zwei Netzwerkports. Einen für die Versorgung mit dem Netzwerk an sich und einen für den Anschluß eines PCs. Man benötigt also für PC und Telefon nur einen Netzwerkanschluss. Da wir mit den Telefonen ein eigenes VLAN betreiben separiert das Telefon den PC in ein anderes VLAN. In unserem Beispiel arbeitet das Telefon in VLAN 3 und der PC in VLAN 20. Das Telefon wird also über einen Trunk Port an den Switch angeschlossen.
Asterisk Projekt: Season 2 – Technik<->Mensch Schnittstelle
26. Sep
Im ersten Teil hab ich die für die Infrastruktur eingesetzten Komponenten soweit beschrieben – Server + Patton Gateways. Nun fehlt jedoch noch so eine ganz unwichtige Kleinigkeit – die Telefone
Offene Standards – also freie Wahl
Mit Asterisk nutzen wir offene Standards für unsere Telefonie. Also können wir – in der Theorie – jedes Endgerät oder jede Software einsetzen die mit diesem offenen Standard umgehen kann. Das ist soweit richtig. Allerdings muss man auch dort unterscheiden und auf die Leistungen der jeweiligen Produkte schauen. Gerade dann, wenn es um Geräte oder Software für den Endbenutzer innerhalb eines Unternehmens geht, sollte man mit einigen Augen darauf schauen. Das ganze wird noch schwieriger, wenn man bspw. altbekannte Geräte durch neue ablöst – der Mensch ist ein Gewohnheitstier
Such das Telefon, suuuuch
Nun, ein Vorteil einer VoIP Anlage ist, dass man auch Softphones einsetzen kann. Softphones machen an sich auch Sinn an normalen Büroarbeitsplätzen. Der Mitarbeiter “sitzt eh den ganzen Tag am Rechner” und kann ohne den PC auch keinem Kunden helfen. Also warum nicht ein Softphone auf den Rechner machen, Headset dazu und gut ist. Naja. An sich richtig. Dagegen steht z.B. der Mensch als Gewohnheitstier – und wir sprechen ja hier nicht von EDV Menschen. Jemand der EDV interessiert ist wird mit einem Softphone das geringste Problem haben. Aber wir sprechen hier von “normalen Menschen”. Das wird schwieriger. Des Weiteren muss man zuerst einmal ein Softphone finden, mit dem man auch Business Funktionen darstellen kann. Schaut man sich mal um, so wird das nicht so einfach. Natürlich funktioniert Ekiga und auch Jitsi macht eine gute Figur. Jedoch nicht für Unternehmen. Teilweise fehlt die Unterstützung für ein Telefonbuch über LDAP, teilweise können keine Featurecodes (z.B. *88) gewählt werde, Pickup ist nicht möglich oder die Anzeige von vorhandenen Nachrichten auf der Mailbox ist nicht vorhanden.
Es gibt kommerzielle Softphones, welche einige – oder sogar alle – dieser Funktionen bieten.
Wir haben uns aktuell komplett gegen Softphones entschieden. Die meisten kommerziellen sind nicht – oder nur abgespeckt – Linux kompatibel und es rechnet sich nur solala. Ein solches Softphone kostet ca. 40€. Ein wirklich gutes Headset für Unternehmen kostet schnell auch seine 100€. Dagegen steht nun ein Hardware Telefon mit ca. 180€ (mit großem Display) und zusätzlich der geringere Aufwand um die Mitarbeiter zu schulen. Des Weiteren ist man mit Softphones immer abhängig von der Funktion des Rechners. Da brauche ich glaub ich nicht viel zu sagen. Software + OS sind immer so eine Sache
Womit wir an sich wieder dabei wären warum wir die Schnittstellen von dem Asterisk Server getrennt haben und auf die Patton Gateways ausgewichen sind
Das ist irgendwo schon vergleichbar, vor allem da das Telefon als Arbeitsmittel einfach zu wichtig ist.
Also Hardware, und welche??
Wir setzen Snom Telefone ein. Um genau zu sein Snom 370.
Warum diese? Also ehrlich gesagt konnte ich mir nicht eine Batterie an verschiedenen Geräten zulegen und genau testen welche am besten passen und auch qualitativ am besten sind. Wenn man so im Internet stöbert und auch sonst ein wenig die Augen auf hält, dann wird man nur auf wenige Hersteller stoßen. Snom und Siemens als die großen und bekannten in Deutschland. Mittlerweile soll wohl auch Samsung immer mehr mitspielen.
Was ich mir vorher angeschaut habe waren die Möglichkeiten der zentralen Einstellungen (Provisioning) bzw. auch Erfahrungsberichte von anderen Projekten. Mit den ersten Testgeräten wurde ich auch nicht enttäuscht. Die Geräte machen qualitativ wirklich einen guten Eindruck und sind auch von der Bedienung her absolut in Ordnung. Schön sind die vielen Funktionstasten die man quasi beliebig belegen kann.
Viel negatives kann ich von den Geräten bisher nicht berichten. Klar hat sich das ein oder andere mal “aufgehangen”. Aber da muss man auch einfach wissen, dass das ja mittlerweile kleine PCs sind und da kann das mal vorkommen. Ein Gerät (von ca. 80) hatte ein defektes Display. Ansonsten keine Beanstandungen.
Neue Serie: Asterisk Projekt – erst einmal Vortasten
22. Sep
Zur Zeit ist es “Inn” auch innerhalb von Firmen auf VoIP umzustellen. Das ganze macht auch durchaus Sinn. Die Installationskosten lassen sich damit drücken – schon alleine von der Verkabelung her da lediglich Netzwerk benötigt wird. Ansonsten verlangen die klassichen Telefonanlagenanbieter auch recht hohe Wartungskosten. Oft für Anlagen, an die moderne Funktionen immer nur “angebaut” werden. Des Weiteren gibt trotz der Abhängigkeiten vom Hersteller (bspw. Systemtelefone) auch noch weitere Lizenzmodelle. Beispielsweise kostet jeder Post oder auch jeder SIP Account.
Das ganze kann man sich mit Hilfe der freien Anlagen sparen und ist noch dazu – ein wenig Erfahrung vorausgesetzt – um einiges flexibler. Als ich mit dem Projekt begonnen habe hatte ich quasi keine Ahnung von Asterisk und dem Aufbau einer solchen produktiven Anlage. Mittlerweile hab ich dann doch einiges an Know-How aufgebaut. Der Grund warum ich daraus auch wieder eine Reihe auf linux-aha machen möchte: Es gibt nur recht wenig Dokumentation für Business Anforderungen. Ich musste mir viel an Informationen zusammen suchen und genau das ist das, was hier nun hin soll.
Was sind die Anforderungen?
Welche Anforderungen gibt es an eine Telefonanlage innerhalb eines Unternehmens? Wir haben das “einfach” so gemacht, dass wir den Ist Stand als Minimum definiert haben und das Ziel mehr zu bieten. Die “normalen” Anforderungen sind von uns also quasi so definiert:
- Rufumleitung
- Rufweiterleitung
- Anrufergruppen
- Warteschleifen / Queues
- Mailboxen
- Auswertungsmöglichkeiten
- Anbindung an externe Systeme
- Mobilteile (DECT)
- Skalierbarkeit
- Verfügbarkeit
- Offenheit (keine Bindung an Hersteller, Schnittstellen)
- interaktive Menüs
- Ansagen, auch Zeitgesteuert
Nur Asterisk?
Am bekanntesten ist natürlich Asterisk – die OpenSource Anlage. Es gibt auch viele andere. Wir haben uns für Asterisk entschieden, da es dort die größte Community gibt und die Software einfach auch am längsten verfügbar ist. Wobei der Part mit der Community mich dann doch an der ein oder anderen Stelle ein wenig enttäuscht hat.
Eine potenziell mögliche Alternative ist freeswitch. Freeswitch ist wohl – und das hab ich nun nicht weiter geprüft – aus Asterisk entstanden aber hat mit einigen Altlasten aufgeräumt. Ich habe es nie getestet, da uns das ganze als noch zu früh beschrieben wurde.
Großer Kasten oder wie?
Telefonanlagen sind oft recht große Kästen. Ein Haufen Steckkarten, Netzteile und ….
Kann den eine VoIP Anlage das gleiche leisten? Naja, schon. Die eigentliche VoIP Anlage ist ja zuerst einmal ein Server. Der Server muss eine gewisse Leistung haben um x gleichzeitige Anrufe verwalten zu können. Der Server ist also zuerst einmal vergleichbar mit dieser großen Kiste. Nun hat der Server jedoch keine Anschlußmöglichkeiten für analoge Telefone, für Faxgeräte oder auch für den Zugang zum PSTN (zum öffentlichen Telefonnetz). Um diese Anschlußmöglichkeiten zur Verfügung zu stellen gibt es nun mehrere Möglichkeiten. Man kann auf der einen Seite den Server genau so nutzen wie die große Kiste vom klassischen Anbieter. Man nimmt einen Server der einige Steckplätze hat und baut dort dann Karten ein, welche die gewünschten Ports zur Verfügung stellen. Bis zu einem gewissen Maß mag das funktionieren. Allerdings birgt das ganze einen recht großen Nachteil. Die Karten müssen vom Betriebssystem und auch von der VoIP Software unterstützt werden. Das mag am Anfang nicht das Problem sein. Was ist aber bei einem Update? Update des OS, bzw. der VoIP Software? Mit jedem Update stellt sich damit immer wieder nicht nur die Frage ob die Software noch läuft, sondern auch ob die Hardware noch läuft. Das ist nicht wirklich wünschenswert – wenn vermeidbar
Vermeiden lässt das ganze sich durch sogenannte Gateways. Gateways sind in dem Fall schwarze Boxen die beispielsweise einen Ethernet und 8 analoge Ports zur Verfügung stellen oder auch einfach die Schnittstelle zum PSTN darstellen. Sie wandeln beispielsweise das SIP Protokoll (bzw. RTP, T.38) in analoge Signale um das ganze kompatibel zu einem Faxgerät zu machen. Wir setzen dabei die Geräte der Firma Patton (www.patton.com) ein. Die Geräte sind ein wenig teurer, wurden uns jedoch als Qualitativ hochwertig und zuverlässig empfohlen. Damit hat man kein Problem mehr mit Updates und ist dazu noch nach oben hin skalierbar. Braucht man weitere Ports, so kommt eine weitere Box dazu und gut. Die Konfiguration ist recht einfach – darauf wird später nocheinmal eingegangen.
— Soweit Teil 1 —
Unleserliches debuggen, oder: Fehlersuche in verschlüsselten Protokollen
03. Mai
Immer mehr Datenverkehr wird verschlüsselt. Einerseits natürlich richtig und gut. Andererseits ein Problem. Früher konnte man mit Hilfe von Tools wie Wireshark (Ethereal) oder tcpdump relativ schnell Probleme (z.B.) in der Kommunikation zwischen Programm und Server herausfinden. Einfach den Netzwerkverkehr mitschneiden, ansehen / auswerten und es zeigten sich Fehler die man im Programm möglicherweise nicht zu Gesicht bekommen hat.
Mittlerweile sind die Pakete weitestgehend verschlüsselt und man kann nicht mehr einfach so “mit schreiben” – naja, man kann natürlich; aber lesen kann man es nicht. Also fällt ein mitschreiben – einfach mal so – flach.
Eine andere Möglichkeit die Kommunikation zwischen Programmen zu debuggen ist, sich einfach manuell zu verbinden und die Kommandos direkt einzugeben um zu prüfen ob der Server richtig reagiert. Dazu nahm man früher telnet … Auch telnet ist kein Kandidat mehr für verschlüsselte Protokolle.
Verbindung zu einem SSL geschützten Dienst
Eine Möglichkeit sich auf einen solchen Dienst zu verbinden bietet der Befehl
openssl s_client -connect <Zielrechner>:<Port>
Mit diesem Befehl kann man sich beispielsweise direkt auf einen per SSL geschützten IMAP Server (Port 993) verbinden und manuell Kommandos absetzen. Das ganze über eine SSL geschützte Verbindung – die nicht mitgeschnitten werden kann
Ganz wie früher mit telnet *freu*
Daten auf NAS – aber bitte sicherererer
12. Apr
Vor genau einem Jahr habe ich einen Artikel geschrieben der sich mit einem NAS für zu Hause mit iSCSI beschäftigte (s. Teil I, Teil II, Teil III). Mittlerweile habe ich mir ein neues NAS gekauft – ein Synology DS411slim (Link). Was hat mich nun zu diesem NAS System gebracht? Kurz gesagt: Denny
Nee, im Ernst. Die Unterschiede zwischen den Systemen (und ich spreche nur von den Home NAS Systemen) ist sehr identisch. Man bekommt sehr billige die – laut Beschreibung – sämtliche Protokolle unterstützen und auch schnell sein sollen. Man bekommt teure die das gleiche versprechen.
Natürlich gibt es Unterschiede. Ein wichtiger Faktor ist beispielsweise die Lautstärke. Hat das System Lüfter? Welche größe haben sie? Laufen sie immer? Auch die Plattendimension macht einen Unterschied bei der Lautstärke – 3,5″ oder 2,5″? Für uns hier interessant: Mit welchem OS wird das System betrieben? Linux? Bei komplett fertigen Systemen ist auch die Frage welche Festplatten eingebaut sind oder ob 2x die gleiche oder verschiedene eingebaut sind. Das kenne ich aus dem Enterprise Umfeld, wo man zusieht dass in einem Plattensystem nicht eine komplette Serie verbaut ist – hat die einen Fehler, so hat mein ganzes System ein Problem. Das zu Hause zu bedenken mag dem ein oder anderen übertrieben erscheinen, allerdings ist das recht kostenneutral 2 oder mehrere Platten von verschiedenen Serien oder Herstellern zu nehmen – also warum nicht?
Das aber nur als kleines Vorwort
Darum Synology für mich
Ich habe mich für Synology entschieden, weil
- OS ist Linux
- Shellzugriff (bisher nicht benötigt aber möglich)
- erweiterbar über Pakete
- intuitive Benutzeroberfläche
- sehr nützliche Softwarefeatures
- das Gerät wurde als extrem leise getestet (stimmt auch)
- extrem klein, da nur 2,5″ Festplatten eingebaut werden können
- Raid im nachhinein erweiterbar
- geringer Stromverbrauch, gerade auch wegen den 2,5″ Platten
Nun kann man sagen das ganze sind keine Alleinstellungsmerkmale und diese Features haben viele NAS Systeme verschiedener Hersteller. Richtig. Aber:
- Von Synology gibt es gibt Apps für Android und iPhone, mit denen man bequem auf die Bilder, Musik und auch die Dateien auf der Box von überall zugreifen kann
Das war für mich das ausschlaggebende Argument.
Sicherheit der Daten
Das eigentliche Thema dieses Beitrags ist die Datensicherheit auf einer solchen Box. Ich habe einiges an Dokumenten die eine gewisse Sicherheit benötigen. Kann ich diese dann einfach per NFS oder Samba auf eine NAS Box legen? Meiner Meinung nach nicht.
Was passiert wenn die Box gehackt wird? Was wenn sie gestohlen wird? Der Hersteller muss nur einen Softwarefehler in der Firmware haben und die Daten stehen jedem offen. Alles natürlich nur dann, wenn die Box per DynDNS von Außen erreichbar ist (Apps!).
Nun bietet Synology an, die Daten eines “Gemeinsamen Ordners” per integriertem AES Chip zu verschlüsseln. Gut. Aber wie funktioniert das? Naja, so wie es eben nur möglich ist. Das Volume ist verschlüsselt. Um darauf zuzugreifen muss man entweder vorher per Benutzeroberfläche das Volume entsperren oder man lässt es beim booten entsperren. Hmmm… Also der Sinn das ganze beim Booten automatisch machen zu lassen erschließt sich mir auf Anhieb nicht und vor jedem Zugriff das Volume über die Benutzeroberfläche zu entsperren, bzw. danach wieder zu sperren, ist nicht wirklich benutzerfreundlich. Eine andere Möglichkeit gibt es jedoch so direkt nicht.
Container?
Am Anfang dachte ich, man könnte das ganze mit einem Container machen. Beispielsweise mit TrueCrypt. In Nautilus auf den Container klicken, Passwort eingeben und glücklich sein. Nada. TrueCrypt kann nicht mit Samba Laufwerken umgehen
(wenigstens nicht so über Nautilus).
Also das Verzeichnis direkt beim Booten mounten? Auch unschön. Der NetworkManager ist bei mir für die Netze verantwortlich. Also ist ein mounten von Laufwerken über die fstab nicht so einfach möglich.
iSCSI!!
Tja, nach einigem überlegen bin ich dann auf meinen eigenen Artikel gekommen
. Warum nicht iSCSI? Die Box macht das und ich könnte – mit Linux Standardmitteln – die Daten verschlüsseln. Gedacht, getan. Ein iSCSI Target auf der Box angelegt. Und wie schon in meinem anderen Artikel das LUKS Device angelegt, formatiert und gut.
Sobald der NetworkManager ein Device konfiguriert hat, erscheint in Nautlilus ein neues Gerät. Anklicken, Passwort eingeben (oder beim ersten Mal speichern) und schon bin ich auf der Box in einem verschlüsselten Volume.
Problem
Es gibt an sich nur ein Problem mit der Lösung. Es kann immer nur einer darauf zugreifen (zur selben Zeit). Das ist für mich kein Problem, da es sich nur um die Sicherheitsbedürtigen Daten handelt. Alle anderen Dateien sind von mehreren Rechnern gleichzeitig zugreifbar.









