В этой подшивке я собираю все найденные, на личном опыте и из сторонних источников полезные и не очень советы, руководства и т.п. - ответы на вопросы, начинающиеся на "Как".
Здесь собраны материалы, касающиеся работы и настройки ОС Linux семейства Fedora/Fedora Core.
Вступление
Невзирая на то, что USB модемы на базе чипа Conexant AccessRunner достаточно популярны, пришлось несколько поломать голову, прежде чем удалось настроить этот модем для подключения к Интернету в Fedora 9.
Данные инструкции должны быть также пригодными и для Fedora 8, Fedora 7, Fedora Core 6.
Основные шаги
1. На сайте Conexant AccessRunnerADSL USB Modems with Linux, в разделе Firmware возьмите и соберите из исходников программу, которая извлекает прошивку для вашего модема. Извлекает она её из драйвера для Windows, ищите его в .cab файле на диске, поставляющемся с модемом.
Чтобы не нарушать лицензионного соглашения, я не включаю саму прошивку (cxacru-fw.bin) в данный документ. Вам придётся извлечь её самостоятельно. Если у вас возникают непреодолимые препятствия с этим или потерян диск, напишите мне, обсудим, что делать.
2. Поместите извлечённую прошивку, cxacru-fw.bin. в каталог /lib/firmware. Перезагрузите компьютер, воткните USB кабель модема. Должна начать мигать (загрузка прошивки) и устойчиво загореться зелёная лампочка справа. Предполагается, что сам модем подключён должным образом, что у вас стоит разветвитель для телефонной линии и услуга ADSL вам доступна.
3. Найдите в сети и установите br2684ctl-20040226-alt1.i586.rpm (для создания виртуального интерфейса-моста для подключения модема). Найти этот пакет непросто, поэтому я прикрепил к сообщению его копию.
4. Убедитесь, что установлен пакет pppoe - потребуется для настройки собственно P2P соединения.
5. На этом предварительные шаги окончены, далее даются собственно инструкции по подключению модема.
a) подключите модем и дождитесь, когда загрузится прошивка, оба крайних индикатора должны загореться ровным зелёным светом
b) дайте команду
br2684ctl -b -c 0 -e 0 -a enc.vpi.vci
заменив указанные символьные строки на соответствующие цифровые.
enc - тип инкапсуляции. В случае LLC это 0.
vpi, vci - соответствующие значения, их вам должны были сообщить при предоставлении услуги ADSL
В итоге вам должны сообщить, что интерфейс nas0 успешно создан.
c) (делается в нормальных условиях только раз) запустите pppoe-setup, ответьте на вопросы. Укажите nas0 в качестве имени интерфейса.
d) командой
ifup ppp0
подключите модем.
e) перезапустите брандмауэр (service iptables restart)
Всё. Связь установлена, Интернет доступен. В дальнейшем вам придётся повторять шаги a,b,d,e для подключения к Интернету.
Отключиться можно командой ifdown ppp0, при повторном подключении без перезагрузки - повторите шаги d и e.
Примечание 1: всё вышеперечисленное, разумеется, запускается из-под root. Настройте sudo (/etc/sudoers), чтобы иметь возможность подключаться непривилегированным пользователем.
Примечание 2: если только у вас не безлимитный план, позаботьтесь об учёте трафика и мерах по автоматическому отключению связи, если необходимо. Я использую для таких целей ipcad (о его настройке - в отдельной статье).
Все комментарии, пожелания, указания на неточности и т.п. принимаются и приветствуются.
| Вложение | Размер |
|---|---|
| br2684ctl-20040226-alt1.i586.rpm | 8.61 КБ |
Статьи, посвящённые системам управления содержимым - настройки, вопросы работы, маленькие хитрости (Drupal, TextPattern и другие).

