jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi <ignasi.barr...@gmail.com>
Subject Re: Details logs for the exception
Date Thu, 16 May 2013 16:39:50 GMT
Hmm, they should be there.
I've noticed thar the log directory is only writeable by root. Does your
application process (or the eclipse one) have write permissions there?
El 16/05/2013 18:13, "Rahul Nema" <rahulnema@in.ibm.com> escribió:

> No the logs are not there . I created the file manually but still no luck
>
> [root@devvm test-data]# ls -l
> total 0
> -rw-r--r--. 1 root root 0 May 16 21:19 jclouds.log
> [root@devvm test-data]#
>
>
> With warm  regards,
>  ------------------------------------------------------------
> Rahul Nema,
> Tivoli Group
> IBM-India Software Lab,Pune
> Mo: +91-9860254300
> ------------------------------------------------------------
>
>
>
> From:        Ignasi <ignasi.barrera@gmail.com>
> To:        user@jclouds.incubator.apache.org,
> Cc:        George Moberly <george@opscode.com>, Lisbeth Arriaza <
> larriaza@us.ibm.com>, Vijay K Sukthankar/India/IBM@IBMIN
> Date:        05/16/2013 09:31 PM
> Subject:        Re: Details logs for the exception
> ------------------------------
>
>
>
> According to your logback.xml file, logs should have been written to
> "/iwd/workspace/ChefIntegration/log/test-data/jclouds-wire.log". Are
> the logs there?
> I can not see a ConsoleAppender configured there, so don't expect a
> console output.
>
>
>
>
> On 16 May 2013 17:51, Rahul Nema <rahulnema@in.ibm.com> wrote:
> > Hi,
> >
> > Did as mentioned but this time there are no errors but still not able to
> see
> > the log files generated. The console output in ecllipse is the same.
> >
> > context = ContextBuilder.newBuilder("chef") //
> >                     .endpoint(endpoint) //
> >                     .modules(ImmutableSet.<Module> of(new
> > SLF4JLoggingModule())) //
> >                     .credentials(client, credentialForClient(credsDir,
> > client)) //
> >                     .buildView(ChefContext.class);
> >
> > Added this
> >
> >
> >
> >
> > [root@devvm ChefIntegration]# ls -l
> > total 24
> > drwxr-xr-x. 3 root root 4096 May 16 20:42 bin
> > drwxr-xr-x. 2 root root 4096 May 16 20:39 lib
> > drwxr-xr-x. 3 root root 4096 May 16 21:19 log
> > -rw-r--r--. 1 root root 3795 May 16 11:52 log4j.xml
> > -rw-r--r--. 1 root root 1804 May 16 20:49 logback.xml
> > drwxr-xr-x. 3 root root 4096 May  4 22:19 src
> > [root@devvm ChefIntegration]#
> >
> >
> > With warm  regards,
> >  ------------------------------------------------------------
> > Rahul Nema,
> > Tivoli Group
> > IBM-India Software Lab,Pune
> > Mo: +91-9860254300
> > ------------------------------------------------------------
> >
> >
> >
> > From:        Ignasi <ignasi.barrera@gmail.com>
> > To:        user@jclouds.incubator.apache.org,
> > Cc:        George Moberly <george@opscode.com>, Lisbeth Arriaza
> > <larriaza@us.ibm.com>, Vijay K Sukthankar/India/IBM@IBMIN
> > Date:        05/16/2013 07:56 PM
> > Subject:        Re: Details logs for the exception
> > ________________________________
> >
> >
> >
> > There are three steps you should do:
> >
> > 1. Add the driver dependency for your logging framework. Assuming
> logback:
> >
> > <dependency>
> >  <groupId>org.apache.jclouds.driver</groupId>  <!-- May be >
> org.jclouds.driver if using older versions of jclouds -->
> >  <artifactId>jclouds-slf4j</artifactId>
> >  <version>yout jclouds version</version>
> > </dependenvy>
> >
> > 2. When creating the ChefContext, make sure you configure the slf4j
> > logging module. Something like:
> >
> > ChefContext context = ContextBuilder.newBuilder("the chef provider ") //
> >    .endpoint("the chef endpoint") //
> >    .credentials(client, credential) //
> >    .modules(ImmutableSet.<Module> of(new SLF4JLoggingModule())) //
> >    .buildView(ChefContext.class);
> >
> > 3. Make sure you have a 'logback.xml' file in the root of your
> > classpath with the desired logging configuration. You can use the
> > example file [1] as a template, and modify it to fit your logging
> > needs. In your case, it should be enough to change the root log level
> > to DEBUG.
> >
> >
> >
> > HTH
> >
> >
> >
> > [1]
> >
> https://github.com/jclouds/jclouds/blob/master/compute/src/test/resources/logback.xml
> >
> > On 16 May 2013 15:57, Rahul Nema <rahulnema@in.ibm.com> wrote:
> >> Hi,
> >>
> >> I tried today to add the logs but was not able to do that correctly. It
> >> seems not able to configure log4j correctly. Can you please help how
> can I
> >> enable the logs.
> >>
> >> With warm  regards,
> >>  ------------------------------------------------------------
> >> Rahul Nema,
> >> Tivoli Group
> >> IBM-India Software Lab,Pune
> >> Mo: +91-9860254300
> >> ------------------------------------------------------------
> >>
> >>
> >>
> >> From:        Ignasi <ignasi.barrera@gmail.com>
> >> To:        user@jclouds.incubator.apache.org,
> >> Cc:        George Moberly <george@opscode.com>, Vijay K
> >> Sukthankar/India/IBM@IBMIN, Lisbeth Arriaza <larriaza@us.ibm.com>
> >> Date:        05/16/2013 11:00 AM
> >> Subject:        Re: Details logs for the exception
> >> ________________________________
> >>
> >>
> >>
> >> That's right Rahul.
> >>
> >> Take a look at the jclouds logging documentation [1]. You'll find there
> >> how
> >> to configure it as well as some example files for the different logging
> >> frameworks.
> >>
> >> As said in previous emails, the signature may be properly generated (the
> >> mentioned unit tests pass). If that is the case the issue might be when
> >> the
> >> request is sent. (Maybe something about the concrete implementation of
> the
> >> HttpUrlConnection class on the IBM jvm?, just saying...)
> >>
> >> [1] http://www.jclouds.org/documentation/reference/jclouds-logging
> >>
> >> El 16/05/2013 05:54, "Rahul Nema" <rahulnema@in.ibm.com> escribió:
> >> Hi,
> >>
> >> Sorry could not continue working in the last night. I am back now so
> will
> >> start the debug. So if I understand Ignasi correctly there will be no
> >> exception for java as it is not failing. We need to compare the
> component
> >> of
> >> the header which is not correctly generated by JVM. And then look for
> the
> >> code which generates that particular component of the header. Please
> >> confirm
> >> if my understanding is correct.
> >>
> >> Also can you please help me How I can change the log level " log the
> >> category "jclouds.headers" at DEBUG or TRACE?" How do I achieve this in
> my
> >> java code.
> >>
> >> With warm  regards,
> >>  ------------------------------------------------------------
> >> Rahul Nema,
> >> Tivoli Group
> >> IBM-India Software Lab,Pune
> >> Mo: +91-9860254300
> >> ------------------------------------------------------------
> >>
> >>
> >>
> >> From:        Ignasi <ignasi.barrera@gmail.com>
> >> To:        Lisbeth Arriaza <larriaza@us.ibm.com>,
> >> Cc:        George Moberly <george@opscode.com>, Rahul
> >> Nema/India/IBM@IBMIN,
> >> user@jclouds.incubator.apache.org, Vijay K Sukthankar/India/IBM@IBMIN
> >> Date:        05/16/2013 03:05 AM
> >> Subject:        Re: Details logs for the exception
> >>
> >> ________________________________
> >>
> >>
> >>
> >> Just to avoid confusion, note that the exception thrown is a
> >> "org.jclouds.rest.AuthorizationException". Note the package. It is not
> >> an exception thrown by a Java Security component. It is an exception
> >> generated by jclouds when the backend (the Chef server in this case)
> >> returns an HTTP response with a status code 401.
> >>
> >> I should not focus in a concrete Java Security component, but try to
> >> find why the requests generated by the IBM JVM are not acceptable by
> >> the Chef server, following the hints given in the previous email.
> >>
> >> On 15 May 2013 23:32, Lisbeth Arriaza <larriaza@us.ibm.com> wrote:
> >>> Thanks Ignasi.  Unfortunately I am not able to see what exact Java
> >>> Security
> >>> component is being used here that can cause the problem.  I believe the
> >>> best
> >>> option at this point is to enable the tracing you recommend.  Hopefully
> >>> it
> >>> can shed some light.
> >>>
> >>> Rahul,  Please gather the trace logs advised by Adrian and Ignasi so
> they
> >>> can help us to review the output.
> >>>
> >>> Thank you.
> >>> Best regards,
> >>>
> >>> Lisbeth Arriaza
> >>> Java Security Support
> >>> IBM Security Compliance (IAM)
> >>> IBM Security Systems Division
> >>>
> >>> Submit and manage your PMRs online 24x7 using IBM Service Request.
> >>> ________________________________
> >>> Phone: +502 2410 4366
> >>> E-mail: larriaza@us.ibm.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> From:        Ignasi <ignasi.barrera@gmail.com>
> >>> To:        Lisbeth Arriaza/Fairfax/Contr/IBM@IBMUS,
> >>> Cc:        George Moberly <george@opscode.com>,
> >>> user@jclouds.incubator.apache.org, Vijay K Sukthankar
> >>> <vksuktha@in.ibm.com>,
> >>> Rahul Nema <rahulnema@in.ibm.com>
> >>> Date:        05/15/2013 03:11 PM
> >>> Subject:        Re: Details logs for the exception
> >>> ________________________________
> >>>
> >>>
> >>>
> >>> Hi Lisbeth,
> >>>
> >>> The AuthorizationException you get, is raised because the Chef server
> is
> >>> returning a "401 Unauthorized" response, which is caused by a request
> >>> having
> >>> invalid credentials.
> >>>
> >>> The way authentication works in Chef [1] is by signing the request and
> >>> adding a set of headers with the signature, a timestamp, and a few more
> >>> fields. All those headers are validated by the Chef server in order to
> >>> decide if the request is authorized or not. In your case, it seems that
> >>> the
> >>> request that arrives to the Chef server does not contain the
> appropriate
> >>> values in the headers.
> >>>
> >>> The class that adds those headers to each http request sent to the Chef
> >>> server is the SignedHeaderAuth class [2]. This class is invoked before
> >>> sending any http request. There is also a unit test class [3] that
> >>> verifies
> >>> that the signatures are being properly generated, so if that test
> >>> succeeds,
> >>> the problem may not be in the signature generation. Anyway, it is worth
> >>> checking it.
> >>>
> >>> If the issue is not in the signature generation, then is might be in
> the
> >>> code executed between the signature is generated and the request is
> >>> actually
> >>> sent. If you want to take a look at this, the class that sends the
> >>> request
> >>> is the JavaUrlHttpCommandExecutorService [4], in the jclouds core.
> >>>
> >>> It is also a good idea, as Adrian suggested, to turn on the wire and
> >>> trace
> >>> logs, as they will output the request (and the headers) that are being
> >>> sent.
> >>>
> >>>
> >>> HTH
> >>>
> >>> Ignasi
> >>>
> >>>
> >>> [1] http://docs.opscode.com/auth_authentication.html
> >>> [2]
> >>>
> >>>
> >>>
> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/filters/SignedHeaderAuth.java
> >>> [3]
> >>>
> >>>
> >>>
> https://github.com/jclouds/jclouds-chef/blob/master/core/src/test/java/org/jclouds/chef/filters/SignedHeaderAuthTest.java
> >>> [4]
> >>>
> >>>
> >>>
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java
> >>>
> >>>
> >>> On 15 May 2013 22:56, Lisbeth Arriaza <larriaza@us.ibm.com> wrote:
> >>> Hello,
> >>>
> >>> You had mentioned that the issue may be related to the signature not
> >>> being
> >>> generated properly .  Can you please provide a link to the code that
> >>> generates the signature?  We need to see how this application is
> calling
> >>> the
> >>> IBM JVM APIs.
> >>>
> >>> Thanks.
> >>> Best regards,
> >>>
> >>> Lisbeth Arriaza
> >>> Java Security Support
> >>> IBM Security Compliance (IAM)
> >>> IBM Security Systems Division
> >>>
> >>> Submit and manage your PMRs online 24x7 using IBM Service Request.
> >>> ________________________________
> >>> Phone: +502 2410 4366
> >>> E-mail: larriaza@us.ibm.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> From:        Ignasi <ignasi.barrera@gmail.com>
> >>> To:        user@jclouds.incubator.apache.org,
> >>> Cc:        George Moberly <george@opscode.com>, Vijay K Sukthankar
> >>> <vksuktha@in.ibm.com>, Lisbeth Arriaza/Fairfax/Contr/IBM@IBMUS
> >>> Date:        05/15/2013 11:10 AM
> >>> Subject:        Re: Details logs for the exception
> >>> ________________________________
> >>>
> >>>
> >>>
> >>> Re-reading the old thread, if the tests in the SignedHeaderAuthTest
> pass,
> >>> the problem shouldn't be in the signature.
> >>>
> >>> Follow Adrian's advice and turn on the wire logs to see the exact
> request
> >>> that is being sent. Also take a look at this class [1]. It is the one
> >>> that
> >>> actually performs the http requests. Maybe the jvm specific issues are
> >>> caused there.
> >>>
> >>> [1]
> >>>
> >>>
> >>>
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java
> >>>
> >>> El 15/05/2013 18:40, "Ignasi" <ignasi.barrera@gmail.com> escribió:
> >>> The thing here is that there is no specific code that directly causes
> >>> that stacktrace.
> >>> All requests to a chef server must have the headers signed (that is
> >>> how authentication works in chef), and that signature is not being
> >>> generated properly with your JRE. That's why the Chef server rejects
> >>> the request.
> >>>
> >>> As told in the old thread, you can check this by running the
> >>> SignedHeaderAuthTest class.
> >>> What comes to my mind, is to run and debug that test class with a JVM
> >>> that works and with your JVM, to try find and isolate where the
> >>> generated signatures differ, so you can see what the JVMs are doing
> >>> different
> >>>
> >>>
> >>> On 15 May 2013 18:32, Rahul Nema <rahulnema@in.ibm.com> wrote:
> >>>> Hi,
> >>>>
> >>>> So I am running this code(Java) inside eclipse using a stand-alone
> java
> >>>> file
> >>>> and added jClouds Jar as dependency. Correct Ignasi supported us last
> >>>> time
> >>>> as well.
> >>>>
> >>>> Yes this code works in other level of JRE so it is a specific problem
> >>>> with
> >>>> this version of JRE but we need to solve this one as it is with the
> >>>> product
> >>>> which we are integrating with so no JRE change allowed.
> >>>>
> >>>> My question is so How can I get more details log such that we can
> track
> >>>> the
> >>>> exact Java class which is causing the issue or the component which
> leads
> >>>> to
> >>>> this.
> >>>>
> >>>> Do I need to add some property which I run the java program which i
> use
> >>>> to
> >>>> connect.
> >>>>
> >>>> this is the code which I use today
> >>>>
> >>>>  context = ContextBuilder.newBuilder("chef") //
> >>>>                     .endpoint(endpoint) //
> >>>>                     .credentials(client, credentialForClient(credsDir,
> >>>> client)) //
> >>>>                     .buildView(ChefContext.class);
> >>>>
> >>>> I feel github has all the java files can you please look into the flow
> >>>> and
> >>>> let me know. I passed the link to the java support team but they were
> >>>> not
> >>>> able to get it in the flow.
> >>>>
> >>>>
> >>>> With warm  regards,
> >>>>  ------------------------------------------------------------
> >>>> Rahul Nema,
> >>>> Tivoli Group
> >>>> IBM-India Software Lab,Pune
> >>>> Mo: +91-9860254300
> >>>> ------------------------------------------------------------
> >>>>
> >>>>
> >>>>
> >>>> From:        Ignasi <ignasi.barrera@gmail.com>
> >>>> To:        user@jclouds.incubator.apache.org,
> >>>> Cc:        Lisbeth Arriaza <larriaza@us.ibm.com>, George Moberly
> >>>> <george@opscode.com>, Vijay K Sukthankar/India/IBM@IBMIN
> >>>> Date:        05/15/2013 09:56 PM
> >>>> Subject:        Re: Details logs for the exception
> >>>> ________________________________
> >>>>
> >>>>
> >>>>
> >>>> I remember the issue [1], and with other JREs it worked fine.
> >>>> This [2] is the class that generates the signature for each request.
> >>>> Maybe you can debug it or add some extra traces to see what's going
> >>>> on.
> >>>>
> >>>>
> >>>> [1] https://groups.google.com/d/msg/jclouds/KXPHgHxxQXg/V_EfNFpV3jcJ
> >>>> [2]
> >>>>
> >>>>
> >>>>
> >>>>
> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/filters/SignedHeaderAuth.java
> >>>>
> >>>> On 15 May 2013 18:23, Adrian Cole <adrian.f.cole@gmail.com> wrote:
> >>>>> can you run the same command with a different JRE and log the
> category
> >>>>> "jclouds.headers" at DEBUG or TRACE?
> >>>>>
> >>>>>
> >>>>> On Wed, May 15, 2013 at 9:17 AM, Rahul Nema <rahulnema@in.ibm.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I am getting this exception when using IBM JRE of a specific
> version.
> >>>>>> It
> >>>>>> seems to be a problem with the JRE but the support team need
more
> logs
> >>>>>> and
> >>>>>> java component which is causing this issue.
> >>>>>>
> >>>>>> Can you please help us providing some details of which Java
Security
> >>>>>> components we call and also how can we get exact java stack
trace
> for
> >>>>>> the
> >>>>>> problem .
> >>>>>>
> >>>>>> This urgent a component release blocked because of this error.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> With warm  regards,
> >>>>>>  ------------------------------------------------------------
> >>>>>> Rahul Nema,
> >>>>>> Tivoli Group
> >>>>>> IBM-India Software Lab,Pune
> >>>>>> Mo: +91-9860254300
> >>>>>> ------------------------------------------------------------
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
>
>
>

Mime
View raw message