Did you ever want to connect to IBM lotus sametime using the Linux messenger client (pidgin)? Here is a procedure of doing the same:-
OS:- Linux redhat 4 U4 (Nahant)
Messaging client:- pidgin (by default included in Redhat).
If you don't have pidgin, I would recommened downloading the rpm or debian package from Internet depending upon the OS version you have. Its a nice client used to connect to several protocols like yahoo, google talk, myspace IM etc.
Here is how to enable the sametime protocol alongwith others in pidgin:-
1. Run pidgin client on command console and check if you have sametime protocol listed in login options.
$ pipdgin &
If you are not running GUI on Linux, use export DISPLAY to export the GUI interface to any Linux desktop. If you have Reflection available, you can export it to Windows desktop as well.
2. Download the "meanwhile" rpm from internet. Check out "http://meanwhile.sourceforge.net", you should be able to download the rpm/debian package based on your OS/kernel version.
3. Install the package
rpm -ivh meanwhile*
if you manage to get hands on the source code, then compile and install the library.
4. Depending upon whether you have a GAIM client or pidgin, the library rpm might differ. For pidgin, I used libpurple-meanwhile** library.
5. Finally check the libmeanwhile.so file under pidgin install directory. "/usr/lib/pidgin/". If you are unable to find the libmeanwhile library under pidgin, then you will have to copy the file into pidgin lib folder.
6. Restart the pidgin client and check if sametime protocol appears under the drop-down.
I have a central server from where I can export the display onto my Linux desktop or various linux desktop's.
My first impression of sametime library was quite nice. It does not hang up while someone tries to contact me and is absolutely flawless in working.
Do not forget to check the port where you would be connecting to your sametime server. Ideally it should be 1533.
Rahul.
Monday, February 9, 2009
Friday, January 30, 2009
How to remove LUN devices from Veritas on Solaris and re-use them on a different server
Ever wanted to get rid of some of the old veritas disk groups from a Sun Solaris box in order to allocate that space onto a new server? Here is a short summary of steps which could be really helpful. As we all have faced these scenarios, I thought of documenting it.
Requirement
To remove about 10 recently allocated storage LUN devices (out of available 18 devices in the veritas disk group) from the server and put them onto a new box.
Summary of work required
1. First of all, unmount all the new filesystems created after the recent addition of 10 devices in the disk group.
2. Stop the new volume within the disk group (If you miss it, it might come back to haunt you when you deport the volume).
vxvol -g datadg stopall ## in case you are removing the whole disk group
vxvol -g datadg stop {volume} ## in case you are removing only some volumes from the disk group.
3. Remove the new volume for freeing the disks.
vxassist remove volume {volume} ## Step for removing some volumes out of the disk group
If you want to remove the complete disk group you can use the following:-
vxdg deport datadg
vxdg destroy datadg
4. Once the volumes are removed, check if the associated LUN disk drives are empty.
vxdg free
It should report the OFFSET to be 0 for the devices, if not DO NOT remove that drive, rather try to shrink the volume. Since the new drives were added latest into the disk group, the resizing will free those up first.
5. If 4 holds true for you (for me it did :D) then go ahead and mark the disk drives offline.
Use vxdiskadm command for the same, its CLI is pretty nice.
6. Once the drives are marked offline, you can safely login to the Storage and unmap the associated drives.
Ideally, while using Sun storage, the devices appear in the order to generation/detection. Unlike Linux, where you can use devlabel, Solaris offers controller based device naming conventions. But the only issue is that this convention is not visible on OS. For Sun storage, all LUN devices have a WWN number, but the server only prefixes the HBA card's WWN number. Hence the order of adding new LUNs should be done one by one and not in batch ;).
7. After I unmasked the drives, I used format command to check if OS still sees those LUNs. Afterwards, follow the following steps to remove the device config from Veritas:-
vxdisk rm {lun}
devfsadm -C
I do not like to use cfgadm to unconfigure the path, this is a step which is required if format still shows the removed LUN devices
cfgadm -c unconfigure cx::dsk/cxtydz
8. Now the devices are out of Solaris/Veritas control. Run vxdctl enable to cross-check if the devices show up again.
Well, the hard/tricky part is over. Go ahead and destroy the unmapped LUNs and re-create the device on storage. Afterwards, map it to new server where it would be used finally. Sounds easy isn't it? Well if you are lucky enough, just like me, you will run into another weird stuff.
When I presented the newly created 300 GB device (6X50 GB old LUNs), the device showed up with veritas plexes/pre configuration on new server. In another words, the device data was still intact :(. And to my surprise it reported 50 GB device rather then the actual 300 GB.
So I had to finally use the good old "dd" companion for flushing out the first 128 bits on the storage LUN. This was enough for Veritas volume manager to treat the device as a new one.
If you run into this issue, better remove the LUN device, re-create it on storage, remove the config from solaris kernel and then add it to the OS.
Hope it helps,
Rahul.
Requirement
To remove about 10 recently allocated storage LUN devices (out of available 18 devices in the veritas disk group) from the server and put them onto a new box.
Summary of work required
1. First of all, unmount all the new filesystems created after the recent addition of 10 devices in the disk group.
2. Stop the new volume within the disk group (If you miss it, it might come back to haunt you when you deport the volume).
vxvol -g datadg stopall ## in case you are removing the whole disk group
vxvol -g datadg stop {volume} ## in case you are removing only some volumes from the disk group.
3. Remove the new volume for freeing the disks.
vxassist remove volume {volume} ## Step for removing some volumes out of the disk group
If you want to remove the complete disk group you can use the following:-
vxdg deport datadg
vxdg destroy datadg
4. Once the volumes are removed, check if the associated LUN disk drives are empty.
vxdg free
It should report the OFFSET to be 0 for the devices, if not DO NOT remove that drive, rather try to shrink the volume. Since the new drives were added latest into the disk group, the resizing will free those up first.
5. If 4 holds true for you (for me it did :D) then go ahead and mark the disk drives offline.
Use vxdiskadm command for the same, its CLI is pretty nice.
6. Once the drives are marked offline, you can safely login to the Storage and unmap the associated drives.
Ideally, while using Sun storage, the devices appear in the order to generation/detection. Unlike Linux, where you can use devlabel, Solaris offers controller based device naming conventions. But the only issue is that this convention is not visible on OS. For Sun storage, all LUN devices have a WWN number, but the server only prefixes the HBA card's WWN number. Hence the order of adding new LUNs should be done one by one and not in batch ;).
7. After I unmasked the drives, I used format command to check if OS still sees those LUNs. Afterwards, follow the following steps to remove the device config from Veritas:-
vxdisk rm {lun}
devfsadm -C
I do not like to use cfgadm to unconfigure the path, this is a step which is required if format still shows the removed LUN devices
cfgadm -c unconfigure cx::dsk/cxtydz
8. Now the devices are out of Solaris/Veritas control. Run vxdctl enable to cross-check if the devices show up again.
Well, the hard/tricky part is over. Go ahead and destroy the unmapped LUNs and re-create the device on storage. Afterwards, map it to new server where it would be used finally. Sounds easy isn't it? Well if you are lucky enough, just like me, you will run into another weird stuff.
When I presented the newly created 300 GB device (6X50 GB old LUNs), the device showed up with veritas plexes/pre configuration on new server. In another words, the device data was still intact :(. And to my surprise it reported 50 GB device rather then the actual 300 GB.
So I had to finally use the good old "dd" companion for flushing out the first 128 bits on the storage LUN. This was enough for Veritas volume manager to treat the device as a new one.
If you run into this issue, better remove the LUN device, re-create it on storage, remove the config from solaris kernel and then add it to the OS.
Hope it helps,
Rahul.
Tuesday, December 9, 2008
Connect a Sun Solaris SPARC box to HP storage
My experience with SUN Sparc servers has been pretty good except for the fact that Sun charges $$ for anything which does not qualify as support and hence does not fall under master support contract.
I was once setting up a SPARC box V4** series and wanted to connect it to Sun Storage. I was told by Sun that it would cost us to connect the server to storage, as it was a new addition and not an existing support, fair enough. So instead we decided to connect it to another HP storage frame in our data center. Here are the detailed activities, which I did in order to connect the SUN box to HP frame.
1. Shutdown the box.
2. Insert the HBA card into the box.
3. Reboot the server.
4. Install the HBA packages and SUN packages for Storage management (SUNWqlc, SUNWqlcx, SUNWsmapi, SUNWssadx, SUNWssaop, OB2-CC, OB2-CORE, OB2-DA) available online and are opensource.
5. Install SFS_base_packages.S8 for Solaris 8 storage management.
6. After installing the packages, the server needs to be rebooted to load the libraries for HBA card detection.
7. Once the server is up, run the following commands to find out the path to HBA:-
bash-2.03# luxadm -e port
Found path to 5 HBA ports
/devices/pci@8,700000/SUNW,qlc@3/fp@0,0:devctl NOT CONNECTED
/devices/pci@8,700000/SUNW,qlc@3,1/fp@0,0:devctl NOT CONNECTED
/devices/pci@8,600000/SUNW,qlc@1/fp@0,0:devctl CONNECTED***
/devices/pci@8,600000/SUNW,qlc@1,1/fp@0,0:devctl NOT CONNECTED
/devices/pci@9,600000/SUNW,qlc@2/fp@0,0:devctl CONNECTED***
*** Indicates the HBA device ports available on the system, rest are the open PCI slots with no controller card.
Now confirm that the CONNECTED paths are HBA cards:-
# luxadm -e dump_map /devices/pci@8,600000/SUNW,qlc@1/fp@0,0:devctl
Pos Port_ID Hard_Addr Port WWN Node WWN Type
0 10e00 0 50001fe15000f3d8 50001fe15000f3d0 0xc (Array controller device)
1 10000 0 210000e08b07d5b4 200000e08b07d5b4 0x1f (Unknown Type,Host Bus Adapter)
Now check the dynamic configured devices
# cfgadm -al
Ap_Id Type Receptacle Occupant Condition
c0 scsi-bus connected configured unknown
c0::dsk/c0t0d0 CD-ROM connected configured unknown
c1 fc-private connected configured unknown
c1::500000e01129ff41 disk connected configured unknown
c1::500000e0112a0281 disk connected configured unknown
c2 fc connected unconfigured unknown
c3 fc connected unconfigured unknown
c4 fc-fabric connected configured unknown
c4::50001fe15000f3d8 array-ctrl connected unconfigured unknown
c5 fc connected unconfigured unknown
If the cfgadm command shows the HBA on controller 4 as unconfigured, connect the HBA to SAN through fiber cable, and run the command "cfgadm -o force_update -c configure c5" to configure the HBA channel. The good thing is that at this point you don’t have to actually present the vdisk, just ensure that the cable is in the HBA card so that link is UP..
# cfgadm -al
Ap_Id Type Receptacle Occupant Condition
c0 scsi-bus connected configured unknown
c0::dsk/c0t0d0 CD-ROM connected configured unknown
c1 fc-private connected configured unknown
c1::500000e01129ff41 disk connected configured unknown
c1::500000e0112a0281 disk connected configured unknown
c2 fc connected unconfigured unknown
c3 fc connected unconfigured unknown
c4 fc-fabric connected configured unknown
c4::50001fe15000f3d8 array-ctrl connected configured unknown
c5 fc connected unconfigured unknown
Important commands for HBA detection and configuration of LUNs are:-
luxadm -e port
luxadm -e dump_map
cfgadm -al
cfgadm -al -o show_FCP_dev
cfgadm -c configure c3
cfgadm -o force_update -c configure c3 ###Use this if the normal configure does not work.
luxadm probe
luxadm qlgc
8. Once the HBA is configured, create a vdisk on HP storage and assign it to the HBA card (using the WWN number).
9. Since my HP storage is connected to couple of switches, the switch needs to be configured to allocate the Path to HBA card.
10. After configuring the switch, enable the config on it (Note:- Never reboot the SAN switch, this is a common mistake and could lead to path revertion)
11. Once the config is enabled, the switch would be able to send out the LUNs to HBA card on the server.
12. Make sure that the Server Vdisk on the storage is set to "Path A/failover".
13. Begin detection of the disk drives on the server (following is the order of commands):-
luxadm probe ## initial probe for disk drives
luxadm qlgc ## initial probe of devices on Qlogic driver (HBA card vendor)
cfgadm -al ## Would display the new devices on the server
Sometime, cfgadm is unable to configure the controller so force it:-
"cfgadm -o force_update -c configure c3"
Once the controller is configured, the devices needs to be detected on the server:-
cfgadm -al -o show_FCP_dev ## this command will show all Fiber Channel Port devices coming from SAN.
14. Run the “format” command to see all the disk drives on the server.
Ideally, put in two HBA cards and then configure them. Afterwards, you could use the Volume manager software (like Veritas, it is free with Solaris 8 :D ). The LUNs multi-pathing can be done via DMP module of Veritas or any volume manager software.
I was once setting up a SPARC box V4** series and wanted to connect it to Sun Storage. I was told by Sun that it would cost us to connect the server to storage, as it was a new addition and not an existing support, fair enough. So instead we decided to connect it to another HP storage frame in our data center. Here are the detailed activities, which I did in order to connect the SUN box to HP frame.
1. Shutdown the box.
2. Insert the HBA card into the box.
3. Reboot the server.
4. Install the HBA packages and SUN packages for Storage management (SUNWqlc, SUNWqlcx, SUNWsmapi, SUNWssadx, SUNWssaop, OB2-CC, OB2-CORE, OB2-DA) available online and are opensource.
5. Install SFS_base_packages.S8 for Solaris 8 storage management.
6. After installing the packages, the server needs to be rebooted to load the libraries for HBA card detection.
7. Once the server is up, run the following commands to find out the path to HBA:-
bash-2.03# luxadm -e port
Found path to 5 HBA ports
/devices/pci@8,700000/SUNW,qlc@3/fp@0,0:devctl NOT CONNECTED
/devices/pci@8,700000/SUNW,qlc@3,1/fp@0,0:devctl NOT CONNECTED
/devices/pci@8,600000/SUNW,qlc@1/fp@0,0:devctl CONNECTED***
/devices/pci@8,600000/SUNW,qlc@1,1/fp@0,0:devctl NOT CONNECTED
/devices/pci@9,600000/SUNW,qlc@2/fp@0,0:devctl CONNECTED***
*** Indicates the HBA device ports available on the system, rest are the open PCI slots with no controller card.
Now confirm that the CONNECTED paths are HBA cards:-
# luxadm -e dump_map /devices/pci@8,600000/SUNW,qlc@1/fp@0,0:devctl
Pos Port_ID Hard_Addr Port WWN Node WWN Type
0 10e00 0 50001fe15000f3d8 50001fe15000f3d0 0xc (Array controller device)
1 10000 0 210000e08b07d5b4 200000e08b07d5b4 0x1f (Unknown Type,Host Bus Adapter)
Now check the dynamic configured devices
# cfgadm -al
Ap_Id Type Receptacle Occupant Condition
c0 scsi-bus connected configured unknown
c0::dsk/c0t0d0 CD-ROM connected configured unknown
c1 fc-private connected configured unknown
c1::500000e01129ff41 disk connected configured unknown
c1::500000e0112a0281 disk connected configured unknown
c2 fc connected unconfigured unknown
c3 fc connected unconfigured unknown
c4 fc-fabric connected configured unknown
c4::50001fe15000f3d8 array-ctrl connected unconfigured unknown
c5 fc connected unconfigured unknown
If the cfgadm command shows the HBA on controller 4 as unconfigured, connect the HBA to SAN through fiber cable, and run the command "cfgadm -o force_update -c configure c5" to configure the HBA channel. The good thing is that at this point you don’t have to actually present the vdisk, just ensure that the cable is in the HBA card so that link is UP..
# cfgadm -al
Ap_Id Type Receptacle Occupant Condition
c0 scsi-bus connected configured unknown
c0::dsk/c0t0d0 CD-ROM connected configured unknown
c1 fc-private connected configured unknown
c1::500000e01129ff41 disk connected configured unknown
c1::500000e0112a0281 disk connected configured unknown
c2 fc connected unconfigured unknown
c3 fc connected unconfigured unknown
c4 fc-fabric connected configured unknown
c4::50001fe15000f3d8 array-ctrl connected configured unknown
c5 fc connected unconfigured unknown
Important commands for HBA detection and configuration of LUNs are:-
luxadm -e port
luxadm -e dump_map
cfgadm -al
cfgadm -al -o show_FCP_dev
cfgadm -c configure c3
cfgadm -o force_update -c configure c3 ###Use this if the normal configure does not work.
luxadm probe
luxadm qlgc
8. Once the HBA is configured, create a vdisk on HP storage and assign it to the HBA card (using the WWN number).
9. Since my HP storage is connected to couple of switches, the switch needs to be configured to allocate the Path to HBA card.
10. After configuring the switch, enable the config on it (Note:- Never reboot the SAN switch, this is a common mistake and could lead to path revertion)
11. Once the config is enabled, the switch would be able to send out the LUNs to HBA card on the server.
12. Make sure that the Server Vdisk on the storage is set to "Path A/failover".
13. Begin detection of the disk drives on the server (following is the order of commands):-
luxadm probe ## initial probe for disk drives
luxadm qlgc ## initial probe of devices on Qlogic driver (HBA card vendor)
cfgadm -al ## Would display the new devices on the server
Sometime, cfgadm is unable to configure the controller so force it:-
"cfgadm -o force_update -c configure c3"
Once the controller is configured, the devices needs to be detected on the server:-
cfgadm -al -o show_FCP_dev ## this command will show all Fiber Channel Port devices coming from SAN.
14. Run the “format” command to see all the disk drives on the server.
Ideally, put in two HBA cards and then configure them. Afterwards, you could use the Volume manager software (like Veritas, it is free with Solaris 8 :D ). The LUNs multi-pathing can be done via DMP module of Veritas or any volume manager software.
Subscribe to:
Posts (Atom)
