В дорвеестроительстве, в отличие от создания СДЛ, важно изначально понимать, через какие фильтры придется пройти сайту. Как ни как лицензия на поиск нарушается (пункт 3.5, «Поисковый спам»), да и на лицо полная зависимость от индексации и позиций. Если при создании белого проекта цели вебмастера (создать хороший сайт) и ПС (отранжировать хорошие сайты выше) так или иначе в большинстве случаев совпадают, то при создании дорвеев начинается явное противостояние. Цель дорвейщика — создать механизм, позволяющий максимально автоматизировано получать поисковый трафик, цель поисковой системы — не допустить этого.

Сразу хочу отметить, что «окологуманитарный» подход, частенько принятый в «белом» SEO, здесь не совсем подходит. Почему «окологуманитарный»? Да по другому и не может быть. Белые проекты — долгоживущие. Развивать и раскручивать их надо на перспективу, а не подстраиваясь под текущие алгоритмы. Отсюда и «надо повышать траст», «обмениваться ссылками», «покупать статьи на тематичных ресурсах» и т.д. Плюс большая растянутость во времени, не позволяющая точно оценить влияние того или иного фактора. К примеру, есть у меня сайт, который я двигаю в топ по запросу миллионнику (по вордстату). Бюджет не изменялся уже несколько месяцев, однако позиции подросли с 100+ до первой тридцатки, скоро и в топ выбьюсь. С чем это связано? Статьи стали действовать, ссылки отстоялись, какие-то из доноров стали более трастовыми, естественные ссылки сказались, просто сайт стал более «выдержанным»? Точно не ответить, скорее всего все вместе. И далее я буду развивать сайт не делая упор на что-то одно, а именно «гуманитарным» комплексным методом — ссылок прикупить, статей разместить, контента добавить, внутреннею перелинковку улучшить и т.д. Т.е. упор идет не на воздействие на какой-то конкретный алгоритм, а на развитие сайта неким эталонным образом. Хотя, конечно, и технических моментов хватает, от составления анкоров до подбора доноров. К слову о донорах, зачем искать хорошие площадки в сапе, когда их можно найти в Яндексе, а потом уже проверить, какие из них продают ссылки и сформировать свой white list.

С дорвеями все немного по другому. Надо обойти фильтры, которые существуют здесь и сейчас. Надо постараться создать такую технологию, разработка противодействия которой либо теоретически трудно реализуема, либо повлечет большие накладные расходы, существенно превышающие потенциальные убытки, либо если практическая реализация будет иметь слишком большую погрешность. За примерами далеко ходить не надо — фильтр АГС17. Ну были ГС, ну продавали с них ссылки и что с того? Но когда это стало настолько массовым, что новые индексируемые сайты были на 99% ГС для влияния на ранжирование, когда выбор доноров для покупки ссылок был просто заоблачным практически по любым тематикам, когда стали появляться даже специальные CMS для ГС — надо было что-то делать. И сделали. Причем, на мой взгляд, весьма успешно. Да, была погрешность и улетали многие белые сайты. Да, было потрачено время на разработку этого фильтра. Да, пришлось выделить мощности, чтобы проверить этим фильтром все или большинство имеющихся сайтов в индексе. Но однозначно игра стоила свеч — массовая индустрия создания ГС под сапу фактически умерла.

Именно поэтому стоит пользоваться своими приватными наработками. Предположим, есть какая-то технология, например хитрый клоакинг по ip-шникам или рефереру. Этой технологией пользуется один-два-три человека. Сколько они создадут дорвеев? Сто, тысячу, вряд ли больше. Стоит ли этому искать противодействие? Может быть и да, но всегда есть другие, более насущные проблемы. А теперь представим, что эта технология выходит в паблик, становится опцией по умолчанию в доргенах и т.д. Что получим в итоге? Ежедневное создание 100500 доров и захламление выдачи. Как результат — разработка фильтра и его внедрение. А это со стороны ПС лишние траты, как денег так и мощностей, но в данном случае оправданные.

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

Лирическое отступление, получившееся немного больше запланированного, закончилось. Дальше будет собственно про фильтры Яндекса.

Как уже выше говорилось, для успешного дорвеестроительства необходимо представлять себе те фильтры, через которые придется пройти. Документации на них, естественно, нет. Поэтому приходится заниматься так называемой «обратной разработкой», когда по внешним проявлением строится модель, приближенная к оригиналу.

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

Сразу оговорюсь, что все ниже приведенные рассуждения касаются новозареганных рушек, наверняка на фри хосты существуют дополнительные фильтры, как и на «неблагонадежные зоны», например .info, не говоря уже о .cn и прочих.

Далее отталкиваться буду от следующих концепций:

• Апдейты в Яндексе происходят ежедневно, если не чаще. Раз в несколько дней результаты последнего (?) апдейта выкладывают в паблик. Это и называется в понимании большинства «апом Яндекса». Придумал это не я (хотя догадаться было бы не сложно), это где-то говорили/писали представители Яндекса, точную ссылку на источник, к сожалению, привести не могу, не помню.

• Фильтров несколько. Структура прохождения сайтов через фильтр — очередь (FIFO, First Input — First Output). Каждый сайт проходит через все фильтры последовательно. Прямой взаимосвязи между индексом, алгоритмами ранжирования и фильтрами нет. Т.е. апдейты это один процесс, прохождение сайтов через фильтры совершенно другой.

С первым утверждением все понятно, поэтому перейдем к более подробному рассмотрению второго.

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

Фильтров несколько. Ну это и так понятно, что существует не один «мегафильтр», а много разных, на контент, на трафик, на ссылки входящие/исходящие и т.д. Смысл в том, что каждый сайт проходит через все фильтры не «разом», а в строгой последовательности. Связано это, в первую очередь, с экономией мощностей. Для наглядности приведу упрощенный пример. Есть 100 сайтов. Есть два фильтра, один проверяет наличие простеньких JS редиректов/скрытого текста, второй — морфологическую целостность текста. Сайт проходит через эти два фильтра последовательно, результат прохождения, условно, либо 0 (фильтр не пройден, сайт забанен, второй фильтр не проходится), либо 1 (фильтр пройден, постановка в очередь на проверку через второй фильтр). Предположим, что экспериментально доказано, что 50% сайтов не соответствуют как первому, так и второму фильтру. С какого фильтра надо начать? Естественно, с первого. По той причине, что на прохождение ста сайтов через первый фильтр и 50 через второй потребуется затратить меньше мощностей, чем сначала у всех сайтов проверить морфологию (достаточно затратный процесс) и у оставшихся тупо проанализировать исходный код и файлы стилей. Таким образом, фильтры располагаются в следующем порядке — первыми идут те, которые требуют меньше всего мощностей и которые в идеале отсеивают больше всего сайтов, последними идут те, которые соответственно потребляют больше всего мощностей, т.к. чисто экономически выгодно, чтобы до этого фильтра добралось как можно меньше сайтов. Также повторюсь, что все фильтры проходятся последовательно, т.е. пока сайт стоит в очереди на проверку, скажем, вторым фильтром, третьим-четвертым-пятым он не проверится.

Теперь немного о самих фильтрах и вообще об отношении Яндекса к сайту прошедшему/непрошедшему фильтр. Изначально сайт считается «белым». Такая вот презумпция невиновности. Даже если сайт полностью состоит из генерированного контента, спам ссылок и т.д., он все равно будет считаться «белым» и будет находится в индексе до тех пор, пока не пройдет хотя бы первый фильтр.

