Spam/AV for Postfix

Taken from http://wiki.centos.org/HowTos/Amavisd

1. Introduction

Amavisd-new is a reliable high-performance interface between an email server (MTA) and content checkers such as virus scanners (ClamAV), and/or SpamAssassin. Amavisd-new supports both (E)SMTP and LMTP protocols as well as UNIX sockets for communicating with the MTA and content checkers. In addition, it may also use dedicated helper programs such as the Mail::SpamAssassin Perl module.


Amavisd-new supports a number of MTA's. As the Amavisd-new documentation states, Amavisd-new works "best with Postfix, fine with dual-sendmail setup and Exim v4, works with sendmail/milter, or with any MTA as a SMTP relay". This guide was written and tested on Postfix and can be used to compliment the basic Postfix guide here. Other MTA's may get added later.


We are going to configure Amavisd-new's daemon, amavisd, to accept mail from our MTA, pass it to ClamAV and SpamAssassin for checking, and then return it back to our MTA for delivery. Amavisd will use lmtp listening on TCP port 10024 to accept mail from our MTA and then pass it to ClamAV using a local UNIX socket and SpamAssassin using the Mail::SpamAssassin Perl module. Scanned mail will then be returned to our MTA using smtp on TCP port 10025 for delivery.


Amavisd-new doesn't have to reside on the same physical server as the MTA, and in high load environments it is not uncommon to have Amavisd-new, ClamAV and SpamAssassin on a physically separate server than the MTA.

2. Installation

Amavisd-new and ClamAV were installed from the RPMForge repository. To enable the RPMForge repository, please see the RPMForge instructions.


SpamAssassin is part of the CentOS base repository, but RPMForge carries a more current version of it. You should consider using the version from RPMForge. To do so (especially if you use the priorities plugin for yum), add the following to the [base] and the [updates] sections of your /etc/yum.repos.d/CentOS-Base.repo file:

[base] exclude=spamassass* ... [updates] exclude=spamassass* ...


First, install amavisd-new, clamav and spamassassin packages:


yum --enablerepo=rpmforge,rpmforge-extras install amavisd-new clamav clamav-devel clamd spamassassin

This will likely also install a bunch of dependencies including various perl modules and archive packages. If all went well, two new users, amavis and clamav should have been installed onto the system:


# cat /etc/passwd | grep "amavis\|clamav" clamav:x:101:102:Clam Anti Virus Checker:/var/clamav:/sbin/nologin amavis:x:102:103:Amavis email scan user:/var/amavis:/bin/sh





In addition, the clamav user should automatically have been added to the amavis group:


# groups clamav clamav : clamav amavis





If not, you can manually add clamav to the amavis group:


gpasswd -a clamav amavis





Finally, three new services should have been added to the system


# chkconfig --list | grep "amavisd\|clamd\|spamassassin" amavisd 0:off 1:off 2:on 3:on 4:on 5:on 6:off clamd 0:off 1:off 2:on 3:on 4:on 5:on 6:off spamassassin 0:off 1:off 2:off 3:off 4:off 5:off 6:off





The spamassassin service, which starts spamd, can be set to off as Amavisd-new doesn't actually use the spamassassin daemon (spamd) but rather loads spamassassin as a module.

3. Configuration




SpamAssassin actually requires no special configuration to work with Amavisd-new and will work out of the box. This does not mean that you cannot configure it via/etc/mail/spamassassin/local.cf, or your own cf-files in that directory.

3.1. ClamAV




ClamAV's configuration is stored in /etc/clamd.conf. We must edit /etc/clamd.conf to tell ClamAV that Amavisd-new will communicate using a local UNIX socket rather than a tcp socket, and where to find that socket. Edit the LocalSocket setting and comment out the TCPSocket like so:


### /etc/clamd.conf # # Set the LocalSocket for clam # Note this *MUST* match that set in /etc/amavisd.conf # LocalSocket /var/run/clamav/clamd.sock # # Comment out the TCPSocket setting: # TCPSocket 3310




3.2. Amavisd-new




Amavisd-new keeps it's configuration settings in /etc/amavisd.conf.


Due to the power and flexibility of Amavisd-new, there is actually quite a lot to look at, so we'll cover some of the more important settings a few at a time.


First up, we can disable either virus or spam checking by uncommenting the following lines (by default, both virus and spam checking is enabled as the lines are commented out):


### /etc/amavisd.conf: # # To disable virus or spam checks, uncomment the following: # # @bypass_virus_checks_maps = (1); # controls running of anti-virus code # @bypass_spam_checks_maps = (1); # controls running of anti-spam code # $bypass_decode_parts = 1; # controls running of decoders & dearchivers





Next, note to following lines although no change is required:


$max_servers = 2; # num of pre-forked children (2..30 is common), -m $daemon_user = "amavis"; # (no default; customary: vscan or amavis), -u $daemon_group = "amavis"; # (no default; customary: vscan or amavis), -g ... $inet_socket_port = 10024; # listen on this local TCP port(s) ... # $notify_method = 'smtp:[127.0.0.1]:10025'; # $forward_method = 'smtp:[127.0.0.1]:10025'; # set to undef with milter!





$max_servers sets the number of concurrent Amavisd-new processes and must match the number set in /etc/postfix/master.cf "maxproc" column for the amavisfeed service (see configuration of Postfix below).


$daemon_user and $daemon_group should match the user and group, respectively, under which Amavisd-new will run.


$inet_socket_port defines the tcp port over which Amavisd-new will accept connections from Postfix.


$notify_method and $forward_method define the reinjection path of mail from Amavisd-new back into Postfix.


