[Freeipa-users] Exporting data?

[Bret Wortman]

That worked for one out of 24 zones. Dig gave the same error on the rest:

# dig +onesoa -t AXFR foo.net

; <<>> DiG 99.3-rl.156.01-P1-RedHat-9.9.3-3.P1.fc18 <<>> +onesoa -t AXFR
foo.net
;; global options: +cmd
; Transfer failed.
#

/var/log/messages errors at the same time with:

named[925]: LDAP error: Size limit exceeded
named[925]: connection to the LDAP server was lost
named[925]: successfully reconnected to LDAP server

I think my master has, to stick with technical terminology, "completely
lost the plot". And I'm equally certain it's because of something I did to
it....


*
*
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret


On Thu, Sep 5, 2013 at 7:48 AM, Bret Wortman
<bret.wortman at damascusgrp.com>wrote:

> D'Oh! Thanks, Petr.
>
>
> *
> *
> *Bret Wortman*
>
> http://damascusgrp.com/
> http://about.me/wortmanbret
>
>
> On Thu, Sep 5, 2013 at 2:33 AM, Petr Spacek <pspacek at redhat.com> wrote:
>
>> On 4.9.2013 20:23, Bret Wortman wrote:
>>
>>> ...and I tried exporting the DNS data but ended up with a bunch of files
>>> that looked liket his:
>>>
>>> # cat foo.net.db
>>>
>>> ; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.**3-3.P1.fc18 <<>> +onesoa -t
>>> AXFR
>>> foo.net
>>> ;; global options: +cmd
>>> ; Transfer failed.
>>> #
>>>
>>> The logs showed:
>>>
>>> <timestamp> ipamaster named[31633]: client 1.2.3.4#39992 (foo.net) :
>>> zone
>>> transfer 'foo.net/AXFR/IN' denied
>>>
>>
>> You have to add IP '1.2.3.4' to the allow-transfer Address List Match.
>>
>> $ ipa dnszone-mod --allow-transfer='localhost; 1.2.3.4;'
>>
>> See
>> http://www.zytrax.com/books/**dns/ch7/address_match_list.**html<http://www.zytrax.com/books/dns/ch7/address_match_list.html>
>> for further details.
>>
>> Petr^2 Spacek
>>
>>
>>  On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce <simo at redhat.com> wrote:
>>>
>>>  On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote:
>>>>
>>>>> On 09/04/2013 09:26 AM, Petr Spacek wrote:
>>>>>
>>>>>> On 4.9.2013 15:04, Bret Wortman wrote:
>>>>>>
>>>>>>> What's the right venue for making a suggestion? In particular, I'd
>>>>>>> like to
>>>>>>> toss out there that it would be really nice to be able to export, at
>>>>>>> a
>>>>>>> minimum, DNS and user data from IPA in the form of a zone file and a
>>>>>>> passwd/shadow file pair.
>>>>>>>
>>>>>>> I realize there might be security implications to the latter, and
>>>>>>> masking
>>>>>>> out passwords might be advisiable. And there's no easy way,
>>>>>>> necessarily, to
>>>>>>> get out sudo information. But having DNS and user details would at
>>>>>>>
>>>>>> least
>>>>
>>>>> permit a sysadmin having major issues (like I have been for the past
>>>>>>>
>>>>>> two
>>>>
>>>>> weeks) to get up and running in some form, using puppet or some other
>>>>>>> tool
>>>>>>> to distribute flat files with named running against a static zone
>>>>>>> file, or
>>>>>>> even to migrate off IPA if absolutely necessary.
>>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> for DNS you can use normal zone transfer. Just configure IPA zone to
>>>>>> allow zone transfer to an IP address (localhost means 'localy to IPA
>>>>>> server') and use standard DNS tools, e.g. dig:
>>>>>>
>>>>>> $ ipa dnszone-mod example.com --allow-transfer='localhost;'
>>>>>> $ dig +onesoa -t AXFR example.com > /root/example.com.db
>>>>>>
>>>>>> That is all you need for DNS, you have the standard zone file.
>>>>>>
>>>>>>
>>>>>> I believe that you can use SSSD (with enumeration enabled) to run
>>>>>> "getent passwd > /root/passwd.bck". I have no idea how it works with
>>>>>> shadow map/password. Try to ask sssd-users at lists.fedorahosted.**org<sssd-users at lists.fedorahosted.org>
>>>>>> .
>>>>>>
>>>>>>  And to add to it:
>>>>> IPA does not keep password in clear or the hashes that are used in
>>>>> passwd and shadow files for security reasons so it can't generate these
>>>>> files as you suggest.
>>>>>
>>>>
>>>> We do have hashes, the default is SHA256, it is stored in userPassword
>>>> and is used to validate LDAP binds, however we never let it out of LDAP,
>>>> neither SSSD not the integrate NIS server expose the password hash to
>>>> clients. You need Directory Manager privileges to read it.
>>>>
>>>
>> ______________________________**_________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130905/c4c20938/attachment.htm>