Thursday, June 01, 2006

New ATI drivers for Linux

yamla writes "ATI has finally released new Linux drivers that claim support for the Radeon and Radeon Mobility 1x00 graphics cards, more than six months after releasing the chips. Read the release notes here. Any reviews are welcome."
New Product Support

Radeon X1900 series
Radeon X1800 series
Radeon X1600 series
Radeon X1300 series
Mobility Radeon X1800
Mobility Radeon X1600
Mobility Radeon X1400
Mobility Radeon X1300

Resolved Issues

Quake 3: Texture corruption is no longer noticed when playing the game on systems containing an ATI Radeon® 8x00, Radeon® 9000, Radeon® 9100, Radeon® 9200, or Radeon® 9250 product
The ATI Installer no longer inconsistently backs up and recovers existing XF86 and Xorg config files.
The ATI Uninstaller /usr/share/fglrx/, can now be executed from any path

Build Spam Filter for Linux

1. Build bare-bones Linux server
a. Custom Configurations
b. Partitions
c. Firewall Option
d. Package Selection
e. LANG variable

2. Install Postfix Message Transfer Agent (MTA)
a. Disable sendmail
b. Install Postfix
c. Configure Postfix
d. Test Postfix
e. Configure for mail forwarding
f. Test again

3. Install Mailscanner
a. Install MailScanner Package
b. Initial MailScanner Configuration

4. Install Spamassassin
a. Install SpamAssassin
b. Configure SpamAssassin

5. Install ClamAV
a. Install ClamAV
b. Configure ClamAV
c. Test ClamAV
Step I - Build Bare-Bones Linux Server
I've used some of the fairly recent versions of RedHat Linux. Versions 8, 9 or Fedora should work fine. I choose the custom build using the GUI installer.

a. Custom User Configurations
Select the generic selections for keyboard, language and timezone.

b. Partitions
You should partition the server with at least this layout: / /usr /varThis will protect your server from runaway log files.

c. Firewall Configuration
I chose to select the "no firewall" option. I consider this device to be a traffic management device and not a security device. Upstream security should be handeld by an actual firewall. Of course, many may disagree with this and choose to load IPTables. Just make sure you have the right chains configured to allow traffic to flow properly.

d. Package Selection
When you get to the package selections, DE-SELECT EVERYTHING. Go back and choose only the following items:

Editors -> you'll need this to vi files
Development Tools -> you'll need this to compile software

Once the machine builds itself, it will reboot.

e. Fix LANG Variable
Once it reboots, we need to edit the LANG variable. RedHat's LANG variable setting of LANG="en_US.UTF-8" can cause compilation errors in some perl code used by MailScanner and SpamAssassin.

In Red Hat Linux you must edit the file /etc/sysconfig/i18n to change the lines:
LANG="en_US.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en" To: LANG="en_US" SUPPORTED="en_US.UTF-8:en_US:en"You then need to re-set and export the LANG variable: [root@titan sysconfig]# LANG='en_US' [root@titan sysconfig]# export LANGStep II - Install Postfix
I chose to use postifx instead of sendmail for my MTA. I like postfix because its configuration is very understandable. Also, I believe it is a bit more lightweight than sendmail.

a. Disable existing Sendmail services
Before you install postfix, you need to disable the existing sendmail items running on your Linux box. Service sendmail stop chkconfig sendmail offb. Install Postfix
Download postfix 2.1.5 from and install as per this postfix document. Make sure you add the required records in passwd, group and aliases files. Postfix and Mailscanner will not work without them!

Accept all of the default settings when you "make install"

c. Configure Postfix
Postifx has two files which control most of its functionality. These are and

Specific edits: myhostname = mydomain = myorgin = $mydomain inet_interfaces = all mydestination = $myhostname, localhost.$mydomain $mydomain mynetwork_style = hostNote: some of these items need to be changed, while some only need to be uncommented.

d. Test Postfix Build
It is very importiant to test postfix now to make sure everything works.

Send an email to this mail server. You can telnet on port 25 to this box and manually send an email.

e. Configure Postfix to forward email
Since we do not want this device to be the final destination for our mail, we need to configure Postfix to forward all mail for our domain to our SMTP mail server. We need to make sure that only mail for our domain is forwarded, and mail for other domains is dropped (do not become a open mail relay - very bad!)

