Автоматичен инсталационен скрипт

Автоматичен начин: един скрипт от личния профил подготвя целия сървър (уеб стек Apache + PHP, база данни, инструменти за сигурност, cron). След това — разгръщане на панела, издаване на SSL и въвеждане на лиценз. Работи на Ubuntu/Debian: на нов VPS настройва всичко от нулата, на вече настроен сървър — само добавъчно (профил „Настроен сървър“, стъпка 01). Всички команди по-долу са подредени — просто ги прелистете отгоре надолу. На нов VPS е приложима всяка стъпка последователно; ако сървърът вече е настроен или на него има хостинг панел, част от работата скриптът нарочно оставя на вас — какво точно, той изписва в края на работата си (разборът на изхода е в стъпка 01).

Избор на начин Ръчна инсталация FAQ справочник

Заместващите стойности в командите заменете със свои: monitor.example.com — вашият домейн; 203.0.113.10 — реалният IP на сървъра; /var/www/monitor — коренът на панела (където се намират public/, assets/, config.php); за паролата на БД измислете своя.

Пълният набор („Пълна защита“) е предвиден за нов VPS. На чиста Ubuntu/Debian той настройва системата за сигурност от нулата — Fail2ban (jail.local), root-crontab, правила на UFW, конфигурация на Apache. Ако сървърът е вече настроен (работещ панел, сайтове, поща, собствени jail-ове) — изберете профил „Настроен сървър“: той внася само добавъчни промени и не докосва вашия защитен екран, Fail2ban, поща, SSH и sysctl. При откриване на хостинг панел скриптът сам превключва на този режим. Преди първото стартиране можете да включите сух пробег (отметка в профила) — той ще покаже какво ще бъде направено, без да променя нищо. На работещ сървър за всеки случай направете снимка (snapshot).

01. Команда за автоматична настройка от профила

Командата вземате от своя личен профил my.arciveo.com → раздел „Настройка на сървъра“ (достъпен след активиране на Arcivéo Security Monitor). Тя е обвързана с вашия акаунт и съдържа персонален токен.

Скриптът подготвя целия сървър: уеб стек (Apache + PHP), база данни, инструменти за SSL, пълен набор от средства за защита и cron задачи (Lynis, SMART, debsums, Logwatch, ежедневен отчет, обновяване на ipsum).

1) Изберете ниво на защита (в профила, преди копиране на командата):

Пълна защита (препоръчва се) — UFW (защитна стена), Fail2ban, CrowdSec + bouncer, ipsum (блок-списък с IP), Suricata (IDS/IPS), Falco, ModSecurity + OWASP CRS (WAF), PSAD, mod_evasive (анти-DoS), AIDE (цялост на файловете), debsums, ClamAV + maldet (антивирус), Auditd, AppArmor, Monit, Lynis (одит), Logwatch, автоматични обновления за сигурност.
Облекчена — за VPS с малко RAM: базов набор без тежки компоненти.
Настроен сървър (хостинг панел) — за вече работещ сървър с панел (HestiaCP и др.), сайтове и поща: само добавящи промени (доинсталиране на инструменти, cron, sudo правила), а защитната стена, Fail2ban, пощата, SSH и sysctl остават непроменени. На сървър с панел скриптът избира този режим сам.

Пробно изпълнение. В профила може да отметнете „Пробно изпълнение“ — тогава командата само ще покаже какво ще инсталира и промени скриптът и ще приключи, без да променя нищо. Полезно е на вече настроен сървър: първо пробно, после реално изпълнение без отметката.

2) Изпълнете на сървъра като root командата от профила — тя изглежда така:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN" | sudo bash

Командата пазете в тайна — тя е обвързана с вашия акаунт. Връзката има ограничен срок на валидност; ако е изтекла, натиснете в профила „Получи нова връзка“.

След автоматичната настройка уеб сървърът е Apache + PHP-FPM, а инструментите за сигурност и cron задачите вече са инсталирани и работят „наготово“.

3) Прочетете изхода в края — там е казано какво остава за вас. Скриптът завършва работата си с блок проверки и списък „По-нататък — инсталиране на панела“. Част от стъпките той нарочно не изпълнява: кои точно, зависи от избрания профил и от това какво е намерил на сървъра. Сверете се със списъка по-долу — трябва да изпълните само онези точки, чиито редове са се появили във вашия изход.

