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.


Montag
05. August 2013


face


Wer das System-Update auf Android 4.3 durchgeführt hat , wird eine Meldung von SuperSu erhalten, dass dieses nicht mehr funktioniert. Auch verweigern alle anderen Programme, die root benötigen ihren Dienst.
Dies lässt sich jedoch auch ohne das Nexus 4 Toolkit durchführen (welches zu diesem Zeitpunkt noch kein Android 4.3 unterstützt).

Einfach die SuperSu zip über CWM Recovery flashen, fertig. Ich habe vorher noch über den Playstore die vorhandene SuperSu-Version deinstalliert (bzw. das Update).
Achtung: ihr habt hoffentlich brav im ClockWorkModRecovery nach dem Android Update die Hinweise zur Sicherung des Bootmanagers beachtet d.h. NICHT Stock Boot installiert… sonst wird ein Start ins Recovery nicht ohne weiteres möglich sein. Ihr könnt dies ganz einfach testen, indem ihr Schritt 2 und 3 durchführt.

1. SuperSu zip herunterladen: http://download.chainfire.eu/supersu
2. In CWM Recovery starten (Power + Vol-down)
3. mittels Vol bis auf RECOVERY schalten
4. dort install zip from SD – dann eure supersu zip wählen (0 = emulated sd)
5. Neustarten, fertig.

(Update 13.08.2013):

Quelle: http://ncry.eu/

Wer nicht CWM Recovery nutzt (und daher auch nicht vor dem Überschreiben des Bootloader geschützt / gewarnt wird), kann sich auch das Tool N-Cry anschauen.
Damit lässt sich auf einfachste Weise das Gerät entsperren und / oder den Bootloader wieder einspielen.

Ich habe es zwar nicht getestet, aber die Meinungen sprechen sehr dafür.
Link (Forum)http://www.android-hilfe.de/root-custom-roms-modding-fuer-google-nexus-4/356561-toolkit-n-cry-nexus-4-jb-4-3-a.html
Link (Entwicklerseite): http://ncry.eu/


Samstag
03. August 2013


face

dank einem Hinweis von Michael konnte ich einen Fehler im Kommentar-System beheben (Spam deleted). Die beiden WordPress-Plugins “Antispam Bee” und “NoSpamNX” kamen sich in die Quere. Nach der Deaktivierung von letzterem könnt ihr nun wieder die Kommentar-Funktion nutzen (worüber ich mich natürlich freuen würde).



Donnerstag
01. August 2013


face

Nun werde ich mich einem weiteren Projekt widmen, welches gleich eine eigene Kategorie bekommt: Heimautomatisierung. Da ich einen kleinen Raspberry PI in meinem Besitz habe, werde ich den Großteil der Automatisierung über diesen laufen lassen.

In diesem ersten Teil werde ich versuchen mein NAS automatisch mit dem HTPC (XBMC) starten zu lassen. Von Hause aus hat das eTrayZ NAS leider kein WOL (Wake On Lan), sodass ich mir über einen sehr unkonventionellen Weg helfen musste.

Der erste fehlgeschlagene Versuch: Steuerung über den Raspberry PI, einen Standby Killer und dem Infrarot Toy V2 bzw IRToy V2 (Details / Bezugsquelle)…
“Leider” war der Verbrauch des NAS zu niedrig, sodass der SBK immer wieder nach einer Minute vollständig abschaltete, da er annahm, das angehängte Gerät wäre im Standby. Also musste ein anderer Weg her.

Nun habe ich mir folgende Anleitung vorgenommen: [Raspberry Pi] erster Schritt zur Hausautomation (PDF) oder auf englisch (PDF)
Aber auch dieser Beitrag geht einen ähnlichen Weg: Funksteckdosen mit dem Raspberry Pi schalten (PDF)

Die Idee:

Beim Start des HTPC mit XBMC (auf Ubuntu Basis) wird ein Befehl an den Raspberry Pi gesendet, welcher nun per Funk die Funksteckdose des NAS aktiviert. Beim Abschalten wird wieder ein Befehl an den Raspberry Pi abgesetzt, welcher zuerst ein Shutdown-Script (z.B. von hierPDF) auf dem NAS aufruft, damit dieses sauber herunter fährt und nach einer vordefinierten Zeit wird der Befehl zum Abschalten an die Funksteckdose zum Strom trennen gesendet.

Der Einkauf:

Also habe ich mir aus dem Baumarkt für knapp 14 Euro ein Set Funksteckdosen von der Firma ELRO besorgt. Wichtig dabei war die Möglichkeit, die Funkeinheiten per Schalter auf einen Code zu konfigurieren. Weiterhin ein Funkmodul für 433Mhz (z.B. von eBay)

Sendemodul Sender Sendeeinheit 433 Mhz Funk Modul

Die Funktion der Scripte:

  • Zuerst einmal benötigen wir ein Script auf dem HTPC, welches nach dessen Start ein Script auf dem Pi aufruft das wiederum das Funksignal “anschalten” an die Funksteckdose des NAS sendet. Dieses Script muss allerdings auch nochmal bei Shutdown mit einem anderen Parameter aufgerufen werden um eben diesen auch wieder an den Pi weiter zu geben.Nennen wir dieses Script “raspberrysender
  • Nun benötigen wir ein weiteres Script, welches 1. die Funksteckdose(n) schaltet und das 2. NAS sauber herunter fährt.Dieses Script nennen wir “pi_gateway.php” und es liegt auf dem Pi. Es fungiert also wie oben beschrieben als eine Art Brücke zwischen dem HTPC und der Funksteckdose sowie NAS. Wer seinen Pi als XBMC nutzt, dürfte es hier etwas leichter haben.Das XBMC ruft also mit “an” (beim Start) oder “aus” (beim Herunterfahren) über raspberrysender die pi_gateway.sh auf dem Pi auf.
  • Letztendlich noch ein kleines Script auf dem NAS, welches eben diesen sauber herunter fährt. Dieses nennen wir “nas_shutdown.php” und es wird durch die pi_gateway.sh aufgerufen.

Ich habe mich bewusst für PHP Scripte entschieden, da ich auf dem NAS sowie dem Raspberry Pi jeweils einen Webserver laufen habe. Dadurch spare ich mir einen Umweg über eine


Sonntag
21. Juli 2013


face

muninMunin ist ein Hardwaremonitoring Werkzeug für Linux/Unix Systeme, welches sehr einfach zu installieren ist und es ermöglicht, mehrere PCs und Server zu überwachen. Dabei fragt ein Master-Node in regelmäßigen Abständen die Clients und bereitet die Daten grafisch auf.

Installation

Die Installation ist sehr einfach gehalten. Installieren Sie zuerst als root mittels

yum install munin munin-node

die nötigen Pakete.

Klammern Sie nun in der Datei /etc/munin/munin.conf folgendes aus, um die Daten anzeigen zu lassen. Auf Clients müssen Sie dies nicht tuen, wenn nur Daten abgefragt werden sollen.

dbdir /var/lib/munin
htmldir /var/www/html/munin
logdir /var/log/munin
rundir /var/run/munin

Passwortabfrage

Später können Sie unter http://localhost/munin auf die Grafiken zugreifen. Wenn Sie dies durch ein Passwort geschützt haben wollen müssen Sie zuerst eines mittels

htpasswd -c /etc/munin/munin-htpasswd username

