Hommel-Net Weblog

Vor einiger Zeit habe ich mal einen Tweet gelesen, ich habe ihn auf die Schnelle nicht wieder gefunden. Er ging ungefähr so: "Neue tolle Projektidee für den Raspberry Pi, Hardware bestellt, nie wieder angefasst." Auch bei mir liegen mittlerweile zwei Raspis herum, werden ab und an mal gestartet und mit einer anderen Distro bespielt, aber das wars dann auch schon.

Jetzt hatte ich nach Ostern ein paar Tage Urlaub und war in Bastellaune. Da kam mir die Idee, mit dem etwas ältern RPi Modell B und einer hier ebenfalls schon etwas angestaubten Webcam von Logitech eine Webcam aufzubauen, die ihre Bilder dann auch twittern kann. Eigentlich kein großes Ding, also hab ich mich mal daran gesetzt und das Ergebnis dokumentiere ich hier in dieser kleinen Artikelreihe.

Artikelübersicht

• Teil 1: Der Raspi macht Bilder (dieser Artikel)
• Teil 2: Hallo Twitter
• Teil 3: Wie ist das Wetter?
• Teil 4: Aufbau und fertig

Teil 1: Der Raspi macht Bilder

Wie gesagt nehme ich für das Projekt einen Raspberry Pi Modell B und eine Logitech Webcam.

Als Betriebssystem habe ich zunächst das akutelle Raspbian-Image auf https://www.raspberrypi.org/downloads/ gezogen und auf die obligatorische SD-Karte übertragen. Das neue Image bootet automatisch in den grafischen Modus. Das ist für den späteren Betrieb unnötig. Im Terminal habe ich also zunächst mit

sudo raspi-config

die Konfiguration dahingehend geändert, dass der Raspi nur noch in den Textmodus startet. Bei dieser gelegenheit wurde gleich noch die Sprache, Tastaturlayout und Zeitzone auf deutsche Verhältinisse angepasst.

Damit bin ich auch schon bereit, den ersten Schritt anzugehen, nämlich mit der Logitech Kamera Bilder auf dem Raspi zu produzieren. Die Kamera wurde dazu an einen der beiden USB-Ports angeschlossen. Eine Softwarepaket, dass einfach Bilder mit einer Webcam erzeugt, war mit "fswebcam" schnell gefunden. Das Paket wird einfach mit

sudo apt-get install fswebcam

installiert. Die Nutzung ist denkbar einfach:

fswebcam image.jpg

sucht nach der ersten angeschlossenen USB-Kamera und mach ein Bild, das unter dem angegebenen Dateinamen abgespeichert wird. Dabei wird eine Default-Auflösung von 384x288 genutzt. Die Auflösung kann man über den Parameter "-r" ändern, so erstellt

fswebcam -r 800x600 image.jpg

ein solches Bild:

Wie man sieht, fügt fswebcam dem Bild automatisch ein Banner mit dem aktuellen Datum und der Uhrzeit hinzu (wie bei Webcams durchaus üblich). Dies kann man über den Parameter "--no-banner" aber auch ausschalten. fswebcam hat noch einige Parameter mehr zu bieten, diese kann man sich über die Manpage des Pakets zu Gemüte führen. Ich benötige zunächst nur die oben angegebene Variante für meine Zwecke.

Da das Aufnehmen von Bildern über die Webcam jetzt funktioniert, können wir uns im nächsten Teil der Artikelreihe damit befassen, dem Raspi das Twittern beizubringen.

Die Linuxdistribution Debian führte den beliebten Internetbrowser Firefox bisher aus lizenztechnischen Gründen unter einem eigenen Fork mit dem Namen Iceweasel. Aufgrund der Updatepolitik von Debian wurde der Browser in den Paketquellen der stabilen Version auch nicht mehr auf höhere Majorversionen upgedatet. Debiannutzer, die eine Iceweasel-Version nutzen wollten, die der aktuellen Firefox-Version entsprach, mussten sich mit sogenannten Backports behelfen. Dazu ist die Seite http://mozilla.debian.net die Anlaufstelle. Dort erhielt man bisher nach Eingabe der genutzten Debian-Version und der gewünschten Variante von Iceweasel die Angabe der Paketquellen, die in die /etc/apt/sources.list eingetragen werden musste.

