Installing Puppet Client on Solaris 11 with OpenCSW

The easiest way to install on Solaris is to obtain the packages from http://OpenCSW.org. OpenCSW uses a tool called pkgutil on top of the existing Solaris toolset to obtain, install and maintain OpenCSW packages.

Continue reading →

Configuring Transitive IPMP on Solaris 11

We all know the pain of configuring probe-based IPMP under Solaris, with a slew of test addresses being required, and a long line of ifconfig configuration in our /etc/hostname.<interface> files.

With Solaris 11, there is a new type of probe-based IPMP called transitive probing. This new type of probing does not require test addresses, as per the documentation: “Transitive probes are sent by the alternate interfaces in the group to probe the active interface. An alternate interface is an underlying interface that does not actively receive any inbound IP packets”.

In this article, I will configure failover (active/passive) IPMP on clusternode1 (the first node of a Solaris Cluster I’m building). Interface net0 has an address of 10.1.1.80 (configured at install time), and I’ll be adding this into an IPMP group ipmp0 along with a standby interface, net1. Make sure you are performing these steps via a console connection, as the original address associated with net0 will need to be removed before attempting to add it to an IPMP group.

The first step, ensure that there is an entry in /etc/hosts for the IP address you’re configuring IPMP for:

Next, ensure that automatic network configuration is disabled. In my case it was as I’d configured networking manually during the installation of Solaris 11:

Verify that the appropriate physical interfaces are available. In the following output, I’ll be bonding e1000g0 (net0) and e1000g1 (net1) into a failover IPMP group.

List the current addresses - from the output of ipadm show-addr I can see that I’ll need to delete net0/v4 and net0/v6, otherwise I’ll be unable to add net0 to the IPMP group.

As the net0 IP interface is already created, I only need to create the net1 interface:

I can then create the IPMP group, which I’ll call ipmp0:

Next, enable transitive probing, which is disabled by default:

And configure the appropriate interface (in my case net1) to be a standby interface (as I’m using failover):

Now I can create my IPv4 address on the IPMP group:

Finally, fix the default route. I removed the existing route and added a new default route using the new and correct interface - ipmp0:

You can use ipmpstat to verify the configuration and health of the IPMP group:

Let’s perform a failover test. I’ll disable net0 and ensure that the clusternode1 address fails over:

It works! (and my SSH connection is still active…) - net1 is now active with the correct IP address. Let’s fail it back:

The address has failed back to net0, and again my SSH connection is still active. I can now continue with clusternode2, and the rest of the cluster install.

 

Adding Logging to IPTables under CentOS

Whilst troubleshooting some firewall issues with a CentOS host, I wanted to enable logging. Thankfully, there is a very customisable iptables target - LOG (funnily enough) - that will do this in a few steps.

First, add a new chain with a reasonable name. I chose LOGGING:

Next, review the current iptables configuration to ensure that the chain has been created successfully:

Next, insert a rule at the appropriate point (hence me using --line-numbers above). You could replace the existing REJECT at line 7 in its entirety as its functionality will be moved into the LOGGING chain (where I change it to a DROP anyway):

Add the actual logging rule next. I also use the limit module to add some rate-limiting into the mix. The iptables man page documents both the LOG target and the limit module in great detail. But - here I specify a limit of 10 messages per minute, which is ample for my testing. The log level is set at debug (as per standard syslog log levels).

Finally, we actually DROP the packet (whether it has been logged, or not (if the rate limit has been exceeded)):

OK - let’s check our iptables configuration once again:

Everything looks good. Try telnetting to a bad port, or doing something else the firewall should block, and depending upon your syslog configuration, the DROP message should be logged, for example:

If nothing is broken, save your configuration:

As an aside, if (as with the default rsyslog configuration under CentOS 6.x) nothing is logged, you will need to configure rsyslog appropriately. We specified a --log-level of 7 - which is the debug syslog log level. So we need to configure rsyslog to send messages from the kern facility at log level 7 to somewhere useful. I chose /var/log/firewall.log:

As a final tidy up, don’t forget to update your logrotate configuration, if required:

Configuring Interface Bonding on CentOS/RHEL/OEL 6.x

In my previous article I wrote about configuring configuring network interface bonding under Debian Wheezy. Here, I’ll briefly outline the steps required to get the same configuration running under recent RHEL-flavoured distributions - namely CentOS 6.4 in my case.

I will be bonding eth0 and eth1 into a bond named bond0. Ensure that you’re connected to your host via a console. I’ll be using active-backup (i.e. failover) bonding, but there are other options available - see the Debian article for links to reference material for those.

First, create the ifcfg-bond0 configuration file:

Substitute relevant values as appropriate for your setup. Next, edit/create the ifcfg-eth{0,1} files. Note that these are created as slave interfaces (SLAVE=yes) with bond0 as the master interface (MASTER=bond0):

Note - that if NM_CONTROLLED is set, you should strictly define your HWADDR entries too at this step, for each interface. Configure the bonding module. miimon is the MII link monitoring frequency in milliseconds, {down,up}delay are the times, in milliseconds, to wait before disabling or enabling an interface in the bond (to safeguard against flapping), and should be a multiple of the miimon value. Note that /etc/modprobe.conf is deprecated in CentOS 6.x so an appropriate file should be created under /etc/modprobe.d - in our case, bonding.conf:

To test, manually load the module (and appropriate options - I see many tutorials with a simple modprobe bonding here - you’ll end up with the default bonding mode which is round-robin - not what we want):

And restart networking:

Verify that all is well with ifconfig -a, or more suitably a cat on /proc/net/bonding/bond0:

Reboot the host at the earliest opportunity to verify that all is well after a reboot.

 

 

BIND 10: Upgrading from 1.0.0-rc to 1.0.0 - The Production Release

After many years in development, and many releases (development, alpha, beta, release candidate), ISC have announced the final Production release of BIND 10 1.0.0. My previous article covered the upgrade from 1.0.0-beta to 1.0.0-rc. Aside from a database upgrade (which was clearly logged for our attention) the upgrade was very straightforward.

Let’s see if the upgrade from 1.0.0-rc to 1.0.0 is as easy.

Continue reading →

Shells: ksh Tab Completion

If you are using the public domain version of the Korn Shell (pdksh), you can add the following line to your .kshrc and (providing ENV is set), you will have tab completion in vi mode:

You can see which shell options are currently set by running:

Please note, vi-tabcomplete is an option within the public domain Korn Shell only, and will not work with the “standard” ksh provided by many OS’s. In this case, you’ll have to make do with Esc-\ for filename completion.

Securing and Hardening the Linux Operating System

Any application is only as secure as the operating system hosting it. Whilst most servers are protected behind firewalls with the main avenue of exploit being the application, if an application is exploited and the user did manage to obtain server access, we need to minimise the damage that can be done to the exploited machine and others. Running hardened systems is a requirement of certain data security standards such as PCI-DSS (PCI Application Data Security Standard), as well as mandated by many organisations. Plus, it is just good practice. Out-of-the-box, most modern OSes are configured to be secure. There is still a great deal we can do, however, to further harden the operating system to various vectors of attack.

This article will only cover the core aspects of Linux OS lockdown, and will focus on CentOS 6.4. Most of the concepts here should be able to be ported to other flavours, using the appropriate commands for your OS.

For further detail, consult the security benchmarks available at http://cisecurity.org. You should employ multiple layers of security within your architecture – for example, using network-based firewalls as well as host firewalls, writing secure code, ensuring that all aspects of the application stack are patched and up-to-date, etc. Hardening the OS is just one more layer of security.

Continue reading →

BIND 10: How to Upgrade from 1.0.0-beta to 1.0.0-rc

Today, the first RC of BIND 10 was released. There are some new features that will change how you use my previous articles on this subject. Apart from a slew of bug fixes, there are some functionality changes that will affect both the installation and configuration of BIND 10. The BIND 10 Guide has also been updated to reflect these changes.

The major change of note is:

The previous versions of BIND 10 (I was using 1.0.0-beta previously) would have a master process - bind10. This Boss process was responsible for managing the state of other modules, restarting them when they fail, and so on. bind10 is now a shell script that fires up b10-init. This keeps the module names consistent, and we can now address the module as Init. Thus, a Boss shutdown now becomes Init shutdown, Boss show_processlist becomes Init show_processlist, config add /Boss/components b10-auth is now config add /Init/components b10-auth, and so on.

Continue reading →

Puppet Module: security::tcpwrappers with Hiera

Module: security::tcpwrappers

Purpose: This module configures TCP Wrappers on CentOS 6 and Solaris 10 hosts with Hiera.

Notes: This module does some pretty fancy things. It uses Hiera to provide lookup for the $hostsallow and $hostsdeny variables, and interfaces with inetadm and svccfg on Solaris. Let’s look at hiera.yaml first.

File: /etc/puppet/hiera.yaml

As you can see, we first check the %{::clientcert}, then the %{::operatingsystem} before falling back to common. So, essentially you have hostname-specific control if you need it.

Under /etc/puppet/hieradata, I have the following:

Host centosa.local would use centosa.local.yaml (due to %{::clientcert} in the hierarchy) and pull the values in for security::tcpwrappers::hostsallow and security::tcpwrappers::hostsdeny from that file. Host centosb.local would fall through to common.yaml (unless there was a %{::clientcert}.yaml or Centos.yaml), and a Solaris host would use Solaris.yaml.

File: security/manifests/tcpwrappers.pp

Notes: Uses Hiera to copy in appropriate files. On Solaris, it configures inetd-controlled services to use TCP Wrappers via inetadm, and enables TCP Wrappers for the RPC portmapping service via svccfg.