Побег от WSL или как превратить старый ноутбук в домашний сервер для хранения данных и удаленной работы

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

Поднять файлопомойку с рабочим стеком на Linux — это тоже прогресс 🧠📁⚙️

Получилось что-то вроде мини-датацентра у меня дома — он хранит файлы на жёстком диске с бэкапом в облаке, 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 года выпуска.

По команде neofetch терминал Ubuntu выдает всю информацию о железке

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

Задумал связать все рабочие устройства на Linux😎🛠️

Помимо разгрузки основного ПК, отдельный сервер даёт ещё плюсы, например, можно не беспокоиться, что внеплановая перезагрузка 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, установщик разобьёт диск на подразделы автоматически.

По командеdf -h терминал покажет разделение SSD/HDD после установки

Во время установки ОС и после советую оставить проводное интернет-соединение 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 — за вдохновением — туда 😜).

Открытые данные — топливо для пингвинотопливных ракет GNU/Linux 🚀🐧

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

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 — это и танец, и общая папка для себя и близких с бэкапом на облаке

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

— А можно ли сделать общую папку, куда можно скидывать файлы со своего компа? — Да без проблем!

Решено поднять 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.

   

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) до сервера под разработку. Старичок-ноутбук, надеюсь, всё вытянет потихоньку.

Макет веб-интерфейса Home Assistant

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

Выводы

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

Схема архитектуры домашнего сервера, от Docker-контейнеров до будущего терминала умного дома, — на старом ASUS

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

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