Archiv der Kategorie: Uncategorized

OwnCloud als Alternative zu Dropbox und Co

Dropbox, Gdrive und der ganze Rest der Cloudhoster haben ein schönes Geschäftsmodell und es scheint für sie zu funktionieren. Auf der anderen Seite hatte Dropbox mehr als seinen gerechten Anteil an Sicherheitspannen und die Entwickler schienen dabei nicht immer auf der Herr der Dinge zu sein. Hinzu kommt beim Benutzen dieser Dienste, daß man private und sensitive Daten auf Server hochlädt, die (meistens) in den USA residieren. Das verursacht bei einigen von uns ein ungutes Gefühl.

Wie gewohnt gibt es eine Alternative für Linux: ownCloud wurde 2010 von KDE-Entwickler Frank Karlitschek gestartet und ist inzwischen bei der stabilen Version 4.07 angelangt, welche im Debian unstable Repository zu finden ist. OwnCloud ist in PHP und JavaScript geschrieben und benutzt eine {sqlite, mysql, postgresql}-Datenbank. Es gibt einen Webclient, der es für alle Plattformen inklusive Android und iPhone nutzbar macht. Außerdem gibt es eine Integration in den Desktop (wenigstens für KDE mit Dolphin) mit dem owncloud-client. Die Entwicklung von ownCloud war für meinen Geschmack gelegentlich ein wenig hastig, die Veröffentlichung von ownCloud 4 sicher ein wenig verfrüht. Jetzt, mit 4.04 in wheezy und 4.07 in sid dachte ich, ich gebe dem letzteren übers Wochenende mal eine faire Chance. Es gibt ebenfalls noch 4.5.x als git-Version für die ganz Tapferen. Da ich testen wollte, ob ich ownCloud in diesem Stadium für mich selbst produktiv nutzen kann, entschied ich mich für die 4.07.

Der V-Server, den ich für dieses Abenteuer benutze, läuft unter Wheezy. Also erweiterte ich die Quellen um sid und installierte owncloud und owncloud-sqlite von dort. Das Webinterface zu öffnen und etwas Konfiguration war eine Sache von Minuten. Alles, was manuell getan werden musste, waren einige Änderungen an /etc/php5/apache/php.ini. PHP hat als Voreinstellung ein Upload-Limit von 2MByte. Das muß geändert werden und ist gut dokumentiert, wie auch der Rest der ownCloud Features. Vergesst nicht, apache danach neu zu starten.

Auf meiner Arbeitsplattform zu Hause hatte ich ebenfalls 2 Quellen hinzuzufügen, um den owncloud-client hinzufügen zu können. Eine davon war einen Zeile für squeeze in meiner sid-Umgebung, was normalerweise keine gute Idee ist. Aber da es nur für libssl0.9.8 gebraucht wird, die gut mit libc6 aus sid zusammenarbeitet und keine anderen Abhängigkeiten hat, auf die man aufpassen müsste, ist das in diesem Fall so in Ordnung. Aber trotzdem: Kinder, macht das nicht zu Hause nach Smile. Die andere hinzugefügte Zeile war eine von Suse weil Debian den //owncloud-client// bis jetzt noch nicht ausliefert. Diese benötigte Zeile ist:

deb http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_6.0/ /

Nachdem installieren der libssl0.9.8 explizit aus stable könnt ihr dann csync und owncloud-client installieren. Mit dem owncloud-client könnt ihr dann das Synchronisieren mit eurem Dateimanger einrichten (bisher nur mit Dolphin getestet).

Nachdem alles (upload, download,synching, sharing)  arbeitete, begann ich meine lokalen und Google-Kalender, sowie mein Adressbuch aus kontact, mittels akonadi und Webdav zu integrieren. Fünf Minuten später richtete ich ampache auf meinem Droid ein und ownCloud kann Musik aus der Wolke zu meinem Smartphone streamen. Amorok kann ebenfalls dazu überedet werden, Musik aus eurer Cloud zu streamen. All dies funktionierte innerhalb von Minuten ohne viel Mühe. Es gibt noch weitere Features, die ich noch nicht getestet habe, wie LDAP Integration.

