In this post I’ll try to walk you through the necessary steps to install phpMyAdmin with Lighttpd in Gentoo.

Installing Lighttpd and PHP

Before installing Lighttpd and PHP you’ll need to enable some USE flags. For Lighttpd you’ll need to at least enable the php and fastcgi USE flags. For PHP enable the cgi, crypt, ctype, pcre, session, unicode. The first one is required for working with Lighttpd, while the others are required for phpMyAdmin.

See the handbook for information about enabling USE flags.

Now install the packages

emerge -av lighttpd php

After installation is complete, start the Lighttpd process

/etc/init.d/lighttpd start

and you should have a working Lighttpd server with PHP support.

Installing phpMyAdmin

phpMyAdmin depends on a package called webapp-config. While usually we let Portage take care of dependencies, this time we’ll have to install webapp-config manually before we install phpMyAdmin, so we can change its configuration for suit Lighttpd.

emerge -av --oneshot webapp-config

After installation is done edit using your favourite editor the /etc/vhosts/webapp-config and change the line:

vhost_server="apache"

to

vhost_server="lighttpd"

Now we are ready to install phpMyAdmin.

emerge -av phpmyadmin

After installation is complete, you’ll need to create a phpMyAdmin configuration file

cp /var/www/localhost/htdocs/phpmyadmin/config.sample.inc.php /var/www/localhost/htdocs/phpmyadmin/config.inc.php

Now open the newly created configuration file and edit the line with the blowfish_secret (at the top of the file) as explained in it. An easy way to generate the password would be to use spass.

Now if you use the default Lighttpd configurations you’re done. You can access the phpMyAdmin via http://localhost/phpmyadmin. If however you’ve changed the document root, there is one more step for you. Enable the mod_alias module in /etc/lighttpd/lighttpd.conf and append to the file

alias.url += ("/phpmyadmin" => "/var/www/localhost/htdocs/phpmyadmin")

and don’t forget to restart the Lighttpd server after making the changes.

You should have by now everything installed and configured to work. If you have any further questions don’t hesitate to comment.

10:41:47 up 5 days, 48 min,  1 user,  load average: 0.82, 0.71, 0.66

the last three numbers are the “load average”. Each number represent the systems load as a moving average over 1, 5 and 15 minutes respectively. Now, the important thing is to understand what is being averaged, the load metric.

The metric that represent the load at a given point in time is how many process are queued for running at each given time (including the process that is currently being ran). Generally speaking, on a single core machine, this can be looked at as CPU utilization percentage when multiplied by 100. For example if I had a load-average of 0.50 in the last minute, this means that over the last minute half of the time the CPU was idle as it had no running process. On the other hand if I had load average of 2.50 it means that over the last minute an average of 1.5 process were waiting to their turn to run. so the CPU was overloaded by 150%.

On a multi-core systems things are a bit different, but in order to avoid unnecessary complications one can usually divide the load-average by the number of cores an treat the result as the load average of single core machine. For example let’s say the load average of a two-core machine was 3.00 2.00 0.50. This means that over the last minute we had an average of three runnable process, this means that one process, in average, was queued as there are two core in the machine that can run to process at a time. So the machine was overloaded had a load of 150% its capability. Over the last 5 minutes the load average of 2.00 means that we roughly had 2 process running each time, so the machine was fully utilized but wasn’t overloaded by work. On the other hand over last 15 minutes the load-average of 0.50 means that we could handle 4 time that load without overloading the CPU, we only had (0.50/2)*100=25% CPU utilization in that 15 minutes.

I hope I made the load-average a bit more clearer using the above example. Load-average is an important metric for measuring a system performance, and good understanding of it is beneficial.

The first step is to install ctags (if you haven’t got it already installed), this provides the tags file, on which the autocompletion is based. ctags is available directly from the package manager of all popular distro’s.

The next step is to install the OmniCppComplete plugin for vim. The plugin uses the ctags‘ generated tags file for the autocompletion. In order for the autocompletion to properly work with classes, you need to create the ~/.ctags file and add some default options. Each option should be listed in a newline. Your ~/.ctags file should look like this:

