Crashplan auf Windows Homeserver (WHS) installieren

Seit langem bin ich auf der Suche nach einer Off-Site Backup Lösung, die preislich noch im Rahmen ist, aber gleichzeitig auch relativ große Datenmengen erlaubt. Letzteres ist bei nahezu allen “einfachen” Diensten wie Dropbox, OneDrive, iCloud usw. nicht gegeben, da dort eher im Bereich GB bis wenige TB gearbeitet wird. Als Fotograf mit sehr vielen und leider auch sehr großen RAW Files stoße ich da relativ schnell an die Grenzen. Hinzu kommt die Einschränkung, dass ich meine Daten auf einem Windows Homeserver liegen habe, der auch gleichzeitig das zentrale Backup übernehmen soll. Mit Crashplan bin ich fündig geworden – es gibt einen “unlimit” Backup für 60€ im Jahr – und der Client läuft auch unter Windows Homeserver. Andere Anbieter blockieren sofort, wenn sie merken, dass der Client auf einer “Serverversion” von Windows läuft. Crashplan glücklicherweise nicht.

Zurück zum Thema. Ich hab den Client installiert und es passiert nichts. Der Dienst besteht aus zwei Teilen: einer Backup Engine und der Gui. Die Gui sagte mir einfach nur, dass sie die Backup Engine nicht finden könne. Ein Blick in den Dienste Manager von Windows zeigte mir, dass der Service auch nicht lief. Wenn man ihn starten wollte, kam nur die Meldung, dass der Dienst “gestartet und anschließend gleich wieder gestoppt/pausiert wurde. Keine weiteren Hinweise oder Logs. Nach etwas Recherche im Netz fand ich zumindest Hinweise, dass es wohl Probleme mit den Portbelegungen gibt – aber bei mir wollte ja der Dienst nicht mal starten. Die Lösung war dann doch etwas simpel: Der Client verbraucht per Default mittlerweile 1GB Ram – und das hat mein Acer Aspire easyStore H340 mit seinen 2GB Ram scheinbar nicht mehr übrig. Also editiert man in der Datei “c:\Programme\CrashPlan\CrashPlanService.ini” die Zeile mit den Java Virtual Machine Parameters:

von

-Xmx1024M

in

-Xmx512M

Und schon läuft der Service, sobald man ihn nochmal startet. Aber der Client wollte noch immer nicht – und da kam die eben genannte Port Problematik zum Vorschein. Um dies nachvollziehen zu können, ruft man die Command Shell von Windows auf und gibt da folgendes ein:

netstat -ona

Bildschirmfoto 2016-05-08 um 14.28.37 Kopie

Wie man sieht, lauscht die Backup Engine auf Port 4242, der Port im Client ist per Default jedoch 4243. Wenn man nun in der Datei “c:\Programme\CrashPlan\conf\ui.properties” die folgende Zeile editiert, läuft es:

#servicePort=4243


in

servicePort=4242

Abschließend startet man nun den Client und wird endlich von der Crashplan Oberfläche empfangen 😉

[Quicktip] Hosts Datei unter Windows 7 wird ignoriert

Durch solche Probleme werde ich immer wieder erinnert, warum ich einen Mac und keine Windows Kiste verwende. Aber egal 😉

Die Hosts Datei eines Windows Systems befindet sich ja bekanntlich unter C:\Windows\System32\drivers\etc\hosts – eine direkte Bearbeitung ist so nicht möglich, da dafür Administratorrechte benötigt werden. Hinzu kommt, dass der Windows Editor so intelligent ist eine keine Dateien ohne Endung zulässt. Mittlerweile wird die Endung einfach nicht mehr angezeigt, sie ist aber trotzdem da 😉

Aber nun die einfache Möglichkeit, wie es funktioniert:

  • Im Startmenü nach “Editor” suchen und das Ergebnis mit rechts anklicken und “Als Administrator ausführen” auswählen.
  • Datei – öffnen und dort den Pfad C:\Windows\System32\drivers\etc\ heraussuchen (beim Filter “alle Dateien” auswählen nicht vergessen)
  • Hosts Datei auswählen
  • eure Änderungen durchführen
  • originale Hosts Datei löschen
  • im Editor “speichern unter” wählen und prüfen, ob ihr noch im richtigen Pfad seid. Im Filter wieder “alle Dateien” auswählen und als Dateiname hosts wählen und auf speichern klicken
  • nun im Explorer prüfen, ob beim Dateityp der Hosts Datei “Textdatei” steht – das war bei mir der Fall
  • wenn dem so ist, die cmd Box auch als Administrator starten, in den Pfad wechseln und ein “rename hosts.txt hosts” ausführen.
  • fertig.

