The documentation needs to be updated to reflect recent changes made to the ern tool.
Create an installer for the eRN. While creating the installer:
include a BOM (bill of materials) of files used in the eRN. The BOM records blake3 checksums for each file.
embed minisign as a base64 encoded payload.
Cryptographically sign and embed the eRN as a tar.xz archive
When installing, the installer must:
Verify the embedded archive, and copy it to the correct location
Include a command in the ern tool to run a self check using the generated BOM.
Cryptographically sign the final release of SIF files with minisign.
Update the module loading algorithm to:
Verify the cryptographic signature of the downloaded SIF file.
During development, continue using sha512 checksums.
Move the SSH configuration files used by the eRN to the user`s SSH directory.
Configure yazi to access the file systems of configured Slurm and PBS clusters.
Write a dialog to collect information to facilitate debugging user issues. Information to be collected:
Relevant command history
Environment variables
Any modules loaded.
Improve module documentation by:
Include a table, under a heading named Revisions, with each row corresponding to a previous version of the module. Each row also includes the version of the installed software and the date the module was released.
Add tooling to manage and mount remote filesystems, such as:
sftp, to access storage on, for example, clusters.
s3, to access files in cloud storage.
Complete tooling to backup projects.
Apply CGroup v2 fixes that affects determining available memory. This depends on the availability of the new cluster for testing.
Software such as Positron, Quarto, and Visual Studio Code can be used with multiple programming languages. The languages relevant for the eRN are Python, R, and Julia. While these languages are available in the eRN as modules, the isolation provided by containers presents one significant problem: shared object files are not accessible between containers. A standard mechanism needs to be developed to manage software that needs access to shared object files to enable all the capabilities. Some options are:
Install all the software into a container. Does not scale, as more software is bundled together, more and more version incompatibilities are encountered.
Development of a user modules: Refactor existing recipes to build modules with the required combination of software, some issues:
Floating licenses were available and therefore Geneious could easily be used on the HPC. Unfortunately, the floating license option was removed by Dotmatics. Workarounds, or alternatives, need to be investigated.