Автоматизация для бедных. Часть 2 – отсылка файлов на SFTP

Первая часть была о том, как простенько сделать автоматическую отправку документов с приложением в виде шифрованных архивов ZIP. Пока заметка писалась, один из партнеров согласился открыть доступ по SFTP.
Офисные сотрудники и протоколы Интернета по определению не совместимы, поэтому даже такую несложную операцию лучше автоматизировать.
Конфигурация серверов остается полностью той же, добавляется один скрипт пересылки файлов, дополнительная задача в crontab и пару рабочих каталогов. Для использования SFTP в скриптах необходимо, чтобы вход на удаленный сервер проходил без пароля, по ключу. Как настроить такую удобную штуку, я писал здесь 10 лет назад.

1. Структура каталогов и рабочие файлы
/var/transfer/partner2/
/var/transfer/partner2/out/ <- очередь на пересылку
/var/transfer/partner2/backup/ <- копии отправленных файлов
/var/transfer/partner2/transfer <- скрипт отсылки
/var/transfer/partner2/sftp.job <- батник для sftp

2. Скрипт отсылки
#!/bin/sh

# Find and deliver files to Partner2

src=/mnt/company/#secure_transfer_partner2/
dst=/var/transfer/partner2/out/
bkp=/var/transfer/partner2/backup/

# Только файлы старше 3 минут, игнорировать каталоги, подкаталоги и скрытые dot-файлы
/usr/bin/find $src -maxdepth 1 -not -path '*/\.*' -mmin +3 -type f -exec mv '{}' $dst \;
/usr/bin/sftp -b /var/transfer/partner2/sftp.job company@ftp.partner2.com
if [ $? -eq 0 ]
then
mv $dst/* $bkp/
fi

3. Батник для sftp
rat@assistant:~$ cat /var/transfer/partner2/sftp.job
lcd /var/transfer/partner2/out
cd /in
put *

Кстати, одним бантиком можно файлы положить, забрать, перенести. Причем, из множества каталогов.

4. Crontab
rat@assistant:~$ cat /etc/cron.d/securetransfer
# /etc/cron.d/securetransfer: crontab entry to deliver files to Partner2 SFTP

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

*/5 * * * * root /usr/bin/test -x /var/transfer/partner2/transfer && /var/transfer/partner2/transfer >/dev/null 2>&1

Логирование, нотификации передающей и принимающей сторонам не включены, но в планах.

Теперь небольшой хак как использовать sftp в скриптах, но на принимающей стороне нет возможности прописать свой публичный ключ. Есть утилитка sshpass, которая позволяет подать пароль для ssh, sftp или scp из переменной, из файла или (для безмозглых) в открытом виде.
rat@assistant:~$ sudo apt-get update && sudo apt-get install sshpass

Тогда вызов SFTP из скрипта без ручного ввода пароля может выглядеть так:
rat@assistant:~$ /usr/bin/sshpass -f ~/.partner2 /usr/bin/sftp -b ~/partner2_sftp.job customer@ftp.partner2.com, где:
~/.partner2 – пароль к аккаунту customer@ftp.partner2.com, -f – чтение из файла;
~/partner2_sftp.job – батник со списком sftp-команд, например:
lcd /var/transfer/partner2/out
cd /in
put *

SCP в таком случае выглядит предпочтительнее, но, если удаленный сервер сконфигурирован “sftp only”, scp и ssh работать не будут.

Еще пара любопытных примеров как положить или скачать отдельный файл с удаленного сервера по sftp, не вводя дополнительных команд:
Скачать: sftp {user}@{host}:{remoteFileName} {localFileName}
Положить: sftp {user}@{host}:{remote_dir} <<< $'put {local_file_path}'

Пример взят со StackOverflow в "Single Line sftp from Terminal".

Автоматизация для бедных. Часть 1 – отсылка почты с шифрованными приложениями