[Quicktip] git per Samba Share zeigt alle Dateien als “geändert” an

Nehmen wir folgende Konstellation: Du hast einen Linux Server, der einen Ordner per SMB (Samba, Windows Freigabe) Share freigibt, in dem sich git Repositories befinden. Greifst du nun von einem anderen Rechner auf diese Dateien zu, so wird git alle Dateien innerhalb dieses Repositories als geändert anzeigen. Ein git diff zeigt dann z.B. folgendes:

old mode 100644
new mode 100755

Dies bedeutet nichts anderes, als dass sich die Zugriffsrechte der Dateien geändert haben. Innerhalb der Samba Share Konfiguration kann man diese Rechte (also Zugriff für Benutzer, Gruppe, Alle) regeln. In vielen Fällen wird sich diese Konfiguration von der in git eingecheckten unterscheiden. Um das Problem zu umgehen, gibt es nun folgende Möglichkeiten:

– im Samba Share Config File die Dateirechte korrekt setzen
– innerhalb des git Repositories folgenden Parameter setzen bzw. umstellen:

git config core.filemode false

Bitte beachten: Wenn dieser Parameter gesetzt wird, kann man KEINE Änderungen von Dateirechten in git committen!

Wollt ihr dies auf eurem Rechner global für alle Repositories machen, dann verwendet folgenden Befehl:

git config --global core.filemode false

Bitte hier besonders daran denken, dass nun in ALLEN git Repositories, auf die dieser Rechner zugreift, kein Committen von Änderungen an den Dateirechten möglich ist – es sei denn, der Parameter wird in einzelnen Repositories explizit überschrieben.

[Quicktip] VMWare Images in VirtualBox importieren / konvertieren

Glücklicherweise unterstützt Virtualbox seit Version 2.1.0 nativ VMWware VMDK Dateien – also die Festplatten-Images von VMWare. Die Vorgehensweise ist folgende: man erstellt eine neue virtuelle Maschine mit Virtualbox. Wenn man gefragt wird, ob man eine neue Festplatte erstellen möchte oder bereits eine hat, wählt man letzteres. Anschließend wählt man einfach die VMDK Datei des VMWare Systems aus und bestätigt.

Das Problem ist nun: macht man dies bei einem Windows-Gastsystem und fährt es anschließend hoch, so wird man wahrscheinlich einen Bluescreen bekommen. Das Problem: VirtualBox verwendet in der Standardeinstellung scheinbar inkompatible Treiber für den Festplatten Controller.

Und hier gibt’s die Lösung für das Problem:

Die Settings der VM aufrufen und prüfen, ob folgende Einstellungen wie auf den Bildern zu sehen, gesetzt sind.

Anschließend fügt ihr die VMWare VMDK beim IDE Controller als Festplatte hinzu – falls die Platte bereits beim SATA Controller eingebunden ist, entfernt ihr sie dort wieder.

Anschließend die VM hochfahren und Windows sollte problemlos starten.

Windows Bluescreens speichern bzw. im Nachgang auswerten

Manchmal, aber auch wirklich nur manchmal, setze ich mich vor eine Windows Kiste. Und was passiert dann auch ab und zu? Genau: es kommt ein Bluescreen. Nun hat Windows die tolle Eigenschaft, einen Bildschirmfüllenden Bluescreen für ca. 0,5 Sekunden anzuzeigen und dann den Rechner neu zu starten. Sehr hilfreich!

Sollte man das Glück haben, dass noch ein Speicherabbild erzeugt wird, so hat man ggf. genug Zeit, sich den Text doch anschauen zu können. Und was erhält man? Kryptische Fehlercodes, mit denen kein Mensch etwas anfangen kann.

Doch es gibt Abhilfe: BlueScreenView!

Screenshots und weitere Daten zum Bluescreen

