After installing GateOne on my Raspberry Pi 2 Debian system, I can log on to SSH via HTTP and browser. But only from my internal network, as the external accessible port is blocked by Apache. To add GateOne from outside, I either can disable Apache (no, won`t do it) or make GateOne accessible through Apache. I`ll use Apache as a reverse proxy for this.
Note: you`ll need Apache 2.4 for this, as GateOne uses Websocket for communication, and this is included only ootb with Apache 2.4.
I won`t use a subdomain for this example, so no new Apache virtual host will be use. This means that I have to use a URL prefix to access GateOne. The prefix is: /ssh. This must be configured in the GateOne configuration file:
sudo vim /opt/gateone/server.conf
Change the parameter url_prefix and restart GateOne
url_prefix = "/ssh"
To be able to access GateOne from external, the URL of the external server must be added to origin. In my case, this means that www.itsfullofstars.de is added.
Easiest way to test SCEP with Afaria is to make use of the delivered ServerSCEPtest application. This application comes with Afaria`s PackageServer component. It can be found in the bin directory of the package server.
The test application is a Windows executable that executes the SCEP process through Afaria. You have two options available for the test:
I am going to execute the SCEP/NDES test using the package server. This is the Afaria component used by all clients to receive a client certificate for apps.
To run the test, at least the common name value must be filled in. This is the CN= part of the certificate. Normally, this is your user id. Unfortunately, the test tool is limited to 2048 bit key (Afaria SP8) and does not select you higher or custom values. To run the test, just select perform test button. The additional CSR informations like city, org, etc are taken from the package server configuration. These values are given by the Afaria admin.
The status of the SCEP process is shown in the log area. You can see that the CSR is created and send to the package server CA. After the test ran without errors, the returned certificate is saved to: C:\ProgramData\SAP\Afaria.
The see and validate the value of the new certificate, you can use the Crypto Shell Extensions of Windows Server.
The certificate was issued by the CA: CA. Lifetime is one year. And the template is AfariaUser. This matches exactly how the NDES template was configured.
To be 100% sure, the CA can be consulted. Normally, all issued certificates are stored there and can be consulted. Taking a look into the issued certificate list, I can see that a new certificate by the NDES user was issued using as a template AfariaUser. Therefore, the new NDES configuration is validated and working.
When you work with Afaria, you`ll sooner (iOS) or later (Android, WP) come in contact with certificates. To be more specific, with device (iOS) and user (all platforms) certificates. To make it as easy as possible to get those certificates available to the devices and users, an MDM solution makes use of SCEP. SCPE in the Microsoft world is called NDES, and is available with their CA. If you install everything following the official documentation, you`ll end up having
A working environment (yeah)
Most probably a certificate issue, as your users and devices get a certificate named IPSec (Offline request).
This default certificate is what Microsoft thinks fulfills most use cases of SCEP (sorry, NDES) and basically they are right. A device or user can use this certificate without problems for most of the scenarios. Most importantly, users can use it to authenticate themselves against services. It may be that
your security area does not like the name
the lifetime does not meet the requirement: its 2 years as given by Microsoft
it is missing some functionality
wrong algorithm or key length
or something else
All of the above points are valid and can invalidate the use of the default configuration. Which leaves you to the question: how to solve this?
To make Afaria get back from the CA a valid certificate based on a custom template, it only takes two steps:
Create a template
Assign template to NDES (SCEP)
With SCEP, Afaria is only consuming a service offered by CA. How the CA is treating the request, depends 100% on the CA. Therefore, no additional configuration is needed on the consuming service: Afaria. As a result of this, three steps are necessary to make Afaria get back a custom certificate:
To change the default certificate template NDES is using, it is necessary to change some Windows registry values. Looks like there is no GUI tool from Microsoft for this available. The procedure for changing these values is given by Microsoft ,. To do so, open the registry editor and navigate to:
HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> Cryptography -> MSCEP
Under this node, the registry values can be found. By default, the certificate template used by NDES is IPSECIntermediateOffline.
I`ll now use my AfariaUser certificate I created in an earlier blog (you can find it on my site). To change this and to make use of the new AfariaUser certificate, edit all three entries.
Afterwards, the registry key looks like this:
To make the new templates effective for new requests, restart IIS (or the CA too, or the whole computer).
The creation of a certificate template is a basic administration task for a CA admin. To create a new template, open the CA management console and manage the available certificate templates
Next, select a base template and duplicate it. The new template will be based on this template and inherit some if its properties. It is a good idea to take the User template as a basis for certificates requested by Afaria via SCEP.
Select for which CA type this template is going to be generated and later on used. You should go for at least Windows Server 2008.
Now you can fill in the information of your certificate template. This information will be used by the CA to create the final certificate, requested by Afaria. Make sure to include all you need and to configure it accordingly to your requirements.
After clicking OK, the new certificate template is listed in the available templates of your CA. Please be aware that with this, the new certificate template is only available for the CA, it is not added to the list of templates actually used by the CA. You can have several CA`s in your organization and while the administrator add new templates for the whole organization, only selected certificates may be used by certain CAs. You can have a CA that is only issuing user certificates, while another CA only issues device certificates.
To make the template available to your CA, add the template to the list of available templates to issue for your CA.
Select it from the list.
Congratulations. Now your new certificate template is available to your CA and new certificates based on this template can be issued to clients.
I created a set of Docker images that contain the OpenUI5 runtime library. They are available for download at Docker hub.
Developing UI5 apps means to try out things and to support the final app. You may have the challenge to find out up to which library version your app works or when it is broken. For this, it is necessary to have a range of versions of the UI5 library available. OpenUI5 makes the latest supported version of their library available for download and there is also a CDN with a list of older releases. The CDN is the way to go when you have to do some backward testing as it also contains the SDK. To make use of an older UI5 version, just point to it. Example for 1.28.6: https://openui5.hana.ondemand.com/1.28.6/resources/sap-ui-core.js
To make use of the older releases, you must have internet access. That may not always be the case. In that case, you`ll have to download the resources. From the OpenUI5 project home you can right now download the latest version of 1.26, 1.28, 1.30 and 1.32. You can either download the SDK or runtime version or use the online version. But you`ll depend on what UI5 is offering online. This causes a problem when you have to do offline testing or the library version you need is not made available for download by OpenUI5. Having the libraries on CDN implies that you can access the CDN. Good luck for your CI builds or automated testing when you are behind a corporate proxy. Some CI setups also do DevOps, and when you have to reflect some operational configuration in your web server setup, you`ll have to set up somehow your own OpenUI5 environment. Something a CDN only supports partly.
What to do when you want to have the libraries available locally, in your intranet, on a computer without internet access or for your CI build? Easy: just download the files and host them on a web server like apache. This gives you still just one version of OpenUI5. Repeat this for each new version of OpenUI5 and over the years you`ll get a nice archive. To get a OpenUI5 library repository with all released version, you can make use of the fact that the project is open source and hosted on GitHub. And all versions tagged. It`s easy to build each historic version out of the git repository. Build it, put it into an apache www directory, and you can access it via a browser. This is easy, but takes some time.
To help you out with your OpenUI5 CI projects (or bug hunting, compatibility checks, etc), I created some Docker images. These images contain a set of OpenUI5 libraries and can be used in your CI setup or to try out OpenUI5 in a simple and easy way without having to install something besides Docker.
Contains all openui5 library versions. The images is automatically build using my Docker file hosted on GitHub. Contains ALL OpenUI5 versions. You get >70 versions accessible via Apache. Each version is hosted under /<version>/resources. Example: /1.34.2/resources.
I had to face some Docker hub build restrictions, which impaired me to offer just one image. Right now I have one image for each minor tagged version (1.26, 1.28 -> 1.34). The images are cumulative. 1.26 gives you the version from 1.25 to 1.26, while 1.34 comes with all version from 1.25 up to 1.34. I guess in the near future I`ll also create images that only contain the versions of each minor release (only 1.28.*, but not 1.26.*).
Size: 1.34: 877 MB
Get image: docker pull tobiashofmann/openui5-rt:<tag>
Start container: docker run –d –p 50000:80 –t tobiashofmann/openui5-rt
Lately I was playing around with HCP and Olingo and wanted to expose a JPA model as OData. I created some data using EJB and then tried to read this data via OData. Accessing the collection gave me a list of created entities:
<message xml:lang=”en-US”>Requested entity could not be found.</message>
Thing is: the entity was there. I know it (I have DB access), I just could not access it. Turned out that the version of org.eclipse.persistence.jpa I was using does not like when the @ID key is of type long (8L). Using version >= 2.5.2 solved the issue for me. Changing my pom.xml:
You won`t have to declare it in pom.xml. Either way, if you do not declare it, or use the wrong version, you`ll end up getting the same error: Requested entity could not be found. The version of the library delivered with HCP is 188.8.131.52 org.eclipse.persistence.jpa_2.4.1.v20121003-ad44345 and looking the Google results, this version is also not working 100% when the @ID is long. Best solution should be to declare the dependency in pom.xml and use as version at least 2.5.2.
I wrote about this problem already earlier in 2015, but after installing VMWare Player 7 and a CentOS based VM, the process did not work anymore for me. I did the dd part to fill the disk with 0, but the Player tool for shrinking did just execute without doing nothing. Running from within the VM the vmware-toolbox command for shrinking a disk returned an error message.
Command: vmware-toolbox-cmd disk list
What happened? I do not know for sure, but it looks like VMWare Player does not like a lot CentOS and XFS for shrinking. For my VM the actual space used inside was reported by df –h as not even 15 GB, while on the physical disk it occupied 25 GB. So, how to get back several GB of space?
There is a tool available from VMware that allows to shrink a vmdk offline. It`s part of VDDK and of their Workstation and more professional products, but not for Player. With the use of Google I found a KBA article where the tool is actually attached. Downloading the tool and put it into the right VMPlayer directory so it can find some DLLs needed for execution. You can also download the VDDK SDK where the tool is included: Download VDDK. After installing the tool, call it with the –k flag to compress a vmdk disk.
Command: vmware-vdiskmanager.exe –k <path to vm>\<Name of disk>.vmdk
The name of the disk can be seen in the directory, it’s the one ending on vmdk.
Running your own home server is nice, especially when it`s a Raspberry Pi and the power consumption is very low (hint: your light bulb consumes more). When you run your own server, from time to time you`ll have to access your server remotely. From inside your home network this is not a problem, but how about remote access? SSH is the preferred solution, but you need to have a port open, in and out. So when you are at a location where SSH is not allowed, you won`t be able to connect, and running your SSH server on port 80 or 443 isn`t always a solution:
Your web server might be running there or
The proxy you have to pass through will find it strange to see non HTML requests being made to that port
You might consider a remote desktop solution that allows you to connect to a terminal, but why not making use of a solution that exposes SSH server over HTTP? Say hello to GateOne. To know more what GateOne is check out their web site and GitHub repository
Besides the downloaded packages, you`ll need python and python-support.
sudo apt-get install python
sudo apt-get install python-support
sudo dpkg -i python-tornado_2.4-1_all.deb
sudo dpkg -i gateone_1.1-1_all.deb
The above dpkg command installed GateOne in the folder /opt/gateone. When started, GateOne reads its configuration from a file named server.conf. This file is only created after GateOne was run at least once (or you copy another version into the directory). Next step therefore is to run GateOne and then stop it to be able to alter the default configuration. Run GateOne to let it create the configuration file:
End the program (ctrl-c). As a result, server.conf will be now available.
I`ll run GateOne behind a proxy that will do the SSL stuff, so I can disable ssl
disable_ssl = True
On port 443 my proxy is running, so I must change the port GateOne is going to use.
port = 9080
To make connections to this port, add it to origins
This is the basic GateOne configuration. My reverse proxy will handle the TLS part, so I did not have to configure GateOne for this. Of course, best practice is to also make sure GateOne only accepts TLS secured connections. After all, I`ll transmit a password. But the proxy and GateOne run on the same host, and I`ll use GateOne only for external access. I think in this special case I can ignore the additional security.
SAP releases a software development kit (SDK) for its SAP Mobile Platform 3 (SMP3) to enable developers to efficiently create apps. The SDK is not a static product but is actively developed and supported by SAP. This means that a SDK receives constant updates and patches.
The above screenshot shows that only for SDK SP10 7 patch levels were released, in a little more than 1 month. The installation of a SDK is always done in the same location. Therefore, only one SDK version can be used at a time be a developer. While this assures that only the latest version is going to be used, it creates a problem in regards to maintainability and ongoing development. A new development project may use SP10, while a current one may still depend on SP9. To overcome this, a developer may create local copies of the SDK and manually switch between the different versions, an approach is going to be presented in this document that allows the developer to have different versions of the SDK available.
The approach consists of using git to manage the individual versions of the SDK. Of course, a different revision control system may be used, but git offers normally a superior handling and speed. The overall process is as followed:
Create an initial version of the SDK.
Add this version to git and tag it correspondently
Install a newer version of the SDK to the same location
Use git to add this version and tag it correspondently
The work with a specific SDK version, the developer checks out the needed version
If necessary, remove/add the Kapsel plugins / libraries to a project
Path: Sybase products -> SAP Mobile Platform SDK -> SAP MOBILE PLATFORM SDK 3.0 -> Support Packages -> SAP MOBILE PLATFORM SDK 3.0 -> [OS]
Install the initial version of the SDK
Go the the installation folder. Either opt to version the whole installation folder or just a part of the SDK, like Kapsel. The following example will only version Kapsel.
Note: by default, Fiori Mobile Client apps are stored inside the Kapsel SDK folder. As each FMC app adds a few thousands files, it is a good idea to not have these included into the git versioning. Consider using .gitignore for those folders.
Initial commit and tag
Initialize the folder: git init
Add all content: git add –A –v
Commit files: git commit
Tag commit: git tag –a SPnPLm –m “SDK SPnPLm”
Updating the SDK
Download a newer version of the SDK and install it. Ensure that KapseSDK is going to be upgrade (which should be the default).
Go the installation folder to add the new files to git.
Note: it is important to know that with git a folder .git is created which stores all the git relevant information. In case this folder is deleted, so will also the files and versions added to git. Normally the SDK installer is only overwriting and adding files and not removing. The .git folder should therefore not be impacted by the SDK installation / upgrade process.
Subsequent commit and tag
Add all content: git add –A –v
Commit files: git commit
Tag commit: git tag –a SPn+1PLm+1 –m “SDK SPn+1PLm+1
Files that were part of the previous SDK version but not of the current one will be shown as remove.
See available SDK versions
Use a specific version of the SDK
To use a specific version of the SDK, it must first be stored in git and tagged. To use the version, a simple checkout is sufficient to update the whole KapselSDK folder to the specified version. To make use of this version, the Kapsel plugins must be updated in an already used project. For a new project, the usual process of adding a plugin is to be used.
List available versions: git tag
Checkout version: git checkout
To complete the installation, install the Kapsel dependencies as described in README.md.