В соответствии с требованиями европейской регулы по защите данных GDPR данные частных лиц не могут передаваться в публичной сети в открытом виде. Это в первую очередь относится к операторам данных. Если необходимо передать информацию третьей стороне, то она должна быть в защищенном виде.
Пришлось помочь одной дружественной фирме. У них обмен данными с партнерами идет по электронной почте, и теперь вся информация, содержащая персональные данные клиента, должна быть зашифрована. Самое простое – пересылка шифрованных архивов ZIP. Несмотря на слабость алгоритмов шифрования ZIP, использование длинных сложных паролей делает атаку перебором малопривлекательной – данные не стоят ресурсов, необходимых для взлома. Но шифровать файлы вручную с правильным ключом (партнеров > 10) – то еще занятие. Уровень ошибок и время, уходящее на вроде простую операцию – неадекватно высокие.
Идея автоматизации очень простая – на сервере документов (Windows Server) делаются папки для каждого партнера, куда сотрудники складывают документы, которые необходимо зашифровать и отослать партнерам, а все автоматические задачи выполняет маленький офисный “сервер” под Linux.

Как поставить и настроить сервер (в данном случае подойдет и старый ноутбук, и Raspberry Pi) написаны тысячи статей разной степени полезности. Поэтому примем, что настроенный сервер у нас есть, дистрибутив Linux – Debian или Ubuntu. Так же у нас есть сторонний SMTP сервер, через который будем отправлять почту.

Задача – периодически заглядывать в папку и, если там что-то есть, зазимовать это “что-то” с паролем и отправить заданному адресату по электронной почте. Так как файловая система удаленная (cifs), мониторить ее события по inotify не получится, придется опрашивать по расписанию.

1. Как подмонтировать файловую систему с Windows Server
Необходимо добавить информацию о новой файловой системе в /etc/fstab:
# Company documents
//172.16.171.10/company /mnt/company cifs credentials=/etc/.credentials 0 0

Раньше тип файловой системы указывался как smbfs, но эти времена прошли.
Файл /etc/.credentials содержит всю информацию для подключения к “шаре” Windows Server:
rat@assistant:~$ sudo cat /etc/.credentials
domain=domainname
username=username
password=userpassword

Пользователь должен иметь права на запись и удаление файлов.

После того, как информация добавлена, подключим новую файловую систему:
rat@assistant:~$ sudo mount -a

Если все настроено правильно, новая файловая система будет доступна:
rat@assistant:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 989M 0 989M 0% /dev
tmpfs 202M 22M 180M 11% /run
/dev/sda5 9.1G 6.2G 2.5G 72% /
tmpfs 1007M 124K 1007M 1% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 1007M 0 1007M 0% /sys/fs/cgroup
/dev/sda6 136G 25G 105G 19% /var
tmpfs 202M 8.0K 202M 1% /run/user/1000
//172.16.171.10/company 80G 30G 51G 38% /mnt/company

2. Как настроить компоненты почтовой системы.
Для отправки почты понадобятся mutt и ssmtp.
rat@assistant:~$ sudo apt-get update && sudo apt-get install ssmtp mutt

Mutt – отличный консольный почтовый клиент, а sSMTP – хитрая штука, которая прикидывается полноценным почтовым сервером, но для операций использует ресурсы стороннего сервера (Google, Yandex, etc.). Настраивать еще один почтовый сервер и заботиться о его безопасности в наши планы не входит. Тем более, что наш сервер “assistant” находится далеко за брандмауэром и NAT:
rat@assistant:~$ ifconfig enp1s0
enp1s0 Link encap:Ethernet HWaddr 00:0f:1f:ab:c3:9c
inet addr:192.168.88.3 Bcast:192.168.88.255 Mask:255.255.255.0

sSMTP настраивается тривиально, вся конфигурация в одном файле, обычно /etc/ssmtp/ssmtp.conf. Реверсные алиасы не трогаем.
rat@assistant:~$ sudo cat /etc/ssmtp/ssmtp.conf|grep -v '#'
root=postmaster
rewriteDomain=domainname.lv
FromLineOverride=YES
mailhub=mail.provider.lv:587
AuthUser=robot@domainname.lv
AuthPass=strongpassword

Mutt тоже потребует настройки, иначе не получится корректно указывать желаемый адрес отправителя.
Файл настройки находится в каталоге пользователя, от которого будут запускаться скрипты. В данном случае /root/.muttrc
rat@assistant:~$ sudo cat /root/.muttrc
set content_type="text/html"
set realname="CompanyName Accounting"
set from="accounting@domainname.lv"

Первый параметр указывает на формат сообщения. Если форматирование и фирменный стиль не важны, можно оставить plain text, не указывая параметр content_type.

3. Структура каталогов и скрипты запуска.

Рабочие каталоги и файлы конфигурации разместим в /var/transfer/email:
/var/transfer/email/
/var/transfer/email/fetch <- скрипт обработки
/var/transfer/email/message_body <- тело письма
/var/transfer/email/partner1/ <- файлы и конфигурация для партнера
/var/transfer/email/partner1/recipient <- файл с адресом получателя
/var/transfer/email/partner1/.pswd <- понятно
/var/transfer/email/partner1/out/ <- очередь архивов на отсылку
/var/transfer/email/partner1/spool/ <- локальный спулер файлов для архивирования
/var/transfer/email/partner1/backup/ <- архив полученных и отосланных файлов (в основном на время отладки)

В текстовом редакторе создадим содержимое тела письма (простейший HTML):
rat@assistant:~$ sudo vim /var/transfer/email/message_body

Файлы recipient и .pswd содержат адрес получателя и пароль шифрования соответственно.

Скрипт архивирования и отсылки:
rat@assistant:~$ sudo vim /var/transfer/email/fetch
#!/bin/sh

# Find and fetch files for processing over email

# Partner1 #################################
pswd=`cat /var/transfer/email/partner1/.pswd`
rcpt=`cat /var/transfer/email/partner1/recipient`
src='/mnt/company/#encrypted_email_partner1/'
spool='/var/transfer/email/partner1/spool/'
out='/var/transfer/email/partner1/out/'
bkp='/var/transfer/email/partner1/backup/'

# Files only, no subfolders, older than 3 min, ignore hidden files
/usr/bin/find $src -maxdepth 1 -not -path '*/\.*' -mmin +3 -type f -exec mv '{}' $spool \;

# Files should be moved from spool to backup only on successful archiving
if [ "$(ls -A $spool)" ]
then
/usr/bin/zip -j -P $pswd $out/company_transfer_`date +\%Y\%m\%d\%H\%M\%S`.zip $spool/*
if [ $? -eq 0 ]
then
mv $spool/* $bkp
fi
fi

# Archives should be removed from outbox only on successful transfer
if [ "$(ls -A $out)" ]
then
cd $out
for i in `ls -A $out`
do
/usr/bin/mutt -s "CompanyName secure document transfer `date +\%Y\%m\%d\%H\%M`" $rcpt -a "$i" < /var/transfer/email/message_body if [ $? -eq 0 ] then mv $i $bkp fi done fi

Запуск скрипта по расписанию, каждые 5 минут:
rat@assistant:~$ cat /etc/cron.d/securemail
# /etc/cron.d/fetch: crontab entry to deliver files for encryption and sending over email

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

*/5 * * * * root test -x /var/transfer/email/fetch && /var/transfer/email/fetch >/dev/null

Если все настроено правильно, файлы будут забираться с сервера, архивироваться с паролем и отсылаться получателю, указанному в файле recipient, с адреса, указанного в .muttrc.

Логгинг добавить по вкусу. Отправку почты на CC, BCC и список адресов смотрим в документации к Mutt.
Про корректные права на каталоги, исполняемые файлы и особо чувствительные данные все и так все знают.

P.S. Скрипты в данной конфигурации работают от root'a, но, так как сторонний контент не выполняется, решение достаточно безопасное. При желании можно создать отдельного пользователя под задачи автоматизации.

Умная розетка Tp-Link Wi-Fi Smart Plug HS100

Заметка планировалась как очень краткий обзор умной розетки и использование дополнительных возможностей управления Tp-Link Wi-Fi Smart Plug HS100 по сети, а вылилась в анализ ситуации с безопасностью этих самых “умных” девайсов. И ситуация, мягко говоря, не очень хорошая.

Такие розетки нельзя использовать в сети, которую вы не контролируете, например в публичной сети или сети без шифрования (а так же WEP, WPA) или со слабым паролем. Категорически не рекомендуется использовать всю линейку Tp-Link Wi-Fi Smart Plug для подключения оборудования, неожиданное включение или выключение которого может нанести вред самому оборудованию или другому имуществу владельца (холодильники, нагреватели, насосы, и т.д.)!