erstellen.

Außerdem müssen Sie noch eine Datei unter /etc/httpd/conf.d/munin.conf erstellen bzw. bearbeiten und mit folgenden füllen:

<directory /var/www/html/munin>
AuthUserFile /etc/munin/munin-htpasswd
AuthName "Munin"
AuthType Basic
require valid-user
ExpiresActive On
ExpiresDefault M310
</directory>
ScriptAlias /munin-cgi/munin-cgi-graph /var/www/cgi-bin/munin-cgi-graph

Nach einem

service httpd restart

erscheint nun eine Passwortabfrage.

Plugins konfigurieren

Munin verfügt ab Werk über eine große Anazahl an Plugins. Diese liegen unter /usr/share/munin/plugins
Wenn Sie eines der Plugins verwenden möchten so müssen Sie es nur linken

ln -s /usr/share/munin/plugins/df /etc/munin/plugins

Ob zu kontrollieren, ob ein Plugin konfiguriert werden muss, können Sie es einfach ausführen:

./df autoconf

Erscheint ein Yes müssen Sie nichts mehr vornehmen.

Einige Plugins sind Wildcard Plugins und enden auf einen Unterstrich wie zum Beispiel sensors_. Führen Sie diese mit der Option suggest aus um die möglichen Optionen zu erhalten:

./sensors_ suggest

Nun können Sie ja nach gewünschter Option die Datei umbennen

mv sensors_ sensors_fan

Manche Plugins können in der Datei /etc/munin/plugin-conf.d noch weiter angepasst werden. Dies würde den Artikel aber sprengen, deswegen hier nur ein Beispiel:

[sensors_*]
 
env.ignore_fan3 true
env.ignore_fan4 true
env.ignore_volt3 true
env.ignore_volt7 true
 
[smart_*]
user root
group root
 
[hddtemp_smartctl]
user root
group root
env.ignore "sda"

Andere Systeme verbinden

Munin selber benutzt den Port 4949, den Sie in der Firewall, wenn laufend, frei geben müssen. Andere Munin Installation können dann von der oben eingerichteten Master-Server abgefragt werden. Wenn nur ein Client (Node) installiert wird, können Sie die Einstellungen von munin.conf und dem Apache ignorieren. Auschlaggebeden ist nur die munin-node.conf an der Sie allerdings nichts mehr einstellen müssen. Sie können dort festlegen welche IPs auf die gesammelten Daten zugreifen kann um diese Abzufragen.

Beim Master-Server tragen Sie die zusätzlichen PCs / Server in der munin.conf ein. Hier eine Beispiel:

[Lokal]
address 127.0.0.1
use_node_name yes
[Server_1]
address 10.0.0.5
use_node_name yes
[Server_2]
address 

Mittwoch
10. Juli 2013


face

Zur Erinnerung: Am ersten August-Wochenende (02.08.-04.08.2013) findet in Hesselberg das Anwendertreffen 2013 statt. Es werden noch Leute für den regen Informationsaustausch zu openSUSE wie auch für einen netten Plausch gesucht. ;-) Meine Wenigkeit wird auch vor Ort sein. Am Samstag Abend wird gemeinsam gegrillt. Das Grillgut kann entweder selbst mitgebracht oder bei den Organisatoren bestellt werden.

Folgende Vorträge sind derzeit geplant (Weitere können noch hinzukommen):

  • Freitag (Abend):
    • Einführung in SSH, SSHFS, SCREEN
    • Einführung zur Programmierung eines Bash-Skripts
  • Samstag:
    • Vorstellung der openSUSE Wiki
    • Einführung zur Erstellung eines RPM-Paketes
    • Einführung in die Arbeit mit dem Open Build Service (OBS)
  • Sonntag (Vormittag):
    • Austausch von offenen Fragen und weiteren Tipps & Tricks für die tägliche Arbeit mit openSUSE

Die Organisatoren sind sich bewusst, dass die o.g. Vorträgen sich zum Teil an Semiprofessionelle oder die es gerne werden möchten gerichtet sind. Sie sind gerne für weitere Themenvorschläge auch für den einfachen Anwender offen. Vor Ort können auch aufkommende Fragen, die in anderen Themenbereichen einschlagen, gemeinsam erörtert werden. Auch spezielle Problematiken im Alltag mit openSUSE oder Linux im Allgemeinen können auf diese Weise mit erfahrenen Linux-Usern ausgetauscht werden.

Den Teilnehmern wird empfohlen, sich für 2 Übernachtungen einzuplanen. Ob man Vollpension haben möchte, individuelles Frühstück & Mittagessen & Abendessen oder nur das Zimmer mit der Möglichkeit selbst für Verpflegung zu sorgen, ist jedem selbst überlassen.

Preisliste für die Übernachtung und Verpflegung zum Download: Preisliste2013.pdf

Wer am Anwendertreffen 2013 teilnehmen möchte oder weitere Fragen hat, möge sich bitte via E-Mail/IRC an Marcel Kühlhorn a.k.a. tux93 (E-Mail: tux93 (at) opensuse (punkt) org) oder im IRC an Karl Thomas Schmidt a.k.a. }ls{ wenden. Wenn es um die Anmeldung geht, kann ich auch behelfsmäßig einspringen und leite die Informationen an die Organisatoren weiter. Im Moment sind noch Plätze wie auch Zimmer frei. Bitte bedenkt: Je näher der Termin rückt, desto weniger Plätze sind dann noch frei.

Die Organisatoren wie auch ich würden uns auf zahlreiche Teilnehmer freuen.

Quelle:


Sonntag
02. Juni 2013


Christian Boltz: LinuxTag

22:27 UTCmember

face
Bernhard (on the left) answering questions
Jos at Towel day (aren't you exaggerating a bit? ;-)

Vor gut einer Woche ging der LinuxTag zu Ende. Zeit, kurz darüber zu schreiben ;-)

Ich war drei Tage in Berlin. Neben einigen interessanten Vorträgen war ich oft am openSUSE-Stand, um die Fragen der Besucher zu beantworten und habe mit 3 Runden openSUSE Jeopardy dafür gesorgt, das openSUSE-Motto "have a lot of fun" umzusetzen.

Außerdem hatte ich mich mit PostfixAdmin am Stand "einquartiert". Das erwies sich als Vorteil, weil deutlich mehr PostfixAdmin-Benutzer und -Interessenten zu mir kamen als letztes Jahr am Project Meeting Point.

An dieser Stelle vielen Dank an Bernhard, Jos und Sascha, die mit mir den openSUSE-Stand betreut haben, und ans Travel Support Programm für die Unterstützung bei den Reisekosten.

LinuxTag ended about a week ago. Time to write about it ;-)

I was in Berlin for three days. Besides listening to several interesting talks, I often was at the openSUSE booth, answered the visitor's questions and did 3 rounds of openSUSE Jeopardy to put the openSUSE motto "have a lot of fun" into practise.

Besides that, I "accomodated" myself with PostfixAdmin at the openSUSE booth. This turned out to be an advantage because many more PostfixAdmin users and might-become-users came to me (compared to the Project Meeting Point last year).

Thanks a lot to Bernhard, Jos and Sascha who manned the openSUSE booth together with me, and the travel support program for supporting me.


Mittwoch
08. Mai 2013


face

