Control the MaxClients setting in Apache
A webserver should never ever have to swap, as swapping increases the latency of each request.
You can, and should, control the MaxClients* setting so that your server does not spawn so many children it starts swapping. This procedure for doing this is simple: determine the size of your average Apache process, by looking at your process list via a tool such as top, and divide this into your total available memory, leaving some room for other processes.
*MaxClients [Maximum number of connections that will be processed simultaneously]
CPAN - query, download and build perl modules from CPAN sites
Interactive mode:
Batch mode:
use CPAN;
autobundle, clean, install, make, recompile, test
Example:
root@laptop:~# perl -MCPAN -e shell
Terminal does not support AddHistory.
cpan shell -- CPAN exploration and modules installation (v1.9205)
ReadLine support available (maybe install Bundle::CPAN or Bundle::CPANxxl?)
cpan[1]> test
CPAN: Storable loaded ok (v2.18)
CPAN: LWP::UserAgent loaded ok (v5.819)
CPAN: Time::HiRes loaded ok (v1.9711)
I would like to connect to one of the following sites to get ‘authors/01mailrc.txt.gz’:
http://www.perl.org/CPAN/
ftp://ftp.perl.org/pub/CPAN/
Is it OK to try to connect to the Internet? [yes]
Source: Man Page - http://theoryx5.uwinnipeg.ca/CPAN/perl/lib/CPAN.html
How to install missing perl modules.
What is CPAN?
CPAN is the Comprehensive Perl Archive Network, a large collection of Perl software and documentation. You can begin exploring from either http://www.cpan.org/, http://www.perl.com/CPAN/ or any of the mirrors listed at http://www.cpan.org/SITES.html.
Note that CPAN is also the name of a Perl module, CPAN.pm, which is used to download and install Perl software from the CPAN archive. This FAQ covers only a little about the CPAN module and you may find the documentation for it by using perldoc CPAN via the command line or on the web at http://search.cpan.org/dist/CPAN/lib/CPAN.pm
Cpan is the easiest method to install new perl modules.
perl -e shell -MCPAN
install Bundle::DBD::mysql
hdparm provides a command line interface to various kernel interfaces supported by the Linux SATA/PATA/SAS “libata” subsystem and the older IDE driver subsystem.
hdparm [ flags ] [device]
-T Perform timings of cache reads for benchmark and comparison purposes. For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory. This displays the speed of reading directly from the
Linux buffer cache without disk access. This measurement is essentially an indication of the throughput of the processor, cache, and memory of the system under test.
root@desktop:~#hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 2254 MB in 1.99 seconds = 1131.64 MB/sec
-t Perform timings of device reads for benchmark and comparison purposes. For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory. This displays the speed of reading through the buffer cache to the disk without any prior caching of data. This measurement is an indication of how fast the drive can sustain sequential data reads under Linux, without any filesystem overhead. To ensure accurate measurements, the buffer cache is flushed during the processing of -t using the BLKFLSBUF ioctl.
root@desktop:~# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 118 MB in 3.01 seconds = 39.16 MB/sec
SSH Public key authentication
SSH Public key authentication works as follows:
The scheme is based on public-key cryptography, using cryptosystems where encryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. The idea is that each user creates a public/private key pair for authentication purposes.
The server knows the public key, and only the user knows the private key. ssh implements public key authentication protocol automatically, using either the RSA or DSA algorithms. Protocol 1 is restricted to using only RSA keys, but protocol 2 may use either. The HISTORY section of ssl(8) contains a brief discussion of the two algorithms.
The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account.
The user creates his/her key pair by running ssh-keygen(1). This stores the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 2 DSA), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the users home directory.
The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, the user can log in without giving the password.
The most convenient way to use public key authentication may be with an authentication agent. See ssh-agent(1) for more information.
