Postfix Configuration Files and descriptions

image_pdfimage_print

Postfix Configuration Files
The Ubuntu Postfix mail server uses three configuration files, all of which are installed in the
directory /etc/postfix:
dynamicmaps.cf:
Identifies additional capabilities to be loaded at run time based on
the type of operation that is being performed.
main.cf:
Contains configuration information for Postfix that is used during message
processing.
master.cf:
Contains parameters used when the Postfix master program runs other
programs from /usr/lib/postfix.
Postfix can also use standard mailer configuration files such as /etc/aliases (which allows
e‐mail addressed to one user to be automatically delivered to another), but this is not a Postfix-
specific configuration file.
The main.cf configuration file is the only Postfix configuration file that most users will ever
have to modify. As installed on an Ubuntu system, the main.cf configuration file for a system
following the Internet site model looks like the following (I’ve removed some irrelevant com‐
ments and white space):

 

In order, these configuration variables do the following:
myorigin:
An option for Debian and derivative distributions (such as Ubuntu) that
enables you to use the first line of the text file /etc/mailname as the name of the
mailer. This is actually set later in the default file.
smtpd_banner:
Sets the value of the banner that is displayed when an SMTP connec‐
tion is established. In this case, the banner is constructed by using the value of other
variables set in the configuration file.
biff:
Determines whether the local e‐mail notification service (biff) should be used
for each user with new mail each time Postfix processes the incoming mail queue. In
this case, it is disabled because biff notifications can cause a performance drain, and
are relevant only on the machine that houses the mail files. Users who use local mail
files can enable this for themselves.
append_dot_mydomain:
Determines whether Postfix should append a domain name
to mail sent to user@host. Nowadays, this is usually handled by the MUA, so this is
disabled.
delay_warning_time:
Uncommenting this parameter would specify the period of
time after which users would be notified if mail that they had sent had not yet been
delivered. After all, the remote site could be using Microsoft Exchange, and might be
down.
smtpd_tls_cert_file:
Identifies the full pathname of the file on this system that
holds the certificate used by this machine when sending messages using TLS (Transport
Layer Security).
smtpd_tls_key_file:
Identifies the full pathname of the file on this system that
holds the RSA private key for the Postfix SMTP client when sending messages using TLS
(Transport Layer Security).
smtpd_use_tls:
Determines whether this Postfix server should use TLS when a
remote SMTP server announces STARTTLS support. If the remote server does not
announce STARTTLS support, the message is sent in the clear.
1045
Part III: Ubuntu for System Administrators
smtpd_tls_session_cache_database:
Identifies the organization and location of
the SMTP server TLS session cache used by the tlsmgr daemon.
smtp_tls_session_cache_database:
Identifies the organization and location of the
SMTP client TLS session cache used by the tlsmgr daemon.
myhostname:
Identifies the actual Internet hostname of this system. By default, this
value is the value returned by gethostname().
alias_maps:
Identifies the organization and full pathname of the aliases file used for
local mail delivery.
alias_database:
Identifies the organization and full pathname of the aliases file used
for local mail delivery, and which is updated using the traditional newaliases com‐
mand. This is often the same file as that identified by the alias_maps parameter, but
need not be.
myorigin:
Identifies the name of the host or domain that local mail is assumed to come
from and is sent to. On Ubuntu systems, it is the name of a file containing whatever you
specified as the mail name when installing Postfix. This is suitable for single-domain
installations, but insufficient for Postfix mail servers that support multiple domains.
mydestination:
A list of domains for which mail is delivered via local mail delivery. I
specified ubuntu.vonhagen.org as the name of my host when I installed Postfix╃—╃in
most cases, mail.domain-name (i.e., mail.vonhagen.org, in my case) would be the
standard name to use for a mail server to help keep your sysadmins sane and make it
easy to locate/identify your domain’s mail server.
relayhost:
If outgoing mail must be sent to another mail server for delivery, this
parameter identifies that mail server; otherwise, it is empty.
mynetworks:
Identifies the networks or specific hosts from which this mail server will
send mail. This information is specified in both IPv4 and IPv6 formats. In this case, the
mail server will only send mail from the loopback network, which is a problem. This is
discussed in the following section, “Identifying Trusted Hosts and Domains.”
mailbox_size_limit:
Identifies the maximum size of any mailbox on the system. In
this case, 0 means that there is no limit.
recipient_delimiter:
Identifies the separator used internally by the Postfix server
between usernames and addresses.
inet_interfaces:
Identifies the network interfaces on which the machine can receive
mail. In this case, the Postfix server will listen on all network interfaces.
html_directory:
Identifies the location of HTML files that describe how to install and
configure a Postfix server and various Postfix features.
A complete list of Postfix configuration parameters and possible values is available in the files sec‐
tion of the online reference information for the postconf command (man 5 postconf) or online
at locations such as www.postfix.org/postconf.5.html.

