SAMBA Druck Problem in SuSE Leap VERSION = 15.2, mit "PRINT COMMAND ="

openSUSE VERSION = 15.2 SAMBA Version 4.11.14-git.247.8c858f7ee14lp152.3.19.1-SUSE-oS15.0-x86_64 Hallo, ich habe diese Wochen eine neue Server frisch aufgesetzt. Diese ersetzt meine vorherige SAMBA Server. Auf diesem neuen Server kann ich nicht mehr meine gewohnte Druck-Dienste ausführen: z.B. eine einfache PDF-Drucker [pdf] printing = sysv comment = PDF Generator path = /tmp read only = no printer name = ps1 guest ok = yes printable = yes browseable = yes print command = /usr/local/lufa/mkpdf %s ~%u //%L/%u %m %I Also das Drucken via "print command =" an einen Script ist mir wichtig und ist hier nur als Beispiel PDF-Drucker für den Share angegeben. Die sonstige [HOMES] Fileserver Share funktionierten alle gut, ohne Probleme. Nur diese "print command" Scripting, an DIESEN neue Server versagt. Diese Script wird überhaupt nicht vom Samba Ausgeführt. Log-Datei bleibt leer. Keine Fehlermeldung! Hat jemand eine Idee warum und auch wie ich diese Dienst Debuggen könnte. Auch: wie kann ich genau wissen ob überhaupt meine Windows Client den Job an Samba aufgegeben hat. Den "log level = 10" erzeugt mir keine brauchbare Info über Fehler für diese [PDF] Share. Mir ist bewusst daß "printing = cups" (mit cups Library) den "print command" aussetzt, aber heist es das KEINE "print command" mehr geht? Meine Drucker-Shares haben bisher mit " printing = sysv" immer funktioniert. kann mir hierbei jemand weiterhelfen, mit freundlichen Grüßen Stefan Becker LUFA Speyer Meine Script: ------------ Rechte: /usr/local/lufa/mkpdf : die Rechte Stimmen: /usr/local/lufa # dir mkpdf -rwxr-xr-x 1 becker users 4299 14. Jun 12:25 mkpdf Script: #!/bin/bash #/usr/local/lufa/mkpdf # samba-print-pdf cd /tmp/ ( echo "" echo Time: $(date +"%Y-%m-%d %H:%M:%S") echo Proc: $USER [ $UID ] echo Call: $0 echo File: $1 echo User: $2 echo Para: $3 , $4 , echo Para: $5 , $6 ) >> /tmp/mkpdf.log if [ "$1" = "" ] ; then exit 10 fi # .... hier die vollständige smb.conf : ------------------------------ [global] workgroup = HOME netbios name = SUE log level = 3 realm = HOME.DE passdb backend = tdbsam security = ADS ntlm auth = ntlmv1-permitted min protocol = NT1 interfaces = 127.0.0.0/255.0.0.0 192.168.10.0/255.255.252.0 hosts allow = 127.0.0.0/255.0.0.0 192.168.10.0/255.255.252.0 hosts deny = all bind interfaces only = yes printing = cups printcap name = cups printcap cache time = 750 cups options = raw guest account = nobody guest ok = no logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = L: domain logons = No domain master = No prefered master = No wins server = 192.168.3.13 wins support = No allow insecure wide links = yes follow symlinks = yes wide links = yes allow trusted domains = No template homedir = /home/%U template shell = /bin/bash oplocks = No level2 oplocks = No client min protocol = NT1 nt acl support = no inherit acls = no kerberos method = secrets and keytab winbind use default domain = yes winbind enum users = yes winbind enum groups = yes winbind nested groups = No winbind refresh tickets = yes winbind offline logon = yes idmap config HOME : backend = rid idmap config HOME : range = 1000 - 20000 idmap cache time = 20000 unix charset = utf8 dos charset = cp1252 [homes] comment = home valid users = %S, %D%w%S read only = no create mask = 0600 directory mask = 0700 browseable = no printable = no [pdf] printing = sysv comment = PDF Generator path = /tmp read only = no printer name = ps1 guest ok = yes printable = yes browseable = yes print command = /usr/local/lufa/mkpdf %s ~%u //%L/%u %m %I

