When started vmware server console, there is no option to select for direct connection to vmware-server on localhost. I ask, because if connect to server using hostname, user, and password, then vmware-authd crashes silently. Reproducible: Always Actual Results: After starting of vmware-server-console there is no radiobutton for localhost selection in connection dialogbox. The option can be activated using ln -s /opt/vmware/server/sbin/vmware-authd /usr/sbin/vmware-authd Please add this to ebuild.
I don't know what happen on my browser, that bug is assigned to games. It should be assigned to applications. Sorry for that
Hi, you're quite right vmware-server-console will never contain a radio button for connecting to localhost. If you're directly on the box, the vmware-server package should include a binary (/opt/vmware/server/bin/vmware I believe) that may let you connect directly to your local server. This will however be being removed, since it causes extra dependencies for people who'd like to run a vmware-server without X, and vmware-server-console should include all of the functionality necessary. You did however mention that you're suffering from a different problem, whereby attempting to connect to localhost with your correct username and password causes problems. Could you please provide a bit more information about that? You said you think that vmware-authd crashes silently. Have you determined this using logs or process watching or some other method? Also, symlinking vmware-authd to arbitrary locations probably isn't the best solution, and I've been able to authenticate to localhost/127.0.0.1 without problem from my test build here, so any further information you could provide me about that would be handy too...
Hi Mike Yes I suffer from the login to vmware using host, username, and password. When I try to login, then in log there is only following: May 25 18:23:32 laptop-mirka xinetd[10863]: FAIL: vmware-authd address from=127.0.0.1 May 25 18:23:32 laptop-mirka xinetd[10713]: START: vmware-authd pid=10863 from=127.0.0.1 May 25 18:23:32 laptop-mirka xinetd[10713]: EXIT: vmware-authd status=0 pid=10863 duration=0(sec) So I cannot login using above. Searching throught the net I founf, that vmware-server-console checks if there exist file /usr/sbin/vmware-authd and if the file exists, then console assume that there is vmware server installed on this particular computer. So I made the link described, and now I can enjoy with direct connection to localhost from vmware-server-console. Therefore my suggestion to add the link into the ebuild. In such case even if you cannot connect to vmware-server using hostname, you can do it directly on the host.
Hiya Miroslaw, So, it looks very much as though xinetd isn't configured correctly to allow connections from local host. Whilst this is a problem, the correct solution is not to start making symlinks to workaround the problem. Please check your xinetd.conf and ensure that the only_from line allows access from localhost, then also verify that you have not modified /etc/xinetd.d/vmware-authd. Then please try logging in using both localhost and 127.0.0.1. I believe if your /etc/hosts file isn't to xinetd's liking, it will deny access. Please see bug 137424 comment 42 for more information. They're having exactly the same problem as you are. There's also a description of the problem in bug 122500 comment 220. If you're still having difficulties, please reopen this bug and post all the relevant files /etc/xinetd.conf, /etc/xinetd.d/vmware-authd and /etc/hosts here, plus the outcome of your attempts to log in using both 127.0.0.1 and localhost as the server name...
Hi Mike OK I will take a look to bug reports you mentioned. And one more time about the link. VM-Ware is closed software, so we don't know strictly what is it doing. As I described before that thanks to this link, vmware-server-console assume that there is server installed on the same machine as the console is started, and allow direct connection to the server (without engage of all authentication process, and network layer for communication). And I am 100% sure that direct connection application <-> application is faster than application <-> network layer <-> application. So in my opinion that thing is worthy of insertion in our distribution. About the problem with xinet, and vmware-authd, I just made completely fresh gentoo installation on amd64, and the problem exists. So maybe there is missing some package dependency, something that you have in your installation, and I don't have in my. For now I will not reopen the bug until I read the other bug reports. But please consider possibility of unlocking of direct connection to the server from vmware-server-console. best regards
Hi again I just checked with my system. Originally there was no line only_from .... in /etc/xinet.d/vmware-authd And in that case the vmware-server-console cannot connect to server, the vm-s-console freeze and get 100% of cpu. If I added considered line in the form: only_from = localhost then the symptoms are the same as above. If I changed the line to: only_from = 127.0.0.1 then it connected without any troubles (great :), it works, no any missing dependency). So it seems, that there is missing the line only_from... in xinet config file. But what if someone would like to use vmserver from localhost, and from local network at the same time? Do you have solution for that case?
Miroslaw, As you point out, the software is closed source. It's for that reason that it is stored in /opt and not in /usr, and it's also for that reason that I will not add a symlink from one to the other. It is unnecessary (as you've demonstrated) and the performance issues do not warrant one-off symlinks on a user's filesystem. If you would like a better mechanism for enabling a local connection, a support request to vmware upstream would be your best bet. Also, this bug was an xinetd configuration issue rather than a problem with vmware-server in anyway. If you'd like network access locally and remotely, I recommend reading the xinetd configuration documents, which explain that the only_from line can occur multiple times in a service definition as follows: only_from = 127.0.0.1 only_from += 192.168.0.0/24 As to the software not working by default, you haven't specified what your host file looked like (which directly affects xinetd's lookup abilities of hostnames such as localhost) and you also neglected to mention what /etc/xinetd.conf looked like. You should find a line in there reading only_from localhost. You overrode that line by adding one directly in for the service. Unfortunately, vmware-server cannot educate users about all of the problems they may encounter in dependent components, such as broken host files or problems in xinetd. Finally as to the performance differences between using the application directly or connecting to it by hostname, the applications almost certainly talk through some local socket mechanism and other than the initial overhead, I anticipate the performance differences would by negligible. However, I don't know any more about the actual performance gains than you do, so I'm sure we'd both prefer a comment or actual figures from vmware themselves before making unnecessary changes to the package. 5;) However, since you seemed so determined to have direct access, you should re-read comment 2, where I mentioned that at the moment you can connect directly by running /opt/vmware/server/bin/vmware, which is effectively a local copy of vmware-server-console installed by vmware-server. It is not recommended because the dependency list cannot be guaranteed (hence there is no desktop icon for it), but it will give any performance gain that may exist. I hope that helps... 5:)
