Линукс на сервер 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 года.

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

sudo nano /etc/hostname  
#печатаем желаемое имя ПК в открывшемся файле,
# затем перезагружаем ПК

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

sudo apt install apt-mirror 

sudo nano /etc/apt/mirror.list 
#настраиваем конфигурационный файл зеркала

############# config ##################
set base_path    /repo  
set mirror_path  $base_path/mirror
set skel_path    $base_path/skel
set var_path     $base_path/var
set cleanscript $var_path/clean.sh
set postmirror_script $var_path/postmirror.sh
set run_postmirror 0
set limit_rate 2000000
set nthreads   20
set _tilde 0
############# end config ##############
#------------------------------------------------------------------------------#
#                            OFFICIAL UBUNTU REPOS                               #
#------------------------------------------------------------------------------#
###### Ubuntu Main Repos
# 18.04 mirroring
deb http://archive.ubuntu.com/ubuntu focal main main/debian-installer restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu focal-updates main main/debian-installer restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu focal-proposed main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu focal-security main main/debian-installer restricted universe multiverse

clean http://archive.ubuntu.com/ubuntu

#------------------------------------------------------------------------------#
#                           UNOFFICIAL UBUNTU REPOS                            #
#------------------------------------------------------------------------------#
###### 3rd Party Binary Repos
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

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

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

sudo apt-mirror 
#запускаем настроенный пакет (осторожно, большой объем >= 80 Gb) 

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

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

sudo nano /etc/crontab
30 02     * * 0   admin      /usr/bin/apt-mirror > /path/to/your.log
#каждое воскресенье в 02:30
#Немного подробнее о планировщике можно прочитать по ссылке #https://crontab.guru/examples.html

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

sudo apt install apache2  
ln –s /repo/mirror/archive.ubuntu.com/ /var/www/html/ubuntu 
#(символическая ссылка на наш репозиторий отправленная в вебсервер)
sudo systemctl restart apache2 
# (перезапуск веб-сервера).

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

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

sudo apt install tftpd-hpa  
sudo nano /etc/default/tftpd-hpa 

# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"   
TFTP_DIRECTORY="/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure -l -v -m /etc/tftpd.remap"

#В свою очередь /etc/tftpd.remap должен содержать следующую строчку
rg \/

sudo mkdir /tftpboot  
#(создаем директорию в корне)
sudo chmod -R 755 /tftpboot
cd /tftpboot

#Скачиваем систему syslinux
wget https://www.kernel.org/pub/linux/utils/boot/syslinux/4.xx/syslinux-4.07.tar.gz 

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

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

ui vesamenu.c32
ALLOWOPTIONS 0 
PROMPT 0
menu title Microsoft SCCM Enterprice Endpoint :-)
MENU WIDTH 77
MENU MARGIN 10
MENU PASSWORDMARGIN 3
MENU ROWS 12
MENU TABMSGROW 18
MENU CMDLINEROW 18
MENU ENDROW 24
MENU PASSWORDROW 11
MENU TIMEOUTROW 60
NOESCAPE 0
MENU COLOR SCREEN 44;30 #00FFFFFF #00000000
MENU COLOR BORDER 44;30 #FFFFFFFF #FF000000
MENU COLOR TITLE 1;44;30 #FFFFFFFF #FF000000
MENU COLOR SCROLLBAR 44;30
MENU COLOR HOTKEY 44;30 #FFFFFF00 #FF000000
MENU COLOR UNSEL 44;30 #FFFFFFFF #FF000000
MENU COLOR HOTSEL 1;30 #FFFFFFFF #FF333333
MENU COLOR SEL 7;44;30 #FFFFFF00 #FF333333
MENU COLOR CMDMARK 44;30
MENU COLOR CMDLINE 44;30
MENU COLOR TABMSG 44;30
MENU COLOR DISABLED 44;30
MENU COLOR HELP 44;30
MENU COLOR PWDBORDER 44;30 #FF187CCA #FFFFFFFF
MENU COLOR PWDHEADER 1;44;30 #FF187CCA #FFFFFFFF
MENU COLOR PWDENTRY 5;44;30 #FF187CCA #FFFFFFFF
TIMEOUT 120
LABEL HDD
MENU LABEL Boot from first HDD
KERNEL chain.c32
APPEND hd0 0
ENDTEXT
LABEL TEST
MENU LABEL Install Ubuntu 20.04
KERNEL linux/linux
IPAPPEND 1
APPEND initrd=linux/initrd.gz url=http://server.local/preseed/ubuntu2.cfg auto=true priority=critical debian-installer/locale=en_US keyboard-configuration/layoutcode=us languagechooser/language-name=en_US countrychooser/shortlist=US localechooser/supported-locales multiselect en_US splash noprompt noshell ---
ENDTEXT

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

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

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

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

https://github.com/drumit/ubuntu_config/blob/master/ubuntu2.cfg

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

archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/20101020ubuntu614/legacy-images/netboot/ubuntu-installer/amd64

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

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

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

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

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

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

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

sudo apt install ansible
sudo nano /etc/ansible/hosts 
#это инвентори файл, в нем должны быть все управляемые компьютеры, по их hostname. либо  IP
#Синтаксис простой, в левой части произвольное имя, для нашего удобства, в правой части hostname или IP адрес.

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

ssh-keygen #(на сервере создаем пару приватный/публичный ключ) 

сd /home/localadm/.ssh/
ssh-copy-id localadm@192.168.*.*
#копируем публичный ключ с сервера на локальный компьютер (Затем, вводим пароль #локального администратора для локального ПК

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

ansible  all –m ping   

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

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

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

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

ansible-vault encrypt playbook3.yaml
#(введите пароль для зашифровки).

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

1. ansible-playbook playbook3.yaml –ask-vault-pass
2. вводим пароль локального администратора удаленного ПК
3.  вводим пароль шифрования

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

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

https://github.com/drumit/ubuntu_config/blob/master/playbook3.yaml

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

https://github.com/drumit/ubuntu_config/commits/master/krb5.conf

https://github.com/drumit/ubuntu_config/blob/master/samba.conf.j2

  
https://github.com/drumit/ubuntu_config/blob/master/nsswitch.conf.j2

https://github.com/drumit/ubuntu_config/blob/master/common-auth.j2

https://github.com/drumit/ubuntu_config/blob/master/common-account.j2

https://github.com/drumit/ubuntu_config/blob/master/common-password.j2

https://github.com/drumit/ubuntu_config/blob/master/common-session.j2

https://github.com/drumit/ubuntu_config/blob/master/common-session-noninteractive.j2

P.S. Упустил возможность написать выше о замечательном продукте Evolution который совместно с плагином Evolution-ews успешно взаимодействует по протоколу EWS с Exchange сервером, «отдавая» не только почту, но и вполне приемлемо взаимодействуя с календарем.

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

Так чем же плох Linux и подходит ли он для обычного пользователя? А для пользователя в корпоративной среде?

Если бы не слушатель курсов по Linux, преподавателем которых я являюсь, мне, как человеку, очень долго работающему с Linux, эта мысль вряд ли пришла бы в голову. На первый взгляд кажется, а зачем ЭТО вообще надо? Но по здравому размышлению предложенная идея показалась достаточно интересной, и захотелось посмотреть, как он будет работать.

С чего все началось? После рассмотрения темы, посвященной системе X Window и возможности запуска X-клиентов и X-серверов на разных машинах в сети, у слушателя возник вопрос: «А можно ли сделать так, чтобы все критические с точки зрения безопасности приложения выполнялись на Linux, а их вывод отображался на машинах с Windows?».

Вопрос показался странным — зачем устанавливать рабочие станции Windows, если так волнует безопасность? В системе Linux имеется полный набор офисного программного обеспечения, для их использования переобучать персонал почти не приходится. Как рабочая станция Linux — вполне приемлемое и безопасное решение. Разве что специфическое программное обеспечение, наподобие «1С Предприятие», на нем не установишь — для его выполнения потребуется терминальный сервер Windows.

Однако слушатель отверг такое решение, поскольку основными пользователями в его системе были дизайнеры, а им требуется специфичное ПО, отсутствующее в Linux. Проблемы возникают в основном с программами, где предусмотрен доступ в Internet: с почтовыми клиентами, браузерами и т. п. Установка антивирусных средств и обновление самой системы мало чем помогает. Поэтому, когда он услышал на занятии, что в Linux программа способна физически работать на одной машине, а отображать данные на другой, без потери качества изображения и скорости работы, у слушателя возник вполне естественный, с его точки зрения, вопрос о возможности отображать данные программ, работающих под управлением Linux, на компьютерах с Windows. Тогда все программы, обращающиеся в Internet, можно перевести на Linux, где они не подвержены вирусам и прочим возможностям взлома. Все файлы, получаемые клиентами из Internet, будут сохраняться исключительно на машине Linux, а там, где установлена Windows, останутся только окна с соответствующими программами.

ОБ ИСПОЛЬЗУЕМЫХ ТЕХНОЛОГИЯХ

В UNIX в качестве графической оболочки применяется система X Window, у которой имеется много различных реализаций — коммерческих, полукоммерческих и т. д. Что касается Linux, то на данный момент в основном используются XFree86 и xorg. Из-за проблем с лицензированием первая система отсутствует в современных дистрибутивах Linux, поэтому все чаще встречается xorg.

X Window построена по принципу клиент-сервер. Однако принцип взаимоотношения клиента и сервера поставлен «с ног на голову». Обычно под сервером или серверным приложением понимают какое-либо программное обеспечение, реализующее хранение информации или сложные вычисления. А клиент — это программа, позволяющая осуществлять управление или получать доступ к информации. В X Window сервер — программа для отрисовки изображения на экране, а назначение клиента — отображать данные на сервере, с использованием функций библиотеки Xlib. Таким образом, сервер X Window содержит драйверы видеокарты, клавиатуры, мыши и других устройств ввода и позволяет клиентским программам «рисовать» на экране монитора. Клиент и сервер могут находиться на различных машинах в сети. Более того, допустимо, чтобы на одном сервере «рисовали» несколько клиентов, каждый из которых выполняется на разных машинах.

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

Для отрисовки окон используется специальное программное обеспечение — оконный менеджер (Window Manager). От него зависит, как выглядят окна и как они себя ведут. Оконный менеджер — тоже X-клиент, т. е. для отображения окон он посылает данные на Х-сервер. Некоторые программы X-сервера, работающие под управлением Windows, имеют встроенный оконный менеджер.

И еще одна немаловажная для X Window программа — менеджер дисплеев (Display Manager). Х-терминал — это устройство, на котором нет ни одной программы. Все программы (X-клиенты) выполняются на каких-либо машинах, а на Х-терминале только отображаются данные. После включения Х-терминал подключается по протоколу X Display Manager Connect Protocol (XDMCP) к серверу, где установлен менеджер дисплеев, посредством которого клиент осуществляет вход в систему и запускает оконный менеджер. Так мы получаем полноценное рабочее место на машине UNIX с отображением рабочего стола на машине Windows. Все программы (включая оконный менеджер) будут выполняться на UNIX, а данные представит Windows.

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

РЕАЛИЗАЦИЯ X-SERVER ДЛЯ WINDOUS

Итак, какие же программы реализуют работу X-сервера на машине Windows? После непродолжительных поисков мне удалось найти три бесплатных сервера: Gygwin/X, WiredX на Java и условно бесплатный X-Deep/32.

