1. Предварительная подготовка

Что у нас есть и что с этим делать?

Имеется:

• Русская версия Windows 2000 Server SP4, AD
• Домен: MYDOMAIN
• Netbios имя сервера: win_server
• Имя нового Linux-сервера: lin_server
• ОС на рабочих станциях: Windows 2000/XP

Для Linux-сервера я выбрал новый на момент написания статьи Ubuntu Linux 7.04 Feisty со следующими версиями пакетов:

• slapd 2.3.30-2
• samba 3.0.24-2ubuntu1.1
• smbldap-tools 0.9.2-3
• libnss-ldap 251-7.5
• libpam-ldap 180-1.7
• phpldapadmin 0.9.8.3-7
• nscd 2.5-0ubuntu14
• apache2 2.2.3-3.2build1

Инструмент для перехода: Windows to Linux Migration Toolkit (w2lmt).

Инструмент для графического отображения дерева LDAP: phpldapadmin.

Подготовка Windows-сервера.

Следующие группы, названные по-русски, необходимо переименовать:

Связано это с тем, что эти группы имеют фиксированное значение SID, а используемый в процессе перехода скрипт smbldap-populate создаст группы с именами в латинице, и пользователи корректно не перенесутся на новую систему.

Также надо быть особо внимательным, если в сети имеется несколько рабочих станций, за которыми работают под одним и тем же именем.

Подготовка Linux-сервера

Подготовка Linux-сервера сводится к устранению возможных дубликатов uid и gid, хранящихся в базе LDAP и в /etc/passwd.

После первоначальной установки ОС Linux, в системе создается первый пользователь с uid=1000 и gid=1000.

Скрипт smbldap-populate без параметров создаст первоначальную структуру LDAP, в которой будут созданы пользователи root и nobody, а первый пользователь домена будет иметь uid=1000. Т.е. будет конфликт между локальным пользователем и пользователем в LDAP, имеющими одинаковый uid=1000.

Группы, созданные smbldap-populate будут иметь следующие параметры:

В заново установленной ОС Linux локальных групп с такими gid-ми скорее всего не будет, но лучше убедиться, что их действительно нет. И, если есть, присвоить им другие значения gid, отличные от перечисленных.

Предполагается, что в сети уже есть работающий DNS-сервер.
В моей сети работает связка DDNS + DHCPD3. О том, как ее настроить можно прочитать здесь:
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html
http://www.opennet.ru/base/net/auto_dns_dhcp.txt.html

2. Windows to Linux Migration Toolkit

Краткое отступление
Об утилитах Windows to Linux Migration Toolkit (w2lmt) я узнал из книги Дэвида Аллена "Переход с Windows на Linux".

Другой документации или какого-либо описания работы w2lmt в Сети я не нашел. Поэтому все описанное цитаты из книги и личный опыт. Книга посвещена не только w2lmt, все "грабли" в ней не расписаны.

Кроме этого, я не буду полностью описывать работу w2lmt, а коснуcь только тех моментов, которые возникали именно в моем процессе перехода.

Состав w2lmt
Для перехода с AD на LDAP+Samba3 использовались w2lmt 0.3.1.
Скачанный архив, кроме всего прочего, содержит perl-скрипты и соответствующие им конфигурационные файлы.

Все скрипты запускаются с ключем "-f /path/to/file.conf".
Для работы скриптов требуется пакет smbldap-tools версии не ниже 0.8.5.

3. Установка и настройка

Установка пакетов

Устанавливаем сервер LDAP:

Отвечаем на следующие вопросы:

DNS domain name: mydomain
Name of organisation: My Organization
Admin password: password
Confirm password: password
Allow LDAP v2: no

После первой установки slapd, в базе LDAP будет единственная запись администратора cn=admin,dc=mydomain с паролем password.

Устанавливаем phpldapadmin и apache2

Устанавливаем samba

Отвечаем на следующие вопросы:

Domain Name: MYDOMAIN
Use Password Encryption: Yes
Modify smb.conf to use WINS settings via DHCP: No
How to run Samba: daemons
Create password database: Yes

Хотя созданный файл smb.conf будет изменет, на вопросы ответить придется.

Устанавливаем smbldap-tools и ldap-utils

Настройка

Настройка slapd

