Section 4.4. Questions and Answers

4.4. Questions and Answers

F.A.Q.

1. Q:	The example smb.conf files in this chapter make use of the include facility. How may I get to see what the actual working smb.conf settings are?
A:	You may readily see the net compound effect of the included files by running: root# testparm -s | less
2. Q:	Why does the include file common.conf have an empty include statement?
A:	The use of the empty include statement nullifies further includes. For example, let's say you desire to have just an smb.conf file that is built from the array of include files of which the master control file is called master.conf. The following command produces a compound smb.conf file. root# testparm -s /etc/samba/master.conf > /etc/samba/smb.conf If the include parameter was not in the common.conf file, the final smb.conf file leaves the include in place, even though the file it points to has already been included. This is a bug that will be fixed at a future date.
3. Q:	I accept that the simplest configuration necessary to do the job is the best. The use of TDbsam passdb backend is much simpler than having to manage an LDAP-based ldapsam passdb backend. I tried using rsync to replicate the passdb.tdb, and it seems to work fine! So what is the problem?
A:	Replication of the TDbsam database file can result in loss of currency in its contents between the PDC and BDCs. The most notable symptom is that workstations may not be able to log onto the network following a reboot and may have to rejoin the domain to recover network access capability.
4. Q:	You are using DHCP Relay enabled on the routers as well as a local DHCP server. Will this cause a clash?
A:	No. It is possible to have as many DHCP servers on a network segment as makes sense. A DHCP server offers an IP address lease, but it is the client that determines which offer is accepted, no matter how many offers are made. Under normal operation, the client accepts the first offer it receives. The only exception to this rule is when the client makes a directed request from a specific DHCP server for renewal of the lease it has. This means that under normal circumstances there is no risk of a clash.
5. Q:	How does the Windows client find the PDC?
A:	The Windows client obtains the WINS server address from the DHCP lease information. It also obtains from the DHCP lease information the parameter that causes it to use directed UDP (UDP Unicast) to register itself with the WINS server and to obtain enumeration of vital network information to enable it to operate successfully.
6. Q:	Why did you enable IP forwarding (routing) only on the server called MASSIVE ?
A:	The server called MASSIVE is acting as a router to the Internet. No other server (BLDG1 or BLDG2) has any need for IP forwarding because they are attached only to their own network. Route table entries are needed to direct MASSIVE to send all traffic intended for the remote network segments to the router that is its gateway to them.
7. Q:	You did nothing special to implement roaming profiles. Why?
A:	Unless configured to do otherwise, the default behavior with Samba-3 and Windows XP Professional clients is to use roaming profiles.
8. Q:	On the domain member computers, you configured winbind in the /etc/nsswitch.conf file. You did not configure any PAM settings. Is this an omission?
A:	PAM is needed only for authentication. When Samba is using Microsoft encrypted passwords, it makes only marginal use of PAM. PAM configuration handles only authentication. If you want to log onto the domain member servers using Windows networking usernames and passwords, it is necessary to configure PAM to enable the use of winbind. Samba makes use only of the identity resolution facilities of the name service switch (NSS).
9. Q:	You are starting SWAT up on this example but have not discussed that anywhere. Why did you do this?
A:	Oh, I did not think you would notice that. It is there so that it can be used. This is more fully discussed in TOSHARG2, which has a full chapter dedicated to the subject. While we are on the subject, it should be noted that you should definitely not use SWAT on any system that makes use of smb.conf include files because SWAT optimizes them out into an aggregated file but leaves in place a broken reference to the top-layer include file. SWAT was not designed to handle this functionality gracefully.
10. Q:	The domain controller has an auto-shutdown script. Isn't that dangerous?
A:	Well done, you spotted that! I guess it is dangerous. It is good to know that you can do this, though.

Example 4.3.10. Server: MASSIVE, File: named.conf, Part: A

### # Abmas Biz DNS Control File ### # Date: November 15, 2003 ### options {    directory "/var/lib/named";    forwarders {       123.45.12.23;       123.45.54.32;       };    forward first;    listen-on {       mynet;       };    auth-nxdomain yes;    multiple-cnames yes;    notify no; }; zone "." in {    type hint;    file "root.hint"; }; zone "localhost" in {    type master;    file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in {    type master;    file "127.0.0.zone"; }; acl mynet {    172.16.0.0/24;    172.16.4.0/24;    172.16.8.0/24;    127.0.0.1; }; acl seconddns {         123.45.54.32; }; 

Example 4.3.11. Server: MASSIVE, File: named.conf, Part: B

zone "abmas.biz" {    type master;    file "/var/lib/named/master/abmas.biz.hosts";    allow-query {       mynet;    };    allow-transfer {       mynet;    };    allow-update {       mynet;    }; }; zone "abmas.us" {         type master;         file "/var/lib/named/master/abmas.us.hosts";         allow-query {                 all;         };         allow-transfer {                 seconddns;         }; }; 

