sapinst hang at "import java dump" stage when installting SAP NetWeaver 7.0

When installting SAP NetWeaver 7.0 on HP-UX 11.23, the sapinst comes to an halt. A java process "/opt/java1.4/bin/java -classpath /tmp/sapinst_instdir/NW04S/SYSTEMORA/CENTRAL/ASinstall/sharedlib/launcher.jar... uses 100% CPU not not doing anything)

Your JDK is 1.4.2_10

there is a problem in the Java VM 1.4.2_10 that will cause the installation to hang at this stage. It has been reported on Sun Solaris, but not on HP-UX yet. Apparently it affects HP-UX (IA64) too.

So, upgrade to 1.4.2_13 (patch 14,15,16 has know issue with Kerbose authentication). 1.4.2_17 should work too. But don't forget the installation guide tells you Java 5.0 is NOT supported.

OK Good luck.

VMWare player

It may because of the opensource EMUs like QEMU, VMWare player 2.0 is released as open source software.
To retain some value to its VMWare Workstation, EMC kept VMWare player to be "play" only, you don't have GUI to configure a Virtual Machine.

Ironically, the configuration of the VM (the vmx file) is a plain text file. So you know if you are handy enough, you can do without a GUI. (well, you'd better by their stuff as I own their stock).

For you to get a quick jump start on that, here is a sample vmx configuration file enables most (read: not all) of the features available to VMWare Player 2.0


### sample vmx file ###
config.version = "8"
virtualHW.version = "4"
scsi0.present = "TRUE"
memsize = "512"
MemAllowAutoScaleDown = "FALSE"
ide0:0.present = "TRUE"
ide0:0.fileName = "GL_WXP2C623A.vmdk"
ide1:0.present = "TRUE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
floppy0.fileName = "A:"
ethernet0.present = "TRUE"
usb.present = "TRUE"
sound.present = "FALSE"
sound.virtualDev = "es1371"
sound.fileName = "-1"
sound.autodetect = "TRUE"
displayName = "SAP IT Office Image - GL_WXP2C623A"
guestOS = "winxppro"
nvram = "winxppro.nvram"
ide1:0.autodetect = "TRUE"
floppy0.startConnected = "FALSE"
workingDir = ""
toolScripts.afterResume = "TRUE"
toolScripts.beforeSuspend = "TRUE"
ide0:0.redo = ""
ethernet0.addressType = "generated"
uuid.location = "56 4d 3c e6 4c ee 29 a3-f6 26 00 51 eb 87 50 70"
uuid.bios = "56 4d 3c e6 4c ee 29 a3-f6 26 00 51 eb 87 50 70"
uuid.action = "create"
ethernet0.generatedAddress = "00:0c:29:87:50:70"
ethernet0.generatedAddressOffset = "0"
ide1:0.startConnected = "FALSE"
tools.syncTime = "FALSE"
annotation = "SAP IT Office Image - GL_WXP2C623A"
floppy0.present = "FALSE"
isolation.tools.hgfs.disable = "TRUE"

ethernet0.connectionType = "bridged"

checkpoint.vmState = ""

virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "manual"

extendedConfigFile = "winxppro.vmxf"
sharedFolder.option = "alwaysEnabled"
sharedFolder0.present = "TRUE"
sharedFolder0.enabled = "TRUE"
sharedFolder0.readAccess = "TRUE"
sharedFolder0.writeAccess = "TRUE"
sharedFolder0.hostPath = "C:\"
sharedFolder0.guestName = "C"
sharedFolder0.expiration = "never"
sharedFolder.maxNum = "1"

Microsoft IntelliMouse for Bluetooth on Mac OS X Tiger

It has long been talked about: Microsoft IntelliMouse for Bluetooth and Mac OS X.

I can confirm 2 things for you:
1) the IntelliMouse DOES work with Mac OS X. And its dongle works in Mac OS X too. However, since the dongle is Bluetooth 2.0, it only works in Tiger, not Panther. And it's right, you don't need special drivers, Mac recognize it.
2) The dongle does NOT support headset profile. Hardware wise not. While in Windows, the MS driver does not tell you if this is a driver problem or a hardware issue. Mac tells you right a way. "The hardware does NOT support headset profile". So save you some time, don't bother download wincomm etc.

One good thing about Mac is it comes with generic drivers for many devices. Nowadays, most brand-named products are actually OEM of some very generic stuff and you know Microsoft is not a chip maker, so. . .

Yeah, sure enough, once you connect your MS Bluetooth 2.0 dongle for the mouse to Mac OS X Tiger (either intel or PowerPC) it is recognized and started. You can pair the mouse easily.

When you try to add device and choose headset, you will be told the hardware does not support this profile.

So, kudu to the Mac! You can use Microfot IntelliMouse for Bluetooth even though Microsoft says "support Windows ONLY". Yeah! Who trust Microsoft! Well holdon on that statement, Microsoft said the dongle does not support headset, and it is true, it does not!.

Compile WINE on Mac OS X Tiger

The WINE is more practical than ever on Mac OS after the Apple Inc. shifted to Intel platform.

There was Darwine (maybe I should say IS, but I haven't seen any update from Darwine for over half a year now). Darwine is meant for PowerPC Macs - because the lack of binary compatibility, Darwine needs a PC emulator to run Windows applications on PowerPC Macs. (It still better than running a virtual Windows - you don't need the Windows license to run WINE or Darwine.

Things are much less complex now, thanks to the moving to the Intel CPUs. At the core, a Mac is binary wise compatible with a PC running Windows. All you need to run (most) Windows applications on a Mac OS is WINE.

However, there are not many doc out there telling people how to build WINE on a Mac.
I guess it is TOO easy for the hard-core WINE "drinkers" and there is no need for a step by step doc for building it. However, a lot of Mac user are not as CMDLUI (Command line User Interface) as Linux users, and I figure it may be helpful if we have a (brief) doc helping users to build WINE on Mac OS X.


Let me try to make it easier for you here (Everything is done on Mac OS X 10.4 Tiger).

1) you will need X11. Remember that WINE is written for Linux originally, and it use the de facto GUI standard - X11. While Mac OS X comes with X11 (Mac is based on Darwin - a variance of FreeBSD), it is not the default Apple GUI (which is AQUA). You can check if you have X11 by open the Finder, under Applications, Utilities, you an app called X11 sitting there. If you don't see it there, you need to install it by pop in the Mac OS X installation DVD, run the Optional Packages, and select X11 in it.

2)You will need Xcode with X11 SDK. These are the tools you use to compile and build WINE. It is freely available to Mac Users (it is GCC 3.3 and 4.0 at the core). One thing to note though, you need Xcode 2.4.1 or up. The Xcode came on the DVD will give you Syntax error ( unknow structure x86_DEBUG_STATE32) while compiling mach.c.

A good thing about Xcode is it is so easy to use, it nearly make you forget you are "developing" something. Don't be scared if you never wrote any program, it is really simpler than Microsoft Office.

3)You need Freetype 2.05 or up. You can either use a package (Macport/DarwinPort or fint), or you can download the source and build your own. I prefer download and build my own (probably because of my Linux background).

4)You will need Fontforge. Again you can chose to install a package or build it from source. Again, I prefer build from source.

5) You will need to change the PATH before you start ./configure of WINE, or it will not be able to find X11 and freetype. export PATH=/usr/X11/bin:$PATH.

6) now some basic things that Linux guys will laugh at me for writing about it. you now download wine, extract it to a directory, go into that dir and run "./configure"

7) make sure ./configure shows you no error, at the end it tells you now run "make depend && make". do so.

8) if everything returns clean, you should install wine to /usr/local/ by running make install.

9) now you can test your wine by running ./wine notepad.exe (you need to copy the notepad.exe from a real Windows machine).

10) optional but suggested: add "/usr/local/bin" to your PATH.

Upgrading to SAP ECC 6.0 with error in RSUVSAVE phase.

YOu may see error check log failure "PSUVSAVE\.SID".
The message inidicates the filename is not right (the "\" before the ".") make you think the upgrade assistant (SAPup actually) is looking for a file with "\" in its name.

That's misleading. It is just a Unix escape character that was not removed in the error message.

This actually because the DIR_PUT was not set right (check your DEFAULT.PFL) the upgrade always check for the log files in /usr/sap/put/log dir, but most of the case the default DIR_PUT is the transport dir.

Also, you NEED to bounce your SAP instance for this change. While the UA will go on right after you change the DEFAULT.PFL without recycle the instance, it will give you error like this one later.

So, check your profile as early as you can, and bounce your instance if you need to.

Perl ERROR: Can't call method "mail" on an undefined value at smtp.pl line 10.

As confusing at it sounds, this means your smtp object has not been sucessfully constructed. I know the error message reads more like a problem with the "mail" method, but it is actually because the SMTP obj was not initialized.


Try this:
#!/usr/bin/perl -w
use Net::SMTP;
$smtp_test = Net::SMTP->new('smtp.mail.com',
Timeout => 30,
Debug => 1,)|| print "ERROR creating SMTP obj: $! \n";
print "SMTP obj created.";

If you see "ERROR createing SMTP obj" then you know the SMTP object is not created correctly.


Some times, this is because the SMTP package was not installed right, some times, it may because the SMTP protocal is blocked, sometimes it means something else is wrong.

QEMU TAP bridge network configuration

Well, it is interesting to see how many posts out there on the web deals with this topic "configure tun/tap bridge for QEMU". Yet, I have to write one more page about it.

OK, here is why: 1st while most of them are informative, there has been no SINGLE page I read (dozens, if not more) that really helped me to configure the thing easily. 2nd, once I figured it out, it is unbelievable EASY!!! - it's just the lack of documentation make people stump. Last but not least, there are some docs out there are incorrect or misleading. While following their instruction may lead to a working configuration, it will cause you trouble later, or lead you to a wrong route when troubleshoot.

Here is what would have saved my 4 hours:

First and foremost, bridge in this case is really the ISO term of bridge. It is not something specific for QEMU. Actually, the bridge functionality is provided by Linux kernel, not QEMU - some docs on the net may lead you to believe bridge is a QEMU feature (well, QEMU does have this feature - by utilizing Linux feature, instead of providing the functionality itself).

Back to QEMU network 101, there are several ways to configure QEMU network, the default which happens to be the easiest is "-net user" this is a very neat function implemented by QEMU - it creates a virtual router (with virtual DHCP server, virtual DNS, etc) it uses 10.0.2.x address.
Just think about a home high-speed internet router, it gives you NAT addresses to all your computers at home, the router then connects to the WAN (read internet here) and forward traffic back and forth between your computers and the internet. The user mode QEMU does the same thing, QEMU gives your "Virtual computer" a "virtual IP - i.e. 10.0.2.15" and QEMU talks to the real network.
This usually is good enough if you only surf the internet from your virtual computer. However, since not every application work with NAT, (and since most of the home network already use a NAT to share one real internet IP, the virtual computer is behind 2 NATs). You may want some "direct" connection for your virtual computer.

Now, here comes the confusing part. QEMU supports tap device ("-net tap" instead of "-net user"). And its official document says "... you can then configure it as if it was a real ethernet card." But how? if everyone is as familiar with TAP device as the QEMU author, probably I won't need to write this (at least it would have saved me 4 hours if someone has written something like this :-)


TUN/TAP device is "virtual ethernet driver", the official doc of tuntap.txt says: "TUN/TAP provides packet reception and transmission for user space programs. It can be seen as a simple Point-to-Point or Ethernet device, which, instead of receiving packets from physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program."

So, QEMU runs on the real computer as a program, can write packets to the TAP device. That's cool! QEMU can simply write all the virtual computer generated packets to the TAP device and forward packets to the virtual computer, right? Right! but it is only sufficient if your virtual computer wants to talk to the real computer it runs on ONLY. Because once the packets from the virtual computer reaches the TAP device, how does Linux know where to send the packets? That's not part of the TAP device functionality.

So here comes bridge.
The bridge is (sort of) the most reliable way of connecting your virtual computer to the real network. Unlike some docs on the internet suggested - you do NOT need to configure IP for the TAP device for the bridge to work, no IP forwarding, routing needed! That's why I said "1st, bridge is ISO bridge!" at the beginning. Because packets are forwarded at Ethernet level (layer 2 in terms of ISO standard), bridge does not even care about IP (sort of, you will see why you still need to manipulate your IP a little bit later.

For those who are not familiar with Ethernet bridging (this is not a scientific definition, rather it is an example tries to help people get a feeling of what bridge is): bridge is a device have 2 (or more) NIC (Network Interface Card), one NIC connected to one Ethernet, the other connected to a second Ethernet. The bridge then joins the 2 Ethernet together, to become one. Of course, a bridge can have more than 2 NIC and connects more than 2 networks. The good use of bridge for example is connecting a 1GBps Ethernet with a 10MBps Ethernet. Since you don't want to slow down the GB net with all the 10MB traffic, you keep them separate but connect them with a bridge. So they can talk to each other, but do not bother each other that much.

OK, back to how to bridge QEMU.
You must have already figured out you need to bridge your real NIC with the TAP device QEMU uses (once you start QEMU with -net tap, it creates a TAP device automatically).
One thing you need to know is once you start a bridge, you cannot manipulate your eth0 (or whatever real NIC device in your real Linux) anymore. "The reason?" I head. Well, since bridge is at level 2, (before IP level), it needs to be able to tell where a packet is going (by the MAC address in the packet). If you manipulate the eth0 device, your packet is going out to the real network directly, the bridge will not have access to the packet, hence it breaks the bridge. (think about a DHCP solution on our 1GBps network and 10MBps network. If you request a DHCP IP address on your eth0 - which is on your 1GBps network, your DHCP server has to be on the 1GBps network or it won't be able to get an IP address. In this situation, you will have to have 2 DHCP servers one on 1GBps, one on 10MBps. You will either create 2 segment of dynamic IPs or find a way to synchronize 2 DHCP servers leases).

So, to solve this problem (well, the problem is there only because you use your bridge-your Linux box-as a computer and a bridge; for a hardware bridge, it is transparent on the Ethernet.) you need to connect to the Ethernet though the bridge interface (once you configured it, you will see the bridge interface has the eth0 MAC address). So the bridge (read the Linux kernel bridge module) can then check the content of the packets and send the packets to the right network.

Since the IP layer is layer 3, which means it builds on top of the bridge which runs at layer 2, you will have to start your IP stack on top of the bridge instead of your real NIC (eth0 in most of the case).
Finally here comes the howto:
Be warned, your IP network will have to come down for a little while (for me this was about 5 seconds). This is because you need to start the IP address on the bridge interface later.
First, release your IP address assigned to your real NIC. I also rename my eth0 to reth0 (stands for Real ETH0) and create the bridge with name "eth0". The reason being it is simpler for your other programs (i.e. iptables which may use eth0 as interface name somewhere).
Then you create a bridge, and add 2 NIC (one is the real NIC the other is the TAP device).
You then re-acquire a DHCP lease with the bridge interface (in my case, is called eth0 now - hey I know it is confusing, but it is just a name, right?).
The following is tested on SLES 9, it should work on most of the linux distro with little change (i.e. the dhcp client tool may be different). You also need the bridge package which is not installed by default (at least on SLES 9 it is not)

#!/bin/bash # 1st, release all DHCP address and remove all IP address associated with the original eth0 /sbin/dhcpcd -k /sbin/ip addr flush eth0 # then take the interface down so we can rename it /sbin/ip link set eth0 down # now rename the original eth0 to reth0 (Real ETH0) /sbin/nameif -r reth0 eth0 # OK, bring the same interface (with new name though) back up /sbin/ip link set reth0 up # 2nd let's create a bridge called eth0 so other programs think they are talking to the same old interface (actually they will talk to the bridge which is a clone of the original eth0 - with name MAC addr) /sbin/brctl addbr eth0 # then add both origianl eth0 and tap1 device to the bridge /sbin/brctl addif eth0 tap1 /sbin/brctl addif eth0 reth0 echo "showing bridge mac addresses" /sbin/brctl showmacs eth0 # 3rd, we need to bring the newly created bridge UP /sbin/ip link set eth0 up # 4th, renew the DHCP address if possible /sbin/dhcpcd -n /sbin/ip addr show

Please note, there are other ways of connecting your virtual computer to the real network with TAP device: you can configure routing on your real computer (I don't see a reason why I want to do that - if you use NAT, why don't you use the "-net user" instead which is much simpler; if you use real world IP, why don't you use bridge? To configure routing for the TAP, you need to start IP stack on the TAP device and start ip forwarding on the real Linux - unnecessarily complex for my environment).

Another good option is VDE (Virtual Distributed Ethernet). It is a very good solution, in some case, it maybe better than bridge. The best feature is you don't need the brief down time as the bridge solution. I found the description of VDE is much better than bridge and hence I will skip this part.