Организация удаленого доступа по VNC (RDP) к гостевым системам VirtualBOX без установки Extension Pack

Гарантированно работает на версии 4.3, на остальных не проверялось.
Для начала необходимо остановить машину.
Запускаем поддержку VNC:
vboxmanage modifyvm [vm_name] --vrde on
Указываем пароль для подключения:
vboxmanage modifyvm [vm_name]--vrdeproperty vncppassword=[some_password]
Указываем порт для подключения:
vboxmanage modifyvm [vm_name] --vrdeport [some_port]
Для каждой гостевой системы должен быть отдельный порт.
Подключаемся с помощью любого vnc-клиента, например xtightvncviewer [hv_ip]:[some_port]

перенос гостевой системы VirtualBOX с одного хоста на другой.

Есть два, гипервизора VirtualBOX. Требуется требуется скопировать одну из гостевых ОС с одного хоста, на другой.

На исходном хосте.

• Сохраняем состояние ВМ - vboxmanage controlvm [vm_name] savestate
• Экспортируем ВМ в файл OVA - vboxmanage export [vm_name] -o [ova_file_name]
• Возобновляем работу ВМ - vboxmanage startvm [vm_name] --type headless
• Копируем файл OVA на целевой хост - scp [local_ova_file_name] [remote_username]@[remote_host]:[remote_ova_file_name]

На целевом хосте:

• Импортируем ВМ из файла OVA - vboxmanage import [ova_file_name]
• Запускаем ВМ - vboxmanage startvm [vm_name] --type headless

монтирование smb в linux

