Bugzilla Bug 137424

This is the tracker bug for the vmware-player ebuilds from the vmware overlay. 
This is split off to try to reduce the pressure on bug #122500 by separating
out issues to specific packages.

Err... vmware-server, that is...

An update from the amd64-hardened issue that I was discussing in the original
thread. I have solved my problem - my emulation libraries were fine, but I did
not have a "multilib" profile. If you are using hardened, you must be using the
hardened/amd64/multilib profile as opposed to the hardened/amd64 profile.
Perhaps the ebuild should produce an error if it detects that the amd64
installation does not have multilib?

One more thing I encountered on amd64-hardened (would apply to any hardened
however), after vmware-server was running...

The file 
/opt/vmware/server/sbin/vmware-serverd requires the PAGEEXEC privilege. If you
use vmware-server-console to connect, you will get an error that the perl
module could not set execute privileges. By default, a PaX enabled kernel will
not allow this, so you must add the following lines to /etc/conf.d/chpax

vmware="/opt/vmware/server/sbin/vmware-serverd"

and add vmware to the PAGEEXEC_EXEMPT line as follows:

PAGEEXEC_EXEMPT="${vmware}"

Quick update, build 27828 is now in the overlay...  5:)

Ok Vic, good catch.  Somewhere in amongst the move to using the vmware.eclass,
the bit that alters the pam file stopped altering the
/etc/vmware/pam.d/vmware-authd file, and start altering the
/etc/pam.d/vmware-authd file.  Since that wasn't getting installed, the file
was never being updated.

I've pushed that into the subversion repository now, but I *haven't* bump the
revision of the ebuild.  So to test out whether it's fixed please delete
/etc/pam.d/vmware-authd, delete /etc/vmware/pam.d/vmware-auth, re-emerge
vmware-server and then re-run the vmware-config.pl.  Once all that's been done,
please double check the file /etc/pam.d/vmware-authd and ensure it contains the
/emul/linux stuff in it.  Then please report back about the pam_deny problems
you seemed to be getting, and we'll look into those separately if they're still
around...

I've been given very conflicting information about what pam will when a 32-bit
program requests the pam libraries without a location.  Seemingly from your
report, it doesn't manage to figure it out automatically, so I'll continue
patching the pam file for amd64.  If anyone can give me a definitive answer
over the "best" solution to this problem, please let me know and we can test it
out in the next build.  Thanks!  5:)

G'day Mike, apologies for using the wrong bug originally...  Followed your
instruction to update from svn, delete the pam config files, remerge and rerun
vmware-config.pl and (sorry) the vmware-authd file has no /emul/linux paths. 
As expected, login from the console fails with all modules listed as faulty.

Yep, sorry, sorry, my bad Vic.  There was, in fact, another typo in there, so
the substitution wasn't happening (and handily failed silently).  That's been
fixed up now, any chance you could give it another try for me?  Thanks...  5:)

Revision 69 from SVN sets up /etc/pam.d/vmware-authd as required -- thanks
Mike!  The message about faulty pam_deny.so still appears, but this could be
some effort in tackling by the looks -- in my Copious Free Time I'll see what I
can find and report (in case no-one else is actively looking).

Now to hook it up to auth off LDAP -- wish me luck...  ;)

Cheers...

Minor feature request, please Mike:

/opt/vmware/server/bin/vmware-config.pl offers to set permissions on the VM
directory. That's fine, but it would be helpful if it said to what.

I suspect that it sets root:root, but I was expecting it to set root:vmware.

Once again, thanks for the sterling work to date.

Ok, Peter, I'll check out the message and see what's going on when I get a
chance.  Remember that hopefully the config script will be completely
eliminated, but for the time being I'll see if I can't fix it up...  5:)

What method should I be using to keep vmware-server updated? I just did the
"cvs up" on it and now have 1.0.0.24927. I am unable to redo the digests
because of a vmware.eclass missing error.

Before I cry bug, was this the right way to stay up to date?

emerge layman
layman -f
layman -a vmware

Ahh, ok...  So after doing those three, an emerge vmware-server gives a new
error. Was I to fill the tree differently than svn which grabbed revision 53?

>svn co http://callisto.cs.kun.nl:81/svn/trees/vmware/app-emulation

>layman -a vmware
Checked out revision 69.
<snip>
* Successfully added overlay "vmware".

>emerge vmware-server
Calculating dependencies     ... done!
>>> Emerging (1 of 2) app-emulation/vmware-modules-1.0.0.15 to /
>>> checking ebuild checksums
!!! A file listed in the Manifest could not be found:
'/usr/portage/local/layman/vmware/app-emulation/vmware-modules/vmware-modules-101-r3.ebuild'

Nevermind.. I have my svn in /usr/local/portage  not in the same layman tree.
I copied it over and all started compiling. :) 

Thanks!

Thanks Nick, you did actually spot a small bug in there, the digests for the
vmware-modules ebuilds hadn't been updated since I removed the
vmware-modules-101 ebuild.  That's now been taken care of...  5:)

Hey Mike, 

Happy to stumble around for ya :) I've tripped again. The configure.pl script
set me all up, but when it tries to start the services the vmnet0 bridge and
vmnet8 nat will not start. See below:

Type XXXXX-XXXXX-XXXXX-XXXXX or 'Enter' to cancel: <yadda>

 * Starting VMware services:                                                   
                                              [ ok ]
 *   Virtual machine monitor                                                   
                                              [ ok ]
 *   Virtual ethernet                                                          
                                              [ ok ]
 *   Bridged networking on /dev/vmnet0                                         
                                              [ !! ]
 *   Host-only networking on /dev/vmnet1 (background)                          
                                              [ ok ]
 *   Host-only networking on /dev/vmnet8 (background)                          
                                              [ ok ]
 *   NAT service on /dev/vmnet8                                                
                                              [ !! ]

The configuration of VMware Server 1.0.0 build-27828 for Linux for this running
kernel completed successfully.

So I try:

goonie app-emulation #  /etc/init.d/vmware restart
 * %LONGNAME% is installed, but it has not been (correctly) configured
 * for the running kernel. To (re-)configure it, invoke the
 * following command: /opt/vmware/server/bin/vmware-config.pl.
 * VMware is not properly configured! 

<sigh> Now I did erase all traces of the previous install done teh old way
before I used the layman approach. I only kept my VM-Host files.

Nick

Ok, scanning logs after logs.. the /dev/vmmon was missing and a modprobe for
vmmon fixed that... which I think would have started if the init script would
run.   Sooo.. I looked into the init script and saw it checking for the
existance of /etc/vmware/not_configure flag file. I had one. I deleted it. All
better. :) VMware starts fine, all networking is functional, and my Win 2K
domain controller is back online as a VM Guest..

Could there be a bug in the vmware-config.pl that fails to clean up that one
flag file?

Nick

Nick

Nick, unfortunately, it's very difficult to identify whether there's a bug in
the flag removal since once you've identified what was going wrong, you've
usually changed the various files that caused the condition.

The problem is that vmware doesn't just create a flag file and check whether it
exists, but also keeps a record of the flag file having been created in the
/etc/vmware/locations database.    That flag gets removed after a successful
run of the vmware-config.pl file, and gets replaced if the init script fails at
any point.

The vmware-config.pl won't remove that file if it doesn't exactly match what's
in that database, which I think could be where the problems are arising.  The
next major task that we're looking at tackling is turning that huge perl config
script into a tiny little configuration section of the ebuilds, however, that
task will unfortunately take us a bit of time.  I guess what I'm trying to say
is that the not_configured flag bug is fairly low on our list of priorities I'm
afraid...

However, having re-read your issue, the vmware init script *should* have run a
modprobe on vmmon, and so you shouldn't have been having those problems.  If
you run into the issue again (say after a reboot or similar), please check your
dmesg logs and let me know if there are any errors concerning the module
loading.  Other than that, all I can suggest is wait for us to ditch the config
scripts, sorry...  5:(

If you need any testers, I am more than able to toss my VMWare load and
reinstall for testing purposes. The guest VM that I need can always be ported
to my second server. 

The vmmon seems to have no trouble loading.. never a glitch in demesg, just in
the serverd.log in /var/log/vmware.

I do not expect the not_configured issue to be addressed if your main effort is
the auto install from within an ebuild script. That's the spirit of Gentoo. :)

Anyway, let me know if I can help any. 

Nick

are there any ebuilds available for the rc2 (Build 27828)?

Yes there are, they've been in the overlay for a couple of weeks.  Please
ensure you are using the correct repository.  If you're using layman, please do
the following:

layman -f
layman -d vmware
layman -a vmware

If you've got >=layman-1.0.4 it should tell you during sync that the location
of the repository has changed, if you're not looking at the right one.  The
latest repository is at http://overlays.gentoo.org/svn/proj/vmware/.  Hope that
helps...  5:)

Ok, VMWare released it out of Beta, am I the first to ask what timeline Gentoo
e-build's are on? :)

Running in a vmware server x86_64 (1.0.0.28343), guest OS is Gentoo x86
2.6.14-hardened-r8, a little problem with vmware-server-tools-1.0.0.28343
SVN revision 79
first I had to digest the ebuild (seemed strange)
and after the emerge command I get this error :

>>> Install vmware-server-tools-1.0.0.28343 into /var/tmp/portage/vmware-server-tools-1.0.0.28343/image/ category app-emulation
 * Installing vmdesched module
 * Installing vmhgfs module
 * Installing vmmemctl module
 * Installing vmxnet module
!!! dosbin: sbin/vmware-checkvm does not exist

!!! ERROR: app-emulation/vmware-server-tools-1.0.0.28343 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_install
  ebuild.sh, line 1013:   Called src_install
  vmware-server-tools-1.0.0.28343.ebuild, line 56:   Called die

Hiya Bertrand, yep, that's correct.  I'm currently in the middle of creating
the tools package.  I meant to mask it off so that it doesn't get used, it's
NOT functional yet, and it will break your system if you try and get it going. 
I've now made sure it's masked off.  Hopefully however, we'll have one in place
soon.  When we do, I'll be sure to announce it on either this bug, or in the
original overlay bug (or possibly both)...  5:)

Everything works for me, except that vmware-prettify in /etc/init.d/vmware
doesn't give good directions after a kernel upgrade.  Purely cosmetic, but
still.  Something like "VMware is not properly configured!  If you changed
kernels, remember to remerge vmware-modules" might help.

That being said, I'm still dumb for getting this wrong.

My problem installing results in:

>>> Unpacking VMware-server-1.0.0-28343.tar.gz to /var/tmp/portage/vmware-modules-1.0.0.15/work

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler.

!!! ERROR: app-emulation/vmware-modules-1.0.0.15 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_unpack
  ebuild.sh, line 711:   Called src_unpack
  ebuild.sh, line 1248:   Called vmware-mod_src_unpack
  vmware-mod.eclass, line 65:   Called unpack
'VMware-server-1.0.0-28343.tar.gz'
  ebuild.sh, line 389:   Called die

!!! failure unpacking VMware-server-1.0.0-28343.tar.gz
!!! If you need support, post the topmost build error, and the call stack if
relevant.
!!! This ebuild is from an overlay: '/usr/portage/local/layman/vmware'

Use, thank you for your report.  Please see the response I gave on 122500.  You
should revert your overlay to it's original state, with the original digest,
and ensure that you have fully deleted the file with the bad digest from
/usr/portage/distfiles.  Once this has been done, please double check that
you're not getting the file through a proxy that may have cached the bad
version and redownload the file.  The digest in the overlay is correct
according to the vmware main distribution site...

Ok, following on from bug 122500 comment 392, Sunil, unfortunately that's an
issue with the gentoo runscript system.  The way they work is that when start
is called, gentoo remembers it (I'm not entirely certain of the location, but
it *isn't* a pid file, it's literally just a file saying whether the service
has been started successfully or not).  Then when you try and stop the service,
it will try to recall whether the service was running or not, and it will only
attempt to stop the service if it believes it is already running.

Now since we're wrapping vmware's init script, and vmware does things in
stages, it's quite possible that a large number of the vmware services will
start up, but that the script as a whole will fail.  When that happens, gentoo
will think that the service hasn't started, whereas vmware may actually be
usable.  Either way, gentoo will not allow you to stop the service until it
believes it has been started successfully.

The same problem exists when trying to start a service that died, but which
gentoo believes is still running.  In this circumstance however, the developers
provide the "zap" method on the service, which will reset it to a not started
state.  Unfortunately there's no covnerse (or none that I know of) to force a
service to believe it's started ok.

So, what I'm trying to say is that there isn't a lot that we can do about it at
the moment (whilst we still rely on the vmware init scripts), so you'll have to
bear with us.  If you ever get in a similar situation, please run zap the
service and kill all the vmware-* processes running to reset the server to a
not running state.  Hopefully if the vmware initscripts haven't spotted you
doing this, they wont' created the hated not_configured file, and you should be
ok to just start the service up again...  5:)

Andy, sorry it took so long to get back to you, there should now be a patch in
portage to alter the failure message.  It should tell you to try recompiling
your modules first, and then attempt to reconfigure the product as well.  I
hope that helps...  5:)