Результатом работы фильтра является не «Да/Нет», а скорее какое-то переменное значение, характеризующее степень соответствия фильтру, пускай будет от 0 до 10. Если 0 — сайт полностью соответствует фильтру и банится, если 10, то никаких признаков соответствия не обнаружено, сайт все также считается «белым» (возможно даже что-то типа +1 к трасту) и встает в очередь на проверку следующим фильтром. Соответственно есть и пограничные варианты, например степень соответствия 3-5, тогда сайт не банится, а выкидывается часть страниц, 7-8 — опускается в результатах поиска и т.д. Из этого следует, что если вы сделали дорвей, и он сразу забанился, значит был не пройдет один из первых фильтров, если полностью влез в индекс и забанился спустя несколько дней, значит первые фильтры пройдены успешно, но не удалось пройти другие, если не забанился, а влез только 5-10-30 страницами, значит какому-то фильтру дорвей соответствует только частично и вы двигаетесь в правильном направлении, немного доработок — и очередной фильтр будет пройден.

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

• Фильтр #1
  Простейший морфологический анализ текстовой составляющей.

  На этом фильтре отсеивается грубо генерированный контент, транслит, плохой синонимайзинг. Чаще всего результатом работы этого фильтра являются пограничные значения, 0 или 10, т.е. либо бан/урезание количества страниц в индексе до не более 10, либо переход к следующему фильтру. Время, необходимое для прохождения сайтов через этот фильтр, минимально. От постановки сайта в очередь до прохождения через фильтр проходит редко больше нескольких дней.

• Фильтр #2
  «Полезность» контента.

  Весьма абстрактный фильтр. Под него попадает «плохой» копипаст (заюзанные адалт рассказы, например), неформатированный контент, в том числе и уник (напарсенный с закрытых от индексации источников или скан). Результат работы фильтра очень зависит от типа контента. Если «плохой» копипаст — бан, если копипаст из многих источников (парсинг Яндекс Новостей), то скорее всего урежет страницы, «хороший» копипаст или уник — ну и нормально, может быть 10-ку не получит, но на 7-8 можно рассчитывать смело. С медиа контентом так вообще прекрасно, Яндекс не может определить полезность, скажем, подборки картинок, подкастов или ютуб-роликов, поэтому такой сайт получает твердую 9-10, если явных нарушений нет.

• Фильтр #3
  Теория вероятностей и мат.статистика.

  Вот тут начинается самое интересное. Наиболее простой пример применения данного фильтра — 100% тайтлов это ключи из вордстата. Дальше — больше. Основательный анализ контента на предмет морфологии и статистического распределения слов и словосочетаний (наилучшая реализация цепей Маркова, прошедшая через первый фильтр, скорее всего запорится на этом). Или еще пример — на сайте 1000 статей, каждая статья содержит 10-15 предложений, по 30-70 знаков в каждом, причем все распределено крайне равномерно без явных отклонений. Что это означает? Да только то, что сайт — генерированный.

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

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

  Для большинства вроде как хорошо сделанных дорвеев прохождение этого фильтра оканчивается баном.

• Фильтр #4
  Анализ трафика, хитроботы.

  До этого фильтра у меня пока не добрался ни один дорвей. На вскидку здесь проверяется разные способы клоакинга, мониторится входящий/исходящий трафик, пути юзеров по сайту, хитробот выполняет скрипты и т.д.

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

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

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

Теперь вернемся к взаимосвязи апдейтов и фильтров. Апдейты идут ежедневно, как только какой-то сайт индексируется, он сразу попадает в выдачу. Одновременно сайты проходят через ряд фильтров, в зависимости от результатов прохождения меняется положение сайта в выдаче и количество страниц в индексе. Причем меняется не сразу после того, как сайт прошел фильтр, а только во время очередного апдейта. Т.е. к примеру сайт попал в индекс и уже висит в выдаче, до наступления следующего апдейта он успел пройти какой-то фильтр, где набрал 3-4 балла из 10, что соответствует урезанию страниц в индексе, до следующего апдейта он будет висеть со всеми страницами, которыми был при предыдущем, а как новый апдейт наступит — тогда уже страницы и вылетят. То же касается и банов. Т.е. по факту прохождения фильтра сайт банится, но до наступления следующего апдейта будет висеть в выдаче. Что касается синхронизации ежедневных апдейтов и тех, при которых индекс выкладывают в паблик, у меня видение такое. Скорее всего тот индекс, который выложили сегодня, принадлежит апдейту некоторой давности, что наиболее целесообразно с той точки зрения, чтобы побольше сайтов успело зафильтроваться и в выдаче было меньше спама. Более того, иногда происходит синхронизация ежедневных апдейтов с выложенным в паблик индексом. Это всем известные выпадения сайтов или баны в «междуапье». Т.е. если сайт попал под какой-нибудь АГС17, то вы об этом узнаете только через несколько дней, когда в паблик выложат тот индекс, в котором уже у сайта урезанное количество страниц. А если сайт попал в бан, то происходит синхронизация текущего индекса с тем, что выложен в паблик именно для этого сайта. Это, в принципе, правильно. Если сайт попал в бан, то это явный спам, а зачем спам держать в индексе еще несколько дней?

Вот вроде бы все. Конечно, многие моменты спорны, многие описаны лишь поверхностно, но для начала, думаю, сойдет. В заключении хотелось бы привести некий Q&A, т.к. я в самом начале сказал, что моя теория отвечает на многие вопросы.

Q: Почему доры на ломе нормально индексируются даже на генерированном контенте?
A: Т.к. сайт уже давным давно прошел через все фильтры, вновь добавленные страницы повторно не проверяются (ну или не так быстро). Еще траст, конечно, но это уже касательно высоких позиций, нежели индексации как таковой.

Q: Почему в выдаче можно найти дорвеи, сделанные паблик доргенами с плохой текстовкой?
A: Как я уже говорил, сайты строятся перед фильтром в очередь и пока фильтр не пройден, сайт считается хорошим. А т.к. дорвеи на паблик решениях генерируются в промышленных масштабах, то пройти через фильтры до наступления того времени, когда индекс выкладывают в паблик, успевают не все доры. Отсюда и их присутствие в выдаче.

Q: Почему раньше, если сгенерировать дор и повесить на главную страницу уник, то он лучше индексировался?
A: Видимо для ускорения прохождения сайтов через фильтр анализировалась только главная страница. Соответственно если на ней был уник, то фильтр проходился.

Q: Что лучше, отстаивать домен с заглушкой или с мини сайтом?
A: Склоняюсь к тому, что с мини сайтом. Скорее всего Яндекс не считает заглушку «Сайт в разработке» или приветственные страницы установленных CMS полноценными сайтами, поэтому прохождение через фильтры начинается только тогда, когда на сайте начинает что-то появляться. Отсюда, кстати, и тот факт, что полностью идентичные сайты (с только что установленным вордпрессом с тестовой записью, например) не склеиваются.

Q: Почему среднее время жизни хорошего дора порядка двух недель?
A: Проходят два первых фильтра, но не проходят третий. А это как раз неделя-две.

Q: Почему иногда доры банятся в междуапье?
A: Дор забанился во время очередного ежедневного апа. Раз забанился, значит спам и держать такой сайт в выдаче еще несколько дней не представляется разумным. Поэтому происходит синхронизация индекса, выложенного в паблик, с индексом, полученным в результате последнего апдейта.

