My world of Unix and Storage

We have an impressive footprint of Sun server mainly M8000, M5000 and E2900 where frequently we have to create Veritas file system on storage provisioned from Clariions . Since, we handle both the Unix and Storage team it becomes rather easy to fulfill business requirement and avoid possible delays. Once the storage is provisioned we start like this: 1. As leadville drivers are in place on Solaris 10 servers, use cfgadm - al to determine the attachment points for external FC . 2. Use cfgadm -c configure , repeat this for all Ap _Id ,Changing the state of the attachment point for making the occupant hardware resource to be usable by OS 3. devfsadm -C ,Asking the drivers to do whatever to probe for the new devices and build subsequently the device files, it also create links for the files like / dev / rdsk /c1t0dos0 etc 4. powercf -q ,Create emcpower pseudo devices for the newly detected luns 5. powermt config ,Creates powerpath configuration 6. powermt save ,Commit the ch...

We have a mammoth task every quarter to patch all our Unix servers, and every month if the servers are in DMZ. With time we have formulated a couple of steps that makes life easier during patching of Sun servers. 1. We apply the same patch cluster on every Sun server for a particular quarter, no matter when we patch the server during a particular quarter . 2. Once the patch is downloaded at the centralized location, it is distributed to every server on the / directory. This may sound a little off track as the patch cluster consumes a good 1GB of space and the patching process might fail if we do not have sufficient disk space on our / and /var file system, but we had faced some NFS issues before where we had a lot of trouble bringing up the system after the nfs server crash in middle of the patching process. 3. We inform the database team before hand (1 week) about the patch cluster release and also share with the them release notes, for them to identify any issues with the database a...

Things have changed much post migration from RHEL 4 to RHEL 5. In 4, we can easily detect the luns by sending an echo command to rescan the HBA adapter driver, however in 5 this does not work or shall I say it is not available. But still I feel their should be some mechanism to query either the hba driver or the SCSI mid layer. I have tried the following on RHEL 5 to scan for the new luns and found it to work, but do not try it on production. # for name in `ls /sys/class/scsi_device`; do echo 1 > /sys/class/scsi_device/$name/device/rescan ;done Or use blockdev per device # for name in `ls /dev`; do blockdev --rereadpt /dev/$name ;done Got a script to do the same: ####### Script starts ######## #!/bin/bash FDBf=/tmp/fdbf FDAf=/tmp/fdaf PBf=/tmp/pbf PAf=/tmp/paf #before fdisk output fdisk -ll | egrep Disk | egrep -v emcpower >> $FDBf #before powerpath powermt display dev=all | egrep Pseudo >> $PBf Lun=$1 for name in `ls /sys/class/fc_transport/ | awk -Ft '{print $3}...

We are migrating our storage environment to the new Data center. As a result of which we had to replicate the storage environment from our current CX3-80 to the new NS-480. We had managed to get the excat snapshot of the existing setup in and excel sheet with raid type, lun number, raid group, lun size etc. We started like this: 1. The code 28 of the Flare on the NS-480 backend supports the navisecli as default not the classic navicli. So we had to create the security file for the user nasadmin on the Celerra control station in order to access the Clariion. We had created the user nasadmin on the Clariion as well. /nas/opt/Navisphere/bin/naviseccli -AddUserSecurity -scope 0 -password -user nasadmin 2. We had only about 14 raid groups so we created them manually one comand at a time. This is just one example /nas/opt/Navisphere/bin/naviseccli -h SPA createrg 101 0_1_0 1_1_0 0_2_0 1_2_0 0_1_1 1_1_1 0_2_1 1_2_1 -rm no -pri high -raidtype R10 3. Once the raid groups are in place, we had a ...

The tortoise client does not work with http, it has to be https when we use mod_ntlm in Linux. Following are steps to configure SVN with https wih Apache on Linux to work with tortoise svn client and with web browser on Windows/Linux: We will use the Apache httpd that comes with the distribution with ssl: Ensure atleast openssl-0.97 is available. Hostname: svnreposerver Server version: Apache/2.2.3 Openssl version: openssl097a Subversion version: 1.6.0 Neon version: 0.28.4 1. Yum update httpd-devel for mod_ntlm 2. Yum update mod_dav_svn for mod_dav_svn.so authz_mod_dav.so 3. Download sqlite-amalgamation-3.6.11 untar it. 4. Download neon-0.28.4 for subversion compilation with ssl 5. Download subversion-1.6.0 and untar it. 6. Copy sqlite-amalgamation/sqlite3.c inside subversion-1.6.0/sqlite-amalgamation/sqlite3.c, create the directory if required. 7. Compile neon with ssl support (./configure --with-ssl, make make install) 8. Compile subversion with neon (Take a backup of /usr/local/lib,...

We recently spinned off to a new company from the parent one. As a result a major infrastructure change had to be performed on all our equipments. We had a few Clariions for which the storage processors IP address had to change, as were assigned a new block of IP address. Their are a few things that had to be taken care before undergoing an IP address change of he storage processor IP address. 1. If the Clariion is master node of the global domain, then someone else had to be promoted to be domain master before changing the IP address. That is it has to be demoted as a master domain node. 2. Then the clarrion has to be removed from the domain. That is the domain security has to be reset 3. The storage processor has to be rebooted Briefly, the steps are as follows: 1. Promote some other Clariion to be the master node of the domain. (This can be achieved through the Navisphere web based console). 2. Remove the Clariion from the domain. (This can be done through the Navisphere web conso...

W e are running our Sybase production database on SunFire v490 with Solaris 10. We recently applied the cluster patch 141414 on the system. The root disk is encapsulated in raid1 with SVM with 3 metadb replicas on each disk. After running for a week the system ran out of max number of processes that a user can fork out. We were unable to log into the system from the RSC console also. The system was frozen and as the last option the system had to be hard rebooted. Eventually, this led to the boot archive corruption and the system did not allowed us to boot from the default disk. We had to boot failsafe mode, to recover from the boot archive failure. This also did not worked out, so we booted of from the cdrom and mounted the first disk in /a. We commented out the rootdev section in /etc/system and also removing the svm disk from vfstab and replacing it with ctds format disk. Also, we put a new parameter for maxusers in /etc/system as 4096, as the default value of 2048 was not sufficien...