This Wiki was set up in 2006 by Marshall Perrin, with input and suggestions from Jason Wright and Conor Laver. Its maintenance is the job of the current Student Webmaster.

Use the talk page for discussing wiki-administration-related ideas.

Everything is currently on serpens.berkeley.edu, AKA badgrads.berkeley.edu. I don't know where the hardware is or who formally owns it.

The DokuWiki files are in /export/astroweb/badgrads, which does not seem to be network-accessible right now. They are version-controlled in a Git repository with some site-specific customizations. See below for more details on how the repository works.

The file permissions setup is a little complicated. The reason for this is that multiple administrator uses *and* the webserver all need to be able to write files in the DokuWiki tree. The tree is owned by group webadmin with group write bits active. The directories have their setgid bits set so that files created within them get put in the webadmin group regardless of who creates them. If you're going to modify the files, you obviously need to be a member of webadmin. You also need to set your umask to 002, so that files you create are group-writeable and other administrators can modify them. The permissions on the DokuWiki installation have been set up to create files with the right modes.

The DokuWiki installation has the “Monobook” plugin/template/style/whatever installed which gives it a MediaWiki-like appearance and style. For more info on Monobook, see here.

The files in the live site are backed by a Git repository. As part of the DokuWiki directory tree, the .git directory is subject to the file ownership scheme described above.

The repository has three branches: master, dw-releases, and plugin-releases. The master branch contains the source for the live site and is the one that should be left checked out. dw-releases tracks pristine unpacks of DokuWiki release tarballs. plugin-releases is built on top of dw-releases and adds pristine unpacks of various DokuWiki plugins. master builds on top of plugin-releases, adding site-specific customizations. As described below, this setup allows us to safely update the different components of the software without worrying about losing local modifications. It does require some comfort with Git, though.

To make a change in the site-specific customizations, you should just modify the files in master and make a commit.

To upgrade a plugin, or install a new one, you should check out plugin-releases, unpack the new plugin, and commit it. (If the plugin is being upgraded, check if any existing files were deleted in the new version.) Look at the commit history of plugin-releases to see how this works. Then checkout master and merge plugin-releases. If there are any site-specific customizations to be made, make them in the post-merge master branch. If there are any merge conflicts, one of the site-specific hacks apparently needs to by synced with the new plugin.

To upgrade the base DokuWiki install, check out dw-releases and unpack the new release. Check data/deleted.files for a list of files that were deleted in the release, and git rm them. Commit everything. Check out plugin-releases, and merge in dw-releases. Check out master, and merge in plugin-releases. If there are any conflicts, one of the site-specific hacks needs fixing.

git log plugin-releases shows the plugins that we've installed. git log plugin-releases..master shows the site-specific modifications that have been made.

None at this time. Feel free to add ones.

The “Upload file” link seems to be broken. The workaround is to use the “add images or other files” button (looks like a picture in a frame) above the text box when modifying a page. — Jason Wright 2007/10/11 14:57

I think this has been fixed with the upgrade of DokuWiki and MonoBook. — Peter Williams 2008/08/19 16:28

A new bug seems to have cropped up. Any pages with a percent sign in them seem to be uneditable. This is especially bad for the financial advice pages, which have a lot of percentages in them. As a workaround, I'm using the alternative percent sign ٪, which seems to work, but it's not as pretty as the original sign. Any ideas? — Jason Wright 2007/10/11 15:17

This seems to be due to mod_security, which must have gotten added to the webserver at some point. I've added lines in the .htaccess to attempt to disable the rule which is causing this, but they haven't taken effect – there could be several reasons for that. At least the problem is tracked down now. If you look at /usr/local/apache2/logs/error_log on serpens and try to upload a page with a percent sign, you can see which rule is being triggered. It's defined in /usr/local/apache2/modsecurity_rules/modsecurity_crs_20_protocol_violations.conf. — Peter Williams 2008/08/19 16:24

We commented out the offending rule in the mod_security setup as a workaround. Percent signs are now ok: % . — Peter Williams 2008/08/21 11:51

These are basically lists of things that should be kept up-to-date.

• Past Theses
• Record of Assignments
• Student Directory
• Student Jobs
• Alumni
• Academic Genealogy
• Student Jobs is the job of the student-faculty rep
• Movie Night is the job of the Movie Night person

(This is a bit old; it was moved here from the start page discussion — Peter Williams 2008/08/21 11:14)

Jason wrote: Also, it would be nice if someone who will be here longer than Marshall (like me, I suppose) would learn how to find and edit the wiki generation scripts and configuration files so that we can actually fix the upload bug.

OK, a few comments to get you started:

The wiki is a pretty much stock install of DokuWiki, which I just untarred and it ran automatically with no real work on my part, except for a few minor hacks I made to the login process to only allow new user signup from within Campbell. I'll write up something about that in a bit, but really it was only about five lines of code to check the IP address. Oh, and I installed the “look like wikipedia” display template.

I don't have any special insight into the source code that would let me diagnose the current problem with file uploads. The files are installed in /celt/htdocs on the astro network, if anyone wants to examine the code.

In my opinion, managing the wiki ought to be the job of the grad student webmaster. The old job of the webmaster - run the actual department web site - shouldn't really have even been a grad student job, and thankfully it seems that the department has gotten the message and is now having professionals run the real web site. Since the old badgrads pages vanished along with the old web site, managing the wiki is about the only reasonable thing for the 'grad student web master' job to be about now.

Who should own the actual files and where the server itself goes are another problem. Hopefully serpens will just be handed on to some other student next year, and whenever it actually gets retired (which shouldn't be too soon; it's a 1.5 year old 3 GHz Pentium) they'll need to be propagated to some other machine (by Kelley and/or Bill).

— Marshall Perrin 2007/02/26 10:43