blog.mhus.de

 mhus now supports bearer tokens for authentication. I used the project jjwt to implement the tokens and added dependencies of the current version 0.11.2. The token is implemented to be used with apache shiro. A new service JwtProvider implements creation and reading of the tokens. The keys if not exists will be created and stored in the keychain. Private and public keys in separate key sources. In this way the public keys can be published to other nodes. A new interface BearerRealm must be used to mark realms with Bearer support. Using the interface a token can be created from the realm implementation. You should use the AccessUtil to create tokens. The authentication is already implemented in rest and micro calls. Via rest a node '/jwt_token' can be used to create a token - expires after one hour - and use it as authentication. To use jjwt with osgi I as forced to create a port project. First the 'feature' character of the bundles is not supported in the current felix...

 The generation 7 shows massive reorganisations and reimplementations. After renaming repository names (moved the 'cherry' prefix to 'mhus') the reorg is finished and the sources are ready for a more stable generation 8. Generation 8 will add new features to work with none OSGi services in cloud environments. Actual changes: cherry-reactiive -> mhus-reactive cherry-vault -> mhus-vault cherry-web -> mhus-web mhus-osgi-cluster -> mhus-cluster

To simplify my blog I moved all entries from 'de' and 'dev' into the main blog. This will make it simpler for me to mange the blog and will hide the fact that too less posts on the blog ;) I plan to write more short posts then a few extended once. 

 In Generation 7 (all versions with miner 7 version) all needless prefixes are removed. This means if the artifact name includes the name of the main project - most of all the prefix 'mhu'. For example in the project 'mhus-lib' there was the package 'mhu-lib-core'. The prefix is now removed and the package is name 'lib-core'. The second prefix is left to specify the project.

 For reorganisation I split the project mhus-sop to mhus-rest and mhus-micro and parts in the existing mhus-osgi-tools. Now mhus-sop (service orientated platform) is depecated. The parts to handle rest interfaces is moved to mhus-rest. Why another rest framework? Because this rest is prepared to handle deep rest structures instead of for example jax-rs. The parts for Operations and Operation providers are moved to mhus-micro. This is the central framework to work with micro services. It's able to combine different micro service frameworks to one interface. The part AAA and ADB Service is moved into mhus-osgi-tools. Some interfaces are moved directly in mhus-lib. The tool IdentUtil will return the current ident without big actions.

 I tried to investigate in the felix healthcheck framework to create kubernetes health and ready checks. I found that the healthcheck can be used in karaf even. You have to install it manually with install -s mvn:org.apache.commons/commons-lang3/3.9 install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.api/2.0.2 install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.core/2.0.2 install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.generalchecks/2.0.2 And the webconsole: feature:install webconsole install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.webconsoleplugin/2.0.0 Now you can see the check results with: http://localhost:8181/system/console/healthcheck The source is available under https://github.com/apache/felix/tree/archived/healthcheck/webconsoleplugin

 The main change in mhus-lib will be the extraction of mhu-lib-vaadin into a separate project mhus-vaadin. In this project I started a library for vaadin 14+ but for preparation I moved the subproject of vaadin 8 to this project together. Also the vaadin bridge from mhus-osgi-tools is now located in the new repository. The new project pass on the The package declaration was not changed

 After vaadin changed to the new flow technology it needs more effort to migrate to a new major version then 8. In my case it means to test how to get vaadin in karaf working. Unfortunately there is no direct karaf support in vaadin and there is no example or documentation how to do it. But I found OSGi support since vaadin 13. An example project was not working as described in the documentation (https://github.com/vaadin/base-starter-flow-osgi). Even with different branches and tags I get dependency exceptions in the OSGi framework. So I started creating a new configuration and project from scratch. I used my docker image with karaf 6.2.6 installed and java 11.0.3 to create a sample project and a bundle configuration. You can checkout the project within my example project (https://github.com/mhus/mhus-examples) in folder vaadin-flow/mhu-vaadin-examples1. Compile the sources with maven: git clone https://github.com/mhus/mhus-examples.git cd mhus-examples/vaadin-flow/mhu-vaadin...

 Since Vaadin 7 will no more supported in 2019 I need to migrate to a newer version of the library. I migrated to Vaadin 8 in mhu-lib 3.4.0, mhu-osgi-tools 1.4.3 and mhu-ports 1.3.6. The new version no more supports tables (I will discuss pro and contra in another post) but a set of legacy packages will do it for the moment. There are also some other changes but they are more or less handy.   The migration of the application can be done by a tool. The tool will modify all java imports to the new - correct - packages. I was using the standalone tool (alternatively you can use a maven goal). Download the sources from  https://github.com/vaadin/framework8-migration-tool  and compile the project afterwards you can use the jar file to migrate your projects. Change location into your project home directory and execute the jar file java -jar $HOME/.m2/repository/com/vaadin/framework8-migration-tool/8.0-SNAPSHOT/framework8-migration-tool-8.0-SNAPSHOT.jar If you use maven you...

 A tool that I love for unix is uptime. Showing the current and last runtimes. Now I invested 60 minutes to implement id in karaf also. Showing the current and last runtime records or the karaf server as the original. Use 'uptime' to see the current records karaf @root()> uptime  Status        | Runtime           | Start                     | Pid         | System               -------------------------------------------------------------------------------------------------- CLOSED        | 00 12:14:52       | 2018-08-03 22:26:43       | 24703       | 02 02:18:00          CURRENT       | 00 00:39:39       | 2018-08-04 10:41:37       | 26418       | 02 02:58:00      ...

 It looks like it's not easy to recognise the console cols and rows in every case. After a period of continuous tries and fails I found that even the 'specialists' are not able to find the size of the console in every case. Just now I use jline to find the terminal size. But if you login into karaf using a ssh client it's not possible at all. As reaction I created a console factory (as it should be) to create console instances for every thread and it's possible to overwrite the current used console instance. Now in karaf it's possible to use console set to set a session bound console instance which will recognise the size correctly by using the session instance.

 mhu-lib:3.3.5: Terminal width and height will be recognised correctly for XTerm now. Also it will be updated on the fly. In osgi use 'mhus:console dump' to print the current terminal attributes.

 In mhus-osgi-tools:1.4.1 the command shell:highlight will recognise non graphical terminals and mark finding with stars "*" before and after the finding by default. Graphical options will be disabled. Also the marker #reset is available to reset all previously defined markers. If you set a marker without content, the attribute will be reseted. e.g. '#f' will reset the foreground color and '#b' will reset the background color.

 Zuerst Postgres im Docker-Container starten und den Client aufrufen. Die Version ist natürlich optional.  Hier der Link zur Beschreibung des Containers . docker run --name postgres -e POSTGRES_PASSWORD=nein -d postgres:9.6.7 docker run -it --rm --link postgres:postgres postgres psql -h postgres -U postgres Jetzt die Datenbank anlegen: CREATE DATABASE testdb1 WITH ENCODING='UTF8'; Den Benutzer: CREATE USER usr_testdb1 WITH PASSWORD 'nein'; Und nun die Berechtigungen: GRANT ALL PRIVILEGES ON DATABASE testdb1 TO usr_testdb1; Fertig!

 Um die Kommunikation zwischen mehreren IT-Systemen zu sichern läuft man immer wieder in das Problem des letzten Geheimnisses. Wir wollen eine Kommunikation aufbauen, die zum einen abhörsicher ist, zum anderen beide Seiten eindeutig identifizieren soll. Der erste Teil ist dank asynchroner Verschlüsselung nicht mehr schwer. Jede Seite hält einen öffentlichen Schlüssel der anderen Seite. Da niemand dazwischen, ohne den privaten Schlüssel die Daten lesen kann sind die Daten vor fremden 'Ohren' sicher. Der zweite Teil wird gelöst, indem sich jede Seite durch ein Geheimnis, z.B. Passwort identifiziert. Auch hier kommen asynchrone Schlüssel zur Anwendung. Eine Zeichenfolge wird verschlüsselt und dem gegenüber geschickt. Kann dieser die Zeichen entschlüsseln, wurde er erfolgreich identifiziert. Was aber, wenn ein System kompromittiert wird? Wenn ein Dritter Zugriff auf Datenbank oder Dateisystem bekommt, oder Programmcode auf dem gesicherten System ausführen kann. Er kann private Schl...

 Auch hier zuerst den Docker-Container starten. Ich benötige eine Version 10.2.  Hier wieder der Link zur Beschreibung des Containers . docker run --name mariadb -e MYSQL_ROOT_PASSWORD=nein -d mariadb:10.2 und nun den Client aufrufen docker run -it --link mariadb:mysql --rm mariadb sh -c 'exec mysql -hmariadb -uroot -pnein' Nachdem die Datenbank-Instanz bereit steht, die Datenbank, Benutzer und Rechte anlegen: CREATE DATABASE testdb1; CREATE USER 'usr_testdb1'@'localhost' IDENTIFIED BY 'nein'; GRANT ALL PRIVILEGES ON testdb1.* TO 'usr_testdb1'@'localhost'; Oder/Und eine Benutzer, der auch von außen zugreifen kann: CREATE USER 'usr_testdb1'@'%' IDENTIFIED BY 'nein'; GRANT ALL PRIVILEGES ON testdb1.* TO 'usr_testdb1'@'%';

 Wenn ihr auch eine  Raspi im lokalen Netzwerk angeschlossen habt und außerdem nicht sicher seit was die anderen Geräte wie TV oder Xbox in eurem Netzwerk so machen, könnt ihr dem Raspi noch eine Zusatzfunktion verleihen. Installiert einen Honeypot auf dem Gerät. Ein Honeypot ist im Grunde ein Dienst, den keiner braucht und deshalb nicht nutzt. Fängt ein Angreifer an das Netzwerk auszuspähen, trifft er zwangsläufig auf die vom Honeypot bereitgestellten Dienste und versucht diese zu inspizieren. Nun gibt sich der Honeypot wie ein echter Dienst aus und protokoliert die Aktivitäten. Eine Benachrichtigung, z.B. via Email informiert den Administrator über ein potentielles Problem. Wie also den Raspi zu einem Honeypot machen. Die Software  tiny-honeypot  bietet, was wir benötigen. Dazu muss vorerst git und xinetd installiert werden. apt update apt install git  xinetd nun kann das Projekt abgeholt werden und in das System integriert werden git clone https://github.com/...