Налашуваня скриптів

• Чи можливе використання 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/<ваш-логiн>/data/www/<ваш_домен>/
  
  
  
  
  
  
  
  
  Cgi-bin: /home/<ваш-логiн>/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 краще або видалити, або вказати 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. би) у посиланнi є зворотні слеші (не всі броузери спокійно відносяться до посилань вигляду 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-хостінг не надаємо.