Во-первых, для доступа к оборудованию не используется какая-либо идентификация. Вообще. Любое устройство в локальной сети может послать команду на включение, выключение, изменение параметров или сброс настроек.
Во-вторых, протокол передачи команд между смартфоном с установленной программой “Kasa” или облаком и розеткой использует алгоритм шифрования 16 века с известным ключом. Можно сказать, что его практически нет.

Во всех нюансах управления этими розетками разобрались до меня. В интернете полно материалов для самостоятельного чтения. Самое интересное – это, конечно же, реверс-инжениринг от softScheck

Есть 2 интересных проекта, которые позволят познакомиться с проблемами IoT поближе:

  1. iot-toolkit – набор утилит для обнаружения “умных” устройств в сети и организации атак;
  2. tplink-smartplug – клиентская часть для управления розетками TP-Link, написанная на Python;

Рабочая машина – Ubuntu Server 16.04 LTS.

Для сборки iot-tools понадобятся дополнительные библиотеки.
$ sudo apt-get update && sudo apt-get upgrade
$ sudo apt-get install clang libpcap-dev libssl-dev
$ cd ~/projects
$ git clone https://github.com/fgont/iot-toolkit.git
$ cd iot-toolkit
$ make all

Tplink-smartplug тоже забираем с GitHub, там много полезной информации:
$ cd ~/projects
$ git clone https://github.com/softScheck/tplink-smartplug.git

Посмотрим что у нас в сети (enp0s3), где-то там “умная” розетка:
$ sudo ~/projects/iot-toolkit/iot-scan -v -L -i enp0s3
192.168.88.102 # IOT.SMARTPLUGSWITCH: TP-Link HS100(EU): Wi-Fi Smart Plug: "Smart Gnome"

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

Начнем с безобидных, спросим сколько времени:
$ ~/projects/tplink-smartplug/tplink_smartplug.py -t 192.168.88.102 -c time
Sent: {"time":{"get_time":{}}}
Received: {"time":{"get_time":{"err_code":0,"year":2018,"month":8,"mday":9,"wday":4,"hour":20,"min":23,"sec":39}}}

Просмотр общей информации, запрос в виде JSON:
$ ~/projects/tplink-smartplug/tplink_smartplug.py -t 192.168.88.102 -j '{"system":{"get_sysinfo":{}}}'
Sent: {"system":{"get_sysinfo":{}}}
Received: {"system":{"get_sysinfo":{"err_code":0,"sw_ver":"1.2.5 Build 171213 Rel.101415","hw_ver":"1.0","type":"IOT.SMARTPLUGSWITCH","model":"HS100(EU)",
"mac":"50:C7:BF:XX:XX:XX","deviceId":"800665D682EB40DC3FA09799XXXXXXXXXXXXXXXX",
"hwId":"22603EA5E716DEAEXXXXXXXXXXXXXXXX","fwId":"00000000000000000000000000000000",
"oemId":"812A90EB2FCF306AXXXXXXXXXXXXXXXX","alias":"Smart Gnome","dev_name":"Wi-Fi Smart Plug",
"icon_hash":"","relay_state":1,"on_time":130083,"active_mode":"none","feature":"TIM",
"updating":0,"rssi":-81,"led_off":0,"latitude":0,"longitude":0}}}

Как поменять настройки или сбросить все можно посмотреть в документации к tplink-smartplug.
Как организовать атаку и положить сеть можно узнать из документации к iot-tools.

Несколько интересных презентаций

Дополнительная информация по взлому розеток tp-link, других устройств, рекомендации по обеспечению безопасности устройств – Hacking TP-Link Devices
Дополнительная информация от аналитиков везопасности из softScheck – Internet of (dangerous) Things

Резервное копирование сайта по расписанию (WordPress)

Настраиваем резервное копирование любимого сайтика. Сайтик расположен на дружественном shared-хостинге (Debian Linux). Но есть нюансы: администратор хостинга ничего не гарантирует. Один раз он просто сменил номер телефона и пропал на месяц. Практически целый месяц сервер был недоступен. Это не коммерческий проект, но, все равно, очень неприятно.
Есть доступ по ssh (sftp, scp) и права запускать программы.
Резервное копирование разделим на 2 этапа: создание копии на удаленном сервере и перенос в безопасное место.

