Como Criar um Quiosque Chromium no Ubuntu para Cardápios de Restaurante

Como Criar um Quiosque Chromium no Ubuntu para Cardápios de Restaurante
kiosk mode ubuntu ubuntu kiosk chromium kiosk wayland kiosk linux kiosk

Se está a montar um quiosque Ubuntu neste momento, provavelmente não está a construir um projeto de ciência. O objetivo é manter um menu, uma página de pedidos ou um ecrã voltado para o cliente a funcionar durante o serviço intenso, sem que alguém consiga entrar no ambiente de trabalho, disparar atualizações ou deixar o ecrã preto com um gerente a perguntar porque é que o ecrã morreu outra vez.

Isso muda a forma como se constrói o modo quiosque no Ubuntu. Demonstrações simples não bastam. Um quiosque num restaurante tem de sobreviver a toques abusivos, quedas de energia, falhas do navegador, sessões obsoletas e àquele funcionário que descobre sempre o gesto de canto que sai do ecrã inteiro. A boa notícia é que o Ubuntu já suporta administração ao estilo quiosque há muito tempo. O Wiki de Ajuda da Comunidade Ubuntu documentou o KioskMode desde 2015-08-19, com atualizações tão recentes como 2026-05-02, o que deixa claro que isto não é um truque recente, mas um padrão antigo na administração Ubuntu (documentação Ubuntu KioskMode).

Índice

Porque é que os quiosques Ubuntu falham no mundo real

Às 21h de um sábado, ninguém quer saber se o quiosque passou nos testes na banca na terça à tarde. Querem saber porque é que o ecrã do menu ficou preto, o Chromium voltou com um aviso de restauro após um corte de energia ou um funcionário encontrou uma forma de sair para o ambiente de trabalho ao tentar descongellar a página.

E é assim que os quiosques Ubuntu costumam falhar. Não porque o Ubuntu não consiga desempenhar a função de quiosque, mas porque uma instalação de secretária padrão continua a comportar-se como tal. Quer suspender, espera encerramentos limpos, mantém o estado do utilizador e presume que a pessoa que toca no ecrã tem permissão para aceder às definições se clicar o tempo suficiente.

Vejo isto com mais frequência em painéis de menu de restaurante e ecrãs de autosserviço. A instalação parece estável durante a configuração. Depois o serviço começa, o equipamento é tocado o dia todo, o circuito que alimenta o ecrã é desligado sem aviso e, eventualmente, alguém liga um teclado porque “o ecrã estava bloquado”. Velhas receitas com LightDM e X11 conseguiram dar conta de muitos destes trabalhos, mas também deixaram muitas portas de saída abertas. Abordagens mais recentes baseadas em Wayland fecham algumas dessas lacunas, ao mesmo tempo que introduzem diferentes escolhas operacionais.

As falhas comuns que custam tempo de serviço

Regra prática: Se uma falha normal do navegador ainda exige uma pessoa no local, o quiosque não está pronta para produção.

O ponto fraco normalmente não é "aplicação web vs nativa". A decisão fundamental é quanto da pilha de secretária se está disposto a deixar no lugar. Construções de quiosque Ubuntu mais antigas usavam frequentemente o LightDM, um utilizador com autologin e um script de lançamento do navegador sobre X11. Isso ainda pode funcionar, especialmente em hardware mais antigo ou em locais onde já conhece as peculiaridades. Mas também deixa mais peças para vigiar. As sessões modernas de quiosque baseadas em Wayland e as configurações ao estilo de eletrodoméstico removem parte dessa superfície de ataque, mas podem ser menos tolerantes se precisar de periféricos personalizados, ferramentas de sinalização antigas ou controladores táteis esquisitos.

Uma implementação de menu de restaurante torna a escolha evidente. Se a máquina só precisa de arrancar, mostrar o TopFoodApp, recuperar de uma falha e nunca expor um ambiente de trabalho, uma sessão de quiosque simplificada é mais fácil de manter do que um ambiente GNOME completo disfarçado. Se o local também precisar de ferramentas de suporte remoto, testes de impressão, inícios de sessão de funcionários ou resolução de problemas pontual na mesma máquina, o padrão antigo baseado no ambiente de trabalho é tentador. Essa conveniência é frequentemente o primeiro ponto de rotura.

