Zu den Fakten, die man nicht oder nur nach einiger Recherche im Netz findet:

• Das Teil ist wahnsinnig laut. Ein nach innen zwei nach außen pustende Lüfter sorgen für ausreichend Lärm. Selbst das Abklemmen eines der beiden nach außen blasenden Lüfter verringert die Lautstärke noch nicht auf ein erträgliches Maß.
• in den Factory Settings (also nach Drücken des RESET-Tasters) ist der Switch unter http://192.168.1.1 (und nicht wie in der Anleitung beschrieben unter http://192.168.0.1) erreichbar
• Die "Discovery"-Funktion und damit das gesamte Web configuration Tool funktionieren nur, wenn der Client bereits für das korrekte IP-Subnetz konfiguriert ist.
• Die Anleitung/das Manual findet man bei allnet.de
• Das Gerät ist baugleich/kompatibel mit bzw. enthält eine Platine von, wahrscheinlich rebranded, CAMEO Web-GSM748TG.
• Bei den "Trunk settings" handelt es sich wohl um eine Link Aggregation nach IEEE802.3ad.

Mal sehen, ob Wim mir helfen kann, auf dem QNAP TS-419P+ einen PPTP-VPN-Server aufzusetzen, mit dem ich mit dem Standard Windows-7-VPN-Client eine sichere Verbindung aufbauen kann.
Auf der Fritz.box werde ich dafür ein Port Forwarding einrichten müssen. Die Fritzbox-internen VPN-Mechanismen sind leider proprietär und weder mit dem Windows-Standard als mit OpenVPN kompatibel.

Wim verwendet Poptop. Alternativ gibt es eine Anleitung zur Installation von OpenVPN.

Letztlich habe ich mich dann für OpenVPN entschieden, da PPTP an sich eine zu große Sicherheitslücke darstellt. Zudem installiert es sich auch nicht ganz von alleine. Die Kernelmodule, die benötigt werden, sind via ipkg nur für eine alte, nicht jedoch für die aktuelle QNAP-Firmware zu bekommen. Wahrscheinlich ist das der Grund, warum es nicht geklappt hat.

Bei der Installation von OpenVPN war auf Windows-7-Client-Seite wichtig, dass der Pfad auf "Programme (x86)" korrigiert wird.
Zudem muss man die PEM-Zertifikatsdateien, wenn man sie auf dem QNAP erzeugt und dann auf den Client kopieren will, vorher mit "unix2dos" konvertieren.

Wer mit dem QNAP mit XMAIL auch Mails per SMTP mail relay verschicken will, sollte gemäß Forumseintrag seine /etc/hosts anpassen:
192.168.1.100 <nas name>.<domain name> <nas name>

Xdove auf dem QNAP sieht zwar ein zeitgesteuertes Backup des IMAP-Servers vor. Dies ist zu konfigurieren unter http://qnapserver/xdove. Hin und wieder ist hier alles mit einem roten Kreut versehen (auch wenn der IMAP-Server ganz normal funktioniert). Dann ist ein Server-Neustart nötig via /etc/init.d/xdove.sh restart
Dieses Backup landet aber in /share/MD0_DATA/.qpkg/XDove/xdove/archives/. Falls man eine externe Platte mit der eingebauten QNAP-Backup-Funktion nutzt, werden hier jedoch nur Windows-Samba-Shares gesichert.

Um diese beiden Backup-Funktionen zu vereinen, erweitert man das Skript /share/MD0_DATA/.qpkg/XDove/bin-utils/xdove-backup.sh umfolgende Zeilen (mit einem Samba-Share "Data" mit Unterverzeichnis "Mailarchiv"):

## hinter die Zeile mit: RESTORE_FILES=""
# variables for backup to external harddisk backuping SMB share
EXT_BACKUP_SHARE="Data/Mailarchiv"
EXT_BACKUP_ARCHIVE="latest_xdove_archive"

## hinter die Zeile mit: cd ${QPKG_INSTALL_PATH}/${QPKG_NAME}/${ARCHIVE_DIR}
# link latest archive to SMB share for backup to external disk
rm ${QPKG_BASE}/${EXT_BACKUP_SHARE}/${EXT_BACKUP_ARCHIVE}
ln -s ${QPKG_INSTALL_PATH}/${QPKG_NAME}/${ARCHIVE_DIR}/${ARCHIVE_NAME} ${QPKG_BASE}/${EXT_BACKUP_SHARE}/${EXT_BACKUP_ARCHIVE}

Bei der Auslieferung der Firmware 3.4.0 Build 0212T für das NAS QNAP TS-419P+ wurde die Konfiguration für XDove nicht korrekt angepasst.

