Archiv des Autors: Jörg Kastning

Installation von VMware Tools in einer Ubuntu VM

3 Antworten

Update 2021-06-09

Um den Netzwerkadapter VMXNET3[1. Choosing a network adapter for your virtual machine (1001805)] in einem virtuellen Ubuntu verwenden zu können, müssen die VMware Tools installiert sein. In den aktuellen Versionen von Ubuntu und weiteren Distributionen wie z.B. RHEL, SLES, etc. sind inzwischen Treiber für die VMXNET3-Netzwerkkarte enthalten. Dennoch ist die Installation der VMware Tools empfohlen.
Dieser Artikel beschreibt zwei Methoden, wie dies getan werden kann. Ich gehe dabei ausschließlich auf die Installation unter Verwendung der Kommandozeile (CLI) ein.

Methode 1 – Open-VM-Tools

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB2073803[2. VMware support of open-vm-tools (2073803)].

Bei den open-vm-tools handelt es sich um die Open Source Implementierung der VMware Tools. Die Vorteile dieser Implementierung sind:

  • Die Open-VM-Tools sind in den offiziellen Paketquellen von Ubuntu enthalten. Dadurch wird das Deployment von virtuellen Ubuntu VMs entschieden vereinfacht. Die Installation kann direkt aus den Quellen durchgeführt werden. Es muss nicht auf separate Quellen zurückgegriffen werden.
  • Keine Downtime für das Update der VMware Tools. Das Paket open-vm-tools wird automatisch über die Paketverwaltung aktualisiert.
  • Keine Kompatibilitätsprüfung erforderlich. Aus den Paketquellen wird automatisch das zum Betriebssystem passende Paket installiert.

Die Installation der Tools ist denkbar einfach und geschieht z.B. mittels:

sudo apt-get install open-vm-tools

