Atlantic Linux Blog

Simple Samba PDC on Debian GNU/Linux 4.0 (Etch)

Introduction

We’ve been using Samba in the office since we initially set up the office network but we’ve been using it as a simple fileshare. As we grow the company, managing individual desktops is becoming more of a headache and I’m investigating various solutions.

Samba has had the ability to run as a Windows domain controller for ages. They recommend you install an LDAP server if you have a complex network, more than 250 users or require database replication (one or more backup domain controllers). So far I’ve been reluctant to roll out an LDAP server for our network – it is extremely powerful but the pain of the initial setup hasn’t been justified yet. In addition, the management tools for LDAP are still more complex than they need to be imho.

Thankfully Samba also supports a less complex backend called tdbsam (for those of you familiar with Samba, this is a replacement for the smbpasswd file format which stores additional data over and above the smbpasswd format allowing better support for account and system access controls as seen with Windows NT/2000/2003-based systems). For the moment tdbsam sounds like it will meet our needs perfectly – we want a solution which will involve a minimum of maintenance and will allow our desktop Windows XP Pro systems to join a network and avail of services including centralised authentication, roaming profiles and network shares.

Configuration

Configuration of a basic Samba Primary Domain Controller (PDC – Microsoft’s terminology for the main Windows server – if you want to have failover servers which step in if the PDC goes down you install 1 or more BDCs – Backup Domain Controllers) is pretty straightforward – there is one configuration file you have to edit. The Samba project provide an excellent set of documentation in the Samba HOWTO Collection. It covers pretty much every configuration scenario you could be interested in. Unfortunately it does require you to do some reading and who wants to do that these days? Luckily we’re going to cover the basics of a PDC here … if you need to do something fancier you should probably start by perusing the HOWTO.

I’m going to walk through the configuration file I’ve configured on our server (with the domain and servers names changed for security reasons) and explain the various configurations. If this is all too much for now, then skip to the end where you can download the configuration file, replace the server and domain names and drop it into your Samba configuration for a working PDC. Note that these instructions are for Samba 3.0.24 running on Debian GNU/Linux 4.0 (Etch). Your mileage may vary on other versions of Samba or other Linux distributions and operating systems.

The smb.conf starts with a section for server settings called global. This section is followed by other sections describing particular shares and services.

[global]
workgroup = EXAMPLEDOMAIN
netbios name = EXAMPLESERVER
server string = %h server (Samba %v)

Here we specify that we want Samba to act as a server for a domain called EXAMPLEDOMAIN and that our Windows networking name is EXAMPLESERVER (this should normally be picked up and set from your server hostname but I’ve seen some wierd problems when this isn’t picked up correctly so it’s no harm to set it explicitly).

security = user
domain master = yes
preferred master = yes
domain logons = yes

This is effectively where we configure the server as a PDC. The setting security = user tells Samba to only allow people to connect who supply a valid username and password. The other settings configure Samba as the master browser for a domain/workgroup and act as a domain controller for the domain/workgroup.

os level = 40

This values influences whether Samba will become the local master browser for a subnet – if Samba is acting as PDC it is generally a good idea to set this high.

wins support = yes
dns proxy = yes

This enables Samba to operate as a WINS server on your network (WINS is used by Windows clients to resolve computer names to computer addresses). Normally a good idea if you are running as PDC. The dns proxy setting allows Samba to fall back to using DNS if the windows (netbios) name for the system has not been registered.

log file = /var/log/samba/log.%m
max log size = 1000
log level = 2
syslog = 0

These settings relate to system logging functionality. Note that you can increase log level for debugging purposes. A log level of 1 gives some information about what is happening, a log level of 2 gives enough information to debug most basic problems and a log level of 3 gives you lots and lots of information. Log levels higher than 3 will really only be useful to developers who need detailed information about Samba internals. The log file line configures Samba to create a single log-file for each Windows client that connects to the server.

panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
guest account = nobody
unix password sync = yes
passwd program = /usr/bin/passwd %u
pam password change = yes

Here we configure the password settings. Note that we’re using tdbsam as our backend (rather than smbpasswd or LDAP). Note also that we have configured Samba (unix password sync) to change our Linux password any time we change our Samba password (by default they are stored in 2 separate files on the system). For this scheme to work, you should always use the smbpasswd command to change your system password and not the passwd command. Note that you can also change your password when logged in to a Windows client by pressing CTRL-ALT-DEL and clicking on Change Password.

