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.wort...@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 <pspa...@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 <s...@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@lists.fedorahosted.**org<sssd-us...@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@redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users> >> > >
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users