This is the fourth time I've started a post for today, and the fifth time I've opened an editor and tried to start on a column for the weekend. Each time, I've deleted everything I've typed. You know what? Have a good weekend. I'm going to kick back here at MINERVA with a handfull of X10 modules, the latest revision of MisterHouse, emacs, and xmms. The column will be up sometime this weekend; when it's ready to come out, it's ready.

Thursday, May 17 - How Many Topics Could a Daynoter Chuck if a Daynoter Could Chuck Topics?

Let's start with... politics and freedom of speech / religion...

This is a SlashDot article (without comments) referring to an interesting court case. It seems the involved gentleman picketed a Scientology office, and contributed to a Usenet thread joking about the destruction of Scientology. The result, which is almost predictable considering who we're talking about here, is that the Church of Scientology brought charges, claiming that he had directly threatened them and interfered with their freedom of religion.

Now, let's be clear. Freedom of religion - or to use a broader and, in my opinion, more appropriate term, freedom of belief - is pretty damned important. Ranks right up there with, and is integral to, freedom of speech. So if you want to believe in the teachings of the Church of Scientology, be my guest. Have fun. If, on the other hand, you want to believe that the field mouse you found in your kitchen last week is the One True God - well, you also have my blessing.

On the other hand, I have the right to think and say that you're a fruitcake for either belief. And you, of course, have the right to say the same about me and my beliefs. Is it polite? No. Won't win you many friends, either. But we're not discussing Emily Post here. You have the right to do these things, and you have the right to protest actions by any group - provided you do so legally, without causing harm or damage or seriously interfering with the rights and activities of the protestee.

What concerns me is that the courts seem to have forgotten this concept. Ah well. Looks like Tom gets a new neighbor, one I'd much rather have than the "winners" of the case.

Bah. So goes the world these days. Who needed those silly ol' rights anyway...

Next, MINERVA is now stable. This is a two-part story... first, Keri decided this first experiment with Linux has gone on long enough, and it's time to go back to Windows for a bit. Not that she didn't like Linux - just that this first attack on the learning curve was not sufficient so long as she can only have one OS at a time. Which is fine and completely understandable. So we talked it over, and since Windows was already on THOTH the IBM Thinkpad, that's what she's using for now. ANYA is temporarily decommisioned for a week or two; as soon as the cash flow allows (around the end of the month, roughly) we'll go ahead and replace ANYA with a new machine similar, hardware-wise, to MINERVA. This allowed me to steal Keri's Voodoo3 video card for MINERVA, which solved the video problem. If I were to be so inclined, Mandrake also offered the option of making the box dual-headed; I didn't take the option, but I thought about it. If I had two Voodoo cards (or similar) I might think about it, but... nah. I'd have to use one of the old monitors, and although new ones are in the budget, I'm not buying three.

So MINERVA now has the following configuration:

• MSI VIA-KT133 based motherboard (Micro-ATX, 3 PCI slots, onboard Creative sound)
• 800 MHz Athlon Thunderbird processor
• 256 MB PC-133 RAM (128 MB of which are from ANYA... hey, the box isn't running, right??)
• 40 GB Maxtor ATA-100 IDE hard drive
• 10/100 Intel PCI network card
• 24x IDE CD-ROM Drive
• 2x Acer CD-RW (also from ANYA)

And she's running Mandrake 8.0 for the moment, and providing Samba shares for Keri of both file storage and printers. Which leads to my next topic...

Setting up Samba for a small home network.

Dan Bowman mentioned an interesting method of file sharing that he has set up on his network, and mentions in the process that a lot of the shortcuts Daynoters use might be simple to the individual member - but not to our readers or to other members. That's true enough, and I suppose I should do my part. Dan mentioned in passing that he didn't know about Samba, and since I just set that up last night, I figured I might as well list my steps in doing it.

Couple of caveats to remember; one, this is just my quickie method. It's not very secure. Don't even *think* about using this other than behind a firewall in a trusted environment; this isn't even the configuration I'd use in a small office. This is for home use, where you have a small file/print server with a few client systems and no punishment greater than a spanking will result from the user's breaking into the wrong part of the system. I offer no warranties, guarantees, refunds, or testimonials, your mileage may vary, use at your own risk, not valid in every state, etc. Also, this is the configuration I used in Mandrake 8.0, which is using Samba 2.07. (Samba-2.07-25mdk, to be exact, but let's not worry over trifles.)

