openlmi-devel July 2014

openlmi-devel@lists.fedorahosted.org

16 participants
37 discussions

Polkit-based authorization in OpenLMI providers
by Jan Safranek 16 Feb '15

16 Feb '15

Hello, I've been working on reusing polkit authorization for OpenLMI providers, which use a DBus service (e.g. NetworkManager, PackageKit, realmd, systemd, ...). I've documented the architecture on our wiki [1] and I submitted review in our review-board. I won't push the patches until we get to an agreement that it's the way to go and also the implementation is secure - please review carefully. There are *no* changes needed in our provider code and/or in the DBus services we work with. 1: https://fedorahosted.org/openlmi/wiki/PolkitAuthorization 2: https://reviewboard-openlmi.rhcloud.com/users/jsafrane/ In short, the concept is similar to Cockpit's reauthorization [3], we just don't play tricks with user passwords - we don't have one on CIM provider level. Instead, we register a polkit agent, which bluntly authenticates every request from polkit in its PAM session. 3: https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md [Kudos to Cockpit guys, I used their code to implement polkit agent and helper.] Just a side note: right now, users with remote CIM access must be members of 'pegasus' group, otherwise they cannot start a provider. Is it good or bad? Should _any_ user be able to use CIM by default and let polkit decide? It's trivial to fix, just set different file/directory permissions in tog-pegasus.rpm. And there is /etc/Pegasus/access.conf, which can control access properly if sysadmin wishes, so the question is just about the default setting. Jan

3 7

OpenLMI GUI
by Martin Hatina 23 Oct '14

23 Oct '14

Hello, I developed GUI for OpenLMI (+ account and service provider) as part of my bachelor thesis. Now as an intern I continue working on it. It is capable of generating scripts for LMIShell as well as execute these changes. It can also discover computers on network using SLP. For those of you, who might be interested, follow this link: https://github.com/mhatina/openlmi_gui Martin Hatina

1 3

FreeIPA&OpenLMI integration use cases
by Martin Kosek 18 Aug '14

18 Aug '14

Hello all, In the last month, FreeIPA [1] team was discussing options for remote management and deployment of FreeIPA servers, replicas and clients. We see the OpenLMI as the transport layer of choice for that task. We would like to share our use cases with this list and hopefully get advise and recommendations about the ways we should take (and avoid reinventing the wheel). In short, we have 2 main scenarios in mind: A) Extend FreeIPA Web UI&CLI and allow Administrators to easily enroll hosts in the network to FreeIPA install additional FreeIPA replica servers or control which services are supported by existing FreeIPA servers B) Allow deploying FreeIPA infrastructure from other tools, like Foreman Drop down of the particular use cases we identified for the 2 main scenarios: == FreeIPA management scenarios == A1) Retrieve status of a host User wants to detect what clients are available and enabled for OpenLMI and check whether they are already connected to FreeIPA. User interacts with FreeIPA Web UI/CLI that in turn invokes a remote OpenLMI call per system to check the state of the system. The system should be able to return at least following status: - I do not understand OpenLMI - I am not enrolled - I am enrolled with a particular domain of given type (FreeIPA, AD, LDAP, ...) - I am a FreeIPA server with following services configured (AD Trusts, Legacy clients, DNS, DNSSEC, PKI, Vault, ...), I am master server for following services (PKI/DNSSEC/...) - I am a FreeIPA server/client and I am in the middle of a particular deployment operation (see below) As Stephen Gallagher already suggested, this should be able to work with SLP discovery protocol and query systems individually to be just a fallback. I think some of the data could be already retrieved via existing realmd provider [2] that John Dennis wrote. A2) FreeIPA Client enrollment User wants to change a system into a FreeIPA client. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and checks the enrollment status. If the machine does not have FreeIPA client bits installed, command to enroll a client is issued. While this is happening status checks above should return status indicating that system is in process of becoming a client. This is already mostly possible, as per Stephen's blog [3]. A3) FreeIPA Replica deployment User wants to promote a FreeIPA Client to a Replica. User calls FreeIPA UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command for a client to become a replica. Client turns into a replica. While this is happening status checks above should return status indicating that system is in process of becoming replica. Stephen suggested this should be implemented via Server Roles. A4) FreeIPA Replica decommissioning User wants to remove a FreeIPA Replica. User calls FreeIPA UI/CLI, that in turn removes the replica from FreeIPA replication agreements, connects to a remote host over OpenLMI and issues a command for a replica to uninstall. Stephen suggested this should be implemented via Server Roles. A5) Configure FreeIPA service User wants to configure an optional service on FreeIPA server (DNS, AD Trusts, ...). User calls FreeIPA Web UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command to install the service. While this is happening status checks above should return status indicating that system is in a process of installing a service. Stephen suggested this may be implemented via Server Roles. A6) Configure FreeIPA master service Some FreeIPA services require a single FreeIPA node in the infrastructure to be the master for that service and e.g. generate CRL in case of PKI service or generate DNSSEC keys in case of DNS service. User wants to configure FreeIPA server as the new service master Server. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and issues a command to turn it in a master server for given service. This is tricky, as for some services, it may be also necessary to connect to previous master server and turn it into regular server and do additional migration steps. While this is happening status checks above should return status indicating that system is in a process of configuring a master server. A7) Log gathering User wants to send logs to e.g. Red Hat Access Portal using integration with FreeIPA Web UI. User selects a different server or client. FreeIPA server connects to a selected host over OpenLMI and inspects available logs. User then chooses logs to upload. Server then issues a command over OpenLMI to collect the chosen logs. As per Stephen's info, log collection is under investigation in OpenLMI, though without a given time frame yet. == Remote management systems scenarios == B1) Deploy cluster of FreeIPA servers User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy a cluster of several IPA servers. It is expected that it would connect to a chosen node, pass the required work plan that might include following information: list of nodes (by IP or names or MACs) with user names (if not Pegasus user) and passwords to use, admin and DM passwords, topology to use (full, ring, star, hub and spoke, etc). It is expected that the first node will process the work plan, install the first server, connect to other systems using use case A1, configures clients using A2 and promote them into replicas by using A3. Since this procedure takes time the provisioning system might fire the work plan and periodically check. In this case the head node should respond with the corresponding status: installing server, deploying clients, promoting clients to replicas, etc. B2) FreeIPA Replica deployment User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy another replica in the existing cluster. This case is a sub case of B1 when provisioning system has a work plan to extend an existing cluster. In this case, it provides a modification work plan and then IPA node processes it using capabilities covered in section A. B3) Create Trust relationship between FreeIPA and other domain (like Active Directory) User of a provisioning system invokes a UI/CLI that calls OpenLMI to get a status of the trust relations of a specific IPA domain. This is a slightly different type of status than covered in A1 as it needs to be exposed over OpenLMI only for external systems. B4) Change Trust relationship between FreeIPA and other domain User of a provisioning system invokes a UI/CLI that calls OpenLMI to change trust relationships between a selected IPA realm and other AD forests. Required information is provided and corresponding trusts are added or removed. ========================== This is the main set of use cases, we will be looking forward to your recommendation on how to address them with OpenLMI. We would be also interested whether you would recommend designing&implementing simply via our own CIM model, not integrated in DMTF ecosystem (i.e. mostly just implementing RPC interface) or rather going the hard way and follow the DMTF models and profiles? [1] http://www.freeipa.org [2] http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/0.4.… [3] http://sgallagh.wordpress.com/2014/06/13/using-openlmi-to-join-a-machine-to… Thank you. -- Martin Kosek <mkosek(a)redhat.com> Supervisor, Software Engineering - Identity Management Team Red Hat Inc.

4 9

Site maintenance on www.openlmi.org
by Stephen Gallagher 31 Jul '14

31 Jul '14

1 0

openlmi on RHEL64
by Noel McLoughlin 27 Jul '14

27 Jul '14

Hello, Is it possible to install OpenLMI/Pegasus on RHEL6.4 for evaluation purposes? http://www.openlmi.org/using_openlmi I would prefer not to use Fedora 20 or RHEL7 right now as I'm prototyping. So what LMI components are needed for RHEL6? thanks Noel

