Re: Future of the wiki in 2007?
> It's completely up to Michael to decide for as long as he is running > the wiki. Which does not mean that i won't run another software if this is a.) acceptable for me security wise and b.) a majority asks for it. But there is currently no need to change the wiki software because we've (we as in "the wiki reorg team") added some extensions to dokuwiki, changed some behaviour and are for now satisfied with it. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
Re: Future of the wiki in 2007?
On Jan 30, 2007, at 19:15, Bill Jones wrote: I mean since they are both written in Perl and you may want to start change just a few small things in Twiki. It's completely up to Michael to decide for as long as he is running the wiki. If we ever want to change to something else than docuwiki I'm sure we can figure out to get the data converted. I agree, btw, with him on his assessment on the twiki code. I use it for an internal wiki system and even doing a few simple customizations were A LOT of work (and I barely got it to work). The internal APIs are entirely horrible and I can't imagine how painful it'd be to do a proper security audit. Anyway, as Michael said some time ago: Talking about twiki is off-topic here. :-) - ask -- http://develooper.com/ - http://askask.com/
Re: Future of the wiki in 2007?
On 1/4/07, James Turnbull <[EMAIL PROTECTED]> wrote: My preference is TWiki - stable, powerful, extensible and Perl rather than PHP. I realize I may likely be an unwelcome stranger and more likely my opinion means naught; however I must throw my 2 cents in (it's the way I am.) Feel free to delete. Let's see - In a nut shell, do you want to code for qpsmtpd or code both qpsmtpd and this Twiki? Both are written in Perl -- Dokuwiki isn't. However Dokuwiki has a proven and in my opinion a stable development track record. I have used it to teach and used it to host personal blogs. I love Perl but I would not want to have to track more software development projects than what interests me. Maybe some of you are the same? Maybe not. qpsmtpd by itself sounds fun and using Dokuwiki will not add additional strain to that fun -- Twiki + qpsmtpd sounds a lot like work. The development release of Dokuwiki allows for secondary 'admins' to access the system if you want to delegate authority. If you need server side/domain admin work - then there is nothing stopping you from writing those few tools in Perl. I am not saying you should not use Twiki - I am just wanting to know if Twiki is decided to be best only because it is written in Perl - or that the group truly would want to develop for Twiki as well as qpsmtpd -- I mean since they are both written in Perl and you may want to start change just a few small things in Twiki. -Sx- -- WC (Bill) Jones -- http://youve-reached-the.endoftheinternet.org/ http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x2A46CF06&fingerprint=on
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 17:02 -0500, David Kaufman wrote: > Hi Michael, > > Michael Holzt <[EMAIL PROTECTED]> wrote: > >> I guess I would vote for Twiki if we were changing. > > > > Sorry, twiki isn't going to be installed on _any_ machine controlled > > by me. twiki has a bad history of (overly stupid!) security incidents > > I was unhappy with my experiences with TWiki, too. I reviewed the "bad history" and it appears to have been one major incident and a project which was not prepared to handle it. They appear to have made some effort to fix the problem and I have no real concerns in hosting it. > > I'm hoping to migrate a number of wiki's at work to KWiki > http://www.kwiki.org/ but I haven't had time so far, so nothing to > report except what I've read which is that it's supposed to be (as > advertized) simpler, more extensible and more mod_perl friendly. Does not look more extensible in this comparison: http://www.wikimatrix.org/compare/KWikiKWiki+TWiki But I'll take a look at it. Twiki is pretty large and we may want something which is easier to customize than something with every bell and whistle already attached. I have not made any effort yet to compare all the perl wikis which are documented on wikimatrix. I did the python ones a month ago because there were only about 6 of them. For perl there are 16, iirc, so it's a lot more work. However, since qpsmtpd is perl, we really should favour that a bit. > > hth, > > -dave > -- --gh
Re: Future of the wiki in 2007?
On Fri, 2007-05-01 at 08:07 +1100, James Turnbull wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Guy Hulbert wrote: > > I don't think this is inconsistent with what I said. You have now > > confirmed your decision to not host the wiki if it must be twiki and if > > that is the case then I am willing to try to pick it up. I will keep > > your opinions in mind while I evaluate it. > > > > At the very least - notwithstanding what Wiki software is chosen - we do > need a test environment. Particularly to make any sweeping structure > changes. It's always easier to sin in dev/test than potentially mess up > the prod instance. :) If we can get a test environment up and running > with the existing content I'd be happy to mock up a proposed new > structure for comment. ok ... i'll let you know when there's something to play with > > Regards > > James Turnbull > > - -- > James Turnbull <[EMAIL PROTECTED]> > - --- > Author of Pro Nagios 2.0 > (http://www.amazon.com/gp/product/1590596099/) > > Hardening Linux > (http://www.amazon.com/gp/product/159059/) > - --- > PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFnWyp9hTGvAxC30ARAuVpAKCxocAZQmGrTS71suchqVTVHw2MJACeI9nc > 7RkiebLUNCJk+ziGUnRQ06Y= > =7GX7 > -END PGP SIGNATURE- -- --gh
Re: Future of the wiki in 2007?
Hi Michael, Michael Holzt <[EMAIL PROTECTED]> wrote: I guess I would vote for Twiki if we were changing. Sorry, twiki isn't going to be installed on _any_ machine controlled by me. twiki has a bad history of (overly stupid!) security incidents I was unhappy with my experiences with TWiki, too. I'm hoping to migrate a number of wiki's at work to KWiki http://www.kwiki.org/ but I haven't had time so far, so nothing to report except what I've read which is that it's supposed to be (as advertized) simpler, more extensible and more mod_perl friendly. hth, -dave
Re: Future of the wiki in 2007?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guy Hulbert wrote: > I don't think this is inconsistent with what I said. You have now > confirmed your decision to not host the wiki if it must be twiki and if > that is the case then I am willing to try to pick it up. I will keep > your opinions in mind while I evaluate it. > At the very least - notwithstanding what Wiki software is chosen - we do need a test environment. Particularly to make any sweeping structure changes. It's always easier to sin in dev/test than potentially mess up the prod instance. :) If we can get a test environment up and running with the existing content I'd be happy to mock up a proposed new structure for comment. Regards James Turnbull - -- James Turnbull <[EMAIL PROTECTED]> - --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/159059/) - --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnWyp9hTGvAxC30ARAuVpAKCxocAZQmGrTS71suchqVTVHw2MJACeI9nc 7RkiebLUNCJk+ziGUnRQ06Y= =7GX7 -END PGP SIGNATURE-
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 17:32 +0100, Michael Holzt wrote: > > Unless and until Michael decides that he no longer wants to host the > > wiki, I think he has the final word. > > No. While i "own" qpsmtpd.org and run the current wiki, my opinion is in > no way superiour than those of others. If the project (as represented by Ok. > us all) feels that a twiki would help it and someone is willing to host > one, i'm ready to pass the baton. If the project wants me to continue > hosting the wiki, thats fine as well, but twiki is a no-no for me. But > in the end the decision is up to you. I don't think this is inconsistent with what I said. You have now confirmed your decision to not host the wiki if it must be twiki and if that is the case then I am willing to try to pick it up. I will keep your opinions in mind while I evaluate it. I will also look at some of the other packages suggested. In my mind the least disruptive option, including all the suggestions, as I understand them, would be to make some minor patches to docuwiki, link it to a trac instance, which would include a svn repo for contributed plugins and some additional functionality along the lines of vBulleting-webboard. If the result is something you are comfortable hosting and it is good enough, then fine. I think it is incumbent on the list to actually use the wiki more before too much effort goes into improving it. It'll probably take me a week to look at everything that's been discussed (I do have other things i need to do) more like two weeks to set up something new. We can always use 'twiki.qpsmptd.org' to let people compare before making a final decision. > > > I may be in a position to host the wiki before the end of February and > > I'd like to experiment with mirroring the content from Michael's server > > if that's ok with him. > > No objections. The machine is on a plan with all traffic included. If you > need help by me, please let me know. I'll try wget but it tends to grab all sorts of crap I don't want ... http isn't really designed for recursive mirroring. If there is shell access, I can send you a public key for ssh. Wget works ok over anon ftp ... but 'mirror' is nicer. I can use rsync ... but not bittorrent (overkill anyway for this). > > > Debian has very strict security guidlines and I expect that the Etch > > package will address most technical[*] concerns. > > But debian does not do a code audit. Based on the occurances in the past > i believe that the code base might not be overly clean and probably not I've looked at the code and I have nothing to say on that ;-) > written with security in mind. So there might be other security holes > hidden. I'm more worried that the radical ultra-pure faction (the ones for whom GFDL is a problem) might take over the project ... > > There is a saying in german "Wer einmal lügt, dem glaubt man nicht" (about: > we don't trust people caught lying once). Its some kind of the same > story here. The fact that some class of bugs with should haven't been > there in the first time (as said, the risk of user input is nothing new) > has been found multiple times combined with the attitude shown against > us brought me to my decision. But i'm not you, so you are free to decide > otherwise. ... debian is good enough for me. I just watch the elections every March to see if the new project leader seems reasonable. I'm prepared to switch to CentOS, OpenBSD or Solaris if necessary (in that order). > > > Regards > Michael -- --gh
Re: Future of the wiki in 2007?
Guy Hulbert wrote: On Thu, 2007-04-01 at 08:22 -0700, Tom Smith wrote: You may want to try etch. I expect to type: apt-get install twiki Ubuntu 6.06 LTS is gcc4--versions before that were not. All of the extra Perl modules I needed on 6.06 were installable via apt--only one came from the universe repository. So only Twiki required a manual install. That's the point of using apt-get. It will find all the dependencies for you. You may want to try: apt-get -s install twiki The "-s" prevents the install from running, but tests it. You may find that twiki is already in universe ... Also, 'apt-cache search twiki' should find it (afaik, apt-cache was not available on woody so I don't always remember to use it). Just took a look at this--both Dapper and Edgy show a 'twiki' package, but both show the "version" as 20040902... That's quite outdated (assuming the version number is based on the date of release).
Re: Future of the wiki in 2007?
> Unless and until Michael decides that he no longer wants to host the > wiki, I think he has the final word. No. While i "own" qpsmtpd.org and run the current wiki, my opinion is in no way superiour than those of others. If the project (as represented by us all) feels that a twiki would help it and someone is willing to host one, i'm ready to pass the baton. If the project wants me to continue hosting the wiki, thats fine as well, but twiki is a no-no for me. But in the end the decision is up to you. > I may be in a position to host the wiki before the end of February and > I'd like to experiment with mirroring the content from Michael's server > if that's ok with him. No objections. The machine is on a plan with all traffic included. If you need help by me, please let me know. > Debian has very strict security guidlines and I expect that the Etch > package will address most technical[*] concerns. But debian does not do a code audit. Based on the occurances in the past i believe that the code base might not be overly clean and probably not written with security in mind. So there might be other security holes hidden. There is a saying in german "Wer einmal lügt, dem glaubt man nicht" (about: we don't trust people caught lying once). Its some kind of the same story here. The fact that some class of bugs with should haven't been there in the first time (as said, the risk of user input is nothing new) has been found multiple times combined with the attitude shown against us brought me to my decision. But i'm not you, so you are free to decide otherwise. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
Re: Future of the wiki in 2007?
> Unless and until Michael decides that he no longer wants to host the > wiki, I think he has the final word. No. While i "own" qpsmtpd.org and run the current wiki, my opinion is in no way superiour than those of others. If the project (as represented by us all) feels that a twiki would help it and someone is willing to host one, i'm ready to pass the baton. If the project wants me to continue hosting the wiki, thats fine as well, but twiki is a no-no for me. But in the end the decision is up to you. > I may be in a position to host the wiki before the end of February and > I'd like to experiment with mirroring the content from Michael's server > if that's ok with him. No objections. The machine is on a plan with all traffic included. If you need help by me, please let me know. > Debian has very strict security guidlines and I expect that the Etch > package will address most technical[*] concerns. But debian does not do a code audit. Based on the occurances in the past i believe that the code base might not be overly clean and probably not written with security in mind. So there might be other security holes hidden. There is a saying in german "Wer einmal lügt, dem glaubt man nicht" (about: we don't trust people caught lying once). Its some kind of the same story here. The fact that some class of bugs with should haven't been there in the first time (as said, the risk of user input is nothing new) has been found multiple times combined with the attitude shown against us brought me to my decision. But i'm not you, so you are free to decide otherwise. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 08:22 -0700, Tom Smith wrote: > > You may want to try etch. I expect to type: > > > > apt-get install twiki > > > > Ubuntu 6.06 LTS is gcc4--versions before that were not. > > All of the extra Perl modules I needed on 6.06 were installable via > apt--only one came from the universe repository. So only Twiki > required > a manual install. > > > That's the point of using apt-get. It will find all the dependencies for you. You may want to try: apt-get -s install twiki The "-s" prevents the install from running, but tests it. You may find that twiki is already in universe ... Also, 'apt-cache search twiki' should find it (afaik, apt-cache was not available on woody so I don't always remember to use it). -- --gh
RE: Future of the wiki in 2007?
On Thu, 2007-04-01 at 16:54 +0100, Arnaud ASSAD wrote: > If twiki appears to be the best choice for most of the people, maybe > we > should all consider it on a pragmatic way. Unless and until Michael decides that he no longer wants to host the wiki, I think he has the final word. I am going to look at twiki anyway. The install page does document some post-configuration steps which must be taken (one of the things which reminds me of PHP). I may be in a position to host the wiki before the end of February and I'd like to experiment with mirroring the content from Michael's server if that's ok with him. Debian has very strict security guidlines and I expect that the Etch package will address most technical[*] concerns. Debian also has its own security lists and policy so I would not be too worried about hosting twiki. -- --gh [*] The alleged personal behaviour of the Twiki project leader would be as important to me ... but I would not post them to a public forum without some references.
Re: Future of the wiki in 2007?
> I can't really comment on your situation because I wasn't there... But I > think that sometimes it's prudent to keep such security problems > "secret" until a solution is found. > Discussing them (and their solutions) on mailing lists and such is one > thing, but publicly announcing the problem to the world just opens up > every (in this case) Twiki installation to being hacked by would-be hackers. Fixing the bug was easy, and iirc we also provided a fix within the advisory. What should probably also be mentioned is that a few months later, a new error of the same kind (using unchecked user input for shell execution) was found in twiki. And iirc later such a hole was found once again. So this makes in total at least three occurences of a very stupid bug. It is known and preached for years not to trust user input. A responsible author should have checked his code for more occurences after the first hole was discovered in my opinion. Also the first bugs have been known by blackhats (and widely abused) for at least five weeks before, so stalling the advisory didn't helped in any way, because machines around the world where owned in the meanwhile. However the bugs of twiki are offtopic here. If a majority feels that twiki is the solution for qpsmtpd and someone is willing to operate a twiki installation despite my security concerns, please feel free to do so. I can provide you with the data from the dokuwiki (if needed) and i would then let wiki.qpsmtpd.org point to the new machine. But no installation of twiki is going to happen on any of my machines as a general decision. If someone else is willing to do this, i'm very fine with that. I will continue to sponsor the qpsmtpd.org domain, but i have no problem at all with someone else operating the wiki. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
RE: Future of the wiki in 2007?
On Thu, 2007-01-04 at 16:54 +0100, Arnaud ASSAD wrote: > If twiki appears to be the best choice for most of the people, maybe we > should all consider it on a pragmatic way. If it good enough for these guys... http://wiki.java.net (Just thought that was an interesting place to find a perl-based wiki). -- Les Mikesell [EMAIL PROTECTED]
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 09:53 -0600, Les Mikesell wrote: > On Thu, 2007-01-04 at 16:34 +0100, Michael Holzt wrote: > > Sorry, twiki isn't going to be installed on _any_ machine controlled by > > me. twiki has a bad history of (overly stupid!) security incidents and > > its main developer (Peter Thoeny) has reacted very unfriendly and also > > unprofessional to people reporting such issues. > [...] > > So, sorry, but i won't install software from a author who keeps blatant > > security holes secret by purpose. > > So, no Linux for you, eh? > http://www.securityfocus.com/columnists/35 That's a very old story and, imnho, reflects poorly on Alan Cox more than anything else. -- --gh
RE: Future of the wiki in 2007?
Please don't take it personally: I don't know Peter I don't know you (For sure I'd like to change this if you come to France) I still get a mixed feeling about Twiki (especially about its security) But if I recall correctly, Peter is usually not trying to hide security holes, but rather let some time to the user (via the ML) to apply some patch. So may be it's not as black as you believe (maybe just gray :-) ) If twiki appears to be the best choice for most of the people, maybe we should all consider it on a pragmatic way. Arnaud > -Message d'origine- > De : Michael Holzt [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 4 janvier 2007 16:35 > À : qpsmtpd@perl.org > Objet : Re: Future of the wiki in 2007? > > > I guess I would vote for Twiki if we were changing. > > Sorry, twiki isn't going to be installed on _any_ machine controlled by > me. twiki has a bad history of (overly stupid!) security incidents and > its main developer (Peter Thoeny) has reacted very unfriendly and also > unprofessional to people reporting such issues. > > I was involved in a case where lots of machines were owned because of a > very stupid hole in twiki (doing shell execs with unfiltered user input, > OUCH!). It turned out, that Peter already knew about this hole for DAYS, > but decided to sit on it for some more days while pondering what to do > now. He planned to write an advisory, but this was due to be published > ONLY on to a twiki-users mailinglist, but not to the general public... > > Some friend of mine discovered the hole by analyzing the logs of a owned > machine. An advisory was written (took under 30 minutes) and published > (after Peter was contacted and acknowledged this). Shortly after this, > a machine of a friend of Peter was owned and then suddenly Peter blamed > US because we made the knowledge about the hole public... > > So, sorry, but i won't install software from a author who keeps blatant > security holes secret by purpose. > > > Regards > Michael > > -- > It's an insane world, but i'm proud to be a part of it. -- Bill > Hicks This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 16:34 +0100, Michael Holzt wrote: > > I guess I would vote for Twiki if we were changing. > > Sorry, twiki isn't going to be installed on _any_ machine controlled > by > me. twiki has a bad history of (overly stupid!) security incidents > and > its main developer (Peter Thoeny) has reacted very unfriendly and also > unprofessional to people reporting such issues. Thanks for the info. Both the code and the documentation remind me of PHP but the marketing material looks good. They do mention that its widely used behind firewalls (on their main page, iirc), which I also took as a caveat. What about MoinMoin? That's another one I've been planning to look at. Zwicky looks alright but requires zope. If you want to stick with docuwiki, I would look at upgrading to the latest ... if you go that way I will look at it to see if I can hack in the other feature that I wanted; namely, renaming pages - this will make the index feature much more useful - it could be used as a site map if you use the namespaces and choose categories well. Renaming would allow reorganization without shell access to the server. -- --gh
Re: Future of the wiki in 2007?
On Thu, 2007-01-04 at 16:34 +0100, Michael Holzt wrote: > Sorry, twiki isn't going to be installed on _any_ machine controlled by > me. twiki has a bad history of (overly stupid!) security incidents and > its main developer (Peter Thoeny) has reacted very unfriendly and also > unprofessional to people reporting such issues. [...] > So, sorry, but i won't install software from a author who keeps blatant > security holes secret by purpose. So, no Linux for you, eh? http://www.securityfocus.com/columnists/35 -- Les Mikesell [EMAIL PROTECTED]
Re: Future of the wiki in 2007?
Johan Almqvist writes: However even if there was a separate plugin repository and a vBulletin, I'd still want the wiki to direct all the forum (and list) RTFM's to... You just make those stick at the top of the (sub)forums... With the added benefit that you get a sort of web-of-trust as well as a hierarchy allowing new (and old, of course) users to get a better view of who's doing what job and how well they're doing it. Sure, a badly structured forum wouldn't work well, but with the right structure I think it'd work quite well; and if the wiki's still around then we could get the best of both worlds if people take the time to copy plugins and the fine manuals etc to the wiki (not that I think that anyone will actually do that). Using vBulletin it'd be quite easy to move threads around, add new moderators, new subforums for whatever people want to discuss and so on...
Re: Future of the wiki in 2007?
Michael Holzt wrote: I guess I would vote for Twiki if we were changing. Sorry, twiki isn't going to be installed on _any_ machine controlled by me. twiki has a bad history of (overly stupid!) security incidents and its main developer (Peter Thoeny) has reacted very unfriendly and also unprofessional to people reporting such issues. I was involved in a case where lots of machines were owned because of a very stupid hole in twiki (doing shell execs with unfiltered user input, OUCH!). It turned out, that Peter already knew about this hole for DAYS, but decided to sit on it for some more days while pondering what to do now. He planned to write an advisory, but this was due to be published ONLY on to a twiki-users mailinglist, but not to the general public... Some friend of mine discovered the hole by analyzing the logs of a owned machine. An advisory was written (took under 30 minutes) and published (after Peter was contacted and acknowledged this). Shortly after this, a machine of a friend of Peter was owned and then suddenly Peter blamed US because we made the knowledge about the hole public... So, sorry, but i won't install software from a author who keeps blatant security holes secret by purpose. I can't really comment on your situation because I wasn't there... But I think that sometimes it's prudent to keep such security problems "secret" until a solution is found. Discussing them (and their solutions) on mailing lists and such is one thing, but publicly announcing the problem to the world just opens up every (in this case) Twiki installation to being hacked by would-be hackers. As I said, I don't know the situation and won't take any sides here, I just wanted to interject that thought.
Re: Future of the wiki in 2007?
> I guess I would vote for Twiki if we were changing. Sorry, twiki isn't going to be installed on _any_ machine controlled by me. twiki has a bad history of (overly stupid!) security incidents and its main developer (Peter Thoeny) has reacted very unfriendly and also unprofessional to people reporting such issues. I was involved in a case where lots of machines were owned because of a very stupid hole in twiki (doing shell execs with unfiltered user input, OUCH!). It turned out, that Peter already knew about this hole for DAYS, but decided to sit on it for some more days while pondering what to do now. He planned to write an advisory, but this was due to be published ONLY on to a twiki-users mailinglist, but not to the general public... Some friend of mine discovered the hole by analyzing the logs of a owned machine. An advisory was written (took under 30 minutes) and published (after Peter was contacted and acknowledged this). Shortly after this, a machine of a friend of Peter was owned and then suddenly Peter blamed US because we made the knowledge about the hole public... So, sorry, but i won't install software from a author who keeps blatant security holes secret by purpose. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
Re: Future of the wiki in 2007?
Guy Hulbert wrote: On Thu, 2007-04-01 at 07:58 -0700, Tom Smith wrote: The largest installation woes... - Perl modules--most are part of standard Perl, but some had to be added CPAN is your friend ... but it's getting to be a bit of a monster. My strategy is to use it for a test install and then save all the source and install manually (or build packages) for production. BTW... I installed it on Ubuntu 6.06 LTS. You may want to try etch. I expect to type: apt-get install twiki Answer a few questions and then fire up a browser. Actually, you should have been able to do this on Ubuntu by adding to /etc/apt/sources.list ... but I'm not sure about binary compatibility. Etch has moved to gcc4 ... (but Ubuntu is usually ahead of Debian by a few months). Ubuntu 6.06 LTS is gcc4--versions before that were not. All of the extra Perl modules I needed on 6.06 were installable via apt--only one came from the universe repository. So only Twiki required a manual install.
Re: Future of the wiki in 2007?
On 4-jan-2007, at 15:57, Guy Hulbert wrote: On Thu, 2007-04-01 at 15:14 +0100, Leander Koornneef wrote: May be a few days before I report further ... This may save you a bit of work if it's just for testing: Yeah. Saw that. However ... http://twiki.org/cgi-bin/view/Codev/TWikiVMDebianStable Leander ... I don't use windows ... nothing political, and I've admin'd everything since DOS 5, but I got X-windows working on linux 0.99r15 and windows didn't get sufficiently usable for me until a couple of years after that ... so I never made the switch. Ah, I didn't actually read that page :-) Anyway, I also hardly ever use Windows and I can tell you that running Windows is not a requirement to use these virtual machines. Vmware (player|server) work just fine under Linux (and now also OSX, yay!) Leander
Re: Future of the wiki in 2007?
Robin Bowes wrote: Guy Hulbert wrote: There are better python wikis than trac. In particular moin-moin is quite close to the present docu-wiki. Moin-moin versus trac: http://www.wikimatrix.org/compare/MoinMoin+TracWiki Trac is missing a lot. I don't entirely disagree, but trac is more than just a wiki - it's: "...an enhanced wiki and issue tracking system for software development projects." It has subversion integration, a ticketing system, milestones, a roadmap, timeline (history), etc. I use it a lot for both personal projects, and support it professionally for my clients. Check out Twiki's home page (http://twiki.org/)--look for "Success Stories" and "How is Twiki being deployed?" It's been deployed for a number of different things including project management, knowledge base, bug tracking, etc. It may not do everything that Trac does /like/ Trac does, but I'm sure it can handle some of the tasks you mentioned with ease.
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 07:58 -0700, Tom Smith wrote: > The largest installation woes... > > - Perl modules--most are part of standard Perl, but some had to be > added CPAN is your friend ... but it's getting to be a bit of a monster. My strategy is to use it for a test install and then save all the source and install manually (or build packages) for production. > BTW... I installed it on Ubuntu 6.06 LTS. You may want to try etch. I expect to type: apt-get install twiki Answer a few questions and then fire up a browser. Actually, you should have been able to do this on Ubuntu by adding to /etc/apt/sources.list ... but I'm not sure about binary compatibility. Etch has moved to gcc4 ... (but Ubuntu is usually ahead of Debian by a few months). -- --gh
Re: Future of the wiki in 2007?
Arnaud ASSAD wrote: I'd also like to keep the wiki. To my mind, the tool is ok, We (In fact I should use 'I') only have to contribute more. There is, for example, a lot of knowledge on the ML which has not be put back on the wiki. One could also at how to create a mailing list archive within the wiki, if one doesn't already exist.
RE: Future of the wiki in 2007?
On Thu, 2007-04-01 at 15:43 +0100, Arnaud ASSAD wrote: > I'd also like to keep the wiki. > > To my mind, the tool is ok, We (In fact I should use 'I') only have to > contribute more. > > There is, for example, a lot of knowledge on the ML which has not be put > back on the wiki. Twiki should be able to do that ... I've seen a customized version of phpbb, set up to do it. > > > Arnaud -- --gh
Re: Future of the wiki in 2007?
Guy Hulbert wrote: On Thu, 2007-04-01 at 07:43 -0500, Guy Hulbert wrote: I guess I would vote for Twiki if we were changing. It seems that the latest twiki will be in etch and I have been planning to upgrade my server anyway. My thoughts have changed a bit since looking at the source. The install guide is unreadble without a browser so I went to their site: http://twiki.org/cgi-bin/view/TWiki/TWikiInstallationGuide It's not very pretty ... but the promised features seem to outweigh a bit of work ... I will set up a test etch box as Debian generally takes care of this stuff quite well. May be a few days before I report further ... Twiki is pretty easy to install--I just finished an installation a few days ago and have been working on understanding how to manage Twiki now. The largest installation woes... - Perl modules--most are part of standard Perl, but some had to be added to support some other needed features. This was actually pretty easy, just time consuming to verify whether or not the modules were installed. - File system permissions--this was a bit tricky, but I think I've got it figured out. Should be a fairly secure install now. The documentation doesn't provide a lot of advice here so I winged it a bit, just understanding that Twiki only needs write access to data and pub. There are still some things I'm working out, so that list isn't complete. But the base Twiki install is up and running perfectly. BTW... I installed it on Ubuntu 6.06 LTS.
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 15:14 +0100, Leander Koornneef wrote: > > May be a few days before I report further ... > > This may save you a bit of work if it's just for testing: Yeah. Saw that. However ... > > http://twiki.org/cgi-bin/view/Codev/TWikiVMDebianStable > > Leander ... I don't use windows ... nothing political, and I've admin'd everything since DOS 5, but I got X-windows working on linux 0.99r15 and windows didn't get sufficiently usable for me until a couple of years after that ... so I never made the switch. -- --gh
RE: Future of the wiki in 2007?
I'd also like to keep the wiki. To my mind, the tool is ok, We (In fact I should use 'I') only have to contribute more. There is, for example, a lot of knowledge on the ML which has not be put back on the wiki. Arnaud > -Message d'origine- > De : Michael Holzt [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 4 janvier 2007 12:05 > À : qpsmtpd@perl.org > Objet : Future of the wiki in 2007? > > As some of you might or might now know, i'm the holder of the qpsmtpd.org > domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the > wiki still seems to be a good idea, i've noticed that there have been next > to no contributions to it lately. This is a bit of a shame, as qpsmtpd > lacks good documentation and i hoped the wiki would solve that problem in > a collaborating way. > > I'm looking for suggestions how to continue with the wiki in 2007. What > i especially would like to know if the wiki installed (dokuwiki) is fine > or if you would like to see some other wiki software installed instead. > I used dokuwiki because i've had enough with the bloatness of mediawiki > (which i used for two other projects), but i've noticed that dokuwiki can > be confusing at times (especially this "browsing history" at the top of > the page which is easily confused with a real navigation). So if one has > better suggestions (i would also like to get rid of the security nightmare > also known as php), i would like to hear about it. > > > Regards > Michael > > -- > It's an insane world, but i'm proud to be a part of it. -- Bill > Hicks This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Future of the wiki in 2007?
James Turnbull wrote: Michael Holzt wrote: the page which is easily confused with a real navigation). So if one has better suggestions (i would also like to get rid of the security nightmare also known as php), i would like to hear about it. My preference is TWiki - stable, powerful, extensible and Perl rather than PHP I'll second Twiki--just started using it, but LOVE it!
Re: Future of the wiki in 2007?
On 4-jan-2007, at 14:54, Guy Hulbert wrote: On Thu, 2007-04-01 at 07:43 -0500, Guy Hulbert wrote: I guess I would vote for Twiki if we were changing. It seems that the latest twiki will be in etch and I have been planning to upgrade my server anyway. My thoughts have changed a bit since looking at the source. The install guide is unreadble without a browser so I went to their site: http://twiki.org/cgi-bin/view/TWiki/TWikiInstallationGuide It's not very pretty ... but the promised features seem to outweigh a bit of work ... I will set up a test etch box as Debian generally takes care of this stuff quite well. May be a few days before I report further ... This may save you a bit of work if it's just for testing: http://twiki.org/cgi-bin/view/Codev/TWikiVMDebianStable Leander
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 07:43 -0500, Guy Hulbert wrote: > > I guess I would vote for Twiki if we were changing. > > It seems that the latest twiki will be in etch and I have been > planning > to upgrade my server anyway. My thoughts have changed a bit since looking at the source. The install guide is unreadble without a browser so I went to their site: http://twiki.org/cgi-bin/view/TWiki/TWikiInstallationGuide It's not very pretty ... but the promised features seem to outweigh a bit of work ... I will set up a test etch box as Debian generally takes care of this stuff quite well. May be a few days before I report further ... -- --gh
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 23:58 +1100, James Turnbull wrote: > > I don't feel either of these will be a good replacement for the > current > > wiki. I agree that placing the plugin repository in the wiki wasn't > the > > best idea (I just couldn't think of a better way of doing it at the > time). > > Yes - the plug-ins in the wiki model is a little cumbersome - though > sometimes useful if I want to peek at some code. Perhaps a SVN repo I was wondering about linking Twiki and Trac. > and have people submit a simple application to get check-in rights > (much > like Twiki do with their plug-ins) is an idea? You can link each > plug-in in the Wiki to an SVN browser. Could we do this with a Twkik plug-in ? Trac would provide subversion integration, iirc. I'd much prefer twiki (or anything close to docuwiki) for the documentation. I discovered that Twiki has an awful lot of features (latex, xsl) that I would use (or at least play with :-) http://www.wikimatrix.org/show/TWiki [ I'm going to do this for personal use anyway but I'll contribute anything to qpsmtpd that anyone thinks would be useful. ] -- --gh
Re: Future of the wiki in 2007?
Johan Almqvist wrote: >> 1) a vBulleting-webboard, and >> 2) rsync so that all those that want to can have their set of plugins >> in use (check with the configfile, and only rsync the active ones) >> shared with the world. > > I don't feel either of these will be a good replacement for the current > wiki. I agree that placing the plugin repository in the wiki wasn't the > best idea (I just couldn't think of a better way of doing it at the time). Yes - the plug-ins in the wiki model is a little cumbersome - though sometimes useful if I want to peek at some code. Perhaps a SVN repo and have people submit a simple application to get check-in rights (much like Twiki do with their plug-ins) is an idea? You can link each plug-in in the Wiki to an SVN browser. > However even if there was a separate plugin repository and a vBulletin, > I'd still want the wiki to direct all the forum (and list) RTFM's to... Agreed. Regards James Turnbull -- James Turnbull <[EMAIL PROTECTED]> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/159059/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) signature.asc Description: OpenPGP digital signature
Re: Future of the wiki in 2007?
[ apologies for replying to my own post ... I delete most things after I read them but sent-mail is always there ] On Thu, 2007-04-01 at 06:58 -0500, Guy Hulbert wrote: > On Thu, 2007-04-01 at 11:26 +, Robin Bowes wrote: > > Michael Holzt wrote: > > > As some of you might or might now know, i'm the holder of the qpsmtpd.org > > > domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the > > > wiki still seems to be a good idea, i've noticed that there have been next > > > to no contributions to it lately. This is a bit of a shame, as qpsmtpd > > > lacks good documentation and i hoped the wiki would solve that problem in > > > a collaborating way. > > > > > > I'm looking for suggestions how to continue with the wiki in 2007. What Michael. Can you provide a dump of the existing content? I'd like to set up twiki anyway (see below) and I will try to set up a public copy with the content mirrored. It will take a little while as I am hosting a couple of sites so I need to upgrade my server carefully. However I can try things out on a test server right away. I may be able to provide slow access to that (depends what my provider filters). > > > i especially would like to know if the wiki installed (dokuwiki) is fine > > > or if you would like to see some other wiki software installed instead. > > > I used dokuwiki because i've had enough with the bloatness of mediawiki > > I was very impressed by dokuwiki. The developers have a link to a wiki > comparison site which I found quite useful to compare features. > Moin-moin versus docu-wiki versus twiki > http://www.wikimatrix.org/compare/MoinMoin+DokuWiki+TWiki > > I notice that Twiki has namespaces but Moin-moin does not ... otherwise > all three of these are comparable. > > I guess I would vote for Twiki if we were changing. It seems that the latest twiki will be in etch and I have been planning to upgrade my server anyway. > > > > > R. > > -- --gh
Re: Future of the wiki in 2007?
Hello everyone [EMAIL PROTECTED] wrote: Michael Holzt writes: As some of you might or might now know, i'm the holder of the qpsmtpd.org domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the wiki still seems to be a good idea, i've noticed that there have been next to no contributions to it lately. This is a bit of a shame, as qpsmtpd lacks good documentation and i hoped the wiki would solve that problem in a collaborating way. Personally I'd leave the wiki as it is (basically letting it die), while setting up 1) a vBulleting-webboard, and 2) rsync so that all those that want to can have their set of plugins in use (check with the configfile, and only rsync the active ones) shared with the world. I don't feel either of these will be a good replacement for the current wiki. I agree that placing the plugin repository in the wiki wasn't the best idea (I just couldn't think of a better way of doing it at the time). However even if there was a separate plugin repository and a vBulletin, I'd still want the wiki to direct all the forum (and list) RTFM's to... -Johan
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 12:12 +, Robin Bowes wrote: > Guy Hulbert wrote: > > > There are better python wikis than trac. In particular moin-moin is > > quite close to the present docu-wiki. > > > > Moin-moin versus trac: > > http://www.wikimatrix.org/compare/MoinMoin+TracWiki > > > > Trac is missing a lot. > > I don't entirely disagree, but trac is more than just a wiki - it's: > > "...an enhanced wiki and issue tracking system for software development > projects." > > It has subversion integration, a ticketing system, milestones, a > roadmap, timeline (history), etc. > > I use it a lot for both personal projects, and support it professionally > for my clients. I plan to do the same. However, docuwiki is the first wiki I have actually wanted to use. The combination of features seems to be about right. I also get the impression that this project might be less inclined to use the other features of trac than they are inclined to use the wiki. > > R. > -- --gh
Re: Future of the wiki in 2007?
Guy Hulbert wrote: > There are better python wikis than trac. In particular moin-moin is > quite close to the present docu-wiki. > > Moin-moin versus trac: > http://www.wikimatrix.org/compare/MoinMoin+TracWiki > > Trac is missing a lot. I don't entirely disagree, but trac is more than just a wiki - it's: "...an enhanced wiki and issue tracking system for software development projects." It has subversion integration, a ticketing system, milestones, a roadmap, timeline (history), etc. I use it a lot for both personal projects, and support it professionally for my clients. R.
Re: Future of the wiki in 2007?
On Thu, 2007-04-01 at 11:26 +, Robin Bowes wrote: > Michael Holzt wrote: > > As some of you might or might now know, i'm the holder of the qpsmtpd.org > > domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the > > wiki still seems to be a good idea, i've noticed that there have been next > > to no contributions to it lately. This is a bit of a shame, as qpsmtpd > > lacks good documentation and i hoped the wiki would solve that problem in > > a collaborating way. I created a couple of new pages and I plan to document everything I learn so I would like to see the wiki stay. > > > > I'm looking for suggestions how to continue with the wiki in 2007. What > > i especially would like to know if the wiki installed (dokuwiki) is fine I like the namespace feature and I would like to use it. However to be really useful it would be necessary to rename some of the existing pages and that does not appear to be possible. However, I noticed that docuwiki seems to have quite frequent releases so it might be possible to get the ability to rename pages added -- also to get a bug with the namespaces fixed. > > or if you would like to see some other wiki software installed instead. > > I used dokuwiki because i've had enough with the bloatness of mediawiki I was very impressed by dokuwiki. The developers have a link to a wiki comparison site which I found quite useful to compare features. > > (which i used for two other projects), but i've noticed that dokuwiki can > > be confusing at times (especially this "browsing history" at the top of > > the page which is easily confused with a real navigation). So if one has > > better suggestions (i would also like to get rid of the security nightmare > > also known as php), i would like to hear about it. > > How about moving the project to trac with it's wiki plus subversion > integration and ticketing system? There are better python wikis than trac. In particular moin-moin is quite close to the present docu-wiki. Moin-moin versus trac: http://www.wikimatrix.org/compare/MoinMoin+TracWiki Trac is missing a lot. Moin-moin versus docu-wiki versus twiki http://www.wikimatrix.org/compare/MoinMoin+DokuWiki+TWiki I notice that Twiki has namespaces but Moin-moin does not ... otherwise all three of these are comparable. I guess I would vote for Twiki if we were changing. > > R. > -- --gh
Re: Future of the wiki in 2007?
Michael Holzt writes: As some of you might or might now know, i'm the holder of the qpsmtpd.org domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the wiki still seems to be a good idea, i've noticed that there have been next to no contributions to it lately. This is a bit of a shame, as qpsmtpd lacks good documentation and i hoped the wiki would solve that problem in a collaborating way. Personally I'd leave the wiki as it is (basically letting it die), while setting up 1) a vBulleting-webboard, and 2) rsync so that all those that want to can have their set of plugins in use (check with the configfile, and only rsync the active ones) shared with the world. /Tony
Re: Future of the wiki in 2007?
Michael Holzt wrote: > As some of you might or might now know, i'm the holder of the qpsmtpd.org > domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the > wiki still seems to be a good idea, i've noticed that there have been next > to no contributions to it lately. This is a bit of a shame, as qpsmtpd > lacks good documentation and i hoped the wiki would solve that problem in > a collaborating way. > > I'm looking for suggestions how to continue with the wiki in 2007. What > i especially would like to know if the wiki installed (dokuwiki) is fine > or if you would like to see some other wiki software installed instead. > I used dokuwiki because i've had enough with the bloatness of mediawiki > (which i used for two other projects), but i've noticed that dokuwiki can > be confusing at times (especially this "browsing history" at the top of > the page which is easily confused with a real navigation). So if one has > better suggestions (i would also like to get rid of the security nightmare > also known as php), i would like to hear about it. How about moving the project to trac with it's wiki plus subversion integration and ticketing system? R.
Re: Future of the wiki in 2007?
Michael Holzt wrote: > As some of you might or might now know, i'm the holder of the qpsmtpd.org > domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the > wiki still seems to be a good idea, i've noticed that there have been next > to no contributions to it lately. This is a bit of a shame, as qpsmtpd > lacks good documentation and i hoped the wiki would solve that problem in > a collaborating way. I hope to add to the Wiki this year (I've done a little editing on a page or two). I think it's worth keeping. IMHO It needs a bit of re-organisation - which I volunteer to do some of - and I believe someone else also volunteered to do some edits. I think if we can find a better structure for the content it should be more accessible and easier to update/maintain/expand. > the page which is easily confused with a real navigation). So if one has > better suggestions (i would also like to get rid of the security nightmare > also known as php), i would like to hear about it. My preference is TWiki - stable, powerful, extensible and Perl rather than PHP. Regards James Turnbull -- James Turnbull <[EMAIL PROTECTED]> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/159059/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) signature.asc Description: OpenPGP digital signature
Future of the wiki in 2007?
As some of you might or might now know, i'm the holder of the qpsmtpd.org domain and also host the qpsmtpd wiki on wiki.qpsmtpd.org. Now while the wiki still seems to be a good idea, i've noticed that there have been next to no contributions to it lately. This is a bit of a shame, as qpsmtpd lacks good documentation and i hoped the wiki would solve that problem in a collaborating way. I'm looking for suggestions how to continue with the wiki in 2007. What i especially would like to know if the wiki installed (dokuwiki) is fine or if you would like to see some other wiki software installed instead. I used dokuwiki because i've had enough with the bloatness of mediawiki (which i used for two other projects), but i've noticed that dokuwiki can be confusing at times (especially this "browsing history" at the top of the page which is easily confused with a real navigation). So if one has better suggestions (i would also like to get rid of the security nightmare also known as php), i would like to hear about it. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
