Archive for the ‘Uncategorized’ Category
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)
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.
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:
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:
6. Generate a new ISO:
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.
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.
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:
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.
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:
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:
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).