Linux сервер в windows окружении

Discover which Windows Server versions are compatible with the Windows Subsystem for Linux (WSL). According to the latest guidelines from Microsoft, You can run Linux on Windows Server 2019 with WSL. This compatibility extends to several releases of the Windows Server Semi-Annual Channel (SAC), including versions 1909, 2004, 20H1, 20H2, and the more recent Windows Server 2022.

For those interested in running Linux GUI applications through WSL, there’s a helpful guide titled “How to Install Linux GUI Apps in Windows 10 and Windows 11 with WSL” available on Petri. This resource provides a step-by-step approach to enhancing your WSL experience.

The Installation Process of WSL on Windows Server

The process of installing WSL on Windows Server offers an intriguing perspective, primarily because the procedure varies depending on the specific version of Windows Server in use. One notable distinction is the support, or lack thereof, for WSL 2 distributions on Windows Server 2019 and 2022. This stands out as a significant difference when compared to the installation on Windows 10 and 11.

However, beyond this key point, the overall experience of utilizing WSL on Windows Server parallels that on Windows 10 or 11. The process is akin to setting up Hyper-V across these platforms. Just as you would enable Hyper-V and use the Hyper-V Manager to create virtual machines on Windows 10 and 11, similarly, WSL allows for a seamless transition between using it on Windows client systems and Windows Server environments.

Getting Started with WSL on Windows

Activating WSL on Your System

To kick off the process of using Linux distributions through WSL, the first action is to activate the “Windows Subsystem for Linux” feature on your computer.

• Through PowerShell: Open PowerShell with administrator privileges and input the following command to turn on the WSL feature in Windows:
• Copy code

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

• Confirm and proceed with the system restart when prompted to ensure the changes are applied.

• Via Server Manager (For Server Users): If you’re working with a server, the same result can be achieved graphically. Navigate to the Server Manager, select “Add roles and features,” then go to the “Features” section to enable WSL.

These steps lay the groundwork for installing your preferred Linux distributions under the Windows Subsystem for Linux, streamlining the integration of Windows and Linux environments on your machine.

Initiating Your Preferred Linux Distribution with WSL

Once you’ve enabled the Windows Subsystem for Linux (WSL), the next step is to select and install your desired Linux distribution. This section guides you through the process using the command line, particularly focusing on acquiring a Linux distribution directly.

Downloading and Installing a Linux Distro via Command Line

1. Obtain Your Linux Distribution

Begin by opening PowerShell. You can download your chosen Linux distro using the Invoke-WebRequest cmdlet or curl.exe. For example, to download Ubuntu 20.04, you would use the following command:

“`

curl.exe -L -o ubuntu-2004.appx https://aka.ms/wslubuntu2004

“`

1. Prepare and Install the Distro

Once downloaded, you need to prepare the file for installation:

– Rename the downloaded file to a .zip format for extraction:

“`

Rename-Item ubuntu-2004.appx ubuntu-2004.zip

“`

– Extract the contents of the zip file:

“`

Expand-Archive ubuntu-2004.zip ubuntu2004

“`

– Navigate into the extracted directory and run the installation executable:

“`

cd ubuntu2004

.\ubuntu2004.exe

“`

During installation, you’ll be prompted to create a UNIX username and password. This step is essential for securing your new Linux environment.

Setting Up and Updating Your Linux Environment

After installation, it’s a good practice to update and install essential packages:

– Update your system’s package list and upgrade all your installed packages to their latest versions:

“`

sudo apt update && sudo apt upgrade

“`

– To install additional tools or software, use the apt install command. For instance, installing Ansible:

“`

sudo apt install ansible

“`

Integrating Your Linux Distro into the Windows Environment

To seamlessly operate your Linux distro from any location within PowerShell, add the distro path to your Windows environment PATH. This can be accomplished with the following PowerShell commands:

“`

$userenv = [System.Environment]::GetEnvironmentVariable("Path", "User")

[System.Environment]::SetEnvironmentVariable("PATH", $userenv + ";C:\Users\Administrator\ubuntu2004", "User")

“`

After updating the PATH, you’ll need to restart PowerShell to apply the changes. Now, you can launch your Linux distro directly from any directory by typing its executable name, such as `ubuntu2004.exe`.

