Tag Archives: solaris

User, Group and Password Management on Linux and Solaris

This article will cover the user, group and password management tools available on the Linux and Solaris Operating Systems. The specific versions covered here are CentOS 6.4 and Solaris 11.1, though the commands will transfer to many other distributions without modifications (especially RHEL and its clones), or with slight alterations to command options. Check your system documentation and manual pages for further information.

Knowing how to manage users effectively and securely is a requirement of financial standards such as PCI-DSS, and information security management systems such as ISO 27001.

In this article, I will consider local users and groups - coverage of naming services such as NIS and LDAP is beyond its scope but may be covered in a future article. This article also presumes some prior basic system administration exposure with a UNIX-like operating system.

Continue reading →

Securing the Oracle Solaris 11 Operating System

Solaris 11 is the latest Operating System in the Solaris server OS range from Oracle, previously Sun Microsystems. It incorporates many features from Solaris 10 such as the Service Management Framework, but also pulls a lot from the now defunct OpenSolaris project including a new packaging system and a whole new suite of *adm administrative commands to configure the operating system.

This article will cover security configuration of the OS after a standard text-based installation. I’m using Solaris 11.1 x86_64 running as a VMware Fusion guest, but almost all of the steps will be applicable for the SPARC architecture too.

Continue reading →

How to Fix Perl Make Errors Under Solaris

When you build Perl modules under Solaris, they are optimised for Sun Studio, which of course, we all use :/ So if you build with gcc, the build will likely fail. To avoid this Perl make error, you can use the following magical one-liner to fix this brain damage, and your modules will build correctly.

# pwd
/usr/local/src/cpan/Some-PerlMod-0.123
# find . -name "Makefile" | while read MAKEFILE; do
> sed 's/^CC = cc$/CC = gcc/' ${MAKEFILE} > ${MAKEFILE}.tmp
> sed 's/^LD = cc$/LD = gcc/' ${MAKEFILE}.tmp > ${MAKEFILE}
> sed 's/^CCCDLFLAGS = -KPIC$/CCCDLFLAGS = -fPIC/' ${MAKEFILE} > ${MAKEFILE}.tmp
> sed 's/OPTIMIZE = -xO3 -xspace -xildoff$/OPTIMIZE =/' ${MAKEFILE}.tmp > ${MAKEFILE}
> sed 's/ -xarch=v8//' ${MAKEFILE} > ${MAKEFILE}.tmp && mv ${MAKEFILE}.tmp ${MAKEFILE}
> done

# pwd

/usr/local/src/cpan/Some-PerlMod-0.123

# find . -name "Makefile" | while read MAKEFILE; do

> sed 's/^CC = cc$/CC = gcc/' ${MAKEFILE} > ${MAKEFILE}.tmp

> sed 's/^LD = cc$/LD = gcc/' ${MAKEFILE}.tmp > ${MAKEFILE}

> sed 's/^CCCDLFLAGS = -KPIC$/CCCDLFLAGS = -fPIC/' ${MAKEFILE} > ${MAKEFILE}.tmp

> sed 's/OPTIMIZE = -xO3 -xspace -xildoff$/OPTIMIZE =/' ${MAKEFILE}.tmp > ${MAKEFILE}

> sed 's/ -xarch=v8//' ${MAKEFILE} > ${MAKEFILE}.tmp && mv ${MAKEFILE}.tmp ${MAKEFILE}

> done

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:

# grep '^10\.1\.1\.80' /etc/hosts
10.1.1.80    clusternode1

1 2	# grep '^10\.1\.1\.80' /etc/hosts 10.1.1.80 clusternode1

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:

# netadm list -p ncp -x
TYPE        PROFILE        STATE          AUXILIARY STATE
ncp         Automatic      disabled       disabled by administrator
ncp         DefaultFixed   online         active

# netadm list -p ncp -x

TYPE PROFILE STATE AUXILIARY STATE

ncp Automatic disabled disabled by administrator

ncp DefaultFixed online active

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.

# dladm show-phys
LINK              MEDIA                STATE      SPEED  DUPLEX    DEVICE
net1              Ethernet             unknown    0      unknown   e1000g1
net2              Ethernet             unknown    0      unknown   e1000g2
net3              Ethernet             unknown    0      unknown   e1000g3
net0              Ethernet             up         1000   full      e1000g0

# dladm show-phys

LINK MEDIA STATE SPEED DUPLEX DEVICE

net1 Ethernet unknown 0 unknown e1000g1

net2 Ethernet unknown 0 unknown e1000g2

net3 Ethernet unknown 0 unknown e1000g3

net0 Ethernet up 1000 full e1000g0

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.

# ipadm delete-addr net0/v4
# ipadm delete-addr net0/v6

1 2	# ipadm delete-addr net0/v4 # ipadm delete-addr net0/v6

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

# ipadm create-ip net1

1	# ipadm create-ip net1

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

# ipadm add-ipmp -i net0 -i net1 ipmp0

1	# ipadm add-ipmp -i net0 -i net1 ipmp0

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

# svccfg -s svc:/network/ipmp setprop config/transitive-probing=true
# svccfg -s svc:/network/ipmp listprop config/transitive-probing
config/transitive-probing boolean     true
# svcadm refresh svc:/network/ipmp:default

# svccfg -s svc:/network/ipmp setprop config/transitive-probing=true

# svccfg -s svc:/network/ipmp listprop config/transitive-probing

config/transitive-probing boolean true

# svcadm refresh svc:/network/ipmp:default

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

# ipadm set-ifprop -p standby=on -m ip net1

1	# ipadm set-ifprop -p standby=on -m ip net1

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

# ipadm create-addr -T static -a clusternode1/24 ipmp0/v4
# ipadm show-addr ipmp0
ADDROBJ           TYPE     STATE        ADDR
ipmp0/v4          static   ok           10.1.1.80/24

# ipadm create-addr -T static -a clusternode1/24 ipmp0/v4

# ipadm show-addr ipmp0

ADDROBJ TYPE STATE ADDR

ipmp0/v4 static ok 10.1.1.80/24

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

# route -p delete default 10.1.1.1
# route -p add default 10.1.1.1 -ifp ipmp0
# netstat -rn -f inet
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              10.1.1.1             UG        1          0 ipmp0
10.1.1.0             10.1.1.80            U         8        388 ipmp0
127.0.0.1            127.0.0.1            UH        2        554 lo0

# route -p delete default 10.1.1.1

# route -p add default 10.1.1.1 -ifp ipmp0

# netstat -rn -f inet

Routing Table: IPv4

Destination Gateway Flags Ref Use Interface

-------------------- -------------------- ----- ----- ---------- ---------

default 10.1.1.1 UG 1 0 ipmp0

10.1.1.0 10.1.1.80 U 8 388 ipmp0

127.0.0.1 127.0.0.1 UH 2 554 lo0

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

# ipmpstat -g
GROUP       GROUPNAME   STATE     FDT       INTERFACES
ipmp0       ipmp0       ok        10.00s    net0 (net1)
# ipmpstat -a
ADDRESS                   STATE  GROUP       INBOUND     OUTBOUND
::                        down   ipmp0       --          --
clusternode1              up     ipmp0       net0        net0
# ipmpstat -t
INTERFACE   MODE       TESTADDR            TARGETS
net1        transitive <net1>              <net0>
net0        routes     clusternode1        10.1.1.1

# ipmpstat -g

GROUP GROUPNAME STATE FDT INTERFACES

ipmp0 ipmp0 ok 10.00s net0 (net1)

# ipmpstat -a

ADDRESS STATE GROUP INBOUND OUTBOUND

:: down ipmp0 -- --

clusternode1 up ipmp0 net0 net0

# ipmpstat -t

INTERFACE MODE TESTADDR TARGETS

net1 transitive <net1> <net0>

net0 routes clusternode1 10.1.1.1

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

