Archive for the ‘Uncategorized’ Category

Oracle important patches

Friday, February 9th, 2018

I use this blog as an external memory. I found myself lately looking for the obvious patches for Oracle GI and RDBMS products, and although I eventually reach the right location, the time consumed looking for them is a wasted time. So – to make sure I can remember them correctly, here are the two important sites:

Oracle OPatch:

Oracle GI/DB patches:

Things to remember…

Monday, October 24th, 2011

As my work takes me to various places (where technology is concerned), I collect lots of browser tab of things I want to keep for later reference.
I have to admit, sadly, that I lack the time to sort them out, to make a real good and nice post about them. I do not want to lose them, however, so I am posting now those which I find or found in the past as more useful to me. I might expand either of them one day into a full post, or elaborate further on them. Either or none. For now – let’s clean up some tab space:
Reading IPMI sensors. Into Cacti, and into Nagios, with some minor modifications by myself (to be disclosed later, I believe):
This is somewhat info of the plugin check_ipmi_sensor
And its wiki (in German. Use Google for translation)
XenServer checks:
Checking XenServer using NRPE
But I did not care about Dom0 performance parameters, as they meant very little regarding the hypervisor’s behavior. So I have combined into it the following XenServer License Check. Unfortunately, I could run it only on the XenServer domain0, due to python version limitations on my Cacti /Nagios server.
You can obtain XenServer SDK
This plugin looks interesting for various XenServer checks, but I have never tried it myself.
Backing up (exporting) XenServer VMs as a scheduled task. I have had it modified extensively to match my requirements, but I am allowed to, it has some of its sources based on my blog 🙂
Installing Dell OpenManage on XenServer 5.6.1, and the nice thing is that it works fine on XenServer 6 as well.
Oracle ASM recovery tips . One day I will take it further, and investigate possible human errors and methods of fixing them. Experience, they say, has a value 🙂
A guide dealing with changing from raw to block devices in Oracle ASM . This is only a small part of it, but it’s the thing that interests me.
Understanding Steal Time in Linux Xen-based VMs.
Because I always forget, and I’m too lazy to search again and again (and reach the same page again and again): Upgrading PHP to 5.2 on Centos 5
And last – a very nice remote-control software fomr my Android phone. Don’t leave home without it. Seriously.

Reduced to only 23 tabs is excellent. This was a very nice job, and these links will be useful. To me, for sure. I hope that to you as well.

Preparing your own autoyast with custom Suse CD

Friday, August 17th, 2007

Suse, for some reason, has to be over-complicated. I don’t really know why, but the time required to perform simple tasks under Suse is longer than on any other Linux distro, and can be compared only to other legacy Unix systems I am familiar with.

When it comes to a more complicated tasks, it gets evern worse.

I have created an autoinst.xml today. It, generally speaking, installs a SLES10.1 system from scratch. Luckily, I was able to test it in a networked environment, so I helped the environment just a bit by not throwing tons of CDs.

Attached is my autoinst.xml. Notice that the root user has the password 123456, and that this file is based on a rather default selection.

Interesting, though, is my usage of the <ask> directives, which allow me to ask for manual IP address, Netmask, gateway, etc during the 2nd phase of the installation. sles10.1-autoinst.xml

This is only a small part. Assuming you want to ship this autoinst.xml with your Suse CDs, as a stand-alone distribution, you need to do the following:

1. Mount as loop the first CD:

mount -o loop /home/ezaton/ISO/SLES10-SP1-CD1.iso /mnt/temp

2. For quick response, if you have the required RAM, you could try to create a ramdisk. It will sure work fast:

mkdir /mnt/ram

mount -t ramfs -o size=700M none /mnt/ram

3. Copy the data from the CD to the ramdisk:

cp -R /mnt/temp/* /mnt/ram/

4. Add your autoinst.xml to the new cd root:

cp autoinst.xml /mnt/ram/

5. Edit the required isolinux.cfg parameters. On Suse10 it resides in the new <CD-ROOT>/boot/i386/loader/isolinux.cfg. In our case, CD-ROOT is /mnt/ram

Add the following text to the "linux" append line:

autoyast=default install=cdrom

6. Generate a new ISO:

cd /mnt/ram

mkisofs -o /tmp/new-SLES10.1-CD1.iso -b boot/i386/loader/isolinux.bin -r -T -J -pad -no-emul-boot -boot-load-size 4 -c -boot-info-table /mnt/ram

7. When done, burn your new CD, and boot from it.

8. If everything is ok, umount /mnt/ram and /mnt/temp, and you’re done.

Note – It is very important to use Rock Ridge and Jouliet extensions with the new CD, or else files will be in 8.3 format, and will not allow installation of SLES.

Broadcom (tg3) and quirks in Linux

Saturday, June 2nd, 2007

Most modern servers use Broadcom network cards. The module is called tg3 and is known to have issues.

You can find in my blog several posts about weird problems with tg3. This post is about another one I’ve encountered only recently.

The server: Dell PowerEdge (PE) 830. Linux version: RedHat Advanced Server 4 (RHEL4) Update 4. Kernel version 2.6.9-42.ELsmp. Version of the tg3 module: 3.52-rh.

Problem: When the card is being activated (brought up), it looses link for about 5 seconds. Later the link reappears and everything is fine. Implication: You cannot run DHCP client (dhclient) with this card, as it looses the link, and the DHCP client will fail with "link not ready" error message.

Fixed IP address works well, although the cards still looses the link when its being activated.

Fabric Mess, or how to do things right

Tuesday, May 29th, 2007

When a company is about to relocate to a new floor or a new building, that is the time when the little piles of dirt swept under the rug come back to hunt you.

In several companies I have been to, I have stressed the need of an ordered environment. This is valid to networking and hardware serial numbers as well as it is valid for FC hardware, but when it comes to FC, things always get somewhat more complicated, and when the fit hit the shan, the time you require for tracking down a single faulty cable, or a link led turned off is a time you need for other things.

I can sum it up to a single sentence – Keep you SAN tidy.

Unless you have planned your entire future SAN deployment ahead (and this can be planning ahead for years and years), your SAN environment will grow up. Unlike network, where short cable disconnections have only small influence on the overall status of a server (and this allows you to tidy up network cables on the fly after rush hours when traffic volume is low – without downtime), tidying up FC cables is a matter for a planned downtime, and let me see the high-level manager who would approve 30 minutes downtime (at least) with some risk (as there is always when changing cables) for "tidying up"…

So, your SAN looks like this, and this is the case, and this can be considered quite good:

Cables length is always an issue

You can track down cables, but it requires time, and time is an issue when there is a problem, or when changes are to take place. Wait – which server is connected to switch1 port 12? Donno?

The magic is, like most magic trick, non magical at all. Keep track of every cable, every path, every detail. You will not be sorry.

I have found out that the spreadsheet with the following columns would do the work for me, and I’ve been to some quire large SAN sites:

1. Switch name and port

2. Server Name (if server has multiple FC ports, add 0, 1, etc. Select a fixed convention for directions, for example – 0 is the leftmost, when you look directly at the back of the server). Same goes for storage devices.

3. SAN Zone of VSAN, if valid.

4. Patch panel port. If you go through several patch panels, write down all of them, one after the other.

5. Server’s port PWWN

On another spreadsheet I have the following information:

1. Server name

2. Storage ports accessible to it (using the same convention as mentioned above)

3. LUN ID on the storage described above.

If you keep these two spreadsheets up-to-date, you will be able to find your hands and legs anytime, anywhere in your own SAN. Maintaining the spreadsheet is the actual wizardry in all this.

Additional tip – If your company relocates to another building, and your SAN is pretty much fixed and known, hiring a person to manufacture by-the-length FC cables per device can be one of the greatest things you could do. If every cable has its own exact length, your SAN environment would look much better. This is a tip for the lucky ones. Most of us are not luck enough to either affort such a person, or to relocate with a never-changing SAN environment.