Воскресенье, 17 Июнь 2012 19:21

Установка и настройка сервера 1С под Linux

Автор
Оцените материал
(12 голосов)

Всем привет!

На этот раз, я хочу рассмотреть поднятие сервера для 1с 8.2 под линуксом. В этом мне очень помогла вот эта статья:

http://www.lissyara.su/archive/1c_8.2+postgresql

Начнём с установки операционной системы. Я для этого выбрал Fedora 16. При установке системы я выбрал самый минимальный набор пакетов и поставил галку, чтобы можно было вручную выбрать нужные пакеты для установки. Затем зашёл в «Базовую систему» и там отметил следующее:

- Основные
   - acpid
   - fedora-release-notes
   - krb5-workstation
   - man-pages
   - nano
   - nc
   - pam-krb5
   - sudo
   - tree
   - unzip
   - wget
   - yum-utils
   - zip
- Поддержка оборудования
- Системные средства
   - mc
   - samba-client

Затем, жду, пока система установится. Надо заметить, что с таким небольшим набором пакетов, система ставится очень быстро. После установки перезагружаем комп и настраиваем в биосе, чтоб он грузился с жёсткого диска.

Этап 1. Общая подготовка сервера.

Далее, нужно обновить установленную систему. А для этого надо, чтобы система имела выход в интернет, поэтому нужно настроить сеть. Открываем консольный файловый менеджер:

mc

и переходим в каталог /etc/sysconfig/network-scripts. В более ранних версиях федоры сетевые интерфейсы назывались eth0, eth1, eth2 и так далее, но в шестнадцатой федоре обозначение сетевых карт изменилось. Поскольку, сетевух на сервере у меня две, то у себя я в этом каталоге обнаружил файлы с названиями ifcfg-p2p1 и ifcfg-em0. И решил я их использовать обе на пользу. О том, как это сделать, я прочитал вот тут:

http://ru.gentoo-wiki.com/wiki/HOWTO_%CD%E0%F1%F2%F0%EE%E9%EA%E0_Bonding
http://techgurulive.com/2008/09/08/how-to-configure-bonding-in-fedora

Создаём файл /etc/modprobe.d/bonding.conf и наполняем его вот таким содержимым:

alias bond0 bonding
options bonding mode=6 miimon=100

Для себя, я решил использовать шестой режим объединения двух сетевых карт. Затем создаю файл /etc/sysconfig/network-scripts/ifcfg-bond0 и наполняю его вот таким содержимым:

DEVICE="bond0"
BOOTPROTO="none"
ONBOOT="yes"
IPADDR=192.168.0.201
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
DNS1=192.168.0.200

Сохраняю. Потом, в этом же каталоге, файл ifcfg-em0 привожу вот в такой вид:

DEVICE="em0"
HWADDR="00:1E:67:34:87:08"
BOOTPROTO="none"
ONBOOT="yes"
# NM_CONTROLLED="yes"
MASTER=bond0
SLAVE=yes

И файл ifcfg-p2p1 — в такой же идентичный вид:

DEVICE="p2p1"
HWADDR="08:00:27:7D:71:7C"
BOOTPROTO="none"
ONBOOT="yes"
# NM_CONTROLLED="yes"
MASTER=bond0
SLAVE=yes

После редактирования всех этих файлов, надо перезагрузить сервер. Когда он загрузится, то две сетевухи у нас будут работать как одна, обеспечивая бóльшую пропускную способность и отказоустойчивость.

Далее, находим файл /etc/resolv.conf и в него добавляем строчку:

nameserver 192.168.0.200

Таким образом, мы указали DNS-сервер нашей системе.

После этого, нужно обновить систему. Для начала обновим сам установщик yum:

yum -y update yum

А потом всю систему целиком:

yum -y update

Когда обновление завершится, то перезагружать систему не спешим. Сразу же подправим один конфиг, чтобы отключить SELinux. Находим файл /etc/selinux/config и в нём заменяем строчку:

SELINUX=enforcing

на:

SELINUX=disabled

И вот после этого перезагружаем систему. Кстати, если у вас после перезагрузки пропала запись о DNS-сервере в файле resolv.conf, то пропишите DNS-сервер снова, а потом дайте команду:

chattr +i /etc/resolv.conf

Это чтобы файл нельзя было изменять.

Вообще, надо сказать, что я начал статью с общей подготовки сервера, которую я уже ни раз описывал в других своих статьях. Повторяться не хочется, поэтому о том, как подкрутить sshd, настроить adcupsd, ntp и установить webmin читайте вот на этих страничках:

http://technotrance.su/index.php/moi-stati/linux-fedora/item/2-router-linux-part1
http://technotrance.su/index.php/moi-stati/linux-fedora/item/9-server-mail-ftp-jabber%20mail-gateway1
http://technotrance.su/index.php/moi-stati/linux-fedora/item/17-single-address-space

В Fedora 16 исключением станут лишь некоторые моменты, связанные с включением и запуском сервисов. Эти моменты я упомянул тут:

http://technotrance.su/index.php/moi-zametki/9-fedora-ntsysv

Однако, процесс ввода сервера в домен AD я опишу ещё раз. Прежде всего, заходим на сервер AD (у меня это win srv 2008 r2) и в оснастке DNS создаём «узел А» для нашего сервера 1с:

И обязательно ставим галочку, как это показано на скриншоте.

Далее, уже на 1с-сервере, ставим необходимые пакеты:

yum -y install samba samba-winbind samba-common samba-client samba-winbind-clients

Потом находим файл /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 = MYDOMAIN.DOMAIN
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 MYDOMAIN.DOMAIN = {
  kdc = 192.168.0.200
  admin_server = 192.168.0.200
 }

[domain_realm]
 .mydomain.domain = MYDOMAIN.DOMAIN
 mydomain.domain = MYDOMAIN.DOMAIN

где 192.168.0.200 — это адрес контроллера домена. Регистр соблюдаем! Далее, находим файл /etc/samba/smb.conf и приводим его вот к такому виду:

[global]
log file = /var/log/samba/log.%m
socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192
null passwords = yes
interfaces = p2p1
hosts allow = 192.168. 127.0.0.1
winbind uid = 50-99999999
winbind gid = 50-99999999
auth methods = winbind
winbind enum groups = yes
winbind enum users = yes
winbind use default domain = yes
name resolve order = hosts wins bcast lmhosts
case sensitive = no
dns proxy = no
server string = Linux
netbios name = 1cserv
password server = 192.168.0.200
realm = MYDOMAIN.DOMAIN
client signing = yes
local master = no
domain master = no
workgroup = MYDOMAIN
debug level = 2
security = ads
dos charset = 866
max log size = 50
os level = 0

Здесь также соблюдаем регистр! И последний файл, который надо отредактировать — это /etc/nsswitch.conf. Находим в нём следующие строчки:

passwd: files
shadow: files
group: files
initgroups: files

И правим их до такого вида:

passwd: files winbind
shadow: files
group: files winbind
initgroups: files winbind

После редактирования конфигов, надо не забыть открыть нужные порты на iptables:

-A INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 631 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 631 -j ACCEPT

А уже потом надо запустить/перезапустить следующие сервисы:

service smb restart
service nmb restart
service winbind restart

И не забыть их включить в автозагрузку:

systemctl enable smb.service
systemctl enable nmb.service
systemctl enable winbind.service

Теперь получаем билет керберос:

kinit admin@MYDOMAIN.DOMAIN

Где admin — это администратор домена в AD. Появится запрос пароля доменного администратора. И после ввода пароля команда должна отработать без вывода всяких сообщений — это означает, что билет получен корректно. Потом вводим сервер 1с в домен:

net ads join -U admin

Эта команда также попросит пароль доменного админа. И при её корректной отработке должно выйти сообщение:

Using short domain name -- MYDOMAIN
Joined '1CSERV' to realm 'mydomain.domain'

После этого, перезагружаем сервер. И после его загрузки тестируем, корректно ли он зашёл в домен AD. Делаем это вот такими командами (я сразу буду показывать какой вывод после них должен быть):

wbinfo -t
checking the trust secret for domain MYDOMAIN via RPC calls succeeded
wbinfo -p
Ping to winbindd succeeded
wbinfo -u
admin
гость
krbtgt
user1
user2
user3
......и т.д. пользователи домена
wbinfo -g
компьютеры домена
контроллеры домена
администраторы схемы
администраторы предприятия
издатели сертификатов
администраторы домена
пользователи домена
гости домена
владельцы-создатели групповой политики
серверы ras и ias
группа с разрешением репликации паролей rodc
группа с запрещением репликации паролей rodc
контроллеры домена - только чтение
контроллеры домена предприятия - только чтение
.............и т.д. группы домена
id admin
uid=50(admin) gid=56(администраторы домена) группы=56(администраторы домена),57(группа с запрещением репликации паролей rodc),59(администраторы схемы),60(администраторы предприятия),61(владельцы-создатели групповой политики),62(пользователи домена)

Всё, на этом общую настройку сервера можно считать завершённой.

Этап 2. Сборка PostgreSQL и установка 1C. 

После общей настройки сервера приступим к установке PostgreSQL. На сайте 1С выложены готовые rpm-пакеты уже пропатченого PostgreSQL. Но я не решился их ставить. Потому как, там же есть и src.rpm-ка, которую можно пересобрать под свою систему. На момент написания статьи, это был пакет postgresql-9.0.3-3.1C.src.rpm. Итак, приступим к его пересборке. В этом мне помогли вот эти ресурсы:

http://www.alsigned.ru/?p=329
http://bugs.etersoft.ru/show_bug.cgi?id=4458
http://www.alsigned.ru/?p=1129

Сначала установим программу rpm-build, с помощью которой и будем делать пересборку:

yum -y install rpm-build

После чего, на сервер надо скопировать postgresql-9.0.3-3.1C.src.rpm. Я такие вещи делаю через webmin в меню Others → Upload and Download. Затем, перехожу в папку, в которую скопировал и выполняю вот такую команду:

rpmbuild --rebuild postgresql-9.0.3-3.1C.src.rpm

Сразу получаю вот такую ошибку:

ошибка: Неудовлетворенные зависимости сборки:
        glibc-devel нужен для postgresql-9.0.3-3.1C.x86_64
        bison нужен для postgresql-9.0.3-3.1C.x86_64
        flex нужен для postgresql-9.0.3-3.1C.x86_64
        readline-devel нужен для postgresql-9.0.3-3.1C.x86_64
        zlib-devel >= 1.0.4 нужен для postgresql-9.0.3-3.1C.x86_64
        openssl-devel нужен для postgresql-9.0.3-3.1C.x86_64
        pam-devel нужен для postgresql-9.0.3-3.1C.x86_64

Это значит, что перед сборкой PostgreSQL, нам надо установить недостающие вышеперечисленные пакеты. Ставим их:

yum -y install glibc-devel bison flex readline-devel zlib-devel openssl-devel pam-devel

Затем, снова пробуем выполнить предыдущую команду. И, на этот раз, получим вот такую ошибку:

1 out of 5 hunks FAILED -- saving rejects to file src/Makefile.global.in.rej

Чтобы исправить эту ошибку открываем файл /usr/lib/rpm/macros находим в нем строчку

%_default_patch_fuzz 0

и заменяем ее на

%_default_patch_fuzz 2

Потом, снова пытаемся запустить сборку постгре-скуля. И получаем очередную ошибку:

configure: error: in `/root/rpmbuild/BUILD/postgresql-9.0.3':
configure: error: no acceptable C compiler found in $PATH

Эта ошибка означает, что у нас не установлен компилятор. Поэтому, ставим пакеты, которые обычно необходимы для сборки:

yum -y install gcc gcc-c++ automake cmake make

После этого, я решил, на всякий случай, перезагрузить сервер и почистить каталог /root/rpmbuild. А потом снова пробую запустить сборку пакетов:

rpmbuild --rebuild postgresql-9.0.3-3.1C.src.rpm

На этот раз, сборка вроде пошла, но через какое-то время выходит очередная ошибка:

mchar.h:7:27: fatal error: unicode/uchar.h: No such file or directory
compilation terminated.
make[1]: *** [mchar_io.o] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/postgresql-9.0.3/contrib/mchar'

Решается она установкой вот этих пакетов:

yum -y install libicu libicu-devel

Потом пробуем запустить сборку снова, почистив перед этом каталог /root/rpmbuild. И после этого, всё равно, вылезет уже другая ошибка:

pg_regress: initdb failed
Examine /root/rpmbuild/BUILD/postgresql-9.0.3/src/test/regress/log/initdb.log for the reason.

Ошибка говорит о том, что надо посмотреть, что написано в логе /root/rpmbuild/BUILD/postgresql-9.0.3/src/test/regress/log/initdb.log. Заглянув в него, чётко видно следующее: initdb: cannot be run as root. Сие означает, что оказывается сборку надо запускать не от рута, а от обычного пользователя. Поэтому, создаём пользователя:

adduser admin1
passwd admin1

Логинимся в систему под созданным пользователем, и уже под ним точно такой же командой запускаем сборку. Но рано радоваться! УлыбаюсьСборка продвинется дальше, однако всё равно закончится вот такой ошибкой:

install: cannot stat `/usr/local/lib64/libicuuc.so.46': No such file or directory

И это, как выяснилось, он просто не может найти вот эти библиотеки: libicuuc.so.46, libicui18n.so.46 и libicudata.so.46. Тем не менее, если пройтись по системе поиском, то мы обнаружим, что все эти библиотеки есть, но находятся в каталоге /usr/lib64. Чтобы обойти проблему, мы просто сделаем вот такие символические ссылки:

ln -s /usr/lib64/libicuuc.so.46.0 /usr/local/lib64/libicuuc.so.46
ln -s /usr/lib64/libicui18n.so.46.0 /usr/local/lib64/libicui18n.so.46
ln -s /usr/lib64/libicudata.so.46.0 /usr/local/lib64/libicudata.so.46

Затем, снова запустим сборку под обычным пользователем, не забыв, при этом, почистить папку ~/rpmbuild. И вот оно! Да! Наконец то, сборка завершилась удачно!

Готовые к установке rpm-ки можно найти в каталоге ~/rpmbuild/RPMS/x86_64. Собственно, прямо от туда, их можно и установить, выполнив команду, находясь в каталоге с rpm-ками:

rpm -ivh *.rpm

Многие спросят, а зачем всё это было нужно, если уже есть готовые rpm-пакеты от 1с. Я же считаю, что postgresql, собранный под конкретно свою ОС будет работать лучше, тем более что пересобрать src.rpm, на самом деле, очень легко. Просто я специально расписал все те грабли, на которые можно наткнуться при сборке под федору. Однако, если же перед сборкой сразу провести всю необходимую подготовку, а именно:

yum -y install glibc-devel bison flex readline-devel zlib-devel openssl-devel pam-devel gcc gcc-c++ automake cmake make libicu libicu-devel
ln -s /usr/lib64/libicuuc.so.46.0 /usr/local/lib64/libicuuc.so.46
ln -s /usr/lib64/libicui18n.so.46.0 /usr/local/lib64/libicui18n.so.46
ln -s /usr/lib64/libicudata.so.46.0 /usr/local/lib64/libicudata.so.46

и в файле /usr/lib/rpm/macros поменять «%_default_patch_fuzz 0» на «%_default_patch_fuzz 2», то сборка пройдёт с первого раза. Ну, и запускать сборку надо от простого пользователя.

После установки postgresql запустим вот такую команду:

service postgresql initdb

чтобы инициализировалась база данных. Когда команда отработает, то в каталоге /var/lib/pgsql/data появятся конфигурационные файлы. После чего, можно перейти к редактированию конфига postgresql. В этом мне помогли вот эти материалы:

http://www.lissyara.su/archive/1c_8.2+postgresql
http://wiki.etersoft.ru/PostgreSQL/Optimum

Ниже буду приводить лишь те строчки, которые я менял в файле postgresql.conf:

# Дополнительный буфер между диском и процессами Postgre SQL.
# Не следует указывать слишком большой объем,
# т.к. еще существует системный Кэш, контролируемый ОС.
# Значения:
# Средний объём данных и 256–512 МБ доступной памяти: 16–32 МБ
# Большой объём данных и 1–4 ГБ доступной памяти: 64–256 МБ
shared_buffers = 128MB

# Буфер под временные объекты, в основном для временных таблиц.
# Можно установить порядка 16 МБ
temp_buffers = 8MB

# Специальная память, используется для сортировки и
# кэширования таблиц, для одного запроса.
# При задании этого параметра следует учитывать количество
# конкурентых запросов, выполняемых в один момент времени.
# При памяти 1–4Gb рекомендуется устанавливать 32–128MB
work_mem = 16MB

# Память использующаяся для операций VACUUM, CREATE INDEX,
# ALTER TABLE и FOREGIN KEY.
# Следует устанавливать большее значение, чем для work_mem.
# Слишком большие значения приведут к использованию свопа.
# При памяти 1–4Gb рекомендуется устанавливать 128–512MB
maintenance_work_mem = 32MB

# Специальный стек для сервера, в идеале он должен совпадать
# с размером стека, выставленном в ядре ОС. Установка большего значения
# чем в ядре может привести к ошибкам. Рекомендуется устанавливать 2–4MB
max_stack_depth = 2MB

# Данный параметр отвечает за сброс данных из кэша на диск при завершении
# транзакций. Если установить его значение fsync=off, то данные не будут
# записываться на дисковые накопители сразу после завершения операций.
# Это может существенно повысить скорость операций insert и update, но
# есть риск повредить базу, если произойдет сбой (неожиданное отключение
# питания, сбой ОС, сбой дисковой подсистемы). Используйте эту возможность
# только если у вас имеются надежные ИБП и программное обеспечение,
# завершающее работу системы при низком заряде батарей.
fsync = off

# Установите данный параметр в off, если fsync=off
full_page_writes = off

# Количество памяти используемое в SHARED MEMORY для ведения транзакционных
# логов. При доступной памяти 1–4GB рекомендуется устанавливать 256–1024kb
wal_buffers = 2048kB

# увеличиваем этот параметр до 16. (в своё время, когда я уже настроил сервер,
то система в логах сама просила увеличить этот параметр)
checkpoint_segments = 16

# Передает данные планировщику запросов об объеме памяти, которая используется
# ОС для кэширования файлов, для одного запроса.
# (Устанавливаем в половину оперативки)
effective_cache_size = 1024MB

# Включает или отключает использование планером ограничений CONSTRAINT в
# таблицах при построении запросов. Рекомендуется установить значение on,
# при этом, если Вы изменяете CONSTRAINT у таблиц, необходимо обновить их
# статистику выполнив ANALYZE, в противном случае будут построены неверные
# планы запросов.
constraint_exclusion = on

# указываем писать логи в системный лог
log_destination = 'syslog'

# Включать ли автовакуум, устанавливать on
autovacuum = on

# Пауза между запусками Автовакуума. Зависит от того, как часто обновляются
# данные в ваших таблицах. Может составлять порядка 5min, по умолчанию 1min
autovacuum_naptime = 3min