VMware empfiehlt ausdrücklich die Verwendung der Open-VM-Tools.[3. VMware Tools in an Ubuntu 14.04 Guest] Wer sich über den aktuellen Entwicklungsstand der Open-VM-Tools informieren möchte, kann dies auch direkt auf GitHub tun. [4. https://github.com/vmware/open-vm-tools]

Methode 2

Diese Methode verbleibt der Vollständigkeit halber im Artikel. Es wird ausdrücklich Methode 1, wegen der dort genannten Vorteile, empfohlen.

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB1022525[5. Installing VMware Tools in an Ubuntu virtual machine (1022525)] und führt die einzelnen Schritte auf, die benötigt werden, um die VMware-Tools in einer VM mit Ubuntu zu installieren.

Abhängigkeiten der VMware-Tools

Um die VMware Tools installieren zu können, müssen folgende Pakete auf dem System installiert sein:

  • gcc
  • binutils
  • make
  • kernel sources

Installation auf der Kommandozeile

Als Erstes wird ein Rechtsklick auf die VM in der Bestandsliste des vSphere-Clients ausgeführt. Aus dem Kontextmenü wählt man „Gast -> VMware Tools installieren/aktualisieren“.

In der laufenden Ubuntu-VM werden nun die folgenden Kommandos ausgeführt:

sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
tar xzvf /mnt/cdrom/VMwareTools-.tar.gz -C /tmp/
cd /tmp/vmware-tools/distrib/
sudo ./vmware-install.pl -d

Nach Abschluss der Installation ist ein Neustart auszuführen. Nun kann anstatt des veralteten E1000 auch der aktuelle Netzwerkadapter VMXNET3 zur VM hinzugefügt und verwendet werden.

Testinstanz für einen WordPress Blog erstellen

1 Antwort

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.[1. http://www.mysqldumper.de/] Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.[2. http://www.filezilla.de/]

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.[3. http://nginx.org/]

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.[4. http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html] Nutzer von Apache können .htaccess-Dateien[5. .htaccess – Wikipedia] verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigt, kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name < db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)

Update vom 24.12.2016

Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.

Die Ursache für diese Fehler liegt darin begründet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul mod_rewrite.

Eine Lösung für dieses Problem habe ich ziemlich schnell in der Nginx Library[6. Nginx Library - WordPress Permalinks {en}] gefunden. Es wird die try_files-Direktive[7. Nginx try_files directive {en}] verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.

Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide Fälle betrachtet.

WordPress im Wurzelverzeichnis

Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter http://www.example.com, sucht man in der Konfigurationsdatei der Seite nach dem Block location /. Diesem Block wird folgende Zeile hinzugefügt:

try_files $uri $uri/ /index.php?$args;

Der vollständige Block sollte anschließend wie folgt aussehen:

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

WordPress in einem Unterverzeichnis

Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter http://www.example.com/wordpress, muss der Konfigurationsdatei ein Block nach dem Muster location /wordpress/ hinzugefügt werden, welcher wie folgt aussieht:

location /wordpress/ {
  try_files $uri $uri/ /wordpress/index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

Ein Kalender für die Terminverwaltung

8 Antworten

Nachdem ich in diesem Jahr bereits die Kontrolle über meine E-Mail-Postfächer zurück erlangt habe[1. Der eigene Mailserver – Start der Artikelreihe], gehe ich in diesem Artikel auf die Einrichtung eines Kalenders für die Terminverwaltung im Web und auf diversen Clients ein.

Zu Beginn des Artikels stehen meine Anforderungen an eine Kalender-Lösung. Anschließend gebe ich einen kleinen Überblick über verschiedene kostenlose Lösungen, bevor ich die Lösung näher beschreibe, für die ich mich letztendlich entschieden habe.

Eines sei vorab schon verraten. Bei allen Lösungen handelt sich sich um Software, die auf einem Linux-Webserver installiert werden kann. Die Verwendung eines Root-Servers stellt die größtmögliche Kontrolle über das eigene System und die eigenen Daten sicher.

Anforderungen

Die gesuchte Lösung soll die folgenden Anforderungen erfüllen:

  1. Der Kalender kann auf einem eigenen Server gehosted werden.
  2. Die Terminverwaltung kann über einen Webbrowser erfolgen.
  3. Der Kalender kann unter den mobilen Betriebssystemen Android und iOS genutzt werden.
  4. Eine Nutzung des Kalenders mit dem Mozilla Thunderbird-Plugin Lightning ist ebenfalls möglich.
  5. Mit Hilfe des Kalenders können Termine zwischen den genannten Betriebssystemen und Anwendungen synchronisiert werden.

Kurz angeschaut

Auf der Suche nach einer Lösung habe ich mir die folgenden Projekte kurz angeschaut. Auch wenn ich mich im Endeffekt für ownCloud entschieden habe, führe ich sie hier auf. Evtl. ist jemandem von euch mit einer dieser Lösungen am besten gedient.

Bei sabre/dav[2. Homepage sabre/dav] handelt es sich um einen CardDAV, CalDAV und WebDAV Server. SabreDAV ist komplett in PHP geschrieben und bietet vielfältige Möglichkeiten zum Teilen und Delegieren.

DAViCal[3. DAViCal Homepage] ist ein Server, welcher Kalendereinträge im iCalendar-Format speichern und bereitstellen kann. DAViCal ist in den Ubuntu-Paketquellen enthalten und im Ubuntuusers.de Wiki existiert ein deutschsprachiger Artikel[4. DAViCal im Ubuntuusers.de Wiki] dazu.

Radicale[5. Radicale – CalDAV and CardDAV Server] ist ein sehr einfach einzurichtender Server. Er ist in Python geschrieben und wurde unter der GPL 3 veröffentlicht.

Der ownCloud-Kalender

Meine Entscheidung ist auf den ownCloud[6. ownCloud Documentation Overview]-Kalender gefallen. Er erfüllt alle oben genannten Anforderungen. Darüber hinaus benutze ich bereits eine ownCloud-Instanz zur Verwaltung meiner Kontakte, Bilder und diverser Dateien.

Die Nutzung des ownCloud-Kalenders im Webbrowser ist selbsterklärend. Daher gehe ich an dieser Stelle nur auf die Einrichtung unter iOS, dem Thunderbird-Plugin Lightning und Android ein.

Für alle drei Clients benötigen wir die CalDAV-Adresse des Kalenders. Diese kann man sich anzeigen lassen, indem man auf das Zahnrad unten Links in der Kalenderansicht klickt.

owncloud_calendar

Ansicht eines ownCloud-Kalenders

Einrichtung unter iOS

Die hier beschriebene Einrichtung gilt für iOS 7.1.2. Für andere Versionen müssen die einzelnen Schritte evtl. an die jeweilige Version angepasst werden.

  1. Gehe zu „Einstellungen“ -> „Mail, Kontakte, Kalender“ -> „Account hinzufügen“.
  2. Wähle den Punkt „Andere“ -> „CalDAV-Account hinzufügen“.
  3. Bei „Server“ wird der Hostname eingetragen. Dies ist typischerweise der Name, den man in die Adresszeile des Webbrowsers einträgt, um sich mit der eigenen ownCloud zu verbinden. Benutzername und Kennwort entsprechen den Informationen, mit denen man sich an seiner ownCloud anmeldet. Anschließend kann man noch eine Beschreibung eingeben, um den Kalender in der Übersicht wiederzuerkennen.
  4. Im weiteren Verlauf aktiviert man SSL, falls der eigene Server dies unterstützt.
  5. Bei „Account-URL“ wird die URL eingetragen, welche im ownCloud-Kalender unter „iOS/OS X CalDAV-Adresse“ angezeigt wird.

Viel Spaß mit dem ownCloud-Kalender auf dem iPhone.

Einrichtung in Lightning

Lightning[7. Lightning – Thunderbird Mail DE] ist ein Kalenderplugin für den Mailclient Thunderbird. Es kann über die Thunderbird-Einstellungen -> Add-ons recht simpel gesucht und installiert werden.

In der Ansicht „Erweiterungen“ können die Lightning-Einstellungen konfiguriert werden. Die Dialogfelder sind übersichtlich und zum Großteil selbsterklärend. Anschließend geht es in der Kalenderansicht weiter.

Mit einem Rechtsklick in die Kalenderspalte kann ein neuer Kalender hinzugefügt werden. Im Dialogfenster ist „Im Netzwerk“ auszuwählen und im darauf folgenden Fenster die CalDAV-Adresse des Servers anzugeben.

calendar-caldav-link

CalDAV-Link des Kalenders

Doch Achtung, hier muss der korrekte CalDAV-Link verwendet werden. Dies ist nicht, wie man vermuten könnte, der primäre CalDAV-Link, welcher unter den Kalendereinstellungen der ownCloud zu sehen ist. Statt dessen ist der CalDAV-Link zu verwenden, der direkt neben dem Kalender eingeblendet werden kann.

Im folgenden Dialogfeld kann noch eine Farbe für den Kalender ausgewählt werden und es empfiehlt sich die Offline-Funktionalität zu aktiveren. So kann man den Kalender auch verwenden, wenn keine Online-Verbindung besteht.

Damit ist die Einrichtung des ownCloud-Kalenders in Lightning abgeschlossen.

Einrichtung unter Android

Ich habe den Kalender unter Android 5.0.2 durchgeführt. Die Einrichtung sollte unter den übrigen Android-Versionen jedoch ähnlich verlaufen.

Um den ownCloud-Kalender unter Android nutzen zu können, muss zuerst eine App installiert werden, welche die CalDAV-Unterstützung nachrüstet. Ich habe mich für die kostenlose App „Cal DAV Sync Free Beta“ entschieden. In diese werden Benutzername und Passwort eingetragen, mit denen man sich an seiner ownCloud anmeldet. Hier wird die primäre CalDAV-Adresse aus den Kalendereinstellungen eingetragen, um den Kalender einzubinden.

Damit sind die wichtigsten Einstellungen vorgenommen und der Einrichtungsdialog kann bis zum Ende durchlaufen werden.

Fazit

Die Einrichtung des ownCloud-Kalenders in den verschiedenen Anwendungen und Betriebssystemen ist nicht schwer, sofern man die korrekte CalDAV-Adresse für die jeweilige Anwendung verwendet.

Damit ist ein weiterer Schritt abgeschlossen, die Kontrolle über die eigenen Daten zurückzugewinnen. Der Google-Kalender kann nun in den Ruhestand geschickt werden. :-)

Die Termine können nun auf den verschiedenen Geräten verwaltet und synchronisiert werden. Für mich eine zufriedenstellende Lösung.

Enigmail unterstützt zukünftig nur noch GnuPG 2

2 Antworten

Auf meinem Trusty-Notebook läuft Thunderbird mit dem Addon Enigmail in Version 1.8. Heute Morgen informierte mich Enigmail mit folgender Meldung darüber, dass die unter Ubuntu standardmäßig installierte GnuPG-Version 1.4.16 in zukünftigen Versionen von Enigmail nicht mehr unterstützt wird. Es wird ein Update auf GnuPG 2.0 oder neuer empfohlen.

enigmail-message

Enigmail-Meldung

Nichts leichter als das. Schließlich ist GnuPG 2 bereits in den Paketquellen von Ubuntu enthalten und kann aus diesen installiert werden.

sudo apt-get install gnupg2

Fertig. Mehr ist nicht zu tun. Ein Blick in die Enigmail-Einstellungen zeigt, dass das Addon nun automatisch das soeben installierte gpg2 verwendet.

enigmail-settings

Enigmail-Einstellungen

Die vorhandenen GnuPG-Schlüssel stehen automatisch auch in der neuen Version zur Verfügung. Die Bedienung funktioniert im Wesentlichen wie zuvor. Man verwendet nun lediglich das Kommando gpg2, statt des älteren gpg.

Häufig benötigte MySQL-Befehle

5 Antworten

In diesem Artikel dokumentiere ich die von mir am häufigsten verwendeten und am schnellsten vergessenen MySQL-Befehle. So muss ich sie nicht jedes Mal in der offiziellen Dokumentation nachschlagen.[1. MySQL Documentation]

Der Vollständigkeit halber beginne ich mit dem Befehl, mit dem man sich mit einem MySQL-Server verbindet, welcher auf dem localhost läuft.

$ mysql -u BENUTZERNAME -p
Password:

Eine neue Datenbank kann mit dem folgenden Befehl erstellt werden[2. CREATE DATABASE Syntax]:

CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] db_name
    [create_specification] ...

create_specification:
    [DEFAULT] CHARACTER SET [=] charset_name
  | [DEFAULT] COLLATE [=] collation_name

Beispiel:

CREATE DATABASE db_name;

Einen MySQL-Benutzeraccount erstellt man mit dem Befehl[3. CREATE USER Syntax]:

CREATE USER user_specification [, user_specification] ...

user_specification:
    user [ identified_option ]

auth_option: {
    IDENTIFIED BY 'auth_string'
  | IDENTIFIED BY PASSWORD 'hash_string'
  | IDENTIFIED WITH auth_plugin
  | IDENTIFIED WITH auth_plugin AS 'hash_string'
}

Beispiel:

CREATE USER 'pusemuckel'@'localhost' IDENTIFIED BY 'password';

Mit dem folgenden Kommando werden dem erstellten Benutzer Zugriffsrechte auf die erstellte Datenbank gewährt.[4. GRANT Syntax] Mit diesen Berechtigungen kann der Benutzer neue Tabellen in der Datenbank erstellen, Daten in Tabellen einfügen oder auch die gesamte Datenbank löschen.

GRANT ALL PRIVILEGES ON db_name.* TO 'pusemuckel'@'localhost';

Die letzten beiden Schritte können auch verkürzt mit folgendem Kommando ausgeführt werden:

GRANT ALL ON db_name.* TO 'pusemuckel'@'localhost' IDENTIFIED BY 'password';

Hat man neue Benutzer angelegt, oder die Berechtigungen bestehendender Benutzer geändert, werden die neuen Berechtigungen mit dem folgenden Kommando geladen:

FLUSH PRIVILEGES;

Irgendwann möchte man in seiner Datenbank auch wieder aufräumen und nicht mehr benötigte Datenbanken und Benutzer löschen[5. DROP DATABASE Syntax] [6. DROP USER Syntax]. Dies wird mit den beiden folgenden Kommandos erledigt:

DROP DATABASE db_name;

DROP USER user;

Um eine SQL-Datei einzulesen, um z.B. ein SQL-Dump zu importieren ist folgender Befehl geeignet:

$ mysql -u USERNAME -p DATABASE_NAME < SQL-Datei

So, nun muss ich mich zukünftig nur noch daran erinnern, hier nachzuschauen, wenn mir mal wieder die Syntax entfallen ist. ;-)