Резервное копирование на удаленном сервере

Данные WordPress разделены на 2 компонента: база (в моем случае MySQL) и файлы, как картинки, так и специальные.

Создание архива, в общем виде команда такая:
$ /usr/bin/zip -v -r /home/user/site.tld.`date +%Y-%m-%dT%H:%M:%S`.zip /home/user/site.tld/htdocs

Дамп базы. Несмотря на то, что пароль и так хранится в явном виде в файле wp-config.php, светить его лишний раз не стоит.
Для запуска mysqldump без пароля создадим файл конфигурации:
$ vim ~/.my.cnf

[mysqldump]
user = mysqluser
password = mysqlpassword

Ставим корректные права на файл
$ chmod 600 ~/.my.cnf

Проверим, что все работает
$ /usr/bin/mysqldump -u mysqluser dbname > /home/user/site.tld.`date +%Y-%m-%dT%H:%M:%S`.sql

Создаем расписание срабатывания команд через crontab (особое внимание на форматирование параметров команды date!)
$ crontab -e

# m h dom mon dow command
0 3 * * 6 /usr/bin/mysqldump -u mysqluser dbname > /home/user/site.tld.`date +\%Y-\%m-\%dT\%H:\%M:\%S`.sql
5 3 * * 6 /usr/bin/zip -r /home/user/sitename.tld.`date +\%Y-\%m-\%dT\%H:\%M:\%S`.zip /home/user/site.tld/htdocs

Еженедельное копирование в субботу в 3:00 и 3:05 соответственно.

Перенос данных с удаленного сервера

Перво-наперво избавимся от необходимости вводить пароль при удаленном подключении по ssh/scp. Когда-то в древности я уже писал как настроить подключение по сертификату.

Забирать файлы будем через rsync + ssh. Порт ssh на удаленной системе нестандартный – 2222. Файлы будем перемещать, а не копировать.

$ rsync -avz --remove-source-files -e "ssh -p 2222" user@remote:site.tld.\* /home/user/backup

1. Wildcard!
2. На удаленной системе так же должен быть установлен rsync. Иначе любые попытки скачать файлы будут заканчиваться вот такой проблемой:
bash: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: remote command not found (code 127) at io.c(226) [Receiver=3.1.1]

Запись в crontab выглядит так:
$ crontab -e

# m h dom mon dow command
30 3 * * 6 /usr/bin/rsync -avz --remove-source-files -e "/usr/bin/ssh -p 2222" user@remote:site.tld.\* /home/user/backup >/dev/null 2>&1

Проблема с установкой Zabbix Agent на Windows 10

На Windows 10 Pro 64-bit Zabbix Agent не хочет устанавливаться в соответствии с официальной документацией.

c:\zabbix\bin\win64>.\zabbix_agentd.exe -c c:\zabbix\conf\zabbix_agentd.conf --install
zabbix_agentd.exe [5104]: ERROR: cannot connect to Service Manager: [0x00000005] Access is denied.

Ошибка появляется несмотря на достаточные права у пользователя, от которого идет установка.

Для корректной установки все действия необходимо проводить с правами Администратора:
Search -> cmd -> Run as Administrator
c:\zabbix\bin\win64>.\zabbix_agentd.exe --config "c:\zabbix\conf\zabbix_agentd.conf" --install
zabbix_agentd.exe [4260]: service [Zabbix Agent] installed successfully
zabbix_agentd.exe [4260]: event source [Zabbix Agent] installed successfully
c:\zabbix\bin\win64>.\zabbix_agentd.exe --start
zabbix_agentd.exe [3684]: service [Zabbix Agent] started successfully

Создание виртуальных машин VirtualBox из командной строки. Ubuntu Server 16.04 LTS и Windows 10 Pro

Для домашней “лаборатории” понадобилось поднять 2 виртуальные машины – Windows 10 как рабочая станция и Ubuntu Server 16.04 LTS. Точнее, VM с Windows переносилась с OS X, где она стала есть слишком много места, да и старенький MacBook Air с 4ГБ памяти не очень хорошо справляется с подобным довеском. По-этому было решено машины перенести в домашнее “облако” и работать через RDP. “Облаком” выступил тоже достаточно потертый жизнью Dell Inspiron, набитый памятью под завязку. PAE, аппаратная виртуализация и 64 бита оказались очень кстати.

