Samba en CUPS problemen na upgraden Debian 6.0 naar 8.0 :-(

[Josefien]

Mijn vraag
...
Ja, die meid met een gruwelijke hekel aan het upgraden van besturingssystemen omdat er naderhand altijd weer dingen breken, meldt zich weer

Van de een op de andere dag ben ik plots deels overstag gegaan en besloot het Linux-gedeelte van mijn netwerk te upgraden De server die nog draaide op Debian Linux 6.0 is met "apt-get dist-upgrade" via 7.0 geüpgraded naar de nieuwste 8.0 De upgrade was grotendeels gelukt... dingen als DHCP, DNS, LDAP, NFS en TFTP werken nog prima

Twee belangrijke diensten (Samba en CUPS) hebben echter problemen

- Samba:
Deze is van versie 3.5.6 naar 4.2.14 gegaan. De bestaande configuratie is behouden, niks aan gedaan. Werkt ook nog prima als NT4-stijl PDC.

Probleem is echter dat na deze upgrade alle .exe en .bat bestanden die op een share opgeslagen zijn niet meer uitvoerbaar zijn op de Windows-cliënts als de executable-bit op het onderliggende Linux-bestandssysteem niet is ingeschakeld Standaard worden bestanden via Samba namelijk met 0600 rechten weggeschreven.

Als er op een Windows-cliënt een .exe of .bat wordt gestart waarbij de executable-bit niet aan staan, ontstaat deze foutmelding:


Het moet natuurlijk niet zo zijn dat ik voortaan bij alle .exe en .bat bestanden handmatig die bit moet gaan aanzetten voordat ze uitgevoerd kunnen worden

Is er een mogelijkheid om dit gedrag terug te veranderen naar hoe het was bij de oude Samba-versie? Toen .exe en .bat gewoon uitgevoerd konden worden met 0600 rechten


Er is verder ook nog een 2e issue met Samba, maar dat is niet per definitie een probleem, meer een aanpassing. Met de variabel %a in de smb.conf kon je namelijk de profielen en netlogons scheiden per OS. Windows 7 werd als Vista geïdentificeerd, maar na de upgrade valt 'ie plots onder UNKNOWN


- CUPS:
Deze heeft na de upgrade versie 1.7.5 gekregen. Het oude versienummer heb ik helaas niet genoteerd. Ook hier is er niks aan de configuratie gewijzigd.

CUPS maakt verbinding via JetDirect met 3 printers en deelt deze via IPP. Onder Windows-cliënts werden de printers handmatig toegevoegd, onder Ubuntu-cliënts werden ze automatisch gevonden door simpelweg het vinkje "Show printers shared by other systems" aan te zetten.

En bij dat laatste schuilt nu een probleem: na het upgraden v/d server zien de Ubuntu-cliënts geen printers meer uit zichzelf De oude Ubuntu 12.04 cliënts zien geen enkele printer meer, de nieuwe Ubuntu 16.04 (test)cliënt ziet maar 2 v/d 3 printers Handmatig toevoegen a.d.h.v. de URL werkt wel, maar is ongewenst en veroorzaakt andere vage problemen op de cliënts.

Wat kan er hier mis zijn waardoor de Ubuntu-cliënts na het upgraden v/d server niet meer automatisch printers kunnen vinden?


Relevante software en hardware die ik gebruik
...
- Debian Linux 8.0 (server).
- Ubuntu Linux 12.04 / 16.04 (cliënts, ben bezig met testen van de nieuwe versie).
- Windows XP en Windows 7 (cliënts, van beide de Professional-variant).

Hardware lijkt me in dit geval niet interessant. Het is i.i.g. hardware wat voldoet aan de systeemeisen v/d OS'en.


Wat ik al gevonden of geprobeerd heb
...
Op dit moment niks... weet überhaupt niet waar de problemen precies zitten op de nieuwere versies na

De problemen zitten sowieso niet in de cliënts. Daar is namelijk niks aan veranderd.

[Candymirror]

Voor wat betreft samba. Voor zover ik weet is dit gedrag juist een fix voor een bug. De oplossing is dus de permissies goed te zetten of het oude gedrag terug te zetten met: "acl allow execute always"

[Josefien]

Ah, even geprobeerd "acl allow execute always = yes" toe te voegen aan de smb.conf... en inderdaad... de uitvoerbare bestanden werken weer terwijl ze opgeslagen zijn met 0600

Maar is dit een "bugfix"? Het veroorzaakt juist extra problemen omdat uitvoerbare bestanden het niet meer doen Al minstens een jaar of 10 was het standaard gedrag dat een .exe of .bat uitvoerbaar was ongeacht opgeslagen met 0600 of 0700...


Goed... de Samba-kwestie is opgelost Nu het probleem met CUPS nog

[Candymirror]

@samba probleem. Ja, men heeft het negeren van het ontbrekende executable bit "gefixed" vanaf versie 3.6. Omdat dit nogal wat impact had is, is vanaf versie 4.nog iets acl allow execute always toegevoegd.
Voor wat betrefd IPP, ik gebruik het zelf niet cups. Je kunt er dacht ik niet zoveel instellen, behalve dan welke ip adressen de printers hebben. Het browsen/scannen moet gebeuren door de client. Mischien is het een soort cache probleem op de clients? Aangezien ik dacht dat je vanuit cups zelf geen soort van advertising kan doen kan het ook nog in Avahi zitten...

[Josefien]

Ik ben net ook uit met het CUPS-probleem Tenminste, ik heb het nu weer helemaal werkend onder de Ubuntu 15.04 clients Eerst zagen ze maar 2 van de 3 printers. Nu worden ze alle 3 weer gezien

*Josefien blij*

In de error-log van de CUPS-server kwam ik heel veel regels met deze fout tegen:

code:

W [19/Jan/2017:00:35:52 +0100] DNS-SD registration of "Monochroom, Duplexer @ sv1" failed: Local name collision

Wat blijkt? Zowel "Laserjet_2430dtn" als "Laserjet_4050n" hadden dezelfde description "Monochoom, Duplexer". En daar struikelt deze nieuwe versie over

Na het veranderen van de description van één v/d printers is het probleem opgelost

Wel erg raar dat dit probleem zich met de vorige versie niet voordeed En sowieso vind ik het raar dat de description niet hetzelfde mag zijn... daar wordt over het algemeen een korte omschrijving gegeven wat de printer kan... dat kan best hetzelfde zijn bij één of meerdere apparaten In dit geval heb ik maar "A5 afdrukken" bij de 2430dtn erbij gezet...

Waarom de oudere Ubuntu 12.04 cliënts geen printers meer zien, weet ik niet. Maar daar ga ik geen energie meer in steken, ze worden al geüpgraded naar 15.04

[Brahiewahiewa]

Josefien schreef op donderdag 19 januari 2017 @ 00:50:
...kwam ik heel veel regels met deze fout tegen:

code:

W [19/Jan/2017:00:35:52 +0100] DNS-SD registration of "Monochroom, Duplexer @ sv1" failed: Local name collision

Wat blijkt? Zowel "Laserjet_2430dtn" als "Laserjet_4050n" hadden dezelfde description "Monochoom, Duplexer". En daar struikelt deze nieuwe versie over

Na het veranderen van de description van één v/d printers is het probleem opgelost

Wel erg raar dat dit probleem zich met de vorige versie niet voordeed En sowieso vind ik het raar dat de description niet hetzelfde mag zijn...

Wat nieuw is dat die description in DNS geregistreerd wordt. En op de manier waarop het in samba geïmplementeerd wordt, kun je kennelijk niet twee records met dezelfde naam registreren.
Of ze hadden geen zin om de daarvoor benodigde code te schrijven

[Hero of Time]

Josefien schreef op donderdag 19 januari 2017 @ 00:50:
Ik ben net ook uit met het CUPS-probleem Tenminste, ik heb het nu weer helemaal werkend onder de Ubuntu 15.04 clients Eerst zagen ze maar 2 van de 3 printers. Nu worden ze alle 3 weer gezien
...
Waarom de oudere Ubuntu 12.04 cliënts geen printers meer zien, weet ik niet. Maar daar ga ik geen energie meer in steken, ze worden al geüpgraded naar 15.04

Ik mag hopen voor je dat je 16.04 bedoelt, want 15.04 wordt nog maar een paar maanden ondersteund.

[Josefien]

Brahiewahiewa schreef op donderdag 19 januari 2017 @ 03:55:
[...]

Wat nieuw is dat die description in DNS geregistreerd wordt. En op de manier waarop het in samba geïmplementeerd wordt, kun je kennelijk niet twee records met dezelfde naam registreren.
Of ze hadden geen zin om de daarvoor benodigde code te schrijven

Samba wordt toch niet gebruikt bij het delen tussen Linux-Linux?

Hero of Time schreef op donderdag 19 januari 2017 @ 07:57:
[...]

Ik mag hopen voor je dat je 16.04 bedoelt, want 15.04 wordt nog maar een paar maanden ondersteund.

Het is inderdaad 16.04 Foutje... was waarschijnlijk al een beetje moe

[Hero of Time]

Josefien schreef op donderdag 19 januari 2017 @ 20:13:
[...]
Samba wordt toch niet gebruikt bij het delen tussen Linux-Linux?

Kan wel. Maar normaal gesproken deel je een printer in CUPS en kan een andere CUPS instance die vinden, als je de 'server' van 'buiten' bereikbaar maakt. Dat is standaard niet het geval namelijk.

[Josefien]

In mijn geval heb ik CUPS op de server bereikbaar gemaakt over het netwerk en delen van printers aangezet. Op de cliënts hoeft in het geval van Ubuntu 16.04 niks gedaan te worden, ze tonen de printers vanzelf