How to use qmailmrtg7

REQUIREMENT :-

mrtg.xxx should be installed.


1) Install mrtg

2) Make qmailmrtg7 as root. It needs to be able to read
your /var/qmail/queue directories

# make

3) Install it
# make install
all this does is copy qmailmrg7 to /usr/local/bin

4) Create an mrtg working directory under your web servers
document root.

On default apache installations I do:
mkdir /var/www/html/qmailmrtg

5) setup qmail.mrtg.cfg and index.html

copy qmail.mrtg.cfg and index.html to the
directory you made in step 4.

edit qmail.mrtg.cfg and index.html

Change: FQDN to your hostname
FQDN = fully qualified domain name
Change: WorkDir to point to your http mrtg directory

Change the log file locations to where you store your qmail logs.
I put my qmail-send logs in /var/log/qmail
my pop3 longs in /var/log/pop3 and my smtp logs in /var/log/smtp

If you are not logging pop or smtp comment out the pop3 and smtp
sections with a # character at the beging of each line.

You can update the pop3 and smtp lines and set the
MaxBytes variable to match your -cX line in tcpserver.

You can also update the concurrency to match your
concurrencyremote or concurrencylocal values. The default
qmail values are 20 if those files do not exist in your
/var/qmail/control directory

NOTE:-
Now copy qmail.mrtg.cfg in /etc/mrtg/
which will create png images and also will be linked with mrtg.



6) Add a crontab line
On my machine I do the following:
crontab -e

*/5 * * * * /usr/local/bin/mrtg /etc/mrtg/qmail.mrtg.cfg 2>&1 > /dev/null


exit the crontab editor

7) run mrtg 3 times to get it setup. You will get warning messages
the first 3 times you run it. After that, you should not get more warnings
/usr/local/bin/mrtg /etc/mrtg/qmail.mrtg.cfg

8) wait 15 minutes for the logs to start showing things

9) Check out the graphs
http://your host name/qmailmrtg/

10) Read the FAQ file

Hi-Tech Phones ...........Yet to be in India

APPLE IPHONE



LG KE850 PRADA
SamSung ULTRA VIDEO SGH F500
Nokia 6110

SONY ERRICSON FOMA SO902iwp+

 

Phones We'd Like To See In India

 

SONY ERRICSON FOMA SO902iwp+

Now here's a phone that's right ready for a country like ours that tends to get flooded ever so often during the monsoons. The FOMA SO902… that's too long a name. But this is Sony Ericsson Japan's waterproof phone. So if you're ever caught in a sudden rain shower or for those overly popular people who need to talk even while taking one, this phone is right up your alley. It even runs on a Symbian OS so we're all used to that right (as long as the OS is not in Japanese).

Nokia 6110 Navigator

Not that people in this city need to find their way around or anything (the friendly neighborhood paan-walah is always around), but a GPS map in my mobile phone just might come in handy for people like my dad who tend to get a bit lost in some of those odd places in the city at night. Here's where the Navigator comes in with its voice guided 3D map guidance system. It's also equipped with a 2.0 megapixel camera and software that reads out your messages and emails, just like MOTOMING 's 'Talking Phone' software. The 6110 also runs on Symbian OS. It's also equipped with a media player with 3D sound and it even comes with 40MB of internal memory as well as support for micro SD cards up to 2GB. It's capable of video calling and has EDGE. So it's covered for everything.



SamSung ULTRA VIDEO SGH F500


The F500 is the first Divx certified mobile phone. It also AAC+, WMA music player, MPEG-4, H.263, and WMV video formats. Aside form that the phone itself is design marvel with a swivel screen (2.4-inch) for optimizing your viewing experience. This power packed phone is also A2DP compatible and has EDGE. Now if only you could watch TV on this... But as is, it’s Awesome.



LG KE850 PRADA


Touchscreen phones are not my thing but I have to say the KE850 does seem to intrigue me. It's completely black and so shiny, so it has a lot of bling factor to it. It has a nice large 3-inch display and is equipped with a 2 megapixel camera with an LED flash. It's also equipped with Bluetooth 2.0 connectivity. Its media player supports MPEG4, H.264 formats and the audio player supports MP3/ACC/ACC+/WMA/RA formats. It even has a document viewer. Now although the phone may never reach this country, it should. I mean c'mon we have plenty of people who can afford this and we have plenty of celebs here too with a Paris Hilton complex for shiny new things.



APPLE IPHONE


Hmmm… Now I know I said 5, but I just didn't want this to be left out. Of course we want to see the iPhone come to India as well. Don't we? It's cool as phones go right? So I just thought I'd mention it.

When we first heard about the phone in detail, it blew my mind. Imagine having a phone with just one button and being able to dial a number simply by pointing to the contacts name. What will they think of next? Maybe the next upgrade would be just looking at the contacts name and dialing.

