Showing posts with label tech. Show all posts
Showing posts with label tech. Show all posts

Friday, April 17, 2015

java security exceptions

note to self


Found somewhat easy way to get around the annoying java security settings. Simply add the destinations preceded by http:// and/or https:// to below text file, one per line. Make sure that there are no white spaces at the end of the line.

C:\Users\USER\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

Friday, February 27, 2015

NTFS read-write on Mac

I had no clue it was this complicated when i thought of copying some files on to a portable hard drive from a Mac, for a colleague. As it turned out, Mac has ntfs support but default behavior is to only allow read-only access.

After searching around for a good while finally came across this nice tool called "Mounty for NTFS" which did the trick for me. I'd highly recommend to check it out if you happen to run in to the same problem and not so familiar with Mac way of things -like me.

Google will easily find it for you, but here is a link to the site.

http://enjoygineering.com/mounty/

Friday, December 12, 2014

VMware SRM stuff

note to self

Came across this weird error and spent a good amount of time searching around with not much luck. As it turned out, lot of time could have been saved with a simple reboot of the vCenter server appliance.

SRM 5.8
vCenter Server Appliance 5.5, vSphere Web Client

SRM was fully functional when accessed via one of the vCenters while other gave error "getAttribute: Session already invalidated" when provided the credentials to access the remote vCenter.

A simple reboot of the problematic vCenter brought everything back to normal state, many hours later. When in doubt, reboot is the lesson i suppose.

Thursday, October 17, 2013

Netbackup stuff

note to self


Came across an issue recently on a media server. Issue seems to be related to robotic control and not the drives. In this setup, the media control host was not the media server which experienced the issue. tpconfig and vmoprcmd outputs from the problematic media server were as below. Notice the "AVR" for drives in vmoprcmd output, which indicates an issue with the robotic control.

bash-3.00# ./tpconfig -l
Device Robot Drive       Robot                    Drive                Device     
Type     Num Index  Type DrNum Status  Comment    Name                 Path       
robot      3    -    TLD    -       -  -          -                    ECC-QAS
  drive    -    0  hcart    1      UP  -          IBM.ULT3580-TD4.000  /dev/rmt0.1
  drive    -    1  hcart    2      UP  -          IBM.ULT3580-TD4.004  /dev/rmt1.1
  drive    -    2  hcart    3      UP  -          IBM.ULT3580-TD4.003  /dev/rmt2.1
  drive    -    3  hcart    4      UP  -          IBM.ULT3580-TD4.002  /dev/rmt3.1
bash-3.00# ./vmoprcmd -d

                                PENDING REQUESTS

                                     

                                  DRIVE STATUS

Drv Type   Control  User      Label  RecMID  ExtMID  Ready   Wr.Enbl.  ReqId
  0 hcart    AVR                -                     No       -         0  
  1 hcart    AVR                -                     No       -         0  
  2 hcart    AVR                -                     No       -         0  
  3 hcart    AVR                -                     No       -         0  

                             ADDITIONAL DRIVE STATUS

Drv DriveName            Shared    Assigned        Comment                   
  0 IBM.ULT3580-TD4.000   Yes      -                                         
  1 IBM.ULT3580-TD4.004   Yes      -                           
  2 IBM.ULT3580-TD4.003   Yes      -                                         
  3 IBM.ULT3580-TD4.002   Yes      -     




As it turns out, it was a simple issue of media server not being able to identify the media control host name. It was set up to use /etc/hosts for resolution, and someone had removed the entry for the media control host! 
Frustrating that the error is not specific enough to identify where the problem is..I guess checking if the media control host, master/emm etc. communication and name resolution as the first step in these type of cases would save a few hours.

Thursday, May 16, 2013

ethX adapter names getting incremented in Ubuntu on VMware

note to self

Came across this issue with a P2Vd Ubuntu system. Network interface name seemed to get incremented eth0 >eth1 >eth2 and so on, each time a new adapter is added even when the old one is removed.

It is caused by the udev rule to persist device names with the hardware id located in  /etc/udev/rules.d/70-persistent-net.rules

This blog here helped to figure it out.

