Weekly Edition
Return to the Press page
| |||||||||||
Arch for CVS Users (Linux Journal)
The Linux Journal provides a whirlwind introduction to arch for people already familiar with version control. "Arch is, at its heart, a distributed system. There is no special server process, and each developer's machine can serve as an arch repository. The result is that advanced use of arch can require more work on the client side."
(Log in to post comments)
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 7:07 UTC (Wed) by dmh (guest, #14528) [Link] Apparantly there is another source-code control system, called Subversion. (Sorry. :o)
Subversion Posted Jun 2, 2004 13:46 UTC (Wed) by alogghe (guest, #6661) [Link] Yes Subversion is another version control system but it is not "Distributed", it's old style client server with all the problems that brings. Switch to Subversion if you just want incremental upgrades that fix SOME of cvs issues.
Subversion Posted Jun 3, 2004 0:21 UTC (Thu) by mkching (guest, #21009) [Link] I believe he's poking fun at the way Arch supporters hijack every Subversion thread with pro-Arch propaganda :(
Subversion Posted Jun 3, 2004 1:35 UTC (Thu) by dmh (guest, #14528) [Link] Well spotted. :o) Live and let live, I say.
Subversion Posted Jun 3, 2004 8:53 UTC (Thu) by alogghe (guest, #6661) [Link] Ahhh, well everyone should be using Monotone instead of Arch or Subversion anyway.www.venge.net/monotone ;)
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 9:47 UTC (Wed) by kornak (guest, #17589) [Link] Why can't CVS be upgraded instead? I've heard about so many new sourcemanagement projects lately it's made me dizzy.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 9:47 UTC (Wed) by kornak (guest, #17589) [Link] Actually, I long for the days of SCCS. I feel old.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 10:15 UTC (Wed) by dwheeler (subscriber, #1216) [Link] Actually, that's essentially what subversion is: a CVS upgrade path. Many of the CVS developers felt that CVS's code was too crufty to continue, and that it would be better to start over.You might want to look at my article, Comments on OSS/FS Software Configuration Management (SCM) Systems, to see more about GNU Arch, subversion, and other OSS/FS SCM tools.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 10:37 UTC (Wed) by proski (subscriber, #104) [Link] In fact, the CVS website https://www.cvshome.org/ recommends Subversion. That site was recently broken into. The attacker exploited a bug in CVS. Anonymous CVS access to CVS sources wasn't reopened after the site returned online.Switching from CVS to Subversion doesn't change the organization of the project. Both are server-centric. Arch is decentralized. Switching to Arch from CVS may require changes in the way how the developers interact, not just what tools they use.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 10:38 UTC (Wed) by drathos (guest, #6454) [Link] I'd be interested in using Subversion instead of CVS if it didn't have so many dependencies. The nice thing about CVS is that it doesn't require gobs of third party apps and libraries to work.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 11:00 UTC (Wed) by dmarti (subscriber, #11625) [Link] One cool thing about Arch is that it requires zero server-side setup -- you can use a directory on your existing server for Arch without installing any software there.(I went through the steps in Nick's article, and all I had to do on the server was one mkdir and one chmod)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 12:06 UTC (Wed) by robla (subscriber, #424) [Link] Seems like both a blessing and a curse. It makes it simple to set up, but what happens when you want fine-grained access control? That seems like an architectural limiation; either someone has write access to the repository, or they don't. You can't have high confidence in the change auditing mechanisms, since most of the interesting logging/auditing/etc would need to occur in the client. It also means that if there's a security vulnerability, ALL of your users with write access need to upgrade, or the central server itself is compromised.Rob
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 12:34 UTC (Wed) by moffixx (guest, #22010) [Link] Well, since there is no actual server process, your security is based on the security of your SSH server. This is no different from operation without arch repositories on the machine.There are ways to restrict users to SFTP only, if that's what you're worried about.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 18:58 UTC (Wed) by mbp (guest, #2737) [Link] The most common type of fine-grained access control that you want in SCM is that particular users should be able to commit to particular branches, but not to others. You can easily do this in Arch (or Darcs for that matter) by just setting the permissions on the relevant directory, since each branch is stored in a separate directory. I consider it a feature that it simply uses OS security: if you want ACLs, use a kernel that supports ACLs. If you want SELinux style features, use SELinux. Simplicity helps security.You can also spread branches across machines. Put your main branch on a machine that only the core team can access. Easy. You can't have high confidence in the change auditing mechanisms, since most of the interesting logging/auditing/etc would need to occur in the client. Arch would be an excellent application for the SFTP logging patch. This would give you a strong audit trail of who committed to which branch and when. This is probably stronger than you can manage with CVS or Svn, since the audit log is maintained by root and doesn't directly rely on anything invoked by the user, unlike typical CVS/Svn hooks. It also means that if there's a security vulnerability, ALL of your users with write access need to upgrade, or the central server itself is compromised. That's an issue with Svn and CVS too: if somebody can ssh to your machine and they get rooted then you are at risk. With all three systems you can reduce the risk by using chroots or restricted shells or whatever, but it's still there. So please encourage your developers not to get rooted. Arch allows you to do development without anyone having a login to anyone else's box. This is a major security feature, not supported by either CVS or Svn at the moment.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 18:05 UTC (Thu) by abentley (guest, #22064) [Link] You can't have high confidence in the change auditing mechanisms, since most of the interesting logging/auditing/etc would need to occur in the client. On the contrary, Arch has support for gpg-signed archives. The signing happens client-side, which means you know which archives you can trust even after a server compromise.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 12:38 UTC (Wed) by piman (subscriber, #8957) [Link] Subversion can also operate this way if you're only interested in SSH-based access.Both Arch and Subversion require "a lot" of configuration and dependencies if you want fine-grained access controls, e.g. Apache + DAV.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 13:13 UTC (Wed) by mmarsh (subscriber, #17029) [Link] That's why I'd like to see a more active project adopt the OpenCM approach of using SSL and identifying principals with public keys rather than passwords. Having authorized users specified as "Alice keys/alice.pubkey" and not requiring any further knowledge of Alice on the server would make life much easier for collaborations. Add SPKI/SDSI-type delegation and you could reduce the server-side access control to the public key of the repository owner (who might not even have an account on the machine), but this is probably overkill for a typical CM system.This would be perfect for people who don't have root, and consequently can't add users, and run the server under their own UID. It would also be easier than giving people accounts, though you'd have to worry about the security of the CM software.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 17:21 UTC (Wed) by piman (subscriber, #8957) [Link] I'm no expert in PKI (or Apache), but I think Apache can already authenticate like that.I know that with Apache (or svnserve) you can easily let users define their own authorization schemes, which don't rely on local logins.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 18:04 UTC (Wed) by mmarsh (subscriber, #17029) [Link] Apache certainly can, but that's kind of a heavyweight solution for a CM server. svnserve has a similar feature to pserver, except that passwords are never sent over the wire, but are used in a cryptographic hash. Unfortunately, the passwords are stored in cleartext. I just can't bring myself to use anything that stores cleartext passwords. Given how (relatively) easy OpenSSL is to use, it's surprising that there only seems to be one CM that takes advantage of it (not counting Subversion+Apache).Of course, the right thing to do would be to offer to help Subversion add SSL/TLS to the stand-alone server.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 19:02 UTC (Wed) by mbp (guest, #2737) [Link] Both Arch and Subversion require "a lot" of configuration and dependencies if you want fine-grained access controls, e.g. Apache + DAV.I don't think that is true for Arch. I have different branches with different visibility simply by publishing them on public web sites, private web sites, or not at all. I don't allow anyone to directly commit to my archives and that works fine. There is no DAV involved, and only Apache 1.3. What configuration do you suppose is needed? (Congratulations on spelling "a lot" correctly though. It certainly raises the tone compared to Slashdot. :-)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 0:22 UTC (Thu) by piman (subscriber, #8957) [Link] I don't consider flat-out refusing others to commit to your archive fine-grained. I do realize that it fits much better with some of the development models supported by Arch, and so is a more realistic possibility than with Subversion (where such a situation would essentially result in no developers sharing revision information at all).Personally I see value in having many people able to commit to the same repository. This can be done with Arch or Subversion, but it requires more configuration than just SSH to do properly for both of them. To say that Arch doesn't require any server configuration (like dmarti) did is technically true, but you can make the same claim for SVN - in both cases, for the limited, one-committer, private archive situation. Even in your case, there's some server configuration involved in publishing the Arch changesets appropriately.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 0:31 UTC (Thu) by mbp (guest, #2737) [Link] So what do people mean by "fine-grained"? Finer than branches? Do you want to limit which directories or files can be touched?The thing is this: anyone who I would trust to have SSH access to my machine and to commit to a branch, I would trust to commit to any file within that branch. If they suddenly turn bad, being able to commit anywhere is enough to cause trouble. I can't think of many cases where I want to allow people to write to only particular files in a project. I can certainly imagine people only being able to write to one project and not another, or to one branch but not another. But Arch accomodates those uses just fine, and without requiring as much configuration as Svn. Just chgrp/chmod the directory and you're done. > This can be done with Arch or Subversion, but it requires more I don't think that's correct. What were you thinking of?
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 0:44 UTC (Thu) by piman (subscriber, #8957) [Link] (I realize that one significant thing I was forgetting was that in Arch, branches are not (necessarily) directories. In Subversion, they are, and I was conflating branch permissions with directory permissions unconsciously. Sorry.)I am more interested in the case where I am some user on a system, without root access. I have some repository/project that the admin has set up for me, and I want to be able to authorize people to read from and commit to it. I want to do this as easily as possible, without having to bug the admin whenever I want to change a user's permissions. I cannot see a way to do this with Arch or Subversion, period, without setting up some sort of (non-SSH) server. One serious problem any SCM will run into with SSH-based access, at least if it is used on huge "communities" like SourceForge, is that Linux only allows 32 groups per user. I can't really fault Arch for this, but it does mean that some alternate authentication methods will have to be looked at.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 2:02 UTC (Thu) by mbp (guest, #2737) [Link] Ah, OK. So with subversion, people can write through the DAV module and be authenticated as a user that does not exist as a system user. That is a good feature.I think setting that up to be secure is going to be more work than configuring either svn+ssh or arch+ssh, and I personally would feel less comfortable that it is secure. Although Arch does not take this quite as far as Subversion, it does not require one OS-level uid per committer. For something like SF, you might be better off with one uid per project, and multiple SSH keys. I can think of a few ways to solve your problem, depending on the details. The first question would be, why do you want other people to be able to commit to the repo? Let's suppose the answer is that you have several developers, you all trust all each others changes and nobody wants to be the gatekeeper or integrator. What I would probably do is let every developer have their own archive. On the "head" archive, I would have a script that regularly tries to pull in changes from each developer, and maybe only commits to head if they compile/pass the test/whatever. I guess with Subversion you could set up your own DAV server on a high-numbered port, but frankly I'm not sure that is something you should be doing without the administrator's permission. Most admins on net-connected machines don't appreciate it when people start complex servers listening for connections without the admin's permission. You could get to a similar situation with Arch by running your own ftp server on a high-numbered port, limited to the appropriate directory. I would be a bit nervous about doing that, but it is not inherently any more risky than the Svn server. This would let people directly commit to the archive, etc. (Can you start sshd as non-root? The protocol would allow it in principle, but I don't know if it works...) > One serious problem any SCM will run into with SSH-based access, Right, and SF hit this bug with CVS a while ago. I think the whole idea of having one machine with tens of thousands of users is pretty bad to start with. The security implications are horrible, and in fact I read some project's horror story the other day about a rogue user deleting their files. With Arch you don't *have* to have one centralized machine for the whole world. It solves the SF problem at a deeper level.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 5:15 UTC (Thu) by job (guest, #670) [Link] ACLs? (Rant below.)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 6:40 UTC (Thu) by Wol (guest, #4433) [Link] Nobody's mentioned BitKeeper ... it sounds to me like Arch is meant to be similar in principle.I do not want ANYONE updating my archive. And the central project archive should only be updated by ONE person (or a group agreeing amongst themselves). Linus uses BitKeeper because he can give everyone *read* access to his tree and they keep themselves up-to-date. He has *read* access to other peoples' trees and can update his system from theirs as he sees fit. I get the impression Arch is designed to work the same way - you need one person keeping the master repository up-to-date by *pull*ing from the developers, and the developers keeping up-to-date by *pull*ing from the master. If you think in CVS terms you won't understand what the hell is going on, because CVS is a *push* system - the deverloper pushes updates to the central repository. Cheers,
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 19:46 UTC (Thu) by josh_stern (guest, #4868) [Link] I hate to sound ungrateful and demanding, but for using the pullmodel it would be nice to have an integrated email push of the comment logs. I'm not familiar whether bitkeeper provides such but I haven't come across such a thing in the docs for arch. Yeah, I know it wouldn't be too hard to hack up an alternative interface for oneself...so I'm just giving feedback that this would be a desirable feature add-on.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 2, 2004 12:02 UTC (Wed) by proski (subscriber, #104) [Link] The nice thing about yum and apt-get is that you don't have to worry about dependencies.
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 0:28 UTC (Thu) by mkching (guest, #21009) [Link] If you are doing an open source project, there are a few places that will host your repo for free. The propaganda page lists berlios.de as one. I believe there are a few others. For non-open-source projects, you can test out a free trial at my subversion hosting site. No need to bother with server setup. :)
Why not upgrade CVS? Subversion, GNU Arch, etc. Posted Jun 3, 2004 16:01 UTC (Thu) by brouhaha (subscriber, #1698) [Link] I'd be interested in using Subversion instead of CVS if it didn't have so many dependencies.If you have dependency problems building Subversion (as I did when building it on Red Hat 9), and if you don't need the WebDAV/Delta support (which is superfluous since you can use svnserve instead), it's actually quite easy to build Subversion. It can build all of its prerequisites in its own source tree and statically link them in. The source tarball includes everything you need other than Berkeley DB. I just untarred db-4.2.52 (the latest stable release at that time) inside the top level of the Subversion source tree, and configured it thusly: ./configure --prefix=/usr --enable-all-static --with-berkeley-db=db-4.2.52 --without-apache --without-apxs Now I use Fedora Core 2, which has all the appropriate prerequisites, and includes Subversion anyhow.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 11:19 UTC (Wed) by iabervon (subscriber, #722) [Link] The thing that's difficult about arch is that it doesn't really support having multiple people working on the same archive. So if you have a CVS repository whose commit access is handled with g+ws and a group, you can't do the obvious switch.Instead what you're supposed to do is to have each developer have an archive, and they can pull chagesets from each other's archives; arch understands changesets so the constant branch merging shouldn't be too painful. I'm not sure how you're supposed to make the step of syncing with the rest of the group easy, though; as far as I can tell, you have to search all of the other members archives for changes that you might want to take, or have a single maintainer control the official version. It is possible to do the group access control, but you have to come up with some way of changing your umask when doing sftp and separately changing it (with a wrapper script) for local use.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 11:41 UTC (Wed) by josh_stern (guest, #4868) [Link] The easiest setup if all developers are of equal priviledge isto make a new special user for each given project and have the special user own the repository. Every developer can then login as the special user, for instance via sftp. Deveoper identities are still preserved in the logs. But it would be nicer and more flexible if Arch eventually supported ACLs within its commit process.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 12:36 UTC (Wed) by moffixx (guest, #22010) [Link] Arch's format is inherently log-structured. Changesets are just appended onto the archive. I'm not sure how fine grained you really want to get, but you can't forbid a checkin for one directory in an arch project while allowing all the others.You can, however, restrict access on a per-project basis. And if you really need stricter access control, then you probably want to do a more distributed method anyway. Have untrusted developers publish their own archives, and merge in from them what you feel is appropriate.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 13:34 UTC (Wed) by josh_stern (guest, #4868) [Link] "you can't forbid a checkin for one directory in an arch project whileallowing all the others" Of course it could work that way. A detailed error would be reported, no checkin would occur, and the developer would find an alternative strategy - e.g. a) decide she didn't really need to modify that other directory, or b) get someone else with the necessary priviledge to do the checkin.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 19:27 UTC (Wed) by mbp (guest, #2737) [Link] Oh, you're talking about allowing some users to commit to say ./doc/ but not anywhere else in the source tree?It's true that Arch can't directly support that, while Svn can. I would think that the way to do this under Arch would be to have a separate branch in which the documentation developers can work. A working directory can be assembled from several trees using Arch config specs, which are kind of like CVS modules. (In fact I suppose you could use CVS modules to allow per-directory commits, which I had not thought about before. Doesn't Mozilla do something like that?) In some ways this seems conceptually cleaner. It is somewhat more complex to set up, but that only has to be done once, then copied into the checkout instructions. On the other hand, I think it's a feature that Arch's version control is managed by OS permissions which are likely to be well-understood and stronger. You can also put the different branches on different machines, which might be a good idea if you really distrust those documentation guys. The idea of access control means something different in distributed systems. On Subversion, somebody not trusted to commit to a directory can really work on it. In distributed systems, people who are not trusted to commit at the moment can still do their own work and submit it for consideration.
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 12:32 UTC (Wed) by moffixx (guest, #22010) [Link] The article, in fact, describes precisely how multiple users may share an archive. I encourage you to read it!
Arch for CVS Users (Linux Journal) Posted Jun 2, 2004 15:30 UTC (Wed) by walters (subscriber, #7396) [Link] The thing that's difficult about arch is that it doesn't really support having multiple people working on the same archive. That's completely, totally false. See:
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 0:41 UTC (Thu) by mbp (guest, #2737) [Link] > So if you have a CVS repository whose commit access> is handled with g+ws and a group, you can't do the > obvious switch. Yes you can. It works fine. Why are jaberbon and piman repeatedly insisting on this page that it doesn't work when it plainly does? Did you even try it? OK, it's possible there's soemthing wierd on your machine, or you're hitting an arch bug, or Nick's instructions were less than perfectly clear. Leaving that aside, it works fine: if you have a shared writable directory, you can have a shared writable archive. Easy. In fact, even less is often needed than what Nick says. Many (most?) Linux machines have a umask of 002 by default and per-user groups. If you have this and you just chmod g+swx the directory, you're done. This is exactly the same issue that regularly fouls Subversion repos too.
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 0:47 UTC (Thu) by piman (subscriber, #8957) [Link] I never said that wasn't sufficient; I'm just trying to dispel dmarti's myth that Arch requires zero server-side setup. I consider creating a reasonable SSH policy server-side setup; in addition, see my last comment on what just plain doesn't work with SSH-only access (let alone zero-setup access).
Arch for CVS Users (Linux Journal) Posted Jun 4, 2004 22:26 UTC (Fri) by iabervon (subscriber, #722) [Link] I missed the part of the article which explained how to set up sftp tohave a non-default umask, but that's what I described in my third paragraph: some way to have sftp change the umask. Unlike CVS, arch doesn't handle g+s itself, but does something useless and mysterious in this case (you have a shared writing archive, but users steal the lock when they commit). The article also doesn't mention how you deal with local access to the repository or NFS access to the repository, the first of which I'm using, and the second of which (with CVS) I used at a previous company. I haven't tried Subversion to see what it does. The default umask on Debian (which is what we're using on the relevant systems) is 0022, so there are plenty of systems with this configuration.
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 5:14 UTC (Thu) by job (guest, #670) [Link] Linux has had ACLs for five years now, isn't it time to use them? It'seven all in the stable tree now. Works on ext2/3, xfs, jfs, reiser (a few still require a simple patch). There's no need to mess around with the group/owner-system in the few cases, like this one, where it is clear ACLs makes it easier for you. The right tools for the right job! (And tools taking advantage of this is tools done right.)
Arch for CVS Users (Linux Journal) Posted Jun 3, 2004 14:42 UTC (Thu) by josh_stern (guest, #4868) [Link] I'm also in favor of more future use of ACLs, but are you really sayingthat it is recommended to rely on ACLs for security with non ACL aware file modifying applications (including source control apps)? Why exactly do you expect that newly created and modified files will always get the intended attributes?
Arch for CVS Users (Linux Journal) Posted Jun 10, 2004 2:09 UTC (Thu) by job (guest, #670) [Link] For most repositorys my guess is that one inherited ACL should be enough.Arch is early in its development so perhaps it can be extended to handle the more complicated cases without too much work? I have no idea about this really so I should let someone else talk. I meant to illustrate the upside of leaving authentication to the operating system.
|
|||||||||||