ok, yeah. after restarting, it seems the jolokia endpoint is now adhering to
the proper credentials.

I'm confused about the karaf jolokia stuff though. Is there no way to dump
that and only allow our odl-jolokia feature to be available? That was
pretty confusing to me. I never asked for anything jolokia to be installed
originally, but I guess it was by default.

JamO

On 4/7/18 1:07 PM, Ryan Goulding wrote:
Did you restart ODL after installing odl-jolikia? The issue is you have jolikia 
installed from karaf without auth, then try to install odl-jolikia which lays 
down org.jolikia.osgi.cfg with authMode set to delegate. That managed service 
won’t actually recognize the update to authmode without a restart of Karaf. You 
want to ONLY ever install odl-jolokia!!

Sent from my iPhone

On Apr 7, 2018, at 12:19 PM, Jamo Luhrsen <jluhr...@gmail.com> wrote:

ok, I verified that carbon sr3 is working as we expect, but the recent Fluorine
snapshot distro I have is not behaving like I expect.

I am able to hit this 
jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
endpoint after just installing features-aaa, nothing else. The user/password 
doesn't
seem to matter.

After installing odl-jolokia, it's the same behavior.

should I open a jira, or what other info can I gather?

Thanks,
JamO

On 4/5/18 3:45 PM, Ryan Goulding wrote:
for carbon-sr3 we still hadn't integrated jolokia with AAA;  it was still 
backed by etc/org.jolokia.osgi.cfg, hencewhy you need to use admin/admin after 
changing the password in AAA.
How did you install jolokia in Fluorine?  You must install using "odl-jolokia" feature 
from controller to get protection.  Standard off the shelf "jolokia" has NO auth by 
default...
Regards,
Ryan Goulding
On Thu, Apr 5, 2018 at 6:23 PM, Jamo Luhrsen <jluhr...@gmail.com 
<mailto:jluhr...@gmail.com>> wrote:
    I don't have access to my setup at the moment. I can later.
    but, I think it's based on carbon sr3.
    I do have a recent (2/27) snapshot distro from Fluorine though,
    and that actually doesn't even need creds to access that
    jolokia diagstatus endpoint. restconf still behaves like I
    expect, but the diagstatus endpoint takes any (or no)
    username/password combo.
    JamO
    On 4/5/18 12:06 PM, Ryan Goulding wrote:
        Jamo, can you comment on code version?  Thanks!
        Regards,
        Ryan Goulding
        On Thu, Apr 5, 2018 at 7:10 AM, Ryan Goulding <ryandgould...@gmail.com 
<mailto:ryandgould...@gmail.com>
        <mailto:ryandgould...@gmail.com <mailto:ryandgould...@gmail.com>>> 
wrote:
             What version of code? This wasn’t tied to AAA until oxygen. Prior 
it was controlled by etc/or.jolokia.osgi.cfg.
             Thanks,
             Ryan
             Sent from my iPhone
             On Apr 5, 2018, at 12:32 AM, Michael Vorburger <vorbur...@redhat.com 
<mailto:vorbur...@redhat.com>
        <mailto:vorbur...@redhat.com <mailto:vorbur...@redhat.com>>> wrote:
                 JamO, +aaa-dev and +controller-dev and Stephen FYI:
                 On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhr...@gmail.com 
<mailto:jluhr...@gmail.com>
            <mailto:jluhr...@gmail.com <mailto:jluhr...@gmail.com>>>wrote:
                     Hi Utility folks,
                     I noticed in a local setup I have where I've changed the 
default username
                     and password for RESTCONF, that I still need to use the 
admin:admin creds
                     to hit the diagstatus endpoint.
                     I'm guessing that's just because this is not tied in to 
the magic of
                     AAA and/or RESTCONF creds.
                     Gotta just live with it, or would it be an easy thing to 
add, just to keep
                     things more intuitive?
                 This seems like a bug (bad one, security wise), but it's not 
for infrautils-dev - we don't actually do
            anything
                 re. Jolokia in project infrautils, the diagstatus sub-module 
simply exposes a JMX bean... the code
            related to the
                 Jolokia integration in ODL which then make makes this 
available via HTTP, and secures it with the AAA
            creds (also
                 used by RESTCONF; there are no creds in RESTCONF itself FYI), 
is actually in controller and/or aaa (I'm
            not 100%
                 sure myself what is where)... see 
https://jira.opendaylight.org/browse/AAA-147
            <https://jira.opendaylight.org/browse/AAA-147>
                 <https://jira.opendaylight.org/browse/AAA-147 
<https://jira.opendaylight.org/browse/AAA-147>> and
            https://jira.opendaylight.org/browse/CONTROLLER-1324 
<https://jira.opendaylight.org/browse/CONTROLLER-1324>
                 <https://jira.opendaylight.org/browse/CONTROLLER-1324
            <https://jira.opendaylight.org/browse/CONTROLLER-1324>>.
                 If you are right, we have this problem (that when changing the 
default username and password you can
            still use the
                 previous one) on *ALL* /jolokia/ URLs, I'm guessing.
                 Would you like to open a (Critical?) bug in JIRA against AAA 
about this?
                 Tx,
                 M.
                 --
                 Michael Vorburger, Red Hat
            vorbur...@redhat.com <mailto:vorbur...@redhat.com> 
<mailto:vorbur...@redhat.com
            <mailto:vorbur...@redhat.com>>| IRC: vorburger @freenode | ~ = 
http://vorburger.ch
                 <http://vorburger.ch/>
                     example curl:
                     curl -u "admin:admin"
            
http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
            
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus>
                                
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
            
<http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus>>
                     Thanks,
                     JamO
                     _______________________________________________
                     infrautils-dev mailing list
            infrautils-...@lists.opendaylight.org 
<mailto:infrautils-...@lists.opendaylight.org>
            <mailto:infrautils-...@lists.opendaylight.org 
<mailto:infrautils-...@lists.opendaylight.org>>
            https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
            <https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>
                     
<https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
            <https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>>
                 _______________________________________________
                 controller-dev mailing list
            controller-dev@lists.opendaylight.org 
<mailto:controller-dev@lists.opendaylight.org>
            <mailto:controller-dev@lists.opendaylight.org 
<mailto:controller-dev@lists.opendaylight.org>>
            https://lists.opendaylight.org/mailman/listinfo/controller-dev
            <https://lists.opendaylight.org/mailman/listinfo/controller-dev>
                 <https://lists.opendaylight.org/mailman/listinfo/controller-dev
            <https://lists.opendaylight.org/mailman/listinfo/controller-dev>>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to