O que realmente se aguenta

Os quiosques Ubuntu que sobrevivem aos fins de semana são os aborrecidos. Usam um utilizador de quiosque dedicado. Desativam o escurecimento e a suspensão do ecrã ao nível do sistema operativo e da sessão. Lançam o navegador a partir de um caminho de arranque controlado, e não a partir de um perfil de shell aleatório. Limpam ou contêm o estado do navegador. Reiniciam a aplicação automaticamente se esta sair.

As orientações mais recentes da Canonical para quiosques moveram-se para a implementação nativa em Wayland, em vez do antigo padrão “secretária mais navegador em ecrã intero”, o que é um sinal útil mesmo que ainda escolha o X11 por razões de compatibilidade (Ubuntu Frame e a direção moderna dos quiosques).

O que se aguenta em produção não é a construção mais bonita. E a que tem menos partes móveis e que ainda suporta o hardware, o navegador e o plano de recuperação. Esse é o padrão que utilizo para ecrãs de menu de cafés e bares, porque a máquina acabará por ser reiniciada de forma errada, tocada com as mãos molhadas e cul.pada por um problema de rede que não causou.

Escoller a Abordagem Certa para o Quiosque

Às 16h, um quiosque Ubuntu com secretária completa parece flexível. Às 21 h, quando o ecrã do menu caiu para um ecrã de início de sessão e os funcionários estão a fazer fila para o jantar, a flexibilidade é normalmente o problema.

O Ubuntu oferece-lhe três padrões de quiosque que ainda são práticos hoje. Encaro-os como três modelos de falha diferentes. A velha receita com X11 e LightDM é fácil de inspecionar e rápida de reparar no local. A nova abordagem com Wayland e Frame remove muita bagagem de secretária, mas pede que aceite um fluxo de trabalho mais ao estilo de eletrodoméstico. Um quiosque simples de navegador fica no meio e continua a ser a resposta certa para muitos painéis de menu de restaurante.

Quiosque de navegador para um único estabelecimento

Um quiosque com Chromium ou Firefox encaixa melhor quando o TopFoodApp já corre no navegador e a função do ecrã é simples: arrancar, ligar, mostrar o menu, recuperar se o navegador sair.

Este é o caminho que ainda uso primeiro para um único restaurante ou um bar com um ou dois ecrãs. Mapeia-se de forma limpa para o velho manual de administração Ubuntu. Utilizador dedicado, autologin, início de sessão controlado, navegador em ecrã intero, caminhos de saída restritos. Se o sítio é o produto, embrulhá-lo como uma aplicação nativa muitas vezes acrescenta trabalho sem resolver os problemas que o acordam à noite.

Esses problemas são operacionais. Os perfis do navegador ficam sujos. O estado em cache fica obsoleto. Uma atualização do navegador pode alterar o comportemento de reprodução automática, pop-ups ou GPU sem aviso. Nada disto torna os quiosques de navegador uma má escolha. Significa que precisa de uma construção que possa reiniciar rapidamente.

Quiosque baseado em Snap para instalações mais simples

A Canonical tem empurrado as implementações de quiosque Ubuntu para ferramentas nativas em Wayland por uma razão. A antiga pilha de secretária funciona, mas carrega muitas partes de que não precisa num ecrã de menu montado na parede. O tutorial mais antigo da Canonical para quiosque Wayland agora aponta os leitores para métodos mais recentes, o que é um marcador útil para onde foi a direção do quiosque Ubuntu (Tutorial Ubuntu Wayland kiosk).

Para um operador de restaurante que quer menos ajustes ao nível da sessão, o Ubuntu Frame e um pacote de aplicação de quiosque podem ser mais limpos do que manter o LightDM, ficheiros de sessão X11, flags do navegador e substituições do ambiente de trabalho. Os guias da comunidade para esse modelo seguem geralmente o mesmo padrão: instalar o Frame, instalar a aplicação de quiosque, ligá-la ao servidor de ecrã e deixar o sistema arrancar diretamente para a superfície da aplicação (Fluxo de configuração ao estilo Ubuntu Frame).

Esse modelo mais limpo tem uma contrapartida. As correções pontuais são menos convenientes. Se os funcionários quiserem “só um ambiente de trabalho rápido” para testar a impressora ou o email, esta abordagem combate-os, o que normalmente é bom num ecrã de menu virado para o público.

Se a sua aplicação já é distribuída num wrapper móvel e a decisão de hardware ainda está abert, compare isto com o plugin Capacitor Kiosk para Android. O hardware Android pode ser mais adequado quando precisa de uma imposição de aplicação única mais rigorosa do que um mini PC Ubuntu reaproveitado.

Ubuntu Core e Frame para vários locais

Para vários estabelecimentos, Ubuntu Core com Ubuntu Frame é aquele que eu escolheria de propósito, em vez de cair nele por acaso. Comporta-se mais como um eletrodoméstico do que como uma secretária mantida. Isso é importante quando tem ecrãs em vários restaurantes e ninguém no local deve editar ficheiros de arranque depois do fecho.

O custo é a flexibilidade. Perde-se algum do velho hábito Ubuntu de iniciar sessão, alterar um script e voltar ao negócio cinco minutos depois. Para um único painel de menu por cima de um balcão, isso pode parecer pesado. Para uma frota, muitas vezes compensa-se por manter cada caixa consistente.

Comparação das abordagens de quiosque no Ubuntu

Abordagem Melhor Para Atualizações Recuperação Fixidez
Quiosque de navegador no Ubuntu Desktop Cafés únicos, bares, ecrãs de menu pontuais Gerido através de apt e definições do navegador Fácil de depurar localmente, mas mais fácil de estragar Baixa
Quiosque baseado em Snap Pequenas cadeias que querem instalações repetíveis Gerido por Snap e centrado na aplicação Modelo de reinício da aplicação mais limpo Média
Ubuntu Core e Frame Frotas múltiplas e construções tipo eletrodoméstico Transacional, fluxo de trabalho semelhante a imagem Maior consistência entre dispositivos Maior

A questão principal não é “web ou nativa”. E se quer manter uma sessão de secretária, um runtime de aplicação ou um eletrodoméstico bloquado.

Para ecrãs de menu de restaurante, continuo a começar com o quiosque de navegador, a menos que haja uma razão clara para deixar o velho padrão X11 e LightDM para trás. Se o hardware é muito tátil, a implementação precisa de ser repetível ou os ecrãs se destinam a vários locais, a rota Wayland moderna normalmente compensa o trabalho extra de configuração.

Construir um Quiosque Chromium Funcional no Ubuntu

Às 21 h de um sábado, ninguém quer saber se o Chromium arrancou uma vez durante a configuração. Querem saber que o painel de menu voltou depois de uma oscilação de energia, não caiu para o ambiente de trabalho e não deixou um ponteiro do rato estacionado sobre a lista de bebidas. Esse é o padrão que utilizo para um quiosque Ubuntu.

Screenshot from https://www.chromium.org/

Para um único ecrã de restaurante, o Chromium no Ubuntu continua a ser o caminho mais rápido para algo com que os funcionários possam viver esta noite. A parte que os tutoriais antigos muitas vezes saltam é o controlo da sessão. --kiosk é apenas uma peça. Também precisa de um utilizador dedicado, autologin que entre na sessão certa sempre, definições de inatividade que fiquem desligadas e um caminho de reinício para falhas do navegador.

Criar um utilizador de quiosque e mantê-lo simples

Use uma conta local separada para o ecrã. Não reutilize o início de sessão de secretária de um gerente, e não deixe o quiosque partilhar um perfil normal do navegador. Perfis partilhados acumulam extensões, avisos guardados, avisos de atualização e outro lixo que aparece mais tarde no ecrã ativo.

Instale apenas o que o quiosque precisa:

Também mantenho o estado do navegador no seu próprio diretório de perfil. Isso facilita as reposições. Se uma cache de site ficar corrompida antes do serviço, pode limpar uma pasta em vez de procurar por uma conta de secretária geral.

