knowledge_db

In dieser Kategorie sind alle Artikel, die keine News oder kleine Tipps, sondern wissenswerte Inhalte enthalten. Darunter fällt z.B. die OS-Internals Reihe.

Eigenes Farbschema für KDE/Plasma anlegen

Das KDE/Plasma Farbschema zu ändern ist etwas aufwändiger, aber machbar.

Das KDE/Plasma Farbschema zu ändern ist etwas aufwändiger, aber machbar.

Manchmal möchte man ein eigenes KDE/Plasma Farbschema (bzgl. color-scheme) anlegen, doch nicht überall werden die neuen Farben übernommen. Panels z.B. (wie etwas Anwendungsstarter oder die Taskleiste) übernehmen Farben nicht direkt. Hier mögliche Lösungen des Problems, die mir geholfen haben:

Farbschema anlegen

Farbschemata liegen unter /usr/share/color-schemes/FooBar.color. Um ein neues Schema an zu legen kann einfach eine vorhandene Datei kopieren:

  • cp /usr/share/color-schemes/FooBar.color ~/.local/share/color-schemes/MyScheme.color

Farbschema anpassen

Nun muss man sowohl Metadaten, als auch die eigentlichen Farben anpassen:

  • Metadaten sind in der MySchema.color Datei ganz unten unter dem Punkt [General] zu finden
  • Hier den Namen anzupassen

Nun kann man die Farben anpassen. Dazu bietet KDE ein eigenes Tool (einfach nach „Colors“ um Menü suchen), welches jedoch Änderungen in eine lokale Datei schreibt (~/.config/kdeglobals), was dann nicht im neuen color-scheme enthalten ist. Entweder man kopiert dann die Daten aus ~/.config/kdeglobals heraus oder man bearbeitet die neue MySchema.color Datei manuell.

Wie ich es gemacht habe:

  • Mit KDE Farbverwaltung (nach „Colors“ suchen) Farben anpassen
  • Aus ~/.config/kdeglobals Einstellungen kopieren
  • In MySchema.color die alten durch die neuen ersetzen

Alle Eigenschaften, die man setzen kann, gibt es hier: https://hig.kde.org/style/color/dark.html

Desktop Theme erzeugen

(mehr …)

Passwort Seite überarbeitet

Ein sicheres Passwort muss nicht kompliziert sein, aber ein paar Kriterien erfüllen.

Ein sicheres Passwort muss nicht kompliziert sein, aber ein paar Kriterien erfüllen.

Nur kurz ein Hinweis in eigener Sache: Ich habe die Seite über das Erstellen von Passwörtern überarbeitet.

Was sich geändert hat

Was ich geändert habe ich eigentlich alles. Jetzt ist es mehr Fakten gestützt, leichter verständlich und es wird eher die Frage nach dem „warum“ und nicht mehr ausschließlich die nach dem „wie“ behandelt.

Zudem gibt es jetzt viele Gedankenexperimente, die sehr anschaulich zeigen was für ein Unterschied z.B. die Länge eines Passwortes für dessen Sicherheit aus macht.

Was ihr dort finden werdet

  • Hintergrundwissen
    • Wie werden Passwörter gespeichert und geknackt?
    • Grober Überblick über Hashwerte und Hashfunktionen
    • Kriterien an sichere Passwörter?
  • Passwort Erstellung und Umgang
    • Methoden: Diceware und Generator
    • Hinweise zum sicheren Umgang

Viel Spaß damit und her mit Kritik und Verbesserungsvorschlägen 🙂

Zur Seite

OS-Internals #2: Ext2 und Dateien in Linux

In Linux ist alles eine Datei, selbst Ordner und Geräte.

In Linux ist alles eine Datei, selbst Ordner und Geräte.

In Linux gibt es bezüglich Dingen wie Dateien, Ordnern, Geräten, Schnittstellen und Verknüpfungen eine schöne Regel: „On a UNIX system, everything is a file; if something is not a file, it is a process.“. Bei Linux ist also alles eine Datei (ja, auch Ordner sind Dateien), darum sollten wir mal einen genaueren Blick darauf werfen.

Dateisystem: ext2 und inodes

Da man Dateien nicht einfach hintereinander weg speichern kann (da sich z.B. die Größe ändern kann), greifen UNIX-Systeme meist auf das Konzept der inode (index node) zurück. Um zu verstehen, was eine inode ist, sollte man sich aber anschauen, wie z.B. das ext2 Dateisystem (welches inodes benutzt und auf dem viele weitere Dateisysteme basieren) funktioniert.

