Archive for June 27, 2013

create user and grant permission – mysql

How to Create a New User

In Part 1 of the MySQL Tutorial, we did all of the editing in MySQL as the root user, with full access to all of the databases. However, in the cases where more restrictions may be required, there are ways to create users with custom permissions.

Let’s start by making a new user within the MySQL shell:

CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';

Sadly, at this point newuser has no permissions to do anything with the databases. In fact, if newuser even tries to login (with the password, password), they will not be able to reach the MySQL shell.

Therefore, the first thing to do is to provide the user with access to the information they will need.

GRANT ALL PRIVILEGES ON * . * TO 'newuser'@'localhost';

The asterisks in this command refer to the database and table (respectively) that they can access—this specific command allows to the user to read, edit, execute and perform all tasks across all the databases and tables.

Once you have finalized the permissions that you want to set up for your new users, always be sure to reload all the privileges.


Your changes will now be in effect.

How To Grant Different User Permissions

Here is a short list of other common possible permissions that users can enjoy.

    • ALL PRIVILEGES- as we saw previously, this would allow a MySQL user all access to a designated database (or if no database is selected, across the system)


    • CREATE- allows them to create new tables or databases


    • DROP- allows them to them to delete tables or databases


    • DELETE- allows them to delete rows from tables


    • INSERT- allows them to insert rows into tables


    • SELECT- allows them to use the Select command to read through databases


    • UPDATE- allow them to update table rows


  • GRANT OPTION- allows them to grant or remove other users’ privileges

To provide a specific user with a permission, you can use this framework:

 GRANT [type of permission] ON [database name].[table name] TO ‘[username]’@'localhost’;

If you want to give them access to any database or to any table, make sure to put an asterisk (*) in the place of the database name or table name.

Each time you update or change a permission be sure to use the Flush Privileges command.

If you need to revoke a permission, the structure is almost identical to granting it:

 REVOKE [type of permission] ON [database name].[table name] TO ‘[username]’@‘localhost’;

Just as you can delete databases with DROP, you can use DROP to delete a user altogether:

 DROP USER ‘demo’@‘localhost’;

To test out your new user, log out by typing


and log back in with this command in terminal:

mysql -u [username]-p



Install Mysql 5.5 in centos 6.3

As MySQL 5.1 is standard in CentOS/RHEL 6.x, it is not included in the Webtatic EL 6 repository. 

Install Atomic Yum Repository On CentOS Linux:
[root@test]# wget -q -O - |sh

then install

yum install mysql55 mysql55-server

Shared Address Book (LDAP)

Copied from:

Chapter 20 – Shared Address Book (LDAP)

Version: - openldap-servers 2.3.19
- phpLDAPadmin 1.0.1

Initial Concepts
Basic Configuration
Address Book Entries
TLS Link Encryption
phpLDAPadmin Web Administrator
Email Client Settings

Many individuals throughout professional organisations will consider their list of personal and professional contacts as one of their most important assets. Similarly at home keeping our contact details of friends, relatives and professional service providers like physicians is also equally important, however maintaining that contact list across several computers can be very time consuming; even frustrating if it is lost.

Using the Lightweight Directory Access Protocol (LDAP) we can configure a centrally managed address book that can be shared by all the of computer workstations throughout the network (for many large organisations this is a fundamental design concept). A central (or shared) address book allows easy management of all contact details, it can be backed up and restored very easily, and it can also be made available through a secure web interface so it can be accessed remotely from where ever the user may be.

