Willkommen zum openSUSE Planeten

Dies ist eine Zusammführung der Blog-Einträge von Mitwirkenden im openSUSE-Projekt.

Zum Hinzufügen eines Blog-Feeds bitte die Anleitung lesen.


Freitag
11. April 2014


face

Man kommt nicht umhin, vom schwerwiegenden OpenSSL Fehler zu hören. So gut wie alle Medien berichten über die Lücke, darum werde ich hier nur die nötigsten Infos ergänzen: wie kann ich den Raspberry Pi wieder absichern.

Dazu müssen 2-3 Dinge beachtet werden:
1. Die fehlerhafte OpenSSL Version muss ein Update erfahren.
2. Alle vergebenen Zertifikate müssen erneuert werden.
3. (wenn zutreffend) Webseiten-Passworte ändern.

Viele Infos habe ich von diesen Seiten entnommen: https://www.digitalocean.com/ (englisch) und http://www.hackerway.ch/ (englisch)

1. Update
Da für Debian der Fix schon verfügbar ist, reicht folgender Befehl:

sudo apt-get update && sudo apt-get dist-upgrade

Ob das OpenSSL-Update erfolgreich eingespielt wurde, könnt ihr mittels folgendem Befehl testen:

dpkg -l | grep "openssl"

Es sollte folgendes in etwa anzeigen:
ii  openssl                            1.0.1e-2+deb7u6               amd64        Secure Socket Layer (SSL) binary and related cryptographic tools
u6 ist dabei entscheidend.

2. Zertifikate erneuern

Somit wäre schon mal der Angriffspunkt beseitigt. Da die Zertifikate jedoch noch unsicher sind, müssen diese im nächsten Schritt als ungültig gekennzeichnet und neue erzeugt werden.

Da ich auf oYoX 2 Anleitungen zum Thema SSL veröffentlicht habe ( A OpenVPN in Verbindung mit Android und Raspberry Pi und B SSL verschlüsselte Verbindung zum Raspberry Pi (Lighttpd) ), ist es nun notwendig den entsprechenden Zertifikat-Austausch vorzunehmen. Solltet ihr sowohl lighttpd als auch VPN nutzen, dann einfach beide Wege durchführen.

A
Die Zertifikate für VPN können wir nicht einfach ersetzen, sondern müssen diese vorher für ungültig erklären / widerrufen:

cd /etc/openvpn/easy-rsa
sudo su
./revoke-full client1

client1 steht für den Namen, welchen wir vergeben haben.

Folgende Ausgabe sollte zu sehen sein:

Using configuration from /etc/openvpn/easy-rsa/2.0/openssl-1.0.0.cnf
Revoking Certificate 03.
Data Base Updated
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
client1.crt: C = NL, ST = ZH, L = City, O = Name, OU =, CN = client1, name = client1, emailAddress = openvpn@example.org
error 23 at 0 depth lookup:certificate revoked

Error 23 heißt, die Verifizierung/Überprüfung des zurück gerufenen Zertifikats schlägt fehl (was wir ja erreichen möchten).

Die “index.txt” Datei im Schlüssel-Verzeichnis wird dabei erneuert.
Man sieht ein “R” (für revoked = widerrufen) in der ersten Spalte von links für den Benutzer “client1“, wenn die folgenden Befehle ausgeführt werden:

cat keys/index.txt

Wir erneuern für alle Fälle nochmal komplett das Server-Zertifikat

cd /etc/openvpn/easy-rsa

source vars
./clean-all
./pkitool --initca
ln -s openssl-1.0.0.cnf openssl.cnf

Jetzt zitiere ich Jan:

Wir können nun die Komponenten für die Verschlüsselung des OpenVPN Zugangs generieren. Nach der Eingabe des ersten Kommandos wird man nach dem Land als Abkürzung gefragt (DE = Deutschland; AT = Österreich; CH = Schweiz). Alle weiteren Angaben können einfach bestätigt werden, da sie für OpenVPN nicht relevant sind. Dasselbe gilt bei dem zweiten und dritten Kommando, wobei wir dort


Sonntag
06. April 2014


face

Seit einiger Zeit bin ich ebenfalls, wie schon etliche vor mir, stolzer Besitzer einer Synology DiskStation. Bei mir werkelt ein eher kleineres Teil aus dieser Reihe, nämlich das DS 213j. Aber meine Begeisterung für diese, vereinfacht ausgedrückt Netzwerkfestplatte, kennt keine Grenzen.Ich will mich hier jetzt aber gar nicht zu Einzelheiten dieser DiskStation auslassen. Dafür gibt es etliche spezialisierte Seiten, Blogs und Foren, die das viel besser können.

Aber diese Netzwerk DiskStation hat auch einiges zu bieten, was gerade auch für Linuxer interessant ist. Da wären zum Beispiel, das man die ownCloud darauf betreiben kann und das man den Speicherplatz der Station per NFS und auch per WebDAVs in Linux einbinden kann. Und gerade letzteres finde ich sehr hilfreich, weil man so ( einige Voraussetzungen auf Synology DiskStation müssen erfüllt sein) mit einer verschlüsselte Verbindung übers Internet auf seinen heimatlichen Netzwerkspeicher zugreifen kann, wie auf einem lokalen Laufwerk. Und das ein mal eingerichtet und jederzeit verfügbar.

Was auf der Synology DiskStation für eine Verbindung per WebDAVs ( WebDAVs ist die verschlüsselte Variante von WebDAV ;-) ) konfiguriert sein muss werde ich hier auch nicht im einzelnen erläutern. Das ist recht einfach und die Benutzeroberfläche der DiskStation erklärt das sehr schön selbst und hilft durch alle Schritte die nötig sind, damit die Synology DiskStation auch von außen, vom Internet, erreichbar ist. Einschließlich Tipps für die Konfiguration des Routers.

Ich möchte hier nur den Part auf openSUSE Seite erklären, wie man den Speicherplatz der DiskStation per WebDAVs in KDE einbindet und so z.Bsp. über den Dateimanager Dolphin auf die Daten zugreifen kann.

Startet den KDE Dateimanager Dolphin und klickt links unter

Startet den KDE Dateimanager Dolphin und klickt links unter “Orte” auf “Netzwerk” und dann im rechten Fensterteil auf “Netzwerkordner hinzufügen”.

Daraufhin startet der Assistent für Netzwerkordner.

Daraufhin startet der Assistent für Netzwerkordner. WebDAV ist schon ausgewählt und das lassen wir auch so. Einfach auf “weiter” klicken.

Hier kommen die notwendigen Informationen rein, um eine Verbindung zum Server und zum persönlichen Account aufzubauen.

Hier kommen die notwendigen Informationen rein, um eine Verbindung zum Server und zum persönlichen Account aufzubauen.

webdav _002

Der “Name” der Verbindung ist frei wählbar. Spielt keine Rolle was da steht. ;-) Der “Benutzer” muss identisch mit einem existierenden Benutzer auf der Synology DiskStation sein. Auch die Schreibweise muss exakt übereinstimmen.

Um eine verschlüsselte Verbindung zu der DiskStation aufzubauen musste man bei den Vorbereitungen auf der Station ein eigenes SSL Zertifikat erstellen. Wenn man dieses Zertifikat nicht beglaubigen lässt ( ich glaube so heißt das ;-[ ) und im oberen Fenster letztendlich auf “Speichern & Verbinden” klickt, wird eben dieses Zertifikat vom System erst mal als unbekannt angemeckert. Die zwei Nachfragen, ob man dem Zertifikat trotzdem vertrauen will und dieses nur ein mal oder dauerhaft akzeptieren will kann man bei einem selbst erstellten Zertifikat ruhig tun. Danach wird die Verbindung zur DiskStation übers Internet erst hergestellt und es erfolgt die Passwortabfrage für den jeweiligen Benutzer.

Hier wird erst jetzt das Passwort für den Benutzer der Synology DiskStation abgefragt, dessen Speicherplatz hier ins System eingebunden werden soll.

Hier wird erst jetzt das Passwort für den Benutzer der Synology DiskStation abgefragt, dessen Speicherplatz hier ins System eingebunden werden soll


Dienstag
01. April 2014


face

(Update) Die Änderung bei den openSUSE KDE Repositories ist jetzt verfügbar. Ihr findet die neuen KDE Repos unter
http://de.opensuse.org/KDE_Repositorys#Aktueller_KDE_SC_Release . Beachtet, dass Ihr eventuell andere eingebundene KDE Repos löscht, wenn Ihr die KDE:Current nutzen wollt. Es sollte zu keiner Vermischung von KDE Paketen aus unterschiedlichen Quellen kommen. (/Update)

Bei openSUSE werden bald ein Teil der KDE SC Repositories neu organisiert. Zeitgleich mit der Auslieferung des KDE SC Update 4.12.4 wird openSUSE seine bisherigen KDE:Release:xy-Repositories in das neue KDE:Current-Repository zusammenfassen. Dadurch können Anwender dieses Repository immer die aktuelle KDE-Veröffentlichung benutzen, ohne wie bisher extra das Repository auf die jeweilige KDE SC Version zu wechseln.
Das hat schon ein bisschen was von KDE Rolling Release für openSUSE. ;-)

Auf die anderen bestehenden KDE SC Repositories hat das keine Auswirkungen
Für die Betaversionen und RC’s gibt es weiterhin das KDE:Distro:Factory Repo und für die ganz Eiligen bleibt dann noch das KDE:Unstable:SC mit den Enwicklerschnappschüssen.

Wenn die Repoumstellung vollzogen ist, werden die bisherigen KDE:Release:xy-Repositorien geleert.

Quelle:
http://www.pro-linux.de/news


Samstag
22. März 2014


face

Die openSUSE Entwickler haben den ersten Meilenstein zur Entwicklung von openSUSE 13.2 beendet und zum Herunterladen und Testen zur Verfügung gestellt. Dieser erste Milestone trägt, wie schon beim letzten Mal, die Nummer 0.