Friday, April 05, 2013

Useful Veeam KBs

note to self

Surebackup Ping Test TimedOut
http://www.veeam.com/kb1067

How to log in to the Virtual Proxy Appliance
http://www.veeam.com/kb1447

Thursday, March 28, 2013

Platespin Migrate on RHEL

note to self

We had a requirement to convert a number of workloads on RHEV (Red Hat Enterprise Virtualization) environment to vSphere. This is so far unsupported with the vSphere converter tool, and it fails to at the initial step of querying the source system when attempted, complaining about not being able to detect volumes on the source system. (On RHEV, scsi disks are detected as /dev/vdX devices, could be one of the reasons.)

After trying at it for a while, we decided to give PlateSpin Migrate a go, and the results were quite satisfying.

Setting up and starting a workload "copy" is quite straightforward, but could get tricky at times if the source system is running GNU/Linux. (RHEL etc.) PlateSpin supports file based and block based copy methods and for Linux workloads, only the block based method is supported if the migration is to happen while the source is online. Block based copy method depends on a custom kernel module -which has to be build manually, if PlateSpin doesn't come with a matching one for the current kernel.

Process is explained in detail on the below link.
http://www.novell.com/support/kb/doc.php?id=7005873

During the conversion, if it throws an error similar to "Could not load driver: Exec format error", then probably the kernel module is not built compatible to the currently running kernel.

To make sure a built module is supported on the current kernel, without going through the trouble of packaging it for PlateSpin, it can be inserted to the running kernel manually. Inserting should not return any error. Loaded module can be viewed and then removed to clean up, by below commands in the order given.

insmod blkwatch.ko
lsmod | grep blkwatch
rmmod

Even though it looks like a bit more complicated than the vSphere converter, In my opinion, PlateSpin does a far better job! It will be interesting to see how it will handle a conversion where the kernel it self has to be replaced with a different one to be able to run on the destination platform. (eg. Xen to vSphere )

vCenter Converter Standalone P2V Fail

note to self


vCenter standalone converter 5.0.1-875114 (latest as of 03-2013) still seems to be having this issue with P2V on systems with using the VLAN tagging at the OS level. Culprit seems to be the "dot" (.) in the interface name.

This has been witnessed, identified and workaround suggested by a number of people and the article that helped me is here. Simply turning off those interfaces before the conversion, you can proceed to convert the system -if that is a possibility. If not, you can try the alternative suggested on the same link above, by changing how the interface is named ( VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD )

I witnessed the issue with few RHEL5.4 systems, but was unable to replicate the same on the RHEL5.8. Perhaps the issue has some dependancy on a OS component which has been updated on the later releases on RHEL. ( not so sure! )

Wednesday, December 21, 2011

lvm stuff

note to self
Encountered "Found duplicate PV" warning again, i keep forgetting the solution for some reason. Good KB article is here. Idea is to filter out everything that has multiple device files leaving only one, and making sure the one that is left is the best one to be used. For example, in a multipath environment filter out everything except the multipath'd device node created by the device-mapper or whichever multipath tool that is used. ( Eg. /dev/emcpowera etc. ) Once the changes are in place pvscan and vgscan can be issued and check the warning appears no longer. Example filter rule from the current SLES san-boot setup this was tested is below. It filters out everything except /dev/dm-* devices which are the multipath devices created by device mapper.
filter = [ "a|/dev/dm-.*|", "r|.*|" ]
Once this is tested, mkinitrd should be done to put the changes in to the initrd image to be activated at the boot.

uefi boot stuff

note to self
Came across this strange problem with SLES 11 SP1.
When installing on a UEFI enabled hardware, the system doesn't allow to create a LVM based partitioning scheme. According to tech-support it is due to be a bug in SP1, only to be fixed in SP2 which is due first quarter next year. Workaround is to create a separate /boot/efi , /boot in traditional partitions and rest inside the LVM as usual. Found this out from the good folk at #lvm. Looks more like a limitation of UEFI boot, rather than a OS bug to me.

Friday, December 10, 2010

V2V Conversion of a Redhat Xen VM to vSphere