Bluescreenview analysiert die Fehlerberichte von Windows, welche während eines Absturzes erzeugt werden. Anschließend zeigt es die einzelnen Berichte an, und – jetzt kommt’s – listet auch gleich die betroffenen Dateien auf. Sicher hilft das eurer Mutter, die vor ihrem PC verzweifelt, nicht weiter – aber ihr könnt Fehler so auch noch im Nachgang erkennen.

Fairerweise muss man sagen, dass spätestens seit Windows Vista Bluescreens nur durch Software bzw. Treiber von Drittanbietern erscheinen. Mit Bluescreenview könnt ihr die betroffenen Dateien schnell herausfinden und das Problem hoffentlich lösen.

Und das beste kommt am Schluss: das Tool ist kostenlos!

Links
BlueScreenView

F.Lux – und dein Rechner schont deine Augen

Seit einiger Zeit bin ich fleißiger Hörer der Nerdtanke, einem Podcast von Nerds für Nerds. In Folge 4 wurde ein Tool vorgestellt, welches die Bildschirmfarben eures Rechners an den aktuellen Stand der Sonne anpasst: F.Lux.

Was passiert da genau?
F.Lux prüft per Geolocation, an welchem Ort ihr euch befindet, wodurch die Zeit des Sonnenuntergangs bestimmt werden kann. Ist die Sonne untergegangen, dann ändert die App die Farbtemperatur (ist einstellbar, ich empfehle “Fluorescent”) eures Monitors in wärmere Farben. Dies geschieht entweder innerhalb von 20 Sekunden, oder einer Stunde. Dabei wird die Temperatur langsam gefadet, sodass die Augen sich daran gewöhnen können.

Was bringt das?
Die App Beschreibung sagt folgendes: Obwohl die Sonne am Abend untergeht, schauen wir, wenn unser Monitor mit normalen Farben betrieben wird, Abends in eine weitere Sonne. Dadurch denkt der Körper, dass die Sonne weiterhin scheint und kommt schlechter zur Ruhe – was in schlechtem Schlaf enden kann. Verwendet man F.Lux, erlebt man eine natürliche Abendröte bzw. angenehmere Farben und kann somit besser schlafen.

Sagen wir es mal so: ich hab nicht viel von der Erklärung gehalten. Allerdings muss ich sagen: Das Tool bringt wirklich was. Nach einer Woche Betrieb hab ich es testweise mal deaktiviert und hab bald einen Schock bekommen, wie grell das Bild auf einmal war. Natürlich kann man die Monitorhelligkeit anpassen, was aber nicht so viel bringt wie diese App. Probiert’s einfach mal aus.

ACHTUNG: Falls ihr in den Abendstunden Fotobearbeitung betreiben wollt, sollte das Tool natürlich nicht aktiv sein, weil ihr sonst Farben mit einem Rotstich habt. Dafür gibt’s einen eigenen Menüpunkt – und die Farbtemperatur wird für eine Stunde wieder auf “normal” gestellt.

Sehr geiles weiteres Feature: solltet ihr ein iPhone mit Jailbreak betreiben, so gibt es die App dafür auch im Cydia Store. Sonst gibt es Versionen für Mac, Windows und Linux.

Links
Nerdtanke
F.Lux

[Quicktip] Ruhezustand in Windows 7 aktivieren

Da ich einer von (hoffentlich) vielen Menschen bin, der bei Nichtbenutzung seine Technik vom Strom trennt, bringen mir Standbymodus oder “Hybrider Ruhezustand” von Windows 7 nicht viel. Ich möchte einfach den aktuellen Zustand meines Rechners speichern und den Rechner komplett ausschalten können. Unter Windows 7 finde ich aber nur das hier:

Der normale Ruhezustand, wie man ihn z.B. von Windows XP kennt, macht genau das. Er speichert den kompletten Arbeitsspeicher auf die Festplatte und schalten anschließend den Rechner aus. Wenn man ihn wieder einschaltet, wird der vorherige Zustand wieder hergestellt und man kann normal weiter arbeiten. Gerade wenn man intensive Arbeitsumgebungen wie z.B. Entwicklungsumgebungen und Emulatoren am Laufen hat, kann man sich somit lange Startzeiten sparen.

Um diesen altbekannten Ruhezustand unter Windows 7 wieder zu aktivieren, ist folgendes nötig:

Anschließend finden wir den alten Ruhezustand wieder im “Herunterfahren” Menü:

Betriebssystem auf Werkseinstellungen zurücksetzen