Seit einiger Zeit erzeugt die bisher funktionierende Backports-Adresse für Iceweasel allerdings bei Update einen Fehler. Der Grund hierfür ist, dass die Backports jetzt auf den originalen Firefox umgestellt wurden.

Aus meiner bisher unter Debian Jessie genutzen Paketquelle

deb http://mozilla.debian.net/ jessie-backports iceweasel-release

wird jetzt

deb http://mozilla.debian.net/ jessie-backports firefox-release

Nach der Umstellung kann ich dann mit

$ apt-get update
$ apt-get install -t jessie-backports firefox firefox-l10n-de

die aktuelle Firefox-Version samt deutscher Sprachpakete installieren.

Die nun nicht mehr aktuellen Iceweasel-Pakete habe ich noch mit

$ apt-get remove iceweasel

deinstalliert.

Wer weiter Iceweasel nutzen möchte, kann bis zur aktuellen Stable von Debian die originalen Pakete der Distribution nutzen. Dort wird die ESR38 von Iceweasel noch weiter gepflegt. Einen älteren Backport von Iceweasel weiter zu nutzen ist nicht unbedingt empfehlenswert, da hier natürlich keine Fehler und Sicherheitslücken mehr gefixt werden.

Vor kurzem berichtete ich über den Twitter Client Oysttyer, der aus einem einzelnen Perl-Skript besteht und das Twittern auf einer Textkonsole ermöglicht.

Jetzt gab es ein kleines Update, dass einige Verbesserungen und Fehlerbehebungen mitbringt.

Changes in version 2.6.1:

• Add the ability to share tweets via direct message with the /qdm command (Work towards of 2.7 milestone)
• Use the Twitter account in the prompt instead of oysttyer when showusername is true.
• Add ':large' to Twitter image URLs when largeimages is true.
• Add a space between tweets when doublespace is true.
• Fixed an issue where retweeted tweets displayed the wrong timestamp.
• Fixed an issue where tco were not destroyed in threads
• Display link to video file instead of link to video thumbnail in tweets
• Display video files in /entities
• Bring /entities back into Twitter TOS compliance and make it only open tco links (I.e. make it behave worse. Sorry)
• Add tab expansion for like and retweet (missed from 2.5.1)

Interessant finde ich besonders den neuen Parameter "doublespace", der eine Leerzeile zwischen die einzelnen Tweets zaubert. Das macht den Stream nach meiner Meinung besser lesbar.

So sieht der Stream ohne "doublespace" aus:

Und so mit:

Mir gefällt das so wesentlich besser, weshalb meine .oysttyerrc jetzt so aussieht:

# Die Daten für meine erstellte Twitter-App
oauthkey=XXXXX
oauthsecret=XXXXXX
# Farbe für ansifähige Terminals einschalten
ansi=1
# Neue Zeilen in Tweets erlauben
newline=1
# Nach 120 Zeichen umbrechen (je nach Bildschirmgröße verwenden)
wrap=120
# Pflicht, sonst geht die Twitter-API nicht
ssl=1
# Nutzung des Echtzeit-Streamings
dostream=1
# Beim Start auf neue Version prüfen
vcheck=1
# Leerzeile zwischen den Tweets
doublespace=1

Ich bin gespannt, was die nächsten Versionen von Oysttyer noch so bringen. Zum Updaten wird einfach die aktuelle Version von Github gezogen und die oysttyer.pl mit der neuen Datei überschrieben.

Wie die Entwickler der beliebten Linuxdistribution Mint in ihrem Blog bekannt gaben, kam es zu einem Einbruch in deren Server, wobei die zum Download zur Verfügung gestellten ISOs der Cinnamon Edition kompromitiert wurden. Die Installations-Abbilder enthalten Schadsoftware, die eine Backdoor für Botnetze öffnen.

Laut Chefentwickler Clement Lefebvre sind nur Downloads betroffen, die am Samstag, den 20. Februar 2016 durchgeführt wurden. Besitzer solcher Dateien sollten die im Blogpost angegebenen Checksummen prüfen und, falls mit einem betroffenen Abbild installiert wurde, diese Installation umgehend löschen.

