Solaris kernel tuning when upgrading to Solaris 10 Comments Off on Solaris kernel tuning when upgrading to Solaris 10

When migrating to Solaris 10, most people focus on the more obvious changes, such as using SMF to manage services, and ZFS for the filesystems. Something that seems to catch lots by surprise is what happened to kernel turnables in Solaris 10.

In Solaris, the kernel is largely self-tuning, with each new major release and kernel patch building on this. There’s not really that much to tweak, and for most of the time, you can just leave Solaris to get on with it.

There are always edge cases, though. Oracle is a classic one, and if you’re doing HPC, big compute jobs, or lots of I/O intensive work, you’ll want to start tweaking.

In previous releases of Solaris, this involved digging out the correct syntax from the Solaris documentation, working out what the values should be, then editing /etc/system, followed by a reboot.

Oracle DBAs in particular will now be distressed to note that Solaris 10 happily ignores the settings in /etc/system. If you’re lucky, you’ll see some complaints about deprecated settings in /var/adm/messages.

Lots of the defaults have now been changed in Solaris 10, and they’re a lot more sensible – you shouldn’t really need to play with System V IPC tunables like semaphores and message queues.

The Solaris 10 Tunable Parameters Reference Manual can be found at http://download.oracle.com/docs/cd/E19253-01/817-0404/

Things have changed a bit for Oracle databases as well, which is the most common case for kernel tuning most people will encounter. Solaris Resource Controls – aka projects – are now used to set things up for Oracle.

Setting up a project for Oracle, and then defining the kernel settings, is pretty straightforward:

• Setup a new project for the Oracle user:
  

  projadd user.oracle

• Modify the project to increase the number of semaphores:
  

  projmod -s -K “process.max-sem-nsems=VALUE” ‘user.oracle’

  Where VALUE should be the total number of Oracle processes, + 10. Chris Gerhard has an excellent blog entry here that discusses the pros and cons of fiddling with the number of semaphores.

• Modify the project to set the maximum shared memory segment size:
  

  projmod -s -K “project.max-shm-memory=(privileged,VALUE,deny)” ‘user.oracle’

  This corresponds to the old shmsys:shminfo_shmmax kernel tunable in /etc/system.

Once you’ve done that, you’re all set. The old semsys:seminfo_semmns tunable is now deprecated, and you should find that the resource controls that replaced the old tunables semsys:seminfo_semopm and shmsys:msginfo_msgmni have high enough defaults that you won’t need to tweak them.

There are still lots of Solaris 8 and Solaris 9 machines out there, that are only just coming to the end of their service life. Although Solaris 10 has been out for a while, and we’re looking at Solaris 11 being released soon, many clients are still looking to tackle the challenges that a Solaris 10 migration brings.

Capturing core files in Red Hat Enterprise Linux 1 comment

Capturing core files in Solaris is pretty straightforward – even more so if you’ve used JASS to secure the system. By default JASS will give you a nice /etc/coreadm.conf file:

COREADM_GLOB_PATTERN=/var/core/core_%n_%f_%u_%g_%t_%p
COREADM_GLOB_CONTENT=default
COREADM_INIT_PATTERN=core
COREADM_INIT_CONTENT=default
COREADM_GLOB_ENABLED=yes
COREADM_PROC_ENABLED=no
COREADM_GLOB_SETID_ENABLED=yes
COREADM_PROC_SETID_ENABLED=no
COREADM_GLOB_LOG_ENABLED=yes

This ensures that we keep all our core files in a sensible place, and that they have enough information in the filename to identify where they came from.

With some visualisation applications required Linux – more specifically Red Hat Enterprise Linux (RHEL), you’ll find the handy coreadm tool missing. Core file management is instead configured in the kernel configuration file, /etc/sysctl.conf

We’ve got three main challenges in RHEL:

1. enable core dumps from setuid processes
2. remove file size limits for core dumps
3. stick them all in a sensible place, and give the core files sensible names

To accomplish all of this, we need to add the following lines into /etc/sysctl.conf:

fs.suid_dumpable = 2
kernel.core_pattern = /var/corecore_%h_%e_%u_%g_%t_%p

And then to make sure we aren’t imposing limits on our core files, we add the following to /etc/sysconfig/init:

DAEMON_COREFILE_LIMIT='unlimited'	# don't limit our core file sizes

Luckily there’s just a couple of differences between Solaris and Linux when it comes to naming our core files:

Once you’ve updated /etc/sysctl.conf we can just refresh our settings by running sysctl:

[root@altix ~]# /sbin/sysctl -p
< list of kernel tunables >
fs.suid_dumpable = 2
kernel.core_pattern = /var/core/core_%h_%e_%u_%g_%t_%p
< list of kernel tunables >

Solaris 9 branded zones Comments Off on Solaris 9 branded zones

Solaris zones are great for handling all those dev and test environments that seem to breed like cockroaches. The problem recently has been that lots of these environments have been on old sun4u architecture machines (which were cheap), whereas they should be on shiny new sun4v architecture machines (which are great for this sort of work).

Enter branded zones. Unlike a normal zone, which installs from the global zone, a branded zone uses a flar (Solaris flash archive) to install a different Solaris OE. In this case I’m going to go through setting up a Solaris 9 sun4u branded zone on a Solaris 10 sun4v T2000.

First of all, we need to apply a quick kernel patch to Solaris 10. Currently I’ve got:

bash-3.00# cat /etc/release 
                       Solaris 10 8/07 s10s_u4wos_12b SPARC
           Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 16 August 2007

For branded zones for this OE, we need to apply kernel patch 127111-01 at a minimum. Once that’s in place, it’s over to Sun’s website to download the branded zones support files.

There are two different packages – one to support Solaris 8 branded zones, and one for Solaris 9. Head on over to http://www.sun.com/software/solaris/containers/ and download the one you need.

Once you uncompress the TAR file, there’ll be a README, which explains minimum patch levels, and which version of the branded zones package you need to install. For Solaris 9 on the 8/07 release of Solaris 10, I need to install version 1.0 of the Solaris 9 containers.

Installation is pretty simple:

bash-3.00# cd /var/tmp/s9containers-bundle/1.0/Product/
bash-3.00# pkgadd -d `pwd` SUNWs9brandr SUNWs9brandu SUNWs9brandk

pkgadd will go away and do it’s thing – answer ‘yes’ to all the questions, and in a couple of minutes the packages are in place. And that’s it – you’re done! Time to install those branded zones.

Zone configuration is pretty standard, except we need to tell Solaris we’re installing a specific branded zone:

bash-3.00# zonecfg -z test-zone
test-zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test-zone> create -b
zonecfg:test-zone> set brand=solaris9
zonecfg:test-zone> set autoboot=false
zonecfg:test-zone> set zonepath=/export/zones/test-zone
zonecfg:test-zone> add net
zonecfg:test-zone:net> set physical=e1000g1
zonecfg:test-zone:net> set address=192.168.13.251
zonecfg:test-zone:net> end
zonecfg:test-zone> verify
zonecfg:test-zone> info
zonename: test-zone
zonepath: /export/zones/test-zone
brand: solaris9
autoboot: false
bootargs: 
pool: 
limitpriv: 
scheduling-class: 
ip-type: shared
net:
 address: 192.168.13.251
 physical: e1000g1
zonecfg:test-zone> verify
zonecfg:test-zone> commit
zonecfg:test-zone> exit

Note that the only real difference during zone configuration is branding the zone. Normally we wouldn’t specify the brand, and it would default to ‘native’.

Once the zone is configured, we need to install it. As we’re installing a branded zone, we can’t take the Solaris files from the global zone, so we need to use a flar as our boot image.

The process is very straightforward – we just supply the path to the flar as an argument to our zone install command:

bash-3.00# zoneadm -z test-zone install -u -a /mnt/flars/sun4u_sol_9_Generic_118558-11.flar 
      Log File: /var/tmp/test-zone.install.4436.log
        Source: /mnt/flars/sun4u_sol_9_Generic_118558-11.flar
    Installing: This may take several minutes...