# Продолжительность времени в секундах между проверками на дедлок. Для загруженных серверов имеет смысл это значение увеличить. По умолчанию − 1s.
deadlock_timeout = 2s

# Количество блокировок за одну транзакцию: установить порядка 200-250
max_locks_per_transaction = 250

# Чтобы вновь создаваемые таблицы посредством клиента psql автоматически включали столбец OID.
default_with_oids = on

# Отключаем вывод предупреждений при нахождении слэша в запросе
escape_string_warning = off

После редактирования конфига пробуем запустить postgresql:

service postgresql start

Однако, он, скорей всего, не запустится и в логах выдаст примерно во такую ошибку:

[1-1] FATAL: could not create shared memory segment: Недопустимый аргумент
[1-2] DETAIL: Failed system call was shmget(key=5432001, size=148946944, 03600).
[1-3] HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 148946944 bytes), reduce PostgreSQL's shared_buffers parameter (currently 16384) and/or its max_connections parameter (currently 104).
[1-4] #011If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
[1-5] #011The PostgreSQL documentation contains more information about shared memory configuration.

Здесь надо обратить внимание на цифру 148946944. Это означает, что необходимо увеличить параметр SHMMAX в системе. Но встаёт вопрос о том, как же его правильно задать. В этом мне помогла статья, которую я нашёл сразу на двух ресурсах. Уж не знаю, кто из них первоисточник, поэтому привожу ссылки на оба этих ресурса:

http://wiki.ayac.ru/skripty/nastrojka-shared-memory
http://leopard.in.ua/2011/02/05/nastrojka-shared-memory-dlya-postgresql-sovety

Выложу этот скрипт и у себя тоже:

#!/bin/bash
# simple shmsetup script
page_size=`getconf PAGE_SIZE`
phys_pages=`getconf _PHYS_PAGES`
shmall=`expr $phys_pages / 2`
shmmax=`expr $shmall \* $page_size`
echo kernel.shmmax = $shmmax
echo kernel.shmall = $shmall

Загрузив скрипт и запустив его, я, для своего сервера, получил вот такие значения:

kernel.shmmax = 1050689536
kernel.shmall = 256516

Затем, скопировал эти строчки и добавил их в конец файла /etc/sysctl.conf. Перезагружаю сервер и снова пробую запустить postgresql. На этот раз postgresql запустился удачно.

Поэтому сразу установим пароль на пользователя postgres:

su -l postgres
psql
alter user postgres with password 'YOUR_PASSWORD';
\q
exit

Теперь настало время установить саму 1С. Копируем готовые rpm-ки в какой-нибудь каталог:

1C_Enterprise82-common-8.2.15-310.x86_64.rpm
1C_Enterprise82-server-nls-8.2.15-310.x86_64.rpm
1C_Enterprise82-common-nls-8.2.15-310.x86_64.rpm
1C_Enterprise82-ws-8.2.15-310.x86_64.rpm
1C_Enterprise82-server-8.2.15-310.x86_64.rpm
1C_Enterprise82-ws-nls-8.2.15-310.x86_64.rpm

И устанавливаем их вот такой командой:

rpm -ivh *.rpm

Обратим внимание, что в системе у нас появится пользователь usr1cv82 и группа grp1cv82, а демон 1С-сервера будет называться srv1cv82. И сама 1С-ка установилась в каталог /opt/1C. Нужно пользователя usr1cv82 сделать владельцем этого каталога, а группу grp1cv82 сделать владеющей группой этого каталога:

chown -R usr1cv82:grp1cv82 /opt/1C

Затем надо включить логи для сервера 1С. Для этого, сначала, создадим каталог для хранения логов:

mkdir /var/log/1c
chown usr1cv82:grp1cv82 /var/log/1c

А затем, в папку /opt/1C/v8.2/x86_64/conf надо поместить конфиг с названием logcfg.xml. Именно с таким названием. А содержимое конфига будет вот такое:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="/var/log/1c/" history="168">
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>

И не забываем настроить права к нему:

chown usr1cv82:grp1cv82 /opt/1C/v8.2/x86_64/conf/logcfg.xml

Также, не забываем открыть нужные порты на сервере. В стандартном виде они вот такие: 1540,1541, 5432, 1560:1591. Правила в iptables будут вот такими:

-A INPUT -p tcp -m tcp -m multiport -m state --state NEW -j ACCEPT --dports 1540,1541,5432
-A INPUT -p tcp -m tcp -m state --dport 1560:1591 --state NEW -j ACCEPT

Перезапускаем iptables, чтобы изменения вступили в силу:

service iptables restart

Далее, нужно попробовать, с помощью виндовой консоли администрирования, подключиться к серверу. А потом — попробовать создать базу прямо из самой 1с.

Этап 3. Настройка вэб-доступа, установка HASP, решение проблем.

