Пользователь
0,0
рейтинг
23 октября 2012 в 03:08

Администрирование → Как установить 1С Предприятие 8.2 (релиз 8.2.16.368 от 05.10.12) на линукс CentOS 6.3 (статья, HowTo) из песочницы tutorial

Предупреждение: Никаких подробных инструкций не будет! Только последовательность действий, необходимые шаги и наводки. Это руководство только для опытных администраторов Линукс!

Примеры некоторых моих конфигов прилагаются...

Замечание: эта статья написана на основе экспериментов с 32-битным CentOS 6.3 (Для сервера необходимо использовать 64-битную ОС. Но так получилось, что на доступном мне для экспериментов железе 64-битный CentOS не установился.) Однако разницы для методики установки нет (32 vs 64bit) — она только в суффиксах дистрибутивных файлов: либо i686 (или i386), либо x86_64…

Содержание:






0) Подготавливаем серверное железо



Конкретных рекомендаций по выбору серверного железа (какой мощности железо требуется) давать не буду — нет личного опыта. Смотрите официальные «Рекомендации по выбору оборудования для работы с 1С: Предприятием 8» от v8.1c.ru и неофициальные «Требования к компьютеру для работы с программой 1С: Предприятие 8» от 1c.xxi.kiev.ua…
И рекомендую брать железо с запасом мощности, чем рекомендуемое (потому что «на вырост» потребностей предприятия; и потому что Платформа 1С тоже постоянно «растёт и оптимизируется» — значит потребляет от релиза к релизу всё больше ресурсов).

Вдобавок, в двух словах, наиболее выгодна следующая стратегия:
  • Разнести два сервера (сервер 1С и сервер СУБД Postgres) по двум разным машинам — мощность наращивается в два раза, а лишних лицензий покупать не надо. Это и дешёвое решение: Линукс бесплатен, а стоимость железа не в счёт (железо всегда дешевле лицензий).
  • Примечание: учтите, что «кластер серверов 1С» ещё очень глючный. Причём, каждая дополнительная отдельная машина под «Сервер 1С в составе кластера» — требует покупки отдельной «Лицензии на Сервер»! Поэтому, со всех сторон, под «Сервер 1С» выгоднее всего использоватьТОЛЬКО ОДНУ МАШИНУ — купите под сервер только одну машину, с достаточно мощным железом, которое способно тянуть всю нагрузку...
  • В сервер СУБД установить аппаратный RAID10 (файлы БД резервированы, а объём дискового пространства наращивать по необходимости).
    Причём: В бюджетных рещениях, вполне достаточно использовать Чипсетный RAID-контроллер, встроенный во многие современные материнские платы, чем покупать отдельный и дорогой Аппаратный RAID-контроллер (цена которых от $250). Встроенные чипсетные RAID-контроллеры уже имеют широкий функционал; поддерживают необходимые режимы RAID (0, 1, 5, 10) и автоматизированную миграцию между ними, с сохранением данных.
    Есть только одна но существенная ложка дёгтя: плохая поддержка аппаратных RAID-контроллеров в ОС Linux. И к тому же, встроенный в материнскую плату чипсетный SATA-RAID не является полностью аппаратным: управление данными происходит не на уровне самого «железа», а на уровне микрокода BIOS через драйвер ОС — отсюда и такие понятия как «драйвера на SATA-RAID» (Intel Matrix Storage Driver), без которых RAID видится как отдельные диски — отсюда и проблемы поддержки… Под Linux — традиционно используются программные RAID-массивы, поддержка которых уже давно реализована и отлажена!
  • Оба сервера конечно поднимать на ОС windows/linux 64bit (т.к. поддерживают много ОЗУ и большую мощность). А «сервер 1С» купить и установить 32bit (потому что «Сервер 1С 64bit» стоит в 2 раза больше, а прирост производительности при прочих равных условиях даёт лишь +5%!!! неофициально умельцы тестировали...)





1) Устанавливаем Операционную Систему (ОС)



Установить линукс CentOS 6.x (последний релиз), лучше 64bit.
Причины выбора дистрибутива CentOS: Это серверный дистрибутив линукс. Это свободный (бесплатный, «Community Edition») дистрибутив. Это дистрибутив основанный на ядре RedHat, который 1С декларирует как «поддерживаемый».

Образы дистрибутива CentOS качаются отсюда (с любого из зеркал).
Удобнее выкачать iso, прожечь на болвань (DVDRW) и с неё ставить.
Для установки, как правило, достаточно только первого диска из двух компонуемых (на втором диске — всякий второстепенный софт).
А потом установочные дистки уже не нужны — всё равно весь софт нужно обновлять и доставлять через Интернет...


Замечание: Пользователь root в системе CentOS нелогинный (должен быть)!
Вся работа в системе CentOS ВСЕГДА осуществляется из сеанса обычного пользователя, в т.ч. и установка/настройка системы. И только для некоторых действий каждый раз запрашиваются привилегии «суперпользователя» (нечто подобное появилось и в Windows7).
Поэтому для выполнения правки конфигов, установки пакетов и прочих «админских» действий — открыв консоль в сеансе обычного пользователя, сразу выполняем команду «su», которая переключит текущую консоль в режим «суперпользователя» (фича CentOS):
	bash# su
	Пароль: <вводим пароль root>

Далее эта консоль bash# используется для разных привилигированных действий. Например, можно запустить «mc» и править конфиги в /etc/…




2) Настраиваем Сеть



Настроить сетевые адаптеры, имя хоста, gateway и DNS…
Подключиться к Интернет и обновить все базовые пакеты до последних версий…
Все дальнейшие действия будем делать только при наличии подключения к Интернет, считаем что оно постоянно!

Настройка сети осуществляется стандартно… Но есть распространённые Грабли, которые надо обойти:

2a)


Первое – имя нашего сервера должно без проблем разрешаться в IP-адрес.

В файле /etc/sysconfig/network проверяем значение параметра hostname («имя компьютера» севера), при необходимости меняем, что бы новые параметры вступили в силу нужно перезапустить систему.
	bash# cat /etc/sysconfig/network
	NETWORKING=yes
	NETWORKING_IPV6=no
	HOSTNAME=delldev
	GATEWAY=192.168.10.2    

(Последняя строчка — шлюз по-умолчанию, указывать необязательно. Если не указан — он будет браться из конфигов ifcfg или по DHCP...)

В файле /etc/hosts не должно быть записей формата localhost.localdomian или относящихся к IPv6, в случае отсутствия DNS-сервера в нем должно быть прописано четкое соответствие IP-адрес сервера – FQDN имя – короткое имя. Пример правильного файла hosts:
	bash# cat /etc/hosts
	127.0.0.1 localhost delldev


Проверка: пингует ли сервер сам себя? Введите в консоли:
	bash# ping delldev


2b)


Второе – на файрволе не должно быть правил запрещающих взаимодействие между собой компонентов 1с предприятия.
В большинстве случаев сервер 1с предприятия находится в пределах локальной сети, поэтому мы вполне может отключить файрвол (хотя бы на время пуско-наладки):
	bash# chkconfig iptables off
	bash# service iptables stop


2c)


Третье – необходимо также отключить SELinux policy!

Причины:
1) Ранее SELinux был причиной ошибки Segmentation Fault.
2) Со включенным SELinux не работают шары Samba (удалённые пользователи в шары заходят, но файлы не видят… или файлы видятся, но не читаются… и т.п. глюки)
3) Кроме того, плюсы от использования SELinux на высоко-нагруженном сервере, находящемся в пределах локальной сети, — выглядят крайне туманно.

Как отключить:
	Редактируем конфиг /etc/selinux/config
	строку SELINUX=enforcing
	меняем на SELINUX=disabled
	перегружаем машину...


2d)


У интернет провайдера «Укртелеком/Украина» есть ещё такие грабли: глючные DNS сервера — поэтому нужно использовать вспомогательные (лучше от Google)… А ещё возможно мой DSL-роутер оказался плохо совместим с ОС Линукс…

Симптом: при работе с Интернет, резолвинг каждого DNS-имени происходит очень долго (несколько [десятков] секунд таймаута), работать очень плохо…
Решение: Поэтому я сервера DNS не получал автоматически через DHCP, а статически прописал в настройках адаптера (в конфиге /etc/sysconfig/network-scripts/ifcfg-eth0) следующие адреса: 213.179.249.151, 213.179.249.152, 8.8.8.8, 8.8.4.4 (первые два — новые Укртелекомовские, следущие два — от Google).




3) Настраиваем менеджер пакетов (yum)


Примечание: подробный мануал по использованию yum — смотри в статье «Управление пакетами в RHEL6. Yum»...

3a)


Настраиваем источники софта (репозитории):

включаем стандартные репозитории (в конфиге репозитария пропишем enabled=1, или установим галочки через графический интерфейс...):
   CentOS-6 — Base
   CentOS-6 — Contrib
   CentOS-6 — Extras
   CentOS-6 — Plus
   CentOS-6 — Updates

И добавляем/подключаем дополнительные репозитории (без них очень грустно, т.к. стандартные репозитории содержат преимущественно серверный софт, причём устаревшие хотя и сверхотлаженные версии).

Примечание: В большинстве случаев, для облегчения подключения новых репозиториев, владельцы репозиториев подготовили RPM-пакеты для автоматической конфигурации — эти пакеты нужно только скачать и установить. Причём, выбирайте пакеты правильной версии: для соответствующей версии репозитария и предназначенные для соответствующего вашему релиза Линукс. При установке этого псевдопакета автоматически сгенерируются необходимые конфиги, сконфигурируется yum и т.п.

Рекомендации:
   Use «cat /etc/redhat-release» to find which release of EL you are using (у меня говорит: «CentOS release 6.3» — т.е. «el6»)
   Use «uname -a» to find your processor architecture (у меня говорит: «i686 i386»)
   Use «rpm -ivh package-filename» to install the rpmforge-release package (also works with URLs)

RPMforge
   инструкции по установке: repoforge.org и wiki.centos.org
   рабочий пример установки: su -c 'rpm -Uvh packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.i686.rpm'

EPEL
   инструкции по установке: fedoraproject.org
   рабочий пример установки: su -c 'rpm -Uvh download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm'

ATrpms
   инструкции по установке: atrpms.net
   рабочий пример установки: su -c 'rpm -Uvh dl.atrpms.net/all/atrpms-repo-6-5.el6.i686.rpm'

3b)


