date:20130114

Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?

2013-01-14 Thread Petr Viktorin


On 01/11/2013 09:57 PM, John Dennis wrote:

On 01/11/2013 03:52 PM, Dmitri Pal wrote:

On 01/11/2013 03:27 PM, John Dennis wrote:

On 01/11/2013 03:10 PM, Dmitri Pal wrote:

On 01/10/2013 11:00 AM, John Dennis wrote:

On 01/10/2013 08:15 AM, Petr Spacek wrote:

Hello,

is there any user of CSV support built-in to IPA administration tools
("ipa"
command)? Do you consider it sane or even useful? Please reply.


I've always disliked our use of CSV values on both the command line
and internally. They're just weird, nothing else in Unix works like
this and as you point out below there are easier better alternatives.
Plus with the use of CSV's there is a lot of awkward quoting in a
variety of places.

On the command line I always thought multiple values should be
specified multiple times and internally they should be encapsulated in
lists rather than parsing a CSV string (if it's logically a list then
why isn't it a list?)

However at this juncture I'm not sure we can make such a change, we
have a published API that we would be violating. But perhaps we're not
so far down the road we can't make such a change and we're better off
doing it now while there is even a chance. It's not clear to me how
much the command line is being used and specifically with CSV values.

Do I think CSV's are sane and useful? No. Can we change that? That's a
whole other story.



I wanted to add single TXT record with double quotation marks (")
inside the
TXT data.

I spent some time figuring out how it is supposed to work ... and
with help of
Petr^3 I managed to write the command.

The resulting command (for BASH) is absolutely crazy:
ipa dnsrecord-add example.test. newrec --txt-rec='"""created on
13:01:23"""'

Do we really need support for this piece of insanity? Shells can do
the same
thing with much less pain :-)

IPA with CSV support can add multiple attributes at once, e.g.
ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9
will add TXT records with value 1, 2, 3 etc.

BASH can do the same thing (without the escaping hell):
ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9}
and
ipa dnsrecord-add example.test. newrec --txt-rec={1..9}
BASH would expand to
ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2
--txt-rec=3
--txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8
--txt-rec=9





Do we already have CSV support?
Where is it used?
It is not clear to me if BASH example above requires the CSV support or
it does expansion on its own. Please explain.



We already have CSV support. It's a mechanism that allows multiple
values to be passed for one command line argument. The alternate
approach is rather than having one command line arg that takes
multiple values is to allow multiple command line args, each one
taking a single value. This is the UNIX methodology. I believe the
original thinking was who would want to type out multiple command line
args, it's too verbose. However the shell expansion illustrated above
shows how with simple shell syntax one can have succicent args and
allow the shell to expand them into the preferred verbose form.



So both are already supported and we want to stop using CSV and
deprecate it over time?
This makes sense if there are good examples of how to use bash expansion.
I suggest we create a page and describe preferred method of dealing with
the lists and document it.
Also do the same with the manual, i.e. review it to make sure we do not
show CSV syntax in the docs, same with the man pages.
On the project page we will say that CSV will not be added to the new
and existing commands and will be deprecated over time (probably by IPA
version 4).
Do I get it right?



I'm not sure both are currently supported. I'm not sure we permit
multiple args with the same name and aggregate them, I thought that was
part of the proposal.



We do support multiple arguments.

The trouble with CSV is that to put commas (or in some cases double 
quotes) in the data, they need to be escaped in a way that's not 
intuitive. The proposal is to change this, so that instead of

--txt-rec='"""created on 13:01:23"""'
you can use just
--txt-rec='"created on 13:01:23"'
and instead of
--txt-rec='Record one, record two'
you need to say
--txt-rec={'Record one','record two'}
The assumption is that this makes more sense to a sysadmin, who is much 
more likely to know bash scripting than our flavor of CSV escaping.



--
Petr³

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

Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?

2013-01-14 Thread Martin Kosek

On 01/14/2013 09:09 AM, Petr Viktorin wrote:
> On 01/11/2013 09:57 PM, John Dennis wrote:
>> On 01/11/2013 03:52 PM, Dmitri Pal wrote:
>>> On 01/11/2013 03:27 PM, John Dennis wrote:
 On 01/11/2013 03:10 PM, Dmitri Pal wrote:
> On 01/10/2013 11:00 AM, John Dennis wrote:
>> On 01/10/2013 08:15 AM, Petr Spacek wrote:
>>> Hello,
>>>
>>> is there any user of CSV support built-in to IPA administration tools
>>> ("ipa"
>>> command)? Do you consider it sane or even useful? Please reply.
>>
>> I've always disliked our use of CSV values on both the command line
>> and internally. They're just weird, nothing else in Unix works like
>> this and as you point out below there are easier better alternatives.
>> Plus with the use of CSV's there is a lot of awkward quoting in a
>> variety of places.
>>
>> On the command line I always thought multiple values should be
>> specified multiple times and internally they should be encapsulated in
>> lists rather than parsing a CSV string (if it's logically a list then
>> why isn't it a list?)
>>
>> However at this juncture I'm not sure we can make such a change, we
>> have a published API that we would be violating. But perhaps we're not
>> so far down the road we can't make such a change and we're better off
>> doing it now while there is even a chance. It's not clear to me how
>> much the command line is being used and specifically with CSV values.
>>
>> Do I think CSV's are sane and useful? No. Can we change that? That's a
>> whole other story.
>>
>>
>>> I wanted to add single TXT record with double quotation marks (")
>>> inside the
>>> TXT data.
>>>
>>> I spent some time figuring out how it is supposed to work ... and
>>> with help of
>>> Petr^3 I managed to write the command.
>>>
>>> The resulting command (for BASH) is absolutely crazy:
>>> ipa dnsrecord-add example.test. newrec --txt-rec='"""created on
>>> 13:01:23"""'
>>>
>>> Do we really need support for this piece of insanity? Shells can do
>>> the same
>>> thing with much less pain :-)
>>>
>>> IPA with CSV support can add multiple attributes at once, e.g.
>>> ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9
>>> will add TXT records with value 1, 2, 3 etc.
>>>
>>> BASH can do the same thing (without the escaping hell):
>>> ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9}
>>> and
>>> ipa dnsrecord-add example.test. newrec --txt-rec={1..9}
>>> BASH would expand to
>>> ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2
>>> --txt-rec=3
>>> --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8
>>> --txt-rec=9
>>>
>>
>>
> Do we already have CSV support?
> Where is it used?
> It is not clear to me if BASH example above requires the CSV support or
> it does expansion on its own. Please explain.
>

 We already have CSV support. It's a mechanism that allows multiple
 values to be passed for one command line argument. The alternate
 approach is rather than having one command line arg that takes
 multiple values is to allow multiple command line args, each one
 taking a single value. This is the UNIX methodology. I believe the
 original thinking was who would want to type out multiple command line
 args, it's too verbose. However the shell expansion illustrated above
 shows how with simple shell syntax one can have succicent args and
 allow the shell to expand them into the preferred verbose form.

>>>
>>> So both are already supported and we want to stop using CSV and
>>> deprecate it over time?
>>> This makes sense if there are good examples of how to use bash expansion.
>>> I suggest we create a page and describe preferred method of dealing with
>>> the lists and document it.
>>> Also do the same with the manual, i.e. review it to make sure we do not
>>> show CSV syntax in the docs, same with the man pages.
>>> On the project page we will say that CSV will not be added to the new
>>> and existing commands and will be deprecated over time (probably by IPA
>>> version 4).
>>> Do I get it right?
>>>
>>
>> I'm not sure both are currently supported. I'm not sure we permit
>> multiple args with the same name and aggregate them, I thought that was
>> part of the proposal.
>>
> 
> We do support multiple arguments.
> 
> The trouble with CSV is that to put commas (or in some cases double quotes) in
> the data, they need to be escaped in a way that's not intuitive. The proposal
> is to change this, so that instead of
> --txt-rec='"""created on 13:01:23"""'
> you can use just
> --txt-rec='"created on 13:01:23"'
> and instead of
> --txt-rec='Record one, record two'
> you need to say
> --txt-rec={'Record one','record two'}
> The assumption is that this makes more sen

Re: [Freeipa-users] openldap to ipa

2013-01-14 Thread Johnathan Phan

Hi Aquino,

thanks for the input, however. There is a CRT in there already and it was
set to allow on both the IPA server and the target openldap server.
the core of the issue seems to be that IPA does not accept the cert either
locally or remotely as it does not trust it.

anyone know how I can troubleshot this. I have reviewed the dirsrv logs for
ldap and I can't spot anything/.

Regards
John

On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino  wrote:

> Try editing /etc/openldap/ldap.conf:
>
> TLS_CACERT  /etc/ipa/ca.crt
> TLS_REQCERT allow
>
>
> See if that helps
>
> "Keeping your head in the cloud"
> ~
> Jr Aquino | Sr. Information Security Specialist
> GIAC Exploit Researcher and Advanced Penetration Tester |
> GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
> Citrix Online | 7408 Hollister Avenue | Goleta, CA
> 93117
> T:  +1 805.690.3478
> C: +1 805.717.0365
> jr.aqu...@citrix.com
> http://www.citrixonline.com
>
> On Jan 11, 2013, at 8:05 AM, Johnathan Phan  > wrote:
>
> Hi There,
>
> This is driving me up the wall.
>
> I have two servers. 1 is a live openldap/kerberous AAA server running on
> RHEL6. The LDAP service has SSL/TS support. The second server is a test
> environment running on fedora and has 3.1 IPA installed.
>
> As a last step of my POC I need to migrate the users and passwords from
> the LDAP server to IPA server.
>
> I ran this command perfectly fine.
>
> ipa config-mod --enable-migration=TRUE
>
> However the next step was where my issues began.
>
> In the end after a lot of IRC communication and troubleshooting I now run
> the following command.
>
> ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com"
> --user-container="ou=users,ou=live,dc=example,dc=com"
> --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps://
> ldap1.live.example.com
>
> I get the following error.
>
> ipa: DEBUG: Caught fault 4203 from server
> http://fedoraipaserver.test.example.com/ipa/xml: Can't contact LDAP
> server: TLS error -8179:Peer's Certificate issuer is not recognized.
> ipa: DEBUG: Destroyed connection context.xmlclient
> ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's Certificate
> issuer is not recognized.
>
> I have summarized that the IPA server does not trust the cert served by
> the openldap or the other way around. Does anyone know how to get around
> this? Or allow me to finish the migration of user data.
>
> Regards
>
> John
>
> --
> Johnathan Phan
>
> T: +44 (0)784 118 7080
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>

-- 
Johnathan Phan
ox-consulting

T: +44 (0)784 118 7080
j...@ox-consulting.com

www.ox-consulting.com

OX CONSULTING Ltd is registered in England & Wales, number: 07113039,
registered address as above.

The information contained in this email message may be privileged,
confidential or exempt from disclosure under applicable law. If you are not
the intended recipient, you are hereby notified that any use,
dissemination, distribution or copying of this transmission is strictly
prohibited. If you have received this communication in error, or if any
problems occur with transmission, please notify the sender immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] how do i apply patch?

2013-01-14 Thread Umarzuki Mochlis

2013/1/12 John Dennis :
> 1) Download the source rpm matching the version you have installed, add the
> patch, rebuild the rpm locally, install the locally built rpm.

how do i 'add the patch' to source rpm? any documentation that i can
follow to do this?

-- 
Regards,

Umarzuki Mochlis
http://debmal.my

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

Re: [Freeipa-users] openldap to ipa

2013-01-14 Thread Johnathan Phan

Anyone know the details of the low level system steps for the migration
script to work? so I can try and backwards engineer or troubleshoot each
system as I go along so I can actually migrate the data from openldap to
ipa?

Regards

John


On Mon, Jan 14, 2013 at 9:19 AM, Johnathan Phan wrote:

> Hi Aquino,
>
> thanks for the input, however. There is a CRT in there already and it was
> set to allow on both the IPA server and the target openldap server.
> the core of the issue seems to be that IPA does not accept the cert either
> locally or remotely as it does not trust it.
>
> anyone know how I can troubleshot this. I have reviewed the dirsrv logs
> for ldap and I can't spot anything/.
>
> Regards
> John
>
>
> On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino  wrote:
>
>> Try editing /etc/openldap/ldap.conf:
>>
>> TLS_CACERT  /etc/ipa/ca.crt
>> TLS_REQCERT allow
>>
>>
>> See if that helps
>>
>> "Keeping your head in the cloud"
>> ~
>> Jr Aquino | Sr. Information Security Specialist
>> GIAC Exploit Researcher and Advanced Penetration Tester |
>> GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
>> Citrix Online | 7408 Hollister Avenue | Goleta, CA
>> 93117
>> T:  +1 805.690.3478
>> C: +1 805.717.0365
>> jr.aqu...@citrix.com
>> http://www.citrixonline.com
>>
>> On Jan 11, 2013, at 8:05 AM, Johnathan Phan > > wrote:
>>
>> Hi There,
>>
>> This is driving me up the wall.
>>
>> I have two servers. 1 is a live openldap/kerberous AAA server running on
>> RHEL6. The LDAP service has SSL/TS support. The second server is a test
>> environment running on fedora and has 3.1 IPA installed.
>>
>> As a last step of my POC I need to migrate the users and passwords from
>> the LDAP server to IPA server.
>>
>> I ran this command perfectly fine.
>>
>> ipa config-mod --enable-migration=TRUE
>>
>> However the next step was where my issues began.
>>
>> In the end after a lot of IRC communication and troubleshooting I now run
>> the following command.
>>
>> ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com"
>> --user-container="ou=users,ou=live,dc=example,dc=com"
>> --group-container="ou=groups,ou=live,dc=example,dc=com" ldaps://
>> ldap1.live.example.com
>>
>> I get the following error.
>>
>> ipa: DEBUG: Caught fault 4203 from server
>> http://fedoraipaserver.test.example.com/ipa/xml: Can't contact LDAP
>> server: TLS error -8179:Peer's Certificate issuer is not recognized.
>> ipa: DEBUG: Destroyed connection context.xmlclient
>> ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's Certificate
>> issuer is not recognized.
>>
>> I have summarized that the IPA server does not trust the cert served by
>> the openldap or the other way around. Does anyone know how to get around
>> this? Or allow me to finish the migration of user data.
>>
>> Regards
>>
>> John
>>
>> --
>> Johnathan Phan
>>
>> T: +44 (0)784 118 7080
>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>
>
> --
> Johnathan Phan
> ox-consulting
>
>
> T: +44 (0)784 118 7080
> j...@ox-consulting.com
>
> www.ox-consulting.com
>
> OX CONSULTING Ltd is registered in England & Wales, number: 07113039,
> registered address as above.
>
> The information contained in this email message may be privileged,
> confidential or exempt from disclosure under applicable law. If you are not
> the intended recipient, you are hereby notified that any use,
> dissemination, distribution or copying of this transmission is strictly
> prohibited. If you have received this communication in error, or if any
> problems occur with transmission, please notify the sender immediately.
>



-- 
Johnathan Phan
ox-consulting

T: +44 (0)784 118 7080
j...@ox-consulting.com

www.ox-consulting.com

OX CONSULTING Ltd is registered in England & Wales, number: 07113039,
registered address as above.

The information contained in this email message may be privileged,
confidential or exempt from disclosure under applicable law. If you are not
the intended recipient, you are hereby notified that any use,
dissemination, distribution or copying of this transmission is strictly
prohibited. If you have received this communication in error, or if any
problems occur with transmission, please notify the sender immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] openldap to ipa

2013-01-14 Thread Rob Crittenden

Johnathan Phan wrote:

Anyone know the details of the low level system steps for the migration
script to work? so I can try and backwards engineer or troubleshoot each
system as I go along so I can actually migrate the data from openldap to
ipa?

The migration is taking place in the context of the web server. So any 
trust needs to be added to /etc/httpd/alias (and the httpd service 
restarted). It needs to trust the signer of the remote LDAP server. What 
I don't know is how you add trust in NSS for a self-signed server 
certificate. You might be best off issuing new SSL certs for your 
openldap server which uses a CA to issue the server cert in order to 
perform the migration.

rob

Regards

John

On Mon, Jan 14, 2013 at 9:19 AM, Johnathan Phan mailto:j...@ox-consulting.com>> wrote:

Hi Aquino,

thanks for the input, however. There is a CRT in there already and
it was set to allow on both the IPA server and the target openldap
server.
the core of the issue seems to be that IPA does not accept the cert
either locally or remotely as it does not trust it.

anyone know how I can troubleshot this. I have reviewed the dirsrv
logs for ldap and I can't spot anything/.

Regards
John

On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino mailto:jr.aqu...@citrix.com>> wrote:

Try editing /etc/openldap/ldap.conf:

TLS_CACERT  /etc/ipa/ca.crt
TLS_REQCERT allow

See if that helps

"Keeping your head in the cloud"
~
Jr Aquino | Sr. Information Security Specialist
GIAC Exploit Researcher and Advanced Penetration Tester |
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA
93117
T: +1 805.690.3478

C: +1 805.717.0365 
jr.aqu...@citrix.com
>
http://www.citrixonline.com

On Jan 11, 2013, at 8:05 AM, Johnathan Phan
mailto:j...@ox-consulting.com>>> wrote:

Hi There,

This is driving me up the wall.

I have two servers. 1 is a live openldap/kerberous AAA server
running on RHEL6. The LDAP service has SSL/TS support. The
second server is a test environment running on fedora and has
3.1 IPA installed.

As a last step of my POC I need to migrate the users and
passwords from the LDAP server to IPA server.

I ran this command perfectly fine.

ipa config-mod --enable-migration=TRUE

However the next step was where my issues began.

In the end after a lot of IRC communication and troubleshooting
I now run the following command.

ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com"
--user-container="ou=users,ou=live,dc=example,dc=com"
--group-container="ou=groups,ou=live,dc=example,dc=com"
ldaps://ldap1.live.example.com

I get the following error.

ipa: DEBUG: Caught fault 4203 from server
http://fedoraipaserver.test.example.com/ipa/xml: Can't contact
LDAP server: TLS error -8179:Peer's Certificate issuer is not
recognized.
ipa: DEBUG: Destroyed connection context.xmlclient
ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's
Certificate issuer is not recognized.

I have summarized that the IPA server does not trust the cert
served by the openldap or the other way around. Does anyone know
how to get around this? Or allow me to finish the migration of
user data.

Regards

John

--
Johnathan Phan

T: +44 (0)784 118 7080 

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

--
Johnathan Phan
ox-consulting

T: +44 (0)784 118 7080 
j...@ox-consulting.com 

www.ox-consulting.com 

OX CONSULTING Ltd is registered in England & Wales, number:
07113039, registered address as above.

The information contained in this email message may be privileged,
confidential or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any
use, dissemination, distribution or copying of this transmission is
strictly prohibited. If you have received this communication in
error, or if any problems occur wi

[Freeipa-users] compat and ou=People

2013-01-14 Thread Orion Poplawski

We're looking at migrating from 389ds to ipa.  Currently our users are in 
ou=People with rfc2307 attributes.  Is there any way to provide an 
ou=people,dc=nwra,dc=com compatibility group in IPA?  Or does everything have 
to remain under cn=compat?  We have a lot of references to 
ou=People,dc=nwra,dc=com in clients.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

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

Re: [Freeipa-users] compat and ou=People

2013-01-14 Thread Nalin Dahyabhai

On Mon, Jan 14, 2013 at 12:06:35PM -0700, Orion Poplawski wrote:
> We're looking at migrating from 389ds to ipa.  Currently our users
> are in ou=People with rfc2307 attributes.  Is there any way to
> provide an ou=people,dc=nwra,dc=com compatibility group in IPA?  Or
> does everything have to remain under cn=compat?  We have a lot of
> references to ou=People,dc=nwra,dc=com in clients.

Things show up under cn=compat because the Schema Compatibility plugin
is configured to put them there.  With a bit of manual configuration,
the compatibility user entries can show up under ou=People, too.  Here's
an initial guess at how that'd look, mostly copy/pasted from the compat
configuration:

  dn: ou=people,cn=Schema Compatibility,cn=plugins,cn=config
  schema-compat-entry-attribute: objectclass=posixAccount
  schema-compat-entry-attribute: gecos=%{cn}
  schema-compat-entry-attribute: cn=%{cn}
  schema-compat-entry-attribute: uidNumber=%{uidNumber}
  schema-compat-entry-attribute: gidNumber=%{gidNumber}
  schema-compat-entry-attribute: loginShell=%{loginShell}
  schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
  ou: people
  objectClass: top
  objectClass: extensibleObject
  schema-compat-search-filter: objectclass=posixAccount
  schema-compat-entry-rdn: uid=%{uid}
  schema-compat-search-base: cn=users, cn=accounts, dc=nwra,dc=com
  schema-compat-container-group: ou=people,dc=nwra,dc=com

You'd need to stop the directory server, add this to its dse.ldif file,
and start it up again.

HTH,

Nalin

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

Re: [Freeipa-users] compat and ou=People

2013-01-14 Thread Orion Poplawski


On 01/14/2013 01:40 PM, Nalin Dahyabhai wrote:

On Mon, Jan 14, 2013 at 12:06:35PM -0700, Orion Poplawski wrote:

We're looking at migrating from 389ds to ipa.  Currently our users
are in ou=People with rfc2307 attributes.  Is there any way to
provide an ou=people,dc=nwra,dc=com compatibility group in IPA?  Or
does everything have to remain under cn=compat?  We have a lot of
references to ou=People,dc=nwra,dc=com in clients.


Things show up under cn=compat because the Schema Compatibility plugin
is configured to put them there.  With a bit of manual configuration,
the compatibility user entries can show up under ou=People, too.  Here's
an initial guess at how that'd look, mostly copy/pasted from the compat
configuration:

   dn: ou=people,cn=Schema Compatibility,cn=plugins,cn=config
   schema-compat-entry-attribute: objectclass=posixAccount
   schema-compat-entry-attribute: gecos=%{cn}
   schema-compat-entry-attribute: cn=%{cn}
   schema-compat-entry-attribute: uidNumber=%{uidNumber}
   schema-compat-entry-attribute: gidNumber=%{gidNumber}
   schema-compat-entry-attribute: loginShell=%{loginShell}
   schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
   ou: people
   objectClass: top
   objectClass: extensibleObject
   schema-compat-search-filter: objectclass=posixAccount
   schema-compat-entry-rdn: uid=%{uid}
   schema-compat-search-base: cn=users, cn=accounts, dc=nwra,dc=com
   schema-compat-container-group: ou=people,dc=nwra,dc=com

You'd need to stop the directory server, add this to its dse.ldif file,
and start it up again.

HTH,

Nalin



Great, that seems to work well.  Thanks!

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

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

[Freeipa-users] Process conflict issue when restarting IPA

2013-01-14 Thread William Muriithi

Hello

When I restart IPA through  ipactl, I get the following message.  All
seem to be working despite the message.  I think it is pki-ca that is
running on tomcat

Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker
ajp://localhost:9447/ already used by another worker
[Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already
used by another worker

I assume there may be a bug on the ipactl script, is this a correct assumption?

Regards

William

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

Re: [Freeipa-users] Process conflict issue when restarting IPA

2013-01-14 Thread Dmitri Pal

On 01/14/2013 05:59 PM, William Muriithi wrote:
> Hello
>
> When I restart IPA through  ipactl, I get the following message.  All
> seem to be working despite the message.  I think it is pki-ca that is
> running on tomcat
>
> Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker
> ajp://localhost:9447/ already used by another worker
> [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already
> used by another worker
>
> I assume there may be a bug on the ipactl script, is this a correct 
> assumption?
>
> Regards
>
> William
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
Which version you are on?

This issue seems to be addressed quite some time ago
https://fedorahosted.org/freeipa/ticket/2333
https://bugzilla.redhat.com/show_bug.cgi?id=785791

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

[Freeipa-users] JSON-RPC documentation?

2013-01-14 Thread Brian Smith

Before I pester the dev list, I was wondering if anyone here could point me
to documentation on the JSON-RPC interface to FreeIPA.  I'm not doing
anything fancy, just adding users and updating passwords, so my
requirements are pretty tame.  I've gone through the Python code and have
somewhat pieced it together myself, but would be more comfortable if there
were official docs.

Thanks,

-- 
Brian Smith
Assistant Director
Research Computing, University of South Florida
4202 E. Fowler Ave. SVC4010
Office Phone: +1 813 974-1467
Organization URL: http://rc.usf.edu
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] JSON-RPC documentation?

2013-01-14 Thread Dmitri Pal

On 01/14/2013 08:16 PM, Brian Smith wrote:
> Before I pester the dev list, I was wondering if anyone here could
> point me to documentation on the JSON-RPC interface to FreeIPA.  I'm
> not doing anything fancy, just adding users and updating passwords, so
> my requirements are pretty tame.  I've gone through the Python code
> and have somewhat pieced it together myself, but would be more
> comfortable if there were official docs.
>
I do not remember us having documentation about XML-RPC but I will check.
We are actually debating deprecating XML-RPC over time in favor of JSON.

> Thanks,
>
> -- 
> Brian Smith
> Assistant Director
> Research Computing, University of South Florida
> 4202 E. Fowler Ave. SVC4010
> Office Phone: +1 813 974-1467
> Organization URL: http://rc.usf.edu
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] JSON-RPC documentation?

2013-01-14 Thread Rob Crittenden


Dmitri Pal wrote:

On 01/14/2013 08:16 PM, Brian Smith wrote:

Before I pester the dev list, I was wondering if anyone here could
point me to documentation on the JSON-RPC interface to FreeIPA.  I'm
not doing anything fancy, just adding users and updating passwords, so
my requirements are pretty tame.  I've gone through the Python code
and have somewhat pieced it together myself, but would be more
comfortable if there were official docs.


I do not remember us having documentation about XML-RPC but I will check.
We are actually debating deprecating XML-RPC over time in favor of JSON.


There is no official documentation on either XML-RPC or JSON. The format 
is rather straightforward once you get the hang of things. Each command 
is effectively an RPC function (e.g ipa user-add -> user_add). The 
arguments consist of positional arguments followed by named arguments 
(there is usually only one positional arg).


For XML-RPC it is generally fairly easy to work out what it's doing by 
adding -vv option to the command-line to see the raw request and 
response. I personally haven't done a lot of raw JSON work.


The final option is to skip all that and use the ipalib to do the work 
for you.


For example, to add a user you'd do something like:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
api.Command['user_add'](u'newuser',
loginshell=u'/bin/something',
givenname=u'New', sn=u'User')
except errors.DuplicateEntry:
print "user already exists"
else:
print "user added"

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

Re: [Freeipa-users] JSON-RPC documentation?

2013-01-14 Thread Brian Smith

That helps a lot.  Thanks!  I would use ipalib, but I'm developing a Rails
application, so the JSON interface is the quickest (and since XML may be
deprecated) best way forward (unless you know a way to use it in Ruby :).
 I'm guessing in JSON, the structure would look something like this:

{
  "method": "user_add",
  "params": [
[],
{
  "uid":"testuser",
  "givenname":"Test",
  "sn":"User",
  "userpassword":"mySecretPasswordBlahBlah"
  ...
}
  ]
}

Maybe I'll try to compile some documentation.  I know that this page helped
a lot, to cook up a quick ruby client with Curb:
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/


On Mon, Jan 14, 2013 at 9:35 PM, Rob Crittenden  wrote:

> Dmitri Pal wrote:
>
>> On 01/14/2013 08:16 PM, Brian Smith wrote:
>>
>>> Before I pester the dev list, I was wondering if anyone here could
>>> point me to documentation on the JSON-RPC interface to FreeIPA.  I'm
>>> not doing anything fancy, just adding users and updating passwords, so
>>> my requirements are pretty tame.  I've gone through the Python code
>>> and have somewhat pieced it together myself, but would be more
>>> comfortable if there were official docs.
>>>
>>>  I do not remember us having documentation about XML-RPC but I will
>> check.
>> We are actually debating deprecating XML-RPC over time in favor of JSON.
>>
>
> There is no official documentation on either XML-RPC or JSON. The format
> is rather straightforward once you get the hang of things. Each command is
> effectively an RPC function (e.g ipa user-add -> user_add). The arguments
> consist of positional arguments followed by named arguments (there is
> usually only one positional arg).
>
> For XML-RPC it is generally fairly easy to work out what it's doing by
> adding -vv option to the command-line to see the raw request and response.
> I personally haven't done a lot of raw JSON work.
>
> The final option is to skip all that and use the ipalib to do the work for
> you.
>
> For example, to add a user you'd do something like:
>
> from ipalib import api
> from ipalib import errors
>
> api.bootstrap(context='cli')
> api.finalize()
> api.Backend.xmlclient.connect(**)
>
> try:
> api.Command['user_add'](u'**newuser',
> loginshell=u'/bin/something',
> givenname=u'New', sn=u'User')
> except errors.DuplicateEntry:
> print "user already exists"
> else:
> print "user added"
>
>
> __**_
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/**mailman/listinfo/freeipa-users
>



-- 
Brian Smith
Assistant Director
Research Computing, University of South Florida
4202 E. Fowler Ave. SVC4010
Office Phone: +1 813 974-1467
Organization URL: http://rc.usf.edu
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] DNS chages made from the WebUI take a long time to be recognized.

2013-01-14 Thread Tim Hildred

Should it take several hours for me to be able to ping a host at it's new IP 
address when I update the DNS record in the WebUI?

I deleted the old records (A and PTR), and added new records for the same FQDN, 
with a different IP address. But I can't ping the host using the FQDN. 

Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thild...@redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred

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

Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?

Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?

Re: [Freeipa-users] openldap to ipa

Re: [Freeipa-users] how do i apply patch?

Re: [Freeipa-users] openldap to ipa

Re: [Freeipa-users] openldap to ipa

[Freeipa-users] compat and ou=People

Re: [Freeipa-users] compat and ou=People

Re: [Freeipa-users] compat and ou=People

[Freeipa-users] Process conflict issue when restarting IPA

Re: [Freeipa-users] Process conflict issue when restarting IPA

[Freeipa-users] JSON-RPC documentation?

Re: [Freeipa-users] JSON-RPC documentation?

Re: [Freeipa-users] JSON-RPC documentation?

Re: [Freeipa-users] JSON-RPC documentation?

[Freeipa-users] DNS chages made from the WebUI take a long time to be recognized.

16 matches

Site Navigation

Mail list logo

Footer information