• Необходимо скопировать файл /usr/share/doc/samba-doc/example/LDAP/samba.schema.gz в папку /etc/ldap/schema/ и распаковать его.
• В файл /etc/ldap/slapd.conf в конце списка, помеченного строкой
  # Schema and objectClass definitions
  нужно добавить строку
  include /etc/ldap/schema/samba.schema

  В результате файл slapd.conf будет выглядеть примерно так:

  # This is the main slapd configuration file. See slapd.conf(5) for more
  # info on the configuration options.

  #######################################################################
  # Global Directives:

  # Features to permit
  #allow bind_v2

  # Schema and objectClass definitions
  include /etc/ldap/schema/core.schema
  include /etc/ldap/schema/cosine.schema
  include /etc/ldap/schema/nis.schema
  include /etc/ldap/schema/inetorgperson.schema
  include /etc/ldap/schema/samba.schema

  # Where the pid file is put. The init.d script
  # will not stop the server if you change this.
  pidfile /var/run/slapd/slapd.pid

  # List of arguments that were passed to the server
  argsfile /var/run/slapd/slapd.args

  ###################################################################
  # loglevel # Logging description

  loglevel 256

  # Where the dynamically loaded modules are stored
  modulepath /usr/lib/ldap
  moduleload back_bdb

  # The maximum number of entries that is returned for a search operation
  sizelimit 500

  # The tool-threads parameter sets the actual amount of cpu's that is used
  # for indexing.
  tool-threads 1

  #######################################################################
  # Specific Backend Directives for bdb:
  # Backend specific directives apply to this backend until another
  # 'backend' directive occurs
  backend bdb
  checkpoint 512 30

  #######################################################################
  # Specific Directives for database #1, of type bdb:
  # Database specific directives apply to this databasse until another
  # 'database' directive occurs
  database bdb

  # The base of your directory in database #1
  suffix "dc=MYDOMAIN"

  # Where the database file are physically stored for database #1
  directory "/var/lib/ldap"

  # For the Debian package we use 2MB as default but be sure to update this
  # value if you have plenty of RAM
  dbconfig set_cachesize 0 2097152 0

  # Number of objects that can be locked at the same time.
  dbconfig set_lk_max_objects 1500

  # Number of locks (both requested and granted)
  dbconfig set_lk_max_locks 1500

  # Number of lockers
  dbconfig set_lk_max_lockers 1500

  # Indexing options for database #1
  index objectClass eq

  # Save the time that the entry gets modified, for database #1
  lastmod on

  # users can authenticate and change their password
  access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange
  by dn="cn=admin,dc=MYDOMAIN" write
  by self write
  by anonymous auth
  by * none

  # The admin dn has full write access, everyone else
  # can read everything.
  access to *
  by dn="cn=admin,dc=MYDOMAIN" write
  by * read

• Для проверки нужно выполнить команду slaptest:
  
  $ slaptest
  config file testing succeeded

Настройка samba