This setup provides a flexible and integrated environment for running Linux alongside your Windows Server, offering the best of both worlds for developers and system administrators.

Уровень сложностиСредний

Время на прочтение10 мин

Количество просмотров17K

Привет, Хабр! Хочу поделиться личным опытом превращения старенького ноутбука ASUS X552CL (i5-5200U, 12 ГБ RAM, SSD + HDD), выпущенный 12 лет назад, в полноценный домашний сервер под Linux Ubuntu Server 24.04.5 LTS.

Картинка с сайта: habr.com

Получилось что-то вроде мини-датацентра у меня дома — он хранит файлы на жёстком диске с бэкапом в облаке, Docker-контейнеры крутит для дата-аналитики и даже имеет легковесный интерфейс XFCE, при этом есть потенциал к росту до терминала для управления умным домом. Расскажу, почему было решено отказаться от WSL на рабочем ноутбуке Huawei, как настроить удалённый доступ через xRDP (чтобы не было чёрного экрана), запустить там Docker, сборку Superset и JupyterLab с Anaconda (с разными версиями Python), прикрутить Samba-шару для домашнего использования и организовать бэкап в облачное хранилище. В этой статье будет немного технических деталей, чуть-чуть шуток и парочка мемов с советскими плакатами.

Зачем отдельный сервер вместо WSL на основном ноутбуке?

Началось всё с раздражения от багов на основном рабочем ноутбуке после запуска WSL (Windows Subsystem for Linux) — Windows стал ощутимо подтормаживать после запуска ресурсоёмких задач в Docker-контейнерах. Стало проблематично активно пользоваться Python, JupyterLab, Superset в сборке — для pet-проектов и быстрых аналитических MVP. В какой-то момент параллельная работа Windows-приложений и WSL с нагрузкой стала слишком тяжелой для нового бойца — вентиляторы воют, батарея тает на глазах, да и вообще неприятно, когда основная система проседает из-за бекграунд-задач. И вот в бой вступил старичок — лежавший в пыли несколько лет, но проверенный временем ASUS X552CL — рабочая лошадка для типовых прикладных задач.

Мне пришла в голову простая мысль «а если взять отдельную машину под все эти linux-сервисы?» И тут вспомнился мой старый добрый ASUS X552CL 2013 года выпуска.

Картинка с сайта: habr.com

Он пылился на полке, но всё ещё был в рабочем состоянии. Пусть слабенький i5 и всего 12 ГБ оперативки — зато свой собственный, выделенный Linux, который не жалко нагружать по полной. Решено — поднимаю домашний сервер.

Картинка с сайта: habr.com

Помимо разгрузки основного ПК, отдельный сервер даёт ещё плюсы, например, можно не беспокоиться, что внеплановая перезагрузка Windows (привет, обновления) убьёт длительный расчёт в Jupyter с выгрузкой в Superset через SQL Lab. Плюс, весь нужный софт можно настроить один раз под себя в Linux-среде и запускать как угодно долго. Короче говоря, WSL — это хорошо, но выделенный Linux-сервер — лучше (по крайней мере, для моих задач).

Установка Ubuntu Server 24.04 с XFCE — почему минимализм рулит?

На старый ноут поставьте свежайший Ubuntu Server 24.04.5 LTS (без графической оболочки, только терминал). Почему серверная версия? Потому что она изначально более легковесная, там ничего лишнего, только базовая система без окружения рабочего стола. Как раз то, что надо для слабого железа. Установка проходит штатно (с USB флешки, используя текстовый установщик Ubuntu Server). Достаточно загрузить дистрибутив (3 ГБ) на флешку через Rufus (Windows) или balenaEtcher (Windows/Linux/macOS). Во время установки ОС загрузить дополнительные драйверы для видеокарты и установить всю ОС на SSD, установщик разобьёт диск на подразделы автоматически.

Во время установки ОС и после советую оставить проводное интернет-соединение Ethernet, так установщику будет легче обновить компоненты и найти новые драйверы, а стабильное соединение не уронит все развёрнутые инструменты в будущем. После установки добавьте XFCE — легковесную графическую оболочку, чтобы при желании можно было подключаться по Remote Desktop и иметь привычный графический интерфейс. Обновите систему и поставьте сам XFCE.

