[sharp-discuss] apache2 not starting on Ubuntu 7.04 SHARP installation

Thu Aug 14 19:31:15 CEST 2008

Dear Lee,

On Thu, Aug 14, 2008 at 12:33:08PM -0400, Lee S Parsons wrote:
>> You should be able to create new users for the SHARP server by doing:
>>
>>   % cd /where/ever/sharp
>>   % source ./setup.csh           # tcsh/csh
>>     - or -
>>   % . ./setup.sh                 # sh/bash/ksh/zsh
>>   % adm/bin/newuser
>>
>>   
>
>
> I should have mentioned, I was able to create new users using the newuser 
> script, but I could never log in as them.  Only the user that I created 
> when setting up SHARP was allowed in. 

I see. the problem then is probably that the email that should have
been sent out by this 'newuser' command didn't get to them? Often,
email isn't setup on the machine you're running SHARP/autoSHARP. But
the email is actually also saved in

  $BDG_home/users/USERNAME

so you can have a look at it. The important bit is that every newly
created user needs to run the useSHARP script. It's quite simple:
he/she needs to run

  % /where/ever/sharp/bin/useSHARP USERNAME

(where USERNAME is the SHARP username given when running the 'newuser'
script).

>>   % cd /where/ever/sharp
>>   % source ./setup.csh           # tcsh/csh
>>     - or -
>>   % . ./setup.sh                 # sh/bash/ksh/zsh
>>   % adm/bin/kill_server
>>   % adm/bin/restart_server
>>   % adm/bin/check_server
>>
>>   
>
> As mentioned, restart_server (sorry about the earlier typo) dies 
> immediately with the "AuthUserFile" error that I mentioned earlier.  Still 
> trying to figure out how to get around that one...

It's all related to you using a 2.X version of the Apache httpd
distributed by the OS supplier (I'm prettu sure about that).

> Though kill_server is now irrelevant, since the server doesn't start at all 
> since the reboot...

True: but sometimes the server can't be restarted because th httpd.pid
file of a dead instance is still lurking around. Then the
'kill_server' command is the easiest way of getting rid of it.

>> You are trying to use apache2 as the httpd for SHARP/autoSHARP? This
>> is different from the recommended version of the apache httpd (1.3.X)
>> that also comes with the SHARP/autoSHARP files
>> (helpers_server.*.tar.gz). There is a basic example configuration file
>> for apache2 available in $BDG_home/sushi/conf, but this might need
>> some tweaking and editing before it is going to work.
>>
>>   
>
> Maybe I misread the installation information on the SHARP website - I 
> thought I had to install Apache before installing SHARP. 

This might have been unclear: we do supply a pre-compield Apache 1.3.X
httpd binary that _should_ work out of the box (and running
'installSHARP -F' will automatically try using it). If it doesn't work
right away, then the recommendation is to install a fresh 1.3.X
version according to the README file mentioned.

>> If at all possible, try to use the 1.3.X httpd binary that comes as
>> part of the installation. Or compile your own 1.3.X binary - for
>> details see $BDG_home/helpers/*/httpd.README_GPhL on how to do that.
>>
>>   
>
> I just tried starting the 1.3.34 that came with SHARP - I extracted the 
> contents of the tarball into /usr/local/Helpers-server/ (notice the 
> intentional capitalization).

You should install it into $BDG_home too as part of the 'installSHARP
-F'. You can in principle install it into a different directory, but
that is just making your life difficult I guess.

> I then tried
>
> /usr/local/Helpers-server/httpd -f 
> /usr/local/SHARP/sushi/conf/httpd-1.3.conf
>
> And the response was a core dump. 

Yes.

>> If you are using a apache httpd binary coming with your operating
>> system: be aware that these are very often compiled/configured
>> differently from a plain default installation of the official Apache
>> httpd distribution. OS supplier configure their version of the Apache
>> httpd very modular which would require that you have to manually load
>> all kind of modules before it will behave as expected by
>> SHARP/autoSHARP (which assumes a httpd installation based on the
>> official Apache httpd distribution).
>>
>>   
> I think I have the modules part figured out - it seems that there is a 
> syntax problem somewhere in here that involves the difference in 
> configurations between Apache 1.3.x and 2.2.x.   I verified which modules 
> to run for Apache2 (and we even had it somehow working right after the 
> SHARP install - just never again). 

Good - if you get it to work with your OS-supplied apache2 binary and
a configuration file in $BDG_home/sushi/conf I'm impressed. I never
bothered, because using a plain 1.3.X is just much easier.

>> 2 possibilities (with 2 sub-possibilities each):
>>
>>   1. use a 1.3.X version of the httpd
>>
>>      a) we do ship pre-compiled binaries inside of
>>         helpers_server.*.tar.gz that can be tried
>>   
>
> I've tried them, and found that:
> ( .RedHat-FC3, .glibc23, .SuSE-9.1, .SuSE-9.3) return an error on not being 
> able to resolve the FQDN, and then promptly die without leaving any 
> messages

If you want to test different httpd binaries you need to do this
through the 'httpd-setup' admin tool. So running the sequence

  % adm/bin/kill_server   # just in case
  % adm/bin/httpd-setup   # and pick the httpd and conf file you want
                          # to use
  % adm/bin/restart_server
  % adm/bin/check_server
  % ps -efl | egrep "httpd|apache2"  # just in case

will show you if the combination of httpd binary and configuration
file is working.

> ( .RedHat-7.3, .glibc22, and "httpd" with nothing after it) all segfault 
> and core dump. 
> This was when using the config file at 
> /usr/local/SHARP/sushi/conf/httpd-1.3.conf
>
>
>>      b) if none of those works (because of the way the httpd is built
>>         this can happen): just follow the instructions in
>>         /usr/local/SHARP/helpers/*/httpd.README_GPhL to compile your
>>         own (very easy). This is then guaranteed to work on that
>>         machine.
>>
>>   
>
> When I opened the tarball "helpers_server.linux.tar.gz", there was no file 
> "apache_1.3.34.tar.gz" as suggested by httpd.README_GPhL.  Should I 
> download that version directly from the Apache group and build it myself?

Yes - and you can download the latest from the 1.3.X series.

This option is by far the safest for getting everything to work!

>>   2. use a 2.X version of the httpd: you will most likely need to do
>>      some editing in the configuraiton file.
>>
>>        a) try using the system-supplied apache2 binary: you need to load
>>         additional modules ... but I don't know which (depends on your
>>         operating system and how the vendor has configured it)
>>
>>   
>
> It seems like the problem lies in how the "AuthUserFile" method is called.  
> I'm looking to see if I can find good documentation on how it may have 
> changed between apache 1.3.x and 2.2.x.  I am starting to wonder if perhaps 
> "AuthUserFile" may have been deprecated (in name) along the way and 
> replaced by something else.

I think it is a module that needs to be enabled. Apache2 is much more
modular by default _and_ the OS supplier are keen on modular httpds
...

>>      b) compile your own 2.X version
>>
>> I would definitely go with option 1 (hopefully a) but b) is easy
>> enough as well). Yes, 1.3.X is a bit older version, but this is a
>> httpd running on a local machine on a non-privileged port (8080) under
>> a non-root account (right?) behind a firewall (I guess) ... so I can't
>> really see any security implications here.
>>
>>
>>   
>
> As much as I didn't think I'd be saying this, we aren't really much at all 
> concerned about security on this system.  You are correct that it is behind 
> a firewall, running as a non-root account.  Apache2 was built just because 
> this system had no webserver on it prior, so it seemed logical at the time 
> to build the newest version.  We certainly didn't expect to walk into this 
> mess with the Apache2 config files, or we would have built the older 
> version instead.

I agree: we need to find the time to move the system to the latest 2.X
series of Apache ... touche ;-)

> Any insight on where to go next with this would be great. 

Option 1b) followed by httpd-setup.

Cheers

Clemens

-- 

***************************************************************
* Clemens Vonrhein, Ph.D.     vonrhein AT GlobalPhasing DOT com
*
*  Global Phasing Ltd.
*  Sheraton House, Castle Park 
*  Cambridge CB3 0AX, UK
*--------------------------------------------------------------
* BUSTER Development Group      (http://www.globalphasing.com)
***************************************************************