SpamAssassins Erkennungsrate mit SA-Learn verbessern

6 Antworten

Unter „Training für SpamAssassin“ wurde bereits erklärt, wie man mit dem Hilfsprogramm sa-learn das Erkennungsverhalten von SpamAssassin trainieren kann.

An dieser Stelle möchte ich noch mal ein konkretes Beispiel dazu dokumentieren.

Auf meinem Server verwende ich die Maildir-Verzeichnisstruktur, zum Speichern meiner E-Mails.

In meinem Fall befinden sich die bereits gelesenen E-Mails im Posteingang im Pfad /var/mail/vmail/example.org/username/mail/cur. Die in diesem Ordner liegenden E-Mails sind kein Spam. Dies kann SpamAssassin mit dem folgenden Befehl mitgeteilt werden:

# sa-learn --ham /var/mail/vmail/example.org/username/mail/cur/ --progress
100% [=========================================================================================================================]  10.43 msgs/sec 00m01s DONE
Learned tokens from 13 message(s) (18 message(s) examined)

Spam landet in meinem Fall im Pfad /var/mail/vmail/example.org/username/mail/Junk/cur. Diese Mails können mit dem folgenden Kommando verarbeitet werden.

sa-learn --spam /var/mail/vmail/example.org/username/mail/Junk/cur

