dawgiestyle

01/23/05: Fetchmail For Easier Desktop Administration

My latest project at work involves the use of MS Exchange with the pop3 connector to retrieve mail from external mailboxes. This made me want to try out Fetchmail, which does exactly that. Of course, my home mail server of choice is Qmail, not Exchange.

I'm sure there are many people like myself who have 5 or 6 seperate email accounts set up in their preferred mail client. While this is no big deal, it can be quite a hassle to remember/re-enter all the account information after a fresh desktop install. Wouldn't it be much easier to set up one account that includes mail from all others? A simple use of message filters can then seperate the mail as it arrives.

So I went once again to the trusty FreeBSD ports collection on my fileserver and installed the Fetchmail port. A quick scan through the man page was all I needed to find the syntax for my ~/.fetchmailrc file. I opted to set up a cron job to poll the pop3 servers every 5 minutes rather than use daemon mode. My reason for this being that there may potentially be other people in the household using my fetchmail system who have no *nix experience. My understanding of the man page is that each user needs to have their own Fetchmail daemon process running, and I'm not quite sure how to achieve that (I am open to suggestions). Anyway, I thought it would be easy enough to add a cron job for anybody using the system, and it seems to be working ok so far.

Now, the next time I set up my mail client, I only have to set up my local server pop3 account and it will get all my other mail to me. Setting up a few message filters can be much easier than remembering passwords I rarely use.

Another advantage of this setup is if my internet access goes down sometime in the middle of the night for any length of time, I know that I have recieved all email up to about 5 minutes before it went down.

I really should start looking at disk redundancy for that server.

12/17/04: Vulnerabilities in Cisco, Veritas, and Samba

Holes Found in Cisco, Veritas, Samba Products By Wayne Rash -- Thursday was a big day for vulnerability announcements, but not necessarily for big vulnerabilities. Cisco on Thursday announced two problems with its products, one of which had the potential to be serious. A potentially serious problem with Samba appeared on Bugtraq, and Veritas reported a problem with Backup Exec versions 8 and 9. None of the problems should cause trouble for companies with good security practices.

I got worried when I saw Veritas and Samba in the title :) Here's a tip: do not dismiss vulnerabilities because they can only be exploited locally. Many boxes running Samba may not necessarily be used directly by many people, but usually there are at least a few user accounts that could ssh in if they were so inclined. Locally does not mean sitting at the machine, it means from a user account, whether that user is logged in at the console or via ssh/telnet.

12/15/04: Free VPN over SSL

Meet OpenVPN By Hans-Cees Speel -- If your company has people on the road, such as sales or technical people, a VPN is a good method for letting them access data on the company network. Many different VPN solutions can be bought, but many are free. Here, I discuss only solutions you can set up without buying a commercial VPN product.

VPN is my latest stumbling block. I have mostly been experimenting with Smoothwall Express and OpenBSD but with no success. From what I gather, there is a very good chance that everything is done right on the server end, but its the native windows client that is giving me trouble. OpenVPN is a little encouraging, and this article is definitely a keeper to help with experimenting, but I still lack a solution for networks with a VPN router already in place as I am not sure if they will do VPN Pass-through. On the other hand, I suspect that this may be a non-issue since OpenVPN uses SSL tunnels. I will post my findings on this as soon as I get time to create a test environment.

12/12/04: FreeBSD RAID

Implementing Hardware RAID on FreeBSD by Dan Langille -- Want better performance, higher reliability, and better recovery possibilities from your disks? Try RAID. Dan Langille recently made the switch to hardware RAID on his FreeBSD box; here's how he did it.

When I read this article, it struck me as something I would wish I saved, so hear it is :) The author mentions buying his drives at OEM Express, which is cool because I do my shopping in the Edmonton location. Over the past little while, I've been thinking about replacing my Slackware file/authentication server with FreeBSD. To be clear, I absolutely love Slackware for being what it is and nothing else. Unfortunately, what it is is not extremely well suited to my current setup. If you read my Linux and Windows Interoperability post, you know that I use LDAP authentication on my network. Usually, with other Linux distributions and FreeBSD, this is achieved through the use of PAM, or Pluggable Authentication Modules. Slackware, however, does not support PAM because of its past security vulnerabilities. Slackware being the server in my setup, it is manageable, but authentication only half works for users that exist only in the LDAP directory. In many many cases, PAM is completely unnecessary, and in those cases I will continue to use Slackware over anything else. Here at home, on the other hand, FreeBSD will be a worthy replacement just as soon as I come up with a plan for a swift replacement and the time to carry it out.

12/05/04: Linux and Windows Interoperability