Gerüchten zu Folge soll genau diese Funktion in Windows 8 verfügbar sein. Nach einem ersten Stutzen finde ich die Funktion mittlerweile richtig cool – und warum soll man ein nützliches Feature aus der Handy-Welt nicht auch auf den PC übertragen können.

Klar gibt es Backuplösungen (wie z.B. Timemachine) oder auch die Windows Systemwiederherstellungspunkte, mit denen ähnliches erreicht werden kann. Nur hat dies den Nachteil, das man zusätzlichen Speicher dafür benötigt.

Eine allgemeine “System zurücksetzen” Funktion würde sämtliche Einstellungen und Apps einfach entfernen. Und wer weiß am besten, welche Einstellungen Standard sind? Genau, das Betriebssystem selbst. Trotzdem sollen auf Wunsch Nutzerdaten nicht betroffen sein. In diesem Fall wird es spannend, die Umsetzung zu sehen. Aber wenn das Feature sauber aufgesetzt ist, dann würde ich, sofern ich Windows-Nutzer wäre, ab und zu mal einen Reset durchführen. Schon alleine aus Angst, mir doch irgendwann mal nen Trojaner oder eingefangen zu haben, den das Antivirenprogramm nicht kennt.

Was haltet ihr von einer solchen Funktion? Überflüssig oder sinnvolles Feature?

via golem.de

Nokia & Microsoft – eine neue große Liebe?

Letzte Woche haben die beiden strauchelnden Giganten nun das Unglaubliche getan: eine Kooperation. War Microsoft selbst nie Hardwarehersteller, wenn es um Mobiltelefone ging, so hatte Nokia sowohl Hardware als auch Software inne.

Doch kommen wir erstmal zu Microsoft. Der Konzern hatte im Verlauf seiner mobilen Geschichte vier große Fehler begangen: fehlende Hardwarerestriktionen, Overlays, fehlende Updatepolitik und die Apps.
Am Beispiel der Hardwarerestriktionen bemerkt man, dass viele noch nicht aus diesem Fehler gelernt haben, und so ist es kein Wunder, dass die eigentlich super innovative Plattform Android zum Scheitern verurteilt ist, da es schlicht zu viele Geräte und Hersteller gibt. Jeder kocht sein eigenes Süppchen, legt irgendwelche Overlays über die eigentliche Oberfläche (Stichwort “HTC Sense”) und lässt eines außen vor – den Benutzer. Denn so schön diese Aufhübschungen auch alle sein mögen, sie haben den Nachteil, dass man sie pflegen muss. Beim alten Windows Mobile war das nicht das große Problem, denn ein Großteil der Geräte erhielt nie ein Update auf eine neuere Version des Betriebssystems. Android wirbt aber z.B. genau mit diesem Feature und hat nun den Nachteil, dass Updates zwar vorhanden sind, diese von den Herstellern aber nicht verteilt werden.

Aber wir wollen nicht über Android sprechen, sondern Windows. Microsoft hat bei Mobiltelefonen/Smartphones den Kardinalsfehler begangen, dem Benutzer weis machen zu wollen, dass er ein Handy und keinen Computer in der Hand hält. Das stimmt bei Smartphones so aber nicht, denn es handelt sich hier eher um einen Computer mit Telefonfuktion. Die Plattform hätte wesentlich erfolgreicher sein können, wenn man hier immer wieder neue Features und Funktionen gebracht hätte. Scheinbar hat niemand das Potential von Smartphones erkannt, aber in solchen Sachen war Microsoft ja bekanntlich noch nie so wirklich fit – siehe Arbeitsspeicher oder Internet.

Aber das wirklich traurige ist, dass sie ihre Pole-Position verschenkt haben. Windows Mobile hatte, im Gegensatz zu allen anderen mobilen Betriebssystemen, bereits sehr früh die Möglichkeit, Apps herunterzuladen und zu installieren. Zum einen musste man sich diese Apps aber manuell im Netz suchen und auch manuell installieren, zum anderen war aber auch auf Seiten der meisten Benutzer nicht wirklich ein Interesse vorhanden, diese Möglichkeit zu nutzen. An dieser Stelle kann man mal wieder sehr schön sehen, wie Apple bereits vorhandene Funktionen einfach nur neu verpackt und daraus ein Erfolgsprodukt werden lässt.

