openlmi-devel January 2015

openlmi-devel@lists.stg.fedorahosted.org

4 participants
6 discussions

Add LANGUAGE property to LMI_Locale
by Alexander Lakhin 13 Jul '15

13 Jul '15

Hello, It seems that LMI_Locale misses one important property - LANGUAGE. The property can have value distinct from LC_* and LANG and it is supported by systemd-localed/localectl. Is it possible to add it to the LMI_Locale provider? I would like to propose the attached patch for it or should I file the bug? Best regards, Alexander

3 12

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 Weekly Public IRC Meeting
by Stephen Gallagher 23 Jan '15

23 Jan '15

The following meeting has been modified: Subject: OpenLMI Weekly Public IRC Meeting Organizer: "Stephen Gallagher" <sgallagh(a)redhat.com> Location: #openlmi on irc.freenode.net Time: 9:00:00 AM - 10:00:00 AM (GMT-0500) GMT-05.00/-04.00 [MODIFIED] Recurrence : Every Monday End by Jan 18, 2015 Effective Oct 21, 2013 Invitees: brennand(a)us.ibm.com; jsafrane(a)redhat.com; jsynacek(a)redhat.com; openlmi-devel(a)lists.fedorahosted.org; rdoty(a)redhat.com *~*~*~*~*~*~*~*~*~*

1 1

LMIWBEM Documentation online
by Peter Hatina 13 Jan '15

13 Jan '15

Hi all, documentation for LMIWBEM is now available at: http://phatina.github.io/lmiwbem/ Thanks and regards. -- Peter Hatina ENG Server Experience, System Management PGP: F32822A9 Red Hat, Inc. http://cz.redhat.com

1 0

ANNOUNCE: lmiwbem-0.6.0
by Peter Hatina 13 Jan '15

13 Jan '15

Hi all, there is a new version of lmiwbem available at [1]. What's new? - WBEMConnection can parse `username:password` from URL - added *compatibility parameters* in pull operations - added missing CIM error constants for pull operations - lmiwbem.config object - DEFAULT_NAMESPACE - DEFAULT_TRUST_STORE - SUPPORTS_PULL_OPERATIONS - fixed overflow error for large int on 64-bit - proper hostname is set for local connections - unified string for whole code base - source tree reorganization - various fixes and improvements [1] https://github.com/phatina/lmiwbem/releases/download/lmiwbem-0.6.0/lmiwbem-… -- Peter Hatina ENG Server Experience, System Management PGP: F32822A9 Red Hat, Inc. http://cz.redhat.com

1 0

Beware of the exceptions: LMIClassNotFound is never raised
by Tomáš Smetana 07 Jan '15

07 Jan '15

Hi. I have no idea how to properly report this... In several of the scripts (including "mine" realmd) we detect the missing provider by catching the LMIClassNotFound exception. This is not working for some time already: it needs to be changed to CIMError and checking the exact type of the error. It's not super-urgent (it only makes the providers to display little less pretty error) but keep it on mind when updating the scripts and check whether there is the correct exception being caught. I'll have to check how do the scripts behave with older LMI Shell... With several "stable" branches we need to be quite careful. Regards, -- Tomáš Smetana Platform Engineering, Red Hat

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

openlmi-devel January 2015