cron job, crontab -e, -l using

image_pdfimage_print

Cron Job  Timing ,

Advanced Crontab

The Crontabs discussed above are user crontabs. Each of the above crontabs is associated with a user, even the system crontab which is associated with the root user. There are two other types of crontab.

Firstly, as mentioned above anacron uses the run-parts command and /etc/cron.hourly/etc/cron.weekly, and /etc/cron.monthly directories. However anacron itself is invoked from the /etc/crontab file. This file could be used for other cron commands, but probably shouldn’t be. Here’s an example line from a ficticious /etc/crontab:

This would run Rusty’s command script as user rusty from his home directory. However, it is not usual to add commands to this file. While an experienced user should know about it, it is not recommended that you add anything to /etc/crontab. Apart from anything else, this could cause problem if the /etc/crontab file is affected by updates! Rusty could lose his command.

The second type of crontab is to be found in /etc/cron.d. Within the directory are small named crontabs. The directory is often used by packages, and the small crontabs allows a user to be associated with the commands in them.

Instead of adding a line to /etc/crontab which Rusty knows is not a good idea, Rusty might well add a file to /etc/cron.d with the name rusty, containing his cron line above. This would not be affected by updates but is a well known location.

When would you use these alternate crontab locations? Well, on a single user machine or a shared machine such as a school or college server, auser crontab would be the way to go. But in a large IT department, where several people might look after a server, then /etc/cron.d is probably the best place to install crontabs – it’s a central point and saves searching for them!

You may not need to look at /etc/crontab or /etc/cron.d, let alone edit them by hand. But an experienced user should perhaps know about them and that the packages that he/she installs may use these locations for their crontabs.

string

meaning

@reboot

Run once, at startup.

@yearly

Run once a year, “0 0 1 1 *”.

@annually

(same as @yearly)

@monthly

Run once a month, “0 0 1 * *”.

@weekly

Run once a week, “0 0 * * 0”.

@daily

Run once a day, “0 0 * * *”.

@midnight

(same as @daily)

@hourly

Run once an hour, “0 * * * *”.

Using Cron

To use cron for tasks meant to run only for your user profile, add entries to your own user’s crontab file. Start the crontab editor from a terminal window:

crontab -e

Edit the crontab using the format described in the next sections. Save your changes. (Exiting without saving will leave your crontab unchanged.)

Note that a great source of information about the format can be found at:

man 5 crontab

Commands that normally run with administrative privileges (i.e. they are generally run using sudo) should be added to the root user’s crontab (instead of the user’s crontab):

sudo crontab -e

Crontab Sections

Each of the sections is separated by a space, with the final section having one or more spaces in it. No spaces are allowed within Sections 1-5, only between them. Sections 1-5 are used to indicate when and how often you want the task to be executed. This is how a cron job is laid out:

minute (0-59), hour (0-23, 0 = midnight), day (1-31), month (1-12), weekday (0-6, 0 = Sunday), command

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on January 1st plus every Monday in January. An asterisk (*) can be used so that every instance (every hour, every weekday, every month, etc.) of a time period is used. Code:

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on every day of every month.

Comma-separated values can be used to run more than one instance of a particular command within a time period. Dash-separated values can be used to run a command continuously. Code:

The above example will run /usr/bin/somedirectory/somecommand at 01 and 31 past the hours of 4:00am and 5:00am on the 1st through the 15th of every January and June.

