On 02/02/2011 04:02 PM, Ian Stokes-Rees wrote:
>> 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.
> 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.
>> 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
> 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.
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.
>> 2) You do not want to loose passwords
> 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.
The procedure described above, i.e. using SSSD on the client will solve
the problem of the password migration if you care.
>> 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.
> Yes, we're OK to try manual procedures and different approaches, *if* we
> decide it is worth sticking with FreeIPA.
This is your decision to make.
>> 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
>> Hope to find understanding on your side and willingness to work with
>> us on a solution.
> 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.
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
> Freeipa-users mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list