Q: Почему иногда все доры у всех начинают очень быстро банится?
A: Обычно когда на всех форумах начинают писать, что доры стали резко банится, можно заметить либо тормозящие другие сервисы Яндеса, либо радостные сообщения в официальном блоге/блоге на Хабре о приобретении нового оборудования. Т.е. либо выделили новые мощности в ущерб чему-то, либо просто расширили техническую базу. В итоге сайты стали проходить через фильтры быстрее.

Из неприятного.

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

Из позитивного.

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

Продолжаю обживаться в Linux'е, хотя темпы изучения уже снизились на порядок. Все что необходимо для комфортной работы уже знаю, а «курить» ОСь глубже вроде бы и надо, но с практической точки зрения если эти знания и понадобятся, то не скоро. Поставил LAMP, чему просто несказанно рад, хотел, наверно, уже года два-три как. Еще начал учить MySQL, давно пора было, но руки дошли только сейчас, когда столкнулся с острой нехваткой знаний. Тема реляционных баз, SQL достаточно широка и сложна, но на «бытовом» уровне чаще всего углубляться в дебри не придется, поэтому разбираться досконально во всем тонкостях для себя пока не вижу смысла, знать о них — да, надо, но не более.

А, да. Еще впервые за все время счетчик RSS подписчиков несколько раз перешагнул отметку в 100 читателей. Приятно. Думаю, к концу августа 100+ будет уже не пиковым значением, а средним.

Из рутины.

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

Что заметил — я совершенно не умею писать хороший код. Если скрипт строчек на 100 (какое-то утилитарное решение, парсинг гугл картинок, например), то еще нормально, за исключением того, что это самое утилитарное решение будет выполнять только то, ради чего и писалось. Если на следующий день надо написать аналогичный скрипт, но выполняющий чуток другие функции, то вчерашние наработки использовать уже становится на порядок труднее, чем написать все с нуля. Ну а если код растягивается уже далеко за 100 строчек, то разобраться в своем же коде (если это "месиво" можно назвать кодом), чтобы что-то изменить или добавить изначально не планировавшийся функционал, становится практически нереально.

Так что сейчас прибываю в состоянии выработки своего стиля, максимально приближенного по моему мнению к идеальному. Изучение и применение ООП я откинул сразу на полгода-год, поэтому упор буду делать на применение везде и всюду пользовательских функций, наиболее абстрактные из которых вообще выносить во внешние файлы и юзать в других скриптах. Есть к примеру строка или массив строк, есть лесенка из фильтров, которые должны обработать эти строки. Зачем этот блок из 10-50 строк кода помещать в середину скрипта, когда можно создать свою функцию, на вход которой давать строку/массив строк, а на выходе получать именно то, что нужно? И код чистый, и логика в скрипте видна, даже если читаешь его через месяц после написания, и если что-то подправить нужно, всегда знаешь где и зачем. Красота. А еще, ИМХО, для скриптов, которые даже в перспективе будешь использовать только ты сам, нужно прикручивать удобный интерфейс, а не постоянно редактировать исходники, чтобы поменять, скажем, входные данные.

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

Сейчас деньги со счета списываются ежедневно в равных количествах, а не раз в месяц, как было раньше. После того, как в результате очередного списания ваш счет станет отрицательным, аккаунт не заблокируют и сайты продолжат работать, вы просто будете ежедневно уходить в минус. Так будет продолжаться несколько дней (в моем случае 4 или 5 дней, точно не знаю), причем каждый день на почту будет приходить уведомление о том, что у вас отрицательный баланс и сколько дней осталось до блокировки.

После деактивации аккаунта все ваши сайты станут вести на Петерхост, а списание со счета прекратится. Также вы получите письмо с уведомлением о приостановке действия вашего аккаунта.

Доступ в аккаунт останется доступным, причем сам аккаунт со всеми данными удаляется только по истечению 6 месяцев.

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

А так, естественно, советую постоянно следить за счетом и платить всегда за несколько месяцев вперед. У меня ситуация была банальной — заплатил около 2кр за хостинг (при стоимости 450р в месяц) и уехал на пару недель, а в это время автоматически продлилась регистрация трех доменов (зарегистрированных по розничным ценам через хостера), поэтому счет плавно и вышел сначала в ноль, а потом и в минус.

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

Статья рассчитана на начинающих пользователей Linux, поэтому содержит теоретические вставки и предполагает использование GUI там, где это возможно и оправдано.

В качестве дистрибутива Linux используется Ubuntu 10.04, хотя инструкция, надо полагать, справедлива как для других версий Ubuntu, так и для некоторых других дистрибутивов.

Установка Apache

Текущая версия Apache 2.2.Х, поэтому в качестве названия чаще всего будет фигурировать не «apache», а «apache2» или «a2».

Итак, заходим в менеджер пакетов Synaptic и вбиваем в поиск слово «apache2».

Пакет «аpache2» является метапакетом, его установка повлечет за собой установку пакетов apache2-mpm-worker (обеспечивает многопоточность), apache2-utils (содержит некоторые дополнительные утилиты для тестирования и управления сервером), apache2.2-bin (двоичные файлы), apache2.2-common (сценарии настройки и поддержки) и ряда библиотек. Все вместе весит чуть больше 10МБ.

Отмечаем пакет «apache2» для установки, соглашаемся с установкой дополнительных пакетов, нажимаем «применить».

Все, Apache установлен. Переходим в браузере по адресу http://localhost/, чтобы проверить работоспособность. Если все сделали правильно, должно вывестись сообщение «It works!».

Для проверки статуса сервера, его включения, выключения, рестарта или перезагрузки данных конфигурации используются следующие команды:

/etc/init.d/apache2 status
sudo /etc/init.d/apache2 start
/etc/init.d/apache2 stop
sudo /etc/init.d/apache2 restart
sudo /etc/init.d/apache2 reload

Start, restart и reload надо производить с root правами (используя sudo), в противном случае будет ошибка такого вида:

Permission denied: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down

Это связано с тем, что работать с портами 0-1024 можно только имея административные права (в данном случае используется 80-й порт, стандартный для веб-сервера).

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

Файл конфигурации Apache хранится по адресу /ect/apache2/apache2.conf. Привычный файл httpd.conf располагается в той же папке и предназначен для пользовательской конфигурации, поэтому изначально пуст.

Корневым каталогом для сервера является каталог /var/www. Если в него заглянуть, можно обнаружить файл index.html, именно содержание этого файла нам вывелось, когда мы набрали в браузере «http://localhost/».

Если при попытке старта, остановки или перезапуска выдается ошибка вида

Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName»

то стоит прописать ServerName вручную.

Открываем файл httpd.conf в редакторе gedit с правами администратора

sudo gedit /etc/apache2/httpd.conf

прописываем

ServerName 127.0.0.1

и сохраняем.

Установка PHP

Переходим в менеджер пакетов Synaptic и вводим в поиск «php5».

Отмечаем и устанавливаем метапакет «php5», в который помимо всего прочего входит модуль php5 для Apache libapache2-mod-php5.

PHP установлен, осталось только его проверить. Для этого создаем в папке /var/www файл test.php. Так как на папку www стоят права 755, никто кроме root-а не имеет прав доступа на изменения чего-либо в ней.

Наберем в терминале

sudo gedit /var/www/test.php

Это команда создает от имени администратора файл test.php и открывает его для изменения в текстовом редакторе gedit.

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

и сохраняем. К слову, созданный файл получил права 644, что также оставляет права на редактирование только за root-ом.

