Настройка веб-сервера Apache, для локального сервера Windows
Вступительная часть
Продолжаем собирать локальный сервер на своем компьютере, с осью Windows. После установки трех компонентов локального сервера AMP (Apache+MySQL+PHP) на свой компьютер, работающий под Windows, переходим к их настройке. В этой статье настроим веб-сервер, Apache.
Подготовка к настройке веб-сервера Apache
Если вы делаете установку локального сервера без временных пауз, вам достаточно легко, будет вспомнить, куда вы установили компоненты сервера Apache; MySQL; PHP.
Общая задача настроек Apache; MySQL; PHP это связать их воедино, указав в каждом из них, расположение других серверов. А также, нужно выставить наиболее приемлемые настройки параметров этих компонентов.
Задача этой статьи, понять, где у сервера Apache, лежит «золотой ключик» настроек. Настройки можно менять в зависимости от встающих задач, ведь глобальная задача, не установить локальный сервер на локальный компьютер, а пользоваться им.
Настройка веб-сервера Apache по шагам
Идем в директорию установки Apache. В прошлых статьях я ставил Apache в папки c:/www (установка Apache MSI) и c:/Apache24;
В папке c:/www/conf нам нужен файл конфигурации веб-сервера, httpd.php;
Настройка веб-сервера Apache (редактирование файла) делаем в удобном редакторе Notepad++.
Примечание: Термин раскомментировать (uncomment), означает открыть доступ к функционально строке файла для системы. По факту. Раскомментировать в файлах Apache, значит убрать в начале строке знак решетка (#).
1. uncomment: #LoadModule rewrite_module modules/mod_rewrite.so(включаем загрузку для модуля mod_rewrite)
включаем загрузку для модуля mod_rewrite2. В конце группы директорий LoadModule, прописываем расположение вашего уже установленного сервера PHP и этим, подключаем PHP к Apache (расположение пишите свои).3. uncomment [#ServerName localhost:80] 4. Проверьте правильность директивы (проверяем путь): DocumentRoot «C:/www/htdocs» 5 Для управление Apache на сайтах создаются файлы .htaccess. Чтобы включить в работу этот файл в блоке директив:LoadModule php5_module "C:/php/php5apache2_2.dll" AddType application/x-httpd-php .php PHPIniDir "c:/php/"
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>Меняем [None] на команду [All]
6. В строку [DirectoryIndex:] вписываем максимальное количество разрешенных расширений [index.html index.shtml index.htm index.php index.phtml](816)#AddType text/html .shtml
(817)#AddOutputFilter INCLUDES .shtmlДополняем их двумя строками:
AddType application/x-httpd-php-source .phps
AddType application/x-httpd-php .php(тем самым, включаем SSL на Apache)
Проверка работы файла httpd.php
Для проверки правильности настройки идем через меню «Пуск» во все программы, далее Apache HTTP файл «TestConfiguration». Если есть ошибки они отразятся на экране.
Вывод
Настройка веб-сервера Apache завершена. В завершении замечу, что в файле httpd.php сервера Apache, все директории и блоки директорий снабжены подробными комментариями на английском языке. Для глубоко понимания настроек их нужно почитать.
Скачать файл httpd.php сервера Apache можно тут configs (на сайте). Обратите внимание, что в нем другое место расположения Apache.
©www.wordpress-abc.ru
Еще статьи
Похожие посты:
Права доступа CHMOD для пользователей и групп в Apache
Недавно мне довелось прочесывать интернет в надежде найти подробную информацию о том, как правильно выставить права доступа для пользователей и групп в Apache с помощью chmod. Что мне удалось найти:
Есть три группы прав доступа к файлам/директориям, о которых вам стоит позаботиться:
- Пользователь – что может делать владелец файла;
- Группа – что могут делать пользователи отдельных групп;
- Другие – что могут делать остальные пользователи.
У пользователей есть логины (уникальные для каждого пользователя). Пользователи могут быть частью группы.
Примечание: команда chmod принимает целые числа (0664), и каждая из цифр отвечает за определенные права доступа.
Сегодня я расскажу вам о том, как правильно использовать chmod-настройки. Chmod используются для изменения прав доступа к директории или файлу.
Chmod cинтаксис:
chmod -flags permissions /path/to/dir/or/file
chmod –R позволит рекурсивно пройтись по всей указанной директории и изменить права доступа для всех файлов и вложенных директорий.
Вы можете определять, для кого изменяете права доступа:
- u = пользователь;
- g = группа;
- o = другие.
Вы можете добавлять или удалять права доступа при помощи следующих команд chmod:
- + добавить права доступа;
- — удалить права доступа.
Можно задавать следующие права доступа:
- r = чтение;
- w = запись;
- x = исполнение.
Эти знания можно использовать для настройки прав доступа в Apache:
- Apache запущен как пользователь www-data в группе www-data;
- Корневой каталог сервера: /var/www.
Нам нужно установить владельца/группу для корневого каталога (и любых внутренних директорий и файлов):
$ sudo chown -R www-data:www-data /var/www
Нужно установить правильные права доступа для пользователей и групп. Запускаем несколько общих команд, которые закрывают доступ, а затем открываем доступ, насколько нам требуется.
Сначала сделайте так, чтобы никто кроме текущего пользователя (www-data) не имел доступа к содержимому директории web-root. Мы используем ‘go‘, поэтому команда будет направлена к группам и другим пользователям (‘group‘ и ‘other‘). Также мы используем ‘—‘ для отключения прав доступа. Затем используется параметр ‘rwx‘, чтобы запретить чтение, запись и исполнение.
Далее нужно разрешить пользователям из той же группы (и ‘other’) открывать директорию /var/www. Это делается без рекурсивного подхода. Мы указываем ‘group‘ и ‘other‘, но используем параметр ‘+‘, чтобы разрешить исполнение (chmod ‘x’).
Далее изменяем права доступа всех директорий и файлов в корневом каталоге для той же группы (www-data). На случай, если в ней есть файлы:
$ chgrp -R www-data /var/www
Теперь нужно произвести некоторые «сбросы». C помощью команд chmod сделайте так, чтобы только один пользователь мог осуществлять доступ к контенту:
$ chmod -R go-rwx /var/www
Сделайте так, чтобы любой пользователь из той же группы мог читать/записывать и выполнять директории и файлы в корневом каталоге на сервере:
Лично я дал группе право записывать – это нужно для тех пользователей, которые редактируют контент. Выглядит это следующим образом:
$ chmod -R g+rwx /var/www
Зачастую вам даже не придется проделывать все это, но данная статья вполне способна помочь разобраться.
Данная публикация представляет собой перевод статьи «User and Group permissions, with chmod, and Apache» , подготовленной дружной командой проекта Интернет-технологии.ру
www.internet-technologies.ru
Дополнительная Настройка Apache
Apache — частица программного обеспечения, легко поддающаяся настройке. Он имеет множество миссий, но каждая является ценной. Настройка Apache отчасти заключается в надлежащем распределении источников и подразумевает отключение ненужных настроек.
Конфигурирование мультипроцессорных модулей
Приложение Apache является модульным, в том смысле, что вы легко можете добавлять и удалять его элементы. Эту модульную функциональность в ядре Apache — управление сетевыми соединениями и отправку запросов — обеспечивают мультипроцессорные модули (Multi-Processing Modules, MPM). Модули позволяют вам использовать thread’ы или даже перемещать Apache в другую операционную систему.
Одновременно может быть действующий лишь один мультипроцессорный модуль и он должен быть скомпилирован статически при помощи —with-mpm=(worker|prefork|event) .
Обычная модель «один процесс на запрос» назвается prefork. Более новая, модель с thread’ами, называемая worker, использует несколько процессов, каждый с несколькими thread’ами, для получения более высокой производительности при более низких накладных расходах. Наконец, event — экспериментальный модуль, который содержит особые гурьбы thread’ов для различных задач. Чтобы определить, какой мультипроцессорный модуль вы сейчас используете, осуществим httpd -l.
Выбор мультипроцессорного модуля зависит от многих факторов. Отключение модуля event до тех пор, покамест он имеет экспериментальный статус, — это выбор меж thread’ами и их отсутствием. Внешне кажется, что использовать thread лучше, чем использовать fork, если целое основные модули являются безопасными thread’ами, включая целое используемые PHP библиотеки. Prefork — более безопасный выбор; если вы выбрали worker, вы должны провести тщательное тестирование. Рост производительности также зависит от входящих в дистрибутив библиотек и вашего оборудования.
Независимо от того, какой мультипроцессорный модуль вы выбрали, вы должны согласным образом сконфигурировать его. Вообще, конфигурирование модуля подразумевает определение, как Apache контролирует количество запущенных worker’ов, являются ли они thread’ами или процессами. В Листинге 1 показаны важные опции конфигурирования модуля prefork.
Листинг 1. Конфигурирование мультипроцессорного модуля prefork
StartServers 50
MinSpareServers 15
MaxSpareServers 30
MaxClients 225
MaxRequestsPerChild 4000
Сборка вашего собственного программного обеспечения
Когда я начинал использовать UNIX®, я настаивал на том, чтобы собирать свои собственные программы для целого, что я назначал на свою систему. В итоге поддержка обновлений утомила меня, так что я узнал, как образовывать пакеты для облегчения этой задачи. В конце концов я понял, что большую доза времени я дублировал усилия производителей дистрибутива; ныне, если это возможно, я по большей частицы использую то, что предоставляет выбранный мной дистрибутив, и созидать свои собственные пакеты в казусе необходимости.
Вы тоже можете разрешить, что удобство поддержки пакетов производителем перевешивает выгоды от наличия самого свежего, прекрасного кода. Иногда настройки производительности и системное администрирование имеют противоположные задачи. Если вы используете коммерческий Linux или рассчитываете на стороннюю поддержку, вы можете рассмотреть допустимость использования поддержки производителя.
Если вы придумываете свои программы, узнайте, как основывать пакеты, которые работают в вашем дистрибутиве, и как включить их в вашу систему патчей. Это будет гарантией того, что программное обеспечение и сделанные вами настройки будут совместимы, и их можно будет использовать в других системах. Также поддерживайте последние обновления программного обеспечения, подписавшись на должные табели рассылки и материалы Rich Site Summary (RSS).
В модуле prefork новый процесс создан при помощи запроса. Резервные процессы простаивают, чтобы общаться с поступающими запросами, что уменьшает время ожидания запуска. Предыдущая конфигурация запускает 50 процессов, как лишь стартует Web-сервер, и старается поддерживать в наличии от 10 до 20 простаивающих запущенных серверов. Жесткий лимит процессов определяется при помощи MaxClients. Даже если процесс может общаться с множеством последовательных запросов, Apache убивает процессы после 4,000 соединений, что уменьшает риск утечки памяти.
Конфигурирование мультипроцессорных модулей с поддержкой thread’ов производится подобным образом, за исключением того, что вы должны определить, сколько thread’ов и процессов должно использоваться. Документация Apache дает разъяснения по целым параметрам и необходимым счетам.
Выбор используемых значений подразумевает некий метод проб и ошибок. Наиболее важное значение — MaxClients. Мишень заключается в том, чтобы разрешить достаточное количество процессов worker или thread’ов, чтобы сервер не занимался исключительно свопингом. Если поступает больше запросов, чем может быть обработано, то по крайней мере те, которые устроились, обрабатываются; другие блокируются.
Если MaxClients чересчур высок, целое клиенты получают недостаточно высокий уровень сервиса, поскольку Web-сервер пробует выгрузить один процесс, чтобы позволить выполняться другому. Установка излишне низкого значения приводит к тому, что вы можете необоснованно отказать в обслуживании. Проверка количества процессов, запущенных в момент повышенной нагрузки, и анализ объема памяти, используемой целыми процессами Apache, дает вам хорошую идею сравнительно установки этого значения. Если вы устанавливаете значение MaxClients выше 256, вы должны определить то же значение для ServerLimit; внимательно прочитаем документацию по мультипроцессорным модулям, чтобы узнать о должных предостережениях.
Настройка количества запускаемых серверов и наличие запасных зависит от роли сервера. Если на сервере выполняется лишь Apache, вы можете использовать маленькое значение, как показано в поскольку вы можете использовать машину в полной мере. Если система используется еще и основой данных или другим сервером, вы должны ограничить количество запасных запущенных серверов.
Эффективное применение опций и переопределений
Каждый запрос, который обрабатывает Apache, проходит через сложный набор правил, которые диктуют любые ограничения или отдельные инструкции, которым должен руководствоваться Web-сервер. Доступ к папочке может быть ограничен IP-адресом для определенной папочки, или могут быть сконфигурированы имя пользователя и пароль. Эти опции также включают обработку определенных документов, например, если предоставляется листинг каталога, они определяют, как будут обрабатываться определенные типы документов, или должен ли быть сжат итог.
Эти конфигурации имеют тип контейнеров в httpd.conf, например, <Directory> определяет, что конфигурация обращается к местоположению на диске, или <Location> задает отсылку на путь, указанный в URL. В Листинге 2 показан контейнер Directory в действии.
Листинг 2. Контейнер Directory, применяемый к каталогу root
<Directory />
AllowOverride None
Options FollowSymLinks
</Directory>
В Листинге 2 конфигурация, ограниченная тегами Directory и /Directory, применяется к данному каталогу и его содержимому — в этом факте к каталогу root. Здесь тег AllowOverride определяет, что пользователям не разрешается отменять любые опции (более подробно об этом позже). Опция FollowSymLinks разрешена, что позволяет Apache видеть прошлые символьные линки для обслуживания запроса, даже если документ не входит в каталог, содержащий Web-документы. Это означает, что если документ в вашем Web-каталоге является символьным линком на /etc/passwd, Web-сервер удачно обслужит документ, если попаду запрос. Использование -FollowSymLinks отключит эту осуществимость, и тот же самый запрос будет причиной возврата ошибки клиенту.
Последний сценарий — повод для беспокойства на двух фронтах. Ведущий — вопрос производительности. Если FollowSymLinks отключен, Apache должен проверять каждый компонент имени документа (каталоги и собственно документ), чтобы убедиться, что они не являются символьными линками. Это влечет дополнительные накладные расходы в форме нагрузки на диск. Сопутствующая опция FollowSymLinksIfOwnerMatch руководствоваться за символьным линком, если владелец документа тот же, что и владелец линка. Это оказывает таковое же влияние на производительность, как и отключение следования символьным линкам.
Читатели, которых волнуют вопросы безопасности, уже должны быть обеспокоены. Безопасность — всегда компромисс меж функциональностью и риском. В этом эпизоде функциональность — это скорость, и риск предполагает неавторизованный доступ к документам системы. Смягчающим фактором является то, что серверы приложений LAMP обычно предназначены для определенной миссии, и пользователи не могут учреждать потенциально опасные символьные линки. Если жизненно необходимо разрешить проверку символьной ссылки, вы можете разрешить это едва в определенной области файловой системы, как показано в Листинге 3.
Листинг 3. Ограничение FollowSymLinks для каталога пользователя
<Directory />
Options FollowSymLinks
</Directory>
<Directory /home/*/public_html>
Options -FollowSymLinks
</Directory>
В Листинге 3 каждый каталог public_html в комнатный каталоге пользователя имеет опцию FollowSymLinks, отключенную для этого и целых вложенных каталогов.
Как вы видели, опции могут конфигурироваться на покаталожной основе через конфигурацию первого сервера. Пользователи могут самостоятельно отменить конфигурацию сервера (если администратором разрешено AllowOverrides), исключив из каталога документ .htaccess. Этот документ содержит дополнительные директивы сервера, которые загружаются и применяются к каждому запросу каталога, в котором содержится документ .htaccess. Несмотря на прежние рассуждения об отсутствии в системе пользователей, многие приложения LAMP используют эту функциональность для осуществления контроля доступа и для перезаписи URL, так что это целесообразно для осмысления того, как это работает.
Несмотря на то, что утверждение AllowOverrides препятствует пользователям в совершении тех действий, которые вы хотите им запретить, Apache по-прежнему должен искать документ .htaccess, чтобы выяснить, нужно ли что-нибудь сделать. Родительский каталог может определить директивы, которые должны быть обработаны запросом дочернего каталога, что означает, что Apache должен также исследовать каждый компонент дерева каталогов, ведущий к запрашиваемому документу. По толковым причинам это является причиной высокой дисковой активности по каждому запросу.
Самое простое решение — не позволять любые переопределения, которые отменяют необходимость проверки Apache документа .htaccess. Любые специализированные конфигурации затем помещаются непосредственно в httpd.conf. В Листинге 4 показано, что нужно добавить в httpd.conf, чтобы позволить проверку пароля для пользовательского каталога project, вместо того чтобы помещать информацию в документ .htaccess и надеяться на AllowOverrides.
Листинг 4. Перемещение конфигурации .htaccess в httpd.conf
<Directory /home/user/public_html/project/>
AuthUserFile /home/user/.htpasswd
AuthName «uber secret project»
AuthType basic
Require valid-user
</Directory>
Если конфигурация помещена в httpd.conf и AllowOverrides отключен, интенсивность использования диска может уменьшиться. Каталог пользователя project может не привлечь большого количества воззваний, но учитывайте мощь этого метода применительно к сайту, работающему с большой нагрузкой.
Иногда невозможно исключить использование документов .htaccess. Например, в Листинге 5, где выбор ограничен определенной деталью файловой системы, вероятность отмены также может быть ограничена.
Листинг 5. Ограничение проверки .htaccess
<Directory />
AllowOverrides None
</Directory>
<Directory /home/*/public_html>
AllowOverrides AuthConfig
</Directory>
После того как вы осуществим операции из Листинга 5, Apache целое же ищет документы .htaccess в родительском каталоге, но прекращает поиск в каталоге public_html, поскольку становится невозможным функционирование остальной доли файловой системы. Например, если запрашивается документ /home/user/public_html/project/notes.html, то его успешное отображение произойдет лишь в том факте, если каталоги public_html и project будут открыты.
Уместно сделать одно последнее замечание сравнительно относящихся к отдельным каталогам конфигураций. Всякий документ о настройке Apache дает указание запретить DNS lookup через директиву HostnameLookups off, поскольку попытки назад разрешить соединения целых IP-адресов с вашим сервером — излишняя трата источников. Однако любые ограничения, базирующиеся на имени хоста, вынуждают Web-север выполнять обратный lookup на IP-адресе клиента и прямой lookup на основании результата проверки подлинности имени. Поэтому благоразумно избегать использования снадобьй контроля доступа, базирующихся на имени хоста, и, когда они необходимы, проверять их, как описано.
Постоянные соединения
Когда клиент соединяется с Web-сервером, разрешается порождение множественных запросов по одному и тому же TCP-соединению, что уменьшает время ожидания, связанное с многократными соединениями. Это полезно, когда Web-страница содержит несколько изображений: клиент может запросить страницу и затем целое изображения в течение одного соединения. Обратная сторона заключается в том, что процесс worker на сервере должен ожидать закрытия сеанса клиентом, прежде чем он сможет перешагнуть к грядущему запросу.
Apache позволяет вам определять, как будут обработаны постоянные соединения, называемые keepalives. KeepAlive 5 на глобальном уровне httpd.conf позволяет серверу обработать 5 запросов на соединение, прежде чем соединение будет насильственно прервано. Установка этого количества в 0 запретит использование постоянных соединений. KeepAliveTimeout, тоже на глобальном уровне, определяет, как долго Apache будет ожидать другого запроса, прежде чем сессия закроется.
Обработка постоянных соединений не является конфигурацией типа «один-размер-годится целым». Некоторые Web-сайты функционируют лучше, если keepalives запрещены (KeepAlive 0), и в некоторых курьезах их включение может принести непомерную пользу. Единственное решение — испробовать оба варианта и выяснить целое самостоятельно. Тем не меньше разумно использовать низкий таймаут, например, 2 секунды, при помощи KeepAliveTimeout 2, если вы разрешили keepalives. Это даст гарантии, что всякий клиент, желающий сделать другой запрос, будет иметь достаточное количество времени, и что процессы worker не останутся без работы, ныне будут ждать другого запроса, который может никогда не попасть.
Сжатие
Web-сервер может сжимать ответ, прежде чем он возвратить его клиенту. В результате уменьшается объем страницы, посылаемой по Интернету, за счет циклов CPU на Web-сервере. Для тех серверов, которые могут позволить себе высокую нагрузку на CPU, это отличный способ создания быстро загружаемых страниц — размер страницы может после сжатия уменьшиться втрое.
Изображения обычно уже сжаты, поэтому необходимо сжимать лишь текстовый ответ. Apache предусматривает сжатие при помощи mod_deflate. Несмотря на то, что mod_deflate может быть свободно отключен, он содержит множество сложных моментов, которые руководство стремится объяснить. Эта статья не касается темы конфигурирования сжатия, за исключением предоставления ссылки на согласную документацию.
Настройка PHP
PHP — движок, который запускает код приложений. Вы должны определить лишь модули, которые планируете использовать, и сконфигурировать ваш Web-сервер для использования PHP едва для документов скриптов (обычно те документы, названия которых заканчиваются на .php) а не целых статических документов.
Кеширование кода операции
Когда запрашивается скрипт PHP, PHP читает скрипт и собирает его в то, что называется код операции Zend, бинарное представление кода, который будет выполнен. Этот код операции затем выполняется движком PHP и теряется. Кэш кода операции сохраняет его и в второй раз при запросе страницы вновь использует. Это экономит немало времени. Некоторые кэши кода операции доступны; я благополучно использовал eAccelerator.
Инсталляция eAccelerator требует наличия в компьютере библиотек разработки PHP. Поскольку разные дистрибутивы Linux помещают документы в разные места, получите инструкции по инсталляции непосредственно с Web-сайта eAccelerator’а. Также возможно, что ваш дистрибутив уже упаковал кэш кода операции, и вы должны свободно определить согласный пакет.
Независимо от того, каким образом вы определили на своей системе eAccelerator, есть несколько вариантов конфигурации. Конфигурационным документом обычно бывает /etc/php.d/eaccelerator.ini. eaccelerator.shm_size определяет размер кэша совместно используемой памяти, где хранятся скомпилированные скрипты. Значение измеряется в мегабайтах. Определение подходящего размера зависит от приложения. eAccelerator предоставляет скрипт для показа статуса кэша, который включает использование памяти; 64 мегабайта — хорошее значение для происхождения (eaccelerator.shm_size=»64″). Вы также можете настроить максимальный размер для shared memory, если выбранное вами значение не было принято. Добавьте kernel.shmmax=67108864 в /etc/sysctl.conf и запустите sysctl -p, чтобы настройки вступили в значительность. Значение kernel.shmmax измеряется в байтах.
Если превышен объем выделяемой shared memory, eAccelerator должен удалить из памяти старые скрипты. По умолчанию это отключено; eaccelerator.shm_ttl = «60» устанавливает, что когда eAccelerator исчерпывает размер shared memory, каждый скрипт, доступ к которому не был получен в течение 60 секунд, должен быть удален.
Другая популярная альтернатива eAccelerator — Alternative PHP Cache (APC). Создатели Zend также имеют коммерческий кэш кода операции, включающий оптимизатор для дальнейшего повышения эффективности.
php.ini
Вы конфигурируете PHP в php.ini. Четыре важных параметра настройки определяют, какое количество системных источников может потреблять PHP, как показано в Таблице 1.
Таблица 1. Параметры настройки php.ini, связанные с источниками
Параметр Описание Рекомендуемое значение
max_execution_time Сколько CPU-секунд может потреблять скрипт 30
max_input_time Как долго (в секундах) скрипт может ждать входных данных 60
memory_limit Какое количество памяти (в байтах) может тратить скрипт, прежде чем он будет убит 32M
output_buffering Какое количество данных (в байтах) накапливается в буфере, прежде чем они будут отправлены клиенту 4096
Размер этих значений обычно зависит от приложения. Если вы принимаете от пользователей большие документы, max_input_time может быть увеличен или в php.ini, или путем его переопределения в коде. Подобным образом, для программ, потребляющих большое количество CPU или памяти могут потребоваться более высокие значения. Мишень заключается в том, чтобы уменьшить влияние «прожорливой» программы, поэтому глобальная отмена этих настроек не отрекомендовывает. Другое замечание сравнительно max_execution_time: это относится к времени, затраченному CPU на процесс, а не к абсолютному времени. Таковым образом, программа, совершающая большое количество вводов/ответов и мелкое количество вычислений, может выполняться намного дольше, чем max_execution_time. max_input_time также может быть больше, чем max_execution_time.
Количество записей, которые может сделать PHP, может настраиваться. В промышленной эксплуатации экономят место на диске, отменяя целое журналы, кроме самых критических. Если журналы необходимы для диагностики трудностей, вы можете возвратить то журналирование, которое необходимо. error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR включает журналирование, достаточное для выявления загвоздок, но удаляет из скриптов лишнюю информацию.
skachivaem.ru