(no subject)
___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ANN: cvssh - secure ext-to-pserver bridge
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, January 23, 2002 at 22:56:35 (-0800), Paul Sander wrote: ] Subject: Re: ANN: cvssh - secure ext-to-pserver bridge When someone uses shared accounts, they throw away Unix security. Maybe that's your point, but on the other hand Unix security is not needed in many carefully controlled situations. No, they throw away any and all possibility of accountability, especially with CVS. Period. Applications don't require Unix user IDs to track their own user bases. You don't need *Unix security* to have *good security*, even on a Unix system. But obviously if an application does away with Unix security and all the stuff that goes with it, then it must replace it with its own mechanism. This clearly can and in fact is done; ask anyone who provides applications that service more than 33000 users on a Unix system. Anyway, this is getting a bit off topic... --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository access question...
Thanks alot for all the help...I'll try and get it done during the weekend. I'll let you know if it works or not. Regards from Olav! Rob Helmer wrote: On Thu, Jan 24, 2002 at 06:01:31PM -0500, Douglas Finkle wrote: :-) I have SSH, CygWin, and Putty on my windoze box. Tortoise CVS comes with SSH via a DOS window...and you have to punch in the password for every CVS command. Thats not very user friendly for people totally blank on CVS and SSH and linux. Must be a better way (easier for the users). Why not use WinCVS? I'm pretty sure the user can even set his/her passwd in the line that specifies the repository. That would solve the retyping problem, but at the expense of some security/authentication. Can anyone confimr this? Larry, Greg, anybody? Again, this is a training/procedural problem. The way to do this in WinCVS is by using an SSH private/public keypair with no passphrase. HOWTO is here : http://www.jfipa.org/publications/CVSGuide/ HTH, Rob Helmer ___ 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
Canonical Substitution
Hi, Is it the client or the servers job to perform CRLF -- LF substitution when transfering text files between Windows and Unix platforms? Many thanks, Duncan. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Revision Problem
Seyethu - Just check the source out as you would normally do cvs -d CVSROOT co Module. The 1.1.1.1 revision is from a vendor import. Unless you explicitly work on the vendor branch you will be ok. Also, I noticed that you also emailed me seperately, in the future I only answer cvs questions directly on info-cvs. Emails sent directly to me will generally be ignored. donald On Thu, Jan 24, 2002 at 11:43:21PM -0800, seyethu Abthagir wrote: Hi All, I have created new directory structure for my project and imported it into the CVS repository using import command on Linux. I can see the Revision number as 1.1.1.1, when I checking out the imported .cpp files. But, I don't want the Revision number to be as 1.1.1.1 and I want the Revision number to be start with 1.1 as such. It would be appriciated, Could any one of u give me solution to erodicate this problem as soon as possible? Thanks in adv, abu. __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ 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: Revision Problem
On Thu, Jan 24, 2002 at 11:43:21PM -0800, seyethu Abthagir wrote: Hi All, I have created new directory structure for my project and imported it into the CVS repository using import command on Linux. I can see the Revision number as 1.1.1.1, when I checking out the imported .cpp files. But, I don't want the Revision number to be as 1.1.1.1 and I want the Revision number to be start with 1.1 as such. This is standard behaviour for CVS. It actually creates both version 1.1 and 1.1.1.1 of the files (which happen to be identical). The 1.1.1.1 version is on the vendor branch. The revision numbers should not really be taken as having much of a meaning. I find that just letting CVS do it's own thing with the version numbers works. If you want to assign any meaningful labels to the version numbers, tags are the way to go. If you reall, reall, really want the version numbers to start with 1.1 and never want to see an 1.1.1.1 version, they you may be better off performing an *empty* import: - Create a new directory - import the newly created (and still empty) directory. - check out the newly created project somewhere - copy your existing files into the new sandbox - add all your new directories and files - cvs commit. This should give you version 1.1 of everything. It would be appriciated, Could any one of u give me solution to erodicate this problem as soon as possible? Thanks in adv, abu. -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com Today's fortune: BTW: I have a better name for the software Microsoft Internet Exploder. -- George Bonser [EMAIL PROTECTED] msg16594/pgp0.pgp Description: PGP signature
Re: it is in the way problem
At 12:19 AM 1/25/2002 -0600, Jason Allen wrote: I have my CVS repository all setup and working but occasionally I am seeing some really strange errors. Every once in a while when doing an update I get a whole bunch of move away file X, it is in the way errors. One not-so-obvious cause for this error occurred with my development team not too many days ago. We are developing a PHP-driven website using CVS for versioning. I develop on an Apache server running on Linux, and another team member develops on Windows/IIS. The other day she started getting the error you're talking about. Since she didn't have any uncommitted changes, we dropped the module out of her sandbox completely and re-checked it out. Still got the same error. I went to my sandbox and did the same thing without any problems. Turns out that on my sandbox I had created a new file that had the same name as another file with a different case. For example, the repository contained button.gif and I had added a file called Button.gif. Of course on Linux this is perfectly legal so I wasn't aware there was a problem. On Windows as soon as the CVS client tried to create Button.gif Windows said that file is already here. Anyway, to fix I renamed the file (obviously). This may not have anything to do with what you are doing but I thought I'd share just in case. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
permissions on modules
Two questions actually. 1. Say you have a repository with two modules (let's say red and blue for the names). I know if you put a user account in the readers file in CVSROOT, it will give that person only read access to the whole repository. Is there a way to give someone read-only to red but read/write to blue? Is it a bad idea to start using actual Unix permissions for things like this or does CVS allow you to get granular? 2. I assume you can create more than one repository on a machine, but my CVS repository is in /usr/local/cvs now. Where would a second one go? Can you specify any directory for where the repository can sit. Thanks for your help, Scott ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
default entry in cvswrappers
Hello, I would like to define -kb as default in cvswrappers and then list only file types that should be treated as text, like this: * -k 'b' *.rtf -k 'kv' -m 'COPY' *.RTF -k 'kv' -m 'COPY' *.txt -k 'kv' -m 'MERGE' *.TXT -k 'kv' -m 'MERGE' Will this work as defined, do I have to reorder entries, and are the patterns case sensitive? Thanks Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: permissions on modules
1. Say you have a repository with two modules (let's say red and blue for the names). I know if you put a user account in the readers file in CVSROOT, it will give that person only read access to the whole repository. Is there a way to give someone read-only to red but read/write to blue? Is it a bad idea to start using actual Unix permissions for things like this or does CVS allow you to get granular? Have a look at the message thread from yesterday and the day before called Repository access question. I had kind of the same problem you had and got a pretty detailed answer. 2. I assume you can create more than one repository on a machine, but my CVS repository is in /usr/local/cvs now. Where would a second one go? Can you specify any directory for where the repository can sit. Yes you can. Read the Cederquist manual section about Multiple repositories at http://www.cvshome.org/docs/manual/cvs_2.html#SEC9 Olav! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: after Cygwin update, CVS authorization fails
What you see (mangling) is a CR after john so the start of the follwing line (probably cvs server: au is hidden on screen). Seems you have checked out a text file under Windows (WinCVS) and now under Unix (Cygwin) the CR is not recognized as end of file (instead of a checked out file it could also be any file in the CVS subdirectories). Essentially that means: Use one sandbox for working under WinCVS and another one for Cygwin. If this advice/solution does not please you... that is the result of the thread with subject WINCVS and MSVC problem on this very list. Regards Stephan -- john lukar wrote: I just did an update to my cygwin installation which includes the cvs client as well. after doing so, I can no longer login and checkout to our cvs server. my cvs client version using cvs -version says: Concurrent Versions System (CVS) 1.11 (client/server) the peculiar thing is that, when I change to another directory e.g. e:\temp, then I can do all of my cvs operations including login and checkout of modules. It is only the e:\projects directory that is creating this problem for me. This is where I maintain all of my cvs managed projects, even prior to my cygwin upgarde. Also my failure message says: thorization failed: server mycvsserver rejected access to /share/CVS. As you can see the user name johnthoriztion is mangled. My cvs login d is john, but the au part of authorization is dropped and prefixed with my name. I can jCVS and WinCVS to manager this same directory e:\projects. I seems to be only the cygwin cvs client that is a problem. thanks much john. any ideas? __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ 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: it is in the way problem
I have my CVS repository all setup and working but occasionally I am seeing some really strange errors. Every once in a while when doing an update I get a whole bunch of "move away file X, it is in the way" errors. This seems to happen quite randomly and I haven't been able to pin it down. Anybody ever experienced something like this?Heres the CVS command I'm using to update my working copy:cvs -d :ext:user@server:/repository -z3 up -d -I ! -I CVSI believe this error occurs when/if you have deleted/moved etc some of the CVS files that are created at checkout. It helps to delete that directory/module and checkout again. Subsequent update commands will not have the error. -Anjali Jason Allen wrote: I have my CVS repository all setup and working but occasionally I am seeing some really strange errors. Every once in a while when doing an update I get a whole bunch of "move away file X, it is in the way" errors. This seems to happen quite randomly and I haven't been able to pin it down. Anybody ever experienced something like this?Heres the CVS command I'm using to update my working copy:cvs -d :ext:user@server:/repository -z3 up -d -I ! -I CVSAny help is appreciated,Jason A.
Customer Care Center
Title: Take Control Of Your Conference Calls Crystal Clear Conference CallsOnly 18 Cents Per Minute! (Anytime/Anywhere) No setup fees No contracts or monthly fees Call anytime, from anywhere, to anywhere Connects up to 100 Participants International Dial In 18 cents per minute Simplicity in set up and administration Operator Help available 24/7 Get the best quality, the easiest to use, and lowest rate in the industry. If you like saving money, fill out the form below and one of our consultants will contact you. Required Input Field* Name* Web Address Company Name* State* Business Phone* Home Phone Email Address* Type of Business c 1999-2002 CCFL To be removed from our distribution lists, please Click here.. ** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and i18n.
Vijay Sridhar writes: I would like to know if CVS has been internationalized. No, it has not. -Larry Jones Pitiful. Just pitiful. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: after Cygwin update, CVS authorization fails
john lukar writes: It is only the e:\projects directory that is creating this problem for me. This is where I maintain all of my cvs managed projects, even prior to my cygwin upgarde. Also my failure message says: for user johnthorization failed: server mycvsserver rejected access to /share/CVS. That indicates that the CVS administrative files (in the CVS subdirectory) in that particular directory have DOS line endings (CRLF), but the CVS executable you're using is running in Unix mode and thus interpreting the CRs as data rather than as part of the line endings. I don't know if that's a problem with the way the CVS executable was built or with the cygwin environment, but it's not a problem with CVS itself. -Larry Jones Even though we're both talking english, we're not speaking the same language. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge issue
Schwenk, Jeanie writes: I received this from one of our engineers here (I added a few details for clarity). I think the merge behaved this way because of the order of the tags. Is that correct? Yes and no. So I tried something different. I checked in my current, beautified version, so that my version and the branch were both beautified and both committed. Then I did this: cvs update -j HEAD -j systema_v1_2 EQC_RobotArm.java The results of this were bizarre. These files were merged. Where there were conflicts, the contents of systema_v1_2 were taken only. No conflict file was created. ViewCVS's diff clearly showed the conflicts ... I know they are there. That's not bizzarre, that's exactly what [s]he asked for. That particular update command says, Please take all of the changes between version HEAD and version systema_v1_2 and apply them to the current version in my working directory. Since the current version *was* HEAD, there aren't any local changes that need to be merged and thus no chance of conflicts; it effectively replaces the current version in toto with version systema_v1_2. The original update with just one -j option is the correct way to merge. I would presume that the extended conflicts are due to subtle differences in the beautification, which is why doing such things is generally inadvisable when branches are, or may be, involved. -Larry Jones Talk about someone easy to exploit! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Overwriting a sandbox
Ajmal Chaumun writes: Does anyone know how we can update the sandbox with the BEST_TODAY tag while keeping the files already checked out under previous tag LAST_GOOD_BUILD but that are not tagged BEST_TODAY. Basically, it comes to saying I want to overwrite a few files on top of an existing sandbox. There isn't any easy way (there may well not even be a hard way). You should tag all the files, not just some of them. -Larry Jones I sure wish I could get my hands on some REAL dynamite. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Revision Problem
seyethu Abthagir writes: I can see the Revision number as 1.1.1.1, when I checking out the imported .cpp files. But, I don't want the Revision number to be as 1.1.1.1 and I want the Revision number to be start with 1.1 as such. Revision numbers are for CVS's internal bookkeeping only, you should ignore them. Use tags for external version numbering. -Larry Jones Physical education is what you learn from having your face in someone's armpit right before lunch. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to enforce user enter log message before run commit command ?
George xu writes: In wincvs console ,I get cvs commit: warning: unrecognized response = `your log msg is:test . ' from cvs server ,why ? I want to print your log msg is:test when = log exist. and if log is empty then print you must enter log message . But Now I get cvs commit: warning: unrecognized response . What server are you using? I believe this is a bug in the NT server and does not occur with the standard CVS code. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Can I temporarily stop commits to a directory
Title: Can I temporarily stop commits to a directory Hello, I know this is a weird request but we are moving some directories around and so need to stop only commits to the current directory so we can copy \ make the new directory and then cvs remove the files at the old places so the files can later on be modified at new location. ( I would like to clarify that maintaining the version history of these few files is not important but moving is more necessary) . Is it possible to temporarily restrict the commit access to these directories only. with say lock files so that people can still checkout and update the said directories. I tried putting #cvs.lock and this stops the checkout and update also. Thank you very much for your time. If this has been addressed elsewhere kindly point me in the right direction, I tried to search on Google, but may have missed the relevant document. Regards, Rajesh PS: Please copy the reply to me since I had to unsubscribe recently due to spam mail on the list.
Re: default entry in cvswrappers
Stephan Feder writes: I would like to define -kb as default in cvswrappers and then list only file types that should be treated as text, like this: * -k 'b' *.rtf -k 'kv' -m 'COPY' *.RTF -k 'kv' -m 'COPY' *.txt -k 'kv' -m 'MERGE' *.TXT -k 'kv' -m 'MERGE' Will this work as defined, do I have to reorder entries, and are the patterns case sensitive? CVS will use the first entry that matches, so you need to reorder to put the more specific entries first and the more general entries last. The patterns are case sensitive, but you can use character classes to make the specification easier. Also, there's no need to specify -k or -m if it matches the default. So, the above could be: *.[Rr][Tt][Ff] -m 'COPY' *.[Tt][Xx][Tt] * -k 'b' This doesn't work in client/server mode, however, unless you're running the current development version of CVS on the client. -Larry Jones Whatever it is, it's driving me crazy! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Canonical Substitution
Stephan Feder writes: What I would like to known is what (standard) C library function does the trick? All of the standard I/O functions are responsible for mapping between the C stream format with LF line terminators and whatever the host file format is when the file is opened in text mode (which is the default). -Larry Jones Years from now when I'm successful and happy, ...and he's in prison... I hope I'm not too mature to gloat. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Overwriting a sandbox
Title: RE: Overwriting a sandbox Hi, That's the way I find it! For a few files (10), I would just update each of them. For more files (~100), I did the following: 1o Tag my working sandbox with tag FUTURE_GOOD_BUILD (cvs tag FUTURE_GOOD_BUILD ...) 2o Check out using tag BEST_TODAY in another sandbox, and tag it FUTURE_GOOD_BUILD too (cvs tag -F FUTURE_GOOD_BUILD ...) ~ notice the -F option this time 3o Go back to the first sandbox, and do an update using the tag FUTURE_GOOD_BUILD to fetch the files BEST_TODAY This seems to work; still, it would have been less painful with one single command. Thanks for the response. /Ajmal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 11:36 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Overwriting a sandbox Ajmal Chaumun writes: Does anyone know how we can update the sandbox with the BEST_TODAY tag while keeping the files already checked out under previous tag LAST_GOOD_BUILD but that are not tagged BEST_TODAY. Basically, it comes to saying I want to overwrite a few files on top of an existing sandbox. There isn't any easy way (there may well not even be a hard way). You should tag all the files, not just some of them. -Larry Jones I sure wish I could get my hands on some REAL dynamite. -- Calvin
Re: ANN: cvssh - secure ext-to-pserver bridge
[ On Friday, January 25, 2002 at 00:24:31 (-0800), Paul Sander wrote: ] Subject: Re: ANN: cvssh - secure ext-to-pserver bridge Applications don't require Unix user IDs to track their own user bases. Yes, they do, since in particular this one uses the Unix filesytem and has no other means of controlling who has access to what. And we're _not_ even talking about minimal C2 level security here. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Canonical Substitution
Duncan Sommerville writes: Is it the client or the servers job to perform CRLF -- LF substitution when transfering text files between Windows and Unix platforms? The client/server protocol specifies that files are to be transferred in a canonical format, so it is the client's job to translate between that format and the host-specific file format. However, that job is delegated to the C run-time library in the standard implementation. -Larry Jones Shut up and go get me some antiseptic. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS utility offered
I have come up with a utility that handles the following situation: 1) User X sets up a cvs watch on files in a project. 2) User X leaves company. [Normally, at this point, you can su to that user and do a cvs watch remove, and all is well. But what if(read on)] 3) User X user account is deleted. [Now you cannot su to that user anymore.] 4) Some other user commits changes to one of those watched files, and gets error messages (dying gasp) related to that missing watcher. 5) That other user complains about the error messages. The utility I have written is a perl script / shell script that, as safely as I could possibly make it, gets rid of that user from the watch lists in a project. I think that this might be of interest to others. Do you have any recommendations as to what I can do with it? [Now there's a setup line if I ever heard one...] Thanks. - Rob - Rob Ries The Adrenaline Group, Inc. 1445 New York Avenue 4th Floor Washington, DC 20005 work: 202.628.4438 fax: 202.628.7120 cell: 703.863.8606 http://www.adrenaline.com | building the next opportunity ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS utility offered
Rob Ries wrote: The utility I have written is a perl script / shell script that, as safely as I could possibly make it, gets rid of that user from the watch lists in a project. I think that this might be of interest to others. Do you have any recommendations as to what I can do with it? [Now there's a setup line if I ever heard one...] Posting it to the list would be a good first step. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can I temporarily stop commits to a directory
Rajesh Patwardhan writes: Is it possible to temporarily restrict the commit access to these directories only. with say lock files so that people can still checkout and update the said directories. I tried putting #cvs.lock and this stops the checkout and update also. You need to create a read lock in that directory. See the manual for details: http://www.cvshome.org/docs/manual/cvs_2.html#SEC17. -Larry Jones At times like these, all Mom can think of is how long she was in labor with me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
»õÇØ Ã¹ Ãâ¹ßºÎÅÍ ¾Ë¶ãÇÏ°Ô~ °¡»ç¸ô °øµ¿±¸¸Å¿Í ÇÔ²²Çϼ¼¿ä![±¤°í]
Title: Untitled Document ¿À¸®ÅÐÆÄÄ« FISHJIVE ÃÖÁ¾°¡:58,000 ¿ø µ¹°í·¡Äí¼Ç´ã¿ä °¡»ç¸ô ÃÖÁ¾°¡:18,900 ¿ø ¸ÓÇ÷¯ (2°³ 1¼¼Æ®) Å©¸®½ºÃ® ¿ÀÀÚ¸£ ÃÖÁ¾°¡:8,800 ¿ø Çظ®Æ÷ÅÍ ¸ÓÇ÷¯ ¸¶ÅÚ (2°³1¼¼Æ®) ÃÖÁ¾°¡:19,500 ¿ø ·çÀ̺ñ¶ËŸÀÔÅäÆ®¹é °¡»ç¸ô ÃÖÁ¾°¡:10,900 ¿ø Çظ®Æ÷ÅÍ °¡¹æ¼ÂÆ® ¸¶ÅÚ ÃÖÁ¾°¡:37,600 ¿ø
Re: CVS, Connection refused
William Daffer wrote:
Lamar Thomas [EMAIL PROTECTED] writes:
Hi everyone,
I am running RH 7.1 and CVS 1.11-3 using the bash shell. When I try and
connect to cvs I get the following error: Connection refused. Anyone
have any ideas? Thanks for any help.
Lamar
I take it you're connecting to a remote server?
Are you using RSH as the transport? What is the value of CVS_RSH?
Assuming you are: is rshd installed? (or is it rexecd, it's been so
long since I installed those Sun RPC facilities) rpm -q rsh
If installed, does the server have `rsh' chkconfig'd on? This is
part of the xinetd configuration. man chkconfig man xinetd
If installed and chkconfig'd on, does the server's
/etc/hosts.{allow,deny} allow such a connection? man hosts_access
You can use SSH by setting CVS_RSH to 'ssh'. That's a safer way to
do it anyway.
whd
--
ABILITY, n. The natural equipment to accomplish some small part of
the meaner ambitions distinguishing able men from dead ones. In the
last analysis ability is commonly found to consist mainly in a high
degree of solemnity. Perhaps, however, this impressive quality is
rightly appraised; it is no easy task to be solemn.
-- Ambrose Bierce: _The Devil's Dictionary_
No, I am trying to connect from the server it self.
Lamar
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ANN: cvssh - secure ext-to-pserver bridge
--- Forwarded mail from Greg Woods: [ On Friday, January 25, 2002 at 00:24:31 (-0800), Paul Sander wrote: ] Subject: Re: ANN: cvssh - secure ext-to-pserver bridge Applications don't require Unix user IDs to track their own user bases. Yes, they do, since in particular this one uses the Unix filesytem and has no other means of controlling who has access to what. And we're _not_ even talking about minimal C2 level security here. Kindly take my comments in context: Applications don't require Unix user IDs to track their own user bases. You don't need *Unix security* to have *good security*, even on a Unix system. But obviously if an application does away with Unix security and all the stuff that goes with it, then it must replace it with its own mechanism. This clearly can and in fact is done; ask anyone who provides applications that service more than 33000 users on a Unix system. Applications require a Unix user ID to run, especially if they write to the Unix filesystem. That's not the same thing as tracking their user bases. They can either use the mechanisms supplied with the Unix system and use Unix user IDs, or they can roll their own security. My point is that they don't *need* to do security the Unix way, if they're willing to put in the work to do something else. If the application uses something else, then it's up to its implementors to decide what else, how much, and how well. Some would argue that the latter route is preferable, because if an application runs without privilege in a regular Unix account with a filesystem having minimal permissions (perhaps even a chroot jail if the operator is paranoid) then security is increased. The reason for that is because if a user breaks out of the application, the amount of damage he can inflict upon the system (as a whole) is limited. But because such a rogue user can potentially damage the application significantly, there is incentive for the application developers to do their security right. CVS' pserver mode implements its own security. It's up to the CVS developers and the pserver mode users to decide if the security is good enough. If it's not, then pserver mode should be fixed, or the users should use another mode (as you suggest). I argue the former, whereas you argue the latter. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ANN: cvssh - secure ext-to-pserver bridge
[ On Thursday, January 24, 2002 at 20:40:53 (-0500), Michal Wallace wrote: ] Subject: Re: ANN: cvssh - secure ext-to-pserver bridge You obviously have very strong feelings about this... Can you help me understand specifically what risks are involved? This has been discussed endlessly in this forum in the past :-) These are the precautions I'm taking: - The CVSROOT directory is read-only, so customers can't add their own users without going through me, nor can they set up wrappers. Ah, but is it protected from potential trojans -- i.e. from authorised users being tricked into making such modifications on behalf of unathorised users? - CVS runs as the user(s) specified in the CVSROOT/passwd file. Each repository gets its own user, that does not have access to any other repository. This is a big mistake. You've turned CVS into an authorisation tool giving outside users access to your Unix filesystem (or at least some part of it) and to Unix user-ids. CVS was not designed or implemented as an authroisation tool. It is not secure -- there are many potential bugs, and some of them are not bugs in the normal proper use of CVS. - The cient-server traffic is protected with SSL. That's mostly irrelevant, though obviously something of the sort is necessary for any communications over an insecure network. - I am in the process of setting up a chrooted jail (or jails) on the server, to keep CVS from accessing any other directories. Chroot() is vastly over-rated, and rather complex to get right. Complexity is an enemy of security. Jail() similarly so. CVS was not designed to play well with either and there are many assumptions built into the design of CVS which will break the most fundamental premises necessary to do chroot() well. I would suggest you and your users just learn to use SSH and forget about trying to implement any security software yourself. If you already have real unix user-ids for every real user then you're most of the way to making it work properly -- why not go all the way? If you insist on going your own way then I insist you first read Bruce Shneier's Secrets Lies: Digital Security in a Networked World from cover to cover, and then also read John Viega Gary McGraw's Building Secure Software: How to Avoid Security Problems the Right Way cover to cover (maybe even twice) before you even think about how to design your program, let alone write a single line of its code. (i.e. first throw away what you have and be prepared to start over from scratch after you've learned from these most learned of security sages) CVS is a simple filesystem level tool. You should no more put security responsibilities in it than you would in 'vi' or 'emacs'. CVSpserver must die. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Utility to remove dead watchers
I wrote a utility that handles the following situation:
1) User X sets up a cvs watch on files in a project.
2) User X leaves company.
[Normally, at this point, you can su to that user and do a cvs watch
remove, and all is well. But what if(read on)]
3) User X user account has been deleted.
[Now you cannot su to that user anymore.]
4) Some other user commits changes to one of those watched files, and gets
error messages (dying gasp) related to that missing watcher.
5) That other user complains about the error messages. Continually.
The utility is a perl script / shell script (both below) that gets rid of
that user from the watch lists in a project. I tried to make it as safe as I
could think to make it (given my admittedly non-expert CVS internals
knowledge).
Since I figured that others might be up against this same problem, I posted
a question to gnu.org asking them if they had any ideas as to what I could
do with it. They suggested I post them here. So, here you go. Please don't
hesitate to flame if I've just transgressed some rule that I should already
know about.
Thanks.
- Rob
-
Rob Ries
The Adrenaline Group, Inc.
1445 New York Avenue
4th Floor
Washington, DC 20005
work: 202.628.4438
fax: 202.628.7120
cell: 703.863.8606
http://www.adrenaline.com | building the next opportunity
=
*
=
Typical usage - save the fixcvswatchers.sh script, below, as
fixcvswatchers.sh.
Typical usage - save the fixcvswatchers.pl script, below, as
fixcvswatchers.pl.
Then, as root on the box containing the CVSROOT tree:
perl fixcvswatchers.pl -c CVSPROJECTNAME -u USER_TO_BE_AXED_FROM_WATCHERS -r
CVSROOT
That script creates a copy of all of the fileattr files in the target
project tree, without that dead watcher in the watchers list.
At end of that script, you'll get a process ID.
To be extra cautious, you can now do a:
fixcvswatchers.sh -p PROCESSID -x diff -c CVSPROJECTNAME -r CVSROOT | less
This will show you a diff of all of the original fileattr files vs. the new
copies you just created. Finally, to cause CVS to use the new fileattr
files, do a:
fixcvswatchers.sh -p PROCESSID -x move -c CVSPROJECTNAME -r CVSROOT
Until you do that last line, you really haven't changed anything. Look
through the comments at the top of fixcvswatchers.sh for some of its other
functionality.
=
*
=
use File::Find;
use strict;
use vars qw($opt_c $opt_u $opt_r $opt_d);
use Getopt::Std;
#!/usr/bin/perl
# name: fixcvswatchers.pl
# desc: Situation: user X has a cvs watch on a bunch of files
# in CVSProject
# user X leaves company
# user X watches trigger error messages whenever
# surviving company users screw with watched files.
# Easy solution: if userid still exists in /etc/passwd, as root:
# su - username
# cd /home/username/projects
# cvs checkout CVSProject
# cd CVSProject
# cvs watch remove -a all -l *
# cvs watcher | grep username (to make sure)
# Problem:if userid no longer exists, Linux can sometimes
# make it difficult to re-add a user who was
# deleted prior. So this script will get
# rid of the watch for the user.
# environment:
# Script must be run on same box as cvs master repository tree.
# Script must be run as root
# parameters:
# -c CVS project name
# -u user name
# -r CVSROOT
# -d (If present, debug mode is on)
# observations:
# In looking through hundreds or even thousands of fileattr
# files, it appears to be okay if fileattr files have:
# _watchers= without _watched=
# _watched=without _watchers=
# fileattr files do NOT appear to ever have
# empty _watchers lists - eg: _watchers=; or
# _watchers=EOL
# author:
# F. Rob Ries
# The Adrenaline Group, Inc.
# Washington, DC
# [EMAIL PROTECTED]
#
# date: January 23, 2002
my $debug = 0;
my $keystring = ^_watchers=;
my $keystringout = _watchers=;
my $attribseparator = ;;
my $watcherseparator = ,;
my $usage = usage: perl fixcvswatchers.pl -c cvs_project_name -u
user_name_to_be_removed_from_watchlist -r cvsroot\n;
my $matchuser;
sub prtdebug {
if ( $debug 0 ) {
print DEBUG: $_[0]\n;
}
}
sub
Tool to draw a time line
Does anybody know of a tool, that will draw the time-line of a cvs repositary, branches and all? Nigel ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, Connection refused
Hi!,
Lamar Thomas wrote:
William Daffer wrote:
Lamar Thomas [EMAIL PROTECTED] writes:
Hi everyone,
I am running RH 7.1 and CVS 1.11-3 using the bash shell. When I try and
connect to cvs I get the following error: Connection refused. Anyone
have any ideas? Thanks for any help.
Lamar
I take it you're connecting to a remote server?
Are you using RSH as the transport? What is the value of CVS_RSH?
Assuming you are: is rshd installed? (or is it rexecd, it's been so
long since I installed those Sun RPC facilities) rpm -q rsh
If installed, does the server have `rsh' chkconfig'd on? This is
part of the xinetd configuration. man chkconfig man xinetd
If installed and chkconfig'd on, does the server's
/etc/hosts.{allow,deny} allow such a connection? man hosts_access
You can use SSH by setting CVS_RSH to 'ssh'. That's a safer way to
do it anyway.
whd
--
ABILITY, n. The natural equipment to accomplish some small part of
the meaner ambitions distinguishing able men from dead ones. In the
last analysis ability is commonly found to consist mainly in a high
degree of solemnity. Perhaps, however, this impressive quality is
rightly appraised; it is no easy task to be solemn.
-- Ambrose Bierce: _The Devil's Dictionary_
No, I am trying to connect from the server it self.
Have you checked that there are no firewalls blocking the connection and that
the server service has been started. A look at the netstat -anp connections
will tell you whether or not it is listening for incoming connections.
See ya
Dean Thompson
--
+++
| Dean Thompson | E-mail - [EMAIL PROTECTED] |
| Bach. Computing (Hons) | ICQ - 45191180 |
| PhD Student| Office - Off-Campus |
| School Comp.Sci Soft.Eng | Phone - +61 3 9903 2787 (Gen. Office)|
| MONASH (Caulfield Campus) | Fax - +61 3 9903 1077 |
| Melbourne, Australia ||
+++
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: ANN: cvssh - secure ext-to-pserver bridge
--- Forwarded mail from [EMAIL PROTECTED] [ On Friday, January 25, 2002 at 11:30:27 (-0800), Paul Sander wrote: ] Subject: Re: ANN: cvssh - secure ext-to-pserver bridge CVS' pserver mode implements its own security. It's up to the CVS developers and the pserver mode users to decide if the security is good enough. And there's where your fatal flaw lies. CVS cannot, by design *and* implementation, possibly securely implement any even reasonable level of authentication and authorisation service. Period. CVS pserver is good enough only for totally anonymous (and presumably read-only) access, and _NOTHING_ more. Fine. CVS is BAD (broken as designed) in many ways. Fix the rest of it and pserver at the same time. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