Когда создадите базу и зальёте в неё какую-нибудь конфигурацию, а затем попытаетесь в неё зайти, то получите ошибку:

Ошибка инициализации графической подсистемы.

То это означает, что на сервер надо установить необходимые шрифты. В этом мне помогли вот эти статьи:

http://www.easycoding.org/2011/08/14/ustanovka-microsoft-core-fonts-v-fedora.html
http://www.alsigned.ru/?p=416

Сначала установим все нужные пакеты (некоторые из них уже стоят):

yum -y install gcc gcc-c++ make rpm-build cabextract ttmkfdir popt-devel unixODBC ImageMagick libgsf ttf2pt1 xfs

После этого, собираем пакеты для установки необходимых шрифтов:

wget "http://www.easycoding.org/linux/srpms/chkfontpath-1.10.1-2.src.rpm"
rpmbuild --rebuild chkfontpath-1.10.1-2.src.rpm

Собранный пакет появится тут: ~/rpmbuild/RPMS/x86_64. Перейдя в этот каталог, установим его:

rpm -ivh chkfontpath-1.10.1-2.fc16.x86_64.rpm

Затем, собираем второй пакет:

wget "http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec"
rpmbuild -ba msttcorefonts-2.0-1.spec

Собранный, он появится вот тут: ~/rpmbuild/RPMS/noarch. Также, перейдя в этот каталог, установим его командой:

rpm -ivh msttcorefonts-2.0-1.noarch.rpm

После чего, переходим в каталог /opt/1C/v8.2/x86_64/utils и, находясь в нём, выполняем вот такую команду:

./config_server /usr/share/fonts/msttcorefonts

При этом, у меня вылезла вот такая ругань:

Please install following package: libglib

Но установка пакета glib эту ситуацию не исправила. Тем не менее, я перезапустил сервер 1с:

service srv1cv82 restart

И после этого, ошибка про инициализацию графической подсистемы больше не выходила.

Теперь, настало время рассмотреть настройку веб-доступа к нашему серверу 1с. Мне в помощь пришли вот эти статьи:

http://www.alsigned.ru/?p=416
http://pg1c.ru/?page_id=129

Для начала, ставим apache:

yum -y install httpd

И, на всякий случай, если система сама не включила его в автозагрузку, выполняем команду:

systemctl enable httpd.service

Далее, нам надо определиться, где будет располагаться файл веб-интерфейса. Для каждой базы надо делать свой такой каталог. Файл вэб-интерфайса к моей базе будет располагаться вот тут:

mkdir /var/www/ut-11

Затем, переходим в каталог /opt/1C/v8.2/x86_64 и, находясь в нём, выполняем команду:

./webinst -apache22 -wsdir ut-11 -dir '/var/www/ut-11/' -connStr 'Srvr=1cserv;Ref=base1' -confPath /etc/httpd/conf/httpd.conf

Где:
-wsdir – имя алиаса, используемого на веб-сервере для соединения с базой. В последствии мы будем обращаться к ней набирая в браузере http://адрес.сервера/ut-11
-dir – директория где будет располагаться файл web-интерфейса 1с (файл  default.vrd)
-connStr – строка соединения с базой 1с предприятия, в которой Srvr – адрес сервера 1С предприятия, а Ref – имя базы.
-confPath – расположение конфигурационного файла web-сервера apache

Не забудем исправить права доступа к файлу default.vrd:

chown -R apache:apache /var/www/ut-11

и открыть 80-ый порт на iptables:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

Затем, стартуем апач:

service httpd start

А потом пробуем зайти по адресу:

http://1cserv/ut-11

Где, в моём случае, 1cserv — это адрес сервера 1с предприятие, а ut-11 — это вышеописанный алиас в апаче. Кстати, если у вас нет Active Directory или DNS-сервера в локальной сети, то вам и на сервере, и на клиенте надо будет обязательно добавить запись в файле hosts. (Возможно, об этом надо было упомянуть в самом начале статьи...) Выглядеть она будет так:

192.168.0.201  1cserv

(IP-шник и имя, соответственно, пишите свои)

Итак, после того, как вы попробуете зайти в свою базу через вэб-доступ, вы получите вот такую ошибку:

о том, что не обнаружен ключ защиты программы.

Ситуация невесёлая Улыбаюсь  Однако, у меня ключ куплен, и его просто надо вставить в сервер. Но для того, чтобы система его увидела, нужно поставить драйвер HASP. На CD-диске, который прилагается к купленному ключу, этот драйвер есть. Однако, он там лежит в исходниках и человеческой инструкции, как его установить, я не нашёл. Немного погуглив, я вспомнил, что есть контора с названием Etersoft. И у этого самого Етерсофта в публичном доступе выложены уже готовые собранные rpm-пакеты драйвера HASP. Точнее, в эти пакеты включён и драйвер USB-ключа HASP, и LPT-ключа HASP, и HASP-manager. Для Fedora 16 x86_64 эти пакеты находятся тут:

ftp://updates.etersoft.ru/pub/Etersoft/HASP/3.3/x86_64/Fedora/16/

Для остальных же систем, не только федоры, его надо поискать вот в этом каталоге:

ftp://updates.etersoft.ru/pub/Etersoft/HASP/3.3/

Итак, скачиваю и устанавливаю эти пакеты:

wget ftp://updates.etersoft.ru/pub/Etersoft/HASP/3.3/x86_64/Fedora/16/haspd-3.3-eter3fedora.x86_64.rpm
wget ftp://updates.etersoft.ru/pub/Etersoft/HASP/3.3/x86_64/Fedora/16/haspd-modules-3.3-eter3fedora.x86_64.rpm
rpm -ivh haspd-3.3-eter3fedora.x86_64.rpm haspd-modules-3.3-eter3fedora.x86_64.rpm

и получаю вот такое сообщение:

ошибка: Неудовлетворенные зависимости:
        libc.so.6 нужен для haspd-3.3-eter3fedora.x86_64
        libc.so.6(GLIBC_2.0) нужен для haspd-3.3-eter3fedora.x86_64
        libc.so.6(GLIBC_2.1) нужен для haspd-3.3-eter3fedora.x86_64
        libc.so.6(GLIBC_2.1.2) нужен для haspd-3.3-eter3fedora.x86_64
        libc.so.6(GLIBC_2.2) нужен для haspd-3.3-eter3fedora.x86_64
        libdl.so.2 нужен для haspd-3.3-eter3fedora.x86_64
        libdl.so.2(GLIBC_2.0) нужен для haspd-3.3-eter3fedora.x86_64
        libdl.so.2(GLIBC_2.1) нужен для haspd-3.3-eter3fedora.x86_64
        libm.so.6 нужен для haspd-3.3-eter3fedora.x86_64
        libm.so.6(GLIBC_2.0) нужен для haspd-3.3-eter3fedora.x86_64
        libpthread.so.0 нужен для haspd-3.3-eter3fedora.x86_64
        libpthread.so.0(GLIBC_2.0) нужен для haspd-3.3-eter3fedora.x86_64
        libpthread.so.0(GLIBC_2.1) нужен для haspd-3.3-eter3fedora.x86_64

Это ему не хватет покета glibc.i686. Ставим его:

yum -y install glibc.i686

После установки этого пакета снова пробуем установить скачанные с Etersoft пакеты драйвера HASP. На этот раз, всё пройдёт удачно:

rpm -ivh haspd-3.3-eter3fedora.x86_64.rpm haspd-modules-3.3-eter3fedora.x86_64.rpm
Подготовка...     ########################################### [100%]
   1:haspd                  ########################################### [ 50%]
Loading HASP LPT kernel module...  (/dev/lp0 device has not found)      [PASSED]
Check kernel for CONFIG_USB_DEVICEFS...                                 [ DONE ]
Mounting usbdevfs to /proc/bus/usb (it can be insecure)...              [ DONE ]
Running aksusbd...                                                      [ DONE ]
Running winehasp...                                                     [ DONE ]
Running hasplm...                                                       [ DONE ]
Running hasplmd...                                                      [ DONE ]
   2:haspd-modules          ########################################### [100%]
Stopping hasplmd... ..                                                  [ DONE ]
Stopping hasplm...                                                      [ DONE ]
Stopping winehasp...                                                    [ DONE ]
Stopping aksusbd...                                                     [ DONE ]
Stopping skeyd...                                                       [PASSED]
Stopping usbsentinel...                                                 [PASSED]
Stopping SntlKeysSrvrlnx...                                             [PASSED]
Unloading HASP LPT kernel module...                                     [PASSED]
Loading HASP LPT kernel module...  (/dev/lp0 device has not found)      [PASSED]
Running aksusbd...                                                      [ DONE ]
Running winehasp...                                                     [ DONE ]
Running hasplm...                                                       [ DONE ]
Running hasplmd...                                                      [ DONE ]

Чтобы система корректно увидела ключ, надо перезагрузить сервер, но пока не спешим это делать. Сразу же, подправим конфиг /etc/haspd/hasplm.conf. Добавим в него строчку:

NHS_IP_LIMIT = 127.0.0.1, 192.168.0.0/16

Именно в этой строчке мы перечисляем сети и хосты, которые смогут видеть HASP-ключ. Также, нужно помнить про фаервол. Нужно чтобы был открыт порт 475 в обе стороны, причём, и для TCP-пакетов, и для UDP-пакетов. Поэтому в /etc/sysconfig/iptables добавляем вот такие строчки:

-A INPUT -p udp -m udp -m multiport -m state --ports 475 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport -m state --ports 475 --state NEW -j ACCEPT

