on-prem / jidoteki-admin

On-Prem virtual appliance administration

On-Prem virtual appliance & live image administration

On-Prem installs the On-Prem Admin package in /opt/jidoteki.

This repository contains bash scripts, ansible roles, and other files needed to perform remote virtual appliance or live image administration, updates, etc.

Requirements

• PicoLisp 32-bit or 64-bit v17.12+
• Tested up to PicoLisp v20.6.29, see test runs
• Ansible 1.8.4 to 2.7.x
• curl
• git
• sha1sum (from core-utils)
• dos2unix (from busybox)
• symlinktool for running backups
• openssl v1.0.2+, for validating TLS certs
• stunnel for validating TLS certs

Usage

# replace <destdir> with the directory prefix to install the files
ansible-playbook jidoteki.yml -c local -i images.inventory -e prefix=<destdir> --tags=admin

tags

There exist two tags for running the ansible roles:

• admin: executes every task in the role, installing all On-Prem Admin scripts
• lib: only executes tasks related to the lib dependencies, without the On-Prem Admin scripts

admin role

The admin role configures directories and files in /opt/jidoteki/tinyadmin:

• Create admin directory structure
• Create admin directories writeable by root/admin
• Create admin sftp uploads directory
• Add SSH admin management scripts
• Add SSH admin wrapper script
• Add SSH admin lib dependencies

Tests

To run the tests, type make check

Changelog

See the Changelog.

License

This project is MIT licensed, see the LICENSE file for more info.

jidoteki-admin's Issues

Sorting command fails on v >= 10

The sorting command used to identify the latest software update package will fail if the version number is greater or equal to 10.

Example output :

$ ls -r software_package-*.asc*
software_package-v1.1.7.asc
software_package-v1.10.9.asc
software_package-v1.10.7.asc
software_package-v1.0.5.asc
software_package-v1.0.1.asc

The latest should be v1.10.9.

This can be fixed with sort --version-sort -r

Example:

$ ls software_package-*.asc* | sort --version-sort -r
software_package-v1.10.9.asc
software_package-v1.10.7.asc
software_package-v1.1.7.asc
software_package-v1.0.5.asc
software_package-v1.0.1.asc

Debug script to obtain appliance info

Sometimes an appliance, or its applications crash for unknown reasons.

It would be nice to have an API endpoint + admin scripts to obtain appliance debug info. This information could be used to debug an offline/on-premises appliance.

The script would need to be flexible, to allow additional debug commands to be added without modifying the actual script.

Separate boilerplate code from scripts

The update_* scripts contain a lot of code which repeats itself. A generic functions script should be created which exports the repetitive functions, and allows the update scripts to be simpler and easier to debug.

The 'api' role has too many dependencies

In the spirit of keeping things light weight, I find it quite troublesome that so many external deps are required to run the api role.

It would be best if it could install a binary (yum/deb) package containing the pre-compiled binaries for the API (picoLisp, compiled json parser, etc).

Code signing for update packages

There is no way to identify the creator of the update package.

Anyone having the shared key can create a valid update package for an appliance. We can solve this by using gpg to sign the update packages, and ensure only valid ones can/will be applied to the appliance. This would require the trusted signer's public key in the appliance.

Prevent certain scripts from running simultaneously

Add mutex to ensure two calls to the same script can't be made simultaneously. This could be tied into #6 as a generic function / safeguard.

The mutex should be enabled only on specific scripts, essentially the ones which modify data.

Don't base64 encode update packages

Current update packages are created with openssl's -a flag, which base64 encodes the encrypted file, increasing its file size by ~33%.

Removing this flag is easy, but older systems will not be able to update from a package that's not base64 encoded -- a transition plan will be necessary.

Cert update shouldn't restart Admin API

Restarting the admin API will not reload the new cert.

We should instead send SIGHUP to stunnel/stunnel4/nginx in order to pickup the new certificate.

Temporary TLS cert files should be removed on failure

From update_certs.sh, on failure, a call is made to cleanup(), but the ca.pem and possibly public/private TLS keypairs are not removed from the temporary storage location.

Those files should be removed to ensure a second upload attempt succeeds.

Allow updates to major versions

At the moment it's not possible to update from v1.0 to v2.0 due to a restriction in the update_vm.sh script. The only workaround is to omit the version.txt in the update package.

The script needs to allow updates of major versions as well.

Services toggle script

Related to on-prem/jidoteki-admin-api#11

The services toggle script update_services.sh should generate entries for the services.json as well as generate services flag files to be read by the boot script.

For forward compatibility, the list of services which can be toggled should be stored in a simple text configuration file.

Upon running the script and updating services.json, the script should then attempt to start the services whose toggle files are present, and attempt to stop the services whose toggle files are missing 😕

EDIT: changed the order, present toggle files = start, missing = stop

update_settings script should update wifi settings

The current update_settings script does not handle wifi settings unless they are added to network.json / network.conf.

These should be separate, therefore the script needs to handle wifi.json / wifi.conf which can be parsed by external tools such as wpa_supplicant.

Convert text files with incorrect line endings

Certain files uploaded from Windows computers contain invalid line endings ^M (ex: TLS certificates).

This causes app problems and can be corrected with dos2unix. The tool should be used to convert text files before processing them any further.

New update_certs script for TLS certificates

If an end-user manages their own PKI, this will allow them to use their own TLS certificates and CA roots.

An update_certs script should exist to validate uploaded .crt and .key certificates, as well as the CA root certificate. It should then merge them into a single .pem file and add the CA root to the system store.

Related to on-prem/jidoteki-admin-api#10