I was involved in converting some Redhat Xen based VMs to VMware ESXi recently and found out that the conversion doesn't work straight away without any tweaks. So here is how we went about getting it done. Pretty simple, but just in-case anyone needs it.. 1. Find and Copy the normal kernel ( not the xen-kernel, the one that is installed by default ) rpm package on to the Xen based VM that is to be converted. 2. Convert the Xen based VM using the VMware Converter like its done on any other machine. 3. Once the conversion is complete, on the ESXi host, attach the appropriate Redhat installation media ( 1st CD, DVD ) to the newly created VM cdrom. 4. Startup the converted VM with the attached Redhat installation media and boot into the rescue mode with "linux rescue" 5. Once the system boots in to the rescue mode, it should automatically detect the Redhat Linux installation and mount it in to /mnt/sysimage. Do a "chroot /mnt/sysimage". 6. Install the previously copied kernel rpm from within the chroot'ed environment, using "rpm -i". Once the installation is complete take a look at the grub.conf and see if the necessary entries have been made by the installer. -not really necessary, installer will do the job properly every-single-time! :-) 7. Exit from the rescue environment, detach the Redhat installation media and boot up the VM with the newly installed kernel. That pretty much sums it all up. The reason why a kernel installation is necessary is, Xen kernel on a guest system is quite different from a normal kernel, and is specifically designed to run on top of a Xen Host. ( Something to do with having front-end device drivers etc.. I never finished reading up about this ) This process shouldn't be necessary for a KVM based VM, as the guests are unmodified on that platform. I have yet to try this. Hope this helps.

sysprep stuff

note to self
Ran in to some hassle with finding appropriate syspreps with VMware vCenter Converter. Quite simple as it turned out to locate them, but i keep forgetting what to put and where. Simply extract and copy all the contents of the appropriate package from this VMware KB article into the location that is displayed in the table. And remember, its not just the sysprep.exe it needs, but also the accompanying files as well. Hope i won't run into anymore time-wasting situations by forgetting this. Another thing worth noting is, in case a conversion was done without the proper packages in place, you can always initiate a reconfigure of the that VM using the Converter after making sure necessary files are in place.

Sunday, September 19, 2010

teamviewer stuff

note to self
Just happened to shut the TeamViewer from within the remote computer console and got kicked out of my session with no way to re-connect. Luckily i had ssh access to the same machine and tried a few things to get it working, as just issuing the command on the ssh'd terminal didn't go so well. Googled a bit and noticed that few others have come across similar problems starting TeamViewer from the terminal, but couldn't find a simple method that worked. -didn't look that hard anyway- Found out its a easy fix.
export DISPLAY=:0
That should do it. All it seems to need is a proper $DISPLAY with the value set to where current display manager's running. Once that's taken care of, TeamViewer can be started as a background process with "&". It should work even better with something like "screen" but didn't try that. yet.

Sunday, February 14, 2010

Moovida on F12

note to self
Experienced few problems getting Moovida to work on my Fedora 12. Moovida, formerly known as Elisa is a Media Center application. Elisa is still on yum, but the newer moovida is not on that yet.
One main problem on the old version Elisa, is that the grooveshark plugin is no longer working due to some changes (gstreamer?) [1] [2]. A set of Moovida packages for F12 are already available on the above bugzilla links, but they are not yet on the yum, seem to be undergoing review.
After downloading and building the RPMs from above, ran in to some other python related problem due to a deprecated function.
DeprecationWarning: the md5 module is deprecated; use hashlib instead
The fix was to install python-twisted.noarch
To sum it all up, below steps can be followed to get moovida on F12 until it appears on yum, which I'm hoping to take place soon.
1. Grab the SRC rpms from here. 2. Remove elisa components if they are already installed. 3. Install python-twisted.noarch along with it's dependencies. 3. rpmbuild --rebuild the moovida src rpms & install them.
Just checked it, and Grooveshark plugin is working without any problem now! :-) It doesn't have the facility to add tracks to the library, hope it's on the roadmap.

Friday, January 01, 2010

dcache on fedora12

Below are the steps taken to get dcache working on Fedora. I was using my Fedora 12 for this. A lot of stuff below is coming from my chat logs with wvithanage who is the project fellow.
Install below packages via yum along with their dependancies. yum package-name install
uuid-devel mysql-devel php-mysql php-ZendFramework-Db-Adapter-Mysqli lighttpd lighttpd-fastcgi
Make below symbolic links. You will have to create /usr/include/ossp directory as well )
Inside /usr/include/ossp/
uuid.h -> /usr/include/uuid.h
Inside /usr/lib
/usr/lib/libmysqlclient_r.so -> /usr/lib/mysql/libmysqlclient_r.so.16.0.0
Make a directory, and inside it run the below. If you don't have "svn" installed,
yum install svn would get that for you.
Now, simply change the directory to "trunk" and run the below commands.
./autogen.sh ./configure --prefix=/usr sudo make install
Run sudo dcache Point the browser to http://127.0.0.1:8085/ and create a user and login. Make sure to put the mysql database access details properly, and assign a port for dcache to listen on..and you are done. Now change your browser settings to use dcache as the proxy, after few minutes of browsing you should start noticing activities on the graphs. Hope this helps..did this in a bit of a hurry. Probably will have to go through again and make sure i didn't miss anything out.

Tuesday, December 29, 2009

gnome autostart stuff

note to self
Seems that the prioritizing autostart scripts has been dropped for some reason. Wanted this as i wanted to get Rumpus to start as i login to my F12. But it depends on Internet connectivity or else the java starts throwing some exceptions at you. Someone on #fedora pointed this out, saying priorities are not one of the priorities ;-) of gnome-autostart dev's at the moment. Hopefully they will do something about that once the more important stuff are taken care of. For the time being, something like this can be used to get around the network connectivity by checking for the connection before trying anything.
#!/bin/bash check() { if [[ `nm-tool | grep "^State"` = 'State: connected' ]]; then -YOUR-STUFF-GOES-IN-HERE- else sleep 5 check fi } check
Nothing big, but saves sometime looking around. Hope this helps.

Sunday, December 27, 2009

gnome stuff

note to self
Came across a small problem with a USB Scroll Mouse on Fedora 12, where the 3rd button functionality not proper. Simple fix was changing a gnome configuration key value. Good to have Configuration Editior installed for these sort of stuff. Change the key /desktop/gnome/accessibility/mouse/button_layout value from 2 > 3 and you are done. To get the Configuration Editor installed, yum install gconf-editor can be used.

Thursday, December 24, 2009

squid stuff

note to self
Keep forgetting this one, and end up look around for it all over again. To get the Date & Time in a human friendly format on Squid, it can be piped through this.
#!/usr/bin/perl -p s/^\d+\.\d+/localtime $&/e;
Quite useful if you are going through the logs looking for activities on certain dates and times, and if you don't have a log-parser-report generator program installed. Found it over here.

Tuesday, December 01, 2009

Pidgin-2.6.4 RPMs for Fedora 12

Just built a set of RPMs from pidgin-2.6.4 which was released some hours ago. I think i have messed up the package naming conventions, made the build to appear as 2.6.4-0.f12pre. Had to make some small changes to the 2.6.3 .spec cuz. the .spec that comes with the source was not made specifically for current Fedora releases, as it appeared. If you are interested in checking them out, get them from the below links. libpurple-2.6.4-0.fc12pre.i686.rpm pidgin-2.6.4-0.fc12pre.i686.rpm finch-2.6.4-0.fc12pre.i686.rpm Uploading to MediaFire sucked big time! and then tried a similar site with the same result. Perhaps its their flash based upload tools that doesn't play well with Firefox-GNU/Linux. Uploading to RapidShare now, and probably won't be going back to any of those other services for a long time if it keeps working well. 2.6.4 is not on the yum yet, make sure to take this one off and put the proper one once it appears on the updates. This is only meant to be a experiment. :-)

changing opnsense mtu

 note to self When an OpnSense is deployed on Proxmox environment where MTU is <1500, it doesn't seem to auto-detect and leaves the O...