Edit this item in relay_domains = lab.netThis tells Postfix which domains it should relay mail. All mail destined for this doamin (and only this domain) will be forwarded to its remote SMTP server. You can put multiple domains here, just seperate them with a comma or whitespace.

Add line to end of transport_maps = hash:/etc/postfix/transportThis tells Postfix what method to use to resolve the destination address for relayed mail:

Add line to end of "/etc/postfix/transport" smtp:[]This command specifically maps the domain "" to the IP address and tells Postfix to use SMTP as the transport. All mail destined for which is relayed thru this Spam Gateway will be forwarded via SMTP to

Then run command: postmap /etc/postfix/transportThis command builds the hash table/file which Posfix will use to forward mail. If you don't do this, it wont work.

Finally add this line to append_at_myorigin = noThese lines will make sure your Spam Gateway does not add any of its own header domain info to the mail as it passes thru.

f. Test Again
Stop and start postfix to make sure all changes take. postfix stop postfix startI know this is redundent, but you really should test your system again before installing MailScanner. Make sure that mail gets passed thru the system wihtout problem. If you do encounter a problem, it will be alot easier to fix it now than after you've installed MailScanner, SpamAssassin and ClamAV.
Step III - Install MailScanner

a. Install MailScanner
MailScanner installation is very easy to install. Just download the package from I use the version for RedHat/Mandrake.

Place the tar file in you directory of choice then run: tar zxvf MailScanner-.tar.gzRun the install script: ./install.shUse chkconfig to make sure MailScanner is set for the proper run levels. chkconfig --list | grep MailScannerYou should see: MailScanner 0:off 1:off 2:on 3:on 4:on 5:on 6:offAlso, you'll need to disable postfix via chkconfig. MailScanner starts postfix itself. chkconfig postfix offb. Configure MailScanner Settings

Updates to postfix's by adding this line: header_checks = regexp:/etc/postfix/header_checks In the file /etc/postfix/header_checks add this line: /^Received:/ HOLDHere are the edits to Mailscanner - place / update in /etc/MailScanner/MailScanner.conf Run As User = postfix Run As Group = postfix Incoming Queue Dir = /var/spool/postfix/hold Outgoing Queue Dir = /var/spool/postfix/incoming MTA = postfixHere's some file permissions changes you'll need to make: chown postfix.postfix /var/spool/MailScanner/incoming chown postfix.postfix /var/spool/MailScanner/quarantineIts a good idea to test the server now. Send a message to the remote server and see if it goes thru. It should, and then you can move to installing SpamAssassin.
Step IV - SpamAssassin
a. Install SpamAssassin
SpamAssassin is also very easy to install, however, you need to make sure you have the proper PERL modules installed. They are: Digest::SHA1 HTML::ParserOptional Modules: MIME::Base64 DB_File Net::DNS Mail::SPF::Query Time::HiResYou can install SpamAssassin with: perl -MCPAN -e 'install Mail::SpamAssassinThen install Net::DNSb. Configure SpamAssassin
You don't need to edit any of the SpamAssassin conf files because all of the configuration is done thru MailScanner.

In /etc/MailScanner/MailScanner.conf we will make these changes:
Change this line: Use SpamAssassin = noto: Use SpamAssassin = yesUpdate the SpamAssassin User State Dir setting: SpamAssassin User State Dir = /var/spool/MailScanner/spamassassinand then run commands: mkdir /var/spool/MailScanner/spamassassin chown postfix.postfix /var/spool/MailScanner/spamassassinRestart MailScanner to make changes stick. service MailScanner restartStep V - ClamAV
a. Install ClamAV
Before you install ClamAV, you need to add the clamav user and group. You can do this as follows: groupadd clamav useradd -g clamav -s /bin/false -c "Clam AntiVirus" clamavOnce this is done, you can build the software.
Open up the package: tar xvzf clamav-0.80.tar.gzGeneric build proceedure: ./configure makeI encountered a problem with my RedHat Fedora Core 3 build which was fixed by using this command "ln -s /usr/lib/ /usr/lib/". See this web page for details: "" make installNow you need to load the perl modules for the ClamAV perl -MCPAN -e shell install Parse::RecDescent install Inline install Mail::ClamAV b. Configure ClamAV and MailScanner Settings
In /usr/local/etc/clamd.conf make the following edits:

Add '#' in front of the word 'Example'

Do the same in /usr/local/etc/freshclam.conf

Now you need to update ClamAV's virus signature files [root@titus]# freshclam ClamAV update process started at Sat Jan 29 19:43:51 2005 main.cvd is up to date (version: 29, sigs: 29086, f-level: 3, builder: tomek) daily.cvd is up to date (version: 691, sigs: 804, f-level: 4, builder: ccordes)Update MailScanner's configuration file to use ClamAV 'Virus Scanners = clamav'In MailScanner.conf, check the setting of 'Monitors for ClamAV Updates' to ensure it matches the location of your ClamAV virus database files. This should be "/usr/local/share/clamav/*.cvd".

Windows Vista vs Linux servers

Windows vs. LinuxThis article will not attempt to advocate the use of Linux over Windows or vice versa. I will try to present the differences and similarities between Linux and Windows in a fair manner.
Both Linux and Windows (2000, NT, XP, Vista) are operating systems. Linux was inspired from Unix, while Windows was inspired from VMS.

While no single company "owns" Linux, Windows is owned by Microsoft. Various distributions (often referred to as "distros") of Linux come from different companies (e.g. Red Hat, Novell SuSE, Mandrake etc.), while all Windows flavors (95, 98, 2000, XP, Vista) come from Microsoft.

Both Linux and Windows come in Desktop and Server editions.

As far as cost is concerned, Linux is very cheap or free. I used the word "very cheap" for enterprise users. While anybody can download, install and use Linux, the distribution companies usually charge for technical support. Windows is expensive. You first pay for the copy of the software and then again for the technical support if you ever want it. There is another catch though; Windows enforces you to use a single copy on a single computer. This is not the case with Linux though, once you purchase Linux, you can run it on an unlimited number of computers.

Both Windows and Linux are GUI based operating systems. I'm afraid but, Windows has better GUI than Linux and it will get far better with the upcoming Windows Vista release. Linux has two GUIs: Gnome and KDE. Linux is fast catching up and is evolving from a server operating system to a desktop operating system.

Command Line:
Both Windows and Linux comes with command line interface. Windows calls it the "DOS prompt", while Linux refers to it as the "shell". Linux's shell is far more superior than Window's DOS prompt. It can do a whole lot of things that are not possible in Windows. Linux support various command line shells such as BASH, Bourne, Korn, C shell and many other.

Third Party Application Software Availability:
Both Windows and Linux run third-party applications. Windows, compared to Linux, has far greater number of third party applications available for use. A program written for Windows will not run under Linux (although it can be made to emulate, but it will be very annoying and hence not recommened).

Linux's application base is, however, increasing threefold. On a more close examination, the average computer user uses the following applications 90% of the time: Word Processor (Office suite), E-mail client, Web browser, Media software, and Instant Messenger. Linux has all these applications and in fact has many flavors for each.

Like Linux, all third party applications are very cheap or free. Whereas, Windows applications can cost a leg and a limb.

Simply put it this way, Windows is not secure. If you are using Windows and don't have Antivirus, Anti Spyware, and firewall (memory and resource eating applications), your computer can get affected by a virus in less than 10 minutes. I remember restoring a fresh copy of Windows XP on my Toshiba A40 notebook. I was browsing the Internet with Microsoft Internet Explorer and my machine got infected with loads of spyware in less than 15 minutes!

Microsoft came up with Firewall and Anti Spyware products, but these programs run in the background and eat up your computer's precious memory.

Linux, on the other hand, doesn't have these issues. I'm not aware of any spywares for Linux. One can safely run a Linux distro without ever worrying about installing Anitvirus or Anti-Spywares.

Windows also has more security flaws than Linux. By security flaw, I mean a hacker can compromise the Windows operating system and break into your machine and destroy your files. But, flaws on Windows are quickly fixed and patches are often made available almost instantly after the flaw is reported.