As long as I have been using Linux, I have been striving for seamless interoperability between my Linux and Windows experiences. It hasn't been easy, but over time - with enough tinkering - I have arrived at a very finely tuned setup that provides full functionality in both environments.

The big requirement for all of this is a Linux server, along with a Linux/Windows desktop. LDAP authentication is key for true consistency. With it, we have only one source for accounts and passwords. The passwd/shadow files are still used for root and system accounts on the Linux side, but all user accounts exist only in the LDAP directory. I use OpenLDAP for this task. This Howto was helpful.

Samba is also key. My Samba server is set up as a domain controller, using LDAP authentication. This is what makes the Windows client use the same LDAP directory as the Linux client. All of this took some digging around in the Samba Howto Collection. My smb.conf is attached to this post.

I also use smbldap-tools to act as an interface between Samba and OpenLDAP. This set of tools includes useradd, passwd, etc. scripts that act on the LDAP directory.

Obviously this isn't a step-by-step howto, but merely a guideline. Besides, I honestly don't remember exactly how I did all of this :) The hope is that it will be much easier for somebody else if they know where to look.

Moving on, the main setup now being in place, I looked to the system policy editing. As you may know, Samba does not use Windows 2000 style group policies, but rather the older NT4 style system policies. This type of policy has its drawbacks such as registry tattooing (where a policy is enforced until another policy specifies otherwise), but for our purposes it will do just fine. The only policy setting I use is a folder redirection of My Documents to serverusernameDocuments so that I have a Documents directory right in my Linux home directory.

The system policy editor is not included with Windows XP, but one simply has to download a Windows 2000 service pack, extract it with the /x switch, and install it from there. The policy templates file I use is attached to this post.

The latest addition to my setup is the Mozilla Thunderbird email client. With just a little tinkering I was able to configure it to use the same directory in both Linux and Windows (it uses the directory in my linux home dir).

Again, this is nowhere near a complete howto. I have neither the patience nor the experience to take on such a task. Keep in mind that this whole setup took months of playing around to achieve, only because I was starting with a blank slate. If I were to very simply trace my footsteps, it would look something like this: Install Samba (manually map home dir) -> setup domain controller with tdb backend (map via logon script) -> system policy -> LDAP authentication (linux) -> convert Samba to LDAP with the help of smbldap-tools -> Thunderbird.

I would be happy to offer any help I can if anybody tackles this and gets stuck at some point. Perhaps if I go through the steps with others enough times, a full howto may not be out of the question afterall.

Good luck!

My Samba config file Poledit Template

11/28/04: NFS Performance on Suse 9.1

NFS performance is talked about on quite a large number of sites, but as I have just found out, Google cannot always solve one's problems. I got a lot of results where people were talking about terrible NFS write performance, which is what I was experiencing, but most of them either went unanswered or were solved by adjusting rsize and wsize mount options. I tried playing with these settings even though I knew they were fine. I was using the same mount options that I used with Gentoo and Slackware on my desktop with great performance. It was only after installing Suse 9.1 that I noticed a nasty slowdown in NFS write performance. 3MB/s on a 100Mbit lan.

I actually really like Suse, so I began desperately trying to find a solution, because if I could not find one I knew I would have to change desktop OSs yet again.

My fileserver is a Slackware 10 box with 2 NICs bonded into 1 interface, which I had done around the same time I installed Suse, so I reversed those changes, and still no luck.

There were other things I changed (kernels on server and desktop) but I won't go into them. Finally, as a last resort, I noticed "nfsvers=2" on the end of my mount options and changed it to "nfsvers=3" and bam, 8-9MB/s writes. This was about 5 minutes ago so I'm still ecstatic.

So I had to post this in case others are banging their heads against walls about it as I have been doing for a couple weeks now. I love solving problems, but its very annoying knowing that it was right in front of me the whole time. Though situations like these do wonders for troubleshooting skills :)

11/23/04: More Secure Remote Access Options

Citrix to Acquire SSL VPN Provider by Dennis Fisher -- Citrix Systems Inc. on Tuesday announced that it is acquiring a small SSL (Secure Sockets Layer) VPN provider, a move that company officials hope will position Citrix as a major player in the remote-access market.

The purchase of Net6 Inc. for $50 million puts Citrix smack in the middle of a rapidly expanding and fiercely competitive portion of the security market. --

Thanks to things like SSL, remote access is much less of a double-edged sword today than it was not so long ago. It saves an enormous amount of time for anybody who administers servers in more than one location, as I do. Precautions must be taken, however, to ensure that what is convenient for the admin is not a cakewalk for the cracker that wants access to your network. Competition in secure remote access is good news for everyone.