Re: svn.haxx.se is going away
On Fri, Nov 27, 2020 at 12:26 PM Daniel Shahaf
wrote:
> Greg Stein wrote on Wed, Nov 25, 2020 at 00:08:32 -0600:
> > Hey Daniel,
> >
> > I think the best place for this content is on mbox-vm.a.o. That is where
> we
> > have our permanent list archives in mbox format.
> > We can then arrange to ship them off to lists.a.o. If you concur,
>
> I concur in the sense that it'd be great to have the mboxes stored on
> and served by whatever Infra uses for all other archives.
>
> However, when I last looked at lists.a.o I was of the opinion that Infra
> shouldn't use it. (Back then its permalinks weren't permanent and
> weren't able to be generated or dereferenced while the user was offline
> *or while the external vendor was offline*. I don't know whether those
> have been fixed since then.) Unless that has changed, I wouldn't like
> Subversion to rely on that particular archive. Instead, there's
> mod_mbox, or a static snapshot of svn.haxx.se.
>
Infra has no plans to switch away from lists.a.o. The permalinks issue is
being solved for the oldest archives (we have a copy of the ElasticSearch
database holding them, so we don't have to rely on a .csv file). The
mail-archives.a.o and mail-private.a.o mod_mbox servers will be taken
offline at some point, and a redirector left in its place.
The Subversion community can stand up its own archive on svn-qavm, or rely
on lists.a.o and a redirector. Infra has no opinion on that.
(@Greg: You know I wouldn't normally have repeated the above, but
> (1) you asked, and (2) the dev@ audience doesn't all know this context.)
>
No worries at all.
> > then I'll ask the team to get you access.
>
> Would InfraAdmin let someone else from the PMC take point? I realize
> that this is an ASF-wide box (as opposed to a PMC box) and I'm a known
> entity at Infra, but I'm short on tuits.
>
Anybody with an @apache account. Or if somebody emails me privately with a
path on svn-qavm.a.o for the content that I should mirror onto our mbox
storage machine. I can get that content moved over from svn-qavm maybe even
a bit more easily. (iirc, DShahaf and Nathan have copies on svn-qavm?)
> You can preserve all the data you want into your homedir, and we can
> > sort from there.
>
> Sounds good. Nathan, Daniel Sahlberg — could you work with Infra on
> getting the data over to ASF hardware?
>
> Note that svn-org@ doesn't have an equivalent @s.a.o list, and that, as
> mentioned upthread, the post-migration (from tigris.org to apache.org)
> mboxes may be in a different order than the official ones, and shouldn't
> be "deduplicated".
>
> > You indicate a desire to maintain URLs. Do you have some ideas on that?
>
> Each individual message .shtml file contains the message-id in
> a comment. We can extract the comments and build a redirector around
> them. (By the way, this is basically the same exercise that Infra must
> have solved back when Sebb received that CSV file from the lists.a.o
> vendor, so there may be an opportunity for code reuse.) Of course, the
> full rsync likely has the same info available less scrapily.
>
> Or, as mentioned above, the .shtml files could just be preserved
> statically (plus or minus an appropriate message in the list of years on
> the /${listname}/ page). In fact, I'm having trouble coming up with
> a reason _not_ to serve a static snapshot of the pages, even if we do
> build a redirector.
>
svn-haxx.spache.org is live now. It is an A record pointing to
svn-qavm.a.o. (one day, it might be a CNAME, but for $reasons it is not,
today).
Thus, anybody can configure httpd on svn-qavm however you like, and have it
respond to svn.haxx.se and svn-haxx.apache.org. Whether redirects or a
static site, or ...
DSahlberg could do this if somebody on the PMC gives him a +1 to have an
account created (effectively as a partial committer, but with no
directories specified). Then he can sign/send an ICLA, and get an account.
That can be added to svn-qavm, where he could set up a site. Tho I'll warn
that root would be required for httpd configuration.
Medium/long-term I would suggest putting the httpd configuration into
Puppet once it is stable, so it will stick around across machine
(re)provisioning.
Feel free to ping me on Slack or via email. I read svn lists sporadically
nowadays, but am more than happy to represent both svn and infra.
Cheers,
-g
Re: Error E170013: The server unexpectedly closed the,connection.
Den fre 27 nov. 2020 kl 20:45 skrev Thomas Singer : > How valuable is the information that the user can access the SVN server > from a browser? How to analyze/debug the access to find out at what > stage it fails? > Not a Mac guy myself, but I on Windows would suspect proxy configurations in the browser, application aware firewall that filter out requests from Subversion or some trickery with the https certificate chain. I would assume these are also possible on macOS. On corporate networks I have seen firewalls or transparent proxy servers that decrypt https traffic and filter based on for example user agent strings or usage patterns. It seems Wireshark is available for macOS so I would start there to make sure traffic is actually getting out of the box. Then working my way through the network to see where the packages are dropped. Kind regards Daniel Sahlberg
Re: Error E170013: The server unexpectedly closed the,connection.
How valuable is the information that the user can access the SVN server from a browser? How to analyze/debug the access to find out at what stage it fails? -- Tom On 2020-11-27 9:27, Branko Čibej wrote: On 27.11.2020 07:18, Thomas Singer wrote: Hi, According to the user this error occurs now permanently on macOS 10.15 for him while in previous versions it only occurred sometimes with macOS 10.14/15, but not with 10.12/13. Just as a data point, I use svn-1.14 on macOS 10.15 all the time with no problems. But I can't even connect to port 443 on this server, there's no response, with or without Subversion. My guess would be that something is wrong with the configuration on the server end, it sure looks like it's just dropping packets. -- Brane
Re: svn.haxx.se is going away
Den fre 27 nov. 2020 kl 19:26 skrev Daniel Shahaf :
> Greg Stein wrote on Wed, Nov 25, 2020 at 00:08:32 -0600:
> > You can preserve all the data you want into your homedir, and we can
> > sort from there.
>
> Sounds good. Nathan, Daniel Sahlberg — could you work with Infra on
> getting the data over to ASF hardware?
>
I can help, but I have no reputation in the project.
> You indicate a desire to maintain URLs. Do you have some ideas on that?
>
> Each individual message .shtml file contains the message-id in
> a comment. We can extract the comments and build a redirector around
> them. (By the way, this is basically the same exercise that Infra must
> have solved back when Sebb received that CSV file from the lists.a.o
> vendor, so there may be an opportunity for code reuse.) Of course, the
> full rsync likely has the same info available less scrapily.
>
> Or, as mentioned above, the .shtml files could just be preserved
> statically (plus or minus an appropriate message in the list of years on
> the /${listname}/ page). In fact, I'm having trouble coming up with
> a reason _not_ to serve a static snapshot of the pages, even if we do
> build a redirector.
>
I think it's best to start with a plain copy of the existing site, then we
can also pay homage to Daniel Stenberg's efforts for the 20 years.
Kind regards,
daniel
Re: svn.haxx.se is going away
Greg Stein wrote on Wed, Nov 25, 2020 at 00:08:32 -0600:
> Hey Daniel,
>
> I think the best place for this content is on mbox-vm.a.o. That is where we
> have our permanent list archives in mbox format.
> We can then arrange to ship them off to lists.a.o. If you concur,
I concur in the sense that it'd be great to have the mboxes stored on
and served by whatever Infra uses for all other archives.
However, when I last looked at lists.a.o I was of the opinion that Infra
shouldn't use it. (Back then its permalinks weren't permanent and
weren't able to be generated or dereferenced while the user was offline
*or while the external vendor was offline*. I don't know whether those
have been fixed since then.) Unless that has changed, I wouldn't like
Subversion to rely on that particular archive. Instead, there's
mod_mbox, or a static snapshot of svn.haxx.se.
(@Greg: You know I wouldn't normally have repeated the above, but
(1) you asked, and (2) the dev@ audience doesn't all know this context.)
> then I'll ask the team to get you access.
Would InfraAdmin let someone else from the PMC take point? I realize
that this is an ASF-wide box (as opposed to a PMC box) and I'm a known
entity at Infra, but I'm short on tuits.
> You can preserve all the data you want into your homedir, and we can
> sort from there.
Sounds good. Nathan, Daniel Sahlberg — could you work with Infra on
getting the data over to ASF hardware?
Note that svn-org@ doesn't have an equivalent @s.a.o list, and that, as
mentioned upthread, the post-migration (from tigris.org to apache.org)
mboxes may be in a different order than the official ones, and shouldn't
be "deduplicated".
> You indicate a desire to maintain URLs. Do you have some ideas on that?
Each individual message .shtml file contains the message-id in
a comment. We can extract the comments and build a redirector around
them. (By the way, this is basically the same exercise that Infra must
have solved back when Sebb received that CSV file from the lists.a.o
vendor, so there may be an opportunity for code reuse.) Of course, the
full rsync likely has the same info available less scrapily.
Or, as mentioned above, the .shtml files could just be preserved
statically (plus or minus an appropriate message in the list of years on
the /${listname}/ page). In fact, I'm having trouble coming up with
a reason _not_ to serve a static snapshot of the pages, even if we do
build a redirector.
Cheers,
Daniel
Re: Error E170013: The server unexpectedly closed the,connection.
On 27.11.2020 07:18, Thomas Singer wrote: Hi, According to the user this error occurs now permanently on macOS 10.15 for him while in previous versions it only occurred sometimes with macOS 10.14/15, but not with 10.12/13. Just as a data point, I use svn-1.14 on macOS 10.15 all the time with no problems. But I can't even connect to port 443 on this server, there's no response, with or without Subversion. My guess would be that something is wrong with the configuration on the server end, it sure looks like it's just dropping packets. -- Brane
