Ubuntu server 22.04 KVM host

This template contains the configuration files needed to run a KVM host on Ubuntu Server 22.04 LTS.

Virtual machines are created on storage supported by LVM services.

Template override parameters

File _values-tpl.yaml contains template configuration parameters and their default values:

#
#   _values-tpl.yaml
#
#   cskygen template default values file
#
_tplname: ubt2204srv-kvm
_tpldescription: Ubuntu server 22.04 kvm base installation
_tplversion: 23-11-24
#
# Values to override
#
## Machine related configuration values
machine:
  hostname: ubt2204srv-kvm
  domainname: cskylab.net
  localadminusername: kos
  localadminpassword: "NoFear21"
  timezone: "UTC"
  # networkinterface: enp1s0
  ipaddress: 192.168.80.9
  netmask: 24
  gateway4: 192.168.80.1
  searchdomainnames:
    - cskylab.net
  nameservers:
    - 192.168.80.1
  ## Setup directory where configuration files will be injected
  setupdir: "/etc/csky-setup"
  systemlocale: "C.UTF-8"
  systemkeyboard: "us"
  
restic:
  ## Restic password is mandatory to access repository
  password: 'NoFear21'
  ## Restic repositories can be located in local paths, sftp paths and s3 buckets
  ## Local path example:
  # repo: '/srv/restic/mydir'
  ## S3 example:
  # repo: 's3:https://backup.cskylab.net/restic/mydir'
  ## sftp example:
  repo: 'sftp:kos@hostname.cskylab.net:/media/data/restic/mydir'
  
  ## S3 Bucket access and secret keys must be specified for S3 located repositories
  aws_access: 'restic_rw'
  aws_secret: 'iZ6Qpx1WiqmXXoXKxBxhiCMKWCsYOrgZKr'

Prerequisites

Hardware requirements

Note: Additional disks can be added and managed by LVM.

Network assignements

cSkyLab virtual networking model is defined in 01-netcfg.yaml NetPlan configuration file in kvm machines. It includes the following networks:

All VLAN's are defined inside a unique uplink bond:

If external managed switches are used, it is recommended to bond 2 or 4 NIC's for the uplink, as defined in NetPlan configuration file 01-netcfg.yaml.

If only two physical machines are used (kvm-main and kvm-aux), there is no need to deploy the networking model to external switches. You must then connect the bond between both machines in order to get the networking model up and running.

The physical machine hosting kvm services must have at least 4 NIC's (5 if users local access is needed) in order to provide external connections to the following networks:

• NIC 1: WAN
• NIC 2: sys
• NIC 3: SETUP
• NIC 4: bond_csky
• Optional NIC 5: usr

The recommended configuration is 4 10Gb NIC + 4 1Gb NIC connected as in the SuperMicro example provided.

Note: Before deploying kvm, you should perform in your machine a basic installation of Ubuntu 22.04 server and get the interfaces names with networkctl status --all. Plan and modify your NetPlan configuration file 01-netcfg.yaml according to your interfaces names.

How-to guides

Inject & Deploy configuration

To install and configure the machine, open a terminal from the machine configuration directory in the management repository, and perform the following configuration steps:

1. SSH Authentication and sudoers file

# Run csinject.sh in [ssh-sudoers] execution mode
./csinject.sh -k

NOTE: If IP address has not been previously set in cloud-init or net-config, use -r IPaddress until network configuration files are deployed.

This step injects ssh key and sudoers file into the machine.

Required before other configuration options. Its purpose is to allow automated and passwordless logins by using ssh protocol.

If ssh key has not been injected before, you must provide the password for username {{ .machine.localadminusername }}@{{ .machine.hostname }} twice:

• First one to install ssh key (ssh-copy-id).
• Second one to deploy the sudoers file.

2. Network configuration

# Run csinject.sh to inject & deploy configuration in [net-config] deploy mode
./csinject.sh -d -m net-config

NOTE: If IP address has not been previously set in cloud-init or net-config, use -r IPaddress until network configuration files are deployed.

This step deploys network configuration files that allow the machine to operate with specific IP address and hostname. Cloud-init configuration will be disabled from the next start.

Reboot is recommended when finished.

3. Install packages, updates and configuration tasks

# Run csinject.sh to inject & deploy configuration in [install] deploy mode
./csinject.sh -d -m install

This step performs:

• Package installation
• Updates
• Configuration files deployment
• Configuration tasks

Required to run at least once in order to complete proper configuration. Reboot is recommended when finished.

4. Configuration tasks

# Run csinject.sh to inject & deploy configuration in [config] deploy mode (default)
./csinject.sh -d

When configuration needs to be changed, this mode redeploys all configuration files into the machine, executing again all configuration tasks.

5. Connect and operate

# Run csconnect.sh to establish a ssh session with sudoer (admin) user
./csconnect.sh

To run scripts and operate from inside the machine, establish an ssh connection with administrator (sudoer) user name {{ .machine.localadminusername }}@{{ .machine.hostname }}.

Storage services

Manage disk volume groups

Usage:

  sudo cs-volgroup.sh -h

List status:

  sudo cs-volgroup.sh -l

Create volume group + LVM thin pool:

# Create volume group with default variable values
  sudo cs-volgroup.sh -m create

If only one volume group is going to be created, you can edit the script and update in section Variable initialization the values for volume group name vg_name and block device names block_dev_names.

Otherwise, you can specify these values in the following way:

  # Create volume group with name "ssd"
  # from disk devices "/dev/sdb /dev/sdc /dev/sdd"
    sudo cs-volgroup.sh -m create -d "/dev/sdb /dev/sdc /dev/sdd" -v ssd

Delete volume group + LVM thin pool:

# Delete volume group with default variable values
  sudo cs-volgroup.sh -m delete
  # Delete volume group with name "ssd"
  # from disk devices "/dev/sdb /dev/sdc /dev/sdd"
    sudo cs-volgroup.sh -m delete -d "/dev/sdb /dev/sdc /dev/sdd" -v ssd

Before deleting volume groups, you must delete the LV's inside.

Manage Thin Provisioning LVM data services

Usage:

  sudo cs-lvmserv.sh -h

List status:

  sudo cs-lvmserv.sh -l