Wie ihr wahrscheinlich bemerkt habt hatte ich eine Menge Spaß, mag ownCloud sehr gern und werde es produktiv anstatt Dropbox nutzen. Natürlich gibt es Raum für Verbesserungen in so einem jungen Projekt. Die Entwickler integrieren zu viel zu schnell und jetzt läuft der Bugtracker über. Probleme in die ich rannte waren ein langsamer Webclient der gelegentlich einfror (bisher nur mit Chromium getestet) und der owncloud-client, der falsche errors zeigte und so den sync blockte. Diese Dinge sind einfach zu umgehen, aber nichtsdestotrotz störend und werden hoffentlich bei 0.5 in Ordnung gebracht.

Meine Zusammenfassung: Die Bedürnisse an eure Cloud in die eigenen Hände zu nehmen ist gut investierte Zeit. OwnCloud wird hoffentlich noch einen langen Weg gehen.

Wenn dies euer Interesse geweckt hat, schaut euch mal die Features und Dokumentation an.

Vorbereitung auf 2012.2

Wie ihr bestimmt schon erraten habt, wenn ihr gelegentlich unser Forum besucht, ist ein neues Release in der Mache. Was wir bis jetzt haben ist ein Name. 🙂 Auch wenn sid wegen des Freeze ziemlich zahm ist, nennen wir es „Riders on the Storm“, geborgt von dem letzten Doors Album „LA Woman“. Danke, daß ihr euch an der Abstimmung in unserem Forum beteiligt habt. 2012 wird noch 2 Veröffentlichungen und zwei neue Desktop-Umgebungen sehen. Gut, nicht ganz richtig, da eines keine Desktop-Umgebung ist, sondern ein Release, dem genau diese fehlt. Es wird No-X heißen und das beschreibt es ziemlich genau. Das andere wird (hört, hört) Gnome werden, wohl in Version 3.6.x. Wir alle wissen, daß Gnome letzthin eine höllisch gute Zeit mit den Versuchen verbringt, sich selbst überflüssig zu machen, mit dem letzten und größten von Herrn Miguel de Icaza durch das Erwecken der allerbesten Flame-Monster.

Nichtsdestotrotz gibt es User, die das Flavour Siduction-Gnome haben wollen und sie werden es bekommen… Convbsd  ist zum Team gestoßen, um dies zu ermöglichen. Wir halten weiterhin Ausschau nach einem zweiten Maintainer, der Convbsd hilft, dieses Flavour auf lange Sicht zu warten.

Während des Kern Team Meetings Sonntag Nacht konnten wir uns bis jetzt nicht ganz einigen, wann wir was veröffentlichen. Was wir sicher wissen ist, daß beide neuen Flavours ein Entwickler-Release haben werden, bevor sie permanent in unseren offiziellen Releasezyklus aufgenommen werden. Als einen groben Termin für das Release 2012.2 haben wir die Tage um Anfang November genommen.

Die Ferientage zwischen den Jahren werden ein Überraschungs-Release irgend einer Art zu Gesicht bekommen. Die Entwickler-Releases der beiden neuen Flavours werden bis Ende des Jahres erscheinen. Das Kern-Team-Metting in zwei Wochen wird genaueres zu den besagten Terminen ergeben.

Persönlich bin ich sehr gespannt auf das Erscheinen von Razor-QT 0.5 in den nächsten Wochen. Ebenso wartet Qupzilla 1.3.5 mit neuen Funktionen hinter der nächsten Ecke. Wenn alles soweit in Ordnung ist, wird Razor-QT mit einem der nächsten beiden Releases in die siduction-Familie integriert.

Was gibt’s sonst Neues? Ein User fragte danach, 3 seiner Lieblingswerkzeuge paketiert zu bekommen und in das Repo zu integrieren. Dies war eine gute Möglichkeit klar zu machen, daß wir nicht die Möglichkeiten haben, jeden Wunsch den ein User hat, zu paketieren. Dies ist der Grund, aus dem es unser (bisher wenig) User-Repository gibt. Wir leisten gerne Hilfestellung, wenn ein Benutzer Probleme hat, etwas zu paketieren, aber wir werden ihm das nicht abnehmen. Wir haben einfach nicht die Zeit dazu. Wenn eine größere Nachfrage nach einem Paket aus dem user repository entsteht, werden wir es in Augenschein nehmen und es eventuell langfristig in Extra übernehmen.

