And then…

In case you read my post, Email, the New “Sneakernet”, you might have been left wanting to know more about how to use Samba. There are plenty of sites and books dedicated to the topic, but here’s a quicky post on how to most easily use Samba.

To make your Linux, UNIX or Mac files available to Windows clients, do this:

1. Make sure you have a reasonably recent version of Samba on your Linux, UNIX or Mac machine. 3.x is generally good; 2.x is not.
2. Edit or create /etc/samba/smb.conf to look like this:

[global]
workgroup = WGNAME
netbios name = MYMACHINE

[SHARENAME]
path = /PATHTOSHARE
public = yes
guest ok = yes

Where WGNAME is whatever you want to use as your Windows “workgroup name”, MYMACHINE is your computer’s “netbios” (short, network) name — one that ideally matches your DNS name, SHARENAME is the public name of your “share” (for example, “BobsHomeDir”) and PATHTOSHARE is the file system path that you want to make available as that share (for example, “/home/bob”).

3. After creating or editing the /etc/samba/smb.conf file, you must start/restart the smbd daemon. Do this with:

/etc/init.d/smbd restart

(Note: Different versions of UNIX, Linux and Mac OS X do this differently).

4. To access the files shared in step 2, on your windows machine, type:

net use * \\MYMACHINE\SHARENAME

Replacing MYMACHINE and SHARENAME as needed.

Doing the reverse, accessing Windows files from Linux/UNIX/Mac is easier. You don’t need to configure anything or run any daemons:

1. As above, make sure you have a reasonably recent version of Samba.
2. Run the smbclient program from the command line. It’s arguments look like this:

smbclient -U DOMAIN\\username //WINCOMP/SHARENAME

Replace DOMAIN and username with the Active Directory short domain name and username of a user that has access to the computer whose files you’re trying to reach . Replace WINCOMP with the name of that computer. You can use its short, Netbios, name or its fully qualified DNS name (e.g. wfsshare or wfsshare.corp.mycompany.com). Replace SHARENAME with the name of the “share” on the Windows computer. Note the use of a double “backslash” when specifying the username and domain. When using the command line shell on Linux/UNIX/Mac, you typically need to type in two backslashes when you want one. The backslash is a special “escape” character and you need two of them to end up with just one. No kidding.

3. The smbclient program will prompt you for the password of the username that you specified. Type it in.
4. The program will display a prompt and wait for you to type a command. At this point, pretend you are in ftp. Use the ls command to list available files. Use cd to change remote directories. Use get to retrieve a file. mget is also useful because it supports wildcards. put and mput can be used to copy files from Linux/UNIX/Mac to Windows. Use bye to quit.

There is an alternative to using smbclient. You can use the “smb filesystem”. This approach lets you “mount” a Windows disk into the Linux/UNIX/Mac filesystem so that you can access its files like you would any local file. Here’s how you do that:

1. Create a “mount point” in your file system. This is where you want your Windows files to appear. On Linux, the media directory is often used for flash drives and other transient “disks”. You might want to use it for this purpose, too:

mkdir /media/fromwindows

(Replace fromwindows with whatever you want).

2. Use the mount or mount.cifs command to mount your Windows share to the mount point. I’d try the second form first:

mount.cifs //WINCOMP/SHARENAME /media/fromwindows -o user=USERNAME,password=PASSWORD

WINCOMP and SHARENAME are as used earlier. USERNAME and PASSWORD are the username and password of a user that has permissions to access the given Windows file share.

3. If your system complains that it doesn’t know mount.cifs try this instead:

mount -t cifs //WINCOMP/SHARENAME /media/fromwindows -o user=USERNAME,password=PASSWORD

If this doesn’t work, try substituting smbfs for cifs. If that doesn’t work, just email the damned files!

As you can read in my “About” page, I’ve been involved with computing for a long time. Although the industry has seen tremendous progress during that time, every once in a while, something comes along that makes me think it is still 1980.

In the early days of personal computing (about 25 ago), when IBM PCs and Apple IIs started appearing on corporate desktops but before “LANs” became commonplace, the term “sneakernet” was used to refer to communicating information by physically walking it over. You’d write out your WordPerfect file to a 5-1/4″ “floppy” (which actually was “floppy”) then stroll over to your intended recipient. Pretty simple.

Later, even this simple scenario was complicated by the advent of 720Kb, 1.4Mb and 2.8Mb 3.5″ floppies (no longer “floppy”) and differences between IBM and Apple formats. The Mac used a weird variable speed technique that the PC could not read.

Even when networks started showing up in office settings, sneakernet remained popular. Early networks required that file exchange be accomplished by writing the data to a “file server” and then having the recipient read it from the agreed location. Connecting to a file server required magic NetWare or LANMAN command-line incantations.

“Windows for Workgroups” and, later, Windows 95 made PC networking much easier. Meanwhile Apple had a very easy to use network based in AppleTalk, yet another example of Apple’s willingness/bias towards doing things their own way.

It did not take long for the industry to consolidate on standards. AppleTalk, like “token ring” and other competing protocols gave way to Ethernet. Netbios and IPX gave way to TCP/IP. For a while, file sharing was not too hard. Users could easily “share” folders or store things in their automatically shared Public folders and use these file file exchange. It was okay to wear dress shoes to work and leave the sneakers at home.

The arrival and broad adoption of the Internet introduced new challenges that reversed this trend. The Internet made possible the effective use of WANs (wide-area networks) and the connection of companies and company branches that were not normally connected in a private network. Sharing files through sneakernet, now, became impossible because sneakers would not get you from New York to Japan or Australia (at least, not without getting them wet). On the other hand, sharing files through simple operating system mechanisms also became (almost) impossible, mostly, due to security concerns.

