Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC6

[Steve Malenfant]

+1 based on the ORT changes.

On Fri, May 11, 2018 at 2:22 PM, Robert Butts  wrote:

> Hello All,
>
> I've prepared a release for v2.2.0-RC6
>
> The vote is open for at least 72 hours and passes if a majority of at least
> 3 +1 PPMC votes are cast.
>
> [ ] +1 Approve the release
>
> [ ] -1 Do not release this package because ...
>
> Changes since 2.1.0:
> https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-2.1.0...RELEASE-2.2.0-RC6
>
> This corresponds to git:
>  Hash: 8f4d1ee2aa25000a9d0e17bbf85286c4a7264eab
>  Tag: RELEASE-2.2.0-RC6
>
> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC6
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), md5 and sha1 checksums are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC6
>
>
>
> Thanks!
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC5

[Steve Malenfant]

-1

ORT has backward compatibility issues with previous 2.2 versions.

On Wed, May 9, 2018 at 10:12 AM, David Neuman 
wrote:

> +1
> Checked hashes
> Ran `pkg` to build the RPMs
> Installed Traffic Ops
> Ran postinstall
>
> On Tue, May 1, 2018 at 1:13 PM, Robert Butts  wrote:
>
> > Hello All,
> >
> > I've prepared a release for v2.2.0-RC5
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> least
> > 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.1.0:
> > https://github.com/apache/incubator-trafficcontrol/
> > compare/RELEASE-2.1.0...RELEASE-2.2.0-RC5
> >
> > This corresponds to git:
> >  Hash: 3dec97f5577514e8ea21c26959562afdb0297245
> >  Tag: RELEASE-2.2.0-RC5
> >
> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC5
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), md5 and sha1 checksums are provided here:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC5
> >
> >
> > Thanks!
> >
>

Re: TO jobs_* Table Cleanup

[Steve Malenfant]

We haven't touched those tables @Cox. We use the built-in content
invalidation.

On Tue, May 1, 2018 at 6:05 PM, Hongfei Zhang (hongfezh)  wrote:

> @Dew - we did not touch job_result table. Thanks, -Hongfei
>
> On 5/1/18, 5:03 PM, "Dewayne Richardson"  wrote:
>
> @Hongfei
>
> What about the "job_result" table?  It doesn't seem to be used at all.
>
> - Dew
>
> On Tue, May 1, 2018 at 2:47 PM, Hongfei Zhang (hongfezh) <
> hongf...@cisco.com
> > wrote:
>
> > Hi Dew/Jan,
> >
> > We made some minor changes in content invalidation which were using
> > Job/Status - specifically we:
> > 1. added back CANCELLED job_status and added a Cancel subroutine  in
> > API/Job.pm
> > 2. Exposed the cancel function via API endpoint DELETE
> > /api/$version/jobs/:id  - which calls above cancel()
> >
> >
> > Thanks,
> > -Hongfei
> >
> > On 5/1/18, 4:27 PM, "Jan van Doorn"  wrote:
> >
> > I think they should be nuked.
> >
> > Rgds,
> > JvD
> >
> > > On May 1, 2018, at 2:04 PM, Dewayne Richardson <
> dewr...@apache.org>
> > wrote:
> > >
> > > I'm beginning to evaluate the Perl cleanup effort and noticed
> that
> > the
> > > *job_agent*, *job_status*, and *job_result* are minimally used
> > (except for
> > > the "job" table which has the list of Purge Jobs").  I wanted
> to get
> > a feel
> > > for the usage outside of Comcast and what the sentiment is to
> those
> > tables
> > > (or not).
> > >
> > >
> > >
> > > -Dew
> >
> >
> >
> >
>
>
>

Re: TLS Client Authentication in Traffic Control

[Steve Malenfant]

Eric,

Maybe I'm wrong here, but in the new API to generate config files, you can
have a single line separated with __RETURN__ instead of having to provision
a bunch line entries.

Steve

On Mon, Apr 30, 2018 at 2:49 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Someone else may find this useful, so I thought I would share. (Apologies
> for the earlier cross-post)
>
>
> Configuring TLS Client Authentication in Traffic Control (Experimental
> Testing Procedure)
> =
> Note: Trafficserver does not currently allow per-Delivery Service
> (per-remap) configuration of client authentication. The below instructions
> will enable client authentication for all HTTPS services on a given
> profile/cache.
>
> 1) In TrafficOps, configure the Edge cache “Profile” to turn on client
> authentication. Set the following parameters:
>   - name: CONFIG proxy.config.ssl.client.certification_level
>   - file: records.config
>   - value: INT 2
> Screenshot: https://cisco.box.com/s/lxtlfbfrbpnaa17cnp4dddj2p0wwzril
>
>   - name: CONFIG proxy.config.ssl.CA.cert.filename
>   - file: records.config
>   - value: STRING etc/trafficserver/ssl/ca.crt
> Screenshot: https://cisco.box.com/s/hq7vubwd9z0k1g8705eaagbvdg0aokjc
> See below for instructions on generating the Certificate Authority (CA),
> Certificate and private key.
>
>
>   You can add the CA file via TrafficOps, but its a painful process.
> Please see the screenshot. If you wish to skip this step, you can scp the
> file directly to the cache (/opt/trafficserver/etc/
> trafficserver/ssl/client_ca.crt)
>   Screenshot: https://cisco.box.com/s/849imlapxj1e30zi6y63a8fwd31swv21
>  (Now that I know what a take and bake is, I think I was better off
> before. Configuring a whole SSL Cert in here is pretty painful, but thanks
> to Jeff for the help on this step)
>
>
> 2) Queue and run ORT On caches to get updated settings
>
> 3) Verify by making a curl request
> $ curl -k --cert ~/client_auth/client.crt --key
> ~/client_auth/client.key -v  https://edge-cache-1.cdn.cisco.com/test.m3u8
>
> On success, you will receive the content.
>
> On failure, you will see something like:
> [cloud-user trafficserver]$ curl -k -v  https://edge-cache-1.cdn.
> cisco.com/test.m3u8
> * About to connect() to localhost port 443 (#0)
> *   Trying ::1...
> * Connected to localhost (::1) port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> * skipping SSL peer certificate verification
> * NSS: client certificate not found (nickname not specified)
> * NSS error -12227 (SSL_ERROR_HANDSHAKE_FAILURE_ALERT)
> * SSL peer was unable to negotiate an acceptable set of security
> parameters.
> * Closing connection 0
> curl: (35) NSS: client certificate not found (nickname not specified)
>
>
> Generating a Certificate Authority and Client Certificate (optional)
> =
> 1) Create the Certificate Authority Key
> $ openssl genrsa -out client_ca.key 2048
>
> 2) Generate the Certificate Authority Cert
> $ openssl req -new -x509 -key ./client_ca.key -out client_ca.crt
>
> 2) Generate the Client Key and Certificate Signing Request
> $ openssl req -newkey rsa:2048 -nodes -keyout client.key -out
> client.csr
>
> 3) Use the Certificate Authority to sign the client certificate signing
> request
>$ openssl x509 -req -in ./client.csr -CA ./client_ca.crt -CAkey
> ./client_ca.key -CAcreateserial -out client.crt
>
> 4) The  client_ca.crt file is copied to the Trafficserver. The client
> (curl) is given client.crt and client.key
>

Re: [VOTE] Traffic Control graduation to TLP

[Steve Malenfant]

+1

On Thu, Mar 1, 2018 at 12:14 PM, Phil Sorber  wrote:

> +1
>
> On Thu, Mar 1, 2018 at 1:12 PM Hank Beatty  wrote:
>
> > +1
> >
> > On 03/01/2018 10:41 AM, Dave Neuman wrote:
> > >   Hey All,
> > >
> > > After a great discussion amongst the Apache Traffic Control PPMC,
> > reviewing
> > > the graduation checklist[1], updating the podling status page[2], and
> > > updating the project website to ensure the whimsy podling website
> checks
> > > pass[3], I would like to call a vote for Apache Traffic Control
> > graduating
> > > to a top level project.
> > >
> > > Apache Traffic Control entered the incubator on July 12, 2016.  Since
> > then
> > > we have announced 4 releases, nominated 4 new committers, organized 3
> > > summits, had almost 8,000 commits from 63 different contributors, and
> --
> > > most importantly -- we have grown and diversified our community.
> Apache
> > > Traffic Control is a healthy project that is already acting like an
> > Apache
> > > top level project, so we should take the next step.
> > >
> > > If we agree that we should graduate to a top level project, the next
> > steps
> > > will be to pick the initial PMC chair for the TLP and draft a
> Resolution
> > > for the PPMC and IPMC to vote upon.
> > >
> > > Please take a minute to vote on wheter or not Traffic Control should
> > > graduate to a Top Level Project by responding with one of the
> following:
> > >
> > > [ ] +1 Apache Traffic Control should graduate.
> > > [ ] +0 No opinion
> > > [ ] -1 Apache Traffic Control should not graduate (please provide the
> > > reason)
> > >
> > > The VOTE will be opened for at least the next 72 hours.  Per Apache
> > > guidelines[4] I will also be notifying the incubator mailing list that
> a
> > > community vote is under way.
> > >
> > > Thanks,
> > > Dave
> > >
> > >
> > > [1]
> > >
> > https://incubator.apache.org/guides/graduation.html#
> graduation_check_list
> > > [2] http://incubator.apache.org/projects/trafficcontrol.html
> > > [3] https://whimsy.apache.org/pods/project/trafficcontrol
> > > [4]
> > >
> > https://incubator.apache.org/guides/graduation.html#
> community_graduation_vote
> > >
> >
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC1

