fsmithred | torrent appears to be working correctly here | 00:56 |
---|---|---|
mason | Magnet link breaks here. | 04:17 |
mason | Torrent links seems to be correct, though. | 04:19 |
mason | bbiab | 04:19 |
golinux | mason: Is the the magnet link you tried? | 04:44 |
golinux | magnet:?xt=urn:btih:21c309091f3853e1ac7d80d6c4e2ca4f869e2d77&tr=udp%3a%2f%2ftracker.dyne.org%3a6969&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80 | 04:44 |
golinux | Make sure that you refresh the page. You might be trying to access the magnet for 2.0.0 | 04:46 |
Beerbelott | Hi, my monitoring tool reports to me that since at least 2019-11-22T22:55Z, the 190.64.49.124 mirror, part of deb.devuan.org pool, is not responsive on TCP/80 port anymore | 10:34 |
Beerbelott | The defect has been continuous since then (on a check/5 min basis) | 10:35 |
Beerbelott | Would it be possible to confirm defect & if positive act on it? | 10:35 |
onefang | I can confirm that, my monitoring scripts say the same. | 10:37 |
onefang | As of about half an hour ago it was still responding to deb.devuan.org, just not connecting directly. | 10:40 |
onefang | I'm part way through cooking dinner, I'll investigate further after eating. | 10:45 |
Beerbelott | What do you mean by "still responding to deb.devuan.org"? | 10:45 |
Beerbelott | The IP address is currently still in the pool, yes, but connection to this IP address on TCP/80 is defunct since almost 12h now | 10:46 |
onefang | https://sledjhamr.org/apt-panopticon/results/LOG_deb.devuan.org_190.64.49.124.html is the logs of my checker connecting to that IP as deb.devuan.org. | 10:46 |
Beerbelott | The fact a non-responsive TCP/80 address is included in the deb.devuan.org is the problem indeed, as it can be damaging | 10:47 |
onefang | https://sledjhamr.org/apt-panopticon/results/LOG_espejito.fder.edu.uy_190.64.49.124.html is connecting to that IP as espejito.fder.edu.uy. | 10:47 |
onefang | BRB | 10:47 |
Beerbelott | I see you use a timeout of 15 seconds on the connections | 10:48 |
Beerbelott | I used 5 on my test script... which seems to me far more than generous on a mere TCP connection (no data sent) | 10:48 |
Beerbelott | I am not sure the timeout is the reason you could connect and not me, though. Routing difference? I guess only the mirror's owner could investigate | 10:53 |
onefang | I just actually downloaded a file from that IP using deb.devuan.org as the host. | 10:53 |
onefang | Have you tried a traceroute? | 10:55 |
onefang | curl --retry 0 -s --path-as-is --connect-timeout 15 --max-redirs 0 --connect-to 190.64.49.124 -H "Host: deb.devuan.org" http://deb.devuan.org/merged/dists/jessie/Release | 10:57 |
onefang | Time for me to eat. Back soon. | 11:02 |
onefang | Even with timeout of 5 seconds, I get the file. | 11:14 |
onefang | curl http://espejito.fder.edu.uy/merged/dists/jessie/Release | 11:22 |
onefang | curl: (7) Failed to connect to espejito.fder.edu.uy port 80: Connection timed out | 11:22 |
onefang | So as part of the deb.devuan.org pool it's working fine, just not as a stand alone mirror. | 11:23 |
* onefang sends an email to the mirror's owner. | 11:29 | |
onefang | Beerbelott: did you get in touch with Evilham about your mirror? | 11:41 |
onefang | Also, I can ping both IPs. | 11:49 |
Evilham | onefang: it doesn't look like espejito is working fine as part of the RR either, I removed it | 11:51 |
onefang | Hmmm, there might be something wrong with my tests then. B-( | 11:52 |
onefang | Does that above curl test look OK to you? | 11:53 |
Evilham | huh | 11:59 |
Evilham | interesting | 11:59 |
Evilham | curl -H "Host: deb.devuan.org" http://190.64.49.124/merged/dists/jessie/Release | 11:59 |
Evilham | doesn't work | 11:59 |
Evilham | but yours does | 11:59 |
onefang | Ah, the --connect-to 190.64.49.124 bit seems to not be doing what I thought it would. I tried it with -v. | 11:59 |
Evilham | alrighty :-p | 12:00 |
Evilham | so yeah, it's remove | 12:00 |
Evilham | d | 12:00 |
Evilham | I have to be away \o | 12:00 |
onefang | "--connect-to "deb.devuan.org::190.64.49.124:" is the correct way, and it fails now. | 12:05 |
* onefang updates my monitor script. | 12:05 | |
Evilham | I think --resolve is clearer | 12:11 |
Evilham | but also I always just use the IP in the URL and use the hostname header | 12:11 |
Evilham | so: | 12:12 |
Evilham | curl --resolve deb.devuan.org:80:190.64.49.124 http://deb.devuan.org | 12:12 |
Evilham | (where 80 is the port) | 12:12 |
onefang | As far as I can tell --connect-to supports SNI properly, and one of the mirrors is using SNI, and my checker was failing on that mirror when I used the IP in the URL. | 12:13 |
Beerbelott | onefang: I'd weight in favour of --resolve for cURL | 13:05 |
Beerbelott | It does what you think it does | 13:05 |
Beerbelott | It then allows you to use the hostname in the URL, which conveniently helps populating the HTTP Host field | 13:06 |
onefang | The docs for it don't mention SNI though, and the docs for --connect-to do mention SNI. | 13:06 |
Beerbelott | The docs for --connect-to mentions SNI to tell it's *not* affecting it | 13:08 |
onefang | The problem with writing this sort of in depth checking script is that I can't afford to setup a whole bunch of servers that do the wrong thing. So I have to wait for actual servers to do the wrong thing before I know I'm checking for that wrong thing incorrectly. lol | 13:09 |
onefang | *not* affecting SNI is exactly what I want. | 13:09 |
Beerbelott | Well when checking for connectivity, you need to separate problems | 13:10 |
Beerbelott | My check, which properly failed on this unresponsive host, is quite simple: TCP connection | 13:10 |
Beerbelott | Not more | 13:10 |
onefang | I have a TODO item to add that sort of basic test, coz you mentioned it long ago. B-) | 13:11 |
Beerbelott | Complex scripts mix up variables, so you do not know which layer is wrong | 13:11 |
onefang | I'm trying to probe things all the way down the various layers. | 13:11 |
Beerbelott | Well then you have a test somewhere whoch merely checks TCP connectivity (and not more) telling you this host was down on TCP/80 for half a day | 13:12 |
Beerbelott | ;) | 13:12 |
Beerbelott | I do not get why you do not want SNI though | 13:12 |
Beerbelott | Checking a server without SNI... you might be routed to a failing location while the proper one, routed with proper SNI, might be responsive | 13:13 |
onefang | I do want SNI, and I want it tested for correctly. Two of our mirrors use SNI, and my previous "use the IP in the URL" test failed for them. | 13:13 |
Beerbelott | (routed in "application routing") | 13:13 |
Beerbelott | --resolve is the way to go for SNI | 13:14 |
Beerbelott | use the hostname in the URL | 13:14 |
onefang | Which is why I now use --connect-no, coz as you mentioned, it hdoes not affect SNI. | 13:14 |
Beerbelott | I guess we udnerstand the docs differently | 13:14 |
onefang | --connect-to mentions SNI, --resolve doesn't, so I went with the one that is documented to work with SNI. | 13:15 |
Beerbelott | I am not sure --connect-to does what you think it does | 13:15 |
onefang | What exactly do you think it does? | 13:16 |
Beerbelott | All I know is IIRC --resolve allows you to use a hsotname in a URL, hostname which will then be used in SNI as expected, while resolving said hostname to the precise IP address you wish for tests purpose | 13:16 |
Beerbelott | I have extensively used --resolve is almost exclusively SNI environments. If SNI wasn't respected, I should have noticed... because I would most of the time not received the content of the proper virtual server ;) | 13:18 |
Beerbelott | virtual server -> certificate, my bad | 13:18 |
onefang | Like I said, --resolve doesn't mention SNI, --connect-to does. So I went with the one that is documented to work. I don't see that --resolve gets me anything more than --connect-to does. | 13:19 |
Beerbelott | About your question on my mirror... I did raise the subject on #devuan-infra and got in touch w/ Evilham, to no avail so far. However I am only occasionally connected on IRC, hence I might have slipped past any answer on unlogged channels | 13:20 |
Beerbelott | I'll reverse the q°: why do you want SNI to be mentioned when it's the expected, default, behaviour? | 13:21 |
onefang | I was pointing you at Evilham coz you where asking about your mirror at 3AM my time, I figured he would be a lot closer to your timezone. | 13:21 |
Beerbelott | The fact SNI is mentioned in your switch means something fishy or at least non-standard seems to be done with it there | 13:21 |
Beerbelott | curl has the habit of being pretty standard in its behaviour, auto-filling basic requirements (like the Host header) based on called URI | 13:22 |
onefang | Coz SNI also not mentioned in using -H "host:" documentation, which DID fail. So I searched through the docs for SNI, only --connect-to mentioned it. | 13:22 |
Beerbelott | it does the same at the TLS layer level | 13:22 |
Beerbelott | Host HTTP header != TLS SNI | 13:22 |
Beerbelott | -H "Host: ***" fills up... a HTTP header. | 13:23 |
onefang | Soooo, why should I switch to --resolve if --connected-to works AND is documented to work for SNI? | 13:23 |
Beerbelott | I thought you said this switch was not doing what you wanted/thought it was doing? | 13:24 |
onefang | It was the format of the --connect-to argument that I switched. | 13:25 |
Beerbelott | I can't comment the --connect-to switch I don't know. And its docs are nto clear to me. --resolve is way clearer to me, much simpler to remember, and allows the called URL to successfully impact both TLS & HTTP layers seamlessly | 13:25 |
Beerbelott | I'd warmly recommend you to use it. I am not trying to convince you if you *know* better. | 13:25 |
Beerbelott | I also find elegant that, leveraging the called URL, you do not have to manually feed any -H switch | 13:26 |
Beerbelott | especially for the Host HTTP header | 13:26 |
onefang | I'm not trying to remember it, I'm trying to script it. B-) | 13:26 |
Beerbelott | I'd always advise the compactest, leanest & most elegant solutions as to avoid false positives | 13:27 |
onefang | I was trying several methods of dealing with SNI, using various libraries, using wget or curl command lines. | 13:29 |
Beerbelott | curl -svo /dev/null --resolve home:443:127.0.0.1 https://home/ | 13:30 |
Beerbelott | Don't you think that's immediately understandable? | 13:30 |
Beerbelott | and it does SNI & populates HTTP Host... | 13:31 |
Beerbelott | Thx to using the targeted hostname in the URI part of cURL | 13:31 |
onefang | --connect-to home:433:127.0.0.1 Is just as understandable. | 13:32 |
onefang | And has the advantage of being documented as working with SNI. | 13:32 |
onefang | At that point, after failing with lots of other methods, I stopped looking. | 13:32 |
onefang | I wasn't gonna start experimenting with stuff that doesn't mention SNI, just on the off chance it would work. | 13:34 |
onefang | Though now I'm wondering why they bothered with two options which seem to work in exactly the same way? | 13:36 |
Beerbelott | FWIU --connect-to might allow you to connect to another hostname while retaining the 1st one for SNI & virtual server resolution | 13:37 |
Beerbelott | ie instead of resolving the connection host and then using its IP address in resolve (2 steps) you could do that in a single step | 13:38 |
Beerbelott | That's for a hostname -> hostname transition | 13:38 |
Beerbelott | for hostname -> IP address, I guess they are equivalent? | 13:38 |
Beerbelott | Pure speculation. I'd do not trust --connect-to myself as its documentation seems unclear to me (personal opinion *2) | 13:39 |
Beerbelott | You do what works best to you and what is easiest to maintain. Make sure you scripts do not pretend connecting to unresponsive hosts though ;) | 13:39 |
Beerbelott | Also, I was using nc. | 13:40 |
Beerbelott | One layer at a time. | 13:40 |
onefang | In about half an hour the regularly scheduled checking run will happen on my server, which has better connectivity than my home, especially at this time of night on a Saturday, when others in the house are watching Netflix on our shared WiFi. I'll see what happens. B-) | 13:40 |
Beerbelott | If you wanna decouple SNI & HTTP layers, I'd use a TLS-specific client for SNI, and reserve cURL for mere HTTP checks | 13:41 |
onefang | https://sledjhamr.org/mantisbt/view.php?id=81 doing the nc thing is a TODO, coz you mentioned it before. B-) | 13:41 |
Beerbelott | I'd use nc, then openssl s_client, then cURL | 13:43 |
Beerbelott | (with --resolve) | 13:43 |
onefang | Sooo, about your mirror. It's only an ISO mirror, not a package mirror? Do you intend to add a package mirror later? | 13:43 |
Beerbelott | I'm doing basic checks so I only consider unresponsive hosts. I am not checking responsive hosts' integrity | 13:44 |
Beerbelott | I might do... the only problem is disk space | 13:44 |
Beerbelott | last I checked it was requiring a little bit short of 60 GiB | 13:44 |
Beerbelott | (the package repo that is) | 13:44 |
Beerbelott | That's the estimate rsync gave me, I dunno if it's accurate | 13:45 |
onefang | For an ISO mirror, we just need to list you on https://devuan.org/get-devuan if I recall correctly. I've mostly been dealing with package mirrors so far. | 13:45 |
Beerbelott | I suppose so | 13:46 |
Beerbelott | The download URI in MIRRORS.txt shall be updated though | 13:46 |
onefang | The package mirror walk through says 50GB, pkgmaster currently has 44GB. | 13:47 |
Beerbelott | btw I am only providing HTTPS, with also HTTP supported in a HTTP -> HTTPS fashion | 13:47 |
onefang | Some of our package mirrors do that. | 13:47 |
Beerbelott | Would not it be interesting to have a torrent for those files? | 13:48 |
Beerbelott | It could help duplicating sources without having to manage newcomers/outgoers | 13:48 |
Beerbelott | without having to manage them *manually* at least | 13:48 |
onefang | https://files.devuan.org/devuan_ascii.torrent and magnet:?xt=urn:btih:21c309091f3853e1ac7d80d6c4e2ca4f869e2d77&tr=udp%3a%2f%2ftracker.dyne.org%3a6969&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80 | 13:48 |
Beerbelott | Oooh | 13:48 |
Beerbelott | How did I miss that? | 13:49 |
Beerbelott | It's not on the download page | 13:49 |
onefang | No idea, I copied those from the Devuan front page. | 13:49 |
Beerbelott | Yeah this website is a bit of a mess actually :D | 13:50 |
Beerbelott | Yeah it's on the front page but not in the download section | 13:50 |
onefang | You need to talk to the people that deal with the website, that's not me. | 13:50 |
onefang | Currently it's being redone for the ASCII point release, so some of this stuff might have been cleaned up already. golinux would know. | 13:51 |
Beerbelott | Great! | 13:53 |
onefang | https://sledjhamr.org/apt-panopticon/results/Report-web.html is the current result. Interesting, I'm getting different responses from espejito's IPv4 and IPv6 addresses. | 14:12 |
Evilham | onefang: you should probably check the grafana instance as well :-p | 17:59 |
golinux | onefang: Yes, the index page has been updated to point to ASCII 2.1 | 18:10 |
golinux | And the point release announcement is linked from the first paragraph: https://devuan.org/os/debian-fork/ascii-point-release-announce-112119 | 18:11 |
* onefang checks grafana. | 18:12 | |
golinux | I have requested that jaromil send it to the "announce" list to make it official | 18:12 |
onefang | Cool golinux. Can you / have you added Beerbelott's ISO mirror? | 18:13 |
golinux | As a response to Beerbelott's comments . . . the index page points to all 3 options to download isos: the mirror list page (get-devuan), the torrent and the magnet. | 18:16 |
golinux | I didn't read all that very carefully so didn't catch that he has a mirror that needs to be added. | 18:16 |
golinux | onefang: ^^^ | 18:17 |
golinux | Usually the mirror team relays that info to me once a mirror has been verified. I would never make that decision on my own. | 18:18 |
golinux | You can pm it to me so as not to flood this channel | 18:18 |
onefang | I haven't come up to speed on how things go with ISO mirrors, I'm still learning the ropes for package mirrors. | 18:19 |
golinux | Right . . . the only thing I'm concerned with on the website are the iso mirrors | 18:20 |
golinux | And when someone on the team gives me that info, I add it. | 18:20 |
onefang | Found Beerbellot's mirror message - 2019-11-01 13:02:11 Beerbelott: Hello. I have a Devuan Archive Mirror up & running at https://devuan.rosset.eu.org/ | 18:22 |
golinux | Only https? | 18:24 |
onefang | It redirects http to https. | 18:24 |
golinux | Thanks for finding that | 18:25 |
golinux | No ftp or rsync? | 18:25 |
onefang | Nope. | 18:25 |
golinux | I'll do that after I get some b'fast. | 18:26 |
onefang | Just having a quick look around. Seems up to date, has ASCII 2.1. My mirror checker script has ISO mirror checking as a TODO item. | 18:26 |
onefang | Enjoy your brekky. | 18:28 |
golinux | Yes, 2.1 is available and iiuc, 2.0.0 has been "archived" somewhere. 2.0.0 embedded images are still available though because there are no official 2.1 replacements. | 18:29 |
onefang | ISO mirrors have an "archive" directory with the archived 2.0 ISOs in them. | 18:30 |
golinux | We'll see if the devuan arm community gets it together . . . | 18:30 |
onefang | Beerbelott's mirror has that to. | 18:30 |
golinux | All that was just sorted at the last meet. | 18:31 |
onefang | I did manage to sneak in a quick peek at the meeting pad during the 7 AM inspection. | 18:32 |
golinux | onefang: https://devuan.rosset.eu.org/ added to get-devuan | 20:56 |
onefang | Thanks. | 20:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!