Example 4.3.12. Server: MASSIVE, File: named.conf, Part: C

zone "0.16.172.in-addr.arpa" {    type master;    file "/var/lib/named/master/172.16.0.0.rev";    allow-query {       mynet;    };    allow-transfer {       mynet;    };    allow-update {       mynet;    }; }; zone "4.16.172.in-addr.arpa" {    type master;    file "/var/lib/named/master/172.16.4.0.rev";    allow-query {       mynet;    };    allow-transfer {       mynet;    };    allow-update {       mynet;    }; }; zone "8.16.172.in-addr.arpa" {    type master;    file "/var/lib/named/master/172.16.8.0.rev";    allow-query {       mynet;    };    allow-transfer {       mynet;    };    allow-update {       mynet;    }; }; 

Example 4.3.13. Forward Zone File: abmas.biz.hosts

$ORIGIN . $TTL 38400  ;  10 hours 40 minutes abmas.biz   IN  SOA   massive.abmas.biz. root.abmas.biz. (             2003021833  ; serial             10800       ; refresh (3 hours)             3600        ; retry (1 hour)             604800      ; expire (1 week)             38400       ; minimum (10 hours 40 minutes)             )          NS massive.abmas.biz.          NS bldg1.abmas.biz.          NS bldg2.abmas.biz.          MX 10 massive.abmas.biz. $ORIGIN abmas.biz. massive        A   172.16.0.1 router0                  A      172.16.0.128 bldg1                    A      172.16.4.1 router4                  A      172.16.4.128 bldg2                    A      172.16.8.1 router8                  A      172.16.8.128 

Example 4.3.14. Forward Zone File: abmas.biz.hosts

$ORIGIN . $TTL 38400  ;  10 hours 40 minutes abmas.us IN SOA    server.abmas.us. root.abmas.us. (             2003021833 ; serial             10800      ; refresh (3 hours)             3600       ; retry (1 hour)             604800     ; expire (1 week)             38400      ; minimum (10 hours 40 minutes)             )          NS dns.abmas.us.          NS dns2.abmas.us.          MX 10 mail.abmas.us. $ORIGIN abmas.us. server         A  123.45.67.66 dns2        A  123.45.54.32 gw       A  123.45.67.65 www         CNAME server mail        CNAME server dns         CNAME server 

Example 4.3.15. Servers: BLDG1/BLDG2, File: named.conf, Part: A

### # Abmas Biz DNS Control File ### # Date: November 15, 2003 ### options {    directory "/var/lib/named";    forwarders {       172.16.0.1;       };    forward first;    listen-on {       mynet;       };    auth-nxdomain yes;    multiple-cnames yes;    notify no; }; zone "." in {    type hint;    file "root.hint"; }; zone "localhost" in {    type master;    file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in {    type master;    file "127.0.0.zone"; }; acl mynet {    172.16.0.0/24;    172.16.4.0/24;    172.16.8.0/24;    127.0.0.1; }; acl seconddns {    123.45.54.32; }; 

Example 4.3.16. Servers: BLDG1/BLDG2, File: named.conf, Part: B

zone "abmas.biz" {    type slave;    file "/var/lib/named/slave/abmas.biz.hosts";    allow-query {       mynet;    };    allow-transfer {       mynet;    }; }; zone "0.16.172.in-addr.arpa" {    type slave;    file "/var/lib/slave/master/172.16.0.0.rev";    allow-query {       mynet;    };    allow-transfer {       mynet;    }; }; zone "4.16.172.in-addr.arpa" {    type slave;    file "/var/lib/named/slave/172.16.4.0.rev";    allow-query {       mynet;    };    allow-transfer {       mynet;    }; }; zone "8.16.172.in-addr.arpa" {    type slave;    file "/var/lib/named/slave/172.16.8.0.rev";    allow-query {       mynet;    };    allow-transfer {       mynet;    }; }; 

Example 4.3.17. Initialize Groups Script, File: /etc/samba/initGrps.sh

#!/bin/bash # Create UNIX groups groupadd acctsdep groupadd finsrvcs groupadd piops # Map Windows Domain Groups to UNIX groups net groupmap modify ntgroup="Domain Admins"   unixgroup=root net groupmap modify ntgroup="Domain Users"    unixgroup=users net groupmap modify ntgroup="Domain Guests"   unixgroup=nobody # Add Functional Domain Groups net groupmap add  ntgroup="Accounts Dept"        unixgroup=acctsdep type=d net groupmap add  ntgroup="Financial Services"   unixgroup=finsrvcs type=d net groupmap add  ntgroup="Insurance Group"      unixgroup=piops type=d