Что: 5d6954c43987ff375e590e853d1cc1cdcd46457c
Когда: 2022-05-13 12:39:49+03:00
Темы: hate
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", не меняешь привычки на что-то менее удобное, только потому что нет возможности настроить или изменить что-то, а ты просто модифицируешь свою ОС и программы как
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, и на неё ушло около пары часов времени. > довольно быстро находишь место в коде поведение которого тебе не > нравится Как мне кажется, такой навык быстро не нарабатывается. Особенно, если не пользоваться какой-то системой на постоянной основе.
From: Sergey Matveev Date: 2022-05-13 16:55:12Z
From: Sergey Matveev Date: 2022-05-15 15:21:42Z С xfreerdp /drive всё вышло без проблем. SMB с qemu хотел попробовать, но он потребовал smbd демон, который я уже успел снести, так что забил. xfreerdp ещё сумел по IPv6 подключиться, в отличии от GNOME-овского Vinagre.
Сгенерирован: SGBlog 0.34.0