SUNWjet: Add a slice 7 to a zpool’s disk

According to Oracle's documentation, if you want to use SUNWjet to jumpstart a server with a ZFS Root pool and a slice 7 to put metadb on, you must first parition your drives and then launch the jumpstart.

This is particularly annoying as two operations are required.

I've found this post while searching on Google to see if it was possible to create a slice 7 automatically during the jumpstart. Unfortunately, it didn't worked as:

  • Disks were hardcoded
  • Line 321 seemed to be architecture dependant (i86pc)

As I wanted to add this permanently and as every server I jumpstart can possibly one day use either UFS/DiskSuite or metaset, I wanted to have a slice 7 on every server in case of future use.

I wrote then this little patch to adapt the "populate_client_dir" script to add a slice 7 of 100Mb on every disk specified to be used as root pool:

So, to apply the patch, simply run:

 cd /opt/SUNWjet/Utils/solaris
patch -p0 < /tmp/solaris-populate_client_dir.patch

Then, run the make_client script against your template, where you would have specified the zpool spec:

base_config_profile_zfs_disk="c0t0d0s0 c1t0d0s0"

Solaris 11 ISC DHCP: Cannot specify multiple interfaces

While trying to configure the ISC DHCP server on Solaris 11 to serve my local VLANs, I wanted to restrict its usage to only three interfaces, I then issued the following setprop command:

# svccfg -s svc:/network/dhcp/server:ipv4 config/listen_ifnames astring\: "vlan100 vlan201 vlan202"
# svcadm refresh -s svc:/network/dhcp/server:ipv4
# svcadm enable svc:/network/dhcp/server:ipv4

But the service was failing to start... after adding some debug echo's to the /lib/svc/method/isc-dhcp file, I saw that the whitespaces of this property get escaped when retrieved from the method's script:

# tail -3 /var/svc/log/network-dhcp-server:ipv4.log
[ Jul 10 13:44:02 Executing start method ("/lib/svc/method/isc-dhcp"). ]
IFACES: vlan100\ vlan201\ vlan202
[ Jul 10 13:44:02 Method "start" exited with status 95. ]
# ggrep -B 4 IFACES /lib/svc/method/isc-dhcp
get_dhcpd_options() {
# get listen_ifname property value.
LISTENIFNAMES="`get_prop listen_ifnames`"
# /usr/lib/inet/dhcpd -f -d -4 --no-pid  -cf /etc/inet/dhcpd4.conf -lf /var/db/isc-dhcp/dhcpd4.leases vlan100\ vlan201\ vlan202
vlan100 vlan201 vlan202: interface name too long (is 23)
# /usr/lib/inet/dhcpd -f -d -4 --no-pid  -cf /etc/inet/dhcpd4.conf -lf /var/db/isc-dhcp/dhcpd4.leases vlan100 vlan201 vlan202
Internet Systems Consortium DHCP Server 4.1-ESV-R4

So, to fix this behaviour, edit the /lib/svc/method/isc-dhcp, line 66 should be changed:

LISTENIFNAMES="`get_prop listen_ifnames`"


LISTENIFNAMES="`get_prop listen_ifnames|sed -e 's/,/ /g'`"

Then, you can set the listen_ifnames properties with multiple interfaces separated by commas:

# svccfg -s svc:/network/dhcp/server:ipv4
svc:/network/dhcp/server:ipv4> setprop config/listen_ifnames = astring: "vlan100,vlan201,vlan202"
svc:/network/dhcp/server:ipv4> exit
# svcadm refresh svc:/network/dhcp/server:ipv4
# svcadm disable svc:/network/dhcp/server:ipv4
# svcadm enable svc:/network/dhcp/server:ipv4

WeSunSolve: One year later

More than one year ago, the WeSunSolve website has been launched publicly to address the lack of information available for the Solaris operating system.

Facing it's success, a lot of improvements, features and stuff were added.. and visitors keeps like it!

Here are some statistics about this past year on the website:


  • 307191 Unique Visits
  • 657270 Page viewed
  • 64% Bouncing Visits
  • 670 Registered Users


  • 1. United States
  • 2. United Kingdom
  • 3. Germany
  • 4. Japan
  • 5. France


  • Number of patches registered: 75928
  • Number of readmes version gathered: 63579
  • Number of checksums registered: 59471
  • Number of BugIDs registered: 365191
  • Total size of the patches repository: 623.57 GBytes
  • Number of Files detected: 1323021
  • Number of Packages: 8639
  • Number of CVE: 438

I would like to thank all the people who have made bugs reports, features requests and comments as well as the ones who have simply put their thumbs up!

If you like WeSunSolve, please spread the word! Talk 'bout it with your colleagues and share your experiences! If you're achieving a recurrent task using WeSunSolve, why not writing a little Howto?

You're part of a team of Solaris sysadmin? Did you know that you can know work in collaboration with your colleague on WeSunSolve? Check the documentation for more information ;-)

Last but not least, do not hesitate to send me your thoughts on the website! It's always good to hear from people who are using your work :) Especially when it's free ;-)

WeSunSolve: Site News April

New Features

  • Added wiki to hold the documentation;
  • Added the monitoring of multiple IPS Repositories;
  • User list now allows the user to load multiple patches at once;
  • Added patch timeline
  • Added CVE list affecting Solaris packages
  • Added patch link to CVE when issue is fixed
  • Users can now download a ZIP containing all README of user patch list
  • SSL Signed certificate added to https domain
  • User login goes over SSL by default
  • Added support for SRV4 Packages link to patches
  • Modified the structure of patch level to link SRV4 packages
  • Added user setting for API access
  • Added function to API to allow server registration and adding a patch level
  • Added patch/security report based on patch level and PCA execution
  • Added mail report for patch/security based on a patch level and patchdiag.xref automatic selection
  • We added a logo to our Wiki! (thanks to Dagobert Michelsen for the logo ;-)

Full listing of changes made can be found here

Patch level report (Using PCA)

PCA has been integrated into WeSunSolve so you can generate patch report on any server registered into your account where at least one patch level is defined.
The report which is created by WeSunSolve is based on the information you are entering when adding a server's patch level: showrev-p.out and pkginfo-l.out.
Theses two files are generated while running the Explorer or simply gathered by hand with the two corresponding commands. (respectively: /usr/bin/showrev -p and /usr/bin/pkginfo -l).

You can see there a full example of such generated report.
To generate a report like this, you must Add a server and an associated patch level, you can achieve this by following steps pointed in the documentation.

Please, give us feedback if you feel something is missing inside this report!

Mail reports

You can also get the previous report being sent to you by mail regularly, everything can be configured to fit your needs... You can:

  • Choose the server and the patch level on which the report will be generated;
  • Choose the interval between two reports being sent to you: every day, every week, every month ?
  • You can decide which patchdiag.xref delay you want to have, this is the best if you always want to have a delay between what's out and what you will actually install.

This way, you can get a report of what patches are to be installed on your server based on an up-to-date baseline every day...

To create a report, simply follow the steps at our documentation.

API Access

As of now, you can enable the API access inside your panel and take advantage of the function we have recently implemented, like:

  • Add a server easily;
  • Upload a patch level directly from command line;
We plan to add more feature to the API very soon...

Least known features: Window size

If you are browsing WeSunSolve regularly, you can greatly enhance your browsing by fitting the size of the website to your resolution.
We've implemented three size of screen:

  • 960px
  • 1200px
  • 1600px
By default, the website is rendering in 960px, which is fine to cope with most of our visitors but certainly not the best one if you have a 22" screen ;-)
See our documentation to know how to change your settings.

Like it? Spread it!

Please, if you do like WeSunSolve, spread it over your fellow sysadmin! Write a blog post 'bout it and send it over to get a backlink :-)

You found a cool way of doing something with WeSunSolve that spared you hours of work? Please, tell us how! Don't hesitate to write a Howto on our wiki...

Finally, if you want to thank me personally, you can simply connect through LinkedIN and let a little recommendation on the WeSunSolve job...

How to upgrade a Solaris server to a particular patching level


Today at work, I needed to prepare the patching of a two-nodes cluster. Not only I should patch this cluster, but I should also mimic the same patching level as the currently used prod server. Well Well. Instead of making a diff of the showrev and try to sort out which patch is installed on this node, not on the other and so on, I tried to define a new way of doing this kind of things. I'll describe my method here, don't hesitate to comment, suggest or criticize something :)

The Idea

The idea is to use PCA to achieve everything. As you may (or may not) know, PCA is based upon patchdiag.xref files, which are provided by SUN Oracle once a day.

They contain the list of latest released patches as well as dependencies. The Idea of my solution is to generate a patchdiag.xref based on the patching level I should match. I could then use PCA together with this patchdiag.xref on the two nodes I need to patch. Child-Game!

WeSunSolve to the rescue

Again, you may (or not) know that WeSunSolve allow you to register yourself and use the Panel as a little server dashboard. You can enter some server name and link some patching level to them. This is being done using a simple "showrev -p" output that you can paste on the website to add patch level to a server.

Once you got two (or more) server, you can use the newly added feature Server Upgrade. You can choose two patching level there to generate a patchdiag.xref file:

  • Source patching level, is the patch level of the server you'll need to patch.
  • Destination patching level, is the patch level of the server you want to mimic.

Use PCA, and voila!

Next step is known by you all! Just use pca together with the patchdiag.xref file and see the output:

 $ ./pca -X . -f explorer.XXXXXXXXX.YYYYYYYYY-2011. -l
 Using /home/wildcat/YYYYYYYYYYY/./patchdiag.xref from Feb/03/12
 Host: XXXXXXXXXXX (SunOS 5.9/Generic_122300-05/sparc/sun4u)
 List: missing (133/210205)
 Patch  IR   CR RSB Age Synopsis
   -  - - -
 112951 13 < 14 RS- 999 SunOS 5.9: patchadd and patchrm Patch
 111711 16 < 18 R-- 999 SunOS 5.9: 32-bit Shared library patch for C++
 111712 16 < 18 R-- 999 SunOS 5.9: 64-Bit Shared library patch for C++
 **SNIPPED** – The Solaris Fingerprint Companion revived!

A few ago, I've found the script from Glenn Brunette which was used to check the fingerprint of any Solaris file against the SunSolve Fingerprint Database.

I've managed to port this script to be used against WeSunSolve fingerprint database, as the old sunsolve one is not available anymore.

You can find the modified version there:

Usage Example:

 # uname -a
 SunOS xxxxxxx 5.10 Generic_147440-01 sun4u sparc SUNW,SPARC-Enterprise
 # find /usr -type f -perm -2000 -o -perm -4000 -exec digest -a md5 {} \; | tee /tmp/md5.list
 ~/sfpC/sfpC-v0.6 $ ./ md5.list 
 -> 70888c55597129ae8f7143567c7dd2f1 found in 2 OS Releases and 1 patches.
   path: /usr/bin/at
   md5: 70888c55597129ae8f7143567c7dd2f1
   sha1: ce12021b0694dfe8d58c74f45b7988d87250dfb7
   size: 41344
   associated package: SUNWcsu
   associated solaris releases:
    > Solaris 10 (Update 10) 8/11 (sparc)
    > Solaris 10 (Update 9) 9/10 (sparc)
   associated solaris patches:
    > 142909-17  
 -> b437cf99006a0d22287f8b26938a90db found in 2 OS Releases and 1 patches.
   path: /usr/bin/atq
   md5: b437cf99006a0d22287f8b26938a90db
   sha1: 5568caebc18d066edf1d4d6a8888c91b521a19fa
   size: 19064
   associated package: SUNWcsu
   associated solaris releases:
    > Solaris 10 (Update 10) 8/11 (sparc)
    > Solaris 10 (Update 9) 9/10 (sparc)
   associated solaris patches:
    > 142909-17  
 -> 378b83c6d55b44d20a1f6902612a1d3d found in 2 OS Releases and 1 patches.
   path: /usr/bin/atrm
   md5: 378b83c6d55b44d20a1f6902612a1d3d
   sha1: 8ff96329c9e4f99a9288115fb8acc7cfa089ce10
   size: 19016
   associated package: SUNWcsu
   associated solaris releases:
    > Solaris 10 (Update 10) 8/11 (sparc)
    > Solaris 10 (Update 9) 9/10 (sparc)
   associated solaris patches:
    > 142909-17 
 -> d2acd1dd698e218a62aae3567336b4e1 found in 2 OS Releases and 1 patches.
   path: /usr/bin/crontab
   md5: d2acd1dd698e218a62aae3567336b4e1
   sha1: 45c6aa5803d3f4f02d68076eb99bbcc508511d59
   size: 20336
   associated package: SUNWcsu
   associated solaris releases:
    > Solaris 10 (Update 10) 8/11 (sparc)
    > Solaris 10 (Update 9) 9/10 (sparc)
   associated solaris patches:
    > 142909-17
 -> 055bc51ba15da6d5c15c7f7e26d538ea found in 11 OS Releases and 0 patches.

My Oracle Support: Authenticate with CLI

I was wondering since some times how I could authenticate on MOS using CLI. Now I got my answer: By reversing the whole SSO auth process in a python script that generate a cookies.txt file, usable with wget.

I know that a simpler method exists using directly wget, but as it doesn't work with every MOS page, I'll prefer a more generic way of doing things.

Here is a quick how to use:

  1. Edit and setup variables inside.
  1. Install python dependencies (linux/debian):
apt-get install python-pip
pip install BeautifulSoup
pip install requests
  1. Run the script
$ ./ 
[-] Initialization...done
[-] Gathering JSESSIONID..done
[-] Trying loginSuccess.jsp...done
[-] Signing in...done
[-] Trying to submit credentials...done
[-] Checking that credentials are valid...done
[-] Logged-in.
  1. Use the cookies.txt with wget
wget --load-cookies=/tmp/cookies.txt --save-cookies=/tmp/cookies.txt --no-check-certificate http://MOSURL

With a little bit of time and fun, you can imagine every tool based on this to ease your sysadmin life. You can even fetch your SR summary/updates using this cookie...

Get the file...