On 2011-04-18 16:36:28 -0700, Daniel Holth said:
On Apr 18, 2011, at 6:09 PM, Alice Bevan–McGregor wrote:
I've already defined that. RTFM or many ML messages about logging.
Please remain friendly and patient.
That depends on how you define the F in RTFM. In this instance, I
meant "read the fine manual". ;)
You can understand my frustration, however, that > 10% of the posts in
this thread demonstrate a lack of understanding of (or lack of even a
cursory glance at) a) my initial post and associated document, and b)
the rest of the mailing list posts.
Asking for things already agreed upon or questions already resolved
wastes everyone's time.
On 2011-04-18 16:46:12 -0700, Eric Larson said:
Instead of assuming "/etc" always means "the root of the filesystem" we
should consider it the "root of the sandbox" where the system providing
the "sandbox" defines what that is.
While /etc certainly wouldn't be the root of anything (insert sarcastic
smiley here ;), it was already agreed upon that / would refer to the
application container root, not system root. I share Ian's sentiment,
see: (search for 'root' on that page)
http://mail.python.org/pipermail/web-sig/2011-April/005041.html
It is _a_ filesystem in that there is a place that an application will
be run. For argument's sake, we'll say it is a directory on some
server. Now, within that directory we choose to take some known bits
from the LFS standard such as /etc, /bin, /var, etc for the placement
of our application.
Again, not such a great idea.
With that in mind, I think using things like LFS makes a ton of sense.
We can piggy back or copy (since previous discussions for .debs or rpms
seem not to sit well... even though they would fit this model very
well...) systems like RPM rather directly and hopefully allow our
Python web apps to play very nicely with applications in other
languages.
I can't fully grok this paragraph. FHS (my bad calling it LFS
earlier!) = good because we won't confuse systems administrators and it
matches other binary packaging models?
I doubt an isolated web application will have a need for more than 6%
(3) of these:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure
While I personally have a FHS-like application deployment model using
Git, I would rather not see that level of complexity as a requirement
for deploying basic applications.
Please do not get hung up on the fact that I've said RPMs here. The
fact is distros have been doing package management for quite a long
while. It is insanely convenient to say apt-get install couchdb and
when it is done, having a couchdb server running.
It may be convienent, but it's also quite the risk. You're letting
someone else configure your server. Also, do binary installation
systems automatically start the service post-installation before you
can configure them? I have difficulty believing that, which means a
whole whack-ton of effort under a systems administrator hat has been
glossed over.
Copying the model seems like a good option in that we get to learn from
the mistakes of others while inheriting a wild variety of tools and
concepts.
The on-disk structure which the application lives within (the
"application container") is up to the application server in use. The
underlying application should, and, IMHO, -must- be agnostic to it.
Passing paths to configuration files, TMPDIR, etc. in the environment
is a fairly trivial way to do that, at which point the FHS discussion
is nearly moot.
If you want a complete (complete enough for a simple web application)
FHS structure within the redistributable, I don't see the point of
having that many empty directories. ;)
As an aside, I -do- have an application in production using a FHS-like
file structure:
https://gist.github.com/926617
But again, I'm not suggesting something like that for the
redistributable application!
— Alice.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
