Максимум что мне приходило на почту- это была первая версия Дыбалы, которую мне в свое время переслали ребята из РТКОММа и я тогда конечно намучился, получая по почте около 150 мегов. Так что когда 5-6 лет спустя я обнаружил у пользователя в почтовом ящике письмо с вложенным роликом на полгига, которые он пытался отправить по почте, я даже не удивился.

Вообще пользователей стоит приучать к тому, что максимальное вложение письма должно составлять 20-25 мегов, но и даже таких объемов идеально избегать, пользуясь архиваторами и не забывая о том, что почтовые программы (больше всего конечно мелкомягкие) любят дописывать от себя 10-15%. И если твой админ позволяет отправлять 30+ метров почты, то это не значит что на принимающей стороне работает такой же добряк. Вообще большие сообщения это головняк для админа, так как они загружают почтарь который вынужден держать сессию на получение такого письма, да к тому же забивают почту. Поэтому пользователей стоит приучать использовать другие механизмы передачи файлов через интернет. Естественно, что админ может предложить юзверям пользовать общедоступные веб-ресурсы, вроде депозита или рапидшары, но более корректно в моем понимании- это иметь собственный FTP сервер, позволяющий выкладывать и скачивать с него файлы.

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

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

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

На счет подключения к веб-серверу- тут все просто- просто прописываем либо субдомены для каждой папки, либо паролим каждую папку и даем адреса вида: наш_сайт/папка1

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

В этой связи существуют несколько видов борьбы с DDoS атаками:
1. Прежде всего ваш хостинг должен иметь защиту на уровне провайдера, так как часть атак можно отфильтровать на уровне доступа к сети, путем бана определенных пакетов, или же определенных IP адресов и сетей. Естественно что подобное оборудование весьма дорогостоящее, и только небольшая часть хостингов предлагает подобную защиту.
2. На самом сервере должны быть установлены необходимые заплатки, позволяющие не реагировать на различные типы DDoS атак, а также анализатор пакетов позволяющий отправлять в бан атакующие адреса.
3. Использовать сторонние сервисы, на которые средствами DNS заворачивается трафик, и они либо проксируют доступ к серверу, либо выдают статический контент на своей стороне. Естественно что эти услуги крайне не дешевы, поскольку используют избыточные серверные мощности.

Вот собственно на подобных сервисах, я бы и хотел остановиться отдельно:
1. Qrator.net – расписано все очень слажено, но по деньгам выходит жестковато. Пишут, что работают на ура, и все проблемы решабельны. Правда и денег за эт просят не мало.

2. DDoS-protection – тоже выглядит довольно убедительно и отзывы хорошие, но не понятно что по деньгам. Видимо такие суммы, что не стоит публиковать, чтобы не отпугнуть потенциальных клиентов. Но судя по подборке клиентов, сервисом много кто пользуется.

3. Как сказали на мауле хостинг Hostace вроде как специализируется на подобных решениях. У них в услугах не указано, так что видимо это выводится из личной беседы со спецами, типо как аренда хрумака. О которой никто не говорит, но она подразумевается.

4. Также на мауле есть чел, который как раз предлагает фронт-энд на своем или вашем оборудовании. Собственно его контакты есть в теме.

Изначально я планировал поднять стрим-сервер на VLC под FreeBSD и спокойно все транслировать в интернет, но закрутился на пару дней с другим проектом, и когда вернулся обратно к изысканиям мне радостно сообщили что уже подняли Microsoft SharePoint, к которому надо всего ничего- добавить возможность стрим-видео.

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

2. Попытаться прикрутить плеер написанный для SharePoint 10, но основная проблема заключается в том, для меня по крайней мере, что придется осваивать SharePoint (чего делать совсем не хочется) на уровне администрирования, ибо с полпинка эта ботва не подключается, так как помимо завода через терминальную строку, плеер где то необходимо включать, но особенности русского перевода не позволяют этого сделать с ходу, ибо облазив все менюхи, я так и не смог найти необходимый раздел. К тому же необходимо вносить исправления в код, чего делать опять же нет никакого желания, так что планирую напрячь юного падавана, но возникают серьезные сомнения.

3. Тупо создать видиотеку и сыпать в неё swf файлы, ибо они отыгрываются нормально по vpn-соединению. Будет конечно кузяво, но зато просто. По крайней мере этот вариант у меня точно будет работать, пока я не разберусь с окончательным решением.

4. Еще один способ для стрим видео под  SharePoint завести все через Windows Media Services (WMS), через настройку сервера WMS и его отображения в SharePoint. Единственный минус, что как я понял с помощью этого способа можно создавать страницы, что мне не очень подходит, ибо заводить для каждого ролика свою страничку или подгружать их на страницы дело интересное, но нудное. И вероятнее всего это станет обязанностью падавана.

5. Также есть плагин создания специального видео поля, для вставки flv-файлов и роликов с ятупы, написанное канадским разработчиком Stephen Huen. Качнуть его можно с сайта кодировщиков.  Но на него, к сожалению, накладываются те же ограничения что и способ номер 4, то есть под каждое файло придется подгружать свою страничку, что не особо удобно.

6. Ну и последнее, но не менее гиморное- это добавление видео-файла средствами мелкомягких. Оно расписано на их офф.сайте, но помимо того что с его реализацией те же проблемы, что и в пунктах 4 и 5, так еще и части указанных в руководстве разделов нет в бесплатной версии SharePoint Foundation, идущей в нагрузку с сервачной лицензией.

Но самое главное, что я вынес из всей этой мозголомки, то что SharePoint это реально гиморой на задницу, который гораздо проще решить например средствами того же Wordpress или Joomla, если бы клиенты обладали хотя бы частью разумения. И поработав за последние несколько лет наверное уже с десятком CMS’ок, у меня появился лидер в желтой майке, которого я теперь буду советовать после Битрекса- и это Microsoft SharePoint. Другое дело, что вероятнее всего это дело подключается гораздо проще на платных версиях SharePoint, но стоимость лицензии такова, что реализация более интересного и гибкого решения на базе Drupal’a, которое я изначально предложил клиенту, встанет либо дешевле, либо в те же деньги.

Но это уже совсем другая история.

Взять то я его взял, но вебмастера не могли ничего делать, так как на любую операцию система ругалась:
ERROR 1135 (HY000): Can’t create a new thread (errno 11); if you are not out of available memory
gzip: error while loading shared libraries: cannot create cache for search path: Cannot allocate memory
подключившись, я обнаружил что при попытке логина по ssh вылетала ошибка:
bash: fork: Cannot allocate memory

То бишь сделать ничего мог, так что отписался суппорту, что вот есть проблема с серваком. так что решите плиз. Суппорт же начал меня грузить на предмет того, что мне надо с апгрейтиться до 1Gb чтобы у меня все стало отлично, так как ось и Direct Admin отжирают все 512Mb. Я же давил на то, что top, к которому я таке смог пробиться показывает что занято всего 42% памяти и значит парни не тока оверселят, но еще и оверлодят память.

В таком духе мы препирались часов 5, поскольку мне некогда было лезть и особо разбираться. Я пару раз обложил в сердцах суппорт матюгами, после чего они начинали шевелиться быстрее, но все равно начинали втулять мне необходимость покупки 1Gb. Хотя по началу я хотел забрать бабло, накатать абузу в палку, в итоге во втором часу решил все таки глянуть более предметно, что происходит. Кстати в этом ключе- суппорт вещь такая- буквально в парралель  меня упал мой VPS и если честно я решил что это месть Burst, но оказалось что там была проблема с диском и другой чувак мне все замечательно и быстро решил, тем более что я конечно нервничал, так как буквально на этой неделе запилил два симпотных сайта, а бэкап датировался естественно началом сентября.

Ну вообщем сунулся кое как в сервак и понял, что мускуль кушает под себя 360Mb, так как грузится без файла конфигурации. Уж не знаю- толи забыли создать при первоначальной настройке, толи удалили в сердцах вебмастера, но пришлось озадачиться тюнингом MySQL под сервер с 512M, поместив в файл /etc/my.cnf следующие строки:
[mysqld]
local-infile=0
socket = /var/lib/mysql/mysql.sock
max_connections=300
slow-query-log
query_cache_limit=16M
query_cache_size=32M
key_buffer=16M
sort_buffer=64M
read_buffer = 2M
read_rnd_buffer_size = 768k
read_buffer_size=64M
max_allowed_packet=16M
thread_stack = 128K
skip-innodb
table_cache = 64M
Поскольку у меня оказалась InnoDB (правда не совсем понятно с какой целью мне ее прикрутили, хотя вебмастеров по форумам я именно ей и пугал при разговорах о горячем бэкапе), то пришлось поиграться с её параметрами, так как стандартные в 50-80% от RAM для innodb_buffer_pool_size забивали систему под 500 Mb, и в этом случае параметр skip-innodb убирается
innodb_buffer_pool_size=16M
innodb_additional_mem_pool_size=8M

После перезагрузки система зашуршала, отбирая под себя 440Mb.

Пришлось еще повыкидывать несколько параметров, так что файл приобрел вид:
[mysqld]
local-infile=0
max_connections=300
read_buffer_size=1M
sort_buffer=1M
log-slow-queries
query_cache_limit=256K
key_buffer=1M
innodb_buffer_pool_size=16M
innodb_additional_mem_pool_size=8M
max_allowed_packet=16M