logon path = \\%L\profiles\%U
logon drive = U:
logon home = \\%L\%U
logon script = logon.cmd

You may wish to customise some of the logon settings. The logon path line specifies where roaming profiles will be stored on the server. Roaming profiles include per-user registry settings (in a file called NTUSER.DAT), My Documents and various application specific configuration files. They are a useful way of keeping a similar environment when you move between systems. We have specified that roaming profiles will be stored in a dedicated share called profiles in a subdirectory with the user’s login name. To ensure this works you will need to manually create profile directories under here for each user. Another approach is to configure logon path to point to a subdirectory in the user’s home directory. The logon path setting specifies which drive letter will be used for user’s home directory on the Samba server. Using letters from the end of the alphabet is advisable to avoid clashing with drive letters used for local drives. The logon home is set as the user’s home directory on the Samba server – if you have a more complex environment you may want to change this to something else. The logon script is a Windows script (or batch file) run by each user when they login – it can used for configure some settings for the user including setting up standard Windows shares and so on.

add machine script = /usr/sbin/useradd -d /var/lib/nobody -g windowsmachines -s /bin/false %u

The add machine script line is distribution specific – different distributions use variations of the useradd command which take different parameters. The above command works on Debian 4.0 (Etch). Note that you need to add a group on your Samba server called windowsmachines – this is the group that Windows machine accounts will belong to.

load printers = yes
printing = cups
printcap name = cups

These lines configure your printer. I’m assuming you have a CUPS server installed. This will automatically share your CUPS configure printers via Samba.

socket options = TCP_NODELAY

This parameter lets you tweak your network settings – the general recommendation is to leave this at the defaults unless you are prepared to run tests of each change you make to determine whether it improves the performance of your Samba server or degrades it (a lot of options can reduce the performance of your server if used in the wrong context).

That concludes the global settings section. The following sections are some standard shares you should provide and a single example share called office data which you can customise. Note that you can add as many sections as you require shares. We will discuss the print related shares below in a follow-up on blog about configuring printers with Samba (there are a few minor problems I have to iron out there before I document my configuration).

[homes]
comment = Home Directories
browseable = no
writable = yes
create mask = 0700
directory mask = 0700
hide files = /desktop/desktop.ini/ntuser.ini/NTUSER.*/RECYCLER/

[printers]
comment = All Printers
browseable = no
path = /var/spool/samba
printable = yes
public = yes
writable = no
create mode = 0700

[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
write list = root, @ntadmin
printer admin = root, @ntadmin

[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = yes
writable = no
share modes = no

# For profiles to work, create a user directory under the path
# shown. i.e., mkdir -p /var/lib/samba/profiles/maryo
[profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
profile acls = Yes

[office data]
path = “/data”
comment = office data files
writable = yes
locking = yes
public = yes
write list = @staff
create mask = 0775
directory mask = 0775

For the Impatient

1. Add a group on your Debian server called windowsmachines.
2. Install the samba package on your server.
3. Download smb.conf and copy it over /etc/samba/smb.conf on your Samba server.
4. Change the workgroup and netbios name settings to your own.
5. Restart Samba
6. Set your root account samba password with the smbpasswd command (it is recommended that you use a different password than your standard root password for security).
7. For each user using this PDC you will need to create a subdirectory under /var/lib/samba/profiles with their username, for example,

   mkdir -p /var/lib/samba/profiles/smulcahy

   chown smulcahy:users /var/lib/samba/profiles/smulcahy

8. To add a new user to your domain, do the following on your Debian server,
   1. Add a Linux account for the new user: adduser smulcahy
   2. Add a Samba account for the new user: pdbedit -a smulcahy
   3. Set the initial password for the new user: smbpasswd smulcahy

   The user can subsequently change their password from Windows in the usual way.

9. To join new machines to your domain, follow the standard Windows procedure of clicking on Start/Control Panel/System/Computer Name/Network Identification Wizard and use root when prompted for a user with Administrative privileges.

Next Steps
I’m hoping this is the first in a series of Samba related blogs. Some of the other items I want to look at are as follows (if there is something else you’d like me to talk about drop me a line and if it’s relevant I’ll give a shot at investigating it as I roll out our Samba server).

• Printers
• Policies

Thanks, see you soon.

Acknowledgement: I’d like to thank Mick Lohan for his feedback and testing of this procedure. Thanks Mick!

X Servers for Windows

I recently needed to connect to a remote Linux system and run some diagnostics. Normally, this involves opening an ssh session to the system in question and running various command-line tools. In this case though, there is a graphical tool which it would have been really useful to run (if you’re curious, the tool in question is Luke – a graphical tool for diagnosing problems with the Lucene Java search engine).

I usually run Linux on my desktop at work so in this case I should have been able to ssh to the system in question, and set my DISPLAY environment variable to my local desktop. Assuming the remote system allows X11 Forwarding, after that it should just be a case of typing the command on the remote system and see the command’s graphical window appearing on your local desktop.

Unfortunately, in this case, the remote system is sitting behind a Cisco firewall. To connect to it I have to use the Cisco VPN client on a Windows system (I’m aware of vpnc – a Linux Cisco VPN client but I’ve had some problems with it in the past connecting to this particular site so it’s not a viable solution here). So I’m stuck ssh’ing into the remote system from Windows using the wonderful putty ssh client. If I want to run the graphical tool on the remote system I’m going to need an X Server running on Windows.

It’s been a few years since I ran an X Server on Windows. The last time I looked, there was a bunch of commercial options including Reflection X, Exceed and X-Win32. There was also a free option from the Cygwin project. Cygwin is a collection of free software tools originally developed by Cygnus Solutions to allow various versions of Microsoft Windows to behave and feel more like a Unix system. Cygwin is a great engineering effort and does a great job of giving you a Linux-like environment on your Windows desktop – but using it involves installing all sorts of dependencies and libraries on your system. As a general rule on my Windows desktop I try to keep installed software to the bare minimum – it makes it easier to move to another system when the time comes and it makes tracking software updates and fixes less of a headache. This leaves me a bit uneasy about installing Cygwin/X – I’m sure it does a good job when installed but the prospect of having to install all those libraries put me off a little.

So I dug around on the X Window System Wikipedia page. It turns out there are a few more options since the last time I looked at X Windows servers for Windows. In particular there is the Xming server. Like Cygwin/X it is based on the current X.org release of X, but it is a standalone application that doesn’t depend on any external libraries. This sounded like just what I wanted. The Xming home page has good notes on how to configure and install Xming, so I’ll just summarise how I got it going for my environment.

1. Downloaded the 3 Xming packages – Xming, Xming-fonts and Xming-tools-and-clients.
2. Installed these packages in the same order downloaded (I extracted the Xming-tools-and-clients to C:\Program Files\Xming).
3. Started putty and enabled X11 Forwarding as described in this diagram (if you use remote X11 a lot you might want to save this to Putty’s default settings).
4. Start the Xming server locally (either via the Xming or Xlaunch commands).
5. Run the xhosts command from the Windows command prompt to enable access from the remote address

• Click Start, Run… and input cmd.
• In the command window that appears type cd \Program Files\Xming.
• from C:\Program Files\Xming type xhost +hostname where hostname is the name of the remote system.

Use putty with X11 Forwarding enabled to connect to the remote host.

Verify that X11 Forwarding is working,

• At the shell prompt type echo $DISPLAY and you should see it has been set by Putty.
• Run a simple X11 command like xeyes to verify basic operation.

If all that works, you’re all set to start your graphical commands. It worked well enough to let me get my work done. I need to take a look at ssh compression and see if that improves the speed a little. Kudos to the Xming team for putting together a nice package and some clear instructions on how to get them up and running.

The Debian Installer and Resizing Windows Partitions

Following an earlier blog about installing Debian Etch (a pre-release of Debian 4.0 due early next year) and my comments about the Debian installer’s inability to resize Windows partitions in the past, one of the Debian developers challenged me to retry it and document the results of the exercise. Specifically, he suggested I perform the following tests,

1. Backup the NTFS partition
2. Resize the NTFS partition with debian-installer (just make it some what smaller )
3. Restart the computer, boot into MS-Windows to check the partition.
4. Resize the NTFS partition with debian-installer (back to previous size)
5. Restart the computer, boot into MS-Windows to check the partition.
6. Report/blog about the NTFS resize excersize

I haven’t gotten around to 4. yet but hopefully people will find the rest useful (and I will try to get around to 4. at some stage, but it seems a shame to blow away a perfectly good Debian install).

Restoring the default Windows configuration

I started by taking our test PC and restoring it the same state that it came from the factory. The test PC is a HP dx5150 – an AMD Athlonâ„¢ 64 3200+ system with 1GB of memory and an 80GB SATA hard drive. As well as providing a Windows XP SP2 CD which can be used to install Windows in whatever configuration you desire, HP provide a Restore CD which repartitions the drive, installs Windows in a standard configuration and installs some additional tools and drivers. This is reasonably useful but has the unfortunate downside of insisting on using the entire drive for Windows. In our case, this is ideal, since we want a large NTFS partition that we can subsequently attempt to resize. After some time, the system had been wiped, repartitioned with one big Windows partition and Windows XP SP2 reinstalled.

Installing Debian Etch

I downloaded the latest Debian Etch installer from http://www.debian.org/devel/debian-installer/
and after burning the ISO image to a CD, rebooted our test PC with the CD in the drive.
There are various flavours of installer available from that page, I normally use the netinst CD image which contains a minimal set of software required to bootstrap the system – it then proceeds to download and install additional software from the Internet. Using this guarantees that you have the most current packages installed and is the best approach if you have a reasonable broadband connection to the system you are doing the installation on. The installation CD was booted using the default kernel (2.6.17-2-486) and no additional options.

Initial Install Steps

The initial steps of the install were the same as any standard installation, I selected language settings of English / Ireland, the keyboard layout was British English and the network settings were configured with an appropriate hostname and domain (the IP address for the system was automatically assigned by our DHCP server).

Partitioning

The following steps were followed when prompted for how to partition the system,

1. Manual partitioning.
2. Selected the primary partition on the primary disk – which was an NTFS partition spanning the entire disk as created by the HP Restore CD.
3. Selected Resize the partition (currently 80.0GB)
4. Set New partition size to 40.0 GB (I thought it was fairest to give each OS an equal share of the disk, I mean, 40GB should be enough for any OS, right?).
5. After a brief delay I was returned to the main partitioning screen which listed the following partitions

• partition #1 – primary, ntfs, 40GB
• free space of 40GB

I selected the free space and the option Automatically partition the free space and specified that I wanted separate /home, /usr, /var and /tmp partitions.

After a further brief delay, the partition manager created the following partitions,

• partition #2 – primary, ext3, 279.7 MB /
• partition #5 – logical, ext3, 5.0 GB /usr
• partition #6 – logical, ext3, 3.0 GB /var
• partition #7 – logical, swap, 2.9 GB
• partition #8 – logical, ext3, 403.0 MB /tmp
• partition #9 – logical, ext3, 28.4 GB /home

Selected Finish partitioning and Y to Write Changes to Disk.

Finishing the Installation

The installer wrote the changes to the partition table and proceeded to let me set a root password and create a non-root user for day to day use of the system. I opted to use a local Debian mirror in Ireland for the retrieval of additional packages and then proceeded to install the Desktop Environment and Standard System tasks. We have informally standardised on GNOME as our company Linux desktop environment and people seem to be generally happy with it. With Debian Etch, selecting those 2 tasks gives us a system which is generally suitable for our developers – I normally manually install a Sun JDK, the latest Eclipse and some Eclipse plugins to meet our development needs. Towards the end, the installer prompted on whether to install the GRUB bootloader indicating that it would also provide an option to boot the detected Windows XP Professional. I OK’ed this and rebooted to find a GRUB boot menu with options for both Debian and Windows.

I decide to boot first to Debian to make sure everything went ok – it automatically starts the GNOME Display Manager graphical login and logging in with the account setup earlier gives me a nice clean desktop – even sound was working out of the box. Overall, the Debian Etch installer is looking pretty solid at this stage.

I rebooted again and selected Windows this time. Windows XP performs a filesystem check during the boot process and then restarts the computer (no errors reported). Selected Windows XP Professional again at the boot menu and Windows booted all the way to the login^H^H^H^H^HWelcome screen without any further warnings. Logging in shows that everything seems to be working ok.

Conclusions
Partition Resizing in the Debian Installer works much better than it used to and seems to be good enough for daily use on production systems. I guess at some stage I should try a further resize of the Windows partition (up or down) to verify that works ok but I’m pretty happy with it now and the scenario I’ve just described is probably the norm for most people using partition resizing software. Thanks to the Debian Installer team for their work on this. Oh, and Merry Christmas to all!