There are only two files that you need to be concerned with; /etc/smb.conf and /etc/smbpasswd. Also, on your system find the init script that initializes the Samba server; in Mandrake, it's /etc/rc.d/init.d/smb, while in SuSE it's /etc/rc.d/smb. You'll also need to have your printers installed and running using CUPS (OK, you don't need to, but it's a heck of a lot easier that way.) All set? Let's roll.

Part One: /etc/smb.conf

Download the complete file from here

First, the general configuration...
1. workgroup = WORKGROUP

This just defines which workgroup your Windows machines are in.

2. server string = Server Name

This is just a description of the server; I use the server name, but it can be anything. Most home users will only have one server I suspect, but at any rate this allows you to set a description.

3. hosts allow = 192.168.1. 127.

This specifies which machines can connect to the Samba server. Set this to the address ranges used in your internal network; under no circumstances should you include any outside address. 127. specifies that the localhost (the server itself) is allowed to connect. Please note that this does NOT mean all of those machines are allowed to actually use the system shares; they still have to log in to gain access.

4. printcap name = lpstat
   load printers = yes
   printing = CUPS

This tells Samba to look at CUPS and set up the printers installed there as shared printers. One interesting possibility here is that you could have printers scattered across your network, connected to any number of machines - yet so long as they're in CUPS and accessable from the Samba server, your workstations will be able to print to all of them through the Samba server. In other words, you can have nested shared printers.

5. log file = /var/log/samba/log.%m
   max log size = 50

This will have Samba maintain a separate log file for each machine, with a maximum size of 50kb per file.

6. security = user
   encrypt passwords = yes
   smb password file = /etc/smbpasswd

This sets up the user authentication. User is the simplest (and best, IMO) authentication method; encrypted passwords are the standard for most Windows clients (certainly for Windows 98, ME, and 2000) and even those clients that don't encrypt passwords by default can be made to with a simple registry hack (available all over the web; search Google for "windows encrypt passwords" or "samba howto"). It also sets the location of the smbpasswd file; /etc/smbpasswd is the default, but there's no reason why you couldn't put it elsewhere if you like.

7. socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

This sets some basic TCP protocol values to improve performance. These settings are fine for a small network, and are the values used by the default Mandrake install.

8. os level = 33

This sets the precedence level for the server in Master browser elections. For a small home network (<10 clients) this is almost completely unimportant; 33 is a reasonable number to use even in larger installations.

9. dns proxy = no

This allows for client name resolution using DNS. I could technically use this on our home network, but I'm wierd; most home networks don't have that ability. Even those of us that do probably don't use it much in small networks.

And now, we set up the server shares themselves...

10. [homes]
      comment = User Storage
      public = no
      writable = yes

This creates private shares for each user who has an account on the server through their home directory. The share is defined by default, and you may find it useful even in a small network.

11. [sharename]
      comment = Shared Storage
      path = /path/to/directory
      public = yes
      browseable = yes
      writeable = yes

This is a basic shared-storage directory, accessable to every user listed in the smbpasswd file. Remember, though, that the files in this directory (so far as SMB clients are concerned) have no ownership or per-user file restrictions. If a file is in this directory, any authenticated user can see and modify it, or delete it. So back up early, back up often, and use private directories for critical items.

12. [printers]
      comment = All Printers
      path = /var/spool/samba
      browseable = yes
      writeable = no
      printable = yes
      create mode = 0700
      print command = lpr-cups -P %p -o raw %s -r
      lpq command = lpstat -o %p
      lprm command = cancel %p-%j