Концепция: главное — не нарушить функциональность базового ядра системы.
Стандартные репозитарии CentOS (особенно «CentOS-6 — Base») составляют специально обученные люди, которые обеспечивают наличие в каждый момент времени в репозитарии среза совместимых друг с другом пакетов и библиотек. (CentOS — система серверная, которая установлена на самых дорогих Продакшн серверах, которые работают в режиме автоапдейта. Глюк в репозитарии сломает много серверов, ну то есть у админов будет много гемора и кредит доверия к CentOS подорвётся… Этого не допускают.)
Но если играться с третьими левыми дистрибутивами, то в них всегда новые (и нестабильные) версии библиотек появляются ранее — они могут быть автоматически установлены в систему при автоапдейте, породив несовместимость для сервисов ядра. Плохо!

Для того чтобы на сервер устанавливался именно самый отлаженный софт, а из дополнительных репозитариев устанавливался только софт отсутствующий в базовых (пакеты развязываются по «зависимостям») — нужно настроить/использовать систему приоритетов:

Для управления приоритетами — нужно установить дополнительные плагины для yum (полезно установить все три):
  • yum-protect-packages (позволяет защитить указанные пакеты от удаления; по умолчанию защищён сам yum и его цепочка зависимости)
  • yum-plugin-protectbase (позволяет защитить пакеты из указанного репозитария от обновления из незащищённых репозитариев) — ЕГО ПРОЩЕ НАСТРАИВАТЬ.
  • yum-plugin-priorities (позволяет назначить приоритеты различным репозиториям; пакеты из репозитория с более низким значением приоритета не могут быть обновлены из репозитория с высоким значением приоритета — это другой вид защиты, более продвинутый и гибкий) — ОН ЛУЧШЕ!

(Примечание: для yum есть ещё много интересных плагинов, но эти самые необходимые...)

Настройки репозитариев yum хранит в: /etc/yum.repos.d/
конфиги, которые можно редактировать, называются: *.repo
остальные файлы служебные — их не трогаем.

Нужно дописать в текстовые конфиги (как минимум для всех репозитариев с enabled=1): строки с параметрами protect=… и priority=… (примечание: чем меньше значение priority — тем репозиторий главнее)
Рекомендую прописать следующие установки приоритетов...
#== CentOS-Base.repo
[base]
enabled=1
protect=1
priority=1

[updates]
enabled=1
protect=1
priority=1

[extras]
enabled=1
protect=1
priority=1

[centosplus]
enabled=1
protect=0
priority=2

[contrib]
enabled=1
protect=0
priority=2


#== CentOS-Media.repo
[c6-media]
enabled=0 # На самом деле это локальный репозитарий на установочных дисках. В реальной работе он не нужен, т.к. используется Интернет - Отключим этот репозитарий.
protect=0
priority=2


#== rpmforge.repo
[rpmforge]
enabled=1
protect=0
priority=9

[rpmforge-extras]
enabled=0
protect=0
priority=9

[rpmforge-testing]
enabled=0
protect=0
priority=99


#== epel.repo
[epel]
enabled=1
protect=0
priority=10

[epel-debuginfo]
enabled=0
protect=0
priority=10

[epel-source]
enabled=0
protect=0
priority=10


#== epel-testing.repo
enabled=0


#== atrpms.repo
[atrpms]
enabled=1
protect=0
priority=11

[atrpms-debuginfo]
enabled=0
protect=0
priority=11

[atrpms-source]
enabled=0
protect=0
priority=11


#== atrpms-bleeding.repo
enabled=0


#== atrpms-testing.repo
enabled=0



3c)


Ещё рекомендую установить использовать графическую оболочку к менеджеру пакетов: Yum Extender (бинарь называется yumex) — он гораздо продвинутей стандартного GUI!




4) Устанавливаем дополнительный софт, не относящийся к системе 1С



Теперь можно проинсталировать (через консоль управления менеджером пакетов yum, конечно):
   поддержку ntfs
   wine (эмулятор для запуска простых приложений windows)
и другие полезные локальные приложения…




5) Настраиваем Samba-сервер



Нужно установить (через yum) и настроить сервер Samba (службы «smb» и «nmb») — это поддержка протокола Microsoft NetBIOS под Линукс, т.н. «Сетевое окружение»…

Причём Samba рекомендую поднять, даже если вы не будете предоставлять файловые шары на этом сервере для других клиентов локальной сети, чтобы этот сервер появился в «сетевом окружении» у всех Windows клиентов и других серверов сети, сканировался стандартным API, резолвил своё «сетевое имя машины» — чтобы на него можно было ссылаться как-то типа ¨\\MyLinuxServer¨. Для удобства, настройте Samba так, чтобы Сервер 1С был виден в вашей WORKGROUP…

Примечание по поводу: Нужен ли Samba-сервер для работы 1С:Предприятия или нет?
1) Раньше, для работы 1С: Предприятие версии 8.1, Samba-сервер был строго необходим: например, MMC-оснастке «Администрирование серверов», если сервер 1С под Линукс, требовался аналог «Cлужбы доступа к файлам и принтерам Windows» – Samba… Но сейчас админы отмечают, что поздние версии 1С: Предприятие 8.2 нормально работают и без поднятия Samba на сервере. (Хотя замечу, что тогда клиентским приложениям 1С, в т.ч. оснастке «Администрирования серверов», приходится обращаться к серверу 1С только через IP. Либо требуется поднимать и настраивать соответствующим образом локальный DNS-сервер, для трансляции IP сервера в символическое имя компьютера.)

2) В отличие от «файловой Информационной Базы», для размещения которой требовалась «общая сетевая папка», — в клиент-серверном варианте samba-шара уже не требуется… Однако Samba-сервер остаётся полезным! Основное назначение Samba в клиент-серверной конфигурации — легко и просто резолвить в локальной сети символическое «имя сервера» в его IPшник, для всех клиентских приложений 1С, без необходимости применения локального DNS-сервера — что значительно упрощает настройку и администрирование сетей, для небольших 1С-решений.

3) Кроме того, нужно понимать, что платформа 1С: Предприятие была всегда заточена под Windows (COM, RPC, NetBIOS) и её миграция под Линукс, в кросплатформенное решение (TCP/IP, HTTP и на собственные переносимые протоколы), началась недавно. Пока кросплатформенные решения обладают гораздо меньшим доступным функционалом, чем при развёртывании системы на платформе Windows. И разработчики 1С ещё работают над переделкой сервисов платформы 1С на «кросплатформенные протоколы» (а сервисов в пакете много)… И «1С: Предприятие 8.х» во многом ориентировано на работу «в локальной сети» (например, вся их лицензионная политика на этом построена)… Поэтому есть ещё масса явных и неявных использований протокола NetBIOS сервисами 1С (что может быть и недокументировано, но это обычные накладки при «итеративной разработке») — и мне профессиональная интуиция подсказывает, что Samba очень желательно поднять!


Для настройки Samba советую:
создать и настроить шаровые папки так:
	mkdir /home/samba
	mkdir /home/samba/вседругие
	...
	chown -R samba /home/samba
	chgrp -R samba /home/samba
	chmod -R a+rw  /home/samba

создать нелогинного пользователя/группу: samba/samba
назначить этому пользователю домашнюю папку: /home/samba

Настройка службы Samba:
   Конфиги лежат в /etc/samba/
   см. man smb.conf
   см. smb-conf.ru
   Для простой настройки — см. статью «Простая установка и конфигурация сервера SAMBA в CentOS»...

Важно: Кроме службы «smb» (основной), также следует «включить» и «запустить» службу «nmb» (которая отвечает за публикацию NetBIOS имени компьютера в локальной сети — Сервер станет виден в «Сетевом окружении»):
	chkconfig --level 2345 smb on
	chkconfig --level 2345 nmb on
	service smb start
	service nmb start

Совет: Режим работы Служб лучше всего настраивать через графическую оснастку «GNOME / Система / Администрирование / Службы»…




6) Достаём и готовим дистрибутивы 1С: Предприятие… Откуда всё взять?



Пиратские дистрибутивы 1С (и кряки) можно скачать с обменников (ссылки не привожу, найдёте на forum.ru-board.com в разделе «Варезник»)…

Итак, добыли/скачали дистрибутив «1С: Платформа 8.2 релиз 8.2.16.368 от 05.10.12» -> из него берём «Cервер 1С: Предприятия (32bit) для RPM-based Linux-систем», файл «8_2_16_368_rpm.tar.gz» (169.07 MB) -> после распаковки архива получим 8 RPM-файлов дистрибутива…

Готовые сборки «PostgreSQL от 1С релиз 9.0.3-3.1C от 17.01.12» нам не подойдут, не установятся по зависимостям (там пакеты собраны для CentOS 5.x, а не для 6.x.).
Нам нужны исходные коды PostgreSQL, патченные 1С, для самостоятельной сборки! Из дистрибутива «PostgreSQL от 1С релиз 9.0.3-3.1C от 17.01.12» -> берём только файл «PG90331_Patch903.rar» -> из архива берём только файл «postgresql-9.0.3-3.1C.src.rpm» (это RPM-пакет c исходными кодами PostgreSQL версии 9.0.3, УЖЕ ВКЛЮЧАЮЩИЙ ВСЕ НЕОБХОДИМЫЕ ПАТЧИ для обеспечения совместимости с сервером 1С: Предприятия 8.1 и 1С: Предприятия 8.2)
Примечание: Кроме того, исходные коды для самостоятельной сборки СУБД PostgreSQL, поддерживаемой 1С: Предприятием 8, проще всего скачать с оф.сайта напрямую...

Замечания: Какую платформу выбрать?
  1. сервер 1С бывает: и х64, и х86
  2. клиентские программы 1С бывают: только х86, на сегодняшний момент (повторюсь: х64 бывает только сервер 1C)
  3. известно что на ОС х64 можно ставить программы х86 (это касается не только 1С)
  4. клиентские программы 1С (толстый и тонкий клиенты) работают только под Windows!
    Дополнительная информация...
    На оф.сайте v8.1c.ru для «Технологической платформы 1С: Предприятия» / «Тонкий клиент» и «толстый клиент» — возможность работы под Linux не упомянута! Хотя таковая упомянута для web-клиента и для Сервера 1С…

    В дистрибутивах платформы 1С: Предприятие 8.2 клиентских приложений под Линукс — НЕ ОБНАРУЖИЛ (т.о. из под Линукс доступны только Web-клиенты, которые работают в окружении Браузера).

    В дистрибутивах платформы 1С: Предприятие 8.3 (пока тестовая версия) клиентские приложения под Линукс (и 32bit и 64bit) — УЖЕ ПРИСУТСТВУЮТ!

    Кстати, поэтому для локальной установки 1С (один пользователь/один компьютер) — пока доступен только вариант под Win32.






7) Сборка и Установка «СУБД PostgreSQL от 1С (релиз 9.0.3-3.1C от 17.01.12)» на Линукс CentOS (6.3)



Первым делом, чтобы не было конфликтов в системе, нужно деинсталлировать все другие/предыдущие версии СЕРВЕРА PostgreSQL, если таковые установлены (проверьте).

