Vtrio SysAdmins

In cpanel exim mail logs are stored in following files

/var/log/exim_mainlog -: All the logs are recorded into the exim_mainlog file
/var/log/exim_rejectlog -: Rejected emails logs are recorded into the exim_rejectlog
/var/log/exim_paniclog -: If the exim server stuck or fails then those logs will be recorded into the exim_paniclog file.

Log line flags:
—————

<= Shows arrival of a message for incoming mail.
=> Shows a normal message delivery for outgoing mail
-> Shows additional address for the same delivery, i.e. an Email forwarder.
*> Shows delivery suppressed by -N**delivery failed; address bounced.
== Shows delivery deferred; temporary problem.
** Shows delivery failed; address bounced.
From the email queue, we can find the log details of an email by using the command “exim -Mvl Message-ID”

A summary of the field identifiers that are used in log lines:

R=  The address immediately following “<=” is the sender address. A bounce message is shown with the sender address “<>”, and if it is locally     generated, this is followed by an item of the form R=<message id>.

T= The relay used to transmit the message. Example: T=remote_smtp T=local_delivery

H= Represents the host name and IP address.

U= The MTA used.

I= local interface used.

P= This is the return path on delivery.

A= If A= is present, then SMTP AUTH was used for the delivery.

S= Is the delivery size of the message.

ID= Represents the incoming message ID

T= Topic / Subject

from :From whom the mail was received

for : Who the email is for.

C : SMTP confirmation on delivery.

D : Duration of “no mail in SMTP session”.

S : size of message.

X :TLS cipher suite

DT:on => lines: time taken for a delivery

Email of users are stored in “/home/user/mail/<domain>/<emailuser>”
/home/username/mail(mail folder)
/home/username/etc (configuration files)
/domain.com
maildirsize (quota/usage summary, expendable)
cur (default inbox for read email)
new (default email for unread email)

In order to send the mails the website and email for a domain need not be in same server. DNS is used to point the services to the correct place. Exim, cPanel SMTP service needs a little help beyond DNS in order to know how to handle mail that is generated locally. This is where /etc/localdomains and /etc/remotedomains are usefull.

/etc/localdomains :

If the MX record of the domain is pointed to same server then there must be entry for that domain under /etc/localdomains file for local delivery of email.

/etc/remotedomains :

If you are using remote mail server then entry for that domain must be removed from /etc/localdomains files and should added in /etc/remotedomains files for proper routing of emails.

Setting this option during account creation
——————————————-

Local Mail Exchanger:-cPanel will place the domain in localdomains.

Remote Mail Exchanger :- It will place the domain in remotedomains.

Backup Mail Exchanger:- The domain will be added to localdomains but will only accept mail if there are no other mail servers available.

Automatically Detect Configuration:- It will check the DNS Mail Exchanger records to see where the DNS is pointed, and make the configuration based off of that.

Changing the exchanger after account creation in WHM
—————————————————–

In WHM, navigate to “Edit MX Entry” under “DNS Functions” in the left menu list.

From there, simply select the domain name you wish to edit, and then select the desired mail exchanger (Local Mail Exchanger, Backup Mail Exchanger, or Remote Mail Exchanger) to change the mail routing settings for the domain:

Changing the exchanger after account creation via SSH
———————————————————-

Modifying a domain to use a different exchanger is as simple as SSHing into the server and editing the files; simply remove the domain from one file and add it to the other. It is that simple. No need to restart services afterward.

How to change sites MX record to point mail to another domain or server.
————————————————————————-

An MX Record is used by a mail server to route incoming email. Changing your MX record is usually done to redirect email to a remote server.

To point the MX to another domain do the following.

1. Log into your WHM.
2. Click the Edit DNS Zone.
3. Select the domain name from the drop-down list.
4. Change the MX from domain.com to mail.domain.com.
5. Click the save button.

If you want to point it to another server using the same domain:

1. Log into your WHM.
2. Click the Edit DNS Zone.
3. Pick the domain you wish to edit.
4. Change the MX from domain.com to mail.domain.com.
5. mail.domain.com should have the A entry of the external mail server IP address.
6. Click the save button.

Note: You need to change the domain from /etc/localdomains to /etc/remotedomains for sending mails when your mail service is hosted on another server.

Just putting together, what we have done in sharding so that we dont forget it later. I shall update this doc as and when we have more details.

Sharding means, distributing data across multiple servers.Basically, mongodb sharding requires three things

1) a config server which stores the metadata which knows where the data resides

2) a query router server is the server to which the application actually communicates. It contacts the config servers to find in which shard the data resides and retrieves the data to the application.

3) shard servers – this consists of a subset of the entire data, distributed across multiple servers

In our case, for test purpose, we used the minimal number of servers. Mongod eats up ram hence, it will be good to use servers with somewhat good specifications. We used

1) 1 config servers

2) 1 query router server. We combined config server and query router server into one, hence these two required only 1 server.

3) In order to see how sharding actually works, we needed 2 shard servers. So a total of 3 servers

Install mongo in all servers as mentioned in http://greproot.com/install-mongodb-centos/

Setting up config server

————————–

Hostname of server chosen as config.mongotest.com

mkdir /mongo-metadata     – create a folder for the mongo metadata

Now start mongo config server as follows. Make sure to use the port as 27019. Whatever number of config servers you use, you need to make sure the path and port are same for all.

mongod –configsvr –fork –logpath=/var/log/mongo/mongod.log  –dbpath /mongo-metadata –port 27019

Setting up query router

—————————-

Please note I chose config and query router servers to be same. If you have an alternate server, use it as queryrouter server. Query router use the mongos service. Mongos runs on port 27017.

mkdir /queryrouter_log

Start mongos as follows.

mongos –fork –logpath /queryrouter_log/query.log –configdb config.mongotest.com:27019

Shard Servers

—————–

Hostnames chosen are shard1.mongotest.com and shard2.mongotest.com. Just start mongodb in both servers and it will run on port 27017

We dont have to setup shard servers separately.  Just login to any one shard server and you can setup all shards from there itself.

Login to any shard server as root. Connect to the query router server from there as follows.

mongo –host config.mongotest.com –port 27017

above command connects to the mongo shell of queryrouter server, at port 27017 which runs mongos

mongo –host config.mongotest.com –port 27017

MongoDB shell version: 2.4.9
connecting to: config.mongotest.com:27017/test

Add the two shard servers first
mongos> sh.addShard( “shard1.mongotest.com:27017″ )
mongos> sh.addShard( “shard2.mongotest.com:27017″ )

Create a new database

mongos> use divya_test
switched to db divya_test
Enable Sharding for that db

mongos> sh.enableSharding(“divya_test”)
{ “ok” : 1 }

Create a new collection test with an index _id

mongos> db.test.ensureIndex( { _id : “hashed” } )

Now shard this collection using a hashed shard key(i am not very sure of how shard keys has to be selected)

sh.shardCollection(“divya_test.test”, { “_id”: “hashed” } )

You can see the status of the shards by issuing the following command

mongos>sh.status()

Now, try adding some data to the collection and check both shard servers. You will see the data is spread across those servers.

mongos> db.test.save({_id:1})
mongos> db.test.save({_id:2})
mongos> db.test.save({_id:3})
mongos> db.test.find()
{ “_id” : 1 }
{ “_id” : 2 }
{ “_id” : 3 }

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!