Suffr: collaborative system administration using a wiki
Kirk Zurell wrote today to tell me about Suffr, a module that allows, in effect, collaborative system administration using a wiki. Here’s how he describes it:
Users can compose recipes of changes to system configuration, and then sign off on them; when enough users approve, the wiki (through this module) implements the changes. Wiki users could democratically accomplish potentially any sysadmin tasks, including administering their own web server or applications, mail/news server, VOIP PBX, or peripherals. They can (and may have to!) even restart or shutdown the machine by majority vote.
I’ve wanted to introduce more people to wiki but always hit my head on the “what happens when someone posts something objectionable” type of questions. I knew the stock answers wouldn’t be enough for some audiences. Suffr lets me give a better answer: groups can decide for themselves what needs to happen, and can implement it right down to the hardware.
It’s a pretty interesting idea, but I see some issues. For example, how would you prevent someone from using this to take down a website? I think it’s not really meant for a public wiki, and may be most useful in a secure environment with a known group of people. For example, I could imagine the system administrator in charge of maintaining a wiki using Suffr to determine which plugins to enable based on popularity. People could vote on the plugins they’d like to use, and those with the most demand would be enabled automatically as need arises.
What do you think? Would it be useful for your wiki?
Kirk Zurell says:
Jan 28th, 2008
Some clarification:
No individual someone could take down a well-bootstrapped, popular website using Suffr. No matter how many times the villain signed off on a “shutdown” or “rm -rf /” recipe, other users simply wouldn’t sign off if they wanted the system to stay up. Exploits aside, Suffr prevents unintended root actions by any one sysadmin, authorized or no.
There’s no reason why a polished product couldn’t serve public wikis. In fact, the more public, the better: Suffr relies on a largish number of named users, each with their own passwords. That’s a lot of shoulder surfing needed to breach security.
The vote up/down idea for modules is interesting, but you can do nearly as much with email to that same sysadmin. Suffr lets a majority of users run “./configure; make; sudo make install” without needing to ask anyone else.
Stewart Mader says:
Jan 30th, 2008
Kirk,
Does Suffr rely on a fixed number of users or a percent? I think you make a great point that it would be pretty hard to game the system, but what about someone who creates a lot of accounts automatically? I guess security measures like CAPTCHA would help deter that.
Cheers,
Stewart
Kirk Zurell says:
Jan 31st, 2008
No, it’s simple (signed/total) > n, where n is as parametric as the module writer wants (I hard coded it to start, will fix it later).
Re: automatic accounts, this is a certain potential threat (esp. with CAPTCHAs offloaded to unsuspecting humans). I’d look to personal certificates or some other mechanism to raise the bar. Think of certificates with signatures: if a multitude of (fake) users had certificates that were all signed by exactly the same (fake) people, the system would be wise in refusing to continue. Just an idea.
Stewart Mader says:
Jan 31st, 2008
Kirk,
I like that – certificates would be the hardest to compromise.
Overall, I like this – it’s a good, forward-thinking approach to wiki use!
Stewart