Pages

Showing posts with label Linux Service Config. Show all posts
Showing posts with label Linux Service Config. Show all posts

Friday, 28 June 2013

Configure Sendmail as SMTP Mail Client

Configuration

Step # 1: Disable Sendmail Daemon In a Listing Mode

# vi /etc/sysconfig/sendmail

Modify the line:
DAEMON=no
 

Step #2: Configure Mail Submission

# vi /etc/mail/submit.cf 
 
D{MTAHost}<smtp.mailserver.com>


Sending Emails With Sendmail

SMTP Headers File  

<e.g /tmp/mail.txt>
From: "Me" <jxx_1@mail1.com>
To: "jxx_1@mail1.com" <jxx_1@mail1.com>
Subject: First Email
MIME-Version: 1.0
Content-Type: text/plain

Hello, World!
.

Send Email

cat /tmp/mail.txt | sendmail -i -t

-t tells sendmail that the message contains all the information it needs to send an email, i.e. the To: and From: fields, etc. Otherwise it's going to expect you to pass them as arguments on the command line.
-i tells sendmail that we're piping the message in from a file, so it should ignore the single-period requirement and expect an EOF instead. If you don't pass this argument when piping a file, then sendmail will expect a lone period at the end of your message file.
 
Source: 

Tuesday, 5 March 2013

How to setup a slave DNS Nameserver with Bind



When implementing redundancy as far as DNS is concerned, automated is always better. In a hosting environment, new zone files are constantly being created.
This need for a DNS master/slave implementation where new zone files are transferred between the master nameserver and the slave became apparent as operations grew and geographic DNS redundancy became apparent.
Obviously some commercial dns products provide this type of functionality out-of-the-box, but I will show you how to do this with a simple Bind DNS distribution.
I wrote this tutorial to help you, hopefully, to create an automated DNS slave / zone file transfer environment. Obviously you can create as many slave servers as you feel necessary.
MASTER Server
1. Edit /etc/named.conf and add the following to the options section where xx.xx.xx.xx is the ip of your slave server.:

allow-transfer { xx.xx.xx.xx; };

2. Create a script with the following, where somedirectory is the directory on your SLAVE server to store the slave zones and where yy.yy.yy.yy is your MASTER server ip and somewwwdir is a directory browsable via http and finally someslavefile.conf is the output file to write you slave config:

#!/bin/sh
#
for domain in `/bin/grep ^zone /etc/named.conf |/bin/grep "type master" |/bin/awk '{print $2}' |/bin/awk -F" '{print $2}'`

do

/usr/bin/printf "zone "${domain}" { type slave; file "/var/named/slaves/somedirectory/${domain}.db"; masters { yy.yy.yy.yy; }; };n"

done > /var/www/html/somewwwdir/someslavefile.conf

3. Test the script to ensure it is writing out the appropriate format.
4. Run the script as any user with permission to write to an http visible directory via cron.

0 4 * * * /path/to/script > /dev/null 2>&1

SLAVE SERVER
1. Transfer the rndc.key file from your master server to the slave :

scp MASTERSERVER:/etc/rndc.key /etc/ns1rndc.key

2. Edit ns1rndc.key and change the name of the key definition.
3. Edit named.conf and add the following to the options section:

allow-transfer { zz.zz.zz.zz; };

4. Append the following to the named.conf file:

include "/etc/ns1rndc.key";
include "/path/to/someslavefile.conf";

5. Run the following commands

touch /path/to/someslavefile.conf
mkdir /var/named/slaves/somedirectory/
chown -R named:named /var/named/slaves/somedirectory/
/etc/init.d/named restart

6. Create a script:

#!/bin/sh
/usr/bin/wget http://yy.yy.yy.yy/somewwwdir/someslavefile.conf  -O /var/named/slaves/someslavefile.conf
/etc/init.d/named restart

7. Add to root’s crontab

0 4 * * * /path/to/script

