Как стать автором
Обновить

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

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

По пунктам 1 и 2, либо удалите не нужную информацию для опытных администраторов линукса, либо удалите надпись что статья предназначается для них, а вместо нее поставьте предупреждение (раз вам так хочется кого-то о чем-то предупредить и придать напущенности статье), что статья подразумевает базовые знания *nix.
Уж лучше так, чем недосказанность в каких-либо местах. Автору респект за статью.
Ставил я 1С и на Debian, и на ALTLinux, и 32 и 64. Сама установка и запуск простые. Ставил два одновременно работающих (на разных портах, разумеется) 1С сервера на одну систему. Пока конфигурация стандартная, связка Linux+1C+PostgreSQL работает, но как только в неё начинают вносить изменения программисты, начинает падать в неожиданных местах, вплоть до падений при попытке РАСПЕЧАТАТЬ счёт на оплату (то есть формирует, отправляешь на печать, материшься/плачешь). Пришлось в итоге сказать клиенту, чтоб покупал Win + MSSQL. Заработало.
А может кто-нибудь рассказать, что содержат патчи 1С? Я вообще не понимаю с чего бы его патчить. Если он не работает с 1С-кой это ведь 1Ску патчить надо…
Там внесены изменения в режим блокировок.
Т.е. оно все-таки работает «как надо» (как в MSSQL)? Просто я слышал, что при программировании в 1С под постгресс лучше пользоваться управляемыми блокировками чтобы не блочились целые таблицы.
PostgreSQL — версионник, в нем используется иной механизм блокировок, не как в MSSQL. И конечно, при работе с постгрес нужно использовать управляемые блокировки иначе утоните в «конфликте блокировок».
1c имеет свою логику работы с данными в БД, и вот она не всегда просто и гладко ложится на классическую технологию, т.к. имеет в своем арсенале объектно-ориентированную составляющую.
Изначально платформа писалась под MSSQL, а уже потом появились вариации на тему Linux с postgres. Естественно пропатчить проприетарную СУБД весьма проблематично, поэтому они написали платформу с учетом требований MS SQL.
Но т.к. вроде и Postgres, и MS SQL — СУБД, но они все таки разные по внутренней архитектуре. И вот здесь и накладываются патчи, чтобы привести к общему знаменателю (среднему по больнице) СУБД.
ну я в принципе имею представление о том какие могут быть проблемы, хотелось узнать какие конкретно изменения вносят патчи 1С в постгрес
Я к сожалению не скажу, не смотрел) Только читать исходники.
Самое главное — это поддержка типа данных mchar (независимый от регистра тип данных, при сравнениях полей этого типа РеГистр символов не важен). Это делает PG похожим на MS SQL, в котором такие типы по умолчанию.
Действительно, сейчас просмотрел патч, почти все изменения сводятся к поддержке mchar и mvarchar, спасибо.
Фирма 1С даёт уже патченные исходники (это проще). И из них потом собрать RPMки под свою систему — получается легко и по довольно прозрачной методике.
А если вскоре выйдет новый релиз PostgreSQL — то методика будет работать, а RPM-ки устареют.
И потом: мне нельзя выкладывать RPMки — я же неофициальное и недоверенное лицо! А вдруг я накосячил при сборке? А вдруг я хакер и вставил backdoor? Правильные админы не возьмут неофициальные сборки для сервера…
Вот здесь можно скачать пакет PostgreSQL, с приложенными патчами 1С, собранные под все системы: wiki.etersoft.ru/PostgreSQL
Статья полезная, наверняка сэкономит кому-то много времени, хотя бы за счет того, что все собрано в одном месте. Но некоторые вещи не совсем верны.
Во первых для работы консоли администрирования и вообще 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 работает корректно.
Основное назначение Samba здесь — легко и просто резолвить в локальной сети символическое «имя компьютера» сервера в его IPшник, без применения и доп.настройки DNS сервера (и чтобы вообще не поднимать локального DNS). Это только для дополнительного удобства работы софта с клиентских компьютеров. Так они могут и обращаться к серверу через символическое имя, и не править себе hosts, и прописывать DNS какой-хотят…
А потом, если в дальнейшем понадобится и файлообмен между клиентами [и сервером] организовать — то вот она сетевая шара... (Ну, это конечно для маленьких решений: когда выделенный сервер один.)
Использовать самбу вместо DNS это конечно немного странно, но пожалуй оправданно в некоторых ситуация. Но главное что в статье написано:
Samba-сервер необходим для работы сервисов 1С, при явных и неявных использованиях протокола NetBIOS (что может быть и недокументировано, но нужно понимать, что 1С была всегда заточена под Windows). Например: MMC-оснастке «Администрирование серверов 1С: Предприятия» требуется аналог Cлужбы доступа к файлам и принтерам Windows – Samba. То есть Samba нужно обязательно настроить, иначе работать с этой оснасткой не удастся.

Это не совсем соответствует действительности, и вообще звучит «не научно».
Да, согласен! Это и «не научно», и не совсем соответствует действительности… Это есть шаманство, чтобы столь сложная распределённая система, портированная из Windows в Linux, заработала с чуть большей вероятностью! ;) Извините мне эту формулировку — я только хотел сказать пользователям, что Samba лучше поднять.
Саму фразу «Samba настроить нужно обязательно, иначе работать с этой оснасткой не удастся» — я почти дословно прицитировал из другой статьи... Но та статья для «1С: Предприятия 8.1» и уже подустарела…
И кстати, я признаю, что у вас опыта в 1С под Линукс — явно больше моего! Пусть ваш комментарий (что Samba не обязательна для сервера 1С) будет правильным дополнением к статье.
*дополнение: по профессии я — программист, аналитик и технический писатель. не сисадмин.
поэтому замечания профессиональных админов к статье будут очень кстати.
Совет.
Не делайте так 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
А я жаловался на арч, что у него сложная и не интуитивная установка… Да он просто бог простоты по сравнению с вашим «одноэс»
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну, во втором может еще и нету…
Скорее всего, вы пропустили какие-то пункты. В который раз пробую с нуля — не работает.

[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: Нет такого файла или каталога
Хм, я только что перепроверил…

Файл 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» — то должны быть правильные)
Если у вас всё-таки не получится пересобрать RPMки, то можете использовать мои пересобранные — я выложил здесь: PostgreSQL_от_1С_релиз_9.0.3-3.1C_от_17.01.12_-_RPMS_пересобранные_для_CentOS_6.3_32bit.rar.

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

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


Поменять 686 на 386
На самом деле, 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?
Создание ссылок одной командой:
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
Спасибо автору, статья очень помогла!
У меня только вопрос, кто может, помогите.

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

Публикации

Истории