Beiträge getagged mit Linux
Debugging von C-Applikationen unter Linux
Verfasst von Schakko unter Entwicklung, Linux am 22. Juli 2010
Da ich gegenwärtig an libopenranked von etqw-openranked arbeite und ich vermute, dass ich meine Erkenntnisse nach einiger Zeit wieder vergesse, gibt es hier die Kurzfassung.
Damit bei einem Segmentation Fault eine Core-Dump erzeugt wird, muss
ulimit -c unlimited
aufgerufen. Damit wird festgelegt, dass der Core-Dump beliebig groß sein darf.
Mit
gdb a.out core backtrace
lassen sich die letzten Ausführungsschritte der Applikation anzeigen.
Mit
apt-get install valgrind valgrind --tool=memcheck --leak-check=yes ./a.out
lässt sich überprüfen, welche Funktionen potenzielle Memory Leaks erzeugen, die wiederum zu einem Segmentation Fault führen können.
Windows 2003 als zentraler Event Log-Server / Freigeben von Event Logs an bestimmte Benutzer
Verfasst von Schakko unter Active Directory / LDAP, Linux, Windows am 11. Juni 2010
Florian hatte vor einigen Wochen das Tool eventcreatef vorgestellt. Es dient dazu, dass komplette Log-Dateien und nicht nur einzelne Log-Nachrichten in die Ereignisanzeige von Windows geschrieben werden können. eventcreatef delegiert die Aufrufe an das Microsoft-Tool eventcreate, dass die übergebenen Daten in kleinere Teile an den jeweiligen Server sendet.
Somit kann man mit Hilfe von eventcreatef einen zentralen Log-Server auf Basis von Windows Server 2003 o.ä. aufsetzen, der alle Log-Dateien sammelt, z.B. die, die während eines nächtlichen Backups auftreten.
Leider gibt es für Linux kein Tool, dass direkt in die Ereignisanzeige von Windows Server 2003 schreiben kann. Für unsere heterogene Umgebung war dies ein ungünstiger Sachverhalt. Ich musste also einen generischen Service schreiben, der per SOAP die Log-Daten entgegen nehmen konnte und dann dementsprechend an eventcreatef weiterdelegiert.
Dabei ist das unten angehängte Script namens eventcreateservice.php (ECS)heraus gekommen: Es stellt über das Zend Framework eine SOAP-Schnittstelle bereit, die die einfache Methode create besitzt. Wird das Script über eventcreateservice.php?wsdl aufgerufen, wird die WSDL-Datei ausgegeben, über eventcreateservice.php?bash lässt sich ein Bash-Script downloaden, dass mit Hilfe von curl eine Verbindung mit dem SOAP-Service herstellt. An dem Bash-Script muss nichts weiter angepasst werden, da die URLs automatisch generiert werden. Somit lassen sich nativ auf Linux-Maschinen Einträge in die (native) Ereignisanzeige von Windows-basierten Maschinen schreiben.
Ein Syslog-Server ist also nicht mehr nötig. Das Konzept ist besonders für kleinere Unternehmen interessant, die mehr Windows-Maschinen als Linux-Maschinen besitzen und für die ein zentraler Syslog-Server oversized ist.
Nachdem ich ECS fertig entwickelt hatte, ging es nun darum, dass ich die von mir erstellten Log-Einträge nicht in den Standard-Log-Dateien Applikation, System und Sicherheit schreiben wollte, sondern in eine Extra-Logdatei namens Backups.
Florian stellt in der oben bereits genannten URL ein kleines Tool namens CreateEventLog2 bereit. Über die Aufmachung und Fehlerbehandlung der GUI lässt sich streiten, mir ging es um den Funktionsumfang: CreateEventLog2 erzeugt eine neue Log-Datei, die dann in der Ereignsanzeige der MMC angezeigt werden kann.
Damit hatte ich schon ein Großteil erreicht: Ich konnte nun von Windows-Systemen aus Log-Nachrichten auf unserem Log-Server speichern, die Linux-Systeme konnten über das Bash-Script und den SOAP-Service ebenfalls in die Windows-Ereignisanzeige schreiben und schließlich hatte ich ein weiteres Log neben den Standard-Windows-Logs.
Im letzten Schritt ging es nun darum, das von mir definierte Log einem dedizierten Benutzer zugänglich zu machen. Ich wollte in der Konfigurationsdatei von ECS (logischerschweise) keinen Domänen-Administratoraccount eintragen, sondern einen Benutzer mit beschränkten Rechten. Für dieses Vorhaben muss man zuerst einmal ein paar Sachen wissen: Der Zugriff auf die Log-Dateien eines Systems werden über Registry-Einträge geregelt. Es gibt unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog zu jeder Log-Datei einen Schlüssel, der wiederum diverse Attribute enthält. Wichtig ist das Attribut CustomSD: dieses beschreibt anhand eines SDDLs, ob und wer auf dieses Objekt zugreifen darf. Standardmäßig steht in der CustomSD (in meinem Fall zu finden unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Backups\CustomSD) ein String der folgenden Art: O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0×7;;;BA)(A;;0×7;;;SO)(A;;0×3;;;IU)(A;;0×3;;;SU)(A;;0×3;;;S-1-5-3). Sieht kryptisch aus, ist es aber eigentlich nicht – wenn man weiß, wie die SDDLs aufgebaut sind.
Kurz dazu: Jeder eingeklammerte Eintrag, z.B. (D;;0xf0007;;;AN) definiert eine Zugriffsregel (ACE). Die erste Regel, die vom System gefunden wird und zutrifft, wird benutzt.
Wie dem auch sei: Es gibt glücklicherweise ein Tool namens sddlparse, das die zugegebenermaßen etwas kryptisch anmutende Zeichenkette analysiert und dann wieder in lesbarer Form ausspuckt.
Nachdem ich damit die benötigten Rechte für einen schreibenden Zugriff auf die Ereignisanzeige auslesen konnte (ADS_RIGHT_DELETE, ADS_RIGHT_READ_CONTROL, ADS_RIGHT_WRITE_DAC, ADS_RIGHT_WRITE_OWNER, ADS_RIGHT_DS_CREATE_CHILD, ADS_RIGHT_DS_DELETE_CHILD und ADS_RIGHT_ACTRL_DS_LIST), erstellte ich einen neuen ACE mit eben diesen Rechten. Die ACE muss an erster Stelle eingefügt werden, so dass der Registry Key wie folgt aussieht: O:BAG:SYD:(A;;LCDCCCWOWDSDRC;;;S-1-5-21-xxx-xxx-xxx-xxx)(nächste ACE…). Der Registry Key wird übrigens bei jedem Aufruf der Ereignisanzeige ausgelesen, somit tritt die Änderung sofort in Kraft.
Ich fügte die SID unseres dedizierten Ereignisanzeigen-Benutzer mit Hilfe der obigen ACE hinzu und war in der Lage mit diesem in die Ereignisanzeige zu schreiben.
Während ich mich in SDDLs und ACEs einarbeitete, fiel auch ein kleineres Tool namens ACECreator ab. Es verbindet sich mit dem Active Directory und sucht mit Hilfe von Ambigious Name Resolution (ANR) Objekte heraus. Diesen Objekten lassen sich dann die Einstellungen verpassen, die man braucht, das passende ACE wird automatisch erzeugt.
Alles in allem war dieses Projekt äußerst spannend. Zwar klingt die Durchführung relativ einfach, allerdings gab einige Probleme mit den Rechten bzw. Benutzeraccount, unter dem eventcreatef lief u.s.w.
Lesenswert sind folgende Links, die ich u.a. für den ACECreator als Referenz herangezogen habe:
- Security Descriptor String Format in der MSDN
- ACEs in der MSDN
- Parsing SDDL Strings bei Jorge
- Overview of Active Directory security
- Vordefinierte Sicherheitskennungen im Technet
Angehängte Downloads
eventcreateservice-1.0.zip (3.6 KiB, 48 hits)
ACEGenerator-1.0 (12.2 KiB, 43 hits)
Perle IOLAN und RXTXcomm (Java) unter Linux
Für unser aktuelles Projekt verwenden wir eine Perle IOLAN-Box. Die Box stellt serielle Ports – in unserem Fall sind das zwei Stück – über Ethernet zur Verfügung.
Der Einsatzbereich ist z.B. nötig, wenn man GSM-Modems in abgeschirmten Räumen (Rechenzentren, Bunkern) betreiben will. Die IOLAN-Box bildet eine Bridge zwischen Seriell- und Ethernet ab. So lässt sich das GSM-Modem (Seriell) an die IOLAN-Box (Seriell) anschließen, die wiederum über Ethernet an das Netzwerk angebunden ist. Für Linux und Windows existieren passende Programme, die nun lokal wiederum die Verbindung über das Netzwerk als serielles Interface abbilden.
Gestern stieß ich bei der Einrichtung der lokalen Schnittstellen auf ein Problem: RXTXComm – das Java-Framework zur Kommunikation mit seriellen/parallelen Schnittstellen – listete beim Start die /dev/tx00*-Devices nicht auf. Die FAQ von RXTX weist daraufhin, dass man per
System.setProperty(“gnu.io.rxtx.SerialPorts”, portFileNames) zusätzliche Ports definieren kann. Der Lösungsansatz brachte kein Erfolg.
Zweite Idee war dann, dass ich – wie in der FAQ beschrieben – die tx*-Devices manuell in die RXTXCommDriver.java eintrage. Auch das war nicht von Erfolg gekrönt.
Zeit zum Nörgeln: Warum Open Source besser ist als Closed Source
Verfasst von Schakko unter Open Source am 11. August 2009
Mit diesem Artikel möchte ich mal meine Sichtweise zum Thema Open Source / Closed Source niederlegen.
Generell gehöre ich zu der Sorte von Entwicklern, die ihre Software unter der BSD-Lizenz oder GPL veröffentlichen. Allerdings sage ich auch nicht, dass z.B. Treiber, die als Binary veröffentlicht werden, nicht in Linux integriert werden sollten.
Ich bin froh, wenn sich überhaupt Unternehmen die Mühe machen und Ressourcen binden, um die Portierung der Treiber nach Linux (BSD, MacOS, Solaris etc. – wenn ich im folgenden Text von Linux spreche, schließt dies diese Betriebssysteme einfach mal mit ein) voran zu treiben. Schließlich kann man so unter diesen Betriebssystemen neue und (oft) bessere Hardware schnell nutzen.
Die Entwicklung von Treibern nach dem altbekannten Ansatz des Reverse Engineerings, wie es z.B. bei Samba bis zur Veröffentlichung der Protokoll-Details von Microsoft der Fall war, nimmt einfach viel zu viel Zeit in Anspruch. Und Zeit ist Geld.
James Bottomley, Vorsitzender des TAB und SCSI Maintainer, hat letztes Jahr ein Essay herausgegeben, in dem er indirekt die Bereitstellung der Treiber-Quellcodes an die Community fordert. Intel und ATI sind bereits vor einiger Zeit mit ihren Treibern auf den Zug aufgesprungen.
Die Vorteile für Intel, ATI und andere Unternehmen, die ihre Quellen und Interface-Dokumentation veröffentlichen, liegen eigentlich auf der Hand:
- Es wird eine wesentlich breitere Nutzerbasis angesprochen. Gehen wir von einer neuen 10 GBit-Netzwerkkarte, die auf den Markt geworfen wird. Folgende Szenarien sind nun möglich:
- Die Treiber liegen nur in binärer Form für Windows-Plattformen vor.
Als Zielgruppe für die Nutzung dieser Karte wird man vor allem Rechenzentren oder Internet-Provider ansprechen wollen, die zum großen Teil auf Linux setzen. Es liegt ein eindeutiger #fail vor, da der Hersteller sich einen Großteil der Nutzerbasis versperrt. - Der Hersteller veröffentlicht die Schnittstellenbeschreibung.
Bleiben wir bei unserer Netzwerkkarte: Der Hersteller entschließt sich, die Treiber in binärer Form für Windows-Plattformen zu veröffentlichen. Zusätzlich legt er die Spezifikationen für die Hardware offen.
Ambitionierte Entwickler haben nun die Möglichkeit, den Treiber für Linux nachzubauen. Wichtig ist aber, dass es beim Hersteller immer einen Ansprechpartner für die Treiber-Entwicklung gibt, da oft die Dokumentation trotz merhmaliger Reviews Fehler enthalten kann. - Windows und Linux werden mit binären Treibern beliefert.
Beide “großen” Betriebssysteme werden mit Treibern in Form von Binärpaketen ausgeliefert. An sich nicht schlecht, schließlich hat nun eine große Zielgruppe die Möglichkeit, die darunter liegende Hardware einzusetzen.
Aber hier gibt es zwei gravierende Probleme: Auf der einen Seite werden – so habe ich zumindest das Gefühl – die Linux-Treiber als Abfallprodukt gesehen, die “mal so nebenbei” programmiert wurden. Viele Treiber-Entwickler kennen eher die Windows- als Linux-Umgebung. So kommt es, dass der Linux-Treiber Kernel-Panics auslöst oder ähnliches. Falls es mal Probleme mit dem Treiber geben sollte, wird dies (hoffentlich) zur Kenntnis genommen – aber eine baldige Lösung ist oft nicht in Sicht.
Das zweite große Problem besteht in den Regeln bzw. Lizenzen, die der Distribution zu Grund liegt. Unter Ubuntu ist es kein Problem, binäre properitäre Treiber aus einem anderem Repository nachzuinstallieren. Das Debian-Projekt würde hingegen niemals Treiber in binärer Form einbinden. - Der Treiber liegt in binärer Form und als Quellcode vor.
Ideal ist meiner Meinung nach die folgende Form: Der Treiber liegt für Windows und auch Linux in binärer Form vor, zusätzlich gibt es den Quellcode des Treibers zum Download. Entwickler seitens des Herstellers haben sich um die Dokumentation gekümmert und stehen als Ansprechpartner zur Verfügung.
In diesem Zuge muss ich ganz klar ATI mein Lob aussprechen, da sie den kompletten Schritt im Jahr 2008 vollzogen haben.
Wie schon geschrieben: Ideal wäre Konzept Numero 4. Leider hat sich NVidia gegen ein solches Vorgehen ausgesprochen. Die Absage wurde mit der Begründung erteilt, dass der Treiber geistiges Eigentum enthält. Mich würde interessieren, von welchem “geistigen Eigentum” NVidia spricht. Irgendwelche genialen Treiber-Optimierungen? Ein Quake-Easteregg, dass bei einer speziellen Auflösung aktiviert wird?
Meine Idee für eine kommende Hardware-Generation wäre die folgende: Alle Teile, die “geheim” sein sollen, werden direkt in der Hardware, z.B. mit Hilfe von FPGAs entwickelt. Die Hardware wird nun über weiter abstrahiertere Interfaces dem Kernel (Windows, Linux oder sonstwas) zur Verfügung gestellt. Bei einem Update der (Hardware-)Treiber profitieren alle Betriebssysteme. - Die Treiber liegen nur in binärer Form für Windows-Plattformen vor.
- Der Treiber wird durch die breitere Nutzerbasis von mehr Personen überprüft und auch getestet.
- Machen wir uns nichts vor: Linux-Benutzer sind zum größten Teil Frickler – ich zähle natürlich auch dazu. Viele Frickler sind bei einem Problem bereit, Zeit in die Lösung zu investieren und wenn nötig auch dafür neue Programmiersprachen oder Techniken zu erlernen.
Henrik Ibsen sagte mal “Weltverbesserer gibt es genug, aber einen Nagel richtig einschlagen können die wenigsten” – ich behaupte mal eher folgendes: “Frickler gibt es genug und die meisten probieren den Nagel einzuschlagen bis er wirklich sitzt.” - Durch die große Anzahl von Entwicklern, die Zugriff auf den Quellcode haben, lassen sich Features oder Performance-Optimierungen einfacher implementieren oder sich eben eine Grundlage für eine neue Grafikkarten-Generation schaffen.
Der Grund für diesen Post lieferte mir konkret NVidia. Vor einigen Wochen bestellte ich mir ein Zotac ION-Board, dass als Grundlage für meinen neuen Server und als DVD-Player dienen sollte.
Nun ist es aber so, dass mein Fernseher in Kombination mit dem HDMI-Ausgang des Boards einen extremen Overscan produziert, dass man von der gesamten Oberfläche 3/4 auf dem Fernseher sieht.
Sucht man in den Foren von NVidia nach “Overscan”, findet man massig Einträge, die sich damit befassen. Mich stört es ganz besonders, dass der Windows-Treiber die Möglichkeit bietet, das Overscanning zu neutralisieren. Dieses Feature ist aber unter Linux – in der äußerst armseeligen – Konfigurationsoberfläche nicht vorhande und lässt sich auch nicht per Xorg.conf vernünftig einstellen.
Ganz ehrlich: Hätte ich den Quellcode für den NVidia-Treiber, wäre ich bereit, mich des Themen “Treiber-Entwicklung unter Linux” und “Overscanning” zu stellen – so sehr stört mich dieser Bug.
Konvertieren von virtuellen Linux-VMware-Maschinen nach Citrix XEN Server
Verfasst von Schakko unter Linux, Virtualisierung am 15. Juli 2009
Wegen der Migration unserer virtuellen Server-Infrastruktur von VMware Server nach Citrix XEN Server 5.5 stieß ich auf ein Problem. Einer unser virtuellen Maschinen dient als Backup-Server und läuft unter Linux, in dem Fall unter Ubuntu 6.10 Server.
Zur Konvertierung der Maschinen dient das Tool XenConverter, das von Citrix kostenlos bereit gestellt wird.
Ich führte also die Konvertierung der VMDK-Datei aus, dies funktionierte soweit auch ohne Probleme, eben so klappte der Import in den Citrix XEN Server einwandfrei.
Beim Starten des Systems hing Linux allerdings mit der Meldung
Waiting for root file system...
VMware beschreibt in der Dokumentation, dass standardmäßig die Festplatten als SCSI-Devices gemountet werden sollen. Dies würde zu einer besseren Performance führen. Diesen Hinweis haben wir beim Einrichten aller virtuellen Maschinen unter VMware auch durchgeführt.
Allerdings bindet Citrix XEN Server nach dem Import die virtuellen Festplatten als normale IDE-Devices ein. Mir fiel das auch erst nach ein paar Minuten auf, nachdem ich über die vorher eingetragenen Boot-Meldungen schaute.
Die Lösung des Problems war dann relativ einfach umzusetzen:
- Virtuelle Maschine neu starten
- Während Grub lädt, ESC drücken
- Aktuellen Kernel auswählen
- /dev/sda1 durch /dev/hda1 ersetzen
- System booten und als root anmelden
- in der /boot/grub/menu.lst /dev/sda1 durch /dev/hda1 ersetzen, so dass die Änderungen permanent sind
MLG: Präsenzklausur bestanden / Spielzeug bestellt / Kernel-Patch
Verfasst von Schakko unter Active Directory / LDAP, Linux, Mathematisch-logische Grundlagen der Informatik, Webdesign & Web-Ergonomie, ckl-net am 24. Juni 2009
Ich wurde bereits heute darüber informiert, dass ich das Modul Mathematisch-logische Grundlagen mit einer Note von 1.0 bestanden habe. In der Präsenzklausur habe ich 83% erreicht – ich vermute, dass der Punktabzug durch die Vollständige Induktion und der ersten Aufgabe zustande kommt – durch meine Bonuspunkte konnte ich die fehlenden Prozent zur 1.0 aber ausgleichen. Somit ist also das dritte Modul bestanden. Für mich folgt als nächstes Modul Web-Design und -Ergonomie, dass ich hoffentlich zum nächsten außerordentlichen Klausurtermin am 14.08.2009 beenden kann.
Mein heutiger Tag war relativ hektisch: Heute Vormittag war ich in Osnabrück und habe mir das Kolloquium von Sarah angeschaut, danach ging es in die Firma, dann zum Training und schließlich zur Bandprobe.
Als “Belohnung” für die bestandene Klausur – von der ich während des Kolloquiums per Email (es lebe Active Sync) erfuhr – habe ich mir heute Abend neue Hardware für das ckl-net bestellt, da mein “altes” Embedded Board mittlerweile nicht mehr meinen Zwecken genügt. Somit habe ich dann ein Zotac ION ITX B anstatt des von mir erst angedachten MSI IM 945GSE bestellt, zuzüglich fanless Netzteil von Fortron und Bluetooth Tastatur. Ich freue mich wieder auf’s Frickeln 
Die letzten beiden Abende verbrachte ich damit, auf meine Wii Homebrew Software zum Laufen zu bringen. War an sich auch schnell gemacht. Allerdings hatte ich das Problem, dass der SD-Kartenleser meines alten Notebooks (Tagra Vision 811) unter Ubuntu zwar erkannt wurde, ich aber keine Daten darauf schreiben konnte. Mit einem externen Kartenleser funktionierte das Schreiben sowohl unter Windows als auch unter Linux. Für mich stand also fest, dass meine SD-Karte völlig funktionsfähig war.
Theoretisch hätte ich das Problem dabei bewenden und mir meine Homebrew über den externen Kartenleser auf die Karte kopieren lassen können. Aber wie das so ist: Man möchte ja das Problem auch beheben, um ein Erfolgserlebnis zu haben.
Deshalb habe ich mir die letzten Sourcen des Linux Kernels geschnappt und die im SCSI-Treiber – das SCSI-Subsystems ist für das Lesen von SD-Medien zuständig – verankerten Überprüfungen, ob ein Medium schreibgeschützt ist, deaktiviert.
Nach der Kompilierung des Kernels funktionierte auch das Schreiben auf die SD-Karte.
Und zu guter letzt noch eine Werbung in eigener Sache: Christoph hat heute das Active Directory Plugin für WordPress veröffentlicht. Klasse Sache und funktioniert sogar 
In aller Kürze: Unter Linux WAV zu MP3s konvertieren
Nach der gestrigen Bandprobe bekam ich unsere Samples als WAV zugeschickt. Als ich mit lame versuchte, die Dateien mit lame in.wav out.mp3 zu konvertieren, bekam ich den Fehler Unsupported data format: 0×0011. Der Fehler enstand dadurch, dass die WAV-Datei mit einer Kamera aufgenommen wurde. Die Kamera wandelt den Audio-Stream automatisch nach Microsoft ADPCM und nicht pures PCM um. Außerdem wird eine Sample Rate von 8000 Hz benutzt. Ungünstig.
Mit ADPCM kommt hingegen ffmpeg klar. Leider ist aus lizenzrechtlichen Gründen in den Binaries von Ubuntu der MP3-Outputstream nicht mit kompiliert wurden. Deshalb braucht man einen zusätzlichen Konverter, wie z.B. Bladeenc.
Damit nun alles funktioniert und Bladeenc nicht den Fehler ERROR: Sample ‘sample.wav’ is not in 32, 44.1 or 48 kHz!
meldet, muss folgendermaßen vorgegangen werden:
ffmpeg -y -i sample_low.wav -ar 44100 sample_high.wav bladeenc sample_high.wav sample.mp3
Interessante Links (Die besten Einzeiler, Analyse mit Traceroute, Closures and JVM)
Verfasst von Schakko unter Effizient arbeiten, Java, Linux am 23. Februar 2009
Hier ein paar interessante Links, die über das Wochenende in meinen Lieblings-Blogs aufgetaucht sind
- Command Line FU – Die besten Einzeller Einzeiler für die Kommandozeile (Linux)
- Analyse mit Traceroute
Sag was!