In the second slave script, you see that the transfer is done via wget. This can be replaced by many other more secure methods. If ssh based key authentication is employed, a simple scp or even rsync can be utilized to accomplish the actual zone transfer.

Thursday, 7 February 2013

daemontools svscan - list of programs in /service

svscan is a program in the daemontools package. The program starts instances of supervise and restarts them when they die. The scripts to start the applications are stored in /service.

[root@mail FAMS_MON_952]# pwd
/service/FAMS_MON_952
[root@mail FAMS_MON_952]# ls
run  supervise

[root@mail FAMS_MON_952]# cat run
#!/bin/sh
exec /var/fams_mon/fams_svr_monitor -c /var/fams_mon/fams_mon_952.conf

Instance is monitored by daemontool. The run will be called when the instance die
[root@mail FAMS_MON_952]# ps -ef | grep fams_svr_monitor
root     10189 32234  0 14:42 ?        00:00:00 /var/fams_mon/fams_svr_monitor -c /var/fams_mon/fams_mon_952.conf

[root@mail FAMS_MON_952]# kill -9 10189
The /service/FAMS_MON_952/run is called to restart the instance
[root@mail FAMS_MON_952]# ps -ef | grep fams_svr_monitor
root     12033 32234  0 14:44 ?        00:00:00 /var/fams_mon/fams_svr_monitor -c /var/fams_mon/fams_mon_952.conf

HOW TO STOP THE INSTANCE?
1> rename the /service/FAMS_MON_952/run to /service/FAMS_MON_952/run.bak
2> kill the instance

/etc/inittab

Put the line
     SV:12345:respawn:/command/svscanboot
at the end of /etc/inittab.

Wednesday, 23 January 2013

vncserver config

From: http://www.skullbox.net/vncserver.php

You will need several things to get started:
  • root privledges
  • VNC client software (tightVNC, you can download it here.)
  • A good password!
This example is done with RHEL, which comes standard with VNCserver installed. To start the vncserver simply invoke the following commands:
[root@roswell etc]# service vncserver start
Starting VNC server:                                       [  OK  ]
[root@roswell etc]# 
[root@roswell etc]# vncpasswd
Password: 
Verify: 
[root@roswell etc]#
[root@roswell etc]# vncserver

New 'roswell:1 (root)' desktop is roswell:1

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/roswell:1.log

[root@roswell etc]# 

Tuesday, 23 October 2012

DNS, BIND How to

Source http://www.howtoforge.com/traditional_dns_howto

BIND comes with three components. 
1> named or name-dee. It's a daemon that runs the server side of DNS.

2> resolver library. People think of a resolver as the client side of BIND. The resolver code makes queries of DNS servers in an attempt to translate a friendly name to an IP address. This component uses the resolv.conf file. 
 
3> BIND provides tools for testing you DNS server. We call them tools but they are really a set of command line utilities like dige.g dig yahoo.com

Named lives on a domain name server and answers queries from resolvers. The application reads its data from a configuration file called named.conf. named.conf gets its information from something we call zone files.

 

named.conf

