Monday, April 9, 2012

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

Monday, August 29, 2011

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

Wednesday, August 10, 2011

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


Sunday, May 29, 2011

Load Balancing With A F5 GTM

Understanding load balancing on the Global Traffic Manager

When the Global Traffic Manager receives a name resolution request, the system employs a load balancing mode to determine the best available virtual server. Once the Global Traffic Manager identifies the virtual server, it constructs a DNS answer and sends that answer back to the requesting client's local DNS server. The DNS answer, or resource record, can be either an A record that contains the IP address of the virtual server, or a CNAME record that contains the canonical name for a DNS zone.
Within the Global Traffic Manager, you have two categories of load balancing modes from which to select: static and dynamic. A static load balancing mode selects a virtual server based on a pre-defined pattern. A dynamic load balancing mode selects a virtual server based on current performance metrics.
The Global Traffic Manager provides tiered load balancing system. A tiered load balancing system is a load balancing system that occurs at more than one point during the resolution process. The tiers within the Global Traffic Manager are as follows:
  • Wide IP-level load balancingWide IPs that contain two or more pools use a load balancing mode first to select a pool. Once the Global Traffic Manager selects a pool, the system then uses pool-level load balancing mode to choose a virtual server within the selected pool. If the Global Traffic Manager does not choose a virtual server in the first pool, it applies the load balancing mode to the next pool, either until it selects the best virtual server to respond to the request, or all the pools are tried.
  • Pool-level load balancingA pool contains one or more virtual servers. After the Global Traffic Manager uses wide IP-level load balancing to select the best available pool, it uses a pool-level load balancing to select a virtual server within that pool. If the first virtual server within the pool is unavailable, the Global Traffic Manager selects the next best virtual server based on the load balancing mode assigned to that pool.
For each pool that you manage, the Global Traffic Manager supports three types of load balancing methods: preferred, alternate, and fallback. The preferred load balancing method is the load balancing mode that the system will attempt to use first. If the preferred method fails to provide a valid resource, the system uses the alternate load balancing method. Should the alternate load balancing method also fail to provide a valid resource, the system uses the fallback method.
One of the key differences between the alternate methods and the other two load balancing methods is that only static load balancing modes are available from the alternate load balancing list. This limitation exists because dynamic load balancing modes, by definition, rely on metrics collected from different resources. If the preferred load balancing mode does not return a valid resource, it is highly likely that the Global Traffic Manager was unable to acquire the proper metrics to perform the load balancing operation. By limiting the alternate load balancing options to static methods only, the Global Traffic Manager can better ensure that, should the preferred method prove unsuccessful, the alternate method will return a valid result.

F5 GTM Topologies Load Balancing

Topologies are a way to load balance to a specific pool dependent on were the traffic comes from or is going.


This requires a topology record for the GTM, so that it knows how to handle DNS requests. This is made up of 3 parts. the Request Source, the Destination Source and Weight.




The reuqest source defines where the DNS request came from. the can use 




  • A continent


  • A country (based on the ISO 3166 top-level domain codes)


  • An IP subnet (CIDR definition)


  • An Internet Service Provider (ISP)


  • A custom region


  • The destination defines the resource to which the GTM will direct the DNS request too.

    • A continent
    • A country (based on the ISO 3166 top-level domain codes)
    • A data center
    • An IP subnet (CDIR definition)
    • An Internet Service Provider (ISP)
    • A pool of virtual servers
    • A custom region

      The last element of a topology record, called the topology score or weight, allows the Global Traffic Manager to evaluate the best resolution option for a DNS request. In the event that a name resolution request matches more than one topology record, the Global Traffic Manager uses the record with the highest weight attribute to determine which statement it uses to load balance the request

        To set up a topology record

        1. On the Main tab of the navigation pane, expand Global Traffic and then click Topology.
          The main screen for topologies opens.
        2. Click the Create button.
          The New Record screen opens.
        3. To create a request source statement, use the request resource settings:
          1. Select an origin type from the corresponding list.
          2. Select an operator, either is or is not.
          3. Define the criteria for the request source statement. For example, if the statement focuses on a country, a list appears from which you select the country. If the statement focuses on an IP subnet, a box appears that allows you to define that subnet.
        4. To create a destination statement, use the destination settings:
          1. Select a destination type from the corresponding list.
          2. Select an operator, either is or is not.
          3. Define the criteria for the destination statement. For example, if the statement focuses on a country, a list would appear from which you select the country. If the statement focuses on an IP subnet, a box appears that allows you to define that subnet.
        5. In the Weight box, specify the priority this record has over topology records.
        6. Click the Create button to save the new topology.


        Using topology load balancing in a wide IP

        You can use the Topology load balancing mode to distribute traffic among the pools in a wide IP. To do this, you must have at least two pools configured in the wide IP. With topology load balancing, you send name resolution requests to specific data centers or other resources based on the origin of the request.

        To configure a wide IP to use topology load balancing

        1. On the Main tab of the navigation pane, expand Global Traffic and then click Wide IPs.
          The Wide IPs screen opens.
        2. Click the name of the wide IP for which you want to assign topology-based load balancing.
          The properties screen for the wide IP opens.
        3. On the menu bar, click Pools.
          The pools screen opens. This screen contains a list of the pools currently assigned to the wide IP.
        4. From the Load Balancing Method list, select Topology.
        5. Click the Update button to save your changes.
        Repeat this process for each wide IP as needed.