Просмотр исходного текста страницы Сборка PostgreSQL для 1C на Gentoo

== Сборка PostgreSQL для 1C на Gentoo ==

Возникла необходимость поднять на Gentoo PostgreSQL-сервер для 1С-ки. Как всем известно одинэсовцы являются знаменитыми костылестроителями и в данном случае СУБД PostgreSQL не обошли стороной.

Почему Gentoo? Потому что данный дистр можно заточить именно для решения узко определенной задачи, со всеми преимуществами оптимизации USE-флагов, в отличие от бинарных дистров, где много вшито лишнего, а сборка собственных пакетов означает отказ от пакетных менеджеров (может и не так, не знаток этого вопроса), что сильно ухудшает поддержание инсталляции в актуальном состоянии. Ну и к тому же, на то он и гентушник раз любит сам готовить, а не использовать готовое.

Блуждания в интернете не принесли желаемого результата, а именно не нашлось ebuild-а, для такой задачи, хотя упоминания имеются, на неком ростовском сервере, то некто выкладывал на форуме (может плохо искал), то изобретали костыли с использованием rpm2cpio - над пропатченными сырцами, а то и вовсе редхатовскими бинарниками, но сим не есть gentoo-way, а хочется именно чтобы собрать из сырцов, без левых зависимостей, установить в каталоги стандартные для этой системы, а не какие-то /opt, и чтобы пакетный менеджер знал о нашей инсталляции и считал ее родной, с учетом make.conf и USE-флагов.

Имеется хороший ресурс ftp://ftp.etersoft.ru/pub/, оттуда берем патчи 1С-ки для PostgreSQL 8.4.4 - ftp://ftp.etersoft.ru/pub/Etersoft/Postgre@Etersoft/8.4.4/sources/postgresql-8.4eter-8.4.4-alt1.1.src.rpm, т.к. у самих 1С-цев на сайте патчи только для версии 8.4.1 (опять-таки может плохо искал, а может они и подходят для нашей версии). Кроме того, етерсофтцы опять таки патчат некоторые наработки одинэсевцев, исправляя их баги.

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

Итак, наш рецепт приготовления будет состоять в следующем:
* скачиваем сырцы и патчи на etersoft.ru
* готовим локальный оверлей
* наложение гентушных патчей на оригинальные исходники
* наложение етерсофтных патчей поверх гентушных
* снятие diff-а с гентушных сырцов PostgreSQL и патченного етерсофтом, в целях получения своего патча
* оформляем патч для кормления epatch'а
* оформляем наш ebuild
* ловля блох (багов) сборки
* тюнинг системы
* напутствия жаждущим

== Где мы находимся ==

В качестве версии СУБД будем использовать версию 8.4.4, хотя сейчас уже 1с-цы выложили патчи для 9-й версии, думаю не будет сложно и их адаптировать по аналогии.

Ранее установленная ОС Gentoo x86_64 на домашней машине [4G 1333, 1Tb] (самопальное ядро Linux localhost 2.6.36-gentoo-r5 #1 SMP Sun Dec 26 21:57:53 YEKT 2010 x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz GenuineIntel GNU/Linux и все что на нем крутится также собрано gentoo-способом), которая содержит очень много лишнего для боевого сервера узко-направленного значения, но это нам не помешает, а скорее будет проще не отвлекаться на шлифовку ядра, если таковое требуется, о чем мне не ведомо.

=== Что мы имеем ===

Для начала обновим порты, это уж кто как предпочитает, я делаю так:
 # eix-sync

Посмотрим что нам предлагают в портежах:
 eix postgresql-server
 [D] dev-db/postgresql-server
     Available versions:  
        (8.1)	8.1.21-r1 ~8.1.22
        (8.2)	8.2.17-r1 ~8.2.18
        (8.3)	8.3.11-r1 ~8.3.12
        (8.4)	8.4.4-r1!t ~8.4.5!t
        (9.0)	~9.0.0!t ~9.0.1!t

Как видно последняя размаскированная (а значит стабильная версия postgresql-а) - 8.4.4-r1, то что нам нужно.

== Качаем патчи ==
Как было сказано качаем исходники PostgreSQL вместе с патчами отсюда ftp://ftp.etersoft.ru/pub/Etersoft/Postgre@Etersoft/8.4.4/sources/postgresql-8.4eter-8.4.4-alt1.1.src.rpm. Открываем архив кому как угодно, я пользуюсь Gnome - у него имеется менеджер архивов и вытаскиваем оттуда следующие файлы:
* 1c_FULL_84-0.19.2.patch - оригинальный 1с-ский патч, добавляет три новых модуля fulleq, fasttrun, mchar и еще массу телодвижений
* 1cfix_etersoft.patch - данный патч фиксит 1с-ский патч
* applock-1c-8.4.1.patch - добавляет необходимоые типы блокировок
* eter-rename-libpq.patch - переименовывает библиотеку (единственное, что мне пришло в голову зачем это сделано, так это чтобы как то отметиться в системе, - вместо стандартного названия libpq, делает название libpq-8.4eter, мне это показалось саморекламой (есть ли нарушения GPL? или BSD, или какая лицензия у PostgreSQL и патчей?), поэтому данный патч не был использован, к тому же при сборке PostgreSQL все же хочет файл libpq, так что ребята недостарались)
* postgres_datalen.patch - что-то меняет для успешной инициализации кластера PostgreSQL (initdb)
* postgresql-1c-8.4.patch - рихтует Makefile для сборки модулей написанных 1с-цами - fulleq, fasttrun, mchar, плюс рихтует конфиг для PostgreSQL
* postgresql.conf.sample.patch - как видно из названия, также рихтует конфиг (честно говоря не понимаю для чего это сделано, ребята полагают, что PostgreSQL будут ставить полные нули которые не осилят чтения документации а-ля MSSQL)
* postgresql-no_transaction_blocks.patch - этот и следующие два патча, по мелочам вносят правки
* postgresql-perl-rpath.patch
* postgresql-tmp_table_cleanup.patch
* rpm-pgsql.patch - опять самопиар для сборки RPM-пакета, также не понял зачем менять стандартную директорию размещения БД-х PostgreSQL с /var/lib/postgresql, на /var/lib/pgsql
* timestamp.c.diff - корректировки насчет пустого поля времени - по аналогии с MSSQL, устанавливает в качестве даты значение 1900-01-01 по умолчанию для полей даты таблицы - могу ошибаться, но где-то встречал такое описание (как ни странно, но это отражено в самом патче).

Сохраним патчи сюда
 mkdir -p /tmp/postgresql/patches

== Локальный оверлей ==

Для интеграции в существующее дерево портежей плодов наших манипуляций сделаем локальный оверлей (почитать можно здесь http://ru.gentoo-wiki.com/wiki/Portage_Overlay):
 echo 'PORTDIR_OVERLAY="/usr/local/portage"' >> /etc/make.conf
 install -d /usr/local/portage
У кого будут ругания на оверлей, почитать man make.conf и гугл - у меня не было косяков, но может быть конфликт с другими параметрами в нем, на предмет очередности их объявления.

По аналогии с родной структурой дерева портежей создаем структуру директорий для локального:
 mkdir -p /usr/local/portage/dev-db/postgresql-server
Копируем исходный ebuild, который будем патчить:
 cp /usr/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r1.ebuild \
 /usr/local/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild
Стоит обратить внимание что исходный ebuild имеет версию обновления r1, нам нужно чтобы не совпадало с ней, поэтому свой ebuild называем r3 (r2 появился у меня после очередного eix-sync), - надо выбирать именование так чтобы не пересекалось с имеющимися ebuild'ами, возможно можно как-то еще, но по правилам именования нужно соблюдать определенные требования.

Также при сборке PostgreSQL понадобятся патчи подготовленные командой Gentoo, вероятно как-то можно использовать их из системного дерева портежей, но пока не знаю как, так что делаем:
 cp -R /usr/portage/dev-db/postgresql-server/files \
 /usr/local/portage/dev-db/postgresql-server
Хотя реально оттуда требуется всего лишь два файла:
 * /usr/portage/dev-db/postgresql-server/files/postgresql-8.4-common.patch
 * /usr/portage/dev-db/postgresql-server/files/postgresql-8.4-server.patch

== Приготовление исходников ==
Использовать исходники PostgreSQL не будем от команды etersoft'а (как-то в душу запали только их патчи, не дай .. они еще и сырцы трогали, про сравнение хэш-сумм знаю - не заморачивался), а возьмем те что тянет emerge из интернета для оригинального PostgreSQL.

Загружаем исходники:
 emerge -fv dev-db/postgresql-server

Сделаем рабочую директорию и распакуем туда сырцы:
 mkdir -p /tmp/postgresql/orig && cd /tmp/postgresql/orig && \
 tar xjf /usr/portage/distfiles/postgresql-8.4.4-tar.bz2 
Идем туда и накладываем гентушные патчи:
 cd /tmp/postgresql/orig/postgresql-8.4.4
 patch -p0 -g0 -E < /usr/local/portage/dev-db/postgresql-server/files/postgresql-8.4-common.patch
 patch -p1 -g0 -E < /usr/local/portage/dev-db/postgresql-server/files/postgresql-8.4-server.patch
С ключами у них для одного патча применяем -p0 для другого -p1, по-крайней мере у меня так получилось. Хотя можно применять просто команду: patch -pX < <patch-name>, но анализ лог-файлов показал, что epatch использует такую хитрую комбинацию ключей. Теперь считаем что у нас получились эталонные исходники, на которые будет ebuild накладывать патчи для 1с-ки.

Подготовим площадку для дальнейших экзекуций:
 mkdir -p /tmp/postgresql/patch
 cp -R /tmp/postgresql/orig/postgresql-8.4.4 /tmp/postgresql/patch

Теперь нужно внимательно изучить файл postgresql-8.4eter.spec, поставляемый в postgresql-8.4eter-8.4.4-alt1.1.src.rpm, чтобы определить в каком порядке накладываются патчи, вообщем имеется такая секция описывающая порядок и уровень -pX, с которым они применяются:
 # Patch1: rpm-pgsql.patch
 %patch1 -p2
 # Patch4: postgresql-test.patch
 # now test is by C program.
 # %patch4 -p1
 # Patch6: postgresql-perl-rpath.patch
 %patch6 -p2
 # Patch7: 1c_FULL_83-0.19.patch
 %patch7 -p2
 # Patch8: postgresql-1c-8.4.patch
 %patch8 -p2
 # Patch9: applock-1c-8.3.1.patch
 %patch9 -p0
 # Patch10: timestamp.c.diff
 %patch10 -p2
 # Patch11: postgresql.conf.sample.patch
 %patch11 -p2
 # Patch12: pg_hba.conf.sample.patch
 # already included in postgresql-1c-8.3.patch
 # %patch12 -p1
 # Patch13: postgres_datalen.patch
 %patch13 -p2
 # Etersoft's fix for 1c patches
 # Patch15: 1cfix_etersoft.patch
 %patch15 -p2
 # Etersoft rename libpq
 %patch50 -p2
 #Patch51: postgresql-tmp_table_cleanup.patch
 %patch51 -p1
 #Patch52: postgres-no_transaction_blocks.patch
 %patch52 -p2

=== А как же в Gentoo? ===
Последив как работает команда ebuild при сборке пакетов (немного есть здесь http://www.gentoo.org/doc/ru/handbook/handbook-x86.xml?part=3&chap=6), выяснил что выполняются по шагам следующие действия:
* ebuild /path/to/ebuild unpack
* ebuild /path/to/ebuild prepare
* ebuild /path/to/ebuild compile
* ebuild /path/to/ebuild install
* ebuild /path/to/ebuild clean

Распаковка исходников производится в каталог: /var/tmp/portage/dev-db/postgresql-server/work/postgresql-8.4.4 и он делается текущим, затем при выполнении команды prepare, накладываются патчи и выполняется ./configure, т.е. команда patch вызывается с уровнем -p0 (хотя и это меняется редактированием ebuild-файла), вот это и нужно поправить в патчах. Вообщем как удалось расковырять патчи ложатся в следующем порядке, хотя для некоторых файлов он не важен (не спешим патчевать, а читаем дальше):
 cd /tmp/patch/postgresql
 # сделаем симлинк
 ln -s postgresql-8.4.4 postgresql
 patch -p2 < postgreslq-perl-rpath.patch
 patch -p2 < 1c_FULL_83-0.19.patch
 patch -p0 < applock-1c-8.3.1.patch
 patch -p2 < timestamp.c.diff
 patch -p2 < postgresql.conf.sample.patch
 patch -p2 < postgres_datalen.patch
 patch -p2 < 1cfix_etersoft.patch
 patch -p1 < postgresql-tmp_table_cleanup.patch
 patch -p2 < postgres-no_transaction_blocks.patch

Как видно, были пропущены файлы prm-pgsql.patch и eter-rename-libpq.patch по причине описанной ранее. Также patch споткнется на файле postgresql-1c-8.4.patch, - он выполняет редактирование файла postgresql/contrib/Makefile, на предмет добавления в собираемые модули fulleq, mchar и fasttrun - т.к. гентушные патчи тоже наводят там небольшой порядок, то возникает конфликт. Поэтому данный патч можно не применять, а дописать модули вручную (тру-гении смогут и патч отрихтовать). Также этот патч по мелочи шлифует pg_hba.conf.sample и postgresql.conf.sample, т.е. конфигурационные файлы, на попсовые настройки - никто же не собирается использовать дефолтные поэтому можно смело забить. И чтобы было все как с остальными, то содержимое файла postgresql-1c-8.4.patch можно заменить на:
 --- ../contrib/Makefile	2011-01-06 15:30:50.670856014 +0500
 +++ ../contrib/Makefile	2011-01-06 16:00:39.664856014 +0500
 @@ -36,7 +36,10 @@
  		spi		\
  		tablefunc	\
  		tsearch2	\
 -		test_parser
 +		test_parser	\
 +		fasttrun	\
 +		fulleq		\
 +		mchar
 
 ifeq ($(with_openssl),yes)
 WANTED_DIRS += sslinfo


Также файл applock-1c-8.4.1.patch в голом виде так и не смогла переварить команда patch. Исследование содержимого файла показало, что пути к файлам, предназначенные для изменений начинаются следующим образом, например первая строка того же файла содержит:
 diff -c -r -N ..\postgresql-8.4.0/doc/src/sgml/ref/lock.sgml ./doc/src/sgml/ref/lock.sgml 
где видно, что путь к файлу начинается с обратного слэша '''..\''', есть предположение что данный патч писался под оффтоповой осью, однако дальнейшие слэши все же правильные, к тому же тут указывается версия PostgreSQL 8.4.0, что есть не страшно, я делал так:
 cd /tmp/postgresql/patches
 cat applock-1c-8.4.1.patch | sed 's!\.\.\/postgresql\-8\.4\.0!\.\./postgresql\-8\.4\.0!' > \
 applock-1c-8.4.1.patch-fix && mv applock-1c-8.4.1.patch-fix applock-1c-8.4.1.patch

И делаем симлинки:
 cd /tmp/postgresql/patch
 ln -s postgresql-8.4.4 postgresql-8.4.0
После манипуляций с патчами можно еще раз прогнать "патчевание" (а лучше все сначала, предварительно сделав rm -rf /tmp/postgresql/patch/postgresql-8.4.4 && cp -R /tmp/postgresql/orig/postgresql-8.4.4 /tmp/postgresql/patch/), т.к у меня все патчи наложились далеко не с первого раза, то процедуру патчевания лучше записать в bash-скриптик.

В итоге в директории /tmp/postgresql/ имеем следующую структуру:
 /tmp/postgresql/
 |
 +- orig (оригинальный PostgreSQL + Gentoo-патчи)
 |  |
 |  +- postgresql-8.4.4
 |
 +- patch (копия orig/postgresql-8.4.4 + патчи 1С/etersoft)
 |  |
 |  +- postgresql
 |  +- postgresql-8.4.0
 |  +- postgresql-8.4.4
 |
 +- patches
    |
    +- список файлов-патчей

=== Наложение патчей от 1c/etersoft ===
Собственно процедура наложения выглядит таким образом (после всех манипуляций, исправлений и рихтований):

 cd /tmp/postgresql/patch/postgres
 patch -p2 ../../patches/postgreslq-perl-rpath.patch
 patch -p2 ../../patches/1c_FULL_83-0.19.patch
 patch -p2 ../../applock-1c-8.3.1.patch
 patch -p2 ../../timestamp.c.diff
 patch -p0 ../../postgresql-1c-8.4.patch
 # Данный патч немного глюкавит, но как очевидно, 
 # он делает то что будет переделано - тюнинг конфиг-файла
 # patch -p2 ../../postgresql.conf.sample.patch
 patch -p2 ../../postgres_datalen.patch
 patch -p2 ../../1cfix_etersoft.patch
 patch -p1 ../../postgresql-tmp_table_cleanup.patch
 patch -p2 ../../postgres-no_transaction_blocks.patch

== Получение итогового патча ==
Возня с исходниками практически закончена, осталось только сделать свой патч и прописать все это дело в ebuild-файле:
 cd /tmp/postgresql/patch/
 ln -s /tmp/postgresql/orig/postgresql-8.4.4 postgresql-8.4.4.orig
 # Это наш патч, который можно отослать другу-гентушнику
 diff -urdN ../postgresql-8.4.4.orig ../postgresql-8.4.4 > ../postgresql-8.4-1c8all.patch
 # Копируем в папку к остальным патчам
 cp /tmp/portage/patch/postgresql-8.4-1c8all.patch /usr/local/dev-db/postgresql-server/files

Свой патч мы делаем, чтобы получить разницу между исходным деревом PostgreSQL и патченным, чтобы эта разница уместилась в одном файле - так менее геморно будет с ebuild-ом возиться.

== Шлифуем ebuild-файл ==
Открываем в любимом редакторе ранее сделанную копию ebuild-файла:
 mcedit /usr/local/portage/dev-db/postgresql-server/postgresql-server-8.4.4-r3.ebuild
и вносим правки.

В строке 3 можно поменять (не уверен, что не нужно, хотя и работает без правки): 
 # $Header: /var/cvsroot/gentoo-x86/dev-db/postgresql-server/postgresql-server-8.4.4-'''r3'''.ebuild,v 1.6 2010/08/11 19:27:10 josejx Exp $
- ревизию ebuld-файла

Далее в строке можно поменять 
 DESCRIPTION="PostgreSQL server with patchset from 1C company. I'm was hack the Internet"

Менять обязательно:
 IUSE="'''1c8''' pg_legacytimestamp doc perl python selinux tcl uuid xml nls kernel_linux ${IUSE_LINGUAS}"
- добавили ключик "1c8"

Ищем функцию '''src_prepare()''' и после слов epatch ...-common.patch ...-server.patch пишем свое:
 if use 1c8; then
         epatch "${FILESDIR}/postgresql-${SLOT}-1c8all.patch"
 fi

== Создание цифровой подписи для ebuild-файла ==
 cd /usr/local/portage/dev-db/postgresql-server
 ebuild postgresql-server-8.4.4-r3.ebuild digest
 # Если все в порядке, то получим, если нет - то читаем вывод и в маны и гугл
 >>> Creating Manifest for /usr/local/portage/dev-db/postgresql-server

= Подготовка системы к установке =
Предварительно сделаем небольшой тюнинг системы:
 # Архитектура нашего ПК (в данный момент уже является стабильным для x86 и amd64) поэтому можно и не делать
 echo '=dev-db/postgresql-server-8.4.4-r3 amd64' >> /etc/portage/package.keywords
 # Маскируем версии старше нашей, чтобы по-умолчанию ставилась наша 
 echo '>dev-db/postgresql-server-8.4.4-r3' >> /etc/portage/package.mask
 # Указываем USE-флаг ради которого все затевалось
 echo '=dev-db/postgresql-server-8.4.4-r3 1c8' >> /etc/portage/package.use

= Установка PostgreSQL с патчами от 1C - gentoo-way =
Посмотрим, что нам скажет emerge:
 emerge -pv postgresql-server
 [ebuild   R   ] dev-db/postgresql-server-8.4.4-r3  USE="'''1c8''' nls perl python -doc -pg_legacytimestamp \
 (-selinux) -tcl -uuid -xml" LINGUAS="ru -af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -sk -sl \ 
 -sv -tr -zh_CN -zh_TW" 0 kB [?=>1]
 
 Total: 1 package (1 reinstall), Size of downloads: 0 kB
 Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage
 [?] indicates that the source repository could not be determined
Как видим система по-умолчанию выбирает нашу сборку (когда 9 версия будет размаскированной, что-то придется поменять в /etc/portage). Emerge увидел два дерева портежей - системный и наш локальный, среди флагов USE появился флаг 1c8.

Для 1с-сборки PostgreSQL, помимо самого флага 1с8, флаги tcl, perl, python, selinux не являются обязательными, т.к. вроде бы являются биндингами к соответсвующим ЯП, насчет остальных не уверен.

А теперь ставим:
 emerge -av postgresql-server

Если внимательно посмотреть, то заметим, что после распаковки исходников, происходит наложение патчей по порядку:
 postgresql-8.4-common.patch
 postgresql-8.4-server.patch
 postgresql-8.4-1c8all.patch
А после того как СУБД будет установлена в директорию (можно увидеть при работе процедуры копирования файлов при установке) /usr/lib64/postgresql-8.4/lib64 помимо идущих в комплекте файлов модулей, будут лежать 1с-ские модули: '''fasttrun.so''', '''fulleq.so''' и '''mchar.so'''.

Почистим /tmp, больше не пригодится
 rm -rf /tmp/postgresql
и небольшой лоск (т.к. делал от рута)
 chown portage:portage -R /usr/local/dev-db

= Послеустановочный тюнинг =
В интернете много сообщений на тему руганья 1с-ки: ERROR: Invalid value for parameter "lc_messages":"en_US". Для Gentoo смотрим:
 cat /etc/locale.gen | grep -v "#"
 en_US.UTF-8 UTF-8
 ru_RU.UTF-8 UTF-8
По рекомендации из того же файла проверяем файл /usr/share/i18n/SUPPORTED | grep "en_US"
 en_US.UTF-8 UTF-8
 en_US ISO-8859-1
и добавляем локаль:
 echo 'en_US.ISO-8859-1' >> /etc/locale.gen
и обновляем систему:
 locale-gen 
 env-update && source /etc/profile
Скорее всего это не совсем поможет, - читаем дальше.
== Файл /etc/conf.d/postgresql-8.4 ==
Смотрим файл на предмет переменных, кластер баз данных по-умолчанию находится по адресу PGDATA, можно поменять как угодно, у меня было так:
 PGDATA=/var/lib/postgresql/8.4
поменял на 
 PGDATA=/var/lib/postgresql

Установим:
 PG_INITDB_OPTS="--local=ru_RU.UTF-8"
 # Это чтобы PostgreSQL начал слушать на всех адресах, можно указать конкретный
 PGOPTS="-h 0.0.0.0"
 PG_EXTRA_ENV="LC_ALL=\"ru_RU.UTF-8\""

Но и в таком случае тема "lc_messages" может себя не исчерпать, то делаем вмешательство в скрипт запуска/останова - где-нибудь в начале файла, перед описанием функций, добавляем:
 export LC_ALL=ru_RU.UTF-8

= На старт... =
Если внимательно смотреть лог установка СУБД, то там при окончании процедуры установки говорится, что прежде чем запускать кластер нужно его инициализировать:
 emerge --config =dev-db/postgresql-8.4.4-r3
А затем запускаем:
 /etc/init.d/postgresql-8.4 start
Для разрешения авторизации на сервере с других компьютеров сети, покорректируем файл /var/lib/postgresql/data/pg_hba.conf, добавив строку
 host all all <сетка>/<маска> trust
 host all all <сетка>/<маска> md5
 # хотя можно просто 0.0.0.0/0
не забыв после этого выполнить перезапуск: /etc/init.d/postgresql-8.4 restart

== Отладка и запуск ==
Ну и напоследок классика жанра - проверить, что PostgreSQL действительно запускается и работает:
 netstat -na | grep 5432
 ps ax | grep postgres
 tail /var/log/messages
 tail /var/lib/postgresql/data/postmaster.log

== Авторизация на сервере ==
От рута
 su postgres
 psql template1
 psql# ALTER USER postgres WITH PASSWORD 'newpassword';

Теперь можно из 1с-ки цепляться к серверу указав имя пользователя '''postgres''' и пароль '''newpassword''', а также почитать на тему разграничения прав доступа.

= Размышления =
* Насчет прав доступа к файлам прошу не обращать внимания, полагаю что Linux-пользователи понимают разницу в уровне доступа для /tmp и /usr, так что где нужно, естественно производится переключение на root (su, sudo, etc).
* Сами 1с-цы обязуют к использования библиотеку ICU (http://icu.sourceforge.net), хотя она у меня была установлена ранее (eix dev-libs/icu), но беглый просмотр исходников показал, что данная библиотека используется для Windows-сборки PostgreSQL, но вроде бы в модуле mchar (sources/contrib/mchar) в описании Makefile также встречается ее упоминание. Раскопал: 
 ldd /usr/lib64/postgresql-8.4/lib64/mchar.so 
        linux-vdso.so.1 =>  (0x00007fff105ff000)
        libicuuc.so.44 => /usr/lib/libicuuc.so.44 (0x00007f452ea67000)
        libicui18n.so.44 => /usr/lib/libicui18n.so.44 (0x00007f452e693000)
        libc.so.6 => /lib/libc.so.6 (0x00007f452e337000)
        libicudata.so.44 => /usr/lib/libicudata.so.44 (0x00007f452d2f7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f452d0da000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f452ced6000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6 (0x00007f452cbcb000)
        libm.so.6 => /lib/libm.so.6 (0x00007f452c947000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f452c730000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f452efed000
Так что будут у кого руганья при сборке, то сначала поступить так: emerge -av dev-libs/libicu, хотя может по зависимостям и вытащит (но в ebuilde ничего такого не нашел и, скорее всего надо будет руками добавлять).

* В [http://habrahabr.ru/blogs/linux/107321/ статье] автор описывает ручную установку функции datediff в кластере, а также еще чего из SQL-диалекта, однако при загрузке ранее сделанного дампа БД из ранее установленной PostgreSQL (установка на Debian из готовых deb-пакетов), функции уже имелись в наличии, правда они были только для конкретной базы, а не всего кластера (опять же могу ошибаться, хотя в Makefile модулей contrib есть упоминания про sql-файлы, которые возможно заливаются в кластер при его инсталляции, даже если и так, то думаю не составить труда выдернуть SQL-дампы этих функций и записать их в шаблон). 

 postgres@localhost echo "\df" | psql testbase1
 выдает кучу функций среди них и datediff и еще пара десятков, судя по названию которых и есть необходимый набор.

* Данная статья не означает что рассмотренный способ еть Gentoo-way, однако приближение все-таки ощущается.
* Для других версий СУБД и дистрибутивов работа с патчами будет выглядеть аналогичным образом.
* Не являюсь гуру Gentoo в частности и *nix-ов в целом, поэтому не исключено что уже имеются где-то оверлеи в которых уже все отлажено и готово к употреблению, а также существуют более красивые решения.
* В данном случае поставленная цель достигнута, сервер БД установлен и инсталляция отражена в пакетном менеджере, так что какие-либо инструменты устанавливаемые в дальнейшем будут "знать" и работать с данной версией.
* Если использовать USE="-1c8", то будет устанавливаться оригинальная версия с гентушными наработками без патчей от 1с.
* Сам ни в коем случае не являюсь 1с-ником, то мои познания в этой области заканчиваются инсталляцией и демонстрацией запуска 1с-ки. Так что если есть какие баги, то я о них пока не знаю.
* Моя первая статья, надеюсь кому поможет.

= Ресурсы =
* man ebuild
* man make.conf
* man patch
* man diff
*[http://postgresql.org СУБД PostgreSQL]
*[http://www.v8.1c.ru/overview/postgres_patches_notes.htm Патчи компании 1С для СУБД PostgreSQL]
*[ftp://ftp.etersoft.ru/pub/ FTP-сервер компании Etersoft]
= Другие рецепты инсталляций =
* [http://www.lissyara.su/archive/1c_8.2+postgresql/ Ubuntu]
* [http://life.screenshots.ru/the-code-inside/php-platform/linux-1c-setup/ RPM дистрибутивы]
* [http://habrahabr.ru/blogs/linux/107321/ Статья на хабре]
* И еще масса вариаций рассказывающих "как я с другом ставил..." - вносящие корректировки в уже обкатанные рецепты.

= Файлы =
В архиве прилагается готовый ebuild и результирующий патч [[Медиа:Gentoo-postgresql-1c8.zip]].