Instalação de saned com systemd (sem inetd ou xinetd) - saned recusa conexão

2

Eu configurei um Raspberry Pi B v1 com uma imagem mínima do Jessie e configurei-o para impressão via xícaras e digitalização via saned.

A configuração local é sem problemas; um

pi@EMK-RPiBv1:~$ scanimage -L device 'fujitsu:ScanSnap S1500:25959' is a FUJITSU ScanSnap S1500 scanner

No entanto, o scanner não está visível na rede. um scanimage -L em outra máquina mostra emk2203@XPS12-9Q33:~$ scanimage -L device 'hpaio:/net/HP_LaserJet_CM1415fn?ip=192.168.1.30' is a Hewlett-Packard HP_LaserJet_CM1415fn all-in-one device 'hpaio:/net/HP_Officejet_Pro_276dw_MFP?ip=192.168.1.40' is a Hewlett-Packard HP_Officejet_Pro_276dw_MFP all-in-one

Portanto, o scanimage -L funciona - ele encontra os outros dois scanners em rede, mas não o scanner anexado ao Raspi.

Se eu emitir netstat -tulpn no pi e verificar o status de saned.service e saned.socket , obtenho

pi@EMK-RPiBv1:~$ netstat -tulpn
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::6566                 :::*                    LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN                    
tcp6       0      0 :::631                  :::*                    LISTEN      
udp        0      0 0.0.0.0:42976           0.0.0.0:*                           
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           
udp        0      0 0.0.0.0:29987           0.0.0.0:*                           
udp        0      0 0.0.0.0:68              0.0.0.0:*                           
udp        0      0 192.168.1.34:123        0.0.0.0:*    -                       
udp        0      0 127.0.0.1:123           0.0.0.0:*-                           
udp        0      0 0.0.0.0:123             0.0.0.0:*-                           
udp6       0      0 :::35810                :::*     -                           
udp6       0      0 :::5353                 :::*     -                           
udp6       0      0 :::49009                :::*     -                         
udp6       0      0 fe80::ba27:ebff:fe4:123 :::*     -                          
udp6       0      0 2a02:8070:a182:ce00:123 :::*     -                           
udp6       0      0 ::1:123                 :::*     -                           
udp6       0      0 :::123                  :::*     -                        

pi@EMK-RPiBv1:~$ systemctl status saned.socket
● saned.socket - saned incoming socket
    Loaded: loaded (/lib/systemd/system/saned.socket; enabled)
    Active: active (listening) since Sun 2015-10-11 20:01:52 CEST; 2min 18s ago
    Listen: [::]:6566 (Stream)
Accepted: 0; Connected: 0

pi@EMK-RPiBv1:~$ systemctl status saned.service
● saned.service - LSB: SANE network scanner server
   Loaded: loaded (/etc/init.d/saned)
   Active: active (exited) since Sun 2015-10-11 20:01:53 CEST; 2min 26s ago
  Process: 342 ExecStart=/etc/init.d/saned start (code=exited, status=0/SUCCESS)

A porta aberta é mostrada somente para tcp6, mas de acordo com pi@EMK-RPiBv1:~$ sudo sysctl net.ipv6.bindv6only eu recebo net.ipv6.bindv6only = 0 - isso não deve ser um problema, já que o ipv6 não está ligado apenas a v6, mas também inclui ipv4.

Mas quando tento fazer telnet na porta aberta do pi, a conexão é recusada :

pi@EMK-RPiBv1:~$ telnet localhost 6566
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

Isso indica que não posso alcançar meu saned.

Se eu matar o serviço systemd e o soquete para saned e tentar depurar, recebo o seguinte:

root@EMK-RPiBv1:~# systemctl stop saned.service
root@EMK-RPiBv1:~# systemctl stop saned.socket
root@EMK-RPiBv1:~# lsof -i :6566

Então, nada de ouvir no momento - sem saída.