Create LV data service (Thin logical volume + directory mount):

  # Create thin logical volume data service "/srv/mydir"
  # in default volume group.
    sudo cs-lvmserv.sh -m create -d /srv/mydir

Create snapshot:

# Create snapshot of data service "/srv/mydir"
# in default volume group.
# Snapshot will be mounted read-only in /tmp/mydir_snap
  sudo cs-lvmserv.sh -m snap-create -d /srv/mydir

Remove snapshot:

# Remove snapshot of data service "/srv/mydir"
# in default volume group
  sudo cs-lvmserv.sh -m snap-remove -d /srv/mydir

Merge snapshot (Rollback to snapshot status):

# Merge snapshot of data service "/srv/mydir"
# in default volume group
  sudo cs-lvmserv.sh -m snap-merge -d /srv/mydir

Delete LV data service:

# Delete thin logical volume data service "/srv/mydir"
# in default volume group.
  sudo cs-lvmserv.sh -m delete -d /srv/mydir

Free space of unused blocks inside thin-pools:

# Free space inside thin-pools
  sudo cs-lvmserv.sh -m trim-space

Repair LVM thin-pool

1. Unmount all LVM in the volume group

2. List LVM to see vg and lv names

sudo lvscan

3. Deactivate volume group

sudo lvchange -an vg

4. Repair thin-pool

sudo lvconvert --repair  vg/tpool

5. Activate volume group

sudo lvchange -ay vg

6. Mount LVM and check data

To learn more see the following procedure: https://smileusd.github.io/2018/10/12/repair-thinpool/

Rsync data replication

Note: Prior to operate rsync with a remote host, you must insert the root public key for ssh authentication and passwordless login as sudoer user in the remote host. From a console inside the machine you must run sudo ssh-copy-id {{ .machine.localadminusername }}@hostname.domain.com

Usage:

  sudo cs-rsync.sh -h

RSync data from local directory TO remote directory (snapshot automatically created and removed):

# RSync data service "/srv/mydir"
# TO same remote directory at host "hostname.cskylab.net"
  sudo cs-rsync.sh -m rsync-to -d /srv/mydir \
  -t hostname.cskylab.net

RSync data FROM remote directory to local directory:

# RSync data service "/srv/mydir"
# FROM remote directory "/srv/mydir" at host "hostname.cskylab.net"
  sudo cs-rsync.sh -m rsync-from -d /srv/mydir \
  -t hostname.cskylab.net

KVM RSync:

Pre-configured cron jobs for rsync are available in files tpl-kvm-main-cs-cron_scripts and tpl-kvm-aux-cs-cron_scripts

When kvm-main & kvm-aux machines are present, rsync cronjobs are used to achieve service HA for machines running in mirrored pools in the following way:

• To activate backup & data protection:

  • In kvm-main configuration repository directory (cs-sys/kvm-main) rename file tpl-kvm-main-cs-cron_scripts to cs-cron_scripts
  • In kvm-aux configuration repository directory (cs-sys/kvm-aux) rename file tpl-kvm-aux-cs-cron_scripts to cs-cron_scripts

• To deactivate backup & data protection:

  • In machine configuration repository directory rename file cs-cron_scripts to tpl-cs-cron_scripts

• Inject & deploy the desired configuration (activated or deactivated) to the machines by executing:

# Inject & deploy configuration files
./csinject.sh -qd

To dump virtual machines xml configurations and perform RSync manual copies on demand:

## RSync path:  /srv/vm-main/
## TO HOST:     kvm-aux.cskylab.com
sudo cs-kvmserv.sh -q -m vm-dumpcfg -p /srv/vm-main/ \
  && sudo cs-rsync.sh -q -m rsync-to -d /srv/vm-main/ -t kvm-aux.cskylab.net
## RSync path:  /srv/vm-aux/
## TO HOST:     kvm-main.cskylab.com
sudo cs-kvmserv.sh -q -m vm-dumpcfg -p /srv/vm-aux/ \
  && sudo cs-rsync.sh -q -m rsync-to -d /srv/vm-aux/ -t kvm-main.cskylab.net

Restic data backup and restore

The script cs-restic.sh is designed as a wrapper to execute restic in LVM data services with snapshot operations.

Usage:

  sudo cs-restic.sh -h

Credentials for default Restic environment and S3 bucket if used, are stored in the following variables:

# restic-environment
export RESTIC_REPOSITORY="{{ .restic.repo }}"
export RESTIC_PASSWORD="{{ .restic.password }}"
export AWS_ACCESS_KEY_ID="{{ .restic.aws_access }}"
export AWS_SECRET_ACCESS_KEY="{{ .restic.aws_secret }}"

Note: Prior to operate restic with a remote host in sftp mode, you must insert the root public key for ssh authentication and passwordless login as sudoer user in the remote host. From a console inside the machine you must run sudo ssh-copy-id {{ .machine.localadminusername }}@hostname.domain.com

Create repository:

To create Restic repository (Directory must exist):

  # Create repository
    sudo cs-restic.sh -m repo-init -r "{{ .restic.repo }}"

Backup LVM data service:

Data services must have been previously created with cs-lvmserv.sh. When making backup of a data service, the script automatically creates a snapshot and removes it when finished.

To backup a data service directory:

  # Backup data service /srv/mydir
    sudo cs-restic.sh -m restic-bck -d /srv/mydir \
      -r "{{ .restic.repo }}"

List snapshots in repository:

To list snapshots in a repository:

  # List snapshots in repository
    sudo cs-restic.sh -m restic-list -r "{{ .restic.repo }}"

Restore snapshot:

Data service directory must be empty. Otherwise you should use restic-mount and rsync data from mount point.

Restic restore does not show progress information in console. To see progress, open another terminal and run sudo du -sh /srv/mydir

To restore from specific snapshot E.G.:(2a3dff53):

  # Restore from specific snapshot
    sudo cs-restic.sh -m restic-res 2a3dff53 -d /srv/mydir \
      -r "{{ .restic.repo }}"

Mount restic repository snapshot:

Restic repository can be locally mounted, by default in /tmp/restic directory, in order to manually explore and copy files or to use the script cs-rsync.sh -m rsync-from to synchronize data from any snapshot in the repository to local data service directory.

To mount restic repository:

  # Mount repository in local directory /tmp/restic
    sudo cs-restic.sh -m restic-mount -r "{{ .restic.repo }}"

