<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 02/02/2011 04:02 PM, Ian Stokes-Rees wrote: <blockquote cite="mid:4D49C682.2090406@hkl.hms.harvard.edu" type="cite"> <blockquote type="cite"> <pre wrap=""> Can this wait till next week? If not it would be a real pity. We are working hard to deliver the project to research groups like yours and we will do our best to help you to migrate your data forward. </pre> </blockquote> <pre wrap=""> We will probably decide what path to take tomorrow. I'm not sure if we're prepared to wait, since waiting 1 week will probably only get us using the new Beta-2, and won't solve any problems for Beta-3 or official release of 2.0. </pre> <blockquote type="cite"> <pre wrap="">To reduce the scope of the effort let me recap the goal: 1) You want to install IPA and load the users (is there anything else?) from the previous installation and abandon the old installation </pre> </blockquote> <pre wrap=""> I'm not sure the details of everything that is in FreeIPA, but I think right now it is at least user information and NFS mounts. Possible more. We have 10-20 accounts, so not much. </pre> </blockquote> NFS mount schema is the same and standard 2307bis so there is no difference between the versions. The only issue can be the location of the container since we did some rearrangement of the tree recently. But there is no crypto or hashes there so dumping the cn=automount and loading it into the new version should be straightforward exercise. For the users migrate-ds should be used then. It will take user accounts from the old installation and move to the new one. If you use SSSD on the client in the migration mode then it will recreated migrated kerberos hashes behind the scenes as soon as you log into a client machine using SSSD after migration. If migrate-ds does not work for you then we need to know all the details and logs of what went wrong so that we can fix the issue. <blockquote cite="mid:4D49C682.2090406@hkl.hms.harvard.edu" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">2) You do not want to loose passwords </pre> </blockquote> <pre wrap=""> I don't really care about this. We can loose all passwords as far as I'm concerned. Peter, the other person who has been on this thread and the one who has done all the work, may have a different opinion. </pre> </blockquote> The procedure described above, i.e. using SSSD on the client will solve the problem of the password migration if you care. <blockquote cite="mid:4D49C682.2090406@hkl.hms.harvard.edu" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">3) You are Ok with manual procedure 4) You are Ok to try different approaches (some of which might not work out) and work with us on formulating a procedure that would help other deployments like yours to overcome this situation. </pre> </blockquote> <pre wrap=""> Yes, we're OK to try manual procedures and different approaches, *if* we decide it is worth sticking with FreeIPA. </pre> </blockquote> This is your decision to make. <blockquote cite="mid:4D49C682.2090406@hkl.hms.harvard.edu" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">Again sorry for all the trouble. If we knew the requirement to be able to migrate between betas earlier we might have done some things differently. Hope to find understanding on your side and willingness to work with us on a solution. </pre> </blockquote> <pre wrap=""> How did you expect anyone to seriously try to use FreeIPA if they couldn't migrate between versions? Surely installation and extended use (weeks/months) by non-developers is part of any beta-testing plan. </pre> </blockquote> They are not "migratable" versions. Frankly I have not heard of any product of such complexity that would support migration between the alpha-beta-rc drops. Sorry but your expectation is wrong. It is our fault that we have not clearly stated it but this is the case. And yes, just to set expectations straight, when we release IPA v2 we expect it to be a fresh install and users migrated to it using migrate-ds and passwords migrated using SSSD or a special migration page we provide. Other parts of the tree can be migrated piecemeal and we will be happy to help you do it if migrating this part of information is possible. For example migrating hosts and service will not be possible but sudo, HBAC, DNS etc. will be, so discretion should be used depending upon what you have in your deployment. However if we are talking about 10-20 accounts it might be easier to recreate them manually or with a simple script. Overall we appreciate your business and would be glad to help within the reasonable expectations. Thank you, Dmitri <blockquote cite="mid:4D49C682.2090406@hkl.hms.harvard.edu" type="cite"> <pre wrap="">Regards, Ian </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ Freeipa-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre> </blockquote> <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? <a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a> </pre> </body> </html>