UNIX Consulting and Expertise
Golden Apple Enterprises Ltd. » Archive of 'Feb, 2009'

Solaris 9 branded zones Comments Off on Solaris 9 branded zones

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

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

RBAC examples – rebooting a server Comments Off on RBAC examples – rebooting a server

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

So, in a followup to the Solaris RBAC configuration post, I wanted to show how quick and easy it is to configure RBAC. As an example, I’m going to be working with the Solaris reboot command, on the basis that many developers want to reboot their environments, but you don’t always want to give them root.

So, the basic steps are:

  1. define a Profile
  2. assign a command to the Profile
  3. define a Role
  4. assign the Profile to the Role
  5. allow a user to use the Role

Easy stuff. First stage, let’s create the profile. Profiles live in /etc/security/prof_attr, and are a way to group together similar commands. If you look in that file, you’ll see a lot of existing profiles, which tie together common groups of Solaris commands.

Adding a new profile is easy – we just add an extra line to the end of that file:

# echo "Reboot:::Profile to reboot Solaris:help=" >> /etc/security/prof_attr

Breaking it down – the first field is the profile name, and the fourth field is the description. The rest of the fields don’t matter at this stage, for what we’re doing.

The new profile is useless without a command, so let’s add the Solaris reboot command. Commands associated with RBAC profiles live in /etc/security/exec_attr (can you see a pattern in the filenames yet?) and – again – this file is pre-populated with command Solaris commands, grouped by profile.

# echo "Reboot:suser:cmd:::/usr/sbin/reboot:euid=0" >> /etc/security/exec_attr

Breaking the fields down again:

  • first field is the profile name
  • second field is the security policy – in this case, standard superuser
  • third field is the type – in this case, it’s a command
  • sixth field is the full path to the command
  • final field is the effective user ID the command is executed as

So far, it’s all pretty straightforward. Now we have a profile, and we have a command associated with that profile. Now we need to create a role.

RBAC roles are essentially normal user accounts, which have a restricted shell, and associated profile(s). The restricted shell is there to apply all the execution privilege and audit trail RBAC goodness.

Adding a role is nice and easy:

# roleadd -m -d /export/home/reboot reboot
64 blocks

Note the command line options to roleadd are the same as used when adding a normal Solaris user with useradd.

We also need to give the role a password:

# passwd reboot
New Password:
Re-enter new Password:
passwd: password successfully changed for reboot

And now we can see the role has been added to /etc/passwd:

# grep reboot /etc/passwd
reboot:x:1001:1::/export/home/reboot:/bin/pfsh

So it looks almost exactly the same as a normal Solaris user. Now all we need to do is add a profile to the role. We do this with the rolemod command, which – again – is very similar to the normal usermod command:

# rolemod -P Reboot reboot

Details of which profiles are assigned to roles – and which roles are assigned to users – live in /etc/user_attr – so we can look in there to see the changes we’ve made:

# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot

Finally we’ll add the role to our user account:

# usermod -R reboot tomk
UX: usermod: tomk is currently logged in, some changes may not take effect until next login.

And just look in /etc/user_attr to make sure the changes have been made:

# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot
tomk::::type=normal;roles=reboot

We can use the roles command to see what roles we have available to us:

$ roles
reboot

However, logged in as myself I still can’t reboot the machine:

$ /usr/sbin/reboot
reboot: permission denied

And that’s because the profile is assigned to the role, not to my user account:

$ profiles
All
Basic Solaris User

The clue on how to use roles was in how they are created and stored – they’re just like normal users. So to access a role, we su to it:

$ su reboot
Password: 

The moment we su to a role, the whole RBAC audit trail kicks in. Everything, from that initial su onwards, is logged and tracked. Unlike sudo, this logging continues, even if we change shells or become another user (if the role allows us to). It’s this unbreakable audit trail that makes RBAC so powerful.

Now that we’ve assumed a role, we can check out the profiles available to us:

$ profiles
Reboot

So we can now execute the reboot command and bounce the box:

$ /usr/sbin/reboot
Connection to 192.168.13.101 closed by remote host.
Connection to 192.168.13.101 closed.

Have a look at the configuration files and see all of the roles and profiles that come pre-configured with Solaris. Play about with them and get familiar with the terminology. RBAC isn’t difficult or complex – it’s just very different. Get comfortable with it and you’ll soon be able to leverage it’s power to really secure your Solaris machines without denying users any functionality.

What version of the SAN Foundation Suite is installed? 1 comment

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

This is a constant pain that rears it’s ugly head again and again. You have a Solaris machine, the SAN Foundation Suite is installed, and you want to find out what version it is.

Well, you’d do a pkginfo on the SUNWsan package, right? Wrong.

# pkginfo -l SUNWsan
   PKGINST:  SUNWsan
      NAME:  SAN Foundation Kit
  CATEGORY:  system
      ARCH:  sparc
   VERSION:  1.0
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  This package provides a support for the SAN Foundation Kit.
    PSTAMP:  sanserve-a20031029172438
  INSTDATE:  Nov 24 2008 17:46
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed

Every version of SUNWsan reports 1.0. This is unforgivably rubbish – why hasn’t it been sorted yet?

To find out the real version of the SFS, you need to do something far more esoteric – look at the versions of the relevant kernel modules.

If you’ve got SFS 4.3 or later, they will be reported as ‘build dates’:

# modinfo | egrep '(SunFC|mpxio|scsi_vhci)'   
  79  138f975  15f10 149   1  fp (SunFC Port v20051027-1.61)
  80  13a50cd   7fa4   -   1  fctl (SunFC Transport v20051027-1.33)
  82  13ab699  5032a 153   1  qlc (SunFC Qlogic FCA v20050926-1.50)
  113 78196000  20313 150   1  fcp (SunFC FCP v20051027-1.80)
  114 781b8000   55fc   -   1  mpxio (MDI Library v20051027-1.17)
  115 781be000   c8cc 189   1  scsi_vhci (SCSI vHCI Driver v20051027-1.40)
  222 780de000   783f 154   1  fcip (SunFC FCIP v20050824-1.28)

If the version of SFS is earlier than 4.3, then the version is directly referenced for each driver:

# modinfo | egrep '(SunFC|mpxio|scsi_vhci)'   
  85 103199bc  10c23 149   1  fp (SunFC Port v5.e-2-1.18)
  86 1032a0c7   6f28   -   1  fctl (SunFC Transport v5.e-2-1.16)
  87 1032f747  2db28 153   1  qlc (SunFC Qlogic FCA v5.e-2-1.16)
  88 7825a000   fe94 150   1  fcp (SunFC FCP v5.e-2-1.17)
  89 7826a000   49ac   -   1  mpxio (MDI Library v5.e-1-1.7)

If you want to decipher what versions of SFS the build dates map to, you need to look at Sunsolve Document ID 216809. It can be found at http://sunsolve.sun.com/search/document.do?assetkey=1-61-216809-1

You seem to need a Sunsolve login (free) to view the document, and as far as I can tell it’s not restricted to contract customers only. If you find out that’s not the case, please let me know, and I’ll stick a copy up here.

A Rough Guide to LDAP Comments Off on A Rough Guide to LDAP

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

I’ve been working on some Rough Guides – high level overviews to introduce a particular technology or tool. These are not particularly technical or indepth – instead, I want to introduce new technology topics and hopefully you’ll be interested enough to find out more (and start using them yourself).

This is the first in (what I hope will become) a series of them, and provides a high level introduction to LDAP.

Please have a read and let me know what you think in the comments section.

Edit: Quick update to the PDF, please re-download again to get the changes.

A Rough Guide to LDAP

Top of page / Subscribe to new Entries (RSS)