[PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

DoneSubmitted by Ludovic Courtès.
Details
11 participants
  • Andreas Enge
  • Chris Marusich
  • Giovanni Biscuolo
  • Hartmut Goebel
  • Hartmut Goebel
  • Ludovic Courtès
  • Pierre Neidhardt
  • Marius Bakke
  • Meiyo Peng
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Severity
normal
L
L
Ludovic Courtès wrote on 3 Dec 2018 16:43
(address . guix-patches@gnu.org)
20181203154335.10366-1-ludo@gnu.org
Hello Guix!
These patches (actually the last one) switch Guix to default tohttps://ci.guix.info for substitutes, in preparation for theupcoming 0.16.0 release (hopefully this week!).
Rationale:
• berlin.guixsd.org generally performs better than hydra.gnu.org;
• berlin supports x86, ARMv7, and AArch64 (hydra lacks AArch64);
• berlin has much more storage space than hydra;
• berlin runs Cuirass on GuixSD, so software-wise, it corresponds to what we want to push; Cuirass still has limitations in some ways compared to Hydra, but we’re getting there, and hydra.gnu.org is still up and running so we can still use it, e.g., to track build progress until Cuirass is as convenient.
For the domain name I initially wanted “ci.guix.gnu.org” but we failedto set that up. Oh well, I think that’s OK.
This change modifies the manual. Translations will thus be stale;Julien, do you think it’d be reasonable to push a new pre-releaseto the Translation Project? Or should be just live with theslight inaccuracy?
Thanks,Ludo’.
Ludovic Courtès (3): etc: Add "ci.guix.info.pub" public key file. Remove most references to hydra.gnu.org. build: Default to https://ci.guix.infofor substitutes.
Makefile.am | 5 +- build-aux/check-available-binaries.scm | 4 +- .../check-final-inputs-self-contained.scm | 2 +- config-daemon.ac | 10 +-- doc/contributing.texi | 2 +- doc/guix.texi | 67 +++++++++---------- etc/substitutes/ci.guix.info.pub | 1 + gnu/services/base.scm | 4 +- gnu/system/install.scm | 2 +- guix/scripts/build.scm | 2 +- guix/scripts/size.scm | 2 +- guix/scripts/substitute.scm | 2 +- guix/self.scm | 3 + guix/store.scm | 2 +- 14 files changed, 51 insertions(+), 57 deletions(-) create mode 120000 etc/substitutes/ci.guix.info.pub
-- 2.19.2
L
L
Ludovic Courtès wrote on 3 Dec 2018 16:53
[PATCH 3/3] build: Default to https://ci.guix.info for substitutes.
(address . 33600@debbugs.gnu.org)
20181203155335.10629-3-ludo@gnu.org
* config-daemon.ac (guix_substitute_urls): Always default to"https://ci.guix.info".* doc/guix.texi (SUBSTITUTE-SERVER): Switch to ci.guix.info.* guix/scripts/build.scm (%default-log-urls): Likewise.* guix/scripts/substitute.scm (%default-substitute-urls): Likewise.* guix/store.scm (%default-substitute-urls): Likewise.--- config-daemon.ac | 10 +--------- doc/guix.texi | 13 ++++--------- guix/scripts/build.scm | 2 +- guix/scripts/substitute.scm | 2 +- guix/store.scm | 2 +- 5 files changed, 8 insertions(+), 21 deletions(-)
Toggle diff (93 lines)diff --git a/config-daemon.ac b/config-daemon.acindex aac46817f5..e5b0ee082c 100644--- a/config-daemon.ac+++ b/config-daemon.ac@@ -120,15 +120,7 @@ if test "x$guix_build_daemon" = "xyes"; then dnl Determine the appropriate default list of substitute URLs (GnuTLS dnl is required so we can default to 'https'.)- case "x$host_cpu" in- xaarch64)- # Currently only berlin.guixsd.org provides aarch64 binaries.- guix_substitute_urls="https://berlin.guixsd.org"- ;;- *)- guix_substitute_urls="https://mirror.hydra.gnu.org"- ;;- esac+ guix_substitute_urls="https://ci.guix.info" AC_MSG_CHECKING([for default substitute URLs]) AC_MSG_RESULT([$guix_substitute_urls])diff --git a/doc/guix.texi b/doc/guix.texiindex d96c35eace..a5ae1c65e6 100644--- a/doc/guix.texi+++ b/doc/guix.texi@@ -14,7 +14,7 @@ @set KEY-SERVER pool.sks-keyservers.net @c The official substitute server used by default.-@set SUBSTITUTE-SERVER ci.guix.info+@set SUBSTITUTE-SERVER mirror.hydra.gnu.org @copying Copyright @copyright{} 2012, 2013, 2014, 2015, 2016, 2017, 2018 Ludovic Courtès@*@@ -2374,14 +2374,9 @@ Then, you can run something like this: @end example @quotation Note-Similarly, the @file{berlin.guixsd.org.pub} file contains the public key-for the project's new build farm, reachable at-@indicateurl{https://berlin.guixsd.org}.--As of this writing @code{berlin.guixsd.org} is being upgraded so it can-better scale up, but you might want to give it a try. It is backed by-20 x86_64/i686 build nodes and may be able to provide substitutes more-quickly than @code{mirror.hydra.gnu.org}.+Similarly, the @file{hydra.gnu.org.pub} file contains the public key+of an independent build farm also run by the project, reachable at+@indicateurl{https://mirror.hydra.gnu.org}. @end quotation Once this is in place, the output of a command like @code{guix build}diff --git a/guix/scripts/build.scm b/guix/scripts/build.scmindex 5532c65eb6..0b7da3189e 100644--- a/guix/scripts/build.scm+++ b/guix/scripts/build.scm@@ -65,7 +65,7 @@ (define %default-log-urls ;; Default base URLs for build logs.- '("http://hydra.gnu.org/log"))+ '("http://ci.guix.info/log")) ;; XXX: The following procedure cannot be in (guix store) because of the ;; dependency on (guix derivations).diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scmindex eb82224016..d6dc9b6448 100755--- a/guix/scripts/substitute.scm+++ b/guix/scripts/substitute.scm@@ -1052,7 +1052,7 @@ found." (#f ;; This can only happen when this script is not invoked by the ;; daemon.- '("http://hydra.gnu.org"))))+ '("http://ci.guix.info")))) (define substitute-urls ;; List of substitute URLs.diff --git a/guix/store.scm b/guix/store.scmindex 9dc651b26c..509fd4def6 100644--- a/guix/store.scm+++ b/guix/store.scm@@ -693,7 +693,7 @@ encoding conversion errors." (map (if (false-if-exception (resolve-interface '(gnutls))) (cut string-append "https://" <>) (cut string-append "http://" <>))- '("mirror.hydra.gnu.org")))+ '("ci.guix.info"))) (define* (set-build-options server #:key keep-failed? keep-going? fallback?-- 2.19.2
L
L
Ludovic Courtès wrote on 3 Dec 2018 16:53
[PATCH 1/3] etc: Add "ci.guix.info.pub" public key file.
(address . 33600@debbugs.gnu.org)
20181203155335.10629-1-ludo@gnu.org
* etc/substitutes/ci.guix.info.pub: New file.* Makefile.am (dist_pkgdata_DATA): Add it.* guix/self.scm (miscellaneous-files): Add"share/guix/ci.guix.info.pub".--- Makefile.am | 3 ++- etc/substitutes/ci.guix.info.pub | 1 + guix/self.scm | 3 +++ 3 files changed, 6 insertions(+), 1 deletion(-) create mode 120000 etc/substitutes/ci.guix.info.pub
Toggle diff (38 lines)diff --git a/Makefile.am b/Makefile.amindex 32cebd5917..6803666a57 100644--- a/Makefile.am+++ b/Makefile.am@@ -459,7 +459,8 @@ check-system: $(GOBJECTS) # Public key used to sign substitutes from hydra.gnu.org & co. dist_pkgdata_DATA = \ etc/substitutes/hydra.gnu.org.pub \- etc/substitutes/berlin.guixsd.org.pub+ etc/substitutes/berlin.guixsd.org.pub \+ etc/substitutes/ci.guix.info.pub # Bash completion file. dist_bashcompletion_DATA = etc/completion/bash/guix \diff --git a/etc/substitutes/ci.guix.info.pub b/etc/substitutes/ci.guix.info.pubnew file mode 120000index 0000000000..b1d1e4d763--- /dev/null+++ b/etc/substitutes/ci.guix.info.pub@@ -0,0 +1 @@+berlin.guixsd.org.pub\ No newline at end of filediff --git a/guix/self.scm b/guix/self.scmindex 8476c422ec..f2db3dbf52 100644--- a/guix/self.scm+++ b/guix/self.scm@@ -428,6 +428,9 @@ load path." ,(file-append* source "/etc/substitutes/hydra.gnu.org.pub")) ("share/guix/berlin.guixsd.org.pub"+ ,(file-append* source+ "/etc/substitutes/berlin.guixsd.org.pub"))+ ("share/guix/ci.guix.info.pub" ;alias ,(file-append* source "/etc/substitutes/berlin.guixsd.org.pub"))))) (define* (whole-package name modules dependencies-- 2.19.2
L
L
Ludovic Courtès wrote on 3 Dec 2018 16:53
[PATCH 2/3] Remove most references to hydra.gnu.org.
(address . 33600@debbugs.gnu.org)
20181203155335.10629-2-ludo@gnu.org
* Makefile.am (assert-binaries-available): Don't mention hydra.gnu.orgin comment.* build-aux/check-available-binaries.scm: Likewise.* build-aux/check-final-inputs-self-contained.scm: Likewise.* doc/guix.texi (SUBSTITUTE-SERVER): New variable.Use it throughout instead of "mirror.hydra.gnu.org".* doc/contributing.texi (Submitting Patches): Likewise.* gnu/services/base.scm (hydra-key-authorization)(guix-activation): Remove mentions of "hydra.gnu.org" in comments andmessages.* gnu/system/install.scm (%installation-services): Likewise.* guix/scripts/size.scm (guix-size): Likewise.--- Makefile.am | 2 +- build-aux/check-available-binaries.scm | 4 +- .../check-final-inputs-self-contained.scm | 2 +- doc/contributing.texi | 2 +- doc/guix.texi | 56 ++++++++++--------- gnu/services/base.scm | 4 +- gnu/system/install.scm | 2 +- guix/scripts/size.scm | 2 +- 8 files changed, 38 insertions(+), 36 deletions(-)
Toggle diff (310 lines)diff --git a/Makefile.am b/Makefile.amindex 6803666a57..a7a67e81cf 100644--- a/Makefile.am+++ b/Makefile.am@@ -763,7 +763,7 @@ assert-no-store-file-names: $(distdir)/ChangeLog exit 1 ; \ fi -# Make sure hydra.gnu.org has the important binaries.+# Make sure important substitutes are available. assert-binaries-available: $(GOBJECTS) $(AM_V_at)$(top_builddir)/pre-inst-env "$(GUILE)" \ "$(top_srcdir)/build-aux/check-available-binaries.scm"diff --git a/build-aux/check-available-binaries.scm b/build-aux/check-available-binaries.scmindex b832d99935..c80db1a37e 100644--- a/build-aux/check-available-binaries.scm+++ b/build-aux/check-available-binaries.scm@@ -1,5 +1,5 @@ ;;; GNU Guix --- Functional package management for GNU-;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>+;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2018 Ludovic Courtès <ludo@gnu.org> ;;; ;;; This file is part of GNU Guix. ;;;@@ -17,7 +17,7 @@ ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. ;;;-;;; Check whether important binaries are available at hydra.gnu.org.+;;; Check whether important binaries are available. ;;; (use-modules (guix store)diff --git a/build-aux/check-final-inputs-self-contained.scm b/build-aux/check-final-inputs-self-contained.scmindex 37dc883d3c..c819086508 100644--- a/build-aux/check-final-inputs-self-contained.scm+++ b/build-aux/check-final-inputs-self-contained.scm@@ -17,7 +17,7 @@ ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. ;;;-;;; Check whether important binaries are available at hydra.gnu.org.+;;; Check whether important binaries are available. ;;; (use-modules (guix store)diff --git a/doc/contributing.texi b/doc/contributing.texiindex 7417f28d14..c55eb63382 100644--- a/doc/contributing.texi+++ b/doc/contributing.texi@@ -443,7 +443,7 @@ as timestamps or randomly-generated output in the build result. Another option is to use @command{guix challenge} (@pxref{Invoking guix challenge}). You may run it once the package has been committed and-built by @code{hydra.gnu.org} to check whether it obtains the same+built by @code{@value{SUBSTITUTE-SERVER}} to check whether it obtains the same result as you did. Better yet: Find another machine that can build it and run @command{guix publish}. Since the remote build machine is likely different from yours, this can catch non-determinism issuesdiff --git a/doc/guix.texi b/doc/guix.texiindex b0aa5aa872..d96c35eace 100644--- a/doc/guix.texi+++ b/doc/guix.texi@@ -13,6 +13,9 @@ @set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 @set KEY-SERVER pool.sks-keyservers.net +@c The official substitute server used by default.+@set SUBSTITUTE-SERVER ci.guix.info+ @copying Copyright @copyright{} 2012, 2013, 2014, 2015, 2016, 2017, 2018 Ludovic Courtès@* Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@*@@ -1274,8 +1277,7 @@ remote procedure call (@pxref{The Store}). @anchor{daemon-substitute-urls} Consider @var{urls} the default whitespace-separated list of substitute source URLs. When this option is omitted,-@indicateurl{https://mirror.hydra.gnu.org https://hydra.gnu.org} is used-(@code{mirror.hydra.gnu.org} is a mirror of @code{hydra.gnu.org}).+@indicateurl{https://@value{SUBSTITUTE-SERVER}} is used. This means that substitutes may be downloaded from @var{urls}, as long as they are signed by a trusted signature (@pxref{Substitutes}).@@ -2321,7 +2323,7 @@ also result from derivation builds, can be available as substitutes. @cindex hydra @cindex build farm-The @code{mirror.hydra.gnu.org} server is a front-end to an official build farm+The @code{@value{SUBSTITUTE-SERVER}} server is a front-end to an official build farm that builds packages from Guix continuously for some architectures, and makes them available as substitutes. This is the default source of substitutes; it can be overridden by passing the@@ -2353,22 +2355,22 @@ other substitute server. @cindex substitutes, authorization thereof @cindex access control list (ACL), for substitutes @cindex ACL (access control list), for substitutes-To allow Guix to download substitutes from @code{hydra.gnu.org} or a+To allow Guix to download substitutes from @code{@value{SUBSTITUTE-SERVER}} or a mirror thereof, you must add its public key to the access control list (ACL) of archive imports, using the @command{guix archive} command (@pxref{Invoking guix-archive}). Doing so implies that you trust @code{hydra.gnu.org} to not+archive}). Doing so implies that you trust @code{@value{SUBSTITUTE-SERVER}} to not be compromised and to serve genuine substitutes. -The public key for @code{hydra.gnu.org} is installed along with Guix, in-@code{@var{prefix}/share/guix/hydra.gnu.org.pub}, where @var{prefix} is+The public key for @code{@value{SUBSTITUTE-SERVER}} is installed along with Guix, in+@code{@var{prefix}/share/guix/@value{SUBSTITUTE-SERVER}.pub}, where @var{prefix} is the installation prefix of Guix. If you installed Guix from source, make sure you checked the GPG signature of @file{guix-@value{VERSION}.tar.gz}, which contains this public key file. Then, you can run something like this: @example-# guix archive --authorize < @var{prefix}/share/guix/hydra.gnu.org.pub+# guix archive --authorize < @var{prefix}/share/guix/@value{SUBSTITUTE-SERVER}.pub @end example @quotation Note@@ -2409,7 +2411,7 @@ $ guix build emacs --dry-run @end example @noindent-This indicates that substitutes from @code{hydra.gnu.org} are usable and+This indicates that substitutes from @code{@value{SUBSTITUTE-SERVER}} are usable and will be downloaded, when possible, for future builds. @cindex substitutes, how to disable@@ -2501,9 +2503,9 @@ by a server. Today, each individual's control over their own computing is at the mercy of institutions, corporations, and groups with enough power and determination to subvert the computing infrastructure and exploit its-weaknesses. While using @code{hydra.gnu.org} substitutes can be+weaknesses. While using @code{@value{SUBSTITUTE-SERVER}} substitutes can be convenient, we encourage users to also build on their own, or even run-their own build farm, such that @code{hydra.gnu.org} is less of an+their own build farm, such that @code{@value{SUBSTITUTE-SERVER}} is less of an interesting target. One way to help is by publishing the software you build using @command{guix publish} so that others have one more choice of server to download substitutes from (@pxref{Invoking guix publish}).@@ -3658,11 +3660,11 @@ Read a single-item archive as served by substitute servers low-level operation needed in only very narrow use cases; see below. For example, the following command extracts the substitute for Emacs-served by @code{hydra.gnu.org} to @file{/tmp/emacs}:+served by @code{@value{SUBSTITUTE-SERVER}} to @file{/tmp/emacs}: @example $ wget -O - \- https://hydra.gnu.org/nar/@dots{}-emacs-24.5 \+ https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-emacs-24.5 \ | bunzip2 | guix archive -x /tmp/emacs @end example @@ -6683,7 +6685,7 @@ but you are actually on an @code{x86_64} machine: @example $ guix build --log-file gdb -s mips64el-linux-https://hydra.gnu.org/log/@dots{}-gdb-7.10+https://@value{SUBSTITUTE-SERVER}/log/@dots{}-gdb-7.10 @end example You can freely access a huge library of build logs!@@ -8342,7 +8344,7 @@ When @command{guix publish} runs, it spawns an HTTP server which allows anyone with network access to obtain substitutes from it. This means that any machine running Guix can also act as if it were a build farm, since the HTTP interface is compatible with Hydra, the software behind-the @code{hydra.gnu.org} build farm.+the @code{@value{SUBSTITUTE-SERVER}} build farm. For security, each substitute is signed, allowing recipients to check their authenticity and integrity (@pxref{Substitutes}). Because@@ -8579,20 +8581,20 @@ any given store item. The command output looks like this: @smallexample-$ guix challenge --substitute-urls="https://hydra.gnu.org https://guix.example.org"-updating list of substitutes from 'https://hydra.gnu.org'... 100.0%+$ guix challenge --substitute-urls="https://@value{SUBSTITUTE-SERVER} https://guix.example.org"+updating list of substitutes from 'https://@value{SUBSTITUTE-SERVER}'... 100.0% updating list of substitutes from 'https://guix.example.org'... 100.0% /gnu/store/@dots{}-openssl-1.0.2d contents differ: local hash: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q- https://hydra.gnu.org/nar/@dots{}-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q+ https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q https://guix.example.org/nar/@dots{}-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim /gnu/store/@dots{}-git-2.5.0 contents differ: local hash: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha- https://hydra.gnu.org/nar/@dots{}-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f+ https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f https://guix.example.org/nar/@dots{}-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73 /gnu/store/@dots{}-pius-2.1.1 contents differ: local hash: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax- https://hydra.gnu.org/nar/@dots{}-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax+ https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax https://guix.example.org/nar/@dots{}-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs @dots{}@@ -8612,7 +8614,7 @@ the servers obtained a result different from the local build. @cindex non-determinism, in package builds As an example, @code{guix.example.org} always gets a different answer.-Conversely, @code{hydra.gnu.org} agrees with local builds, except in the+Conversely, @code{@value{SUBSTITUTE-SERVER}} agrees with local builds, except in the case of Git. This might indicate that the build process of Git is non-deterministic, meaning that its output varies as a function of various things that Guix does not fully control, in spite of building@@ -8626,14 +8628,14 @@ To find out what is wrong with this Git binary, we can do something along these lines (@pxref{Invoking guix archive}): @example-$ wget -q -O - https://hydra.gnu.org/nar/@dots{}-git-2.5.0 \+$ wget -q -O - https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-git-2.5.0 \ | guix archive -x /tmp/git $ diff -ur --no-dereference /gnu/store/@dots{}-git.2.5.0 /tmp/git @end example This command shows the difference between the files resulting from the local build, and the files resulting from the build on-@code{hydra.gnu.org} (@pxref{Overview, Comparing and Merging Files,,+@code{@value{SUBSTITUTE-SERVER}} (@pxref{Overview, Comparing and Merging Files,, diffutils, Comparing and Merging Files}). The @command{diff} command works great for text files. When binary files differ, a better option is @uref{https://diffoscope.org/, Diffoscope}, a tool that helps@@ -8648,7 +8650,7 @@ In the meantime, @command{guix challenge} is one tool to help address the problem. If you are writing packages for Guix, you are encouraged to check-whether @code{hydra.gnu.org} and other substitute servers obtain the+whether @code{@value{SUBSTITUTE-SERVER}} and other substitute servers obtain the same build result as you did with: @example@@ -11238,14 +11240,14 @@ Number of build user accounts to create. @item @code{authorize-key?} (default: @code{#t}) @cindex substitutes, authorization thereof Whether to authorize the substitute keys listed in-@code{authorized-keys}---by default that of @code{hydra.gnu.org}+@code{authorized-keys}---by default that of @code{@value{SUBSTITUTE-SERVER}} (@pxref{Substitutes}). @vindex %default-authorized-guix-keys @item @code{authorized-keys} (default: @var{%default-authorized-guix-keys}) The list of authorized key files for archive imports, as a list of string-valued gexps (@pxref{Invoking guix archive}). By default, it-contains that of @code{hydra.gnu.org} (@pxref{Substitutes}).+contains that of @code{@value{SUBSTITUTE-SERVER}} (@pxref{Substitutes}). @item @code{use-substitutes?} (default: @code{#t}) Whether to use substitutes.@@ -23747,7 +23749,7 @@ system}. @cindex substituter Users can obtain the new package definition simply by running @command{guix pull} (@pxref{Invoking guix pull}). When-@code{hydra.gnu.org} is done building the package, installing the+@code{@value{SUBSTITUTE-SERVER}} is done building the package, installing the package automatically downloads binaries from there (@pxref{Substitutes}). The only place where human intervention is needed is to review and apply the patch.diff --git a/gnu/services/base.scm b/gnu/services/base.scmindex 228d3c5926..cee9898d79 100644--- a/gnu/services/base.scm+++ b/gnu/services/base.scm@@ -1518,7 +1518,7 @@ public key, with GUIX." (let ((status (cdr (waitpid pid)))) (unless (zero? status) (format (current-error-port) "warning: \-failed to register hydra.gnu.org public key: ~a~%" status))))))))+failed to register public key '~a': ~a~%" key status)))))))) (define %default-authorized-guix-keys ;; List of authorized substitute keys.@@ -1630,7 +1630,7 @@ failed to register hydra.gnu.org public key: ~a~%" status)))))))) ;; otherwise call 'chown' here, but the problem is that on a COW overlayfs, ;; chown leads to an entire copy of the tree, which is a bad idea. - ;; Optionally authorize hydra.gnu.org's key.+ ;; Optionally authorize substitute server keys. (if authorize-key? #~(begin #$@(map (cut hydra-key-authorization <> guix) keys))diff --git a/gnu/system/install.scm b/gnu/system/install.scmindex 45b3a0c839..c345ba0626 100644--- a/gnu/system/install.scm+++ b/gnu/system/install.scm@@ -250,7 +250,7 @@ You have been warned. Thanks for being so brave.\x1b[0m ;; The usual services. (syslog-service) - ;; The build daemon. Register the hydra.gnu.org key as trusted.+ ;; The build daemon. Register the official server keys as trusted. ;; This allows the installation process to use substitutes by ;; default. (guix-service (guix-configuration (authorize-key? #t)))diff --git a/guix/scripts/size.scm b/guix/scripts/size.scmindex 344be40883..25218a2945 100644--- a/guix/scripts/size.scm+++ b/guix/scripts/size.scm@@ -297,7 +297,7 @@ Report the size of PACKAGE and its dependencies.\n")) (leave (G_ "missing store item argument\n"))) ((files ..1) (leave-on-EPIPE- ;; Turn off grafts because (1) hydra.gnu.org does not serve grafted+ ;; Turn off grafts because (1) substitute servers do not serve grafted ;; packages, and (2) they do not make any difference on the ;; resulting size. (parameterize ((%graft? #f))-- 2.19.2
L
L
Ludovic Courtès wrote on 3 Dec 2018 17:12
Using a CDN or some other mirror?
(address . 33600@debbugs.gnu.org)
87tvju6145.fsf@gnu.org
Hello,
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (4 lines)> These patches (actually the last one) switch Guix to default to> <https://ci.guix.info> for substitutes, in preparation for the> upcoming 0.16.0 release (hopefully this week!).
Right now, ci.guix.info points to berlin.guixsd.org, the front-end ofthe build farm hosted at the MDC.
The previous setup was that mirror.hydra.gnu.org mirrors hydra.gnu.org(the actual build farm front-end) using an nginx proxy:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf
This provides a bit of redundancy that we don’t have currently forberlin.
Thus, I’m thinking about using a similar setup, but hosting the mirroron some Big Corp CDN or similar. Chris Marusich came up with a setupalong these lines a while back:
https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00312.html
Compared to Chris’s setup, given that ‘guix publish’ now provides‘Cache-Control’ headers (that was not the case back then, seehttps://lists.gnu.org/archive/html/guix-devel/2016-03/msg00360.html),caching in the proxy should Just Work.
I would like us to set up such a mirror for berlin and then haveci.guix.info point to that. The project should be able to pay thehosting fees.
Thoughts?
Would someone like to get started? You’ll undoubtedly get all theappreciation of each one of us and a beverage of your choice next timewe meet! :-)
Thanks,Ludo’.
R
R
Ricardo Wurmus wrote on 3 Dec 2018 21:44
Re: [PATCH 1/3] etc: Add "ci.guix.info.pub" public key file.
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 33600@debbugs.gnu.org)
87y396gx1e.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (5 lines)> * etc/substitutes/ci.guix.info.pub: New file.> * Makefile.am (dist_pkgdata_DATA): Add it.> * guix/self.scm (miscellaneous-files): Add> "share/guix/ci.guix.info.pub".
LGTM!
-- Ricardo
R
R
Ricardo Wurmus wrote on 3 Dec 2018 21:47
Re: Using a CDN or some other mirror?
(name . Ludovic Courtès)(address . ludo@gnu.org)
87wooqgwx3.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (25 lines)> Hello,>> Ludovic Courtès <ludo@gnu.org> skribis:>>> These patches (actually the last one) switch Guix to default to>> <https://ci.guix.info> for substitutes, in preparation for the>> upcoming 0.16.0 release (hopefully this week!).>> Right now, ci.guix.info points to berlin.guixsd.org, the front-end of> the build farm hosted at the MDC.>> The previous setup was that mirror.hydra.gnu.org mirrors hydra.gnu.org> (the actual build farm front-end) using an nginx proxy:>> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf>> This provides a bit of redundancy that we don’t have currently for> berlin.>> Thus, I’m thinking about using a similar setup, but hosting the mirror> on some Big Corp CDN or similar. Chris Marusich came up with a setup> along these lines a while back:>> https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00312.html
Large ISPs also provide CDN services. I already contacted DeutscheTelekom so that we can compare their CDN offer with the Amazon Cloudfontsetup that Chris has configured.
--Ricardo
M
M
Mark H Weaver wrote on 4 Dec 2018 00:44
Re: [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)
(name . Ludovic Courtès)(address . ludo@gnu.org)
8736re41kp.fsf@netris.org
Hi Ludovic,
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (4 lines)> These patches (actually the last one) switch Guix to default to> <https://ci.guix.info> for substitutes, in preparation for the> upcoming 0.16.0 release (hopefully this week!).
Who owns the guix.info domain? Also, who owns the guixsd.org domain?
Thanks, Mark
R
R
Ricardo Wurmus wrote on 4 Dec 2018 06:55
(name . Mark H Weaver)(address . mhw@netris.org)
87va49hm4d.fsf@elephly.net
Hi Mark,
Toggle quote (8 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> These patches (actually the last one) switch Guix to default to>> <https://ci.guix.info> for substitutes, in preparation for the>> upcoming 0.16.0 release (hopefully this week!).>> Who owns the guix.info domain?
I registered it and offered it to Guix Europe (though we aren’t yetsharing administration of the domain).
--Ricardo
R
R
Ricardo Wurmus wrote on 3 Dec 2018 21:44
Re: [PATCH 2/3] Remove most references to hydra.gnu.org.
(name . Ludovic Courtès)(address . ludo@gnu.org)
87zhtmgx2n.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (13 lines)> * Makefile.am (assert-binaries-available): Don't mention hydra.gnu.org> in comment.> * build-aux/check-available-binaries.scm: Likewise.> * build-aux/check-final-inputs-self-contained.scm: Likewise.> * doc/guix.texi (SUBSTITUTE-SERVER): New variable.> Use it throughout instead of "mirror.hydra.gnu.org".> * doc/contributing.texi (Submitting Patches): Likewise.> * gnu/services/base.scm (hydra-key-authorization)> (guix-activation): Remove mentions of "hydra.gnu.org" in comments and> messages.> * gnu/system/install.scm (%installation-services): Likewise.> * guix/scripts/size.scm (guix-size): Likewise.
This looks good to me.
-- Ricardo
A
A
Andreas Enge wrote on 4 Dec 2018 09:59
Re: [bug#33600] [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)
(name . Mark H Weaver)(address . mhw@netris.org)
20181204085948.GA1690@jurong
On Mon, Dec 03, 2018 at 06:44:43PM -0500, Mark H Weaver wrote:
Toggle quote (2 lines)> Who owns the guix.info domain? Also, who owns the guixsd.org domain?
guixsd.org is owned by the Guix Europe association. guix.info, as far asI know, by Ricardo. Plans are to drop guixsd.org in the long run, and Iwould suggest to transfer guix.info to Guix Europe at the next renewal.
Andreas
L
L
Ludovic Courtès wrote on 4 Dec 2018 10:03
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87bm617jga.fsf@gnu.org
Hello,
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (11 lines)>> Ludovic Courtès <ludo@gnu.org> writes:>>>>> These patches (actually the last one) switch Guix to default to>>> <https://ci.guix.info> for substitutes, in preparation for the>>> upcoming 0.16.0 release (hopefully this week!).>>>> Who owns the guix.info domain?>> I registered it and offered it to Guix Europe (though we aren’t yet> sharing administration of the domain).
Could you make sure several people have access to the administrationinterface?
As for guixsd.org, it was initially owned by Andreas Enge whotransferred it to Guix Europe and also provided credentials to me and Ithink a couple of other people, though I forgot who. Andreas?
We should write all this information down in guix-maintenance.git likewe did for build machines, so people know who to contact in casesomething goes wrong or what to do when someone leaves the project.
Thanks,Ludo’.
A
A
Andreas Enge wrote on 4 Dec 2018 11:08
(name . Ludovic Courtès)(address . ludo@gnu.org)
20181204100807.GA4134@jurong
On Tue, Dec 04, 2018 at 10:03:01AM +0100, Ludovic Courtï¿œs wrote:
Toggle quote (4 lines)> As for guixsd.org, it was initially owned by Andreas Enge who> transferred it to Guix Europe and also provided credentials to me and I> think a couple of other people, though I forgot who. Andreas?
Apart from you, to Ricardo Wurmus, Christopher Baines and Manolis Ragkousis.I am of course happy to share the credentials with more people from theGuix sysadmin group.
Andreas
L
L
Ludovic Courtès wrote on 4 Dec 2018 11:21
Re: [bug#33600] [PATCH 2/3] Remove most references to hydra.gnu.org.
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87mupl6188.fsf@gnu.org
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (17 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> * Makefile.am (assert-binaries-available): Don't mention hydra.gnu.org>> in comment.>> * build-aux/check-available-binaries.scm: Likewise.>> * build-aux/check-final-inputs-self-contained.scm: Likewise.>> * doc/guix.texi (SUBSTITUTE-SERVER): New variable.>> Use it throughout instead of "mirror.hydra.gnu.org".>> * doc/contributing.texi (Submitting Patches): Likewise.>> * gnu/services/base.scm (hydra-key-authorization)>> (guix-activation): Remove mentions of "hydra.gnu.org" in comments and>> messages.>> * gnu/system/install.scm (%installation-services): Likewise.>> * guix/scripts/size.scm (guix-size): Likewise.>> This looks good to me.
Great, pushed!
Ludo’.
Closed
L
L
Ludovic Courtès wrote on 4 Dec 2018 11:28
Re: [bug#33600] [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)
(name . Andreas Enge)(address . andreas@enge.fr)
87in0960ws.fsf@gnu.org
Hello,
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (7 lines)> On Mon, Dec 03, 2018 at 06:44:43PM -0500, Mark H Weaver wrote:>> Who owns the guix.info domain? Also, who owns the guixsd.org domain?>> guixsd.org is owned by the Guix Europe association. guix.info, as far as> I know, by Ricardo. Plans are to drop guixsd.org in the long run, and I> would suggest to transfer guix.info to Guix Europe at the next renewal.
Awesome. I’ve added a file to record that info inguix-maintenance.git. Please feel free to complete it; for instanceit’d be good to know the expiration date of each domain.
Thanks!
Ludo’.
A
A
Andreas Enge wrote on 4 Dec 2018 11:46
(name . Ludovic Courtès)(address . ludo@gnu.org)
20181204104659.GA6125@jurong
On Tue, Dec 04, 2018 at 11:28:51AM +0100, Ludovic Courtès wrote:
Toggle quote (4 lines)> Awesome. I’ve added a file to record that info in> guix-maintenance.git. Please feel free to complete it; for instance> it’d be good to know the expiration date of each domain.
Done for guixsd.org. It expires on January 27. I would be okay to let itrun out if guix.info is sufficiently marketed in the meantime.
Andreas
L
L
Ludovic Courtès wrote on 4 Dec 2018 15:12
(name . Andreas Enge)(address . andreas@enge.fr)
87in091iuz.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (8 lines)> On Tue, Dec 04, 2018 at 11:28:51AM +0100, Ludovic Courtès wrote:>> Awesome. I’ve added a file to record that info in>> guix-maintenance.git. Please feel free to complete it; for instance>> it’d be good to know the expiration date of each domain.>> Done for guixsd.org. It expires on January 27. I would be okay to let it> run out if guix.info is sufficiently marketed in the meantime.
Thanks. I think it’s safer to keep it for a while because there may bemachine referring to berlin.guixsd.org here and there.
Ludo’.
L
L
Ludovic Courtès wrote on 4 Dec 2018 15:14
Re: [PATCH 3/3] build: Default to https://ci.guix.info for substitutes.
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87a7ll1irc.fsf@gnu.org
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (17 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> * doc/guix.texi (SUBSTITUTE-SERVER): Switch to ci.guix.info.> […]>> diff --git a/doc/guix.texi b/doc/guix.texi>> index d96c35eace..a5ae1c65e6 100644>> --- a/doc/guix.texi>> +++ b/doc/guix.texi>> @@ -14,7 +14,7 @@>> @set KEY-SERVER pool.sks-keyservers.net>> >> @c The official substitute server used by default.>> -@set SUBSTITUTE-SERVER ci.guix.info>> +@set SUBSTITUTE-SERVER mirror.hydra.gnu.org>> Is this really correct?
Oops, I must have messed up while preparing the patches.Thanks for the heads-up!
Ludo’.
R
R
Ricardo Wurmus wrote on 3 Dec 2018 21:38
(name . Ludovic Courtès)(address . ludo@gnu.org)
871s6yibw3.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (1 lines)> * doc/guix.texi (SUBSTITUTE-SERVER): Switch to ci.guix.info.
[…]
Toggle quote (11 lines)> diff --git a/doc/guix.texi b/doc/guix.texi> index d96c35eace..a5ae1c65e6 100644> --- a/doc/guix.texi> +++ b/doc/guix.texi> @@ -14,7 +14,7 @@> @set KEY-SERVER pool.sks-keyservers.net> > @c The official substitute server used by default.> -@set SUBSTITUTE-SERVER ci.guix.info> +@set SUBSTITUTE-SERVER mirror.hydra.gnu.org
Is this really correct?
-- Ricardo
C
C
Chris Marusich wrote on 9 Dec 2018 04:33
Re: Using a CDN or some other mirror?
87ftv7l6gy.fsf@gmail.com
Hi everyone,
ludo@gnu.org (Ludovic Courtès) writes:
Toggle quote (19 lines)> Ludovic Courtès <ludo@gnu.org> skribis:>> [...] I’m thinking about using a similar setup, but hosting the mirror> on some Big Corp CDN or similar. Chris Marusich came up with a setup> along these lines a while back:>> https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00312.html>> Compared to Chris’s setup, given that ‘guix publish’ now provides> ‘Cache-Control’ headers (that was not the case back then, see> <https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00360.html>),> caching in the proxy should Just Work.>> I would like us to set up such a mirror for berlin and then have> ci.guix.info point to that. The project should be able to pay the> hosting fees.>> Thoughts?
Regarding DNS, it would be nice if we could use an official GNUsubdomain. If we can't use a GNU subdomain, we should at least makesure we have some kind of DNS auto-renewal set up so that nobody canpoach our domain names. And the operators should take appropriateprecautions when sharing any credentials used for managing it all.
Regarding CDNs, I definitely think it's worth a try! Even Debian isusing CloudFront (cloudfront.debian.net). In fact, email correspondencesuggests that as of 2013, Amazon may even have been paying for it!
https://lists.debian.org/debian-cloud/2013/05/msg00071.html
I wonder if Amazon would be willing to pay for our CloudFrontdistribution if we asked them nicely?
In any case, before deciding to use Amazon CloudFront for ci.guix.info,it would be prudent to estimate the cost. CloudFront, like most AmazonAWS services, is a "pay for what you use" model. The pricing is here:
https://aws.amazon.com/cloudfront/pricing
To accurately estimate the cost, we need to know how many requests weexpect to receive, and how many bytes we expect to transfer out, duringa single month. Do we have information like this for berlin today?
Although I don't doubt that a CDN will perform better than what we havenow, I do think it would be good to measure the performance so that weknow for sure the money spent is actually providing a benefit. It wouldbe nice to have some data before and after to measure how availabilityand performance have changed. Apart from anecdotes, what data do wehave to determine whether performance has improved after introducing aCDN? For example, the following information could be useful:
* Network load on the origin server(s) * Clients' latency to (the addresses pointed to by) ci.guix.info * Clients' throughput while downloading substitutes from ci.guix.info
We don't log or collect client metrics, and that's fine. It could beuseful to add code to Guix to measure things like this when the userasks to do so, but perhaps it isn't necessary. It may be good enough ifpeople just volunteer to manually gather some information and share it.For example, you can define a shell function like this:
Toggle snippet (22 lines)measure_get () {curl -L \ -o /dev/null \ -w "url_effective: %{url_effective}\\n\http_code: %{http_code}\\n\num_connects: %{num_connects}\\n\num_redirects: %{num_redirects}\\n\remote_ip: %{remote_ip}\\n\remote_port: %{remote_port}\\n\size_download: %{size_download} B\\n\speed_download: %{speed_download} B/s\\n\time_appconnect: %{time_appconnect} s\\n\time_connect: %{time_connect} s\\n\time_namelookup: %{time_namelookup} s\\n\time_pretransfer: %{time_pretransfer} s\\n\time_redirect: %{time_redirect} s\\n\time_starttransfer: %{time_starttransfer} s\\n\time_total: %{time_total} s\\n" \"$1"}
See "man curl" for the meaning of each metric.
You can then use this function to measure a substitute download. Here'san example in which I download a large substitute (linux-libre) from oneof my machines in Seattle:
Toggle snippet (19 lines)$ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 2>/dev/nullurl_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19http_code: 200num_connects: 1num_redirects: 0remote_ip: 141.80.181.40remote_port: 443size_download: 69899433 Bspeed_download: 4945831.000 B/stime_appconnect: 0.885277 stime_connect: 0.459667 stime_namelookup: 0.254210 stime_pretransfer: 0.885478 stime_redirect: 0.000000 stime_starttransfer: 1.273994 stime_total: 14.133584 s$
Here, it took 0.459667 - 0.254210 = 0.205457 seconds (about 205 ms) toestablish the TCP connection after the DNS lookup. The averagethroughput was 1924285 bytes per second (about 40 megabits per second,where 1 megabit = 10^6 bits). It seems my connection to berlin isalready pretty good!
We can get more information about latency by using a tool like mtr:
Toggle snippet (7 lines)$ sudo mtr -c 10 --report-wide --tcp -P 443 berlin.guixsd.orgStart: 2018-12-08T16:57:40-0800HOST: localhost.localdomain Loss% Snt Last Avg Best Wrst StDev[... I've omitted the intermediate hops because they aren't relevant ...] 13.|-- 141.80.181.40 0.0% 10 205.0 201.9 194.9 212.8 5.6
My machine's latency to berlin is about 202 ms, which matches what wecalculated above.
For experimentation, I've set up a CloudFront distribution atberlin-mirror.marusich.info that uses berlin.guixsd.org as its originserver. Let's repeat these steps to measure the performance of thedistribution from my machine's perspective (before I did this, I madesure the GET would result in a cache hit by downloading the substituteonce before and verifying that the same remote IP address was used):
Toggle snippet (23 lines)$ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 2>/dev/nullurl_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19http_code: 200num_connects: 1num_redirects: 0remote_ip: 13.32.254.57remote_port: 443size_download: 69899433 Bspeed_download: 9821474.000 B/stime_appconnect: 0.607593 stime_connect: 0.532417 stime_namelookup: 0.511086 stime_pretransfer: 0.608029 stime_redirect: 0.000000 stime_starttransfer: 0.663578 stime_total: 7.117266 s$ sudo mtr -c 10 --report-wide --tcp -P 443 berlin-mirror.marusich.infoStart: 2018-12-08T17:04:48-0800HOST: localhost.localdomain Loss% Snt Last Avg Best Wrst StDev[... I've omitted the intermediate hops because they aren't relevant ...] 14.|-- server-52-84-21-199.sea32.r.cloudfront.net 0.0% 10 19.8 20.3 14.3 28.9 4.9
Establishing the TCP connection took about 21 ms (which matches the mtroutput), and the throughput was about 79 megabits per second. (On thismachine, 100 Mbps is the current link speed, according to dmesg output.)This means that in my case, when using CloudFront the latency is 10xlower, and the throughput (for a cache hit) is 2x higher, than usingberlin.guixsd.org directly!
It would be interesting to see what the performance is for others.
Ricardo Wurmus <rekado@elephly.net> writes:
Toggle quote (4 lines)> Large ISPs also provide CDN services. I already contacted Deutsche> Telekom so that we can compare their CDN offer with the Amazon Cloudfont> setup that Chris has configured.
That's great! There are many CDN services out there. I am unfamiliarwith most of them. It will be good to see how Deutsche Telekom'soffering compares to CloudFront.
FYI, CloudFront has edge locations in the following parts of the world:
https://aws.amazon.com/cloudfront/features/
Hartmut Goebel <hartmut@goebel-consult.de> writes:
Toggle quote (13 lines)> Am 03.12.2018 um 17:12 schrieb Ludovic Courtès:>> Thus, I’m thinking about using a similar setup, but hosting the mirror>> on some Big Corp CDN or similar.>> Isn't this a contradiction: Building a free infrastructure relaying on> servers from some Big Corporation? Let allow the privacy concerns> raising when delivering data via some Big Corporation.>> If delivering "packages" works via static data without requiring any> additional service, we could ask universities to host Guix, too. IMHO> this is a much preferred solution since this is a decentralized publish> infrastructure already in place for many GNU/Linux distributions.
I understand your concern about using a third-party service. However,we wouldn't be using a CDN as a "software substitute", which is one ofthe primary risks of using a web service today:
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
Instead, we would be using a CDN as a performance optimization that istransparent to a Guix user. You seem unsettled by the idea ofentrusting any part of substitute delivery to a third party, butconcretely what risks do you foresee?
Regarding your suggestion to ask universities to host mirrors (really,caching proxies), I think it could be a good idea. As Leo mentioned,the configuration to set up an NGINX caching proxy of Hydra (or berlin)is freely available in maintenance.git. Do you think we could convincesome universities to host caching proxies that just run an NGINX webserver using those configurations?
If we can accomplish that, it may still be helpful. If there isinterest in going down this path, I can explore some possibilities inthe Seattle area. If the university-owned caching proxies are easilydiscoverable (i.e., we list them on the website), then users mightmanually set their substitute URL to point to one that's close by.
Going further, if our DNS provider supports something like "geolocationrouting" for DNS queries, we might even be able to create DNS recordsfor ci.guix.info that point to those universities' caching proxies. Inthis way, when a user resolves ci.guix.info, they would get the addressof a university-owned caching proxy close by. This could have thebenefits of requiring less money than a full-fledged CDN like AmazonCloudFront, and also decentralizing the substitute delivery, while stillremaining transparent to Guix users. However, it would still require usto rely on a third-party DNS service.
For example, Amazon Route 53 provides this sort of geolocation routing:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-geo
I wouldn't be surprised if there are other DNS providers out there whooffer something similar. However, I also wouldn't be surprised if theoverall performance of CloudFront turns out to be better.
"Thompson, David" <dthompson2@worcester.edu> writes:
Toggle quote (11 lines)> If AWS CloudFront is the path chosen, it may be worthwhile to follow> the "infrastructure as code" practice and use CloudFormation to> provision the CloudFront distribution and any other supporting> resources. The benefit is that there would be a record of exactly> *how* the project is using these commercial services and the setup> could be easily reproduced. The timing is interesting here because I> just attended the annual AWS conference on behalf of my employer and> while I was there I felt inspired to write a Guile API for building> CloudFormation "stacks". You can see a small sample of what it does> here: https://gist.github.com/davexunit/db4b9d3e67902216fbdbc66cd9c6413e
Nice! That seems useful. I will have to play with it. I created mydistributions manually using the AWS Management Console, since it'srelatively easy to do. I agree it would be better to practice"infrastructure as code."
On that topic, I've also heard good things about Terraform by HashiCorp,which is available under the Mozilla Public License 2.0:
https://github.com/hashicorp/terraform
Here is a comparison of Terraform and CloudFormation:
https://www.terraform.io/intro/vs/cloudformation.html
I looked briefly into packaging Terraform for Guix. It's written in Go.It seems possible, but I haven't invested enough time yet.
As a final option, since the AWS CLI is already packaged in Guix, wecould just drive CloudFormation or CloudFront directly from the CLI.
Meiyo Peng <meiyo.peng@gmail.com> writes:
Toggle quote (8 lines)> I like the idea of IPFS. We should try it. It would be great if it works> well.>> If at some point we need to setup traditional mirrors like other major> Gnu/Linux distros, I can contact my friends in China to setup mirrors in> several universities. I was a member of LUG@USTC, which provides the> largest FLOSS mirror in China.
IPFS would be neat. So would Gnunet. Heck, even a publicationmechanism using good old BitTorrent would be nice. All of these wouldrequire changes to Guix, I suppose.
A CDN would require no changes to Guix, and that's part of why it's soappealing.
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwMjP0ACgkQ3UCaFdgiRp0CrQ//fg4wLWX9FsZ4N03FuXwKscGFwUjqHic1cxXv9bjygDsHLwzxVaKxYf9tIZ93XHdBwSmsFPn+CUO4jhJ0MetQUumJmUr6XZRLEmS70XBuCh1iHibVj7YhPf3a+jHCmbkjVIHTY2VOiN3tR/pFcmtehn4Uma6ZZ4PZgaRNoxDxLiFEM/Fmv0v+mslVZqGyQmiEC97I67XMFkLvPmB2p0yfJD/oFRtEd0saMLPuFsdrSk2g+OADiUrKIJr+GRgBsBAP9VLqUfzlM5K6GqVQO9917bB93OnCMQz89ak47GQ27FiZZs3toK0QplyFYhXYPofOvb/zyy1qdrlSlhuXUjQXs/v6sa3TMxi1d0XCLcOR551qHie/tu8nQiZUcUxINBrRwkKngjaR0cEKfjLP8cAYoweuljyfe+LqIjFny+vQLEOipLOIzZBir3j3qvl9rjy3McZkQoTy38+fS1ti8jj5TDzpwugpPxU3KpSW/HmZCE+O+IOGaDctWC4mElWnnQNX6+INA7jl4RbYUqSobOV+OHZw1GZXO4YelUMVUBLEftmWXY3Pw/CrSDbYcz5v/WJNVS/Kzc0clsKyBG3OgvAPhXdvmKZi6cQfOgwGUfvCIJC9ONnT81qMIHnBLN5ZSaMduWwkXDxYCyJBVRG+AZEHN0F46eLttsALTkEdrVTbCCA==H3rW-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 9 Dec 2018 14:58
(name . Hartmut Goebel)(address . hartmut@goebel-consult.de)
87pnua244k.fsf@gnu.org
Hi Hartmut,
Hartmut Goebel <hartmut@goebel-consult.de> skribis:
Toggle quote (14 lines)> Am 09.12.2018 um 04:33 schrieb Chris Marusich:>> Instead, we would be using a CDN as a performance optimization that is>> transparent to a Guix user. You seem unsettled by the idea of>> entrusting any part of substitute delivery to a third party, but>> concretely what risks do you foresee?>> I have serious privacy concerns.>> TL;DR: A CDN is a centralized infrastructure, allowing to collect> information about valuable vulnerability information of almost all> Guix-users and -systems. This is might become a thread to freedom of> speech, human rights, democracy and economics. Guix should build on a> decentralized infrastructure.
Heck it would be ironic to find myself arguing in favor of centralizedcommercial services. So I won’t do that. :-)
Clearly, I do understand the concerns you list. As a maintainer, I’mlooking for solutions that can address real problems (availability ofsubstitutes and bandwidth) while not being a threat to our user’sprivacy and security.
The operator of a substitute server (or caching proxy), in general,knows which IPs downloaded vulnerable software. This is the mainthreat.
This can be mitigated by talking to nearby mirrors and not justci.guix.info, a feature we implemented a year ago (seehttps://gnu.org/s/guix/blog/2017/reproducible-builds-a-status-update/),or by using several substitute servers, or by not using (or not alwaysusing) substitutes. Few distros have all these options.
We might also be able to somehow balance requests between several CDNsor mirrors.
But again, medium- to long-term, the goal is to move towards IPFS orGNUnet/Bittorrent. IPFS is attractive because it would probably requireno modifications to ‘guix substitutes’ and only minor changes to ‘guixpublish’ since the IPFS daemon has an HTTP interface.
Toggle quote (17 lines)>> Regarding your suggestion to ask universities to host mirrors (really,>> caching proxies), I think it could be a good idea. As Leo mentioned,>> the configuration to set up an NGINX caching proxy of Hydra (or berlin)>> is freely available in maintenance.git. Do you think we could convince>> some universities to host caching proxies that just run an NGINX web>> server using those configurations?>> The difference is: For a traditional "ftp"-mirror, an organization just> needs to add another source to its existing configuration and administer> to the save way as all other mirrors. Whereas for a caching proxy they> need to change the setup of the web-server and learn how to administer> the cache. This difference might make it difficult to convince> organizations to mirror.>> I could try and ask a few organizations in my area, but I would need> figures for this.
What would you need to know? ‘guix weather’ can provide info aboutstorage size.
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 9 Dec 2018 16:59
CDN performance
(name . Chris Marusich)(address . cmmarusich@gmail.com)
871s6qzo6m.fsf_-_@gnu.org
Hello Chris,
Chris Marusich <cmmarusich@gmail.com> skribis:
Toggle quote (6 lines)> Regarding DNS, it would be nice if we could use an official GNU> subdomain. If we can't use a GNU subdomain, we should at least make> sure we have some kind of DNS auto-renewal set up so that nobody can> poach our domain names. And the operators should take appropriate> precautions when sharing any credentials used for managing it all.
Agreed.
Regarding the GNU sub-domain, as I replied to Meiyo, I’m in favor of it,all we need is someone to champion setting it up.
Toggle quote (6 lines)> Regarding CDNs, I definitely think it's worth a try! Even Debian is> using CloudFront (cloudfront.debian.net). In fact, email correspondence> suggests that as of 2013, Amazon may even have been paying for it!>> https://lists.debian.org/debian-cloud/2013/05/msg00071.html
(Note that debian.net is not Debian, and “there’s no cloud, only otherpeople’s computer” as the FSFE puts it.)
Toggle quote (12 lines)> Although I don't doubt that a CDN will perform better than what we have> now, I do think it would be good to measure the performance so that we> know for sure the money spent is actually providing a benefit. It would> be nice to have some data before and after to measure how availability> and performance have changed. Apart from anecdotes, what data do we> have to determine whether performance has improved after introducing a> CDN? For example, the following information could be useful:>> * Network load on the origin server(s)> * Clients' latency to (the addresses pointed to by) ci.guix.info> * Clients' throughput while downloading substitutes from ci.guix.info
Note that performance is one aspect; another one is availability (we’veseen that with the recent hydra.gnu.org outage!). We know we’ll alwayswin in terms of availability by having a CDN in front of our servers.
That said, measuring performance is very useful and it’s great that wecan benefit from your expertise here!
Toggle quote (6 lines)> Here, it took 0.459667 - 0.254210 = 0.205457 seconds (about 205 ms) to> establish the TCP connection after the DNS lookup. The average> throughput was 1924285 bytes per second (about 40 megabits per second,> where 1 megabit = 10^6 bits). It seems my connection to berlin is> already pretty good!
Indeed. The bandwidth problem on berlin is when you’re the first todownload a nar and it’s not been cached by nginx yet. In that case, youget very low bandwidth (like 10 times less than when the item is cachedby nginx.) I’ve looked into it, went as far as strace’ing nginx, butcouldn’t find the reason of this.
Do you any idea?
Toggle quote (7 lines)> Establishing the TCP connection took about 21 ms (which matches the mtr> output), and the throughput was about 79 megabits per second. (On this> machine, 100 Mbps is the current link speed, according to dmesg output.)> This means that in my case, when using CloudFront the latency is 10x> lower, and the throughput (for a cache hit) is 2x higher, than using> berlin.guixsd.org directly!
Impressive.
Toggle quote (2 lines)> It would be interesting to see what the performance is for others.
I’ve tried this from home (in France, with FTTH):
Toggle snippet (34 lines)$ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 2>/dev/nullurl_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19http_code: 200num_connects: 1num_redirects: 0remote_ip: 141.80.181.40remote_port: 443size_download: 69899433 Bspeed_download: 1522001.000 B/stime_appconnect: 0.178892 stime_connect: 0.049649 stime_namelookup: 0.000422 stime_pretransfer: 0.178934 stime_redirect: 0.000000 stime_starttransfer: 0.278312 stime_total: 45.926021 s$ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 2>/dev/nullurl_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19http_code: 200num_connects: 1num_redirects: 0remote_ip: 2600:9000:2116:6e00:c:49d4:5a80:93a1remote_port: 443size_download: 69899433 Bspeed_download: 20803402.000 B/stime_appconnect: 0.552008 stime_connect: 0.482477 stime_namelookup: 0.467598 stime_pretransfer: 0.552157 stime_redirect: 0.000000 stime_starttransfer: 0.735758 stime_total: 3.360500 s
Wall-clock time is less than a tenth; woow.
Thanks for sharing your insight and scripts!
Ludo’.
H
H
Hartmut Goebel wrote on 9 Dec 2018 13:12
Re: Using a CDN or some other mirror?
d870d06a-a95c-2b0b-a196-b5166d50400a@goebel-consult.de
Am 09.12.2018 um 04:33 schrieb Chris Marusich:
Toggle quote (5 lines)> Instead, we would be using a CDN as a performance optimization that is> transparent to a Guix user. You seem unsettled by the idea of> entrusting any part of substitute delivery to a third party, but> concretely what risks do you foresee?
I have serious privacy concerns.
TL;DR: A CDN is a centralized infrastructure, allowing to collectinformation about valuable vulnerability information of almost allGuix-users and -systems. This is might become a thread to freedom ofspeech, human rights, democracy and economics. Guix should build on adecentralized infrastructure.
A distribution provider gets a notion which system is running whichsoftware in which version. In case of guix, the provider even gets theexact version of the software and all its dependencies. Combining thiswith the rise of IPv6, which per default uses the MAC address as part ofthe IP address, actually allows identifying a single system.
This information is extremely valuable for all kinds of attackers as iteases attacking a system a lot. This becomes a thread to
* to opposition members, dissidents and human rights activists as the intelligent agencies can target these persons much more precisely, * to companies all over the world as many countries do industrial espionage.
This becomes even worst when using a CDN, since the CDN is a centralizedsystem: A single CDN provider gains knowledge for almost all systems allover the world. Which means: this valuable vulnerability information iscollected at a single place. Intelligence agencies might be keen ongetting access to this information and a centralized system makes iteasy for them. And there is evidence they actually collect thisinformation [*].
This gets even worse when the CDN belongs to one of these companiescompiling personal profiles, like Google, Facebook or Tencent. Amazonbelongs to this group.
I have the strong opinion that Guix should build on a decentralizedinfrastructure to support keeping the freedom of speech, democracy andhuman rights.
[*] Actually it is known the US-American intelligence agencies haveequipment placed at Verizon to collect all kind of data [1]. One canreason the same is true for other big providers in the US. The USA hasthe FISA act AFAIU enforcing US companies to collaborate in industrialespionage. In Germany it is known that the BND is extracting high-volumedata at the central internet exchange (DE-CIX) [2]. One can reason suchalso happens in other countries, esp. members of the five-eyes, France,Russia, China, Israel, Saudi Arabia, Iran, Irak, etc.
Toggle quote (7 lines)> Regarding your suggestion to ask universities to host mirrors (really,> caching proxies), I think it could be a good idea. As Leo mentioned,> the configuration to set up an NGINX caching proxy of Hydra (or berlin)> is freely available in maintenance.git. Do you think we could convince> some universities to host caching proxies that just run an NGINX web> server using those configurations?
The difference is: For a traditional "ftp"-mirror, an organization justneeds to add another source to its existing configuration and administerto the save way as all other mirrors. Whereas for a caching proxy theyneed to change the setup of the web-server and learn how to administerthe cache. This difference might make it difficult to convinceorganizations to mirror.
I could try and ask a few organizations in my area, but I would needfigures for this.

[1] https://www.bbc.com/news/world-us-canada-23123964or search theinternet for e.g. "cia verizon espionage"[2]https://www.heise.de/newsticker/meldung/Gerichtsurteil-BND-darf-weiterhin-Internet-Knoten-De-CIX-anzapfen-4061494.html[3] https://en.wikipedia.org/wiki/Foreign_Intelligence_Surveillance_Act[4]
-- +++hartmut
| Hartmut Goebel | || hartmut@goebel-consult.de | www.goebel-consult.de |
Attachment: file
M
M
Meiyo Peng wrote on 11 Dec 2018 06:17
Re: CDN performance
(name . Ludovic Courtès)(address . ludo@gnu.org)
874lbk63se.fsf@gmail.com
Hi,
I have changed my mind. I don't care about the domain name of thedefault substitute server any more. I am more worried about the networkspeed within China. While I am writing this email, my computer isdownloading substitutes from ci.guix.info at an average speed of about50kB/s.
After careful thought, I realized the new CDN won't benefit Chinaresidents as planned. Any popular CDN outside China is significantlythrottled by ISP/GFW and the situation is worse every year. A CDN willbe a great improvement for western countries but not for many asiacountries.
I have been running a nginx caching mirror at home since the first timeI met guix. My first attempt to install guix took me one afternoon andone night. Most of the time was wasted on downloading substitutes. Afterthat, I searched online and found the nginx mirror configuration inguix/maintenance.git. Then I set up my own caching mirror. It would beextremely painful for me to play with guix during these months withoutthis caching mirror. Debian was my favorite GNU/Linux distro before Idiscovered Guix. It usually costs me only 30 minutes to install Debianfrom scratch. Other GNU/Linux distros are about the same. If guix takesmore than 5 hours to install, most new users will be scared away.
Although now there are only a few Chinese guix users, I still prefer toset up a caching mirror within China. The user experience improvementwill be significant. Like Hartmut Goebel described, I need informationabout "expected storage demand, expected transfer traffic from upstream,how often updates are published, how long to hold copies" so I can writea proposal to maintainers of mirrors.ustc.edu.cn to add a new mirror forguix. I tried the `guix weather` command, but it failed with an error:
#+BEGIN_EXAMPLE computing 8,821 package derivations for x86_64-linux... guix weather: error: lstat: No such file or directory: "/src/config/packages/patches/libjxr-add-cmakelists-file.patch"#+END_EXAMPLE
Can anyone provide the numbers for me? The numbers ofmirror.hydra.gnu.org would be a good reference.
In addition, I think we should put up a page on guix's website providinginformation about available substitute servers including address,backend build farm, geolocation, maintainer, so users (many asiaresidents) can pick the best substitute server for themselves. This willbe necessary until alternative solutions like IPFS or GNUnet areimplemented.
This email only describes the situation in China. I don't intend todiscourage you on the CDN plan. There is no conflicts between myproposal to set up a caching mirror in China and our plan to set up anew CDN.
--Meiyo Peng
M
M
Meiyo Peng wrote on 11 Dec 2018 06:59
(name . Zephyr Waitzman)(address . i@wi24rd.ml)
87woog4n9i.fsf@gmail.com
Hi, Zephyr Waitzman <i@wi24rd.ml> writes:
Toggle quote (1 lines)> 大哥你的镜像速度怎么样?可以蹭网吗?(手动滑稽
My caching mirror is at home and it has an ip address of 192.168.x.x. You may connect to it if you have magic power. BTW. Nice to see another Chinese here. What's your experience with the default substitute server? -- Meiyo Peng
M
M
Meiyo Peng wrote on 11 Dec 2018 07:14
(name . Zephyr Waitzman)(address . i@wi24rd.ml)
87pnu84mjw.fsf@gmail.com
Hi, Zephyr Waitzman <i@wi24rd.ml> writes:
Toggle quote (2 lines)> 以前官方的慢死人,最近的话安装靠玄学(找以前邮件列表里的几个 substitude 换着用也就那样吧),偶尔会出一些(感觉不像是网络的)问题。 > 以后有时间再深入学习下。
Thank you for your feedback. That means we do need to set up a caching mirror within China. -- Meiyo Peng
G
G
Giovanni Biscuolo wrote on 11 Dec 2018 17:38
Re: Using a CDN or some other mirror?
8736r4hvcs.fsf@roquette.mug.biscuolo.net
Hi all,
my two cents...
(I can't still help with a public cache, I hope soon...)
Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (6 lines)>> TL;DR: A CDN is a centralized infrastructure, allowing to collect>> information about valuable vulnerability information of almost all>> Guix-users and -systems. This is might become a thread to freedom of>> speech, human rights, democracy and economics. Guix should build on a>> decentralized infrastructure.
I completely agree with you, decentralization is the solution
unfortunately the **only functioning** way is to avoid current Internet,since it's broken (https://youbroketheinternet.org/);I see GuixSD as anintegral part of The Project Map™ https://youbroketheinternet.org/map
...but to fix the situation we need a substantial GNUnet(work) effectand for that we _need_ GuixSD substitutes to be easily and quicklydownloaded (can we avoid this asking potential adopters to be patient orto build?)
maybe we should divide this task in two steps:
1. distributed substitutes: caching servers hosted by a network offriendly institutions and companies donated to GNU/GuixSD, with ahaproxy frontend for geolocated load-balancing [1]
2. decentralized substitutes: caching servers on IPFS or better (sinceit allows complete anonimity) on GNUnet
Toggle quote (3 lines)> Heck it would be ironic to find myself arguing in favor of centralized> commercial services. So I won’t do that. :-)
I see no problems with commercial services, _unfortunately_ nowadaysthis *almost* always means centralized silos, usually exploited forglobal surveillance (since Internet is broken)
[...]
Toggle quote (4 lines)> The operator of a substitute server (or caching proxy), in general,> knows which IPs downloaded vulnerable software. This is the main> threat.
on Internet, and on IPFS? (sorry for the ignorance)
on GNUNet filesharing can be completely anonymous, but the performace isdegraded (so we need a large network effect here)
Toggle quote (9 lines)> This can be mitigated by talking to nearby mirrors and not just> ci.guix.info, a feature we implemented a year ago (see> <https://gnu.org/s/guix/blog/2017/reproducible-builds-a-status-update/>),> or by using several substitute servers, or by not using (or not always> using) substitutes. Few distros have all these options.>> We might also be able to somehow balance requests between several CDNs> or mirrors.
did someone explored an haproxy (with geolocation) solution?
is there a wip-haproxy attempt?
[...]
HTHGiovanni

[1] in the next few weeks I'm going to test an haproxy instance withgeolocated ACLs following this directionshttps:/www.haproxy.com/blog/use-geoip-database-within-haproxy/
-- Giovanni Biscuolo
Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAlwP6AMACgkQ030Op87MORJmUA/8CxtARpNArscx4wpAFv7NWjeqt4eeVX5NArl4N0rKTTz6TobOKY0TMe7u5DCMxJWLzxY4U7qrGf0NLOsdA4O9L290JujVJ4UIaTUT4nlibIb4FQjUMF+2C2nDetHTvcNV4A/v0nqiA67NYeT0fqD13l7AMdqnYCg3iPBhWnCFxWNBlAU4uCGq/e43bUdJ1pqlwYfUGg6vxKZAiun6FIUFWnGDAU46ewTxKzE8z4MEalB5tvWeRRIQwvu9Y7LCyn2+9UjuthkWeYyawNil82z3DwgHJVk8OtBMjyCeqbXThD3Nj90Ix8EVo9NVLDwhqHVchomzDjXj/aRybdRwTRQuQxvwQsGhRXnm2WghWOjsbQ7X92fATIGZtmV3Em0NzqvMfN6VUeuNqBWywtvUbJE91jjRQvqEW7YEsmA1tsf2JuwcdWWF0Lc5VA7nhbWzUHKLEvT1YOZB5oslOCCZDvFHIMMMgFrP1NaddF+kASm9ha5WxfEi4pYS3wgsRk/Vz9vVE9JGZti42Za24RIKv7Ff0+2AJ+/8lUHKSKSTIQdlYd092rPQ4HeF11johFn0XNoHjX5lnOGLyk/rAgEaf8GvfsuPQD8p7m3tz5LLPiIkxBwEe1iZO8VPHD3F2iG7Kv2gRcreZMAxPAD/m0ArW97OLU5WMeHkShvv1dk1/nD/ny8==WG9l-----END PGP SIGNATURE-----
C
C
Chris Marusich wrote on 13 Dec 2018 08:11
Re: CDN performance
(name . Meiyo Peng)(address . meiyo.peng@gmail.com)
877egdyk82.fsf@gmail.com
Meiyo Peng <meiyo.peng@gmail.com> writes:
Toggle quote (6 lines)> After careful thought, I realized the new CDN won't benefit China> residents as planned. Any popular CDN outside China is significantly> throttled by ISP/GFW and the situation is worse every year. A CDN will> be a great improvement for western countries but not for many asia> countries.
Could you try running the measure_get shell function I included in thefollowing email?
https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00192.html
For convenience, here is the definition:
Toggle snippet (22 lines)measure_get () {curl -L \ -o /dev/null \ -w "url_effective: %{url_effective}\\n\http_code: %{http_code}\\n\num_connects: %{num_connects}\\n\num_redirects: %{num_redirects}\\n\remote_ip: %{remote_ip}\\n\remote_port: %{remote_port}\\n\size_download: %{size_download} B\\n\speed_download: %{speed_download} B/s\\n\time_appconnect: %{time_appconnect} s\\n\time_connect: %{time_connect} s\\n\time_namelookup: %{time_namelookup} s\\n\time_pretransfer: %{time_pretransfer} s\\n\time_redirect: %{time_redirect} s\\n\time_starttransfer: %{time_starttransfer} s\\n\time_total: %{time_total} s\\n" \"$1"}
Specifically, I am curious to know what performance you get when you run
measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
from a computer in China. Please be sure to run it two times in a row,to ensure that CloudFront has cached the object.
CloudFront has edge locations in Hong Kong, so I am curious to know whatperformance improvement, if any, you observe.
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwSBh0ACgkQ3UCaFdgiRp1GYg/8DlO2r7vzsG/EZ2W6roDRqEEyIaAcMLr7C2x1Xeu/U9xRuC3DKbfNR2qrxDKmOW4EzknoClEXusKyNH1IrlxHvttGPGpoW8IxacTU1gqZxMjkg3oEn61FQcuITyN3QgITIpea37ohf2D7QhLpzItC5yhALFf39oN98Syv5u07YDqRHOYJHGsOxwC+HsBO+ZDnyIPPxc8qArCj2yUO4+u4ecLradM6ELqnl0jR3mxpAXrsPv+a1D6XTwklWaxpyyJDbPQcTVLs2X6xsoabZBrE1mDI1CNO65gxLmDvNAg+/mBYvtgCXYS8AxDeNzGC3c+nccsXGlHN5drdevv7AG/yyodjY8y9L3ImcaFfeVe6GrftnMeCvFan4ktf3YSZHRvsS0vuQibpqfwrCIP6kslWMgPETWEvcBMRdHlC/ucYZ0a+oLgORPbf79OBY8V2AQKRmFaUa9IgzkvV+Mk8xSt/y/mu6kBpE7iBVpkj4jchnwWoi30FGZH+/uMdeJtfQ2GgeBbCsifs+N5xUCKPtqDDe+l6aUWsgVFJqED4jAOg52XdubvUXgpdkCPGFjg21jjIaWmiykzDgcgYYvMFwxSHpc0w5BNoEqnqcfcSTbMjV6yPOQC7+ks5+ZZ1V1l6ETooNv920YSrcnNnMAESkNgPbBZm5cFIte4bzx5mfneOZHA==h//j-----END PGP SIGNATURE-----
C
C
Chris Marusich wrote on 13 Dec 2018 09:05
(name . Ludovic Courtès)(address . ludo@gnu.org)
87y38tx365.fsf@gmail.com
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (3 lines)> Regarding the GNU sub-domain, as I replied to Meiyo, I’m in favor of it,> all we need is someone to champion setting it up.
I could help with this. Whom should I contact?
Toggle quote (9 lines)>> Regarding CDNs, I definitely think it's worth a try! Even Debian is>> using CloudFront (cloudfront.debian.net). In fact, email correspondence>> suggests that as of 2013, Amazon may even have been paying for it!>>>> https://lists.debian.org/debian-cloud/2013/05/msg00071.html>> (Note that debian.net is not Debian, and “there’s no cloud, only other> people’s computer” as the FSFE puts it.)
I do try to avoid the term "cloud" whenever possible. It's hard toavoid when it's in the product name, though! A wise man once said, "Acloud in the mind is an obstacle to clear thinking." ;-)
You may be right about debian.net. I don't know who owns that domain.It's confusing, since debian.org is definitely owned by the Debianproject, and the following page says they're using Amazon CloudFront:
https://deb.debian.org/
Maybe Debian still uses Amazon CloudFront, or maybe they don't any more.In any case, I've found the following email thread, which documents athoughtful discussion regarding whether or not Debian should use a CDN.They discussed many of the same concerns we're discussing here.
https://lists.debian.org/debian-project/2013/10/msg00029.html
A summary, in the middle of the long thread, is here:
https://lists.debian.org/debian-project/2013/10/msg00074.html
Later, part of the thread broke off and continued here:
https://lists.debian.org/debian-project/2014/02/msg00001.html
That's as far as I've read.
Judging by that email thread, one of the reasons why Debian consideredusing a CDN was because they felt that the cost, in terms of peoplepower, of maintaining their own "proto-CDN" infrastructure had grown toogreat. I believe it! I think it would be ill-advised for the Guixproject to expend effort and capital on building and maintaining its ownCDN. I think it would be wiser to focus on developing a decentralizedsubstitute solution (GNUnet, IPFS, etc.).
That said, I still think that today Guix should provide a third-partyCDN option. For many Guix users, a CDN would improve performance andavailability of substitutes. Contracting with a third party to providethe CDN service would require much less effort and capital than buildingand maintaining a CDN from scratch. This would also enable the projectto focus more on building a decentralized substitute solution. And oncethat decentralized solution is ready, it will be easy to just "turn off"the CDN.
I also understand Hartmut's concerns. The risks he points out arevalid. Because of those risks, even if we make a third-party CDN optionavailable, some people will choose not to use it. For that reason, weshould not require Guix users to use a third-party CDN, just as we donot require them to use substitutes from our build farm.
However, not everyone shares the same threat model. For example,although some people choose not to trust substitutes from our buildfarm, still others do. The choice is based on one's own individualsituation. Similarly, if we make a third-party CDN option available andexplain the risks of using it, Guix users will be able to make aneducated decision for themselves about whether or not to use it.
Toggle quote (14 lines)>> Here, it took 0.459667 - 0.254210 = 0.205457 seconds (about 205 ms) to>> establish the TCP connection after the DNS lookup. The average>> throughput was 1924285 bytes per second (about 40 megabits per second,>> where 1 megabit = 10^6 bits). It seems my connection to berlin is>> already pretty good!>> Indeed. The bandwidth problem on berlin is when you’re the first to> download a nar and it’s not been cached by nginx yet. In that case, you> get very low bandwidth (like 10 times less than when the item is cached> by nginx.) I’ve looked into it, went as far as strace’ing nginx, but> couldn’t find the reason of this.>> Do you any idea?
I made a typo here. The value "1924285" should have been "4945831",which is what measure_get printed. However, the intended result (40Mbps) is still correct.
Actually, I thought 40 megabits per second was pretty great for asingle-threaded file transfer that originated in Europe (I think?) andterminated in Seattle (via my residential Comcast downlink). Irequested that particular file many times before that final test run, soit was probably already cached by nginx.
However, I believe you when you say that it's slow the first time youdownload the substitute from berlin. What path does the data take fromits origin through berlin? If berlin needs to download the initial filefrom another server, perhaps the connection between berlin and thatserver is the bottleneck? Maybe we should discuss that in a differentemail thread, though.
Toggle quote (6 lines)> I’ve tried this from home (in France, with FTTH):>> [...]>> speed_download: 20803402.000 B/s
Wow, that's 166 megabits per second! I'm jealous. :-)
Toggle quote (2 lines)> Wall-clock time is less than a tenth; woow.
I expect others will see similar performance improvements, as long asthey are close to the edge locations provided by Amazon CloudFront andtheir local ISP downlink is fast enough to see a benefit. Again, theedge locations are here:
https://aws.amazon.com/cloudfront/features/
Here's a direct link to their current map:
https://d1.awsstatic.com/global-infrastructure/maps/CloudFront%20Network%20Map%2010.12.18.59e838df2f373247d2efaeb548076e084fd8993e.png
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwSErIACgkQ3UCaFdgiRp2YSw/8CEe20/+GGK08/1cvQz8VKeoDglWValQLJyFNAsuxhEd7W0f+1l5XNRq3PZhQEvwffPWeM7l65HVeJH7fzJPk6RDTS20ifLG9SpOQ9Oeb1ER3QxOWg829rz9gh9G/KUyoPp7KZORQFI87BeGPBPhJdYjHRoZOOraYUdZzRU6Ve7dq5drn4f0salVIZaN7AUs1Qwm18Osv3OEEyFa7uorIM0WpHKtiaYvWORQj/Ly4nz38aoAtSNIwg5juhSZIt2wqjjIVpxjv2IDe7DsNI2j/9cr2ahFkXZje8sKFLOLPtyGQJDpD3VqM/3L7LIhUowY0iqgUoe8L/2u5Nyc+wNFmQ3YNTbKTeOEms0e48gFW96KO42ED5GnA5pUfau1g8o2NusA5jYA0GTFDLPwvSc7Go9PY3j9gWOTurVA4CqPfsxrQ2nCLtkQ7KHbWz6ebD8WCusUAWQAVe+byNJ3dQvluK2ZhYektt8IhN5588Ys191ljVJLZ5mBThKdl/OhyzC7GzGehzvl38ohA/tcBYTA9QTA/xQXtZHnpI6wJXcnVByG//wmhwvoAEo+tNMk4cue+GOGTrbG0sQGQz0iv90IcY0EZVngOXRWqJvPl2cgiwmPbIOq2FSF0DAVTWRo1DKyPtVn2NgrkKARZActkPwpjyHvNeoJFO2r6NwZ1sSfW1bU==kuJA-----END PGP SIGNATURE-----
G
G
Giovanni Biscuolo wrote on 13 Dec 2018 11:41
878t0thfp9.fsf@roquette.mug.biscuolo.net
Hi Chris,
nice to see this discussion, IMHO how GuixSD subsitutes are distributedis a key issue in our ecosystem and is _all_ about privacy and metadata*mass* collection
most "normal users" are not concerned about this so they are fine withsuper-centralization since it's a convenience... not us :-)
personally I've come to GuixSD because I see this project as a key partin liberating me from this class of problems
Chris Marusich <cmmarusich@gmail.com> writes:
[...]
Toggle quote (4 lines)> A summary, in the middle of the long thread, is here:>> https://lists.debian.org/debian-project/2013/10/msg00074.html
thank you for the reference, I've only read this summary
the key part of it IMHO is "Q: Do CDNs raise more security/privacy concerns than our mirrors?"
and the related subthread https://lists.debian.org/debian-project/2013/10/msg00033.html
the quick reply to the above question is: yes, CDNs raise moresecutiry/privacy concerns than "distributed mirrors"
obviuosly "distributed mirrors" _does_ rise some security/privacyconcerns but *centralization*... much more
[...]
Toggle quote (5 lines)> Judging by that email thread, one of the reasons why Debian considered> using a CDN was because they felt that the cost, in terms of people> power, of maintaining their own "proto-CDN" infrastructure had grown too> great.
I'm still new to guixsd but understood enough to se we are much morewell equipped to maintain our distributed network of substitutes cachingservers... **transparently** configured :-)
[...]
Toggle quote (4 lines)> I also understand Hartmut's concerns. The risks he points out are> valid. Because of those risks, even if we make a third-party CDN option> available, some people will choose not to use it.
probably I'll be one of those, I'm considering to maintain a cachingsubstitute server in a "semi-trusted" colocated space and I'd be veryhappy to share that server with the community
[...]
Toggle quote (4 lines)> However, not everyone shares the same threat model. For example,> although some people choose not to trust substitutes from our build> farm, still others do.
for this very reason IMHO we should work towards a network of **verytrusted** build farms directly managed and controlled by the GuixSDproject sysadmins; if build farms will be able to quickly providesubstitutes, caching mirrors will be _much more_ effective than today
... and a network of "automated guix challenge" servers to spotnot-reproducible software in GuixSD
with a solid infrastructure of "scientifically" trustable build farms,there are no reasons not to trust substitutes servers (this impliesworking towards 100% reproducibility of GuixSD)
Toggle quote (5 lines)> The choice is based on one's own individual> situation. Similarly, if we make a third-party CDN option available and> explain the risks of using it, Guix users will be able to make an> educated decision for themselves about whether or not to use it.
that's an option... like a "last resort" in order to be able to useguixSD :-)
we could also teach people how to setup their own caching servers andpossibly share them with the rest of the local community (possibly withsome coordination effort from the project sysadmins)
for Milan I've plans to setup such caching mirror in Jan 2019
[...]
happy hacking!Gio
-- Giovanni Biscuolo
Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAlwSN0MACgkQ030Op87MORK3kw/+LM9TUQ9jT+6nts+h1cW8e5BVZJgtaDVtLsgjikEqmhos6PBow3D3ylPtZ1t68D9eXQrHFY8lTP8Ml149wokHhGGPWyVgF+pwPdDUjkK+nQy8An9hpfxpM6lVfn0gL/FTAsHS/un970pw2RDy/BaeBhTXPOU9EekveBxjnDBv7nsXqX7nnDhnbRUyBO1pzLNiYSo7+9Op5bsmIiDTJibK9TuVIVMSKAzaHs8WtvuYlqlUH1cQDNtNdEG5buaXbJyRgvfTlJ7uSm211JSFu46GCfxDh1Rxo0IX4qqh1AybBTAIj2R6inhJgy4ROni9oTUbc7Fs2xwwn67XVMHx43PSx6gZIQAgr9X898OJM7IogVI476zqwU4B/lwBjsdKunCZNmwugcRO7MNAc0tFTdIw8o6P6hSFe2WS8irhDH+v/3+YGN5lTM336Gux4yiB3EUxjp91Wjw7Sblz3NipmADjovYUUc8mO56MkuDyQasdBIar4qCCjo4ww7sJMAJt0PaJWdwu22wbPfWhXMCHZErrcPS7lVy/OUNPOTgAx2s/7rk18i6hNL1awhFiDCIEDPOKzODyB2g+Pwy1Ormmrr8iEKT5lP8zS4f4byicFrC2cJt+1clggnKN9qw7y5VyZH0j3In7+ZYFdIhkv7YGGRaKujyUnLc3Bg060eBbnVaTNA8==jw02-----END PGP SIGNATURE-----
H
H
Hartmut Goebel wrote on 14 Dec 2018 09:35
Re: Using a CDN or some other mirror?
(name . Ludovic Courtès)(address . ludo@gnu.org)
65fa6be4-3ddc-703b-708d-e223c2474d0b@crazy-compilers.com
Am 09.12.2018 um 14:58 schrieb Ludovic Courtès:
Toggle quote (5 lines)>> I could try and ask a few organizations in my area, but I would need>> figures for this.> What would you need to know? ‘guix weather’ can provide info about> storage size.
I don't know yet, which info the admins need for a decision. FMPOV I'dsays: Disk-space and traffic to be expected.
`guix weather` only provides the disk-space, but even this is notobvious for me:
  13912.1 MiB of nars (compressed)  41176.6 MiB on disk (uncompressed)
From reading the manual, I assume 13.9 GB are required on the server(which is quite a lot IMHO). Is this correct?
-- +++hartmut
| Hartmut Goebel | || hartmut@goebel-consult.de | www.goebel-consult.de |
Attachment: file
P
P
Pierre Neidhardt wrote on 14 Dec 2018 10:02
(name . Hartmut Goebel)(address . h.goebel@crazy-compilers.com)
87tvjgeb12.fsf@ambrevar.xyz
Talking about this, I recently discussed with Ludovic the idea of compressingnars in Lzip instead of gzip.
http://lzip.nongnu.org/lzip.html(benchmark included)
I can work on some Lzip guile-bindings, it should be quite easy, then we couldsave some 10-50% (!!!) disk usage.
-- Pierre Neidhardthttps://ambrevar.xyz/
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlwTcakACgkQm9z0l6S7zH/4QAf/Rn2lKzmd2wFCOMm2Dhr3e5Z507oAZv+6Ci0P7qxG51nW1A5rTQYr31qXr8s++AUgD88nooX8ZtvKv13rkxWkdifnu4iXuwaRM/2FmXTp2NfQ8ZNvQi+/CKrcxbDH8+1o6f0aID0c2EFSxo9eQn73COegujH+PZHHrgpBVHYe9e9ZC/54ACC2m9lAS9u1Bj05TAJBpSxSbhe0wp/j47gn4ealuFHRqXuXRhy/fNMJB2uMS+ZcCL7wv+XY1waYZDYElxrc13HsfCK3OfP8PiMplSTuq3lWYVvHysY/q0mXvTjola5Jdq9Z73KO4BRXLSJg4qBesMnhLiHQVOrdJrAWhQ===zi5X-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 14 Dec 2018 11:26
guix.gnu.org sub-domain
(name . Chris Marusich)(address . cmmarusich@gmail.com)
874lbg76b2.fsf_-_@gnu.org
Hi Chris,
Chris Marusich <cmmarusich@gmail.com> skribis:
Toggle quote (7 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> Regarding the GNU sub-domain, as I replied to Meiyo, I’m in favor of it,>> all we need is someone to champion setting it up.>> I could help with this. Whom should I contact?
We discussed this over the last few days in Paris and Julien (roptat onIRC) volunteered to come up with a Knot service setup for bayfront.scm.When that’s ready, we can contact the FSF sysadmins so they delegate tobayfront.
I’m sure Julien wouldn’t mind getting some help or insight, so please doget in touch!
Ludo’.
L
L
Ludovic Courtès wrote on 14 Dec 2018 11:35
Re: CDN performance
(name . Chris Marusich)(address . cmmarusich@gmail.com)
87pnu45rba.fsf@gnu.org
Hello!
Chris Marusich <cmmarusich@gmail.com> skribis:
Toggle quote (3 lines)> Ludovic Courtès <ludo@gnu.org> writes:

[...]
Toggle quote (30 lines)> Judging by that email thread, one of the reasons why Debian considered> using a CDN was because they felt that the cost, in terms of people> power, of maintaining their own "proto-CDN" infrastructure had grown too> great. I believe it! I think it would be ill-advised for the Guix> project to expend effort and capital on building and maintaining its own> CDN. I think it would be wiser to focus on developing a decentralized> substitute solution (GNUnet, IPFS, etc.).>> That said, I still think that today Guix should provide a third-party> CDN option. For many Guix users, a CDN would improve performance and> availability of substitutes. Contracting with a third party to provide> the CDN service would require much less effort and capital than building> and maintaining a CDN from scratch. This would also enable the project> to focus more on building a decentralized substitute solution. And once> that decentralized solution is ready, it will be easy to just "turn off"> the CDN.>> I also understand Hartmut's concerns. The risks he points out are> valid. Because of those risks, even if we make a third-party CDN option> available, some people will choose not to use it. For that reason, we> should not require Guix users to use a third-party CDN, just as we do> not require them to use substitutes from our build farm.>> However, not everyone shares the same threat model. For example,> although some people choose not to trust substitutes from our build> farm, still others do. The choice is based on one's own individual> situation. Similarly, if we make a third-party CDN option available and> explain the risks of using it, Guix users will be able to make an> educated decision for themselves about whether or not to use it.
That summarizes the situation very well.
In Paris, there was consensus on two things: that a CDN would be helpfulfor performance and availability (though availability could suddenly beworse if we run… out of money), and that it raises privacy concerns.
Based on this, some suggested having a way to opt out of the CDNdistribution: for example, we might make ci.guix.info point to the CDNand also advertise berlin.guixsd.org as a way to bypass it.
Of course in parallel we want to do our best to develop decentralizedsolutions.
Toggle quote (7 lines)> However, I believe you when you say that it's slow the first time you> download the substitute from berlin. What path does the data take from> its origin through berlin? If berlin needs to download the initial file> from another server, perhaps the connection between berlin and that> server is the bottleneck? Maybe we should discuss that in a different> email thread, though.
On the first hit, nginx fetches the file from ‘guix publish’, which isalso on berlin. ‘guix publish’ gets the file from local storage andpasses it with sendfile(2), so it’s as fast as can be.
Thanks for the info!
Ludo’.
L
L
Ludovic Courtès wrote on 14 Dec 2018 15:45
Re: Using a CDN or some other mirror?
(name . Hartmut Goebel)(address . h.goebel@crazy-compilers.com)
87a7l82mmg.fsf@gnu.org
Hello,
Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:
Toggle quote (18 lines)> Am 09.12.2018 um 14:58 schrieb Ludovic Courtès:>>> I could try and ask a few organizations in my area, but I would need>>> figures for this.>> What would you need to know? ‘guix weather’ can provide info about>> storage size.>> I don't know yet, which info the admins need for a decision. FMPOV I'd> says: Disk-space and traffic to be expected.>> `guix weather` only provides the disk-space, but even this is not> obvious for me:>>   13912.1 MiB of nars (compressed)>   41176.6 MiB on disk (uncompressed)>> From reading the manual, I assume 13.9 GB are required on the server> (which is quite a lot IMHO). Is this correct?
If you’re running a caching proxy, you’ll need 13G. However note thatit’s only for one architecture and one revision of Guix. The totalspace needed is obviously a function of time (number of Guix revisionsserved) and number of architectures.
You could choose an expiration time in your caching proxy that satisfiesyour disk space constraints, though.
Our machines that run Cuirass + ‘guix publish --cache’ need roughly41+13G since they contain both /gnu/store and /var/cache/guix/publish.
HTH!
Ludo’.
L
L
Ludovic Courtès wrote on 14 Dec 2018 15:48
Compressing nars with lzip or similar
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
874lbg2mh3.fsf_-_@gnu.org
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
Toggle quote (8 lines)> Talking about this, I recently discussed with Ludovic the idea of compressing> nars in Lzip instead of gzip.>> http://lzip.nongnu.org/lzip.html (benchmark included)>> I can work on some Lzip guile-bindings, it should be quite easy, then we could> save some 10-50% (!!!) disk usage.
That would be sweet!
Though we have to keep in mind that today’s ‘guix substitute’ doesn’tknow about lzip at all (see (guix scripts substitute) and‘call-with-decompressed-port’.) So while lzip would be my preference,we may not be able to use it until we can be sure our users can actuallyunpack it.
Ludo’.
P
P
Pierre Neidhardt wrote on 14 Dec 2018 16:21
(name . Ludovic Courtès)(address . ludo@gnu.org)
878t0sdthe.fsf@ambrevar.xyz
Absolutely, but once the bindings are up and running, it should bestraightforward to update (guix scripts substitute), no?
-- Pierre Neidhardthttps://ambrevar.xyz/
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlwTyn0ACgkQm9z0l6S7zH+zPAf7BkIiDgq7m3duDpfVf3z4wjB9W+9O6+8N7ilk6GEarHzKN7Ed5yfxiKBK8f1/eZPhAQusAmOlucIa5cwed6OgdJg7saYUvwMfG+yDRh2SBRaNr79/ISjRfrm7JqdHFABRZQVUeS4kMjeIcUNH7um1ZICgetV9X3Jb4zZUgq8FiEK39NGSQIeUSn7AcbcLYK5fCzXyHikhiDmbWB/k9Xs7ej8poOFYH0wjLSb6wcYCCuuoEXY8qef+zFHQRvL6t7Y1w5eO6dfxYPHbcgUbsDdSASVpbYsR5J6QPjve1zfJ+7YX0edXSbz1TnZ68LLMlMC3nuznI8l9MpYt2V15zPkp/w===fPIo-----END PGP SIGNATURE-----
M
M
Mark H Weaver wrote on 15 Dec 2018 02:40
Re: CDN performance
(name . Giovanni Biscuolo)(address . g@xelera.eu)
874lbfd0sd.fsf@netris.org
Hi Giovanni,
Giovanni Biscuolo <g@xelera.eu> writes:
Toggle quote (4 lines)> with a solid infrastructure of "scientifically" trustable build farms,> there are no reasons not to trust substitutes servers (this implies> working towards 100% reproducibility of GuixSD)
What does "scientifically trustable" mean?
Mark
P
P
Pierre Neidhardt wrote on 15 Dec 2018 13:17
Re: Compressing nars with lzip or similar
(name . Ludovic Courtès)(address . ludo@gnu.org)
87k1kbrnlq.fsf@ambrevar.xyz
I've done some quick research over the various options.
- lzip: better than gz and bzip2 for sure, possibly better than xz (atleast according to the author).
- plzip: for "parallel lzip". With 4 threads I was able to compressicecat 2.5x faster. It used 5x more memory though. The compressionratio is 1-2% worse.
- lrzip: it would crash whenever I would change the compression level. Seems less stable. It's as fast as plzip, while being 1-2% less compressed. I don't think it's worth using.
All in all, lzip is a definite win over most options. The main questionis: lzip or plzip?
In my opinion it makes more sense to use plzip, gotta put those cores tosome use (on the user side at least)! Not sure what the build farmwould think about this though.
Finally, plzip can be quite memory-intensive. When passed "--threads=1"however, it gets closer to lzip (bit faster, bit more memory). So maybethe ideal would be to support plzip with a user-settable "threads" option.
Thoughts?
--Pierre Neidhardthttps://ambrevar.xyz/
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlwU8MEACgkQm9z0l6S7zH+5owgAhdRMia1xxIiCANu8UorM980EiPuGsTAO/VnnLpleGnQsdfQKjU7SWsk+3aV9B/zHmyyouA902HTQK0h5HxzXfW2QivrZx7RtkOFXnckbvMjt7epT0UzaaK+vE+zjC5o16DmDiRyYdmqttDnSNL4Kp30zawRDwN+IXYaWm3L1cb6qSU7H4UgmbFng80MHofqdU/2Uk042pNwZNQUZPjtIWSX611LJGT7YmrfscyDDBhijXTIjiNaIKa6bTm7Vr7HLN100k3gzPVEBONfrDFMBfOqNHfxy8Y1+79c0eMFqHbvSDKpghxRCrByklhGLOPPKrvH3LWkJHE2MHh/z8pIb5Q===gxzl-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 15 Dec 2018 19:04
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
87tvjey8co.fsf@gnu.org
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
Toggle quote (3 lines)> Absolutely, but once the bindings are up and running, it should be> straightforward to update (guix scripts substitute), no?
Sure! But it will take time before we can assume all our users arerunning it.
Ludo’.
L
L
Ludovic Courtès wrote on 15 Dec 2018 19:06
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
87o99my89u.fsf@gnu.org
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
Toggle quote (16 lines)> I've done some quick research over the various options.>> - lzip: better than gz and bzip2 for sure, possibly better than xz (at> least according to the author).>> - plzip: for "parallel lzip". With 4 threads I was able to compress> icecat 2.5x faster. It used 5x more memory though. The compression> ratio is 1-2% worse.>> - lrzip: it would crash whenever I would change the compression level.> Seems less stable. It's as fast as plzip, while being 1-2% less> compressed. I don't think it's worth using.>> All in all, lzip is a definite win over most options. The main question> is: lzip or plzip?
‘guix publish’ has its own worker pool and handles parallelisminternally, so in that context plain sequential lzip would be moreappropriate IMO.
Ludo’.
C
C
Chris Marusich wrote on 16 Dec 2018 00:20
Re: guix.gnu.org sub-domain
(name . Ludovic Courtès)(address . ludo@gnu.org)
87va3us7gf.fsf@gmail.com
Hi Ludo,
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (3 lines)> I’m sure Julien wouldn’t mind getting some help or insight, so please do> get in touch!
OK, I'll speak privately with Julien about the DNS setup to avoid addingnoise to this email thread.
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwVjEAACgkQ3UCaFdgiRp1F2A/+MaCjKRMoDkdwHe57P8HP1Czh7uYAuzCZNs3H6lFUTr2eXGNYHqH84slxCb+U8RPt9PxrQseGm4C2MakOx1gyttvC45NA3cFoNt0HmZdUa/tlx9non/vQ33R+OcXtMsHMcgeLq/CRZ0vnURIEN4WelKCF6kanFsex7Q6Wg/6P1J1a+Fhomp2yW3TMucpzj81jpkVfXA/M3H7Vms9AeKi9lN8b71PWxmPwqHqmEgQWl1blBPY5JQLSFRTC6Cw/QrHbQ1JEj1A+xffweFR8lobyFEVKVMtjMR0LNAD4YObLsPEH02BTdRd8bnI2zFIdKWprOAHNYTjUCLSBzAg0dFCSfEsppKhlg9tOEzrplYZBG2wwzJIPwr/KTSG+9BSMce0/ok5Mq3i7s+s9m5t88GPdrZWnh3xeTCR5G1XmrPmHqIVFoz8O6k3EbkMKII14ooLaYd1LCB0STsWadUVqJmRPgOoAYi1n5lQSSOZ+1M6FxX7qhmGhOEuwlot38tmlJduzjxr3FNXxt6xh2/GV6xtO5o8FvAex2T1X45Ye+Iq+9SDRM1xgncIXi6iXCdQfcW8iY7DcvgUYvUqP3Za0chGw0shCcCRYGnRG09h9kPTMa+hE2dm8Q/wgFZapaR/XHgFa0sAf3I64ymUXmolRs1DnPN3525UJL2c2+ZqItIL9rV4==Iuh7-----END PGP SIGNATURE-----
M
M
Meiyo Peng wrote on 17 Dec 2018 07:48
Re: CDN performance
(name . Chris Marusich)(address . cmmarusich@gmail.com)
87d0q01wdx.fsf@gmail.com
Hi Chris,
Chris Marusich <cmmarusich@gmail.com> writes:
Toggle quote (46 lines)> Meiyo Peng <meiyo.peng@gmail.com> writes:>>> After careful thought, I realized the new CDN won't benefit China>> residents as planned. Any popular CDN outside China is significantly>> throttled by ISP/GFW and the situation is worse every year. A CDN will>> be a great improvement for western countries but not for many asia>> countries.>> Could you try running the measure_get shell function I included in the> following email?>> https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00192.html>> For convenience, here is the definition:>> measure_get () {> curl -L \> -o /dev/null \> -w "url_effective: %{url_effective}\\n\> http_code: %{http_code}\\n\> num_connects: %{num_connects}\\n\> num_redirects: %{num_redirects}\\n\> remote_ip: %{remote_ip}\\n\> remote_port: %{remote_port}\\n\> size_download: %{size_download} B\\n\> speed_download: %{speed_download} B/s\\n\> time_appconnect: %{time_appconnect} s\\n\> time_connect: %{time_connect} s\\n\> time_namelookup: %{time_namelookup} s\\n\> time_pretransfer: %{time_pretransfer} s\\n\> time_redirect: %{time_redirect} s\\n\> time_starttransfer: %{time_starttransfer} s\\n\> time_total: %{time_total} s\\n" \> "$1"> }>> Specifically, I am curious to know what performance you get when you run>> measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19>> from a computer in China. Please be sure to run it two times in a row,> to ensure that CloudFront has cached the object.>> CloudFront has edge locations in Hong Kong, so I am curious to know what> performance improvement, if any, you observe.
Sorry for the delay. My computer was reinstalled with Windows and takenaway by my girlfriend. So I have been waiting for my new computer that Ibought online to arrive. Finally, it arrived yesterday and Isuccessfully installed Guix on it.
I tested your script several times.
1. Tested today at home. China Unicom home broadband. 50Mb/s.
The result is slow as usual. curl failed once.berlin-mirror.marusich.info is resolved to Seattle, WA, US.
#+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 55 66.6M 55 36.9M 0 0 17926 0 1:04:59 0:36:02 0:28:57 17733 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.151 remote_port: 443 size_download: 38764357 B speed_download: 17926.000 B/s time_appconnect: 6.078850 s time_connect: 3.006821 s time_namelookup: 2.659785 s time_pretransfer: 6.079097 s time_redirect: 0.000000 s time_starttransfer: 9.626001 s time_total: 2162.379211 s curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 109k 0 0:10:25 0:10:25 --:--:-- 241k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 69899433 B speed_download: 111816.000 B/s time_appconnect: 3.507528 s time_connect: 2.650373 s time_namelookup: 2.261801 s time_pretransfer: 3.507637 s time_redirect: 0.000000 s time_starttransfer: 5.995298 s time_total: 625.129571 s
➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 109k 0 0:10:23 0:10:23 --:--:-- 141k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 69899433 B speed_download: 112187.000 B/s time_appconnect: 2.280972 s time_connect: 1.407197 s time_namelookup: 1.056180 s time_pretransfer: 2.281234 s time_redirect: 0.000000 s time_starttransfer: 3.167703 s time_total: 623.061584 s#+END_EXAMPLE

2. Tested 3 days ago at my office. China Telecom enterprise broadband. 50Mb/s.
Unusually fast! berlin-mirror.marusich.info is resolved to Seattle, WA,US. I have no idea why it's so fast that day.
#+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 1364k 0 0:00:50 0:00:50 --:--:-- 1352k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.109 remote_port: 443 size_download: 69899433 B speed_download: 1397429.000 B/s time_appconnect: 2.432387 s time_connect: 0.200842 s time_namelookup: 0.000446 s time_pretransfer: 2.432659 s time_redirect: 0.000000 s time_starttransfer: 2.673045 s time_total: 50.020945 s
➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 1592k 0 0:00:42 0:00:42 --:--:-- 2506k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.109 remote_port: 443 size_download: 69899433 B speed_download: 1630687.000 B/s time_appconnect: 0.653270 s time_connect: 0.209455 s time_namelookup: 0.001582 s time_pretransfer: 0.658399 s time_redirect: 0.000000 s time_starttransfer: 0.883126 s time_total: 42.865868 s#+END_EXAMPLE

3. Tested today at my office. China Telecom enterprise broadband. 50Mb/s.
Slow as usual. berlin-mirror.marusich.info is still resolved to Seattle,WA, US. I killed the program several times because it hung there with nodata transfer for a few minutes. The TCP connection was probably closedby GFW. This is very common here.
#+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 48110 0 0:24:12 0:24:12 --:--:-- 41808 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.151 remote_port: 443 size_download: 69899433 B speed_download: 48110.000 B/s time_appconnect: 0.872926 s time_connect: 0.282048 s time_namelookup: 0.000524 s time_pretransfer: 0.873099 s time_redirect: 0.000000 s time_starttransfer: 1.187467 s time_total: 1452.904154 s
➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 2 66.6M 2 1809k 0 0 5760 0 3:22:15 0:05:21 3:16:54 0^C%
➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 52 66.6M 52 34.9M 0 0 16772 0 1:09:27 0:36:26 0:33:01 0^C%
➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 58181 0 0:20:01 0:20:01 --:--:-- 87975 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 69899433 B speed_download: 58181.000 B/s time_appconnect: 2.297713 s time_connect: 1.904176 s time_namelookup: 1.727602 s time_pretransfer: 2.297974 s time_redirect: 0.000000 s time_starttransfer: 2.503263 s time_total: 1201.408929 s#+END_EXAMPLE

Well. As you see, the network in China is both slow and unstable.
G
G
Giovanni Biscuolo wrote on 19 Dec 2018 13:40
(name . Mark H Weaver)(address . mhw@netris.org)
87imzpd70s.fsf@roquette.mug.biscuolo.net
Hi Mark,
sorry for the late reply
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (7 lines)> Giovanni Biscuolo <g@xelera.eu> writes:>> with a solid infrastructure of "scientifically" trustable build farms,>> there are no reasons not to trust substitutes servers (this implies>> working towards 100% reproducibility of GuixSD)>> What does "scientifically trustable" mean?
I'm still not able to elaborate on that (working on it, a sort ofself-research-hack project) but I'm referencing to this message relatedto reduced bootstrap tarballs:
https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00347.html
and the related reply by Jeremiah (unfortunately cannot find it inarchives, Message-ID: <877eh81tm4.fsf@ITSx01.pdp10.guru>)
in particular Jeremiah replied this:
Toggle snippet (9 lines)> so, if I don't get it wrong, every skilled engineer will be able to> build an "almost analogic" (zero bit of software preloaded) computing> machine ad use stage0/mes [1] as the "metre" [2] to calibrate all other> computing machines (thanks to reproducible builds)?
well, I haven't thought of it in those terms but yes I guess that is oneof the properties of the plan.
and
Toggle snippet (7 lines)> so, having the scientific proof that binary conforms to source, there> will be noo need to trust (the untrastable)
Well, that is what someone else could do with it but not a direct goalof the work.
maybe a more correct definition of the above "scientific proof" should be"mathematical proof"
I lack the theoretical basis to be more precise now, sorry :-S
a marketing-like campaign sould be "no more trusting trust"
best regardsGiovanni
-- Giovanni Biscuolo
Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAlwaPDMACgkQ030Op87MORLmMhAA3wY2DoFzwN39wWQuqUV4PKTMl9B+9hWl6MjL7J4tPsBWkgXn1QvjOF11Fs7aX3kZ3swDhcfXR6DL9zj8ZmZplp0AqbLVuB+31Nvyy3kjFiW38XWlv65z7XCi9AxXHndI3IxMEbVXk0v8Vjo7R4fj9n9tmV1Vw6nnv/n3FcAusrZRF9fH0lQrd/Su8tL/30CLuLNBJWj5xxrV6HRmvki4Jdn8G/IqNAAj0mFS2XN0zYCNf+NlmXkd/GmjhTMpxiWRtJiGXCQEzElPZjiOw/Ce48oCqjvsCsQa5a5JY2gLp7LM8tWA/Uqo5NrC5kuCL6Oe/izl2tex9pOMKO/wVct0bCTPLNjOJUQaUIS13V4H7yf8VhwK6Nq2KV+KwdqKmegWvaDO1jXuHBRbW8L1HXxD1YvUUrn7rXVd/DTGPeltyI38wDG6Z3L33SligelYo3ZC7Ia3ZtER/75sCKXqUSzBSPGbzztC6W6AsUtun8S9ofk3N5lZx4M3dssLVHb2QZtLIlkU5OMWhaKrz+szM1SQGMBYD0xoe9t3qZgUrdq78M1Yeo+qFOd3vWbA2g7CWAx8ah9sPAC5MZiojF2OqMhRCuYSUJ/ene0ukQgr10+lY3ZunOx6bNFyJQiRNpQQFbwCfYfPCtlibrv2+QGxG38MI65WMnu+Kyc74eJTR0HtqWE==RMw8-----END PGP SIGNATURE-----
M
M
Mark H Weaver wrote on 21 Dec 2018 01:23
Trustworthiness of build farms (was Re: CDN performance)
(name . Giovanni Biscuolo)(address . g@xelera.eu)
87fturwwup.fsf_-_@netris.org
Hi Giovanni,
Giovanni Biscuolo <g@xelera.eu> writes:
Toggle quote (40 lines)> Mark H Weaver <mhw@netris.org> writes:>>> Giovanni Biscuolo <g@xelera.eu> writes:>>> with a solid infrastructure of "scientifically" trustable build farms,>>> there are no reasons not to trust substitutes servers (this implies>>> working towards 100% reproducibility of GuixSD)>>>> What does "scientifically trustable" mean?>> I'm still not able to elaborate on that (working on it, a sort of> self-research-hack project) but I'm referencing to this message related> to reduced bootstrap tarballs:>> https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00347.html>> and the related reply by Jeremiah (unfortunately cannot find it in> archives, Message-ID: <877eh81tm4.fsf@ITSx01.pdp10.guru>)>> in particular Jeremiah replied this:>>> so, if I don't get it wrong, every skilled engineer will be able to>> build an "almost analogic" (zero bit of software preloaded) computing>> machine ad use stage0/mes [1] as the "metre" [2] to calibrate all other>> computing machines (thanks to reproducible builds)?>> well, I haven't thought of it in those terms but yes I guess that is one> of the properties of the plan.>>> and>>> so, having the scientific proof that binary conforms to source, there>> will be noo need to trust (the untrastable)>> Well, that is what someone else could do with it but not a direct goal> of the work.>> maybe a more correct definition of the above "scientific proof" should be> "mathematical proof"
I agree that a mathematical proof is what we should be aiming for, andthe only kind of proof that I could trust in, in this scenario.
However, it's important to note several caveats:
* A mathematical proof showing that the binary conforms to the source requires a proof of correctness of the language implementation, which in turn requires formal semantics for both the source language and the underlying machine code. As far as I know, the current bootstrappable.org effort does not include anything like this. Existing projects that provide this include CakeML and Jitawa.
* One must assume that the hardware behaves according to its formal specification. The veracity of this assumption is not something we can currently verify, and even if we could, it would be invalidated if someone gained physical access to the machine and modified it.
* The hardware initialization program (e.g. coreboot) and the kernel used to perform the bootstrap must still be trusted, and unless I'm mistaken, the bootstrappable.org effort does not currently address these issues.
* The software running on the substitute servers could be compromised by stealing SSH keys from someone with root access.
* If the private signing key of the substitute server can be stolen, e.g. by gaining physical access to the machine for a short time, then a man-in-the-middle can deliver to users compromised binaries that appear to come from the substitute server itself.
* Not only the substitute server, but also all of its build slaves, must be trusted as well.
So, while I certainly agree that it will be a *major* improvement toavoid the need to blindly trust precompiled bootstrap binaries, weshould be clear that the current efforts fall far short of a proof, andthere still remain several valid reasons not to place one's trust insubstitute servers.
Does that make sense?
Regards, Mark
C
C
Chris Marusich wrote on 21 Dec 2018 11:22
Re: CDN performance
(name . Meiyo Peng)(address . meiyo.peng@gmail.com)
87o99f9o2t.fsf@gmail.com
Hi Meiyo,
Thank you for sharing this information with us!
Can you also share what numbers you get when you run measure_get againstberlin.guixsd.org directly? Clearly, the connection from you toCloudFront is not as performant as it is for others in other parts ofthe world, but I wonder if it's still better than accessing berlindirectly. If you could run measure_get against berlin directly andshare the numbers, we can see if it represents any significantimprovement for you.
Meiyo Peng <meiyo.peng@gmail.com> writes:
Toggle quote (7 lines)> I tested your script several times.>> 1. Tested today at home. China Unicom home broadband. 50Mb/s.>> The result is slow as usual. curl failed once.> berlin-mirror.marusich.info is resolved to Seattle, WA, US.
Well, that's not great. Perhaps it's still better than it would be ifthe DNS name resolved to a location in Europe, though.
Toggle quote (22 lines)> #+BEGIN_EXAMPLE> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 55 66.6M 55 36.9M 0 0 17926 0 1:04:59 0:36:02 0:28:57 17733> url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> http_code: 200> num_connects: 1> num_redirects: 0> remote_ip: 52.85.158.151> remote_port: 443> size_download: 38764357 B> speed_download: 17926.000 B/s> time_appconnect: 6.078850 s> time_connect: 3.006821 s> time_namelookup: 2.659785 s> time_pretransfer: 6.079097 s> time_redirect: 0.000000 s> time_starttransfer: 9.626001 s> time_total: 2162.379211 s> curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
I see, this is about 143 Kbps (not Mbps) of throughput, and 347 ms afterDNS name resolution.
Toggle quote (41 lines)> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 100 66.6M 100 66.6M 0 0 109k 0 0:10:25 0:10:25 --:--:-- 241k> url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> http_code: 200> num_connects: 1> num_redirects: 0> remote_ip: 52.85.158.22> remote_port: 443> size_download: 69899433 B> speed_download: 111816.000 B/s> time_appconnect: 3.507528 s> time_connect: 2.650373 s> time_namelookup: 2.261801 s> time_pretransfer: 3.507637 s> time_redirect: 0.000000 s> time_starttransfer: 5.995298 s> time_total: 625.129571 s>> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 100 66.6M 100 66.6M 0 0 109k 0 0:10:23 0:10:23 --:--:-- 141k> url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> http_code: 200> num_connects: 1> num_redirects: 0> remote_ip: 52.85.158.22> remote_port: 443> size_download: 69899433 B> speed_download: 112187.000 B/s> time_appconnect: 2.280972 s> time_connect: 1.407197 s> time_namelookup: 1.056180 s> time_pretransfer: 2.281234 s> time_redirect: 0.000000 s> time_starttransfer: 3.167703 s> time_total: 623.061584 s> #+END_EXAMPLE
897 Kbps, 351 ms after the name lookup.
Toggle quote (26 lines)> 2. Tested 3 days ago at my office. China Telecom enterprise broadband. 50Mb/s.>> Unusually fast! berlin-mirror.marusich.info is resolved to Seattle, WA,> US. I have no idea why it's so fast that day.>> #+BEGIN_EXAMPLE> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 100 66.6M 100 66.6M 0 0 1364k 0 0:00:50 0:00:50 --:--:-- 1352k> url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> http_code: 200> num_connects: 1> num_redirects: 0> remote_ip: 13.35.20.109> remote_port: 443> size_download: 69899433 B> speed_download: 1397429.000 B/s> time_appconnect: 2.432387 s> time_connect: 0.200842 s> time_namelookup: 0.000446 s> time_pretransfer: 2.432659 s> time_redirect: 0.000000 s> time_starttransfer: 2.673045 s> time_total: 50.020945 s
11 Mbps, 200 ms after the name lookup.
Toggle quote (21 lines)> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 100 66.6M 100 66.6M 0 0 1592k 0 0:00:42 0:00:42 --:--:-- 2506k> url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> http_code: 200> num_connects: 1> num_redirects: 0> remote_ip: 13.35.20.109> remote_port: 443> size_download: 69899433 B> speed_download: 1630687.000 B/s> time_appconnect: 0.653270 s> time_connect: 0.209455 s> time_namelookup: 0.001582 s> time_pretransfer: 0.658399 s> time_redirect: 0.000000 s> time_starttransfer: 0.883126 s> time_total: 42.865868 s> #+END_EXAMPLE
13 Mbps, 208 ms after the name lookup.
Toggle quote (28 lines)> 3. Tested today at my office. China Telecom enterprise broadband. 50Mb/s.>> Slow as usual. berlin-mirror.marusich.info is still resolved to Seattle,> WA, US. I killed the program several times because it hung there with no> data transfer for a few minutes. The TCP connection was probably closed> by GFW. This is very common here.>> #+BEGIN_EXAMPLE> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 100 66.6M 100 66.6M 0 0 48110 0 0:24:12 0:24:12 --:--:-- 41808> url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> http_code: 200> num_connects: 1> num_redirects: 0> remote_ip: 52.85.158.151> remote_port: 443> size_download: 69899433 B> speed_download: 48110.000 B/s> time_appconnect: 0.872926 s> time_connect: 0.282048 s> time_namelookup: 0.000524 s> time_pretransfer: 0.873099 s> time_redirect: 0.000000 s> time_starttransfer: 1.187467 s> time_total: 1452.904154 s
385 Kbps, 282 ms.
Toggle quote (30 lines)> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 2 66.6M 2 1809k 0 0 5760 0 3:22:15 0:05:21 3:16:54 0^C%>> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 52 66.6M 52 34.9M 0 0 16772 0 1:09:27 0:36:26 0:33:01 0^C%>> ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> % Total % Received % Xferd Average Speed Time Time Time Current> Dload Upload Total Spent Left Speed> 100 66.6M 100 66.6M 0 0 58181 0 0:20:01 0:20:01 --:--:-- 87975> url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19> http_code: 200> num_connects: 1> num_redirects: 0> remote_ip: 52.85.158.22> remote_port: 443> size_download: 69899433 B> speed_download: 58181.000 B/s> time_appconnect: 2.297713 s> time_connect: 1.904176 s> time_namelookup: 1.727602 s> time_pretransfer: 2.297974 s> time_redirect: 0.000000 s> time_starttransfer: 2.503263 s> time_total: 1201.408929 s
465 Kbps, 177 ms.
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwcvtoACgkQ3UCaFdgiRp1IGg//Qza4bHAjMAfJGjgsps/Rvw6CjD9cnDd1pImeqKpNohplRu+FX3A8J9B7bjtzJSyX4KbGu4RlPWGq2PlfV3DwR3DXkYBTTPWnRsbXQs5NQ42YABjBP0dwLOTnzBv64nn7LVG46Cf2GTTKCNURB5QQd0Z/wzPaLM48Ij72wBdYlLapDxYdVlldFtFTUW+f8z6UGUfgZZo5FJKzEy1QvrWyHAHgMPn7zteJttTHoltUKw3VWhVfMxePzcVjWL0/zRMLvs1i9HfZqgmrA0fTMa+HPQqtJI0tIGf+ito1Ra62rpXegOcjyVAgsk9Fn4BExTKdIHkWWr/NAKS5HUbiit5RMzHacaWwpe+JnNUEnu9Gsg1/Q6tljf0hok1UHOhrqN3xs7rD5nWVOMBybYeZv5aeK9ZBBa50rYCeziOxluKeL8VGyEDu4Vft4ehDEkzE2rOZ5WYm3DOsigIlnpKrhNSjV9bOV4tSiAMbCNvzLe+wchDn4nqpysvQI1x3GY59hnFKzy+dEr6jQxobS8b1mMDaioVwmn1X8gaYHNMKp2VKs86Fl3pqBeobQgJ/pd2PqAGsTCLtOQ777EknuXw8Wp56CGiT1m4WXgLYcax7N/Scv2GK5FtOfuUVm9zJMIpucCTcksX+7Rk5KvjUXsfpiRU2ySZ7H+lf3AfKZgg8pNKu6vs==JveL-----END PGP SIGNATURE-----
M
M
Meiyo Peng wrote on 21 Dec 2018 17:04
(name . Chris Marusich)(address . cmmarusich@gmail.com)
87y38isw77.fsf@gmail.com
Hi Chris,
Thank you for your patience!
Chris Marusich <cmmarusich@gmail.com> writes:
Toggle quote (8 lines)> Can you also share what numbers you get when you run measure_get against> berlin.guixsd.org directly? Clearly, the connection from you to> CloudFront is not as performant as it is for others in other parts of> the world, but I wonder if it's still better than accessing berlin> directly. If you could run measure_get against berlin directly and> share the numbers, we can see if it represents any significant> improvement for you.
1. Tested today at home. China Unicom home broadband. 50Mb/s.
berlin.guixsd.org:
#+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 54 66.6M 54 36.3M 0 0 14981 0 1:17:45 0:42:25 0:35:20 0 url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 38141765 B speed_download: 14981.000 B/s time_appconnect: 3.228601 s time_connect: 2.213136 s time_namelookup: 0.856194 s time_pretransfer: 3.228820 s time_redirect: 0.000000 s time_starttransfer: 3.851583 s time_total: 2545.889968 s curl: (56) GnuTLS recv error (-54): Error in the pull function.
➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 20415 0 0:57:03 0:57:03 --:--:-- 25983 url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 69899433 B speed_download: 20415.000 B/s time_appconnect: 2.005881 s time_connect: 0.785257 s time_namelookup: 0.000520 s time_pretransfer: 2.006124 s time_redirect: 0.000000 s time_starttransfer: 3.031582 s time_total: 3423.813489 s#+END_EXAMPLE
berlin-mirror.marusich.info:
#+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 1470k 0 0:00:46 0:00:46 --:--:-- 2368k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.87 remote_port: 443 size_download: 69899433 B speed_download: 1505934.000 B/s time_appconnect: 3.343496 s time_connect: 3.164926 s time_namelookup: 3.060655 s time_pretransfer: 3.343581 s time_redirect: 0.000000 s time_starttransfer: 5.766543 s time_total: 46.416495 s
➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 3182k 0 0:00:21 0:00:21 --:--:-- 4612k url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 13.35.20.87 remote_port: 443 size_download: 69899433 B speed_download: 3259170.000 B/s time_appconnect: 0.225982 s time_connect: 0.070428 s time_namelookup: 0.000483 s time_pretransfer: 0.226055 s time_redirect: 0.000000 s time_starttransfer: 0.306621 s time_total: 21.447966 s#+END_EXAMPLE

2. Tested today at my office. China Telecom enterprise broadband. 50Mb/s.
berlin.guixsd.org:
#+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 3091k 0 0:00:22 0:00:22 --:--:-- 3649k url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 69899433 B speed_download: 3166021.000 B/s time_appconnect: 3.288213 s time_connect: 2.733554 s time_namelookup: 2.486754 s time_pretransfer: 3.288320 s time_redirect: 0.000000 s time_starttransfer: 3.780341 s time_total: 22.078489 s
➜ ~ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 66.6M 100 66.6M 0 0 3499k 0 0:00:19 0:00:19 --:--:-- 4011k url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 69899433 B speed_download: 3583667.000 B/s time_appconnect: 0.761166 s time_connect: 0.244415 s time_namelookup: 0.000981 s time_pretransfer: 0.761275 s time_redirect: 0.000000 s time_starttransfer: 1.247935 s time_total: 19.505515 s#+END_EXAMPLE
berlin-mirror.marusich.info:
#+BEGIN_EXAMPLE ➜ ~ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 49 66.6M 49 32.8M 0 0 19012 0 1:01:16 0:30:13 0:31:03 29265 url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 52.85.158.22 remote_port: 443 size_download: 34488133 B speed_download: 19012.000 B/s time_appconnect: 2.958899 s time_connect: 2.487483 s time_namelookup: 2.271520 s time_pretransfer: 2.959321 s time_redirect: 0.000000 s time_starttransfer: 5.447693 s time_total: 1813.938029 s curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)#+END_EXAMPLE

Although both 13.35.20.0/24 and 52.85.158.0/24 IP ranges are located at Seattle,the result shows that the connection to 13.35.20.0/24 is significantly faster.This is pretty normal in China. It's definitely caused by the GFW. Giantinternet service providers (e.g. AWS) are the primary targets of the GFW.
M
M
Marius Bakke wrote on 21 Dec 2018 21:47
87zhsy8v5l.fsf@fastmail.com
Giovanni Biscuolo <g@xelera.eu> writes:
Toggle quote (18 lines)> Mark H Weaver <mhw@netris.org> writes:>>> Giovanni Biscuolo <g@xelera.eu> writes:>>> with a solid infrastructure of "scientifically" trustable build farms,>>> there are no reasons not to trust substitutes servers (this implies>>> working towards 100% reproducibility of GuixSD)>>>> What does "scientifically trustable" mean?>> I'm still not able to elaborate on that (working on it, a sort of> self-research-hack project) but I'm referencing to this message related> to reduced bootstrap tarballs:>> https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00347.html>> and the related reply by Jeremiah (unfortunately cannot find it in> archives, Message-ID: <877eh81tm4.fsf@ITSx01.pdp10.guru>)
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlwdUUYACgkQoqBt8qM6VPruRwgAhSOerLH74Awnfrly6rUDSJy3ujd7d2AY8etcSQwf83A5XJhVJ6w2TMRwE1kE5aBeXDwL8tzfY0rvQC9BFMwouhpiR691ta8aGjXJ4XBN6VMQ2lstIR0i6jwbhsGGApGw62ftaO54DAxTr0N35aedkvWEbGYydCAJ5Hpb5LjReeCL/AU/A8lbuVYAn9KLfXuP8wv07Ss+xUdSudlDVsnnG+axXdBpP4mQl+556bsGldtz1QKGaN9l3wKRpZlM01aDmda5ZLnh/up/5LoMFmWK7SAq+sqrmKf79rxUt45FvcB3p/Yz9XIaKF3sJsMsd+SZs8m5xnM24A64jxvMUCAKLA===W5IM-----END PGP SIGNATURE-----
R
R
Ricardo Wurmus wrote on 24 Dec 2018 15:47
(name . Giovanni Biscuolo)(address . g@xelera.eu)
87ftunq8wq.fsf@mdc-berlin.de
Hi Giovanni,
Toggle quote (12 lines)> for this very reason IMHO we should work towards a network of **very> trusted** build farms directly managed and controlled by the GuixSD> project sysadmins; if build farms will be able to quickly provide> substitutes, caching mirrors will be _much more_ effective than today>> ... and a network of "automated guix challenge" servers to spot> not-reproducible software in GuixSD>> with a solid infrastructure of "scientifically" trustable build farms,> there are no reasons not to trust substitutes servers (this implies> working towards 100% reproducibility of GuixSD)
This sets the bar very high. I administer berlin.guix.info /ci.guix.info (same server) and most of the associated build nodes, but Idon’t think people should trust these computers more than their owncomputers or those managed by people they personally know.
The build servers do the same work that a user would do who buildssoftware locally without substitutes; the builders are supposed tobehave just like any other user. (And we can challenge their authoritywith “guix challenge”.) I want us to keep in mind that build farmsdon’t necessarily deserve any more trust than other computers you don’tcontrol. Substitute servers are a convenience.
To improve distribution of binaries we are committed to working ondifferent strategies at the same time:
- improve our processes so that non-critical package changes only hit the master branch when we have already built the package and made it available for distribution.
- improve availability of the single server berlin.guix.info by hooking it up to a CDN via the name ci.guix.info (from which users can easily opt out by changing their default substitute server to berlin.guix.info).
- improve redundancy by setting up an off-site fail-over for the head of the build farm at berlin.guix.info (such as bayfront).
- distribute build artefacts over IPFS without requiring a central authority
All of these things can be done in parallel by different people. Thisincreases the project’s resilience and the options that users can choosefrom.
--Ricardo
P
P
Pierre Neidhardt wrote on 5 Mar 2019 17:19
unarchive 33600
(address . control@debbugs.gnu.org)
875zsxgupo.fsf@ambrevar.xyz
unarchive 33600
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlx+oYMACgkQm9z0l6S7zH+irQf/VdPjKDt+TYVxsxRjvDjdrUuPo0KKTPlpoRObBfxPJ+C/AQmn6AYcfoT1vyey+lcSeFrnEfo1hIYlCT9T1TRIC+qIaK61BQVsMQV29o7wiJz2zSKw4bGDdGwk2w7Dhcw8cM8V1mRQ5jppM4wtl0zq1AWwuQy2ehOOQ8H2Nt99zLYnbKC7GIqaSpZVJeTmcc7gIoNEZeZOcsxhmsrICXgj7b+edyuZzTJbz21vV+XFFx/gIWlnYhpR8vZHws9m+YsRs1yxGNiNPdqH53ibKeY3l57hunzI6ICMS6+8qy+n/midjhN4Fql2CuKC9kJBj1Z0wBVwLMgrAcyueVBekmyVZA===zIMj-----END PGP SIGNATURE-----
?
Your comment

This issue is archived.

To comment on this conversation send email to 33600@debbugs.gnu.org