Re: t5539 fails on ubuntu for v2.0.0-rc2

From: Fabio D'Alfonso <fabio.dalfonso@fabiodalfonso.com>
Date: May 9, 2014, 16:43 UTC
Message-ID: <536D05CE.6040004@fabiodalfonso.com>
In-Reply-To: <20140509155945.GG18197@sigill.intra.peff.net>

Hi, yes, the problem comes from root. I made a make test using "git" user in my 12.04 server where there is a gitlab and the test went on for 5539. I think the 3 could be the better solution.

This is not the place to discuss about the sudo mania, a disease I did not get and hope not to get, but let me share just a short think. Oracle, by product was never made possible to install as a root on linux/unix , while OEL allow the login to made any system / maintenance activity. Such a kind of protection , 'product configuration based' protection, targeted to the needs of the specific usage , always made sense: smoothly configure the system , then stay in the bound of the product.

Why I should manage a possibly try and trash personal desktop (or a 3 backups VM) as the NSA server is a mistery I do not want to solve. So this seems a way to give a box to a dumb, to prevent the breakage. Last but not least, desktop involve shortcuts and other things, that fly to the root when something is set up by sudo, and I used to put software in /opt for out of the tree stuff (e.g. netbeans or smartgit) , and should have to fight with myself to access my setups. The server setup I made for gitlab has quite sense with its user for the same reason the oracle pretends and in both cases it is a server , you get access to your service not being aware of the mechanics of the backend. In a personal desktop, where confort is the premiere need, all this seems quite stupid to be forced, also any one could use if he wants.

Sorry for the digression, but it is starting to hurt, generally speaking.

Fabio D'Alfonso 'Enabling Business Through IT' cell. +39.348.059.40.22 *** web: www.fabiodalfonso.com <http://www.fabiodalfonso.com/> email: fabio.dalfonso@fabiodalfonso.com <mailto:fabio.dalfonso@fabiodalfonso.com>linkedin: www.linkedin.com/in/fabiodalfonso <http://it.linkedin.com/in/fabiodalfonso> twitter: www.twitter.com/#!/fabio_dalfonso <http://www.twitter.com/#%21/fabio_dalfonso>

fax: +39.06.874.599.581 BlackBerry® Wireless Enabled Address.

          ** Hidden  numbers are automatically rejected by the phone*

On 5/9/2014 5:59 PM, Jeff King wrote:

Show 49 quoted lines

> On Thu, May 08, 2014 at 08:02:28AM +0200, Fabio D'Alfonso wrote:
>
>> this is the error in httpd error.log
>>
>>   [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
>> from  uid 4294967295, you probably need to modify the User directive
>>   [Wed May 07 20:44:10 2014] [notice] Apache/2.2.17 (Ubuntu) configured --
>> resuming normal operations
>>   [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
>> from  uid 4294967295, you probably need to modify the User directive
>>   [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
>> from  uid 4294967295, you probably need to modify the User directive
>>   [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
>> from  uid 4294967295, you probably need to modify the User directive
>>   [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
>> from  uid 4294967295, you probably need to modify the User directive
>>   [Wed May 07 20:44:11 2014] [alert] Child 12037 returned a Fatal error...
>> Apache is exiting!
> Hmm.  Some googling turned up a similar case:
>
>    http://www.linuxquestions.org/questions/linux-server-73/apache-won%27t-start-because-490312/
>
> It looks like apache is trying to getpwuid (probably as part of doing a
> setuid on its children), failing, and then crashing. I suspect that this
> is related to you running as root, as a non-root apache would not want
> to (nor be able to) call setuid.
>
> Does running the tests as a non-root user fix it? If so, I think we have
> a few options in git:
>
>    1. Add a User directive to our httpd.conf. I doubt this is a good
>       idea to do unconditionally, as a non-root apache would probably be
>       unhappy with it.
>
>    2. Add a User directive when we detect that the tests are running as
>       root.  This might work, but I'm a bit iffy, as we do not know the
>       appropriate username for the system (e.g., "nobody" versus
>       "www-data" versus something else).
>
>    3. Just disable the http tests when run as root.
>
> I think I'd favor 3. But I'd like to be sure that being root is the
> problem.
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html