Cygwin/X (http://x.cygwin.com). Широко известная в узких кругах компания Cygwin разрабатывает библиотеку cygwin1.dll для эмуляциии Linux API и занимается переносом на Windows набора популярных утилит GNU. Последние (gcc, ld и т. д.) распространяются по лицензии GNU GPL, однако библиотека cygwin1.dll имеет собственную, отличную от GPL лицензию, в соответствии с которой ее можно использовать в коммерческом программном обеспечении.

Cygwin/X — это перенос X Window System на различные виды ОС Windows. Продукт работает на всех видах Windows, начиная с Windows 95 и заканчивая Windows Server 2003. Cygwin/X содержит X-сервер, библиотеку X и набор стандартных Х-клиентов: xterm, xhost, xclock и др.

WeiredX (http://www.jcraft.com/weiredx). Компания JCraft специализируется на создании коммуникационных программ с использованием технологии Java. Большая часть программного обеспечения распространяется в соответствии с лицензией GNU GPL, в том числе сервер WeiredX. Кроме того, компания распространяет еще один сервер, но под коммерческой лицензией — WiredX.

WeiredX реализует все возможности стандартного X-сервера, а поставляемый с ним набор утилит расширяет их: JSch организует передачу данных по защищенному каналу, JRexec является клиентом rexec и т. д.

X-Deep/32 (http://www.pexus.com/). К сожалению, на сайте производителя не указаны особенности данного Х-сервера, лишь заявлено о полной совместимости с редакцией X11R6.5.1.

ПОДГОТОВКА МАШИНЫ LINUX

Для того чтобы Х-серверы могли взаимодействовать с машиной Linux, на ней следует, во-первых, завести учетные записи пользователей, а во-вторых, соответствующим образом настроить программу менеджера дисплеев, если планируется использовать полноценный вход в систему (наподобие X-терминала).

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

С менеджерами дисплеев ситуация несколько сложнее, поскольку с Linux могут поставляться три менеджера: xdm, gdm (Gnome) и kdm (KDE). Каждый настраивается различными способами. Мы будем использовать kdm.

Для конфигурации kdm необходимо:

• найти файл kdmrc. В разных дистрибутивах он находится в разных каталогах. Например, в Slackware Linux — в /opt/kde/share/config/kdm, в RedHat Linux — в /etc/X11/xdm;
• в файле kdmrc найти раздел [Xdmcp] и задать параметр Enable=true;
• в том же каталоге, где расположен kdmrc, имеется файл Xaccess, где описываются Х-терминалы, с которых возможно подключаться к менеджеру дисплеев. Чтобы всем разрешить такое подключение, в любую пустую строку необходимо поместить символ «*»;.
• в файле /etc/X11/xdm/xdm-config, в начале последней строки в параметре DisplayManager.requestPort следует указать символ «!»;
• если система X Window на сервере не настроена, т. е. не предполагается работать в графическом режиме на самом сервере, то в файле /etc/X11/xdm/Xservers рекомендуется поставить символ комментария «#» в начале строки «:0 local /usr/X11R6/bin/X»;
• если kdm не был запущен, его следует запустить. Если он уже активен, то следует указать, чтобы он перечитал свой конфигурационный файл — killall -HUP kdm;
• убедитесь, что kdm открыл на прослушивание порт 177: netstat -nlp | grep 177.

Теперь kdm готов к использованию.

УСТАНОВКА И КОНФИГУРАЦИЯ GYGWIN/X

Для установки Gygwin/X достаточно открыть главную страницу сайта и загрузить программу установки setup.exe.

Рисунок 1. Cygwin в режиме эмулятора терминала. Вход в систему.

Программу можно установить прямо из Internet или из каталога, куда она была сохранена заранее. Далее следует указать каталог, куда будет установлена программа, а также тип текстовых файлов (UNIX или DOS). Затем в предложенном списке серверов FTP отметить ближайший сервер.

В окне Select Packages необходимо выбрать следующие пакеты:

• xorg-x11-base (обязательно устанавливаемый базовый набор);
• xorg-x11-bin (рекомендуемый к установке набор содержасщий базовыми программами: xterm, twm и др.);
• xorg-x11-bin-dlls (рекомендуемый к установке набор с библиотеками, необходимыми для выполнения программ (DLL);
• xorg-x11-etc (обязательно устанавливаемый набор с конфигурационными файлами Х-сервера и программ);
• xorg-x11-fcyr (рекомендуемый к установке набор с русскими шрифтами);
• xorg-x11-fenc (обязательно устанавливаемый);
• xorg-x11-fnts (обязательно устанавливаемый);
• xorg-x11-libs-data (обязательно устанавливаемый набор с библиотеками);
• xorg-x11-xwin (обязательно устанавливаемый, Cygwin/X X Server);
• xterm: Xterm — X Terminal (рекомендуемый к установке набор с программой X-терминал).

Кроме того, в разделе Net следует включить установку openssh и openssl.

После установки Gygwin/X необходимо настроить. Конфигурационные параметры передаются Gygwin/X при запуске программы XWin.exe в ее командной строке. Для облегчения запуска поставляется специальный файл startxwin.bat.

Если в качестве основного каталога был выбран C:cygwin, то файл startxwin.bat следует искать в каталоге C:cygwinusrX11R6in. В нем необходимо найти строку run XWin -multiwindow -clipboard -silent-dump-error и дописать в конце -xkbrules xorg -xkbmodel pc104 -xkblayout «us,ru» -xkbvariant winkeys -xkboptions «grp:alt_shift_toggle». Добавленные параметры позволяют использовать русскую клавиатуру и по своему значению полностью совпадают с аналогичными параметрами конфигурационного файла Х-сервера xorg.conf в Linux.

РАБОТА С GYGWIN/X

После установки программы на рабочем столе создается ярлык Cygwin, посредством которого запускается оболочка bash, так что можно работать со знакомой командной строкой Linux. С ее помощью можно запустить Х-сервер в режиме Х-терминала: X -query 192.168.1.3. Вместо IP-адреса 192.168.1.3 следует указать IP-адрес компьютера, где находится менеджер дисплеев kdm. На экране должно появиться приглашение войти в систему на машине Linux. После входа активизируется оконный менеджер, и теперь можно работать на машине Linux с отображением данных в Windows.

Конечно, такой метод весьма ресурсоемок, при большом количестве клиентов для Linux следует установить мощный компьютер. Впрочем, Gygwin/X предполагает и другой режим, когда на машине Windows запускается Х-сервер, собственный оконный менеджер и программа эмуляции терминала. В этом случае для запуска используется файл startxwin.bat. Благодаря параметру -multiwindow, который передается при запуске XWin.exe, каждое приложение будет открываться в своем окне.

При использовании startxwin.bat не происходит подключение Х-сервера как Х-терминала, и поэтому на машине Linux не требуется настраивать менеджер дисплеев.

После запуска startxwin.bat появляется окно программы эмуляции терминала. Сначала необходимо разрешить удаленным программам отображать данные на Х-сервере, работающем в Windows. Для этих целей воспользуемся программой xhost: xhost +192.168.1.3. Вместо указанного в примере IP-адреса следует ввести IP-адрес машины Linux, на которой будут запускаться программы.

Рисунок 2. Выбор Displey Manager в X Deep/32

Потом необходимо зайти на машину с Linux при помощи программы ssh: ssh user@192.168.1.3 и указать имя пользователя машины Linux и ее IP-адрес.

Теперь сделаем так, чтобы программы, запускаемые на Linux, отображали свои данные в окне на машине Windows. Один из вариантов — использование переменной среды окружения DISPLAY: export DISPLAY=192.168.1.2:0.0. Вместо IP-адреса, указанного в примере, следует использовать IP-адрес машины Windows, на которой работает Х-сервер. Программы запускаются обычным образом.

УСТАНОВКА И НАСТРОЙКА WEIREDX

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

В каталоге, где был распакован архив, появится подкаталог config, в нем находится всего один конфигурационный файл — props. Все параметры сервера задаются в этом файле.

В файле props следует найти параметр weirdx.display.acl, чтобы определить, кому можно отображать данные на этом Х-сервере. Например: +192.168.1.3 или просто символ «+», если доступ разрешен всем.

Запуск сервера лучше производить посредством специального командного файла из каталога misc — weirdx-Java2.bat. Затем надо зайти на сервер Linux при помощи любой программы, поддерживающей протокол ssh (например PuTTY). Как и в случае с Gygwin/X, это необходимо для определения переменной DISPLAY и запуска программы.

WeiredX работал очень медленно (сказывается использование Java), и при отрисовке на экране появлялись черные полосы. В целом качество данного продукта разочаровало, поэтому снимки экрана с примерами работы WeiredX не приводятся.

УСТАНОВКА И НАСТРОЙКА X-DEEP/3

На сайте X-Deep/32 отсутствовала какая-либо документация по продукту, кроме FAQ. Установочный файл занимал почти 16 Mбайт, а для установки нужно 43 Mбайт свободного дискового пространства.

Сам процесс представляет собой обычную процедуру установки программы Windows. По его завершении была обнаружена документация по продукту и две программы: Х-сервер и X Client Launcher.

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

Правда, при первой попытке подключиться к менеджеру дисплеев не удалось: в сети требовалось настроить корректное преобразование имен. Но после запуска X-Deep/32 можно открыть окно настроек, где явным образом указать машину Linux, к которой следует подключаться.

И еще одна интересная возможность — сделать главное (root) окно Х-сервера прозрачным. Тогда на рабочем столе Windows будут видны пиктограммы Linux.

Рисунок 3. Linux Mozilla показывает данные в окне Windows.

Но при всей простоте установки и настройки Х-сервер показал себя не с лучшей стороны в плане производительности — Gygwin/X работает гораздо быстрее. Встроенная в X-Deep/32 возможность удаленного запуска программ опирается на rsh и rexec. Ни один здравомыслящий администратор эти программы использовать не будет. Таким образом, в случае X-Deep/32 остается довольствоваться режимом эмуляции Х-терминала, что не всегда удобно.

ИТОГИ

В результате проверки трех бесплатных серверов под Windows, наиболее приемлемой, по моему мнению, является реализация от cygwin. Несмотря на то что Х-сервер от cygwin требует установки почти всей базовой среды запуска, он работает великолепно. И это не удивительно, ведь он представляет собой стандартную реализацию сервера xorg, собранную в среде cygwin. Соответственно, при конфигурации сервера применяются те же приемы, что и в Linux.

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

X-Deep/32 мог бы оказаться лучшим выбором, если бы в нем имелась возможность нормального запуска программ или хотя бы встроенный клиент для удаленной регистрации на машине Linux.

Вероятно, существуют и другие бесплатные реализации Х-серверов для Windows, но при быстром поиске в Internet их обнаружить не удалось. Возможно, коммерческие Х-серверы способны продемонстрировать куда большую скорость работы и легкость конфигурирования, ведь не зря же их продают (цены колеблются от 40 до 300 долларов за рабочее место).

В заключение считаю нужным отметить, что содержать рабочие места под управлением Windows для того, чтобы несколько человек могли запускать специфичные для Windows программы, на мой взгляд, неудобно. Проще выделить один терминальный сервер под управлением Windows 2000 и разместить на нем специфичные программы — 1C, системы CAD и проч., а на рабочих местах использовать бездисковые рабочие станции под управлением Linux, на которых и запускать rdesktop, терминальный клиент для Windows (http://www.rdesktop.org).

Вопросы: Как включить функцию Windows Subsystem for Linux (WSL) на Windows Server 2019?

Как использовать Linux на Windows Server 2019?

В этом руководстве показано, как включить функцию Windows Subsystem for Linux (WSL) на сервере Windows 2019 и запустить сервер Linux, например Ubuntu, внутри Windows Server.

В нашей последней статье мы рассмотрели запуск контейнеров Docker на Windows Server.

Как запустить Docker Containers на Windows Server 2019

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

Одна предварительная версия уже установлена Windows Server 2019.

Достаточно повезло,что у нас есть руководство по установке Windows Server 2019.

Как установить Windows Server 2019 шаг за шагом

И его обзор

Полный обзор Windows Server 2019 — что нового?

Шаг 1. Включите функцию Windows Subsystem для Linux (WSL) в Windows

Прежде чем вы сможете установить любой дистрибутив Linux для WSL, вы должны убедиться, что включена функция «Windows Subsystem for Linux»:

Откройте PowerShell от имени администратора и выполните следующую команду, чтобы включить функцию Windows Subsystem for Linux (WSL) в Windows.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Согласитесь и перезагрузите компьютер при появлении соответствующего запроса.

Вы можете сделать то же самое из Диспетчер серверов графического интерфейса Server Manager>Add roles and features>Select features

Шаг 2: Установите свой Linux

Существуют различные способы установки дистрибутивов WSL Linux через Microsoft Store.

В этом руководстве мы будем использовать скачать и установить один из командной строки.

Запустите PowerShell и загрузите дистрибутив с помощью командлета Invoke-WebRequest или curl.exe. Вот пример инструкции по загрузке Ubuntu 18.04.

curl.exe -L -o ubuntu-1804.appx https://aka.ms/wsl-ubuntu-1804

После загрузки распакуйте и установите дистрибутив Linux.

Rename-Item ubuntu-1804.appx ubuntu-1804.zip
Expand-Archive ubuntu-1804.zip ubuntu1804

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

cd ubuntu1804
.ubuntu1804.exe

Программа установки предложит вам указать имя пользователя и пароль для создаваемого пользователя UNIX.

Команда sudo может использоваться для привилегированных операций.

sudo apt update && sudo apt upgrade
sudo apt install ansible

Образец вывода:

Добавьте свой путь к дистрибутиву в среду PATH среды Windows, используя Powershell:

$userenv = [System.Environment]::GetEnvironmentVariable("Path", "User")
[System.Environment]::SetEnvironmentVariable("PATH", $userenv + "C:UsersAdministratorubuntu1804", "User")

Это позволит вам запустить ваш дистрибутив с любого пути, набрав .exe загрузчик

Например, используя ubuntu1804.exe.

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

ubuntu1804.exe

Наслаждайтесь использованием дистрибутива Linux на вашем Windows Server. Другие дистрибутивы Linux, которые вы можете запустить:

• Ubuntu 18.04 ARM
• Ubuntu 16.04
• Debian GNU/Linux
• Kali Linux
• OpenSUSE
• SLES

В этой статье будет описан процесс добавления Linux-машины (Ubuntu 20.04) в домен Windows AD.

Шаг 1. Установка пакетов и подготовка

sudo apt updatesudo apt upgrade

sudo apt -y install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

Шаг 2. Настройка DNS

sudo nano /etc/netplan/*.yaml

network:ethernets:enp0s3:addresses:- 192.168.0.15/24gateway4: 192.168.0.10nameservers:addresses: [192.168.0.1, 192.168.0.2]search:- office.localoptional: trueversion: 2

• addresses — это IP, назначаемый сетевой карте;
• gateway4 — IP роутера;
• nameservers — DNS-сервера;
• search — целевой домен.

sudo netplan apply

Шаг 3. Обнаружение домена, присоединение к нему и проверка результата.

realm discover office.local

office.localtype: kerberosrealm-name: OFFICE.LOCALdomain-name: office.localconfigured: no...

realm join -U admin1 office.localPassword for admin1:

id user1@office.localuid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)

Шаг 4. Последние настройки и авторизация.

sudo nano /etc/sssd/sssd.conf

sudo systemctl restart sssdid useruid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)

sudo nano /etc/pam.d/common-session#add this line in the end of filesession optional pam_mkhomedir.so skel=/etc/skel umask=077

su – userPassword:Creating directory '/home/user1@office.local'.user1@ubuntu-server:~$

Это означает, что вы успешно вошли в систему как пользователь AD.

sudo realm deny –allsudo realm permit user0@office.local user1@office.localsudo realm permit -g 'Main Admins'

sudo nano /etc/sudoers.d/admins

user ALL=(ALL) ALL%Domain\ Admins ALL=(ALL) ALL

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А

+7 (812) 403-06-99

ООО «ИТГЛОБАЛКОМ ЛАБС»

Следующий шаг после установки WPS офиса в списке был – ввод Linux в домен Windows

В данной статье будет рассмотрен вопрос 🔥🔥🔥 о том, как нужно вводить компьютер под управлением ALT Linux в домен который находится на Windows Server 2012 ✅ (но версия тут не играет роли) и подготовительные шаги для этого действия, а также до настройка с подключением сетевых дисков и окна с логином ⭐️

подписывайтесь на мой канал Яндекс дзена!Вы будете первым узнавать  о новых материалах!

Вводим в домен Alt Linux

Для того что ввести станцию в домен надо сначала подготовить ее к этому, для этого делаем след шаги:

1. Выставляем на станции точное время (или время равное с контроллером домена)
2. Редактируем файл /etc/resolv.conf и прописываем там ДНС контроллера домена
   

   search имяДомена.lcl
   nameserver ДНСконтроллераДомена

3. Еще проверяем ДНС тут /etc/net/ifaces/<interface>/resolv.conf 
4. проверяем файл HOST /etc/hosts  
   

   127.0.0.1 localhost.localdomain localhost
   127.0.0.1 имяКомпа.имяДомена имяКомпа

5. если вы во время установки системы не ввели имя станции, то можно переименовать компьютер сейчас /etc/sysconfig/network
6. Теперь надо установить пакеты которые позволят ввести станцию в домен (Поставить все обновления на linux перед этим не забудте)

   apt-get install task-auth-ad-sssd

7. Заходим в настройки системы (или из терминала набираем AAC) и заходим в меню Аутентификация
8. Переключаем чекбокс на пункт Active Directory и заполняем эти моля так:
   

   Домен: ИМЯДОМЕНА.LCL
   Рабочая группа: ИМЯДОМЕНА
   Имя компьютера: имя компьютера

   PS соблюдайте регистр!!!

9. Нажимаем ок, вводим логип и пароля администратора Домена
10. Перезагружаем компьютер и проверяем )

Сейчас каждый подумает, что это сложно и долго, но если присмотреться, то все эти же действия мы делаем когда вводим в домен нашу станцию под Windows))) так что все не так и сложно!

Окно авторизации с логином

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

что бы в В Alt Linux такое сделать нужно сделать след:

1. открыть файл /etc/lightdm/lightdm.conf
2. находим строчку greeter-hide-users и после = пишем false (greeter-hide-users = false)
   

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

В прошлой статье я обещал рассмотреть механизм удаленного подключения с 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:

cat /etc/passwd | ConvertFrom-Csv -Delimiter ':' -Header Name,Passwd,UID,GID,Description,Home,Shell | Sort-Object Name | Format-Table

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

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

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

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

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

curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/microsoft.repo

yum install -y powershell

pwsh

После установки появилась возможность запускать привычные 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 командой:

yum install omi

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

/opt/omi/bin/service_control restart

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

winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/client @{AllowUnencrypted="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}

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

winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/OMI_Identify?__cimnamespace=root/omi -r:http://server:5985 -auth:Basic -u:root -p:"password" -skipcncheck -skipcacheck -encoding:utf-8 -unencrypted

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

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

/opt/omi/bin/omicli ei root/cimv2 Win32_Environment --auth Basic --hostname server -u username -p password --port 5985 

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

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

yum groupinstall 'Development Tools'
yum install openssl-devel pam-devel
git clone --recursive [https://github.com/PowerShell/psl-omi-provider.git](https://github.com/PowerShell/psl-omi-provider.git)

cd psl-omi-provider/
make release
rpm -ihv target/Linux_ULINUX_1.0_x64_64_Release/psrp-1.4.1-0.universal.x64.rpm

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

$cred = Get-Credential

#пропустим проверку сертификата для нашей тестовой лаборатории
$o = New-PSSessionOption -SkipCACheck -SkipRevocationCheck -SkipCNCheck

#выполнение команды:
Invoke-Command -ComputerName server -ScriptBlock { Get-Process } -Authentication Basic -SessionOption $o -Credential $cred -UseSSL | Select-Object -First 5

#подключение к консоли
Enter-PSSession -ComputerName 'server' -Credential $cred -Authentication basic -UseSSL -SessionOption $o

С Windows на Linux.

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

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

 Invoke-Command -ComputerName server1,server2,server3  -ScriptBlock { adduser admin;echo admin:password | chpasswd
 }

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

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

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

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

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

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

Установка OpenSSH описана в отдельной инструкции.

powershell -ExecutionPolicy Bypass -File install-sshd.ps1

.ssh-keygen.exe -A
.FixHostFilePermissions.ps1 -Confirm:$false

```bash
PasswordAuthentication yes
```

Subsystem   powershell C:/Program Files (x86)/PowerShell/6.0.0-beta.9/pwsh.exe -sshs -NoLogo -NoProfile

setx path "%path%;C:Program FilesOpenSSH"

Set-Service sshd -StartupType Automatic
Set-Service ssh-agent -StartupType Automatic
net start sshd

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

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

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

Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile

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

Сначала Windows:

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

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

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

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

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

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

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