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

Обсуждается путь запроса пользователя до и внутри сервера, его обработка и возврат ответа. Затрагиваются вопросы состояния приложения — работы с хранилищами, кэширования.

Затрагиваются вопросы масштабирования и отказоустойчивости. Речь идет о приложениях со средними и относительно большими нагрузками, где есть место универсальным решениям. Для систем, где нагрузки особо большие, существуют другие архитектуры и подходы, которые тут не упоминаются.

Смотрите в полноэкранном режиме.

Стоит отметить то, что исполняемый код сайта (PHP) на целевом сервере работает по схема схема nginx—php-fpm, а выбор файла — через try_files. Так же подчеркиваю, что требуется проверка, является ли пользователь разработчиком. Эти два фактора вместе отметали простые классические решения этой проблемы (в Гугле их масса, например).

Самое простое решение без проверки (разработчик или нет) заключается в том, что  бы проверять наличие специального файла в начале до проверки других условий. Это можно сделать с помощью try_files, подставив файл страницы с ошибкой первым в очереди. Но помимо того неудобства, что требуется добавлять/удалять файл в исходниках сайта (что не очень хорошо при заливке исходников через системы контроля версий), этот вариант просто не работает в сочетании с секциями if, которые появятся для добавления проверки «разработчик или нет». После входа в любую секцию if try_files ведет себя своеобразно и неправильно резолвит полные пути к файлам; источник проблемы описан тут.

Кстати, а по какому признаку мы будем проверять, является ли пользователь разработчиком? Ну, вариантов достаточно много. Самый удобный и популярный вариант — по наличию «специальной» cookie. Еще один популярный вариант — по IP. На какой фактор полагаться, большой разницы нет. В любом случае требуется проверка значения некоторой переменной, и осуществить эту проверку можно только с помощью секции if.

Резюмируя описанное выше: мы не можем делать проверку на наличие файла страницы обслуживания вместе с проверкой дополнительного фактора «разработчик или нет», используя try_files. Значит, проверку на наличие файла можно делать только с помощью if. В nginx if не может принимать два условия. Но эта проблема решается. Казалось бы, что цель достигнута. Проверяем 2 фактора: наличие файла и факт того, что пользователь — разработчик. Но такие проверки обязательно требуют входа хотя бы в один if. И тут опять фэйл: после входа в любой if try_files ведет себя своеобразно и неправильно резолвит полные пути к файлам после входа в секцию if; источник проблемы описан тут.

Короче, все довольно запутано и мутно. После нескольких часов мучительного подбора вариантов решение таки было найдено. Я выбрал способ проверки разработчика по cookie. Схема вышла очень простой. Один из if-ов был заменен map-ом, который работает нормально с try_files. А объединение условий (наличия файла и cookie) было реализовано через подмену пути к этому файлу. Т.е. в случае, когда пользователь — разработчик, мы просто портим имя файла, наличие которого свидетельствует о включенном режиме обслуживания.

Итоговая конфигурация.

В секции http (вне секций server) прописываем проверку «разработчик или нет». Она будет распространяться на все сайты в случае виртуального хостинга. В данном случае, если у пользователя установлена cookie DEVELOPER_SECRET_COOKIE со значением 1100110101, то пользователь будет признан разработчиком.

map $http_cookie $isDevHack {
    default "";
    ~DEVELOPER_SECRET_COOKIE=1100110101 "/non-existed-location";
}

В соответствующей секции server объявляем собственный обработчик ошибки 503, которая будет использована для индикации режима обслуживания:

error_page 503 @maintenance;
location @maintenance {
    rewrite ^(.*)$ /maintenance-mode.html break;
}

В данном случае подразумевается, что страница, которую нужно показать в случае работы в режиме обслуживания, находится в файле maintenance-mode.html, который лежит в корне сайта ($document_root данной секции server).

Теперь осталось определить, нужно ли показывать страницу «на обслуживании». В секциях location, для которых должно работать это правило, в начале (до применения других правил, которые работают в нормальном режиме работы сайта) добавляем:

if (-f "$isDevHack/home/site_root/maintenance") {
    return 503;
}

В данном конкретном случае проверяется наличие файла в домашнем каталоге сайта. Вообще, проверять файл можно где-угодно. Проверка будет работать только для обычных пользователей, потому что переменная $isDevHack из нашего map-а выше испортит это имя в случае, если пользователь — разработчик, так что файл никогда не будет найден.

Пример конфига nginx целиком для сайта example.com.

Создается скрипт, запуск которого можно поместить в cron (расписание зависит от ситуации и важности сайта). Код:

Посмотрите на

Но самое важное то, что они намекают на скорый отказ от классических программных технологий для десктопного программирования и продвигают новые, которые раньше применялись только в Вебе — HTML и JavaScript. Это пугает всех разработчиков настольных приложений для Windows, потому что они, по сути, теряют весь наработанный опыт и становятся в положение новичков на рынке (речь как об индивидуальных разработчиках, так и об огромных компаниях).

Почему Microsoft так поступает? Пытается тягаться с Google и Facebook? Или просто в компании понимают, что уже в ближайшем будущем суть операционной системы, как и классического десктопного прикладного программного обеспечения, в корень изменится?

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

Естественно, что в этом случае выбор операционной системы имел огромное значение. Все приложения разрабатывались под определенную ОС, поэтому выбирая ОС, пользователь фактически выбирал набор программ, которые он мог использовать.

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

С развитием скоростного, постоянно- и повсеместно-доступного Интернета ситуация начала меняться. Стали появляться веб-сервисы, ориентированные на замену старого десктопного софта. Прямая связь между компьютером пользователя и серверами размывалась стандартными протоколами Интернета. Значительно упростились требования к пользовательскому железу. И самое главное, что выбор операционной системы перестал влиять на выбор сервисов, потому что все они работали на технологиях, которые не зависят от платформы: HTML+CSS, XML, JavaScript.

Хост приложения разделился на две слабо связанных составляющих: клиентская и серверная. Причем хостом на клиентской стороне на этот раз целиком и полностью выступал веб-браузер, а не операционная система. От характеристик последней уже практически ничего не зависело. Это развязало руки пользователям — появилась возможность выбирать. Отчасти по этой причине удалось захватить неплохой кусок рынка OS X.

Перенос второй части хоста на серверную платформу развязал руки и разработчикам: теперь при разработке не требовалось брать в расчет мощность компьютера пользователя. Появилась возможность для каждого отдельного клиента пользоваться огромными объемами собранных данных. Стали разрабатываться такие приложения, делать которые раньше было невозможно или очень сложно. Кроме того, с пользователя стало проще брать деньги, так как модель продаж уступила место модели сервиса (оказания услуг).

Коренным образом изменились для разработчиков и критерии выбора операционной системы — отпала необходимость выбирать ту же ОС, что и у пользователей

Да, мы пользуемся большим количеством онлайн-сервисов, но подавляющее большинство софта по-прежнему все еще офлайн! — скажите вы, — Тогда о чем говорить: ничего не поменялось!

Нет, поменялось. Забудем пока о работе и рассмотрим досуг. Что нужно среднестатистическому пользователю домашнего ПК? Простенький текстовый редактор для написания заметок в блог. Простой табличный процессор для ведения домашней бухгалтерии или расчета стоимости покупки телевизора в кредит. Простое приложение для базового редактирования, хранения, каталогизации и просмотра фотографий и видео. Приложение для прослушивания музыки. Болталка (IM) для коммуникаций с другими людьми. И, конечно, браузер для чтения новостей. Пожалуй, все.

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

Сейчас весь перечисленный список программ доступен в Вебе бесплатно! Возможно, для русского человека выделенное курсивом слово безразлично — у него и так все бесплатно. Давайте на секунду представим, что все это надо купить. А еще надо купить операционную систему, чтобы оно работало. Возможно, покупка набора нужного ПО обойдется дороже, чем стоимость ноутбука, на котором оно будет работать. Так что выделенное курсивом слово дает возможность сэкономить раза в два.

Работая с веб-приложениями ничего не нужно устанавливать и обслуживать. «Сломалась» Winsows? Нет проблем, переустановить ее не сложно. Сложно поставить и настроить после установки еще 15 программ. С веб-сервисами это не нужно, для пользования ими достаточно даже встроенного в ОС браузера. А это дает еще один большой дополнительный бонус — мобильность.

Задача работы с файлами так же резко уходит на второй план с веб-сервисами. Все файлы — фотографии, видео, музыка, текстовые и табличные документы, презентации хранятся на серверах соответствующих сервисов (на первом этапе развития облачных сервисов) или в некоем едином пользовательском облачном пространстве, как SkyDrive (на втором этапе развития). Локальная файловая система нужна только для временного хранения файлов.

Фактически, для среднестатистического пользователя больше не требуется от операционной системы ничего, кроме возможности включиться и запустить браузер, чтобы пользоваться облачными веб-приложениями. Тогда зачем ее покупать? Можно взять простую бесплатную ОС. Например, Chrome OS. Именно эту нишу спешно пытается занять Google. Linux — не конкурент для Windows на десктопах, конкурент для Windows — это Chrome OS.

Пока у Microsoft есть фора перед Google. У них есть пользователи. Один раз Google уже обыграл Microsoft на их поле — доля браузера Chrome уже больше, чем Internet Explorer. Скоро Google постарается повторить свой успех в чемпионате разработчиков операционных систем. Что особо забавно — с тем же именем — Chrome. Очевидно, что в Microsoft все это прекрасно понимают и пытаются действовать на опережение. Почитайте заметку Джоэла Спольски «Огонь и движение» — во второй половине он как раз об этом пишет.

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

Microsoft хочет сделать тоже самое, что и Google, — операционную систему-браузер — хост для веб-приложений, полностью интегрированный с Сетью. Это и есть будущее операционных систем. Никакого больше десктопного софта! Только веб-приложения, которые запускаются прямо в операционной системе (зачем лишняя прослойка в виде браузера?).