root@EMK-RPiBv1:~# saned -d128 -a saned
[saned] main: starting debug mode (level 128)
[saned] read_config: searching for config file
[saned] read_config: done reading config
[saned] saned (AF-indep+IPv6) from sane-backends 1.0.24 starting up
[saned] do_bindings: trying to get port for service "sane-port"   (getaddrinfo)
[saned] do_bindings: [1] socket () using IPv6
[saned] do_bindings: [1] setsockopt ()
[saned] do_bindings: [1] bind () to port 6566
[saned] do_bindings: [1] listen ()
[saned] do_bindings: [0] socket () using IPv4
[saned] do_bindings: [0] setsockopt ()
[saned] do_bindings: [0] bind () to port 6566
[saned] do_bindings: [0] bind failed: Address already in use
[saned] run_standalone: spawning Avahi process
[saned] run_standalone: waiting for control connection
[saned] saned_avahi_callback: AVAHI_CLIENT_S_RUNNING
[saned] saned_create_avahi_services: adding service 'saned'
[saned] saned_avahi_group_callback: service 'saned' successfully established

O que preciso fazer para abrir a conexão? Sem instalar o inetd ou o xinetd, por favor. Isso deve funcionar apenas com o systemd.

    
por emk2203 11.10.2015 / 22:44

2 respostas

1

A cooperação adequada do sistema está no SANE 1.0.25, o SANE 1.0.24 tem problemas restantes. Mais sobre o rastreador de bugs do SANE . Para conseguir trabalhar com o systemd, deve-se usar a versão 1.0.25 da sane-utils (não na Jessie Raspbian) ou fazer ajustes na versão 1.0.24.

Em suma, libsystemd-dev precisa ser instalado para que o systemd cola funcione, e o saned.service editado para corresponder à sugestão da página de manual para 1.0.25: página de manual 1.0.25 .

Man Page for 1.0.25

Configuração do Systemd quando o saned é compilado sem suporte ao systemd

Essa configuração também funcionará quando o Saned for compilado com o suporte à integração do systemd, mas não permitirá que as informações de depuração sejam registradas.

saned.socket (inalterado)

[Unit]
Description=saned incoming socket

[Socket]
ListenStream=6566
Accept=yes
MaxConnections=1

[Install]
WantedBy=sockets.target

[email protected] (alterado, funciona também se systemd support estiver compilado, mas não permitir o registro de informações de depuração)

[Unit]
Description=Scanner Service
Requires=saned.socket

[Service]
ExecStart=/usr/sbin/saned
User=saned
Group=saned
StandardInput=socket

Environment=SANE_CONFIG_DIR=/etc/sane.d

[Install]
Also=saned.socket

Você também pode inserir Alias=saned.service na última sub-rotina de instalação após Also=saned.socket para que as duas referências sanadas comecem com o mesmo saned. *

Além disso, /etc/default/saned precisa conter RUN=no ou o serviço falha e, como lembrete, o endereço do servidor protegido ou FQDN (não apenas o nome do servidor) precisa ser colocado em /etc/sane.d/net.conf em todas as máquinas clientes.

    
por 12.10.2015 / 18:59
1

But when I try to telnet into the open port on the pi, the connection is refused:

pi@EMK-RPiBv1:~$ telnet localhost 6566
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

Mas, um, não é recusado . Se fosse, você veria "Conexão recusada". Mas diz claramente "Conectado" aqui - a conexão foi aceita e, em seguida, fechada pelo serviço real.

De qualquer forma: posso adivinhar dois problemas:

  1. Com a ativação de soquete inetd-like como este, o serviço saned não está sendo executado até que uma conexão seja tentada . Portanto, ele não pode aparecer nos resultados da verificação (já que não está sendo executado durante a verificação). Então, em vez disso, você pode precisar executá-lo como um serviço permanente, não um ativado por soquete.

  2. Seu saned.service não é um serviço real do systemd; Ele foi convertido automaticamente de /etc/init.d/saned (como mostra o prefixo "LSB:"). Como a conversão init.d precisa lidar com muitos casos estranhos de borda, às vezes isso resulta em serviços que mal funcionam - especialmente quando combinados com a ativação de soquete. Assim, você deve evitar inicializar as unidades nativas do systemed e as unidades convertidas pelo LSB ao mesmo tempo.

por 11.10.2015 / 23:15