Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Отличная статья, как раз на днях понадобилось пробрасывать usb-токен в контейнер.
Помимо описанного варианта поднятия иксов для скайпа есть вариант использования xvfb, он особых махинаций не требует.
Помимо описанного варианта поднятия иксов для скайпа есть вариант использования xvfb, он особых махинаций не требует.
Господа, сливающие карму, аргументируйте пожалуйста.
А я тут как раз сегодня резервное копирование поднастраивал. Могу поделиться несколькими ньюансами.
1. Если у вас контейнер на локальном LVM, то режим бэкапа снимком (mode snapshot) не будет работать если хранилище бэкапов находится на том же разделе LVM, а бэкап автоматически будет производиться в режиме suspend, что выведет контейнер в оффлайн на некоторое время. Последнее может легко пройти незамеченным для администратора, но не для аптайма с точки зрения внешних наблюдателей. Проверьте себя:
2. В интерфейсе proxmox опущено несколько очень полезных опций бэкапа утилиты vzdump, но их можно дописать вручную в /etc/cron.d/vzdump, причем у меня они даже сохраняются после изменения задачи через вебморду (хотя лучше всё равно проверять):
3. send-backups-to-remote-host.sh
Полный список доступных событий и переменных можно посмотреть в файле /usr/share/doc/pve-manager/examples/vzdump-hook-script.pl.
1. Если у вас контейнер на локальном LVM, то режим бэкапа снимком (mode snapshot) не будет работать если хранилище бэкапов находится на том же разделе LVM, а бэкап автоматически будет производиться в режиме suspend, что выведет контейнер в оффлайн на некоторое время. Последнее может легко пройти незамеченным для администратора, но не для аптайма с точки зрения внешних наблюдателей. Проверьте себя:
grep -ir "trying 'suspend' mode instead" /var/log/vzdump/2. В интерфейсе proxmox опущено несколько очень полезных опций бэкапа утилиты vzdump, но их можно дописать вручную в /etc/cron.d/vzdump, причем у меня они даже сохраняются после изменения задачи через вебморду (хотя лучше всё равно проверять):
--exclude-path "/var/www/temp-or-big-files/"--script /root/bin/send-backups-to-remote-host.sh3. send-backups-to-remote-host.sh
#!/bin/bash
RSYNC_TARGET="limited-user@example.com:/backups/incoming/"
if [ "$1" == "backup-end" ]; then
/usr/bin/rsync --bwlimit 5000 -a $TARFILE $RSYNC_TARGET
fiПолный список доступных событий и переменных можно посмотреть в файле /usr/share/doc/pve-manager/examples/vzdump-hook-script.pl.
4. Закрытие security issue связанного с п.3 (немного оффтоп).
Т.к. бэкапы на удаленную машину производятся автоматически, на сервере proxmox остается ssh-ключ. Значит, с помощью него злоумышленник, получивший доступ к серверу, может попытаться испортить бэкапы на удаленной машине. Чтобы не допустить этого, можно использовать замечательный демон incron, использующий механизм ядра inotify, а значит — почти бесплатный и запускающий нужное нам действие ровно в тот миг, когда нам нужно:
Incron перенял многое у cron:
Теперь пропишем в открывшийся файл запуск скрипта (/sbin/protect_backups.sh) с передачей в качестве параметра полного пути к файлу ($@$#) при событии закрытия файла на запись (IN_CLOSE_WRITE) для пути /backups/incoming/.
В скрипте /sbin/protect_backups.sh мы забираем у юзера, закачивающего бэкапы, возможность их изменять после окончания закачки:
Не забываем делать скрипты исполняемыми:
Теперь сервер с proxmox по cron'у ночью запускает резервирование контейнера, в ходе которого архив автоматически доставляется на удаленную машину. После окончания доставки, удаленная машина защищает бэкап от возможных инсинуаций. В итоге получилась безопасная, легкая, понятная и ненавязчивая система резервного копирования контейнеров без применения каких-либо спец.средств (считаю, что incron должен быть в стандартной поставке дистрибутивов linux).
sudo apt-get install incronIncron перенял многое у cron:
sudo incrontab -eТеперь пропишем в открывшийся файл запуск скрипта (/sbin/protect_backups.sh) с передачей в качестве параметра полного пути к файлу ($@$#) при событии закрытия файла на запись (IN_CLOSE_WRITE) для пути /backups/incoming/.
/backups/incoming/ IN_CLOSE_WRITE /sbin/protect_backups.sh $@$#В скрипте /sbin/protect_backups.sh мы забираем у юзера, закачивающего бэкапы, возможность их изменять после окончания закачки:
#!/bin/sh
/bin/chmod 660 $1
/bin/chown regular-user:regular-user $1Не забываем делать скрипты исполняемыми:
sudo chmod a+x /sbin/protect_backups.shТеперь сервер с proxmox по cron'у ночью запускает резервирование контейнера, в ходе которого архив автоматически доставляется на удаленную машину. После окончания доставки, удаленная машина защищает бэкап от возможных инсинуаций. В итоге получилась безопасная, легкая, понятная и ненавязчивая система резервного копирования контейнеров без применения каких-либо спец.средств (считаю, что incron должен быть в стандартной поставке дистрибутивов linux).
Отличное дополнение, если о первом пункте знал и просто делаю перекрестный бэкап + бэкап на общедоступный сторадж, то о безопасности бэкапов на удаленном хосте даже не задумался. Утащил к себе в заметки.
Кстати, сегодня поутру выяснилось, что рецепт с incron выше нерабочий, т.к. rsync сначала закачивает архив во временный файл, а потом переименовывает в оригинальное название, а до incron'а доходит событие со старым названием файла. Чтобы rsync работал в этом смысле как cp или scp, нужно запускать его с опцией --inplace. Чуть менее хорошее, но тоже рабочее решение — мониторить incron'ом событие IN_MOVED_TO.
Отлаживать inotify можно так:
Отлаживать inotify можно так:
sudo inotifywait -m /backups/incoming/
В интерфейсе proxmox опущено несколько очень полезных опций бэкапа утилиты vzdump
Кстати о какой версии речь? А то я вот что то в третьей потерял вообще возможность добавить задачу автоматического бэкапа.
Не вижу ее в упор. Не прикрутили чтоль. В 1.9 была.
Как починить загрузку бекапов? Опять таки последняя версия ProxMox. Без кластера, локальное хранилище. Бэкапы для хранилища разрешил, закачать через веб-морду не дает. Точнее закачивать поначалу закачивает, ждешь себе, а в конце сообщает — извини бэкапы не разрешены для этого хранилища. Хотя они разрешены. Гипревизор перезапускал. В итоге добавил к файлам расширение iso и закачал как образы, потом ручками мувал на узле.
Скачать бэкапы, кстати тоже низзя. И апач выпиляли. Пытался подкладывать их в директорию с картинками интерфейса — фиг все равно не дает скачать. Плюнул поставил vsftpd. Забодал меня этот 3-ий проксмокс. Такое впечатление, что это специально для платной поддержки сделано.
Второй у меня на одном объекте уходит время от времени(раз в квартал где то) в прострацию. К сожалению добраться туда и выяснить причину не могу. Там жмут на кнопку ресет и все подымается.
Самый стабильный пока 1.9.
Проброс nfs на каком контейнере? Для 1.9 и ubuntu10.04 нифига у меня это не работало. nfs-common не ставился в контейнер. Что то там вешалось мертво. Выходил из положения через маунт nfs в гипервизор, а в контейнер пробрасывал через bind. Но при таком способе при бэкапе контейнера все разваливается. Надо снова биндить.
Скачать бэкапы, кстати тоже низзя. И апач выпиляли. Пытался подкладывать их в директорию с картинками интерфейса — фиг все равно не дает скачать. Плюнул поставил vsftpd. Забодал меня этот 3-ий проксмокс. Такое впечатление, что это специально для платной поддержки сделано.
Второй у меня на одном объекте уходит время от времени(раз в квартал где то) в прострацию. К сожалению добраться туда и выяснить причину не могу. Там жмут на кнопку ресет и все подымается.
Самый стабильный пока 1.9.
Проброс nfs на каком контейнере? Для 1.9 и ubuntu10.04 нифига у меня это не работало. nfs-common не ставился в контейнер. Что то там вешалось мертво. Выходил из положения через маунт nfs в гипервизор, а в контейнер пробрасывал через bind. Но при таком способе при бэкапе контейнера все разваливается. Надо снова биндить.
По поводу 3.1 и бэкапов. Я один раз попробовал закачать браузером — PVE тоже выдал какую-то ошибку, но я, честно говоря, вообще не расстроился, т.к. думаю что доверять браузеру такие вещи нельзя. Тем более, что нет докачки при обрыве.
То, что теперь обходятся без Apache наверное скорее плюс. При желании его же можно поставить также как и vsftpd. Правда, я бы не ставил ни того, ни другого, т.к. это значит передавать нешифрованые бэкапы по нешифрованому каналу. Если не заморачиваться с HTTPS или FTPS, конечно. По-моему, SFTP через SSH намного безопаснее, проще, удобнее и быстрее.
То, что теперь обходятся без Apache наверное скорее плюс. При желании его же можно поставить также как и vsftpd. Правда, я бы не ставил ни того, ни другого, т.к. это значит передавать нешифрованые бэкапы по нешифрованому каналу. Если не заморачиваться с HTTPS или FTPS, конечно. По-моему, SFTP через SSH намного безопаснее, проще, удобнее и быстрее.
Писал для версии 3.1 (актуальная на сегодня).
По бэкапам, первое разрешаем для локального хранилища вообще работать с бэкапами:
Датацентр -> Хранилище -> выбрать локальное -> отметить в списке бэкапы.
Затем переходим в само хранилище и можем закачать бэкап через web интерфейс.
Хотя лично я практически все делаю через ssh, в том числе переброс бэкапов.
В 1.9. очень уж древнее ядро и например завести gsm модемы (huawei e173) в качестве шлюза внутри контейнера OpenVZ нормально не выйдет, получим кучу проблем с передачей голоса, так что нужно свежее ядро.
nfs пробрасывал в контейнеры Debian 6,7 CentOs 5,6 проблем не возникало. Я использую nfs для хранения больших неизменяемых файлов либо большого количества файлов вне контейнера, чтоб они не попадали в периодический бэкап контейнера, например, записи разговоров телефонии, записи камер видеонаблюдения и т.п. Убунту у себя в инфраструктуре не использую, с чем связаны проблемы не скажу, но может ее стоит обновить до актуальной LTS.
По бэкапам, первое разрешаем для локального хранилища вообще работать с бэкапами:
Датацентр -> Хранилище -> выбрать локальное -> отметить в списке бэкапы.
Затем переходим в само хранилище и можем закачать бэкап через web интерфейс.
Хотя лично я практически все делаю через ssh, в том числе переброс бэкапов.
В 1.9. очень уж древнее ядро и например завести gsm модемы (huawei e173) в качестве шлюза внутри контейнера OpenVZ нормально не выйдет, получим кучу проблем с передачей голоса, так что нужно свежее ядро.
nfs пробрасывал в контейнеры Debian 6,7 CentOs 5,6 проблем не возникало. Я использую nfs для хранения больших неизменяемых файлов либо большого количества файлов вне контейнера, чтоб они не попадали в периодический бэкап контейнера, например, записи разговоров телефонии, записи камер видеонаблюдения и т.п. Убунту у себя в инфраструктуре не использую, с чем связаны проблемы не скажу, но может ее стоит обновить до актуальной LTS.
вот именно показанное на картинках не работает.
я тоже делал перепроброс бэкапов по ssh, только под виндой утилитой psftp очень медленно получается.
может psftp виновата а не ssh.
я тоже делал перепроброс бэкапов по ssh, только под виндой утилитой psftp очень медленно получается.
может psftp виновата а не ssh.
Надо сделать маршрутизатор VLAN'ов в виртуалке.
Т.е. реализовать схему router-on-a-stick.
Как пучок VLAN'ов пробросить в контейнер или виртуалку?
Т.е. реализовать схему router-on-a-stick.
Как пучок VLAN'ов пробросить в контейнер или виртуалку?
Проброс виланов в контейнер делается в 2 этапа. Покажу на примере виланов 151,152,666
На гипервизоре:
В /etc/network/interfaces
В контейнере:
Есть и другой вариант проброса виланов, но я использую такой, так-как при нем можно использовать удобно один и тот-же вилан в нескольких виртуалках, что часто нужно.
На гипервизоре:
В /etc/network/interfaces
добавляем
Устанавливаем поддержку виланов
Затем применяем их
Проверяем что интерфейсы поднялись через ifconfig
Затем в вебморде выбираем нужный контейнер, идем на закладку сеть(network), добавляем сетевое оборудование, примерно как на скриене
в качестве бриджа выбираем интерфейс с нужным виланом.
auto vlan151
iface vlan151 inet manual
vlan_raw_device eth0
auto vlan152
iface vlan152 inet manual
vlan_raw_device eth0
auto vlan666
iface vlan666 inet manual
vlan_raw_device eth0
auto vmbr151
iface vmbr151 inet static
address 0.0.0.0
netmask 255.255.255.255
bridge_ports vlan151
bridge_stp off
bridge_fd 0
auto vmbr152
iface vmbr152 inet static
address 0.0.0.0
netmask 255.255.255.255
bridge_ports vlan152
bridge_stp off
bridge_fd 0
auto vmbr666
iface vmbr666 inet static
address 0.0.0.0
netmask 255.255.255.255
bridge_ports vlan666
bridge_stp off
bridge_fd 0
Устанавливаем поддержку виланов
apt-get install vlan
Затем применяем их
ifup vlan151
ifup vlan152
ifup vlan666
Проверяем что интерфейсы поднялись через ifconfig
Затем в вебморде выбираем нужный контейнер, идем на закладку сеть(network), добавляем сетевое оборудование, примерно как на скриене
в качестве бриджа выбираем интерфейс с нужным виланом.
В контейнере:
добавляем
Просто настройки на интерфейсе, которые должны быть на вилане, пример для контейнера на debian
В /etc/network/interfaces.tail
Затем
Файл *.tail нужен для того, чтоб если мы изменим настройки сети в контейнере через web интерфейс, сохранить настройки виланов внутри контейнера.
В /etc/network/interfaces.tail
auto eth1
iface eth1 inet static
address 10.7.10.5
netmask 255.255.255.0
Затем
cat /etc/network/interfaces.tail >> /etc/network/interfaces
Файл *.tail нужен для того, чтоб если мы изменим настройки сети в контейнере через web интерфейс, сохранить настройки виланов внутри контейнера.
Есть и другой вариант проброса виланов, но я использую такой, так-как при нем можно использовать удобно один и тот-же вилан в нескольких виртуалках, что часто нужно.
Может быть кто знает почему не срабатывает автоматический бекап контейнеров, в которых есть примонтированные ресурсы NFS. Ошибка такая:
Backup of VM 118 failed — command 'vzctl --skiplock chkpnt 118 --suspend' failed: exit code 16
Другие контейнеры бекапятся.
Backup of VM 118 failed — command 'vzctl --skiplock chkpnt 118 --suspend' failed: exit code 16
Другие контейнеры бекапятся.
Покажите полный вариант ошибки из лога, скорее всего что-то не размонтируется, но по этой строке не угадать. Старые версии ругались на cpt лечилось командой modprobe vzcpt и добавлением модуля в загрузку, но если версия свежая нужен полный лог.
Оказалось в логах nginx тупит:
Jan 25 01:33:34 INFO: suspend vm
Jan 25 01:33:34 INFO: Setting up checkpoint…
Jan 25 01:33:34 INFO: suspend…
Jan 25 01:33:37 INFO: Can not suspend container: Resource temporarily unavailable
Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
Jan 25 01:33:37 INFO: Error: suspend is impossible now.
Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
Jan 25 01:33:37 INFO: Error: suspend is impossible now.
Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
Jan 25 01:33:37 INFO: Error: suspend is impossible now.
Jan 25 01:33:37 INFO: Checkpointing failed
Jan 25 01:33:42 ERROR: Backup of VM 104 failed — command 'vzctl --skiplock chkpnt 104 --suspend' failed: exit code 16
Jan 25 01:33:34 INFO: suspend vm
Jan 25 01:33:34 INFO: Setting up checkpoint…
Jan 25 01:33:34 INFO: suspend…
Jan 25 01:33:37 INFO: Can not suspend container: Resource temporarily unavailable
Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
Jan 25 01:33:37 INFO: Error: suspend is impossible now.
Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
Jan 25 01:33:37 INFO: Error: suspend is impossible now.
Jan 25 01:33:37 INFO: Error: task 724055,29828(nginx) is traced. Checkpointing is impossible.
Jan 25 01:33:37 INFO: Error: suspend is impossible now.
Jan 25 01:33:37 INFO: Checkpointing failed
Jan 25 01:33:42 ERROR: Backup of VM 104 failed — command 'vzctl --skiplock chkpnt 104 --suspend' failed: exit code 16
Ну теперь думаю и помощь не нужна, сами подправите nginx
дело в том что я очень понимаю какая с ним может быть проблема и как его подправить, если вам известны такого рода ошибки, пожалуйста подскажите
В самом контейнере nginx завершается нормально? В его логах при завершении ошибок никаких нет? Скорее всего если он завершается дольше определенного времени, то истекает время таймаута на завершение виртуалки и бэкап не запускается. Если nginx ссылается на файлы, которые находятся на nfs, возможно nfs завершается раньше и это мешает нормально завершиться nginx-у. Попробуйте выключить контейнер вручную и посмотрите как долго она завершается и какие ошибки при этом идут.
Да, nginx без проблем останавливается. Но я не пойму вот чего, ведь в процессе бекапа не происходит полного выключения контейнера, а только приостановка, и в этом случае система не получает сигнала к выключению и не гасит работающие процессы. Как следствие и nginx выключаться не должен. Или я чего то не понимаю?
Зависит от режима бэкапа, как писали выше
Попробуйте остановить nginx и провести бэкап вручную, ошибки быть недолжно. Хотя долго можно гадать что происходит, надо подробно смотреть логи контейнера.
1. Если у вас контейнер на локальном LVM, то режим бэкапа снимком (mode snapshot) не будет работать если хранилище бэкапов находится на том же разделе LVM, а бэкап автоматически будет производиться в режиме suspend, что выведет контейнер в оффлайн на некоторое время.
Попробуйте остановить nginx и провести бэкап вручную, ошибки быть недолжно. Хотя долго можно гадать что происходит, надо подробно смотреть логи контейнера.
А покажите содержимое dmesg в момент этой ошибки? Это либо баг OpenVZ либо фича OpenVZ :)
Здравствуйте товарищи. Если уж такая тема то хотел спросить никто не знает как поменять пароль скриптом из консоли
сама команда вот такая
Но можно всё поменять только в ручную. Вот такое не проходит
сама команда вот такая
pveum passwd user@pveНо можно всё поменять только в ручную. Вот такое не проходит
<code>echo -e "new_password\nnew_password" | pveum passwd user@pve Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OpenVZ в Proxmox, заметки на полях