После этого перезапускаем Apache и переходим в браузере по адресу http://localhost/test.php. Если все сделали правильно, то должна вывестись информация о php:

Конфигурационный файл php находится в /etc/php5/apache2/php.ini, права на файл выставлены 644, поэтому что-либо изменить в нем можно только открыв файл для редактирования с root правами. Советую сразу в php.ini изменить строчку «display_errors = Off» на «display_errors = On», в противном случае если в коде будут какие-то ошибки, браузером будет отдаваться пустая страница без пояснений. Также не ищите в файле php.ini подключаемых расширений, код для их подключения находится в ini файлах в папке /etc/php5/conf.d. Этот каталог при каждом запуске сервера сканируется, и информация из расположенных в нем ini файлов подключается к главному конфигурационному файлу php.ini.

Установка MySQL

Переходим в Synaptic, вбиваем в поиск «mysql-server-5.1», отмечаем для установки пакет «mysql-server», который является метапакетом и потянет за собой как сам MySQL сервер последней версии, так и другие пакеты, в частности пакет MySQL клиента mysql-client-5.1.

Соглашаемся с установкой дополнительный пакетов и кликаем на «Применить». В процессе установки у нас скорее всего потребуют ввести и подтвердить пароль для root-пользователя базы данных (ничего общего с root-ом самой Linux он не имеет). Вводим, подтверждаем и ждем завершения установки пакетов.

СУБД MySQL установлена. По умолчанию создаются две базы данных, mysql (системная) и information_schema (своего рода информационная метабаза, данные в ней нельзя редактировать или удалять, только просматривать, также под нее не создается отдельного каталога).

Проверим, действительно ли создались эти две базы данных. Для работы в MySQL в консоле и выполнения SQL запросов воспользуемся утилитой mysql (входит в состав пакета mysql-client, который мы уже установили).

mysql -u root -p

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

show databases;

Должен вывестись список имеющихся баз данных, в нашем случае это mysql и information_schema.

Выходим из mysql:

exit;

Выглядеть это должно примерно так:

Для старта, остановки или перезагрузки MySQL используйте команды:

sudo /etc/init.d/mysql start
sudo /etc/init.d/mysql stop
sudo /etc/init.d/mysql restart

Главный конфигурационный файл MySQL находится в /etc/mysql/my.cnf.

Каталоги с базами данных по умолчанию находятся в /var/lib/mysql. Право на просмотр и редактирования содержимого этого каталога имеет только пользователь с root правами. Если постоянно вводить команду «sudo» не хочется, то можно запустить файловый менеджер Nautilus от имени суперпользователя. Нажмите Alt+F2 и наберите gksudo nautilus:

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

Более того, все файлы, открытые в запущенном от имени администратора Nautilus-е, также будут открыты от имени администратора, а соответственно и доступны для редактирования.

Установка phpMyAdmin

Консоль это конечно хорошо, но не слишком удобно. Поэтому установим phpMyAdmin, веб-интерфейс для администрирования СУБД MySQL.

Переходим в Synaptic, вбиваем в поиск «phpmyadmin» и отмечаем для установки пакет с аналогичным названием, соглашаемся на установку дополнительных пакетов, применяем изменения.

Во время установки пакета вам надо будет ответить на несколько вопросов. В качестве веб-сервера надо выбрать Apache2, согласиться с автоматической настройкой phpMyAdmin, ввести root пароль MySQL и назначить пароль для самой phpMyAdmin.

PhpMyAdmin установлен, переходим по адресу http://localhost/phpmyadmin/, вводим логин и пароль (который мы назначили в процессе установки phpMyAdmin) и оказываемся в административной части.

Файлы конфигурации phpMyAdmin хранятся в /etc/phpmyadmin, сам phpMyAdmin лежит в /usr/share/phpmyadmin, а не в /var/www, как можно было бы подумать (в конфигурационном файле /etc/phpmyadmin/apache.conf прописан алиас «Alias /phpmyadmin /usr/share/phpmyadmin»).

Установка модулей Apache

Скорее всего, нам рано или поздно придется ставить некоторые модули для Apache. Какие-то модули уже установлены, но не активированы, какие-то придется выкачивать используя все тот же Synaptic.

Скаченные и доступные модули хранятся в папке /etc/apache2/mods-available, включенные — в папке /etc/apache2/mods-enabled (папка содержит символические ссылки на доступные модули из папки mods-available).

В первую очередь нас интересует модуль mod_rewrite (если коротко — используется для ЧПУ, 301 редиректа, организации запрета хотлинков).

Модуль mod_rewrite у нас уже установлен (/etc/apache2/mods-available/rewrite.load), осталось его только активировать.

Для включения и выключения модулей используются следующие команды:

sudo a2enmod модуль
sudo a2dismod модуль

Где a2enmod расшифровывается как Apache2 enable module, т.е. включить модуль апача, а a2dismod наоборот, выключить.

Включим модуль mod_rewrite:

sudo a2enmod rewrite

и перезагрузим апач:

sudo /etc/init.d/apache2 restart

Мод установлен. Теперь, если мы перейдем по адресу http://localhost/test.php (где мы сделали вывод функции phpinfo), то в графе «Loaded Modules» мы увидим наш активированный модуль mod_rewrite.

Установка библиотек расширений PHP

В первую очередь, конечно же, надо установить библиотеку php-mysql для работы с MySQL функциями. Однако это библиотека у нас уже стоит, она требовалась для работоспособности phpMyAdmin и поставилась автоматически.

Поэтому ставить будем php-curl (Client URL Library). Заходим в Synaptic, набираем в строке поиска php-curl, отмечаем для установки, применяем. В отличии от предыдущих устанавливаемых нами пакетов, этот пакет ничего кроме php-curl за собой не потянет, т. к. является просто расширением.

После установки пакета в выводе функции phpinfo() должна появиться информация об установленном cURL.

Создание виртуальных хостов

По умолчанию корневой директорий у нас является /var/www, но это не очень удобно. Хочется для каждого сайта создать отдельную папку, получить полную свободу действий без ограничений по правам (хотя, конечно, и на /var/www права изменить никто не запрещает).

Создадим в нашем домашнем каталоге (/home/username) папку sites, в ней папку test.my, а в папке test.my папку public. Создадим и поместим в папку public файл index.php следующего содержания:

Теперь необходимо сделать так, чтобы при обращении в браузере к адресу http://test.my или http://www.test.my на экран выводилась надпись «Hello, world!».

Зайдем в папку /etc/apache2. Здесь мы увидим помимо прочего два каталога — sites-available и sites-enabled. Как и в случае с модулями, в папке sites-available хранится информация о существующих хостах, а в папке sites-enabled о подключенных, причем файлы в ней являются символическими ссылками на файлы из папки sites-available.

Создадим в каталоге sites-available файл test.my (к слову, назвать его можно как угодно, но так просто легче не запутаться) и откроем его для редактирования.

sudo gedit /etc/apache2/sites-available/test.my

Скопируем в него полностью содержимое файла /etc/apache2/sites-available/default (отрыть для чтения его можно просто двойным кликом) и внесем некоторые изменения.

После строчки

ServerAdmin webmaster@localhost

добавим

ServerName test.my
ServerAlias www.test.my

Заменим адрес директории

DocumentRoot /var/www

на директорию, созданную нами в своем домашнем каталоге

DocumentRoot /home/username/sites/test.my/public

Теперь разрешим использовать файл .htaccess для этого хоста.

Заменим строчку

<Directory /var/www/>

на