So there you have it people, 5 hi-tech phones we want to see here and ASAP please. Since mobile phones aren’t just for communication anymore but have become tools of the business trade and for a country like ours, they're a must. These phones however may not necessarily be for business but they are phones that we'd love to see in our local stores soon. As soon as we find anymore that we get a bit greedy for, you'll be the first to know.

ANAND SHAH

Apache How to

APACHE HOW TO

Installing the Unix version takes a bit of extra work. You'll first need to decompress the files using a command like this:

gzip -d apache_1.3.1.tar.gz

That leaves you with a file called apache_1.3.1.tar. To extract the Apache files from this file you need to use the following:

tar xvf apache_1.3.1.tar

Certain versions of Unix may require you to type tar -xvf, though most modern version of Unix should let you omit the minus sign and use just tar xvf.
This will create a subdirectory called apache_1.3.1. Go to that directory, and then compile Apache.

Compile Apache

There are precompiled versions of Apache available for many Unix platforms. For example, we used Red Hat Linux 5.1 as our Unix test platform and could have installed a prepackaged executable of Apache available from the Red Hat FTP site.
However, most Web builders download the source version of Apache and compile it themselves in order to gain control over the initial configuration. Once you've downloaded the source and extracted it to a directory on your local disk drive, you can change to that new directory and run the Configure program:

./configure

This creates a makefile using the default configuration file, src/Configuration.tmpl. If you want to make changes, such as including a module that's normally commented out of Apache, make that change in the Configuration.tmpl file before running Configure.
Now you need to issue two commands, one to build Apache, and the other to install it in the appropriate directories:

make & make install

This will create an Apache installation in the /usr/local/apache directory, unless you've overridden that default directory during the previous configuration step. For more on customizing Configure, check out the README.configure file that comes with Apache.
Once you've installed the Apache binaries, you're ready to learn how to run Apache.
Increase DOS environment space
Compiling Apache 1.3.1 for Windows requires the Visual C++ compiler from Microsoft. The easiest way to run the compilation scripts is from a command prompt, also known in Windows 95 as a DOS window. And the easiest way to run the Visual C++ command-line tools is by setting a number of environment variables. The Visual C++ set-up program normally puts all the environment settings in a special BAT file called vcvars32.bat. All you have to do is find and run that file (normally in the \Program Files\DevStudio\VC\bin directory) to set up your compilation environment.

On most Windows 95 and 98 installations, you don't usually have enough environment space to store all the compiler settings in vcvars32.bat. When you run the batch file, you'll get a bunch of "Out of environment space" warnings.
Digging back to the ancient days of DOS, the way you increase environment space is by adding something like the following line to your config.sys file:
shell=c:\command.com /e:1024 /p

You would replace the value 1024 with however many bytes of environment space you need. That's going to be a bit different from machine to machine, depending on what other software and settings you have, so you may want to play around with that value. Unfortunately, DOS requires you to reboot in order for any changes in config.sys to take place, so you're in for a couple reboots before you find the right amount of environment space.
Once you've got the program compiled, you're ready to try running your new Apache server.
Run Apache
Apache for Windows is run just like any other Windows application--click the appropriate shortcut in your Start menu. If you install Apache on Windows NT, you can configure it as an NT Service, which means it will start whenever NT is booted up. The Apache installation program installs a shortcut in your Start menu to let you configure this option.
Unix On Unix, you have two basic options for running Apache. The first is as a standalone server, which is the normal mode of operation. The second is as an inetd server, which is useful if you're experimenting with various Apache configuration settings.
Apache comes preconfigured to run standalone. To double-check this for your copy of Apache, open the httpd.conf file (normally stored in the /usr/local/apache/etc directory). Look for this line:

ServerType standalone

The httpd.conf file is one of Apache's configuration files. The ServerType command is called a directive, an instruction that tells Apache how to execute. The httpd.conf file is one of three Apache configuration files; the others are src.conf and access.conf. For now you just want to make sure the ServerType directive is set to standalone mode.
To actually run Apache, you execute the apachectl script. Assuming you used the default directories when you built Apache, the full command line would be:
/usr/local/apache/sbin/apachectl start

You would use apachectl stop to stop the server, and apachectl restart to restart it. If you want Unix to automatically start Apache whenever the computer boots up, copy the apachectl file into the /etc/rc.d/init.d directory.
While standalone mode is the simplest way to run Apache, there are times when you want to run it as an inetd service.

Configure inetd