--c++-kinds=+p
--fields=+iaS
--extra=+q

These options will now be used as default when running ctags.

The next step is to create a tag file for the wxWidgets library. This can be done using the following command:

 ctags -f ~/.vim/wxwidgetstags -R /usr/include/wx-2.8

Don’t forget to replace /usr/include/wx-2.8 with the path to the header files of wxWidgets. This will create the tags file under your ~/.vim directory.

The next step is to tell vim to use this tags file. This is done by adding the following line to your ~/.vimrc:

:set tags+=~/.vim/wxwidgetstags

And now your done. OmniComplete will now work for wxWidgets, listing members and functions for any of the wxWidgets classes.
Remember you can repeat the last two steps for any other libraries you use in order for the OmniComplete to work with them too.

N.B. don’t forget to run ctags -R . in your projects root dir if you want OmniComplete to work for classes you defined.

Creating the repository

We will start by creating the repository. From the command line do the following:

$ mkdir /home/user/svnrep
$ cd ~/svnrep
$ svnadmin create project1

In the first line we create a directory to house all of your repositories (I assume you are working under the username “user”). I prefer to use different repositories for different projects that are unrelated, no matter how small they are. Because I use many repositories, I prefer to have a single directory underneath all repositories will reside in an organized way (i.e. no junk files or any other kind of stuff except directories). Next thing, is to cd into the directory we created, and actually create the repository using the svnadmin command. To repository we’ve created is called “project1″.

The brand new “project1″ repository is currently empty and in revision 0. This will change once we put some data in it. The first thing you do with a new repository is to import initial project data into it.

$ svn import /home/user/project1 file:///home/user/svnrep/project1/trunk -m "Initial import of project1"

Will import the current project1’s file into the repository (assuming that project1 indeed resides in /home/user/project1). The trunk appended to the end of the repository URL, is part of the directory layout convention used by many Subversion users. The last part of the command is the message that will be attached to the import in the SVN log.

Now the repository holds data and you are ready to checkout the code from it, and start working.

Checkout a Working Copy and Start Working

When using SVN (as well as in most revision control systems) you don't work directly on the repository. Instead you checkout a working copy from it, and work on this copy. To checkout a working copy from the repository, use:

$ svn co file:///home/user/svnrep/project1/trunk /home/user/project1_work

This will create a working copy of the repository under /home/user/project1_work. You can edit this copy safely.

After you've done editing your working copy, you will want to commit those changes back to the repository. Assuming you are already inside the directory of the working copy, just do:

$ svn commit -m "Some log message"

This will send you changes back to the repository and store them there. Change the "Some log message" to some useful short description of the changes you've made.

Some Useful Commands

To view a list of log messages that were attached to the operations on the repository, use:

$ svn log
$ svn log -r 5:HEAD

The first command will print all log messages. The second command will print the log messages from revision 5 to the latest revision. You can substitute the HEAD with a number to get the log messages of the revisions up to a specific one.

To view the changes you made before committing your code, use:

$ svn diff

Another important command is the one to update your working copy with the latest revision from the repository. This can be done using:

$ svn update

However, since your are the only user of the local repository, you won't have to use this function often (if at all), unless you use two, or more, working copies for your project.

This concludes this tutorial. I hope you know by now how to create and use, a single user local SVN repository.

Generating Keys

Generating public keys for authentication is the basic and most often used feature of ssh-keygen. ssh-keygen can generate both RSA and DSA keys. RSA keys have a minimum key length of 768 bits and the default length is 2048. When generating new RSA keys you should use at least 2048 bits of key length unless you really have a good reason for using a shorter and less secure key. The key length for DSA is always 1024 bits as specified in FIPS 186-2. Because DSA key length is limited to 1024, and RSA key length isn’t limited, so one can generate much stronger RSA keys than DSA keys, I prefer using RSA over DSA. Another reason for not using DSA is that DSA is a government standard and one may wonder if the key length was limited deliberately so it will be possible for government agencies to decrypt it.