<Directory /home/username/sites/test.my/public/>

А также изменим значение

AllowOverride None

на значение

AllowOverride All

Без этих изменений файл .htaccess в корне нашего сайта будет игнорироваться.

Вместо username, естественно, надо поставить свой логин в системе. После чего закрываем файл с сохранением изменений.

В принципе, можно было изменить и директорию для сохранения логов, но это необязательно. К слову, папка test.my/public сделана исключительно для удобства, чтобы в случае чего создать еще test.my/log, test.my/tmp и другие, так что вместо /var/www можно указать и просто /home/username/sites/test.my.

Переходим к редактированию файла hosts.

sudo gedit /etc/hosts

Добавляем строчку

127.0.0.1 test.my www.test.my

и закрываем файл hosts с применением изменений.

Осталось только включить наш сайт, перезапустить апач и проверить, все ли работает нормально.

Включаем сайт:

sudo a2ensite test.my

Для выключения сайта используется команда

sudo a2dissite test.my

Перезагружаем апач

sudo /etc/init.d/apache2 restart

или

sudo /etc/init.d/apache2 reload

И переходим в браузере по адресам test.my и www.test.my. В обоих случаях должна выводиться надпись «Hello, world!».

Установка Drupal

LAMP у нас уже установлен, осталось его протестировать. Всякие phpinfo() и прочие «Hello, world» это конечно хорошо, но установка CMS поможет протестировать именно связку MySQL, php и кучи модулей и выявить проблемы, если таковые имеются. Итак, приступим.

Для начала создадим папку /home/username/sites/drupal1.my/public и настроим виртуальный хост для нашего будущего сайта.

Далее скачаем последний дистрибутив Drupal с официального сайта drupal.org и распакуем его содержимое в папку public. В папке с Drupal необходимо создать копию файла sites/default/default.settings.php и переименовать ее в sites/default/settings.php (сам файл default.settings.php изменять или удалять нельзя).

Если вы распакуете архив с Drupal в другую папку, а потом просто все скопируете в public, не забудьте перед самим копированием включить в файловом менеджере отображение скрытых файлов (в Nautilus-е это Ctrl+H или Вид/Показывать скрытые файлы). Дело в том, что файл .htaccess начинается с точки, а значит в Linux является скрытым. Если вы его не скопируете в папку с вашим сайтом, то как минимум не будет работать mod_rewrite.

Создадим БД для нашего сайта, воспользовавшись уже установленным phpMyAdmin. Базу назовем, к примеру, drupal1.

После того, как база данных создана, переходим в браузере по адресу drupal1.my. Нас должно средиректить на страницу установки drupal1.my/install.php?profile=default. Если редиректа не произошло, то сами переходим по адресу drupal1.my/install.php.

Выбираем «Install Drupal in English» и переходим к следующему шагу установки. Сразу могут посыпаться ошибки, связанные с правами доступа, но это решается довольно быстро.

Ошибка:

The Drupal installer requires write permissions to ./sites/default/settings.php during the installation process.

Проверим, какие права у нас стоят на файл settings.php

ls -l /home/username/sites/drupal1.my/public/sites/default/settings.php

Права стоят rw-r--r-- (или 644 в восьмеричной системе счисления), т.е. изменять файл может только его владелец. Изменим права на rw-r--rw-, или 646.

chmod 646 /home/username/sites/drupal1.my/public/sites/default/settings.php

Теперь вернемся к нашему Drupal и нажмем на ссылку «tray again». Ошибка должна исчезнуть.

Вторая ошибка, связанная с правами доступа, может звучать так:

The directory sites/default/files does not exist. An automated attempt to create this directory failed, possibly due to a permissions problem.

Drupal не может создать папку files, т.е. cкорее всего ограничены права на запись для папки default. Проверим их.

ls -ld /home/username/sites/drupal1.my/public/sites/default

Права rwxr-xr-x (или 755), а значит право на запись имеет только владелец. Изменим их на rwxr-xrwx (757).

chmod 757 /home/username/sites/drupal1.my/public/sites/default

Снова вернемся к Drupal и перейдем по ссылке «tray again». Ошибок с правами доступа больше быть не должно, и мы перейдем к основным этапам установки.

На первом этапе нас попросят ввести имя базы данных, имя пользователя и пароль к БД. Базу данных мы назвали drupal1, в качестве пользователя указываем root, пароль указываем тот, который мы вводили при установке MySQL. В разделе «Advanced options/Database host» оставляем localhost. Кликаем на «Save and continue».

На следующем этапе установки надо будет указать e-mail сайта (с которого будут рассылаться автоматические письма, всякие уведомления или напоминания пароля, первоначально можно написать любой адрес). Также необходимо указать регистрационные данные первого пользователя (логин, пароль, e-mail). Напомню, в Drupal'e первый пользователь является администратором и обладает неограниченными правами. Далее выставляем часовой пояс и разрешаем или запрещаем автоматическую проверку обновлений (по умолчанию разрешено). В пункте «Clean URLs» можете выбрать между «Disabled» и «Enabled», по умолчанию поддержка чистых ссылок включена.

На этом этапе установки Drupal уже внес все необходимые изменения в файл settings.php и папку default, поэтому в целях безопасности возвращаем им изначальные права (конечно, для тестов вопросы безопасности не так важны, но привычку делать все правильно надо вырабатывать изначально).

chmod 644 /home/username/sites/drupal1.my/public/sites/default/settings.php

chmod 755 /home/username/sites/drupal1.my/public/sites/default

После смены прав возвращаемся к Drupal и кликаем «Save and continue».

Скорее всего появится ошибка

Unable to send e-mail. Please contact the site administrator if the problem persists.

но у нас не стоит задачи поднять почтовый сервер, поэтому кликаем на «you new site».

Drupal работает, что подтверждает правильность установки и настройки LAMP.

Всего у меня на компьютере два винчестера, 160ГБ и 120ГБ. На первом стоит Windows XP и все остальное ПО, второй использовался для хранения всей нужной и не очень информации.

Изначально при установке Linux'а перенес все со второго винчестера на первый и установил Ubuntu, отдав под нее весь диск не особо вдаваясь в подробности. Хотя пункт «Указать разделы вручную (для опытных пользователей)» и выбрал в первую очередь, в итоге пришлось вернуться к «Использовать весь диск» и разрешить системе автоматически разметить винчестер. То ли встроенная в инсталлятор программа разметки диска глючила, то ли я что-то делал не так (что скорее всего), но переразметить диск под себя не получилось.

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

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

Каждому разделу винчестера, будь то основной или логический, в соответствие ставится UUID (Universally Unique Identifier) для его дальнейшей однозначной идентификации. Причем после форматирования одного из разделов, его UUID меняется (установил опытным путем).

В Линуксе отсутствует привычное с Windows буквенное название винчестеров (C:\, D:\ и т. д.), вместо этого используется немного другой подход.

Винчестеры в системе будут видны под названиями sd*, где * - это буква a-z, в зависимости от количества жестких дисков. Если их у нас в системе два, то называться они будут sda и sdb, если три, то sda, sdb и sdc.

Как уже говорилось выше, каждый винчестер должен иметь как минимум один основной раздел, при желании максимум четыре, один из которых можно назначить расширенным и создать в нем любое количество логических. Все эти разделы также имеют свое обозначение, состоящее из название самого винчестера и цифры, например sda1 или sdb5. Цифры идут по порядку, за исключением того, что цифры 1-4 зарезервированы под основные разделы (что и понятно, всего их может быть от одного до четырех), а нумерация логических начинается с 5.

Предположим, что мы разметили диск на два основных раздела, один из которых сделали расширенным и разбили на три логических. Тогда их названия будут такими (допустим, что сам винчестер называется sda): sda1 (первый основной), sda2 (второй основной, назначенный расширенным), sda5 (первый логический), sda6 (второй логический), sda7 (третий логический). Причем диск sda2 (расширенный) будет недоступен в системе, т. к. записать на него ничего нельзя, он является лишь контейнером для логических дисков.

Для разбивки жесткого диска решил воспользоваться утилитой GParted, она была доступна прямо с Live CD. По ощущениям, ничем не хуже Partition Magic, а в чем-то даже удобней.

Диск разметил следующим образом:

Разбил на два основных, первый выделил для хранения информации без привязки к ОС (поэтому и назначил файловую систему NTFS, прав доступа и прочих плюшек файловых систем Linux для просто данных мне не надо, а заставлять Windows видеть ext не хочется).

Второй основной отдал чисто под Linux, назначил расширенным и разбил на три логических. Раздел под своп сделал в 2 ГБ, много, конечно, еще ни разу больше 100МБ не использовалось, но сойдет. Тем более часто в мануалах советуют под своп выделять памяти не меньше объема оперативки (у меня 1,5ГБ).

Под сам Linux выделил 30ГБ. Остановился на файловой системе ext4. Выбрал ее, т.к. она по сути дефолтная для Linux'а. Потом еще почитал про нее немного теории и всяких тестов и еще раз убедился, что ext4 оптимальна, если нет каких-то специфичных требований, которые реализованы только в других ФС.

Каталог /home вынес на отдельный раздел, отдав под него все оставшееся место (получилось около 20ГБ). В принципе, оно понятно почему — держать свои собственные настройки и пользовательские файлы лучше отдельно, в случае перестановки системы ничего не потеряется.

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

Ну и немного о трудностях, с которыми пришлось столкнуться. Как выше писал, один раздел отформатировал в NTFS и настроил автоматическое монтирование в каталог /media/data. Все работало идеально. Потом зашел в Windows проверить, виден ли этот раздел. Потестив, решил отформатировать. При следующей загрузке Linux стали выдаваться ошибки, по тексту которых можно было догадаться, что что-то не так с монтированием. Как в последствии выяснилось, для монтирования жестких дисков Linux использует UUID винчестеров, а при форматировании этот самый ID сменился на новый, поэтому пришлось изменить конфиги. После правки все заработало как надо. Команды использовал такие:

cat /etc/fstab

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

ls -l /dev/disk/by-uuid

Смотрим текущие UUID-шники подключенных винчестеров. Если находим несоответствия с данными в файле fstab, то его надо поправить.

sudo gedit /etc/fstab

Открываем файл fstab в редакторе gedit с правами суперюзера, чтобы можно было сохранить результат, заменяем старый UUID на новый, который мы получили выполнив предыдущую команду, сохраняем изменения, перезагружаем компьютер. Ошибок монтирования при загрузке системы больше быть не должно.

По финансам опять все более чем удручающе, хватает только на ссылки, хостинг и прочие мелочи. Еще подошел срок продливать регистрацию пачке доменов, зарегистрированных в незапамятные времена через хостера у разных регистраторов по 600 р. за штуку. Все никак не соберусь перенести их к единому регистратору.

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

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

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

Ну и как всегда небольшое планирование деятельности на текущий месяц. Ну, во-первых, для начала не мешало бы... Хотя нет, надо быть лаконичней. Цель на месяц — пахать, а не планировать.

Около двух месяцев назад я анонсировал эксперимент «дорвеи и текстовка». Что ж, пора поделиться результатами.

В двух словах о самом эксперименте. Было сделано суммарно 18 дорвеев, протестированы шесть вариантов текстовок (по три дора на каждый).

Домены брались нулевые, на которые вешались заглушки «сайт в разработке» на срок примерно полторы-две недели, до тех пора пока эти самые заглушки не попадут в индекс. После чего выжидалось какое-то время (от нескольких дней), и доры начинали заполняться контентом, по 10+ постов в сутки.

Количество страниц у каждого дора небольшое, 100+ самих статей, плюс навигация по страницам, рубрикам и тегам.

Слива трафика не было чисто принципиально, чтобы не нарушать чистоту эксперимента.

• 3 дора на генерированном контенте

  На всех трех дорах текстовка делалась по одной схеме. Было взято 100+ метров текстовки (источники точно не вспомню, но их было много, в основном книги в txt). 100 метров текста разбивалось на пять равных частей, на основе каждой полученной текстовки генерировался дорвей на несколько сотен страниц доргеном RBT с разной степенью уникализации. В итоге получилось пять сгенерированных дорвеев из исходника в 20+ метров для каждого, и на основе их контента и заполнялись три экспериментальных дора. Т.е. на конечном дорвее подряд шли статьи, сгенерированные из разных текстовок с разной степенью уникализации. Сделано это было с целью понизить вероятность распознавания сгенерированного текста Яндексом.

  #1 дорвей
  1АП – 7 страниц
  2АП – 2 страницы
  3АП – 2 страницы
  4АП – 3 страницы
  5АП – 4 страницы

  #2 дорвей
  1АП – 4 страницы
  2АП – 5 страниц
  3АП – 5 страниц
  4АП – 5 страниц
  5АП – 9 страниц

  #3 дорвей
  1АП – 53 страницы
  2АП – 10 страниц
  3АП – 7 страниц
  4АП – 5 страниц
  5АП – 9 страниц

  До сих пор в индексе у каждого <10 страниц, полностью не вылетел ни один дор.

• 3 дора на синонимизированном контенте

  Синонимизировал исключительно AllSubmitter-ом.

  #1 дорвей
  В качестве текстовки использовался сервис Гугл Новости (агрегатор новостников).
  1АП – 7 страниц
  2АП – 1 страница
  3АП – 0 страниц
  4АП – 0 страниц
  5АП – 2 страницы

  #2 дорвей
  В качестве текстовки использовались адалт рассказы.
  1АП – 21 страница
  2АП – 93 страницы
  3АП – 0 страниц
  …

  #3 дорвей
  В качестве текстовки использовался сервис Яндекс Новости (агрегатор новостников), адалт рассказы. Вся текстовка была перемешана.
  1АП – 83 страницы
  2АП – 138 страниц
  3АП – 0 страниц
  …

  В итоге из трех доров на данный момент в индексе только один с двумя страницами (без главной).

• 3 дора на транслите

  Перевод с английского на русский Гуглом.

  #1 дорвей
  В качестве текстовки использовался сервис Гугла «Поиск по блогам».
  1АП – 14 страниц
  2АП – 0 страниц
  …

  #2 дорвей
  В качестве текстовки использовался агрегатор новостей Гугла.
  1АП – 0 страниц
  …

  #3 дорвей
  В качестве текстовки использовались сервисы Гугла «Гугл Новости» и «Гугл Блоги», примерно в равных пропорциях.
  1АП – 3 страницы
  2АП – 0 страниц
  …

  Из трех доров на транслите не выжил никто.