After a restic-mount operation, console will be freezed while repository is mounted. To access the contents of the repository, open another terminal and refer to the locally mounted directory /tmp/restic

Use of cs-rsync from mount point:

You can use the script cs-rsync.sh to restore a complete snapshot from mount point.

Examples:

  # RSync data service "/srv/mydir"
  # FROM Restic snapshot /tmp/restic/snapshots/latest
    sudo cs-rsync.sh -m rsync-from -r "/tmp/restic/snapshots/latest" \
      -d /srv/mydir
  # RSync data service "/srv/mydir"
  # FROM Restic snapshot /tmp/restic/snapshots/2021-04-03T21\:39\:08+02\:00
    sudo cs-rsync.sh -m rsync-from -r "/tmp/restic/snapshots/2021-04-03T21\:39\:08+02\:00" \
      -d /srv/mydir

Maintain Restic repository with forget option:

The default forget option provided in the script is --keep-hourly 6 --keep-daily 31 --keep-weekly 5 --keep-monthly 13 --keep-yearly 10. You can provide a specific forget option (-f) with an specific tag (-t).

It's not recommended to run restic prune with regular backups, since it can be a time-consuming process and it should be planned in a way that it doesn’t interfere with regular backups.

  # Forget snapshots in repository with default forget option and tag mydir
    sudo cs-restic.sh -m restic-forget -t "mydir" -r "{{ .restic.repo }}"

KVM Restic:

Restic is configured to perform data backups to local USB disks, remote disk via sftp or remote S3 storage.

Virtual machines running in storage pool /srv/vmachines (Kubernetes nodes) are not considered to perform restic backup of its storage disk files. Restic jobs must be scheduled for local storage services inside these virtual machines instead.

Pre-configured cron jobs for restic backups are available in files tpl-kvm-main-cs-cron_scripts and tpl-kvm-aux-cs-cron_scripts

To perform on-demand restic backups:

## Data service:      /srv/vm-main/
sudo cs-restic.sh -q -m restic-bck -d /srv/vm-main/ -r {{ .restic.repo }} -t vm-main 
## Data service:      /srv/setup/
sudo cs-restic.sh -q -m restic-bck -d /srv/setup/ -r {{ .restic.repo }} -t kvm-setup
## Data service:      /srv/vm-aux/
sudo cs-restic.sh -q -m restic-bck -d /srv/vm-aux/ -r {{ .restic.repo }} -t vm-aux

To view available backups:

## All snapshots
sudo cs-restic.sh -q -m restic-list -r {{ .restic.repo }}
## Specific tag
## Data service:      /srv/setup/
sudo cs-restic.sh -q -m restic-list -r {{ .restic.repo }} -t kvm-setup

Virtualization services

Create virtual bridges from list

Before applying virtual bridges, you must check Netplan network definition 01-netcfg.yaml and have prepared the desired bridges there.

The virtual networks to apply are listed in file brvlan-list.txt and names must match with the bridges defined in Netplan.

To apply network bridges and create virtual networks run:

# Apply virtual bridges:
sudo cs-kvmserv.sh -m set-bridges

Create directory services and storage pools

Local directory based storage pools must be created before defining pools. They should be created using the script cs-lvmserv.sh that handles management for local data services.

For future replication purposes, it is recommended to create a directory data service for clones, dvd iso, and cloud image files, and at least one directory for virtual machines. Example:

# Create local directories data services:
sudo cs-lvmserv.sh -m create -qd "/srv/setup" \
&& sudo cs-lvmserv.sh -m create -qd "/srv/vmachines" \
&& sudo cs-lvmserv.sh -m create -qd "/srv/vm-main" \
&& sudo cs-lvmserv.sh -m create -qd "/srv/vm-aux"

You can manage directory replication to or from other servers using the script cs-rsync.sh that handles replication for local data services. To backup local directory data services use the script cs-restic.sh.

Once the directory data services have been created, to apply storage pools check the file dirpool_list.txt and run:

# Apply storage pools:
sudo cs-kvmserv.sh -m set-stpools

Create virtual machines

You can create virtual machines with generic settings from a list (batch mode), or create a single machine with specific settings (single mode).

Create virtual machines in batch mode:

Batch mode allows creating vm's from a list vmachines_list.txt. Each record must contain the following information (space separated values):

vm_name         # Virtual machine hostname
vm_ipaddress    # IPAddress
vm_network      # Virtual network interface
vm_memory       # Memory in MiB
vm_vcpus        # Number of virtual CPU’s
vm_disk_size    # Disk size
vm_disk_path    # Virtual machine disk path.
vm_osvariant    # OS optimization. Use “osinfo-query os” to see options available
wm_cloud_image  # Cloud image full path name

Additionally to the specific values provided in the list, all virtual machines created will take values from the following templates:

• cloud_init.0000.yaml: Cloud-init template file.
• cloud_netcfg.000.yaml: Network configuration template file used when vm_ipaddress contains a specific address.
• cloud_netcfg.DHCP.yaml: Network configuration template file used when vm_ipaddress contains the value "DHCP".

You can customize these templates if needed.

To create virtual machines in batch mode, execute:

# Create virtual machines in batch mode:
sudo cs-kvmserv.sh -m vm-create

Create virtual machines in single mode:

To create a specific virtual machine from default cloud image, execute:

# Create virtual machine "srvtest" in single mode from default cloud image. 
# Directory "srvtest" must exist in setup containing cloud values files):
sudo cs-kvmserv.sh -m vm-create -n srvtest

Default cloud image can be changed specifying option [-i <cloud_image>] or changing the value for variable cloud_image in variable initialization section.

When creating a specific virtual machine, you must provide a directory named after the virtual machine in setup config, containing these three files:

• cloud_init.yaml: Cloud-init configuration file.
• cloud_netcfg.yaml: Network configuration file.
• cloud-virt-install.sh: Sourced script to execute virt-install command.

An example is provided with values to create virtual machine srvtest.cskylab.com.

Create virtual machine from blank disk & DVD installation:

To create a specific virtual machine from a blank disk and DVD installation, execute:

  # Create virtual machine "srvtest" in single mode from blank disk and DVD setup. 
  # Directory "srvtest" must exist in setup containing cloud values files):
    sudo cs-kvmserv.sh -m vm-create -n srvtest -i NONE \
      -r /srv/setup/OPNsense-20.7-OpenSSL-dvd-amd64.iso