Weitere Informationen findet man auf der offiziellen Homepage von SpamAssassin.

CAcert Assurance auf der CeBIT 2015

Wie im Artikel „CAcert at CeBIT 2015“ beschrieben, könnt ihr mich morgen (17.3.) in der Zeit von 12.00 Uhr bis 13.00 Uhr vor der Halle 2 treffen.

Dort könnt ihr eure Identität von mir und hoffentlich noch einigen anderen CAcert Assurern für das Vertrauensnetzwerk bestätigen lassen.

Bitte bringt mindestens einen gültigen, amtlichen Lichtbildausweis zur Assurance mit.

ownCloud Major-Update durchführen

7 Antworten

Auf meinem privaten Linux-Server lief bis vor kurzem noch ownCloud 7.0.4. In diesem Artikel möchte ich kurz dokumentieren, wie das Update auf Version 8.0.0 durchgeführt wurde.

Zuerst ist sicherzustellen, dass man eine aktuelle Datensicherung der ownCloud-Installation mit dazugehöriger Datenbank hat.

Vor dem Update habe ich im Administrationsbereich meiner ownCloud die beiden Apps „Contacts“ und „Calendar“ deaktiviert. Laut unbestätigten Quellen im Internet können damit seltene Probleme vermieden werden. Dirk und hefeweiz3n haben mich in den Kommentaren zu diesen Artikel darauf hingewiesen, dass dieser Hinweis in der offiziellen ownCloud Dokumentation zu finden ist.[1. ownCloud Server Administration Manual] Und ich dachte mir: „Better safe than sorry.“ ;-)

