Debian и Windows в ВМ

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

Debian выбран потому что это один из самых популярных GNU/Linux
дистрибутивов, но не такого паршивого качества как Ubuntu. FreeBSD не
рассматривал, потому что с ней на работе мог бы помочь только я, а с
Debian в принципе любой, ибо он же даже и на systemd переехал.

Помню что в Ubuntu, в нескольких версиях, не выходило установить её не
на основной диск. Точнее загрузчик не прописывался как надо. В Debian
проблем не возникло. Это было приятно.

Но на этом всё положительное закончилось -- всё криво, не раз замечал в
man-ах опечатки или неактуальную информацию. Как пользоваться GNOME-ом
удобно можно -- не понимаю, но я привык к интерфейсам не для индусов,
которые читать то не умеют.

Одной из проблем было то, что в штатной поставке есть только какой-то
GNOME-овский инструмент для удалённого рабочего стола. Поддерживает VNC,
Spice, RDP. Начал пробовать с VNC, потом Spice впервые использовал.
Клавиатура как-то не так работала, да и в целом experience ужасный. RDP,
что не должно быть удивительно, оказался лучше чем, но это потребовало
уже поднятия сети между хостом и ВМ, чего прежде не планировалось. Но
этот GNOME-овский клиент не поддерживает возможность использования
нескольких мониторов.

В Интернете все рекомендуют FreeRDP, которого на диске не оказалось. Она
заработала отлично, без проблем, сразу же, и, по мне так, без нареканий.
Но почему на многогигабайтный DVD образ Debian они не засунули этот,
явно лучшего качества, пакет в сотни килобайт?

Я думал что на этом завершилась самая геморройная часть. Что может быть
проще чем уж обмениваться файликами под современным GNU/Linux и Windows
в 2022-ом? В Windows очень не хотелось ставить что-то дополнительное. А
раз сеть для RDP уже всё равно поднята, то логично бы было поднять SMB.
И... я потратил наверное пару часов, держа и документацию администратора
Debian под рукой, и поисковик Интернета, но я не смог сделать так, чтобы
Windows 10 увидел в сети второй компьютер (SMB-сервер). Два часа, казалось
бы отлаженных технологий и двух распространённых ОС -- но я не смог ничего
сделать. А главное я даже не понимаю что именно не работало. Я плюнул и
бросил, ибо это уже перебор был тратить столько времени. Возможно я
какую-то опцию или галочку где-то не выставил, но когда я поднимал SMB
10+ лет назад, то даже в гетерогенных Windows сетях я не помню чтобы
возникали какие-то серьёзные проблемы.

Многие упомянули про VirtFS, когда по 9P протоколу можно обмениваться
файлами, минуя все эти сетевые стэки. Было потрачено ещё несколько
часов, всё же подсовывая драйвера от virtio разнообразного. Но абсолютно
никакого результата. PCI устройство в ВМ появляется, но не удалось
ничего сделать чтобы оно хоть как-то начало "работать". Всё делалось по
документациям KVM, qemu, статьям, качая официальные драйвера от Red Hat.
Полный fail.

Я помню что rdesktop позволял обмениваться файлами через RDP. Но FreeRDP
этого не умеет. Снова выкачивать .deb-ы руками, записывать на CD-RW,
устанавливать и не быть уверенным что с Win10 это заработает? Отказался.
В курсе про apt-offline, но для этого надо бы находится внутри Debian
системы, которая не подключена к сетям (air-gap компьютер).

Лично я бы, будь у меня в руках система в которой нихрена ничего не
сработало (фиг знает что с SMB, нет NFS, VirtFS не работает),
использовал бы свой uploader:
http://www.git.stargrave.org/?p=uploader.git;a=blob;f=README
для передачи файлов через броузер с ВМ на хост, ну и просто
HTTP-сервером для передачи в обратном направлении. Но предлагать не
стал.

Подумал про FTP, был почти уверен что его в Win10 уже нет, но оказалось
что ftp команда присутствовала, хотя я так и не проверил работает ли она
в действительности.

Напомнили мне про SSH, что я сразу отбросил, уже на 100% будучи
уверенным в том, что в Windows этого не будет. Был не прав. В итоге,
передавать файлы удалось через SSH.