When creating a virtual machine with blank disk and DVD installation, you still must provide a directory named after the virtual machine in setup config containing these three files with the following information:

• cloud_init.yaml: Not used. Must exist only for validation purposes.
• cloud_netcfg.yaml: Not used. Must exist only for validation purposes.
• cloud-virt-install.sh: Sourced script to execute virt-install command.

List all virtual machines

To list all virtual machines with its status, execute:

  # List all virtual machines
    virsh list --all

Start virtual machines

To start a specific virtual machine:

  # Start a virtual machine (domain in libvirt terminology)
    virsh start <machine_name>

To enable autostarting (configure a virtual machine to be automatically started at boot):

  # Autostart a virtual machine (domain in libvirt terminology)
    virsh autostart <machine_name>

To disable autostarting:

  # Disable autostarting for a virtual machine (domain in libvirt terminology)
    virsh autostart <machine_name> --disable

To start all virtual machines with --autostart option defined, execute:

  # Start all virtual machines with --autostart option defined
    sudo cs-kvmserv.sh -m vm-startall

Stop virtual machines

To shutdown gracefully a specific virtual machine:

  # Shutdown a virtual machine (domain in libvirt terminology)
    virsh shutdown <machine_name>

To force a virtual machine to stop:

  # Stop a virtual machine (destroy domain in libvirt terminology)
    virsh destroy <machine_name>

Note: Destroy command only force to stop a virtual machine. It remains defined in the virtualization host and can be started again by running virsh start <machine_name>

To shutdown gracefully all running virtual machines:

  # Shutdown all running virtual machines
    sudo cs-kvmserv.sh -m vm-stopall

Delete virtual machines

Delete mode can be executed in batch or single mode.

Delete virtual machines in batch mode:

To delete virtual machines in batch mode, execute:

  # Delete virtual machines in batch mode:
    sudo cs-kvmserv.sh -m vm-delete

Batch mode allows to delete vm's from a list vmachines_list.txt. The file and format is the same as explained previously in batch mode create section.

Delete virtual machine in single mode:

To delete a specific virtual machine, execute:

  # Delete virtual machine "srvtest" in single mode:
    sudo cs-kvmserv.sh -m vm-delete -n srvtest

Dump virtual machines xml configuration

You can dump xml configuration files for all machines in a directory (path mode) or for a specific machine (single mode).

Dump virtual machines xml configuration in path mode:

This is used to update all xml configuration files in a path. It's useful when preparing to export a whole data service directory to another KVM server.

To update and dump all configuration files in a path, execute:

  # Update xml dump of virtual machines in a path:
    sudo cs-kvmserv.sh -m vm-dumpcfg -p /srv/vmachines

Dump xml configuration for a single machine:

To dump a specific virtual machine xml configuration file, execute:

  # Dump xml configuration file of virtual machine "srvtest" in path /srv/vmachines
    sudo cs-kvmserv.sh -m vm-dumpcfg -n srvtest -p /srv/vmachines

In this case, xml configuration file /srv/vmnodexx/srvtest-dump.xml will be generated.

Define virtual machines

This execution mode defines in kvm servers virtual machines from xml configuration files generated previously when virtual machine was created. The files must be named consistently in the folowing way: vmachine_name-dump.xml.

Define virtual machines in path mode:

In this mode, all xml configuration files in a path will be used to define virtual machines. It's useful when importing a whole data service directory from another KVM server.

To define all virtual machines from xml configuration files in a path, execute:

  # Define virtual machines in a path from xml config files:
    sudo cs-kvmserv.sh -m vm-define -p /srv/vmachines

Define a single virtual machine:

In this mode, an specific xml configuration file will be used to define a virtual machine.

To define a virtual machine from xml configuration file, execute:

  # Define virtual machine srvtest from xml config file:
    sudo cs-kvmserv.sh -m vm-define -p /srv/vmachines -n srvtest

In this case, file /srv/vmnodexx/srvtest-dump.xml will be used to define the virtual machine.

Undefine virtual machines

Undefine virtual machines in path mode:

In this mode, all xml configuration files in a path will be used to undefine virtual machines. It's useful when exporting a whole data service directory to another KVM server.

To undefine all virtual machines from xml configuration files in a path, execute:

  # Undefine virtual machines in a path from xml config files:
    sudo cs-kvmserv.sh -m vm-undefine -p /srv/vmachines

Undefine a single virtual machine:

To undefine a virtual machine from xml configuration file, execute:

  # Undefine virtual machine srvtest:
    sudo cs-kvmserv.sh -m vm-undefine  -n srvtest

Utilities

Recover a qcow2 image using fsck

Load network block device module:

# modprobe nbd max_part=8

Poweroff machine:

# virsh destroy virtual-machine

Connect disk image:

# qemu-nbd --connect=/dev/nbd0 /var/lib/libvirt/images/virtual-machine.qcow2

Check disk:

# fsck /dev/nbd0p1
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
/dev/nbd0p1: recovering journal
/dev/nbd0p1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 274 was part of the orphaned inode list.  FIXED.
Inode 132276 was part of the orphaned inode list.  FIXED.
Deleted inode 142248 has zero dtime.  Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -603674 -623174 +(689342--689343)
Fix<y>? yes
Free blocks count wrong for group #18 (15076, counted=15077).
Fix<y>? yes
Free blocks count wrong for group #19 (11674, counted=11675).
Fix<y>? yes
Free blocks count wrong (632938, counted=670871).
Fix<y>? yes
Inode bitmap differences:  -274 -132276 -142248
Fix<y>? yes
Free inodes count wrong for group #0 (52, counted=53).
Fix<y>? yes
Free inodes count wrong for group #16 (99, counted=100).
Fix<y>? yes
Free inodes count wrong for group #17 (519, counted=520).
Fix<y>? yes
Free inodes count wrong (204392, counted=204599).
Fix<y>? yes
/dev/nbd0p1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/nbd0p1: 101833/306432 files (0.2% non-contiguous), 553321/1224192 blocks

Disconnect device:

# qemu-nbd --disconnect /dev/nbd0
/dev/nbd0 disconnected

Start machine:

# virsh start virtual-machine

Passwords and secrets