options {
     pid-file "/var/run/bind/run/named.pid";
     directory "/etc/bind";
     // query-source address * port 53; };

//
// a master nameserver config
// The zone statement identifies the location of the hints, localhost, zone and reverse zone files. 
 
zone "." {
     type hint;
     file "db.root";
};

zone "0.0.127.in-addr.arpa" {
     type master;
     file "db.local";
}; 

zone "158.253.70.in-addr.arpa" {
     type master;
     file "pri.158.253.70.in-addr.arpa";
};

zone "centralsoft.org" {
     type master;
     file "pri.centralsoft.org";
};


  • Hints file

  • This file contains the names and addresses of the root servers on the Internet. These know where the authoritative servers for your domain exist - the first one being the Top Level Domain (com, net, org, etc.) and next being the authoritative server for your domain.

  • Local host file

  • Name servers are the masters of their own loopback domain (127.0.0.1). The point of creating local zone files for each aspect of your of localhost is to reduce traffic and allow the same software to work on your system as it does on the network.

  • Zone file

  • This file, also called the domain database, defines most of the information needed to resolve queries about the domain you administer. It maps names to IP addresses and provides information about the services offered by your Internet computer including your web and ftp server, email, telnet, name servers, etc.

    The zone file uses several record types including the SOA or start of authority; NS or name server; A or host name to address map;
    PTR or pointer which maps addresses to names; MX or mail exchanger which identifies the mail servers in the domain; and CNAME or canonical name which defines an alias for a host name.


  • Reverse zone file

  • Another way to talk about zone files is to define them something that links all the IP addresses in your domain to their corresponding server. The reverse zone file maps IP addresses to host files. It's a mirror image of the database file above. You can recognize a reverse zone file because it has the extension of in-addr.arpa.

Now we put all these records in our zone file pri.centralsoft.org. It looks like this:
@ IN SOA server1.centralsoft.org. root.localhost. (
                        2006012103; serial
                        28800; refresh, seconds
                        7200; retry, seconds
                        604800; expire, seconds
                        86400 ); minimum, seconds

;
                   NS server1.centralsoft.org.;
                   NS ns0.centralsoft.org. ;

;
                   MX 10 server1.centralsoft.org.

;

centralsoft.org.   A 70.253.158.42
www                A 70.253.158.42
server1            A 70.253.158.42
ns0                A 70.253.158.45
ftp                CNAME www
centralsoft.org.                  TXT "v=spf1 a mx ~all"
server1.centralsoft.org.          TXT "v=spf1 a -all"





SOA refers to "Start of Authority".  By the time you enter the picture, the system has handed off authority for part of the entire database to you. So, your zone file has to indicate where your authority starts. 

The data field of the SOA record contains several components or fields. They include:
  • Name
  • The root name of the zone. The "@" sign is a shorthand reference to the current origin (zone) in the /etc/named.conf file for that particular database file.
  • Class
  • A number of different DNS classes exist. For our purposes we will use the IN or Internet class used when defining IP address mapping information for BIND. The other classes exist for non Internet protocols and functions.
  • Type
  • The type of DNS resource record. In the example, this is an SOA resource record.
  • Name-server
  • Fully qualified name of your primary name server. Must be followed by a period.
  • Email-address
  • Notice that instead of an @ sign, the address uses a period and is followed by a period. In this case, root@localhost is represented as root.loalhost.
  • Serial-no
  • It is in a date format YYYYMMDD with an incremented double digit number tagged to the end. It's a numeric value that the slave server can use to check whether the zone file has been updated to perform a zone transfer.
  • Refresh
  • This field tells a slave DNS server how often it should check the master and perform a zone transfer. In this file we use 28800s as the value.
  • Retry
  • This field tells the slave how often it should try to connect to the master in the event of a connection failure. The interval in our example is 7200.
  • Expiry
  • Total amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directed towards the root servers. This is the expiration time, the length of time that the slave server should continue to respond to queries even if it cannot update the zone file. An expiration period exists under the theory that out of date data is worse than no data at all. In our example we use 604800
  • Minimum-TTL  
  • The TTL value defines the caching duration your DNS response. The value is included in your server's response. Because 86400 seconds is one day, the querying cache's record should die in one day.
Next we create NS records. These specify the name servers that are responsible for our domain. You must have at least one, however it is common practice to at least list two.

                   NS server1.centralsoft.org.; 
                   NS ns0.centralsoft.org. ;

 

MX Records

As we want to receive emails on centralsoft.org, we must list the mail exchanger(s) for the domain. This is done with an MX record:
                   MX 10 server1.centralsoft.org.
This record says that emails for centralsoft.org should be delivered to server1.centralsoft.org (which is the mailserver for the domain) with a priority of 10. You can list more than one mail exchanger:
                   MX 10 server1.centralsoft.org.
                   MX 20 mail.someotherdomain.com.
 
Let's say, we have an email address of the form user@subdomain.centralsoft.org. 
Therefore we must create an MX record for subdomain.centralsoft.org:
subdomain.centralsoft.org.        MX 10 server1.centralsoft.org.
 

A Records


centralsoft.org.   A 70.253.158.42

This means that centralsoft.org has the IP address 70.253.158.42.

CNAME Records

CNAME is short for "canonical name", you can think of it as an alias to an A record. For example,
ftp                CNAME www
means, ftp.centralsoft.org is an alias for www.centralsoft.org, so ftp.centralsoft.org points to the same machine as www.centralsoft.org.
A CNAME must always point to an A record; a CNAME must not point to another CNAME! In addition to that, you must not use CNAME records for MX and SOA records. For example,
                   MX 10 ftp   ;not allowed!
is not allowed!

TXT Records

TXT records give you the ability to assign some text/additional information to a zone. Normally this feature is not much in use - with one exception: SPF (Sender Policy Framework) records. These are records that specify from which machines you are allowed to send mail with the sender domain centralsoft.org.
There is a wizard for creating SPF records at http://www.openspf.org/wizard.html?mydomain=&x=26&y=8. We use this wizard to create an SPF record for centralsoft.org, and add this to our zone file:
centralsoft.org.                  TXT "v=spf1 a mx ~all"
server1.centralsoft.org.          TXT "v=spf1 a -all" 

The Reverse Zone File

We need a reverse zone which maps IP addresses to centralsoft.org. This reverse lookup is used by many programs that will refuse to talk to you if the reverse lookup and the forward lookup (i.e. the normal lookup of centralsoft.org) do not match each other.

Therefore we have this in our named.conf file:
zone "158.253.70.in-addr.arpa" {
     type master;
     file "pri.158.253.70.in-addr.arpa";
};





@ IN SOA server1.centralsoft.org. root.localhost. (
                        2006012103; serial
                        28800; refresh, seconds
                        7200; retry, seconds
                        604800; expire, seconds
                        86400 ); minimum, seconds

;
                   NS server1.centralsoft.org.;
                   NS ns0.centralsoft.org. ;

42                 PTR    centralsoft.org.
45                 PTR    ns0.centralsoft.org.

PTR Records

PTR is short for pointer, and that's what it is: it points to a domain name.
centralsoft.org's IP address is 70.253.158.42, and we want 70.253.158.42 to point to centralsoft.org.
The other IP address we use is 70.253.158.45 (for ns0.centralsoft.org)

Secondary Name server

Secondary name server ns0.centralsoft.org

ns0.centralsoft.org's named.conf resembles that of the primary name server very much, with a few differences:
options {
     pid-file "/var/run/bind/run/named.pid";
     directory "/etc/bind";
     // query-source address * port 53;
};


zone "." {
     type hint;
     file "db.root";
};

zone "0.0.127.in-addr.arpa" {
     type master;
     file "db.local";
};

zone "centralsoft.org" {
     type slave;
     file "sec.centralsoft.org";
     masters { 70.253.158.42; };
};


The secondary has contacted the primary name server, and the primary name server has transferred the zone to the secondary.
Now whenever you update the zone on the primary name server, make sure you increase the serial number, otherwise the updated zone will not be transferred to the secondary!
Please make sure you have no firewall on the primary and the secondary name server that blocks port 53 (TCP and UDP) because otherwise zone transfers will fail!

A Word On Security

In our current configuration every name server is allowed to transfer our centralsoft.org zone from our primary name server. Since we want only our secondary name server (70.253.158.45) to be allowed to transfer the zone, we add the following line to the centralsoft.org zone in named.conf on our primary name server server1.centralsoft.org:

So the zone should look like this:
zone "centralsoft.org" {
     type master;
     file "pri.centralsoft.org";
     allow-transfer { 70.253.158.45; };
};