Außerdem wurde das Benutzerforum des Servers ausgelesen. Die Benutzerdaten inklusive verschlüsselten Passwörtern werden bereits zum Verkauf angeboten. Dies hat Zack Whittaker von ZDNET in einem verschlüsselten Chat vom mutmaßlich verantwortlichen Hacker mit dem Pseudonym "Peace" erfahren. Die Erkenntnisse aus dem Chat sind in seinem Artikel bei ZDNET nachzulesen.

Ich bin im Bezug auf Twitter-Clients für den PC sehr experimentierfreudig. Hier ist die Auswahl für Linux-Nutzer nicht so üppig. Schon vor einiger Zeit bin ich hierbei auf das Perl-Skript "TTYtter" gestossen. Das Skript ist ein vollwertiger Twitter-Client für die Textkonsole. Leider hat der Entwickler die aktive Arbeit an TTYtter in 2012 beendet, dennoch war und ist das Skript noch nutzbar.

Erfreulicherweise hat sich jetzt ein neues Opensource Projekt der Sache angenommen und mit Oysttyer einen Nachfolger veröffentlicht, der jetzt auch aktiv gepflegt wird und neue Twitter-Features einbindet.

Die Installation besteht daraus, das Skript auf den lokalen Rechner zu kopieren und mit "perl ./oysttyer.pl" zu starten. In einer "~/.oysttyerrc" kann man Voreinstellungen für das Skript festlegen, diese können aber auch während der Laufzeit gesetzt und geändert werden.

Meine .oysttyerrc sieht zum Beispiel so aus:

# Die Daten für meine erstellte Twitter-App
oauthkey=XXXXX
oauthsecret=XXXXXX
# Farbe für ansifähige Terminals einschalten
ansi=1
# Neue Zeilen in Tweets erlauben
newline=1
# Nach 120 Zeichen umbrechen (je nach Bildschirmgröße verwenden)
wrap=120
# Pflicht, sonst geht die Twitter-API nicht
ssl=1
# Nutzung des Echtzeit-Streamings
dostream=1
# Beim Start auf neue Version prüfen
vcheck=1

Die Entwickler empfehlen zur Zeit, eine eigenen Anwendungskey für Oysttyer zu erstellen, da der mitgelieferte Key von Twitter öfter gesperrt wird. Das ist aber schnell erledigt und dürfte für die Zielgruppe (Terminal-User) kein Problem darstellen. Beim ersten Start erfolgt die Autorisierung mittels OAuth, die auch bekannt sein dürfte.

Nach dem Start wird die Timeline angezeigt und in Realtime aktualisiert, wenn man den obigen Parameter gesetzt hat. Jeder Tweet bekommt einen "Menücode", der dann als Platzhalter für den Tweet in den Befehlen dient.

g9> <apfelnase> #DoctorWho #JETZT!

Nach dem Menücode (hier "g9") sieht man das Twitter-Handle des Autors und danach den Tweet-Text. Vor dem Twitter-Handle können noch spezielle Zeichen stehen, die bestimmte Tweetarten anzeigen.

d4> <%heartcrazed> RT @gerritvanaaken: Über „Design“ gebloggt: http://praegnanz.de/weblog/designer-artikel-ueber-design-artikel

Der Autor hat etwas retweetet (% vor dem Twitter-Handle), wen und was folgt dann.

d7> <+mspro> das neuerliche „comeback“ der newsletter verdankt sich reiner dreistigkeit.

Der Tweet enthält Geo-Daten (+ vor dem Twitter-Handle), die über den Befehl /du <Menücode> abgefragt werden können.

b4> <"SirTomate> Nicht mitmachen. Ich will die Minidrone haben. 
   https://twitter.com/Pixelaffe/status/690803220487213056
b5> (x2) <↑Pixelaffe> Nur noch wenige Tage - Verlosung: Alcatel OneTouch Go Play + Parrot Airborne Cargo Drohne -
   http://bit.ly/1PfguKI https://pbs.twimg.com/media/CZY53mrXEAAq12T.png

Das ist so ein neumodischer Retweet mit Kommentar, zu erkennen am " vor dem Twitter-Handle und danach der kommentierte Tweet im Wortlaut, mit dem ↑.

