Map sd names to Solaris disk names

Map sd names to Solaris (SmartOS, Openindiana) disk names

paste -d= <(iostat -x | awk 'NR>2{print $1}') <(iostat -nx | awk 'NR>2{print "/dev/dsk/"$11}')

https://stackoverflow.com/questions/555427/map-sd-sdd-names-to-solaris-disk-names

Link for today

Solaris command: prstat http://jianmingli.com/wp/?p=1967

mysql Can't create/write to file /var/tmp/

Solaris 10 x86

mysqldump: Couldn't execute 'show fields from `general_log`': Can't create/write to file '/var/tmp/#sql3a3_43024_4.MYI' (Errcode: 13) (1)

Why?! WTF!

The last operation I made was the installation of MegaRAID Storage Manager from LSI Corporation package.

So? The /var/tmp directory was no more 777

Strange

Cycling date in bash

Maybe you want to cycle a time frame from a day to another, taking in consideration how many days a month have (also for leap years). Here is how you can do in bash.

Date format is: YYYYMMDD

#!/bin/bash

b=$1
e=$2

while [ "$b" -le "$e" ]
do
&nbsp;&nbsp;&nbsp;echo $b
&nbsp;&nbsp;&nbsp;b=$(date +%Y%m%d -d "$b +1 day")
done




Execute it

./loopdate.sh 20090101 20090301


Result

20090101
20090102
...
20090226
20090227
20090228
20090301


It works on Linux, and using gdate (from opencsw, blastwave) on Solaris. On Mac OS X it doesn't work.

JAVA cache at System Level

It could be useful to avoid that each user, on a multiuser operating system, have own java cache under his home directory, i.e. a corporate application used by each user. Every time the jnlpi is upgraded, every user have to download the new version in his home directory cache.

Using system level cache, only the first user launching the jnlpi will download the java application in the cache.


vi /usr/java/jre/lib/deployment.config

deployment.system.config file:/etc/java/deployment.properties

vi /etc/java/deployment.properties

deployment.system.cachedir /var/tmp/java/wscache
deployment.system.security.trusted.certs /var/tmp/java/security/trusted.certs

mkdir /var/tmp/java
mkdir /var/tmp/java/wscache


Warning. There will be problems with write and read permission on such directory...

Solaris, snooping RPC and "can't authenticate (unknown cause)" message

The problem

I had a problem with QStar Remote Admin connecting to a Solaris server. As far I can understand QStar uses RPC.

Sniffing traffic using snoop, I've seen a message like this:

1.2.3.4 →1.2.3.5 RPC R (#140) x10=1209249015 can't authenticate (unknown cause)

The problem was that local_only option in the network/rpc/bind service was set to true.

The solution

svccfg
  svc:> select network/rpc/bind
  svc:/network/rpc/bin> setprop config/local_only=false
  svc:/network/rpc/bind> quit
svcadm refresh network/rpc/bind:default
svcprop network/rpc/bind:default | grep local_only

References

https://blogs.oracle.com/rajeshr/entry/in_house_training_on_ha