To generate a pair of public and private keys execute the following command:
ssh-keygen -t rsa -b 2048
You can use “dsa” instead of the “rsa” after the -t to generate a DSA key. The number after the -b specifies the key length in bits.

After executing the command it may take some time to generate the keys (as the program waits for enough entropy to be gathered to generate random numbers). When the key generation is done you would be prompted to enter a filename in which the key will be saved. The public key will have the same filename but it will end with .pub. You should make sure that the key can only be read by you and not by any other user for security reasons.

Next you’ll be prompted to enter a passphrase. Each generated key can be protected by a passphrase. When a key is generated with a passphrase, the key can’t be used without the passphrase, so by using a passphrase one can prevent others from using his private keys without first guessing the passphrase. A good passphrase should be at least 10 characters long. One should stay away from English sentences as their entropy level is just too low to be used as a safe passphrase. I usually use a randomly generated passphrase, as this kind is considered the most secure. If you intend to use the key for accessing a remote machine from inside an automated script you may wish to enter an empty password, so the script won’t need user interaction. In this case just press <ENTER> twice.
If you create a passphrase-less key just make sure you only put it on trusted hosts as it may compromise the remote machine if the key falls to the wrong hands.

After entering you passphrase twice the program will print the key fingerprint, which is some kind of hashing used to distinguish different keys, followed by the default key comment (more on key comments later). After printing the key information the program will terminate. Congratulations, you’ve just created you own public key using ssh-keygen.

Comments

Adding comments to keys can allow you to organize your keys more easily. The comments are stored in end of the public key file and can be viewed in clear text. For example:

cat id_rsa2.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyyA8wePstPC69PeuHFtOwyTecByonsHFAjHbVnZ+h0dpomvLZxUtbknNj3+c7MPYKqKBOx9gUKV/diR/mIDqsb405MlrI1kmNR9zbFGYAAwIH/Gxt0Lv5ffwaqsz7cECHBbMojQGEz3IH3twEvDfF6cu5p00QfP0MSmEi/eB+W+h30NGdqLJCziLDlp409jAfXbQm/4Yx7apLvEmkaYSrb5f/pfvYv1FEV1tS8/J7DgdHUAWo6gyGUUSZJgsyHcuJT7v9Tf0xwiFWOWL9WsWXa9fCKqTeYnYJhHlqfinZRnT/+jkz0OZ7YmXo6j4Hyms3RCOqenIX1W6gnIn+eQIkw== This is the key's comment

As you can see the comment is appended in clear text to the end of the public key file. To alter the comment just edit the public key file with a plain text editor such as nano or vim.
To add a comment to the public key file when generating the key add to the key generation command -C "you comment". For example to generate 4048 bit RSA key with “home machine” as a comment you will do the following:

ssh-keygen -b 4048 -t rsa -C "home machine"

Notice that each copy of a public key can have its own comment and you cannot retrieve the comment from the private key.

Passphrases

Passphrases allow you to prevent unauthorized usage of your key by meaning of protecting the key itself by a password. Although your ssh directory holding the private keys should be unaccessible to other users, the root user of the system, or anyone who can achieve is privileges can access your key and copy it. In this case the passphrase will prevent him from using it.

To add a passphrase to a key just type it when prompted during the key generation process. Keep in mind that the password must be at least 5 characters long. A good passphrase, as I said before, should be at least 10 characters long, and consist of random upper and lower case letters, numbers and symbols.

While the passphrase boosts the security of the key, under some conditions you may want to leave it empty. Leaving the passphrase empty allows you to use the key from within scripts, for example to transfer a file via scp. While passphraseless keys are very useful for scripts just remember to only use them at trusted machines.

You can change the passphrase of key after it’s been created, and you should do it at least annually. To change the passphrase execute:

ssh-keygen -p

After this you will be prompted to enter the location of your private key and enter twice the new passphrase. If you don’t want a passphrase just enter empty one.

End Notes

Feel free to share your public key, as its name suggests, it should be public. Keep in mind that your private key should be kept private. If someone gets hold of your private key, change it imediatly, even if it’s passphrase protected.

