Procedure to add a user to PostgreSQL database

To create a normal user and an associated database you need to type the following commands. The easiest way to use is to create a Linux / UNUX IDENT authentication i.e. add user tom to UNIX or Linux system first.

Step # 1: Add a Linux/UNIX user called tom

Type the following commands to create a UNIX/Linux user called tom:
# adduser tom
# passwd tom


Step # 2: Becoming a superuser

You need to login as database super user under postgresql server. Again the simplest way to connect as the postgres user is to change to the postgres unix user on the database server using su command as follows:
# su - postgres

Step #3: Now connect to database server

Type the following command
$ psql template1
OR
$ psql -d template1 -U postgres
Output:

Welcome to psql 7.4.16, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
      \h for help with SQL commands
      \? for help on internal slash commands
      \g or terminate with semicolon to execute query
      \q to quit

template1=# 

Step #4: Add a user called tom

Type the following command to create a user called tom with a password called myPassword (you need to type command highlighted with red color):
template1=# CREATE USER tom WITH PASSWORD ‘myPassword’;

Step #5: Add a database called jerry

Type the following command (you need to type command highlighted with red color):
template1=# CREATE DATABASE jerry;
Now grant all privileges on database
template1=# GRANT ALL PRIVILEGES ON DATABASE jerry to tom;
Type \q to quit:
template1=# \q

Step #6: Test tom user login

In order to login as tom you need to type following commands. Login as tom or use su command:
$ su - tom
$ psql -d jerry -U tom

Output:

Welcome to psql 7.4.16, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
      \h for help with SQL commands
      \? for help on internal slash commands
      \g or terminate with semicolon to execute query
      \q to quit

jerry=> 

Common error messages

10.1 ‘The server's host key is not cached in the registry’

This error message occurs when PuTTY connects to a new SSH server. Every server identifies itself by means of a host key; once PuTTY knows the host key for a server, it will be able to detect if a malicious attacker redirects your connection to another machine.

If you see this message, it means that PuTTY has not seen this host key before, and has no way of knowing whether it is correct or not. You should attempt to verify the host key by other means, such as asking the machine's administrator.

If you see this message and you know that your installation of PuTTY has connected to the same server before, it may have been recently upgraded to SSH protocol version 2. SSH protocols 1 and 2 use separate host keys, so when you first use SSH 2 with a server you have only used SSH 1 with before, you will see this message again. You should verify the correctness of the key as before.

See section 2.2 for more information on host keys.

10.2 ‘WARNING - POTENTIAL SECURITY BREACH!’

This message, followed by ‘The server's host key does not match the one PuTTY has cached in the registry’, means that PuTTY has connected to the SSH server before, knows what its host key should be, but has found a different one.

This may mean that a malicious attacker has replaced your server with a different one, or has redirected your network connection to their own machine. On the other hand, it may simply mean that the administrator of your server has accidentally changed the key while upgrading the SSH software; this shouldn't happen but it is unfortunately possible.

You should contact your server's administrator and see whether they expect the host key to have changed. If so, verify the new host key in the same way as you would if it was new.

See section 2.2 for more information on host keys.

10.3 ‘Out of space for port forwardings’

PuTTY has a fixed-size buffer which it uses to store the details of all port forwardings you have set up in an SSH session. If you specify too many port forwardings on the PuTTY or Plink command line and this buffer becomes full, you will see this error message.

We need to fix this (fixed-size buffers are almost always a mistake) but we haven't got round to it. If you actually have trouble with this, let us know and we'll move it up our priority list.

10.4 ‘The first cipher supported by the server is ... below the configured warning threshold’

This occurs when the SSH server does not offer any ciphers which you have configured PuTTY to consider strong enough.

See section 4.17.5 for more information on this message.

10.5 ‘Server sent disconnect message type 2 (SSH_DISCONNECT_PROTOCOL_ERROR): "Too many authentication failures for root"’

This message is produced by an OpenSSH (or Sun SSH) server if it receives more failed authentication attempts than it is willing to tolerate. This can easily happen if you are using Pageant and have a large number of keys loaded into it. This can be worked around on the server by disabling public-key authentication or (for Sun SSH only) by increasing MaxAuthTries in sshd_config. Neither of these is a really satisfactory solution, and we hope to provide a better one in a future version of PuTTY.

10.6 ‘Out of memory’

