Customer Site


The customer site,, provides customer-specific data and configuration hosting. The site is maintained by Partner.

Currently, the primary purpose of this site is to provide updates to Partner on iOS. This role will certainly enlarge in the future.


The customer website is based on a Debian Linux virtual machine, and is accessible from the public Internet to authorized parties.

Customers are given a unique “Customer ID”. This ID serves several purposes: * the root directory for that customer’s web content, * the Linux user account for that customer’s data storage, * the Linux user group that other users authorized to access that customer’s data are in, * a standard identifier used by update, installation, and synchronization software.

Base URLs for customer data are constructed from the ID as:

Customer IDs can be any legal URL string, but should general be simple, lowercase, have no spaces or funny characters, etc. The recommended format is to use their domain name if they have one, or NAME-STATECODE if they do not.

For example a hypothetical co-op named East West Texas Electric with a website at should get a customer ID of “” and a website at If they didn’t have a website or domain name, as an alternative we could assign a customer ID of “eastwest-tx” and a base URL of .

Kerberos v5 is used for secure authentication, both for Linux login permissions and web access. HTTPS is used to ensure security when accessing data.

Current Version

Version 1 of the customer site, designed to work with version 1 of Partner on iOS, has the following features:

Future Versions

Future versions have no specific timetable yet, but we plan on including features such as:

  • version-controlled configuration via git,
  • per-user logins, e.g.,
  • preferences and permissions controlled via LDAP,
  • customer control of passwords and permissions,
  • user-specific and customer-specific web portals,
  • haversack integration, and
  • sandboxes.

Red-Flag Policy

While we have made every attempt to provide a secure server, there is always the chance of a break-in or security breach.

Partner’s Red Flag Policy specifies how we deal with customer data that may be sensitive. It defines two levels, “Highly Sensitive” and “Sensitive”. Highly sensitive data should never be stored on the hosted server. Sensitive data may be.

If Partner employees see that highly sensitive data has been uploaded to that server, or that sensitive data is exposed to those without credentials, they must comply by the policy as usual.

The customer must also inform Partner if a breach has occurred, if passwords need to be changed, or any other action applicable to the Red Flag Policy needs to be taken.

In any case where instructions or procedures related to conflict with the Red Flag Policy, the Red Flag Policy takes precedence.

File Locations

For version 1.0, only HTTPS access is available to customer-specific base URLs.

Files are stored in /var/www/CUSTOMER_ID/.

So, for example, the HTTPS-accessible files for would be stored in:


Currently only iOS file updates are implemented. These are stored in a single ZIP file, e.g.:


This is then visible over https at:

We are not using FTP for security reasons, so please use SCP or other secure method to update files.


Authentication is done via kerberos logins, both for the web site and for user logins.

Every customer has an account corresponding to their customer ID. E.g. This is for the organization, not for a person.

Every Partner employee has an account corresponding to their email address, with the @ replaced with a hyphen, e.g.

When implemented, per-user accounts will follow the same format - email address with @ replaced by a hyphen.


Customer-specific files are stored in /var/www/CUSTOMER_ID

Files are given read-write permission for group, the group matching the customerId.

Partner employees allowed to modify customer data are added to that customer organization’s group.

Per-user upload accounts allowed to modify customer data are added to their customer organization’s group.

iOS Updates

Partner on iOS has an update facility to pull data from

It requires the following information from the user:

  • customer ID
  • user ID (optional)
  • password (optional)

If the user ID or password are left blank, they are assumed to be the same as the customer ID.

macleod command

The macleod command is a terminal program that serves as a wrapper command for a variety of administrative activities on the customer server.

In MacleodPlatform/installation/ -


Currently you can:

  • macleod create customer CUSTOMERID PASSWORD - creates customer account, group, and download id
  • macleod create uploader USERNAME PASSWORD CUSTOMERID - creates user account for uploading maps and adds to customer id group
  • macleod create user USERNAME PASSWORD - creates both principal and user account
  • macleod create principal USERNAME PASSWORD - just principal
  • macleod create account USERNAME PASSWORD - just account
  • macleod update install - updates the install in /opt/partner using svn
  • macleod update htaccess - updates ~/www files for each user and ~/www/.htaccess files
  • macleod watch logs - follow the system logs to help debug issues with authorization etc.

On the server itself, this is installed in /opt/partner (just using svn co) and I’ve made a symlink to the macleod file from /usr/local/bin/macleod

It uses sudo internally just when required, so you don’t need to

sudo macleod



Permissions, accounts, and groups


There are these kerberos accounts:

  • - shared password for downloading for now, deprecated later

There are these unix accounts: * - ssh enabled * - ssh enabled

www-data owns all files under /var/www/

All files under /var/www/ are assigned to the group.

permissions are u+rx g:rwx o: (570)

A setuid tool, macleod-post, takes care of moving the uploaded files to the right place and fixing ownership and permissions. group contains: