Re: gitweb: (potential) problems with new installation

Re: gitweb: (potential) problems with new installation

[Jakub Narebski]

[Cc-ed to git mailing list, again this time without HTML]

On Mon, 27 Feb 2012, Ramsay Jones wrote:
 
> I recently decided to update the gitweb installation on my laptop, since
> it was still running version 1.5.5! (also, the cgit I have installed is
> about the same vintage ...)
> 
> The version of gitweb I installed was, simply because I had just built
> and tested it, the version included in the pu branch as of a couple of
> days ago (commit 8544a26).
> 
> First, I should say that I had to modify the script, and move the static
> directory out of cgi-bin, in order to get it to work.

You should never have to modify generated gitweb.cgi script; that is what
configuration file, gitweb_config.perl by default, is for.  It is well
documented in gitweb.conf(5) manpage, which in turn is referenced in
gitweb(1) manpage... at least with modern git.

Note also that you can specify where to put static files (page 
prerequisites) during "make install"... though that it would not obviate
need to create and edit gitweb configuration file.

>                                                       However, this is 
> not something new; I had to do the same with the previous version. The
> problem is obviously an apache configuration problem, which I tried to
> fix last time and (having spent *lots* of effort) gave up on; the main
> symptom of the problem is that apache attempts to *exec* any file in
> cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which
> fills up the apache error logs with "permission denied" errors while
> trying to exec.

Strange.  Which version of Apache are you using, and how do relevant
parts of Apache configuration (httpd.conf etc.) look like?  

If you use ScriptAlias directive, or ExecCGI option, then the problem
might be executable permissions -- Apache shouldn't execute scripts
without execute permission set as CGI scripts... errr... are you running
httpd as root?

You can move to using "AddHandler cgi-script .cgi" instead.

> 
> Anyway, I moved the static directory into a gitweb directory (as a sibling
> to cgi-bin) and changed the paths in gitweb.cgi by prefixing "../gitweb/".
> 
> Now that I had working gitweb, I played with some of the new features and
> noticed a few problems ... I suspect that most of the problems are caused
> by my *old* version of firefox, which is:
> 
>     firefox version 2.0.0.3
> 
>     Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) \
>     Gecko/20061201 Firefox/2.0.0.3

I have even older web browser:

      Mozilla 1.7.12

      Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) \
      Gecko/20050923 MultiZilla/1.7.9.0a

> However, I hope the following may be of use; even if only to document a
> version of firefox that is not supported by gitweb. ;-)
> 
>     1. The new date timezone pop-up; The pop-up window comes up directly
>        over the date, so you can no longer read it, and once you have set
>        the desired timezone, it can not be dismissed. (including the x
>        button on the window). The only way to remove it is to refresh the
>        page, which makes it a little less that useful ... :-D

Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time
of writing Firefox, Chrome, IE, and ancient Konqueror without encountering
any problems.

Could you at minimum check for JavaScript errors using JavaScript Console
(clearing it and reloading gitweb page if needed)?  Please provide line
where error is with a bit of context (around 3 lines).


Note also that as workaround you can simply turn off this feature: put
the following line in gitweb configuration file:

  $feature{'javascript-timezone'}{'default'} = [];
 
>     2. The error console shows a repeated warning about the css file, like
>        so:
> 
>            Warning: Error in parsing value for property 'display'.  \
>            Declaration dropped.
>            Source File: http://localhost/gitweb/static/gitweb.css
>            Line: 621
> 
>        which corresponds to the following in gitweb.css:
> 
>            div.remote {
> 	       margin: .5em;
> 	       border: 1px solid #d9d8d1;
> 	       display: inline-block;       <-- line 621
>            }

This is probably caused by the fact that your web browser doesn't
understand this value of 'display' property because it is too old,
and does not implement CSS2.1 fully.


  9.2.4 The 'display' property

  inline-block
     This value causes an element to generate an inline-level block
     container. The inside of an inline-block is formatted as a block
     box, and the element itself is formatted as an atomic inline-level
     box.


Nb. this is probably not necessary, gitweb looks just fine without it.

>     3. I mis-typed an search term into the project search box and didn't
>        see the error message displayed by firefox as I expected (maybe
>        incorrectly?). Firefox displayed:
> 
>            XML Parsing Error: xml declaration not at start of external entity
>            Location: http://localhost/cgi-bin/gitweb.cgi?a=project_list&\
>                s=*git.*%5C.git&btnS=Search
>            Line Number 30, Column 1:
>            <?xml version="1.0" encoding="utf-8"?>
>            ^

It is the problem with older Firefoxes, namely that with XHTML DTD and
with application/xhtml+xml mimetype it enters strict XML compliance mode.
If webpage is not well-formed XML it would display XML error page instead.
It is enough that there is some whitespace before <?xml ... ?> processing
instruction... which might make for intermittent and annoying to squash
Heisenbug.

But in some cases it might happen if there are warnings or errors created
by Perl itself and converted to web page by CGI::Carp (fatalsToBrowser).
 
>        The apache error log looked correct:
> 
>            [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \
>            in regex; marked by <-- HERE in m/* <-- HERE git.*\.git/ at \
>            /var/www/cgi-bin/gitweb.cgi line 3084.

Hmmm... if we don't use regexp search, then all metacharacters should be
quoted, including leading '*'.  Strange.

If you did use regexp search, then it is a real issue, and it is not
something I have thought about.  Your search term

  *git.*\.git

is invalid regexp, because '*' quantifier which means zero or more 
occurrences does not follow any term.  Valid regexp is

  .*git.*\.git

or just

  git.*\.git

Gitweb should probably check that regexp is valid before using it.
Thanks for reporting this; I'll try to fix it shortly.

>        Whereas the page source did look wrong. Just in case it would be of
>        use, I have included the page source below.

Thanks.

Damn, I thought that I have that issue squashed!  The problem is when
there is error thrown or warning triggered when gitweb already printed
part of page.  The error handler then writes error page from beginning
inside existing page... not good.

I'll try to look at this.

> As I said above, I suspect these problems are caused by my relatively old
> Linux installation (I keep meaning to get around to updating, but I must
> say that I don't like the new Ubuntu, although Linux Mint 12 looks quite
> good ...).
> 
> Having said that, ignoring the new features, gitweb is working fine for
> me (I only installed it in the first place to test it out ...). Also, the
> above represents (literally) only ten minutes of playing around with the
> new features, without having read any documentation or code. So, if I have
> mis-understood how something should work, then sorry for the noise! :(
> 
> Hope this helps.
> 
> ATB,
> Ramsay Jones

[cut example HTML output]

-- 
Jakub Narebski
Poland

Re: gitweb: (potential) problems with new installation

[Ramsay Jones]

Jakub Narebski wrote:
>> First, I should say that I had to modify the script, and move the static
>> directory out of cgi-bin, in order to get it to work.
> 
> You should never have to modify generated gitweb.cgi script; that is what
> configuration file, gitweb_config.perl by default, is for.  It is well
> documented in gitweb.conf(5) manpage, which in turn is referenced in
> gitweb(1) manpage... at least with modern git.

Indeed, but I find "sudo bash; cd /var/www/cgi-bin; vim gitweb.cgi; etc..."
just as easy! :-D

However, ... point taken.

>>                                                       However, this is 
>> not something new; I had to do the same with the previous version. The
>> problem is obviously an apache configuration problem, which I tried to
>> fix last time and (having spent *lots* of effort) gave up on; the main
>> symptom of the problem is that apache attempts to *exec* any file in
>> cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which
>> fills up the apache error logs with "permission denied" errors while
>> trying to exec.
> 
> Strange.  Which version of Apache are you using, and how do relevant
> parts of Apache configuration (httpd.conf etc.) look like?

Heh, I only described the above apache config problems (in the spirit of
full disclosure) so that you would not be surprised by certain files not
being in their usual location ... It wasn't a sneeky attempt to get some
apache support! Having said that, my apache version is:

    Apache/2.2.3 (Ubuntu) mod_perl/2.0.2 Perl/v5.8.8 configured

> If you use ScriptAlias directive, or ExecCGI option, then the problem
> might be executable permissions -- Apache shouldn't execute scripts
> without execute permission set as CGI scripts... errr... are you running
> httpd as root?

No, it's running as www-data (well, the initial apache is run as root, but
all worker processes are run as www-data - only the worker processes actually
handle requests, I think).

> You can move to using "AddHandler cgi-script .cgi" instead.

I remember having tried that as well - without success.

>>     1. The new date timezone pop-up; The pop-up window comes up directly
>>        over the date, so you can no longer read it, and once you have set
>>        the desired timezone, it can not be dismissed. (including the x
>>        button on the window). The only way to remove it is to refresh the
>>        page, which makes it a little less that useful ... :-D
> 
> Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time
> of writing Firefox, Chrome, IE, and ancient Konqueror without encountering
> any problems.
> 
> Could you at minimum check for JavaScript errors using JavaScript Console
> (clearing it and reloading gitweb page if needed)?  Please provide line
> where error is with a bit of context (around 3 lines).

I don't have a JavaScript Console. (I suppose that is an add-on? Hmm, I don't
have internet access from Linux... ).

> Note also that as workaround you can simply turn off this feature: put
> the following line in gitweb configuration file:
> 
>   $feature{'javascript-timezone'}{'default'} = [];

Thanks. [BTW, if it wasn't clear before, you cannot grab the pop-up and move
it out of the way...]

>>     2. The error console shows a repeated warning about the css file, like
>>        so:
>>
>>            Warning: Error in parsing value for property 'display'.  \
>>            Declaration dropped.
>>            Source File: http://localhost/gitweb/static/gitweb.css
>>            Line: 621

> 
> This is probably caused by the fact that your web browser doesn't
> understand this value of 'display' property because it is too old,
> and does not implement CSS2.1 fully.

Yep, I suspected as much. Not a Problem.

>>        The apache error log looked correct:
>>
>>            [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \
>>            in regex; marked by <-- HERE in m/* <-- HERE git.*\.git/ at \
>>            /var/www/cgi-bin/gitweb.cgi line 3084.
> 
> Hmmm... if we don't use regexp search, then all metacharacters should be
> quoted, including leading '*'.  Strange.

Yes, this happens whether the re checkbox is set or *not*.

> If you did use regexp search, then it is a real issue, and it is not
> something I have thought about.  Your search term
> 
>   *git.*\.git
> 
> is invalid regexp, because '*' quantifier which means zero or more 
> occurrences does not follow any term.  Valid regexp is
> 
>   .*git.*\.git

Indeed, this is the regexp I had intended. (I started with a glob pattern,
noticed the re checkbox, checked it, then went back to edit the search
text, but forgot the initial '*' quantifier)

Thanks.

ATB,
Ramsay Jones

Re: gitweb: (potential) problems with new installation

[Jakub Narebski]

On Fri, 2 Mar 2012, Ramsay Jones wrote:
> Jakub Narebski wrote:

> > > First, I should say that I had to modify the script, and move the static
> > > directory out of cgi-bin, in order to get it to work.
> > 
> > You should never have to modify generated gitweb.cgi script; that is what
> > configuration file, gitweb_config.perl by default, is for.  It is well
> > documented in gitweb.conf(5) manpage, which in turn is referenced in
> > gitweb(1) manpage... at least with modern git.
> 
> Indeed, but I find "sudo bash; cd /var/www/cgi-bin; vim gitweb.cgi; etc..."
> just as easy! :-D
> 
> However, ... point taken.

Note that position of static files, and where they are installed, can
be set at build time.
 
> > >                                                       However, this is 
> > > not something new; I had to do the same with the previous version. The
> > > problem is obviously an apache configuration problem, which I tried to
> > > fix last time and (having spent *lots* of effort) gave up on; the main
> > > symptom of the problem is that apache attempts to *exec* any file in
> > > cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which
> > > fills up the apache error logs with "permission denied" errors while
> > > trying to exec.
> > 
> > Strange.  Which version of Apache are you using, and how do relevant
> > parts of Apache configuration (httpd.conf etc.) look like?
> 
> Heh, I only described the above apache config problems (in the spirit of
> full disclosure) so that you would not be surprised by certain files not
> being in their usual location ... It wasn't a sneeky attempt to get some
> apache support! Having said that, my apache version is:
> 
>     Apache/2.2.3 (Ubuntu) mod_perl/2.0.2 Perl/v5.8.8 configured

Do you use CGI (mod_cgi or mod_cgid), or mod_perl?
 
> > If you use ScriptAlias directive, or ExecCGI option, then the problem
> > might be executable permissions -- Apache shouldn't execute scripts
> > without execute permission set as CGI scripts... errr... are you running
> > httpd as root?
> 
> No, it's running as www-data (well, the initial apache is run as root, but
> all worker processes are run as www-data - only the worker processes actually
> handle requests, I think).

Strange.  WORKSFORME anyway...
 
> > You can move to using "AddHandler cgi-script .cgi" instead.
> 
> I remember having tried that as well - without success.

This must be done _instead_ of ScriptAlias directive and/or ExecCGI option.

> > >     1. The new date timezone pop-up; The pop-up window comes up directly
> > >        over the date, so you can no longer read it, and once you have set
> > >        the desired timezone, it can not be dismissed. (including the x
> > >        button on the window). The only way to remove it is to refresh the
> > >        page, which makes it a little less that useful ... :-D
> > 
> > Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time
> > of writing Firefox, Chrome, IE, and ancient Konqueror without encountering
> > any problems.
> > 
> > Could you at minimum check for JavaScript errors using JavaScript Console
> > (clearing it and reloading gitweb page if needed)?  Please provide line
> > where error is with a bit of context (around 3 lines).
> 
> I don't have a JavaScript Console. (I suppose that is an add-on? Hmm, I don't
> have internet access from Linux... ).

JavaScript Console is built in, though there are plugins like Console^2
that extend it.

In Mozilla 1.7.12 it is "Tools > Web Development > JavaScript Console"
It is "Tools > Errors Console" or "Tools > Web Console" in modern Firefox.
 
> > Note also that as workaround you can simply turn off this feature: put
> > the following line in gitweb configuration file:
> > 
> >   $feature{'javascript-timezone'}{'default'} = [];
> 
> Thanks. [BTW, if it wasn't clear before, you cannot grab the pop-up and move
> it out of the way...]

Well, of course.  Currently JavaScript is hand-written, and does not use
any of JavaScript toolkits / UI frameworks.  There are some plans to move
gitweb to use jQuery or MooTools library (YUI is probably too large).
 
> > >        The apache error log looked correct:
> > >
> > >            [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \
> > >            in regex; marked by <-- HERE in m/* <-- HERE git.*\.git/ at \
> > >            /var/www/cgi-bin/gitweb.cgi line 3084.
> > 
> > Hmmm... if we don't use regexp search, then all metacharacters should be
> > quoted, including leading '*'.  Strange.
> 
> Yes, this happens whether the re checkbox is set or *not*.

As I wrote in a separate thread, there were two separate errors, and both
need to be fixed.
 
> > If you did use regexp search, then it is a real issue, and it is not
> > something I have thought about.  Your search term
> > 
> >   *git.*\.git
> > 
> > is invalid regexp, because '*' quantifier which means zero or more 
> > occurrences does not follow any term.  Valid regexp is
> > 
> >   .*git.*\.git
> 
> Indeed, this is the regexp I had intended. (I started with a glob pattern,
> noticed the re checkbox, checked it, then went back to edit the search
> text, but forgot the initial '*' quantifier)

Fixed-string search should have worked even if this string contains
regexp metacharacters like '*'.  '*foo' searches for literal '*foo'
(using /\*foo/ search regexp)... or at least it should (send a patch
fixing this).

-- 
Jakub Narebski
Poland

Re: gitweb: (potential) problems with new installation

[Ramsay Jones]

Jakub Narebski wrote:
> Do you use CGI (mod_cgi or mod_cgid), or mod_perl?

mod_cgid although mod_perl is also available (and *is* used by git-instaweb).

>>> You can move to using "AddHandler cgi-script .cgi" instead.
>> I remember having tried that as well - without success.
> 
> This must be done _instead_ of ScriptAlias directive and/or ExecCGI option.

Indeed :-D

I had another quick look at this and (I now remember) the AddHandler approach
actually *did* work. However, I already had some other (perl, shell) scripts
in cgi-bin and would have had to add file extensions ('.pl' or '.sh') in order
for them to keep working.

The relevant part of httpd.conf looks like this:

<Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
        # This directive allows us to have apache2's default start page
        # in /apache2-default/, but still have / go to the right place
        #RedirectMatch ^/$ /apache2-default/
</Directory>

ScriptAlias /cgi-bin/ /var/www/cgi-bin/
<Directory "/var/www/cgi-bin">
       Options +ExecCGI
</Directory>
<Directory "/var/www/cgi-bin/static">
       Options -ExecCGI
</Directory>

#<Directory "/var/www/cgi-bin">
#        Options +ExecCGI
#        AddHandler cgi-script .cgi .pl .sh
#</Directory>

Note that the "/var/www/cgi-bin/static" directory entry *should* have solved
the problem, but it does not make any difference at all!

BTW, the error.log entries look like:

[Sun Mar 04 15:06:03 2012] [error] (13)Permission denied: exec of '/var/www/cgi-bin/static/gitweb.css' failed
[Sun Mar 04 15:06:03 2012] [error] [client 127.0.0.1] Premature end of script headers: gitweb.css, referer: http://localhost/cgi-bin/gitweb.cgi

with similar entries for git-logo.png and gitweb.js. The access log show
"500 Internal Server error" responses for gitweb.css, git-logo.png and gitweb.js.

Maybe I should re-visit the decision and swap over to using the AddHadler
approach - adding file extensions is not that hard! ;-)

Anyway, the above should work as-is, and I'm somewhat puzzled that it doesn't.
However, as I said before, it's not a gitweb fault.

>>> Could you at minimum check for JavaScript errors using JavaScript Console
>>> (clearing it and reloading gitweb page if needed)?  Please provide line
>>> where error is with a bit of context (around 3 lines).
>> I don't have a JavaScript Console. (I suppose that is an add-on? Hmm, I don't
>> have internet access from Linux... ).
> 
> JavaScript Console is built in, though there are plugins like Console^2
> that extend it.
> 
> In Mozilla 1.7.12 it is "Tools > Web Development > JavaScript Console"
> It is "Tools > Errors Console" or "Tools > Web Console" in modern Firefox.

Ah, OK. I thought you meant something other than the "Error Console".
In that case, *no* javascript errors appear in the error console.

ATB,
Ramsay Jones