Publicar y utilizar el servicio del fotomatón

LinuxBeginner
Practicar Ahora

Introducción

En Maple Yard, los visitantes quieren una pequeña vista previa de las fotos o el álbum completo del fotomatón. Los servidores de fotos ya funcionan, pero los visitantes no deberían necesitar una tarjeta con una dirección IP y un puerto. Publicarás dos servicios con nombre, los descubrirás desde los clientes y guardarás las colecciones correspondientes sin interrumpir el punto de información.

Debes reconocer direcciones IPv4, nombres de host, puertos, rutas y roles de terminal, y haber seguido comandos completos de descarga HTTP. Se recomienda el proyecto anterior sobre la red del evento. No necesitas administración DNS, experiencia con XML ni programación. Los 60 minutos estimados incluyen lectura y errores habituales; es una estimación del autor, no un tiempo medido con principiantes.

Publisher, Client y New Client son nodos de red Linux aislados en una LAN preparada y comparten un núcleo. Photo Shelf muestra los archivos descargados. Este laboratorio enseña mDNS y DNS-SD en el enlace local, no DNS público, descubrimiento entre routers, autorización automática ni compatibilidad con todos los dispositivos físicos o navegadores. Las imágenes de muestra son tarjetas ilustradas sintéticas originales, no fotografías de asistentes reales.

Descubrir un servicio que funciona

En este paso, utilizarás el punto de información que ya funciona antes de publicar nada. Comienza en Client. Su terminal se inicia en /home/labex/project/photo-network/client; este directorio y su shell son independientes de las otras pestañas. pwd muestra el directorio actual:

pwd

El DNS de multidifusión (mDNS) permite que dispositivos vecinos intercambien información de nombres en el mismo enlace local. Aquí sus paquetes utilizan la dirección IPv4 de multidifusión 224.0.0.251 y el puerto UDP 5353. El sufijo .local pertenece a este mecanismo de descubrimiento local; no lo añadas al archivo hosts de la plataforma ni lo trates como una zona DNS pública.

El descubrimiento de servicios basado en DNS (DNS-SD) describe instancias de servicios con nombre. Un tipo de servicio indica qué busca un cliente: _http._tcp significa HTTP sobre TCP. Un nombre de instancia, como Information Desk, identifica un servicio ofrecido. El nombre de host de destino identifica el nodo que lo sirve. Un puerto selecciona la aplicación que escucha; los metadatos path seleccionan un recurso dentro de ella. Encontrar un nombre es solo el comienzo de utilizar un servicio.

avahi-browse pide al demonio nativo de Avahi que descubra servicios. -r resuelve cada instancia en información de conexión, -t sale cuando termina la exploración, -p imprime campos separados por punto y coma y -k conserva los nombres originales de los tipos de servicio en lugar de sus traducciones descriptivas:

avahi-browse -rtpk _http._tcp

Espera una fila resuelta que comience con = y contenga estos campos:

=;eth0;IPv4;Information\032Desk;_http._tcp;local;desk.local;10.93.0.10;8080;"path=/welcome/index.json"

Avahi también puede imprimir filas + para instancias recién detectadas. En su salida analizable, \032 representa un espacio. Lee la fila resuelta en este orden: instancia, tipo, dominio, nombre de host de destino, dirección, puerto y metadatos TXT. El orden de las filas y los escapes pueden variar. El demonio nativo recibe estos registros por esta LAN; no hay una lista de descubrimiento preparada.

Utiliza el cliente proporcionado photo-get para guardar una colección por su nombre de instancia. Las comillas mantienen un nombre con espacios como un único argumento. El segundo argumento es una carpeta de salida dentro del espacio de trabajo de esta terminal:

photo-get "Information Desk" desk

photo-get realiza otra exploración real de Avahi, resuelve esa instancia exacta, imprime su destino, obtiene el índice JSON anunciado y cada PNG que este enumera, decodifica todas las imágenes y guarda los bytes recibidos. No consulta el plan de estaciones para obtener una IP, un puerto o una ruta. El índice enumera los nombres de archivo de las imágenes; es una convención de aplicación de estos servicios, no un formato universal de DNS-SD. Espera Saved 1 real images en la carpeta desk.

Cambia a Photo Shelf y selecciona Client. Recarga los archivos guardados. Deberías ver la tarjeta Welcome to Maple Yard. El visor solo lee los archivos guardados en el espacio de trabajo de este cliente; nunca obtiene datos del servidor ni repone una imagen ausente. El enlace Download image devuelve ese mismo archivo guardado.