Criar o caminho X11 antigo de forma limpa

Se estiver a fazer a ponte entre receitas mais antigas de LightDM e versões mais recentes do Ubuntu, trate o X11 como uma escolha deliberada, não como um padrão residual. Para painéis de menu de restaurante, ainda o uso em hardware que já se mostrou estável com LightDM e Chromium. E familiar, fácil de depurar localmente e tolerante quando precisa de mexer num script de arranque à pressa.

Crie um drop-in do LightDM em /etc/lightdm/lightdm.conf.d/10-kiosk.conf e defina:

Depois adicione um ficheiro de sessão em /usr/share/xsessions/ que aponte para o seu script de lançamento.

Esse script de lançamento deve fazer quatro tarefas:

  1. Desativar o escurecimento do ecrã e o DPMS.
  2. Iniciar o unclutter.
  3. Lançar o Chromium com flags seguras para quiosque.
  4. Sair de forma a que o systemd ou a sessão o possam reiniciar.

Flags úties do Chromium para um ecrã de menu:

Deixe o pacote de navegador do sistema em paz se a máquina estiver de resto estável. Coloque o seu comportemento personalizado no ficheiro de sessão e no script wrapper. Os quiosques são mais fáceis de recuperar quando os ficheiros da distribuição permanecem próximos do original.

Desativar interrupções na camada certa

O Ubuntu ainda presume que está a executar uma secretária, a menos que lhe diga o contrário. A suspensão, o escurecimento, os ecrãs de bloqueio e as ações de inatividade têm de ser desativados onde a sessão ativa os vai ler.

Numa construção com LightDM e sessão X personalizada, as velhas ferramentas X11 ainda importam. xset s off, xset -dpms e xset s noblank pertencem ao script wrapper se a sessão for X11. Alterar chaves do GNOME numa máquina que nunca entra numa sessão GNOME é perda de tempo e deixa-o com uma falsa sensação de que o problema está resolvido.

Muitas construções de quiosque de eras mistas correm mal. Alguém copia definições do GNOME de um guia Wayland para um quiosque LightDM, ou copia comandos X11 para uma sessão de quiosque GNOME mais recente e espera o mesmo resultado. Faça corresponder a correção à sessão que arranca.

Para menus que mudam ao longo do dia, o modelo de navegador mantém as operações simples. Os funcionários atualizam a aplicação web, não a caixa por cima do balcão. Esse mesmo padrão funciona bem para atualizações de menu QR em tempo real em vários locais.

Testar falhas, não só o arranque

Um quiosque que só sobrevive a um reinício limpo ainda está inacabado.

Antes de sair do local, teste estes casos:

Também verifico o que acontece depois de o navegador estar a correr há algumas horas. Algumas sobreposições táteis e adaptadores HDMI baratos comportam-se bem durante dez minutos, depois começam a fazer coisas estranhas à medida que o calor aumenta.

Uma verificação visual rápida ajuda se estiver a validar flags e comportamento de lançamento no local:

Adicionar um watchdog

O Chromium vai acabar por crashar. Construa para isso.

Um serviço systemd simples com Restart=always é normalmente suficiente para uma instalação de ecrã único em restaurante. Se o wrapper sair ou o navegador morrer, a sessão recomeça sem que os funcionários toquem num teclado. Este passo único importa mais na prática do que poupar mais um minuto na configuração inicial.

O objetivo é um comportamento aborrecido. A energia volta. A rede volta. O Chromium volta. O menu está de volta ao ecrã antes de o pessoal do bar decidir que a caixa está amaldiçoada.

Wayland vs X11 e Sessões de Quiosque GNOME

A maior parte da confusão em torno do modo quiosque no Ubuntu vem agora de um facto. Os guias antigos assumem X11 e LightDM. Os novos sistemas Ubuntu apontam-no cada vez mais para Wayland e sessões de quiosque orientadas ao GNOME. Ambos podem funcionar, mas não se comportam da mesma forma.

