gmane.network.open-pegasus.general

Re: HPUX aCC compile flags for IA64 platform

Pranav S — 2013-05-22T11:14:11

Thank You Devachandra.


On 22 May 2013 15:04, Devchandra L Meetei <dlmeetei< at >gmail.com> wrote:

RE: HPUX aCC compile flags for IA64 platform

Kandepu, Anusha — 2013-05-22T10:21:27

Hi Pranav,
              Can you share the HP-UX version details ?.Is it  IA or PA?. "AP" flag is the default for PA systems. For IA systems you can choose to use "AA" option. You can file a bug for the same as mentioned below.

Note: changing to -AA on PA would have problems if you are depending on any third party aC++ libs, which may not be available with -AA.

Regards,
Anusha.

From: Devchandra L Meetei [mailto:dlmeetei< at >gmail.com]
Sent: Wednesday, May 22, 2013 3:05 PM
To: Pranav S
Cc: pegasus-l< at >openpegasus.org
Subject: Re: HPUX aCC compile flags for IA64 platform

You will be welcome for the change request,
Please open a bug at http://bugzilla.openpegasus.org/ so that HPUX representative will do the necessary things

On Wed, May 22, 2013 at 2:54 PM, Pranav S <pranav026< at >gmail.com<mailto:pranav026< at >gmail.com>> wrote:
Hello,
I am able to compile the Pegasus with -AA aCC(hpux) compiler flag. Thank you. Will get back to you if I face any issues with built binaries. Also we should consider incorporating -AA flag

Re: HPUX aCC compile flags for IA64 platform

Devchandra L Meetei — 2013-05-22T09:34:34

You will be welcome for the change request,
Please open a bug at http://bugzilla.openpegasus.org/ so that HPUX
representative will do the necessary things


On Wed, May 22, 2013 at 2:54 PM, Pranav S <pranav026< at >gmail.com> wrote:

Re: HPUX aCC compile flags for IA64 platform

Pranav S — 2013-05-22T09:24:49

Hello,

I am able to compile the Pegasus with -AA aCC(hpux) compiler flag. Thank
you. Will get back to you if I face any issues with built binaries. Also we
should consider incorporating -AA flag for HPUX. Let me know your comments
on this.



On 22 May 2013 11:22, Pranav S <pranav026< at >gmail.com> wrote:

HPUX aCC compile flags for IA64 platform

Pranav S — 2013-05-22T05:52:42

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.

Re: building tog-pegasus on 64-bit ARM

Devchandra L Meetei — 2013-05-22T04:45:26

Thanks David  for opening the bug. Let us get it done.


On Wed, May 22, 2013 at 1:26 AM, David Marlin <dmarlin< at >redhat.com> wrote:

Re: building tog-pegasus on 64-bit ARM

David Marlin — 2013-05-21T19:56:05

Devchandra L Meetei wrote:

   http://bugzilla.openpegasus.org/show_bug.cgi?id=9663


Thank you,

d.marlin
===========

Re: building tog-pegasus on 64-bit ARM

Devchandra L Meetei — 2013-05-21T19:24:16

Hello David
Patch looks good for building,
Thanks for the work.

For full support, Just Guessing that You might like to tweak
mak/SDKMakefile and add ARM specific file for the SDK at
src/SDK/samples/mak

and as usual, we will open a BZ to for the change, BZ is the vehicle for
any change in pegasus.

Please feel free and do let us know if you need anything else


On Wed, May 22, 2013 at 12:02 AM, David Marlin <dmarlin< at >redhat.com> wrote:

building tog-pegasus on 64-bit ARM

David Marlin — 2013-05-21T18:32:33

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

Re: Terminating provider process

Jan Safranek — 2013-05-20T08:16:40

Python terminates pretty quickly, that's fine. Problem is it cannot be
started again *in the same process*, it uses some global variables etc.
Therefore the only sane way is to exit the ProviderAgent process
immediately when the provider is unloaded.

Of course, fixing Python would be the best solution, but it seems it's
like this on purpose and changing this behavior would need really
significant changes in its design.

Jan

Re: Terminating provider process

Devchandra L Meetei — 2013-05-17T17:10:21

Hi Jan
As Marek pointed out, We have this in our radar. Please look at bug
9657<http://bugzilla.openpegasus.org/show_bug.cgi?id=9657>which will
track this.
Have started working on it and left it for some time now due to urgent
provider work.
I hate myself as a pegasus developer( would consider myself as pegasus
developer rather than a provider writer) to say that, unfortunately,it will
not make it to 2.13 from my end.
Volunteers like yourself are welcome.

Also was little alarmed by the figure you gave(15 mint), I was under the
impression that it is 5 minute(unless modified at packaging).

It has also been my experience that sometimes bad provider take longer time
to unload.







On Fri, May 17, 2013 at 5:22 PM, Jan Safranek <jsafrane< at >redhat.com> wrote:

Re: Terminating provider process

Kirk Augustin — 2013-05-17T15:54:25

Not sure I am following exactly, but isn't the problem more to do with the time delay in Python unloading?
I don't think the ProviderAgent closing down can be hastened if Python itself is slow to unload.
Nor do I think there should there be a crash because the provider is called again before the ProviderAgent process has shut down.
Which is why I wonder if both problems are really coming from Python, and not the ProviderAgent?
Is it possible to watch the Python process to see if it is what is causing the delay in the ProviderAgent closing?

Kirk  Augustin
11821 NW McNamee Rd
Portland, OR 97231


HM: 503-289-4356


>

Re: Terminating provider process

Jan Safranek — 2013-05-17T11:52:17

Hi Marek,

thanks for a reply.

On 05/17/2013 01:49 PM, Marek Szermutzky wrote:

Yes, that's it. As soon as the last provider is uloaded, I need to stop
ProviderAgent and it process (assuming there is such process).

Jan

Re: Terminating provider process

Marek Szermutzky — 2013-05-17T11:49:03

Hi Jan.


First I want to say thank you for reporting that issue.

Thank you Jan!

Secondly, we have picked up on this specific case of behavior, but 
we(OpenPegasus) do not have a performing and nice solution for it right 
now. But you started the discussion.
We have this issue on our radar, we talked about it in Architecture 
discussion on Thursday.



Now ... lets talk technical ... (I prefer this...> =))
Basically what you need is a ProviderAgent which closes down as soon as 
all providers have cleaned up, right ?


Marek 



From:   Jan Safranek <jsafrane< at >redhat.com>
To:     "pegasus-l< at >openpegasus.org" <pegasus-l< at >openpegasus.org>, 
Date:   15.05.2013 15:50
Subject:        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 pr

Terminating provider process

Jan Safranek — 2013-05-15T13:45:22

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

salutations!

Somnath kotur — 2013-05-13T19:39:01

   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
%

Re: Changing user credentials in Pegasus on Linux

Anuj Jain — 2013-05-13T15:27:54

Thank you Ashok/Marek,
This gives me good information. I might have to get back to you folks with
more questions.
Anuj


On Mon, May 13, 2013 at 11:13 AM, Marek Szermutzky
<MSzermutzky< at >de.ibm.com>wrote:

Re: Changing user credentials in Pegasus on Linux

Marek Szermutzky — 2013-05-13T15:13:02

Hi Anuj!


I have right now a feature request on the table about allowing remote 
change of a user's password. Though in this specific case invented to 
allow an update of an expired password, the same mechanism probably could 
be used. As Ashok wrote, on Linux people usually use PAM to handle their 
authentication needs.

The Bug report for this is: 
http://bugzilla.openpegasus.org/show_bug.cgi?id=9641 , planned to be 
implemented in OpenPegasus 2.13.


Kind regards
Marek Szermutzky
 
Software Engineer
IBM Systems &Technology Group, Systems Software Development / SW Linux on 
System z Development
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-5182
E-Mail: mszermutzky< at >de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & D

Re: Unloading a CMPI provider

Kirk Augustin — 2013-05-10T15:41:12

Sorry that I misunderstood.
The most common cause of not unloading is repeating enumertion requests by a client.
Logging your own provider activity would show this.

Kirk Augustin
11821 NW McNamee Rd
Portland, OR 97231


HM: 503-289-4356


>

Re: OpenPegasus conformance to DMTF spec DSP 203?

Ashok K Pathak — 2013-05-10T15:33:36

I look into below link and it has mentioned that  pegasus support  or based
on DMTF DSP0203 - XML Document Type Definition (DTD)

https://wiki.opengroup.org/pegasus-wiki/doku.php?id=doc:documentation_topics

Open Pegasus was created based on a significant number of DMTF
specifications including at least the following specifications. These
specifications are avialable from the DMTF Publication List and the version
supported by OpenPegasus depends on the release version of Open Pegasus.
Generally the version of each specification supported is documented in the
release notes for each version of Open Pegasus.

    DMTF DSP0004 - CIM Infrastructure Specification
    DMTF DSP0200 - CIM Operations over HTTP
    DMTF DSP0201 - Representation of CIM in XML
    DMTF DSP0202 - CIM Query Language Specification
    DMTF DSP0203 - XML Document Type Definition (DTD)
    DMTF DSP0205 - WBEM Discovery Using SLP
    DMTF DSP0206 - WBEM SLP Template
    DMTF DSP0223 - Generic Operations Specification
    DMTF DSP0226 - Web Ser

Re: Changing user credentials in Pegasus on Linux

Ashok K Pathak — 2013-05-10T09:14:28


Pegasus does  authentication/password management using system
user/passwords (PAM)

In other words,  Pegasus exploits PAM to  authentication & password
management
The PAM conf file for  Open Pegasus uses is usually
named /etc/pam.d/wbem.

For Setting up PAM authentication refer notes.txt  in folder
pegasus/src/Executor

      First compile with PEGASUS_PAM_AUTHENTICATION.

        Next install the PAM configuration file.

            % cd $PEGASUS_ROOT
            % cp rpm/wbem /etc/pam.d
            % chmod 0644 /etc/pam.d/wbem

      To build for standalone PAM authentication, compile with these:

            PEGASUS_PAM_AUTHENTICATION
            PEGASUS_USE_PAM_STANDALONE_PROC

       To run cimserver to use PAM
            enableAuthentication=true


<<<<
Hope it helps.

Regards
Ashok



                                                                           
             Anuj Jain                                                     
             <anujjain.work< at >gm