Re: [Freeipa-users] UID 999, not possible?

2012-07-03 Thread Petr Viktorin

On 07/03/2012 05:55 AM, Nathan Kinder wrote:

On 06/29/2012 07:10 AM, Petr Viktorin wrote:

On 06/29/2012 03:55 PM, Alexander Bokovoy wrote:

On Fri, 29 Jun 2012, Petr Viktorin wrote:

On 06/29/2012 03:04 PM, Alexander Bokovoy wrote:

On Thu, 28 Jun 2012, sysad...@noboost.org wrote:

Hi All,

Is there a weird restriction to UID 999 in ipa, as IPA keeps changing
the UID when I add a user with that number? (I've already checked the
UID isn't in use)

We use 999 as a marker for DNA plugin. UID/GID 999 is replaced by
an allocated one with the help of the 389-ds plugin
http://directory.fedoraproject.org/wiki/DNA_Plugin
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Defining_Dynamic_Atrribute_Values.html#about-dunamically-assigning-attribute-values




The documentation mentions that the magic value can be a word
(magic), or it doesn't have to exist at all (it's added for
objectClass:posixAccount entries). Is there a reason IPA is using 999
here?

uidNumber and gidNumber field use integer value syntax:
OID value: 1.3.6.1.4.1.1466.115.121.1.27

OID description:
Values in this syntax are encoded as the decimal representation of their
values, with each decimal digit represented by the its character
equivalent. So the number 1321 is represented by the character string
1321.
So, you can't have string there that does not evaluate to integer.


That's true, but according to the documentation you linked,
uidNumber/gidNumber syntax doesn't matter.
The dnaMagicRegen field is in fact a DirectoryString. I assume the DNA
plugin sees and modifies the value before it's validated as an integer.

I wouldn't trust this, as DNA was initially designed/implemented before
we added syntax validation to 389.  DNA was also written to be able to
work with non integer attributes, where values have some sort of prefix
followed by an integer (such as user1, user2, etc.).  For this
reason, dnaMagicRegen was left as Directory String syntax.  I
personally feel that it is safer to have the magic value be
syntactically valid for the attribute that DNA is configured to generate.


Best go with a negative number then.
The DS docs should be updated if you don't trust what they say, though.


On 06/29/2012 04:23 PM, Alexander Bokovoy wrote:
 Looks like you are right:
 http://comments.gmane.org/gmane.linux.redhat.fedora.directory.user/10641

 We would have issue on our side when using non-integer value as Int()
 parameter does not support non-integer values. However, we could select
 some negative value as default one and use the same value for DNA
 configuration.

The value can be optional, the server can fill in the default if it's 
not received from the client.


--
PetrĀ³

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


Re: [Freeipa-users] UID 999, not possible?

2012-07-03 Thread Nathan Kinder

On 07/03/2012 12:38 AM, Petr Viktorin wrote:

On 07/03/2012 05:55 AM, Nathan Kinder wrote:

On 06/29/2012 07:10 AM, Petr Viktorin wrote:

On 06/29/2012 03:55 PM, Alexander Bokovoy wrote:

On Fri, 29 Jun 2012, Petr Viktorin wrote:

On 06/29/2012 03:04 PM, Alexander Bokovoy wrote:

On Thu, 28 Jun 2012, sysad...@noboost.org wrote:

Hi All,

Is there a weird restriction to UID 999 in ipa, as IPA keeps 
changing
the UID when I add a user with that number? (I've already 
checked the

UID isn't in use)

We use 999 as a marker for DNA plugin. UID/GID 999 is replaced by
an allocated one with the help of the 389-ds plugin
http://directory.fedoraproject.org/wiki/DNA_Plugin
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Defining_Dynamic_Atrribute_Values.html#about-dunamically-assigning-attribute-values 






The documentation mentions that the magic value can be a word
(magic), or it doesn't have to exist at all (it's added for
objectClass:posixAccount entries). Is there a reason IPA is using 999
here?

uidNumber and gidNumber field use integer value syntax:
OID value: 1.3.6.1.4.1.1466.115.121.1.27

OID description:
Values in this syntax are encoded as the decimal representation of 
their

values, with each decimal digit represented by the its character
equivalent. So the number 1321 is represented by the character string
1321.
So, you can't have string there that does not evaluate to integer.


That's true, but according to the documentation you linked,
uidNumber/gidNumber syntax doesn't matter.
The dnaMagicRegen field is in fact a DirectoryString. I assume the DNA
plugin sees and modifies the value before it's validated as an integer.

I wouldn't trust this, as DNA was initially designed/implemented before
we added syntax validation to 389.  DNA was also written to be able to
work with non integer attributes, where values have some sort of prefix
followed by an integer (such as user1, user2, etc.).  For this
reason, dnaMagicRegen was left as Directory String syntax.  I
personally feel that it is safer to have the magic value be
syntactically valid for the attribute that DNA is configured to 
generate.


Best go with a negative number then.
The DS docs should be updated if you don't trust what they say, though.
I should have been a bit more clear.  I believe that the core 389 DS 
code does handle replacing the magic value before the syntax is checked, 
but we have encountered issues with client applications trying to 
enforce syntax before the server receives the operation. An example of 
this is the 389-console application (which FreeIPA doesn't use).  The 
Console knows that the uidNumber attribute is defined to use the Integer 
syntax, so the UI field is validated before it can be submitted to the 
server.  Other client applications may do similar things by looking up 
the schema definitions on the server and trying to do some client-side 
validation.  This sort of behavior prevents the ability to trigger DNA 
if the magic value does not meet the syntax requirements of the 
attribute.  Again, this may not affect FreeIPA, but I wanted to provide 
a bit of background.



On 06/29/2012 04:23 PM, Alexander Bokovoy wrote:
 Looks like you are right:
 
http://comments.gmane.org/gmane.linux.redhat.fedora.directory.user/10641


 We would have issue on our side when using non-integer value as Int()
 parameter does not support non-integer values. However, we could select
 some negative value as default one and use the same value for DNA
 configuration.

The value can be optional, the server can fill in the default if it's 
not received from the client.





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


[Freeipa-users] win7 client

2012-07-03 Thread george he
Hello all,

I'm trying to set up a win7 as a client of my freeipa server running on fc17. 
so I followed the instructions here:

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_Microsoft_Windows.html
But then what? The win7 is currently in a workgroup. I tried to join the win7 
to a domain with my ipa realm name, but it failed.
Thanks in advance for your help,
George___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] FreeIPA DNS manager

2012-07-03 Thread Josh Becigneul

Hi All,

I'd like to get some opinions on using the DNS component of freeIPA to 
manage dns zones not necessarily associated with the freeIPA realm.


My thinking is to use it as a hidden master to a pre-existing group of 
authoritative systems, so one thing I'm curious about is is there a 
theoretical (or real) limit on the number of zones it can handle? Is 
there a limit to the number of records in a zone? I would think that 
this may depend on the performance of the 389 directory service.


Is it possible to import existing zones? Would this be possible with 
zone transfers or would we have to convert the zone files to an LDIF?


Thanks in advance.

Josh Becigneul

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