You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2020/01/08 11:53:53 UTC
Re: Svn server images / appliances / packages
Summarizing this thread so far...
There is broadly some agreement that a Docker setup wouldn't be a bad
idea; no other options stood out as being worth our attention; some
concern about whether "we" can maintain anything "we" do; some
opportunities for engaging with externally published solutions.
Responses to feedback...
Paul Hammant wrote:
> Here's one for AWS - https://aws.amazon.com/marketplace/pp/Bitnami-Subversion-Certified-by-Bitnami/B00NN8NOAE
That one does look like a good, enterprise-grade, maintained offering.
That's the sort of thing I'm looking for. Thanks.
> - but it does't meet your at home requirement.
There's no specific "at home" requirement, although that's always nice
to have for FOSS. In this thread my concern is that there should be a
practical option for people wanting or needing to run a server for
serious use, above hobbyist level and below enterprise (plentiful IT
resources) level. Solutions that run on paid cloud hosting can be
within scope if anybody wants to provide and maintain them.
Mark Phippard wrote:
> I do not think we should do it as I do not believe we are willing to hang with it and support it.
We'll see. It doesn't have to be the traditional "us" that is willing
to support it: I would be happy to see something supported by a
commercial vendor such as the Bitnami one above.
In fact the best way to achieve the goal might be to encourage outsiders
to do it. For example, we could contribute improvements to one of the
existing, independently published Docker scripts. That is a valid and
maybe better alternative to asking volunteers to bring their
contributions "here".
Brane wrote:
> [...] "no binary packages" policy [...]
There is not a "no binary packages" policy; I addressed this with a
footnote in my original email. Specifically, ASF policy says a project
MAY distribute binaries:
http://www.apache.org/legal/release-policy.html#compiled-packages
Daniel Shahaf wrote:
> There's an official https://hub.docker.com/u/apache.
I would prefer a docker repository at apache.org -- owning our own
identity -- but pragmatically we'll go with what the ASF already has, if
we publish something ourself. Thanks for the link.
- Julian
Re: Svn server images / appliances / packages
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Wed, Jan 08, 2020 at 11:53:53 +0000:
> Brane wrote:
> > [...] "no binary packages" policy [...]
>
> There is not a "no binary packages" policy; I addressed this with a footnote
> in my original email. Specifically, ASF policy says a project MAY
> distribute binaries:
>
> http://www.apache.org/legal/release-policy.html#compiled-packages
My understanding is that binaries are allowed onto the mirror system but aren't
subject to the legal shield, because there's no way for the PMC to audit them.
If the binaries are bit-for-bit reproducible and have been blessed by a dev@
vote they might be allowed to enter the legal shield, but AFAIK no project has
actually asked for this yet.
Re: Svn server images / appliances / packages
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Jan 13, 2020 at 9:00 AM Julian Foad <ju...@apache.org> wrote:
> Recognizing that OS/packaging is only one small part of the issue, we
> will want to specify a reference system in terms like these...
>
> Essentials
>
> * OS and installation procedure
> - see above
> * Subversion access methods:
> - http, https (mod_dav_svn)
> - svn (svnserve)
> - domain name / IP address / ports
> * authn & authz:
> - manually configured authn
> - manually configured authz rules
> - some semi-realistic examples of each
> * an automated backup, of some sort
> - see below
> * repo organization
> - single repo
> - many repos
>
> Bonus extras
>
> * LDAP integration
> * an svnsync mirror configuration
> * scripted creation of repositories from templates
> * hook scripts: semi-realistic examples
> * ...
>
> Some of these -- such as "an automated backup, of some sort" -- will
> lead to us having to discuss what is going to be our best practice
> recommendation. I think the need to deal with issues like that would be
> an important and valuable outcome of this project.
A few days ago I jotted down a few bulletpoints in my notes. The
purpose was to think about what subject headings might be found in an
administrator's reference.
Not terribly important or groundbreaking, but I'll post it for
completeness:
(1) Choosing the hardware and software platform
(2) Installation (ok the least of your worries)
(3) Configuration and security
(4) Maintenance: What specifically does the administrator need to do?
How to do these tasks? Suggested maintenance schedule? What are
the specific pitfalls and complexities? What to do about them?
(5) Backup and restore
(6) Relocating a repository
Nathan
Re: Svn server images / appliances / packages
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jan 13, 2020 at 02:00:15PM +0000, Julian Foad wrote:
> Recognizing that OS/packaging is only one small part of the issue, we will
> want to specify a reference system in terms like these...
>
> Essentials
>
> * OS and installation procedure
> - see above
> * Subversion access methods:
> - http, https (mod_dav_svn)
> - svn (svnserve)
> - domain name / IP address / ports
> * authn & authz:
> - manually configured authn
> - manually configured authz rules
> - some semi-realistic examples of each
> * an automated backup, of some sort
> - see below
> * repo organization
> - single repo
> - many repos
The above list seems to have some overlap with contents of the
svn book's Server Configuration chapter and others.
> Some of these -- such as "an automated backup, of some sort" -- will lead to
> us having to discuss what is going to be our best practice recommendation.
> I think the need to deal with issues like that would be an important and
> valuable outcome of this project.
Perhaps improving relevant sections of the svn book would be a
desirable outcome?
Re: Svn server images / appliances / packages
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> [...] suitable "reference system" options [...]:
>
> * Ubuntu (server, latest LTS)
> * Docker (probably using an Alpine image, or maybe Ubuntu)
Recognizing that OS/packaging is only one small part of the issue, we
will want to specify a reference system in terms like these...
Essentials
* OS and installation procedure
- see above
* Subversion access methods:
- http, https (mod_dav_svn)
- svn (svnserve)
- domain name / IP address / ports
* authn & authz:
- manually configured authn
- manually configured authz rules
- some semi-realistic examples of each
* an automated backup, of some sort
- see below
* repo organization
- single repo
- many repos
Bonus extras
* LDAP integration
* an svnsync mirror configuration
* scripted creation of repositories from templates
* hook scripts: semi-realistic examples
* ...
Some of these -- such as "an automated backup, of some sort" -- will
lead to us having to discuss what is going to be our best practice
recommendation. I think the need to deal with issues like that would be
an important and valuable outcome of this project.
- Julian
Re: Svn server images / appliances / packages
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Fri, 10 Jan 2020 15:07 +00:00:
> But: The reference system would be one particular configuration known
> to work, with all the kinks ironed out.
Isn't that just
cd subversion/tests/cmdline && ./davautocheck.sh --no-tests
?
Re: Svn server images / appliances / packages
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jan 10, 2020 at 9:40 AM Julian Foad <ju...@apache.org> wrote:
> Branko Čibej wrote:
> > Nathan Hartman wrote:
> >> If there is a defined "reference system," that makes it possible to
> >> focus on making that configuration as turn-key as possible, and also
> >> to document it as well as possible.
>
> If I understand correctly, the point is to concentrate on one system in
> our efforts to improve the experience of running Subversion, so that we
> avoid diluting our efforts with discussing and accommodating the
> differences between systems.
I think you understand my point but just to be extra clear, I'd like to
emphasize that I'm *not* suggesting to let other systems fall by the
wayside. We would continue having buildbots on different platforms, support
building on different platforms, etc. You would still have infinitely many
possible ways to configure and run a Subversion server, including locally,
svnserve, and httpd.
But: The reference system would be one particular configuration known to
work, with all the kinks ironed out. It would be the system that
documentation writers of a "Subversion Administration" manual could focus
on without diluting their exposition. If someone has trouble with their
system, we could ask "what are you doing differently from the reference
system?" and they'd have a reference point for comparison.
Cheers,
Nathan
Re: Svn server images / appliances / packages
Posted by Julian Foad <ju...@apache.org>.
Branko Čibej wrote:
> Nathan Hartman wrote:
>> If there is a defined "reference system," that makes it possible to
>> focus on making that configuration as turn-key as possible, and also
>> to document it as well as possible.
If I understand correctly, the point is to concentrate on one system in
our efforts to improve the experience of running Subversion, so that we
avoid diluting our efforts with discussing and accommodating the
differences between systems.
Discussing and accommodating other systems should and can still happen,
but it can happen separately (different discussion threads, different
times, different people) so as not to distract (so much) from that
primary effort.
That sounds like a good plan.
>> A reference system [...] is a [...] configuration with the
>> best probability of success, the best documentation, and the best
>> understanding of the potential pitfalls and their solutions or
>> workarounds. [...] It could be docker based, or not.
>
> On most "sane" OSes, administrators are used to the way their upstream
> packager sets up things. [...]
> The most we could do would be for such cases would be to provide
> example configurations for, e.g., LDAP/AD integration etc. That's really
> a part of end-user documentation and should go into the wiki.
That seems to miss the point. A native installation on any "sane" OS
would make a perfectly adequate reference platform, as would a Docker
installation.
> The OS that would be best served by a reference installation (or
> convenience binaries, if you prefer) would be, not so surprisingly,
> Windows. [...]
I'm not quite sure how to interpret that. The primary goal is not to
benefit the chosen platform (although that would of course happen) but
rather to make it easy for contributors to concentrate on something.
The system to concentrate on therefore needs to be one that a large
subset of contributors can work with. I personally am here because I
support FOSS in general. Although I am willing to help anyone who wants
to make Subversion also work well on Windows, I would not support
favouritism toward any proprietary software.
From my limited experience, it seems the most suitable "reference
system" options, ones that are open and that a large sector people in
this space are likely able to work with, would be:
* Ubuntu (server, latest LTS)
* Docker (probably using an Alpine image, or maybe Ubuntu)
- Julian
Re: Svn server images / appliances / packages
Posted by Branko Čibej <br...@apache.org>.
On 10.01.2020 06:14, Nathan Hartman wrote:
> On Thu, Jan 9, 2020 at 11:05 AM Julian Foad <julianfoad@apache.org
> <ma...@apache.org>> wrote:
>
> Branko Čibej wrote:
> > [... Docker...] as much a PITA as maintaining any other server. The
> > installation step is the *least* of your worries.
>
> Well, that's a good point. Maybe the goal of making svn more easily
> deployable is better served by doing something towards making it more
> set-and-forget, removing pitfalls and unnecessary complexities...
>
> Any more concrete thoughts in that direction, anyone?
>
>
> Anything we can do to make Subversion more deployable is potentially
> more people attracted to the project as contributors.
>
> One thought is a "reference system." That would comprise a specific
> hardware platform, specific OS, dependencies, and configuration.
>
> If there is a defined "reference system," that makes it possible to
> focus on making that configuration as turn-key as possible, and also
> to document it as well as possible.
>
> A reference system doesn't mean that everyone is forced to run their
> Subversion server that way, but it is a way of saying that if you're
> between hobbyist and enterprise, here's the configuration with the
> best probability of success, the best documentation, and the best
> understanding of the potential pitfalls and their solutions or
> workarounds.
>
> Now, I recognize that everyone has their favorite OS etc, so that
> might make it difficult to reach consensus on what that "reference
> system" should be.
>
> It could be docker based, or not.
On most "sane" OSes, administrators are used to the way their upstream
packager sets up things. For example, on anything derived from Debian,
you'll have a structured /etc/apache2 and installing libapache2-mod-svn
will put config files with the necessary incantations in the expected
places. The most we could do would be for such cases would be to provide
example configurations for, e.g., LDAP/AD integration etc. That's really
a part of end-user documentation and should go into the wiki.
The OS that would be best served by a reference installation (or
convenience binaries, if you prefer) would be, not so surprisingly,
Windows. However I'd hesitate to provide those without co-ordination
with the httpd and APR projects.
-- Brane
Re: Svn server images / appliances / packages
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jan 9, 2020 at 11:05 AM Julian Foad <ju...@apache.org> wrote:
> Branko Čibej wrote:
> > [... Docker...] as much a PITA as maintaining any other server. The
> > installation step is the *least* of your worries.
>
> Well, that's a good point. Maybe the goal of making svn more easily
> deployable is better served by doing something towards making it more
> set-and-forget, removing pitfalls and unnecessary complexities...
>
> Any more concrete thoughts in that direction, anyone?
Anything we can do to make Subversion more deployable is potentially more
people attracted to the project as contributors.
One thought is a "reference system." That would comprise a specific
hardware platform, specific OS, dependencies, and configuration.
If there is a defined "reference system," that makes it possible to focus
on making that configuration as turn-key as possible, and also to document
it as well as possible.
A reference system doesn't mean that everyone is forced to run their
Subversion server that way, but it is a way of saying that if you're
between hobbyist and enterprise, here's the configuration with the best
probability of success, the best documentation, and the best understanding
of the potential pitfalls and their solutions or workarounds.
Now, I recognize that everyone has their favorite OS etc, so that might
make it difficult to reach consensus on what that "reference system" should
be.
It could be docker based, or not.
Nathan
Re: Svn server images / appliances / packages
Posted by Julian Foad <ju...@apache.org>.
Branko Čibej wrote:
> [... Docker...] as much a PITA as maintaining any other server. The
> installation step is the *least* of your worries.
Well, that's a good point. Maybe the goal of making svn more easily
deployable is better served by doing something towards making it more
set-and-forget, removing pitfalls and unnecessary complexities...
Any more concrete thoughts in that direction, anyone?
- Julian
Re: Svn server images / appliances / packages
Posted by Branko Čibej <br...@apache.org>.
On 08.01.2020 12:53, Julian Foad wrote:
> There's no specific "at home" requirement, although that's always nice
> to have for FOSS. In this thread my concern is that there should be a
> practical option for people wanting or needing to run a server for
> serious use, above hobbyist level and below enterprise (plentiful IT
> resources) level. Solutions that run on paid cloud hosting can be
> within scope if anybody wants to provide and maintain them.
In my experience "serious use" and "install provided docker image" are
inconsistent with "no plentiful IT resources." Specifically, maintaining
a server that just happens to be installed via Docker or some other
equivalent is just as much a PITA as maintaining any other server. The
installation step is the *least* of your worries.
-- Brane