Zunächst zur Hardware: Ein Block ist eine Menge von Sektoren einer Festplatte, wobei ein Sektor die kleinste zu adressierende Einheit einer Festplatte ist. Ein Block ist normalerweise 1, 2, 4 oder 8 KiB groß (also ggf. ein Zusammenschluss von Sektoren), was bei der Formatierung der Festplatte angegeben wird. Fasst man mehrere Blöcke zusammen ist es eine block group.

Kommen wir jetzt zur inode, was im Prinzip nichts weiter als eine block group ist. Sie ist 128 bytes groß und enthält Metadaten und Referenzen auf weitere Blöcke.
Jede Datei ist eine Referenz auf genau eine inode, wobei die eigentlichen Daten eben in anderen inodes liegen und referenziert werden. Es gibt 12 direkte Referenzen und 3 weitere Referenzen, die jeweils auf cluster zeigen. Ein cluster enthält 256 Referenzen auf weitere cluster oder inodes. Dadurch kann eine Datei bis zu 2 TiB groß werden. (mehr …)

Seminar-Arbeit über peer-to-peer Netzwerke

Da ich mit etwas Verspätung endlich meine Note für meine Seminararbeit über peer-to-peer Netzwerke bekommen habe, stelle ich nun auch die Arbeit hier zur Verfügung.

Es geht dabei um P2P (peer-to-peer) Netzwerke und ihr Einsatz in der verteilten Software Entwicklung, wobei der Fokus eher auf technische Details liegt. Wer also einen groben Einblick in BitTorrent und ein darauf basierendes Protokoll (apt-p2p) bekommen möchte, kann sich die Arbeit gerne durchlesen.

BitTorrent als peer-to-peer Protokoll steht in der Arbeit stark im Fokus.

BitTorrent als peer-to-peer Protokoll steht in der Arbeit stark im Fokus.

In der ersten Hälfte der Arbeit geht es hauptsächlich im die technischen Details rund um BitTorrent. Das Protokoll apt-p2p implementiert eine leicht veränderte Variante von BitTorrent mit interessanten Ideen zur Performance Optimierung. Für viele sehr kleine Dateien (eben Pakete vom apt-Paketmanager) ist BitTorrent nämlich richtig schlecht. Auch gibt es ein verteiltes Versionierungssystem, welches an BitTorrent angelehnt ist.

Hier sind die Dateien

PDF
der Arbeit, wie sie bei der Abgabe war.

ZIP
der Quelldateien (inklusive Vortrag, BibTeX und Bilddateien)

Alle anderen Paper befinden sich natürlich weiterhin unter Wissenswertes → Paper.

OS-Internals #1: /dev/null in Linux UND Windows

Wie ein Müllcontainer fungiert /dev/null unter UNIX als schwarzes Loch für Daten.

Wie ein Müllcontainer fungiert /dev/null unter UNIX als schwarzes Loch für Daten.
(by-nc-sa 2.0)

Dies ist der erste Beitrag der OS-Internals Reihe. Ich versuche unter diesem Begriff sehr technische Aspekte von Linux zu beleuchten und verständlich zu erklären.

Die meisten, die Linux benutzen, sollten das Gerät /dev/null kennen, welches auch Null-Gerät genannt wird. Hierbei handelt es sich um ein spezielles Gerät, das alle Eingehenden Daten sofort löscht und gar nicht erst persistiert. Es wird daher auch oft scherzhaft als schwarzes Loch oder Nirvana bezeichnet.

Technisch ist /dev/null – genau wie alles andere bei Linux – eine Datei, jedoch eine spezielle, die output streams bereit stellt und input streams entgegen nehmen kann (doch zu Dateien in Linux in einem späteren Teil mehr). Wenn man schauen möchte was es ist, kann man auch einfach folgendes machen und sich die Ausgabe anschauen:

Eigenschaften
$ ls -alh /dev/null
crw-rw-rw- 1 root root 1, 3 Nov 10 19:06 /dev/null

Es ist also eine spezielle Datei (das c bedeutet char device), jeder hat Zugriff darauf, es gehört root und es werden weitere, für uns momentan nicht wichtige, Informationen angezeigt.

Nutzen von /dev/null

Man kann es einsetzen um z.B. einen gewissen output-Stream (z.B. stderr) aus der Ausgabe von einem Programm zu entfernen. Hierfür benutzt man einfach den Umleitungs-Operator (redirection operator, also das > Zeichen) kombiniert mit der file descriptor number für stderr (sprich 2):

Ausgaben weg schmeißen
$ find /etc/ -iname apt 2> /dev/null

Wir suchen hier nach allen Dateien und Ordnern unter /etc/ in deren Namen der string apt vorkommt. Alle Ausgaben auf den stream stderr werden ins Nirvana geschickt.

Gefahren von /dev/null

(mehr …)