int clock_gettime(clockid_t clk_id, struct timespect *tp);

The clk_id allows us to select a specific clock from the several
offered by the system, which includes:

• CLOCK_REALTIME, a system-wide realtime clock.
• CLOCK_PROCESS_CPUTIME_ID, high-resolution timer provided by the CPU for each process.
• CLOCK_THREAD_CPUTIME_ID, high-resolution timer provided by the CPU for each of the threads.

Usually, there are more clocks provided, but I find these three the most useful as they allow to get the execution time spent in the system level, process level and the thread level.

The current clock time, for the chosen clock is stored int the struct provided by the *tp pointer. The timespec struct is defined as follows:

struct timespec {
	time_t tv_sec; /* seconds */
	long tv_nsec; /* nanoseconds */
};

To time the processing time some function took, one should call clock_gettime() twice. Once before the function call and once right after it and subtract the returned timings to get the actual runtime.

Getting the difference between two timespec structs isn’t very complicated and can be acheived using the function diff() defined bellow:

timespec diff(timespec start, timespec end)
{
	timespec temp;
	if ((end.tv_nsec-start.tv_nsec)<0) {
		temp.tv_sec = end.tv_sec-start.tv_sec-1;
		temp.tv_nsec = 1000000000+end.tv_nsec-start.tv_nsec;
	} else {
		temp.tv_sec = end.tv_sec-start.tv_sec;
		temp.tv_nsec = end.tv_nsec-start.tv_nsec;
	}
	return temp;
}

Now let’s move to some real example:

#include <iostream>
#include <time.h>
using namespace std;
 
timespec diff(timespec start, timespec end);
 
int main()
{
	timespec time1, time2;
	int temp;
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1);
	for (int i = 0; i< 242000000; i++)
		temp+=temp;
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time2);
	cout<<diff(time1,time2).tv_sec<<":"<<diff(time1,time2).tv_nsec<<endl;
	return 0;
}
 
timespec diff(timespec start, timespec end)
{
	timespec temp;
	if ((end.tv_nsec-start.tv_nsec)<0) {
		temp.tv_sec = end.tv_sec-start.tv_sec-1;
		temp.tv_nsec = 1000000000+end.tv_nsec-start.tv_nsec;
	} else {
		temp.tv_sec = end.tv_sec-start.tv_sec;
		temp.tv_nsec = end.tv_nsec-start.tv_nsec;
	}
	return temp;
}

To use clock_gettime you need to include time.h and to link to librt.a. If you use gcc just make sure you add -lrt to your list of arguments.

Play a bit with the length of the for loop. As you can see clock_gettime provides much more accurate results and can register very short processing time too. Just remember that as the case with any profiling functions, this function adds a little overhead to your program, so make sure you disable the profiling code, using preprocessor commands for example, in the production release.

26/9/2007 – Update

You may want to take a look at The Revised String Iteration Benchmark post for another, larger, example of using clock_gettime to time performance of code.

Processing forms is the basic function of any CGI script and the main purpose of CGIs. As you probably know there are two common ways to send form data back to the web server: “post” and “get”. When form data is sent with the “get” method it is appended to the URL string of the form submission URL. The “post” method is much like the “get” except the data is transmitted via http headers and not via the URL itself. When a form uses “get” it allows the user to easily bookmark the query created by the form as the data is transmitted in URL itself, on the other hand the “post” method allows to send much more data and spares to user from seeing the data in the URL.

Getting the “post” and “get” data is relatively easy. To get the data sent by “get” you can just call getenv("QUERY_STRING") and you will receive a pointer to null-terminated string containing the “get” data. Reading the “post” data is a bit more complicated. The data needs to be read from the standard input, but the program won’t receive an EOF when it reaches the end of the data but instead it should stop reading after reading a specified amount of bytes, which is defined in the environment variable “CONTENT_LENGTH“. So you should read getenv("CONTENT_LENGTH") bytes from the standard input to receive the “post” data.

