Installation errors in Aegir with php 5.3.1 update - Where to go for help

As nobody pointed me where to post the solution here is the fix in case someone else has run into this:

The first 8 errors were due to lack of TZ information in PHP, edit /etc/php.ini and add the timezone default. In my case it is:
date.timezone = 'America/Los_Angeles'

The 9th error was caused by a new restriction in PHP 5.3.1. You are no longer allowed to have spaces in command names and the Aegir install scripts use this. The fix is to temporarily accept spacey commands in a new drush preferences file:
cat >> ~/.drush/drushrc.php <<EOF
<?php
$options['allow-spaces-in-commands'] = 1;
EOF

"Constraints on Shared Hosting" To me, using that term implies that it can be used on shared hosting, but you are restricted/constrained and cannot perform certain actions.

"BTW, shared hosting is all the rage in big companies in Gartner-land"

Well Big companies are always a few years behind..

Who do they use the most Dreamhost, Bluehost, Godaddy? I just don't believe that any good company would be using commercial shared hosting, they may however be running their own company servers and creating a shared hosting platform for the individual dept.

which means some techie at the company will have root access to it..
which means some techie can install individual copies of aegir for each dept, if they wanted to.

You need to give aegir permissions that are in no way possible to make play nicely with other people on the server.

if you are in a situation where you have enough permissions to install aegir on a shared host, you need to change hosts because the server is being severely mismanaged, and all your data can be accessed by all the users on it.

This includes being given super user mysql access, in such a way that it can destroy databases of other users using the db server, and being able to manipulate apache virtual host configuration, including and up to overriding the configuration of other users on the shared server.

If you are really in gartner-land, getting a server or at least a virtual machine on a server provisioned should be the least of your problems.

I see this "shared hosting" topic is causing more distress than warranted here. Maybe it's best to leave these investigations under the hood for the time being, and note our experiences in other forums to avoid panic.

Still, there are (and will be) small changes needed to the release to get this to work cleanly. For example, to avoid the potential disruption of other databases on the same virtual machine, parallel database instances can easily be set up so Aegir has all the isolated root access it needs and no one's the wiser. This solves the concern above, and might be needed in corporate environments as department-specific VM's may well run other stuff needing undisturbed database access. But for this to work, the database configuration of Aegir (mostly embedded deep in drush include code, it seems) needs parameterized db connection values such as port number. (http://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html)

Now, there are other reasons to support this - as evidenced in the forum group. Is it feasible we can make fix requests that are useful in general, without triggering denials or hostilities if it becomes apparent that such updates are also useful for shared hosting or perhaps originally driven by this desire?

I think of these requests towards shared hosting not as new features, but rather, non-functional requirements (http://en.wikipedia.org/wiki/Non-functional_requirements) for deployment which don't need big changes. In other words, NFRs are not what you do, but how well you do it - ie, Gartner's ability-to-execute criteria.