The “/usr/bin/somedirectory/somecommand” text in the above examples indicates the task which will be run at the specified times. It is recommended that you use the full path to the desired commands as shown in the above examples. Enter which somecommand in the terminal to find the full path to somecommand. The crontab will begin running as soon as it is properly edited and saved.

You may want to run a script some number of times per time unit. For example if you want to run it every 10 minutes use the following crontab entry (runs on minutes divisible by 10: 0, 10, 20, 30, etc.)

which is also equivalent to the more cumbersome

Crontab Options

  • The -l option causes the current crontab to be displayed on standard output.
  • The -r option causes the current crontab to be removed.
  • The -e option is used to edit the current crontab using the editor specified by the EDITOR environment variable.

After you exit from the editor, the modified crontab will be checked for accuracy and, if there are no errors, installed automatically. The file is stored in /var/spool/cron/crontabs but should only be edited via the crontab command.

Enable User Level Cron

If the /etc/cron.allow file exists, then users must be listed in it in order to be allowed to run the crontab command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does, then users must not be listed in the /etc/cron.deny file in order to run crontab.

In the case where neither file exists, the default on current Ubuntu (and Debian, but not some other Linux and UNIX systems) is to allow all users to run jobs with crontab.

No cron.allow or cron.deny files exist in a standard Ubuntu install, so all users should have cron available by default, until one of those files is created. If a blank cron.deny file has been created, that will change to the standard behavior users of other operating systems might expect: cron only available to root or users in cron.allow.

Note, userids on your system which do not appear in /etc/shadow will NOT have operational crontabs, if you desire to enter a user in /etc/passwd, but NOT /etc/shadow that user’s crontab will never run. Place an entry in /etc/shadow for the user with a * for the password crypt,ie:

Further Considerations

Crontab commands are generally stored in the crontab file belonging to your user account (and executed with your user’s level of permissions). If you want to regularly run a command requiring administrative permissions, edit the root crontab file:

Depending on the commands being run, you may need to expand the root users PATH variable by putting the following line at the top of their crontab file:

It is sensible to test that your cron jobs work as intended. One method for doing this is to set up the job to run a couple of minutes in the future and then check the results before finalising the timing. You may also find it useful to put the commands into script files that log their success or failure, for example:

For more information, see the man pages for cron and crontab (man is detailed on the Basic Commands page). If your machine is regularly switched off, you may also be interested in at and anacron, which provide other approaches to scheduled tasks. For example, anacron offers simple system-wide directories for running commands hourly, daily, weekly, and monthly. Scripts to be executed in said times can be placed in/etc/cron.hourly//etc/cron.daily//etc/cron.weekly/, and /etc/cron.monthly/. All scripts in each directory are run as root, and a specific order to running the scripts can be specified by prefixing the scripts’ filenames with numbers (see the man page for run-parts for more details). Although the directories contain periods in their names, run-parts will not accept a file name containing a period and will fail silently when encountering them.

/etc/init.d/cron

MySQL: Connect From an Other System / Computer

image_pdfimage_print

You need to allow access to 192.168.1.5 from apache server located at 192.168.1.8.

Step #1: Configure MySQL Server For Remote Access

Modify or append as follows:

Step #2: Linux Firewall Configuration For TCP Port # 3306
# >>>> You need to open TCP port # 3306 at the firewall level, enter:

Sample outputs:

How Do I Enable Remote Access To MySQL Database Server?

image_pdfimage_print

How Do I Enable Remote Access To MySQL Database Server?

You need type the following commands which will allow remote connections.
Step # 1: Login Using SSH (if server is outside your data center)

First, login over ssh to remote MySQL database server:

Once connected you need to edit the MySQL server configuration file my.cnf using a text editor such as vi.

Step # 3: Once file opened, locate line that read as follows

Where,

bind-address : IP address to bind to.
skip-networking : Don’t listen for TCP/IP connections at all. All interaction with mysqld must be made via Unix sockets. This option is highly recommended for systems where only local requests are allowed. Since you need to allow remote connection this line should be removed from my.cnf or put it in comment state.
Step# 4 Save and Close the file

Step # 5 Grant access to remote IP address

 

Step # 6: Logout of MySQL

Type exit command to logout mysql:
mysql> exit

Step # 7: Open port 3306

 

Step # 8: Test it