Сегодня такое будущее не представляется реальным в обозримой перспективе — снова парируете вы. Да, нужно признать, что огромное количество программных продуктов пока не готово к переходу в облака (вы можете называть «это» как хотите, но суть не изменится; мне больше нравится слово «облака», чем, например, «режим онлайн»). Но уже сегодня по всем фронтам разработки все идет именно к этому! Игры — класс самых тяжелых для переноса в Сеть приложений. Но, посмотрите — в последнее время появляется все больше серьезных браузерных онлайн-игр (например, Command & Conquer). Их качество растет. Рабочие приложения для бухгалтеров, инженеров, дизайнеров, программистов тоже начали переход— постепенно появляются онлайн-аналоги десктопного софта. 1С, Adobe и другие гиганты ставят «облачные» цели (правда, причины там другие).

Кто-то делает это потому, что модно. Кто-то — потому, что понимает все описанное выше. У других причины свои. Но в любом случае — сейчас все начинают. Полностью перейти в онлайн пока не реально, и это нормально. Вспомните, сколько времени занял переход от консольных приложений к GUI. Во многих банках до сих пор сотрудники работают в DOS, хотя уже больше 20 лет прошло. Переход в облака займет еще больше времени, потому что задача на порядок сложнее. Но рано или поздно веб-технологии достигнут нужного уровня и переход произойдет. Кто будет больше готов к нему лучше, тот и выиграет. Кто не будет готов — останется не у дел. Мы уже проходили такое в истории индустрии программного обеспечения, и будем проходить снова во время каждой очередной смены эпохи технологий.

Так каким же я вижу будущее операционных систем? Операционная система станет чем-то похожим на веб-браузер, установленный на голое железо. Современный классический интерфейс (разработанный в Xerox PARC и впервые внедренный Apple почти 30 лет назад) отойдет в прошлое. Многие современные составные части ОС станут попросту не нужны, другие скроются от пользователя и превратятся в сервисы API для программистов. Основной задачей ОС станет предоставление возможности запуска клиентской части облачных сервисов. И преимущества, которые имеет Microsoft в современном мире ОС, будет значительно растеряны. Им придется придумывать новые способы привязки к себе пользователей и программистов в новой среде, более конкурентной, по сравнению с нынешней.

Когда это произойдет? Думаю, ответить не сможет никто. Многое зависит от решений, успехов и неудач крупных софтверных компаний, таких как Microsoft, Google, Facebook. В отличие от той эволюции софта, которую мы наблюдали в девяностых и двухтысячных, новая эволюция все меньше будет зависеть от производителей железа, и все больше — от производителей конечного ПО для пользователей.

Озадаченно смотрю на версии «свежего софта»…

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

Объясните — в чем смысл? Только в «проверенности» и стабильности этих версий?

Ответ:

Да. И это «только» весьма дорогого стоит. Более того, в рамках политики дебиана обновляться версии будут только на security fix’ы, то есть никаких новых фич до момента явного dist-upgrade’а. Сравните с убунтой, в которой каждые N дней пачка обновляемых пакетов.

Для десктопа это, может быть и нормально, но для сервера — неприемлимо. Я лично несколько раз сталкивался с дурацкими проблемами при обновлении версий (к счастью, только на декстопе). В списке лидеров — evolution (похерил архив почту), krusader (похерил половину настроек), deluge (криво подцепил старые настройки).

Если такой же сюрприз произойдёт на продакт-сервере, это будет очень не смешно. Особенно, если учесть сложность отката некоторых изменений в распределённых системах, даже при наличии бэкапа.

Таким образом, stable — это идеальное решение для сервера. А sid/ubuntu — вполне хорошо для _своего_ десктопа (решать проблемы похерившейся почты у себя неприятно, но решать их же у главбуха — куда грустнее).

Кстати, ровно той же политики придерживается и RHEL (CentOS) — у них в пятой версии до сих пор 2.6.18, хоть и с кучей бэкпортов.

© amarao, Хабрахабр.

Чтобы решить проблему отказа серверов Gmail от обслуживания  при отправке большого числа писем на несуществующие адреса, используем для отправки почты из скриптов сайта локальный почтовый SMTP-сервер (MTA). Локальный сервер будет выступать в качестве mail relay. В дополнение мы откажемся от подключения из скрипта к удаленному серверу, что может быть медленно. Локальные подключения всегда должны быть быстрее и стабильнее.

Локальный сервер мы будем использовать только для отправки писем. Причем, не важно, как будет происходить отправка: непосредственно через SMTP, или с помощью MUA. Получение почты по-прежнему будет происходить с серверов Gmail.

В дистрибутиве Debian 5 по умолчанию устанавливается MTA Exim4. Он отлично подойдет для наших задач. Причем его настройка производится с помощью мастера и невероятно проста. Настроить сервер требуется на прием соединений исключительно с локального соединения. При этом не нужно поручать ему обслуживание доменов, кроме дефолтного локального (localhost).

Итак, если Exim у вас не установлен, то установим его:

# aptitude install exim4

Далее запускаем его конфигурацию:

# dpkg-reconfigure exim4-config

