LogoLogo
WebsiteTechnical Discussions
Developer documentation
Developer documentation
  • Public Technical Documentation
    • device-management-service
      • main
        • actor
        • api
        • cmd
          • actor
          • cap
        • db
          • repositories
            • clover
        • dms
          • behaviors
          • jobs
          • node
          • onboarding
          • resources
        • docs
          • deployments
          • onboarding
          • private_network
        • executor
          • docker
          • firecracker
          • background_tasks
          • config
          • hardware
        • maint-scripts
        • network
          • libp2p
        • observability
        • specs
          • basic_controller
          • s3
          • volume
          • integration
        • tokenomics
        • types
        • utils
          • validate
      • release
        • actor
        • api
        • cmd
          • actor
          • cap
        • db
          • repositories
            • clover
        • dms
          • behaviors
          • hardware
          • jobs
          • node
          • onboarding
          • resources
        • docs
          • deployments
          • onboarding
          • private_network
        • executor
          • docker
          • firecracker
        • internal
          • background_tasks
          • config
        • maint-scripts
        • network
          • libp2p
        • observability
        • plugins
        • specs
        • storage
          • basic_controller
          • s3
          • volume
        • test
        • tokenomics
        • types
        • utils
          • validate
    • solutions
      • asi-node
        • main
          • demos
            • ocap_auth
              • ansible
              • videos
          • did-auth-use-scenarios
            • create-a-hosting-deployment
            • make-a-payment
            • manage-dids-and-ocaps
            • register-an-ai-agent
            • submit-a-compute-job
          • pilots
            • asi-create-authentication-poc
        • release
      • nunet-appliance
        • main
        • release
    • test-suite
      • main
        • cicd
          • tests
            • acceptance_tests
            • feature_environment
          • cli
          • dms-on-lxd
            • local
        • environments
          • development
          • feature
          • production
          • staging
        • infrastructure
          • acc-tests-config-maker
          • cloud-init
          • nginx
        • stages
          • dependency_scanning
          • functional_tests
          • integration_tests
          • load_tests
          • regression_tests
          • security_tests_1
          • security_tests_2
          • security_tests_live
          • unit_tests
          • user_acceptance_tests
      • release
        • cicd
          • tests
            • feature_environment
          • cli
          • dms-on-lxd
            • local
        • environments
          • development
          • feature
          • production
          • staging
        • infrastructure
          • cloud-init
          • dms-on-lxd
          • nginx
        • lib
        • stages
          • dependency_scanning
          • functional_tests
          • integration_tests
          • load_tests
          • regression_tests
          • security_tests_1
          • security_tests_2
          • security_tests_live
          • unit_tests
          • user_acceptance_tests
    • team-processes-and-guidelines
      • main
        • best_practices
        • ci_cd_pipeline
        • community_feedback_process
        • contributing_guidelines
        • git_workflows
        • nunet_test_process_and_environments
        • secure_coding_guidelines
        • specification_and_documentation
        • team_process
          • a_project_management
          • b_ceremonies_artifacts
          • c_drum_buffer_rope
          • d_development_process
          • e_culture_rules
          • f_mr_review
        • vulnerability_management
          • devsecops_maturity_models
          • nunet_security_pipeline
          • secret_management
          • sop_security_mr_review
Powered by GitBook
On this page
  • incus-acc-tests-config-maker
  • Pre-requisites
  • Usage
Export as PDF
  1. Public Technical Documentation
  2. test-suite
  3. main
  4. infrastructure

acc-tests-config-maker

PreviousinfrastructureNextcloud-init

Last updated 5 minutes ago

Last updated: 2025-06-02 01:06:31.173446 File source:

incus-acc-tests-config-maker

This project reads client certs and server certs and outputs a file compatible with the acceptance tests.

For more details please refer to the

Pre-requisites

  • Python >3.9

  • uv

Usage

First you should create the tokens from the remote. Log into each server and execute incus config trust add {name}. The name should be descriptive of its use and is for reference when managing the target server.

Then you should create the certificates. To do so, first build the provided docker image:

docker build -t incus-acc-tests-config-maker .

Then open a shell in a container using that image

docker run -it --rm -v $PWD:/app -v ./incus:/root/.config/incus incus-acc-tests-config-maker bash

Inside that shell, you can issue the certificates for each server. You can also change -v ./incus:/root/.config/incus to a different folder map if issuing server certificates for different clients, i.e. -v ./incus-new-user:/root/.config/incus

To generate the cerfificates:

incus remote add {remote-name-1} remote-url.example.com:8443 --accept-certificate --token {generated-token-1}
incus remote add {remote-name-2} remote-url.example.com:8443 --accept-certificate --token {generated-token-2}
#...

Now make sure you fix the permissions before running this tool:

sudo chown -R $USER: .

Then you can generate the config file using this tool:

uv run main.py --remotes {remote-name-1} {remote-name-2}

This will generate a new config file with the required certificates. If you want to amend an existing config file for instance to add new remotes to a pre-existing config, you can pass the existing config file to the tool:

uv run main.py --remotes {remote-name} --config-file /path/to/existing/cfg.yml

Also, when managing multiple users, you can specify the incus config folder as well as the existing config file:

uv run main.py --remotes {remote-name} --config-file /path/to/existing/cfg.yml --incus-conifg-folder $PWD/incus-new-user

The output file is called config_out.yml and is deployed in the current working directory from which this tool is being executed.

link on GitLab
Acceptance tests architecture documentation