TokuDB von Tokutek.com ist seit ein paar Tagen OpenSource. Erstmal Daumen hoch !. Es handelt sich dabei um eine Storageengine für das DBMS System Mysql, oder eins seiner Derivate, z.B MariaDB. Letztere verschmelzt gerade mit den Entwicklern des Percona Servers. Auch dafür Daumen hoch!.

ABER

Wer Probleme hat das fertige Binary Build von MariaDB + TokuDB unter Centos oder RHEL zum laufen zu bekommen befolge oder besser prüfe den folgenden Sachverhalt, bei mir hat es geholfen, dass der Dienst endlich startet.

Im Errorlog taucht folgendes auf:

130507 13:17:07 [ERROR] Plugin 'TokuDB' init function returned error.
130507 13:17:07 [ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.
130507 13:17:07 [ERROR] Unknown/unsupported storage engine: TokuDB
130507 13:17:07 [ERROR] Aborting

Das war der einzige erkennbare Fehler, aber entscheidend sind genau die zwei Zeilen im Log davor

Transparent huge pages are enabled, according to /sys/kernel/mm/redhat_transparent_hugepage/enabled
Transparent huge pages are enabled, according to /sys/kernel/mm/transparent_hugepage/enabled

nach Stunden langem googlen habe ich einen Kommentar in einem Blog gefunden, der genau darauf verwiesen hat. Unter den beiden Systemen Centos und RHEL muss man noch folgendes ausführen, damit der Dienst sauber startet

echo never >   /sys/kernel/mm/redhat_transparent_hugepage/enable

Quelle:


Freitag
26. April 2013


face

AMD Catalyst 13.4 (fglrx 12.104) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.4.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.8.

[UPDATE 19.08.2013]
Durch den Patch von Kolasa ist eine neue Funktion für den EFI-Teil für den fglrx-Kernelmodul 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]

[UPDATE 04.08.2013]
Das Patch von mir habe ich gegen das Patch von Kolasa aus dem GitHub ausgetauscht. Da der Maintainer noch weitere sinnvolle Bugfixes eingebracht hat. Ab sofort wird nun bis Kernel 3.10 unterstützt. Das Packaging Skript habe ich hingehend erneuert. An dieser Stelle vielen Dank an Paolo Marzari für den Hinweis und Kolasa für die Änderungen am fglrx-Code.
[/UPDATE 04.08.2013]

AMD hat erfreulicherweise wieder eine Release Notes für Linux veröffentlicht. ;-)

Neu bei dem Treiber ist:

  • OpenCL Console Mode Support
  • Kernel 3.7 and 3.8 Support

Folgende Probleme sind im Treiber behoben worden:

  • [370253]: Serious Sam 3 – Color of Objects turning into be red when enabling separate shader object
  • [371937]: Team Fortress 2 – Screen black

Sonntag
17. März 2013


face
openSUSE Stand

openSUSE Stand

Das waren sie schon wieder. Die Chemnitzer Linux Tage 2013. Dieses Jahr wie immer gut besucht. Gefühlt sogar etwas mehr als letztes Jahr, was vielleicht auch an dem dieses mal offenen Vortagsprogramm lag, welches inhaltlich wesentlich ausgewogener war. Und natürlich habe ich mir vorgenommen ein paar Vorträge zu besuchen, was letztlich dann doch nur in einem geendet ist (der dann aber auch wirklich interessant war).

Der openSUSE-Stand war die beiden Tage gut besucht, wohl auch weil wir uns den Stand zusammen mit ownCloud geteilt haben. ownCloud ist ein OpenSource Projekt welches von der ownCloud Inc. maßgeblich gefördert wird. Das Projekt erstellt eine Softwarelösung auf Basis von PHP, SQLite / MySQL, die es erlaubt, dass jeder seinen eigenen Cloudspeicher, ähnlich wie Dropbox einrichten kann und auf seinen eigenen Server(n) laufen lässt. Dies kann unter anderem auch auf einem Rapsberry Pi geschehen.

wildes Weltraumspektakel gegen Ende der CLT

wildes Weltraumspektakel gegen Ende der CLT

Alexander Graf brachte am Samstag im Zuge seines ARM Vortrags auch noch einiges an Hardware unter anderem ein Chromebook von Google mit, welches allerdings auch von SD-Karte ein openSUSE booten konnte.

Am Fedora-Stand konnte man eine 3D-Drucker bei der Arbeit beobachten, der im Akkord Fedora Logos, Bausteine, Trillerpfeifen und andere Modelle produzierte.

Letztendlich waren wir mit der CLT wieder sehr zufrieden. Die Organisation hat auf der Seite der CLT super geklappt. Nur das Wetter wollte nicht so wirklich mitspielen. Letztes Jahr konnten wir noch mit dem T-Shirt draußen herumlaufen. Dieses Jahr war es da doch ein wenig kälter.


Dienstag
12. März 2013


face

(Kleine Werbeeinlage auf speziellen Wunsch von Michal Hrušecký ;-)

Die meisten Leute wissen wahrscheinlich schon, dass openSUSE 12.3 diesen Mittwoch (also morgen) releast wird.

Um das zu feiern, gibt es (ebenfalls am Mittwoch, also morgen) ab 19:00 Uhr eine Release Party im Artefakt in Nürnberg, bei der jeder willkommen ist. Dort kann man viele Geekos treffen, auch das openSUSE-Team von SUSE hat sich angekündigt und freut sich darauf, viele openSUSE-Begeisterte, Unterstützer und Benutzer zu sehen. Für Essen und openSUSE-Bier ist laut Michal gesorgt.

Natürlich ist auch der Star des Tages da - openSUSE 12.3 wird auf einem Demo-Rechner gezeigt. Mit etwas Glück gibt es auch ein Google Hangout für alle, die nicht nach Nürnberg kommen können - Infos dazu auf der openSUSE G+-Seite.

Ich selbst kann leider nicht zur Party kommen, wünsche aber allen viel Spaß ;-)


Samstag
23. Februar 2013


face

idp13Heute ist, wie schon in verschiedenen Medien berichtet, der Tag für Datenschutz und Privatsphäre  Im Zuge dessen gab es in mehreren Städten Kundgebungen und Demonstrationen. Unter anderem auch in Düsseldorf, wo ca. 50 bis 60 Leute für die Privatsphäre bei eisigen Temperaturen auf die Straße gingen. Neben zwei Kundgebungen, in der Altstadt sowie vor dem Landtag, wurde Passanten mit Flugblättern aufgeklärt was sich hinter Acta und INDECT verbirgt. Einer der Redebeiträge kann hier nachgelesen werden.


Freitag
22. Februar 2013


face
Cisco IP Phone 7960

Cisco IP Phone 7960

Das das Cisco IP Phone ein schönes Gerät ist, scheint in vielen Kreisen bekannt zu sein. Das gute ist, dass es sich als IP Telefon sogar an der Fritzbox nutzen lässt. Auch wenn es ein wenig Spielerei und Gefummel ist.

Die Geräte gibt es bei eBay für 30 bis 50 Euro gebraucht bzw. neu für etwa 120 bis 200 Euro.

Bitte zuerst die Anleitung komplett lesen. Auch den unten aufgeführten Link lege ich sehr ans Herz. Durch das flashen mit der falschen Firmware kann das Gerät u.U. nicht mehr funktionieren. Die Konfigurationsdateien können immer wieder neu eingespielt werden. Falsche Konfigurationsdateien sollten das Gerät nicht unbrauchbar machen.

Fritzbox vorbereiten

Einfach unter Telefonie > Telefoniegeräte > Neues Gerät einrichten klicken und dann Telefon auswählen. Im nächsten Dialog wählen Sie LAN/WLAN (IP-Telefon) aus und geben Sie dem Gerät einen Namen. Drücken Sie dann weiter. Im nächsten Dialog notieren Sie sich die Angaben und wählen ein Passwort aus. Dann noch die Rufnummer einrichten und das war es an der Fritz!Box auch schon.

TFTP Server einrichten

Windows

Für Windows empfehle ich TFTPD32.

Linux

Diese Anleitung bezieht sich auf CentOS / Scientific Linux.

yum install tftp-server
chkconfig --level 345 xinetd on
chkconfig --level 345 tftpd on

Die benötigten Dateien können dann später nach

/var/lib/tftpboot

abgelegt werden.

(Falls noch eine Firewall läuft muss der Port noch freigegeben werden. Dies kann mit system-config-firewall-tui geschehen.)

Konfigurationsdateien

Je nachdem welche Firmware Sie auf dem Gerät installiert haben müssen Sie dieses erst flashen. Die nötigen Dateien finden Sie, wen Sie einen Supportvertrag mit Cisco haben in deren Downloadbereich oder z.B. unter

http://radiotwenterand.nl/~graver/cisco/SIP-7960/

Ich habe mich für die Release P0S3-8-12-00.zip entschieden. Dies funktionierte auch bei mir ohne Probleme. Entpacken Sie das Archiv einfach in den tftpboot Ordner.

Nun kommt die schwierigere Aufgabe. Die Konfigurationsdateien für das Telefon. Hier habe ich bei http://www.europott.org/2009/05/31/cisco-7960g-und-fritzbox-fonwlan abgeschaut. Die Anleitung ist sehr gut gemacht und die zum Download bereitstehenden Konfigurationsdateien haben bei mir funktioniert. Dort beachten Sie einfach die Kommentare in den ersten Zeilen der Dateien. Die bennenung der der SIP[MAC].cnf wird auf der oben genannten Webseite erklärt.

Allerdings müssen Sie an der SIPDefault.cnf eine änderung vornehmen. Klammern Sie

# image_version: "P0S3-08-8-00" Auskommentiert da SIP Firmware schon geladen ist

aus und ändern Sie die Zeile so ab wie die Firmware heisst. In unserem Falle

image_version: "P0S3-8-12-00"

Wenn Sich das Telefon dann die Konfiguration abholen möchte wird es sich direkt flashen. Die beiden Konfigurationsdateien kommen dann nach dem Ändern der entsprechende Zeilen auch in den tftpboot Ordner. Ändern Sie die Rechte noch mit

chmod 777 /var/lib/tftboot

ab.

Telefon einrichten

Wenn Sie jetzt das Gerät richtig angeschlossen haben (Netzwerkkabel gehört in den mit Switch beschrifteten Anschluss) wird erstmal nicht viel passieren


Donnerstag
07. Februar 2013


face
kfritz1

Anrufliste von KFritz

Nach Umzug und Vertragswechsel bei meinem Provider gab es ein neues Modem. In meinem Fall ein AVM Fritz!Box 6360 Cable. Das schöne dabei ist die Möglichkeit, die Anrufliste aus der Fritz!Box auszulesen. Besonders auf KDE angepasst gibt es das Programm KFritz zu finden unter http://www.joachim-wilke.de/kfritz.htm. Der Vorteil an diesem Programm liegt noch dabei, dass es Benachrichtigungen (KNotify) beherrscht.

kfritz2

KFritz benachrichtigt bei Anrufen

So bekommt man beim Anruf direkt zu sehen wer anruft. Ist die Nummer nicht im Telefonbuch der Fritz!Box hinterlegt so sucht das Programm automatisch in Telefonnummerdatenbanken nach dem Namen des Besitzers. Das Systemabschnittssymbol passt sich auch gut in die Standardsymbole ein.

Das einzige was man Einstellen muss ist eventuell die IP der Fritz!Box (wenn nicht unter fritz.box erreichbar) sowie das Passwort für jene.

Leider hat es bei mir nicht funktioniert neue Kontakte zu den Fritz!Box Kontakten hinzuzufügen. Zwar werden die Kontakte in der Liste angezeigt, sind aber nach einem Refresh nicht mehr vorhanden. Auf der Fritz!Box tauchen sie garnicht auf. Stört mich allerdings weniger. Die Hauptsache der Meldung für ein- und ausgehende Telefonverbindungen reicht mir hier völlig.

Installation

Das Programm gibt es für alle großen Linuxdistribution.
openSUSE User laden sich das Programm von http://download.opensuse.org/repositories/home:/rbos/openSUSE_12.1/i586/ herunter.

Arch Linux Nutzer finden im AUR ein PKGBUILD (https://aur.archlinux.org/packages/?O=0&K=kfritz). Das kompilieren dauert nicht lange.

Andere Distributionen haben auch passende Pakete zur Hand. Genaueres gibt es auf der Entwicklerseite.


Freitag
25. Januar 2013


face

AMD Catalyst 13.1 Legacy (fglrx 8.97.100.7) wurde veröffentlicht und unterstützt nur ältere Grafikkarten der Serie Radeon HD 2000 bis einschließlich HD 4000. Das Skript makerpm-amd-13.1-legacy.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1 und 12.2 sowie bis Kernel 3.8. Das Packaging Skript wurde im Zuge der Kernel-Patches für 3.5 bis einschließlich 3.8 aktualisiert (offiziell wird von AMD nur bis Kernel 3.4 unterstützt).

Im IRC-Chat habe ich um einen Test mit dem Legacy-Treiber auf openSUSE 12.3 Beta 1 gebeten. Freiwillige User haben hierzu Feedback gegeben. Leider sah es nicht besonders gut aus. Auf openSUSE 12.3 ist der X-Server in der Version 1.13.1 im Einsatz und der Legacy-Treiber unterstützt jedoch nur bis 1.12.x.

Da bin ich wie auch viele andere User dem Artikel von Michael Larabel (Phoronix) auf den Leim gegangen. Der Artikel wurde trotz der Beschwerden und Hinweise im Forum immer noch nicht korrigiert. Daher der Hinweis: Der Legacy-Treiber läuft nicht auf openSUSE 12.3 in Verbindung mit dem X-Server 1.13.1.

Man kann den Legacy-Treiber noch mit openSUSE 12.2 bis zum 15. Januar 2014 betreiben, dann endet die Lebenszeit von openSUSE 12.2 und jegliche Updates werden eingestellt. Für Tumbleweed-Benutzer endet es bereits mit der Veröffentlichung von openSUSE 12.3 voraussichtlich am 13. März 2013. Hier wird empfohlen, nach dem Release von openSUSE 12.3 auf entsprechende Repos für openSUSE 12.2 umzusteigen. Alternativ kann man sich openSUSE 12.3 installieren und lässt es mit dem Kernel-Treiber radeon laufen und aktualisiert entsprechend den Kernel, um neuere und stabilere radeon Treiber zu erhalten.

Zu diesem Legacy-Treiber gibt es momentan noch keinen Changelog.

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.1-legacy.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

Freitag
18. Januar 2013


face

AMD Catalyst 13.1 (fglrx 9.012) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-13.1.sh steht ab sofort zum Download zur Verfügung und unterstützt openSUSE 11.4, 12.1 und 12.2 sowie bis Kernel 3.8. Das Packaging Skript wurde im Zuge der Kernel-Patches für 3.7 und 3.8 (offiziell wird von AMD nur bis Kernel 3.6 unterstützt) und der vorläufigen Unterstützung von openSUSE 12.3 Beta 1 aktualisiert. Der Treiber kann auch unter openSUSE 12.3 Beta 1 installiert werden (Feedback erwünscht).

Ursprünglich sollte AMD Catalyst 12.12 (fglrx 9.011) im Dezember 2012 herauskommen. Jedoch habe ich einige Mängel zu dieser Treiberversion bei AMD gemeldet und darum gebeten, diese AMD Version zu überspringen. Offenbar haben die AMD-Entwickler es ebenso gesehen und war auch einer der Gründe für die Verspätung des Treibers.

AMD hat erfreulicherweise wieder eine Release Notes für Linux veröffentlicht. Es hat sich gelohnt, bei AMD regelmäßig mit diesem Anliegen auf der Matte zu stehen. ;-)

