[gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?

Discussion:

Chris Dagdigian

2011-11-22 20:05:43 UTC

Hi folks,

I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and
am having some issues running jobs as a non-root user via an account
that lives in Active Directory.

The cluster is the standard sort of RHEL 5.7 based system but we are
using Centrify and in particular the Centrify
NIS-gateway-to-ActiveDirectory to service the cluster nodes without
having to license centrify on all nodes in the cluster.

The user errors I see are familiar ones:

"can't get password entry for user "x". Either user does not exist or
NIS error!"

The confusing thing is that I can SSH into compute nodes as the same
user and both password logins and passwordless SSH work perfectly. It's
only when running under SGE that the jobs fail.

If I had to guess I'd wonder first if SSHD was using Linux /etc/pam.d/
in a way that "works" while SGE is accessing PAM in some way that we
have not configured properly yet. That's only a guess though.

Does anyone have examples of SGE running via NIS authentication or via
Centrify? Any examples of PAM configuration that were needed to get NIS
users recognized under SGE?

Thanks!

-Chris

Reuti

2011-11-22 20:32:59 UTC

Permalink

Hi Chris,

I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and am having some issues running jobs as a non-root user via an account that lives in Active Directory.

isn't Univa offering "Full, Enterprise Class Support"? I thought this is one of the advantages over the community support for the open source version. So I would assume they have their own forum/list like Oracle does for their version:

https://forums.oracle.com/forums/forum.jspa?forumID=859

-- Reuti

The cluster is the standard sort of RHEL 5.7 based system but we are using Centrify and in particular the Centrify NIS-gateway-to-ActiveDirectory to service the cluster nodes without having to license centrify on all nodes in the cluster.
"can't get password entry for user "x". Either user does not exist or NIS error!"
The confusing thing is that I can SSH into compute nodes as the same user and both password logins and passwordless SSH work perfectly. It's only when running under SGE that the jobs fail.
If I had to guess I'd wonder first if SSHD was using Linux /etc/pam.d/ in a way that "works" while SGE is accessing PAM in some way that we have not configured properly yet. That's only a guess though.
Does anyone have examples of SGE running via NIS authentication or via Centrify? Any examples of PAM configuration that were needed to get NIS users recognized under SGE?
Thanks!
-Chris
_______________________________________________
users mailing list
https://gridengine.org/mailman/listinfo/users

Bill Bryce

2011-11-22 20:40:40 UTC

Permalink

Hi Chris,

I think the best way is to log this as an issue at Univa and we can go from there. Is this cluster for your personal use or are you configuring it on behalf of a customer? You can send an email to ***@univa.com or login to the support portal http://www.univa.com/support and we can help.

Regards,

Bill.

Post by Reuti
Hi Chris,

I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and am having some issues running jobs as a non-root user via an account that lives in Active Directory.

https://forums.oracle.com/forums/forum.jspa?forumID=859
-- Reuti

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

William Bryce | VP of Products
Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA
Email ***@univa.com | Mobile: 512.751.8014 | Office: 416.519.2934

Chris Dagdigian

2011-11-22 20:54:46 UTC

Permalink

Like many users of the Oracle branded SGE I was hopefully assuming
faster and more targeted support would be available from the smart
people who inhabit the users- list. Don't we have a history going back
(like forever?) of doing that?

Univa support is going to be my 2nd stop mainly because I'd expect it to
take longer to open, troubleshoot and resolve via a formal ticketing
system. I think my issue has more to do with PAM and NIS than any deep
SGE issue.

I really have not been paying much mind to the fireworks on this list
recently but if the end result is that people are going to shun Oracle
and Univa customers on this mailing list then let me be the first person
to complain how unfortunate and sad this state of affairs has become.

Will we shun ScalableLogic customers next?

Let me be perfectly blunt as nominal owner of the gridengine.org domain
name - there is nobody on earth who has the authority (informal or
otherwise) to declare that this mailing list can't be used to support or
not-support any particular variant of Grid Engine. We've never given
anyone that authority, nor should we.

I don't want to start an entirely new complaint-fest so let me withdraw
my question. I'll go straight to Univa on this one.

dag

Post by Reuti
Hi Chris,
Regards,
Bill.

Post by Reuti
Hi Chris,

I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and am having some issues running jobs as a non-root user via an account that lives in Active Directory.

https://forums.oracle.com/forums/forum.jspa?forumID=859
-- Reuti

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

William Bryce | VP of Products
Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA

Rayson Ho

2011-11-22 21:37:15 UTC

Permalink

Hi Chris,

I *DID NOT* say that all discussions related to Univa Grid Engine had
to be banned. As we don't have the Univa Grid Engine source code, we
just can't debug the problem. That's basically the same reason Bill
asked others to turn to Oracle for help with issues related to Oracle
Grid Engine back in March 2011:

http://gridengine.org/pipermail/users/2011-March/000288.html

Not only that we don't have the source code, Univa Grid Engine is not
even available as a free download. I am not interested in registering
for Univa's trival license, and this means we can't reproduce the
problem.

When I said that "we also cannot help users using UGE which is also
not opensource", I mean that, we, as people who answered literally
thousands of questions on the Grid Engine mailing lists, have to
speculate whether it is a bug in UGE or it really is a limitation.
This is not productive, and you have to understand that our time, like
everyone's is not free. We don't have 48 hours a day while Univa only
has 24. And besides, Univa knows how to solve its own customers
issues.

Like many users of the Oracle branded SGE I was hopefully assuming faster
and more targeted support would be available ... Don't we have a history going
back (like forever?) of doing that?

We (at least Ron & myself, I can't speak for Reuti), helped lots of
new users install & setup Grid Engine when Sun was in charge. Back in
those days, Reuti, Ron, & I (and others) often responsed in minutes,
and we enjoyed working with Sun because Sun contributed the Gridware
source code to the open source community, and the product was
completely open source.

However, responding to mailing list messages actually took time away
from us to do useful things. If you are using Univa Grid Engine, then
you are paying a Univa customer (since it is commercial only). Univa
has support engineers and they are the people who are hired to support
Univa customers.

Now Chris, tell me why my (as well as Reuti's) original response was
not a fair & accurate answer.

Rayson

Like many users of the Oracle branded SGE I was hopefully assuming faster
and more targeted support would be available from the smart people who
inhabit the users- list. Don't we have a history going back (like forever?)
of doing that?
Univa support is going to be my 2nd stop mainly because I'd expect it to
take longer to open, troubleshoot and resolve via a formal ticketing system.
I think my issue has more to do with PAM and NIS than any deep SGE issue.
I really have not been paying much mind to the fireworks on this list
recently but if the end result is that people are going to shun Oracle and
Univa customers on this mailing list then let me be the first person to
complain how unfortunate and sad this state of affairs has become.
Will we shun ScalableLogic customers next?
Let me be perfectly blunt as nominal owner of the gridengine.org domain name
- there is nobody on earth who has the authority (informal or otherwise) to
declare that this mailing list can't be used to support or not-support any
particular variant of Grid Engine. We've never given anyone that authority,
nor should we.
I don't want to start an entirely new complaint-fest so let me withdraw my
question. I'll go straight to Univa on this one.
dag

Post by Reuti
Hi Chris,
I think the best way is to log this as an issue at Univa and we can go
from there. Is this cluster for your personal use or are you configuring it
login to the support portal http://www.univa.com/support and we can help.
Regards,
Bill.

Post by Reuti
Hi Chris,

Post by Chris Dagdigian
I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and
am having some issues running jobs as a non-root user via an account that
lives in Active Directory.

isn't Univa offering "Full, Enterprise Class Support"? I thought this is
one of the advantages over the community support for the open source
version. So I would assume they have their own forum/list like Oracle does
https://forums.oracle.com/forums/forum.jspa?forumID=859
-- Reuti

Post by Chris Dagdigian
The cluster is the standard sort of RHEL 5.7 based system but we are
using Centrify and in particular the Centrify NIS-gateway-to-ActiveDirectory
to service the cluster nodes without having to license centrify on all nodes
in the cluster.
"can't get password entry for user "x". Either user does not exist or NIS error!"
The confusing thing is that I can SSH into compute nodes as the same
user and both password logins and passwordless SSH work perfectly. It's only
when running under SGE that the jobs fail.
If I had to guess I'd wonder first if SSHD was using Linux /etc/pam.d/
in a way that "works" while SGE is accessing PAM in some way that we have
not configured properly yet. That's only a guess though.
Does anyone have examples of SGE running via NIS authentication or via
Centrify? Any examples of PAM configuration that were needed to get NIS
users recognized under SGE?
Thanks!
-Chris
_______________________________________________
users mailing list
https://gridengine.org/mailman/listinfo/users

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

William Bryce | VP of Products
Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA

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

Chris Dagdigian

2011-11-22 21:47:45 UTC

Permalink

Hi Rayson,

Did not mean to imply that it was you who made those statements - I
actually thought you were referring to or quoting someone else who had
attempted in the past to dictate what the community list can be used
for. All I wanted to say was that nobody can dictate how this list is
used and it would be a shame if our mailing-list/support group started
to fragment up.

That said, however, I 100% understand that support can't be a given when
the source is not available. I'll keep my UD-product questions to Univa
when I'm dealing with their versions.

-dag

Post by Reuti
Hi Chris,
I *DID NOT* say that all discussions related to Univa Grid Engine had
to be banned. As we don't have the Univa Grid Engine source code, we
just can't debug the problem. That's basically the same reason Bill
asked others to turn to Oracle for help with issues related to Oracle
http://gridengine.org/pipermail/users/2011-March/000288.html
Not only that we don't have the source code, Univa Grid Engine is not
even available as a free download. I am not interested in registering
for Univa's trival license, and this means we can't reproduce the
problem.
When I said that "we also cannot help users using UGE which is also
not opensource", I mean that, we, as people who answered literally
thousands of questions on the Grid Engine mailing lists, have to
speculate whether it is a bug in UGE or it really is a limitation.
This is not productive, and you have to understand that our time, like
everyone's is not free. We don't have 48 hours a day while Univa only
has 24. And besides, Univa knows how to solve its own customers
issues.

Like many users of the Oracle branded SGE I was hopefully assuming faster
and more targeted support would be available ... Don't we have a history going
back (like forever?) of doing that?

We (at least Ron& myself, I can't speak for Reuti), helped lots of
new users install& setup Grid Engine when Sun was in charge. Back in
those days, Reuti, Ron,& I (and others) often responsed in minutes,
and we enjoyed working with Sun because Sun contributed the Gridware
source code to the open source community, and the product was
completely open source.
However, responding to mailing list messages actually took time away
from us to do useful things. If you are using Univa Grid Engine, then
you are paying a Univa customer (since it is commercial only). Univa
has support engineers and they are the people who are hired to support
Univa customers.
Now Chris, tell me why my (as well as Reuti's) original response was
not a fair& accurate answer.
Rayson

Like many users of the Oracle branded SGE I was hopefully assuming faster
and more targeted support would be available from the smart people who
inhabit the users- list. Don't we have a history going back (like forever?)
of doing that?
Univa support is going to be my 2nd stop mainly because I'd expect it to
take longer to open, troubleshoot and resolve via a formal ticketing system.
I think my issue has more to do with PAM and NIS than any deep SGE issue.
I really have not been paying much mind to the fireworks on this list
recently but if the end result is that people are going to shun Oracle and
Univa customers on this mailing list then let me be the first person to
complain how unfortunate and sad this state of affairs has become.
Will we shun ScalableLogic customers next?
Let me be perfectly blunt as nominal owner of the gridengine.org domain name
- there is nobody on earth who has the authority (informal or otherwise) to
declare that this mailing list can't be used to support or not-support any
particular variant of Grid Engine. We've never given anyone that authority,
nor should we.
I don't want to start an entirely new complaint-fest so let me withdraw my
question. I'll go straight to Univa on this one.
dag

Post by Reuti
Hi Chris,

Post by Chris Dagdigian
I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and
am having some issues running jobs as a non-root user via an account that
lives in Active Directory.

isn't Univa offering "Full, Enterprise Class Support"? I thought this is
one of the advantages over the community support for the open source
version. So I would assume they have their own forum/list like Oracle does
https://forums.oracle.com/forums/forum.jspa?forumID=859
-- Reuti

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

William Bryce | VP of Products
Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA

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

Rayson Ho

2011-11-22 22:35:15 UTC

Permalink

Hi Chris,

Thanks for the clarification.

I have been a supporter of open-source Grid Engine for over 8 years,
and the last thing I wanted to see is the mailing list fragmented up.
As you know OGS' mailing list was not created until Oracle announced
its plan to finally shutdown the original site, because we didn't want
to fork the Grid Engine community. (However, we didn't want to merge
with others because there really are valid reasons, but it is too long
to talk about those on this list.)

Back to the usage of this list... Even on the steering committee
mailing list, I was one of those who said that job ads on the "users"
list discussions should not be disallowed. In my "Re: [Grid Engine
Steering] job ads" (April 28) email, I said: "It is not good to have
so many rules, and we can just ignore & not reply to the messages we
don't like. Unless the message is totally junk, we should just leave
it."

Finally, let me reiterate that I've been a Grid Engine contributor for
8 years because I think that everyone on this planet is supposed to
have free access to this technology. (The keyword here is "free", and
I am pro-SGE not because I hate LSF or PBS) Again, I can't speak for
Reuti or Ron, but given that I only have 24 hours a day, I would
rather use my time on something useful (like improving Open Grid
Scheduler/Grid Engine, and I am starting to share enhancements with
Dave), and answering questions on this list becomes the 2nd or 3rd
priority among the list of things that I wanted to/needed to do. I am
staying with the Grid Engine community for at least another 10 years,
and this change is just a way of moving Open Grid Scheduler/Grid
Engine forward - so don't blame me for not answering non-opensource
Grid Engine related questions or not answering as quickly questions on
this list.

Rayson

Post by Chris Dagdigian
Hi Rayson,
Did not mean to imply that it was you who made those statements - I actually
thought you were referring to or quoting someone else who had attempted in
the past to dictate what the community list can be used for. All I wanted to
say was that nobody can dictate how this list is used and it would be a
shame if our mailing-list/support group started to fragment up.
That said, however, I 100% understand that support can't be a given when the
source is not available. I'll keep my UD-product questions to Univa when I'm
dealing with their versions.
-dag

Like many users of the Oracle branded SGE I was hopefully assuming faster
and more targeted support would be available ... Don't we have a history going
back (like forever?) of doing that?

We (at least Ron& myself, I can't speak for Reuti), helped lots of
new users install& setup Grid Engine when Sun was in charge. Back in
those days, Reuti, Ron,& I (and others) often responsed in minutes,
and we enjoyed working with Sun because Sun contributed the Gridware
source code to the open source community, and the product was
completely open source.
However, responding to mailing list messages actually took time away
from us to do useful things. If you are using Univa Grid Engine, then
you are paying a Univa customer (since it is commercial only). Univa
has support engineers and they are the people who are hired to support
Univa customers.
Now Chris, tell me why my (as well as Reuti's) original response was
not a fair& accurate answer.
Rayson

Like many users of the Oracle branded SGE I was hopefully assuming faster
and more targeted support would be available from the smart people who
inhabit the users- list. Don't we have a history going back (like forever?)
of doing that?
Univa support is going to be my 2nd stop mainly because I'd expect it to
take longer to open, troubleshoot and resolve via a formal ticketing system.
I think my issue has more to do with PAM and NIS than any deep SGE issue.
I really have not been paying much mind to the fireworks on this list
recently but if the end result is that people are going to shun Oracle and
Univa customers on this mailing list then let me be the first person to
complain how unfortunate and sad this state of affairs has become.
Will we shun ScalableLogic customers next?
Let me be perfectly blunt as nominal owner of the gridengine.org domain name
- there is nobody on earth who has the authority (informal or otherwise) to
declare that this mailing list can't be used to support or not-support any
particular variant of Grid Engine. We've never given anyone that authority,
nor should we.
I don't want to start an entirely new complaint-fest so let me withdraw my
question. I'll go straight to Univa on this one.
dag

Post by Reuti
Hi Chris,

Post by Chris Dagdigian
I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and
am having some issues running jobs as a non-root user via an account that
lives in Active Directory.

isn't Univa offering "Full, Enterprise Class Support"? I thought this is
one of the advantages over the community support for the open source
version. So I would assume they have their own forum/list like Oracle does
https://forums.oracle.com/forums/forum.jspa?forumID=859
-- Reuti

Post by Chris Dagdigian
The cluster is the standard sort of RHEL 5.7 based system but we are
using Centrify and in particular the Centrify
NIS-gateway-to-ActiveDirectory
to service the cluster nodes without having to license centrify on all nodes
in the cluster.
"can't get password entry for user "x". Either user does not exist or NIS error!"
The confusing thing is that I can SSH into compute nodes as the same
user and both password logins and passwordless SSH work perfectly. It's only
when running under SGE that the jobs fail.
If I had to guess I'd wonder first if SSHD was using Linux /etc/pam.d/
in a way that "works" while SGE is accessing PAM in some way that we have
not configured properly yet. That's only a guess though.
Does anyone have examples of SGE running via NIS authentication or via
Centrify? Any examples of PAM configuration that were needed to get NIS
users recognized under SGE?
Thanks!
-Chris
_______________________________________________
users mailing list
https://gridengine.org/mailman/listinfo/users

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

William Bryce | VP of Products
Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA

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

Ron Chen

2011-11-23 06:52:49 UTC

Permalink

Chris,

1) There really are differences between Oracle Grid Engine and Univa Grid Engine. First and foremost, Oracle has never used misleading or false information just to get an extra customer to pay for Oracle Grid Engine. If you have not read all the messages in the mail thread started by Dave Love recently, then don't blame us for being rude to Univa.

And related to shunning Grid Engine users? Is there a more effective way to shun Grid Engine users and potential users than to tell them that using Grid Engine can get sued by oracle?

If you think that the end (that your client who wants to get Grid Engine support can get it from a commercial source) justifies the means (the way this company gets new customers by spreading misleading or false information), then I have nothing more to say. I personally have a higher moral standard, and I try to avoid companies that do not play fairly in their markets.

2) If you go to a Redhat RHEL mailing list and ask questions related to Oracle Enterprise Linux, guess what? People are willing to answer your RHEL or CentOS questions, but none of your Oracle Enterprise Linux questions. At least one non-Redhat guy will give you a lecture on why you are supposed to get support from Redhat, and will also tell you why Oracle Enterprise Linux is a parasite. And yes, support for Oracle Enterprise Linux is cheaper than a RHEL subscription, and yes, Oracle does have a team that develops Oracle Enterprise Linux.

With Grid Engine, Oracle's the position gets flipped with Redhat's. Oracle becomes Redhat and needs to pay for the acquisition cost of Sun Microsystems (which owns Grid Engine). Only Oracle owns the intellectual property of Grid Engine, all other versions (or implementations) of Grid Engine did not have to pay for the initial development cost or acquisition cost. And most of the community support work is done by Reuti (always the winner in terms of the number of messages or speed), Andy (who is still at Oracle), Rayson, and me. While the original SGE developers were under Sun's payroll, we have spent a great amount of time on this community, and built it from scratch when no one had heard of Grid Engine in the early 2000s.

3) Both the responses from Reuti & Rayson are valid, and not particular harsh. Keep in mind that an open core product is not supportable by the community, as explained by Michael ‘Monty’ Widenius (the MySQL founder):

http://monty-says.blogspot.com/2011/09/oracle-adding-close-source-extensions.html

* You are depending on one vendor (ie. vendor lock-in)

* You can't do any bug fixes yourself and you can't contract anyone except the original vendor to get things fixed.

I am quoting 2 most important ones, especially "you can't contract anyone except the original vendor to get things fixed". And that's only for open core software, and Univa Grid Engine is not even an open core product now, it is an closed source product. There can be fixing in Univa Grid Engine, or things that we don't know in the code. If we guess that there is a bug, and turns out to be wrong, then we are blamed as bashing Univa Grid Engine. And if we guessed right, then we can't prove that until it is confirmed by the company that owns the source.

4) Last but not least, Monty built MySQL from scratch and he is not happy with MySQL turning from an open-source application into an open-core application, but at least Sun paid him US $1B for MySQL. We helped to build the Grid Engine community from scratch and we are not happy with this "unfortunate and sad this state of affairs" status quo.

Anyway, enough ranting from me, and this email, like all other emails from others who complained about this state of affairs & things in Grid Engine, will be ignored by you and you will "not be paying much mind" again and treat them as "fireworks". And tomorrow you will be getting new Grid Engine users for this company that is the root of the problem & trouble (and you are helping this cancer grow by allowing it to hire more sales to spread FUD and damage our community), and you sleep well and don't feel anything, and both the bioteam & this company make money and are happy.

-Ron

----- Original Message -----
From: Chris Dagdigian <***@sonsorol.org>
To: "***@gridengine.org Group" <***@gridengine.org>
Cc:
Sent: Tuesday, November 22, 2011 3:54 PM
Subject: Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?

Like many users of the Oracle branded SGE I was hopefully assuming
faster and more targeted support would be available from the smart
people who inhabit the users- list. Don't we have a history going back
(like forever?) of doing that?

Univa support is going to be my 2nd stop mainly because I'd expect it to
take longer to open, troubleshoot and resolve via a formal ticketing
system. I think my issue has more to do with PAM and NIS than any deep
SGE issue.

I really have not been paying much mind to the fireworks on this list
recently but if the end result is that people are going to shun Oracle
and Univa customers on this mailing list then let me be the first person
to complain how unfortunate and sad this state of affairs has become.

Will we shun ScalableLogic customers next?

Let me be perfectly blunt as nominal owner of the gridengine.org domain
name - there is nobody on earth who has the authority (informal or
otherwise) to declare that this mailing list can't be used to support or
not-support any particular variant of Grid Engine. We've never given
anyone that authority, nor should we.

I don't want to start an entirely new complaint-fest so let me withdraw
my question. I'll go straight to Univa on this one.

dag

Post by Reuti
Hi Chris,
Regards,
Bill.

Post by Reuti
Hi Chris,

I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and am having some issues running jobs as a non-root user via an account that lives in Active Directory.

https://forums.oracle.com/forums/forum.jspa?forumID=859
-- Reuti

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

William Bryce | VP of Products
Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA

Rayson Ho

2011-11-22 20:44:20 UTC

Permalink

While I worked with Billl before, and I've started working with Chris
even before SGE was opensourced (that was in early 2001), and I don't
want to be rude on this list - I just cannot agree more with Reuti!!

At the beginning of this year, Univa said that this list can't help
users using Oracle Grid Engine because OGE is not opensource, we also
cannot help users using UGE which is also not opensource.

Rayson

Post by Reuti
https://forums.oracle.com/forums/forum.jspa?forumID=859
-- Reuti

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

b***@merctech.com

2011-11-22 21:32:01 UTC

Permalink

In the message dated: Tue, 22 Nov 2011 15:05:43 EST,
The pithy ruminations from Chris Dagdigian on
<[gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active
directory integration?> were:
=>
=> Hi folks,

In the spirit of supporting the community of SGE users, rather than
splitting hairs over open-source vs. commercial, I'm going to offer some
possible answers. Of course, they are worth exactly as much as Chris is
paying me for support. :)

=>
=> I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and
=> am having some issues running jobs as a non-root user via an account
=> that lives in Active Directory.

We're running SGE 6.2u5 (Sun courtesy binaries) on a mixed CentOS 4.8 &
CentOS 5.7 cluster.

=>
=> The cluster is the standard sort of RHEL 5.7 based system but we are
=> using Centrify and in particular the Centrify
=> NIS-gateway-to-ActiveDirectory to service the cluster nodes without
=> having to license centrify on all nodes in the cluster.

We're using Kerberos to integrate with AD for authentication, and using
NIS for authorization. Ie., users must be in the local NIS tables in
order to login, but passwords are stored solely within AD.

In our environment, the AD authentiation only takes place when users
login to the head node. Once they are logged in, SGE connections between
nodes (qlogin, qsub) use passwordless SSH, but still depend on NIS for
the authorization (ie. user account information) on the compute nodes.

=>
=> The user errors I see are familiar ones:
=>
=> "can't get password entry for user "x". Either user does not exist or
=> NIS error!"

Yes, we've seen that too, when NIS is unavailable on some compute nodes.

=>
=> The confusing thing is that I can SSH into compute nodes as the same
=> user and both password logins and passwordless SSH work perfectly. It's

Hmm...if NIS is broken, I'd expect that ssh would fail. If NIS is
working but NIS->AD integration is broken, I'd expect the passwordless
SSH to succeed.

On the compute node, does
getent passwd $user
return the expected info?

Do you allow direct logins from outside the cluster to compute nodes?

The question is...do you really need NIS->AD integration to perform
authentication for SGE jobs? Is there a gateway (a cluster head node)
or some division between interactive and batch-only nodes? If the
authorization & authentation take place on the interactive nodes, and SGE
can trust passwordless SSH between the interactive and compute nodes,
then you don't need the NIS->AD gateway in addition to an entry in the
NIS passwd table to give the UID<->login mapping, home directory, etc..

=> only when running under SGE that the jobs fail.

This suggests to me that SGE is using a different authorization mechanism
that you use for login sessions.

Do you use SSH for SGE jobs (ie., what are the values of 'qlogin_daemon'
and 'rsh_command' in the SGE config)?

=>
=> If I had to guess I'd wonder first if SSHD was using Linux /etc/pam.d/
=> in a way that "works" while SGE is accessing PAM in some way that we
=> have not configured properly yet. That's only a guess though.
=>
=> Does anyone have examples of SGE running via NIS authentication or via
=> Centrify? Any examples of PAM configuration that were needed to get NIS
=> users recognized under SGE?

I can give you our /etc/pam.d/system-auth config from the interactive
nodes, but we don't do anything special on the compute nodes...just
using NIS and passwordless SSH.

Mark

=>
=> Thanks!
=>
=> -Chris
=>
=>

Brooks Davis

2011-11-22 21:45:26 UTC

Permalink

Post by Chris Dagdigian
Hi folks,
I'm hands-on with a shiny new cluster running Univa's 8.0.1 release and
am having some issues running jobs as a non-root user via an account
that lives in Active Directory.
The cluster is the standard sort of RHEL 5.7 based system but we are
using Centrify and in particular the Centrify
NIS-gateway-to-ActiveDirectory to service the cluster nodes without
having to license centrify on all nodes in the cluster.
"can't get password entry for user "x". Either user does not exist or
NIS error!"
The confusing thing is that I can SSH into compute nodes as the same
user and both password logins and passwordless SSH work perfectly. It's
only when running under SGE that the jobs fail.
If I had to guess I'd wonder first if SSHD was using Linux /etc/pam.d/
in a way that "works" while SGE is accessing PAM in some way that we
have not configured properly yet. That's only a guess though.
Does anyone have examples of SGE running via NIS authentication or via
Centrify? Any examples of PAM configuration that were needed to get NIS
users recognized under SGE?

We're running with BeyondTrust PowerBroker Identity Sevices which is
somewhat equivalent without modification. This is likely an nsswitch
rather than PAM issue.

With BeyondTrust we were seeing issues with bare qrsh failing for
non-root users. In the end I found a bug in GE in that case (file
descriptors closed too early which killed access to the daemon that
talks to AD) and posted a fix to the developers list a few months ago.

Univa did ask if they could include it so it may or may not be included
in your current release. If not, they should give you a with it
included.

-- Brooks

Beat Rubischon

2011-11-23 06:06:32 UTC

Permalink

Hi Chris!

Post by Chris Dagdigian
"can't get password entry for user "x". Either user does not exist or
NIS error!"

I assume those errors are intermittent and not permanent. Otherwise I'm
pretty sure you found them long before your users were accessing the
system :-)

My workaround for such nasty bugs are static passwd / group files on the
compute nodes. I use a "getent passwd" and "getent group" on the
headnode which is attached to any arbitrary directory service and copy
those lines to the appropriate files on the compute nodes. Of course
you'll need some lines of your favorite scripting language to merge the
system users with those out of the directory.

Authentication could still be directed to the directory services by
using PAM. You only have to make NSS happy to run jobs using any kind of
job scheduler.

Beat

--
\|/ Beat Rubischon <***@0x1b.ch>
( 0-0 ) http://www.0x1b.ch/~beat/
oOO--(_)--OOo---------------------------------------------------
Meine Erlebnisse, Gedanken und Traeume: http://www.0x1b.ch/blog/

William Hay

2011-11-23 08:54:18 UTC

Permalink

As others have pointed out community support for closed source
versions is necessarily limited but nothing stops us from having a go.
As Univa and Oracle diverge from the open source versions this will
become harder though.

We have a setup where the user accounts are made available via NIS (ie
nsswitch.conf points to NIS) with a "*" in the password field. We
don't authenticate that way. On our worker nodes we use ssh host
based auth (root has a local password) on our login nodes we use
pam_ldap. This config is largely historical but allows us to use the
college's central authentication services on the login nodes without
having to import a lot of other stuff that we don't need. We didn't
do anything special as far as setup was concerned. This is with SGE
6.2u3.

I'd try running a getent command on the nodes to check that NIS is
propogating all the way through to the name service. I think SGE just
checks the account is present and not locked in some way.

Do you perhaps have enforce_user set to yes in your sge_conf without
having defined users?

William

Post by Chris Dagdigian
Thanks!
-Chris
_______________________________________________
users mailing list
https://gridengine.org/mailman/listinfo/users

Chris Dagdigian

2011-11-23 12:19:04 UTC

Permalink

Post by William Hay
As others have pointed out community support for closed source
versions is necessarily limited but nothing stops us from having a go.
As Univa and Oracle diverge from the open source versions this will
become harder though.

Just wanted to mention on the list and in public that many smart people
that I respect pointed this same observation out. Sorry for my "doh!"
moment last night ...

-chris