Friday, February 25, 2011

the issuer of this certificate cannot be found Certificate cannot be verified up to a trusted certification authority

SkyHi @ Friday, February 25, 2011
After migrate(export and import ssl from Windows Server 2003 IIS to a new IIS server, the following 2 errors appears:
  • the issuer of this certificate cannot be found
  • Certificate cannot be verified up to a trusted certification authority?

SOLUTION:      (talk to thawte tech support)
 Install the thawte Intermediate CA file

Step 2 - Download the thawte Intermediate CA file for your SSL product type:
Note: You MUST install correct thawte Intermediate CA file on your server for your SSL certificate to work and be fully supported in all web browsers.
Skip to step 3 If you have already downloaded the CA file otherwise select your SSL product type below to download the thawte Intermediate CA (Right Click on link & Save)

Step 3 - Create a Certificate Snap-in:
Note: Please ensure for step 8 to select 'Computer Account', selecting any other option will result in a failed installation.
  1. From the Web Server, Click Start > Run
  2. Type in MMC and Press Enter
  3. Click OK
  4. From the Microsoft Management Console (MMC) menu bar, Click File (in IIS 6.0) or Console (in IIS5.0) > Add/Remove Snap-in
  5. Click Add
  6. From the list of snap-ins, Select Certificates
  7. Click Add
  8. Select Computer Account
  9. Click Next
  10. Select Local Computer (the computer this console is running on)
  11. Click Finish
  12. In the snap-in list window, Click Close
  13. In the Add/Remove Snap-in Window, Click OK

Step 4 - Install the thawte Intermediate CA file:
  1. From the left pane, Expand the 'Intermediate Certification Authorities' folder
  2. Right-Click on 'Certificates' folder
  3. Click All Tasks > Import
  4. In the Certificate Import Wizard, Click Next
  5. Click on Browse and locate the Intermediate CA Certificate File (The PKCS#7 file you downloaded in step 2)
  6. Click Next
  7. Select option 'Place all certificates in the following store'
  8. Click Browse button and select 'Intermediate Certification Authorities'
  9. Click OK
  10. Click Next
  11. Click Finish
  12. Keep the Certifcate Snap-in open as you will need it to complete step 5.

Please download the Thawte Intermediate CAs for your SSL certificate here:

If you require the CA bundle version of the Intermediate CAs, please download it here:

Ensure you have installed your certificate correctly at:

Additionally, as part of your SSL Certificate Service, you are entitled to display the Thawte Trusted Seal - recognised across the Internet and around the world as a symbol of authenticity, security, and trust - to build consumer confidence in your Web site.

Installation instructions for the Thawte Trusted Seal can be found on the following link:

Visit the Thawte Support Web site, where you will find a range of support tools to help you:


Thursday, February 24, 2011

Sendmail: How To Queue Mails based Server Load Average

SkyHi @ Thursday, February 24, 2011
There has been a lot of web debates and arguments which STMP email server works better, safer and faster. Not to discredit any other SMTP armies on the field, but I do often hear people debating about how difficult for them to configure Sendmail on time. Probably sendmail should be repackaged with a little teaspoon drop of sweet patience into it, so those mingling crowd could can get the taste better than they used to have.
In reality Sendmail is very easy to configure and flexible. Sendmail growth continuous to evolve as the crowd needs continue on demanding. Have you ever heard of Sendmail Engineer job position that only works with Sendmail setup and configuration? Just imagine what kind of sendmail job this sendmail engineer is usually doing.
Here are a few sendmail configuration tweaks that you can play with on queueing up incoming and new SMTP connection based on server’s current load average value.

Sendmail Directive Configurations
Most sendmail directives does not come with its default sendmail rpm installation. Here are a few of sendmail directives that you could manage to control, delay and queue incoming SMTP connections based on current server load average.

Sendmail directive: confQUEUE_LA
One trick you can play along with sendmail configuration setup is on how you could tweak sendmail to queue incoming mails and put on hold, rather than queue them up immediately for delivery if a certain sendmail rules is met. The below sendmail directive considers current server’s load average value as a basis to put new and incoming emails on hold.
define(`confQUEUE_LA’, `10′)dnl

If the server’s load average value increases to or more than 10, then sendmail is then instructed to put all incoming emails on queue for hold, instead of delivering all new incoming emails for delivery. The sendmail directive is active until the server’s load average value decreases down below 10.

Sendmail directive: confREFUSE_LA
Now, if you want to tweak sendmail to stop accepting any new incoming SMTP connections and mails based on server load average value, you could make use of the below sendmail configuration directive as shown below
define(`confREFUSE_LA’, `15′)dnl

The above instructs sendmail to completely stop accepting new and rejecting incoming SMTP connections if and only the current server load average reaches and stays 15 or above.
Sendmail directive: confDELAY_LA

Now, to throttle SMTP connections, we can make use of the below sendmail directive
define(`confDELAY_LA’, `5′)dnl

The server load average value of 5 is a sendmail directive trigger point at which sendmail is instructed to sleep for one second on most SMTP commands and before accepting SMTP connections again. 0 means no limit.
When modifying sendmail configuration file /etc/mail/, always remember to restart sendmail service to take effect the new changes from sendmail directives.

To recompile sendmail configuration file
# m4 /etc/mail/ > /etc/mail/

To restart sendmail service
# service sendmail restart

To monitor sendmail logs
# tail -f /var/log/maillog

To monitor queued mails
# mailq
There are a lot more sendmail directives and M4 sendmail variables that are just waiting to be configured and changed.


Monday, February 21, 2011

Understanding logrotate on CentOS

SkyHi @ Monday, February 21, 2011

Understanding logrotate on CentOS - part 1

It's no fun when log files grow out of control. In this two-part series, learn how to use logrotate to keep those logs in check.

What is logrotate?

It may surprise you to learn that logrotate is a program used to rotate logs. It's true! The system usually runs logrotate once a day, and when it runs it checks rules that can be customized on a per-directory or per-log basis.
"Log rotation" refers to the practice of archiving an application's current log, starting a fresh log, and deleting older logs. And while we're explaining things, a "log" is a file where an application stores information that might be useful to an administrator or developer - what it's been doing, what errors it's run into, that sort of thing. So logs are good, you just usually don't want to keep a ton of them around. That's where logrotate comes in.

The importance of log rotation

Logs are wonderful things when you want to track usage or troubleshoot an application. Unfortunately the more information that gets logged, the more disk space the log uses. Over time it can really add up.
A log left unrotated can grow to a pretty unwieldy size. Running out of disk space because of a giant log is a problem of course, but a huge log file can also slow down the process of resizing or backing up your virtual server. Another practical consideration is that it's hard to look for a particular event if you have a million log entries to skim through. So on the whole it's a good idea to keep log files down to a manageable size, and to prune them when they get too old to be of much use.
Fortunately logrotate makes log rotation easy.

How it works

The system runs logrotate on a schedule, usually daily. In fact, you'll find the script that runs logrotate daily at:
If you want logrotate to run more often (for hourly log rotation, for example) you'll need to look into using cron to run logrotate through a script in /etc/cron.hourly.
When logrotate runs it reads its configuration files to determine where to find the log files it needs to rotate, and to check on details like how often the files should be rotated and how many archived logs to keep.


The main logrotate configuration file is located at:
If you look inside that file you'll see the default parameters logrotate uses when it rotates logs. The file is nicely commented, so skim it to see how things are set up. We'll talk about several of the specific commands in that file shortly.
Note that one line reads:
include /etc/logrotate.d
That's where we'll find most of the application-specific configuration files.


Take a look inside the directory where you'll store application-specific log settings:
ls /etc/logrotate.d
Depending on how much you've installed on your server there may be no files in this directory, or there may be several. In general, applications that are installed through CentOS's package manager (yum) will also create a config file in /etc/logrotate.d.
Most likely you will at least see a config file for syslog, which logrotate will read when it goes to rotate the system logs. If you look inside you'll see an entry for various system logs along with some commands similar to what you saw in logrotate.conf.

Inside an application file

As an example, let's take a look at the contents of a logrotate config file that might be put in place when you install apache:
/var/log/httpd/*log {
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
We'll look at what most of the specific directives in this file mean in a bit, but the short version is that when logrotate runs it will check for any files in /var/log/httpd that end in "log" and rotate them, so long as they aren't empty. If it checks the httpd directory and doesn't find any logfiles it won't throw an error. Then it will run the command in the "postrotate/endscript" block (in this case, a command that will tell apache to restart), but only after it's processed all the specified logs.

What you don't see in that file are some settings you saw back in logrotate.conf. This is because the commands in logrotate.conf act as defaults for log rotation. You can specify different settings for any application where you want to override the defaults. For example, if you run a busy web server, you may want to include a "daily" command in apache's config block so apache's logs will rotate daily instead of the default weekly rotation.

That might be more clear if we talk about what some of the more commonly-used commands actually do in a logrotate config file. So let's do that next.

Configuration commands

You can get a full list of commands used in logrotate configuration files by checking the man page:
man logrotate
We'll go over more commonly-used commands here.
Remember, the config files for applications in /etc/logrotate.d inherit their defaults from the main /etc/logrotate.conf file.

Log files

A log file and its rotation behavior is defined by listing the log file (or files) followed by curly brackets. Most application configuration files will contain just one of these blocks, but it's possible to put more than one in a file, or to add log file blocks to the main logrotate.conf file.

You can list more than one log file for a block either by using a wildcard in the name or by separating log files in the list with spaces. For example, to specify all files in the directory /var/foo that end in ".log", as well as the file "/var/bar/log.txt", you would set up the block like so:
/var/foo/*.log /var/bar/log.txt {
        blah blah blah
        blah blah blah redux
Just not with as many blahs.

Rotate count

The "rotate" command determines how many archived logs will be kept around before logrotate starts deleting the older ones. For example:
rotate 4
That command tells logrotate to keep 4 archived logs at a time. If there are already four archived logs when the log is rotated again, the oldest one (the one with ".4" at the end, usually) will be deleted to make room for the new archive.

Rotation interval

You can specify a command that will tell logrotate how often to rotate a particular log. The possible commands include:
If a rotation interval is not specified the log will be rotated whenever logrotate runs (unless another condition like "size" has been set).

If you want to use a time interval other than the keywords listed here you'll have to get clever with cron and a separate config file. For example, if you wanted to rotate a particular log file hourly, you could create a file in "/etc/cron.hourly" (you may need to create that directory too) that would contain a line like:
/usr/sbin/logrotate /etc/logrotate.hourly.conf
Then put the configuration for that hourly run of logrotate (the log file location, whether or not to compress old files, and so on) into "/etc/logrotate.hourly.conf".


You can specify a file size that logrotate will check when determining whether or not to perform a rotation by using the "size" command. The format of the command tells logrotate what units you're using to specify the size:
size 100k
size 100M
size 100G
The first example would rotate the log if it gets larger than 100 kilobytes, the second if it's larger than 100 megabytes, and the third if it's over 100 gigabytes. I don't recommend using a limit of 100G, mind you, the example just got a little out of hand there.

The size command takes priority over a rotation interval. When a log rotates because it hit its size limit the time interval resets for that log file. For example, if a log set to rotate "weekly" is rotated because it hit its max size after four days, logrotate will wait another week after that before rotating the log based on the time interval that has passed. As a result, if you use an interval other than "daily" and specify a maximum size for the log file, the log rotation won't be guaranteed to happen on the same day every week.


If you want archived logfiles to be compressed (in gzip format) you can include the following command, usually in /etc/logrotate.conf:
This is normally a good idea, since log files are usually all text, and text compresses very well. You might, however, have some archived logs you don't want compressed, but still want compression to be on by default. In those cases you can include the following command in an application-specific config:
One more command of note in regard to compression is:
This command can be useful if you want the archived logs to be compressed, but not right away. With "delaycompress" active an archived log won't be compressed until the next time the log is rotated. This can be important when you have a program that might still write to its old logfile for a time after a fresh one is rotated in. Note that "delaycompress" only works if you also have "compress" in your config.

An example of a good time to use delaycompress would be when logrotate is told to restart apache with the "graceful" or "reload" directive. Since old apache processes would not be killed until their connections are finished, they could potentially try to log more items to the old file for some time after the restart. Delaying the compression ensures that you won't lose those extra log entries when the logs are rotated.


The "postrotate" script is run by logrotate each time it rotates a log specified in a config block. You'll usually want to use this to restart an application after the log rotation so the app can switch to a new log.
    /usr/sbin/apachectl restart > /dev/null
That "> /dev/null" bit at the end tells logrotate to pipe the command's output to, well, nowhere. Otherwise the output of that command will be sent off to the console or the log or email or whatever, and in this case, you don't really care about the output if everything restarted okay.

The "postrotate" command tells logrotate that the script to run will start on the next line, and the "endscript" command says that the script is done.


Normally logrotate will run the "postrotate" script every time it rotates a log. This is true for multiple logs using the same config block. So for example, a web server config block that refers to both the access log and the error log will, if it rotates both, run the "postrotate" script twice (once for each file rotated). So if both files are rotated, the web server will be restarted twice.

To keep logrotate from running that script for every log, you can include the command:
That tells logrotate to wait until it's checked all the logs for that config block before running the postrotate script. If one or both of the logs get rotated, the postrotate script still only gets run once. If none of the logs get rotated, the postrotate script won't run at all.


You've seen an overview of what logrotate does and what kind of configuration options are available to you. You should be all set to go poking around in the existing configs and adapt them to your needs. But let's not stop there! In the next article we'll look at putting an example config together (to rotate the logs for custom virtual hosts), and also cover some handy troubleshooting approaches.

Understanding logrotate on CentOS - part 2

In this second part of the logrotate series we look at how to set up rotation for virtual host logs, as well as some troubleshooting techniques.

Applying knowledge

In the previous article we talked about what logrotate does and how you can configure it. In this article we'll apply this new knowledge to putting together a log rotation solution for a custom virtual host or two (or three, or four, etc.). We'll also look at some options for testing and troubleshooting logrotate.

Tying it all together: virtual host logs

To show how you can use logrotate for your own applications, let's look at an example that will come in handy for a lot of people: rotating logs for your custom virtual hosts. We'll use apache for this example, but it can be tweaked pretty easily for other web servers like nginx or lighttpd, usually just by changing the postrotate script.

First we'll want to create a file to hold the configuration that will tell logrotate what to do with the virtual host's log files. We won't edit the main config file or the web server's config file, since there's always a possibility that a future package upgrade might want to overwrite the config. Instead we'll make our own. Let's call it:
This example tosses all the virtual hosts into one file, but if you have one that's busier than others you may want to create separate config files to handle the needs of your different domains. We'll also specify several items that are probably already set in your main config, just so we cover all the bases.

The files

We'll say that we have two virtual domains, and, and that the log files for each are in /home/demo/public_html/(domain name)/log. The first thing we'll do in our config file is tell logrotate where to find the log files, then start the config block for them:
/home/demo/public_html/*log /home/demo/public_html/*log {
If you have more log directories or files to add, just insert them into that list.


Next we'll want to make sure logrotate only keeps as many old logs as we want:
rotate 14
We'll use 14 in this example to keep two weeks' worth of logs, but you can of course adjust that number to something suitable to your requirements.


Now we'll tell the web server to rotate these logs daily (again, change it if you prefer a longer interval):

Size (optional)

If you prefer a weekly rotation it's wise to specify a max log size as well, to be on the safe side. The max size setting doesn't make much difference if you have the logs rotating daily, but if you use "weekly" or longer instead you might also include the line:
size 50M
That way if a log starts getting too large (from unexpectedly heavy traffic, for example) it will be rotated early rather than allowing it to get too unwieldy.


We'll specify whether or not we want these logs to be compressed when they're archived. For this example we'll use delaycompress to account for the graceful restart of apache, which means we also need to turn compression on:


You might have several virtual hosts, and that would mean several logs to rotate. To make sure the web server only gets restarted after all the rotations are done we add:


We'll specify a postrotate script that will restart the web server:
        /usr/sbin/apachectl graceful > /dev/null
And finally, we close the config block with a curly bracket:

The whole shebang

Once we bring it all together our config file will look like this:
/home/demo/public_html/*log /home/demo/public_html/*log {
        rotate 14
                /usr/sbin/apachectl graceful > /dev/null
You'll want to test that, of course, either by making sure you're watching things when the nightly cron jobs are run, or by running logrotate right now:
/usr/sbin/logrotate /etc/logrotate.conf
If you don't get any errors back you should be okay. But if you want to be absolutely certain you can run through some of the tests we would use when we suspect something isn't working right.

Testing logrotate

If you suspect logrotate is having some trouble, or you just want to make sure a new config you've put in place will work, there are some useful flags you can pass to logrotate when you run it from the command line:


The verbose flag, "-v", tells logrotate to say what it's doing while it's doing it. It's very useful when trying to find out why logrotate doesn't rotate a log when you want it to.


The debug flag, "-d", tells logrotate to go through the motions of rotating logs but not actually rotate them. It can be handy if you want to test a new config file but don't want any actual log rotation run when you do (if you're working on a production server, for example).

The debug flag is good for checking that the config file is formatted properly and that logrotate can find the log files it would rotate. However, since it doesn't actually run the rotations it doesn't test some parts of the process like the postrotate scripts.


The force flag, "-f", forces logrotate to rotate all logs when it runs, whether or not they would normally need to be rotated at that time. If you want to thoroughly test logrotate's configs this is the flag to use. Just remember that logrotate will be rotating logs and deleting old ones according to the configuration you've set up, so don't accidentally rotate out a recent log you needed to keep.

The force flag can be useful if you're convinced that logrotate should be rotating a log, but it isn't. Forcing the issue will help you tell if the problem is that logrotate doesn't think the log needed rotating (if you run with the force flag and the log is rotated), or if the problem is that logrotate isn't able to affect the log file (if you run it and nothing happens to the log).

Note that if logrotate is set to add a date to the name of an archived log, not even using the force flag will get logrotate to make a new archive in the same day (since the name it would use for the archive is already taken). In that circumstance you may need to rename the most recent archive (for each log file in a given config block) before you can force a log rotation.

Combining flags

The testing flags can be used together quite effectively. To have logrotate tell you what it would do if you made it rotate everything, but not actually rotate anything, you can combine all three:
/usr/sbin/logrotate -vdf /etc/logrotate.conf
You'll get treated to a long list of things logrotate would do, including which log files it would rotate and what it would do during that process.

If you then want to test all the rotate configs in their entirety — including the scripts run after rotations — you can run logrotate without the debug flag:
/usr/sbin/logrotate -vf /etc/logrotate.conf
All the logs will be rotated, and skimming the output should help you catch any obvious problems. You'll also want to make sure that all your services are still running okay (that there was nothing wrong with the postrotate scripts), and that all the logs actually did get rotated.

How logrotate remembers

If you find that a log isn't rotating even though it's old enough that it should, a simple way to fix the problem is to manually run logrotate with the "-f" flag. But if you're the sort who wants to know why something's gone wrong, there's one more file you can check before forcing a rotation:
That file is where logrotate stores information about when it last rotated each log file. If you look inside you'll see something like:

logrotate state -- version 2
"/var/log/acpid.log" 2010-6-18
"/var/log/iptables.log" 2010-6-18
"/var/log/uucp.log" 2010-6-29
It's a straightforward format - the log file location is on the left, and the date when it was last rotated is on the right. Sometimes it can happen that the dates on your server get a little wonky (if you were tinkering with an NTP service or the like), and the date when a log was last rotated winds up being a future date. If that's happened you'll see it here.

If you want to check logrotate out with a particular log file but don't want to force everything to rotate, you can delete the log's entry from the logrotate status file. Then when you run logrotate normally it should create a new entry for the log with today's date (even though it may not actually rotate the log - it uses that first run as a baseline if it's just interval-based).


For something that runs quietly in the background and only really performs one type of task, logrotate does quite a bit. You hopefully understand logrotate better than you wanted to. At the least you should be able to set up new logrotate config files for your own purposes, either creating them from scratch or copying existing configs and modifying them appropriately. And most importantly, you can keep your logs from getting out of control.


PHP: Stop Notice and Variable Warnings in Error Log Files

SkyHi @ Monday, February 21, 2011
Q. I'm using error logging in place of error displaying on production web sites. However, I do not want to see error messages about the use of uninitialized variables. I'd like to see all critical errors, except for notices and coding standards warnings. How do I disable error messages?

A. PHP provides various levels of error reporting using a bit-field as follows:

Error BitPurpose
E_ALL All errors and warnings (doesn't include E_STRICT)
E_ERROR Fatal run-time errors
E_WARNING Run-time warnings (non-fatal errors)
E_PARSE Compile-time parse errors
E_NOTICERun-time notices (these are warnings which often result from a bug in your code, but it's possible that it was intentional (e.g., using an uninitialized variable and relying on the fact it's automatically initialized to an empty string)
E_STRICTRun-time notices, enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.
E_CORE_ERRORFatal errors that occur during PHP's initial startup
E_CORE_WARNING Warnings (non-fatal errors) that occur during PHP's initial startup
E_COMPILE_ERROR Fatal compile-time errors
E_COMPILE_WARNING Compile-time warnings (non-fatal errors)
E_USER_ERROR User-generated error message
E_USER_WARNINGUser-generated warning message
E_USER_NOTICEUser-generated notice message

Show only errors

Open /etc/php.ini file
# vi /etc/php.ini

Set error_reporting as follows:
Alternately, you can show all errors, except for notices and coding standards warnings
error_reporting = E_ALL & ~E_NOTICE
Save and close the file. Restart apache web server:
# /etc/init.d/httpd restart

I am running my web site on a shared host.
In my case the /etc/php.ini is not accessible, but they allow me to use local php.ini in each folder.
Other web hosting companies allow to modify .htaccess, so the alternative solution for this:

error_reporting = E_ALL & ~E_NOTICE

when using .htaccess is:

php_value error_reporting 2039