Neu ist bei dem Treiber die X-Server 1.13 Unterstützung.

Folgende Probleme sind im Treiber behoben worden:

  • [368958]: Driver release version is added to GL_VERSION
  • [367282]: Bblank VGA display after resume from suspend
  • [367245]: X crash for AMD PowerXpress™ A+I High-Performance mode on Ubuntu 12.10
  • [366820] Performance of Valve Linux games
  • [366805]: Segmentation fault when exit QtOpenGL applications such as AMD CodeXL
  • [366425]: Xserver getting exit upon resume from suspend on RHEL 5.8
  • [364107]: VariBright not working when change AMD PowerPlay™ settings in AMD Catalust Control Center:LE
  • [363638]: VariBright doesn’t work after resume from suspend on “Trinity” platform
  • [350759]: Flickering cursor when run some full-screen OpenGL games with CrossFire enabled
  • [347895]: OpenGL performance on “Southern Islands” ASICs
  • [344996]: 16 re-frames doesn’t work for H.264 @Level 5.1
  • [337240]: Corruption when resize the Konsole window
  • [304016]: One display goes black after changing from multi-display desktop from single independent

Link: AMD Catalyst™ 13.1 Proprietary Linux® Graphics 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.1.sh ist sehr mächtig, robust und läuft vollautomatisch. Der


Donnerstag
10. Januar 2013


face

Die HMM Deutschland GmbH sucht zur Verstärkung ihres Teams einen Linux Admin.
Wenn also jemand Interesse hat bitte eine Bewerbung an:

bewerbung (at) hmmdeutschland.de senden.

Informationen zum Unternehmen gibt es unter der Adresse www.hmmdeutschland.de


Dienstag
08. Januar 2013


face

Die Planung zum nächsten openSUSE Anwendertreffen 2013 ist bereits angelaufen. Der Termin für das Treffen steht in der ersten Runde fest und ist der 03. August 2013. Die meisten Teilnehmer haben dieses Datum gewählt. Meine Wenigkeit wird auch anwesend sein und freue mich riesig alle aus der openSUSE-Community kennenzulernen. Wer kommen möchte, ist herzlichst zum openSUSE Anwendertreffen 2013 eingeladen und würde mich über rege Teilnahme freuen. ;-)

Nun ist noch der Veranstaltungsort offen und kann ab sofort über eine Umfrage via Mehrfachauswahl (Multiple Choice) öffentlich abgestimmt werden (Link). Die vorgeschlagenen Orte wurden so gewählt, dass diese in etwa zentral in Deutschland gelegen sind und über eine gute Verkehrsverbindung und/oder Übernachtungsmöglichkeit verfügt, um möglichst viele an der Teilnahme des Anwendertreffen zu ermöglichen. Der Veranstaltungsort mit den meisten Stimmen zum Abschluss der Umfrage am 28. Februar 2013 gewinnt.

Um die Abstimmung zu erleichtern, wurde zu jedem Veranstaltungsort ein Link zur Webseite sowie ein Link zu Google Maps für die Routenplanung angegeben:

  1. Ökomarkt Vachdorf (Veranstaltungsort auf Google Maps / Vorschlag von Kanonentux)
  2. EBZ-Hesselberg (Veranstaltungsort auf Google Maps / Vorschlag von boser)
  3. Unperfekthaus Essen (Veranstaltungsort auf Google Maps / Vorschlag von mir / Sebastian Siebert)
  4. Bildungsstätte Bundeshöhe Wuppertal (Veranstaltungsort auf Google Maps / Vorschlag von yogie)

Link zur Umfrage: openSUSE Anwendertreffen Veranstaltungsort

Link zum Forum: openSUSE Anwendertreffen 2013

Link zum Forum (ursprünglicher Post): openSUSE Anwendertreffen 2013


Montag
31. Dezember 2012


face
Mediacenter mit XBMC

Mediacenter mit XBMC

Frisch zu Weihnachtszeit Anfang Dezember, habe ich mir mal ein kleines Mediacenter gegönnt. Nach nun mehreren erfolgreichen Abenden der Nutzung nun einen kleinen Blogartikel darüber.

Aber erst etwas Theorie meinerseits. Ich wollte für das Mediacenter auf der einen Seite nicht viel Geld ausgeben, denoch auf Standardkomponenten setzen die nicht viel Strom verbrauchen. Dolby oder ähnliches sind für mich nicht von belang. Letztlich habe ich mich für folgenden Komponenten entschieden die ich bei einem großen Onlinecomputerhandel erworben habe:

  • Intel D2550DC2 Mainboard mit aufgelöteten Atom D2550
  • SO-DIMM 2 GB DDR3-1333
  • Antec ISK 300-150 Mini ITX
  • GeForce GT 610 PCI pasiv (dazu später mehr)

Eine alte aber noch gute 2,5″ Festplatte hatte ich noch zur Hand, so das ich hier nichts mehr einkaufen musste. Viel Speicher muss die Platte bei mir nicht haben, da sich das Mediacenter die Medien vom Homeserver holt. Die entsprechenden Ordner sind per SMB freigegeben. Insgesamt hat mich der Einkauf (ohne Festplatte) knapp 215 Euro gekostet.

An dieser Stelle muss ich nun kurz vorgreifen warum ich zusätzlich zu der mit auf dem Atom eingebaute Grafikkarte (eine PowerVR Grafikkarte) eine nVidia Karte eingebaut habe.
Die schon eingebaute Karte des Atom D2550 wird vom Linuxkernel 3.6 aktuell nicht unterstützt. Aus diesem Grund sollten Linux Nutzer die aktuelle Atom Version erstmal meiden, da die Treiber für PowerVR Grafikkarten noch nicht stable sind.

Hardware

PCI Slot mit wenig Luft

PCI Slot mit wenig Luft