# ipadm disable-if -t net0
# ipmpstat -t
INTERFACE   MODE       TESTADDR            TARGETS
net1        routes     clusternode1        10.1.1.1

# ipadm disable-if -t net0

# ipmpstat -t

INTERFACE MODE TESTADDR TARGETS

net1 routes clusternode1 10.1.1.1

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

# ipadm enable-if -t net0
# ipmpstat -t
INTERFACE   MODE       TESTADDR            TARGETS
net0        routes     clusternode1        10.1.1.1
net1        transitive <net1>              <net0>

# ipadm enable-if -t net0

# ipmpstat -t

INTERFACE MODE TESTADDR TARGETS

net0 routes clusternode1 10.1.1.1

net1 transitive <net1> <net0>

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.

How to Check md5sum on Solaris 10

If you don’t have the md5sum utility installed, just use the digest tool supplied with Solaris 10

$ digest -a md5 -v /bin/ls
md5 (/bin/ls) = b57e173220af4b919f1d4bef9db11482

1 2	$ digest -a md5 -v /bin/ls md5 (/bin/ls) = b57e173220af4b919f1d4bef9db11482

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

---
:backends:
   - yaml
:yaml:
   :datadir: /etc/puppet/hieradata
:hierarchy:
   - %{::clientcert}
   - %{::operatingsystem}
   - common

---

:backends:

- yaml

:yaml:

:datadir: /etc/puppet/hieradata

:hierarchy:

- %{::clientcert}

- %{::operatingsystem}

- common

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:

[root@centosa hieradata]# cat centosa.local.yaml 
---
security::tcpwrappers::hostsallow: "puppet:///modules/security/etc/hosts.allow-centosa.local"
security::tcpwrappers::hostsdeny: "puppet:///modules/security/etc/hosts.deny-centosa.local"
[root@centosa hieradata]# cat common.yaml 
---
security::tcpwrappers::hostsallow: "puppet:///modules/security/etc/hosts.allow-common"
security::tcpwrappers::hostsdeny: "puppet:///modules/security/etc/hosts.deny-common"
[root@centosa hieradata]# cat Solaris.yaml 
---
security::tcpwrappers::hostsallow: "puppet:///modules/security/etc/hosts.allow-solaris"
security::tcpwrappers::hostsdeny: "puppet:///modules/security/etc/hosts.deny-solaris"

[root@centosa hieradata]# cat centosa.local.yaml

---

security::tcpwrappers::hostsallow: "puppet:///modules/security/etc/hosts.allow-centosa.local"

security::tcpwrappers::hostsdeny: "puppet:///modules/security/etc/hosts.deny-centosa.local"

[root@centosa hieradata]# cat common.yaml

---

security::tcpwrappers::hostsallow: "puppet:///modules/security/etc/hosts.allow-common"

security::tcpwrappers::hostsdeny: "puppet:///modules/security/etc/hosts.deny-common"

[root@centosa hieradata]# cat Solaris.yaml

---

security::tcpwrappers::hostsallow: "puppet:///modules/security/etc/hosts.allow-solaris"

security::tcpwrappers::hostsdeny: "puppet:///modules/security/etc/hosts.deny-solaris"

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.

# class security::tcpwrappers
# Set up tcpwrappers on Solaris and CentOS hosts
class security::tcpwrappers ( $hostsallow = "", $hostsdeny = "" ) {
  file { '/etc/hosts.allow' :
    owner  => 'root',
    group  => 'root',
    mode   => '0644',
    source => $hostsallow
  }
  file { '/etc/hosts.deny' :
    owner  => 'root',
    group  => 'root',
    mode   => '0644',
    source => $hostsdeny
  }
  case $::operatingsystem {
    'CentOS' : {
      # nothing else to do, files are in place
    }
    'Solaris' : {
      # set up inetd-controlled services for tcp_wrappers
      exec { '/usr/sbin/inetadm -M tcp_wrappers=TRUE' :
        unless => '/usr/sbin/inetadm -p | /bin/grep tcp_wrappers=TRUE'
      }
      # enable TCP wrappers for RPC portmapping service
      exec { '/usr/sbin/svccfg -s svc:/network/rpc/bind setprop config/enable_tcpwrappers=true' :
        unless => '/usr/sbin/svccfg -s svc:/network/rpc/bind listprop config/enable_tcpwrappers | /bin/grep true',
        notify => Service['svc:/network/rpc/bind']
      }
      # need the service defined here so we can notify it
      service { 'svc:/network/rpc/bind' :
        ensure => running,
        enable => true
      }
    }
    default : { fail( 'OS unsupported by security::tcp_wrappers class' ) }
  }
}

# class security::tcpwrappers

# Set up tcpwrappers on Solaris and CentOS hosts

class security::tcpwrappers ( $hostsallow = "", $hostsdeny = "" ) {

file { '/etc/hosts.allow' :

owner => 'root',

group => 'root',

mode => '0644',

source => $hostsallow

}

file { '/etc/hosts.deny' :

owner => 'root',

group => 'root',

mode => '0644',

source => $hostsdeny

}

case $::operatingsystem {

'CentOS' : {

# nothing else to do, files are in place

}

'Solaris' : {

# set up inetd-controlled services for tcp_wrappers

exec { '/usr/sbin/inetadm -M tcp_wrappers=TRUE' :

unless => '/usr/sbin/inetadm -p | /bin/grep tcp_wrappers=TRUE'

}

# enable TCP wrappers for RPC portmapping service

exec { '/usr/sbin/svccfg -s svc:/network/rpc/bind setprop config/enable_tcpwrappers=true' :

unless => '/usr/sbin/svccfg -s svc:/network/rpc/bind listprop config/enable_tcpwrappers | /bin/grep true',

notify => Service['svc:/network/rpc/bind']

}

# need the service defined here so we can notify it

service { 'svc:/network/rpc/bind' :

ensure => running,

enable => true

}

default : { fail( 'OS unsupported by security::tcp_wrappers class' ) }

}

How to Network Solaris 11 Zones Under VMware or VirtualBox

Whilst playing around with the changes in zone virtualisation technology between Solaris 10 and Solaris 11, I found that all zones now use exclusive IP, not shared. There is a new anet interface type configured via zonecfg that handles this.

This will all be covered in detail in a future article, but for now take a look at this:

root@sol11lab:~# zoneadm -z testzone boot
root@sol11lab:~# dladm show-link
LINK                CLASS     MTU    STATE    OVER
net0                phys      1500   up       --
testzone/net0       vnic      1500   up       net0

root@sol11lab:~# zoneadm -z testzone boot

root@sol11lab:~# dladm show-link

LINK CLASS MTU STATE OVER

net0 phys 1500 up --

testzone/net0 vnic 1500 up net0

I boot my new testzone, and the vnic is automatically created over net0. But net0 is itself a virtual NIC (i.e. VMware or VirtualBox is virtualising this for us in the first place), whilst Solaris obviously sees it as a physical interface.

Inside the new zone, I was unable to ping anything. The zone was not on the network. The fix? Place net0 into promiscuous mode using snoop inside the global zone. This makes sense when you think about it, and will fix your zone networking allowing you to virtualise within your VM:

# snoop -d net0
# ping testzone
testzone is alive

# snoop -d net0

# ping testzone

testzone is alive

Solaris Cluster 4.1 Part Four: Highly Available Containers

Introduction

The previous article covered the configuration of two resource groups, each containing a failover zpool for use as the zonepath to a highly-available zone, and a failover IP address to be assigned to each zone. The two zones were also configured and installed, and we verified that they could be booted on either node of the cluster, provided that the storage had been failed over appropriately and was available on the node where the zone was being booted.

This final part in the series will cover the incorporation of the zone boot/shutdown/failover into the cluster framework, as well as the configuration of two iPlanet resources to illustrate how Solaris Cluster can manage SMF services deployed within a highly-available Solaris zone.

Highly-Available Zones

First, install the ha-zones data service, if you haven’t done so already. I installed the full cluster package suite, so already have all data services at my disposal:

# pkg install ha-cluster/data-service/ha-zones

1	# pkg install ha-cluster/data-service/ha-zones

# clresourcetype register SUNW.gds

1	# clresourcetype register SUNW.gds

This is the Generic Data Service that is utilised by SUNWsczone (HA for Solaris Containers) for deploying highly-available zones. SUNWsczone supplies three highly-available mechanisms for zone deployment - sczbt (zone boot - used to start/stop/failover zones), sczsh (zone script resource - used for deploying highly-available services within zones, with start/stop scripts to control them) and sczsmf (zone SMF resource, used for deploying highly-available services within zones, with SMF services to control them). We’ll be using both sczbt and sczsmf.

Continue reading →

Solaris Cluster 4.1 Part Three: Cluster Resources

Introduction

In my previous article, we ended up with a working cluster, with all appropriate cluster software installed. In this article, I’ll start to configure cluster resources. I want to configure two resource groups, ha-zone-1-rg and ha-zone-2-rg. Each resource group will contain a highly-available failover filesystem, a highly-available failover IP address and a highly-available Solaris Zone. I’ll illustrate the process for cloning a zone to save on installation time, as zones in Solaris 11 now use IPS and unless you have a local IPS repository, will connect to http://pkg.oracle.com to download all appropriate packages during zone installation - not something you want to repeat too many times.

A summary of the resources/resource groups I’m looking to create is as follows:

ha-zone-1-rg - Resource group for the first set of failover resources
ha-zone-1-hasp - a SUNW.HAStoragePlus resource for the first failover zpool used for the zonepath for the first failover zone, ha-zone-1
ha-zone-1-lh-res - a SUNW.LogicalHostname resource for the first failover zone
ha-zone-1-res - a SUNW.gds resource, coupled with SUNWsczone/sczbt zone boot registration to create a highly-available zone, ha-zone-1
ha-zone-1-http-admin-smf-res - a SUNW.gds resource, coupled with SUNWsczone/sczsmf zone SMF service registration to create a highly-available iPlanet admin server instance
ha-zone-1-http-instance-smf-res - a SUNW.gds resource, coupled with SUNWsczone/sczsmf zone SMF service registration to create a highly-available iPlanet instance
ha-zone-2-rg - Resource group for the second set of failover resources
ha-zone-2-hasp - a SUNW.HAStoragePlus resource for the second failover zpool used for the zonepath for the second failover zone, ha-zone-2
ha-zone-2-lh-res - a SUNW.LogicalHostname resource for the second failover zone
ha-zone-2-res - a SUNW.gds resource, coupled with SUNWsczone/sczbt boot registration to create a highly-available zone, ha-zone-2

This article will cover a lot of ground, much more so than the previous two parts. By the end of the article, you will see two HA resource groups in action, each with a failover zpool and logical hostname resource. I’ll also install the two zones, but won’t make them HA as yet - that’ll be in the next part of the series, as will the configuration of the HA SMF iPlanet resources.

As always, ensure that you read the Oracle Solaris Cluster 4.1 documentation library for full details.

Let’s make a start …

Continue reading →

Toki Winter

Advanced UNIX for the experienced system administrator

Tag Archives: solaris

User, Group and Password Management on Linux and Solaris

Securing the Oracle Solaris 11 Operating System

How to Fix Perl Make Errors Under Solaris

Installing Puppet Client on Solaris 11 with OpenCSW

Configuring Transitive IPMP on Solaris 11

How to Check md5sum on Solaris 10

Puppet Module: security::tcpwrappers with Hiera

How to Network Solaris 11 Zones Under VMware or VirtualBox

Solaris Cluster 4.1 Part Four: Highly Available Containers

Introduction

Highly-Available Zones

Solaris Cluster 4.1 Part Three: Cluster Resources

Introduction