Блог компании DinoHost.ru

Архив Декабрь 2008

Редактор командной строки Pico и его установка

Четверг, 11 Декабрь, 2008

Чаще всего редактор командной строки Pico на вашем сервере уже установлен по умолчанию. Однако случаются и исключения.

Чтобы узнать, стоит ли на вашем сервере такой редактор, вам нужно соединиться с сервером по SSH и ввести «rpm -q pine». Если в ответ в окне появилась строка типа «package pine is not installed», вам необходимо ввести строку «wget ftp://rpmfind.net/linux/redhat/9/en/os/i386/RedHat/RPMS/pine-4.44-18.i386.rpm» и установить заказанный пакет с помощью «rpm -Uvh pine-4.44-18.i386.rpm».

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


Установка менеджера файлов Putty.exe.

Четверг, 11 Декабрь, 2008

После загрузки и установки Putty.exe его нужно немного настроить:

“server ip here” – что означает IP адрес сервера

Кликните на ( ) SSH чтобы изменить порт доступа на 22

Server Name – здесь необходимо ввести название вашего сервера (любое, как хотите, так и называйте, главное – запомните его).

Далее необходимо сохранить настройки конфигурации, кликнув “Save”

Чтобы соединиться с сервером, теперь вам нужно запустить Putty и два раза кликнуть на имени сервера, которое отображается под строкой “Default Settings”. После чего Putty соединит Вас с сервером и запросит ваш логин и пароль. Введя логин и пароль вы сможете соединиться сервером по SSH.


К вопросу о безопасности сервера

Понедельник, 8 Декабрь, 2008

После того, как из дата-центра пришло сообщение о том, что ваш сервер готов и онлайн, необходимо внести настройки безопасности на сервер.

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

Для работ на сервере вам понадобится программа Putty. Затем после установки редактора командной Pico переходим к работе с командной строкой, которая не имеет графического интерфейса.

1. Необходимо оставить подключение только по протоколу SSH2, как самое безопасное, и отключить прямой логин для root. Для этого вводим в командную строку:
pico -w /etc/ssh/sshd_config

Далее ищем в открывшемся файле строку
#Port 22
И убираем из нее знак #

Ищем строку: #Protocol 2, 1
И изменяем ее на: Protocol 2

Так вы сможете запретить подключение к серверу по протоколу SSH1, ведь такое соединение недостаточно защищено.

В WHM создаем аккаунт админа с нестандартным логином и паролем, как можно боле сложным. Для админа разрешите соединение SSH, после чего зайдите в WHM:

Server Setup, затем в:
Manage Wheel Group Users

Назначьте админа как члена Wheel Group.

Для этого введите

pico -w /etc/ssh/sshd_config

строку: #PermitRootLogin yes
Измените на: PermitRootLogin no

С помощью команды: /etc/rc.d/init.d/sshd restart перезагрузите демон SSH

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

Для соединения с сервером вы будете использовать логин и пароль, назначенный вами для админа, после чего вводить «su -» root пароль.

Для отключения от сервера достаточно будет ввести «exit» и нажать ENTER.

2. Настраиваем сообщения по электронке в ROOТ логине на вашем сервере

Для этого необходимо отредактировать файл
.bash_profile
в директории пользователей /root

для редактирования файла используем команды:
cd
su -
pico .bash_profile

В конце файла нужно ввести строку:
echo ‘ALERT - Root Shell Access on:’ `date` `who` | mail -s “Alert: Root Access on Server #1″ admin@XXXXXXX.com

Строка admin@XXXXXXX.com будет означать ваш адрес на другом сервере. Такое ухищрение необходимо для того, чтобы вторгнувшийся на ваш сервер не смог уничтожить сообщение о своем вторжении.

Сохраняем изменения в файле при помощи комбинации клавиш
CTRL+X
Y
И ENTER.

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


Хостинг на основе WEB 2.0

Пятница, 5 Декабрь, 2008

Многие из нас наслышаны о технологиях WEB 2.0, но каким на самом деле будет хостинг для WEB 2.0, мало кто думал.

Новшества будут заметны невооруженным взглядом в наполнении контентом, который будет более четкий и однозначный. Будет осуществляться реальная поддержка клиентов, аптайм максимально приблизится к 100%, гео-кластеризация, а также суперповышенная защита от DDOS атак.

Суть WEB 2.0 заключается в том, что пользователи сайта являются главными его авторами, формируя контент сайта непосредственно из окна браузера. О такой фишке как FTP забудут, а загрузка информации будет осуществляться из окна браузера. Сайт можно будет полностью изменять в визуальном редакторе. А HTML 5 даст еще больше возможностей в этом плане.

Обычный хостинг предлагает своим клиентам самые обыкновенные технологии, не дающие каких-либо гарантий. Из-за некоторых настроек безопасности хостинга может не работать совсем или работать некорректно СМS вашего сайта.

С этой точки зрения хостинг WEB 2.0 предложит своим клиентам новые сервисы. Под него будут модифицированы самые популярные CMS, движки блогов и форумов. Такие инструменты предложат клиентам уже готовый и предустановленный сервис, настроить который можно сразу же из браузера.

Хостинг WEB 2.0 будет предлагать не список технологий, а список сервисов, хорошо и четко работающих.

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

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

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

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

Разделив классическую файловую систему, вы получите повышенную отказоустойчивость и сократите избыточность дублированной информации на одном сервере. Для классической CMS не требуется модификация ее ядра, а изменяются всего лишь 1-2 дирректории, в том числе и БД.

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

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

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

Давайте представим себе классический сервер хостинга WEB 2.0:
• Прежде всего, на нем стоит nginx, который отдает статический контент
• Далее классический apache
• Для исполнения скриптов используют fastcgi php
• MySQL сервер, работающий в режиме slave, который в любой момент может стать master
• Репозиторий сервисов хранится на разделе диска, размеченного под классической ФС. Файловый сервер в любой момент может измениться и синхронизироваться с остальными серверами через rsync
• Между остальными серверами коммуникации WEB 2.0 стоит демон.
• Отказоустойчивая файловая система расположена на оставшейся части диска Одновременное использование большого числа серверов направляют их ресурсы на борьбу с DDOS атаками.
• При атаке одного из серверов демон комуникации сообщает IP сети атаки на остальные сервера, после чего постепенно блокируются все IP ботнеты.

Сейчас распределенной файловой системы с открытым исходным кодом, полностью подходящей для системы хостинга WEB 2.0 пока не существует. Ближе всего к истине находится Hadoop HDFS с Namenode.


Особенные характеристики выделенного сервера

Пятница, 5 Декабрь, 2008

В чем особенность и главные отличия выделенного сервера? Прежде всего, в том, что выделенный сервер - это все ресурсы, а также нестандартные возможности. К примеру, для того, чтобы получить высокоскоростной доступ к сайтам, построенным на движках вида phpnuke, необходимо использовать 2 веб-сервера, которые не обязательно могут быть размещены на одном веб-сервере.

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

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

Такой нюанс, как возможность докупить дополнительные IP из другой подсети, необходим только для NS доменов в зоне RU. А вот возможность увеличить объем памяти, подключить дополнительный жесткий диск и список панелей, имеющихся в наличии, их стоимость и перечень подходящих ОС очень важные критерии выбора дедика.


Дедик или выделенный сервер – что это такое?

Понедельник, 1 Декабрь, 2008

Dedicated Server, в переводе с английского выделенный сервер, а на жаргоне просто «Дедик». В отличие от виртуального dedicated хостинг представляет собой выделенный сервер, место на котором не делится между несколькими сайтами, обслуживающихся хостером. Выделенный сервер расположен в специальном дата-центре, где для его бесперебойной работы обеспечены необходимые условия. Это и подача энергии, и охлаждение, а также канал и место в стойке.

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

По обслуживанию выделенные серверы делятся на две категории: unmanaged (необслуживаемые) и managed (обслуживаемые). Техподдержка необслуживаемых серверов обычно сводится к перезагрузке сервера и переустановке ОС, если она вышла из строя из-за неграмотного обращения с ней.

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

Техподдержка или support также подразделяется на уровни (levels).

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

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

Решение глобальных проблем или траблшутинг – это специализация support level 3. Этот уровень техподдержки способен найти решение таким проблемам как некорректная работа ПО, медленная загрузка сервера, аппаратные проблемы, настройка и корректировка работы ПО.

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

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

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

Есть и другой вариант – дата-центр предлагает оплачивать услуг по числу тикетов. То есть хозяином сервера предоставляется определенное количество тикетов в месяц – от 20 до 100. Это количество тикетов будет обслуживаться бесплатно, но если вы его превысите, за остальные тикеты придется платить отдельно. Могут быть и такие условия, что бесплатные тикеты предоставляются хостером только для первого уровня техподдержки, а все остальные уже платные.

SLA – еще один важный момент. Это уровень сетевой доступности, который означает, что отправленный вами запрос будет прочитан немедленно, даже ночью в воскресенье, и обработан в указанные в договоре сроки. Но стоит помнить о том, что даже обещанный SLA в 99% на деле может сильно до этого уровня не дотягивать.

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