• Файл /etc/samba/smb.conf:
  
  # Global parameters
  [global]
  wins support = no
  protocol = NT1
  name resolve order = lmhosts host bcast
  dns proxy = no
  dos charset = CP866
  unix charset = UTF-8
  display charset = UTF-8
  workgroup = MYDOMAIN
  server string = linserver Server
  netbios name = LINSERVER
  netbios aliases = linserver
  security = users
  map acl inherit = yes
  inherit acls = yes
  inherit permissions = yes
  encrypt passwords = yes
  null passwords = yes
  enable privileges = yes

  passdb backend = ldapsam:ldap://127.0.0.1
  idmap backend = ldap:ldap://127.0.0.1
  ldap admin dn = cn=admin,dc=mydomain
  ldap suffix = dc=mydomain
  ldap machine suffix = ou=Computers
  ldap user suffix = ou=Users
  ldap group suffix = ou=Groups
  ldap passwd sync = yes
  ldap delete dn = yes
  ldap passwd sync = yes
  ldap ssl = no

  preferred master = yes
  domain master = no
  domain logons = yes

  logon path =
  logon drive = Z:
  logon home = \\%L\SYSVOL\users\%U

  add machine script = /usr/sbin/smbldap-useradd -t 0 -w "%u"
  add user script = /usr/sbin/smbldap-useradd -m "%u"
  delete user script = /usr/sbin/smbldap-userdel "%u"
  add group script = /usr/sbin/smbldap-groupadd -p "%g"
  delete group script = /usr/sbin/smbldap-groupdel "%g"
  add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
  delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
  set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u'

  interfaces = 127.0.0.0/8 eth0
  hosts allow = 127.0.0.1 192.168.0.0/255.255.255.0
  hosts deny = ALL
  map to guest = Bad User
  guest account = nobody
  log file = /var/log/samba/log.%m
  max log size = 500 # in Kb
  log level = 5
  socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192
  socket address = 127.0.0.1 192.168.0.2

  printing = cups
  load printers = yes

  ####### MAIL THE ADMIN A BACKTRACE
  panic action = /usr/share/samba/panic-action %d

  [homes]
  comment = Home Directories
  guest ok = No
  browseable = No
  create mask = 0644
  directory mask = 0775
  writeable = yes
  inherit permissions = Yes

  [profiles]
  path = /home/SYSVOL/profiles
  comment = User Profiles
  guest ok = Yes
  browseable = No
  create mask = 0600
  directory mask = 0700
  writeable = Yes
  profile acls = Yes
  csc policy = disable
  force user = %U
  valid users = %U @"Domain Admins"

  [netlogon]
  comment = User Netlogon
  path = /home/SYSVOL/netlogon
  browseable = No
  write list = MYDOMAIN@"Domain Admins"

  [IPC$]
  # IPC необходимо для нормальной работы Windows-домена:
  # browse network, browse folder и прочее.
  path = /tmp
  hosts allow = 192.168.0.0/24, 127.0.0.1
  hosts deny = 0.0.0.0/0

  Для хранения сценариев регистрации, профилей и домашних папок пользователей LDAP, я создал папку /home/SYSVOL (по аналогии с Windows, мне так удобнее). Соответственно, в ней созданы папки netlogons, profiles, users.

  Параметры domain master = no и domain logons = yes превращают сервер Samba в резервный контроллер домена.

  Параметр logon path = оставлен пустым, т.к. я не хочу хранить профили пользователей рабочих станций на сервере. Если все же требуется хранить профили, то нужно указать путь. По-умолчанию
  logon path = \\%N\%U\profile

• Проверить файл smb.conf на наличие ошибок можно с помощью команды testparm. Если ошибок нет, Samba надо перезапустить.
• Далее следует задать Samba пароль администратора (rootdn) LDAP:
  $ smbpasswd -w password
• Если все операции прошли без ошибок, Samba следует остановить.
  $ /etc/init.d/samba stop

Пакеты для аутентификации Linux

• Устанавливаем пакет libnss-ldap
  
  $ apt-get install libnss-ldap
  LDAP Server Host: 127.0.0.1
  DN of Search Base: dc=mydomain
  LDAP Version: 3
  Database requires login: no
  Make config readable by owner only: yes
• Корректируем в файле /etc/nsswitch.conf параметры passwd, group и shadow:
  
  passwd: compat ldap
  group: compat ldap
  shadow: compat ldap

Устанавливаем пакет libpam-ldap

$ apt-get install libpam-ldap
Make local root db admin: yes
Database requires logging in : no
Root login account : cn=admin,dc=mydomain
Root password : password
Crypt : crypt

Файл /etc/ldap/ldap.conf должен выглядеть так:

BASE dc=mydomain
HOST localhost
• Для настройки PAM для LDAP надо внести изменения в следующие файлы:

  /etc/pam.d/common-account

  # Закоментировать следующую строку
  #account required pam_unix.so

  # и добавить две строки
  account sufficient pam_ldap.so
  account required pam_unix.so try_first_pass

  /etc/pam.d/common-auth

  # Закоментировать следующую строку
  #auth required pam_unix.so nullok_secure

  # и добавить две строки
  auth sufficient pam_ldap.so
  auth required pam_unix.so nullok_secure use_first_pass

  /etc/pam.d/common-password

  # Закоментировать следующую строку
  #password required pam_unix.so nullok obscure min=4 max=8 md5

  # и добавить две строки
  password sufficient pam_ldap.so
  password required pam_unix.so nullok obscure min=4 max=8 md5 use_first_pass

• Устанавливаем пакет nscd (name service caching daemon):
  
  $apt-get install nscd

4. Переход

Итак, Linux-сервер готов для переноса пользователей из AD в LDAP. Но нужно сделать еще кое-что.

Дерево LDAP.

Я использовал простую структуру дерева LDAP, которую создает утилита smbldap-populate.

w2lmt

Скачиваем архив w2lmt-0.3.1 и распаковываем его любое удобное место.

Далее следует внести изменения в файл migrate-smbauth.conf.

Если Active Directory выполняется в смешанном режиме (Mixed Mode, как раз мой случай), то в файле конфигурации сценария w2lmt-migrate-smbauth в качестве SourceType следует использовать настройку NT4. При использовании этой настройки сохраняется SID и RID существующего домена.

При выполнении Active Directory в "родном" режиме (Native Mode) сценарии будут создавать новый домен с новыми SID и RID для пользователей, групп и машин. Это происходит потому, что собственный режим AD не совместим с доменом типа Samba NT4, на который осуществляется переход. Следует помнить о том, что все объедененные в этом домене машины необходимо повторно объединять в новый домен на базе Linux.

Сценарий w2lmt-migrate-smbauth по ходу выполнения вызовет скрипт smbldap-populate без параметров. Т.к. установки по-умолчанию меня не устраивали, я внес в файл w2lmt-migrate-smbauth следующие изменения:

• В конце файла есть описание функции initldapou
  
  sub initldapou {
  ########################################################################
  # Checks ldap server to see if initial entries have been placed in there
  # adds them if necessary
  ########################################################################
  .....
  if ($checkvar lt 110) {
  $cmd = $config{'smbldap-populate'};
  print $cmd;
  print "\n";
  print "Initializing root Directory objects...\n";
  $result=`$cmd`;
  } else {
  print "Directory root objects have been previously populated...\n";
  }
• Строку "$result=`$cmd`;" я заменил на "$result=`$cmd -u 10000 -g 5000 -a Administrator -b guest`;".
  Т.е. добавил параметры к вызову скрипта smbldap-populate, которые означают, что в моем дереве LDAP uid-ы начинаются с 10000, gid-ы начинаются с 5000, учетное имя локального администратора (с uid=0) - Administrator, гостевое имя - guest.
  В smbldap-populate по-умолчанию, соответственно 1000, 1000, root, nobody.

smbldap-tools

По-умолчанию, после установки пакета smbldap-tools, в папке /etc отсутствуют его конфигурационные файлы. По-этому их надо создать вручную. Это файлы /etc/smbldap-tools/smbldap.conf и /etc/smbldap-tools/smbldap_bind.conf.

Непосредственно для перехода конфигурационные файлы smbldap-tools можно оставить пустыми. Главное, чтобы они были, иначе скрипты smbldap-tools просто не будут выполняться, ссылаясь на их отсутствие.

Сценарий w2lmt-migrate-smbauth сначала покажет список параметров и их значения по-умолчанию и позволит изменить значения некоторых из них, но, увы, не у всех. По-этому конфигурационные файлы smbldap-tools лучше все-таки заполнить. Как вариант, их можно скопировать из папки /usr/share/doc/smbldap-tools/examples в папку /etc/smbldap-tools/ и отредактировать.

У меня конфигурационные файлы smbldap-tools выглядят так:

/etc/smbldap-tools/smbldap_bind.conf

/etc/smbldap-tools/smbldap.conf

Обратите внимание на то, что параметр SID закомментирован. Если его раскомментировать, то сценарий w2lmt-migrate-smbauth сам подставит занчение SID, и оно будет не верным. Почему так, я не понял, установил опытным путем.
После того, как перенос данных из AD в LDAP будет выполнен, следует раскомментировать параметр SID и прописать его значение, узнать которое можно будет с помощью команды net getlocalsid.

Параметр ldapTLS="0" означает, что я не использую шифрование.

Параметр userProfile="" означает, что я не использую перемещаемые профили. Если есть необходимость их использовать, то этот параметр будет выглядеть, например, так: userProfile="\\LAN2\profiles\%U".

Ключ на старт

Перед запуском сценария w2lmt-migrate-smbauth стоит лишний раз убедиться в следующем:

• Сервер Samba должен быть остановлен!
• Сервер slapd должен быть запущен.
• База LDAP должна содержать единственную запись администратора LDAP, т.е. cn=admin,dc=mydomain. Убедиться в этом можно с помощью phpldapadmin. Нужно в браузере зайти по адресу http://lin_server/phpldapadmin, выбрать "Login", в поле "Login DN" ввести "cn=admin,dc=mydomain", ввести пароль.
  Если в процессе настройки сервер slapd перезапускался, когда сервер samba был запущен, то в базе LDAP будет присутствовать запись "sambaDomainName=MYDOMAIN". Эту запись необходимо удалить.

Теперь запускаем сценарий w2lmt-migrate-smbauth

После этого на экране появится примерно такой диалог:

В общем то можно нажать M и исправить параметры, но я бы не рекомендовал так поступать, т.к. скрипт позволяет редактировать только некоторые из показанных. Лучше выйти и отредактировать файлы конфигурации в текстовом редакторе.

Жмем C.
Вот тут я не сразу смог понять, что же не так. Вроде бы и настройки верные, и первоначальное дерево LDAP создалось, а перенос пользователей начинается только, если нажать два раза Enter.
Дело в том, что по окончанию создания первоначального дерева LDAP, скрипт smbldap-populate предлагает ввести пароль Администратора. Скрипт w2lmt-migrate-smbauth строку приглашения ввода пароля не выводит, просто курсор мигает. Так что пароль и подтверждение пароля пользователя Administrator приходится вводить вслепую.

Теперь можно пойти заварить кофейку. Перенос моих пользователей занял около 20 мин. ;-)

"Обработка напильником"

Можно сказать, что на этом все. Windows сервер можно выключать. Все пользователи со всех рабочих станций успешно прошли аутентификацию. Но "грабли" на некоторых станциях все же были, причем я не смог установить связаны ли они с версий Windows или с чем то еще.
Проблемы следующие:

• Не у всех пользователей подключился персональный диск (Z:).
• На некоторых станциях Login Script вообще не выполнялся.
• На некоторых станциях не проходила печать на сетевые принтеры, при этом доступ к сетевым дискам был.

Решение было одно - вывести станции из домена и заново их зарегистрировать.

5. Заключение

Осень 2007 года подходит к концу.
Описанный вариант замены Active Directory на OpenLDAP+Samba3 был осуществлен полгода назад.
Система продолжает успешно работать.

Повторюсь, предложенное описание перехода не претендует на Полное руководство или How-To. Пишу, в основном, для себя.

Буду рад, если кому-то это описание окажется полезным.

Установка сервера ИС-ПРО 4 под Linux

Технические требования.

Для работы сетевого варианта ИС-ПРО с выделенным сервером потребуется сервер следующей конфигурации:

Рекомендуемая конфигурация:
• Процессор : Intel Pentium III 800 MHz или выше
• Объем оперативной памяти : 256 Mb или более
• Жесткий диск : 10 Gb Ultra Wide SCSI
  Приведенные выше параметры предназначены для сетей с 10-25 рабочими станциями.

  Операционная система GNU/Linux.
  Подойдет в общем-то любой дистрибутив Linux, но RPM-based будет удобнее. Почему - поясню далее.

  Требования к конфигурации операционной системы GNU/Linux:

• Kernel version 2.4 или выше
• Glibc 2.1 или выше
• PAM libraries (if PAM is selected for security)
• Установленный сервер SAMBA
• Файловая система: ext3 или raisefs
• Установленная и запущенная система управления базами данных Pervasive.SQL 2000i Service Pack 3 или выше

Полный список режимов работы и аппаратно-программных требований ИС-ПРО смотрите здесь: http://www.intelserv.kiev.ua/texn.shtml

Проще говоря, для того, чтобы ИС-ПРО заработал, на серере нужно установить Pervasive.SQL 2000i SP3 или выше и SAMBA.

Несколько слов, о чем на сайтах, посвященных ИС-ПРО, не говорится.

Хотя, может я просто плохо искал... Если честно, особенно и не старался...

Pervasive.SQL 2000i под Linux распространяется в виде RPM-пакета или ZIP-архива, содержащего RPM-пакет сервера Pervasive.SQL 2000i, клиента под Windows и программы Pervasive System Analyzer.
Pervasive.SQL 2000i - на самом деле это версия 7.9x, предшествующая Pervasive 8.0. ServicePack-ам соответствуют следующие версии RPM-пакетов:

Pervasive.SQL 2000i SP3 - Pervasive.SQL-7.90.243.007-2000i.i386.rpm
Pervasive.SQL 2000i SP4 - Pervasive.SQL-7.94.251.005-2000i.i386.rpm

Найти их в Internet можно, воспользовавшись сервером "Поиска файлов", например http://www.filesearch.ru, или на сайте производителя http://www.pervasive.com. Точную ссылку на Pervasive.SQL 2000i на сайте производителя дать не могу, т.к. во-первых, текущая версия 9 SP2, и ссылки на ранние версии как-то хитро замаскированны, во-вторых, чтобы скачать Pervasive.SQL 2000i с этого сайта, предварительно надо зарегистрироваться.

В любом случае Вы скачаете 30-и дневную Trial-версию Pervasive.SQL 2000i на 20 пользовательских подключений.

Установка.

SAMBA.

Как уже было сказано, нужно предварительно установить SAMBA. Об этом уже много написано, повторяться не буду.
Отмечу лишь следующее:

• На момент написания статьи установлена версия Samba и Winbind - 3.0.23c
• Настроена аутентификация Samba через ActiveDirectory на Windows 2000 Server. Если в локальной сети имеется Active Directory, то удобнее сделать именно так. Меньше будет возни с пользователями.

PSQL

RPM-based дистрибутив Linux
Если у Вас RPM-based дистрибутив Linux (RedHat, Mandriva, AltLinux, ASPLinux и т.д.), то проблем с установкой быть не должно. Выполняем команду:

и все.
Для запуска и остановки сервера Pervasive.SQL выполните команду, соответственно

или, если есть поддержка команды service, как в RedHat

Дистрибутив Debian GNU/Linux
Если во всех RPM-based установка Pervasive.SQL 2000i проходит одинаково, то как она пройдет в других дистрибутивах Linux, я не знаю. На своих серверах я использую Debian GNU/Linux. На момент написания статьи установлен Debian Sarge 3.1r2a с текущими обновлениями. Хоть Debian и использует свои DEB-пакеты, с RPM от тоже работать умеет.
Для установки Pervasive.SQL-7.9x.xxx.xxx-2000i.i386.rpm нужно установить rpm и cpio.

Далее тоже самое, что и в RPM-based дистрибутиве, но с ключем, чтобы зависимости не проверялись.

Pervasive.SQL-7.9x.xxx.xxx-2000i.i386.rpm требует sh.xxx.rpm. Разумеется ставиь его из RPM не надо.

У Debian-а нет папки /etc/rc.d, но после установки Pervasive.SQL 2000i она будет создана. В каждом из каталогов /etc/rc.d/init.d, /etc/rc.d/rc0.d, ..., /etc/rc.d/rcS.d будет лежать по одному файлу. Эти файлы нужно будет перенести соответственно в /etc/init.d, /etc/rc0.d, ..., /etc/rcS.d. Или можно просто перенести файл /etc/rc.d/init.d/psql в /etc/init.d/psql и установить его запуск, используя команду update-rc.d.
После этого папку /etc/rc.d можно удалить.

Если по каким-либо причинам команда rpm -ivh ... выдала ошибку, и пакет не установился, то можно преобразовать его в DEB-пакет, воспользовавшить утилитой alien, или распаковать вручную. Но тут уж без "бубна" не обойтись.

Настройка
Pervasive.SQL 2000i установиться в папку /usr/local/psql/. Будут созданы локальный пользователь psql и группа pvsw. В файл /etc/samba/smb.conf будут добавлены сетевые разделы [PSQL] и [PVPIPE$].
Настройки раздел [PVPIPE$] менять не надо, а в [PSQL] следуюет прописать доступ пользователям ИС-ПРО. Так же потребуется создать раздел, в который будет установлена система ИС-ПРО. У меня этот раздел называется [BPRO]. В итоге часть файла smb.conf с настройками для Pervasive.SQL и ИС-ПРО будет выглядеть примерно так:

На этом все. Перезапускаем Samba, на рабочей станции ставим Pervasive.SQL-клиента, назначаем сетевой диск для ресурса \\MYSERVER\BPRO и можно устанавливать систему ИС-ПРО (об этом написано в документации к ИС-ПРО).

Утилиты PSQL.

Хочу отметить две утилиты, которые точно понадобятся.

btadmin [-p пароль] [a+] [a-] [-r] username
btadmin создает или обновляет файл аутентификации пользователей. Для работы ИС-ПРО пользователи, созданные с помощью btadmin не требуются. Но если потребуется снять зависшее подключение или т.п., то эти пользователи понадобятся. Наверное, можно настроить аутентификацию из Active Directory, но я с этим еще не разбирался.

Ключи:
• -p - задать пароль
• -r - удалить пользователя
• a+ - задать пользователю атрибуд "admin"
• a- - убрать у пользователя атрибуд "admin"

ucutil -D <путь> | -G<код> | -K<ключ> | -S
ucutil - утилита поддержки количества пользовательских подключений. Она управляет лицензионными ключами. Чтобы ее использовать, нужно войти в систему как пользователь root.

Ключи:
• -D<путь> - добавить лицензию из указанного пути
• -G<код> - показать количество пользовательских подключений по коду продукта
• -K<ключ> - ввести ключ
• -S - показать серийный номер

Команда:

Покажет серийный номер, на основе которого генерируется лицензионный ключ. Этот ключ вводится с помощью команды:

После выполнение команды:

на экране будет следующее:

Далее нужно ввести код продукта (в моем случае это 11) и тогда будет показано количество возможных пользовательских подключений и дата окончания действия лицензии.

Переход с Windows Server.

Сервер
Если кто-то Вам скажет, что перенести систему ИС-ПРО 4 с сервера Windows на сервер Linux сложно, не верьте. Перенос данных и самой системы - процесс, наверное, самый длительный, но и самый простой во всем описанном здесь "безобразии". ;-) Заключается он в простом копировании всего содержимого папки [BPRO] со старого (Windows) сервера на новый (Linux) сервер.
Первое, что нужно сделать, это остановить сервис Pervasive на Windows-сервере и закрыть файловый доступ к [BPRO] всем, кроме себя. Даже если Вы занимаетесь переносом системы ИС-ПРО в выходные или ночью, когда по-вашему никого на работе нет, подстраховаться не помешает.

Далее, на Linux-сервере, проверьте владельца и группу файлов и папок, скопированных в [BPRO].
Владелец и группа должны быть psql и pvsw.
Если владелец и/или группа другие, то выполняем:

Запускаем Pervasive.SQL

Если требуется, открываем пользователям доступ к ресурсу [BPRO] на Linux-сервере и перезапускаем Samba.

Рабочие станции
Если новый Linux-сервер, конкретно Samba, имеет такое же NETBIOS-имя, что и старый Windows-сервер (мой случай), то делать что либо на рабочих станциях не потребуется. Не важно, как был подключен сетевой диск [BPRO] (именно он нужен для работы системы ИС-ПРО) - в сценарии или средствами Windows. Если сетевое имя сервера и имя сетевого ресурса не изменились, то при загрузке рабочая станция подключит диск, а ИС-ПРО будет продолжать работать. Пользователи даже не узнают, что на сервере сменилась операционная система. Каких либо проблем с аппаратным ключом защиты, установленном на одной из рабочих станций, так же не замечено.

Если же Linux-сервер имеет другое имя, то, возможно, на рабочих станциях придется переустановить клиент Pervasive.SQL (хотя мне не пришлось). Клиентов ИС-ПРО переустанавливать не надо, лишь бы они запускались с подключенного сетевого диска.

Ссылки по теме.

http://volgograd.lug.ru/wiki/TarasAblamsky/PervasiveSQL?v=bt0

Клиент ИС-ПРО 4

Проблема выбора.

Сервер установлен и настроен. Надо ставить клиентскую часть.
При отсутствии полноценной клиентской части ИС-ПРО 4 под Linux придется пойти на всякие ухищрения. Нужно лишь выбрать, какое из них приведет к желаемому результату.

Wine
Запустить Windows-клиента ИС-ПРО 4 из-под wine я пытался, но безуспешно. Виной тому используемые в системе ИС-ПРО драйверы VXD/SYS.
Кстати, такая же проблема и с сетевыми версиями Справочных правовых систем "Консультант Плюс", хотя локальная демонстрационная база "Законодательства Самарской области" запускается и довольно сносно работает.

DOS
При установке клиента ИС-ПРО 4 под Windows устанавливается и клиент под DOS. Внешне и функционально клиенты ИС-ПРО 4 под Windows и DOS практически не отдичаются. Значит DOS-клиента и будем ставить.

Установка.

Для запуска DOS-приложений под Linux мне известны два средства DosEmu и DosBox.

----------
Практика показала, что "напильник в шкаф не попал", блин... Проблема с клиентом Pervasive под DOS. Нужно каким-то хитрым образом поднять Winsock, иначе Pervasive отказывается устанавливать соединение. Поэтому DosBox отпадает, а как это сделать в DosEmu в руководстве описано очень скудно, что делать при возникновении кое-каких ошибок вообще ничего не написано. Так что я пока прекращаю эксперименты с клиентом ИС-Про.
Если кто знает, как поднять Winsock и/или заставить работать клиента Pervasive в DosEmu, напишите мне. Буду очень признателен.