This occurs when PuTTY tries to allocate more memory than the system can give it. This may happen for genuine reasons: if the computer really has run out of memory, or if you have configured an extremely large number of lines of scrollback in your terminal. PuTTY is not able to recover from running out of memory; it will terminate immediately after giving this error.

However, this error can also occur when memory is not running out at all, because PuTTY receives data in the wrong format. In SSH 2 and also in SFTP, the server sends the length of each message before the message itself; so PuTTY will receive the length, try to allocate space for the message, and then receive the rest of the message. If the length PuTTY receives is garbage, it will try to allocate a ridiculous amount of memory, and will terminate with an ‘Out of memory’ error.

This can happen in SSH 2, if PuTTY and the server have not enabled encryption in the same way (see question A.7.5 in the FAQ). Some versions of OpenSSH have a known problem with this: see question A.7.16.

This can also happen in PSCP or PSFTP, if your login scripts on the server generate output: the client program will be expecting an SFTP message starting with a length, and if it receives some text from your login scripts instead it will try to interpret them as a message length. See question A.7.6 for details of this.

10.7 ‘Internal error’, ‘Internal fault’, ‘Assertion failed’

Any error beginning with the word ‘Internal’ should never occur. If it does, there is a bug in PuTTY by definition; please see appendix B and report it to us.

Similarly, any error message starting with ‘Assertion failed’ is a bug in PuTTY. Please report it to us, and include the exact text from the error message box.

10.8 ‘Unable to use this private key file’, ‘Couldn't load private key’, ‘Key is of wrong type’

Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) when trying public-key authentication, or given by Pageant when trying to load a private key.

If you see one of these messages, it often indicates that you've tried to load a key of an inappropriate type into PuTTY, Plink, PSCP, PSFTP, or Pageant.

You may have specified a key that's inappropriate for the connection you're making. The SSH-1 and SSH-2 protocols require different private key formats, and a SSH-1 key can't be used for a SSH-2 connection (or vice versa).

Alternatively, you may have tried to load an SSH-2 key in a ‘foreign’ format (OpenSSH or ssh.com) directly into one of the PuTTY tools, in which case you need to import it into PuTTY's native format (*.PPK) using PuTTYgen - see section 8.2.12.

10.9 ‘Server refused our public key’ or ‘Key refused’

Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) when trying public-key authentication.

If you see one of these messages, it means that PuTTY has sent a public key to the server and offered to authenticate with it, and the server has refused to accept authentication. This usually means that the server is not configured to accept this key to authenticate this user.

This is almost certainly not a problem with PuTTY. If you see this type of message, the first thing you should do is check your server configuration carefully. Also, read the PuTTY Event Log; the server may have sent diagnostic messages explaining exactly what problem it had with your setup.

10.10 ‘Access denied’, ‘Authentication refused’

Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) during authentication.

If you see one of these messages, it means that the server has refused all the forms of authentication PuTTY has tried and it has no further ideas.

It may be worth checking the Event Log for diagnostic messages from the server giving more detail.

This error can be caused by buggy SSH-1 servers that fail to cope with the various strategies we use for camouflaging passwords in transit. Upgrade your server, or use the workarounds described in section 4.20.1 and possibly section 4.20.2.

10.11 ‘Incorrect CRC received on packet’ or ‘Incorrect MAC received on packet’

This error occurs when PuTTY decrypts an SSH packet and its checksum is not correct. This probably means something has gone wrong in the encryption or decryption process. It's difficult to tell from this error message whether the problem is in the client or in the server.

A known server problem which can cause this error is described in question A.7.16 in the FAQ.

10.12 ‘Incoming packet was garbled on decryption’

This error occurs when PuTTY decrypts an SSH packet and the decrypted data makes no sense. This probably means something has gone wrong in the encryption or decryption process. It's difficult to tell from this error message whether the problem is in the client or in the server.

If you get this error, one thing you could try would be to fiddle with the setting of ‘Miscomputes SSH2 encryption keys’ on the Bugs panel (see section 4.20.5).

Another known server problem which can cause this error is described in question A.7.16 in the FAQ.

10.13 ‘PuTTY X11 proxy: various errors’

This family of errors are reported when PuTTY is doing X forwarding. They are sent back to the X application running on the SSH server, which will usually report the error to the user.

When PuTTY enables X forwarding (see section 3.4) it creates a virtual X display running on the SSH server. This display requires authentication to connect to it (this is how PuTTY prevents other users on your server machine from connecting through the PuTTY proxy to your real X display). PuTTY also sends the server the details it needs to enable clients to connect, and the server should put this mechanism in place automatically, so your X applications should just work.

