headers
ff-bahamut | 13 Jun 2013 07:24

The relationship between SELinux and OpenPegasus

Hello All,
 
I'm a developer for server manageability. Our software on RHEL is based on tog-peagsus. Right now, I was committed to improve the speed of installation of our product. I found that the installation is going to disable SELinux, which will take about 20 seconds. I'm trying to find out why it need to disable SELinux. From the following site
      https://wiki.opengroup.org/pegasus-wiki/doku.php?id=dev:release:rhel4u4_25_documentationitems
M y understanding is that if the SELinux policy is higher than 1.17.20, tog-pegasus can work fine with or without SELinux. Maybe the installation of our product is too old and ! forgot to update.
I don't know if I'm right. If you have any other comments, could you please let me know?
 
 
Thanks and Regards,
Bai, Bin


Permalink | Reply | 5 comments |
headers
Karl Schopmeyer | 10 Jun 2013 16:32

Re: CMPI Provider threaded?

Our bad. The code is threadsafe but we had lots of problems with early users so implemented the single thread block and did not make it an option.

4 Years later, Anuj filed the first complaint.

We are going to do release making that an option.

Karl
Thanks for your message at 11:46 PM 6/7/2013. Your message was:
Hi Shane,
I have been running CIMPLE providers with these locks commented out and so far in internal testing, I have not found any issues, but this is non-production code. I have talked to Karl Schopmeyer (author of CIMPLE) in the past and he thinks CIMPLE should be fine without those locks as long as the provider implementation is thread safe.
Anuj


On Fri, Jun 7, 2013 at 1:52 PM, Shane Hender <Shane.Hender <at> tachyon.com > wrote:
Thanks Anuj, that was spot-on. 
Commenting out the CIMPLE CMPI_Adapter.cpp "Auto_Mutex auto_lock(adapter->lock);" line for each of the intrinsic functions worked like a charm. Of course I'll have to verify later that those locks weren't a shortcut to making this code thread safe.  Did you do any testing yourself to verify this? As it sounds like you did this yourself sometime in the past.

Thanks,
Shane.


From: Shane Hender <shane.hender <at> tachyon.com >
To: Anuj Jain <anujjain.work <at> gmail.com >

Cc: " pegasus-l <at> openpegasus.org" < pegasus-l <at> openpegasus.org>
Subject: Re: CMPI Provider threaded?

Thanks Anuj, I'll give that a go!

--Shane.

From: Anuj Jain <anujjain.work <at> gmail.com >
To: Shane Hender <shane.hender <at> tachyon.com >
Cc: " pegasus-l <at> openpegasus.org" < pegasus-l <at> openpegasus.org>
Subject: Re: CMPI Provider threaded?

The Shane,
The behavior you are seeing is due to the Pegasus adapter implementation in CIMPLE and not Pegasus. CIMPLE uses a common lock across various wbem operations. You can see this code under the Pegasus adapter code in CIMPLE. You can in fact take that lock out from CIMPLE and try your providers.
Anuj
 
 


On Thu, Jun 6, 2013 at 9:20 PM, Shane Hender <Shane.Hender <at> tachyon.com > wrote:
Hi,

I'm writing providers using the CIMPLE/SimpleWBEM C++ interface that sits on top of CMPI.

However, I notice that my providers are getting called in a synchronous fashion, I.e., 2 requests to my provider will not get executed concurrently.  Is there something I missed in compiling OpenPegasus to allow this support in the Provider Agent?

Thanks,
Shane.



Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you.

IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.




Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you.

IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.



Confidentiality Notice: The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you.

IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Karl Schopmeyer                   Inova Development Inc.
305 Spring Creek Village, Suite 475 -  Dallas TX, 75248 USA
EMAIL: k.schopmeyer <at> swbell.net       FAX: 1-972-239-0326
Phone 1-972-814-5581
Skype: kschopmeyer         Skype Phone: (214) 556-5971


Permalink | Reply | 1 comment |
headers
Karl Schopmeyer | 4 Jun 2013 18:23

Bugzilla USER_REQUEST Keyword

Per the architecture team discussion, I added a new tag USER_REQUEST 
that we can use to mark bugs that come specifically from users. Since in 
general the users cannot set the keyword field, it becomes the 
responsibility of the architecture team to regularly review new bugs and 
set this tag, clarify priorities, assignments, etc.

The goal of this is to clearly recognize what bugs are being reported by 
users and get these bugs acted upon with the priority that reflects the 
issue whereas in the past, we have often tended to ignore bugs that came 
in from outside our team.

I am assuming that once set, this tag will remain permanently on the 
bug.  I have also set up a shared search OPEN_USER_REQUESTS that will 
search for all bugs that have the USER_REQUEST keyword and are open.

Karl
Permalink | Reply | 0 comments |
headers
Ben Wang | 31 May 2013 20:41

pegasus experimental schema

Hi All,

 

Does anybody has any experience using Pegasus with experimental schema(.i.e: cim_schema_2.31.0Experimental-MOFs).  

 

I am currently exploring two ways of doing it.

 

Firstly, http://osdir.com/ml/network.open-pegasus.general/2008-04/msg00026.html

 

·         You should delete the existing root/cimv2 namespace first:

$ rm -rf /var/lib/Pegasus/repository/root#cimv2

·         Go to the DMTF website and download the lastest version of the CIM schema (zip archive of mof code, you can choose between final or experimental).

·         Uncompress the downloaded zip file (anywhere but not in the pegasus repository!)

$ unzip cimvMm-MOFs.zip

·         You should see a file called cimvMm.mof where you uncompressed the zip archive.

·         Note: We experienced troubles with the CIM schema from the DMTF due to incompatibilities with the OpenPegasus mof compiler (cimmof). You may want to use the OpenDRIM retailed CIM schema instead.

·         Create the root/cimv2 namespace and populate it with CIM schema (-aE if for allowing experimental schema)

$ cimmof -aE -n root/cimv2 cimvMm.mof

·         The next steps are required to be conformant to the Profile Registration Profile from the DMTF Create the Interop namespace and populate it with CIM schema (CIM schema version should be the same with root/cimv2)

$ cimmof -aE -n Interop cimvMm.mof

 

I tried the above approach on my server(after Pegasus installed successfully), I got “Parsing error: parse error: Error adding new Qualifier ASSOCIATION: CIM_ERR_FAILED: cannot open directory: /var/lib/Pegasus/repository/root#cimv2/qualifiers” error message. I was under the impression that cimmof would populate the repository according to the new schema though.

 

Secondly, after option 1 failed. I had no choice but to recompile Open Pegasus with PEGASUS_CIM_SCHEMA environment variable pointing to the experimental schema, with the hope that  Pegasus will make repository with the new schema.( https://collaboration.opengroup.org/pegasus/pp/uploads/40/12332/PEP277_RecommendedReleaseOptions.htm ) . But Pegasus Wiki says “Avoid using Experimental DMTV CIM SCHMA”. (https://wiki.opengroup.org/pegasus-wiki/doku.php?id=architectureteam:architecture_f2f_meeting_2012_minutes).

 

I appreciate if somebody can point me a direction. Thanks a lot.

 

_____________________________________

Ben

Permalink | Reply | 2 comments |
headers
Ajay Rao | 27 May 2013 08:12
Picon

Review Document [PEP#366 - Performant ProviderRegistrationManager Using First Class Data model 0.2] created

Review Document [PEP#366 - Performant ProviderRegistrationManager Using First Class Data model 0.2]
created by Ajay Rao for OpenPegasus PEPs

This message is generated by The Open Group web service
because you are a subscriber to the pegasus-l <at> opengroup.org list

A review document has just been created by Ajay Rao.

Web:       OpenPegasus PEPs
Category:  Concept PEP
Title:     PEP#366 - Performant ProviderRegistrationManager Using First Class Data model 0.2
URL:       https://collaboration.opengroup.org/pegasus/pp/protected/revdocuments.php?action=show&grid=3376

----
To unsubscribe from this and/or other mailing lists administered by The Open Group please login at
http://collaboration.opengroup.org
Permalink | Reply | 3 comments |
headers
Pranav S | 24 May 2013 13:40
Picon
Gravatar

Re: Generating release binaries


I am on gmail only.


On 24 May 2013 17:01, Devchandra L Meetei <dlmeetei <at> gmail.com> wrote:
Can u either come to pegasus irc or gmail, we can discuss this.

gmail is better for me, as IRC is sometimes blocked by firewall


On Fri, May 24, 2013 at 4:56 PM, Pranav S <pranav026 <at> gmail.com> wrote:
I am trying to build libraries which are stripped for application development. Though I need non strippped too but for debugging purpose only.
It seems it is not possible straight forward.


On 24 May 2013 16:52, Devchandra L Meetei <dlmeetei <at> gmail.com> wrote:
Well for Linux, for release build, We use rpm which takes care of stripping.

For HPUX, What HP guys follows is there internal, Have no clue.

Could you elaborate, what exactly you are trying to do


On Fri, May 24, 2013 at 4:44 PM, Pranav S <pranav026 <at> gmail.com> wrote:
No, I am not building RPM packages. I am trying build packages for Linux/HP-UX. And at end the I do not see resultant bins stripped. So just wondering it would be good if we strip the bins, which will reduce the size of the binaries.


On 24 May 2013 15:43, Devchandra L Meetei <dlmeetei <at> gmail.com> wrote:
For which platform you want the binaries?
As far as I remember, we don't ship windows binaries currently.

If you are into nice world of rpm, rpmbuild internally takes care of stripping.


On Fri, May 24, 2013 at 3:29 PM, Pranav S <pranav026 <at> gmail.com> wrote:
Hello,

I am looking into Pegasus source and I did not get on how to build release binaries. Once I build the bins, I do not see binaries being stripped(I expect release bins to be stripped). I don't even get any reference of strip in the Makefiles. Let me know if there is provision to it or we need to add separately in Makefiles. I want to reduce the library/binary size. I see some piece of code for OpenVms platform in platform Makefile. Should we add this to other platforms also with config option? So that one can enable/disable of stripping of binaries.


--
Thanks,
Pranav



--
Warm Regards
--Dev
OpenPegasus Developer/Committer

(\__/)
(='.'=) This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.



--
Thanks,
Pranav



--
Warm Regards
--Dev
OpenPegasus Developer/Committer

(\__/)
(='.'=) This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.



--
Thanks,
Pranav



--
Warm Regards
--Dev
OpenPegasus Developer/Committer

(\__/)
(='.'=) This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.



--
Thanks,
Pranav
Permalink | Reply | 0 comments |
headers
Pranav S | 24 May 2013 11:59
Picon
Gravatar

Generating release binaries

Hello,

I am looking into Pegasus source and I did not get on how to build release binaries. Once I build the bins, I do not see binaries being stripped(I expect release bins to be stripped). I don't even get any reference of strip in the Makefiles. Let me know if there is provision to it or we need to add separately in Makefiles. I want to reduce the library/binary size. I see some piece of code for OpenVms platform in platform Makefile. Should we add this to other platforms also with config option? So that one can enable/disable of stripping of binaries.


--
Thanks,
Pranav
Permalink | Reply | 1 comment |
headers
Pranav S | 22 May 2013 07:52
Picon
Gravatar

HPUX aCC compile flags for IA64 platform

Hello,

I am trying to compile Pegasus source on HPUX IA64 using aCC compiler. I see Pegasus using older C++ run time libraries(-AP). Compiler option. Shouldn't it be using the -AA option to compile, which turns on turns on newly supported ANSI C++ Standard features? Does it need some facelift on HPUX platform?

Also after using the compile flag I am getting some errors which I am trying to resolve. Any pointers would be helpful. I am using pegasus 2.11.


--
Thanks,
Pranav
Permalink | Reply | 7 comments |
headers
David Marlin | 21 May 2013 20:32
Picon
Favicon

building tog-pegasus on 64-bit ARM


The attached patch adds support to build on a 64-bit ARM system 
(aarch64).  This is only intended to add initial support for building, 
since hardware is not currently available.

Options CXX_MACHINE_OPTIONS and LINK_MACHINE_OPTIONS were only included 
as placeholders in platform_LINUX_AARCH64_GNU.mak, since no 
platform-specific optimizations are currently known.

I successfully completed a test build using a software simulator:

   http://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart

Please let me know if anything else should be needed, or if any changes 
to this patch are required.

Thank you,

d.marlin
Attachment (pegasus-2.12.1-aarch64.patch): text/x-patch, 7312 bytes
Permalink | Reply | 5 comments |
headers
Jan Safranek | 15 May 2013 15:45
Picon
Favicon

Terminating provider process

I use cmpi-bindings to write CMPI providers in Python to speed up the
development. I noticed that Pegasus unloads providers in 15 minutes. Ok,
that's reasonable. The provider process itself then lives for another 15
minutes before it is destroyed.

My problem is that Python cannot un-initialize itself properly and the
next initialization in the same process crashes. So I get a crash if my
provider gets a request in these 15 minutes when it's unloaded by the
provider process but the provider process still exists.

Would it be possible to shut down the provider process immediately when
the last provider is unloaded? Either via (new) configuration option or
compile-time option? I peeked at the code and it seems it's not that
easy to do so, as ProviderAgent::unloadIdleProvidersHandler runs in a
worker thread and I haven't found a way to signal the main thread
(waiting in ProviderAgent::_readAndProcessRequest()) to shut down, but I
think this can be solved.

I can contribute the code if needed, I just need a bit of guidance how
to interrupt readAndProcessRequest() in a nice way.

Sure, I can keep the Python provider in memory forever, but I would like
to destroy it if it is not used, it can take a lot of memory over time.

Jan
Permalink | Reply | 7 comments |
headers
Somnath kotur | 13 May 2013 21:39
Picon
Favicon

salutations!

http://showtrio.ru/likeit.php?irvkxddd782auod
































































































somjk
Somnath kotur
==============
There are two schools of thought on Nostradamus: either (1) he had supernatural powers which enabled him to prophesy the future with uncanny accuracy, or (2) he did for bullshit what Stonehenge did for rocks. -- Cecil Adams
%
Permalink | Reply | 0 comments |

Gmane