sudo apt update && sudo apt upgrade -y
sudo apt install -y xfce4 xfce4-goodies

Почему XFCE, а не что-то другое? XFCE славится скромным аппетитом к ресурсам и неприхотливостью. Запускать на старом ноуте полный GNOME или KDE будет слишком жирно, а XFCE — в самый раз. К тому же, работать с сервером по SSH и через веб-интерфейсы (типа JupyterLab) лучше на постоянно поднятых localhost без необходимости поднимать их снова после перезапуска системы. Но иногда удобнее покликать мышкой в удалённом рабочем столе — например, настроить ту же Samba через файловый менеджер или показать что-то приятелю на экране.

Пакет xfce4-goodies ставит дополнительные полезные штуки для XFCE (плагины, утилиты — пусть будут). После этого установите xRDP для RDP-доступа.

sudo apt install -y xrdp
sudo systemctl enable --now xrdp

Теперь самое интересное — настройка xRDP с XFCE и борьба с чёрным экраном. Если попробовать подключиться по умолчанию, то велик шанс увидеть просто чёрный экран вместо рабочего стола — беда всего Windows — чёрный и синий экраны. Пришлось немного погуглить форумы (спасибо dmosk.ru и официальным мануалам на manpages.ubuntu.com — за вдохновением — туда 😜).

Картинка с сайта: habr.com

В итоге найдено такое решение.

1. Создайте файл с командой запуска XFCE при RDP-сессии. Проще всего положить команду в ~/.xsession для конкретного пользователя. Она укажет xRDP запускать сессию XFCE (xfce4-session) при логине.

   echo "xfce4-session" > ~/.xsession

2. Отключите переменные окружения, которые мешают запуску. Откройте файл /etc/xrdp/startwm.sh командой sudo nano /etc/xrdp/startwm.sh от имени администратора и добавьте две строки перед запуском Xsession. Вставьте в начало файла (или перед строкой test -x /etc/X11/Xsession && exec /etc/X11/Xsession) команды.

   unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR

   Сохраните файл Ctrl+O → Enter → Ctrl+X.

3. Перезагрузите xRDP.

   sudo systemctl restart xrdp

После этих настроек удалённый рабочий стол будет работать штатно. Подключайтесь с Windows через стандартный клиент RDP (запускается через PowerShell по команде mstsc). Важно! В окне входа xRDP выбирайте сессию Xorg, а не Xvnc или что-то другое. Зачастую вариант Xorg прекрасно запускает XFCE-сессию. Если выбрать не тот тип сессии, опять можете получить пустой (чёрный, синий) экран. Также убедитесь, что в данный момент тот же пользователь не залогинен локально на ноутбуке — xRDP не любит одновременный локальный и удалённый вход под одним пользователем.

Чтобы подключиться с винды, нужно ввести IP-адрес своего домашнего сервера в локальной сети. Узнать его легко по выводу команды ip a в терминале Linux Ubuntu.

Пример вывода по команде ip a.$ ip a
2: wlp4sds0: ...
inet 192.168.1.100/28 brd 192.168.1.255 scope global dynamic noprefixroute wlp3sds0
...

В выводе ищем свой интерфейс (Ethernet или Wi-Fi, у меня wlp3sds0 для Wi-Fi) и смотрим после inet. Вот, в примере вывода, 192.168.1.100 — это и есть локальный IP сервера. Вбиваем этот IP в Windows в «Подключение к удалённому рабочему столу», вводим учётные данные Ubuntu-пользователя – и вуаля, получаем рабочий стол XFCE. Теперь старенький ноутбук радостно показывает свой экран в окошке RDP.

Кстати, производительность XFCE через RDP оказалась вполне сносной. Основная же работа всё равно идёт через терминал и Docker, о чём далее.

Samba — это и танец, и общая папка для себя и близких с бэкапом на облаке

После настройки базовой системы сразу возникает запрос от Домашнего Заказчика 😊

Картинка с сайта: habr.com

Решено поднять Samba-сервер на Ubuntu, чтобы Windows-устройства в сети видели ноутбук как файловое хранилище. Благо на Ubuntu Samba настраивается элементарно.

