BitBastelei #155 – KiCad: Wir basteln ein PCB

KiCad ist eine freie Software zur Erstellung von PCBs. Ich selbst nutzte bisher das Paket EAGLE, wenn es jedoch freie Alternativen gibt, welche meine Bedürfnisse erfüllen, wechsel ich gerne. Hier gibts einen Kurzen Blick auf KiCad und die enthaltenen Funktionen. Als Beispiel wird die Blink-Schaltung von http://www.555-timer-circuits.com/flashing-led.html erstellt, in ein Board umgesetzt und passende Gerber-Dateien zur Platinenbestellung erzeugt.

Linux: Partitionen innerhalb einer Image-Datei/LV mounten

Bisher speicherte ein Windows-System seine Datensicherung per CIFS (aka Samba) auf einer Linux-basierten NAS. Das Konzept ist dabei schon etwas älter – die Windows-Software unterstützte bei der Einrichtung weder Kompression noch Deduplizierung, sodass hier das ZFS-Dateisystem der Linux-Kiste einiges an Platz einsparen konnte. Inzwischen ist die Windows-Software gewachsen: Kompression und Deduplizierung werden bereits vorab durchgeführt, dafür machten die vielen neuen Funktionen immer häufiger Probleme mit CIFS. Kaputte Locks, schlechte Performance, Verbindungsabbrüche – alles lässt sich recht genau auf die Kombination aus dem Server und CIFS zurückführen. Während eine “normale” Kopie unter Linux mit etwa 100MB/s von statten geht schafft der Server nur 4MB/s. Andere Protokolle sind schneller, andere Windows-Server haben ebenfalls keine Probleme. Inzwischen sind ohnehin neue Platten fällig – Zeit hier gegenzusteuern.

Die Speicherung soll weiterhin auf der Linux-Kiste erfolgen – dort ist die Sicherung und Verwaltung deutlich zuverlässiger und flexibler. Andererseits habe ich keine Lust auf CIFS-Fehlersuche, also lassen wir es einfach weg – die Lösung: iSCSI. Der Windows-Server greift direkt auf den rohen Datenträger des Linux-Systems zu. Da wie erwähnt keine Linux-seitige Kompression stattfinden muss wird diese einfach per LVM verwaltet und ist über den Kernel-iSCSI-Server exportiert. Das Anlegen verläuft ohne Probleme, müssen nur noch die Daten rüben. Mit 4MB/s. Bei fast 4TB. Mit 5 Tagen Restzeit. Nope.

Also, fassen wir nochmal zusammen: Sowohl der alte als auch der neue Datenbestand liegen auf dem selben Linux-System. Warum nicht einfach da kopieren? NTFS-Schreiben unter Linux ist zwar nicht schnell, aber die 4MB/s-Marke sollte zu schaffen sein. Problem: Auf dem LVM-LV hat Windows automatisch eine GPT-Partitionstabelle angelegt, sie lässt sich also nicht direkt unter Linux mounten.

Um trotzdem an das NTFS-System zu kommen müssen wir erst mal wissen wo die passende Partiton beginnt. Hier kommt parted zum Einsatz, welcher auch GPT-Partitionstabellen unterstützt. Da wir die Angaben in Byte, nicht den üblichen Sektoren, benötigen muss die Anzeige erst ungeschaltet werden.

Wie wir sehen wurden auf dem LVM-LV durch Windows zwei Partitionen angelegt: Die Erste enthält Managementdaten, die Zweite ist unsere eigentliche NTFS-Datenpartition. Letztere beginnt bei 135266304 Byte – genau diesen Bereich müssen wir auf dem Datenträger also überspringen um auf das NTFS-Dateisystem zugreifen zu können. Also legen wir uns ein passendes Loop-Device an. Da ich bereits ein anderes Device aktiv habe nutze ich loop2 – generell ist die Zahl wählbar.

Passt doch, schon haben wir unter Linux nativen Zugriff auf das Device. Das Kopieren läuft nun mit 90MB/s – nicht ganz die bestmögliche Geschwindigkeit, für NTFS über fuse aber kein Schlechter wert – und etwas schneller als die 4MB/s der Windows-Kiste.

Linux als iSCSI-Target

iSCSI ermöglicht es entfernte Festplatten über Ethernet an einen Rechner anzubinden. Hierbei kümmert sich nicht wie bei CIFS/NFS/… der Zielrechner um die Dateiverwaltung, sondern der Client behandelt die Festplatte wie eine lokal eingebaute – incl. Partitionierung, Dateisystem & Co. Ethernet ist hierbei zwar nicht die schnellste Lösung, jedoch erheblich günstiger und flexibler als professionelle Lösungen wie Fibre-Channel.

