Bitrix Virtual Appliance

To update settings for all MySQL servers, you must proceed to main menu item 3. Configure MySQL servers - 1. Update settings for all MySQL servers:

This option updates the configuration of one or several MySQL servers in the pool (if available) and results in default settings for Virtual Appliance.

2. Change Root User Password for MySQL Server

If you need to change root password for MySQL server, it is necessary to go to main menu item 3. Configure MySQL servers - 2. Change password for mysql user root.

After that, select a required server (host name), approve the change and input a new password.

3. Stop/Start MySQL Service

MySQL server can be started and stopped in the main menu 3. Configure MySQL servers - 3. Stop/Start mysql service on the server.

Then select a required server (host name), confirm the stop or the start of MySQL server:

4. Create a Slave MySQL Server

In Bitrix24 Virtual Appliance, it is possible to quickly deploy a Master-Slave cluster configuration for Bitrix24 On-Premise.

«Master - Slave» model is realized via MySQL tools. Bitrix24 software allows to flexibly balance the load between servers, participating in replication.

5. Change Master MySQL Server

The following steps are required to transfer master MySQL servers to another computer:

Ultimately, master MySQL server is transferred from the computer with server1 to server2.

6. Remove Slave MySQL Server

This way, resources of the computer with server1 are freed and available for other roles.

4. Configure Memcached Servers

Bitrix24 products allow creating the pool for memcached servers to work with data cache.

1. Create Memcached Server

2. Update Settings on all Memcached Servers

To update the settings for all memcached servers, go to the main menu item 4. Configure memcached servers - 2. Update settings on all memcached servers:

This option launches the verification of current configuration of one or several memcached servers in the pool (if they are available).

3. Remove Memcached Server

5. Background Tasks in the pool

Task history overview

All modifications in the Virtual Appliance - settings, synchronization, launch of any services and etc. are performed via scripts - tasks.

It is possible to view the task that is currently in progress, as well as task history, in the menu 5. Background tasks in the pool:

It is possible to view the task that is currently in progress in the menu 5. Background tasks in the pool > 1. View running tasks:

To stop the task in progress, go to menu item 5. Background tasks in the pool > 1. View running tasks > 1. Stop task and input task identifier:

Attention! The tasks will be completed during quite a significant period of time (up to 2-3 hours and more), depending on the task complexity, data volume, used in these tasks, capacity and server load.

To clean the task history, select the menu item 5. Background tasks in the pool > 2. Clean history:

Then, select the number of days, for which the task history should be preserved, with applied filter for task selection (for example, select all tasks with TaskID common):

After this, all the tasks which satisfy the indicated period and filter are displayed; proceed with history cleaning query afterwards:

Attention! if there is a reason to review task completion log files, they are located in the /opt/webdir/temp directory.

6. Configure pool sites

1. Create Site

Attention! After creating additional site, you must delete default site, created upon installation, if it's not being used.

Additional Site Creation Wizard permits to deploy several sites on the same Virtual Appliance on independent Bitrix installations as well as a part of multi-siting.

Attention! In BitrixVA\BitrixEnv version 7.x, root password for MySQL cannot be empty. It is configured for BitrixEnv during the installation stage and is automatically configured for BitrixVA during the first start. MySQL root password can be found in the menu 3. Configure MySQL server root. Change password for mysql user root. If MySQL root password is empty, then an error will occur during the creation of a new site.

The following steps are required to create an additional site:

Pre-configure DNS-server, or in case of local installation, indicate the domain name in /etc/hosts in Virtual Appliance, as well as on all appliances with access to this site.
Then, launch the Wizard from the administrative menu 6. Manage sites in the pool > 1 Create site:

and indicate:
1. Enter site name - domain name for the additional site without 'www';
  Attention! If you have domain in the national encoding (for example, Cyrillic domain), then domain name should be inputted into this field in Punycode-format, by using any Unicode-Punycode converter (for example, this).
2. Enter site type - Bitrix kernel installation:
  - kernel - if additional site is created within the framework of separate installation - separate Bitrix24 product kernel in the new site directory.
  - ext_kernel - separate Bitrix24 product kernel in the new site directory to create links to this kernel in the framework of multiple sites. The kernel will not be accessible directly, but only via additional sites (operates together with link-type sites).
  - link - if additional site is created in within multiple siting structure - shared kernel and data in the general database with already installed Bitrix24 product (operates together with ext_kernel).
3. Enter full path to the Bitrix installation directory - indicate the path to Bitrix24 product kernel, to which symlinks will be created (for kernel type: link ).
4. Enter site encoding - indicate the coding for future site: UTF-8 or windows 1251 (for kernel and ext_kernel type).
5. Do you want to enable cron task on site - option to enable task execution for cron for future site (for kernel and ext_kernel type).
6. Do you want to specify them - by default, the name, login and password for database and root-directory for site are created automatically (in dbconn.php and .settings.php files). However, via this option, unique parameters can be inputted, by selecting y response (for kernel and ext_kernel type).
During the wizard configuration procedure, the following directory will be created on the server: /home/bitrix/ext_www/{host_name}, containing the following:
- symbolic links to kernel directory, which was selected previously (if the option link was selected).
- directories and BitrixSetup script for installation or product backup (if the option kernel was selected).
- directories and BitrixSetup script for product backup (if the option ext_kernel was selected).
After the task to add the site is completed, the site will be ready for use.
Note: Quantity of additional sites is limited only by the Bitrix24 license for this installation.

Attention! If the ext_kernel option was selected and the kernel is installed into /home/bitrix/ext_www/{host_name}, then this kernel will not appear in the Virtual Appliance site list, until at least one site (link) to this kernel is created.

Attention! Task execution may take a rather long time (up to 2-3 hours and more) depending on the task complexity, data volume used in such tasks, capacity and server load. You can check the currently executed tasks by using menu item 5. Background tasks in the pool > 1. View running tasks. If task completion log files are needed to be reviewed, they are located in the following directory /opt/webdir/temp.

2. Delete Site

To delete a record about the additional site, select item 6. Manage sites in the pool > 2. Delete site in the administrative menu and select the directory of the site to be deleted (Enter site directory):

Attention! Additional Site Removal Wizard deletes folder and the database of the additional site, that is why it is necessary to preliminary create backup of important data.

3. Change Cron Tasks on Site

By default, cron is already enabled in the Virtual Appliance. If for some reasons, cron service is required to be disabled, proceed with the following steps:

Go to main menu in 6. Manage sites in the pool > 3. Change cron tasks on site and enter the site directory, for which the cron service needs to be disabled:
Confirm the cron disabling and wait until the task is completed:

Cron enabling is performed in the same way:

Note: Information on how to configure processing of all agents via cron in Birix24 products can be found here.

4. SMTP setup (4. Change E-mail Settings on Site)

To configure integrated e-mail service, complete the following actions:

In main menu, go to 6. Manage sites in the pool > 4. Change e-mail settings on site and enter host name, for which the e-mail settings should be configured:
Then, enter the necessary data for e-mail server:
- from address - sender's address for e-mail forwarding.
- server address or DNS - IP- or DNS-address for e-mail server. If you press Enter, by-default address will be used (127.0.0.1)
- server port - server port. The Port depends on the Connection type, 25 - for the usual and 465 - for encoded (with the use of SSL). If to press Enter, then the by-default port will be used (25).
- If SMTP-authorization is required, then type in y in SMTP authentication line and enter the login and password for access to SMTP-server; otherwise type-in n.
- If the SMTP-authorization option is selected, then it will be required to enter the type of authentication method: auto, plain, scrum-sha-1, scrum-md5, gssapi, external, digest-md5, login, ntlm (for example, for yandex.ru, the auto is sufficient; for mail.ru - plain).
- If protected data transfer TLS-protocol is required, then type in y in the TLS enabled line; otherwise - type-in n.
Note: When configuring, indicate the data of your own or public e-mail service.
Want until the task of configuring e-mail server is completed.
You can check if all the data, inputted into the e-mail server is correct again at 6. Manage sites in the pool > 4. Change e-mail settings on site:

MSMTP logs storage

MSMTP logs can always be reviewed for sent emails-related errors. Such logs are located at this directory: /home/bitrix/.

Each individual site has its dedicated MSMTP log, with log name containing site name – msmtp_{SiteName}.log. For example, default site will have the name msmtp_default.log.

Email service settings

This article provides list of some email services.

Gmail

From Email address – your address used to send emails (example: mail@gmail.com)
Server address or DNS – smtp.gmail.com
Server port – 587
SMTP authentication – yes
Login – your full login (example: mail@gmail.com)
SMTP authentication method – auto
Enable TLS – yes

Note: Gmail service can block smtp connection for security reasons. Find more details on how to change account access settings for unsecure applications in Google documentation.

Other services

Settings for other smtp services can be found via the links below:

MSMTP logs storage

MSMTP logs can always be reviewed for sent emails-related errors. Such logs are located at this directory: /home/bitrix/.

Each individual site has its dedicated MSMTP log, with log name containing site name – msmtp_{SiteName}.log. For example, default site will have the name msmtp_default.log.

Important! SMTP services can have custom limits for sending email campaigns and can limit such campaigns up to complete blocking of email account used for email campaigns.