La tarjeta del punto de información guardada en Photo Shelf

La selección Client identifica este espacio de trabajo. La tarjeta del punto de información es la referencia funcional que conservarás al añadir el fotomatón.

Si la exploración está vacía, comprueba el tipo exacto de servicio y que estés en Client, y repítela. Daemon not running significa que el cliente de descubrimiento no puede comunicarse con su demonio preparado; es distinto de un resultado vacío. Si photo-get no puede resolver el nombre, compara su escritura y sus comillas con la fila resuelta. Una conexión rechazada significa que se encontró una dirección, pero nada aceptó ese puerto. HTTP 404 significa que se llegó al servidor, pero la ruta del recurso no existe. Un error de JSON o de decodificación de imágenes indica contenido inadecuado. No sustituyas la solución de estos problemas por una entrada hosts o una imagen copiada manualmente.

Publicar el fotomatón con una plantilla completa

En este paso, anunciarás el servidor de vista previa existente. Cambia a Publisher. Su terminal comienza en /home/labex/project/photo-network/services. cat muestra un archivo de texto; ../ representa su directorio padre:

cat ../stations.tsv

Este plan de negocio describe los servicios de escucha reales ya preparados. Photo Booth Preview pertenece a publisher.local, en el puerto 8081, con el recurso /preview/index.json. El álbum completo tiene otro servicio de escucha y otro recurso. El punto de información pertenece a otro nodo y debe permanecer sin cambios.

Lee la definición incompleta de la vista previa:

cat preview.service

Aquí un archivo .service utiliza XML: las etiquetas de apertura y cierre rodean cada valor. service-group contiene el name mostrado; su service proporciona type, port y txt-record. Publicar una definición no crea un servidor web, una colección ni un permiso de acceso. Esas aplicaciones ya están funcionando.

El siguiente here-document escribe el archivo pequeño completo. > reemplaza su contenido anterior. El delimitador entre comillas 'XML' mantiene el texto literal; el XML final debe estar solo al principio de su línea. Copia todo el bloque:

cat > preview.service <<'XML'
<?xml version="1.0" standalone="no"?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name>Photo Booth Preview</name>
  <service>
    <type>_http._tcp</type>
    <port>8081</port>
    <txt-record>path=/preview/index.json</txt-record>
  </service>
</service-group>
XML

Lee la definición guardada:

cat preview.service

El comando del curso photo-load analiza ambos archivos XML editables antes de pedir únicamente al demonio Avahi de Publisher que los recargue. No reinicia el punto de información ni los servidores de negocio:

photo-load

Espera Reload requested for the photo publisher. Deja unos segundos para la comprobación del nombre y el registro. Un análisis correcto confirma la estructura XML; no demuestra que el puerto o la ruta anunciados sean correctos. Si falta una etiqueta de cierre, photo-load informa del archivo y del error sin solicitar una recarga. Lee el archivo, restaura el bloque completo y vuelve a ejecutar photo-load. No necesitas restablecer el entorno.

Cambia a Client y explora otra vez:

avahi-browse -rtpk _http._tcp

Busca Photo Booth Preview, su destino publisher.local, el puerto 8081 y /preview/index.json. Guarda y decodifica la colección real:

photo-get "Photo Booth Preview" preview

Espera una imagen de vista previa. En Photo Shelf, selecciona Client, recarga y examina la tarjeta de vista previa junto a la tarjeta existente del punto de información. Que un servicio aparezca en la lista sin proporcionar la imagen correcta sigue siendo un resultado incompleto.

Distinguir dos servicios

En este paso, publicarás el álbum completo en el mismo nodo y distinguirás las dos instancias. Cambia a Publisher. Ambas utilizan _http._tcp y publisher.local, pero el álbum usa el puerto 8082 y /album/index.json. Sus tres imágenes son distintas de la vista previa de una sola imagen.

Escribe su definición independiente con la sintaxis here-document ya aprendida:

cat > album.service <<'XML'
<?xml version="1.0" standalone="no"?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name>Photo Booth Full Album</name>
  <service>
    <type>_http._tcp</type>
    <port>8082</port>
    <txt-record>path=/album/index.json</txt-record>
  </service>
</service-group>
XML
photo-load

Cambia a Client. Explora y lee cada fila resuelta por separado:

avahi-browse -rtpk _http._tcp

