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 <hbea...@gmail.com> 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) <j...@apache.org> > 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) <j...@apache.org> 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)
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 <hbea...@apache.org> 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) <j...@apache.org> > 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) > >
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) <j...@apache.org> 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) <j...@apache.org> 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) <j...@apache.org>
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: Project Management - New Jira Status Requests
I received no objections. Ticket https://issues.apache.org/jira/browse/INFRA-14501 is now open to add two new statuses and update the workflow. Ryan DurfeyM | 303-524-5099 CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com> From: Ryan Durfey <ryan_dur...@cable.comcast.com> Date: Wednesday, June 28, 2017 at 5:22 PM To: "dev@trafficcontrol.incubator.apache.org" <dev@trafficcontrol.incubator.apache.org> Subject: Project Management - New Jira Status Requests I want to request a couple of new workflow statuses in our Jira. Specifically I want to add “Intake” and “In Queue” which I think will add a lot of value to the organization of the project. If no one objects to this I will submit a ticket next week to get them added. Please let me know if you have any questions or other ideas. Intake >> Open >> In Queue >> In Progress >> Resolved >> Closed 1. Intake (default): issue created by community member and waiting on intake process by any knowledgeable community member * Intake process includes setting proper components, key word labels, reviewing description for adequacy, etc… 2. Open: Issue has been through intake process and is sitting in backlog waiting to be worked 3. In Queue: Issue has been assigned to a community member and they are indicating they intend to work in the near future 4. In-progress: Issue has been assigned and is being worked and is assigned to a release 5. Resolved: Initial code is done and is in testing 6. Closed: Test Complete Additional Documentation https://cwiki.apache.org/confluence/pages/editpage.action?pageId=70258743 Ryan Durfey Sr. Product Manager - CDN | Comcast Technology Solutions 1899 Wynkoop Ste. 550 | Denver, CO 8020 M | 303-524-5099 ryan_dur...@comcast.com<mailto:ryan_dur...@comcast.com> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>
Project Management - Jira Kanban
I created a handy new Kanban that shows all Traffic Control tickets that are open (ie not yet marked “Done”). Please let me know if I missed anything. https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=177 Notes * Quick Filters * Filter by Component (ex. Traffic Router) * Filter by Watched by you * Filter by Assigned to you * Filter by Type (bug, improvement, feature) * Status Change by Drag and Drop * Move to “Done” and it will be removed from the board. * Swimlanes by Assignee * Set your favorite filters and bookmark Ryan Durfey Sr. Product Manager - CDN | Comcast Technology Solutions 1899 Wynkoop Ste. 550 | Denver, CO 8020 M | 303-524-5099 ryan_dur...@comcast.com<mailto:ryan_dur...@comcast.com> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>
Re: [jira] [Commented] (TC-120) The zero size file can't be updated by Traffic Ops ORT
Hey Jifeng- I added you to the contributors list. —Eric > On Feb 6, 2017, at 3:05 AM, Jifeng Yang (JIRA) <j...@apache.org> wrote: > > >[ > https://issues.apache.org/jira/browse/TC-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853650#comment-15853650 > ] > > Jifeng Yang commented on TC-120: > > > There is no "Assign" button for me (There are buttons such as "Edit", > "Comment", "Agile Board", etc). > > Seems due to I'm not in the developer list. Could add me to the list or tell > me how to do that? > >> The zero size file can't be updated by Traffic Ops ORT >> -- >> >>Key: TC-120 >>URL: https://issues.apache.org/jira/browse/TC-120 >>Project: Traffic Control >> Issue Type: Bug >> Components: Traffic Ops ORT >> Affects Versions: 1.8.0 >> Reporter: Jifeng Yang >> >> The ORT doesn't update a file if the file is zero size. >> The configuration file may become zero size file by some reason (such as by >> accident). If a file is zero size, it can't be updated any more. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346)
Re: [jira] [Commented] (TC-28) API response structure should be hierarchical instead of flat
API 1.3!!!
On Fri, Nov 4, 2016 at 3:41 PM, Jeremy Mitchell <mitchell...@gmail.com>
wrote:
> what i should have done has rolled api/1.3
>
> on monday, i'll get api/1.2 back to where it's always been and move this
> new structure into api/1.3
>
> Jeremy
>
> On Fri, Nov 4, 2016 at 3:11 PM, ASF GitHub Bot (JIRA) <j...@apache.org>
> wrote:
>
> >
> > [ https://issues.apache.org/jira/browse/TC-28?page=com.
> > atlassian.jira.plugin.system.issuetabpanels:comment-
> > tabpanel=15637694#comment-15637694 ]
> >
> > ASF GitHub Bot commented on TC-28:
> > --
> >
> > Github user mitchell852 closed the pull request at:
> >
> > https://github.com/apache/incubator-trafficcontrol/pull/48
> >
> >
> > > API response structure should be hierarchical instead of flat
> > > -
> > >
> > > Key: TC-28
> > > URL: https://issues.apache.org/jira/browse/TC-28
> > > Project: Traffic Control
> > > Issue Type: Improvement
> > > Components: Traffic Ops API
> > >Affects Versions: 1.8.0
> > >Reporter: Jeremy Mitchell
> > >Priority: Minor
> > > Fix For: 1.8.0
> > >
> > >
> > > I created a handful of api endpoints in 1.8 with a flat response
> > structure like:
> > > {
> > > "response": [
> > > {
> > > "asn": "23",
> > > "cachegroupId": "69",
> > > "cachegroupName": "Foo_Cachegroup",
> > > "id": "60",
> > > "lastUpdated": "2016-10-13 12:31:43"
> > > }
> > > ]
> > > }
> > > Although this is fine, it makes it more difficult to test when using
> > structures derived from the database. This structure is more friendly.
> > > {
> > > "response": [
> > > {
> > > "asn": "23",
> > > "cachegroup": {
> > > "id": "69",
> > > "name": "Aberdeen_17802B_Ciscos"
> > > },
> > > "id": "60",
> > > "lastUpdated": "2016-10-13 12:31:43"
> > > }
> > > ]
> > > }
> > > This nested structure needs to be applied to api endpoints related to
> > asn, cachegroup, deliveryservice, phys_location, region, server and user.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.4#6332)
> >
>
Re: [jira] [Commented] (TC-28) API response structure should be hierarchical instead of flat
what i should have done has rolled api/1.3
on monday, i'll get api/1.2 back to where it's always been and move this
new structure into api/1.3
Jeremy
On Fri, Nov 4, 2016 at 3:11 PM, ASF GitHub Bot (JIRA) <j...@apache.org>
wrote:
>
> [ https://issues.apache.org/jira/browse/TC-28?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15637694#comment-15637694 ]
>
> ASF GitHub Bot commented on TC-28:
> --
>
> Github user mitchell852 closed the pull request at:
>
> https://github.com/apache/incubator-trafficcontrol/pull/48
>
>
> > API response structure should be hierarchical instead of flat
> > -
> >
> > Key: TC-28
> > URL: https://issues.apache.org/jira/browse/TC-28
> > Project: Traffic Control
> > Issue Type: Improvement
> > Components: Traffic Ops API
> >Affects Versions: 1.8.0
> >Reporter: Jeremy Mitchell
> >Priority: Minor
> > Fix For: 1.8.0
> >
> >
> > I created a handful of api endpoints in 1.8 with a flat response
> structure like:
> > {
> > "response": [
> > {
> > "asn": "23",
> > "cachegroupId": "69",
> > "cachegroupName": "Foo_Cachegroup",
> > "id": "60",
> > "lastUpdated": "2016-10-13 12:31:43"
> > }
> > ]
> > }
> > Although this is fine, it makes it more difficult to test when using
> structures derived from the database. This structure is more friendly.
> > {
> > "response": [
> > {
> > "asn": "23",
> > "cachegroup": {
> > "id": "69",
> > "name": "Aberdeen_17802B_Ciscos"
> > },
> > "id": "60",
> > "lastUpdated": "2016-10-13 12:31:43"
> > }
> > ]
> > }
> > This nested structure needs to be applied to api endpoints related to
> asn, cachegroup, deliveryservice, phys_location, region, server and user.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