For example, Google has a default limit for emails: 500 emails per 24 hours. When an email has several recipients, each email is deemed as separate email. This daily limit can change based on service custom algorithms for calculation user credibility.

5. Change HTTPS Settings on Site

Site access via HTTP and HTTPS protocols is enabled in the Virtual Appliance by default.

If required, site access can be kept only via HTTPS protected protocol:

Go to 6. Mange sites in the pool > 5. Change https settings on site in the main menu and enter the host name, for which the access protocol should be configured:
Confirm disabling of HTTP access to site and wait until the task is completed:

Attention! SSL-certificate is required to access a site only via HTTPS protocol. The certificate should be issued by a trusted certification authority. Otherwise, web browsers will display an error, indicating that the site safety certificate is not trusted.

The same procedure is used to restore site access via HTTP protocol:

6. Change Backup Settings on Site

Scheduled backups

Often, when deploying project, based on BitrixVA/BitrixEnv, a backup copy for the project is required.

Automatic backup feature for the site and the database is available in BitrixVA/BitrixEnv. Backup will be created as per schedule in the .tar.gz archive format and recorded in the directory /home/bitrix/backup/archive/.

This method has both advantages and disadvantages, compared to Bitrix24 products built-in backup copy mechanism:

Advantages: higher creation speed for backup copy and independence from project performance.
Disadvantages: backup copy cannot be created for files, stored in Cloud-storage drives.

Creating a schedule

To create scheduled automatic backup copy via BitrixVA/BitrixEnv tools:

Select item 6. Manage sites in the pool > 6. Change backup settings on site in the Virtual Appliance settings.
Select host name from the list and confirm the option to change of automatic backup schedule:
Select period and hour for the start of automatic backup:

If more detailed configuration for backup is required, command line utility can be used:
```
/opt/webdir/bin/bx-sites -a backup -d dbcp --enable --minute=10 --hour=18 --day=any --month=any --weekday=any
```
Note: How to configure the correct time in BitrixVA/BitrixEnv, see here.
After this step, the work of configuration wizard is finished. The task to create backup copy for project is added in Cron (/etc/crontab).
Backup is created for kernel (site type kernel and ext_kernel) and its all links, if such exist. To perform backup, the task is created in crontab-file. For example:
```
10 22 * * * bitrix /opt/webdir/bin/bx_backup.sh sitemanager0 /home/bitrix/backup/archive
```
As the first option, DB name is added; second option indicates catalogue, where the archive will be created.

As a result, the following type of archive will be created by the script: www_backup__DD.MM.YYYY_<random_string>.tar.gz (for example - www_backup_dbcp_21.10.2014_1RJKXbMv.tar.gz).

The following files could exist inside the archive:
1. DB dump /home/bitrix/mysql_dump__DD.MM.YYYY_.sql
2. site kernel data
3. sites Links-type data with full path

Managing backups via bx-sites

-a|--action - action to manage the site; in this case it executes backup
-d|--database - DB name (data for all sites that use this DB will be contained in the backup)
--enable|--disable - enabling and disabling backup for sites
--minute - parameters for crontab file record (minutes)
--hour - parameters for crontab file record (hours)
--day - parameters for crontab file record (day)
--month - parameters for crontab file record (month)
--weekday - parameters for crontab file record (week day)

In case of successful execution, the utility will return new options for site:

/opt/webdir/bin/bx-sites -a backup -d sitemanager0 --enable --minute=10 --hour=23 --day=1 --month=any --weekday=any -o json | python -mjson.tool  
...
            "BackupCronFile": "/etc/crontab",
            "BackupDay": "1",
            "BackupFolder": "/home/bitrix/backup/archive",
            "BackupHour": "23",
            "BackupMinute": "10",
            "BackupMonth": "*",
            "BackupTask": "enable",
            "BackupVersion": "v5",
            "BackupWeekDay": "*", 
...

Exclusion lists

Several files/catalogues are queried to be excluded from the backup copy. The list of such exclusions can be found in the file /opt/webdir/bin/ex.txt.

By default, it contains the following subcatalogues:

bitrix/cache
bitrix/managed_cache
bitrix/stack_cache
bitrix/local_cache
bitrix/backup
bitrix/tmp
upload/tmp
upload/resize_cache

Backup contents/Restore from backup

As noted above, backup includes:

site kernel catalogue itself (kernel or ext_kernel);
DB dump file (/home/bitrix/mysql_dump_<db>.sql);
sites' catalogues (link), which use the kernel.

For example, the command:

/opt/webdir/bin/bx_backup.sh sitemanager /home/bitrix/backup/archive

creates file www_backup_sitemanager_30.01.2015_bnnW1NPm.tar.gz in the directory /home/bitrix/backup/archive/

To perform restoration from backup, unpack the backup archive to kernel's DocumentRoot. The example below uses a default site directory /home/bitrix/www:

tar -xvzf /home/bitrix/backup/archive/www_backup_sitemanager_09.03.2023_zJ34ogIj.tar.gz -C /home/bitrix/www/

After that, restore the database:

mysql sitemanager < /home/bitrix/www/home/bitrix/mysql_dump_sitemanager_09.03.2023_zJ34ogIj_after_connect.sql

You can use similar command to restore another file with site database backup:

mysql sitemanager < /home/bitrix/www/home/bitrix/mysql_dump_sitemanager_09.03.2023_zJ34ogIj.sql

Next restore data for the additional link type sites, if such are available:

rsync -av /home/bitrix/www/home/bitrix/ext_www/<site_name> /home/bitrix/ext_www/

Next, delete the database dump and additional site backups for security purposes.

