FrontPage ProductInstallationSystem ProductInstallationSystemFeedback / backlinks

Brian 2000/07/25

Why embark on a total reinvention here? If we are going to do something, I would far prefer to see if distutils could be leveraged here. In fact, I would be more inclined to modify things about the current Zope distribution / deployment situation to work with an existing tool than to invent a totally new one that works with the current situation. Plus - someone else gets to maintain it, support it, write the documentation... :^)

ShaneH 7/25

Again, this proposal deals only with the selection of a strategy for installing Zope add-on modules. It looks like distutils addresses solution #2, however it does not address the following goals:

• Semi-automated download and dependency resolution.

• Alerting users when a new version is available.

• Uninstallation.

There is an increasing number of products, dependencies, and sources. The major goal of this proposal is to make it possible to distribute changes in products to a customer without making the customer go through a lot of steps. The distutils package simply does not help with the situation we have with two customers.

ChrisW 26/7

I think it is very necessary to solve this problem. I think Option 3 would be best. If you have a seperate environment for managing products and the like (has anyone though about "templates" and "skins"?) then the security issue goes away. That said, I don't know what the difference in security is between SSL access to a shell or an HTTP port and why this can't be done "through the web"...

The dependency checking is a great idea. This's make it a lot easier to package functionality up in smaller products and yet not have the user go through loads of installation pain. I like the idea of product suppliers for this and a search order for them. Bit like DNS lookups? (I haven't got that, but I know someone who has)

I don't like the Alerting thing as it implies polling. How about a button in the Control Panel saying Check for new product versions with an option to install?

Simple and easy uninstall in the same system would also be pretty cool :-)

PS I think these discussions would be better on a mailing list. How about zope-dev?

ShaneH 28/7

Perhaps the real problem with ultra-simple installation through the web isn't the security issue, but the fact that the Zope process usually runs with privileges that don't allow it to write to its own product directories. That, IMHO, should not be changed; it's a feature. On the other hand, it might be feasible to create another Zope process that runs in privileged mode on another port. But that solution sounds like a honeypot, don't you think?

I didn't mean to imply polling. The user would visit the product list page and see what needs to be updated. It would be quite similar to the xemacs.

IMHO these discussions are much better in wiki form. Just visit http://dev.zope.org/Wikis/DevSite/Proposals/RecentChanges frequently or use Mind-It. It works pretty well.

ChrisW 29/7

I'd think we should agree to disagree about the Wiki ;-)

Dunno anything about xemacs :S

What's a honeypot in the context having Zope runs in privileged mode on another port? I know a lot of people who'd love that, for things like ZMI as well :-)

Oh yeah, I'll throw this in here on the of chance... it'd be really nice to be able to install and uninstall products (and anything else ;-) without having to restart Zope...

JoeW 30/7

There are a couple of existing "workarounds" to make Zope product installation over the web possible:

• For ZClass-based products (*.zexp files) it is really easy: You only need to install LocalFS^x to make your "import" folder accessible over the web. The process of uploading and then installing could be automated with a simple DTML script or minor changes to the "import/export" tab (choose file to be uploaded and installed and click on "install"). However, this only works with uploading stuff from another machine over the browser, not from a URL, so you can't just select a product from a list and get it installed, but have to download it first (e.g. from zope.org) to upload it.

• For tar.gz-archives there is a thing called "ZInstaller" that needs some improvement but does the job - for Unix only, as it needs tar installed to work (http://www.zope.org/Members/slef/ZInstaller/).

For the later you need to give the user Zope is running as write access to the Products directory and an upload directory ("/tmp"), for the ZClass/LocalFS^x solution the same applies for the "import" directory. Both is rather insecure. But I'll comment on that later ...

ZInstaller^x won't work without modification if Zope is running behind a proxy/firewall, as it downloads the archives directly from a web address. (Workaround: copy it to a folder on the server machine using LocalFS^x and then use its (local) URL to install it).

As an (upcoming) hosting provider, I'm looking for a purely web-based way of installing product archives and *.zexp-files. This should be controllable however, e.g. by opening the install procedure only to preselected products in a local directory on the provider's network.

I'd like to get some feedback on the security issues. As most important data on a Zope web server is likely to be stored in the ZODB (or an SQL database that has to be accessible from Zope) anyway, I personally think that opening up some system directories for write access doesn't make too much of a difference. If the Zope web interface was (or is) insecure then it could be quite easily hacked without having to get into the Products folder or installing ZClasses^x first. After all, Zope has got a web-accessible "Stop" button ...

I think if the design of Zope (2.2) is inherently secure, making sure that only superuser can install and that he uses an SSL-encrypted connection should be fine. BTW: With ZEO it should be easy to set up a privileged "management" Zope on a second port.

I like the idea of dependency checking ... New product notification is a good idea, too. But again I'd like to be able to restrict the user's choice to "approved" products.

ShaneH 7 Aug --

See http://slashdot.org/comments.pl?sid=00/08/07/0225240&cid;=41. "stevenj" points out that the reason one packaging system might be better than another is because of the central organization that maintains the packages. We have that kind of organization for Zope, therefore an attempt to create a product installation system for Zope may have a good chance of success.

ChuiTey^x 20 Mar --

Every package should be uninstallable from the Control Panel. This would involve deleting the code off the filesystem and then removing itself from the ZODB.

Dependency is a nice to have feature, but initially, it would be better if the original tarball contained all the dependent packages as subpackages.

If dependent products are not packaged as subpackages, version rules should apply to avoid overwriting new versions with older file versions.

If Zope could host two identical products of the different versions a la .so files on Linux, we might just be able to avoid clashes altogether.