Installation von saned mit systemd (kein inetd oder xinetd) - saned verweigert die Verbindung

Installation von saned mit systemd (kein inetd oder xinetd) - saned verweigert die Verbindung

Ich habe einen Raspberry Pi B v1 mit einem minimalen Jessie-Image eingerichtet und ihn für das Drucken über CUPS und das Scannen über Saned konfiguriert.

Die lokale Einrichtung funktioniert problemlos;

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

Der Scanner ist jedoch im Netzwerk nicht sichtbar. a scanimage -Lauf einem anderen Computer zeigt 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

So scanimage -Lfunktioniert es - es findet die beiden anderen vernetzten Scanner, abernichtder an den Raspi angeschlossene Scanner.

Wenn ich netstat -tulpnauf dem Pi ausstelle und den Status von saned.serviceund überprüfe saned.socket, erhalte ich

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)

Der offene Port wird nur für TCP6 angezeigt, aber meines Wissens nach pi@EMK-RPiBv1:~$ sudo sysctl net.ipv6.bindv6onlysollte net.ipv6.bindv6only = 0das kein Problem sein, da IPv6 nicht nur an v6 gebunden ist, sondern auch IPv4 umfasst.

Aber wenn ich versuche, per Telnet auf den offenen Port des Pi zuzugreifen, wird die Verbindungabgelehnt:

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

Dies zeigt an, dass ich meinen Saned nicht erreichen kann.

Wenn ich den systemd-Dienst und den Socket für saned beende und versuche, das Debugging durchzuführen, erhalte ich Folgendes:

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

Es wird also im Moment nichts abgehört – keine Ausgabe.

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

Was muss ich tun, um die Verbindung zu öffnen? Bitte ohne inetd oder xinetd zu installieren. Mit systemd allein sollte das klappen.

Antwort1

Die ordnungsgemäße systemd-Zusammenarbeit ist in SANE 1.0.25 vorhanden, SANE 1.0.24 hat noch Probleme. Mehr dazuSANE-BugtrackerUm saned mit systemd zum Laufen zu bringen, sollte man entweder die Version sane-utils 1.0.25 verwenden (nicht in Raspbian Jessie) oder Anpassungen an der Version 1.0.24 vornehmen.

Kurz gesagt: libsystemd-devmuss installiert werden, damit systemd glue funktioniert, und anschließend saned.serviceso bearbeitet werden, dass es dem Manpage-Vorschlag für 1.0.25 entspricht:1.0.25 man-Seite.

Manpage für 1.0.25

Systemd-Konfiguration, wenn saned ohne Systemd-Unterstützung kompiliert wird

Diese Konfiguration funktioniert auch, wenn Saned MIT Unterstützung für die Systemd-Integration kompiliert wird, ermöglicht jedoch nicht die Protokollierung von Debuginformationen.

saned.socket(unverändert)

[Unit]
Description=saned incoming socket

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

[Install]
WantedBy=sockets.target

[email protected](geändert, funktioniert auch, wenn systemddie Unterstützung einkompiliert ist, erlaubt aber keine Protokollierung von Debuginformationen)

[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

Alias=saned.serviceSie können auch in der letzten Installationsstrophe Folgendes eingeben, Also=saned.socketdamit beide sanierten Referenzen mit demselben sanierten Verweis beginnen.*

Außerdem /etc/default/sanedmuss enthalten RUN=nooder der Dienst schlägt fehl, und als Erinnerung, die saned Server-Adresse oderVollqualifizierter Domänenname(nicht nur der Servername) muss auf allen Client-Rechnern eingegeben werden /etc/sane.d/net.conf.

Antwort2

Aber wenn ich versuche, per Telnet auf den offenen Port des Pi zuzugreifen, wird die Verbindung abgelehnt:

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

Aber, ähm,es wird nicht abgelehnt. Wenn dies der Fall wäre, würde „Verbindung abgelehnt“ angezeigt. Aber hier steht eindeutig „Verbunden“ – die Verbindung wurdeakzeptiert, und dann durch den eigentlichen Dienst geschlossen.

Wie dem auch sei: Ich kann zwei Probleme vermuten:

  1. Bei einer inetd-ähnlichen Socket-Aktivierung wie dieser läuft der Saned-Dienst nichtbis ein Verbindungsversuch erfolgt. Daher kann es auch nicht in den Scan-Ergebnissen erscheinen (da es während des Scans nicht ausgeführt wird). Stattdessen müssen Sie es möglicherweise als permanenten Dienst ausführen, nicht als Socket-aktivierten.

  2. Ihr saned.serviceDienst ist kein echter systemd-Dienst; er wurde automatisch aus /etc/init.d/saned konvertiert (wie das Präfix "LSB:" zeigt). Da die init.d-Konvertierungvieleseltsame Randfälle, manchmal führt es dazu, dass Dienste kaum funktionieren –besondersin Kombination mit Socket-Aktivierung. Sie sollten daher vermeiden, die nativen Systemd-Einheiten von Saned und die LSB-konvertierten Einheiten gleichzeitig zu starten.

verwandte Informationen