Вредный совет: Чтобы не было путаницы из-за программной несовместимости, я также деинсталировал клиента «postgresql-8.4.13» (установленный изначально, из стандартного репозитария CentOS 6.3)… Некоторые пакеты (например, «postgresql-libs-8.4.13» и др.) сейчас пришлось оставить, т.к. от них зависят многие другие пакеты в системе — однако их можно будет деинсталировать потом, после установки PostgreSQL 9.0.3 (забегая вперёд, мне это удалось)…
Тем не менее, есть смысл оставить эти стандартные пакеты в системе (особенно «postgresql-libs-8.4.13») — на тот случай, если в будущем вам прийдётся деинсталировать PostgreSQL 9.0.3. Потому что сейчас у меня сложилась такая ситуация, что все системные пакеты теперь зависят только от пакета «postgresql-libs-9.0.3-3.1C» и менеджер пакетов не даёт деинсталировать последний не снеся заодно половину систему (крах).


К сожалению, в базовых репозитариях CentOS 6.3, т.е. в текущей системе, имеются не все необходимые библиотеки (зависимости) для использования готовой сборки «PostgreSQL от 1С». Кроме того, следует иметь в виду, что для работы сервера 1С: Предприятия 8.2 требуется версия PostgreSQL не ниже 8.3.8 .

Я перепробовал разные дистрибутивы...
PostgreSQL от 1С релиз 9.0.3-3.1C (последняя доступняя стабильная версия, патченная 1С) — сходу не установился из-за отсутствующих зависимостей, требует новые версии библиотек (libcrypto.so.4, libssl.so.4, libreadline.so.4, libtermcap.so.2).

PostgreSQL от 1С релиз 8.4.3-3.1C — сходу не установился из-за отсутствующих зависимостей, требует новые версии библиотек (libcrypto.so.4, libssl.so.4, libreadline.so.4, libtermcap.so.2); также требуется установить пакет openldap (библиотеки libldap-2.2.so.7, libldap_r-2.2.so.7); [и необязательно, для дополнительных клиентов, требуются библиотеки: libpython2.3.so.1.0, libtcl8.4.so].

PostgreSQL от 1С релиз 8.3.3-2.1C — сходу не установился из-за отсутствующих зависимостей, требует новые версии библиотек (libreadline.so.4, libtermcap.so.2); [и необязательно, для дополнительных клиентов, требуются библиотеки: libpython2.3.so.1.0, libtcl8.4.so]. Кроме того, устанавливаемый пакет «postgresql-libs-8.3.3» был меньшей версии и конфликтовал с уже установленным в системе пакетом «postgresql-libs-8.4.13» (поэтому версия 8.3.3 вообще не подходит).


Итак, лучше всего подходит версия «PostgreSQL от 1С релиз 9.0.3-3.1C», но собранные RPM-пакеты из дистрибутива «PG90331_setuppln903.rar» нам не подойдут: не установятся по зависимостям (там пакеты собраны для CentOS 5.x, а не для 6.x.)…

Неправильный подход: Апгрейдить вручную существующие старые библиотеки — это геморно и опасно (от них зависит куча софта из базового и стабильного ядра CentOS)! Ещё можно было бы вставить костыли-хаки в виде символических ссылок (с именами требуемых библиотек, ссылающиеся на существующие версии), но это совсем плохо на Production-сервере…


Поэтому чтобы не нарушать целостность ядра CentOS, нужно пересобрать сам PostgreSQL из исходных кодов, пропатчив его патчами 1C (так он будет базироваться на наших существующих библиотеках). Патченные исходники PostgreSQL берём из дистрибутива «PostgreSQL от 1С релиз 9.0.3-3.1C» -> нам понадобится только файл «PG90331_Patch903.rar» -> а из архива берём только файл «postgresql-9.0.3-3.1C.src.rpm»… или скачиваем этот файл напрямую с оф.сайта…

7a)


Примечание: Я не опытен в сборке из исходников, поэтому далее идёт слегка модифицированный рецепт из блога «Админа-маньяка» на alsigned.ru (автору респект).

Установка должна выполняться от имени пользователя root...

Перед PostgreSQL, необходимо установить (или убедиться что уже установлена) библиотеку ICU — она необходима для работы PostgreSQL версии от 1С. Установить можно вручную из RPM-пакета (но не нужно)… Или с помощью yum, из стандартного репозитария (что лучше):
	yum install icu libicu libicu-devel


Устанавливаем также пакеты необходимые для компиляции и сборки:
	yum install rpm-build wget glibc-devel bison flex readline-devel zlib-devel openssl-devel pam-devel gettext gcc make 


7b)


Загружаем с сайта 1с исходники PostgreSQL 9.0.3:
	wget http://v8.1c.ru/overview/postgresql_patches/9-0-3/postgresql-9.0.3-3.1C.src.rpm

и устанавливаем пакет с исходниками (будут созданы разные папки в системе и по ним раскиданы исходные файлы):
	rpm -ihv postgresql-9.0.3-3.1C.src.rpm


Открываем для редактирования файл /usr/lib/rpm/macros и меняем в нем уровень подгона пачей _default_patch_fuzz на 2:
	%_default_patch_fuzz    2

Примечание: Раньше подобные действия приходилось делать только на Fedora 12 и выше, при сборке софта не поддерживающего обработку пачей новыми скриптами, а начиная с 6-ой версии новые скрипты пришли и в CentOS.

Создаем символические ссылки на библиотеки libicu:
	ln -s /usr/lib/libicui18n.so /usr/local/lib/libicui18n.so.46
	ln -s /usr/lib/libicudata.so /usr/local/lib/libicudata.so.46
	ln -s /usr/lib/libicuuc.so   /usr/local/lib/libicuuc.so.46


Переходим к сборке PostgreSQL:
	rpmbuild -bb --define 'runselftest 0' ~/rpmbuild/SPECS/postgresql-9.0-1C.spec

Примечание: Установкой параметра «runselftest 0» мы отказываемся от инициализации тестовой базы и проверки работоспособности PosgreSQL во время сборки, для того что бы тестирование прошло успешно его нужно выполнять из-под ограниченного пользователя, иначе процесс сборки будет остановлен.

Процесс сборки займёт некоторое время…

Наконец, просмотрим список собранных RPM-пакетов (т.к. у меня ОС Линукс 32-битная, то и пакеты PostgreSQL были собраны тоже 32-битной версии):
	bash# ls -1 ~/rpmbuild/RPMS/i686
	postgresql-9.0.3-3.1C.i686.rpm
	postgresql-contrib-9.0.3-3.1C.i686.rpm
	postgresql-debuginfo-9.0.3-3.1C.i686.rpm
	postgresql-devel-9.0.3-3.1C.i686.rpm
	postgresql-docs-9.0.3-3.1C.i686.rpm
	postgresql-libs-9.0.3-3.1C.i686.rpm
	postgresql-server-9.0.3-3.1C.i686.rpm
	postgresql-test-9.0.3-3.1C.i686.rpm


7c)


Установка патченного сервера СУБД PostgreSQL от 1С:

Совсем необязательно устанавливать все пакеты… для нормальной работы PostgreSQL вполне достаточно четырёх: postgresql-libs, postgresql, postgresql-server, postgresql-contrib. Переходим в директорию /root/rpmbuild/RPMS/i686 (на 64-битной ОС — в /root/rpmbuild/RPMS/x86_64) и устанавливаем пакеты…

порядок установки пакетов следующий:
	postgresql-libs-9.0.3-3.1C.i686.rpm
	postgresql-9.0.3-3.1C.i686.rpm
	postgresql-server-9.0.3-3.1C.i686.rpm
	postgresql-contrib-9.0.3-3.1C.i686.rpm

Необязательно но полезно (для разработчиков) затем ещё установить следующие пакеты:
	postgresql-docs-9.0.3-3.1C.i686.rpm
	postgresql-devel-9.0.3-3.1C.i686.rpm
	postgresql-debuginfo-9.0.3-3.1C.i686.rpm
	postgresql-test-9.0.3-3.1C.i686.rpm


Но чтобы не заморачиваться с порядком установки — лучше установить все пакеты скопом (yum сам разберётся с зависимостями):
   rpm -ihv postgresql-9.0.3-3.1C.i686.rpm postgresql-contrib-9.0.3-3.1C.i686.rpm postgresql-debuginfo-9.0.3-3.1C.i686.rpm postgresql-devel-9.0.3-3.1C.i686.rpm postgresql-docs-9.0.3-3.1C.i686.rpm postgresql-libs-9.0.3-3.1C.i686.rpm postgresql-server-9.0.3-3.1C.i686.rpm postgresql-test-9.0.3-3.1C.i686.rpm

Грабли: при установке пакета «postgresql-contrib-9.0.3-3.1C.i686.rpm» возникает ошибка?
ошибка: распаковка архива не удалась на файле /usr/pgsql/lib/libicudata.so.46;4e9327cc: cpio: Digest mismatch

ошибка: postgresql-contrib-9.0.3-3.1C.i686: install failed

Решение: Запускаем rpm без проверки digest и md5
	rpm --nodigest --nomd5 -ihv postgresql-contrib-9.0.3-3.1C.i686.rpm


Все вышеперечисленные действия должны выполняться от имени пользователя root.

После этого в операционной системе появится пользователь «postgres», который будет владеть всеми файлами СУБД и в сеансе которого будет запускаться сервер (не путайте его с одноимённым суперпользователем самой СУБД).
Будет создан скрипт /etc/init.d/postgresql для старта и остановки СУБД.
Бинарные файлы клиента и сервера PostgreSQL 9.0.3 находятся в /usr/pgsql/bin/…


7d)


Инициализируем кластер баз данных PostgreSQL (так называется директория, обычно /var/lib/pgsql/data, в которой хранятся данные всех баз этой установки СУБД PostgreSQL):

Примечание: в предыдущих версиях Postgres проходил трюк, когда мы просто запускали сервер СУБД, и он при первом запуске не обнаруживая директории с файлами БД — сам инициировал initdb… Но сейчас это не работает —
нужно запускать initdb явно и с правильными параметрами. При этом, нужно явно указать системного пользователя в сеансе которого происходит запуск сервера СУБД (командой «su postgres»). Также явно указываем локаль в которой работает сервер (locale=ru_RU.UTF-8).
	bash# su postgres -c '/usr/pgsql/bin/initdb -D /var/lib/pgsql/data --locale=ru_RU.UTF-8'


При выполнении этой команды, её консольный вывод подтвердит заданные параметры (в консоли появится текст):
   Файлы, сопутствующие этой системе баз данных, будут принадлежать пользователю «postgres». Этот пользователь также должен быть владельцем процесса сервера.
   Кластер баз данных будет инициализирован с локалью ru_RU.UTF-8. Кодировка базы по умолчанию установлена в UTF8. Конфигурация полнотекстового поиска по умолчанию установлена в «russian».


