pa as easy as it was for 389-ds?
thanks,
Brian LaMere
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
On Tue, Aug 24, 2010 at 6:16 PM, Rob Crittenden wrote:
> Brian LaMere wrote:
>
>> Yes, if not easier. It is just 389-ds under the hood, we have some simple
>> management tools that create the agreements for you. Since we use our own CA
>> SSL is easy as well.
>
>
i
nd test to see if everything I want to happen
can be made to happen, and everything I don't want to happen can be made to
not happen.
Thanks,
Brian LaMere
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
>
> 389 access control is pretty powerful and flexible. There's usually a way
> to do what you want to do without having to resort to using subtrees (as in
> AD).
>
> http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_Access_Control.html
>
>
aye - I already have everything on th
ame
389-DS. Having kerberized systems would improve more workflow issues around
here than I can even comprehend, and there are other features of the IPA I
am very interested in as well that will help solve other issues...once I get
around to having enough time to get to those tasks.
Apologies, as m
t more current?
Is there a wiki documentation project (none shows in a couple minutes of
google searching)? If there's nothing more current, I'd be happy to update
whatever is where ever while I'm going through it myself.
Thanks,
Brian LaMere
__
fficial
docs would have less info but would be more accurate, whereas the wiki would
be far more info but with less accuracy. I'll check out the docs in git,
thanks!
Brian LaMere
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
I have the following error in the log after named refuses to start:
named[1736]: failed to dynamically load driver 'ldap.so': libldap-2.4.so.2:
cannot open shared object file: No such file or directory
At first I thought it was simply a "bah, they require the i686 library and I
only have x86_64"
The primary GID for a user isn't in the web interface for the user to be
able to change it. /usr/sbin/ipa-moduser (what the document references)
doesn't exist, nor does "ipa user-mod" have an options for changing the GID.
How is this done?
___
Freeipa-u
On Wed, Sep 22, 2010 at 12:09 PM, James Roman wrote:
> On 9/22/10 2:42 PM, Brian LaMere wrote:
>
>> The primary GID for a user isn't in the web interface for the user to be
>> able to change it.
>>
> Holy cow. What a security flaw that would be if it were. How a
I know about --user-container and --group-container, but that's not
sufficient; the domain is different, so I want to completely change the
search base for migration. Is this possible?
Thanks!
Brian
___
Freeipa-users mailing list
Freeipa-users@redhat.co
h extensively for the actual domain) then looking for
namingContexts within that base won't work; I would like instead to just
grab everything from one base, and import it in to the new base.
Is it not working as you would expect it? Or, is it just not possible to do
what I'm wanting?
On Wed, Sep 22, 2010 at 1:14 PM, Rob Crittenden wrote:
> And this request came from newserver? I don't see where we would query
> namingContexts with this search base. Seems strange that something knew
> about the new basedn though.
aye - and I can say that the only thing pointing at oldserver
>
> It looks like we have a bug when setting an empty base_dn. We try to set it
> blank but it ends up getting set to the IPA base.
>
so if I just change base_dn from '' to 'dc=briandomain,dc=com' then my
selfish desire to complete the migration might complete? ; )
> Are you working from IPA v2
the attribute "hostMask" attribute in the 60sudo.ldif schema def has a
syntax of 1.3.6.1.4.1.1466.115.121.1.15 but it should be
1.3.6.1.4.1.1466.115.121.1.26...maybe?
attributeTypes: (2.16.840.1.113730.3.8.7.11 NAME 'hostMask' DESC 'IP mask to
identify a subnet.' EQUALITY caseIgnoreIA5Match ORDERI
ah, odd - I'm used to IPs being IA5. then the equality match should be
changed? Can't have caseIgnoreIA5Match on a directory string :)
On Fri, Sep 24, 2010 at 9:30 AM, Dmitri Pal wrote:
> Brian LaMere wrote:
> > the attribute "hostMask" attribute in the 60sudo.ldi
On Fri, Sep 24, 2010 at 10:43 AM, Dmitri Pal wrote:
> Brian LaMere wrote:
> > ah, odd - I'm used to IPs being IA5. then the equality match should
> > be changed? Can't have caseIgnoreIA5Match on a directory string :)
> Yes. This is what the patch does :-)
>
17 matches
Mail list logo