Hallo Stefan, hallo zusammen, Am Dienstag, 15. Juni 2021, 14:05:50 CEST schrieb Stefan Becker:
Schuss ins Blaue: Kann es sein, dass Du am AppArmor-Profil anstehst? (Shares werden automatisch erlaubt, print command braucht wohl eine manuelle Anpassung.) Guck mal in /var/log/audit/audit.log, ob Du da DENIED-Meldungen für mkpdf findest. Falls ja: Um die Ausführung des print command zu erlauben, musst Du Dein Samba- Profil anpassen. Das geht wahlweise mit aa-logprof oder durch manuelles Ändern des Profils. Sicherste Lösung ist, für mkpdf ein eigenes Profil anzulegen. In diesem Fall würde ich aa-logprof empfehlen, weil das die nötigen Fragen stellt, und für mkpdf die Option "Profil" wählen. Vermutlich brauchst Du mehrere aa-logprof-Durchgänge, bis das mkpdf- Profil komplett ist. Es kann auch helfen, das mkpdf-Profil erstmal in den complain-Mode (mit aa-complain) zu schalten - damit wird erstmal alles erlaubt und geloggt. Anschließend wieder aa-logprof, und aa-enforce zum Scharfschalten nicht vergessen ;-) Weniger sicher, aber dafür auch einfacher ist es, das Ausführen von mkpdf ohne AppArmor-Schutz zu erlauben. Dafür kannst Du folgende Zeile in /etc/apparmor.d/local/usr.sbin.smbd ein: /usr/local/lufa/mkpdf mrUx, und rufst anschließend rcapparmor reload auf.
Stefan Becker LUFA Speyer
Ah, dann gibt es die Bodenproben-Ergebnisse also weiterhin als PDF? ;-) Gruß Christian Boltz -- Pro-tip: never talk to infrastructure people. You don’t want to know how the sausage is made or how close we always are to being the sausage. It’s bad. [https://nitter.net/tressiemcphd/status/1328475420510064640]

Hallo Stefan, hallo zusammen, Am Dienstag, 15. Juni 2021, 14:05:50 CEST schrieb Stefan Becker:
Schuss ins Blaue: Kann es sein, dass Du am AppArmor-Profil anstehst? (Shares werden automatisch erlaubt, print command braucht wohl eine manuelle Anpassung.) Guck mal in /var/log/audit/audit.log, ob Du da DENIED-Meldungen für mkpdf findest. Falls ja: Um die Ausführung des print command zu erlauben, musst Du Dein Samba- Profil anpassen. Das geht wahlweise mit aa-logprof oder durch manuelles Ändern des Profils. Sicherste Lösung ist, für mkpdf ein eigenes Profil anzulegen. In diesem Fall würde ich aa-logprof empfehlen, weil das die nötigen Fragen stellt, und für mkpdf die Option "Profil" wählen. Vermutlich brauchst Du mehrere aa-logprof-Durchgänge, bis das mkpdf- Profil komplett ist. Es kann auch helfen, das mkpdf-Profil erstmal in den complain-Mode (mit aa-complain) zu schalten - damit wird erstmal alles erlaubt und geloggt. Anschließend wieder aa-logprof, und aa-enforce zum Scharfschalten nicht vergessen ;-) Weniger sicher, aber dafür auch einfacher ist es, das Ausführen von mkpdf ohne AppArmor-Schutz zu erlauben. Dafür kannst Du folgende Zeile in /etc/apparmor.d/local/usr.sbin.smbd ein: /usr/local/lufa/mkpdf mrUx, und rufst anschließend rcapparmor reload auf.
Stefan Becker LUFA Speyer
Ah, dann gibt es die Bodenproben-Ergebnisse also weiterhin als PDF? ;-) Gruß Christian Boltz -- Pro-tip: never talk to infrastructure people. You don’t want to know how the sausage is made or how close we always are to being the sausage. It’s bad. [https://nitter.net/tressiemcphd/status/1328475420510064640]
participants (2)
-
Christian Boltz
-
Stefan Becker