IT Infrastruktur selber betreiben - wie und warum Andrea Widmann

Transkript

1 IT Infrastruktur selber betreiben - wie und warum Andrea Widmann aw@kalpha.de Selbständige werden durch ihre Berufsethik und den Gesetzgeber oft dazu gezwungen Daten, die berufsbezogen erhoben werden, besonderer Sorgfalt zukommen zu lassen. Ich wollte diese Daten, welche nicht gerade wenig sind, sichern, soweit nötig darauf Zugriff haben und mit meinen Klienten und Angehörigen, sowie Involvierten manche Dateien austauschen können ohne kilometerweise Papier der Briefpost anzuvertrauen. Zur Historie: Mein "digitales Leben" begann bereits in sehr jungen Jahren und ich hatte glücklicherweise keinen Datenverlust zu verzeichnen. Seit meinem ersten eigenen Computer als Jugendliche, einem Apple ][+, hatte ich Daten. Anfänglich nichts, was ich dauerhaft behalten wollte. Mein damaliges Interesse lag eher am Spielen und gelegentlichen Programmieren und diese Ergüsse hielt ich nicht für aufhebenswert. Nach meiner Abiturszeit begann sich das zu ändern. Zu dem Zeitpunkt hatte ich bereits meine ersten Mailboxerfahrungen gesammelt, damals die heis box, habe Daten mit anderen über eine Dial-up-Verbindung per Akkustikkoppler ausgetauscht und fand es später total spannend mit dem ersten eigenen Modem die große weite digitale Welt zu erkunden. Seitdem gab es Daten, die ich behalten wollte. Viele von den damaligen Daten sind nicht mehr vorhanden, die die ich als meine ältesten Daten bezeichnen kann, entstanden während meiner Studienzeit an der Uni Ulm, u.a. als SysOp einer privaten Mailbox im FidoNet und die meisten davon haben heute eher rein nostaligschen Wert für mich. Seite 1

2 Sogar damals wollten wir Betreiber der Mailboxen unsere persönlichen Nachrichtenaustausche privat halten und griffen zu den ersten Verschlüsselungsmechanismen, um das sicherzustellen. Es war u.a. ein offenes Geheimnis, dass einige Uplinks die Nachrichten, die über ihre Systeme liefen, mitlasen oder die Hex-"Downloads" aus dem Usenet mitschnitten. Was ging, wurde gemacht! Das trifft auch auf heutige Zeiten zu. Irgendwann traf mich dann mein Berufsleben und im Laufe der Zeit wurde mir selbst, auch aufgrund vergangener Hackertätigkeiten, klar, was man mit den Daten anderer alles anstellen könnte bzw. wie einfach man auch noch an diese ran käme. Würden meine berufsbezogenen Daten eines Tages Füße kriegen, könnte dies nicht nur einen kleinen Eklat auslösen, sondern meine berufliche Zukunft gefährden. Dropbox, OneDrive & co. sind schon praktische Lösungen, sie haben aber alle eines gemeinsam: Es sind die IT-Systeme anderer Leute! Wenn Daten über die IT-Systeme anderer Leute laufen, werden diese genutzt. Das lehrte auch die Erfahrung. Was geht, wird gemacht wie früher eben auch. Die kritische Frage lautet dabei jedoch inwieweit und zu welchen Zwecken diese Daten verwendet werden. Mit absoluter Sicherheit kann das niemand sagen, es gibt aber entsprechende Vermutungen und Erkenntnisse, die sich nicht erst mit dem Whistleblower Snowden offenbart haben. Kurz: Es ist ein Faß ohne Boden. Viele meiner Kolleginnen und Kollegen gehen deutlich unbekümmerter mit dem IT-Thema um, als ich es tue. Viele meiner Bekannten tun das auch. Vieles beruht sicherlich darauf, dass man nicht weiß wie man dem Abhilfe schaffen kann und auf mangelnden IT-Kenntnissen. Seite 2

3 Es kann nicht jedermanns Aufgabe sein, sich in die IT-Fragestellungen einzuarbeiten. Nicht jeder will wissen, wie man ggf. Klempnerarbeiten zuhause in Eigenregie erledigen kann. Andere lassen dafür den Handwerker anrücken. Dieser Vortrag ist für die gedacht, die trotzdem selbst Hand anlegen wollen und sich zutrauen eine entsprechende Lösung selbst zu realisieren. Die Übersicht der Lösung, die für mich funktioniert: Webserver für meine statische Webseite. Warum statisch? Wenn man weiß wie oft CMSe gehackt werden, will man sich den Aufwand nicht geben, wenn man nur einen kleinen Webauftritt hat. Auf ein BLOG verzichte ich aus Datenschutzgründen gerne. Weiterhin lässt sich eine statische Webseite im Falle eine Crashes nahezu instant auf einen anderen Webserver umziehen. Owncloud-Server, jederzeit über das Internet erreichbar. Synchronisierung aller wichtigen Daten auf Wunsch in Echtzeit, bei mir aber eher selten, über die jeweils angeschlossenen Endgeräte via Owncloud-Client. Zusätzliche Datensicherung per Rsync, gesteuert über einen Cronjob oder gelegentlich per Hand ausgelöst. NAS (aka Samba-Server), ebenfalls auf Debian für private Daten und zur Lagerung nicht mehr dauerhaft benötigter Daten. Auch hier eine weitere Datensicherung. Inkrementelle Sicherung aller Daten separat ein Mal wöchentlich auf externe Festplatten. Vollständige Sicherung, ebenfalls separat, ein Mal monatlich, ebenfalls auf externe Datenträger. Ggf. Verschlüsselung via VeraCrypt und/oder PGP, insbesondere, wenn ich meine Daten archiviere. Zugriff von außen via VPN, insbesondere, wenn ich in öffentlichen WLANs unterwegs bin. Seite 3

4 Die Hardware (und jetzt wird es schräg!): Ursprünglich waren zwei meiner Server X86er-Maschinen, die mir aber insgesamt zu laut und zu kostenintensiv für die kleine Lösung, die ich fahre, wurden. Deshalb habe ich umgestellt, als einer der Server abrauchte. Alle heutigen Server sind Raspberry Pi Kleinstcomputer (RPi2 bzw. Rpi3, die per Bootloader (bootcode.bin) von der micro-sd-karte gestartet werden, dann aber auf eine extern angeschlossene Festplatte zugreifen. Dadurch vermeide ich korrumpierte SD-Karten, weil sie nicht gemountet werden und keine Schreibvorgänge im laufenden Betrieb vorkommen. Wie das geht, kann man hier z.b. nachlesen: Ich habe jedoch NTFS nicht als Dateisystem gewählt, sondern auf EXT4 zurück gegriffen, man müsste die Anleitung ggf. an die eigenen Bedürfnisse anpassen, z.b. ntfs-3g und ntfs-config nicht installieren und die HDD eben mit sudo mkfs.ext4 /dev/sdax (das X steht für die Datenträgernummer) kurzerhand formatieren. Der Rest ist ansich das selbe Vorgehen. Kurzer Hinweis zur Festplatte und zur Vorbeugung von Datenverlust: Die jeweilige HDD wird bei mir alle 18 Monate ausgetauscht, um durch den 24/7-Betrieb möglichen Totalschaden aus dem Weg zu gehen. Die SD- Karte ebenso. Die Überwachung der SMART-Daten der HDDs findet via Seite 4

5 Smartmontools statt, was aber keinen Sicherheit garantiert. Wenn das meckert, so meine Erfahrung, ist das Kind zumindest teilweise schon in den Brunnen gefallen. Aufgrund unangenehmer Erfahrungen hat sich bei mir bei jedem Festplattentausch etabliert, dass ich nach der ersten Installation, bzw. Wiedereinrichtung, generell ein Image der HDD per DD ziehe, um einem möglichen Crash vorzubeugen, der bei Dauerbetrieb bei manchen Festplatten nach 2-3 Wochen kommen kann. Dies gilt auch für die SD- Karten. Diese sind, wenn man sie dauerhaft nutzt, sehr schnell im Eimer, da sie nicht für einen solchen Einsatz konzipiert sind. Ich habe immer eine oder zwei Festplatten als Ersatz auf Lager, falls es zum Crash kommen sollte. Da die Daten aber mehrfach gesichert sind, ist es nicht weiter tragisch, wenn es zum echten Crash kommen sollte, nur eine Frage der Zeit, bis wieder alles läuft. Wichtig: Wenn es in dem Raum, in dem die Server/der Server betrieben wird, richtig warm werden sollte, müsste man sich eine Lösung zur Kühlung einfallen lassen. Dies jedoch weniger für die Kleinstrechner, sondern für die Festplatten. Ich habe mich bisher mit genügend Abluft aka einem einfachen Lüfter beholfen, das ging auch im extrem heißen Sommer 2015 gut. Die technische Realisierung: Eine Domain ist immer irgendwie empfehlenswert, wenn es halbwegs lesbar sein soll, was man als URL anderen vorsetzen mag. Soll es eine private Seite werden und man sich darüber keine Gedanken machen braucht, ist es soweit egal. Für die Domain-Lösung sucht man sich einen Seite 5

6 Domainanbieter nach Wahl, bucht kein Hosting-Paket, sondern nur die Domain und editiert die dazugehörigen DNS-Einträge so, dass diese auf die IP-Adresse zeigen, die am Anschluss genutzt wird. Dazu benötigt man eine statische IP-Adresse, die es vom Provider der eigenen Wahl gibt. Wer einen Dynamic-DNS-Anbieter wählt, leitet beim Domainanbieter weiter. Der Dynamic-DNS-Anbieter sollte idealerweise im Router eintragbar sein, da es in manchen Fällen interessant werden könnte mit der Ermittlung der IP-Adresse durch den Client des Anbieter. Bitte hier also das Angebot genau prüfen. Es gibt kostenlose und zahlungspflichtige Angebote. Erstere sind schwerer zu finden, gibt es aber definitiv noch. Im Router Portweiterleitungen für die folgenden Ports einrichten: 80 für HTTP 443 für HTTPS Auf keinen Fall das Scheunentor auf machen! Idealerweise lässt sich das im Rahmen von Kleinlösungen durch eine FritzBox erledigen, viele andere Router lassen hierzu ebenfalls sinnige Lösungen zu. Manche fallen ganz durch, weil sie erst einmal alles offen lassen, was geht. Ich rate dringendst davon ab einen eigenen Router dafür zu bauen! Das ist aus Sicherheitsgründen keine sinnige Wahl, die Gefahr, dass das früher oder später gehackt wird, weil es einfach zu viele Möglichkeiten gegeben sind, ist zu groß für Eigenlösungen. Der Aufwand stünde in keinem Verhältnis zum Nutzen. Alle meine Server sind per LAN-Kabel angebunden, aus unerklärlichen Gründen tritt im WLAN-Stack alle paar Tage, manchmal auch erst nach ein oder zwei Wochen, ein Fehler auf und man muss diesen neu starten. Da ich zu wenig Zeit und zu viel Faulheit für die Fehlersuche hatte, habe ich Seite 6

7 es dabei bewenden lassen, weil die angeschlossenen HDDs aufgrund von USB 2.0 eh nicht extrem schnell sind. Im Web fanden sich div. Hinweise, aber keine Lösungen. Betriebssystem: Debian Jessie aka Raspbian Jessie Lite als Image von der Raspberry Pi Foundation ( entsprechend der dort vorhandenen Anleitung installiert und mit raspi-config ( konfiguriert. Der SSH-Server (Secure Shell) wird aktiviert, sodass man später per SSH darauf zugreifen kann. Hier ist wiederum wichtig zu erwähnen, dass der SSH-Port (Standard ist 22) bitte im Router tunlichst zu ist! SSH sollte nur im Intranet gehen! Sicherheit geht auch hier vor. Ab jetzt sind alle Befehle/Anleitungen via SSH oder Shell durchzuführen, grafische Tools habe ich keine genutzt und kann keine empfehlen, da ich damit keine Erfahrungen gesammelt habe. Nach der ersten Installation das übliche Update drüber laufen lassen: sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y && sudo apt-get autoremove -y Es lohnt sich jetzt einen Kaffee holen zu gehen, das kann etwas dauern. Nach dieser initialen Installation ziehe ich in der Regel per DD unter Linux ein Image der SD-Karte, um bei Fehlern in der späteren Konfiguration wenigstens einen definierten Stand zu haben, den ich ggf. wieder drüber schreiben kann. Alternativ kann man es auch unter Windows machen, dazu verwendet man den Win32DiskImager. Dazu muss man den RPi runterfahren, die Karte entfernen und auf einem anderen Rechner das Image ziehen. Seite 7

8 Alle meine Server haben Samba installiert, weil es für mich auf diese Weise recht einfach ist, Dateien dorthin zu transferieren. Jedoch nur einen nutze ich als NAS für den internen Datenaustausch. NAS: Samba-Server Wie man einen Samba-Server unter Linux installiert, kann man auf reichlich vielen Webseiten nachlesen. Die Kürze des Vortrages erlaubt leider nicht, dass ich dahingehend stark in die Tiefe gehe. Bitte nicht vergessen mindestens einen Sambauser anzulegen, sonst wird es interessante Zugriffsprobleme geben (Befehl: smbpasswd), weil kein User definiert ist. Wer eine Anleitung braucht, diese hier ist gut gelungen: Die wesentlichen Teile der smb.conf meines Samba-Servers (ein bisschen zur Sicherheit modifiziert und gekürzt): [alle] comment = Alle User path = /wo_ich_auch_immer_meinen_mountpunkt_habe/data/sambashare/allusers valid users force group = users create mask = 0660 directory mask = 0771 writable = yes [homes] comment = Home Folders browseable = no Seite 8

9 valid users = %S writable = yes create mask = 0700 directory mask = 0700 Gut zu sehen ist, dass jedermann, der sich in meinem Netz aufhält, auf den angeschlossenen externen Datenträger zugreifen kann. Dort fliegen reichlich viele Daten rum, das hat seinen Sinn und Zweck. Dies ist jedoch so aufgeteilt, dass jeder User sein eigenes Verzeichnis hat, das niemand anderes einsehen kann und ein gemeinsames Verzeichnis für alle User, um Daten auszutauschen. Für einen vollen Zugriff, wie ich ihn im Home-NAS konfiguriert habe, sähe das dann so aus: [Daten] comment = Medienserver path = /mein_mountpunkt/datentraeger writeable = Yes only guest = Yes create mask = 0777 directory mask = 0777 browseable = Yes public = yes Die Datei-Rechtevergabe unter Linux zur Wiederholung kann hier nachgelesen werden: Auf meinem Samba-Server läuft zugleich auch mein Webserver für die HTTP-Seiten, aber nicht die SSL-abgesicherte HTTPS-Seite. Warum ich das trenne? Bastle ich an meinem Webserver, kann ich, ohne einen Ausfall meiner Webpräsenz zu generieren, einfach auf den anderen Seite 9

10 Server umlenken indem ich im Router kurzerhand die Portweiterleitung vor der Wartungsarbeit verändere. Außerdem sind die meisten Skriptkiddies zu dämlich bei einer Webpräsenz erst einmal gezielt die HTTPS-Seite anzugreifen, man testet in der Regel automatisiert die Schwachstellen der nicht-verschlüsselten Verbindung aus. Händische Hackversuche sind bisher noch keine auf meinem Server passiert. Fail2ban ist deshalb so ziemlich auf meinem anderen Server unterbeschäftigt und das LOG-File des Apache-Servers sieht richtig überschaubar aus, im Vergleich zum unverschlüsselten HTTP-Server. Meistens sind es chinesische oder russische IP-Adressen, die ihr Glück versuchen, es gibt aber auch einzelne andere Adressen, die ich mir hin und wieder neugierig genauer betrachte. Interessanterweise grasen die Suchmaschinen auch nicht per Standard die HTTPS-Seiten ab, sondern bleiben auf den HTTP-Seiten. Der Webserver auf beiden Servern: Dafür habe ich Apache gewählt, alternativ ginge auch Nginx. Das ist dem persönlichen Geschmack überlassen. Beide installieren sich fast gleich, mehr Möglichkeiten bietet Apache. Da es von der Performance her hier bei mir keinen echten Unterschied macht aufgrund der kleinen Site und wenig Anspruch, hätte auch Nginx locker seinen Dienst verrichtet, ich kannte Apache nur schon von früher und da siegte schlicht die Faulheit sich in ein anderes Produkt einzulesen. Eine einfache Standardkonfiguration genügt, um Apache dazu zu überreden eine nicht SSL-abgesicherte Webseite zu zeigen. Bis dahin sind die beiden Server, die über das Web erreichbar sind, fast Seite 10

11 identisch. Die Samba-Konfiguration unterscheidet sich ein bisschen, um Sinn zu machen. Beim anderen Server kommt noch die Cloud dazu. Für den Webserver, der auch NAS ist, braucht es keine Datenbankinstallation, sollte man zu einer statischen Webseite greifen. Dies wäre dann erst notwendig, wenn man z.b. Wordpress o.ä. doch den Vorzug geben mag. Mit sudo apt-get install apache2 ist der Webserver auch schon installiert und kann getestet werden. Eine Anleitung kann auf der Raspberry Pi Foundation Webseite gefunden werden: meine /etc/apache2/sites-available/000-default.conf für die Standard-Webseite ohne SSL sieht so (ein bisschen anonymisiert und wieder standardisiert) aus: <VirtualHost *:80> ServerAdmin DocumentRoot /var/www/html <Directory /> Seite 11

12 Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/html/> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> 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> Wer SSL aktivieren will, sollte die /etc/apache2/sites-available/default-ssl.conf anpassen, hier ein Vorschlag meinerseits mit eingebundenem SSL- Zertifikat von WoSign und ich nicht zur Selbstsignierung gegriffen habe (bitte auch hier beachten, dass ich ein bisschen anonymisiert habe): <IfModule mod_ssl.c> <VirtualHost _default_:443> Seite 12

13 ServerAdmin DocumentRoot /var/www/html <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/html/> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/pfad_zum_zertifikat/2_mein_zertifikat.crt SSLCertificateKeyFile /etc/apache2/pfad_zum_zertifikat/3_mein_zertifikat.key SSLCACertificateFile /etc/apache2/pfad_zum_zertifikat/1_root_bundle.crt <FilesMatch "\.(cgi shtml phtml php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ Seite 13

14 downgrade-1.0 force-response-1.0 # MSIE 7 and newer should be able to use keepalive BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> </IfModule> Jetzt nur noch die Webseitendateien in den Dateipfad kopieren (/var/www/html) und dann kann man das erste Ergebnis auch schon im Browser bestaunen. Die Cloud: Das ist ein anderer Server mit der selben Grundinstallation, jedoch läuft auf diesem noch die Cloud. Derzeit Owncloud, eventuell irgendwann Nextcloud. Aus Zeitgründen bin ich noch nicht umgestiegen und es ist auch noch fraglich, ob. Zuerst möchte ich etwas Zeit ins Land streichen lassen, bevor ich mich mit wehenden Fahnen einem anderen Produkt zuwenden sollte. Eine gute Anleitung zur Installation von Owncloud kann hier gefunden werden: Auch hier bitte beachten, dass ich bei mir ein Zertifikat von WoSign eingebunden habe und nicht zur Selbstsignierung greife. Das schreckt nur die User ab, die ich auf meine Seiten schicke, um sich dort Dateien runter Seite 14

15 zu laden. Man bekommt sonst eine Meldung, dass die Seite unsicher sei und man sich besser schleunigst wieder davon machen möge. Ganz so abschreckend wollte ich meine berufliche Webpräsenz dann doch nicht gestalten. WoSign ( bietet kostenlose SSL- Zertifikate an, man kann aber auch zu Let's Encrypt greifen ( Warum ich nach wie vor ein WoSign-Zertifikat habe? Weil das schon existierte bevor Let's Encrypt seine Pforten öffnete. Dabei halte ich mich an die Regel: Never touch a running system. Der Zugriff von unterwegs via VPN: Ich nutze eine FritzBox als Router. Die dazu gehörige Anleitung kann auf den AVM-Webseiten ( nachgelesen werden. In der Regel ist es für alle FritzBoxen gleich bzw. ähnlich. Wichtig ist zu beachten, dass wenn man mit mehreren Geräten gleichzeitig eine VPN-Verbindung aufbauen mag, muss man für jedes Gerät einen eigenen VPN-User anlegen. Parallel über den selben User an verschiedenen Geräten eine VPN-Verbindung zur FritzBox aufzubauen ist nicht möglich. Der Betrieb, andere Dienste: Ich nutze zur Überwachung der Festplatten smartmontools, auf den Webservern fail2ban und habe die.htaccess modifiziert. Die meisten Anpassungen der.htaccess sind Einschränkungen im Zugriff oder eine Weiterleitung, weil z.b. jemand anderes meine Webseite noch auf eine alte Unterseite verlinkt hatte, die sonst einen 404er auswerfen würde. Seite 15

16 Weiterhin nutze ich die "6g Firewall" als Modifikation der.htaccess von Ich halte mich in Sachen IT möglichst auf dem Laufenden, Updates auf meinen Servern werden regelmäßig eingespielt, davor generell Datensicherungen gemacht. Diese laufen per Rsync auf externe Festplatten, die man auch am RPi einfach im laufenden Betrieb einstecken/einschalten, mounten, nutzen, dismounten und wieder ausstecken/ausschalten kann. Zusätzliche Datensicherungen lasse ich an meiner Hauptarbeitsmaschine laufen. Fällt kein Update an, werden nur Daten gesichert. Nichts ist lästiger, als die Arbeit von Wochen oder sogar Monaten zu verlieren. Man kann damit sogar seine selbständige Existenz gefährden. Owncloud erlaube ich nicht in Echtzeit zu synchronisieren, falls ich meine Daten doch noch verändern sollte. Es erfordert ein gewisses Maß an Disziplin, das ich aber gerne aufbringe, um das Risiko von Datenverlust minimal zu halten. Ich habe noch nie mehr als die Arbeit von wenigen Stunden verloren. Der Aufwand für die Wartung und Instandhaltung hält sich dabei absolut in Grenzen. Derzeit ist Ransomware eine ernstzunehmende Bedrohung, ich bekommen regelmäßig entsprechende Mails mit Dateianhang. Daten, die von diesen Biestern verschlüsselt wurden auf die Cloud zu syncen bedeutet, dass man diese auf der Cloud dann auch vergessen kann. Aber einen Zugriff hat die Ransomware nicht auf die Cloud, jedoch auf z.b. die Verzeichnisse des NAS, die im PC gerade eingebunden sind. Für den Virenfall habe ich Backups via Rsync (eigentlich ein Shellscript), das als Cronjob alle paar Stunden startet und bei manchen Daten sogar mehrere Iterationen in Verzeichnisse wegsichert, auf die nicht per LAN zugegriffen werden kann. Bisher hat es mich nicht erwischt, aber auch hier geht bei Seite 16

17 mir Sicherheit vor. Daten, die ich archiviere, landen in VeraCrypt-Containern, insbesondere wenn es sich um meine Klientendaten handelt. Andere verschlüssele ich unter Nutzung von PGP, damit ich nicht mit Dateicontainern arbeiten muss, die zum Teil recht groß werden könnten, was die Synchronisation auf die Cloud erschwert. Beim Raspberry Pi ist ab 2GB die Grenze, die möglich ist, Owncloud erlaubt ansich deutlich mehr, es wird jedoch unpraktisch, wenn man mit Containern/Dateien in Verbindung mit dieser Hardware in ziemlicher Größe hantiert. Sollte dies aber bei einzelnen Containern sich nicht vermeiden lassen, teile ich die Containerdateien oder auch andere Dateien durch einen Trick auf: Ich generiere mit 7Zip fortlaufende Archive, die sich dann als einzelne Dateien ohne Probleme synchronisieren lassen. Sehr große Dateimengen sollten jedoch nicht am Stück synchronisiert werden, die physischen Grenzen (RAM und damit der PHP-Cache, den man anpassen sollte, siehe div. Anleitungen) des Raspberry Pi sich mit Fehlernachrichten zurückmelden. Wenn man die Erstsynchronisation vornimmt, lässt man dem Ganzen einfach etwas Zeit, das regelt sich dann von selbst, da der Sync, wenn aktiviert, die abgebrochenen Teile wieder aufnimmt, bis alles "passt" und man irgendwann an den zu synchronisierenden Ordnern die Rückmeldung bekommt, dass alles übertragen wurde. Wer mag kann in Owncloud die Verschlüsselung aktivieren, aus meiner Erfahrung heraus ist sie jedoch nicht ganz so ideal auf einem Kleinstsystem, sobald man einige Gigabyte an Daten auf die Cloud synct. Dafür rate ich dann zu einem leistungsfähigeren System. Ich behelfe mir hierbei bei sehr wichtigen Daten mit VeraCrypt bzw. PGP (siehe oben). Seite 17

18 Usern, mit denen ich Daten austausche, gebe ich eine individuelle URL mit Zugriff nur auf die freigegebenen Dateien, ggf. abgesichert mit Passwort und begrenzem Zeitraum für den Zugriff. Useraccounts gibt es auf der Cloud nur bedingt: Meinen und einen weiteren Administrationsaccount. Anderen Personen, wie meinen Supervisandinnen und Supervisanden, bei denen ich deutlich mehr an Daten austauschen muss, begrenze ich die Upload-Kapazität auf 0 (Null), sodass sie nur ihre Daten von dort holen können, nur im Austauschordner, den ich eingerichtet habe und vollen Zugriff habe, Dateien reinladen können. Für weitere Zwecke habe ich noch einen XMPP-Server installiert (Prosody), der nur mich als User hat, um eine individuelle JID (Jabber ID) zu erhalten, die meine berufliche Präsenz wiederspiegelt. Eine private JID habe ich natürlich auch: kalpha@jabber.de (Achtung, keine Mailadresse, wer nicht weiß, was XMPP ist, bitte erst eine Suchmaschine bemühen!). Zur Sprachkommunikation kann man mit mir auf meinem Mumble-Server reden ohne abgehört zu werden. Andrea Widmann, aw@kalpha.de pgp-key: op=get&search=0x129fd ead Seite 18