Как работает компилятор gcc/g++

Не могу не поделиться ссылкой на роскошнейшую статью: О GCC, компиляции и библиотеках
Досконально разобраны все четыре этапа, написано как их прерывать и как продолжать с прерванной точки. И отличное продолжение этой статье GCC and Make

Fatal: no entropy gathering module detected

Подобное сообщение появляется в том случае, если команда, запущенная из chroot'а требует генерации случайных чисел. Например svn checkout https://

Эта проблема достаточно хорошо освящена на просторах интернетов... людьми, которые не понимают, что говорят.

Итак, стандартное решение для нее - убедиться, что в системе есть эти девайсы. Если нет, то создать:

mknod -m 666 /dev/random c 1 8 
mknod -m 666 /dev/urandom c 1 9

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

mknod -m 666 /chroot/path/dev/random c 1 8
mknod -m 666 /chroot/path/dev/urandom c 1 9

или пробросить (команда для Jailkit):

jk_cp -v -j /chroot/path /dev/random
jk_cp -v -j /chroot/path /dev/urandom

Все три варианта - бред. Потому что в случае отсутствия этих устройств или неправильных прав на них, ошибка была бы другой.

Так о чем нам говорит именно эта ошибка?
Тут надо разобраться как работают эти две команды. Они залазят в буфер шумов от драйверов устройств и берут оттуда данные, из которых и составляются рандомные цифры. Стоп! Каких устройств? Мы же в чруте :)
Правильный вопрос - 50% ответа. Решение приходит само собой:

mount -o bind /dev /chroot/path/dev

UPD: как правильно заметил мой товарищ Павел, это резко понижает безопасность сервера, выкладывая диски в chroot. Так что нужно взвешивать такое решение.

Установка почтового сервера Exim4 и Dovecot и проксирование IMAP через Nginx

Отличная подборка информации: Exim 4.70 (lissyara)

Сначала капельку терминологии:

MTA - mail transfer agent. Это сервис, который передает почту между серверами, используя протокол SMTP. (эту задачу будет выполнять Exim4).

MSA - mail submission agent. Этот сервис используется для отправки почты пользователем с сервера наружу. Именно он получает запрос на обработку исходящего письма от нашего пользователя по протоколу SMTP на портах 25 или 587 и передает ее MTA для дальнейшей транспортировки. То есть это сервис для исходящей почты. (эту задачу будет выполнять Exim4).

MDA - mail delivery agent. Это сервис, который раскладывает почту по папкам, после того как MTA принял какую-то почту извне сервера для нашего пользователя. То есть это сервис для входящей почты. (эту задачу будет выполнять Exim4).

MRA - mail retrieval agent. Это сервис, который достает почту из папок для клиента, пришедшего по протоколам POP/IMAP. (эту задачу будет выполнять Dovecot).

MUA - mail user agent. Это программа, предоставляющая человеческий интерфейс для обращения к MRA по протоколу POP/IMAP. Она может быть исполнена как вэб-приложение на том же сервере (RoundCube, Squirrel, Horde, etc.) так и быть десктопным приложением (Outlook, Thunderbird, The Bat). В любом случае это приложение подключается к MRA на порт 110/143 и работает по протоколу POP/IMAP. (эту задачу будет выполнять десктопный клиент на стороне пользователя).


Цепочка отправки письма выглядит так:
MUA(Outlook, отсылка, ivanov@abc.com)-->MSA-->MTA(abc.com)-->
>-----интернет----->
-->MTA(xyz.com)-->MDA-->MRA-->MUA(Outlook, прием, petrov@xyz.com)

Любой из вышеперечисленных сервисов может работать не только по обычным протоколам, но и по шифрованным. Такие протоколы обозначаются буквами S в конце. Например IMAPS. Номера портов соответственно тоже меняются.

Итак приступим...

Как вытащить на свой терминал чужой процесс

Все очень просто:

apt-get install reptyr

Если процесс случайно оказался отдетаченным от PTY (например сеть отлетела), то так:
Смотрим PID своего процесса:

ps auxf 

И подключаемчя к нему:

reptyr PID-процесса

Но если надо рестартануть сервер, а процесс висит в данный момент и его жалко прекращать, то сначала надо его отцепить от сессии, а то он завершится, а не уйдет в бэкграунд:
Убираем его в jobs:

Ctrl+Z

Запускаем в бэкграунде:

bg

Делаем его сиротой:

disown