Generate passwords and secrets with:

# Screen
echo $(head -c 512 /dev/urandom | LC_ALL=C tr -cd 'a-zA-Z0-9' | head -c 16)
# File (without newline)
printf $(head -c 512 /dev/urandom | LC_ALL=C tr -cd 'a-zA-Z0-9' | head -c 16) > RESTIC-PASS.txt

Change the parameter head -c 16 according with the desired length of the secret.

Abridged ‘find’ command examples

When looking for files or directories, you can use the find command like in the following examples:

# Basic case-insensitive commands
# -------------------------------
find /tmp/restic/snapshots/latest/ -type f -iname "*foo*"   # find files under latest snapshot
find /tmp/restic/snapshots/latest/ -type d -iname "*foo*"   # find directories under latest snapshot
find /tmp/restic/snapshots/ -type f -name "foo.txt"         # find a specific file in all snapshots
# find files with different extensions
# ------------------------------------
find . -type f \( -name "*.c" -o -name "*.sh" \)                       # *.c and *.sh files
find . -type f \( -name "*cache" -o -name "*xml" -o -name "*html" \)   # three patterns
# find files that don't match a pattern (-not)
# --------------------------------------------
find . -type f -not -name "*.html"    # find all files not ending in ".html"
# Execute ls -lah with files found
# --------------------------------
find $PWD -type f -iname "*foo*" -exec ls -lah {} \;
# find files bigger than a size
# -----------------------------
find $PWD -type f -size +4G -exec ls -lah {} \;  # find all files bigger than 4GB

USB disk operations

Disk formatting and partitioning:

• Plug USB disk and find the block device:

  # List all disk devices and partitions
  sudo fdisk -l

• Execute fdisk in interactive mode:

  # fdisk interactive mode (Example for device /dev/sdc)
  sudo fdisk /dev/sdc
  
  Welcome to fdisk (util-linux 2.34).
  Changes will remain in memory only, until you decide to write them.
  Be careful before using the write command.
  Command (m for help): 

• Enter m to get a list of all available commands:

  Command (m for help): m
  Help:
    GPT
    M   enter protective/hybrid MBR
    Generic
    d   delete a partition
    F   list free unpartitioned space
    l   list known partition types
    n   add a new partition
    p   print the partition table
    t   change a partition type
    v   verify the partition table
    i   print information about a partition
    Misc
    m   print this menu
    x   extra functionality (experts only)
    Script
    I   load disk layout from sfdisk script file
    O   dump disk layout to sfdisk script file
    Save & Exit
    w   write table to disk and exit
    q   quit without saving changes
    Create a new label
    g   create a new empty GPT partition table
    G   create a new empty SGI (IRIX) partition table
    o   create a new empty DOS partition table
    s   create a new empty Sun partition table
  Command (m for help): 

• Enter g to create a new empty GPT partition table:

  Command (m for help): g
  Created a new GPT disklabel (GUID: FB0E06DB-479A-C842-A775-657D4D52BA41).
  Command (m for help): 

• Enter n to create a new partition and accept default values:

  Command (m for help): n
  Partition number (1-128, default 1): 
  First sector (2048-62545886, default 2048): 
  Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-62545886, default 62545886): 
  Created a new partition 1 of type 'Linux filesystem' and of size 29.8 GiB.
  Command (m for help): 

Note: You can change the partition type if needed, using option t change a partition type. (Example: 11 Microsoft basic data to support exfat file system.)

• Enter p to display the new partition table:

  Command (m for help): p
  Disk /dev/sdc: 29.84 GiB, 32023511040 bytes, 62545920 sectors
  Disk model: USB Flash Drive 
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: FB0E06DB-479A-C842-A775-657D4D52BA41
  Device     Start      End  Sectors  Size Type
  /dev/sdc1   2048 62545886 62543839 29.8G Linux filesystem
  Command (m for help):   

• Enter w to save the changes:

  Command (m for help): w
  The partition table has been altered.
  Calling ioctl() to re-read partition table.
  Syncing disks.

Format partition & create file system:

• To format partition and create the file system, run:

  # Format partition & create file system (Example for partition /dev/sdc1)
  sudo mkfs.ext4 -L USBDisk /dev/sdc1

Note: You can use analog commands (i.e., mkfs.exfat or mkfs.ntfs) to create other types of file systems.

Repair file system:

You can use the fsck command to repair corrupted file systems.

• To check and repair the filesystem, unmount the partition and run:

  # Check and repair the file system (Example for partition /dev/sdc1)
  sudo fsck.ext4 /dev/sdc1

Note: You can use analog commands (i.e., fsck.exfat or fsck.ntfs) to check or repair other types of file systems.

USB Disk mount:

Disk must be previously partitioned and file system created.

To mount a USB disk in /media directory:

• Find the disk and its UUID

  # List all disk devices and partitions
  sudo fdisk -l
  
  # Find disk UUID
  sudo blkid

Output example for /dev/sdc1:

  Output
  /dev/XXX: xxxxxxxxxxxxxxxxxxxxxxxxx
  /dev/sdc1: UUID="74530e5a-836c-4cf1-963a-2743b296349b" TYPE="ext4" PARTUUID="e7d880eb-f6a6-8648-bb80-21d8dc72b6e0"

• To mount interactively for the current session use the mount command (Example for /dev/sdc1):

  # Mount disk interactively
  sudo mount /dev/sdc1 /media

• To mount at system startup if present, you must update /etc/fstab in the following way (Example for UUID=...):

  # Update fstab to mount disk at startup
  sudo echo "UUID=74530e5a-836c-4cf1-963a-2743b296349b  /media  auto nosuid,nodev,nofail 0 0" | sudo tee -a /etc/fstab
  
  # Mount interactively if not mounted at startup
  sudo mount -a

Create data directory:

Note: As a best practice, you should create a data directory with sudoer user ownership for remote access, in the mounted file system to be referenced in scripts instead of the mounting point. (i.e. You should reference /media/data instead of /media).

• To create data directory and set ownership:

  # Create data directory
  sudo mkdir /media/data
  sudo chown -R {{ .machine.localadminusername }}:{{ .machine.localadminusername }} /media/data

USB Disk unmount:

• To unmount from /mediaand get the disk ready to unplug:

  # Unmount disk interactively
  sudo umount /media

