On Tue, Dec 18, 2012 at 10:38 AM, KodaK <sako...@gmail.com> wrote:
> On Tue, Dec 18, 2012 at 9:17 AM, Jakub Hrozek <jhro...@redhat.com> wrote:
>> On Tue, Dec 18, 2012 at 09:07:25AM -0600, KodaK wrote:
>>> On Tue, Dec 18, 2012 at 3:51 AM, Jakub Hrozek <jhro...@redhat.com> wrote:
>>> > On Tue, Dec 18, 2012 at 10:39:56AM +0100, Jakub Hrozek wrote:
>>> >> On Mon, Dec 17, 2012 at 04:03:03PM -0500, Dmitri Pal wrote:
>>> >> > On 12/17/2012 03:11 PM, KodaK wrote:
>>> >> > > I'm attempting to install Satellite in my IPA domain.  There is a
>>> >> > > ridiculous requirement that the group "dba" must not already exist
>>> >> > > prior to installing.  Red Hat support wanted me to *remove* the DBA
>>> >> > > group and then install.
>>> >> > >
>>> >> > > Anyway, I'm trying to play around with filter_groups in sssd, and I
>>> >> > > can't seem to get it to "take."  The man page isn't exactly clear, 
>>> >> > > but
>>> >> > > here's what I've tried:
>>> >> > >
>>> >> > > filter_groups = dba
>>> >> > > filter_groups= dba@fqdn
>>> >> > >
>>> >> > > In the [domain], [sssd] and [nss] sections of the config file.
>>> >> > >
>>> >> > > What's the right syntax?  Do I need it in every section?
>>> >> > >
>>> >> > Is it a local group or a central group?
>>> >>
>>> >> Where Dmitri's question is headed is that if dba is a local group (aka
>>> >> stored in /etc/passwd), then the SSSD should be queried at all.
>>> >               ^^^
>>> >             /etc/group obviously
>>>
>>> I figured. :)
>>>
>>> The group "dba" is stored in IPA.  Here's a funny thing, though (short 
>>> rundown):
>>>
>>> Installed RHEL 6.3 on Satelite server, joined it to the domain.
>>>
>>> Try to install Satellite: get the "Could not install database."
>>>
>>> I try to filter out the group in IPA, try to install Satellite, get:
>>> "The group 'dba' should exist."  This makes me think that the filter
>>> is doing every "dba" not just dba on the IPA server.
>>>
>>> I removed the Satellite server from IPA (ipa-client-install
>>> --uninstall) and I get the same message (dba should exist.)
>>>
>>> Fun stuff.
>>>
>>
>> Unless you wiped out the machine completely, do you know if:
>>
>> $ getent group -s sss dba
>>
>> Returned the group or not?
>>
>> I wouldn't be surprised if the installer tools checked the files directly..
>
> I did wipe it out, but I do know that "getent group dba" returned the
> IPA group *before* I put in the filter, I stupidly didn't check after.
>
> I'm in the middle of re-installing the OS now on the VM, we'll see how
> it goes.  Red Hat says they got it to work in their lab with an IPA
> controlled Oracle user and dba group.
>

So, in case anyone else ever runs into this, this is what I had to do
to get around the problem:

First, maybe I missed it, but I don't see any recommendation in the
documentation that the user oracle and dba *must* exist before you
start the install.  Combine that with the fact that the suggestion I
got from support that the "dba" group can't exist and you have the
recipe that had me going down the wrong path for quite some time.
This had nothing to do with IPA at all, really.

The answer, which like most is incredibly simple, was to create a
local oracle user and dba group, overriding the dba group in IPA.
After that the install went fine(ish.)

--Jason

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to