Also bitte füllt unser User-Repository mit Leben und redet im Forum darüber, damit wir ihm das Fliegen beibringen können. Wir sind offen für Fragen und Anregungen.

Nochmals Infrastruktur-Anpassungen

Unser 14-tägiges Kernteamtreffen letzte Nacht war erneut ausschließlich bestimmt durch die geplanten strukturellen Änderungen zur Verbesserung unserer Arbeitsabläufe und Vereinfachungen, die es unseren Benutzern leichter machen, sich zu beteiligen.

Wie in meinem letzten Blogpost erwähnt, wollten wir die Paketlisten in unser Buildsystem pyfll vereinfachen. Es brauchte ein paar Wochen der Diskussion um hier einen Kompromiss zu finden. Leute, die dies interessiert oder die unser Buildsystem privat nutzen, können den anstehenden Veränderungen im Log ab [21:08:57] folgen.

Das zweite Thema gestern Abend betraf die Repository Struktur und neue Repository Namen. Dies sollte alle Benutzer interessieren, denn es betrifft ihre sources.list.d/siduction.list.

Zunächst einmal: Keine Panik!

Wir haben bereits einige Tests durchgeführt, um auszuprobieren ob alte und neue Bezeichnungen gleichzeitig funktionieren. Das tun sie, so daß wir jetzt Links bereitstellen können von alt nach neu. Ihr als User braucht erst mal gar nichts zu tun, es wird einfach funktionieren. Aber natürlich könnt ihr, wenn ihr wollt, um auch in Zukunft auf der sicheren Seite zu sein. Neue Installationen werden natürlich die neuen Bezeichnungen benutzen.

Hier ist die überarbeitete Struktur:

  • base war bisher siduction benannt. Es enthält alle offiziellen siduction Pakete
  • community gibts nicht mehr, es wurde nie verwendet. (Bitte entfernt es aus eurer Liste, wenn ihr es drin habt)
  • extra ist neu und enthält alle Pakete, die nicht nach base oder user gehören. (Pakete, die wir für die Verbesserung von siduction bauen, Pakete welche (noch) nicht in Debian und nicht essentieller Bestandteil von siduction sind)
  • user ist für Pakete von erfahrenen Benutzern / Team-Mitgliedern, die ihre Pakete verteilen möchten (wie z. B. towos inkscape- und gimp- Pakete)
  • fixes enthält zeitweise Pakete, die in Debian kaputt sind, wenn wir einen schnellen Fix dafür haben. Unser zukünftiges Ziel ist, diese Patches upstream zu übergeben.
  • razor-qt wird in base aufgehen, sobald wir Razor-Qt zu unserem offiziellen Releasezyklus hinzugefügt haben.
  • experimental ist wohl selbsterklärend
  • experimental-snapshots ist nur ein Puffer für unseren Teamgebrauch (Benutzer sollten dies nicht in ihre Liste aufnehmen).

Die Repository Webseite enthält die richtigen Zeilen für eure Änderungen.

Das nächste Thema handelte ebenfalls von Repositories und dem Versuch zu definieren, wo die Paketquellen am sinnvollsten vorzuhalten sind. Für die base und extra Repositories ist dies klar unsere eigenen Infrastruktur (chili/git). Die Quellen unseres user Repositories sollten von unserer Infrastruktur getrennt gehalten werden. Der Grund ist, daß jeder in der Lage sein sollte, diese auf einfache Weise zu forken, zu paketieren und in anderen Projekten zu verteilen. Github scheint hier der benutzbare Weg zu sein. Es ist dafür ausgelegt, geforkt(abgespalten) zu werden. Alle Änderungen an geforkten Paketen sind nur einen merge weit weg, um zur originalen Quelle zurück portiert zu werden.

Das letzte Thema letzte Nacht war Jenkins. Es braucht mehr Zeit und Tests. Wir stimmen alle überein, daß es nicht dringend ist und die Letzte in der Linie unserer Verbesserungen sein muß. Wenn wir es aufgesetzt haben und voll verstehen, wie es arbeitet, wird es uns eine Menge Zeit sparen, indem es Dinge automatisiert, die wir im Moment per Hand erledigen.

Und noch ein anderes Thema: Die Zeit ist gekommen, um über einen Namen für unser nächstes Release nachzudenken, denn das Art-Team braucht Zeit, um die Release-art dafür zu entwickeln. Der Prozess, mit dem wir im Moment arbeiten (User übermitteln ihre Favoriten, das Team wählt den Gewinner durch Abstimmung), ist nicht wirklich flüssig und befriedigend, soweit es mich betrifft. Wenn jemand eine bessere Idee für diese wiederkehrende Routine hat, wären wir glücklich, davon zu hören. Auf der anderen Seite, wenn nichts großartiges kommt, werden wir die alte Methode noch einmal anwenden. Also seid auf die Ankündigung einer Wikiseite zu diesem Zweck gespannt.

Änderungen an der Infrastruktur

Weil nach dem Release vor dem Release ist, nehmen wir die Gelegenheit wahr, einige Teile unserer Infrastruktur zu zerbrechen und verbessert wieder zusammen zu setzen. Das Core-Meeting der letzten Nacht war komplett über die Unzulänglichkeiten, die wir fanden und wie sie zu reparieren wären.

Die erste diskutierte Veränderung war, wie unser Releaseprozess funktioniert. Bisher: Wenn wir veröffentlichen, warten wir, bis ein Debian Mirror Sync beendet ist und beginnen dann, unseren Schnappschuß zu bauen. Das lässt uns zwischen 2 Syncs 6 Stunden Zeit. Solange alles glatt geht, ist das so in Ordnung. Trotzdem könnten Probleme leicht ein Release verzögern. Außerdem haben wir mehr Geschmacksrichtungen als zuvor und werden vielleicht in Zukunft auch noch weitere hinzufügen, dann kann der Zeitrahmen ein Problem werden. Wir werden also einen Proxy-cache oder Mirror dazwischen schalten, um auf der sicheren Seite der Dinge zu sein. Sollten Probleme während des Build-Prozesses auftreten, können wir einen intakten Schnappschuss von vor 6 Stunden oder einem Tag vorher ohne viel extra Arbeit veröffentlichen. Hier muß noch diskutiert werden, welche Methode oder welches Werkzeug wir dafür benutzen.

Die zweite Veränderung betrifft die pyfll-Pakete-Listen selbst: Wir finden das, was wir von aptosid geforkt haben, in der Form nicht mehr länger brauchbar. Möglicherweise ist dies so, weil wir mehr Flavours haben als unser Vorgänger. Wir haben alle Situationen erlebt, wo wir uns nicht wirklich sicher waren, wohin wir ein Paket hinzufügen sollten oder dass wir bei einer bestimmten Liste nicht übereinstimmten. Das muß logisch und offensichtlich werden. Wo ein Paket hingehört, muß geradlinig und zweifelsfrei sein. Also ist eine Reorganisation dieser Listen notwendig. Bis zu unserem nächsten Meeting werden wir die letzte Nacht diskutierten Modelle überdenken. Wir kamen sehr viel näher an einen Kompromiss, als wir das vor einem Monat waren, wo ein Boxkampf ein schneller Weg zu sein schien, die Differenzen auszutragen. 🙂

Nicht zuletzt diskutierten wir die Struktur unserer Reopositories. Welche Pakete gehören in welches Repo? Haben wir zu viele oder nicht genug Repos und sind sie harmonisch danach benannt, welche Pakete sie beherbergen? Wir stimmten überein, daß wir ein oder zwei zu viele haben und ein wenig Umbenennen nötig ist. Unsere User werden nicht darüber stolpern, weil wir Links zur Verfügung stellen werden, um die sources.list intakt und arbeitsfähig zu halten.

Bevor ich’s vergesse: Wer das Log unseres letzten Meetings vor zwei Wochen gelesen hat, wird gesehen haben, daß wir zwei Teammitglieder ersetzt haben. Vibora und edhunter haben im Moment nicht die Zeit, um in unserem Kernteam mit zu arbeiten. Sie werden ersetzt durch hendrikL und Goingeasy9. Die Abstimmung dazu könnt ihr in unserem Log sehen. Danke an Vibora und edhunter für ihre gute Arbeit in den letzten paar Jahren. Euer Code wird in siduction lebendig bleiben.

Drucker-Reise ala Samsung

