How to configure Postfix as a relay server

I have a Redmine instance, where email configuration is working fine without "TLS" (encrypted). Requirement is to configure the email emission part with TLS enabled?

 I tried to change the default file of Redmine (/usr/share/redmine/config/configuration.yml) to add the TLS enabled, with our relay server and all. But still the out put is emails without TLS.

Later I analyzed that, in that box, postfix is running and is responsible for making the encryption. Then i configure postix as a relay server to our remote mail server. Following steps helps to solve the issue

postconf -e 'relayhost = smpt.remote_mailserver.com'
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_sasl_security_options ='
echo "smpt.remote_mailserver.com   username@remote_mailserver.com:password" > /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
/etc/init.d/postfix restart

Once I complete the above step, i got TLS enabled mails.
 
If, you need to read a related blog - http://skynetclouds.com/blog/configure-postfix-relay-centos/

Error with first step to install 11g R2 RAC

When i try to install yum install oracle-rdbms-server-11gR2-preinstall  i am getting an error

This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

OS: RedHat 6.5
Solution:
rpm –import http://oss.oracle.com/ol6/RPM-GPG-KEY-oracle
rpm -q gpg-pubkey-ec551f03-4c2d256a
yum install oracle-rdbms-server-11gR2-preinstall

This helps to solve the issue.

What is Puppet, why we need puppet?

10 years back, the job of a System Administrator was a tedious one. He need to spend a lot of time to keep the systems harmonized. He needs to know whats going on each server even-though he was not in his work time. Other main challenge in his/her job was replacing a faulty server or scaling an additional server to the existing infrastructure. System Admins need to know the exact OS, version, softwares, applications, patches, disk size and its partitions etc. They need to first bring a bare metal server, then OS, then necessary services, softwares and application deployments. The entire process will consume a good amount of time.Not only this, a System Admin need to understand the different commands that are using in different Operating Systems. For example, In RHEL we use rpm, in Debian we use dep, in SUSE linux we use yast etc. Other main problems are to roll out a change to all the servers in a data center. Suppose, in my case, my  webserver farm has 15 webservers, running apache on port 80. I need to change the port from 80 to 81. As you all know, we need to login to server and change the listening port from 80 to 81 and then restart the apache. You need to do the same steps in all 15 web servers. Do you think its a duplicate of effort? Yes, it is. These all make the life of a System Admin worse and they can't think of going home early :(

How we can solve these problems?
One method is the "manual way", yes, accepting the facts that, these are my jobs and i need to do it. This method of thinking is good for only limited sets of machines. Can we do this for 100's of servers? BTW, we can think of some auto config scripts or kickstart methods to address these 100's server. Still what you do when it comes to 1000's or lakhs of servers? Wooww... Another issue we need to address here are the following

a) Who push the change?
b) Do we have any history of change?
c) Do we have a audit logs?

Here comes the solution for all these issues. What is Puppet?

• Puppet is a GPL Open Source Project written in Ruby language. 
• It uses a declarative language for expressing system configurations. 
• It's a client server model. We have at least one server and "n" clients can connect to that server.
• Puppet is used for infrastructure automation and configuration management. It helps to define our infrastructure as a line of code. 
• Puppet is build to be for cross platform. We can use linux, unix or windows machines as clients for puppet.
• Puppet client runs at every 30 min by default to check the server for any changes. We can adjust this default time as we like.

Puppet Resource Type -
A Type is a particular element that Puppet knows how to configure. There are so many resource types are available in puppet. The commonly used resource types are the following:

• Files (content, permissions, ownership)
• Packages (ensure installed or absent)
• Services (enabled/disabled, running/stopped)
• Exec (run commands)

Puppet Terminology -
I will try to understand the basic terminology used in Puppet which will help us understand puppet more in deep.

Puppet master - This is our Puppet server which takes care of puppet clients which connect to it. Here the puppet master code runs. This acts as a centralized machine for all your Puppet activity by default.

Puppetmasterd - Running state of Puppet server is called as puppetmasterd

Puppet Agent - Running state of Puppet client software. This software is useful for

1)  Gathering facts: Getting vast system details like OS type, version, RAM details, CPU details and much more using installed facter tool.

2)  Send those details to master for getting required compiled configuration details(catalogs)

3) Getting compiled configuration details from puppet master

4) Executing those compiled configurations at a designated time.

5) Collecting and sending reports of this expected configuration on the client.

Puppet Node - Puppet clients are called as nodes.

Resources - These are files/configs which can be used for changing settings at nodes.

Facter - Reporting tool at nodes, which reports about OS/HW/SW types etc to puppet master about the node where it is installed.

Clipped output of facter command:
swapfree => 13.67 GB
swapsize => 13.67 GB
timezone => PDT
type => Other
uniqueid => c40a660c
uptime => 67 days
virtual => xenhvm

Attribute - Attributes are used to specify the state desired for a given configuration resource. We will see more about this in our coming posts.

Puppet Manifests - A file containing code written in the Puppet DSL language, and named with the .pp file extension. All manifests are stored in /etc/puppet/manifests or /etc/puppet/modules/<name-of-module>/manifests.

Catalogs - Compiled form of manifests.

Puppet Modules - Modules are a bigger form of manifests. Every manifest in a module should define a single class or defined type.

Files - Physical files you can serve out to your agents through puppet. These are stored in /etc/puppet/files or /etc/puppet/modules/<name-of-module>/files.

Templates - Template files contain puppet code with variables which can populate variable values depending on node details.

Classes - Collections of resources

Definitions - Composite collections of resources

If you are interested more, you will get the complete list at http://docs.puppetlabs.com/references/glossary.html.

NFS mount issue on client machine - clnt_create: RPC: Program not registered

Getting the following error
"clnt_create: RPC: Program not registered" on terminal for command showmount

[root@servername ~]# showmount -e 192.168.1.100
clnt_create: RPC: Program not registered


Fix:
Login to the NFS server
Recheck the /etc/export file
/uploads        192.168.0.0/255.255.255.0(rw,async,no_root_squash)
/etc/init.d/nfs stop
/etc/init.d/nfs start


If the service nfs started fine, you need to login to the client and issue the previous command showmount, it should work.