Вот теперь нужно перезагрузить сервер. И после его загрузки снова попробовать зайти в базу через вэб-доступ.

И на этом всё, сервером 1с можно пользоваться.

Примечание: Почему-то у меня, после перезагрузки сервера, демон 1с предприятия никак не хотел автоматически стартовать... Вручную запускается благополучно. Решение оказалось простым. Находим скрипт запуска демона /etc/init.d/srv1cv82 и в самый-самый его верх добавляем строчку:

#!/bin/bash

Этап 4. Настройка прозрачной авторизации пользователей через kerberos.

Поскольку у меня есть Active Directory, то почему бы не настроить авторизацию пользователей 1с через неё? Тем более, что 1с это поддерживает. В линуксе мы это сделаем через kerberos.

В настройке всего этого мне помогла вот эта статья:

http://kb.1c.ru/articleView.jsp?id=49

Сперва наперво, на контроллере домена надо создать keytab-файл и пользователя, с которым он будет ассоциироваться. Пользователь – это самый обычный пользователь без каких-либо особых привилегий. Называться он будет usr1cv8, и пароль у него будет pass1cv8.

Напомню, что у меня контроллер домена на Windows server 2008 R2. После того, как создали пользователя, открываем виндовую командную строчку и делаем вот такую команду:

ktpass /crypto ALL /princ usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN /mapuser usr1cv8 /pass pass1cv8 /out c:\111\usr1cv82.keytab

где параметр /crypto ALL позволяет использовать любой тип шифрования
параметр /princ usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN – это имя службы, с которой будет ассоциирован виндовый пользователь usr1cv8.
Само собой, что вместо 1cserv.mydomain.domain@MYDOMAIN.DOMAIN вы должны подставить имя своего сервера 1с и название своего домена AD.
параметр /out C:\111\usr1cv82.keytab – название keytab-файла и путь, куда его положить.

Итак, после выполнения этой команды получим файл C:\111\usr1cv82.keytab, который надо скопировать на наш линуховый сервер 1С и положить его в каталог /opt/1C/v8.2/x86_64. Если хотите, чтоб keytab-файл у вас лежал в каком-либо другом каталоге, то в конфиге /etc/sysconfig/srv1cv82 надо подправить параметр:

SRV1CV8_KEYTAB

Далее, нам надо посмотреть, корректен ли наш keytab-файл. Вводим команду:

klist -e -k -t /opt/1C/v8.2/x86_64/usr1cv82.keytab

и если вывод такой:

Keytab name: WRFILE:/opt/1C/v8.2/x86_64/usr1cv82.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 01/01/70 05:00:00 usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN (des-cbc-crc)
3 01/01/70 05:00:00 usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN (des-cbc-md5)
3 01/01/70 05:00:00 usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN (arcfour-hmac)
3 01/01/70 05:00:00 usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN (aes256-cts-hmac-sha1-96)
3 01/01/70 05:00:00 usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN (aes128-cts-hmac-sha1-96)

то значит всё в порядке.

Если вы эту статью читаете с самого начала, то помните, что сервер мы уже ввели в домен. И когда это делалось, то использовалась обычная команда kinit admin@MYDOMAIN.DOMAIN, которая уже выдала нашему серверу билет kerberos. Чтобы удалить этот билет, делаем вот такую простую команду:

kdestroy

Затем указываем керберосу, что надо использовать наш keytab-файл:

kinit -k -t /opt/1C/v8.2/x86_64/usr1cv82.keytab usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN

команда должна отработать без вывода каких-либо сообщений – это означает, что всё хорошо. Затем смотрим полученный билет:

klist

вывод должен быть примерно таким:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: usr1cv82/1cserv.mydomain.domain@MYDOMAIN.DOMAIN

Valid starting Expires Service principal
12/13/12 11:46:26 12/13/12 21:46:26 krbtgt/MYDOMAIN.DOMAIN@MYDOMAIN.DOMAIN
          renew until 12/20/12 11:46:26

Собственно, на этом всё. Осталось проверить, работает ли прозрачная авторизация на практике. Подозреваю, что у вас уже есть какая-нибудь база. Важным моментом является то, что в её свойствах аутентификации надо выставить крыж «выбирать автоматически»:

Далее, в конфигураторе надо создать или изменить пользователя, сопоставив его с пользователем AD. Прописываться он должен вот в таком формате:

Ну или проще его выбрать из списка, нажав кнопку с многоточием. Выбирать надо из третьего списка, где домен представлен вида mydomain.domain.

Прочитано 21817 раз Последнее изменение Вторник, 17 Июнь 2014 15:22

Комментарии  

Alex
+2 # Alex 13.12.2013 22:35
Статья на 100баллов!! Автору огромное спасибо за систематизацию инфы.
Ответить

Добавить комментарий

Защитный код
Обновить

Вы здесь: Home Мои статьи Linux Fedora Установка и настройка сервера 1С под Linux