Chat Server geöffnet – ich will dass Ihr den nutzt!!!

XMPP Chat Standard Logo

Einleitung Chat-Nutzung

Ich habe meinen Prosody-Server für die öffentliche Chat Registrierung freigegeben. Er wird nicht kommerziell betrieben. MUC, MAM und OMEMO sind möglich bzw. werden verwendet. Gebräuchliche Software ist Conversations und Gajim. Einen Webchat könnt Ihr auch gleich verwenden. Viel Spass bei der Nutzung.

I have shared my prosody server for public chat registration. It is not operated commercially. MUC, MAM and OMEMO are possible or are used. Common software is Conversations and Gajim. You can also use a Webchat. Have fun with the use.

Links

Vor- und Nachteile Conversations/Whatsapp-Chat

Pro

  • Keine Datenabgriffe
  • Verschlüsselung Ende zu Ende mit Omemo auch in Gruppen
  • viele kleine Server die alle miteinander verbunden sind
  • Keine zentrale Instanz, die Millarden Menschen überwachen kann
  • Clienten für alle gängigen Systeme (Android, Windows, Linux, IOS)
  • Offener kontrollierbarer Code
  • Standardisiert

Contra

  • Alle lieben whatsapp und wollen nicht mit einer beta-software arbeiten!
  • Alle Freunde nutzen whatsapp
  • Datenabgriff ist egal – was habe ich schon zu verbergen
  • Zentrale Überwachung der Metadaten

Pros and Cons Conversations / Whatsapp

Pro

     No data taps
     Encryption End to end with Omemo also in groups
     many small servers that are all connected to each other
     No central authority that can monitor millions of people
     Clients for all popular systems (Android, Windows, Linux, IOS)
     Open, controllable code
     Standardized

Contra

     All love whatsapp and do not want to work with a beta software!
     All friends use whatsapp
     Data taps does not matter – what I already have to hide
     Central monitoring of the metadata

 

Feinstaub-Messung in Limbach-Oberfrohna

SDS011 Feinstaub-Sensor

Einleitung

Da ich Sensoren gern baue, habe einen Feinstaub-Sensor zusammengebaut und konfiguriert. Auf http://luftdaten.info/ gibt es die Anleitung für einen verbreitet genutztes Messmodul mit angeschlossener Webdarstellung.

Kosten des Feinstaub-Sensors

Die Kosten liegen bei etwas über 40 Euro. Teuerstes Teil ist der Sensor (SDS011), welcher die Partikelanzahl über einen Laser misst.

Funktion

Die Daten des Feinstaub-Sensors werden dann mit der Temperatur und Feuchte an einen NodeMCU geschickt und per Wlan über das eigene Netzwerk zur Webseite geschickt und dann dort angezeigt.

Links

Hier der Link für die Daten meines Sensors für Limbach-Obefrohna. Eine Karte mit den weltweiten Messwerten des Sensors kann man mit folgendem Link öffnen.

 

Insekten-Fotos Limbach-Oberfrohna mit der Sony Alpha 77II und dem Tamron 90

Libelle

Einleitung

Heute habe ich meine Kamera mit dem neuen Objektiv zur Makrofotografie getestet. Jetzt bin ich begeistert. Endlich gelingen mir Fotos so, wie ich es mir vorstelle. Jetzt bin ich erstaunt wie nah mich die Tierchen heran lassen und still bleiben. Selbst mit dem Wind hatte ich keine Probleme. So konnte ich alle Bilder aus der Hand also ohne Stativ fotografieren. Besonders habe ich Intresse an extremer Schärfe. Leider ist das aber nicht ganz einfach zur erreichen.

Meine Ausrüstung für Makro-Fotos

Ich benutze die Sony Alpha A77 II mit einem Tamron 90 Makroobjektiv. Zusätzlich werde ich  mich demnächst noch mit automatischen Zwischenringen, Stativ, Reflektor und Fernauslöser versuchen. Auch mal schauen, was ich da noch heraus zaubern kann. Diese Ergebnisse werde ich natürlich hier veröffentlichen.

Andere coole Fotos sind hier zu finden. Allerding finde ich die Regelungen dort nicht sehr anziehend. Wer gern Fotos hier veröffenlichen möchte gibt mir einfach eine Info. Ich melde mich umgehend.

Introduction

Today I tested my camera with the new lens for macro photography. I am enthusiastic At last, I am able to take photos as I imagine. I am amazed how close the animals let me stay and still stay. Even with the wind I had no problems. All pictures had also photographed from the hand without a tripod.


My equipment for macro photos

I use the Sony Alpha A77 II with a Tamron 90 macro lens. I will try again with automatic intermediate rings, tripod, reflector and remote release. Let’s see, I’m there can still conjure out. The results I will publish here, of course.

Linux-NAServer Erfahrungen mit OSS

open mdeia vault nas

Da mein altes NAS keinen Support mehr vom Hersteller bekommt, musste ich mich nach einer neuen Lösung umsehen. Anforderung ist OpenSource, ZFS, Backupmmöglichkeiten, Verschlüsselung und geringer Energieverbrauch. ZFS ist angeblich leistungsfähiger als BTRFS. Meine Erfahrungen damit könnt ihr hier nachlesen

Hardware

Zum Einsatz kommt die Empfehlung von http://www.technikaffe.de/anleitung-178-eigenbau_nas_anleitungen_fuer_4_bis_16_festplatten_auf_einen_blick mit dem NAS 3.0 Apollo Lake mit 4 x SATA

Software

Nas4Free:

Die Testinstallation viel trotz der ansprechenden Oberfläche letztendlich wegen Unübersichtlichkeit durch.

Freenas:

Ich testete die beiden aktuellen Versionen 9 und 11. Version 9 erzeugte grundsätzlich eine unauffällige Last wohin gegen die 11er eine Grundlast von über 1 anzeigte. Ich testete dann weiter mit der 9er Version. Leider habe ich nichts über die Supportzeit gefunden. Bei diesem System funktionierte leider nicht richtig die  Energiesparmodi der Platten. ZFS wird standardmäßig mit Verschlüsselungsmöglichkeit vorgesehen. Ein Backup kann man per Remote oder auch lokal mit Snapshots erstellen. Leider ist keine Mini-DLNA-Server einfach installierbar.

Openmediavault 3

Hier funktioniert fast alles ohne Probleme: Energiemanagement, ZFS, Backup über Rsnapshot. Einziges Manko ist, das die Verschlüsselung für ZFS nicht korrekt arbeitet, da LUKS manuell bei jedem Neustart entsperrt werden muss und dadurch alle folgenden Stufen (Freigaben, SAMBA) Probleme haben. Das lässt sich allerdings manuell heilen. Energieverbrauch liegt bei abgeschalteten Platten bei 12 Watt. In Betrieb sind es dann so zwischen 20 und kurzzeitig 30 Watt. Ich habe Hoffnung, dass die Verschlüsselung bald ordentlich implementiert wird.

ENGLISH

Because my old NAS gets no more support of the manufacturer, I had to look around after a new solution. Requirement is OpenSource, ZFS, Backupmmöglichkeiten, encoding and low energy consumption. ZFS is supposedly more efficient than BTRFS. With it you can read up my experiences here

Hardware

For the application comes the recommendation from http://www.technikaffe.de/anleitung-178-eigenbau_nas_anleitungen_fuer_4_bis_16_festplatten_auf_einen_blick with the NAS 3.0 Apollo Lake with 4 x SATA

Software

Nas4Free:

The test installation a lot in spite of the attractive surface at last because of vagueness by.

Freenas:

I tested both current versions 9th and 11th version 9 an unobtrusive load where against the 11th generated basically a basic load from more than 1 registered. Then I further tested with the 9th version. Unfortunately, I have found nothing for the support time. Unfortunately, with this system did not function properly the energy savings modes of the records. ZFS is planned by default with encoding possibility. One can provide a backup by Remote or also locally with Snapshots. Unfortunately, it is simply installable no Mini DLNA servers.

Openmediavault 3

Here almost everything functions without problems: Energy management, ZFS, backup about Rsnapshot. The only deficiency is which does not work the encoding for ZFS correctly, because of HATCH must be unlocked by hand with every restart and thereby all following steps (releases, SAMBA) problems have. However, this can be cured by hand. Energy consumption lies with switched off records with 12 watts. Then in company these are thus between 20 and for a short time 30 watts. I have hope that the encoding is soon implemented substantially.

XMPP Server Ursache für fehlende Nachrichten?

server

