|
Samba 3: van Windows NT naar Windows 2000 en XP Eerste praktijkervaringen met Samba 3.0.20b
|
Samba op SuSE Linux 10 van Novell
|
Suse Linux 9.1 kwam met Samba versie 3. De resultaten vielen me enorm tegen. Onder OS/2 kon ik de samba bronnen wel benaderen, maar niet met de WPS bezien.
Klassieke net opdrachten gaven geen probleem.
Het bekijken van de netwerkomgeving:
[F:\]net view Naam server Opmerking --------------------------------- \\MULTIBOOT \\SUSE9 SAMBA SERVER De opdracht is uitgevoerd.
Het onderzoek van de bronnen van de server:
[F:\]net view \\suse9 Gemeenschappelijke resources bij \\suse9 Samba Server naam resource Type Gebruikt als Commentaar --------------------------------------------------- groups Schijf All groups pdf Afdrukken PDF creator sjoerd Schijf Home Directories users Schijf All users De opdracht is uitgevoerd.
Om de share te mounten moet u zowel een UNIX account als een samba wachtwoord op de server hebben. Dat laatste gaat met smbpasswd -a gebruikernaam. Of vanuit OS/2 met de Samba Web Administration Tool (swat) server op poort 901. Zonder geldig samba wachtwoord krijgt u een foutmelding.
[F:\]net use C: \\suse9\sjoerd NET2758: Het systeem kan geen verbinding maken met de server. Voor meer informatie typt u HELP NET2758. [F:\]help net2758 NET2758: Het systeem kan geen verbinding maken met de server. Oorzaak: het gebruikers-ID en het wachtwoord waarmee u bent aangemeld geven u niet de bevoegdheid deze actie te voltooien. Actie: meld u aan met een ID en een wachtwoord die u de vereiste bevoegdheid geven of geef het juiste wachtwoord op voor het ID.
Netstat -s(ockets) laat in zo'n geval wel een TCP/IP verbinding met poort 139 zien. Maar op de toepassingslaag loopt het vast. Na aanmaak van het samba wachtwoord gaat het wel:
[F:\]net use c: \\suse9\sjoerd De opdracht is uitgevoerd. [F:\]c:
Alles leek het te doen. Overigens zag ik soms wel namen met een hartje aan het eind. Een teken dat er nog wel fouten in de LAN ManManager API van de samba server zitten en/of dat de codetabellen niet overeenstemmen .
[C:\]dir
The volume label in drive C is sjoerd.
The Volume Serial Number is 01ED:0993.
Directory of C:\
12-04-05 2:17 <DIR> 0 ---- .
23-08-04 3:45 <DIR> 0 ---- ..
23-08-04 3:45 <DIR> 0 ---- bin
11-04-05 2:49 <DIR> 0 ---- Desktop
12-04-05 2:21 <DIR> 0 ---- Documents
30-08-04 22:58 <DIR> 0 ---- OpenOffice.org1.1
23-08-04 3:45 <DIR> 0 ---- public_html
7 file(s) 0 bytes used
2.734.686 K bytes freeGrafische PM programma's (File Manager/2) en tekstmodus programma's (File Commander/2 en cmd.exe) konden de samba 3 share benaderen, maar de WPS gaf een lege C map te zien met de foutmelding:
"Er zijn geen objecten met de opgegeven zoekcriteria aangetroffen"
Experimenteren met het bestand smb.conf leverde niets op. Zoeken op het internet wel. De OS/2 WPS gaf foutmeldingen die sinds Samba 3.0 op comp.os.os2.networking.misc vermeld waren:
"No objects were found that matched the specified criteria" "The system call level is incorrect"
Samba 3.01 zou dit verbeteren, maar inmiddels bestaat de problematiek al meer dan een jaar. Wel kreeg het de aandacht de samba ontwikkelaars. Zie: https://bugzilla.samba.org/show_bug.cgi?id=872 .
Wat is hier aan de hand?
Samba is een open source implementatie van het Server Message Block (SMB) protocol dat OS/2 en Windows voor bestanden en printerdeling over het netwerk gebruiken.
Er zijn drie versies van:
Het oude Network Basic Input/Output broadcast systeem voor lokale werkgroepen (OS/2's NetBIOS, Windows' NetBEUI = NetBIOS Extended User Interface)
Het routerbare Netbios via TCP/IP (NBT) voor OS/2 LanManager en NT domeinen (OS/2, Windows, samba)
Het direct via de DNS werkende SMB over TCP protocol van Windows 2000/XP/2003 en recente versies van samba.
Samba versie 2.0 (1999) servers bootsten NT servers in Microsoft Windows domeinen na. Ze kregen een met Windows compatibele wachtwoordversleuteling en een Access Control List (ACL) methode van bestandspermissies. Omdat Unix/Linux POSIX bestandssystemen de ACL beveiligingsmethode niet kenden hadden samba servers een dubbele boekhouding. Ze sloegen Windows wachtwoorden en toegangscontrolelijsten in aparte bestanden op. Die oplossing was trager dan ACLs in het bestandssysteem zelf (HPFS386, NTFS en JFS), maar het werkte. Zo kon Samba 2 veel taken van een Windows NT 4 servers (Primaire Domein Controllers, WINS servers) overnemen, waar ook OS/2 gebruikers van konden profiteren.
Maar met Microsoft Windows 2000 introduceerde Microsoft nieuwe WAN technieken. Windows 2000 en XP gebruiken nu bij voorkeur Microsofts SMB over TCP protocol dat over TCP poort 445 loopt. Deze voor Windows 20003 servers bestemde MS Directory Services (MS-DS) werken niet meer met de NetBIOS namen van een WINS server/LMHost bestand, maar met de IP adressen van een dynamische (DHCP!) DNS server. Dit directe SMB over TCP alias MS-DS protocol wordt deels door samba, maar niet OS/2 en Windows 9x/ME ondersteund. Maar als aan de andere kant van Windows 2000/XP werkstation geen open TCP poort 445 gevonden wordt schakelen Windows 2000/2003 en XP over op het NetBios via TCP/IP (NBT) protocol van TCP poort 139. De NetBIOS naamresolutie en veel metacommunicatie verlopen dan via de UDP poorten 137 en 138.
Overigens kunnen Windows 2000 en XP en zelfs Linux (Netbeui for linux) ook het door iedere ethernetwerkkaart ondersteunde NetBIOS protocol gebruiken om met OS/2 en oudere Windows versies binnen een werkgroep (alle ethernetkaarten die op één hub/switch aangesloten zijn) te communiceren. Het NetBIOS protocol zit op de XP CD in Valueadd\MSFT\Net\NetBEUI verstopt. Maar omdat de pure NetBIOS communicatie (zonder spyware) niet op het internet te zien is, blijft een veilige manier van bestands- en printerdeling op een bedraad netwerk. Zolang u maar geen WLAN gebruikt want ook firewalls hebben er geen grip op. Onder OS/2 kunt u via de NetBIOS API zelfs COM poorten (fax, modem) en uitgebreide attributen delen.
Voor mijn samba verhaal is belangrijk dat Windows 2000 en XP werkstations en servers gebruik gingen maken van Microsofts Active Directory Services (ADS, DS) die deels vastgelegd werden in het NTFS versie 5 bestandssysteem. En die extra eigenschappen van NTFS5 kunnen klassieke Unix bestandssystemen en samba niet zomaar emuleren. Bovendien "integreerde" het object georiënteerde Actieve Directory Systeem een hele reeks protocollen: niet alleen het Server Message Block protocol, maar ook Kerberos, LDAP, DHCP als ook MS only protocollen, waardoor het beheer van Windows 2000 en XP werkstations op ADS domeinen vereenvoudigd werd, maar het samba team op achterstand werd gezet.
Als
zo'n op het eerste gezicht aanlokkelijk "MS doet alles voor u
systeem" eenmaal ingesteld is, kun je niet zomaar terug. Dat was
ook de reden dat veel netwerkbeheerders aarzelden om van met samba
uitwisselbare Windows NT domeinen naar het MS Windows ADS systeem
over te gaan. Maar aan de andere kant moesten ze wel omdat de nieuwe
werkstations alleen maar met XP geleverd werden en ze zonder ADS
achter zouden lopen.
Zo'n vergaande integratie past niet bij het open source "Keep It Simple, Stupid" toolbox model. Dat wist Microsoft natuurlijk heel goed. Maar om Microsoft enigszins bij te benen introduceerde Samba 3 "OS/2 type" ondersteuning voor Extended Attributes (EA's).
Leuk voor OS/2 zou u denken, maar het samba team had hierbij niet zozeer de OS/2 Werkplek of Gnome voor ogen, maar de metadata voor bestanden op NTFS versie 5 schijven. En daar vallen allerlei gegevens onder: DOS bestandssattributen, de uitgebreide bestandsattributen (EA's) van OS/2 clients, de NTFS toegangscontrolelijsten (ACL's), gegevens voor POSIX systemen, informatie van programma's als virusscanners en bijvoorbeeld ook de (meta)bestandsinformatie voor de index dienst van de Windows 2000 Active Directory.
Het lokaal vastleggen van bestandseigenschappen in het bestandssysteem werkt nu eenmaal sneller en veiliger dan het in een aparte database (server) vastleggen van die eigenschappen. En omdat NTFS was ontworpen om allerlei systemen te bedienen, was er ook genoeg ruimte voor. En wel veel meer dan voor zijn voorgangers HPFS (met alleen ondersteuning voor de door DOS en OS/2 gebruikte bestandsattributen) en HPFS386 (met extra ondersteuning voor ACL's).
Op Unix bestandssystemen die de uitgebreide attributen (experimenteel) ondersteunden (EXT3, XFS, Reiser en JFS) moest samba 3 de metadata van NTFS op het UNIX bestandssysteem kwijt. Zo werden de door DOS, Windows en OS/2 clients gebruikte DOS attributen (readonly, system, hidden) door samba als uitgebreide attributen in het UNIX bestandssysteem vastgelegd.
In de afbeelding van VPC hiernaast ziet u bijv. dat Windows 2000 Professional een security tab krijgt op een samba share. Door de ondersteuning van uitgebreide attributen worden Windows ACLs gezien. Onder Windows XP Home ziet u ze als u FaJo's XP File Security Extension gebruikt. Overigens kon ik ze nog niet veranderen.
Maar helaas werkte het voor de Windows 2000 en XP professional bestemde EA transportmechanisme maar halfbakken samen met OS/2 (Lan Manager) werkstations, waardoor de EA sensitieve WPS het samba 3 bestandssysteem helemaal niet meer kon inlezen. Een gedeeltelijke verklaring hiervoor is dat OS/2 ieder bestand 64 KB ruimte voor uitgebreide attributen belooft, terwijl UNIX bestandssystemen als EXT3 nauwelijks 4 KB ' xattr' boden. Reiser, JFS en XFS doen het beter,
De situatie voor OS/2 was nog ongunstiger dan onder samba 2.2 waar OS/2 net als op FAT schijven uitgebreide attributen in WP ROOT. SF en WP SHARE. SF bestanden op netwerkdrives aanmaakte. Presentation Manager en tekstmodusapplicaties die geen uitgebreide attributen via het netwerk transporteren kennen dit probleem niet. Maar de ea-sensitieve xcopy weer wel:
[[D:\]xcopy j:\wp\*.* k:\ /h/o/t/s/e/r/v De uitgebreide kenmerken van het bestand of de directory zijn gewist, omdat het doelbestandssysteem geen uitgebreide kenmerken ondersteunt. Bronbestanden worden ingelezen... SYS1693: De directory kan niet worden gemaakt. 0 bestand(en) gekopieerd.
Onder samba 2 wordt de directory wel gemaakt en worden de bestanden zonder EA's gekopieerd.
Een soortgelijk fenomeen was ook al beschreven bij het benaderen van FAT32 partitie onder XP of W2K: Op een gedeelde FAT32 partitie ziet de OS/2 WPS slechts lege mappen. Dit probleem deed zich voor als Windows XP en 2000 een FAT32 partitie als NTFS partitie benaderen (een ontwerpfout in Windows dus). NTFS kent aan ieder bestand gebruikersrechten toe, maar FAT32 doet dat niet. Het Windows netwerk veronderstelt ten onrechte dat de bestanden op FAT32 shares bestandspermissies hebben.
Welke opties hebben we zolang dit probleem niet opgelost is? De laatste versie samba versie die ik installeerde (3.0.14A) had het probleem nog. Ik zag het probleem ook met de op samba code gebaseerde Netdrive voor OS/2, wat aangeeft dat het toch wel een server probleem moet zijn.
De enigste optie was om Samba 2.2.12 van 29 september 2004 te draaien. De broncode kan van www.samba.org worden opgehaald. Ziet u tegen compileren op dan zijn ook rpm pakketen beschikbaar in http://samba.org/samba/ftp/Binary_Packages. Deze kunt u onder SuSE het best met sax(2) installeren.
In oktober 2004 kwam Samba 3.0.20b uit. Van de instabiele testversie Samba 3.0.20a werd op news.ecomstation.nl gemeld dat de problemen met OS/2's uitgebreide attributen opgelost waren, dus haalde ik de stabiele Samba 3.0.20b rpm pakketjes op voor Suse 9.1: In maakte een backup van /etc, controleerde de paden en installeerde de rpm pakketjes met de mc vanuit ssh voor OS/2. De configuratiebestanden in /etc/init.d en /etc/xinetd.d werden aangepast (ze verwezen eerder naar /usr/local/samba/, nu naar /usr/share/samba). Opnieuw werd via yast de samba server ingesteld. Eerder (met de niet meer door suse 9.1 ondersteunde versie 2) gebeurde dat handmatig met mc of met swat (op http://server:901).
Swat deed het, maar de onmisbare swat help links deden het nog niet. Hiervoor was het pakket samba-doc-3.0.20b-2.1.i586.rpm nodig. Maar vanuit OS/2 kon ik de samba server zien (net view), maar nog niet expliciet benaderen:
[F:\]net view Naam server Opmerking _______________________________________ \\DESKPRO \\MULTIBOOT \\ZOLDER SAMBA 3.0.20B-2.1-SUSE De opdracht is uitgevoerd. [F:\]net view \\zolder NET3502: OS/2-fout 5 is opgetreden. SYS0005: Toegang geweigerd
Ik dacht eerst dat het samba wachtwoordbestand door de update veranderd was. Daarom logde ik via ssh in om het wachtwoord te veranderen.
zolder:/home/sjoerd # smbpasswd sjoerd New SMB password: Retype new SMB password: Password changed for user sjoerd.
Maar dat veranderde niets aan het probleem. Ook niet als ik de samba server herstartte (met: /etc/init.d/smb restart). Ook de andere grote valkuil; de OS/2 firewall was niet het probleem. Als ik die uitzette bleef alles hetzelfde. Wel zag ik in het router logbestand dat de samba server vanaf een lage UDP poort >1023 contact wilde maken met poort 137 op OS/2 . Tot nu toe verliep die communicatie tussen beide UDP poorten 137. Maar als ik dit in mij firewall toestond waren de problemen niet verdwenen.
Uiteindelijk hielp een reboot van het Linux systeem. Hierna kon ik wel weer inloggen op de samba server. Maar onder de WPS zag ik lege folders met de foutmelding " Er zijn geen objecten met de opgegeven zoekcriteria aangetroffen". PM en VIO applicaties konden de share wel lezend en schrijvend benaderen. En netstat onder OS/2 en smbstatus onder Linux gaven een correct werkende TCP verbinding aan.
sjoerd@zolder:~> smbstatus WARNING: The "printer admin" option is deprecated Samba version 3.0.20b-2.1-SUSE PID Username Group Machine ------------------------------------------------------------ 9043 sjoerd users multiboot (192.168.123.5) Service pid machine Connected at ------------------------------------------------------- sjoerd 9043 multiboot Fri Nov 4 08:48:42 2005 IPC$ 9043 multiboot Fri Nov 4 08:48:42 2005 samba 9043 multiboot Fri Nov 4 08:48:42 2005 mp3 9043 multiboot Fri Nov 4 08:48:42 2005 fat32 9043 multiboot Fri Nov 4 08:48:43 2005 No locked files
Opnieuw had ik dus het probleem met de hoger in de TCP IP stack doorgegeven uitgebreide attributen. Maar de WPS liet de shares wel zien na het invoeren van ea support = Yes in de Global section van smb.conf:
[Globals] ea support = Yes
De bestanden WP ROOT. SF en WP SHARE. SF worden dan niet meer aangemaakt. U kunt ze met ea support = Yes aan gerust wissen. Want ze worden nu lokaal opgeslagen in alle Linux bestandssystemen die uitgebreide attributen ondersteunen: in ieder geval Reiser, JFS en XFS; NFS en EXT2/3 zouden het met kernel 2.6 moeten doen. EXT2 en 3 moeten hiervoor met de 'user_xattr' optie gemount worden.
Maar dat de OS/2 WPS ondersteuning nu werkte, betekende nog niet dat samba 3 voor OS/2 gebruikers betrouwbaar was. Daarvoor waren uitgebreide testen en veel tijd nodig. Wie naar de gefixte bugs kijkt ziet dat er gemakkelijk uitzonderingssituaties kunnen optreden. Situaties die normaal niet optreden, maar wel als een smb.conf of een OS/2 IBMLAN.INI parameter anders staat of bij kleine foutjes in het bestandssysteem.
Ook de vertaling van de OS/2 naamgeving en bestandsattributen via Samba naar bijv. Reiser onder Linux is een omslachtig procedure. Zo zijn de DOS, OS/2 en Windows opdrachten niet voor hoofd of kleine letters gevoelig (case sensitief), maar de programmabestanden worden wel op HPFS, JFS en FAT volgens de POSIX regels opgeslagen. Dus met behoud van grote en kleine letters. Waar Windows het vFAT en FAT32 heeft, gebruikt OS/2 het Super FAT bestandssysteem waarbij de lange namen en uitgebreide attributen in WP ROOT. SF en WP SHARE. SF opgeslagen worden. En van dit mechanisme maakt ze ook op FAT netwerkdrives gebruik.
Legitieme vragen zijn dus:
Daar was meer tijd voor nodig.
Begin februari 2006 liep mijn Linux server - een door het bedrijfsleven afgedankte 800 MHz Celeron Compaq - steeds weer vast. Ik dacht eerst dat de kinderen de server die ze ook wel voor spelletjes, internet en televisie (bttv) gebruiken keihard (harde reset) hadden uitgezet, maar het Reiser bestandssysteem gaf steeds weer fouten aan. Pas nadat ik ACPI via PnP OS = Yes in het BIOS aanzette, gaf de SMART monitor van het ACPI BIOS groot alarm. De bijna 5 jaar oude Maxtor schijf uit 2001 had het begeven. Voor OS/2 had ik PnP OS uitgezet, vandaar dat het blijkbaar voor Windows PnP geoptimaliseerde ACPI BIOS bij iedere reboot zijn mond had gehouden over de defecte schijf (:-(.
Nu had ik mijn data op een tweede 120 GB grote IDE schijf, zodat deze niet verloren gingen. Ik kon hierop nog backups maken van \home, \etc en \var\spool\mail maken en zo mijn belangrijkste data redden.
Ik besloot Novell SuSE 10 aan te schaffen. Daarna installeerde ik SuSE Linux 10 op de 120 GB vaste schijf. In de eerste instantie gaf de samba server onder OS/2 en Windows 2000 en XP home geen probleem. Dat kwam overeen met mijn goede OpenSuse ervaringen, maar Novells SuSE Linux samba versie was weer wat ouder. En toen ik er later met OS/2 eCS en Warp 4 niet meer in kwam, besloot ik samba te updaten met rpm bestanden uit: http://us5.samba.org/samba/ftp/Binary_Packages/SuSE/3.0/i386/10.0/.
Ik heb eerst de SuSE 10 samba componenten verwijderd (zoeken naar samba en cifs in Yast2 en deze deïnstalleren) en daarna de map met gedownloade samba pakketten aan Yast2 / Software / Wijzig Installatiebron als Lokale directory toegevoegd. Achteraf had ik ook het HTTP adres kunnen nemen om updates uit voeren. Wat dat betreft is Yast2 flexibel genoeg.
Daarna herstartte ik het systeem, maar nu bleek na een /etc/init.d/smb restart samba niet meer automatisch te lopen.
Shutting down Samba SMB daemon Warning: daemon not running. done Starting Samba SMB daemon done zolder:/home/sjoerd #
Dit kon in de runlevel editor van yast2 hersteld worden. De samba server smb heb ik toegevoegd.
Maar OS/2 gaf weer dezelfde foutmelding:
[F:\CMD]net use T: \\zolder\sjoerd NET3502: OS/2-fout 53 is opgetreden. SYS0053: Het pad voor het netwerk is niet gevonden.
Ping zolder deed het en zolder was in MPTS tweemaal toegevoegd. Wat bleek? Etc/samba/smb.conf was overschreven. Tux-Net was het domein geworden. Maar ik had een actueel backup van etc. Dat is een kleine moeite met mc, dus altijd doen voor voor een systeemwijziging. En daarmee kon ik smb.conf weer terugzetten.
Doelbestand "/etc/samba/smb.conf" bestaat reeds!
Brondatum: feb 12 22:56, grootte 2215
Doeldatum: feb 9 14:44, grootte 1200
Dit doel overschrijven? [ Ja ] [ Nee ] [ Toevoegen ]
[ Reget ]
Alle doelen overschrijven? [ Alle ] [ Verversen ][ geEn ]
[ bij verSchillende grootte ]Maar na het herstarten van samba met /etc/init.d/smb restart liep het weer mis met dezelfde NET3502: OS/2-fout 53 is opgetreden.
zolder:/home/sjoerd # smbpasswd sjoerd New SMB password: Retype new SMB password: Failed to find entry for user sjoerd. Failed to modify password entry for user sjoerd
Verder kijkend bleek dat dat ook het oude /etc/samba/smbpasswd niet meer bestond. Net als de vorige keer bleek het samba wachtwoord bestand te zijn overschreven. Daarom kon ik wel de samba gebruiker sjoerd toevoegen, maar hem (daarvoor nog) niet wijzigen.
zolder:/home/sjoerd # smbpasswd -a sjoerd New SMB password: Retype new SMB password: Added user sjoerd.
Opnieuw bleek de backup van /etc/samba/ waardevol. Want het oude samba wachtwoordbestand /etc/samba/ smbpasswd bleek het nog wel te doen. En dit bespaarde me de wachtwoorden van de ander werkgroep leden opnieuw in te voeren. Maar wel slordig van de rpm makers om er niet een backup van te laten maken. Maar misschien was het met een update beter gegaan (hier niet getest).
Met het goede wachtwoord kreeg ik opnieuw dezelfde foutmelding. Het probleem zat dus op een lager niveau van communicatie. En dat is echt vervelend. Want dan gaat het niet meer om herstelbare configuratiefouten, maar om basale protocollaire fouten en onenigheden.
Uiteindelijk bleek dat yast2 na de deïnstallatie ook de open firewall poorten 139 en 445 had uitgezet (wel logisch). Via Yast2 Netwerkdiensten Samba server was dit te herstelen. Uiteindelijk was dit de oorzaak van de "SYS0053: Het pad voor het netwerk is niet gevonden" foutmelding.
Mocht u deze foutmelding blijven houden, controleer dan altijd weer de basale uitgangspunten.
Zet om te beginnen eventuele firewalls filters voor het LAN (niet de interface naar het internet!)) even uit.
Controleer dat het IP adres van de server in het OS/2 host bestand (\MPTN\ETC\hosts) zit.
192.168.1.2 zolder.thuis zolder
Bij gebruik van DHCP hoeft de hostnaam van de server natuurlijk niet in \MPTN\ETC\hosts te zitten. Als de DHCP server het IP adres van uw hostbestand veranderd hebt u een probleem met SET USE_HOSTS_FIRST=1 in de CONFIG.SYS. De volgende opdrachten met betrekking tot uw samba server zouden het dus altijd moeten doen. Anders heb u een basaal probleem op het gebied van de IP laag dat u eerst moet oplossen.
[F:\]host zolder zolder.thuis = 192.168.123.2 [F:\]ping zolder PING zolder.thuis: 56 data bytes 64 bytes from 192.168.123.2: icmp_seq=0. time=0. ms 64 bytes from 192.168.123.2: icmp_seq=1. time=0. ms 64 bytes from 192.168.123.2: icmp_seq=2. time=0. ms 64 bytes from 192.168.123.2: icmp_seq=3. time=0. ms
Controleer dat de NetBIOS naam van de server in \IBMCOM\RFCNAMES.LST staat:
"zolder" 192.168.1.2 "zolder" zolder
De laatste vorm heeft mijn voorkeur, want dan hoeft u alleen maar het host bestand aan te passen als de DNS naam dezelfde is als de netBIOS naam. En het werkt ook als een DHCP client zijn hostnaam doorgeeft aan de DHCP server.
En laat OS/2 zich bij de server aanmelden via de NetBIOS via TCP/IP Verzendlijst (\IBMCOM\RFCBCST.LST):
192.168.1.255 zolder
Mocht u dan nog een NET3502: OS/2-fout 53 zien, dan is het verstandig om naast de samba server (smb) de samba naamserver (nmb) te installeren.
De Samba Naming service over IP zet TCP/IP hostnamen in NetBIOS namen om. Een Windows client kan u een SMB server benaderen via zijn IP adres, maar OS/2 verwacht dat de server NetBIOS namen gebruikt. NET VIEW \\192.168.1.2 werkt dus niet onder OS/2. Dat moet NET VIEW \\zolder zijn en de hostnaam of het IP adres van zolder moet in \IBMCOM\RFCNAMES.LST staan. En als het de hostnaam is dan moet die via de DNS op te lossen zijn.
Onder OS/2 doet het als eerder genoemde bestand \IBMCOM\RFCNAMES.LST dienst als hostbestand voor de NetBIOS namen. Onder Windows NT en opvolgers zitten het gewone host bestand en lmhost bestanden in %WINDIR%\system32\drivers\etc. En onder samba gaat het om het bestand lmhosts. Afhankelijk van de distributie staat het in /usr/local/samba/lib/LMHOSTS of in /etc/samba/lmhosts. Vraag 'man lmhosts' hoe het zit in uw distributie. De manual geeft ook een voorbeeld voor de configuratie.
An example follows: # # Sample Samba lmhosts file. # 192.9.200.1 TESTPC 192.9.200.20 NTSERVER#20 192.9.200.21 SAMBASERVER
Het lijkt op die van Windows en OS/2. Wilt u een NetBIOS server voor de opdracht NET VIEW verbergen dan voegt u een #20 toe achter de netbiosnaam in de tweede kolom. Maar een gerichte NET VIEW \\NTSERVER zal het dan wel doen. Dat wil zeggen het IP adres 192.9.200.20 van NTSERVER aan de NetBIOS stack wordt doorgegeven en de shares worden afgebeeld. En dus zal de NET USE STATION: \\NTSERVER\SHARE opdracht het ook doen.
Vraag: Hoe moet u het lmhost bestand instellen als u van dynamische IP adressen gebruik maakt. Dus als u DHCP gebruikt. Onder OS/2 kunt u dan het best in \IBMCOM\RFCNAMES.LST de door de DHCP server gebruikte hostnamen opgeven:
"zolder" zolder
Maar daarnaast kan OS/2 ook gebruik maken van een NetBIOS namenserver. Dus niet die van de router die eigenlijk alleen de door Windows gebruikte hostnamen weergeeft, maar een echte Windows Internet Naming Service (WINS) dienst. Dit is wat IBM de NetBIOS naamserver onder de OS/2 NetBIOS via TCP/IP Drive parameters instellingen noemt. Het gaat om de volgende instelling in \IBMCOM\PROTOCOL.INI:
|[tcpbeui_nif] NBNSADDR = "192.168.1.2"
Hier kunt u het IP adres van uw samba naamserver (nmb) invoeren. Maar deze moet wel goed ingesteld zijn, want er niet iets als SET USE_RFCNAMES.LST_FIRST=1!
Bij een backup mag u in de vertaalslag van het ene naar het andere medium geen dat verliezen. De inhoud van een gekopieerd bestand zal in de praktijk bijna nooit worden veranderd. Zowel de netwerkhardware als de software voeren hier hun controles op uit. Anders ligt het met systematische fouten, die bijv. ontstaan omdat het ene bestandssysteem andere eigenschappen heeft als het andere. Met name de taalinstellingen zijn dan van belang. Deze bepalen of de exact gekopieerde enen en nullen ook in uw taal worden weergeven. Wie wel eens vreemde "Windows ansi" teksten ziet, weet waar het om gaat. Zie: Codetabellen en speciale tekens in de OS/2 sectie.
Onder OS/2 werk ik met de config.sys instelling CODEPAGE=850,437. De meertalige codetabel 850 is actief en "DOSLatinUS"codetabel 437 kan met chcp 437 worden geactiveerd. Maar dat laatste is in mijn praktijk nooit nodig.
J:\>chcp Active code page: 850 Prepared system code pages: 850; 437
Ook samba maakt gebruik van CP850 en het universele UTF-8 in het (virtuele bestands)systeem:
[global] dos charset = CP850 unix charset = UTF-8 display charset = LOCALE
Als er hier iets misgaat dan heeft dat waarschijnlijk met de taalinstellingen van afzonderlijke applicaties te maken. Want net als onder Linux vormt een op Unicode gebaseerd systeem de vertalende instantie (ULS: Landinstellingen van OS/2). En de meeste applicaties maken van de systeeminstellingen gebruik.
Samba 3 moet OS/2's uitgebreide attributen in het bestandssysteem kunnen opslaan. Anders kan de hiervan afhankelijke WPS er niets mee.
[Globals] ea support = Yes
Zonder deze instelling zal de WPS de samba 3 shares wel zien, maar hun inhoud niet kunnen benaderen ("No objects were found that matched the specified criteria"). U moet deze optie expliciet instellen. De default is nee, omdat niet alle kernels en bestandssystemen EA's ondersteunen.
Van belang is ook het bestandssysteem. Reiser, XFS en JFS ondersteunen de door OS/2 gebruikte 64 KB EA's per bestand. EXT2 en EXT3 ondersteunen maar 4 KB per bestand. En dat geeft dus na een tijdje problemen.
Unix bestandssystemen hebben andere eigenschappen dan DOS, OS/2 en Windows bestandssystemen. Een verborgen bestand begint onder Unix met een punt, maar onder DOS en zijn navolgers is het "verborgen zijn" een apart bestandsattribuut. In 1993 (*) werd daarom al besloten om in samba 3 uitgebreide attributen te gebruiken om de DOS attributen Systeem (system), Verborgen (hidden), Archief (archive) en alleen lezen (read-only) te emuleren.
Voor een OS/2 gebruiker heeft deze instelling beslist voordelen.
[Globals] store dos attributes = Yes
Deze voor OS/2 nuttige optie staat standaard uit (No). Gebruik in swat de Advanced view van Globals of voer het Yes handmatig toe in smb.conf.
Zoals gezegd worden de DOS attributen door samba als uitgebreide attributen op het server bestandssysteem opgeslagen. UNIX bestandssystemen gebruiken het UGO systeem van bestandspermissies. Een systeembestand zal dan bijvoorbeeld alleen te lezen zijn door zijn eigenaar en root. Er is onder UNIX dus geen noodzaak om een bestand als hidden of systeem te labelen. Dat wekt alleen maar aandacht.
Mocht u met Samba/2 werken, dan worden de DOS attributen op bijv. HPFS of JFS door Samba/2 genegeerd. Dat een lokaal bestand onder OS/2 read-only is, ziet samba niet, omdat samba op de hiermee onbekende UNIX bestandssystemen gebaseerd is. Samba/2 zal het dus gewoon tonen. En als een bestand via samba het read-only attribuut krijgt, zal dit bestand op de OS/2 server niet dat DOS attribuut krijgen, omdat het in de uitgebreide attributen vastgelegd is. En niet als een klassiek DOS attribuut.
Een lastige optie is:
hide dot files = Yes
Deze staat standaard aan. Dit voorkomt dat een Windows of OS/2 gebruiker (%u) van de home map (path = /home/%u) de voor Linux zo belangrijke punt-configuratiebestanden per abuis wist. De Windows en OS/2 bestandssystemen beschouwen de UNIX .puntbestanden immers niet als verborgen. Maar als samba ze verbergt, kunnen ze niet door programma's als secure shell over het netwerk worden benaderd.
Persoonlijk vind ik het handig om iedere gebruiker een map /home/user-id/Documents te geven en deze als de standaardshare homes te mappen. Dit heb ik van SuSE afgekeken. Gebruikers moeten samba gebruiken om hun "My Documents" te lezen, maar niet voor de de mail en de configuratiebestanden. Daar zijn de veel veiliger mail en ssh applicaties voor beschikbaar.
[homes]
# Let op: Dit is niet de echte home directory: path = /home/%u van de Unix user-id.
# waarop u kunt inloggen met de samba gebruikersnaam %S.
# maar besef dat de samba (%S) en Unix (%u)gebruikersnamen kunnen verschillen.
[homes]
comment = Home Directories
path = /home/%u/Documents
valid users = %S
read only = No
inherit acls = Yes
browseable = No
Suse's
standaardshare van alle gebruikers [users] behalve root deel ik
liever niet. En zeker niet met de instelling "hide dot files =
Yes". Hiermee zouden andere gebruikers wachtwoorden, slecht
beveiligde mailbestanden (normaal is -rw-------, maar vreemd genoeg
-rw-r----- voor send) en andere vitale bestanden van hun home\buren
kunnen afkijken. Deze al te openbare share is dus met het # teken
geremd: een standaardinstelling doelbewust weglaten of veranderen doe
ik liever met een remark.
# [users] # comment = All users # path = /home # read only = No # inherit acls = Yes # veto files = /aquota.user/groups/shares/
Na deze wijzigingen maakte ik de dot files globaal zichtbaar t.b.v. backups en dergelijke.
[Globals]
hide dot files = noMaar als u de puntbestanden alleen op bepaalde shares nodig hebt, dan kunt "hide dot files = no" natuurlijk ook uit de globale sectie halen en alleen onder het kopje van de betreffende share (hier: Backup) plaatsen:
[Globals]
hide dot files = yes
[Backup]
comment = Deze map is van sjoerd
path = /backup
valid users = sjoerd
hide dot files = no
inherit acls =no
read only = No
browsable = noAls u onder Windows 2000 de bestandspermissies (ACLS) van een map instelt, kunt u ervoor kiezen ze ook voor onderliggende mappen te laten gelden. Samba zal ze echter niet overnemen; tenzij u onderstaande waarden globaal of lokaal of yes zet. Overigens wordt het setuid bit nooit overgeërfd.
[Globals] inherit permissions = no inherit ACLS = no
In latere versies van swat kwam de optie "inherit permissions" niet meer voor.
Met Service Pack 3 voor Windows NT 4 voerde Microsoft een nieuwe vorm van wachtwoordversleuteling in. Dit NT LM 0.12 protocol verzorgde een tweezijdige versleuteling die moeilijk door een "man in the middle" te kraken was. Hierdoor konden gebruikers van NT werkstations zich redelijk veilig op de Windows NT domeincontrollers authentificeren.
Maar de oude Windows (9x, 3.11) en alle OS/2 versies ondersteunden deze tweezijdige vorm van wachtwoordversleuteling niet. Als zij contact met de NT SP3 domeincontroller (DC) zochten moest de DC dus naar het oude met eenzijdig versleuteling werkende LanManager 2.1 protocol uit 1992 overschakelen. Wat de DB ook deed, omdat maar weinig bedrijven de laatste NT werkstations gebruikten. En omgekeerd moest een NT SP3 werkstation maar het LanManager 2.1 overschakelen als het met een OS/2 LAN server of peer werkstation te maken kreeg. Of automatisch naar een nog lagere vorm van versleuteling als de server daarom vroeg.
Maar wat moest een Windows NT SP3 werkstation doen als hij met een peer server te maken kreeg die slechts onversleutelde wachtwoorden ondersteunde? Alle vormen van versleuteling van hoog naar laag uitproberen om het ten slotte maar onversleuteld uit te proberen? Dat was de oude LM manier waar ook OS/2 nog gebruik van maakt. Dit ging Microsoft te ver, want het zou haar beveiliging uitschakelen. Een hacker die een Windows NT server over kon nemen zou op die manier onversleutelde (plain text) wachtwoorden kunnen afdwingen. Microsoft besloot daarom het (automatisch) verzenden van plain text passwords vanaf NT SP3 Werkstations te verbieden. Sterker nog: ze verbood dat Windows NT werkstations contact zouden maken met servers die gemakkelijk plain text passwords accepteerden. Daaronder zaten UNIX werkstations en servers die niet over deze door IBM en MS gedeelde closed source beschikten.
Maar het samba team wilde ze beiden bedienen. Daarom bood ze een instelling aan waarmee clients ook met onversleutelde LanManager wachtwoorden konden inloggen, zonder dat Windows NT SP 3.5 werkstations argwaan kregen.
[Globals] update encrypted = Yes
Maar voor moderne OS/2 clients is deze instelling niet nodig, omdat samba OS/2's LM wachtwoordversleuteling goed ondersteund. Update encrypted = No of de instelling weglaten is wat veiliger.
[Globals] lm announce = Yes
De standaardwaarde is auto. Samba reageert dan op de "hier ben ik" omroep van een OS/2 client. Maar samba kan zich naar OS/2 toe ook pro-actief gedragen met een spontane lm announce, zoals ook ieder OS/2 werkstation doet.
wins support = Yes
De optie wins support biedt OS/2 enige voordelen. Samba's nmb demon emuleert een NetBIOS namen server, maar deze is weer op het - niet zo OS/2 vriendelijke - Windows Internet Naming Service (WINS) model gebaseerd. Uw Windows clients kunnen er wel hun voordeel mee doen. En OS/2 in die gevallen dat ondanks perfecte OS/2 instellingen het netwerkpad niet wordt gevonden.,
De door u gebruikte OS/2 NetBIOS namen en bijbehorende IP adressen kunt u ook handmatig (\ibmcom\rfcnames.lst) of met MPTS instellen (IBM OS2 NETBIOS via TCIP installeren):
"laptop" laptop.thuis "visser" visser.thuis "zolder" 192.168.1.2
Eerder stelde ik de volgende legitieme vragen:
Bij een backup over het netwerk met dsync voor OS/2 van minder dan 4 GB date zie ik in de regel geen problemen. Maar als ik 15 GB naar mij samba server kopieer wordt de kopieeractie doorgaans wel door NET foutmeldingen onderbroken. Bestanden groter dan 2 GB kon ik niet verplaatsen maar dit probleem ligt waarschijnlijk aan de OS/2 kant.
Ik
denk het niet. De voor OS/2 optimale instellingen kunnen ook door
Windows clients worden benut. De EA ondersteuning was oorspronkelijk
voor Windows 2000 en XP bedoeld om de MS Directory Services te
ondersteunen. Dat OS/2 hier ook van meeprofiteren kan is vooral te
danken aan de samba bijdragen van Guenter
Kukkukk.
Voor zover ik kon nagaan gelden hier dezelfde regels als op een OS/2 LM of Windows SMB server. Allereerst gelden de bestandspermissie van het lokale bestandssysteem: hier van de samba server.
Als sjoerd onder Linux geen leesrechten op de map /home/atke/Drafts van zijn dochter heeft, zal hij die map ook niet via de door samba vrijgeven share \\users (lees \home) kunnen benaderen.
OS/2 geeft dan "Toegang geweigerd:padnaam" voor de nog wel weergeven bestanden of "Er zijn geen objecten met de opgegeven zoekcriteria aangetroffen"voor de geopende mappen.
Na een update naar OpenSuse 11.0 deed de samba server het niet onder OS/2. Dat wil zeggen niet via NetBIOS via TCP/IP. De samba client van Netdrive die poort 445 gebruikte deed het wel.
De oorzaak bleek een verborgen default instelling te zijn die de LAMNAN2 authentificatie van OS/2 negeerde.
# change for W9x and OS/2 clients! # lanman auth = no
De manual van smb.conf zegt hierover:
Oftewel: standaard kan een OS/2 of Windows 9x client niet inloggen. Het resultaat is dat de client OS/2 authentificatie mislukt:
[F:\]net view Naam server Opmerking ____________________________________________________________________ \\DESKPRO \\MULTIBOOT \\ZOLDER SAMBA 3.2.3-0.1-1882-SUSE-SL11.0 AT ZOLDER De opdracht is uitgevoerd. [F:\]net view \\zolder NET3502: OS/2-fout 5 is opgetreden. SYS0005: Toegang geweigerd [F:\]net use T: \\zolder\homes NET2758: Het systeem kan geen verbinding maken met de server. Voor meer informatie typt u HELP NET2758.
Met de smb.conf instelling:
log level = 2
Vertelde het het logbestand \var\log\samba\smbd hier het volgende over:
[2008/09/03 23:49:03, 2] lib/interface.c:interpret_interface(469) interpret_interface: Adding interface 192.168.123.2/255.255.255.0 [2008/09/03 23:49:03, 2] lib/interface.c:add_interface(334) added interface 192.168.123.2/2 ip=192.168.123.2 bcast=192.168.123.255 netmask=255.255.255.0 [2008/09/03 23:49:03, 2] smbd/server.c:open_sockets_smbd(581) waiting for a connection [2008/09/03 23:49:08, 2] smbd/reply.c:reply_special(425) netbios connect: name1=ZOLDER name2=MULTIBOOT [2008/09/03 23:49:08, 2] smbd/reply.c:reply_special(432) netbios connect: local=zolder remote=multiboot, name type = 0 [2008/09/03 23:49:08, 2] smbd/sesssetup.c:setup_new_vc_session(1363) setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources. [2008/09/03 23:49:08, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [SJOERD] -> [SJOERD] FAILED with error NT_STATUS_WRONG_PASSWORD [2008/09/03 23:49:16, 2] smbd/reply.c:reply_special(425) netbios connect: name1=ZOLDER name2=MULTIBOOT [2008/09/03 23:49:16, 2] smbd/reply.c:reply_special(432) netbios connect: local=zolder remote=multiboot, name type = 0 [2008/09/03 23:49:16, 2] smbd/sesssetup.c:setup_new_vc_session(1363) setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources. [2008/09/03 23:49:16, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [SJOERD] -> [SJOERD] FAILED with error NT_STATUS_WRONG_PASSWORD [2008/09/03 23:49:19, 2] smbd/reply.c:reply_special(425) netbios connect: name1=ZOLDER name2=MULTIBOOT [2008/09/03 23:49:19, 2] smbd/reply.c:reply_special(432) netbios connect: local=zolder remote=multiboot, name type = 0 [2008/09/03 23:49:19, 2] smbd/sesssetup.c:setup_new_vc_session(1363) setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources. [2008/09/03 23:49:19, 2] auth/auth.c:check_ntlm_password(318) check_ntlm_password: Authentication for user [SJOERD] -> [SJOERD] FAILED with error NT_STATUS_WRONG_PASSWORD
Met de smb.conf instelling lanman auth = Yes gaat het wel goed.
[F:\]net use T: \\zolder\homes De opdracht is uitgevoerd.
Voor samba servers die printers herbergen is het volgende instelling van belang:
large readwrite (G)
Standaard zal de een samba client
Uit smb.conf:
Zet dus client lanman auth expliciet op Yes.
client lanman auth = Yes
Daarnaast moet u smbmount installeren, die in de samba 3.2.0 distributie ontbreekt. Samba maakte nu standaard gebruik van het Common Internet File System (CIFS), dat door Windows 2000 server werd ondersteund. Maar het door smbmount gebruikte SMB bestandssysteem (fstab type smbfs) wordt helaas door steeds minder standaardkernels ondersteund. In ieder geval niet meer door Feodora en OpenSuse.
zolder:/home/sjoerd # mount /mnt/data mount: onbekende bestandssysteemsoort 'smbfs'
Maar voor Windows 2000 en XP emulerende CIFS bestaat de OS/2 server weer niet.
zolder:/home/sjoerd # mount /mnt/data mount error 112 = Host is down Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
Wilt u dus OS/2 vanuit Linux benaderen, dan heeft u veel werk te doen.
Een Linux kernel compileren met smbfs ondersteuning.
En een met smbmount compatibele samba versie installeren.
Op Samba - SerNet staan recente versies in http://ftp.sernet.de/pub/samba/.
Maar dit alles is veel werk en kan (is) met de eerste beste samba security fix waarschijnlijk weer obsoleet.
Daarom is het slimmer een plugin te gebruiken.
Met KNetAttach bleken OS/2 shares wel bereikbaar.
Essentieel was de volgende module:
Dezeis te vinden op: http://barryp.org/software/py-smbpasswd/ maar maakt deel uit van de het standaard KNetAttach pakket zodat u het niet afzonderlijk hoeftte installeren.
Maar u moet deze module natuurlijk wel een kans geven met de Global smb.conf instelling:
client lanman auth = Yes
Want anders gedraagt Samba zich als een onwetende Windows Vista of later client die niets meer van haar oorsprong in het het oude LANMAN protocol van Windows 3.1, 95, 98 en ME wil weten. Ook Windows XP en 2000 doen hier al moeilijk. Zo zetten ze het door OS/2 en Windows 9x gebruikte NetBIOS via TCP/IP standaard uit (netwerkaart / TCP/IP/ extra opties). Waardoor OS/2 en Windows 9x servers voor gewone gebruikers (maar zeker niet voor hackers) ineens onzichtbaar werden. Dit natuurlijk voor uw eigen veiligheid.
Extended attributes - LinuxQuestions.org Wiki
Linux Extended Attributes and ACLs
The Official Samba-3 HOWTO and Reference Guide
Samba-3 by Example Practical Exercises in Successful Samba Deployment. John H. Terpstra
The use of TCP port 445 in Windows 2000
Deze tekst mag niet worden gewijzigd, vermenigvuldigd of voor commerciële doeleinden gebruikt worden zonder toestemming van de auteur. © Sjoerd Visser (2005).