on-prem / jidoteki-admin Goto Github PK

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

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.