[Steve Malenfant]

Maybe I should have mentioned a few more details...

As for Traffic Ops/Portal, this upgrade was from earlier 2.2 build (early
December).
As for Monitor/Router/Stats, that was actually a 2.1 -> 2.2 upgrade.

Steve

On Wed, Feb 21, 2018 at 5:24 PM, Dave Neuman <neu...@apache.org> wrote:

> Hi Steve, for the upgrade did you go from 2.1 -> 2.2?
>
> On Wed, Feb 21, 2018 at 10:15 AM, Steve Malenfant <smalenf...@gmail.com>
> wrote:
>
> > +1
> >
> > Upgraded the following succesfully to RC1:
> > Traffic Ops
> > Traffic Portal
> > Traffic Monitor (from java to golang)
> > Traffic Router
> > Traffic Stats
> >
> > I only opened a single issue related with some required parameter for
> > Traffic Monitor. But if used according to the default RASCAL profiles, no
> > problem. Logs are specific. Issue is #1902.
> >
> > Steve
> >
> > On Wed, Feb 14, 2018 at 4:01 PM, Robert Butts <r...@apache.org> wrote:
> >
> > > Hello All,
> > >
> > > I've prepared a release for v2.2.0-RC1
> > >
> > > The vote is open for at least 72 hours and passes if a majority of at
> > least
> > > 3 +1 PPMC votes are cast.
> > >
> > > [ ] +1 Approve the release
> > >
> > > [ ] -1 Do not release this package because ...
> > >
> > > Changes since 2.1.0:
> > > https://github.com/apache/incubator-trafficcontrol/
> > > compare/RELEASE-2.1.0...RELEASE-2.2.0-RC1
> > >
> > > This corresponds to git:
> > >  Hash: ea549797d98c4fe96e484c9e88f82e2d7f876c1e
> > >  Tag: RELEASE-2.2.0-RC1
> > >
> > > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC1
> > >
> > > My code signing key is available here:
> > > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
> > >
> > > Make sure you refresh from a key server to get all relevant signatures.
> > >
> > > The source .tar.gz file, pgp signature (.asc signed with my key from
> > > above), md5 and sha1 checksums are provided here:
> > >
> > > https://dist.apache.org/repos/dist/dev/incubator/
> > trafficcontrol/2.2.0/RC1
> > >
> > >
> > > Thanks!
> > >
> >
>

Re: Connection leaks traffic stats -> influxdb

[Steve Malenfant]

Nir,

We have observed this in the past as well. We are still running
traffic_stats 2.1.0 and using this cronjob as workaround for now.

$ cat /etc/cron.d/traffic_stats_restart

#Ansible: Restart Traffic Stats

0 8 * * * root /etc/init.d/traffic_stats restart >/dev/null 2>&1

Steve

On Mon, Feb 12, 2018 at 9:50 AM, Dave Neuman  wrote:

> hmm, ok.  Can you try running that master version of Traffic Stats and let
> me know if you still see the same issue?
>
>
> On Mon, Feb 12, 2018 at 7:29 AM, Nir Sopher  wrote:
>
> > Thanks Dave,
> > I'm working with traffic stats 2.1.0 and influx 1.2.2. Tried also with
> > influx 1.4.3 and found the same issues.
> > OS: Centos 7.4-1708
> > Nir
> >
> > On Mon, Feb 12, 2018 at 2:00 AM, Dave Neuman  wrote:
> >
> > > Hi Nir,
> > > I have not seen this issue and I do have some setups with Traffic Stats
> > and
> > > InfluxDB on the same server.
> > > A couple of questions:
> > >   - What version of Traffic Stats are you running?
> > >   - What version of InfluxDB are you running?
> > >   - What version of OS are you running?
> > >
> > > Thanks,
> > > Dave
> > >
> > >
> > > On Sun, Feb 11, 2018 at 12:52 PM, Nir Sopher  wrote:
> > >
> > > > Hi,
> > > >
> > > > On my setup, traffic-stats is installed on the same server as the
> > > influxdb
> > > > server.
> > > > We have noticed that the number of open sockets, from stats to
> influx,
> > is
> > > > constantly increasing,
> > > > All connections are at state "ESTABLISHED".
> > > >
> > > > Did anyone encounter a similar issue?
> > > > I'm familiar with https://issues.apache.org/jira/browse/TC-373 but
> > > believe
> > > > it is a different case.
> > > >
> > > > Thanks,
> > > > Nir
> > > >
> > >
> >
>

[VOTE] CHANGELOG.md file (second try)

[Steve Malenfant]

Hey All,

There has been a vote on not maintaining a CHANGELOG file in the past and
seems like we leaned toward an automated process. I believe none of them
had happened (please correct me if not).

I have been upgrading Traffic Control from 2.1 to 2.2 this week and found
numerous gotchas.

Some examples of things I ran into and luckily I was able to get good
support from the Slack channels. Here is a few example of possible breaking
changes :

- Delivery Service prefixes disappeared after upgrade, was not handled in
postinstall (requires special attention, this was on this forum and well
documented on the mailing list)
- Traffic Ops Golang doesn't connect to a Riak with self-signed certificates
- Riak security grant needs updated
- cdn.conf configuration change
- Traffic Portal required for new features (URI Signing)
- cachekey plugin instead of cacheurl

There was great enhancements made in 2.2 needs to be noticed by current and
new users.  If we are looking to get more engagement, that's probably the
#1 thing to do. I usually go and read about all the other components which
we use around the Traffic Control CDN (Influx, Elastic, Grafana, etc...)

So let me re-quote what Dave has sent and ask the same question again.

==
Hey All,
One thing we discussed at the meetup was the addition of a CHANGELOG.md
file to the project.   This file will contain changes that are made to the
project including bug fixes and new features. (e.g.
https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md).  Adding
this file means that we will now require each PR to contain an update to
the CHANGELOG.md file, and our documentation will need to be updated
accordingly.
I thought it would be good to open a vote for adding this file, and if it
passes, I will update the documentation and add a CHANGELOG.md file.

Thanks,
Dave
==

I'm a +1 on CHANGELOG, but I'm not heavy creating PRs which kind influence
my vote.

Steve

Re: Courtesy notice: per-Delivery-Service Routing Names

[Steve Malenfant]

Rawlin,

All my "edge." are gone after an upgrade. Is there a different parameter to
used for the DNS delivery services migration?

Thanks,

Steve

On Fri, Sep 15, 2017 at 5:19 PM, Rawlin Peters 
wrote:

> Hey folks,
>
> A new feature for Delivery Services has been merged into master
> recently - per-Delivery-Service Routing Names [1] - and will end up in
> release 2.2. Just so you're not surprised next time you upgrade your
> environments, you will now see a "Routing Name" field when creating or
> editing a Delivery Service. This field fulfills the role of the "edge"
> and "tr" names (e.g. http://tr.deliveryservice.cdn-domain.com) that
> have been traditionally used for DNS and HTTP Delivery Services,
> respectively, except now there is no longer that distinction. A
> Delivery Service's routing name can now be any valid hostname without
> periods, and if left unspecified the routing name defaults to 'cdn'
> (e.g. http://cdn.deliveryservice.cdn-domain.com).
>
> Changing the routing name of a Delivery Service after it's been
> deployed is not recommended, however, because it changes the Delivery
> URL and will require all clients of the Delivery Service to transition
> to the new URL (as well as possibly invalidating SSL certs among other
> things). Right now it's an editable field, but if it causes a lot of
> problems we may find it better to lock that field down and make it
> read-only after creation.
>
> I will put this in the release notes for 2.2 as well, but if you are
> using an `http.routing.name` other than "tr" (i.e. your HTTP Delivery
> Services use a URL that does not match this regex: |https?://tr\..*|),
> then you will have to create one or more temporary upgrade parameters
> before performing your next upgrade. This is possible by changing the
> Traffic Router config file named `http.properties` to add an
> `http.routing.name=foo` line, which would make your HTTP Delivery
> Services URLs look like "http://foo.deliveryservice.cdn-domain.com;.
>
> If you have changed `http.routing.name` for your CDNs to something
> other than "tr" like I've described, then you have to perform the
> following steps *before* upgrading to the latest version of Traffic
> Ops:
>
> 1. In Traffic Ops, create the following parameter (double-check for typos):
> name: upgrade_http_routing_name
> config file: temp
> value: 
> 2. Add this parameter to a *single* profile in each CDN that uses that
> `http.routing.name`
> 3. Repeat steps 1 and 2 for each unique `http.routing.name` in use
>
> After these parameters have been properly created, the Traffic Ops 2.2
> upgrade may be done, and the Routing Name fields for pre-existing
> Delivery Services will be populated with the proper values. Note:
> these parameters can safely be created at any time before upgrading to
> Traffic Ops 2.2 and can be removed safely after a successful upgrade
> has been completed.
>
> If you have any questions or concerns regarding this new feature,
> please let me know.
>
> - Rawlin
>
> P.S. if you have any external tooling that relies on the stale
> assumption that HTTP Delivery Service URLs start with "tr" and DNS
> Delivery Service URLs start with "edge", now may be the best time to
> think about updating that tooling.
>
> [1] https://github.com/apache/incubator-trafficcontrol/pull/865
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2

[Steve Malenfant]

+1 here as well.

On Tue, Nov 14, 2017 at 4:09 PM, Dave Neuman  wrote:

> Hey Hank,
> It looks like you have the votes you need to pass, but can you leave it
> open a little longer for those of us that haven't gotten a chance to test
> yet?
>
> Thanks,
> Dave
>
> On Tue, Nov 14, 2017 at 12:47 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > I’m +1 as well
> >
> > Checked out:
> > - signatures/checksums (Hank is your key signed yet?)
> > - licenses
> > - build
> >
> > —Eric
> >
> >
> > > On Nov 14, 2017, at 2:36 PM, Nir Sopher  wrote:
> > >
> > > +1
> > > We were able to build traffic-control, install and connect OPs,
> > Portal-V2,
> > > Monitor (Golang), Router and Stats.
> > > Also got a redirect.
> > > Note that I missed the last commit ("Change cdn.name to
> cdn.domain_name
> > in
> > > DeliveryServiceInfoForDomainList"), but as far as I see it could not
> > break
> > > the installation.
> > > Nir
> > >
> > > On Tue, Nov 14, 2017 at 8:10 PM, Eric Friedrich (efriedri) <
> > > efrie...@cisco.com> wrote:
> > >
> > >> Thanks Matt-
> > >>  I found another LEGAL ticket (https://issues.apache.org/
> > >> jira/browse/LEGAL-330) based on a Google version of the PATENTS file
> > this
> > >> time.
> > >>
> > >> Looks like things are OK to use then.
> > >>
> > >> —Eric
> > >>
> > >> On Nov 14, 2017, at 12:50 PM, Mills, Matthew <
> matthew_mi...@comcast.com
> > <
> > >> mailto:matthew_mi...@comcast.com>> wrote:
> > >>
> > >> FYI, Go itself has the same file
> > >>
> > >> https://github.com/golang/go/blob/master/PATENTS
> > >>
> > >>
> > >> On 11/14/17, 10:36:43 AM, "Eric Friedrich (efriedri)" <
> > efrie...@cisco.com>
> > >> wrote:
> > >>
> > >>   I’ve been going through licensing for the 2.1 release and found this
> > >> file:
> > >>   ./traffic_stats/vendor/golang.org/x/net/PATENTS > >> golang.org/x/net/PATENTS>
> > >>
> > >>   This looks like it places some of the same restrictions that caused
> > the
> > >> whole Facebook React.js and rocksDb controversy a few months ago.
> > >>   Fun reading here: https://issues.apache.org/jira/browse/LEGAL-303
> > >>   There’s some in depth discussion of the detailed Facebook license, I
> > >> can’t even begin to speculate how that compares to this Google
> > conditional
> > >> patent grant.
> > >>
> > >>   We can see what the IPMC/Legal thinks or maybe just remove the code?
> > >>
> > >>   —Eric
> > >>
> > >>
> > >>
> > >>
> > >>
> >
> >
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC1

[Steve Malenfant]

Is there any Release Notes associated with this release? 1,337 changes and
the link above will only display 250 of them.

Steve

On Mon, Oct 23, 2017 at 4:01 PM, Hank Beatty  wrote:

> Hello All,
>
> I've prepared a release for v2.1.0-RC1
>
> The vote is open for at least 72 hours and passes if a majority of at
> least 3 +1 PPMC votes are cast.
>
> [ ] +1 Approve the release
>
> [ ] -1 Do not release this package because ...
>
> Changes since 2.0.0:
> https://github.com/apache/incubator-trafficcontrol/compare/
> 2.0.x...RELEASE-2.1.0-RC1
>
> This corresponds to git:
>  Hash:6ea2ca86d07c16a3b3ca419dd56b975059271206 <(505)%20927-1206>
>  Tag: RELEASE-2.1.0-RC1
>
> Which can be verified with the following: git tag -v RELEASE-2.1.0-RC1
>
> My code signing key is available here:
> https://pgp.mit.edu/pks/lookup?op=get=0x582D3F6E79270895
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.1.0/RC1
>
> Thanks!
>
>

Re: Building Traffic-Router - Failed to bring jdnssec-tools

[Steve Malenfant]

Nir,

Try to add "network_mode: bridge" under your services inside of the
docker-compose file. I know I had to do this to build under Linux, but
works fine under OSX Docker Engine.

We do have the problem here since we don't allow docker to manage iptables.
This problem is limited to docker-compose as it will create a new network.

https://docs.docker.com/compose/compose-file/#network_mode

Example :
  traffic_router_build:
image: traffic_router_builder
build:
  dockerfile: infrastructure/docker/build/Dockerfile-traffic_router
  context: ../../..
volumes:
  - ../../..:/trafficcontrol
network_mode: bridge

Let me know if that works for you.

Steve

On Thu, Oct 5, 2017 at 5:55 PM, Nir Sopher  wrote:

> Hi Rawlin and thank you very much for your help!
> The link to http://www.verisignlabs.com/jdnssec-tools/packages/
> old-releases/jdnssec-tools-0.12.tar.gz is not available from our
> environment (in Israel).
> Curl first tries IPv4 and when failed, fallback to IPv6... (see output
> below).
> Pinging verisignlabs.com
>  releases/jdnssec-tools-0.12.tar.gz>
> also
> fails. It is trying to approach an IPv4 address, but fails to connect to it
> - as if I'm blocked by a firewall.
>
> I'll discuss our IT team about method to resolve the issue, possibly trying
> to connect verisignlabs (are there any contact information in their
> website?).
> 10x,
> Nir
>
> curl -vvv
> http://www.verisignlabs.com/jdnssec-tools/packages/old-
> releases/jdnssec-tools-0.12.tar.gz
> * About to connect() to www.verisignlabs.com port 80 (#0)
> *   Trying 72.13.58.64... Connection timed out
> *   Trying 2620:74:13:4400::201... Failed to connect to
> 2620:74:13:4400::201: Network is unreachable
> * Success
> * couldn't connect to host
> * Closing connection #0
> curl: (7) Failed to connect to 2620:74:13:4400::201: Network is unreachable
>
>
> On Thu, Oct 5, 2017 at 11:49 PM, Rawlin Peters 
> wrote:
>
> > Hey Nir,
> >
> > Are you still having build issues?
> >
> > I found an interesting tidbit from `curl --manual` using Curl version
> > 7.29.0 (x86_64-redhat-linux-gnu) inside a centos:7 Docker container
> > (what the build uses):
> >
> > IPv6
> >
> >   curl will connect to a server with IPv6 when a host lookup returns an
> > IPv6
> >   address and fall back to IPv4 if the connection fails. The --ipv4 and
> > --ipv6
> >   options can specify which address to use when both are available.
> >
> > So assuming curl would've fallen back to an IPv4 address if it was
> > able to get an A record, I think we can assume that in this case your
> > local resolver did not get an A record when it resolved that hostname
> > or your build environment is ipv6-only. Is it possible that happened
> > in your environment, Nir?
> >
> > To fix builds in IPv6-only environments, I think we'd have to
> > configure the docker network to enable ipv6. This doesn't appear
> > possible using docker-compose format version 2 (what the build
> > currently uses), but maybe in format version 2.1 [1]. However,
> > enabling IPv6 might then require an IPv6-enabled host, and IPv6
> > doesn't appear to be supported on at least Docker For Mac [2]. On
> > operating systems that support it, maybe you'd just have to configure
> > the Docker daemon for IPv6 and update the docker-compose.yml file to
> > enable it for the build.
> >
> > - Rawlin
> >
> > [1] https://docs.docker.com/compose/compose-file/compose-
> file-v2/#network-
> > configuration-reference
> > [2] https://docs.docker.com/docker-for-mac/troubleshoot/#known-issues
> >
> > On Tue, Oct 3, 2017 at 10:06 PM, Mark Torluemke 
> > wrote:
> > > I think we should be resilient and try both address families...curl
> might
> > > even do this 'for free' if we enable retries.
> > >
> > > On Tue, Oct 3, 2017 at 3:21 PM, Rawlin Peters  >
> > > wrote:
> > >
> > >> It's possible that Docker isn't playing nicely with IPv6 in your build
> > >> environment. The RPM build script is curling
> > >> http://www.verisignlabs.com/jdnssec-tools/packages/old-
> > >> releases/jdnssec-tools-0.12.tar.gz,
> > >> and in your case is using the  record for some reason. My guess is
> > >> that the container doing the build probably only routes IPv4 by
> > >> default in some environments. Checking in my build environment, none
> > >> of the Docker networks have IPv6 enabled.
> > >>
> > >> Should we pass `-4` to the curl command here [1] to force it to
> > >> resolve to IPv4 addresses only?
> > >>
> > >> - Rawlin
> > >>
> > >> [1] https://github.com/apache/incubator-trafficcontrol/blob/
> > >> master/traffic_router/build/build_rpm.sh#L41
> > >>
> > >> On Tue, Oct 3, 2017 at 3:02 PM, Nir Sopher  wrote:
> > >> > I now see that "./pkg traffic_portal_build" fails as well. This time
> > with
> > >> > no log.
> > >> > It worked before, back when I was building it from master.

Re: Configuration Management - Generic Configuration for Caches and Components

[Steve Malenfant]

Ryan,

I'm just going through what it takes to upgrade Traffic Server from 5.3.2
to 7.1 right now. There is a few things that changed in the configuration
which are easy to take care of, some others are not.

The easy one which I'm already taking care of :
- logs_xmls.config changed to logging.config (#1126)
- ORT change to use traffic_ctl instead traffic_line (#1128)

The one that will require some heavier work (github issue #1130) :
- cacheurl is deprecated, but the UI and API is specific to cacheurl.
Should be a good time to rename those and document how they should be used.
This is a "specific" Traffic Server case which actually becomes an issue
between version. The new plugin is called "cachekey".

I would like some feedback on how we can resolve issues between traffic
server as the profiles can't handle this at the moment. This is where the
"client" side processing of specific features would be nice.

Thanks,

Steve


On Fri, Sep 1, 2017 at 4:12 PM, Durfey, Ryan 
wrote:

> Opening a new thread on Generic Configuration as discussed in our
> meeting.  I drew a sketch (probably inaccurate) to prompt conversation.  If
> you can’t see it in the email there is a link to the wiki below where you
> can see it.  Please keep responses in the email thread (vs. wiki). I will
> summarize once we conclude debate.
>
>
>
> Ryan
>
>
> Generic_Configuration
> 
>
>- There is a desire to move to a generic configuration that is stored
>by Traffic Ops DB that could be interpreted separately for each CDN
>component or cache type
>- We are not exactly sure where interpretation gets done but probably
>in a separate Traffic Ops module before it is pushed out to the component
>   - It could exist on the component, however in the case of edge
>   caches it might not be efficient to operate an interpreter under heavy 
> loads
>- It would be the responsibility of the Cache or Component development
>team to write the interpreter of the generic config file
>   - So if you want to use Varnish caches you would be responsible for
>   writing a Varnish interpreter for the generic configuration file
>- One issue we might experience is that some cache engines may require
>new configuration parameters that don't exist in prior engines.
>   -  In this case we would need to add something upstream.  Other
>   engines would need to ignore this parameter, which is probably not a
>   problem so long as we go in knowing they can ignore unrecognized 
> parameters
>   without crashing.
>
>
>
> [image:
> https://cwiki.apache.org/confluence/download/attachments/69405446/image2017-9-1%2013%3A46%3A3.png?version=1=1504295163661=v2]
>
>
>
>
>
> *Ryan Durfey*
>
> Sr. Product Manager - CDN | Comcast Technology Solutions
>
> 1899 Wynkoop Ste. 550 | Denver, CO 80202
>
> M | 303-524-5099 <(303)%20524-5099>
>
> ryan_dur...@comcast.com
>
> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
> cdn_supp...@comcast.com
>
>
>

Re: [VOTE] Bugtracking in Github Issues

[Steve Malenfant]

+1

On Mon, Aug 28, 2017 at 1:02 PM, Dewayne Richardson 
wrote:

> +1
>
> On Mon, Aug 28, 2017 at 10:44 AM, Dave Neuman  wrote:
>
> > I thought we already had a vote on this?  Maybe I am thinking of the
> "move
> > to github" vote which I assumed to be all-encompassing.
> > Anyway, +1
> >
> > On Mon, Aug 28, 2017 at 10:43 AM, Dan Kirkwood 
> wrote:
> >
> > > +1
> > >
> > > On Mon, Aug 28, 2017 at 10:38 AM, Eric Friedrich (efriedri)
> > >  wrote:
> > > > We currently use JIRA Issues to track all of the Traffic Control
> bugs.
> > > >
> > > > Now that we have write access to Github, we can move back to GH
> Issues
> > > for bug tracking.
> > > >
> > > > This will be a better workflow because its one fewer tool and account
> > to
> > > have to interact with. This will hopefully lower the bar for new
> > > contributors to file bugs and engage with the product. We can also help
> > use
> > > it (along with the milestones) to create more useful changelogs and
> > release
> > > notes.
> > > >
> > > > A possible downside is that the Issues are maybe less flexible than
> > JIRA
> > > in terms of permissions, workflow, fields, etc. However, we were using
> > > Issues before we entered the incubator and that was fine for us.
> > Hopefully
> > > no one has developed an attachment for JIRA in the last year.
> > > >
> > > >
> > > > Please Vote +1 to move to Github Issues or -1 to stay on Jira. I’ll
> > > assume a lazy consensus if there aren’t enough votes.
> > > >
> > > > —Eric
> > > >
> > > >
> > >
> >
>

Re: Global parameters and seeds.sql

[Steve Malenfant]

Jeremy,

I observed the same thing when I upgraded my instance of Traffic Ops. It
had duplicated "tm.toolname" as a key. +1 on the proposal.

Steve

On Thu, Aug 24, 2017 at 12:04 PM, Jeremy Mitchell 
wrote:

> IMO there seems to be an inherent flaw with global parameters and that flaw
> is exposed in via seeds.sql.
>
> Let's use an example.
>
> There is a global parameter called tm.toolname with a seeded value of
> 'Traffic Ops' (
> https://github.com/apache/incubator-trafficcontrol/blob/
> master/traffic_ops/app/db/seeds.sql#L39
> )
>
> Obviously, the intention of this parameter is that you can change it to fit
> your needs. Maybe you want to change it to "Traffic Mops".
>
> However, when seeds.sql runs again (on upgrade for example), you will end
> up with a duplicate tm.toolname parameter because the unique constraint on
> the parameter table is applied to name + config_file + value.
>
> For "global" parameters, the unique constraint should really be on name +
> config_file because, really, why would you want more than 1 global
> parameter?
>
> So we have a table (parameters) where some parameters the unique constraint
> should be name + config_file + value (which makes perfect sense if you
> think about how parameters are used with profiles) and other parameters
> (global) where the unique constraint should be name + config_file...
>
> Anyhow, after saying all of thatI think the solution (or a solution) is
> to modify seeds.sql to first run a query (select count) for global
> parameters to ensure that they are not already there before inserting
> them
>
> I'll create a jira for that if there is no objections.
>
> jeremy
>

Re: Traffic Logs Code Release to Open Source

[Steve Malenfant]

I'd be interested to know as well. Something we need to work here as well.

On Wed, Aug 9, 2017 at 9:58 AM, Durfey, Ryan 
wrote:

> Guys, any idea when traffic analytics (traffic logs) base code might be
> released to open source?
>
> Ryan Durfey
> Sr. Product Manager - CDN | Comcast Technology Solutions
> 1899 Wynkoop Ste. 550 | Denver, CO 80202
> M | 303-524-5099
> ryan_dur...@comcast.com
> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com>
>
>

New Committer: Derek Gelinas

[Steve Malenfant]

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: Traffic Ops Golang Migration Proposal

[Steve Malenfant]

+1 to move to Golang. Few questions.

Configuration seems like a none issue for us since we are using Ansible, we
would prefer less postinstall interaction as possible as long as the
configuration is documented.
As for the name, do we plan to keep "traffic_ops_golang" in the future?
Have we thought about using "traffic_ops" for golang and
"traffic_ops_something" for Perl? It seems like the "Perl TO" should be the
dependency here and should be handled by the RPM at installation. There
could be confusion about folks not installing "traffic_ops_golang" on
upgrades since they are doing a "yum update traffic_ops".

If the dependency is this way, the golang version will need to be installed
and the perl version as well. But you don't need to run any postinstall and
simply need to change golang configuration to change the proxy.

Talking about postinstall and migrations (SQL), which package would contain
it in the future? The Perl or TO version?

Is there something preventing re-using the same /opt/traffic_ops directory
for both?

Steve

On Wed, Jul 19, 2017 at 5:25 PM, Dewayne Richardson 
wrote:

> When:   Read · Wed, Jul 19. If Cc: read
> 
> [image: Timyo expectation line]
> I had a knee jerk reaction to separate the RPMs because of the potential
> for a "new" approach, but I've now been convinced otherwise based upon the
> "Strangler Pattern" where the Perl gets rewritten into Golang overtime and
> the TO clients know none the difference.
>
> +1
>
> -Dew
>
> On Wed, Jul 19, 2017 at 12:52 PM, Jeff Elsloo  wrote:
>
>> I see. If that's the case, it's a hard requirement to run the golang
>> portion from whenever this is introduced onward. As long as we have
>> discipline around removing migrated routes, that should work okay and
>> would solve the "two watches" issue Mark mentioned when we discussed
>> this in person: A man with two watches (old API route, golang route)
>> does not know what time it is.
>>
>> I don't think that it makes a lot of sense to have a separate RPM
>> since the dependency goes the other direction, and users are required
>> to run the golang component no matter what. We might as well just
>> build that into the existing RPM build process for traffic_ops.
>>
>> Do we really need to ask the user for the port to move mojo to?
>> Obviously we can ask them to provide a port, but we could also just
>> pick a random, unused high port, and have mojo listen only on the
>> loopback interface. Maybe that's too "magical"?
>>
>> Does the golang app run as trafops:trafops and drop privileges after
>> opening :443?
>> --
>> Thanks,
>> Jeff
>>
>>
>> On Wed, Jul 19, 2017 at 11:58 AM, Robert Butts 
>> wrote:
>> >> This means that the traffic_ops side would have to check to see whether
>> >> traffic_ops_golang
>> >
>> >> Because the traffic_ops_golang package will depend on traffic_ops, not
>> the
>> >> other way around
>> >
>> > I was suggesting the other way around - traffic_ops will depend on
>> > traffic_ops_golang. Which means upgrading traffic_ops automatically
>> installs
>> > traffic_ops_golang, and we don't need to do the check. It'd mean you
>> > couldn't remove `traffic_ops_golang`, but the plan is to remove old
>> > endpoints from old TO anyway. Which is another reason making
>> > traffic_ops_golang a dependency of traffic_ops makes sense: it really
>> is,
>> > traffic_ops really does require it for the migrated endpoints.
>> >
>> > I agree with moving away from manual post-installation scripts, but I
>> don't
>> > think we can avoid it here, because we need the user to set a new port.
>> >
>> >
>> > On Wed, Jul 19, 2017 at 11:40 AM, Jeff Elsloo 
>> wrote:
>> >>
>> >> I'm +1 on most of what you suggest, except for doing the takeover in
>> >> postinstall in traffic_ops.
>> >>
>> >> While we can do whatever we want with postinstall, I think it's
>> >> awkward to have a tool within the traffic_ops package configuring
>> >> something under the traffic_ops_golang package, when the latter
>> >> package might not be installed. This means that the traffic_ops side
>> >> would have to check to see whether traffic_ops_golang is installed
>> >> outside of the normal RPM dependencies, adding more platform specific
>> >> code to postinstall. I don't see a generic way to implement the
>> >> "check" for the golang package within postinstall that will work. We
>> >> would have to check for a path that is not likely to exist for most
>> >> users, or check for a package. Both approaches require platform
>> >> specific code and assumptions.
>> >>
>> >> Because the traffic_ops_golang package will depend on traffic_ops, not
>> >> the other way around, it makes more sense to place the configuration
>> >> piece in the golang package. When the golang package is installed, we
>> >> can "take over" the port in the listen directive of cdn.conf, because
>> >> we know for a fact 

Re: traffic_router tomcat init script (shutdown) problems

[Steve Malenfant]

Does Traffic Monitor (Java version) have the same problem? If it does, can
the fix be applied?

On Wed, Jul 12, 2017 at 12:43 PM, Jason Tucker 
wrote:

> Thanks, Jeff.
>
> And just to clarify - this will *try* to do a graceful shutdown first, wait
> for the timeout period (10 seconds) and then force it if that was
> unsuccessful. The previous behavior was to wait for 5 seconds, and then
> give up entirely.
>
> We'll have to take another look at this when we move to a newer tomcat
> package. I have some ideas on how to improve this further - like switching
> to a systemd unit rather than init script for el7, and putting tunables in
> an external config (i.e. /etc/sysconfig/tomcat) like the tomcat RPMs
> generally do.
>
> __Jason
>
> On Wed, Jul 12, 2017 at 11:44 AM, Jeff Elsloo  wrote:
>
> > I discussed this with Jason, reviewed the PR and will be merging it
> > soon unless someone has concerns. I asked specifically about "force"
> > being the default shutdown mode, and that was done intentionally.
> > There might be a use case for a graceful shutdown with typical
> > applications deployed into Tomcat, but Traffic Router does not service
> > any long running sessions, so getting it shut down quickly is actually
> > desired.
> >
> > We can use this new init script and make changes as necessary in the
> > future, but this should be an improvement. Hopefully we won't have to
> > `kill -9 ` anymore.
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Tue, Jul 11, 2017 at 3:37 PM, Jason Tucker 
> > wrote:
> > > FYI - opened ticket and PR for this issue:
> > >
> > > The tomcat init script has a few problems:
> > >
> > > 1. "Clean" shutdowns frequently timeout, and the scripts give up,
> leaving
> > > tomcat running
> > >
> > > 2. Normal tomcat shutdown actually involves spinning up a second jvm
> > > instance. Right now, we start this second instance with the same
> > > CATALINA_OPTS as traffic_router, which can be problematic on
> > > memory-constrained hosts.
> > >
> > > https://issues.apache.org/jira/browse/TC-416
> > > https://github.com/apache/incubator-trafficcontrol/pull/724
> > >
> > > Thanks,
> > >
> > > _Jason
> >
>

Re: Update on RFC7871 - Client Subnet in DNS Support

[Steve Malenfant]

I've been able to start some discussions internally and looks like it would
be considered for certain domains (Like the one served by Traffic Routers).
We definitevely have cache groups which are not associated with some local
caching DNS.

On Tue, Jun 6, 2017 at 2:50 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Thanks Ryan-
>We will certainly have the option to disable use of this if you don’t
> want to use it.
>
> This is useful feedback though and I’ll be sure to push on the caching
> aspects of our specific use case more.
>
> —Eric
>
> > On Jun 6, 2017, at 2:43 PM, Durfey, Ryan <ryan_dur...@comcast.com>
> wrote:
> >
> > FYI, I followed up with one of our staff informally about implementation
> of RFC7871 and got similar feedback.  They ran a test and found a lot of
> impacts at scale.
> >
> > Feedback:
> > We found that EDNS0 Client Subnet, as currently standardized and
> implemented, doesn't work well with our distribution/scale.  Could actually
> increase the number of upstream queries and memory required to store
> responses by 1000x.
> >
> > Ryan DurfeyM | 303-524-5099
> >
> >
> > From: Steve Malenfant <smalenf...@gmail.com>
> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Date: Monday, June 5, 2017 at 6:15 AM
> > To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Subject: Re: Update on RFC7871 - Client Subnet in DNS Support
> >
> > +1.  We have a hard time convincing our DNS team to enable EDNS0 in our
> > caching DNS (because of the caching implications). I do see great
> benefits
> > to localize DNS DS.
> >
> > On Sun, Jun 4, 2017 at 5:29 AM, Ori Finkelman <o...@qwilt.com o...@qwilt.com>> wrote:
> >
> > +1
> > This will also work nicely with the effort to have a localized TR DNS
> > selection.
> > If Traffic Routers are selected the same way a traffic server is
> selected,
> > by the client proximity from CZF or Geo, then using EDNS0 client-subnet
> > will enable this choice to be more accurate based on real client subnet
> > rather than DSN resolver.
> >
> >
> >
> > On Fri, Jun 2, 2017 at 10:46 PM, David Neuman <david.neuma...@gmail.com<
> mailto:david.neuma...@gmail.com>>
> > wrote:
> >
> >> +1, excited to see this one come through.
> >>
> >> On Fri, Jun 2, 2017 at 12:15 PM, Eric Friedrich (efriedri) <
> >> efrie...@cisco.com<mailto:efrie...@cisco.com>> wrote:
> >>
> >>> We are planning to add support for RFC7871 to Traffic Router. Here is a
> >>> brief description of the feature. Comments appreciated!
> >>>
> >>> Background
> >>> Clients do not make DNS requests directly to TR. Typically TR requests
> >>> come from DNS resolvers within the infrastructure. Today, Cache Group
> >>> selection for DNS Delivery Services is based on the IP address of the
> > DNS
> >>> resolver making the request to TR. RFC7871 includes the client subnet
> > in
> >> an
> >>> EDNS0 option within the DNS query. When the ECS OPT is present (and the
> >>> feature is enabled via a TR parameter), Traffic Router will use this IP
> >> in
> >>> place of the source IP of the DNS packet (the IP of the resolver). This
> >> IP
> >>> will be used in the CZF and maxmind lookups.
> >>>
> >>> Requirements
> >>>
> >>>  1.  If DNS query includes ECS option in the Optional Record, Traffic
> >>> Router will use the IP address included in the ECS option as the client
> >>> address for Cache Group Selection
> >>>  2.  If there are multiple ECS options in the Optional Record, the one
> >>> with the longest IP prefix - i.e. the ECS option with largest Source
> > Net
> >>> Mask will be used
> >>>  3.  If DNS query includes ECS Option, then DNS response from Traffic
> >>> Router will also include the ECS Option. In the response the Scope Net
> >> Mask
> >>> is set to be same as the Source Net Mask. This is required by RFC 7871
> >> for
> >>> DNS caching to work properly.
> >>>  4.  It is assumed that customers/operators will ensure that Source
> > Net
> >>> Mask for a subnet specified in the ECS is at greater than or equal to
> > the
> >>> net mask for the corresponding subnet entry in the CZF file. e.g. if

Re: Update on RFC7871 - Client Subnet in DNS Support

[Steve Malenfant]

+1.  We have a hard time convincing our DNS team to enable EDNS0 in our
caching DNS (because of the caching implications). I do see great benefits
to localize DNS DS.

On Sun, Jun 4, 2017 at 5:29 AM, Ori Finkelman  wrote:

> +1
> This will also work nicely with the effort to have a localized TR DNS
> selection.
> If Traffic Routers are selected the same way a traffic server is selected,
> by the client proximity from CZF or Geo, then using EDNS0 client-subnet
> will enable this choice to be more accurate based on real client subnet
> rather than DSN resolver.
>
>
>
> On Fri, Jun 2, 2017 at 10:46 PM, David Neuman 
> wrote:
>
> > +1, excited to see this one come through.
> >
> > On Fri, Jun 2, 2017 at 12:15 PM, Eric Friedrich (efriedri) <
> > efrie...@cisco.com> wrote:
> >
> > > We are planning to add support for RFC7871 to Traffic Router. Here is a
> > > brief description of the feature. Comments appreciated!
> > >
> > > Background
> > >  Clients do not make DNS requests directly to TR. Typically TR requests
> > > come from DNS resolvers within the infrastructure. Today, Cache Group
> > > selection for DNS Delivery Services is based on the IP address of the
> DNS
> > > resolver making the request to TR. RFC7871 includes the client subnet
> in
> > an
> > > EDNS0 option within the DNS query. When the ECS OPT is present (and the
> > > feature is enabled via a TR parameter), Traffic Router will use this IP
> > in
> > > place of the source IP of the DNS packet (the IP of the resolver). This
> > IP
> > > will be used in the CZF and maxmind lookups.
> > >
> > > Requirements
> > >
> > >   1.  If DNS query includes ECS option in the Optional Record, Traffic
> > > Router will use the IP address included in the ECS option as the client
> > > address for Cache Group Selection
> > >   2.  If there are multiple ECS options in the Optional Record, the one
> > > with the longest IP prefix - i.e. the ECS option with largest Source
> Net
> > > Mask will be used
> > >   3.  If DNS query includes ECS Option, then DNS response from Traffic
> > > Router will also include the ECS Option. In the response the Scope Net
> > Mask
> > > is set to be same as the Source Net Mask. This is required by RFC 7871
> > for
> > > DNS caching to work properly.
> > >   4.  It is assumed that customers/operators will ensure that Source
> Net
> > > Mask for a subnet specified in the ECS is at greater than or equal to
> the
> > > net mask for the corresponding subnet entry in the CZF file. e.g. if
> ECS
> > > Option has 192.168.10.0/8, then 192.168.0.0/16 in CZF will work, but
> > > 192.168.10./28 will not work.
> > >   5.  Add a TR parameter to disable use of ECS field even when present
> > >
> > > Design
> > >
> > > To support this feature new logic will be added to NameServer.query()
> > > function. The new logic will be responsible for parsing ECS option in
> the
> > > OptionalRecord of the incoming DNS Request, and retrieving the Client
> IP
> > > address and the associated Source Net Mask (Scope Net Mask must be 0 in
> > the
> > > incoming Request per RFC 7871). Please note that the underlying DNS
> > library
> > > xbill/dnsjava already has support for parsing the ECS Options. These
> > > functions from the library will be leveraged.
> > >
> > >   1.  Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will
> > > return list of ClientSubnetOption for the incoming Request (Message)
> > >   2.  ClientSubnetOption has public methods to retrieve netmask and
> > Client
> > > IP address:  getSourceNetmask(), getAddress()
> > >
> > > If ECS option is present, then the IP address retrieved from the ECS
> > > option, and will be passed as the Client IP address to the Traffic
> Router
> > > (through getZone call) for CZF/geo lookup
> > >
> > > If ECS option is present, then ClientSubnetOption will be created and
> > > included in the DNS response. In the Response the Scope Net Mask of the
> > > ClientSubnetOption is set as the Source Net Mask
> > >
> > > Testing
> > >   We’ll test against all of the various CZF, National, Regional, VPN
> > > Blocking features and will do our best to check with DNSSEC
> > >
> > > —Eric
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> o...@qwilt.com
>

Re: Getting CZF data from BGP?

[Steve Malenfant]

+1 on this. Although no experience with BGP. I've been looking into OpenBMP
lately which seems to support BGP-LS.

On Tue, May 30, 2017 at 1:48 PM, Jan van Doorn  wrote:

> Definitely the first, the second maybe as a stretch goal.
>
> On Tue, May 30, 2017 at 11:23 AM Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > Hey Jan-
> >
> > Are you looking to build a static CZF based off of BGP inputs?
> >
> > Are you looking for something that will listen to BGP and create a
> > “real-time CZF” that responds to routing/CG changes?
> >
> > Or something else?
> >
> > > On May 30, 2017, at 1:00 PM, Jan van Doorn  wrote:
> > >
> > > Hi,
> > >
> > > We are considering building something to get the CZF data directly from
> > the
> > > network, possibly using BGP and open source routing software. Before we
> > get
> > > going, wanted to ask if anyone has any experience with this, or tools
> > > already built to do this?
> > >
> > > Rgds,
> > > JvD
> >
> >
>

Re: [VOTE] Move Traffic Control to full GitHub

[Steve Malenfant]

+1

Re: Invalidate Content Error

[Steve Malenfant]

> > > > >
> >>> > > > > On Wed, Feb 1, 2017 at 8:11 AM, Oren Shemesh <or...@qwilt.com>
> >>> > wrote:
> >>> > > > >
> >>> > > > > > Thanks Jeremy :-)
> >>> > > > > >
> >>> > > > > > On Wed, Feb 1, 2017 at 5:09 PM, Jeremy Mitchell <
> >>> > > mitchell...@gmail.com
> >>> > > > >
> >>> > > > > > wrote:
> >>> > > > > >
> >>> > > > > > > I don't think jobs are ever programmatically removed from
> the
> >>> > jobs
> >>> > > > > table
> >>> > > > > > > nor are their statuses changed. They always remain in a
> >>> pending
> >>> > > > state.
> >>> > > > > > >
> >>> > > > > > > SELECT COUNT(*) FROM job WHERE status NOT IN ( SELECT id
> FROM
> >>> > > > > job_status
> >>> > > > > > > WHERE name = 'PENDING' )
> >>> > > > > > > 0
> >>> > > > > > >
> >>> > > > > > > Like I mentioned earlier, I think there was a lot more
> >>> planned
> >>> > for
> >>> > > > jobs
> >>> > > > > > but
> >>> > > > > > > as it stands today, the jobs table is currently for
> >>> "invalidate
> >>> > > > > content"
> >>> > > > > > > (purge) jobs ONLY and the jobs go in to that table and
> never
> >>> come
> >>> > > > out.
> >>> > > > > > It's
> >>> > > > > > > kind of like the roach motel :)
> >>> > > > > > > https://www.youtube.com/watch?v=jKhGHxO-woc=youtu.
> >>> > be=27
> >>> > > > > > >
> >>> > > > > > > Anyhow, it's important to remember that when initiating an
> >>> > > > "invalidate
> >>> > > > > > > content" request for delivery service X, the important
> thing
> >>> is
> >>> > > that
> >>> > > > > the
> >>> > > > > > > upd_pending flag for all servers that serve that delivery
> >>> service
> >>> > > is
> >>> > > > > > > flipped to true that way each one of those servers will
> >>> fetch a
> >>> > new
> >>> > > > > > > regex_revalidate.config file that ATS needs to "invalidate"
> >>> the
> >>> > > > asset.
> >>> > > > > > > Whether or not a job is created really has nothing to do
> >>> with how
> >>> > > > > content
> >>> > > > > > > is invalidated. It's currently just a way to record who did
> >>> what
> >>> > > and
> >>> > > > > > when.
> >>> > > > > > >
> >>> > > > > > > I'm going to create an issue to remove those unused tables
> >>> > > > (job_status,
> >>> > > > > > > job_result, job_agent) if nobody is opposed to it. Maybe
> I'll
> >>> > send
> >>> > > > out
> >>> > > > > a
> >>> > > > > > > different email specifically about that.
> >>> > > > > > >
> >>> > > > > > > Jeremy
> >>> > > > > > >
> >>> > > > > > > On Wed, Feb 1, 2017 at 2:07 AM, Oren Shemesh <
> >>> or...@qwilt.com>
> >>> > > > wrote:
> >>> > > > > > >
> >>> > > > > > > > Thanks for your replies and the information :-)
> >>> > > > > > > >
> >>> > > > > > > > Dave, Is there a place I can document a work-around for
> >>> being
> >>> > > > > included
> >>> > > > > > in
> >>> > > > > > > > the release notes of 1.8 ?
> >>> > > > > > > > My suggested work-around would be fixing the
> >>> create_tables.sql
> >>> > > > script
> >>> >

Re: Invalidate Content Error

[Steve Malenfant]

Please look at the release notes of 1.3.0, might solve your problem.

https://github.com/Comcast/traffic_control/releases/tag/RELEASE-1.3.0

The revalidation feature doesn't work out of the box. The entry id=1 in the
job_agent table MUST exist as well as name=PURGE must be present in the
job_status table.

On Tue, Jan 31, 2017 at 3:31 PM, Jeremy Mitchell 
wrote:

> In my opinion, the job agent id should have been passed to the newjob()
> subroutine rather than depending on a hard-coded value...actually, it looks
> like that was the intent but the $agent variable never got used.
>
> https://github.com/apache/incubator-trafficcontrol/blob/
> master/traffic_ops/app/lib/UI/Job.pm#L42
>
> Also, I don't think the concept of jobs, job agents, etc was ever fully
> fleshed out (somebody correct me if i'm wrong), therefore, it would be my
> opinion that we eventually kill these tables:
>
> - job_agent
> - job_status
> - job_result
>
> this would eliminate the job_agent FK from the job table and then this
> problem of potentially using an job agent ID that doesn't exist goes bye
> bye...
>
> also, fyi, i believe the job table really only contains "purge" aka
> "invalidate content" jobs...(defined by keyword=purge).
>
> Jeremy
>
> On Tue, Jan 31, 2017 at 12:42 PM, Dave Neuman  wrote:
>
> > Thanks for the investigation.  Sounds like there is definitely a bug
> > there.  I would vote don't worry about fixing the issue in 1.8 since it
> is
> > fixed in master.  We should, however, make a release note or something
> > explaining the issue and the work around.
> >
> > --Dave
> >
> > On Tue, Jan 31, 2017 at 12:32 PM, Oren Shemesh  wrote:
> >
> > > Continuing the investigation of this issue, I have found what I believe
> > to
> > > be an inconsistency in the code that handles content invalidation.
> > > To the best of my understanding, the bug exists in 1.7.x, and in the
> > latest
> > > 1.8.x as well, and was only fixed in master, as part of the move to
> > > postgresql.
> > >
> > > The bug prevents you from adding a job, you get an immediate error in
> the
> > > UI.
> > >
> > > Question: Can anyone attest to Content Invalidation working in a fresh
> > > install of TC 1.7 or 1.8 ?
> > >
> > > Another question: Given that the problem probably does not exist in
> > > 'master', do we care about fixing it in the 1.8.x train (Or a following
> > > train, non-postgresql) ?
> > > If so, I will issue a JIRA.
> > >
> > > The details:
> > >
> > > I believe there is an inconsistency between the code that creates the
> TO
> > DB
> > > during a clean install, and the code that depends on it.
> > >
> > > Creating the TO DB is done by traffic_ops/app/db/create_tables.sql. In
> > the
> > > mysql version (1.7 and 1.8), it creates the 'job_agent' table and the
> > > 'job_status' table with table options AUTO_INCREMENT=2
> > > and AUTO_INCREMENT=5, respectively:
> > >
> > > *CREATE TABLE `job_agent`* (
> > >   `id` int(11) NOT NULL AUTO_INCREMENT,
> > > ...
> > > ) ENGINE=InnoDB *AUTO_INCREMENT=2* DEFAULT CHARSET=latin1;
> > >
> > > *CREATE TABLE `job_status`* (
> > >   `id` int(11) NOT NULL AUTO_INCREMENT,
> > > ...
> > > ) ENGINE=InnoDB *AUTO_INCREMENT=5* DEFAULT CHARSET=latin1;
> > >
> > > This means that when the script that populates these tables
> > > (traffic_ops/app/db/migrations/2015120800_add_job_status.sql) is
> > run,
> > > it creates entries with an id that begins with 2 and 5, respectively.
> > >
> > > However, the code that attempts to add an entry to the 'job' table,
> > assumes
> > > that the id numbers in both tables, begins at 1.
> > >
> > > From traffic_ops/app/lib/UI/Job.pm:
> > >
> > > sub newjob {
> > > ...
> > > my $*status = 1*;
> > > ...
> > > my $insert = $self->db->resultset('Job')->create(
> > > {
> > > *agent   => 1,*
> > > object_type => $object_type,
> > > object_name => $object_name,
> > > entered_time=> $entered_time,
> > > keyword => $keyword,
> > > parameters  => $parameters,
> > > asset_url   => $org_server_fqdn,
> > > asset_type  => $asset_type,
> > > *status  => $status*,
> > > job_user=> $user,
> > > start_time  => $start_time_gmt,
> > > job_deliveryservice => $ds->id,
> > > }
> > >
> > > As you can see, both the 'agent' and the 'status' fields are set to a
> > > hard-coded value of 1, which cannot exist in tables that are set to
> have
> > an
> > > auto-incremented value of 'id' that begins with 2 or 5.
> > >
> > > When looking at the traffic_ops/app/db/create_tables.sql script in
> > > 'master', which is now adapted to postgresql, it seems that it is
> totally
> > > different code, but the inconsistency is now gone, because the
> numbering
> > > starts at 1:
> > >
> > > CREATE TABLE job_agent (
> > > id bigint NOT NULL,
> > > name text,
> > > description text,
> > > active integer DEFAULT 0 NOT NULL,
> > > 

Re: Issues with using Traffic-Vault

[Steve Malenfant]

Have you tried to simply restart Traffic Ops? We've seen ours (1.6) not
being able to create Certificates after a while.

On Wed, Jan 18, 2017 at 11:10 PM, Nir Sopher  wrote:

> ERROR result for http://ops.nirs-tc1.tc-dev.qwilt.com/api/1.2/cdns/name/
> nirs-tc1-cdn/sslkeys.json is: ...{"message":"No SSL certificates found for
> nirs-tc1-cdn"}...
> FATAL http://ops.nirs-tc1.tc-dev.qwilt.com/api/1.2/cdns/name/
> nirs-tc1-cdn/sslkeys.json returned HTTP 404!
>
>
> On Thu, Jan 19, 2017 at 12:43 AM, Dave Neuman  wrote:
>
> > What error are you getting in ORT?
> >
> > On Wed, Jan 18, 2017 at 11:57 AM, Nir Sopher  wrote:
> >
> > > OK.
> > > I called the command from traffic op and got the below output, which
> > looks
> > > ok to me.
> > > So now I know that adding a certificate via the "paste" screen works
> (and
> > > not only say "success").
> > > Still, pulling the configuration via the ort script fails.
> > >
> > > Regarding the log, no message during the certificate paste. My log cfg
> is
> > > also paste below.
> > >
> > > 10x,
> > > Nir
> > >
> > > $ cat /opt/traffic_ops/app/conf/production/log4perl.conf
> > > log4perl.rootLogger = ERROR, SCREEN, FILE
> > > log4perl.appender.FILE = Log::Log4perl::Appender::File
> > > log4perl.appender.FILE.layout = PatternLayout
> > > log4perl.appender.FILE.layout.ConversionPattern = [%d{ISO8601}] [%p]
> > %m%n
> > > log4perl.appender.FILE.filename = /var/log/traffic_ops/traffic_ops.log
> > >
> > > log4perl.appender.SCREEN = Log::Log4perl::Appender::Screen
> > > log4perl.appender.SCREEN.layout = PatternLayout
> > > log4perl.appender.SCREEN.layout.ConversionPattern = [%d{ISO8601}] [%p]
> > > %m%n
> > >
> > >
> > >
> > > $ curl -k "https://admin:admin...@vault-int.nirs-tc1.tc-dev.qwilt.com:
> > > 8088/riak/ssl/ynet-images-latest"
> > > {"cdn":"nirs-tc1-cdn","deliveryservice":"ynet-images"
> > > ,"certificate":{"csr":"
> > > LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0NCk1JSUI2REND
> > > QVZFQ0FRQXdnYWN4\nQ3pBSkJnTlZCQVlUQWtsTU1ROHdEU
> > > VlEVlFRSURBWkpjM0poWld3eEZEQVMNCkJnTlZCQWNNQzBo\
> > > ndlpFaGhjMmhoY205dU1RNHdEQVlEVlFRS0RBVlJkMmxzZERFTE1Ba0dBMVV
> > > FQ3d3Q1VVTXgNCk5U\nQXpCZ05WQkFNTUxDb3VlVzVsZEMxc
> > > GJXRm5aWE11Ym1seWN5MTBZekV0WTJSdUxuUmpMV1JsZGk1\
> > > namNXeHYNCmRXUXVZMjl0TVIwd0d3WUpLb1pJaHZjTkFRa0JGZzV1YVhKelF
> > > IRjNhV3gwTG1OdmJU\nQ0JuekFOQmdrcWhraUcNCjl3MEJBU
> > > UVGQUFPQmpRQXdnWWtDZ1lFQTAxVWZnbzZrcEJOMGNQOEV5\
> > > nVXY4MW9WNFB2WlJoM2V5dmViNjBaZnQNCldjblZ0Zk53N1ZJRW52Q1ByU0J
> > > 6b25MajI4NGoyUGcv\nQkhQQ3Rudmc2N2N5bXRKT2pJVU4rZ
> > > XoyRXkvSUxnUXYNCkdjZFQ0RmErTGZmcXFudUc3Y3gxcDRU\
> > > nR3k2aGpYdFNPZ2R0YklyNFhEajJiWlBIVTVxTFlkak1QSXZXc2M5aGkNCmV
> > > QY0NBd0VBQWFBQU1B\nMEdDU3FHU0liM0RRRUJCUVVBQTRHQ
> > > kFDRGJQUlFSM1RkNWh1QmtQMUg3V0l4ejdjNU8NCnJsYnpn\
> > > nWHlxcEpjRFg2Q3RJaEd1d1orYkxIa3Y4dXdsMUoyZm5QTWM3TlB4UGxjbXY
> > > 0RWU3RXpJQ3dJTzBr\ncTMNClFvdksraEp1MDJLTE1peUp5b
> > > HZpT1VEeWlldEtPdEpDNlVKelNhZEpjWjVnSmJzNjNiRk83\
> > > nWmlpbDQ0UmdKaFYNCklBMSsyYUwwU0hmeTY4R2cNCi0tLS0tRU5EIENFUlR
> > > JRklDQVRFIFJFUVVF\nU1QtLS0tLQ==","crt":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS
> > > 0tLS0tDQpNSUlDeHpDQ0FqQUNDUURvZlNRcTJpcnQ4REFO\
> > > nQmdrcWhraUc5dzBCQVFVRkFEQ0JwekVMTUFrR0ExVUVCaE1DDQpTVXd4RHp
> > > BTkJnTlZCQWdNQmts\nemNtRmxiREVVTUJJR0ExVUVCd3dMU
> > > 0c5a1NHRnphR0Z5YjI0eERqQU1CZ05WDQpCQW9NQlZGM2FX\
> > > neDBNUXN3Q1FZRFZRUUxEQUpSUXpFMU1ETUdBMVVFQXd3c0tpNTVibVYwTFd
> > > sdFlXZGxjeTV1DQph\nWEp6TFhSak1TMWpaRzR1ZEdNdFpHV
> > > jJMbU54Ykc5MVpDNWpiMjB4SFRBYkJna3Foa2lHOXcwQkNR\
> > > nRVdEbTVwDQpjbk5BY1hkcGJIUXVZMjl0TUI0WERURTNNREV4TmpFeE5UQTB
> > > NbG9YRFRFNE1ERXhO\nakV4TlRBME1sb3dnYWN4DQpDekFKQ
> > > mdOVkJBWVRBa2xNTVE4d0RRWURWUVFJREFaSmMzSmhaV3d4\
> > > nRkRBU0JnTlZCQWNNQzBodlpFaGhjMmhoDQpjbTl1TVE0d0RBWURWUVFLREF
> > > WUmQybHNkREVMTUFr\nR0ExVUVDd3dDVVVNeE5UQXpCZ05WQ
> > > kFNTUxDb3VlVzVsDQpkQzFwYldGblpYTXVibWx5Y3kxMFl6\
> > > nRXRZMlJ1TG5SakxXUmxkaTVqY1d4dmRXUXVZMjl0TVIwd0d3WUpLb1pJDQp
> > > odmNOQVFrQkZnNXVh\nWEp6UUhGM2FXeDBMbU52YlRDQm56Q
> > > U5CZ2txaGtpRzl3MEJBUUVGQUFPQmpRQXdnWWtDDQpnWUVB\
> > > nMDFVZmdvNmtwQk4wY1A4RXlVdjgxb1Y0UHZaUmgzZXl2ZWI2MFpmdFdjblZ
> > > 0Zk53N1ZJRW52Q1By\nU0J6DQpvbkxqMjg0ajJQZy9CSFBDd
> > > G52ZzY3Y3ltdEpPaklVTitlejJFeS9JTGdRdkdjZFQ0RmEr\
> > > nTGZmcXFudUc3Y3gxDQpwNFRHeTZoalh0U09nZHRiSXI0WERqMmJaUEhVNXF
> > > MWWRqTVBJdldzYzlo\naWVQY0NBd0VBQVRBTkJna3Foa2lHD
> > > Qo5dzBCQVFVRkFBT0JnUUJha0tKaTNrN1hOUDljWTZ0K05i\
> > > nT0hNVWJPWVI0WWE2Y2xKN3cyYU1CSTNYdjNZMUcyDQo5K1ZxajA1cDZXaU8
> > > xWVNGWWRBb2QxSnRD\nNDRieUt4NWRBbTNKdnZrUWZNNU8xb
> > > 09zNG8yWnhrMXRmZmVqN3NkDQpCSDBKOGdqSkhYbmg0TWFm\
> > > neHhzR09KSXhOSXI3aDA5cTZYUENaTlVVaTROQnRrRzVVM2dsUnB0YWlnPT0
> > > NCi0tLS0tRU5EIENF\nUlRJRklDQVRFLS0tLS0=","key":"
> > > LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQ0KTUlJQ1hRSUJBQUtC
> > > Z1FEVFZSK0NqcVNr\nRTNSdy93VEpTL3pXaFhnKzlsR0hkN
> > > 0s5NXZyUmwrMVp5ZFcxODNEdA0KVWdTZThJK3RJSE9pY3VQ\
> > > nYnppUFkrRDhFYzhLMmUrRHJ0ekthMGs2TWhRMzU3UFlUTDhndUJDOFp4MVB
> > > 

Re: regex_revalidate.config

[Steve Malenfant]

I'm OK with this. I think most of the revalidate functionality is not well
understood here... I guess I need to look into the API since we are using
the UI to issue revalidate today.

On Mon, Dec 12, 2016 at 5:43 PM, Jeremy Mitchell 
wrote:

> I've created an issue to solicit some feedback regarding the removal of
> regex_revalidate.config from the file system. If you are not aware,
> regex_revalidate.config is the ATS config file used to "invalidate
> content". Storing regex_revalidate.config on the file system makes it
> harder to set up a highly-available, redundant traffic ops.
>
> https://issues.apache.org/jira/browse/TC-68
>
> Thanks!
>

Re: EDGE client of the MID

[Steve Malenfant]

Are you configuring using Traffic Control or modifying the trafficserver
configuration directly? Traffic Control takes care of those configuration
once deployed with ORT at the Edge.

On Thu, Oct 27, 2016 at 8:37 AM, Muhammed Olgun <mh.ol...@gmail.com> wrote:

> Hey Steve,
>
> I'm using TC 1.7.0.
>
> Thank you!
> Muhammed
>
> 27 Eki 2016 Per, saat 15:18 tarihinde Steve Malenfant <
> smalenf...@gmail.com>
> şunu yazdı:
>
> Which version of Traffic Control are you using? I believe it's important
> you use 1.7.0 because earlier version didn't support different origin port
> than 80 in the past.
>
> On Thu, Oct 27, 2016 at 7:53 AM, Muhammed Olgun <mh.ol...@gmail.com>
> wrote:
>
> > Hey,
> >
> > I'm trying to build a simple PoC of Traffic Control based on this
> > architecture
> > http://traffic-control-cdn.net/docs/latest/_images/
> > traffic_control_overview_3.png
> >
> > It looks like reverse proxy is client of the forward proxy. I've created
> > two separate Traffic Server in two separate VMs. But I don't know how to
> > configure the remap.config in reverse proxy. I couldn't find any
> > configuration for this use case.
> >
> > What I have in remap.config right know is
> >
> > regex_map http://(.*)/ http://mid.mycdn.com:8080/
> >
> > Any suggestions?
> >
> > Thank you!
> > Muhammed
> >
>

Re: EDGE client of the MID

[Steve Malenfant]

Which version of Traffic Control are you using? I believe it's important
you use 1.7.0 because earlier version didn't support different origin port
than 80 in the past.

On Thu, Oct 27, 2016 at 7:53 AM, Muhammed Olgun  wrote:

> Hey,
>
> I'm trying to build a simple PoC of Traffic Control based on this
> architecture
> http://traffic-control-cdn.net/docs/latest/_images/
> traffic_control_overview_3.png
>
> It looks like reverse proxy is client of the forward proxy. I've created
> two separate Traffic Server in two separate VMs. But I don't know how to
> configure the remap.config in reverse proxy. I couldn't find any
> configuration for this use case.
>
> What I have in remap.config right know is
>
> regex_map http://(.*)/ http://mid.mycdn.com:8080/
>
> Any suggestions?
>
> Thank you!
> Muhammed
>