Wie Anfang Februar in diesem Artikel angekündigt, wird die kommende openSUSE Version 13.2 nicht den ehemals angestrebten 8 monatigen Releasezyklus einhalten. Die openSUSE-Entwickler wollen und müssen erst mal dringende Aufgaben bei den openSUSE eigenen Werkzeugen und bei der grundsätzlichen Infrastruktur der Distribution abarbeiten und überarbeiten. Daraus resultiert ein wahrscheinlich 5 Monate späteres Release der nächsten Version 13.2. Also ungefär im November 2014. Vom 24. – 28. April 2014 findet die nächste openSUSE Konferenz in Dubrovnik (Kroatien) statt. Bei der Gelegenheit wollen sich die openSUSE Macher ausführlich über die genauen Releasetermine für 13.2 und auch über den zukünftigen generellen Releasezyklus austauschen. Fakt ist, dass zukünftig mehr Gewicht bei den Releases der Community übertragen werden soll. Fakt ist aber auch: ( und das hatte viele Gemüter im Vorfeld bewegt ) Release Manager Stephan “Coolo” Kulow wird auch die 13.2 wieder “zur Welt bringen” ;-)

Es gab einige Verwirrungen in den letzten Wochen und Monaten, wobei eine recht dürftige openSUSE Kommunikation eine starke Rolle spielte. Das hat wohl auch das openSUSE Team selbst schnell erkannt und mit diesem Beitrag bereits Anfang Februar drauf reagiert. Bleibt zu hoffen, dass sich dazu wirklich etwas tut.

Aber nun endlich zu openSUSE 13.2 Milestone 0

Dafür, dass es sich um einen ersten Milestone für eine neue Version handelt, sind schon ganz schön viele bedeutende Änderungen eingeflossen. Weitere Änderungen in der kommenden Entwicklung sind natürlich noch viele möglich und auch wahrscheinlich. Diese frühe Ausgabe ist nur als Testversion zu verstehen und zum Gewinnen von Feedback gedacht.

Fakten:

  • Kernel: Testversion von Linux 3.14
  • Btrfs als Standard-Dateisystem mit btrfsprogs 3.12 zur Verwaltung enthalten
  • Systemd 210
  • Netzwerkverwaltung mit wicked (ersetzt ifup)
  • Dracut zum Erzeugen des Initramfs
  • optisch erneuertes YaST (Qt-Frontend auf Qt5 portiert)
  • Zypper 1.10
  • neuste KDE SC Version 4.x und KDE Frameworks 5 enthalten
  • Wayland 1.4

Diese Entwicklerversion kann von der openSUSE Entwicklerseite in all den bekannten Formaten und für 32Bit und 64Bit Architektur herunter geladen werden.

Ich habe mal fix das KDE Live Images von openSUSE 13.2 Milestone 0 herunter geladen und mittels “openSUSE Images Writer” aus meinem installiertem openSUSE 13.1 auf einen USB Stick geschrieben. Wie zu erwarten, ist selbstverständlich die Optik noch die selbe wie bei 13.1 . Das kommt, wenn überhaupt, erst viel später dran. Der Start vom USB Stick funktionierte auf meinem doch recht betagtem Test Notebook “HP Pavilion dv9000″ problemlos.

openSUSE 13.2 Milestone 0 KDE Desktop

openSUSE 13.2 Milestone 0 KDE Desktop

Die Optik des KDE Networkmanager von KDE 4.12.2 war für mich einigermaßen neu. Kann aber auch daran liegen, dass ich mein gewohntes KDE System im Laufe der Zeit schon etwas mit persönlichem Style verändert habe


Freitag
21. März 2014


face

AMD FirePro and FireMV Unified Driver (fglrx 13.251.1) wurde veröffentlicht und unterstützt Grafikkarten der Serie FirePro und FireMV. Das Skript makerpm-amd-unified-13.251.1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3 sowie bis Kernel 3.9. Im aktualisierten Packaging Skript wurde openSUSE 13.1 freigeschaltet und eine Reihe von Kernel-Patches hinzugefügt. Somit ist der Treiber bis Kernel 3.14 lauffähig.

Eine Release Notes gibt es zu diesem Treiber offiziell noch nicht.

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Downloads:

Die Installation des AMD FirePro and FireMV Unified Treibers ist bis auf den Dateinamen des Skriptes nahezu identisch mit dem AMD Catalyst Treiber. Daher verweise ich auf die AMD Catalyst Installationsanleitung.

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-unified-13.251.1.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

-b Nur das RPM-Package bauen (Standard)
-c <type> Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d Nur den AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese in eine Datei namens amd-report.txt
-u|–uninstall entfernt AMD FirePro and FireMV Unified Driver restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt.
-ur|–uploadreport wie Option –report nur zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei Erfolg den Link zurück.
-h Die Hilfe anzeigen lassen
-V Version des Skript anzeigen

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

  1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
  2. Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
  3. In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.

Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen


face

AMD Catalyst 14.3 Beta V1.0 (fglrx 13.35.1005) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-14.3-betav1.0.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.13. Zum Packaging Skript wurde ein Patch hinzugefügt und unterstützt bis Kernel 3.14

Nachfolgende Release Notes von AMD zum AMD Catalyst 14.3 Beta V1.0:

Folgende Probleme sind im Treiber behoben worden:

  • [394848] – Xorg crashed playing AVI video file in VLC player or Parole player
  • [394705] – “Nexuiz – Demo3″ Ubuntu performance lower than Redhat
  • [394704] – “Nexuiz – Demo3″ Linux performance lower than Windows

Offene Probleme:

  • [390964] : Stuttering and poor performance after playing an OpenGL game for a several minutes on Ubuntu
  • [393377] : Terminal panel stops refreshing until there is movement from mouse cursor
  • [392546] : System hang observed while hotpluging the stereo display
  • [388835] : Corruption and system hang observed while running Sanctuary BM with TFD enable
  • [392552] : Enabling Overlay: StartX , the screen shows corruption

Link: AMD Catalyst™ 14.3 LINUX Beta Driver Release Notes

Folgende Steam-Spiele habe ich getestet und laufen mit diesem Treiber:

  • Amnesia: The Dark Descent
  • Cities in Motion 2
  • Crusader Kings II
  • Duke Nukem 3D: Megaton Edition
  • Euro Trucker Simulator
  • Europa Universalis IV
  • Half-Life 2: Deathmatch
  • Half-Life 2: Lost Coast
  • Hotel Miami
  • Project Zomboid
  • Shadow Warrior Classic Redux
  • Strike Suit Zero
  • Survivor Squad
  • Wargame Franchise Pack

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Achtung: openSUSE 12.3 und 13.1 wird nicht unterstützt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2013/01/25/opensuse-amd-catalyst-13-1-legacy-treiber-als-rpm-installieren/

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-14.3-betav1.0.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

-b Nur das RPM-Package bauen (Standard)
-c <type> Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d Nur den AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren

Dienstag
18. Februar 2014


face