• 3 дора на копипасте

  #1 дорвей
  В качестве текстовки использовался сервис «Яндекс Новости». Статьи подбирались тематические.
  1АП – 72 страницы
  2АП – 145 страниц
  3АП – 98 страниц
  4АП – 0 страниц
  …

  #2 дорвей
  В качестве текстовки использовались адалт рассказы.
  1АП – 10 страниц
  2АП – 0 страниц
  …

  #3 дорвей
  В качестве текстовки использовался сервис «Яндекс Новости», адалт рассказы, анекдоты и т.д.
  1АП – 10 страниц
  2АП – 9 страниц
  3АП – 9 страниц
  4АП – 9 страниц
  5АП – 10 страниц

  Из трех доров выжил только один, количество страниц в индексе у которого не более 10.

• 3 дора без контента

  Имеется ввиду в виду без текстового контента. Только тайтлы и альты к картинкам.

  #1 дорвей
  Контент – ролики с ютуба. По одному на пост.
  1АП – 120 страниц
  2АП – 186 страниц
  3АП – 230 страниц
  4АП – 0 страниц
  …

  #2 дорвей
  Контент – ролики с ютуба и картинка, спарсенные с Гугл Картинок по англоязычным запросам.
  1АП – 75 страниц
  2АП – 182 страницы
  3АП – 222 страницы
  4АП – 0 страниц
  …

  #3 дорвей
  Из контента только картинки, по 2-6 на пост, одна в анонсе, остальные под катом. Прописанные альты.
  1АП – 57 страниц
  2АП – 124 страницы
  3АП – 152 страницы
  4АП – 0 страниц
  …

  Все три дора вылетели полностью.

• 3 дора на унике

  Контент уникальный. Источник – обсуждения во вконтакте. Объем контента на каждый пост от 0.2к до 2к символов. Использовался кат для постов больше 600 символов.

  #1 дорвей
  1АП – 15 страниц
  2АП – 99 страниц
  3АП – 124 страницы
  4АП – 0 страниц
  …

  #2 дорвей
  1АП – 28 страниц
  2АП – 186 страниц
  3АП – 236 страниц
  4АП – 0 страниц
  …

  #3 дорвей
  1АП – 65 страниц
  2АП – 128 страниц
  3АП – 10 страниц
  4АП – 10 страниц
  5АП – 10 страниц

  Из трех доров на унике два вылетело, один остался с 10 страницами в индексе.

Апдейты указались не все, а только значащие. Однако указанные апдейты для каждого дора идут один за другим, чтобы лучше прослеживалась статистика. Изначально каждый дорвей был в индексе страницей-заглушкой.

Все дорвеи были на одном хостинге, на одном ip. На всех стояла статистика LI, и все были добавлены в панель вебмастера Яндекса. Средняя продолжительность пребывания уника на страницах дорвея, а также количество просмотренных им страниц, отлична от нуля. Кто-то даже участвовал в опросах (на многих дорвеях был установлен модуль опросов).

Часть доров побанилась, часть попала под АГС. Некоторые фильтровались сразу, некоторые успели полностью проиндексироваться.

Писать какие-то абстрактные выводы исходя из результатов эксперимента на тему «какая текстовка лучше», не буду. Эта тема отдельно поста, здесь же только результаты эксперимента.

Последние несколько лет было желание не то чтобы перейти, а просто хотя бы попробовать Linux, чисто ради интереса. Но руки все как-то не доходили, да и предпосылок не было — Windows XP устраивала более чем. Точнее, раньше устраивала, когда не было с чем сравнивать.

И вот недавно понадобилось поюзать Линукс, загрузился с Live CD без установки, поигрался немного и как-то сразу «подсел». Подкупила визуальная составляющая — по качеству и продуманности интерфейсов XP остается далеко позади. Это было для меня первым откровением, раньше я считал, что Linux это «навороченная командная строка», без которой абсолютно ничего нельзя сделать. Ошибался, все оказалось интуитивно понятным и достаточно красивым.

Дальше — больше. Наличие множества «фич», которые вроде как и не нужны были раньше, но воспользовавшись которыми единожды, уже не представляешь себя без них. Например, возможность использовать любое количество рабочих столов, переключаясь между ними одним кликом или горячими клавишами. Частенько приходится одновременно держать открытыми много разнообразных приложений, из-за чего постоянно возникала путаница с окнами — а здесь такое простое и элегантное решение. Или еще пример — сейчас у меня рядом с текущим временем на панели отображается температура с пиктограммой погоды. Мелочь? Мелочь, но приятно.

Это что касательно «визуального» восприятия, но логически продуманный подход в Линуксе проявляется во всем. Программы устанавливаются сугубо в определенное место, по необходимости занося информацию в системную папку пользователя. А если вспомнить Windows? Программа пишется в папку Program files, добавляет свои файлы в Document and settings, не гнушается что-то записать в windows и даже иногда сама создает какие-то директории в корне винчестера, плюс реестр, который если и пытаешься регулярно чистить, то вскоре оставляешь эту затею. А ведь может быть иначе. Может быть правильно. Как в Линуксе.

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

Отдельного внимания заслуживают так называемые «репозитории», архивы программ. В официальных репозиториях можно найти если не все, то практически все необходимые программы. И скачивать вы будете их не с варезников, а с официальных источников. Установка/удаление ПО занимает не больше минуты. Причем удаляется программа полностью, не оставляя после себя следов в «реестре», которого здесь, к слову, вообще нет как такового. Если какая-то версия ПО обновится — вы сразу же получите об этом уведомление, да и само обновление не займет много времени. Теперь не надо качать дистрибутив нужной программы, запускать инсталлятор, на автомате расставлять флажки и кликать «далее», потом удалять выкачанный уже ненужный дистрибутив и изредка проверять обновления, т.к. на уведомления чаще всего надеяться не приходится. В Линуксе все происходит само и именно так, как надо.

Все эти восторженные изливания связаны конечно же с тем, что на Linux я перешел совсем недавно (окончательно поставил только вчера), соответственно и впечатлений много. Но если подходить сугубо с практической точки зрения, то картина должна быть примерно такая: есть поставленные задачи, есть средства их решения (в данном случае ОСи), и выбор должен быть как минимум аргументирован (то, что Linux-ом пользуется 0.8% процента аудитории интернета по статистике LI, а значит его использование автоматически превращает пользователя в тру айтишника, не аргумент, да и вообще далеко от истины).

Итак, что же требуется для работы и прочего времяпрепровождения «сферическому вебмастеру в вакууме»?

• Серфинг
  Никаких проблем, Opera, FF, Chrome есть под Линукс. IE, думаю, мало кто использует, ну разве что кроме верстальщиков для тестов.

• Работа с сайтами/сервисами
  Чаще всего это веб-интерфейс, поэтому проблем быть не должно.

• Работа с текстом
  Не думаю, что многим уж так требуется весь функционал пакета Microsoft Office, OpenOffice чаще всего покроет все потребности. Проверка орфографии, кстати, тоже имеется.

• Музыка/фильмы/игры
  Плееров великое множество на любой вкус, нужные кодеки ставятся без проблем. С играми, да, проблемы. Но я не считаю это минусом, т.к. последние несколько лет папка Games у меня отсутствует, убивать время можно более продуктивно, ИМХО.

• Работа с файлами, создание/копирование/удаление
  Все аналогично работе в Windows.

• Специализированный софт
  Чаще всего замену можно найти. Но не всегда. Тот же AllSubmitter работает только под виндой. Хотя, конечно, никакому профессиональному софту от того же Adobe аналогов найти не удастся.

• Дизайн, работа с графикой
  Вот тут, конечно, без Photoshop-а не обойтись, достойной альтернативы ему нет, последние версии под Линуксом не идут, так что рисовать дизы придется только под виндой. Ну а для не слишком сложной работы с графикой идеально подходит Gimp.

