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:02:15 GMT
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