1. На первом шаге необходимо выбрать конфигурацию сервера. В Exim есть несколько стандартных конфигураций, предназначенных для разных случаев. Подробнее о них в мануале. Нам нужна конфигурация “internet site; mail is sent and received directly using SMTP”.

2. Далее укажите имя сервера. Оно будет передаваться в SMTP-протоколе в команде HELLO, т.е. будет видно получателям вашей почты. Лучше всего, чтобы это имя совпадало с доменом, с которого шлется почта. Например, valera.ws.

Если у вас на сервере несколько сайтов с разными доменами (см. ниже), то лучше это имя сделать нейтральным, чтобы «не палиться». Например, можно выбрать local-mail-agent.

3. Далее требуется указать, какие интерфейсы должен слушать Exim. В нашем случае удаленные подключения мало того, что не нужны, так еще и опасны: кто угодно сможет рассылать почту через ваш сервер. Указываем только 127.0.0.1.

4. Далее спрашивается, какие домены должен обслуживать сервер. Т.е. для каких доменов не нужно пересылать письма на удаленные SMTP-сервера, пользователь заберет их с этого сервера. Нам не нужно обслуживание наших доменов. Можно указать только localhost, т.к. его больше обслужить некому.

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

5. Далее можно указать, для каких доменов сервер должен служить релеем (список через точку с запятой). Здесь не указываем ничего, так как на следующем шаге мы разрешим себе релей для всех доменов. Можете указать список ваших доменов.

6. Здесь укажем 127.0.0.1, чтобы раз-решить релей для всех запросов с локального IP.

При этой конфигурации есть один негативный момент. Если ваш сайт поломают, то злоумышленники смогут слать почту с любых доменов через ваш сервер. Если на сервере 1—2 сайта, то лучше на этом шаге оставить поле пустым, а на предыдущем шаге внести список этих доменов (для возврата на шаг назад нажмите кнопку “Cancel”). При появлении новых доменов не забывайте их заносить в конфиг. Если вы считаете свои сайты надежными, то проще всего указывать здесь 127.0.0.1.

7. Дале уточняется, является ли для нас проблемой постоянные DNS-запросы при отправке каждого письма. В 99,9% это не проблема, так что выбираем ответ на вопрос “Keep number of DNS-queries minimal (Dial-on-Demand)?” “No”.

8. Где хранить локальную почту (помните, мы указали серверу обслуживать домен localhost?) нам по сути не важно, так как этим как правило никто не пользуется. Можно выбрать вариант по умолчанию: складывать все в /var/mail.

9. Предпоследний шаг — выбор конфигурации. Хранить все в одном файле, или раскидать по множеству мелких файлов. В большой файл проще вносить большие изменения, а с мелкими проще работать в случае мелких правок. Выберите вариант на свой вкус. Я выбрал “unsplit configuration” (ответ “No”).

10. На последнем шаге укажем на какой аккаунт реального пользователя системы пересылать сообщения, отправленные на служебные аккаунты postmaster, root и т.д. Здесь имеет смысл указать ваше имя пользователя в системе.

Переконфигурировать Exim в любой момент можно тем же способом. Мастер подставит в значения по умолчанию текущие значения вашей конфигурации.

Правильная настройка SPF

Если кратко, то SPF — это способ борьбы со спамом.

Мы собираемся отправлять почту с сервера, PTR IP которого не равен одной из MX-записей сервера, а так же в большинстве случаев PTR IP не равен самому нашему домену (не всегда хостеры соглашаются менять PTR). В этом случае вероятность попадания писем в спам повышается. Но есть хороший способ ее понизить: указать правильно запись SPF нашего домена.

SPF-запись — это обыкновенная запись доменной зоны, имеющая тип TXT. Узнать текущее ее значение для домена можно с помощью команды host в Linux:

$ host -t TXT valera.ws
valera.ws TXT record currently not present

В данном примере SPF-запись не задана. Зададим ее. С моего домена почта может отправляться с серверов Gmail и с моего сервера. Для начала узнаем, какой PTR моего сайта (valera.ws):

$ nslookup valera.ws
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
Name:     valera.ws
Address:  93.174.6.118

IP-адрес моего сервера 93.174.6.118. Узнаем PTR:

$ nslookup 93.174.6.118
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
118.6.174.93.in-addr.arpa name = server.valera.ws.

Видно, что PTR IP, к которому привязан мой домен (IP моего сервера) — server.valera.ws.

v=spf1 a mx ptr include:_spf.google.com ~all

По порядку:

• v=spf1 — версия SPF (первая);
• a — разрешение отправлять почту с IP, указанного в A-записи домена (собственно с сервера, на который ваш домен ссылается);
• mx — разрешение отправлять почту с IP, указанных в MX-записях домена (в нашем случае сервера Gmail);
• ptr — разрешение отправлять почту с IP, PTR-запись которых содержит ваш домен (т.е. сам домен и поддомены);
• include:_spf.google.com — подключение разрешений для серверов отправки почту Gmail (совсем не обязательно почта будет слаться с серверов, указанных в MX-записи);
• ~all — нейтральная реакция на всю остальную почту; здесь можно указать -all, что будет значить, что почта, не попадающая под эти правила, — спам.

Если вы хотите отправлять почту с сервера, не попадающего под все эти правила, его можно указать по IP или домену PTR, например:

v=spf1 a mx ptr ptr:example.com include:_spf.google.com ~all

Запись указывается для вашего домена соответствующим образом, который определяет владелец DNS-сервера. Обычно сервером заведует хостер и предоставляет возможность вносить изменения в DNS-зоны через панель хостинга. Либо сам по запросу в саппорт меняет запись. В зональном файле должна появиться запись вида:

valera.ws.      TXT      v=spf1 a mx ptr include:_spf.google.com ~all

После обновления зоны host выдаст следующее:

$ host -t TXT valera.ws
valera.ws      TXT      «v=spf1 a mx ptr include:_spf.google.com ~all»

PHP mail()

После всей этой настройки функция mail() в PHP начнет слать почту через ваш локальный сервер на законных основаниях для антиспам-ботов. Но косяк будет в том, что в поле отправителя будет фигурировать адрес системного пользователя www-data@localdomain. Нас это не устраивает. Чтобы почта правильно слалась из mail(), необходимо использовать ее дополнительный параметр.

bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )

Именно $additional_parameters нас и интерисует. В него надо передавать реального отправителя:

mail($to, $subject, $message, $additional_headers, $additional_parameters.» -frealsender@valera.ws»);

Указывается отправитель слитно с параметром -f.

Теперь отправленные через mail() письма будут абсолютно адекватны (при условии, что вы указываете все нужные SMTP-заголовки, вроде “FROM:”, “TO:” и т.д.).

А если несколько сайтов с разными IP (настройка Exim для отправки писем с разных IP)?

Мы хотим использовать локальный SMTP-сервер для отправки почты со всех сайтов на сервере. Никаких проблем нет, если настроен Exim правильно (см. выше). Но проблема появляется, если разные сайты работают на разных IP. Мы не хотим в почте «палить» то, что все наши сайты живут на одном сервере. Но Exim по умолчанию шлет всю почту с основного (первого) IP сетевого интерфейса, а этот IP всем получателям в SMTP-заголовках “Received:” письма. Кроме того, там указывается и имя сервера, которые мы в случае с разными сайтами на сервере выбрали нейтральными.

Чтобы не «палить» IP сервера, нужно отсылать письмо на удаленный сервер с IP, равного A-записи домена сайта. Делается это несложно путем изменения конфига Exim. Внесем изменения в настройки транспорта SMTP Exim. Если вы выбрали монолитный конфиг, то нужно отредактировать файл:

# nano /etc/exim4/exim4.conf.template

Находим в файле строку “remote_smtp:” (поиск в nano — F6). Добавляем в конец этого блока:

interface = «${lookup{$sender_address_domain}lsearch{/usr/share/exim4/domain2ip}{$value}}»
helo_data = «$sender_address_domain»

Это значит, что при отправке письма нужно определить домен отправителя почты (для sender@valera.ws это valera.ws) и отправить почту с IP, к которому этот домен привязан. Само собой разумеется, что домен должен быть привязан к серверу, где установлен Exim.

Так же нужно создать файл в любом месте файл привязки доменов к IP (у домена может быть несколько IP, так что просто lookup-ить его не прокатит). Я выбрал для файла место: /usr/share/exim4/domain2ip

# nano /usr/share/exim4/domain2ip

Туда вводим наши домены по шаблону:

valera.ws: 123.123.123.123
vasya.ws: 123.123.123.124

Не забудьте дописать домен в файл в случае появления нового сайта.
Кстати, строку helo_data = «$sender_address_domain» можно добавить в файл даже если у вас один IP на все сайты. Тогда в команде HELLO SMTP-протокола (а, следовательно, и в заголовках писем) будет фигурировать ваш домен.

Идея с указанием интерфейса взята отсюда: http://www.directadmin.com/forum/showthread.php?t=36468

Проверка

Остается проверить, чтобы все ваши настройки работали верно. Для этого просто отправим письмо с локального сервера через консоль.

$ mail -a «From:feedbee@valera.ws» -s Test feedbee@gmail.com — -ffeedbee@valera.ws
Test <Ctrl-D>
Cc:

Проверяем отосланное письмо в ящике получателя:

А вот текст SMTP-протокола:

Delivered-To: feedbee@gmail.com
Received: by 10.236.109.139 with SMTP id s11cs13826yhg;
Wed, 24 Nov 2010 02:18:14 -0800 (PST)
Received: by 10.227.145.134 with SMTP id d6mr9025492wbv.195.1290593893066;
Wed, 24 Nov 2010 02:18:13 -0800 (PST)
Return-Path: feedbee@valera.ws
Received: from valera.ws (server.valera.ws [93.174.6.118])
by mx.google.com with ESMTP id b7si11085685wer.164.2010.11.24.02.18.12;
Wed, 24 Nov 2010 02:18:12 -0800 (PST)
Received-SPF: pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) client-ip=93.174.6.118;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) smtp.mail=feedbee@valera.ws
Received: from root by server.valera.ws with local (Exim 4.69)
(envelope-from <feedbee@valera.ws>)
id 1PLCQW-0006KD-Pc
for feedbee@gmail.com; Wed, 24 Nov 2010 10:18:12 +0000
To: feedbee@gmail.com
Subject: Test
From:feedbee@valera.ws
Message-Id: E1PLCQW-0006KD-Pc@server.valera.ws
Date: Wed, 24 Nov 2010 10:18:12 +0000