После чего система стартанула уже с 350Mb, с которыми уже можно было в принципе жить.

Хостинг конечно хороший, но как попадешь на тупаря в суппорте, так хоть стой, хоть падай.

И вот сегодня посещалка на основном блоге, на котором она уже с месяц не поднималась выше 340 уников, неожиданно поползла вверх, преодолев сначала порог в 400 суточных уников, а потом и подтянувшись к 490, что заставило меня закрыть, открытый в кои то веки WoW и полезть в инет за разъяснениями. Проанализировав логи LI я увидел незначительный прирост трафика с Google- порядка 7% и некоторый с Mail – 4,5%, что навело меня на мысль о том, что возможно это как то связано в Google.

И после непродолжительного гугления, оказалось что действительно- 28 сентября Google анонсировал новую версию поискового движка Панда, сведшего в никуда труды многих вебмастеров в бургонете и в таком же виде добравшегося до рунета. Эта версия панды 2.5, по заявлениям разработчиков, также направлена на ротацию качественного контента, и является одним из 500 изменений, вносимых в поисковый алгоритм за год. Вообщем обычная пустая вода ни о чем, но факт остается фактом, трафик на мои молодые сайты и несколько основных, вернулся, если не в полной мере, то уже с минимальными потреями, так что остается надеяться, что он продержится некоторое время в таком состоянии.

Причем в бургонете, народ отреагировал матюгами, так как у народа траф с 30 сентября упал в несколько раз. Больше всего в этой связи меня умиляет мой “Одминский блог”, которому все фильтры пока, совершенно фиолетово, ибо когда пришла первая панда, он как раз перевалил за 500 ежесуточных пользователей, так что траф составил около 750-800 посетителей, а на данный момент он преодолел еще один идеологический барьер в 600 уников, заделав в понедельник 880 посетителей в сутки по Statpress.  Примерно также себя чувствуют и мои старые проекты, слегка подрастая в посещалке, но в основном- не проваливаясь столь ужасно как новые сайты.

В процессе рысканья обнаружил график обновления поискового алгоритма Панда, с периодами действия, так что привожу его здесь:
* Panda Update 1.0: Feb. 24, 2011
* Panda Update 2.0: April 11, 2011 (about 7 week gap)
* Panda Update 2.1: May 10, 2011 (about  4 week gap)
* Panda Update 2.2: June 16, 2011 (about 5 week gap)
* Panda Update 2.3: July 23, 2011 (about 5 week gap)
* Panda Update 2.4: August 12, 2011 (about 3 week gap)
* Panda Update 2.5: September 28, 2011 (about 7 week gap)

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

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

