working on prerelease wiki, other notes

--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 --z4D23EFnZpzTzcHd--