This repository contains a Java application that monitors a given folder so that, every time a new file is modified or created, it is uploaded to a remote server.
On this repository you will also find scripts for client certificates generation and a minimal server for testing purposes.
You just need a Linux PC capable of running docker containers. Then, run this:
...it will automatically download a docker container prepared to run "gradle" (a Java build system) and compile the source code.
The final "binary" will be placed on the root folder (the same folder where this
README.md file can be found) and it's called
IntraService-x.x.jar (for example
build.sh is run the container is created, gradle is initialized,
the build process takes place and, finally, the docker is destroyed. If you are
going to be working on the source code, you can tell
build.sh to stay
inside the container, so that future invocations will be much faster. This is
how it is done:
build.sh xxxto build and stay inside the container.
exitto terminate the container.
In order to run the application on a given PC, you need 3 things on that PC:
IntraService-1.2.jarbinary that we generated in the previous section.
client_certificate.p12keystore file containing a client certificate.
The JRE (Java Runtime Environment) version 8 (or higher) can be installed
directly from Oracle (for Windows computers) or from your distro package maneger
(for Linux computers, example:
$ sudo pacman -S jre8-openjdk).
There is also a script called "run.sh" that will use a docker container with JRE preinstalled so that you don't have to install anything. Note, however, that you will only then be capable of monitoring folders from inside the docker container (obviously!).
client_certificate.p12 file is generated following the instructions in the
next section. It must be placed in the same folder from where you will be
executing the application.
Once you have everything ready, run this:
$ java -jar IntraService-x.x.jar /path/to/folder/to/monitor
Note, however, that unless the server to which the application connects to is up and running the application will fail with a "Connection error".
The URL of the server the application connects to is fixed and can only be changed by modifying file
SERVER_URL) and re-building the application.
There are instructions on how to set up a basic test server later on this same README.md file.
As we explained in the previous section, in order to run the application, a file
client_certificate.p12 must be pressent on the same folder from where
you run the application.
The idea is that the "service provider" (ie. the company running the server) provides a unique client certificate to each client. This is how the server knows who is making each request and if it is allowed or not to do it.
This is how the "service provider" does this:
scripts/certificatesand run this:
./create_new_client_certificate.sh ca client <company_name>
cafolder is empty (which will be the case the first time you run this script) a new root certificate (used to sign all client certificates) will be created (this is what you will later have to place on the server so that it can figure out if client certificates are valid or not). When this happens, you will be prompted for data regarding your (ie. the "service provider") company (name, country, etc...).
cafolder is not empty, then the root certificate contained in there will be use to sign the client certificate instead of creating a new one. Note that all your client certificates should be signed by the same root certificate, thus after the
cafolder has been filled the first time this script is executed, you should probably commit that to the git repository so that they can be used in the future to sign all new client certificates.
clientfolder is where several files named <company_name>.<something_else> will be place. The one that ends in ".p12" is the one you need to take and rename to
client_certificate.p12. In order to generate these files you will be asked to provide information regarding the client company. The most important field is the one called "Common Name" (its value will later be used by the monitor application to fill the
client_idfield that is embedded on each request).
In order to be able to work on the source code of the monitor application, we needs a simple server it can connect to.
There is one such server on folder
tests/server. This is how you use it:
That's all. The server will place all the received files from the server on
The server will be listening on
localhost:5000, thus you must configure the
monitor application to connect to this URL (which is what comes by default).