Control panel detected (…) — сайтът се създава със средствата на самата хостинг панел, скриптът не прави vhost. Стъпка 03, клон „Сървър с хостинг панел“.
No vhost created (no domain given) — профил „Настроен сървър“ без домейн: vhost без име би станал сайт по подразбиране и би прихващал вашите собствени сайтове, затова не е създаден. Стъпка 03, клон „Създаване на vhost на ръка“.
sudo rules NOT written — скриптът не е могъл да определи под кой акаунт работи панелът. Това е обичайна ситуация: файловете на панела се качват след автоматичната настройка и още не е имало по какво да се определи. Без тези правила модулите няма да виждат системните данни. Стъпка 04, блок „sudo за уеб сървъра“.
! Nginx does not read .htaccess — пред Apache стои Nginx и вписването на забраната в неговата конфигурация не е успяло автоматично. Направете го задължително: иначе data/, keys/, database/ и config.php се отдават навън, заобикаляйки .htaccess. Стъпка 03, блок „Ако пред Apache стои Nginx“.
UFW installed but inactive — защитната стена е инсталирана, но изключена: на настроен сървър скриптът не я включва сам, за да не ви отреже достъпа. Включете я сами, като задължително разрешите своя SSH порт:
sudo ufw allow OpenSSH # нестандартен SSH порт: sudo ufw allow 2222/tcp sudo ufw allow 80,443/tcp sudo ufw enable
Fail2ban installed but not running — стартирайте: sudo systemctl enable --now fail2ban.
Database server present … but not running — стартирайте СУБД преди стъпка 04: sudo systemctl enable --now mariadb (или mysql — според това какво е инсталирано).
Certbot skipped — issue SSL in … — сертификатът се издава с превключвателя Let's Encrypt в хостинг панела; стъпка 06 не ви е нужна.

Ако в блока с проверки всичко е наред, последният ред е All checks passed. Точките с ! изискват внимание; подробностите се записват в лога, чийто път скриптът отпечатва в самия край (Log: …).

02. Домейн и DNS

За да отваряте панела на адрес като monitor.example.com и да получите безплатен SSL, домейнът трябва да сочи към сървъра. В панела за управление на DNS (при регистратора или хостинг доставчика) създайте A-запис:

Тип: A Име: monitor (поддомейн → monitor.example.com) или @ (корен на домейна → example.com) Стойност: 203.0.113.10 ← IP на вашия сървър TTL: 3600

След няколко минути (понякога до час) проверете дали домейнът сочи към сървъра:

dig +short monitor.example.com # трябва да върне вашия IP # или, ако няма dig: getent hosts monitor.example.com

SSL-сертификатът (стъпка 06) се издава само за домейн — затова DNS трябва да сочи към сървъра преди издаването на сертификата.

03. Качване на файловете на панела

Обичайният случай (нов VPS). Автоматичната настройка вече създаде директорията на панела /var/www/monitor и конфигурира сайта на Apache (DocumentRoot към корена на панела, PHP-FPM, AllowOverride за .htaccess). В изхода на скрипта това е редът vhost … → DocumentRoot …. Не е нужно да създавате отделно директория и vhost — просто качете файловете и задайте правата.

Два случая, в които vhost НЕ е създаден — скриптът съобщава за това пряко в края на работата си. Тогава първо изпълнете съответния клон по-долу и едва след това качвайте файловете.

Клон „Сървър с хостинг панел“ (в изхода: Control panel detected (…)). На такъв сървър със сайтовете се разпорежда панелът и скриптът нарочно не създава свой vhost — той би бил изтрит при първото пресъздаване на конфигурациите от панела. Редът е следният:

Създайте уеб домейн в хостинг панела (HestiaCP и др.) — неговият DocumentRoot остава както е.
Качете дистрибуцията изцяло в public_html на този домейн: до index.php, api/, assets/ трябва да се намират и служебните config.php, includes/, data/, tmp/, logs/, keys/, cron/, database/. Не е нужно да изнасяте нищо над уеб корена: служебните папки са затворени с файла .htaccess от дистрибуцията, а под Nginx — със забраната, която скриптът е вписал в конфигурацията на домейна.
SSL се издава с превключвателя Let's Encrypt в самия панел — пропуснете стъпка 06.
По-нататък — правата (по-долу в тази стъпка), базата (стъпка 04) и config.php (стъпка 05). Пътищата в командите заменете с /home/акаунт/web/домейн/public_html, а собственика — с потребителя на този домейн вместо www-data.

