I asked Shawn to make it so that http://svn.osgeo.org/ didn't respond
with the same content as the main site.
Jason
-----Original Message-----
From: sac-bounces@lists.osgeo.org [mailto:sac-bounces@lists.osgeo.org]
On Behalf Of Howard Butler
Sent: Friday, January 19, 2007 16:06
To: System Administration Committee Discussion/OSGeo
Subject: Re: [SAC] Subversion is 403 right now
I think that it should be re-enabled, at least long enough to switch the sites over to SSL.
However, I think a better solution would be to make svn.osgeo.org its own virtual server, rather than relying on an alias within www.osgeo.org. This would have the desired results without requiring any client-side changes.
If we have multiple sites that answer for the content at www.osgeo.org, there's a strong possibility of being penalised by the search engines. A large part of OSGeo's role is marketing, and search engine ranking is important.
Does SVN require an account on the server? If so, isn't it more secure to require SSL?
Jason
________________________________
From: sac-bounces@lists.osgeo.org on behalf of Howard Butler
Sent: Sun 2007-01-21 12:16 PM
To: System Administration Committee Discussion/OSGeo
Subject: Re: [SAC] Subversion is 403 right now
It means you have to re-check out and manually merge because svn
switch will not work if it cannot read from its old repository.
I think that it should be re-enabled, at least long enough to switch the sites over to SSL.
However, I think a better solution would be to make svn.osgeo.org its own virtual server, rather than relying on an alias within www.osgeo.org. This would have the desired results without requiring any client-side changes.
If we have multiple sites that answer for the content at www.osgeo.org, there's a strong possibility of being penalised by the search engines. A large part of OSGeo's role is marketing, and search engine ranking is important.
Understood. Another big part of OSGeo is actually writing the software
Does SVN require an account on the server? If so, isn't it more secure to require SSL?
SVN requires an LDAP account to be able to commit to the repository. Ideally, we allow anonymous (http) checkout and read access and authenticated (https) commit access. If you are a committer, you should be working with an https repository. I think that CN just always used https to eliminate the ambiguity. It isn't a problem to switch between http and https if you are committer and can actually read both repositories though.
my apologies...i had a rule to rewrite svn.osgeo.org to a 403 i had
tested to see if you could still svn.osgeo.org/svn/project but, i guess
i was really testing my browsers cache.
So consensus is virtual host for svn.osgeo.org?
trac is installed and i'm currently working on importing fdo and
mapguide bugs from cn into trac. this is taking a little longer than i
had hoped as the cn's bug/artifact tracker is quite different than trac.
shawn
Howard Butler wrote:
On Jan 21, 2007, at 2:43 PM, Jason Birch wrote:
I think that it should be re-enabled, at least long enough to switch
the sites over to SSL.
However, I think a better solution would be to make svn.osgeo.org its
own virtual server, rather than relying on an alias within
www.osgeo.org. This would have the desired results without requiring
any client-side changes.
If we have multiple sites that answer for the content at
www.osgeo.org, there's a strong possibility of being penalised by the
search engines. A large part of OSGeo's role is marketing, and search
engine ranking is important.
Understood. Another big part of OSGeo is actually writing the software
Does SVN require an account on the server? If so, isn't it more
secure to require SSL?
SVN requires an LDAP account to be able to commit to the repository.
Ideally, we allow anonymous (http) checkout and read access and
authenticated (https) commit access. If you are a committer, you should
be working with an https repository. I think that CN just always used
https to eliminate the ambiguity. It isn't a problem to switch between
http and https if you are committer and can actually read both
repositories though.
Are you actively making changes to the Trac architecture or restarting it, etc? Or can we start to use an instance of it for WebCom, SAC issues now?
Tyler
On 22-Jan-07, at 5:57 AM, shawn barnes wrote:
Fixed for now.
my apologies...i had a rule to rewrite svn.osgeo.org to a 403 i had
tested to see if you could still svn.osgeo.org/svn/project but, i guess
i was really testing my browsers cache.
So consensus is virtual host for svn.osgeo.org?
trac is installed and i'm currently working on importing fdo and
mapguide bugs from cn into trac. this is taking a little longer than i
had hoped as the cn's bug/artifact tracker is quite different than trac.
shawn
Howard Butler wrote:
On Jan 21, 2007, at 2:43 PM, Jason Birch wrote:
I think that it should be re-enabled, at least long enough to switch
the sites over to SSL.
However, I think a better solution would be to make svn.osgeo.org its
own virtual server, rather than relying on an alias within
www.osgeo.org. This would have the desired results without requiring
any client-side changes.
If we have multiple sites that answer for the content at
www.osgeo.org, there's a strong possibility of being penalised by the
search engines. A large part of OSGeo's role is marketing, and search
engine ranking is important.
Understood. Another big part of OSGeo is actually writing the software
Does SVN require an account on the server? If so, isn't it more
secure to require SSL?
SVN requires an LDAP account to be able to commit to the repository.
Ideally, we allow anonymous (http) checkout and read access and
authenticated (https) commit access. If you are a committer, you should
be working with an https repository. I think that CN just always used
https to eliminate the ambiguity. It isn't a problem to switch between
http and https if you are committer and can actually read both
repositories though.
I'll create an instance of trac for sac and webcom today or early
tomorrow morning (EST).
what access levels are needed? who can read and who can submit tickets?
shawn
Tyler Mitchell wrote:
Are you actively making changes to the Trac architecture or restarting
it, etc? Or can we start to use an instance of it for WebCom, SAC
issues now?
Tyler
On 22-Jan-07, at 5:57 AM, shawn barnes wrote:
Fixed for now.
my apologies...i had a rule to rewrite svn.osgeo.org to a 403 i had
tested to see if you could still svn.osgeo.org/svn/project but, i guess
i was really testing my browsers cache.
So consensus is virtual host for svn.osgeo.org?
trac is installed and i'm currently working on importing fdo and
mapguide bugs from cn into trac. this is taking a little longer than i
had hoped as the cn's bug/artifact tracker is quite different than trac.
shawn
Howard Butler wrote:
On Jan 21, 2007, at 2:43 PM, Jason Birch wrote:
I think that it should be re-enabled, at least long enough to switch
the sites over to SSL.
However, I think a better solution would be to make svn.osgeo.org its
own virtual server, rather than relying on an alias within
www.osgeo.org. This would have the desired results without requiring
any client-side changes.
If we have multiple sites that answer for the content at
www.osgeo.org, there's a strong possibility of being penalised by the
search engines. A large part of OSGeo's role is marketing, and search
engine ranking is important.
Understood. Another big part of OSGeo is actually writing the
software
Does SVN require an account on the server? If so, isn't it more
secure to require SSL?
SVN requires an LDAP account to be able to commit to the repository.
Ideally, we allow anonymous (http) checkout and read access and
authenticated (https) commit access. If you are a committer, you should
be working with an https repository. I think that CN just always used
https to eliminate the ambiguity. It isn't a problem to switch between
http and https if you are committer and can actually read both
repositories though.
I'll create an instance of trac for sac and webcom today or early
tomorrow morning (EST).
what access levels are needed? who can read and who can submit tickets?
Shawn,
Can we allow anonymous users submit tickets? Since we have no mechanism
in place for lightweight user signup yet, we pretty much will need to
allow anonymous submissions I would think.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
what would you like the instance to be called. i'll initialize it this
afternoon so you can take a look.
shawn
Frank Warmerdam wrote:
shawn barnes wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll create an instance of trac for sac and webcom today or early
tomorrow morning (EST).
what access levels are needed? who can read and who can submit tickets?
Shawn,
Can we allow anonymous users submit tickets? Since we have no mechanism
in place for lightweight user signup yet, we pretty much will need to
allow anonymous submissions I would think.
Allowing anonymous submission over the web these days inevitably leads to spam... we've all seen wikis being spammed... I've even seen bugzilla which requires signing up for a user account being spammed. I don't know Trac but I'd think about it twice before allowing anonymous users to submit tickets.
Daniel
shawn barnes wrote:
Yes it's easy to set up anonymous submissions.
what would you like the instance to be called. i'll initialize it this
afternoon so you can take a look.
shawn
Frank Warmerdam wrote:
shawn barnes wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll create an instance of trac for sac and webcom today or early
tomorrow morning (EST).
what access levels are needed? who can read and who can submit tickets?
Shawn,
Can we allow anonymous users submit tickets? Since we have no mechanism
in place for lightweight user signup yet, we pretty much will need to
allow anonymous submissions I would think.
Allowing anonymous submission over the web these days inevitably leads
to spam... we've all seen wikis being spammed...
Daniel is right.
I've noticed spam comments on my personal Trac installation,
also AFAIK Trac of QGIS project has experienced it too.
May be for anonymous submission it's possible to use
dummy user/password and explain the procedure on TracWiki.
Folks,
Yes, this would be fine. The point is (for now) we can't expect people to
first request Shawn, Howard or I to create them an LDAP userid manually before
they can even report a small issue they would like to see fixed.
Once it is easy for folks to signed up at www.osgeo.org as a new user and get
an unpriveledged LDAP account, we can use those for authentication and remove
the dummy account.
We really need the new member / new user creation capability!
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
On 1/22/07, Daniel Morissette <dmorissette@mapgears.com> wrote:
Allowing anonymous submission over the web these days inevitably leads
to spam... we've all seen wikis being spammed... I've even seen bugzilla
which requires signing up for a user account being spammed. I don't know
Trac but I'd think about it twice before allowing anonymous users to
submit tickets.
In the GRASS RT bugtracker which automatically sends the report
to the grass-dev list, I use "bogofilter" in /etc/aliases before these mails
reach the grass-dev Mailman list. This catches 99.x% of the problems.
On 1/21/07, Markus Neteler <neteler.osgeo@gmail.com> wrote:
On 1/20/07, Jason Birch <Jason.Birch@nanaimo.ca> wrote:
> My fault I think.
>
> I asked Shawn to make it so that http://svn.osgeo.org/ didn't respond
> with the same content as the main site.
>
> Jason
Jason, Shawn,
does this mean that we have to check out everything again?
I had checked out GDAL via https, but today it says:
svn up
svn: PROPFIND request failed on '/svn/gdal/trunk/gdal'
svn: Could not open the requested SVN filesystem
SVN can lock if a ctrl-c is used to abort a checkout.
shawn
Markus Neteler wrote:
Hi SAC,
On 1/21/07, Markus Neteler <neteler.osgeo@gmail.com> wrote:
On 1/20/07, Jason Birch <Jason.Birch@nanaimo.ca> wrote:
> My fault I think.
>
> I asked Shawn to make it so that http://svn.osgeo.org/ didn't respond
> with the same content as the main site.
>
> Jason
Jason, Shawn,
does this mean that we have to check out everything again?
I had checked out GDAL via https, but today it says:
svn up
svn: PROPFIND request failed on '/svn/gdal/trunk/gdal'
svn: Could not open the requested SVN filesystem
SVN can lock if a ctrl-c is used to abort a checkout.
Shawn (Howard?),
Is there seriously no way around this other than someone doing something
on the server? I find it hard to imagine that "next generation" source
control software would have such an obvious gotcha that is unsolvable.
Is it that we are using the wrong kind of back end database?
Given the glacial speed that svn https transactions happen over my satellite
link I find myself frequently control-c'ing things in the middle when I
realize I am not doing what I want. I *may* be able to train myself out of
this, but I hardly expect everyone to be well behaved.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
I suspect that part of the issue is that we are running an ancient version of subversion -- 1.1.4 -- instead of a more current version like the latest stable -- 1.4.3. I know there have been numerous improvements in the svn DAV module, and it's probable that the lock and 'svn recover' issues with Ctrl-C have been fixed in these later versions.
Howard
At 10:06 AM 1/29/2007, Frank Warmerdam wrote:
shawn barnes wrote:
Marcus,
This is now fixed.
SVN can lock if a ctrl-c is used to abort a checkout.
Shawn (Howard?),
Is there seriously no way around this other than someone doing something
on the server? I find it hard to imagine that "next generation" source
control software would have such an obvious gotcha that is unsolvable.
Is it that we are using the wrong kind of back end database?
Given the glacial speed that svn https transactions happen over my satellite
link I find myself frequently control-c'ing things in the middle when I
realize I am not doing what I want. I *may* be able to train myself out of
this, but I hardly expect everyone to be well behaved.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org Sac Info Page
The issue is the version of berkeley db and svn.
i'm testing an upgrade of both on another server... if works out i will
upgrade the server tomorrow.
shawn
Howard Butler wrote:
I suspect that part of the issue is that we are running an ancient
version of subversion -- 1.1.4 -- instead of a more current version like
the latest stable -- 1.4.3. I know there have been numerous
improvements in the svn DAV module, and it's probable that the lock and
'svn recover' issues with Ctrl-C have been fixed in these later versions.
Howard
At 10:06 AM 1/29/2007, Frank Warmerdam wrote:
shawn barnes wrote:
Marcus,
This is now fixed.
SVN can lock if a ctrl-c is used to abort a checkout.
Shawn (Howard?),
Is there seriously no way around this other than someone doing something
on the server? I find it hard to imagine that "next generation" source
control software would have such an obvious gotcha that is unsolvable.
Is it that we are using the wrong kind of back end database?
Given the glacial speed that svn https transactions happen over my
satellite
link I find myself frequently control-c'ing things in the middle when I
realize I am not doing what I want. I *may* be able to train myself
out of
this, but I hardly expect everyone to be well behaved.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