Bei dem Zusammenbau ist selber nicht viel zu beachten. Das Gehäuse selber kenne ich noch aus meinem ersten Homeserver. In der neuen Revision ist das Netzteil nun geschlossen und aktiv gekühlt.
Blöderweise lag bei dem Mainboard der Anschluss für den Gehäuselüfter so weit weg, das das Kabel zu kurz war. Aus diesem Grund musste ich mir erstmal eine Verlängerung zusammenlöten damit der Stecker passt.
Die Grafikkarte mit ihrem passiven Kühlkörper ist etwas wuchtig, da der Kühlkörper auch auf der anderen Seite

Grafikkarte ist gut durchlüftet

Grafikkarte ist gut durchlüftet

noch ausgebaut ist. Erst nach dem umlegen von ein paar Kabeln passte die Grafikkarte zufriedenstellend. Hier ist zu beachten, dass nur Grafikkarten mit LowProfile-Blende passen. Von der Hitzeentwicklung her ist die Karte in Ordnung. Sie wird zwar warm aber nicht heiss.

Software

Als Betriebssystem ist ein minimales Arch Linux installiert. Zusätzlich werden über den Befehl

pacman -S xorg-server xorg-xinit xorg-utils xbmc

die nötigen Pakete für XBMC installiert. Damit XBMC automatisch beim Hochfahren mitstartet müssen folgenden Befehle ausgeführt werden:

systemctl enable xbmc
systemctl enable graphical.target

Anfangs hatte ich Probleme dem richtigen Sound. Eventuell müssen Sie hier mit

pacman -S alsa-utils
alsamixer

erst noch die Lautstärke von Hand hochdrehen.

Für die Grafikkarte verwende ich die properitären Grafkikkartentreiber. Diese installieren Sie mit

pacman -S nvidia libvdpau

Vergessen Sie hier nicht die VDPAU Bibliothek zu installieren, wie oben beschrieben, und das XBMC diese auch nutzt (unter Einstellungen > Wiedergabe > Video), ansonsten werden 1080p Videos nur


Sonntag
30. Dezember 2012


face

Wie angekündigt habe ich versucht auf das Galaxy Tab 2 KDE zum laufen zu bringen, leider erfolglos.
Nachdem das Gerät erfolgreich gerootet wurde (dies wird für Installation von Ubuntu benötigt, bzw. für alle Anwendungen die im chroot Kontext laufen sollen) habe ich Ubuntu per Installer darauf installiert. Ich wurde nach dem Booten auf der Shell begrüßt und habe danach ein apt-get install kde-desktop eingegeben. Alle Pakete wurde runter geladen und installiert. Leider fährt das Ubuntu danach nicht richtig hoch, man sieht kurz den Bildschirm flackern und landet danach in einem Blackscreen. Im Logfile des Grafikservers ist leider kein Hinweis zu finden, was schief gelaufen ist, auch die sonstigen Logfiles sehen sauber aus. Leider fehlt mir nun die Zeit mich damit weiter zu beschäftigen, aber einen Versuch war es wert.


Montag
24. Dezember 2012


face

An dieser Stelle wünsche ich euch heute Abend und die nächsten Weihnachtstage ein besinnliches und ruhiges Fest.


Freitag
07. Dezember 2012


face

Ich habe mich dazu entschlossen zwischen den Feiertagen ein kleines Projekt zu realisieren.

Es existiert für Android Geräte ein Ubuntu Installer. Den werde ich einmal ausprobieren. Sollte das auf dem Galaxy Tab gelingen werde ich versuchen den KDE Desktop darauf zu installieren. Natürlich werde ich hier im Blog darüber berichten ob alles reibungslos funktioniert :-)

Hat von euch schon jemand Erfahrungen mit einer Ubuntu Installation auf dem Galaxy Tab ?

 


Sonntag
28. Oktober 2012


Christian Boltz: openSUSE conference

21:17 UTCmember

face

emacs-based music at the party - maybe vi would have been better? ;-)
Letztes Wochenende (bis Dienstag) war ich bei der openSUSE conference, die diesmal in der "goldenen Stadt" Prag stattfand. Die Konferenz war sehr interessant - zum Einen die Vorträge, zum Anderen der "hallway track", bei dem ich viele Leute persönlich traf, die ich sonst nur namentlich aus Mailinglisten oder Bugzilla kenne.

Mein Workshop zu AppArmor wurde von rund 15 Personen besucht, die jetzt mehr über AppArmor wissen. Es wurden auch Fragen zum Packaging von Profilen gestellt - mit etwas Glück bekommen also ein paar Programme ein AppArmor-Profil in ihr Paket oder das Profil wird upstream zur Aufnahme zu den Standard-Profilen vorgeschlagen. Die Folien zum Workshop gibt es am Ende dieses Eintrags.

The "golden town" prague, with the Charles Bridge on the left

Zum openSUSE Jeopardy kamen nur 5 Personen. Diese haben aber alle mitgespielt und hatten sichtlich Spaß, die passenden Fragen zu meinen Antworten rund um Linux und openSUSE zu finden - vor allem Jan, der beide Runden (und somit zwei Flaschen Wein) gewann. Der IRC-basierte "Buzzer" hat dabei gut funktioniert und kommt mit etwas Glück beim nächsten LinuxTag nochmal zum Einsatz.

Am Montag  war ich einer der wenigen Teilnehmer der BoF zur openSUSE landing page, die wir spontan etwas verlängerten. Daher fiel die admin@-BoF mehr oder weniger aus, was mangels anwesender Admins auch nicht wirklich schlimm war. Danach wurde ich von Coolo noch zum Filmen freiwillig gemeldet ;-) - die schrecklichen Publikums-Bilder vom Montag Nachmittag (Project Meeting etc.) und Dienstag (hauptsächlich Raum Riker) stammen von mir ;-)

Vielen Dank an alle, die zur openSUSE Conference beigetragen haben, and für die Unterstützung bei den Reisekosten!

AppArmor workshop

Last weekend (until tuesday) I visited the openSUSE conference which was in the "golden town" Prague this year. The conference was very interesting. One part are the talks, the other part is the "hallway track" where I met lots of people I only knew from mailinglists or bugzilla.

About 15 persons took part in my AppArmor workshop, which means they now know more about AppArmor. Some also asked about packaging of AppArmor profiles. If we are lucky, some applications will receive a profile in their package, or their profile will be proposed for inclusion the the upstream set of default profiles. The slides I used in the workshop are available for download at the end of this post.

Jürgen's UFO advertising openSUSE TV

Only 5 persons came to my openSUSE jeopardy, but they all played and had fun in finding the matching questions for my answers about Linux and openSUSE. Jan must have had most fun - he won both rounds (and two bottles of wine). The IRC based "buzzer" worked quite well and will probably be used again at next LinuxTag.

On monday, I was one of the few participants of the BoF about the openSUSE landing page, which we extended time-wise. This also means the admin@ BoF was more or less dropped, which wasn't really


Donnerstag
25. Oktober 2012


face

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

[UPDATE 13.12.2012]
Das Packaging Script wurde aktualisiert und ein Patch wurde zwecks Kompatibilität zum Kernel 3.7 hinzugefügt.
[/UPDATE 13.12.2012]

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/2012/07/28/opensuse-amd-catalyst-12-6-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-12.10.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 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 an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte


Sonntag
14. Oktober 2012


face