In a production Web server, you'd most likely run Apache as a standalone server. But there are times when you might prefer to run it as an inetd server--on a test server with limited resources, for example.
Inetd is the Unix Internet daemon, which listens to the TCP/IP connection on your computer. Whenever inetd sees a call to a specific socket, it launches the program that's configured to handle that socket, such as Telnet (port 23) and SMTP (port 25). When the program finishes, inetd shuts it down.
This has the advantage of reusing limited resources--you don't need to have dozens of different programs running simultaneously, inetd will run them only when needed. On a test server, where you're trying different configuration directives, using inetd means you don't have to manually restart the server each time you alter the configuration.
If you want to try inetd, the first step is to edit the httpd.conf file by changing the ServerType:
ServerType inetd

Now add the following line to the /etc/inetd.conf file, which tells inetd what kind of services it's running and where to find the appropriate executable files:
httpd stream tcp nowait root /usr/local/apache/sbin/httpd -f /usr/local/apache/etc/httpd.conf

This assumes you want to run Apache as the root user. That's not a good idea on a production server, but on a test server it's probably acceptable and definitely simpler.
The last configuration change you need to make is in the /etc/services file, which tells inetd which port to associate with the HTTPD service. We've assumed the default HTTP port, port 80:

httpd 80/tcp httpd

Next, you need to restart inetd. To do that, you'll need to first figure out its process ID (PID):

ps auxw grep inetd

This runs the Unix ps command, which generates a list of running processes. That list is then piped to grep, which looks for any string that includes inetd. You'll probably get back two process IDs--one for inetd and one for grep inetd.
Finally, use the kill command to restart the appropriate PID:

kill -HUP pid