$ VM='ubuntu1604lts'
$ mkdir /data/vm/$VM
$ cd /data/vm/$VM

Образ диска, динамический до 50ГБ:
$ VBoxManage createhd --filename $VM.vdi --size 50000

Список поддерживаемых типов систем:
$ VBoxManage list ostypes

Создаем VM Ubuntu 64–bit с указанием базового каталога. В противном случае все окажется в домашнем каталоге:
$ VBoxManage createvm --name $VM --ostype Ubuntu_64 --register --basefolder /data/vm

Что получилось:
$ VBoxManage showvminfo $VM

Укажем размер памяти, укажем порт RDP для начальной установки, подключим диски по SATA, укажем желаемый чипсет и создадим сетевой интерфейс через бриджирование, по-старинке. Если есть графический интерфейс, то там VirtualBox легко бриджируется с любым адаптером, но вот на безголовом сервере разбираться с этим не хотелось.
$ VBoxManage modifyvm $VM --memory 4096 --boot1 dvd --vrde on --vrdeport 5001
$ VBoxManage storagectl $VM --name "ubuntu1604_SATA" --add sata
$ VBoxManage storageattach $VM --storagectl ubuntu1604_SATA --port 1 --type hdd --medium /data/vm/$VM/$VM.vdi
$ VBoxManage storageattach $VM --storagectl ubuntu1604_SATA --port 0 --type dvddrive --medium /data/install/ubuntu-16.04.4-server-amd64.iso
$ VBoxManage modifyvm $VM --chipset ich9
$ VBoxManage modifyvm $VM --nic1 bridged --bridgeadapter1 br0

Запускаем, настраиваем. Закрытие терминальной сессии убьет работу виртуальной машины. Так что либо держим открытую сессию, либо вспоминаем древний GNU screen.
$ screen
$ VBoxHeadless -s ubuntu1604lts&

Подключаемся при помощи официального клиента “Microsoft Remote Desktop”, благо на OS X он работает достаточно неплохо.

С виртуальной машиной MS Windows дело обстоит несколько сложнее – придется воссоздать рабочую конфигурацию на новом месте. В противном случае “Тамагочи” не запустится. Вроде бы стандартная процедура экспорта-импорта VM не прошла, я получил нерабочий образ диска.

$ VM='win10pro'
$ mkdir /data/vm/$VM
$ VBoxManage createvm --name $VM --ostype Windows10_64 --register --basefolder /data/vm
$ VBoxManage modifyvm $VM --memory 4096 --boot1 disk --vrde on --vrdeport 5002
$ VBoxManage storageattach $VM --storagectl win10pro_SATA --port 1 --type hdd --medium /data/vm/$VM/win10pro_2.vdi
$ VBoxManage storageattach $VM --storagectl win10pro_SATA --port 0 --type dvddrive --medium /data/install/Win10_1803_English_x64.iso
$ VBoxManage modifyvm $VM --chipset ich9
$ VBoxManage modifyvm $VM --nic1 bridged --bridgeadapter1 br0
$ VBoxManage modifyvm win10pro --paravirtprovider hyperv

На удивление все запустилось с первого раза.
$ VBoxHeadless -s win10pro&

Донастройка и смена сетевого адреаса на статический по RDP.

Просто несколько полезных команд посмотреть что у нас с дисками, виртуалками и что работает:
$ VBoxManage list hdds
$ VBoxManage list runningvms
$ VBoxManage list vms -l

Снапшоты делаю по мере необходимости, больше для самоуспокоения. Но после окончания установки – обязательно:
$ VBoxManage snapshot ubuntu1604lts take "ubuntu1604lts_2018.07.12" --description "Initial"
$ VBoxManage snapshot win10pro take "win10pro_2018.07.12" --description "Initial"

Полезные ссылки:

Create VirtualBox VM from the command line
Create VirtualBox Guest Machines On Ubuntu 16.04 LTS Server (Headless)

Устновка VirtualBox 5.2 на Ubuntu Server 16.04 LTS. Шпаргалка

Вся информация на официальном сайте VitualBox, просто собрал ее здесь в сжатом виде.

Подключим репозиторий для Debian/Ubuntu (мой вариант – Xenial):
$ sudo sh -c "echo 'deb https://download.virtualbox.org/virtualbox/debian xenial contrib' >> /etc/apt/sources.list"

Скачиваем и устанавливаем публичные ключи (новый и старый, мало ли понадобится):
$ wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -
$ wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -

Обновляем систему и ставим VirtualBox 5.2 (последний на момент):
$ sudo apt-get update && sudo apt-get upgrade
$ sudo apt-get install virtualbox-5.2

После установки проверяем что VB поставился:
$ VBoxManage -v
5.2.12r122591

Не забываем пакет расширений:
$ wget https://download.virtualbox.org/virtualbox/5.2.12/Oracle_VM_VirtualBox_Extension_Pack-5.2.12.vbox-extpack
$ sudo VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-5.2.12.vbox-extpack
$ VBoxManage list extpacks
Extension Packs: 1
Pack no. 0: Oracle VM VirtualBox Extension Pack
Version: 5.2.12
Revision: 122591
Edition:
Description: USB 2.0 and USB 3.0 Host Controller, Host Webcam, VirtualBox RDP, PXE ROM, Disk Encryption, NVMe.
VRDE Module: VBoxVRDP
Usable: true

Мелкие доработки Ubuntu Server 16.04

После установки домашнего микро-сервера (Ubuntu Server 16.04 + EeePC 901) сразу вылезли мелкие неприятные моменты.
Во-первых, при закрытии крышки экрана малютка уходит в спячку.
Вообще отключим реакцию системы на открытие-закрытие экрана:
1. Поправим конфигурацию Login Manager:
$sudo vim /etc/systemd/logind.conf
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=ignore
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
#UserTasksMax=12288

2. Рестартим сервис:
$sudo service systemd-logind restart

Источник: Как заставить Ubuntu не реагировать на закрытие крышки экрана

Идем дальше.

Поднимаем маленький файловый сервер на Samba. Жене нужно бекапить рабочий компьютер, для нее создал раздел с настроенными правами. Хороший простенький гид есть на Howtoforge: Samba Server installation on Ubuntu 16.04 LTS.

Продолжение следует…

Решение проблемы с зависанием Dell Latitude D400

Понадобился маломощный линукс-сервер, под него был выбран старенький, но надежно работающий ноутбук Dell Latitude D400. С установкой операционной системы проблем не возникает – после экспериментов с Ubuntu 16.04LTS вернулся на более консервативный Debian Server 9.2.1. Проблемы начинаются, когда закрывается крышка экрана – ноутбук зависает намертво. Эксперименты с версиями систем, управлением питанием, чтением форумов позволили выяснить, что проблема находится в самом ядре (4.0 и последние версии ветки 3) и никакие настройки Power Management ситуацию не решают. Соответственно, либо откат к старым версиям, либо танцы с бубном.

Если нельзя заставить компьютер правильно обрабатывать сигналы о закрытии крышки монитора, значит он вообще не должен знать, что крышку закрыли. Решение заключается в отключении датчика закрытия. Самый простой вариант – снять магнит в рамке экрана. Он находится в левом нижнем углу. Рамку крепят 6 винтов, закрытых декоративными заглушками. Понадобится маленькая крестовая отвертка и нож.

Все, проблема решена.

Создание загрузочной флешки OS X (OS X 10.7.2 Lion)

Понадобилось на свой старенький MacBook 4.1 (да, машинка 2008 года в хорошем состоянии и все еще годна для большинства задач) накатить последнюю версию операционки, которую он поддерживает (10.7.5) и снести то старье что там было, “улучшенное” всевозможными экспериментами за много лет.
Образ диска в формате DMG подогнал коллега, до сиx пор занимающийся ремонтом яблочной техники в качестве хобби, а вот создание правильной загрузочной флешки оказалось делом нетривиальным, куда как сложнее создания загрузочной версии Linux.
На простораx интернета нашлась толковая инструкция:
Make a bootable Mac OS X 10.7 Lion installer from a USB flash drive

←Older