| Summary: | cluster-url should be checked for syntax errors | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Zdenek Kraus <zkraus> |
| Component: | qpid-cpp | Assignee: | messaging-bugs <messaging-bugs> |
| Status: | NEW --- | QA Contact: | MRG Quality Engineering <mrgqe-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 2.1 | CC: | astitcher, jross |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
To be picky - I don't think that all of these errors are syntax errors. And given the current URL syntax none of them are. To explain: The current URL syntax accepts the IPv6 literal form with only character qualifications in the square braces. So in order to check for the kind of thing you are suggesting it needs to do some semantic checking. (I am aware that the syntax could be changed to catch some of these errors, but I don't think it's worth making the syntax more complex for this). The very first incorrect address - "192.168.0.256" would be very difficult to disallow with only a syntax check, so only a semantic check check would seem sensible. It might well be a good idea to do some semantic checking before accepting the addresses too. This might relate to BZ 808396 which would be a similar sort of semantic check. Hi Andrew, maybe all of them are not a synrax errors, but they are wrong IPv6 address, so they should be prevented. (NOTE: I'm sure that any Finite Language can be generated by regular gramar, and since syntax check is described by Context Free Grammar thus they all can be syntax checked, but it can be unecessary diffucult.) All these bugzillas are related, I just wanted to let you know whole problem of --cluster-url. |
Description of problem: it is possible to provide syntax-wrong addresses to cluster url. Both address types should be checked IPv4 and IPv6. When user configuring broker, some mistype can occure, so syntax should be check in cluster-url supplied address, and broker should not be started if some mistake is discovered. User will rely on operational failover and because of small mistake in cluster-url, failover won't work as he expected. pass the syntax check -- FAIL 192.168.0.256 [:::1] -- mistyped "::" [fe80:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:1] -- too long address, nine groups [fe80:aaaa:1] -- too short, and does not contain "::" [fe80::aaaa::1] -- contains two "::" [:aaaa::1], [fe80::aaaa:] -- leadin/ending ":" rejected by syntax check -- correct [fe80:123g::1] -- contains "g" notice that IPv6 with decimal ipv4 address has to be accepted as good [0:0:0:0:0:0:192.168.1.1] [0:0:0:0:0:ffff:192.168.1.1] [::192.168.1.1] [::ffff:192.168.1.1] Version-Release number of selected component (if applicable): qpid-cpp-server-0.14-10.el6.x86_64 qpid-cpp-server-ssl-0.14-10.el6.x86_64 qpid-cpp-server-xml-0.14-10.el6.x86_64 qpid-cpp-server-store-0.14-10.el6.x86_64 qpid-cpp-server-devel-0.14-10.el6.x86_64 qpid-cpp-server-cluster-0.14-10.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. set up cluster-name and cluster-url to some localhost address in /etc/qpidd.conf cluster-name=mycluster cluster-url=amqp:tcp:192.168.0.256 # select address from list above 2. start openais/corosync for clustering and broker 3. run qpid-cluster and observe that address are provided as URL Actual results: Cluster Name: mycluster Cluster Status: ACTIVE Cluster Size: 1 Members: ID=126.39.0.0:5602 URL=amqp:tcp:192.168.0.256:5672 Expected results: qpidd fails with error message like: "Syntax error in cluster-url" or prints warning, and will not provide such address to clients if there is some other correct addresss (Note that second result is subject of disscution) Additional info: