Archiv für den Monat: Oktober 2013

RetroShare – Chat mit Verschlüsselung

Security

Nachdem Skype als „sicheres“ Kommunikationsmittel ausscheidet, haben wir uns Jabber (XMPP) zugewendet. Wenn man in seiner Firma einen eigenen Jabber-Server aufgesetzt hat, dann ist man auf der richtigen Seite. Zumindest, was Chat und Dateitransfer angeht, funktioniert das sehr gut über die meisten Plattformen.

Nachteilig ist natürlich, dass es hier eines zentralen Servers bedarf. So muss man sich einen oder mehrere Accounts bei hoffentlich vertrauenswürdigen Servern verschaffen.

Einen anderen Weg beschreitet RetroShare. Das Programm bietet im Wesentlichen 2 für mich interessante Features:

  1. volle PGP-Verschlüsselung und
  2. dezentrale „Friend-2-Friend“-Kommunikation.

Als Open-Source-Projekt hat man zumindest die relative Sicherheit, dass der Code-Stand einem Public-Review ständig standhalten muss. Man ist nicht auf Closed-Source oder (bewusst) schlechte Implementierungen eigentlich guter Algorithmen angewiesen wie bei einigen beliebten Tools.

Zu Beginn kreiert man ein PGP-Schlüsselpaar und kann den öffentlichen Teil nun auf verschiedene Weisen seinem Partner senden. Erst, nachdem beide Enden der Kommunikation den jeweiligen Schlüssel des Anderen in Händen halten, kann die Suche losgehen.

Dezentral bedeutet, dass man gerade keinen zentralen Look-Up für das Vorhandensein und das Routing zu seinem Partner erhält. So beinhaltet RetroShare verschiedene Strategien, wie das Gegenüber gefunden wird.

Im gleichen Subnetz wird man relativ schnell gefunden. Es seid denn, man befindet sich hinter einer Firewall mit Proxy und NAT (wie in Firmen üblich). Dann muss man auf einen „Relay“ zugreifen oder einer der Partner macht sich selbst zu einem solchen.

Zur Erklärung des Suchvorganges gibt es im RetroShare-Wiki eine gute Quelle: RetroShare’s anonymous routing model.

Neben dem reinen Austausch von Texten und Dateien realisiert RetroShare noch sehr viel mehr an Funktionalität:

  • …
  • Messages
  • Forums
  • Channels
  • Voice over IP
  • Instant messaging
  • Groupchat
  • …

Auf alle Fälle eine gute Alternative für sicherere Kommunikation und ein interessantes Konzept für möglichst hohe Infrastruktur-Unabhängigkeit.

Cargo remote deployment Tomcat7: Error writing request body to server

Java, Maven, Pitfall

I tried to deploy a WAR into a TomEE/Tomcat7 application server and I received an exception: „Error writing request body to server„. No Tomcat log file has useful information about that.

I use maven with Cargo plugin to deploy via the manager application of the Tomcat.

The configuration of the plugin inside the pom.xml is:

<plugin><!-- http://stackoverflow.com/questions/6436351/cannot-redeploy-to-remote-tomcat-7-with-using-cargo-maven-plugin, http://cargo.codehaus.org/Deploying+to+a+running+container -->
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.2</version>
<configuration>
<path>${remote.deployment.path}/${project.artifactId}/DEPLOY    /${project.artifactId}-DEPLOY.war</path>
<skip>${xxxx.deployment.skip}</skip>
<container>
<containerId>tomcat7x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.remote.username>${xxxx.user}</cargo.remote.username>
<cargo.remote.password>${xxxx.pwd}</cargo.remote.password>
<cargo.remote.uri>http://${xxxx.host}:8080/manager/text</cargo.remote.uri>
</properties>
</configuration>
</configuration>
</plugin>

The command line is: mvn -X cargo:deployer-redeploy -P testsystem

In the internet I found two hints to solve the problem. First I checked the amount of bytes to send to the management application. There were some restrictions in the webapps/manager/WEB-INF/web.xml file at multipart-config>max-***-size.

Unfortunately this wasn’t my problem. The second hint were the proxy settings. I disabled my Ubuntu network proxy. But I forgot the ~/.m2/settings.xml of maven itself. After I fixed the maven proxy setting no exception occured and the deployment was successful.