Re: man.cgi doesn't find symlinked manpages

[Ingo Schwarze <schwarze@usta.de>]

Hello Abigail,

so far, i did not manage to reproduce.

So we have to inspect more closely what is going on on that particular
machine.

Abigail G wrote on Mon, Apr 04, 2022 at 01:25:13PM -0400:

> I'm working on tracking down an issue with the Void Linux instance of
> man.cgi, man.voidlinux.org, which uses mandoc v1.14.6.
> 
> Manpages that are symlinks of other manpages are not included in the
> results of a man.cgi search, returning 404, but are confirmed to exist
> in the mandoc.db the cgi uses. An example of this is xlocate(1), which
> is a symlink of xtools(1). `man xlocate`, `apropos xlocate`, and
> `whatis xlocate` work fine locally on that host,

Those commands are probably not using the particular database nor
the directory hierarchy used by the CGI script (both inside the
webserver chroot), but instead a system-wide directory hierarchy
outside the chroot, probably somewhere below /usr/.

To help narrow down the problem, could you please get a local shell
on that machine, use the "cd" shell builtin command to change
into the webserver chroot, then "cd" down further the directory
containing all the man1 man2 man3... subdirectories for the
manual page collection your man.cgi is using.  When you changed to
the correct directory, the command "less ../manpath.conf" should show
the configuration file man.cgi is using, and the command "ls mandoc.db"
should find the mandoc database that man.cgi is using.

In this directory, could you please run these commands and show
the results:

   $ man -M . -w xtools
   $ man -M . -w xlocate
   $ man -M . xtools | head -n 1
   $ man -M . xlocate | head -n 1
   $ ls -ald man1/xtools.1 man1/xlocate.1

> but the same query via cgi does not when using the 'man' button.
> Using the 'apropos' button does, however.

On my test server man.bsd.lv, i have just done this:

   $ cd /var/www/vhosts/man.bsd.lv/man/
   $ vi manpath.conf    # to add a line reading "Test"
   $ mkdir Test
   $ cd Test
   $ mkdir man1
   $ cp /usr/share/man/man1/true.1 man1/xtools.1
   $ ln -s xtools.1 man1/xlocate.1
   $ ls -al man1/x*
  lrwxr-xr-x 1 schwarze mdocml    8 Apr 8 10:32 man1/xlocate.1 -> xtools.1
  -r--r--r-- 1 schwarze mdocml 2283 Apr 8 10:30 man1/xtools.1
   $ makewhatis .
   $ man -M . -w xtools 
  /var/www/vhosts/man.bsd.lv/man/Test/man1/xlocate.1
   $ man -M . -w xlocate
  /var/www/vhosts/man.bsd.lv/man/Test/man1/xlocate.1
   $ man -M . xtools | head -n 1   
  TRUE(1)                General Commands Manual               TRUE(1)
   $ man -M . xlocate | head -n 1
  TRUE(1)                General Commands Manual               TRUE(1)

And now

  https://man.bsd.lv/Test/xlocate

works for me whereas

  https://man.voidlinux.org/xlocate
  https://man.voidlinux.org/xlocate.1
  https://man.voidlinux.org/man1/xlocate.1
  https://man.voidlinux.org/?query=xlocate

do not.

So i suspect that something more might be going on in addition to merely
having a symbolic link.  No idea yet what it could be, though.

Maybe if you answer the questions above that might provide a clue.

> I've narrowed it down to the following in pg_search() in cgi.c:
> 
> 	if (req->isquery && req->q.equal && argc == 1)
> 		pg_redirect(req, argv[0]);
> 	else if (mansearch(&search, &paths, argc, argv, &res, &ressz)
> == 0)
> 		pg_noresult(req, 400, "Bad Request",
> 		    "You entered an invalid query.");
> 	else if (ressz == 0)
> 		pg_noresult(req, 404, "Not Found", "No results
> found.");
> 	else
> 		pg_searchres(req, res, ressz);
> 
> and the search mode that man.cgi is using (req->q.equal), which seem to
> imply that mansearch() is not finding the symlink in its search because
> of the mode of search that it is in.

The request for https://man.voidlinux.org/xlocate returns

  "No results found."

which means we somehow get into the "ressz == 0" branch for some reason.
So the mansearch(3) internal API function did not produce the desired
result.  Very strange indeed.

> Is this the intended behaviour?

I don't think so, but i don't see just yet where exactly the problem is.

> If so, can it be changed to match man,
> apropos, and whatis? Not finding the page in one search method is a
> bit unintuitive to me, at least.

Right, we should figure this out.  It looks mysterious.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv