Hey Guys, I am specifying this post for everyone who is going to use it as I searched number of pages but could not find all these information at a single page.
So basically there are three steps to get your website live on plain (No control panel) centos server.
1. Register your nameservers and domain at your registrar end.
2. Set up DNS including nameservers and DNS zones
3. Set up web user and apache entries.
I am considering that you already know about domain/nameservers registrationso I am moving ahead to 2nd step.
Nameservers setup
CentOS 4 : chroot DNS with BIND
February 4, 2007 - 23 comments
I won’t go into the details of what is DNS, or the difference between an A record and a CNAME record.. just a quick howto to set up a chrooted DNS server using Bind under CentOS in a mere 5 minutes..
Howto available for CentOS 5 : http://www.wains.be/index.php/2007/12/13/centos-5-chroot-dns-with-bind/
1. Install packages :
yum install bind bind-chroot bind-libs bind-utils
2. Configure rndc :
The rndc tool allow to get some useful info on your dns server (stats, status, etc.) so you better get it set up.
rndc.conf is staying out of the chroot cage, for clarity we’ll move it into the chroot cage
cp /etc/rndc.conf /var/named/chroot/etc
Let’s make a symbolic link back in /etc, so we get 3 symlinks pointing to files in the cage (rndc.conf, rndc.key, named.conf) :
cd /etc
ln -s /var/named/chroot/etc/rndc.conf -f
Create the rndc key, this command will create your key and store it under /etc/rndc.key :
rndc-confgen -a
/etc/rndc.key looks like this :
key "rndc-key" {
algorithm hmac-md5;
secret "ZK4g84WrfdfsTIQLVs59Eg==";
};
Pay close attention to the key name, rndc-confgen makes a “rndc-key” while /etc/named.conf calls “rndckey”, you’ll have to carefully edit your named.conf
Edit /etc/rndc.conf so it looks like this :
include "/etc/rndc.key";
options {
default-server localhost;
default-key "rndc-key";
};
server localhost {
key "rndc-key";
};
3. Set up BIND
Edit /etc/named.conf so it looks like this :
include "/etc/rndc.key";
// we assume our server has the IP 192.168.100.100 serving the 192.168.100.0/24 subnet
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; };
inet 192.168.100.100 allow { 192.168.100.0/24; } keys { "rndc-key"; };
};
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
recursion yes;
allow-recursion {
127.0.0.1;
192.168.100.0/24;
};
// these are the opendns servers (optional)
forwarders {
208.67.222.222;
208.67.220.220;
};
listen-on {
127.0.0.1;
192.168.100.100;
};
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
query-source address * port 53;
// so people can't try to guess what version you're running
version "REFUSED";
allow-query {
127.0.0.1;
192.168.100.0/24;
};
};
server 192.168.100.100 {
keys { rndc-key; };
};
zone "." IN {
type hint;
file "named.root";
};
// we assume we have a slave dns server with the IP 192.168.100.101
zone "test.be" IN {
type master;
file "data/test.be.zone";
allow-update { none; };
allow-transfer { 192.168.100.101; };
};
};
4. Your zones
Download named.root under /var/named/chroot/var/named :
wget http://www.internic.net/zones/named.root
Create your first zone under /var/named/chroot/var/named/data/test.be.zone (syntax may not be perfect but is working) :
$ttl 38400
test.be. IN SOA ns.test.be. admin.test.be. (
2007020400 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
test.be. IN NS ns.test.be.
test.be. IN MX 1 mx.test.be.
test.be. IN MX 5 mx2.test.be.
ns.test.be. IN A 192.168.100.10
mx.test.be. IN A 192.168.100.20
mx2.test.be. IN A 192.168.100.21
mail.test.be. IN CNAME mx.test.be.
5. Set up your server to query its own dns server
Edit /etc/resolv.conf and add this line at the top of the file :
nameserver 127.0.0.1
6. Start the service
Start the DNS server :
service named start
Make sure the service will start at reboot :
chkconfig named on
Thats it, now move ahead to set 3.
The first step, but not always a necessary step is setting up a new user. This is the preferred way to start as the /etc/skel has been preloaded with all the necessary directories and files to get new users started. If you are going to be a system administrator and you are not familiar with the /etc/skel/, please take some time learn more information about placing files in the /etc/skel/ directory to save time setting up new users. You can put default web directory such as www or public_html plus any other files and or directories you want to give to all new users.
To setup a new user you can simply use the following command (replace username with the username you want to use)
adduser -m username
Now that you have created the account, it is best to setup a password for the account. You can assign a password to the account using the following command
passwd username
You should be prompted to enter in the new password and then confirm the password. Assume a new account needs to be setup with the username of ditto. When you run the passwd ditto command you should be prompted for the password as follows.
Changing password for user ditto.
New UNIX password:
Retype new UNIX password:
Your new account is almost ready to start putting files up for the web. One thing to pass along to new system administrators is that you have to make sure you setup the right permissions on this new account so it is strongly suggested that you do this now.
Now the path to the new account may differ depending on your server. Assume for now that new users are setup in the /home/ directory. Assuming your new user “ditto” was created successfully, the new account for ditto should be /home/ditto/. Any files in your /etc/skel/ directory would be there as well. You can check this by using the following command to change directories and list the contents of the directory
cd /home/ditto && ls
In this example we have two folders for our user ditto and they are the public_html and wwwconf directories.
To change the permissions on the users ditto directory so it can be viewed by visitors, the permissions on the ditto directory must be changed to something like 755. This can be done to just ditto directory using following command:
chmod 755 /home/ditto
If you don’t know what 755 is as far as permissions, pause this tutorial and take the time to learn about chmod and what the different permissions will do for you.
Now comes the part where many configurations likely differ depending on what you have installed to run on your server. This tutorial opts to save a core httpd related .conf file in one httpd directory (conf.d) and then from there look for more .conf files in the user directory called wwwconf/. This setup is not the only one possibility in the universe and if you have an older setup or wish to do it differently that is your choice.
You can start your .conf file by copying a current one or creating a new one in your httpd/conf.d/ directory. This tutorial will assume that directory is located at /etc/httpd/conf.d/. Creat your new .conf file in vi or vim by using the following command.
sudo vim web.ditto.com.conf
This is going to be the core configuration file for your virtualhost. You will need to start the virtualhost using the tag:
The VirutalHost directive is used to enclose a group of directives which will apply only to a particular virtual host. Inside this directive you will put all the information pertaining to your site. You can put the email address to your ServerAdmin, the absolute path to the Document Root, the ServerName and any ServerAlias
ServerAdmin webmaster@localhost
Documentroot /home/ditto/public_html/
ServerName www.ditto.com
ServerAlias ditto.com
Now it is necessary to give Apache some directives that will apply to our public_html directory. To do this you will create another node inside the VirtualHost node named Directory. The Directory node here is used to enclose a group of directives which will apply only to the named directory and sub-directories of that directory (in this case the public_html directory).
Options ExecCGI FollowSymLinks +Includes
This tells Apache that the execution of CGI scripts is permitted, the server will follow symbolic links in this directory, and that server-side includes are permitted.
You will also like to have some type of error log as is very useful when troubleshooting an issue on the box, so be sure to include the following code for error logging. You can access the logs in your httpd/logs directory
ErrorLog logs/ditto.error
CustomLog logs/ditto.log combined
Now for the customized part. In order to let the user create their own Directory options another Directory directive is created that will point to a folder where other options/modifications can be made by the account user.
AllowOverride All
What this does is allows ditto to ftp or ssh into the box and create a .conf file with their own directives and options in the wwwconf/ directory. The directive inside the above tag says any directive which has the .htaccess context is allowed in .htaccess files. After this tag is closed, it can be followed up with
Include /home/ditto/wwwconf/*.conf
which tells Apache to grab any file with .conf in the wwwconf/ directory of ditto (if you didn’t know it already, the “*” is a wildcard here).
That should do it. You can now put an end to your VirtualHost node (if you have not already) and your end result should look something like
ServerAdmin webmaster@localhost
Documentroot /home/ditto/public_html/
ServerName www.ditto.com
ServerAlias ditto.com
Options ExecCGI FollowSymLinks +Includes
ErrorLog logs/ditto.error
CustomLog logs/ditto.log combined
AllowOverride All
Include /home/ditto/wwwconf/*.conf
You can now save this in the httpd/conf.d/ folder. Now if you want to add a mod re-wite or make a password protected directory in public_html, you can add a .conf file to the wwwconf directory and save my changes there. There is still one more command to use in order for all of this to work and that is the command to restart the httpd service. This can be done very easily using the following command.
service httpd restart
If you are running on an older system, this command may not be recognized. In those cases you should be able to use
/etc/init.d/httpd restart
Assuming you didn’t get any errors when you restarted the httpd service your web service should now be working. If you get an error, be sure to address it right away. Most common issues are invalid paths in the tags or missing directories that the tags are directed too.
Hopefully this tutorial was helpful to at least one user out there. This tutorial will be followed up next by a tutorial that will help you setup subdomains, create password protected directories and create mod rewrites.
Referred links ::
http://www.wains.be/index.php/2007/02/04/centos-chroot-dns-with-bind/
http://www.dingobytes.com/tutorial/web-site-on-centos-5-box
http://manageyourservers.blogspot.com/2010/09/setting-up-new-web-site-on-centos-5-box.html
No comments:
Post a Comment