Google Search

Google
Showing posts with label Hack. Show all posts
Showing posts with label Hack. Show all posts

Thursday, January 31, 2008

CentOS 5.1 kickstart lvm problems...

I have been messing around with the 5.1 kickstart for i386 for about 2 days now - as I'm not very good with python - as we need to kickstart PC-s with lvm support.

The error message states the following "An error occurred trying to format system/root_lv. This problem is serious, and the install cannot continue. Press to reboot your system."

And on tty5 (Alt + 5) another informative message "Could not stat /dev/system/root_lv --- No such file or directory. The device apparently does not exist; did you specify it correctly?"

It worked fine with the 5.0 tree, but when I wanted to kickstart with 5.1 I get an error that mkfs fails with /dev/system/root_lv and yes - there isn't a lvm path like that under the /dev.

After allot of debugging and messing around I found a workaround for it! It isn't easy nor is it for novice administrators so I would recommend just plain old install without the LVM support.

The problem is that the kickstart wont bring up lvm volumes before it tries to make a file system on them. Yes, it creates the physical volume, volume group and logical volumes, but it fails to activate them as the the LV-s are marked as created in the prep stages. This leaves us with a fully working LVM setup that is not activated and so the install crashes.

To fix the problem we need to hack the minstg2.img file in the repository. First make a backup of this file and copy it to a different folder. As I hacked it under Fedora 8 we need a package called "squashfs-tools" to unpack the image.

In the local folder run "unsquashfs minstg2.img" - this will create "squashfs-root" folder with the file system unpacked inside.

The problematic file is located "squashfs-root/usr/lib/anaconda" and the file is "fsset.py".
On line 1753 there is "self.volumesCreated = 1" - this should be changed "self.volumesCreated = 0".

Warning - watch the spacing as python is very touchy with extra or missing spaces.

Save the file and "cd ../../../../" back to the beginning.

Now we need to create and new image and for that I strongly recommend creating an image with a different name.

To create the image run "mksquashfs squashfs-root test.img" and it will create the new image.

Warning - back up the original if you have not done it for now!!!

copy the test.img the the repository server and replace the original minstg2.img with the test.img.

This should do the trick and kickstarting PC-s with LVM should work now.

As I mentioned - this is an hack not a solution, so if you have automatic mirroring and the image gets rewritten with the old one copy the test.image back.

Also this bug could be fixed in the future so this hack will get obsoleted some time...

Update: Added exact error messages and my local mirror updated the minstg2.img from upstream, so I had to copy the test.img to the minstg2.img again...

Have fun.

Blogged with Flock

Sunday, November 25, 2007

How to fix a simple Fedora 7 to Fedora 8 mess...

when doing a dist-upgrade from Fedora 7 to Fedora 8 I accidentally did a "init 3" - this is not recommended as the dkms installer runs and hangs the system as the rpm database gets locked.

The main thing is not to panic and send the machine to boot as it may not boot up and create even bigger mess...

The solution to this is simple:
first kill of any instance of rpm and rpmq
do and rm -rf /var/lib/rpm/__db.*
and rpm --rebuilddb

You can test if it worked by doing apt-get update and if it works - it will complain about allot of installed packages having duplicates but thats not really a problem (if you crashed at the beginning).

In my case it left duplicates that are obsoleted with the new release so I had to do "apt-get -f install" to fix the immediate dependence problems before I can continue with the dist-upgrade.

some could be frightened by this message
You are about to do something potentially harmful
To continue type in the phrase 'Yes, do as I say!'

well it is the reality - it is potentially dangerous to remove them so it is wise the check if the packages that will be removed have duplicates installed already (hint - removing glibc* will trash your system if you don't have a new version installed).

If you think everything is fine, well guess again - the first thing you need to do is to install new apt with its deps, do an "apt-get update" and then "apt-get upgrade". Dist upgrade is not possible as it most likely there are broke deps and file conflicts at the system right now so most like it will fail at the the end.

In my case it was at around 800 packages so I have around 800 duplicates - ARRGH. Removing them manually is possibly the wisest thing as some packages do not contain fc6/fc7/fc8 tags so you don't have a reference point what package is newer. All so some Fedora 8 packages come without the fc8 tag, so go figure...

The dist upgrade part will be next after the system gets "fixed".

Here are few scripts that "can" help:
rpm -qa | grep fc7 > /tmp/fc7packages
rpm -qa | grep fc6 >> /tmp/fc7packages

for i in `cat /tmp/fc7packages | sort | sed -e "s/-[0-9].*//" `; do echo "$i check-------------------------------------------------------"; rpm -q $i; done > /tmp/checklist


This is not an fix for a beginner, but a guide on how I did it, so use it at your own risk!

Blogged with Flock

Thursday, October 11, 2007

Resurrecting old hardware...

Hardware is getting faster and faster, so people upgrade as the needs get bigger and bigger. What about the old hardware that stays behind? Some of it gets reused for low priority servers but most of them get thrown away as obsolete. The worst case is if the hardware itself has become obsolete aka its maxed out when it was current.

Well I happened to be involved in one of this type of resurrections. The server was an IBM xSeries 220 tower with 72GB hardware raid 1 array and a small 40GB IDE drive. The idea was to upgrade the small IDE to a 160GB drive to get more storage area. As the 220 has show insane stability the idea was well at the beginning, well until the new drive was installed and well, the Linux recognized it. But here is where the problems started. The performance was insane - the drive would max out at 500KB/s with the read timings test (hdparm -t /dev/hda). The other symptom was drive seek errors which would indicate that there were bad blocks at the beginning or supernodes which would mean that the drive was dieing.

As the Maxtor's drive was brand new (just out of the anti static bag) it could not be the case. After a test with a second 160GB drive the results were the same. Logically thinking - this means we have hit the LBA32 127GB limit. The BIOS cant address more address space than 127GB and when you do you hit the brick wall of buffer overflows in the address registers (most likely when you write over 127GB you start from the 0x0 h again and write up the drives beginning). Of course the Linux kernel takes over the drive addressing after you boot up, but for that to work well the BIOS has to be satisfied first. Well copying 127GB at the rate of 500KB/s would take 266 338 seconds - thats around 3 days straight - I didn't have that much time to wait to see what would happen after the limit gets exceeded.

So what to do when your hardware is too obsolete for upgrading to your needs? You hack it!

In my case it was simple as Maxtor has firmware utility called SeaTools that can change the drive capacity in the firmware. Why is that good you ask? Well this way we can fake the hardwares without using the soldering iron or assembler to hack the firmware in the device.

The procedure goes like this:
  1. install the new HDD
  2. boot into BIOS and accept the changes (new HDD 6GB?!?!?)
  3. boot into the SeaTools utility (CD or floppy)
  4. Change the drives capacity to be 32GB
  5. Shutdown the machine and remove the drive
  6. Boot into the BIOS and accept the changes (the IDE drive has gone away)
  7. Shutdown the machine and reconnect the drive
  8. Boot into BIOS and accept the changes (new 32GB drive)
  9. Boot into the SeaTools and restore the drives capacity
  10. Boot into Linux :)
The BIOS still thinks it has a 6GB drive connected but its happy with it. Also the Linux boots up faster as BIOS is not complaining about seek errors when addressing the drive.

Running hdparm  -t should result in 13...25MB/sec - not the best speed but a lot better than 500KB/sec. You may ask what the range is so big - but I don't have an answer. On some systems the drive runs with udma2 mode on others in mdma2 mode. Forcing the mdma2 mode to go to udma2 mode did not seem to have the desired performance change but still its working well enough.

Many may ask "why would you ever want to resurrect an old xSeries 220", but the answer is simple. The system has been in use for a long time and if it has not died so far it wont in the near future. Also the speed is boosted with built in SCSI drives.

So where to use the old xSeries 220? Well, for test servers, for low priority web/sql servers, dns servers - there is no good answer. It all depends on the needs of the system. One place would be central log server - aka other servers log to this host, the syslog would save the logs in real time to the SCSI drives and nightly you rotate the logs to go into the mysql database on the IDE drive. Why do this? Well, logs are here for one purpose to be analyzed afterwards.

Another good example would be to use it as a file server - share out the data on SCI to Linux hosts and from IDE to windows hosts and if they start to complain that the speeds are soooo slooowwww blame it on windows and propagate the move to Linux :P

What can I say - use Your imagination.
Tested on CentOS 4.5 - but should work on any Linux with 2.6 kernel.

Blogged with Flock

Wednesday, August 8, 2007

Uplink - The way of the hacker...

Ok, so this is a bit of off topic, but I just could not leave it unmentioned.

Everyone is talking that Linux is crap just because there are no games that run natively under Linux and I'm not talking about the GPL-d games and the community "hacked" games. All the big game companies are wining about the lack of standard game development api-s and libraries, but they exist and they just don't have the coders to port the games to Linux as they are only built on top of the windows DirectX api-s and are not written in consideration for other rendering api-s. So its simpler to blame the Linux for lacking api-s than admit that it would take around 3 years to totally rewrite an existing game to Linux.

Well, I'm glad that one small firm has written a game that runs natively under Linux. The game is called Uplink and the company is Introversion.

This game has existed for a while (ummm 4+ years) and as I have not played games for a while I found that it had a native Linux version built also :)

Ok, the game is not really big and fancy for its graphics, but starting from version 1.3 it looks like its windows counterpart. As I'm found of my 1600x1200 resolution the 1.3 version is the milestone that proves that it is doable. Maybe it is not as simple to make a 3d FPS than a 2d strategy/RPG but it just show that the potential is there and that the big companies should stop hiding behind the "lack of api-s" and start thinking of the market share the Linux games will be taking in the near future. Especially when the "Completely Fair Queue" has been implemented in the Linux kernel starting from 2.6.23.

As a side note - an old goddy also exist "Railroad Tycoon" run through OpenTT works also perfectly :)

PS!: I love my vacation so far :)

technorati tags:, ,

Blogged with Flock

Saturday, July 7, 2007

LVM volume management made easy...

As a enterprise architect/infrastructure developer I'm faced with allot of problems that seem trivial on small scale but when you need to manage thousands of workstations or servers become critical problems. One of them is hard drive partitioning.

For security and stability reasons it is wise to split your root file system to several peaces - my default is:

/boot
/
/tmp
/var
/var/log
/home
swap

This may seem like crazy layout, but when you think of it, most problems start with servers getting root kited by some trivial exploit that will be used to trigger a buffer overflow and there for get a shell. If the tmp, var, var/log and home are mounted as noexec even when the exploit manages to download the overflow script - it wont be allowed to execute. This means its 1 step closer to avoid a security breach.

As I said before - it looks like a trivial task - install the server properly and thats it. Well this advice is good for up to 25..50 machines per admin, but it will fail miserably when you are running hundreds or thousands of machines. You may succeed to install them but soon after you are faced with a problem that some partitions need to be resized because one is almost empty and the other is constantly filling up.

If its just a pc you can take it offline and reinstall/boot to rescue and resize them. But when you are running mission critical servers its not an option. The same gos when you are running systems with different hardware configurations and there fore with different disk sizes. Here comes in the Logical Volume Manager (LVM). It creates another layer of abstraction on top of the physical layer therefore giving you another layer of dynamic configuration.

The greatest advantage of using LVM is that it you can create/resize/delete volumes on the fly without needing to reboot the server or boot to rescue to manage it. Sure it is not as simple as it sounds but basically it works wonders. It also gives the possibility to build the LVM volume on top of the hard drive or a raid device on full extent leaving you (in ideal case) with only 1 partition on the device (I use 2 - I like to keep /boot separately).

So in my case it is not wise make "full" partitioning of the drive, but to keep the partition sizes to minimum (that means with 10% overhead) leaving the rest of the drive free. This will allow me the simply "add" space to the volume that needs space without needing to shrink another volume (this volume cant be mounted while shrinking so this will need rescue mode!!!). Also keeping operating system on one volume group and data on another can save allot of work when restoring a system. For this I use a software designed by me called FabricManager - looks like I have to blog about in the future...

This works well until you run into a problem - You have 1000 workstations installed with this configuration and you want to do a dist upgrade. All is goo until you run out of space in the root volume to do it. 80% of the disk is filled with downloaded rpm's and there is no space left to install them. With LVM it is no problem, You just add some space to the root volume and all works out well, but here comes the catch - how long will it take to manually resize the root volume in 1000 workstations? I'm guessing around a month or two. And this is the best case scenario. Assuming that a good security policy is in place and none of the workstations have the same root password the time could be extended to few years which defies the whole point of upgrading. Sure if all the workstations have been installed with the same root password you can use an script to run the command automatically, but then You will run into about 10% of computers that wont accept the password and the 10..20% of PCs that are turned off at the time you run it. What about strict security policy that wont allow root to even log in remotely? What if the workstations are in different locations or countries or even continents? You can't just run the script few times and hope for the best as some workstations get several times the space needed and some get none.

And so a trivial problem grew out of proportions in seconds and one small design flaw can cost ALLOT of time trying to fix all the problems separately. this led me to write a small shell script that would be able to create/extend logical volumes as needed and it can be found here. It is not 100% what I need but the core functionality is there and it works.

This also solves problems with few "special" applications that need their own partition to run and as I try towards simplicity I can now package the script into the autoupdate package (right... haven't mentioned it before also... need to fix it in near future...) and set a dependence for it. So to automate the install of the application I just add one row in the %pre section of the package and woala - new volume created in the install time :D

It also helps to resize partitions by simply updating the base package of my configuration that contains the sizes of the required volumes. this gives me the ability to reconfigure workstations in few days to new configuration and life can go on...

For conclusion - security is important, so no cutbacks should be made there, noexec and nodev are your friends - use them wisely, LVM is a great tool but it is not a magic bullet - adding an extra abstraction layer multiples the complexity of the system so use it carefully and when developing large scale infrastructure multiply the the count of computers with 1000 and think if the solution is easily managed then.

This script was built for CentOS 4.4 and tested on it - it will work on other distros but may need some modifications.

technorati tags:, , , , , , , ,

Blogged with Flock

Friday, May 25, 2007

Centos 4.4 and 4.5 apt problems...

Ok, so the first question would be "Why the f*** do you use apt for CentOS?!?!". Well the answer is simple - yum is too intelligent and is too big of a blabber, so its not useful for automation. Thats why apt is preferred - its dumb as a door knob, it works fast and it does not try to do things fully automatically (like up2date).

up2date is also an alternative that could be used but wen you one day discover that the uber expensive and uber busy system has crashed and its the fault of up2date upgrading the system automatically, well... no thanks...

There is a file conflict between the centos-release and apt - one of them has got too smart. In 4.3 the centos-release provided just basic necessities, but now also includes both yum and apt repository lists. And as apt has not been upgraded for a while, there is a file conflict at hand.



The bug has been reported and assigned in the centos bug tracker, but it looks like the fix wont come out anytime soon.

So here is my quick fix - rebuild the apt rpm. In the apt spec file line 122 is:

%{__install} -p -m0644 centos.list %{buildroot}%{_sysconfdir}/apt/sources.list.d/

remove or comment out this line and run:

rpmbuild -ba apt.spec

To make the build succeed I also had to do this "hack" on line 140:

%doc %{_mandir}/man?/* -> %doc %{_mandir}/man*

This will produce a new rpm that can be manually upgraded with rpm and the upgrade to centos 4.5 can continue. This will also give an opportunity that when the conflict is finally resolved the new apt will get upgraded or the old one can be reinstalled depends on who gives up the file...

Also a recommendation for the apt maintainer would be to include a buildreq. for "bzip2-devel" and "libselinux-devel"

Update:

As I was asked for my version of the apt.spec I uploaded it here.

technorati tags:, , , , , , ,

Blogged with Flock

Wednesday, April 25, 2007

Lightning Mutiweek fix in 60 seconds...

As I really cant live without it I decided to hack it. Here is my little hack step by step as it may be useful to someone until it gets fixed by the author. As I use Linux the hack is made under SuSE 10.0 Pro.

Not to create useless stuff in the home directory I recommend using the /tmp directory:

vahur@too:~> cd /tmp/
vahur@too:/tmp> mkdir lm
vahur@too:/tmp> cd lm
vahur@too:/tmp/lm> wget --no-check-certificate https://addons.mozilla.org/en-US/thunderbird/downloads/file/12248/lightning_multiweek_view-0.0.2-tb.xpi
vahur@too:/tmp/lm> unzip -x lightning_multiweek_view-0.0.2-tb.xpi
vahur@too:/tmp/lm> dos2unix install.rdf
vahur@too:/tmp/lm> cat install.rdf |sed -e "s#>2.0b1<#>2.0.0.*<#" > install.rdf
vahur@too:/tmp/lm> zip lm.xpi chrome/ltnmw.jar chrome.manifest install.rdf

Here is the long version: I create a folder called "lm" in the tmp directory, download the original xpi from the mozilla site with wget, extract all the files with unzip, as the file was created under windows we need to convert it to unix before editing (lowers the risks of random character interfering), replace the old version with new one with stream editor sed and the last thing is to zip it back up :)

Thats it - just install it as a normal extension in Thunderbird. Works 95% - may mess up preferences menu a litle- use at your own risk.

I wish all my work would be that easy...

technorati tags:, , , , ,

Blogged with Flock