Using the SVM first startup script

An SVM supports the use of a first startup script to run configuration commands. It is recommended to use an SVM first startup script to perform the following tasks:

• Configure the network settings of SVMs when using static IP addressing. You can use the following commands: network, dns, manageservices (to restart the network service).
• Configure authorization by SSH key for accessing an SVM without the klconfig account password (configuration password). The setsshkey command is provided for this purpose.

It is not recommended to use a long list of commands because the first startup script is intended for performing a minimal set of commands.

Commands using the standard input stream, for example, passwd, should not be sent to the first startup script. This leads to the inability to start the SVM.

To send commands to the first startup script, you need to specify them in the following format:

KL_CMD1="<command1>" KL_CMD2="<command2>" … KL_CMDn="<commandN>"

where <command> – name of the command, with parameters (if necessary).

For example, the following sequence of commands lets you configure SVM network settings when using static IP addressing:

KL_CMD1="network eth0 10.65.78.35 255.255.255.0 10.65.78.255 10.65.78.1" KL_CMD2="manageservices restart network"

While the first startup script is being run, commands are numbered and executed in the order in which they were sent to the first startup script.

After the script is executed, the file named boot_config.log containing the script execution results is created in the folder /var/log/kaspersky/la/.

You can use the following special commands when creating a first startup script:

• RESET – delete the boot_config_done file (an indicator that the first startup script has already been executed). As a result, all commands sent to the first startup script will also be executed the next time the SVM is started.
• ALWAYS – execute the commands following this command even if the SVM first startup script has already been executed (the boot_config_done file is present).
• REPORT – write information about the command execution results to a file.

For example:

KL_CMD1="ALWAYS" KL_CMD2="network eth0 10.65.78.35 255.255.255.0 10.65.78.255 10.65.78.1"

The mechanism used to send commands to the first startup script depends on the type of hypervisor:

• Citrix Hypervisor (Citrix XenServer): first startup commands can be added to the kernel command line in the following format:

  KL_CMD1="…" KL_CMD2="…"

• Microsoft Windows Server (Hyper-V) hypervisor: uses a system of exchanging key-value pairs (for details, please refer to the Microsoft documentation).
• VMware ESXi hypervisor: first startup commands can be conveyed in one of the following ways:
  • In a VMX configuration file
  • In the VMware vSphere Web Client Console: Edit Settings/Options/Advanced/General/Configuration Parameters
  • Using the vmware-cmd setguestinfo command

  First startup commands must be specified in the following format:

  guestinfo.klfirstboot.cmd1

  guestinfo.klfirstboot.cmd2

• KVM hypervisor: commands may be inserted into the file /opt/kaspersky/la/bin/kvm_first_boot_args in string format:

  KL_CMD1="…" KL_CMD2="…"

• Proxmox VE hypervisor: commands may be inserted into the file /var/opt/kaspersky/la/patches/default_patch_index/bin/kvm_first_boot_args in the following format:

  KL_CMD0=%command1%

  KL_CMD1=%command2%

• R-Virtualization hypervisor: uses the QEMU guest agent utility that lets you execute commands under the root account:

  POST /api/0/vm/%vm_id%/execute

  In the request body:

  command_with_args=[ "bash", "-c", "%command%" ]

Page top