Test

P.S. Чтобы отправленная почта не попадала в спам, отправляйте письма только от имени реально существующих на серверах Gmail адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

В Windows, которым я пользуюсь на работе, протестировал только что купленную Cruser. Скорость чтения около 12 Мбит/с, запись — за 20 Мбит/с. Меня такие скорости устраивали полностью. Эпик фэйл случился, когда я попробовал писать на нее с Linux. Сказать, что SanDisk Cruser в нем был медленный — ничего не сказать. Скорость записи упорно не превышала 4,5 Мбит/с. Проверил на другом ПК с Linux — тоже самое. Поигрался с размером блока, толку ноль. Флэшка должна быть в NTFS, чтобы ее видела Windows. Так что другие FS даже не стал пробовать, просто выставил ее на продажу.

Снова пришлось что-то выбирать. Перерыл все Интернеты. Точной информации о скоростях в Linux не было практически нигде. Вообще, из того, что есть в наличии и по нормальной цене, были выделены два варианта: OCZ Rally 2 и Silicon-Power LuxMini 920. Причем скорости у второй вообще были подозрительно высоки (запись до 20 Мбит/с, чтение — до 30). Эти данные подтверждали обладатели флэшек. Но практически все отзывы были от виндузятников.

У моего коллеги на работе оказалась купленная долгое время назад OCZ Rally 2 16 Гб. Он так же пользуется Linux и никаких нареканий к флэше и скоростям не имел. Реальные скорости флэшки у него — до 15 Мбит/с запись и до 25 — чтение.
Рисковать второй раз я не захотел и купил себе такую же — OCZ Rally 2 16 Гб. Главный ее минус — колпачек. Но выбора то не было.

Отформатировал флэшку в NTFS с размером сектора 16 Кб. И начал тестить. Реальная скорость в Winsows и Linux почти не отличалась. Запись была все же не 15, но плавала от 12 Мбит/с. Правда потом, почему-то несколько упала, но все равно оставалась выше 11 Мбит/с при копировании больших файлов.

В поисках решения начал мучать Гугл. Большого количества материалов не было, но несколько тем, касающихся чипсета Интела, разрешения 1680×1050 и Убунту было. В большинстве материалов упоминалось решение с использованием софтины 915resolution. Но практически сразу выяснилось, что она устарела и в последних версиях Debian и Ubuntu ее нет смысла использовать вовсе.

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

Далее нашел упоминание еще одной замечательной софтины — gtf. Она очень нужна для того, чтобы определить правильные параметры режима моего внешнего монитора.

Так же познакомился таки с системой видеовыходов в ОС. Как то раньше разбираться с этим не приходилось. А вот по мере изучения Линуксов все больше и больше приходится вдаваться в такие тонкости :) Ну да ладно. Если выполнить в консоли команду xrandr, то она покажет вам в ответ ваши текущие видеовыходы и подключенные на них мониторы. Вывод будет примерно такой:

feedbee@debian:~$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 2048 x 2048
VGA connected 1680×1050+0+0 (normal left inverted right x axis y axis) 433mm x 271mm
1280×800 60.0 +
1680x1050x74.9 74.9*
[…]
LVDS connected 1280×800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
1280×800 60.0 + 60.0*
[…]
TV disconnected (normal left inverted right x axis y axis)

Такой вывод говорит, что у меня в системе один «экран» (Screen 0). Показаны его разрешения (текущее и экстремумы). Разрешения имеют значения, если мы раздвигаем мониторы (то есть делаем на каждый разную картинку; тогда они оба должны помещаться в экран). Так же показано, что у меня есть 3 видеовыхода: VGA, LVDS, TV. По VGA подключен внешний монитор, LVDS — это встроенный дисплей ноутбука. TV-выход не подключен. Звездочка напротив режима обозначает, что он активный.

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

Чтобы определить нужный режим и активировать его, надо сделать следующее:

1)Выключить ноут.

2)Подключить внешний монитор.

3)Включить ноут и сразу зукройте его (или переключитесь на внешний монитор Fn+F4), т.е. работать сейчас вы будите через внешний монитор с неродным разрешением.

4)Выполнить ~$ gtf 1680 1050 60
Я получил от команды такой вывод:
~$ gtf 1680 1050 60
# 1680×1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
Modeline «1680x1050_60.00» 147.14 1680 1784 1968 2256 1050 1051 1054 1087 -HSync +Vsync
Это и есть рассчитанные параметры режима для моего внешнего монитора.

5)Полученную строку добавить в /etc/X11/xorg.conf в Section «Monitor». Получится так:
Section «Monitor»
Identifier «Универсальный монитор»
Option «DPMS»
Modeline «1680x1050x74.9» 187.00 1680 1800 1976 2272 1050 1053 1059 1099 -hsync +vsync
EndSection