В файл /etc/rc.conf добавляем строку запускающую наш сервер доменных имен:
named_enable=”YES”
Открываем наш файл, отвечающий за локальных резолв /etc/resolv.conf и меняем его содержимое (вероятнее всего там стоит провайдерские DNS), на следующие строки, содержащие ваши домены:
domain  your-domain.ru
search host.your-domain.ru your-domain.ru
nameserver 127.0.0.1
для того чтобы сделать поиск доменных имен по кешу локального сервера.
Проверяем в файле /etc/nsswitch.conf наличие записи
hosts:      files dns
говорящей о том, что при резолве имен сначала будет использоваться информация содержащаяся в файле /etc/hosts, а затем запрашивать у доменных серверов, в соответствии с описанием в файле /etc/resolv.conf
После этого в файл /etc/host.conf добавляем строку
order hosts,bind
которая разрешает ту же последовательность, что и в файле /etc/nsswitch.conf
После этого переходим к настройке основного файла конфигурации любого доменного сервера, а не только кеширующего: /etc/namedb/named.conf. Для начала добавляем и раскомментируем следующие опции, идущие списком после директивы options {
Каждая строка, а также перечисление например IP адресов, должно закрываться символом точки с запятой “;”
Определяем на каких интерфейсах слушать входящие пакеты:
listen-on       { 127.0.0.1; 192.168.0.1; 172.16.0.1; };
Данную строку следует прописывать, если возникают какие то проблемы с фаерволом:
query-source address * port 53;
Также если охота поиграться с безопасностью, то можно озвучить сети, из которых разрешены запросы (сети определяем перед директивой options), а также отрубить фингерпринт и включить обработчик рекурсивных запросов:
acl “our_lanz” { 192.168.0.0/24; };
options {
directory “/etc/namedb”;
allow-recursion { “our_lanz”; };
allow-query {“our_lanz”; };
version “unknown”;
fake-iquery no;
};
Добавляем директивы запросов к DNS провайдера, для того чтобы дергать запросы из них и тем самым облегчить работу сетки:
forwarders {
NS_IP1; NS_IP2;
};
forward first;
На этом в принципе можно и остановиться, ибо все должно уже начать шуршать, после перезапуска сервера доменных имен, но для того чтобы произвести классические действия- идет в описание доменных зон и добавляем локальные зоны:
zone “.” {
type hint;
file “named.root”;
};
zone “0.0.127.in-addr.arpa” {
type master;
file “master/127.0.0″;
};
Надо отметить, что все эти файлы указываются от корневой директории named.conf, так что создаем упомянутый файл /etc/named/master/127.0.0
@               IN      SOA     host.your-domain.ru. hostmaster.your-domain.ru. (
1       ; Serial
8H      ; Refresh
2H      ; Retry
1W      ; Expire
1D)     ; Minimum TTL
NS      host.your-domain.ru.
1                       PTR     localhost.
и проверяем что файл /etc/named/named.root содержит информацию о корневых доменных серверах, в нем на самом деле много инфы, вроде подобного:
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30
;
Теперь радостно перезапускаем наш сервер доменных имен, и можем спокойно тестить или заниматься другими делами.
Тестится естественно через терзания nslookup’a:
# nslookup
Default server: 127.0.0.1
Address: 127.0.0.1#53
> odminblog.ru
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
Name:   odminblog.ru
Address: 174.120.3.60

Как видно из Non-authoritative answer сервер берет эти данные из кеша, о чем нас и предупреждает этой надписью.

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

Для начала крайне желательно что бы каждый сайт на хостинге принадлежал отдельному пользователю, и под каждый сайт была бы заведена отдельная SQL база с различными правами доступа. Крайне желательно, чтобы движок сервера баз данных использовал для своей работы только соединение через localhost. Права на все файлы в папках ваших сайтов должны быть выставлены на чтение, кроме тех где необходимы права на исполнение или запись. Для каждого сайта желательно иметь собственного пользователя FTP, который бы имел доступ только в корневую папку сайта. По хорошему- общий доступ к папке сайтов лучше отключить, или привязать к своему IP. Если у вас IP динамический, то перепривязать его из панели управления займет лишнюю минуту, но это обезопасит ваш сайт от взлома ftp аккаунта или кражи пароля из ftp клиента.

После этого можно приступать к настройке защиты через консоль управления хостингом. Я расскажу про cpanel, ибо я предпочитаю использовать именно её, так как меня устраивает функционал и интерфейс, при том что на моем хостинге она стоит на 4 бакса дороже чем никакой DirectAdmin. Итак в cpanel есть раздел Security Center, который и отвечает за закручивание гаек в системе безопасности веб-сервера. О всех рассказывать не стану, так как там довольно много разделов, а поведаю о наиболее, на мой взгляд, важных:

1. mod_userdir Protection : здесь можно отключить возможность чтобы ваши домены были доступны по имени пользователя под которым заведен сайт, по адресу: хттп://дефолтныйхостнейм/~username
В принципе этот функционал советуют отрубать, иначе все переходы по данным урлам будут засчитаны для дефолтного домена, то есть в случае реселла вас смогу легко накалывать благодарные юзвери. Но если вы используете хостинг только для себя, я не уверен что это так уж и страшно.
2. Compiler Access: отрубает доступ к компилятору С на веб-сервере, для не привилегированных юзверей, в том числе и владельцев сайта. Очень полезная штука, ограничивающая возможности злоумышленника при попытке взлома со стороны пхпшных шеллов.
3. cPHulk Brute Force Protection: одна из самых полезных штук, позволяющая предотвращать атаку переборки паролей. Включив этот твит- вы будите удивлены тому, как часто вам пытаются ломануть аккаунт, так что в итоге я выставил 3 максимальные попытки, после которых идет бан по IP адресу на 2 недели. Также можно настроить уведомления о логинах рута и отловленных атаках, тогда в этих случаях будет приходить письмо в линками на бан IP и сеток по маскам 16 и 24. Но вам надо будет настроить в зоне домена сервисный субдомен для бана, а также привыкнуть к тому, что вам будет падать уведомление и о системных входах рута.
4. Host Access Control: фактически фаервол, позволяющий настроить права доступа для определенных сервисов к хостингу. В случае динамических адресов, может стать проблемой, так как придется либо открывать сетке, либо пересоздавать правила каждый раз.
5. Manage root’s SSH Keys: очень полезная штука, позволяющая обезопасить ssh соединение с сервером, путем использования аутентификации не паролями, а на уровне сертификатов. Для начала надо сгенерировать сертификаты, путем клика на Generate a New Key и следуя указаниям (пароль и логин следует запомнить, а лучше записать). Создав их – говорим для ключей download key, после чего копируем представленный текст в блокнот и сохраняем под одним именем файла: Public Keys с расширением pub, а  Private Keys без расширения файла. После чего ныкаем файлы куда-нить вглубь операционки. После чего заводим новое соединение, выбрав в качестве метода аутентификации сертификат, и указываем публичный ключ (он должен находиться в одной директории с приватным), после чего вводим имя пользователя которым хотим залогиниться в систему, например root, и пароль который мы вводили при создании сертификата. Если соединение прошло успешно, то идем в раздел SSH Password Authorization Tweak и отключаем аутентификацию по паролю. Так что теперь к нашему ssh серверу мы можем подключиться исключительно с использованием сертификатов.
6. Quick Security Scan: здесь можно просканить сервер на предмет не нужных портов и сервисов, запущенных по умолчанию.
7. Scan for Trojan Horses: очень полезная штука, позволяющая сканить ваши директории, на предмет выявления троянов, подсунутых вам в систему. Рекомендуется эпизодически запускать, чтобы быть уверенным что у вас на сайте не шуршит какая нибудь нечисть.
8. Shell Fork Bomb Protection: полезная штука для ресселеров, позволяющая предотвратить запуск из шела каких либо циклов и процессов, способных переполнить память и тем самым привести к краху системы.
9. Security Questions: также полезная опа, для предотвращения несанкционированного доступа к системе, путем создания листа разрешенных IP адресов, и при попытке логина с не зарегистрированного IP адреса выдающего вопрос. В случае правильного ответа- пользователь входит в систему, а IP вносится в базу разрешенных адресов.
10. SMTP Tweak: заточка SMTP, которую также можно произвести на странице настроек – Server Configuration >> Tweak Settings, которые я настоятельно  рекомендую просмотреть, так как там можно поотключать много чего не нужного.

Собственно эти небольшие настройки позволят повысить безопасность вашего веб-сервера простыми настройками из понятного интерфейса cpanel и придать вашему сну размеренность и спокойное дыхание.

Для меня это было довольно приятной неожиданностью, тем более что этот сайт получил 20ку, что явилось следствием последних телодвижений с продвижением, что  делал в июле, так что продолжу свои изыскания и в августе. Но 20 тиц за две недели- это более чем приятно, хотя на туристическом блоге я ожидал роста в районе 30-40, но возможно будет в следующем апе. А пока по итогам двух последних апов, ситуация по проектам следующая:
0 -> 10 -> 20
0 -> 10 -> 20
10 -> 20 -> 10
0 -> 0 -> 10
Остальные вообще без изменений, но не понятно откуда два последних взяли подвижки, так как по ним я не делал вообще ничего, но видимо тот что получил с нуля – 10 тиц придется развивать, ибо это был мой типо сеошный блог, де я хотел писать о каких то экспериментах, но по ходу дела буду тупо его гнать под сапу и нагон рефералов. Но ему уже как то давали не разобравшись 10 тиц, потом правда отобрали через пару недель, так что полагаю что и в этот раз его ждет такая же судьбинушка.

Но самое забавное, что зайдя на свой ЖЖ обнаружил, что он стал из 0-0, 2-10, то есть в последний ап пыра еще и получил двоечку. То есть либо опять переделали алгоритм влияния линков из ЖЖ на трастовость ресурса, толи еще что, ибо после того как СУП сделали ссылки из ЖЖ nofollow мой блог потерял свои статсы, которые на тот момент были 1-10, и несколько месяцев был 0-0, и вот теперь получил все обратно, так еще и прибавил в весе, что дало мне повод пересмотреть свои взгляды на продолжение построения сетки жжных блогов.

Уже пару месяцев от мага, да и из бургонета слышал отзывы о том, что Панда рубит по совершенно не понятным признаком как говносайты, так и качественные ресурсы. Так у одного чеса, имевшего на мувиках порядка 4к трафа и 350$ ежедневного дохода с AdSense траф упал до 500 уников и доход срезался до $60, так что человек породил тред с  сотней откликов о том, как гугл разбил его мечты. Еще у одного человека, траф также с 2к упал до 200, тоже срезав доход от рекламы в несколько раз. Причем надо отметить, что сайты у этих людей базировались на чистом и качественном копирайте, так что возникает большой вопрос о критериях раздачи плюшек и пинков, особенно учитывая то, что мои английские говносателлиты, также и имеют свои 50-100 уников в день, что и до ввода панды.

И вот 12 августа Панду запустили в рунет и другие языковые сегменты, пообещав, что в отличии от англонета, в рунете она затронет не более 9% поисковых запросов, против 12% бургонета. И самое главное что я почувствовал отдачу Панды как раз с 11 числа, когда траф на моем туристическом блоге- не понятным для меня образом скользнул с 480 ежесуточных пользователей к отметке в 400 уников, что я списал на качество очередного мега прогона, который я заказывал на прошлой неделе. И только сегодня, обнаружив начало карательной операции под кодовым названием “Панда”, понял что же это было на самом деле. После чего засел анализировать, что персонально мне принесла панда.

Судя по ситуации трех сайтов что я мониторю, все мои сайты возрастом около года получили пендаля из выдачи по самым жирным ключам, на которые я успешно тянул сайты последние пару месяцев, так что с 12-15 позиций я улетел на 30-40, уступив место в выдаче каким то говно лентам с парой десятков слов, о которых я до этого момента и слыхом не слыхивал (ибо все сайты в районе топ 30 я знал досконально) и чья основная заслуга тиц-пыр и возраст. СЧ и НЧ практически не тронуло, изменения получились равнозначные обычной поисковой выдачи +/- 5-6 пунктов туда сюда.

А вот все молодые сайты, до года- получили хорошего пендаля, причем по ходу дела по всем позициям, так что на тех где траф радостно стремился к 150, он упал обратно к весенним позициям в районе 50-60 уников. Самая забавная сиутевина была на молоденьком сайте, который я запустил в середине июля, и который за последние 2 недели само собой набрал какие то нереальные обороты, так что последнюю неделю до 10го числа имел по 60-80 уников в день, но после 11го- словно дернули рубильник и он стал иметь всего 6-8 посетителей.

На старичках же, которым 4+ лет, траф подрос на те же 20-30% причем совершенно без моей помощи, ибо я ими не занимался несколько месяцев.
Так что судя по ситуации на моих сайтах, могу сделать вывод что из толстой выдачи повылетала вся молодежь, не успевшая к выходу Панды набрать достаточного траста. Но в моем случае- все не так смертельно, ибо падение в выдаче- не бан, и оставляет место для дальнейшего творчества. Обидно конечно что сайты просели в выдаче, но есть куда рости, хотя для молодых сайтов- порог в 1к уников в день теперь отодвинулся на более дальний период, чем я планировал весной- доростить несколько сайтов к концу осени.

2 -> 1 -> 2 -> 1
2 -> 1 -> 2 -> 1
0 -> 4 -> 1 -> 2
1 -> 5 -> 2 -> 3

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

Но при этом по сайтам щедрой рукой рассыпали PR1, выдав всем постам, категориям и тегам, и что самое смешное- на этом сайте, и на паре других, выдали PR аналогичный морде сайта, всем постам что на момент 29 июля находились на морде. Так что мне сдается, что очередная корректировка не за горами. А значит этому сайту, вполне вероятно дадут уже PR3, ибо он его заслуживает.

Так что на данный момент картина следующая:
27.06 – апдейт Page Rank
18.07 – первая корректировка Page Rank
04.08 – вторая корректировка Page Rank

ждем третью???

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

На 7 проектах добавилось по 10 пунктов, причем три из них я активно продвигал различными прогонами по каталогам, профилям, покупкой постовых и статей. Еще два, включая этот бложик, я практически не трогал- проведя за последние три месяца только пару прогонов по каталогам и по базе из 400 профилей, ну еще руками зарегался на 40-50 форумах из ЯК, что по идее само по себе могло бы дать 10-20 пунктов. И еще два не трогал вообще, так как один просто отстаивается в ожидании того момента когда у меня дойдут руки до его развития, а второй просто не продвигал.

Так что выглядит все довольно забавно, ибо сайт с ~60 бэками вырос с 0 до 10 тиц, и при этом же сайт с 3к бэков поднялся с 20 до 30. Так что вероятнее всего могут дать что нить более впечатляющее по результатам следующего апа.

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

Так, по инфе на вчерашний вечер, некоторых клиентов секс-шопа Sexyz.ru уже начали троллить в социальной сети “ВКонтакте”, ибо у них обнаружились какие то нереальные списки заказанных сексуальных игрушек.

Новость изначально коснулась только Яндекса, но позднее выяснилось что все эти данные также доступны и на большинстве поисковиков- Mail, Rambler, Google. Собственно как и в случае утечки информации с сайта Мегафон- индексация поисковиками стала возможной в связи с некорректной работой файла индексации интернет-магазина robots.txt.

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

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

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

Мог бы понаписать много чего еще, но пошел проверять роботсы на своих сайтах. Ибо чем Яндекс не шутит.

З.Ы: Поковырявшись на сайте вышеозначенного сексшопа и других героев ленты яндекса, обнаружил что собственно это одна и та же платформа, и как оказалось- это сугубо российская поделка Shop-Script – за который люди еще платят бобло порядка 300 американских рублей. Полагаю что после такого замечательного и главное показательного пиара в интернете, у парней их поделка будет продаваться уже менее успешно. Так что развитие ситуации было видимо таким, что кто то случайно пробил Sexyz.ru, и дальше уже по фингерпринту движка ситуация пошла развиваться дальше. Тем более что для этого даже не надо было терзать поисковые системы запросами, а просто зайти на офф.сайт shop-script.ру в раздел партнеров, где и выложена часть сайтов, использующих данный движок. Сексшопов естественно в данном списке нет.

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

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

Так что учитывая тот факт, что на Мегафон тем не менее уже подают в суд с исками в 30-50к рублей, то здесь все гораздо серьезнее и все таки у мегафона имеется своя сильная юридическая база, чего лишены торговцы самотыками, так что их однозначно будут иметь как тузик грелку. А они в свою очередь перевыставлять претензии к создателям дырявого двигла. Так что полагаю и интернет магазины, использовавшие дырявое двигло Shop-Script и самих быдлокодеров, продающих не тестированную поделку, ждет не мало приятных минут общения с судейскими.

Да и как быть если например в тэге порядка 40 постов, а хочется чтобы тэги кроме своей основной задачи добавления ключиков, не транжирили вес страницы понапрасну. Для этого их можно залинковать на туже страницу к которой они и относятся. А делается это следующим образом: находим в теле вывода единичного поста тот раздел который отвечает за вывод тэгов  <?php the_tags( ); ?> и заменяем его на более модный формат рерайта тэгов на целевую страницу:

Метки: <?php $post_tags = get_the_tags(); $tag_permalink = get_permalink(); $split_comma = 0; if ($post_tags) { foreach($post_tags as $tag_single) { ?><?php if ($split_comma > 0) { echo “, “; } $split_comma++; ?><a href=”<?php echo $tag_permalink; ?>” title=”<?php echo $tag_single->name; ?>”><?php echo ucwords($tag_single->name); ?></a><?php } }  ?>

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

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

Но на вопрос откуда же брать изображения, многие русские блоггеры, раздающие полезные советы и ноухау, выдают что берут все необходимое из раздела картинок поисковых систем Яндекс и Google. И правда, введя необходимое ключевое слово, мы получаем листинг сотен изображений подпадающих под данное описание, и вроде бы они даже находятся, как может показаться на первый взгляд, в свободном доступе. Так что мы спокойно кликаем на это изображение и сохраняем его. Но вот как раз на этом  моменте и происходит ошибочное действие, ибо изображение мы дергаем с сайта правообладателя данной фотографии, который, обнаружив своё фото, вполне может предъявить вам претензию о защите авторского права и интеллектуальной собственности. Причем самое интересное, что если копипейст контента российские вебмастера уже худо- бедно избегают, может и не отдавая себе отчета что это чистой воды воровство, а просто боясь санкций поисковых систем, то относительно изображений, данные претензии воспринимаются как что то из серии лулзов – “лол!!!1 какой то тупарь хочет бабок за то, что я использую его фотку”.

В этой связи решение относительно рунета навряд ли будет приниматься в судебном порядке: заявитель просто пишет письмо в Google с просьбой исключить сайт, использующий ворованный (да-да, именно ворованный) контент, из поисковой выдаче, и в итоге мы получаем тот самый пресловутый бан поисковой системой, дающей до 40% трафика, ибо помимо исключения из индекса Google, в нагрузку, вероятнее всего, получаем еще и бан в Mail.ru.

И если на сателлите можно этим не запариваться, так как потеря одного сайта приносящего скажем 30$ в месяц не сильно отразится на работе MFA сетки, да и навряд ли кто будет разбираться с сателлитом, то хороший сайт, приносящий стабильный доход с трафика- лучше защитить от жадного аффтора, ибо в случае бана сайта (так как Google, вполне возможно, даже не сочтет нужным выносить вам предупреждение, и зразу забанит, ибо как он один, а вас много), вернуть его обратно в выдачу, займет гораздо больше усилий, чем предотвратить данную ситуацию. Тем более, что в последнее время появились довольно пакостные сервисы вроде Tineye (после знакомства с одним из таких, я и озадачился подобным вопросом, так как сам на некоторых сайтах пользовал чужие фотографии), позволяющие просканить гугль на предмет соответствий, к тому же даже уже имеющийся в виде надстройки к FF, так что шанс быть пойманным на краже чужого изображения, с каждым годом возрастает.

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

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

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

Конечно имеются и другие фотобанки, но на них отсутствуют бесплатные разделы и ценник в разы выше, так что из отсмотренных 5-6 штук, я остановил свой выбор именно на вышеупомянутых фотостоках:
Fotolia
Dreamstime

Не думаю что при стоимости качественного копирайта в районе 6-7$ за пост на 2-3к символов, стоимость качественного и привлекающего внимание изображения в размере бакса, может стать проблемой, тем более что оно также послужит для привлечения трафика, который с общем итоге пойдет в карман вебмастеру в виде дохода с посетителей.

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

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

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

1. BigDump
Открываем файл скрипта bigdump.php, в котором отыскиваем и меняем следующие строки на необходимые значения
$db_server   = ‘localhost’;
$db_name     = ‘DB_NAME’;
$db_username = ‘DB_USER’;
$db_password = ‘DB_PASSWORD’;
$filename           = ‘OUR_DUMP.SQL’; /* Наш дамп базы данных который мы выгрузили вместе со скриптом*/
$db_connection_charset = ‘Charset’; /*Поскольку мы работаем с русскими базами, то вероятнее всего это utf8 или cp1251*/

После этого открываем в бродилке скрипт хттп://наш-сайт/папка/bigdump.php и видим свой файлец, после чего наживаем на линк Start import

2. Sypex Dumper
С этим скриптом еще проще, так как у него есть графический интерфейс, через который можно вводить все данные, а также делать экспорт и импорт баз данных. Собственно заливаем файлец скрипта dumper.php на хостинг, но с одной оговоркой- опять же в плане кодировок. По умолчанию скрипт работает с cp1251, так что если надо залить utf-8, то добавляем в следующую строку параметр принудительной замены кодировки:
define(‘RESTORE_CHARSET’, ‘forced->utf8′);

После чего коннектимся через бродилку хттп://наш-сайт/папка/dumper.php
вводим логин на базу данных сайта и получаем возможность как импортировать нужную нам базу данных, так и экспортировать.

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

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

2. Вариант второй – выгружать в пожатом состоянии- так как степень сжатия для текстового файла будет максимальной. Но тут опять же можно столкнуться с тем, что на хостинге не установлена поддержка архиваторов.

3. Используем сторонний скрипт, который позволяет производить экспорт и импорт базы данных, минуя общение с phpMyAdmin. Наиболее известный из имеющихся в наличии, и к тому же наиболее хорошо работающий- это BigDump. О том как его настроить – я отписался чуть позже, так что это касается и настройки по 5му пункту.

4. Как частный случай 3 вариант, возможно залить на сервер эмулятор терминала и сделать 5 пункт через него. Например можно попробовать PHPterm, но в этом варианте можно столкнуться с ограничениями хостинга в плане безопасности запуска команд и скриптов.

5. Также есть простенькая программка аналогичная BigDump, которая также позволяет импортировать большие базы данных, только в данном случае необходим Zend Optimizer либо Nu-Coder. Программка называется Sypex Dumper, и вторую версию скрипта можно даже интегрировать в наиболее популярные CMS. На сайте есть как платная утилита, так и облегченная бесплатная версия.

6. Если таки имеется доступ к консоли, то можно добавить в php.ini следующие строки (увеличиваем лимит загрузки файлов по времени и размеру), после загрузки, лучше вернуть все назад, чтобы не нагнули сервак с оказией:
max_execution_time = 20000
max_input_time = 20000
upload_max_filesize = 150M
post_max_size = 150M

7. Но на самом деле наиболее быстрым и оптимальным вариантом загрузки большой базы данных, имея доступ к консоли, будет загрузить дамп базы данных dump.sql через ftp, а затем залить её через консоль ssh:
mysql -h hostname -u user-name -p DB_name <  /path-to-dir/dump.sql
если у вас в качестве хоста базы данных используется стандартный localhost , то ключик -h можно и опустить, так что получится вида:
mysql -u user-name -p DB_name <  /path-to-dir/dump.sql

Да, чуть не забыл про самые поганые грабли всей пляски с импортом- при импорте базы данных могут возникнуть проблемы с кодировками, поэтому нам надо убедиться что дефолтная база и выгрузка sql находятся в одной кодировке, либо переконвертировать базу данных в стандартную для mysql кодировку (обычно это utf-8):
iconv -f CP1251 -t UTF-8 dump.sql > dump.sql.utf8
либо указать необходимую кодировку при процедуре импорта базы данных:
mysql -h hostname -u user-name -default_character_set utf8 -p DB_name <  /path-to-dir/dump.sql

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

Web-порталы, по сути, приложения на базе браузера, которые позволяют различную деятельность, включая деловые операции, например, настройку цепочки поставок того или иного продукта. Порталы открывают доступ к структурированным и неструктурированным данным, интегрируют приложения, которые помогают выполнять функции пользователя. А также обеспечивают доступ в режиме реального времени к текущей и последовательной информации. Примерами популярных web-порталов служат Yahoo, MSN и другие.

Типы порталов:

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

Вертикальные порталы (Ворталы)

Такие web-порталы сосредотачивают внимание только на одной конкретной отрасли, области или вертикали. Вертикальные порталы или ворталы предоставляют средства, информацию, статьи, исследования и статистические данные по конкретной отрасли или вертикали. Когда Интернет стал стандартным инструментом бизнеса, ворталы обеспечивали идеальный шлюз для предприятий на рынок своей продукции и услуг. Таким образом, ради роста продаж, организации развивали собственные ворталы. Классическим примером вертикального портала будет Cnet.com, который сосредоточился на компьютерной тематике и околокомпьютерных вопросах, MP3.com – музыкальный портал, который ориентирован на MP3-музыку. В большинстве случаев, вертикальные порталы предлагают информацию и услуги, настроенные под нишу аудитории или конкретную область интересов. Вертикальные отраслевые порталы, известные как ворталы, сайты, которые обеспечивают доступ к информации, связанной с той или иной отраслью, как страхование, автомобили и так далее.

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

Корпоративные порталы:

- Создание персонализированного доступа к отдельным видам информации для / о конкретной компании.

Коммерческие порталы:

- Поддержка корпоративных клиентов и поставка услуг электронной торговли к потребителю.

Горизонтальные порталы

Эти web-порталы сосредоточили своё внимание на широком спектре интересов и тем. Они сосредоточены на широкой аудитории и пытаются предоставить информацию для всех. Горизонтальные порталы стараются действовать в качестве отправной точки web-серферов сети Интернет, предоставляя содержание на интересующие пользователя темы и направляя пользователя на другие ресурсы за поле полной информацией. Таким образом, горизонтальные порталы выступают в роле связующего звена для целой сети web-сайтов. Классическим примером горизонтальных web-порталов является Yahoo.com, Msn.com и другие. Они предоставляют пользователям информацию по самым различным темам. Горизонтальные порталы ориентированы на всё интернет-сообщество. Эти сайты, часто упоминаются как «мегапорталы», которые, как правило, включают поисковые системы и обеспечивают для пользователя возможность персонализировать страницу, предлагая различные каналы, как региональная погода, котировки акций или новости.

Интранет-порталы (Корпоративные порталы)

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

Порталы знаний

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

Корпоративные порталы

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

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

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

Порталы – Виртуальные рынки

Виртуальные рынки существуют для поддержки клиентов и торговли по средствам электронной коммерции.

Основные функциональные возможности таких порталов включают:

1. Программное обеспечение для транзакций в области электронной торговли.
2. Инструменты для поиска и доступа к информации о продукции, выставленной на продажу.
3. Инструменты для участия в дискуссионных группах с другими поставщиками и / или покупателями.

Подготовлено по материалам сайта buzzle.com

Так вот- помог я сделать страницу другу, который создает не хилый портал по Бали, и ищет всевозможные способы его продвижения, после чего озадачился вопросом, почему же это моя страница, против всяких правил отсутствует в индексе Google. Причем самое прикольно, что в выдаче Яндекса она тем не менее присутствовала, но с последним обновлением с начала апреля, то есть за три месяца Яндекс не прочухал о том, что страница закрыта от индексации.

Собственно почему страница закрыта от индексации я понял сразу: идем в редактирование страницы, раздел Управление разрешениями, и вот там есть два поля Ограничения страны и Возрастные Ограничения (кстати в этом же разделе можно и удалить страницу в facebook). Если эти курки взведены, то страница требует логина, для проверки соответствия ограничениям. Для новых страниц эти поля пустые, но в тот момент когда я воевал с проблемой Facebook Like Box одна из рабочих версий была отсутствие этих полей. Так что тогда я выставил страну Россию и возрастное ограничение 13+ лет. И вот, попробовав удалить эти данные, я столкнулся с тем, что страна удалилась нормально, а возраст не удалялся. То есть он снимался, но после сохранения данных возвращался обратно на 13+ лет, и как следствие при попытке перейти на адрес страницы facebook с незареганного браузера, мы все равно попадали на официальную страницу facebook с landing page ввода логина.

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

например основная морда гугля- google.com потеряла единичку и теперь имеет всего PR9
русскоязычная версия гугля google.ru тоже потеряла единицу веса и теперь имеет PR7
при этом новый соперник Google- социальная сеть Facebook получила потеряную гуглем единицу и получила максимально возможный пыр = Page Rank 10

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

кстати, для проверки истории изменения PR можно воспользоваться сервисом push2check, единственное что если ваш сайт не какой либо крутой и известный портал, то история навряд ли выдаст что либо вразумительное, поэтому регистрируемся в системе и она начинает следить за изменением пыра

Но как водится выход есть даже из самой жопской ситуации. То есть если вам необходимо завести пяток сайтов в одной базе, то это возможно сделать. Но надо учитывать несколько моментов:

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

Если вы все же решили что оно того стоит, то создаем базу данных средствами хостинга, после чего закачиваем нужное количество копий wordpress на хостинг, подключаем домены и запускаем установку CMS Wordpress, где для каждой установки указываем различные table_prefix: wp_ ; wp1_; wp2_ и т.п, которые после копируем в файл wp-config.php (в самом файле для копии wordpress эта строка будет выглядеть $table_prefix = ‘wp_’; )

Точно такое же действие подойдет и для других CMS:
в Drupal прописываем в файл sites/default/settings.php аргумент $db_prefix = ‘drupal1_’;
в Joomla в файле configuration.php указываем var $dbprefix = ‘joomla1_’;
После того как запустим установку CMS все необходимые таблицы, с указанными префиксами создадутся установочными скриптами.

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

Четыре сайта от 4 до 7 лет выглядят следующим образом:
1 -> 2 (тут очень странная картина, так как эта двоечка распространилась по практически всем внутрякам идущим с морды, так что категории и теги получили от 1 до 2PR, в количестве около сотни штук)
0 -> 1 (субдомен предыдущего, 1 отобрали в предыдущий ап, сейчас вернули обратно, после того как я убрал огромное количество тегов с морды)
3 -> 4 (дроп)
3 -> 1 (дроп)

Всем сайтам от 10 месяцев до года, продвигаю фактически последние 3-4 месяца:
1 -> 1 (пара внутряков получила PR3, так как я по этим статьям прогонял сайт)
0 -> 3 (все внутряки остались на 0, но этот сайт я продвигаю последние несколько месяцев на постоянной основе)
0 -> 4 (собственно это мой одминский блог, который я двигал, но очень ненавязчиво, проведя пару прогнозов, и ради эксперимента приклеив пару дропов: кстати на нем также пыр разползся по всем тегам и категориям так что почти все статьи и разделы с морды получили PR2, что крайне меня озадачило)
1 -> 5 (данный проект мне вообще не ясен, так как на сайт ведет от силы 20-30 ссылок, которыми он прирос сам собой, так как я его вообще не продвигал, но при этом данный PR также растекся по всем внутрякам- страницы из меню, теги, категории, алфавитный указатель, так что около 100 страниц получили в одночасье PR3, так что остается получить тиц 20-30 и спокойно пожинать плоды)

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

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

Первыми же в голову пришли три основных способа редиректа:
1. Создать вместо страницы php документик с таким же названием, или папочку, в которой положить index.php со  следующим содержимым:
<?php $url = $_GET['url']; header(“Location: forward-to.ru”); exit; ?>
2. в файле .htaccess прописать строку редиректа с определенного адреса:
Redirect /need-to-redirect.html  http://forward-to.ru/
3. добавить в хедер мета-тег перенаправляющий загрузку страницы:
<meta http-equiv=”refresh” content=”50; URL=http://forward-to.ru/”>

Но вспомнив о Javascript’е надыбал еще одну возможность через атрибут тега BODY onLoad, то есть добавляем в header следующие строки:
<SCRIPT LANGUAGE=”JavaScript”><!–
function redirect () { setTimeout(“go_now()”,1000); }
function go_now ()   { window.location.href = ” http://forward-to.ru/”; }
//–></SCRIPT>
где 1000 – это 1 секунда, после чего меняем стандартный <BODY> на:
<BODY onLoad=”redirect()”>

Но поскольку задача стояла сделать это все таки средствами поста, то следовательно тег надо выносить в тело документа, так что в html коде поста, вместо изменения BODY, прописываем:
<script type=”text/javascript” language=”javascript”> redirectPage();</script>
здесь я несколько запутался, так как по идее надо прописать
<script type=”text/javascript” language=”javascript”> onload=”redirectPage()”</script>

но проверять не стал, так как решив что надо было делать средствами Wordpress обнаружил, что какой то умный разработчик для WP уже давно за нас всех подумал и специально разработал плагин для этой задачи, именуемый Quick Page/Post Redirect Plugin

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

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

ExBB, Ikonboard, eForum 2.5, Forum203, QuickForum, Simple BBS, Tiny php forum, Ultimate PHP Board (UPB), x.forum, ZZ PHP Board, TextDB forum, PHPWind

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

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

Собственно погуглив какое то время обнаружил, что это баг дебиановской платформы, так как сама платформа и её дистрибутивы содержат не оригинальный GD, а кастрированную модификацию, в которой ради безопасности отключены по умолчанию  некоторые функции,, которые могут скомпрометировать систему. В том числе вырублен и упомянутый функционал imageantialias.  Так что с этой стороны лечится данный косяк не хитрыми манипуляциями пересборки пакета php с включенным функционалом:
устанавливаем необхоимые для пересборки пакеты:
# apt-get install build-essential debhelper fakeroot

Вытягиваем исходник php и подтягиваем депендансы
# cd /usr/src
# apt-get source php5
# apt-get build-dep php5
# cd php5-5.2.17

После этого в файле  debian/rules меняем содержащеюся там строку
–with-gd=shared,/usr –enable-gd-native-ttf \
на более правильную
–with-gd=shared –enable-gd-native-ttf \
И затем пересобираем пакет
dpkg-buildpackage -rfakeroot
dpkg -i php5-gd_5.2.0-8+etch13_i386.deb
Собственно тут же мне упал ответ от хостинга, гласивший что данная проблема является особенностью php5.2 так как в этой версии интерпретатора не включен функционал ‘bundled’. И если я хочу чтобы мне было щасте. то они могут меня перести на php5.3, но с оговоркой что могут быть косяки в работе. Прошерстив все подробности о проблемах wordpress с php 5.3, я решил остаться на версии 5.2, предложив парням свое решение проблемы, на что они мне поведали, что пробовали эту тему, но зверек получается крайне нестабильный, так что на шареде они это не будут делать точно.

Так что теперь одна надежда- попытаться найти плагин extranews более старой версии, чем я сейчас и пытаюсь заниматься.

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

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

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

Так что пришлось таки биться с phpMyAdmin. Качаем утилиту с официального сайта, разархивируем её себе на компьютер и редактируем файл конфигурации, предварительно ознакомившись с файлом конфигурации сайта имеющейся резервной копии, на предмет выяснения паролей и явок связи сайта с базой данных. Собственно у каждого движка его расположение свое собственное, поскольку я переносил друпальный сайт, то в моем случае его местоположение было sites/all/default.

Создаем конфиг-файл config.inc.php, из имеющегося config.sample.inc.php, и заполняем строчку
$cfg['blowfish_secret'] = ‘ba17c1ec07d65003′;  // use here a value of your choice
произвольным кодом, который нам будет нужен для аутентификации по кукам. Также мы можем поменять тип аутентификации, в строчке
$cfg['Servers'][$i]['auth_type'] = ‘cookie’;
например на аутентификацию по http, что бы при обращении к странице сразу выскакивал логин-промт:
$cfg['Servers'][$i]['auth_type'] = ‘http’;

Помещаем файл в корневую директорию phpmyadmin. После этого загружаем все содержимое каталога  в подпапку, например phpmyadmin, корневого раздела сайта и заходим через бродилку http://сайт//phpmyadmin. Вводим логин который мы достали из конфига CMS и вуаля- “мы уже а Хопре!”

Вероятнее всего при заходе через бродилку у вас будет ругань следующего содержания: «Расширение mcrypt не найдено. Пожалуйста, проверьте ваши настройки PHP», но её мы просто игнорируем. Также в этой ситуации придется забить и на все остальные варнинги, как то отсутствие библиотеки mbstring, которая также ставится из консоли, и всевозможные опции для утилиты phpmyadmin.

Поэтому проходим в экспорт и цинично сливаем базу данных, выбрав доступный формат сохранения базы данных- как минимум sql.

После чего зашедшему на сайт пользователю суется исполняемый php или javascript который базируясь на уязвимости системы, инсталяет в систему некий злонамеренный код, который подтягивается зачастую с использованием внедренных элементов iframe, или же flash редирект, когда предлагается загрузить сторонний кодек для просмотра видеоролика (преимущественно порнографического содержания). Таким же образом эта атака происходит, когда злоумышленникам удается внедрить данный метод XSS-атаки и на “честные” сайты имеющие некоторые уязвимости безопасности, которые и эксплуатируются негодяйскими негодяями для внедрения злонамеренного кода на машину потенциальной жертвы. И не смотря на постоянную борьбу Google с подобными сайтами, следствием которой вы можете видеть красную заставку, предупреждающую вас о потенциальной угрозе, исходящей с данного сайта, популярность данного вида мошенничества неумолимо растет в и данный момент (по состоянию 2010 года) составляет порядка 17% от всех топовых поисковых запросов Goolge, то есть переходя по ссылкам из топа выдачи, в 17 случаях из 100 вы попадаете на специально сконфигурированный сайт, или же подвергшийся компрометации. И не малое значение здесь конечно играют компании, специализирующиеся на разработке и распространении подобных продуктов, в чьи партнерки с радостью и подключаются не сильно разборчивые в средствах заработка веб-мастера, ибо что продвигать педофильско-зоофильские партнерки, что клепать и подсовывать буржуйским лохам мальвары- все едино, тем более что заработки подобных веб-мастеров, именно на мальварных партнерках исчисляются десятками тысяч долларов.

Но тут, после некоторого количества наблюдений за яндексом, который просто тупо идиотничал, то компануя из сайта индекс на 800 страниц, то уменьшая его до 150, и таким же образом перемещая его по выдаче, я решил что пришла пора получать доверие от яндекса, путем вступления в директ. Зарегался в системе и стал ждать радостного письма о том, что я принят. Через четыре дня мне пришло письмо следующего содержания:

К сожалению, мы не можем принять Ваш сайт в Рекламную сеть.
Причины:
- Содержание сайта не соответствует редакционной политике Рекламной сети Яндекса
Повторная подача заявки на участие для данного домена возможна через месяц.

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

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

Здравствуйте.
К сожалению, мы не даем комментариев по решению модератора.

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

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

Кстати в это же самое время поимел  блокировку аккаунта Adwords который я неделю назад завел под очередной промо-купон, купленный под практикующийся арбитраж трафика. Залочен аккаунт был с формулировкой: без возможности восстановления, в связи с невозможностью проверить платежные данные. Решив, что это тот самый лок акка, которым пугают друг друга арбитражники, я тем не менее написал из встроенной формы обратной связи свой WTF, но скорее для очистки совести, и был крайне приятно удивлен, когда на следующий день на целевой ресурс полился траф с адвордса, принеся мне лишних 65 бачинских за два дня.

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

Уж не знаю какие там счеты у Навального с компанией Google, но то что его имя демонизирует блог для системы Adsense явилось для меня весьма интересным открытием, после чего я прошел на сайт Google и ввел “Навальный” в форму поиска- после чего с радостью обнаружил, что и на самом Google это слово отрубает контекстную рекламу, которая показывается в правом сайдбаре. После чего стал рыть далее и обнаружил интересную особенность, что некоторые фамилии отрубают показы рекламных блоков, как на самих страницах, так и в разделах где они упоминаются с другими постами.

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

этому сайту вернули 10 ТиЦ которые отобрали 16 марта, видимо тем самым намекнув- так нельзя;
на этом положительные новости заканчиваются, ибо все мои остальные сайты не потеряли, но и не приобрели ничего нового, не считая моей жжшки которую я пользую для пинков ссылок, и которую думал вытянуть на 20-30 тицев, для чего позаписывал её в различные сообщества и начал с неё довольно много комментить и всячески участвовать в жизни змеиного гнезда, под названием ЖЖ- и как итог сняли имевшиеся на сайте 10 тиц;
остальные сайты, как я уже сказал, не претерпели никаких изменений, при том, что на основном домене наростил под 1.2к бэков, на игрушечном портале также увеличил уже месяца два как до 600 бэков;
но самое веселое оказалось с клиентским доменом, который двигаю де то с конца января- начинал с 60 тицев, в итоге 16 марта ему дают 80, а спустя 7 дней добавляют еще 20, так что тиц становится равным 100, но при этом часть линков улетает в жопу из топ10, так что их с неделю не было даже в сотне. Зато когда проверял их сегодня, большая часть из них вернулась, да еще и те что упорно не хотели входить в сотню, вдруг оказались на 20-30 местах;
и как обычно бывает после долбанных яндексовых штормов, мой авиабилетный бложик потерял дето 25-30% трафа, который вернул только вчера.

Такой вот апдейт, бесмысленный и беспощадный..

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

З.Ы. Самое интересное, что по версии сеопульта так никакого обновления тиц и не было, а только лишь прошел 34% шторм, так что ожидаем дальнейшего развития событий. Тем более, что пока у меня на бложке, не смотря на снижение пузомеров, траф прирос на 70 уников от среднестатистического трафика, так что такое развитие событий довольно не плохо.

Долго ли коротко ли, но сегодня мой прекрасный сайт получил 110 лайкера, после чего в виджете вместо симпатичных личиков фанатов появилась не приятная розовая надпись “The page you are trying to access is restricted or unavailable”. Решив что какая то ошибка в коде, я поперся на фейсбучный сайт в раздел для разработчиков и минут 30 ковырялся с разными вариациями своего сайта, но ничего путного у меня не вышло. Поначалу я грешил на русское название своей группы, но попробовав еще с двумя русскими группами- пришел к выводу того что это какой то баг системы, и собрался уже писать Кате Скоробогатовой, как единственному представителю FB которого я знаю и которая меня уже не раз выручала с консультациями по вопросам обращения с facebook.

Но прежде чем отправить тупой вопрос “апачиму” я решил прогуглить на эту тему, и обнаружил причину по которой такая ситуация может быть- какой то американец обнаружил что данный баг срабатывает для не залогиненного пользователя, если для страницы установлены ограничения доступности по возрасту, и поэтому в настройках страницы надо выставлять “для всех- 13+ лет”. Пройдя в настройки своей страницы, я проверил и эту опочку, но она у меня была выставлена, так что я уже было отчаялся- но в последний момент увидел возможность создания короткого алиаса для страницы: проходите  на свою страницу в Facebook -> в верхнем правом углу кнопка редактировать -> раздел Маркетинг -> Создать короткое имя -> выбираете название страницы на которую создаете алиас и там вводите короткое имя для этой страницы и проверяете его свободность с помощью кнопочки, расположенной там же.

И что бы подумали? Заменив адрес страницы из двухсложного русского, на короткий английский алиас, я снова попробовал поднять Like Box для своего сайта, и у меня все заработало. Так что видимо это какой то глюк с русскими (а возможно и английскими страницами в Facebook) состоящими из нескольких слов.

Собственно такая вот ситуация у меня произошла и с установкой eGroupWare- ибо я её поставил, настроил и отложил на 3 дня, в течении которых я напрочь забыл на чем я собственно остановился и главное какой пароль администратора я установил, так что мои попытки вломиться в вебконсоль управления сервером EgroupWare не увенчались успехом, после чего я пошел другим путем.

Для этого открываем файлик header.inc.php расположенный в корневой директории сервера eGroupWare и ищем строки:
$GLOBALS['egw_info']['server']['header_admin_user'] = ‘admin’;
$GLOBALS['egw_info']['server']['header_admin_password'] = ‘XXXXXXXXX’;
где XXXXXXXXX является хешированным с помощью алгоритма MD5  паролем, удалив который и приведя строку к следующему виду:
$GLOBALS['egw_info']['server']['header_admin_password'] = ”;
мы получим возможность войти в систему с пустым паролем.

Поставил CentOS, проапргейдил, после чего качнул с оффсайта исходники. Там есть несколько типов исходников- rpm, который всем рекомендуют ставить, и который при этом вообще не понятно как и куда ставится и снимок системы eGroupWare, представляющий собой домашнюю директорию сервака. Скачиваем снапшот и засовывавем его в папку egroup которую создаем в корне домашней директории нашего веб-сервера: /var/www, после чего заходим по адресу http://localhost/eware/ и у нас запускается установка, которая проверив нашу систему сказала мне что у меня старенький php- ибо для системы требуется 5.2 а у меня всего 5.16, так что начнем с обновления php:
Смотрим для начала что у нас вообще установлено:
# rpm -qa |grep php
Далее добавляем репозитарий разработчика, в который вносим только php
# vi /etc/yum.repos.d/CentOS-Testing.repo
############################################################
# CentOS-Testing:
# !!!! CAUTION !!!!
# This repository is a proving grounds for packages on their way to CentOSPlus and CentOS Extras.
# They may or may not replace core CentOS packages, and are not guaranteed to function properly.
# These packages build and install, but are waiting for feedback from testers as to
# functionality and stability. Packages in this repository will come and go during the
# development period, so it should not be left enabled or used on production systems
#without due consideration.
[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
includepkgs=php*
############################################################
Сохраняем файл и запускаем обоновление, которое займет некоторое время, так что можно сходить налить чайку:
# yum update
После чего смотрим снова пакеты установленные в системе и версию самого:
# rpm -qa |grep php
# php -v
Перегружаем веб-сервер и после этого снова проходим тест
# service httpd restart
Перед этим надо внести исправления в php.ini, поскольку у меня тест также ругался на предмет двух директив указанных в файле, которые надо выставить в следующих параметрах:
upload_max_filesize = 8M (для возможности загрузки больших файлов)
mbstring.func_overload = 7 (для поддержки UTF-8)
Также необходимо указать временную зону в которой находится наща система:
date.timezone = “Europe/Moscow”

После теста мы проходим по нему и смотрим на параметры обозначенные молнией, и по возможности устраняем их. Также у меня вывалилась еще одна фатальная ошибка относительно отсутствия JPGraph в директории /var/www/html/jpgraph, который необходим как раз для отрисовки диаграмм этого самого Ганта.

Выкачиваем с http://jpgraph.net/download/ и разархивировавыем его в нужную нам папку
После этого запускаем, уже установленный мускуль:
# /etc/rc.d/init.d/mysqld start
и задаем пароль для одмина
# /usr/bin/mysqladmin -u root password ‘PassworD’
Далее создаем базу данных и пользователя для нашей системы:
mysql> CREATE DATABASE egroupware;
mysql> use egroupware;
mysql> GRANT ALL PRIVILEGES ON *.* TO egroupware@localhost IDENTIFIED BY ‘PassworD’ WITH GRANT OPTION;
После этого проходим все тесты, заполняем поля и устанавливаем движок, после чего переходим к процессу настройки основных конфигураций- таких как фтп сервер, почтовый сервер, LDAP и прочее.

Собственно из всего многообразия систем, предлагающих ведение бизнес проектов и пляшущих от Microsoft Project я выбрал наиболее, на мой взгляд, интересное решение, называемое eGroupWare. Это пхпшное open source  решение, естественно в этой связи кроссплатформенное, так что запускается под любым веб-сервером- будь то Apache или IIS. Также поддерживает различный СУБД- MySQL, PostgreSQL, MaxDB, Microsoft SQL Server и даже каким то боком Oracle.

Написано про систему довольно много, но меня собственно в ней привлекло то, что она веб-ориентированная, а не клиент-сервер, как большая часть подобных приложений, в добавок обладает своей CMS,  включает в себя кучу всяких фич, как то календари, планеры, менеджер проектов с диаграммами Ганта ( на мой пасс о том, что это за верь я не разбирался- босс мне есессно заявил что это все полная лажа и там разбираться нечего), хранилище файлов, встроенное wiki и базу данных решений, средства контроля исполнений и расчет трудозатрат и стоимости, всякие голосалки и даже внутренний чат. Система как я уже писал- полностью бесплатная в версии Community Edition, и поддерживает около 25 языков, в том числе и русский. Также в системе имеется поддержка всевозможных PDA, Outlook’ов и различных других клиентов, с которыми синхронизирует свой планнер.

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

Звонок в суппорт закончился долгим рассказом про мой зараженный компьютер, и то что вирус пишет по фтп в файло всякие iframe или script и прочая, потом стали смотреть файлы, модификации, думать и пыхтеть. Попутно гуглю, но без особого фанатизма ибо перед тем как набрать никовцев полчаса потратил на поиски по инету.
Собственно в процессе разговора натыкаюсь на описание FirePHP, и того что фраза FirePHP::INFO не поддерживается php4, которому надо объявлять FirePHP_INFO. Собственно после этого залез в раздел управления хостингом и действительно обнаружил, что какой то умелец, надо полагать технари клиента, врубили php4, вместо крутившегося на хостинге php5.

**** Если же изменить выражение, как было указано,  то может появиться ошибка PHP: Parse error: syntax error, unexpected T_ARRAY, expecting ‘)’ in , в строке содержащей следующее выражение:
function devel_watchdog(array $log_entry) {
тогда его надо аменить на:
function devel_watchdog($log_entry) {

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

Собственно для начала можно попытаться открыть ссылочку хостнейм/?q=admin/settings/clean-urls и зайти оттуда админом, но вероятнее всего ничего не получится, но если по этому адресу высветится такая панель логина- то это оно самое.
Для начала проверяем .htaccess на предмет записи вида:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

Если оно есть и все равно ничего не работает, то вооружаемся кофием и идем в phpMyAdmin, где ищем по базе строчку clean_url, скорее всего она находится в табличке variable со значение s:1:”1″; которое мы меняем на значение s:1:”0″; после чего очищаем кэш всем табличкам начинающимся с префикса cache_ выбрав Очистить или TRUNCATE. После этого все начинает открываться, но без использования чистых ссылок, то есть в виде /?q=имя страницы
Собственно теперь последний момент- идем в админку и снова включаем чистые ссылки в настройке сайта: Administer > Site configuration > Clean URL.

Согласуясь с вышесказанным запись в named.conf приобретает следующий вид:

############################################
zone “newdomain.odminblog.ru” {
type slave;
file “slave/newdomain.odminblog.ru”;
masters {
DNS-провайдера;
};
############################################

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

newdomain    IN    NS    ns1.newdomain.odminblog.ru
newdomain    IN    NS    ns2.newdomain.odminblog.ru

После чего, через канонический тип имени CNAME определяем доменные сервера провайдера

ns1.newdomain  CNAME  ns1.DNC-провайдера.
ns2.newdomain  CNAME  ns2.DNC-провайдера.

В таком варианте все должно нормально работать. При тестировании попробовал описать DNS сервера провайдера сразу в описании NS для субдомена, используя их хостнеймы, но после такого финта, по непонятной причине отвалились MX-записи для корневого домена, что было довольно неожиданно, ибо вся остальная зона отдавалась замечательно.

Для начала создаем на нашем хостинге базу данных с которой будет работать движок, для это пользуемся либо стандартной консолью хостинга, либо приложением phpMyAdmin. Я пользуюсь стандартным функционалом cPanel, для чего идем в раздел  Databases -> MySQL Databases и там заводим базу и пользователя, после чего в разделе Add User To Database назначаем созданному пользователю права на базу данных, нажатием кнопки Add и расстановкой галочек привилегий. После этого, ну или до этого, скачиваем с офф.сайта http://www.phpbb.com/downloads/ последнюю стабильную версию двигла, и распаковав архив, закачиваем его по фтп в корневую директорию своего сайта, на различным хостингах это обычно папка public_html. В распакованном виде движок занимает порядка 10Мб.

Выставляем права на запись, по маске 666, для файла config.php (или -rw-rw-rw-)
Выставляем полные права для всех, по маске 777, для следующих папок:  store/, cache/, files/ and images/avatars/upload/  (или -rwxrwxrwx)
После этого идем бродилкой по адресу нашего сайта- корневой http://domain.ru/ или http://domain.ru/forum
Устанавливаем и подклчючаем поддержку php для следующих модулей: zlib compression,  remote FTP, GD graphics, XML, Imagemagick.
Кликаем на вкладку INSTALL и стартуем процесс установки. Смотрим все ли у нас установлено, если необходимы какие то дополнительные модули, подключаем их, после чего заполняем всю необходимую информацию, которую нам предоставляет хостер и мы записали, я по крайней мере, при выполнении подготовительных работ
После завершения установки,удаляем каталог install и меняем права на config.php, оставив права на запись только для владельца, по маске 644 или -rw-r–r–

Теперь можно переходить к настройке движка форума.

Итак имеем cPanel WHM.

Для начала создадим реселера.
Идем в раздел:  Account Functions -> Create a New Account и заполняем всю необходиую информацию об аккаунте, после чего в разделе Reseller Settings ставим галочку “Make the account a Reseller” и в Account Functions -> Change Site’s IP Address назначаем данному аккаунту дополнительный IP адрес.

Теперь содаем другой домен, который повесим также на дополнительный адрес. В разделе Account Functions -> Create a New Account создаем новый аккаунт, затем идем в Account Information -> List Accounts кликаем в иконку редактирования, в последнем столбце Owner, нашего нового аккаунта. Из выпадающего меню Change OwnerShip выбираем нашего реселлера и говорим Ок. Возвращаемся в список аккаунтов Account Information -> List Accounts  и идем в столбец IP нашего нового аккаунта. Убеждаемся что в строке New Address стоит новый IP адрес, на который бал назначен наш новый реселлер, и нажимаем Change. Теперь наш сайт привязан к дополнительному IP адресу, и точно также мы сможем привязать к нему любое количество доменов.

Но я не делаю больше 15-20 доменов на один адрес, ибо это чревато баном или попаданием под поисковые фильтры, особенно если планируется линковать сайты между собой.

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

Очень забавная тема приключилось с апдейтом, поскольку из имеющихся у меня блогов на российскую тематику, двум присвоили значение PR 1: zavalinka.sane4ka.ru и sane4ka.ru. Остальные все русскоговорящие сайты остались без изменений, не смотря на то, что с последнего апдейта я по некоторым нарастил достаточную для апдейта ссылочную массу. При этом две англоговорящие партнерки, которые я запустил в феврале этого года, получили показатель 2, при том, что на каждую из них ведет всего порядка 20-25 ссылок.

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

Итак на “Завалинку” прикрутил Поиск, который у меня по каким то причинам не работал. Собственно по-началу не мог понять чем это вызвано, поскольку поиск не искал ничего, и любой запрос получал 0 результатов. Проковырявшись какое то время в сторону того что поиск не ищет по utf-8 я допетрил, что в Joomla все крайне взаимосвязано, и включив модуль в разделе модулей, также необходимо активировать соответствующие ему плагины.  Так что собственно после включения плагина Search – Content все начало нормально искаться.

Туда же я прикрутил отличный модуль RokAjaxSearch, позволяющий осуществлять поиск как по содержимому сайта, так и по Google. Причем найденные страницы он выводит сразу же по мере набивания текста, в ниспадающем меню, что крайне удобно и позволяет не прибегать к каким нибудь сторонним поисковым формам.  Модуль абсолютно бесплатный и крайне удобный в настройке и использовании. Единственное что, надо его заставить говорить по русски, а то слово Search среди русских букв слишком бросается в глаза.  Для этого берем файл language/en-GB/en-GB.mod_rokajaxsearch.ini (для другого модуля файло будет называться соответственно), в котором меняем правую часть выражений на русские варианты. Далее файл сохраняем в кодировке UTF-8, иначе все будет козякозябрами. Для этого в блокноте, при сохранении, в нижнем выпадающем меню кодировка выбираем UTF-8. Сохраняем- заливаем обратно на сайт- и все работает.

После этого я подключил страницу о 404 ошибке, которая не смотря на мои пылкие терзания файла .htaccess не возымела никакого действия. Довольно странно, ибо получается что отработка движка  joomla каким то образом превалирует над правилами файла управления .htaccess
Собственно пути для получения страницы ошибки два:

1. Через файл .htaccess в который мы добавляем строчки:

ErrorDocument 401    /error401.php
ErrorDocument 403   /error401.php
ErrorDocument 404   /error401.php
ErrorDocument 500   /error401.php

2. Через движок Joomla

Изменяем вид стандартного документа об ошибке, который выдает CMS Joomla. Файлец находится по маршруту templates/system/error.php
Открываем его и заменяем его содержимое на следующий код:
######################################

<?php ($error->code == ‘404′) ;
{header (‘Location: http://odminblog.ru/error404.html’);
exit;
} ?>

######################################
где адрес http://odminblog.ru/error404.html путь к сконфигурированной до этого странице ошибки.

Хотя конечно с Яндексом это и не так просто, тем более что у меня это обновление сыграло как обычно не понятную штуку: на 10 пунктов подрасло значение для двух сайтоы на которые я не тратил ни времени, ни денег, при этом сайты у которых я стабильно нарастил ссылочную массу до 100+ ссылок (причем срок ссылок порядка полутора-двух месяцев), по прежнему имеют всего лишь 0.

Так что остается ждать следующего апдейта, который должен по идее прийтись на 20е числа марта, хотя если на этот год расписание точно такое же как и на предыдущие, то тогда следующего обновления не стоит ожидать ранее середины апреля.

Хотя какие либо выводы можно будет делать только завтра- послезавтра пока вся болтанка с изменением ТиЦ устаканится и станут понятны результаты нового тасования колоды популярности сайтов.

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

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

После этого я обнаружил, что парни из Webintellects ответили мне по поводу проблем с выделенными IP адресами, уже в нормальном ключе. Кратко проблема заключалась в том, что по их правилам я мог использовать каждый дополнительный выделенный IP адрес для хостинга ТОЛЬКО ОДНОГО домена. Если мне нужно было больше, то я должен был использовать основной IP адрес или покупать новый адрес (для seo-линков конечно такой подход просто идеален, но для кармана не особо, поскольку я планировал что этого хостинга мне должно было хватить на 30+ сайтов, и никак не рассчитывал при этом ежемесячно докидывать 30 баксов за выделенные адреса ).  В итоге, весь вчерашний день я убил на жаркую переписку со службой поддержки Webintellects, в процессе которой успело засветиться неколько специалистов их технической и пресейл поддержки, от продавца, до руководителя системного администрирования. Собственно последний  (при том, что 3 админа до этого сработали “на отъе..”) как раз  и дал мне совет что и как попытаться сделать, и хотя, как оказалось, совет был не рабочий, но это дало мне правильное направление изысканий, так что за час плясок с бубнами вокруг WHM, я все таки умудрился повесить больше одного домена на дополнительные IP, так что вопрос переезда и с этого хостинга, для меня вроде как отпал- надеюсь насовсем.

Далее подробнее, а пока могу сказать, что впечатления от Cyber Wurx просто самые замечательные, поскольку мой журнал Что Читать, отвратительно работавший на движке Globat, на новой площадке просто летает. В добавок к этом очень порадовала общительная и оперативная поддержка клиентов- так что будем продолжать сотрудничество с данными товарищами.

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

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

Поскольку у меня в системе нет ни того, ни другого, то я спокойно пойду спать…

Обновления ТиЦ

2009 год
26 января
12 февраля
27 марта
28 апреля
22 мая
10 июня
26 июня
31 августа
16 октября
30 октября
24 декабря

2010 год
28 января
19 февраля
03 марта
08 апреля

Обновление PR

2009 год
1 января
3 апреля
29 мая
24 июня
31 октября

2010 год
1 января
5 апреля

http://www.yougetsignal.com/tools/web-sites-on-web-server/

https://secure.domaintools.com

http://www.ip-adress.com/reverse_ip/

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

Собственно ситуация была простая: перенес данный сайт с субдомена odmin.sane4ka.ru на собственный новообретенный домен odminblog.ru, после чего из выдачи Яндекса, в течение нескольких дней, вылетели оба домена принадлежавших к старому домену: www.sane4ka.ru и zavalinka.sane4ka.ru

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

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

В итоге после полутора недель ожидания, мне упало письмо от поддержки Яндекса, за подписью естественно Платона Щукина, смысл которого сводился к тому, что дескать извини мужик- херня вышла. Будем искать в чем причина.

Причину они видимо искали еще где то 5 дней.

И вот только что пришел финальный росчерк:

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

Просим Вас высказать свое мнение о полученном ответе:

http://feedback.yandex.ru/appraisal.xml?session=XXXX

–
С уважением, Платон Щукин
Служба поддержки Яндекса
##########

Две недели конечно срок не малый опять же, но с другой стороны это лучше чем сообщение: извини, но на тебе глобальный бан. Теперь остается ждать две недели и следить как появится. За время отсутствия в индексе, основной домен потерял 10ку ТиЦев, на второй это никак не повлияло.