• Верстка, программирование
  Редакторов текста с подсветкой синтаксиса много. Всяких специализированных сред разработок тоже хватает. Единственный минус — я обычно верстаю и что-то правлю в дизайне одновременно, поэтому наличие открытого фотошопа с макетом чаще всего обязательно. Ну а для веб-программирования лучше Линукса вряд ли что-то может быть, на то он и LAMP. Денвер он для простеньких скриптиков, в основном чтобы «перекантоваться», для серьезного изучения и работы не подходит. Связку Апач+пхп+мускл на винде я поднимал, но как-то все глючило, а в итоге и сервер MySQL умер, переустанавливать Windows не хотелось, поэтому и пришел к Denwer-y.

Еще, конечно, из плюсов Линукса стоит выделить следующие:

• Безопасность. Можно смело забыть о вирусах.

• Неубиваемая система. Если ядро не трогать, то что-то поломать проблематично, поэтому постоянно ставить систему по новой, «чтобы быстрее работало и меньше глючило», совершенно не надо.

• Наличие большого количества качественной документации, в том числе и на русском.

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

Из дистрибутивов Линукса остановился на Ubuntu 10.04, игрался с девяткой (пока десятая не вышла), ставил альфа версию 10.10 (но она частенько зависала). Почему именно Ubuntu? Не хотелось бы употреблять слово «попсовая», пусть будет популярная. Так вот — Ubuntu популярная. Ей пользуются большинство линуксоидов (судя по опросам), она удобна и понятна человеку, только что перешедшему с Windows, для нее много софта, документации и т.д. Т.е. так как у меня не было к дистрибутиву особых требований, то выбрал тот, с которым у меня будет меньше всего проблем. И считаю, что не прогадал. Пока все устраивает.

А вообще, конечно, Linux сложнее на порядок Windows. Даже если не брать в расчет тот факт, что приходится перестраиваться и что «разрывы шаблона» будут на первоначальном этапе на каждом шагу (нет диска C:\, нет exe-шников, четкое разграничение прав доступа...). По сути, чтобы работать в Windows, в самой Windows разбираться не надо, да и если очень захотеть, вряд ли получится, нормальной документации нет, все сводится в большинстве случаев к теоретическим рекомендациям «ткнуть туда, скачать ту софтинку, должно заработать». С Linux-ом же не получится работать, именно работать, а не юзать только для «вконтактика и фишек», без хорошего знание системы, в том числе и базовых основ (что, куда и зачем начиная с файловой системы). Но изучение лично мне доставляет сплошное удовольствие, это интересно, это полезно, это просто необходимо. А в купе с хорошей документацией и сообществом — не так уж и трудно.

И да, от Windows я не в коей мере не отказываюсь, да и не получится, слишком уж много софта идет только под нее. Но буду использовать ее только при необходимости использования этого самого софта, а ОСь по умолчанию теперь — Linux и только Linux. Чего и вам советую.

PS Пост получится местами ламерским. Но вот такое вот у меня впечатление от Линукса после многолетнего сидения исключительно под Windows.

PPS На блоге появилась рубрика «Linux», буду изредка в нее писать. Тема сама по себе достаточно обширная, и не на все вопросы можно найти исчерпывающий ответ в документации. Блоги и обсуждения на форумах в этом случае частенько выручают, почему бы и самому не поделиться мыслями/опытом. На то он и блог.

Надеюсь, что это если и не последние «безциферные» итоги месяца, то как минимум одни из последних. Крайне на это надеюсь.

Если по существу, то первая часть мая прошла абсолютно впустую. У меня так частенько бывает – взглянешь на календарь, уже число 15-е, хотя вроде как вчера было только первое, пытаешься вспомнить, куда же пропала половина месяца – и не получается. Впустую спущенное время.

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

После с головой погрузился в дорвеи в рамках текущего эксперимента, к тому времени как раз домены выстоялись и попали в индекс заглушками. Итого 10+ дней ежесуточного батрачества с перерывами только на сон.

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

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

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

Факторов, влияющих на автобан или вылет дора из индекса, великое множество. Но основной, конечно же, это текстовка, т.е. контентная составляющая.

Цель эксперимента – выявить лучший источник контента для дорвеев. В идеале добиться того, чтобы фильтр за текст не налагался вообще.

Будет протестировано использование шести разных вариантов текстовок, по три дора на каждый вариант:

• 3 дора на генерированном контенте
  Использоваться будет встроенный в RedButton генератор.

• 3 дора на синонимизированном контенте
  Синонимизировать буду с помощью AllSubmitter-а.

• 3 дора на транслите
  Перевод с английского на русский гуглом. Будет найден такой тип контента, при котором полученный перевод остается читаемым и морфологически правильным. Т.е. «сложные» статьи не подходят, нужно будет найти «simple English text», может форумы, детские сайты, обучающие ресурсы и т.д.

• 3 дора на копипасте
  Чистый копипаст.

• 3 дора без контента
  Точнее без текстового контента. Только картинки, ролики с ютуба и т.д.

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

Для чистоты эксперимента никаких дорогенераторов использовано не будет. Все дорвеи будут сделаны вручную, на CMS Drupal.

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

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

Сколько будет страниц на каждом доре, не знаю. Не меньше 100 точно. Скорее всего от 500, в идеале около 1000 и больше. Сказывается то, что все посты будут создаваться руками, а 1000 постов на 18 сайтах – это 18к публикаций. Даже если в минуту постить по три новости (форматирование, нормальный заголовок и т.д.), то это займет 18к/(3*60)=100 часов чистого времени. Так что скорее всего буду заполнять каждый сайт по мере попадания страниц в индекс, ибо зачем заполнять дор на 1к страниц, если еще даже опубликованные 100 не проиндексировались. Также вполне возможно, что будет настроена отложенная публикация, т.е. 100 страниц не сразу создаются, а автоматически по 5-15 в сутки.

Ключи буду собирать сам и объединять с паблик базами. Помимо автоматической чистки, все кеи просмотрю вручную, чтобы не было мусора. Ключи для доров пересекаться не будут, т.е. вся база поделится на 18 частей (чтобы в топе по нч не висело более одного моего дора).

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

Да, забыл про тематику сказать. Тематику выбрал дэйтинг, как одну из самых сложных, трафикогенерирующих и денежных. По поводу сложности, бытует мнение, что сайт подвергается той или иной проверке в зависимости от ключевых слов. Т.е. ПС слишком затратно каждый сайт скрупулезно изучать на сгенерированность, поэтому были выделены тематики, наиболее популярные у дорвейщиков, и сайты по ним анализируются тщательнее, нежели по другим. Иными словами, если дор на какую-то узкую тематику не вылетел из-за текстовки, то использую эту же текстовку, только для дэйтинг ключей, дор улетит в бан в считанные дни, если не часы.

Что сделано на данный момент? Пока только зарегистрированы и привязаны к хостингу домены, доделывается сборка Drupal, подобраны шаблоны.

Планы примерно такие: на днях залить и настроить движок на всех 18-ти дорах, написать приветственную страницу аля «Скоро здесь будет лучший сайт знакомств», дождаться пока все доры влезут в индекс главной страницей (если главная страница какого-то сайта упорно не хочет лезть в индекс, то он удаляется и заместо него создается новый), подождать несколько апов, и уже только тогда начинать заполнять контентом.

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

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

О результатах эксперимента напишу, как только все доры забанятся, т.е. не раньше чем через месяц.