Настройка скриптов

• Возможно ли использование CMS (системы управления контентом) у нас на хостинге?
  Да, Вы можете использовать практически любую CMS, но Вы должны себе четко представлять:
  
  
  
  
  
  
  
  а) Устанавливая типовую CMS - Вы получаете также и типовые дыры в ней. Если вышедшее обновление (security update) вы не установите вовремя - этими обнаруженными дырами очень вероятно воспользуются злоумышленники.
  
  
  
  
  
  
  
  б) Универсальная CMS потребляет много процессорных ресурсов. Если Ваш ресур начнет набирать популярность, будьте готовы к тому, что вам придется либо оплачивать расходуемые системные ресурсы, либо оптимизироваться или полностью менять CMS на что-то более "легкое". Рекомендуем: SmallNuke, Joomla, phpBB2
• Настройки программы FARmanager для работы с Вашим хостингом
  В FARmanager заведение новой записи производится в следующем порядке: Одновременно нажимаете Alt+F1 – переходите в меню на строку «Ftp», затем Shift+F4 - создаете запись: логин:пароль@ftp.ваш домен строку с паролем и описанием ftp, теперь уже заполнять не нужно, нажимаете Connect, и соответственно попадаете на свой ftp-сервер.
  
  
  
  
  
  
  
• Какую версию Perl вы используете? Каков набор установленных модулей?
  На момент написания ответа мы используем Perl 5.8.8 Обновление версий софта происходит примерно каждые 3 месяца. Набор модулей достаточно велик, если вам потребуется модуль, которого нет в комплекте, напишите - мы его установим вам, либо даже включим комплект по умолчанию.
• Какая версия PHP используется на вашем хостинге?

  На наших серверах вы можете выбирать между: 5.2, 5.3, 5.4, 5.5, 5.6, 7.0, 7.1

• Есть ли на Ваших серверах поддержка Python?
  Да.
• Есть ли на Ваших серверах поддержка Ruby?
  Да.
• Поддерживаете ли вы Java Servlets и JSP?
  Нет, не поддерживаем, по крайней мере пока. На наш взгляд, в данном сегменте предложение и так превышает спрос.
• Каковы точные пути к Perl и другим программам?

  
  
  
  
  
  
  
  Путь для PERL: /usr/bin/perl, путь для sendmail: /usr/sbin/sendmail. Пути к скриптам вашего сайта:
  
  
  
  
  
  
  
  Основной каталог: /home/<ваш-логин>/data/www/<ваш_домен>/
  
  
  
  
  
  
  
  Cgi-bin: /home/<ваш-логин>/data/www/<ваш_домен>/cgi-bin
  
  
  
  
  
  
  
  *некоторые скрипты не работают без " -t" после пути к Sendmail, например: /usr/sbin/sendmail -t.

  
  
  
  
  
  
  
  
• Директория для размещения скриптов
  Автоматически после регистрации вами домена в корневом каталоге вашего
  
  
  
  
  
  
  сайта (www/<ваш сайт>) создается папка cgi-bin для размещения
  
  
  
  
  
  
  cgi скриптов.
  
  
  
  
  
  
  Не стоит помещать в этот каталог графические файлы и html и php-скрипты.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
