Может линукс работать с виндовс

Возможно ли использовать Linux Desktop в Windows инфраструктуре?

Всем привет! На Хабре неоднократно поднимались вопросы о том, как подготовить дистрибутив Linux для ввода в Active Directory, а также для интеграции с некоторыми другими серверами Windows. При этом, до сих пор не было написано статьи о том, стоит ли вообще этим заниматься, и будет ли конечный результат стоить потраченных времени и усилий.

Почему возник этот вопрос? Меня попросили настроить Linux для ребят, которые утомились от обновлений и прожорливости Windows 10 (особенно на компьютере без SSD и с оперативной памятью DDR2). Кроме того, одним из неоспоримых плюсов Linux (и его признают даже его ярые противники) является его открытость бесплатность. Это тоже значимый аргумент.

Обычный пользователь в среднестатистической компании, компьютер использует для Word и Excel, браузера, плюс в редких случаях, работает с каким-либо удаленным приложением, например через RDP. Необычный пользователь, типа целого программиста, без значительных сложностей может попросить админов найти требуемую IDE, Jenkins, git, и что там еще нужно программистам? Мессенджеры, на отсутствие которых в Linux в соседней статье жалуются, в дистрибутиве имеются во всевозможном изобилии. Skype, Viber, ICQ, даже заблокированный в РФ клиент, полностью в наличии на официальных сайтах, прекрасно поддерживаются и в полной мере идентичны по UI с клиентами предназначенными для Windows.

Итак, смотришь на требования пользователей к системе, сравнишь их с возможностями Linux и думаешь, сплошные плюсы, а еще и экономия четко прослеживается. Почему же возникают какие-либо возражения к такой прекрасной идее как перевод пользователя с Windows, на Linux? Только лишь вредные привычки?

Я совсем не крутой пользователь открытых операционных систем, но некоторым минимальным практическим опытом который я получил (при переводе пользователей с Windows на Linux) хочу поделиться.

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

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

Подготовка локального репозитория

Linux (по крайней мере Ubuntu), как и Windows полностью поддерживает сетевую/локальную установку. Вполне можно было бы опустить этот шаг, так как linux прекрасно устанавливается и из интернета. Но учитывая, что установка системы, задача довольно часто повторяемая, мы попытаемся ее автоматизировать, а чтобы избежать ненужных проблем с внешним репозиторием, который мы не контролируем, подготовим виртуальную машину, с локальным репозиторием, на котором будут расположены установочные файлы системы, файл ответов, (а заодно, весь необходимый нам софт, а также будущие обновления).

Файлы установки и все дополнительное ПО, для LTS версии Ubuntu 20.04 Focal Fossa, занимают примерно 80 Гб.

В качестве ОС для виртуальной машины — я использовал Ubuntu Server 20.04 Это стабильный релиз, который будет полностью поддерживаться до 2025 года.

После окончания установки, задаем человеко-понятное имя нашему компьютеру

Устанавливаем пакет для клонирования репозитория

Хочу отметить, что в этой конфигурации показывается возможность управления количеством потоков и скоростью закачки файлов при клонировании репозитория, а также демонстрируется возможность клонировать внешние репозитории, не принадлежащие Canonical. Например, Google Chrome.

Также, заслуживает внимания, что, дополнительно в конфигурации необходимо прописать ветку main/debian-installer, хотя она и является дочерней по отношению к ветке main, Это не было очевидным для меня, я не нашел чтобы об этом писалось раньше, и поначалу не мог понять в чем дело.

Необходимо выполнять команду sudo apt-mirror например, еженедельно, для обновления нашего репозитория — «сервера» обновлений клиентских компов.

Пример настройки автообновления репозитория с записью логов о обновлении

Установка веб-сервера (для раздачи файлов нашим будущим клиентам)

Для проверки, что все получилось как задумывалось, необходимо попытаться зайти на наш ip через браузер. В результате мы должны увидеть файлы репозитория.

Установка tftpd для установки ubuntu по сети

Разархивируем и рекурсивно копируем все найденные файлы библиотек .c32 из syslinux в /tftpboot любым удобным вам способом, а также создаем в /tftpboot папки pxelinux.cfg и папку linux

В /tftpboot/pxelinux.cfg будет находится меню загрузчика (файл с именем default)

В /tftpboot/linux должны находиться следующие файлы:

-файл ответов ubuntu2.cfg, загрузчик initrd.gz, файл ядра linux

Ниже пример preseed файла (файла ответов).

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

Ядро и загрузчик были получены по этому адресу:

Файл ответов позволяет автоматически выбрать язык системы, язык установки системы, задать требуемое разбиение и форматирование диска и даже задать хэши паролей на загрузчик и локального администратора (на момент установки — единственного пользователя ПК).

При предварительно настроенном DHCP (опции 66 и 67) включающих загрузочный файл и IP адрес tftp сервера после загрузки и выбора строчки «Install Ubuntu 20.04» Все остальное будет сделано без нашего вмешательства. (Система будет устанавливаться около 25-30 минут).

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

Установка занимает около 25-30 минут. и проходит полностью автоматически. Для обычного пользователя этого достаточно.

Но мы ведь говорим о работе Ubuntu в корпоративной среде, а значит речь пойдет об интеграции с Active Directory, Exchange, DFS и т.д. Может быть где-то на пути поиска взаимодействия с этими службами возникнут неполадки? Может быть что-то из изложенного выше уже на данном этапе сделано неправильно? В следующей части статьи напишу о моем пути интеграции Linux систему в корпоративную Windows инфраструктуру.

Для управления удаленными компьютерами и их настройки необходимо установить на «сервер» операционную систему с репозиторием систему управления конфигурациями Ansible

Установка и настройка Ansible (для авто настройки и администрирования Ubuntu)

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

Для проверки успешности настроек введем команду.

Если мы видим ответ от клиентского ПК наши настройки выполнены верно.

После успешной проверки настроек, необходимо запустить скрипт для доустановки необходимых пакетов и введения ПК в домен.

Для управления поведением компьютера в Ansible обычно создаются роли, но так как у нас тривиальная задача просто установить, удалить, настроить и ввести в домен компьютер c Ubuntu воспользуемся простым скриптиком (в терминогогии Ansible плэйбуком).

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

Для запуска скрипта после приведения скрипта к рабочему виду:

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

Вот этот скрипт:

Скрипт Ansible ссылается на несколько дополнительных скриптов конфигурирующих kerberos, sssd, samba и еще некоторые важные файлы

Источник

Опыт настройки и использования WSL (подсистемы Linux в Windows 10)

К написанию данной статьи меня побудил вопрос на Тостере, связанный с WSL. Я, после нескольких лет использования систем на ядре Linux, около полугода назад перешел к использованию Windows 10 на домашнем ПК. Зависимость от терминала и Linux окружения в моей работе практически сразу привели меня к вопросу: или ставить виртуалку или попробовать WSL. Я выбрал второе, и остался вполне доволен.

Под катом я расскажу как установить и настроить WSL, на какие я наткнулся проблемы и ограничения, как запускать Linux приложения из Windows и наоборот, а так же как интегрировать элементы окружения Xfce в окружение рабочего стола Windows.

Никогда не думал, что однажды вернусь на Windows, но повод попробовать мне дали стечения обстоятельств: жена, далекая от IT, дергала почти каждый раз, когда у нее возникала необходимость воспользоваться компом; проснулась ностальгия по одной игре, но она никак не хотела адекватно работать под wine; а тут еще мне подарили коробочную Windows 10 Pro. WSL я поставил чуть ли не сразу после установки системы, поигрался несколько вечеров, понял, что продукт для моих задач годный, но хочется более привычный терминал и вообще некоторых удобств.

Установка WSL и дистрибутива

Сразу оговорюсь, в интернете можно найти описание установки с помощью выполнения команды lxrun /install в командной строке или консоли PowerShell. Данный способ больше не работает (после выхода WSL в стабильный релиз). Насколько мне известно, сейчас WSL можно установить только из Microsoft Store вместе с предпочитаемым дистрибутивом.

Так же отмечу, что когда установку производил я, на выбор были доступны дистрибутивы OpenSUSE, SUSE Linux Enterprise и Ubuntu 16.04 — последний я и установил. Сейчас также доступны Ubuntu 18.04, Debian 9 и Kali Linux, возможно появятся и другие дистрибутивы. Действия по установке могут отличаться. Так же, часть проблем описанных в статье может быть уже исправлена.

Находим в магазине желаемый дистрибутив и устанавливаем. Установка пройдет быстро, так как скачает только эмулятор ядра Linux и утилиту для запуска подсистемы, которая окажется в системной папке в трех экземплярах: wsl.exe, bash.exe и ubuntu.exe (вместо ubuntu будет имя Вашего дистрибутива). Все они равнозначны и делают одно и то же — запускают собственный эмулятор терминала, в нем linux’овый bash работающий под эмулятором ядра. При первом же запуске нас попросят придумать логин и пароль для пользователя по умолчанию, а после произойдет непосредственно установка дистрибутива. В качестве пользователя по умолчанию указываем root без пароля — это потребуется для дальнейших шагов. Безопасность не пострадает, кроме того при подготовке материалов к статье, в англоязычном туториале, я наткнулся на информацию, что новые версии WSL теперь делают пользователем по умолчанию root без пароля без лишних вопросов.

Дожидаемся установки. Далее первым делом стоит обновить зеркала apt на ближайшие. Для этого понадобится CLI текстовый редактор. В комплекте только vi, я же больше предпочитаю nano, поэтому ставлю его:

sudo вводить не требуется, так как мы уже под root’ом. Отредактируем файл /etc/apt/sources.list:

У меня лучше всего работают зеркала Яндекса, поэтому мой файл выглядит так:

Нажимаем Ctrl+O для сохранения и Ctrl+X для выхода. Теперь можно обновить систему до актуального состояния:

После обновления можно создать нашего основного пользователя. В данной статье я назову его user1, Вы же можете задать привычное имя:

Далее переходим в папку юзера, зайдем под ним, установим пароль и отредактируем файл

Все, подсистема готова к использованию… почти.

Установка X-сервера, Xfce и прочих GUI’шных приложений

Первая же проблема, на которую я натолкнулся — bash-completion в предлагаемом эмуляторе терминала работал, мягко говоря, некорректно. Кроме того, данный эмулятор не умеет вкладки, а каждый его экземпляр запускает все в новом пространстве процессов, с отдельным init’ом (который кстати не заменить). Мне захотелось нормальный эмулятор терминала, некоторых других GUI приложений, а так же панельку, чтоб это все быстро запускать.

Когда я гуглил этот вопрос, я наткнулся на множество проблем, вроде необходимости перевода dbus на tcp протокол. На данный момент всех этих проблем нет. В подсистеме нормально работают unix-domain-socket’ы и все спокойно общается через них.

Первым делом нам понадобится X-сервер, притом установленный в основную систему (в Windows). Лично я использую для этих целей VcXsrv — порт X11 на Windows. Официальный сайт указанный в about самой утилиты его сейчас не предоставляет, поэтому гуглим установщик и устанавливаем все по умолчанию.

Пока идет установка возвращаемся в терминал WSL, командой exit выходим обратно в root’а. Первым делом настроим русские локали:

Далее установим некоторые компоненты Xfce. Можно конечно установить его целиком из мета-пакета, но большинство компонентов нам не понадобится, а модульная архитектура Xfce позволяет нам поставить только необходимое:

Запускать каждый раз окружение руками не очень удобно, поэтому я автоматизировал данный процесс. Для этого в основной системе создадим в удобном для нас месте папку, а в ней 3 файла для запуска:

config.xlaunch — файл настроек для VcXsrv

x-run.vbs — WSL всегда запускается со своим эмулятором терминала, если его закрыть — завершатся все его дочерние процессы. Чтоб данное окно не мозолило глаза, неплохо его запускать скрытым. К счастью в Windows встроен интерпретатор VBScript, который позволяет это сделать в одну строчку:

Поясню, что здесь происходит. Мы говорим VBscript выполнить приложение wsl с параметром cd /home/user1; DISPLAY=:0 LANG=ru_RU.UTF-8 su user1 -c xfce4-session , папка запуска нам не важна, поэтому пустая строка, действие open — запуск, 0 — скрытый режим. Самому wsl мы отдаем команду на выполнение: переход в папку пользователя, затем с установкой переменных окружения DISPLAY (дисплей X-сервера) и LANG (используемая локаль) мы запускаем xfce4-session от имени нашего пользователя user1 (благодаря команде su)