Im QPKG wird XDove 1.3 mit Dovecot 1.2.9 angeboten. Die damit installierte Config ist jedoch nur für Dovecot 1.1.x gültig.

Daher muss per Hand die Datei /share/MD0_DATA/.qpkg/XDove/dovecot/etc/dovecot/dovecot.conf angepasst werden:

#ssl_disable = yes
ssl = no

und
#login_greeting_capability = yes

Bei der Fehlersuche können helfen:
cat /var/log/dovecot/dovecot-info.log
cat /var/log/dovecot/dovecot.log

Eigene Applikationen beim Reboot/Boot automatisch zu starten kann man beim QNAP TS-419-P+ über die autorun.sh steuern, wie im QNAP Wiki beschrieben.

Einzig der dort vorgeschlagene Ort ist etwas versteckt.
meine autorun.sh sieht deshalb so aus:

#!/bin/sh
/mnt/HDA_ROOT/myautorun.sh


Auf /share/MD0_DATA liegen eher Applikation, auf /mnt/HD0_ROOT liegen Systemdateien.

Verlagernd in eine andere Batch-Datei sollte man die autorun.sh in jedem Fall, um bei häufigem Editieren den Flash zu schonen.

Auf meinem QNAP TS-419-P+ möchte ich ressourcensparend nicht einen SMB- und einen NFS-Server parallel laufen lassen. Da ich durch Windows-Clients auf SAMBA angewiesen bin, möchte ich NFS deaktivieren und von Linux-, insbesondere Ubuntu-Clients auf die SMB-Shares zugreifen.

Komischerweise hatte mit der Grundinstallation ein Zugriff von Windows 7 aus funktioniert, der Ubuntu-Client lieferte jedoch "permission denied". Zur Fehleranalyse habe ich auf dem QNAP unter "System Administration -> System Logs -> System Connection Logs" das Logging für "all Events" aktiviert. Dann fährt die CPU-Last zwar auf über 50% bei jedem SMB-Zugriff. Aber man sieht sofort, welche Zugriffe versucht werden.

Ergebnis ist:

• Auf dem QNAP ist unter "Network Services -> Microsoft Networking -> Advanced Options" die Option "Allow only NTLMv2 authentication".
• Windows 7 nutzt NTMv2.
• Bei Ubuntu und auf dem Asus eeePC 701 ist NTLMv2 standardmässig nicht aktiv.
• Der Samba-Client unter Linux lässt sich mit einer zusätzlichen Konfigurationszeile zur Nutzung von NTLMv2 bewegen (unter Ubuntu /etc/samba/smb.conf):client ntlmv2 auth = yes

Ich hatte vorgehabt, auf einem Networking Event, auf dem ein Haufen intelligenter Menschen aus der Automobilbranche auflaufen sollten, eine Vortrag durch die IT- und IT-Security-Brille zu halten.
Meine Prioritäten wollten es anders.
Dennoch möchte ich meine Notizen nicht wegwerfen.
Hier die Stichworte:

• Geschichte
  • <1980 Cars & Computers, einzige Gemeinsamkeit: das "C"
  • ca. 1980: elektronische Steuergeräte
  • ca. 2000: ca. 20 Steuergeräte je Auto, erste fest installiert, später per software update programmierbar/änderbar (z.B. Einspritzverhalten (Software-Tuning), Airbag-Logik)
  • CANBUS
  • Wartungsbuchse, "Auslesen des Fehlerspeichers", VAG-COM et al.
  • keyless go
  • jetzt: Internet im Auto, Android im Auto
• Hacker-Angriffe:
  • DOS-Attacke auf Funkschlüssel durch wireless scrambler
  • hacking von keyless go via Funk-Relay
• Threats and opportunities von der totalen Vernetzung der Autos
• IT-Security as a business enabler:
  • Abrechnung des Ladens eines Elektroautos an einer öffentlichen Zapfsäule nicht möglich ohne intelligente digitale Signaturverfahren: Wie berechne ich die richtige Menge kWh des richtigen Energieversorgers dem richtigen Konsumenten - über die Zapfsäule eines Dritten?
  • Herausforderungen:
    • Auto und Motor vom Automobilhersteller
    • Zapfsäule/Ladestation vom Stromversorger oder einer Tankstelle im Auftrag des Stromversorgers
    • Datenkommunikation und Abrechnungssystem über einen Treuhänder (z.B. Mobilfunkprovider)
• Datenschutz/Privacy in Smart Grids: Bewegungsprofile durch Ladevorgänge an Ladestationen
• Sartre: Safe Road Trains for the Environment