jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Nema <rahuln...@in.ibm.com>
Subject Re: Details logs for the exception
Date Thu, 16 May 2013 19:48:02 GMT
Hi,

Yes I am running the process as root . also tried changing the permission 
I am not sure why but still don't have any logs .

I create all the files still no luck 

[root@devvm test-data]# ls -l
total 0
-rwxrwxr-x. 1 root root 0 May 17 00:52 jclouds-compute.log
-rwxrwxr-x. 1 root root 0 May 16 21:19 jclouds.log
-rwxrwxr-x. 1 root root 0 May 17 00:52 jclouds-ssh.log
-rwxrwxr-x. 1 root root 0 May 17 00:51 jclouds-wire.log
[root@devvm test-data]#

Also I ran the program in the debugger still same results no logs as per 
now 

ChefContext context = getContext(credsDir, endpoint, org, client);
                        if(context!=null){
                                Set<String> nodes = 
context.getApi(ChefApi.class).listNodes();   --- It cataches the exception 
at this point 

I still feel the error is in  the getContext it self but it seems when we 
call the api then only run the validations.

Please let me know what i can do to get the logs if it is needed we can 
have a live debugging session in your evening today after some 9 hours, 
planning to have some sleep now.

Also if you are able to print the logs can you please let me know which 
are the class files which are likely to be causing this issues will be a 
great help. 


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 10:09 PM
Subject:        Re: Details logs for the exception



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