The following settings must be edited (in the case of $mydomain and $myhostname) and uncommented (remove the leading #):


$mydomain = 'example.com'; # Edit: a convenient default for other settings $MYHOME = '/var/amavis'; # Uncomment: a convenient default for other settings, -H $helpers_home = "$MYHOME/var"; # Uncomment: working directory for SpamAssassin, -S $lock_file = "$MYHOME/var/amavisd.lock"; # Uncomment, -L $pid_file = "$MYHOME/var/amavisd.pid"; # Uncomment, -P $myhostname = 'mail.example.com'; # Uncomment & Edit: must be a fully-qualified domain name!





Next up are some SpamAssassin settings which override the default SpamAssassin settings:


$sa_tag_level_deflt = 2.0; # add spam info headers if at, or above that level $sa_tag2_level_deflt = 6.2; # add 'spam detected' headers at that level $sa_kill_level_deflt = 6.9; # triggers spam evasive actions (e.g. blocks mail) $sa_dsn_cutoff_level = 10; # spam level beyond which a DSN is not sent # $sa_quarantine_cutoff_level = 25; # spam level beyond which quarantine is off $penpals_bonus_score = 8; # (no effect without a @storage_sql_dsn database) $penpals_threshold_high = $sa_kill_level_deflt; # don't waste time on hi spam $sa_mail_body_size_limit = 400*1024; # don't waste time on SA if mail is larger $sa_local_tests_only = 0; # only tests which do not require internet access?





None of these need to be changed, but it's worthwhile being aware of them as this is the most convenient place to tweak spam thresholds.


$sa_tag_level_deflt is the level at which Amavisd-new will write spam info headers such as X-Spam-Flag, X-Spam-Score and X-Spam-Status. If you would always like header info to be written to all messages, set this value to -999.


$sa_tag2_level_deflt sets the level at which spam is tagged in the subject line of the message.


$sa_kill_level_deflt sets the level at which Amavisd-new will block the message and quarantine it. This is useful as SpamAssassin doesn't do this by default.


$sa_dsn_cutoff_level is the level at which delivery failure notices are no longer sent to the sender. As most spam sender addresses are forged anyway, it makes sense not to send failure notices in response to obvious spam as you're only contributing to the problem of backscatter.


$sa_quarantine_cutoff_level is the level at which spam isn't even quarantined. By default it is commented out meaning all spam will be quarantined.


Next up are some email addresses for notifications to be sent:


$virus_admin = "virusalert\@$mydomain"; # notifications recip. $mailfrom_notify_admin = "virusalert\@$mydomain"; # notifications sender $mailfrom_notify_recip = "virusalert\@$mydomain"; # notifications sender $mailfrom_notify_spamadmin = "spam.police\@$mydomain"; # notifications sender





You will probably want to set these to "postmaster\@$mydomain" or some other address you would rather receive spam notifications.


Finally, we need to uncomment the section for ClamAV like so:


### http://www.clamav.net/ ['ClamAV-clamd', \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"], qr/\bOK$/, qr/\bFOUND$/, qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ], # # NOTE: run clamd under the same user as amavisd, or run it under its own # # uid such as clamav, add user clamav to the amavis group, and then add # # AllowSupplementaryGroups to clamd.conf; # # NOTE: match socket name (LocalSocket) in clamav.conf to the socket name in # # this entry; when running chrooted one may prefer socket "$MYHOME/clamd".





Note that the "/var/run/clamav/clamd.sock" setting must match the "LocalSocket /var/run/clamav/clamd.sock" we made earlier in /etc/clamd.conf.

3.3. Postfix




Next we need to configure the services in Postfix (/etc/postfix/master.cf) to allow mail to be passed to Amavisd-new for filtering and then reinjected back into Postfix.


First we will configure the Amavisd-new service to accept mail From Postfix. Amavisd-new supports both lmtp and smtp, and in this instance we have chosen to use the lmtp protocol. (FIXME: I'm not aware of any reasons for choosing one protocol over the other so selected to use lmtp on the basis that having local delivery to Amavisd-new show up in the logs as "lmtp" makes the log files somewhat easier to read).


Open /etc/postfix/master.cf and add the following service called "amavisfeed":


# ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== amavisfeed unix - - n - 2 lmtp -o lmtp_data_done_timeout=1200 -o lmtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20





Note that the number (2) in the "maxproc" column must match the $max_servers setting in /etc/amavisd.conf. For a detailed description of the options, see the Amavisd-new documentation (/usr/share/doc/amavisd-new-2.5.4/README.postfix.html).


Then we must define a dedicated service to reinject mail back into Postfix. For this we add an smtp service listening on localhost (127.0.0.1) tcp port 10025 (the default setting in /etc/amavisd.conf) to /etc/postfix/master.cf:


# ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings -o local_header_rewrite_clients= -o smtpd_milters= -o local_recipient_maps= -o relay_recipient_maps=





For a detailed description of the options, see the Amavisd-new documentation (/usr/share/doc/amavisd-new-2.5.4/README.postfix.html).


After making changes to /etc/postfix/master.cf, we must reload postfix for the changes to take effect:


postfix reload





At this point it might be wise to test the Amavisd-new and Postfix daemons are listening correctly (see the Testing section below).


Once everything is in place and working, the final step is to enable message filtering in Postfix by adding the following setting to /etc/postfix/main.cf:


content_filter=amavisfeed:[127.0.0.1]:10024





and reload postfix for the changes to take effect:


postfix reload





and watch your mail logs.


tail -f /var/log/maillog




3.4. Other MTA's




Amavisd-new can be configured with other MTA's besides Postfix. README docs for other MTA's can be found here:


http://www.ijs.si/software/amavisd/#doc


If anyone would like to contribute section's on configuring other MTA's they should see the How To Contribute page here:


http://wiki.centos.org/HowToContribute

4. Testing




Now would be a good time to test that the services we've defined are working as expected.


First, start the clamd and amavisd services:


# service clamd start Starting Clam AntiVirus Daemon: [ OK ] # service amavisd start Starting Mail Virus Scanner (amavisd): [ OK ]





Now test that the amavisd service is listening on 127.0.0.1:10024 using telnet:


$ telnet localhost 10024 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 [127.0.0.1] ESMTP amavisd-new service ready ehlo localhost 250-[127.0.0.1] 250-VRFY 250-PIPELINING 250-SIZE 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 XFORWARD NAME ADDR PROTO HELO quit 221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel Connection closed by foreign host.





If everything is working then you should see a successful connection similar to above.


Next to test the Postfix smtpd is listening on 127.0.0.1:10025:


$ telnet localhost 10025 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 mail.example.com ESMTP Postfix ehlo localhost 250-mail.example.com 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN quit 221 2.0.0 Bye Connection closed by foreign host.





Again we should see a successful connection as shown above. Now we can test if everything is working by sending special strings to test the scanning.


GTUBE (Generic Test for Unsolicited Bulk Email) string for testing SpamAssassin.


EICAR string for testing ClamAV.


Change directory to /usr/share/doc/amavisd-new-2.5.4/test-messages, and run:


perl -pe 's/./chr(ord(amp;)^255)/sge' <sample.tar.gz.compl | zcat | tar xvf -





to extract the sample test messages. Use these two commands to send a sample spam and virus message through:


$ sendmail -i your-address@example.com < sample-virus-simple.txt $ sendmail -i your-address@example.com < sample-spam-GTUBE-junk.txt





Please replace "your-address@example.com" with your actual address. Check your mail log (i.e., /var/log/maillog) for the scan result from amavis and you should see something like "Passed SPAMMY" or "Blocked INFECTED (Eicar-Test-Signature)". You can now verify your settings match your delivery expectations.

5. SELinux




When SELinux is enabled and in enforcing mode, some additional policies are required for amavisd and ClamAV. The following SELinux policy modules were determined by running the amavisd/ClamAV/SpamAssassin setup described herein on CentOS 5 (fully updated) with SELinux in permissive mode and running AVC error logs through audit2allow as described in the SELinux HowTo.


We are going to create two custom SELinux policy modules, amavisdlocal and clamlocal for amavisd and ClamAV, respectively (SpamAssassin does not require a custom SELinux policy). Cut and paste the following code and save to amavisdlocal.te and clamlocal.te, respectively:


module amavisdlocal 1.0; require { type traceroute_port_t; type pgpkeyserver_port_t; type amavis_var_lib_t; type amavis_t; type clockspeed_port_t; class udp_socket name_bind; class lnk_file { read create unlink getattr }; } #============= amavis_t ============== allow amavis_t clockspeed_port_t:udp_socket name_bind; allow amavis_t pgpkeyserver_port_t:udp_socket name_bind; allow amavis_t traceroute_port_t:udp_socket name_bind; allow amavis_t amavis_var_lib_t:lnk_file { read create unlink getattr };





module clamlocal 1.0; require { type proc_t; type var_t; type sysctl_kernel_t; type clamd_t; class file { read getattr }; class dir { read search }; } #============= clamd_t ============== allow clamd_t proc_t:file { read getattr }; allow clamd_t sysctl_kernel_t:dir search; allow clamd_t sysctl_kernel_t:file read; allow clamd_t var_t:dir read; allow clamd_t var_t:file { read getattr };





Now build and load the amavisdlocal module:


# checkmodule -M -m -o amavisdlocal.mod amavisdlocal.te checkmodule: loading policy configuration from amavisdlocal.te checkmodule: policy configuration loaded checkmodule: writing binary representation (version 6) to amavisdlocal.mod # semodule_package -o amavisdlocal.pp -m amavisdlocal.mod # semodule -i amavisdlocal.pp





and repeat for clamlocal:


# checkmodule -M -m -o clamlocal.mod clamlocal.te checkmodule: loading policy configuration from clamlocal.te checkmodule: policy configuration loaded checkmodule: writing binary representation (version 6) to clamlocal.mod # semodule_package -o clamlocal.pp -m clamlocal.mod # semodule -i clamlocal.pp





Finally, check that our custom local SELinux policy modules are loaded:


# semodule -l amavis 1.1.0 amavisdlocal 1.0 ccs 1.0.0 clamav 1.1.0 clamlocal 1.0 dcc 1.1.0 evolution 1.1.0 iscsid 1.0.0 mozilla 1.1.0 mplayer 1.1.0 nagios 1.1.0 oddjob 1.0.1 pcscd 1.0.0 postgrey 1.0 pyzor 1.1.0 razor 1.1.0 ricci 1.0.0 smartmon 1.1.0




6. Updating



6.1. SpamAssassin




Spam is rapidly changing, and new rules are often written in response. With sa-update, those rules can quickly (potentially within minutes) be distributed and the new spam caught. Please read about sa-update before continuing. To enable automatic updates, open up /etc/cron.d/sa-update in your favorite editor and uncomment the cron line so it looks like this:


10 4 * * * root /usr/share/spamassassin/sa-update.cron 2>&1 | tee -a /var/log/sa-update.log





Save and exit. This cron job will run at 4:10AM everyday.

6.2. ClamAV




ClamAV uses freshclam to update the virus definitions. They are automatically updated with the /etc/cron.daily/freshclam cron script. No actions need to be taken. You can verify that your updates are being completed by looking at your /var/log/clamav/freshclam.log log file.

7. Links




Amavisd-new is supplied with extensive documentation installed to /usr/share/doc/amavisd-new-2.5.4/ and the reader is referred to /usr/share/doc/amavisd-new-2.5.4/README.postfix.html in particular. An online version is also available here: http://www.ijs.si/software/amavisd/README.postfix.html


http://www.linuxjournal.com/article/7778


http://www200.pair.com/mecham/spam/clamav-redhat-amavis.html


http://www200.pair.com/mecham/spam/clamav-amavisd-new.html

Squirrelmail Install

Taken from http://squirrelmail.org/docs/admin/admin-3.html#ss3.1


3. Installing SquirrelMail
3.1 Quick and Dirty install


In order to use SquirrelMail, you should take the following steps.
Download all required software


You can find the SquirrelMail package at the SquirrelMail site. PHP can be found at the PHP site.
Install web server and PHP (version 4.1.0 or above)


SquirrelMail needs a web server with PHP support. Please refere to the PHP installation manual for information about what web servers PHP works with and its installation procedures.


Note that some Linux and Unix distributions provide a precompiled web server with PHP support built in.


We recommend the following PHP settings:

register_globals off - This is a dangerous setting when enabled, and is not generally needed for most recent PHP applications. We no longer release security advisories for issues only exploitable with this setting turned on because it has long been a well-known weakness in PHP (and has been removed from PHP 6). Note that you can easily enable it only for a single legacy application that may require it while keeping the default off for the rest of your applications.
magic_quotes_{runtime, gpc, sybase} off - SquirrelMail may work with any of these turned on, but if you experience stray backslashes in your mail or other strange behaviour, it may be advisable to turn them off.
file_uploads on - This is needed if your users want to attach files to their emails.
safe_mode on or off - Turning safe mode on in SquirrelMail's case is not much more secure than having it off. When it is enabled, incompatibilities with some functionality may arise (see our safe mode notes).

Install IMAP server


What IMAP server you can use depends on what the other components in your email system are and how they were installed and configured. The IMAP server needs to understand and be compatible with how messages are stored on your system.


If you use Unix or Linux with a standard sendmail MTA server, you probably have to install an IMAP server that works with mail stored in /var/spool/mail/, such as UW IMAP, Dovecot, etc.


If you are running your email server on a Windows platform, you might have to enable an IMAP service that is bundled with your email server.


If your email server does not support IMAP, you might have to find some other email server product.
Unpack SquirrelMail package


Unpack the SquirrelMail package in a web-accessible location.
Prepare data and attachment directories


Select a data dirrectory and attachment dirrectory outside of the web server's reach (for example in a Unix or Linux environment, a subdirectory of /var is a good place for these).


The data directory is where SquirrelMail user preferences are stored - even when you have configured SquirrelMail to store user preferences in a database, some plugins might still need to use this directory. The attachment directory is used mainly for temporary storage of file uploads that will become email attachments.


Both of these directories should be writable (not readable) by the web server and no one else (except you). In a Unix or Linux environment, that means that they should be owned by the root user if possible (otherwise whatever user you log in as), their group should be the same as that that the web server runs as (e.g. "www-data", "apache", "nobody", "wheel", etc.), and their permissions should be 0730 (rwx-wx---).


If you use PHP with safe mode enabled, check our safe mode notes which explain other possible limitations on these directories.
Directory access considerations


Only a small subset of the SquirrelMail source code needs to be directly accessible to users' browsers. The rest of the source code is used internally by SquirrelMail. Leaving the entire source tree open to outside access is not a problem or vulnerability, but some attackers have been known to snoop for old versions of SquirrelMail by trying to inspect things such as the ChangeLog file. If you want to employ the maximum level of protection against snoops and would-be attackers, you can make use of the.htaccess files that come with the SquirrelMail source code by adding "AllowOverride AuthConfig" to the Directory settings for SquirrelMail in your Apache configuration file (if using the Apache web server), or you can use the Directory settings suggested in the Apache configuration section below.
Configure SquirrelMail


Run config/conf.pl (or just configure) from the command line. This is a Perl script, so if you do not have Perl installed, please refer to our notes about how to configure SquirrelMail without shell access.


Use the D option to load predefined settings for your particular IMAP server, and edit at least the Server Settings and General Options (making sure to set the "Data Directory" and "Attachment Directory" settings).
Check your SquirrelMail configuration


Browse to http://example.com/squirrelmail/src/configtest.php to test your configuration for common errors. You'll need to adjust the "example.com" and "squirrelmail" parts to match the location where you installed it. Note that in SquirrelMail versions 1.5.0 and up, if you are accessing configtest.php from any place other than the machine where SquirrelMail is installed, you'll need to make sure $allow_remote_configtest is enabled in your configuration file to do so (or see "11. Tweaks" ==> "7. Allow remote configtest" in the configuration utility). If you do that, be sure to disable it again when you are finished.
Log into SquirrelMail


Browse to http://example.com/squirrelmail/ to log in. Again, you'll need to change "example.com" and "squirrelmail" to whatever the location is that you have it installed.
3.2 Installing SquirrelMail on Unix and Linux systems


This chapter covers the installation of SquirrelMail and related packages on a generic Unix or Linux system. It does not cover the installation of the operating system or any other tools required for a fully functional email system.


Any version numbers used in these examples are specific to the time when this documentation was written. You should generally use the most up to date versions of all software involved. That is, if there are newer versions of these packages available now, you'll probably want to substitute the newer numbers in the examples below. Make sure that you are not using old, obsolete or vulnerable software!


This guide uses the UW IMAP server, because it is a simple (and ubiquitous) example and because it can be used in most generic email system setups where incoming mail is stored in the /var/spool/mail directory. If you are planning to offer webmail on a system with a large number of users or where users have large mailboxes, consider planning a better email system design and using different IMAP server software.


PLEASE NOTE that before you begin installing such things as a web server, PHP or an IMAP server, you should check whether or not your system already has such software installed. Many server-class systems come with that kind of software ready to go. Also note that these installation instructions use generic compilation commands that should work on most any system, however your system may have more graceful (and even easier) ways to install software, like the apt-get tool in systems such as Debian and the yum tool in systems such as Fedora/Red Hat.


Typically, you'll need to have root-level access to your server to perform these operations.
Download required software


You will need:
Apache - http://httpd.apache.org/download.cgi
PHP - http://php.net/downloads.php
UW IMAP - http://www.washington.edu/imap/
SquirrelMail - http://squirrelmail.org/download.php




# install -d /usr/local/src/downloads # cd /usr/local/src/downloads # wget http://some-apache-mirror-server/apache/httpd/httpd-2.2.11.tar.gz # wget http://www.php.net/get/php-5.2.9.tar.bz2/from/a/mirror # wget ftp://ftp.cac.washington.edu/mail/imap.tar.Z # wget http://some-sourceforge-mirror/some-path/squirrelmail-1.4.17.tar.bz2




Unpack and install Apache



# cd /usr/local/src # tar -xzvf /usr/local/src/downloads/httpd-2.2.11.tar.gz # cd httpd-2.2.11 # ./configure --prefix=/usr/local/apache --enable-module=so # make # make install




Unpack and install PHP



# cd /usr/local/src # tar --bzip2 -xvf /usr/local/src/downloads/php-5.2.9.tar.bz2 # cd php-5.2.9 # ./configure --prefix=/usr/local/php \ > --with-apxs2=/usr/local/apache/bin/apxs # make # make install






Note that if you decide to configure your PHP compilation with the --disable-all option, you must also add the --enable-session and --with-pcre-regex options.
Add PHP support to Apache


In your main Apache configuration file (typically /etc/httpd/conf/httpd.conf), add this:



<IfModule mod_php5.c> AddType application/x-httpd-php .php </IfModule>




Restart Apache and check if PHP is working


Execute the restart request from the command line:



# /usr/local/apache/bin/apachectl graceful






Create a test file in the document root of Apache and put this in it:



<?php phpinfo(); ?>






Load that file in a web browser and make sure it displays a page describing your PHP system details.
Unpack and install IMAP server


Unpack the UW IMAP package.



# cd /usr/local/src # tar -xzvf /usr/local/src/downloads/imap.tar.Z






Compile UW IMAP:



# cd /usr/local/src/imap-<some version> # make port-name EXTRADRIVERS='' SSLTYPE=unix






Replace "port-name" above with the name that matches your system. Check the file "Makefile" for possible values. If you haven't installed OpenSSL libraries and headers, use "SSLTYPE=none" instead of "SSLTYPE=unix".


Install IMAP server binary:



# strip imapd/imapd # install -d /usr/local/libexec/ # cp imapd/imapd /usr/local/libexec/






Enable IMAP server in inetd.conf:



imap2 stream tcp nowait root /usr/sbin/tcpd /usr/local/libexec/imapd






Now, restart inetd.
Prepare SquirrelMail directories


Make sure to change "nogroup" to whatever group Apache will be running as. You can check what that is by looking at the value of the "Group" setting in your Apache main configuration file (probably /etc/httpd/conf/httpd.conf).



# mkdir /usr/local/squirrelmail # cd /usr/local/squirrelmail # mkdir data temp # chgrp nogroup data temp # chmod 0730 data temp




Unpack SquirrelMail



# cd /usr/local/squirrelmail # tar --bzip2 -xvf /usr/local/src/downloads/squirrelmail-1.4.17.tar.bz2 # mv squirrelmail-1.4.17 www




Configure SquirrelMail


Run the SquirrelMail configuration utility.



# cd /usr/local/squirrelmail # www/configure






This is a Perl script, so if you do not have Perl installed, please refer to our notes about how to configure SquirrelMail without shell access.


Select the "D" option and then configure SquirrelMail with the "uw" preset. Also make sure to set the data and attachment directory settings ("/usr/local/squirrelmail/data" and "/usr/local/squirrelmail/temp" respectively) under "4. General Options". Make any other changes as you see fit, select "S" to save and then "Q" to quit.
Configure access to SquirrelMail in Apache


Modify your main Apache configuration file (typically /etc/httpd/conf/httpd.conf) by adding the following:



Alias /squirrelmail /usr/local/squirrelmail/www <Directory /usr/local/squirrelmail/www> Options None AllowOverride None DirectoryIndex index.php Order Allow,Deny Allow from all </Directory> <Directory /usr/local/squirrelmail/www/*> Deny from all </Directory> <Directory /usr/local/squirrelmail/www/images> Allow from all </Directory> <Directory /usr/local/squirrelmail/www/plugins> Allow from all </Directory> <Directory /usr/local/squirrelmail/www/src> Allow from all </Directory> <Directory /usr/local/squirrelmail/www/templates> Allow from all </Directory> <Directory /usr/local/squirrelmail/www/themes> Allow from all </Directory> <Directory /usr/local/squirrelmail/www/contrib> Order Deny,Allow Deny from All Allow from 127 Allow from 10 Allow from 192 </Directory> <Directory /usr/local/squirrelmail/www/doc> Order Deny,Allow Deny from All Allow from 127 Allow from 10 Allow from 192 </Directory>






Now restart Apache from the command line:



# /usr/local/apache/bin/apachectl graceful






You also might be interested in how to alias different locations to your SquirrelMail installation.
Log into SquirrelMail


Now you should be able to access SquirrelMail by going to http://example.com/squirrelmail.
3.3 Installing SquirrelMail on a hosted service without shell access


This chapter discusses how to install SquirrelMail on a server where you do not have shell access or administrative access.
Requirements


First, check the general SquirrelMail requirements.


Additionally, you should be able to:

add files to your web server's document directory
execute PHP scripts (see the wiki page about testing PHP settings).
PHP scripts should be able to connect to your IMAP, SMTP and any other servers that are used by SquirrelMail.



Optional features:

Control of PHP settings with .htaccess files
PHP access to a SQL database.



You will need:

the address and type of the IMAP server you plan to use
the address of the SMTP server you plan to use

Installation


SquirrelMail is installed by copying all of its files to the web server. You should be able to do that with a FTP, SFTP or FTP-SSL client program.
Configuration


You need to create a configuration file for SquirrelMail. If you have Perl on your own computer, you can run the SquirrelMail configuration script (conf.pl, found in theconfig/ directory) on your computer, using it to adjust your configuration, choose save when done, and then upload the resultant config.php file to the web server. Be sure to put this file into the SquirrelMail config/ directory on your web server. You can now skip to the next step below - testing your configuration.


If you don't have Perl on your computer, you'll need to create the configuration file by hand. Make a copy of config_default.php (also found in the config/ directory), naming it config.php, then open it in your favorite text editor or PHP editor (see below). You must save the file as plain text - do not use a word processor's document format. When you're done with it, put it in the SquirrelMail config/ directory on your web server.


Editing the configuration file is fairly easy: the comments in the default configuration file that you are starting with do a good job of explaining what each setting is for. Keep in mind that the configuration file is actually a PHP script and must contain valid PHP syntax. This means that you should only change values that are (usually but not always) in quotes, making sure not to alter anything else. It is especially important that you leave the semicolons at the end of each line. Always save a copy of the original file in case you make a mistake and need to start over.


When editing the configuration file by hand, you don't have to change ALL the settings in the default configuration file, but there are several that are mandatory:


1. Default Domain: This is set in the $domain setting and is the part after the "@" sign in the mail addresses on your mail server. For example:



$domain = 'example.org';






2. Paths to Data and Attachment Directories: These are set in the $data_dir and $attachment_dir settings. These should usually be the full path from the root directory of your hard disk, not a path that is relative to your web or FTP directory. However, it is possible to specify a relative path from the SquirrelMail src/ directory (for example,../data might work for $data_dir), but this is discouraged in favor of more robust full path specification and placing these directories apart from the SquirrelMail code itself. The web server must have write permission to these directories (your FTP access permissions are not the same as the web server's access permissions). See the comments in the configuration file for more information about setting the correct directory permissions (you may need to ask your hosting service to do this for you). For example:



$data_dir = '/var/lib/squirrelmail/data/'; $attachment_dir = '/var/spool/squirrelmail/attachments/';






3. Address of the IMAP Server: This is set in the $imapServerAddress variable. For example:



$imapServerAddress = 'imap.example.org';






4. IMAP Encryption: You may use encryption for your IMAP connections if desired or necessary. If you don't know what this means, chances are that you may not need it and can skip this step. To do this, you will have to modify the $imapPort and $use_imap_tls settings. For example:



$imapPort = 993; $use_imap_tls = true;






5. Address of the SMTP Server, SMTP Port and SMTP Encryption Settings: You must set the $smtpServerAddress, $smtpPort and $use_smtp_tls settings. These are similar to the IMAP settings explained above. Encrypted SMTP typically uses port 465, and may not be necessary if you are unaware of whether your SMTP server supports encryption. For example:



$smtpServerAddress = 'smtp.example.org'; $smtpPort = 25; $use_smtp_tls = false;






6. IMAP Server Settings: Check the file presets.txt in the SquirrelMail doc/ directory to see if your IMAP server type is listed there. If so, adjust the settings in your configuration file according to the ones that match your server type.


7. Optional: It is easier to continue to configure SquirelMail using a web interface (the "administrator" plugin), however this requires that the web server is able to overwrite the configuration file - some hosting environments do not allow this or require you to ask them to do it for you. This can also be a security risk that you may wish to weigh against the trouble of continuing to edit other configuration settings by hand. If you decide to (and are able to) proceed in this fashion, you'll add "administrator" as the first plugin in the configuration file. Find this part of the configuration file:



/** * To install plugins, just add elements to this array that have * the plugin directory name relative to the /plugins/ directory. * For instance, for the 'sqclock' plugin, you'd put a line like * the following. * $plugins[0] = 'sqclock'; * $plugins[1] = 'attachment_common'; */ // Add list of enabled plugins here






Just after that, you'll add this line:



$plugins[0] = 'administrator';






Next, you'll need to tell the administrator plugin who the administrator is (so that only you have access to it and your normal users do not). Create a file named admins with your IMAP user name in it and upload it to the SquirrelMail config/ directory. When you have logged in to SquirrelMail (see below), click on the "Options" link at the top of the page. If your user name matches the one that is in admins file, you should now see an "Administration" block on the SquirrelMail options page which can be used to further configure SquirrelMail.
Test your configuration


After you have uploaded config.php to the SquirrelMail config/ directory, go to http://example.com/squirrelmail/src/configtest.php and check if the configuration is correct so far. You'll need to adjust the "example.com" and "squirrelmail" parts to match the location where you installed it. Note that in SquirrelMail versions 1.5.0 and up, if you are accessing configtest.php from any place other than the machine where SquirrelMail is installed, you'll need to make sure $allow_remote_configtest is enabled in your configuration file to do so (or see "11. Tweaks" ==> "7. Allow remote configtest" in the configuration utility). If you do that, be sure to disable it again when you are finished.


Every time you change your configuration file, it is a good idea to re-visit this page to make sure everything is working correctly. This page includes making a test connection to the IMAP server, so make sure it is working correctly and accepting connections.
First login


Go to http://example.com/squirrelmail/src/login.php and try logging in. You'll need to adjust the "example.com" and "squirrelmail" parts to match the location where you installed it. You should use a user name and password that are known to work with your IMAP server.
3.4 Prepackaged SquirrelMail installs


If your operating system distribution provides prepackaged SquirrelMail, it might be a good idea to use that. The drawback is that you probably don't have the latest and greatest version. But on the plus side: the whole installation step is managed for you, it integrates better with the rest of your system and you're provided with security updates automatically.


SquirrelMail provides RPM packages. There are two packaging flavors. Standard package that can be used on RedHat 8.x or later. 7.x.noarch.rpm package is designed for RedHat 7.x systems. Main difference between packages - standard package contains standard Apache configuration file with /webmail/ alias in /etc/httpd/conf.dand different package dependencies. There are other SquirrelMail packages created by RedHat, Fedora, SuSE and other RPM distributions.


Debian packages can be downloaded from the Debian website or you can install them with your favorite Debian package manager. For example: apt-get install squirrelmail. If you use Debian stable and SquirrelMail package is a little bit outdated, you might be able to install newer SquirrelMail package from testing or unstable. This is not guaranteed to work though.


FreeBSD includes two different SquirrelMail packages in their ports collection.

Postfix Install

Taken From http://wiki.centos.org/HowTos/postfix



1. Introduction


This article is aimed at beginners who wish to set up a basic email server. Basic system administration knowledge would be an advantage and the ability to install software and edit configuration files is essential. The article was written for CentOS 5 but should be equally applicable to earlier versions. Later versions may differ.


There are many different scenarios and combinations that can be used when setting up an email server (far to many to cover here), so this article makes some basic choices for you, such as the software we will use (postfix and dovecot). Other options are required to be altered by the user, such as your network addresses and domain names. More advanced options such as virtual domains and users are outside the scope of this article and will not be covered herein.


This article uses postfix as the mail transport agent (MTA), as opposed to sendmail, the default MTA for CentOS. Dovecot is used to allow users to access their email by either imap or pop protocols. We assume a domain name of example.com which should be changed by the reader and can be either a real domain name for a fully qualified email server or a fake domain name if you only wish to implement an internal mail server. We assume that the physical mail server (host) is mail.example.com and is located at the private IP address 192.168.0.1 (this should be changed to suit the readers needs). The email server will provide email accounts via standard user system accounts and users will access their email using their system account username and password. We will assume a user called John Smith who has a system account under the login name of john.


2. Installation


The first thing we need to do is install the requisite software. The easiest way to do this is with yum from the command line:


yum install postfix dovecot system-switch-mail system-switch-mail-gnome


Yum should automatically resolve any dependencies. Dovecot is dependent on mysql and perl, so these will likely be installed too if they are not already installed on the system.


3. Configuration


Next we need to configure the various parts of our email server.


3.1. Postfix


Postfix configuration files are stored in /etc/postfix. The two main postfix configuration files are master.cf and main.cf, although we will only be dealing with main.cf here. First we are going to make some additions or changes to the main.cf configuration file. The following lines should be added, edited or uncommented:


myhostname = mail.example.com


mydomain = example.com


myorigin = $mydomain


inet_interfaces = all


mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain


mynetworks = 192.168.0.0/24, 127.0.0.0/8


relay_domains =


home_mailbox = Maildir/


Note: Each line should start at the beginning of a new line and should not be preceded by white space or tabs. White space or tabs at the beginning of a line are treated as a continuation of the previous line, and if the previous line is a comment (#) line then the subsequent line is also treated as such. Further, inline comments should be avoided.


Now lets take a look at each setting it turn to understand what we've just done:


myhostname: is the host name of the system (i.e, the system is called mail or mail.example.com).


mydomain: is the domain name for the email server (it can be a real or fake domain name).


myorigin: is the domain name that locally-posted email appears to have come from and is delivered to.


inet_interfaces: sets the network interfaces that Postfix can receive mail on. These need to include at least localhost and the local domain.


mydestination: is the list of domains that will be delivered to (i.e, this server is the final destination for email addressed to these domains).


mynetworks: is a list of trusted IP addresses that may send or relay mail through the server. Users attempting to send email through the server originating from IP addresses not listed here will be rejected.


relay_domains: is a list of destination domains this system will relay mail to. By setting it to be blank we ensure that our mail server isn't acting as an open relay for untrusted networks. The reader is advised to test that their system isn't acting as an open relay here: http://www.abuse.net/relay.html


home_mailbox: sets the path of the mailbox relative to the users home directory and also specifies the style of mailbox to be used. Postfix supports both Maildir and mbox formats and readers are encouraged to read up on the merits of each for themselves. However, in this article we have chosen to use Maildir format (a trailing slash indicates Maildir format. To specify mbox format, the reader would use home_mailbox = Mailbox).


3.2. Dovecot


The dovecot configuration file is located at /etc/dovecot.conf. The following lines should be added, edited or uncommented:


protocols = imap imaps pop3 pop3s


mail_location = maildir:~/Maildir


pop3_uidl_format = %08Xu%08Xv


# Required on x86_64 kernels


login_process_size = 64


Again, looking at each option:


protocols: specifies the protocols available to users to access their email. Dovecot supports imap(s) and pop3(s), and any or all may be used.


mail_location: specifies the format and location of each users mailbox. Here we see we are using maildir format and each user has their mailbox located at ~/Maildir. Examples for mbox format are provided in the configuration file.


pop3_uidl_format: is required to fix a problem with Outlook 2003 accessing mailboxes via pop3 so it makes sense to set this (see the notes in the configuration file for more details).


login_process_size: The release notes for CentOS 5.1 state that "the Dovecot package on x86_64 kernels requires the parameter "login_process_size = 64" to be added to /etc/dovecot.conf after an upgrade to CentOS 5.1". 32-Bit installations are unaffected and do not require this setting.


Note: If you have any issues connecting with either imap or pop3 to dovecot, check the IMAP specific settings and POP3 specific settings sections of the dovecot.conf configuration file for workarounds. The available options mostly affect older mail clients and workarounds for Microsoft Outlook and Outlook Express.


3.3. Create users mailboxes


Next we need to create a mailbox for each user in their home directory and set the appropriate permission, so using our example user john:


mkdir /home/john/Maildir


chown john:john /home/john/Maildir


chmod -R 700 /home/john/Maildir


Note: If creating the user mailboxes as root then we must set ownership of the directory to the user.


3.4. Aliases


We are nearly finished. We have an email account set up for our user John Smith who logs in as john. His email address would be john@example.com . However, John may like to receive email as jsmith@example.com (or any other alias). We can achieve this by setting an alias for John using the system alias file (by default postfix uses /etc/aliases). We can also add aliases for other users, so for example we could also redirect root's email to John by adding the following to /etc/aliases:


# Person who should get root's mail


root: john


# User aliases


jsmith: john


j.smith: john


If you edit the aliases file to set up new aliases for users once postfix is running, you must rebuild the aliases database by running the newaliases command.


4. Starting the server


We are now ready to fire up our new email server. First we need to tell our system to use postfix as the MTA rather than the default sendmail. To do this, run the system-switch-mailcommand and select postfix as the MTA. This will install the postfix service and set it to start automatically at runlevels 3, 4, and 5. Next we need to set the dovecot service to also automatically start at runlevels 3, 4, and 5, and start both services:


chkconfig --level 345 dovecot on


/etc/init.d/dovecot start


/etc/init.d/postfix start


at which point you should be up and running. Your email server should have no trouble sending and receiving email internally and sending external email. To receive external email on your domain, you will also need to configure MX records in DNS for your domain (ideally a PTR rDNS entry should also be configured through your ISP mapping your IP address to your domain). Don't forget to open any required ports on your Linux firewall depending what services you are running (SMTP 25; POP3 110; IMAP 143; IMAPS 993; POP3S 995) and enable port forwarding for those ports on any routers.


If you make any changes to the postfix configuration file main.cf, you can either restart the postfix service or run the postfix reload command to update the changes.


5. Summary


Postfix is an extremely powerful and versatile mail transport agent. In this article we have seen how to implement a basic email server using postfix and dovecot for a single domain based on system user accounts. We have barely scratched the surface of the true capabilities of a postfix-based system, but hopefully have provided a solid working foundation on which new users can build.


Readers are now encouraged to read the complimentary postfix restrictions guide.


6. Links


Readers are encouraged to read the extensive postfix documentation available at the postfix website including the many example configurations:


http://www.postfix.org/documentation.html


Test for email servers configured as open relays:


http://www.abuse.net/relay.html

Centos Static IP

/etc/sysconfig/network-scripts/ifcfg-eth1

with the following contents

DEVICE=eth1
BOOTPROTO=none
HWADDR="00:27:0E:1E:4B:38"
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
NETMASK=255.252.0.0
IPADDR=10.22.106.2
GATEWAY=10.20.0.254

InfoBlox default Username/Password

username -> admin
password -> infoblox

InfoBlox Lost Password

I have lost the password for my only Superuser account.  How do I reset the 
database without the admin password?

Please note that employing the following instructions will remove ALL data from 
the Infoblox device.  It is our suggestions that, in order to keep from 
resorting to such drastic measures, the default "admin" account be 
reserved only for emergency situations, and that additional Superuser accounts 
are created for the purpose of standard day-to-day administration.  Please make 
sure that the password set for the default “admin” is kept up-to-date with the 
other Superuser accounts.

Connect to the serial console port on the device (not via Remote Console 
or SSH), power cycle the device, after system goes through the initial boot-
up messages, it will display the following message:

"Wait 5 secs for login prompt. Hit "Esc", then "Enter" for 
Emergency prompt."

At this point, during the remaining 5 seconds, hit both the "Esc" key 
and the "Enter/return" key.  You will now be taken to the Emergency 
prompt at which time you can type "reset database" to reset the system. 
After a successful reset from the Emergency prompt, you can "exit" from 
the emergency prompt by entering command "exit" which will take you to 
the regular login prompt. At this point system configurations are completely 
reset to factory defaults and you can login with the default username and 
password.

InfoBlox Replacement

Steps needed to bring a replacement unit on-line in different scenarios: standalone / HA Pair / Grid




For replacing a faulty unit, please follow these steps: Adding IP information to the new appliance --Step 1: Connect a serial console cable (null modem cable) to the replacement appliance --Step 2: Access the replacement appliance (default login credentials are username -> admin; password -> infoblox) --Step 3: Configure it with the IP Address, Subnet mask and the Gateway using the command "set network" --Step 4: When prompted to join the grid, say "n" for no. Depending on the model number of the appliance, you may also enter this data by using the LCD/Front panel. You may also access the appliance by connecting a cross over cable from your workstation to the replacement appliance LAN1 interface. Configure the workstation NIC with any IP address in the network 192.168.1.0/24 except 192.168.1.2 (the default IP of the Infoblox appliance). Now access the GUI using a web browser (https://192.168.1.2). The LAN IP Address, Subnet mask and gateway can be configured from the GUI (GRID perspective- >expand members and select the appliance name->right click and select 'Edit Properties'->configure the settings from the ‘Node Properties tab') --Step 5: Verify if the NIOS version on the replacement appliance and the production Grid are the same. If the replacement unit is a single (non-grid, non-HA) device and you need a specific NIOS version installed, you will need to either upgrade, or downgrade the unit. Please refer to the section ‘Upgrading Software on an Independent Appliance or HA Pair’ in the Administrators Guide accessible from the support site [after logging in with your credentials] or the appliance GUI (help -> download admin guide) for upgrade steps. If you are replacing one node of an HA pair, or the device is part of a grid, the code will automatically syncronize when you connect the replacement to teh HA pair, or grid. Now, depending on your scenario please follow the next steps: Scenario 1: Unit is a standalone device Scenario 2: Unit is a part of independent HA pair Scenario 3: Unit is a part of the HA Grid Master Scenario 4: Unit is a standalone Grid Master with multiple members in the Grid Scenario 5: Unit is a part of HA Grid member Scenario 6: Unit is a standalone member in the Grid Scenario 1: Unit is a standalone device: ---------------------------------------- --Step 6: Take the current database backup from the faulty unit. If the unit is off-line and cannot be powered on, you may take the latest dataset backup downloaded prior to taking the unit off-line. --Step 7: Upload the backup to this replacement unit. While force restoring choose the option to obtain IP address from the backup. --Step 8: Remove the network cables running to the defective unit after powering it down. --Step 9: Connect the network cables removed from the defective unit to the replacement unit For instructions on backup and restore, you may please refer to the section 'Backing Up and Restoring a Configuration File' in our Admin Guide. Scenario 2: Unit is a part of independent HA pair ------------------------------------------------- --Step 6: Login to the HA pair and verify if the faulty unit is the ' Active' unit. If it is the Active unit of the HA pair do a 'forced failover' from the GUI to bring the faulty unit as the Passive unit. You will get disconnected from the GUI when doing a forced failover. Login back and confirm whether all the status indicators for the HA pair are green. --Step 7: Bring down [shutdown] the Passive unit from the HA pair --Step 8: Change the LAN configuration[IP address, Netmask, Gateway, Speed and Duplex settings] of the replacement unit to the same LAN configuration as that of the faulty unit --Step 9: Connect the replacement appliance to the network. Please ensure that the switch ports are configured as recommended by Infoblox in the KB articles 10411, 10270 etc. --Step 10: Join the replacement unit to the Grid using the command 'set membership' from the console or 'join Grid' option from the GUI [Grid perspective -> members -> select the grid master -> view option on the top menu -> select Detailed status]. In either case you will have to provide the IP address of the Grid Master, Grid Name & Shared secret [All of these are case sensitive] After the unit joins back, you will be able to view the status of the unit as 'normal' in the GUI and all the indicators for this unit will turn Green Scenario 3: Unit is a part of the HA Grid Master ------------------------------------------------ --Step 6: Login to the production grid and verify if the faulty unit is the 'Active' unit. If it is the Active unit of the HA pair do a 'forced failover' from the GUI to bring this node as the Passive unit. Before doing a failover make a note of all the units which are not on-line as you will have to verify the status of other members after the failover. You will get disconnected from the GUI when doing a forced failover. Login back and confirm whether all the status indicators for the Grid master and the members are green. If there are members are still communicating with the active grid master ( data sync/NTP sync etc), please wait until all the status indicators turn green. --Step 7: Take the faulty unit which the current Passive node of the grid master off-line from the network. --Step 8: Connect the replacement appliance to the network. Preferably use the same switch ports which were used by the defective appliance. Also please ensure that the switch ports are configured as recommended by Infoblox in the KB articles 10411, 10270 etc. --Step 9: Change the LAN configuration[IP address, Netmask, Gateway, Speed and Duplex settings] of the replacement unit to the same LAN configuration as that of the faulty unit --Step 10: Join the replacement unit to the Grid using the command 'set membership' from the console or 'join Grid' option from the GUI [Grid perspective -> members -> select the grid master -> view option on the top menu -> select Detailed status]. In either case you will have to provide the IP address of the Grid Master, Grid Name & Shared secret [All of these are case sensitive] After the unit joins back, you will be able to view the status of the unit as 'normal' in the GUI and all the indicators for this unit will turn Green Scenario 4: standalone Grid Master with a Grid Master Candidate in the Grid --------------------------------------------------------------------------- --Step 6: Check whether you have a Grid Master Candidate. If there is a Grid Master Candidate, then promote this member as a Grid Master by using the command 'set promote_master'. To get access to the GUI you need to connect to the VIP address of the new Grid Master. --Step 7: Remove the defective Grid Master from the network. --Step 8: Join the replacement unit to the Grid using the command 'set membership' from the console or 'join Grid' option from the GUI [Grid perspective -> members -> select the Grid Master -> view option on the top menu -> select Detailed status]. In either case you will have to provide the IP address of the Grid Master, Grid Name & Shared secret [All of these are case sensitive] --Step 9: If you want to make the replacement unit as the Grid Master again, you may please issue the command 'set promote_master' from the CLI of the Grid Master Candidate. --Step 10: Login to the Grid using the IP address of the new Grid Master and verify if all the members are online and services are up. Scenario 5: Standalone Grid Master with no Grid Master Candidate configured --------------------------------------------------------------------------- 5A) Grid Master is not completely down. --------------------------------------- Method 1: --Step 6: You may connect to the GUI and configure a member as a Grid Master Candidate (refer admin guide to GMC configuration). Ensure that the member being configured as a GMC has the same or better hardware platform than the Grid Master. Making the unit a GMC will force it to drop off the Grid and join back. --Step 7: You may refer to Scenario 4 for promoting the GMC as the Grid Master and replacing the Grid Master --Step 8: If required you may uncheck the option of Grid Master Candidate from the promoted Grid Master after bring it back as the Grid Master Candidate. Method 2: Configure the Grid Master as an HA pair. --Step 6: Join the replacement unit as the Passive of that HA pair. [Please refer admin guide for instructions to form an HA pair]. --Step 7: Once the replacement appliance joins as node 2, do a Forced Failover. This will bring the defective unit as the Passive unit. --Step 8: Now remove the defective appliance from the network. You can remove the HA configuration now. 5B) The Grid Master is completely down. --------------------------------------- In scenarios where you don't have a GMC and the Grid Master failed completely the only option left is to upload the latest backup file to the replacement appliance. --Step 6: Upload a backup to the replacement appliance. Please make sure to select the 'Obtain IP address from backup file' option and not to retain the existing IP address. The replacement appliance should have the same IP address as the grid master. Members will attempt to connect to this IP address. --Step 7: Remove the Grid Master from the network and connect the replacement appliance to the network. --Step 8: Launch the grid manager and verify that all the members are online. Scenario 6: Unit is a part of HA Grid member -------------------------------------------- --Step 6: Login to the production grid and check whether the node[of the member] to be replaced is the Active unit. If it is the Active unit, then do a forced failover (right click the member name -> select Forced failover) to bring this node as the Passive unit. Check the detailed status of this node and confirm that the node to be replaced has become the Passive unit. --Step 7: Remove the Passive unit of the grid member from the network. --Step 8: Change the LAN configuration [IP address, Netmask, Gateway, Speed and Duplex settings] of the replacement unit to the same LAN configuration as that of the faulty unit --Step 9: Connect the replacement appliance to the network. Please ensure that the switch ports are configured as recommended by Infoblox in the KB articles 10411, 10270 etc. --Step 10: Join the replacement unit to the Grid using the command 'set membership' from the console or 'join Grid' option from the GUI [Grid perspective -> members -> select the Grid Master -> view option on the top menu -> select Detailed status]. In either case you will have to provide the IP address of the Grid Master, Grid Name & Shared secret [All of these are case sensitive] After the unit joins back, you will be able to view the status of the unit as 'normal' in the GUI and all the indicators for this unit will turn Green Scenario 7: Unit is a standalone member in the Grid --------------------------------------------------- --Step 6: Remove the defective appliance from the network. --Step 7: Change the LAN configuration [IP address, Netmask, Gateway, Speed and Duplex settings] of the replacement unit to the same LAN configuration as that of the faulty unit. --Step 8: Connect the replacement appliance to the network. --Step 9: Join the replacement unit to the Grid using the command 'set membership' from the console or 'join Grid' option from the GUI [Grid perspective -> members -> select the Grid Master -> view option on the top menu -> select Detailed status]. In either case you will have to provide the IP address of the Grid Master, Grid Name & Shared secret [All of these are case sensitive] After the unit joins back, you will be able to view the status of the unit as 'normal' in the GUI and all the indicators for this unit will turn Green