rm -fr /home/bitrix/www/home/bitrix/*

Restoring data for another server

In case the copy is being restored on another server, first you have to create restored sites in the VMBitrix menu. At the same time, password for database in the archive won't match to the password from database at the new server, because passwords are generated at random after new virtual appliance is installed. It means that after restoring from backup, you need to change password for database user. This data can be taken from the section connections of the file /bitrix/.settings.php after unpacking the archive backup (bitrix0 - is the database user password for default site).

You can change the password via SQL query in mysql console:

SET PASSWORD FOR 'bitrix0'@'localhost' = PASSWORD('new_pass');

Next, restore the database dumps and backups for additional sites.

You need to perform similar actions, if /home/bitrix/ext_www directory was used as DocumentRoot for sites.

Attention!: Do not forget to monitor the space on disk and periodically delete old backup copies.

7. Configure NTLM Authorization for all Sites

Attention! For Bitrix24 On-Premise and Bitrix Site Manager - AD/LDAP integration module version 11.5.0 and higher is required to support NTLM-authorization tool.

After enabling and configuration, new NTLM-authorization mechanism starts to work as follows:

Unauthorized visitor joins the project, to be redirected by event processor to an open Apache port (8890 for HTTP or 8891 for HTTPS);
Apache completes NTLM-authorization and the user is redirected back to port 80 or port 443 (for HTTP and HTTPS, accordingly);
The user performs the next hits normally.

The following is an example of Bitrix24 On-Premise settings.

Configuring NTLM-user authorization in Bitrix24 On-Premise

During the installation, select Allow Active Directory Users to Authorize in portal in the Installation Wizard:
Next, input domain AD connection settings, check the connection:
Specify the relations of groups in AD to the corporate portal groups.
After installation is complete, open the Active Directory/LDAP servers page in the portal administrative section (AD/LDAP Settings):
edit Active Directory server parameters, by indicating NTLM Authorization Domain:
Next, enter AD/LDAP module settings and select Use NTLM authentication:

Bitrix24 product is ready to use of NTLM-authorization. Next and final step: configure Virtual Appliance.

Note! If the company's local network requires a configured NTLM-authorization and employees need to work with the portal via standard authorization, then it is necessary to indicate the IP-addresses range for which the NTLM-authorization is required in the AD/LDAP module settings - Restrict NTLM redirection to this subnet (for example, 192.168.0.1/24):

Configuration of NTLM-user authorization in Bitrix24 Virtual Appliance

To configure Virtual Appliance, connect to it under root user, select menu item 6. Manage sites in the pool > 7. Configure NTLM auth for all sites and input the required data:

After the correctness of inputted data is confirmed, the wizard will configure and launch all the necessary services, as well as connect the Virtual Appliance into the domain.

Note: The following command can check if the computer has successfully joined the domain:

net ads testjoin

The setup is complete. Next, check the browser settings to ensure successful NTLM-authorization.

Configuration of NTLM-authrization in browsers

Internet Explorer
Make sure NTLM authorization is successful, the web server must be located in the Local Intranet zone (if necessary, it must be added there).
Mozilla Firefox:
Add web-server to the list of authorised URI for automatic NTLM-authorization (via the network.automatic-ntlm-auth.trusted-uris parameter on the Firefox page: about:config)

Note: Actions to enable NTLM-authorization on pre-installed Bitrix24 On-Premise are similar to the above listed, except that the Active Directory server is added manually in the administrative section.

8. Configure Optional Services (xmppd|smtpd) for Site

The wizard allows to manage the work of XMPP and SMTP services via Cron. This could be required if there is a need to distribute jabber- and e-mail messages - if there is no activity on the site, i. e. all events of site operate on hits.

The following steps are required to setup such management configuration:

Launch the wizard 6. Manage sites in the pool > 8 Configure optional services (xmppd|smtpd) for site from the administrative menu:
Next, indicate:
- Enter site-name - site name;
- Enter service name - xmppd or smtpd service name.
Confirm services activation via Cron:
After completion of this task, jabber-notifications and messages will be sent as per cron-schedule, independently from the activity on the site.

The same procedure is used to disable these options:

9. Bitrix Composite Site

Bitrix Composite Site is a unique technology to enhance site performance that unites high-speed loading of static data and background preparation of dynamic data. This technology can work on any site created on Bitrix Site Manager.

Learn more about the features provided by Bitrix Composite Site, available for Bitrix Site Manager users here.

10. Configure Site Options

1. Configure proxy_ignore_client_abort for Site

Attention! Enabling Global nginx parameter proxy_ignore_client_abort shall be done only as a last resort - usually it is not required. It is better to do it manually, and for specific location, but not globally for all server. This item will be additionally developed in the next versions of BitrixVA/BitrixEnv.

Enabling nginx proxy_ignore_client_abort parameter can be useful with Telephony, Open Channels operational errors. This parameter determines, if the connection with proxy server is to be closed in case, if the client had terminated the connection, without waiting for response.

To configure this option, it is necessary:

Launch wizard from the menu 10. Configure site options > 1. Configure proxy_ignore_client_abort for site, input site name and confirm the enabling of the parameter proxy_ignore_client_abort:
Wait until the task is completed.

The same procedure is used to disable this parameter:

11. Show Sites with Errors

If serious errors had occured on sites, they can be caused by the following reasons: modules are missing on site, or there is no connection to the DB (failed attempts to connect to site settings data). Then the menu item 6. Manage sites in the pool > 11. Show sites with errors appears in the Virtual Appliance:

By selecting this menu item, list of sites will display with a brief description of an error (in this example - no connection with MySQL database):

Note: Menu item 6. Manage sites in the pool > 11. Show sites with errors is hidden and appears only when errors occur on sites, controlled by BitrixVA Virtual Appliance or BitrixEnv Linux-environment. As a rule, when such errors are be corrected, this item will hide again.

7. Manage Sphinx in the pool

The use of Sphinx as a search engine allows to significantly increase the speed of search and decreases server load.

1. Create Sphinx Instance on the Server

The following steps are required to install Sphinx on a server:

Install and update the project to the latest current version;
Select the item 7. Manage sphinx in the pool > 1. Create sphinx instance on server in the virtual application menu:
Then, enter the host name, on which the Sphinx search server will be launched (in this example server1):
Select database of website system core data from the list:
Confirm the launch of full reindexing after Sphinx server is installed:
Wait until the task of Sphinx installation and reindexing is completed:

Note: Manual configuration of Sphinx search engine is described in this lesson.

2. Update Sphinx Instance on Server (add index)

To update settings for all Sphinx instances, go to 7. Manage sphinx in the pool - 2. Update sphinx instance on server (add index) in the main menu:

Note: This menu item will appear only when at least 1 Sphinx instance is created via the menu 7. Manage sphinx in the pool > 1. Create sphinx instance on server.

After that, enter the host name, where the search engine will be launched Sphinx (in this example server1):
Select system core database from the list:
Confirm the launch of full reindexing after Sphinx server is installed:
Wait until the task of Sphinx installing and reindexing is completed.

This option launches the verification of the current configuration of one or several Sphinx instances (if available) in the pool and launches forced reindexing.

Note: Manual configuration of Sphinx search engine is described in this lesson.

3. Remove Sphinx Instance on Server

The following steps are required to remove Sphinx instance from a server:

Select menu item 7. Manage sphinx in the pool > 3. Remove sphinx instance on server.
Note: This item will appear only when at least 1 Sphinx instance is created via the menu 7. Manage sphinx in the pool > 1. Create sphinx instance on server.
Enter host name of remote Sphinx instance (for example: server1):
Select website system core database website from the list:
Wait until the task of removing Sphinx instance is completed.

8. Manage Web Nodes in the pool

Bitrix Virtual Appliance allows for quick web-server clusterization deployment in Bitrix24 On-Premise.

When splitting the project into several web-servers, it is necessary to resolve two tasks:

data (files) synchronisation between servers
load balancing between servers

1. Create Web Instance on Server

The following steps are required to create web server role:

Select menu item 8. Manage web nodes in the pool > 1. Create web instance on server and to enter host name in the pool, where the web server will be created (in this example - server3):
Select option to create a role:
1. one step - all actions to create web-role will be performed in 1 step. This option is recommended for simple projects with insignificant data volume.
2. two steps - actions to create web-role will be performed in 2 steps to reduce errors during the role creation process. This option is recommended for large projects with significant data volumes.
  Attention! If you have selected two steps option, after 1st step task is completed, 2nd step should be launched in the same manner, on the same server.
Wait until tasks of web-server creation are completed. As a result, 2 servers will be available with the web role in the pool: server1 and server3:
Add the role (server2) to one more server in the web pool in the similar manner. The server with the balancer, web-role has the main type, and the additional servers of the pool - spare:

2. Manage PHP Extensions

Additional PHP modules can be enabled in this section 8. Manage web nodes in the pool > 2. Manage PHP extensions, which can be required in Bitrix24 products.

Presently, SSH2 module can be enabled for PHP - it will be required for Ebay integration with Bitrix24 - e-shop:

This module is disabled in the same manner:

3. Configure certificates

SSL certificate – is a digital signature of a website. It ensures encrypted connection between website visitors and the server. The certificate is also used to confirm website authenticity: any user can verify if a specific website truly belongs to a corresponding company.

Starting from BitrixVM version 7.2.0 offers a new feature of connecting both free Let's Encrypt, as well as own SSL certificates, issued by any certification authority.

Let’s Encrypt certification authority issues Domain-validated certificates (DV), free of charge and with 90-day validity period. These DV-class certificates confirm the domain as well as encode and protect data during data transfer via https protocol. Both individual persons and legal entities can install it on their websites. Such SSL certificates will be suitable for medium-sized websites and small projects, when high level of trust is not required from clients and website visitors. Let’s Encrypt SSL certificates in BitrixVM are issued within several minutes and are automatically extended approximately one month prior to validity expiration.

SSL certificates that offer a higher level of trust to your products, company and services, are issued by certification authorities with more detailed validation:

Organization Validation certificate (OV). In addition to data protection, domain membership to a specific organization is also guaranteed. The certificate is issued only to legal entities with confirmed phone number. A visitor of a website with such certificate can find information about the organization-website owner by just clicking on a 'lock' button.
Extended Validation certificate (EV). It is identical to OV, only with more detailed validation of tax and commercial activities of a company. Name of the company appears near the 'lock' icon at the website. Such certificates can be often found at website of banks and online systems with large number of visitors.

Own SSL certificates, issued by certification authorities must be issued and extended individually. In BitrixVM, such certificates must be re-connected each time, when they are re-issued by the certification authority.

1. Configure "Let's encrypt" certificate

Important! Before issuing the Let’s Encrypt certificate, make sure that you have created a site at the host (also available from the Internet), to which the certificate is issued, as well as that DNS settings for DNS hoster and registrator for this domain are configured correctly. Otherwise the certificate won't be issued. Plus, there is a limit – 5 errors for certificate issue per hour and per account for one domain.

The following is required to create the Let’s Encrypt SSL certificate:

Go to menu 8. Manage web nodes in the pool > 3. Configure certificates:
Select the menu item 1. Configure "Let's encrypt" certificate and enter site name (or several site names), for which the Let's encrypt certificates must be issued (in this example: test2.b24test.site), enter DNS name (-s), email for Lets Encrypt service notifications and confirm the input:
The wizard itself will request and install the certificate within several minutes. Paths of SSL certificates will be specified in the same section:
It is easy to check the issued certificate – just go to your site via https protocol and the valid certificate will have a green coloured 'lock' icon:

Support of several sites is available, separated by comma. Certificate validity period – 90 days. Certificate re-issuing is launched automatically, approx. one month prior to its expiration.

Important! Lets Encrypt service has limits for issuing certificates. The main ones are as follows:

Issue of 50 certificates per week for domains (from registration for registered domains, subdomains are not included).
If you have a lot of subdomains, all subdomains can be specified in a single certificate. However, there is a limit of 100 subdomains per single certificate.
Five errors per 1 hour of certificate issue per account for one domain (host is unavailable, records in domain DNS are not specified and etc.).
HTTP-01 validation is performed only via port 80. In case this port is closed (for example, by a provider), then certification won't be re-issued.

Please, find additional details about limits of Let’s Encrypt in this Rate Limits article.

2. Configure own certificate

Own SSL certificate, issued by any certification authority, can be also connected to a site in BitrixVM.

Important! Before issuing a certificate, make sure that you have created a site at the host (also available from the Internet), to which the certificate is issued, as well as that DNS settings for DNS hoster and registrator for this domain are correct. Otherwise the certificate won't be issued. Plus, there is a limit – 5 errors for certificate issue per hour and per account for this domain.

You must have the following certificate files: private key, certificate chain and the certificate.

Requirements for imported certificates:

Certificate, private key and certificate chain must have PEM-encoding.
Private key must not be encoded.
Files of the certificate and private key are required, file with the chain may not be specified.
If you use your own paths for uploading the certificates, specify full paths during import. When using relative pathnames, the certificate files must be uploaded into the /etc/nginx/certs directory.

The following must be done to connect own SSL certificate:

Copy the certificate files into any server directory via any SFTP client. In our example, we have create the /home/bitrix/ssl/ directory and have copied certificate files into it.
The resulting paths are as follows:
1. private key – /home/bitrix/ssl/test2.b24test.site_privkey.pem
2. certificate – /home/bitrix/ssl/test2.b24test.site_cert.pem
3. certificate chain – /home/bitrix/ssl/test2.b24test.site_chain.pem
After that, go to the menu 8. Manage web nodes in the pool > 3. Configure certificates:
Select menu item 2. Configure own certificate and enter site name (or several site names), for which the certificate (-s) must be imported (in this example: test2.b24test.site), Private Key path, Certificate path, Certificate Chain path and confirm certificate installation for this domain:
The installation wizard will install the certificate. Paths of SSL certificates will be specified in the same section:
Connected certificate can be easily checked - go to your site via https protocol, and the valid certificate will have a green lock icon:

Support of several sites is available, separated by comma. You will have to track validity period of your certificate on your own. Certificate re-issuing is also performed by the site owner as well. After the new certificate is issued, it can be imported again.

Note: If you have used your own server directory to copy initial certificate files, then after import is completed it is recommended to delete these files for security purposes (in the example - /home/bitrix/ssl/). If you have copied files into /etc/nginx/certs, then there is no need to delete them.

3. Restore default certificate

The following must be done If something went wrong and you want to restore self-signed certificate that is created during first BitrixVM launch:

Go to menu 8. Manage web nodes in the pool > 3. Configure certificates:
Select menu item 3. Restore default certificate and enter site name (or several site names), which need by-default certificate (-s) to be restored (in this example: test2.b24test.site) and confirm the action:
The wizard will restore by-default SSL certificate in /etc/nginx/ssl/cert.pem:

Several sites are supported, separated by comma.

4. Remove web role from server

The following steps are required to remove web-server:

Select menu item 8. Manage web nodes in the pool > 4. Remove web role from server::
Enter server host name, which web role is to be deleted (for example server3):

Attention!! Only type spare web-role can be deleted, web-role type main (server with balancer) cannot be removed.
Wait until the task of role removal is completed.
As a result, from 3 web-servers, only 2 will have a web-role (main - server1, spare - server2):

9. Monitoring in the pool

When deploying projects on the BitrixVA/BitrixEnv basis, it is necessary to monitor the condition of the server and its separate components.

Monitoring systems Munin and Nagios are already available in the BitrixVA/BitrixEnv. These systems have a signficant amount of different components for monitoring the functions of all server systems, for a single, or mulpitle number of servers as part of the cluster.

1. Configure Monitoring Services

The following steps are required to initiate operation of monitoring system:

Select the item in virtual appliance the item 9. Monitoring in pool > 1. Configure monitoring services:
Then, the wizard will offer to change the login and password for server Nagios and Munin monitoring services:
The system will offer to indicate the e-mail for Nagios system notifications (root user e-mail is used by default) and e-mail server data for e-mailing:
- from address - sender's address for e-mail forwarding. In this case, this e-mail will be used also as the recipient of notifications from Nagios.
- server address or DNS - IP- or DNS- e-mail server address. By default address will be used (127.0.0.1), if Enter is pressed
- server port - server port. The port depends on the connection type, 25 - for simple and 465 - for encoded (with the use of SSL). By default port (25) will be used if Enter is pressed.
- If SMTP-authorization is required, then input y in the line SMTP authentication and enter login and password for access to SMTP-server; otherwise - input n.
- If SMTP-authorization option is selected, then it will be necessary to input type of authentication method authorization type: auto, plain, scrum-sha-1, scrum-md5, gssapi, external, digest-md5, login, ntlm.
- If TLS-protocol for protected data transfer is required, then input y in the TLS enabled line, otherwise - input n.
After that, the wizard will configure the required settings and will launch server monitoring services.

Monitoring

For server monitoring from the browser, go to addresses and login into monitoring accounts:

Munin - http://server_adress/munin/:
Nagios - http://server_adress/nagios/:

Note: Change of passwords for monitoring systems is possible with the repeated launch of the menu 9. Monitoring in pool > 1. Configure monitoring services.

How to check e-mail notifications from Nagios

It is easy to check how notifications operate:

For example, stop the MySQL service:
CentOS 6:
```
service mysqld stop
```
CentOS 7:
```
systemctl stop mysqld.service
```

By default, Nagios will record into the log 3 messages with the CRITICAL;SOFT status each minute, and, at the 4th message, the service will show status CRITICAL;HARD:

As a result, the message with approximately the same content could be sent to the e-mail, indicated in the para. 3 of admin notification settings (from address field):

Subject: ** PROBLEM Service Alert: server2/MySQL: connection to 3306 is CRITICAL **

***** Nagios *****

Notification Type: PROBLEM

Service: MySQL: connection to 3306
Host: server2
Address: 192.168.1.246
State: CRITICAL

Date/Time: Wed Jul 5 14:12:46 MSK 2017

Additional Info:

connect to address 192.168.1.246 and port 3306: Connection refused

After the launch of MySQL service with # service mysqld start command (CentOS 6) or with # systemctl start mysqld.service (CentOS 7), the record with OK;HARD status will appear in the Nagios log:

And the message should arrive to e-mail:

Subject: ** RECOVERY Service Alert: server2/MySQL: connection to 3306 is OK **

***** Nagios *****

Notification Type: RECOVERY

Service: MySQL: connection to 3306
Host: server2
Address: 192.168.1.246
State: OK

Date/Time: Wed Jul 5 14:22:46 MSK 2017

Additional Info:

TCP OK - 0.001 second response time on 192.168.1.246 port 3306

As we can see, everything is operational - in case of malfunctions on any server, Nagios will send a notification to the admin's e-mail with indication of a problem.

Note: Details about e-mail notifications can be read here in Nagios documentation.

2. Disable Monitoring Services

The following steps are required to disable Nagios and Munin monitoring services:

Select 9. Monitoring in pool > 2. Disable monitoring services menu item:
Confirm the action:
Wait until the task of disabling the monitoring services is completed.

3. Add New Host(s) to Monitoring

If server monitoring systems have been launched and a new host had been added to the cluster, then the system itself will trace the new appliance and will launch the task to add this appliance to monitoring.

Menu item 9. Monitoring in pool > 3. Add new host(s) on monitoring allows to launch new host addition to monitoring system, if it was not added into monitoring for some reason:

Note: When selecting 9. Monitoring in pool > 3. Add new host(s) on monitoring), the task of automatic addition of new host into monitoring launches immediately, without any queries.

10. Configure Push/RTC Service

Attention! This menu item is accessible in BitrixVA/BitrixEnv starting from version 7.1.0.

Push-server

Nginx-PushStreamModule module is used by default for Push&Pull server in BitrixVA/BitrixEnv. Its main drawback: if the service is offline, then the undelivered messages get lost, which creates a high load on the PHP-backend due to the specifics of Nginx module operation. New module, based on NodeJS does not have these drawbacks.

1. Configure NodeJS RTC Service

The following steps are required to transition to the new NodeJS RTC module as replacement for Nginx-PushStreamModule:

Select item 10. Configure Push/RTC service > 1. Configure NodeJS RTC Service in the main menu of Virtual Appliance:
Enter the host name, where NodeJS RTC service is to be launched (server1 was selected in the example with launched Nginx-PushStreamModule service), confirm the replacement of Nginx-PushStreamModule to NodeJS RTC:
Wait until the tasks of launching NodeJS RTC Push&Pull server are completed:

Attention! The pool can have only one Push&Pull service. If you have launched Push&Pull service on one server and are selecting another Virtual Appliance as the server, then the wizard will stop Push&Pull service on the first Virtual Appliance and launch it on the other.

2. Remove NodeJS RTC Service

The following steps are required to transition from NodeJS RTC back to Nginx-PushStreamModule:

Select item 10. Configure Push/RTC service > 2. Remove NodeJS RTC Service in the Virtual Appliance main menu:
Enter the host name, where it is necessary to transition back Nginx-PushStreamModule (server1 was selected in the example with launched NodeJS RTC), confirm NodeJS RTC removal:
Wait until the tasks of launching Nginx-PushStreamModule Push&Pull server are completed:

Task execution may take a rather long time (up to 2-3 hours and more) depending on the task complexity, data volume used in such tasks, capacity and server load. You can check the currently executed tasks by using menu item 5. Background tasks in the pool > 1. View running tasks. If task completion log files are needed to be reviewed, they are located in the following directory /opt/webdir/temp.

11. Configure file converter/transformer service

File converter processes documents and video files to be viewed in the Feed, Task posts and comments, in Drive, as well as generates documents by templates in CRM.

File converter service in VMBitrix is available starting from Virtual Appliance version 7.5.0.

Bitrix24 must have the following installed to enable the File converter service:

"File Converter" (transformer) module version 20.100.0 and higher.
"File Conversion Service" (transformercontroller) module version 20.100.0 and higher.

Attention! File Conversion Service (transformercontroller) module is only available in Bitrix24 On-premise Enterprise edition.

Upon successful installation, module do not require additional setup, the new service automatically configures the required options for your site.

1. Configure Transformer service

File converter module limitations:

File converter module requires the File conversion server module that is available only in the Bitrix24 Enterprise edition .
Site with configured File converter module cannot be deleted: you have to delete the module first and only then delete the site.
File converter module cannot be moved to a separate server in the pool (cluster).
Only a single File converter module can be installed for a single Virtual Appliance.

File converter module can be configured as follows:

In the Virtual Appliance main menu, select the item 11. Configure Transformer service – 1. Configure Transformer service:
Enter a site name (vm1.local in the example):
Before installing the Transformer module, the system shows installed software details. After that, it launches task configure_transformer_**********, which:
- installs packages erlang, rabbitmq, libreoffice6.4, ffmpeg and corresponding associations;
- configures modules the File converter (Transformer) and File conversion server (Transformer controller) for a specified site.
When installation is complete, tasks in modules Transformer controller and Transformer will contain all the required settings.
Then, ensure that Bitrix24 Settings public or administrative UI sections inside the Drive module settings (Settings – Product settings – Module Settings – Drive) have the installed option View documents using Bitrix24.
All is ready for use.

2. Remove Transformer service

To delete the Transformer service, proceed as follows:

Select the item inside the Virtual Appliance main menu: 11. Configure Transformer service – 2. Remove Transformer service:
Select the item 1. Remove Transformer service and confirm the deleting:
It starts the task that deactivates previously launched services, deletes their data and resets Transformer and Transformer controller module settings.

Additional Settings for BitrixAV/BitrixEnv

Attention! Basic administration knowledge is required to implement operations, described in this chapter. It is recommended to create a full Virtual Appliance backup prior to starting to implement these operations. Also, some settings may be "lifehacks" that are not documented by the BitrixVA/BitrixEnv developer. That is why, please be advised, knowledge of your actions is required.

Editing BitrixVA Standard Settings without Disabling Autotuning

Attention! Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

When launching BitrixVA Virtual Appliance or a physical server with BitrixEnv installation package, bvat service automatically configures the main Apache, PHP, MySQL and nginx parameters, depending on the quantity of available memory. This allows to provide optimal server configuration.

In several cases, it is necessary to modify certain parameters without disabling bvat service. To implement such modifications in the server settings, special configuration files are available which allow to re-define parameters, installed by the bvat service. They are stored in the following directories:

MySQL - /etc/mysql/conf.d/z_bx_custom.cnf
Apache - /etc/httpd/bx/custom/z_bx_custom.conf
/etc/nginx/bx/site_ext_enabled/ - additional sites configuration files for its server файлы своих дополнительных сайтов для всего сервера (for example, bx_ext.conf, bx_ext_custom1.conf, ext_custom_site.com.conf and etc.)
/etc/nginx/bx/settings/ - settings config files for the complete server http-level settings (for example, z_bx_custom.conf, z_bx_custom1.conf and etc.)
/etc/nginx/bx/site_settings/<SITE_NAME>/ - personal settings for specific site, starting from BitrixVM version 7.5 or beta version 7.4.10 (for example, /etc/nginx/bx/site_settings/site.com/myconfig.conf).

PHP - /etc/php.d/z_bx_custom.ini

Attention! All modifications of standard configuration files Apache, PHP, MySQL and nginx can be lost when updating BitrixVM/BitrixEnv Virtual Appliance. To avoid such loss, only the file type z_bx_custom.* specified above for each service, must contain all re-defined parameters.

You have to re-launch corresponding services: MySQL, Apache or nginx to enable the redefined parameters.

Example of updating the parameters in the file z_bx_custom.cnf

Expanding BitrixVA Disk Space

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

If the use of BitrixVA Virtual Appliance or BitrixVA ami-image, the problem of insufficient free space can occur after some time.

There are two methods to resolve this problem:

Add one more hard drive to the Virtual Appliance, mount it in the system and transfer a portion of content to it (more optimal method);
Increase size of existing virtual hard drive.

Supplementing an Additional Hard Drive to BitrixVA

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

You should place specific partitions at the separate disks due to the majority of disk space being occupied by site content and reserve copies, located in /home/bitrix, as well as by the database, located in /var/lib/mysql.

Let's overview this case with an example, when a folder /home is transferred with site contents and backup copies to a separate disk.

Add a new disk of needed size inside the Virtual Appliance settings hardware list. Perform all the actions, listed below, under the root user administrator account:
After the disk was added, a server re-load may be required to initialize it. You can see the new disk and its assigned letter designation via this command:
```
fdisk -l
```
Launch the fdisk utility for work with the /dev/sdb disk:
```
fdisk /dev/sdb
```
Create a new partition via the n command:
- new (primary partition) - p command and Partition number (1-4): 1;
- first and the last sectors should be selected by default - this way, a partition will be created, using all the free space on the disk:

To save changes on the disk and to exit from the fdisk, enter the w command.

After partition table are saved, format new partition and transfer information from /home to it:

CentOS 6

mkfs.ext4 /dev/sdb1 
mount /dev/sdb1 /mnt 
service httpd stop 
service nginx stop
mv -f /home/* /mnt 
umount /mnt

CentOS 7

mkfs.ext4 /dev/sdb1 
mount /dev/sdb1 /mnt 
systemctl stop httpd.service
systemctl stop nginx.service
mv -f /home/* /mnt 
umount /mnt

Text step, define UUID for new disk:

blkid
/dev/sda1: UUID="99066558-ba04-465c-9962-e827aa2928ec" TYPE="ext4" 
/dev/sda2: UUID="8ea38ef9-1ee5-423b-a013-15fd603a678e" TYPE="swap" 
/dev/sda3: UUID="08ec5c65-8fd8-47ac-a998-d81195c8f964" TYPE="ext4" 
/dev/sdb1: UUID="b2e58731-b621-4bd5-909a-afe3bb5dd8a1" TYPE="ext4"

and add the record (in this example: UUID=b2e58731-b621-4bd5-909a-afe3bb5dd8a1) about it in /etc/fstab (instead of UUID, device name /dev/sdb also can be used):

The only thing that is left, is to import a new disk and to launch previously stopped services:

CentOS 6

mount /home 
service httpd start 
service nginx start

CentOS 7

mount /home 
systemctl start httpd.service
systemctl start nginx.service

Adding disks in other virtualization environment or directly on a physical server is performed in a similar manner.

Increasing Size of Existing BitrixVA Hard Drive

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

Second method to increase the space in BitrixVA is to expand the size of already existing virtual appliance hard drive.

This example uses Virtual Appliance BitrixVA for VMWare and demonstrates how to increase the size of system hard drive to 100GB:

Change system drive size in VMWare

Change system drive size in VirtualBox

After that, it is necessary to launch BitrixVA Virtual Appliance, login under root user and go to command line (console) by selecting the 0. Exit menu item in the Virtual Appliance.
See the disk and its assigned letter designation via console command:
```
fdisk -c -u -l
```
where for the disk /dev/sda:
- sda1 - disk boot sector;
- sda2 - swap file;
- sda3 - partition, where the operating system is installed and which should be expanded specifically.
Launch the fdisk utility to work with /dev/sda disk:
```
fdisk -c -u /dev/sda
```
Delete partition sda3 via command d, by selecting Partition number (1-4): 3:

Attention! Data on the disk is not deleted, in this case, only the partition record is deleted from the disk partition table.
Next, create a new partition via the n command:
- Primary (primary partition) - p and Partition number (1-4): 3 command;
- simultaneously, first and last sectors could be selected by default - this way, partition will be created by using all free space on the disk.
To save all the modifications of updated partition table and to exit from fdisk, enter the w command:
For the system to load a new partition table, reboot the Virtual Appliance:
```
reboot
```
After the reboot, increase the size of file system for the partition /dev/sda3 via the resize2fs utility:
```
resize2fs /dev/sda3
```

You can check the partition increase via the df command:

The same procedure modifies the disk size in other virtualization environments.

Increasing Size of BitrixVA LVM-Partition

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

Attention! Logic Volume Manager LVM2 is installed by default in CentOS 7 during the automatic partitioning of the disk during the system installation phase (in case if BitrixEnv is installed via bitrix_env.sh script on the CentOS 7). In such case, the size change for LVM-partition will differ from previous methods.

Scenario: the size of system disk was increased from 20GB to 100GB, as was done previously in VMWare Player.

Then, the actions to change LVM-partition size will be the following:

Check, what devices/partitions are available at the moment via the command:
```
fdisk -l
```
Verify, that the space did not increase automatically via the command:
```
df -h
```
Volume group name and the name volume are also visible (we will have different ones):
- cl - volume group name;
- root - volume name.
Create a new sda3 partition - partition type: Linux LVM (code type 8e) on the unpartitioned space. To do that, start working with the sda device via the command:
```
fdisk /dev/sda
```
Next, create a new partition via the n command:
- primary (primary partition) - p and Partition number (1-3, default 3): 3 command (because we had 2 logical partitions sda1 and sda2 - p.1);
- in this case, first and last sectors are selected by default - this way, partition will be created by using all available free space on disk;
- indicate partition type - t and Partition number (1-3, default 3): 3 command;
- enter partition code type, corresponding Linux LVM - 8e;
- see the partition table - enter p command and make sure, that all is correct;
- Partition sda3 is created. To save the updated partition table and to exit from fdisk - w command.
For the system to load the new partition table, reload the Virtual Appliance:
```
reboot
```
After the reset, it is necessary to create a sda3 physical volume:
```
pvcreate /dev/sda3
```
Next, expand the volume group to a new space, using the cl volume group name (which we have memorized previously in p.2):
```
vgextend /dev/cl /dev/sda3
```
Now, expand the logical volume, by using the root volume name (hich we have memorized previously in p.2):
```
lvextend -l+100%FREE /dev/cl/root
```
Scan disks for the for the availability of volume groups and activate all volume groups that are found:
```
vgscan
vgchange -ay
```
Find the type of file system:
```
file -s /dev/sda1
```
See, that file system is XFS.
And finally, expand XFS file system (may require time):
```
xfs_growfs /dev/cl/root
```
Note: If the file system is not XFS, but, for example, id ext4 or reiserfs, then the commands will be the following (with account of cl - to group name and root - volume name from p.2):
- resize2fs /dev/cl/root - for ext4;
- resize_reiserfs /dev/cl/root - for reiserfs;
Check the final result:
```
df -h
```

Connecting Swap Partition

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

BitrixVA Virtual Appliance is supplied with 256MB Swap partition, and it is not connected in the ami image by default. That is why, during operation, there could be a necessity to expand the swap partition.

As in the case with expansion of free space, the simplest - is to add an additional disk and create swap partition on it, or is to create a swap file.

For this:

connect the disk to the Virtual Appliance or create a swap file:
```
dd if=/dev/zero of=/swapfile bs=1M count=1024
```
create swap partition on disk:
```
mkswap /dev/sdb1
```
or in a file:
```
mkswap /swapfile
```
Connect swap partition:
```
swapon /dev/sdb1
```
or swap file:
```
swapon /swapfile
```
and finally, add the record about a new swap partition in /ets/fstab, to avoid manual enabling after each reloading:
```
/dev/sdb1 none swap sw 0 0
```
or add the record about the swap file:
```
/swapfile none swap sw 0 0
```

Fixing issues in old sites with windows-1251 encoding

The following errors can be encountered when updating old sites that have Windows-1251 encoding, created in VMBitrix version 7.4.3 or lower:

Bitrix24 product update system is not operating correctly – requires the available parameter mb_internal_encoding('Windows-1251'); в dbconn.php.
With enabled Update system notifications does not operate due to the warning: «PHP Warning: htmlspecialchars(): charset `latin' not supported, assuming utf-8».
System check issues an error: "String functions strtoupper and strtolower operate incorrectly".

When updating VMBitrix to version 7.5 and higher, these errors occurring in previously installed sites with Windows-1251 encoding are not fixed automatically. That is why, you need to fix them manually for each individual site.

Add the following string to the file /bitrix/php_interface/dbconn.php:
```
mb_internal_encoding('Windows-1251');
```
Replace the following string in the Apache config file for your site /etc/httpd/bx/conf/bx_ext_[your_site].conf:
```
php_admin_value default_charset latin
```
with this string:
```
php_admin_value default_charset cp1251
```
and relaunch the Apache:
```
systemctl restart httpd.service
```
Check, if the locale en_EN.cp1251 is available in the system. When response is 0, it means that the localeen_EN.cp1251 is not available, when 1 – it is available:
```
locale -a | grep en_EN.cp1251 -ic
```
When locale en_EN.cp1251 is not available, execute the following command:
```
localedef -c -i en_EN -f CP1251 en_EN.CP1251
```
Then add two strings into your site's file /bitrix/php_interface/dbconn.php that has windows-1251 encoding:
```
setlocale(LC_ALL, 'en_EN.CP1251' );
setlocale(LC_NUMERIC, 'C' );
```
and relaunch Apache:
```
systemctl restart httpd.service
```
All is ready. Perform these actions for each individual site with encoding windows-1251, created previously.

Note: VMBitrix 7.5 and higher, new sites, created with Windows-1251 encoding won't have any issues with single-byte character encodings.

Memcached Manual Configuration

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

Attention!

Incorrectly configured Memcached (available for third-parties) can be used for for malicious purposes for site hacking. Check the option -l <ip> in its settings. Querying Memcached must be permitted only from your site.

Memcached settings

If memcached is planned to be used in the project, it is necessary to configure it in accordance with anticipated load.

For this, it is required:

To specify the following parameters in the /etc/sysconfig/memcached file:
- MAXCONN = "1024" - quantity of simultaneous connections (1024 by default);
- CACHESIZE="1024" - volume of memory, allocated for cache (64MB by default);
- OPTIONS="t 8" - quantity of memcached flows (4 by default).
Note: MAXCONN, CACHESIZE and OPTIONS parameters are selected experimentally depending on the type of load and on the available resources.
The volume of memory required for caching (parameter CACHESIZE) can be evaluated according to the size of your file cache. If file cache occupies 3GB in your project, then the use of memcached with 256MB memory will not be effective due to frequent preemption.
After configuring is competed, it is necessary to restart memchached via the command:
CentOS 6:
```
service memcached restart
```
CentOS 7:
```
systemctl restart memcached.service
```

Next, connect it into /bitrix/php_interface/dbconn.php:

define("BX_CACHE_TYPE", "memcache");
define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"]."#01");
define("BX_MEMCACHE_HOST", "127.0.0.1");
define("BX_MEMCACHE_PORT", "11211");

and in the file /bitrix/.settings_extra.php (create it, if unavailable):

<?php
return array(
  'cache' => array(
    'value' => array(
      'type' => 'memcache',
      'memcache' => array(
        'host' => '127.0.0.1',
        'port' => '11211',
      ),
      'sid' => $_SERVER["DOCUMENT_ROOT"]."#01"
    ),
  ),
);
?>

Handling memcached via socket

If one more server is used, you can configure the operation with memcached via socket to improve the productivity:

Set parameters in the file /etc/sysconfig/memcached:
- USER="bitrix" - user from which memcached will be launched;
- OPTIONS="-t 8 -s /tmp/memcached.sock" - quantity of flows and path to socket.

Restart memcached via command:

CentOS 6:

service memcached restart

CentOS 7:

systemctl restart memcached.service

After that, it is necessary to modify settings in /bitrix/php_interface/dbconn.php:

define("BX_CACHE_TYPE", "memcache");
define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"]."#01");
define("BX_MEMCACHE_HOST", "unix:///tmp/memcached.sock");
define("BX_MEMCACHE_PORT", "0");

and in the file /bitrix/.settings_extra.php (create it, if unavailable):

<?php
return array(
  'cache' => array(
    'value' => array(
      'type' => 'memcache',
      'memcache' => array(
        'host' => 'unix:///tmp/memcached.sock',
        'port' => '0',
      ),
      'sid' => $_SERVER["DOCUMENT_ROOT"]."#01"
    ),
  ),
);
?>

Note: When using multiple sites, the example must contain static [dw]sid[/dw][di]Site ID, an ID field in settings site config parameters[/di], without $_SERVER["DOCUMENT_ROOT"]. Otherwise, cache will be different for two sites, because site folders are different.

Correct Mounting of Windows-Resources

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

If Windows network disk is required to be connected as storage for WebDAV, the following command can be used:

mount -t cifs -o -fstype=cifs,iocharset=utf8,username=XXXX,password=XXXX,uid=500,gid=501,fmode=0777,noserverino //xxx.xxx.xxx.xxx/folder /home/bitrix/www/docs/folder/smb

where:

uid - bitrix user identifier;
gid - bitrix group identifier;
//xxx.xxx.xxx.xxx/folder - path to network resource;
/home/bitrix/www/docs/folder/smb - folder, where the disk will be mounted.

Attention! Use of noserverino option is mandatory, due to existing security vulnerability in PHP.

Execution of All Agents via Cron

Moving agent to cron

In large or medium-sized projects, sometimes there is an issue with the transfer of especially heavy agents to Cron.

First, fully disable execution of agents on a hit. To do this, the command /bitrix/admin/php_command_line.php?lang=en should be executed in PHP-console of Bitrxi24 product administrative menu:

COption::SetOptionString("main", "agents_use_crontab", "N"); 
echo COption::GetOptionString("main", "agents_use_crontab", "N"); 

COption::SetOptionString("main", "check_agents", "N"); 
echo COption::GetOptionString("main", "check_agents", "Y");

As the result, we should have NN.

Remove the definition of the following constants from the /bitrix/php_interface/dbconn.php file:

define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);

And add:

if(!(defined("CHK_EVENT") && CHK_EVENT===true))
   define("BX_CRONTAB_SUPPORT", true);

Next, create agent verification and system messages multicasts file /bitrix/php_interface/cron_events.php:

<?
$_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__)."/../..");
$DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"];

define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS",true); 
define('CHK_EVENT', true);

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

@set_time_limit(0);
@ignore_user_abort(true);

CAgent::CheckAgents();
define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);
CEvent::CheckEvents();
?>

And add this script into Cron:

 */5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php

After that, all agents and forwarding of system Messages will be processed under cron, once each 1 minute.

Note: Cron failing to execute after the command means you have errors in your project. These errors, most likely, are not agent-related. Look for them in the PHP logs. You can enable an extended error display in .settings.php.

Email message queue

The parameter responsible for the quantity of e-mail messages, processed at once, must modified to prevent a large of e-mail messages queue. To do that, execute the following command in PHP-console:

COption::SetOptionString("main", "mail_event_bulk", "20"); 
echo COption::GetOptionString("main", "mail_event_bulk", "5");

When a regular cron_events.php was launched before completing previously triggered script, agents will fail to launch and script terminates (due to agents being blocked during execution time). In this case, processing is no different from processing on a hit; a new hit can occur at the moment, when agents failed to execute on the previous hit.

Usually, scripts, executed under cron do not have limits on execution time. However, using database-handling methods in scripts can encounter an error with executing embedded scripts. To avoid this error, you can modify the value in /bitrix/php_interface/dbconn.php:

// when script is executed by cron, database connection limit is: 600 seconds, otherwise - 60
@set_time_limit(php_sapi_name() == "cli" ? 600 : 60);

Mounting Options

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

To provide higher productivity of the file system, it is recommended to disable the timestamp modification when reading files and directories: noatime, nodiratime.

For this, parameters in the line with its UUID shall be edited (added into current line) in /etc/fstab:

UUID=abd9bdaa-e17d-40b3-aee5-37ef53a57b16 /    ext4    defaults,noatime,nodiratime    1 1

where UUID=abd9bdaa-e17d-40b3-aee5-37ef53a57b16 - unique disk identifier, which can be recognized in the console with blkid command.

Note: Instead of UUID, device name also can be used: /dev/sda1, /dev/sda2, /dev/sda3. Or volume label, if specified, for example: LABEL=root.

After restart, new settings will be applied.

To apply new settings without restarting the server, partitions can be remounted via the command:

mount -o remount,noatime,nodiratime /

Note: Creative approach should be applied to resolving the problem of file system productivity. If, for example, cache of some applications is still available on the disk, then the productivity can decrease as a result of proposed measures, because many applications clear cache via label-based index, which is recommended to be disabled in the example. In some cases, the commit time extension can give better result, especially if there is significant amount of available memory. Commit time is set by the commit parameter. To set it for 120 seconds, for example, it is necessary to add commit=120. That is, the set of options for mounting will be defaults,noatime,commit=120.

By default, data and metadata flush to disk happens each 5 sec. Delaying the flush time also can decrease file fragmentation on disk, if there are files available to which data are supplementary recorded. Log files, for example.

Connecting IDE

To simplify the work with Bitrix Framework the Xdebug is included into the Virtual Appliance. It works as per the diagram:

Prior to modifying the settings, the file xdebug.ini.disabled should be renamed to xdebug.ini and httpd restarted.

To configure the Virtual Appliance, use the following example:

$ cat /etc/php.d/xdebug.ini
; Enable xdebug extension module
zend_extension=/usr/lib/php/modules/xdebug.so
xdebug.remote_enable=on
xdebug.remote_host=192.168.205.1
xdebug.remote_port=9000

Attention! Xdebug requires using proxy when working via Network Address Translation (NAT); open port 9000 is required.

Packet Source Codes (starting from version 7.3.0!)

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

When developing your BitrixEnv-based solutions, tracking of file version changes will be required. This feature can be enabled by connecting a source data repository for Virtual Appliance, allowing to track all changes and modifications.

Attention! Packet source codes are available for stable and beta versions of BitrixEnv, starting from version 7.3.0.

VMBitrix stable version

Add file for the repo /etc/yum.repos.d/bitrix-source.repo with the following content:

[bitrix-source]
name=$OS $releasever - source
failovermethod=priority
baseurl=https://repo.bitrix.info/yum/SRPMS
enabled=1
gpgcheck=1
gpgkey=https://repo.bitrix.info/yum/RPM-GPG-KEY-BitrixEnv

Check, if the packet yum-utils is available:
```
yum clean all && yum install yum-utils
```

Download virtual appliance source code data:

Standard BitrixEnv:

yumdownloader --source bitrix-env

Approx. console response for standard BitrixEnv

VMBitrix

Add file for the repository /etc/yum.repos.d/bitrix-source-beta.repo with the following contents:

[bitrix-source-beta]
name=$OS $releasever - source
failovermethod=priority
baseurl=https://repo.bitrix.info/yum-beta/SRPMS
enabled=1
gpgcheck=1
gpgkey=https://repo.bitrix.info/yum/RPM-GPG-KEY-BitrixEnv

Check if yum-utils package is available:
```
yum clean all && yum install yum-utils
```
Download virtual appliance sources:
- VMBitrix:
```
yumdownloader --source bitrix-env
```

PHP-Extensions Manual Enabling

Attention!

For operations, described in this chapter, knowledge of *nix-systems administration is required. Prior to start of these operations, it is recommended to perform full backup of Bitrix Virtual Appliance.
Provided settings are listed outside the scope of the Virtual Appliance menu. This means that the details below are provided for informational purposes only and should be used with clear understanding of your actions and under your own liability. Bitrix24 technical support reviews the questions related to Virtual Appliance menu items only.

Manual activation

In addition to enabling specific PHP-extensions from the BitrixEnv menu, the required extensions can be connected manually.

Configuration ini-files for the available php-extensions are located in the directory /etc/php.d/:

To manually enable a required extension, the file {name_extension}.ini.disabled must be renamed to {name_extension}.ini and the Apache service must be re-launched – httpd.

Пример

For example, extension dom must be enabled.

Go to server directory /etc/php.d/:
```
cd /etc/php.d/
```
Print list of files in the directory:
```
ls
```
Find the file 20-dom.ini.disabled in the list, rename it for 20-dom.ini, save and replace the current file:
```
mv 20-dom.ini.disabled 20-dom.ini
```
Attention! If the content of 20-dom.ini.disabled is copied into 20-dom.ini and those two files are kept in the directory /etc/php.d/, then the dom-extension will deactivated when the PHP or Virtual Appliance are updated. To avoid this, only one file 20-dom.ini must be kept with the active extension.

Re-launch the Apache service – httpd:

CentOS 6:
```
service httpd restart
```
CentOS 7:
```
systemctl restart httpd.service
```

The procedure is completed, extension is dom operational:

Setting a php-extension, unavailable in BitrixVA

You can also set any php-extension manually.

For example, set the extension php-imap.

First, find name for ph-extension using the command:

yum list php-imap*

Next, set using the command:

yum install php-imap

Creates the file /etc/php.d/20-imap.ini upon installation.

Then, re-launch the httpd service.

All is ready, php-extension imap is operational:

Note: some php-extensions can automatically be enabled after installation. When ini-file weren't created during setting of the extension, you need to create it manually.

BitrixVA proxying settings

Often times a situation occurs when BitrixVM is installed inside a local office network and queries from Internet are sent to it via proxy.

In this context, proxying is understood as a http proxy that allows connect users to site located on the BitrixVM Virtual Appliance. This term is also includes network equipment that allows to establish TCP/IP connection.

Server Settings

Organizing web-sockets

Organized web-sockets (ws/wss protocols) are the key when additional settings are required to avoid terminated connection via timeout by the network equipment.

Network equipment settings are not subject of this article, it presupposes that all settings are in order and web socket support is enabled.

This article's main focus is on a situation when port for ws/wss protocols must be moved for correct operation.

1. Virtual Appliance configuration

2. Ports opening

3. Change site settings

Query proxying

Let's assume, nginx server acts as an external proxy.
When required, you can adapt these settings for other proxy-services as well.

Push-server

Push-server settings must be moved to your load balancer (whether it's the only input point or it services only client queries from external networks when BitrixVA services the local network).

Duplicate push queries proxying settings to the load balancer. You can take a Virtual Appliance config file bx/conf/im_subscrider.conf as the basis (you can directly copy it to the balancer):

This file is connected to the server with configured query proxying to the virtual appliance.

Higher level config file depends on bx/settings/rtc-im_settings.conf, with the following parameters defined:

Also copy the file bx/settings/rtc-im_settings.conf and connect on the level of http-section at the load balancer.

Next, open the ports 8010-8015 and 9010-9011 on the push-server for accessing from the balancer.

HTTPS access

In situation, when we are proxying http and https for site test.example.org for port 80 of Bitrix Virtual Appliance.

Enable module real_ip in BitrixVA – create the config file bx/settings/real_ip.conf:

Indicate balancer header in real_ip_header passed to the backend (to Bitrix Virtual Appliance). In set_real_ip_from – balancer IP address.

Configure on the backend (Bitrix Virtual Appliance) to setup variables in the file bx/settings/schema.conf:

The backend's variable $http_x_forwarded_proto will contain the value http or https depending on connection protocol.

BitrixVA API for Providers

This chapter describes the API that is used to connect the order/VA creation procedure with the pool management in Bitrix24 Products.

Providers

All work with providers is carried out via plugins, located in the specific catalogue (presently, all management is file-based): /opt/webdir/providers.

Plugin script, to be used in web-interface of Bitrix24 products shall be located at the address:

To be connected to the pool, provider's plugin shall support the following command line arguments:

Script to Work with Providers

This script is required to embed provider plugins into Bitrix24 products web-interface.

Web Cluster setup and config

Description

First server in the group - always serves as balancer and web role. All additional servers - serve as web role. In case of Virtual Appliance - balancer role cannot be switched. If you need to move it to separate server, read the next lesson.

Web node settings

Files synchronization/lsyncd

Between servers with the web role: synchronizes site directories, except the following subdirectories:

lsyncd settings

Web service setup and config

Web cluster: config, backup, restoration

Description

For this purpose, each node has additional service lsyncd-, where server name - host identifier in the synchronized Virtual Appliance pool. In our example, the service lsyncd-srv2 to synchronize files from server srv1 to srv2 can be found at the server srv1. File synchronization is performed by protocol SSH+Rsync with authorization by key by user bitrix in Virtual Appliance (BitrixVM).

Service logs can be found in the catalog /var/log/lsyncd. For example, daemon-srv2.log will contain sync log from servers srv2, and daemon-srv2.status - current sync status. With this, the main server synchronizes the following directories:

The following is excluded at the main and additional servers: subdirectories contains cache for sites and config files are excluded at additional sites:

Additional web server is broken

There is a significant probability that you may simply do not notice such error, because NGINX server marks your backend servers as unoperable only after several errors. NGINX continues to use the same servers that respond in a standard mode. For you not to miss such malfunction - configure internal monitoring for Virtual Appliance or any other monitoring.

If additional server is operational, but you need to pull it out of operation, use the corresponding menu item of Virtual Appliance. If such option is unavailable, you can disable it manually, by removing it from upstream of NGINX servers and by disabling lsyncd config synchronization.

Main server is broken

Complex variant - web server malfunction. You won't miss it, but it's better to configure the monitoring feature.

The situation is dire, but do not panic: you have all the necessary config files at the additional node (not all are in use, but it can be easily corrected).

How to create BitrixVM image for cloning

It's useful for developers who set up and clone a BitrixVM virtual appliance minimal configuration. The cloned virtual appliance image is then used to be deployed separately.

Let's overview the setup of two virtual appliance services that are used most frequently:

There are 2 ways of moving BitrixVM virtual appliance: manually, by creating a cloned image for existing virtual appliance with required services included or using an automatic deployment of an image (recommended).

Image cloning

1. Running a management pool for virtual appliance

This step is required to get access to server settings, as well as push-server and memcached setup.

At a clean server, select item 1. Create Management pool of server, it specifically will guide you through the required settings.

When fields unreachable and failed are null, everything is completed successfully to continue to the next stage.

2.1. Configuring push-server

By default, virtual appliance scenario configures services for using operational IP address, so other appliances joining the pool could use it.

This image is used to copy the virtual appliance, that's why the address most likely, will be different and the specified settings won't be applied. To avoid this, change the server address to localhost, available at any Linux host.

To do it, change the parameter in the file /etc/sysconfig/push-server-multi to:

Nginx proxies the queries to push-server based on host name. To ensure it determines everything correctly, where and how to proxy, change entry in /etc/hosts:

2.2. Configuring memcached server

At this point, service itself ensures that the address is copied correctly and the access is limited by iptables/firewalld settings.

3. Deleting pool settings

When only a single virtual appliance is in the pool, settings should be deleted to create new ssh-keys and other security settings for the new virtual appliance.

When the pool has several virtual appliances, it's not recommended to save pool settings when copying, because the pool has address update identification mechanisms and the new appliance can take up wizard duties.

4. Additional cleanup

Upon deploying a cloned image on a new location, it's recommended to configure management pool to have an option to continue managing the virtual appliance.

The abovementioned actions can be skipped when the pool remains in the same location, a copy (image) created for backup, and the same virtual appliance will be restored from it, without an address or keys updates.

Automatic image deployment and setup (recommended)

Clean image can be configured automatically. To do it, just add the above-listed commands to your scenario or bash-script:

As a result, you get an operational virtual appliance without the need to solve address update issues when copying the template.

Upon each launch, a background job will be executed, with status being traceable, as shown above.

Bitrix Virtual Appliance Contents

Introduction

Bitrix24 On-premise operational requirements

BitrixVM edition packages

Both variants are very similar: BitrixVM completed images are assembled based on the same bitrix-env.sh script, each image with additional drives included for handling its hypervisor and scripts for Amazon EC2 service.

bitrix-env.sh packets are updated more frequently, than BitrixVM images. That's why, on first image launch, its preferable to launch BitrixVM update via the menu.

Bitrix repository

Repository – is a file storage, organized in a specific order. It stores software packages, available for further distribution.

BitrixVM virtual appliance packages are stored in a special Bitrix yum-repository, located in CloudFront (AmazonCDN).

Bitrix repository contains the following software packages:

BitrixVM package contents

bx-nginx

Apache/PHP

PHP – standard packages from REMI-repository. BitrixVM virtual appliance supports option to update from PHP version from 5.6 to 7.0 – 7.1 – 7.2 – 7.3 – 7.4 – 8.0 as well as downgrade back.

MySQL Percona Server

When installing bitrix-env the following configurations are created for mysqld:

Additional setup options are available from the BitrixVM Virtual Appliance menu scenarios:

Ansible

Ansible is a configuration management system with declarative markup language used for configurations description and automating software setup and deployment.

Ansible is easy to setup and only ssh-access to server is required for it to operate. There is an easy access point, both in terms of available configuration scenarios (ini-, yml- and json formats), templates (jinja2), as well as in terms of plugin writing using sufficient available languages (bash and etc.). Ansible has a clear documentation and a large support community with significant database with examples.

BitrixVM Virtual Appliance has the following setup: BitrixVM menu can select, how to proceed (configure SSL certificate, create site, enable cron jobs for site and etc.), and then task is initiated via the interface to implement the update via API - this is exactly the ansible-based scenario with all required options.

Management Interface

Using the web interface in the administrative section for several Bitrix24 products: Settings > Scale management > Control Panel.

This server scale management option is mainly directed to manage one or several servers, included into the pool for fail-safe system within increasing load conditions. it's features are limited in comparison to second option.

It is the most comprehensive and recommended BitrixVM Virtual Appliance management interface. All new features are displayed in this interface variant.

Ansible inventory

Most important is description of hosts, managed by the Virtual Appliance. In the most simple case – it is a local server with the installed Bitrix environment.

Scenarios, roles, API

Scenario – set of actions to be executed at the server or group. Scenarios are grouped by roles.

Roles – the method for organizing scenario storage. Allows storing all the necessary files in a separate catalog.

Ansible scenario API is used for launching scenarios, retrieving their status and returning it in a convenient format (json, txt).

Scenarios are launched via API in background mode so that any current web- or ssh-session would not affect configuration process. During this process, current ongoing task status is saved, and its log can be retrieved in case of an error.

Command ansible-playbook launches yml scenario and additional options are collected from the menu and sent via the file opts.yml in the parameter ansible_playbook_file.

Before launching ansible scenario, API creates the task directory /opt/webdir/temp/<TASK_ID> and then places the following files into it:

Task statues can be viewed via the virtual appliance menu item 10. Background pool tasks:

Service configuration

Configuration for nginx

Site configuration files are setup when site is created and can be updated depending on the selected action.

All changes in standard nginx configuration files can be lost during updating or modifying BitrixVM Virtual Appliance settings. To avoid this, individual specific files and storage locations are available for personal settings.

Global nginx settings for the complete server is available in the file /etc/nginx/bx/settings/z_bx_custom.conf, as well as in the file /etc/nginx/bx/site_ext_enabled/.

Personal settings for specific site are available in the directory /etc/nginx/bx/site_settings/<SITE_NAME>/ (starting from BitrixVM version 7.5 or beta version 7.4.10).

Configuration for apache/httpd

All changes in standard apache configuration files can be lost during updating or modifying BitrixVM Virtual Appliance settings. To avoid this, individual specific files and storage locations are available for personal settings.

Global apache settings for the complete server can be updated in files /etc/httpd/bx/custom/*.conf.

MySQL configuration

Global mysql settings for the complete server are available in the file /etc/mysql/conf.d/z_bx_custom.cnf.

BitrixVM Configuration

Pool

In the simplest case, the pool can contain a single server with configured Bitrix environment.

Creating and deleting a pool

Without creating a pool you cannot perform site and server management via the menu. Only local host network settings will be available (name and IP-address setup, server updating).

Adding and deleting server in the pool

Site

DOCUMENT_ROOT files:

Apache files in /etc/httpd/bx/conf/:

Nginx files in /etc/nginx/bx/site_enabled/:

Crontab files:

Site types

Creating and deleting sites

Launching site via API:

Ansible-playbook:

Launching site deleting via API:

Ansible-playbook:

Bitrix Virtual Appliance