d1> <+@uniwave> Oder auch so. https://pbs.twimg.com/media/CZZ519UW0AEZAPN.jpg

Am @ vor dem Twitter-Handle erkennt man, dass es sich um einen Antwort-Tweet handelt. Den ganzen Thread sieht man mit /th <Menücode>.

Erstmal ist alles, was man im Terminal tippt und mit <Enter> abschliesst, ein Tweet. Eine neue Zeile innerhalb eines Tweets erhält man mit \n. Ausnahme ist die Eingabe von Befehlen, die immer mit einem "/" beginnen. So gibt "/help" eine kurze Befehlsreferenz mit den wichtigsten Kommandos aus.

Die Befehle decken so ziemlich alle Funktionen ab, die man in Twitter so braucht. Follower- und Listenmanagement sind kein Problem. Retweeten, Liken, Replien und DMs funktionieren prima, sogar das relativ neue kommentierte Retweeten funktioniert.

Die Suchfunktion ist über /search zu erreichen. Außerdem kann man bestimmte Suchbegriffe (respektive Hashtags) mittels /tron oder /troff in die Timeline einspielen oder wieder entfernen.

Das ganze ist natürlich schon etwas nerdig, aber macht Spaß und ist eine gute Alternative, wenn man gern am Terminal arbeitet. Natürlich werden in der Timeline keine Bilder angezeigt. Diese, wie auch Links zu Internetseiten müssen mit externen Tools aufgerufen werden. So kann man zum Beispiel in "Konsole", dem Terminal der KDE Umgebung mit einem Rechtsklick auf einen Link diesen im Browser öffnen. Alternativ ruft /url <Menücode> alle Links des Tweets im Standardbrowser der Umgebung auf (das könnte auch der Textbrowser Lynks sein).

Neben dem interaktiven Modus kann Oysttyer auch im Skripting-Modus genutzt werden, so kann man zum Beispiel mit "perl ./oysttyer.pl -status "Dies ist ein Tweet."" einen Tweet absetzen. Das eröffnet natürlich noch mehr Möglichkeiten, das Perlskript zu nutzen.

Die Dokumentation des Oysttyer-Projekts ist noch etwas dünn. Allerdings kann man immer noch die alte Dokumentation von TTYtter nutzen, die auch mit Oysttyer noch funktioniert.

Was meint ihr, ist so ein textbasierter Client noch zeitgemäß oder doch nur Nerdstuff?

Wer einen Rootserver - egal ob es eine physische oder virtuelle Maschine ist - im Internet betreibt, muss sich Gedanken um dessen Absicherung machen. Früher oder später kommt man dann auch an den Punkt, wo man entscheiden muss, ob man einen Paketfilter wie Iptables auf seinem Server konfigurieren soll. Hier gibt es unterschiedliche Meinungen im Netz, ob das sinnvoll ist oder nicht. Schauen wir die Argumente doch mal an.

Gründe, warum man keinen Paketfilter auf dem Rootserver benötigt

Auf einem Rootserver gibt es normalerweise nur ein Netzwerkinterface, dass nach außen auf das Internet routet. Daneben haben wir immer noch das lokale Interface, dass nur intern auf dem Rechner erreichbar ist. Auf dem "klassischen" Rootserver sollen Dienste, die man installiert, in der Regel auch vom Internet erreichbar sein. Auf Ports, die nicht erreichbar sein sollen, sollte auch kein Dienst erreichbar sein. Ein Beispiel ist der Webserver, der natürlich vom Internet erreichbar sein soll. Das Datenbankbackend sollte aber nur vom Webserver auf dem internen Interface erreichbar sein. Wenn also alle Dienste auf dem Server korrekt installiert sind, macht ein Paketfilter keinen wirklichen Sinn. 

Ein Schutz gegen DDOS-Angriffe oder ein Lastverteilung muss immer auf den Routern vor dem Rootserver laufen, um zu funktionieren. Also ist auch dies kein Grund für eine Iptables auf dem Server selbst.

Szenarien, in denen ein Paketfilter Sinn macht

Zunächst einmal kann man den Paketfilter als "Sicherheitsnetz" betreiben. Wenn man mal einen Dienst, der eigentlich nur auf der internen Schnittstelle erreichbar sein soll, falsch konfiguriert, wäre er dann aufgrund den dann nicht freigeschalteten Ports eben nicht erreichbar und die Fehlkonfiguration hätte keine Auswirkungen auf die Sicherheit des Servers. Außerdem könnte ein installierter Dienst eine Sicherheitslücke haben, durch die ein Angreifer einen Dienst im Benutzerkontext etablieren könnte, der dann von außen erreichbar ist und entsprechend ausgenutzt werden könnte. Ein Paketfilter würde so etwas verhindern.

Dann gibt es noch einige spezielle Szenarien, die einen Paketfilter nötig machen. So wäre zum Beispiel ein Portknocking möglich, bei dem ein Dienst erst erreichbar ist, nachdem man auf einem anderen nicht bekannten Port "angeklopft" hat.

Fazit

Grundsätzlich macht ein Paketfilter auf einem Rootserver erstmal keinen Sinn. Zur Absicherung von Fehlkonfigurationen oder Folgen von Angriffen auf erreichbare Dienste kann Iptables aber durchaus Sinn machen und genutzt werden. Für einige spezielle Aufgabenstellungen wird der Paketfilter sogar explizit benötigt. Jeder Betreiber eines Rootservers sollte die Notwendigkeit also selbst beurteilen und eine entsprechende Konfiguration einsetzen.

Habt ihr einen Rootserver in Betrieb? Wie sieht es bei euch mit dem Betrieb eines Paketfilters aus. Gibt es Szenarien, die ich nicht angesprochen habe? Lasst es mich in den Kommentaren wissen.

Ein eigener Server im Internet ist dank der Virtualisierungstechnik relativ erschwinglich geworden. Eine solche virtuelle Maschine bietet viele Vor- aber auch Nachteile.

Größter Vorteil: Ich habe Rootrechte und kann alles installieren was ich möchte.

Größter Nachteil: Ich habe Rootrechte und kann alles installieren was ich möchte.

Spaß beiseite, ob man einen eigenen Server betreiben will, bei dem ich mich um alles kümmern muss, (Absicherung, Updates, Konfiguration usw.) und das eigentlich immer, auch wenn ich eigentlich im Urlaub bin, muss man sich gut überlegen. Aber dazu gibt es einige gute Artikel im Netz, zum Beispiel hier.

Der Hosting- und Server-Anbieter Linevast hat mir einen ihrer Linux vServer in der "Starter" Variante zur Verfügung gestellt und ich habe die virtuelle Maschine ein paar Wochen getestet.

Einrichtung und Ausstattung des Servers

Die Einrichtung des Servers ist denkbar einfach. Nachdem man einen Benutzer-Account erstellt hat, kann man den gewünschten vServer buchen und er steht einem dann im eigenen Kundenbereich im Dashboard für weitere Konfigurationen zur Verfügung. So bietet Linevast zum Beispiel einen DDOS-Schutz als zusätzliche Leistung an. Der Starter-Server ist mit 2 CPU, 1GB Hauptspeicher und 30 GB Festplattenplatz ausgestattet. Man bekommt eine V4-IP sowie ein 64er IPV6 Netz. Domains und DNS können verwaltet werden, sind aber natürlich auch über externe Anbieter möglich.

Als Konfigurationsplattform kommt bei Linevast SolusVM zum Einsatz, das Panel ist übersichtlich und verständlich. Es bietet die wichtigsten Funktionen zur Verwaltung der virtuellen Maschine auf einen Blick.

Betriebssystem

Man hat die Auswahl zwischen sechs Linuxdistributionen in verschiedenen Versionen. Debian, CentOS, SuSE, Ubuntu, Fedora und Scientific stehen zur Auswahl. Auf meinem vServer habe ich das standardmäßig installierte Debian 7 64bit belassen und damit getestet. Das Betriebssystem wird in einer sehr kleinen Paketauswahl installiert, was ich persönlich sehr angenehm empfinde, denn man schleppt dann keinen unnötigen Ballast mit herum. Als Webserver ist allerdings bereits ein Apache betriebsbereit installiert, so dass ein Aufruf der IP-Adresse im Browser die Apache "It Works!" Seite zeigt.

Erste Konfigurationsschritte

Der Server ist selbstverständlich über SSH erreichbar. Allerdings ist in der Standardinstallation der Root-Login über ein Passwort möglich. Dies ist natürlich als Erstes anzupassen. Man sollte sich halt immer vor Augen halten, dass es sich bei einem virtuellen Server um ein Produkt handelt, bei dem man von Anfang an die komplette Verantwortung für die Sicherheit des Systems hat. Hier stellt der Anbieter die Plattform zur Verfügung und ist dann eigentlich "raus aus der Nummer".

Der Apache ist wie oben schon erwähnt bereits startklar in der Grundkonfiguration von Debian installiert. Als Mailer ist sendmail installiert und nachdem man seiner IP-Adresse einen Rechner/Domain-Namen verpasst hat, ist auch die Mailzustellung an andere Mailserver problemlos möglich. Auch hier ist die Grundkonfiguration von Debian natürlich an die eigenen (Sicherheits-)Bedürfnisse anzupassen oder natürlich ganz nach Geschmack auch ein anderer Mail-Server zu installieren.

Webserver und Blog

Eine der ersten Tests war natürlich der Betrieb als Webserver. Hierzu habe ich noch den MySQL-Server und PHP-Unterstützung installiert, um natürlich sofort ein Serendipity-Testblog aufzusetzen.

Das war in wenigen Minuten erledigt und der Testblog läuft auf der virtuellen Maschine sehr flüssig.

Problemfall VPN und der Support

Die nächste Aufgabe war, einen VPN-Server für die persönliche Nutzung aufzusetzen. Es ist ja immer ganz nützlich, wenn man unterwegs mit dem Smartphone mit einem vertrauenswürdigen VPN verbunden ist. Mitnutzer desselben Hotel-WLANs oder Hotspots können dank der Verschlüsselung nicht mithören. Ein VPN-Server auf dem Router daheim hat immer den Nachteil eines eventuell langsamen Upstreams und so ist natürlich so ein vServer mit einer schnellen Internetanbindung in beide Richtungen eine feine Sache.

Bei der von mir geplante Nutzung von Strongswan mit IKEV2 stieß ich jedoch auf einige Probleme, so dass ich auch Gelegenheit hatte, den Support von Linevast zu testen. Der Support ist über ein Ticketsystem in der Benutzer-Konsole realisiert. Ich bin sehr angetan von den raschen und kompetenten Hilfestellungen, die ich bekommen habe. So wurden Fragen im Ticket auch noch spät Abends und teilweise auch auch Wochenende beantwortet.

Das Problem war, dass die VPN-Verbindung zwar geklappt hat, aber der Datenverkehr ins Internet nicht mehr zurück an die virtuelle IP meines Smartphones genattet wurde. Nachdem vom Support noch einige Firewall-Einstellungen versucht wurden und es immer noch nicht geklappt hat, war die Lösung schließlich ein Problem von Strongswan im Zusammenspiel mit der OpenVPS-Implementierung, mit der die vServer bei Linevast realisiert sind. Mit Hilfe des Supports habe ich dann auf OpenVPN gewechselt und das funktioniert jetzt ganz wunderbar (mit dem kleinen Wehrmutstropfen, dass mein BlackBerry Z30 kein OpenVPN unterstützt, aber mit anderen Geräten ist das kein Problem).

Ich fand es toll, wie der Support mit mir zusammen nach Lösungsmöglichkeiten gesucht hat, die Kontakte mit den einzelnen Mitarbeitern waren sehr angenehm. Sehr empfehlenswert!

Leistung

Die Leistung des vServers ist im Testbetrieb wirklich sehr ordentlich. Natürlich kann ich nicht sagen, wie es bei einer großen Besucheranzahl auf dem Webserver aussehen würde. Die Produktbeschreibung auf der Webseite von Linevast empfiehlt den Starter-Server für kleine bis mittlere Projekt und nach meinem Gefühl nach den Tests ist das durchaus eine realistische Angabe.

Fazit

