English | English
German | Deutsch
Indonesian | Bahasa Indonesia
Italian | Italiano
Spanish | Español
Turkish | Türkçe
Specifics of 1C:Enteprise server administration on Linux
- Performance degradation in debug mode
- How to change the temporary file directory of a 1С:Enterprise server
- Dump generation at unexpected application shutdown on Linux
- Kerberos authentification setup example for the Linux version of 1С:Enterprise server
Performance degradation in debug mode
When a 1C:Enterprise server is running on Linux in debug mode, starting a client application from Designer might take significant time. This is because Windows Firewall blocks the server request to the client on the computer where Designer is running.
The delay is shorter if the server is running on Windows, due to the differences in TCP/IP implementation and settings.
Further starts of the application being debugged occur without delay.
How to change the temporary file directory of a 1С:Enterprise server
When a 1C:Enterprise server is running on Linux, errors caused by 1C:Enterprise attempting to access files missing from the temporary directory may occur. This issue appears because a script cleans the temporary file directory. This article describes how to avoid this issue.
The variety of Linux distribution kits cannot give you a 100% guarantee that the following steps are applicable to all of them without any modification. However, the general idea stays the same. The steps given in this article are fully applicable to Fedora Core 4 and its analogs where bash is used as a command-line shell.
The default temporary file directory is /tmp. It is processed by scheduled runs of the /etc/cron.daily/tmpwatch script, which deletes files that have not been accessed for a long time.
To eliminate the issue, you have to change the temporary file directory of 1C:Enterprise server /tmp/.usr1cv82). To change the directory, add the following lines to the .bash_profile file, which is located in the home directory of the user on whose behalf the 1С:Enterprise server runs:
TMPDIR=/tmp/.usr1cv82 export TMPDIR
NOTE You can use any directory as a temporary file directory. Ensure that the user on whose behalf the 1С:Enterprise server runs has the right to write to this directory. |
To apply the changes, restart the 1С:Enterprise server.
Then exclude the directory from the list of directories processed by the tmpwatch utility, which is started automatically by the OS job scheduler.
In the /etc/cron.daily/tmpwatch script, modify the line that processes the /tmp directory by adding the parameter indicating that the directory should be skipped. Example:
/usr/sbin/tmpwatch -x /tmp/.usr1cv82 240 /tmp
NOTE If you choose a directory that is not processed by tmpwatch, you do not have to change the script. |
Dump generation at unexpected application shutdown on Linux
The article covers the steps for configuring Linux to generate memory dumps in the event of unexpected application shutdown. The variety of Linux distribution kits cannot give you a 100% guarantee that the following steps are applicable to all of them without any modification. However, the general idea stays the same. The steps given in this article are fully applicable to Fedora Core 4 and its analogs.
Dump generation at unexpected application shutdown is disabled by default. Developers of Linux distribution packages recommend that you only enable dump generation on application developer computers and disable it on end-user computers.
Enabling automatic dump generation
If you run a 1C:Enterprise server as a service or you want the dumps generated every time you start the server, in the home directory of the user on whose behalf the server runs (for example, /home/usr1cv82), open the .bashrc file and add the following line to it:
ulimit -с unlimited
If you run a 1C:Enterprise server as a regular application, it is enough to run the following command before starting a server:
ulimit -с unlimited
These actions can be performed by a user with the root privileges or by a user on whose behalf the 1С:Enterprise server runs (the default user name is usr1cv82).
Specifying dump names and locations
To understand clearly which process generated a dump and to specify the dump directory, create a dump name template. You can specify a template for a single session or for all sessions. This requires root privileges.
To specify dump names and location template for a single session, run the following command:
kernel.core_pattern = /tmp/core.%e.%p
In this example the dumps are stored to the /tmp directory. A dump name begins with the core prefix, followed by the executable file name and the process ID.
To specify dump names and location template for all sessions, add the following line to the /etc/sysctl.conf file:
kernel.core_pattern = /tmp/core.%e.%p
For the changes to take effect, run the following command:
sysctl -p
Kerberos authentification setup example for the Linux version of 1С:Enterprise server
The article is applicable to 1С:Enterprise versions starting from 8.1.12 and 8.2.8.
This example describes how to set up Kerberos authentication for a 1С:Enterprise 8.1 server in a simple system that consists of three computers: a domain controller, a central server of a 1C:Enterprise cluster, and a workstation.
The setup procedure for a 1C:Enterprise 8.2 server is similar, with the following differences:
- Replace usr1cv81 with usr1cv82
- Replace grp1cv81 with grp1cv82
- Replace /opt/1C/v8.1 with /opt/1C/v8.2
Description of the system used in this example
The system includes the following computers:
Active Directory domain controller
Host name: main
IP address: 192.168.29.150
Domain name: krb.local
Central server of a 1C:Enterprise cluster
Operating system: Fedora 6
Host name: srv1c
IP address: 192.168.29.151
MIT Kerberos, which supports the RC4-HMAC algorithm (krb5-workstation package)
Workstation
Domain controller setup
In this example we assume that Active Directory domain controller is configured and running. To set up Kerberos authentication, perform the following steps:
Manually register all of the Linux computers in the DNS server. Windows computers are registered automatically once they are added to the domain. In this example you have to register the central server of the 1С:Enterprise cluster manually (as it runs the Linux version of the server) and add the workstation to the domain (it will be registered automatically).
Create the account for use in authorization requests to the 1С:Enterprise server. In this example it is the user usr1cv8 with the password pass1cv8. In the account properties, clear the check box Use DES encryption types with this account. If your Kerberos version does not support the RC4-HMAC coding algorithm, select this check box.
For the user usr1cv8, generate a secret key file. Use the ktpass utility available in the Windows Support Tools package (you can find it in the SUPPORT subdirectory of the Windows installation disc).
Run the ktpass command-line utility with the following options :
C:\>ktpass -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8-out usr1cv81.keytab C:\>
If the RC4-HMAC algorithm is not supported, use the following options:
C:\>ktpass -crypto DES-CBC-CRC -princ usr1cv81/srv1c.krb.local@KRB.LOCAL -mapuser usr1cv8 -pass pass1cv8-out usr1cv81.keytab C:\>
This creates the usr1cv81.keytab file in the current directory (in this example it is the root of drive C
. The service member name usr1cv81/srv1c.krb.local is linked to the user usr1cv8.
Pay attention to the difference between the names usr1cv81 and usr1cv8. In this example usr1cv81/srv1c.krb.local@KRB.LOCAL is a stardard service name. It includes the local user name used to run the 1C:Enterprise server on the central cluster server (usr1cv81). The name usr1cv8 in the mapuser option is the domain user name created in step 2
The pass option specifies the password for the usr1cv8 account: pass1cv8.
The out option specifies the key file name. In this example it is usr1cv81.keytab.
Central 1C:Enterprise cluster server setup
In this example we assume that a 1С:Enterprise server cluster is configured and running on the central cluster server.
First, specify the DNS server for the central cluster server. It must be the DNS domain controller. The setup depends on the Linux distribution package that you use, in this example you have to edit the /etc/resolv.conf file manually by adding the IP address of the domain controller, so that the file includes the following lines:
srv1c:~# cat /etc/resolv.conf nameserver 192.168.29.150 search krb.local srv1c:~#
Then check the work of the DNS. Run the ping command:
srv1c:~# ping main -c 1 PING main.krb.local (192.168.29.150) 56(84) bytes of data. 64 bytes from 192.168.29.150: icmp_seq=1 ttl=128 time=0.177 ms ---main.krb.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.177/0.177/0.177/0.000 ms srv1c:~#
Computers that take part in the authentication cannot have a big system clock difference, as authentication packages (tickets) have a time limit. Therefore, you need to synchronize the time of the central cluster server with the domain controller. Use the ntpdate command:
srv1c:~# ntpdate main 4 Jun 11:51:53 ntpdate[2527]: step time server 192.168.29.150 offset -56.766439 sec srv1c:~#
Then set up Kerberos. Edit the /etc/krb5.conf file. You will need the NETBIOS name of the domain controller. As a rule, it is the domain name written in uppercase. In this example it is KRB.LOCAL.
The resulting /etc/krb 5.conf file looks as follows:
srv1c:~# cat /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = KRB.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
[realms]
KRB.LOCAL = {
kdc = main.krb.local:88
default_domain = krb.local
}
[domain_realm]
krb.local = KRB.LOCAL
.krb.local = KRB.LOCAL
KRB.LOCAL = KRB.LOCAL
.KRB.LOCAL = KRB.LOCAL
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = false
krb4_convert = false
}
srv1c:~#If the RC4-HMAC algorithm is not supported, the default_tkt_enctypes and default_tgs_enctypes parameters must have the following values:
... default_tkt_enctypes = des-cbc-crc des-cbc-md5 default_tgs_enctypes = des-cbc-crc des-cbc-md5 ...
Then check the work of the authentication system. Run the kinit <name> command, where the name is the name of any user registered in the krb.local domain. In this example the name is "user". Then enter the password of that user and press Enter. If the application does not display any messages, everything is all right.
Use the klist command to check the result. As you can see in the listing below, a ticket-granting ticket is received from the KDC (Key Distribution Center). The domain controller, the so-called ticket-granting ticket, performs this function. Then use the kdestroy command to clear the local ticket cache and return to the initial state.
srv1c:~# kinit user Password for user@KRB.LOCAL: srv1c:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user@KRB.LOCAL Valid starting Expires Service principal 06/04/08 11:29:21 06/04/08 21:28:28 krbtgt/KRB.LOCAL@KRB.LOCAL renew until 06/05/08 11:29:21 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached srv1c:~#kdestroy srv1c:~#
Copy the usr1cv81.keytab secret key file that you created during the domain controller setup to the central server of the 1C:Enterprise cluster, to the 1C:Enterprise server installation directory (the default directory is /opt/1C/v8.1/i386). Then set the file owner and rights as follows:
srv1c:~# cd /opt/1C/v8.1/i386 srv1c:i386# chown usr1cv81:grp1cv81 usr1cv81.keytab srv1c:i386# chmod 600 usr1cv81.keytab srv1c:i386#
You can store this file to any other directory. If you do, change the value of the SRV1CV8_KEYTAB in the configuration file, it stores the secret key file location.
Then use the klist command to check that you did everything in the right way:
srv1c:~# klist -e -k -t /opt/1C/v8.1/i386/usr1cv81.keytab
The command execution result should look as follows:
Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytab KVNO Principal ---- --------------------------------------------------------------------- 13 usr1cv81/srv1c.krb.local@KRB.LOCAL (ArcFour with HMAC/md5)
If the RC4-HMAC algorithm is not supported, the command execution result looks as follows:
Keytab name: FILE:/opt/1C/v8.1/i386/usr1cv81.keytab KVNO Principal ---- --------------------------------------------------------------------- 13 usr1cv81/srv1c.krb.local@KRB.LOCAL (DES cbc mode with RSA-MD5)
You can see that the secret key file contains exactly what you need. The Principal column contains the service name that you specified during the creation of the secret key file and the correct encryption algorithm (ArcFour with HMAC/md5 for RC4-HMAC or DES cbc mode with RSA-MD5 for DES).
Let us check whether Kerberos can work without a password using the secret key. Use the kinit command to specify that the authentication information is read from a file (in this example it is /opt/1C/v8.1/i386/usr1cv81.keytab) and the key for the usr1cv81/srv1c.krb.local@KRB.LOCAL service is read from that file. As a result, the kinit command should not display any messages or ask for passwords, and it should return the control back to the command line:
srv1c:~# kinit-k -t /opt/1C/v8.1/i386/usr1cv81.keytab usr1cv81/srv1c.krb.local@KRB.LOCAL srv1c:~#
Use the klist command to check the result. It should look like this:
srv1c:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal:usr1cv81/srv1c.krb.local@KRB.LOCAL
Valid starting Expires Service principal
06/04/08 11:44:54 06/04/08 21:43:58 krbtgt/KRB.LOCAL@KRB.LOCAL
renew until 06/05/08 11:44:54
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
srv1c:~#If something is set up in a wrong way, the result might look like this:
srv1c:~# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000 Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached srv1c:~#
If the check is successful, the 1C:Enterprise cluster server is now capable of processing authentication requests. You do not need to restart the server, except the scenario where you change the location of the secret key file in the configuration file.