You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Arno Toell (JIRA)" <ji...@apache.org> on 2011/05/09 01:55:03 UTC

[jira] [Created] (TS-767) Make the cluster port configurable

Make the cluster port configurable
----------------------------------

                 Key: TS-767
                 URL: https://issues.apache.org/jira/browse/TS-767
             Project: Traffic Server
          Issue Type: Improvement
          Components: Configuration, Network
    Affects Versions: 2.1.8
            Reporter: Arno Toell
            Priority: Minor


I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 

* Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.
* Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.
* Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
* The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-767) Make the cluster interface configurable

Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-767:
-----------------------------

    Fix Version/s:     (was: 3.1.1)
                   3.1.2

Moving these to 3.1.2 for now. please move back if they will be worked on asap for 3.1.1.
                
> Make the cluster interface configurable
> ---------------------------------------
>
>                 Key: TS-767
>                 URL: https://issues.apache.org/jira/browse/TS-767
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration, Network
>    Affects Versions: 2.1.8
>            Reporter: Arno Toell
>            Priority: Minor
>             Fix For: 3.1.2
>
>
> I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 
> * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.-
> * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.-
> * Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
> * -The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.-
> n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765:
> 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (TS-767) Make the cluster interface configurable

Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-767:
-----------------------------

    Fix Version/s:     (was: 3.1.5)
                   3.3.0

Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please!
                
> Make the cluster interface configurable
> ---------------------------------------
>
>                 Key: TS-767
>                 URL: https://issues.apache.org/jira/browse/TS-767
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration, Network
>    Affects Versions: 2.1.8
>            Reporter: Arno Toell
>            Priority: Minor
>             Fix For: 3.3.0
>
>
> I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 
> * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.-
> * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.-
> * Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
> * -The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.-
> n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765:
> 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (TS-767) Make the cluster interface configurable

Posted by "Leif Hedstrom (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193463#comment-13193463 ] 

Leif Hedstrom commented on TS-767:
----------------------------------

We should look into this in relation to the changes being made for TS-1077.
                
> Make the cluster interface configurable
> ---------------------------------------
>
>                 Key: TS-767
>                 URL: https://issues.apache.org/jira/browse/TS-767
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration, Network
>    Affects Versions: 2.1.8
>            Reporter: Arno Toell
>            Priority: Minor
>             Fix For: 3.1.3
>
>
> I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 
> * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.-
> * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.-
> * Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
> * -The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.-
> n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765:
> 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (TS-767) Make the cluster port configurable

Posted by "Arno Toell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arno Toell updated TS-767:
--------------------------

    Description: 
I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 

* -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.-
* -Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.-
* Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
* -The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.-

n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765:

8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers.

  was:
I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 

* Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.
* Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.
* Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
* The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar. 


> Make the cluster port configurable
> ----------------------------------
>
>                 Key: TS-767
>                 URL: https://issues.apache.org/jira/browse/TS-767
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration, Network
>    Affects Versions: 2.1.8
>            Reporter: Arno Toell
>            Priority: Minor
>
> I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 
> * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.-
> * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.-
> * Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
> * -The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.-
> n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765:
> 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-767) Make the cluster interface configurable

Posted by "Arno Toell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arno Toell updated TS-767:
--------------------------

    Summary: Make the cluster interface configurable  (was: Make the cluster port configurable)

> Make the cluster interface configurable
> ---------------------------------------
>
>                 Key: TS-767
>                 URL: https://issues.apache.org/jira/browse/TS-767
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration, Network
>    Affects Versions: 2.1.8
>            Reporter: Arno Toell
>            Priority: Minor
>
> I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 
> * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.-
> * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.-
> * Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
> * -The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.-
> n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765:
> 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-767) Make the cluster interface configurable

Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leif Hedstrom updated TS-767:
-----------------------------

    Fix Version/s: 3.1

> Make the cluster interface configurable
> ---------------------------------------
>
>                 Key: TS-767
>                 URL: https://issues.apache.org/jira/browse/TS-767
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Configuration, Network
>    Affects Versions: 2.1.8
>            Reporter: Arno Toell
>            Priority: Minor
>             Fix For: 3.1
>
>
> I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest 
> * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.-
> * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.-
> * Disable the "reliable service port" (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the "autoconfiguration port". If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. 
> * -The "internal communication port" (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.-
> n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765:
> 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira