I touched X11 for the first time in 30 years to run wrangler login. YouTube audio came with it.

Я вперше торкнувся X11 за 30 років, щоб запустити wrangler login. До цього також з’явилося аудіо з YouTube.

https://ift.tt/6ehIEn4

Про що цей допис

Ось що фактично я зробив:

• Я хотів запустити wrangler login на сервері Ubuntu без GUI для проекту Cloudflare Workers
• Я вже знав, що API Token — правильне рішення
• Але все одно хотів перевірити, чи зможе переадресація X11 перенести вікно браузера на macOS
• Працювало
• Потім я зловився на цьому: додав переадресацію PulseAudio і в підсумку запускав YouTube-відео та аудіо з боку macOS

Оточення:

• хостова macOS
• VMware Fusion
• гостьова Ubuntu Server 24.04

Чому я взагалі торкнувся X11 у 2026 році

Я працював над проектом Cloudflare Workers і потребував запустити:

wrangler login

Це запускає браузер для автентифікації через OAuth.

Проблема була проста: моє робоче середовище — Ubuntu Server, а не Ubuntu Desktop. Немає GUI, немає локального браузера, немає екрану OAuth.

На той момент існували дві очевидні опції:

Я з самого початку знав, що API Token — розумна відповідь.

Я використав X11 все одно.

Частково через те, що хотів дізнатися, чи це все ще працює. Частково через те, що минуло близько 30 років від того часу, як я востаннє торкнувся X11, і, здається, я приймаю погані рішення в історично‑точному стилі.

Етап 1: Базова настройка переадресації X11

На macOS: встановіть XQuartz

brew install --cask xquartz
open -a XQuartz

На Ubuntu Server: встановіть потрібні пакети

sudo apt install -y xauth x11-apps

Увімкніть X11 переадресацію в sshd

sudo vi /etc/ssh/sshd_config

Розкоментуйте або встановіть:

X11Forwarding yes
X11DisplayOffset 10

Потім перезапустіть SSH:

sudo systemctl restart sshd

X11DisplayOffset підказує sshd, який номер дисплея використовувати для перенаправлених сесій X11. За замовчуванням це 10. На практиці $DISPLAY часто завершується приблизно на localhost:10.0, якщо цей номер дисплея вже не зайнятий.

Перевірте

З macOS спочатку підключіться з xterm у XQuartz:

ssh -Y user@ubuntu-vm

Потім на Ubuntu:

echo $DISPLAY
xclock &

Якщо на вашому Mac з’явиться вікно годинника, переадресація X11 працює.

Одна річ, яка мене збила з пантелику

В моєму середовищі вже відкритий сеанс Terminal.app не надійно навчався отримати придатний $DISPLAY, тоді як xterm від XQuartz працював стабільно.

Це не означає, що Terminal.app суто несумісний.

Можливі причини включають:

• XQuartz був встановлений, але я ще не повністю вийшов та не увійшов знову
• файли ініціалізації оболонки, такі як ~/.bashrc або ~/.zshrc, перезаписували $DISPLAY

Отже, якщо переадресація X11 поводиться дивно, швидкий спосіб перевірки — використати власний xterm від XQuartz.

Пастка з Firefox — Snap знову повірне

Моя перша спроба була очевидна:

firefox &

Вона була закрита помилкою:

X11 connection rejected because of wrong authentication.

Чому?

У Ubuntu 22.04 і пізніше Firefox зазвичай постачається через Snap. Ізоляція Snap та переадресація X11 у такій конфігурації не дуже гарно працюють.

Підтвердити це можна так:

which firefox
# /snap/bin/firefox

Тож я перейшов на нестандартну збірку без Snap.

Етап 3: Встановлення firefox-esr за допомогою прив’язки APT

Я використав PPA mozillateam і встановив firefox-esr.

Важлива деталь: якщо робити це неакуратно, пізніше операції apt install / apt upgrade можуть повернути вас до переходу Ubuntu на поточну версію Firefox та шлях Snap.

Тож я чітко прив’язав це:

sudo add-apt-repository -y ppa:mozillateam/ppa

sudo tee /etc/apt/preferences.d/mozilla-firefox << 'EOF'
Package: firefox*
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001
Package: firefox*
Pin: release o=Ubuntu
Pin-Priority: -1
EOF
sudo apt update
sudo apt install -y firefox-esr

Кілька зауваг:

• цей PPA mozillateam не той самий, що офіційний APT-репозиторій Mozilla на packages.mozilla.org
• я використав його тут, бо він вирішував практичну проблему
• Pin-Priority: 1001 чітко надає перевагу цьому джерелу
• Pin-Priority: -1 блокує відповідні кандидати пакета від Ubuntu

Потім:

firefox-esr &

І цього разу вікно браузера дійсно з’явилося на macOS.

Я також отримав такі попередження:

No matching fbConfigs or visuals found
glx: failed to create drisw screen

Вони виглядали драматично, але на практиці означали лише те, що апаратне прискорення GPU не виконується. Браузер все ще працював.

Етап 4: wrangler login нарешті працює

Тепер початкова мета:

wrangler login

Firefox ESR відкрився, з’явилася сторінка аутентифікації Cloudflare і успішно пройшов вхід.

На цьому завдання було фактично завершено.

Якими повинна була бути фінальна точка? Так само повинна була.

Замість цього мій мозок одразу поставив набагато гірше запитання:

Якщо Firefox вже з’явився на macOS, чи можу я зробити так, щоб звідти також передавалося аудіо з YouTube?

Так починаються проєкти, які гниють.

Етап 5: Чому відео працює, але аудіо ні

На цьому етапі відео з YouTube відображалося через X11 без проблем.

Аудіо — ні.

