При замовленні хостингу вам необхідно заповнити наступні поля регістраціонної форми:

• Ваше им'я та назва організації - буде використовуватися для рахунку.
• Ваш контактний e-mail - адреса єлектронної пошти, на яку буде відправлено ключ активації хостингу і через який буде здійснюватися підтримка хостингу. Ця адреса повинна бути рабоча, тому що на неї будуть відправлятися всі інформаційні та технічні повідомлення.
• Бажаний логін - ім'я (маленькі латинські літери, цифри и знак тіре) довжиною до 16 символів, яке буде використовуватися для доступу по FTP. Це також частина адреси вашого майбутнього єккаунта хостингу (наприклад, LOGIN.ho.ua, де LOGIN - це вказанний вами логін). це також и Ім'я можливой бази даних MySQL. Враховуйте, що бажаний логін може бути вже ким-то зайнятий, і вам довідеться його уточнити. Поряд з логіном вам також пропонується на вибір 2 варианти домених імен для сайту (*.ho.ua и *.houa.org).
• Ваши існуючі домени - Якщо у вас є домени (зареєстрованні у будь-якого реєстратору домених імен), які підтримуються на NS-серверах і які ви бажаєте налаштувати для майбутнього хостингу - вкажить їх в даному полі форми.
• Країна - це країна, де ви мешкаєте.

Після заповнения реєстраційної форми натиснить кнопку Замовити. Якщо форма заповнена вірно та вказанний логін в нашії базі відсутний, ви побачите повідомлення про те, що на ваш e-mail відправлено листа с ключем (посилання) активації хостингу. Вам необхідно уважно прочитати цей лист, перш ніж переходити по вказанному в ньому посиланню.

Якщо ж при реєстрації виникли деякі помилки (неточність заповнення форми, бажаний логін зайнятий тощо) - вам буде повідомлено про це та запропоновано їх виправити.

Після успішного заповнення реєстраційнної форми вам буде відправлено лист з ключем активації. Даний лист сам по собі перевіряє доступність вашії e-mail адреси із мережі нашого провайдеру. Якщо ви не отримали даний лист, то по перед всього, перевірьте теку СПАМ та налаштування поштової скриньки (всеможливі SPAM-фильтри и т.п.) Далее, Вам краще звернутися до свого провайдера за допомогою. Також ви можете написати нам листа з нашого сайту (розділ Контакти).

У листі с ключом активації буде вислано код вашої заявки, який необхідно буде відправити SMS-повідомленям на наш технічний номер. Вартість SMS - звичайна, залежить тільки від вашого оператору мобильного свя'зку. У випадку успішной доставки вашого SMS-повідомлення Вам потрібно буде перейти за посиланням активації.

Після успішної активації, буде проїзведено початкове налаштування хостингу - створений обліковий запис на сервері хостингу, внесуться зміни в налаштування веб-серверу та інші початкові налаштування, а ви отримаєте на e-mail повідомлення про успешну активацію та початкові відомості для роботи з хостингом. Однак враховуйте, що повністю працездатним ваш хостинг стане продовж 1 (однієї, one) години після активації. Продовж цього часу ви можете бачити за адресой вашого сайту помилку 404, однак це цілком нормально. Не поспішайте і не пишіть до служби подтримки про непрацездатность вашого сайту протягом першого часа після активації.

При активації можуть виникнути деякі непередбаченні сітуації (наприклад, з моменту подачі вами заявки ваш логін хто-то вже зайняв, вказанний вами логін вже вказан кимось в налаштуваннях іншого сайту и т.п.). При цьому ви отримаєте відповіднее повідомлення, яке поле форми потрібно виправити. При серьозних проблемах звертайтесь до служби підтримки, обов'язково вказавши ключ (посилання) активації хостингу.

Для отримання доступу до хостингу при втраті контактного e-mail у випадку, коли ви маєте доступ до панелі управління хостингом, вам достатньо зайти в панель и відредактувати контактні дані (кнопка "Контакти"). Після додавання новой e-mail адреси на неї прийде лист з підтверженням додавання цієї адреси.

Якщо же ви не пом'ятаєте свій пароль, то вам потрібно звернутися в службу підтримки, вказавши свой логін, причину втрати e-mail и данні, які можуть вас авторизувати як власника вказанного хостингу (дату та час подачі заявки хостингу, коли и яким чином в останій раз робилиcь зміни сайту и т.п.)

Безкоштовний хостинг може бути закритий з кількох причин. Основні причини, це:

• порушення Правил надання хостингу;
• несвоєчасне продовження хостингу (нагадування про продовження приходить на контактний е-мейл раз на місяць;
• не слідуванння або просто ігнорування листів від служби підтримки ho.ua;
• у випадку виявлення на сайті вірусов та кодів їх завантажуючих (сайт тимчасово заблокований);
• відсутність змін на сайті зі дня створения протягом 30 днів;
• перевищення сайтом лімітів системних ресурсів (навантаження на сервер, перевищення дискової квоти), особливо необґрунтоване відвідуваністю сайту.

В будь-якому випадку, перед закриттям хостингу користувачу буде відправлено повідомлення по e-mail. Тільки при самих злосних порушеннях ми можемо закрити хостинг негайно. У решті випадків існує ненульова імовірність відміни закриття хостингу після усунення зауважень.

Платний хостинг может бути закритий з наступних причин:

• порушення Правил надання хостингу;
• порушення Публічного договору;
• не слідування або просто ігнорування листів від служб підтримки та біллингу ho.ua.

Во всіх випадках залишок коштів на рахунку клієнта може бути повернено, що регламентується Публічним договором. Всі спірні питання з закриття також регламентуються даним документом.

Якщо с моменту закриття сайту пройшло більш 1-2 місяців, то всі його данні и налаштування вже видалені. Вам для відновленя потрібно знов реєструвати эккаунт та заливати сайт знову.

Якщо сайт був закритий через те, что ві не встигли вчасно продовжити хостинг, то вам достатньо зайти в панель управління хостингом и самостійно його відкрити. Через 1-2 години ваш сайт буде відновлено.

Якщо ж сайт закрит з інших причин, необхідно звертатися в службу підтримки ho.ua. Однак, якщо раніш перед закриттям ви отримали чітке НІ, то це звернення навряд чи умісно. Ми, зазвичай, не змінюємо свого рішення.

Термін користування безкоштовним хостингом обмежений 3 місяцями. Все безкоштовні хостинги заводяться не назавжди, а до якоїсь дати. До вказанной дати Через 3 місяці вам необхідно підтвердити свои наміри користуватись хостингом, у панелі управління хостингом натиснувши кнопку "продовження". При цьому хостинг буде продовжений

Для спрощення відстеження моменту чергового продовження хостингу ми висилаемо за 30, 10 и 1 добу до моменту закрития листа с попередженням про закриття хостингу и прямим посиланням для його продовження (або оплати).

Якщо безкоштовний хостинг був закритий з причини невчасного продовження, та з моменту закриття пройшло меньше 1 місяця, то вам достатньо зайти в панель управління хостингом и натиснути кнопку "продовження". сплатити хостинг.

Якщо ж з моменту закриття хостингу пройшло більше 3х місяців, то всі дані экаунту можуть бути вже видалени, і вам потрібно зновУ реєструвати хостинг. Довго бэкапні файли видалених сайтів ми не зберегаемо.

Після закриття хостингу його файли зберегаються на сервері 2-3 місяця.

Нияк. Якщо вам потрібно видалити хостинг, то ви можете його:

• не подовжувати - хостинг закриєтся и через 1-2 місяці автоматично видалиться;
• написати листа в службу підтримки - ми закроемо хостинг, та він через 1 місяць автоматично видалиться.

Не потрібно писати листи с проханням/вимогою негайно видалити хостинг, оскільки ми це не робимо. Інакше би підміна e-mail адреси в листі до служби підтримки мігла би спричинити видалення сайту без відома власника. Якщо вим потрібно видалити його для перереєстрації (невірно вказані дані) - не вигадуйте нічого та просто зверниться до служби підтримки ho.ua и опишить свою проблему.

Основною особливістю цього рекламного посилання є саме те, що воно текстове. Графічну кнопку ставити не можна (ії нема зовсім :)). Текст посилання може змінюватися та трошки переробляться, залишаючи основні ключові слова: хостинг, в Україні та безкоштовно. Посилання можна розташувати в будь-який видимої частині вашого сайту и оформити ії як рекламний блок, не показуючи Вашим відвідувачам, що ваш сайт розташован на безкоштовному хостингу. Сайтів на платному хостингу це правило не стосується, однак нам було б приємно бачити ії на вашому сайті.

Ні, ми надаємо підтримку наших користувачів тільки за допомогою електронної пошти. Якщо ви грамотно задасте нам свое питання, та на нього (чи на подібне) нема відповіді в розділу FAQ, то ми обов'язково на нього відповімо.

Ні, це безпосередньо заборонено Правилами. Будь-які массові розсилки, навіть ті, на які адресати самостійно підписалися, будуть автоматично зупиняться у нашій системі, а хостинг буде закрито за порушення даного пункту Правил. Дозволяється лише производити відправлення одиночних листів (повідомленнь користувачам і т.і.), інтенсивність яких не буде перевищувати 2-3 листи у хвилину.

Одразу відмітимо, що не схвалюється розташування на сайті незахищенних форм відправки листів або SMS відвідувачами (за допомогою коду на зображенні або інакше) - в даному випадку є немала імовірность того, що хтось за ії допомогою зробить цю саму масову (SPAM) розсилку, в результаті якої винним і постраждалим залишитеся ви (як власник сайту).

Статистику по навантаженню для свого сайту можна подивитися в Панелі управління (кнопка "Статистика"). Данні про навантаження збираються за багатьома параметрами. Детально ви можете дізнатися про дозволене навантаження на цій сторинці.

Ми не надаємо статистику сайту, оскільки знов винаходити колесо ми не хочемо. До нас уже винайдено багато систем статистики відвідуваності сайту. Для своих користувачів ми рекомендуем відмінний, а главное безкоштовний сервис статистики сайту.

Ні, ми надаємо тільки послугу хостингу. Поштові скриньки ви можете завести у будь-якого провайдера безкоштовної пошти.

Для домену, який надаємо ми (*.ho.ua и т.п.) є наступнее правило: всі листи, які идут на адресу LOGIN-admin@sN.ho.ua перенаправляються на ваш контактний e-mail. LOGIN - це ваш логін, sN - Ім'я серверу хостингу, на якому розташован ваш сайт (s1, s2, s3 и т.п.).

Стосовно налаштування переадресації пошти для домену, який ви зареєстрували окремо, вам потрібно звернуться безпосередньо до вашого реєстратора.

Для зміни логіну (та відповідно доменого імені *.ho.ua та імені бази даних MySQL) вам потрібно написати запит в службу підтримки, вказавши ваш поточний і бажаємий новий логін. Якщо цей логін вільний, то через 3 години після нашої відповіді ваш хостинг отримає нове ім'я.

Адреса для тестування - 91.228.146.10.

При вході у панель управління хостингом на сторинці авторизації є кнопка "Забули пароль?" - скористайтеся нею для отримання на ваш контактний e-mail листа з ключем (посиланням) для зміни паролю. Після переходу по вказанному в листі посиланню вам буде запропоновано ввести новий пароль до хостингу (FTP).

Ми надаємо сайтам користувачів SSL-сертифікат за окремим запитом в службу підтримки хостингу.

Ні в якому разі не відправляйте нам поштой ніяки архіви та другу інформацію великого об'ему - це просто некультурно, а головне - ми вкладення не переглядаємо.

У налаштуванні (разархівуванні) сайту ми допомогти не можемо. Якщо у вас нема елементарних навичок по створенню і редагуванню сайтів, то вам прийдется цьому вчитися. Рекомендуємо причитати статті.

По окремій домовленності (завантаження проблемного дампа БД і т.і.) вам слід записати по FTP великий файл в свою домашню директорію, а нам прислати тільки ім'я цього файла.

Аналогічно ми чинимо при необхідности надати вам архіви змісту вашого сайту, архіва БД и т.п. - ми просто разміщуємо потрібний файл у вашій домашней директорії, вам вказуемо тільки його ім'я. ви же Після того, як скористаєтесь цим файлом, ви видаляете його самостійно (Якщо він вам більше не потрібен).

Можете, однак це приведе лише до негативного відношению до вам. Це просто некультурно. Виключення відноситься тільки до тіх користувачів, у яких зламана клавіатура (заліпша клавіша Shift і т.н.) Однак, для таких користувачів одразу відмітимо, що у нас реєстр літер має велике значення.

Ні, у нас не windows-Хостинг, тому ASP (які працюють у середовищі windows) скрипти у нас працювати не будуть.

Сплатити використання нашого хостингу можна в будь-якому банку України, крім тех банків, які затримують платежи, а також сплатити он-лайн за допомогою банковської картки. Наши ціни та реквизити вказани на цій сторінці.

Ваш платіж ми отримааем як мінімум через 1 робочий день. Тобто переводу на платний вид хостингу потрібно очікувати на наступний робочий день. Он-лайн платежі можуть дійти раніше.

В першу чергу перевірьте в панелі управління хостингом, чи збільшена дискова квота для вашого сайту відповідно із сплаченним тарифним планом.

Якщо квота збільшена, то Вас переведено на платний хостинг.

