Google Search

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

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

Sunday, October 14, 2007

Problems with bluez and bluetooth headset...

For some time I have been tinkering with my Jabra BT500v and the bluez bluetooth stack. Under SuSE I had only one way of getting it work - bluetooth-alsa with all the extra packages to get it to work (sbc, plugz, btsco, the snd-bt-sco kernel module, and the HCI SCO patch for the kernel). All was simple/(err - possible) and kinda worked (patching the kernel was a pain tho). The bluez was really old (2.19 if I remember correctly) so there were no choices really.

When I moved to Fedora 7 I had everything set to rebuild everything necessary to get it running again. As Fedora 7 should have a new BT stack I would not have to do all the things again as starting from 3.16 you don't need them any more. To my surprise I discovered that Fedora 7 had only 3.9 version of bluez. Not a problem - rebuild with the latest sources - 3.20 is the latest so should be the best so it is a prime candidate.

At the beginning I thought everything was fine (well, after tinkering with the spec file a little). Well I got the amarok to play, I got vlc to play, I got the mplayer to play but what I did not get to play is Skype. The thing I was trying to use the headset with. The thing to what the headset was meant to be used for.

Another blow to my ego was today when I updated my system today and got a kdebluetooth update (1.0 beta 8). After a boot it could not even start - just plain sigserv at the login. Right. The first thing that comes to my mind is that kdebluetooth is liked against an older version of the api that is been redesigned or removed from new version. Tho the interesting part is that the older version worked fine with new bluez, so I'm a bit confused at the moment. Anyway I went back to the 3.9 bluez until I figure out which is the reason for the crashes.

For the moment I have 43 self built/patched rpm's running on my system and no way to track them expect the gray matter called the brain. With every rpm I customize/upgrade for my needs grows the need to track the mainstream for bug fixes and security fixes. With this hack I tried to ease my life by replacing the tracking from 6 to 2. But it seems Ill have to do it the old way or wait for Fedora 8 to come out to make my life little easier. Then again if I can't get Skype running with new bluez I have to go back again. Anyway I'm back in the point where I started.

Anyway hers some links that can help  (or make life more complicated): here, here, here, here, here, here, here, here, here and here.

If I figure out how to how to get it running Ill add another post.

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

Tuesday, October 9, 2007

Linux Bioapi on Fedora 7...

I have been using bioapi and pam_bioapi on my T43p ThinkPad under SuSE 10 Pro for the past 2 years and been happy with it. No annoying password prompts to type your passwords and well typing your password to the screen saver prompt... I wont go into that...

As always all good things have to end sometime, so went my bioapi when I replaced my SuSE with Fedora 7. The reason to switch to Fedora was forced upon me by the all famous evil MicroSoft with its all famous MSN version upgrade. As I hacked the Kopete as much I could the old libs in SuSE were not just up to the task of plain rebuild to a newer version.

After backing up the usuals about a week ago I reinstalled my laptop. No big deal. Around half an hour of installation, another half a hour to strip all of the gnome components and yum junk and another 2 hours of installing and configuration of KDE. All was well untill I remembered the most important thing - I didn't backup my own rpm's. And this included the bioapi and the pam module. After about 20 times entering the password for screen saver the old finger swiping reflex started to come back. Crap...

Oh well - I had to start from the beginning.

The first thing to do is the bioapi lib's. Everything is straight forward until I started packaging it. Google was no help - the best thing google could offer was the "--with-Qt-dir=no" configure option, but that was not acceptable for me. I needed the Qt for my screen saver so after little debugging I found the evil source of the Qt compile errors. It is an rpm macro

# here is a hack
# in /usr/lib/rpm/rpmrc line 18
# replace optflags: i386 -O2 -g -march=i386 -mcpu=i686
# with optflags: i386 -O2 -g -march=i386

Every time when compiling the configure test part spitted out error messages about mcpu being deprecated and the test failed.
As I'm low on time for the time being I just used the hack and Bingo - every test was passed successfully.
As this is literally an hack I wont be using it for other packages until needed again, but basically its biapi's testing problem and currently I don't have time to start fixing it. The i386 rpm is here and the source rpm is here. One day I will move the udev rules the the bioapi package, but not right now.

Ok, so everything should be set to run the bioapi right? Well, not really - the one thing that I had totally forgotten was the UPEK inc. tfmss bsp api. This was the most frustrating thing as I had forgotten about it totally. As it is distributed under property license and it seems everyone have drawn back their binary and source packages I'll just publish the spec to build the rpm and the config. It seems that UPEK is forcing their license, so here is the spec and here is the configuration fail. A simple rpmbuild will build the package that can be installed. For licensing read the SDK EULA, and thus I'm not responsible for whatever you do after building the package - this information is provided AS IS, without any warranty by the packager.

The final thing is the pam_bioapi package. This packaged nicely without any hiccups. But then the problems started. It seems that the new version of the module is only capable of using SQLlite3 back end and not the old flat bir file based back end (atl east I dint find an option to enable it). Thus I'm still without a working bioapi. Oh well - back to the old reliable 0.2.1 it went. After little patching it built nicely. But the problems did not end - I started to get bioapi errors. "BioAPI error #194d" - google did not give any good answer to it except it is a permissions error. After some debugging I found out that the error is cosed by wrong permissions on the usb fingerprint reader device. By default it is owned by root and writable by user root - naturally I'm not a root on everyday tasks so I did some magic and got it running. To make the changes permanent I wrote a little udev rule that makes the device to be owned by group "fingerprint" and made it writable by the group so it started to work nicely. Here is the rpm and here is the source rpm.

I also included a mini "howto" on how to get it to work fast and easy. I also may be missing some libs and deps from the packages as my systems are always bloated with libs and development headers, but the examples are here, so have fun everybody.

Some useful links allso: udev rule writing, file permissions in linux, a good howto on enabling fingerprint reader, the bioapi error I mentioned before, another error symptom, Novell way of doing things, the TFMSS fingerprint reader api.

Thats about it for today - have fun and play nice :)
PS! Great thanks the the people in UPEK for releasing the Linux port for the fingerprint reader api :)

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

Thursday, May 3, 2007

Horror of menu editing...

Have You ever had the need to edit your application menu or create new links to it? Click... Click... Drag... Drop.. Save! Thats how you would do it in KDE kiosk mode. As a result you get a custom menu file that represents the applications menu. Now in Gnome it isn't that easy - you need to create the .desktop file manually with your favorite menu editor (as gnome does not have a kiosk mode nor a menu editor). Ok so far so good - You have just created a new menu application link with that nice custom menu icon and the nice parameters that will run the app just nice.

How about when you want to create an sub menu or two? So you have already created the .desktop files with the right categories - lets assume we need to create sub menu under applications "SubA" and under that a sub menu "SubB". So the .desktop links have categories "Applications;SubA;SubB". Simple eh? Well not really. You also need to create the .directory entries. What they are useful - I don't know - possibly to just add a comment to the menu, or maybe to just add the icon to the folder. Nop! They contain the category tag. All that hassle to just get a category tag?!?!?

So You have the .desktop and the .directory files in place, but the menu is still not showing the right subtree and the icons come under "Other" menu. So whats missing? The menu file! Who would have guessed that you need to create another file JUST to get the sub menus! Ok, you create the xml menu file structure consisting of applications->SubA->SubB menu directories. so now you have 4 files: 1 for the application, 2 for the directories and 1 for the menu. With anticipation you expect to have a new sub menu structure created and with even bigger bitterness You will discover that the menu does still not show up!

The missing link is the inclusion of the menu into the APPLICATIONS.MENU?!?!?!?!? this is just crazy - why can I just create a menu file and it would be included into the menu structure automatically??? Well it seems there is "start-here.menu" witch includes the rest of the menus. So to finally get the menu structure you want you edit the applications.menu file and add to the end this line "<MergeFile>my-custom.menu</MergeFile>". With the greatest anticipation you log out, for insurance kill the X server (I recommend this as several times the gconfd daemon did not die after just plain old log out so ->Ctrl+Backspace), log back in and with anticipation open the applications menu. Woala - our SubA and SubB menus are there. Now the horror is still not over - we need to make a script that checks if our menu is included in the menu on entering run level 5 or on boot. The simplest way was not with some xml parser but a simple perl script that would read the menu file into array, join the array into an long string and with regular expression look if the string contains the menu file, if not do a little preg_replace known merge file and add our line. Woala - now the process is complete. Btw - in KDE there is a merge directory from where you can automatically merge menu files into the tree...

So if You have red so far You might ask why the hell I'm going into all this trouble with the menu's and files - well how else you can put the files into an RPM. Again You might ask why would someone need to do this ever? And again I would answer - to deploy this menu structure on around 1000 workstations. RedHat and Novell enterprise linuxes are excentric on gnome, so I don't understand why??? They promote gnome because gnome is absolutely minimalistic, so the end user cant mess things up with "accidental" configuration. I use KDE on all my computers and I have never run into problems running and packaging KDE in kiosk mode.

So here are some useful info on menu editing and structures: basic, example, .menu file structure, .desktop files, .directory files and menu file structure.

Here are some suggestions on how to improve the "functionality" of the menu editing from the enterprise level:

1) as gnome seems to be all in for the xml - make handlers for xml based desktop and directory links - it isn't as fast as stream parsing a file, but still computers are fast enough so they can be parsed once and put into the memory.

2) drop the stupid menu hierarchy with all the inclusions and stuff. The start-here.menu can be there but it should contain only folder links to folders that contain the desktop files (remember - they are in xml so they can contain their own menu structure!!!). This would obsolete the need the create 5 files to just create a link into sub menu of a sub menu - I know its against the Gnome philosophy to keep everything minimalistic, but from the enterprise point of view it would be minimalistic. We could just point the start-here menu to look for the menu structure from another location and woala - perfection!

3) if the 1. suggestion is too much work, the menu file in it self could be put together from the xml files - merging xml files is simpler than building 1 stream parses for desktop files and another for directory files. This way we can join the directory entries and the desktop links into one folder so managing them would be easier.

Too long... Too boring... Maybe useful...

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

Tuesday, April 24, 2007

x86 on a POWER...

It seems like IBM has few tricks in their sleeves. Normally there would not be an efficient way to run Linux on their mainframes thanks to their fully hot-swap architecture. Fried a CPU or a RAM? Maybe even a mainboard? No problem - they are hot swappable :)

More info on the architecture here. Normal small to midrange enterprises usually don't need them as they can deploy grid architecture, but there is wide range of services that need to maintain around 99.9+% of uptime with high loads. Here comes the System p to fix most of the problems. As grids are powerful, they have some shortcomings. They don't provide enough power for high end calculations as they usually are linked with up to 1gbit interfaces - the system P is on the other hand interlinked with maximum theoretical bandwidth of 30gbit or more interlinks. It also provides the hot swap for all components (well almost all) - I haven't looked into System p design for a long time, but the only part that was not hot swap was the interconnect plate around 3 years ago. Usually these system sun without problems (after they have been set up properly) 6+ years and when the crash happens its total as people who set the system up most likely have moved up the food chain and got a better job or just wont remember how to set them up. Here is where the grid is more fault tolerant - you can loose some of the nodes without any impact on overall performance (and I don't mean "2 pc clusters"). Grid hardware is also cheaper (usually normal PC's or racked server or blades) interconnected with ether 1gbit full duplex single mode fiber, 10gbit multi mode dark fiber, or when the requirements are high enough a profession interconnect.

Anyone wanna donate an IBM System p5 595 with 64x2.3GHZ CPU, 2TB RAM and a 28.1TB storage node for hmm... testing purposes? :)


technorati tags:, , , , , , , ,

Blogged with Flock