On 3/18/13 11:07 AM, First Last wrote: > I think I have to clarify some points... > > 1) I started by doing step by step what is in the user guide. But as > long as I using an headless computer, the user guide doesn't help me > straight forward. I took a look in the mailling list, and in google of > almost all occurences with headless and virtualgl... but I didn't found > the solution, so if you think about a mail I would be happy to read it...
https://sourceforge.net/mailarchive/forum.php?thread_name=BANLkTi%3DOXLchUdBd%2BGBio871mqkYNYVuCA%40mail.gmail.com&forum_name=virtualgl-users http://comments.gmane.org/gmane.comp.video.opengl.virtualgl.user/477 > 2) about the "-x" option for vglconnect, the user guide says "this mode > performs optimally on local-area networks" what I'm doing here. I don't > have to encrypt or to securise anything. But at anytime i read it's a > legacy mode... and I still want to remember the fact that without "-x" I got You are misquoting. Section 8.2 (describing vglconnect -x) says "AS WITH THE PREVIOUS MODE, this mode performs optimally on local-area networks", but it goes on to say that vglconnect -x is less secure and is primarily useful only in grid environments (in which case you may not be able to use SSH forwarding because you don't know which machine will be running the 3D job.) In fact, that was the whole purpose of vglconnect -x to begin with. The "previous mode" is the one described in Section 8.1, which is using vglconnect with no arguments. Section 8.1 also clearly says "This mode is recommended for use on secure local-area networks." > 5) I tried this morning to install turbovnc (1.2), I download and compil > it on both client and server. But thanks to the documentation there > should be /opt/TurboVNC/bin/vncserver actually isn't here. there is > vncserver in .../turbovnc-1.1.90/unix . So don't know what to do here, > just root cp never sound clever... Try using the binaries we provide. It is much easier to provide support if I know that you are using a build that works. Otherwise, I have no way of knowing that you didn't mess something up in the installation or the build process. > 6) not sure what you mean here (maybe my english) : > > > after some research, I did this, > > [root ~]# chmod u+s /opt/VirtualGL/lib/libdlfaker.so > > [root ~]# chmod u+s /opt/VirtualGL/lib/librrfaker.so > > after reboot, I still got same errors than before. > > You are apparently running a custom build of VGL. Our packages install > the faker DSO's under /usr/lib*. It may be that you can't preload a > DSO > into a setuid root executable unless the DSO is in the system library > path. It also goes without saying that the lib*faker.so files need to > be owned by root. Not sure why a game would be setuid root. That > seems > very odd to me. > > because, I downloaded the src from sourceforge, I didn't customised > anything (excepted FindTurboJPEG.cmake to reach the good directory)... > anyway, I created two symbolic links ont the server, > > ln -s /opt/VirtualGL/lib/librrfaker.so /usr/lib/lib/librrfaker.so > ln -s /opt/VirtualGL/lib/librrfaker.so /usr/lib/librrfaker.so Try using the binaries we provide. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
