I was driving. 90 kmph.
Suddenly I have been flashed. Then flashed again. Then some horns.
I panicked a little and pulled right to make space for the monster car that wanted to surpass me.
Voom!!!
It surpassed me in a blink.
I had just a little time to see its registration plate. It was reading ASS.
Just perfect.
20091105
20091031
Upgrade 9.04 to 9.10 headlessly
I did those steps from SSH (although not recommended).
1. apt-get update -> all repos updated
2. apt-get dist-upgrade -> somehow not necessary
3. do-dist-upgrade - the magic begins here
Respond to the questions according to the customizations you've done on your system.
In my case I've chosen to keep my locally installed versions.
At the end DO NOT REBOOT the system (do not answer Y at the final question).
4. Edit the /boot/grub/menu.lst and check if the serial console lines are still present. If not add them by hand before the beginning of "AUTOMAGIC KERNEL" section.
5. Now it would be safe to reboot... Good luck.
If you want to upgrade to grub2 (as I did) do the following:
1. apt-get install grub2
2. Edit the /etc/defaults/grub to something as:
The bolded lines are my modifications for the file.
3. Run /usr/sbin/update-grub as advised.
1. apt-get update -> all repos updated
2. apt-get dist-upgrade -> somehow not necessary
3. do-dist-upgrade - the magic begins here
Respond to the questions according to the customizations you've done on your system.
In my case I've chosen to keep my locally installed versions.
At the end DO NOT REBOOT the system (do not answer Y at the final question).
4. Edit the /boot/grub/menu.lst and check if the serial console lines are still present. If not add them by hand before the beginning of "AUTOMAGIC KERNEL" section.
5. Now it would be safe to reboot... Good luck.
If you want to upgrade to grub2 (as I did) do the following:
1. apt-get install grub2
2. Edit the /etc/defaults/grub to something as:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT="3"
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=serial
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,38400n8"
GRUB_SERIAL_COMMAND="serial --speed=38400 --unit=0 --word=8 --parity=no --stop=1"
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entrys
#GRUB_DISABLE_LINUX_RECOVERY="true"
The bolded lines are my modifications for the file.
3. Run /usr/sbin/update-grub as advised.
20091030
Finally SnowLeopard in VMWare
It works witn VMWare 7 in Ubuntu 9.10.
I had quite a trouble to get it right. The main differences are:
1. The name of operating guest system should be changed into "darwin10-64"
2. the VMWare tools iso images should be upgraded to Fusion 3 or the one you can find on the net (see the InsanelyMac forums).
http://sourceforge.net/projects/vmsvga2/files/is offering both a better video driver and usable sound with Ensoniq emulation,
There is a bug - I do nyt know if in VMWare or drivers - but the screen shots/Grab are not working.
20091025
Movies in weekend
1. Blidness
An adaptation of Jose Saramago's novel. A bitter look on how mankind reacts in a situation of crisis. Some hard scenes depicting degradation.
2. Antichrist
Again, not an easy movie. Interesting story - where Antichrist really is? Lars Von Trier dives deep in the human mind and reveals some dark sides of it.
An adaptation of Jose Saramago's novel. A bitter look on how mankind reacts in a situation of crisis. Some hard scenes depicting degradation.
2. Antichrist
Again, not an easy movie. Interesting story - where Antichrist really is? Lars Von Trier dives deep in the human mind and reveals some dark sides of it.
20091022
How not to use RPM
This one would better go to the dailywtf.
In order to achieve some kind of multiple installed versions of the same package some guy thought a "wise" solution.
Every release of package foo will install itself in /opt/foo/<version> and will create a symbolic link as /opt/foo/current -> /opt/foo/<version>. Every time the package would be installed with rpm -ivh foo-<version>.
On uninstall the rpm -e will erase the latest version and move the link to the previously installed one.
In my humble opinion this is not really the way RPM was meant to be used. The idea behind RPM is to offer consistent package management and not handling concurrent versioning for packages. Upgrading is handled by the package manager itself via internal mechanisms.
The most flawed part of this approach is that human errors would compromise this kind of multi version setup for packages in a manner that automated recovery would not be possible.
The management of concurrent versions of the same package proved - at least for me a real pain in the ass over the time therefore I am more than reluctant to apply such a scheme.
In order to achieve some kind of multiple installed versions of the same package some guy thought a "wise" solution.
Every release of package foo will install itself in /opt/foo/<version> and will create a symbolic link as /opt/foo/current -> /opt/foo/<version>. Every time the package would be installed with rpm -ivh foo-<version>.
On uninstall the rpm -e will erase the latest version and move the link to the previously installed one.
In my humble opinion this is not really the way RPM was meant to be used. The idea behind RPM is to offer consistent package management and not handling concurrent versioning for packages. Upgrading is handled by the package manager itself via internal mechanisms.
The most flawed part of this approach is that human errors would compromise this kind of multi version setup for packages in a manner that automated recovery would not be possible.
The management of concurrent versions of the same package proved - at least for me a real pain in the ass over the time therefore I am more than reluctant to apply such a scheme.
Things to be changed
I had today one of the most bitter experiences from all my career in ALU.
The idea was to offer a HA web service to a 3rd party application.
I proposed a HAProxy based solution that would hide the internal structure of the media server cluster offering to the client application a single and reliable entry point. This would be in my opinion the standars approach for this kind of setups.
One of my line managers (not the direct one) had a brilliant idea. He suggested that the client should modify its application and add code that will do the load balancing and failover inside its software.
In vain I have tried to explain to him using technical and economical arguments that this is really not a good idea, he continually pushed its own vision.
I really do wonder how ALU will realize the so called "Application Enablement" with this kind of managers? I think that we have a looooong way to come until this wish would come true. The reason is not the technical competence - there are a lot of very talented people in ALU but the managerial lack of vision and the intestine wars.
As a conclusion - management has to be changed.
In the meanwhile have a look at http://www.openapiservice.com - it is one of ALU's first attempts to open towards web.
The idea was to offer a HA web service to a 3rd party application.
I proposed a HAProxy based solution that would hide the internal structure of the media server cluster offering to the client application a single and reliable entry point. This would be in my opinion the standars approach for this kind of setups.
One of my line managers (not the direct one) had a brilliant idea. He suggested that the client should modify its application and add code that will do the load balancing and failover inside its software.
In vain I have tried to explain to him using technical and economical arguments that this is really not a good idea, he continually pushed its own vision.
I really do wonder how ALU will realize the so called "Application Enablement" with this kind of managers? I think that we have a looooong way to come until this wish would come true. The reason is not the technical competence - there are a lot of very talented people in ALU but the managerial lack of vision and the intestine wars.
As a conclusion - management has to be changed.
In the meanwhile have a look at http://www.openapiservice.com - it is one of ALU's first attempts to open towards web.
Subscribe to:
Posts (Atom)