USB Restic backup repository initialization

If you want to perform Restic backups in SFTP mode into USB removable disks, you must plug and mount a USB disk following the procedures in section Utilities > USB disk operations in this document.

Note: It is recommended to use at least 3 different backup USB disks and rotate them daily before backup time (Typically scheduled at night, between 0:00 and 6:00 hours). Every disk will contain the same backup retention and forget policy.

• Create a directory for restic repository under /mnt/data:

  # Create directory for restic repository
  # (Don't use sudo option here)
  mkdir /media/data/restic

• Initialize local Restic repository by running:

  # Initialize /srv/restic repository 
  # (Change password in cs-restic.sh if needed and keep it safe)
  sudo cs-restic.sh -m repo-init -r /media/data/restic

Reference

Scripts

cs-kvmserv

Purpose:
  KVM Services.
Usage:
  sudo cs-kvmserv.sh  [-l] [-m <execution_mode>] [-n <vmachine_name>]
                      [-p <vmachines_path>] [-i <cloud_image>]
                      [-s <vmachine_hd_size>] [-r <dvd_iso_file>] [-h] [-q]
Execution modes:
  -l  [list-status]       - List virtual machines and kvm server status.
  -m  <execution_mode>    - Valid modes are:
  
      [set-bridges]       - Create virtual bridges from brvlan file list.
                            Netplan bridges must have been created before.
      [set-stpools]       - Create storage pools from dirpool file list.
                            LVM Data service directory must have been created before.
      [vm-create]         - Create virtual machines from file list
                            or single machine if [-n ] is specified.
      [vm-delete]         - Delete virtual machines from file list
                            or single machine if [-n ] is specified.
      [vm-define]         - Define virtual machines in path [-p] 
                            or single machine if [-n ] is specified.
      [vm-undefine]       - Undefine virtual machines in path [-p] 
                            or single machine if [-n ] is specified.
      [vm-dumpcfg]        - Dump virtual machines xml configurations in path [-p] 
                            or single machine if [-n ] is specified.
      [vm-startall]       - Start all virtual machines with --autostart option defined.
      [vm-stopall]        - Stops all running virtual machines.
Options and arguments:
  -n  <vmachine_name>     - Virtual machine name. If set, single machine mode is used. If not, batch mode.
Options and arguments (Single machine creation mode):
  -p  <vmachines_path>    - Virtual machine path. Optional. If not set, default value in variable is used.
  -i  <cloud_image>       - Cloud image full path name Optional. Use "NONE" for no image (boot with blank disk. 
                            If not set, default value in variable is used.
  -s  <vmachine_hd_size>  - Virtual machine system HD size Optional. Use "NONE" for direct copy without resizing. 
                            If not set, default value in variable is used.
  -r  <dvd_iso_file>      - DVD iso file at startup. Required when booting from blank disk.
Options and arguments (General):
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # Apply virtual bridges:
    sudo cs-kvmserv.sh -m set-bridges
  
  # Apply storage pools:
    sudo cs-kvmserv.sh -m set-stpools
  # Create virtual machines in batch mode:
    sudo cs-kvmserv.sh -m vm-create 
  # Create virtual machine "srvtest" in single mode from default cloud image. 
  # Directory "srvtest" must exist in setup containing cloud values files):
    sudo cs-kvmserv.sh -m vm-create -n srvtest
  # Create virtual machine "srvtest" in single mode from blank disk and DVD setup. 
  # Directory "srvtest" must exist in setup containing cloud values files):
    sudo cs-kvmserv.sh -m vm-create -n srvtest -i NONE \
      -r /srv/setup/OPNsense-20.7-OpenSSL-dvd-amd64.iso
  # Delete virtual machines in batch mode:
    sudo cs-kvmserv.sh -m vm-delete
  # Delete virtual machine "srvtest" in single mode:
    sudo cs-kvmserv.sh -m vm-delete -n srvtest
  # Define virtual machines in a path from xml config files:
    sudo cs-kvmserv.sh -m vm-define -p /srv/vmachines
  # Define virtual machine srvtest from xml config file:
    sudo cs-kvmserv.sh -m vm-define -p /srv/vmachines -n srvtest
  # Undefine virtual machines in a path from xml config files:
    sudo cs-kvmserv.sh -m vm-undefine -p /srv/vmachines
  # Undefine virtual machine srvtest:
    sudo cs-kvmserv.sh -m vm-undefine  -n srvtest
  # Update xml dump of virtual machines in a path:
    sudo cs-kvmserv.sh -m vm-dumpcfg -p /srv/vmachines
  # Dump xml configuration file of virtual machine "srvtest" in path /srv/vmachines
    sudo cs-kvmserv.sh -m vm-dumpcfg -n srvtest -p /srv/vmachines
  # Start all virtual machines with --autostart option defined
    sudo cs-kvmserv.sh -m vm-startall
  # Stop all running virtual machines
    sudo cs-kvmserv.sh -m vm-stopall

Tasks performed:

cs-volgroup

Purpose:
  Disk volume group management.
  Use this script to create and delete volume groups
  from one or several disk devices.
  Each volume group will have a thin-pool associated to hold
  data services that will be created with the script "cs-lvmserv.sh".
Usage:
  sudo cs-volgroup.sh [-l] [-m <execution_mode>] [-d  <block_dev_names>]
                      [-v <vg_name>] [-h] [-q]
Execution modes:
  -l  [list-status]     - List volume group and disk status.
  -m  <execution_mode>  - Valid modes are:
  
      [create]          - Create volume group and thin pool.
      [delete]          - Delete volume group and erase disks.
Options and arguments:  
  -d  <block_dev_names> - Disk device names to be added into volume group.
                          (Array quoted list and space separated values)
                          (Optional. Default value)
  -v  <vg_name>         - Volume group name. (Optional. Default value)
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # List current status
    sudo cs-volgroup.sh -l
  # Create volume group with default variable values 
    sudo cs-volgroup.sh -m create
  # create volume group with name "ssd"
  # from disk devices "/dev/sdb /dev/sdc /dev/sdd"
    sudo cs-volgroup.sh -m create -d "/dev/sdb /dev/sdc /dev/sdd" -v ssd

Tasks performed:

cs-lvmserv

Purpose:
  LVM data services.
  Use this script to create or delete directory data services with independent 
  thin logical volumes suitable for snapshot operations.
  A volume group and thin-pool must have been created before using the 
  script "cs-volgroup.sh".
Usage:
  sudo cs-lvmserv.sh  [-l] [-m <execution_mode>]
                      [-d <data_path>] [-v <vg_name>] [-h] [-q]
Execution modes:
  -l  [list-status]     - List status of existing logical volumes.
  -m  <execution_mode>  - Valid modes are:
  
      [create]          - Create data service.
                          (Thin logical volume + directory mount)
      [delete]          - Delete data service.
                          (Thin logical volume + directory mount)
      [snap-create]     - Create snapshot and mount to read-only directory.
      [snap-remove]     - Remove snapshot and unmount from read-only directory.
      [snap-merge]      - Roll back logical volume to snapshot status
                           and discard all changes.
      [trim-space]      - Free space inside thin-pools
                          discarding unused blocks on all mounted filesystems.
Options and arguments:  
  -d  <data_path>       - Data service directory path.
                          (Thin LV will be mounted on it)
  -v  <vg_name>         - Volume group name. (Default value)
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # List logical volume status
    sudo cs-lvmserv.sh -l
  # Create thin logical volume data service "/srv/gitlab-postgresql"
  # in default volume group.
    sudo cs-lvmserv.sh -m create -d /srv/gitlab-postgresql
  # Create snapshot of data service "/srv/gitlab-postgresql"
  # in default volume group.
  # Snapshot will be mounted read-only in /tmp/gitlab-postgresql_snap
    sudo cs-lvmserv.sh -m snap-create -d /srv/gitlab-postgresql
  # Remove snapshot of data service "/srv/gitlab-postgresql"
  # in default volume group
    sudo cs-lvmserv.sh -m snap-remove -d /srv/gitlab-postgresql
  # Merge snapshot of data service "/srv/gitlab-postgresql"
  # in default volume group
    sudo cs-lvmserv.sh -m snap-merge -d /srv/gitlab-postgresql
  # Delete thin logical volume data service "/srv/gitlab-postgresql"
  # in default volume group
    sudo cs-lvmserv.sh -m delete -d /srv/gitlab-postgresql
  # Free space inside thin-pools
    sudo cs-lvmserv.sh -m trim-space

Tasks performed:

cs-rsync

Note: Prior to operate rsync with a remote host, you must insert the root public key for ssh authentication and passwordless login as sudoer user in the remote host. From a console inside the machine you must run sudo ssh-copy-id {{ .machine.localadminusername }}@hostname.domain.com

Purpose:
  RSync copies for LVM data services.
  Use this script to perform RSync operations with data services supported by
  thin-logical volumes created with the script "cs-lvmserv.sh".
  Snapshots will be created automatically for rsync-to copies 
  and removed when finished.
Usage:
  sudo cs-rsync.sh  [-m <execution_mode>] [-d <data_path>] [-v <vg_name>] 
                    [-r <remote_data_path>] [-t <hostname.domain.com>] [-h] [-q]
Execution modes:
  -m  <execution_mode>  - Valid modes are:
      [rsync-to]        - RSync data from local directory TO remote directory.
      [rsync-from]      - RSync data FROM remote directory to local directory.
Options and arguments:  
  -d  <data_path>           - Local data service directory path.
  -v  <vg_name>             - Volume group name. (Default value)
  -r  <remote_data_path>    - Remote directory path. (Default is same as local)
  -t  <hostname.domain.com> - Backup host (Default value)
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # RSync data service "/srv/gitlab-postgresql"
  # TO same remote directory at host "bckpoint.cskylab.com"
    sudo cs-rsync.sh -m rsync-to -d /srv/gitlab-postgresql \
    -t bckpoint.cskylab.com
  # RSync data service "/srv/gitlab-postgresql"
  # FROM remote directory "/srv/gitlab-postgresql" at host "bckpoint.cskylab.com"
    sudo cs-rsync.sh -m rsync-from -d /srv/gitlab-postgresql \
    -t bckpoint.cskylab.com

Tasks performed:

cs-restic

Purpose:
  Restic backup for LVM data services.
  Use this script to perform Restic operations with data services supported by
  thin-logical volumes created with the script "cs-lvmserv.sh".
  Snapshots will be created automatically for backups and removed when finished.
Usage:
  sudo cs-restic.sh [-m <execution_mode>] [-d <data_path>] [-v <vg_name>] [-t <tag_name>] 
                    [-r <RESTIC_REPOSITORY>] [-i <restic_snap_id>]
                    [-p <RESTIC_PASSWORD>] [-a <AWS_ACCESS_KEY_ID>]
                    [-k <AWS_SECRET_ACCESS_KEY>] [-f <forget_options>] [-h] [-q]
Execution modes:
  -m  <execution_mode>   - Valid modes are:
  
      [restic-bck]       - Backup to local or remote repository.
      [restic-list]      - List snapshots in repository.
      [restic-mount]     - Mount repository to /mnt directory.
      [restic-res]       - Restore from repository to directory data service.
                           (Directory must be empty).
      [repo-init]        - Initialize repository (Directory or bucket must exist).
      [restic-forget]    - Maintain repository and remove snapshots with forget option.
Options and arguments:  
  -d  <data_path>             - Local data service directory path. (Mandatory)
  -v  <vg_name>               - Volume group name. (Default value)
  -t  <tag_name>              - Tag name for the snapshot. (Default value)
  -r  <RESTIC_REPOSITORY>     - Restic repository (Default value)
  -i  <restic_snap_id>        - Snapshot ID to restore (Default latest)
  -p  <RESTIC_PASSWORD>       - Restic password (Default value)
  -a  <AWS_ACCESS_KEY_ID>     - S3 access key (Default value)
  -k  <AWS_SECRET_ACCESS_KEY> - S3 secret key (Default value)
  -f  <forget_options>        - Options to execute (Default value)
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # Backup data service "/srv/gitlab-postgresql"
  # TO local repository "/srv/restic/gitlab-postgresql/" 
    sudo cs-restic.sh -m restic-bck -d /srv/gitlab-postgresql \
                                  -r "/srv/restic/gitlab-postgresql/"
  # Backup data service "/srv/gitlab-postgresql"
  # TO remote sftp repository "sftp:kos@backup.cskylab.com:/srv/restic/gitlab-postgresql/" 
    sudo cs-restic.sh -m restic-bck -d /srv/gitlab-postgresql \
                                  -r "sftp:kos@backup.cskylab.com:/srv/restic/gitlab-postgresql/"
  # Backup data service "/srv/gitlab-postgresql" tagged "gitlab-postgresql"
  # TO shared repository in MinIO bucket "s3:https://minio-standalone.cskylab.com/restic-test/" 
    sudo cs-restic.sh -m restic-bck -d /srv/gitlab-postgresql \
                                  -t gitlab-postgresql -r "s3:https://minio-standalone.cskylab.com/restic-test/"
  # List snapshots in repository "s3:https://minio-standalone.cskylab.com/restic-test/" 
    sudo cs-restic.sh -m restic-list -r "s3:https://minio-standalone.cskylab.com/restic-test/"
  # Restore data service "/srv/gitlab-postgresql"
  # FROM latest snapshot in repository "/srv/restic/gitlab-postgresql" 
    sudo cs-restic.sh -m restic-res -d /srv/gitlab-postgresql \
                                  -r "/srv/restic/gitlab-postgresql"
  # Create repository in directory "/srv/restic/gitlab-postgresql"
    sudo cs-restic.sh -m repo-init -r "/srv/restic/gitlab-postgresql"
  # Maintain repository "/srv/restic/gitlab-postgresql" applying host, tag and forget options
    sudo cs-restic.sh -m restic-forget -r "/srv/bck/gitlab-postgresql" \
              -t "gitlab-postgresql" -f "--keep-hourly 6 --keep-daily 31 --keep-weekly 5 --keep-monthly 13 --keep-yearly 10"
  # Mount repository "/srv/bck/gitlab-postgresql"   
  # in /mnt directory
    sudo cs-restic.sh -m restic-mount -r "s3:https://minio-standalone.cskylab.com/restic-test/"

Tasks performed:

cs-deploy

Purpose:
  Machine installation and configuration deployment.
  This script is usually called by csinject.sh when executing Inject & Deploy
  operations. Exceptionally, it can also be run manually from inside the machine.
Usage:
  sudo cs-deploy.sh [-m <execution_mode>] [-h] [-q]
Execution modes:
  -m  <execution_mode>  - Valid modes are:
  
      [net-config]      - Network configuration. (Reboot when finished).
      [install]         - Package installation, updates and configuration tasks (Reboot when finished).
      [config]          - Redeploy config files and perform configuration tasks (Default mode).
Options and arguments:  
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # Deploy configuration in [net-config] mode:
    sudo cs-deploy.sh -m net-config
  # Deploy configuration in [install] mode:
    sudo cs-deploy.sh -m install
  # Deploy configuration in [config] mode:
    sudo cs-deploy.sh -m config

Tasks performed:

cs-inject

Note: This script runs from the "DevOps Computer", opening a terminal from the machine configuration directory in the management repository,.

Purpose:
  Inject & Deploy configuration files into remote machine.
  This script runs from the management (DevOps) computer, copying all configuration
  files to the remote machine, and calling the script 'cs-deploy.sh' to run from
  inside the remote machine if 'deploy' mode [-d] is selected.
Usage:
  ./csinject.sh [-k] [-i] [-d] [-m <deploy_mode>] [-u <sudo_username>] [-r <remote_machine>] [-h] [-q]
Execution modes:
  -k  [ssh-sudoers] - install ssh key and sudoers file into the machine. Required before other actions.
  -i  [inject]      - Inject only. Inject configuration files into the machine for manual deployment.
  -d  [deploy]      - Inject & Deploy configuration. Calls 'cs-deploy.sh' to run from inside the machine.
Options and arguments:  
  -m  <deploy_mode>       - Deploy mode passed to 'cs-deploy.sh'. Valid modes are:
      [net-config]        - Network configuration. (Reboot when finished).
      [install]           - Package installation, updates and configuration tasks (Reboot when finished).
      [config]            - Redeploy config files and perform configuration tasks (Default mode).
  
  -u  <sudo_username>     - Remote administrator (sudoer) user name (Default value).
  -r  <remote_machine>    - Machine hostname or IPAddress (Default value).
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # Copy ssh key and sudoers file into the machine:
    ./csinject.sh -k
  # Inject & Deploy configuration in [net-config] mode:
    ./csinject.sh -dm net-config
  # Inject & Deploy configuration in [install] mode:
    ./csinject.sh -dm install
  # Inject & Deploy configuration in [config] mode (default):
    ./csinject.sh -d

Tasks performed:

cs-connect

Note: This script runs from the "DevOps Computer", opening a terminal from the machine configuration directory in the management repository,.

Purpose:
  SSH remote connection.
  Use this script to remote login into the machine and establish a ssh session.
Usage:
  csconnect.sh [-u <sudo_username>] [-r <remote_machine>] [-h]
Options and arguments:  
  -u  <sudo_username>   - Remote user name (Default value).
  -r  <remote_machine>  - Machine hostname or IPAddress (Default value).
  -h  Help
Examples:
  # Connect to the machine with default values
    ./csconnect.sh
  # Connect to IPAddress with specific user
    ./csconnect.sh -u sudo_username -r 192.168.2.99

Tasks performed:

cs-helloworld

Purpose:
  Sequential block script model.
  Use this script as a model or skeleton to write other configuration scripts.
Usage:
  sudo cs-helloworld.sh [-l] [-m <execution_mode>] [-n <name>] [-h] [-q]
Execution modes:
  -l  [list-status]     - List current status.
  -m  <execution_mode>  - Valid modes are:
      [install]         - Install.
      [remove]          - Remove.
      [update]          - Update and reconfigure.
Options and arguments:  
  -n <name>             - Name of the person to report status.
                          (Optional in list-status. Default value) 
  -h  Help
  -q  Quiet (Nonstop) execution.
Examples:
  # Mode "install":
    sudo cs-helloworld.sh -m install
  # Mode "remove":
    sudo cs-helloworld.sh -m remove
  # Mode "list-status":
    sudo cs-helloworld.sh -l
  # Mode "list-status" with special name to report:
    sudo cs-helloworld.sh -l -n Bond

Tasks performed:

License

Copyright © 2021 cSkyLab.com ™

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.