Posts filed under ‘SuSE’

VMware will lockup when trying to click the browse button – Solution

VMware will lockup when trying to click the browse button on SLES10 SP1. Very frustrating bug but fortunately there is workaround:

  1. Open a terminal and su to root.
  2. Change to the directory.
    cd /usr/lib/vmware/lib/
  3. Rename the file within that directory.
  4. Create a new soft link for this file.
    ln -sf /usr/lib/
  5. Now change the the directory.
    cd /usr/lib/vmware/lib/
  6. Rename the file within that directory.
  7. Create a new soft link for this file.
    ln -sf /lib/
  8. Restart VMware and you should now be able to use the browse option.

More information about this issue here.


March 28, 2008 at 11:12 am Leave a comment

Daylight saving time

Daylight savings time change is upon us again. Worth taking some time to make sure the timezone pacgages are updated.

For SLES10: timezone-2.4-31.43.3
For SLES9: timezone-2.3.3-98.86.8
For SLES8: timezone-2.2.5-261

I went back and checked timezone patches released during last year. You may be affected if your server is in one of the following regions:

  • America/Caracas
  • Asia/Damascus (time change in effect since start of November)
  • America/Havana (ditto)
  • America/St_Barthelemy
  • America/Marigot
  • Africa/Cairo
  • Antarctica/McMurdo
  • Asia/Tehran
  • Asia/Gaza
  • Australia/Adelaide, Australia/Hobart, Australia/Melbourne, Australia/Sydney, Australia/Lord_Howe
  • America/Indiana/Tell_City (new)
  • America/Indiana/Petersburg
  • America/Sao_Paulo, America/Campo_Grande, America/Cuiaba
  • America/Caracas
  • Asia/Pontianak, Asia/Makassar, Asia/Jayapura
  • Asia/Hovd, Asia/Ulaanbaatar, Asia/Choibalsan *
  • Asia/Damascus *
  • Pacific/Auckland, Pacific/Chatham *
  • Australia/Adelaide, Australia/Hobart, Australia/Currie, Australia/Melbourne, Australia/Sydney, Australia/Broken_Hill, Australia/Lord_Howe *
  • Europe/Istanbul / Asia/Istanbul *
  • America/Indiana/Winamac * (new timezone)
  • America/Pangnirtung, America/Iqaluit, America/Rankin_Inlet, America/Cambridge_Bay, America/Yellowknife, America/Inuvik
  • America/Resolute * (new timezone)
  • America/Havana *
  • America/Port-au-Prince *
  • America/Tegucigalpa *
  • America/Grand_Turk *

And finally quote from the timezone release notes:

This patch updates the glibc timezone database according to a last-minute change of the time shift date by Venezuelan government from 2008-01-01 to 2007-12-09. Venezuela will move from UTC-4:00 to UTC-4:30.

Seems like rush decision to change timezone by …half an hour. What is the rationale here?

February 18, 2008 at 3:51 pm Leave a comment

Wrong system time and Lotus/Domino

Domino appears to very sensitive when started with wrong date, therefore it is worth considering the following precautions on a server hosting domino messaging system.

1.Make sure ntp service starts before domino. Look at the sequence in /etc/init.d/rcX.d directory

lrwxrwxrwx 1 root root 9 Feb 18 10:24 S10domino -> ../domino
lrwxrwxrwx 1 root root 8 Feb 18 10:25 S12xntpd -> ../xntpd

lrwxrwxrwx 1 root root 9 Feb 18 10:24 S12domino -> ../domino
lrwxrwxrwx 1 root root 8 Feb 18 10:25 S12xntpd -> ../xntpd

(with the same priority numbers (12) domino still will start ahead of xntpd as the startup sequence will be determined alphabetically in this case (d before x).

lrwxrwxrwx 1 root root 8 Feb 18 10:25 S08xntpd -> ../xntpd
lrwxrwxrwx 1 root root 9 Feb 18 10:24 S12domino -> ../domino

2. SuSE Enterprise Server has a configuration parameter that should force ntp to adjust time in one step during boot. Enable the following in /etc/ssyconfig/ntp:

3. Additionally you may consider putting fail-safe check into start-up scripts for ntp and domino to prevent mail server starting in cases when there is possibility NTP is not functioning correctly (either due to network problems or misconfiguration). This fail-safe measure will favour not starting domino over risking starting it with incorrect date.

This is how it should work:

In case of NTP failure:

  • NTP starts before Domino and in case it fails to fetch time from external time sources it will create file /var/log/xntp which would indicate ntp failure.
  • Domino startup script will check for existence of /var/log/xntp, print current time both for hardware clock and system and asks user to confirm desired action.
  • At this point user can override default action if satisfied that the time is correct. After 60 seconds startup will proceed with the default setting which is not to initialize domino services.

In case NTP working correctly

  • NTP sets the correct time and as a result /var/log/xntp file will not be created
  • Domino startup does not detect /var/log/xntp file and the default action in this scenario is to proceed with domino startup. User still will have 60 second to override default action.

The following should be added to ‘start’ section of domino initialization script (/etc/init.d/Domino):

if [ -e /var/log/xntp ]; then
echo “NTP server failed to contact external time source.”
echo “Domino startup will be skipped in order to prevent it running with incorrect date”
echo “Your current System time is:”
echo “Your current Hardware Clock time is:”
sudo /sbin/hwclock –show
echo “Please verify the System Time and Hardware Clock show correct date”
while true

echo -n “Please confirm you want to start Domino at this time (y or n) :”
echo ” ”
echo -n “Boot process will continue in 60 seconds. Current default value is set to: $CONFIRM”
echo ” ”
read -t 60 CONFIRM
case $CONFIRM in
y|Y|YES|yes|Yes) break ;;
echo Aborting – you entered $CONFIRM
*) echo Please enter only y or n
echo “You entered $CONFIRM. Continuing …”

February 18, 2008 at 2:54 pm Leave a comment

Recent Posts