Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
Hi Chris, Am 22.11.2011 um 21:05 schrieb 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 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. > > 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 > > > ___ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
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 supp...@univa.com or login to the support portal http://www.univa.com/support and we can help. Regards, Bill. On 2011-11-22, at 3:32 PM, Reuti wrote: > Hi Chris, > > Am 22.11.2011 um 21:05 schrieb 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 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. >> >> 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 >> >> >> ___ >> users mailing list >> users@gridengine.org >> https://gridengine.org/mailman/listinfo/users > > > ___ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users William Bryce | VP of Products Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA Email bbr...@univa.com | Mobile: 512.751.8014 | Office: 416.519.2934 ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
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 On Tue, Nov 22, 2011 at 3:32 PM, Reuti wrote: > 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. >> >> 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 >> >> >> ___ >> 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
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 Bill Bryce wrote: 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 supp...@univa.com or login to the support portal http://www.univa.com/support and we can help. Regards, Bill. On 2011-11-22, at 3:32 PM, Reuti wrote: Hi Chris, Am 22.11.2011 um 21:05 schrieb 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 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. 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 ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users William Bryce | VP of Products Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA Email bbr...@univa.com | Mobile: 512.751.8014 | Office: 416.519.2934 ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
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 => => ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
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 On Tue, Nov 22, 2011 at 3:54 PM, Chris Dagdigian wrote: > > 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 > > > > > Bill Bryce wrote: >> >> 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 supp...@univa.com or >> login to the support portal http://www.univa.com/support and we can help. >> >> Regards, >> >> Bill. >> >> On 2011-11-22, at 3:32 PM, Reuti wrote: >> >>> Hi Chris, >>> >>> Am 22.11.2011 um 21:05 schrieb 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 >>> 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. 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 perfectl
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
On Tue, Nov 22, 2011 at 03:05:43PM -0500, Chris Dagdigian wrote: > > 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? 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 ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
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 Rayson Ho wrote: 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 On Tue, Nov 22, 2011 at 3:54 PM, Chris Dagdigian wrote: 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 Bill Bryce wrote: 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 supp...@univa.com or login to the support portal http://www.univa.com/support and we can help. Regards, Bill. On 2011-11-22, at 3:32 PM, Reuti wrote: Hi Chris, Am 22.11.2011 um 21:05 schrieb 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 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-
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
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 On Tue, Nov 22, 2011 at 4:47 PM, Chris Dagdigian wrote: > 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 > > > Rayson Ho wrote: >> >> 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 >> >> >> >> On Tue, Nov 22, 2011 at 3:54 PM, Chris Dagdigian wrote: >>> >>> 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? >>>
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
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 To: "users@gridengine.org Group" 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
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
Hi Chris! On 22.11.11 21:05, Chris Dagdigian wrote: > The user errors I see are familiar ones: > "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 ( 0-0 ) http://www.0x1b.ch/~beat/ oOO--(_)--OOo--- Meine Erlebnisse, Gedanken und Traeume: http://www.0x1b.ch/blog/ ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
On 22 November 2011 20:05, Chris Dagdigian wrote: > > 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? 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 > > Thanks! > > -Chris > > > ___ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users > > > ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
Re: [gridengine users] SGE (univa 8.0.1) - anyone running SGE with Centrify active directory integration?
William Hay wrote: > 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 ___ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
