From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout.scc.kit.edu (scc-mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id pAOMZqHN016584 for ; Thu, 24 Nov 2011 17:35:52 -0500 (EST) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1RThtW-0005C6-J3; Thu, 24 Nov 2011 23:35:50 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1RThtW-0002L2-JH for discuss@mdocml.bsd.lv; Thu, 24 Nov 2011 23:35:50 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1RThtW-0000cQ-Hl for discuss@mdocml.bsd.lv; Thu, 24 Nov 2011 23:35:50 +0100 Received: from schwarze by usta.de with local (Exim 4.72) (envelope-from ) id 1RThtW-0002bF-H2 for discuss@mdocml.bsd.lv; Thu, 24 Nov 2011 23:35:50 +0100 Date: Thu, 24 Nov 2011 23:35:50 +0100 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: Re: man.cgi in "online" mode Message-ID: <20111124223550.GA9283@iris.usta.de> References: <4ECEB84A.20203@bsd.lv> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ECEB84A.20203@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, Kristaps Dzonsons wrote on Thu, Nov 24, 2011 at 10:34:02PM +0100: > If you're looking at commits and tech@ messages, you'll notice a lot > of work in apropos(1) and mandocdb(8). Yes, and we'll have to resync, i hope to do a bit of that this weekend, let's see how far i can get. > What's not mentioned much is man.cgi, which is similar to existing > man.cgi scripts but with the power of our apropos(1) and mandoc(1) > as a renderer. The biggest problem with that currently is that the interface is incompatible. Yes, the old interface is horrible (sektion=, anyone?), but we can't break existing links. I hope to work on that at one point, but one thing at a time, i first have to get mandocdb(8) and apropos(1) ready for production in base. Probably, in some way or another, man.cgi will have to support both the traditional man.cgi syntax and the new apropos(1) syntax. I haven't thought about the details yet. > To date, I've designed man.cgi to run in "secure" and "insecure" > mode. In general, secure and insecure mode tend to make very little sense. You want to have one mode that's secure *and* works, not two (one securely non-working and one working insecurely). > "Insecure" mode is for non-jailed CGI processes, scanning the > system's mandocdb(8) (like apropos(1)) and formatting output with > mandoc(1). The "secure" mode uses mandocdb(8) databases and a cache > of pre-formatted manpages, both kept fresh with the new-born > manup(8) utility. The so-called secure mode makes more sense to me, also regarding efficiency. If we need to serve from source code, which i'm not yet sure we really have to, but maybe i'm missing something, then i'd probably try to just link both the parsers and the -Thtml formatter right into the man.cgi executable. Not sure whether that would fly, but it might be worth a try. Of course, it's not urgent. First, what matters is a system that serves the manuals at all, with the right interface. > One triggers insecure mode by passing the > $INSECURE variable to the CGI script. > > The question is as follows: is an "insecure" mode reasonable? It's > a security risk to allow a CGI to fork()/exec() at all, which makes > it unlikely for public-facing servers. But it's a hassle to set up > and maintain a server just for internal manpages. And do manuals > really change so much that on-line rendering is necessary? The > "secure" mode cache is freshened with a single command invocation, > only updating what's out of date (quickly, at that). I tend to think that the so-called secure mode is sufficient and running one command for setup seems acceptable (i don't like the name "manup", but that's not a crucial point). Ultimately, i think giving a working, compatible system and setup instruction to Bob Beck and seeing what happens will be the test to see whether what we built is usable, and only when that has run for some time in public and -current snapshots have been sucessfully installed for a few times (without Bob complaining about having to do tedious work) should we consider the design finished and proven good. Until then, we should be ready to implement tweaks that practice might teach us. > My thought is to write a Firefox add-in to do this instead, I think this has nothing to do with browsers at all, and writing Firefox plugins is a complete waste of time no matter what the purpose might be. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv