Re: turn off debug logging from org.apache.http.wire
Interesting. Thanks Larry. I'll dig more on my side.
On Sun, Apr 15, 2018 at 4:54 AM, larry mccay <lmc...@apache.org> wrote:
> No, I cannot reproduce it.
> If you are modifying the correct gateway-log4j.properties and restarting
> the server you should not see that.
>
> In fact, turning on DEBUG for wire via:
> log4j.logger.org.apache.http.wire=DEBUG
>
> Doesn't result in output in gateway.out for me but instead gateway.log and
> turning it on and off certainly works for me.
>
> You may have enabled TRACE logging if you are seeing body content - those
> settings are like the following:
>
> #log4j.logger.org.apache.knox.gateway.access=TRACE,httpaccess
> #log4j.additivity.org.apache.knox.gateway.access=false
>
> #log4j.logger.org.apache.knox.gateway.http=TRACE,httpserver
> #log4j.additivity.org.apache.knox.gateway.http=false
> ##log4j.logger.org.apache.knox.gateway.http.request.headers=OFF
> ##log4j.logger.org.apache.knox.gateway.http.response.headers=OFF
> ##log4j.logger.org.apache.knox.gateway.http.request.body=OFF
> ##log4j.logger.org.apache.knox.gateway.http.response.body=OFF
>
> I suggest you back up to the gateway-log4j.properties from the original
> install and remove any other log4j config that you may have elsewhere.
>
> On Sun, Apr 15, 2018 at 1:58 AM, Wei Han <wei...@uber.com> wrote:
>
>> Hi Larry - Thanks a lot for getting back to me.
>>
>> Yes I made sure all DEBUG level is turned off in my gateway-log4j.properties
>> file, but that doesn't seem to be working. I also tried to explicitly
>> set log4j.logger.httpclient.wire.header to WARN (as suggested in post
>> <https://stackoverflow.com/questions/4915414/disable-httpclient-logging>),
>> but that also didn't help.
>>
>> Actually it's very easy to reproduce this(at least on my side). If you
>> call knox with a webhdfs request (like
>> webhdfs/v1/tmp/weihan/small.txt?op=OPEN),
>> you should be able to see a bunch of below logs in gateway.out. In fact it
>> outputs the actual content on the wire(security hole?)
>>
>> 06:52:49.751 [qtp1473205473-61] DEBUG org.apache.http.wire -
>> http-outgoing-2 << "[0x0][0x0
>>
>> Let me know if you're able to repro this.
>>
>> Thanks.
>>
>> On Sat, Apr 14, 2018 at 7:11 AM, larry mccay <lmc...@apache.org> wrote:
>>
>>> Hi Wei -
>>>
>>> If you look at your gateway-log4j.properties file, you should see
>>> something like the following near the top:
>>>
>>> app.log.dir=${launcher.dir}/../logs
>>> app.log.file=${launcher.name}.log
>>> app.audit.file=${launcher.name}-audit.log
>>>
>>> log4j.rootLogger=ERROR, drfa
>>>
>>> log4j.logger.org.apache.knox.gateway=INFO
>>> #log4j.logger.org.apache.knox.gateway=DEBUG
>>>
>>> #log4j.logger.org.eclipse.jetty=DEBUG
>>> #log4j.logger.org.apache.shiro=DEBUG
>>> #log4j.logger.org.apache.http=DEBUG
>>> #log4j.logger.org.apache.http.client=DEBUG
>>> #log4j.logger.org.apache.http.headers=DEBUG
>>> #log4j.logger.org.apache.http.wire=DEBUG
>>>
>>> Note that all of the DEBUG settings are commented out.
>>> Also note that the rootLogger is set to ERROR and not DEBUG.
>>>
>>> Can you compare and share with us what yours are set to?
>>>
>>> thanks,
>>>
>>> --larry
>>>
>>> On Sat, Apr 14, 2018 at 2:56 AM, Wei Han <wei...@uber.com> wrote:
>>>
>>>> Hi Knox experts -
>>>>
>>>> Has anyone successfully turn off the debug loggings
>>>> from org.apache.http.wire, like below?
>>>>
>>>> 06:52:49.751 [qtp1473205473-61] DEBUG org.apache.http.wire -
>>>> http-outgoing-2 << "[0x0][0x0
>>>>
>>>> I've tried almost everything in this stackoverflow post
>>>> <https://stackoverflow.com/questions/4915414/disable-httpclient-logging>,
>>>> but my gateway.out is still filled with all the debug logs from httpclient.
>>>>
>>>> Any tip would be appreciated.
>>>>
>>>
>>>
>>
>
Re: turn off debug logging from org.apache.http.wire
Hi Larry - Thanks a lot for getting back to me.
Yes I made sure all DEBUG level is turned off in my gateway-log4j.properties
file, but that doesn't seem to be working. I also tried to explicitly set
log4j.logger.httpclient.wire.header to WARN (as suggested in post
<https://stackoverflow.com/questions/4915414/disable-httpclient-logging>),
but that also didn't help.
Actually it's very easy to reproduce this(at least on my side). If you call
knox with a webhdfs request (like webhdfs/v1/tmp/weihan/small.txt?op=OPEN),
you should be able to see a bunch of below logs in gateway.out. In fact it
outputs the actual content on the wire(security hole?)
06:52:49.751 [qtp1473205473-61] DEBUG org.apache.http.wire -
http-outgoing-2 << "[0x0][0x0
Let me know if you're able to repro this.
Thanks.
On Sat, Apr 14, 2018 at 7:11 AM, larry mccay <lmc...@apache.org> wrote:
> Hi Wei -
>
> If you look at your gateway-log4j.properties file, you should see
> something like the following near the top:
>
> app.log.dir=${launcher.dir}/../logs
> app.log.file=${launcher.name}.log
> app.audit.file=${launcher.name}-audit.log
>
> log4j.rootLogger=ERROR, drfa
>
> log4j.logger.org.apache.knox.gateway=INFO
> #log4j.logger.org.apache.knox.gateway=DEBUG
>
> #log4j.logger.org.eclipse.jetty=DEBUG
> #log4j.logger.org.apache.shiro=DEBUG
> #log4j.logger.org.apache.http=DEBUG
> #log4j.logger.org.apache.http.client=DEBUG
> #log4j.logger.org.apache.http.headers=DEBUG
> #log4j.logger.org.apache.http.wire=DEBUG
>
> Note that all of the DEBUG settings are commented out.
> Also note that the rootLogger is set to ERROR and not DEBUG.
>
> Can you compare and share with us what yours are set to?
>
> thanks,
>
> --larry
>
> On Sat, Apr 14, 2018 at 2:56 AM, Wei Han <wei...@uber.com> wrote:
>
>> Hi Knox experts -
>>
>> Has anyone successfully turn off the debug loggings
>> from org.apache.http.wire, like below?
>>
>> 06:52:49.751 [qtp1473205473-61] DEBUG org.apache.http.wire -
>> http-outgoing-2 << "[0x0][0x0
>>
>> I've tried almost everything in this stackoverflow post
>> <https://stackoverflow.com/questions/4915414/disable-httpclient-logging>,
>> but my gateway.out is still filled with all the debug logs from httpclient.
>>
>> Any tip would be appreciated.
>>
>
>
Re: conflicting outbound rewrite rules
Hi Larry - Thanks again for your reply. I dug more on this issue and I
think I've found the root cause. Please take a look at
https://issues.apache.org/jira/browse/KNOX-1157 when you get a chance.
Thanks.
On Wed, Dec 27, 2017 at 4:02 PM, larry mccay <lmc...@apache.org> wrote:
> Hi Wei -
>
> Sorry for not responding.
>
> Rewrite rules are global for REST APIs and local for anything else.
> So, for the UIs they should be resolving as local.
>
> Only REST APIs that require the rewrite rules from other services need
> global resolution.
> Things like Oozie.
>
> Do I owe you any other answer here?
>
> thanks,
>
> --larry
>
> On Wed, Dec 27, 2017 at 2:23 PM, Wei Han <wei...@uber.com> wrote:
>
>> Hi Larry - I haven't heard from you about this yet. Could you take a look
>> when you get a chance?
>>
>> On Wed, Dec 13, 2017 at 3:41 PM, Wei Han <wei...@uber.com> wrote:
>>
>>> Hi Larry - Thanks for your response. Actually hdfsui and sparkhistoryui
>>> are two different services. My understanding is a rewrite rule change in
>>> sparkhistoryui shouldn't affect hdfsui, is this the right assumption? Are
>>> these outbound rules designed to be global, or local to the service?
>>>
>>> Thanks.
>>>
>>> On Wed, Dec 13, 2017 at 12:12 PM, larry mccay <lmc...@apache.org> wrote:
>>>
>>>> Hi Wei -
>>>>
>>>> Thank you for tracking that down!
>>>>
>>>> Yes, I believe it is a bug but may be slightly more than that
>>>> considering the same service def is being used for multiple logical UIs.
>>>> Those being HDFSUI and SPARKHISTORYUI - these likely need to be broken
>>>> out separately to avoid such things.
>>>>
>>>> I suspect that sparkhistoryui isn't going to work now that you removed
>>>> that second rule.
>>>>
>>>> Can you please file a JIRA for this and if you provide a patch, we can
>>>> review and possibly commit it as is - as long as sparkhistory ui still
>>>> works.
>>>>
>>>> thanks again!
>>>>
>>>> --larry
>>>>
>>>> On Wed, Dec 13, 2017 at 2:55 PM, Wei Han <wei...@uber.com> wrote:
>>>>
>>>>> I found out that knox didn't rewrite /static/jquery-1.10.2.min.js in
>>>>> HDFS home page(url:
>>>>> https://knox_host:port/gateway/test/hdfs/dfshealth.html),
>>>>> which was causing some UI issues.
>>>>> After some digging, I found out the following two rules, which can
>>>>> both match the string (/static/jquery-1.10.2.min.js)
>>>>> If I remove rule2, the rewrite will start to work.
>>>>>
>>>>> Is this a bug? Shouldn't knox only apply rules for the same service(in
>>>>> my case hdfsui)?
>>>>>
>>>>>
>>>>> *rule1:*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *source:*
>>>>>
>>>>> https://github.com/apache/knox/blob/master/gateway-service-d
>>>>> efinitions/src/main/resources/services/hdfsui/2.7.0/rewrite.xml#L67
>>>>>
>>>>>
>>>>> *rule2:*
>>>>>
>>>>> >>>> pattern="/static/{jquery=jquery*.min.js}">
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *source:*
>>>>>
>>>>> https://github.com/apache/knox/blob/master/gateway-service-d
>>>>> efinitions/src/main/resources/services/sparkhistoryui/1.4.0/
>>>>> rewrite.xml#L56
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: conflicting outbound rewrite rules
Hi Larry - Thanks for your response. Actually hdfsui and sparkhistoryui are
two different services. My understanding is a rewrite rule change in
sparkhistoryui shouldn't affect hdfsui, is this the right assumption? Are
these outbound rules designed to be global, or local to the service?
Thanks.
On Wed, Dec 13, 2017 at 12:12 PM, larry mccay <lmc...@apache.org> wrote:
> Hi Wei -
>
> Thank you for tracking that down!
>
> Yes, I believe it is a bug but may be slightly more than that considering
> the same service def is being used for multiple logical UIs.
> Those being HDFSUI and SPARKHISTORYUI - these likely need to be broken out
> separately to avoid such things.
>
> I suspect that sparkhistoryui isn't going to work now that you removed
> that second rule.
>
> Can you please file a JIRA for this and if you provide a patch, we can
> review and possibly commit it as is - as long as sparkhistory ui still
> works.
>
> thanks again!
>
> --larry
>
> On Wed, Dec 13, 2017 at 2:55 PM, Wei Han <wei...@uber.com> wrote:
>
>> I found out that knox didn't rewrite /static/jquery-1.10.2.min.js in
>> HDFS home page(url: https://knox_host:port/gateway/test/hdfs/dfshealth.html),
>> which was causing some UI issues.
>> After some digging, I found out the following two rules, which can both
>> match the string (/static/jquery-1.10.2.min.js)
>> If I remove rule2, the rewrite will start to work.
>>
>> Is this a bug? Shouldn't knox only apply rules for the same service(in my
>> case hdfsui)?
>>
>>
>> *rule1:*
>>
>>
>>
>>
>>
>>
>>
>>
>> *source:*
>>
>> https://github.com/apache/knox/blob/master/gateway-service-
>> definitions/src/main/resources/services/hdfsui/2.7.0/rewrite.xml#L67
>>
>>
>> *rule2:*
>>
>> > pattern="/static/{jquery=jquery*.min.js}">
>>
>>
>>
>>
>>
>>
>> *source:*
>>
>> https://github.com/apache/knox/blob/master/gateway-service-
>> definitions/src/main/resources/services/sparkhistoryui/1.4.
>> 0/rewrite.xml#L56
>>
>>
>>
>>
>
Re: knox rewrite false positives
Thanks folks. I created https://issues.apache.org/jira/browse/KNOX-1106 with a patch to fix oozieui. On Fri, Oct 27, 2017 at 11:24 AM, Mohammad Islam <misla...@yahoo.com> wrote: > Thanks Wei and Sandeep to be on top of it. > > Wei, > One option could be to resolve the issue for Oozie first in one JIRA. And > then create a ticket for other UI's. > > > > On Friday, October 27, 2017, 9:58:49 AM PDT, Wei Han <wei...@uber.com> > wrote: > > > viewfs is not the original request, I guess it's part of a html body. > > Yes this can definitely work, I can provide a patch for oozie. However > this sounds like a potential issue for a lot of services(like yarnui, etc), > should we change all of them? > > On Fri, Oct 27, 2017 at 6:37 AM, Sandeep More <moresand...@gmail.com> > wrote: > > Hello Wei Han, > > Do you send 'viewfs://' as a request (like http) ? > > Also, there could be a chance that the protocol could be http or https, so > I think it would be better to handle both in the rewrite rules, for e.g. > > > http://*:*/**/oozie/; > > > > https://*:*/**/oozie/ "> > > > > > There could be a better way to handle this, if anyone knows please let me > know ! > > Best, > Sandeep > > > On Fri, Oct 27, 2017 at 1:15 AM, Wei Han <wei...@uber.com> wrote: > > We have seen some false positives with the current rewrite rules. For > example the following rule in oozieui will rewrite > viewfs://ns-default/foo/bar/oo zie/myfile.jar to > http://oozie:11000/oozie/myfil > e.jar <http://oozie:11000/oozie/myfile.jar> > pattern="*://*:*/**/oozie/"> > > > > The reason is the ** before 'oozie' in the pattern can match any number of > paths, however in reality any valid url(like https://localhost:844 > 3/gateway/sandbox/oozie/v1/job s?action=start > <https://localhost:8443/gateway/sandbox/oozie/v1/jobs?action=start>) > should only have two paths before 'oozie', so can we change the pattern to > "*://*:*/**/**/oozie/" (note the extra slash I added between the stars)? > > Another option is to make the scheme explicit in the patter, for example: > https://*:*/**/oozie/ > > Thanks. > > > > >
