Настройка киоска на Ubuntu для ресторанного меню: полное руководство

Настройка киоска на Ubuntu для ресторанного меню: полное руководство
kiosk mode ubuntu ubuntu kiosk chromium kiosk wayland kiosk linux kiosk

Если вы прямо сейчас настраиваете киоск на Ubuntu, то вряд ли собираете научный проект. Скорее всего, вам нужно, чтобы экран с меню, страницей заказа или гостевым интерфейсом работал без сбоев даже в часы пик: никто не должен случайно выйти на рабочий стол, запустить обновление или увидеть чёрный дисплей, после чего менеджер спросит, почему экран опять не работает.

Это меняет подход к созданию режима киоска на Ubuntu. Чистых демонстрационных сборок недостаточно. Киоск в ресторане обязан выдерживать беспорядочные касания, перебои питания, падения браузера, устаревшие сеансы и того самого сотрудника, который всегда находит жест, сворачивающий полноэкранный режим. Хорошая новость в том, что Ubuntu давно поддерживает администрирование в стиле киоска. Вики-страница сообщества Ubuntu описывает KioskMode с 2015-08-19, а последние обновления датированы 2026-05-02, что подтверждает: это не трюк для гиков, а давно сложившаяся практика в администрировании Ubuntu (документация Ubuntu KioskMode).

Содержание

Почему Ubuntu-киоски ломаются в реальных условиях

В девять вечера субботы никого не волнует, что киоск проходил тестирование на рабочем столе во вторник днём. Всех волнует, что экран меню только что погас, Chromium после жёсткого отключения питания показывает запрос на восстановление сессии, а кто-то из персонала нашёл способ выйти на рабочий стол, пытаясь «отвиснуть» зависшую страницу.

Именно так обычно и выходят из строя Ubuntu-киоски. Не потому, что Ubuntu не справляется с ролью киоска, а потому, что стандартная установка рабочего стола всё ещё ведёт себя как рабочая станция. Она хочет уходить в сон, ожидает чистого завершения работы, сохраняет состояние пользователя и исходит из того, что человек у экрана может добраться до настроек, если пощёлкает подольше.

Чаще всего я наблюдал такое на ресторанных табло с меню и экранах самообслуживания. При установке всё выглядит стабильно. Затем начинается обслуживание, в экран тыкают весь день, питание на розетку за дисплеем отключают без предупреждения, а в какой-то момент кто-то подключает клавиатуру, потому что «экран завис». Старые рецепты на LightDM и X11 помогли выполнить многие из этих задач, но они же оставляли массу лазеек. Более современные решения на Wayland закрывают часть этих брешей, однако привносят другие эксплуатационные компромиссы.

Типичные поломки, отнимающие время обслуживания

Практическое правило: Если для восстановления после обычного падения браузера всё ещё требуется присутствие человека на месте — киоск не готов к работе.

Узкое место обычно не в дилемме «веб-приложение или нативное приложение». Ключевой вопрос — какую часть стека рабочего стола вы готовы оставить нетронутой. Старые сборки Ubuntu-киосков часто использовали LightDM, пользователя с автовходом и скрипт запуска браузера поверх X11. Это до сих пор работает, особенно на старом оборудовании или в заведениях, где вы уже знаете все особенности. Но такой подход оставляет больше компонентов, за которыми нужно следить. Современные сеансы Wayland-киоска и сборки в стиле «бытового прибора» убирают часть этой поверхности атаки, но могут быть менее снисходительны, если вам нужны нестандартные периферийные устройства, устаревшие инструменты для цифровых вывесок или диковинные драйверы сенсорных экранов.