Чем интересна хостинг-компания Aiso.net? Наверное, в первую очередь тем, что всю энергию для датацентров получает от естественных источников — например, солнечных батарей. Понятно, что и в этом случае необходимо использовать аккумуляторы, и что само по себе использование даровой энергии не является защитой окружающей среды, но само по себе это интересно.
Однако не это понравилось мне, а тот факт, что Aiso.net предоставляет, среди прочего, услуги CDN, сети доставки контента. Как я уже писал в предыдущей заметке, идея «статического блога» мне понравилась настолько, что я всерьёз делаю двигатель и/или модули для тех CMS, с которых не планирую переходить, чтобы реализовать идею статического блога на основе CDN.
Почему я так тщательно взялся за эту мысль? Всё те же идеи: быстрая доставка контента и низкая цена этого процесса. Меньше платить за лучшее качество. Парадокс? Отнюдь нет.
Как выглядит процесс хостинга в общем случае, с использованием традиционных технологий?
Очень просто. Вы находите хостинг, устанавливаете двигатель для ведения блога (или иного интерактивного ресурса), после чего настраиваете двигатель.... и так далее, в справочнике блогороба об этом если ещё не сказано, то скоро будет. Вопрос в том, что делать, когда популярность блога растёт или, что того хуже, вы решаете завести несколько блогов?
Истина в том, вчитайтесь внимательно, что для ведения даже активного блога практически нет нужды в подлинно динамическом контенте, т.е. не нужно именно то, что вынуждает вас приобретать более «толстый» хостинг по мере того, как блог набирает обороты. Потому что на каждый чих, на каждую загрузку страницы двигатель бодро работает, исполняются мегабайты PHP-кода, тратится память и процессорное время. А на самом деле, ровно всего того же самого можно достичь, используя старые добрые чисто статические страницы.
Неубедительно? Я сказал слишком мало? На самом деле, я сказал слишком много, и вновь вернусь к этой теме, только когда у меня под руками будет продукт, демонстрирующий этот подход. И проверять его начну, само собой, на своих ресурсах.
И вот первый из тех, на котором я уже испытываю упомянутую технологию: Библиотека в облаках, куда я, к слову, постепенно переношу все свои книги, статьи, документацию и руководства. Вообще всё, что написал или собираюсь написать.
А пока вновь советую изучить сайт упомянутого в самом начале провайдера. Там можете найти много интересного, и не только в связи с охраной окружающей среды.
Статьи, посвящённые CMS Drupal. Установка, настройка, тонкости экплуатации.
В тяжёлое время живём, товарищи. Мало нам было спама в комментариях от программ, так стали ещё появляться т.н. платные комментаторы. И почувствовал я себя как в родном одна тысяча девятьсот девяносто восьмом году....
Переезд сайтов (в основном на Drupal) на выделенный сервер таки состоялся. На "разделённом" (shared) хостинге провайдер всё чаще и настойчивее намекал, что нагрузка на сервер от моих сайтов слишком высока и надо что-то делать.
Далее немного технических подробностей. Могут пригодиться тем, кто собирается создать свой сайт, которому в перспективе грозит высокая посещаемость. Знатокам это может быть малоинтересно, просьба не смеяться.
Нынешняя "железная база": P4 2GHz, 1 Gb RAM (DDR2), SATA HDD. Среда обитания сайтов:
ОС: CentOS 5.3
httpd: nginx (FastCGI: spawn-fcgi)
PHP: 5.3 + eaccelerator, "ручная сборка", всё ненужное не включено.
MySQL 5
memcached
Drupal: последняя версия старшей версии 6, штатный кэш включен, memcache включен
Ежедневно создаётся минимум одна полная архивная копия каждой базы данных и сохраняется в шифрованном виде на трёх ресурсах резервного копирования (один из них Amazon S3). Ежедневно создаётся минимум одна полная архивная копия файловой базы сайтов, точно так же копируется на резервные хранилища.
Точные версии по некоторым соображениям не указываю, равно как и критерии, по которым брандмауэр временно отсекает слишком активных "посетителей".
Установленный по умолчанию Apache 2.2 уже вечером первого дня работы сайтов умер сам и утащил в перезагрузку сервер, не выдержав "атаки ботов" (поисковые системы, похоже, с радостью бросились индексировать сайты на новом месте). После работы в связке nginx+Apache пришла в голову простая идея удалить из связки Apache вообще.
В настоящий момент конфигурация выдерживает до 35 обращений к страницам в секунду (средний вес страницы 70 кил) и можно, наконец, дышать спокойнее и вернуться к литературе.
Указанные подробности приведены в первую очередь для тех, кто планирует переводить свои сайты на автономное плавание (DS/VDS), осознавая все вытекающие последствия.
Подробное, пошаговое руководство по созданию оптимальной среды для блога на DS/VDS я дам в соответствующей статье ИНФОфики.
Пока что грубая оценка. Для блога на Wordpress, владелец которого ожидает до 50000 посетителей в сутки, достаточна будет следующая конфигурация VDS: RAM 256Mb, CPU минимум 800MHz. Стоить такой хостинг будет, если потратить некоторое время на поиски, не более 240 рублей в месяц. Мне лично удалось найти всего за 150.
Если вам уже сейчас интересны подробности, как именно настроить такую конфигурацию, пишите.
О том, что такое "dofollow', говорилось во многих местах, в том числе на странице списка русскоязычных dofollow-блогов. Поскольку в Друпале по умолчанию во всех гостевых комментариях стоит атрибут rel="nofollow", имеет смысл пояснить, как именно включается режим «dofollow».
Режим отображения этого атрибута можно изменить, определив функцию themeid_username() т поместив её в файл template.php в каталоге используемой вами темы оформления.
Узнать, какую темы вы используете, вы можете, или посмотрев в исходный код страницы (там часто указано имя темы), или открыв меню «Администрирование» -> «Конструкция сайта» -> «Темы оформления».
Теперь файловым менеджером или иным удобным способом откройте каталог (папку) themes/themeid, где themeid — идентификатор (имя) темы (пишется латинскими буквами. цифрами и знаком подчёркивания). Убедиться, что вы используете точный идентификатор темы можно, открыв файл с расширением .info, находящийся в каталоге с файлами темы.
Если в каталоге нет файла template.php, создайте его (не забудьте про <?php в начале файла). Если есть, скопируйте туда следующий код, заменив themeid идентификатором используемой вами темы:
function themeid_username($object) {
if ($object->uid && $object->name) {
if (drupal_strlen($object->name) > 20) {
$name = drupal_substr($object->name, 0, 15) .'...';
}
else {
$name = $object->name;
}
if (user_access('access user profiles')) {
$output = l($name, 'user/'. $object->uid, array(
'attributes' => array('title' => t('View user profile.'))
));
}
else {
$output = check_plain($name);
}
}
else if ($object->name) {
if (!empty($object->homepage)) {
$output = l($object->name, $object->homepage, array(
'attributes' => array(
'rel' => 'external')
)
);
}
else {
$output = check_plain($object->name);
}
// $output .= ' ('. t('not verified') .')';
}
else {
$output = variable_get('anonymous', t('Anonymous'));
}
return $output;
}
Там, где стоит строка 'external', код из ядра Друпала ставит по умолчанию 'nofollow'. В нашем случае все ссылки будут отмечены атрибутом rel="external". Если это также излишне, удалите или закомментируйте эту строку в коде выше. Код функции основан на фрагменте, скопированном непосредственно из ядра Друпала 6 и переопределяет логику отображения имён анонимных комментаторов и ссылок в заголовках их комментариях (это документированный способ, именно так и надо переопределять отображение).
Сохраните файл, убедитесь, при помощи команды
$ php -l template.php
что файл не содержит синтаксических ошибок, и сбросьте реестр тем, очистив кэш (если вы его используете), в меню «Администрирование» -> «Настройки сайта» -> «Производительность»
Всё, dofollow работает. Не забудьте только устраивать подобную модификацию всякий раз, когда обновляете тему или используете другую.
Система управления контентом (Content Management System, CMS) Drupal — один из популярных двигателей Web-приложений, обладающая рядом особенностей, среди которых следует отметить следующие:
— модульность: новая функциональность добавляется созданием т.н. модулей, позволяющих дополнить базовые возможности двигателя любой новой
— интернационализация: есть возможность не только переводить интерфейс на произвольные языки, но и создавать мультиязычные версии меню, одного и того же документа
— развитый API: существует подробная документация по разработке новых модулей, тем оформления и прочих возможностей расширения функциональности
— темы оформления: логика приложения в Drupal отделена от логики представления (того, как это будет видно в браузере); вам не нужно, как в некоторых популярных двигателях, постоянно вносить правки непосредственно в тему оформления — отсюда меньше путаницы и трудно преодолимых сбоев
— универсальность: грамотным выбором модулей Drupal становится годным для практически любого класса приложений, от крупного новостного портала (пример: Internet.ru) до частного блога, от социальной сети (пример: Grabr) до фотогалереи — всё, что вы можете придумать из популярных ныне классов сайтов, может быть реализовано на Drupal
Чем Drupal полезен именно для блогера?
— лёгкость установки (то, чему посвящён этот документ)
— возможность добавлять произвольное количество новых сайтов на основе уже существующей базы кода (файлов двигателя) и администрирования их из единого места
— поддержка RSS и агрегации сторонних источников в ленту RSS (вы можете читать RSS ленты любого количества сайтов, не покидая собственного сайта, сделанного на на Drupal)
— встроенная категоризация документов: вы можете поддерживать категории произвольной сложности иерархии, а также назначать произвольные теги (ассоциативные метки)
— возможность разделения доступа к разным категориям документов на основе т.н. ролей
Всё остальное проще увидеть самому, нежели долго и скучно описывать. Добавлю ещё, что Drupal написан в расчёте на создание очень посещаемых сайтов, а его разработчики крайне оперативно выпускают обновления важных модулей системы в случае, если найден сбой, угроза безопасности и т.д.
Предполагается, что читающий настоящее руководство умеет распаковывать архивные файлы с расширением .tar.gz, владеет способом редактировать текстовые файлы и эффективно переносить их на внешний сервер (я лично предпочитаю SCP, но и FTP вполне годится).
Вам потребуется хостинг с поддержкой
— PHP 5 (хотя поддерживается и архаичный уже PHP 4, крайне рекомендуется именно пятая версия PHP, желательно 5.2 или старше)
— системой управления базами данных MySQL (4.1, 5.0 или выше) или PostgreSQL (7.4 или выше)
Чаще всего блогеры используют MySQL, поэтому предположим, что у вас есть хостинг с поддержкой PHP и MySQL — тип операционной системы на нём значения в нашем случае не имеет, но, если особо не оговорено, я предполагаю, что сайт будет работать под управлением Un*x-подобной ОС и Web-сервера Apache.
Итак, у вас должны быть: созданная база данных (т.е., вы знаете имя сервера, где эта БД располагается, имя базы данных, имя и пароль пользователя базы данных), а также способ залить файлы установочного комплекта (дистрибутива) Drupal на ваш будущий сайт.
Если у вас есть затруднения по обеспечению любого из упомянутых шагов выше — я намерен, при наличии пожеланий, описать и эти шаги более подробно.
Теперь мы готовы. Самое простое — взять дистрибутив Drupal с официального сайта (в настоящий момент последним из рекомендуемых является Drupal 6.11), распаковать его (прямо на будущем сайте или же распаковать на своём компьютере и перенести файлы на сайт), но у этого подхода есть ряд недостатков:
— там будут только базовые модули, а блогеру могут пригодиться некоторые дополнительные
— и установщик сайта и сам сайт будут на английском языке, и впоследствии потребуется относительно скучная работа по добавлению поддержки русского языка
Поэтому вначале подготовим дистрибутив в том виде, в котором мы его загрузим: это позволит получить сразу сайт на русском языке и подключить все необходимые для его эффективного использования модули.
Скачаем дистрибутив Drupal с официального сайта (см. ссылку выше) во вновь созданную папку (каталог) на вашем компьютере и распакуем её. При этом создастся каталог drupal-6.11 (предполагаем, что мы ставим именно версию 6.11, для других версий имя каталога будет иным).
Теперь добавим в исходную комплектацию некоторые очень полезные модули, взять которые можно по приведённым ниже ссылкам:
archive (последняя версия 6.x 1.3) — для отображения архивов документов, с удобной визуализацией в виде календаря
atom (последняя версия 6.x-1.0) — для поддержки формата RSS Atom
calendar (последняя версия 6.x-2.1) — в сочетании с модулем Views позволяет представлять любую дату в календарном формате, удобно в т.ч. для навигации
captcha (последняя версия 6.x-1.0-rc2) — основной инструмент противодействия спаму
cck (последняя версия 6.x-2.2) — если вам потребуются новые типы документов (например, если вы создаёте магазин, хранилище ссылок или статей и т.д.), это позволит создать новые типы документов быстро и изящно
date (последняя версия 6.x-2.1 ) — в сочетании с модулем Views позволяет представлять любую дату в "человеческом представлении, удобно в т.ч. для навигации и отображения данных
dhtml_menu (последняя версия 6.x-3.4 ) — позволяет быстро и красиво перемещаться по сложным иерархическим меню, не загружая каждый раз новую страницу с сервера
domain (последняя версия 6.x-2.0-rc6) — если вы установили несколько сайтов на основе единой физической базы кода и в одной и той же БД, модули из этого компелкта позволят управлять всеми такими сайтами из единого командного центра
i18n (последняя версия 6.x-1.0) — предоставляет возможность перевода контента и выбора языка представления того или иного документа
l10n_client (последняя версия 6.x-1.7) — модуль, позволяющий переводить оставшиеся не переведёнными сообщения сайта легко и удобно, на лету
messaging (последняя версия 6.x-2.0) — позволяет расширить перечень способов уведомлять пользователей и владельца сайта о тех или иных событиях — электронная почта, SMS, Twitter и так далее (для конкретных новых способов может потребоваться установка дополнительных модулей)
multiping (последняя версия 6.x-1.x-dev) — позволяет уведомлять аткие сервисы как Pingoat о новинках на вашем сайте
mollom (последняя версия 6.x-1.7) — ещё один способ противодействия спаму, на основе внешнего сервиса Mollom
nodewords (последняя версия 6.x-1.0) — способ задавать META теги в заголовках документах, как для заглавной страницы, так и для любой иной индивидуально
notify (последняя версия 6.x-1.0 ) — настройка уведомлений о тех или иных событиях (новые документы, комментарии и т.д.)
pathauto (последняя версия 6.x-1.1) — возможность автоматически назначать документам ссылки по множеству схем — с указанием, например, даты и заголовка в ссылке
print (последняя версия 6.x-1.6) — возможность создавать удобные версии для печати того или иного документа
site_map (последняя версия 6.x-1.0) — возможность генерировать карту сайта для посетителей вашего сайта — все меню раскрыты, все иерархические структуры перечислены и т.д.
spamspan (последняя версия 6.x-1.3) — удобно, чтобы смело писать адреса email прямо в тексте документа, не опасаясь, что спам-боты подберут его
tagadelic (последняя версия 6.x-1.2) — удобный способ рисовать облако ассоциативных меток
taxonomy_access (последняя версия 6.x-1.x-dev) — способ управлять доступом к тем или иным категориям документов для тех или иных ролей пользователей
token (последняя версия 6.x-1.1) — модуль, предоставляющий те или иные макроимена для свойств документа, необходим для pathauto
trackback (последняя версия 6.x-1.1 ) — поддержка трэкбэков, автоматического уведомления стороннего сайта о новом содержимом
views (последняя версия 6.x-2.5) — если вам потребуется создать новое представление данных (сделать, например, выборку только материала конкретного типа из конкретных категорий и нужным образом отобразить), этот модуль позволит всё сделать крайне быстро и эффективно
xmlsitemap (рекомендуемая версия 6.x-0.x-dev) — генератор XML карты сайта для поисковых служб, чтобы те могли индексировать сайт быстро и эффективно
Всё скачанное распаковываем в папке modules — она создалась, когда мы распаковали дистрибутив самого Drupal.
Распаковали — при этом каждый модуль создаёт новую папку с соответствующим именем. Перевели дух. Всё? Нет, теперь займёмся переводом на русский язык.
Drupal, начиная со старшей версии 6, поддерживает автоматизированный перевод: достаточно положить файлы, содержащие переведённые строки (в правильном формате) в правильное место, и при установке соответствующей компоненты нужный язык будет введён в строй автоматически.
Чтобы подготовить весь комплект переводов, идём на сайт Drupaler (честь и хвала энтузиастам, активно поддерживающим перевод Drupal на многие языки) и переходим на страницу загрузки переводов на русский язык.
Теперь вводим в поле поиска, поочерёдно, имя каждого дополнительного модуля, а также строку 'drupal' (без кавычек). Выбираем соответствующую версию, когда предложат, тип: перевод, формат пакетов Drupal 6.x для модуля autolocale (выбрано по умолчанию), нажимаем "Экспортировать".
Сохраняем прибывший файл, затем открываем (в случае модулей) одноимённый каталог в каталоге modules и распаковываем файл с файлами перевода туда. Т.е., если мы, к примеру, скачали файл переводов для модуля domain,то распаковать полученный архив нужно в папке modules/domain.
Переводы для самого Drupal следует распаковать в той папке, куда распаковали сам дистрибутив.
Всё. Теперь можно вновь упаковать полученный, дополненный модулями и переводами дистрибутив, перенести файл на ваш сервер и там распаковать. Ну или закачать по файлам при помощи FTP, хотя это существенно дольше.
Но перед этим сделаем ещё несколько действий, чтобы сэкономить время на их выполнение уже на серере.
В папке sites/default (по отношению к корневой папке, куда распаковали дистрибутив) есть файл default.settings.php. Скопируем его в settings.php (не переименуем! исходный файл лучше оставить нетронутым) в той же папке.
В папке modules/pathauto есть файл i18n-ascii.example.txt — переименуем его или скопируем в файл i18n-ascii.txt
Вот теперь всё, можно переносить на сервер.
Итак, всё подготовлено, закачано, база данных создана. После того, как вы перенесли все файлы на сервер, необходимо ещё сделать вот что: войти в каталог sites, в нём — в каталог default и дать файлу settings.php права на запись для сервера. В случае, если PHP установлен как модуль Apache, обычно необходимо назначить права 0666, если установлен как CGI — права 0644. Также дайте права на запись для самого каталога sites/default (0777 и 0755, соответственно).
Что теперь? Теперь, если вы готовили хостинг для домена example.com, и всё уже настроено (DNS записи указывают на сервер, куда перенесли дистрибутив Drupal), наберите адрес
http://example.com/install.php
(замените example.com на имя вашего домена)
Выберите русский язык на первом шаге и просто ответьте на очевидные вопросы на последующих.
В среднем процесс установки занимает 2-3 минуты, если дистрибутив уже на месте и БД готова. Вам нужно будет указать параметры подключения к БД, выбрать имя администратора, его пароль и email, название сайта. И всё. Верьте или нет, но сайт для блогера готов и можно его заполнять.
Но как же эта процедура сборки комплекта модулей и переводов, спросите вы? Ответ прост: вам надо проделать её только раз. Потом, по мере выхода новых версий модулей, или при необходимости добавления новых, вы будете повторять операцию только для конкретного модуля и его файлов перевода. Это намного менее трудоёмкий процесс и делается лишь изредка, обычно 1-2 раза в месяц. А добавление нового сайта на основе того же физически дистрибутива — ещё 2-3 минуты работы на каждый новый сайт (при этом у сайта может быть своё оформление и свой комплект модулей, если так будет нужно). О том, как это сделать — в одной из следующих публикаций.
В случае, если вы не боитесь скачивать файлы установки из сторонних источников, вот вечнодействующая ссылка на последнюю версию Drupal 6, со всеми перечисленными модулями, в архиве, который нужно распаковать непосредственно в корневую папку вашего сайта (в ту, на которую ссылается главная страница) по вот этому адресу с моего сайта:
http://dev.boyandin.ru/distr/drupal-6-latest-with-modules-ru.tar.gz
Я стараюсь вносить в него изменения максимально оперативно, в течение 1-2 дней по выходу нового модуля или версии Drupal.
Установка сайта — полдела. Drupal — сложный инструмент и главное — правильно всё настроить. В последующих статьях я расскажу про то, как быстро и оптимально настроить ваш сайт на Drupal так, чтобы вы могли использовать ваш блог по прямому назначению ещё 20 минут спустя после установки.
Предвижу ряд возможных откликов и сразу предваряю их коментариями.
1. Drupal слишком тяжёл и не подходит для обычного блога.
Ответ: всё дело в настройках. Drupal - универсальная система и требует точной настройки. Он не имеет основного, профильного использования и начальные параметры настройки предоставляют некоторую усреднённую функциональность.
Основной ошибкой начинающих пользователей Drupal является то, что они включают все показавшиеся полезными модули, и, не читая советов и руководств, пытаются получить сразу всё. Итогом становится медленная работа двигателя и чрезмерная нагрузка на сервер.
2. Drupal слишком сложен в постижении.
Глаза боятся, руки делают. Интерфейс Drupal не везде представляется самым логичным, но при желании разобраться в нём, да при наличии множества свободно доступных руководств, это всегда можно делать. Drupal не настолько запутан, просто к располоежнию управляющих элементов требуется привыкнуть.
Если у вас нет планов, помимо создания "обычного блога" и вас не интересует тонкая оптимизация системы, возможность интегрировать её с другими службами, если вам не нужна универсальность - вам не стоит изучать Drupal или иные универсальные двигатели. Возьмите что-то "стандартное", созданное для вашего случая.
3. Вы предлагаете включить в дистрибутив для блогера кучу ненужных модулей (CCK, Views, Taxonomy access).
Основное достоинство Drupal в том, что если конкретная странциа не пользуется данным модулем, модуль не бует загружаться, требовать какие-то ресурсы и тем самымувеличивать нагрузку на систему. МОдули используются там и тогда, где и когда нужны. Отключенные модули вообще не принимаются двигателем во внимание и ничего, кроме дискового пространства (и неиспользуемых таблиц в БД, если модули уже включались, работали и требовали БД), не отнимают.
В списке выше указаны модули, которые могут оказаться полезными при решении типичных задач работы с блогом, это обобщение не только моего личного опыта. Если конкретный модуль вам в вашей конкретной задаче не нужен - просто не включайте его. Если считаете, что и не будет нужен -удалите его из каталога modules, и всё.
Drupal.org, официальный сайт на английском языке
Drupal.ru, сайт русскоязычного сообщества пользователей
Drupaler.ru , репозиторий переводов Drupal на различные языки — помогите и вы перевести оставшееся не переведённым
-------
Анонсы этой статьи: sloger.net blogistica.ru blogparad.ru grabr.ru
В предыдущем выпуске рассказывалось, как скомпоновать дистрибутив CMS Drupal (далее Друпал) в вид, пригодный для максимально оперативной установки. Просьба обратить внимание, что и версия самого Друпала, и версии модулей могли значительно измениться - просьба проследовать на страницы, с которых можно скачать модули, и взять там последние версии, или скачать файл drupal-6-latest-with-modules-ru.tar.gz (5.3Мб) и распаковать его в каталог, где находится стартовая страница сайта (Web root directory).
Предполагается, что читатель этого руководства
В тексте далее я предполагаю, что к данному моменту пользователь
Строкой <root> в дальнейшем будем обозначать каталог (папку), в которую распаковали дистрибутив Друпала.
Важно: этот документ одинаково информативен как при наличии иллюстраций шагов установки, так и без них.
Далее возможны варианты.
1. Установка Друпал с указанием подключения к БД
Перед тем, как начать установку: если это первый ваш сайт на данном дистрибутиве, то двльнейшие действия производятся в каталоге "<root>/sites/default"; если вы создаёте ещё один сайт на той же самой установке Друпала (Друпал позволяет создавать произвольное количество сайтов на основе одной и той же установки), то выполните следующие действия (далее предполагаю, что имя домена вновь создаваемого сайта example.com):
Теперь откройте страницу
http://example.com/index.php
(не забудьте поставить подлинное имя вашего домена) и установка начнётся. Если вы увидите какие-либо сообщения об ошибках, исправьте их, прежде чем продолжить. На первом шаге вам предложат выбрать язык установки. Выбирайте русский, и нажимайте на кнопку "Select language".

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

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

Следующий этап - ввод названия сайта, адреса электронной почты, от имени которого будут рассылаться технические письма и уведомления, и создание первой учётной записи. Внимание: первая учётная запись в Друпал - аналог суперпользователя (root в Un*x, Administrator в Windows). Ни при каких обстоятельствах не используйте эту учётную запись для повседневной работы, взамен созадйте другую учётную запись и дайте ей все полномочия, какие необходимо (об этом позже).

Подходите ответственно к заданию имени и пароля для суперпользователя. На этом же экране вы увидите, поддерживает ли ваша установка т.е. "чистые ссылки" - красиво выглядящие адреса, не содержащие знаков '?' и '&'. Иногда их ещё называют "ЧПУ" (это сокращение должно быть знакомо пользователям Wordpress).
Там же вы увидите задание часового пояса сервера по умолчанию (установите так, как удобнее - обычно имеет смысл установить ваш собственный пояс и опция автоматической проверки наличия обновлений для ядра Друпала, дополнительных модулей и тем оформления.
Я настоятельно рекомендую оставить эту опцию включенной. Обновления в данной старшей версии Друпала не происходят автоматически, вас будут только уведомлять. Разработчики самого Друпала и наиболее популярных модулей делают всё, чтобы уведомлять о важных обновлениях как можно более оперативно. Обычно на эти сигналы следует обращать самое пристальное внимание.

Вновь нажимаете на "Сохранить и продолжить" и, если только не случилось чего-нибудь крайне странного, установка Друпал закончится.

В данный момент вы располагаете полностью функциональным сайтом. К сожалению, вы работаете из-под имени суперпользователя (помните предупреждение?), и большинство полезных функций отключены. Что делать дальше, мы рассмотрим сразу после описания второго, "упрощённого" способа установки Друпал в уже существующую базу данных.
1. Установка Друпал с использованием существующих настроек БД
При установке по этой схеме мы используем уже настроенное подключение к БД. Иными словами, мы возьмём файл настроек для уже установленного сайта Друпал на той же физической установке (том же комплекте файлов). Это удобно, когда вы ставите второй и так далее сайт на ту же физически установку. Расходы усилий минимальны: всё, что потребуется - создать новый каталог для хранения файла настроек и данных, специфических для нового сайта - загруженных файлов, настроек тем и т.д.).
Проделайте следующие действия:
Теперь откройте в редакторе скопированный файл <root>/sites/example.com/settings.php и найдите в нём примерно такую строку:
$db_prefix = '';
Задайте другой префикс (см. выше) и сохраните файл. После этого откройте следующий адрес:
http://example.com/install.php
После этого установка пройдёт примерно так же, как и в первом случае. нон е будет шага настройки подключения к БД.
Итак, установка в её начальном виде завершена. Теперь следует произвести несколько важных настроек: установить модули, параметры сайта, защиту от спама и так далее. Если вы посмотрите на экран, то увидите, что именно вам сейчас рекомендуется сделать.

Начнём с установки модулей. Нажмите на пункт навигационного меню "Управление", далее "Конструкция сайта" (или сразу отыщите в открывшемся списке всех возможных действий справа от меню ссылку "Модули". Нажмите на "Модули".

Модули - то, что придаёт Друпалу гибкость. Вы увидите большой список модулей; не следует ставить все подряд из соображений "могут пригодиться" - это один из верных способов превратить ваш сайт в медленное и ресурсоёмкое чудовище.
Ниже приводится список модулей, которые я бы советовал устанавливать блогеру (часть этих модулей уже установлена; я перечисляю их в том порядке, в котором они видны при прокрутке страницы):
Archive: позволяет создать окно навигации по архивам записей - с возможностью поиска по годам и месяцам.
Aggregator: позволяет импортировать сторонние ленты RSS/Atom для чтения и дальнейшего преобразования их на сайте.
Blog: то, что позволяет писать блоги, поддержка формата блога.
Color: позволяет менять раскраску тем оформления.
Comment: позволяет оставлять комментарии к докментам, а также следить за действиями (активностью) пользователей.
Contact: позволяет добавить форму обратной связи, чтобы отправлять электронные письма на заранее заданные адреса (можно создать произвольные комбинации адресов, на которые отправлять сообщения по тому или иному поводу)
Content translation: поддержка перевода интерфейса и прочего содержимого на другие языки
Database logging: удобно при посике разного рода проблем, хранит сообщения о тех или иных событиях, включая системные ошибки, в специальном журнале - администратор может задать, как долго сохраняются там записи, а также просматривать журнал в любой момент.
Help: позволяет использовать контекстную подсказку.
Locale: поддержка языков, отличных от английского.
Menu: позволяет настраивать меню на сайте.
OpenID: позволяет подключить, после создания, несколько OpenId к учётной записи, для упрощения процедуры авторизации.
Path: позволяет переименовывать внутренние ссылки (в т.ч. создавать те самые чистые ссылки, ЧПУ)
PHP Filter: позволяет использовать непосредственно на страницах код PHP. Внимание: крайне опасная при неосторожном обращении вещь. Если не планируете на самом деле исполнять PHP код, не включайте.
Ping: уведомляет т.н. пинг-сервисы о новых материалах на сайте (чтобы те могли в т.ч. побудить поисковые системы заглянуть на сайт и прочесть новый материал). Как только закончат разрабатывать Multiping, я буду рекомендовать его взамен.
Profile: позволяет добавлять в профиль пользователей новые поля.
Search: встроенный поисковый двигатель в пределах сайта.
Statistics: ведёт статистику доступа к сайту.
Syslog: регистрирует события и записывает в системный журнал.
Taxonomy: позволяет использовать категоризацию материалов, включая свободно назначаемые метки (теги)
Tracker: позволяет пользователям следить за изменениями на сайте.
Trigger: позволяет инициировать те или иные действия в ответ на то или иное событие (например, создание или правку материала)
Update status: автоматически следит за наличием обновлений для модулей и тем, если те поддерживают такую возможность. Очень не советую отключать.
Upload: позволяет прицеплять файлы к документам. Если не собираетесь прицеплять, не включайте.
Spamspan: позволяет защищать адреса электронной почты в документах. Если этот фильтр активен, то адреса преобразуются в нераспознаваемую большинством спам-ботов форму.
Notify: позволяет рассылать уведомления о тех или иных изменениях на сайте
Messaging, Messaging PHP Mailer: возможность отпарвлять уведомления и системные сообщения при помощи электронной почты. PHPMailer - специальный класс, позволяющий удобно составлять и отправлять разными способами электронные письма.
Block translation, Content type translation, Internationalization, Menu translation, Profile translation, String translation, Synchronize translations, Taxonomy translation: этот комплект позволяет переводить те или иные части системы на другие языки, а также создавать многоязычные версии одних и тех же сущностей.
Printer-friendly pages (core), Send by email: возможность видеть страницы в оптимальном для принтера виде, а также пересылать их электронной почтой (надоедать друзьям, показывая им интересные страницы прямо в почте).)
CAPTCHA, Text CAPTCHA: одиозный и малополезный, с точки зрения одних, но во многом помогающий от потока спама модуль. Я не использую графические капчи, мне лично хватает текстовых (арифметическая задача или выбор строки из множества строк).
Atom: возможность поставлять RSS каналы в формате Atom.
Tagadelic: поддержка "облака меток" - представление списка категорий в виде "облака", где самая популярная категория рисуется более крупным шрифтом.
XML Sitemap, XML Sitemap Engines, XML Sitemap Node: позволяет предоставлять т.н. карту сайта для поисковых машин, Sitemap. Если передать эту карту, а такие инструменты есть для Яндекса и для Google, то индексирование страниц сайта пройдёт много эффективнее.
DHTML Menu: по умолчанию, многие меню в блоке навигации иерархические. Если не ставить этот модуль. то придётся несколько раз перезагружать страницу. чтобы добраться до нужной иерархии. Этот модуль экономит время и ресурсы, открывая сложные иерархии достаточно грациозно и красиво.
Meta tags: позволяет назначать каждому документу свои мета-теги (метки и описание как минимум), в т.ч. специальные теги для головной страницы сайта.
Path auto: позволяет создавать чистые ссылки нужного формата.
Sitemap: строит сводную карту сайта, для людей (ранее упоминавшаяся - для поисковых машин).
Token, Token actions: поддержка макро-элементов и действий для них, необходима для Pathauto.
Trackback: поддержка обратных уведомлений (трекбэков) стороннего сайта об изменениях на данном.
Перевели дух? Нажимаем кнопку "Сохранить" и смотрим за процессом установки модулей и импорта переводов. Вас могут предупредить, что для выбранного вами списка модулей есть необходимость включить другие модули. Соглашайтесь - большого выбора всё равно нет.

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

