Вау, я сделал это )) Наверно год всё собирался открыть свой блог, дабы копить информацию, необходимую чаще, возможно, мне самому, а может и пригодится ещё кому нибудь. Если Вы здесь — Добро пожаловать на мой блог !!
WordPress был избран как система, лидирующая на рынке, посудите сами -61% от всех установленных систем управления контентом !. И кроме, этого он таки поднялся на моём более чем скромном оборудовании с большими задачами)
Сервер поднят на стареньком HP 7400dx c 3Гб памяти, на нём работает сайт imbus.ru , система видеонаблюдения , а также файловое хранилище. Думаю, HP даже предполагать не могли такой долгой жизни своего продукта. Эх, было же когда то качество !!
Теоритически я планировал, что на своей десктопной машине разверну копию сервера в виртуальном окружении, а затем проведу изощренные опыты на этом виртуальном окружении. Копия у меня была, даже несколько. Первая это была стартовая виртуальная машина , развернутая когда то под Windows и используемая для разработки своего сервера, на ней изначально ставились опыты. После некоторых танцев с подключением старого диска в vdi-формате к Virtual Manager ( сейчас я пытаюсь перейти на c Windows 7 на Ububtu, в которой используется сервис QEMU) машина завелась. Танцы заключались во первых в том, что тип драйвера должен SATA, а по умолчанию ставится virtio. Когда стоит virtio, система начинает грузиться, однако потом останавливается с ошибкой определения диска по UUID, который пропискан в fstab. Я сначала посчитал, что при переносе машины QEMU по другому определяет диски и начал пытаться следовать руководствам по восстановлений ubuntu в таких случаях — т.е. грузить систему из флэшки или iso образа и в отладочном режиме определить новый UUID и исправить его. Когда я до этого добрался, то увидел, что UUID, выдаваемый командами blkid или lsblk — t тот же,что был в fstab. После столкновения с реальностью, испытал шок и пошел искать по просторам инета дальше, тогда я наткнулся на рекомендацию сменить тип драйвера
Это и спасло ситуацию.
Но к сожалению только отчасти, т.к. эта инсталляция содержала только давнее состояние сервера, до его модификации и апгрейда.
Но это было начало. Далее была виртуальная машина из под винды, но в нестартуемом состоянии, она была сделана с помощью восстановления из образа диска, созданного командой dd(если я не ошибаюсь тут). Однако, т.к. исходный диск был в формате LSW и он был уменьшен в ходе восстановления(т.е. на оригинальной системе физический диск 128 Гб, реально занимает система около 30, и при восстанвлении в виртуальный диск он был соразмерно уменьшен), то при загрузке система выдвала уже другую ошибку. Это удалось преодолеть, путем установки ubuntu той же версии , но в графическом варианте, затем с утилитой GParted была выполнена проверка раздела и Gparted спокойненько и мимоходм так исправил его. К сожалению, применить эту систему не удалось, т.к. она оказалась ещё старее.
Была надежда также на другой вариант. В феврале этого года был сделан бэкап ОС сервера со всеми потрохами с помощью CloneZilla — мега тулза, очень помогает с бэкапированием как windows, таки linux. Так вот, у меня имелся её бэкап и возможный ход действий следующий: Создать новую виртуалку, там для неё создать диск, пустой, подключить к виртуалке CD от CloneZilla и воспользоваться бэкапом для восстановления. CloneZilla и здесь показала себя замечательно — подключалась даже по Samba за образом. Однако оказалось, что она не может восстановить образ с диска большего размера на диск меньшего размера , наоборот — пожалуйста, в этом направлении никак. Единственный вариант получить нормальный тестовый полигон, это выделить 128Гб под виртуальный диск, восстаноивить туда из бэкапа Clonezilla и запустившись, выполнить изменение размера диска(урезать). Т.е. получится копия боевого сервера, но на меньшем виртуальном диске.
Но на это я пойтить не могу, сказала моя внутренняя жаба, осмотрев имеющиеся свободные спэйсы)). Пришлось забить пока на нормальный полигон, взять старый бэкап и проапгрейдить его до аналога текущего. Аналога, потому что некоторые пакеты, были безжалостно отключены авторами-суппортерами на текущий момент в пользу обновления версий.
Так или иначе, я поставил WordPress сначала на тестовом окружении и затем уже на боевом. Использовалась вот это замечательное руководство на сайте digitalocean.com от Brian Boucheron и Justin Ellingwood Спасибо им!
Если кому то интересны команды, использованные мной походу установки, то ниже фрагмент bash_history Надо понимать, что они не носят исчерпывающий характер, а скорее показывают ход действий.
<создана директория для файлов wordpress в разделе /var/www и создан файл конфигурации для нового сайта>
sudo a2ensite wordpressdir
systemctl reload apache2
sudo apt install certbot python3-certbot-apache
sudo apachectl configtest
sudo certbot --apache
sudo systemctl status certbot.timer
sudo certbot renew --dry-run
sudo mysql -u root -p
<создана база для wordpress>
sudo apt install -y software-properties-common
sudo apt update
sudo apt install php7.2-curl
sudo apt install php7.2-gd php7.2-mbstring php7.2-xml php7.2-xmlrpc php7.2-soap
sudo apt install php7.2-intl php7.2-zip
sudo systemctl restart apache2
sudo apache2ctl configtest
sudo systemctl restart apache2
curl -O https://wordpress.org/latest.tar.gz
tar xzvf latest.tar.gz
touch wordpress/.htaccess
cd ..
sudo cp -a ~/wp/wordpress/. /var/www/wordpressdir
sudo cp -a ~/wp/wordpress/. /var/www/wordpressdir
sudo find /var/www/wordpressdir/ -type d -exec chmod 750 {} \;
sudo find /var/www/wordpressdir/ -type f -exec chmod 640 {} \;
sudo chown -R www-data:www-data /var/www/wordpressdir
curl -s https://api.wordpress.org/secret-key/1.1/salt/ > salt.txt
<далее происходила правка конфигурации wordpress и были внесены полученные секреты>
sudo systemctl restart apache2
И. надо учитывать, что wordpress жалуется на не совсем новую версию php, а кроме того закрывает нектороые плагины от загрузки. Но мне это не так важно.
С уважением, Макс