Innotop is a very useful tool to monitor innodb information in real time. This tool is written by Baron Schwartz who is also an author of “High Performance MySQL, Second edition” book. [Side note: I highly recommend getting this book when it comes out (in June, 08?). Other authors include: Peter Zaitsev, Jeremy Zawodny, Arjen Lentz, Vadim Tkachenko and Derek J. Balling.] Quick summary of what innotop can monitor (from: http://innotop.sourceforge.net/): InnoDB transactions and internals, queries and processes, deadlocks, foreign key errors, replication status, system variables and status and much more.
Following are the instructions on how to install innotop on CentOS x64/Fedora/RHEL (Redhat enterprise). Most probably same instructions can be used on all flavors of Linux. If not, leave me a comment and I will research a solution for you. Let us start with downloading innotop. I used version 1.6.0 which is the latest at the time of writing.
wget http://internap.dl.sourceforge.net/sourceforge/innotop/innotop-1.6.0.tar.gz
Now let us go ahead and unzip and create the MakeFile to get it ready for install
tar zxpf innotop-1.6.0.tar.gz
cd innotop-1.6.0
perl Makefile.PL
At this point if you get the following output, you are good to continue:
Checking if your kit is complete...
Looks good
Writing Makefile for innotop
If you get something similar to following, you will need to take care of the prerequisites:
Looks good
Warning: prerequisite DBD::mysql 1 not found.
Warning: prerequisite DBI 1.13 not found.
Warning: prerequisite Term::ReadKey 2.1 not found.
Writing Makefile for innotop
Just because they are warnings does not mean you ignore them. So let us install those prerequisites. We will use perl’s cpan shell to get this installed (visit my post on how to install perl modules for more details). If it is your first time starting this up, you will have to answer some questions. Defaults will work fine in all cases.
perl -MCPAN -eshell
install Term::ReadKey
install DBI
install DBD::mysql
Note: you must install DBI before you can install DBD::mysql.
If you get an error like following when you are installing DBD::mysql:
Error: Can't load '/root/.cpan/build/DBD-mysql-4.007/blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: libmysqlclient.so.15: cannot open shared object file: No such file or directory at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230.
You will have to create a symlink to the object file in your lib64 (or lib if you are not using x64 version) folder:
ln -s /usr/local/mysql/lib/mysql/libmysqlclient.so.15 /lib64/
Once all prerequisites are done, type perl Makefile.PL and you should have no warnings. Continue the install:
make install
At this point you should have innotop installed on your system. Let us do some quick set up so you can start using innotop. We start with configuring your .my.cnf to include connection directives.
vi ~/.my.cnf
Add the following (edit to reflect your install) and save/exit
[mysql]
port = 3306
socket = /tmp/mysql.sock
Start up innotop by typing innotop at your shell prompt. First prompt will ask you to “Enter a name:”. I just put localhost since this will be used to connect locally. Next prompt asks you about DSN entry. I use: DBI:mysql:;mysql_read_default_group=mysql
This tells innotop to read .my.cnf file and use group [mysql] directives. Next prompt is optional (I just press enter). Next two prompts you enter information if you need to.
At this point your innotop installation / testing is complete. You can read man innotop to get more details on how to use innotop.
Thứ Ba, 30 tháng 3, 2010
Thứ Ba, 16 tháng 3, 2010
Multiple PHP Instances With One Apache
Long-winded Introduction
It took me a couple of days to figure this out due to lack of decent tutorials and not enough confidence in my Linux skills to build programs from source. I think I have the hang of it now, and write this up with the intent on providing another, or the only, tutorial on setting up CentOS 5 with multiple instances of PHP using one Apache install. That being said, there are a number of good tutorials out there, just none of them explicitly for CentOS and some leave out some details that n00bs like me get confused about.
PHP4 and PHP5 on SuSE 10.1 – This was by far the most helpful of the tutorials. Even though it was written for SuSE, it works almost straight across for CentOS.
There is also a great list of instructions in the comments on the php.net site under installing PHP for Apache 2.0 on Unix systems (see http://www.php.net/manual/en/install.unix.apache2.php#90478).
I found this one after I wrote up this tutorial at http://cuadradevelopment.com. It’s a bit different, but should work as well.
There are basically two different ways I could have done this. 1- run a single instance of Apache, and run one instance of PHP as a module, and other installs as CGI. 2- run several instances of Apache, each with it’s own instance of PHP as a module. I chose to do the first method for no particular reason. Dreamhost has a post about the good and bad with running PHP as CGI.
So basically, the steps are: 1. Set up Apache and have PHP install as a module. 2. Configure and make another instance of PHP to run as CGI. 3. Add a virtual host to Apache running under a different port to access the PHP as CGI.
Set up Apache with PHP module
So here’s what I did to get the basic Apache, PHP and MySQL working. This sets up the first PHP install to run as a module in Apache:
From a clean install of CentOS 5 (virtually no packages selected during initial install), I installed the following packages:
$ yum install gcc make subversion ImageMagick php php-cli php-common php-ldap php-mysql php-pdo php-pear php-devel bzip2-devel libxml2-devel mysql mysql-server mysql-devel mod_auth_mysql httpd httpd-manual
From there I needed to get PHP 5.2.x, so I did the following to get PHP, Apache, MySQL and PEAR all set up.
1. Step 1: GET PHP 5.2.x
Check out instructions and packages here: http://blog.famillecollet.com/pages/Config-en
$ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm
$ wget http://rpms.famillecollet.com/el5.i386/remi-release-5-4.el5.remi.noarch.rpm
$ rpm -Uvh remi-release-5.rpm epel-release-5.rpm
$ yum—enablerepo=remi update php-pear php
Copy the /etc/php.ini file from the /etc/php.ini.default:
$ cp /etc/php.ini.default /etc/php.ini
Change the following lines:
* 1. upload_max_filesize = 20M #line 573
* 2. mysql.default_socket =/path/to/mysql/mysql.sock #about line 736
* 3. mysqli.default_socket =/path/to/mysql/mysql.sock #about line 771
2. Step 2: Edit /etc/httpd/conf/httpd.conf by changing the following lines
* 1. Listen xxx.xxx.xxx.xxx:80 #line 134
* 2. ServerAdmin admin@email.org #line 251
* 3. ServerName somesite.org #line 265
* 4. DocumentRoot ”/path/to/htdocs” #line 282
* 5. #line 307
* 6. AllowOverride All #line 328
* 7. DirectoryIndex index.php index.html index.html.var #line 392
3. Step 3: Create the /etc/my.cnf file for MySQL
[mysqld]
datadir=/path/to/mysql
socket=/path/to/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
[client]
socket=/path/to/mysql/mysql.sock
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
4. Step 4: Start apache and mysql and set them to start on boot up:
$ service httpd start
$ service mysqld start
$ chkconfig mysqld on
$ chkconfig httpd on
5. Step 5: Set the MySQL password for root
$ mysqladmin -u root password ‘XXXXXX’
6. Step 6: install Phing and other PEAR packages
$ pear channel-discover pear.phing.info
$ pear channel-discover pear.phpunit.de
$ pear install phing/phing
$ pear install PhpDocumentor
$ pear install XML_Beautifier
$ pear install PHPUnit
$ pecl install Xdebug
Configure second version of PHP
From here we need to install a second version of PHP. Grab the version you want from http://www.php.net/releases/, and stick that any where you want to (usually your root’s home directory is fine). I’m installing PHP 5.2.4, so I’ll use that in my examples.
Unpack the tarball and enter the directory it created.
$ tar -xjf php-5.2.4.tar.bz2
Now, you’ll need to determine which modules you need to install. For this part I used the steps from the php.net comment under “my approach for determining required modules” (copied here, without permission, but with lots of gratitude and full credit going to the author of the comment).
my approach for determining required modules
------------------------------------
1. get the list of the modules
$ php -m | grep -v -e Modules] -e ^$ > php-default-modules
2. create the configure script
$ for i in $(cat php-default-modules); do echo -n "--with-$i ">> phpconfigure.sh ;done
2.2 add #!/bin/bash to the top line, and ./configure to the second line.
Each of the --with-* need to be on the second line.
3. run the configure script, and iterate through the "Configure script errors"
section below until it completes properly
$ ./phpconfigure.sh
4. at the end of the output, look for a notice of unknown options
Notice: Following unknown configure options were used:
--with-date
--with-gum-disease
Check './configure --help' for available options
5. as suggested, execute '$ ./configure --help' and correct the options. The
"for" command above indiscriminately inserts "--with-" for all modules,
but bundled modules may require "--enable-" instead, so mostly you'll
be changing those. For modules that are enabled by default you'll need
to remove the entry.
6. Add anything else you personally want or need. I like to add "--enable-safe-mode".
After doing all of that, I had the following in phpconfigure.sh
#!/bin/bash
./configure –prefix=/usr/share/ –datadir=/usr/share/php –libdir=/usr/share –includedir=/usr/include –bindir=/usr/bin –enable-safe-mode –with-config-file-path=/etc/php542 –enable-force-cgi-redirect –enable-discard-path –with-bz2 –enable-calendar –with-curl –enable-dbase –enable-exif –enable-ftp –with-gettext –with-gmp –with-iconv –with-ldap –with-libxml-dir=/usr/lib/ –enable-mbstring –with-mime_magic –with-mysql –with-mysqli –with-openssl –enable-pcntl –with-pcre-dir=/usr/lib/ –with-pdo_mysql –with-pdo_sqlite –with-readline –enable-shmop –enable-sockets –with-SQLite –enable-wddx –with-xsl –enable-zip –with-zlib
# Changes from what php -m spits out. You don’t need the info below in your phpconfigure.sh script
#–enable-calendar
#–with-ctype # default
#–with-date # not found, default?
#–enable-dbase
#–with-dom # default
#–enable-exif
#–with-filter #default
#–with-ftp
#–with-hash #default
#–with-json #default
#–with-libxml-dir=/usr/lib/
#–enable-mbstring
#–with-memcache #not found, default?
#–enable-pcntl
#–with-pcre-dir=/usr/lib/
#–with-PDO #taken care of with the pdo_mysql and pdo_sqlite
#–with-Reflection #default
#–with-session #default
#–enable-shmop
#–with-SimpleXML #default
#–enable-sockets
#–with-SPL #default
#–with-standard #not found, is it SPL? default?
#–with-tokenizer #default
#–enable-wddx
#–with-xdebug #not found, not needed
#–with-xml #default
#–with-xmlreader #default
#–with-xmlwriter #default
#–enable-zip
#–with-Xdebug #not found, not needed
NOTE: make sure you do not include ‘–with-apxs2=/usr/sbin/apxs’. This is what installs PHP as an Apache module. Also, since you have the original PHP running, you can theoretically make a phpinfo file (with phpinfo() ) in it, and grab the configure entries from that, making sure to change ‘–with-config-file-path=/etc’ ‘–with-config-file-scan-dir=/etc/php.d’
During the configure, you might run into some errors. Again from the php.net comment:
Configure script errors
--------------------------------------------
In my experience, these errors have been due (with any software, PHP included) mostly to missing
development packages, which contain the libraries and headers needed to compile support for that
library's function into the application.
This becomes a process of:
-executing the ./configure script and looking at the error
-installing the devel package providing the resource referenced by the error (google using the error
as search term as needed)
-repeat until the ./configure script makes it through without error
Upshot: identify the software referenced by the error, and install it.
Example
-----------
Example error:
configure: error: Cannot find OpenSSL's
Example explanation
configure is looking for a header (and probably a lot of other stuff) from a missing openssl package.
Example solution:
php-5.2.9]$sudo yum install openssl-devel
The previous yum command should take care of most of those dependencies.
After the phpconfigure script runs without errors, then simply run
$ make
As the JpGraph tutorial explains, there is no need to run “make install”. Just simply copy the php-cgi executable to the proper place. We’ll get to that step shortly.
Set up Apache VirtualHost and website directories
Now you need to create two directories to handle the PHP as CGI. They can be virtually wherever, but should be in the same directory where you have the main html content. So if you set the path to the website data (in the httpd.conf) to /path/to/htdocs/, then you’ll need to make a /path/to/php524/ and a /path/to/php524-cgi/
$ mkdir /path/to/php524/
and
$ mkdir /path/to/php524-cgi/
After you have those directories, you can add the VirtualHost information to the Apache config (httpd.conf). I like to have a separate file for the VirtualHosts, so I added this to the end of the httpd.conf file.
Include conf/XXXXX_vhosts.conf
And to allow VirtualHosts, uncomment this line:
NameVirtualHost *:80
To allow Apache to listen on (or accept requests from) different ports besides the default 80, add another Listen line to the httpd.conf file:
Listen XXX.XXX.XXX.XXX:8524
I used port 8524 to correspond to version 5.2.4 of PHP
Now create the XXXXX_vhosts.conf file
#this doesn’t really seem to be needed, but it’s there
NameVirtualHost *:8524
# this is the original and runs the PHP as a module
DocumentRoot /path/to/htdocs/
ServerName somesite.org
####### Add other Virtual Hosts below here #######
# Setup PHP 5.2.4 on port 8524
DocumentRoot /path/to/php524/
# We use a separate CGI directory
ScriptAlias /cgi-bin/ /etc/php524/
# For good measure we also add recognition of PHP5 index
DirectoryIndex index.php5
# These are the two critical statements for this virtual
# host. This activates PHP 5.2.4 as a CGI module
Action php524-cgi /cgi-bin/php-cgi
AddHandler php524-cgi .php5 .php
#Options None
Options FollowSymLinks
#AllowOverride None
AllowOverride All
Order allow,deny
Allow from all
DirectoryIndex index.html index.php
Now, you need to copy the php-cgi binary/executable to the /path/to/php524-cgi-bin/ directory. The php-cgi file is located in the file where you ran the configure and make for the new php install. So if you did all that in the /opt/php-5.2.4/ directory, the php-cgi will be located at /opt/php-5.2.4/sapi/cgi/php-cgi.
$ cp /opt/php-5.2.4/sapi/cgi/php-cgi /path/to/php524-cgi-bin/
Finally, copy the php.ini file to the right place. And configure as needed.
$ cp /opt/php-5.2.4/php.ini-dist /path/to/php524-cgi-bin/php.ini
Test the apache configs to make sure they work:
$ /usr/sbin/apachectl configtest
If that returns OK restart Apache.
$ /etc/init.d/httpd graceful
You can make a phpinfo page to test that it’s using the new PHP version.
phpinfo();
? >
Then check out your new site: http://somesite.org:8524/phpinfo.php
In order to get the different versions of PHP to interact with MySQL, you’ll have to use the URL on port 80 as the MySQL host. So, for example, in a WordPress install at http://somesite.org:8524/blog, the wp-config.php will have to have the following for the MySQL hostname:
define('DB_HOST', 'dev.omeka.org');
There is some issue with mod_rewrite on the different versions of PHP. I’ll replace this paragraph with a fix when I have one.
UPDATE: 9/9/09 – I figured out how to get the .htaccess working for the Omeka installs we were working with. I needed to change the AllowOverride lines in the vhost.conf (or httpd.conf) file from None, to All.
It took me a couple of days to figure this out due to lack of decent tutorials and not enough confidence in my Linux skills to build programs from source. I think I have the hang of it now, and write this up with the intent on providing another, or the only, tutorial on setting up CentOS 5 with multiple instances of PHP using one Apache install. That being said, there are a number of good tutorials out there, just none of them explicitly for CentOS and some leave out some details that n00bs like me get confused about.
PHP4 and PHP5 on SuSE 10.1 – This was by far the most helpful of the tutorials. Even though it was written for SuSE, it works almost straight across for CentOS.
There is also a great list of instructions in the comments on the php.net site under installing PHP for Apache 2.0 on Unix systems (see http://www.php.net/manual/en/install.unix.apache2.php#90478).
I found this one after I wrote up this tutorial at http://cuadradevelopment.com. It’s a bit different, but should work as well.
There are basically two different ways I could have done this. 1- run a single instance of Apache, and run one instance of PHP as a module, and other installs as CGI. 2- run several instances of Apache, each with it’s own instance of PHP as a module. I chose to do the first method for no particular reason. Dreamhost has a post about the good and bad with running PHP as CGI.
So basically, the steps are: 1. Set up Apache and have PHP install as a module. 2. Configure and make another instance of PHP to run as CGI. 3. Add a virtual host to Apache running under a different port to access the PHP as CGI.
Set up Apache with PHP module
So here’s what I did to get the basic Apache, PHP and MySQL working. This sets up the first PHP install to run as a module in Apache:
From a clean install of CentOS 5 (virtually no packages selected during initial install), I installed the following packages:
$ yum install gcc make subversion ImageMagick php php-cli php-common php-ldap php-mysql php-pdo php-pear php-devel bzip2-devel libxml2-devel mysql mysql-server mysql-devel mod_auth_mysql httpd httpd-manual
From there I needed to get PHP 5.2.x, so I did the following to get PHP, Apache, MySQL and PEAR all set up.
1. Step 1: GET PHP 5.2.x
Check out instructions and packages here: http://blog.famillecollet.com/pages/Config-en
$ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm
$ wget http://rpms.famillecollet.com/el5.i386/remi-release-5-4.el5.remi.noarch.rpm
$ rpm -Uvh remi-release-5.rpm epel-release-5.rpm
$ yum—enablerepo=remi update php-pear php
Copy the /etc/php.ini file from the /etc/php.ini.default:
$ cp /etc/php.ini.default /etc/php.ini
Change the following lines:
* 1. upload_max_filesize = 20M #line 573
* 2. mysql.default_socket =/path/to/mysql/mysql.sock #about line 736
* 3. mysqli.default_socket =/path/to/mysql/mysql.sock #about line 771
2. Step 2: Edit /etc/httpd/conf/httpd.conf by changing the following lines
* 1. Listen xxx.xxx.xxx.xxx:80 #line 134
* 2. ServerAdmin admin@email.org #line 251
* 3. ServerName somesite.org #line 265
* 4. DocumentRoot ”/path/to/htdocs” #line 282
* 5.
* 6. AllowOverride All #line 328
* 7. DirectoryIndex index.php index.html index.html.var #line 392
3. Step 3: Create the /etc/my.cnf file for MySQL
[mysqld]
datadir=/path/to/mysql
socket=/path/to/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
[client]
socket=/path/to/mysql/mysql.sock
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
4. Step 4: Start apache and mysql and set them to start on boot up:
$ service httpd start
$ service mysqld start
$ chkconfig mysqld on
$ chkconfig httpd on
5. Step 5: Set the MySQL password for root
$ mysqladmin -u root password ‘XXXXXX’
6. Step 6: install Phing and other PEAR packages
$ pear channel-discover pear.phing.info
$ pear channel-discover pear.phpunit.de
$ pear install phing/phing
$ pear install PhpDocumentor
$ pear install XML_Beautifier
$ pear install PHPUnit
$ pecl install Xdebug
Configure second version of PHP
From here we need to install a second version of PHP. Grab the version you want from http://www.php.net/releases/, and stick that any where you want to (usually your root’s home directory is fine). I’m installing PHP 5.2.4, so I’ll use that in my examples.
Unpack the tarball and enter the directory it created.
$ tar -xjf php-5.2.4.tar.bz2
Now, you’ll need to determine which modules you need to install. For this part I used the steps from the php.net comment under “my approach for determining required modules” (copied here, without permission, but with lots of gratitude and full credit going to the author of the comment).
my approach for determining required modules
------------------------------------
1. get the list of the modules
$ php -m | grep -v -e Modules] -e ^$ > php-default-modules
2. create the configure script
$ for i in $(cat php-default-modules); do echo -n "--with-$i ">> phpconfigure.sh ;done
2.2 add #!/bin/bash to the top line, and ./configure to the second line.
Each of the --with-* need to be on the second line.
3. run the configure script, and iterate through the "Configure script errors"
section below until it completes properly
$ ./phpconfigure.sh
4. at the end of the output, look for a notice of unknown options
Notice: Following unknown configure options were used:
--with-date
--with-gum-disease
Check './configure --help' for available options
5. as suggested, execute '$ ./configure --help' and correct the options. The
"for" command above indiscriminately inserts "--with-" for all modules,
but bundled modules may require "--enable-" instead, so mostly you'll
be changing those. For modules that are enabled by default you'll need
to remove the entry.
6. Add anything else you personally want or need. I like to add "--enable-safe-mode".
After doing all of that, I had the following in phpconfigure.sh
#!/bin/bash
./configure –prefix=/usr/share/ –datadir=/usr/share/php –libdir=/usr/share –includedir=/usr/include –bindir=/usr/bin –enable-safe-mode –with-config-file-path=/etc/php542 –enable-force-cgi-redirect –enable-discard-path –with-bz2 –enable-calendar –with-curl –enable-dbase –enable-exif –enable-ftp –with-gettext –with-gmp –with-iconv –with-ldap –with-libxml-dir=/usr/lib/ –enable-mbstring –with-mime_magic –with-mysql –with-mysqli –with-openssl –enable-pcntl –with-pcre-dir=/usr/lib/ –with-pdo_mysql –with-pdo_sqlite –with-readline –enable-shmop –enable-sockets –with-SQLite –enable-wddx –with-xsl –enable-zip –with-zlib
# Changes from what php -m spits out. You don’t need the info below in your phpconfigure.sh script
#–enable-calendar
#–with-ctype # default
#–with-date # not found, default?
#–enable-dbase
#–with-dom # default
#–enable-exif
#–with-filter #default
#–with-ftp
#–with-hash #default
#–with-json #default
#–with-libxml-dir=/usr/lib/
#–enable-mbstring
#–with-memcache #not found, default?
#–enable-pcntl
#–with-pcre-dir=/usr/lib/
#–with-PDO #taken care of with the pdo_mysql and pdo_sqlite
#–with-Reflection #default
#–with-session #default
#–enable-shmop
#–with-SimpleXML #default
#–enable-sockets
#–with-SPL #default
#–with-standard #not found, is it SPL? default?
#–with-tokenizer #default
#–enable-wddx
#–with-xdebug #not found, not needed
#–with-xml #default
#–with-xmlreader #default
#–with-xmlwriter #default
#–enable-zip
#–with-Xdebug #not found, not needed
NOTE: make sure you do not include ‘–with-apxs2=/usr/sbin/apxs’. This is what installs PHP as an Apache module. Also, since you have the original PHP running, you can theoretically make a phpinfo file (with phpinfo() ) in it, and grab the configure entries from that, making sure to change ‘–with-config-file-path=/etc’ ‘–with-config-file-scan-dir=/etc/php.d’
During the configure, you might run into some errors. Again from the php.net comment:
Configure script errors
--------------------------------------------
In my experience, these errors have been due (with any software, PHP included) mostly to missing
development packages, which contain the libraries and headers needed to compile support for that
library's function into the application.
This becomes a process of:
-executing the ./configure script and looking at the error
-installing the devel package providing the resource referenced by the error (google using the error
as search term as needed)
-repeat until the ./configure script makes it through without error
Upshot: identify the software referenced by the error, and install it.
Example
-----------
Example error:
configure: error: Cannot find OpenSSL's
Example explanation
configure is looking for a header (and probably a lot of other stuff) from a missing openssl package.
Example solution:
php-5.2.9]$sudo yum install openssl-devel
The previous yum command should take care of most of those dependencies.
After the phpconfigure script runs without errors, then simply run
$ make
As the JpGraph tutorial explains, there is no need to run “make install”. Just simply copy the php-cgi executable to the proper place. We’ll get to that step shortly.
Set up Apache VirtualHost and website directories
Now you need to create two directories to handle the PHP as CGI. They can be virtually wherever, but should be in the same directory where you have the main html content. So if you set the path to the website data (in the httpd.conf) to /path/to/htdocs/, then you’ll need to make a /path/to/php524/ and a /path/to/php524-cgi/
$ mkdir /path/to/php524/
and
$ mkdir /path/to/php524-cgi/
After you have those directories, you can add the VirtualHost information to the Apache config (httpd.conf). I like to have a separate file for the VirtualHosts, so I added this to the end of the httpd.conf file.
Include conf/XXXXX_vhosts.conf
And to allow VirtualHosts, uncomment this line:
NameVirtualHost *:80
To allow Apache to listen on (or accept requests from) different ports besides the default 80, add another Listen line to the httpd.conf file:
Listen XXX.XXX.XXX.XXX:8524
I used port 8524 to correspond to version 5.2.4 of PHP
Now create the XXXXX_vhosts.conf file
#this doesn’t really seem to be needed, but it’s there
NameVirtualHost *:8524
# this is the original and runs the PHP as a module
DocumentRoot /path/to/htdocs/
ServerName somesite.org
####### Add other Virtual Hosts below here #######
# Setup PHP 5.2.4 on port 8524
DocumentRoot /path/to/php524/
# We use a separate CGI directory
ScriptAlias /cgi-bin/ /etc/php524/
# For good measure we also add recognition of PHP5 index
DirectoryIndex index.php5
# These are the two critical statements for this virtual
# host. This activates PHP 5.2.4 as a CGI module
Action php524-cgi /cgi-bin/php-cgi
AddHandler php524-cgi .php5 .php
#Options None
Options FollowSymLinks
#AllowOverride None
AllowOverride All
Order allow,deny
Allow from all
DirectoryIndex index.html index.php
Now, you need to copy the php-cgi binary/executable to the /path/to/php524-cgi-bin/ directory. The php-cgi file is located in the file where you ran the configure and make for the new php install. So if you did all that in the /opt/php-5.2.4/ directory, the php-cgi will be located at /opt/php-5.2.4/sapi/cgi/php-cgi.
$ cp /opt/php-5.2.4/sapi/cgi/php-cgi /path/to/php524-cgi-bin/
Finally, copy the php.ini file to the right place. And configure as needed.
$ cp /opt/php-5.2.4/php.ini-dist /path/to/php524-cgi-bin/php.ini
Test the apache configs to make sure they work:
$ /usr/sbin/apachectl configtest
If that returns OK restart Apache.
$ /etc/init.d/httpd graceful
You can make a phpinfo page to test that it’s using the new PHP version.
phpinfo();
? >
Then check out your new site: http://somesite.org:8524/phpinfo.php
In order to get the different versions of PHP to interact with MySQL, you’ll have to use the URL on port 80 as the MySQL host. So, for example, in a WordPress install at http://somesite.org:8524/blog, the wp-config.php will have to have the following for the MySQL hostname:
define('DB_HOST', 'dev.omeka.org');
There is some issue with mod_rewrite on the different versions of PHP. I’ll replace this paragraph with a fix when I have one.
UPDATE: 9/9/09 – I figured out how to get the .htaccess working for the Omeka installs we were working with. I needed to change the AllowOverride lines in the vhost.conf (or httpd.conf) file from None, to All.
Thứ Hai, 15 tháng 3, 2010
Logon Type Codes Revealed
Logon Type Codes Revealed
The logon/logoff category of the Windows security log gives you the ability to monitor all attempts to access the local computer. In this article I’ll examine each logon type in greater detail and show you how some other fields in Logon/Logoff events can be helpful for understanding the nature of a given logon attempt.
* Published: Mar 29, 2005
* Updated: Mar 29, 2005
* Section: Articles :: Misc Network Security
* Author: Randall F. Smith
* Printable Version
* Adjust font size: + -
* Rating: 4.6/5 - 500 Votes
* 1
* 2
* 3
* 4
* 5
AddThis
If you want even more advice from Randall F Smith, check out his seminar below:
Attend the only 2-day seminar devoted to the Windows security log
Event IDs 528 and 540 signify a successful logon, event ID 538 a logoff and all the other events in this category identify different reasons for a logon failure. However, just knowing about a successful or failed logon attempt doesn’t fill in the whole picture. Because of all the services Windows offers, there are many different ways you can logon to a computer such as interactively at the computer’s local keyboard and screen, over the network through a drive mapping or through terminal services (aka remote desktop) or through IIS. Thankfully, logon/logoff events specify the Logon Type code which reveals the type of logon that prompted the event.
Logon Type 2 – Interactive
This is what occurs to you first when you think of logons, that is, a logon at the console of a computer. You’ll see type 2 logons when a user attempts to log on at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. To tell the difference between an attempt to logon with a local or domain account look for the domain or computer name preceding the user name in the event’s description. Don’t forget that logon’s through an KVM over IP component or a server’s proprietary “lights-out” remote KVM feature are still interactive logons from the standpoint of Windows and will be logged as such.
Logon Type 3 – Network
Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS. (The exception is basic authentication which is explained in Logon Type 8 below.)
Logon Type 4 – Batch
When Windows executes a scheduled task, the Scheduled Task service first creates a new logon session for the task so that it can run under the authority of the user account specified when the task was created. When this logon attempt occurs, Windows logs it as logon type 4. Other job scheduling systems, depending on their design, may also generate logon events with logon type 4 when starting jobs. Logon type 4 events are usually just innocent scheduled tasks startups but a malicious user could try to subvert security by trying to guess the password of an account through scheduled tasks. Such attempts would generate a logon failure event where logon type is 4. But logon failures associated with scheduled tasks can also result from an administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.
Logon Type 5 – Service
Similar to Scheduled Tasks, each service is configured to run as a specified user account. When a service starts, Windows first creates a logon session for the specified user account which results in a Logon/Logoff event with logon type 5. Failed logon events with logon type 5 usually indicate the password of an account has been changed without updating the service but there’s always the possibility of malicious users at work too. However this is less likely because creating a new service or editing an existing service by default requires membership in Administrators or Server Operators and such a user, if malicious, will likely already have enough authority to perpetrate his desired goal.
Logon Type 7 – Unlock
Hopefully the workstations on your network automatically start a password protected screen saver when a user leaves their computer so that unattended workstations are protected from malicious use. When a user returns to their workstation and unlocks the console, Windows treats this as a logon and logs the appropriate Logon/Logoff event but in this case the logon type will be 7 – identifying the event as a workstation unlock attempt. Failed logons with logon type 7 indicate either a user entering the wrong password or a malicious user trying to unlock the computer by guessing the password.
Logon Type 8 – NetworkCleartext
This logon type indicates a network logon like logon type 3 but where the password was sent over the network in the clear text. Windows server doesn’t allow connection to shared file or printers with clear text authentication. The only situation I’m aware of are logons from within an ASP script using the ADVAPI or when a user logs on to IIS using IIS’s basic authentication mode. In both cases the logon process in the event’s description will list advapi. Basic authentication is only dangerous if it isn’t wrapped inside an SSL session (i.e. https). As far as logons generated by an ASP, script remember that embedding passwords in source code is a bad practice for maintenance purposes as well as the risk that someone malicious will view the source code and thereby gain the password.
Logon Type 9 – NewCredentials
If you use the RunAs command to start a program under a different user account and specify the /netonly switch, Windows records a logon/logoff event with logon type 9. When you start a program with RunAs using /netonly, the program executes on your local computer as the user you are currently logged on as but for any connections to other computers on the network, Windows connects you to those computers using the account specified on the RunAs command. Without /netonly Windows runs the program on the local computer and on the network as the specified user and records the logon event with logon type 2.
Logon Type 10 – RemoteInteractive
When you access a computer through Terminal Services, Remote Desktop or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. Note however that prior to XP, Windows 2000 doesn’t use logon type 10 and terminal services logons are reported as logon type 2.
Logon Type 11 – CachedInteractive
Windows supports a feature called Cached Logons which facilitate mobile users. When you are not connected to the your organization’s network and attempt to logon to your laptop with a domain account there’s no domain controller available to the laptop with which to verify your identity. To solve this problem, Windows caches a hash of the credentials of the last 10 interactive domain logons. Later when no domain controller is available, Windows uses these hashes to verify your identity when you attempt to logon with a domain account.
Conclusion
I hope this discussion of logon types and their meanings helps you as you keep watch on your Windows network and try to piece together the different ways users are accessing your computers. Paying attention to logon type is important because different logon types can affect how you interpret logon events from a security perspective. For instance a failed network logon on a server might now be surprising since users must access servers over the network all the time. But a failed network logon attempt in a workstation security log is different. Why is anyone trying to access someone else’s workstation from over the network? As you can see, it pays to understand the security log.
The logon/logoff category of the Windows security log gives you the ability to monitor all attempts to access the local computer. In this article I’ll examine each logon type in greater detail and show you how some other fields in Logon/Logoff events can be helpful for understanding the nature of a given logon attempt.
* Published: Mar 29, 2005
* Updated: Mar 29, 2005
* Section: Articles :: Misc Network Security
* Author: Randall F. Smith
* Printable Version
* Adjust font size: + -
* Rating: 4.6/5 - 500 Votes
* 1
* 2
* 3
* 4
* 5
AddThis
If you want even more advice from Randall F Smith, check out his seminar below:
Attend the only 2-day seminar devoted to the Windows security log
Event IDs 528 and 540 signify a successful logon, event ID 538 a logoff and all the other events in this category identify different reasons for a logon failure. However, just knowing about a successful or failed logon attempt doesn’t fill in the whole picture. Because of all the services Windows offers, there are many different ways you can logon to a computer such as interactively at the computer’s local keyboard and screen, over the network through a drive mapping or through terminal services (aka remote desktop) or through IIS. Thankfully, logon/logoff events specify the Logon Type code which reveals the type of logon that prompted the event.
Logon Type 2 – Interactive
This is what occurs to you first when you think of logons, that is, a logon at the console of a computer. You’ll see type 2 logons when a user attempts to log on at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. To tell the difference between an attempt to logon with a local or domain account look for the domain or computer name preceding the user name in the event’s description. Don’t forget that logon’s through an KVM over IP component or a server’s proprietary “lights-out” remote KVM feature are still interactive logons from the standpoint of Windows and will be logged as such.
Logon Type 3 – Network
Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS. (The exception is basic authentication which is explained in Logon Type 8 below.)
Logon Type 4 – Batch
When Windows executes a scheduled task, the Scheduled Task service first creates a new logon session for the task so that it can run under the authority of the user account specified when the task was created. When this logon attempt occurs, Windows logs it as logon type 4. Other job scheduling systems, depending on their design, may also generate logon events with logon type 4 when starting jobs. Logon type 4 events are usually just innocent scheduled tasks startups but a malicious user could try to subvert security by trying to guess the password of an account through scheduled tasks. Such attempts would generate a logon failure event where logon type is 4. But logon failures associated with scheduled tasks can also result from an administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.
Logon Type 5 – Service
Similar to Scheduled Tasks, each service is configured to run as a specified user account. When a service starts, Windows first creates a logon session for the specified user account which results in a Logon/Logoff event with logon type 5. Failed logon events with logon type 5 usually indicate the password of an account has been changed without updating the service but there’s always the possibility of malicious users at work too. However this is less likely because creating a new service or editing an existing service by default requires membership in Administrators or Server Operators and such a user, if malicious, will likely already have enough authority to perpetrate his desired goal.
Logon Type 7 – Unlock
Hopefully the workstations on your network automatically start a password protected screen saver when a user leaves their computer so that unattended workstations are protected from malicious use. When a user returns to their workstation and unlocks the console, Windows treats this as a logon and logs the appropriate Logon/Logoff event but in this case the logon type will be 7 – identifying the event as a workstation unlock attempt. Failed logons with logon type 7 indicate either a user entering the wrong password or a malicious user trying to unlock the computer by guessing the password.
Logon Type 8 – NetworkCleartext
This logon type indicates a network logon like logon type 3 but where the password was sent over the network in the clear text. Windows server doesn’t allow connection to shared file or printers with clear text authentication. The only situation I’m aware of are logons from within an ASP script using the ADVAPI or when a user logs on to IIS using IIS’s basic authentication mode. In both cases the logon process in the event’s description will list advapi. Basic authentication is only dangerous if it isn’t wrapped inside an SSL session (i.e. https). As far as logons generated by an ASP, script remember that embedding passwords in source code is a bad practice for maintenance purposes as well as the risk that someone malicious will view the source code and thereby gain the password.
Logon Type 9 – NewCredentials
If you use the RunAs command to start a program under a different user account and specify the /netonly switch, Windows records a logon/logoff event with logon type 9. When you start a program with RunAs using /netonly, the program executes on your local computer as the user you are currently logged on as but for any connections to other computers on the network, Windows connects you to those computers using the account specified on the RunAs command. Without /netonly Windows runs the program on the local computer and on the network as the specified user and records the logon event with logon type 2.
Logon Type 10 – RemoteInteractive
When you access a computer through Terminal Services, Remote Desktop or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. Note however that prior to XP, Windows 2000 doesn’t use logon type 10 and terminal services logons are reported as logon type 2.
Logon Type 11 – CachedInteractive
Windows supports a feature called Cached Logons which facilitate mobile users. When you are not connected to the your organization’s network and attempt to logon to your laptop with a domain account there’s no domain controller available to the laptop with which to verify your identity. To solve this problem, Windows caches a hash of the credentials of the last 10 interactive domain logons. Later when no domain controller is available, Windows uses these hashes to verify your identity when you attempt to logon with a domain account.
Conclusion
I hope this discussion of logon types and their meanings helps you as you keep watch on your Windows network and try to piece together the different ways users are accessing your computers. Paying attention to logon type is important because different logon types can affect how you interpret logon events from a security perspective. For instance a failed network logon on a server might now be surprising since users must access servers over the network all the time. But a failed network logon attempt in a workstation security log is different. Why is anyone trying to access someone else’s workstation from over the network? As you can see, it pays to understand the security log.
Thứ Hai, 8 tháng 3, 2010
Crontab – Quick & Complete reference Setting up cronjobs in Unix and Linux.
What is crontab?
cron is a unix, solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon.
These tasks are often termed as cron jobs in unix , solaris.
Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times.
Crontab Restrictions
You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow. If that file does not exist, you can use
crontab if your name does not appear in the file /usr/lib/cron/cron.deny.
If only cron.deny exists and is empty, all users can use crontab.
If neither file exists, only the root user can use crontab. The allow/deny files consist of one user name per line.
Crontab Location
Where is it stored?
It will be stored /var/spool/cron/ but we only root has permission for those directories
Crontab Commands
export EDITOR=vi ;to specify a editor to open crontab file.
crontab -e Edit your crontab file, or create one if it doesn’t already exist.
crontab -l Display your crontab file.
crontab -r Remove your crontab file.
crontab -v Display the last time you edited your crontab file. (This option is only available on a few systems.)
Crontab file
Crontab syntax :-
A crontab file has five fields for specifying day , date and time followed by the command to be run at that interval.
* * * * * command to be executed
- – – – -
‘ ‘ ‘ ‘ ‘
‘ ‘ ‘ ‘ +—– day of week (0 – 6) (Sunday=0)
‘ ‘ ‘ +——- month (1 – 12)
‘ ‘ +——— day of month (1 – 31)
‘ +———– hour (0 – 23)
+————- min (0 – 59)
* in the value field above means all legal values as in braces for that column.
The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).
Note: The specification of days can be made in two fields: month day and weekday. If both are specified in an entry, they are cumulative meaning both of the entries will get executed .
How to Modify Crontab file?
*
crontab -e
This will open the crontab file and let you edit it. By default this file will be opened with the VI editor and you will need to press the “Insert” key on your keyboard to be able to write in that file.
*
30 13 * * * /home/your_username/run-me.sh >/dev/null 2>&1
The first character you see is “30” this means that crontab will run the script every time the clock hits the 30 minutes mark. Next “13” this means that crontab will run the script when the clock hits 13. The next three * tell crontab to run the script every day, of every month of every weekday. Combining these fields crontab will run the script every day at exactly 13:30. You may notice that we added the “>/dev/null 2>&1” string at the end of the command. The default cron job will always send and e-mail to the root account when ever a command is executed. Now you don’t want to be notified every day that your crontab job has been executed. If you don’t want to receive e-mails every day notifying you about your job’s execution place this “>/dev/null 2>&1” at the end of every instance of every crontab command.
When you are finished adding your commands to the crontab file you need to save and exit. If you are using VI as your editor you need to issue the following commands:
*
Press the Esc (Escape key) on your keyboard to enter the command mode of VI
*
After you pressed Escape then type the following characters :wq! and press Enter. Remember you have to type this characters (remove the quotes): “:wq!”.
linux_crontab_colorful.png
Crontab Example
#A line in crontab file like below removes the tmp files from /home/someuser/tmp each day at 6:30 PM.
30 18 * * * rm /home/someuser/tmp/*
#This runs every fifteen minutes
*/15 * * * * /notesbit/work/scripts/crons/denyhack1 > /dev/null 2>&1
*/20 * * * * /notesbit/work/scripts/crons/denyhack2 > /dev/null 2>&1
#This runs every twenty five minutes
*/25 * * * * /notesbit/work/scripts/crons/denyhack3 > /dev/null 2>&1
*/35 * * * * /notesbit/work/scripts/crons/denyhack4 > /dev/null 2>&1
# This runs every day at 2:14 PM
08 14 * * * /root/work/scripts/crons/stkinc NUAN > /dev/null 2>&1
Crontab Example 1: This crontab example runs updatedb command 35 minutes past every hour.
35 * * * * updatedb
Crontab Example 2: This crontab example runs /usr/local/bin/diskusage.sh every 5 minutes (e.g. 0, 5, 10, 15, …).
*/5 * * * * /usr/local/bin/diskusage.sh
Crontab Example 3: This crontab example runs /usr/local/bin/diskusage.sh at 1:25 AM, 1:50 AM every Tuesday and on 15th of every month.
25,50 1 15 * 2 /usr/local/bin/diskusage.sh
Crontab Example 4: This crontab example runs /usr/local/bin/diskusage.sh at 2:00 PM on 10th of March, June, September and December.
00 14 10 3,6,9,12 * /usr/local/bin/diskusage.sh
Crontab Example 5: This crontab example runs ‘/usr/local/bin/diskusage.sh user@linuxconfig.sh’ at 9.00 PM every Monday, Wednesday, Friday. Note: Using names for the week day and months is extension in some versions of crontab.
00 21 * * Mon,Wed,Fri /usr/local/bin/diskusage.sh user@linuxconfig.sh
Crontab Example 6: This crontab example runs /usr/local/bin/diskusage.sh every 5 minutes during the 5 working days (Monday – Friday), every week and month.
*/5 * * * 1-5 /usr/local/bin/diskusage.sh
Crontab Example 7: This crontab example runs /usr/local/bin/diskusage.sh every minute during the 4-th hour only in Sunday, every week and month. This is every minute from 0:00 till 0:59, then from 4:00 till 4:59, etc.
* */4 * * sun /usr/local/bin/diskusage.sh
3. System wide cron scheduler
As a Linux administrator you can also use predefined cron directories:
/etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly
If root wishes to run backup.sh script once a week he will place backup.sh script into /etc/cron.weekly directory.
4. Cron Scheduler on user level
Every user can edit, view or remove his own crontab file. If the root user needs to change someone else’s crontab file he must add ‘-u’ option to specify the user name. To edit crontab file for user foobar we can use command:
# crontab -u foobar -e
Remove foobar’s crontab file:
# crontab -u foobar -r
To view foobar’s crontab content:
# crontab -u foobar -l
Crontab Environment
cron invokes the command from the user’s HOME directory with the shell, (/usr/bin/sh).
cron supplies a default environment for every shell, defining:
HOME=user’s-home-directory
LOGNAME=user’s-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh
Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry
Reference & source: http://www.linuxconfig.org
cron is a unix, solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon.
These tasks are often termed as cron jobs in unix , solaris.
Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times.
Crontab Restrictions
You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow. If that file does not exist, you can use
crontab if your name does not appear in the file /usr/lib/cron/cron.deny.
If only cron.deny exists and is empty, all users can use crontab.
If neither file exists, only the root user can use crontab. The allow/deny files consist of one user name per line.
Crontab Location
Where is it stored?
It will be stored /var/spool/cron/ but we only root has permission for those directories
Crontab Commands
export EDITOR=vi ;to specify a editor to open crontab file.
crontab -e Edit your crontab file, or create one if it doesn’t already exist.
crontab -l Display your crontab file.
crontab -r Remove your crontab file.
crontab -v Display the last time you edited your crontab file. (This option is only available on a few systems.)
Crontab file
Crontab syntax :-
A crontab file has five fields for specifying day , date and time followed by the command to be run at that interval.
* * * * * command to be executed
- – – – -
‘ ‘ ‘ ‘ ‘
‘ ‘ ‘ ‘ +—– day of week (0 – 6) (Sunday=0)
‘ ‘ ‘ +——- month (1 – 12)
‘ ‘ +——— day of month (1 – 31)
‘ +———– hour (0 – 23)
+————- min (0 – 59)
* in the value field above means all legal values as in braces for that column.
The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).
Note: The specification of days can be made in two fields: month day and weekday. If both are specified in an entry, they are cumulative meaning both of the entries will get executed .
How to Modify Crontab file?
*
crontab -e
This will open the crontab file and let you edit it. By default this file will be opened with the VI editor and you will need to press the “Insert” key on your keyboard to be able to write in that file.
*
30 13 * * * /home/your_username/run-me.sh >/dev/null 2>&1
The first character you see is “30” this means that crontab will run the script every time the clock hits the 30 minutes mark. Next “13” this means that crontab will run the script when the clock hits 13. The next three * tell crontab to run the script every day, of every month of every weekday. Combining these fields crontab will run the script every day at exactly 13:30. You may notice that we added the “>/dev/null 2>&1” string at the end of the command. The default cron job will always send and e-mail to the root account when ever a command is executed. Now you don’t want to be notified every day that your crontab job has been executed. If you don’t want to receive e-mails every day notifying you about your job’s execution place this “>/dev/null 2>&1” at the end of every instance of every crontab command.
When you are finished adding your commands to the crontab file you need to save and exit. If you are using VI as your editor you need to issue the following commands:
*
Press the Esc (Escape key) on your keyboard to enter the command mode of VI
*
After you pressed Escape then type the following characters :wq! and press Enter. Remember you have to type this characters (remove the quotes): “:wq!”.
linux_crontab_colorful.png
Crontab Example
#A line in crontab file like below removes the tmp files from /home/someuser/tmp each day at 6:30 PM.
30 18 * * * rm /home/someuser/tmp/*
#This runs every fifteen minutes
*/15 * * * * /notesbit/work/scripts/crons/denyhack1 > /dev/null 2>&1
*/20 * * * * /notesbit/work/scripts/crons/denyhack2 > /dev/null 2>&1
#This runs every twenty five minutes
*/25 * * * * /notesbit/work/scripts/crons/denyhack3 > /dev/null 2>&1
*/35 * * * * /notesbit/work/scripts/crons/denyhack4 > /dev/null 2>&1
# This runs every day at 2:14 PM
08 14 * * * /root/work/scripts/crons/stkinc NUAN > /dev/null 2>&1
Crontab Example 1: This crontab example runs updatedb command 35 minutes past every hour.
35 * * * * updatedb
Crontab Example 2: This crontab example runs /usr/local/bin/diskusage.sh every 5 minutes (e.g. 0, 5, 10, 15, …).
*/5 * * * * /usr/local/bin/diskusage.sh
Crontab Example 3: This crontab example runs /usr/local/bin/diskusage.sh at 1:25 AM, 1:50 AM every Tuesday and on 15th of every month.
25,50 1 15 * 2 /usr/local/bin/diskusage.sh
Crontab Example 4: This crontab example runs /usr/local/bin/diskusage.sh at 2:00 PM on 10th of March, June, September and December.
00 14 10 3,6,9,12 * /usr/local/bin/diskusage.sh
Crontab Example 5: This crontab example runs ‘/usr/local/bin/diskusage.sh user@linuxconfig.sh’ at 9.00 PM every Monday, Wednesday, Friday. Note: Using names for the week day and months is extension in some versions of crontab.
00 21 * * Mon,Wed,Fri /usr/local/bin/diskusage.sh user@linuxconfig.sh
Crontab Example 6: This crontab example runs /usr/local/bin/diskusage.sh every 5 minutes during the 5 working days (Monday – Friday), every week and month.
*/5 * * * 1-5 /usr/local/bin/diskusage.sh
Crontab Example 7: This crontab example runs /usr/local/bin/diskusage.sh every minute during the 4-th hour only in Sunday, every week and month. This is every minute from 0:00 till 0:59, then from 4:00 till 4:59, etc.
* */4 * * sun /usr/local/bin/diskusage.sh
3. System wide cron scheduler
As a Linux administrator you can also use predefined cron directories:
/etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly
If root wishes to run backup.sh script once a week he will place backup.sh script into /etc/cron.weekly directory.
4. Cron Scheduler on user level
Every user can edit, view or remove his own crontab file. If the root user needs to change someone else’s crontab file he must add ‘-u’ option to specify the user name. To edit crontab file for user foobar we can use command:
# crontab -u foobar -e
Remove foobar’s crontab file:
# crontab -u foobar -r
To view foobar’s crontab content:
# crontab -u foobar -l
Crontab Environment
cron invokes the command from the user’s HOME directory with the shell, (/usr/bin/sh).
cron supplies a default environment for every shell, defining:
HOME=user’s-home-directory
LOGNAME=user’s-login-id
PATH=/usr/bin:/usr/sbin:.
SHELL=/usr/bin/sh
Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry
Reference & source: http://www.linuxconfig.org
Đăng ký:
Bài đăng (Atom)