working on prerelease wiki, other notes
by Karsten Wade
--z4D23EFnZpzTzcHd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I'm working on a private pre-release wiki space so we can start
getting project and sub-project content staged. This will be at /wiki
so part of this pre-release staging space is to prepare the static
HTML pages for the rest of the project site.
Currently lists.ovirt.org is on a Linode instance. I just need your
sshkey to give you sudo access. (I just set root(a)linode01.ovirt.org
email to come to this list, so we'll start getting logwatch here
tomorrow, etc.)
My plan for MediaWiki right now is to do the staging server on
OpenShift Flex, since they have a MediaWiki example we can fork. The
reason for using Flex is to be able to get the configuration just the
way we want it for easy porting to ovirt.org. (Community Architecture
will cover related expenses for now, should only be a month or so.)
Some random thoughts:
* Project HTML, wiki configuration, and the like should be kept in a
git repository. I'll start a new one somewhere, either
fedorahosted.org or gitorious.org.
* We could get in to the game of hosting our own git repositories,
and I don't see much hassle there if we can get the http+ssh bits
responding ... and we can find a way to deal with growing accounts.
* I'll put MediaWiki at /wiki, put a .htaccess password on it, and set
the contents to only be writable by logged in users. (I could make
it read-only, but then that's double protection and makes it hard to
share the preview via password.)
* I have a way I'd like to setup the wiki account system. On
theopensourceway.org we have permissions configured so that ANY
existing user can make a new account for a NEW user. That is the
only way accounts are created - you have to ask someone to set you
up.
https://www.theopensourceway.org/wiki/How_to_create_a_user_account
To start, I am going to setup the wiki this way. It has the downside
of raising the barrier against casual editors, but it keeps us from
having to patrol the wiki constantly against the ever-cleverer
spammers and their automatic-anti-MediaWiki tools. Adding a new user
is easier than giving commit privileges to git, so I'll argue it's a
reasonable approach for now.
* As part of all this work, I'm going to be putting passwords in a
file in /root so you need sudo access to read it. This is a
lightweight mirroring of what I think Fedora Infrastructure does. It
makes sense to me that once we have given out sudo access to
someone, we want to trust that person to Do the Right Thing and have
all passwords needed to fix anything they break while trying to
do-right.
That's it for now. :)
As a quick reminder, this email list archives are currently private,
but we'll be flipping them to open with the opening of the
project. I'm not concerned about confidential business information in
this channel, and we're going to be open about
infrastructure-save-for-the-passwords ... but just in case, here's my
reminder.
- Karsten
--=20
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture & Leadership
uri: http://communityleadershipteam.org
http://TheOpenSourceWay.org
gpg: AD0E0C41
--z4D23EFnZpzTzcHd
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFOYTTj2ZIOBq0ODEERAvqdAJ9k5t1evkfyk4P3DAdAhJzaQPo9rwCfarEj
2qJZ+4gPKrYY+vRhM8DbK5I=
=muNl
-----END PGP SIGNATURE-----
--z4D23EFnZpzTzcHd--
13 years, 2 months
- 1
- 0