Bugs - Page locking
... but to start with, I have a suggestion to modify locking and editing conflict prevention at some point (not high priority). Currently pages are locked for a time period whilst being edited, and the lock can be removed by clicking cancel or save. There's a minor bug where if a user edits a page, then clicks preview and again clicks preview, the page also becomes locked to the editing user. Rather than mandatory timeout locking, I'd prefer to see conflicts solved by:
- storing in the database the time at which a page was retrieved for editing
- notifying anyone attempting to reedit that page within a certain period wherein the previous edit had not been saved of the situation, allowing them to decide whether to proceed anyway
- storing the time the page was retrieved for editing in the form to be submitted when it is saved
- upon submitting an edit for saving, checking whether it has been saved by someone else since the date of retrieval. If so, notifying the editor and allowing them to automatically/manually merge changes.
The main drawback is that the original editor won't be informed during editing if someone else changes the page under them, but the other person will have been warned. Unless it's a huge change, an automatic merge should be feasible anyway.
--Netocrat 01:33, 31 August 2005 (BST)
Re: Page Locking...
I can't get it to lock on me using Firefox under Windows and Linux. I've even had it editing logged in as two different users and not hit this problem.
--Flash Gordon 20:25, 1 September 2005 (BST)
Re: Page Locking...
Right, I use Firefox on Linux which is where the problem occurred. I can't repeat it, and now that I recall, when it occurred I was blocked from editing all protected pages, not just the one I had recently previewed, so it must have been related to a config change you were in the process of making or a transient bug. I've seen it a couple of times since. Also, I can't get it to lock when editing by a separate user as you say but I've just tested and conflict resolution already works as I propose - conflicts result in a warning and opportunity to manually merge, which is good, so disregard that proposal. But locking seems to be a little buggy.
--Netocrat 20:46, 1 September 2005 (BST)
Site structuring and formatting
I think we need to decide on some kind of structure for the site and see about getting it organised for putting in clc FAQ entries etc.
--Flash Gordon 00:01, 31 August 2005 (BST)
I agree with Flash and will make some suggestions on site structure and content soon
The above was moved down from the top by me to group stuff togester. --Flash Gordon 13:08, 6 September 2005 (BST)
Giannis' Suggestions And Questions Moved From Main Decisions Page And Paraphrased::
- We should add licencing to the "About clc" and to "General Disclaimer"
- My response: agree but keep this kind of administrative talk to the page to which I've moved it
- Flash's response: agree (also note that the "Content available under... bit at the bottom of all pages can be changed)
- I tried to add the first FAQ, just to see how it would look like ( in Loops) however I can't create a link from the full title. Should we use the form
- Question? answer
However, we should choose unique and consistent names for the answer links... Does anyone knows a better way? - My response: Yes, use sections - see http://meta.wikimedia.org/wiki/Help:Section
Another option is to use templates: http://meta.wikimedia.org/wiki/Help:Template#Other_duplication_of_content- Giannis: OK, I'll check it out...
- Question? answer
- Who would contact Steve Summit for "FAQ donation"? Mention that everything is under the FDL etc etc etc.
- My response: First let's draft the email, agree on it and then send it co-signed by all of us.
- I do not think that the author of http://www.plethora.net/~seebs/faqs/c-iaq.html should be contacted. Most of the FAQs are not very helpful and are really misguiding (since it is more or less a FAQ full of jokes).
- My response: Agreed - it's a playful/facetious FAQ and not appropriate as seed material for this wiki.
- My response: Agreed - it's a playful/facetious FAQ and not appropriate as seed material for this wiki.
--Netocrat 23:46, 3 September 2005 (BST)
- We can use a namespace to separate these planning pages logically from the actual content of the wiki. It means identically named pages can be created in each namespace. I'd suggest the new namespace be called "planning". Flash you would need to create the namespace as described at http://meta.wikimedia.org/wiki/Help:Custom_namespaces since it requires changes to the php pages. Then the pages Decisions, Planning status, Justifications, Public comments, Planned structure and Loops would be moved to that namespace. This link has more general info on namespaces: http://meta.wikimedia.org/wiki/Help:Namespace
- We can (and should) also use categories to structure content; see http://meta.wikimedia.org/wiki/Help:Category
- Another option is subpages, which are not enabled by default and probably we don't need them in the main namespace: http://meta.wikimedia.org/wiki/Sub_pages
- Look at this link to see how we can use templates:
- http://meta.wikimedia.org/wiki/Help:A_quick_guide_to_templates
- and especially for variable content i.e. a template can take parameters as though it were a function http://meta.wikimedia.org/wiki/Help:Template_names%2C_variable_names_and_parameters_depending_on_a_variable_or_parameter
--Netocrat 00:39, 4 September 2005 (BST)
I'm a little busy with work at the moment so don't have time to read through this. If someone tells me specifically what to put in I'll do it.
--Flash Gordon 20:41, 5 September 2005 (BST)
The minimum that you personally need to do is add this text to the LocalSettings.php file for the site(s) - staging site too:
$wgExtraNamespaces = array(100 => "Planning", 101 => "Planning_Talk" );
I or someone else can then move the pages into the new namespaces.
--Netocrat 05:21, 6 September 2005 (BST)
OK, I've done that. When you've tested we can decide on other name spaces, such as Configuration, Administration, spaces for FAQ entries etc.
--Flash Gordon 13:04, 6 September 2005 (BST)
People, please note that we get a contents list for free on the page when we use sections. Any text before the first section appearing above the contents list.
--Flash Gordon 13:11, 6 September 2005 (BST)
I've moved all appropriate pages to the new planning namespace and deleted old pages from the original namespace - the old pages are converted into a redirect to the new page which seemed a little messy to me; instead I've changed all links in pages to refer to the new namespace. Quite a lot of fiddly work involved but I've also added templates that limit the amount of work involved in changing links in the future. These templates are template:locked non-category planning page and template:locked category planning page and can be included in a page by replacing the [[ and ]] with {{ and }}. They should be included in all locked planning pages to provide the viewer with reason why the page is locked from public edits and to provide a link to the wiki planning category, which I've also added.
Flash, as regards more namespaces, I think that they should be kept to a minimum - configuration, admin could all go under planning. Main site content including FAQ entries should all go under the default namespace which I think is (articles). The main reason I say this is the display of the namespace prefix - every link to an article in the namespace has to be prefixed with the namespace and a colon and to prevent that showing in the link display, one has to type a pipe symbol and retype the text one wants to display for the link. This is a problem in category pages where the pages within the category are prefixed with their namespace - I haven't found a way to prevent this as with other links since those pages are added automatically, but probably there is a way that I haven't yet come across.
The main reason I suggested a separate planning namespace is to separate meta-level content (talk about the wiki) from the actual content of the wiki. Of course if you can see compelling reasons for different namespaces, go ahead and say so (one reason is the ability to have identically named articles in the different namespaces, but I think we can get around this in other ways).
--Netocrat 23:38, 6 September 2005 (BST)
Draft email to Steve Summit
Steve,
There has been recent suggestion that a wiki be created for the comp.lang.c newsgroup and that it have status as the official wiki of the group. There were some suggestions in the thread that this could satisfactorily be achieved by limiting edits/moderation to a set of trusted/senior members of the group.
It was also suggested that the current FAQ or part of it be used to seed the wiki, however it was noted that you hold copyright on this FAQ and that your permission should be sought on this issue: http://groups.google.com/group/comp.lang.c/msg/cef967f2ab5c3a4b http://groups.google.com/group/comp.lang.c/msg/a590be57125b1a36
Those of us who have started planning the site actively have thus drafted this email to you to seek a response. Our individual contact addresses are as listed in the CCs of this email.
We have chosen the GNU Free Documentation License (currently at version 1.2) to cover the content of the wiki. It can be viewed at http://www.gnu.org/copyleft/fdl.html.
You can view the planning site for the wiki at http://clc.flash-gordon.me.uk.
Regards,
The comp.lang.c wiki planners
Sending it
Once everyone is happy with the draft, I suggest Flash (as site host) or Giannis (as initial proposer of the wiki) send it with CC's to all of us... unless Mark H. becomes active and gives his approval he shouldn't be included in the CCs.
Indicate whether you are satisfied with the draft, and if you amend the draft, add "(draft later changed)" after the "agree" of anyone who has done so.
I'm happy for the draft to be sent (whoever of Flash and Giannis sees this first when everyone has agreed, go ahead and send it):
Netocrat | agree (that just leaves you Flash - go ahead and send it unless you propose any changes) | |
Ipapadop | agree (I really think I shouldn't be sending it. I believe Flash is our man. After all he has done all the dirty work.) | |
FlashGordon | I should have known I was making work for myself by doing this! OK, OK, I'll look at the FAQ for his address and send the email! | |
Mark H |
I meant to put a smiley on my comment.
The email has been sent, now we just have to wait for a response.
--Flash Gordon 13:24, 6 September 2005 (BST)
Server Administration
Netocrat and I (Flash) had some brief discussions on this by email some time back. A summary is that Netocrat wanted to be able to get backups of the SQL DB and suggested a web based admin tool, I suggested perhaps something using ssh since I'm more familiar with that and the security risks.
Having reminded myself of my previous investigations, here is how the stuff with ssh I was thinking about would go.
- It would be done using public/private key authentication and ssh protocol 2 only.
- Each key can be locked to execute only 1 command, although the full command is available so it could be a script which provides you with limited options like this.
- Someone writes a scrip that provides the required admin functions and nothing else. Dumping the database, running mysql using the mediawiki DB user account, anything else I am prepared to agree to that people think is justified.
- The script must include logging.
- We need some way for people to submit requests to be given access, and even if we have voting on it (which would be fine by me) whilst it is my machine I would maintain an absolute veto right.
- When someone is to be added, I need there public key so I can create an account for them and put the key in it.
Sounds fine. I'll put a script together and send it on.
--Netocrat 05:21, 6 September 2005 (BST)
After looking at it, the best solution I can see is the simplest: create a forced script with these two lines (replacing username and password as appropriate):
# /bin/sh /usr/bin/mysqldump -u <username> --password=<password> -e --lock-tables --add-drop-table wikidb | /bin/bzip2 -c
Then you simply need to create a generic account and create the file ~/.ssh/authorized_keys for that account, adding a line such as the following for each person who requires access (this includes my ssh public key which you can add; and you'll obviously need to replace <forcedscriptname>):
command="<forcedscriptname>" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0w1pEMGLGhSUKE+OwZ0C0ENqxpHUiHTZPHOak+XwJMKK2nBr1oTb9DDAxucVpOIqZkEX0b/Mxo5NfG/It+AUZldNcpH4Xubh4XBghv+J9BPr5k59/rUjcmzUE2QPPXpR8j2yU80l9/4pnYSFYdGmIMs6iQl+WZGcBuMFElHtutc=
Now for me to get a copy of the database file I'd run from my local machine:
ssh genericuser@clc.flash-gordon.me.uk > clcwikidump.sql.bz2
An alternative is to as you suggested have a menu-driven script allowing other things; one of the options would be to generate a web-accessible dump file. That would make the dumpfile accessible to people other than those with an account on your server which is probably a good way to go.
--Netocrat 16:58, 15 October 2005 (BST)
...and here is that alternative: Create the forced script as:
#! /bin/sh unset ans; tmpfile="/tmp/wikidbdumpfile.bz2.$$" rootmysqlpw="" mvscript="~/bin/mvdumpfiletowebloc" /bin/echo "Welcome!" while [ "$ans" != "q" ] do /bin/echo "Your choices are: 1 Dump and compress clc wiki database q Quit" /bin/echo -n "Your choice: " read ans case "$ans" in 1) /bin/echo "Dumping and compressing database with bzip2..." /usr/bin/mysqldump -u root --password="$rootmysqlpw" -e --lock-tables --add-drop-table wikidb | /bin/bzip2 -c > $tmpfile webloc=`sudo $mvscript $tmpfile` /bin/echo "...done." /bin/echo "File now available from $webloc" ;; q) /bin/echo "Goodbye" exit 0 ;; *) /bin/echo "Invalid choice '$ans': please try again" ;; esac done exit 0
Create the mvdumpfiletowebloc script as:
#! /bin/sh dumpfilename="clcwikidb.sql.bz2" dumpfile="/data/www/localhost/htdocs/$dumpfilename" webloc="http://clc.flash-gordon.me.uk/$dumpfilename" mv $1 $dumpfile echo $webloc exit 0
Add permission for the generic ssh account to run mvdumpfiletowebloc with appropriate permissions (to be able to write within the webserver's file hierarchy) to the sudoers file, e.g.:
$ visudo
[add the following line then save the sudoers file]
<sshaccountname> ALL = (root) NOPASSWD: <pathto_mvdumpfiletowebloc_script>
One final alternative is to automate this through a cgi script; but I won't go there for the moment.
--Netocrat 12:43, 24 October 2005 (BST)
I've implemented something slightly different. Expandable like the menu but easier to do do dumps. The script checks what command you specify and behaves differently depending on the command. Tell it to dump and it will dump, currently anything else and it will tell you it was not allowed. The script is:
#!/bin/sh case "$SSH_ORIGINAL_COMMAND" in dump) mail -s "clc database dump" clc-admin@flash-gordon.me.uk << EOF Command: $SSH_ORIGINAL_COMMAND Connection: $SSH_CONNECTION EOF /usr/bin/mysqldump -u <wikidbuser> --password=<password> -e --lock-tables --add-drop-table wikidb `/usr/bin/mysqlshow -uwikiuser -p<password> wikidb|grep clc_|cut -d'|' -f2` | /bin/bzip2 -c ;; *) mail -s "clc illegal admin command" clc-admin@flash-gordon.me.uk << EOF Command: $SSH_ORIGINAL_COMMAND Connection: $SSH_CONNECTION EOF echo "Command \"$SSH_ORIGINAL_COMMAND\" not allowed" ;; esac
To dump the database use
ssh clc@home.flash-gordon.me.uk dump > clc.sql.bz2
In .ssh/authorized_keys I add keys as follows:
Comment: Netocrat's key no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/home/sodall/clcadmin" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0w1pEMGLGhSUKE+OwZ0C0ENqxpHUiHTZPHOak+XwJMKK2nBr1oTb9DDAxucVpOIqZkEX0b/Mxo5NfG/It+AUZldNcpH4Xubh4XBghv+J9BPr5k59/rUjcmzUE2QPPXpR8j2yU80l9/4pnYSFYdGmIMs6iQl+WZGcBuMFElHtutc=
which should prevent people from tunnelling anything in to my network thus protecting both the clc site and everything of mine. --Flash Gordon 00:26, 26 October 2005 (BST)
I've updated the admin script to allow copying the live database to the new test database. Currently this explicitly excludes the vote and decition tables. The new script (I hope without sensitive information) is
#!/bin/sh case "$SSH_ORIGINAL_COMMAND" in dump) mail -s "clc database dump" clc-admin@flash-gordon.me.uk << EOF Command: $SSH_ORIGINAL_COMMAND Connection: $SSH_CONNECTION EOF /usr/bin/mysqldump -u <wikidbuser> --password=<password> -e --lock-tables --add-drop-table wikidb `/usr/bin/mysqlshow -uwikiuser -p<password> wikidb|grep clc_|cut -d'|' -f2` | /bin/bzip2 -c ;; cp_l2t) mail -s "clc copy live to test" clc-admin@flash-gordon.me.uk << EOF Command: $SSH_ORIGINAL_COMMAND Connection: $SSH_CONNECTION EOF /usr/bin/mysqldump -u <wikidbuser> --password=<password -e --lock-tables --add-drop-table wikidb `/usr/bin/mysqlshow -u<wikidbuser> -p<password> wikidb|grep -v clc_vote|grep -v clc_decision|grep clc_|cut -d'|' -f2` | mysql -u <testwikidbuser> --password=<passwork> test_wiki ;; *) mail -s "clc illegal admin command" clc-admin@flash-gordon.me.uk << EOF Command: $SSH_ORIGINAL_COMMAND Connection: $SSH_CONNECTION EOF echo "Command \"$SSH_ORIGINAL_COMMAND\" not allowed" ;; esac
--Flash Gordon 23:43, 14 February 2006 (GMT)
Server Upgrade
Could you please test the staging site and see if you think I should go live with the latest release candidate of Mediawiki? It is running on the live database, so changes there show up here and vice-versa. If people are happy I can go live with it any time.
I'm currently using it in preference to the original and will let you know if I come across any problems - none so far.
--Netocrat 05:21, 6 September 2005 (BST)
I'll upgrade the main site some time on Friday if no problems have been uncovered before then.
--Flash Gordon 22:36, 6 September 2005 (BST)
The tag below (only visible when editing) adds this page to the "wiki planning" category and should not be removed. More than one such tag may be present to add the page to multiple categories. In general, it's recommended that such tags occur at the very bottom of the page.
--Netocrat 23:38, 6 September 2005 (BST)