A common reason why people see one of these messages is because they used SSH to log in as one user (let's say ‘fred’), and then used the Unix su command to become another user (typically ‘root’). The original user, ‘fred’, has access to the X authentication data provided by the SSH server, and can run X applications which are forwarded over the SSH connection. However, the second user (‘root’) does not automatically have the authentication data passed on to it, so attempting to run an X application as that user often fails with this error.

If this happens, it is not a problem with PuTTY. You need to arrange for your X authentication data to be passed from the user you logged in as to the user you used su to become. How you do this depends on your particular system; in fact many modern versions of su do it automatically.

10.14 ‘Network error: Software caused connection abort’

This error occurs when the Windows network code decides that your network connection is dead. For example, it will happen if you pull the network cable out of the back of an Ethernet-connected computer, or if Windows has any other similar reason to believe the entire network has become unreachable.

We are not aware of any reason why this error might occur that would represent a bug in PuTTY. The problem is between you, your Windows system, your network and the remote system.

10.15 ‘Network error: Connection reset by peer’

This error occurs when the machines at each end of a network connection lose track of the state of the connection between them. For example, you might see it if your SSH server crashes, and manages to reboot fully before you next attempt to send data to it.

However, the most common reason to see this message is if you are connecting through a firewall or a NAT router which has timed the connection out. See question A.7.10 in the FAQ for more details. You may be able to improve the situation by using keepalives; see section 4.13.4 for details on this.

10.16 ‘Network error: Connection refused’

This error means that the network connection PuTTY tried to make to your server was rejected by the server. Usually this happens because the server does not provide the service which PuTTY is trying to access.

Check that you are connecting with the correct protocol (SSH, Telnet or Rlogin), and check that the port number is correct. If that fails, consult the administrator of your server.

10.17 ‘Network error: Connection timed out’

This error means that the network connection PuTTY tried to make to your server received no response at all from the server. Usually this happens because the server machine is completely isolated from the network, or because it is turned off.

Check that you have correctly entered the host name or IP address of your server machine. If that fails, consult the administrator of your server.

How do I use sprintf() function in a perl script under Linux or UNIX?

perl printf() function is use to format and print data on screen.

You need to use sprintf to print or store formatted data/string to a variable or to a string.

Also note that Perl does its own sprintf formatting–it emulates the C function sprintf, but it doesn’t use it (except for floating-point numbers, and even then only the standard modifiers are allowed). As a result, any non-standard extensions in your local sprintf are not available from Perl.

perl printf() example

Following statement will round number to 2 digits after decimal point (type at shell prompt):
$ perl -e '$num=53535.35353535;printf ("Result = %.2f\n",$num);'

perl sprintf() example

Type following at shell prompt:

$ perl -e '$num=53535.35353535;$result=sprintf("Result = %.2f\n",$num);print "$result"'

If you need to store output to a string / variable called $result you need to use sprintf(). Here is a small script to make you idea more clear:

#!/usr/bin/perl
$num=585858.64645;
$result = sprintf("%.2f", $num);
$now=sprintf("Today is ".`date`);
print "$result\n";
print "$now\n";

How to use unrar

unrar command supports various options below are common options that you need to use everyday.

Task: To open rar (unpack) file in current directory type command:

$ unrar e file.rar

Please note that replace file.rar filename with your actual filename.

Task: List (l) file inside rar archive:

$ unrar l file.rar

Task: To extract (x) files with full path type command:

$ unrar x file.rar

(D) To test (t) integrity of archive, file type command:
$ unrar t file.rar

Install unrar command

Under Debian Linux, you need to type apt-get as follows to install unrar program:
# apt-get install unrar

If you are using Fedora core Linux then use yum command as follows (see discussion below):
# yum install unrar

If you are using FreeBSD, use:
# pkg_add -v -r unrar

If any of above, methods is not working for you, download binary package from official rarlab site:
$ cd /tmp
$ wget http://www.rarlab.com/rar/rarlinux-3.6.0.tar.gz

Untar file
$ tar -zxvf rarlinux-3.6.0.tar.gz

Both unrar and rar commands are located in rar sub-directory. Just go to rar directory:
$ cd rar
$ ./unrar

Now copy rar and unrar to /bin directory:
# cp rar unrar /bin

puzzles

Apples delivery

The distance between the towns A and B is 1000 miles. There is 3000 apples in A, and the apples have to be delivered to B. The available car can take 1000 apples at most. The car driver has developed an addiction to apples: when he has apples aboard he eats 1 apple with each mile made. Figure out the strategy that yields the largest amount of apples to be delivered to B.

Generalize the strategy for an arbitrary amount of apples.

Zen problem

A Buddhist monk got an errand from his teacher: to meditate for exactly 45 minutes. He has no watch; instead he is given two inscent sticks, and he is told that each of those sticks would completely burn in 1 hour. The sticks are not identical, and they burn with variant yet unknown rates (they are hand-made). So he has these two inscent and some matches: can he arrange for exactly 45 minutes of meditation?

Recovering Permanently Deleted Mails :

Procedure

1: Go to Run & type regedit.

2: Go to hkey_local_machine\software\microsoft\exchange\client\options.

3: right click on the right hand side & choose new dword value & name the key to DumpsterAlwaysOn It is case sensitive.

4: Then right click & select ‘modify’ & make the value 1 to turn the recover deleted items menu choice on for all the folders or enter 0 to turn it off.

5: Then go to Outlook, & choose”Recover deleted items” option from the tools menu to get back your permanently deleted” mails.

Note: this procedure can recover mails which were deleted by pressing shift+del in the past 4 days.

SEARCH ENGINES

THE MYTH

It is a myth among web designers that with the right meta tags you can make it to the top on all search engines.
The truth is close to being the opposite.

With the wrong meta tags you can make it to the bottom,
but meta tags alone do not take you to the top anywhere.

THE ABUSE

Two meta tags have special relevance for search engines: Description and Keywords.

When search engines first started to look for these meta tags, the intention was that web designers could emphasize what the pages were about. For example, a scientific page about the surface of the moon might not have the word "moon" on it, although the page definately related to the topic "moon".

Creative minds didn't take long to find out that this could be an excellent tool for improving search rankings. Many webmasters included keywords and descriptions that held no relevance to their page.

THE STRIKE BACK

After some time, the meta tags did not serve the purpose they were intended for. Most were being used for spamming. Therefore, some search engines, such as Excite, stopped looking at them entirely.

Other search engines, such as Infoseek, directed the spammers weapons back at them. They simply ranked sites lower if the meta tags included words that were not present in the content of the page.

THE CONCLUSION

• Use meta tags with care.


• Do not include words that are not present on your pages.


• Do not repeat words.


• Use the meta tags the way they were intended, because the search engines are well aware that meta tags are an excellent filter for spam sites.

Let's proceed to the details about the tags.

---

DESCRIPTION

name="DESCRIPTION" content="AN HTML Tutorial">

Most search engines will display the description when they list results from a search.
If you do not include this tag, then the engine will simply list the first words on the page - which is not always very meaningful.

---

KEYWORDS

name="KEYWORDS" content="html, webdesign, javascript">

This meta tag was intended to be used for keywords with special relevance for the page.
But because of misuse, many engines skip them. Others use them as an indicator of whether a page is spam or not.
The few that use them to indicate what the page is really about, do not value them as much as they used to.

---

OTHER TAGS

Many HTML editors create a meta tag telling which program was used for the page.

name="GENERATOR" content="Frontpage 3.0">

---

Another common tag tells who created the page:

name="AUTHOR" content="Bill Gates">

---

Finally there are some meta tags that are only relevant to certain search engines.

Individual search engines will recognize different tags telling it when to come back and re-index the site etc.

Look at the help sections for particular search engines to see which meta tags are supported.

Server error messages, the bane of web developers everywhere.

Intro

One of the biggest problems with developing dynamic content for your site, is when things go wrong. Most of the error messages displayed in the browser don't really give any useful information about what the error actually is, or how to fix it.
Believe it or not, but that's usually on purpose. Think about it, if your script gave a big error message detailing all manner of things about your server, like file paths, permissions or database settings, would you really want just anybody to be able to see it?

So where does that leave you? well we are going to discuss some of the common error messages, and what hints they give us with regards to fixing them.
The first 3 error messages detailed here are actually related and often relate to the same common problems. These messages, or variations of them can come from any script based server side language, be it Perl, PHP, Pythod or something else. Most of these error messages are generated by the web server software so they are not really language specific.

If you are going to be dealing with lots of scripts, and you don't have access to your server error log, it is to find yourself a new host that does give you that access. It may not sound like a big thing, but having access to a server error log can save you hours upon hours of time debugging. Good luck!

Click your server error message for an explanation.

:- Premature end of script headers:

:- Internal Server Error:

:- 500 internal server error:

:- The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:

:- Can't locate XX.pm in @INC (@INC contains: /foo /bar) at:

:- perl: warning: Setting locale failed.

:- MySQL: Access denied for user: 'foo@baa' (Using password: YES)

:- MySQL: Can't open file: 'foo.MYD'. (errno: 145)

:- MySQL: Notice: Undefined index: foo

:- MySQL: column count doesn't match value count at row X

:- 403 Forbidden You don't have permission to access /foo/bar.cgi on this server.

---

Premature end of script headers:

The "Premature end of script headers" error message is probably the most loathed and common error message you'll find.
What the error actually means, is that the script stopped for whatever reason before it returned any output to the web server.
A common cause of this for script writers is to fail to set a content type before printing output code. In Perl for example, before printing any HTML it is necessary to tell the Perl script to set the content type to text/html, this is done by sending a header, like so:

print "Content-type: text/html\n\n";

If you don't do that, Perl will try to output to STDOUT (Standard Output, or the servers terminal) instead of through the web server to your browser.
The same applies to any CGI script of any language.

The problem might be the script itself, for example, say you have a formmail type script that is trying to send an e-mail to sendmail on the server, but the path to sendmail in the script is wrong or has passed bad parameters. The script should die at this stage and print an error message to the server error log, saying that it was "unable to open sendmail" or some such error, but you will see an error like "Internal Server error" or "Premature end of script headers" because printing detailed error messages to an unknown users browser is giving to much potentially damaging information away to possibly untrustworthy people.

With Perl there is something you can try that will attempt to redirect error messages to the browser so you can attempt to diagnose the problem.
Open the script in your text editor, and under the path to Perl on the first line, place this:

use CGI::Carp qw(fatalsToBrowser);

Then upload the script again, set it to executable and point your browser at it. If all goes according to plan, the error message will now be printed to the browser for all to see. Fix the error it details, and then comment out (or remove) that line because its never a good idea to give server settings out.

We are sorry, but there is no quick and easy explanation for this error. Simply because all the error really says is "it didn't work". So in short the answer may be simple, but this error message isn't going to tell you what it is. Permissions, ascii & binary file uploading and script configuration (are the required files where the config says they should be?) are the things most likely to cause such an error.
[top]

---

Internal Server Error:

This one is nasty and gives very little information about what is going on. Here is an example.

The example script causing that error above, is a perfectly legit/valid "hello world" script, and I was able to generate this error simply by setting the permission on the file to 700 instead of 755, meaning that only the user owning the file was able to execute it, not the user the web server software runs under.
For more information on server permissions, see here.

Normally, when asked how these errors are caused, my first suggestion (or question in this case) is "what does the server error log say about it?" however in this case, the only error message in the log is: Premature end of script headers: error2.pl so my advice in this case, is that if you get the internal error message the first thing you should do is check your file permissions, after all, if a script can't execute, it can't generate a useful error message. So, first thing to check after getting one of these error messages, is to find your servers error log, (if you don't know where it is, you should ask your hosting provider).
If your error log doesn't provide any useful message, the next thing to do is check your file permissions, scripts should generally have permissions of 755.
The other thing to check is how you uploaded the script, did you upload it as binary or ASCII? if its a script file like Perl, or UNIX shell, or PHP, (by script I mean a program you can open in a text editor and read the code.) you should have uploaded it as a text file (ASCII).
If the file a C or C++ or other compiled program, you should upload it as "binary". Getting that wrong will result in a script that simply will not work, and the only recourse is to delete the file off the server and upload it again with the correct type set.

Lastly is another common problem with script files. end of line characters.
Unfortunately, windows, Unix/Linux/*BSD and Mac all have different return characters, (the characters that denote end of line or "return characters")
This can cause problems because quite often, they are not at all compatable. In particular, windows return characters will often cause a UNIX perl or shell script to die with a relatively useless error message, because the Perl or shell interpreter doesn't know how to "interpret" them.
More often then not, these errors are caused by editing a file on one platform, (like windows) and uploading .the file to a different platform. (like Linux).

The solution is pretty simple really. First get yourself a decent text editor like Textpad.com or Notetab.com. These editors will allow you to change the format of a file between the different variations, or allow you to change them appropriately.
My experience, is that "when in doubt" use the UNIX file format, as it will cause no problems on widows machines and should be good to go with all other variations as well.
[top]

---

500 internal server error:

No difference between this error and the one above, the same recommendations apply. The 500 is just an Apache error code designating an internal server error.
[top]

---

The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:

This one is also not very specific to the problem and can be grouped into the same category as Internal Server Error and Premature end of script headers, basically what they are all telling you is that the script died before it could return anything that the web server could send to the browser. Usually this means the permissions are bad, or the script doesn't have permission to run, or that some misconfiguration in the script has caused it to die with an error before it could return anything useful. The same advice as the above mentioned errors applies here.
[top]

---

Can't locate XX.pm in @INC (@INC contains: /foo /bar) at:

Also shows up as:
"Can't locate XX.pm in @INC. BEGIN failed--compilation aborted."

This one is a pretty simple to explain Perl error. In short, a required module, (code library) that your script needs is not installed or not locatable on the server.
You have a couple of options, one is to have the host install the module. (or at least ask) the second is to install the module in your home directory. (only an option if you have shell access to the server, like Telnet or SSH).
You can find a good tutorial on how to install Perl modules as a user here.
[top]

---

perl: warning: Setting locale failed.

Also shows up as:
"perl: warning: Please check that your locale settings:"

If you are using remote web hosting as opposed to having your own server then there is not that much you can do about this one as it should be fixed by root user system wide. This is not usually a fatal error as there is usually a fallback local that will be used if the configured one is not available. (or if there is no configured one.) If the server is your own, then you need to look into the method by which the server OS configures its locale. For example in Debian Linux you would install and run localeconf. In RHEL or CENTOS you might give editing /etc/sysconfig/i18n a try. The documentation for your OS will tell you what you need to know.
[top]

---

MySQL: Access denied for user: 'foo@baa' (Using password: YES)

Basically a user/password error. The password "YES" doesn't mean that you put yes as a password, it just means that yes a password was given but it was wrong for that user or this database. It says yes instead of giving you the password used incase you are not a person who should see said password.

The solution is pretty simple, check that you have the right database name, and then check your user/password credentials. One of them (or your syntax) will definately be wrong.
[top]

---

MySQL: Can't open file: 'foo.MYD'. (errno: 145)

In the case above, it means that a table called foo in your MySQL database has become corrupted. To repair it you can try running mysqlcheck from the command line in the format: mysqlcheck [options] my_db_name [table_name]
You can also use phpMyAdmin to repair the table if you do not have shell access to the server. Browse to the table in question in phpMyAdmin, select the "Operations" tab and in a box to the right is a "Repair table" option.
[top]

---

MySQL: Notice: Undefined index: foo

Also shows up as:
"Notice: Undefined offset: baa"

You have messed up inserting data into a db somehow, for instance a variable in your SQL that should have a value, doesn't. This happens sometimes when people don't validate user supplied data before putting it into a DB. If you are not sure which one it is try printing the values to screen (or write them to file) rather than putting them in the DB so you can see what their actual values are.
Oh, and always validate user supplied input and don't assume they will have filled out a form (for example) correctly or completely, so you have to check everything they entered before using it. (start looking at regex)
[top]

---

MySQL: column count doesn't match value count at row 1

This is an error message produced by the MySQL database when you pass it a request that doesn't match the output variables that you have provided..
Don has already covered this common error here so I'd rather direct you there then explain it from scratch. :-)
[top]

---

403 Forbidden You don't have permission to access /foo/bar.cgi on this server.

OK, This message can be a permissions problem, but it seems to show up now days more in the context of a mod_security conflict.
ModSecurity is a lovely Apache module designed to help server admins stop nasty people doing nasty things to other peoples webservers. It records and blocks what it considers to be nasty behaviour before it can do any harm.
Sometimes however it blocks programs that really didn't deserve such scrutiny and that is when you'll get the Forbidden You don't have permission to access.... message.

Fortunately it is usually pretty easy to get around this message. (after you have verified why you are getting it.)

All you need to do, is create a file called .htaccess in that directory, and put the following into it.:

SecFilterInheritance Off

Obviously bar.cgi should be replaced by the name of the file you are having troubles with, and it should be saved to the directory containing that file. (in my example here that would be directory /foo).
Assuming that your server is configured to follow htaccess files, you should no longer have a problem. (and if it doesn't work, you'll probably have to ask your host to fix it in the Apache config settings for your account)

I know that ModSecurity can effect the latest versions of Wordpress (The admin front page losses bits due to ModSecurity) and CGI::IRC also has an issue with client-perl.cgi or client.cgi kicking up the error. There are no doubt many more.