Table of Contents
+ + + +Standalone servers are independent of domain controllers on the network. +They are not domain members and function more like workgroup servers. In many +cases a standalone server is configured with a minimum of security control +with the intent that all data served will be readily accessible to all users. +
+ + +Standalone servers can be as secure or as insecure as needs dictate. They can +have simple or complex configurations. Above all, despite the hoopla about +domain security, they remain a common installation. +
+ + + + +If all that is needed is a server for read-only files, or for +printers alone, it may not make sense to effect a complex installation. +For example, a drafting office needs to store old drawings and reference +standards. Noone can write files to the server because it is legislatively +important that all documents remain unaltered. A share-mode read-only standalone +server is an ideal solution. +
+ + + +Another situation that warrants simplicity is an office that has many printers +that are queued off a single central server. Everyone needs to be able to print +to the printers, there is no need to effect any access controls, and no files will +be served from the print server. Again, a share-mode standalone server makes +a great solution. +
+ + + +The term standalone server means that it will provide local authentication and access +control for all resources that are available from it. In general this means that there will be a local user +database. In more technical terms, it means resources on the machine will be made available in either +share mode or in user mode. +
+ + + +No special action is needed other than to create user accounts. Standalone +servers do not provide network logon services. This means that machines that +use this server do not perform a domain logon to it. Whatever logon facility +the workstations are subject to is independent of this machine. It is, however, +necessary to accommodate any network user so the logon name he or she uses will +be translated (mapped) locally on the standalone server to a locally known +user name. There are several ways this can be done. +
+ + + +Samba tends to blur the distinction a little in defining +a standalone server. This is because the authentication database may be +local or on a remote server, even if from the SMB protocol perspective +the Samba server is not a member of a domain security context. +
+
+
+
+
+
+
+
+
+Through the use of Pluggable Authentication Modules (PAM) (see the chapter on PAM)
+and the name service switcher (NSS), which maintains the UNIX-user database, the source of authentication may
+reside on another server. We would be inclined to call this the authentication server. This means that the
+Samba server may use the local UNIX/Linux system password database (/etc/passwd or
+/etc/shadow), may use a local smbpasswd file, or may use an LDAP backend, or even via PAM
+and Winbind another CIFS/SMB server for authentication.
+
+ + +The example Reference Documentation Server and Central Print Serving are designed to inspire simplicity. It is too easy to +attempt a high level of creativity and to introduce too much complexity in server and network design. +
+
+
+
+
+Configuration of a read-only data server that everyone can access is very simple. By default, all shares are
+read-only, unless set otherwise in the smb.conf file. The example - Reference
+Documentation Server is the smb.conf file that will do this. Assume that all the reference documents
+are stored in the directory /export, and the documents are owned by a user other than
+nobody. No home directories are shared, and there are no users in the /etc/passwd UNIX
+system database. This is a simple system to administer.
+
Example 7.1. smb.conf for Reference Documentation Server
| # Global parameters |
[global] |
workgroup = MIDEARTH |
netbios name = GANDALF |
security = SHARE |
passdb backend = guest |
wins server = 192.168.1.1 |
[data] |
comment = Data |
path = /export |
guest only = Yes |
+I would have spoken more briefly, if I'd had more time to prepare. + | ||
| --Mark Twain | ||
+ + + + +In this example, the machine name is set to GANDALF, and the +workgroup is set to the name of the local workgroup (MIDEARTH) so the machine will appear together +with systems with which users are familiar. The only password backend required is the “guest” +backend to allow default unprivileged account names to be used. As there is a WINS server on this network, we +of course make use of it. +
+A US Air Force Colonel was renowned for saying: “Better is the enemy of good enough!” There are often +sound reasons for avoiding complexity as well as for avoiding a technically perfect solution. Unfortunately, +many network administrators still need to learn the art of doing just enough to keep out of trouble. +
+ + +Configuration of a simple print server is easy if you have all the right tools on your system. +
Assumptions
+ The print server must require no administration. +
+ The print spooling and processing system on our print server will be CUPS. + (Please refer to CUPS Printing Support, for more information). +
+ The print server will service only network printers. The network administrator + will correctly configure the CUPS environment to support the printers. +
+ All workstations will use only PostScript drivers. The printer driver + of choice is the one shipped with the Windows OS for the Apple Color LaserWriter. +
+
+
+
+In this example our print server will spool all incoming print jobs to
+/var/spool/samba until the job is ready to be submitted by
+Samba to the CUPS print processor. Since all incoming connections will be as
+the anonymous (guest) user, two things will be required to enable anonymous printing.
+
Enabling Anonymous Printing
+ + + + The UNIX/Linux system must have a guest account. + The default for this is usually the account nobody. + To find the correct name to use for your version of Samba, do the + following: +
+$testparm -s -v | grep "guest account"+
+
+ Make sure that this account exists in your system password
+ database (/etc/passwd).
+
+
+
+
+ It is a good idea either to set a password on this account, or else to lock it
+ from UNIX use. Assuming that the guest account is called pcguest,
+ it can be locked by executing:
+
+root# passwd -l pcguest
++ The exact command may vary depending on your UNIX/Linux distribution. +
+ + + + + + + The directory into which Samba will spool the file must have write + access for the guest account. The following commands will ensure that + this directory is available for use: +
+root#mkdir /var/spool/samba+root#chown nobody.nobody /var/spool/samba+root#chmod a+rwt /var/spool/samba+
+
+The contents of the smb.conf file is shown in the Anonymous Printing example.
+
Example 7.2. smb.conf for Anonymous Printing
+
+
+
+
+
+On CUPS-enabled systems there is a facility to pass raw data directly to the printer without intermediate
+processing via CUPS print filters. Where use of this mode of operation is desired, it is necessary to
+configure a raw printing device. It is also necessary to enable the raw mime handler in the
+/etc/mime.conv and /etc/mime.types files. Refer to CUPS Printing Support, Explicitly Enable raw Printing
+for application/octet-stream.
+
+
+
+
+
+The example in the Anonymous Printing example uses CUPS for direct printing
+via the CUPS libarary API. This means that all printers will be exposed to Windows users without need to
+configure a printcap file. If there is necessity to expose only a sub-set of printers, or to define a special
+type of printer (for example, a PDF filter) the printcap name = cups can be replaced
+with the entry printcap name = /etc/samba/myprintcap. In this case the file specified
+should contain a list of the printer names that should be exposed to Windows network users.
+