Re: Search machine is ready

>>> None of the other entities providing the project with hosting have
>>> gone out of their way to deny us the ability to control the
>> services
>>> we provide,
>> I am not going out of my way. I am not sure why you have such
>> a problem with this.
>>
>> 1. This is the way that Command Prompt, Inc. does hosting for
>> all people that it hosts. Nobody gets root access.
>
> Really? For "server hosting" as well, or do you just do "web hosting"?

Yes Really. Even for dedicated machines (which is majority of our
hosting). Nobody gets root access.

> AFAIK, you need root to restart apache, just as an example. (So it can
> bind to port 80). Say after a recompile because you needed to tweak a
> module. Sure, you can set up sudo for each individual command, but that
> means you have to know everything ahead of time.

Well I would hope that you would know everything ahead of time. Of
course nobody is perfect but if we actually document this machine we
shouldn't have any problems. We could even (and I am happy to do this)
set up a Trac for the machine so we know what the heck is going on with it.

Actually a Trac for all of pgsql-www might be a pretty good idea.

>>> it works is in any way a good thing.
>> What level 1 support tech would this be? I don't have any
>> level 1 support techs. Remember, we are not a hosting company.
>
> Whatever people you'd page in the middle of the night if things go down
> :-) Or is that you all the time?

It isn't always me, but it is never a tier 1 and if we do what
we are supposed to do :) this will be documented and wouldn't be an issue.

>> I am not trying to be difficult here but all I see is, "Well
>> we like to do things as root and since this is only a
>> community machine you should let us."
>
> That's not really so. Maybe there weren't enough details in the original
> mail. We do beleive there is a *reason* for it. See above for one
> example.

Well I again refer back to using sudo.

>> I on the other hand am trying to bring a certain level of
>> stability and quality to the infrastructure. That requires a
>> level of discipline which means we use things like sudo, acls
>> and group rights. We don't use root.
>
> I do beleive we'd be fine without root as long as we could do all the
> things required - it's not root in the absolute that's needed. This does
> include recompiling and restarting "line of business" apps like apache.
> (But not necessariliy things like changing system libs or kernel - I'm
> fine with some on-site tech dealing with that)

Well I would question the need to recompile apache (that is what apxs is
for) but I get your point.

If it really comes do to you "needing" to recompile apache then we can
do what we do for the buildfarm which is proxy to a private apache
instance that is completely controlled via userspace.

>> You will need to configure apache... I will make sure you can
>> do so via included confs.
>
> See above - config not enough, recompile/replace needed. For
> flexibility. (Needed is always a relative matter of course, but it would
> certainly make things a hell of a lot easier)

A lot of this argument seems to come down to making sure things are
available in general. I am one of the most available guys when it comes
to the community. I am not hard to find ;). If you need something that
isn't there, we can make sure it happens.

> Well as said above, we can set everything up with sudo.  But that cuts
> down flexibility quite a bit, since every time you need to do something
> "outside the box", you're stuck.

Not stuck, just need to plan :). Again, if we need something outside the
box we can make sure that happens.

> But in general, if you're scared of the people maintaining the other
> community servers, then perhaps there is a bigger problem...

It isn't an issue of being scared. It is an issue of liability,
security, and insuring a quality of service. The root user is a foot
gun. I would prefer you all keep your toes :)

> For core-os, absolutely. For LOB, we've learned from the stuff we have
> on the other machines that building them from source is more or less
> required. Using the pre-packaged ones isn't flexible enough when it
> comes to which modules are loaded and not.

Well we are getting a little semantic here, and I would actually love to
have this discussion on a different thread because my experience is
different. (there are exceptions of course)

> And assuming you test things properly (say on a different port) before
> you do it, you can do most upgrades with sub-second downtime, so they
> can be done without scheduling a particular service window. Some things
> take longer, and need to be scheduled.

It should still be scheduled so people know it is happening "just in
case" :)

Joshua D. Drake


>
>
> //Magnus


--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/