• На другом хостинге PHP скрипт работал, у вас не хочет, в чем проблема?
  Если Вы действительно все настроили со своей стороны правильно, возможны 2 варианта:
  
  
  
  
  
  
  
  а) У нас по умолчанию register_globals=off. На это в частности ругается движок osCommerce. Можно включить эту настройку для конкретного аккаунта, это открывает дополнительные бреши в системе, особенно если Вы используете параллельно несколько CMS. Одна может требовать register_globals=on, а во второй при этом появляются дополнительные бреши в защите.
  
  
  
  
  
  
  
  б) На предыдущем хостинге PHP выполнялся как модуль web-сервера, а у нас он работает в режиме CGI. Замеченные отличия PHP в режиме CGI от модуля:
  
  
  
  
  
  
  
  1) $SCRIPT_NAME выдает неверное значение. (Нужно пользоваться $PHP_SELF ($_SERVER['PHP_SELF']))
  
  
  
  
  
  
  
  2) Не работают адреса типа: http://somehost.com/script.php/params/via/slash (нужно писать дополнительно правила для mod_rewrite)
  3)Не работает HTTP авторизация (либо авторизоваться через куки и сессии, либо использовать паролирование в панели управления)
  4) Скрипт не может получить ответ обратились к нему по http или https (можно получить номер порта и считать, что если 443 - значит https)
  
  
  
  
  
  
  
  5) Включение в .htaccess команд типа php_admin_value в таком режиме приводит к сообщению 500 - InternalServerError (register_globals и прочие настройки делаются в индивидуальном php.ini).
• У меня при переезде к вам на хостинг на сайте полетели кодировки!

  
  
  
  
  
  
  
  Причин может быть 2:
  
  
  
  
  
  
  
  Первая - для вашего сайта нужно принудительно указывать кодировку html - контента, браузер не может корректно определить кодировку в автоматическом режиме. WWW-домены -> Параметры WWW домена -> Кодировка.
  
  
  
  
  
  
  
  Вторая причина уходит корнями в коренные изменения между mysql 4.0 и 4.1 Начиная с Mysql 4.1 данные могут передаваться в одной кодировке, хранится на диске во второй, сравниваться в третьей, а результат может выдаваться в четвертой. Иногда бывают ситуации, на разборку с которыми уходит не один час. Вероятнее всего при снятии дампа на предыдущем хостинге, Вы либо не выставили все полезные опции (в данном случае указание кодировки дампа), либо до того пользовались старыми версиями mysql 3.23 - mysql4.0. Несколько советов: Самое главное! Если у вас нет опыта в жонглировании кодировками, базу данных лучше создавать изначально с кодировкой cp1251. Если быть точным, то создавать базу желательно в той же кодировке, в которой написаны шаблоны (templates) вашего сайта или форума, и cp1251 подойдут для 99% случаев. Корректировка дампа: Дамп БД является обычным текстовым файлом, с набором SQL команд внутри. Его можно редактировать любым простым текстовым редактором (блокнот, Wordpad встроенный редактор FarManager). После того как вы выясните в какой кодировке записаны данные в дампе нужно в одной из первых строк дампа указать кодировку данных, например так: SET NAMES uft8; кроме того, если в дампе присутствуют подобные строки ENGINE=MyISAM DEFAULT CHARSET=latin1; DEFAULT CHARSET лучше либо удалить, либо указать cp1251 (кодировку в которой создана база.), после этого можете заливать подкорректированный дамп. Определение с какими кодировками имеем дело, если не угадали: Если в крокозяблах на сайте или форуме проглядывается периодичность (часто через одну букву повторяется Г, символ псевдографики, или еще какой то символ) - это признак того что в базу с однобайтовой кодировкой (cp1251 или koi8r ) влит дамп UTF8, если вы получили на сайте вместо кирилицы кучу знаков ?????? - это признак того что база вами создана в кодировке UTF8, где на каждую букву расходуется 2 байта, а вливали в эту базу дамп в однобайтовой кодировке (cp1251 или koi8r), если появились символы псевдографики (всякие рамки и уголки) - в базу cp1251 вливался дамп koi8, если появились символы с всякими тильдами, ударениями и двоеточиями сверху - вероятно где то затесалась кодировка latin1, не особо пригодная для кирилицы. Если при переборе кодировок в браузере после открытия сайта, вы часть текста видите нормально, а часть повреждена, причем в другой кодировке ситуация меняется наоборот - это признак того, что файлы-шаблоны в вашем сайте написаны в кодировке cp1251, а встраиваемые в шаблоны данные выдаются базой в кодировке UTF8. Также в этих разборках с кодировками может помочь маленькая программка shtirlitz, которая легко ищется через любой поисковик. Если ничего не получилось, обращайтесь к support@hvosting.net.ua, постараемся помочь.

  
  
  
  
  
  
  
  
