Hi Herald,

Still no luck. There isnt any difference in doing with source or executable way. I have gone through the inst_sge script, it trying to get QMaster and EXECD port numbers by knowing their services. Especially in settings.sh script i am just getting unset QMASTER_PORT and EXECD_PORT no commands available to set or export them.

One gud thing is, i have re installed every thing from scratch again including SUA. Luckily the SSL library loading problem is resolved. But when i give qconf -sconf i am getting a new error like :

sh-3.1$ qconf -sconf
error: commlib error: ssl certificate error (please check certificate validity)
ERROR: unable to contact qmaster using port 6444 on host "raghavendra"

This error looks like there is a mismatch between the certificates. But i have done exactly as said in the document. For the sake of clarity i just want to describe wat i have done.

1. Installed SUA in windows, DEP Disabled.
2. set up debian-interix for SUA following the instructions in - http://debian-interix.net/debian-interix/INSTALL
3. Tried installing OpenSSH Server using apt-get

     #apt-get install openssh-server

    got following error:

Unpacking openssh-blacklist (from .../openssh-blacklist_0.4.1+nmu1_all.deb) ... dpkg-deb: file `/var/cache/apt/archives/openssh-blacklist_0.4.1+nmu1_all.deb' co
    ntains ununderstood data member data.tar.xz     , giving up
dpkg: error processing /var/cache/apt/archives/openssh-blacklist_0.4.1+nmu1_all.
    deb (--unpack):
     subprocess dpkg-deb --fsys-tarfile returned error exit status 2
    Selecting previously deselected package openssh-server.
Unpacking openssh-server (from .../openssh-server_1%3a4.7p1-9+interix.3_interix-
    i386.deb) ...
    Errors were encountered while processing:
     /var/cache/apt/archives/openssh-blacklist_0.4.1+nmu1_all.deb
    E: Sub-process /usr/bin/dpkg returned an error code (1)

Now I am able to connect to other systems with SSH but other systems cannot connect to mine.

4. Setup QMaster in a RHEL 64 bit linux system using the respective common.tar and lx-amd64.tar files Installed with CSP and did all that is required for windows execution host. The certificate files were created in /var/sgeCA/default/sge_QMaster folder but according to document they should be created in p6444 folder 5. After Setting up QMaster in Linux system, I extracted common.tar and windows specific.tar file in windows system. I copied the installation folder "default" folder
   to the SGE_Root directory of windows system.
6. I copied and extracted the certificate files generated in Linux system to /var of Windows SUA.
7. In SUA shell sourced settings.sh present in default folder.
8. Run the qconf -sh or qconf -scong in SUA shell. Initailly it gave me error that cannot find cert.pem file in /var/sgeCA/port6444/default/userkeys/vizexperts directory. 9. My directory structure was different with sge_qmaster folder instead of port6444 - /var/sgeCA/sge_qmaster/default/userkeys/vizexperts 10. so changed directory name of sge_qmaster to p6444 and ran qconf -sconf again then i got the above mentioned SSL certificate error.

I am not sure if i am doing it wrong at some step or using some completely different files. Kindly let me know if u can point out any difference from how u do in the above mentioned steps.

Thanks,
Ryagz




On 06/28/2013 09:18 AM, Harald Pollinger wrote:
Hi Ryagz,

sadly, my truss doesn't print any version information. Probably I update mine once from the suacommunity.com site.


Do you really run the settings script, or do you source it?
It's meant for being sourced, not being run. This is why it doesn't have the execute flag set after installation.

If you run the script, it is executed in a sub shell, it sets the variables in the sub shell. After the script finished, also the sub shell finishes and the variables are lost.

If you did source it and the variables are not set by the settings script, it seems your installation wasn't successful. The settings script should set or modify these variables:

SGE_ROOT
SGE_CELL
SGE_CLUSTER_NAME
SGE_QMASTER_PORT
SGE_EXECD_PORT
MANPATH
PATH
LD_LIBRARY_PATH

If this is not the case, I'd repeat the Qmaster installation.

Does this help you?

Cheers,
Harald


On 06/28/2013 07:45 PM, Raghavendra wrote:
Hi Harald,

Thanks for trying it out for me. Now i am confident that we could make
it work some how.

Yea i have followed the installation guide and have disabled data
execution prevention.

When i run the following in cmd prompt, i get:

C:\Users\vizexperts>wmic OS Get DataExecutionPrevention_SupportPolicy
DataExecutionPrevention_SupportPolicy
0

from an online resource, the result 0 means DEP set to always off.

So DEP should not be the issue. One more observation i have is truss is
giving the same error for wat ever command i execute. I Simply tried

#truss ls
tracing pid 1051
getdata() getdata returned 0
process killed by signal 9

I am not sure if truss is not setup properly or if i am having some
issues at SUA level only.

I have installed SUA as decribed in the document and installed various
packages using debian-interix link http://debian-interix.net/ provided
by bill.

Another issue - when i just run default/common/settings.sh and then run
qconf -sconf, the first error i get is missing environment variable for
SGE_QMASTER_PORT and then for SGE_EXECD_PORT after i set those
environment variables in the shell i then get this libssl error. So, are
these env variable missing errors expected? because i didnt face them in
linux.


Thanks,
Ryagz



On 06/28/2013 07:25 AM, Harald Pollinger wrote:
Hi Ryagz,

I just tested the win32-x86 binaries from the UGE 8.1.4 demo package.

I ran
# truss bin/win32-x86/qconf -sconf
and got about 50 lines of output and an "exit(1)" at the end.

Then I installed Qmaster on a Linux host and the Execd on the Windows
host, unset LD_LIBRARY_PATH and ran "qconf -sconf" again in the truss
and got a lot of output including:

open("/work/clusters/V814/lib/win32-x86/libssl.so", 0x1) open returned 3
read(3, 0x19FDBB0, 4096) read returned 4096 0x1000
close(3) close returned 0

I.e. the libssl.so was successfully opened, i.e. in principle it works.



You got "process killed by signal 9" in your output - did you disable
the Data Execution Prevention?

See
http://social.technet.microsoft.com/Forums/windows/en-US/0f4f1fa2-bef2-483e-a00f-9c5224e1f403/turn-off-dep


Like Bill wrote, there are a lot of things to take care of, following
the installation guide is really necessary here...

Cheers,
Harald


On 06/28/2013 01:10 PM, Raghavendra wrote:
Hi Harald,

Thanks for the reply.

if its looking for libraries in ../../lib/win32-x86 then they are
readily available there. Using truss command i am getting following
error:

-sh-3.1$ truss qconf -sconf
tracing pid 1051
getdata() getdata returned 0
process killed by signal 9

Any idea?

Ryagz

On 06/27/2013 03:22 PM, Harald Pollinger wrote:
The SFU/SUA binaries are built with the -rpath option of the linker.
The -rpath option tells the loader to search for the libraries not in
the LD_LIBRARY_PATH, but in the specified path, which is
"../../lib/win32-x86" from the location of the binary you want to run.

So if the qconf binary is in the "$SGE_ROOT/bin/win32-x86" directory,
it should find the ssl library in the "../../lib/win32-x86" path.

If you have installed truss, then run
# truss qconf -sconf
to see which ssl lib the loader really wants to open.

Cheers,
Harald

On 06/28/2013 01:41 AM, Raghavendra wrote:
Hi Bill,

Thanks for your effort in searching for me. Debian for interix is
working, i was able to install openssh for sua. But one problem still
exists.

When i run qconf -sh in the sua command prompt after loading
settings.sh
file. I am getting the following error:

error: commlib error: can't open ssl library (Unable to open the
OpenSSL
library
.  Please make sure libssl is accessible from your shared library
path.)
ERROR: unable to send message to qmaster using port 6444 on host
"raghavendra":
framework is not initialized

 From the error i understood its trying to load library libssl. I
searched and found the libraries libssl.so and libssl.so.1.0.0 are
available in $SGE_ROOT\lib\win32-x86 directory. I even tried adding
this
directory to $LD_LIBRARY_PATH but didnt work.
On digging on the internet i found cl_com_ssl_crypto_handle =
sge_dlopen
("libssl", LIBSSL_VER); dlopen is failing.

What would be the possible reasons? Incompatible libssl libraries?
These libraries have been taken from univa win32 tar file.

Kindly help me to resolve the issues.

Thanks,
Ryagz
On 06/26/2013 08:33 AM, Bill Bryce wrote:
Another possible useful link Ryagaz....Debian has an Interix port for
tools that include OpenSSH.  You can find it here:
http://debian-interix.net/

Regards,

Bill.

On 2013-06-26, at 11:16 AM, Raghavendra wrote:

Hi,

I found that scalable logic guys have implemented support of cygwin
from the link bellow:

http://blogs.scalablelogic.com/2012/06/grid-engine-cygwin-port.html

But i am not able to find binaries for the above anywhere over the
net. I tried contacting scalable logic guys about this, but there
hasn't been any reply from them. Is any one aware of how to use the
above mentioned in cygwin?

And Is scalable logic  still an active group? If so can any one
provide us their contact information other than
i...@scalablelogic.com <mailto:i...@scalablelogic.com>. Because we
are interested in opting for their commercial support program if
cygwin implementation works for windows 7 64 bit version.

Regards,
Ryagz

_______________________________________________
users mailing list
users@gridengine.org <mailto:users@gridengine.org>
https://gridengine.org/mailman/listinfo/users




_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users



_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users



_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users



_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users

Reply via email to