In diesem Video zeige ich das Grundgerüst einer wxWidgets-Anwendung. Wir implementieren unsere eigene wxApp und schreiben die main-Funktion einmal via wx-Makro und einmal händisch.
Viel Spaß beim Implementieren.
Kategorie: YouTube
Bald neue Videos
Viele haben mir geschrieben, dass ich doch weitere Videos bzw. Tutorials machen soll. Das freut mich sehr.
Zur Zeit nimmt mich die neue Arbeitstelle und meine Familie gut ein, ich habe aber schon die nächsten Videos geplant (Themen: wxWidgets, Qt und auch FreeBSD) und freue mich, sie bald machen und veröffentlichen zu können. Es dauert allerdings noch ein paar Tage. Aber: Es wird mit den Tutorials weiter gehen.
Wenn ihr Vorschläge für bestimmte Themen habt, gerne her damit.
KooKooK (Update 4): Die Authentifizierung im Einzelnen
Vielleicht interessiert es den ein oder anderen, wie ich die Authentifizierung durchführe. Mich würde unbedingt Eure Meinungen interessieren.
Ziel war es, dass man nicht Benutzername und Kennwort über die Leitung zum Server zur Verifizierung überträgt, da ich das für unsicher halte. Ich habe es erst einmal so gelöst:
- Client verbindet sich zum Server
- TLS-Handshake
- Server sendet Welcome-Message an Client. Die Welcome-Message besteht aus der Versionsnummer des Servers sowie einer UUID, getrennt mit einem Doppelpunkt (1.0.1:8234-234-234-234)
- Der Client trennt die empfangene Versionsnummer von der UUID anhand des Doppelpunkts
- Der Benutzer hat am Client den Benutzernamen und das Kennwort eingegeben
- Das Kennwort wird mit MD5 gehasht
- Benutzername, UUID und gehashtes Kennwort wird als Bytearray zusammengefasst und mit Keccak_512 gehasht
- Daraus entsteht dann das Bytearray, was zum Server geschickt werden soll
- Das gehashte Bytearray mit vorangestelltem Benutzername@ wird zum Server geschickt (ausgedachtes Beispiel: thorsten@ljdf08asdflu0dsa98foklj234ASDF)
- Der Server hat jetzt den unverschlüsselten Benutzernamen, der eindeutig in der Datenbank ist und zieht das Kennwort, fügt auch alles zusammen und hasht dann das Bytearray
- Der Server vergleicht, ob das empfangene Bytearray gleich dem selbst generiertem Bytearray ist. Ja = Der Benutzer ist eingeloggt, Nein = Der Benutzer ist nicht eingeloggt
Anmerkungen: In der Implementierung werden weitere Fehler behandelt und zurückgeliefert. Beispielsweise, ob der Benutzer überhaupt vorhanden ist, ob der Hash gebildet wurde, usw. Was noch fehlt ist, ob der Benutzer auch (in der Datenbank) auf aktiv steht.
Ihr könnt das in folgenden Dateien nachvollziehen:
Mitunter sollte man weitergehen und zum Beispiel auch den Benutzernamen nicht im Klartext senden?
Ich bin wieder in Lohn und Brot – Meine neue Festanstellung und wie es hier weitergeht
Ich bin wieder unter Dach und Fach und freue mich unendlich. Ich habe eine neue Festanstellung gefunden und befinde mich gerade in der Einarbeitung.
Da ich jetzt erstmal, zumindest während der Einarbeitung, in Vollzeit arbeite, habe ich leider keine Zeit mehr für Videos, da ich vollständig mit Job und Familie ausgelastet bin. Damit bleiben die ganzen Serien zuerst einmal stehen.
Wie es da in Zukunft weitergeht, weiß ich noch nicht. Ich danke aber schon einmal bis hierhin und hoffe, den ein oder anderen Blogartikel in den nächsten Wochen schreiben zu können.
KooKooK (Update 3): Umbauten und weitere Informationen
Ich habe mich doch entschieden, einige Umbauten durchzuführen. Zunächst wollte ich den Server eigentlich pro Verbindung mit einem Thread laufen lassen. Das hat direkt, für ein Hobbyprojekt mit wenig Zeit, viele Probleme aufgeworfen.
Von Threads
Vor allem sind die Dateideskriptoren auf unterschiedlichen Betriebssystemen unterschiedlich konfiguriert, aber doch teils sehr limitiert. Ich wollte auf meinem Mac mal eben 500 Verbindungen aufbauen, bei 80 oder so war Schluss. Man kann das Limit zwar höher schrauben, aber man ist natürlich durchaus limitiert.
Dann gab es noch Probleme mit dem Verschieben von Objekten innerhalb von Qt zu Threads. Neue erstellte Objekte liefen nicht im Thread, sondern Hauptthread. Das kann man alles recht problemlos fixen, indem man mit Workerprozessen arbeitet, aber ich wollte da nicht weiter herumbauen (zeitliche Einschränkung), da ich vorwärts kommen wollte. Aber interessant: Ich habe mal 500 Konnektierungen gleichzeitig startet (so gleichzeitig, wie es nur geht). Das hat auf meinem Mac 200ms (etwas darunter) benötigt, um auf 500 Verbindungen ein “Hallo Welt” über das Loopback-Device zu senden. War zwar nur Loopback, aber ich war doch erstaunt, wie schnell es geht, so viele Threads zu öffnen, was zu schicken und wieder zu schließen.
Keine Threads mehr
Dann habe ich einfach mit generellen nonblocking Sockets herumgespielt (im Thread waren sie auch nonblocking!) und festgestellt, dass es von der Geschwindigkeit her für einige hundert Verbindungen ausreichen sollte, zumal man nicht sonderlich viele Informationen senden muss und diese ja auch noch komprimieren kann. Also habe ich alles umgebaut.
Benutzerauthentifizierung
Ich habe das tatsächlich so ähnlich, wie im vorherigen Blogeintrag, implementiert. Letztlich ist es so: Der Client macht eine Authentifizierungsanforderung an den Server. Der Server kennt den Benutzernamen und schickt eine UUID. Dann werden die Benutzerinformationen mit der UUID zusammengefasst und gehasht, zurückgeschickt, der Server macht das selbe und vergleicht beide Ergebnisse. Sind sie gleich, gilt der Benutzer als eingeloggt.
Weiteres
Weiterhin habe ich noch Datenbankabstraktionen implementiert für MySQL, PostgreSQL und SQLite, damit man Benutzer speichern kann. Ein Logging habe ich implementiert und dem Server kann man Signale schicken, um ihn zu beenden oder sonst was zu tun. Es gibt einen Testclient unter resources/sslclient, mit dem man mit dem Server ein wenig spielen kann.
KooKooK (Update 2): Überlegungen zur Benutzerauthentifizierung
Benutzer sollen sich am System anmelden können. Ich dachte mir, die speichern wir einfach in einer relationalen Datenbank, da Qt dafür schon Bibliotheken mitbringen (MySQL, PostgreSQL, SQLite). Welches DBMS wir nehmen, weiß ich noch nicht.
Dennoch muss die Benutzerauthentifizierung ja implementiert werden. Naiv könnte man das so machen:
- Client schickt Benutzernamen und Kennwort an Server
- Server prüft per Datenbank Benutzernamen und Kennwort
- Server gibt OK oder NK zurück
Jetzt will ich aber, wenn auch verschlüsselt, keinen Benutzernamen und kein Kennwort einfach durch die Gegend schicken. Meine Idee war folgende:
- Auf dem Server sind Benutzername und Kennwort in der Datenbank hinterlegt, wobei das Kennwort gehasht ist
- Client meldet sich bei Server, dass er sich authentifizieren will
- Server schickt einen einfache String (z.B. eine UUID) an den Client
- Der Client hasht sein Kennwort in der selben Weise, wie der Server, und fügt im String Benutzernamen und Kennwort zusammen (thorstenAdsfjlksudSDFAalsj)
- Mit dem zusammengefügten Benutzernamen und gehashten Kennwort verschlüsseln wir den vom Server geschickten String (z.B. die UUID)
- Den verschlüsselten String schicken wir an den Server zurück
- Der Server prüft den verschlüsselten String mit seinem eigenen (er macht das selbe online)
- Der Server gibt OK oder NK zurück
Was haltet ihr davon? Eine gute Idee? Hat jemand eine bessere?
KooKooK (Update 1): Ein paar Implementierungen ohne Video
Ich habe überlegt: ich kann leider nicht alles zu dem Projekt aufnehmen. Ich habe noch ein paar Erweiterungen gemacht. Was alles, seht ihr im GitHub-Projekt.
Hier eine Liste:
- Über die Server.ini kann man den Server jetzt teils konfigurieren
- Einfaches Logging wurde eingebaut
- Threads können beendet werden
- Kompilierungsscript wurde erweitert
- Unix-Signal-Handling wurde implementiert (TERM und HUP)
Schreibt mir gerne bei Fragen und Anregungen.
KooKooK 0017: Beginnen wir mit Sockets und Threads
Stürzen wir uns nach fast einem Jahr der Pause in den Spaß. Beginnen wir mit der Serverkomponente und dort mit Sockets und Threads. Los geht’s.
Es ist noch viel zu tun. Packen wir es an. Wer Lust hat, mitzuhelfen, ist gerne eingeladen.
FreeBSD-Grundkurs 031: Virtualisierung mit bhyve und vm-bhyve
Wer mit FreeBSD Virtualisierung durchführen möchte, hat mehrere Möglichkeiten: Jails, VirtualBox und QEmu. Mit bhyve bietet FreeBSD aber ein eigenes Virtualisierungsprogramm an, welches sehr einfach mit vm-byhve zu benutzen ist. Wie das geht, zeigt dieses Video.
In diesem Beispiel zeige ich, wie man vm-byhve und grub2-bhyve installiert, konfiguriert und ein Debian darin installiert.
Hier einige Kommandos:
# SSH-Verbindung, falls nötig, zum Host aufbauen und darauf achten, dass Escape-Sequenzen von SSH ignoriert werden, da diese sonst nicht an die Console von bhyve geschickt werden können (cu)
ssh -e none $servername
# Installation der benötigten Pakete
pkg install vm-bhyve grub2-bhyve
# ZFS-Dataset erstellen
zfs create storage/bhyve
# /etc/rc.conf bearbeiten
sysrc vm_enable="YES"
sysrc vm_dir="zfs:server/bhyve"
# vm-byhve initialisieren
vm init
# Template kopieren und bearbeiten
cp /usr/local/share/examples/vm-bhyve/debian.conf /server/bhyve/.templates/mydebian.conf
# Switch erstellen und Netzwerk-Interface hinzufügen
vm switch create public
vm switch add public bge0
# ISO-Datei für die Installation von Debian herunterladen
vm iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso
# Virtuelle Maschine erstellen, Festplattengröße auf 16GB setzen
vm create -t mydebian -s 16g mydebian
# Virtuelle Maschine installieren
vm install -f mydebian debian-11.5.0-amd64-netinst.iso
# Virtuelle Maschinen auflisten (inkl. Status)
vm list
# Vorhandene ISO-Dateien ansehen
vm iso
# Automatischer Start der virtuellen Maschinen
vm_list="vm1 vm2"
vm_delay="5"