Debbie developed a split personality! But she's better now.

After neglecting my Linux Home Server project for over 2 weeks I've had some time to work on her. Sometime before then, I managed to screwup the smb.conf file and disabled Samba sharing such that Windows XP could not connect successfully to Debbie. Debbie however worked extremely well as a SMB client of whatever Windows server I pointed her at! Attempting to log on from a Windows client onto Debbie however was another issue. I could get the log-on dialog form repeatably but not a complete transaction. Fixing that took a little time. (see below for a sample smb.conf file.)

Connections are now automatic onto Debbie from all Windows OS boxes, mainly by implementing a log-on/drive mapping script run on each user log on. This duplicates the functionality of the "WHS Client Connector" used by Kraken (Release Candidate 1 of Windows Home Server). All of the log-ons on the Microsoft system need to be "replicated" or basically copied onto the Samba server. That means the User name and its password used to log onto on the Windows system needs to be copied into the configuration of the Samba server. I would heartily suggest that these accounts be only USER accounts on the Windows systems. You don't have any business using an Admin account to access movies or media files on an external server system, Linux or Windows! I do not worry about the security issues of the Debian system but Windows systems have demonstrated many times their vulnerability to "man-in-the-middle" attacks.

Overall, I will be depending on a hardware firewall based on a Linux distribution that basically shuts down ALL Netbios (and a lot of other ) interaction with the outside Internet. I will not be putting Debbie directly on the Internet. She'll be working through the firewall like all of the other systems on my home network. The difference will be that she'll have a NIC in the DMZ and another on the local network. Routing between the NIC ports will be heavily controlled.

Here's how to do the auto-log on on the Windows clients. This line below is saved as a Windows (MSDOS) batch file saved as ANSI or UTF-8. Notepad (not as extensive as gedit) works fine.

net use x: \\192.168.99.30\serverclientsshare password /user:username /persistent:yes

This assumes your Samba equipped server is located at 192.168.99.30 with the share named "serverclientsshare". Don't type , just press enter. The password and username are the password and user name of the Windows AND the Samba account. This is one of those areas where I've run into some confusion. If the Linux account username and password do not match the Windows username and password, the logon on the Samba server usually fails. You can't operate in a mode that is essentially "log-on-Samba-as- another-username". This might be a "feature" of one of the myriad post-Service Pack 2 quick-fix patches from Microsoft, I do not know for certain. I have been keeping the WinXP Pro system up to date using Microsoft/Windows Update, especially since it seems as if support for XP is soon to stop. One of the fixes might have broken using user name aliases.

Then the complete path to the batch file location, as a string, is placed in the Run key in the HK_Current_User.

Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run] "LinuxShareLogon"="C:\\Documents and Settings\\username\\batchfilename.bat"

Shown here as the complete text for a sample.REG file. Double left click on it in Explorer and answer yes twice. There you go, you've just installed a Trojan! No not really. The keyname listed on the left (LinuxShareLogon) makes absolutely no difference, it just can't be "" (a null string or a space). Its the path listing on the right side of the equation as the value that is important. You may already have other programs set to run in the Run key, just add this one to the list.

Or you can add it using a shortcut to the batch file in the Start folder in: C:\Documents and Settings\username\Start Menu\Programs\Startup

Either of these two methods will enable an automatic log-on to the Linux based Samba share. If you want to enable the same drive mapping (x:, substitute any drive letter for x) for ALL users on the Windows computer, substitute All Users for username in the above listed path. I do not suggest it except on Windows systems used only to access the Samba shares. This mapping will override whatever user mappings for that particular drive letter that have been previously set so be careful! The persistent setting may generate an error message on subsequent log ons but will be ignored. This will allow the system to reconnect automatically on the next Windows system boot-up or user log on regardless of the user mistakenly deleting the drive mapping.

For those of you that know about WINS or Netbios browsing groups, you may wonder why I used an IP address to address or name the computer in the command line above. Windows simply connects twice or three times as fast when it doesn't have to do a lookup in a WINS server or Netbios listing. In the system design model I am using, Debbie is going to eventually be a PDC (or Primary Domain Controller in Windows nomenclature) and will be running DHCP, DNS caching services and WINS, so it needs a fixed IP to remain consistent for all the Windows client applications (most of them!) that don't like moving DHCP targets.

Files and Folders security and access settings are part of the NFS and Samba settings used on the Debian folders setup as shares. All users and at least one group they are a member of must have at least read access to the folders both under the Debian file system settings and under the Samba configuration file settings in smb.conf. The settings likewise must be consistent. The service with the least level of access rules. In other words Samba access set to write doesn't over-ride the Linux access of read-only, or vice versa. This might be a feature of Linux SE, I'm not sure. I do remember it working differently with Samba 1.

There are nuances in the Linux and Samba security models I still haven't completely mastered yet. I do know that essentially all users on the Windows systems accessing the LHS must have valid user accounts on the Debian system before any of the Samba implemented shares will work properly. The computers the users are logged onto, likewise are required to either have a Machine account or a listing in the permitted systems sections of smb.conf. In addition, there is a Debian-Samba system update cycle issue that limits the number of system privileges, shares access and user group permissions that can be changed at any given time. Using SWAT and then looking at the smb.conf file settings is not guaranteed to give you the total picture of what is going to happen the next time on boot-up of the Debian system. I do not blame Samba or Debian but my own understanding of what items take priority over others in the smb.conf file and how SWAT makes things work.

Here below is a sample smb.conf that works reliably on Debbie. There is actually nothing here that is unusual. serverclients is the name of the general public folder and the user group that has access to LHS. All users having access to the LHS must be a member of serverclients the group. I've set the folder up to be shared as a Samba and a NFS share with the same more or less open permissions. Although the user interfaces and the OS are different, the folder is easily accessible by both types of client. Later I plan on tightening up write permissions so that users can write to their own folder and read all others under serverclients. I also would like to set up the user account routines so that as users are added, they get a public folder and a private folder under their username folder automatically.

I've set the announce level and the OS level to 33 to prevent any Master Browser server battles. WINS server is enabled on Debbie. This level and server setting should guarantee that the LHS is always the Master Browser. 33 is also the recommended setting for a Samba server set-up as PDC. This smb.conf is still set for stand-alone server settings with the exception of the OS level setting. Mangling method has been left blank and will eventually be set to whatever level I can manage to include all the Windows clients I have that will need to access the server. As may not be obvious, Microsoft calls it the "encryption" level and it relates to the security model used in LanManager(NTLMv1 & 2) and later methods of security on user passwords. Mangling method is an all too apt jab at MS for their "encryption techniques".

# Samba config file created using SWAT # from 127.0.0.1 (127.0.0.1) # Date: 2007/08/02 16:56:05

[global] workgroup = Homenet server string = Debbie auth methods = sam announce version = 33 client signing = No client use spnego = No mangling method = os level = 33 wins server = 192.168.99.30 ldap ssl = no username = xwindowsjunkie valid users = xwindowsjunkie, user1, user2, @serverclients write list = xwindowsjunkie, user1, user2, @serverclients hosts allow = 192.168.99.0/255.255.255.0 wins support = yes

[xwindowsjunkie] comment = this is a folder inside /home on debbie for a Linux client but also shared as an SMB client path = /home/xwindowsjunkie read only = No max connections = 25 available = yes browseable = yes public = no writable = yes [serverclients] comment = this is a folder inside /home on debbie path = /home/serverclients read only = No browseable = yes available = yes public = yes writable = yes [user1] comment = this is a private folder path = /home/serverclients/user1 read only = No browseable = yes available = yes public = no writable = yes

In Debian's Shared Folder applet, I've set the Samba share for the folder /home/serverclients as listed above in the smb.conf. The same folder is also set as a NFS share and its acl (Access Control List) state is saved in the file /etc/exports and gets listed as /home/serverclients 192.168.99.0/255.255.255.0(rw). The acl setting is exactly the same as a Windows group serverclients would get in an NTLM type group as folder owners. Remember that Debian Linux requires the Samba clients have valid Linux accounts in a valid Linux usergroup to have access to the Samba share.

If you are a Windows IT guru in a one-man IT department with no budget and you need a reason to learn Linux, Samba is the reason, especially Samba-3. It is by far the most impressive application to promote interoperability between Linux and Windows systems. It has in my opinion done more to make heterogeneous network installations work than any other piece of software ever written, period. It bridges the gap between Windows workgroups and NT domains and Linux in so many easy ways. It has a scalability that allows for graduated incremental steps from workgroup to full Domain. It is worth the price of learning Linux to use Samba to get around the high price tag of Windows Server products and the high-priced hardware needed to run them, especially with Windows Vista.