Ausgangssituation der vorhanden XMPP-Chat-Konfiguration

Ich betreibe einen XMPP-Chat-Server (Prosody). Als Clienten verwende ich Gajim und Conversations. Zur Verschlüsselung des Chats kommt OMEMO zum Einsatz. Außerdem verwende ich die Module mod_mam, mod_muc_mam und die Speicherung der Nachrichten in eine MYSQL/MariaDB-Datenbank.

Probleme beim Chat

Ständig hatte ich einen unterschiedlichen Datenstand bei den Nachrichten auf den unterschiedlichen Clients, obwohl diese immer synchron sein müssten. Häufig sind Clients nicht verbunden, wie Gajim auf dem Desktop. Die Synchronisation nach Einschalten des Rechner funktioniert, aber es gab immer fehlende Nachrichten. Durch die XMPP Standards dürfte so etwas nicht passieren. Als Ursache habe ich viele Dinge in Betracht gezogen.

Ursachen für fehlende/unsynchrone Nachrichten

Letztendlich hat sich heraus gestellt, dass als Ursache zu viele instabile Module und ständige Serverneustarts zu den Unsynchronitäten geführt haben. Aufgefallen ist mir zufällig, dass die Schlüssel meiner Clienten bei Serverneustart u. U. nicht wieder aktiviert wurden. Dadurch werden dann Nachrichten nicht mehr angezeigt, weil die Schlüssel inaktiv sind und es kommt zum Nachrichtenverlust beim Chat.

Lösung

Ich habe alle nicht notwendigen Module deaktiviert. Quasi sind nur noch die in Conversations angezeigten XMPP-Server-XEPs aktiv. Außerdem habe ich am Server Änderungen bei der Update-Politik vorgenommen. So starte ich meine Server nicht mehr neu. Dies kann man mit der autom. Installation zum Einen bewerkstelligen. Die notwendigen Neustarts des Systems bei Kernelaktualisierungen lassen sich dann mit dem Verfahren Kernel Live Patching (KLP) unter Ubuntu/Linux zum Anderen verhindern. Somit ist ein Hochverfügbarkeitsbetrieb mit einfachen Mitteln z. B. auch im Heim möglich. Seit dem habe ich eine sehr zuverlässige Funktion meines Prosody-Servers, mit dem alle Beteiligten viel Freude haben.

Weitere Lösung für die XMPP-Standards

Gut wäre infolge dessen, wenn Prosody die Aktivierung der Schlüssel nach Neustart erhalten könnte. Leider ist OMEMO nur Client-seitig implementiert. Wahrscheinlich müssen die XMPP-Clients die Aktivierung der OMEMO-Keys sichern. Somit sollte dann der Betrieb auch bei einem Neustart abgefangen werden (können).

Initial situation of the existing XMPP chat configuration

I am running an XMPP chat server (prosody). As clients I use Gajim and Conversations. OMEMO is used to encrypt the chat. I also use modules mod_mam, mod_muc_mam and storing the messages in a MYSQL / MariaDB database.

Chat problems

I always had a different dataset in the messages on the different clients, although these should always be synchronous. Frequently, clients are not connected, such as Gajim on the desktop. Synchronization after power on works, but there was always missing messages. The XMPP standards should not happen. As a cause I have considered many things.


Causes for missing / unsynchronous messages

In the end, it turned out that too many unstable modules and constant server restartes led to the unsynchronization. It is a coincidence that the keys of my clients might not have been activated again during server reboot. This means that messages are no longer displayed because the keys are inactive and there is a loss of messages during the chat.

Solution

I have disabled all unnecessary modules. Quasi, only the XMPP server XEPs displayed in conversations are active. I also made changes to the update policy on the server. So I do not restart my servers. This can be done with the autom. Installation on the one hand. The necessary reboots of the system during kernel updates can then be prevented with the procedure Kernel Live Patching (KLP) under Ubuntu / Linux on the other. Thus, a high-availability operation is possible with simple means, eg also in the home. Since then I have a very reliable function of my prosody server, with which all involved have a lot of fun.

Another solution for the XMPP standards

Good would be if Prosody could get the key activation after reboot. Unfortunately, OMEMO is only implemented on the client side. It is likely that the XMPP clients must back up the activation of the OMEMO keys. Thus, the operation should be intercepted (also) during a restart.