Java API for nextCloud/ownCloud

Java API for nextCloud

Currently the nextCloud and ownCloud solutions have a very big drive in the market. One of the main reason is, that you have control over your data.

When you look at recent events and news, then we can confirm this.
In our company we have been using ownCloud/nextCloud since version 5.x and have a long positive history with the solution.
We also provide managed nextCloud solutions, for sharing data with your customers for example, as backup back end and many other use cases.

The use case

To integrate nextCloud in your business processes, you sometimes need to automate things a bit more than what is included out of the box.
If possible we do this with shell scripts, but for complexer work flows, this isn't enough.
In those cases we use the full power of server side java applications.
Unfortunately the API of nextCloud is not fully REST/Webdav, it has some parts (Mainly file sharing and provisioning) which work with a XML style interface.

The java integration

To be able to use these API also from java applications, we have created a API library which exposes the important parts for simple usage in java applications.
To give back something to the open source community, we have decided to publish the library under the GPL license, so it can be used by other applications.
You can find the library source on github, and feedback and additions to the api are appreciated.

Happy coding

Extended monitoring of SSL certificates with Zabbix

In my post about two years ago I showed how to monitor SSL certificates with Zabbix.
In the meantime the scripts/templates have been enhanced, with some small corrections/bugfixes.

One notable new feature is the possiblity to monitor SSL certificates which are delivered by SNI, which means you can have multiple SSL certificates available on the same IP/Port combination.
This is a critical feature, to better use the available IPv4 addresses.

The enhanced templates and scripts are now available via Github, which allows you to open issues if something is not working in your environment or contribute to new features as well.

I'm interested to hear about your use cases and feedbacks.

Install Symantec Endpoint Protection on Debian Jessie

Syamntec endpoint protection is not only shipping for Windows systems, but also for OS-X and Linux systems.
Installing it on a debian jessie server does require some manual steps to have all features enabled.

The first step is to create a package in your SEP installation, simplest with a web downloadlink which you can later use to fetch the package via wget.

1. Install Java 8
2. Download JCE from http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
3. Install the cryptografic files into "/usr/lib/jvm/java-8-oracle/jre/lib/security"
4. Ony 64-bit systems enable i386 packages and install glibc in 32bit edition
   dpkg --add-architecture i386
   apt-get update
   apt-get install libc6:i386
5. On 64-bit systems install the linux-headers to allow compilation of the realtime scan kernel modules
   apt-get install linux-headers-amd64
6. Download your SEP package from your server wget http://<your-sep-server>/EmailInstallPackages/xxxxxxxxxxxx/sep/SymantecEndpointProtection.zip
7. Unzip zip package
8. bash ./install.sh -i  

Installing Java 8 on Debian Jessie

Installation Oracle Java 8 on Debian Jessie

Debian 8 alias Jessie ships with OpenJDK 7 which is fine in many cases. But sometimes you need a more recent version.
In that case you can use the ubuntu ppa archives as install source.

Just type these commands in the console of your Debian system and it should install just fine, also providing automatic security upgrades as they become available.

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" > /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" >> /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer
java -version

Upgrading from Debian 6 Openswan to Debian 8 Strongswan

When upgrading from Debian 6 to Debian 8, then IPSEC softwarestack is changed from Openswan to Strongswan.
The switch itself is not a big thing, but when you still have other Openswan IPSEC partners, you will have to change your Strongswan config a little bit.
Otherwise the two IPSEC implementations won't be able to build the VPN tunnel.

On the Openswan end of the VPN you will see such messages in your auth.log file:

Jan 28 11:58:55 fw pluto[1279]: "vpn01" #746: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #670 {using isakmp#4 msgid:6c3f1671 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: starting keying attempt 5 of an unlimited number
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #747: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #669 {using isakmp#4 msgid:23eb99a9 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000

On the Strongswan side, you see this in the daemon.log:

Jan 28 12:16:52 vpn01 ipsec[13909]: 09[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
Jan 28 12:16:52 vpn01 ipsec[13909]: 09[ENC] generating INFORMATIONAL_V1 request 2468276578 [ HASH N(NO_PROP) ]

This is dues to some IKE mismatch (The OpenSWAN IKEv2 implementation has does not respect all standards)
You can solve this issue by specifying IKEv1 for the connection in your ipsec.conf on the Strongswan side:

keyexchange=ikev1

This should solve the problem.
Sometimes (Depending the Openswan setttings) you also have to add this to your connection  definition on the Strongswan side:

esp=aes128-sha1-modp2048!

Removing Windows Intune client (4 methods)

Hi there, just a quick and simple overview on how to remove a Windows Intune client installation.

Method 1

The best way of achieving this would be to retire the client from the Windows Intune admin console. This removes the client software on the target systems.

Method 2

If you don't have access to the admin console (for whatever reasons) uninstalling a recent version of the client can only be done with the help of some batch scripts and an executable which can be downloaded from Microsoft.
Uninstall download

After executing the exe some files will be extracted. Copy these files to the client and execute the batch files (method 2):

• AgentUninstall_AIS.cmd
• AgentUninstall_Intune.cmd

After some time the folder C:\Program Files\Microsoft\OnlineManagement should only hold some logfiles. Reboot the client.

At this moment you can enroll the client into Windows Intune again or install a SCCM client to manage the client again.

Method 3

1. Open an admin command prompt
2. Navigate to C:\Program Files\Microsoft\OnlineManagement\Common
3. Run “ProvisioningUtil /UninstallAgents WindowsIntune” (method 3)

Method 4

Uninstall is also possible via WMI.
wmic product where “name like ‘%intune%'” call uninstall

Using ftdi_sio with linux kernel 3.12 and up

A few years ago I did post some informations on how to use a Bixolon BCD-1100 or a Epson DM-D110 displays attached via USB to a linux system.

This works fine, unless you upgrade your Linux system to a kernel with version 3.12 or greater.

Since Kernel 3.12 you will see this in the logs:
# dmesg
ftdi_sio: unknown parameter 'vendor' ignored
ftdi_sio: unknown parameter 'product' ignored 


The problem is, that these two parameters where only intended to be used by developers for testing purposes. So they have now been removed from the 3.12 kernel.
But fortunaly, the linux guys did provide a official way to specify the vendor and product ID's.

We can find it in the file: /sys/bus/usb-serial/drivers/ftdi_sio/new_id.
This file contains a pair of vendor and product id, so all we need is to put those values into this file, doing something like this:

/sbin/modprobe ftdi_sio
echo "1208 0780" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

If you wish to have it automatically configured, just update your /etc/udev/rules.d/50-dmd110.rules file as follows:

ATTR{idProduct}=="0780", ATTR{idVendor}=="1208", RUN+="/sbin/modprobe -q ftdi_sio" RUN+="/bin/sh -c 'echo 1208 0780 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'",  OWNER="root", MODE="0666"

or for the /etc/udev/rules.d/51-bixolonBCD1100.rules

ATTR{idVendor}=="1504", ATTR{idProduct}=="0011", RUN+="/sbin/modprobe -q ftdi_sio"  RUN+="/bin/sh -c 'echo 1504 0011 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'",  OWNER="root", MODE="0666"

or for the  /etc/udev/rules.d/52-star-bcd122u.rules
ATTR{idVendor}=="0519", ATTR{idProduct}=="0007", RUN+="/sbin/modprobe -q ftdi_sio"  RUN+="/bin/sh -c 'echo 0519 0007 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'",  OWNER="root", MODE="0666"

Please note that you still need to use the correct serial port settings.
The bcd122u for example runs at 19200 baud as where most others are using 9600 baud.