Nicht lange her kaufte ich für €55 einen schönen kleinen Samsung ML 1675 Laserdrucker. Er sollte mit dem Samsung Unified Linux Treiber arbeiten. Also googlete ich, ging zur Samsung Webseite, lud den Treiber herrunter und installierte ihn. Das brachte den Drucker nicht zum arbeiten. Das Cups Interface konnte den Drucker jetzt sogar nicht mehr erkennen. Ich lies die Dinge wie sie waren, es war spät. Am nächsten Morgen war mein dist-upgrade mit seltsamen Fehlermeldungen blockiert die sich als vom Samsung mfp-driver hervorgerufen erwiesen. Entfernen des Ganzen löste die Probleme.

Also, installiert nicht die Treiber von der Samsung Webseite, sie funktionieren nicht.

Ich grub ein bischen tiefer in Google und fand The Samsung Unified Linux Driver Repository. Hier sind die Schritte um jeden Drucker / Multifunktionsgerät, das auf diesen Treiber angewiesen ist, in sehr kurzer Zeit zum Laufen zu bekommen.

Öffnet eine Shell und werdet root:

su [ENTER]

root@siductionbox: cd /etc/apt/sources.list.d [ENTER]

root@siductionbox:/etc/apt/sources.list.d# touch Samsung_Printer.list && echo deb http://www.bchemnet.com/suldr/ debian extra > Samsung_Printer.list && wget -O –      http://www.bchemnet.com/suldr/suldr.gpg | apt-key add – ;  apt-get update [ENTER]

Das richtet das benötigte Repository ein und installiert den gpg-Schlüssel dafür. Danach möchtet ihr die Treiber installieren:

apt-get install samsungmfp-data samsungmfp-configurator-qt4 samsungmfp-configurator-data samsungmfp-driver samsungmfp-driver-4.00.39 printer-driver-splix

Dies wird nur die für den Drucker gebrauchten Teile installieren. Wenn das alles ist was ihr braucht, Drucker einschalten und freuen. Falls der Drucker noch nicht eingerichtet war, kann dies jetzt unter http://localhost:631 geschehen. Hier wählt ihr deen Treiber für Samsung ML 1670 aus.

Wenn ihr ein Multifuntkionsgerät habt, das auch scannen kann, braucht ihr noch etwas mehr Software. Benutzt ihr siduction ist der Benutzer sowieso Mitglied der Gruppe „lp“, es braucht also keine weitere Aktion. Solltet ihr eine andere Distribution benutzen, kontrolliert dies – als user- durch die Eingabe von:

devil@siductionbox:~$ groups [ENTER]

devil lp dialout cdrom floppy audio dip video plugdev users fuse scanner netdev

Ist lp vorhanden braucht ihr nur ein paar Zusatzpakete obenauf zu installieren:

apt-get install samsungmfp-scanner samsungmfp-scanner-sane-fix samsungmfp-scanner-sane-fix-multiarch

 Hinweis: Bevor ihr die letzten beiden Pakete installiert lest die Ausgabe von apt-cache show um zu sehen ob sie bei euch zutreffen.

 

Für ein kleines Druckaufkommen im SoHo taugt der Samsung ML 1675 Laserdrucker durchaus. Er ist schnell und hat ein sauberes Druckbild. Über Verbrauchsmaterialien (Toner) kann ich noch nichts sagen

Neuer Debian Mirror Redirector

Wenn ihr Euch die sources.list unseres neuen Release anschaut, seht ihr ein neues Schema in der debian list. Es basiert auf http://http.debian.net/debian. Das ist das Schema des neuen Debian Mirror Redirector, der einige Vorteile mit sich bringt. Er sucht nicht nur den schnellsten Mirror sondern hilft auch beim Load-Balancing und ermöglicht parallele Downloads. Außerdem ist er für das kommende IPv6 gerüstet.

Wenn ihr ein älteres Release installiert habt, stellt einfach die Zeilen in der debian.list um. Wenn ihr dann apt-get update ein paar Mal beobachtet, solltet ihr verschiedene Mirror benutzt sehen.

Desperado Reloaded veröffentlicht

Spät gestern abend haben wir, gerade mal eine Woche vor dem Freeze für Debian 7, Desperado Reloaded veröffentlicht. Die Details stehen in der Release Note.  Downloads findet man auf unseren Spiegelservern oder als Torrent.