Развёртывание ресторанного меню делает этот компромисс очевидным. Если машина должна всего лишь загружаться, показывать TopFoodApp, восстанавливаться после сбоя и никогда не показывать рабочий стол, то урезанный сеанс киоска намного удобнее в эксплуатации, чем полноценный рабочий стол GNOME в маскировке. Если же на том же устройстве нужны ещё и средства удалённой поддержки, тестирование принтеров, вход персонала или ситуативное устранение неполадок, старый подход на базе рабочего стола выглядит заманчиво. Именно это удобство обычно и ломается первым.

Что действительно работает стабильно

Ubuntu-киоски, которые выживают в выходные, — это скучные киоски. Они используют выделенного пользователя киоска. Они отключают гашение экрана и ждущий режим на уровне ОС и сеанса. Они запускают браузер контролируемым путём, а не из случайного профиля оболочки. Они очищают или изолируют состояние браузера. Они автоматически перезапускают приложение, если оно завершилось.

Новые рекомендации Canonical по киоскам сместились в сторону Wayland-развёртываний, а не старой модели «рабочий стол плюс полноэкранный браузер», что является полезным сигналом, даже если вы по-прежнему выбираете X11 из соображений совместимости (Ubuntu Frame и современное направление развития киосков).

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

Выбор правильного подхода к киоску

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

Ubuntu предлагает три практически применимых сегодня модели киоска. Я отношусь к ним как к трём разным моделям отказов. Старый рецепт на X11 и LightDM легко изучить и быстро починить на месте. Более новый подход на Wayland и Frame убирает много наследия рабочего стола, но требует принимать более «приборный» стиль работы. Обычный браузерный киоск находится посередине и до сих пор является правильным ответом для многих ресторанных информационных табло.

Браузерный киоск для одного заведения

Киоск на Chromium или Firefox подходит лучше всего, когда TopFoodApp уже работает в браузере, а задача экрана проста: загрузиться, подключиться, показать меню, восстановиться после завершения браузера.

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

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

Киоск на основе Snap — установка как бытового прибора

Canonical неспроста двигает развёртывание Ubuntu-киосков в сторону Wayland-инструментария. Старый стек рабочего стола работает, но тащит за собой много деталей, которые не нужны на настенном экране меню. Старое руководство Canonical по Wayland-киоскам теперь направляет читателей к более новым методам, и это хороший маркер того, в каком направлении движется киоск-разработка Ubuntu (руководство по Wayland-киоску Ubuntu).

Для владельца ресторана, который хочет меньше возиться с настройками на уровне сеанса, связка Ubuntu Frame и пакета с киоск-приложением может оказаться аккуратнее, чем поддержка LightDM, файлов сеансов X11, флагов браузера и переопределений рабочего стола. Любительские руководства по этой модели обычно следуют одному шаблону: установите Frame, установите приложение киоска, подключите его к дисплейному серверу и дайте системе загружаться прямо на поверхность приложения (примерный процесс настройки в стиле Ubuntu Frame).

У этой более чистой модели есть компромисс. Ситуативные исправления делать менее удобно. Если персоналу нужен «чисто на секундочку рабочий стол» для проверки принтера или почты, такой подход будет этому сопротивляться, что для публичного экрана меню, как правило, хорошо.

Если ваше приложение уже поставляется в мобильной обёртке, а решение по оборудованию ещё не принято, сравните этот вариант с плагином Capacitor Kiosk для Android. «Железо» на Android может подойти лучше, когда требуется более жёсткое ограничение одним приложением, чем может дать перепрофилированный мини-ПК с Ubuntu.

Ubuntu Core и Frame для сети устройств

Для нескольких заведений я бы выбрал Ubuntu Core с Ubuntu Frame осознанно, а не пришёл к этому случайно. Он ведёт себя скорее как прибор, чем как обслуживаемый десктоп. Это важно, когда у вас экраны в нескольких ресторанах, и никто на месте не должен редактировать файлы автозагрузки после закрытия.

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

Сравнение подходов к киоску на Ubuntu

Подход Лучше всего для Обновления Восстановление Привязка
Браузерный киоск на Ubuntu Desktop Одиночные кафе, бары, разовые экраны меню Через apt и настройки браузера Легко отлаживать локально, но легче сломать Низкая
Киоск на основе Snap Небольшие сети, которым нужна повторяемость установок Управляется через Snap, с фокусом на приложение Более чистая модель перезапуска приложения Средняя
Ubuntu Core и Frame Сети из множества точек и «приборные» сборки Транзакционный процесс, похожий на работу с образами Наивысшая согласованность между устройствами Высокая

Ключевой вопрос не «веб или натив». Ключевой вопрос — хотите ли вы обслуживать сеанс рабочего стола, среду выполнения приложения или заблокированный прибор.

Для экранов ресторанного меню я по-прежнему начинаю с браузерного киоска, если нет явной причины отказываться от старой модели на X11 и LightDM. Если же оборудование будет интенсивно использоваться касаниями, развёртывание нужно повторять, или экраны отправляются в несколько заведений, то современный Wayland-маршрут обычно оправдывает дополнительные усилия по настройке.

Создание рабочего Chromium-киоска на Ubuntu

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

Скриншот с https://www.chromium.org/

Для одиночного экрана в ресторане Chromium на Ubuntu по-прежнему остаётся самым быстрым путём к тому, с чем персонал сможет жить уже сегодня вечером. Деталь, которую часто пропускают старые руководства, — это управление сеансом. --kiosk — лишь часть картины. Вам также нужны выделенный пользователь, автовход, который каждый раз попадает в правильный сеанс, постоянно выключенные настройки бездействия и механизм перезапуска на случай падения браузера.

Создайте пользователя киоска и ограничьте его окружение

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

Установите только то, что нужно киоску:

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

Аккуратно соберите старый путь на X11

Если вы связываете старые рецепты на LightDM с более новыми выпусками Ubuntu, относитесь к X11 как к осознанному выбору, а не как к унаследованному умолчанию. Для экранов ресторанных меню я до сих пор использую его на оборудовании, которое уже доказало свою стабильность с LightDM и Chromium. Это знакомая, легко отлаживаемая на месте и снисходительная система, когда нужно срочно поправить скрипт запуска.

Создайте drop-in-файл LightDM в /etc/lightdm/lightdm.conf.d/10-kiosk.conf и задайте:

Затем добавьте файл сеанса в /usr/share/xsessions/, который указывает на ваш скрипт запуска.

Этот скрипт запуска должен делать четыре вещи:

  1. Отключать гашение экрана и DPMS.
  2. Запускать unclutter.
  3. Запускать Chromium с флагами, безопасными для киоска.
  4. Завершаться так, чтобы systemd или сеанс могли его перезапустить.

Полезные флаги Chromium для дисплея меню:

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

Отключите прерывания на нужном уровне

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

В сборке с LightDM и пользовательским сеансом X11 старые инструменты X11 по-прежнему важны. xset s off, xset -dpms и xset s noblank следует поместить в скрипт-обёртку, если сеанс работает на X11. Изменение ключей GNOME на машине, которая никогда не входит в сеанс GNOME, — пустая трата времени, оставляющая ложное ощущение, что проблема решена.

Множество сборок киосков смешанной эпохи идут неправильно. Кто-то копирует настройки GNOME из руководства по Wayland в LightDM-киоск или наоборот, тащит команды X11 в более новый сеанс GNOME Kiosk и ожидает того же результата. Применяйте исправление к тому сеансу, который вы загружаете.

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

Тестируйте отказы, а не только запуск

Киоск, который выживает только после чистой перезагрузки, ещё не готов.

Прежде чем покинуть объект, проверьте эти сценарии:

Я также проверяю, что происходит после того, как браузер проработает несколько часов. Некоторые сенсорные оверлеи и дешёвые HDMI-переходники хорошо ведут себя десять минут, а потом начинают чудить по мере нагрева.

Быстрая визуальная демонстрация помогает, если вы проверяете флаги и поведение запуска прямо на месте:

Добавьте сторожевой механизм

Chromium рано или поздно упадёт. Заложитесь на это.

Простого сервиса systemd с Restart=always обычно достаточно для одноэкранной установки в ресторане. Если обёртка завершится или браузер умрёт, сеанс запустится снова, и персоналу не придётся трогать клавиатуру. В реальном мире этот шаг значит гораздо больше, чем выкраивание ещё одной минуты на начальную настройку.

Цель — скучное поведение. Питание вернулось. Сеть вернулась. Chromium вернулся. Меню снова на экране прежде, чем бармены решат, что коробка проклята.

Wayland против X11 и сеансы GNOME Kiosk

Сейчас основная путаница вокруг режима киоска на Ubuntu проистекает из одного факта. Старые руководства предполагают X11 и LightDM. Новые системы Ubuntu всё чаще направляют вас в сторону Wayland и сеансов киоска, ориентированных на GNOME. И то и другое может работать, но ведут они себя по-разному.

Недавнее практическое руководство, посвящённое безопасным Ubuntu-киоскам, прямо указывает на это несоответствие. В новых руководствах всё чаще упоминаются gnome-kiosk-script-wayland и настройка сеансовых файлов, тогда как старые рецепты по-прежнему полагаются на унаследованный автовход, Xsession и скрипты запуска браузера. Это оставляет администраторов гадать, какой путь подходит для какой версии Ubuntu и состава оборудования (разрыв между руководствами по Wayland и устаревшими рекомендациями).

Что меняется при переходе на Wayland

С Wayland композитор управляет большей частью сеанса. Гашение экрана, обработка ввода и поведение окон реализованы иначе. Многие старые привычки X11 не переносятся гладко, особенно всё, что завязано на xset, прямые хаки сеанса X или трюки оконного менеджера.

Это не плохо. Wayland-киоски часто чище. Но они безжалостно наказывают за бездумное копирование команд X11.

Чтобы проверить, что использует работающая система, посмотрите сеанс через loginctl и удостоверьтесь, что тип указан как wayland или x11. Не делайте предположений на основе одного лишь релиза Ubuntu.

Когда что использовать

Аспект Сеанс X11 Сеанс Wayland
Рецепты браузерных киосков Зрелые и широко документированные Более современные, меньше устаревших хаков
Особенности сенсорных экранов Лучше запасной вариант для старого оборудования Лучший вариант по умолчанию на актуальных Ubuntu
Управление питанием и гашением Часто на основе скриптов В большей степени управляется композитором
Блокировка сеанса Легче импровизировать Чище, если построено правильно
Сопровождение между версиями Устаревшие руководства всё ещё помогают Лучше согласуется с текущим направлением

Если вы разворачиваетесь на Ubuntu 22.04 или новее, а сенсорный экран относительно современный, я бы по умолчанию выбрал Wayland. Оставьте X11 для старых панелей, нестандартных графических стеков или древних контроллеров касаний, которые работают только с устаревшими драйверами.

Практическое правило выбора

Для автовхода GDM в сеанс киоска используйте путь, ориентированный на GNOME Kiosk, когда хотите оставаться близко к современному стеку рабочего стола Ubuntu. Для дисплейного прибора, управляемого композитором, более чистый путь — Ubuntu Frame. Для старого оборудования, которое уже работает на LightDM плюс Openbox или пользовательском сеансе X, не переписывайте всё только потому, что Wayland новее.

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

Если вы работаете с конфигурацией seat или обёртками сеансов, делайте их минимальными. Простейшая настройка seatd должна существовать только для поддержки того композитора или стека ввода, который вы используете. Не наваливайте устаревшие обходные решения X11 на Wayland-киоск, если только вы не доказали реальную аппаратную необходимость.

Сенсорные экраны, клавиатуры и работа с периферией