В результате будет создана база данных, размещенная в каталоге /var/lib/pgsql/data (примечание: тут же и конфиги сервера PostgreSQL).

Грабли: если во время инициализации кластера баз данных выпадает ошибка?
FATAL: could not create shared memory segment…
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 35233792 bytes), reduce PostgreSQL's shared_buffers parameter (currently 3584) and/or its max_connections parameter (currently 104).

Решение: Необходимо увеличить значение параметра kernel.shmmax, для этого добавляем в файл /etc/sysctl.conf строчку:
	kernel.shmmax = 40000000

Затем обновляем параметры sysctl следующей командой:
	bash# sysctl -p

Примечание: Обычно эта проблема характерна для 32-битных версий… Но у меня на CentOS 6.3 32bit такой проблемы не возникло — здесь уже установлен параметр kernel.shmmax = 4294967295


7e)


Настройка сервиса PostgreSQL:

Добавляем в автозагрузку и запускаем сервис PostgreSQL:
	bash# chkconfig postgresql on
	bash# service postgresql start


Бинарные файлы клиента и сервера PostgreSQL 9.0.3 находятся в /usr/pgsql/bin/… Создадим символические ссылки на необходимые бинари, чтобы они запускались без указания пути (особенно это нужно для Консольного клиента PostgreSQL):
	ln -s /usr/pgsql/bin/psql  /usr/local/bin/psql
	и др.


При первом запуске PostgreSQL, для контроля привилегий доступа к сущностям БД, в СУБД создаётся учётная запись суперпользователя «postgres» с паролем «postgres» (не путайте её с учётной записью ОС Линукс). Первое что нужно сделать – сменить стандартный пароль… Задаем пароль для суперпользователя СУБД «postgres» командой:
	bash# psql -U postgres -c "ALTER USER postgres PASSWORD 'newpassword'"

Примечание: теперь этот пароль будет использоваться при соединении клиентов к СУБД: login=«postgres» password=«newpassword».

7f)


Настраиваем сервер PostgreSQL для работы с «Сервером 1С: Предприятие» (правим конфиги):
См. описание параметров конфигов на русском...

В файле /var/lib/pgsql/data/postgresql.conf — настройки сервера. Нужно указать параметры (раскомментировать строки или если этих параметров нет, то ввести их вручную):
	default_with_oid = on


По умолчанию, Автовакуум в PostgreSQL 9.0.3 отключён… Если вы хотите включить «Автоматическую сборку мусора (Automatic Vacuuming)» в БД (что полезно для слабонагруженных серверов, чтобы админу не требовалось делать процедуру «упаковки БД» периодически и вручную, а просто установить и забыть) — то установите такие параметры:
	track_counts = on
	autovacuum = on

Примечание: в предыдущих версиях СУБД был параметр «stats_row_level»… но в PostgreSQL 9.0.3 этот параметр устарел и вошёл в новый параметр «track_counts».

В файле /var/lib/pgsql/data/pg_hba.conf настраивается политика доступа и идентификации пользователей (т.е. допустимые параметры подключения к PostgreSQL-серверу)… Убедитесь, что в конце этого файла указана незакомментированная такая строчка (что означает «разрешить подключения к серверу с любых хостов, пароли при логине хешируются md5»):
	host all all 0.0.0.0/0 md5

Примечание: если в строке политики заменить «md5» на «trust», то пароль при подключении проверяться не будет! (полезно для восстановления/изменения забытого пароля суперпользователя) Также обратите внимание, что политика по-умолчанию для клиентских подключений с localhost: пароли не проверяются...

Примечание: Эти параметры вы сможете конфигурировать и позднее. А когда убедитесь, что всё включая клиента 1С работает — имеет смысл, в целях безопасности, ограничить подключения только локальным хостом localhost (или точнее хостами «кластера серверов 1С», если они отделены)...

Наконец, перезапустите сервер PostgreSQL:
	/etc/init.d/postgresql restart





8) Установка «Сервера 1С: Предприятие 32bit для RPM-based Linux-систем (8.2.16.368)» на Линукс CentOS (6.3)



Дистрибутив серверной части 1С: Предприятия 8 для Linux представлен в виде нескольких rpm-пакетов:
  • 1C_Enterprise-common — общие компоненты 1С: Предприятия 8;
  • 1C_Enterprise-server — компоненты сервера 1С: Предприятия 8;
  • 1C_Enterprise-ws — адаптер для публикации Web—сервисов 1С: Предприятия 8 на веб-сервере на основе Apache HTTP Server 2.0 или Apache HTTP Server 2.2;
  • 1C-Enterprise-crs — компоненты сервера хранилища конфигурации 1С: Предприятия 8.
  • Пакеты, содержащие в названии суффикс "-nls" — это дополнительные национальные ресурсы для соответствующего пакета.

Пакеты 1C_Enterprise-server и 1C_Enterprise-ws не зависят друг от друга. Соответственно, они могут быть установлены на одном компьютере как вместе, так и по отдельности (т.е. «сервер 1С» и «Web-сервер» можно разнести по разным машинам, как и отделить сервер СУБД, для разгрузки «сервера 1С»)…

Примечание от 2014.01.15: замечено, что код пакета «1C_Enterprise-ws» всё-таки зависит от пакета «1C_Enterprise-server», но это не принципиально...
По опыту Tern222, замечено, что код пакета «1C_Enterprise-ws» всё-таки зависит от пакета «1C_Enterprise-server»! (Вероятно, там зависимости по библиотекам или ещё что.) Таким образом, на хосте «1C web-server под Linux» нужно устанавливать оба этих пакета. Однако, конфигурировать и запускать только Web-сервер…
Пытаюсь ставить именно «веб компонент» отдельно. Если не установлен «сервер» то, при попытке зайти через браузер, получаю ошибку: «Error loading component pack». Как только доставляю сервер — все отлично. Но самое интересное: сервер даже не запущен…
Затем, после правильной конфигурации «web-сервера», я без проблем подключаюсь к «серверу 1с» на удаленной машине, через браузер.



Установка должна выполняться от имени пользователя root...

При установке следует учитывать следующие зависимости между пакетами (чтобы успешно установить пакет, предварительно нужно установить все пакеты, от которых он зависит) — поэтому порядок установки следующий:
	rpm -ihv 1C_Enterprise82-common-8.2.16-368.i386.rpm
	rpm -ihv 1C_Enterprise82-common-nls-8.2.16-368.i386.rpm
	rpm -ihv 1C_Enterprise82-server-8.2.16-368.i386.rpm
	rpm -ihv 1C_Enterprise82-server-nls-8.2.16-368.i386.rpm
	rpm -ihv 1C_Enterprise82-ws-8.2.16-368.i386.rpm
	rpm -ihv 1C_Enterprise82-ws-nls-8.2.16-368.i386.rpm
	rpm -ihv 1C_Enterprise82-crs-8.2.16-368.i386.rpm
	rpm -ihv 1C_Enterprise82-crs-nls-8.2.16-368.i386.rpm


Затем сервер следует запустить в режиме демона:
	/etc/rc.d/init.d/srv1cv82 stop
	/opt/1C/v8.2/i386/ragent -daemon
	/etc/rc.d/init.d/srv1cv82 restart


Все вышеперечисленные действия должны выполняться от имени пользователя root.

В процессе установке компонент сервера 1C: Предприятия 8 создается пользователь операционной системы с именем usr1cv82, под учетной записью которого будут исполняться серверные процессы 1С: Предприятия 8.

8a)


После установки всех требуемых пакетов, нужно запустить скриптовую утилиту диагностики и инициализации графической подсистемы в 1С v8.2 и выполнить её рекомендации, если таковые возникнут. (Утилита проверяет систему на наличие в ней требуемых для графической подсистемы в 1С v8.2 компонентов и настроек, и выдаёт рекомендации, если 1С ещё что-то требуется.)
	/opt/1C/v8.2/i386/utils/config_server


Дополнительная информация про утилиту «config_server»: на nefrit.arvixe.ru и blog.unixstyle.ru

Порядок настройки системы с помощью утилиты «config_server» будет примерно следующий (некоторые из этих этапов у вас могут отсутствовать — пропустите):

Установка должна выполняться от имени пользователя root...

1) После первого запуска утилиты «config_server» — должна вылететь ошибка: «Can not detect font directory, please specify it!»
Решение: ставим отсутствующие TTF-шрифты по рецепту linewb.ru FAQ и сайта corefonts.sourceforge.net.
Примечание: система папок ~/rpmbuild/ у вас уже должна существовать (они были созданы ранее, при сборке дистрибутива PostgreSQL).
В итоге, для установки шрифтов, достаточно примерно следующих действий:
	yum install rpm-build cabextract
	wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
	rpmbuild -bb msttcorefonts-2.5-1.spec
	rpm -ivh ~/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm


2) Повторно запускаем утилиту «config_server» — должна вылететь ошибка: «No truetype conversion utility found! Please install ttf2afm or ttf2pt1!»
Решение: ставим утилиту ttf2pt1 (доступна в репозитарии EPEL):
	yum install ttf2pt1


3) Третий раз запускаем утилиту «config_server» — cистема задумается подольше и все будет отлично: больше ошибок в консоль не выдаст…

Наконец, нужно перегрузить «Сервер 1С» (или целиком всю машину):
	/etc/init.d/srv1cv82 restart


Все вышеперечисленные действия должны выполняться от имени пользователя root.

8b)


Все, установка «Сервера 1С» на ОС Линукс завершена!
Остается подключиться к этому «Серверу 1С» через MMC-консоль «Администрирование сервера 1С: Предприятие 8.2» и создать «информационные базы» конфигураций. Об этом ниже…

Примечание: MMC-консоль устанавливается в составе «Технологической платформы 1С: предприятия 8.2» — на другом хосте, и только под управлением Windows. (Хотя в версии «1С: Предприятие 8.3» обещают, что уже реализовано ПО администрирования и под Линукс...)

8c)


Настраиваем поддержку web-клиентов 1С через вебсервер Apache:

Подготовка: Мы будем использовать локальный вебсервер Apache, установленный на этой же линукс-машине, что и «Сервер 1С». Если у вас ещё не установлен вебсервер Apache — то выполните действия из раздела «Task: Install Apache/httpd under Fedora Core/Cent OS Linux» статьи «How to install and start the Apache or httpd service under Linux»:
	yum install httpd
	chkconfig httpd on
	/etc/init.d/httpd start


Далее, действуем как сказано в разделе «2. Публикация web-клиента» статьи «Ставим 1C web-клиент на Apache»...

Предположим, у вас на «Сервере 1С» есть информационная база с названием «test1c» (фактически она будет создана поздже, после инициализации кластера и создания БД в postgreSQL… но публикацию можно выполнить спекулятивно и сейчас, т.к. фактически к ИБ мы обращаться не будем, а просто поправим конфиги Apache и создадим на вебсервере заглушку, некоторые папки/файлы). Процедура публикации очень простая и автоматизированная (каждый шаг подробно описан в вышеназванной статье, поэтому тут не повторяюсь) — нужно исполнить следующие команды:
	cd /opt/1c/v8.2/i386
	./webinst -apache22 -wsdir test1c -dir '/var/www/html/test1c/' -connStr 'Srvr="delldev";Ref="test1c"' -confPath /etc/httpd/conf/httpd.conf
	chown apache:apache /var/www/html/test1c/default.vrd
	chkconfig httpd on
	service httpd start

Всё, информационная база «test1c» опубликована! Когда вы до конца настроите «кластер серверов 1С» и информационную базу, то к ней можно будет подключиться через броузер, введя адрес http:// delldev/test1c (где delldev — имя хоста под управлением CentOS, с «Сервером 1С» и «вебсервером Apache», который мы сейчас настраиваем)...

Помните: чтобы веб-клиент заработал — также необходимо: к хосту, на котором работает «Сервер 1С» или «Web-сервер Apache» (в данном случае он один), подключить пакет «Сетевых клиентских лицензий» (ключ защиты можно подключить локально или настроить доступ к «менеджеру лицензий»); и включить в «Свойствах» Информационной Базы пункт «Выдавать лицензии сервером приложения» (настраивается через оснастку «Администрирование серверов»).

8d)


Дополнительно: следует знать как включить «Технологический журнал» (он же «логи», он же «log»)…

По-умолчанию логи отключены, потому что они быстро разрастаются и занимают очень много места на диске (при ошибках, вместе с «логами» создаются также «дампы»). Включайте логи только если вам действительно необходимо отследить некую проблему.

8e)


Дополнительно: если вдруг понадобится… для удаления «Сервера 1С», следует выполнить такие шаги:

Перед удалением необходимо завершить работу кластера серверов:
	/etc/rc.d/init.d/srv1cv82 stop 

Затем, удаляем пакеты в порядке, обратном установке, чтобы зависимый пакет удалялся до того пакета, от которого он зависит:
	rpm -e 1C_Enterprise82-crs-nls-8.2.16-368.i386.rpm
	rpm -e 1C_Enterprise82-crs-8.2.16-368.i386.rpm
	rpm -e 1C_Enterprise82-ws-nls-8.2.16-368.i386.rpm
	rpm -e 1C_Enterprise82-ws-8.2.16-368.i386.rpm
	rpm -e 1C_Enterprise82-server-nls-8.2.16-368.i386.rpm
	rpm -e 1C_Enterprise82-server-8.2.16-368.i386.rpm
	rpm -e 1C_Enterprise82-common-nls-8.2.16-368.i386.rpm
	rpm -e 1C_Enterprise82-common-8.2.16-368.i386.rpm


Или также можно выполнить удаление всех rpm-пакетов одной универсальной командой, которая удалит все установленные пакеты, которые начинаются с префикса «1C_», а зависимости будут отслежены автоматически:
	rpm —e`rpm —qa|grep 1C_` 





9) Установка защитных ключей (лицензирование 1С)



Подключить ключи к «Серверу 1С» — просто. Нужно скачать драйвер с сайта производителя ключа, распаковать его и выполнить установку двойным кликом…

Советы по выбору драйвера — рекомендуют использовать драйвер от Etersoft...
Драйверы ключей и менеджер лицензий для Linux и WINE@Etersoft, собранные для всех систем — можно получить здесь...
Конкретно под линукс CentOS 6 — драйвера качать отсюда...

Установка HASP-драйвера от Etersoft, со встроенным «менеджером лицензий»:
	rpm -ihv haspd-3.3-eter4scientific.i586.rpm haspd-modules-3.3-eter4scientific.i586.rpm


Далее, нужно вставить в USB-порт этого сервера два аппаратных ключа: «ключ на сервер 1С: Предприятие» и «ключ на X сетевых пользовательских лицензий» (все ключи в одной физической «флешке»). И всё должно заработать: клиенты будут получать клиентские лицензии через сервер…

Примечание: Ключи нужны только для «Сервера приложений 1С: Предприятие» и для «защищённых клиентских приложений 1С». с СУБД PostgreSQL проблем нет — это opensource и не требует ни лицензий, ни ключей (в отличие от СУБД «MS SQL Server», но мы её не используем).

Примечание: Некоторые версии 1С работали и без ключей (беты)...


Внимание: Нелицензионный «Сервер 1С» (т.е. даже без «серверного ключа») нормально работает с небольшим числом клиентских подключений (до ~12 подключений). Вероятно это сделано для облегчения задач администрирования: начального конфигурирования и мониторинга в случае проблем… Но при превышении этого административного лимита — Сервер начинает отвергать новые подключения и требовать ключ.
По результатам эксперимента...
у меня точное число допустимых подключений = 13, из которых 1-3 подключения, в разное время, могут захватываться некоторыми внешними сервисами самого 1С (они периодически автоматически стартуют, делают что-то своё и отключаются).

Список текущий соединений можно увидеть через оснастку «Администрирование серверов»:
  • "… / Рабочие серверы / Рабочие процессы / Соединения" — соединения в целом к серверу
  • "… / Информационные базы / test1c (имя ИБ) / Соединения" — соединения к конкретной ИБ (их может быть меньше, чем к серверу в целом)


Примечание: однако «клиентские ключи» (локальные или сетевые) требуются для «защищённых клиентских приложений 1С», в любом случае — что для первого подключения к серверу, что для сотого!

Дополнительная информация по использованию ключей...

Какие бывают ключи?



1) По назначениям, ключи 1С бывают трёх типов:

  1. Локальные однопользовательские клиентские ключи — обязательно должны физически быть подключены к компьютеру, на котором запускается клиент 1С (по одному в каждый комп). модель ключа «HASP HL Basic» (синего цвета), данный ключ имеет маркировку «H4 M1 ORGL8», не имеет встроенной памяти и персонального ID, не хранит в себе никаких параметров и настроек. Обычно поставляется с продуктами имеющими лицензию на одно рабочее место...
  2. Сетевые многопользовательские клиентские ключи — раздаются с одного компьютера многим удалённым сетевым клиентам, через службу «Менеджер лицензий». Модель ключа «HASP HL Net» (красного цвета). Имеют внутреннюю память, в которой хранится количество лицензий, и уникальный ID. Существуют разновидности на 5, 10, 20, 50 и 100 пользователей. Имеет маркировку «NETXX ORGL8», где ХX — количество лицензий (например NET5 ORGL8).
  3. [Локальные] Серверные ключи — обязательно должны физически быть подключены локально к компьютеру, на котором установлен и работает сервер агента 1С: Предприятие. (Подчеркну: Ключи для сервера 1С: Предприятие бывают только локальные!)
    • 32-битная версия сервера имеет ключ защиты «HASP HL Pro» (фиолетового цвета), который имеет внутреннюю память и уникальный ID. Имеет маркировку ENSR8, поставляется вместе с лицензией на сервер 1С: Предприятие.
    • Для 64-битного сервера используется ключ «HASP HL Max» (зеленого цвета), с внутренней памятью и уникальным ID. Имеет маркировку EN8SA и поддерживает также 32-битный сервер (т.е. имея лицензию на 64-битный сервер можно, не меняя ключа, использовать 32-битную версию, но не наоборот).


Подробности тут:
www.online-ufa.ru/content/articles/marking_security_keys_1c
interface31.ru/tech_it/2010/02/klyuchi-zashhity-1s-predpriyatie-81.html
www.k-max.name/windows/ne-obnaruzhen-klyuch-zashhity-programmy-v-1spredpriyatie-8-ili-likbez-zashhity-1s

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

  1. «Аппаратные ключи» (физические устройства, вставляются в USB-порт подобно флешкам) — их легче использовать и они самые понятные/отработанные на практике.
  2. «Программные ключи» (как серийник; активируются с привязкой к конкретному железу посредством интернета/телефона; требуют переактивации каждый раз ПРИ ЛЮБОМ изменении в конфигурации оборудования: например, если планку памяти поменял) — с их использованием возникает много вопросов...


Примечания:
  • Само название HASP (от англ. Hardware Against Software Piracy) — это мультиплатформенная аппаратно-программная система защиты программ и данных от нелегального использования и несанкционированного распространения...
  • Многими драйверами поддерживаются АППАРАТНЫЕ КЛЮЧИ защиты (USB,LPT) — с ними проще и безопаснее иметь дело, они универсальнее.
  • Но также есть сведения, что некоторыми драйверами поддерживаются и ПРОГРАММНЫЕ ЛИЦЕНЗИИ (что удобно при работе 1С: Предприятие в виртуализованной среде типа Hyper-V). Но таковых решений гораздо меньшее количество. И имеется ли реализация драйвера под ваш Линукс? — ещё вопрос...
  • Аппаратные ключи и программные лицензии могут использоваться совместно...


Подробнее тут: www.gilev.ru/1c/hasp

3) Лицензионная политика 1С мутная… Причём, есть две модели лицензирования: «старая, применяющаяся в версии 8.1» и «новая, пришедшая в связи с выходом версии 8.2» (потому что в версии 8.2 появились новые необычные возможности: «тонкий клиент» и «Web-клиент», вся логика которых реализована на сервере. Причём, «Web-клиент» вообще не имеет технической возможности подключить ЛОКАЛЬНЫй HASP-ключ, потому что работает в окружении веб-браузера — понадобилась новая модель лицензирования...)
  • Для пользователей, работающих с толстым или тонким клиентом, может использоваться модель лицензирования, применяющаяся в версии 8.1. Лицензия дает право на запуск неограниченного количества сеансов на конкретном компьютере пользователя. При этом ключ аппаратной защиты должен быть установлен в компьютере пользователя или доступен этому компьютеру по локальной сети.
  • Для пользователей, работающих с тонким, толстым и веб-клиентом в клиент-серверном режиме или через веб-сервер, может применяться новая модель лицензирования. Лицензия дает право на запуск одного сеанса. Ключ аппаратной защиты должен быть установлен в компьютере сервера или веб-сервера или доступен этому компьютеру по локальной сети.


Источник: nefrit.arvixe.ru/page/utochnenie-licenzionnoj-politiki-dlja-1spredprijatija-82

Какие ключи поддерживаются драйвером от Etersoft?