6)Перезапустить X-сервер (Ctrl+Backspace).
После этого остается только переключить нужный режим на нужный видеовыход. Это делается командой:

~$ xrandr —output VGA —mode 1680x1050x74.9

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

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

~$ xrandr —auto

P.S. Выход был найден благодаря http://forums.debian.net/viewtopic.php?p=210202&sid=18c11b5eb193a4399ca4cbbfd206e4a4

Так же полезной оказалась страничка https://answers.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+question/26807

В прошлый раз я писал, что у меня ноутбук HP Compaq nx7300 с сетевой Broadcom BCM4311 802.11b/g WLAN (rev 01). Эта карточка числится в списке поддерживаемых драйвером bc43 при условии свежести ядра (2.6.24 или старше). Чтобы проверить, какая карта у вас, выполните команды:

update-pciids
lspci -nn

В выводе последней команды в конце у меня есть следующая строка:
10:00.0 Network controller [0280]: Broadcom Cor poration BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)

Это и ест ь мой сетевой адаптер Broadcom BCM4311.

Поддерживаются карты:

• bcm4303 (802.11b-only chips, uses b43legacy)
• bcm4306 (Rev. 2 uses b43legacy, Rev. 3 uses b43)
• bcm4309 (only the 2.4GHz part)
• bcm4311 rev 1 / bcm4312
• bcm4311 rev 2 / bcm4312 (needs patches for 2.6.24)
• bcm4312 (only the 2.4GHz part)
• bcm4318

Для карты BCM4306 Rev 2 или для работы с лишь 802.11b режимом используется дрвйвер b43legacy. Во всех других случаях используется b43. Об установке b43 и поговорим :)

Для ядер 2.6.25 и выше надо выполнить лишь 2 следующие пачки команд, и все:

wget http://bu3sch.de/b43/fwcutter/b43-fwcutter-011.tar.bz2
tar xjf b43-fwcutter-011.tar.bz2
cd b43-fwcutter-011
make
cd ..

export FIRMWARE_INSTALL_DIR=»/lib/firmware»
wget http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
tar xjf broadcom-wl-4.150.10.5.tar.bz2
cd broadcom-wl-4.150.10.5/driver
sudo ../../b43-fwcutter-011/b43-fwcutter -w «$FIRMWARE_INSTALL_DIR» wl_apsta_mimo.o

Тем самым мы скачали и собрали b43-fwcutter, которому затем подсунули скачанный драйвер. Он его «вставил» в систему. Все, сетевая работает.

Про настройку сетевой читайте в старом посте.

1) Для поднятия соединения необходимо установить пакеты PPTP и PPP.

Опционально можно установить пакет для мониторинга PPP-соединения:

2) Далее требуется поправить конфиг /etc/ppp/options. Если брать за основу дефалтный файл, надо закомментить лишние строки и добавить недостающие. Но проще удалить все и вставить следующие строки:

3) Необходимо создать файл ppp-соединения в каталоге /etc/ppp/peers. Имя файла может быть любое, но его придется указывать каждый раз при подъеме соединения. Например, /etc/ppp/peers/adsl.by

В данном примере требуется заменить имя пользователя (22222pupkin), а при необходимости и IP шлюза.

3) В файл /etc/ppp/chap-secrets добавляем пароль от Интернета. Для параноиков обращаю внимание, что файл можно писать и читать только из-под root’а. Остальным пользователям заглянуть в него не удастся. В файл требуется добавить строку, в которой все значения разделены не пробелом, а табуляцией.

22222pupkin adsl.by пароль *

4) Если вы еще не указали DNS-сервера Инфонета при настройке сети, сделайте это. Это можно сделать через Network Manager, или вручную в файле /etc/resolv.conf

5) Теперь пропишем роуты. Это можно делать каждый раз после загрузки, можно сделать скрипт (например у меня роуты прописываются после поднятия wi-fi-соединения скриптом), можно засунуть в «автозагрузку». Роут нужен следующий:

192.168.0.1 — это адрес вашего модема.

Настройки готовы. Теперь можно пользоваться. Запуск соединения (из-под  root’а):

Останов всех ppp-соединений:

Останов только данного соединения:

Просмотр статистики (если соответствующий ставили пакет в начале):

(Чтобы выйти из просмотра статистики, наберите !q)

После команды pon adsl.by между вами и сервером поднимается соединение по протоколу PPP, поверх которого идет туннелирование PPTP. Соединению PPP соответствует появившийся сетевой адаптер ppp0. Если создать больше одного соединения, появятся адаптеры ppp1 и т.д. Именно на этот адаптер прописывается default route автоматически (если ваши настройки соответствуют приведенным выше).

Удачи! ;)

В своем блоге я опишу результат собственных изысканий по подъему wi-fi адаптера на ноутбуке HP Compac nx 7300 для дистрибутива Debian (etch). Стоит упомянуть, что вся информация актуальна на момент ноября 2008 года, и что все описанное ниже не претендует на «руководство», это лишь описание моих действий и результатов.