Якщо до вота не збільшена - це означає, що виникли проблеми з ідентификаціей вашого платіжа. Тобто ми не можемо з 100% впевненістю віднести ваш платіж до одного із існуючих логінов. Частіше всього так трапляється, якщо у призначенні платежу не вказано логін або, на приклад, вказали його кирилицею. В цьому випадку пишить на e-mail ваш логін, а також суму и дату платежу - тобто всі ті дані, які допомо;ут ідентифікувати ваш платіж.

Платний хостинг может бути закритий в основному з наступних причин:

• порушення Правил надання хостингу;
• порушення Публічного договору;
• не слідування або просто ігнорування листів від служби підтримки та біллінгу ho.ua.

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

Якщо ви хочете перейти з одного тарифу на інший, напишить на e-mail ваш логін и дату, з якої ви хочете змінити тариф - вам зроблять перерахунок и ви отримаєте відповідь, скількі потрібно доплатити. Пом'ятайте, що при зміні тарифу з Великого на Звичайний зменьшується дискова квота, а в випадку тарифу Статика перестають працювати cgi-додатки. Тобто до зменьшення дискової квоти потрібно підготуватися заздалегідь та "стиснути" об'єм сайту самостійно.

Важливо: при перевишенні сайту дискової квоти деякі файли можуть бути втрачені та працездатність сайту порушена. При перевишенні дискової квоти користувачі платних, так і безкоштовних хостингів, регулярно отримують повідомления про це. При відсутністі реакції з боку користувача ми можемо вжити відповідних заходів.

Існує таріфний план Великий, ціни и параметри вказани тут. Також ви можете сплатити за декілька аккаунтів та держати на них різні частини сайту (на приклад, бази та/або зображення).

Ваш сайт буде закрито, файли будут зберегатися на сервері протягом місяця, а потім будут видалені.

Якщо ви хочете залишити свій сайт на платному хостингу, напишить на e-mail ваш логін та дату, коли ви зможете оплатити.

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

Якщо ви хочете налаштувати хостинг ho.ua для роботи з вашим доменом, то Вам необхідно потурбуватися про його підтримку на NS-серверах реєстратору. Ми не надаємо NS-серверів для доменов користувачів. Або просто зареєструвати цей домен у будь-якого реєстратора домених імен. Після того, як домен буде підтримуватися на чиїсь NS-серверах, вам потрібно встановити для нього IN A запис відповідно з сервером хостингу, на якому розташован ваш сайт:

• 91.228.146.11 - якщо Ваш сайт знаходиться на сервері хостингу s1.ho.ua;
• 91.228.146.12 - якщо Ваш сайт знаходиться на сервері хостингу s2.ho.ua;

За допомогою в налаштуванні IN A запису домену звертайтеся до свого реєстратора - ми в цьому вам нічим допомогти не можем, т.як не маємо доступу до вашему домену.

Після налаштування домену у реєстратора, вам потрібно додати домен (якщо ви не вказали домен при замовленні хостингу) до списку доменов в панелі управління хостингом (кнопка "домени"). Максимум через 3 години домен з нашої сторони буде налаштований. Відмітимо, що зміни IN A записів займають значний час - звичайно біля 1 доби.

Стартова (індекснa) сторинка - це сторинка, яка віддается відвідувачам при наборі адреси в адресному рядку браузера. У нас цей файл повинен називатися index.htm, index.html, index.php і т.і.

Якщо у вас друге ім'я індексной сторинки (наприклад, default.html), ви можете звернутися до директиві DirectoryIndex веб-серверу Apache. Для цього вам достатньо в файлі налаштувань ~/htdocs/.htaccess прописати (або відредактувати існуючую) строку:

DirectoryIndex default.html

За підробицями використання звертайтеся до офіційної документації веб-серверу Apache.

Перш за все вам потрібно перевірити, що після активації хостингу пройшло більш 1-й години. Протягом цього часу хостинг може бути не повністю налаштован, тому і відображается данна сторинка помилки. Крім того, подібна сітуація може траплятися у випадку змін вами списку доменів в панелі управління хостингом - і знов таки - потрібно просто чекати.

Поперше, ви повинні впевнитися, що файли сайту завантажени у теку htdocs вашого домашнього каталогу (а не безпосередньо в нього). Пом'ятайте - тека htdocs - це корінь вашого сайту. Якщо ви звернете увагу, то в цей директорії після створення хостингу знаходяться тестові файли, один із яких і показується при заході на ваш сайт.

Крім того, вам потрібно знати, що при запуску сайту викликається так званий індексний файл, ім'я якого має одне із наступних значень: index.htm, index.html, index.php та т.і. Більш продвинуті користувачи можуть звернутися до документації веб-серверу Apache та явно вказати ім'я індексного файлу у директиві DirectoryIndex в файлі налаштувань ~/htdocs/.htaccess (попередньо розкоментувати цю директиву).

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

Миттево. На сервері хостингу ніяких кешувань не призводиться. Якщо ви бачите стару сторинку, то вона показується або із кеша вашого браузера або із кеша проксі-серверу (якщо останній використовується при підключенні до Інтернет). В обох випадках допомагає один гарний метод - оновлення відображаемій браузером сторинці за допомогою клавіш Ctrl+F5 (всі популярні браузери підтримують це поєднання клавіш для безумовного поновлення сторинки).

Це скоріш всього із-за того, що у вас не співпадає реєстр літер імен файлів на сервері та у посиланнях на них в HTML-документах. У нас використовується ОС UNIX (FreeBSD), яка критична до реєстру літер імен файлів. На приклад, файли image.jpg и Image.JPG - це разні файли.

Деякі FTP-кліенти навіть мають спеціальну опцію при запису на FTP-сервері автоматичного приведення імен файлів до нижнего реєстру. Ми наполегливо рекомендуємо не використовувати в іменах файлів літери великого реєстра (для запобігання подальшої плутанини).

Також слід уникати в іменах файлів літер, відмінних від латинских (наприклад, літери кириллиці). Взагалі, допустимий и вважається "гарним тоном" набір символів для імен файлів веб-серверу такий:

• символи латиніці (a-z);
• цифри (0-9);
• деякі символи: -_,. (тире, символ пікреслення, кома і крапка).

За замовчуванням, SSI директиви виконуються в файлах з розширенням .shtml. Якщо Вам потрібна підтримка SSI в інших файлах (наприклад, з розширенням .html), то вам потрібно в файлі налаштувань ~/htdocs/.htaccess прописати (або відредактувати існуюуючий) рядок:

AddHandler server-parsed .html

До речі, в прикладі файлу ~/htdocs/.htaccess вже є ця строка, її необхідно тільки розкомментувати (вбрати символ # з початку рядку).

Так, базово ми надаємо модуль mod_rewrite веб-серверу Apache. Для увімкнення підтримки цього модуля вам достатньо прописати в файлі налаштувань ~/htdocs/.htaccess веб-серверу наступну директиву:

RewriteEngine on

Інформацію про версії ПЗ на конкретному сервері хостингу ви можете дізнатися за наступним посиланнями:

• Сервер s1.ho.ua
• Сервер s2.ho.ua
• Сервер s3.ho.ua

Інформацію по модулях perl на конкретному сервері хостингу ho.ua ви можете дізнатися за наступними посиланнями:

• Сервер s1.ho.ua
• Сервер s2.ho.ua
• Сервер s3.ho.ua

Інформацію про модулі php на конкретному сервері хостингу ho.ua ви можете дізнатися за наступними посиланнями:

• Сервер s1.ho.ua
• Сервер s2.ho.ua
• Сервер s3.ho.ua

Справа у тому, що в нас стоїть обмеження - не більш 20 тимчасових з'єднань з однієї IP адреси. При наявності вже 20 активних з'єднань ви й не зможете отримать доступ до свого сайту. Дана проблема характерна для великих внутрішних мереж, які можно бачити у мережі Інтернет як один IP (т.н. NAT). Вирішити дану проблему можна тільки звернувшись до адміністратора вашій мережі. Також можливи випадки, коли з'єднания с вашого IP встановлени, але при цьому не використовуються (наприклад, FTP-з'єднания або proxy-сервер).

Вихідні з'єднання на хостингу за замовчуванням закрити крім потрібних для встановлення та оновлення популярних CMS. Та в цілях безпеки, і для відсутністі бажання деяких юних "хакерів" використовувати хостинг не за призначенням. Хоч RSS-єкспорт і є цілком законною і нешкідливою дією, але даная політика не обговорюється і ми не можемо (і не будемо) відкривати вихідні з'єднания для окремих хостингів.

Якщо логін користувача - LOGIN, то полний путь домашній директорії виглядає наступним образом:

/virt/homes/LOGIN/

Поперше опишемо наступні визначення:

• Виртуальний хост (virtual host, виртуалхост) - це ко\інфигурація веб-серверу, якая відповідає за окремий сайт. можна сказати, що 1 виртуальний хост - це 1 окремий сайт. Деякі хостинг-провайдери предоставляют можливость на одном аккаунте заводить декілька окремих сайтів (віртуальних хостов). ми - тільки один.
• Аліас (alias, синонім) - це "друге" ім'я сайту. Собственно "синонім" підходить для цього визначення найкраще. Наведемо приклад: www.some.site.com и some.site.com - 2 різних домени.

На безкоштовному хостингу ми надаємо на аккаунт тільки один віртуальний хост и до 10 аліасов сайту. Це значить, що на безкоштовному хостингу ви не зможете створить 2 та більш окремих сайтів.
На платному хостингу можна створювати більш одного сайту на эккаунті, кількість залежить від тарифу.

Стосовно піддоменів, то ви без проблем можете створить їх в панелі управління хостингом (наприклад, en.LOGIN.ho.ua), однак у випадку безкоштовного хостингу домен буде посилатися на ті ж файли, LOGIN.ho.ua. Звичайно, можна програмним шляхом аналізувати, на який що и домен домен прийшов HTTP-запит, и віддавати зміст того або іншого сайту. Однак цей способ достатньо складний і найголовніше - більш вимогливий до ресурсів.

Інформацию о модулях python на конкретном сервері хостингу ho.ua ви можете дізнатися по наступним посиланням:

• Сервер s1.ho.ua
• Сервер s2.ho.ua
• Сервер s3.ho.ua

Насамперед - для налагодження будь-яких помилок веб-серверу, бажано увімкнути журнал помилок (лог помилок) в Панелі управління хостингом (кнопка "Журнальні файли"). Сам журнал (файл error.log) при цьому з'явиться в директорії logs вашого домашнього каталогу, а повідомления про помилки почнуть писатися протягом 3-х годин.

По аналізу повідомлень про помилки в журналі помилок можна робити висновки про причини, що їх викликали. Взагалі, можна виділити 2 категорії причин помилок:

• неверні налаштування режимов доступу директорій, помилки в файлах налаштувань .htaccess (невірні директиви або директиви с помилками), невірні режими доступу самих скриптов;
• безпосередньо помилки виконання, які виникли в результаті виконання самих скріптів (невірний формат файлу, невірний шлях до інтерпретатору.

Самим ідеальним варіантом буде випадок, коли ви зможете зрозуміти, після якої вашої дії сталася даная помилка 500. Тогда вам буде легче її локалізувати і усунути. Зараз же дамо деякі найбільш типиові випадки та поради, куди потрібно "дивитися":

• помилка з'явилась після розархівування деякого пакету (набіру) файлів, який раніш працював на другому сервері (у другого хостинг-провайдера, локальному тестовому веб-сервері і т.п.) - в цьому випадку порадимо звернути увагу на внесенний даним пакетом файл(и) .htaccess - він може містити директиви веб-серверу, які не підтримуваются версіей або конфігураціей нашого веб-серверу. Для перевірки достатньо переіменувати ваш файл .htaccess (наприклад, в .htaccess-my) и перевірить роботу сайту. Якщо помилка 500 устранится (пусть и сайт буде працювати и не так, як повинен - все таки ви убрали частина налаштувань), то залишиться повернути файл .htaccess назад і подальшу діагностику проводити за допомогою вказанного раніше журнала помилок.
• помилка з'явилась після завантаженя cgi-скриптів - в цьому випадку перевірьте формат файлу скрипту на сервері або невірний шлях до інтерпретатору.
• помилка з'явилась після змін cgi-скрипту - в цьому випадку причиною помилки може бути помилка виконання самого скрипту - див. журнал помилок.
• помилка 500 з'являється іноді - тут крім аналіза журналу помилок нихто допомогти не може.

Це повідомлення з'являється в 2-х випадках:
- невірний шлях до інтерпретатору (звичайно вказуеться в самоу першому рядку скрипта після символів #!, наприклад #!/usr/bin/perl);
- невірний формат файлу відмінний від ASCII (переводи рядків складаються не із одного символа с кодом 10 (\n), а із 2-х: 10 13 (\r\n). Двосимвольній перевод рядків, характерний для DOS та Windows-кодіровок, але ніяк не застосовується для UNIX-сценаріїв.

По цьому цілком рабочі скрипти на Windows-системах будуть виконуватися нормально, а у нас - з помилкой серверу 500. Для перетворення файлу скрипту в ACSII-вид, можна використовувати специальні программи-перекодіровщики текстів, стандартний Windows'овский блокнот (notepad) - має ACSII-опцію при збереженні, а деякі FTP-кліенти (наприклад, рекомендованний нами FAR) - автоматично можуть переконвертувати текстові файли в ACSII-вид при завантаженні файлів на сервер.

Крім цього, надаваємий нами файл-менеджер також автоматично виконає під час закачування на сервер (при необхідности) пертворення скриптів в ACSII-вид.

Дуже розсповсюджена помилка користувачів пов'язана з втручанням в іерархію файлів в директорії cgi-bin. В цій теці не потрібно располагати ніякі php-файли - в неї розташован тільки інтерпретатор php та файл його налаштувань (файли php и php.ini відповідно). Крім цих файлів у директорії cgi-bin можна розташовувати cgi-скрипти.

Самі же php-файли потрібно розташовувати як і звичайні html-документи у директорії htdocs. Отже, якщо дана помилка з'явилась, то вам необхідно відновити початковий стан php-інтерпретатору, а саме - 2 файлу (php и php.ini). Далі наполегливо рекомендуем осторожно відносится до цим двум файлам. При необхідности внесення змін в налаштування php-інтерпретатору - можете (змінювати файл php.ini), однак робийте це грамотно та знаючи, що робите і що хочете добиться. Зламанні php-інтерпретатори обміну та повірненню не підлягають. Ще зауваження - не перезаписувайте файл налаштувань php.ini "своим" - це чревато поломками начиная від платформо-залежних налаштувань и заканчивая налаштуваннями, які залежать від версии інтерпретатору php.

Справа в тому, що HTTP-аутентифікация на php працює тільки у випадку, якщо php працює як модуль веб-серверу Apache (про це чітко написано у документації). У нас інтерпретатор php установлений як cgi-додаток, а надати php як модуль Apache ми не можемо. Однак ви сами можете налаштувати HTTP-аутентификацію для окремих файлів або всього каталога із файл-менеждера.

Це сама поширена помилка. Справа в тому, що з деякіх часів разробники php вирішили відключити за замовчуванням (в цілях повишення безпеки) глобальну реєстрацию змінних, які були передани скрипту різними методами (GET, POST и т.д.). Якщо ви писали свої скрипти "в старому" стилі, покладаючись на автоматичну реєстрацію змінних, і ви не хочете їх переписувати, надайте змінной register_globals значенняOn (в конфігураціоному файлі php.ini, який знаходиться в директорії ~/cgi-bin вашого домашнього каталога).

Також деякі скрипти використовують массиви змінних $HTTP_*_VARS[], автоматичне створення яких також за замовчуванням відключено. Увімкнить створення цих масивов можна за допомогою змінной register_long_arrays. Та не забувайте, що в конфігураціоному файлі php.ini рядки, на початку яких стоїть точка з запятой ";", є коментаріями! І змінні значения закоментованих зміних ни до чого не приведе!

Ці шляхи на всех серверах хостингу ho.ua наступние:

• perl - /usr/bin/perl
• python - /usr/local/bin/python
• sendmail - /usr/sbin/sendmail

Ні. І встанавлювати його ми не плануємо, навіть для окремих хостингов. Серед причин - неможливість підтримки скриптів (без збереження початкових кодів залишаються одні бинарні файли), можливі проблеми із-за несумісності версій php, Zend Optimizer'a та навіть ОС (такі факти відомі).

Встановлення змінних інтерпретатору php в файлі .htaccess за допомогою php_value ... можлива тільки в тому випадку, якщо php працюе як модуль веб-серверу Apache. В нас php працюе як cgi-додаток та його налаштування можна виконати в файлі ~/cgi-bin/php.ini.

Файл налаштувань php.ini інтерпретатора php може знаходиться в директорії ~/cgi-bin. Однак, починаючи з версії php 5.3, існує більш гнучка можливість змін налаштування php - через так званий файл .user.ini, який слід розташовувати в той же директорії, в якой розташовани самі php-скрипти. При цьому, по аналогії с файлами .htaccess веб-серверу Apache, налаштування php можуть бути перевизначенні во вкладених каталогах через разміщений в них файл .user.ini. Т.е. для кожної директорії сайту можна встановити свои певні налаштування php. Якщо ж файлу .user.ini в директорії нема, то php буде використовувати налаштування із глобального файлу налаштувань. А внесенні в файл .user.ini налаштування лишь перевизначають налаштування за замовчуванням із глобального файлу налаштувань php. Відмітимо, що в принципі, опції в глобальному файлі налаштувань php мають рекомендовані разробниками php значення и повинни підійти для більшості коректно-написаних php-скриптів.

Сам файл налаштувань має достатньо зрозумілий сінтаксис, а комментарії и приклади файлу ви можете знайти в Інтернеті, ми наведем лишь деякі поради и визначення початківцям:

• коментарії в файлі налаштуваннь починаются з символу ; (крапка с комой) - все що Після цього символа просто ігноруется;
• на початку файлу налаштуваннь як комментарії йдуть повідомления про зміни у файлі у нових версиях, с прикладами и новими значеннями змінних. При цьому це тільки комментарйї - значення самих змінних потрібно змінювати ниже по файлу налаштувань. Так що не зупиняйтеся на першой знайденой потрібной змінній - перевірьте, щоб у файлі налаштувань ця змінна не визначалась нижче. Кінцеве значеня змінной при ії перевизначенні встановлюється самим останним знайденним по тексту файлу значенням;
• не чіпайте вимкнення модулей (extensions) php в файлі php.ini - це ни до чого хорошого не приведе, оскільки все встановленні модули підключаються у глобальному конфіге. Якщо вам потрібен якись із невстановленних модулей - напишить в службу підтримки, описавши необхідность даного модуля;
• все зміни в файлі php.ini вступають в силу миттево.

На хостингу вихідні з'єднання закрити за замовчуванням, крім потрібних для встановлення та оновлення популярних CMS. cURL працює тільки с дозволеними адресами.

Ми наведемо лише рекомендовані режими доступу в літерному (rwx) і восьмерічному форматах:

• директорії - rwxr-x-r-x (755)
• звичайні html-документи, php-файли, картинки и інші файли - rw-r--r-- (644)
• виконувані cgi-скрипти - rwxr-x-r-x (755)

Більш детально про режими доступу ви можете дізнатися із офіційних джерел UNIX-систем та в статтях, присвячених UNIX. Одне зауваження - не захоплюйтеся занадто широким режимом доступу rwxrwxrwx (777) або вузько-параноїдальним rw------- (600) - перше є відображенням високої неосвіченісті і поганим, а друге - на нашему сервері даремним, оскільки никто крім вас самих не зможе отримати доступ до вашій домашней директорії (и ії змісту).

Единим виключенням може бути випадок конфігураціонних файлів сайту, в яких можуть зберегатися паролі та інші "нікому не потрібні" дані. Однак в цьому випадку правильним буде захистити данні файли за допомогою директив веб-серверу (за допомогою файла .htaccess) або взагалі "винести" данні файли в корень вашій домашній директорії (т.е. не зберегати їх в директорії htdocs). З корню домашній директорії скрипти и php-сценарії зможуть без проблем отримати доступ до даних в цих файлах налаштувань, а вот сторонні через веб-сервер отримати доступ не зможуть ні при яких режимах доступу самого файлу.

Наші рекомендації такі:

• переконайтеся, що у скриптів встановлени правильні режими доступу;
• переконайтеся, що скрипти мають правильний формат рядків;
• нарешті подивиться у журналі помилок.

У нас є наступні типи журнальних файлів:

• common - стандартне логування запитів, включающее в себя IP адресу кліента, час, рядок запиту, відповіді та розмір відповіді (формат %h %l %u %t "%r" %>s %b);
• combined - логування запитів, рівне common, але з додаванням ще адреси сторинки, відкуди прийшов відвідувач і типу браузера відвідувача (формат %h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i");
• referer - формат %{Referer}i -> %U;
• agent - формат %{User-agent}i
• traffic - лог трафіку (формат %h %l %u %t "%r" %>s %O %I "%{Referer}i" "%{User-Agent}i");
• common-wide - "широкий" (формат %h %l %u %a %U %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i");
• full - повний (формат %a | %h | %t | %{Host}i | %U | %>s | %b | %{Referer}i | %{User-Agent}i | %T);
• errors - журнальний файл помилок - в нього записуваються всі повідомления про помилки;
• rewrite - журнальний файл модуля mod_rewrite;
• scripts - журнальний файл помилок CGI скриптов (для логування помилок рекомендуемо використовувати журнальний файл типу errors.

Приведенні в опису журнальних файлів змінні (зі знаком % на початку) замінюються на наступні реальні значення:

• %h - IP адреса кліенту (або адреса проксі-серверу);
• %l - Ім'я користувача (ідентификації клиента по RFC 1413);
• %u - Ім'я користувачя в HTTP-аутентификації;
• %t - час надходження запиту;
• %r - рядок запиту клиенту, наприклад "GET /index.html HTTP/1.1". Зазвичай береться в лапки
• %s - відповіді серверу клиенту (200, 403, 404 і т.і.);
• %b - размір в байтах відповіді кліенту;
• %{Referer} - адреса сторинки, відкуди прийшов відвідувач;
• %{User-agent} - тип браузера відвідувач. Цей та попередній параметр теж зазвичай вказують в лапках;
• %U - адреса запиту без параметрів після знаку питання;
• %O - розмір байту, відправленних кліенту (включая розмір всіх заголовків);
• %I - розмір байту, принятих від кліента (включая розмір всіх заголовків).

більш детально про журнальні файли ви можете дізнатися із документації до веб-серверу Apache.

Керування журнальними файлами (створення, очищення та видалення) проводиться із панели управління хостингом (кнопка "Журнальні файли"). В панелі ви можете як очістити журнальні файли, так и змінити їх ведення - для зменьшення занимаемого дискового простіру можна зменьшити їх кількість, вибрати компресію старих журнальних файлів, а також зменьшити параметр архівации (наприклад, з щотижневої на щодобову).

В жодному випадку не рекомендуемо видалять журнальні файли (крім ротованих (архівних) с іменами, в кінці яких є кількістьвой індекс) через FTP-кліент або файл-менеджер. Це може негативно відбитися на працездатности вашого сайту.

Для редагування змісту сайту ми надаємо FTP-доступ до серверу хостингу. Параметри підключения по FTP висилаються після активації хостингу - це логін, пароль і сервер хостингу (наприклад, s1.ho.ua).

Користувачі, які незнайомі з роботою по FTP, можуть скористатися нашім файловим менеджером, який дозволяє редактувати сайт через веб-інтерфейс. Потрапити в нього можна через панель управління хостингом (кнопка "Управління файлами").

На сервері вам надається так звана домашня директорія, ім'я якой в опису можна зустріти як ~/. В цей директорії одразу знаходиться 2 директорії:

• cgi-bin - директорія для cgi-скриптов; в ней також розташований php-інтерпретатор;
• htdocs - директорія, в яку необхідно записувати файли сайту - саме ця директорія називается коренем сайту.

Крім цих директорій может ще бути директорія logs - це директорія, в якую веб-сервер записує журнальні файли своєї роботи (якщо віни вами увімкнені в панелі управління хостингом). Також в вашій домашній директорії ви можете разташувати будь-які файли та директорії, однак вони через HTTP не будуть доступни. Одне зауваження - ми наполегливо не рекомендуемо видаляти директорії cgi-bin та htdocs - це не кращим чином впливає на роботу вашого сайту.

Для підключення по FTP потрібно використовувати наступні параметри:

• логін (login) - виданий вам логін (був вказаний при реєстрації).
• Пароль (password) - виданий вам пароль до хостингу (ви його можете завжди змінити в панелі управління хостингом).
• FTP хост (FTP host) - ім'я серверу хостингу, на якому розташован ваш сайт (наприклад, frt://s1.ho.ua). Ім'я серверу ви завжди можете дізнатися в панелі управління хостингом. Крім імені серверу можна також вказувати безпосередньо адресу вашого сайту (наприклад, ftp://LOGIN.ho.ua, де LOGIN - це ваш логін), однак після зміни логіна або адреси сайту цей спосіб працювати не буде.
• Порт (port) - 21 (стандартне значення).
• Режим FTP (FTP mode) - можна як активний, так и пасивний. Однак пом'ятайе, що при роботі через файрвол (брандмауэр), NAT (із локальної мережі) та т.і. потрібно використовувати пасивний режим FTP. До речі, при прямому підключенні до мережі Інтернет він також буде працювати. Так що ми рекомендуемо використовувати пассивний режим FTP як більш універсальний.

Крім вказанних опцій кожен FTP-кліент може мати й інші специфічні опції (ACSII-режим и т.п.) - зверніться до документації вашого FTP-кліента за разъясненням цих опцій.

І останне, не в якості реклами, можем порадити використовувати такі FTP-кліенти як FAR, Total Commander. Крім того, практично будь-який браузер может виступати в ролі FTP-кліента. Для цього достатньо в адресному рядку браузера ввести адресу типу:

ftp://LOGIN@sN.ho.ua

де LOGIN - ваш логін, а sN.ho.ua (s1.ho.ua, s2.ho.ua и т.п.) - Ім'я серверу хостингу, на якому розташован ваш сайт. При вході в браузер запит ваш пароль до FTP - введить його, і ви отримаєте доступ до вашій домашнії директорії на сервері.

Дана помилка звичайно є наслідком некоректно налаштованого файрволу (брандмауэру) або другого мережевого ПЗ, блокующого порти компьютеру, а також у випадках, коли підключення призводиться із локальной мережі (через так званий NAT). В цьому випадку необхідно використовувати пасивний режим FTP. А якщо це не допоможе - звірнутися до свого мережевого адміністратору або провайдеру.

Причина скоріш всього у тому, що ви неправильно вказуєте ім'я хоста. Для підключення ви повинні використовувати такі адреси:

ftp://LOGIN.ho.ua/
ftp://sN.ho.ua/

де LOGIN - це ваш логін, а sN - це сервер хостингу, на якому розташован ваш сайт (s1, s2 и т.п.) - цей сервер вказан в листі с налаштуваннями вашого хостингу.

Ні. На наших серверах не встановлено ПЗ для роботи з Microsoft FrontPage (і не буде). Однак той же Microsoft FrontPage підтримує роботу за протоколом FTP - використовуйте його для редагування свого сайту.

Довідка по роботі у файловому менеджері с прикладами наведена на нашому сайті. Також ви можете визвати довідку із самого файлового менеджеру (кнопка-іконка з символом знаку питання).

Даний файл служить для змін налаштувань веб-серверу Apache. Внесені в нього директиви застосуються для файлів та директорій, які знаходяться у директорії, де міститься даний файл .htaccess. Серед можливістей даного файлу можна відмітити:

• реалізація базової HTTP-аутентификації;
• заборона доступу до деяких файлів по масці (по розширенню, імені та т.і.);
• заборона доступу до сайту з деяких IP-адрес або диапазону IP-адрес;
• установка кодування документів;
• опис обробки файлів певного типу (розширення) - SSI, php и т.п.

Все можливості налаштування веб-серверу ми перерахувати не можемо - їх ви можете дізнатися в документації веб-серверу Apache.

Пеперше вам потрібно з'ясувати, наслідком чого є невірне відображення кодування: видачі даних, які містяться у файлах на сервері, або результату роботи скрипту, який бере данні із бази даних. В іншому випадку вам потрібно також прочитати цю інструкцію.

В першому випадку потрібно знати, в якої кодіровці (windows-1252, koi8-r або utf-8) ваші файли на сервері. А далі - виконати просту дію: вказати в директиві AddDefaultCharset windows-1251 файла .htaccess це кодування. До речі, якщо ви не видалили початкові файли .htaccess, то в них уже є необхідні рядки - вам достатньо тільки закоментувати непотрібну и разкоментувати потрібную директиву (тобто прибрати символ # з початку рядка з директивою AddDefaultCharset. При цьому для різних файлів вносить зміни потрібно в наступних файлах .htaccess:

• для cgi-скриптов, розташованих в директорії cgi-bin, а також для файлів php потрібно редактувати файл ~/cgi-bin/.htaccess;
• для остальних файлів, розташованих в директорії htdocs (html-документи, cgi-скрипти и т.п.), потрібно редактувати файл ~/htdocs/.htaccess. відмітім ще раз, що на кодіровку php-скриптов цей файл не впливає!

Щоб вказати, як можна (або неможна) індексувати ваш сайт пошуковими роботами, використовуєтся спеціальний файл robots.txt, який повинен розташовуватися в директорії htdocs і бути доступний по адресі типу http://АДРЕСА.вашого.сайту/robots.txt .

Формат даного файлу наступний: поперше йде рядок опису імені роботу (для кожного пошукового роботу воно унікальне та його можна дізнатися на сайті поисковику

User-Agent: *

За цим рядком слідують рядки, які забороняють індексацію окремих частин сайту - після слова Disallow вказуеться локальна частина URL (адреса після домену). Вот приклад:

• Disallow: /cgi-bin/ - заборона індексації змісту директорії cgi-bin;
• Disallow: /admin.php? - заборона індексації всех URL, які містяться в локальної частині рядку /admin.php? (при цем, URL с /admin.php буде проіндексирований);
• Disallow: /forums/ - заборона індексації змісту директорії /forums/.

заборона індексації окремих частин сайту позбавить ваш сайт (и наш сервер хостингу) від зайвого навантаження. Ми переконливо рекомендуемо виконати хоч часткову заборону дінамічних частин сайту (форуми, дошки об'яв і т.і.). Це не тільки дозволить більш єкономно використовувати ресурси серверу хостингу, але й уникнути закриття ваношо сайту.

Насамперед під СПАМ-ботом в даному контексті ми розуміємо боти (роботи), які автоматично залишають на сайті повідомления (зазвичай рекламного змісту або з посиланням на інші сайти) або відправляють через форми на вашому сайті листи такого ж характеру.

Ми рекомендуемо використовувати на сайті таке ПЗ, яке просто не дозволяє відвідувачам залишати повідомления без попередньої авторизації. В даному випадку ви зможете хоч якось керувати змінами на вашому сайті (форуми, дошки об'яв і т.і.) Сама реєстрація, бажано, повинна происходити с перевіркою того, що даную реєстраційну форму заповнює людина (різного роду логічні питання або картинка ("капча" на жаргоні) напис, який важко автоматично разпознати. Це не дає 100% захисту від реєстрацій роботами, але значно зменьшує цю імовірність.

Друга можливість захисту - це безпосередня перевірка "людяності" ("капча") при створені повідомления відвідувачем сайту.

І останне - ми не рекомендуємо на вашому сайті використовувати (и предзалишаь усім відвідувачам) форми відправки писем (SMS) повідомлений - віни могут иметь много уязвимостей, дозволить злоумисникам використовувати цю форму для відправки СПАМ'у. А це приведе до закриття вашого сайту, а постраждаете саме ви.

Це DATA-з'єднання - наслідок використання звичайного FTP-режиму при підключенні до нашого серверу. Коли ви ініціюєте підключення по FTP, сервер намагається відкрити зустрічне DATA-з'єднание на ваш до омпьютер, що і блокуеться вашим файрволом (брандмауэром). Для нормальной роботи вам потрібно використовувати пасивний режим FTP, коли DATA-з'єднання вічиняє ваш комп'ьютер.

Прежде всього - не нервувати. При виявлені на вашему сайті вірусов и кодів, їх завантажуючих, ми блокуемо доступ по HTTP до вашего сайту. При цьому доступ по FTP залишається відкритим (для видалення кодів вірусів).

Якщо ви отримали лист с попередженням про наявность вірусу и прикладом його коду (деякі поштові служби можуть блокувати подібні листи), то вам достатньо його уважно прочитати та виконати у вірному порядку описані в ньому пункти. Якщо ж ні - то наводим їх (порядок пунктів змінювати вкрай небажано, оскільки в іншому випадку залишиться імовірність того, що з часом віруси з'являться знову):

1. перевірте на наявність вірусів всі комп'ютери, з яких був доступ по FTP до змісту вашого сайту.
2. видалить внесенні вірусом зміни на своему сайті (доступ по FTP для редагування сайту відкритий).
3. змінити пароль для FTP-аккаунта в панелі управління хостингом, або написати про це нам.

Після цьйого ми відкриемо доступ по HTTP до вашого сайту. Якщо ваш сайт вже не вперше закриваеться з причини виявлення вірусів - переконливе прохання віднестись з особливою увагаю до перевіркі вашого локального комп'ьютеру (та інших, з яких виконується підключення по FTP) на наявність вірусів и інших програм "троянів", які можуть вкрасти пароль до FTP-аккаунту.

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

Резервне копіювання домашніх директорій робиться раз на добу (вночі). Якщо Вам потрібна резервна копія - то звірніться до служби підтримки, вказавши точну дату, за якую вам потрібни збереженні дані. Без вказання дати ми запит по відновленю не виконаємо. Кількість самих резервних копій чітко не обмежено - звичайно їх порядка 7 та більше - в залежності від об'єму цих даних.

Q: При роботі у файловому менеджері при виборі будь-якого посиланния часто виникає повідомлення "Неможливо відобразити сторинку". Що робить?

Дана проблема не зв'язана с файловим менеджером або phpMyAdmin, а з роботою за протоколом HTTPS (захищене з'єднання). Ми спостерегали дану проблему тільки при роботі в браузері Internet Explorer. Якщо у вас є можливість зменити браузер (Mozilla, наприклад), то зробить це. Якщо ж ні - можете працювати по незащищенному протоколу HTTP (ми не рекомендуемо робити це, т. як в даному випадку обмін даними між Вами та сервером здійснюється в нешифрованному виді. Для роботи за звичайним нешифрованим протоколом Вам потрібно змінити назву протоколу в адресному рядку: з https://... на http://...

Q: Коли заходжу в панель управління браузер попереджає мене про проблеми з SSL-сертифікатом. Чи можна йому довіряти?

У нас використовується самоподписаний SSL-сертифікат и він має ту же силу, що и подписанний у авторизованих центрах сертифікации (тільки о яких ваш браузер і знає). В цьому нема ничого страшного - головне, не ким підписан SSL-сертифікат (це ви можете дізнатися у його властивостях), а те, що все данні между вашим браузером и нашим сервером передаються в шифрованому вигляді (праця в панелі управління хостингом, файловому менеджері, phpMyAdmin и інших веб-панелях, які ми надаємо), і їх перехоплення не приведе до перехоплення переданих Даних (паролі та інша суб'єктивна інформація).

Зрозуміло, ми не вводимо серйозних обмеженнь на відправку пошти із скриптів. Однак не слід цим зловживати, оскільки у випадку надходження скарг про масові розсилки пошти (SPAM) та інші порушення мережевого етикету ми будемо вимушені закрити Ваш хостинг. Відмітимо, що у нас є заборона на будь-які масові розсилки.

A: Для створенния ще одного сайту на аккаунті Вам необхідно в панелі управління нажати кнопку "домени", де ви можете додавать свої домени до хостингу (кнопка "додати"). При цьому Вам крім поля для вводу самого домену пропонується ввести "Корневу теку:" (htdocs за замовчуванням). Так для створення нового сайту Вам потрібно вказати другу теку - це може бути будь-який каталог в вашій домашній директорії, крім спеціальних - cgi-bin и logs. Наприклад, як корневу теку нового сайту ви можете вказати htdocs2

Після цього у Вашему домашнему каталозі з'явиться вказанна Вами тека, де Вам потрібно размістити файли створеного сайту. При цьому сам сайт запрацює через деякий час (біля 1 години) і за умови вірного налаштування Вашого домену.

Ми надаємо для кожного безкоштовного еккаунта одну базу даних MySQL. При створенні хостингу ця база не створюєтся. При необхідности ви сами можете створити ії у панелі управління хостингом (кнопка "База даних"). Ім'я створеної бази даних співпадає з логіном хостингу, а пароль до неї ви задаете самі.

На безкоштовному хостингу ми надаємо одну БД MySQL на один аккаунт. Якщо Вам потрібно більше одної БД - ми можемо порадити використовувати префикси для таблиц. На платному хостингу кількість БД залежить від тарифу - це 2 та більше БД.

Для керування БД MySQL ми надаємо phpMyAdmin. Для різних серверов хостингу шлях до phpMyAdmin різний. Адрес phpMyAdmin показується при створенні БД, однак його ви самі можете легко запам'ятати. Загальний вид адреси:
https://www.ho.ua/phpMyAdmin

де sN - це сервер хостингу, на якому розташован ваш сайт (s1, s2 і т.п.). Відмітимо, що створювати БД в phpMyAdmin ви не зможете.

Поперше, переконайтеся, що в панелі управління хостингом база даних для вашого єкаунту створена. Якщо ні - створить ії. Далі, переконайтеся, що ви заходите в phpMyAdmin на тому ж сервері хостингу, на якому розташован ваш єкаунт. І нарешті, перевірьте вірність введення логіну та паролю до БД - пом'ятайте, що логін у нас складається тільки із літер нижнього регістру, а паролі до FTP та БД відрізняються!

Для підключення до БД MySQL з ваших скриптів вказуйте наступне ім'я хоста баз даних:

dbN.ho.ua

де dbN - по аналогии з ім'ям серверу хостингу, на якому розташований ваш сайт (db1, db2 и т.п.). Використання в якості імені хоста баз даних значення localhost хоч и буде працювати, але з'являється не зовсім вірним й, до речі, в даному випадку ми не можемо гарантувати в майбутньому працездатність підключения до серверу баз даних з цім значенням.

Щоб легко й просто з першого разу імпортувати дамп БД MySQL, він повинен містити:

• визначення створення таблиц як CREATE TABLE IF NOT EXISTS ... або DROP TABLE IF EXISTS ... (це позбавить вас від проблем при повторному завантаженню дампа);
• вказане кодування даних (звичайно в самому початку дампа);
• дамп не повинен містити SQL-команди створення самій БД - це приведе до помилки у самому початку дампа.

При дотриманні вішеопісаних правил при створенні дампа БД (за допомогою phpMyAdmin і т.і.) ви зможете легко імпортувати отриманий дамп.

Резервне копіювання баз даних виконуєтся раз за добу (ніччю). Якщо Вам потрібна резервна копія (SQL-дамп бази) - то звірніться до служби підтримки, вказав точну дату, за яку вам потрібен цей дамп. Якщо Вам потрібно повністю відновити БД - ми це можем зробити. Якщо окремі таблиці - то ми тільки лишь надамо вам заархівованний SQL-дамп (розмістимо у вашій домашнії директорії) - розбирати його прийдеться вам самому. Без вказання дати ми запит на відновлення не виконуємо. Кількість самих резервних копій чітко не обмежена - звичайно їх поряд 7.

Ні. В цілях безпеки та надійності ми вимкнули зовнішній доступ до БД. Із скриптів вашого сайту и phpMyAdmin доступ є.