Линукс клиент для виндовс сервер

Возможно ли использовать 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 и еще некоторые важные файлы

Источник

Полнофункциональный RDP клиент — FreeRDP

Не секрет, что в современном мире без продуктов Microsoft практически не обойтись. Однако во многих случаях получается так, что гораздо эффективней использовать на рабочих компьютерах системы на базе GNU/Linux, а не Windows. Это значительно упрощает администрирование и сокращает расходы, предоставляя при этом пользователям гораздо больше легкодоступного функционала. Но что делать с теми приложениями, которые работают только под Windows и которым нет подходящего аналога в мире Linux? Поскольку обычно таких приложений единицы (иначе просто нету смысла ставить Linux на рабочий компьютер), то разумным выбором может стать использование терминальных серверов, работающих под серверными ОС от Microsoft. Кроме того, Linux лучше всего подходит для любых тонких клиентов, поскольку адекватных версий Windows для них просто не существует.

В любом случае необходимо уметь подключаться к терминальным серверам Windows. Для этого в MS был разработан свой протокол удалённого рабочего стола — RDP. Однако до недавнего времени для Linux существовал единственный открытый клиент для работы с этим протоколом — rdesktop. К сожалению, его развитие давно остановилось, и он испытывает огромные трудности при взаимодействии с современными версиями Windows.

Но недавно тихо и незаметно проект rdesktop был форкнут, в результате чего на свет появился новый открытый RDP клиент — FreeRDP. Первый же релиз этой программы разом исправил большинство известных проблем rdesktop, и проект продолжает активно развиваться. Почему-то появление столь полезного приложение обошли вниманием, поэтому я и решил опубликовать этот пост, чтобы хоть как-то исправить эту ситуацию и рассказать всем о существовании нормального RDP клиента для Linux. Под катом — описание возможностей FreeRDP и немного про отличную графическую оболочку Remmina для него.

FreeRDP

Официальный сайт проекта — www.freerdp.com

Там же можно найти описание возможностей текущей версии и планы на будущее. Основные отличия от rdesktop:

• Произведён значительный рефакторинг кода. Пользовательский интерфейс полностью переписан и отделён от основной библиотеки, реализована система плагинов.
• Код максимально приведён в соответствие со спецификацией RDP от Microsoft и подробно комментирован.
• Переписана работа с клавиатурой — больше никаких проблем с раскладками.
• Переписана работа с принтерами, звуком и другими пробрасываемыми устройствами и сервисами.
• Исправлены проблемы с указателем и лицензиями при подключении к серверу терминалов Windows 2008.
• Реализовано кеширование графики (bitmap caching), что позволяет значительно повысить производительность.

Поломанные и убранные возможность rdesktop:

• В данный момент не реализована поддержка проброса COM портов и поддержка смарт-карт.
• Убрана поддержка режима SeamlessRDP в пользу реализации RemoteApp, которой правда тоже пока что нет.

Remmina

Кроме того, один из самых удобных графических менеджеров подключений к удалённым рабочим столам Remmina с версии 0.8 перешёл на использование FreeRDP в качестве RDP клиента.

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

Источник

Перекрестное опыление: управляем Linux из-под Windows, и наоборот

В прошлой статье я обещал рассмотреть механизм удаленного подключения с Windows на серверы под управлением *nix, и наоборот при помощи PowerShell. Обещанного обычно ждут три года, но я успел чуть раньше. Что ж, если хочется с верного макбука управлять гетерогенной инфраструктурой, или наоборот ― с Surface Pro рулить Linux-серверами без всяких putty, ― прошу под кат.

Microsoft Loves Linux

Еще в 2015 году Microsoft торжественно объявила о запуске программы «Microsoft Linux». Сюда вошла как банальная поддержка гостевых *nix-like OS на Hyper-V, так и встроенная в Windows 10 Ubuntu и возможность запуска в Docker продуктов Microsoft, таких как SQL Server.

Компания также опубликовала исходный код PowerShell, что позволило запускать «Ракушку Мощи» не только на Windows. Из-под одноименного аккаунта на Github, помимо исходного кода, выложены и бинарники под большинство современных систем (лицензия MIT).

Это позволяет настроить удаленное управление с помощью единого инструмента ― PowerShell. Помимо подключения к консоли компьютера, можно запускать отдельные команды, в том числе и на нескольких серверах одновременно. Довольно удобно для автоматизации задач администрирования, таких как массовое изменение настроек, инвентаризация, сбор логов.

Порой удобно совмещать традиционные консольные команды со вставками PowerShell:

Для подключения к Windows-машинам при помощи PowerShell используется протокол WS-Man. Для GNU\Linux привычен SSH. Так как сегодня становятся универсальными оба протокола, разберем их подробнее.

PowerShell 6.0 под Windows и *nix, пока еще находится в бете. Поэтому не рекомендую без хорошего тестирования применять на боевых серверах описанное ниже.

Магомед не идет к горе

Когда технология удаленного доступа при помощи PowerShell только набирала обороты, единственным универсальным способом подключения к разным системам был протокол WS-Man. Для тестового стенда я взял Windows Server 2016 и Centos 7, для которых и буду настраивать возможность удаленного подключения и выполнения команд при помощи этого протокола.

Для начала установим на Centos свежий PowerShell:

После установки появилась возможность запускать привычные Windows-администратору командлеты. Например, посмотрим версию PS и получим список запущенных процессов командлетами $PSVersionTable и Get-Process:

Работаем в консоли PowerShell на CentOS.

Чтобы подключаться к Linux-машине с консоли Windows, нам понадобится установить и настроить:

• OMI (Open Management Infrastructure) ― адаптация WMI, которую также можно использовать для управления компьютерами с ОС, отличными от Windows;
• PSRP (PowerShell Remoting Protocol) ― библиотека, необходимая для удаленного подключения PowerShell.

Подробно с работой и эволюцией OMI и PSRP можно ознакомиться в отличном материале от Matt Wrock, я же просто установлю OMI командой:

Далее нужно настроить порты и аутентификацию в конфигурационном файле /etc/opt/omi/conf/omiserver.conf, после чего перезапустить сервер командой:

Для упрощения эксперимента я не буду настраивать ни NTLM-аутентификацию, ни Kerberos. Еще и шифрование отключу ― разумеется, в боевой среде делать этого не стоит. Для включения текстовой аутентификации и шифрования на стороне Windows в работе winrm достаточно выполнить следующие команды:

После настройки можно проверить работу OMI из консоли Windows:

Подключаемся к CentOS из cmd.

Теперь проверим работу обратным подключением ― из Linux к Windows:

… а затем с CentOS подключаемся к Windows.

После того, как WMI\OMI заработал, нужно установить и настроить PSRP. К сожалению и вопреки инструкции, бинарник отсутствует. Библиотеку пришлось компилировать, долго и нудно исправляя возникающие ошибки зависимостей:

Теперь мы сможем подключаться с Windows на Linux и наоборот при помощи PowerShell. Начнем с Windows на Linux:

С Windows на Linux.

Аналогичным образом можно провести и обратное подключение.

Invoke-Command можно «натравить» на список компьютеров, и с рабочей станции Windows создать пользователя на всех серверах Linux командой вида:

Надо сказать, что способ не самый удобный и эффективный. Минусов добавляет компиляция библиотек, разнообразные баги ― например, на момент написания статьи PSRP не позволял нормально подключиться из Linux в Windows.

Да и сами разработчики рекомендуют не плясать вокруг WS-Man, а обратиться к проверенному способу ― SSH. Что ж, попробуем и его.

Гора идет к Магомету

На этот раз машина с Windows получит чуть больше специфической подготовки ― нужно установить свежий PowerShell и OpenSSH.

После можно проверить синтаксис командлета New-PSSession. Если все произошло как надо, то командлет, помимо привычного параметра ComputerName, будет поддерживать и HostName.

PowerShell 6.0.0-beta.9 и обновленный синтаксис командлета.

Качаем последний релиз или используем пакет из репозитория Chocolatey. Все это разархивируем в \Program Files\OpenSSH.

В консоли с правами администратора переходим в папку с разархивированным содержимым и запускаем установку командой:

Теперь генерируем ключи:

В тестовой среде мы будем использовать парольную аутентификацию, поэтому стоит убедиться что она включена в файле sshd_config:

Если вы также хотите автоматически запускать PowerShell при подключении по SSH, то в параметре subsystem нужно прописать путь к желаемой версии PS:

Для работы клиента SSH нужно добавить директорию в %PATH% любым удобным способом. Например, таким:

Остается только настроить и запустить службы:

После установки уже можно наслаждаться подключением к серверу Windows по ssh.

C Windows через Putty на Linux, с Linux обратно на Windows по SSH.

На достигнутом останавливаться не будем и перейдем к настройке Linux. При настройке сервера SSH по умолчанию достаточно прописать PowerShell в Subsystem:

Теперь проверим подключение через командлет New-PSSession и Invoke-Command.

Работаем из PowerShell с Linux-сервером.

Теперь подключимся из Linux к Windows:

Работаем из PowerShell с Windows-сервером.

В отличие от WS-Man, SSH настраивается намного проще и работает стабильнее. Да и беспарольное подключение по ключам настраивать привычнее.

В хозяйстве пригодится

С однозначным «советом потребителю» все опять сложно: SSH проще в настройке и стабильнее, но WS-Man использует API и позволяет применять инструменты вроде JEA. На боевых серверах использовать WS-Man я бы не стал однозначно, а вот реализация OpenSSH в Windows как сервера, так и клиента мне понравилась. Для самопальной автоматизации вполне подойдет даже без PowerShell.

В любом случае, границы между Linux и Windows хоть и медленно, но начинают стираться, что безусловно радует.

Источник