Рубрика «Сайты и их проблемы»

Русская CMS DJEM

Wednesday, 13 Jun 2012

Довелось мне тут, в рамках одного проекта, познакомиться с российской разработкой- CMS DJEM. Хотя назвать DJEM именно системой управления контентом я бы не смог- скорее это среда разработки сайтов, то есть Framework, а не CMS.

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

(more…)

VN:F [1.9.21_1169]
Rating: 3.4/10 (21 votes cast)
VN:F [1.9.21_1169]
Rating: +6 (from 8 votes)

Передача больших объемов данных через интернет

Sunday, 01 Apr 2012

За последний годы, объемы данных возросли многократно, и если в 96 году файловый сервер стоявший в здании М9 имел RAID-массив аж на целых 500 мегабайт, что вызывало благоговейный трепет, то сейчас, покупая флешку, даже не рассматриваешь модели менее 8Гб. Соответственно в разы возросли и скорости передачи данных, но с приходом новых поколений пользователей, появляется новая проблема, когда люди начинают недоумевать отчего они не могут переслать 2-3Гб по почте.

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

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

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

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

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

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

VN:F [1.9.21_1169]
Rating: 5.0/10 (1 vote cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

Сервисы защиты от DDoS атак

Saturday, 19 Nov 2011

Многие люди работающие в интернете, слышали про такого страшного зверя как DDos-атака, которая представляет собой тоже самое что и DoS атака, направленная на нарушение работоспособности целевого ресурса- будь то корпоративный сайт, почтовый сервер или сегмент сети. Основным отличием от DoS атаки в механизме DDos, является то что в этом типе атаки может быть использовано несколько типов DoS атак, и исходить они могут с десятков, а то и сотен тысяч узлов по всему интернету, так что обычные методы борьбы, применяемые против DoS атак, как то невосприимчивость целей к атакам, а также бан по IP атакующих хостов; в случае DDoS атаки не работают. Так как даже если у вас установлена заплатка на сервере и он не восприимчив в используемым типам атак, может сложиться такая ситуация, что сервер будет занят только отражением атакующих пакетов, или же эти тысячи обращений в секунду настолько забьют канал, что сервер, оставаясь работоспособным все равно будет не доступен для внешних сетей, то есть DDoS можно будет считать успешным и состоявшимся.

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

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

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

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

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

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

VN:F [1.9.21_1169]
Rating: 7.0/10 (3 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 2 votes)

Проигрывание видео средствами Microsoft SharePoint Foundation

Thursday, 10 Nov 2011

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

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

(more…)

VN:F [1.9.21_1169]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

Настраиваем MySQL для работы на VPS с 512Mb RAM

Saturday, 08 Oct 2011

Прикупил я тут клиенту хостинг под его новый сайт. Поскольку была необходимость в прикручивании библиотеки ffmpeg на сайт под Drupal, для того чтобы видюшки конвертились сами во флешки при добавлении, хотя для меня это не убедительно, так как на локальном компе можно нормально законвертить ручками. Ну вообщем по причине наличия ffmpeg решил взять самый дешевый VPS за 5,95$ у Burst.NET с 512 оперативы, 1MHz, 20Gb HDD, 10Tb трафа и 2IP + Direct Admin за 7$, так как настраивать руками меня ломало.

Взять то я его взял, но вебмастера не могли ничего делать, так как на любую операцию система ругалась:
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

(more…)

VN:F [1.9.21_1169]
Rating: 7.0/10 (10 votes cast)
VN:F [1.9.21_1169]
Rating: +3 (from 3 votes)

Панда к нам приходит когда её совсем не ждешь

Tuesday, 04 Oct 2011

новая панда от googleС середины сегодняшнего дня стал замечать интересные изменения в статистике посещений на своих туристических проектах, которые ушли в никуда после того как Google анонсировал свой поисковый фильтра Panda для рунета. Учитывая что все блоги у меня рукописные и в них я вложил массу сил, то это падения трафика (которое на основном проекте составило порядка 25%) меня несколько огорчило. Но тем не менее я продолжал развивать свои проекты, правда уже с меньшим усилием.

И вот сегодня посещалка на основном блоге, на котором она уже с месяц не поднималась выше 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 будет столь же юзерфрендли как и этот.По крайней мере я даже боюсь что либо делать на сайтах, на которых планировал провести довольно серьезные изменения по внутренней перелинковке, для повышения позиций сайта. :)

VN:F [1.9.21_1169]
Rating: 3.3/10 (43 votes cast)
VN:F [1.9.21_1169]
Rating: +5 (from 11 votes)

Настройка кеширующего DNS сервера на базе BIND

Friday, 19 Aug 2011

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

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

(more…)

VN:F [1.9.21_1169]
Rating: 3.8/10 (24 votes cast)
VN:F [1.9.21_1169]
Rating: +3 (from 7 votes)