Wie ich zu Anfang schon erwähnt habe, ist ein vServer eine günstige Möglichkeit, einen eigenen Root-Server zu betreiben, wenn man die Möglichkeiten eines solchen Produktes braucht und auch beherrschen kann. Für den einfachen Betrieb einer Webseite mit einem Blog wäre ein virtueller Server sicherlich etwas oversized. Für den ambitionierten Admin ist der Starter Server durchaus einen Blick wert. Der Service hat in den Testwochen prima funktioniert, ich habe (bis auf einen kurzen Ausfall am Anfang der Testzeit durch einen defekten Switch) keine Ausfälle des Servers bemerkt. Der Support ist sehr kompetent, freundlich und schnell, was ich übrigens mit als eine der wichtigsten Merkmale eines Hosting- und Serveranbieters sehe.

Linevast hat eine breite Produktpalette von Hosting bis zum Root-Server. Wenn ihr gerade einen Anbieter für ein neues Projekt sucht, schaut doch mal vorbei, ob etwas für euch dabei ist.

Ich habe auf meinem Kubuntu über Virtualbox eine virtuelle Maschine mit Windows 7 laufen. Dieser wollte ich auch das kostenlose Update auf Windows 10 spendieren. Leider gab das Prüftool von Microsoft den Fehler aus, dass die (virtuelle) Grafikkarte nicht kompatibel zu Windows 10 sei und verweigerte das automatische Upgrade.

Zum Glück gibt es ja das Internet und nach einigem Stöbern fand ich die Lösung. Man kann über das MediaCreation-Tool von Microsoft das Update manuell durchführen, was ich dann auch mit Erfolg getan habe.

Und hier ist die ausführliche Anleitung von "Der Tutonaut", die ich gefunden und genutzt habe:

Tipp: Hardwareprüfung beim Windows 10-Upgrade umgehen

Vielen Dank an Christian Rentrop für diesen Tipp.

Und noch eine Neuerscheinung bei den Linuxdistributionen. Nach Ubuntu und diversen Derivaten hat das Debian-Team die neue Version 8 mit dem Codenamen "Jessie" freigegeben.

Neben der Aktualisierung der enthaltenen Software-Pakete dürfte der Wechsel auf das Init-System systemd die größte und umstrittenste Änderung sein. Zusammen mit dem Debian LTS-Projekt vespricht man außerdem, die Version für 5 Jahre mit Sicherheitsupdates zu versorgen. Bisher gab es für Debian-Versionen keine festen Lebenszyklen. Eine Version wurde nach Erscheinen des Nachfolgers immer noch für ein Jahr aktualisiert, danach war Schluss.

Einen guten Startpunkt, um sich einen Überblick über Debian 8 zu verschaffen, ist die Seite mit der Ankündigung des Projekts.

Ich selbst nutze Debian auf einigen Servern, wo ich mir mit dem Update noch etwas Zeit lassen werde. Außerdem nutze ich Debian noch auf meinem Uralt-EEE-PC, wo ich heute schon mal gleich aktualisiert habe und bisher keine Probleme feststellen kann.

Quasi zeitgleich zur "Mutter"-Distribution ist heute auch die KDE-Variante von Ubuntu in der neuen Version 15.04 erschienen. Die auffälligste Änderung dürfte der Wechsel zur Plasma 5 Plattform sein, die ein komplett überarbeitetes Design bietet und ein "flüssigeres" Arbeiten ermöglichen soll.

Den ein oder anderen mag das geänderte Design an das neue Windows 10 erinnern. Die Icons sind jetzt auch im allseits zu sehenden Flat-Design und nicht mehr so bunt wie in früheren Versionen von KDE.

Eine Zusammenfassung der Neuerungen erhält man auf kubuntu.org.

Im folgenden Video gibt es einen ersten Eindruck über die neue Oberfläche, die sicher Geschmacksache ist und die Geister wieder scheiden wird.

Ich weiss noch nicht so recht, was ich davon halten soll. Da ich momentan die LTS-Version 14.04 nutze, werde ich meinen Hauptrechner erstmal nicht updaten. Ich werde die 15.04 aber mal intensiv in einer virtuellen Maschine testen. Wie gefällt euch das neue Aussehen des KDE-Desktops unter Plasma 5?