Киоск, который чисто загружается, всё равно может ощущаться ужасно в заведении, если сенсорный слой работает неаккуратно. Гости замечают это быстрее администраторов. Если экран регистрирует касания чуть мимо, если ввод получает не тот монитор или если экранная клавиатура выскакивает в случайный момент, сборка кажется сломанной, даже когда браузер технически работает.

Что нужно настроить перед передачей в эксплуатацию

Техническая иллюстрация, объясняющая настройку сенсорных экранов, клавиатур и периферии для систем в режиме киоска.

Чек-лист для заведения, который избавляет от повторных визитов

Когда я передаю киоск в кафе или баре, я провожу короткую проверку на месте:

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

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

Запуск меню TopFoodApp на Ubuntu-киоске

Браузерный Ubuntu-киоск хорошо подходит для платформ меню на основе QR, потому что у машины всего одна задача. Открыть публичный URL меню, оставаться в полноэкранном режиме и восстановиться, если браузер завершится. Это отделяет процесс публикации контента заведения от оборудования дисплея.

Скриншот с https://topfoodapp.com/kiosk-mode-ubuntu-menu.png

Соответствие на операционном, а не только техническом уровне

Для экранов меню я бы установил публичный URL меню в качестве стартовой страницы Chromium и подобрал размер окна под фактическую ориентацию панели. Портретные табло требуют иных допущений, нежели дисплеи на стойке. Если локаль браузера должна определять выбор языка, поведение при запуске должно это учитывать, а не заставлять персонал переключаться вручную.

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

Реальные заметки с внедрений

Поведение в офлайне имеет значение. Если Wi-Fi в заведении ненадёжен, либо положитесь на кеш браузера для временной устойчивости, либо обеспечьте киоску отдельный резервный канал связи, например, скромный 4G-модем. Это часто ценнее, чем потратить ещё час, пытаясь заставить нестабильный гостевой Wi-Fi выглядеть стабильным.

Я также стараюсь минимизировать интерактивность:

Если вы оцениваете, насколько самообслуживание через киоски оправдано с точки зрения бизнеса, а не только технической реализации, полезно проанализировать затраты и окупаемость. В России стоимость одного киоска обычно колеблется от 30 000 до 80 000 рублей, в зависимости от комплектации, а в Казахстане — приблизительно от 150 000 до 400 000 тенге. Это стоит учитывать при планировании.

Для команд, которые ещё не настроили свой стек меню, бесплатный конструктор меню снижает порог входа, позволяя протестировать работу киоска с реальным URL меню, а не с пустышкой.

Усиление защиты, удалённые обновления и регламент обслуживания

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

Инфографика с чек-листом из четырёх шагов по безопасности и обслуживанию при настройке Linux-киоска.

Что нужно заблокировать

Удалите лишние пункты рабочего стола, если они не нужны машине. Отключите в активном сеансе сочетания для выхода и переключения пользователя. Если вы остаётесь на Ubuntu Desktop, контролируйте обновления пакетов, чтобы киоск не «уплыл» посреди обслуживания. Если вы управляете множеством устройств, распространяйте изменения централизованно, например, через Ansible или подписанный репозиторий, а не правьте каждый блок в точке вручную.

Ночная перезагрузка до сих пор остаётся практичным решением для долго работающих сеансов браузера. Это не элегантно, но часто предотвращает медленно накапливающиеся странности на необслуживаемых экранах.

Ритм обслуживания, который действительно работает

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

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

TopFoodApp даёт ресторанам быстрый способ публиковать меню на основе QR-кодов, которые отлично работают на экранах Ubuntu-киосков, особенно когда вам нужен один стабильный публичный URL и мгновенное редактирование меню без вмешательства в сам киоск. Если вы создаёте дисплей меню, экран на стойке или решение для самообслуживания, стоит протестировать свой браузерный киоск на реальном ресторанном процессе с TopFoodApp.

Опубликовано:
← Назад в блог