¿Cómo uso inotify o canalizaciones con nombre sobre SSHFS?

Gracias sshfsmagia, puedo montar mi directorio de inicio desde un servidor remoto con

sshfs user@server:/home/user ~/remote

Con optimismo, pensé que había puesto un local de inotify-hook en ~/remote/logFile(en el sshfsmontaje) por lo que un programa local puede reaccionar a los cambios de registro remotos.

cd ~/remote
touch logFile                                # create remote file
inotifywait logFile &                        # set up local inotify-hook
ssh user@server -x touch /home/user/logFile  # touch file from remote

No pasa nada . inotifywaites silencioso a menos que touchel archivo localmente. Escribir en una tubería con nombre falla de manera similar.

¿Por qué es esto?
¿Cómo puedo cerrar esta brecha?

Yo podría funcionar inotifywaiten el control remoto, piratear una estrategia serialización cambio de sistema de archivos y mantener una conexión con el local, pero entonces yo estoy básicamente reimplementar SSHFS . Y mata por completo la abstracción.

sshfs inotify fifo

— Anko
fuente

No creo que haya ninguna forma en que inotifyel sistema local pueda detectar cambios en un sistema de archivos remoto. El núcleo local está fuera del ciclo en esos cambios. Debe ejecutar inotifywaiten el servidor, no en el cliente.

— Barmar

@Barmar Pero entonces el cliente (máquina local) no sabrá acerca de los cambios. Edité para agregar un poco sobre eso.

— Anko

En general, los sistemas de archivos de red no pueden proporcionar una transparencia completa, a menudo rompen la abstracción. Lo que se necesita es una mejora de SSHFS: cuando ejecuta inotify localmente, debe enviar la solicitud al servidor, que ejecuta inotify allí, y devuelve las notificaciones al cliente.

— Barmar

¿Viste Gamin?

— Janus Troelsen

@JanusTroelsen No he oído hablar de Gamin. Según su página de resumen , también usa inotify. ¿Es útil para distribuir tales actualizaciones a través de una red?

— Anko

El sistema de archivos SSHFS está construido sobre el protocolo SFTP . SFTP proporciona solo facilidades para manipular archivos de manera "clásica"; el cliente realiza una solicitud al servidor (enumera un directorio, sube un archivo, etc.) y el servidor responde. No hay ninguna facilidad en este protocolo para que el servidor notifique espontáneamente al cliente que algo ha sucedido.

Esto hace que sea imposible proporcionar una instalación como inotify dentro de SSHFS. Sería posible extender SSHFS con extensiones propietarias, o complementarlo con una conexión SSH completa; pero no conozco ninguna extensión de este tipo para SSHFS.

Las canalizaciones con nombre no se pueden implementar sobre SSHFS por la misma razón. NFS, el sistema de archivos clásico en red, tampoco tiene ninguna facilidad para admitir máquinas cruzadas con nombre de canalizaciones. En un sistema de archivos en red, una tubería con nombre crea un punto de comunicación independiente en cada una de las máquinas donde está montado (además del servidor).

FAM (el análogo de inotify en SGI IRIX, que se ha portado a Linux) proporciona un demonio que permite enviar notificaciones a través de la red. Linux ha desaprobado FAM desde que Inotify entró en escena, así que no sé si hacer que FAM se ejecute sería más fácil que lanzar su propio sistema de notificación específico de la aplicación. Debería configurar algún reenvío de puertos a través de SSH o establecer una VPN para asegurar el enlace de red para FAM y NFS.

Si elige rodar el suyo, suponiendo que está de acuerdo con dar acceso a la shell de los clientes, es bastante fácil ejecutar un monitor inotify en nombre de un cliente: haga que el cliente abra una conexión SSH y ejecute el inotifywaitcomando en el servidor , analizando su salida en el cliente. Puede configurar una conexión maestra para que sea más rápido abrir muchas conexiones del mismo cliente al mismo servidor.

— Gilles 'SO- deja de ser malvado'
fuente

al menos qemu admite una especie de tubería cruzada entre máquinas: una tubería para el invitado virtual

— Janus Troelsen