Eigentlich wollte ich nur ein paar Apps ausprobieren, und das ganze im Firmenumfeld. Ich bin dann relativ schnell gescheitert, die Apps haben immer die Verbindungsparameter für invalide gehalten, und geschrieben ich solle die Einstellungen überprüfen. Nach einiger Recherche, denn ich bin mir sehr sicher das die URLs und die Credentials stimmen, habe ich heraus gefunden, dass viele Apps nicht berücksichtigt haben, dass man Zertifikate selber signieren kann. Dies wird oft bei internen Applikationen gemacht.

Lösung

Um den ganzen Herr der Lage zu werden, habe ich mir das “root” Zertifikat mit dem unsere IT alle selbst signierten Zertifikate unterschreibt geben lassen. Man muss dieses physisch auf dem Android Gerät speichern und mit der Dateiendung “.crt” versehen. Klickt man nun mit einem Dateiexplorer auf diese Datei wir einem das öffnen mit dem Zertifikatsimporter von Android geöffnet. Einmal damit im Gerät hinterlegt, kann man problemlos mit jedem App via https auf die internen Systeme zugreifen.

Besserer Lösungsvorschlag an App Entwickler

Liebe App Entwickler da draußen, bitte seht bei euren Apps vor, dass es auch Zertifikate gibt, die nicht von einem offiziellen Trustcenter signiert sind. Man kann dazu, wie beim Webbrowser, eine Rückfrage an den Anwender stellen, ob er dem Zertifikat dennoch vertrauen möchte, anstelle ihn mit “Bitte überprüfe deine URL sowie Usernamen und Kennwort” zu belasten.

 

Was denkt ihr?


Dienstag
18. September 2012


face

Da es anscheinend noch keine Anleitung auf deutsch gibt wie man sein Arch Linux auf systemd umstellt, werde ich mich nun daran versuchen. Folgend werden wir ein Arch Linux vom alten init-System auf systemd umstellen.

Pakete installieren

Zu allererst ein volles Update des Systems mit dem Befehl:

pacman -Syu

Nun installieren wir systemd mit dem Befehl:

pacman -S systemd

Konfigurationsdateien erstellen

Jetzt legen wir folgende Dateien an mit dem jeweiligen Inhalt:

/etc/hostname
#hostname vom Rechner

 

/etc/vconsole.conf
KEYMAP="de-latin1.map.gz"
FONT=lat9w-16
FONT_MAP=8859-1_to_uni

 

/etc/locale.conf
LANG=de_DE.utf8
LC_COLLATE=C

 

/etc/timezone
Europe/Berlin

Kernelmodule eintragen

Wenn zusätzliche Kernelmodule geladen werden müssen die in der /etc/rc.conf stehen, so müssen diese noch extra eingerichtet werden, da die rc.conf bei systemd in diesem Falle ignoriert wird.

Legen Sie für jedes Kernelmodul das geladen werden soll im Ordner

/etc/modules-load.d/

eine Datei an. Hier am Beispiel vom vboxdrv

touch /etc/modules-load.d/vboxdrv.conf

und schreiben Sie in die Datei den Namen des Kernelmoduls

vboxdrv

Dies wiederholen Sie mit allen zu ladenen Kernelmodulen.

systemd einrichten

Nun kommen wir zur eigentlichen systemd Konfiguration. Zuerst müssen wir das target, also das Ziel festlegen, was in unserem Fall das Ursprüngliche init 5 oder bei systemd das graphical.target ist.

Mit dem Befehl

systemctl enable graphical.target

geben wir dies an systemd weiter.

Nun müssen wir noch alle Deamons die beim Start geladen werden sollen, angeben. Schauen Sie dazu in die /etc/rc.conf hinein und übertragen Sie alle zu startenden Deamons in systemd.

Steht in der rc.conf zum Beispiel

DAEMONS=(syslog-ng acpid dbus iptables networkmanager ntpd alsa cupsd crond kdm)

sehen die Befehle an systemd so aus:

systemctl enable syslog-ng.service
systemctl enable acpid.service
systemctl enable apcid.socket
systemctl enable iptables.service
systemctl enable NetworkManager.service
systemctl enable ntpd.service
systemctl enable cupsd.service
systemctl enable cronie.service
systemctl enable kdm.service

Ohne NetworkManager benutzen Sie einfach

systemctl enable dhcpcd@eth0.service

Tipp: Manche Deamons haben andere Namen im systemd. So heisst zum Beispiel cupsd bei systemd cups.service. Um den richtigen Namen zu finden kann mit

systemctl --all | grep cups

gesucht werden.

Altes init-System löschen

Nun müssen Sie noch das alte init-System löschen

pacman -R initscripts
pacman -S systemd-sysvcompat

Das war es auch schon. Nach einem Neustart sollte systemd den Rechner nun ohne Probleme hochfahren. Sollte ein Deamon nicht starten können Sie die Fehlermeldung mit

systemctl status [deamon].service

abrufen.

Mehr Informationen zum Thema systemd in Arch Linux gibt es in dem sehr ausführlichen Artikel unter https://wiki.archlinux.org/index.php/Systemd

Wichtig: Wer auf der sicheren Seite sein möchte kann initscripts auch erstmal behalten und mit dem Kernelparameter

init=/bin/systemd

ausprobieren ob systemd wie erwartet funktioniert. Ist dies der Fall kann dann das alte init-System wie im letzen Kapitel beschrieben gelöscht werden.


Freitag
07. September 2012


face

Mein Netbook musste wieder als Testobjekt für ein Live-Upgrade von openSUSE 12.1 auf openSUSE 12.2 herhalten. Das ist jetzt für das Netbook das 4. Live-Upgrade seit openSUSE 11.2 und nutze es immer noch produktiv. :-) Das Upgrade ist an und für sich recht flüssig über die Bühne gegangen. Keine nennenswerte Probleme wie bei den anderen Upgrades auch. Außerdem ist mir der Geschwindigkeitszuwachs zwischen openSUSE 12.1 und openSUSE 12.2 aufgefallen, sehr wahrscheinlich würde man es nur auf einer etwas schwächeren Hardware wie z.B. auf einem Netbook bemerken. ;-)

Bevor man ein Upgrade vornimmt, sollte man sich die Versionshinweise aufmerksam durchlesen:
http://www.suse.de/relnotes/i386/openSUSE/12.2/RELEASE-NOTES.de.html

Möglicherweise gibt es noch andere Probleme, die zu umschiffen gilt:
http://en.opensuse.org/openSUSE:Most_annoying_bugs
http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.2_dev

Auch ein Blick im Bugreport zu openSUSE 12.2 ist zu empfehlen:
http://bugzilla.novell.com/buglist.cgi?…

Sollte einer der offenen Bugs möglicherweise zu einem Problem führen, die man selbst nicht beheben kann. Dann ist es besser im Bugreport, in der Mailingliste oder im IRC nachzufragen, ob dafür eine Lösung ggfs. ein Workaround existiert. Je nach Schweregrad sollte man das Upgrade lieber verschieben, bis das Problem behoben wurde.

Anbei noch eine Empfehlung für den Fall der Fälle die folgende von mir gepflegte Seite zu bookmarken (Feedbacks sind erwünscht):
http://www.opensuseusers.de/

Upgrade-Anleitung

