Date   

Re: Configuring OpenLdap with ODL

Ryan Goulding <ryandgoulding@...>
 

Hi Harshit,

Did you replace the values in shiro.ini between square brackets <> with the appropriate values for your LDAP server?  By the way, ODL Beryllium is very old and has not been supported for quite some time.

Regards,

Ryan Goulding

On Tue, Apr 10, 2018 at 7:05 AM, Kaushik, Harshit (EXT - IN/Noida) <harshit.kaushik.ext@...> wrote:

Hi Ryan/Team,

 

I am trying to onfigure OpenLdap with ODL (Beryllium version).

 

I have done below changes in shiro.ini file

 

ldapRealm = org.opendaylight.aaa.shiro.realm.ODLJndiLdapRealmAuthNOnly

ldapRealm.userDnTemplate = uid={0},ou=people,dc=<my-Domain>,dc=<my-TLD>

ldapRealm.contextFactory.url = ldap://<url>:389

 

But I am not able to login to ODL. I am getting below logs in karaf.

 

2018-04-10 13:44:26,360 | DEBUG | qtp501175937-730 | TokenAuthRealm                   | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | Authentication attempt using org.opendaylight.aaa.basic.HttpBasicAuth

2018-04-10 13:44:26,360 | DEBUG | qtp501175937-730 | IdmLightProxy                    | 222 - org.opendaylight.aaa.idmlight - 0.3.4.Beryllium-SR4 | get domain

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | AbstractStore                    | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | Table DOMAINS already exists

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | DomainStore                      | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | query string: prep15: SELECT * FROM DOMAINS WHERE domainid = ?  {1: 'sdn'}

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | IdmLightProxy                    | 222 - org.opendaylight.aaa.idmlight - 0.3.4.Beryllium-SR4 | check user / pwd

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | UserStore                        | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | getUsers for: matrix in domain sdn

2018-04-10 13:44:26,372 | DEBUG | qtp501175937-730 | AbstractStore                    | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | Table USERS already exists

2018-04-10 13:44:26,372 | DEBUG | qtp501175937-730 | UserStore                        | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | query string: prep17: SELECT * FROM USERS WHERE userid = ?  {1: 'matrix@sdn'}

2018-04-10 13:44:26,373 | INFO  | qtp501175937-730 | ODLJndiLdapRealm                 | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | AAA LDAP connection from matrix

2018-04-10 13:44:26,373 | DEBUG | qtp501175937-730 | Accounter                        | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | AAA LDAP connection from matrix

2018-04-10 13:44:26,376 | DEBUG | qtp501175937-730 | AuthenticationListener           | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | Unsuccessful authentication attempt by matrix from <URL>

 

 

Please help me out in this.

Regards,

Harshit Kaushik



Re: Web Framework Discussion (continued from Kernel Call)

Ryan Goulding <ryandgoulding@...>
 

For the sake of being open, this [0] is the partial AAA conversion patch, and [1] is needed to test RESTCONF (RESTCONF currently depends on AAA loading the jersey 1.17 runtime dependencies, which isn't correct and should be fixed anyway).

On Wed, Apr 11, 2018 at 11:50 AM, Ryan Goulding <ryandgoulding@...> wrote:
Hi All,

During the Kernel call this past Tuesday, we talked about attempting an isolated transition of AAA restful web services from Jersey 1 to Jersey 2.  I attempted this change yesterday, and was able to partially convert (I just temporarily removed non-essential code that would've required overhaul).  However, when I compiled NETCONF next to test RESTCONF, I quickly realized that:

1) jersey-2.26 won't behave well, since it relies on javax.ws.rs-api 2.1 and jersey 1.17 relies on javax.ws.rs-api 2.0.1.  This leads to a Uses constraint violation since the dependency is provided via two chains (and two different versions too!).

2) jersey-2.25 won't work for a similar reason.  Even though it relies on the older javax.ws.rs-api 2.0.1 which is currently in place, jersey 1.17 repackages javax.ws.rs-api.  This means that utilizing the off the shelf javax.ws.rs-api 2.0.1 causes another Uses constraint violation, since the dependency is provided via upstream properly and jersey 1.17 in a repackaged form.

I am starting to really agree with the sentiment that we should just stick to only one implementation across the board.  Additionally, I believe that isolating this in an API (utility or not) will help the transition since there will be a single point to toggle the implementations.  We may want to also discuss the drawbacks of jersey 2.  Namely, it appears to require a ton of overhead dependencies and starts a bit slower in newer versions.  Maybe that is fine, but we should fully understand the tradeoffs before investing more time.  We should also settle on what the intended version should be for jersey 2 if we go that route, since jersey-2.26 is a lot different than even jersey-2.25.

Thoughts?

Regards,

Ryan


Web Framework Discussion (continued from Kernel Call)

Ryan Goulding <ryandgoulding@...>
 

Hi All,

During the Kernel call this past Tuesday, we talked about attempting an isolated transition of AAA restful web services from Jersey 1 to Jersey 2.  I attempted this change yesterday, and was able to partially convert (I just temporarily removed non-essential code that would've required overhaul).  However, when I compiled NETCONF next to test RESTCONF, I quickly realized that:

1) jersey-2.26 won't behave well, since it relies on javax.ws.rs-api 2.1 and jersey 1.17 relies on javax.ws.rs-api 2.0.1.  This leads to a Uses constraint violation since the dependency is provided via two chains (and two different versions too!).

2) jersey-2.25 won't work for a similar reason.  Even though it relies on the older javax.ws.rs-api 2.0.1 which is currently in place, jersey 1.17 repackages javax.ws.rs-api.  This means that utilizing the off the shelf javax.ws.rs-api 2.0.1 causes another Uses constraint violation, since the dependency is provided via upstream properly and jersey 1.17 in a repackaged form.

I am starting to really agree with the sentiment that we should just stick to only one implementation across the board.  Additionally, I believe that isolating this in an API (utility or not) will help the transition since there will be a single point to toggle the implementations.  We may want to also discuss the drawbacks of jersey 2.  Namely, it appears to require a ton of overhead dependencies and starts a bit slower in newer versions.  Maybe that is fine, but we should fully understand the tradeoffs before investing more time.  We should also settle on what the intended version should be for jersey 2 if we go that route, since jersey-2.26 is a lot different than even jersey-2.25.

Thoughts?

Regards,

Ryan


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Ryan Goulding <ryandgoulding@...>
 

it's up for interpretation as far as vulnerabilities.
 
Yeah, I am all for implementing good practice by default too, and I understand this is not optimal.  I purely wanted to make sure AAA didn't have a huge bug in the middle of it, which was my initial concern sitting in the Red Sox game when I received the initial message ;).

https://issues.apache.org/jira/browse/KARAF-5540.

Cool, Michael.  But AFAICT, in order to do "replacement" we would need to move odl-jolokia to odlparent from controller to avoid a build loop cycle.  Maybe that should be done anyway?

Another approach could be to fix jolokia to allow configuration changes at runtime, which I don't think it does at this time.  However, I am not sure if this was done on purpose in order to prevent dynamically changing jolokia Authentication strategy at runtime;  I haven't had enough exposure in that community to fully understand. 

Best Regards,

Ryan Goulding

On Tue, Apr 10, 2018 at 5:55 AM, Michael Vorburger <vorburger@...> wrote:
On Mon, Apr 9, 2018 at 7:49 PM, Jamo Luhrsen <jluhrsen@...> wrote:
it's up for interpretation as far as vulnerabilities.

seems by default, the vulnerability is there. However, one can argue that users need
to RTFM, go restart their deployment, ya da ya da ya da (hi robert...) to avoid
the non-authenticated jolokia endpoints.

JamO

On 4/9/18 10:44 AM, Ryan Goulding wrote:
Cool, so there shouldn't be any gaping vulnerabilities as was originally indicated?  Not sure what is installed for features by default anymore, but "jolokia" is part of the karaf standard features we pull in [0].  Stephen, do you know of anyway to strip that out?

 
Thanks,

Ryan

[0] https://github.com/apache/karaf/blob/karaf-4.1.x/assemblies/features/standard/src/main/feature/feature.xml#L1446

On Mon, Apr 9, 2018 at 1:38 PM, Jamo Luhrsen <jluhrsen@... <mailto:jluhrsen@...>> wrote:

    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 <jluhrsen@... <mailto:jluhrsen@...>> 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 <jluhrsen@... <mailto:jluhrsen@...>
                <mailto:jluhrsen@... <mailto:jluhrsen@...>>> 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 <ryandgoulding@...
                <mailto:ryandgoulding@...m> <mailto:ryandgoulding@...m <mailto:ryandgoulding@...m>>
                         <mailto:ryandgoulding@...m <mailto:ryandgoulding@...m>
                <mailto:ryandgoulding@...m <mailto:ryandgoulding@...m>>>> 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 <vorburger@...
                <mailto:vorburger@...> <mailto:vorburger@... <mailto:vorburger@...>>
                         <mailto:vorburger@... <mailto:vorburger@...> <mailto:vorburger@...
                <mailto:vorburger@...>>>> wrote:
                                  JamO, +aaa-dev and +controller-dev and Stephen FYI:
                                  On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@...
                <mailto:jluhrsen@...> <mailto:jluhrsen@... <mailto:jluhrsen@...>>
                             <mailto:jluhrsen@... <mailto:jluhrsen@...> <mailto:jluhrsen@...
                <mailto:jluhrsen@...>>>>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>>
                                  <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>>
                                  <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
                vorburger@... <mailto:vorburger@...> <mailto:vorburger@...
                <mailto:vorburger@...>> <mailto:vorburger@... <mailto:vorburger@...>
                             <mailto:vorburger@... <mailto:vorburger@...>>>| 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>>
                                                                <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-dev@...ght.org <mailto:infrautils-dev@...pendaylight.org>
                <mailto:infrautils-dev@...pendaylight.org <mailto:infrautils-dev@...pendaylight.org>>
                             <mailto:infrautils-dev@...pendaylight.org
                <mailto:infrautils-dev@...pendaylight.org> <mailto:infrautils-dev@...pendaylight.org
                <mailto:infrautils-dev@...pendaylight.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>>
                                      <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@...ght.org <mailto:controller-dev@...pendaylight.org>
                <mailto:controller-dev@...pendaylight.org <mailto:controller-dev@...pendaylight.org>>
                             <mailto:controller-dev@...pendaylight.org
                <mailto:controller-dev@...pendaylight.org> <mailto:controller-dev@...pendaylight.org
                <mailto:controller-dev@...pendaylight.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>>
                                  <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>>>





Configuring OpenLdap with ODL

Kaushik, Harshit (EXT - IN/Noida) <harshit.kaushik.ext@...>
 

Hi Ryan/Team,

 

I am trying to onfigure OpenLdap with ODL (Beryllium version).

 

I have done below changes in shiro.ini file

 

ldapRealm = org.opendaylight.aaa.shiro.realm.ODLJndiLdapRealmAuthNOnly

ldapRealm.userDnTemplate = uid={0},ou=people,dc=<my-Domain>,dc=<my-TLD>

ldapRealm.contextFactory.url = ldap://<url>:389

 

But I am not able to login to ODL. I am getting below logs in karaf.

 

2018-04-10 13:44:26,360 | DEBUG | qtp501175937-730 | TokenAuthRealm                   | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | Authentication attempt using org.opendaylight.aaa.basic.HttpBasicAuth

2018-04-10 13:44:26,360 | DEBUG | qtp501175937-730 | IdmLightProxy                    | 222 - org.opendaylight.aaa.idmlight - 0.3.4.Beryllium-SR4 | get domain

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | AbstractStore                    | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | Table DOMAINS already exists

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | DomainStore                      | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | query string: prep15: SELECT * FROM DOMAINS WHERE domainid = ?  {1: 'sdn'}

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | IdmLightProxy                    | 222 - org.opendaylight.aaa.idmlight - 0.3.4.Beryllium-SR4 | check user / pwd

2018-04-10 13:44:26,367 | DEBUG | qtp501175937-730 | UserStore                        | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | getUsers for: matrix in domain sdn

2018-04-10 13:44:26,372 | DEBUG | qtp501175937-730 | AbstractStore                    | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | Table USERS already exists

2018-04-10 13:44:26,372 | DEBUG | qtp501175937-730 | UserStore                        | 221 - org.opendaylight.aaa.h2-store - 0.3.4.Beryllium-SR4 | query string: prep17: SELECT * FROM USERS WHERE userid = ?  {1: 'matrix@sdn'}

2018-04-10 13:44:26,373 | INFO  | qtp501175937-730 | ODLJndiLdapRealm                 | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | AAA LDAP connection from matrix

2018-04-10 13:44:26,373 | DEBUG | qtp501175937-730 | Accounter                        | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | AAA LDAP connection from matrix

2018-04-10 13:44:26,376 | DEBUG | qtp501175937-730 | AuthenticationListener           | 211 - org.opendaylight.aaa.shiro - 0.3.4.Beryllium-SR4 | Unsuccessful authentication attempt by matrix from <URL>

 

 

Please help me out in this.

Regards,

Harshit Kaushik


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Michael Vorburger <vorburger@...>
 

On Mon, Apr 9, 2018 at 7:49 PM, Jamo Luhrsen <jluhrsen@...> wrote:
it's up for interpretation as far as vulnerabilities.

seems by default, the vulnerability is there. However, one can argue that users need
to RTFM, go restart their deployment, ya da ya da ya da (hi robert...) to avoid
the non-authenticated jolokia endpoints.

JamO

On 4/9/18 10:44 AM, Ryan Goulding wrote:
Cool, so there shouldn't be any gaping vulnerabilities as was originally indicated?  Not sure what is installed for features by default anymore, but "jolokia" is part of the karaf standard features we pull in [0].  Stephen, do you know of anyway to strip that out?

 
Thanks,

Ryan

[0] https://github.com/apache/karaf/blob/karaf-4.1.x/assemblies/features/standard/src/main/feature/feature.xml#L1446

On Mon, Apr 9, 2018 at 1:38 PM, Jamo Luhrsen <jluhrsen@... <mailto:jluhrsen@...>> wrote:

    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 <jluhrsen@... <mailto:jluhrsen@...>> 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 <jluhrsen@... <mailto:jluhrsen@...>
                <mailto:jluhrsen@... <mailto:jluhrsen@...>>> 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 <ryandgoulding@...
                <mailto:ryandgoulding@...m> <mailto:ryandgoulding@...m <mailto:ryandgoulding@...m>>
                         <mailto:ryandgoulding@...m <mailto:ryandgoulding@...m>
                <mailto:ryandgoulding@...m <mailto:ryandgoulding@...m>>>> 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 <vorburger@...
                <mailto:vorburger@...> <mailto:vorburger@... <mailto:vorburger@...>>
                         <mailto:vorburger@... <mailto:vorburger@...> <mailto:vorburger@...
                <mailto:vorburger@...>>>> wrote:
                                  JamO, +aaa-dev and +controller-dev and Stephen FYI:
                                  On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@...
                <mailto:jluhrsen@...> <mailto:jluhrsen@... <mailto:jluhrsen@...>>
                             <mailto:jluhrsen@... <mailto:jluhrsen@...> <mailto:jluhrsen@...
                <mailto:jluhrsen@...>>>>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>>
                                  <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>>
                                  <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
                vorburger@... <mailto:vorburger@...> <mailto:vorburger@...
                <mailto:vorburger@...>> <mailto:vorburger@... <mailto:vorburger@...>
                             <mailto:vorburger@... <mailto:vorburger@...>>>| 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>>
                                                                <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-dev@...ght.org <mailto:infrautils-dev@...pendaylight.org>
                <mailto:infrautils-dev@...pendaylight.org <mailto:infrautils-dev@...pendaylight.org>>
                             <mailto:infrautils-dev@...pendaylight.org
                <mailto:infrautils-dev@...pendaylight.org> <mailto:infrautils-dev@...pendaylight.org
                <mailto:infrautils-dev@...pendaylight.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>>
                                      <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@...ght.org <mailto:controller-dev@...pendaylight.org>
                <mailto:controller-dev@...pendaylight.org <mailto:controller-dev@...pendaylight.org>>
                             <mailto:controller-dev@...pendaylight.org
                <mailto:controller-dev@...pendaylight.org> <mailto:controller-dev@...pendaylight.org
                <mailto:controller-dev@...pendaylight.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>>
                                  <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>>>




Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Jamo Luhrsen <jluhrsen@...>
 

it's up for interpretation as far as vulnerabilities.

seems by default, the vulnerability is there. However, one can argue that users need
to RTFM, go restart their deployment, ya da ya da ya da (hi robert...) to avoid
the non-authenticated jolokia endpoints.

JamO

On 4/9/18 10:44 AM, Ryan Goulding wrote:
Cool, so there shouldn't be any gaping vulnerabilities as was originally indicated?  Not sure what is installed for features by default anymore, but "jolokia" is part of the karaf standard features we pull in [0].  Stephen, do you know of anyway to strip that out?
Thanks,
Ryan
[0] https://github.com/apache/karaf/blob/karaf-4.1.x/assemblies/features/standard/src/main/feature/feature.xml#L1446
On Mon, Apr 9, 2018 at 1:38 PM, Jamo Luhrsen <jluhrsen@gmail.com <mailto:jluhrsen@gmail.com>> wrote:
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 <jluhrsen@gmail.com <mailto:jluhrsen@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 <jluhrsen@gmail.com <mailto:jluhrsen@gmail.com>
<mailto:jluhrsen@gmail.com <mailto:jluhrsen@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 <ryandgoulding@gmail.com
<mailto:ryandgoulding@gmail.com> <mailto:ryandgoulding@gmail.com <mailto:ryandgoulding@gmail.com>>
        <mailto:ryandgoulding@gmail.com <mailto:ryandgoulding@gmail.com>
<mailto:ryandgoulding@gmail.com <mailto:ryandgoulding@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 <vorburger@redhat.com
<mailto:vorburger@redhat.com> <mailto:vorburger@redhat.com <mailto:vorburger@redhat.com>>
        <mailto:vorburger@redhat.com <mailto:vorburger@redhat.com> <mailto:vorburger@redhat.com
<mailto:vorburger@redhat.com>>>> wrote:
                 JamO, +aaa-dev and +controller-dev and Stephen FYI:
                 On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@gmail.com
<mailto:jluhrsen@gmail.com> <mailto:jluhrsen@gmail.com <mailto:jluhrsen@gmail.com>>
            <mailto:jluhrsen@gmail.com <mailto:jluhrsen@gmail.com> <mailto:jluhrsen@gmail.com
<mailto:jluhrsen@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>>
                 <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>>
                 <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
vorburger@redhat.com <mailto:vorburger@redhat.com> <mailto:vorburger@redhat.com
<mailto:vorburger@redhat.com>> <mailto:vorburger@redhat.com <mailto:vorburger@redhat.com>
            <mailto:vorburger@redhat.com <mailto:vorburger@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>>
<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-dev@lists.opendaylight.org <mailto:infrautils-dev@lists.opendaylight.org>
<mailto:infrautils-dev@lists.opendaylight.org <mailto:infrautils-dev@lists.opendaylight.org>>
            <mailto:infrautils-dev@lists.opendaylight.org
<mailto:infrautils-dev@lists.opendaylight.org> <mailto:infrautils-dev@lists.opendaylight.org
<mailto:infrautils-dev@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>>
                     <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>>
            <mailto: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>>
                 <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>>>


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Ryan Goulding <ryandgoulding@...>
 

Cool, so there shouldn't be any gaping vulnerabilities as was originally indicated?  Not sure what is installed for features by default anymore, but "jolokia" is part of the karaf standard features we pull in [0].  Stephen, do you know of anyway to strip that out?

Thanks,

On Mon, Apr 9, 2018 at 1:38 PM, Jamo Luhrsen <jluhrsen@...> wrote:
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!!



On Apr 7, 2018, at 12:19 PM, Jamo Luhrsen <jluhrsen@...> 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 <jluhrsen@... <mailto:jluhrsen@...>> 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 <ryandgoulding@... <mailto:ryandgoulding@...m>
        <mailto:ryandgoulding@...m <mailto:ryandgoulding@...m>>> 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 <vorburger@... <mailto:vorburger@...>
        <mailto:vorburger@... <mailto:vorburger@...>>> wrote:
                 JamO, +aaa-dev and +controller-dev and Stephen FYI:
                 On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@... <mailto:jluhrsen@...>
            <mailto:jluhrsen@... <mailto:jluhrsen@...>>>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
            vorburger@... <mailto:vorburger@...> <mailto:vorburger@...
            <mailto:vorburger@...>>| 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-dev@...ght.org <mailto:infrautils-dev@...pendaylight.org>
            <mailto:infrautils-dev@...pendaylight.org <mailto:infrautils-dev@...pendaylight.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@...ght.org <mailto:controller-dev@...pendaylight.org>
            <mailto:controller-dev@...pendaylight.org <mailto:controller-dev@...pendaylight.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>>


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Jamo Luhrsen <jluhrsen@...>
 

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 <jluhrsen@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 <jluhrsen@gmail.com <mailto:jluhrsen@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 <ryandgoulding@gmail.com <mailto:ryandgoulding@gmail.com>
<mailto:ryandgoulding@gmail.com <mailto:ryandgoulding@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 <vorburger@redhat.com <mailto:vorburger@redhat.com>
<mailto:vorburger@redhat.com <mailto:vorburger@redhat.com>>> wrote:
JamO, +aaa-dev and +controller-dev and Stephen FYI:
On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@gmail.com <mailto:jluhrsen@gmail.com>
<mailto:jluhrsen@gmail.com <mailto:jluhrsen@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
vorburger@redhat.com <mailto:vorburger@redhat.com> <mailto:vorburger@redhat.com
<mailto:vorburger@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-dev@lists.opendaylight.org <mailto:infrautils-dev@lists.opendaylight.org>
<mailto:infrautils-dev@lists.opendaylight.org <mailto:infrautils-dev@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>>


Fw: Announcing that Apache Oltu has been moved to the Attic

Stephen Kitt <skitt@...>
 

Hello AAA devs,

This is relevant to AAA... (I know Ryan intended to move away from
Oltu, this just adds another nail to the coffin.)

Regards,

Stephen


Begin forwarded message:

Date: Sun, 8 Apr 2018 13:49:00 +0200
From: jani@apache.org
To: announce@apache.org
Subject: Announcing that Apache Oltu has been moved to the Attic


Announcing that the Apache Oltu committers have voted to retire the
project due to inactivity. Oltu was an OAuth protocol implementation in
Java. It also covers others "OAuth family" related implementations such
as JWT, JWS and OpenID Connect.

Retiring a project is not as simple as turning everything off, as
existing users need to both know that the project is retiring and
retain access to the necessary information for their own development
efforts. You can read more about Oltu's retirement at:
http://attic.apache.org/projects/Oltu.html The user mailing list
remains open, while the rest of the project's resources will continue
to be available in a read-only state - website, wikis, svn, downloads
and bug tracker with no change in url. Providing process and solutions
to make it clear when an Apache project has reached its end of life is
the role of the Apache Attic, and you can read more about that at:
http://attic.apache.org/

Thanks, Jan Iversen on behalf of the Apache Attic and the now retired
Apache Oltu project



--
Stephen Kitt
Principal Software Engineer, Office of the CTO
Red Hat


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Ryan Goulding <ryandgoulding@...>
 

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!!

On Apr 7, 2018, at 12:19 PM, Jamo Luhrsen <jluhrsen@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 <jluhrsen@gmail.com <mailto:jluhrsen@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 <ryandgoulding@gmail.com <mailto:ryandgoulding@gmail.com>
<mailto:ryandgoulding@gmail.com <mailto:ryandgoulding@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 <vorburger@redhat.com <mailto:vorburger@redhat.com>
<mailto:vorburger@redhat.com <mailto:vorburger@redhat.com>>> wrote:
JamO, +aaa-dev and +controller-dev and Stephen FYI:
On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@gmail.com <mailto:jluhrsen@gmail.com>
<mailto:jluhrsen@gmail.com <mailto:jluhrsen@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
vorburger@redhat.com <mailto:vorburger@redhat.com> <mailto:vorburger@redhat.com
<mailto:vorburger@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-dev@lists.opendaylight.org <mailto:infrautils-dev@lists.opendaylight.org>
<mailto:infrautils-dev@lists.opendaylight.org <mailto:infrautils-dev@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>>


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Jamo Luhrsen <jluhrsen@...>
 

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 <jluhrsen@gmail.com <mailto:jluhrsen@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 <ryandgoulding@gmail.com <mailto:ryandgoulding@gmail.com>
<mailto:ryandgoulding@gmail.com <mailto:ryandgoulding@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 <vorburger@redhat.com <mailto:vorburger@redhat.com>
<mailto:vorburger@redhat.com <mailto:vorburger@redhat.com>>> wrote:
    JamO, +aaa-dev and +controller-dev and Stephen FYI:
    On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@gmail.com <mailto:jluhrsen@gmail.com>
<mailto:jluhrsen@gmail.com <mailto:jluhrsen@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
vorburger@redhat.com <mailto:vorburger@redhat.com> <mailto:vorburger@redhat.com
<mailto:vorburger@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-dev@lists.opendaylight.org <mailto:infrautils-dev@lists.opendaylight.org>
<mailto:infrautils-dev@lists.opendaylight.org <mailto:infrautils-dev@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>>


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Ryan Goulding <ryandgoulding@...>
 

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 <jluhrsen@...> 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 <ryandgoulding@... <mailto:ryandgoulding@...m>> 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 <vorburger@... <mailto:vorburger@...>> wrote:

    JamO, +aaa-dev and +controller-dev and Stephen FYI:

    On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@... <mailto:jluhrsen@...>>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> and 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
    vorburger@... <mailto:vorburger@...>| 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>

        Thanks,
        JamO
        _______________________________________________
        infrautils-dev mailing list
        infrautils-dev@...ght.org <mailto:infrautils-dev@...pendaylight.org>
        https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
        <https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>


    _______________________________________________
    controller-dev mailing list
    controller-dev@...ght.org <mailto:controller-dev@...pendaylight.org>
    https://lists.opendaylight.org/mailman/listinfo/controller-dev
    <https://lists.opendaylight.org/mailman/listinfo/controller-dev>




Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Jamo Luhrsen <jluhrsen@...>
 

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 <ryandgoulding@gmail.com <mailto:ryandgoulding@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 <vorburger@redhat.com <mailto:vorburger@redhat.com>> wrote:

JamO, +aaa-dev and +controller-dev and Stephen FYI:

On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@gmail.com <mailto:jluhrsen@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> and 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
vorburger@redhat.com <mailto:vorburger@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>

Thanks,
JamO
_______________________________________________
infrautils-dev mailing list
infrautils-dev@lists.opendaylight.org <mailto:infrautils-dev@lists.opendaylight.org>
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>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
<https://lists.opendaylight.org/mailman/listinfo/controller-dev>


Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Ryan Goulding <ryandgoulding@...>
 

Jamo, can you comment on code version?  Thanks!

Regards,

Ryan Goulding

On Thu, Apr 5, 2018 at 7:10 AM, Ryan Goulding <ryandgoulding@...> 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


On Apr 5, 2018, at 12:32 AM, Michael Vorburger <vorburger@...> wrote:

JamO, +aaa-dev and +controller-dev and Stephen FYI:

On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@...> 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 and 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
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch
 
example curl:

curl -u "admin:admin" http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus

Thanks,
JamO
_______________________________________________
infrautils-dev mailing list
infrautils-dev@...ght.org
https://lists.opendaylight.org/mailman/listinfo/infrautils-dev

_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: add "Fluorine" to Versions list in AAA JIRA project

Ryan Goulding <ryandgoulding@...>
 

Done. Apologies for the delay!

Regards,

Ryan Goulding

On Wed, Apr 4, 2018 at 11:28 AM, Michael Vorburger <vorburger@...> wrote:
On Wed, Mar 14, 2018 at 11:26 AM, Michael Vorburger <vorburger@...> wrote:
Ryan or any other active AAA committer,

would you be able to add "Fluorine" to Versions list in the AAA JIRA project?

Ryan, would you be able to do this?
 
Tx,
M.
--
Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch



Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Ryan Goulding <ryandgoulding@...>
 

What version of code? This wasn’t tied to AAA until oxygen. Prior it was controlled by etc/or.jolokia.osgi.cfg.

Thanks,
Ryan


On Apr 5, 2018, at 12:32 AM, Michael Vorburger <vorburger@...> wrote:

JamO, +aaa-dev and +controller-dev and Stephen FYI:

On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@...> 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 and 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
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch
 
example curl:

curl -u "admin:admin" http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus

Thanks,
JamO
_______________________________________________
infrautils-dev mailing list
infrautils-dev@...ght.org
https://lists.opendaylight.org/mailman/listinfo/infrautils-dev

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

Michael Vorburger <vorburger@...>
 

JamO, +aaa-dev and +controller-dev and Stephen FYI:

On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhrsen@...> 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 and 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
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch
 
example curl:

curl -u "admin:admin" http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus

Thanks,
JamO
_______________________________________________
infrautils-dev mailing list
infrautils-dev@...ght.org
https://lists.opendaylight.org/mailman/listinfo/infrautils-dev


Re: add "Fluorine" to Versions list in AAA JIRA project

Michael Vorburger <vorburger@...>
 

On Wed, Mar 14, 2018 at 11:26 AM, Michael Vorburger <vorburger@...> wrote:
Ryan or any other active AAA committer,

would you be able to add "Fluorine" to Versions list in the AAA JIRA project?

Ryan, would you be able to do this?
 
Tx,
M.
--
Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch


Fluorine kernel projects planning from the DDF

Stephen Kitt <skitt@...>
 

Hi everyone,

During the DDF we had a kernel projects planning session. Here are my
notes:

Fluorine kernel projects planning session


Clustering
==========

Improve clustering: look at the three-node CSIT and fix the
issues. Make it run reliably so it can be used as a stable base.
Distinguish between failures related to the clustering layer itself,
and failures caused by poor clustering support in individual modules.
We know of one Akka issue we're currently tracking but it's hard to
reproduce and difficult to get Akka upstream involved. Start by
getting Vratko's clustering test-suite stable (it doesn't use any
plug-ins), then work on fixing plug-in issues revealed by the full
CSIT suite.

Ask TAC about buying some upstream support from Akka-supporting
companies? (Need to talk to the governing board, add this to the goals
document. Action => Daniel Farrell.)

Use the lab-as-a-service offering from OPNFV, to see whether the
improved reproducibility promised there helps with the issues we're
seeing. However since the issues we're seeing are now back to the same
on Vexxhost as we had with Rackspace, there's a strong possibility
that the issues are inherent to ODL/Akka and not related to the
hosting environment.

Need to reduce the complexity involved in developing plugins which
behave correctly in a clustered environment (recover from failed
connections etc.). Cluster singleton is documented but users need to
satisfy every single API requirement to the letter. We also have
conflicting requirements, and recovery has different meanings for
different services (e.g. deleting state from external hardware when a
cluster node is no longer its owner) — big mismatch between cluster
singleton requirements and southbound plug-in requirements when the
plug-ins need to synchronise their state across the cluster and with
devices. So at the kernel level we need detailed requirements
describing what other projects want to do; then we could expose new
features if necessary (including Akka features which aren't exposed
currently). Entity ownership service helps a lot.

We will follow up on these points in the kernel call. Action => Anil
Vishnoi to document requirements.

Tell-based: weird behaviour seen in CSIT, need to investigate that
before re-enabling.


Network use
===========

Some plug-ins use the data store for high volume storage, which
results in heavy network use. The data store isn't designed for this
use case, and perhaps we should define limits beyond which other tools
should be used (Cassandra etc.)

We need performance testing, and work on updating our published
performance numbers. We need to instrument performance testing so we
can spot regressions and measure improvements (see Bitergia).


Data store debugging
====================

What is the recommended way to retrieve the data store contents from a
non-shard-leader node? Ask-based Akka limits the amount of data we can
transfer; with tell-based we'll be able to do better. Whether this
makes it in Fluorine is still uncertain.


AAA
===

Removal of web.xml in favour of the code-based configuration
framework.

Jackson migration, done today.

Replace the OLTU-based token server.

More protection, better encryption.


Controller
==========

Fluorine: a lot of clean-up:
* DataChangeListener is up for removal; it was deprecated in Carbon
and scheduled for removal in Fluorine. All the ODL projects have
been converted away from DCL; downstream projects *will* need to
perform the same migration after Fluorine is
released. DataTreeChangeListener provides a better interface with
better performance.
* The controller implementations of the MD-SAL APIs should be dropped
in favour of the MD-SAL versions. This will take many releases but
we will start deprecating them in Fluorine.
* The Config Sub-System is up for removal. The people who wrote it no
longer maintain it, and all of ODL has already switched to
BluePrint.
* The in-memory datastore will be removed (it's also available in
MD-SAL).


MD-SAL
======

Binding v2 won't be ready in Fluorine.

Binding v1 is being retro-fitted to fix the more grievous issues (see
the mailing list). This will allow v1 to keep us ticking over until v2
is ready.

Clean up the DOM-level APIs to better support new use cases.

Support for actions and nested notifications in Fluorine and possible
Oxygen SR2.

MD-SAL will probably become release-based at the end of Fluorine.


Infrautils
==========

See the dedicated Infrautils session.


NETCONF
=======

Same trajectory, nothing major (maintenance mode).

We need to start testing the RFC 8040-based version of NETCONF
(instead of bierman).


Federation
==========

The project is dead; if anyone wants to revive it, see Robert Varga.




Please join the Kernel Projects Call, Tuesdays at 9am Pacific:
https://wiki.opendaylight.org/view/Kernel_Projects_Call




Regards,

--
Stephen Kitt
Principal Software Engineer, Office of the CTO
Red Hat

161 - 180 of 1823