Here I am trying to describe how I configured Postfix with MySQL backend. Here I have given only the important parameter, however you can find tune this in various ways.
1.
Configure your Postfix with MySQL support.
I used following command - make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -I/usr/include/mysql' 'AUXLIBS=-L/usr/lib/mysql -lmysqlclient -lz -lm'
Before do this, please make sure that you have installed all the MySQL components, including mysql-devel.
2.
Then do the make
3.
DO the make install. At the end of this phase you will be prompt with many questions, answer them appropriate.
4.
Then start configure your Postfix, normally you can find the configuration in main.cf
The important settings (though there are several settings) you need to add are :
data_directory = /var/lib/postfix
mail_owner = postfix
- make sure that you have created the user postfix
myhostname = mail.yy.xx.lk
mydomain = XX,cc.lk
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost = 192.NN.N.N
home_mailbox = Maildir/
- This is important, and this is where you say that you want to use MailDir, not Mailbox
virtual_gid_maps = static:506
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 100
virtual_transport = virtual
virtual_uid_maps = static:504
- You must create another user, may be vmail, who should have permission to write mails to maildir. After adding those user, you need to specify the uid and gid of that user here in uid_maps and gid_maps. Also make sure that you have given sufficient permission to the mailbox_base to the user that you have created.
After doing all these settings in the main.cf file, you need to create another two files that you have given in "virtual_mailbox_domains" and "virtual_mailbox_maps".
In my case etc/postfix/mysql_virtual_domains_maps.cf contains following parameters :
hosts = localhost
dbname = maildb
user = mailuser
password = xxxxxxx
table = mail_domains
select_field = mail_domain
where_field = mail_domain
This tells postfix that what are the domains should be handled by the postfix it self and what are should be routed to other MTAs.
/etc/postfix/mysql_virtual_mailbox_maps.cf contains :
hosts = localhost
dbname = maildb
user = mailuser
password = XXXX
table = mail_accounts
select_field = maildir
where_field = mail_user
This is used to select the MailDir name for the respective email account. For example if someone sends a mail to sarves@xyz.com, this will find and tells that where that message should go in the virtual_mailbox_base.
Hope this will work for you all as well.
Good luck
Reference :
http://hostingsoftware.net/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=56
http://www.postfix.org/INSTALL.html
Monday, May 2, 2011
Thursday, March 24, 2011
Moodle - Set default enrolable to no
When you create a course on Moodle, the course enrolable is always set to yes by default. Sometime this is problematic for you.
This is how you set course enrolable to no by default!
Open moodle/course/edit_form.php and find the line:
$mform->setDefault('enrollable', 1);
And change it to:
$mform->setDefault('enrollable', 0);
This is how you set course enrolable to no by default!
Open moodle/course/edit_form.php and find the line:
$mform->setDefault('enrollable', 1);
And change it to:
$mform->setDefault('enrollable', 0);
Tuesday, March 15, 2011
Creating Certificate Authorities and self-signed SSL certificates
Following is a step-by-step guide to creating your own CA (Certificate Authority) -- and also self-signed SSL server certificates -- with openssl on Linux. Self-signing is the simpler route to take, but making one's own CA allows the signing of multiple server certificates using the same CA and involves only a few extra steps.
After using openssl to generate the necessary files, you'll need to integrate them into Apache. This process differs between Linux distros and versions of Apache. Additional references exist at the end of this document. My instructions for Setting up SSL: Ubuntu and Apache 2 are kept most current, and will carry you through to completion.
Making a homemade CA or self-signed certificate will cause the client web browser to prompt with a message whether to trust the certificate signing authority (yourself) permanently (store it in the browser), temporarily for that session, or to reject it. The message "web site certified by an unknown authority... accept?" may be a business liability for general public usage, although it's simple enough for the client to accept the certificate permanently.
Whichever route you take, you'll save the periodic expense of paying a recognized signing authority. This is purely for name recognition -- they've paid the major browser producers to have their CA pre-loaded into them. So if you're on a budget, have a special need or small audience, this may be useful.
Before you start
You need Apache and openssl. Compiling them from source, handling dependencies, etc. is beyond the scope of this document. You can consult their documentation, or go with a mainstream Linux distro that will do the preliminary work for you.
Now you need to decide whether you'll make a CA (Certificate Authority) and sign a server certificate with it -- or just self-sign a server certificate. Both procedures are detailed below.
(1A) Create a self-signed certificate.
Complete this section if you do NOT want to make a CA (Certificate Authority). If you want to make a CA, skip 1A entirely and go to 1B instead.
Some steps in this document require priviledged access, and you'll want to limit access to the cert files to all but the root user. So you should su to root and create a working directory that only root has read/write access to (for example: mkdir certwork, chmod 600 certwork). Go to that directory.
Generate a server key:
openssl genrsa -des3 -out server.key 4096
Then create a certificate signing request with it. This command will prompt for a series of things (country, state or province, etc.). Make sure that "Common Name (eg, YOUR name)" matches the registered fully qualified domain name of your box (or your IP address if you don't have one). I also suggest not making a challenge password at this point, since it'll just mean more typing for you.
The default values for the questions ([AU], Internet Widgits Pty Ltd, etc.) are stored here: /etc/ssl/openssl.cnf. So if you've got a large number of certificate signing requests to process you probably want to carefully edit that file where appropriate. Otherwise, just execute the command below and type what needs to be typed:
openssl req -new -key server.key -out server.csr
Now sign the certificate signing request. This example lasts 365 days:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Make a version of the server.key which doesn't need a password:
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
These files are quite sensitive and should be guarded for permissions very carefully. Chown them to root, if you're not already sudo'd to root. I've found that you can chmod 000 them. That is, root will always retain effective 600 (read) rights on everything.
Now that you've just completed Step 1A, skip ahead to Step 2.
(1B) Generate your own CA (Certificate Authority).
Complete this section if you want to make a CA (Certificate Authority) and sign a server certificate with it. The steps for making a server certificate are also included here. If you'd rather one-time self-sign a server certificate, skip this step entirely and go to 1A instead.
Some steps in this document require priviledged access, and you'll want to limit access to the cert files to all but the root user. So you should su to root and create a working directory that only root has read/write access to (for example: mkdir certwork, chmod 600 certwork). Go to that directory.
In this step you'll take the place of VeriSign, Thawte, etc. You'll first build the CA key, then build the certificate itself.
The Common Name (CN) of the CA and the Server certificates must NOT match or else a naming collision will occur and you'll get errors later on. In this step, you'll provide the CA entries. In a step below, you'll provide the Server entries. In this example, I just added "CA" to the CA's CN field, to distinguish it from the Server's CN field. Use whatever schema you want, just make sure the CA and Server entries are not identical.
CA:
Common Name (CN): www.somesite.edu CA
Organization (O): Somesite
Organizational Unit (OU): Development
Server:
Common Name (CN): www.somesite.edu
Organization (O): Somesite
Organizational Unit (OU): Development
If you don't have a fully qualified domain name, you should use the IP that you'll be using to access your SSL site for Common Name (CN). But, again, make sure that something differentiates the entry of the CA's CN from the Server's CN.
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Generate a server key and request for signing (csr).
This step creates a server key, and a request that you want it signed (the .csr file) by a Certificate Authority (the one you just created in Step #1B above.)
Think carefully when inputting a Common Name (CN) as you generate the .csr file below. This should match the DNS name, or the IP address you specify in your Apache configuration. If they don't match, client browsers will get a "domain mismatch" message when going to your https web server. If you're doing this for home use, and you don't have a static IP or DNS name, you might not even want worry about the message (but you sure will need to worry if this is a production/public server). For example, you could match it to an internal and static IP you use behind your router, so that you'll never get the "domain mismatch" message if you're accessing the computer on your home LAN, but will always get that message when accessing it elsewhere. Your call -- is your IP stable, do you want to repeat these steps every time your IP changes, do you have a DNS name, do you mainly use it inside your home or LAN, or outside?
openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
Sign the certificate signing request (csr) with the self-created Certificate Authority (CA) that you made earlier.
Note that 365 days is used here. After a year you'll need to do this again.
Note also that I set the serial number of the signed server certificate to "01". Each time you do this, especially if you do this before a previously-signed certificate expires, you'll need to change the serial key to something else -- otherwise everyone who's visited your site with a cached version of your certificate will get a browser warning message to the effect that your certificate signing authority has screwed up -- they've signed a new key/request, but kept the old serial number. There are a couple ways to rectify that. crl's (certificate revocation list) is one method, but beyond the scope of the document. Another method is for all clients which have stored the CA certificate to go into their settings and delete the old one manually. But for the purposes of this document, we'll just avoid the problem. (If you're a sysadmin of a production system and your server.key is compromised, you'll certainly need to worry.)
The command below does a number of things. It takes your signing request (csr) and makes a one-year valid signed server certificate (crt) out of it. In doing so, we need to tell it which Certificate Authority (CA) to use, which CA key to use, and which Server key to sign. We set the serial number to 01, and output the signed key in the file named server.crt. If you do this again after people have visited your site and trusted your CA (storing it in their browser), you might want to use 02 for the next serial number, and so on. You might create some scheme to make the serial number more "official" in appearance or makeup but keep in mind that it is fully exposed to the public in their web browsers, so it offers no additional security in itself.
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
To examine the components if you're curious:
openssl rsa -noout -text -in server.key
openssl req -noout -text -in server.csr
openssl rsa -noout -text -in ca.key
openssl x509 -noout -text -in ca.crt
Make a server.key which doesn't cause Apache to prompt for a password.
Here we create an insecure version of the server.key. The insecure one will be used for when Apache starts, and will not require a password with every restart of the web server. But keep in mind that while this means you don't have to type in a password when restarting Apache (or worse -- coding it somewhere in plaintext), it does mean that anyone obtaining this insecure key will be able to decrypt your transmissions. Guard it for permissions VERY carefully.
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
These files are quite sensitive and should be guarded for permissions very carefully. Chown them to root, if you're not already sudo'd to root. I've found that you can chmod 000 them. That is, root will always retain effective 600 (read) rights on everything.
(2) Copy files into position and tweak Apache.
Some professors like to pause for a moment after a long lecture, and do a little recap. It's a good pedagogical tool, so let's do so here. If you took route 1A above, you should have four files in a working directory:
server.crt: The self-signed server certificate.
server.csr: Server certificate signing request.
server.key: The private server key, does not require a password when starting Apache.
server.key.secure: The private server key, it does require a password when starting Apache.
If you took route 1B and created a CA, you'll have two additional files:
ca.crt: The Certificate Authority's own certificate.
ca.key: The key which the CA uses to sign server signing requests.
The CA files are important to keep if you want to sign additional server certificates and preserve the same CA. You can reuse these so long as they remain secure, and haven't expired.
At a bare minimum, the following considerations must now be addressed:
* You'll need a virtual host and document root set up for the SSL instance.
* You'll need to turn on the SSL engine and enable/load the SSL module.
* Apache must reference server.crt and server.key somewhere in its configuration.
* Apache must be listening to a port for which SSL is enabled (443 is default).
The particulars differ between Linux distros and versions of Apache. I'm only able to keep the Setting up SSL: Ubuntu and Apache 2 documentation current due to time constraints. Those steps should apply broadly to Debian-based distros with little or no modification. Red Hat and openSUSE commentary is kept online here for historical purposes.
Setting up SSL: Ubuntu and Apache 2
Setting up SSL: Red Hat and Apache 1.3.x
Setting up SSL: openSUSE
Credit : http://www.tc.umn.edu/~brams006/selfsign.html
After using openssl to generate the necessary files, you'll need to integrate them into Apache. This process differs between Linux distros and versions of Apache. Additional references exist at the end of this document. My instructions for Setting up SSL: Ubuntu and Apache 2 are kept most current, and will carry you through to completion.
Making a homemade CA or self-signed certificate will cause the client web browser to prompt with a message whether to trust the certificate signing authority (yourself) permanently (store it in the browser), temporarily for that session, or to reject it. The message "web site certified by an unknown authority... accept?" may be a business liability for general public usage, although it's simple enough for the client to accept the certificate permanently.
Whichever route you take, you'll save the periodic expense of paying a recognized signing authority. This is purely for name recognition -- they've paid the major browser producers to have their CA pre-loaded into them. So if you're on a budget, have a special need or small audience, this may be useful.
Before you start
You need Apache and openssl. Compiling them from source, handling dependencies, etc. is beyond the scope of this document. You can consult their documentation, or go with a mainstream Linux distro that will do the preliminary work for you.
Now you need to decide whether you'll make a CA (Certificate Authority) and sign a server certificate with it -- or just self-sign a server certificate. Both procedures are detailed below.
(1A) Create a self-signed certificate.
Complete this section if you do NOT want to make a CA (Certificate Authority). If you want to make a CA, skip 1A entirely and go to 1B instead.
Some steps in this document require priviledged access, and you'll want to limit access to the cert files to all but the root user. So you should su to root and create a working directory that only root has read/write access to (for example: mkdir certwork, chmod 600 certwork). Go to that directory.
Generate a server key:
openssl genrsa -des3 -out server.key 4096
Then create a certificate signing request with it. This command will prompt for a series of things (country, state or province, etc.). Make sure that "Common Name (eg, YOUR name)" matches the registered fully qualified domain name of your box (or your IP address if you don't have one). I also suggest not making a challenge password at this point, since it'll just mean more typing for you.
The default values for the questions ([AU], Internet Widgits Pty Ltd, etc.) are stored here: /etc/ssl/openssl.cnf. So if you've got a large number of certificate signing requests to process you probably want to carefully edit that file where appropriate. Otherwise, just execute the command below and type what needs to be typed:
openssl req -new -key server.key -out server.csr
Now sign the certificate signing request. This example lasts 365 days:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Make a version of the server.key which doesn't need a password:
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
These files are quite sensitive and should be guarded for permissions very carefully. Chown them to root, if you're not already sudo'd to root. I've found that you can chmod 000 them. That is, root will always retain effective 600 (read) rights on everything.
Now that you've just completed Step 1A, skip ahead to Step 2.
(1B) Generate your own CA (Certificate Authority).
Complete this section if you want to make a CA (Certificate Authority) and sign a server certificate with it. The steps for making a server certificate are also included here. If you'd rather one-time self-sign a server certificate, skip this step entirely and go to 1A instead.
Some steps in this document require priviledged access, and you'll want to limit access to the cert files to all but the root user. So you should su to root and create a working directory that only root has read/write access to (for example: mkdir certwork, chmod 600 certwork). Go to that directory.
In this step you'll take the place of VeriSign, Thawte, etc. You'll first build the CA key, then build the certificate itself.
The Common Name (CN) of the CA and the Server certificates must NOT match or else a naming collision will occur and you'll get errors later on. In this step, you'll provide the CA entries. In a step below, you'll provide the Server entries. In this example, I just added "CA" to the CA's CN field, to distinguish it from the Server's CN field. Use whatever schema you want, just make sure the CA and Server entries are not identical.
CA:
Common Name (CN): www.somesite.edu CA
Organization (O): Somesite
Organizational Unit (OU): Development
Server:
Common Name (CN): www.somesite.edu
Organization (O): Somesite
Organizational Unit (OU): Development
If you don't have a fully qualified domain name, you should use the IP that you'll be using to access your SSL site for Common Name (CN). But, again, make sure that something differentiates the entry of the CA's CN from the Server's CN.
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Generate a server key and request for signing (csr).
This step creates a server key, and a request that you want it signed (the .csr file) by a Certificate Authority (the one you just created in Step #1B above.)
Think carefully when inputting a Common Name (CN) as you generate the .csr file below. This should match the DNS name, or the IP address you specify in your Apache configuration. If they don't match, client browsers will get a "domain mismatch" message when going to your https web server. If you're doing this for home use, and you don't have a static IP or DNS name, you might not even want worry about the message (but you sure will need to worry if this is a production/public server). For example, you could match it to an internal and static IP you use behind your router, so that you'll never get the "domain mismatch" message if you're accessing the computer on your home LAN, but will always get that message when accessing it elsewhere. Your call -- is your IP stable, do you want to repeat these steps every time your IP changes, do you have a DNS name, do you mainly use it inside your home or LAN, or outside?
openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
Sign the certificate signing request (csr) with the self-created Certificate Authority (CA) that you made earlier.
Note that 365 days is used here. After a year you'll need to do this again.
Note also that I set the serial number of the signed server certificate to "01". Each time you do this, especially if you do this before a previously-signed certificate expires, you'll need to change the serial key to something else -- otherwise everyone who's visited your site with a cached version of your certificate will get a browser warning message to the effect that your certificate signing authority has screwed up -- they've signed a new key/request, but kept the old serial number. There are a couple ways to rectify that. crl's (certificate revocation list) is one method, but beyond the scope of the document. Another method is for all clients which have stored the CA certificate to go into their settings and delete the old one manually. But for the purposes of this document, we'll just avoid the problem. (If you're a sysadmin of a production system and your server.key is compromised, you'll certainly need to worry.)
The command below does a number of things. It takes your signing request (csr) and makes a one-year valid signed server certificate (crt) out of it. In doing so, we need to tell it which Certificate Authority (CA) to use, which CA key to use, and which Server key to sign. We set the serial number to 01, and output the signed key in the file named server.crt. If you do this again after people have visited your site and trusted your CA (storing it in their browser), you might want to use 02 for the next serial number, and so on. You might create some scheme to make the serial number more "official" in appearance or makeup but keep in mind that it is fully exposed to the public in their web browsers, so it offers no additional security in itself.
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
To examine the components if you're curious:
openssl rsa -noout -text -in server.key
openssl req -noout -text -in server.csr
openssl rsa -noout -text -in ca.key
openssl x509 -noout -text -in ca.crt
Make a server.key which doesn't cause Apache to prompt for a password.
Here we create an insecure version of the server.key. The insecure one will be used for when Apache starts, and will not require a password with every restart of the web server. But keep in mind that while this means you don't have to type in a password when restarting Apache (or worse -- coding it somewhere in plaintext), it does mean that anyone obtaining this insecure key will be able to decrypt your transmissions. Guard it for permissions VERY carefully.
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
These files are quite sensitive and should be guarded for permissions very carefully. Chown them to root, if you're not already sudo'd to root. I've found that you can chmod 000 them. That is, root will always retain effective 600 (read) rights on everything.
(2) Copy files into position and tweak Apache.
Some professors like to pause for a moment after a long lecture, and do a little recap. It's a good pedagogical tool, so let's do so here. If you took route 1A above, you should have four files in a working directory:
server.crt: The self-signed server certificate.
server.csr: Server certificate signing request.
server.key: The private server key, does not require a password when starting Apache.
server.key.secure: The private server key, it does require a password when starting Apache.
If you took route 1B and created a CA, you'll have two additional files:
ca.crt: The Certificate Authority's own certificate.
ca.key: The key which the CA uses to sign server signing requests.
The CA files are important to keep if you want to sign additional server certificates and preserve the same CA. You can reuse these so long as they remain secure, and haven't expired.
At a bare minimum, the following considerations must now be addressed:
* You'll need a virtual host and document root set up for the SSL instance.
* You'll need to turn on the SSL engine and enable/load the SSL module.
* Apache must reference server.crt and server.key somewhere in its configuration.
* Apache must be listening to a port for which SSL is enabled (443 is default).
The particulars differ between Linux distros and versions of Apache. I'm only able to keep the Setting up SSL: Ubuntu and Apache 2 documentation current due to time constraints. Those steps should apply broadly to Debian-based distros with little or no modification. Red Hat and openSUSE commentary is kept online here for historical purposes.
Setting up SSL: Ubuntu and Apache 2
Setting up SSL: Red Hat and Apache 1.3.x
Setting up SSL: openSUSE
Credit : http://www.tc.umn.edu/~brams006/selfsign.html
Thursday, March 3, 2011
HowTo make two instance of postfix running on same machine
HowTo make two instance of postfix running on same machine
Posted by Nikesh Jauhari
http://linuxpoison.blogspot.com/2008/02/howto-make-two-instance-of-postfix.html
What's involved?
Creating a second instance of Postfix from an existing one involves the following steps:
1. Add an IP address to the server
2. Copy the /etc/postfix directory and all files
3. Create an additional spool directory
4. Edit the config files
5. Create startup and administration scripts
Step one: Add an IP address
The second instance of Postfix will be used for all outbound e-mail. Users will configure their e-mail clients to connect to that IP as their "SMTP server".
Follow the procedure appropriate to your server's version of Linux to add a second IP. The new IP can exist on the same network card as the first (eg. as device eth0:1 on Linux) or can be tied to a second NIC, whichever best suits your requirements.
The new IP address must resolve to a name. Either add a name for it in your DNS, or add an entry in the server's /etc/hosts file. Postfix will not work unless the IP address resolves to a name on the server Postfix is installed on.
As an alternative, the new instance can share the same IP but receive mail on a port other than port 25. We won't show that here, but it's an alternative to be aware of.
Step two: copy /etc/postfix
Copy your existing /etc/postfix directory to /etc/postfix-out:
cp -rp /etc/postfix /etc/postfix-out
The new directory should have all the files with the same ownership and permissions as the original.
To make the next step easier, edit file /etc/postfix-out/main.cf. Change the following setting or add it if it does not exist:
queue_directory = /var/spool/postfix-out
Save the changes to the file before proceeding to the next step.
Step three: create an additional spool directory
Each instance of Postfix must have it's own mail spool directory. To avoid file conflicts, the default directory /var/spool/postfix must not be shared among instances.
Create a directory named /var/spool/postfix-out and let Postfix create the appropriate subdirectories and permissions:
mkdir /var/spool/postfix-out
postfix -c /etc/postfix-out check
The result should be directory /var/spool/postfix-out containing something similar to the following:
drwxr-xr-x 14 root root 336 Jan 30 10:20 .
drwxr-xr-x 15 root root 384 Jan 30 10:20 ..
drwx------ 2 postfix root 48 Jan 30 10:20 active
drwx------ 2 postfix root 48 Jan 30 10:20 bounce
drwx------ 2 postfix root 48 Jan 30 10:20 corrupt
drwx------ 2 postfix root 48 Jan 30 10:20 defer
drwx------ 2 postfix root 48 Jan 30 10:20 deferred
drwx------ 2 postfix root 48 Jan 30 10:20 flush
drwx------ 2 postfix root 48 Jan 30 10:20 incoming
drwx-wx--- 2 postfix postdrop 48 Jan 30 10:20 maildrop
drwxr-xr-x 2 root root 48 Jan 30 10:20 pid
drwx------ 2 postfix root 48 Jan 30 10:20 private
drwx--x--- 2 postfix postdrop 48 Jan 30 10:20 public
drwx------ 2 postfix root 48 Jan 30 10:20 saved
If directory /var/spool/postfix contains directories named etc, usr and lib, your first Postfix instance was probably installed chrooted: if those directories exist, manually copy them to /var/spool/postfix-out:
cp -rp /var/spool/postfix/etc /var/spool/postfix-out
cp -rp /var/spool/postfix/usr /var/spool/postfix-out
cp -rp /var/spool/postfix/lib /var/spool/postfix-out
Step four: edit the config files
Edit the file /etc/postfix/main.cf and add the following near the bottom of the file:
alternate_config_directories = /etc/postfix-out
The above setting is required to inform the Postfix daemons about the second instance.
Next, edit the file /etc/postfix-out/main.cf and change the following setting:
inet_interfaces = second-IP-address-NAME
Note: in the above you must specify the DNS name of the second IP address, not the IP address. If the IP address does not have a DNS name, add an entry for it to /etc/hosts so it can be resolved locally on the server.
You should also remove settings such as reject_maps_rbl and content filtering that only need to be applied to inbound e-mail, and change syslog_facility so logging of outbound mail sent to a different file than inbound.
You might also want to change the setting myhostname so the second instance uses a name difference than the first (eg. "mx1-out"). This is required if the two instances will exchange mail with each other, otherwise Postfix will complain mail "loops back to myself".
Lastly, you can force mail being sent from the outbound instance to send using the same IP address as the inbound instance. This is useful when the mail server is behind a firewall and you want only one IP address to communicate with the Internet. To send mail on a different IP, add the setting smtp_bind_address to main.cf similar to the following:
smtp_bind_address = 192.168.1.1
(Of course, replace the IP address above with your own server's inbound SMTP IP address)
Step five: Create startup and administration scripts
Startup script
The second instance can be started using the normal postfix start command, except you must point to the other configuration directory. For example:
postfix -c /etc/postfix-out start
To create a startup script for the second instance, either edit your existing Postfix startup script and add the above command after the existing postfix start command, or copy the existing startup script to a new name and change the copy. If you copy the start script, be sure to also follow your operating system's instructions for installing a new init script (for example, chkconfig on Redhat Linux, update-rc.d on Debian Linux).
Posted by Nikesh Jauhari
http://linuxpoison.blogspot.com/2008/02/howto-make-two-instance-of-postfix.html
What's involved?
Creating a second instance of Postfix from an existing one involves the following steps:
1. Add an IP address to the server
2. Copy the /etc/postfix directory and all files
3. Create an additional spool directory
4. Edit the config files
5. Create startup and administration scripts
Step one: Add an IP address
The second instance of Postfix will be used for all outbound e-mail. Users will configure their e-mail clients to connect to that IP as their "SMTP server".
Follow the procedure appropriate to your server's version of Linux to add a second IP. The new IP can exist on the same network card as the first (eg. as device eth0:1 on Linux) or can be tied to a second NIC, whichever best suits your requirements.
The new IP address must resolve to a name. Either add a name for it in your DNS, or add an entry in the server's /etc/hosts file. Postfix will not work unless the IP address resolves to a name on the server Postfix is installed on.
As an alternative, the new instance can share the same IP but receive mail on a port other than port 25. We won't show that here, but it's an alternative to be aware of.
Step two: copy /etc/postfix
Copy your existing /etc/postfix directory to /etc/postfix-out:
cp -rp /etc/postfix /etc/postfix-out
The new directory should have all the files with the same ownership and permissions as the original.
To make the next step easier, edit file /etc/postfix-out/main.cf. Change the following setting or add it if it does not exist:
queue_directory = /var/spool/postfix-out
Save the changes to the file before proceeding to the next step.
Step three: create an additional spool directory
Each instance of Postfix must have it's own mail spool directory. To avoid file conflicts, the default directory /var/spool/postfix must not be shared among instances.
Create a directory named /var/spool/postfix-out and let Postfix create the appropriate subdirectories and permissions:
mkdir /var/spool/postfix-out
postfix -c /etc/postfix-out check
The result should be directory /var/spool/postfix-out containing something similar to the following:
drwxr-xr-x 14 root root 336 Jan 30 10:20 .
drwxr-xr-x 15 root root 384 Jan 30 10:20 ..
drwx------ 2 postfix root 48 Jan 30 10:20 active
drwx------ 2 postfix root 48 Jan 30 10:20 bounce
drwx------ 2 postfix root 48 Jan 30 10:20 corrupt
drwx------ 2 postfix root 48 Jan 30 10:20 defer
drwx------ 2 postfix root 48 Jan 30 10:20 deferred
drwx------ 2 postfix root 48 Jan 30 10:20 flush
drwx------ 2 postfix root 48 Jan 30 10:20 incoming
drwx-wx--- 2 postfix postdrop 48 Jan 30 10:20 maildrop
drwxr-xr-x 2 root root 48 Jan 30 10:20 pid
drwx------ 2 postfix root 48 Jan 30 10:20 private
drwx--x--- 2 postfix postdrop 48 Jan 30 10:20 public
drwx------ 2 postfix root 48 Jan 30 10:20 saved
If directory /var/spool/postfix contains directories named etc, usr and lib, your first Postfix instance was probably installed chrooted: if those directories exist, manually copy them to /var/spool/postfix-out:
cp -rp /var/spool/postfix/etc /var/spool/postfix-out
cp -rp /var/spool/postfix/usr /var/spool/postfix-out
cp -rp /var/spool/postfix/lib /var/spool/postfix-out
Step four: edit the config files
Edit the file /etc/postfix/main.cf and add the following near the bottom of the file:
alternate_config_directories = /etc/postfix-out
The above setting is required to inform the Postfix daemons about the second instance.
Next, edit the file /etc/postfix-out/main.cf and change the following setting:
inet_interfaces = second-IP-address-NAME
Note: in the above you must specify the DNS name of the second IP address, not the IP address. If the IP address does not have a DNS name, add an entry for it to /etc/hosts so it can be resolved locally on the server.
You should also remove settings such as reject_maps_rbl and content filtering that only need to be applied to inbound e-mail, and change syslog_facility so logging of outbound mail sent to a different file than inbound.
You might also want to change the setting myhostname so the second instance uses a name difference than the first (eg. "mx1-out"). This is required if the two instances will exchange mail with each other, otherwise Postfix will complain mail "loops back to myself".
Lastly, you can force mail being sent from the outbound instance to send using the same IP address as the inbound instance. This is useful when the mail server is behind a firewall and you want only one IP address to communicate with the Internet. To send mail on a different IP, add the setting smtp_bind_address to main.cf similar to the following:
smtp_bind_address = 192.168.1.1
(Of course, replace the IP address above with your own server's inbound SMTP IP address)
Step five: Create startup and administration scripts
Startup script
The second instance can be started using the normal postfix start command, except you must point to the other configuration directory. For example:
postfix -c /etc/postfix-out start
To create a startup script for the second instance, either edit your existing Postfix startup script and add the above command after the existing postfix start command, or copy the existing startup script to a new name and change the copy. If you copy the start script, be sure to also follow your operating system's instructions for installing a new init script (for example, chkconfig on Redhat Linux, update-rc.d on Debian Linux).
Wednesday, February 16, 2011
Automatic Linux Server Backup using SSH
Example is given to backup files from hostserver to remoteserver.
---------Logging from hostserver to remoteserver without giving passwords--------
First you should create a user in both servers, in my case the username is backup_user.
I created them in both machine.
Then in hostserver, I created SSH private and Public key pairs using ssh-keygen (as given below) so that backup can be automated without inputing passwords. I did this as backup_user
#ssh-keygen -t rsa -b 1024
When you execute above command it will ask for several things, leave all them as default.
Then at one place it will ask for passphrase. At that point, without enter any password press enter key. (In other words, leave them blank)
Then you may see two files, id_rsa and id_rsa.pub in /home/backup_user/.ssh/
Now you should copy the pub key to the remote server. To do this,
execute following command :
ssh-copy-id -i /home/backup_user/id_rsa.pub backup_user@remoteserver
Now you should be able to login from hostserver to remoteserver without giving any password.
--------Making backups from hostserver to remoteserver------------------------------
**We need to create a script to make the nessary backups to backup_user's home directory with the date label.
eg: Following script will create a folder with date label and server name (eg. 20101223-hostserver).
Then it makes an archive of required folder in the newly created folder. (eg. in our case we get backup of mysql dir)
#backup script .This is saved in /home/backup_user/bak_script
mkdir /home/backup_user/`date +%Y%m%d`-hostserver
tar cfz /home/backup_user/`date +%Y%m%d`-hostserver/something.tar.gz /var/lib/mysql/xxxxx
chown backup_user:backup_user /home/backup_user/ * -R
****Then we should run this script as a ROOT level cronjob
Therefore first become as super user and execute following commands
crontab -e
and then add following
30 18 * * * /home/backup_user/bak_script
Above command says that bak_scipt has to be executed at 6.30 pm everyday.
****Following script is to copy the files to remoteserver
#script to archieve and then copy that to remoteserver. This is saved in /home/backup_user/copy_script
tar cfz /home/backup_user/`date +%Y%m%d`-hostserver.tar.gz /home/backup_user/`date +%Y%m%d`-hostserver
scp `date +%Y%m%d`-hostserver.tar.gz backup_user@192.248.8.17:/home/backup_user/backups
Then we should add a backup_user level cron to the above scipt and run that with some time after the above script
(USER level cron job)
crontab -e
and add folling things
30 19 * * * /home/backup_user/copy_script
According to this, all the files that we specified first backedup to hostserver it self at 18.30.
Then it will be transfered to remoteserver at 19.30. It is recommended to give sufficient time between copying files to server it self and copying to remoteserver.
Good luck
---------Logging from hostserver to remoteserver without giving passwords--------
First you should create a user in both servers, in my case the username is backup_user.
I created them in both machine.
Then in hostserver, I created SSH private and Public key pairs using ssh-keygen (as given below) so that backup can be automated without inputing passwords. I did this as backup_user
#ssh-keygen -t rsa -b 1024
When you execute above command it will ask for several things, leave all them as default.
Then at one place it will ask for passphrase. At that point, without enter any password press enter key. (In other words, leave them blank)
Then you may see two files, id_rsa and id_rsa.pub in /home/backup_user/.ssh/
Now you should copy the pub key to the remote server. To do this,
execute following command :
ssh-copy-id -i /home/backup_user/id_rsa.pub backup_user@remoteserver
Now you should be able to login from hostserver to remoteserver without giving any password.
--------Making backups from hostserver to remoteserver------------------------------
**We need to create a script to make the nessary backups to backup_user's home directory with the date label.
eg: Following script will create a folder with date label and server name (eg. 20101223-hostserver).
Then it makes an archive of required folder in the newly created folder. (eg. in our case we get backup of mysql dir)
#backup script .This is saved in /home/backup_user/bak_script
mkdir /home/backup_user/`date +%Y%m%d`-hostserver
tar cfz /home/backup_user/`date +%Y%m%d`-hostserver/something.tar.gz /var/lib/mysql/xxxxx
chown backup_user:backup_user /home/backup_user/ * -R
****Then we should run this script as a ROOT level cronjob
Therefore first become as super user and execute following commands
crontab -e
and then add following
30 18 * * * /home/backup_user/bak_script
Above command says that bak_scipt has to be executed at 6.30 pm everyday.
****Following script is to copy the files to remoteserver
#script to archieve and then copy that to remoteserver. This is saved in /home/backup_user/copy_script
tar cfz /home/backup_user/`date +%Y%m%d`-hostserver.tar.gz /home/backup_user/`date +%Y%m%d`-hostserver
scp `date +%Y%m%d`-hostserver.tar.gz backup_user@192.248.8.17:/home/backup_user/backups
Then we should add a backup_user level cron to the above scipt and run that with some time after the above script
(USER level cron job)
crontab -e
and add folling things
30 19 * * * /home/backup_user/copy_script
According to this, all the files that we specified first backedup to hostserver it self at 18.30.
Then it will be transfered to remoteserver at 19.30. It is recommended to give sufficient time between copying files to server it self and copying to remoteserver.
Good luck
Tuesday, January 4, 2011
email server migration - Sendmail - Postfix - LDAP
I am given with a task to migrate emails from a sendmail server to postfix server. The was a complex task, because of following reason.
- There were many virtual domains
- The sendmail was using mailbox and postfix was using maildir
- The sendmail authentications was on passd files and the postfix's user profile was on LDAP
- The users who are migrated to postfix will get a emails with new domain which was there in postfix and users should be able to use both emails using single account.
I learnt a lot by doing this. I will share that here.
Migrating virtual domain accounts
Sendmail had several virtual domains
eg. xxx.ttt.lk, nnn.mmm.lk etc. All these were created under /etc/vmail/alias.xxx.yyy.lk, alias.nnn.mmm.lk etc. In /etc/vmail the respecting passwd and shadow files also were there.
There I extracted all the users information and made a ldif file so that I can create users on LDAP server. To do that I developed a PHP scipt which reads the information from an excel file and output a ldif file.
When I do this, I add all the mail accounts are mail alias in LDAP.
Another issue I found when I do this was, some password on the old sendmail system was in Unix crypt format. However in the new postfix server it was decided to use the md5crypt. Since the Unix crypt use fixed salting, I used a default md5crypted password for existing Unix Crypted password.
Using the generated ldif file, I created the accounts on LDAP server
Then another issue was how to have all the sendmail virtual domains in postfix. I found that in postfix configuration there is a pasrameter called virtual_domains where I listed all the virtual domains of sendmail so that the postfix will start allowing those domains.
In addition to that I had to do the change in the DNS server as well so that here after all the xxx.yyy.lk and nnn.mmm.lk will be sent to new postfix server.
Moving mailbox to maildir
Other issues was moving existing mailbox of users in sendmail to maildirs in postfix.
To do this, I used a tool called mb2md (http://batleth.sapienti-sat.org/projects/mb2md/)
This tool has several options.
However to use this tool, your system also should have date::parse perl
I installed this using following way :
perl -MCPAN -e 'SHELL'
Install Date::parse
After installing this I added executable access to downloaded mb2md perl script.
Thereafter I ran the script as follows :
./mb2md -s /var/spool/mail/user1 -d /opt/maildirs/user1
Then I also prepared the existing mailbox folders (which were located in /vhome/user1) as maildirs using following command :
./mb2md -s /vhome/user1 -R -d /opt/maildirs/user1
when I ran these command it was showing how many messages got extacted and how many folders have been created etc.
After creating these maildirs I moved them to the respecting locations in the postfix server and provided the owenership to vmail (in my case it was vmail. This user should be defined in main.cf file.
Hope this will help
Enjoy!
- There were many virtual domains
- The sendmail was using mailbox and postfix was using maildir
- The sendmail authentications was on passd files and the postfix's user profile was on LDAP
- The users who are migrated to postfix will get a emails with new domain which was there in postfix and users should be able to use both emails using single account.
I learnt a lot by doing this. I will share that here.
Migrating virtual domain accounts
Sendmail had several virtual domains
eg. xxx.ttt.lk, nnn.mmm.lk etc. All these were created under /etc/vmail/alias.xxx.yyy.lk, alias.nnn.mmm.lk etc. In /etc/vmail the respecting passwd and shadow files also were there.
There I extracted all the users information and made a ldif file so that I can create users on LDAP server. To do that I developed a PHP scipt which reads the information from an excel file and output a ldif file.
When I do this, I add all the mail accounts are mail alias in LDAP.
Another issue I found when I do this was, some password on the old sendmail system was in Unix crypt format. However in the new postfix server it was decided to use the md5crypt. Since the Unix crypt use fixed salting, I used a default md5crypted password for existing Unix Crypted password.
Using the generated ldif file, I created the accounts on LDAP server
Then another issue was how to have all the sendmail virtual domains in postfix. I found that in postfix configuration there is a pasrameter called virtual_domains where I listed all the virtual domains of sendmail so that the postfix will start allowing those domains.
In addition to that I had to do the change in the DNS server as well so that here after all the xxx.yyy.lk and nnn.mmm.lk will be sent to new postfix server.
Moving mailbox to maildir
Other issues was moving existing mailbox of users in sendmail to maildirs in postfix.
To do this, I used a tool called mb2md (http://batleth.sapienti-sat.org/projects/mb2md/)
This tool has several options.
However to use this tool, your system also should have date::parse perl
I installed this using following way :
perl -MCPAN -e 'SHELL'
Install Date::parse
After installing this I added executable access to downloaded mb2md perl script.
Thereafter I ran the script as follows :
./mb2md -s /var/spool/mail/user1 -d /opt/maildirs/user1
Then I also prepared the existing mailbox folders (which were located in /vhome/user1) as maildirs using following command :
./mb2md -s /vhome/user1 -R -d /opt/maildirs/user1
when I ran these command it was showing how many messages got extacted and how many folders have been created etc.
After creating these maildirs I moved them to the respecting locations in the postfix server and provided the owenership to vmail (in my case it was vmail. This user should be defined in main.cf file.
Hope this will help
Enjoy!
Friday, August 13, 2010
Configure TSIG between DNS master and slave
Generating SIG(0) Keys
SIG(0) keys are generated with the following command:
$ dnssec-keygen -a -b -n HOST
is the desired algorithm of the key and can be any of the following values: RSAMD5, RSASHA1, DSA. We recommend that you use RSAMD5.
is the desired size in bits of the key and the ranges are different depending on the algorithm:
* RSAMD5: 512 to 4096 (recommended size 1024)
* RSASHA1: 512 to 4096 (recommended size 1024)
* DSA: 512 to 1024 (must be divisible by 64, recommended size 1024)
is the name of the key. Since it must be published in the zone file, it should be a subname of the zone that it is being published in. It is recommended that the keyname be the fully qualified domain name of the host so that the update-policy self works correctly. (see Section 6.2.22.4 of the BIND ARM for more information on update-policy).
The key will be stored in the file K++.private
is an identity tag to be able to differentiate between different keys under the same name.
There will also be a corresponding K++.key file that contains a DNS KEY resource record formatted for inclusion in the zone file.
One possible problem that can be encountered with dnssec-keygen is that it might use up all the entropy in /dev/random before it is done generating the key. This will make dnssec-keygen appear to hang, when in fact it is simply waiting for more entropy. One solution to this is to use the -r parameter that allows you to specify another random device, such as /dev/urandom.
Configuring the DNS Server
Configuring the server also depends on which type of key you choose.
TSIG Keys
The /etc/named.conf file must be edited to configure the server for dynamic update.
The first step is to configure the server to use the key. This is accomplished with the following lines in the /etc/named.conf file:
key {
algorithm HMAC-MD5;
secret "";
};
is the name of the key chosen when the key was generated (See the previous step, Generating TSIG keys).
is the string after the Key: line in the generated key file (See the previous step, Generating TSIG keys).
SIG(0) Keys
Only the zone file must be edited to configure the server for dynamic update with sig(0). No changes are needed in /etc/named.conf as the client's public, not private, key is in the zone file.
The first step is to add the generated key, using the K++.key file, to the zone file. This generated key file contains a properly formatted resource record that can be simply copy-and-pasted into the zone file.
If you are using DNSSEC signed zones, then the next step is to resign your zone.
Allowing Updates
The final step is to configure the zone to allow updates using the key. The following statements should be added to the zone options block in /etc/named.conf. The simplest configuration is to add:
update-policy {
grant name A TXT;
};
e.g.
zone "example.com" {
type master;
file "master/example.com";
update-policy {
grant foo.example.com. name foo.example.com. A TXT;
};
};
Complex example with a number of hosts allowed to update only their own A+TXT records and one master key allowed to update anything:
update-policy {
grant host1.example.com. name host1.example.com. A TXT;
grant host2.example.com. name host2.example.com. A TXT;
grant host3.example.com. name host3.example.com. A TXT;
grant host4.example.com. name host4.example.com. A TXT;
grant bofh.example.com. subdomain example.com. ANY;
};
Simple example where every key can update the A+TXT records of its matching hostname:
update-policy {
grant * self * A TXT;
};
Note: update-policy is described further in Section 6.2.22.4 of the BIND ARM.
The allow-update statement can also be used, which allows the key to modify any data in the zone. Using more fine grained access control with update-policy is recommended.
allow-update {
key ;
};
is the name of the key chosen when the key was generated (See the previous step, Keys)
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html
SIG(0) keys are generated with the following command:
$ dnssec-keygen -a -b -n HOST
is the desired algorithm of the key and can be any of the following values: RSAMD5, RSASHA1, DSA. We recommend that you use RSAMD5.
is the desired size in bits of the key and the ranges are different depending on the algorithm:
* RSAMD5: 512 to 4096 (recommended size 1024)
* RSASHA1: 512 to 4096 (recommended size 1024)
* DSA: 512 to 1024 (must be divisible by 64, recommended size 1024)
is the name of the key. Since it must be published in the zone file, it should be a subname of the zone that it is being published in. It is recommended that the keyname be the fully qualified domain name of the host so that the update-policy self works correctly. (see Section 6.2.22.4 of the BIND ARM for more information on update-policy).
The key will be stored in the file K++.private
is an identity tag to be able to differentiate between different keys under the same name.
There will also be a corresponding K++.key file that contains a DNS KEY resource record formatted for inclusion in the zone file.
One possible problem that can be encountered with dnssec-keygen is that it might use up all the entropy in /dev/random before it is done generating the key. This will make dnssec-keygen appear to hang, when in fact it is simply waiting for more entropy. One solution to this is to use the -r parameter that allows you to specify another random device, such as /dev/urandom.
Configuring the DNS Server
Configuring the server also depends on which type of key you choose.
TSIG Keys
The /etc/named.conf file must be edited to configure the server for dynamic update.
The first step is to configure the server to use the key. This is accomplished with the following lines in the /etc/named.conf file:
key {
algorithm HMAC-MD5;
secret "";
};
is the name of the key chosen when the key was generated (See the previous step, Generating TSIG keys).
is the string after the Key: line in the generated key file (See the previous step, Generating TSIG keys).
SIG(0) Keys
Only the zone file must be edited to configure the server for dynamic update with sig(0). No changes are needed in /etc/named.conf as the client's public, not private, key is in the zone file.
The first step is to add the generated key, using the K++.key file, to the zone file. This generated key file contains a properly formatted resource record that can be simply copy-and-pasted into the zone file.
If you are using DNSSEC signed zones, then the next step is to resign your zone.
Allowing Updates
The final step is to configure the zone to allow updates using the key. The following statements should be added to the zone options block in /etc/named.conf. The simplest configuration is to add:
update-policy {
grant name A TXT;
};
e.g.
zone "example.com" {
type master;
file "master/example.com";
update-policy {
grant foo.example.com. name foo.example.com. A TXT;
};
};
Complex example with a number of hosts allowed to update only their own A+TXT records and one master key allowed to update anything:
update-policy {
grant host1.example.com. name host1.example.com. A TXT;
grant host2.example.com. name host2.example.com. A TXT;
grant host3.example.com. name host3.example.com. A TXT;
grant host4.example.com. name host4.example.com. A TXT;
grant bofh.example.com. subdomain example.com. ANY;
};
Simple example where every key can update the A+TXT records of its matching hostname:
update-policy {
grant * self * A TXT;
};
Note: update-policy is described further in Section 6.2.22.4 of the BIND ARM.
The allow-update statement can also be used, which allows the key to modify any data in the zone. Using more fine grained access control with update-policy is recommended.
allow-update {
key ;
};
is the name of the key chosen when the key was generated (See the previous step, Keys)
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html
Wednesday, July 14, 2010
Reset mysql root password - in LAMP / XAMPP
Once I forgot the mysql root password of my laptop computer in which I have Fedora 10 and also XAMPP running in it.
When I searched on Web there are soooo many solutions and none of them worked for me. However I could get un understanding about the issue....
With that I worked out in following way to get rid of the issue :
1. Stop mysqld
2. start /opt/lampp/sbin/mysqld --skip-grant-priviledges --user=nobody
3. open new terminal and type : mysql -u root
4. excute following commands in order :
shell> mysql
mysql> UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';
mysql> FLUSH PRIVILEGES;
mysql> exit
Now its done.
You may think that you can do use phpmyadmin after the step-2 to reset the root password. But it was not working for me though I have a phpmyadmin. So I worked our in mysql prompt.
After this everything were working wellll...
but I was not sure with one thing that I could not stop / restart mysql service as usual...
SO what I did is, I restarted the machine... SO simple ha!... but this is not possible in production servers....
Anyone of you know the solution for this?
Enjoy!....
When I searched on Web there are soooo many solutions and none of them worked for me. However I could get un understanding about the issue....
With that I worked out in following way to get rid of the issue :
1. Stop mysqld
2. start /opt/lampp/sbin/mysqld --skip-grant-priviledges --user=nobody
3. open new terminal and type : mysql -u root
4. excute following commands in order :
shell> mysql
mysql> UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';
mysql> FLUSH PRIVILEGES;
mysql> exit
Now its done.
You may think that you can do use phpmyadmin after the step-2 to reset the root password. But it was not working for me though I have a phpmyadmin. So I worked our in mysql prompt.
After this everything were working wellll...
but I was not sure with one thing that I could not stop / restart mysql service as usual...
SO what I did is, I restarted the machine... SO simple ha!... but this is not possible in production servers....
Anyone of you know the solution for this?
Enjoy!....
Wednesday, June 30, 2010
Launch of .ලංකා and .இலங்கை domains
28th of June 2010, the .ලංකා and .இலங்கை were formally opened for registration. Now any people who is having a .lk domain can request for .ලංකා and .இலங்கை domains for free.
This launch was held at Mount Lavinia hotel and many people around the world have participated in it including an ICANN board member.
This is an historic event. Because .lk domain was added to root servers on 15th June 1990. Till that date the Sri Lanka was identified the two words .lk. But from 28th June 2010 onwards the country can be indexed using .ලංකා and .இலங்கை.
The another notable point is, these are the two domains which are going to be added to the root servers in the South Asian region and .இலங்கை is the first Tamil domain which is going to be added.
Though the only people in Sri Lanka can access these Sinhala and Tamil domain now, from august onwards all the world should be able to type URL in Sinhala and Tamil and reach respective web sites.
currently there are few IDNs assigned to government sites.
eg
http://தளம்.பாராளுமன்றம்.இலங்கை
http://වෙබ්.පාර්ලිමේන්තුව.ලංකා
I am very happy that I also could take part in this developments and event.
visit www.nic.lk to register and also visit www.idns.lk to get more information about this.
This launch was held at Mount Lavinia hotel and many people around the world have participated in it including an ICANN board member.
This is an historic event. Because .lk domain was added to root servers on 15th June 1990. Till that date the Sri Lanka was identified the two words .lk. But from 28th June 2010 onwards the country can be indexed using .ලංකා and .இலங்கை.
The another notable point is, these are the two domains which are going to be added to the root servers in the South Asian region and .இலங்கை is the first Tamil domain which is going to be added.
Though the only people in Sri Lanka can access these Sinhala and Tamil domain now, from august onwards all the world should be able to type URL in Sinhala and Tamil and reach respective web sites.
currently there are few IDNs assigned to government sites.
eg
http://தளம்.பாராளுமன்றம்.இலங்கை
http://වෙබ්.පාර්ලිමේන්තුව.ලංකා
I am very happy that I also could take part in this developments and event.
visit www.nic.lk to register and also visit www.idns.lk to get more information about this.
Tuesday, June 29, 2010
Niue - A country - Population is 1000
I had a chance to attend APTLD (Asia Pacific Top Level Domain) meeting which was held at Mount Lavinia hotel on 27 - 28 June, 2010. Many people from Asia pacific region who maintain Domain registries also came for that meeting.
I met a person called Stafford Guest. His native country is Nieu!
Nieu! first time I hear that name. This is an island located near New Zealand. Though it got the Independence in 1974, still getting the symbotic support from New Zealand.
The interesting things to note are :
- Population of the country is 1000!
- The total intetnet bandwidth the country has is 4mbps :-) I have more than that in my PC
- Only one hotel is there
- Only flights can reach there and also those operates once in a week. Therefore if you would like to attend a meeting some there else you may need to leave atlease 8 days before.....
- No Cinema...
- No big shopping malls....
Cant Believe isnt it!
I was really supprised when he tells all these!
But you know it looks soooooo beautiful. Nice beaches (though it rough)... Full of cocunut treess (I saw some picture in Google images)
Also found that Nieu means "Behold! Coconut"
I met a person called Stafford Guest. His native country is Nieu!
Nieu! first time I hear that name. This is an island located near New Zealand. Though it got the Independence in 1974, still getting the symbotic support from New Zealand.
The interesting things to note are :
- Population of the country is 1000!
- The total intetnet bandwidth the country has is 4mbps :-) I have more than that in my PC
- Only one hotel is there
- Only flights can reach there and also those operates once in a week. Therefore if you would like to attend a meeting some there else you may need to leave atlease 8 days before.....
- No Cinema...
- No big shopping malls....
Cant Believe isnt it!
I was really supprised when he tells all these!
But you know it looks soooooo beautiful. Nice beaches (though it rough)... Full of cocunut treess (I saw some picture in Google images)
Also found that Nieu means "Behold! Coconut"
Subscribe to:
Comments (Atom)