On 11/06/2015 11:06 AM, Petr Vobornik wrote:
On 11/06/2015 10:15 AM, Petr Spacek wrote:
On 6.11.2015 09:25, Martin Kosek wrote:
On 11/05/2015 07:02 PM, Petr Vobornik wrote:
On 11/02/2015 12:37 PM, Martin Kosek wrote:
On 11/02/2015 06:10 AM, Jan Cholasta wrote:
Hi,

On 22.10.2015 10:44, Martin Babinsky wrote:
https://fedorahosted.org/freeipa/ticket/5181

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"
or
$ 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
I am thinking "Roles" could be printed out even in default listing.
It looks as
an important piece of information you want to know about your master.
I also
originally used that with servercomponent, you moved it to server
itself. It
makes also sense.

We will need a design for this servercomponent/roles anyway, to agree
on the
API with all stakeholders.

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

Just keep in mind that 'role' design requires yet another layer of
indirection
because there is no 1:1 mapping between services and roles. E.g.
'DNSSEC key
master' role consists of several services, as 'DNS server' role etc.

Also, we can get into trouble because role 'DNS server' in IPA 4.2 can
contain
different set of services than 'DNS server' in IPA 5.0 etc.

For these reasons I question necessity of 'role' abstraction. Is it
worth?


IMO yes. Current patch is better than nothing but roles are more
friendly, components are implementation detail.

Showing only CNs on components doesn't show all info. E.g.

ipa server-show `hostname`
   Server name: ipa.example.com
   Managed suffix: dc=example,dc=com, o=ipaca
   Min domain level: 0
   Max domain level: 1
   Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA

This doesn't show that the server is actually also a ca-renewal-master.
  What is the command I can use to solve: "show me what server is the
ca-renewal-master"?

In that case we would IMHO need to redesign the whole service to LDAP mapping to incorporate server roles in some sane and scalable way. I'm not sure if that fits in the 4.3 timeframe. If yes, the we should first start with first putting the plumbing in and then adding API calls on top.

It doesn't make much sense to push this patch first and then rework the whole thing.

Then what's the difference between ADTRUST and EXTID? One is smb, second
winbind but from user perspective it is the same thing - AD Trusts
controller.

Could there be DNS without DNSKeySync?


--
Martin^3 Babinsky

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

Reply via email to