Once you get Apache running, it's time to figure out how to configure it.
Apache is controlled by a series of configuration files: httpd.conf, access.conf. and srm.conf (there's actually also a mime.types file, but you have to deal with that only when you're adding or removing MIME types from your server, which shouldn't be too often). The files contain instructions, called directives, that tell Apache how to run. Several companies offer GUI-based Apache front-ends, but it's easier to edit the configuration files by hand.
Remember to make back-up copies of all your Apache configuration files, in case one of the changes you make while experimenting renders the Web server inoperable.
Also, remember that configuration changes you make don't take effect until you restart Apache. If you've configured Apache to run as an inetd server, then you don't need to worry about restarting, since inetd will do that for you.
Download the reference card
As with other open-source projects, Apache users share a wealth of information on the Web. Possibly the single most useful piece of Apache-related information--apart from the code itself, of course--is a two-page guide created by Andrew Ford.
Called the Apache Quick Reference Card, it's a PDF file (also available in PostScript) generated from a database of Apache directives. There are a lot of directives, and Ford's card gives you a handy reference to them.
While this may not seem like a tip on how to run Apache, it will make your Apache configuration go much smoother because you will have the directives in an easy-to-access format.
One quick note--we found that the PDF page was a bit larger than the printable area of our printer (an HP LaserJet 8000 N). So we set the Acrobat reader to scale-to-fit and the pages printed just fine.

Use one configuration file
The typical Apache user has to maintain three different configuration files--httpd.conf, access.conf, and srm.conf. These files contain the directives to control Apache's behavior.
The tips in this story keep the configuration files separate, since it's a handy way to compartmentalize the different directives. But Apache itself doesn't care--if you have a simple enough configuration or you just want the convenience of editing a single file, then you can place all the configuration directives in one file. That one file should be httpd.conf, since it is the first configuration file that Apache interprets. You'll have to include the following directives in httpd.conf:

AccessConfig /dev/nullResourceConfig /dev/null

That way, Apache won't cough up an error message about the missing access.conf and srm.conf files. Of course, you'll also need to copy the directives from srm.conf and access.conf into your new httpd.conf file.

Restrict access

Say you have document directories or files on your Web server that should be visible only to a select group of computers. One way to protect those pages is by using host-based authentication. In your access.conf file, you would add something like this:
order deny,allowdeny from allallow from 10.10.64
The directive is what's called a sectional directive. It encloses a group of directives that apply to the specified directory. The Apache Quick Reference Card includes a listing of sectional directives.
The above case allows only computers with an IP address starting with 10.10.64 to access the pages in the given directory. You can use the complete IP address, an IP range as shown here, or even use the DNS names. For example, to allow only CNET computers access to a specific file, you might do this in your access.conf file:

order deny,allowdeny from allallow from .cnet.com

It's important to have that preceding period on the domain name, otherwise Apache allows only the computer that exactly matches cnet.com. If that's what you want, you can restrict to individual IP addresses and fully qualified domain names.
An interesting side-effect of host-based authentication is that if you're using a browser on the Web server machine itself and attempt to access the page through localhost, you'll be denied permission. That's because the localhost IP, 127.0.0.1, will not be in the .cnet.com range. You can easily add localhost to the permission list by putting the appropriate IP on the allow directive:
allow from .cnet.com 127.0.0.1
The majority of security measures you will need to take when running a publicly accessible Web site will be set at the operating system level. You will want to make sure write access is restricted in the directories where your Web pages are stored to keep visitors from defacing your site.

Customize error messages

If a user requests a page that doesn't exist or is in a protected directory, Apache returns one of its built-in error messages that say things like Forbidden or Not Found. That's accurate, but not very informative. You may want to give your users more guidance as to what they did wrong, provide an alternative URL to get them back in your site, or at least offer an error page that fits in with your overall site design. With a bit of editing, you can make Apache return a custom error page or run a script to handle the error.

Open the srm.conf file and insert the following:
ErrorDocument 404 /error.html

Your server will now return the error.html page whenever a user requests a page that doesn't exist (which is what the 404 error code means--check out the Apache Quick Reference Card for a list of other HTTP 1.1 status codes). In this example, the destination of the directive is an HTML page, but you could also point to a CGI or even a URL from a different Web site.
Unless you include a full URL, the ErrorDocument directive uses a path relative to the document root of your Web server. So in our example, error.html must reside in the Apache document root. By default that document root is /usr/local/apache/share/htdocs. Also, when Apache actually serves up this error page it does so within the context of the erroneous URL. So if a user requested a nonexistent page (http://www.dummydomain.com/one/two/none.html), Apache returns error.html as if it resided in the /one/two directory. That means you need to be careful and fully qualify any relative paths to images or other pages in the error.html file. Otherwise you might serve an error page that itself contained errors.

Support multiple languages

HTTP 1.1 formally specified a feature called content negotiation, which had actually been around for awhile in experimental servers, including early versions of Apache. It's a way to present documents in different languages and formats based on a user's browser configuration.
For example, suppose you're a Canadian company that needs to serve both French and English versions of your Web site. First, you must enable the feature by adding the appropriate directive to your access.conf file.
Open the access.conf file and find or create the appropriate entry where you plan to store the multilanguage pages. Then add the Options MultiViews directive to that section. Remember that Options All does not actually mean all--it doesn't turn on MultiViews support. So you must explicitly declare your intention to use MultiViews. For example:
Options MultiViews

Next, you need to edit your srm.conf file to include the languages you want to support and the file extensions associated with each language. The Canadian example calls for English and French, which have the standard identifiers en and fr, respectively. Your srm.conf file should already have these, but if not, add the appropriate lines:
AddLanguage en .enAddLanguage fr .fr
LanguagePriority en fr

The LanguagePriority directive is used when there's a tie during content negotiation. For example, if Apache can't tell whether the browser prefers English or French, the LanguagePriority directive tells Apache to serve the English version of the page.
For Apache to recognize which pages it should serve, you have to include the proper extension on your file names. If, for example, you want to offer a help file in two languages, you'd create a help.html.en and help.html.fr file with the appropriate language content. Then, when a user requests the http://yourdomain.com/multi/help.html file, Apache will check the browser's language preference and return the correct version.

Configure for server-side includes

If you want to take a small step beyond static HTML pages, but you aren't quite ready to dive into writing your own Perl scripts, then you should try server-side includes (SSI). With SSI turned on, Apache will preparse certain HTML files before sending them out, looking for special embedded commands. These commands allow you to do basic things like include the contents from another file or print out an environment variable.
To enable it, you first need to make sure it has been compiled into your version of Apache. Go to the directory where your httpd executable resides, typically /usr/local/apache/sbin, and type ./httpd -l. That should return a list of all the modules included in your build of Apache. Hopefully mod_include.c is in that list. If not, you'll have to rerun the build of Apache, editing the comment code from the mod_include in the Configuration.tmpl file.
Once you've determined that mod_include is available, you have to allow the execution of includes and map an appropriate filetype. As with all things Apache, there are about a gazillion ways to do this. Probably the easiest is to enable all the options in one place in your access.conf file:

Options +IncludesAddType text/html .shtmlAddHandler server-parsed .shtml

All files in the /usr/local/apache/share/htdocs/include directory that contain a .shtml extension get parsed by Apache before being sent out to a browser.

In many instances, the AddType and AddHandler directives are already in your srm.conf file, but they're commented out. So you could uncomment those, and in your access.conf file set the Options to allow executing include commands. Note the use of the plus sign in the Options directive--that tells Apache to add this option to any preceding options settings, rather than overriding them. If you want to limit the SSI support to prevent executing potentially dangerous programs, you might want to use Options +IncludesNOEXEC.

To test your settings, create a test.shtml file like this one:
(head)(title)SSI Test(/title)(/head)(body bgcolor="white")(h1)SSI Test(/h1)File last modified (p)(pre)(/pre)(p)(/body)(/html)

Apache will attempt to parse any text that starts with a