Hinweis: Alle Befehle sind als root-User in der Konsole bzw. im Terminal auszuführen. Um Tippfehler zu vermeiden, empfiehlt es sich die Befehle zu kopieren und in die Konsole/Terminal einzufügen.

  1. Vor dem Upgrade wird empfohlen, ein Backup vom System zu machen.
  2. Alle eingebundenen Repos in /etc/zypp/repos.d vorübergehend deaktivieren:
    zypper mr -a -d

    oder alternativ:

    sed -i 's/enabled=.*/enabled=0/g' /etc/zypp/repos.d/*.repo
  3. Die alten Standard-Repos von openSUSE in /etc/zypp/repos.d vorsichtshalber entfernen:
    for REPOFILE in `grep -rliE '/distribution/12.1|/update/12.1' /etc/zypp/repos.d`; do rm -v "${REPOFILE}"; done
  4. Alle deaktivierten Repos in /etc/zypp/repos.d auf openSUSE 12.2 umschreiben:
    sed -i 's/openSUSE_12.1/openSUSE_12.2/g' /etc/zypp/repos.d/*.repo
  5. Die neuen Standard-Repos für openSUSE 12.2 einfügen:
    zypper ar -t yast2 -f -c http://download.opensuse.org/distribution/12.2/repo/oss/ "openSUSE 12.2 OSS"
    zypper ar -t yast2 -f -c http://download.opensuse.org/distribution/12.2/repo/non-oss/ "openSUSE 12.2 NON-OSS"
    zypper ar -t rpm-md -f -c http://download.opensuse.org/update/12.2/ "openSUSE 12.2 OSS Update"
    zypper ar -t rpm-md -f -c http://download.opensuse.org/update/12.2-non-oss/ "openSUSE 12.2 NON-OSS Update"
  6. Cache bereinigen:
    zypper clean -a
  7. Repo-Cache aktualisieren:
    zypper ref
  8. Upgrade starten (Abhängigkeiten auflösen):
    zypper dup
  9. Sicher gehen, dass auch alles upgegradet wurde. Wenn nicht, so oft wiederholen bis nichts mehr zum Upgraden da ist.
    zypper dup 

Mittwoch
05. September 2012


face

openSUSE 12.2 wurde veröffentlicht und kann als GNOME- bzw. KDE–Live CD sowie die Installations-DVD und die Netzinstallations-CD unter http://software.opensuse.org/122/de heruntergeladen werden.

Bei jedem Release fragt man sich: Welche Pakete sind neu? Welche Pakete sind weggefallen? Und welche Pakete wurden aktualisiert? Um die Fragen kurz und knapp zu beantworten, habe ich weiter unten eine kleine Auflistung der Neuerungen beschrieben.

Zuletzt hatte ich openSUSE 11.3 und 11.4 ebenfalls auf Basis der Repository verglichen. Aus zeitlichen Gründen konnte ich den Vergleich zwischen openSUSE 11.4 und 12.1 im letzten Jahr nicht mehr durchführen. Dennoch ist die letzte Auswertung so gut angekommen, dass ich mich entschlossen habe, sie in diesem Jahr wieder zu machen. ;-)

Zusätzlich habe ich eine umfangreiche Paketliste im offenen ODS-Tabellenformat erstellt, die ich mittels selbstgeschriebenem Skript ausgewertet habe. Das Dokument beinhaltet auch Makros, um über die Filterfunktion (Schaltflächen) im Dokument z.B. nur neuere, aktualisierte oder entfernte Pakete ein- bzw. auszublenden und ist in Englisch für die Linux-Freunde in der Welt gehalten. Die Liste berücksichtigt alle Pakete im OSS-, NON-OSS- und das Update-Repository.

Tipp: Um die Makros im Dokument in LibreOffice/OpenOffice zu aktivieren, ist es erforderlich die Makrosicherheitsstufe unter Extras -> Optionen -> Sicherheit -> Makrosicherheit auf Mittel zu stellen. Somit werden Makros im unsignierten Dokument nicht grundsätzlich abgelehnt, sondern erst auf Nachfrage beim Benutzer für das aktuelle Dokument aktiviert oder deaktiviert.

Download:
packagelist-opensuse-12-1-vs-12-2.ods
packagelist-opensuse-12-1-vs-12-2.ods.sha1

Die wichtigste Änderungen im Überblick:

Desktop
Paket openSUSE 12.1 openSUSE 12.2
GNOME 3.2.1 3.4.2
KDE 4.7.2 4.8.4
LXDE (Panel) 0.5.8 0.5.10
Xfce 4.8.0 4.10.0
Bankinganwendung
Paket openSUSE 12.1 openSUSE 12.2
aqbanking 5.0.16 5.0.23
gnucash 2.4.7 2.4.11
kmymoney 4.6.0 4.6.2
moneyplex 2009 12.0.20869
Bibliotheken / Frameworks
Paket openSUSE 12.1 openSUSE 12.2
bluez 4.96 4.99
glibc 2.14.1 2.15
gtk2 2.24.7 2.24.10
gtk3 3.2.1 3.4.4
horde4 4.0.8 4.0.13
libboost 1.46.1 1.49.0
libqt4 4.7.4 4.8.1
mono-core 2.10.6 2.10.6
mozilla-nspr 4.9.2 4.9.2
mozilla-nss 3.13.6 3.13.6
udev 173 182
udisks 1.0.4 1.0.4
udisks2 - 1.97.0
upower 0.9.14 0.9.16
Buildwerkzeuge
Paket openSUSE 12.1 openSUSE 12.2
autoconf 2.68 2.69
autogen 5.11.8 5.16
autoyast2 2.21.4 2.22.5
binutils 2.21.1 2.22
build 2012.03.06 2012.07.19
ccache 3.1.6 3.1.7
cmake 2.8.6 2.8.8
doxygen 1.7.5.1 1.8.1
gcc 4.6.2 4.7.1
gdb 7.3 7.4.50.20120603
gettext-tools 0.18.1.1 0.18.1

face

Sagt man nicht immer so? Doch, stimmt das auch? Ich hab zwar keine Ahnung wo der Spruch ursprünglich her kommt, aber dieser galt bestimmt in einem anderen Zusammenhang als das dies die Entwickler/Macher des openSUSE Projektes der gleichnamigen Distribution dem … Continue reading


Montag
20. August 2012


face

AMD Catalyst 12.8 (fglrx 8.982) wurde veröffentlicht und unterstützt Grafikkarten ab Radeon HD 5000 und höher. Das Skript makerpm-amd-12.8.sh steht ab sofort zum Download zur Verfügung und unterstützt 11.4, 12.1 und 12.2.

Offiziell unterstützt der Treiber bis Kernel 3.4. Ich habe wie schon im vergangenen Treiber auch die Kernel-Unterstützung für 3.5 als Patch im Packaging Skript hinzugefügt. Ab sofort wird auch openSUSE 12.2 mit dieser Version unterstützt, was soviel heißt, dass die RPM-Paketierung auf openSUSE 12.2 offiziell freigegeben ist. Wer das inoffizielle AMD-Repo in YaST eingebunden hat, möchte ich hier einmal erinnern, dass sich die URL zum Repo geändert hat. Mehr Informationen zum Repo in der Wiki.

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 hoffentlich nächsten Treiber-Version beheben zu lassen. Gerne würde ich mich über ein paar Rückmeldungen freuen, wie der Treiber z.B. auf openSUSE 12.2 RC 2 läuft und wo es ggfs. noch Probleme gibt. 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/2012/07/28/opensuse-amd-catalyst-12-6-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-12.6.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 zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei

<- Aktuelle Artikel