guix.gnu.org is inaccessible from Russia

Hello. I would like to request a clarification on the issue of

inaccessibility of guix.gnu org from the Russian Federation.

Is the blocking intentional or is there some kind of networking problem?

Here's my traceroute output:

Thanks.

Hello!

Check out this discussion:

Hi Point4d,

Specifically, from the thread linked by Evgeny:

"At the MDC level there’s an unrelated recent ban of some Russian IP ranges in place due to massively increased port scans and intrusion attempts since about one week. I hope you can use the Chinese mirror for the time being."

That mirror is at https://mirrors.sjtug.sjtu.edu.cn/guix. Let us know if it works.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.

Hm,

I didn't address guix.gnu.org beyond ci.guix.gnu.org.

Everyone: should we ask SJTUG to mirror the Web site as well?

I'm generally weary of that.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.

Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

I believe bayfront was being setup to serve the website (see [1]), but

I'm not sure on how that's progressing.

1: https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=8250a46b2fa178d1cdd37986028d5a07e3db65ed

Hi,

Christopher Baines <mail@cbaines.net> skribis:

Indeed. The plan we discussed during the “sysadmin hackathon” a couple

of months ago was to, for instance, have the DNS entry point to these

two machines.

The problem we keep stumbling upon and that I don’t know how yet how to

solve is how to make it work for HTTPS: do we copy raw certificates to

bayfront, or is there a way to have separate certificates? How about

Let’s Encrypt challenges?

These are the last issues to solve and I’d welcome expertise here. Any

ideas?

Everything else is addressed: the web site gets built on bayfront just

like it is on berlin, static data such as videos and PDFs are

automatically mirrored to bayfront.

https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=601691e7ea07c999d60993464b27d4cba2621f05

Thanks,

Ludo’.

Hi!

On 2022-03-13 15:30, Ludovic Courtès wrote:

Uhm, quick but:

Apparently some browsers (OK, one, and we all know which one) embraces &

extends the DNS in such a way that this provides the fall-back behaviour

you seem to expect. But this is not standard and it won't fly with most

software. I checked.

It doesn't in Firefox/IceCat. Even if it does in current Chrom{e,ium},

it might just be an unreliable side-effect.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

[Resending to the proper address, sorry; I'm mu4e-less and hence

incompetent :-]

Hi!

On 2022-03-13 20:00, poiNt_3D wrote:

I'm afraid we don't control the berlin firewall or have much sway in how

it's managed, so there's little point in discussing such actions.

With Russia waging war, it seems likely that these Russian ISPs tolerate

abusive traffic for political reasons. There are probably political

consequences for those who refuse.

The Internet was and still is built on ISP accountability and gives

targets few other tools to effectively defend themselves, short of

blocking such IP ranges.

I wish there were a better answer than 'use Tor' for those stuck in the

cross-fire :-(

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Pending expertise, is it feasible to serve the copy as-is without trying

to impersonate berlin? E.g. mirror.guix.gnu.org?

Hm, maybe that's not worth the effort…

I've asked around and short of pointing guix.gnu.org to bayfront —

working around the issue & hoping that it will continue to be unaffected

— or using a CDN that has points of presence in Russia — which can

easily be taken down in a future wave of sanctions — the situation seems

to be quite disappointing.

For proper fail-over you (ironically) need one box sitting in front of

the boxes you want to fail over to.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Tobias Geerinckx-Rice via Bug reports for GNU Guix schreef op zo 13-03-

2022 om 20:50 [+0100]:

For the website, publishing the website not only over HTTP/S but also

over IPFS might help? The website is static and Guix has an IPFS

service, so it should be feasible I think. The browser extension

(https://docs.ipfs.io/install/ipfs-companion/)would need to be

packaged though, and a DNS link record

(https://docs.ipfs.io/concepts/dnslink/#resolve-dnslink-name)would

need to be set up.

Greetings,

Maxime.

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> skribis:

That and/or publishing as an onion service would be great.

Ludo’.

retitle 54370 guix.gnu.org is inaccessible from Russia

quit

Hi,

I updated the onion address in the section of the cookbook that explains

how to get substitutes from ci.guix over Tor:

https://guix.gnu.org/cookbook/en/html_node/Getting-substitutes-from-Tor.html

Copying the text inline below.

Next step is to publish an Onion service for the web site.

HTH,

Ludo’.

3.8 Getting substitutes from Tor

================================

Guix daemon can use a HTTP proxy to get substitutes, here we are

configuring it to get them via Tor.

Warning: _Not all_ Guix daemon’s traffic will go through Tor! Only

HTTP/HTTPS will get proxied; FTP, Git protocol, SSH, etc

connections will still go through the clearnet. Again, this

configuration isn’t foolproof some of your traffic won’t get routed

by Tor at all. Use it at your own risk.

Also note that the procedure described here applies only to package

substitution. When you update your guix distribution with ‘guix

pull’, you still need to use ‘torsocks’ if you want to route the

connection to guix’s git repository servers through Tor.

Guix’s substitute server is available as a Onion service, if you want

to use it to get your substitutes through Tor configure your system as

follow:

(use-modules (gnu))

(use-service-module base networking)

(operating-system

…

(services

(cons

(service tor-service-type

(tor-configuration

(config-file (plain-file "tor-config"

"HTTPTunnelPort 127.0.0.1:9250"))))

(modify-services %base-services

(guix-service-type

config => (guix-configuration

(inherit config)

;; ci.guix.gnu.org's Onion service

(substitute-urls

"https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion")

(http-proxy "http://localhost:9250")))))))

This will keep a tor process running that provides a HTTP CONNECT

tunnel which will be used by ‘guix-daemon’. The daemon can use other

protocols than HTTP(S) to get remote resources, request using those

protocols won’t go through Tor since we are only setting a HTTP tunnel

here. Note that ‘substitutes-urls’ is using HTTPS and not HTTP or it

won’t work, that’s a limitation of Tor’s tunnel; you may want to use

‘privoxy’ instead to avoid such limitations.

If you don’t want to always get substitutes through Tor but using it

just some of the times, then skip the ‘guix-configuration’. When you

want to get a substitute from the Tor tunnel run:

sudo herd set-http-proxy guix-daemon http://localhost:9250

guix build \

--substitute-urls=https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion...

merge 55500 54370

poiNt_3D <point4d@gmail.com> writes:

Now that the website is hosted on bayfront, which wasn't changed

specifically to address this, but should do anyway, I'm going to close

this issue.

Things like ci.guix.gnu.org will still be inaccessible, so feel free to

open issues about those if you wish.

Thanks,

Chris