Если нужно сделать перенаправление с одной страницы (псевдонима) на другую страницу нужно добавить следующий код в настройки сайта
server { ... location = /имя { rewrite ^/.* http://localhost permanent; } ... }
Настройка Linux сервера
Если нужно сделать перенаправление с одной страницы (псевдонима) на другую страницу нужно добавить следующий код в настройки сайта
server { ... location = /имя { rewrite ^/.* http://localhost permanent; } ... }
Мне лично проще всего думать о KVM (Kernel-based Virtual Machine), как о таком уровне абстракции над технологиями хардверной виртуализации Intel VT-x и AMD-V. Берем машину с процессором, поддерживающим одну из этих технологий, ставим на эту машину Linux, в Linux’е устанавливаем KVM, в результате получаем возможность создавать виртуалки. Так примерно и работают облачные хостинги, например, Amazon Web Services. Наряду с KVM иногда также используется и Xen, но обсуждение этой технологии уже выходит за рамки данного поста. В отличие от технологий контейнерной виртуализации, например, того же Docker, KVM позволяет запускать в качестве гостевой системы любую ОС, но при этом имеет и большие накладные расходы на виртуализацию.
Примечание: Описанные ниже действия были проверены мной на Ubuntu Linux 14.04, но по идее будут во многом справедливы как для других версий Ubuntu, так и других дистрибутивов Linux. Все должно работать как на десктопе, так и на сервере, доступ к которому осуществляется по SSH.
Проверяем, поддерживается ли Intel VT-x или AMD-V нашим процессором:
Если что-то нагреполось, значит поддерживается, и можно действовать дальше.
Устанавливаем KVM:
Что где принято хранить:
Теперь, когда KVM установлен, создадим нашу первую виртуалку.
В качестве гостевой системы я выбрал FreeBSD. Качаем ISO-образ системы:
Управление виртуальными машинами в большинстве случаев производится при помощи утилиты virsh:
Перед запуском виртуалки нам понадобится собрать кое-какие дополнительные сведения.
Смотрим список доступных сетей:
Просмотр информации о конкретной сети (с именем default):
Смотрим список доступных оптимизаций для гостевых ОС:
Итак, теперь создаем виртуальную машину с 1 CPU, 1 Гб RAM и 32 Гб места на диске, подключенную к сети default:
Вы можете увидеть:
Это нормально, так и должно быть.
Затем смотрим свойства виртуалки в формате XML:
Тут приводится наиболее полная информация. В том числе есть, к примеру, и MAC-адрес, который понадобятся нам далее. Пока что находим информацию о VNC. В моем случае:
С помощью любимого клиента (я лично пользуюсь Rammina) заходим по VNC, при необходимости используя SSH port forwarding. Попадаем прямо в инстялятор FreeBSD. Дальше все как обычно — Next, Next, Next, получаем установленную систему.
Давайте теперь рассмотрим основные команды для работы с KVM.
Получение списка всех виртуалок:
Получение информации о конкретной виртуалке:
Запустить виртуалку:
Остановить виртуалку:
Жестко прибить виртуалку (несмотря на название, это не удаление):
Ребутнуть виртуалку:
Склонировать виртуалку:
Включить/выключить автозапуск:
Запуск virsh в диалоговом режиме (все команды в диалоговом режиме — как описано выше):
Редактирование свойств виртуалки в XML, в том числе здесь можно изменить ограничение на количество памяти и тд:
Важно! Комментарии из отредактированного XML, к сожалению, удаляются.
Когда виртуалка остановлена, диск тоже можно ресайзить:
Важно! Вашей гостевой ОС, скорее всего, не понравится, что диск внезапно стал больше или меньше. В лучшем случае, она загрузится в аварийном режиме с предложением переразбить диск. Скорее всего, вы не должны хотеть так делать. Куда проще может оказаться завести новую виртуалку и смигрировать на нее все данные.
Резервное копирование и восстановление производятся довольно просто. Достаточно сохранить куда-то вывод dumpxml, а также образ диска, а потом восстановить их. На YouTube удалось найти видео с демонстрацией этого процесса, все и вправду несложно.
Интересный вопрос — как определить, какой IP-адрес получила виртуалка после загрузки? В KVM это делается хитро. Я в итоге написал такой скрипт на Python:
#!/usr/bin/env python3
# virt-ip.py script
# (c) 2016 Aleksander Alekseev
# http://eax.me/
import sys
import re
import os
import subprocess
from xml.etree import ElementTree
def eprint(str):
print(str, file=sys.stderr)
if len(sys.argv) < 2:
eprint(«USAGE: « + sys.argv[0] + » <domain>»)
eprint(«Example: « + sys.argv[0] + » freebsd10″)
sys.exit(1)
if os.geteuid() != 0:
eprint(«ERROR: you shold be root»)
eprint(«Hint: run `sudo « + sys.argv[0] + » …`»);
sys.exit(1)
if subprocess.call(«which arping 2>&1 >/dev/null», shell = True) != 0:
eprint(«ERROR: arping not found»)
eprint(«Hint: run `sudo apt-get install arping`»)
sys.exit(1)
domain = sys.argv[1]
if not re.match(«^[a-zA-Z0-9_-]*$», domain):
eprint(«ERROR: invalid characters in domain name»)
sys.exit(1)
domout = subprocess.check_output(«virsh dumpxml «+domain+» || true»,
shell = True)
domout = domout.decode(‘utf-8’).strip()
if domout == «»:
# error message already printed by dumpxml
sys.exit(1)
doc = ElementTree.fromstring(domout)
# 1. list all network interfaces
# 2. run `arping` on every interface in parallel
# 3. grep replies
cmd = «(ifconfig | cut -d ‘ ‘ -f 1 | grep -E ‘.’ | « + \
«xargs -P0 -I IFACE arping -i IFACE -c 1 {} 2>&1 | « + \
«grep ‘bytes from’) || true»
for child in doc.iter():
if child.tag == «mac»:
macaddr = child.attrib[«address»]
macout = subprocess.check_output(cmd.format(macaddr),
shell = True)
print(macout.decode(«utf-8»))
Скрипт работает как с default сетью, так и с bridged сетью, настройку которой мы рассмотрим далее. Однако на практике куда удобнее настроить KVM так, чтобы он всегда назначал гостевым системам одни и те же IP-адреса. Для этого правим настройки сети:
… примерно таким образом:
После внесения этих правок необходимо выполнить команды:
Теперь перезагружаем несколько раз гостевую систему и убеждаемся, что она всегда получает адрес 192.168.122.184.
По умолчанию виртуальные машины могут ходить в интернет, а также к ним можно приконнектится из хост-системы. В общем и целом все выглядит так, словно гостевые системы находятся за NAT. На практике же часто бывает куда удобнее иметь bridged сеть. Как она настраивается на хост-системе ранее мы уже рассматривали в заметках Туториал по контейнеризации при помощи LXCи Контейнерная виртуализация при помощи OpenVZ.
После окончания настройки правим конфиг гостевой системы. Находим в нем что-то вроде:
… и заменяем на что-то вроде:
Перезагружаем гостевую систему и проверяем, что она получила IP по DHCP от роутера. Если же вы хотите, чтобы гостевая система имела статический IP-адрес, это настраивается как обычно внутри самой гостевой системы.
Вас также может заинтересовать программа virt-manager:
Так выглядит ее главное окно:
Как видите, virt-manager представляет собой не только GUI для виртуалок, запущенных локально. С его помощью можно управлять виртуальными машинами, работающими и на других хостах, а также смотреть на красивые графички в реальном времени. Я лично нахожу особенно удобным в virt-manager то, что не нужно искать по конфигам, на каком порту крутится VNC конкретной гостевой системы. Просто находишь виртуалку в списке, делаешь двойной клик, и получаешь доступ к монитору.
Еще при помощи virt-manager очень удобно делать вещи, которые иначе потребовали бы трудоемкого редактирования XML-файлов и в некоторых случаях выполнения дополнительных команд. Например, переименование виртуальных машин, настройку CPU affinity и подобные вещи. Кстати, использование CPU affinity существенно снижает эффект шумных соседей и влияние виртуальных машин на хост-систему. По возможности используйте его всегда.
Если вы решите использовать KVM в качестве замены VirtualBox, примите во внимание, что хардверную виртуализацию они между собой поделить не смогут. Чтобы KVM заработал у вас на десктопе, вам не только придется остановить все виртуалки в VirtualBox и Vagrant, но и перезагрузить систему. Я лично нахожу KVM намного удобнее VirtualBox, как минимум, потому что он не требует выполнять команду sudo /sbin/rcvboxdrv setup
после каждого обновления ядра, адекватно работает c Unity, и вообще позволяет спрятать все окошки.
По традиции, немного ссылок по теме:
В целом, KVM произвел на меня исключительно положительное впечатление. Теперь я не понимаю, зачем все это время я мучился с Vagrant и VirtualBox, когда все уже есть в KVM и сделано куда лучше. Ну, почти. Кое-какие косяки все же имеются. Так, например, в htop гостевой системы вы можете видеть, что утилизируете CPU на 30%, хотя на хост-системе вы утилизируете все 100%. Однако мой опыт работы с виртуальными машинами свидетельствует о том, что такого рода проблемы и прочие шумные соседи возникают всегда, и еще один минорный баг в общем-то не делает в этом плане все сильно хуже.
Информация о свободном месте на жестком диске. Параметр -h нужен чтобы выводить форматирование.
df -h
Информация о размере папки.
du /var/www
Информация об установленном диске.
hdparm -Ii /dev/sda1
Авторизация от имени администратора:
sudo -s
Информация о дисках
fdisk -l
Проверка диска
sudo shutdown now - переход в single режим umount / - размонтирование диска (fdisk -l) fsck -y -f -c /dev/sda1
Проверка на битые секторы
badblocks -v /dev/XYZ > file.list - проверка e2fsck -l file.list /dev/XYZ - лечим если наши ошибки
sudo touch /forcefsck - для проверки при загруке
sudo apt-get install postgresql
Дальше настраиваем безопасность:
1. переходим в папку /etc/postgresql/{version}/main
2. открываем папку postgresql.conf
listen_addresses = ‘*’
3. открываем файл pg_hba.conf
Находим строку
host all all 127.0.0.1/32 md5
и меняем её на
host all all 0.0.0.0/0 md5
Дополнение для windows
Скачиваем приложение managment tools и создаем подключение к БД
Статьи:
Руководство по postgresql — http://help.ubuntu.ru/wiki/%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_ubuntu_server/%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85/postgresql
Права доступа — http://dba.stackexchange.com/questions/83984/connect-to-postgresql-server-fatal-no-pg-hba-conf-entry-for-host
Managment Tools — https://www.postgresql.org/ftp/pgadmin3/pgadmin4/v1.2/windows/
Скачиваем CMS
wget https://ru.wordpress.org/wordpress-4.7.2-ru_RU.tar.gz
tar -xvzf wordpress-4.7.2-ru_RU.tar.gz
sudo mkdir -p /var/www/wordpress
sudo cp -r ~/wordpress/* /var/www/wordpress/
Настраиваем SQL
mysql -u root -p
create database wordpress;
CREATE USER ‘wordpress’@’localhost’ IDENTIFIED BY ‘12345’;
GRANT ALL PRIVILEGES ON wordpress.* TO ‘wordpress’@’localhost’ IDENTIFIED BY ‘12345’;
exit
Настраиваем CMS
sudo cp /var/www/wordpress/wp-config-sample.php /var/www/wordpress/wp-config.php
Устанавливаем права
Дать права доступа к chown -R www-data:www-data /var/www/wordpress
В файле wp-config.php добавить в конце
if ( is_admin() ) {
add_filter ( ‘filesystem_method’, create_function(‘$a’, ‘return «direct»;’ ) );
define ( ‘FS_CHMOD_DIR’, 0751 );
}
Для ubuntu 14.04 и php 5 последняя поддерживаемая версия
https://ru.wordpress.org/wordpress-5.1.1-ru_RU.tar.gz
Установка не сложная все делаем по инструкции которая указана в стать выше. Просто для установки русской версии переходим на сайт http://joomla.ru/downloads и скачиваем там файл при помощи команды
wget https://downloads.joomla.org/cms/joomla3/3-6-5/Joomla_3.6.5-Stable-Full_Package.zip
затем распаковываем при помощи unzip
если приложение не установлено, то выполняем вначале sudo apt-get install unzip
unzip file.zip -d destination_folder
Чтобы просмотреть процессы запущенные в linux нужно выполнить команду
ps aux
Если нужно фильтрация. то можно воспользоваться
ps aux | grep node
где node имя фильтруемого процесса
Чтобы остановить процесс выполнить команду
kill -9 123
где 123 идентификатор процесса (второй слева при выполнении команды ps aux)
Что создать хост на сервере нужно перейти в каталог /etc/apache2/sitres-available
Создаем копию с файла 000-default.conf, например my.conf
Затем выполняем команду sudo a2ensite my
Думаю, кому-нибудь будет полезно знать, как запустить проект на Node.js.
Первым делом необходимо установить саму ноду, но об этом я писать не буду, это размусоленно на триллионах сайтов. А вот как поднять проект на русскоязычных сайтах, инфы маловато. Сам я искал инфу на ру сайтах, но в итоге все равно пришлось питаться инфой из-за бугра.
Задача состоит в следующем:
Запустить ноду.
Писать лог по ошибкам.
Если сайт падает, надо его поднять.
Ставим upstart
sudo apt-get install upstart
Предположим, у вас есть проект site.ru, и расположен он в каталоге
/var/www/nodejs/site/
Создаем файл /etc/init/site.conf
#site.conf description "node.js bin/www" author "username" start on startup stop on shutdown script export HOME="/root" echo $$ > /var/run/site.pid exec sudo -u username /usr/local/bin/node /var/www/nodejs/site/bin/www >> /var/log/site.sys.log 2>&1 end script pre-start script # Date format same as (new Date()).toISOString() for consistency echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Starting" >> /var/log/site.sys.log end script pre-stop script rm /var/run/site.pid echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Stopping" >> /var/log/site.sys.log end script Далее открываем /ect/monit/monitrc check process site with pidfile "/var/run/site.pid" start program = "/sbin/start site" stop program = "/sbin/stop site" if failed port 3000 protocol HTTP request / with timeout 10 seconds then restart
Где порт 3000, впишите свой, по умолчанию нода запускается с портом 3000.
Чтобы избавиться от порта в site.ru:3000, правим конфиг nginx /etc/nginx/nginx.conf
server { server_name site.ru www.site.ru; listen 37.143.15.183; charset UTF-8; set $root_path /var/www/nodejs/site; location / { proxy_read_timeout 120s; proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } location ~* ^/(webstat|awstats|webmail|myadmin|pgadmin)/ { proxy_pass http://37.143.15.183:81; proxy_redirect http://37.143.15.183:81/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } location @fallback { proxy_pass http://37.143.15.183:81; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } include /usr/local/ispmgr/etc/nginx.inc; }
Перезапускаем nginx
service nginx restart
Запускаем проект
start site monit -d 60 -c /etc/monit/monitrc
Открываем site.ru, и если все в порядке, увидите приветствие от Express.
ПС. более подробно можно почитать на забугорном сайте
http://howtonode.org/deploying-node-upstart-monit