Software: Apache/2.0.54 (Fedora). PHP/5.0.4 uname -a: Linux mina-info.me 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 uid=48(apache) gid=48(apache) groups=48(apache) Safe-mode: OFF (not secure) /usr/bin/X11/./../../share/doc/MySQL-python-1.2.0/../samba-3.0.23a/htmldocs/Samba3-HOWTO/ drwxr-xr-x |
Viewing file: Select action/file-type: 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 ( 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 Example 7.1. smb.conf for Reference Documentation Server
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
In this example our print server will spool all incoming print jobs to
Enabling Anonymous Printing
The contents of the Example 7.2. Note
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
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 |
:: Command execute :: | |
--[ c99shell v. 1.0 pre-release build #16 powered by Captain Crunch Security Team | http://ccteam.ru | Generation time: 0.004 ]-- |