Поддерживаемые драйвером от Etersoft ключи защиты:
    HASP 3/HASP 4/HASP HL от Aladdin (HASP SRM пока не поддерживается)
    Smartkey 3 от Eutron
    SafeNet и UltraPro/SuperPro от Sentinel
    SenseLock (USB)
    Катран (USB и LPT)
    Guardant Stealth/Net II USB, Stealth/Net III USB, Stealth III Sign/Time USB HID от компании Актив

Подробнее — см. в полном списке поддерживаемых ключей...

Ещё не проясненный вопрос: Поддерживает ли драйвер от Etersoft под Линукс «программные лицензии» (и если да, то каким образом они активируются?) или только «аппаратные ключи (USB)»?

Ещё не проясненный вопрос: Сколько одновременно подключенных локально к компьютеру ключей распознаёт драйвер от Etersoft под Линукс?
  • Уточню: к одному компьютеру гарантированно можно подключить один «серверный ключ» И один «клиентский ключ» (на 5, 10, 20, 50, 100 пользователей) — оба подхватятся и будут работать нормально. Но если вы подключите одновременно два и более «клиентских ключа» (например, на 5 + на 20 пользователей), то из них увидится только один, причём случайно какой.
  • Есть известная особенность «драйверов HASP под Windows»: он распознаёт/подхватывает только один ключ из множества подключённых к компьютеру (По крайней мере, точно не поддерживает несколько ключей одной серии! А несколько ключей разных серий может быть и проиндексирует, в зависимости от реализации/версии драйвера… Причём, не подхватывает по такой системе: либо подхватывает любой ключ совершенно случайно, игнорируя остальные; либо подхватывает только ключ что в USB-порте с младшим номером или в LPT-порте ближайший.)
  • Как с этим у «драйвера от Etersoft под Линукс»? Похоже что также — поскольку это особенность технологии, и регламентируется в большинстве руководств...


По результатам эксперимента: драйвер от Etersoft также имеет встроенную службу «HASP License Manager». Утилита «Aladdin NetHASP Monitor» видит на линукс-хосте с Сервером 1С: Предприятие службу «HASP License Manager». Но реальную работу службы (раздачу сетевых клиентских ключей) пока протестировать не смог (нет официальных ключей)...

Документация/Вопросы по установке/настройке драйвера от Etersoft



Про установку и использование АППАРАТНЫХ КЛЮЧЕЙ защиты в Linux, с драйвером от Etersoft — читай тут:


Другие вопросы по эксплуатации ключей (рассматриваются только Аппаратные ключи защиты)



Аппаратный ключ защиты, вставленный в USB-порт, можно использовать следующим образом:
  • Локально установленным ПО;
  • Существуют варианты проброса локального USB-порта в установленную виртуальную машину (VM), в которой крутится комплекс 1С;
  • существуют варианты проброса USB-порта по сети (это для каких-то очень специальных нужд, не путать с «менеджером лицензий»).


Варианты лицензирования клиентских программ 1С:
  • «Локальный однопользовательский клиентский ключ» подключается в USB-порт локального компьютера, где используется локальным HASP-драйвером для лицензирования локально установленного «защищённого ПО». Внимание: но «Локальный однопользовательский клиентский ключ» не работает на компьютере, где установлен Сервер Терминалов!
  • И «сервер лицензирования» (некий удалённый хост, на котором установлен «менеджер лицензий» и вставлен «сетевой ключ») — может лицензировать по сети множество защищённых программ (клиентов 1С) с удалённых хостов.


Для лицензирования ПО запускаемого в сессиях на Сервере Терминалов — необходимо использовать «Сетевые многопользовательские клиентские ключи», через «HASP License Manager» («менеджер лицензий»), установленный локально или на другом компьютере локальной сети («сетевой ключ» естественно вставляется в тот компьютер, где устанавливается «менеджер лицензий»).

Примечание: «Сервер Терминалов» был необходим в 1С 7.7 для обеспечения надёжной работы многих пользователей по сети… В 1С 8.2 гораздо более развитые сетевые клиент/серверные возможности: появилась трёхуровнеая архитектура с выделенным сервером приложений, кластер серверов с баллансировкой нагрузки и т.п. В 1С 8.2 надёжная работа через сеть отлично обеспечивается и без использования «Сервера Терминалов»! Кроме того в 1С 8.2 появилась замечательная универсальная альтернатива — веб-клиент…

Однако, «Сервер Терминалов» всё ещё может использоваться вместе с 1С 8.2 и полезен в случаях: если вы не хотите устанавливать/настраивать приложения 1С «Толстый или Тонкий Клиент» на каждом клиентском хосте (которые обязательно должны быть в текущей локальной сети); если клиентские хосты расположены не в текущей локальной сети (и не связаны VPN) и если для них вы по каким-то причинам не хотите использовать «веб-клиентов 1С» (например, «веб-клиент» и «тонкий клиент» работают только в конфигурациях, написанных в режиме «управляемого приложения» ).


Для лицензирования веб-клиентов 1С: Предприятие 8.2, которые работают в окружении веб-броузера и физически изолированы от локального компьютера (локального ключа) и от локальной сети (сетевого ключа) — применяется новая модель лицензирования, когда «клиентский ключ» для этого подключения делегируется через обслуживающий клиента «Сервер 1С» или «Веб-сервер».

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

Работа с ключами по сети — Менеджер лицензий



Если у вас два и более комплекта «сетевых пользовательских ключей» (например, другие были докуплены позднее), то вставлять их в порт одного компьютера нельзя (драйвер не увидит все ключи). Нужно взять отдельный хост в текущей локальной сети, установить там «HASP driver» и «HASP License Manager» (он шарит ключи по сети), и затем воткнуть в этот хост только один «сетевой ключ». Для остальных ключей — повторить процедуру… Каждый ключ «пользовательских лицензий» необходимо вставлять в отдельный хост!

Варианты установки «Менеджера лицензий»:
  • До недавнего времени, существовал только один вариант установки «Менеджера лицензий» автономно (без Сервера 1С): требовался обязательно компьютер под управлением ОС Windows.
  • Под Линукс, сейчас регламентируется поддержка работы «HASP License Manager» по такой схеме: Сервер 1С: Предприятие 8.2 на Linux + Сервер PostgreSQL 9.0.3 на Linux + HASP License Manager на Linux + клиенты 1С на Windows.
  • Но последнее время софт защиты под Линукс активно разрабатывается, поэтому скоро могут возникнуть и другие варианты...


Назначение «Менеджера лицензий»:
  • HASP License Manager позволяет организовать сеть распределённых ключей, которыми будут пользоваться сервер и клиенты 1С (защищённые приложения).
  • HASP License Manager устроен так: Выдаёт лицензии обратившимся к нему «защищённым приложениям». уменьшая внутренний счётчик доступных от ключа лицензий. Когда лицензий уже нет, то клиент не может получить лицензию ОТ ЭТОГО экземпляра «менеджера лицензий» — тогда «защищённое приложение» обращается к следующему найденному в сети «менеджеру лицензий» (если таковой есть) и просит лицензии у него, затем к следующему…
  • Программы находят друг друга через локальную сеть автоматически, с помощью широковещательных запросов; или соединения к конкретному (одному или нескольким) «менеджеру лицензий» можно прописать явно (как серверу, так и клиентам), через конфиг nethasp.ini, расположенный в папке установки каждого «защищённого приложения» (а под линуксом тут: /opt/1С/v8.2/i386/conf/ )...
  • При автоматической конфигурации, все «менеджеры лицензий» в сети должны быть видны всем работающим программам. Но сеть бывает сегментирована через VPN (широковещательные запросы могут быть запрещены), бывают проблемы с каналами и оборудованием (пакеты могут повреждаться/теряться) — тогда нужно дополнительно конфигурировать эту сеть «менеджеров лицензий» (явно прописывать IP и протоколы соединения).


Схема/порядок проверки лицензий 1C примерно следующий:
  1. Клиентские программы сначала ищут «локальный ключ»…
  2. Если не находят локального ключа, то ищут в сети «сервер лицензирования» и получают лицензию от него.
  3. Если на первом «сервере лицензирования» закончились свободные лицензии, а в сети найдены другие «серверы лицензирования» — то клиенты последовательно обходят следующие сервера и получают лицензию от них...
  4. И только когда «клиентская лицензия получена» — программы идут подключаться к «Серверу 1С».
  5. «Сервер 1С» проверяет свою «лицензию на сервер» и количество доступных подключений (рабочие сервера кластера имеют настраивамый лимит подключений, для баллансировки нагрузки; на это накладывается ограничение работы «Сервера 1С» без «серверного ключа») — если ок, то принимает клиента и даёт подключение к Информационной базе.
  6. А ещё информационные базы (Конфигурации) тоже могут иметь свою встроенную защиту: проверку лицензии подключаемого клиента.


Примечание: механизм проверок всё усложняется, от релиза к релизу, для обнаружения новых нелицензионных ключей и эмуляторов. И для усложнения жизни хакерам, 1С тщательно скрывает детали проверки — поэтому если что-то при проверке пошло не так, то программа просто скажет «Не найден ключ защиты». А что и где у него «не так»? (либо ключ сгорел, либо HASP-драйвер кривой, либо «License Manager» неправильно сконфигурирован, либо приложение, либо проблемы с сетью) — х. его знает… Приходится догадываться методом «телепатии и научного тыка» (правда логи чуток помогают) — чем сильно усложняется жизнь и всем лицензионным пользователям и администраторам.






10) Далее, устанавливаем клиентскую часть — на другой машине под управлением Windows



10a)


См. подробнейшие инструкции по установке «Технологической платформы для Windows»(в картинках и с видео)…

Запускаем инсталлятор «Технологическая платформа для Windows версии 8.2.16.368» (в версии 8.2 бывает только 32-битная) — там все программы в одном флаконе. При установке выбираем следующие компоненты:
  • «1С: Предприятие» (Основные компоненты «1С: Предприятия», включая компоненты для администрирования, конфигурирования, толстый и тонкий клиент)
  • «1С: Предприятие — Тонкий клиент» (Компоненты тонкого клиента только для работы в клиент-серверном варианте, без возможности работы с файловым вариантом)
  • «Администрирование сервера 1С: Предприятия» (MMC-консоль для администрирования кластера серверов)
  • «Интерфейсы на различных языках: английский, русский...» (по-умолчанию)


