Appendices

This section provides information that complements the primary text of the document.

Using the klconfig script API to define SVM configuration settings

The main resource for deploying and configuring an SVM is the SVM Management Wizard, which you can run from the Integration Server Console.

You can also perform initial configuration of new SVMs and change the configuration settings of previously deployed SVMs using the klconfig script API manually or by means of automation tools.

If the SVM Management Wizard is not used, the SVM deployment procedure consists of the following stages (the sequence and number of stages depends on the type of virtual infrastructure):

1. SVM deployment using virtual infrastructure tools from the image included in the Kaspersky Security distribution kit, and configuration of SVM system resources.
2. Configuring an SVM first startup script. To configure certain SVM configuration settings, you can use a script that is started when the SVM is started for the first time.
3. Starting the SVM. At this step, the SVM receives an IP address.
4. Assigning SVM configuration settings and checking the success of SVM deployment using configuration commands.

You can also use configuration commands to change the configuration settings of previously deployed SVMs.

Executing configuration commands

Configuration commands are executed over SSH using the klconfig account.

To execute a command, enter the following into the command line:

ssh klconfig@<SVM address> <command>

where:

• <SVM address> – IP address of the SVM or localhost if the command is run on an SVM.
• <command> – command, with parameters (if necessary).

Each command requires entry of the klconfig account password (configuration password) if you have not configured authorization by SSH key for accessing the SVM without a password (the setsshkey command).

Certain commands require additional interactive entry of data. For example, the passwd command requires entry of a new user password.

Each command displays the result of its execution in the following format:

• KLCONFIG OK – if the command was executed successfully.
• KLCONFIG FAILED – if an error occurred during execution of the command.

Certain commands may provide additional information about an error in the following format:

ERROR:<NNNN error description>

where <NNNN error description> is the digital error code and text description. Some errors may not contain a digital code.

For example, executing the connectorlang command without parameters for an SVM with the IP address 10.16.98.17 returns an error message and a message about how to use the command (the lang parameter is required):

> ssh klconfig@10.16.98.17 connectorlang

> klconfig@10.16.98.17’s password:

Usage: connectorlang lang

KLCONFIG FAILED

Result of execution of the same command with the correct parameters:

> ssh klconfig@10.16.98.17 connectorlang en

> klconfig@10.16.98.17’s password:

KLCONFIG OK

The result of execution of each command is written to the file results.log located in the folder /var/opt/kaspersky/klconfig/.

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="<command 1>" KL_CMD2="<command 2>" … KL_CMDn="<command N>"

where <command> is the 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:

• XenServer hypervisor: 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%" ]

Configuring SVM configuration settings

Initial configuration of an SVM using configuration commands consists of the following steps:

1. Modify the SVM name (the hostname command).
2. For each network interface of the SVM:
   • Allow the use of DHCP if dynamic IP addressing is used (the dhcp command).
   • Configure the network settings of the SVM if static IP addressing is used (the network command).
3. Configure DNS settings if static IP addressing is used (the dns command).
4. Configure the settings for connecting the SVM to Kaspersky Security Center Administration Server: address and ports (the nagent command).
5. Initial configuration of the Protection Server (the productinstall command).
6. Accept Kaspersky Security End User License Agreement and the Privacy Policy (the accept_eula_and_privacypolicy command or the accept_eula_and_privacypolicy setting in the ScanServer.conf configuration file).

   You must accept the terms of the End User License Agreement and the Privacy Policy for the proper SVM operation.

7. Start the Protection Server (the manageservices start scanserver command).

In addition, you can configure the following SVM configuration settings:

• Select the language of Kaspersky Security Center Network Agent Connector (the connectorlang command).
• Change the configuration password and root account password that were defined by default (the passwd klconfig and passwd root commands).
• Allow or deny access to the SVM over SSH under the root account.

After initial configuration of the SVM is completed, it is recommended to make sure that the SVM is deployed and configured successfully. To do so, you can use the checkconfig command.

Description of commands

This section contains a description of the configuration commands.

accept_eula_and_privacypolicy

This command allows you to accept or decline the terms of Kaspersky Security End User License Agreement between you and Kaspersky and the Privacy Policy that describes processing and transmission of data.

You must accept the terms of the End User License Agreement and the Privacy Policy to install Protection Server. The text of the End User License Agreement and Privacy Policy is included in the Kaspersky Security distribution kit.

Settings

<acceptFlag> = yes|no – possible values:

• yes – accept the terms of the End User License Agreement and the Privacy Policy.
• no – do not accept the terms of the End User License Agreement and the Privacy Policy.

By setting this parameter to yes, you confirm the following:

• You have fully read, understood and accept the terms and conditions of the Kaspersky Security End User License Agreement.
• You have fully read and understood the Privacy Policy, you are aware and agree that your data will be handled and transmitted (including to third countries) as described in the Privacy Policy.

Specific errors

None.

apiversion

This command displays the current version of the klconfig script API.

Settings

None.

Specific errors

None.

Page top

checkconfig

This command lets you check if the configuration of one or multiple Kaspersky Security components is correct.

Settings

findsvm hv_connect network routing sc_connect

where:

• findsvm – check for the SVM in the list of virtual infrastructure objects (Inventory).
• hv_connect – check the connection between the SVM and the Integration Server and check for a list of virtual infrastructure objects (Inventory).
• network – check the network configuration.
• permitrootlogin — check whether the root account is allowed to gain access to the SVM over SSH.
• routing – check network routing.
• sc_connect – check the connection to Kaspersky Security Center.

You can specify one or multiple parameters.

Specific errors

The command always returns KLCONFIG, even if an error was detected. For this reason, it is recommended to always pay attention to errors when analyzing the output.

0001 Hostname is not set or contains invalid data. The domain name of the SVM is not set or contains an invalid value, for example, LightAgentSVM, localhost or localdomain. Use the hostname command to define the domain name of the SVM.

0002 Could not get hostname FQDN. Failed to receive the fully qualified domain name (FQDN) of the SVM. Check the SVM name and DNS settings.

0003 Could not find the host interface IP address. The IP address of the network interface eth0 is not found or is not configured.

0004 Host interface IP address <host IP> does not match DNS <DNS IP of hostname>. The IP address associated with the primary network interface does not match the IP address returned for the domain name of the SVM in the DNS PTR entry.

0010 Could not find the default route. A default network route is not configured.

0011 Cannot ping the default route address. Failed to verify the default network route using the ping command. Check the network settings.

0030 Inventory is not valid. The list of virtual infrastructure objects (Inventory) is empty or contains invalid values. Make sure that the SVM has received a policy with the correct Integration Server address. Use the checkconfig sc_connect command to make sure that the SVM is connected to Kaspersky Security Center.

0060 Could not get the UUID of the SVM. Failed to receive a unique ID (BIOS ID) for the SVM.

0061 Could not find our self in the inventory. Failed to detect the unique ID of the SVM in the list of virtual infrastructure objects (Inventory). Check the Integration Server settings.

0062 Could not find host in inventory path. Failed to detect information about the hypervisor on which an SVM is deployed in the list of virtual infrastructure objects (Inventory). Check the Integration Server settings.

0070 klnagchk reported failure. The klnagchk command returned an error. Analyze the additional error messages.

0071 Could not verify klnagent settings. Cannot verify the settings of the Kaspersky Security Center Network Agent. Kaspersky Security Center Network Agent is not configured or is configured incorrectly.

0072 Could not connect to the Kaspersky Security Center Server. Kaspersky Security Center Network Agent cannot connect to the Kaspersky Security Center Administration Server. Check the settings of Kaspersky Security Center Network Agent and make sure that the network is configured correctly.

0073 Could not connect to the klnagent administration agent. Failed to connect to Kaspersky Security Center Network Agent. Possibly, Kaspersky Security Center Network Agent is not running on the SVM.

0074 Could not get the klnagent administration agent statistics. Kaspersky Security Center Network Agent cannot obtain Administration Server statistics. Kaspersky Security Center Network Agent on the SVM is operating incorrectly.

0100 Could not look up <address> in DNS. The domain name or IP address is not found. Check the DNS settings.

0101 Look up of <address> returned no DNS data. The DNS search returned no data. The DNS server responded, but the relevant types of entries were not detected.

0110 Host to IP to host is not equal in DNS. An error occurs when a DNS check is looped: a search is run for the IP address based on the domain name, and then a search for the domain name based on this IP address returns a name that is different from the original name.

connectorlang

This command lets you define the language of Kaspersky Security Center Network Agent Connector in the configuration file /etc/opt/kaspersky/la/ScanServer.conf. The Connector language affects the language of the events and errors sent to Kaspersky Security Center.

The new settings are applied after the Protection Server is restarted.

Settings

<lang> – language ID. Possible values:

• de – German.
• en – English.
• fr – French.
• ja – Japanese.
• ru – Russian.
• zh-Hans – Chinese (Simplified).
• zh-Hant – Chinese (Traditional).

Specific errors

None.

dhcp

This command lets you configure the use of DHCP for the network interface of the SVM.

The new settings are applied after the file /etc/resolv.conf is overwritten as a result of a restart of the SVM or network service (the manageservices restart network command).

If you want to change the IP address assignment method for SVMs using static IP addressing to the use of DHCP, sequentially execute the dns and dnssearch commands without parameters after the dhcp command. This lets you delete the previously configured list of DNS servers and search domains in the file /etc/resolv.conf.

If you want to add a DNS server or search domain to the list of DNS servers and search domains received over the DHCP protocol when using dynamic IP addressing, first restart the SVM or restart the network service (the manageservices restart network command). This lets you overwrite the file /etc/resolv.conf. Then execute the dns and dnssearch commands with the necessary parameters.

Settings

<InterfaceName> [<MakePrimary>]

where:

• <InterfaceName> – name of the network interface. For example, eth0.
• <MakePrimary> = yes|no – indicator of whether it is the primary network interface (optional parameter). Possible values:
  • yes – network interface is primary.
  • no – network interface is not primary.

The primary network interface sets the default route and DNS servers (DEFROUTE = yes, PEERDNS = yes). Only one network interface from those utilized by an SVM may be primary. If the "primary" indicator is assigned to multiple network interfaces, the last one of them becomes the primary network interface.

Specific errors

None.

dhcprenew

This command lets you renew and continue the lease of an IP address for the network interface on the DHCP server.

Depending on the specifics of the virtual infrastructure in which the SVM is running, command execution may result in modification of the IP address and termination of network connections.

You can use this command to let the DHCP server accept the new name of the SVM.

Settings

<InterfaceName> – name of the network interface of the SVM. For example, eth0.

Specific errors

0140 Failed to release dhcp. Failed to release the IP address for the specified network interface on the DHCP server.

0141 Failed to request a new lease. Failed to receive a new IP address lease for the specified network interface on the DHCP server.

dns

This command lets you define a list of DNS servers that will be used in the specified order in the file /etc/resolv.conf. The previously configured list of DNS servers is deleted.

If you are also planning to configure the use of DHCP (the dhcp command), execute the dns command after the dhcp command is executed and after the SVM is restarted or the network service is restarted (the manageservices restart network command).

As a result of execution of the dns command, the list of search domains in the file /etc/resolv.conf is deleted. If you are planning to configure a list of search domains, execute the dnssearch command after the dns command.

Settings

[<Server1>] [<Server2>] [<Server3>]

where <Server> is the IP address of the DNS server (optional parameter). You can specify up to three IP addresses.

If the command is executed without parameters (no address is specified), all nameserver entries in the file /etc/resolv.conf are deleted.

Specific errors

None.

dnslookup

This command lets you receive an IP address from the DNS server based on the domain name, or vice versa (analogous to the host command in Linux). The command returns only the first entry.

You can also use this command to verify that DNS is operating correctly.

Settings

<HostNameOrIpAddress> – domain name or IP address.

Specific errors

None.

dnssearch

This command lets you define a list of search domains that are used to determine domain names for name resolution in the file /etc/resolv.conf. The previously configured list of search domains is deleted.

If you are also planning to configure a list of DNS servers (the dns command), execute the dnssearch command after the dns command because the dns command will cause the list of search domains in the file /etc/resolv.conf to be deleted.

Settings

[<Domain1>] [<Domain2>] [<Domain3>]

where:

<Domain> – name of the search domain (optional parameter). You can specify up to three domains.

If the command is executed without parameters (no domain is specified), all search entries in the file /etc/resolv.conf are deleted.

Specific errors

None.

dnsshow

This command lets you view information about DNS settings from the file /etc/resolv.conf.

The command returns all entries in one string, separated by a space. If an empty string is returned, the DNS settings are not configured.

Settings

<InfoKind> = nameservers|search – type of information that you want to view. Possible values:

• nameservers – display the list of DNS servers.
• search – display the list of search domains.

Specific errors

None.

getdnshostname

The command returns the domain name corresponding to the IP address of the primary network interface.

Settings

None.

Specific errors

0100 Could not look up <IP> in DNS. Failed to find the IP address. Check the DNS settings.

gethypervisordetails

The command allows to receive information about the SVM path. One of the following values is returned depending on type of the virtual infrastructure:

• For virtual infrastructures based on Microsoft Hyper-V, XenServer, VMware vSphere, KVM, Proxmox VE, Basis, Skala-R, HUAWEI FusionSphere, Nutanix Acropolis, Alt Virtualization Server, Astra Linux or Numa vServer – the IP address or fully qualified domain name (FQDN) of the hypervisor on which the SVM is deployed.
• For virtual infrastructures running on the OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform – IP address or fully qualified domain name (FQDN) of the Keystone microservice that manages the OpenStack project within which the SVM is deployed.

Information is available only after the SVM is connected to the Integration Server whose connection settings are specified in the Protection Server policy applied on the SVM.

Settings

address or all – return name or address of the hypervisor, on which the SVM is running, or name or address of the Keystone microservice that manages the OpenStack project, within which the SVM is deployed.

Specific errors

0060 Could not get the UUID of the SVM. Failed to receive the unique ID of the SVM (BIOS ID).

0061 Could not find our self in the inventory. The unique ID of the SVM is not found in the list of virtual infrastructure objects (Inventory). Check the Integration Server settings.

0062 Could not find host in inventory path. The list of virtual infrastructure objects (Inventory) does not contain information about the hypervisor on which the SVM is running, or about the Keystone microservice that manages the OpenStack project, within which the SVM is deployed. Check the Integration Server settings.

hostname

This command lets you define the domain name of the SVM and make sure that the IP address and domain name of the SVM are in the file /etc/hosts.

Settings

<hostname> [<IP>]

where:

• <hostname> – domain name of the SVM.
• [<IP>] – IP address of the SVM (optional parameter).

Specific errors

0120 Invalid hostname characters <characters>. Invalid characters in the SVM name.

0121 Invalid hostname, empty label present. The SVM name contains an empty section.

listpatches

This command lets you generate an XML list of Kaspersky Security application module updates installed on SVMs.

The XML file has the following format:

<?xml version="1.0" encoding="UTF-8"?>

<patches>

<patch>

<id>patchId</id>

<sha_256>checkSum</sha_256>

<status>status</status>

<patch_type>type</patch_type>

<version>productTargetVersion</version>

<description><![CDATA[description]]></description>

<status_changed_date>statusChangedDate</status_changed_date>

dependsOn

</patch>

<patch>

...

</patch>

...

</patches>

where:

• patchId is an identifier of the Kaspersky Security module update.
• checkSum is a hash of the TGZ archive in HEX format.
• status is a module update installation status. Possible values:
  • installed: the module update was successfully installed.
  • failed: an error occurred.
  • rolledback: the module update was rolled back.
• type is a type of module update. Possible values:
  • auto: module update received with the update package from the Kaspersky Security Center Administration Server repository.
  • config: module update resulting from applying a configuration file.
  • custom: a special release of a module update.
• productTargetVersion is a version of the update.
• description is a description of the update.
• statusChangedDate is date and time of the status change.
• depensOn is an ID of the module update upon which this specific module update depends (optional parameter).

Settings

None.

Page top

manageservices

This command lets you start, stop, or restart the specified service.

Remotely stopping or restarting the network service may cause the connection to drop or hang. For this reason, two types of network service are provided: network_local and network. For the network_local service, the action is applied immediately (synchronous). It is recommended to use this type of service in the SVM first startup script. For the network service, the action is applied asynchronously (in a separate shell). Therefore, the klconfig script can return control. This means that the invoking side must check the command execution result in no less than 20 seconds.

Settings

<Action> <ServiceType1> [<ServiceType2>] [<ServiceType3>]

where:

• <Action> = start|stop|restart – type of action applied. Possible values:
  • start
  • stop
  • restart
• <ServiceType> – type of service. Possible values:
  • klnagent – Kaspersky Security Center Network Agent.
  • network – network service (asynchronous).
  • network_local – network service (synchronous).
  • scanserver – Protection Server.
  • sshd – SSH service.

Specific errors

None.

nagent

This command lets you set the address and ports for connecting an SVM to the Kaspersky Security Center Administration Server.

Settings

<Address> <SslPort> [<Port>]

where:

• <Address> – IP address or fully qualified domain name (FQDN) of the device on which the Kaspersky Security Center Administration Server is installed.
• <SslPort> – Number of the port for connecting an SVM to the Kaspersky Security Center Administration Server using an SSL certificate (13000 is recommended).
• <Port> – Port number for connecting an SVM to the Kaspersky Security Center Administration Server (14000 is recommended) (optional parameter).

Specific errors

None.

network

This command lets you configure static IP addressing and SVM network settings.

The new settings are applied after the SVM is restarted or the network service is restarted (the manageservices restart network command).

Settings

<InterfaceName> <IP> <NetMask> <Broadcast> [<GateWay>]

where:

• <InterfaceName> – name of the network interface, for example, eth0.
• <IP> – IP address of the network interface that you want to assign.
• <NetMask> – network mask.
• <Broadcast> – broadcast address.
• <GateWay> – gateway address (optional parameter). It should be set only on one network interface that uses DHCP.

Specific errors

None.

ntp

This command lets you assign an NTP server and make sure that it is running.

Settings

<ServerName> – fully qualified domain name (FQDN) or IP address of the NTP server.

Specific errors

None.

passwd

This command lets you change the password for the specified account.

Passwords must be no longer than 60 characters. You can use only letters of the Latin alphabet (uppercase and lowercase letters), numerals, and the following special characters: ! # $ % & ' ( ) * " + , - . / \ : ; < = > _ ? @ [ ] ^ ` { | } ~. For security purposes, you are advised to set passwords that are at least 8 characters long and use at least three of the four categories of characters: lowercase letters, uppercase letters, numerals, and special characters.

The password is read from the standard input stream of the SSH connection without an invitation.

Settings

<UserName> – name of the account for which you need to create a password.

Specific errors

0130 Invalid password. Invalid password.

permitrootlogin

The command allows or denies access to the SVM over SSH under the root account

The new settings are applied after the SVM is restarted or the SSH service is restarted (the manageservices restart sshd command).

Settings

<AllowOrNot> = yes|no – possible values:

• yes — allow access to the SVM over SSH under the root account.
• no — deny access to the SVM over SSH under the root account.

  Example: > ssh klconfig@10.16.98.17 permitrootlogin yes > klconfig@10.16.98.17’s password: Permit root login = yes KLCONFIG OK

Specific errors

None.

productinstall

This command lets you perform various one-time tasks for Protection Server installation, such as configuring the installation ID.

You can execute a command more than once consecutively.

The new settings are applied after the SVM is restarted or the scanserver service is restarted (the manageservices restart scanserver command).

Settings

None.

Specific errors

None.

reboot

This command lets you restart the SVM in one minute.

Settings

None.

Specific errors

None.

resetnetwork

This command lets you return all network settings to their default values, including DNS settings and the settings of network interfaces. This means that DHCP will be used with the first network interface as the primary network interface for the SVM.

You can use this command to reset network settings to their original state before SVM configuration settings were changed.

The new settings are applied after the SVM is restarted or the network service is restarted (the manageservices restart network command).

Settings

None.

Specific errors

None.

rollbackpatch

This command lets you roll back the last update of the Kaspersky Security modules on SVMs.

Settings

[Patchid] is an ID of the Kaspersky Security module update (optional parameter). If no ID is specified, the last installed module update will be determined automatically.

Specific errors

None.

setsshkey

This command lets you configure authorization by SSH key for accessing an SVM without the klconfig account password (configuration password). As a result of command execution, the specified key (text in Base64 encoding) is added to the authorized SSH key file. The key is valid for 2 hours.

You can use this command in the SVM first startup script for configuring access to the SVM prior to setting the configuration password.

Settings

<Base64EncodedAuthorizationKeyEntry> – key (text encoded in 64-bit code without spaces).

Specific errors

0160 Could not decode key. Make sure that the key is correctly encoded and does not contain spaces.

settracelevel

This command lets you configure the trace level for the Protection Server (ScanServer.log).

The trace level is changed immediately if the <Immediately>=yes parameter is set. Otherwise, the change occurs after a restart of the SVM or Protection Server (the manageservices restart scanserver command).

Settings

<TraceLevel> [<Immediately>]

where:

• <TraceLevel> is a numerical value that determines the trace level. Possible values:
  • 0: creation of trace files is disabled.
  • 100: informational messages about the Protection Server components being started and stopped.
  • 200: messages about critical errors in the Protection Server operation.
  • 300: messages about errors and critical errors in the Protection Server operation.
  • 400: critical warnings and messages about ordinary and critical errors.
  • 500: all warnings and messages about ordinary and critical errors.
  • 600: important messages, all warnings and messages about ordinary and critical errors.
  • 700: informational messages, important messages and all warnings and messages about ordinary and critical errors.
  • 800: debugging messages and all informational and important messages, as well as all warnings and messages about ordinary and critical errors.
  • 900: debugging messages with more detailed information and all informational and important messages, as well as all warnings and messages about ordinary and critical errors.
  • 1000: all possible messages and warnings.
• <Immediately> = yes|no is an indicator determining when the new trace level settings should be applied (optional parameter). Possible values:
  • yes: apply immediately.
  • no: apply after restart of the SVM or the scanserver service (the manageservices restart scanserver command).

Specific errors

0150 Could not update <configfile>. Failed to update the configuration file /etc/opt/kaspersky/la/ScanServer.conf. Make sure that the file exists and is accessible.

test

This command returns information about an SVM.

You can use this command for SVM operability validation.

Settings

None.

Specific errors

None.

timezone

This command lets you set the time zone for an SVM.

This change is applied after the SVM is restarted.

Settings

<TimeZoneName> – name of the time zone in Linux format.

Specific errors

None.

version

This command returns the SVM version.

Settings

None.

Specific errors

None.

Settings in the ScanServer.conf file

The ScanServer.conf file contains the SVM operation settings. The file is located on the SVM in the /etc/opt/kaspersky/la/ directory.

Root account permissions are required to view and modify the file.

This section describes the settings in the ScanServer.conf file that allow you to configure logging of the SVM traces and dumps, usage of the SVM system log, and agree to the terms of the End User License Agreement. Information about other settings, if necessary, can be obtained from the Technical Support.

Unassisted modification of the Kaspersky Security operation settings in the ways not described in the Kaspersky Security help or in the recommendations from the Technical Support specialists can lead to slowdowns and malfunctions of the operating system, decrease of the virtual machine protection level, as well as to a violation of the availability and integrity of the processed information.

Expand all | Collapse all

General settings

[rotation_settings] section

[extra_tracing] section

[syslog] section

[dumps] section

Object ID values for SNMP

The table presents the values and descriptions of object identifiers (OID) that are used to transfer information about the SVM state.

Values and descriptions of OID settings for SNMP

Page top

How to remove duplicate virtual machines from the list of managed devices in Kaspersky Security Center

In some VDI infrastructures, after a user session ends, the non-persistent virtual machine is powered off without shutting down the guest operating system or stopping applications. As a result, the Light Agent running on the virtual machine does not transmit information about the shutdown of that virtual machine to Kaspersky Security Center, and the virtual machine is not removed from the list of managed devices in Kaspersky Security Center. At the next startup, the non-persistent virtual machine is registered in Kaspersky Security Center, causing a duplicate to appear in the list of managed devices, representing the previous session for the virtual machine template. As a result, the list of managed devices contains a large number of non-persistent virtual machines corresponding to each user session in the VDI infrastructure.

This problem exists, for example, for VDI infrastructures based on Termidesk and Basis.WorkPlace.

You can use one of the following methods to remove a non-persistent virtual machine from the list of managed devices in Kaspersky Security Center after it is powered off:

• Before powering off the non-persistent virtual machine, stop the Kaspersky Security Center Network Agent (the 'klnagent' service). To do this, run the following command:
  • On a virtual machine with a 64-bit Linux operating system:

    systemctl stop klnagent64

  • On a virtual machine with a 32-bit Linux operating system:

    systemctl stop klnagent

  • On a virtual machine with a 32-bit Windows operating system:

    net stop klnagent

  While shutting down, the Network Agent notifies Kaspersky Security Center about the non-persistent virtual machine shutting down, and the virtual machine is removed from the list of managed devices in Kaspersky Security Center.

• After starting the virtual machine and the Network Agent (the 'klnagent' service):
  1. Take note of the device ID assigned to the virtual machine. The device ID is in the Protection_HostId parameter in the protection information of the client device:
     • On a Linux virtual machine, it is in the text files in the "/var/opt/kaspersky/klnagent/1103/1.0.0.0/Statistics/AVState/" directory.
     • On a 32-bit Windows virtual machine, it is in the HKEY_LOCAL_MACHINE\SOFTWARE\KasperskyLab\Components\34\1103\1.0.0.0\Statistics\AVState registry key.
     • On a 64-bit Windows virtual machine, it is in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\Components\34\1103\1.0.0.0\Statistics\AVState registry key.
  2. When the user is done working with the non-persistent virtual machine, delete the device by ID using the Kaspersky Security Center Open API: HostGroup::RemoveHost (wstring strHostName).