Zunächst lädt man sich das aktuelle ownCloud Release in ein beliebiges Verzeichnis herunter und entpackt es dort.

wget https://download.owncloud.org/community/owncloud-8.0.0.tar.bz2
tar -xjf owncloud-8.0.0.tar.bz2

Anschließend wechselt man in das DocumentRoot der ownCloud-Installation und löscht dort alle Dateien und Verzeichnisse mit Ausnahme von config und data. Dies kann man z.B. schnell erreichen, wenn im DocumentRoot folgender Befehl ausgeführt wird:

find . -mindepth 1 -maxdepth 1 ! -path ./data ! -path ./config -exec rm -rf {} \;

Nun können die heruntergeladenen Dateien in das DocumentRoot kopiert werden. Im Anschluss sind lediglich die Benutzerrechte zu kontrollieren. Der Benutzer, unter dem der Webserver läuft, muss wieder überall Leserechte erhalten.

Zum Abschluss ruft man die ownCloud-Installation auf und führt die Datenbankaktualisierung durch.

Abschließend nicht vergessen, die Plugins wieder zu aktivieren.

Fertig!

An dieser Stelle noch einmal vielen Dank an kofrezo für seine Tipps vor dem Update.

Spam-SMS und wie man sich dagegen wehrt

3 Antworten

Aus gegebenen Anlass möchte ich in diesem Artikel über Spam-SMS berichten und einen Weg aufzeigen, wie man sich wirksam gegen diese lästigen SMS wehren kann.

