Google Search

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

Thursday, July 19, 2007

Adobe Reader and Fedora 7...

Like always, nothing is without problems - this time is not an exception.

So as everybody has heard the Linux AdobeReader_enu-7.0.8-1 has some holes in it and the 7.0.9-1 is available. So today I thought that it would be a good idea to upgrade my old version to the new version.

Lets just say it did not go as expected....

Its good that Adobe makes an effort to provide the reader in rpm format, but this time I ran into a small problem. It seems Fedoras libgtk-x11 version has gotten a bit too new version. The "rpm -Uvh" went fine, nut when I tried to launch the reader form the start menu nothing happened. After few tries the reader didn't start - no errors nor warning were displayed, so the easiest thing to do was to open my favorite tool the console :)

When starting the "acroread" script from the command line it starts spitting out "expr: syntax error" errors. This usually means that the evaluated expression is faulty ore some values have not been assigned. Right it just couldn't go without the pain of debugging...

Oh well, fairing up the vi and opening the "/usr/local/Adobe/Acrobat7.0/bin/acroread" showed too much info to start with. First step was to debug the script to see where it crashed. Just by replacing the first line "#/bin/sh" with a bit more intelligent shell with debugging output "#/bin/bash -x" showed me the problem location.

It looks like the "base_version" variable will get an empty value witch on the other hand makes the loop to go wild. So to fix it we have to look at the "get_gtk_file_ver()" function.

And here it is - on line 418 - "echo $mfile| sed 's/libgtk-x11-\([0-9*\).0.so.0.\([0-9]\)00.\([0-9]*\)\|\(.*\)/\1\2\3/g'". This regex expects to find the version <= 900 but in fedora it is 1000 so we need to mod it to look like this "echo $mfile| sed 's/libgtk-x11-\([0-9*\).0.so.0.\([0-9]\)000.\([0-9]*\)\|\(.*\)/\1\2\3/g'". This one extra zero will make it run nicely and this method is applicable on one machine at a time, but when going full scale the regex should be modified to look for 2 OR 3 zeros, so lets hope that Adobe fixes it soon.

This "bug" also hunts the CentOS 5 and RHEL 5 and maybe some other newer distros.

So hope for the best and a quick fix from Adobe :)

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