create new tag
, view all tags
I wonder if other people need this or think that it's already covered?

Lately I've been wishing there was a collection of HowTo articles for the common moderate to advanced system administrator requests that are discussed in Codev. Let me explain why.

Subject areas I've read up on recently include those to do with time and time zones, using mod perl, planning and organising a system to ease the next upgrade, how far you can go with TWiki for a standard project management tool, cgiwrap, and installing TWiki on hosted systems in case I want to set this up nicely for users on my systems.

I'm generally looking for a take-away answer of sorts, though I do expect to get information and have to weigh it up for myself. I also hope to be able to offer something in return sometimes, even if it's just a "thanks much, it works on my PDP-11 too!"

In this quest, I have encountered the following problems:

  • Most of the good gear is in Codev. Sometimes that's because it's unfunished or untested, but most times it is finished to the point of being usable even if there's room for improvement or a lack of portability. We're not told to look at Codev for this sort of stuff so it's there for the lucky few who find it.
  • Information on one subject is split among several topics. That's the least of my worries because they're well linked. I sometimes wonder, though, whether I've missed a slightly different topic that is closer to my unusual needs.
  • The big problem is recognising when a solution has been found, or whether I have picked up all the warnings for implementation of an imperfect solution. That's because of the way wiki discussions tend to wander around, especially when everone is excited, and there are too many potentially relevant red herrings for a reader at the edge of their depth to be able to pull the essence out of a topic. For example, I've hovered over a topic for weeks, waiting for someone to come back and say whether or not the umpteenth suggestion worked or killed the user, then seen someone ask a similar question on Support and be told it works well, see that topic in Codev.

The discussions are handled well and do what they set out to do. The only problem is that while they don't set out to speak to the proficient system administrator implementing TWiki and prepared to consider a little reconfiguration approaching hackery, nothing else speaks to us on these topics either. The topics tend to appear either for and by coders, or write-only topics from an admin perspective. Sometimes we want a half page lecture.

One example is the server time discussions. Last year several people found and shared "solutions", only to be surprised that they didn't work, which they then reported back. There was so much enthusiasm and sharing that it got a bit hard to follow. That wasn't helped by related but different desires and their proposed solutions being interleaved, in the hope that an imminent solution for one would apply to others, generally a good idea. So, when finally someone came up with a solution that "worked", like all the other almost right solutions had also "worked", it passed without fanfare. People didn't rush in to confirm or otherwise. Some time later, we saw yet another shocked new TWiki admin bemoaning that it hadn't been worked out yet. I think we lost him, too. Some time yet later, I was kindly sent a personal email assuring me that one of the patches did seem to work right and I might want to try it, but it was a few more months before I could rekindle the optimism to try TWiki again. Until I did so and made a big noise about the patch (almost a year later), I don't think anyone realised how close to a solution we actually were. What a shame!

Mod perl is a curly one. Let's just consider unix for now. Summary: Lots of people are using it, it gives huge performance improvement but some scripts benefit more than others, there can be problems which have been mostly solved by applying it to some scripts and not others, it is not straightforward to install and set up, something needs to be done about taint checking, variables problems if you run more than one installation of TWiki on the server, you can test the performance difference, there's something strange about Red Hat, and maybe a few other points I forgot.

Maybe I got some of the modperl conclusions wrong. I wished I could have found a finished summary like the one above, maybe with a todo checklist, and either add my environment to the list of those that it was running on, or correct some of the statements that proved inacurate or limited. It would be one small topic to read to decide whether it does what is wanted and whether any risks are big enough to be worth investigating the links to the full brainstorm.

Now I could write that myself, I almost did above, but where would I put it? I fear if it's not in Codev the right sort of people won't see it and the wrong sort will, but if it is here then many suitably geekish new admins won't know about it, or it'll just become yet-another-overwhelming-mod-perl-topic instead of the final (but changeable) answer. In many cases the method is clear and somewhat tested, that's a bleeding edge how-to, and in others it's just a summary of the state of a hack that can be tried with partial success, adequate for some (e.g. modperl? I still can't tell). For example, while ModPerlUnix is a great resource, if you think that's what I want to read first then I haven't made myself at all clear.

I'd hate this to sound critical of how topics have been handled, because it's not meant that way at all. It has been fun and beneficial to read through the bouncing around of these ideas and different experiences. Good tested solutions go into the docs. I don't want to change any of that, I just want something else, a well known place to find, write, and contribute to evolving summaries without long discussions, that will be the means for those who need a technique or feature to decide whether to try it yet or not and see how to proceed if they do. And for a silent few, it would be a place to check before assuming that TWiki can't meet their needs.

I could make a start, but I don't know how to make it fit in and be used.

-- SueBlake - 06 Aug 2003

Thanks for the summary Sue. I think you pretty much captured the problem. I don't have a solution. As I see it one of the root causes is that we the twiki community as a rule don't have well established refactoring habits. This is a social and workflow issue not a technical one. There doesn't need to be another place to go look for information, just better structuring of the information that's already here.

There a couple of topics which I "own" (TransparentAuthentication and WindowsInstallModNTLM) and have been trying to keep up to date and distill out the real goods from the failed attempts. The problem is that this is hard, requiring work and mental gymnastics. So much easier to just to jump down to the end of the topic and slap down the latest thought fragments.

One project that might help is to build something that sits between Support and Codev and TWiki webs. As it happens there is a mostly-empty empty web already here. To top it off, it even has an appropriate name: the Know web.

I think a FAQ approach rather than How-To would have better viability. Howto's require an owner with long term commitment and good refactoring abilities. The WindowsInstallCookbook is a howto; just ask RichardDonkin how much work that was! : )

-- MattWilkie - 06 Aug 2003

Writing mostly as a lurker here, I agree with both the issue Sue raises and Matt's statement that it's a social issue, not a technical one. But part of the key is to not let topics have an owner. It needs to be community ownership. The question is how to build the community.

From internal wiki use, I found a few things that helped:

  • Write topics in DissertationMode and actively segregate off the discussion.
  • Discourage the use of signed postings and first person pronouns (I, me, my) - nobody feels comfortable changing somebody else's words
  • ContinuouslyRefactor
    • Don't respond directly to a new question/issue, instead update the page and delete the question.
    • Minimize new topic creation - Relocate any new topics that should (or even just could) be part of an existing topic.
  • Give lots of positive reinforcement to any WikiMasters who emerge

I think that part of the problem here is that the user base is so large that no one feels comfortable writing authoritatively. The use of first person acts as a sort of disclaimer. The ModPerlUnix page is a great example of that. I don't know if this is surmountable given the broad user base. But as a suggestion, Sue could write her proposed summary of ModPerlUnix and put it at the top of the ModPerlUnix page, and whack any comments/questions that she feels her summary addresses. And if you accidentally delete too much, don't worry about it. Someone can always comeback and re-raise the issue if it's important. The history exists for anyone who cares. Most won't.

Violating all of my suggestions

-- ScottGargash - 07 Aug 2003

I tried to create such a how-to repository in TWikiAdminCookBook. So please feel free to add useful links you found there.

-- PeterMasiar - 12 Aug 2003

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2003-08-12 - PeterMasiar
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.