Hosting of OSG related projects
Robert Osfield
related services, and soon we'll be making a decision on where to host
and start migration. There are projects that are in the OSG family,
or presently hosted on current server, what to do about these. Also
as time goes on new projects in the OSG family will grow up and to
provide them with hosting local to the OpenSceneGraph project would be
advantageous too.
I therefore would like to see us be able to offer some form of OSG
Forge facility, initially this could be informal, with just OSG family
projects hosted on the new server. Projects like OpenThreads is an
obvious candidates. Later this week I'll be releasing the newly open
sourced Present3D and this too would be a good candidate.
I don't know what Don wants to do with Producer, I expect him to want
to return full control of the project and host it locally himself.
However, I think it appropriate to offer the possibility of hosting on
the new server.
There are various aspects to hosting - from just svn, to websites and
mailing lists. I'd suggest just sticking to svn in the first
instance. Perhaps never going beyond this, since I'll not be able to
take much of the admin work and not in any place to go volunteering
other peoples time. All I can put out is the notion that it'd be
interesting to be able to provide hosting in some form, what form this
could take will depend on the host of the new server, the engineers
doing the support of the new server, and also the communities will to
support any new initiative in this direction.
Thoughts? Suggestions?
Robert.
Jose L. Hidalgo
Support multiple projects is really easy with subversion. Even if
you have just one repository it can be configured to restrict access to
projects by path. This is done with an access file:
[groups]
projectA = user1, user2
projectB = user1, user3
osg-admins = robert
[/]
*= r
@osg-admins = rw
[/projectA]
@projectA = rw
[/projectB]
@projectB = rw
Here you can se how setup projects with groups. directory permissions
are inherited from parent to child directory, for example the group
osg-admins will be able to write in whatever project, in the same
manner than "* = r" means anybody can read so every single project in
the repository will be accessible.
Basically, it is possible with subversion to give access to many people
with restrictions.
About web hosting and mailing lists, that will depend on the final
hosting solution :)
Cheers,
Jose L.
Robert Osfield
Thanks for the notes of repository access. We'll be needing to grant
access selectively for the different projects, this is one of the nice
things about migrating to svn :-)
Robert.
Jan Ciger
Hash: SHA1
Jose L. Hidalgo wrote:
> Hi Robert,
> Support multiple projects is really easy with subversion. Even if
> you have just one repository it can be configured to restrict access to
> projects by path. This is done with an access file:
>
<...>
> Basically, it is possible with subversion to give access to many people
> with restrictions.
Similar thing is possible with Trac, IMHO. We just need to provide a new
config file+database and a project in the repository and the new project
can have its own wiki, bug tracker and repository browser in addition to
the SVN repo Jose described above.
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFYfKJn11XseNj94gRAk+RAKDR/CJb9xWGyGfwKruZUImVoe4XlACgm1Cc
Hsa6UHgzRICaKtcQyMyGHug=
=AfeS
-----END PGP SIGNATURE-----
Robert Osfield
>
> > Basically, it is possible with subversion to give access to many people
> > with restrictions.
>
> Similar thing is possible with Trac, IMHO. We just need to provide a new
> config file+database and a project in the repository and the new project
> can have its own wiki, bug tracker and repository browser in addition to
> the SVN repo Jose described above.
Mailman is also pretty easy to set up mailing lists with too.
Alternatively you can just point people at google groups or similar.
So this then leaves the domains/project paths.
openscenegraph.org/forge/projectname
Or would sub domains possible? Or just have the above subdirectory
and let the project themselves go buy themselves a domain and point it
at the forge location.
I am a being a bit optimistic, or is really something that could be
done without too much overhead?
Other things to concern ourselves would be the extra opening to
litigation one might expose one selves to with relatively
un-controlled access to parts of the server. Perhaps ones signing up
for the forge service would need to accept responsibility and
liability for there sub project in some way. I don't think this is
really exposing ourselves that much, but it would be worth flagging up
this type of stuff early.
Thoughts/suggestions?
Robert.
Jose L. Hidalgo
On Nov 20, 9:50 pm, "Robert Osfield" <robert.osfi...@gmail.com> wrote:
> So this then leaves the domains/project paths.
>
> openscenegraph.org/forge/projectname
>
> Or would sub domains possible? Or just have the above subdirectory
> and let the project themselves go buy themselves a domain and point it
> at the forge location.
>
> I am a being a bit optimistic, or is really something that could be
> done without too much overhead?
>
You as owner of openscengraph.org are the responsible of creating those
subdomains as
DNS entries. With very little effort we can handle this, look at this
page I've found googleing:
http://steinsoft.net/index.php?site=Programming/Articles/apachewildcarddomain
Basically both DNS, and Apache are able to handle multiple subdomains
at one. Then with
rewriting rules we can redirect (.*).openscenegraph.org -->
openscenegraph.org/forge/$1
with no problem.
> Other things to concern ourselves would be the extra opening to
> litigation one might expose one selves to with relatively
> un-controlled access to parts of the server. Perhaps ones signing up
> for the forge service would need to accept responsibility and
> liability for there sub project in some way. I don't think this is
> really exposing ourselves that much, but it would be worth flagging up
> this type of stuff early.
Access to wiki and subversion only should not expose critical things.
The very problem giving access to projects is the much more amount of
work of handling n-users with n-projects....
Jose L.
Robert Osfield
On 11/20/06, Jose L. Hidalgo <joseLuis...@gmail.com> wrote:
> You as owner of openscengraph.org are the responsible of creating those
> subdomains as
> DNS entries. With very little effort we can handle this, look at this
> page I've found googleing:
> http://steinsoft.net/index.php?site=Programming/Articles/apachewildcarddomain
>
> Basically both DNS, and Apache are able to handle multiple subdomains
> at one. Then with
> rewriting rules we can redirect (.*).openscenegraph.org -->
> openscenegraph.org/forge/$1
> with no problem.
Thanks for info.
> > Other things to concern ourselves would be the extra opening to
> > litigation one might expose one selves to with relatively
> > un-controlled access to parts of the server. Perhaps ones signing up
> > for the forge service would need to accept responsibility and
> > liability for there sub project in some way. I don't think this is
> > really exposing ourselves that much, but it would be worth flagging up
> > this type of stuff early.
>
> Access to wiki and subversion only should not expose critical things.
Indeed. I was assuming restricted access to the server. The
litigation side I was thinking of was some copyright owner or patent
troll coming knocking at our door because the "infringing" project is
hosted on as part of our site.
> The very problem giving access to projects is the much more amount of
> work of handling n-users with n-projects....
My expectation would that most forge projects would be relatively
small in size, with just a one or two engineers do the dev work.
They'd have to be OpenSceneGraph related too.
For big projects that need lots of bandwidth and lots of control then
they wouldn't be great candidates for the forge, or perhaps could
start off in the forge, incubate and then finally go with their own
servers etc when they get big enough.
I wouldn't be surprised if we'd only be talking about half a dozen
projects too.
One thing you could use the forge for is project grooming. So if a
project looks interesting as a possible candidate for future
integration with the core OSG, or to end up distributed in binary
packages as part of the OSG family, then the first step to getting
closer to the core would be the Forge. osgLua and osgPython would be
good examples of the type of project I see as being well suited for
this Forge facility.
Cheers,
Robert.
Jose L. Hidalgo
On Nov 20, 10:46 pm, "Robert Osfield" <robert.osfi...@gmail.com> wrote:
> I was assuming restricted access to the server. The
> litigation side I was thinking of was some copyright owner or patent
> troll coming knocking at our door because the "infringing" project is
> hosted on as part of our site.
Wops, that is a very bad problem. As you said before, the best solution
seems to
make the users responsible of their own projects. :( I will try to
ask in the uni about this.
> > The very problem giving access to projects is the much more amount of
> > work of handling n-users with n-projects....
> My expectation would that most forge projects would be relatively
> small in size, with just a one or two engineers do the dev work.
> They'd have to be OpenSceneGraph related too.
>
> For big projects that need lots of bandwidth and lots of control then
> they wouldn't be great candidates for the forge, or perhaps could
> start off in the forge, incubate and then finally go with their own
> servers etc when they get big enough.
Well they should not be bigger than OSG, even If they are I expect
bandwidth
not to be a problem.
> I wouldn't be surprised if we'd only be talking about half a dozen
> projects too.
Well, I don't see any problem if they are few projects, more precisely
while they don't give to much work to the admins ;) I don't want an
admin calling me because the osgLua guy is asking for this or that
all the time. XD
> One thing you could use the forge for is project grooming. So if a
> project looks interesting as a possible candidate for future
> integration with the core OSG, or to end up distributed in binary
> packages as part of the OSG family, then the first step to getting
> closer to the core would be the Forge. osgLua and osgPython would be
> good examples of the type of project I see as being well suited for
> this Forge facility.
Indeed, that will allow better development of those projects...
Cheers,
Jose L.
Jan Ciger
Hash: SHA1
Robert Osfield wrote:
> Mailman is also pretty easy to set up mailing lists with too.
> Alternatively you can just point people at google groups or similar.
Indeed - creating a new list in Mailman is a matter of 5 minutes - one
command and copy&pasting the output into the aliases file of the MTA. If
you do not have your own MTA then it could be an issue (having to ask
the hoster to update a central file, etc.)
>
> So this then leaves the domains/project paths.
>
> openscenegraph.org/forge/projectname
This is easily doable with Apache mod_rewrite module. However, you need
to run your own Apache, it is likely not possible with shared hosting.
> Or would sub domains possible? Or just have the above subdirectory
> and let the project themselves go buy themselves a domain and point it
> at the forge location.
You could probably get the second level domains without too much hassle
- - ask the hosting provider. These tend to be free as well, since they do
not require central registration with a domain registry, only in the DNS
of the provider.
Then you can get a virtual host for each subdomain pointing into a
separate directory (different document root). This is a standard feature
of Apache and this is actually how shared hosters are doing it.
> I am a being a bit optimistic, or is really something that could be
> done without too much overhead?
This is easily (relatively) doable if you have your own server that you
fully control. It could be a problem if you have only shared hosting -
ask your hosting provider.
> Other things to concern ourselves would be the extra opening to
> litigation one might expose one selves to with relatively
> un-controlled access to parts of the server. Perhaps ones signing up
> for the forge service would need to accept responsibility and
> liability for there sub project in some way. I don't think this is
> really exposing ourselves that much, but it would be worth flagging up
> this type of stuff early.
IANAL, but if they sign a waiver to take responsibility for anything
they put there, it should be fine - same as the ISP/hoster is not
responsible for what you put there. However, you may want to check it
with a lawyer, especially if the hosting company is in the US :(
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFYjEbn11XseNj94gRAg7RAJ44kJEHJnJfhr7gw5DBLjsWTdnq3ACeKgGC
xfs92LjXidLsQ0U2wgP3pK0=
=qRst
-----END PGP SIGNATURE-----