Подчёркиваю, мы не ставим следующие компоненты (они не нужны в этом клиент/серверном варианте использования 1С):
  • «1С: Предприятие — Тонкий клиент, файловый вариант» (Компоненты тонкого клиента, включая компоненты для работы с файловым вариантом информационной базы)
  • «Сервер 1С: Предприятие» (на этой машине он не нужен, т.к. он уже установлен на другом хосте под ОС Линукс… Хотя если у вас в будущем будет гетерогенный «кластер серверов 1С»: в которых будут входить машины под управлением не только Линукс, но и Widows — только тогда этот пункт вам понадобится...)
  • «Модули расширения веб-сервера» (работают только под Windows: «Сервер 1С» под Windows + web-сервер IIS под Windows, можно на разных машинах… Эти модули позволяют просто реализовать сайт, на котором будет интерфейс 1С-клиента встроен прямо в web-страничку. Тяжёлый неповоротливый сайт, потому что соединение из модулей веб-сервера к «серверу 1С» — через DCOM… Но польза сомнительна: эта хрень требует на каждое подключение удалённого веб-клиента по отдельному полноценному «клиентскому ключу»! Поэтому такой сайт никак не может быть массовым...)
  • «Сервер хранилища конфигураций 1С: Предприятия» (Используется если конфигурация хранится не в реляционной СУБД, а файлово — оптимизирует работу с ней многопользователей, сервера 1С или Web-сервера Apache. По отзывам: глючная фигня, и походу 1С забила на её развитие...)
  • «Конвертер ИБ 1С: Предприятия 7.7» (нужен только разработчикам)


«Установку HASP-драйвера» производим в том случае, если 1С на данном компьютере будем использовать лицензионную: либо к USB-порту будет присоединяться аппаратный ключ защиты, либо лицензия будет браться из сети с «менеджера лицензий»… (Напоминаю: если будете использовать кряк/эмулятор, то при инсталляции не ставьте «HASP-драйвер защиты»!)

Совет: Чтобы ничего не глючило, убедитесь в правильных настройках DCOM НА КАЖДОЙ МАШИНЕ под управлением ОС Windows, которую вы используете для работы с 1С.
DCOM настраиваются через оснастку dcomcnfg, как показано в инструкции... (Примечание: в инструкции говорится не только про DCOM, а про установку 1Сv8+MSSQL… Но в ней также наглядное описание в картинках, куда кликать чтобы настроить DCOM.)

10b)


Теперь переходим непосредственно к эксплуатации установленного пакета программ:

Запускаем MMC-консоль: Пуск -> Программы -> 1С: Предприятие 8.2 -> Дополнительно -> Администрирование серверов 1С: Предприятие.

Через консоль, последовательно создаем объекты: «Центральный сервер», «Кластер», «Рабочий сервер», «Рабочий процесс», «Информационная база» — как описано и показано в статье «Администрирование серверов 1С Предприятия»...

Следующие статьи немного устарели и неполные (изменился вид MMC-консоли, порядок создания и параметры компонент), но тоже могут быть полезны для иллюстрации, что требуется сделать на этом этапе:


10c)


Сейчас установите в USB-порт линукс-сервера 1С аппаратные ключи лицензий (два ключа: особенно требуется «лицензия на сервер», и ещё желательно «сетевые клиентские лицензии»), ибо дальше без ключей работа невозможна! Другие варианты ключей и вопросы с ними здесь не рассматриваю — они уже выходят за рамки данной статьи… Ещё можно активировать программные лицензии через email/телефон (если линукс драйвер их поддерживает?), или настройте эмуляторы/кряки (но замечу, что под линукс эмуляторов ещё не реализовали, и вряд ли сделают, т.к. особо не нужны)...

После того как, через MMC-консоль администрирования сервера, [уже была] создана «Информационная база» (пока пустая) — к ней можно подключиться «Толстым клиентом» в режиме «Конфигуратора» и начать создание/настройку прикладной Конфигурации… Сделайте это сейчас:
  1. Подключитесь к ИБ Конфигуратором (при первом запуске клиента, нужно добавить ИБ в список: кнопка «Добавить» / «Добавление в список существующей информационной базы» / «На Сервере 1С: Предприятия» / «Кластер серверов» = delldev (имя хоста сервера); «Имя ИБ в кластере» = test1c );
  2. Загрузите Конфигурацию («Конфигурация / Загрузить конфигурацию из файла (.cf)»… затем пройдёт длительный процесс слияния конфигураций и перестройки БД, с запросами подтверждений);
  3. Импортируйте реальные учётные данные (пункт меню «Администрирование / Загрузить информационную базу» — это когда данные были предварительно выгружены в «файловый вариант ИБ», используется для сервисных нужд);
    Примечание: не путайте этот пункт с «восстановлением базы данных PostgreSQL из регулярной резервной копии» — этот процесс делается на сервере СУБД PostgreSQL, для всего кластера баз данных целиком, т.е. для всех информационных баз хранящихся на текущем сервере СУБД… Это операция грубая и грандиозная, делается в случае сбоев сервера или при миграции существующего сервера на новое железо...
  4. Настройте Пользователей системы и их Роли (пункт меню «Администрирование / Пользователи»… обязательно создайте пользователя «Администратор» и включите ему все возможные Роли).


А когда прикладная Конфигурация будет загружена и настроена — к ней можно будет подключаться разными клиентами (толстым, тонким, web) для использования и решения прикладных задач…

На этом всё! Спасибо за внимание!




Литература (использованная и дополнительно рекомендуемая)



За основу методики взяты статьи:


Книга «1С: Предприятие 8.2 — Руководство администратора».

Вдобавок может быть интересно форум-обсуждение «Есть ли возможность разнести сервера: 1С Сервер отдельно от PostgreSQL?»

Смотри также рекомендации по тонкой настройке и оптимизации PostgreSQL (после установки системы пригодится) (немного устарело): тут, тут, тут, тут, тут