Um guia recente focado em quiosques Ubuntu seguros aborda diretamente este desencontro. Os guias mais recentes mencionam cada vez mais gnome-kiosk-script-wayland e configuração de ficheiros de sessão, enquanto as receitas antigas ainda dependem do autologin herdado, Xsessions e scripts de lançamento do navegador. Isto deixa os operadores a adivinhar qual o caminho adequado a cada versão do Ubuntu e combinação de hardware (lacuna de orientação entre Wayland e o quiosque herdado).

O que muda no Wayland

Com o Wayland, o compositor detém mais da sessão. O escurecimento do ecrã, o manuseamento da entrada e o comportamento das janelas são aplicados de forma diferente. Vários hábitos antigos do X11 não se transpõem de forma limpa, especialmente qualquer coisa que dependa de xset, hacks diretos de sessão X ou truques de gestor de janelas.

Isso não é mau. Os quiosques Wayland são muitas vezes mais limpos. Mas punem comandos X11 copiados à pressa.

Para verificar o que um sistema em execução está a usar, consulte a sessão com loginctl e confirme se o tipo é wayland ou x11. Não assuma com base apenas na versão do Ubuntu.

Quando usar cada um

Aspeto Sessão X11 Sessão Wayland
Receitas de quiosque de navegador Maduras e amplamente documentadas Mais modernas, menos hacks herdados
Esquisitices de ecrã tátil Melhor alternativa para hardware antigo Melhor padrão no Ubuntu atual
Controlo de energia e escurecimento Muitas vezes baseado em scripts Mais orientado ao compositor
Bloqueio de sessão Mais fácil de improvisar Mais limpo se construído da forma certa
Manutenção entre versões Os guias herdados ainda ajudam Melhor alinhamento com a direção atual

Se estiver a implementar no Ubuntu 22.04 ou mais recente e o ecrã tátil for razoavelmente recente, eu optaria por Wayland como padrão. Mantenha o X11 para painéis antigos, pilhas de GPU esquisitas ou controladores táteis ancestrais que só se comportam com drivers herdados.

Regra prática de decisão

Para autologin GDM numa sessão de quiosque, use o caminho orientado ao quiosque do GNOME quando quiser manter-se perto da pilha de secretária moderna do Ubuntu. Para um eletrodoméstico de ecrã gerido pelo compositor, o Ubuntu Frame é a rota mais limpa. Para hardware antigo que já funciona com LightDM mais Openbox ou uma sessão X personalizada, não o reescreva só porque o Wayland é mais recente.

O movimento errado é misturar os dois modelos numa única máquina e esperar que as partes úteis de cada pilha cooperem.

Se estiver a trabalhar com configuração de seat ou wrappers de sessão, mantenha-os mínimos. Uma configuração seatd básica deve existir apenas para suportar o compositor ou a pilha de entrada que executa. Não acumule soluções de recurso X11 herdadas num quiosque Wayland, a menos que tenha provado uma necessidade real de hardware.

Ecrãs táteis, teclados e periféricos

Um quiosque que arranca de forma limpa pode ainda assim parecer horrível no local se a camada tátil for desleixada. Os clientes notam isso mais depressa do que os administradores. Se o ecrã registar os toques ligeiramente deslocados, se o monitor errado receber a entrada, ou se um teclado no ecrã aparecer aleatoriamente, a construção parece estar partida, mesmo quando o navegador está tecnicamente a correr.

O que ajustar antes da entrega

Um gráfico de guia técnico que explica como configurar ecrãs táteis, teclados e periféricos para sistemas de modo quiosque.

Lista de verificação do local que evita deslocações extra

Quanto entrego um quiosque num café ou bar, faço esta verificação rápida no local:

Para os operadores que constroem ecrãs de menu voltados para o client, a mesma disciplina aplica-se à camada de conteúdo. Um bom hardware de quiosque não pode salvar um menu confuso. Este tutorial sobre como criar um menu digital com fotos gratuitamente é útil porque o ecrã e o design do menu precisam de se apoiar mutuamente.

Um quiosque estável parece invisível. Ninguém comenta porque ninguém repara na máquina. Apenas usam o ecrã.

Executar Menus do TopFoodApp num Quiosque Ubuntu