Я бы советовал пойти и настроить дату. Меню: "Управление" - "Настройка сайта".

Если вы указали поддержку экспорта страниц в PDF, не забудьте посетить страницу настройки этой функции.

Прежде, чем настраивать роли, вкратце поясню, что это такое. Друпал использует систему управления доступом к тем или иным данным и возможностям на основании т.н. ролей. Можно рассматривать это как группы в операционных системах - участие в той или иной группе даёт те или иные полномочия. Есть две встроенные роли: анонимные (неавторизованные, не представившиеся системе) пользователи и авторизованные пользователи. Все прочие роли нужно создавать.
Роли удобны для "точечного" назначения прав в тех случаях, когда не хочется, чтобы все до единого авторизованные пользователи умели исполнять те или иные действия. Скажем, вы можете создать роль "Блогеры" и дать ей право создавать, править и удалять записи в блоге. Не нужно добавлять что-то ещё - права ролей суммируются (если одна из ролей, к которым отнесён пользователь, имеет некие полномочия, а другие роли такоих полномочий не имеют - пользователь будет иметь все полномочия этой роли. Поэтому не стоит повторять то, что уже умеет авторизованный пользователь.
В нашем примере мы создадим административную роль, которая может всё, создадим нового пользователя, которого произведём таким образом в администраторы, и перестанем, наконец, использовать суперпользователя.
Меню: "Управление" - "Управление пользователями" - "Роли".

В поле слева от "добавить роль" вводим имя новой роли. Можно вводить что хотите, я обычно пишу что-то вроде "Administrator". После того, как роль добавлена, назначим ей полномочия.
Меню: "Управление" - "Управление пользователями" - "Разрешения".

В этом поле помечаем все до единой галочки для роли "Administrator" (или как вы её хотите назвать). Сохраняем изменения.
Теперь делаем то, что многие делают первым: запретим пока что регистрироваться всем желающим на нашем сайте. Меню: "Управление" - "Управление пользователями" - "Параметры регистрации". Выберем пункт, по которому только администратор может создавать учётные записи. Сохраняем изменения.

Теперь настроим анти-спам, CAPTCHA. Меню: "Управление" - "Управление пользователями" - "CAPTCHA".
Поскольку идентификаторы форм, которые можно защитить "тестом на человечность", так упрощённо переводится CAPTCHA, даны по-английски, поясню:
comment_form: форма отправки комментариев. Обязательно защитить, иначе спамеры в момент наводнят ваш сайт мусором.
comment_mail_page: форма отправки сообщений с сайта. Если позволяете анонимным пользователям отправлять вам сообщения (а надо позволять, иначе потеряете множество потенциальных партнёров), защитите. Иначе спамеры будут слать вам свои послания долго и с удовольствием.
comment_mail_user: то же, но для сообщений конкретному пользователю. Я обычно тоже защищаю.
user_login: форма входа (авторизации). Я обычно не защищаю: если спамер пробил прежний тест и смог зарегистрироваться, то и этот пробьёт. А нормальных людей это раздражает.
user_login_block: то же, но в блоке (обычно над блоком навигации). Не защищаю по той же причине.
user_pass: поле отправления забытого пароля. Обычно защищаю, чтобы меня не развлекали письмами о созданном новом пароле.
user_register: регистрация нового пользователя. Обычно защищаю.
Какую именно версию теста - графику, арифметику или выбор строки - вы выберете. не очень важно. Эффективность их сопоставима.
Если вам потребуется добавить тест CAPTCHA на любую другую форму, пометьте галочкой "Доабвить административную ссылку CAPCTHA на формы", сохраните, затем перейдите под именем с административными полномочиями на страницу с нужной формой и добавьте туда тест. Всё очень просто. Потом советую эту галочку снять, ибо ссылки с предложением поставить CAPTCHA вскоре начнут раздражать.
Теперь, когда CAPTCHA настроена, можно заняться счётчиками. Все любят показывать, сколько раз читали ту или иную страницу. Настроим эту возможность. Меню "Управление" - "Отчёты" - "Настройки журнала доступа".

Тут всё просто: помечаем включенным "Счётчик просмотра содержимого" и, если нас интересует ведение системных журналов - в том числе о разных ошибках и предупреждениях - пометим также "Включить журнал доступа". Внимание! Не ставьте слишком большой период хранения записей в журнале - база данных, особенно на посещаемом сайте, начнёт стремительно раздуваться. Теперь не забудьте вернуться в "Разрешения" и убедиться, что и анонимным, и авторизованным пользователям позволено видеть счётчики.

И, наконец, синонимы. Те самые красивые ссылки. Меню "Управление" - "Конструкция сайта" - "Синонимы" - "Настройка автоматических синонимов".

Здесь я советую произвести следующие действия:
Основные настройки: Действия при обновлении: Ничего не делать. Оставить старый синоним нетронутым.
Основные настройки: Транслитерировать перед созданием синонима - пометить, не то все ссылки начнут быть с русскими буквами.
Настройки адреса блога: Шаблон для адресов страниц блогов: поставить
blog/[uid]И очистить поле внутреннего синонима ленты. И все аткие поля очистить, см. ниже - ни к чему плодить синонимы сверх меры.
[type]/[nid]/[title-raw](это породит красивые ссылки вида blog/42342/zagolovok-zapisi)
Дальше вам нужно войти на "Управление" - "Управление пользователями" - "Пользователи" и добавить нового пользователя вручную, не забыв включить его в роль администраторов. После этого выйти из системы и войти уже под именем нового пользователя.
Дальнейшие настройки - настройки темы, блоков, способов комментирования и так далее - это тема для следующих статей. По окончании того, что описано в этой, у вас есть достаточно защищённая система, уже готовая для ведения блога. Она относительно голая, нет ни облаков тегов, ни форм со счётчиками и списком комментариев. Всё это вы можете поискать сами - а можете подождать день и посетить ИНФОтеку, где в качестве службы скорой помощи будет краткая сводка. в какие пункты меню идти, чтобы произвести то или иное действие.

Блоги и динамический контент. Казалось бы, эти две сущности подразумевают друг друга. Как минимум, блоги означают динамический контент. Так ли это на самом деле?
На самом деле, не вполне. В любой конкретный момент большинство ресурсов, именуемых блогами, являются набором статических страниц. Никакой динамики там не нужно. В большинстве случаев нечему там обновляться в реальном времени, ну разве что вы большой любитель техники типа AJAX и желаете голосовать и пр. за тот или иной материал. Сама страница, контент, в большинстве случаев вполне статична.
Примерно из этого я исходил, когда продумывал, как и где хранить обширную коллекцию своих графических файлов, а также набор статей, книг и прочих публикаций. В конечном итоге выбор пал на AWS, Amazon Web Services. О них нынче не пишет только ленивый, поэтому я вкратце поясню, в каком контексте упомянуты блоги и чем AWS может оказаться полезным большинству блогеров.
AWS — достаточно необычный набор продуктов. Необычный уже тем, что с самого начала ориентируется на разработчиков, а не на «мышководов», конечных потребителей. Из всего семейства сервисов я выделю два, из которых платным является только один.
Amazon Simple Storage Service, он же S3, есть достаточно надёжный и дешёвый способ хранения статических данных. Если сравнивать с «обычными» видами хостинга, то, если говорить о надёжном и оправдавшем себя хостинге, никто не может побить S3 низкой ценой и надёжностью. Почему же его до сих пор не используют блогеры в качестве хостинга? Да потому что это — способ хранения статических данных. Никаких скриптов на стороне сервера. Что залили, то и скачаете. Один в один.
Amazon CloudFront (букв., «грозовой фронт») — второй сервис, использующий S3 в качестве хранилища данных. Это сеть доставки контента, она же CDN. Также далеко не новое изобретение. Для тех, кто не в курсе, что такое CDN: это методика доставки контента, оптимизированная по скорости и качеству связи. На практике это выглядит так: когда вы запрашиваете контент (документ, файл) через CDN, то искомое доставляется вам из того датацентра, который ближе к вам в смысле скорости и надёжности.
Если использовать CloudFront для доставки контента, то есть страниц, то одно приятное обстоятельство такое: вы не платите за саму услугу CDN. Платите только то, что взимает S3 за хранение и обмен данными. А тамошние тарифы очень, очень умеренны. Грубо говоря, для тех, кому лень считать: средней посещаемости блог, если весь его контент хранить на S3, встанет своему владельцу в сумму, мало отличающуюся от доллара в месяц.
Оценили возможности?
Основное достоинство CDN — высокая надёжность доставки контента. Вы не печалитесь касательно нагруженности сервера, на котором живёт ваш сайт. Вы не ломаете голову по поводу скорости связи: это тоже забота CDN. Наконец, S3 — это крайне надёжный в смысле сохранности данных сервис.
Естественно, возвращаемся к исходному вопросу: как обеспечить динамические элементы? Например, комментирование?
Ответ простой: активный контент на статических страницах. Иными словами, Java, JavaScript и всё такое. Комментарии, например, можно реализовать при помощи систем типа Disqus. Прчоие традиционные «навороты» аналогичными сервисами.
Да, встанет вопрос: чем создавать такие статические страницы? Готового решения, из серии нажал кнопку и загрузил, я с ходу назвать не могу. Сам я привык пользоваться несколькими достаточно быстро написанными скриптами, которые поддерживают всё, что нужно настоящему блогеру: шаблоны страниц, RSS, список недавних публикаций. При большой необходимости можно скооперироваться с кем-то, кто создаст приложение, обеспечивающее публикацию квазидинамического контента таким вот образом.
Вероятно, вы всё ещё задаётесь вопросом, к чему городить такой огород? А ответ простой, и он уже прозвучал. Вы не беспокоитесь о способе доставки, CDN это сделает за вас. Вы всего лишь копируете файлы, причём, при грамотно построенном процессе, вы сможете использовать «слабый» хостинг, или и вовсе домашний компьютер для поддержки своего ресурса.
Вас не будет волновать нагрузка, вам не придётся искать новый хостинг по мере роста популярности блога. Вы будете заниматься всё тем же: создавать контент. Всё остальное CDN возьмёт на себя.
Но даже если это покажется вам слишком радикальным для ведения именно блога, есть вполне уместное применение такого подхода: хранение редко изменяемого контента. Галерей картинок, коллекций софта, статей, книг и т.п.
Ваш покорный слуга уже принялся переносить свои собственные публикации на CloudFront, вот пример: Библиотека в облаках.
У CDN, конкретно у CloudFront, есть две не очень удобные особенности:
– вы не сможете заставить контент обновляться (на терминальных серверах, откуда они идут собственно посетителям) чаще, чем раз в 24 часа
– хотя вы можете привязать своё доменное имя к комплекту распределения (аналогу сайта в традиционном понимании), там нет поддержки имени индексного файла по умолчанию; иными словами, вы не увидите ничего хорошего в ответ на адрес вида http://domain.tld, нужно писать что-то вроде http://domain.tld/index.html (или как вам ещё захочется назвать стартовую страницу)
Однако для меня лично это не явилось непреодолимым препятствиям. В последующих публикациях я расскажу, для желающих, как настроить CDN CloudFront и какими инструментами удобно пользоваться для быстрого создания сайтов на основе CDN. В т.ч. тех самых статических, как ни парадоксально звучит, блогов.
Готовите презентацию? Любите смотреть кино? Проекторы, экраны, аксессуары и комплектующие — есть, из чего выбрать.
Формат блога идеален для личного дневника, анонсов, новостей и прочих записей, актуальных не слишком долгое время. Однако создавать статьи удобнее при помощи CMS, ориентированной изначально на рубрикацию, относительно редко изменяемый контент.
Очевидным кандидатом является Вики, например, Mediawiki (на нём работает Википедия). Но как быть с комментариями и обратной связью? Ниже я поясняю, как скрестить MediaWiki и сервис комментариев Disqus. Итогом скрещивания стала ИНФОвики, где отныне я и буду публиковать статьи и руководства.
Вопрос, который могут задать: зачем ставить именно Disqus, если у того же MediaWiki есть расширение, позволяющее добавлять комментарии? Причины минимум две:
- вы управляете лентами комментариев от Вики вместе с другими такими же лентами в едином командном центре на Disqus
- вас не так сильно будут беспокоить вопросы спама в комментариях, потому что ленты не видны поисковым роботам
Скрещивание не составляет большого труда. На странице установки кода Disqus:
где channel-name - идентификатор вашего канала (форума, ленты комментариев) Disqus, есть два фрагмента кода, первый и второй. Первый вписывается туда, где должны отображаться управляющие элементы Disqus. Второй - перед тегом </body>.
Изменения делаются в основном файле темы ("шкурки", skin) MediaWiki, они находятся в каталоге skins/ в каталоге, куда установлен Вики-двигатель.
Темой по умолчанию является MonoBook, её головной (управляющий) файл MonoBook.php. Ниже приведены краткие указания по тому, как вставить управляющий код Disqus в файл темы.
0a. Установите Mediawiki. Предполагается, что это не составит большого труда.
0b. Регистрируетесь на Disqus и создаёте канал (учётную запись сайта).
1. Перейдите в каталог skins/ и обязательно сделайте резервную копию головного файла темы (в нашем примере MonoBook.php).
2. Найдите в файле темы следующий вызов:
3. Вставьте после него следующий фрагмент:
не забыв заменить channel-name на подлинное имя вашего канала.
Пояснение: комментарии не будут отображаться, если установлен параметр action - иными словами, если выполняется действие, отличное от отображения страницы. Нам незачем комментарии на страницах редактирования и т.п.
4. Найдите тег </body> и перед ним вставьте второй блок кода:
не забыв заменить channel-name на подлинное имя вашего канала.
5. Открываете заглавную страницу вашей Вики и смотрите, появилось ли поле ввода комментариев. Если нет, вызовите главную страницу, нажмите на "править", и замените в адресной строке
на
и вызовите получившийся адрес для сброса кэша. После этого повторяете попытку.
Чтобы комментарии были и в других темах, в головном файле каждой темы произведите точно такие же изменения.
Замечания, комментарии, пожелания принимаются и приветствуются.
Формат блога идеален для личного дневника, анонсов, новостей. Однако вести статьи удобнее при помощи CMS, ориентированной изначально на рубрикацию, относительно редко изменяемый контент, например - Вики. В этой заметке я поясняю, на примере MediaWiki, ...

Типичная ситуация, с которой приходится сталкиваться: размещение на одной странице множества ссылок. Когда число ссылок, условно говоря, больше пятидесяти, могут начаться негативные последствия.
Поисковые службы могут начать считать страницу «собранием ссылок» (в русском сегменте используют иной, куда менее приятный термин). Обрамить ссылки так, чтобы не производилось их индексирования? Вес страницы в глазах того же Google всё равно пострадает — в связи с методикой вычисления PR, которым делится страница. Владельцев ресурсов, на которые указывают такие ссылки, тоже порой задевает запрет индексирования.
Один из вариантов — разместить ссылки в текстовом виде. Но тогда будет неудобно по ним переходить: не у каждого в браузере установлен модуль, превращающий такой текст в полноценную ссылку.
Задачу можно решить при помощи JavaScript. WordPress, Drupal и некоторые другие популярные CMS используют JavaScript-библиотеку jQuery, и решение поставленной задачи становится крайне простым.
Шаг 1. Поместите все ссылки, подлежащие преобразованию, в виде следующей разметки:
<span class="makelink">http://example.com</span>
или
<span class="makelink">http://example.com Имя сайта</span>
Шаг 2. В самом конце заметки поместите следующий блок кода
<script type="text/javascript">
$('span.makelink').each(function(index) {
var h = $(this).html(); var t = h;
var spos = h.indexOf(' ');
if (spos > 0) {
t = h.substring(1 + spos, h.length);
h = h.substring(0, spos);
}
$(this).html('<a href="'+h+'" target="external">'+t+'</a>');
});
</script>
(убедитесь, что разрешается вставка JavaScript-блока).
Всё. Сохраните и смотрите на результат. Пример такого трюка в действии см, например, на странице списка DoFollow блогов, F-R.
1. Вы можете использовать тег, отличный от span и класс, отличный от makelink, но тогда измените JavaScript-фрагмент соответственно.
2. Если через пробел после адреса ссылки идёт произвольный текст, именно он станет текстом анкора (рабочей ссылки). Если там только URL, он же и будет использован в качестве текста.
3. Если у вас не используется jQuery, установите, следуя инструкциям на сайте. Сокращённый вариант библиотеки занимает 70 килобайт, но этот файл статический и прекрасно кэшируется.
То, что подходит более чем к одной ОС.
Иногда необходимо напрочь отсечь самую возможность доступа к контенту с неких доменных имён. Это и рекламные блоки, и «жизнерадостные новости» от Life.ru (название более чем иронично).
Фильтры рекламы в браузерах работают нормально, но проще бывает зарезать возможность передачи ненужного контента на корню.
Для этого можно использовать простой и радикальный трюк: в файле hosts (расположен обычно в /etc в Un*x и в %WINDOWS%\system32\etc\drivers в Windows) для домена, подлежащего «занулению», добавляется строка вида
127.0.0.1 example.com
В качестве примера привожу (прицепленный к этой записи) файл hosts.txt, содержащий примеры таких записей, компиляция вашего покорного слуги и Линда Кайе.
Просто допишите его содержимое к вашему hosts для зануления всего того, что там перечислено. В основном это реклама и порносайты.
Сразу пояснения
Будет дополнение к списку — буду рад увидеть и дополнить свой, пишите.
| Вложение | Размер |
|---|---|
| hosts.txt | 7.15 КБ |

Перефразируя известного древнегреческого философа Гераклита, можно сказать: «Всё течёт, всё ломается». А ещё есть такое наблюдение: люди делятся на две категории. Одни ещё не теряли важные данные, другие регулярно делают архивные копии. Вот об архивных копиях и поговорим.
Вы готовы к ситуации, когда завтра на дата-центр вашего сервера нападут марсиане, выкрадут именно ваш сервер и исчезнут с ним навсегда? Можно и менее шуточно: вы готовы принять новость, что злоумышленники взломали сервер провайдера и всё там потёрли? А просто к тому, что сгорел жёсткий диск? Ведь всякое случается.
Я — готов. Знаете, почему?
Потому что раз в сутки на всех моих блогах и сайтах происходит создание полной архивной копии файлов и содержимого баз данных. Архивные копии затем рассылаются на другие сервера в других странах. Периодически я прожигаю несколько архивных копий на DVD и храню физически в разных местах мира.
По той же причине я давно уже не теряю существенные объёмы работ над своими книгами и программными продуктами: они хранятся в т.н. репозиториях, а архивные копии репозиториев точно так же периодически сохраняются на разных серверах.
Это даёт некоторую гарантию того, что даже в случае одновременного выхода из строя 2-3 таких хранилищ я смогу восстановить сайты из архивов давностью не более суток.
Вы ещё не делаете архивных копий? Надеетесь на провайдера или на Провидение? Тогда всего лишь вопрос времени, когда вы потеряете что-то очень важное без шансов восстановить. Интернет помнит всё, но не всё хранит в том виде, в котором вам нужно.
Итак, обдумайте, по карману ли вам неожиданно потерять важные данные. Пусть даже это файл в сотню-другую байт, он может оказаться бесценным. В каком направлении двигаться?
Прежде всего, решите, кто будет заниматься ведением архивных копий, каковы возможные риски, накладные расходы и хлопоты.
1. Где хранить? Вопрос не праздный. В случае активного блога ежедневные архивы могут исчисляться сотнями мегабайт. Хранить имеет смысл как минимум недельную версию всего (при циклической замене архивов), значит - нужен надёжный сервер, способный вместить такое количество информации. В моём случае типичным сервером является VPS (виртуальный выделенный сервер, «на вид» — как отдельно стоящий физически независимый сервер с полными правами доступа) с 20 гигабайтами дисковой памяти. Таких у меня несколько, типичная цена аренды 10 USD в месяц.
Альтернативой является использование службы онлайн-архивирования (зачастую они привязаны к типу ОС, и могут быть только, например, для Windows).
2. Как защищать? Действительно, как удостовериться, что создаваемые архивы не могут быть взяты третьими лицами и использованы в не устраивающих вас целях?
Очевидный ответ: криптография. Используя 7-zip с наложенным на архив паролем, GnuPG, или такой контейнер как TrueCrypt, вы сделаете фактически невозможным дешифровку ваших архивов — понятно, что при условии соблюдения техники безопасности по хранению паролей и прочих данных доступа к файлам.
3. Сколько это будет стоить в смысле времени и финансов, включая необходимость восстановления в случае аварии или потери данных?
Это вопрос, на который трудно дать чёткий ответ. Если вас устроит 1 сервер для хранения данных, как минимальная гарантия сохранности данных, я бы назвал сумму в 10-15 USD в месяц плюс часа 1-2 на настройку процесса.
Важный момент: скооперировавшись с другими блогерами, вы можете сообща приобрести несколько таких серверов и свести эффективные затраты на ведение архивов к очень и очень небольшой сумме.
Подумайте о сохранности ваших данных уже сейчас. До того, как грянет гром.
Блог может и должен приносить не только моральное удовлетворение. Научиться тому, как заработать в Сети, может каждый. Настойчивость и решительность — ключи к успеху в любом деле.

Бесплатный сыр — давний и безотказный манок для всех и каждого. Не нужно спорить с очевидным: всегда, когда говорят «бесплатно», так и тянет как минимум поинтересоваться, а правда ли? А вдруг правда? А почему бы не воспользоваться?
При этом абсолютное большинство людей пользуется бесплатным сыром (почтой, простенькими сайтами на бесплатном хостинге и т.п.), при этом начинает возмущаться и скептически приподнимать брови, когда рекламируешь или просто ссылаешься на бесплатный продукт.
Сервис In.solit.us — пример того самого бесплатного сыра. Это возможность хранить неограниченное количество файлов и, что важно, монтировать ссылку на хранилище как файловую систему. Для тех, кто использует Windows, поясняю: как сетевой диск. После чего копирование файлов становится простым делом.
Сервис декларирует безграничное, но разумное использование ресурсов. При том, что сервис всё ещё в стадии тестирования, он вполне жизнеспособен и работает нормально, изредка встречающиеся замедления доступа не в счёт.
Итак, почему оправдано хранение своих данных на подобных сервисах? Ответ простой: потому что бесплатно. Если хоть что-то распространяется бесплатно, то как минимум провайдеры ресурса получают рекламу и множественные ссылки на себя любимых. Что вполне оправдано и честно: доволен ресурсом — порекомендуй другому. Вот я и рекомендую.
В последующих публикациях я расскажу и о других способах хранения данных, в том числе бесплатных, а пока напомню только основные правила работы с бесплатным сыром.
1. Даже платное не всегда вечно, а бесплатное тем более. Не используйте бесплатные ресурсы как единственный и основной вариант, всегда имейте платный, принадлежащий только вам аналог.
2. Не полагайтесь на доступность и надёжность бесплатных ресурсов. Нелепо размещать на них коммерческие и/или посещаемые сайты и пр., а потом удивляться, отчего вдург «всё кончилось».
3. Знайте меру. Если вы начнёте наводнять бесплатный ресурс множеством громоздкого, популярного, а тем более не вполне законного контента — не удивляйтесь, что можете неожиданно потерять всё, что сложили, а о и понести за это взыскания в виде штрафов и т.п.
4. Будьте вежливы. Требование на первый взгляд странное (хотя я вообще всегда и со всеми вежлив, сколько позволяет ситуация). Люди предоставили вам что-то бесплатно — даже отвлекшись от мысли, что некую выгоду они всё равно с этого имеют, люди стараются. поддерживают ресурсы, работают в буквальном смысле слова за так. Если что-то ломается — примите спокойно, вежливо узнавайте причину сбоев и время восстановления доступа.
Помните, что вы соглашались с условиями использования ресурса, когда создавали учётную запись или загружали свои данные. А стало быть, обязаны их соблюдать.
Надеюсь, что и вам понравится сервис in.solit.us, как он понравился мне.
Комментирование, помимо целей общения - главного смысла блога как жанра - несёт и функцию создания ссылок на другие ресурсы. В традиционном случае, когда комментарии живут на том же сайте и видны как поисковым системам, так и людям, это порождает, неизбежность, злоупотребления - спам в комментариях. Даже если отключена индексация спам-записей и ссылок в них, они всё равно засоряют сайт и создают ему неприятную репутацию. Одно из решений - хранить комментарии так, чтобы они были видны только живым посетителям (тем, у кого есть работающий JavaScript).
Служба "Disqus" (далее "Дискус") предлагает один из вариантов решения, а именно - хранить все комментарии на внешнем ресурсе, подключать их так, чтобы лишь живые посетители могли видеть и - это самое важное - управлять всеми записями из единого командного центра.
Система оказалась достаточно эффективной, с точки зрения вебмастера, чтобы я установил её на все автономные блоги. Однако я по-прежнему считаю свои блоги "DoFollow", потому что и прежние, родные комментарии доступны зарегистрированным посетителям блогов. Смысл? Как минимум дать людям возможность оставлять прямые ссылки. Если человек не поленился зарегистрироваться (это занимает пару минут), а ещё лучше - назначить потом OpenID, то и входить, и комментировать сможет, как раньше, сов семи преимуществами такой системы. Но посетителям-гостям теперь есть возможность комментировать только через "Дискус".
Очевидно, есть и недостатки у подхода, связанного с использованием специальной службы комментирования. Вкратце перечислим очевидные:
Очевидным "нашим ответом Керзону", следующим этапом, станет создание (кем-нибудь) аналогичной системы централизованного комментирования, с открытым кодом и возможностью интеграции везде, где разрешается JS/HTML. Простая, очевидная идея, и она, несомненно, будет реализована. Перечислим очевидные достоинства такого подхода:
Преимущества столь очевидны, а расходы на реализацию такого сервиса настолько малы, что впору делать ставки, когда возникнет свободный аналог "Дискуса" с открытым кодом.
Разумеется, всё, сказанное выше, не должно навести на мысль, что "Дискус" чем-то фундаментально плох. Но чем больше сторонних служб, с которыми интегрирован ваш сайт, тем дольше он грузится, тем менее надёжен доступ к полной функциональности, тем труднее за всем следить.
Ну, а до тех пор я пользуюсь "Дискусом", периодически делаю полные архивные копии своих лент там, и вам всем рекомендую попробовать то же самое. По словам представителя службы тех.поддержки, перевод интерфейса на другие языки - вопрос ближайшего будущего. Как минимум одной проблемой станет меньше.
Простые решения типичных задач.
Основной сложностью блогера, которому нужно множество разнообразных статей, является быстрое создание в достаточной мере уникальных текстовых документов. Предлагаемый "бюджетный" способ достаточно удобен, если использовать исходный документ (шаблон) с большим количеством вариаций. От блогера требуется некоторая изобретательность при подготовке шаблона, всё прочее скрипт сделает сам.
Что требуется: умение работать из командной строки с Perl, установленный Perl версии не ниже 5.6.
Собственно скрипт, необходимый для работы, можно взять двумя способами:
1. В репозитории, по адресу
http://svn.xp-dev.com/svn/boyandin_public/boyandin.info/scripts/sts/perl/sts.pl
-оптимально, потому что файл может периодически обновляться.
2. Из архива, прицепленного к данной записи (см. её конец). Менее удобно в том смысле, что возможны ситуации, когда в репозитории файл новее.
1. Распакуйте скрипт в любое удобное для вас место; в дальнейших командах предполагается, что вы распаковали его в текущий каталог и назначили права на исполнение (если работаете в Un*x).
2. Создайте произвольный текстовый файл (текстовый в смысле не двоичный - это может быть и текстовый файл, и HTML, и всё, что угодно, что не теряет своих свойств при замене части строк на другие.
В тех местах, где нужно породить выбор синонимичных строк, вставьте шаблон вида
{строка 1|строка 2|...|строка N}
Количество вариантных строк произвольно, разделитель - вертикальная черта, строки не могут, как следствие, содержать фигурные скобки или вертикальную черту. Между фигурными скобками не должно быть переводов строк.
3. Дайте команду вида
./sts.pl -s template.html -d article-%d.html -n 2000
Описание параметров:
template.html - имя исходного файла, содержащего упомянутые выше шаблоны
article-%d.html - шаблон для порождения имён выходных уникальных файлов. Если вы знаете, что такое sprintf(), то можете подставить любое аналогичное макро для вывода целого, если нет - используйте любую строку, в которой есть подстрока '%d' (без кавычек). При создании файлов вместо этой строки будет подставлен порядковый номер созданного уникального документа.
2000 - число попыток создания очередного уникального файла на основе исходного. Если параметр не задан, то один.
Скрипт не порождает дубликатов - они опознаются в процессе создания и игнорируются. Однако стоит иметь в виду, что вариации выбираются случайно, и потому конечное число порождённых документов может быть меньше ожидаемого. Иными словами, параметр '-n' указывает, сколько попыток создать документ будет произведено.
Так сделано намеренно - поскольку неясен механизм работы генератора псевдослучайных чисел (rand()), скрипт может работать неопределённо долго, если попробовать добиваться нужного числа выходных файлов повтором попыток. Если порождено слишком мало статей, сотрите созданные файлы и повторите операцию, увеличив параметр '-n'.
В ближайшее время я сделаю Web-аналог, позволяющий генерировать уникальные документы всем, у кого нет либо познаний в области работы с командной строкой и скриптами, либо нет такой возможности.
Также я располагаю "интеллектуальным" синонимизатором, который использую для собственных нужд - который распознаёт словоформы и использует настраиваемый контекст для порождения синонимов без создания шаблонов вручную. Скрипт будет выложен в свободный доступ, как только его разработка дойдёт до устраивающей меня по эффективности версии.
Анонсы этой статьи: grabr.ru sloger.net blogparad.ru blogistica.ru
| Вложение | Размер |
|---|---|
| sts-perl.zip | 1.37 КБ |

Не буду в очередной раз говорить о двусмысленности т.н. бесплатного сыра. О том, что такое бесплатный хостинг, говорилось не раз, и не два, и все минусы и плюсы этого уже изложены многими.
Однако есть способы использовать ресурсы, ориентированные в основном на «бесплатный сыр», чтобы с их помощью отыскивать коммерческие, вполне вменяемые и интересные предложения.
Чтобы не быть голословным. Может ли заинтересовать вас выделенный (dedicated) сервер, вполне мощный, чтобы на нём жило пять-шесть весьма популярных блогов или иной сервис, меньше чем за 30 USD (долларов США, то есть) в месяц?
А VPS, сиречь виртуальное воплощение того же, столь же мощное, но вообще за 5 USD? Причём в обоих случаях цены фиксированы и не увеличиваются впоследствии.
Уточню, это важно: речь не о б/у технике, и не о демпинговых вариантах от малоизвестных хостеров. Речь о солидных компаниях, у которых не страшно приобретать хостинг. Интересно, где всё это можно найти? Пожалуйста, вот одно из таких мест: форум предложений платного хостинга на сайте FreeWebSpace.
Таких сайтов в природе несколько. Сразу скажу, почему я предпочитаю искать выгодные предложения хостинга именно в подобных форумах.
Во-первых, сама цена весьма и весьма привлекательна. Разумеется, вменяемые хостеры не живут себе в убыток, и таких предложений у них немного. Кто успел — того и тапки.
Во-вторых, хостеры прекрасно знают психологию клиентов. Люди активно читают предложения бесплатного сыра, а если рядом есть предложения весьма выгодных вариантов сыра, хорошего, пусть и платного — люди обязательно заглянут и туда.
В-третьих, атмосфера на форуме царит весьма вменяемая. Модераторы знают своё дело, да и хостеры с клиентами весьма дружелюбны. По одной простой причине: дашь скидку или составишь выгодный план хостинга — человек ведь и другим посоветует.
Лично мне этот форум позволил обрести несколько весьма выгодных планов хостинга. В частности, данный конкретный сайт сейчас успешно использует такой вариант (вы могли заметить, что скорость загрузки и доступность моих блогов ощутимо улучшились).
О том, как именно себя вести на подобных форумах, я подробно напишу в будущих заметках, а пока ссылки на другие форумы, где вы можете найти очень выгодные предложения по хостингу (и не только).
Одна беда: все эти форумы англоязычные. Это, увы, суровая реальность: русскоязычных форумов, посвящённых хостингу, крайне мало, а на существующих весьма странные правила. Словом, ситуация в среднем та же, что и с отечественным хостингом в целом: хороший хостинг в ex-USSR есть, но либо крайне дорогой, либо низкого качества.
Поэтому, если вас не пугает английский язык, вот список нескольких очень полезных аналогичных ресурсов:
1. WebHostingTalk, крупнейший англоязычный форум о хостинге. именно там последние новости, полезные обзоры и свежие заметки о том, что происходит в индустрии. Примечание: там нельзя просить хостинга (нет такого форума, закрыт), но ато предложений — видимо-невидимо.
2. Форумы про хостинг на DevShed. DevShed — кладезь полезных новостей и информации вообще, там не только о хостинге.
2. WebHostingChat. Не такой известный, но тоже полезный форум, посвящённый хостингу.
Главное в офисной работе — комфорт. Удобные и красивые офисные кресла — не роскошь, а необходимость.
Задача: во всех файлах, соответствующих тому или иному шаблону, произвести замену строки на строку. Самое простое решение:
find . -type f -name "pattern" | xargs perl -pi~ -e "s/SEARCH/REPLACE/ig"
Пояснение: найти все файлы, в данном каталоге и всех подкаталогах, удовлетворяющие шаблону "pattern", после чего произвести замену в соответствии с переданным регулярным выражением (поиск, игнорирующий регистр), причём исходный файл сохранить, приписав к его имени тильду ('~'). Поиск ведётся по умолчанию и во всех подкаталогах.
Пример: заменить во всех .html файлах все вхождения example.com на example.net
find . -type f -name "*.html" | xargs perl -pi~ -e "s/example\.com/example\.net/ig"
Любители sed могут использовать его вместо относительно тяжеловесного perl.
А ещё знатоки Perl могут попробоватьс ходу сказать, что делает вот эта команда:
perl -i~ -p00e0 file.ext
Электронная почта и все маленькие хитрости из этой области.
Вести архив (резервную копию) электронной почты может быть не менее важно, нежели сохранять архивные копии важных файлов. Почтовые сервера - в особенности это касается бесплатных - не являются надёжным способом хранить важные сообщения. Неосторожность пользователя, всевозможные сбои, случаи временной или постоянной потери контроля над ящиком - всё это может привести к частичной или полной потере важной переписки.
Средства для создания архивных версий электронной почты есть, из них я рекомендую isync. Пакет isync бесплатный, является утилитой командной строки и, судя по сведениям от разработчиков, работает под Linux, Solaris 2.7, OpenBSD 2.8, FreeBSD 4.3.
Для того, чтобы использовать пакет из-под Windows, требуется вначале установить Cygwin, бесплатную эмуляцию Un*x-подобной среды, под которую портированы многие существующие пакеты приложений.
Установка isync осуществляется
- при помощи менеджера пакетов данной конкретной ОС (например yum в случае RedHat и производных, таких как Fedora, CentOS и т.д.) - ищите и устанавливайте пакет isync
- сборкой из исходников, они доступны на странице isync в SourceForge; для тех, кто знает знаменитую последовательность "./configure; make; make install" сборка не составит труда; вам потребуется библиотека OpenSSL, если вы будете использовать защищённую авторизацию (крайне рекомендую)
В общем и целом сборка, в т.ч. на Cygwin, проблем не вызывает, если у вас затруднения, можете в т.ч. обращаться ко мне (хотя не думаю, что придётся).
В пакет входят две программы, isync, "обёртка" для второй программы, mbsync, которая, собственно, и является рабочей лошадкой пакета. Работу с isync я опишу в одной из последующих статей, а пока опишу основные шаги конфигурирования mbsync и запуск процедуры создания резервной копии всей почты конкретного почтового ящика.
В примере ниже мы настроим создание архивной копии всей почты с почтового ящика в Google Mail, для ящика nobody [at] gmail [dot] com.
1. Создаём каталог (папку), в котором будем хранить архив почты:
mkdir -p ~/mailarc/gmail.com/nobody
(создать от корня домашнего каталога указанную иерархию - обратите внимание на принцип именования; он удобен, если вы настроите автоматическое создание архивов для множества ящиков)
2. Получаем цепочку SSL сертификатов (это необязательно, если не используем защищённое соединение; в случае Google Mail это является обязательным шагом). Проще всего это сделать, дав команду такого вида:
openssl s_client -connect imap.gmail.com:993 -showcerts 1>> ~/mailarc/gmail.com/gmail.pem </dev/null
Пояснение: openssl в данном случае - это "обёртка", позволяющая открыть соединение с IMAP-сервером imap.google.com по защищённому каналу; мы запрашиваем цепочку сертификатов, а поскольку нам ничего более не нужно, то при помощи ввода /dev/null прекращаем разговор)
Далее откроем любой текстовый редактор, не форматирующий строки в исходном файле, и редактируем сохранённый файл gmail.pem. В нём ищем блоки вида
-----BEGIN CERTIFICATE----- MIIDLzCCApigAwIBAgIKKNVg8QAAAAAHfzANBgkqhkiG9w0BAQUFADBGMQswCQYD VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu dGVybmV0IEF1dGhvcml0eTAeFw0wOTAzMTIyMDIzNDFaFw0xMDAzMTIyMDMzNDFa MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw5pbWFw LmdtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAo1cDhDhgSN3M 9Do6D459nSNxZW1fTPJV5rmJctt12zZwDTBbHqWlZsK1ZvcV1ngj1nYgZ7RXZmgC sxEUSK/sw+/5Otl6BpK3OLFZI5U/FmMUTssG588Hsl21SBxeK7RoAgxxM2vB2Jgi 3KH+E13mlgUXlCyrehnbbTlwEosURyUCAwEAAaOCAQAwgf0wHQYDVR0OBBYEFNiX w7Ps6PWzF80VrxYbz63ucVArMB8GA1UdIwQYMBaAFL/AMOv1QxE+Z7qekfv8atrj axIkMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwuZXh0Lmdvb2dsZS5jb20v R29vZ2xlSW50ZXJuZXRBdXRob3JpdHkuY3JsMFAGCCsGAQUFBwEBBEQwQjBABggr BgEFBQcwAoY0aHR0cDovL2NhLmV4dC5nb29nbGUuY29tL0dvb2dsZUludGVybmV0 QXV0aG9yaXR5LmNydDAhBgkrBgEEAYI3FAIEFB4SAFcAZQBiAFMAZQByAHYAZQBy MA0GCSqGSIb3DQEBBQUAA4GBALo7fCzccb+0OeU+iGPJ/CEynTIegiqt/OkZPP4P aVy7a0MjwK7mDDYpMMu10r4oYSM8iI1BN2iIXRFDkuogp48yeh8P3In1A332XdW3 UoaoIhI8DunLXgfBEr2/TPUHtXDfJumu+wCojdjT2ywwud1hY8LSRR2zv27FWEAD OaRh -----END CERTIFICATE-----
Их оставляем в сохранности, включая обе ограничивающие строки, всё прочее из файла удаляем, включая пустые строки. Сохраняем файл.
3. Создаём конфигурационный файл mbsync, по умолчанию это ~/.mbsyncrc и помещаем в него следующее содержимое (внимание! не забудьте указать действительное имя почтового ящика; все имена локальных каталогов для хранения почты также укажите по своему выбору; в примере используется то, что было упомянуто ранее)
IMAPAccount nobody-gmail-com
Host imap.gmail.com
User "nobody [at] gmail [dot] com"
# Pass mysecretpass
UseIMAPS yes
CertificateFile ~/mailarc/gmail.com/gmail.pem
IMAPStore nobody-gmail-com-remote
Account nobody-gmail-com
MaildirStore nobody-gmail-com-local
Path ~/mailarc/gmail.com/nobody/
Inbox ~/mailarc/gmail.com/nobody/Inbox
Channel gmail-nobody-save
Master :nobody-gmail-com-remote:
Slave :nobody-gmail-com-local:
# Exclude everything under the internal [Gmail] folder, except the interesting folders
Patterns * ![Gmail]* "[Gmail]/All Mail"
# Patterns * ![Gmail]*
Create Slave
Expunge Slave
Sync Pull
Для mbsync есть страница стандартной документации, но она весьма лапидарная, поэтому вкратце опишем, как создаются настройки для ведения архивов почты, пока что для самого общего случая - синхронизацию ящика в целом.
Конфигурационный файл состоит из блоков, где определяются учётные записи, удалённые и локальные хранилища и каналы (правила) синхронизации. Символ диеза (решётки) в первой строке означает комментарий. Пустые строки игнорируются.
Для создания правил (каналов, channel) синхронизации состояния почты, определяют учётные записи на IMAP сервере, локальное и удалённое хранилища, и собственно канал - правила синхронизации. В примере выше:
Определение учётной записи IMAP:
IMAPAccount nobody-gmail-com
Host imap.gmail.com
User "nobody [at] gmail [dot] com"
UseIMAPS yes
CertificateFile ~/mailarc/gmail.com/gmail.pem
IMAPAccount: идентификатор (имя) учётной записи. Любая строка. Я предпочитаю указанное правило именования, просто для удобства чтения. Двоеточий там быть не должно.
Host: доменное имя IMAP-сервера (или IP-адрес)
User: имя пользователя, необходимое для авторизации на IMAP.
Pass: пароль (если содержит пробелы, возьмите пароль в двойные кавычки). Внимание: пароль указывать имеет смысл, только если производите синхронизацию автоматически. В одной из последующих статей я расскажу, как передавать пароль, не указывая его открытым текстом, а при ручной синхронизации эту строку не указывайте - пароль программа запросит сама.
UseIMAPS: использовать ли защищённый канал (SSL, STARTTLS) для авторизации. "yes" или "no", если не указано - считается "no".
CertificateFile: файл с цепочкой сертификатов, полученных на шаге 2. Необходим при использовании защищённых каналов.
Определение удалённого хранилища (IMAP)
IMAPStore nobody-gmail-com-remote Account nobody-gmail-com
IMAPStore: идентификатор (имя) хранилища на удалённом (IMAP) сервере. См. по поводу именования выше.
Account: идентификатор описания учётной записи IMAP, приведённый ранее в файле конфигурации при помощи директивы IMAPAccount.
Определение локального хранилища
MaildirStore nobody-gmail-com-local Path ~/mailarc/gmail.com/nobody/ Inbox ~/mailarc/gmail.com/nobody/Inbox
MaildirStore: идентификатор (имя) локального хранилища, где будут сохраняться индивидуальные письма и служебная информация об архиве. См. выше по поводу именования.
Path: база (корень) хранения состояния почтового ящика, мы создали её на шаге 1.
Inbox: каталог, в котором будем помещать сообщения из "Входящих". Примечание: создавать его НЕ нужно, программа создаст его сама.
Определение канала синхронизации:
Channel gmail-nobody-save Master :nobody-gmail-com-remote: Slave :nobody-gmail-com-local: # Exclude everything under the internal [Gmail] folder, except the interesting folders Patterns * ![Gmail]* "[Gmail]/All Mail" # Patterns * ![Gmail]* Create Slave Expunge Slave Sync Pull
Channel: идентификатор (имя) канала. Я использовал строку 'save', чтобы указать. что данный канал сохраняет локальную копию почтового ящика и всех его папок.
Master: между двоеточий, указать идентификатор исходного хранилища, ранее определённого в конфигурационном файле директивой IMAPStore или MaildirStore. Оттуда будут браться сообщения (почта).
Slave: между двоеточий, указать идентификатор целевого хранилища, ранее определённого в конфигурационном файле директивой IMAPStore или MaildirStore. Там будут сохраняться сообщения (почта).
Patterns: перечисление имён папок, которые подлежат синхронизации, можно использовать метасимволы '*' (без кавычек, обозначает любую последовательность любых символов) и '%' (без кавычек, обозначает любое количество любых символов вплоть до упомянутой иерархии, например '% !Trash'). Восклицательный знак обращает действие - указывается то, что НЕ подлежит синхронизации.
В нашем примере мы не берём ничего, что лежало бы внутри технических каталогов Gmail, кроме "всей почты" (таким образом мы исключаем корзину и спам-папку). Явное указание папки отменяет описанное ранее исключение, под которое она попадает.
Create Slave: указывает, что, если папка на целевом хранилище отсутствует, то создать её.
Expunge Slave: удалять на целевом хранилище всё, что отсутствует на сиходном.
Sync: указать тип синхронизации. Указать флаги и директивы, из следующего списка:
Pull - копировать изменения из исходного в целевое.
Push - копировать изменения из целевого в исходное.
New - копировать только новые сообщения.
ReNew - скопировать то новое, что ен было скопировано по тем или иным причинам (например, нехватка места).
Delete - синхронизовать - удалить - то, что было окончательно удалено.
Flags - синхронизовать флаги состояния сообщений (новое или нет, помеченное к удалению и пр.).
All - всё, перечисленное выше, действие по умолчанию, если директива Sуnc не задана.
None - не делать ничего; удобно для синхронизации удалений (expunge).
Вы можете создавать произвольное количество самых разных каналов: один может копировать всё на локальное хранилище, другой - наоборот, копировать на IMAP сервер.
Теперь, когда конфигурационный канал создан, можно его испытать. В целях испытаний рекомендую вначале указать для канала директиву
Sync None
чтобы просто проверить, всё ли настроено, как следует.
Для запуска процесса вызовите mbsync и передайте программе имя канала (каналов), например, в нашем примере,
mbsync gmail-nobody-save
введите пароль, примите (обычно один раз) SSL сертификат, если программа сомневается в его подлинности, и наблюдайте за процессом копирования. Программа действует экономно - считывает с сервера только то, что отсутствует в локальном хранилище.
Для каждой IMAP папки (в случае Google Mail - для каждой метки, тега) создаётся отдельный подкаталог. Все сообщения лежат в виде отдельных файлов, в исходном (сыром) виде, со всеми техническими заголовками.
Очень не советую что-то править во вспомогательных файлах, созданных mbsync, это может првиести к сбоям при последующих запусках. Также не создавайте каталоги под будущие IMAp папки, программа создаст их сама при необходимости.
Примечание. Я обычно сохраняю всё сохранённое в едином архиве (упаковываю всё при помощи tar/bzip2 или 7z) и копирую ещё куда-нибудь. На случай, если удалённые сообщения были важны и пропадут при последующей синхронизации. Как вариант, вообще удалите "Expunge Slave", чтобы на локальной копии сохранялось всё.
Данная статья описывает простейший способ использования пакета isync для синхронизации состояния почтового ящика. Очень рекомендую пользоваться таким способом, ибо люди, как известно, делятся на две категории: тех, кто ещё не терял очень важные файлы, и тех, кто регулярно делает резервные копии.
Пожелания, комментарии, предложения по следующим статьям приветствуются.
Анонс этой статьи на: grabr sloger blogistica blogparad showblogs
Электронная почта была и остаётся важным инструментов не только общения, но и продвижения, рекламы. Ниже я даю общее описание зарубежных провайдеров электронной почты, услугами которых пользуюсь не менее пяти лет - и остаюсь доволен.

Google Mail - безусловный лидер среди почтовых провайдеров, как по качеству, так и по количественным характеристикам. Доступный некогда только по приглашениям, сейчас Google Mail доступен всем и каждому.
Краткие характеристики:

Fastmail.fm - один из лучших платных сервисов "старого образца" (только в течение последних 1-2 лет начали появляться признаки Web 2.0). Невзирая на то, что есть и бесплатный вариант, я рекомендую платный план, причём самый дорогой из "обычных" (не бизнес- и не семейных), все последующие описания имеют в виду именно этот план.
Краткие характеристики:
Fastmail.fm больше, чем традиционный почтовый сервис. Здесь вы найдёте множество разных планов - персональные, семейные, бизнес-планы. Есть партнёрская программа, есть удобные виды сервиса вроде отправки SMS, есть автоответчики и списки рассылки. Если вас не смущает английский язык интерфейса и вам не кажется чрезмерной указанная плата - не медлите, откройте там учётную запись и используйте всё, что там есть, для работы, общения и продвижения.

GoDaddy.com - в первую очередь, регистратор доменных имён; если вам нужен домен не в национальных зонах RU/SU, то я б советовал именно GoDaddy. Интерфейс у их сайта тяжёлый, покупка доменов связана с необходимостью постоянно отмахиваться от навязчивых предложений, но всё же я советую попробовать тамошний сервис почты, план Ultimate.
Краткие характеристики:
Традиционный совет обычно звучит так: не покупайте у регистратора доменов ничего, кроме доменов. Касательно хостинга и прочего - тут я совершенно согласен, а вот почта у GoDaddy вполне адекватная. Хотя и без наворотов, "просто почта" с очень большой квотой.

Строго говоря, Cotse (Cult of the Swimming Elephant, культ купающегося слона) - это набор средств безопасности, от анонимизрующего прокси до римейлеров. Почта у них - не самый важный, хотя и очень удобный сервис. Как и всё в Cotse, почта защищена и надёжно, от проникновения и перехвата. Пусть вас не смущает неказистый интерфейс: такого комплекта услуг, как на Cotse, за подобную цену и с отличным качеством вы попросту нигде не сыщете.
Краткие характеристики:
Ссылка выше ведёт на страницу, где описывается комплектация того самого "Internet shield", самого популярного из планов Cotse.
Если вы хотите уверенности в защищённости и неприкосновенности своей почты и путешествий по Сети, лучше Cotse вы вряд ли что-нибудь сыщете.
В последующих выпусках я дам краткие описания не столь внушительных сервисов, а также отечественных провайдеров электронной почты.


О том, что такое агрегатор FriendFeed, думаю, долго рассказывать нет нужды. Равно как и рассказывать о достоинствах почтовой службы Google, Google Mail (GMail).
Основной проблемой любого и всякого потока информации является структурировать его, уметь искать в нём всё, что необходимо, хранить. В этом смысле отдельно взятый FriendFeed, при относительно большом числе подписчиков становится крайне неудобен для поиска в потоке сообщений чего-то интересного. А когда вы должны оставить компьютер и препоручить себя заботе Морфея или иным, не менее важным, делам, то как потом узнать, было ли что полезное?
Решение — простое и эффективное — предоставляет Google Mail. Используя связку GMail + FriendFeed, вы в состоянии хранить, эффективно искать и, что самое главное, помогать индексировать всё то, что проходит по каналам FriendFeed. Подробности ниже.
Шаг 1. Создайте себе почтовый ящик на Google Mail, если его у вас ещё нет. Там всё по-русски, и большую синюю кнопку на главной странице трудно не заметить. После регистрации и входа, обязательно включите чат (установите там свой статус в любой, отличный от «отключен», лучше всего — укажите, что вы на связи и готовы поболтать. Затем на странице настроек выберите закладку «Чат» (Google Talk) и обязательно поставьте галочку «Сохранять историю чата».
Шаг 2. Создайте учётную запись на FriendFeed. Там тоже всё по-русски, и достаточно прозрачно. Сразу после создания проследуйте на страницу настроек уведомлений и добавьте в качестве приёмника уведомлений Google Talk (см самый верх). Как вариант — установите в качестве почтового адреса для получения уведомлений ваш адрес Google Mail (он же используется для подключения Google Talk). Откройте страницу Google Mail и в чате авторизуйте новый контакт, ff@chat.friendfeed.com. Именно он будет поставлять вам все новости от FriendFeed.
Примечание: если вы используете Jabber-клиент или клиент Google Talk, то можете внести указанный контакт в ростер и авторизовать его в клиенте. Я лично использую Пси.
Шаг 3. Не кидайте всё в одну кучу: создайте списки (каналы) на соответствующей странице. Затем вернитесь на страницу настроек уведомлений и пометьте галочкой пункт IM для каждого канала, который вы захотите получать по Google Talk (если вы решили использовать почту, пометьте галочкой пункт Email, выберите в выпадающем меню "In real time" (в реальном времени), пометьте, что хотите получать всё, включая комментарии — и приготовьтесь к огромному наплыву писем — почему я и советую использовать Google Talk).
Шаг 4. Подписывайтесь на каналы FriendFeed тех, кто вам интересен и не забывайте при этом назначать им тот или иной канал (список друзей).
Всё. Теперь, когда вы откроете Google Mail, вы увидите, в разделе чата, обновляемый в реальном времени список сообщений, полученных от FriendFeed.
Действительно, что вам это даёт? Вот основные достоинства такой сцепки:
1. Вся история чатов, весь поток ленты друзей Твиттера и всё остальное, что вы добавили в свои каналы FriendFeed теперь хранится у вас в едином формате, в записях можно делать поиск а, значит, вы легко отыщете пропущенную или просто интересную реплику, ссылку, объявление. Не забывайте, что можно легко и просто сохранять в архивы всё содержимое папок почтового ящика, а, значит, вести строгий учёт всего потенциально полезного.
2. Google индексирует ссылки, которые проходят через Google Mail и Google Talk. Это, хоть и не подтверждается явно самой компанией. имеет множество косвенных свидетельств. Таким образом, участвуя в получении каналов FriendFeed, вы помогаете полученным в нём ссылкам и записям быстрее проиндексироваться.
Хотите что-то-то добавить? Я с удовольствием прочитаю ваши отзывы, комментарии и уточнения, если они есть.
Заметки и статьи, относящиеся к использованию служб компании "Яндекс".
Отец наш Яндекс, как известно, старается вовсю подражать западным гигантам IT-индустрии. Среди прочего, это выражается в нежелании отечественного лидера поиска в Сети следовать стандартам, если это будет слишком простым решением.
Чтобы не позволять передавать ссылочный вес, был придуман атрибут rel, у которого есть значения, среди прочих, noindex и nofollow.
Google использует этот тег по прямому назначению и, пусть даже rel="nofollow" уже не исключает полностью деление ссылочного веса при ранжировании, вес на помеченную этим значением ссылку не перейдёт.
Яндексу было слишком просто использовать rel="noindex", а потому он изобрёл тег <noindex> </noindex>.
Всем хорош тег, но он не соотносится со стандартами ]]>WWW-консорциума]]>, а, следовательно. страница не пройдёт проверку на соответствие разметки стандартам. А это несколько больше, нежели простая гордость за грамотность разметки.
По счастью, (X)HTML предусматривает специальный синтаксис для блоков, которые могут содержать произвольный текст, который иначе трактовался бы как разметка и мог порождать ошибки и неверную интерпретацию.
Определение блока CDATA:
<![CDATA[ ...произвольный текст, который не следует интерпретировать как разметку... ]]>
Таким образом, если вы хотите указать роботу поисковой службы Яндекса, что не нужно передавать ссылочный вес на те или иные ссылки, и при этом хотите сохранить соответствие стандартам разметки, можно написать примерно так:
<span style="display: none;"><![CDATA[<noindex>]]></span> <a href="http://example.com" rel="nofollow">текст ссылки</a> <span style="display: none;"><![CDATA[</noindex>]]></span>
В этом примере мы указываем одновременно Яндексу и Google на недопустимость учёта веса нашей страницы при ранжировании упомянутого в ссылке документа, при этом сохраняя соответствие стандартам. Чтобы избежать неверной интерпретации секциии CDATA, скрываем её при помощи CSS атрибута display.
Нестандартный тег <noindex> ... </noindex> спрятан в CDATA и не вызовет ошибок. Точно так же рекомендуется «прятать» в такие же блоки JavaScript-код и прочие элементы разметки, не соответствующие указанным в заголовке стандартам.
Примечание: явного подтверждения, что указанный конструкт с гарантией закроет ссылку от поискового робота, нет. Если это так (нужно найти официальное подтверждение от Яндекса), то у вас будет выбор: или корректный HTML, или закрытые от поисковика ссылки. Все претензии, пожалуйста, к Яндексу.