Was sind Spam-SMS?

Spam-SMS sind unverlangte SMS. Sie haben meist das Ziel, den Empfänger in eine Kostenfalle zu locken. Häufig wird dabei von professionellen Animateuren ein Flirt vorgetäuscht. Mit Methoden des „Social Engineering“ wird versucht, das Opfer möglichst lange dazu zu animieren, die Konversation fortzusetzen.

example of an actual case of sms spam

Beispiel einer aktuellen Spam-SMS

Häufig wird dabei verschleiert, dass durch die Antwort an die angegebene Rufnummer hohe Kosten entstehen.[1. AntiSpam e.V.]

Woher haben die Täter meine Rufnummer?

Spam-SMS werden nicht von Menschen versendet. Computerprogramme versenden diese Nachrichten auf gut Glück an einen automatisch generierten Nummernkreis.[2. Wie kommen die SMS-Spammer an meine Handy-Nummer?]

Wie kann man sich wehren?

Im Kampf gegen den nervigen SMS-Spam, steht einem die Bundesnetzagentur zur Seite.

Hier kann jeder zu verschiedenen Fällen von Rufnummernmissbrauch Beschwerde einreichen.

Die Beschwerde kann dabei direkt über ein Online Formular[3. Beschwerde/Anzeige/Anfrage in Zusammenhang mit einer Rufnummer] eingereicht werden. Alternativ kann man auch ein PDF-Formular[4. Mitteilung über den Erhalt unverlangter Werbung über Fax, Telefon und E-Mail] ausfüllen, ausdrucken und per Post an die Bundesnetzagentur senden.

Einfach und schnell gibt man seine Anzeige mit dem Online-Beschwerdeformular auf. Durch einen kurzen Frage- und Antwortmodus wird die Anzeige / Anfrage in wenigen Schritten erstellt.

Um den begangenen Rufnummernmissbrauch zu beweisen, ist es ratsam einen Screenshot von der oder den erhaltenen Spam-SMS zu erstellen. Falls man noch nicht weiß, wie man mit dem Smartphone einen Screenshot erstellt, hilft euch das Internet nach einer kurzen Suchanfrage schnell auf die Sprünge.

Nachdem man eine Beschwerde eingereicht hat, erhält man kurze Zeit später eine Bearbeitungsbestätigung mit einem Aktenzeichen.

Maßnahmen der Bundesnetzagentur

Die Bundesnetzagentur selbst schreibt dazu:

Die von Ihnen zu machenden Angaben dienen der Einleitung von Ermittlungen, die zu Maßnahmen gegen Rufnummernmissbrauch und unerlaubte Telefonwerbung führen können. Soweit dies zur Verfolgung des Rechtsverstoßes erforderlich ist, werden die von Ihnen gemachten Angaben an andere Behörden oder Diensteanbieter übermittelt. Nach Abschluss der erforderlichen Ermittlungsarbeit sowie eines eventuellen Verwaltungs- oder Bußgeldverfahrens erhalten Sie unaufgefordert weitere Nachricht bzw. werden im Internet über den Ausgang informiert.

Mögliche Maßnahmen:

  • Abschaltung der Rufnummern
  • Rechnungslegungs- und Inkassierungsverbot
  • Bußgelder

Dazu veröffentlicht die Bundesnetzagentur auf ihren Seiten eine Maßnahmenliste[5. Maßnahmenliste der Bundesnetzagentur], welche über die wegen Missbrauchs von Rufnummern ergriffenen Maßnahmen der letzten 6 Monate informiert.

Ich persönlich habe die Erfahrung gemacht, dass die Bundesnetzagentur jeder Anzeige nachgeht. Dabei kann es manchmal bis zu mehreren Monaten dauern, bis der Betreiber einer Rufnummer ermittelt werden kann. Doch darum muss man sich ja nicht selbst kümmern.

Also macht mit, beim Kampf gegen Spam!

Der Raspberry Pi 2 als Desktop-Ersatz

2 Antworten

In diesem Artikel möchte ich von meinen Erfahrungen berichten, den Raspberry Pi 2 als Ersatz für den Dekstop-PC zu nutzen.

