On 11/02/2015 12:37 PM, Martin Kosek wrote:
On 11/02/2015 06:10 AM, Jan Cholasta wrote:

On 22.10.2015 10:44, Martin Babinsky wrote:

This should be handled by a separate object plugin:

$ ipa servercomponent-find master.ipa.test
6 server components matched
   Component name: CA
   Enabled: TRUE
   Start order: 50

   Component name: KDC
   Enabled: TRUE
   Start order: 10

   Component name: KPASSWD
   Enabled: TRUE
   Start order: 20

   Component name: MEMCACHE
   Enabled: TRUE
   Start order: 39

   Component name: OTPD
   Enabled: TRUE
   Start order: 80

   Component name: HTTP
   Enabled: TRUE
   Start order: 40
Number of entries returned 6

This will allow us to consolidate all the ad-hoc component-related code
scattered throughout IPA (search for enable component, enable/disable
component, ...) into IPA command calls.

I'm not opposed to showing a summary in server-show (although we don't do
anything like this for any other hierarchical objects), but it should be done
just for the users' sake, not for internal use (the ticket suggests to use this
for topology visualisation).

BTW as far as the scalability of the current solution goes, you should have a
list of all the *non*-optional components and display everything else.

The API proposal should be in line with our future extensions of the API. We
for example want to move "ipa-csreplica-manage" set-renewal-master command to
API call. Or DNSSEC generation master. Or we may want to change some other
flag/role of a master via this interface.

So we will need something like
$ ipa server-add-role ipa.example.com --role "ca-renewal-master"
$ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master

Depends on usage. If we want to internally unify manipulation with configs for component we can create low-level commands which won't be exposed to CLI.

E.g. ipa servercomponent-find ipa.example.com
Component name: ADTRUST
Config: enabledService, startOrder 60

<other services>

This is all what Web UI needs.

From user perspective, for CLI, something different is better. Martin used term 'role', lets go with that.

Idea 1:
$ ipa server-show ipa.example.com --roles
Server name: vm-073.idm.lab.eng.brq.redhat.com
  Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca
  Min domain level: 0
  Max domain level: 1
  Role: dns-server, cs-server, ca-renewal-master, trust-controller

--all would imply --roles

$ ipa server-add-role ipa.example.com --roles=ca-renewal-master

This is not good because this add operation will also remove a role from different master which could be unexpected. I.e. set-renewal-master might be a separate command. Same would apply to DNSSec generation masters.

Idea 2:
$ ipa serverrole-add ipa.example.com ca-renewal-master
$ ipa serverrole-find ipa.example.com
Role: dns-server
Role: cs-server
Role: ca-renewal-master
Role: trust-controller

All variants alone are fine for Web UI.
Petr Vobornik

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to