But here it’s get tricky. The data is received in an encoded way. The data for both “post” and “get” is a string in the form of “var1=value1&var2=value2&var3=value3” and so on, where the “var*” is the names of the submitted form elements and “value*” is their values respectively. And now it gets a bit more tricky, both the elements’ names and values are url-encoded. That means that almost every non alphanumeric character will be encoded as %XX, where XX represents its ASCII value (see the linked Wikipedia article for more information and extra reading). So to sum up the process of processing forms in CGI you should do the following:

1. Get the data (either by “post” or “get”).
2. Parse the data to get key-value pairs.
3. Decode the url-encoded key-value pairs.
4. Process the data.

Getting the first and last step done is easy. The second and third step require some work, but fortunately when done properly they should only have to be done once, as you will create functions/classes to handle those, so it is really only a one time job. That leaves you only to do yourself the first and last steps.

As I said the second and third steps are troublesome only when not done before. Here is an implementation for those steps that I’ve written as a part of (yet unreleased) CGI library for C++. It implements functions that take the care of the first three steps and return to the user an STL map containing the form elements’ names in the key and their value in the map pair’s value. This functions allows to process forms in a similar way to processing forms in PHP using $_GET and $_POST.

Here is a simple example of processing a “get” form using the above getpost.h header file.

#include <iostream>
#include <string>
#include <map>
#include "getpost.h"
 
using namespace std;
 
int main()
{
	map<string,string> Get;
	initializeGet(Get); //notice that the variable is passed by reference!
	cout<<"Content-type: text/html"<<endl<<endl;
	cout<<"<html><body>"<<endl;
	cout<<"<h1>Processing forms</h1>"<<endl;
	cout<<"<form method=\"get\">"<<endl;
	cout<<" <label for=\"fname\">First name: </label>"<<endl;
	cout<<" <input type=\"text\" name=\"fname\" id=\"fname\"><br>"<<endl;
	cout<<" <label for=\"lname\">Last name: </label>"<<endl;
	cout<<" <input type=\"text\" name=\"lname\" id=\"lname\"><br>"<<endl;
	cout<<" <input type=\"submit\" />"<<endl;
	cout<<"</form><br /><br />"<<endl;
 
	if (Get.find("fname")!=Get.end() && Get.find("lname")!=Get.end()) {
		cout<<"Hello "<<Get["fname"]<<" "<<Get["lname"]<<", isn\'t "
			"processing CGI forms with C++ quite easy?"<<endl;
	} else {
		cout<<"Fill up the above from and press submit"<<endl;
	}
	cout<<"</body></html>"<<endl;
 
	return 0;
}

While this is a simple example, it’s enough to demonstarte how stuff is done. The same way you can process the “post” variables. Feel free to take a look at the getpost.h source-code to see how the URL decoding and the other implementation aspects were done.

Update 2009-09-18: There was a bug in getpost.h, see my comment bellow.

cout<<"Content-type: text/html"<<endl<<endl;

So getting back to our “Hello World” CGI, it will look like this:

#include <iostream>
using namespace std;
int main()
{
	cout<<"Content-type: text/plain"<<endl<<endl;
	cout<<"Hello World!"<<endl;
 
	return 0;
}

Congratulations! You have just created your first C++ CGI. To see it in action, move it to a directory on the web server configured to run CGI scripts, this directory is usually called cgi-bin. Now just point your web browser to the the address of CGI app to see in in action.

Now that you have seen the basic example, let’s move on to a bit more complex example.

#include <iostream>
using namespace std;
 
int main()
{
	cout<<"Content-type: text/html"<<endl<<endl;
	cout<<"<html><body>"<<endl;
	cout<<"<h1>Hello World!</h1>"<<endl;
	cout<<"This is HTML formatted Hello World C++ CGI"<<endl;
	cout<<"</body></html>"<<endl;
 
	return 0;
}

As you see, even writing pages with HTML content isn’t that hard. Yes, C++ may not be the easiest programming language for developing web applications, but it may turn out easier than you thought.

In this post I covered creating basic CGI that don’t relay on user input. As proccessing user input in one of the goals of CGI, I will cover it next time.