Re: CVS server upgrade?
Jim, Just wondering what minor problems you had, just in case they might pertain to other peoples' migration strategies (or my own someday)? Thanks! David R. Chase Senior Unemployed Software Developer ; ) - Original Message - From: "Jim.Hyslop" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 02, 2004 3:00 PM Subject: RE: CVS server upgrade? > Courier [mailto:[EMAIL PROTECTED] wrote: > > Here is I would like to do: I will take currently cvs server off line, > > then tar the whole Repository, then bring up a new system and > > cp and untar > > Repository on new server. Our cvs server is a stand alone > > server. All my > > users are accessing via pserver. I don't have any problems > > with username > > and their password migrations, but just concerned about cvs > > Repository. > When we upgraded our server, we took a similar approach. > > We scheduled a dry-run of the process ahead of time, just to make sure there > were no problems and to work out any unforeseen problems. The dry run proved > very valuable, because there _were_ some minor things we had overlooked. > This saved us the time (and embarassment) of cutting off our users from the > repository multiple times. > > In order to minimize the impact on the users, we took the original server > off-line just long enough to create the tarball. As soon as the tar was > complete, we restarted the server in read-only mode (create an empty > CVSROOT/writers file to make the whole repository read-only). Thus, people > could still check out and browse the repository, but they couldn't check > anything in (and thus throw the two repositories out of sync). > > After we were satisfied the new server was up and running properly, we > simply did a DNS switch on the server name (the name the users see is an > alias to the actual machine name). > > -- > Jim Hyslop > Senior Software Designer > Leitch Technology International Inc. (<http://www.leitch.com/>) > Columnist, C/C++ Users Journal (<http://www.cuj.com/experts>) > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
- Original Message - From: <[EMAIL PROTECTED]> To: "Mike Ayers" <[EMAIL PROTECTED]> Cc: "Nick Patavalis" <[EMAIL PROTECTED]>; "David R. Chase" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, October 25, 2002 1:59 PM Subject: Re: Per-modules readers/writers ? > > Nick Patavalis wrote: > > > > > What's wrong with uid/gid based permissions? > > > > For starters, they require that each CVS user have a login account on > > the machine in question. In some cases, this is not acceptable. > > > Assuming that you don't let them log in using it (and that's not > difficult), why would it be unacceptable? > > Moreover, how do you expect to get any accountability without having > separate user accounts, and why would readers/writers work any better > than uid/gid without separate accounts? Sorry about the direct email -- clicked the wrong button for replying to the list. : ) It's probably not any better, more like an alternate feature that would be handy in certain environments. Personally, I'd rather the repository be owned and operated by just one user, and allow the repository administrator to be able to grant and revoke permissions and add new projects and project groups without having to add any users/groups to the system. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Per-modules readers/writers ?
Hello there, Searched some of the archives but came up empty. I don't think it's supported, but I'm mainly asking to see if this will ever be implemented in the future. Basically, I'm wondering if there's any way to limit read/write access to a repository on a modular level, that is, some users mapped in $CVSROOT/CVSROOT/passwd will have read or write access to some modules, while other users will have it for others. I'm mainly trying to obtain finer granularity access control via pserver (or other remote access) authentication rather than via the filesystem's uid/gid and related permissions. With a fairly large repository, administration of large groups of users for a large number of modules can become a nightmare if done on the filesystem level without ACLs. I'd rather have one system user that a great number of developers are mapped to as virtual users, rather than creating a new user or group for each project's members to access the repository with. If not, and I wanted to write a patch to add this feature, what would be the best way to do it? Have module-permissions defined in $CVSROOT/CVSROOT/ [readers,writers] or have permissions defineable in each module directory such as $CVSROOT/module-name/config-dir/[readers,writers] ? (personally, I believe the second choice reduces overhead as the lookups could be done on modular files rather than the global readers/writers files which could tend to become very large). Unless, of course, there's a better way to do what I want it to do, and not on the filesystem level... : ) Thanks in advance, David R. Chase College of Computer Science Northeastern University, Boston ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
