[Catalyst] Cached TT w/mod_perl issue? Or just a Toby-bug?

[Toby Corkindale]

On Wed, Sep 28, 2005 at 12:30:59PM -0500, Wade.Stuart at fallon.com wrote:
> > >       You kinda sound like you want to have your cake and to eat it too
> > > all while having someone else pay for dinner.  There is no magic bullet
> > > that makes all the problems go away here.
> >
> > Uh, no. I'm seeing if someone else knows an elegant, thoughtful fix to
> > this issue, before I go off and re-invent the wheel. I'm not looking for a
> > magic bullet - I'm looking for discussion of the issue - Although that
> > appears to be something you don't seem to want to add to sensibly.
> 
> My point is you have made choices about your environment that is forcing
> you into a more difficult corner.

Perhaps you would care to re-read your original statement, above, then, as it
doesn't read anything like that, and comes across quite aggressively.

> > > All of these solutions require thought, have weaknesses, are inflexible
> > > in some way or another -- you are in this position by previous choices
> > > you have made (starting apache as root and changing ID).   Sometimes it
> > > does seem silly to ask for directions after you decide to drive half way
> > > across the country,  you may not like that the answers all involve
> > > driving backwards 15 hours.
> >
> > I see from your comments near the end of your email that you think that my
> > choice to use mod_perl, and to run apache as root (and let it changeuid)
> > is a great mistake. Since those methodologies are quite common on
> > high-traffic dynamic public facing websites, I am genuinely interested to
> > hear your reasons for suggesting that they are a poor choice of platform.
> > Please, do go on.
> 
> No,  I am saying that you have chosen to do so -- you deal with the
> results.  I don't run apache as root.  I setup production servers to do so
> all the time.  There are many ways to do this, reverse (caching) proxies,
> port translation on firewalls, etc..
> https://itso.iu.edu/You_Don't_Need_Root_for_That has a simple ipchains port
> forward solution.  I suppose if you want to run
> apache/mod_perl/mysql/gogo-gadget out of the box on linux distros and can't
> be bothered to secure the systems, you can continue they way you are.

So, you aren't willing to answer the question asked - ie. What is actually
/wrong/ with running apache (as root) and mod_perl, that makes it such a poor
platform in your opinion.

Out of interest, do you work in a development team, or purely as a lone wolf?
I ask, because you seem out of touch with the realities of software
development. In particular, that a completed system is a result of decisions
and work by software developers, system administrators, team managers, client
managers, and customers.

Our sysadmins are not going to change their operating practices on the basis
of someone flaming a developer on a mailing list.
I trust our sysadmins to be able to secure the systems properly, and they
trust the developers to write secure software. There are certain mandates to
the developers to produce software that behaves in certain ways - one of which
is to avoid installation and maintenance complexity.

Automatically creating a temporary directory is a common procedure, as it
using a distro-provided Apache. We all have better things to do with our time
than recreate the wheel, and requiring our admins to setup custom apaches,
manually create directories with setgid permissions, modify firewall rules,
and so on. It's all unneccessary complexity. We are quite capable of *doing*
it, so please do not patronise me by assuming that neither I nor they have any
idea about such things. We just don't believe that it is the correct solution
for the problem at hand.

Also, can I refer you to my email m-ID: <20050927134454.GB16972 at penfold.mine.nu>
in which I mentioned that it was possible we'd run the cache in a memory-based
FS? I also mentioned some of the difficulties to do with differing Apache
user/group names to place into an automated script, and why that solution
wasn't ideal for us as it required extra configuration. We *have* put some
thought into all this, despite your continual assumption that I have not.

I asked the original question because I was not sure if I was merely missing a
switch somewhere, or in case there was a simple solution out there. I did not
expect to get into a highly unprofessional flamewar.