Це очікувано, бо X11 ніколи не був розроблений для переадресації аудіо.

X11 переадресовує:

• команди відображення вікна
• вхідні дані клавіатури
• вхідні дані миші

X11 не переадресовує аудіо:

• аудіо

Тож якщо потрібно було також аудіо, потрібен був інший шлях.

Етап 6: Переадресація PulseAudio

Ідея була такою:

• запустити PulseAudio сервер на macOS
• відкрити його для Ubuntu через SSH зворотне портове перенаправлення
• наказати Firefox на Ubuntu використати цей перенаправлений PulseAudio‑вузол

Ось так:

На macOS: встановіть і запустіть PulseAudio

brew install pulseaudio
mkdir -p ~/.config/pulse

Далі запустіть його на передньому плані:

pulseaudio --load="module-native-protocol-tcp auth-anonymous=1 auth-ip-acl=127.0.0.1" \
           --exit-idle-time=-1 --daemonize=no

Можуть з’явитися попередження:

W: [] caps.c: Normally all extra capabilities would be dropped now...
W: [] socket-util.c: IP_TOS failed: Invalid argument

У моєму випадку вони не ламали нічого.

auth-anonymous=1 допустимий тут лише тому, що це тимчасова побудова за SSH‑тунелюванням і обмежена до localhost. Відкривати це більш широко було б ризиковано.

Так, це хитро. Ні, я не зробив би цього на реальному сервері.

Також варто зауважити: PulseAudio тут ще працює, але його розробники заявляють, що розвиток зменшився, а більші нові задачі переходять у PipeWire / WirePlumber. Для такого хак‑рішення це все ще зручно.

На Ubuntu Server: встановіть пов’язані з аудіо пакети

sudo apt install -y ubuntu-restricted-extras ffmpeg libavcodec-extra pulseaudio

Цей допис розрахований на Ubuntu Server 24.04. На Ubuntu Desktop 24.04 PipeWire / pipewire-pulse є більш стандартною базою, тому бездумне додавання PulseAudio може зробити налаштування заплутаним.

Етап 7: SSH з одночасною переадресацією X11 та аудіо

З macOS:

ssh -Y -R 24713:localhost:4713 user@ubuntu-vm

Тлумачення:

Номер порту 24713 не був магічним. Я просто взяв стандартний порт PulseAudio 4713 і додав 20000, щоб його було легко розпізнати і менше ймовірності конфліктів.

Чому -Y, а не -X?

Ця частина має значення:

Використовуйте -Y лише з машинами, якими повністю керуєте.

Надійчий X11‑клієнт може робити погані речі, зокрема моніторинг клавіатури. На вашій власній VM за вашим SSH‑підключенням — ок. На сервері іншої людини — зовсім ні.

Етап 8: Вказати Ubuntu на перенесений PulseAudio сервер

На Ubuntu:

export PULSE_SERVER=tcp:localhost:24713
firefox-esr &

На цьому обидва YouTube відео та аудіо проходили через macOS.

Проти всього гідності це спрацювало.

Чому відео й аудіо залишалися синхронізованими

Справедливе питання тут таке:

X11 і PulseAudio — це два різних протоколи на двох різних шляхах переадресації. Чому аудіо не зрушувало сильно в бік?

Відповідь полягає в тому, що синхронізацію обробляв Firefox, а не X11 або PulseAudio.

• медіа-потік містить часові штампи
• Firefox планує кадри відео та частинки аудіо відповідно до цих часових штампів
• обидва потоки затримуються тунелем, але приблизно однаково
• тому відтворення залишає можливість прийнятної синхронізації

Тобто тут немає елегантного протокольного механізму синхронізації. Це поведінка на рівні прикладного шару, яке тримає весь «бардак» на собі.

Примітки з безпеки

Слабке місце тут не сам X11.

Це ви, що експлуатуєте довіру нечітко.

Як зазвичай.

Що я з цього виніс

1. X11 — давній, але все ще дивно спроможний

Дизайн старий, здається зворотним і трохи проклятим.

І все ж:

• сервір відображення живе на машині з екраном
• приклад запускається десь інде
• інтерфейс все одно з’являється там, де потрібно

Ця ідея древня, але не мертва.

2. Маленькі UNIX‑приклади все ще складаються абсурдним чином

• SSH обробляє шифрування та тунелювання
• X11 обробляє віддалені вікна
• PulseAudio обробляє транспортування аудіо
• Firefox «зклеює» користувацький досвід разом

Ні одна частина не була надзвичайно елегантна.

Разом вони були достатньо добрі, щоб запустити щось безглуздо смішне.

3. Правильна відповідь все ще була API Token

Дозвольте бути дуже чітким:

Якщо ваша реальна мета — просто коректно використовувати Cloudflare Workers на безголовому комп’ютері, використовуйте API Token.

Це лишається правильною відповіддю.

Цей допис — про побічне завдання.

Кінцевий результат

Я почав з рішення нудної проблеми:

• запустити wrangler login на Ubuntu Server без локального GUI

В результаті вийшло щось набагато тупіше й набагато цікавіше:

• Firefox, що прямує через X11, на macOS
• успішний вхід через OAuth Cloudflare
• PulseAudio, тунелюваний через SSH
• відео з YouTube і аудіо, що відтворюються через хост-машину

Чи було це необхідно? Ні.

Чи це було правильне рішення? Також ні.

Чи спрацювало?

Набагато дратівнішою мовою — так.

Мораль історії: іноді правильне рішення — нудне. Веселе рішення — X11 + PulseAudio + сумнівні життєві рішення.

HI-FI News

через DEV Community https://dev.to

20 квітня 2026 р. о 17:58

April 20, 2026 at 05:58PM