Within their LANs, companies often have liberal policies regarding what type of network traffic is allowed to occur. File sharing protocols work within these corporations because the necessary TCP/IP ports are available and communication to/from these ports is permitted. Corporations typically separate their internal LANs from the external Internet by using firewalls. Firewalls are typically appliances (or dedicated computers running networking software) that control what type of information is allow to flow between the internal LAN and the external Ethernet. The TCP/IP ports required for file sharing are usually blocked by firewalls. No IT director wants random strangers on the Internet to be able to access computers in their corporate LANs and to read shared files.

The net result (no pun intended) is that sharing files across the Internet has gotten complicated again. Some companies will set up special FTP servers outside their firewalls. Others might use Internet “collaboration” web sites to facilitate file sharing. More often than not, I see people simply e-mailing files to each other. Crude but simple. The electronic equivalent of sneakernet.

Another thing that makes file sharing complicated even within a LAN is the use of different operating systems. Once again, Apple is involved here but, this time, it’s got plenty of company. Mac OS X is based on the FreeBSD operating system - a UNIX variant. Mac OS X has the same challenges that Linux and all flavors of UNIX (AIX, Solaris, HPUX) have. In order for these systems to “talk” to Microsoft systems, they have to do one of two things: they have to “look like” a Windows client to get data from a Windows server or they have to look like a Windows server so that Windows clients can get data from them. (FTP is, again, an option in LANs but a relatively painful one).

The Samba open source software can help with both of these. Samba, for example, provides the smbclient utility that allows UNIX systems to get data from Windows servers using an FTP-like interface (but without requiring the Windows servers to run any FTP software). Samba also provides the smbd service (daemon) that allows a UNIX computer to look like a Windows server so that it can be accessed by Windows clients.

Setting up a Samba server can be a difficult task, especially if you want it to be integrated with Microsoft Active Directory and to supports its user authentication features. There’s a great 700+ page book that describes how to do it. Nevertheless, there’s no better way to do this. If you’re willing to forego AD security, setting up Samba is a lot easier.

Beyond Samba, there’s also the “smb file system” smbfs and some commercial products to allow Linux and Mac OS X to act like a Windows client. Additionally, Apple and Linux vendors have begun to build such functionality into their standard graphical “shells”.

Perhaps, in another 25 years, we’ll have it all worked out.

Both Windows and UNIX (and Linux and Mac OS X) support some type of event log. The event log consists of a set of timestamped entries that document significant operating system or application activity. Events might be strictly informational (Successful logon for Joe) or might document errors (Unsuccessful logon for Joe or Out of disk space!)

As you might imagine, event logs are important. They let help system administrators in several ways:

• Problem diagnosis. When a computer is misbehaving, administrators can look at its event log to see if there are messages in it that provide clues to what’s broken.
• Security enforcement and intrusion detection. Event logs contain information that can be used to detect intrusion attempts and unauthorized access to protected resources.
• Auditing. Event logs contain information that helps administrators keep track of who is accessing what systems and what they’re doing while they’re there. This information can be used to satisfy security auditors that adequate practices are in place.

Although both UNIX and Windows have event logs, their mechanisms are very, very, different. The Windows event log consists of structured data with explicit fields for “Type”, “User”, “Computer”, “Category” and other fields. Windows provides an API that allows event logs to be read from local or remote computers. The API allows monitoring programs to securely access event information from Windows computers.

The UNIX event log is stored in text files. The syslog API is typically used to write to the event log text files but syslog does not support remote access of UNIX event logs. Although syslog provides for a facility code and a priority field in its API, the data actually stored in the text files is mostly unstructured.

Both mechanisms have their problems.

Although syslog data is unstructured, it is in a great form for full-text search. There are good log file analysis programs (for example, Splunk) that do a good job of searching through syslog files for well known patterns. Windows data is structured and in a much better form to be formally searched “by field” but it is less amenable to full-text searching.

The Windows event log offers the advantage of a remote API and structured data, but doesn’t provide a good mechanism for event log storage. With syslog, you can set up a syslog server that collects data from other machines that have been configured to send their logs to that server. The syslog server, then, creates a consolidated log file that contains information from multiple computers. Performing full-text searches on this file is even more useful. The Windows event log does not have this functionality. True, you can run Microsoft “MOM” (Systems Center Operations Manager) and accomplish this but only at great cost (money, time).

As weird as it sounds, some Windows sites run a program called Snare whose Windows version takes structured event log data, “flattens it”, and sends it to a central syslog server allowing it to be stored and analyzed using the same tools used for UNIX.

If the syslog server functionality is sounding cool to you, keep in mind that the standard syslog daemon only communicates to syslog servers using UDP protocol. UDP is unreliable so you can lose (important event) data. The data sent over UDP is also sent in clear text format so anyone can “sniff” the network and analyze it. The syslog server offers no security mechanism to control who can write to it. A rogue machine could spam it or could effect a denial-of-service-attack by flooding its incoming UDP socket.

There are newer versions of syslog, syslog-ng (next generation), for example, that overcome some of these limitations. syslog-ng, for example, can communicate to a syslog server using TCP instead of UDP. There are ways of hacking stunnel into the process to allow data to be SSL encrypted. The overall architecture, however, remains clunky and fragile.

Wouldn’t it be great if some clever company could offer a better solution?