Getting tag information without checkout
I'm trying to find out what files a tag owns and then inturn find out what tags a specific file belongs to. The problem is that I need to do this without checking out the file every time. I am trying to set up a notification system for ant builds for some code that is moving from a development environment to production environment. The person preforming the move is not a developer so the build itself needs to warn them that the file has been modified by multiple tags recently and there could be a conflict with a version on the production machine. Any ideas welcomed, Yolan * * Yolan (Aaron Jackson) [EMAIL PROTECTED] * * http://mlug.missouri.edu/~yolan/* *AIM: YolanLINUX, YolanOTHER, YolanLAPTOP * * ICQ: 74624109 * * * Doubling Technologies * ** ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: I just instigated admin controls by opening up and configuring the UserAdminOptions setting. My account is a member of Linux cvsadmin group, yet like non-privileged users I cannot execute admin commands. Then you're not really a member of the cvsadmin group. If you just added your account to the group, you have to log out and back in again before it takes effect. The id command will show you which groups you're really a member of. That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. julian. = -Larry Jones Girls are so weird. -- Calvin tell me about it - I've married three of them so far ... ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I just instigated admin controls by opening up and configuring the UserAdminOptions setting. My account is a member of Linux cvsadmin group, yet like non-privileged users I cannot execute admin commands. Then you're not really a member of the cvsadmin group. If you just added your account to the group, you have to log out and back in again before it takes effect. The id command will show you which groups you're really a member of. -Larry Jones Girls are so weird. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. In that case, my guess is that you're not using your account, you're using the generic cvs account (you say all of your CVS users are mapped to the same cvs system user and it's the system user that has to be in the cvsadmin group). Mapping all of your CVS users to the same system user destroys any system-level security or accountability since everyone appears to be the same user. If you have SSH access to the system, you're much better off using it directly in :ext: mode as individual system users rather than tunnelling pserver and mapping everyone to the same user. -Larry Jones When you're as far ahead of the class as I am, it doesn't take much time. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Getting tag information without checkout
On 6/27/05, Aaron Jackson [EMAIL PROTECTED] wrote: I'm trying to find out what files a tag owns cvs rlog -NS -r tag name module name | grep RCS file: | sed some sed script to get the file name and then inturn find out what tags a specific file belongs to. cvs rlog module name/file name | sed some sed script that parses from 'symbolic names:\n' to 'Keyword subsitution: ' one tag name:version pair per line The problem is that I need to do this without checking out the file every time. I am trying to set up a notification system for ant builds for some code that is moving from a development environment to production environment. The person preforming the move is not a developer so the build itself needs to warn them that the file has been modified by multiple tags recently and there could be a conflict with a version on the production machine. Any ideas welcomed, Yolan * * Yolan (Aaron Jackson) [EMAIL PROTECTED] * * http://mlug.missouri.edu/~yolan/* *AIM: YolanLINUX, YolanOTHER, YolanLAPTOP * * ICQ: 74624109 * * * Doubling Technologies * ** ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. In that case, my guess is that you're not using your account, you're using the generic cvs account (you say all of your CVS users are mapped to the same cvs system user and it's the system user that has to be in the cvsadmin group). Mapping all of your CVS users to the same system user destroys any system-level security or accountability since everyone appears to be the same user. If you have SSH access to the system, you're much better off using it directly in :ext: mode as individual system users rather than tunnelling pserver and mapping everyone to the same user. -Larry Jones I'm not quite sure what you mean by mapping users. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. I need Internet access, which is why I tunnel across ssh. The instructions I followed to configure cvs suggested I use a userlogin:password:cvsaccount structure to the $CVSROOT/CVSROOT/passwd file, so each user would have his/her specific cvs-related privileges, but that the server would run as user cvs. If I'm not understanding this correctly, please let me know :-) j. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I obey the letter of the law, if not the spirit. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: undesirable cvs behavior?
Hi Greg - There is a better way to do this. We have designed the WANdisco CVS Replicator for extreme fault tolerance. Using our solution you create active/active replicas that can be failed over with zero data-loss instantly. CVS hosting companies like CVSdude (http://www.cvsdude.org) are adopting our solution to offer High Availability (HA) for CVS repositories. Since the replicas are all equal (no master/slave) anyone of them can field a request in case there is network or node failure at a site. So no issues like missing updates when you switchback from secondary to primary. To learn more you can visit http://www.wandisco.com/cvs Regards, - Rahul Bhargava, CTO, WANdisco Mountain View, CA http://www.wandisco.com/cvs Gregory N. Olszewski wrote: We have a situation where we may have to quickly failover to a mirror which may be missing 5-10 minutes of data. In that case, it would be impractical to ensure that every engineer knows that they may lose data if they update. 3. Does anyone know of a better way to accomplish this? ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? j. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
permission to a single module
Hi to all, I am new to the use of CVS. How can I set to a USER a write(commit) permission to MODULE-A and readonly permission to MODULE-B and forbid read and write permissions to othe modules ? I read a lot of documentation and FAQ, but so far I don't have solved the above permission problems. If you can address me to a complete documentation, I'd really appreciate it. Thank you in advance, Nicola ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian Opificius [EMAIL PROTECTED] writes: Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? Using ssh in a restricted execution mode in general and for restricted execution of CVS is discussed in many places. I suggest you may find more reading useful... try these documents: http://www.idealx.org/doc/chrooted-ssh-cvs-server.en.html http://www.prima.eu.org/tobez/cvs-howto.html http://www.informatimago.com/linux/chrooted-ssh-cvs.html You may also find other documentions via your favorite search engine. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCwF2X3x41pRYZE/gRAv1sAJ0e08Qbt74VqXR4ELjguqFkoruPPwCdHKna u9OpZ7vumWiDN1fHzzEFa/s= =sqVv -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius wrote: SNIP I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? If you search the list[1] and some of the howtos you should be able to figure out how to set ssh so that the users can only execute one command on the server, that command is 'cvs'. If you are already giving them SSH access to the machine, to then run pserver, you have less accountability (and/or authentication [I can never remember which]) than if you were just giving them SSH (with no restrictions on commands), because all logs show the cvs user they are mapped to instead of the real user name (look for some of Greg A. Woods posts[2] on these matters). [1] http://lists.gnu.org/archive/html/info-cvs/ A promising hit is http://lists.gnu.org/archive/html/info-cvs/2003-09/msg00203.html [2] http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=woods+AND+ssh+AND+pserveridxname=info-cvsmax=20result=normalsort=score -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. Please note that CVS was designed to enable collaboration, not to enforce access controls and audit trails. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