Postprocessing: This may take several minutes...

        Result: Installation completed successfully.
      Log File: /export/zones/test-zone/root/var/log/test-zone.install.4436.log

And we’re done. Now just boot the zone and carry out the initial configuration as per normal.

Finally, a quick check to show off our sun4v architecture machine running a Solaris 9 sun4u branded zone:

bash-3.00# uname -m
sun4v
bash-3.00# cat /etc/release 
                       Solaris 10 8/07 s10s_u4wos_12b SPARC
           Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 16 August 2007
bash-3.00# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   5 test-zone        running    /export/zones/test-zone        solaris9 shared
bash-3.00# uname -a
SunOS sunt2k-test 5.10 Generic_127111-01 sun4v sparc SUNW,Sun-Fire-T200

Solaris RBAC configuration 1 comment

RBAC is Roles Based Access Control for Solaris. It’s similar to sudo in that it allows you to let specific users enhance their privileges to run specific tasks.

RBAC has been around in Solaris for a long, long time. It’s matured nicely and is now very accessible and usable – once you get your head round the concepts. It’s very powerful and it’s an under-used framework which really needs to be understood more.

Unlike sudo RBAC can be integrated into NIS or LDAP, and provides a much more comprehensive framework out of the box for doing things.

The basic tasks to setup RBAC are:

1. define a ‘Profile’ in prof_attr
2. tie specific commands to that profile in exec_attr
3. tie specific authorisations to that profile in auth_attr
4. tie the profile to a role, then that role to a user(s) in user_attr
5. or tie the profile directly to a user in user_attr

There are some tradeoffs between using Roles vs. adding Profiles to user:

• Roles require a user to su to another user to execute the command
• when many users need to do the same thing that requires several different Profiles, it’s easier to change the Role once to add more Profiles than to edit many users to add the same extra Profiles to all of them
• easier to track who has access to what by using Roles rather than assigning things direct to users

Personally, when doing more than one thing, I like to define a Role, and then make users su to that Role. It makes management and scalability that much easier, and also more clearly defines who can do what.

It also continues the paradigm of having to su to another user to gain extra privileges. Keeping things working the same as they have done previously is the easiest way to introduce new methods of working, and new technologies, to the users whilst avoiding complaints :-)

In the next few posts I’ll cover some basic RBAC setup, and then adding RBAC configuration to allow a non-privileged user to control Solaris services via SMF.

Tape Devices in Solaris Comments Off on Tape Devices in Solaris

Yes, people out there are still using tape – and in fact in certain situations tape still has many advantages over disk backup or site replication. One of the many quirks with Solaris is how tape devices are addressed, so in this post I’m going to quickly cover the options.

Solaris tape devices all live under /dev/rmt, where rmt stands for Raw Magnetic Tape device.

First tape device name: /dev/rmt/0
Second tape device name: /dev/rmt/1

Each tape device also has special characters added after it to specify density and the characteristics of the drive that you want to use.

So the actual format you’d use to address a drive would be /dev/rmt/XY, where:

• X is tape drive number such as 0, 1 etc.
• Y can be any one of following
  • l – Low density
  • m – Medium density
  • h – High density
  • u – Ultra density
  • c – Compressed density
  • n – No rewinding

It’s actually pretty straightforward. If you want to use tar to backup to your first tape drive, using compressing, and not rewinding the media afterwards (so you can append to the backup), you’d use the device /dev/rmt/0cn

On top of this, Solaris comes with a utility called mt, which is used to carry out some simple tape operations.

mt takes the -f option to specific which device it should talk to, and it then mainly used for these three options:

1. Rewinding a tape

   # mt –f /dev/rmt/0 rewind
   

2. Display the status of a tape drive

   # mt –f /dev/rmt/0 status
   

3. Retensioning a tape

   # mt –f /dev/rmt/0 retension
   

Most people will have some sort of front end software to handle their tape backups – Oracle RMAN, Networker, Netbackup or similar – but if you need to do a quick test, or are just using tar or another backup utility, then this post should point you in the right direction.