fedora-infra / fas2ipa Goto Github PK

View Code? Open in Web Editor NEW

2.0 9.0 7.0 261 KB

FAS -> IPA import script

License: MIT License

Dockerfile 0.44% Python 99.21% Shell 0.34%

fas2ipa's Introduction

fas2ipa

Assumptions:

Account with admin privileges on the IPA server
Account with privileges enough to dump users and groups in FAS
python-fedora, python-requests, python_freeipa, progressbar2

Development environment

Vagrant allows contributors to get quickly up and running with a development environment by automatically configuring a virtual machine running FreeIPA. To get started, first install the Vagrant and Virtualization packages needed, and start the libvirt service:

$ sudo dnf install ansible libvirt vagrant-libvirt vagrant-sshfs vagrant-hostmanager
$ sudo systemctl enable libvirtd
$ sudo systemctl start libvirtd

Check out the code and run vagrant up:

$ git clone https://github.com/fedora-infra/fas2ipa
$ cd fas2ipa
$ vagrant up

Your newly installed IPA Server will be viewable on your host machine at http://ipa.fas2ipa.test

Next, SSH into your newly provisioned development environment:

$ vagrant ssh

After initial setup, you will need to add FAS credentials to /vagrant/config.toml by replacing the following two lines in that file:

[fas]
# username =
# password =

The vagrant machine has a handful of aliases configured to help development.

fas2ipa-resetdata restores the freeIPA data to a backup that was taken during the provisioning of the vagrant machine

fas2ipa-run runs the tool itself

fas2ipa's People

Contributors

Stargazers

Watchers

Forkers

stephencoady ryanlerch abompard nphilipp tubbz-alt markobrien1 seanpm2001

fas2ipa's Issues

MIgrate more user attributes

SInce the last time the import script was updated, there have been a few attributes added and updated to freeipa-fas fasuser.

Need to change this import script to include these changes

Doing some extra checks when importing users

Discussed today with @abompard so creating issue here to track the request.
As we'll have also to migrate CentOS users (from the https://accounts.centos.org FAS instance), we should verify in case of name conflict that user from one side is indeed user from the other side.
Let's assume that we have user1 existing in FAS and then we try to import CentOS Account, but that we also have user user1 in FAS/IPA, we should verify/confirm that it's indeed same user before just adding existing user into groups that were also migrated.

There is indeed no nickname protection, so the only "primary key" to validate that same nickname is the same user is to validate that email address (validated on each side) is indeed the same, and if not, not do anything (not adding existing user in groups) but mark these in a "to be processed later" state.

From that report, we can reach out to users in such state and ask them to change/update their email address to match in both FAS and ACO and then put users into correct groups. If not, (and same nickname mismatch, aka same nickname for different users), we should discuss how to handle that, but probably just put new nickname in correct groups

User's fullname are not synced additively

There's a case of a user with a fullname attribute in CentOS, but no fullname in FAS, that ends up with no firstname/lastname in IPA (they have the standard "unset" fillers). See user carlwgeorge. The fullname sync should be additive.

Migrate group attributes

Since fedora-infra/freeipa-fas#104, groups have attributes in FreeIPA, so they should be migrated.

Default locale/timezone are vague

If a user doesn't have a locale or timezone setup, the dropdown boxes default to af-ZA and Africa/Abidjan respectively.
Maybe it's a good idea to put an empty value as option for these fields.

Migrate FPCA details

Now we have agreements in freeipa-fas, we need to migrate the FPCA over to ipa. and make everyone that has previously signed the agreement, signed in the new system

Improve the fas2ipa import speed

FAS2IPA could be made a lot faster if we disable the memberOf plugin in IPA. See this email.

To test it, we need to remove all the users and all the groups from the current staging database and do a full import run again.

The conflicts report crashes because sets are not JSON-serializable

Traceback (most recent call last):
  File "./venv/bin/fas2ipa", line 5, in <module>
    cli() 
[...]                                                                                                                                                                                                        
  File "./fas2ipa/cli.py", line 211, in cli
    save_data(conflicts, conflicts_file, force_overwrite=force_overwrite)
  File "./fas2ipa/utils.py", line 96, in save_data
    json.dump(data, fobj, indent=2)
  File "/usr/lib64/python3.6/json/__init__.py", line 179, in dump
    for chunk in iterable:
[...]
TypeError: Object of type 'set' is not JSON serializable

Conflicting users should be excluded from the sync

Currently, they are just reported. If a conflicting user is processed, group membership can be applied to the wrong user.

adding a possibility to have a prefix for groups to import

During meeting with @abompard this morning, I discussed one idea that we had discussed already in the past, but that doesn't seem to be implemented (yet).
As we'll have to merge groups from both Fedora and CentOS FAS instances, ideally when we'll migrate groups from these instances, we'll use a prefix (at least on on source) so that we don't have conflicts/overlaps.
Example : sig-cloud group on https://accounts.centos.org would be imported like centos-sig-cloud (assuming that we use the 'centos' prefix)

Use more speaking placeholders for unset first, last name fields

Right now, the placeholders for unset first (<fnu>) and last (<lnu) names aren't very speaking. If these values leak (e.g. some service accesses user information directly from FreeIPA), it'll confuse users. It'd be better to spell this out, e.g. use <first-name-unset> and <last-name-unset>, respectively.

The --check option should be default

Checking for conflicts should be on by default, especially if the conflicts file has been specified.

Allow to mark groups as "obsolete" or "expired"

FAS contains many many groups (well over 1000). The question is are all of these still in use? who do we contact to find out?

There are a whole bunch of git* cvs* and svn* groups which i think are leftover from the old fedora hosted days. are these worth importing in?