- 1 Mailing lists
- 2 Cron
- 3 The Mysterious Front Page
- 4 Planet
- 5 Domains
- 6 Calendar publishing
- 7 Email
- 8 Databases
- 9 Chapter hosting
- 9.1 Step 1: Creating the chapter's web space
- 9.2 Step 2: Enable the chapter's web space in Apache
- 9.3 Adding a wiki
- 9.4 Lyceum (WordPress farm)
- 9.5 Moving an existing wiki to the farm
- 10 Subversion
- 11 Backups
- 12 Wiki
We use Mailman to manage our lists. Here are some links you might like:
We use cron to run tasks every once in a while. To see the current list of jobs that run, do:
To edit them:
To see what the file format is, read this reference.
The Mysterious Front Page
How does the actual FreeCulture.org homepage get produced? What does everyone see when they visit http://freeculture.org ?
Since we have moved the site into Wordpress, most of our code can be found in the Wordpress theme "fco-wordpress-theme" in "~/domains/freeculture.org/wp-content/themes/". The skeleton for the front page is found in "front_page.php", which gets the content from functions found in "fco-wordpress-theme/front_page/". For instance, the "blurb" at the top of the front page (currently "Students for Free Culture is an international chapter-based student organization that promotes the public interest in intellectual property and information & communications technology policy.") can be found in "fco-wordpress-theme/front_page/front_page_code.php".
The content for the "Current Campaign" box does not come from the theme, it is what you see if you try to open the front page in the Wordpress page editor... it is intended to be easily edited and updated through the GUI just like any other blog page.
The planet program lives in ~/planet-prog/. It outputs to ~/public_html/planet/ via an every-30m cron job.
There are two planets. They share the same Python code; they just have different config.ini directories:
Add people's RSS feeds to those config files according to the comments you'll find inside. For the people Planet, add people's mini-photos in ~/domains/planet.freeculture.org/images/ and adjust the config.ini as appropriate. For the chapters Planet, I have no idea.
You might consider backing up all of the files to the .backup directory before making changes.
You could try upgrading it using "bzr". I wouldn't try it without backing up ~/planet-prog/. I expect it to clobber ~/planet-prog/examples/fancy/config.ini.
LiveJournal, for example, has broken RSS feeds that sometimes give the wrong Last-Modified-Date. So you might need to ask Planet to redownload the whole feed.
According to ~/planet-prog/examples/fancy/config.ini , Planet stores its cache in ~/planet-prog/cache/ . So to delete the whole cache:
In that directory, you can choose to remove just a single cached feed. The names make it clear which one is which.
Every domain we own or run is listed at Domains.
We use phpicalendar. If everyone working on the national level shares their calendars with each other, it becomes much easier to schedule meetings at mutually convenient times (instead of playing calendar battleship... "are you free at 3pm?" "No." "How about 4pm?" "You sunk my battleship! You bastard!").
As a user
- Set your calendar client to synchronize to http://freeculture.org:8080/calendars/YOURNAMEHERE.ics
- You will need to use a username/password pair special to the calendar stuff assigned to you by the web team
- Be SURE you use a file with your name in it. Otherwise you run the risk of others overwriting your data, and vice-versa!
- Check on http://freeculture.org/cal/ that your calendar appears
As a sysadmin
- Apache2 runs the WebDAV service; its configuration is in /etc/apache2/
- htpasswd file in ~freecult/passwords/calendar-htpasswd
- calendar files stored in ~freecult/public_html/database/calendars/
- to change someone's password, or create a user, do:
htpasswd /home/freecult/passwords/calendar-htpasswd USERNAME
We have a secret gmail account, freeculture.org at gmail dot com, that receives copies of the email sent to freedom, newgroup, and media. This was built to solve .
Because each of those email addresses is a separate account, they have a .procmailrc in their $HOME that reads:
:0c ! firstname.lastname@example.org
The "c" stands for copy. That's key - they stay in the IMAP box.
Creating a new list
- Go to http://lists.freeculture.org/
- Click for "the list admin overview page"
- Click to "create a new mailing list"
- Like, create one.
- Visit https://secure.makesad.us/~admin/intranet/mysql_tools/make_db.html from the fc.o server, and enter some username freecult_something and click "Submit"! (the username / db name should be 16 characters or less in length)
- When you create a new database, be sure to BACK IT UP (see section backups)
- You can use PHPMyAdmin to view our databases.
- You must log in using the username and password the web app itself uses, which you must fish out of the configuration for said app.
note: in the instructions below, '~' will only be the correct path if you're logged in as freecult
Step 1: Creating the chapter's web space
- mkdir -p ~/chapter-hosting/$subdomain/files
Step 2: Enable the chapter's web space in Apache
- Become root, then
- cd /etc/apache2/conf.d/
- export subdomain=SUBDOMAIN_YOU_ARE_CREATING
- svn cp 200-umich.conf 200-$subdomain.conf
- sed -i s/umich/$subdomain/g 200-$subdomain.conf
- svn commit 200-$subdomain.conf -m "Created web space for $subdomain"
- /etc/init.d/apache2 reload
- Go to http://$subdomain.freeculture.org/. It will say "Curious. There seems to be an error" until you set up Lyceum for this subdomain, or configure a redirect in the Semantic MediaWiki entry for this chapter.
Adding a wiki
Wiki step 1: Put the files in the right place
Go to the right directory:
- cd ~/chapter-hosting/$college
Now copy our MediaWiki setup in:
- git clone ~/chapter-hosting/wiki-skeleton/mediawiki/ wiki
Wiki step 2: Put content in the database
Now create the database you will use:
- python /home/freecult/software/fco-svn/mediawiki-cloning/clone.py /home/freecult/chapter-hosting/wiki-skeleton/mediawiki/LocalSettings.php
Take note of the username and password it prints. Now, open up LocalSettings.php with an editor:
- cd ~/chapter-hosting/$college/wiki/
- nano -w LocalSettings.php
- Update LocalSettings.php to have the right DB config info
- Update LocalSettings.php to have the right Wiki name
Now, run the UPGRADE_ALL_WIKIS.sh script. (This makes sure that the new wiki, as well as all the old wikis, have all the maintenance scripts run that they need.)
- cd ~/chapter-hosting
Ta-da! http://$college.freeculture.org/wiki/ should work now.
Wiki step 3: Customization for the chapter
- When you go to edit the Main_Page, you will see links to these templates: Chapter_name, Chapter_subdomain, School_name, School_url. Fill those in properly
- use this url syntax: '.../wiki/template:$template_name'
- Create a username for the chapter's lead member and promote him to Bureaucrats.
- Whew, that's all!
Lyceum (WordPress farm)
- Log in as admin at freeculture.org/lyceum
- go to the new user registration page
- enter the desired username for the administrative account on the new blog
- enter the new blog's subdomain (under "blog address")
- from the terminal, ssh to freeculture.org
- Become root
- cd /etc/apache2/conf.d/
- Look at 200-$college.conf - make sure the "DocumentRoot /home/freecult/subdomains/" line is commented-out, and make sure "DocumentRoot /home/freecult/chapter-hosting/lyceum_test/src/lyceum/" is enabled.
- run /etc/init.d/apache2 reload
now the blog is live. have a representative from the chapter create an account on lyceum, and give them admin powers for their new blog.
Moving an existing wiki to the farm
- First get a SQL dump
- As per this warning, use --default-character-set=latin1 for really old wikis.
- Then create a new DB
- Then use the mysql CLI to import the dump
- Then delete the SQL dump!
- move AdminSettings.sample into AdminSettings.php
- Edit LocalSettings.php to be similar to the old one, but with the current DB
- NOTE: If you did --default-character-set=latin1 for the mysqldump, you will want to set $wgDBmysql5=false in LocalSettings.php.
- Comment-out the define("MW_INSTALL_PATH") at the top
- Set IP to ~/chapter-hosting/$chapter/wiki/
- cp -a ~/software/mediawiki/maintenance .
- php maintenance/update.php maintenance/refreshLinks.php
Good! If it said it worked, then:
- rm -rf maintenance
- mv AdminSettings.php AdminSettings.example
- edit LocalSettings.php and re-enable the define("MW_INSTALL_PATH")
- Copy their old logo into ~/chapter-hosting/$chapter/files/fcWikiLogo.png
- Remove the "#" before the $wgLogo setting in LocalSettings.php
- Do the usual Apache preparation as per chapter hosting in general.
- svn checkout http://freeculture.org:8080/svn/
- Just do "svn commit"!
- But you must be a registered user first, see below!
- Log in to the freeculture.org server, and do:
htpasswd /home/freecult/subversion-repository/conf/htpasswd YOUR_USERNAME
- Your password will not be encrypted when sent across the Internet, so keep that in mind when picking the password.
Asheesh set up 'dirvish' and configured his work desktop to pull the backups from the fco vserver.
Every night, a cron job runs that saves all the databases to separate files in /home/freecult/backups/databases/. These are then copied as regular files during the nightly dirvish backup job.
To get a database in on this super fun backup party (everyone's doing it), add it to /home/freecult/passwords/mysql_passwords
we have a whole page on the Chapters database
Data privacy on this wiki
We ask users to store personal information in this wiki. Here are all the ways we restrict access to it:
- TODO: Non-includable namespaces: NS_USER should be blocked from being transcluded.
- DONE: Semantic MediaWiki currently does not store properties whose names begin with secret_.
- FIXME: It should store the data and just not show it unless you're an admin.
- TODO: Choose some MW extension to prevent people from reading source of NS_USER pages.
- In practice, the "read" right allows viewing the source. Therefore, we will have to:
- Prevent non-owners of an NS_USER page from changing that user's page, and
- Around line 1077, change the $source to a message indicating data has been hidden from view for privacy reasons, and
- Prevent the DifferenceEngine from showing these pages.
- Main call is Article.php:661, but just grep for new.*DifferenceEngine
- In practice, the "read" right allows viewing the source. Therefore, we will have to:
Review of UserCan extensions
Which MW extension can easily prevent people from writing each others' NS_USER pages?
- NOT Read Restrict - this isn't tested against the possible security holes.
- NOT UserPageEditProtection - no discussion of view source.
- NOT WhiteList - whitelisting isn't what we want.
- NOT Prefix security - requires manual group maintenance.
- NOT PermissionACL - requires manual group maintenance.
- NOT PasswordProtected- wrong model
Hmm. From #mediawiki moments ago:
<paulproteus> I want pages that people can read but can't view the source of, to be clear. <Simetrical> paulproteus, it controls all view permissions, including view source. <paulproteus> I see. <Simetrical> You can't have that.
Upgrading Semantic MediaWiki
If you feel motivated to upgrade Semantic MediaWiki or Semantic Forms, you should be sure to update the SMW data set. Here's how:
$ cd domains/wiki.freeculture.org/maintenance/ $ php SMW_refreshData.php -pv $ php SMW_refreshData.php -v