I've just had to rebuild my system again after a power outage that fried my
md-raid partitions (just before taking a backup!), and now I have new
difficulties. First, layman is dropping the host name from the target URL, so I
can't use that tool to manage vmware-server sources (I've lodged a fault
report). Secondly, having used a Web browser to get all the files (I hope) from
http://overlays.gentoo.org/svn/proj/vmware/trunk/app-emulation, installation
goes ok but my serial number is rejected. Have I cocked something up?
(Vmware.com's Web site won't show me my serial numbers and I can't find where
to request a new one, so I'm stuck with the one I have.)

I also can't run vmware-server-console because I've no authority, even though I
am in the vmware group. What's the state of auth these days?

My gcc went up to 4.1.1 during the rebuild - is that a problem too? This is a
~amd64 box.

Hiya Peter, sorry to hear about your raid getting fried...  5:(

First off you'll need the eclasses as well as app-emulation, but if you got
vmware-server emerged ok, then you've probably got those.  Second since it's
now out of beta, you'll have to re-register to get licenses for the latest
version, if you go to download Vmware Server from the vmware site, you should
see a bit "download now" button, above that, there should be an orange
"register now" button.  That should lead you to
http://register.vmware.com/content/registration.html, where you can pick up
your new serial number.

As to why vmware-server-console can't be started, please do ensure that you've
configured it.  I know the configuration doesn't look like it actually does
anything, but the console will simply fail to start (silently if done from the
desktop icon) unless you configure it.  If you're having difficulty connecting
to the server rather than starting the console itself, please double check your
xinetd config and ensure it's set to allow from 127.0.0.1, for some reason it
doesn't do hostname resolution very well, and won't figure out what localhost
means, so best to put it in as 127.0.0.1...

Hopefully this will solve most of your problems, please let me know if any of
them are still hanging around, and we'll see what we can do to fix them...  5:)

Nameless, whilst we have managed to remove most of the X dependencies,
unfortunately the main server executable (the bit which actually emulates the
virtual machines) is still linked against several X libraries as you can see:

ikelos bin # ldd /opt/vmware/server/lib/bin/vmware-vmx
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/libm.so.6 (0xb7f10000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7f0c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7ef9000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e0d000)
        libXtst.so.6 => /usr/lib/libXtst.so.6 (0xb7e07000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7df9000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0xb7da8000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb7d92000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb7d89000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7d81000)
        libz.so.1 => /lib/libz.so.1 (0xb7d6e000)
        libc.so.6 => /lib/libc.so.6 (0xb7c52000)
        /lib/ld-linux.so.2 (0xb7f4a000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7c4f000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7c4a000)

Whilst many of these are provided as part of the binary package, the general
policy on these matters is to take the system compiled files over the binary
shipped versions (not least to allow for rapid security patching of such
libraries).  Since X is now modular, this should have a very small impact on
your system, installing just the necessary libraries, and not the whole of X. 
This is as close to a headless system as we can manage.

As it turns out, the full dependencies necessary to run the local console have
not been included, and in the future we hope to strip out the local console
completely.  Until then, this is the smallest set of dependencies we can
provide.  I hope this answers your question...

*** Bug 140819 has been marked as a duplicate of this bug. ***

Just a quick note for myself, and anyone else who might happen to run into
this.  Cardoe just discovered that vmware doesn't seem to bridge very will with
an aliased interface, so bridging against eth0:1 will fail, whereas bridging
directly against eth0 will succeed.

Hi Mike, and thanks for all the help.

I now have another problem: when I invoke vmware-server-console I find these
entries in the log:

-- 
# grep "Jul 23 12:46:" /var/log/messages
Jul 23 12:46:57 wstn xinetd[8555]: START: vmware-authd pid=14046
from=192.168.129.25
Jul 23 12:46:57 wstn vmware-authd[14046]: PAM unable to
dlopen(/lib/security/pam_deny.so)
Jul 23 12:46:57 wstn vmware-authd[14046]: PAM [error:
/lib/security/pam_deny.so: wrong ELF class: ELFCLASS64]
Jul 23 12:46:57 wstn vmware-authd[14046]: PAM adding faulty module:
/lib/security/pam_deny.so
Jul 23 12:46:57 wstn vmware-authd[14046]: login from 192.168.129.25 as prh
Jul 23 12:46:57 wstn xinetd[8555]: EXIT: vmware-authd status=0 pid=14046
duration=0(sec)
Jul 23 12:46:57 wstn xinetd[8555]: START: vmware-authd pid=14047
from=192.168.129.25
Jul 23 12:46:57 wstn vmware-authd[14047]: PAM unable to
dlopen(/lib/security/pam_deny.so)
Jul 23 12:46:57 wstn vmware-authd[14047]: PAM [error:
/lib/security/pam_deny.so: wrong ELF class: ELFCLASS64]
Jul 23 12:46:57 wstn vmware-authd[14047]: PAM adding faulty module:
/lib/security/pam_deny.so
Jul 23 12:46:57 wstn vmware-authd[14047]: login from 192.168.129.25 as prh
Jul 23 12:46:57 wstn xinetd[8555]: EXIT: vmware-authd status=0 pid=14047
duration=0(sec)
-- 

I find myself logged-in ok, and the WinXP client runs happily from localhost,
but when I try to get Win to see the host's samba shares it always either can't
see the SMB network or tells me I'm not authorised to connnect to it. I'm not
an expert in samba config, but any plausible set of parameters results in these
failures, and I wonder if the wrong-ELF-class errors above are at the root of
it. As I said last time, I'm unsure these days of the state of auth in
vmware-server. I checked the things you said last time, and the only only_from
lines I can see are:

-- 
# grep -r only_from /etc/* | grep -v "#"
/etc/xinetd.conf:       only_from       = 192.168.0.0/16
/etc/xinetd.d/swat:     only_from       = localhost
-- 


(Reminder: this is a dual-Opteron box running ~amd64.)

PS: I changed the swat line to read the same as the one above and reloaded
samba, but it made no difference.

Hi Peter, I'm not certain about the samba configuration.  I don't think the
vmware configuration will be affecting samba between the two hosts.

The wrong ELF class issues are a bit worrying, however.  I'd suggest posting
your /etc/pam.d/vmware-authd file here (it should be very short) and we can try
and see what the problem is.  My guess is that one of the lines still points to
/lib/security/ rather than /lib/emul-somethingorother/someotherstuff/security. 
Since vmware is all 32-bit, it will have to use the 32 bit version of PAM. 
We've tried to set this up automatically for you, but it's possible we haven't
got it quite right yet...

That module shouldn't be causing you networking problems between the two,
however.  The best suggestion I have is to check how it's networked and ensure
you can ping the other machine, then ensure you can see the samba ports, then
check the samba logs etc.  If you really think it's a vmware problem, check the
permissions on /dev/vmnet* and ensure that the vmware group can read and write
to those (which allows for raw/promiscuous mode on the network interface, which
the internal samba may require?).  Sorry I can't be of more help, but I doubt
vmware is the root of this problem...

When trying to emerge vmware-server, I get a SECURITY VIOLATION. See example:

# layman -s vmware
* Running command "/usr/bin/svn update /usr/portage/local/layman/vmware"...
At revision 86.
* Successfully synchronized overlay "vmware".
# emerge vmware-server vmware-modules
Calculating dependencies ...done!
>>> emerge (1 of 2) app-emulation/vmware-modules-1.0.0.15 to /
!!! Security Violation: A file exists that is not in the manifest.
!!! File: files/digest-vmware-modules-1.0.0.14


# emerge --info
Portage 2.0.54 (default-linux/amd64/2006.0, gcc-3.4.4, glibc-2.3.5-r2,
2.6.17-gentoo x86_64)
=================================================================
System uname: 2.6.17-gentoo x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.14
dev-lang/python:     2.4.2
dev-python/pycrypto: [Not Present]
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/gcc-config: 1.3.12-r6
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/vmware"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X a52 aac acpi alsa apache2 arts audiofile avi berkdb bidi
bitmap-fonts borbis bzip2 calendar cdparanoia cdr cli cups curl dga directfb
divx4linux dri dv dvb dvd dvdr dvdread eds emboss encode esd ethereal evo exif
expat fam fbcon ffmpeg flash foomaticdb fortran ftp gd gdbm geoip gif glut gmp
gpm gps gstreamer gtk gtk2 iconv icq idn imagemagick imap imlib innodb ipv6
isdnlog jpeg kde kdeenabelfinal kerberos lcms logitech-mouse lzw lzw-tiff mad
memlimit mng mono motif mp3 mpeg msn mysql ncurses nls nptl ogg opengl pam pcre
pdflib perl php png posix ppds pppd pri python qt quicktime readline reflection
ruby samba scanner sdl session snmp sockets spell spl sqlite ssl svg symlink
tcltk tcpd theora tidy tiff tokenizer truetype truetype-fonts type1-fonts udev
unicode usb v4l vcd vhosts videos vorbis xine xinerama xml2 xorg xpm xv xvid
zlib video_cards_nv video_cards_nvidia video_cards_vesa input_devices_keyboard
input_devices_mouse userland_GNU kernel_linux elibc_glibc"
Unset:  CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS

Thanks for the report Shimi, it was an old file that isn't necessary and should
now be fixed in the overlay...  5:)

Thanks - Now works! :)

Hi Mike,

-- 
$ cat /etc/pam.d/vmware-authd
#%PAM-1.0
auth       sufficient       /emul/linux/x86/lib/security/pam_unix.so shadow
nullok
auth       required         /emul/linux/x86/lib/security/pam_unix_auth.so
shadow nullok
account    required         /emul/linux/x86/lib/security/pam_listfile.so
item=group sense=allow file=/etc/vmware/vmwaregroup onerr=fail
account    sufficient       /emul/linux/x86/lib/security/pam_unix.so
account    required         /emul/linux/x86/lib/security/pam_unix_acct.so
-- 

So that isn't it. On looking at samba more closely, I find from its emerge log
that the module rpctorture fails to build. I can easily imagine that that could
be a problem for SMB networking, so I'd better follow it up there.

Ok Peter, it looks as though one of the default is leaking through, and hence
the 64-bit library is trying to be invoked, rather than the 32-bit one.  Either
way that doesn't seem to be causing you trouble.  Good luck trying to track
down your samba problems, and gimme a shout if I can help at all...  5:)

Not sure if it's related to this bug, but...

Now I am having a trouble accessing the installed VMware server with my VMWare
Server Console (which works against other computers...). I see the following in
/var/log/everything/current:

Jul 23 18:57:43 [xinetd] START: vmware-authd pid=24957 from=127.0.0.1
Jul 23 18:57:43 [xinetd] FAIL: vmware-authd address from=127.0.0.1
Jul 23 18:57:43 [xinetd] EXIT: vmware-authd status=0 pid=24957 duration=0(sec)

And the VMWare Server Console just hangs (and consumes 99.9% CPU) and has to be
manually killed (I waited a few minutes to no avail...). strace on the console
pid says that it does the following two calls in a loop:
time(NULL)                              = 1153671080
read(17, "", 1)                         = 0

I already tried various tips on the net (the xinetd file doesn't have only_from
localhost and I am using localhost anyways, trying symlinking the files
suggested at http://gentoo-wiki.com/HOWTO_Install_VMWare_Server as I am an
AMD64 user, to no avail...)

My emerge --info is at Comment #37.

help? :)

Shimi, please try using 127.0.0.1 rather than localhost, and be sure to add a
line to your /etc/xinetd.d/vmware-authd file saying "only_from 127.0.0.1". 
This will override any possible entries in xinetd.conf, and also uses direct IP
addresses which should avoid any problems associated with name lookups.  Don't
forget to restart xinetd to ensure it picks up the new settings.

If this still fails, please test your console against another server if
possible, and test another console against your server.  If it succeeds, then
it is in fact an xinetd problem (which is what I'm betting on) and you'll have
to double check your settings to get them the way you want them.

If you get confusing results at all, post them here and we'll try and figure
them out (or you can ask me on #gentoo-dev and we can try and sort it out in
real time if you'd like)...

Surprisingly, adding that line helped (how can limiting something help removing
a limit - is beyond me).

It's important to note that I did _not_ have xinetd before that VMWare
installation, which means that I'm probably using stock options of xinetd
(didn't change anything), which I guess means that you must add that line to
the stock ebuild of VMWare?

Up to you... :)

Thanks!

Hi Shimi, yep xinetd is a pain.  It defaults to the outer xinetd.conf settings,
and then individual files override it.  Also, it's caught other people out that
it doesn't handle localhost very well.  There is an einfo at the end of the
vmware-server installation mentioning that users should set an appropriate
only_from line in /etc/init.d/vmware-authd.  It's unfortunately about the best
we can do.  Sorry!

Well, not 10 seconds ago I finally unmasked the ~x86 and ~amd64 versions of
vmware-server and vmware-server-console in the main portage tree!  Hurray!  5:)

So now it's your job to go out there and use it, and hopefully file not too
many bug reports against it.  Enjoy!  5:)

Please consider adding the following to /etc/services at baselayout:
---
vmware-authd 902/tcp
---

So that vmware-config.pl will not modify this file by-itself.
The script will not change the /etc/services if it find a correct line there.

Alon, hopefully in the future we'll be able to eliminate the perl configuration
and init scripts, and do everything in a much more gentoo-ish type way. 
Unfortunately that isn't possible at the moment, and the perl configuration
script has always modified /etc/services.  It's unfortunate, but there's little
that we can easily do about it at the moment, and it's quite low on our list of
priorities at the moment.

Simply adding it to baselayout isn't a solution, since I believe it's required
by xinetd to perform lookups, and if the user decides to set a different port
for vmware-authd, the service file will still need to be edited.  Sorry we
can't fix it at the moment, hopefully it's not too much of an inconvenience.

(In reply to comment #48)
> Alon, hopefully in the future we'll be able to eliminate the perl configuration
> and init scripts, and do everything in a much more gentoo-ish type way. 

Yes, I hope so too.

> Unfortunately that isn't possible at the moment, and the perl configuration
> script has always modified /etc/services. 

No... The vmware-workstation did not have /etc/services entry... So it is a new
issue (as far as I know).

I don't know there is a gentoo-ish type of handling /etc/services... The
current approach is to add all known services into baselayout...

I can imagine the solution... Putting /etc/services.d, and using
update-services script in order to build /etc/services... But it was not
implemented so far.

> Simply adding it to baselayout isn't a solution, since I believe it's required
> by xinetd to perform lookups, and if the user decides to set a different port
> for vmware-authd, the service file will still need to be edited. 

That's true... For vmware AND other services listed at /etc/services.
Current approach is to put the default into baselayout. If the user touches the
file by him-self he will install the prober mechanism (such as remarks) in
order to merge it into new versions of baselayout.

> Sorry we can't fix it at the moment, hopefully it's not too much of an inconvenience.

It is not too much of inconvenience... But I thought you may want to fix
this... As done with many other known services in the system.

Regards.

Something's not quite right with the latest vmware-server ebuild:

DreamSong ~ # emerge -pv vmware-server

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] app-emulation/vmware-server-1.0.0.28343  0 kB 

Total size of downloads: 0 kB

It installed with no complaints, however:

***
 * Updating /etc/vmware/locations

 * You need to run 
 *     /opt/vmware/server/bin/vmware-config.pl
 * to complete the install.

DreamSong ~ # /opt/vmware/server/bin/vmware-config.pl
-su: /opt/vmware/server/bin/vmware-config.pl: No such file or directory
DreamSong ~ # 

Hrmmmm, that is a bit strange, could you please make sure you have
portage-utils installed, and then attach the output of "qlist vmware-server"? 
That should tell us what files were installed by vmware-server, and we can
start working from there...

(In reply to comment #51)
> Hrmmmm, that is a bit strange, could you please make sure you have
> portage-utils installed, and then attach the output of "qlist vmware-server"? 
> That should tell us what files were installed by vmware-server, and we can
> start working from there...
> 

DreamSong ~ # emerge -pv portage-utils

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] app-portage/portage-utils-0.1.18  USE="python" 0 kB 

Total size of downloads: 0 kB
DreamSong ~ # qlist vmware-server
/etc/vmware/init.d
/etc/vmware/locations
/usr/bin/vmware
/usr/share/applications/vmware-server-console-vmware-server-console.desktop
/usr/bin/vmware-server-console
DreamSong ~ # 

Ok, that means something went badly, *badly* wrong with the install.  5:( 
Could you please attach the complete output of "emerge vmware-server" and post
the output of  "emerge --info"...

Created an attachment (id=93520) [details]
Log file from the emerge

Created an attachment (id=93521) [details]
emerge --info output

Bad ebuild??

Ok, it looks as though you're missing the vmware.eclass file.  Please check
that it's present in /usr/portage/eclass/, and that you're not using any
overlays that may overwrite it (ie. double check that your vmware overlay is up
to date).  vmware_src_install was previously called something else, so if
you've been updating you vmware ebuilds manually and haven't updated the
eclass, that could cause this problem.  Note also that eclasses in overlays
take precedence over eclasses in portage, so my best suggestion is either to
remove the vmware overlay, or ensure it's fully up-to-date.  If that solves it,
then just drop a short note here so we know that was the problem.  Thanks... 
5:)

Well ...

Step 1: Removed the vmware overlay from /usr/portage/local/layman/make.conf
Step 2: emerge --sync
Step 3: emerge -v vmware-server
Step 4: stand back

Created an attachment (id=93527) [details]
log of emerge after removing the vmware overlay

Ok, believe it or not, it's looking much healthier now, all the files are being
put in place (as you can see), so now all we have to do is deal with that pesky
error at the end.  Please move your /etc/vmware directory to some place else,
just in case portage is trying to make a directory on top of a file or
something like that.  Then give it another go.  If you get the same error, then
perhaps it might be worth filing a separate bug with the portage people (since
all the parts relating to the ebuild seemed to complete successfully this
time)...

(In reply to comment #60)
> Ok, believe it or not, it's looking much healthier now, all the files are being
> put in place (as you can see), so now all we have to do is deal with that pesky
> error at the end.  Please move your /etc/vmware directory to some place else,
> just in case portage is trying to make a directory on top of a file or
> something like that.  Then give it another go.  If you get the same error, then
> perhaps it might be worth filing a separate bug with the portage people (since
> all the parts relating to the ebuild seemed to complete successfully this
> time)...
> 


It's now up and running! I need to clean up my virtual machine now, but the
server is OK.

# emerge --search vmware-server
Searching...
[ Results for search key : vmware-server ]
[ Applications found : 0 ]

this is an amd64 box i have with 2.6.x gentoo.  do i need to do anything else
to get to this ebuild ?

Not that I can think of.  Give it an emerge --sync, ensure you've added ~amd64
to your accepted keywords (either globally or just for
app-emulation/vmware-server using /etc/portage/package.keywords).  Then it
should emerge.  I dunno whether the search function ignores packages that can't
be installed (and hence the ~amd64 is causing it to be hidden).  You can check
if the files are there by going into /usr/portage/app-emulation/vmware-server
and see if you can see the ebuild...

Yup, that seems to work with emerge.

However here is a problem which i get while configuring vmnet using
vmware-config.pl

# /opt/vmware/server/bin/vmware-config.pl
Making sure services for VMware Server are stopped.

 * Stopping VMware Server ...
   Virtual machine monitor                                             done
   Bridged networking on /dev/vmnet0                                   done
   DHCP server on /dev/vmnet1                                          done
   Host-only networking on /dev/vmnet1                                 done
   Virtual ethernet                                                    d  [ ok
]
Configuring fallback GTK+ 2.4 libraries.

You have already setup networking.

Would you like to skip networking setup and keep your old settings as they are?
(yes/no) [no] no

Do you want networking for your virtual machines? (yes/no/help) [yes]

Would you prefer to modify your existing networking configuration using the
wizard or the editor? (wizard/editor/help) [wizard]

The following bridged networks have been defined:

Do you wish to configure another bridged network? (yes/no) [no]

Do you want to be able to use NAT networking in your virtual machines? (yes/no)
[yes] no

Do you want to be able to use host-only networking in your virtual machines?
[no] yes

Configuring a host-only network for vmnet1.

The host-only network is currently configured to use the private subnet
172.16.249.0/255.255.255.0.  Do you want to keep these settings? [yes]

The following host-only networks have been defined:

Do you wish to configure another host-only network? (yes/no) [no]

Please specify a port for remote console connections to use [902]

Configuring the VMware VmPerl Scripting API.

Building the VMware VmPerl Scripting API.

Using compiler "/usr/bin/gcc". Use environment variable CC to override.

Installing the VMware VmPerl Scripting API.

The installation of the VMware VmPerl Scripting API succeeded.

Do you want this program to set up permissions for your registered virtual
machines?  This will be done by setting new permissions on all files found in
the "/etc/vmware/vm-list" file. [no]

Generating SSL Server Certificate

In which directory do you want to keep your virtual machine files?
[/home/vmware/vmachines]

Do you want to enter a serial number now? (yes/no/help) [no]

 * Starting VMware Server ...
   Virtual machine monitor                                             done
   Virtual ethernet                                                    done
Module vmnet is not loaded.  Please verify that it is loaded before
running this script.
                                                                          [ ok
]
The configuration of VMware Server 1.0.0 build-28343 for Linux for this running
kernel completed successfully.


any insight ?



(In reply to comment #63)
> Not that I can think of.  Give it an emerge --sync, ensure you've added ~amd64
> to your accepted keywords (either globally or just for
> app-emulation/vmware-server using /etc/portage/package.keywords).  Then it
> should emerge.  I dunno whether the search function ignores packages that can't
> be installed (and hence the ~amd64 is causing it to be hidden).  You can check
> if the files are there by going into /usr/portage/app-emulation/vmware-server
> and see if you can see the ebuild...
> 

Ok, please double check that your vmware-modules is installed, and that the
running kernel is also the whose source directory you've symlinked to
/usr/src/linux.  If you've symlinked in a different kernel, it will have built
the modules for that one, and hence not been able to load them for the current
kernel.  If all that's ok, then get back to me and we'll investigate it some
more...  5:)

Hmmm.... seems like the things you mention are in place...

# uname -a
Linux tyan-e 2.6.15-gentoo-r4 #8 SMP Thu Mar 30 18:20:47 PST 2006 x86_64 Dual
Core AMD Opteron(tm) Processor 265 AuthenticAMD GNU/Linux

# ls -l /usr/src
total 50836
lrwxrwxrwx   1 root root       22 Mar  9 15:16 linux -> linux-2.6.15-gentoo-r4
drwxr-xr-x  20 root root     4096 Apr 28 18:18 linux-2.6.15-gentoo-r4
drwxr-xr-x  20 root root     4096 Aug  3 15:15 linux-2.6.16-gentoo-r12
-rw-r--r--   1 root root 51985790 Aug  3 13:55 linux-sources-2.6.16-r12.tar.gz
drwxr-xr-x   7 root root     4096 Apr 21 22:19 pc

# emerge --search vmware-modules
Searching...
[ Results for search key : vmware-modules ]
[ Applications found : 1 ]

*  app-emulation/vmware-modules
      Latest version available: 1.0.0.15
      Latest version installed: 1.0.0.15
      Size of downloaded files: 308,490 kB
      Homepage:    http://www.vmware.com/
      Description: Modules for Vmware Programs
      License:     vmware


(In reply to comment #65)
> Ok, please double check that your vmware-modules is installed, and that the
> running kernel is also the whose source directory you've symlinked to
> /usr/src/linux.  If you've symlinked in a different kernel, it will have built
> the modules for that one, and hence not been able to load them for the current
> kernel.  If all that's ok, then get back to me and we'll investigate it some
> more...  5:)
> 

Ok, please stop the vmware service, ensure that no vmnat/dhcp/whatever services
are running and then lsmod and ensure that both vmmon and vmnet are unloaded. 
Then please try to manually load vmmon and vmnet using modprobe.  If they fail
please report the error message here, if they don't please unload the modules
and attempt to start the service, if it fails again stop the service, kill off
all the vmwhatever processes, manually modprobe the two modules in and start
the service again.  This will help determine whether the modules can be loaded
ok, and whether the service is having difficulty loading them, or fails even
once they've been loaded already... 

ok, so i can finally get it to start (with some similar to steps to an earlier
comment about vmmon and vmnet)

1) /etc/init.d/vmware stop
2) rm /etc/vmware/not_configured
3) modprobe vmnet
4) modprobe vmmon
5) /etc/init.d/vmware start

It seems that without 3 and 4 the service is unable to start.

However, now I am into the (oft-reported) console and server hangs issue

strace on the vmware-serverd (with ~99% usage) shows innumerable
read(29, "", 1)                         = 0
time(NULL)                              = 1155157971

i am using IP addresses in vmware_authd - only_from tag
any ideas ?

Ok, it'd be interesting to find out why steps 3 and 4 aren't working, the
service should be running modprobe for you when it starts.  Please double check
that you've run etc-update, and then please grep /etc/vmware/init.d/vmware for
modprobe.  If it's not in there then one of the patches failed to apply.  If it
is, then something even weirder is going on...

As to the hang, if you're definitely using IP addresses in the only_from line,
and the only_from line is in /etc/xinetd.d/vmware-authd and not just the global
/etc/xinetd.conf, and you're attemping to connect to the server from that valid
IP address, and asking it for it using the valid IP of the server, then I've
got *no* idea I'm afraid...  5:(

1)

# grep -inR modprobe /etc/init.d/vmware
572:      /sbin/modprobe parport || eend 1
576:      /sbin/modprobe parport_pc || eend 1
588:   /sbin/modprobe -r parport_pc
589:   /sbin/modprobe -r parport
638:         /sbin/modprobe parport_pc >/dev/null 2>&1
713:         /sbin/modprobe -r parport_pc >/dev/null 2>&1


2)

hmm - then i will just wait for another update and try this one on another a
different server.

Thanks for the help.


(In reply to comment #69)
> Ok, it'd be interesting to find out why steps 3 and 4 aren't working, the
> service should be running modprobe for you when it starts.  Please double check
> that you've run etc-update, and then please grep /etc/vmware/init.d/vmware for
> modprobe.  If it's not in there then one of the patches failed to apply.  If it
> is, then something even weirder is going on...
> 
> As to the hang, if you're definitely using IP addresses in the only_from line,
> and the only_from line is in /etc/xinetd.d/vmware-authd and not just the global
> /etc/xinetd.conf, and you're attemping to connect to the server from that valid
> IP address, and asking it for it using the valid IP of the server, then I've
> got *no* idea I'm afraid...  5:(
> 

Ok, from part 1, it looks as though you're using an old vmware init script. 
The current one should give you the following results:

$ grep -inR modprobe /etc/vmware/init.d/vmware
578:   /sbin/modprobe -s -f "$1" || exit 1
603:      /sbin/modprobe parport || exit 1
607:      /sbin/modprobe parport_pc || exit 1
619:   /sbin/modprobe -r parport_pc
620:   /sbin/modprobe -r parport
891:         /sbin/modprobe parport_pc >/dev/null 2>&1
989:         /sbin/modprobe -r parport_pc >/dev/null 2>&1

So please double check your installation, ensure you're not getting it from any
unusual overlays, etc or even try a re-install (also remember to etc-update or
dispatch-conf to update the init file)...  5:)

Hello Mike,

Today I sync'ed and was offered upgrades for vmware-server and the console, but
on attempting the server upgrade I got:

-- 
!!! Missing digest for 'vmware-any-any-update101.tar.gz'
-- 

Hiya Peter,

Yeah, that's a known problem (see bug 139134), that Zac Medico's very kindly
working on as we speak!  5:)  I had thought I'd been through and updated all of
the ebuilds to force the cache to fix itself, but seemingly that didn't help. 
This was also originally reported as bug 143289, but that's since been marked
as a duplicate of 139134, so I'd suggest you follow that one for now.  Sorry
it's not been quite as smooth as we'd hoped...

I am not sure why but everytime I install the vmware-server and run config.pl,
my /etc/vmware/locations file keeps expanding with duplicate entries. Does
anybody knwo why?

$ wc -l /etc/vmware/locations
1157 /etc/vmware/locations

$ cat /etc/vmware/locations |sort |uniq | wc -l
1122

Yes, although it's a bit of legacy code and I'm going to be explaining this
from memory so it might not be *quite* right...  Since /etc/vmware/locations is
technically in the CONFIG_PROTECTED part of the system, if we try to put the
new locations file in there, we risk someone not updating it, and then vmware
getting confused about starting etc.

So we rather dirtily read all the entries out of the new locations file and
tack them onto the end of the old locations file.  This shouldn't have too much
of a detrimental effect (since it should only grow by one install list each
time) and it ensures that all your previous settings are saved.  If we
completely overwrote the file, you'd lose certain network configuration
settings and other bits and pieces you'd miss.

This is unfortunately a problem that's going to have to wait until we manage to
completely remove all the perl scripts from our vmware setup, and that could
take a while.  Hope that explains it a bit better...

In comment 30 I said my GCC had been upgraded. I was mistaken - the new version
had been installed, but the system was still using the older 3.4.4. Today,
however, I /am/ upgrading GCC. The ABI has changed, I understand, so the entire
system has to be rebuilt with emerge -e system and emerge -e world. I've
finished the first and started the second, and I'm recompiling the kernel too
at the same version (2.6.18).

Am I going to run into problems when I remerge vmware-server? I thought I'd
seen some discussion of gcc-4.1.1 and vmware, but if so I can't find it now.

Hiya Peter,

The short answer is No, you should be fine.

The longer answer is that since vmware's all precompiled anyway you shouldn't
run into any problems with that.  The main issue is with the kernel modules
(which are compiled).  The kernel modules require that they're built with the
same compiler as the kernel was (which is easy to do), but they also feature a
couple of tests to determine how to build the system on linux.  They basically
have small programs that they try to compile for each feature, and if the
feature isn't present they provide a warning.  The vmware tests upgrade the
warning to a build error and then check to see if the small program compiled. 
Unfortunately gcc-4.1 feature much stricter checking of some issues and reports
*more* warnings than just those expected by vmware.  These also get turned into
build errors and hence mess up the tests.

The newer kernels (>=2.6.17) seem to have been checked to ensure they don't
throw any additional errors under gcc-4.1, and the newer modules
(vmware-any-any104 and vmware-server's modules) don't have an issue with them. 
Unfortunately older kernels still cause gcc to throw some additional errors,
and there's an extra patch I need to add into vmware-modules-1.0.0.13 that I've
been particularly slow about dealing with unfortunately...  5:(

In summary, if you're with a newer (>=2.6.17) kernel, and using gcc-4.1,
everything should work perfectly.  Hope that helps (in a long winded kind of a
way)...  5:)

Ok, thanks Mike. Sorry to have disturbed you. For some reason I thought I'd run
into problems, but so far I haven't. I'm on kernel 2.6.18-gentoo and the emerge
-e world is under way. I'll go back to sleep now...

Anytime Peter!  I particularly enjoy the comments where all I have to do is
write back, you make my job easy!  5:)

Hello Mike,
   I've stumbled over another problem. After some hardware failures recently I
had to rebuild my Gentoo box. I had a copy of the virtual machines, so I copied
it into place for the new vmware-server to pick up. Now the XP client runs just
fine except for one thing: it can't download Windows updates. Other network
traffic works as it should, just the one operation fails: fetching the updates
to install. It wants to fetch 26 updates, but it can't get them.
   Watching network traffic in gkrellm, I don't see anything on any connection
while this is going on, and the route out through my firewall box has not
changed as far as I know. The blockage seems to be in the bridged connection
between the virtual XP machine and the external eth0 of its Gentoo host.
   I have reinstalled VMware tools, and that helped with some things but not
this one. Any ideas?

Ok, I'm going to close this bug, since the overlay is now only for testing.