Supported Hardware:
Windows was originally designed for Intel based machines. Earlier version of Windows NT also ran on RISC and Alpha architectures, but not anymore. Linux run on a wide variety of hardware. And can support some very old legacy hardware. I've seen a Linux distro running on a 486 based machine.

Diver Availability:
As one author once said, "Windows is a bag of drivers". I think that is quite true. Installing a new hardware device is a piece of cake in Windows, whereas it can be a nuisance on Linux especially for average Joe. I can't in my wildest dreams imagine my dad installing a sound card successfully in Linux.

Things however will not stay the same for long. Manufacturers are also offering Linux drivers for their hardware, which will simplify the process.

Network Support:
Linux beats Windows bad in this area. Windows was never designed for the Internet. Unix, on which Linux is based, was designed for Internet (or Network) and is far more efficient compared to Windows. A senior Network Administrator working for a Fortune-500 company, recently pointed to me that if we monitor the traffic between exchange Windows based Exchange Server and Client, we can see that hundreds of packets are going to and from even when both are idle. He said that such is not the case with Linux.

However, our average Joe will never see or feel any difference. Windows Internet is good enough for him.

File System:
Windows Vista will use a new file system called WinFS. Earlier version used FAT (FAT16 and FAT32) and NTFS file systems, with NTFS being the preferred choice. Linux supports ext2 and ext3 file systems.

FAT file systems were mediocre, but NTFS can be compared with the Linux file systems.

Both file systems allows us to create directories, sub directories and file. Linux file systems are case-sensitive whereas, NTFS is not.

Normally, Linux systems cannot access NTFS file systems, but with the help of add-on software, it can.

Help and Documentation: Linux help and documentation is quite good, accurate and to the point compared.

I've been using Windows for well over 8 years now. Frankly speaking, I hardly ever checked the accompanying documentation or the help file because everything is so simple that nobody needs to venture in the help file.

What should I buy?
OK. Truth hurts, but let it be. If you are average Joe, that extra $300 on Windows are worth spending. If you are looking an OS for your server, never even think about Windows. Buy Linux.

LDAP for authentication

Authenticating to a LDAP serverReasons for authenticating to an LDAP server.

We assume that you would like to create a web server where a client can log in and then retrieve their e-mails via internet and/or send e-mails etc. (example:, or ).

Therefore the client has to become a user on the web server. That means they have to run the web server as root (not recommended) to be able to use the commands useradd and groupadd. Your second option is to put all users into a database, where the system looks at every login and controls individual access if the user exists.

This second opportunity is safer as you have one single location in the network where all users log in (like the NDS from Novell); you can administrate the users at a central point (Single Point of Administration).

Necessary software

OpenLDAP 2.x.x ( (In this tutorial OpenLDAP 2.0.12 is used)

Nss_ldap (

Pam_ldap (

Pam-devel ( (only necessary if you did not compile PAM yourself)

Debian users only need the package libpam0g-dev ("apt-get install libpam0g-dev")

OpenLDAP should already be completly configured; if it is not and you have problems look for the tutorial by Thomas Kroll ( 1.html)

Installing the software

First, decompress the packages nss_ldap and pam_ldap by:

>> tar xvfz nss_ldap....tar.gz
>> tar xvfz pam_ldap....tar.gz

Then compile and install them by:
>> ./configure
>> make
>> make install

in each directory.

Installation time will depend on your computer.

Configuring the software

In order to store the following objects, for the LDAP account, you have to adapt the file slapd.conf ( it is in the configuration directory of OpenLDAP).

It should look like this:


include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema

# These are the files which define the objects
# that are included before starting the server.
# These entries must be changed.

# The following files should already be present,
# otherwise the LDAP server would not work properly.

pidfile /usr/local/var/
argsfile /usr/local/var/slapd.args

# This data is necessary for starting the LDAP server.

database ldbm
suffix "dc=alkronet,dc=de"

# This entry determines the highest object in your LDAP database.
# This value must be adapted.

rootdn "cn=Manager,dc=alkronet,dc=de"

# This entry determines a person who has all permissions
# for the following object in the LDAP database.
# This value must be adapted.

rootpw test

# The root password.

directory /usr/local/var/openldap-ldbm

# Directory with the LDAP database.

defaultaccess write

# Standard permissions for every user.

# Indices to maintain
index objectClass eq

The file /etc/ldap.conf must also be adapted because the programs nss_ldap and pam_ldap are accessing it (Be careful, do not edit the file: /etc/openldap/ldap.conf). It is also possible that the files are in a different place. If you use the option -sysconfdir= ... at configuration time, the files will reside in the corresponding directory.

# host where you can reach the LDAP server

base dc=alkronet,dc=de

# the base of the LDAP server

pam_filter objectclass=posixAccount

# At log in all objects which are contained in the object class
# posixAccount are searched for the user

pam_login_attribute uid

# also those which have the attribute uid

nss_base_passwd o=auth_user,dc=alkronet,dc=de?one
nss_base_shadow o=auth_user,dc=alkronet,dc=de?one
nss_base_group o=auth_group,dc=alkronet,dc=de?one

# names the LDAP place where the account data must be


# ssl connections = no

Afterwards a file should be created where an organizations container object is put in. This file could look like the following:

dn: o=auth_user, dc=alkronet, dc=de
o: auth_user
objectclass: organization

# these lines create an organizations object
# which is named "auth_user". Later, new
# users will be inserted in this object.

dn: o=auth_group, dc=alkronet, dc=de
o: auth_group
objectclass: organization

dn: cn=user, o=auth_group, dc=alkronet, dc=de
objectClass: posixGroup
objectClass: top
cn: user
userPassword: {crypt}x
gidNumber: 10

# here the group "user" with the number 10 is created

dn: uid=tester, o=auth_user, dc=alkronet, dc=de
uid: tester
cn: Test Tester
objectclass: account
objectclass: posixAccount
objectclass: top
objectclass: shadowAccount
userPassword: test
shadowLastChange: 11472
shadowMax: 99999
shadowWarning: 7
uidNumber: 1000
gidNumber: 10
homeDirectory: /home/tester
loginShell: /bin/bash

# uid = user- und login name
# cn = christian name, surname would be sn
# afterwards the object classes are defined
# for the quite tricky values with shadow*
# the manpages of passwd, useradd and
# shadow should probably be consulted
# uidNumber = user number or user id
# gidNumber = group number or id the user belongs to
# homeDirectory = home directory
# loginShell = login shell

After this file is created it can be added to the LDAP server.

This is done with the command ldapadd.

>> ldapadd -x -D "cn=manager, dc=alkronet, dc=de" -W -f User.ldif

Now the user is included in the LDAP database but the database is not accessed during log in.

So the PAM service must be adapted to the LDAP server.

Preparing the system for authenticating to a LDAP server

First /etc/nsswitch.conf must be edited to tell the system that group-, user- and password information is not only held in files but also on a LDAP server.

This could look like the following:

passwd: ldap files
group: ldap files
shadow: ldap files

# ldap was added here

hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

If you compiled the packages nss_ldap and pam_ldap yourself, a file named ldap.conf should exist in the directory /usr/local/etc. If it is not, the option -sysconfdir was used at compile time. You should look in the directory you chose then.

Debian users who have worked with apt-get own the two files pam-ldap.conf and libnss-ldap.conf. These files are the same and you could also create a link (e.g.: ln -snf /etc/pam-ldap.conf /etc/libnss-ldap.conf).

The content of this file determines which LDAP server to authenticate to and which objects contain the user- and password information.

It could look like the following:

Ldap.conf oder ldap-pam.conf

# IP des LDAP Servers

base dc=alkronet,dc=de
# base object of the server

# binddn cn=proxyuser,dc=padl,dc=com
# bindpw secret
# rootbinddn cn=manager,dc=padl,dc=com
# port 389

# if you have to authenticate to the LDAP server to be able
# to browse data, the user and password have to be
# named here

# timelimit 30
# sets how long a user is allowed to browse the LDAP server

# bind_timelimit 30
# sets how long a user is allowed to be connected
# to the LDAP server

# idle_timelimit 3600
# sets the time the connection is automatically cut
# when the user is idle

pam_filter objectclass=posixAccount
# search all entries where the object class equals posixAccount

pam_login_attribute uid
# the username is stored in the attribute uid

nss_base_passwd o=auth_user, dc=alkronet,dc=de?one
nss_base_shadow o=auth_user, dc=alkronet,dc=de?one
nss_base_group o=auth_group, dc=alkronet,dc=de?one

# sets the path to the passwords, the shadow entries and the
# group information
# ?one means, that only one entry may be used
# if there is more than one entry the first found
# password is used

# SSL connections are not supported

Furthermore the configuration files of every service that is running on the system that will authenticate to the LDAP server must be adapted.

The configuration files reside in /etc/pam.d. Some examples are already included with the PAM software and can be found in example.

If you did not compile PAM yourself they should be in /usr/share/doc/pam, /usr/share/doc/packages/pam or /usr/share/doc/libpam.

The file that is accessed during log in is named login and could look like this:

auth required /lib/security/
auth required /lib/security/
auth sufficient /lib/security/ use_first_pass
auth required /lib/security/ try_first_pass
account sufficient /lib/security/
account required /lib/security/
password required /lib/security/
password required /lib/security/
password required /lib/security/ use_first_pass
session required /lib/security/

# /lib/security/ should be available
# for every section (auth, account, password) now

# use_first_pass means that the first entered password is used
# and the files (shadow and passwd) are omitted

The other files in the directory can also be adapted this way; or you could take the example files from PAM.

Now logging in should be working, but I had to reboot (perhaps some services must be restarted).

PHP script for adding users

$username = testuser;
$password = testuser;
$user_id = 1005;

$ldap_server = "";
$ldap_base = "dc=alkronet,dc=de";

# Attention: Double user ids could lead to authenticating errors


$connect = ldap_connect($ldap_server);
$bind = ldap_bind($connect, "cn=manager, ".$ldap_base, "test");

if (!$bind || !$connect) {
echo "Connection could not be established.";

ldap_add($connect, "uid=".strtolower($username).", o=auth_user, ".$ldap_base, $entries);

if (ldap_error($connect) != "Success") {
echo "




In the real world, corporate networks are usually a heterogeneous mix of different makes and models of computers and services. In my probably typical work environment, we mix a few MS Windows Servers in with many Linux and IBM A/S400 servers. While it would be nice to be a homogeneous network, often times, the software required for business just isn't made for your preferred operating system. Hopefully this brief paper will help integrate your rock-solid "legacy" DNS servers running on *NIX with your Active Directory Domain Controllers.

The key to this is a little used (at least in the BIND DNS world) item called a Service Record, or SRV record. SRV records are intended to relay information via DNS regarding which server is providing which service. The server may be on your local LAN, but it's not required. If a Domain Controller (referred to here after as DCs) is on the same LAN as your workstation, the workstation will use it's own mechanism, a network broadcast, to find the DC so a SRV record may not be absolutely required. If however they are on different networks or LANs, SRV records will be required so the workstations knows where the DC is located. If you've read anything about routing, you probably know this is because the router between the 2 LANs will not forward the workstations broadcast traffic to the DCs LAN. Thus the DC cannot answer the broadcast leaving the workstation isolated on the other side of the router.

Don't be alarmed by the funky syntax, but here is a sample SRV record: SRV 10 5 80

As you can see an SRV record has several fields and a unique system for naming. The naming system is an underscore followed by the name of the service, followed by a period, an underscore, and then the protocol, another dot, and then the name of the domain. The period at the end of the domain is required in this case. This tells BIND not to append another "" to the name making it "". Same goes for the period at the end of the target computer as well.

If the fields were labeled by number left to right in the above example. The fields are:
1. The _service._protocol.domainname
2. The Resource Record. As you can guess, it will always be SRV for Service Records. For other types of records it can be different, eg, for Address Records it will be A instead of SRV.
3. The Priority of 10. This sets the preference for a host specified in the target field. DNS clients that query for SRV resource records attempt to contact the first reachable host of the lowest numbered preference listed here. Although target hosts have the same stated preference value, they can be tried in random order. The range of preference values is 0 to 65535. I keep these at 0 (zero) most of the time to make it simpler.
4. The Weight of 5. Can be used in addition to preference to provide a load-balancing mechanism, where multiple servers are specified in the target field and are all set to the same level of preference. When selecting a target server host among those of equal preference, this value can be used to set an added level of preference that can be used to determine the exact order or balancing of selection for the target hosts used in an answered SRV query. When a non-zero value is used, servers of equal preference are tried in proportion to the weight of this value. The range of values is 1 to 65535. If load balancing is not needed, use a value of 0 in this field to make the record easier to read.
5. The Port Number for the service(80). In the example it is the common port for the http service of 80, but it can be anything. For example, if you run http on port 8888, then you would put 8888 in this field. This particular field was the entire reason SRV records surfaced. They were made to allow clients to know which port a service was running on in case it was running on an unusual port number. The *NIX world thought running common services on unusual ports was a bad idea. As a side effect so SRV records were never embraced and are not commonly used by *NIX admins.
6. The target server. This should match the name given by the Address Record of the target server of course.

The SRV record will go in the forward look-up file. This will be the same file containing the A records. If you see files with Pointer Records (PTR) files, you are in the wrong file.

Ok, now the actual part that makes things work. In order for a workstation to find out which server is the DC, four SRV records are required to complete the deal for each DC. This example is for one domain controller, so the weight and priority fields are set to zero (0). Also, you should be able to see that the LDAP service uses port 389, and the Kerberos service uses port 88.

If you have an Address Record (A) that identifies your server name like this: A 111.222.333.444

Then your SRV records for this DC would be as follows SRV 0 0 389 SRV 0 0 88 SRV 0 0 389 SRV 0 0 88

You may notice that there are two LDAP and two Kerberos entries that look similar. One simply tell where the LDAP and Kerberos services are running and the other on tell the client that it is the DC for the listed target domain.

If you have 2 or more DCs you can experiment with the priority and the weight fields, but I'll leave that as an exercise for you.

Hopefully with this little bit of info, you can forgo the hardships of trying to make your legacy system work with MSDNS. Why learn more than you have to when, in this instance, the old way is clearly the best way!

MPM in apache

'Multi Processing Modules', generally called MPMs, are modules that get the primary attention in Apache. Apache has been known for its extensibility through modules and this is one of the main reason that it has been favoured worldwide, apart from its rock stabilty. Modules that can be added at a later stage or when in need makes Apache more stable due to the decreased load.

MPMs are supposed to do the rigorous work of binding to the port specified, accepts the connection requests, generate the child processes according to the load of the server and dispatch the children for the incoming connections. They are loaded along with 'httpd' at startup time. Many a MPM exist, but one and only one can exist in a running Apache installation. The default MPM for Unix is the 'Prefork' module. The default MPMs which exist for other platforms are :

BeOS : beos
Netware : mpm_netware
OS/2 : mpmt_os2
Windows : mpm_winnt

The main difference between MPMs and normal modules is that only one of the former can be used and multiple ones can be loaded in the latter. MPMs must be chosen during install and can be compiled into the binary using the '--with-mpm=NAME' option. If any of the MPMs are not specified, then the default MPM, 'prefork', will be compiled. Apache in Windows is now more efficient since it does not need to use the POSIX compliance and can use the native networking features of the OS. In the Windows environment,the MPM 'mpm_winnt' is used as the default.

Two of the MPMs specified in 'httpd.conf' are 'prefork' and 'worker'. These two MPMs exists for different specifications. The 'worker' MPM was introduced in Apache2. It uses a multiprocess-multithreaded structure. Multi-process means the number of child servers started and multi-threads, the number of connections made by each child-process. The child servers starts the threads according to the directives 'ThreadsPerChild', 'MinSpareThreads' and 'MaxSpareThreads'. By using a threaded structure, each child server can handle more than one connection, upto the limit specified by 'MaxSpareThreads'. The parent process is responsible for starting the child processes. The child instances inturn starts the number of threads specified by 'ThreadsPerChild ' and one additional thread for listening to incoming requests. The main drawback is that it makes more demand on your virtual memory and since one child server handles more than one thread (each thread equals one connection), anything that effects a particular child process has the same effect on the connections. In short, one crashed child process means more than one lost connection. But in the case of 'prefork' module, the concept of threads doesn't exist. A seperate child process get started for each incoming connection, provided within the limit specified. This concept is more geared towards stability since each child process has to handle only its own connection.

'Multi Processing Modules' are just a small part of the really big world of modules in Apache. More about module configuration in the next part. More to come.