In der näheren Zukunft werden wir, um der Langeweile des Freeze zu entgehen, ein paar Dinge kaputtmachen, um sie dann neu zusammen zu setzen:

  • Die Art und Weise, in der wir unsere Art-Pakete bauen und vor allem integrieren bedarf einer Generalüberholung. Das st viel zu kompliziert und fehleranfällig.
  • Anstatt bei Releases zwischen 2 Sychronisationsläufen der Debian Server direkt von diesen zu bauen, werden wir einen Repositiry-Server aufsetzen, der uns etwas mehr Freiraum im Release-Prozess gewährt.
  • Außerdem wollen wir uns Jenkins für automatisiertes  Paket/Iso-bauen und Regressionstests genauer anschauen um unsere Infrastruktur weiter zu härten.

Zum Schluss noch eine News für die Freunde von Razor-qt: Im August-Heft des LinuxUser gibt es ein gestern gebautes, exklusives, aktualisertes und verbessertes Image unseres Razor-qt-Releases samt Artikel.

Desperado Reloaded

Wir hatten letzte Nacht ein (verspätetes) Kern Team Treffen. Hauptsächlich hatten wir 2 Themen:

  • Ein Reparatur-Release für 2012.1 Desperado
  • Die permanente Abwesenheit von zwei Kern Team Mitgliedern

Das Reparatur-Release wird am Abend des Sonntag, 24.06.2012, veröffentlicht (wenn sid uns lässt). Dieses Fix-Release wird KDE SC 4.8.4-x als das gleiche komplette Set mit sich bringen, wie es auch nach Wheezy einfließen wird. Mit dem „Einfrieren“ für das Release von Wheezy, beginnend am 30.06.2012, wollen wir die Zeit nutzen um zu diesem Paket-Set zu erweitern , da das bei 2012.1 Desperado (nur) ein sehr Grundlegendes war. Daneben wird unser KDE SC Abbild für akonadi auf sqlite voreinstellen, anstatt mysql zu benötigen. Kleinere Reparaturen an LXDE und XFCE komplettieren das Fix-Release 2012.1.1 Desperado.

Das zweite Hauptthema war eine Abstimmung, was in Bezug auf 2 Core-Team-Mitglieder zu tun sei, die seit einer Weile abwesend sind. Die beiden Mitglieder sind vibora und edhunter. In der Abstimmung wurde entschieden, dass beide aus dem Kern Team entlassen werden. Das Team braucht aktive Mitglieder, die mindestens an den Treffen und Abstimmungen teilnehmen. Tote Stimmen blockieren das Team, weil sie die Anzahl der Teilnehmer reduzieren, ebenso ist die Beschlussfähigkeit ein Problem. Wir werden an einer Regel arbeiten, um damit umzugehen. Unser Dank geht an vibora und edhunter für die Arbeit die sie für siduction und seine Vorgänger geleistet haben. Wir werden die beiden leeren Plätze im Team in Kürze auffüllen. Es gibt bereits einige Kandidaten, aber mehr dazu wenn wir jemanden herein wählen.

Ein anderes Thema war, einen Code freeze 24 Stunden vor einem Release zu setzen. Ihr findet das log des Treffens wie immer bei Chili.

Nachlese

LinuxTag 2012 ist vorbei. Wir hatten eine gute Zeit während dieser 4 Tage und auf den nächtlichen Parties. Natürlich haben eine Menge Leute gefragt, was es mit dem erneuten Namenswechsel auf sich hat, aber niemand missgönnte es wirklich. Danke an die Debian- und Kanotix-Leute für das Teilen eines großartigen Standes.

Freitag nacht hatten wir eine kleine Release-Party am Stand mit etwa 30 Beobachtern, die Bier, Fleischklopse und einen ersten öffentlichen Build und eine Einführung in unser razor-qt-Release genossen. Es war geplant, dieses auch von dort aus zu veröffentlichen, aber wir entschieden,  ihm noch etwas mehr Liebe zukommen zu lassen und noch etwas optische Verschönerung hinzuzufügen. Wir haben es deshalb erst heute morgen veröffentlicht. Downloads können von unseren Spiegeln bezogen werden.

Kurz vor dem LinuxTag hatten wir auch das finale siduction 12.1 „Desperado“ veröffentlicht.
Die Release-Notes zeigen die Details und es kann ebenfalls über unsere Mirrors bezogen werden.