working on prerelease wiki, other notes

[Karsten Wade]

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 at 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
-- 
name:  Karsten 'quaid' Wade, Sr. Community Gardener
team:   Red Hat Community Architecture & Leadership
uri:             http://communityleadershipteam.org
                        http://TheOpenSourceWay.org
gpg:                                       AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20110902/0fa01844/attachment.sig>