> > As per your other responses:
[snip]
> > > *  You can leave root -> userid apache and change your umask and make
> > > the dirs and files writable by all.
> >
> > Which really doesn't sound a particularly secure way to do things. So why
> > compromise with it?
> 
> I would not, I was listing it because it is one of the options.  As you
> seem to want "easy" options where "... considered using the setgid trick to
> retain permissions,
> but past experience of setgid is that it always ends up getting
> lostsomewhere, accidentally. (eg. Someone copies directories without
> realising they need to maintain it)" type of issues may be avoided.  Mind
> you, that you may also mount filesystems read only to protect from those
> pesky "rm -rf /" issues.

Thanks for patronising me further.

As for the above - we have a number of people working on systems, some more
technical than others. Windows bunnies in particular can become very confused
when they are using their GUI scp or svn clients to build directory trees that
then 'just don't work' because of permissions issues. I realise that is
(their) knowledge problem, and not applicable to this tempdir issue we're
discussing right now, but you can see how similar things can become a problem,
and why it is good practice to keep things simple where possible.

> > > *  You can create the directories before hand and set permission to work
> > > like you need them to.
> >
> > Harder than it sounds, as the TT create also mkdirs a bunch of
> > subdirectories, dependant upon the template tree structure. Doing it
> > automatically is a much better idea than training the sysadmins to do it
> > (and correctly) every time they install a system, or the config changes.
> 
> It is not,  the sticky group bit message that I sent out before gets set on
> all files and folders created inside that directory and forces the group to
> be the same.  You only have to create the top TT cache dir and set sticky
> bit on this.  But alas,  If you cant handle 4 command lines to do so (or
> making a script to change that to 1 command line if you do it umpteen times
> a day),  or if you think the people managing your servers and apps cant
> handle a 4 command line or 1 script exec prereq I have no idea how you
> expect them to setup apache/mod_perl/mysql not to mention the recursive
> dependances nightmare that is the Catalyst install.  Hell, if you want them
> created "on startup" modify your httpd startup script to do so.

We're all capable of running a few commands, and rest assured it would be
documented. However it is possible for people to miss a step here or there, or
for an admin to skip one during deployment. As a result, it is considered Good
Practice to keep systems simple - less things to do, equals less things that
can go wrong.

I'm not saying your solutions you suggested are wrong, but as I said before, I
would prefer a more elegant solution. Is there something wrong with my desire
to write decent software? You seem to imply that there is, and I should be
happy to accept one of the various kludges you have pointed out.
I appreciate the effort you are taking to point them out, but I do not
appreciate the continual implications that I am too stupid to realise or
implement them.

> You could also set COMPILE_EXT and not COMPILE_DIR and that would build the
> template cache in the same dir as the real templates avoiding the whole
> dynamic template dir all together -- but alas you would have to give up
> even more security having writable template dirs.

Exactly. Also, another bit of installation methodology is that the installed
files/directories do not self-modify.
An interesting take on this might be to copy the entire template tree to a
ram-based FS, point TT at it, and then use compile_ext; I'll have a think
about that in an optimisation stage, bounce the idea off the admins. Still
requires the ability to know the apache user/group in advance though.

> > > *  You can hold off on the TT create until apache has changed ID.
> >
> > Preferable, and the lesser of evils - I even asked for advice on how to go
> > about that in a previous email to this list, although you seem to have
> > ignored that. Since you seem to think yourself superior in your knowledge
> > of perl, apache and catalyst, perhaps you would like to volunteer
> > something useful yourself?
> 
> Sure,  dig into Catalyst core and setup a childinithandler for tt. and deal
> with all of the complexities that creates for you.  The problem is of your
> making, all of the fun cleaning it up should be yours as well.

Fair enough. Sometimes there are clean and easy ways to do things in Catalyst
that are not immediately obvious to the non-gurus among us.. and sometimes
there are not. Knowledge of whether or not these methods exist is the thing
that this mailing list can provide, but you seem to have won an award for the
most long-winded and annoying way of saying "Actually, no, it's really not
very simple at all."

Do you realise you could have said that several emails back and saved us all a
lot of time?

tjc

-- 
Turning and turning in the widening gyre/The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world
(gpg --keyserver www.co.uk.pgp.net --recv-key B1CCF88E)