Archiv der Kategorie: PC-Kram

Meine Lieblingsbeschäftigung :)

BitBasics IT – 0x06 – Programme und PCs

Bisher haben wir alle Aktionen per Hand ausgelöst – im Rechner laufen diese Dings jedoch automatisch ab. Hierzu wird ein so genanntes Programm verwendet, eine Sammlung von Befehlen, welche nacheinander ausgeführt werden. Hier schauen wir in vereinfachter Form den Ablauf eines solchen Programms an.

Korrekturen und Ergänzungen

  • 07:00 Bit natürlich, nicht Byte
  • 14:35 0b…, nicht 0x…

Links zum Thema

s

Serie

Vorherige Folge: BitBasics IT – 0x05 – Speicher mit Latche

Credits

BitBastics // BitBastelei
IT-Grundlagen
Florian “adlerweb” Knodt · http://biba.adlerweb.info/ · CC-BY

Intro-Musik (verändert): Take a Chance Kevin MacLeod (incompetech.com) · Licensed under
Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/

Die-Fotografie: Pauli Rautakorpi · CC BY 3.0 (http://creativecommons.org/licenses/by/3.0)
via https://commons.wikimedia.org/wiki/File:Intel_Pentium_P54C_die.jpg

[ICStation.com] BitBastelei #261 – GPS-Tracker mit Neo-6/7-Module und ESP8266

In der letzten Woche haben wir uns angesehen, wie Satellitennavigationssysteme wie GPS funktionieren, nun wollen wir diese auch in der Praxis nutzen. Da die Berechnungen komplex sind ist es auch hier eine gute Idee spezialisierte ICs zu verwenden, welche eine einfache Schnittstelle für Mikrocontroller bereitstellen. ICStation.com bietet hierzu ein Modul auf Basis des mächtigen U-Blox Neo M6/M7 an, welches über UART angesprochen werden kann. Schauen wir mal auf das Modul, welche Optionen die Konfigurationssoftware bietet, den Aufbau des NMEA-Protokolls und bauen am Ende einen GPS-Trakcer auf Basis des ESP8266.

Links

Code

Inhalt

  • 00:35 Das Modul
  • 09:07 Das NMEA-Protokoll
  • 13:33 Test & Konfiguration per U-Center
  • 18:02 GPS mit ESP8266 und Arduino
  • 19:05 Test mit SoftwareSerial
  • 20:47 GPS/WiFi-Tracking mit OwnTracks

Hinweise:

Das GPS-Modul wurde mir von ICStation.com für dieses Video kostenfrei zur Verfügung gestellt.

Postfix: Alle ausgenenden Mails mit einer Absenderadresse

Standardmäßig versendet Postfix die Mails wie sie ankommen, also z.B. mit dem jeweiligen Nutzernamen als Absendeadresse. Nutzt man jedoch einen Smarthost, lässt ausgehende Mails also z.B. über den Server des Providers abwickeln, ist dies häufig nicht erlaubt, einzig die eigene E-Mail wird akzeptiert.

Mit diesen Schritten kann man Postfix anweisen alle ausgehenden Mails so umzuschreiben, dass die vorgegebene E-Mail-Adresse als Absender genutzt wird. Da so auch nicht mehr auf den ersten Blick ersichtlich ist wer die Mail versendet hat, eignen sich diese Schritte nur für Systeme, auf denen ausschließlich vertrauenswürdige Personen Zugang gewährt wurde. Weiterhin gehe ich davon aus, dass Postfix bereits funktionsfähig konfiguriert wurde und für den Versand per Smarthost eine Authentifizierung notwendig ist.

Fangen wir damit an das Passwort zu hinterlegen. Hierzu legen wir eine neue Datei /etc/postfix/relay_password an und tragen Benutzername und Passwort ein.

Ggf. sollte die Datei über entsprechende Dateirechte vor neugierigen Blicken geschützt werden. Da Postfix üblicherweise aus geschwindigkeitsgründen Datenbankdateien nutzt müssen wir unsere Textdatei noch entsprechend umwandeln:

Nun bereiten wir noch eine Absenderersetzung vor. Die Datei sender_canonical biegt mWn den internen Absender um, welcher z.B. im Envelope verwendet wird, header_check kümmert sich um das FROM:-Feld. Je nach Provider kann es ausreichend sein nur eine der Varianten zu verwenden, beachtet jedoch, dass solche Mails gerne von SPAM-Filtern aussortiert werden.

Hier sind die Dateien als regexp deklariert und können ohne Mapping genutzt werden.

Zuletzt machen wir diese Dateien noch in der Postfix-Konfiguration bekannt:

In der ersten Zeile wird der eigentliche Server des Providers als ausgehender Server definiert – mit dieser Einstellung wird Postfix nicht mehr selbst versuchen Mails zuzustellen sondern alles an diesen weiterleiten. Im nächsten Block wird angegeben, dass für den ausgehenden Server eine Authentifizierung notwendig ist und wo die Passwörter zu finden sind. In den letzten Zeilen definieren wir unsere Filter, welche die Ersetzung vornehmen.

Nach dem nächsten Reload des MTA sollten nun alle E-Mails mit der gesetzten Absenderadresse über den angegebenen Smarthost versendet werden.

Firefox statt IE im Unternehmen – Deployment, Konfiguration und Co

In vielen Firmen gilt noch immer Microsoft Edge bzw. der Internet Explorer als Standardbrowser für Inter- und Intranet. Einer der wichtigsten Gründe ist die Verwaltbarkeit: Updates werden über die Systemfunktionen automatisch installiert, Eintellungen lassen sich komfortabel über Gruppenrichtlinien zuweisen. Was viele IT-Abteilungen nicht auf dem Schirm haben ist, dass es auch mit alternativen Browsern nicht vollkommen unmöglich ist eine solch zentrale Konfiguration einzurichten. Hier möchte ich ein paar Kniffe für den Einsatz von Firefox in größeren Installationen geben.

Deployment und Updates

Fangen wir kurz mit Deployment und Updates an: In vielen Firmen laufen Updates des IE über WSUS. Dieser ermöglicht es Aktualisierungen erst in einem Laborumfeld auf unerwünschte Nebenwirkungen zu testen und im Anschluss an die Clients zu verteilen. Prinzipitell gut, jedoch ist WSUS hauptsächlich für Microsoft-Produkte ausgelegt, wird vom Hersteller etwas stiefmütterlich behandelt und ist – zumindest nach meiner Erfahrung – nur mäßig zuverlässig. Nicht zuletzt weil nahezu kein Unternehmen ohne Drittanbietersoftware auskommt, wird in vielen Firmen ein weiteres Deployment-System wie z.B. SCCM oder das kostenfreie OPSI zum Einsatz. Über diese kann man auch Firefox recht schnell ausrollen. Hierzu benötigt man statt dem kleinen Stub-Installer, welcher für Windows üblicherweise ausgeliefert wird, den Offline-Installer, welcher z.B. auf der Sprachübersicht zu finden ist. Wer neue Funktionen gegen seltenere Wartung tauschen möchte kann alternativ auf den Extended Service Release” (ESR) zurückgreifen. Hierbei handelt es sich um eine spezielle Version von Firefox, welche über einen längeren Zeitraum mit Sicherheitsaktualisierungen versorgt wird. Im Gegensatz zur Desktop-Version werden bei diesen Updates – soweit mögich – keine Funktionen verändert. Der Befehl für eine Silent-Installation lautet

Achtung: Beim Download haben 32- und 64-Bit-Varianten aktuell, trotz unterschiedlichem Inhalt, den selben Dateinamen. Über den selben Weg kann man neuere Versionen zur Aktualisierung installieren. Möchte man die Software später wieder löschen findet sich im Installationsverzeichnis eine passende Datei

Konfiguration

Bleibt die Konfiguration. Hier lässt sich ein Überbleibsel aus der Netscape-Zeit nutzen, welche die Ausführung von Scripten beim Start des Browsers erlaubt. Im ersten Schitt legt man eine neue Datei im Ordner “%PROGRAMFILES%\Mozilla Firefox\defaults\pref\” an. Der Name kann frei gewählt werden, jedoch erfolgt die Ausführung alphabetisch. Als inoffizielle Konvention hat sich “autoconfig.js” durchgesetzt. Erste Falle: Die erste Zeile. Diese wird automatisch übersprungen, dort hinterlegte Befehle also ignoriert. Als Workarround sollte man in dieser folglich besser einen Kommentar unterbringen. Zweite Falle: Zwar können in dieser Datei bereits Konfigurationen gesetzt werden, jedoch wird sie während des Browserstarts zu einem Zeitpunkt geladen, an dem noch nicht alle Subsysteme verfügbar sind. Um dies zu umgehen wird stattdessen ein Verweis auf eine weitere Konfiguration hinterlegt, welche am Ende des Starts geladen wird. In diesem Beispiel nenne ich diese “mycompany.js“. Standardmäßig sind diese nachgeladenen Dateien mir ROT13 (sic!) codiert um neugierige Blicke und Änderungen von Nutzerseite zu erschweren. Da Ersteres ohnehin auch über die Browserfunktionen möglich ist und sich Schreibzugriffe über die Berechtigungen des Dateisystems effektiver verhindern lassen, schalte ich diese Funktion aus, so sind Änderungen einfacher.

Nun geht es daran die eigentliche Konfiguration zu erstellen. Die zuvor referenzierte “mycompany.js” wird im Programmverzeichnis, also “%PROGRAMFILES%\Mozilla Firefox\“, erwartet. Für das Setzen von Konfigurationen stehen uns verschiedene Befehle zur Verfügung – hier die wichtigsten:

Befehle

pref()

So gesetzte Einstellungen sind identisch zu jenen, die der Nutzer in der GUI oder about:config vornimmt. Die Änderungen werden als “vom Benutzer eingestellt” angezeigt. Benutzer können diese weiterhin ändern, da das Konfigurationsscript jedoch bei jedem Browserstart läuft werden die Änderungen nach dem Neustart des Browsers wider auf den vorgegebenen Wert zurückgesetzt.

defaultPref()

Hiermit wird die Standardeinstellung geändert. Der Nutzer hat auch hier die Möglichkeit diese selbstständig zu ändern, jedoch sind Benutzeranpassungen bei dieser Variante persistent und werden bei einem Neustart nicht automatisch zurückgesetzt.

lockPref()

Hiermit wird eine Einstellung gesetzt und gleichzeitig gesperrt. Sie kann im Anschluss nicht mehr vom Nutzer geändert werden, entsprechende Konfigurationsfelder werden ausgegraut.

unlockPref()

Hebt die Sperre wieder auf. Interessant wenn man z.B. mit einer globalen Konfiguration arbeitet, bestimmten Benutzergruppen jedoch Funktionen über eine weitere Konfigurationsdatei wieder freigeben möchte.

getPref()

Liest die Konfiguration – z.B. um ein “identisch zu X” umzusetzen.

clearPref()

Löscht die Konfiguration

getenv()

Liest eine Umgebungsvariable

Wie am Namen zu erkennen handelt es sich um Javascript, man kann also auch eigene Logik einbringen. Auch hier nutze ich die erste Zeile zur Sicherheit als Kommentar. Die Bezeichnungen der Konfigurationsfelder kann man im Browser zu großen Teilen in about:config finden.

Beispiele

Automatische Updates ausschalten

Da Updates, wie oben erwähnt, über das zentrale Deployment laufen sollen, wird der Auto-Updater des Browsers ausgeschaltet. So wird der Nutzer nicht mit entsprechenden Aufforderungen konfrontiert und Änderungen können vor einem breiten Rollout in einer überwachten Umgebung auf Kompatibilität mit den Unternehmensanforderungen geprüft werden. Achtung: Einige der Updater-Einstellungen lassen sich nur mit lockPref() setzen.

Branding und Telemetrie

Je nach Firmen-Policy kann ein Branding oder der Upload von Telemetrieinformationen an Mozilla unerwünscht sein.

Startseite

Wenn ein Intranet-Portal o.Ä. automatisch geladen werden soll kann dies als Startseite hinterlegt werden

Zertifikate

SSL-Zertifikate sind bei Drittbrowsern immer eine Qual. Statt den Systemzertifikatspeicher zu verwenden bringen die meisten Browser einen eigenen Zertifikatspeicher mit. Firmen, welche interne CAs verwenden müssen hier eine separate Konfiguration erzeugen und können sich nicht auf die Verteilung per GPO o.Ä. verlassen. Bei Firefox gibt es hier die Möglichkeit über certutil Zertifikate per Script zu importieren.
Bei neueren Installationen kann man Firefox jedoch instruieren auch Zertifikate zu akzeptieren, welche im Windows-Zertifikatspeicher hinterlegt sind.

Proxy-Server

Verwendet die Firma einen Proxyserver, welcher nicht über den Router als “transparenter Proxy” betrieben wird, kann dieser ebenfalls hier hinterlegt werden.

Lesezeichen

Das Erstellen von Lesezeichen ist etwas komplizierter, da man hier mit Datenbank und GUI interagieren muss, welche erst am Ende des Browserstarts zur Verfügung stehen. Um sicherzugehen, dass hier alle Module verfügbar sind, wird das Erstellen in eine eigene Funktion ausgelagert und mit einem Hook des Browsers verknüpft. Das Erstellen erfolgt über den nsINavBookmarksService. Dieser ermöglicht auch das Verwalten von Ordnern oder das Löschen von Elementen.

Alternativen

Wer weniger administriert und lieber herumklickt eine GUI der Textkonfiguration vorzieht kann einen Blick auf CCK2 werfen, welches die Konfiguration grafisch aufbereitet.

[ICStation.com] BitBastelei #269 – Audio-Frequenzweiche: Soundsystem-Recycling

Es ist Laubbläserzeit – wohl dem, der Soundtechnisch dagegen halten kann. Leider sind meine Eigenbau-Mediacenter da etwas dünn aufgestellt, allerdings liegt noch ein altes, analoges 5.1-System in der Kiste. Könnte man aus dem Stereo-Ausgang des Raspberry Pi nur ein Bass-Signal für den Subwoofer erzeugen. Kann man natürlich, und eine dafür notwendige Frequenzweiche bietet ICStation.com als Bausatz an.

Links

Inhalt

00:00 Warum das Ganze?
02:26 Der Bausatz
05:36 Die Schaltung
07:10 Simulation
09:45 Erste Messung
11:46 Das fertige Modul
12:00 Blick in das Audiosystem
15:05 Frequenzweiche an der Box
16:38 Ozi-Auswertung mit Last

Hinweise

Der Bausatz wurde mir von ICStation.com für dieses Video kostenfrei zur Verfügung gestellt.

VMWare RDM: ESXi-Boot wird minutenlang verzögert

Schlecht. Ein ESXi-Host sollte zwecks Update “mal schnell” neu gestartet werden, doch nun sind mehr als 30 Minuten vergangen und es gibt noch immer kein Lebenszeichen. Selbst für Server etwas ungewöhnlich und lange genug um den VMWare-Updater in einen Timeout laufen zu lassen. Nach einiger Zeit war das System zwar wieder korrekt gebootet und zeigte keine weiteren Auffälligkeiten, eine solche Wartezeit wäre bei Störungen jedoch sehr hinderlich, also gehen wir mal auf Quellensuche.

Im Log finden sich mehrere Einträge, welche durch die Zeitstempel massive Wartezeiten erkennen lassen:

Das Ganze wiederholt sich dann mehrfach. Also ein SCSI-Timeout? Der Host ist per FibreChannel an diverse Storage-Systeme angebunden, sollte jedoch auch nur die für ihn relevanten LUNs sehen. Zumal nach dem langem boot auch alle Datastores verfügbar und VMs ohne Fehler online waren.

Nach einigem Suchen dann die Erkenntnis: Die angekreideten LUNs gehören zu einem Windows-Cluster und sind als RDM vorgesehen. ESXi versucht nun beim Booten diese LUNs zu scannen, was jedoch nicht gelingt da der Cluster auf einem anderen Host aktiv und die Partition somit dauerhaft gesperrt ist. Zur Abhilfe muss man diesen Scan beim Boot explizit für die betroffenen LUNs auf jedem Host deaktivieren:

https://kb.vmware.com/kb/1016106

VMWare vSphere-Client per SSH-Tunnel

vmlistUgh – eine VM hängt und ich habe kein VPN ins zugehörige Netz. Aber jetzt extra hinfahren? Auch unschön. Glücklicherweise gibt es noch einen SSH-Zugang, den ich hier nutzen kann. Also schnell Tunneln – doch welche Ports? Nunja, nehmen wir für den “alten” vSphere-Client folgende:

  • 443
  • 992
  • 993

Wer jedoch versucht mit 127.0.0.1 oder localhost zu verbinden wird auf Probleme stoßen – bei mir lief der Client auf diesen IPs keinen Connect zu. Ein kurzer Griff in die IPv6-Kiste mit dem guten, alten [::1] half und ließ die Verbindung zu.

Linux: Optisches Laufwerk RAW über Netzwerk einbinden

(Hinweis: Der Artikel lag schon etwas rum – möglicherweise sind die verwendeten Tools nicht mehr aktuell)

Hmmm – ungünstig. Das einzige optische Laufwerk steckt in einem Linux-Server, ich möchte die Discs jedoch auf einem anderen Gerät verwenden. Üblicherweise reicht hier ein File-Share wie Samba, NFS o.Ä. aus, wenn man jedoch beispielsweise kopiergeschützte DVDs abspielen möchte ist eine solche Freigabe nicht ausreichend. Glücklicherweise können wir hier einen alten Bekannten bemühen: iSCSI. Dies hatten wie bereits für Festplatten besprochen, kann aber auch für optische Laufwerke genutzt werden.

Server / Target

Nach dem Aufruf von targetcli sollten wir die altbekannte Textkonsole erhalten, welche auf der Root (/) der Konfiguration startet. Im ersten Schritt registrieren wir das physikalische Laufwerk /dev/sr0 als Backstore und aktivieren es für iSCSI. Sofern nicht bereits vorhanden wird automatisch eine TPG erzeugt.

Nun müssen wir noch eine LUN erstellen um Clients den Zugriff zum Gerät zu ermöglichen. Diese Konfiguration findet im Kontext der TPG statt, die nötige ID wurde ja weiter oben angezeigt. Da nur ein Backstore verfügbar ist wird dieser automatisch ausgewählt. Da es sich um ein Testnetz handelt verzichte ich auf eine Absicherung und alle alle Clients zu – bei CD-Laufwerken ein überschaubares Risiko.

Zuletzt wird die Konfiguration gespeichert, so ist sie z.B. auch nach einem Neustart noch vorhanden

Client / Initiator

Auf der Clientseite benötigen wir ebenfalls eine Userspace-Software. Ich nutze zur Konfiguration iscsiadm aus dem Paket open-iscsi. Hier wird erst über Discover geprüft welche LUNs auf der TPG/Ziel-IP verfügbar sind. Über Login werden diese dann verbunden.

Das Ergebnis ist ein zusätzliches Blockdevice, welches wie ein Lokales angesteuert werden kann.