Алексей Стахнов - Linux

mail

Одна из первых программ – почтовых клиентов. Не блещет красотой интерфейса (его просто нет), достаточно примитивна, зато не занимает много места и поэтому присутствует практически на любом хосте. Представление о программе mail можно получить из рис. 18.1.

Рис. 18.1. Почтовый клиент mail

Pine

Один из самых «навороченных» текстовых почтовых клиентов, который так же позволяет работать с сообщениями новостей (news). Удобный, приятный в использовании интерфейс. Внешний вид программы pine изображен на рис. 18.2.

Рис. 18.2. Почтовый клиент pine

Mozilla

Аналог Netscape Communicator. Достаточно устойчивая и надежная почтовая программа. Является частью программного комплекса Mozilla – Web-браузер, почтовый клиент, клиент чата. Почтовый клиент Mozilla представлен на рис. 18.3.

Рис. 18.3. Почтовый клиент Mozilla

Balsa

Стандартный почтовый клиент GNOME. Понятный и удобный интерфейс (рис. 18.4). Могут быть некоторые проблемы с русификацией.

Рис. 18.4. Почтовый клиент Balsa

Stuphead

Модификация почтового клиента, написанного японским программистом, сделанная компанией ALT Linux. Пока получается достаточно неплохо и с русским языком проблем нет (рис. 18.5).

Рис. 18.5. Почтовый клиент Stuphead

Evolution

Попытка программистов создать нечто подобное Microsoft Outlook – почтовый клиент (рис. 18.6), органайзер (рис. 18.7), дневник и записную книжку в одном комплекте. Получился довольно «увесистый» программный пакет.

Рис. 18.7. Почтовый клиент Evolution – планировщик встреч

Kmail

Очень хороший почтовый клиент (рис. 18.8). Хорошо понимает различные кодировки, удобный и понятный интерфейс. Является стандартным почтовым клиентом для KDE.

Рис. 18.8. Почтовый клиент Kmail

Ссылки

• www.citforum.ra/internet/servers/ – Павел Храмцов. Организация и администрирование почтовых и файловых серверов Internet. Центр Информационных Технологий.

• Соответствующие HOWTO (см. гл. 13):

– Linux Mail-Queue mini-HOWTO;

– Sendmail+ UUCP HOWTO;

Для создания Web-сервера (HTTP-сервера) в мире Linux в основном используется бесплатный (лицензия GNU) Web-сервер Apache. По статистическим данным до недавнего времени более пятидесяти процентов Web-серверов в Сети были построены на базе сервера Apache.

Чем же привлекателен этот сервер? Во-первых, большое количество возможностей – использование CGI-скриптов, шифрования, доступ по паролю, перекодирование страниц "на лету", поддержка виртуальных хостов и многое другое. Во-вторых, малая требовательность к ресурсам и большая производительность. В-третьих, многоплатформенность – Apache есть для Linux, для различных клонов UNIX, для Windows. В-четвертых, он бесплатный и с открытым исходным кодом. Список можно продолжать. Конечно, есть и недостатки, к примеру, некоторые сложности с конфигурированием. Но в целом – этот сервер не зря получил столь большую популярность.

В качестве альтернативы для Linux-платформы в последнее время выдвинулся Web-сервер TUX, который использует особенности ядра Linux, что позволило резко увеличить количество обрабатываемых запросов за единицу времени. Однако у этого сервера есть несколько минусов, в том числе:

• платформозависимость;

• неустоявшийся код;

• мало дополнительных возможностей по сравнению с Apache.

Далее мы рассмотрим конфигурирование сервера. Существует так называемый "Русский Apache" – адаптированный для русскоязычной аудитории. Мы, конечно, коснемся этого вопроса, но в целом будем рассматривать стандартный Apache.

Конфигурация

Установка сервера для дистрибутивов, использующих rpm-пакеты, не составляет особого труда – необходимо скачать нужный пакет и произвести установку сервера командой

rpm -I имя_пакета

С конфигурированием труднее. Мы рассмотрим только наиболее распространенные директивы и их параметры, поскольку полный перечень слишком большой. Если вы производите переконфигурирование при рабочем сервере Apache, вам необходимо заставить сервер перечитать конфигурационные файлы. Сервер перечитывает конфигурационные файлы при запуске или при получении сигнала – hup или – uSRi. Если сервер находится в рабочем состоянии, то при изменении конфигурации его рекомендуется перезапустить командой kin – usri, поскольку в этом случае текущие соединения не закрываются принудительно и завершаются обычным образом, а следующие клиенты работают уже с новыми конфигурационными файлами.

Конфигурация сервера задается в файлах httpd.conf, srm.conf, access.conf и. htaccess. Файл httpd.conf предназначен для общей конфигурации сервера, srm.conf содержит описание доступных ресурсов, a access.conf – права доступа к ресурсам. Однако в современных версиях сервера любая директива конфигурации может лежать в любом из этих файлов. Сейчас de-facto все директивы конфигурации содержатся в файле httpd.conf.

Файлы. htaccess могут находиться в каталогах и переопределять права доступа и другие параметры данных каталогов. Некоторые модули могут иметь свои отдельные файлы конфигурации (например, mod_charset требует файлы, хранящие таблицы перекодировки).

Используемые обозначения

Ниже показаны обозначения, используемые при описании параметров конфигурации сервера:

• S – директива действует на поведение сервера целиком;

• V – действует, если запрос касается данного виртуального хоста;

• D – определяет свойства только данного каталога;

• A – определяет свойства только данного каталога.

Права доступа и свойства объекта

Права доступа к данному каталогу и его свойства определяются следующими директивами.

• DA allow from {host}

Определяет, с каких хостов разрешен доступ к данному каталогу:

– all– для всех;

– доменное имя – с тех хостов, имя которых заканчивается этой строкой;

– полный IP-адрес;

– частичный IP-адрес —1,2 или 3 байта IP-адреса;

– a.b.c.d/e.f.g.h – сеть/сетевая маска;

– a.b.c.d/nnn – сеть/подсеть.

• DA allow from env=имя_переменной

Доступ разрешается, только если определена соответствующая переменная окружения.

• D AllowOverride {None | All | AuthConfig | Filelnfo | Indexes | Limit | Options}

Определяет, какие директивы из. htaccess в данном каталоге могут перекрывать конфигурацию сервера.

• D AuthName домен_авторизации

Определяет, какой домен авторизации клиент должен использовать при определении имени и пароля.

• DA deny from {host}

Определяет, с каких адресов запрещен доступ к данному каталогу:

– all– для всех;

– доменное имя – с тех хостов, имя которых заканчивается этой строкой;

– полный IP-адрес;