Um quiosque Ubuntu baseado em navegador encaixa-se bem em plataformas de menu baseadas em QR porque a máquina tem apenas um trabalho. Abrir o URL público do menu, manter-se em ecrã intero e recuperar se o navegador sair. Isso mantém o fluxo de publicação do local separado do hardware de visualização.

Screenshot from https://topfoodapp.com/kiosk-mode-ubuntu-menu.png

A compatibilidade é operacional, não apenas técnica

Para ecrãs de menu, eu definiria o URL público do menu como página inical do Chromium e ajustaria o tamanho da janela à orientação real do painel. Os painéis verticais precisam de pressupostos diferentes dos ecrãs de balcão. Se o idioma do navegador deve conduzir a seleção do idioma, o comportemento de lançamento deve respeitá-lo, em vez de forçar os funcionários a fazerem uma troca manual.

A parte útil deste modelo é que o quiosque não precisa de tarefas cron, scripts de sincronização de conteúdo local ou cópias manuais de ficheiros sempre que o local muda um prato. O navegador simplesmente carrega a página ao vivo. Se o operador alterar o conteúdo do menu, o quiosque reflete-o na atualização.

Notas reais de implementações

O comportamento offline é importante. Se o Wi-Fi do local não for fiável, ou se apoie no comportamento de cache do navegador para uma resiliência temporária, ou dê ao quiosque uma alternativa de conetividade separada, como um modesto dongle 4G. Issão é frequentemente mais valioso do que gastar mais uma hora a tentar fazer com que o Wi-Fi público instável pareça estável.

Também mantenho a interação apertada:

Se estiver a avaliar se os ecrãs de autosserviço fazem sentido do ponto de vista do negócio além da configuração técnica, esta análise dos custos e do ROI de quiosques de restaurante é um companheiro útil do lado empresarial da construção Linux.

Para as equipas que ainda não configuraram a sua pilha de menus, um criador de menus gratuito reduz a barreira, porque pode testar o fluxo de trabalho do quiosque contra um URL de menu real, em vez de uma página fictícia.

Reforço, Atualizações Remotas e Lista de Manutenção

O pior pressuposto no trabalho com quiosques é achar que, uma vez que o ecrã arranca e fica em ecrã intero, o trabalho está feito. Não está. Um quiosque de local é um eletrodoméstico remoto, e os eletrodomésticos precisam de regras de manutenção.

Uma infografia de lista de verificação detalhando quatro passos de segurança e manutenção para configurar um sistema Linux em modo quiosque.

O que bloquear

Remova as entradas extra do ambiente de trabalho se a máquina não precisar delas. Desative os atalhos de terminar sessão e mudar de utilizador na sessão ativa. Se permanecer no Ubuntu Desktop, mantenha as atualizações de pacotes controladas para que o quiosque não divague a meio do serviço. Se estiver a gerir muitas unidades, envie as alterações a partir de um processo central, como o Ansible ou um repositório assinado, em vez de editar manualmente cada caixa de cada local.

Um reinício noturno ainda é uma solução prática para sessões de navegador de longa duração. Não é elegante, mas muitas vezes previne a estranheza lenta que se acumula em ecrãs não supervisionados.

Ritmo de manutenção que realmente funciona

Os quiosques não costumam falhar porque o Linux é frágil. Falham porque ninguém é dono da janela de atualização, do caminho de recuperação ou da lista de verificação.

Se a máquina é importante para o serviço, trate-a como um pequeno sistema de produção. Isso é menos glamoroso do que ajustar flags de lançamento, mas é o que mantém o ecrã vivo quando o local está cheio.

O TopFoodApp dá aos restaurantes uma forma rápida de publicar menus baseados em QR que funcionam bem em ecrãs de quiosque Ubuntu, especialmente quando se quer um URL público estável e edições instantâneas do menu sem tocar no quiosque. Se estiver a construir um ecrã de menu, ecrã de balcão ou uma configuração de autosserviço, vale a pena testar o seu quiosque de navegador com um fluxo de trabalho de restaurante real no TopFoodApp.

Publicado em:
← Voltar ao blog