~greenfoo/sync_monitor

Tool to monitor for file changes to upoad them to a remote server
8630698d — Fernando Ramos 4 years ago
Add license
579f5535 — Fernando Ramos 5 years ago
v0.3
7d6cfe40 — Fernando Ramos 5 years ago
Almost there...

refs

master
browse  log 

clone

read-only
https://git.sr.ht/~greenfoo/sync_monitor
read/write
git@git.sr.ht:~greenfoo/sync_monitor

You can also use your local clone with git send-email.

#What is this?

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.

#Build instructions

You just need a Linux PC capable of running docker containers. Then, run this:

$ ./build.sh

...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 IntraService-1.2.jar).

Every time 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:

  1. The first time (while outside the container) run build.sh xxx to build and stay inside the container.
  2. The rest of times (while inside the container) simply run build.sh.
  3. Once you are done, simply run exit to terminate the container.

#Usage

In order to run the application on a given PC, you need 3 things on that PC:

  1. JRE 8 (or higher).
  2. The IntraService-1.2.jar binary that we generated in the previous section.
  3. A client_certificate.p12 keystore 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!).

The 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 IntraService.java (variable 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.

#Client certificates generation

As we explained in the previous section, in order to run the application, a file called 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:

  1. Go to folder scripts/certificates and run this:
./create_new_client_certificate.sh ca client <company_name>
  1. If the ca folder 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...).
  2. If the ca folder 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 ca folder 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.
  3. The client folder 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_id field that is embedded on each request).
  4. The last argument is a string (protected by quotation marks) that uniquely identifies each client (ex: the name of the client's company).

#Test server

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:

  1. "cd" into tests/server
  2. Run go.sh

That's all. The server will place all the received files from the server on folder downloads.

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).