start.bat — batch файл для запуска, по желанию его можно засунуть в автозагрузку

Далее можем запустить наш start.bat и настроить панель Xfce под себя. Замечу, что здесь я наткнулся на еще одну проблему — панель прекрасно отображается поверх всех окон, но вот выделить себе место, как панель на рабочем столе Windows она не может. Если кто знает решение данной проблемы, поделитесь в комментариях.

Ну и под конец данной части, скриншот моего рабочего стола:

Взаимодействие окружения Windows и окружения подсистемы Linux

Запускать Linux приложения напрямую из Windows можно через те же 3 команды — bash, wsl или ubuntu. Не забываем, что по умолчанию запуск идет от root, поэтому стоит понижать привилегии через su , так же нужно не забывать передавать переменную окружения DISPLAY=:0 если приложению требуется X-сервер. Так же нужно менять папку, из которой должно работать приложение, через cd внутри WSL. Пример, посчитаем md5 для file.txt на диске D средствами Linux’овой md5sum:

Доступ к файловой системе Linux так же имеется, лежит она в %localappdata%\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs . Читать таким образом файлы можно, а вот писать — не желательно, можно поломать файловую систему. Думаю проблема в том, что Windows не умеет работать с правами и владельцами файловой системы Linux.

Из Linux так же можно запускать Windows приложения. Просто запускаем exe-шник и он выполнится в основной системе.

Диски Windows монтируются в /mnt в соответствии со своими буквами в нижнем регистре. Например диск D будет смонтирован в /mnt/d . Из Linux можно свободно читать и писать файлы Windows. Можно делать на них симлинки. Права у таких файлов всегда будут 0777, а владельцем будет root.

Сетевой стек у подсистемы общий с Windows. Сервер поднятый в Linux будет доступен на localhost в Windows и наоборот. Однако unix-domain-socket для Windows будет просто пустым файлом, работать с этим можно только внутри Linux. Выход во внешнюю сеть у Linux так же есть, в том числе можно слушать порты, если этого не запрещает фаервол.
ifconfig в Linux и ipconfig в Windows выдают одинаковую информацию о сетевых интерфейсах.

Из диспетчера задач Windows можно спокойно прибить процесс внутри подсистемы Linux. Однако Linux увидит только свои процессы.

Особенности, ограничения и подводные камни

Ядро Linux в WSL не настоящее. Это всего лишь прослойка-эмулятор, которая часть Linux-специфичных задач выполняет сама, а часть проксирует напрямую в ядро winNT. Большая часть api в нем реализована, но не все. Свое ядро собрать не получится, как и не получится подключить модули ядра (.ko, Kernel Object).

Init процесс у WSL тоже свой и заменить его, например, на system.d не выйдет. У меня давно есть желание написать менеджер демонов на go, который бы работал с файлами юнитов system.d и предоставлял бы схожий интерфейс, да все руки не доходят.

Нет поддержки openFUSE, соответственно примонтировать виртуальную или удаленную файловую систему не получится. Так же нельзя сделать mount из файла, mount вообще ничего кроме bind здесь, похоже, не умеет.

Так же нет никакой возможности разбить файловую систему Linux на несколько разделов/дисков.

Прямой доступ к железу практически отсутствует. Все таки мы находимся в песочнице Windows, а не в полноценном Linux. /dev и /sys заметно пустуют, в них лишь проц да виртуальные устройства. Доступ к GPU — только через X-сервер, напрямую — никак, так что нейросети обучать придется в Windows.

В JS разработке столкнулся с тем, что electron.js отказался запускаться в WSL, пришлось дублировать окружение node.js в Windows.

Итоги

Статья получилась довольно длинной, надеюсь, что она окажется еще и полезной.
WSL для меня лично оказался инструментом вполне юзабельным, решающим мои задачи fullstack backend разработчика. Виртуалка с Linux за полгода так и не понадобилась. По общим ощущениям Windows+WSL намного функциональнее, чем Linux+Wine.

Пока писал статью, обнаружил, что в Microsoft Store появилась сборка WSL с Debian 9.3, данный дистрибутив мне более симпатичен, чем Ubuntu, поэтому буду пробовать ставить.

Источник