Базовые требования к ОС для работы платформы 1С: Предприятие 8.x ...
Андрей Андреев @Celeron81
карма
12,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (34)

  • +8
    1. Статья для опытных линукс адмнистраторов, а в статье рассказывается про su, настройку сети и что такое gateway, и еще в добавок базовые настройки системы… Странно, не правда ли?
    2. Много лишних банальных пунктов, из-за которых статья похожа на бочонок.
    3. В целом статья очень хорошая, читать было интересно. Спасибо.

    По пунктам 1 и 2, либо удалите не нужную информацию для опытных администраторов линукса, либо удалите надпись что статья предназначается для них, а вместо нее поставьте предупреждение (раз вам так хочется кого-то о чем-то предупредить и придать напущенности статье), что статья подразумевает базовые знания *nix.
    • +2
      Уж лучше так, чем недосказанность в каких-либо местах. Автору респект за статью.
  • +4
    Ставил я 1С и на Debian, и на ALTLinux, и 32 и 64. Сама установка и запуск простые. Ставил два одновременно работающих (на разных портах, разумеется) 1С сервера на одну систему. Пока конфигурация стандартная, связка Linux+1C+PostgreSQL работает, но как только в неё начинают вносить изменения программисты, начинает падать в неожиданных местах, вплоть до падений при попытке РАСПЕЧАТАТЬ счёт на оплату (то есть формирует, отправляешь на печать, материшься/плачешь). Пришлось в итоге сказать клиенту, чтоб покупал Win + MSSQL. Заработало.
  • 0
    А может кто-нибудь рассказать, что содержат патчи 1С? Я вообще не понимаю с чего бы его патчить. Если он не работает с 1С-кой это ведь 1Ску патчить надо…
    • +1
      Там внесены изменения в режим блокировок.
      • 0
        Т.е. оно все-таки работает «как надо» (как в MSSQL)? Просто я слышал, что при программировании в 1С под постгресс лучше пользоваться управляемыми блокировками чтобы не блочились целые таблицы.
        • 0
          PostgreSQL — версионник, в нем используется иной механизм блокировок, не как в MSSQL. И конечно, при работе с постгрес нужно использовать управляемые блокировки иначе утоните в «конфликте блокировок».
    • 0
      1c имеет свою логику работы с данными в БД, и вот она не всегда просто и гладко ложится на классическую технологию, т.к. имеет в своем арсенале объектно-ориентированную составляющую.
      Изначально платформа писалась под MSSQL, а уже потом появились вариации на тему Linux с postgres. Естественно пропатчить проприетарную СУБД весьма проблематично, поэтому они написали платформу с учетом требований MS SQL.
      Но т.к. вроде и Postgres, и MS SQL — СУБД, но они все таки разные по внутренней архитектуре. И вот здесь и накладываются патчи, чтобы привести к общему знаменателю (среднему по больнице) СУБД.
      • 0
        ну я в принципе имею представление о том какие могут быть проблемы, хотелось узнать какие конкретно изменения вносят патчи 1С в постгрес
        • 0
          Я к сожалению не скажу, не смотрел) Только читать исходники.
        • 0
          Самое главное — это поддержка типа данных mchar (независимый от регистра тип данных, при сравнениях полей этого типа РеГистр символов не важен). Это делает PG похожим на MS SQL, в котором такие типы по умолчанию.
          • 0
            Действительно, сейчас просмотрел патч, почти все изменения сводятся к поддержке mchar и mvarchar, спасибо.
  • +3
    Рпм пакеты выложите куда нибудь, вы их собрали, остальным их собирать теперь не зачем.
    • 0
      Фирма 1С даёт уже патченные исходники (это проще). И из них потом собрать RPMки под свою систему — получается легко и по довольно прозрачной методике.
      А если вскоре выйдет новый релиз PostgreSQL — то методика будет работать, а RPM-ки устареют.
      И потом: мне нельзя выкладывать RPMки — я же неофициальное и недоверенное лицо! А вдруг я накосячил при сборке? А вдруг я хакер и вставил backdoor? Правильные админы не возьмут неофициальные сборки для сервера…
    • 0
      Вот здесь можно скачать пакет PostgreSQL, с приложенными патчами 1С, собранные под все системы: wiki.etersoft.ru/PostgreSQL
  • +4
    Статья полезная, наверняка сэкономит кому-то много времени, хотя бы за счет того, что все собрано в одном месте. Но некоторые вещи не совсем верны.
    Во первых для работы консоли администрирования и вообще 1С сервера совешенно не нужен самба сервер, я не понимаю почему это утверждение тянется из одной статьи в другую, у меня имеется 2 инсталляции 1С под CentOS в обеих нет самба сервера:
    yum list installed | grep samba
    samba-client.i686 3.5.10-125.el6 base
    samba-common.i686 3.5.10-125.el6 base
    samba-winbind-clients.i686
    все тем не менее работает корректно.

    Во вторых есть большие сомнения по поводу SElinux, имеется сервер где SElinux включен и все работает нормально, при этом есть сервер где SElinux отключен, но 1С сегфолтится, притом проблема только с версиями старше 8.2.15, 8.2.14 работают корректно, изыскания в сети и собственные эксперименты показали, что проблма в совместимости с железом (sic!) в виртуальной машине 8.2.15 работает корректно.
    • –2
      Основное назначение Samba здесь — легко и просто резолвить в локальной сети символическое «имя компьютера» сервера в его IPшник, без применения и доп.настройки DNS сервера (и чтобы вообще не поднимать локального DNS). Это только для дополнительного удобства работы софта с клиентских компьютеров. Так они могут и обращаться к серверу через символическое имя, и не править себе hosts, и прописывать DNS какой-хотят…
      А потом, если в дальнейшем понадобится и файлообмен между клиентами [и сервером] организовать — то вот она сетевая шара... (Ну, это конечно для маленьких решений: когда выделенный сервер один.)
      • +2
        Использовать самбу вместо DNS это конечно немного странно, но пожалуй оправданно в некоторых ситуация. Но главное что в статье написано:
        Samba-сервер необходим для работы сервисов 1С, при явных и неявных использованиях протокола NetBIOS (что может быть и недокументировано, но нужно понимать, что 1С была всегда заточена под Windows). Например: MMC-оснастке «Администрирование серверов 1С: Предприятия» требуется аналог Cлужбы доступа к файлам и принтерам Windows – Samba. То есть Samba нужно обязательно настроить, иначе работать с этой оснасткой не удастся.

        Это не совсем соответствует действительности, и вообще звучит «не научно».
        • –2
          Да, согласен! Это и «не научно», и не совсем соответствует действительности… Это есть шаманство, чтобы столь сложная распределённая система, портированная из Windows в Linux, заработала с чуть большей вероятностью! ;) Извините мне эту формулировку — я только хотел сказать пользователям, что Samba лучше поднять.
          Саму фразу «Samba настроить нужно обязательно, иначе работать с этой оснасткой не удастся» — я почти дословно прицитировал из другой статьи... Но та статья для «1С: Предприятия 8.1» и уже подустарела…
          И кстати, я признаю, что у вас опыта в 1С под Линукс — явно больше моего! Пусть ваш комментарий (что Samba не обязательна для сервера 1С) будет правильным дополнением к статье.
          • 0
            *дополнение: по профессии я — программист, аналитик и технический писатель. не сисадмин.
            поэтому замечания профессиональных админов к статье будут очень кстати.
  • +2
    Совет.
    Не делайте так su -c 'rpm -Uvh download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm'
    Так лучше sudo yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm
  • +2
    А я жаловался на арч, что у него сложная и не интуитивная установка… Да он просто бог простоты по сравнению с вашим «одноэс»
    • –2
      Просто нужно не клепать велосипеды, а ставить в более традиционной среде. Тоже самое в родной винде — запустить инсталлятор, клик-клик-клик, и готово. :)
      • +1
        А как-же снятие галочки с яндекс.бара и установка на 'да согласен я'?
        • +1
          При установке и настройке 1С Предприятие и MS SQL?
          • 0
            Ну, во втором может еще и нету…
  • 0
    Скорее всего, вы пропустили какие-то пункты. В который раз пробую с нуля — не работает.

    [root@srv1c 1c]# cd /tmp/postgre/
    [root@srv1c postgre]# rpm -ihv postgresql-9.0.3-3.1C.src.rpm
    1:postgresql ########################################### [100%]
    [root@srv1c postgre]# mcedit /usr/lib/rpm/macros

    [root@srv1c postgre]# ln -s /usr/lib/libicui18n.so /usr/local/lib/libicui18n.so.46
    [root@srv1c postgre]# ln -s /usr/lib/libicudata.so /usr/local/lib/libicudata.so.46
    [root@srv1c postgre]# ln -s /usr/lib/libicuuc.so /usr/local/lib/libicuuc.so.46
    [root@srv1c postgre]# rpmbuild -bb --define 'runselftest 0' ~/rpmbuild/SPECS/postgresql-9.0-1C
    ошибка: невозможно получить информацию о /root/rpmbuild/SPECS/postgresql-9.0-1C: Нет такого файла или каталога
    • 0
      Хм, я только что перепроверил…

      Файл rpm -ihv postgresql-9.0.3-3.1C.src.rpm вы скачали с оф.сайта?
      Установку произвожу от root…
      Удаляю папку ~/rpmbuild/ (для чистоты эксперимента)
      У меня при установке пакета: rpm -ihv postgresql-9.0.3-3.1C.src.rpm
      Создаётся папка: /root/rpmbuild/
      В ней две подпапки: SOURCES и SCPEC
      в последней присутствует файл: /root/rpmbuild/SPECS/postgresql-9.0-1C.spec (внимание! название файла имеет расширение .spec)

      Ага, может вы не указываете последнего расширения?
      Если я запускаю билд: rpmbuild -bb --define 'runselftest 0' ~/rpmbuild/SPECS/postgresql-9.0-1C
      То у меня конечно выскакивает ошибка: «невозможно получить информацию о /root/rpmbuild/SPECS/postgresql-9.0-1C: Нет такого файла или каталога»

      Но правильно так: rpmbuild -bb --define 'runselftest 0' ~/rpmbuild/SPECS/postgresql-9.0-1C.spec
      и сборка идёт нормально…

      Проверье ещё: существует ли указанный файл спеки и правильные ли разрешения на папке ~/rpmbuild/SPECS/? (хотя если вы устанавливали пакет «postgresql-9.0.3-3.1C.src.rpm» — то должны быть правильные)
    • 0
      Если у вас всё-таки не получится пересобрать RPMки, то можете использовать мои пересобранные — я выложил здесь: PostgreSQL_от_1С_релиз_9.0.3-3.1C_от_17.01.12_-_RPMS_пересобранные_для_CentOS_6.3_32bit.rar.

      Предупреждение: Мои RPMки неофициальные — поэтому я не выкладывал их ранее, ведь это не совсем «концептуально правильно»… Но раз люди просят, то выкладываю.
      Однако, если у вас 64bit-ный Линукс, то вам они не подойдут. Под 64bit пока пересобрать не могу, извините.
  • 0
    Есть мелкие ошибки, неточности. Кое-чего не хватает. Но для начала этого достаточно. Радостно, что такие монстры-производители софта как 1С начали обращать внимание на спо-платформы.
    • 0
      сюда буду потихоньку добавлять неточности

      Наконец, просмотрим список собранных RPM-пакетов (т.к. у меня ОС Линукс 32-битная, то и пакеты PostgreSQL были собраны тоже 32-битной версии):
      bash# ls -1 ~/rpmbuild/RPMS/i686
      postgresql-9.0.3-3.1C.i686.rpm


      Поменять 686 на 386
      • 0
        На самом деле, i686 и i386 — это практически одно и то же… и обе 32bit.

        Перед компиляцией, Скрипт Автоконфигурации сам определяет наиболее подходящие параметры для сборки, подстраиваясь под ОС и установленные в системе библиотеки, и под текущую архитектуру процессора (i386, i686 или др.)… Тут ни программист, ни сисадмин не вмешиваются («поменять» в принципе можно, но не нужно).

        Что лучше?
        При сборке с параметрами «под архитектуру i686» в бинарный код программы вшивается расширенный набор команд — новые команды уже присутствующие в этой поздней архитектуре i686, но которые ещё не присутствовали в более ранних (i386, i586) реализациях архитектуры. На современных 32-битных процессорах, одна и та же программа будет выполняться быстрее и оптимальнее, если она собрана «под архитектуру i686».

        Тут ещё скользкий момент: «Архитектура процессора» и «битность инструкций» — это близкие, но разные вещи! 64-битные инструкции стали появляться в процессорах, начиная с Intel Pentium4 и AMD Athlon64. И с тех пор, в более новых архитектурах процессоров, количество и разнообразие 64-битных инструкций всё расширяется…

        Для обозначения разных архитектур сложились традиционные названия (суффиксы в именованиях пакетов):
        i386, i586, i686, x86 (32bit )
        amd64, em64t, x86_64 (64bit)

        Подробнее смотрите:
        Википедия — x86
        Вопрос: Что такое i686?
        Вопрос: x86-x64 или др. (i386, i586, i686)?
        Вопрос: Что такое x86 и i686?
    • 0
      Создание ссылок одной командой:
      ln -s /usr/pgsql/bin/clusterdb /usr/local/bin/clusterdb &&
      ln -s /usr/pgsql/bin/droplang /usr/local/bin/droplang &&
      ln -s /usr/pgsql/bin/pgbench /usr/local/bin/pgbench &&
      ln -s /usr/pgsql/bin/pg_resetxlog /usr/local/bin/pg_resetxlog &&
      ln -s /usr/pgsql/bin/postmaster /usr/local/bin/postmaster &&
      ln -s /usr/pgsql/bin/createdb /usr/local/bin/createdb &&
      ln -s /usr/pgsql/bin/dropuser /usr/local/bin/dropuser &&
      ln -s /usr/pgsql/bin/pg_controldata /usr/local/bin/pg_controldata &&
      ln -s /usr/pgsql/bin/pg_restore /usr/local/bin/pg_restore &&
      ln -s /usr/pgsql/bin/psql /usr/local/bin/psql &&
      ln -s /usr/pgsql/bin/createlang /usr/local/bin/createlang &&
      ln -s /usr/pgsql/bin/initdb /usr/local/bin/initdb &&
      ln -s /usr/pgsql/bin/pg_ctl /usr/local/bin/pg_ctl &&
      ln -s /usr/pgsql/bin/pg_standby /usr/local/bin/pg_standby &&
      ln -s /usr/pgsql/bin/reindexdb /usr/local/bin/reindexdb &&
      ln -s /usr/pgsql/bin/createuser /usr/local/bin/createuser &&
      ln -s /usr/pgsql/bin/oid2name /usr/local/bin/oid2name &&
      ln -s /usr/pgsql/bin/pg_dump /usr/local/bin/pg_dump &&
      ln -s /usr/pgsql/bin/pg_upgrade /usr/local/bin/pg_upgrade &&
      ln -s /usr/pgsql/bin/vacuumdb /usr/local/bin/vacuumdb &&
      ln -s /usr/pgsql/bin/dropdb /usr/local/bin/dropdb &&
      ln -s /usr/pgsql/bin/pg_archivecleanup /usr/local/bin/pg_archivecleanup &&
      ln -s /usr/pgsql/bin/pg_dumpall /usr/local/bin/pg_dumpall &&
      ln -s /usr/pgsql/bin/postgres /usr/local/bin/postgres &&
      ln -s /usr/pgsql/bin/vacuumlo /usr/local/bin/vacuumlo
      
  • 0
    Спасибо автору, статья очень помогла!
    У меня только вопрос, кто может, помогите.

    Centos 6.3 x64
    при проверке системы с помощью config_server
    вылезают следующие недостающие пакеты:
    ImageMagick libgsf libglib UnixODBC
    Подскажите правильные названия требуемых пакетов, чтоб установить их с помощью yum.
    Только FreeType я смог номально установить.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.