| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision |
| slackware:samba [2006/03/29 19:11] – alien | slackware:samba [2018/11/02 20:16] – Small fixes to modernize the instructions. alien |
|---|
| |
| FIXME ** This article is being worked on ** FIXME | |
| --------------------------------------------------- | |
| |
| ===== File- and printersharing on the local network ===== | ===== File- and printersharing on the local network ===== |
| |
| |
| * This should be in ''/etc/samba/smb.conf'', it defines the password backend Sabma will use (I will not discuss the alternative LDAP backend here, I hope to write another article on that all of it's own): <code> | * This should be in ''/etc/samba/smb.conf'', it defines the password backend Sabma will use (I will not discuss the alternative LDAP backend here, I hope to write another article on that all of it's own): <code> |
| passdb backend = tdbsam guest | passdb backend = tdbsam:/var/lib/samba/private/passdb.tdb |
| </code> //NOTE//: when you enable //tdbsam// on an already configured and running Samba server, and run ''killall -HUP smbd'' to let it re-load the configuration files, you might have to re-add the 'smbguest' user to Samba, since the default to use is the //smbpasswd// file and not the tdbsam database.\\ So, again run: <code> | </code> //NOTE//: when you enable //tdbsam// on an already configured and running Samba server, and run ''killall -HUP smbd'' to let it re-load the configuration files, you might have to re-add the 'smbguest' user to Samba. \\ In the past, the default to use was the //smbpasswd// file but since Sa,ba 3.4 the tdbsam database became the default.\\ So, again run: <code> |
| smbpasswd -a smbguest -d | smbpasswd -a smbguest -d |
| </code> | </code> |
| - In the file ''/etc/cups/mime.convs'' uncomment ''application/octet-stream application/vnd.cups-raw 0 - '' And then restart CUPS daemon using <code>/etc/rc.d/rc.cups restart</code> | - In the file ''/etc/cups/mime.convs'' uncomment ''application/octet-stream application/vnd.cups-raw 0 - '' And then restart CUPS daemon using <code>/etc/rc.d/rc.cups restart</code> |
| |
| * It is now time to fire up our Samba server. But we will test the configuration first by running the command ''testparm''. IT will show us if anything went wrong while editing the ''smb.conf'' file. If everything seems allright, we will procede with making the Samba start script executable (so that it will still start when we boot our server) and then running the script: <code> | * It is now time to fire up our Samba server. But we will test the configuration first by running the command ''testparm''. It will show us if anything went wrong while editing the ''smb.conf'' file. If everything seems allright, we will procede with making the Samba start script executable (so that it will still start when we boot our server) and then running the script: <code> |
| chmod +x /etc/rc.d/rc.samba | chmod +x /etc/rc.d/rc.samba |
| /etc/rc.d/rc.samba start | /etc/rc.d/rc.samba start |
| </code> A Windows user can use the ''<CTRL><ALT><DEL>'' sequence to change the password! | </code> A Windows user can use the ''<CTRL><ALT><DEL>'' sequence to change the password! |
| |
| | |
| | === Samba printers === |
| | |
| | If you have a configured and running CUPS server that has at least one queue setup for //RAW// printing, we can now proceed with integrating this CUPS printer queue with our Samba server, so that Windows clients can automatically download their printer drivers from the Samba server. This is of course more convenient than accessing each and every Windows PC with a printer driver CD and manually configuring the printer. |
| | |
| | Using the directions of the previous sections and the [[#a_sample_smb.conf|smb.conf example]] of the last section, you have everything in place already, server-side. You will now have to take a Windows XP workstation, and logon to a Samba share using an account that is known to Samba as a //printer admin//. In our setup, that means: everyone who is a member of the Linux group [[linux:admin#wheel]]. |
| | |
| | FIXME //to be completed// FIXME |
| |
| === The Linux client setup === | === The Linux client setup === |
| </code> This creates three exports, all accessible by any client with an IP address in the range ''192.168.0.0/24''. I'll discuss them in reverse order: | </code> This creates three exports, all accessible by any client with an IP address in the range ''192.168.0.0/24''. I'll discuss them in reverse order: |
| - the ftp server's 'pub' directory aka the anonymous ftp area. This export will be available as read-only (the 'ro' parameter) with as safe as possible settings | - the ftp server's 'pub' directory aka the anonymous ftp area. This export will be available as read-only (the 'ro' parameter) with as safe as possible settings |
| - your webserver's DocumentRoot (/var/www/htdocs) which will be available as writable, but on the server side, all writes will appear to be done by the user with the userid:groupid of ''99:99'' which is actually the "nobody" user. If you make the DocumentRoot owned by this account (a configuration you often see, so that the Web Server's CGI or PHP scripts can write files in these directories) | - your webserver's DocumentRoot (/var/www/htdocs) which will be available as writable, but on the server side, all writes will appear to originate from the user with the userid:groupid of ''99:99'' which is actually the "nobody" user. If you let the DocumentRoot tree be owned by this account (a configuration you often see), then the Web Server's CGI or PHP scripts can write files in these directories |
| - the server's ''/home'' directory tree which can be mounted writable (the 'rw') using asynchronous transfers (faster but with a chance of data corruption in case of a server crash - 'sync' is safe but slower). User ID's (//uid//) and group ID's (//gid//), even for user 'root' will be mapped 1-on-1 (the 'no_root_squash' option). This means, if the server knows a user 'alien' with a "uid:gid" pair of ''1001:100'', then you will see this uid:gid number pair on the NFS client side as well! So, if the NFS client PC also knows a user 'alien' with the same "uid:gid" number pair of ''1001:100'', he will be able to use the files on the server as they were his own. | - the server's ''/home'' directory tree which can be mounted writable (the 'rw') using asynchronous transfers (faster but with a chance of data corruption in case of a server crash - 'sync' is safe but slower). User ID's (//uid//) and group ID's (//gid//) will be mapped 1-on-1 (even for user 'root' - the 'no_root_squash' option). This means, if the server knows a user 'alien' with a "uid:gid" pair of ''1001:100'', then alien's files in his homedirectory will appear with this uid:gid number pair on the NFS client side as well! So, if the NFS client PC also has an account 'alien' with the same "uid:gid" number pair ''1001:100'', this alien will be able to use the files on the server as they were his own. |
| <note important>You see why it is important to create users on your LAN with the same UID (and GID) on //all// computers if you ever intend to install a NFS server.</note> | <note important>You see why it is important to create users on your LAN with the same UID (and GID) on //all// computers if you ever intend to install a NFS server.</note> |
| |