Клон „Създаване на vhost на ръка“ (в изхода: No vhost created (no domain given)). Това се случва само при профил „Настроен сървър“, когато домейнът не е бил подаден. Най-лесно е просто да рестартирате командата от профила, като посочите домейна:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo bash -s -- monitor.example.com

Повторното изпълнение е безопасно: вече направеното не се дублира. А ако vhost трябва да се създаде на ръка — ето същата конфигурация, която записва инсталаторът:

sudo mkdir -p /var/www/monitor # Сокетът на PHP-FPM се определя автоматично — версията на PHP е различна на различните сървъри. PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) sudo tee /etc/apache2/sites-available/arciveo-monitor.conf > /dev/null <<'EOF' <VirtualHost *:80> ServerName monitor.example.com DocumentRoot /var/www/monitor <Directory /var/www/monitor> Options -Indexes +FollowSymLinks AllowOverride All Require all granted </Directory> <FilesMatch "\.php$"> SetHandler "proxy:unix:__PHPSOCK__|fcgi://localhost" </FilesMatch> ErrorLog ${APACHE_LOG_DIR}/arciveo-monitor_error.log CustomLog ${APACHE_LOG_DIR}/arciveo-monitor_requests.log combined </VirtualHost> EOF sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/apache2/sites-available/arciveo-monitor.conf sudo a2ensite arciveo-monitor.conf sudo apache2ctl configtest sudo systemctl reload apache2

ServerName тук е задължителен. Vhost без име става сайт на Apache по подразбиране и започва да отговаря за чужди домейни на същия сървър. По същата причина не изключвайте 000-default.conf на настроен сървър: този сайт може да е бил преправен за нечий работещ проект — на нов VPS инсталаторът го премахва сам, тук това не е нужно да се прави.

Ако пред Apache стои Nginx (в изхода: ! Nginx does not read .htaccess). Nginx отдава статичните файлове директно от диска и не чете .htaccess — служебните папки ще се окажат отворени навън, макар че Apache ги затваря коректно. Скриптът предварително е подготвил файл със забрани; той трябва да се включи в блока server{} на вашия сайт и Nginx да се презареди:

include /etc/nginx/snippets/arciveo-deny.conf;

sudo nginx -t && sudo systemctl reload nginx # Проверка: трябва да върне 403, а не съдържанието на файла curl -sI https://monitor.example.com/config.php | head -1

Файловете на панела (архивът с дистрибуцията) се изтеглят след покупката в профила my.arciveo.com → „Изтегляния“. Разархивирайте архива преди качване на сървъра.

Качете съдържанието на дистрибуцията в /var/www/monitor (така че вътре да се окажат public/, assets/, config.php и т.н.) — по SFTP/SCP (FileZilla / WinSCP) или с командата scp от локалния компютър:

scp -r ./monitor/* deploy@203.0.113.10:/var/www/monitor/

За да се впише веднага вашият домейн във vhost (ServerName), той се подава в командата за автоматична настройка още на стъпка 01: … | sudo bash -s -- monitor.example.com (или се посочва домейнът в полето „Домейн на панела“ в профила). Ако домейнът не е подаден — панелът отговаря на всеки хост и по IP, а ServerName ще впише certbot при издаването на SSL (стъпка 06); не е нужно да преинсталирате нищо.

Задайте правата върху файловете — това е задължителна стъпка. Ако сте качвали като root или по SFTP, файловете принадлежат на root и уеб сървърът (www-data) няма да може да ги прочете — панелът ще се отвори празен или с грешка 403 (в лога: .htaccess unreadable / directory not executable). Командата по-долу поправя това:

# Нормализираме правата на целия уебрут: директорията, създадена от root, е недостъпна # за уеб сървъра (www-data) — без това панелът връща празна страница или 403. cd /var/www/monitor # Работните папки създаваме ПРЕДИ chown — иначе новите директории ще останат root:root # и при chmod 750 уеб сървърът (www-data) няма да може да пише в тях. sudo mkdir -p data/lynis data/logwatch tmp logs sudo chown -R www-data:www-data /var/www/monitor sudo find /var/www/monitor -type d -exec chmod 755 {} \; sudo find /var/www/monitor -type f -exec chmod 644 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 750 data tmp logs

Отворете си качването на файлове по SFTP. След горната команда всички файлове принадлежат на www-data, а FileZilla / WinSCP се свързват с вашия собствен потребител — качването тогава се проваля с SSH_FX_PERMISSION_DENIED (Permission denied). Изберете един от двата варианта.

Вариант A — ACL само за вашия потребител (препоръчително). Право на запис получавате само вие; уеб сървърът все така не може да презапише кода на панела:

sudo apt install -y acl # Право на запис за вашия потребител върху цялата директория на панела: sudo setfacl -R -m u:deploy:rwX /var/www/monitor # Същото правило по подразбиране — за файлове и папки, създадени по-късно: sudo setfacl -R -d -m u:deploy:rwX /var/www/monitor

Вариант B — през групата www-data. По-прост, но право на запис върху файловете на панела получава и уеб сървърът: при уязвимост в PHP кодът би могъл да бъде подменен. Редът на командите е важен — config.php и работните папки се затварят последни:

sudo usermod -aG www-data deploy # Запис за групата + setgid (бит 2): качените по SFTP файлове остават # в групата www-data — иначе панелът няма да може да ги презапише. sudo find /var/www/monitor -type d -exec chmod 2775 {} \; sudo find /var/www/monitor -type f -exec chmod 664 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 2750 /var/www/monitor/data /var/www/monitor/tmp /var/www/monitor/logs

След вариант B свържете се наново във FileZilla (Сървър → Прекъсване на връзката, след което влезте отново) — новата група се прилага само при ново влизане, дотогава права пак няма да имате. Проверка: id deploy — в списъка с групи трябва да се появи www-data; ls -ld /var/www/monitor — права drwxrwsr-x, буквата s вместо x означава, че setgid е зададен.

04. База данни

Създайте база и потребител, след което импортирайте схемата. Блокът с БД се поставя в терминала изцяло (sudo mysql влиза като root през unix-сокет — паролата за root не е нужна). monitor_db и monitor_user са имена за пример, можете да зададете свои; запомнете името на базата, потребителя и паролата — ще ги впишете в config.php на следващата стъпка:

# 1. База данни. Името на базата, потребителят и паролата се задават ВЕДНЪЖ по-долу и се подставят във всички редове. # Блокът се поставя в терминала ИЗЦЯЛО; sudo mysql влиза като root през unix-сокет # (паролата за root не е нужна). НЕ използвайте интерактивния `sudo mysql -u root -p` # с копи-пейст — при поставяне SQL-редовете ще отидат в подканата за парола и ще се загубят. DBNAME='monitor_db' # ← име на базата, може да остане DBUSER='monitor_user' # ← потребител на БД, може да остане DBPASS='CHOOSE_A_PASSWORD' # ← парола, задайте своя sudo mysql <<SQL CREATE DATABASE IF NOT EXISTS $DBNAME CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS '$DBUSER'@'localhost' IDENTIFIED BY '$DBPASS'; GRANT ALL ON $DBNAME.* TO '$DBUSER'@'localhost'; FLUSH PRIVILEGES; SQL # Проверка (трябва да покаже $DBNAME): mysql -u "$DBUSER" -p"$DBPASS" -e "SHOW DATABASES;" # Същите три стойности впишете в config.php → DB_NAME, DB_USER, DB_PASS.

Обикновено не е нужно да импортирате схемата — панелът сам създава таблиците и акаунта admin при първото влизане в браузъра (от database/db.sql), ако БД е празна.

Ако таблиците не са се създали (панелът показва грешка при свързване с БД или празен екран вместо форма за вход) — импортирайте схемата на ръка. Командата се изпълнява в корена на панела, стойностите се вземат от блока по-горе:

# Импорт на схемата: cd /var/www/monitor && mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" < database/db.sql # Проверка — трябва да се появи списък с таблиците: mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" -e "SHOW TABLES;"

Ако променливите $DBNAME / $DBUSER / $DBPASS вече са „забравени“ (нова сесия на терминала) — заменете стойностите в командата на ръка или ги задайте наново със същите три реда от блока по-горе.

sudo за уеб сървъра. Обикновено правилата вече са записани от автоматичната настройка и модулите виждат системните данни веднага. Но ако в изхода на скрипта е имало ред sudo rules NOT written — акаунтът на панела не е могъл да бъде определен (файловете още не са били качени) и правилата не са създадени. Без тях раздели като защитната стена, Fail2ban и CrowdSec ще останат празни. Сега, когато файловете са на място, изпълнете командата от профила още веднъж, като назовете акаунта изрично:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo ARCIVEO_USER=www-data bash -s -- monitor.example.com

www-data заменете с потребителя, под който работи PHP на вашия сайт (в хостинг панел това обикновено е собственикът на домейна). Можете да го видите така:

ps -o user= -C php-fpm8.3 | sort -u # версията заменете със своята # или: ps aux | grep -m3 '[p]hp-fpm'

Проверка след повторното изпълнение: файлът /etc/sudoers.d/monitor съществува и в него има редове с вашия потребител.

05. Настройка на config.php

config.php в основната директория на панела (/var/www/monitor/config.php) е единственият файл, който трябва да редактирате на ръка. Всички настройки на панела са зададени в него чрез константи define(). Отворете го в редактор:

sudo nano /var/www/monitor/config.php

Заменете със своите стойности на маркираните места; останалото оставете както е:

// --- База данни (от стъпка 04) --- define('DB_HOST', 'localhost'); // оставете define('DB_NAME', 'db_name'); // това, което създадохте в стъпка 04 define('DB_USER', 'user'); // това, което създадохте в стъпка 04 define('DB_PASS', 'db_password'); // това, което зададохте в стъпка 04 define('DB_CHARSET', 'utf8mb4'); // оставете // --- Приложение --- define('APP_URL', 'https://monitor.example.com'); // адрес на панела, без наклонена черта в края define('TIMEZONE', 'Europe/Sofia'); // вашият часови пояс // --- Времетраене на сесията --- define('SESSION_LIFETIME', 28800); // бездействие до повторно влизане, сек (28800 = 8 ч)

Какво да промените:

DB_NAME, DB_USER, DB_PASS — точно същите име на базата, потребител и парола, които зададохте при създаването на БД в стъпка 04 (ако оставихте примерите — monitor_db / monitor_user). Не пипайте DB_HOST и DB_CHARSET.
APP_URL — пълният адрес на панела с https://, без наклонена черта в края и без www. Трябва да съвпада с домейна, за който активирате лиценза (стъпка 07), иначе ключът ще бъде отхвърлен.
TIMEZONE — вашият часови пояс (списък — timedatectl list-timezones). Влияе само на това как панелът показва датите; на времето за стартиране на cron-задачите не влияе (там важи поясът на системата).
SESSION_LIFETIME — след колко секунди бездействие панелът ще поиска повторно влизане (по подразбиране 8 часа). Напр. 3600 = 1 час, 86400 = денонощие.
Блокът за логване на грешки (display_errors, log_errors, error_log) — оставете по подразбиране.

Запазете файла (Ctrl+O, Enter, след това Ctrl+X) и рестартирайте PHP-FPM — иначе заради OPcache промените няма да се приложат:

sudo systemctl restart php*-fpm

config.php е секретен файл (в него е паролата за БД). Той се намира в основната директория на панела, която е и уеб-коренът, но е защитен: права 640 (зададени в стъпка 03) и изрична забрана в основния .htaccess. Не го публикувайте в публични хранилища и не го изпращайте на поддръжката с реалната парола.

Подробен разбор на всички параметри — във FAQ: „Файлът config.php — всички настройки на панела“.

06. Издаване на SSL (HTTPS)

Панелът работи само по HTTPS. Входната сесия използва защитена бисквитка, а WebAuthn (2FA) по стандарт работи само по HTTPS. По http:// няма да можете да влезете.

На сървър с хостинг панел тази стъпка не е нужна (в изхода на скрипта: Certbot skipped — issue SSL in …). Сертификатът се издава с превключвателя Let's Encrypt на уеб домейна в самия панел — така с подновяването му също се занимава панелът.

certbot и плъгинът за Apache вече са инсталирани от автоматичната настройка. DNS на домейна вече трябва да сочи към сървъра (стъпка 02). Издаване с една команда:

sudo certbot --apache -d monitor.example.com

Ако панелът трябва да се отваря и с www. — изброете двете имена в една команда, иначе на втория адрес браузърът ще покаже предупреждение за сертификата:

sudo certbot --apache -d monitor.example.com -d www.monitor.example.com

Добавяйте второто име, само ако и за него има A-запис, сочещ към този сървър (стъпка 02). Иначе Let's Encrypt няма да може да го провери и няма да издаде сертификата изцяло — включително за основния домейн.

Какво ще попита certbot:

Enter email address — вашият e-mail (там ще идват известията за изтичане на сертификата).
Terms of Service … (Y)es/(N)o — Y.
Share email with the EFF … (Y)es/(N)o — по ваша преценка.

След това certbot сам ще издаде сертификата, ще впише <VirtualHost *:443>, ще настрои пренасочване http→https и автоматично подновяване. Накрая — Successfully enabled HTTPS.

Ако издаването се провали — проверете дали dig +short monitor.example.com връща IP адреса на сървъра и дали портове 80/443 са отворени (sudo ufw allow 80,443/tcp).

След издаването: https://monitor.example.com се отваря с катинар, а http:// пренасочва към https://.

07. Вход и първоначална настройка

Отворете https://monitor.example.com, влезте с admin / useradmin и преминете през списъка:

Сменете паролата на admin — раздел „Потребители“ в менюто.
Включете WebAuthn (2FA) — „Ключове WebAuthn“ → регистрирайте ключ/passkey (изисква HTTPS). Регистрирайте веднага два: при загуба на единствения ключ входът с него ще е невъзможен. Повече.
Ограничете достъпа по IP — „Настройки“ → „Ограничаване на достъпа по IP“ (впишете своя IP преди да включите, иначе ще си затворите достъпа).
Въведете лиценз — активирайте кода за активиране ARCIVEO-… от профила за своя домен и поставете ключа в „Настройки“ → „Лиценз“. Повече.
Настройте известията — Telegram и/или Email в „Настройки“. Повече.
Изтрийте инсталатора public/start_db.php, ако е останал: той позволява пресъздаване на базата без оторизация. Докато файлът е в корена на панела или в public/, панелът предупреждава за него с червен банер.
Стартирайте първите проверки на ръка — иначе част от разделите ще са празни до през нощта (вижте блока по-долу).

Защо „Одит Lynis“ и „Logwatch“ са празни в началото. Автоматичната настройка инсталира инструментите и създаде cron задачите, но не стартира самите проверки — те ще тръгнат по разписание: Lynis в 03:00, Logwatch в 06:00, debsums в 04:30, ClamAV в 01:30. Дотогава разделите честно показват, че отчети още няма. За да не чакате едно денонощие, изпълнете ги веднъж на ръка:

# Одит Lynis — първи отчет (няколко минути): sudo /usr/local/bin/lynis-scan.sh # Отчет на Logwatch за денонощието: sudo /usr/local/bin/logwatch_daily.sh # Цялост на пакетите (debsums) — на голям сървър отнема дълго: sudo /usr/local/bin/debsums-scan.sh

Lynis може да се стартира и директно от панела — бутонът „Стартиране на одит“ на страницата „Одит Lynis“: той изпълнява същия скрипт във фонов режим и сам обновява отчета. По-нататък всичко върви по разписание, ръчно стартиране повече не е нужно.

Първото антивирусно сканиране (sudo /usr/local/bin/clamav-scan.sh) натоварва силно диска и процесора и може да продължи час и повече — на работещ сървър е по-добре да изчакате нощното стартиране в 01:30. Разделите „Дискове (SMART)“, „Производителност“ и „Обновления за сигурност“ се попълват сами: съответно на всеки 30 минути, 5 минути и веднъж на час.

Готово. Справочник за всеки инструмент има във FAQ.

Ако на този сървър е нужен още един сайт със собствен домейн — вижте FAQ: „Втори сайт на този сървър (още един домейн)“.

Избор на метод FAQ справочник