2 3

openlmi-reviews Digest, Vol 15, Issue 27
by openlmi-reviews-request＠lists.fedorahosted.org 27 Jul '14

27 Jul '14

Send openlmi-reviews mailing list submissions to openlmi-reviews(a)lists.fedorahosted.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.fedorahosted.org/mailman/listinfo/openlmi-reviews or, via email, send a message with subject or body 'help' to openlmi-reviews-request(a)lists.fedorahosted.org You can reach the person managing the list at openlmi-reviews-owner(a)lists.fedorahosted.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openlmi-reviews digest..." Today's Topics: 1. buildbot failure in OpenLMI on providers-rawhide (openlmiproject(a)gmail.com) 2. Review Request 1930: [1/1] Add thin provisioning admin documentation. (Jan Synacek) 3. Re: Review Request 1927: Add LMI_MediaPresent association. (Jan Synacek) 4. Re: Review Request 1925: Add LMI_StorageExtent.bus property. (Jan Synacek) 5. Re: Review Request 1925: Add LMI_StorageExtent.DeviceBusType property. (Jan Safranek) 6. buildbot failure in OpenLMI on providers-rhel7 (openlmiproject(a)gmail.com) 7. buildbot failure in OpenLMI on providers-rhel6 (openlmiproject(a)gmail.com) 8. buildbot failure in OpenLMI on networking-rhel6 (openlmiproject(a)gmail.com) 9. buildbot failure in OpenLMI on storage-rhel6 (openlmiproject(a)gmail.com) 10. buildbot failure in OpenLMI on networking-rhel7 (openlmiproject(a)gmail.com) 11. buildbot failure in OpenLMI on providers-rhel7stable (openlmiproject(a)gmail.com) 12. buildbot failure in OpenLMI on storage-rhel7 (openlmiproject(a)gmail.com) 13. buildbot failure in OpenLMI on storage-rhel7stable (openlmiproject(a)gmail.com) 14. Re: Review Request 1925: Add LMI_StorageExtent.DeviceBusType property. (Jan Synacek) 15. Re: Review Request 1930: [1/1] Add thin provisioning admin documentation. (Jan Synacek) 16. buildbot failure in OpenLMI on networking-rawhide (openlmiproject(a)gmail.com) 17. buildbot failure in OpenLMI on storage-rawhide (openlmiproject(a)gmail.com) 18. Review Request 1931: openlmi-providers: Use polkit for the providers, which can use it. (Jan Safranek) 19. Re: Review Request 1931: openlmi-providers: Use polkit for the providers, which can use it. (Jan Synacek) 20. Re: Review Request 1930: [1/1] Add thin provisioning admin documentation. (Jan Safranek) 21. buildbot failure in OpenLMI on storage-rhel6 (openlmiproject(a)gmail.com) 22. Re: Review Request 1930: [1/1] Add thin provisioning admin documentation. (Jan Synacek) 23. Re: Review Request 1925: Add LMI_StorageExtent.DeviceBusType property. (Jan Safranek) 24. Re: Review Request 1927: Add LMI_MediaPresent association. (Jan Safranek) 25. Re: Review Request 1928: Remove workaround for bug #1062223. (Jan Safranek) 26. buildbot failure in OpenLMI on storage-rhel6 (openlmiproject(a)gmail.com) 27. buildbot failure in OpenLMI on storage-rhel7 (openlmiproject(a)gmail.com) 28. buildbot failure in OpenLMI on storage-rawhide (openlmiproject(a)gmail.com) 29. buildbot failure in OpenLMI on storage-rhel7 (openlmiproject(a)gmail.com) 30. buildbot failure in OpenLMI on storage-rawhide (openlmiproject(a)gmail.com) 31. Review Request 1932: jobmgr: don't truncate GType's value (Michal Minar) 32. Re: Review Request 1932: jobmgr: don't truncate GType's value (scanbot) 33. Re: Review Request 1932: jobmgr: don't truncate GType's value (scanbot) 34. Review Request 1933: software-dbus [1/3] software-dbus: rename cleanup function of SwPackage (Michal Minar) 35. Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (Michal Minar) 36. Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (Michal Minar) 37. Re: Review Request 1933: software-dbus [1/3] software-dbus: rename cleanup function of SwPackage (Peter Schiffer) 38. Re: Review Request 1933: software-dbus [1/3] software-dbus: rename cleanup function of SwPackage (scanbot) 39. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (scanbot) 40. Re: Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (scanbot) 41. Review Request 1936: lmishell, rewrite synchro methods listener startup (Peter Hatina) 42. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (Peter Schiffer) 43. Re: Review Request 1933: software-dbus [1/3] software-dbus: rename cleanup function of SwPackage (scanbot) 44. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (scanbot) 45. Re: Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (scanbot) 46. Re: Review Request 1936: lmishell, rewrite synchro methods listener startup (Michal Minar) 47. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (Michal Minar) 48. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (Michal Minar) 49. Re: Review Request 1933: software-dbus [1/3] software-dbus: rename cleanup function of SwPackage (scanbot) 50. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (scanbot) 51. Re: Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (scanbot) 52. Re: Review Request 1933: software-dbus [1/3] software-dbus: rename cleanup function of SwPackage (scanbot) 53. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (scanbot) 54. Re: Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (scanbot) 55. Re: Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (Peter Schiffer) 56. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (Peter Schiffer) 57. buildbot failure in OpenLMI on providers-rhel7 (openlmiproject(a)gmail.com) 58. buildbot failure in OpenLMI on providers-rhel6 (openlmiproject(a)gmail.com) 59. buildbot failure in OpenLMI on networking-rhel6 (openlmiproject(a)gmail.com) 60. buildbot failure in OpenLMI on storage-rhel6 (openlmiproject(a)gmail.com) 61. buildbot failure in OpenLMI on providers-rhel7stable (openlmiproject(a)gmail.com) 62. buildbot failure in OpenLMI on storage-rhel7stable (openlmiproject(a)gmail.com) 63. buildbot failure in OpenLMI on storage-rhel7 (openlmiproject(a)gmail.com) 64. buildbot failure in OpenLMI on providers-rawhide (openlmiproject(a)gmail.com) 65. buildbot failure in OpenLMI on networking-rawhide (openlmiproject(a)gmail.com) 66. buildbot failure in OpenLMI on storage-rawhide (openlmiproject(a)gmail.com) 67. buildbot failure in OpenLMI on storage-rhel6 (openlmiproject(a)gmail.com) 68. buildbot failure in OpenLMI on providers-rhel6 (openlmiproject(a)gmail.com) 69. buildbot failure in OpenLMI on networking-rhel6 (openlmiproject(a)gmail.com) 70. buildbot failure in OpenLMI on storage-rawhide (openlmiproject(a)gmail.com) 71. buildbot failure in OpenLMI on storage-rhel7stable (openlmiproject(a)gmail.com) 72. buildbot failure in OpenLMI on storage-rhel7 (openlmiproject(a)gmail.com) 73. buildbot failure in OpenLMI on providers-rhel7 (openlmiproject(a)gmail.com) 74. buildbot success in OpenLMI on networking-rhel7 (openlmiproject(a)gmail.com) 75. buildbot failure in OpenLMI on providers-rawhide (openlmiproject(a)gmail.com) 76. buildbot failure in OpenLMI on networking-rawhide (openlmiproject(a)gmail.com) 77. Re: Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (Michal Minar) 78. Re: Review Request 1935: software-dbus [3/3] software-dbus: optimalized FindIdentity() function (Michal Minar) 79. Re: Review Request 1933: software-dbus [1/3] software-dbus: rename cleanup function of SwPackage (scanbot) 80. Re: Review Request 1934: software-dbus [2/3] software-dbus: enhanced repository listing functions (scanbot) _______________________________________________ openlmi-reviews mailing list openlmi-reviews(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-reviews

1 0

openlmi-reviews Digest, Vol 15, Issue 26
by openlmi-reviews-request＠lists.fedorahosted.org 24 Jul '14

24 Jul '14

1 0

openlmi-reviews Digest, Vol 15, Issue 25
by openlmi-reviews-request＠lists.fedorahosted.org 23 Jul '14

23 Jul '14

1 0

Docstrings: readability vs. ":param:..." et al
by Alois Mahdal 23 Jul '14

23 Jul '14

Hi, I've been playing with and trying to understand OpenLMI API for a while now, and there is one thing that keeps getting back to me as a minor annoyance: the use of the verbose notation in Python docstrings. ~ Let's play a game: *within 5 seconds*, try to guess where this is from and how to use it: :param string uri: URI of the CIMOM :param string username: account, under which, the CIM calls will be performed :param string password: user's password :param bool interactive: flag indicating, if the LMIShell client is running in the interactive mode; default value is False. :param bool use_cache: flag indicating, if the LMIShell client should use cache for CIMClass objects. This saves lot's of communication, if there are :func:`EnumerateInstances` and :func:`EnumerateClasses` intrinsic methods often issued. Default value is True. :param string key_file: path to x509 key file; default value is None :param string cert_file: path to x509 cert file; default value is None :param bool verify_server_cert: flag indicating, whether a server side certificate needs to be verified, if SSL used; default value is True Was it easy? Did the strings like `:param string key_file:` help you? ~ From another POV: I consider myself a Pythonist. I've been playing and working with Python for well over a year now, and I am pretty familiar with ways how to obtain documentation of various libraries. One thing that is cool about it is that it has few built-in facilities for this. And above these, there are even fancy tools like ipython: * $ pydoc something * $ python # lmishell being basically the same here >>> help(something) * $ ipython In [1]: something? # 1q = view basic info + docstring In [2]: something?? # 2q = view above + source * $ vim /path/to/something.py # or your favorite editor Note that these ways are all awesome in that they can all be done * within terminal, i.e. over ssh * "on-premise", I mean from the machine itself, which removes any doubts like "am I looking at correct doc version?" * without active Internet connection * without need to use browser (i.e. possible sluggish behavior or risk of distraction by other tabs). But look[1] how the LMI documentation looks like when viewed using these tools: [1]: http://azzgoat.zxcvb.cz/tmp/lmi_ds/ * pydoc - lmi-ds-in-pydoc.png * lmishell - lmi-ds-in-lmishell.png * ipython - lmi-ds-in-ipython1.png, lmi-ds-in-ipython2.png * vim - lmi-ds-in-vim.png and compare to some of standard Python libraries: * ftplib.FTP.ntransfercmd - std-ds-in-pydoc.png * socket.create_connection - std-ds-in-ipython1.png * re.sub - std-ds-in-ipython2.png * abc.ABCMeta - std-ds-in-vim.png to understand how average Pythonista would feel ;) ~ Now I understand that this metadata can help create cross-links in hypertext documentation, or can help display nice icons in some IDEs, but other than that, I can't see any advantage. I know that conventions like this may make sense with strictly typed languages like Java or PHP or C*, in that it can support some static checkers, but considering dynamics and duck-typing philosophy of Python, I doubt it can be any of real use. And compared to how most of standard Python library is written, the readability (= accessibility) of the documentation is in regression. ~ So is it really necessary to stick with this convention? Or: If I decide to submit patch in order to simplify and increase readability of docstrings, can I drop most of the "meta-data" and make the docs look more like standard docs? Thanks, aL. P.S.: Oh, and the game! In case you did not make it under 5s: * *First*, thanks for proving my point, and * *second*, it's `lmi.shell.connect` and is as easy to use as connect("https://some.example.com/", "pegasus", "aaa") (pretty much what everyone would expect) -- Alois Mahdal <amahdal(a)redhat.com> Platform QE Engineer at Red Hat, Inc. #brno, #daemons, #openlmi

2 2

openlmi-reviews Digest, Vol 15, Issue 24
by openlmi-reviews-request＠lists.fedorahosted.org 22 Jul '14

22 Jul '14

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

openlmi-devel July 2014