Стал ли современный софт/ОС каким-то неработающим дичайшим адом? Скорее
всего нет, ибо я до сих пор не могу поверить что поднять SMB между Win10
это есть что-то сложное. Почему не работал VirtFS? Без понятия. Но было
испробовано всё что только приходило в голову и в статьях. Или я
окончательно уже не в состоянии работать с современными ОС (в том числе
GNU/Linux) и вообще ничего не понимаю как и что надо делать, или можно
только стыдиться во что превратилась ИТ отрасль.

Возвращаюсь к своей FreeBSD, где ощущение что я понимаю чуть ли не всё
что происходит за каждый цикл ядерного планировщика. Где, если надо
сделать headerless шифрованный раздел (а эту задачу для airgap
компьютера с ВМ тоже подкинули), то я со 100% вероятностью знаю что
сделаю за считанные часы.

Ведь даже сущие мелочи важны для удобной и продуктивной hateless работы.
Коллега бесился что в GNOME терминале, когда открыто множество tab-ов, в
их заголовках нет ничего кроме его имени пользователя и хоста: что в них
выполняется -- никто не знает. Да, из коробки в tmux/whatever этого тоже
не будет, но не задумываясь ты тратишь несколько минут на настройку и
исполнению этого желания и у тебя и имена редактируемых файлов Vim-а
прокидываются в tmux tab-ы и удобное (дело вкуса) переключение
Ctrl-PgUp/PgDown переключение tab-ов и всё всё всё подобное. Но у меня
то, как бы, минималистичная система где ты, как из пластилина, делаешь
как тебе удобно и забываешь о настройках на долгие годы, просто
удобнейшим образом работая. Двойной клик мышки в терминале выделяет
какие-нибудь лишние символы типа кавычек-ёлочек или визуализируемых
tab-символов в Vim-е при редактировании Go кода? Ничего не надо искать в
Интернете -- просто идёшь в ~/src/suckless/st и редактируешь config.h
или st.c исходный код. Мне хотелось чтобы italic был жёлтого цвета в
терминале, курсивный, ибо просто я так привык. st этого не позволял
делать настройками. Подправил код терминала -- и поведение как мне надо.
Если что-то происходит непонятным мне образом -- отлаживаешься. Ты не
играешь в квесты под названием "настрой virtfs под win10" или hardcore
адвенчуры "подними smb между debian и win10", не меняешь привычки на
что-то менее удобное, только потому что нет возможности настроить или
изменить что-то, а ты просто модифицируешь свою ОС и программы как
*тебе* надо. Помню что bfs утилита поиска файлов обращалась и лазала
куда не следует, вешаясь если кто-то из NFS mount-ов не был доступен.
Запускаешь truss -- понимаешь суть проблемы. Идёшь в исходный код,
довольно быстро находишь место в коде поведение которого тебе не
нравится, меняешь, перекомпилируешь -- забываешь навсегда о проблеме и
тащишься от удобства и высокого КПД. Вот такими должны быть компьютеры.
А не игровыми консолями нового поколения с кучей квестов, головоломок и
беспомощности.

комментарий 0:

From: kmeaw
Date: 2022-05-13 16:24:23Z

> В Интернете все рекомендуют FreeRDP, которого на диске не оказалось.
> Она заработала отлично, без проблем, сразу же, и, по мне так, без
> нареканий.  Но почему на многогигабайтный DVD образ Debian они не
> засунули этот, явно лучшего качества, пакет в сотни килобайт

Этот пакет лежит на втором DVD-диске. Всего их 19.

% curl -sfsL \
https://cdimage.debian.org/cdimage/release/11.3.0/amd64/list-dvd/debian-11.3.0-amd64-DVD-2.list.gz | \
zcat | grep freerdp
freerdp2-x11_2.3.0+dfsg1-2+deb11u1_amd64.deb

> Я помню что rdesktop позволял обмениваться файлами через RDP. Но
> FreeRDP этого не умеет.

xfreerdp /v:windowsvm /drive:home,/home/user

И /home/user будет доступна в Windows, как \\tsclient\home

> Лично я бы, будь у меня в руках система в которой нихрена ничего не
> сработало (фиг знает что с SMB, нет NFS, VirtFS не работает),
> использовал бы свой uploader

> Подумал про FTP, был почти уверен что его в Win10 уже нет, но оказалось
> что ftp команда присутствовала, хотя я так и не проверил работает ли она
> в действительности.

В Windows NT есть ftp.exe и tftp.exe. Оба работают.
В Windows 10 tftp.exe устанавливаются через
Enable-WindowsOptionalFeature -Online -FeatureName TFTP

Если мне надо было бы закинуть файл на airgapped VM, я бы просто собрал
iso с ним и закинул его в эмулированный CD-привод:

% mkisofs -J -R -o /tmp/cd.iso /some/path
(qemu) change ide1-cd0 /tmp/cd.iso

Или воспользовался бы usernet, если на VM пока нет ничего опасного:

qemu-system-x86_64 … -nic user,smb=/some/path

И файлы были бы доступны по \\10.0.2.4\qemu

Проблемы с samba могли быть вызваны тем, что в современных версиях
Windows выключены режимы совместимости со старыми реализациями. Их можно
включить обратно:

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

> Или я окончательно уже не в состоянии работать с современными ОС  и
> вообще ничего не понимаю как и что надо делать, или можно только
> стыдиться во что превратилась ИТ отрасль.

Может быть дело просто в наличии одного опыта и отсутствии другого?

Во FreeBSD всё кажется легко, потому что

> ощущение что я понимаю чуть ли не всё
> что происходит за каждый цикл ядерного планировщика

а для GNU/Linux и Windows такого опыта пока нет?

Ведь бывают и обратные примеры - когда задача с простым описанием легко
решается в Windows. Из относительно недавнего - в WINAPI есть функция
CreateRemoteThread:

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread

Она принимает HANDLE процесса и создаёт в нём новый поток с заданной
точкой входа (lpStartAddress). Как на FreeBSD сделать то же самое?

Для Linux/amd64 моя реализация занимает около 150 строк кода на Go, и на
неё ушло около пары часов времени.

> довольно быстро находишь место в коде поведение которого тебе не
> нравится

Как мне кажется, такой навык быстро не нарабатывается. Особенно, если не
пользоваться какой-то системой на постоянной основе.

комментарий 1:

From: Sergey Matveev
Date: 2022-05-13 16:55:12Z

*** kmeaw [2022-05-13 19:20]:
>Этот пакет лежит на втором DVD-диске. Всего их 19.

Да, я это видел. Но! Где мне его скачать? Они явно написали что ничего
кроме первого DVD не предоставляют ради экономии места на дисках. Мне
надо ставить дополнительный софт jigdo чтобы воссоздать эти диски.
Против jigdo ничего не имею, но отсутствует решение когда я могу просто
скачать образ и записать его.

>xfreerdp /v:windowsvm /drive:home,/home/user

Только сегодня я увидел /drive опцию в нём. На днях, как буду снова на
работе, планирую проверить как-раз. Это моя невнимательность. Хотя я
ведь бегло просматривал его опции в поисках возможности обмена файлами.
Но, видимо, из-за усталости и кучи потраченного времени, и не заметил.
Если сработает, то конечно со всем остальным (включая SSH) уже можно
будет не возиться.

>Если мне надо было бы закинуть файл на airgapped VM, я бы просто собрал
>iso с ним и закинул его в эмулированный CD-привод:

Вариант безусловно. Но нужно и из ВМ что-то доставать. Как запасной
вариант у меня всегда в голове оставалось создание образа флешки которую
подсовывать ВМ. CD -- read only, а флешка writable. Но да, суть одна
остаётся.

>qemu-system-x86_64 … -nic user,smb=/some/path

Ох ты ж, какая штука оказывается есть. Тоже в упор не увидел (хотя
наверное потому что и не ожидал бы увидеть) в man-е. Выходит, можно
было бы и без стороннего SMB сервера попробовать.

>Проблемы с samba могли быть вызваны тем, что в современных версиях
>Windows выключены режимы совместимости со старыми реализациями. Их можно
>включить обратно:

Сколько статей я не видел в выдаче поисковика, но ничего подобного не
упоминалось. Я тоже думал что: мало ли, SMB же тоже развивается и всё
такое, возможно какая-то несовместимость (ведь я Samba ещё с Win98
пробовал когда-то даже, а это сколько лет назад то было).

>Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
>Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client

Чисто просто из любопытства проверю поможет ли это. Но штатно я так и не
находил подобных упоминаний.

>а для GNU/Linux и Windows такого опыта пока нет?

Про Windows бы я сказал что в нём абсолютно всё требует только либо
знаний, либо опыта, в течении которого эти знания получаются. Ни
логикой, ни документацией, ни чем бы то подобным ты ничего не осилишь,
пока кто-нибудь не покажет или не намекнёт.