Nachdem ich feststellte, dass eine Platte des Servers nach dem Reboot nicht mehr mit ins Raid aufgenommen habe ich diese mittels SMART – Tools untersucht. Ich konnte feststellen, dass bereits 3200 Sektoren automatisch “allocated” wurden :-( . Anruf beim Server Hoster ergab Plattentausch. Gemacht getan, Server fährt normal hoch, platte wird ins Raid array aufgenommen. Sync bricht nach 30% ab, wegen Lesefehler auf der einzigen aktiven Platte :-( . Letztendlich blieb nur ein Fullbackup und der tausch der zweiten Platte. Natürlich erfolgte dann noch ein Restore der gesicherten Daten.

Nachdem Restore hatte ich allerdings Probleme dass die Kiste sauber bootete.

1. Sicherung der neuen fstab (Umstellung auf UUID für die Platten anzusprechen)

2. Sicherung von /boot da hier andere Kernelversionen als in der grub config standen.

Nun schnurrt der Server wieder vor sich hin.


Donnerstag
13. Februar 2014


face

openvpn
Wer gerne mal unterwegs ein öffentliches Wlan nutzt, sollte sich Gedanken machen, in wie weit er seine Daten preisgeben möchte. Viele Webseiten übertragen die Daten unverschlüsselt. Plugins wie “https everywhere” sind zwar ein guter Anfang, aber besser ist ein VPN (Virtual Private Network).

Die folgende Lösung erstellt ein VPN Tunnel zwischen eurem Android-Gerät
und eurem Heimnetzwerk mit dem Raspberry Pi als Gegenstelle.

Das ist zwar auch nicht die top Lösung, denn die Verbindung von eurem Heim-Netz ins www ist noch immer von dem jeweilig aufgerufenen Link abhängig, jedoch sind wir im Wlan Netz dann sicher unterwegs.

1. OpenVPN Installation auf dem Raspberry Pi

Zuerst folgt ihr der ausgezeichneten Anleitung von Jan (PDF) um OpenVPN auf dem Raspberry Pi zu installieren.

Ein paar Anmerkungen zur Anleitung von mir:

Zu Schritt 6
Bei folgendem Fehler:
failed to update database

./clean-all

und nochmal 6. von vorne

Zu Schritt 9
Das ist eine Zeile.

sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/8 ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE

Zu Schritt 12
In Code-Zeile 4 ( remote RASPBERRY-PI-IP 1194 ) die IP eures Internet-Zugangs eingeben, unter welcher ihr dann von außen erreichbar seid.
( Bei einer festen IP hilft z.B. wieistmeineip.de ) Wenn ihr einen DYNDNS Service nutzt, dann schreibt ihr diesen (ohne http://) anstelle von der Raspberry-pi-ip an besagte Stelle – der Port muss dennoch angegeben werden.

Ich habe mir nun die “openvpn-keys.tgz” mittels FileZilla vom Raspberry Pi gezogen, entpackt und dann über das WLAN-Verbindungs-Tool (Remote Manager) des ES-Datei Explorers (unbedingt ansehen, sehr gutes Tool) auf das Android Gerät gespielt.

Converted_file_01a73282
2. “OpenVPN für Android”

Nun könnt ihr “OpenVPN für Android” auf dem Smartphone installieren:

Get it on Google Play

Anleitung zum Einrichten:

  1. Im Reiter “Profile” auf das + klicken.
  2. Einen Namen eingeben (z.B. HeimVPN)
  3. Grundeinstellungen anklicken
  4. Server: siehe Schritt 12 oben (DynDNS oder IP eingeben)
  5. Typ: Zertifikate auswählen
  6. bei CA Zertifikat auf Auswählen klicken – dann ca.crt auswählen
  7. bei Clientzertifikat auf Auswählen klicken – dann client1.crt auswählen
  8. bei Clientzertifikatschlüssel auf Auswählen klicken – hier client1.key auswählen
    beachtet jeweils bei 7. und 8. – der Name client1 richtet sich nach dem Namen, welchen ihr bei der Zertifikat-Erstellung auf dem Raspberry Pi
    vergeben habt. Wenn ihr der Anleitung von Jan ohne Änderung gefolgt seid, dann lautet dieser wie oben “client1″.
  9. Nun auf “Zurück” (auf eurem Telefon ;) ) und auf HeimVPN klicken, FERTIG.

Tipp 1: nach der erfolgreich hergestellten Verbindung könnt ihr diese auch direkt über die Benachrichtungs-Zeile verwalten, indem ihr auf openVPN klickt.

Tipp 2:
um schnell eine Verbindung herstellen zu können, einfach eine “Verknüpfung” auf dem Desktop erzeugen – dabei einfach “OpenVPN Verknüpfung” auswählen und es bietet euch direkt das “HeimVPN” zur Auswahl an. Danach reicht ein Klick auf das Icon und die Verbindung wird hergestellt.


Mittwoch
05. Februar 2014


face

Viele haben es schon mitbekommen. Zuerst nach dem Beitrag von Michal Hrusecky auf http://article.gmane.org/gmane.linux.suse.opensuse.project/14784 und spätestens anschließend nach dem Artikel von Mirko Lindner auf
http://www.pro-linux.de/news/1/20731/veroeffentlichung-von-opensuse-132-verschoben.html, dass sich bei openSUSE etwas tut. Die Wellen schlagen hoch. Das openSUSE 13.2 verschoben werden soll hat jeder schnell begriffen und das habe ich auch noch mal in einem Artikel wiedergegeben. Das stellt sich auch bei den meisten nicht als Problem heraus. Die größte Verwirrung und die meisten Fragezeichen entstehen durch die ganzen anderen Andeutungen in den Beiträgen. Nach der ursprünglichen Ankündigung von Michal Hrusecky sind ja umfangreiche Diskussion entstanden, bei der nicht jeder alles ganz so richtig verstehen konnte. Da fehlte vielen auch einfach der Kontext.

Für einige entstand u.a. der Eindruck, dass die Firma Suse ihre bezahlten Entwickler von openSUSE abziehen könnte oder das z.Bsp. Stephan Kulow (Releasemanager), der die ganze Sache bei den vorigen Releases maßgeblich zusammen gehalten hat, für weitere Versionen nicht mehr zur Verfügung steht u.s.w.

Auf der offiziellen openSUSE Mailingliste hat  Marcus Moeller zu dem Thema direkt nachgefragt und dazu Antworten teilweise aus erster Hand bekommen. Aber auch diese Mailingliste ist wieder englischsprachig. Ich habe kurzerhand den Marcus gebeten, das Ergebnis seiner Anfrage für uns nicht englisch verstehenden openSUSE Fans zusammenzufassen. Mir hat es sehr geholfen und ich reiche es gerne weiter.

Hier die Zusammenfassung von Marcus Moeller:

——————————————————————————————————

Das als Nachfolger der openSUSE Boosters angetretene openSUSE Team (https://en.opensuse.org/openSUSE:OpenSUSE_team) hat beschlossen sich in den nächsten Monaten auf die Weiterentwicklung des OBS (http://openbuildservice.org/) und der Veröffentlichung der Open Source Version von openQA zu konzentrieren. Daraus resultiert, dass der für Mai geplante 13.2er Release verschoben werden muss. Momentan ist von November die Rede. Die ursprüngliche Ankündigung von Michal Hrusecky (http://lists.opensuse.org/opensuse-factory/2014-01/msg00350.html) ist etwas unglücklich formuliert. Daher entstand eine etwas aufgeregte Debatte auf der Mailingliste.

Hier die wichtigsten Fakten:

- Marcus Meissner vom Security Team hat bestätigt, dass es auch in Zukunft Sicherheitsupdate fuer kommende Versionen für openSUSE geben
wird (http://lists.opensuse.org/opensuse-factory/2014-01/msg00392.html).
- Der Release Manager und Member des openSUSE Teams Stephan Kulow (coolo) hat bestätigt, dass er auch am kommenden 13.2 Release
mitarbeiten wird
(http://lists.opensuse.org/opensuse-factory/2014-01/msg00416.html).
- Der Release der 13.2er Version ist für November geplant.
- Ein weiteres Ziel ist es, den sogenannten Factory Zweig, in dem openSUSE entwickelt wird, stabiler zu machen. Das würde laut Robert Schweikert kommende Releases deutlich einfacher machen
(http://lists.opensuse.org/opensuse-factory/2014-02/msg00140.html).
- Eine weitere Möglichkeit die sich daraus ergeben könnte, wäre eine Rolling Version von openSUSE Factory, die besonders für Entwickler interessant sein könnte.
- Tomáš Chvátal vom Release Team hat darauf hingewiesen, dass bereits viele Teile des


Montag
03. Februar 2014


face

Kaum hat man sich halbwegs an openSUSE’s 8 monatigen Releasezyklus gewöhnt, da gibt das Team nach einer einwöchigen Tagung in Nürnberg bekannt, dass openSUSE 13.2 nicht wie geplant im Juni 2014 erscheint. Und wer jetzt mit 2-3 Wochen Verspätung rechnet liegt falsch. Die 13.2 soll um mehrere Monate verschoben werden. Die offizielle Variante besagt, dass sich das openSUSE Team von Suse, welches sich bisher u.a. um die Releases gekümmert hat, erst mal um andere Sachen intensiv kümmern will / muss. Und es soll angeblich nicht nur bei dieser ungewöhnlichen Verschiebung bleiben, sondern openSUSE 13.2 soll auch strukturell überarbeitet werden.
Sicherlich, bei mir und bei vielen anderen läuft die 13.1 tadellos. Da kann man locker mit Leben und braucht nicht gleich wieder eine neue Version bzw. kommt erst mal ein Weilchen um eine Neuinstallation oder ein Upgrade herum. Die Verschiebung an-sich ist also gar nicht das Problem. Die Fakten, dass 13.2 strukturell überarbeitet werden soll und Michal Hrusecky in seinem Beitrag sogar von einem »Community-Release« ohne Mitwirken des Distributors sprach, sind da schon wesentlich interessanter.
Im Laufe der Diskussion wurde dann natürlich wieder der Releasezyklus in Frage gestellt. Ich werde das Gefühl nicht los, dass openSUSE sich mit den 8 monatigen Neuerscheinungen gewaltig übernommen hat.
Als Reaktion auf das folgende Unverständnis für diese Handlungsweise durch die Community haben sich einige Suseverantwortlichen zu Wort gemeldet.
Und zwar hat u.a. der bei Suse angestellte openSUSE Entwickler Stephan Kulow (Releasemanager) klargestellt, dass Suse sich nicht aus der Entwicklung von openSUSE zurückziehen will. Vincent Untz ergänzte, dass es auch nicht geplant sei, die bei Suse in Lohn & Brot stehenden Entwickler die an openSUSE tätig sind zu reduzieren. Okay, wenn das so stimmt ist das ja schon mal ein Lichtblick.
Ein gravierendes Problem, welches
openSUSE aber schon geraume Zeit mit sich herumschleppt ist, dass wohl zu wenig Paketbetreuer und Maintainer für openSUSE vorhanden sind, genau wie bei Packman, welches ja sehr wichtig für openSUSE ist. Wenn ich das richtig mitverfolgt habe, haben sich haufenweise Pakete und Projekte angesammelt um die sich niemand mehr kümmert.

Eins ist jedenfalls Fakt. Wenn das Gefüge bei openSUSE zwischen Mitwirkenden und Aufwand aus dem Gleichgewicht gekommen ist, muss sich etwas ändern damit die Distribution weiterhin erfolgreich bestehen kann.
Jetzt wird es interessant, welche Umstrukturierungen sich die Verantwortlichen einfallen lassen.

Solange jedenfalls… have a lot of Fun
mit 13.1.

Quelle: www.prolinux.de ( von Mirko Lindner)
Beitrag von Michal Hrusecky auf  http://article.gmane.org/gmane.linux.suse.opensuse.project/14784


Sonntag
02. Februar 2014


face

AMD Catalyst 14.1 Beta V1.3 (fglrx 13.35.1005) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-14.1-betav1.3.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.13.

Nachfolgende Release Notes von AMD zum AMD Catalyst 14.1 Beta V1.3:

Folgende Produkte werden zusätzlich unterstützt:

  • AMD A10-7850K
  • AMD A10-7700K

Neue Features:

  • RHEL 6.5 production support
  • openSUSE 13.1 production support
  • Ubuntu 13.10 production support
  • Xserver 1.15 support
  • Kernel 3.13 support

Folgende Probleme sind im Treiber behoben worden:

  • [386897] : System hang on resume from S4 with OpenGL screen saver running
  • [387678] : Backtrace occurs when kill X
  • [387664] : Failed to start X without kernel module loaded
  • [378620] : OpenCL test failure in CrossFire Mode
  • [386945] : piglit test “spec/ARB_copy_buffer/overlap” failed
  • [386710] : piglit test “spec/ARB_draw_buffers_blend” failed
  • [386818] : piglit test “spec/OpenGL 2.0/depth-tex-modes-glsl” failed
  • [386941] : piglit test “spec/ARB_blend_func_extended” failed
  • [386903] : piglit test “spec/OpenGL 3.0/gl-3.0-required-sized-texture-formats” failed
  • [386840] : Viewport goes blank when mouse cursor leaves when run Houdini on Ubuntu
  • [387596] : piglit test “spec/ARB_framebuffer_object (fbo-scissor-blit)” failed
  • [389174] : Failed to get fan speed on Bonaire card
  • [388110] : Intermittent flashing problem when running at 2560×1600
  • [372656] : Crash when resizing Konsole
  • [388325] : Brightness cannot be adjusted on Ubuntu 12.04 LTS
  • [388330] : piglit test “spec/ARB_framebuffer_object (fbo-blit-stretch)” failed
  • [385457] : Blue/white screen after using Google-chrome to run fishietank
  • [388500] : piglit test “spec/EXT_texture_integer” failed
  • [388802] : piglit test “spec/ARB_map_buffer_alignment” failed
  • [386396] : piglit test “spec/ARB_depth_buffer_float/fbo-depthstencil-drawpixels” failed
  • [389431] : Screens are distorted when connecting an external monitor on some Haswell platforms
  • [389530] : Blank screen/crash observed while running unigine heaven benchmark in windowed mode
  • [387124] : OpenCL performance drop observed on Hawaii compared to Tahiti XT
  • [386940] : piglit test “spec/EXT_texture_sRGB” failed
  • [392137] : [SteamOS] Failed to return to desktop from steam.
  • [392015] : [SteamOS] Screen is locked when changing user.
  • [392014] : [SteamOS] Failed to login Steam sometimes
  • [391231] : Blank screen observed while running steam games with Big picture

Offene Probleme:

  • [390964] : Stuttering and poor performance after playing an OpenGL game for a several minutes on Ubuntu
  • [393377] : Terminal panel stops refreshing until there is movement from mouse cursor
  • [392546] : System hang observed while hotpluging the stereo display
  • [388835] : Corruption and system hang observed while running Sanctuary BM with TFD enable
  • [392552] : Enabling Overlay: StartX , the screen shows corruption

Link: AMD Catalyst™ 14.1 LINUX Beta Driver Release Notes

Rezension zum AMD Catalyst 14.1:
AMD hat in ihrer Release Notes angemerkt, dass auch openSUSE 13.1 ab sofort unterstützt wird. Das hört sich erstmal erfreulich an. Nur leider hat das AMD Installer Team das falsche Packaging Skript von mir in dem Installer gepackt. Es war eines, welches 6 Monate alt war und noch aus der Zeit von AMD Catalyst 13.9 stammte. Damit sind auch andere Distributionen betroffen. Auf diesen Fehler habe ich


Mittwoch
29. Januar 2014


face

Das openSUSE-Team hat ab dem 27. Januar das Ende für die Unterstützung von openSUSE 12.2 bekannt gegeben. Alle, die noch die 12.2 im Einsatz haben, sollten jetzt spätestens auf eine offiziell unterstützte Version, wie 12.3 oder aktuell die 13.1, umsteigen. openSUSE 12.3 erhält noch bis November 2014 Updates und die 13.1 wird bis Mai 2015 gepflegt und darüber hinaus noch durch das Evergreen Projekt weiter bis November 2016 unterstützt.

openSUSE 12.2 war am 05. September 2012 erschienen und wurde somit über ca. 17 Monate mit 748 Updates versorgt. Davon waren 352 Sicherheitspatches. Laut. Benjamin Brunner von openSUSE waren das deutlich weniger als noch bei openSUSE 12.1.

Benjamin Brunner hat in seiner Ankündigung in der openSUSE Mailingliste speziell noch mal dem KDE-Team gedankt, die das erste mal ein  KDE Update (auf 4.8.5) ohne größere Probleme in eine laufende openSUSE Version eingebracht haben .


Sonntag
29. Dezember 2013


face

Endlich habe ich ein Gerät, mit dem ich openSUSE neben Windows 8 und mit UEFI Bios und aktivierten Secure Boot testen kann. Aber es gab schon einige Hürden gleich zum Beginn der Installation.

Hardware:

Es handelt sich um ein Toshiba Notebook Qosmio X70-A.

Prozessor: Intel Core i7MQ der vierten Generation

Festplatten: 256 GB SSD und 1,5 TB HDD

Arbeitsspeicher: 16GB

Grafikkarte: NVIDIA GeForce GTX 770M Optimus Technologie

vorinstalliertes OS: Windows 8 64Bit

Als erstes habe ich das openSUSE 13.1 KDE Live Medium 64Bit probiert.

1. Boot von USB

Mit der Taste F12 ruft man bei diesem Notebook das Bootmenü auf. Danach startet openSUSE 13.1 KDE Live sauber bis zum fertigen Desktop durch. Da war ich doch schon etwas beeindruckt. So problemlos hätte ich mir das gar nicht vorgestellt.

2. Installation des Live Mediums

Nachdem der schöne KDE Desktop so gleich nach dem ersten Live Start vor mir erstrahlte, wurde ich mutiger. Also kurzer Hand die Installation aus dem Livebetrieb gestartet. Das lief ebenso problemlos wie vorher der Livestart.
Da es mir wichtig war die Geschwindigkeit der schnelle SSD auch für Linux zu nutzen, habe ich die Linuxpartition / auf die SSD neben die Windowspartition gelegt. Die Partition /home und /swap habe ich dagegen auf die HDD gelegt. Dabei habe ich die /home Partition gleich noch verschlüsselt.
Tja, so ging die Installation erfolgreich zu Ende.
Beim ersten Neustart mit dem installierten System blieb, nach Auswahl von openSUSE im Bootmenü, erstaunlicherweise der Bildschirm dunkel. Nichts, außer ein blinkender Cursor oben links in der Bildschirmecke. Bei weiteren Startversuchen blieb der Start auch mal bei der Meldung ” … grafik interface … ” stehen.

Lösung: Das Problem liegt wohl beim KMS (Kernel Mode Setting) . Wenn der openSUSE Start sich mal wieder an der Stelle verabschiedet hat kann man mit der Tastenkombination “Alt”+”Strg”+”F2″ auf eine andere Konsole wechseln. Dort trifft man dann im Textmodus auf ein Login und muss sich als root und dem dazugehörigen Passwort anmelden. Danach sollte mit Eingabe von “startx” die grafische Oberfläche, sprich der KDE Desktop, starten. Wenn das denn geklappt hat, startet man YaST und wählt links “System” und danach in der rechten Fensterhälfte “Bootloader” . Es geht jetzt hier darum, dem openSUSE Systemstart die Option “nomodeset” mit auf den Weg zu geben. Dazu …

YaST starten und in der Rubrik

YaST starten und in der Rubrik “System” den Bootloader zum Bearbeiten auswählen.

Hier den Button

Hier den Button “Bootloader Optionen” anklicken.

Und hier in der Kernel Befehlszeile die Option

Und hier in der Kernel Befehlszeile die Option “nomodeset” ( ohne Anführungszeichen – wie auf dem Sceenshot ) einfügen.

Danach startet das installierte openSUSE 13.1 Live KDE sauber bis zum fertigen Desktop.

Einerseits war ich jetzt glücklich, andererseits aber noch nicht zufrieden. Ich bevorzuge die Installation des openSUSE DVD Mediums. Also ran da … ;-)

3. Booten und Installation vom DVD Medium

Wenn man vom openSUSE DVD Medium ( ich habe das ISO wieder auf einem USB Stick benutzt ) bootet bekommt man nach dem Willkommens Bildschirm eigentlich dieses DVD Menü.

Bootmenü openSUSE 13.1 DVD 64Bit mit herkömmlichen Bios

Bootmenü openSUSE 13.1 DVD 64Bit mit herk


Samstag
21. Dezember 2013


face

AMD Catalyst 13.12 (fglrx 13.251) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.12.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.13.

[UPDATE 21.03.2014]
Das Packaging Skript für AMD Catalyst wurde aktualisiert und ein Kernel-Patch hinzugefügt. Ab sofort wird Kernel 3.14 unterstützt.
[/UPDATE 21.03.2014]

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.12:

Folgende Probleme sind im Treiber behoben worden:

  • [384861]: Ultra slow dota2 fps
  • [383176]: System hang when startx after enable Eyefinity
  • [383109]: System hang when run Unigine Heaven 4.0
  • [382494]: Screen corruption when run C4Engine with GL_ARB_texture_array enabled
  • [384193]: Fix the procfs permission issue on kernel 3.10 and later
  • [373812]: System hang when run some OpenGL stress test
  • [383430]: Glxtest failed with force AA
  • [383372]: Fail to launch cairo-dock
  • [384509]: glClientWaitSync is waiting even when timeout is 0
  • [383573]: AC/DC switching is broken
  • [384194]: Tear-Free Desktop sets V-Sync to 30Hz instead of 60Hz
  • [385123]: CrossFire aspect observed in CCCLE where it should not
  • [385414]: Steam crashes and games hang on a black screen when Force AA is on
  • [387027]: Glxtest failed on SLED11 SP3
  • [382079]: MARI crash with weird stack
  • [387797]: X crash when kill X with Xserver 1.13 and 1.14
  • [389431]: Screens are distorted when connecting an external monitor on some PowerXpress platform with Intel Haswell
  • [389728]: Segfault after disabling display on re-launch of CCCLE
  • [387573]: Soft hang and error observed on BasicDebug sample for OpenCL when run on x86
  • [385704]: Black window when run glxgears with TWM
  • [376115]: Display corruption when using rotation

Link: AMD Catalyst™ 13.12 LINUX Driver Release Notes

Rezension zum AMD Catalyst 13.12:
Aus der Release Notes geht hervor, dass der Treiber offiziell bis Kernel 3.11 unterstützt. Mit dem letzten Beta-Treiber konnte man das fglrx-Kernelmodul auch noch für Kernel 3.12 bauen und wäre in diesem Sinne ein kleiner Rückschritt. :( Leider hat AMD den Vogel abgeschossen und die Folge war, dass das fglrx-Kernelmodul gar nicht erst mit dem Kernel 3.8 oder höher kompiliert. Alle Linux-Distributionen sind von diesem Fehler betroffen. :-?

Außerdem gab es noch weitere Missgeschicke von AMD, dass ich meinen Frust im nicht-öffentlichen AMD-Forum für Beta-Tester freien Lauf ließ, in der auch die AMD-Entwickler mitlesen. AMD hat einfach versäumt, den finalen Treiber vor der Freigabe ordentlich auf einem x-beliebigen Linux-System zu testen. :evil: Daher hatte ich auch am Tag des Release keine Lust gehabt, die Fehler von AMD überall noch zu beheben.

Nun ja, ich habe doch den Versuch gewagt und den Treiber soweit zum Laufen gebracht, dass dieser sogar auf dem kommenden Kernel 3.13 läuft. AMD macht echt für einen Paketbetreuer wie mir das Leben schwer. :( Dabei will ich einfach nur einen Treiber haben, der sich ohne Problem auf openSUSE installieren


Mittwoch
11. Dezember 2013


face

Dieses mal hat es ein bisschen länger gedauert und viele haben schon drauf gelauert. Deswegen ist es auch einen kleinen Hinweis wert, dass ab heute das NVIDIA Repository für openSUSE 13.1 verfügbar ist.

Es kann im YaST über die “Community Repositories” aktiviert werden

NVIDIA Repository in der Community Repo-Liste

NVIDIA Repository in der Community Repo-Liste

oder auch von Hand mit dieser Adresse  ftp://download.nvidia.com/opensuse/13.1/

eingepflegt werden.

Alternativ natürlich auch über den Link http://de.opensuse.org aus dem deutschen openSUSE Wiki.

Bei der nächsten Systemaktualisierung per YaST oder Zypper werden denn die entsprechenden Treiberpakete automatisch installiert.


Sonntag
24. November 2013


face

Erst vor kurzem ist die neueste openSUSE-Distribution herausgekommen und nun will man die Distribution via “zypper dup” upgraden. Die meisten openSUSE-User müssen erstmal nach einer Anleitung im Internet suchen und diese dann Schritt für Schritt durchgehen. Das kann eine einfache oder auch eine komplizierte Angelegenheit werden.

Aus diesem Grund habe ich ein Skript upgrade-opensuse.sh entwickelt, dass alle notwendigen Schritte eines Distributionsupgrades automatisch durchführt. Die Vorgehensweise des Skript ist ganz grob an das Upgrade-Tool do-release-upgrade von Ubuntu angelehnt. Wenn alle Pakete von zypper korrekt aufgelöst werden kann, ist es sogar möglich, dass der Upgrade-Prozess in einem Rutsch durchläuft und man am Ende nur noch neustarten muss. Das Skript merkt sich auch die Stelle, an der der Upgrade-Prozess abgebrochen wurde und wird beim erneuten Ausführen an der letzten Stelle fortfahren. So kann man zwischendurch ein Problem beheben und anschließend mit dem Upgrade-Prozess fortfahren.

Folgende Schritte werden durchgeführt:

  • Ermittelung der eingesetzten openSUSE-Version.
  • Überprüfung der Internetverbindung.
  • Ermittelung der neuesten openSUSE-Version.
  • Backup vom /etc Verzeichnis.
  • Umbenennung des Verzeichnis der eingebunden Repos /etc/zypp/repos.d nach /etc/zypp/repos.d.upgrade.
  • Hinzufügen der Online-Repos (OSS, NON-OSS, OSS Update, NON-OSS Update) von der neuesten openSUSE-Version.
  • Upgrade der Distribution via zypper dup (Ohne Community-Repos, um ungewollte VendorChanges zu vermeiden).
  • Hinzufügen aller vormals aktivierten Community-Repos.
  • Temporäre Modifizierung der zypper Konfiguration, um VendorChanges zu erlauben.
  • Überprüfung von alten openSUSE-Pakete im System. Es wird versucht, die alten Pakete durch neuere Pakete zu ersetzen.
  • Rückgangig machen der temporäre Modifizierung der zypper Konfiguration.
  • Alte openSUSE-Pakete, die nicht aktualisiert werden konnten, werden endgültig entfernt.
  • Auflistung aller neuen bzw. modifizierten Konfigurationsdateien (*.rpmnew, *rpmsave).

Alle Vorgänge werden protokolliert, um später nachzuvollziehen, was genau am System verändert wurde.

Folgende selbsterklärenden Logdateien werden erzeugt:

  • upgrade-opensuse.zypper-dup-output
  • upgrade-opensuse.old-packages-output
  • upgrade-opensuse.zypper-reinstall-packages-output
  • upgrade-opensuse.remove-old-packages-output
  • upgrade-opensuse.zypper-rm-packages-output
  • upgrade-opensuse.list-new-and-old-config-files

Wichtiger Hinweis: Vor einem Distributionsupgrade bitte unbedingt ein Backup machen, um im Bedarfsfall auf ein aktuelles Backup zurückgreifen zu können! Außerdem gibt es z.B. RPM Pakete von Drittanbietern wie z.B. AMD Catalyst, NVIDIA, VirtualBox, CrossOver, HumbleBundle-Games, usw., die während des Upgrade-Prozess nicht angerührt werden und von Hand aktualisiert werden müssen.

Downloads:

Das Skript wird via root ausgeführt und fängt sofort mit der Arbeit an. Es gibt zu Beginn ein Zeitfenster von 5 Sekunden, in der noch ein unkritischer Abbruch mit STRG+C möglich ist.

sudo sh upgrade-opensuse.sh
-h Die Hilfe anzeigen lassen
-n/–non-interactive Keine Fragen stellen, benutze automatisch Standard-Antworten. (zypper Option)
-r/–reset Beginne das Disributionsupgrade von vorne (Die Option bitte vorsichtig verwenden!)
-V Version des Skript anzeigen

Feedbacks sind wie immer willkommen. :-)

War dieser Artikel für dich hilfreich und/oder konnte dein Problem lösen? Wie wäre es mit einer kleinen Spende (Flattr, Paypal oder Überweisung) für den Erhalt des Blogs und zur Förderung weiterer interessanter Artikel und Skripte? Zudem ist mit jeder Spende


Samstag
23. November 2013


face

AMD Catalyst 13.11 Beta V9.4 (fglrx 13.25.18) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.11-betav9.4.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.12.

Der Beta-Treiber unterstützt jetzt von Haus aus Kernel 3.12. Daher habe ich meinem Patch im Packaging Skript zur neuen Beta-Version wieder entfernt.

Wie gehabt habe ich noch das störende Beta-Wasserzeichen in der unteren rechten Ecke entfernt.

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.11 Beta V9.4:

Folgende Probleme sind im Treiber behoben worden:

  • [372656] : Resolves crash when resizing Konsole
  • [388325] : Resolves brightness adjustment issues
  • [388818] : Resolves kernel module compile failure when CONFIG_UIDGID_STRICT_TYPE_CHECKS is enabled
  • [388335] : Avoids the new GPL symbol acpi_bus_get_device for new kernel support
  • [386897] : Resolves system hang on resume from S4 with OpenGL screen saver running

Link: AMD Catalyst™ 13.11 LINUX Beta V9.4 Driver Release Notes

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2013/01/25/opensuse-amd-catalyst-13-1-legacy-treiber-als-rpm-installieren/

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-13.11-betav9.4.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

-b Nur das RPM-Package bauen (Standard)
-c <type> Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d Nur den AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese in eine Datei namens amd-report.txt
-u|–uninstall entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene AMD-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt.
-ur|–uploadreport wie Option –report nur

Mittwoch
20. November 2013


face

Hier mal ein kurzer Tipp, der nicht unbedingt etwas mit openSUSE zu tun hat, sondern mit dem KDE Dateimanager Dolphin. Ein Option die ich häufig gebrauche ist das direkte Löschen von Dateien ohne Umweg über den Papierkorb. Und jetzt bei der Neuinstallation von openSUSE 13.1 KDE Live war es mal wieder soweit. Diese Option gibt es im KDE Dateimanager Dolphin. Sie ist aber standardmäßig nicht aktiviert und zudem recht gut versteckt.

Wenn wir den KDE Dateimanger Dophin starten haben wir oben in der Menüleiste den Eintrag

Wenn wir den KDE Dateimanger Dophin starten haben wir oben in der Menüleiste den Eintrag ” Einstellungen”. Nach einem Klick darauf öffnet sich ein Dropdown Menü mit Einstellungsoptionen. Weiter unten ist die Option die wir jetzt brauchen, mit dem naheliegenden Namen: “Dolphin einrichten”

In den

In den “Dolphin Eigenschaften” navigieren wir links in die Option “Dienste” und scrollen danach rechts runter bis zu dem Punkt “Löschen” Machen da einen Haken rein und schon ist die gewünschte Option verfügbar.

Danach haben wir im Dolphin, wenn wir mit der rechten Maustaste eine Datei anklicken den neuen Eintrag

Danach haben wir im Dolphin, wenn wir mit der rechten Maustaste eine Datei anklicken den neuen Eintrag “Löschen”.

Aber Vorsicht! Es kommt zwar noch eine Sicherheitsabfrage nach dem Mausklick auf “Löschen” ( ganz Mutige können auch diese noch unterbinden ;-[ ) aber wenn man da weitermacht wird die Datei wirklich gelöscht. Sie kann nicht aus dem Papierkorb wieder hergestellt werden.

PS: Wenn ich hier “wirklich gelöscht” schreibe, meine ich das nur “Anwendermäßig” und nicht, daß sie rein technisch nicht wieder herzustellen sei. Die Datei ist NICHT unwidebringlich vernichtet. Es wurde nur der KDE Papierkorb umgangen und die Datei ist für das System und den Benutzer nicht mehr verfügbar.  Mit etwas Aufwand und einge fachliche Kenntnisse kann so eine Datei wieder hergestellt werden.


face

Wenn man sich das openSUSE KDE Live Medium auf den Rechner installiert ist es schon seit mehreren Ausgaben nötig nachträglich die deutsche Übersetzung für KDE nachzuladen. Und das ist auch bei openSUSE 13.1 nicht anders. Keine große Sache.

Gleich nach der Installation von openSUSE 13.1 KDE Live stellt man fest, die deutsche Übersetzung in KDE fehlt.

Gleich nach der Installation von openSUSE 13.1 KDE Live stellt man fest, die deutsche Übersetzung in KDE fehlt.

Einfach eine Paket- bzw. Softwareaktualisierung machen, z.Bsp. per YaST und die fehlenden Sprachpakete werden automatisch mitgeladen.

Einfach eine Paket- bzw. Softwareaktualisierung machen, z.Bsp. per YaST und die fehlenden Sprachpakete für KDE werden automatisch mit geladen.

Nach einem Neustart sieht's dann schon

Nach einem Neustart sieht’s dann schon wesentlich  “deutscher” aus. ;-)


Dienstag
19. November 2013


face

AMD Catalyst 13.11 Beta V6 (fglrx 13.20.18) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.11-betav6.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.12.

Dank eures Feedbacks habe ich folgende Änderungen eingepflegt:

  • Kompatibilitätspatch für Kernel 3.12
  • Fehlerhafter Symlink zum 32-bit OpenGL auf einem 64-bit openSUSE System behoben
  • Der direkte Download des Treiber vom AMD-Server funktioniert mit einem kleinen Hack wieder

Die Installation des Treibers auf dem heute am 19.11.2013 veröffentlichten openSUSE 13.1 verlief ohne Problem. 32-bit wie auch 64-bit OpenGL-Spiele funktionieren einwandfrei. Genauso wurde auch Steam mit meinem Referenzspiel “Euro Truck Simulator 2″ sowohl 32-bit als auch 64-bit getestet und lief genauso flüssig.

Wie gehabt habe ich noch das störende Beta-Wasserzeichen in der unteren rechten Ecke entfernt.

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.11 Beta V6:

Unterstützung von neuen Grafikkarten

  • AMD Radeon R9 290 SeriesX

Folgende Probleme sind im Treiber behoben worden:

  • [387659] Fixes X crash when kill X server with Xserver 1.13 and above
  • [386508] Fixes fd leak with Application Profile feature
  • [386511] Fixes kernel module build failure with kernel 3.9.1

Link: AMD Catalyst™ 13.11 LINUX Beta V6 Driver Release Notes

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten Fehler zu reproduzieren. Zusammen mit den nötigen System-Informationen werde ich mich direkt an die richtige Stelle bei AMD wenden, um den Bug in der nächsten Treiber-Version beheben zu lassen. Danke schön. :-D

Für Benutzer älterer AMD Grafikkarten (Radeon HD Serie 2000 – 4000) wird dringend die Installation dieses Treibers abgeraten. AMD hat einen Legacy-Treiber zur Verfügung gestellt. Mehr Informationen zum Legacy Treiber: http://www.sebastian-siebert.de/2013/01/25/opensuse-amd-catalyst-13-1-legacy-treiber-als-rpm-installieren/

Downloads:

Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-amd-Skript

Über das makerpm-amd-Skript

Das Skript makerpm-amd-13.11-betav6.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.

Folgende Argumente können dem Skript übergeben werden:

-b Nur das RPM-Package bauen (Standard)
-c <type> Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d Nur den AMD-Installer downloaden
-i Das RPM-Package bauen und installieren bzw. updaten
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-nohw Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM)
-old2ddriver <yes|no> den alten 2D-Treiber aktivieren oder deaktivieren
-r|–report erstellt ein Report und speichert diese

Dienstag
15. Oktober 2013


face

AMD Catalyst 13.11 Beta V1 (fglrx 13.20.16) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.11-betav1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3, 13.1 sowie bis Kernel 3.11.

In eigener Sache: Ich möchte mich bei allen Spendern zur Förderung des Installationsskripts für den AMD Catalyst Treiber unter openSUSE wie auch den Erhalt des Blogs ganz herzlichst bedanken. Somit ist es mir möglich, diesen Blog weiterhin werbefrei zu halten. In der letzten Zeit habe ich nicht gerade wenige Angebote erhalten, über einen einfachen Blog-Artikel zu einem Produkt in Zusammenhang mit Linux in eigenen Worten zu schreiben. Erstens kommt für mich Schleichwerbung gar nicht in Frage und zweitens soll dieser Blog nicht mit irgendwelchen dubiosen Produkten zugemüllt werden. Es kann weiterhin via Flattr, PayPal, Überweisung oder auch per Post gespendet werden. Nochmal vielen Dank für eure Unterstützung. ;-)

Ab sofort habe ich die Unterstützung für openSUSE 13.1 RC1 eingepflegt und wurde von mir ausgiebig getestet. Kleiner Tipp: Sollte es beim Verschieben eines Fensters unter openSUSE 13.1 mit KDE 4.11.2 zum Tearing kommen, dann empfehle ich in der KDE-Einstellung der Arbeitsflächen-Effekte unter Erweitert die OpenGL-Einstellung für “Einzelbild-Zerreißen (Tearing) verhindern (VSync)” auf “Bildschirm-Inhalt wiederverwenden” zu setzen.

Zudem habe ich ein kleinen Bugfix für openSUSE 13.1 RC1 in das makerpm-amd-Skript integriert, dass ein Problem mit der inkorrekten Formatierung von /etc/SuSE-release in Zusammenhang mit dem Kommandozeilten-Tool lsb_release behebt (Siehe Bugreport #845262). Das Tool lsb_release kann dann die korrekten Daten zu openSUSE zurückliefern. Ohne diese Korrektur funktioniert die automatische Erkennung nicht mehr.

Wie gehabt habe ich noch das störende Beta-Wasserzeichen in der unteren rechten Ecke entfernt.

Nachfolgende Release Notes von AMD zum AMD Catalyst 13.11 Beta V1:

Unterstützung von neuen Grafikkarten

  • AMD Radeon R9 280X
  • AMD Radeon R9 270X
  • AMD Radeon R7 260X
  • AMD Radeon R7 250
  • AMD Radeon R7 240

Folgende Probleme sind im Treiber behoben worden:

  • [383176] System hang up when startx after setting up an Eyefinity desktop
  • [384193] Permission issue with procfs on kernel 3.10
  • [373812] System hang observed while running disaster stress test on Ubuntu 12.10
  • [383109] Hang is observed when running Unigine on Linux
  • [383573] AC/DC switching is not automatically detected
  • [383075] Laptop backlight adjustment is broken
  • [383430] Glxtest failures observed in log file with forcing on Anti-Aliasing
  • [383372] Cairo-dock is broken
  • [378333] Severe desktop corruption is observed when enabled compiz in certain cases
  • [384509] glClientWaitSync is waiting even when timeout is 0
  • [382494] C4Engine get corruption with GL_ARB_texture_array enabled

Link: AMD Catalyst™ 13.11 LINUX Beta V1 Driver Release Notes

Eine kleine Bitte habe ich: Wenn irgendwelche Probleme mit dem Treiber auftauchen, scheut euch nicht mir zu berichten (Ich nehme deutsche und englische Bugreports gerne entgegen). ;-) Ich werde versuchen, soweit es mir möglich ist, den gemeldeten


Dienstag
01. Oktober 2013


face

Plasma Active ist eine User Experience für Tablet PC's und Smartphones. Sie ist einfach zu benutzen und (meist) intuitiv zu bedienen und ebenfalls vollständig Open Source.

Ich freue mich sehr, mein erstes Buch im Eigenverlag bekannt zu geben. Das Handbuch ist ein Startup-Guide zu Plasma Active. Ausserdem beinhaltet es Grundlagen, wie USB-Erstellung, Installation, Benutzung als PIM und vieles mehr.

Die Projektseite ist verfügbar unter: http://pactivehandbook.sourceforge.net. Dort finden Sie die Docbook Quelldaten, ein online lesbares HTML-Handbuch, sowie die letzten PDF's. Das beste: Es ist kostenlos zu beziehen. Wenn Sie den Autor unterstützen möchten, können Sie eine Druckversion bestellen. Einfach auf den Button drücken.

Support independent publishing: Buy this book on Lulu.

 Ideen und Tips jederzeit willkommen :-)

Enhanced by Zemanta

Sonntag
22. September 2013


face

In diesem Artikel beschreibe ich den Umzug von openSUSE 12.3 auf eine SSD. In meinem Fall gehe ich auf die Samsung SSD 840 Pro (512 GB) ein. Die Anleitung funktioniert auch mit anderen SSDs von der Samsung Pro-Serie.

Wichtig: Die Befehle im Artikel müssen als root ausgeführt werden. Hier ist die Partitionszuordnung nur als Beispiel anzusehen und muss an die Gegebenheiten vom eigenen System angepasst werden.

Inhalt:

  • Prolog
  • Aktivierung der Host Protected Area (HPA) / Stichwort: Over-Provisioning
  • Partitionierung / Dateisystem
  • Umzug von openSUSE
  • Anpassung an die neue Umgebung

Prolog

Meine 5 Jahre alte Festplatte (Samsung HD753LJ / 750 GB) hatte nicht nur Windows XP überstanden, sondern auch die Anfänge mit openSUSE und diverse andere Linux-Distributionen, die ich zum Test auch heute noch nebenbei installiert habe. Irgendwann wollte ich ein Kernelmodul unter openSUSE bauen. Dabei kam es immer an derselben Stelle zu einem Lesefehler und der Kompiliervorgang wurde abgebrochen. Leider hat mir das S.M.A.R.T.-Monitoring-Tool nicht gutes mitzuteilen und nach einer Überprüfung der Festplatte via fsck kamen auch weitere fehlerhafte Blöcke zum Vorschein. Herbe Datenverluste waren in meinem Fall nicht zu erwarten, obwohl einige Dateien unwiederbringlich verloren gegangen sind. Zum Glück war nur die root-Partition betroffen und konnte die fehlerhaften Dateien durch die Reinstallation des betreffenden RPM-Pakets wiederherstellen. Meine home-Partition war noch in Ordnung. Im Notfall habe ich noch ein aktuelles Backup. Dennoch ist mein Vertrauen in die Festplatte stark gesunken. So kam prompt die Entscheidung eine SSD zu holen, die ich vor langer Zeit eingeplant habe. Zu diesem Thema habe ich mich intensiv auseinander gesetzt und mich letztendlich für die Samsung SSD 840 Pro mit 512 GB entschieden.

Aktivierung der Host Protected Area (HPA)

Kurz vorweg: Was ist eigentlich HPA bzw. Over-Provisioning?
Das ist für das Betriebssystem ein unsichtbarer Datenbereich (Spare Area). Sie dient dazu Lese- und Schreibvorgänge zu optimieren (Read-Modify-Write), Ersatz für fehlerhafte Blöcke (Badblocks Replacement), optimale Ausnutzung der Speicherzellen (Wear-Leveling).

Bei der Samsung SSD Pro-Serie ist das HPA-Feature werksseitig deaktiviert. Sie lässt sich ohne Probleme aktivieren und wird ausdrücklich empfohlen. Eine nachträgliche Aktivierung von HPA ist mit Datenverlust verbunden. Daher sollte man sich mit diesem Thema früh genug auseinandersetzen. Bei einer nagelneuen SSD ist es ein guter Zeitpunkt das HPA-Feature zu aktivieren und sich über die Größe der Spare Area Gedanken zu machen.

Wie groß darf denn die Spare Area sein?
Es gibt je nach Nutzung unterschiedliche Werte, die lediglich auf Empfehlungen basieren. Wir sprechen hier im Bereich von 7% (Empfehlung von Samsung) bis 27% (Empfehlung von Intel) des reservierten Datenbereichs. Für meine Zwecke habe ich die Empfehlung von Samsung (7%) modifiziert und nochmal 3% daraufgelegt. Meines Erachtens sind 10% Spare Area mehr als genug. 10% von 512 GB entspricht 51,2 GB. Also, habe ich am Ende 460,8 GB nutzbaren Datenbereich.

Jetzt müssen wir herausfinden, auf welchem Device-Pfad die SSD zugeordnet ist:

hwinfo --disk | grep -E 'Model|Device File:'

Die Ausgabe von meinem System:

Model: "Samsung 

Mittwoch
04. September 2013


face

cooltek2 Hier einmal ein Bauvorschlag für einen kleine, aber Leistungsfähigen Computer, der sehr gut durch den Alltag kommt. Ziel von mir war es, einen kleinen, stromsparenden (im Vergleich zu Leistung) und leisen PC zu bauen.

Dazu verwendete ich folgende Bauteile:

  • Mainboard: Asus P8Z77-I DELUXE
  • Prozessor: Intel Core i5-3570K 3400
  • RAM: 8GB Tactical K2
  • Gehäuse: Cooltek Coolcube Mini
  • SATA-Kabel: Nanoxia SATA 3.0 Kabel abgewinkelt 45cm
  • Netzteil: SilvStone SST-ST45SF V2 450W SFX
  • Gehäuselüfter: NB BlackSilentPRO PR-1 60x60x25
  • Kühlkörper: Prolimatech Samuel 17
  • CPU-Kühler: EKL Alpenföhn Wing Boost 12 cm (4,7 Zoll) Lüfter

Das ganze System kommt ohne extra Grafikkarte, sollte aber zwei digitale Grafikausgänge haben. In dem Fall hier ein Displayport und DVI Ausgang. Die aktuellen Ivy-Bridge CPUs unterstützen bis zu zwei Digitale Ausgänge. Ist noch eine analoger Anschluss dabei, kann dieser nicht verwendet werden bzw. es muss auf einen digitalen Anschluss verzichtet werden. Was die Grafikkartentreiber angeht, muss man sich bei Intel keine Gedanken machen, da die Treiber eh OpenSource sind und so standardmäßig im Linuxkernel liegen.

cooltek1

Das Gehäuse ist ein Coolcube Mini von der Marke Cooltek. Zu beachten ist, dass es wirklich ,,Mini” ist. Als Netzteil passen nur SFX-Formfaktor Stromspender hinein. Hier ist der Markt noch relativ dünn gesäht. Auch muss bei dem CPU-Lüfter aufgepasst werden, da dieser nicht höher als ca. 7,5 cm sein darf. Festplatten passen entweder eine 3,5 Zoll oder zwei 2,5 Zoll Festplatten / SSDs hinein. Sollten zwei 2,5 Zoll Platten eingebaut werden, muss darauf geachtet werden, dass der optionale 60mm Gehäuselüfter nicht zu tief ist. Ansonsten stößt dieser gegen eine der beiden Platten, so dass dies dann nicht mehr passt.

Der Einbau ist ziemlich frickelig, da hier nur wenig Platz zur Verfügung steht. Als erstes sollte das Mainboard mit CPU-Kühlkörper eingebaut werden. Alle unter dem Kühlkörper liegenden Verkabelungen zuerst vornehmen. Zuerst das Mainboard verschraube, bevor der CPU Kühler angeschraubt wird, da er die Schrauben verdeckt. Nun alle Verkabelungen vornehmen und zuletzt das Netzteil einbauen. Am besten ist es, den CPU-Lüfter so montieren, dass die Luft von der CPU weggeblasen wird (das Netzteil natürlich mit Lüfter zum Mainboard zeigend. So kann die Warme Luft über das Netzteil nach außen transportiert werden. Ein kleiner leiser zusätzlicher Gehäuselüfter transportiert frische kühle Luft in das Gehäuse hinein.

$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +106.0°C)
temp2: +29.8°C (crit = +106.0°C)
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +43.0°C (high = +85.0°C, crit = +105.0°C)
Core 0: +37.0°C (high = +85.0°C, crit = +105.0°C)
Core 1: +42.0°C (high = +85.0°C, crit = +105.0°C)
Core 2: +42.0°C (high = +85.0°C, crit = +105.0°C)
Core 3: +36.0°C (high = +85.0°C, crit = +105.0°C)

Die


Sonntag
01. September 2013


face

froscon13Da ich dieses Jahr arbeitsbedingt Samstag verhindert war, konnte ich nur am zweiten Tag an der FrOSCon teilnehmen. Zum Glück sprang Jörg Stephan noch kurzfristig ein und organisierte einen openSUSE Stand (unter anderem mit ZFS auf openSUSE)

Da es am Sonntag erwartungsgemäß ruhig war, zog ich auch meine Runden und quatsche eine Runde mit den Leuten von Magiea sowie Arch Linux. Letztlich habe ich es sogar noch zu zwei interessanten Vorträgen geschafft. Besonder der Talk von Uwe Ziegenhagen - Python und LaTeX vereint fand ich sehr interessant. Sollte ich mal wieder Luft haben, werde ich mir dies auf jedenfall mal genauer ansehen.

Ansonsten gibt es meinerseits nicht viel von der FrOSCon zu berichten. Sollte nichts dazwischen kommen sehen wir uns im November 2013 auf der OpenRheinRhur.


Samstag
31. August 2013


face

1. Vorwort
2. SSH / SFTP – Installation und Konfiguration
3. ES Datei Explorer – Zugriff einrichten
4. AutoShare – Zugriff einrichten
5. Fail2Ban – Server absichern
6. SFTP – Speicher mit Dolphin öffnen

1. Vorwort
Wer seine Daten lieber auf dem eigenen Speicherplatz weiß und dennoch nicht auf die bequemen Funktionen einer Cloud verzichten möchte (oder kann), der wird eine Weile nach Lösungen suchen können. Man sollte annehmen, dass in Zeiten von Dropbx und Co. zahlreiche Scripte für den heimischen Server bereit stehen. Weit gefehlt – denn neben OwnCloud gibt es nur sehr wenige Alternativen (u.a. Seafile, Ajaxplorer). Diese mögen zwar auf einem schnellen Server auch gut laufen und mit Features glänzen, allerdings kann man auf einem Raspberry Pi an der Geschwindigkeit verzagen. Dabei bietet Linux mit SSH schon alles an, was man für eine “Cloud light” braucht.

Meine Lösung:
SFTP-Zugang (nicht zu verwechseln mit FTPS)
Datei-Verwaltung im Browser mittels eXtplorer (eXtplorer auf dem Raspberry Pi installieren) und SSL
Datei-Verwaltung mit Android: ES Datei Explorer / AutoShare
Datei-Verwaltung mit Linux über Dolphin

___

2. SSH / SFTP – Installation und Konfiguration
sftp
Quellen:
http://www.gambaru.de/blog/2011/08/11/sicherer-datentausch-ein-sftp-server-mit-chroot/ (PDF)
http://www.hack-job.org/how-tos/sftp-downloads-to-the-rescue/ (PDF)
http://madapez.com/it/linux/howto-chroot-sftp-zugang-openssh-ohne-shell-ssh/ (PDF)

Ich setze nun voraus, dass SSL schon auf dem Raspberry Pi installiert ist (was in den meisten Beschreibungen der Fall ist) – wenn nicht, dann “sudo apt-get install ssh” ;)

1. Gruppe “nas” anlegen:

sudo addgroup nas


Weiter unten habe ich einen Kombinations-Befehl aufgeschrieben, der alle nötigen Schritte zum Anlegen eines neuen Users auf einmal ausführt, ich empfehle jedoch mindestens einmal diesen hier beschriebenen Weg zu gehen, damit ihr wisst, was die Befehle überhaupt bewirken.

2. Wir legen einen User an,
dem vorerst der Zugriff “nur lesen” gewährt wird.
loader” steht dabei für den Username. Ihr könnt den Namen frei wählen, müsst dann natürlich unten überall bei loader den gewählten Namen ersetzen.
Mit diesem Namen loggen wir uns dann später in Kombination mit dem Passwort auf dem Server ein.

Es soll sein Home-Verzeichnis automatisch angelegt werden (-m), er soll keinen Shell-Zugang bekommen (-s /bin/false) und er soll der Gruppe “nas” angehören (-G nas):

sudo useradd -m -s /bin/false -G nas loader
# alt: sudo useradd --create-home --home-dir /home/loader --shell /bin/bash loader

Passwort anlegen:

sudo passwd loader


Home/Loader-Ordner “absichern”

(bzw. dem Benutzer root zuweisen)
Damit erhält der User “loader” auf seinen home-Ordner nur Lese-Rechte. Später erhält er seinen “eigenen” Unterordner zum schreiben (uploaden)

sudo chown root.root /home/loader
sudo chmod 0755 /home/loader


optional: Speicherort festlegen

Ich habe nun versucht mittels folgende Anleitung PDF einen USB-Stick einzubinden und diesen als Speicher zu nutzen.
Leider war mir dies bis jetzt nicht möglich, da chroot misslingt. Ansonsten hätte es so ähnlich funktioniert:

sudo mkdir /media/usbstick/loader
sudo chown root.root /media/usbstick/loader
sudo mkdir /media/usbstick/loader/uploads
sudo chown loader.loader /media/usbstick/loader/uploads 

Donnerstag
22. August 2013


face

mysqlbackup

Ein kurzer Tipp für eine automatisierte Sicherung der MySQL Datenbank eures Pi (im laufenden Betrieb der DB):
Quelle: http://www.codingepiphany.com/2013/06/12/raspberry-pi-lamp-server-tuning-and-automated-db-backup/

2. Update 23.08.2013 / 19:45:
Dank dem Hinweis von Shogun im Kommentarbereich, rufen wir das Datenbank-Passwort aus Sicherheitsgründen aus einer externen Datei ab.
MySQLdump bedienen wir dabei mit der Datei .my.cnf

# Passwort-Datei anlegen
cd ~
sudo nano .my.cnf

In der .my.cnf jetzt eingeben (die ??? natürlich durch eure Daten ersetzen):

[client]
host=localhost 
user=???   
password=???

Speichern und schließen.

Jetzt dbbackup.sh anlegen:

cd ~
sudo nano dbbackup.sh

Folgendes Script dort einfügen (Datenbank-Name anpassen – z.B. “tt-rss” für eine Sicherung von Tiny Tiny RSS ):

#!/bin/bash
OUTPUT_FILE=/home/pi/datenbankbackup-$(date +%Y%m%d).bz2
DATABASE_NAME="????"

mysqldump --defaults-file=.my.cnf $DATABASE_NAME | bzip2 > $OUTPUT_FILE

Das ganze speichern (Strg + O) und wieder schließen (Strg + X), danach noch chmod:

sudo chmod 755 dbbackup.sh

Jetzt kann man schon Sicherungen durchführen (sudo sh dbbackup.sh)

Für eine automatische Sicherung ist nur noch der Eintrag in Crontab nötig:

sudo crontab -e

Dort für eine tägliche Sicherung eintragen:

01 00 * * * /home/pi/dbbackup.sh

oder für eine wöchentliche Sicherung:

01 00 * * 6 /home/pi/dbbackup.sh

 


Freitag
16. August 2013


face

Wer programmtechnisch auf das Betriebssystem aus Redmond angewiesen ist, wird sich vielleicht schon einmal die Frage gestellt haben, wie man dieses neben Linux installieren kann. Nun ist es zwar recht einfach, erst Windows, dann Linux zu installieren, da der Bootloader von Linux die Windows-Installation erkennt und diese dann in Grub einbindet, anders herum zerschießt man sich aber auch mal ganz schnell das Bootmenü.

Die einfachste Variante ist es, das weitere Betriebssystem auf einer zweite Festplatte zu installieren. Dazu klemmt man die andere(n) Platte(n) zuerst ab und installiert Windows ganz normal auf der neuen. Wenn der Installationsvorgang abgeschlossen ist, schließen wir alles wieder an und starten normal in Linux (die Linux-Platte muss evtl. über das Bios-Bootmenü ausgewählt werden).
In Linux habe ich nun “Bootloader” (unter Yast oder direkt eingeben) aufgerufen und die Anzeigezeit unter Grub-Einstellungen auf 8 Sekunden gesetzt, gespeichert und neu gestartet… und siehe da, Grub hat automatisch die neue Platte nebst Windows erkannt und bietet diese in der Betriebssystem-Auswahl an. So einfach kann es also sein.

Datei YaST Module Bootloader Bootloader Install.png – openSUSE Datei YaST Module Bootloader Optionen.png – openSUSE

Bilderquelle: http://de.opensuse.org/YaST_Module_Bootloader


Mittwoch
14. August 2013


face

AMD Catalyst 13.8 Beta1 (fglrx 13.20.5) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.8-beta1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1, 12.2, 12.3 sowie bis Kernel 3.10.

[UPDATE 19.08.2013]
Im AMD Catalyst 13.8 Beta1 ist für den fglrx-Kernelmodul eine neue Funktion für den EFI-Teil hereingekommen. Dadurch wurde ich auf einen Kompilierfehler aufmerksam gemacht (Vielen Dank an dieser Stelle an Martin Schröder und Torsten). Der Fehler beim Kompilieren “error: called object ‘efi_enabled’ is not a function” ist nun mit dem neuesten Packaging Skript behoben.

Nun zu den technischen Details:
Die o.g. Fehlermeldung beim Kompilieren des fglrx-Kernelmodul für den Kernel 3.4.47 unter openSUSE 12.2 erschließt sich mir im ersten Moment nicht. Erst als ich openSUSE 12.2 auf einer separaten Partition installiert habe und dann Nachforschungen angestellt habe, kam zu dem Fehler ungeheuerliches zum Vorschein.

Zuerst ist im Kernelcode 3.4.47 ein EFI-Code reingepatcht worden, welches eher dem EFI-Code in neueren Kernelcodes zu finden ist. Dann wurde ein EFI-Patch (kabi-re-add-efi_enabled-variable.patch) von Jiri Slaby (SUSE Niederlassung in Tschechien) angewendet. Der genannte Patch baut quasi die vorhandene Funktion efi_enabled(EFI_BOOT) zu efi_enabled_f(EFI_BOOT) um und ersetzt dann efi_enabled als Variable, um anscheinend das alte Verhalten wegen eines Patch für die Samsung-Laptops wiederherzustellen.

Da EFI_BOOT aber immer noch definiert ist und dieser nur im neuen EFI-Code vorkommt, wird der Patch an der Stelle logischerweise Probleme machen. Das wird nicht nur beim Kompilieren des fglrx-Kernelmodul krachen, sondern woanders auch. Richtig wäre es gewesen, wenn man konsequenterweise EFI_BOOT auch umbenannt hätte. Ein undeklariertes EFI_BOOT wird im entsprechend Code als Variable efi_enabled andernfalls über die Funktion efi_enabled(EFI_BOOT) ausgelesen.

Wieso zum Geier müssen einige Leute im Kernel nur wegen einem Samsung-Laptop mit dem total kaputten UEFI herumpfuschen?! Hier hat der Hersteller die Sorgfaltspflicht ein BIOS-Update herauszubringen und nicht irgendwelche Kernel-Entwickler, die dadurch mehr kaputt machen als reparieren können!!! Ein Bugreport geht auch nochmal separat an die Kernel-Maintainer von openSUSE heraus, um den o.g. “re-add-efi_enabled-variable”-Patch ordentlich machen zu lassen. So kann es definitiv nicht bleiben.
[/UPDATE 19.08.2013]

Auf Grund der großen Nachfrage (Blog, E-Mail, Forum, IRC) nach einem makerpm-amd-Skript für die öffentliche Beta-Reihe, habe ich mich nun dazu entschlossen, diese auch mit dem Skript direkt zu unterstützen. Die Begründung ist, dass die letzte Version (AMD Catalyst 13.4) schon etwas älter ist und die Entwicklung des Treiber natürlich nicht aufgehört hat, sondern in Form eines Beta-Treiber als eine Art “Snapshot” von den AMD-Entwickler zur Verfügung gestellt wird.

Zwischenzeitlich sind ein paar Bugs bekannt geworden, die ein Arbeiten mit dem Treiber unmöglich gemacht haben. Bei einer 3D-Anwendung sind folgende Meldungen aufgetaucht und der Absturz der Anwendung folgte unmittelbar:

libGL error: open uki failed (Operation not permitted)                                                                                                                                                         
libGL error: reverting to (slow) indirect rendering 

face

Nachdem nun mein Raspberry Pi sich mit einem Kernel-Panic (PANIC: VFS: Unable to mount root fs on unknown-block(179,4)… ) von der SD Karte verabschiedet hat, war es Zeit eine andere Möglichkeit des Betriebs zu suchen.

Vorweg – SD-Karte “retten”:
mit folgendem Befehl kann man eine Reparatur der SD Karte versuchen… meistens geht dies allerdings mit nicht geringem Datenverlust einher.
Aber besser ein paar Daten als gar keine…

sudo /usr/sbin/fsck.ext4  -f /dev/sdc2

Nach etlichen “JA” Eingaben kann man die SD Karte in einem Linux-System normal mounten und die nötigsten Dateien retten.


Das Vorhaben:

Zukünftig sollen die System- /OS-Dateien auf der externen Festplatte gespeichert werden. Dazu habe ich an einem USB-HUB mit eigener Stromversorgung eine 2.5 Zoll Festplatte angeschlossen. Weiterhin hängt nun der Raspberry-Pi Stromanschluss auch an diesem HUB.

Eigentlich bootet der RPi immer von der SD Karte, sodass wir uns mit einem Bootloader helfen müssen.
Dazu eignet sich ganz wunderbar das Mini-OS BerryBoot.
Neben der Funktion als Bootloader fungiert BerryBoot auch als Installations-Hilfe und Backup-Tool.

BerryBoot

BerryBoot


Download BerryBoot:
http://www.berryterminal.com/doku.php/berryboot (31MB direkt: http://downloads.sourceforge.net/project/berryboot/berryboot-20130811.zip )

Das ganze entpackt ihr nun auf die SD Karte, welche auch in den Raspberry soll… jetzt bin ich etwas klüger und nehme eine sehr kleine SD Karte, welche ich dann auch prima mit dem Befehl “dd” vollständig sichern kann… (Tolle Anleitung: http://developer-blog.net/hardware/raspberry-pi-backup/ pdf). Alternativ kann wahrscheinlich auch die BerryBoot Backup-Funktion dienen, diese habe ich jedoch noch nicht getestet.

Also kurz “dd” für später… könnt ihr getrost überspringen:

# ACHTUNG: kann bei falscher Anwendung zu Datenverlust führen... 
# wie immer also keine Garantie / Verwendung auf eigene Gefahr.

# Pfad zur SD auslesen:
df -h

# SD wieder unmounten
umount /dev/disk1s1

# backup.img von der SD anlegen
dd if=/dev/disk1s1 of=/home/backup/backup.img bs=1M

Video der Verwendung von BerryBoot:

Nun wurde Wheezy ganz wundervoll auf unserer externen Festplatte / Stick installiert.

Weitere Schritte (optional):

1. Nun der normalen Installation und Konfiguration von Wheezy folgen… (hier beschrieben) – Passwort ändern, SSH aktivieren (jetzt unter “Erweiterte Optionen”) Sprache einstellen, Tastaturlayout, etc. pp.

2. Weiterhin: Feste IP setzen

3. Lighttpd Webserver + PHP5 + MySQL Server unter Raspbian
(“sudo apt-get update && sudo apt-get install lighttpd php5-cgi mysql-server mysql-client phpmyadmin” )
->  ”Ja”  
->  2x ein Passwort für Mysql eingeben *  
->  lighttpd auswählen (=Taste unten, Space, Enter) )

Nach einer ganzen Weile (die Installation dauert seine Zeit):
-> Ja  
->  MySql Passwort eingeben (siehe Sternchen * oben)
->  2 x Passwort von Mysql (für die MySql Weboberfläche)

Das Setzen der Rechte nicht vergessen!!

#Ordner Besitzer und Gruppe zu "www-data:www-data" ändern (-R für rekursiv!):
sudo chown -R www-data:www-data /var/www
#Gruppe das Schreiben erlauben:
sudo chmod 775 /var/www
#Pi User zur www-data Gruppe hinzufügen
sudo usermod -a -G www-data pi

4. Lighttpd Verzeichnisschutz für Raspberry Pi (Nachtrag)

5. Tiny Tiny RSS auf Raspberry Pi ( inzwischen gibt es 1.9 )
Also neuer Befehl (auszuführen

Ältere Artikel ->