For the sake of absolute simplicity I'll assume here the DefaultFixed NCP.
My wired and wireless interfaces have been respectively renamed to e0 and w0.
In this scenario, to manually establish a Wi-Fi connection is not that difficult.
The best of all is that you can do it with a few CLI commands.
You may need to double-check what wireless networks are in range:
# dladm scan-wifi
...
To connect to a secure wireless network you need to define a security object.
This object will typically store a WPA2 shared secret key:
# dladm create-secobj -c wpa secobj-W0
provide value for 'secobj-W0':
******************************************************
confirm value for 'secobj-W0':
******************************************************
# dladm show-secobj
OBJECT CLASS
secobj-W0 wpa
Now it shall be possible to successfully connect to the proected wireless network.
Specify the wireless network, the security object and the wireless interface:
# dladm connect-wifi -e W0 -k secobj-W0 w0
If everything went well you'll get something such as:
# dladm show-wifi
LINK STATUS ESSID SEC STRENGTH MODE SPEED
w0 connected W0 wpa excellent g 54Mb
# dladm show-link
LINK CLASS MTU STATE OVER
w0 phys 1500 up --
e0 phys 1500 unknown --
We have just enabled the link w0 corresponding to the secure wireless network W0.
Now just conclude the usual network configuration over the link w0.
For instance:
# ipadm show-if
IFNAME CLASS STATE ACTIVE OVER
lo0 loopback ok yes --
# ipadm create-ip w0
# ipadm show-if
IFNAME CLASS STATE ACTIVE OVER
lo0 loopback ok yes --
w0 ip down no --
# ipadm create-addr -T dhcp -h vbox-1 w0/v4
# ipadm show-addr
lo0/v4 static ok 127.0.0.1/8
w0/v4 dhcp ok 10.0.0.7/28
lo0/v6 static ok ::1/128
This setup do not not automatically reconnect to W0 upon reboot.
Would this be by design of the fixed network configuration? I do not yet know.
By contrast, the reactive network configuration, such as the Automatic NCP does.
After a reboot it suffices to reenter the dladm connect-wifi command as above.
By the way, before shutdown or reboot it's advisable to manually disconnect.
Not issuing dladm disconnect-wifi before shutdown causes it to take a long time.
Thursday, December 27, 2012
Renaming network interfaces
Since OpenSolaris Crossbow project it's possible to rename network interfaces. This capability is also know as vanity names. This is of great help in organizing and documenting system configuration.
By default, the physical names will be abstracted to net0, net1, and so on...
The net prefix can be tweaked on svc:/network/datalink-management:default.
See the linkname-policy/phys-prefix SMF property.
See also dlmgmtd(1m).
In most cases it seems advantageous to rename interfaces.
For example, assume a desktop with both a wired and wireless connection.
By default, there will exist both net0 and net1.
But it could be easier to give them more meaningful names.
Assuming the wired interface is net0 it could be renamed to e0 (for ethernet).
By the same token I'd rather rename net1 to w0 (for wireless).
To accomplish this it suffices to:
# dladm rename-link net0 e0
# dladm rename-link net1 w0
But note that you can only do this if the link is not busy.
Otherwise you get error messages such as:
# dladm rename-link net0 e0
dladm: rename operation failed: link busy
By default, the physical names will be abstracted to net0, net1, and so on...
The net prefix can be tweaked on svc:/network/datalink-management:default.
See the linkname-policy/phys-prefix SMF property.
See also dlmgmtd(1m).
In most cases it seems advantageous to rename interfaces.
For example, assume a desktop with both a wired and wireless connection.
By default, there will exist both net0 and net1.
But it could be easier to give them more meaningful names.
Assuming the wired interface is net0 it could be renamed to e0 (for ethernet).
By the same token I'd rather rename net1 to w0 (for wireless).
To accomplish this it suffices to:
# dladm rename-link net0 e0
# dladm rename-link net1 w0
But note that you can only do this if the link is not busy.
Otherwise you get error messages such as:
# dladm rename-link net0 e0
dladm: rename operation failed: link busy
Sunday, December 23, 2012
Network Configuration Profiles
Solaris 11.1 documentation has greatly improved on this area.
Network Configuraton Profiles (NCPs) types are now very clearly described:
Of course it's paramount to know the implications of each NCP type.
After installation, netadm command can be used to select the active NCP type.
The reactive NCP type may be mostly interesting for non-server installations.
Nevertheless I believe certain server installations may profit from them as well.
To make the system use the default fixed NCP:
To make the system use the default reactive NCP:
NOTE
Network Configuraton Profiles (NCPs) types are now very clearly described:
- Fixed
There can exist only one per system.
The system-generated one is called DefaultFixed.
This NCP is generally used by the Text Installer.
- Reactive
There can exist as many as needed.
The system-generated one is called Automatic.
This NCP is generally used by the GUI Installer.
Of course it's paramount to know the implications of each NCP type.
After installation, netadm command can be used to select the active NCP type.
The reactive NCP type may be mostly interesting for non-server installations.
Nevertheless I believe certain server installations may profit from them as well.
To make the system use the default fixed NCP:
# netadm enable -p ncp DefaultFixed
# netadm list -p ncp
TYPE PROFILE STATE
ncp DefaultFixed online
ncp Automatic disabled
TYPE PROFILE STATE
ncp DefaultFixed online
ncp Automatic disabled
To make the system use the default reactive NCP:
# netadm enable -p ncp Automatic
# netadm list -p ncp
TYPE PROFILE STATE
ncp DefaultFixed disabled
ncp Automatic online
TYPE PROFILE STATE
ncp DefaultFixed disabled
ncp Automatic online
NOTE
Under Solaris 11 Express things are quite different.
And after a live install, ipfilter may stay in the way.
(if so, one should find out more detail under /etc/nwam)
The automatic stuff is called Network Auto Magic (nwam).
The procedure to revert to a fixed configuration is as follows:
# svcadm disable network/physical:nwam
# svcadm enable network/physical:default
# svcadm disable ipfilter
Then the manual configuration can be carried out as usual.
Thursday, November 22, 2012
SPARC History
The more I know about SPARC the more I like it.
Originally, there were something else than just about money.
Today we have the clear indication of key Oracle application features going into the silicon.
I hope all this is kept as "extensions" that don't cripple the original spirit of SPARC.
Here are some of my favorite "historical" videos:
Originally, there were something else than just about money.
Today we have the clear indication of key Oracle application features going into the silicon.
I hope all this is kept as "extensions" that don't cripple the original spirit of SPARC.
Here are some of my favorite "historical" videos:
Tuesday, November 6, 2012
Solaris Studio 12.3 installation
The best way to install Oracle Solaris Studio is to set up a local IPS repository.
After the above activities are completed, the installation is very easy:
It's important to adjust the PATH and MANPATH environment variables.
At some point on .profile add the following lines:
All this is very simple and we can start coding and compiling right away.
Nevertheless, I would highly recommend using a remote build host.
After the above activities are completed, the installation is very easy:
# pkg install solarisstudio-123
It's important to adjust the PATH and MANPATH environment variables.
At some point on .profile add the following lines:
PATH=$PATH:/opt/solarisstudio12.3/bin
export PATH
MANPATH=${MANPATH:-/usr/man}:/opt/solarisstudio12.3/man
export MANPATHAll this is very simple and we can start coding and compiling right away.
Nevertheless, I would highly recommend using a remote build host.
IPS repository access
The procedure is well and fairly documented but I'll attempt an additional summary.
Once the IPS repository creation is done, an access method must be chosen.
Please, assume the creation settings according to the above link.
If the repository is to be used:
For the file based origin it's as simple as:
# pkg set-publisher -p /export/depot/studio
For the networked version, things are slightly more complicated.
If simply setting up HTTP(S) access to a Solaris repository just do:
# FMRI=pkg/server
# URI=http://depot-1/solaris
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/solaris
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 80
# svccfg -s $FMRI setprop pkg/threads = 10
# svcadm refresh $FMRI
# svcadm enable $FMRI
# DEFAULT=http://pkg.oracle.com/solaris/release
# pkg set-publisher -G "$DEFAULT" -g "$URI" solaris
But if, in addition, for instance, also setting up HTTP(S) access to Solaris Studio repository, it will be necessary to set up an additional instance of the svc:/application/pkg/server SMF service. Note how the new instance, studio, just contains a few overrides.
# FMRI=pkg/server:studio
# svccfg -s $FMRI addpg pkg application
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/studio
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 81
# svccfg -s $FMRI setprop pkg/threads = 10
# svccfg -s $FMRI addpg general framework
# svccfg -s $FMRI addpropvalue general/complete astring: studio
# svccfg -s $FMRI addpropvalue general/enabled boolean: true
# svcadm refresh $FMRI
# svcadm enable $FMRI
# pkg set-publisher -g "$URI" solarisstudio
Once the IPS repository creation is done, an access method must be chosen.
Please, assume the creation settings according to the above link.
If the repository is to be used:
- Just within a single physical system, global zone and/or non-global zones:
It may be more efficient to use a file based origin (URI).
Non-global zones may inherit settings which is nice.
- By multiple physical systems or virtual machines, such as in remote building:
A network transport, such as HTTP or HTTPS is the best.
Note that you may also refer to http://localhost, of course.
For the file based origin it's as simple as:
# pkg set-publisher -p /export/depot/studio
For the networked version, things are slightly more complicated.
If simply setting up HTTP(S) access to a Solaris repository just do:
# FMRI=pkg/server
# URI=http://depot-1/solaris
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/solaris
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 80
# svccfg -s $FMRI setprop pkg/threads = 10
# svcadm refresh $FMRI
# svcadm enable $FMRI
# DEFAULT=http://pkg.oracle.com/solaris/release
# pkg set-publisher -G "$DEFAULT" -g "$URI" solaris
But if, in addition, for instance, also setting up HTTP(S) access to Solaris Studio repository, it will be necessary to set up an additional instance of the svc:/application/pkg/server SMF service. Note how the new instance, studio, just contains a few overrides.
# FMRI=pkg/server:studio
# URI=http://depot-1/studio
# svccfg -s pkg/server add studio
# svccfg -s pkg/server add studio
# svccfg -s $FMRI addpg pkg application
# svccfg -s $FMRI setprop pkg/inst_root = /export/depot/studio
# svccfg -s $FMRI setprop pkg/readonly = true
# svccfg -s $FMRI setprop pkg/proxy_base = astring: $URI
# svccfg -s $FMRI setprop pkg/port = 81
# svccfg -s $FMRI setprop pkg/threads = 10
# svccfg -s $FMRI addpg general framework
# svccfg -s $FMRI addpropvalue general/complete astring: studio
# svccfg -s $FMRI addpropvalue general/enabled boolean: true
# svcadm refresh $FMRI
# svcadm enable $FMRI
# pkg set-publisher -g "$URI" solarisstudio
IPS repository creation
This post is about the first steps on establishing a a local IPS repository.
But once this is done establishing access to it is covered on a separate post.
In addition, after these previous tasks are complete, it may be necessary to update it.
For instance, the best way to install Oracle Solaris Studio is to set up a local IPS repository.
The procedure is reasonably well and fairly documented, but let's review it anyway.
What may not be very clear is that by default a local repository would be assumed to rest in /var/pkg/repo, even though it doesn't exist by default. This means that a dedicated ZFS dataset could or should have its mountpoint property set to this default, although it could be better to use symbolic links yielding something similar to /var/pkg/solaris/11.x/release and /var/pkg/solaris/11.x/sru-# and so on... But below, as dealing with Studio packages instead of OS packages, I've followed the crowd and created something completely apart. Anyway, note that in addition to compression (compression=on), access time could be turned off (atime=off) to buy some performance:
# zfs get -r compression rpool/export/depot
NAME PROPERTY VALUE SOURCE
rpool/export/depot compression off default
rpool/export/depot/studio compression on local
# pkgrepo create /export/depot/studio
# ll /export/depot/studio
...
-rw-r--r-- 1 root root 78 Nov 6 10:45 pkg5.repository
I'll use the support version of the repository which requires an Oracle support plan.
With no support plan the release version can be used according to terms and conditions.
For both versions it's necessary to get certificate(s) at https://pkg-register.oracle.com:
# cd /var/pkg/ssl
# ll Studio_Support.*
...
-rw------- 1 root root 753 ... Studio_Support.cert.pem
-rw------- 1 root root 887 ... Studio_Support.key.pem
I'll use an script to populate and later update the local repository. If behind a proxy, set http_proxy and https_proxy accordingly. But sometimes a proxy/firewall can block the several TCP connections from the remote port 443 to random ports and the symptoms are stalls or ugly messages. In case of difficulties check your command line, your certificates and then the proxy/firewall settings. Perhaps you may need to temporary alter your wired connection and temporarily bypass something.
But IPS repositories are not only useful for Solaris Studio.
In fact, it's crucial for Solaris 11 itself.
Start with just the initial release version of the repository.
Later, it can turn into a multiple support release updates repository.
The big picture is rather simple:
For obtaining the release packages, two methods are available.
As always, begin by creating a dedicated ZFS file system.
Ideally, set compression and atime properties as already described.
The release packages can be found at http://pkg.oracle.com/solaris/release.
Alternatively, download and concatenate a split ISO file.
I'm not sure which is the most efficient.
I do know that burning the ISO file, instead of lofs-mounting it is bad idea.
It'll take much longer to receive all the packages.
Underlying seek in optical media isn't efficient.
The manifests processing is specially awful.
Getting the release packages.
Choose one of the following options.
OPTION 1:
OPTION 2:
user 1m20.248s
sys 3m43.634s
NOTE
# zfs get referenced,compressratio rpool/export/depot/solaris
NAME PROPERTY VALUE SOURCE
rpool/export/depot/solaris referenced 6.07G -
rpool/export/depot/solaris compressratio 1.15x -
# pkgrepo rebuild -s /export/depot/solaris
Initiating repository rebuild.
Up to this point the task is finished.
But for good practice and also for later incremental updates, snapshot it:
# zfs snapshot rpool/export/depot/solaris@release
NOTE
$ zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
depot 149G 38.1G 111G 25% 1.00x ONLINE -
export 464G 339G 125G 73% 1.00x ONLINE -
rpool 55.5G 14.4G 41.1G 25% 1.00x ONLINE -
Let me show a basic scheme that's been useful for years:
# zfs list -o name,mountpoint -t all -r depot | grep -v bk
NAME MOUNTPOINT
depot /depot
depot/software /depot/software
depot/solaris /depot/solaris
depot/solaris/11.2 /depot/solaris/11.2
depot/solaris/11.2@release -
depot/solaris/11.3 /depot/solaris/11.3
depot/solaris/11.3@release -
depot/studio /depot/studio
depot/studio/12 /depot/studio/12
depot/studio/12@release -
# ll /depot/solaris/ /depot/studio/
/depot/solaris/:
total 9
drwxr-xr-x 3 root root ... 11.2
drwxr-xr-x 3 root root ... 11.3
lrwxrwxrwx 1 root root ... current -> 11.3
/depot/studio/:
total 5
drwxr-xr-x 3 root root ... 12
lrwxrwxrwx 1 root root ... current -> 12
But once this is done establishing access to it is covered on a separate post.
In addition, after these previous tasks are complete, it may be necessary to update it.
For instance, the best way to install Oracle Solaris Studio is to set up a local IPS repository.
The procedure is reasonably well and fairly documented, but let's review it anyway.
What may not be very clear is that by default a local repository would be assumed to rest in /var/pkg/repo, even though it doesn't exist by default. This means that a dedicated ZFS dataset could or should have its mountpoint property set to this default, although it could be better to use symbolic links yielding something similar to /var/pkg/solaris/11.x/release and /var/pkg/solaris/11.x/sru-# and so on... But below, as dealing with Studio packages instead of OS packages, I've followed the crowd and created something completely apart. Anyway, note that in addition to compression (compression=on), access time could be turned off (atime=off) to buy some performance:
# zfs create rpool/export/depot
# zfs create -o compression=on rpool/export/depot/studio
NAME PROPERTY VALUE SOURCE
rpool/export/depot compression off default
rpool/export/depot/studio compression on local
# pkgrepo create /export/depot/studio
# ll /export/depot/studio
...
-rw-r--r-- 1 root root 78 Nov 6 10:45 pkg5.repository
I'll use the support version of the repository which requires an Oracle support plan.
With no support plan the release version can be used according to terms and conditions.
For both versions it's necessary to get certificate(s) at https://pkg-register.oracle.com:
# cd /var/pkg/ssl
# ll Studio_Support.*
...
-rw------- 1 root root 753 ... Studio_Support.cert.pem
-rw------- 1 root root 887 ... Studio_Support.key.pem
I'll use an script to populate and later update the local repository. If behind a proxy, set http_proxy and https_proxy accordingly. But sometimes a proxy/firewall can block the several TCP connections from the remote port 443 to random ports and the symptoms are stalls or ugly messages. In case of difficulties check your command line, your certificates and then the proxy/firewall settings. Perhaps you may need to temporary alter your wired connection and temporarily bypass something.
# cat update-studio
#!/bin/sh -
SSL=/var/pkg/ssl
PRODUCT=Studio_Support
PRODUCT=Studio_Support
KEY=$SSL/$PRODUCT.key.pem
CERT=$SSL/$PRODUCT.cert.pem
SOURCE=https://pkg.oracle.com/solarisstudio/support/
TARGET=/export/depot/studio
pkgrecv -s $SOURCE -d $TARGET --key $KEY --cert $CERT '*'
[ $? -eq 0 ] && pkgrepo refresh -s $TARGET pkgrecv -s $SOURCE -d $TARGET --key $KEY --cert $CERT '*'
But IPS repositories are not only useful for Solaris Studio.
In fact, it's crucial for Solaris 11 itself.
Start with just the initial release version of the repository.
Later, it can turn into a multiple support release updates repository.
The big picture is rather simple:
- Create a dedicated file system;
- Obtain just the release packages.
For obtaining the release packages, two methods are available.
As always, begin by creating a dedicated ZFS file system.
Ideally, set compression and atime properties as already described.
# zfs create rpool/export/depot/solaris
The release packages can be found at http://pkg.oracle.com/solaris/release.
Alternatively, download and concatenate a split ISO file.
I'm not sure which is the most efficient.
I do know that burning the ISO file, instead of lofs-mounting it is bad idea.
It'll take much longer to receive all the packages.
Underlying seek in optical media isn't efficient.
The manifests processing is specially awful.
Getting the release packages.
Choose one of the following options.
OPTION 1:
# pkgrepo create /export/depot/solaris
# URI=http://pkg.oracle.com/solaris/release
# URI=http://pkg.oracle.com/solaris/release
# pkgrecv -s $URI -d /export/depot/solaris '*'
# pkgrepo refresh -s /export/depot/solaris
Processing packages for publisher solaris ...
Retrieving and evaluating 4401 package(s)...
Download Manifests ( 369/4401) -
... Retrieving and evaluating 4401 package(s)...
Download Manifests ( 369/4401) -
OPTION 2:
# lofiadm -a /export/archive/sol-11_1-repo-full.iso
/dev/lofi/1
/dev/lofi/1
# mount -F hsfs /dev/lofi/1 /mnt
# ll /mnt
total 29
drwxr-xr-x 3 root root 2.0K ... repo
-rwxr-xr-x 1 root root 1.3K ... NOTICES
-rw-r--r-- 1 root root 3.2K ... COPYRIGHT
-rw-r--r-- 1 root root 7.4K ... README
(on an Intel Core 2 Quad Q6600 2.40 GHz with slow single disk)
total 29
drwxr-xr-x 3 root root 2.0K ... repo
-rwxr-xr-x 1 root root 1.3K ... NOTICES
-rw-r--r-- 1 root root 3.2K ... COPYRIGHT
-rw-r--r-- 1 root root 7.4K ... README
(on an Intel Core 2 Quad Q6600 2.40 GHz with slow single disk)
# time rsync -q -aP /mnt/repo/ /export/depot/solaris
real 8m23.000suser 1m20.248s
sys 3m43.634s
NOTE
Under VirtualBox that could be ridiculously more time consuming:
real 173m51.306s
user 1m19.884s
sys 3m14.512s
# umount /mnt
# lofiadm -d /dev/lofi/1
# zfs get referenced,compressratio rpool/export/depot/solaris
NAME PROPERTY VALUE SOURCE
rpool/export/depot/solaris referenced 6.07G -
rpool/export/depot/solaris compressratio 1.15x -
# pkgrepo rebuild -s /export/depot/solaris
Initiating repository rebuild.
Up to this point the task is finished.
But for good practice and also for later incremental updates, snapshot it:
# zfs snapshot rpool/export/depot/solaris@release
NOTE
On this post I've been using rpool/export/depot.
In fact what I prefer is to create dedicated pools.
That is, one for export and other for depot.
$ zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
depot 149G 38.1G 111G 25% 1.00x ONLINE -
export 464G 339G 125G 73% 1.00x ONLINE -
rpool 55.5G 14.4G 41.1G 25% 1.00x ONLINE -
Let me show a basic scheme that's been useful for years:
# zfs list -o name,mountpoint -t all -r depot | grep -v bk
NAME MOUNTPOINT
depot /depot
depot/software /depot/software
depot/solaris /depot/solaris
depot/solaris/11.2 /depot/solaris/11.2
depot/solaris/11.2@release -
depot/solaris/11.3 /depot/solaris/11.3
depot/solaris/11.3@release -
depot/studio /depot/studio
depot/studio/12 /depot/studio/12
depot/studio/12@release -
# ll /depot/solaris/ /depot/studio/
/depot/solaris/:
total 9
drwxr-xr-x 3 root root ... 11.2
drwxr-xr-x 3 root root ... 11.3
lrwxrwxrwx 1 root root ... current -> 11.3
/depot/studio/:
total 5
drwxr-xr-x 3 root root ... 12
lrwxrwxrwx 1 root root ... current -> 12
Monday, November 5, 2012
C++ remote build host setup
It's not that difficult to setup the a remote build host.
The problem is that it's not fully and/or clearly described in documentation.
In addition, there's a small caveat or trick to get it working: Internal Updates.
For the general setup, Oracle has pointed me out to the following good references:
To begin, install Oracle Solaris Studio on every local coding and remote build hosts.
On the coding nodes, hosts with a GUI, update all plug-ins, notably the C/C++ one.
This will assure the correct configuration and operation of remote build hosts.
You should see something similar to the following:
To finish preparations, also make sure that:
The remote build configuration is set up in the Build Hosts Manage dialog box.
It's invoked by the main menu File | Create Remote C/C++ Project | Manage Hosts...
To change a remote build host properties,
click the Properties... button.
To add a remote build host,
click the Add.. button:
The problem is that it's not fully and/or clearly described in documentation.
In addition, there's a small caveat or trick to get it working: Internal Updates.
For the general setup, Oracle has pointed me out to the following good references:
To begin, install Oracle Solaris Studio on every local coding and remote build hosts.
On the coding nodes, hosts with a GUI, update all plug-ins, notably the C/C++ one.
This will assure the correct configuration and operation of remote build hosts.
You should see something similar to the following:
 | |
| C/C++ plug-in updates (Internal Updates) |
To finish preparations, also make sure that:
- The same login account is consistently used.
This includes uid and gid values as well.
- SSH (preferably) or NFS is properly configured.
Note that NFS is important to the mixed mode only.
The remote build configuration is set up in the Build Hosts Manage dialog box.
It's invoked by the main menu File | Create Remote C/C++ Project | Manage Hosts...
To change a remote build host properties,
click the Properties... button.
To add a remote build host,
click the Add.. button:
- Type in the host FQDN in Hostname and click the Next > button.
Then enter the Login/User and Password information.
Consider ticking Remember Password checkbox.
Click the OK button.
- After a while the Tool Collections should be correctly detected.
Select the appropriate project files access (synchronization) method.
Again, this depends on the desired remote development mode.
Finally, click the Finish button to conclude the host addition.
- There's an additional step if the synchronization is System Level File Sharing.
Use the Path Mapper... button to map paths to the sources' central location.
C++ remote build host
This is one of the coolest features present in Oracle Solaris Studio 12.3 and NetBeans 6.9.
The term Remote Development seems usual, but I prefer the clearer Remote Build Host.
In a remote building scenario two separate hosts have the following activities (roles):
The remote building also supports running and debugging on mixed platforms.
Of course, this implies portable C/C++ coding.
For the sake of sanity I'll stick to, Solaris!
Depending on the setup, where the C/C++source files are kept, 3 modes are supported:
The term Remote Development seems usual, but I prefer the clearer Remote Build Host.
In a remote building scenario two separate hosts have the following activities (roles):
- Coding : A desktop or a laptop with a full-blown GUI IDE.
- Building : A very powerful and efficient server with no GUI.
The remote building also supports running and debugging on mixed platforms.
Of course, this implies portable C/C++ coding.
For the sake of sanity I'll stick to, Solaris!
Depending on the setup, where the C/C++source files are kept, 3 modes are supported:
- Simple : At the local coding host.
- Mixed : On shared storage, such as NFS.
- Full : On the remote build host.
Thursday, November 1, 2012
C++ stability & evolution
I love the C++ language since the beginning.
For me it all begins with BASIC, then Pascal, then C, then Object Pascal and finally C++.
On this blog I intend to share my experience with Oracle Solaris Studio 12.3.
I do not intend to write about C++, at least not on this blog.
What all this had to do with Solaris after all?
Well, C has everything to do with UNIX™ and Solaris is UNIX™ for the best.
I've never looked at any Solaris source code but for the most part it must be purely C.
At the same time a lot of C++ code should out there, despite Java.
Solaris is recognized by its ABI stability, a practical and important aspect to business.
This ABI stability may represent a key foundation and that's why it may be a critical factor.
See Stephen Clamage's Stability of the C++ ABI: Evolution of a Programming Language.
Nevertheless, a new C++ standard has finally emerged, know as C++11.
The language's author, Bjarne Stroustrup, still like the former designation, C++0x.
The new standard, ISO/IEC 14882:2011, is at ISO and a draft is available for free.
As projected there are modifications that may affect ABI implementations.
Bjarne's C++11 FAQ is a must reading for everyone using the old C++03 standard.
Current compilers, such as Oracle Solaris Studio 12.3, fully support only the old standard.
For me it seems inevitable that in the next couple of years things will have to change.
But I don't believe Solaris will break its 20 yeares ABI backwards compatibility.
I do hope that this major breakthrough is carefully handled.
For me it all begins with BASIC, then Pascal, then C, then Object Pascal and finally C++.
On this blog I intend to share my experience with Oracle Solaris Studio 12.3.
I do not intend to write about C++, at least not on this blog.
What all this had to do with Solaris after all?
Well, C has everything to do with UNIX™ and Solaris is UNIX™ for the best.
I've never looked at any Solaris source code but for the most part it must be purely C.
At the same time a lot of C++ code should out there, despite Java.
Solaris is recognized by its ABI stability, a practical and important aspect to business.
This ABI stability may represent a key foundation and that's why it may be a critical factor.
See Stephen Clamage's Stability of the C++ ABI: Evolution of a Programming Language.
Nevertheless, a new C++ standard has finally emerged, know as C++11.
The language's author, Bjarne Stroustrup, still like the former designation, C++0x.
The new standard, ISO/IEC 14882:2011, is at ISO and a draft is available for free.
As projected there are modifications that may affect ABI implementations.
Bjarne's C++11 FAQ is a must reading for everyone using the old C++03 standard.
Current compilers, such as Oracle Solaris Studio 12.3, fully support only the old standard.
For me it seems inevitable that in the next couple of years things will have to change.
But I don't believe Solaris will break its 20 yeares ABI backwards compatibility.
I do hope that this major breakthrough is carefully handled.
Thursday, October 25, 2012
Solaris 11.1 availability
Today is a great day!
Solaris 11.1 is available for downloading!
The new update continues raising the bar.
Tremendous enhancements and new features.
Oracle is definitely sustaining Solaris as the best UNIX™ ever.
Once more, since the beginning of this blog I can say:
If it must run, it runs on Solaris!
For the record, coincidence or not, Windows 8 became available today as well.
Unfortunately I didn't feel inclined to its new interface for desktop computing.
But that's another story that fortunately has nothing to do with Solaris.
Solaris 11.1 is available for downloading!
The new update continues raising the bar.
Tremendous enhancements and new features.
Oracle is definitely sustaining Solaris as the best UNIX™ ever.
Once more, since the beginning of this blog I can say:
If it must run, it runs on Solaris!
For the record, coincidence or not, Windows 8 became available today as well.
Unfortunately I didn't feel inclined to its new interface for desktop computing.
But that's another story that fortunately has nothing to do with Solaris.
Solaris 10 parallel zone patching
By a zoned Solaris 10 system I mean the existence of many non-global zones (NGZ).
There's perhaps a less known tunning that allows for parallel updating of multiple zones.
The num_proc setting is at /etc/patch/pdo.conf and described at pdo.conf(4).
The recommendation is to have num_proc equal to the on-line CPUs.
Thus, on a system with 4 online CPUs:
# psrinfo
0 on-line since 10/18/2012 06:28:18
1 on-line since 10/18/2012 06:28:18
2 on-line since 10/18/2012 06:28:18
3 on-line since 10/18/2012 06:28:18
A setting of 4 is recommended:
# cp -p /etc/patch/pdo.conf{,.0}
# vim /etc/patch/pdo.conf
# grep num_proc= /etc/patch/pdo.conf
# num_proc=
# num_proc=1 # default entry
num_proc=4
There's perhaps a less known tunning that allows for parallel updating of multiple zones.
The num_proc setting is at /etc/patch/pdo.conf and described at pdo.conf(4).
The recommendation is to have num_proc equal to the on-line CPUs.
Thus, on a system with 4 online CPUs:
# psrinfo
0 on-line since 10/18/2012 06:28:18
1 on-line since 10/18/2012 06:28:18
2 on-line since 10/18/2012 06:28:18
3 on-line since 10/18/2012 06:28:18
A setting of 4 is recommended:
# cp -p /etc/patch/pdo.conf{,.0}
# vim /etc/patch/pdo.conf
# grep num_proc= /etc/patch/pdo.conf
# num_proc=
# num_proc=1 # default entry
num_proc=4
Wednesday, October 3, 2012
Unattended SVr4 package install
SVr4 relocatable and non-relocatable packages add/removal can be fully automated.
This is accomplished by CLI options for response and administration files.
For simplicity, assume /pkg/out as the current directory on all that follows.
# cd /pkg/out
A response file is required if the package uses an interactive request script.
If so, the pkgask command is used to record all the answers in this file.
That's the case with my sample relocatable package PHXapp1.
Otherwise the following error message appears explaining the situation.
That's the case for my sample non-relocatable SMF service package PHXsvc1:
# pkgask -r ./PHXsvc1.response -d ./PHXsvc1.pkg PHXsvc1
pkgask: ERROR: ... does not contain an interactive request script
In general an administration file, admin(4), is required.
This is specially required if the package contains or references other scripts.
Basically and at a minimum, the following entries seem enough:
The above files make unattended package operations possible.
Option -r is for specifying the response file to pkgadd.
Option -a is for specifying the administration file to both pkgadd and pkgrm.
Optionally, the listing of the package contents can be omitted with option -n.
For the sample non-relocatable SMF service package PHXsvc1 it looks like:
Installation of <PHXsvc1> was successful.
# pkgrm -n -a ./PHX.admin PHXsvc1
Waiting up to 30 seconds for svc:/site/phx-svc:default to stop...
Removal of <PHXsvc1> was successful.
For the sample relocatable application package PHXapp1 it looks like:
# pkgadd
-n
-a ./PHX.admin
-r ./PHXapp1.response
-d ./PHXapp1.pkg
all
Copyright (c) 2012 ...
Installation of <PHXapp1> was successful.
# pkgrm -n -a ./PHX.admin PHXapp1
Removing package base directory.
Removal of <PHXapp1> was successful.
This is accomplished by CLI options for response and administration files.
For simplicity, assume /pkg/out as the current directory on all that follows.
# cd /pkg/out
A response file is required if the package uses an interactive request script.
If so, the pkgask command is used to record all the answers in this file.
That's the case with my sample relocatable package PHXapp1.
# pkgask -r ./PHXapp1.response -d ./PHXapp1.pkg PHXapp1 all
Processing package instance <PHXapp1> from </pkg/out/PHXapp1.pkg>
Relocatable sample package(i386,sparc) 1.0
Copyright (c) 2012 ...
Enter path to package base directory (q to quit) [/opt/PHXapp1] <ENTER>
Response file </pkg/out/PHXapp1.response> was created.
Processing of request script was successful.
# cat PHXapp1.response
Processing package instance <PHXapp1> from </pkg/out/PHXapp1.pkg>
Relocatable sample package(i386,sparc) 1.0
Copyright (c) 2012 ...
Enter path to package base directory (q to quit) [/opt/PHXapp1] <ENTER>
Response file </pkg/out/PHXapp1.response> was created.
Processing of request script was successful.
BASEDIR=/opt/PHXapp1
Otherwise the following error message appears explaining the situation.
That's the case for my sample non-relocatable SMF service package PHXsvc1:
# pkgask -r ./PHXsvc1.response -d ./PHXsvc1.pkg PHXsvc1
pkgask: ERROR: ... does not contain an interactive request script
In general an administration file, admin(4), is required.
This is specially required if the package contains or references other scripts.
Basically and at a minimum, the following entries seem enough:
# cat PHX.admin
setuid=nocheck
action=nocheck
action=nocheck
The above files make unattended package operations possible.
Option -r is for specifying the response file to pkgadd.
Option -a is for specifying the administration file to both pkgadd and pkgrm.
Optionally, the listing of the package contents can be omitted with option -n.
For the sample non-relocatable SMF service package PHXsvc1 it looks like:
# pkgadd -n -a ./PHX.admin -d ./PHXsvc1.pkg all
Copyright (c) 2012 ...Installation of <PHXsvc1>
# pkgrm -n -a ./PHX.admin PHXsvc1
Waiting up to 30 seconds for svc:/site/phx-svc:default to stop...
Removal of
For the sample relocatable application package PHXapp1 it looks like:
# pkgadd
-n
-a ./PHX.admin
-r ./PHXapp1.response
-d ./PHXapp1.pkg
all
Copyright (c) 2012 ...
Installation of
# pkgrm -n -a ./PHX.admin PHXapp1
Removing package base directory.
Removal of
Monday, September 24, 2012
SVr4 relocatable package
A relocatable package can be more easily developed then a non-relocatable package.
This is probably because it tends to be more self-contained.
The very first steps are common task.
The main idea of a relocatable package is that of a base directory.
It's the root of a directory hierarchy comprising all of the package contents.
It's highly recommended to choose somewhere under /opt and not /usr/local.
Also organize the directory hierarchy, contents, ownership and permissions.
(metafiles are highlighted below just to make them better distinguishable)
total ...
drwxr-xr-x 2 root bin 4 Sep 24 11:38 bin
drwxr-xr-x 2 root bin 3 Sep 24 11:38 include
drwxr-xr-x 2 root bin 3 Sep 24 11:39 lib
drwxr-xr-x 2 root bin 3 Sep 24 11:38 man
-rw-r--r-- 1 root root 186 Sep 25 14:40 copyright
-rw-r--r-- 1 root root 236 Sep 28 07:52 pkginfo
-rw-r--r-- 1 root root 381 Sep 28 10:19 request
-rw-r--r-- 1 root root 69 Sep 28 08:01 postremove
-rw-r--r-- 1 root root 333 Sep 28 08:26 prototype
Most of what's left to do is quite similar to the non-relocatable package's creation.
The first noticeable exception is the pkginfo's BASEDIR variable.
Note that by omitting BASEDIR will make pkgkadd emit an empty prompt for it.
Don't omit BASEDIR to make it a default to a request script base directory prompt.
Interestingly the BASEDIR is not automatically removed by pkgrm.
As the package is relocatable, the base directory may vary among installations.
Thus it isn't a good idea to hard code the base directory in the prototype either.
There comes in the postremove script together with the CLIENT_BASEDIR variable.
# cat pkginfo
PKG="PHXapp1"
NAME="Relocatable sample package"
ARCH="i386,sparc"
VERSION="1.0"
CATEGORY="system"
DESC="Relocatable package demonstration"
VENDOR="AZ - Learnings on Solaris"
PSTAMP="Sep 24, 2012"
CLASSES="none"
BASEDIR=/opt/PHXapp1
# cat prototype
! search bin include lib man
i copyright
i pkginfo
i request
i postremove
d none bin 0755 root sys
f none bin/script 0750 root root
f none bin/app1 0550 root sys
d none lib 0755 root sys
f none lib/libapp1 0444 root root
d none include 0755 root sys
f none include/app1.h 0444 root root
d none man 0755 root sys
f none man/man1 0644 root root
while [ 1 ]
do
printf "\nPath to base directory (q to quit) [$BASEDIR] "
read DIRECTORY
case "$DIRECTORY" in
"") break;
;;
/*) BASEDIR="$DIRECTORY"
break;
;;
q) exit 1
;;
*) printf "\tERROR: Path must begin with a slash (/).\n"
;;
esac
done
cat >$1 <EOF
BASEDIR=$BASEDIR
EOF
exit 0
echo Removing package base directory.
# Let the system complain if directory not empty (as expected).
rmdir $CLIENT_BASEDIR
exit 0
# pkgmk -o -d /pkg/out
## Building pkgmap from package prototype file.
## Processing pkginfo file.
## Attempting to volumize 9 entries in pkgmap.
part 1 -- 22 blocks, 21 entries
## Packaging one part.
/pkg/out/PHXapp1/pkgmap
/pkg/out/PHXapp1/pkginfo
/pkg/out/PHXapp1/reloc/bin/app1
/pkg/out/PHXapp1/reloc/bin/script
/pkg/out/PHXapp1/install/copyright
/pkg/out/PHXapp1/reloc/include/app1.h
/pkg/out/PHXapp1/reloc/lib/libapp1
/pkg/out/PHXapp1/reloc/man/man1
/pkg/out/PHXapp1/install/postremove
/pkg/out/PHXapp1/install/request
## Validating control scripts.
## Packaging complete.
# pkgtrans /pkg/out /pkg/out/PHXapp1.pkg PHXapp1
# ll /pkg/out
total ...
drwxr-xr-x 3 root root 5 Sep 24 11:39 PHXapp1
-rw-r--r-- 1 root root 4.0K Sep 24 12:25 PHXapp1.pkg
...
A few verifications could be:
# pkgchk -d /pkg/out/PHXapp1.pkg all
Checking uninstalled stream format package <PHXapp1> from </pkg/out/PHXapp1.pkg>
## Checking control scripts.
## Checking package objects.
## Checking is complete.
# pkginfo -l -d /pkg/out/PHXapp1.pkg
PKGINST: PHXapp1
NAME: Relocatable sample package
CATEGORY: system
ARCH: i386,sparc
VERSION: 1.0
BASEDIR: /opt/PHXapp1
VENDOR: AZ - Learnings on Solaris
DESC: Relocatable package demonstration
PSTAMP: Sep 24, 2012
STATUS: spooled
FILES: 14 spooled pathnames
4 directories
2 executables
5 package information files
5 blocks used (approx)
This is probably because it tends to be more self-contained.
The very first steps are common task.
# zfs create -o mountpoint=/pkg data/pkg
# zfs create data/pkg/src
# zfs create data/pkg/out
# mkdir /pkg/src/PHXapp1
# cd /pkg/src/PHXapp1
The main idea of a relocatable package is that of a base directory.
It's the root of a directory hierarchy comprising all of the package contents.
It's highly recommended to choose somewhere under /opt and not /usr/local.
Also organize the directory hierarchy, contents, ownership and permissions.
(metafiles are highlighted below just to make them better distinguishable)
# cp -pr /project/PHXapp1/* .
# lltotal ...
drwxr-xr-x 2 root bin 4 Sep 24 11:38 bin
drwxr-xr-x 2 root bin 3 Sep 24 11:38 include
drwxr-xr-x 2 root bin 3 Sep 24 11:39 lib
drwxr-xr-x 2 root bin 3 Sep 24 11:38 man
-rw-r--r-- 1 root root 186 Sep 25 14:40 copyright
-rw-r--r-- 1 root root 236 Sep 28 07:52 pkginfo
-rw-r--r-- 1 root root 381 Sep 28 10:19 request
-rw-r--r-- 1 root root 69 Sep 28 08:01 postremove
-rw-r--r-- 1 root root 333 Sep 28 08:26 prototype
Most of what's left to do is quite similar to the non-relocatable package's creation.
The first noticeable exception is the pkginfo's BASEDIR variable.
Note that by omitting BASEDIR will make pkgkadd emit an empty prompt for it.
Don't omit BASEDIR to make it a default to a request script base directory prompt.
Interestingly the BASEDIR is not automatically removed by pkgrm.
As the package is relocatable, the base directory may vary among installations.
Thus it isn't a good idea to hard code the base directory in the prototype either.
There comes in the postremove script together with the CLIENT_BASEDIR variable.
# cat pkginfo
PKG="PHXapp1"
NAME="Relocatable sample package"
ARCH="i386,sparc"
VERSION="1.0"
CATEGORY="system"
DESC="Relocatable package demonstration"
VENDOR="AZ - Learnings on Solaris"
PSTAMP="Sep 24, 2012"
CLASSES="none"
BASEDIR=/opt/PHXapp1
# cat prototype
! search bin include lib man
i copyright
i pkginfo
i request
i postremove
d none bin 0755 root sys
f none bin/script 0750 root root
f none bin/app1 0550 root sys
d none lib 0755 root sys
f none lib/libapp1 0444 root root
d none include 0755 root sys
f none include/app1.h 0444 root root
d none man 0755 root sys
f none man/man1 0644 root root
# cat request
#!/bin/shwhile [ 1 ]
do
printf "\nPath to base directory (q to quit) [$BASEDIR] "
read DIRECTORY
case "$DIRECTORY" in
"") break;
;;
/*) BASEDIR="$DIRECTORY"
break;
;;
q) exit 1
;;
*) printf "\tERROR: Path must begin with a slash (/).\n"
;;
esac
done
cat >$1 <EOF
BASEDIR=$BASEDIR
EOF
exit 0
# cat postremove
#!/bin/shecho Removing package base directory.
# Let the system complain if directory not empty (as expected).
rmdir $CLIENT_BASEDIR
exit 0
# pkgmk -o -d /pkg/out
## Building pkgmap from package prototype file.
## Processing pkginfo file.
## Attempting to volumize 9 entries in pkgmap.
part 1 -- 22 blocks, 21 entries
## Packaging one part.
/pkg/out/PHXapp1/pkgmap
/pkg/out/PHXapp1/pkginfo
/pkg/out/PHXapp1/reloc/bin/app1
/pkg/out/PHXapp1/reloc/bin/script
/pkg/out/PHXapp1/install/copyright
/pkg/out/PHXapp1/reloc/include/app1.h
/pkg/out/PHXapp1/reloc/lib/libapp1
/pkg/out/PHXapp1/reloc/man/man1
/pkg/out/PHXapp1/install/postremove
/pkg/out/PHXapp1/install/request
## Validating control scripts.
## Packaging complete.
# pkgtrans /pkg/out /pkg/out/PHXapp1.pkg PHXapp1
# ll /pkg/out
total ...
drwxr-xr-x 3 root root 5 Sep 24 11:39 PHXapp1
-rw-r--r-- 1 root root 4.0K Sep 24 12:25 PHXapp1.pkg
...
A few verifications could be:
# pkgchk -d /pkg/out/PHXapp1.pkg all
Checking uninstalled stream format package <PHXapp1> from </pkg/out/PHXapp1.pkg>
## Checking control scripts.
## Checking package objects.
## Checking is complete.
# pkginfo -l -d /pkg/out/PHXapp1.pkg
PKGINST: PHXapp1
NAME: Relocatable sample package
CATEGORY: system
ARCH: i386,sparc
VERSION: 1.0
BASEDIR: /opt/PHXapp1
VENDOR: AZ - Learnings on Solaris
DESC: Relocatable package demonstration
PSTAMP: Sep 24, 2012
STATUS: spooled
FILES: 14 spooled pathnames
4 directories
2 executables
5 package information files
5 blocks used (approx)
Thursday, September 20, 2012
Custom JumpStart first boot
Assume that the setup is according to Custom JumpStart framework setup.
Once the base system is installed, additional customization can take place.
In order to achieve this, an script must be run once on the first boot.
The options are:
For manageability, wrap the SMF service on a non-relocatable SVr4 package.
Make sure to avoid all interactions during package installation and removal.
This way it can be included in the Custom JumpStart general conveniences.
Assume such a package named AZ-1st-boot containing the following:
If in the correct place, the SMF service manifest will be imported on the first boot.
As an example, each file could be as follows:
# cd /pkg/src/AZ-1st-boot
NAME="AZ first boot"
ARCH="i386,sparc"
VERSION="1.0"
CATEGORY="system"
DESC="A 1st-boot one-time-only SMF service for finishing installation"
VENDOR="AZ - Learnings on Solaris"
PSTAMP="Oct 11, 2012"
CLASSES="none"
# cat prototype
i pkginfo
f none /var/svc/manifest/site/AZ-1st-boot.xml 0444 root sys
d none /opt/site 0755 root sys
f none /opt/site/AZ-1st-boot.sh 0555 root sys
# cat AZ-1st-boot.xml
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type='manifest' name='AZ:1st-boot-svc'>
<service name='site/1st-boot-svc' type='service' version='1'>
<create_default_instance enabled='true'/>
<single_instance/>
<dependency
name='multi-user'
grouping='require_all'
restart_on='none' type='service'>
<service_fmri value='svc:/milestone/multi-user:default'/>
</dependency>
<exec_method
type='method'
name='start'
exec='/opt/site/AZ-1st-boot.sh'
timeout_seconds='300'>
<method_context>
<method_credential user='root'/>
</method_context>
</exec_method>
<exec_method
type='method'
name='stop'
exec=':true'
timeout_seconds='30'/>
<property_group name='startd' type='framework'>
<propval name='duration' type='astring' value='transient'/>
</property_group>
</service>
</service_bundle>
# cat AZ-1st-boot.sh
#!/bin/sh
. /lib/svc/share/smf_include.sh
BIN=/usr/bin
SBIN=/usr/sbin
#.................................................................
# configure and enable SAR
$BIN/ed -s /var/spool/cron/crontabs/sys <<EOF
a
0,5,10,15,20,25,30,35,40,45,50,55 * * * 0-6 /usr/lib/sa/sa1
59 23 * * 0-6 /usr/lib/sa/sa2 -A
.
w
q
EOF
$SBIN/svcadm enable svc:/system/sar:default
#.................................................................
# configure FSS scheduler
$SBIN/dispadmin -d FSS
#.................................................................
# self-destroy
$SBIN/svcadm disable svc:/site/1st-boot-svc:default
$SBIN/svccfg delete -f svc:/site/1st-boot-svc:default
$BIN/ed -s <<EOF
a
mail=
setuid=nocheck
action=nocheck
.
w /tmp/AZ.admin
q
EOF
$SBIN/pkgrm -n -a /tmp/AZ.admin AZ-1st-boot
#.................................................................
# end
$SBIN/shutdown -i6 -g5 -y
exit $SMF_EXIT_OK
# pkgmk -o -d /package
## Building pkgmap from package prototype file.
## Processing pkginfo file.
WARNING: missing directory entry for </opt>
WARNING: missing directory entry for </var>
WARNING: missing directory entry for </var/svc>
WARNING: missing directory entry for </var/svc/manifest>
WARNING: missing directory entry for </var/svc/manifest/site>
## Attempting to volumize 3 entries in pkgmap.
part 1 -- 18 blocks, 14 entries
## Packaging one part.
/package/AZ-1st-boot/pkgmap
/package/AZ-1st-boot/pkginfo
/package/AZ-1st-boot/root/opt/site/AZ-1st-boot.sh
/package/AZ-1st-boot/root/var/svc/manifest/site/AZ-1st-boot.xml
## Validating control scripts.
## Packaging complete.
Once the base system is installed, additional customization can take place.
In order to achieve this, an script must be run once on the first boot.
The options are:
- A traditional self-destructive initialization script.
This may be simpler but it's deprecated, so better avoid it.
- A transient self-destructive SMF service.
The overall benefits of SMF tend to compensate the hurdles.
For manageability, wrap the SMF service on a non-relocatable SVr4 package.
Make sure to avoid all interactions during package installation and removal.
This way it can be included in the Custom JumpStart general conveniences.
Assume such a package named AZ-1st-boot containing the following:
- A transient service manifest, AZ-1st-boot.xml, describing the transient service.
To be automatically imported into services database on the next reboot,
place this file in /var/svc/manifest/site.
- The first boot script, AZ-1st-boot.sh, is invoked by the transient service.
The /opt directory is the only correct place to put additional software.
The /usr/local is not recommended for anything in Solaris.
IMPORTANT
Incidentally for a first boot script the class manifest must not be used.If in the correct place, the SMF service manifest will be imported on the first boot.
As an example, each file could be as follows:
# cd /pkg/src/AZ-1st-boot
# cat pkginfo
PKG="AZ-1st-boot"NAME="AZ first boot"
ARCH="i386,sparc"
VERSION="1.0"
CATEGORY="system"
DESC="A 1st-boot one-time-only SMF service for finishing installation"
VENDOR="AZ - Learnings on Solaris"
PSTAMP="Oct 11, 2012"
CLASSES="none"
# cat prototype
i pkginfo
f none /var/svc/manifest/site/AZ-1st-boot.xml 0444 root sys
d none /opt/site 0755 root sys
f none /opt/site/AZ-1st-boot.sh 0555 root sys
# cat AZ-1st-boot.xml
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type='manifest' name='AZ:1st-boot-svc'>
<service name='site/1st-boot-svc' type='service' version='1'>
<create_default_instance enabled='true'/>
<single_instance/>
<dependency
name='multi-user'
grouping='require_all'
restart_on='none' type='service'>
<service_fmri value='svc:/milestone/multi-user:default'/>
</dependency>
<exec_method
type='method'
name='start'
exec='/opt/site/AZ-1st-boot.sh'
timeout_seconds='300'>
<method_context>
<method_credential user='root'/>
</method_context>
</exec_method>
<exec_method
type='method'
name='stop'
exec=':true'
timeout_seconds='30'/>
<property_group name='startd' type='framework'>
<propval name='duration' type='astring' value='transient'/>
</property_group>
</service>
</service_bundle>
# cat AZ-1st-boot.sh
#!/bin/sh
. /lib/svc/share/smf_include.sh
BIN=/usr/bin
SBIN=/usr/sbin
#.................................................................
# configure and enable SAR
$BIN/ed -s /var/spool/cron/crontabs/sys <<EOF
a
0,5,10,15,20,25,30,35,40,45,50,55 * * * 0-6 /usr/lib/sa/sa1
59 23 * * 0-6 /usr/lib/sa/sa2 -A
.
w
q
EOF
$SBIN/svcadm enable svc:/system/sar:default
#.................................................................
# configure FSS scheduler
$SBIN/dispadmin -d FSS
#.................................................................
# self-destroy
$SBIN/svcadm disable svc:/site/1st-boot-svc:default
$SBIN/svccfg delete -f svc:/site/1st-boot-svc:default
$BIN/ed -s <<EOF
a
mail=
setuid=nocheck
action=nocheck
.
w /tmp/AZ.admin
q
EOF
$SBIN/pkgrm -n -a /tmp/AZ.admin AZ-1st-boot
#.................................................................
# end
$SBIN/shutdown -i6 -g5 -y
exit $SMF_EXIT_OK
# pkgmk -o -d /package
## Building pkgmap from package prototype file.
## Processing pkginfo file.
WARNING: missing directory entry for </opt>
WARNING: missing directory entry for </var>
WARNING: missing directory entry for </var/svc>
WARNING: missing directory entry for </var/svc/manifest>
WARNING: missing directory entry for </var/svc/manifest/site>
## Attempting to volumize 3 entries in pkgmap.
part 1 -- 18 blocks, 14 entries
## Packaging one part.
/package/AZ-1st-boot/pkgmap
/package/AZ-1st-boot/pkginfo
/package/AZ-1st-boot/root/opt/site/AZ-1st-boot.sh
/package/AZ-1st-boot/root/var/svc/manifest/site/AZ-1st-boot.xml
## Validating control scripts.
## Packaging complete.
Subscribe to:
Posts (Atom)