Re: [jira] [Created] (TC-187) Update delivery service makes SSL keys invalid
You are a committer too, Hank! ;) On Thu, Aug 10, 2017 at 1:26 PM, Hank Beatty wrote: > It looks like this one is ready to be merged. Can someone please take a > look at this PR https://github.com/apache/incu > bator-trafficcontrol/pull/360? > > Thanks, > Hank > > > > > Forwarded Message > Subject:[jira] [Created] (TC-187) Update delivery service makes > SSL keys invalid > Date: Tue, 14 Mar 2017 06:27:41 + (UTC) > From: Zhilin Huang (JIRA) > Reply-To: dev@trafficcontrol.incubator.apache.org > To: iss...@trafficcontrol.incubator.apache.org > > > > Zhilin Huang created TC-187: > --- > > Summary: Update delivery service makes SSL keys invalid > Key: TC-187 > URL: https://issues.apache.org/jira/browse/TC-187 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops > Reporter: Zhilin Huang > Assignee: Zhilin Huang > > > Modify xml-id or subdomain in a https delivery service will make existing > SSL keys invalid. > > And there is problem to generate keys if using "http and https" together > with 1 host_regex, and 1 path_regex. > > BTW, the certificate returned by RESTful API is not consistent with that > GUI. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > >
Fwd: [jira] [Created] (TC-187) Update delivery service makes SSL keys invalid
It looks like this one is ready to be merged. Can someone please take a look at this PR https://github.com/apache/incubator-trafficcontrol/pull/360? Thanks, Hank Forwarded Message Subject: [jira] [Created] (TC-187) Update delivery service makes SSL keys invalid Date: Tue, 14 Mar 2017 06:27:41 + (UTC) From: Zhilin Huang (JIRA) Reply-To: dev@trafficcontrol.incubator.apache.org To: iss...@trafficcontrol.incubator.apache.org Zhilin Huang created TC-187: --- Summary: Update delivery service makes SSL keys invalid Key: TC-187 URL: https://issues.apache.org/jira/browse/TC-187 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Reporter: Zhilin Huang Assignee: Zhilin Huang Modify xml-id or subdomain in a https delivery service will make existing SSL keys invalid. And there is problem to generate keys if using "http and https" together with 1 host_regex, and 1 path_regex. BTW, the certificate returned by RESTful API is not consistent with that GUI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
New Committer: Derek Gelinas
The Project Management Committee (PMC) for Apache Traffic Control has invited Derek Gelinas to become a committer and we are pleased to announce that he has accepted. Derek has made a lot of good contribution related to Traffic Ops and making ATS configuration better and more efficient. Derek has also been presenting at the ApacheCon summits. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Being a PMC member enables assistance with the management and to guide the direction of the project. Congrats Derek! Thanks, Steve
Re: [jira] [Created] (TC-151) Delivery Service XML IDs should be limited to lower-case letters
This looks like a feature request and not a bug. On Thu, Aug 10, 2017 at 8:20 AM, Hank Beatty wrote: > Does anyone know if this has been fixed? If not, are we planning in fixing > it for 2.1? > > Thanks, > Hank > > > > > Forwarded Message > Subject:[jira] [Created] (TC-151) Delivery Service XML IDs should > be limited to lower-case letters > Date: Thu, 16 Feb 2017 08:10:41 + (UTC) > From: Oren Shemesh (JIRA) > Reply-To: dev@trafficcontrol.incubator.apache.org > To: iss...@trafficcontrol.incubator.apache.org > > > > Oren Shemesh created TC-151: > --- > > Summary: Delivery Service XML IDs should be limited to > lower-case letters > Key: TC-151 > URL: https://issues.apache.org/jira/browse/TC-151 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops > Affects Versions: 1.7.0 > Reporter: Oren Shemesh > Priority: Minor > > > The DNS system is case-insensitive. Since a delivery service XML ID is > used as part of the FQDN of the cache being redirected to, two different > DSs cannot differ only by case. > This leads to the conclusion that it is best if we limit the XML IDs of > delivery services to be lower-case only. > This would achieve the following: > 1. Make domain names used by TC 'conventional' (i.e. lower-case only) > 2. Remove the possibility of a case-conflict between DSs > 3. Currently, Traffic Router does not behave correctly when a DS XML ID > contains upper case letters. Limiting to lower-case would prevent the need > to fix this :-) > > Current problems with TR behaviour, when an XML ID contains opper-case > letter are: > 1. The TR sends a redirect to a host FQDN which contains a lower-case > version of the DS XML ID > 2. The TR does not resolve the lower-case version of the host FQDN. > > Here is an example to demo current bug in TR. DS XML ID is > opencachehub-DT, TR redirects to opencachehub-dt, and then refused to > resolve the cache name using this DS (a lot of irrelevant data was removed > fro this text): > > > $ curl -L -s -D - http://tr.opencachehub-DT.stag > e-cdn.tc-stage.cqloud.com/video01.mp4 -v > * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > (54.244.152.242) port 80 (#0) > >> GET /video01.mp4 HTTP/1.1 >> Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com >> Accept: */* >> >> < HTTP/1.1 302 Moved Temporarily > < Location: http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage. > cqloud.com/video01.mp4 > < Content-Length: 0 > > < > * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > left intact > * Issue another request to this URL: 'http://p39-edge-lab.opencache > hub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4' > * getaddrinfo(3) failed for p39-edge-lab.opencachehub-dt.s > tage-cdn.tc-stage.cqloud.com:80 > * Couldn't resolve host 'p39-edge-lab.opencachehub-dt. > stage-cdn.tc-stage.cqloud.com' > > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > >
Re: [jira] [Updated] (TC-118) Traffic Ops should get it's name from some confioguration when generating CrConfig
To my knowledge it has not been fixed and will not be fixed for 2.1.
On Thu, Aug 10, 2017 at 8:09 AM, Hank Beatty wrote:
> Does anyone know if this has been fixed? If not, are we planning in fixing
> it for 2.1?
>
> Thanks,
> Hank
>
>
>
>
> Forwarded Message
> Subject:[jira] [Updated] (TC-118) Traffic Ops should get it's name
> from some confioguration when generating CrConfig
> Date: Wed, 14 Jun 2017 19:00:01 + (UTC)
> From: Ryan Durfey (JIRA)
> Reply-To: dev@trafficcontrol.incubator.apache.org
> To: iss...@trafficcontrol.incubator.apache.org
>
>
>
> [ https://issues.apache.org/jira/browse/TC-118?page=com.atlass
> ian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Ryan Durfey updated TC-118:
> ---
> Labels: configuration crconfig (was: )
>
> Traffic Ops should get it's name from some confioguration when generating
>> CrConfig
>>
>> --
>>
>> Key: TC-118
>> URL: https://issues.apache.org/jira/browse/TC-118
>> Project: Traffic Control
>> Issue Type: Bug
>> Components: Traffic Ops
>>Affects Versions: 1.7.0
>>Reporter: Oren Shemesh
>>Priority: Minor
>> Labels: configuration, crconfig
>>
>> The code that generates the CrConfig has a problem when creating the
>> "stat" section.
>> It fills values for that section, such as "tm_host", based on the HTTP
>> headers found in the request that triggered the CrConfig snapshot:
>> Here is a snippet from traffic_ops/app/lib/UI/Topology.pm:
>> $data_obj->{'stats'}->{'tm_path'}= $self->req->url->path->{'path'
>> };
>> $data_obj->{'stats'}->{'tm_host'}= $self->req->headers->host;
>> I find this to be a problem for two reasons:
>> This code assumes that it is being run from the context of an HTTP
>> transaction, which to me sounds like contaminating the logic of actually
>> creating the CrConfig with details from the upper layer which currently
>> uses this logic. For example, if one would want to run this code from a
>> different path (Maybe in a unit test), it would be a problem.
>> If the traffic ops is accessed through a NAT, then the host name known to
>> the HTTP client issuing the 'Snapshot CrConfig' request is not necessarily
>> the same as the traffic ops host name known to the other components of the
>> system, e.g. the traffic router that uses this information.
>> (This is how I found out about this problem - we are experimenting with
>> deploying TC in the cloud (Amazon EC2) and the host name visible to the
>> outside world is not the same as the host names used internally)
>> I believe that tm_host should come from the database (Currently there is
>> no entry from the traffic ops itself, but such an entry can be created for
>> this purpose), or from cdn.conf.
>>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>
>
Fwd: [jira] [Created] (TC-157) Failed to restart tomcat in Traffic Router when failed to get SSL keys
There is a PR (https://github.com/apache/incubator-trafficcontrol/pull/294) open for this one. Can someone review and merge and backport if acceptable? Thanks, Hank Forwarded Message Subject: [jira] [Created] (TC-157) Failed to restart tomcat in Traffic Router when failed to get SSL keys Date: Mon, 20 Feb 2017 08:37:44 + (UTC) From: Zhilin Huang (JIRA) Reply-To: dev@trafficcontrol.incubator.apache.org To: iss...@trafficcontrol.incubator.apache.org Zhilin Huang created TC-157: --- Summary: Failed to restart tomcat in Traffic Router when failed to get SSL keys Key: TC-157 URL: https://issues.apache.org/jira/browse/TC-157 Project: Traffic Control Issue Type: Bug Reporter: Zhilin Huang Assignee: Zhilin Huang Stopping tomcat failed with the following log: WARN 2017-02-17T09:00:05.939 [main] com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesPublisher - Detected destroy setting running to false INFO 2017-02-17T09:00:05.943 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesClient - Interrupted while pausing for check of traffic ops config INFO 2017-02-17T09:00:05.943 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: https://192.168.122.181/api/1.1/user/login; timeout is 15000 INFO 2017-02-17T09:00:06.005 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: https://192.168.122.181/api/1.2/cdns/name/kabletown_cdn/sslkeys.jso n; timeout is 15000 WARN 2017-02-17T09:00:06.040 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - Failed Http Request to https://192.168.122.181/api/1.2/cdns/name/kabletown_ cdn/sslkeys.json Status 400 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Fwd: [jira] [Created] (TC-151) Delivery Service XML IDs should be limited to lower-case letters
Does anyone know if this has been fixed? If not, are we planning in fixing it for 2.1? Thanks, Hank Forwarded Message Subject: [jira] [Created] (TC-151) Delivery Service XML IDs should be limited to lower-case letters Date: Thu, 16 Feb 2017 08:10:41 + (UTC) From: Oren Shemesh (JIRA) Reply-To: dev@trafficcontrol.incubator.apache.org To: iss...@trafficcontrol.incubator.apache.org Oren Shemesh created TC-151: --- Summary: Delivery Service XML IDs should be limited to lower-case letters Key: TC-151 URL: https://issues.apache.org/jira/browse/TC-151 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 1.7.0 Reporter: Oren Shemesh Priority: Minor The DNS system is case-insensitive. Since a delivery service XML ID is used as part of the FQDN of the cache being redirected to, two different DSs cannot differ only by case. This leads to the conclusion that it is best if we limit the XML IDs of delivery services to be lower-case only. This would achieve the following: 1. Make domain names used by TC 'conventional' (i.e. lower-case only) 2. Remove the possibility of a case-conflict between DSs 3. Currently, Traffic Router does not behave correctly when a DS XML ID contains upper case letters. Limiting to lower-case would prevent the need to fix this :-) Current problems with TR behaviour, when an XML ID contains opper-case letter are: 1. The TR sends a redirect to a host FQDN which contains a lower-case version of the DS XML ID 2. The TR does not resolve the lower-case version of the host FQDN. Here is an example to demo current bug in TR. DS XML ID is opencachehub-DT, TR redirects to opencachehub-dt, and then refused to resolve the cache name using this DS (a lot of irrelevant data was removed fro this text): $ curl -L -s -D - http://tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com/video01.mp4 -v * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com (54.244.152.242) port 80 (#0) GET /video01.mp4 HTTP/1.1 Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com Accept: */* < HTTP/1.1 302 Moved Temporarily < Location: http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4 < Content-Length: 0 < * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com left intact * Issue another request to this URL: 'http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4' * getaddrinfo(3) failed for p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com:80 * Couldn't resolve host 'p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Fwd: [jira] [Updated] (TC-118) Traffic Ops should get it's name from some confioguration when generating CrConfig
Does anyone know if this has been fixed? If not, are we planning in
fixing it for 2.1?
Thanks,
Hank
Forwarded Message
Subject: [jira] [Updated] (TC-118) Traffic Ops should get it's name
from some confioguration when generating CrConfig
Date: Wed, 14 Jun 2017 19:00:01 + (UTC)
From: Ryan Durfey (JIRA)
Reply-To: dev@trafficcontrol.incubator.apache.org
To: iss...@trafficcontrol.incubator.apache.org
[
https://issues.apache.org/jira/browse/TC-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Durfey updated TC-118:
---
Labels: configuration crconfig (was: )
Traffic Ops should get it's name from some confioguration when generating
CrConfig
--
Key: TC-118
URL: https://issues.apache.org/jira/browse/TC-118
Project: Traffic Control
Issue Type: Bug
Components: Traffic Ops
Affects Versions: 1.7.0
Reporter: Oren Shemesh
Priority: Minor
Labels: configuration, crconfig
The code that generates the CrConfig has a problem when creating the "stat"
section.
It fills values for that section, such as "tm_host", based on the HTTP headers
found in the request that triggered the CrConfig snapshot:
Here is a snippet from traffic_ops/app/lib/UI/Topology.pm:
$data_obj->{'stats'}->{'tm_path'}= $self->req->url->path->{'path'};
$data_obj->{'stats'}->{'tm_host'}= $self->req->headers->host;
I find this to be a problem for two reasons:
This code assumes that it is being run from the context of an HTTP transaction, which to me sounds like contaminating the logic of actually creating the CrConfig with details from the upper layer which currently uses this logic.
For example, if one would want to run this code from a different path (Maybe in a unit test), it would be a problem.
If the traffic ops is accessed through a NAT, then the host name known to the
HTTP client issuing the 'Snapshot CrConfig' request is not necessarily the same
as the traffic ops host name known to the other components of the system, e.g.
the traffic router that uses this information.
(This is how I found out about this problem - we are experimenting with
deploying TC in the cloud (Amazon EC2) and the host name visible to the outside
world is not the same as the host names used internally)
I believe that tm_host should come from the database (Currently there is no
entry from the traffic ops itself, but such an entry can be created for this
purpose), or from cdn.conf.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: New Committer - Rob Butts
Congratulations Rob! Sent from my iPhone > On Aug 10, 2017, at 6:59 AM, Dave Neuman wrote: > > Congratulations, Rob! > >> On Thu, Aug 10, 2017 at 5:26 AM, Eric Friedrich wrote: >> >> The Project Management Committee (PMC) for Apache Traffic Control >> (incubating) >> has invited Rob Butts to become a committer and we are pleased >> to announce that he has accepted. >> >> Rob began his Traffic Control contributions in November of 2015. Rob's >> contributions are wide ranging from Dockerization and build processes, to >> experimental Traffic Ops and most importantly the GoLang evolution of >> Traffic Monitor. Rob is active within the community, participating in >> mailing list threads and presenting at ApacheCon summits. >> >> Being a committer enables easier contribution to the >> project since there is no need to go via the patch >> submission process. This should enable better productivity. >> Being a PMC member enables assistance with the management >> and to guide the direction of the project. >>
Re: New Committer - Rob Butts
Congratulations, Rob! On Thu, Aug 10, 2017 at 5:26 AM, Eric Friedrich wrote: > The Project Management Committee (PMC) for Apache Traffic Control > (incubating) > has invited Rob Butts to become a committer and we are pleased > to announce that he has accepted. > > Rob began his Traffic Control contributions in November of 2015. Rob's > contributions are wide ranging from Dockerization and build processes, to > experimental Traffic Ops and most importantly the GoLang evolution of > Traffic Monitor. Rob is active within the community, participating in > mailing list threads and presenting at ApacheCon summits. > > Being a committer enables easier contribution to the > project since there is no need to go via the patch > submission process. This should enable better productivity. > Being a PMC member enables assistance with the management > and to guide the direction of the project. >
New Committer - Rob Butts
The Project Management Committee (PMC) for Apache Traffic Control (incubating) has invited Rob Butts to become a committer and we are pleased to announce that he has accepted. Rob began his Traffic Control contributions in November of 2015. Rob's contributions are wide ranging from Dockerization and build processes, to experimental Traffic Ops and most importantly the GoLang evolution of Traffic Monitor. Rob is active within the community, participating in mailing list threads and presenting at ApacheCon summits. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Being a PMC member enables assistance with the management and to guide the direction of the project.
