FWIW, ZCVSMixin now at 0.1.1... and rising. ;-)
Hi Folks, I don't know if anyone out there is actually trying to *use* my ZCVSMixin/ZCVS Folder stuff, but if you are you certainly want to get the latest release, ZCVSMixin-0.1.1.tgz from the zope.org site: http://www.zope.org/Members/sspickle/ZCVSMixin I put some screenshots up there so you can see what it looks like at: http://www.zope.org/Members/sspickle I've also found it useful for managing Python products and other software through the web! I have had a couple of minor 'breakthrough's that *seem* cool, but I might just be fooling myself. If an object is not folderish I guess that it's 'simple' so I export it as XML with the following code: def doExport( conn, oid, file=None): counter=0 if file is None: file=TemporaryFile() elif type(file) is StringType: file=open(file,'w+b') write=file.write write('<?xml version="1.0"?>\012<ZopeData>\012') version='' ref=referencesf oids=[oid] done_oids={} done=done_oids.has_key load=conn._storage.load while oids: oid=oids[0] del oids[0] if done(oid): continue done_oids[oid]=1 try: p, serial = load(oid, version) except: pass # Ick, a broken reference else: ref(p, oids) write(conn.XMLrecord(buildOID(counter),len(p),p)) counter = counter + 1 write('</ZopeData>\n') return file def buildOID( value ): return '\000\000\000\000' + struct.pack('!l', value) This way the XML always starts with '0' as a base oid. I experimented a little and the xmlimport stuff doesn't seem to use the 'oid' unless an object is 'complex' (i.e., self references etc... ). Anyway this has the happy effect of making the xml for a simple object the same every time it is exported so diff's make sense etc... If objects are 'folderish' or 'complex' (and the user is permitted to dictate this when objects are added to CVS), they are exported as 'zexp' files and cvs adds them as 'binary'. I was having trouble with certain kinds of object's xml representation. I decided that this was really an xml implementation problem, since I couldn't reliably export these as xml through the normal Zope export mechanism either. Anyway.. let me know what you think if you are using this stuff! Finally I'm aware that there are also security issues with the way this works now. I need to look at all the things a user might need to do and eliminate some of the 'type in' arguments that are in the product now. These arguments wind up on 'os.system' calls, and could be abused by a ill-meaning user (with access to the CVS Admin page!) Any thoughts there? thanks, -steve
Steve Spicklemire wrote:
I don't know if anyone out there is actually trying to *use* my ZCVSMixin/ZCVS Folder stuff, but if you are you certainly want to get the latest release, ZCVSMixin-0.1.1.tgz from the zope.org site:
Hi, Steve. This work looks very interesting. I decided to try it out and noticed it was not possible to manage a product folder with ZCVSMixin, so I started hacking up your product. (Images that resemble a horror movie come to mind.) :-) I've attached my changes in a private e-mail so as to not flood the list. Basically I made it possible to override the behavior of ZCVSMixin so that it can manage a folder other than itself. Then I created a new class derived from ZCVSMixin which is a "CVS" Folder. That way, it's possible to manage any objects in the ZODB, regardless of whether CVS had been considered in the structure.
I put some screenshots up there so you can see what it looks like at:
It looks good, but the interface could be a lot cleaner. I envision a table with three distinct column groups: the ZODB version, the FS version, and the repository (with details). When the ZODB and FS are in sync, a small black equal sign will appear between them (preferrably a graphic to make it more visible.) When the FS and repository are in sync, there will be a small equal sign between them also. When something is not in sync, a green arrow pointing in the direction the file needs to go will replace the equal sign. The buttons below would be placed in such a way to make their function obvious. In fact, the submit buttons could be images containing the arrow icon. Thus the interface would be simple and obvious.
I've also found it useful for managing Python products and other software through the web! I have had a couple of minor 'breakthrough's that *seem* cool, but I might just be fooling myself. If an object is not folderish I guess that it's 'simple' so I export it as XML with the following code:
(snip)
This looks good, Steve.
If objects are 'folderish' or 'complex' (and the user is permitted to dictate this when objects are added to CVS), they are exported as 'zexp' files and cvs adds them as 'binary'. I was having trouble with certain kinds of object's xml representation. I decided that this was really an xml implementation problem, since I couldn't reliably export these as xml through the normal Zope export mechanism either. Anyway.. let me know what you think if you are using this stuff!
I think we need to look into performing complete CVS checkouts which create entire folder hierarchies.
Finally I'm aware that there are also security issues with the way this works now. I need to look at all the things a user might need to do and eliminate some of the 'type in' arguments that are in the product now. These arguments wind up on 'os.system' calls, and could be abused by a ill-meaning user (with access to the CVS Admin page!) Any thoughts there?
Imagine this possibility: Zope would start what I'll tentatively call an "execution proxy" server at startup. When a user want to access CVS through Zope, they would be required to start a background "execution client" which makes a connection to Zope's execution proxy server. When the user accesses a CVS function in Zope, Zope would look at the list of connected execution clients and ask the appropriate execution client to access the file system and execute cvs commands based on that user's system privileges. Advantages: - Unless a given user is running the execution client, the possibility of intruders gaining access to that user's files is not increased. - Nothing has to run with root privileges. - The execution proxy could run on a privileged port, making it impossible for intruders to trick users into using a counterfeit execution proxy (unless, of course, the intruder already has root privileges.) - No need for administrators to fiddle with filesystem permissions. Disadvantages: - If Zope is compromised while execution clients are connected, the intruder may be able to execute commands through the execution clients. To reduce the impact, we can reduce the commands allowed to be executed. Note, however, that this problem is very likely inherent in CVS access through the web. Even the current implementation suffers from this problem. - Users will have to manually start their execution clients, which will stop automatically when they log out. This is actually designed to be an advantage in terms of security. On the other hand, it would be possible to write an execution client that runs as root and automatically spawns child clients for each user. That could be dangerous, though. It should be relatively easy to write all this IMHO. Shane
Hi Shane, This is great.. it does what I wanted to do, but by making a 'fixed name' folder, (a la, 'acl_users'), to do the trick. It also works a lot more like a 'real' CVS folder. Cool. And.. icing on the cake... you can put it in any kinda container! Double Cool!
"Shane" == Shane Hathaway <shane@digicool.com> writes:
Shane> It looks good, but the interface could be a lot cleaner. I Shane> envision a table with three distinct column groups: the Shane> ZODB version, the FS version, and the repository (with Shane> details). Yes.. that sounds good. In my dreams we'd do away with the FS part altogether.. but I think that's another project in itself! Shane> When the ZODB and FS are in sync, a small black equal sign Shane> will appear between them (preferrably a graphic to make it Shane> more visible.) When the FS and repository are in sync, Shane> there will be a small equal sign between them also. When Shane> something is not in sync, a green arrow pointing in the Shane> direction the file needs to go will replace the equal sign. Yes... unfortunately it's possibly, easy really, to get them out of sync in both direction... some kinda scary "AHHH!!!" graphic needed for that case mayhaps.. Shane> The buttons below would be placed in such a way to make Shane> their function obvious. In fact, the submit buttons could Shane> be images containing the arrow icon. Thus the interface Shane> would be simple and obvious. Cool.. yes I like that. >> I've also found it useful for managing Python products and >> other software through the web! I have had a couple of minor >> 'breakthrough's that *seem* cool, but I might just be fooling >> myself. If an object is not folderish I guess that it's >> 'simple' so I export it as XML with the following code: >> >> (snip) Shane> This looks good, Steve. >> If objects are 'folderish' or 'complex' (and the user is >> permitted to dictate this when objects are added to CVS), they >> are exported as 'zexp' files and cvs adds them as 'binary'. I >> was having trouble with certain kinds of object's xml >> representation. I decided that this was really an xml >> implementation problem, since I couldn't reliably export these >> as xml through the normal Zope export mechanism >> either. Anyway.. let me know what you think if you are using >> this stuff! Shane> I think we need to look into performing complete CVS Shane> checkouts which create entire folder hierarchies. Yes... with the new 'CVS' folder concept we could try the following heuristic... If you run into a 'folderish' object during checkin, or checkout, see if it contains an object named 'CVS', if so.. recursively call the same method on that object, if not, treat it as a 'chunk' object in its own right.... ..... ??? Would that work? >> Finally I'm aware that there are also security issues with the >> way this works now. I need to look at all the things a user >> might need to do and eliminate some of the 'type in' arguments >> that are in the product now. These arguments wind up on >> 'os.system' calls, and could be abused by a ill-meaning user >> (with access to the CVS Admin page!) Any thoughts there? Shane> Imagine this possibility: Zope would start what I'll Shane> tentatively call an "execution proxy" server at startup. Shane> When a user want to access CVS through Zope, they would be Shane> required to start a background "execution client" which Shane> makes a connection to Zope's execution proxy server. When Shane> the user accesses a CVS function in Zope, Zope would look Shane> at the list of connected execution clients and ask the Shane> appropriate execution client to access the file system and Shane> execute cvs commands based on that user's system Shane> privileges. Shane> Advantages: Shane> - Unless a given user is running the execution client, the Shane> possibility of intruders gaining access to that user's Shane> files is not increased. Shane> - Nothing has to run with root privileges. Shane> - The execution proxy could run on a privileged port, Shane> making it impossible for intruders to trick users into Shane> using a counterfeit execution proxy (unless, of course, the Shane> intruder already has root privileges.) Shane> - No need for administrators to fiddle with filesystem Shane> permissions. Shane> Disadvantages: Shane> - If Zope is compromised while execution clients are Shane> connected, the intruder may be able to execute commands Shane> through the execution clients. To reduce the impact, we Shane> can reduce the commands allowed to be executed. Note, Shane> however, that this problem is very likely inherent in CVS Shane> access through the web. Even the current implementation Shane> suffers from this problem. Shane> - Users will have to manually start their execution Shane> clients, which will stop automatically when they log out. Shane> This is actually designed to be an advantage in terms of Shane> security. On the other hand, it would be possible to write Shane> an execution client that runs as root and automatically Shane> spawns child clients for each user. That could be Shane> dangerous, though. Shane> It should be relatively easy to write all this IMHO. Hmmm ... I think it might stretch my time/energy barriers! ;-) But I'd love to *help* write it. Shane> Shane So.. I'd like to add you as a 'commit'er to my local CVS... are you intersted? thanks! -steve
Steve and Shane, We've been positively *dying* to have cvs or cvs-like functionality. It's one of those things where we left the unix-everything-is-a-file-idiom and went, "Oh, um, heh, now what?" =) We have been making do with Version objects instead, which are far more rcs-like (exclusive locking, no merging) and not really good when we want to give 2 different people 2 different medium-to-long term projects for adding things to the site. Imagine, one adds something to / and / gets version-locked now, so the other person can't even add things to / anymore. Anyways, enough of that. Point being, we want our site coders to be able to do a sandbox (much like Version essentially provides, if possible, ie transparent rather than explicitly located somewhere else) where they can develop stuff and the ability to only check certain things in, and the ability to do merges, etc. If we couldn't do the development transparently on the production server, and we had to have developers running zope on their workstations and pull from the cvs repository there, that'd be alright too though I guess. How much of this is provided for now or planned on being provided for by this product? And, what can we do to help? I don't know that we have any bodies we can sick on this, but I'd love to get together with you guys and get some of the things that need to be done up on Cosource so that organizations interested in having this can throw money at it, and so that people (you guys included) who might have trouble finding the time to work on it can have a little incentive. =) jim -- Jim Hebert http://www.cosource.com/ jim@cosource.com The cooperative market for open source software "Well actually I was considering opening a market in flying pigs. Mostly because it would be more practical...." -- Alan Cox
Hi Jim, et. al...
Steve and Shane,
We've been positively *dying* to have cvs or cvs-like functionality. It's one of those things where we left the unix-everything-is-a-file-idiom and went, "Oh, um, heh, now what?" =)
Well.. I don't know much about cosource.... but I did just put the latest version on zope.org, with Shane's patches, and incorporating some of his UI suggestions. (as much as I could get done in a few hours...) I'm kinda strapped for time right now.. since I'm working on active, deadline oriented projects and all.. of course all contributions welcome! This latest for example just saved me lots of time, since I was about to do the same thing Shane did in a much less elegant way... Thanks again Shane! For what it's worth, we needed this so badly in my project that I was pretty much forced to implement it, anyway I could! We are using now... and it's working pretty well for us. You have to 'understand' too much about what's going on for my taste.... but it's getting better. -steve
participants (3)
-
Jim Hebert -
Shane Hathaway -
Steve Spicklemire