Archive for the ‘Uncategorized’ Category

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):
Cacti
Nagios
This is somewhat info of the plugin check_ipmi_sensor
And its wiki (in German. Use Google for translation)
XenServer checks:
check_xen_pool
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.cat -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.

Subversion (SVN) over SSL in 10 small steps

Friday, April 27th, 2007

I have installed SVN on Centos4 (RHEL4) following these small and short steps.

1. Check out svnbook. This is the place where all your later questions will be answered.

2. Using Centos/RHEL and still not using Dag Wieers and RPMForge’s RPM repository?

3. Install using YUM or Apt the following packages:

mod_dav_svn

subversion

mod_ssl

distcache

neon

4. Create your SVN repository root directory and cd to there: "mkdir /var/www/svn ; cd /var/www/svn"

5. Create your new repository. I’ve used the name "projects" and I maintain the name later on. If you decide on another name, make sure to change wherever valid later: "svnadmin create projects"

6. Change ownership to Apache: "chown -R apache.apache projects"

7. Rename /etc/httpd/conf.d/subversion.conf to /etc/httpd/conf.d/subversion.conf.old

8. Edit /etc/httpd/conf/ssl.conf and add the following lines:

–Near the beginning, add these two lines:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

–Just above the line saying </VirtualHost> enter the following:

<Location />

      DAV svn
      SVNParentPath /var/www/svn
      SSLRequireSSL
      AuthType Basic
      AuthName "Company"
      AuthUserFile /etc/httpd/conf.d/passwd
      Require valid-user

</Location>

9. Check Apache to verify you didn’t destroy anything. No need, by the way, to create SSL self-signed certificate, as the installation of mod_ssl creates one for you: "apachectl -t". If you get "Ok", you’re Ok.

10. Add users by using the utility "htpasswd". The first time will require the flag "-c" which tells htpasswd to create the file. Later on, no need for this flage. Exmaple: The first user will require: "htpasswd -c /etc/httpd/conf.d/passwd user1". The 2nd user will require just "htpasswd /etc/httpd/conf.d/passwd user2".

Done. All you need to do is point your SVN client to https://<IP or Name>/projects and you’re good to go (of course – as soon as you specify your username and password).

Cacti and per minute poll

Monday, April 16th, 2007

I love the tool Cacti. It’s a nice graphing tool, which helps a lot in system monitoring and management.

Its logic, however, is not always obvious. The relationship between data types, host templates and graph templates is quite complex, and if you are to implement any non-default setup using Cacti, you better understand these relationships as soon as possible.

I was using it to monitor an ERP system. I have encountered in the past a problem with monitoring Linux network traffic through SNMP, since the container is a short integer, and during 5 minutes wait it gets filled several times, if this is 1Gb/s network connection we measure.

The solution I wanted to employ was to haste the system, and measure every minute (60 seconds). This isn’t trivial using either Cacti or MRTG, because they were designed for 5 minute interval.

I have found this link in Cacti’s forums, which shows how to do it, and it works fine, as long as you follow instructions by the letter. This was done on RH4 x86, using Dag Wieers’ Home-made RPM repository as the source for Cacti.

I will attempt to export the modified templates and upload them here, to save some of the dirty work required for the process to work.

AIGLX or XGL?

Monday, April 9th, 2007

As you can see in my previous posts, I have an NVidia card. It worked quite well while using XGL, but due to XGL’s memory consumption (it takes a lot of memory), I have decided to try for AIGLX, which is part of the X.org system.

In my previous post you can see that (and how) it was done. However, my overall experiance is that AIGLX, at least where it comes to Xorg 7.2 and NVidia (Driver 1.0-9755) is that XGL is much much faster.

The slow responses of the system during the several hours I used AIGLX (while trying somehow to increase performance) just made me go back to XGL. AIGLX is not good enough.

I’ve read several posts about it, and still, the results are undetermined. That’s why I post my own software versions here. AIGLX may perform better when using older or newer versions of NVidia’s driver, or Xorg, or whatever, but for me now – XGL does it well.

Compaq Proliant 360/370/380 G1 cpqarray problems with Ubuntu

Saturday, March 24th, 2007

Or, for that matter, any other Linux distribution that:

a. uses kernel 2.6.x up to 2.6.18

b. Does not dynamically create the initrd as part of the installation

Ubuntu, for that matter, is an example of not doing both. While it does create the initrd, it doesn’t create it dynamically per the output of ‘lspci‘, which results in inclusion of every SCSI module which exists.

The symptoms – you can install the system, however, you are unable to boot it afterwards. You might get into your Busybox initrd. The cpqarray module doesn’t detect any arrays. Error is "cpqarray: error sending ID controller" . You will notice that the module sym53c8xx is loaded.

I’ve searched for a solution and found an initial hint in this blog, however, the entry was not completely accurate. Following the tips given in this page, I was able to understand that there was a bug in the kernel which caused sym53c8xx modules to take-over the cpqarray. I was required to remove the modules from the initrd. I booted into rescue mode from the Ubuntu Server CD, and from there did the following:

1. mount /boot

2. add the following modules list to your /etc/initramfs-tools/modules – modules-proliantG1.txt

3. Edit /etc/initramfs-tools/initramfs.conf to change "MODULES=most" to "MODULES=list"

4. Run "update-initramfs -k 2.6.17-11-server -c" (this is relevant in my case – up-to-date Ubuntu server 6.10. For other versions, check what is the latest version of installed kernel. This can be found by a mere ls on /lib/modules/)

After reboot I was pleased to discover that my system was able to boot correctly, and I know it will do so for updated versions of the kernel

Finally had some time today

Thursday, March 22nd, 2007

So this post is not technical by nature.

Today I gave away 14 PCs and 5 VGA screens. All are in some-not-exactly-unworking-condition, which means that you can probably mix two computers into one, or you need only add some RAM, HDD or other several components to make any of these PCs work.

All of them are either Pentium1 or Pentium2 class (I think there was one AMD K6 there).

A picture of the pile before the giveaway:

This is the pile – 14 PCs and 5 VGAs!

So I searched for anyone who was willing to take them, and found one. I was surprised at how quick the responses were. It was less than 5 hours from the time I’ve posted my give-away offer, till the computers were gone.

You can say it’s for a good cause – the person who’s got them tries to make them work and then he installs Xubuntu on them (a very lightweight distro), and give them away (or sell them in a near-zero price) to people with no computer, and usually with zero computer skills. He teaches them to use the computer for the general day-to-day needs WE all are familiar with. This is an honorable task, I must say, and I salute him. Not only adding users to the pool of the modern society, but also doing it for near-zero pay, and actually making them Linux users – plain dumb-I-dont-have-viruses computer users. Can hardly be better.

DL140 Generation 1 (G1) and LILO do not work

Wednesday, February 14th, 2007

I add to this blog all pieces of information which I might think could help other people.

One of the things I have encountered short while ago had to do with DL140 G1 system cannot boot Linux.

It’s Linux system (RedHat 4 32bit) was deployed by an external system and the system could not boot. However, when installed from CD, the system booted just fine. The symptom for this was that after booting, the screen showed:

LILO: Loading Linux…..

and that’s all. The system could have booted (and did so once) after several days, however, this is not really a desired status.

It seems to be an issue of Lilo and this specific hardware. Other systems (non DL140) were able to boot just fine using Lilo, and this same kernel version was bootable on that system through other means.

Replacing Lilo with GRUB during installation/deployment solved the isse. FYI.