One manual that I have scanned at least most of it and read deeply perhaps 25% of is: The Official Samba-3 HowTo and Reference Guide, ISBN 0-13-188222-8. It is also available for free by access by download. My rating: Excellent! Extremely clear explanations. The authors' goals were to promote understanding, not arcane jargon, an attitude often hard to find in software manuals. If you are conversant in Windows NT 4.0 and Windows 2K products, this manual is what you need to configure practically any Linux server from any distro to take over generic file and print serving functions, network protocol server functions, and operate as either primary or backup domain server for a "large" domain workgroup in a small office environment. Although Samba/Linux is often associated with these older NT network servers, it can keep up certainly with a Small Business Server 2003 situation without the freaking large price tag and still do it on hardware of P2/P3/P4 vintage. If you decide to use Samba, you will want to go buy a copy and keep it within arm's reach while you work on and learn Linux server functions.

At one point a few years back I used a license I had for NT 4.0 Server on a P1 system because I wanted a full server with DNS, DHCP servers etc. for use at home. Partially it was for my own education while I did my certifications but also because at the time the idea of a central server to hold my family's files was attractive for the idea of maintaining current backups. Samba3 running on Linux now can not only replace the Windows server Control Panel "applets" and backup functions but also function as a full primary server for user logons etc. It will completely replace NT 4.0 Server in a NTLM domain. With Kerberos and LDAP Linux applications, it can completely replace a Win2K or Win2K3 server as well with the exception of Active Domains. In a small office environment, Active Domains is massive overkill and isn't worth the effort. What this means in the realm of Kraken (a Win2K3 Small Business Server cropped down to Windows Home Server RC1) is that with Debbie (a Debian 4.0 server running Samba3) I can serve files to Linux, Windows Vista, XP, NT, CE, ME, 9X and even WFW 3.11 clients! Kraken can only serve to XP and Vista clients!

Apache2 is my next target of investigation. Apache so far has demonstrated absolutely no issues. Perhaps because I really haven't done anything with it yet! What I have experienced with Apache2 and Samba so far seems as if both projects are being written in the same style, by the same groups of programmers. Both groups are obviously pros and they have dedicated pros writing the documentation. That makes the software they release a joy to use.

Web pages will be the standard User interface to Debbie, the LHS. I haven't done it yet but swat looks like a model to follow for at least a beginning control system for the LHS server. Yes I know. I'm breaking one of my own rules, I'm going to write programs. I think my disease is terminal now. I just spent the last 3 weeks writing and debugging batch files and VB scripts to automatically install application software from a remote Windows server for work. The hardest part was making them "stupid-operator-proof". HTML and javascripts seem trivial in comparison.

It looks as if I will be able to write VB Script or Javascript loaded static pages that are served up by Apache2 on Debbie and actually executed on the Windows clients. These pages will most likely need to be accessed by IE 6 or 7 and I'll need to fiddle the security settings on the Windows clients to allow them to execute on the clients. Dropping shortcuts onto Windows desktops look to be the easiest way to get the embedded script pages "installed" on the Windows clients. Browser functions to open, save and view files are the activities most likely to be the ones needed at the start. That should work on the Linux ones as well.

I'm still interested in adding news website RSS feeds into some kind of a master news server. A long time ago BG (Before Google), I had a spider package that would scan websites for specific info (damn I should have filed a patent!) by using keywords. I could be doing that to incoming RSS feeds. I might not even have to write any software, somebody has probably already written it!

I've had no time yet to look into why Bacula doesn't work on Debbie. Having already exposed my aversion to SQL Servers of every flavor, I'm going to put it off as long as I can and avoid messing with it until I have to, probably with Bacula. If I soon can't get Bacula to work I'll find a replacement for it.

Since I'm using what probably ought to be called junk to implement my media server, I'm still of the opinion that I'll put the TV tuner board and the DVR functions on a separate computer. I have an old 1.8 GHz P4 Intel board based on a 423 pin CPU with 512 MB of RAM that probably could run as a TV/DVR streaming server. Its hard to justify the cost of new CPU hardware ($500+) to replace a $150 DVD recorder/player. Using a separate system gives me the option to run it first as a Windows system to verify that all of the boards, the CPU, RAM etc all work without dragging out the process. My skill-set as a Windows system guru is still much stronger than my Linux newbie side. Hey Yoda backoff! I'm still trying to find my balance in the Force!