1. Установите Samba и создайте папку на втором диске (HDD) для шаринга.

   sudo apt install -y samba sudo mkdir -p /mnt/storage/share sudo chown -R nobody:nogroup /mnt/storage/share sudo chmod -R 0777 /mnt/storage/PublicShare

   Проще выбрать простейший вариант — общий ресурс без авторизации (guest access). В локальной домашней сети безопасность не критична, зато все домашние устройства подключаются без лишних логинов. Откройте конфиг Samba (sudo nano /etc/samba/smb.conf) и добавьте в самый конец файла запись.

   [PublicShare]
path = /mnt/storage/PublicShare
browseable = yes
guest ok = yes
read only = no
force user = nobody

   Сохраните файл Ctrl+O → Enter → Ctrl+X.

   

   Картинка с сайта: habr.com

2. Перезапустите сервер Samba

   sudo systemctl restart smbd

   Теперь мой виден в локальной сети. На Windows достаточно открыть проводник и ввести \\192.168.1.100\PublicShare — общая папка открывается, можно читать/писать. Никаких флешек и Telegram-файлов, всё по Wi-Fi напрямую на сервер. Роднулькины довольны, да и админу сервера удобно файлы перекидывать между устройствами.

3. Дополнительно, чтобы важные данные не хранились только на этом стареньком HDD, настройте резервное копирование в облачное хранилище, например, Я.Диск. Для этого используйте утилиту Yandex.Disk для Linux (она есть в репозиториях) под учёткой своего аккаунта. Смонтируйте Я.Диск в систему и настройте cron задачу, которая раз в ночь синхронизирует содержимое общей папки с облаком. Теперь даже если диск ноутбука накроется, копия файлов будет в облаке. Вы спите спокойно и домашний бухгалтер (в лице кого угодно близкого) — тоже.

   Крутятся Docker-контейнеры — JupyterLab с Anaconda, несколько Python и PostgreSQL

   Конечно, главный смысл всего этого затеянного сервера – запускать рабочие окружения – например, Docker-контейнеры с JupyterLab, где крутятся Python-проекты.

   1. Установите Docker CE из стандартного репозитория Ubuntu (на самом деле, можно было и snap-версию, но эта статья скорее для консерваторов).

      sudo apt install -y docker.io docker-compose sudo usermod -aG docker $USER # чтобы не требовался sudo для docker

      После команды стоит перелогиниться или выполнить newgrp docker, чтобы права применились.

   2. Docker на Ubuntu стартует как служба. Убедитесь что он запущен.

      sudo systemctl status docker (вывод должнен включать active (running)).

   3. Далее — дело техники. Стягивайте образы с JupyterLab. Можно иметь окружения сразу с двумя версиями Python (скажем, для разных проектов требуется 3.10 и 3.11). Чтобы не мучаться с установкой нескольких версий на сам сервер, берите готовые образы Jupyter с нужными Python внутри. Нашёл официальные образы jupyter/base-notebook с тегами под Python 3.10 и 3.11 – самое то, плюс там уже предустановлен JupyterLab и conda (Anaconda). Запустите оба контейнера.

      docker run -d -p 8888:8888 --name jupyter-py310 jupyter/base-notebook:python-3.10.10

      docker run -d -p 8889:8888 --name jupyter-py311 jupyter/base-notebook:python-3.11.5

      Оба контейнера запускаются в фоне (-d), первый мапит порт 8888, второй – 8889 на хосте (чтобы одновременно могли работать). Через пару минут образы скачались и сервисы JupyterLab внутри поднялись. Проверяю командой docker ps – оба контейнера Up. Отлично! Теперь можно заходить в браузере на адрес сервера с указанными портами: http://192.168.1.4:8888 для Python 3.10 (и :8889 для 3.11). JupyterLab спросит токен – его можно увидеть через docker logs jupyter-py310 (в выводе логов Jupyter есть URL с токеном). Ввожу токен – и попадаю в знакомый интерфейс JupyterLab, только теперь он крутится на моём домашнем сервере.

      Замечу, что эти образы содержат Anaconda (то есть пакетный менеджер conda и куча библиотек уже внутри). Это удобно, потому что сразу есть и NumPy, Pandas, SciPy и т.д. Если чего-то не хватает, можно добить через pip или conda внутри контейнера. С точки зрения Windows-ноутбука – никакой нагрузки, всё считается и обрабатывается на своём сервере с ОС Linux Ubuntu, а вы получаете картинку через браузер без утечки данных с локали.