Los dos nombres de instancia deben ser distintos. Compartir un nombre de host no implica compartir un puerto o un recurso. Descarga el álbum en su propia carpeta y conserva la vista previa:

photo-get "Photo Booth Full Album" album

Espera tres PNG decodificados y Saved 3 real images. En Photo Shelf, selecciona Client y recarga. El álbum y la vista previa deben mostrar sus propios archivos guardados.

Ahora practica cómo reconocer un recurso incorrecto sin editar ni borrar tus colecciones correctas. Un nombre de instancia ausente a propósito debe fallar antes de descargar nada:

photo-get "Photo Booth Missing" missing

Espera Download stopped: Expected one resolved instance y una salida distinta de cero. Es intencional. Recupérate utilizando de nuevo el nombre real del álbum resuelto:

photo-get "Photo Booth Full Album" album

Si anunciaste un puerto o una ruta incorrectos, compara la fila resuelta de esa instancia con stations.tsv. Corrige únicamente el archivo .service correspondiente en Publisher, utilizando su bloque completo mostrado, ejecuta photo-load y vuelve a explorar y descargar desde Client. Un puerto de escucha incorrecto puede rechazar la conexión; una ruta errónea puede devolver HTTP 404; una colección accesible pero diferente puede decodificarse y seguir siendo un resultado de negocio incorrecto. Comprueba el título y los nombres de archivo de la colección, no solo un estado de salida cero.

Avahi anuncia los cambios y las retiradas. Un cliente puede conservar brevemente registros antiguos mientras se propaga una actualización. Espera unos segundos tras cargar y repite la exploración; no sigas utilizando destinos antiguos copiados. El siguiente paso comprueba el resultado desde un demonio de cliente y un espacio de trabajo independientes.

Usar el resultado desde otro cliente

En este paso, utilizarás otra identidad de red y un demonio Avahi independiente. Cambia a New Client. Se inicia en /home/labex/project/photo-network/new-client; por defecto no comparte las variables del shell ni las colecciones guardadas del primer cliente. Abrir una pestaña no restablece el publicador ni crea anuncios.

Explora desde este cliente en lugar de copiar las filas del primero:

avahi-browse -rtpk _http._tcp

Lee las relaciones de las tres instancias resueltas. La vista previa y el álbum completo tienen el mismo destino, pero distintos puertos y rutas. El punto de información tiene su propio destino. Descarga los tres desde este cliente:

photo-get "Photo Booth Preview" preview
photo-get "Photo Booth Full Album" album
photo-get "Information Desk" desk

Espera una vista previa, tres imágenes del álbum y una tarjeta del punto de información. Cada invocación vuelve a resolver la instancia nombrada e imprime el destino real utilizado. Estos comandos no configuran descubrimiento mediante IP estática.

Cambia a Photo Shelf, selecciona New Client y recarga. Inspecciona cada imagen y título de colección. Selecciona Download image en una tarjeta de imagen guardada; la imagen descargada debe coincidir con la tarjeta guardada que se muestra. El visor no copia silenciosamente el trabajo del primer cliente ni repone archivos ausentes. Alterna entre Client y New Client para ver sus colecciones separadas.

El cliente independiente conserva las tres colecciones guardadas

Busca la selección New Client, las tres tarjetas del álbum, la tarjeta del punto de información y la tarjeta de vista previa independiente. Cada enlace Download image corresponde a un archivo realmente guardado.

Si falta una colección, vuelve a New Client y repite su descarga después de comprobar el anuncio actual. Si falta un PNG guardado o no puede leerse, el visor lo comunica en vez de reemplazarlo. Corrige primero la publicación o la conexión y vuelve a ejecutar photo-get para obtener la colección original completa. La descarga solo es correcta cuando se han obtenido y decodificado el índice completo y todas las imágenes.

Ahora has conectado la publicación de servicios con su uso: tres instancias distinguibles, destinos actuales correctos, archivos reales en dos clientes y un punto de información que sigue funcionando. El descubrimiento proporciona información de conexión, no autenticación ni una garantía de que el servicio encontrado sea confiable.

Resumen

Exploraste registros mDNS/DNS-SD nativos, distinguiste nombres de instancia de nombres de host y publicaste dos servicios HTTP con puertos y metadatos de ruta separados. Utilizaste cada resultado de descubrimiento real para descargar imágenes decodificables, repetiste el flujo desde un cliente independiente y mantuviste disponible el punto de información. Una fila de descubrimiento y una conexión correcta son pruebas distintas; el contenido correcto guardado completa el resultado.