Warning
Currently kontor is in pre-alpha stage, providing no secure way of transferring the files!
kontor is a client-server bundle that is designed to execute pre-defined procedures on server by request of authorized client.
Most of the class names are based on the word-play around white-collar office work:
- Bureau is a server-side frontline service handling incoming requests and redirecting them to appropriate Clerk for processing
- Clerk is a server-side main request processing entity
- Cubicle is temporary storage for processing files received from an applicant
- Applicant is a client, requesting a procedure and waiting for the results
- and so on...
kontor follows semantic versioning (SemVer) principles. Version numbers are in the format MAJOR.MINOR.PATCH.DEV where:
MAJORversion is incremented when new functionality or bug fixes are added on the protocol level in a non-backwards-compatible manner OR there are incompatible API changesMINORversion is incremented when new functionality or bug fixes are added in a backwards-compatible mannerPATCHversion is ignored since kontor releases do not happen that often, set to0for all releasesDEVversion is incremented for development releases and is not intended for production use, may be in formatdevN, e.g.dev1,dev2,dev3, etc.
kontor can be installed or upgraded by simply calling pip command:
pip install kontor --upgradeMinimum Python version supported is 3.8.
kontor relies on following external packages:
- dacite
-
Create a
start_server.pyfile and add following text there (this file is also present inexamples/serverrepo folder):#!/usr/bin/env python import logging import os import signal import sys from kontor.bureau import Bureau def shutdown_signal_handler(sig, frame): logging.critical("Caught SIGINT signal, bureau will be shut down.") sys.exit(0) if __name__ == "__main__": # # Catch Ctrl+C signal for notifying about bureau shutdown. # signal.signal(signal.SIGINT, shutdown_signal_handler) bureau = Bureau(os.path.dirname(os.path.realpath(__file__))) bureau.start()
-
Create
server_configuration.jsonfile next tostart_server.py. Example configuration may look like following (detailed description of each field is provided in Configuration files breakdown section):{ "ip_address": "localhost", "port": 5690, "chunk_size_kilobytes": 256, "client_idle_timeout_seconds": 30, "max_storage_period_hours": 0, "max_parallel_connections": 100, "max_consequent_client_procedures": 1, "max_grace_shutdown_timeout_seconds": 30, "forced_ssl_usage": false, "certificate_path" : "~/test_certificate.cer", "certificate_key_path" : "~/test_certificate.key", "procedures": { "test_procedure": { "name": "test_procedure", "operation": "echo \"this is a test procedure\"", "error_codes": [ 1 ], "max_repeats_if_failed": 3, "time_seconds_between_repeats": 10 } } } -
Create
server_users.jsonfile next tostart_server.py. Example configuration may look like following (detailed description of each field is provided in Configuration files breakdown section):[ { "username": "test_user", "password_hash": "test_password_hash", "allowed_procedures": [ "test_procedure" ] } ]
It is possible to run Bureau as service on Windows by using WinSW v3 as bundled tool.
-
Create a new folder, e.g.
C:\kontor -
Download WinSW executable of suitable version
-
Put it to
C:\kontorfolder -
Rename it to
kontor.exe -
Create a
kontor.xmlconfiguration file and add following text there:<service> <id>kontor</id> <name>kontor</name> <description>This service runs kontor as Windows service.</description> <executable>python</executable> <arguments>start_server.py</arguments> <log mode="none" /> <onfailure action="restart" /> </service>
-
Create kontor-specific files according to the instructions in General section and put them to
C:\kontorfolder. -
Install kontor as a service by calling following command in CMD:
kontor install
-
Start service by calling the command:
kontor start -
WinSW CLI instruction has a lot more of useful commands that can be applied. Most useful though would be following:
kontor stop
kontor restart
kontor uninstall
Configuration file is a JSON file with structure mentioned in General section. It contains following fields:
ip_address- The IP address on which the bureau server listens for incoming connections. Default islocalhost.port- The port number on which the bureau server listens for incoming connections. Default is5690.chunk_size_kilobytes- The size of data chunks in kilobytes used for file transmission. Default is256.client_idle_timeout_seconds- The time in seconds after which an idle client connection is closed by the bureau. Default is30.max_storage_period_hours- The maximum period in hours for which the bureau can store received files before they are automatically deleted. A value of 0 means no automatic deletion. Default is0.max_parallel_connections- The maximum number of parallel client connections that the bureau can handle simultaneously. Default is100.max_consequent_client_procedures- The maximum number of consequent procedures that a single client can execute before being disconnected by the bureau. A value of 0 means no limit. Default is1.max_grace_shutdown_timeout_seconds- The maximum time in seconds that the bureau waits for ongoing procedures to complete during a graceful shutdown before forcefully terminating them. Default is30.temp_cleanup_enabled- A boolean flag indicating whether the bureau periodically cleans up orphaned temporary folders left behind by procedures that terminated abnormally. Default istrue.temp_cleanup_cron- A cron expression (standard five-field format, e.g."0 * * * *"for hourly) defining the schedule on which the periodic temporary folder cleanup is executed. Only used when temp_cleanup_enabled is True. Folders older than max_storage_period_hours are removed during cleanup. Default is"0 * * * *"(hourly).forced_ssl_usage- A boolean flag indicating whether SSL/TLS encryption is enforced for all communications between the applicant and the bureau. If set to True, all connections must use SSL/TLS; if False, SSL/TLS is optional. Default isfalse.certificate_path- The file path to the SSL/TLS certificate used by the bureau for encrypted communications. This should be provided if forced_ssl_usage is True or if SSL/TLS is desired. Default is empty string.certificate_key_path- The file path to the private key corresponding to the SSL/TLS certificate used by the bureau. This should be provided if forced_ssl_usage is True or if SSL/TLS is desired. Default is empty string.procedures- A dictionary mapping procedure names (strings) to their corresponding ProcedureProtocol objects, representing all procedures available for execution by applicants. Each ProcedureProtocol object contains the following fields:name- The name of the procedure. Also used as a key in theproceduresdictionary. Required field.operation- A description of the operation performed by the procedure. This can be a command, script, or any other operation that the bureau will execute when the procedure is requested. Required field. May contain following macros:<FILE_NAME>- The path to the input file received from the applicant. It will be replaced with the actual file path when the procedure is executed.<FILE_COPY>- The path to a copy of the input file received from the applicant. This copy is created in the cubicle and can be used for operations that require a separate file. It will be replaced with the actual file path of the copy when the procedure is executed.
timeout_in_seconds- The maximum time in seconds that the procedure can take to complete. Default is60seconds.error_codes- A list of error codes that will cause the procedure to be considered as failed. If the procedure returns an error code that is not in this list, it will be considered as successful. Default is an empty list, meaning that any exit code will be considered a success.max_repeats_if_failed- The maximum number of times the clerk can repeat the procedure if it fails. Default is3.time_seconds_between_repeats- The time in seconds that the clerk must wait between repeat attempts of the procedure after a failure. Default is10.time_seconds_between_procedures- The time in seconds that the clerk must wait between executing this procedure and any subsequent procedure, regardless of success or failure. A value of 0 means no waiting time is required between procedures. Default is0.
Users file is a JSON file with structure mentioned in General section. It is a list of dictionaries, each representing an applicant with the following fields:
username- The username of the applicant. Required field.password_hash- The hashed password of the applicant. Password is hashed with SHA512 and stored as a string of hexadecimal digits. Required field.allowed_procedures- A list of procedure names as strings that the applicant is allowed to execute. These names must correspond to the keys in theproceduresdictionary of theserver_configuration.jsonfile. Required field.
-
Install ca-certificates application, if needed:
sudo apt-get install -y ca-certificates
-
Generate a Certificate Authority (CA):
openssl genrsa -out kontor.key 2048
-
Self-sign the newly created Certificate Authority (CA):
openssl req -x509 -new -nodes -key kontor.key -sha256 -days 365 -out kontor.crt
-
Copy newly generated certificate to local certificate folder:
sudo cp kontor.crt /usr/local/share/ca-certificates
-
Update current list of used certificates:
sudo update-ca-certificates
-
Add
kontor.crtandkontor.keyto server configuration withforced_ssl_usageset totrue:... "forced_ssl_usage": true, "certificate_path" : "kontor.crt", "certificate_key_path" : "kontor.key", ...
sequenceDiagram
participant Client
participant Server
loop
Server->>Server: waiting for incoming requests
end
Client->>Server: requesting auth
activate Server
loop
Client->>Client: waiting for the response
end
break when the auth fails
Server-->>Client: show failure
end
Server-->>Client: auth success
deactivate Server
Client->>Server: requesting procedure for file
activate Server
loop
Client->>Client: waiting for the response
end
break when the procedure check fails
Server-->>Client: declining procedure
end
Server-->>Client: accepting procedure
deactivate Server
Client->>Server: sending file
activate Server
break when the file transmission fails
Server-->>Client: show failure
end
Server-->>Client: file receiving receipt
loop
Server->>Server: processing file
end
Server->>Client: requesting result file receiving
activate Client
Client->>Server: accepting result file receiving
deactivate Client
Server->>Client: sending result file
deactivate Server