Про GNU/Linux современный, очевидно, мало что уже знаю и понимаю. Но
ведь прежде я во всех этих GNU дистрибутивах и FreeBSD всё делал без
посторонней помощи. Банально просто не у кого было спрашивать: никого не
было с опытом кроме Windows, или он был меньше чем у меня. И Интернета
ещё многие годы у меня не было, и даже FidoNet. Но как-то пары книжек и
документации было достаточно. Вот беру я незнакомую (прежде) Samba и в
принципе же могу разобраться что там и как настроить -- конфиг у них
понятный и документированный. Всегда есть время когда опыта в чём-то
нет. Папа вот розетки делает за пару минут. А когда берусь я, то 15мин и
всё криво. Но на третьей розетке уже достаточно всё качественно. Тут
опыт, безусловно. Но в том же Windows -- просто ступор. Буквально вообще
не ясно как что-то отлаживать/мониторить/проверять -- полностью
беспомощен. У них и нет цели быть дружелюбным и помогать пользователю:
их цель делать его зависимым и чтобы пользовались их поддержкой, курсами
и чем-то подобным. Тут то всё ясно и не удивительно. Но прежде в
GNU/Linux всё же делалось людьми для людей (разработчиками для
разработчиков -- хотя бы).

Со вчерашнего дня я дал себе слова что больше никогда не буду пытаться
влезать в подобные вещи :-). Сразу пошлю к админам. Если на справятся,
значит задача не выполнима. Но мне это всё точно уже не по силам.

>Ведь бывают и обратные примеры - когда задача с простым описанием легко
>решается в Windows.

Не спорю, не спорю. Я до сих пор не забуду какое-то выступление
какого-то BSD или Linux-оида, который показывал как якобы легко и трушно
в Unix-way режиме что-то сделать с USB устройством (если память не
изменяет) через /proc или /sys абстракции: открыть и отпарсить дюжину
файлов и что-то из этой серии. Тогда как в Windows ровно один удобный
API вызов был из серии DoWhatIWant(USBDevice, bla, bla, bla) -> success.

>Как мне кажется, такой навык быстро не нарабатывается. Особенно, если не
>пользоваться какой-то системой на постоянной основе.

Тоже верно. Но, если брать fzf, st, dwm, bfs, которые я как-то упоминал:
они сами по себе очень просты и мало занимают и поэтому с ними шустро,
типа с первого взгляда, можно найти нужные места и подправить их. В
FreeBSD уже что-то правил и не переставал удивляться что я тупо понимаю
что там написано и как мне примерно реализовать свои пожелания. И
безусловно были случаи когда залазишь в какой-то код не маленькой
библиотеки и тонешь как в зыбучих песках в ней. Первое знакомство с
внутренностями OpenSSL были из этой серии. Когда надо было второй раз
нечто другое массово интегрировать в него, то было конечно проще, но это
просто потому что осталась память, опыт. Но код как был ужасным спагетти
hard-code-ов, так и остаётся. Бывает понятный и качественный,
документированный код, а бывает такой, что только опыт может с ним
спасти :-). Или вот недавно я взялся попытаться понять почему у меня
segfault-ится Vim в некоторых случаях: его код ни разу не открывал, не
видел, слышал что он имеет тьму legacy и не очень приятен, но всё равно
под lldb я относительно быстро (не засекал, возможно и не мало времени,
но оно было незаметно из-за того что не было недовольства и неприязни)
нашёл источник проблемы. Или вот в GNU Info багу нашёл когда элемент из
индекса пропадал: тоже впервые жизни открыл его код, запускал с lldb,
перекомпилировал что-то вставляя, но без каких-то негативных эмоций
добился чего надо, понял что было не так. Не было беспомощности.

Спасибо за кучу наводок и советов! На следующей неделе попробую всё. Я
ведь в поисковиках искал и просто вообще глобальные вопросы: как жить с
Windows под ВМ, какие best practices.

комментарий 2:

From: Sergey Matveev
Date: 2022-05-15 15:21:42Z

С xfreerdp /drive всё вышло без проблем. SMB с qemu хотел попробовать,
но он потребовал smbd демон, который я уже успел снести, так что забил.
xfreerdp ещё сумел по IPv6 подключиться, в отличии от GNOME-овского Vinagre.