My world of Unix and Storage

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...

I recently encountered an issue with one of the production server running RHEL 4. All the httpd processes were alive and their was no issues with the web server, however when we ran the: service httpd status command, it says, "httpd dead but subsys locked." Their were no files inside the /var/lock/subsys directory for httpd and also I deleted the /var/run/httpd.pid file. However, the issue still persists. Even, I rebooted the server in the hope that this will clear any lock files. However, nothing happened. A careful examination of httpd.conf file at /etc/httpd/conf/httpd.conf file referred the pid file directory to /var/www/run, however the corresponding entry in the /etc/init.d/httpd file referred to /var/run directory for pid file. Changing the lockfile directory and the pid file directory to /var/www/lock/subsys and /var/www/run directory solved the issue. Now, service httpd status/start/restart/stop does not complain about the subsys issue.