UPD: Внимание! В связи с выходом Debian 5.0 Lenny сначала прочитайте эту запись!

Гуглинг на тему моего wi-fi в Debian привел к замечательному описанию-руководству по поднятию беспроводной сети. В этом мануале рассказывается про установку драйверов для беспроводных адаптеров на базе чипсетов Broadcom 43xx и 1390. Вот как раз 4311 и установлен в ноутбук HP Compac nx7300.

Драйвера от Broadcom есть и под Linux, и под Windows. Для линукса есть даже 2 разных версии:

• Linux b43 / bcm43xx driver (начиная с ядра 2.6.24 его просто переименовали),
• Linux b43_legacy driver (отделен в ядре 2.6.24 для совместимости со старыми чипсетами).

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

Сначала требуется определить, какой сетевой адаптер используется. Как это сделать, написано в отдельном руководстве. Самый простой вариант — выполнить следующие команды:

update-pciids

lspci -nn

В выводе последней команды в конце у меня есть следующая строка:

10:00.0 Network controller [0280]: Broadcom Cor poration BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)

Это и ест ь мой сетевой адаптер  Broadcom  BCM4311. Теперь пробуем заставить его работать. Стоит отметить, что до установки дров сетевой интерфейс wlan0 просто не существует, а диод на ноуте не горит и не включается кнопкой.

Установкой я занимался по порядку, описанному в статье. Принцип там такой: попробуйте сделать это, если не поможет, попробуйте это, если не поможет, попробуйте это и т.д.

Сразу отмечу, что ядро у меня 2.6.18 (т.е. меньше) 2.6.24, а значит b43_legacy и Native b43 driver рассматривать смысла нет вообще. Cтавим Native bcm43xx driver.

Руководство по установке этого драйвера начинается с этого места. Подзаголовки (option 1, 2, 3, 4, 5) — это этапные варианты установки драйвера. Последним пунктом идет установка Ndiswrapper’а. Я прошел все эти 6 уровней, адаптер заработал у меня только после установки  Ndiswrapper’а. Если у вас не адаптер BCM4311 в связке с linux kernel 2.6 .18, рекомендую попробовать все варианты по порядку (пройти этот увлекательный к вест :), иначе можете сразу приступать к установке  Ndiswrapper’а.

Если в конце концов у вас таки появилось устройство wlan0, поздравляю, драйвер установлен!

Но установить драйвер естественно мало. Надо еще настроить интерфейс. Так как я бродил несколькими обходными путями и произвел достаточно много действий при изучении этого вопроса, точно сейчас сказать сложно, какие из действий являются минимально-необходимыми. Но факт в том, что в файле /etc/networks/interfaces у меня сейчас следующие строки:

allow-hotplug wlan0

iface wlan0 inet static

wireless-essid ZyXEL

address 192.168.0.30

netmask 255.255.255.0

gateway 192.168.0.1

ZyXEL — точка доступа, IP понятны, вторая строка обозначает, что IP пр описаны статически, а не по DHCP. Так же есть файл /home/feedbee/wlan следующего содержания:

echo "Loading ndiswrapper..."

modprobe ndiswrapper

echo "Setting mode Managed..."

iwconfig wlan0 mode Managed

echo " -- Setting ESSID"

iwconfig wlan0 essid ZyXEL

echo " --Setting to channel 6..."

iwconfig wlan0 channel 6

echo " --Turning on managed mode..."

iwconfig wlan0 mode Managed

echo " --Setting encryption key"

iwconfig wlan0 key restricted E3374866EE

echo "Bringing up interface wlan0..."

ifconfig wlan0 up

echo "Disable interface eth0 to kill its routes. .."

ifconfig eth0 down

echo "--Setting routing..."

route add default wlan0

route add -net 81.25.32.0 netmask 255.255.255.0 gw 192.168.0.1 wlan0

Этот файл включает сетевой адаптер. Но до запуска файла адаптер дол жен быть включен физически, т.е. должен гореть синий диод на ноутбуке.

В этом файле все должно быть понятно, отмечу только следующие моменты. Последняя строка строго индивидуальна, она прописывает нужный для работы роут на провайдера. Вообще, после поднятия интерфейса wlan0 остаются старые роуты на eth0 и к ним добавляются новые на wlan0. В этом случае роутиговая система ядра пытается слать пакеты через eth0 даже в том случае, если сетевой кабель не подключен. Именно по этой причине в файле wlan гасится интерфейс eth0 (при этом роуты на него автоматически удаляются). Дефалтные роуты на wlan0 прописываются автоматически.

Строка iwconfig wlan0 key restricted E3 374866EE в файле обозначает, что используется WEP-шифрование.  E3374866EE — это ключ, который введен на точке (в HEX-формате). Для WEP-64 это 10 шестнадцатеричных цифр, для WEP-128 — 26. Если шифрование не используется, эту строчку можно просто убрать.

Если интерфейс wlan0 и соединение с точкой доступа поднялись, но пакеты на сеть не ходят (хосты не пингуются), разбирайтесь с роутами.