This creates shared printers for every print queue defined in CUPS. One thing to remember is that this configuration uses client-side printer drivers; that means you will have to install drivers on each client machine. Other than that, they'll look just like any other shared printer in a Windows network.

And that is all there is to that. Not too bad, huh? All we have left is to define the usernames and passwords, then restart the server.

Part Two: /etc/smbpasswd

This is really very simple. Just use the smbpasswd utility to create the encrypted user file, and your users will be all set. To create a new user, just type

smbpasswd -a username

as root. You'll be prompted for a password, and the /etc/smbpasswd file will have the user and password added to it. The first time you execute that command, it will complain that the smbpasswd file doesn't exist, but that's OK; it will create it for you. Add all the users you intend to use; more can be added at any time.

That's about it. All that remains is to restart the daemon. Under Mandrake, that's as simple as

/etc/rc.d/init.d/smb restart

as root. Other distributions will be similar.

And that will do it for now. I may be back tonight. Have a good one...

Tuesday, May 15 - Fun in the Sun... Pity it's Raining...

MINERVA is having teething problems. So I spent my evening working on that instead of writing a post.

I borrowed (yes, with permission) a decent monitor from work. Whereupon I discovered that I hadn't installed any resolutions for the graphics card higher than 800 x 600. Piffle. Well, I can fix that... oh, but I also didn't install Gnome... or the kernel source... or the Perl headers... geez, I really blew the mission on THAT install. OK, well, I could go through and add everything manually... or I could just take 20 minutes and reinstall Mandrake. All right, reinstall it is.

About 99% of the way through installing the operating system, MINERVA locked up. That was the first time I had even a hint of trouble, so with a small frown and a muttered "that's odd" I hit the reset switch and tried again. This time, the system installed fine. I set it to a resolution of 1280 x 1024 (my preferred working resolution) and, sure enough, the system came up fine.

And promptly locked up.

OK. Try this again, and this time just let it sit at the login prompt... it was fine for a few minutes, then it locked up.

My first assumption was a cooling problem. That's pretty much a "known bug" with Athlon processors; they run hot. But I had a very nice cooling fan on the chip (huge cooling stack and a large, high-rpm fan; supposedly rated by AMD as sufficient up to 1.3 GHz.) Just the right amount of conductive goop on the processor. And, most convincingly, the processor was warm to the touch - but by no means hot. Not only that, but I turned off all power and waited until the processor was stone cold (well, all right, room temperature) and then tried again - and it still locked up right after logging in.

Now, I would normally assume a hardware problem at this point - RAM, perhaps. But I woke up this morning with a completely different thought in mind. See, that system ran for a continuous 36 hours, minus only five minutes for a RAM swap while troubleshooting ANYA. In that time, the system did not crash nor overheat. In addition, the system boots fine - it only crashes AFTER loading the login screen. That is, after loading XFree86. I'll test this tonight, but I think what's happening is that the XServer for the S3 Savage has a bug in it at higher resolutions. It may be a problem with the generic server code, or it may be something specific to this implementation - but I think the problem is just that it can't handle the resolution I'm asking it to run at.

I'm going to test this theory tonight by booting to a text-only prompt and running several source-code compiles without X. (I want Perl 5.6.1 anyway.) If the system neither overheats nor crashes while it's doing that, then I'll reset X to run at 1024 x 768. If THAT doesn't work, then I'll install some other video card - I just flat can't work at 800 x 600.

I came home last night from work to find Keri demanding the return of her Windows. It seems KWord kept crashing, none of the installed email clients were to her liking, and in general life was ungood.

I, being a dutiful and loving husband, found all of this hilarious.

I think we're on the way to resolving all of her problems, though. With the exception of not being able to think of a way to give her "C: drive, D: drive, and so on" icons, I think we can deal with all of it. It's going to take a bit of time, but she's willing to take that time if I'm willing to teach her. So, we're making slow and steady progress.