• Залил на ваш сервер сайт, при нажатии на любую кнопку в меню открывается первая страница сайта.
  Как привило, это следствие отключенного режима register_globals (режим отключен из соображений безопасности), если ваш сайт использует простые рукописные php-шаблоны. Если вы четко представляете себе к чему может привести включение этого режима, мы можем его включить для вашего аккаунта. Также вы можете добавить 1 строку в начало вашего основного скрипта extract($_REQUEST); эта строка практически полностью эмулирует режим register_globals=On, но не в масштабах всего сайта, а только для конкретного скрипта.
• Залил на ваш сервер сайт, выдает ошибку 403 forbidden.
  Чаще всего это связано с тем,  что индексный файл назвается не index.html, а Index.html либо index.HTML. UNIX-системы очень чувствительны к подобным мелочам.
• Залил на сервер сайт, он какой то покалеченый, картинок не видно.

  
  
  
  
  
  
  
  Причин может быть достаточно много. Для начала, стоит выяснить, какую именно ошибку получаем. Нужно кликнуть правой кнопкой на какую-либо картинку (точнее месте, где она должна быть), для Opera - копировать адрес рисунка, IE - выбрать пункт "свойства", зажать Ctrl и кликнуть на адресе рисунка в его свойствах. Затем скопировать этот адрес (Ctrl-C), и попробуйте вставить этот адрес в отдельное окно броузера. Если выдало ошибку 403 (доступ запрещен), значит что-то не в порядке с "правами доступа к файлу", посмотрите справку по соответствующему разделу. Но в большинстве случаев сталкиваются с ошибкой 404 (нет такого файла). Причины: а) Ссылка вообще не ведет на http адрес. Некоторые, очень начинающие веб-мастера, встраивают картинки указывая их абсолютный адрес на СВОЕМ жестком диске. т.е. c:\site\img\kartinka1.jpg, а не img/kartinka1.jpg. б) в ссылке стоят обратные слеши (не все броузеры спокойно относятся к ссылкам вида img\kartinka1.jpg - правильно img/kartinka1.jpg) в) ссылка содержит кириллические названия и пробелы - используйте только английские символы, и знак подчеркивания для имен файлов и рисунков. г) в ссылке и настоящем названии картинки (или папки) есть малозаметная для windows-системы разница: img/kartinka1.jpg и IMG/kartinka1.JPG - это разные папки и файлы, unix-системы чувствительны к регистру в названиях файлов. д) может вы просто забыли переписать папку с изображениями, либо она переписалась не полностью.

  
  
  
  
  
  
  
  
• Какая разница как запускать скрипты в кроне - через wget/fetcg/GET или другим способом?

  В случае прямого вызова php -f /home/test/data/www/test.com/maintenance.php,  демон крон запускает процесс php, который открывает файл /home/test/data/www/test.com/maintenance.php и начинает его выполнять. В случае с использованием wget или fetch /usr/bin/fetch -o /dev/null http://test.com/maintenance.php, крон запускает процесс fetch, который стучится в службу DNS,  чтобы узнать на каком ip находится тот сайт, что просят открыть, открывает tcp соединение с удаленным сервером (неважно, что он локальный), формирует и посылает в балансер нагрузки http запрос, он стучится в веб-сервер, веб сервер принимает http запрос, разбирает его на части и принимает решение под чьими правами этот скрипт выполнять, делает еще некоторое количество системных операций, и таки запускает php. Разница в метров 10-20 оперативной памяти и ~0.1 секунд процессорного времени. Когда 100 клиентов запускают скрипты таким не оптимальным образом по крону раз в минуту, за месяц набегает... вполне ощутимо.

• Есть ли у вас на хостинге совместимость с FrontPage и SharePoint?
  Нет. Для этих целей вам стоит поискать windows-хостинг.
  
  
  
  
  
  
  Мы windows-хостинг не предоставляем.