<div dir="ltr">My problems all seem to be with replication (see the threads with subjects "Scorched earth" and "Replication woes"), and Rob has found an engineer willing to look at log files for me. My problem is in getting the log files over to you for analysis. The system I'm working with is on a private network, so getting the logs off isn't trivial.<div>
<br></div><div>In my case I'm looking for a way to basically start over with as little heartache as possible, and so far, after two weeks of trial and error, we're no closer to being restarted than we were, well, two weeks ago. My customer is getting antsy and I need to return our network to fully operational within the next 24-48 hours or I'm going to have to nuke it and start all over, which I know involves re-registering every single system with the new master (because it'll be a new CA) and entering the new users again, and setting up DNS over again. Which is why I was looking for a way to export as much as possible right now so I can re-import in case the worst happens and I have to nuke all my IPA servers and start over from scratch.</div>
<div><br></div><div>I realize that no one can debug without logs and detailed information. It's just taken a long time to get to where I am, and it takes a full 24 hours or more for me to respond to any request for more detail.</div>
<div><br></div><div>In other words, I'm trying to leave my system as it is so we can try to solve the problem it has and minimize the recovery effort, but I have to balance that against my need to get my network operational again, and we're having many, many problems with SSH, SSSD and other services since we don't have a single IPA server in the mix that's fully functional right now. My master is crippled with replication requests and the one good copy I made couldn't get the CA transfer to work.</div>
<div><br></div><div>Frustrating for you because I can't always give quick data. Frustrating all around. But we'll get through it one way or the other. I hope to have the latest batch of logs over for analysis later this morning.</div>
<div><br></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><br></div><div><u><br></u></div><div><b>Bret Wortman</b></div><div><img src="http://damascusgrp.com/item/51f7de33e4b08d2bdb8b4860?format=1500w" width="200" height="53"><br>
</div><div><a href="http://damascusgrp.com/" target="_blank">http://damascusgrp.com/</a><br></div><div><a href="http://about.me/wortmanbret" target="_blank">http://about.me/wortmanbret</a><br></div></div></div>
<br><br><div class="gmail_quote">On Wed, Sep 4, 2013 at 9:40 AM, Dmitri Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 09/04/2013 09:26 AM, Petr Spacek wrote:<br>
> On 4.9.2013 15:04, Bret Wortman wrote:<br>
>> What's the right venue for making a suggestion? In particular, I'd<br>
>> like to<br>
>> toss out there that it would be really nice to be able to export, at a<br>
>> minimum, DNS and user data from IPA in the form of a zone file and a<br>
>> passwd/shadow file pair.<br>
>><br>
>> I realize there might be security implications to the latter, and<br>
>> masking<br>
>> out passwords might be advisiable. And there's no easy way,<br>
>> necessarily, to<br>
>> get out sudo information. But having DNS and user details would at least<br>
>> permit a sysadmin having major issues (like I have been for the past two<br>
>> weeks) to get up and running in some form, using puppet or some other<br>
>> tool<br>
>> to distribute flat files with named running against a static zone<br>
>> file, or<br>
>> even to migrate off IPA if absolutely necessary.<br>
><br>
> Hello,<br>
><br>
> for DNS you can use normal zone transfer. Just configure IPA zone to<br>
> allow zone transfer to an IP address (localhost means 'localy to IPA<br>
> server') and use standard DNS tools, e.g. dig:<br>
><br>
> $ ipa dnszone-mod <a href="http://example.com" target="_blank">example.com</a> --allow-transfer='localhost;'<br>
> $ dig +onesoa -t AXFR <a href="http://example.com" target="_blank">example.com</a> > /root/example.com.db<br>
><br>
> That is all you need for DNS, you have the standard zone file.<br>
><br>
><br>
> I believe that you can use SSSD (with enumeration enabled) to run<br>
> "getent passwd > /root/passwd.bck". I have no idea how it works with<br>
> shadow map/password. Try to ask <a href="mailto:sssd-users@lists.fedorahosted.org">sssd-users@lists.fedorahosted.org</a>.<br>
><br>
</div></div>And to add to it:<br>
IPA does not keep password in clear or the hashes that are used in<br>
passwd and shadow files for security reasons so it can't generate these<br>
files as you suggest.<br>
<br>
It is unclear what the problems are that you are facing and what made<br>
you get back to local files.<br>
I agree with Petr that SSSD has a lot of bells and whistles to make your<br>
client experience smooth and help you recover from any server side<br>
problems you might have.<br>
<br>
But may be we are missing something  and there is something we can do.<br>
If you can describe the problem you are facing we might be able to<br>
suggest a solution.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thank you,<br>
Dmitri Pal<br>
<br>
Sr. Engineering Manager for IdM portfolio<br>
Red Hat Inc.<br>
<br>
<br>
-------------------------------<br>
Looking to carve out IT costs?<br>
<a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
</div></div></blockquote></div><br></div>