From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 21:23:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A34061065672; Fri, 7 Sep 2012 21:23:33 +0000 (UTC) (envelope-from simon@FreeBSD.org) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id 235988FC08; Fri, 7 Sep 2012 21:23:33 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id 42F592CBE67; Fri, 7 Sep 2012 21:23:32 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id 7Ga3AHdYUcvg; Fri, 7 Sep 2012 21:23:30 +0000 (UTC) Received: from [192.168.4.35] (unknown [89.100.2.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id 03FBA2CBE61; Fri, 7 Sep 2012 21:23:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: "Simon L. B. Nielsen" In-Reply-To: Date: Fri, 7 Sep 2012 22:23:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120830141939.GJ64447@ithaqua.etoilebsd.net> <5048D2EC.70109@FreeBSD.org> <5049E060.9020602@infracaninophile.co.uk> To: Ivan Voras X-Mailer: Apple Mail (2.1486) Cc: Matthew Seaman , freebsd-current@freebsd.org Subject: Re: pkg (aka pkgng) 1.0 released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:23:33 -0000 On 7 Sep 2012, at 13:02, Ivan Voras wrote: > On 7 September 2012 13:54, Matthew Seaman > wrote: >> On 09/07/12 12:30, Ivan Voras wrote: >>> On 06/09/2012 18:44, Matthew Seaman wrote: >>>> On 06/09/2012 16:37, Ivan Voras wrote: >>>=20 >>>>> Hi, >>>>>=20 >>>>> It looks like the pkg port installs pkg.conf.sample with the line: >>>>>=20 >>>>> PACKAGESITE : http://pkg.freebsd.org/${ABI}/latest >>>>>=20 >>>>> ... which is finally a good step in the direction of making pkgng >>>>> working by default, except that the "pkg.freebsd.org" site doesn't = exist >>>>> in DNS. Instead, pkgbeta.freebsd.org still exists. I suppose one = should >>>>> be a DNS CNAME for the other? >>>>=20 >>>> It's a SRV record: >>>>=20 >>>> seedling:~:% dig +short IN SRV _http._tcp.pkg.freebsd.org >>>> 10 10 80 pkgbeta.FreeBSD.org. >>>=20 >>> Hi, >>>=20 >>> What are the benefits of doing it this way? >>=20 >> Yeah -- it's a bit OTT right now given there's just the one publicly >> available pkg repository available. It will pay off later when there >> are more pkg repositories available -- repositories can be added to = (or >> removed from) the list in the SRV record without end-users having to >> know the details. >>=20 >> It may also be possible to replicate what portupdate has done and use >> geolocation based services to steer end users to a nearby repository >> site automatically. >=20 > Ok, but all that can be done the "normal" way with A records. >=20 > As far as I can tell, the intended benefits of the SRV record system > is to disentangle services and hosts, so that, e.g. the same > user-visible DNS name (e.g. "pkg.freebsd.org") resolves to a different > host if asked for the HTTP service and the FTP service. That is one feature of SRV, but that part isn't really something we use = for anything, nor plan to (other than the fact that you specify SRV = records that way). > I suppose this could work in FreeBSD's case if the record was created > differently, instad of the "normal" _http._tcp record, introduce a new > one, e.g. _pkgng._tcp, so when a web browser visits "pkg.freebsd.org" > it gets a regular web page or some other user-visible content, and the There is no plan to add an A record to pkg.freebsd.org, so a browser = would never be able to resolve it. Adding an A record there would IMO be = more likely to mislead people to think that pkg(8) (is it section 8?) = fetches packages from there. > specially made pkg client will resolve it to another service and > another (possibly) server. This also can be done without the SRV > record, by e.g. inspecting client's HTTP headers. >=20 > I'm not saying that the SRV record is technically wrong in this case, > I just don't see how is it useful (and surely there will be others > trying to ping "pkg.freebsd.org" and complaining when it fails to > resolve). As Chip Marshall mentions, SRV records allow us to load balancing and = failover. Both are rather important in allowing us to scale pkg = distribution and changing it without requiring client side changes. The = fallback handling of SRV allows us, among other things, to have thin = frontend servers which only have a subset of packages, and then = automatic fallback to the full mirrors. Once the initial pkg distribution sites are set up, we will also create = some more SRV records, so the people who want can prioritize mirrors = close to them based on regions while still falling back to mirrors = longer away from them. Oh, and anyone using portsnap or freebsd-update are already using SRV = records. For anyone interested in more details, they can read my document = describing the system, which bapt implemented the SRV support in pkgng = from: = https://docs.google.com/document/d/1MmQOV2IUfRtdlzd1i63SJQgngjPJ8eERaSa68X= ydyc0/edit --=20 Simon L. B. Nielsen