This chapter will detail the procedures necessary to configure the OpenLDAP ( directory service that will provide the basis for our address book and make it available to our network users. We will also look at populating the address book and provide security access controls so that only authenticated users can access the information.

Not all email clients are able to write to the address book (although reading is fine), this is normally due to the functionality of the email client and not a problem with the directory service. Therefore, we will also configure the web server with a web based administration application which will allow full control of the address book; this also allows the remote access if needed.

The following list of man pages can provide further information to assist with configuration or debugging requirements.

Man Pages:
ldap slapd slapcat
ldap.conf slapd.conf slapadd
ldapadd slapd.access slappasswd
ldapsearch slaptest ldif


Initial Concepts

The shared address book is being configured using the LDAP directory services which basically stores different types of information and objects in a database and these entries are accessible using its own directory architecture (X.500 standard).

The naming conventions used to traverse this system can be extremely complex for new users to grasp, so the following table has been provided as an example of what these objects are and the names we are going to use in referencing them.

Description String Value (DN)
Base Domain
Admin User
Authorised users located here ou=users,dc=example,dc=com
Authorised user account (example)
Address book entries located here
Also used by client as "Search Base"
Address book entry (example)
cn=Tom Thumb,ou=addressbook,dc=example,dc=com

The following table explains some of the basic acronyms used throughout the directory, there are many more than this that go to make up the naming conventions, however these are the only ones we will be concerned with.

String Attribute Type
dn Distinguished Name
cn Common Name
o Organisational Name
ou Organisational Unit Name
dc Domain Component
uid User Identification


Caution !! Do not confuse the X.500 naming scheme used in LDAP with the email addresses of your contacts, they are totally separate details. This will become clear further on.

Everything inside the directory has a distinguished name (dn) this is what makes each entry unique from the others and also provides a means to easily reference the object. Viewing the top table, the DN for the manager account is “cn=Manager,dc=example,dc=com", while all of the address book entries are contained in the DN of "ou=addressbook,dc=example,dc=com".

The following table displays valid examples of how domains are expressed using the X.500 naming scheme.

Example Domain Names String Value
dc=home,dc=lan dc=example,dc=com dc=example,dc=org dc=domain,dc=org,dc=au dc=sub,dc=domain,dc=org,dc=au dc=more,dc=sub,dc=domain,dc=org,dc=au


Note !! If the LDAP server is simply being configured as a shared address book and not for any real networking requirement, then it is acceptable to use a simple domain similar to “home.lan”


Basic Configuration

The OpenLDAP package contains a server and client application. The client application will be used to query the server and insert/update information during the configuration, so it is necessary to configure this as well as the server.

The configuration that we need is very simple, however good house keeping means making backups before adjusting the configuration file.

[bash]# cp /etc/openldap/ldap.conf /etc/openldap/ldap.conf.original
[bash]# vi /etc/openldap/ldap.conf

The following entry is really all that is needed for the client. It identifies where the server is located, and which part of the directory tree to query.

URI ldap://
BASE dc=example,dc=com

The server can be configured with a built-in administrator account that has global root privileges, it is necessary to store the password for the root account inside the server configuration file. The “slappasswd” application allows passwords to be encrypted (or hashed) which stops unauthorised users from viewing the password, or intercepting a plaintext password while it is being transmitted over the network.

Create a suitable password for the root account so it can be placed into the configuration file.

[bash]# slappasswd

The LDAP server is called slapd (Stand-Alone LDAP Daemon), lets backup the configuration file before making adjustments.

[bash]# cp /etc/openldap/slapd.conf /etc/openldap/slapd.conf.original
[bash]# vi /etc/openldap/slapd.conf

The following slapd.conf file contains the basic configurations required to establish a shared address book on a secure network, however there are no access controls yet defined; security is covered later on. The encrypted root password should be substituted where necessary.

The five lines that are commented below are not needed to configure our simple address book. However they be needed if you wish to advance your LDAP requirements so they have been left as comments only; they may be removed if need be.

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
#include         /etc/openldap/schema/nis.schema

pidfile         /var/run/openldap/
argsfile        /var/run/openldap/slapd.args


database        bdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          {SSHA}RZmBkCh3WwEMNhdANh/l3OynzHSifPzF               <-- insert generated root password here

directory       /var/lib/ldap

index objectClass                       eq,pres
#index ou,cn,mail,surname,givenname      eq,pres,sub
#index uidNumber,gidNumber,loginShell    eq,pres
#index uid,memberUid                     eq,pres,sub
#index nisMapName,nisMapEntry            eq,pres,sub

# DB_CONFIG Settings – For SleepyCat Berkeley DB
dbconfig set_cachesize 0 10485760 0
dbconfig set_lg_regionmax 262144
dbconfig set_lg_bsize 2097152

Note !! It is possible to run multiple databases using the one OpenLDAP server, however we are only concerned with one for the time being. Consult the documentation for further details if needed.

After the configuration has been adjusted it can be checked before it is implemented. Any errors should be fixed before restarting the server.

[bash]# /etc/init.d/ldap configtest

The LDAP service should now be set at the appropriate runlevels and checked to ensure they are set correctly.

[bash]# chkconfig –level 345 ldap on
[bash]# chkconfig –list ldap

The service can now be started with the following command.

[bash]# /etc/init.d/ldap restart


Address Book Entries

Information can be imported and exported into an LDAP directory service using the LDAP Data Interchange Format (LDIF) as defined in RFC2849. An LDIF file specifies the contents of a directory entry in a human readable text format, this allows quick manipulation of a file to re-import similar entries into the directory.

Now that the LDAP server has been configured and is running, we can conduct a simple search of the naming context to see our directory information before we start to import our entries. The “namingContexts” should be similar to the example below.

[bash]# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
# LDAPv3
# base <> with scope base
# filter: (objectclass=*)
# requesting: namingContexts

namingContexts: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

The following LDIF file will create the hierarchical directory service structure that we will be using for our address book. The first entry is that of the base directory and the second entry is for the Manager’s (administrator) account. The last two entries are the two organisational units that we will use to store the authorised users (for adding security later) and the address book entries.

The bolded entries should be changed to suit your configuration requirements.

[bash]# vi /etc/openldap/addressbook.ldif
dn: dc=example,dc=com
objectclass: dcObject
objectclass: organization
o: Home LDAP Server
dc: example

dn: cn=Manager,dc=example,dc=com
objectclass: organizationalRole
cn: Manager

dn: ou=users,dc=example,dc=com
ou: users
objectClass: top
objectClass: organizationalUnit

dn: ou=addressbook,dc=example,dc=com
ou: addressbook
objectClass: top
objectClass: organizationalUnit

Using the “ldapadd” command we can enter the LDIF contents into the server, creating our initial directory scheme.

[bash]# ldapadd -x -D 'cn=Manager,dc=example,dc=com' -W -f /etc/openldap/addressbook.ldif
Enter LDAP Password:
adding new entry “dc=example,dc=com”
adding new entry “cn=Manager,dc=example,dc=com”
adding new entry “ou=users,dc=example,dc=com”
adding new entry “ou=addressbook,dc=example,dc=com”

The following LDAP search is requesting a listing of all entries starting from the base “dc=example,dc=com”. This should return all of the entries that where added in the previous step.

[bash]# ldapsearch -x -b 'dc=example,dc=com' '(objectclass=*)'
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Home LDAP Network
dc: example

# Manager,
dn: cn=Manager,dc=example,dc=com
objectClass: organizationalRole
cn: Manager

# users,
dn: ou=users,dc=example,dc=com
ou: users
objectClass: top
objectClass: organizationalUnit

# addressbook,
dn: ou=addressbook,dc=example,dc=com
ou: addressbook
objectClass: top
objectClass: organizationalUnit

Now that we have defined and imported our directory scheme, we are able to create user entries to populate the addressbook. The following is a simple example LDIF entry for a contact.

The first line (dn:) designates where about in the directory the entry will belong when its imported, this should be changed to suit your needs.

[bash]# vi newcontact.ldif
dn:cn=Tom Thumb,ou=addressbook,dc=example,dc=com
cn: Tom Thumb
gn: Tom
sn: Thumb
o: Home
l: Brisbane
street: 12 Banana Ave
st: QLD
postalCode: 4100
pager: 5555 1111
homePhone: 5555 1234
telephoneNumber: 5555 1235
facsimileTelephoneNumber: 5555 1236
mobile: 0400 123 123
objectClass: top
objectClass: inetOrgPerson

The contents of the LDIF file can be added into the directory service using the “ldapadd” command below.

The standard access controls for the server defines that everyone can read the directory entries, but only the manager (administrator) can write to the directories. To add the LDIF file the manager is authenicating on the command line with the “-D 'cn=Manager,dc=example,dc=com' -W" string.

[bash]# ldapadd -x -D 'cn=Manager,dc=example,dc=com' -W -f newcontact.ldif
Enter LDAP Password:
adding new entry “cn=Tom Thumb,ou=addressbook,dc=example,dc=com”

Now that the first entry has been successfully added to the directory server, the file can be copied so more entries can be added. Alternatively, extra entries can be added to the same file ensuring that a blank line is used to separate each different entry.

TLS Link Encryption

The standard security settings for the LDAP server allows everyone to connect (bind) to the server and read the entire directory contents, while only the administrative account can make changes or add new entries. For your small home network you may find this entirely suitable in its current format, however the following details will provide some extra security configurations to make it less accessible, this is also important if you wish to access your home server from beyond your home network.

The access controls are defined within the servers main configuration file.

[bash]# vi /etc/openldap/slapd.conf

The following details are typical of the security settings that you may consider implementing. The first section details any link encryption using TLS/SSL and it also enforces which actions can be done on the server depending on the level of link security that has been implemented.

The second section details the access controls based on the users authentication and basic anonymous access. The default access controls (below) have been defined to deny everyone access, however people are allowed to bind to the server to authenticate. All authenticated users are allowed to change their own details, and all of the entries in the “ou=addressbook,dc=example,dc=com” directory; anonymous access it disallowed.

TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
TLSCertificateFile /etc/pki/tls/certs/slapd.pem
TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
security ssf=1 update_ssf=112 simple_bind=64

disallow bind_anon
access to *
by self write
by anonymous auth
by users read
access to dn.subtree=”ou=addressbook,dc=example,dc=com”
by users write


Note !! The term “users” defines those people that have successfully authenticated with the server.

You will need to create an SSL certificate for use with your server, the following code will create a self-signed certificate which is good enough for our requirements.

[bash]# cd /etc/pki/tls/certs
[bash]# make slapd.pem
Country Name (2 letter code) [GB]:AU
State or Province Name (full name) [Berkshire]:QLD
Locality Name (eg, city) [Newbury]:Brisbane
Organization Name (eg, company) [My Company Ltd]:Miles Brennan
Organizational Unit Name (eg, section) []:Home Linux Server
Common Name (eg, your name or your server’s hostname) []
Email Address []

The ownership and permissions for the self-signed certificate need to be adjusted slighty so the basic “LDAP” user account can read the certificate details.

[bash]# chown root.ldap /etc/pki/tls/certs/slapd.pem
[bash]# chmod 640 /etc/pki/tls/certs/slapd.pem

Now that the server has been configured for TLS/SSL, the LDAP client also needs to be configured for TLS/SSL otherwise they will not be able to communicate.

[bash]# vi /etc/openldap/ldap.conf
URI ldaps://
BASE dc=example,dc=com
TLS_REQCERT demand                         <-- see warning below, may need to be "allow"
TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt


Warning !! Refer to “man ldap.conf” and “man slapd.conf” for the exact meanings of the TLS options. Incorrect settings when working with a “self signed” PEM certificate may prevent your LDAP client from successfully connecting to your SLAPD server.

An access control list may be prone to user syntax errors and will not be accepted by the LDAP server, so the configuration should be tested before it is loaded.

[bash]# /etc/init.d/ldap configtest

If the configuration passes integrity testing, the server can be restarted.

[bash]# /etc/init.d/ldap restart

The new security access controls now prevent unauthorised access to the directory service, so simple user objects must be prepared that will allow people to authenticate with the server.

The user objects will be imported into the LDAP server using an LDIF file. Remember that everything in an LDIF file is human readable so plain text passwords are a VERY BAD idea, especially if you are following this guide for an organisation; no plain text passwords please.

The slappasswd application can be used to create a hashed value of a users password, these are saved to store in a text file. This does not mean they are completely safe, it just means they can not be easily read. An attacker can still subject the password value to a brute force attack, but it would take them an awfully long time. Physical security is still important.

[bash]# slappasswd

The default algorithm for the hashed password is SSHA, this can be changed at the command line to other formats; the default type (SSHA) is recommended.

[bash]# slappasswd -h {MD5}

The basic user object can now be created and imported into the LDAP server. This file uses the “UID” (User ID) string to distinguish the object and the contents are all that we need to create a basic authentication mechanism.

It should also be noted that this object is stored in the “users” organisational unit, which is located outside of the address book directory.

[bash]# vi useraccount.ldif
uid: alice
userPassword: {MD5}poocSzW4TMBN3fOtmVOQHg==
objectClass: top
objectClass: account
objectClass: simpleSecurityObject

The user account can now be entered into the LDAP server.

[bash]# ldapadd -x -D 'cn=Manager,dc=example,dc=com' -W -f useraccount.ldif
Enter LDAP Password:
adding new entry “uid=alice,ou=users,dc=example,dc=com”


Hint !! For Alice to authenticate to the server, she needs to pass “uid=alice,ou=users,dc=example,dc=com” as her username along with the the plain text value of her password, the hashed value is only for storage purposes.


Backing Up The Database

The OpenLDAP server allows for easy importing and exporting of directory entries using the LDIF format, this makes it extremely easy to extract the complete contents of the database for backup purposes.

The service should be stopped before extracting or importing the directory service listing.

[bash]# /etc/init.d/ldap stop


Caution !! The LDAP server should be stopped before executing the “slapcat” or “slapadd” commands. This prevents the possibility of data corruption and ensures database integrity is maintained.

The following “slapcat” command will extract the entire database contents into the “backup_slapd.ldif” file. This file should be stored in a save place, particularly if password information is contained in the file.

[bash]# slapcat -vl /etc/openldap/backup_slapd.ldif

The contents of the stored “backup_slapd.ldif” file can be imported back into the LDAP server using the following command. This is a quick and easy method to rebuild your entire address book after a system rebuild.

[bash]# slapadd -vl /etc/openldap/backup_slapd.ldif

If an LDIF restore is being done on a new LDAP server, there is a possibility that the database directory has not been configured correctly for the ldap user account. If this is the case then the server may not start correctly because the file permissions are incorrect.

To restore the file permissions on a newly restored LDAP database, use the following command to grant user and group ownership to the “ldap” user account. This may be different for each Linux distribution, please refer to your configuration details first.

[bash]# chown ldap.ldap /var/lib/ldap/*

The service can now be started to access the directory services.

[bash]# /etc/init.d/ldap restart


phpLDAPadmin Web Administrator

There are many different email clients available today that are capable of using an LDAP server as a central address book, however even less of these clients are able to write new contacts details to the server or even make changes to an existing entry (this is not a server problem). One of the easiest mays to interface and administer the shared address book is by using a web based application installed on the web server; this provides easy management and remote access to the address book.

phpLDAPadmin ( is a PHP based web application designed specifically to allow remote management of an LDAP server by using a simple web browser. Although this package is covered under the open source license there is a small fee for “commercial” users, but its still totally free for home use.

The package firstly needs to be downloaded from the phpLDAPadmin site and saved somewhere on the server; the package is available for download as a ‘tarball’ (a .tar.gz file). Use the following commands to extract the archive into the “/var/www” directory, remember to replace ?.?.? with the version number you have downloaded.

[bash]# tar -xzvf phpldapadmin-?.?.?.tar.gz -C /var/www/
[bash]# chown -R root.root /var/www/phpldapadmin-?.?.?/

The application has now been extracted and needs to be configured with the details of the local LDAP server. Normally there is only an example configuration file available in the package, this should be copied over as the main configuration file, then adjusted to suit your needs.

When when configured the Apache web server a few chapters ago, we created an SSL certificate and used the rewrite module to force SSL connections. It is recommended that SSL also be forced on the phpLDAPamin application so that any logon details and database queries are executed confidentially.

[bash]# cp /var/www/phpldapadmin-?.?.?/config/config.php.example /var/www/phpldapadmin-?.?.?/config/config.php

The following details in the configuration file are the basic requirements needed for simple LDAP access and administration by the web application. There are further details which can be configured, but not needed for simple address book management; you may configure these further options if you would like to use them though.

[bash]# vi /var/www/phpldapadmin-?.?.?/config.php

//$config->custom->debug['level'] = 255;
//$config->custom->debug['file'] = ‘/tmp/pla_debug.log’;

/* Define your LDAP servers in this section  */

$ldapservers = new LDAPServers;
$ldapservers->SetValue($i,’server’,’name’,’My LDAP Server’);
$ldapservers->SetValue($i,’login’,’pass’,’password’);                   <– set your Manager password here
$ldapservers->SetValue($i,’server’,’tls’,true);                         <– set to false if not using SSL certs


The archive for the phpLDAPadmin application was originally extracted into the “/var/www/phpldapadmin”, while the Apache web server has its “DocumentRoot” directive set to”/var/www/html” which means the phpLDAPadmin application is located outside of the “DocumentRoot” and the contents are not yet accessible to the web server.

We can create a configuration file for the phpLDAPadmin application so Apache can access the resources that are required. The configuration below is using the AuthType directive from Apache, ensuring that the access is restricted to only those users that have a valid username and password.

[bash]# vi /etc/httpd/conf.d/phpLDAPadmin.conf
Alias /ldap “/var/www/phpldapadmin-?.?.?”

<Location “/ldap”>
AuthType Basic
AuthName “Private Area – LDAP Administrator”
AuthUserFile /etc/httpd/conf/authusers
AuthGroupFile /etc/httpd/conf/authgroups
Require group ldapusers
Require valid-user

If SSL certificates where created for the Apache web server, then it should be configured to force the phpLDAPadmin application into SSL mode to keep it secure. This configuration uses the rewrite module configuration we created in Chapter 13.

[bash]# vi /etc/httpd/conf.d/mod-rewrite.conf
RewriteRule ^/ldap/(.*) https://%{SERVER_NAME}/ldap/$1 [R,L]

The Apache web server needs to be restarted before the settings will be implemented.

[bash]# /etc/init.d/httpd restart

If everything has gone well you should now be able to access the phpLDAPadmin application on the local server at: https://localhost/ldap.

Email Client Settings

The last steps in setting up the shared address book is to configure the users email clients to access the LDAP server.

The following table contains some of the information needed to configure the client applications. Note the username will need to be written as the complete “distinguished name” value so the server knows which object to authenticate.

Remember, not all clients can write to the address book, so use the phpLDAPadmin application to add and manage the entries as needed.

LDAP Server:
Search Base: ou=addressbook,dc=example,dc=com
Login Method: use distinguished name (if listed)
Username: uid=alice,ou=users,dc=example,dc=com
Password: As entered in useraccount.ldif file (plain text version)
Secure Connection: Never (unless encryption has been configured)

If you configured SquirrelMail on your server during Chapter 13, you will be pleased to hear that SquirrelMail is able to be configured to use an LDAP address book.

You can use the following commands to configure SquirrelMail to use your new LDAP address book.

[bash]# cd /usr/share/squirrelmail/config
[bash]# ./

The following list of client configurations should be used as a guide only, they may differ between versions and operating systems.

If you are aware of extra client settings that are not listed below, please send me the connection details to have them added.


Linux Clients

- Evolution (Ver 2.0):
(can read and write)
1.   Press “CTRL+SHIFT+B”, this opens “Add Address Book”
2.   Select “Type: On LDAP Servers”
3.   Enter configuration details then save and close

- Thunderbird (Ver 1.5x):
(read only)
1.   Press “CTRL+2″, this opens “Add Address Book”
2.   Select “Edit” –> “Preferences” –> “Composition” –> “Addressing”
3.   Select “Directory Server” check box, then click “Edit Directories”
4.   Enter configuration details then save and close

Microsoft Clients

- Microsoft Outlook 2003:
(read only)
1.   Select “Tools” –> “E-mail Accounts” –> “Add a new directory or address book” –> “Internet Directory Service (LDAP)”
2.   Enter configuration details then select “More Settings..”
3.   Enter the search base then save and close

- Microsoft Outlook Express (Version 6.0):
(read only)
1.   Select “Tools” –> “Accounts” –> “Add” –> “Directory Service”
2.   Enter simple configuration details from wizard
3.   Highlight the new address book, select “Properties”
4.   Enter login and search base details, save and close

- Mozilla Thunderbird (Ver 1.0):
(read only)
1.    Select “Tools” –> “Options” –> “Composition”
2.   Under “Address Autocompletion”, tick “Directory Server”, then select “Edit Directories”
3.   Select “Add”, enter configuration details then save and close

excitement – WWDC 2013 is around the corner

The big discussion surrounding iOS 7 has been regarding a new driven by Jony Ive, who took over control of Apple’s software-focused Human Interface team late last year in addition to his longtime role as head of Industrial Design.

rumors says

iOS7 , iRadio ,  MAC OS X 10.9 and macbookpro updates


Commom Exim Settings – from exim -book


This chapter discusses some configuration settings that seem to be fairly common. More examples and discussion can be found in the Exim book.

1. Sending mail to a smart host

If you want to send all mail for non-local domains to a “smart host”, you should replace the default dnslookup router with a router which does the routing explicitly:

  driver = manualroute
  route_list = !+local_domains
  transport = remote_smtp

You can use the smart host’s IP address instead of the name if you wish. If you are using Exim only to submit messages to a smart host, and not for receiving incoming messages, you can arrange for it to do the submission synchronously by setting the mua_wrapper option (see chapter 50).

2. Using Exim to handle mailing lists

Exim can be used to run simple mailing lists, but for large and/or complicated requirements, the use of additional specialized mailing list software such as Majordomo or Mailman is recommended. The redirect router can be used to handle mailing lists where each list is maintained in a separate file, which can therefore be managed by an independent manager. The domains router option can be used to run these lists in a separate domain from normal mail. For example:

  driver = redirect
  domains = lists.example
  file = /usr/lists/$local_part
  errors_to = $local_part-request@lists.example

This router is skipped for domains other than lists.example. For addresses in that domain, it looks for a file that matches the local part. If there is no such file, the router declines, but because no_more is set, no subsequent routers are tried, and so the whole delivery fails. The forbid_pipe and forbid_file options prevent a local part from being expanded into a file name or a pipe delivery, which is usually inappropriate in a mailing list. The errors_to option specifies that any delivery errors caused by addresses taken from a mailing list are to be sent to the given address rather than the original sender of the message. However, before acting on this, Exim verifies the error address, and ignores it if verification fails. For example, using the configuration above, mail sent to dicts@lists.example is passed on to those addresses contained in /usr/lists/dicts, with error reports directed to dicts-request@lists.example, provided that this address can be verified. There could be a file called/usr/lists/dicts-request containing the address(es) of this particular list’s manager(s), but other approaches, such as setting up an earlier router (possibly using the local_part_prefix or local_part_suffix options) to handle addresses of the form owner-xxx or xxx-request, are also possible.

3. Syntax errors in mailing lists

If an entry in redirection data contains a syntax error, Exim normally defers delivery of the original address. That means that a syntax error in a mailing list holds up all deliveries to the list. This may not be appropriate when a list is being maintained automatically from data supplied by users, and the addresses are not rigorously checked. If the skip_syntax_errors option is set, the redirect router just skips entries that fail to parse, noting the incident in the log. If in additionsyntax_errors_to is set to a verifiable address, a message is sent to it whenever a broken address is skipped. It is usually appropriate to set syntax_errors_to to the same address as errors_to.

4. Re-expansion of mailing lists

Exim remembers every individual address to which a message has been delivered, in order to avoid duplication, but it normally stores only the original recipient addresses with a message. If all the deliveries to a mailing list cannot be done at the first attempt, the mailing list is re-expanded when the delivery is next tried. This means that alterations to the list are taken into account at each delivery attempt, so addresses that have been added to the list since the message arrived will therefore receive a copy of the message, even though it pre-dates their subscription. If this behaviour is felt to be undesirable, the one_time option can be set on the redirect router. If this is done, any addresses generated by the router that fail to deliver at the first attempt are added to the message as “top level” addresses, and the parent address that generated them is marked “delivered”. Thus, expansion of the mailing list does not happen again at the subsequent delivery attempts. The disadvantage of this is that if any of the failing addresses are incorrect, correcting them in the file has no effect on pre-existing messages. The original top-level address is remembered with each of the generated addresses, and is output in any log messages. However, any intermediate parent addresses are not recorded. This makes a difference to the log only if the all_parents selector is set, but for mailing lists there is normally only one level of expansion anyway.

5. Closed mailing lists

The examples so far have assumed open mailing lists, to which anybody may send mail. It is also possible to set up closed lists, where mail is accepted from specified senders only. This is done by making use of the generic senders option to restrict the router that handles the list. The following example uses the same file as a list of recipients and as a list of permitted senders. It requires three routers:

  driver = redirect
  domains = lists.example
  local_part_suffix = -request
  file = /usr/lists/$local_part$local_part_suffix

  driver = redirect
  domains = lists.example
  senders = ${if exists {/usr/lists/$local_part}\
  file = /usr/lists/$local_part
  errors_to = $local_part-request@lists.example

  driver = redirect
  domains = lists.example
  data = :fail: $local_part@lists.example is a closed mailing list

All three routers have the same domains setting, so for any other domains, they are all skipped. The first router runs only if the local part ends in -request. It handles messages to the list manager(s) by means of an open mailing list. The second router runs only if the senders precondition is satisfied. It checks for the existence of a list that corresponds to the local part, and then checks that the sender is on the list by means of a linear search. It is necessary to check for the existence of the file before trying to search it, because otherwise Exim thinks there is a configuration error. If the file does not exist, the expansion of senders is *, which matches all senders. This means that the router runs, but because there is no list, declines, and no_more ensures that no further routers are run. The address fails with an “unrouteable address” error. The third router runs only if the second router is skipped, which happens when a mailing list exists, but the sender is not on it. This router forcibly fails the address, giving a suitable error message.

6. Variable Envelope Return Paths (VERP)

Variable Envelope Return Paths – see – are a way of helping mailing list administrators discover which subscription address is the cause of a particular delivery failure. The idea is to encode the original recipient address in the outgoing envelope sender address, so that if the message is forwarded by another host and then subsequently bounces, the original recipient can be extracted from the recipient address of the bounce. Envelope sender addresses can be modified by Exim using two different facilities: the errors_to option on a router (as shown in previous mailing list examples), or the return_path option on a transport. The second of these is effective only if the message is successfully delivered to another host; it is not used for errors detected on the local host (see the description of return_path in chapter 24). Here is an example of the use of return_path to implement VERP on an smtp transport:

  driver = smtp
  max_rcpt = 1
  return_path = \
    ${if match {$return_path}{^(.+?)-request@your.dom.example\$}\

This has the effect of rewriting the return path (envelope sender) on outgoing SMTP messages, if the local part of the original return path ends in “-request”, and the domain is your.dom.example. The rewriting inserts the local part and domain of the recipient into the return path. Suppose, for example, that a message whose return path has been set to somelist-request@your.dom.example is sent tosubscriber@other.dom.example. In the transport, the return path is rewritten as


For this to work, you must tell Exim to send multiple copies of messages that have more than one recipient, so that each copy has just one recipient. This is achieved by setting max_rcpt to 1. Without this, a single copy of a message might be sent to several different recipients in the same domain, in which case $local_part is not available in the transport, because it is not unique. Unless your host is doing nothing but mailing list deliveries, you should probably use a separate transport for the VERP deliveries, so as not to use extra resources in making one-per-recipient copies for other deliveries. This can easily be done by expanding the transport option in the router:

  driver = dnslookup
  domains = ! +local_domains
  transport = \
    ${if match {$return_path}{^(.+?)-request@your.dom.example\$}\

If you want to change the return path using errors_to in a router instead of using return_path in the transport, you need to set errors_toon all routers that handle mailing list addresses. This will ensure that all delivery errors, including those detected on the local host, are sent to the VERP address. On a host that does no local deliveries and has no manual routing, only the dnslookup router needs to be changed. A special transport is not needed for SMTP deliveries. Every mailing list recipient has its own return path value, and so Exim must hand them to the transport one at a time. Here is an example of a dnslookup router that implements VERP:

  driver = dnslookup
  domains = ! +local_domains
  transport = remote_smtp
  errors_to = \
    ${if match {$return_path}{^(.+?)-request@your.dom.example\$}}

Before you start sending out messages with VERPed return paths, you must also configure Exim to accept the bounce messages that come back to those paths. Typically this is done by setting a local_part_suffix option for a router, and using this to route the messages to wherever you want to handle them. The overhead incurred in using VERP depends very much on the size of the message, the number of recipient addresses that resolve to the same remote host, and the speed of the connection over which the message is being sent. If a lot of addresses resolve to the same host and the connection is slow, sending a separate copy of the message for each address may take substantially longer than sending a single copy with many recipients (for which VERP cannot be used).

7. Virtual domains

The phrase virtual domain is unfortunately used with two rather different meanings:

  • A domain for which there are no real mailboxes; all valid local parts are aliases for other email addresses. Common examples are organizational top-level domains and “vanity” domains.
  • One of a number of independent domains that are all handled by the same host, with mailboxes on that host, but where the mailbox owners do not necessarily have login accounts on that host.

The first usage is probably more common, and does seem more “virtual” than the second. This kind of domain can be handled in Exim with a straightforward aliasing router. One approach is to create a separate alias file for each virtual domain. Exim can test for the existence of the alias file to determine whether the domain exists. The dsearch lookup type is useful here, leading to a router of this form:

  driver = redirect
  domains = dsearch;/etc/mail/virtual
  data = ${lookup{$local_part}lsearch{/etc/mail/virtual/$domain}}

The domains option specifies that the router is to be skipped, unless there is a file in the /etc/mail/virtual directory whose name is the same as the domain that is being processed. When the router runs, it looks up the local part in the file to find a new address (or list of addresses). The no_more setting ensures that if the lookup fails (leading to data being an empty string), Exim gives up on the address without trying any subsequent routers. This one router can handle all the virtual domains because the alias file names follow a fixed pattern. Permissions can be arranged so that appropriate people can edit the different alias files. A successful aliasing operation results in a new envelope recipient address, which is then routed from scratch. The other kind of “virtual” domain can also be handled in a straightforward way. One approach is to create a file for each domain containing a list of valid local parts, and use it in a router like this:

  driver = accept
  domains = dsearch;/etc/mail/domains
  local_parts = lsearch;/etc/mail/domains/$domain
  transport = my_mailboxes

The address is accepted if there is a file for the domain, and the local part can be found in the file. The domains option is used to check for the file’s existence because domains is tested before the local_parts option (see section 3.12). You cannot use require_files, because that option is tested after local_parts. The transport is as follows:

  driver = appendfile
  file = /var/mail/$domain/$local_part
  user = mail

This uses a directory of mailboxes for each domain. The user setting is required, to specify which uid is to be used for writing to the mailboxes. The configuration shown here is just one example of how you might support this requirement. There are many other ways this kind of configuration can be set up, for example, by using a database instead of separate files to hold all the information about the domains.

8. Multiple user mailboxes

Heavy email users often want to operate with multiple mailboxes, into which incoming mail is automatically sorted. A popular way of handling this is to allow users to use multiple sender addresses, so that replies can easily be identified. Users are permitted to add prefixes or suffixes to their local parts for this purpose. The wildcard facility of the generic router options local_part_prefix and local_part_suffixcan be used for this. For example, consider this router:

  driver = redirect
  file = $home/.forward
  local_part_suffix = -*

It runs a user’s .forward file for all local parts of the form username-*. Within the filter file the user can distinguish different cases by testing the variable $local_part_suffix. For example:

if $local_part_suffix contains -special then
save /home/$local_part/Mail/special

If the filter file does not exist, or does not deal with such addresses, they fall through to subsequent routers, and, assuming no subsequent use of the local_part_suffix option is made, they presumably fail. Thus, users have control over which suffixes are valid. Alternatively, a suffix can be used to trigger the use of a different .forward file – which is the way a similar facility is implemented in another MTA:

  driver = redirect
  file = $home/.forward$local_part_suffix
  local_part_suffix = -*

If there is no suffix, .forward is used; if the suffix is -special, for example, .forward-special is used. Once again, if the appropriate file does not exist, or does not deal with the address, it is passed on to subsequent routers, which could, if required, look for an unqualified .forwardfile to use as a default.

9. Simplified vacation processing

The traditional way of running the vacation program is for a user to set up a pipe command in a .forward file (see section 22.6 for syntax details). This is prone to error by inexperienced users. There are two features of Exim that can be used to make this process simpler for users:

  • A local part prefix such as “vacation-” can be specified on a router which can cause the message to be delivered directly to thevacation program, or alternatively can use Exim’s autoreply transport. The contents of a user’s .forward file are then much simpler. For example:
    spqr, vacation-spqr
  • The require_files generic router option can be used to trigger a vacation delivery by checking for the existence of a certain file in the user’s home directory. The unseen generic option should also be used, to ensure that the original delivery also proceeds. In this case, all the user has to do is to create a file called, say, .vacation, containing a vacation message.

Another advantage of both these methods is that they both work even when the use of arbitrary pipes by users is locked out.

10. Taking copies of mail

Some installations have policies that require archive copies of all messages to be made. A single copy of each message can easily be taken by an appropriate command in a system filter, which could, for example, use a different file for each day’s messages. There is also a shadow transport mechanism that can be used to take copies of messages that are successfully delivered by local transports, one copy per delivery. This could be used, inter alia, to implement automatic notification of delivery by sites that insist on doing such things.

11. Intermittently connected hosts

It has become quite common (because it is cheaper) for hosts to connect to the Internet periodically rather than remain connected all the time. The normal arrangement is that mail for such hosts accumulates on a system that is permanently connected. Exim was designed for use on permanently connected hosts, and so it is not particularly well-suited to use in an intermittently connected environment. Nevertheless there are some features that can be used.

12. Exim on the upstream server host

It is tempting to arrange for incoming mail for the intermittently connected host to remain on Exim’s queue until the client connects. However, this approach does not scale very well. Two different kinds of waiting message are being mixed up in the same queue – those that cannot be delivered because of some temporary problem, and those that are waiting for their destination host to connect. This makes it hard to manage the queue, as well as wasting resources, because each queue runner scans the entire queue. A better approach is to separate off those messages that are waiting for an intermittently connected host. This can be done by delivering these messages into local files in batch SMTP, “mailstore”, or other envelope-preserving format, from where they are transmitted by other software when their destination connects. This makes it easy to collect all the mail for one host in a single directory, and to apply local timeout rules on a per-message basis if required. On a very small scale, leaving the mail on Exim’s queue can be made to work. If you are doing this, you should configure Exim with a long retry period for the intermittent host. For example:

cheshire.wonderland.fict.example    *   F,5d,24h

This stops a lot of failed delivery attempts from occurring, but Exim remembers which messages it has queued up for that host. Once the intermittent host comes online, forcing delivery of one message (either by using the -M or -R options, or by using the ETRN SMTP command (see section 47.8) causes all the queued up messages to be delivered, often down a single SMTP connection. While the host remains connected, any new messages get delivered immediately. If the connecting hosts do not have fixed IP addresses, that is, if a host is issued with a different IP address each time it connects, Exim’s retry mechanisms on the holding host get confused, because the IP address is normally used as part of the key string for holding retry information. This can be avoided by unsetting retry_include_ip_address on the smtp transport. Since this has disadvantages for permanently connected hosts, it is best to arrange a separate transport for the intermittently connected ones.

13. Exim on the intermittently connected client host

The value of smtp_accept_queue_per_connection should probably be increased, or even set to zero (that is, disabled) on the intermittently connected host, so that all incoming messages down a single connection get delivered immediately. Mail waiting to be sent from an intermittently connected host will probably not have been routed, because without a connection DNS lookups are not possible. This means that if a normal queue run is done at connection time, each message is likely to be sent in a separate SMTP session. This can be avoided by starting the queue run with a command line option beginning with -qq instead of -q. In this case, the queue is scanned twice. In the first pass, routing is done but no deliveries take place. The second pass is a normal queue run; since all the messages have been previously routed, those destined for the same host are likely to get sent as multiple deliveries in a single SMTP connection.