Como uso pipes inotificados ou nomeados no SSHFS?

Graças à sshfsmagia, posso montar meu diretório pessoal a partir de um servidor remoto com

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

Otimista, eu pensei que eu ia definir um local de inotify-Gancho em ~/remote/logFile(na sshfsmontagem) para um programa local pode reagir a mudanças de log 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

Nada acontece . inotifywaitfica em silêncio, a menos que eu toucho arquivo localmente. A gravação em um pipe nomeado falha da mesma forma.

Por que é isso?
Como posso preencher essa lacuna?

Eu poderia rodar inotifywaitno controle remoto, hackear uma estratégia de serialização de alterações no sistema de arquivos e manter uma conexão com o local, mas basicamente estou reimplementando o SSHFS . E isso mata completamente a abstração.

sshfs inotify fifo

— Anko
fonte

Eu não acho que exista alguma maneira inotifyde o sistema local detectar alterações em um sistema de arquivos remoto. O kernel local está fora do circuito nessas mudanças. Você precisa executar inotifywaitno servidor, não no cliente.

— Barmar

@ Barmar Mas o cliente (máquina local) não saberá sobre as alterações. Eu editei para adicionar um pouco sobre isso.

— Anko

Em geral, os sistemas de arquivos de rede não são capazes de fornecer total transparência, geralmente interrompem a abstração. O que é necessário é um aprimoramento do SSHFS - quando você executa o inotify localmente, ele precisa enviar a solicitação ao servidor, que executa o inotify por lá e passa as notificações de volta ao cliente.

— Barmar

você viu o gamin?

— Janus Troelsen

@JanusTroelsen Eu não ouvi falar de gamin. De acordo com sua página de visão geral , ele também usa inotify. É útil para distribuir essas atualizações pela rede?

— Anko

O sistema de arquivos SSHFS é construído sobre o protocolo SFTP . O SFTP fornece apenas recursos para manipular arquivos de maneira "clássica"; o cliente faz uma solicitação ao servidor (lista um diretório, upload de um arquivo etc.) e o servidor responde. Não há nenhum recurso neste protocolo para o servidor notificar espontaneamente o cliente que algo aconteceu.

Isso torna impossível fornecer um recurso, como inotificar dentro do SSHFS. Seria possível estender o SSHFS com extensões proprietárias ou complementá-lo com uma conexão SSH completa; mas não conheço essa extensão do SSHFS.

Os pipes nomeados não podem ser implementados no SSHFS pelo mesmo motivo. O NFS, o sistema de arquivos em rede clássico, também não possui nenhum recurso para suportar máquinas cruzadas denominadas pipes. Em um sistema de arquivos em rede, um pipe nomeado cria um ponto de comunicação independente em cada uma das máquinas em que está montado (além do servidor).

O FAM (o analógico inotify no SGI IRIX, que foi portado para Linux) fornece um daemon que permite o envio de notificações pela rede. O Linux depreciou a FAM desde que o inotify entrou em cena, então não sei se conseguir executar a FAM seria mais fácil do que lançar seu próprio sistema de notificação específico do aplicativo. Você precisaria configurar algum encaminhamento de porta pelo SSH ou estabelecer uma VPN para proteger o link de rede para FAM e NFS.

Se você optar por fazer o seu próprio, assumindo que está bem em fornecer acesso ao shell dos clientes, é bastante fácil executar um monitor inotify em nome de um cliente: faça com que o cliente abra uma conexão SSH e execute o inotifywaitcomando no servidor , analisando sua saída no cliente. Você pode configurar uma conexão principal para acelerar a abertura de várias conexões do mesmo cliente para o mesmo servidor.

— Gilles 'SO- parar de ser mau'
fonte

pelo menos qemu suporta um tipo de tubo de cross-máquina: um tubo para o convidado virtual

— Janus Troelsen