RE: [Zope-dev] Opinions wanted: clean installation (was distribut ion)
and results in too little of an integrity gain to make it the default.
That statement gave me something to think about. Indeed, as I had described it there is little to be gained. In practice, I share administrative users between instances. The security gain is that different instances can use the same product source code, without the risk of a compomise spreading between instances.
Indeed, I dont think that works in your proposal. Zope need to write inituser while it is running, if that file is ever to be of use. I also think its unlikely we would want to lock the 'access' file so tightly.
Yes, I'd forgotten about that. inituser is just deleted after it's merged into the ZODB, right? Then it should probably go somewhere in the VARDIR/zope/INSTANCE hierarchy.
It sounds like almost everything is going into VARDIR now, except the source which is elsewhere. If the data.fs is stored in a directory VARDIR/zope/INSTANCE/var then the whole setup looks very much like the traditional INSTANCE_HOME system ;-)
I am thinking of making a wiki re all this... good idea?
mmmmm.
Toby Dickenson wrote:
and results in too little of an integrity gain to make it the default.
That statement gave me something to think about. Indeed, as I had described it there is little to be gained.
In practice, I share administrative users between instances. The security gain is that different instances can use the same product source code, without the risk of a compomise spreading between instances.
[snip]
It sounds like almost everything is going into VARDIR now, except the source which is elsewhere. If the data.fs is stored in a directory VARDIR/zope/INSTANCE/var then the whole setup looks very much like the traditional INSTANCE_HOME system ;-)
Perhaps this is when we have the system administrator install into LIBDIR/zope/site-products (or something similar to whatever it is that Python does, I forget right now). The instance admin could symlink out of this, I guess. To make it easier, though: - ETCDIR/zope/INSTANCE/products could contain a list of products *not* to use. This would simplify installation. I am not sure if this is even possible though. - Symlinks could be added either at startup or by the product install script. Hmm, I smell another utility, BINDIR/zopeprod; this could decipher current Products and install them properly (think zopeprod install Blah.tgz)
I am thinking of making a wiki re all this... good idea?
mmmmm.
Might have to now anyway to get the product installation folks involved. Allright, I've got other work to do today, so I'm going to pick up this thread again tomorrow :-) -- Matt Behrens <matt.behrens@kohler.com> System Analyst, Baker Furniture
Hello! Got in a little late in the discussion. Here is our current setup, for running multiple zopes with multiple instances. It is designed to be self contained with everything needed in one place, and also to be all managed by the user "zope". Can you see any disadvantages with this setup? in /usr/local/zope we have: SharedProducts/ bin/ dist/ doc/ etc/ home/ misc/ sw/ SharedProducts/ contains all the products that are shared between instances (they are symlinked into each instance directory) bin/ contains all scripts needed to create a new instance, to start and stop zope, etc. for instance: instance_make python -> /usr/local/zope/sw/Python2.1.1/bin/python python2.1 -> /usr/local/zope/sw/Python2.1.1/bin/python2.1 zope_start zope_stop zstart dist/ contains the distributions of Zope in use. For instance: drwxr-xr-x 11 zope zope 512 Aug 31 11:39 Zope-2.4.0 drwxr-xr-x 11 zope zope 512 Oct 31 21:06 Zope-2.4.1 drwxrwxr-x 11 zope zope 512 Oct 31 15:27 Zope-2.4.2 by convention they are named Zope-<version-number>. We use this in our scripts. Also every Zope-dist directory has a settings file specifying what python it wants to be run with. Also used in our scripts. doc/ whatever docs we need, such as "How to compile Python" etc etc/ contains sitewide settings, such as a list of instances in use, and general configutation files: env.conf instances oracle.config.in sys.conf z2.conf the *.conf files are used to set values for all the settings possible according to the info in z2.py, sets a lot of env.varaibles and directory locations, etc.. home/ contains one directory for each instance we use. The instances directory structure is as follows: Extensions/ --> whatever extensions to use Products/ --> Products in use - symlink from SharedProducts access --> emergency user password file import/ --> import dir inst.config --> a sourceable sh.script sourced by the start script contains instance specifik settings (use FTP, WebDAV, etc) log/ --> _all_ log files end up here var/ --> the datafiles are stored here that's everything needed to handle an instance. misc/ contains stuff we need to manage our installation. ie. we have our download directries here, and general crap-area sw/ contains our python installation(s), our apache installations, etc...
Dario Lopez-Kästen wrote:
Got in a little late in the discussion. Here is our current setup, for running multiple zopes with multiple instances. It is designed to be self contained with everything needed in one place, and also to be all managed by the user "zope". Can you see any disadvantages with this setup?
Yeah, I think the biggest problem with this setup is that it is all under one tree, which is what my proposal is trying to move away from in the first place. In the (admittedly shorter than some) time I've spent working on FreeBSD and OpenBSD ports, I have yet to run into a package that's important enough to give it its own directory, although several think they are. We took PostgreSQL, for example, right out of it's little /usr/local/pgsql hierarchy in the interest of not polluting /usr/local and PATHs. I know the JDKs that we have are currently in /usr/local/jdkX.Y.Z, but that's (unfortunately) because lots of Java software expects it to be in some similar arrangement to that. Also, having the software core owned by the instance user isn't a really big issue in terms of a security risk, but it is so easy to correct that it's not really desirable. -- Matt Behrens <matt.behrens@kohler.com> System Analyst, Baker Furniture
Matt Behrens wrote:
Yeah, I think the biggest problem with this setup is that it is all under one tree, which is what my proposal is trying to move away from in the first place.
Actually this is intentional. We host a lot of applications in our systems, and I have taken the advices of my syadmins in keeping important applications selfcontained. These apps are not alway developed by ourselves, we just host them for other parts of the university. We want them to be selfcontained, with everything they need to use at the versions thaty they were certfied against. If I need to uppgrade the python or apache for one app I can safely do so w/o worrying what impact it might have on other apps or having to backtrack possible dependencies. If I need to move my entire app to antoher machine, I can safely do so knowing that everything I need will be present in my tarball (or zip-arch). It is not about importance of package, it is about insulation, selfcontainment and ease of deployment efter development. Disk is cheap - time isn't.
Also, having the software core owned by the instance user isn't a really big issue in terms of a security risk, but it is so easy to correct that it's not really desirable.
We don't let users into our systems, and those who go in go by SSH :-) Anyway the zope ownership is just a convenience... Cheers, /dario
Dario Lopez-Kästen wrote:
If I need to uppgrade the python or apache for one app I can safely do so w/o worrying what impact it might have on other apps or having to backtrack possible dependencies.
If I need to move my entire app to antoher machine, I can safely do so knowing that everything I need will be present in my tarball (or zip-arch).
It is not about importance of package, it is about insulation, selfcontainment and ease of deployment efter development. Disk is cheap - time isn't.
Sure, and that solution works for you, so feel free to keep using it. I don't intend this proposal (which it looks like I'll be making by the end of the week) to make you stop using Zope like that. However, we do have a problem in that there is no 'standard' installation that can reasonably be made to have Zope act like any other piece of software, and as a result OS packagers are all doing it different ways and duplicating some effort. The idea is to add hooks to Zope to make it much more flexible about your installation as well as provide a much more sane default installation that can be easily tracked by existing package tools. The more flexible we can make this default installation, the better. Hence the pre-proposal discussion :-) -- Matt Behrens <matt.behrens@kohler.com> System Analyst, Baker Furniture
participants (3)
-
Dario Lopez-Kästen -
Matt Behrens -
Toby Dickenson