Отцепляемся. Прицепляемся потом с нового терминала и забираем его обратно через reptyr.

Сборка пакета PAM-SQLite и NSS-SQLite

Как многим известно, аутентификация в Linux проходит централизованно в PAM. Стандартно PAM использует файлы /etc/passwd (и еще несколько: shadow, group,  и т.д.). В крупных компаниях предпочитают держать пользователей не в файлах, а в LDAP. Но если Вы пишете свое приложение, то наверняка хотите хранить пользователей в базе. Для MySQL и PostgreSQL в репозиториях Debian есть стандартные пакеты libpam-mysql и libpam-pgsql. Но что делать, если пользователи живут в SQlite? Об этом ниже, а пока небольшая вводная, важная к прочтению:

Подразумевается, что читатель знает разницу между аутентификацией и авторизацией.

Процесс происходит примерно так (рассмотрим на примере SSH). Демон SSH принимает соединение с логином и паролем.
Теперь перед SSH-демоном две задачи:
1) Identity. Установить, что пользователь вообще существует.
(это делается на первом слое: NSS)
2) Authnetication. Проверить его пароль.
(это делается на втором слое: PAM, если конечно в /etc/ssh/sshd_config стоит настройка "UsePAM yes" ).

Далее, через систему NSS он смотрит настройки. Находятся они в файле /etc/nsswitch.conf. По дефолту там стоит так:

passwd:         compat

group:           compat

shadow:        compat

compat - значит локальные файл (/etc/passwd,/etc/shadow,/etc/group)
Можно добавить своё, например:

passwd:         compat   ldap   sqlite

group:           compat   ldap   sqlite

shadow:        compat   ldap   sqlite

В таком случае система сначала будет искать пользователя в файлах, если нет, то в LDAP и наконец в SQLite.

Поэтому кроме пакета libpam-sqlite вам понадобится еще пакет libnss-sqlite, чтобы NSS вообще понимал такую инструкцию как "sqlite".

====
Теперь разберемся откуда брать код.
Поиск кода обоих приложений (libnss-sqlite и libpam-sqlite) приводит на аккаунт github Sectoid. Но ведет его достаточно вяло. libpam-sqlite остановился на версии 0.3. Эта версия поддерживает SQLite2, а вот SQLite3 - нет.
Версию 0.3 уже, в свою очередь форкнул ip1981 и добавил в неё поддержку SQLite3, назвав ее версией 0.4.
Но я внезапно нашел вот уже версию 1.0.1 (с поддержкой SQLite3).



Нам понадобятся пакеты:

apt-get install libpam0g-dev libmhash-dev libsqlite0-dev

И инструменты сборки:

apt-get install dh-make dpatch devscripts autoconf  shtool libtool

Переходим в директорию, где будем работать:

cd /usr/src

Скачиваем исходники с сайта:

git clone https://github.com/dtjm/pam_sqlite3.git libpam-sqlite-1.0.1

Логин в RHEL/CentOS/OEL под рутом с RSA-ключом

RHEL-like операционные системы, в отличии от Debian, очень сильно защищены. Сразу после инсталляции Вы получите полный набор заборов в виде SElinux, iptables и прочих. Привыкшему человеку это нормально (оно как бы даже спокойнее), а вот новичка такое состояние приведет к эйфории эфтаназии.
Особо "грамотные" советуют выключить все это. Но я бы им по губам бил за такие советы. Умные дяденьки не для того нас оберегали от безопасности, чтобы мы ей пренебрегали. Подобные вопросы надо решать только по-спортивному.

Одна из таких засад: невозможность залогиниться под рутом с ключом.

Причин две.
1) В RHEL-вском SSH по умолчанию стоит StrictModes yes. Это значит, что мы должны создавать директории и файлы SSH с нормальными правами, а не как рубахи-парни.

mkdir /root/.ssh
chmod 700 /root/.ssh

и

touch /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

2) Но и после этого законнектиться ключем будет невозможно. В этот раз вредит SElinux.
Чинится так:

restorecon -R -v /root/.ssh

Сборка eAccelerator под Debian

Для начала установим необходимые пакеты для сборки PHP и вообще сборки пакетов:

apt-get install php5-dev dh-make autotools-dev gcc-4.3 debhelper devscripts

Так же нужно учесть одну особенность eAccelerator - он будет работать только с той версией PHP, с которой был собран. Если у Вас на тестовом сервере одна версия PHP, например 5.3.3-7+squeeze3,  а на продакшене 5.3.3-7+squeeze8, то eAccelerator не заведется и будет выкидывать такую ошибку:

[eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.3.3-7+squeeze3. Rebuild it for your PHP version (5.3.3-7+squeeze8) or download precompiled binaries.

Чтобы этого избежать, нам надо подтянуть версию на тестовой машине до сервера, где будет использоваться eAccelerator:

apt-get install php5=5.3.3-7+squeeze8 php5-dev=5.3.3-7+squeeze8

Переходим в директорию, где будем работать:

cd /usr/src

Скачиваем туда тарбол с исходниками.

Распаковываем его:

unzip eaccelerator-0.9.6.1.zip

Так как все расширения PHP принято обзывать php5-extention (например php5-tidy, php5-memcached, php5-mysql и т.д.), а имя/версия пакета будет создано на основе имени директории, то переименуем директорию:

mv eaccelerator-0.9.6.1 php5-eaccelerator-0.9.6.1

Заходим в распакованную директорию:

cd php5-eaccelerator-0.9.6.1

Открываем конфиг и настраиваем под себя. Я, например, люблю когда кэш лежит там где он должен лежать по FHS - в /var/cache, а не в /tmp. А еще нужно поправить путь к логу, потому что у нас Debian, а там CentOS-вский путь:

vi eaccelerator.ini

Далее нужно PHP-зировать пакет - подогнать под API PHP:

phpize

И теперь уже можно его конфигурировать:

./configure --with-eaccelerator-debug

Аутентификация SSH через LDAP public key

До того, как начать, нужно обязательно научить SSH работать с LDAP.  Без этого дальше можно не читать.


Первым делом мы должны определиться какую версию OpenSSH мы будем переделывать. Дело в том, что патчи есть не под все версии. Поэтому будем отталкиваться от тех, которые есть. Переходим на страничку патчей и ищем те, которые совпадают с номерами версий, выпущенных с релизами Debian.
Чтобы узнать какие версии шли с Debian, нужно зайти сюда и прощелкать справа сверху все версии.

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

Например. Мы видим, что есть патчи под 5.1, 5.3, 5.4. А у нас Squeeze, с которым идет 5.5. Значит смотрим Lenny - там шла 5.1. А на эту версию у нас патч как раз есть. Добавляем репозиторий Lenny:

vi /etc/apt/sources.list

## Debian Lenny base:
deb http://archive.debian.org/debian/ lenny main non-free contrib
deb-src http://archive.debian.org/debian/ lenny main non-free contrib

Обновляем:

apt-get update

Перейдем в директорию работы с исходным кодом:

cd /usr/src/

Смотрим какие версии нам стали доступны после подключения репозитория от Lenny:

apt-cache show openssh-server | grep Version

Скачаем исходники OpenSSH нужной нам 5.1-версии:

apt-get source openssh-server=1:5.1p1-5

И затем зайдем туда:

cd openssh-5.*p1

Где достать репозитории Debian Lenny

С тех пор, как Lenny перешел в состояние устаревшего, все его репозитории переместили в archive*

## Debian Lenny base:
deb http://archive.debian.org/debian/ lenny main non-free contrib
deb-src http://archive.debian.org/debian/ lenny main non-free contrib

## Debian Lenny updates:
deb http://archive.debian.org/debian/ lenny-updates main non-free contrib
deb-src http://archive.debian.org/debian/ lenny-updates main non-free contrib

## Debian Lenny Security updates:
deb http://archive.debian.org/debian-security/ lenny/updates main contrib non-free
deb-src http://archive.debian.org/debian-security/ lenny/updates main contrib non-free

## Debian Volatile updates:
deb http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free
deb-src http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free

## Debian Lenny Backports
deb http://archive.debian.org/debian-backports lenny-backports main contrib non-free
deb-src http://archive.debian.org/debian-backports lenny-backports main contrib non-free

Сборка PHP в Debian в альтернативную директорию

На просторах Интернета имеется достаточно большое количествео разнообразных мануалов на тему сборки PHP. К сожалению, всех их объединяет одно: все они делаются через make install (читайте: через интимное место). О причинах распыляться не буду, порекомендую лишь статью на Хабре с многоговорящим названием: Хочется взять и расстрелять, или ликбез о том, почему не стоит использовать make install.

В данном мануале я не ограничусь только сборкой одного пакета.Мы соберем все популярные версии и {в}рапперы для него.

Все, что собирается - собирается на Debian Squeeze для FastCGI. Шаг влево/шаг вправо и мануал уже не подходит. Например на Lenny даже близко не так все будет. Я очень рекомендую установить чистенькую свежую систему, чтобы не спотыкаться об пакеты из неродных репозиториев и их разломанными зависимостями.


Начнем с того, что поставим зависимости, которые возможно нам и не понадобятся, но они указаны к стандартному PHP мейнтейнерами:

apt-get install apache2-prefork-dev autoconf automake bison chrpath flex freetds-dev hardening-wrapper libapr1-dev  libbz2-dev libc-client-dev libcurl4-openssl-dev libenchant-dev libevent-dev libexpat1-dev libfreetype6-dev libgcrypt11-dev libgd2-xpm-dev libglib2.0-dev libgmp3-dev libicu-dev libjpeg-dev libkrb5-dev libldap2-dev libmcrypt-dev libmhash-dev libmysqlclient-dev libonig-dev libpam0g-dev libpng12-dev libpq-dev libpspell-dev libqdbm-dev librecode-dev libsasl2-dev libsnmp-dev libsqlite0-dev libsqlite3-dev libt1-dev libtidy-dev libtool libwrap0-dev libxmltok1-dev libxml2-dev libxslt1-dev locales-all mysql-server quilt re2c unixodbc-dev firebird2.1-dev libgdbm-dev libcurl4-openssl-dev libssl-dev  libreadline-dev libedit-dev

Отлично. Теперь поставим утилиту, которой будем собирать пакеты:

apt-get install checkinstall

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

Создадим директории для работы над нашими пакетам:
mkdir -p /usr/src/php/php5.2 /usr/src/php/php5.3 /usr/src/php/php5.4 /usr/src/php/php-switcher

Итак перейдем с сборке первого пакета - PHP 5.2

Какой файл .php исполняется как FastCGI на моем сервере и грузит CPU?

Ответа нет, потому как вопрос задан некорректно. Чтобы докапаться до истины расскажу в кратце как работает FastCGI.
От клиента, будь это браузер или реверс-прокси перед вэб-сервером, поступает запрос на исполнение некоего .php файла (пусть в нашем примере будет index.php). Вэб-сервер создает отдельный от себя процесс, который видно в топе как php-cgi, и говорит ему: "Ты создан! Теперь вот тебе файл index.php, исполни его и верни мне результат." Далее происходит вот что. FastCGI процесс берет файл index.php и проходится по его коду (вопрос компиляции я тут опущу за ненадобностью). На пути встречает include соседних файлов и их соответственно тоже запускает. И, напомню, все это один процесс php-cgi, который пробегает по многим .php файлам.
Затем, как только php-cgi процесс отдаст результаты обратно вэб-серверу, вэб-сервер, исходя из конфига, решит что делать с этим процессом - либо убить, либо оставить для обработки следующих запросов (чтобы заново его не рожать). Но, опять же согласно конфигу, он будет еще поглядывать за этим процессом: сколько раз он выполнял задачи, как часто проставивает, не превратился ли в зомби, не завис ли, не обработал ли слишком много запросов и так далее, пока все-таки не найдет достаточного основания для убийства этого процесса и порождения нового на его место.
То есть один php-cgi процесс - это не только не один .php файл, это еще и не одна порция таких файлов.Чтобы было более понятно, процесс php-cgi, который мы видим в ps, это ничто иное как контейнер, запущенный в памяти интерпретатор, наподобии как Tomcat у Java.
Именно поэтому не нужно удивляться, что при ограничении max_execution_time = 120 секунд в php.ini, в списке процессов вдруг виден процесс, который висит вот уже неделю. Он таких по 120 секунд за свою недельную жизнь видал не перевидал, все через него прошли, как через матрешку.


Для наглядности проведем эксперимент.

Посмотрим, сколько процессов у нас на сервере запустил некто user1316 (много строк я потер, чтобы не получалась длинная простыня).

node1-2:~# ps aux | grep user1316 | grep -v grep

user1316 48214  5.1  0.1 234148 33148 ?        S    10:54   1:52 /usr/bin/php5-cgi php
user1316 48215  5.0  0.1 249040 48068 ?        S    10:54   1:50 /usr/bin/php5-cgi php
user1316 48238  5.9  0.1 244976 43980 ?        S    10:54   2:11 /usr/bin/php5-cgi php
user1316 48242  3.7  0.2 251160 49780 ?        S    10:54   1:22 /usr/bin/php5-cgi php
user1316 48367  5.4  0.1 242904 43752 ?        S    10:54   1:58 /usr/bin/php5-cgi php
user1316 48383  5.3  0.1 244968 43856 ?        S    10:54   1:57 /usr/bin/php5-cgi php
user1316 48388  5.7  0.1 243432 42452 ?        S    10:54   2:06 /usr/bin/php5-cgi php
user1316 48399  4.4  0.1 244968 43968 ?        S    10:54   1:37 /usr/bin/php5-cgi php
user1316 51261  5.6  0.1 243436 42456 ?        S    11:01   1:37 /usr/bin/php5-cgi php
user1316 51262  5.8  0.1 244712 43736 ?        S    11:01   1:41 /usr/bin/php5-cgi php
user1316 52196  8.6  0.1 234540 33568 ?        S    11:04   2:16 /usr/bin/php5-cgi php
user1316 58913  2.9  0.1 244928 43772 ?        S    11:22   0:14 /usr/bin/php5-cgi php
user1316 59862  5.3  0.1 246504 47040 ?        R    11:25   0:18 /usr/bin/php5-cgi php
user1316 59863  4.4  0.1 242908 43448 ?        S    11:25   0:15 /usr/bin/php5-cgi php
user1316 61984  1.6  0.1 248832 49344 ?        S    11:30   0:00 /usr/bin/php5-cgi php
user1316 62000  1.1  0.1 242684 43180 ?        S    11:30   0:00 /usr/bin/php5-cgi php
user1316 62001  4.3  0.1 247412 47692 ?        R    11:30   0:01 /usr/bin/php5-cgi php
user1316 62006  3.1  0.1 231848 32376 ?        S    11:30   0:01 /usr/bin/php5-cgi php
user1316 62323  9.2  0.1 248028 48408 ?        R    11:30   0:01 /usr/bin/php5-cgi php
user1316 62324  2.3  0.1 242688 43188 ?        S    11:30   0:00 /usr/bin/php5-cgi php

Обратите внимание, есть процессы S (sleeping), а есть процессы R (running).
Sleeping - это процесс, который уже обработал основной .php, выданный ему вэб-сервером и все его инклуды. Теперь он просто висит в памяти и спит, пока его не пнёт вэб-сервер с новым заданием.
Running - это процесс, который в данный момент действительно что-то делает для вэб-сервера, а как сделает, то уснёт (S), если вэб-сервер его не убьет.

Теперь попробуем подцепиться к спящему процессу (бегущие (R) процессы нам неинтересны - пока мы будем писать команду, они уже умрут). Возьмем самый последний в списке. Его PID - вторая колонка:

strace -p 62324

Process 62324 attached - interrupt to quit
accept(0,

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

Но если все же вопрос "так какие файлы то?" остался неотвеченным, то вот, что даст ответ:

strace -e open,access -p 62324

А вот так можно померять, на что сколько времени уходит у данного процесса. Эта команда ничего не покажет, ее нужно прервать на ^C через произвольный промежуток времени. Но при выходе стрейс выплюнет красивую табличку с отчетом:

strace -c -p 62324

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 66.04    0.010125           0     20990      1314 open
 11.51    0.001765           0     75052         6 read
  3.59    0.000551           0     19012           munmap
  3.36    0.000515           0     28905           fstat
  2.44    0.000374           0     19012           mmap
  2.37    0.000363           0     19848           close
  2.17    0.000332           0      4536           write
  2.16    0.000331           0     29262           lseek
  1.72    0.000264           0     14543      1385 lstat
  1.21    0.000185           0      3301           poll
...
    <вырезано еще около 20-ти системных вызовов
      но они занимают менее 1% времени каждый>
...

Что-то интересное на эту тему есть в статье Оптимизируем загрузку PHP-кода в 22 раза, или почему FastCGI не ускоряет PHP

Аутентификация SSH через LDAP

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

Делается это следующим образом. Как многие знают, сегодня считается моветоном делать самостоятельные проверки паролей, групп и прочего. Давным давно уже изобрели единый центр проверок PAM. Даже утилита login, которая запускается, когда Вы коннектитесь к консоли, проверяет не сама, а отдает эту задачу "на аутсурс" PAM'у. Соответственно и OpenSSH сам не проверяет пароли.
Изначально у нас есть PAM-модуль для проверки через passwd (вообще их намного больше). Мы же поставим еще один PAM-модуль: для проверки через LDAP. А еще мы дополним NSS-переключатель новой опцией, чтобы он говорил всем, что можно проверять не только через passwd, но и через LDAP.

Сложность аутентификации SSH состоит в том, что запроcы будут идти к объектам PosixAccount, а в нормальном LDAP таким делать нечего. Кроме того, желательно также, чтобы в LDAP проверялись не пароли, а публичная часть ключа.

Итак сначала сделаем, чтобы проверялись хотя бы пароли, а уж потом и ключи допилим.
В моем случае используются:

OS: Debian Squeeze

LDAP: Oracle DSEE7

Начнем с того, что сохраним в безопасное место файл nsswitch.conf, который каждая вражеская программа пытается изкорёжить:

cp /etc/nsswitch.conf /etc/nsswitch.conf.orig

chattr +i /etc/nsswitch.conf.orig

Теперь научим наш PAM работать с LDAP-сервером. Для этого нам понадобятся модуль PAM, которому собственно предстоит работать с LDAP, и модуль NSS ( Name Service Switch), который к этому LDAP доступ для PAM'а обеспечит. Ну и консольные LDAP-утилиты для удобство дебага проблем:

apt-get install ldapscripts libnss-ldapd libpam-ldapd

Прошу обратить внимание на букву "d" в конце слов libnss-ldapd и libpam-ldapd. Раньше эти модули назывались без нее: libnss-ldap и libpam-ldap. Но потом их улучшили и переименовали. Если ошибетесь и поставите старые, то будете сами конфигурировать nscd и nslcd. И вообще там больше геморроя. А новые модули сами все делают.

В процессе установки будут запрошены некоторые параметры (ваши ответы врядли совпадут с моими, так как у меня специфический LDAP-сервер, я просто привожу пример):

LDAP server Uniform Resource Identifier:

ldaps://ldap.nodesquad.com:1686/

Distinguished name of the search base:

dc=nodesquad,dc=com

* (напротив всех сервисов поставить галочки )

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

vi /etc/pam.d/common-session

#Automatically create home direcory if not exist
session required          pam_mkhomedir.so skel=/etc/skel/ umask=0077

Для тех, кто хочет использовать аутентификацию по паролю, а их LDAP использует PosixAccount, на этом мануал будет закончен. Но у нас не все так сладко.

Для пользователей Oracle/SUN DSEE (Directory Server Enterprise Edition) придется каждому существующему пользователю добавить дополнительный класс и несколько его полей.
Как это сделать, написано тут.

Теперь можно пробовать приконнектиться по SSH со своим пользователем. Если не получилось, нужно смотреть логи запросов LDAP - как правило только они и спасают.

Если все ровно, то вот Вам новая проблема. Обратите внимание, что любая команда, подразумвающая обращение к LDAP (да хотябы ls, который показывает владельца файла) отвечает долго. Это из-за того, что она каждый раз обращается к LDAP. Во избежание этого нужно включить кэширование всех NSS-запросов: nscd. Но этому посвящено пол интернета, так что я обойду эту тему.

**********

Здесь можно посмотреть как перевести аутентификацию с паролей на RSA-ключи.

Oracle/Sun DSEE 7 и его отношение к NIS-схеме. (posixAccount)

В Oracle/Sun DSEE по умолчанию нету атрибутов из NIS-схемы, а в частности класса объектов posixAccount, который бывает жизненно необходим, например для аутентификации SSH через LDAP). Но... он там есть! И спасибо большое статье Adding UNIX users to DS6. Я не смог найти как скачать DSE (похоже вражеский Oracle тупо убил этот проект после покупки Sun) или по другому заставить DSEE отображать все, что он умеет, а не только то, что популярно, но мы всегда можем добавить ручками для каждого существующего аккаунта объект posixAccount и его поля.
Подготовим LDIF:

tee > add.posixAccount.ldif

dn: uid=michael.abramovich,ou=people,dc=nodesquad,dc=com
changetype: modify
add: objectClass
objectClass: posixAccount
-
add: homeDirectory
homeDirectory: /home/michael.abramovich
-
add: uidNumber
uidNumber: 1007
-
add: gidNumber
gidNumber: 1007

-
add: loginshell
loginshell: /bin/bash

Ну а теперь вгружаем этот чендж:

ldapmodify -x -D 'cn=Directory Manager' -W -H ldap://:1389/ -f add.posixAccount.ldif