Nokia dagegen ist den Jungs von Apple wesentlich ähnlicher – man fertigt sowohl die Hardware als auch die Software. Diese Kombination ist, und das hat Apple gezeigt, das einzig ware – sowohl bei PCs, als auch bei Tablets oder Handys. Man kann beide Teile des Produktes einfach perfekt aufeinander abstimmen. Doch, anders als viele der heutigen Hersteller von Mobiltelefonen, machen “normale” Handys einen Großteil der Produktpalette von Nokia aus. Smartphones wurden immer als kleine Sparte angesehen, was sich nun als riesiger Fehler herausstellt. Denn es wurde sowohl das Potential von Smartphones, als auch die Konkurrenz unterschätzt – sehr schön sind Aussagen von Nokia, Apple wisse ja gar nicht wie man Handys baue. Das sie dies sehr wohl wussten und auch noch nebenbei den Smartphones zum Durchbruch in den Mainstream verholfen haben, hat dann wohl die ganze Branche schockiert.

Aber kommen wir zurück zu Nokia. Die Jungs aus Finnland waren eigentlich sehr innovativ und haben mit Symbian eine interessante, performante und vor allem sehr akkuschonende Plattform verwendet, um ihre Smartphones zu platzieren. Ich hatte selbst mehrere Geräte von Nokia in Verwendung und war immer zufrieden, jedoch merkte ich schnell, dass der Horizont mit diesem System noch lange nicht erreicht war. Man merkte Symbian einfach an, dass da noch was fehlt. Was genau kann ich nicht sagen, es war einfach eine Gefühlssache. Letztendlich hat sich das System genauso wie ein “normales” Handy mit ein paar mehr Funktionen angefühlt. Leider wurde auch hier der große Fehler begangen, sowohl die App-Funktionalität als auch Updates zu vernachlässigen und so kam die Plattform nie aus den Startlöchern heraus.

So, und nun befinden wir uns im Jahre 2011. Sowohl Microsoft als auch Nokia haben dazugelernt. Vor allem Microsoft muss man ein Lob aussprechen, denn sie haben ihre Fehler erkannt und einen Neustart versucht – und das bereits im letzten Jahr. Inwiefern Windows 7 Mobile nun ein Erfolg wird, ist noch nicht abzusehen. Bisher habe ich aber nur gute Berichte von Bekannten erhalten, was hoffen lässt. Nur sehe ich noch ein großes Problem: in der heutigen Zeit definiert nicht mehr das mobile Betriebssystem, ob eine Plattform erfolgreich ist, sondern die Verfügbarkeit und Qualtität der Apps. Und hier ist jeder Konzern von freien Entwicklern abhängig. Ich persönlich sehe hier noch die Gefahr für Microsoft, denn Entwickler stecken ungerne Geld in eine Entwicklung, die zum Schluss von nur sehr wenigen Leuten verwendet wird.

Auch Nokia hat dazugelernt und versuchte mit Meegoo, einem mobilen Linux mit sehr viel Potential, einen Neustart zu wagen. Warum dies bisher noch nicht von sehr großem Erfolg begleitet wurde kann ich nicht sagen. Es scheint aber so, dass sich das Konzept nicht so richtig durchsetzen will.

Nun haben wir zwei Großkonzerne, die beide im Umbruch stehen, aber beide noch nicht so die Wahrheit gefunden haben. Was liegt also näher, als sich zusammenzuschließen. Denn für beide Unternehmen bringt dieser Deal sehr große Chancen: Microsoft kann auf eine spezifizierte und, dass muss man Nokia lassen, sehr hochwertige Hardware setzen, Nokia hingegen bekommt ein sehr innovatives und modernes Betriebssystem, mit welchem deutlich an verlorener Zeit gutgemacht werden kann. Zum einen ist das System bereits am Markt und scheint gut anzukommen, zum anderen kann Nokia mit langjähriger Erfahrung wirklich gute Qualität liefern. Ich finde diese Konstellation äußerst interessant und bin super gespannt, was aus dieser Kooperation wird. Es gibt meiner Meinung nach noch immer das Problem, dass beide Parteien sehr groß sind und sich daher trotzdem als Konkurrenz sehen. Dieses Verhalten würde aber das ganze Projekt zum scheitern verurteilen.

Sehr interessant sind auch die Meinungen aus der Branche: