I have debugged the python management part which gets the attribute and it
seems to be not reading them from the json config file as it is supposed to. Am
I missing something?
python/qpid_dispatch/management/entity.py (Added code to print attributed to
file)
class EntityBase(object):
"""
A collection of named attributes.
Attribute access:
- via index operator: entity['foo']
- as python attributes: entity.foo (only if attribute name is a legal
python identitfier
after replacing '-' with '_')
@ivar attributes: Map of attribute values for this entity.
NOTE: EntityBase does not itself implement the python map protocol because
map
methods (in particular 'update') can clash with AMQP methods and attributes.
"""
def __init__(self, attributes=None, **kwargs):
self.__dict__['attributes'] = {}
if attributes:
file = open("py.log", "a")
for k, v in attributes.iteritems():
file.write("Attribute: %s = %s\n" %(k,v))
self.attributes[k] = v
self.__dict__[self._pyname(k)] = v
file.close()
for k, v in kwargs.iteritems():
self._set(k, v)
py.log
Attribute: stripAnnotations = both
Attribute: requireSsl = 0
Attribute: idleTimeoutSeconds = 16
Attribute: host = 127.0.0.1
Attribute: cost = 1
Attribute: port = 10399
Attribute: addr = 0.0.0.0
Attribute: saslMechanisms = ANONYMOUS
Attribute: maxFrameSize = 16384
Attribute: requireEncryption = False
Attribute: role = normal
Attribute: authenticatePeer = 0
Attribute: type = org.apache.qpid.dispatch.listener
Regards,
Adel
> From: [email protected]
> To: [email protected]
> Subject: RE: [Qpid-dispatch] Duplication between sslProfile and connector
> options
> Date: Mon, 20 Jun 2016 15:02:01 +0200
>
> I found something which might be interesting. Actually the config of the
> Listener is not taken into consideration.
> With the config you proposed, if you check the below log in the dispatcher,
> the parameters are not taken into consideration. For example, the requiresSSL
> is always False although we have set it to "yes"
>
> Log line:
> Mon Jun 20 14:59:10 2016 AGENT (debug) Add entity:
> ListenerEntity(addr=0.0.0.0, authenticatePeer=False, cost=1, host=127.0.0.1,
> identity=listener/127.0.0.1:10399, idleTimeoutSeconds=16, maxFrameSize=16384,
> port=10399, requireEncryption=False, requireSsl=False, role=normal,
> saslMechanisms=ANONYMOUS, stripAnnotations=both,
> type=org.apache.qpid.dispatch.listener)
>
> Regards,
> Adel
>
> > From: [email protected]
> > To: [email protected]
> > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and connector
> > options
> > Date: Mon, 20 Jun 2016 12:56:02 +0200
> >
> > Hello,
> >
> > I took the latest available dispatcher version (0.6.0-RC4) and replayed my
> > test and tried to send a message using a JMS producer.
> > The connection is failing at the level of the handshake. I also have the
> > SSL debug output java side. On the dispatcher side, I can see that it is
> > receiving an incomming connection.
> >
> > PS: I can still connect using plain AMQP which works correctly. Shouldn't
> > requireSsl prohibit access using amqp connctions and only allow amqps
> > connection?
> >
> > Dispatcher config
> > container {
> > worker-threads: 4
> > containerName: qpid.dispatch.router1
> > }
> >
> > ssl-profile {
> > name: ssl-profile-name
> > certFile: cert_lx.pem
> > keyFile: key_lx.pem
> > }
> >
> > listener {
> > host: 0.0.0.0
> > port: 10399
> > sasl-mechanisms: ANONYMOUS
> > ssl-profile: ssl-profile-name
> > authenticatePeer: no
> > requireSsl: yes
> > }
> >
> > router {
> > mode: interior
> > routerId: router1
> > helloInterval: 60
> > helloMaxAge: 180
> > }
> >
> > log {
> > module: DEFAULT
> > enable: debug+
> > source: false
> > output: dispatch.10399.log
> > }
> >
> > JMS Client code
> > System.setProperty("javax.net.ssl.trustStore",
> > "qpidJavaBrokerTrustStore_linux");
> > System.setProperty("javax.net.debug", "ssl");
> >
> > ConnectionFactory connectionFactory = new
> > JmsConnectionFactory("amqps://my_host:10399");
> > Connection connection = connectionFactory.createConnection();Dispatcher log
> > Mon Jun 20 12:52:45 2016 SERVER (debug) Accepting incoming connection from
> > HOSTNAME:63045 to 0.0.0.0:10399
> >
> > JMS Client log with SSL debug
> > ...
> > *** ClientHello, TLSv1.2
> > RandomCookie: GMT: 1466354171 bytes = { 248, 170, 229, 244, 118, 59, 153,
> > 155, 21, 89, 4, 185, 137, 154, 73, 114, 21, 226, 79, 55, 146, 199, 75, 60,
> > 207, 41, 22, 42 }
> > Session ID: {}
> > Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
> > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
> > TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA,
> > SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA,
> > TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
> > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
> > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
> > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
> > SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
> > Compression Methods: { 0 }
> > Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2,
> > secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1,
> > secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1,
> > secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1,
> > sect193r2, secp224k1, sect239k1, secp256k1}
> > Extension ec_point_formats, formats: [uncompressed]
> > Extension signature_algorithms, signature_algorithms: SHA512withECDSA,
> > SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA,
> > SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA,
> > SHA1withDSA, MD5withRSA
> > ***
> > nioEventLoopGroup-2-1, WRITE: TLSv1.2 Handshake, length = 193
> > 20 juin 2016 12:52:43,925 DEBUG ResourceLeakDetector -
> > -Dio.netty.leakDetectionLevel: simple
> > nioEventLoopGroup-2-1, called closeOutbound()
> > nioEventLoopGroup-2-1, closeOutboundInternal()
> > nioEventLoopGroup-2-1, SEND TLSv1 ALERT: warning, description =
> > close_notify
> > nioEventLoopGroup-2-1, WRITE: TLSv1 Alert, length = 2
> > nioEventLoopGroup-2-1, called closeInbound()
> > nioEventLoopGroup-2-1, fatal error: 80: Inbound closed before receiving
> > peer's close_notify: possible truncation attack?
> > javax.net.ssl.SSLException: Inbound closed before receiving peer's
> > close_notify: possible truncation attack?
> > nioEventLoopGroup-2-1, SEND TLSv1 ALERT: fatal, description =
> > internal_error
> > nioEventLoopGroup-2-1, Exception sending alert: java.io.IOException: writer
> > side was already closed.
> > 20 juin 2016 12:52:43,941 DEBUG SslHandler - Failed to complete handshake
> > java.nio.channels.ClosedChannelException
> > 20 juin 2016 12:52:43,942 ERROR JmsConnectionFactory - Failed to create JMS
> > Provider instance for: amqps
> >
> > Regards,
> > Adel
> >
> > > Subject: Re: [Qpid-dispatch] Duplication between sslProfile and connector
> > > options
> > > From: [email protected]
> > > To: [email protected]
> > > Date: Tue, 14 Jun 2016 13:53:35 -0400
> > >
> > > On Fri, 2016-06-10 at 16:47 +0200, Adel Boutros wrote:
> > > >
> > > >
> > > > The page you provided suits my needs.
> > >
> > > FYI, the real authority for dispatch configuration is:
> > >
> > > python/qpid_dispatch/management/qdrouter.json
> > >
> > > The man pages and configuration chapter are generated from that and are
> > > easier to read, but they have some hand-written sections that are out
> > > of date (all fixed or being fixed I think.)
> > >
> > > > However, I have a problem running SSL. I have configured the
> > > > dispatcher (0.6.0 RC 4) as follows:
> > > > ssl-profile {
> > > > name: ssl-profile-name certFile:
> > > > CERTIFICATE_DIR/cert_lx.pem keyFile: PRIVATE_KEY_DIR/key_lx.pem}
> > > > listener { host: 0.0.0.0 port: 10399 sasl-mechanisms:
> > > > ANONYMOUS ssl-profile: ssl-profile-name requirePeerAuth:
> > > > no requireSsl: yes}
> > > > Yet, I cannot even cannot using qdmanage:
> > > > qdmanage --ssl-certificate=CERTIFICATE_DIR/cert_lx.pem --ssl-
> > > > key=PRIVATE_KEY_DIR/key_lx.pem -b amqps://0.0.0.0:10399 create --
> > > > type=autoLink addr=queue dir=out connection=localhost.5672.connector
> > > > name=localhost.5672.queue
> > > >
> > > > Exception client-side:
> > > > SSLUnavailable:
> > > >
> > > > Weird incomplete message, no?
> > > >
> > > > Regards,
> > > > Adel
> > > >
> > > > >
> > > > > Date: Fri, 10 Jun 2016 10:11:25 -0400
> > > > > From: [email protected]
> > > > > To: [email protected]
> > > > > Subject: Re: [Qpid-dispatch] Duplication between sslProfile and
> > > > > connector options
> > > > >
> > > > > Hi Adel,
> > > > > You can find the entire list of entities and attributes here -
> > > > >
> > > > > http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.
> > > > > conf.html
> > > > >
> > > > > I will purge the book of dashed entity/attribute names on the
> > > > > master branch. I have entered a JIRA for this so it can be tracked
> > > > > -
> > > > >
> > > > > https://issues.apache.org/jira/browse/DISPATCH-377
> > > > >
> > > > > Thanks.
> > > > >
> > > > > ----- Original Message -----
> > > > > >
> > > > > > From: "Adel Boutros" <[email protected]>
> > > > > > To: [email protected]
> > > > > > Sent: Friday, June 10, 2016 9:43:38 AM
> > > > > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and
> > > > > > connector options
> > > > > >
> > > > > > One last section, where in the book can I find the fields for
> > > > > > ssl-profile
> > > > > > configuration? I searched in Configuration Entities and found
> > > > > > everything
> > > > > > except "ssl-profile" fields.
> > > > > > >
> > > > > > > From: [email protected]
> > > > > > > To: [email protected]
> > > > > > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and
> > > > > > > connector
> > > > > > > options
> > > > > > > Date: Fri, 10 Jun 2016 15:39:13 +0200
> > > > > > >
> > > > > > > Thank you Ganesh,
> > > > > > > Is this documented somewhere? Will the dashed properties be
> > > > > > > removed from
> > > > > > > the Book to avoid such confusion in the future?
> > > > > > > Regards,Adel
> > > > > > >
> > > > > > > >
> > > > > > > > Date: Fri, 10 Jun 2016 08:30:15 -0400
> > > > > > > > From: [email protected]
> > > > > > > > To: [email protected]
> > > > > > > > Subject: Re: [Qpid-dispatch] Duplication between sslProfile
> > > > > > > > and connector
> > > > > > > > options
> > > > > > > >
> > > > > > > > Hi Adel,
> > > > > > > > Going forward please use the camelCase and abandon using
> > > > > > > > dashed
> > > > > > > > properties (like cert-file). Following is an example of
> > > > > > > > the *correct*
> > > > > > > > way to use certFile
> > > > > > > >
> > > > > > > > sslProfile {
> > > > > > > > certFile: /home/gmurthy/opensource/server-certificate.pem
> > > > > > > > keyFile: /home/gmurthy/opensource//server-private-key.pem
> > > > > > > > password: some-password
> > > > > > > > name: client-ssl-profile
> > > > > > > > certDb: /home/gmurthy/opensource/ca-certificate.pem
> > > > > > > > }
> > > > > > > >
> > > > > > > > connector {
> > > > > > > > addr: 127.0.0.1
> > > > > > > > role: inter-router
> > > > > > > > sslProfile: client-ssl-profile # This connector will use
> > > > > > > > the
> > > > > > > > sslProfile with the name client-ssl-profile
> > > > > > > > port: 24976
> > > > > > > > }
> > > > > > > >
> > > > > > > > Notice above that we specified certFile in only one place
> > > > > > > > (inside the
> > > > > > > > sslProfile)
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > >
> > > > > > > > > From: "Adel Boutros" <[email protected]>
> > > > > > > > > To: [email protected]
> > > > > > > > > Sent: Friday, June 10, 2016 6:32:06 AM
> > > > > > > > > Subject: [Qpid-dispatch] Duplication between sslProfile and
> > > > > > > > > connector
> > > > > > > > > options
> > > > > > > > >
> > > > > > > > > Hello guys,
> > > > > > > > > In the ssl-profile, we can define some options such as
> > > > > > > > > "cert-file".
> > > > > > > > > When we
> > > > > > > > > define a connector, we can provide the name of ssl-profile
> > > > > > > > > and we can
> > > > > > > > > set
> > > > > > > > > "certFile". What is the behavior if we defined a cert-file
> > > > > > > > > in the
> > > > > > > > > ssl-profile and set the certFile property?
> > > > > > > > > Is setting one of them enough? Or do we really need to set
> > > > > > > > > both?
> > > > > > > > > Regards,Adel
> > > > > > > > -----------------------------------------------------------
> > > > > > > > ----------
> > > > > > > > To unsubscribe, e-mail: [email protected]
> > > > > > > > For additional commands, e-mail: [email protected]
> > > > > > > >
> > > > > > >
> > > > > -----------------------------------------------------------------
> > > > > ----
> > > > > To unsubscribe, e-mail: [email protected]
> > > > > For additional commands, e-mail: [email protected]
> > > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
>