sudo mount -t cifs [//HOST/SHARE] [/path/to/local/folder] -o username=[smb_user],password=[smb_pass],uid=[local_user]

• //HOST/SHARE - хост или ip smb-сервера, а так же наименование ресурса на данном сервере
• /path/to/local/folder - путь к локальному каталогу, в который будет смонтирован удаленный ресурс
• smb_user - имя пользователя на smb-сервере, имеющего права доступа к указанному ресурсу
• smb_pass - пароль пользователя на smb-сервере, имеющего права доступа к указанному ресурсу
• local_user - имя локального пользователя, которому будет предоставлен доступ к каталогу, в который смонтирован smb-ресурс

Настройка PowerMizer проприетарного драйвера NVIDIA на Linux.

Имеется:

1. ОС Debian jessie (3.16.0-4-amd64)
2. Видеоадаптер, определенный системой как GeForce GTX 550 Ti
3. Проприетарный драйвер NVIDIA установленный из репозитория Debian с помощью dkms (NVIDIA GLX Module  340.65)
4. X window system без DE. WM и прочие требуемые приложения запускаются с помощью ~/.xinitrc

Преамбула:

Так как в качестве WM используется kwin (с включенными свистоперделками), работа PowerMizer вызывает известный дискомфорт, при этом перевод PowerMizer  в режим повышенной производительности приводит к повышению, как температуры графического процессора, так и уровня паранойи по поводу его скорого выхода из строя.

Задача: 

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

Действия:

Из этого сайта я выяснил, что утилитой nvidia-settings можно управлять с помощью консольных команд (ранее я думал, что это чисто GUI, а там еще оказывается и man есть, вполне вменяемый). Например команда вот такого вида nvidia-settings -a {DISPLAY}/GpuPowerMizerMode=1 включает режим повышенной производительности. Вместо {DISPLAY} необходимо подставить идентификатор экрана X-сервера, который можно узнать например из второй строки выводы glxinfo, хотя, скорее всего, в случае с одним подключенным монитором, он всегда будет равен :0.
Таким образом, добавив в наш .xinitrc, вышеуказанную команду, мы будем переводить видеоадаптер в режим повышенной производительности при запуске x-server от имени конкретного пользователя. Осталось научить нашу видеокарточку переходить в адаптивный режим в случае простоя.
Самое очевидное, было бы воспользоваться тем же механизмом, с помощью которого запускается хранитель экрана, но я не знаю как он запускается, зато знаю, что можно получить время простоя с помощью команды w, а знающие люди с лора подсказали, что это еще проще сделать с помощью маленькой утилитки xprintidle, ну а дальше дело техники как говорится.
Я нарисовал вот такой вот скриптик:

PM_check () #Провека состояния powermizer
{ if [ $(nvidia-settings -q :0/GpuPowerMizerMode|sed '2!D'|awk {'print $4'}|sed s/.$//) -eq $1 ]; then idle_check; else nvidia-settings -a :0/GpuPowerMizerMode=$1 && idle_check; fi }

idle_check () #Провека времени простоя
{ sleep 1 && if [ $(xprintidle) -gt 30000 ]; then PM_check 0; else PM_check 1; fi }

if [ -n "$(ps aux | grep xserver | grep -v grep)" ]; then idle_check; fi #Проверяем, запущен ли x-server

В данном случае режим работы видеокарты переключается на адаптивный, через 30 секунд простоя.
А на этом сайте знающий человек подсказал как сделать из скрипта практически демона:), добавляем в crontab ежеминутный запуск нашего скрипта, через flock примерно таким образом: *   *   *   *   *   flock -n /tmp/pmc.lock -c 'bash /path/to/script/pmc.sh'  и видим, что ничего не работает:( В логах crontab жалуется, что не может подключиться к x-серверу и мы понимаем, что дело по всей видимости в переменных окружения. Недолгое гугление решает нашу проблему, мы меняем запись в кроне *   *   *   *   *   flock -n /tmp/pmc.lock -c 'export DISPLAY=:0 && bash /patch/to/script/pmc.sh' и радуемся жизни.

Восстановление данных с ZFS, на аппаратном рейде 10

Имеется:

Сервер Supermicro 825-7 с шестью SATA дисками ST31000524NS объеденными в RAID 10 средствами интегрированного raid-контроллера.

В качестве ОС установлена FreeBSD 8.2.

На сервере развернут ряд web-сервисов.

Больше никакой информации нет.

Преамбула:

По словам очевидцев. В какой-то момент, сервер перестал загружать ОС, при этом, судя по светодиодной и звуковой индикации один из жестких дисков вышел из строя (при очередной перезагрузке, напротив одного из дисков загорелся красный светодиод и зазвучал длинный звуковой сигнал).

К моменту моего прибытия на место аварии, никакой индикации не наблюдалось, однако ОС все равно не желала загружаться должным образом. Есть предположение, что контроллер автоматически провел ребилд массива и успокоился, однако часть данных все же была потеряна, как потом подтвердится.

Задача:

Восстановить работоспособность сервера, или, как минимум, восстановить большую часть данных.

Действия:

Raid-контроллер Adaptec, сообщил, что массив в полном порядке.

В процессе загрузки ОС сообщает, что не может смонтировать корневой раздел и предлагает произвести монтирование вручную, однако при нажатии любой клавиши происходит kernel panic и система зависает намертво.

В качестве загрузочного диска был выбран frenzy-1.4-lite. После загрузки с livecd, gpart list показал, что на жестких дисках имеется три раздела: freebsd-boot, freebd-swap и freebsd-zfs. Судя по размеру, все данные были как раз в zfs. Этот zfs меня несколько напугал, но как всегда, великий и ужасный web, пришел на выручку. К сожалению я не помню на каких именно ресурсах искал нужную информацию, поэтому просто приведу порядок действий.

Команда zdb -l /patch/to/block/device позволяет прочитать так называемые метки zfs, из файла блочного устройства раздела. Там много всякого разного, но меня интересовало только имя пула. Теперь, зная это имя, можно импортировать пул и получить доступ к файловой системе, для этого я использовал такую команду: zpool import -o atlroot=/some/directory POOL_NAME
Теперь раздел zfs доступен для чтения и записи в каталоге /some/directory
На этом все, пытаться восстанавливать загрузку ОС я не стал, так как часть данных все же была утеряна, например в usr не осталось ничего кроме home (что он там вообще делал не знаю, возможно это нормальное положение вещей для FreeBSD), меня интересовали только базы mysql, которые к счастью сохранились в полном объеме, в /var/db/mysql и сайты, которые так же лежали в /var/www/