When ikiwiki-hosting is used as a business, information about customers needs to be stored. Rather than use a database, we use the customersite, accessed by the IkiWiki::Customer module.

This is a regular site managed by ikiwiki-hosting like any other. Its configuration is somewhat special though. When setting it up:

• Be sure to configure ikiwiki to exclude: customer/*, and turn off branchability, to avoid customer data leaking out! Also, disable recentchanges, that can leak data too.
• Configure it to accept a ssh key owned by the controlsite, so that site can push into it.
• Configure its git_wrapper_background_command to update the controlsite's checkout of the customersite, by having it run ". /etc/ikiwiki-hosting/ikiwiki-hosting.conf; ikisite-wrapper updatecustomersite $controlsite"

Inside the customersite, there is a customer directory, which holds information about all the customers. Each customer has a subdirectory there, which holds files for each piece of data tracked about a customer.

The name of a customer's subdirectory is obtained by taking the sha1sum of their username. If a customer has multiple openids or emails used for login, they can have multiple subdirectories, symlinked together. (ikiwiki will not render the symlinks, but that's ok; it's not rendering customer data at all if configured right.)

The individual files hold one single piece of data, or a unordered list (ie, a list of email addresses). Files holding a list have "_list" in their filename.

This design is intended to allow changes to be made to multiple branches of the customersite, and merged together with little chance of conflicts. Git's union merge driver can be used to merge the list files. Other fields may have custom merge drivers.

locking

A file named lock in each customer's directory is used as a lock file by anything that reads or writes a customer's data.

A file named lock in the top of the customersite is used as a lock file for anything that needs to change arbitrary files anywhere in the customersite. (For example, a git pull.) This lock should be taken first, as a shared lock by things that do customer-level locking.

fields

• notes.mdwn freeform notes about customer
• currentplan holds the name of the price plan the user has agreed to
• email holds the current contact email of the user
• email_list holds all known emails of the user
• name holds the user's name (preferably full name, but may be whatever is available from openid, or possibly derived from email address).
• openid_list holds the openid(s) of the user
• startdate when this customer's account was first created (represented as time from unix epoch)
• balance amount of money owed (in cents) (a negative balance indicates the customer has a credit)
• previousbalance what the balance was before the last billing or payment event (be sure to update this when changing the balance)
• lastbilldate when user was last billed (represented as time from unix epoch)
• disable_billing if set to a true value, bills will not be sent (used for test accounts)
• lastreminderdate when last billing reminder was sent
• bill_startdate start of billing period for last bill
• bill_enddate end of billing period for last bill
• lastinvoiceid id of the last invoice sent
• lastplan name of the price plan used in the last invoice sent

non-customer data

In a charming example of scope creep, we're storing a bit of non-customer-specific data in the customersite already:

• invoice/last - stores the last used invoice id.
• invoice/YYY-MM/ - stores copies of invoices sent to customers