серера для хостинга

Виртуальный хостинг, ftp и LDAP

div.main {margin-left: 20pt; margin-right: 20pt}Виртуальный хостинг, ftp и LDAPТристан Гривс 16.10.2001 Виртуальный хостинг (поддержка более чем одного домена на одном физиологическом сервере) — одно из основных течений деятельности многих ISP, при этом в качестве программного обеспечения сервера Web, будто правило, используется Apache. Однако это лишь одна сторонка медали, кроме этого, клиенты должны обладать доступ для управления собственным Web-сайтом. Недавно мы свели все домены, обслуживаемые нашим подразделением, на последнюю архитектуру. Мы рассматриваем этот прецедент будто возможность пересмотреть наш подход к решению данной проблемы. информация заказчика должна храниться в гибкой фигуре, обеспечивая удобство управления; сервер ftp должен быть устойчивым и защищенным и ограничивать доступ пользователей, при обращениях к нашему специфическому хранилищу информации, пределами их домашнего каталога. Для работы с этим ресурсом разрешен лишь протокол ftp, что не вручает возможности пользователям применять иные инструменты управления (telnet и др.). Ранее сведения о пользователях сохранялись с подмогой характеристичной для UNIX системы хранения паролей, однако нам хотелось бы ретироваться от этой практики. В качестве механизма для хранения информации о пользователе мы постановили использовать LDAP (Lightweight Directory Access Protocol). LDAP — широко применяемый для цельнее аутентификации протокол, для коего написаны интерфейсные модули на здоровенном числе стилей программирования. Нашей мишенью стала разработка оружий управления на слоге Perl. LDAP — это протокол для доступа к службе каталогов в архитектуре клиент-сервер. Он захватывает свое зачин от X.500, однако ныне он может использоваться для доступа и к прочим службам каталогов. Нам требовался пакет «все в одном», где бы убору с собственно протоколом был реализован механизм хранения баз настоящих. Мы избрали наиболее запоздалую из стабильных версий OpenLDAP (1.2.11) для сферы Linux 2.2.x. планировалось, что один-единственной мишенью системы будет аутентификация пользователей ftp; таковым образом, разработка базы настоящих несравнимо упрощалась. Интеграция этих функций в уже имеющуюся базу настоящих LDAP потребовала бы вящего времени и сил. Процесс установки выходил в соответствии со стандартной документацией, кою можно найти по адресу: — там же будут отвечающие отправные коды программ. Файл slapd.conf — основной конфигурационный файл для slapd (slapd — это сервер LDAP в проекте OpenLDAP). В нем трескать три директивы, на какие необходимо обратить внимание: В этих директивах rootdn и rootpw — имя и пароль пользователя, какие необходимы для доступа к базе настоящих, о чем будет рассказано запоздалее. Строки, ввергнутые патетичнее, — это прямо-таки образец задания директив; на самом деле рекомендуется использовать зашифрованный пароль — в документации вы найдете отвечающие предписания. В Листинге 1 файл slapd.conf вогнан всецело. (Все листинги, упоминаемые в этой статье, можно найти на .) При установке пакета уделите должное внимание ограничению доступа. По умолчанию ваша база настоящих может быть доступна для любого компьютера, кой подключен к Internet. таковым образом, необходимо корректно ввести параметры доступа и ввести, где необходимо, неодинаковые фильтры и экраны для того, дабы ситуация оставалась под контролем. После того будто slapd введен и запущен, вытекающая ключевая проблема — создание класса объектов для хранения учетных записей пользователей. На настоящем этапе схема работы с OpenLDAP может быть расширена для настройки базы настоящих под нужды конкретной задачи (LDAP использует концепции классов и объектов вместо эдаких элементов, будто поля и таблицы реляционных баз данных). Нам было величаво создать формат настоящих, кой был бы ясен нашему серверу ftp. Мы воспользовались рекомендуемой Джоном Моррисси конфигурацией для модуля mod_ldap ProFTPD, какая более досконально изображена басистее. В итоге содержимое нашего файла local.oc.conf выглядело вытекающим образом: # FTP account object class. objectclass ftpAccount requires objectclass, cn, uid, homeDirectory allows userPassword, accountStatus, loginShell, uidNumber, gidNumber Многие из показанных атрибутов недурственно знакомы системным администраторам, желая это, вероятно, не притрагивается атрибута cn. Это сокращение означает common name (общее имя). В настоящем классе мы используем его для хранения имени домена. Поскольку наша конфигурация ориентирована на домены, в любой работе администратор, скорее итого, будет использовать имя домена, этак, для розыска. В вышеприведенной схеме всякий домен, о каком знает система, обладает отвечающую учетную запись на сервере ftp (имя домена — cn, имя ftp-записи — uid). всякий домен обладает по одной учетной записи. userPassword — пароль для аутентификации на сервере ftp (см. ниже); accountStatus — атрибут для административных цельнее (открыт?, оплата позднее? и т. д.); uidNumber — идентификатор UID, выделенный поль зователю; gidNumber — групповой идентификатор GID, выделенный пользователю. Обратите внимание, что атрибуты uidNumber и gidNumber не применяются, поскольку вместо них мы используем значения, заданные при конфигурации нашего ftp-сервера. Детали вогнаны басистее. В стержневом конфигурационном файле сервера slapd с именем slapd.conf необходимо показать ссылку на local.oc.conf вытекающим образом: include /usr/local/etc/openldap/local.oc.conf Это все, что требуется для того, дабы наш свежий класс «ожил». необходимо помнить лишь одну штука — наша база настоящих еще не включает ни одной реальной учетной записи. Во-первых, водящаяся информация об обслуживаемых доменах была вывожена в файл формата CSV. характеристичная строка этакого файла: www.some-domain.com,fred,AaBbCcDdEeFfg,/virtual/ www.some-domain.com где поля содержат: имя домена; имя учетной записи, используемый для загрузки файлов по ftp; шифрованный пароль для данной записи; домашний каталог (где хранятся страницы Web). Затем был написан сценарий на слоге Perl, кой считывал настоящие из файла CSV и строил отвечающие записи в базе настоящих LDAP. Это сценарий domains2ldap (см. Листинг 2). Если вы будете его использовать, отредактируйте в соответствии со своими нуждами. Прежде итого, необходимо изменить информацию о пользователе, кой обладает лево вносить изменения в базу настоящих, и о том, где будет база настоящих. Для этого потребуется Net::LDAP. Он доступен по адресу: (сервер CPAN), под именем perl-ldap. Я использовал версию 0.22. Помимо сценария OpenLDAP поставляется с кое-какими инструментами для работы с базой настоящих. Для того дабы добавить последнюю запись вручную, в файл /tmp/add.tmp вытекает приткнуть что-нибудь вроде нижеприведенного: этот образец составлен для виртуального сервера Web с доступом сквозь ftp по учетной записи ftpfoo. Пароль хранится в шифрованной фигуре, однако, вместо этого, вы можете использовать обыкновенный текст, предварив его ключевым словом {clear}. (Некоторые спросы, связанные с данной конфигурацией, мы обсудим басистее.) ldapadd -D «cn=Admin, dc=your-domain, dc=com « -w <Пароль> -f /tmp/add.tmp Параметр -D должен ссылаться на пользователя с левом добавления настоящих. В характеристичном случае этот параметр идентичен параметру rootdn, кой пояснялся ранее при описании файла slapd.conf. ниже, параметр -W — это пароль для пользователя rootdn, кой хранится в rootpw. таковая команда выполняет добавление записи в базу настоящих от имени пользователя Admin, какому предоставлены спрашиваемые лева. истребить запись еще проще. вытекающая команда удаляет запись, созданную предыдущей строкой. ldapdelete -D « cn=Admin, dc=your-domain, dc=com « -w <Пароль> «Uid=ftpfoo» Для получения более детальной информации об этих командах (и о команде ldapmodify) используйте документацию. В качестве сервера ftp мы избрали ProFTPD ( ). Он верен, спокоен в конфигурировании и (как ранее упоминалось) обладает модуль, с подмогой коего пользователи могут быть аутентифицированы сквозь LDAP. прежде мы ввели версию 1.2.0rc2, однако столкнулись с проблемами в водившейся версии модуля mod_ldap — он прямо-таки не ломил. Ситуация была разрешена получением подновленной версии от автора модуля по адресу: . После копирования последнего модуля в каталог contrib дерева отправных текстов ProFTPD, система была с.компилирована вытекающим образом: ./configure -with-modules=mod ldap make make install зодчество вашей системы может потребовать внесения кое-каких изменений, для чего будет пользительна документация на сервере Web ProFTPD. басистее вогнаны ключевые элементы конфигурационного файла ProFTPD (proftpd.conf), требующиеся для выполнения аутентификации на базе LDAP: В нашем случае все домашние каталоги учетных записей относились одной обобщенной комбинации пользователь/группа — тяни доступ определялся ProFTPD. таковым образом, просмотр был запрещен, и сконфигурированы GID и UID, используемые по умолчанию. Кроме того, по умолчанию пароль являет зашифрованным. Если вы внимательно проглядите domain2ldap (см. Листинг 2), то завидите, что ввозимые (зашифрованные) пароли предваряются ключевым словом {crypt}. В этом дудки непосредственной надобности — что вытекает из строки LDAPDefault-AuthScheme, — однако порядочно бы заблаговременно порассудить о том, что может случиться (например, как-то потребуется использовать простые текстовые пароли). На настоящем этапе все надлежит переть будто по маслу. Если это не этак, проверьте регистрационные журналы (logs) обоих серверов — ProFTPD и slapd, вдруг вы наблюдете очевидные оплошки. К сожалению, в нашем случае основание неработоспособности модуля mod_ldap не залежала на поверхности: розыск по базе настоящих LDAP пролегал успешно, вот лишь ProFTPD всякий одинехонек во период аутентификации пользователя упорно отвечал отказом. будто показано в данной статье, доступ к каталогам при виртуальном хостинге осуществляется на основе параметров «имя пользователя/пароль». Все пользователи оповещаются о том, с каким хостом они будут трубить. Кроме того, для упрощения доступа мы добавляем в DNS запись ftpadmin.their-domain.com, поскольку размещаем у себя и пользовательские DNS. В всяком домене было бы недурственно использовать раздельные базы настоящих аутентификации. В большинстве случаев не получается выделить всякому сайту Web отдельный IP-адрес, более подходящим чудится применение основанного на имени (Named-Based) виртуального хостинга Apache, что вручает возможность пользователям обладать свои, раздельные неподписанные ftp-сайты, предназначающиеся для загрузки информации (но вкалывающие физиологически на том же сервере). К сожалению, таковая возможность не поддерживается протоколом ftp, в каком отсутствует эквивалент системы Host-Header протокола HTTP. таковым образом, сервер не способен ввести, в какой конкретный домен пользователь желает получить доступ, если домены используют одинехонек и тот же IP-адрес. Тристан Гривс трубит системным инженером в Argogroup и консультирует клиентов в области совместимости устройств беспрово

Похожие статьи:

доп мат