Ich nutze ein System auf Basis von Arch Linux, welches eine Partition an einen anderern Rechner bereitstellen soll. Im iSCSI-Jargon nennt sich dies “Target”, der Client “Initiator”. Zur Verwaltung unter Arch nutze ich die Free-Branch des LIO targetcli, dies ist im AUR zu finden.

Im ersten Schritt starten wir das iSCSI-System. Hierbei werden die nötigen Module geladen und ggf. zuvor definierte Geräte exportiert.

Nun starten wir das Management-Tool. Es stellt eine eigene Konsole zur Verfügung. Erst wird die Festplatte mit einem internen Namen verknüpft. Ich nutze hier zur besseren Übersicht den Partitionsnamen

Im Anschluss erstellen wir eine “Target Portal Group” (=Konfigurationsspeicher für das iSCSI-Target) samt passendem “IQN” (=iSCSI-Adresse). Letztere wird im nächsten Schritt benötigt, mit ls kann man bei allen Schritten die aktuelle Konfiguration anzeigen lassen.

nun registrieren wir die zuvor bekanntgemachte Festplatte als LUN (=logischer Speicher)

Nun erstellen wir das Portal selbst (=legen einen Server an), erlauben die Adresse des Initiators, welche man am Client nachschlagen kann, und legen Benutzername und Kennwort fest

Zuletzt wird die Konfiguration gespeichert. Das iSCSI-Target ist nun nutzbar.

Sinnvollerweise sollta man target noch mit einem “systemctl enable target” beim Systemstart automatisch starten lassen.

BTRFS-Recovery

Narf… Das war zu viel. Durch einen Umbau hatte sich offenbar ein Kabel im Lüfter meines Chipsatzes verheddert – keine gute Voraussetzung, wenn man mal eben Wine neu kompiliert. Es kommt, was kommen musste: Kernel panic.

Nunja, Fehler gefunden, weiter gehts. Nicht. Zwar startete das System, meine Home-Partition blieb aber verschwunden. Kurzer Blick auf den Aufbau: Mein Home liegt auf einer separaten Partition, ist mit LUKS verschlüsselt und nutzt – da ich die gigabyteweise IRC-Logs vorratsdatenspeichere und transparente Komprimierung wollte – BTRFS. Das Log verrät: LUKS selbst läuft, mount hingegen scheint sich aufzuhängen. In dmesg sieht alles OK aus, nur die normalen BTRFS-Meldungen, keine Fehler.

Strange, aber Reboot fixed ja fast alles, also schnell die magischen Zeichen eingetippt und zur Sicherheit im Rescue-Mode gestartet. Dort per Hand cryptsetup aufgerufen und erst mal btrfsck losgelassen. Kein Fehler. Mount? Nope.

OK, nun bin ich genervt, vor allem da die Kiste nicht unbedingt schnell bootet. Qemu to the rescue, also schnell ein Debian geklont und die Partition vorgesetzt. Schlechte Idee. Die bei Debian genutzten BTRFS-Libs/Module sind eine Nummer zu alt und können mit der Partition gar nichts anfangen. Ein Arch-Download später kann es weiter gehen.

Erst einmal ein normaler mount in der VM – vielleicht ist ja nur der Host kaputt, außerdem ist auf der CD ein älterer Kernel. Leider ohne erfolg, also VM-Reboot und den Hammer ausgepackt. Mit “mount -o recovery,nospace_cache” lassen sich viele Fehler schon beheben, aber auch hier scheint der mount nichts zu vollziehen. Keine Reaktion, keine IO-Last, keine Fehlermeldung.

Die Lösung: btrfs_zero_log. Hiermit werden die offenen Transaktionen gelöscht. Die kann zwar zu Datenverlust von Änderungen, die kurz vor Absturz geschrieben wurden, führen, aber besser als gar keine Partition. Der mount in der VM war schlussendlich erfolgreich und auch der Host verfügte kurze Zeit später wieder über alle Dateien. Warum btrfsck das offenbar defekte Log nicht ankreidete ist mir allerdings ein Rätsel – sollte das nicht die Aufgabe des Tools sein?

Software als Windows-Service

Programme starten ist toll. Einige müssen aber immer wieder gestartet werden, hierzu nutzt man unter Windows so genannte “Dienste”. Leider sind das unter Windows NT (also auch z.B. Windows 7/8/10, Windows Server 2008/2012) keine einfachen Programme, sondern erfordern spezielle Registrierungen. Leider gent so etwas (soweit mir bekannt) nicht mit Hausmitteln.

Abhilfe schafft ein kleines Tool: winserv verwandelt ein beliebiges Programm in einen passenden Dienst. Hierbei gibt es folgende Modi:

install richtet ein Programm als Dienst ein
configure ändert einen vorhandenen Dienst
uninstall entfernt den Dienst

Zum Anlegen gibt man folgende Parameter:

-displayname Angezeigter Name des Dienstes
-description Beschreibung (das, was in der Diensteverwaltung in der zweiten Spalte steht)
-start Start-Art des Dienstes – “auto” “demand” oder “disabled” (Bedeutung selbstredend, oder?)

Beispiel:

Alternativ kann man auch einen Geplanten Task mit dem Trigger “Bei Systemstart” verwenden, hier muss man jedoch auf die komfortableren Prüf- und Verwaltungsfunktionen des Dienst-Managers verzichten.

Q’n’D Windows-Shutdown-Daemon in PHP

Alles in Deckung, ich mache wieder unschönes Zeugs. Ich hatte ja bereits erklärt wie man über RPC/Samba einen Windows-PC von Linux herunterfahren kann. Leider ist die Installation von Samba aus Embedded-Systemen eine eher ungünstige Sache und ist in meinem Fall wegen Speichermangel nicht drin. Allerdings ist sowohl auf dem Embedded-System als auch dem betroffenen Rechner PHP verfügbar. I aim to misbehave.

Auf dem herunterzufahrenden Windows-Rechner wird per PHP ein TCP-Socket geöffnet. Dieser Code basiert auf einem Beispiel von Michael Kliewe. Um Scriptkiddies nicht direkt Zugang zu geben ist etwas (sehr schlechte) Challenge-Response-Authentifizierung drin – nunja, ist kein kritisches System. Wird der Client bestätigt folgt ein simples Shutdown per exec. Nicht viel, aber schnell Fertig und funktioniert:

Der Client bastelt sich eine passende Authentifizierung und spielt Zündknopf:

Hoffen wir, dass es läuft und ich nie wieder drauf schauen muss, denn irgendwo tut sowas selbst mir weh ;)

BitBastelei #154 – Microsoft Kommunikationssystem: Netzteil/Logikboard

Während meine aktuellen Projekte entweder noch kein zufriedenstellendes Videoscript ergeben oder etwas unter dem Poststreik leiden muss wieder etwas aus der Konserve her: Im Müll fand sich das “Netzteil” eines Kommunikationssystems von Microsoft. Mal schauen, was da denn wirklich drin steckt und ob es am Ende so “kaputt” ist, wie der Fundort vermuten lässt.

SI3016 https://www.silabs.com/Support%20Documents/TechnicalDocs/si3016.pdf
TMS320C54x http://www.ti.com/lit/ug/spru307a/spru307a.pdf
CY22050 http://www.cypress.com/?docID=31116
M95512 http://pdf1.alldatasheet.com/datasheet-pdf/view/246004/STMICROELECTRONICS/M95512WDW3G.html
24LC64 http://pdf1.alldatasheet.com/datasheet-pdf/view/74861/MICROCHIP/24LC64.html
TI1020B http://www.ti.com/lit/ds/sles025b/sles025b.pdf
CS8427 http://www.cirrus.com/en/pubs/proDatasheet/CS8427_F5.pdf

Symantec Backup Exec: Bandstatus per PowerShell auslesen

Symantec Backup Exec ist eine in Windows-Umgebungen recht verbreitete Backup-Software. Seit einigen Versionen lassen sich große Teile auch über die “Microsoft-Bash” PowerShell steuern. Für meinen Zweck wollte ich eine Liste aller im angeschlossenen Bandwechseler eingelegten Bänder und deren Status, so kann ich feststellen welche entnommen werden sollen. Im ersten Schritt muss das PowerShell-Modul geladen werden:

Nun wird die Liste der Bännder im Wechsler ausgelesen – hier lässt sich feststellen welches Band in welchem Slot des Wechslers verfügbar ist:

Zuletzt werden die zugehörigen Banddaten wie z.B. die Dauer des Software-Schreibschutzes gelesen:

Die Daten werden in meinem Fall am Ende einer externen Schnittstelle übergeben, welche die Bandstati sortiert und entsprechende Warnmeldungen zur Entnahme generieren kann.

FTP-Uploads per Shell-Script

Ab und an komme auch ich nicht drumrum mit Zielen zu arbeiten, welche keine SSH/SFTP-Verbindung zulassen, sondern nur per FTP(S) erreichbar sind. Grade beim Automatisieren über Shell-Scripte ist das reichlich unschön. Ein praktischer Client ist in diesem Fall das Urgestein ncftp. Mit dessen Tools lässt sich z.B. schnell ein ein entferntes Verzeichnis löschen und durch die lokale Kopie ersetzen:

Windows Shutdown per Linux

Ab und an möchte man entfernte Rechner mal runterfahren. Mit Linux-Zielen ist das per ssh üblicherweise kein Problem, möchte man jedoch von einem Linux-PC den Shutdown-Befehl an einen Windows-Rechner geben muss man schon einmal suchen. Abhilfe schafft wie üblich Samba, welches den “net”-Befehl mitbringt. Ein Shutdown sieht dann wie folgt aus:

Warning: Nerd inside