SMF svcadm examples

This post is in complement to the SMF interface post.
Here are a few examples for the svcadm command.

Restarting the system-log (syslog) service.
Assume that /etc/syslog.conf wasn't changed.
In this case there's no need to refresh before restarting.

# ll /var/adm/messages
-rw-r--r--   1 root root 29K Jan 24 15:35 /var/adm/messages

# svcadm restart system-log

# ll /var/adm/messages
-rw-r--r--   1 root root 29K Jan 29 10:24 /var/adm/messages

# tail /var/adm/messages
...
Jan 24 15:35:53 server-1 ... NOTICE: ...
Jan 29 10:24:31 server-1 syslogd: going down on signal 15

The refresh subcommand sometimes (or frequently?) implies a restart.
As a best practice it's a good idea to follow a refresh with a restart.
There's no clear rule about this particular behavior of refresh.
Probably it's to cope with legacies and other constraints.

Here's an example where the refresh subcommand seems enough.

# grep Banner /etc/ssh/sshd_config
# Banner to be printed before authentication starts.
Banner /etc/issue

# svcs -p ssh
STATE       STIME    FMRI
online      10:40:21 svc:/network/ssh:default
            10:40:21    16779 sshd

# svcadm refresh ssh

# svcs -p ssh
STATE       STIME    FMRI
online      10:41:35 svc:/network/ssh:default
            10:41:35    16797 sshd

Examples of the enable and disable subcommands.

# svcs -p apache22
STATE       STIME    FMRI
disabled    Jan_24   svc:/network/http:apache22

# svcadm enable apache22

# svcs -p apache22
STATE       STIME    FMRI
online      11:05:35 svc:/network/http:apache22
            11:05:35    16853 httpd
            11:05:36    16854 httpd
            11:05:36    16855 httpd
            11:05:36    16856 httpd
            11:05:36    16857 httpd
            11:05:36    16858 httpd

# svcadm disable apache22

# svcs -p apache22 
STATE       STIME    FMRI
disabled    11:08:08 svc:/network/http:apache22 

# svcs -l apache22 | grep log 
logfile      /var/svc/log/network-http:apache22.log

# tail /var/svc/log/network-http:apache22.log
[ Dec 10 12:39:36 Disabled. ]
[ Jan 29 11:05:33 Enabled. ]
[ Jan 29 11:05:33 Executing start method 
  ("/lib/svc/method/http-apache22 start"). ]
Apache version is 2.2
[ Jan 29 11:05:35 Method "start" exited with status 0. ]
[ Jan 29 11:08:08 Stopping because service disabled. ]
[ Jan 29 11:08:08 Executing stop method 
  ("/lib/svc/method/http-apache22 stop"). ]
Apache version is 2.2
[ Jan 29 11:08:08 Method "stop" exited with status 0. ]

A mis-configured DHCP service will go into the maintenance state.
After troubleshooting, recover the service with the clear subcommand.

# svcs dhcp/server
STATE       STIME    FMRI
disabled    Jan_24   svc:/network/dhcp/server:ipv4
disabled    Jan_24   svc:/network/dhcp/server:ipv6

# svcadm enable dhcp/server:ipv4

# svcs dhcp/server:ipv4
STATE       STIME    FMRI
maintenance 11:31:15 svc:/network/dhcp/server:ipv4

# vi /etc/inet/dhcpd4.conf

# svcadm clear dhcp/server:ipv4

# svcs dhcp/server:ipv4
STATE       STIME    FMRI
online      11:43:32 svc:/network/dhcp/server:ipv4
 

SMF svcs examples

This post is in complement to the SMF interface post.
Here are a few examples for the svcs command.

Online services ordered by FMRI (Fault Management Resource Identifier):

# svcs | sort -t / -k 2 | tail
online    Jan_24   svc:/system/svc/restarter:default
online    Jan_24   svc:/system/sysevent:default
online    Jan_24   svc:/system/system-log:default
online    Jan_24   svc:/system/timezone:default
...
online    Jan_24   svc:/system/zones-install:default
online    Jan_24   svc:/system/zones-monitoring:default
online    Jan_24   svc:/system/zones:default
  
The state of the ssh service and PIDs for all currently associated processes:

$ svcs -p ssh
STATE     STIME    FMRI
online    Jan_23   svc:/network/ssh:default
          Jan_23        937 sshd

Other services upon which the ssh service depends:
(note that ipfilter is disabled; it's an optional dependency)

$ svcs -d ssh
STATE     STIME    FMRI
disabled  Jan_23   svc:/network/ipfilter:default
online    Jan_23   svc:/network/loopback:default
online    Jan_23   svc:/system/cryptosvc:default
online    Jan_23   svc:/system/utmp:default
online    Jan_23   svc:/network/physical:default
online    Jan_23   svc:/system/filesystem/local:default
online    Jan_23   svc:/system/filesystem/autofs:default

Other services that depend on ssh service:

$ svcs -D ssh
STATE     STIME    FMRI
online    Jan_23   svc:/milestone/self-assembly-complete:default
online    Jan_23   svc:/milestone/multi-user-server:default
 
The ssh service's profile, manifest and log:

$ svcs -l ssh | egrep '(log|manifest)'
logfile      /var/svc/log/network-ssh:default.log
manifest     /etc/svc/profile/generic.xml
manifest     /lib/svc/manifest/network/ssh.xml

$ svcs -n ssh
Notification parameters for FMA Events
 
    Event: problem-diagnosed
        Notification Type: smtp
            Active: true
            reply-to: root@localhost
            to: root@localhost

        Notification Type: snmp
            Active: true

        Notification Type: syslog
            Active: true

    Event: problem-repaired
        Notification Type: snmp
            Active: true

    Event: problem-resolved
        Notification Type: snmp
            Active: true
  
  

SMF interface

The SMF interface is comprised of management and configuration commands.

The management CLI commands are:
  

• svcs
  Prints summary information.
  For instance: state, dependencies, log, notifications and processes.
  Examples.
   
• svcadm
  Manipulates instances.
  Requests actions to the associated service restarter.
  For instance: enable, disable, refresh, restart, clear.
  Examples.

The configuration CLI commands are:
  

• svcprop
  Prints properties values.
  It can take into account the different repository layers.
  Examples.
   
• svccfg
  Manipulates configuration data on the repository.
  It also provides helpers for importing, exporting, validation, and so on.
  Examples.
     

SMF overview

As you probably might know SMF stands for Service Management Facility.
It's an evolution to the now obsolete initialization and termination scripts.
Thus SMF replaces init.d and rc?.d scripts as depicted on init.d(4).
The ? on rc?.d corresponds to the init states as depicted on init(1M).

But SMF is actually more than just an interface for services management:
  

• It's part of FMA (Fault Management Architecture).
  This means it automatically restarts services as possible.
  It can notify via SNMP or SMTP on services' state changes.
   
• It's also a repository of services' properties replacing configuration files.
  This is probably the major impact to system administrators.
   
• Service interdependency documentation.
  This means better management and faster troubleshooting.
   
• Parallel initialization.
  This means the system can start way much faster.

   
After understanding all the advantages of SMF its adoption is quite obvious.
There are excellent how-to articles at Oracle website, such as:

• Introducing the the Basics of SMF
• Advanced Administration with the SMF
• Using svcbundle to Create SMF Manifest and Profiles
• Migrate Control of System Services from Scripts to the SMF

Nevertheless, I'd like to add a few notes and summaries.
I think that my effort can add more help in getting acquainted to SMF.
Here's my SMF post list:

• SMF interface
• SMF service - development

   

Xscreensaver unlock picture

Beyond the security & consent banner, one nice touch for a personal desktop installation is the customization of the Xscreensaver unlock picture. It's a JPEG image, possibly a square around 237 pixels in side.


# cd /usr/lib/xscreensaver/config
# cp -p unlock-logo{,-original}.png
# cp /tmp/unlock-logo-new.jpg .
# cp unlokck-logo{-new.jpg,.png}


NOTE

Yes, weird!
It's a JPEG image with a .PNG extension!

The result is something similar to:

 

Mercurial help

After Mercurial installation one may need to browse some help.
But, above all, it's paramount to read:

• Mercurial: The Definitive Guide (HTML)
• Mercurial: The Definitive Guide (Documentation)

The CLI consists on a long list of hg subcommands: 

# hg -v help
Mercurial Distributed SCM

list of commands:

add:
   add the specified files on the next commit
addremove:
   add all new files, delete all missing files
annotate, blame:
   show changeset information by line for each file
archive:
   create an unversioned archive of a repository revision
backout:
   reverse effect of earlier changeset
bisect:
   subdivision search of changesets
bookmarks:
   track a line of development with movable markers
branch:
   set or show the current branch name
branches:
   list repository named branches
bundle:
   create a changegroup file
cat:
   output the current or given revision of files
clone:
   make a copy of an existing repository
commit, ci:
   commit the specified files or all outstanding changes
copy, cp:
   mark files as copied for the next commit
diff:
   diff repository (or selected files)
export:
   dump the header and diffs for one or more changesets
forget:
   forget the specified files on the next commit
graft:
   copy changes from other branches onto the current branch
grep:
   search for a pattern in specified files and revisions
heads:
   show current repository heads or show branch heads
help:
   show help for a given topic or a help overview
identify, id:
   identify the working copy or specified revision
import, patch:
   import an ordered set of patches
incoming, in:
   show new changesets found in source
init:
   create a new repository in the given directory
locate:
   locate files matching specific patterns
log, history:
   show revision history of entire repository or files
manifest:
   output the current or given revision of the project manifest
merge:
   merge working directory with another revision
outgoing, out:
   show changesets not found in the destination
parents:
   show the parents of the working directory or revision
paths:
   show aliases for remote repositories
phase:
   set or show the current phase name
pull:
   pull changes from the specified source
push:
   push changes to the specified destination
recover:
   roll back an interrupted transaction
remove, rm:
   remove the specified files on the next commit
rename, move, mv:
   rename files; equivalent of copy + remove
resolve:
   redo merges or set/view the merge status of files
revert:
   restore files to their checkout state
rollback:
   roll back the last transaction (dangerous)
root:
   print the root (top) of the current working directory
serve:
   start stand-alone webserver
showconfig, debugconfig:
   show combined config settings from all hgrc files
status, st:
   show changed files in the working directory
summary, sum:
   summarize working directory state
tag:
   add one or more tags for the current or given revision
tags:
   list repository tags
tip:
   show the tip revision
unbundle:
   apply one or more changegroup files
update, up, checkout, co:
   update working directory (or switch revisions)
verify:
   verify the integrity of the repository
version:
   output version and copyright information

additional help topics:

 config        Configuration Files
 dates         Date Formats
 diffs         Diff Formats
 environment   Environment Variables
 extensions    Using Additional Features
 filesets      Specifying File Sets
 glossary      Glossary
 hgignore      Syntax for Mercurial Ignore Files
 hgweb         Configuring hgweb
 merge-tools   Merge Tools
 multirevs     Specifying Multiple Revisions
 patterns      File Name Patterns
 phases        Working with Phases
 revisions     Specifying Single Revisions
 revsets       Specifying Revision Sets
 subrepos      Subrepositories
 templating    Template Usage
 urls          URL Paths

global options:

 -R --repository REPO   repository root directory or 
                        name of overlay bundle file
    --cwd DIR           change working directory
 -y --noninteractive    do not prompt, automatically 
                        pick the first choice for
                        all prompts
 -q --quiet             suppress output
 -v --verbose           enable additional output
    --config CONFIG [+] set/override config option 
                        (use 'section.name=value')
    --debug             enable debugging output
    --debugger          start debugger
    --encoding ENCODE   set the charset encoding 
                        (default: UTF-8)
    --encodingmode MODE set the charset encoding mode 
                        (default: strict)
    --traceback         always print a traceback on exception
    --time              time how long the command takes
    --profile           print command execution profile
    --version           output version information and exit
 -h --help              display help and exit

[+] marked option can be specified multiple times

Of course man pages are available at HG(1).
For instance:

$ man hg

Mercurial Manual                                        HG(1)

NAME
  hg - Mercurial source code management system

SYNOPSIS
  hg command [option]... [argument]...

DESCRIPTION
  The hg command provides a command line 
  interface to the Mercurial system.

COMMAND ELEMENTS
  ...

OPTIONS
  ...
 
In addition there's a quick and cool HTTP option.
All that's required is to create an empty repository and start the server.

# cd /var/tmp
# hg init sample
# hg serve -d -p 8000 -R sample -A /tmp/access -E /tmp/error
  
Assume that the previous commands were given at the mercurial host.
Just point a web browser to http://mercurial:8000/help to get started.

The access log will immediately starting tracking activity.

# cat /tmp/access
192.168.0.100 ... "GET /help HTTP/1.1" 200 -
192.168.0.100 ... "GET /static/mercurial.js HTTP/1.1" 304 -
192.168.0.100 ... "GET /static/style-paper.css HTTP/1.1" 304 -
192.168.0.100 ... "GET /static/hgicon.png HTTP/1.1" 304 -
192.168.0.100 ... "GET /static/hglogo.png HTTP/1.1" 304 -

To stop the web server:
 
# pgrep -f 'hg serve -d -p 8000'
16737
 
# pkill -f 'hg serve -d -p 8000'
  

Mercurial installation

Mercurial is a Revision Control System.
Its CLI isn't installed by default.

$ pkg info -r mercurial
          Name: developer/versioning/mercurial
       Summary: The Mercurial Source Control Management System
   Description: A fast, lightweight source control ...
      Category: Development/Source Code Management
         State: Not installed
     Publisher: solaris
       Version: 2.2.1
 Build Release: 5.11
        Branch: 0.175.1.0.0.24.0
Packaging Date: September  4, 2012 05:17:40 PM
          Size: 713.77 kB
          FMRI: pkg://...
   
Solaris Studio 12.3 comes "half-way" configured for Mercurial.
This is verified by accessing the Tools | Plugins menu.

Any attempt to use the Team menu gives the following diagnostic:

To remedy both issues it's necessary to install the required IPS package.
The installation is rather simple.

# pkg install mercurial
           Packages to install:  2
       Create boot environment: No
Create backup boot environment: No

DOWNLOAD          PKGS         FILES    XFER (MB)   SPEED
Completed          2/2       531/531      2.7/2.7  813k/s

PHASE                                          ITEMS
Installing new actions                       599/599
Updating package state database                 Done
Updating image state                            Done
Creating fast lookup database                   Done 

# hg --version
Mercurial Distributed SCM (version 2.2.1)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2012 Matt Mackall and others
This is free software; ... 
There is NO warranty; ...
  
As an alternative, you may try to "externally" install from the source:
https://www.mercurial-scm.org/downloads

If going to use it under Solaris Studio 12.3, then restart the IDE.
For remote use, install it on both endpoints.  

It may be worthy checking help options as a quick reference.
But Mercurial: The Definitive Guide by Bryan O'Sullivan is the book:

• Mercurial: The Definitive Guide (HTML)
• Mercurial: The Definitive Guide (Documentation)

I've also found a few introductory videos by Brian Will quite worthwhile:

• Version Control with Mercurial (part 1 of 5)
• Version Control with Mercurial (part 2 of 5)
• Version Control with Mercurial (part 3 of 5)
• Version Control with Mercurial (part 4 of 5)
• Version Control with Mercurial (part 5 of 5)

  
I would also recommend the following:

• Understanding Mercurial   
• A Tutorial on Using Mercurial   

     

Revision Control System

A Revision Control System (RCS) is at a premium.
Information and complexity are ever growing problems.
A single person can generate and use tons of information a day.
The need to manage changes is absolutely intrinsic to evolution.
Fortunately, there are tools to help with the challenge.

The two most traditional and famous tools are:

• CVS (Concurrent Versions System)
• SVN (Subversion)

 
There are others as well, such as:

• Mercurial
• ClearCase
• Team Foundation
• Git
• Fossil 

   
Fortunately, both Solaris 11 and Oracle Solaris Studio support Mercurial.
Actually, they support the more traditional CVS and SVN too.
I have started with Mercurial by listening to others' experience.
Then I've managed to learn a little more from a main reference:

Mercurial: The Definitive Guide
By Bryan O'Sullivan

Version Control with Mercurial
By Brian Will

• (part 1 of 5)
• (part 2 of 5)
• (part 3 of 5)
• (part 4 of 5)
• (part 5 of 5)

Most think that a Revision Control System (RCS) is just developers.
System administrators usually don't take it to their own advantage.
Traditionally, this results on a nightmare of multiple copies of a file.
Even with a strict change management discipline errors can happen.
ZFS snapshots certainly help, but they aren't fine grained enough.
Perhaps one difficulty is the burden to cope with such a tool.
But the great news is that Mercurial is quite simple and effective.

A Revision Control System (RCS) is also know as a:

• Source/Software Configuration/Control Management (SCM)
• Version Control System (VCS)

  

X11 & SSH & SU

The problem of getting a remote GUI on X11 isn't new.
Traditionally people used a combination of $DISPLAY and xhosts.
The main issue is the lack of security which is paramount nowadays.
Then there is a solution with the -X SSH option, which is great.

But what if the remote X11 GUI needed is to be associate with a different account then the one used to establish the SSH connection? The need is rather common with RBAC, where it's frequent to switch to a role for some temporary privilege elevation. It's also rather common when needing to switch to the root account (su -).

Here's one symptom of the difficulty:

adm1@laptop-1$ xauth list
laptop-1/unix:0  MIT-MAGIC-COOKIE-1  17d8871999...

adm1@laptop-1$ echo $DISPLAY
:0.0
 
adm1@laptop-1$ ssh -X desktop-1
Password: ****************
Last login: Thu Jan  9 09:39:03 2014 from 192.168.0.100
Oracle Corporation      SunOS 5.11      11.1    November 2013

adm1@desktop-1:~$ xauth list
desktop-1/unix:11  MIT-MAGIC-COOKIE-1  7436b5eca2... 
 
adm1@desktop-1:~$ echo $DISPLAY
localhost:11.0 
  
adm1@desktop-1:~$ su -
Password: **************** 
  
root@desktop-1:~# nautilus &
[1] 3009

root@desktop-1:~#
(nautilus:3009): Gtk-WARNING **: cannot open display:

[1]+  Exit 1                  nautilus


The solution is to manually set the X11 cookie and $DISPLAY after su.
Right after connecting via ssh -X, take note of the above values.
Then switch user accordingly.

...

adm1@desktop-1:~$ su -
Password: ****************


Manually set the X11 cookie:

root@desktop-1:~# xauth add 
    desktop-1/unix:11  MIT-MAGIC-COOKIE-1  7436b5eca2...
xauth:  file /root/.Xauthority does not exist

root@desktop-1:~$ xauth list
desktop-1/unix:11  MIT-MAGIC-COOKIE-1  7436b5eca2...


Manually set $DISPLAY:

root@desktop-1:~# export DISPLAY=localhost:11.0

root@desktop-1:~# echo $DISPLAY
localhost:11.0


Invoke the GUI application:

root@desktop-1:~# nautilus > /dev/null 2>&1 &
[1] 3025

Use GUI as needed...

root@desktop-1:~#
[1]+  Done               nautilus > /dev/null 2>&1


Right before disconnecting, clean up the X11 cookie:

root@desktop-1:~# xauth remove desktop-1/unix:11

root@desktop-1:~# xauth list

root@desktop-1:~#
^D

adm1@desktop-1:~$
^D

adm1@laptop-1:~$
  

SSH login-time initializations

Beyond being secure, SSH is feature rich.
It seems that many features are generally overseen.
One quite useful feature is the login-time initializations capability.
One obvious application is to help in tracking SSH logins.
But many other useful actions can be performed.

The details are described at ssh(1) and sshd(1M) man pages.
Even so, I'd like to provide a summary on them on this post.

A fluxogram of the sshd daemon search sequence of each login-time initialization file shall provide a good introductory overview of the feature:

If the $HOME/.ssh/environment exists, it's the first to be read.
The PermitUserEnvironment in /etc/ssh/sshd_config must be set.
Obviously, the file ownership should be set according to the user account.
Its permission should be 600 and contents should be a combination of:

• Empty lines.
• Comments lines (started with #).
• Assignments (name=value)

  
NOTE

The usage of $HOME/.ssh/environment is discouraged.
It may open security breaches as described in sshd_config(4).

Next, if the $HOME/.ssh/rc exists, then it's run with /bin/sh.
Its permission should be 600 and under ownership of the user.
According to sshd(1M) its contents should end with:

    if read proto cookie && [ -n "$DISPLAY" ]
    then
        if [ `echo $DISPLAY | cut -c1-10`  =  'localhost:' ]
        then
            # X11UseLocalhost=yes
            echo add unix:`echo $DISPLAY |
            cut -c11-` $proto $cookie
        else
            # X11UseLocalhost=no
            echo add $DISPLAY $proto $cookie
        fi | xauth -q -
    fi

If the $HOME/.ssh/rc is not found, then /etc/ssh/sshrc is run, if present.
According to sshd(1M) its contents should also end as in  $HOME/.ssh/rc.
The file ownership should be set to the root account.
Its permission should be 644.

That is, if any of $HOME/.ssh/rc or /etc/ssh/sshrc exist, then running xauth is necessary whenever X11 is involved. Of course, this is to add the X11 cookies accordingly.

Finally, if none of the login-time initialization files are found, xauth is run.
 
NOTE

It's critical to not toss out anything to the standard output.
Not observing this is a common source transfer failures with with scp.
For instance, an echo command on .bashrc will break an scp operation.

It's typically a good idea to detect right from the start whether or not the script is running under an interactive session or not. According to tty(1) final NOTES the most portable way of doing that is:

# test for stdin file descriptor
test -t 0 

if [ $? -eq 0 ]
then
    # interactive
    ;
else
    # non-interactive
    ;
fi

An alternative would be to suffix any eventual output to stdout by means of redirection such as 1>&2. But even this may still adversly provoke undesired and unexpected side-effects.
 
If one is running BASH, variations of the previous test could be:
 
if [[ -t 0 ]]; then ...; else ...; fi

if [[ $- =~ i ]]; then ...; else ...; fi

   

DNS server installation

DNS server installation in itself is a rather ordinary sysadmin task.
Nevertheless a simple but important measures are frequently disregarded.
The problem is that these oversights or omissions leads to security issues.
As a consequence, everything that relies on DNS is affected as well.
As such, it's not difficult to see that impacts can be disastrous.

As a good practice:

Start right from the very beginning.
As the British say: Don't make a rod for your own back.

So here's a few important measures to running a DNS server:

• Keep the software as up-to-date as possible;
• Consider a robust networking scheme, such as IPMP or DLMP;
• Run the daemon on an immutable non-global zone (NGZ);
• Run the daemon under a non-root user account;
• Countermeasure MAC-spoof and IP-spoof;
• Consider IPsec where feasible.

Assume a NGZ, not yet (of course) immutable.
Suppose the following interface configuration is present:

dns-1# dladm show-link
LINK    CLASS     MTU     STATE   OVER
net7    phys      1500    up      --
 
dns-1# dladm show-phys
LINK    MEDIA     STATE   SPEED   DUPLEX  DEVICE
net7    Ethernet  up      1000    full    e1000g11

dns-1# dladm show-phys -m
LINK    SLOT      ADDRESS         INUSE   CLIENT
net7    primary   8:0:27:ad:65:e  yes     net7

dns-1# dladm show-linkprop -p allowed-ips,protection
LINK  PROPERTY     PERM  VALUE         DEFAULT  POSSIBLE
net7  allowed-ips  rw    192.168.0.17  --       --
net7  protection   rw    ip-nospoof    --       mac-nospoof,
                                                restricted,
                                                ip-nospoof,
                                                dhcp-nospoof
NOTE

For the examples I'm using VirtualBox 4.3.6 on a Solaris 11 host.
On the host, there are several vnics over a single etherstub.
Such vnics are being provided to VirtualBox guests.
Guests' non-global zones can't use the anet resource.
The only choice in this particulare case is the net resource.
In this scenario it seems impossible to set the mac-nospoof.
On a real world scenario anet resources would fill the gap.

  
Check for a reasonably up-to-date software.
If available, update the IPS repository to the latest SRU.

# pkg info -r service/network/dns/bind | egrep '(State|Ver)'
         State: Not installed
       Version: 9.6.3.8.0 (9.6-ESV-R8)
 
Check the respective ISC-BIND resources on the Internet:

• BIND Software Support Policy
• BIND Significant Features Matrix
• BIND 9 Vulnerabilities Matrix

For instance, for BIND 9.6-ESV-R8 there exists vulnerability #56.

56

2013-6320

A Winsock API Bug can cause a side-effect affecting BIND ACLs

After assessing all the information, the conclusion is that it's safe to proceed as the environment is comprised only of Unix hosts which aren't affected.

# pkg install -nv service/network/dns/bind
           Packages to install:        1
     Estimated space available: 13.98 GB
Estimated space to be consumed: 19.20 MB
       Create boot environment:       No 
Create backup boot environment:       No
            Services to change:        1
          Rebuild boot archive:       No

Changed packages:
solaris
  service/network/dns/bind
    None -> 9.6.3.8.0,...
Services:
  restart_fmri:
    svc:/system/manifest-import:default

# svcs '*dns*'
STATE          STIME    FMRI
disabled       14:01:15 svc:/network/dns/client:default
disabled       14:01:18 svc:/network/dns/multicast:default

# pkg install service/network/dns/bind
           Packages to install:  1
       Create boot environment: No
Create backup boot environment: No
            Services to change:  1

DOWNLOAD          PKGS        FILES    XFER (MB)   SPEED
Completed          1/1        14/14      0.4/0.4  778k/s

PHASE                                        ITEMS
Installing new actions                       44/44
Updating package state database               Done
Updating image state                          Done
Creating fast lookup database                 Done
  
# pkg info service/network/dns/bind | egrep '(State|Ver)'        
         State: Installed
       Version: 9.6.3.8.0 (9.6-ESV-R8)

# svcs '*dns*'
STATE          STIME    FMRI
disabled       14:01:15 svc:/network/dns/client:default
disabled       14:01:18 svc:/network/dns/multicast:default
disabled       15:04:12 svc:/network/dns/server:default

 
The next step is to perform the DNS server configuration.
 

DNS services

DNS (Domain Name System) is a hierarchical and distributed database for hosts name and addresses relationships as well as hosts related information such as: mail exchange routing, location data and available services.

Due to its characteristics, DNS is vital.
Any kind of Internet presence or access requires it.
Many other infrastructure services take advantage of it.
It doesn't replace NIS, but supersedes the hosts map.

NIS has a known DNS-forwarding mode (see nsswitch.conf(4)) where it forwards host names and addresses lookup requests to DNS if it doesn't have the information on its own databases.  This possible integration, together with the further variations on the hosts database source list of the Name Services Switch, can lead to unexpected resolutions and subtle issues. Hence, except for specific cases, it may indeed be better to adopt the following host database source list:

hosts: files dns nis

Nowadays we also have the alternative of multicast DNS and the now reserved .local pseudo-TLD name is used for it. The on-line documentation also talks about it as well as man pages mdnsd(1M) and dns-sd(1M). It has to do with the zero-configuration networking and Apples's Bonjour implementation whose open source framework and tools is present in Solaris. But being restricted to local area networks, at least for now, I won't enable it. One notable exception is when setting up the Automated Installer Framework, which requires enabling it.

# svcs dns/multicast
STATE          STIME    FMRI
disabled       Jan_07   svc:/network/dns/multicast:default

These DNS series of blog posts will primarily cover traditional DNS, a.k.a. unicast DNS. I do not yet know how deep I'll go with my descriptions and examples, but I intend to visit the basics alongside benefits and advantages of implementing it under Solaris.

So these are the main posts:

• DNS client configuration
• DNS server installation
• DNS server configuration

For further detail I'd point to:
 

• Managing DNS (Tasks)
• DNS & BIND - O'Reilly
• InterNIC FAQs

     

Global zone L2 & L3 protection

L2 (layer 2) and L3 (layer 3) refers respectively to MAC and IP addresses.
This is all similar to non-global zones (NGZ) L2 & L3 protection.

By default we have no protection setting for the global zone (GZ).
Note that ip-nospoof also requires setting the allowed-ips property.

$ dladm show-linkprop -p allowed-ips,protection net0
LINK  PROPERTY     PERM VALUE          DEFAULT  POSSIBLE 
net0  allowed-ips  rw   --             --       --  
net0  protection   rw   --             --       mac-nospoof,
                                                restricted,
                                                ip-nospoof,
                                                dhcp-nospoof

In general both should be set to improve security.

# dladm set-linkprop -p allowed-ips=192.168.0.100 net0
# dladm set-linkprop -p protection=mac-nospoof,ip-nospoof net0

$ dladm show-linkprop -p allowed-ips,protection net0
LINK  PROPERTY     PERM VALUE          DEFAULT  POSSIBLE
net0  allowed-ips  rw   192.168.0.100  --       -- 
net0  protection   rw   mac-nospoof,   --       mac-nospoof,
                        ip-nospoof              restricted,
                                                ip-nospoof,
                                                dhcp-nospoof
   

Zones L2 & L3 protection

L2 (layer 2) and L3 (layer 3) refers respectively to MAC and IP addresses.
Zones are particularly attractive in securing those two networking entities.
This is because zones are fundamental to the IaaS cloud service model.
This assures zones will never be a vector for common L2/L3 attacks.

Zones can use two different kind of protected networking resources:

net
Refers to either a physical NIC or a predefined virtual NIC (vnic).
The protection is given by the allowed-address and the configure-allowed-address parameters. This will automatically set ip-nospoof  for the underlying link, but currently it will make it impossible to set the mac-nospoof (sort of bug or limitation).

anet
Automatically creates a vnic according to parameters.
Naturally, the underlying link (lower-link) can't be another vnic.
The protection is given by the link-protection parameter, but
its setting is somewhat automatic along the setting of allowed-address and the configure-allowed-address parameters. I say somewhat because they set the ip-nospoof.  But it may be good to add the mac-nospoof.

Hence, at a minimum, no matter if net or anet is used, what's important is to set the allowed-address and configure-allowed-address parameters. But if using anet, then also set the link-protection to mac-nospoof.
 
For instance:

# zonecfg -z server-1b info net
net:
    address not specified
    allowed-address: 192.168.0.12/24
    configure-allowed-address: true
    physical: net2
    defrouter not specified

But the protection technology isn't restricted to non-global zones (NGZ).
In fact, this networking protection technology is totally independent.
As such they can be used in global zones (GZ) as well.
    

Immutable zones

The advent of immutable zones is a great improvement to Solaris.
Now it's possible to set portions of the root file system as read-only.

The improvement is two-folded:

Security

If the zone virtual environment somehow gets compromised, then the read-only root file system will be a tough barrier helping to limit the exposed surface.

For instance, a DNS service running on a dedicated immutable zone doesn't require the associated SMF service tunning in order to run the service under a non-root account.

Management

This is easier to understand. Once perfectly set up, it's assured that the configuration won't be changed by accident or even by tampering. It's known that a many problems arise from a poor change management. Now the operating system supports and enforces the expected behavior. Great!

There are 3 degrees of protection:

Complete
This is given by the zone property file-mac-profile=strict.
Nothing can be changed and data can only be logged remotely.

Fixed
This is given by file-mac-profile=fixed-configuration.
Logging can be local and portions of /var are writable.
For instance, NIS services seem to work fine.

Flexible
This is given by file-mac-profile=flexible-configuration.
This differs from Fixed by allowing a writable /etc.

To check if a zone is configured as immutable:

# zonecfg -z server-1b info file-mac-profile
file-mac-profile: fixed-configuration 

To check if a zone is running as immutable:

# zoneadm list -p | grep server-1b | cut -d: -f8,9
R:fixed-configuration

NOTE

Immutable zones doesn't protect non-root file systems.
Thus other forms of protection and recover must be devised.

NOTE

To manage an immutable zone, it's necessary to temporarily remove the immutability / read-only enforcements:
 
# zoneadm -z <zonename> boot -w
  
If the zone is already running immutable you don't need to halt or shutdown and then perform the above command; simply use:

# zoneadm -z <zonename> reboot -w

On the last case (a reboot for management) the message [NOTICE: Read-only zone rebooting read-write] will follow on the zone's console.

After the management, to reenter the immutable state simply use init 6 or shutdown -r for an ordered shutdown as usual.