Damit ich meinen alten Desktop-PC endgültig einmotte, möchte ich mit dem Raspberry Pi 2 folgende Aufgaben erledigen:

  1. Aufruf und Lektüre diverser Internetseiten
  2. E-Mail mit Webmail im Browser
  3. Youtube Video wiedergeben
  4. Nutzung verschiedener Social-Media- und Community-Seiten

Für meinen Versuch verwende ich einen Raspberry Pi 2 Modell B mit einer Class 10 SDHC microSD-Karte. Als Betriebssystem kommt Raspbian[1. Raspbian-Download von www.raspberrypi.org] [2. Raspbian Homepage] zum Einsatz. Da sowohl Raspbian, als auch Ubuntu in direkter Linie von Debian abstammen, muss ich mich nicht großartig umgewöhnen, sondern kann direkt mit der Nutzung loslegen.

raspberry-pi-2

Raspberry Pi 2

Wer bei der Installation von Raspbian auf der der microSD-Karte Hilfe benötigt, kann diese im Artikel „Auf den Pi gekommen“ finden.

Der Testverlauf oder auch meine kleine Spielerei

Ist das Image auf der Karte installiert, bootet der Pi 2 in 18-19 Sekunden bis zum Login. Damit ist der Bootvorgang ca. 17 Sekunden schneller als der meines Pi 1. Der Start der grafischen Oberfläche dauert bei meinem ersten Pi ca. 13 Sekunden. Der Pi 2 schafft dies bereits in ca. 8 Sekunden. Das ist auf jeden Fall schneller als mein alter Desktop PC mit klassischen Festplatten. ;-)

Die weiteren Ergebnisse meines Tests sind sehr subjektiv. Der in Raspbian enthaltene Webbrowser Epiphany startet zügig und Webseiten wie www.ubuntuusers.de oder www.raspberrypi.org lassen sich komfortabel ansurfen. Auch der Webmailer Roundcube und XING lassen sich flüssig bedienen. Die Geschwindigkeit ist nicht ganz so hoch wie auf einem aktuellen PC oder Notebook, jedoch ist die Bedienung flüssig und ich fühle mich bisher nicht eingeschränkt.

Beim Besuch von Facebook oder Youtube ist der Spaß dann jedoch vorbei. Facebook wird nur in der Mobilversion angezeigt und Youtube gibt nur die Meldung aus, dass Epiphany nicht unterstützt wird. An dieser Stelle muss ein anderer Browser her. Ich habe mich für Iceweasel entschieden, welcher dem Firefox gleicht.

Dieser Browser braucht schon deutlich länger zum Start. Und auch in diesem Browser hat man an Facebook keine Freude. Es ruckelt, hakt und ist nach meinem Empfinden unbenutzbar. Leider wirken auch Youtube Videos eher wie ein Daumenkino. Dies könnte daran liegen, dass der GPU nur 64 MB RAM zugewiesen sind. Ich habe diesen Wert auf 128 MB erhöht und den Test wiederholt. Während die Benutzung von Facebook immer noch keinen Spaß macht, laufen die Youtube Videos schon deutlich flüssiger ab.

Der Raspberry Pi 2 scheut das Blitzlicht

Im Internet findet man Berichte, dass der Raspberry Pi 2 allergisch auf Blitzlicht reagiert. So schreibt z.B. Golem, dass man den Pi nur ohne Blitz fotografieren kann.

Diesen Bericht kann ich bestätigen. Der Blitz meiner Canon IXUS 115 HS brachte meinen Pi wiederholt zum Absturz.

Fazit

Der Raspberry Pi 2 mag kein vollwertiger Ersatz für einen Desktop PC sein. Dazu ist er aufgrund seiner Hardware einfach zu schwach auf der Brust. Jedoch kann sich der Einsatz eines Desktop PC von Nutzer zu Nutzer sehr unterscheiden. So dass der Pi so manchen Anforderungen bereits genügen mag.

Für Facebook und Youtube werde ich den Pi zukünftig sicher nicht verwenden. Dafür habe ich aber auch noch ein Tablet oder meinen Smart-TV. Für die Internetrecherche oder das Online-Banking ist der Pi jedoch hervorragend geeignet. Damit bekommt er seinen festen Platz auf meinem Schreibtisch. Mein alter Desktop-PC hingegen wird damit leben müssen, dass er mir sein Betriebssystem so schnell nicht wieder zeigen wird.