А как же данные и базы? Для проектов в аналитике может быть нужен PostgreSQL. Его на сервере также лучше не вручную разворачивать, а запустить в Docker-контейнере для удобства связки с остальными инструментами. Заодно есть возможность взаимодействия контейнеров.

Поднимем PostgreSQL.

1. Первая команда запустит Postgres 15, создаст пользователя test с паролем secret и откроет порт 5432 для доступа.

   docker run -d --name pg-db -e POSTGRES_USER=test -e POSTGRES_PASSWORD=secret -p 5432:5432 postgres:15

2. Чтобы Jupyter (который в контейнере) смог достучаться до Postgres, их нужно либо в одну сеть поместить, либо коннектиться по IP хоста. Для удобства создайте общую докер-сеть и подключите сервисы к ней.

   docker network create dev-net
docker network connect dev-net jupyter-py310
docker network connect dev-net jupyter-py311
docker network connect dev-net pg-db

Теперь внутри контейнера Jupyter можно обращаться к хосту pg-db (Docker имена резолвятся в этой сети) на порт 5432. Например, в ноутбуке psycopg2.connect(host=»pg-db», port=5432, user=»test», password=»secret») — и всё работает. Конечно, можно было и просто на хостовой машине установить Postgres, но где наша не пропадала — контейнеризация рулит, все сервисы изолированы и управляются централизованно.

Отдельно отмечу испытание для ноутбука на i5 с 12 ГБ RAM в части запуска одновременно нескольких таких контейнеров (2 Jupyter + Postgres). К удивлению, даже старичок справляется. Когда не пользуетесь каким-то из сервисов, их можно останавливать командой docker stop ... и освобождать ресурсы. В этом прелесть Docker — окружения поднимаются и глушатся по требованию, а не висят всё время в памяти и не тормозят остальные процессы. В итоге старенький ASUS превращается… превращается в маленький личный сервер для разработки — можно с любого компьютера подключиться к JupyterLab и Postgers через браузер и заниматься своими аналитическими проектами в связке с Superset.

Терминал умного дома в будущем

Сейчас ресурc используется как сервер-файлопомойка и удалённый терминал для аналитикии. Но на этом не стоит останавливаться. В планах – прокачать его до центра управления умным домом. Благо он всегда включён и в сети, грех не воспользоваться.

• Установить Home Assistant – следить за датчиками, управлять лампочками, розетками, да хоть умный чайник с компьютерного кресла поставить перед кофе-брейком и дождаться, пока закипит;

• Поднять MQTT-брокер (например, Mosquitto) для обмена сообщениями между IoT-устройствами;

• Подключить USB-донглы для Zigbee/Z-Wave, чтобы сервер мог общаться с датчиками и девайсами напрямую;

• Реализовать систему видеонаблюдения. Те же IP-камеры могут записывать на HDD, а смотреть можно через веб-интерфейс — Home Assistant или ZoneMinder/Frigate;

• Да и вообще, идей масса — от собственного медиа-сервера (Plex или Jellyfin) до сервера под разработку. Старичок-ноутбук, надеюсь, всё вытянет потихоньку.

Картинка с сайта: habr.com

Конечно, важно помнить об ограничениях — i5-5200U не станет мощнее просто и вдруг😅. Скорее всего, придётся докупить планку памяти – лишней не будет. А в крайнем случае более современную видеокарту можно будет подключить через Thunderbolt.

Выводы

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

Картинка с сайта: habr.com

Самое приятное — это ощущение, что сделал маленький личный “облачный” сервер. Хочешь – разворачивай новую БД, хочешь – подними очередной контейнер с редисом или даже веб-приложение — на железке десятилетней давности.

Так что не спешите выбрасывать или продавать раритет — ему можно дать вторую жизнь в новом амплуа. Возможно, старый ноутбук тоже скучает по работе – превратите его в полезный домашний сервер, это увлекательно и практично. Ну а если по ходу дела встретите трудности – заглядывайте на форумы, читайте мануалы и never give up 👌