Add script to setup krb5 NFS exports

[alice-mitchell]

python script to setup secure NFS exports with kerberos that relies heavily on FreeIPA, and is in many ways the compliment to ipa-client-automount that sets up the NFS server side. It attempts to automatically discover the existing ipa/kerneros setup and falls back to asking simple questions, in much the same way as ipa-server-install does.

Difficult to figure out exactly what it should be called, have taken a guess and gone for: ipa-client-exportnfs

[MartinBasti]

Hello,

can you please provide user cases for this, or some kind of top level design what problem are you solving, why and how do you plan resolve it?

We may help you then to create optimal solution.

Current code is hard to read and I think you copy&pasted a lot of code from other IPA parts, also IPA code should not install any other packages.

For me it looks more like work for some provisioning system like ansible than IPA script, so I would like to see design/user cases first.

Thanks

[rcritten]

Quite a lot of this code can be eliminated if you use ipalib instead of manually reading configuration files, forking out to ipa, doing a kinit, etc or do you expect/anticipate that this can be executed on non-IPA-enrolled clients?

[alice-mitchell]

The idea was to produce a script to simplify the setup of kerberos encrypted NFS exports, to make something that was as simple to use as ipa-*-install is, including the configuration of the automount parameters that would be needed to utilise ipa-client-automount.

The script calls the IPA external programs instead of using the library functions to make it easier to substitute AD versions if required.

[alice-mitchell]

@mbasti-rh This is my first python script so apologies for it being a bit rough around the edges, i tried to emulate the stylings of the other ipa-scripts,i recall that the user_input method is very similar, and there is some boilerplate top level exception handling, but no direct cut and paste afair. It does not attempt to install any packages, it just suggests which ones you might need if it finds commands it relies upon are missing.

The brief was to make an easy to use script in the style of ipa-client-install that sets up kerberos encrypted NFS exports on a host, it calls out to the cli commands where possible so that it could potentially be reused with AD in the future.

It tries to retrieve as much information from an already configured system as possible, and if IPA is already setup, configured, and a session in progress it will ask very little. When the setup is not there it gracefully falls back, asking more and more questions as required, attempting to initiate authentications where needed, until a final level where if critical components are missing it will suggest which packages may be missing before giving up.

I have made changes to pass all the pylint tests cleanly, as i hfailed to notice them originally, is there any further modifications i should be making ?

[pspacek]

It sounds to me that it could be an useful plugin for ipa-advise tool. This is the tool which is supposed to given advies like 'install this and that' and so on.

[pvoborni]

Justin, pasting here re-phrased mail I wrote you on Dec 5.

This is a tool which integrates external host with FreeIPA. It is written in a way that it can exist completely outside of FreeIPA git repository. Thinking more about it. It might be actually better to write an Ansible module which would configure server as a NFS server and join it to FreeIPA realm. We will be working on better Ansible integration in very close future.

Technical/maintenance side of the patch: tools merged in FreeIPA repository are then maintained by FreeIPA core team. Problem is that the tool is written in a way that it doesn't use any internal FreeIPA calls and thus reimplements IPA logic, it makes it hard to maintain. To make it easier to maintain it would be better to reuse IPA internal calls. But it doesn't make sense for you to spend time on rewriting it according to upstream rules nor it doesn't make sense for upstream developer to modify your code according to it (this would be faster for both sides then former review ping-pong). So it would be preferred to maintain it elsewhere.

The proposal/general agreement on FreeIPA triage was:

• move this script into separate git repo, e.g. on Git Hub. That way fixing the script doesn't have to rely on FreeIPA schedule. It might be your repo or maybe under FreeIPA org if you prefer it.
• FreeIPA upstream will create wiki page where we will list similar contribution (like https://github.com/peterpakos/ipa_check_consistency/ ) and add it there so it would be discoverable
• FreeIPA upstream will also make it discoverable from installed rpms - https://fedorahosted.org/freeipa/ticket/6536
• if the project receives high enough popularity - will be widely use it may be considered for rewrite and including it into IPA core

What was not discuss but may be a good thing is to create integration travis tests in the separate repo which would test the script so it can be tested automatically.