Re: CVS server upgrade?

[Spiro Trikaliotis]

Hello,

* On Mon, Feb 02, 2004 at 03:00:35PM -0500 Jim.Hyslop wrote:
 
> 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).

not that I would recommend it, but:

But about

1. Taking the CVS repository offline
2. Create the tarball
3. Take the CVS repository online with full access (!)
4. do anything needed to move to the new server
5. When everything is working fine, take the (original) repository
   offline again
6. Now perform an rsync between the two repositories
7. Take the new one online (with changing DNS entries and the like).

Would this make sense, or could 6. break something that was made with
4.?

I understand that this procedure seems more "risky", but it seems to me
that this should work, too, shouldn't it?

Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

"Unnamed Branch" Label

[Ofir Cohen]

Hello,

I've encountered a strange thing!
When I'm looking at a file's log  in "smartCVS" (same as status) I see it
under an
"unnamed branch" label.
How can I remove this "ghost" branch with CVS?
Does CVS still refer to it as a branch? Or is it transparent?

Kind regards,
Ofir Cohen.
Software Engineer.
Remon Medical Technologies Ltd.
Tel:  +972-(0)4-623 00 01 ext. 130
Mobile: +972-(0)50-516278
Fax: +972-(0)4-623 08 36
E-mail: mailto:[EMAIL PROTECTED]



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 30/01/2004




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

"Unnamed Branch" Label

[Ofir Cohen]

Hello,

I've encountered a strange thing!
When I'm looking at a file's log  in "smartCVS" (same as status) I see it
under an
"unnamed branch" label.
How can I remove this "ghost" branch with CVS?
Does CVS still refer to it as a branch? Or is it transparent?

Kind regards,
Ofir Cohen.
Software Engineer.
Remon Medical Technologies Ltd.
Tel:  +972-(0)4-623 00 01 ext. 130
Mobile: +972-(0)50-516278
Fax: +972-(0)4-623 08 36
E-mail: mailto:[EMAIL PROTECTED]


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 30/01/2004




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS server upgrade?

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Spiro Trikaliotis <[EMAIL PROTECTED]> writes:

> Hello,
> 
> * On Mon, Feb 02, 2004 at 03:00:35PM -0500 Jim.Hyslop wrote:
>  
> > 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).
> 
> not that I would recommend it, but:
> 
> But about
> 
> 1. Taking the CVS repository offline
> 2. Create the tarball
> 3. Take the CVS repository online with full access (!)
> 4. do anything needed to move to the new server
> 5. When everything is working fine, take the (original) repository
>offline again
> 6. Now perform an rsync between the two repositories
> 7. Take the new one online (with changing DNS entries and the like).
> 
> Would this make sense, or could 6. break something that was made with
> 4.?

Sure #6 could break something for #4, this is why it is considered
useful to test our your commitinfo, loginfo, verifinfo, and taginfo
scripts to be sure they wok regardless of the platform.

Your steps should work okay.

> I understand that this procedure seems more "risky", but it seems to me
> that this should work, too, shouldn't it?

I have had occasion to move repositories from one machine to another a
number of times over the years.

I typically put something into the commitinfo script that denies any
commits to the repository unless the `hostname` matches what I expected.

I have also used 'rsync' (or CVSup soemtimes) to create mirror copies of
the repository.

0. Assume you have two machines oldbox.example.com and
   newbox.example.com and that everyone checks out using
   cvsbox.example.com which happens to be a DNS CNAME that
   points to oldbox.example.com.

1. Mirror the repository to a slave server (newbox) that will become
   the master eventually. On oldbox.example.com do the following:

   rsync --exclude '#cvs*' --exclude ',*,' --blocking-io \
  --recursive --perms --owner --group --times --links \
  --delete --stats /path/to/your/current/cvsroot/directory \
  newbox.example.com:/path/to/your/new/cvsroot/directory

   doing this rsync a few times in succession, I would expect to
   eventually not see any additional files copied. At that point,
   you have your functional mirror for testing and/or deployment.

2. test the new repository for the ability to checkout a tree any
   commits to this version of the repository will likely fail due to
   your commitinfo trigger test for the filename. It is up to you if
   you want to allow test commits to this test repository or not. I
   typically have a 'debugging' repository and module for this
   purpose.

3. Modify the the commitinfo trigger on the master repository, so
   that only commits to the mirror are allowed. This will have the
   effect of making the current master repository a read-only mirror
   that will not allow commits.

4. Repeat step #1 to effectively make the 'slave server' become
   the new master.

5. Alter your DNS so that cvsbox.example.com has a CNAME record
   that points to nwebox.example.com instead of oldbox.example.com.

You are now done and should be able to retire the oldbox.example.com
fairly soon.

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAH3QF3x41pRYZE/gRAr1/AJ9O4UiJuuUT8X9fqXy1uIrUCyRbWQCfYkiq
VmXvIkOZCyVpaAMgnU3P55I=
=3wCu
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS Newbie: List of modules?

[Alex]

Hi there,

I am accessing files on CVS using pserver.
> cvs -d :pserver:xxx checkout ProjectName
The project has been branched and I am not sure what the branch names 
are. Is there a command to get a branch list?

Regards,

Alex.





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS newbie

[Colin Chalmers]

Hi all,


I have to admit that I am a newbie to the CVS world, I have worked with
VSS and CVS client software but never actually setting up the (CVS)
server. Therefore my apologies beforehand for any questions that may seem
obvious to others!


We have installed CVS 1.11.16 on Solaris 8.
It's installed and I can connect from Eclipse using Pserver. So far so
good :-)
Now I'm trying to configure CVS and hang the 4 projects we have under the
root dir. of cvs

The problem I have at the moment is:

I set repository root to /apps/cvs/cvsroot
I then ran cvs init which created CVSROOT under aforementioned dir.
I configured pserver to point to /apps/cvs/cvsroot.

Now when I connect with Eclipse I see the CVSROOT directory (with it's
config/notify files) under Head. Can I *hide* this directory so that users
only see the four modules I want to import into cvs? Or should I
reconfigure CVS in some way?

I appreciate any help

Colin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS server upgrade?

[Jim.Hyslop]

David R. Chase [mailto:[EMAIL PROTECTED] wrote:
> Just wondering what minor problems you had, just in case they 
> might pertain
> to other peoples' migration strategies (or my own someday)?
Well, our situation was much more complex than "Courier's". Not only did we
upgrade the server hardware, we went from FreeBSD to a Sun workstation, and
upgraded the server version from a very old 1.10.[something] to 1.11.5 We
have several remote repositories that mirror portions of the main
repository, and our main repository mirrors portions of the remote
repositories. We also have developed a client/server utility (LCVS - "Leitch
extensions to CVS") that runs in conjunction with CVS, to provide some
functionality that the stock CVS program doesn't - the ability for users to
change their own passwords, or the ability to execute an 'ls' command in the
current directory, for example.

Most of the minor glitches we encountered had to do with porting the LCVS
utility to Sun, while maintaining FreeBSD compatibility (the remote
repositories still run FreeBSD). Setting up permissions is sufficiently
different on Sun than on FreeBSD (don't ask me the details - I'm not a UNIX
sysadmin) that we had to do some fine-tuning.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS Newbie: List of modules?

[Jim.Hyslop]

Alex [mailto:[EMAIL PROTECTED] wrote:
> I am accessing files on CVS using pserver.
>  > cvs -d :pserver:xxx checkout ProjectName
> 
> The project has been branched and I am not sure what the branch names 
> are. Is there a command to get a branch list?
There are at least two ways to do it, both of which are documented in the
manual:
http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_toc.html#SEC_Contents

Have a look at the "status" and "log" commands.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS server upgrade?

[Jim.Hyslop]

Spiro Trikaliotis [mailto:[EMAIL PROTECTED] wrote:
> not that I would recommend it, but:
> 
> But about
> 
> 1. Taking the CVS repository offline
> 2. Create the tarball
> 3. Take the CVS repository online with full access (!)
> 4. do anything needed to move to the new server
> 5. When everything is working fine, take the (original) repository
>offline again
> 6. Now perform an rsync between the two repositories
> 7. Take the new one online (with changing DNS entries and the like).
> 
> Would this make sense, or could 6. break something that was made with
> 4.?
That would work, as long as nobody checked anything into the new server. We
decided to err on the side of safety, rather than take the chance that one
of our 150 or so users might discover the new server and check into it when
they shouldn't.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS with SMB/Winbind Authentication

[Steve McIntyre]

On Mon, Jan 26, 2004 at 01:07:33PM -0500, Dave Morrow wrote:
>
>Thanks for replying.the only thing I am seeing in the logs (of
>relevance) is a line in the /var/log/secure
>
> cvs: password mismatch for adms_nt+morrowd: xxPHiHjG0rmeM vs. x 

Hmmm. That sounds like your auth config is pointing at the shadow
file. Which, in fact, is what your PAM config for cvs below says:

>>auth   required /lib/security/$ISA/pam_unix.so
>>accountrequired /lib/security/$ISA/pam_unix.so
>>auth   required /lib/security/pam_winbind.so
>>accountrequired /lib/security/pam_winbind.so 

If you change this to something like

auth   sufficient   /lib/security/pam_winbind.so
auth   required /lib/security/$ISA/pam_unix.so
accountsufficient   /lib/security/pam_winbind.so 
accountrequired /lib/security/$ISA/pam_unix.so

this may well do what you need. In PAM-speak, "required" on all lines
means that _all_ of the lines must succeed. Changing the order to the
new one here will allow an auth to succeed against winbind, or fall
back to pam_unix if it fails.

Let me know how you get on...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
You lock the door
And throw away the key
There's someone in my head but it's not me 


pgp0.pgp
Description: PGP signature
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Summarize: CVS server upgrade?

[Courier]

Well, I would like to extended my thanks to:

Jim Hyslop, Mark D. Baushke and David R. Chase. I am appreciate that you
guys take time to respond.

1. I will setting up a newer server with the same name and the same
/Repository file system as the old one.
2. Notify to all my users that CVS server will be down about 4 hours or
so. Tell them that this is for system upgrade (Hardware.)
3. Then take old server off line, then tar its Repository.
4. Connecting these two server by Crossover CAT5 for cp and untar new
Repository.
5. After the new CVS server untar is done. Turn it on line, but users
still not allow to accessing it, this is done by Network blocking subnet.
6. Two or three of my developers with do check out and and check in for
testing. (The old server is still there with the same name, but offline.)
This step need to be done throughly so that won't cause me any headaches
later on.

Thus I am so thankfully, that you guys have time to replied.

This give me more time to think and thought into the whole process.

Again, thank you you all.

C-

PS: My OS is Redhat 9.0 with up to date patches. The only different is cvs
version. The old cvs server is : cvs-1.11-3 and the newer version will be:
cvs-1.11.2-13.rpm. This is a up2date package from Redhat.



> David R. Chase [mailto:[EMAIL PROTECTED] wrote:
>> Just wondering what minor problems you had, just in case they
>> might pertain
>> to other peoples' migration strategies (or my own someday)?
> Well, our situation was much more complex than "Courier's". Not only did
> we
> upgrade the server hardware, we went from FreeBSD to a Sun workstation,
> and
> upgraded the server version from a very old 1.10.[something] to 1.11.5 We
> have several remote repositories that mirror portions of the main
> repository, and our main repository mirrors portions of the remote
> repositories. We also have developed a client/server utility (LCVS -
> "Leitch
> extensions to CVS") that runs in conjunction with CVS, to provide some
> functionality that the stock CVS program doesn't - the ability for users
> to
> change their own passwords, or the ability to execute an 'ls' command in
> the
> current directory, for example.
>
> Most of the minor glitches we encountered had to do with porting the LCVS
> utility to Sun, while maintaining FreeBSD compatibility (the remote
> repositories still run FreeBSD). Setting up permissions is sufficiently
> different on Sun than on FreeBSD (don't ask me the details - I'm not a
> UNIX
> sysadmin) that we had to do some fine-tuning.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS server upgrade?

[Spiro Trikaliotis]

Hello Jim,

* On Tue, Feb 03, 2004 at 09:28:59AM -0500 Jim.Hyslop wrote:
> Spiro Trikaliotis [mailto:[EMAIL PROTECTED] wrote:
> > not that I would recommend it, but:
[...]
> > Would this make sense, or could 6. break something that was made with
> > 4.?
> That would work, as long as nobody checked anything into the new server. We
> decided to err on the side of safety, rather than take the chance that one
> of our 150 or so users might discover the new server and check into it when
> they shouldn't.

A good point, I did not think about this case. I think that's the reason
why I said "not that I would recommend it". ;-)

Thanks,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS security question

[Pankaj Garg]

I am a new user of CVS. I setup CVS server on my linux box. I want two users
to have check-in access to my repository and i want to use SSH. To use SSH i
need to make shell accounts for those two users. Now because these two users
have shell account and have write access to my repository, they can
essentially login in my CVS server box and do an rm -fR on my whole
repository. Is there a way to prevent this?
Thanks
PG
_
Check out the new MSN 9 Dial-up — fast & reliable Internet access with prime 
features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Jim.Hyslop]

Pankaj Garg wrote:
> I am a new user of CVS. I setup CVS server on my linux box. I 
> want two users
> to have check-in access to my repository and i want to use 
> SSH. To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

It is possible to set up shell accounts so that the root directory that the
user sees is not the machine's root. I'm afraid that's the limit of my
knowledge in that area, though. Try a web search on "chroot jail", or look
through the archives of the info-cvs mail list.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Matthew . Riechers]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Pankaj Garg
> Sent: Tuesday, February 03, 2004 10:59 AM
> To: [EMAIL PROTECTED]
> Subject: CVS security question 
> 
> To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

You can restrict the commands that users can run via SSH configuration.
Check the [Open]SSH documentation and the list archives for more
information.

-Matt


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Summarize: CVS server upgrade?

[Larry Jones]

Courier writes:
>
> 3. Then take old server off line, then tar its Repository.
> 4. Connecting these two server by Crossover CAT5 for cp and untar new
> Repository.

You minimize the downtime by connecting the two machines first then
running the two tars in parallel through a remote shell:

tar cf - cvsrepos | rsh newserver 'cd /where/ever; tar xf -'

-Larry Jones

You just can't ever be too careful. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Larry Jones]

Pankaj Garg writes:
> 
> I am a new user of CVS. I setup CVS server on my linux box. I want two users
> to have check-in access to my repository and i want to use SSH. To use SSH i
> need to make shell accounts for those two users. Now because these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

Yes.  Explain to them, in excruciating detail, exactly what you will do
to them should they do anything so stupid and be prepared to follow
through.

-Larry Jones

Hmph. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pankaj Garg <[EMAIL PROTECTED]> writes:

> I am a new user of CVS. I setup CVS server on my linux box. I want two users
> to have check-in access to my repository and i want to use SSH. To use SSH i
> need to make shell accounts for those two users. Now because these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

This topic has been recently discussed. See the thread starting here:
  http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00188.html

Note that you can also make "anonymous cvs" access available via SSH if
you wish. Details are listed here in this article by Joey Hess:

  http://www.kitenet.net/~joey/sshcvs/

(a copy of it may also be found here if the first site is busy or down):

  http://www.blacksheepnetworks.com/security/resources/sshcvs/

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAH9YY3x41pRYZE/gRAhr0AJ9bqCrTBdBflwoUfF+zEs40wk3CHwCgma/8
1tkWzfJy7h17burPL9mM7x8=
=fsNR
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Deleting from CVS repository

[RAJAGOPAL, AARTI (SBCSI)]

Hello all,

I may be posting this question to the wrong list, just thought I'd give it a
shot in case anyone knew??

We have Eclipse/WSAD clients accessing our CVS server on AIX. When you
delete projects/files from Eclipse, files seem to goto the Attic folder on
the actual repository, but projects still remain there after deletion, only
get deleted from the local developer's workspace. Do they have to be
manually removed from the CVS server? Is there no way to permanently delete
projects through a CVS client?

Also, when you delete from the filesystem itself, is it preferred to do like
a cvs delete command or an OS command like rm -rf will suffice to ensure the
project and its associated files have been completely removed? 

Also, are they any config changes that can be made on the client/server side
to enable permanent deletion of projects/files through the cvs client? Can
you retreive Attic files through the client?

Thanks for any help provided!






___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs checkout of files edited by user since date?

[Rhodes, Phillip C.]

Hi,

Is there a way that I can do a cvs checkout of a module with only the files that have 
been edited by a particular user, since a particular date?

Thanks!

Phillip


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: cvs checkout of files edited by user since date?

[Jim.Hyslop]

Rhodes, Phillip C. wrote:
> Is there a way that I can do a cvs checkout of a module with 
> only the files that have been edited by a particular user, 
> since a particular date?
By date, yes; by user, no. See
http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_16.html#SEC118 for
details.

Checking out only portions of a module frequently does not make sense. You
can use the 'log' command to see what revisions a specific user has checked
in.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs checkout of files edited by user since date?

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rhodes, Phillip C. <[EMAIL PROTECTED]> writes:

> Is there a way that I can do a cvs checkout of a module with only the
> files that have been edited by a particular user, since a particular
> date?

No, not without doing manul single-file checkouts or some kind of
tagging based on the criteria you are trying to use.

-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAH/H23x41pRYZE/gRArRJAJ4jqWVSv3cYi3kaDhNYl13a/tQpywCfSXUA
pBmolKZrXe1EH37+MM+5qbc=
=ELJj
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

How to determine what tag a branch was based on?

[Dickson, Craig]

Title: How to determine what tag a branch was based on?





Here is the scenario:


Sometime in the past I created a Branch based on a tag that existed on the files on my main branch. Now I need to go back and find out exactly which tag was used as the base of the branch.

Is there a way to determine this conclusively? Our problem is that there has been many tags applies since the branch was created so the "base" files now have multiple tags on them.

Any input would be appreciated.


Craig



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: How to determine what tag a branch was based on?

[Jim.Hyslop]

Dickson, Craig wrote:
> Here is the scenario: 
> Sometime in the past I created a Branch based on a tag that 
> existed on the files on my main branch. Now I need to go back 
> and find out exactly which tag was used as the base of the branch.
> Is there a way to determine this conclusively? Our problem is 
> that there has been many tags applies since the branch was 
> created so the "base" files now have multiple tags on them.
Step 1) Implement a new rule, effective immediately: all branch tag names
must clearly indicate the non-branch tag from which they are created. One
easy way to do this is to adopt a convention that branch tags use the
non-branch tag name, with a "-bt" suffix, e.g.:

cvs tag whatever
cvs tag -rwhatever -b whatever-bt

Step 2: Prepare for a long session. It can be done, but I don't think it
will be easy.
1) Issue the command "cvs status -v>taglist.txt"
2) Open the file in your favourite text editor
Look at the "Existing Tags" section for the first file; it may look
something like this:
   Existing Tags:
branch_from_branch  (branch: 1.1.2.1.2)
testing (revision: 1.2)
TestOnDeleted   (revision: 1.1)
abranch (branch: 1.1.2)
theHead (revision: 1.2)
release_tag (revision: 1.1.1.1)
vendor_tag  (branch: 1.1.1)
tag3(revision: 1.1)
tag2(revision: 1.1)
atag(revision: 1.1)

Suppose you're trying to find the branch point for "abranch". Looking at the
above, you know that - for this file - abranch is based on 1.1. Make a list
of other tags for this file that are applied to 1.1 - in this case, we have
TestOnDeleted, tag3, tag2, and atag.

Now, go through each remaining entry. Here's the next one in my list:

===
File: file2 Status: Up-to-date

   Working revision:2.2
   Repository revision: 2.2 /cvs/cvs-test/jhyslop/file2,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)

   Existing Tags:
branch_from_branch  (branch: 1.1.4)
testing (revision: 1.1)
TestOnDeleted   (revision: 1.5)
abranch (branch: 1.1.2)
theHead (revision: 1.5)
release_tag (revision: 1.1.1.1)
vendor_tag  (branch: 1.1.1)
tag3(revision: 1.1)
tag2(revision: 1.1)
atag(revision: 1.1)

Again, for this file, the branch point is 1.1. The tag TestOnDeleted is
applied to 1.5, so you can cross that tag off the list of candidates,
leaving tag3, tag2, and atag.

Repeat this process until you have only one candidate left, or you have
examined all the files in the project. If you have multiple candidates after
examining all the files, then it doesn't matter - the tags are identical.
Pick one.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. () 
Columnist, C/C++ Users Journal () 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Mark Jaffe]

You can prevent a user from logging in by setting the shell variable in the 
/etc/password file to a nonexistent shell. This will allow authorization, but not 
allow login.

-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Pankaj Garg
> Sent: Tuesday, February 03, 2004 10:59 AM
> To: [EMAIL PROTECTED]
> Subject: CVS security question 
> 
> To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?



=
Mark Jaffe| (408) 972-9638 (home)
Chief Wizard  | (408) 807-2093 (cell)
Computer Wizards  | (425) 795-6421 (FAX)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

[Rick Genter]

It's probably more secure to set their shell to something that does exist but won't 
function as a shell, like /dev/null or /bin/false. That way you don't leave a hole 
where someone could create the non-existent program that the user points to and voila 
- instant access.

--
Rick Genter
Sr. Software Engineer
Silverlink Communications

(781) 272-3080 x242

This e-mail, including attachments, may include confidential and/or proprietary 
information, and may only be used by the person or entity to which it is addressed.  
If the reader of this e-mail is not the intended recipient or his or her authorized 
agent, the reader is hereby notified that any dissemination, distribution or copying 
of this e-mail is prohibited.  If you have received this e-mail in error, please 
notify the sender by replying to this message and delete this e-mail immediately.




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Mark Jaffe
Sent: Tuesday, February 03, 2004 3:26 PM
To: [EMAIL PROTECTED]
Subject: RE: CVS security question


You can prevent a user from logging in by setting the shell variable in the 
/etc/password file to a nonexistent shell. This will allow authorization, but not 
allow login.

-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Pankaj Garg
> Sent: Tuesday, February 03, 2004 10:59 AM
> To: [EMAIL PROTECTED]
> Subject: CVS security question 
> 
> To use SSH i
> need to make shell accounts for those two users. Now because 
> these two users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?



=
Mark Jaffe| (408) 972-9638 (home)
Chief Wizard  | (408) 807-2093 (cell)
Computer Wizards  | (425) 795-6421 (FAX)


___
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: How to determine what tag a branch was based on?

[Matthew Doar]

cvs history -T works nicely on later versions to show when the tag was
made.,

~Matt

On Tue, 2004-02-03 at 12:15, Jim.Hyslop wrote:
> Dickson, Craig wrote:
> > Here is the scenario: 
> > Sometime in the past I created a Branch based on a tag that 
> > existed on the files on my main branch. Now I need to go back 
> > and find out exactly which tag was used as the base of the branch.
> > Is there a way to determine this conclusively? Our problem is 
> > that there has been many tags applies since the branch was 
> > created so the "base" files now have multiple tags on them.
> Step 1) Implement a new rule, effective immediately: all branch tag names
> must clearly indicate the non-branch tag from which they are created. One
> easy way to do this is to adopt a convention that branch tags use the
> non-branch tag name, with a "-bt" suffix, e.g.:
> 
> cvs tag whatever
> cvs tag -rwhatever -b whatever-bt
> 
> Step 2: Prepare for a long session. It can be done, but I don't think it
> will be easy.
> 1) Issue the command "cvs status -v>taglist.txt"
> 2) Open the file in your favourite text editor
> Look at the "Existing Tags" section for the first file; it may look
> something like this:
>Existing Tags:
> branch_from_branch  (branch: 1.1.2.1.2)
> testing (revision: 1.2)
> TestOnDeleted   (revision: 1.1)
> abranch (branch: 1.1.2)
> theHead (revision: 1.2)
> release_tag (revision: 1.1.1.1)
> vendor_tag  (branch: 1.1.1)
> tag3(revision: 1.1)
> tag2(revision: 1.1)
> atag(revision: 1.1)
> 
> Suppose you're trying to find the branch point for "abranch". Looking at the
> above, you know that - for this file - abranch is based on 1.1. Make a list
> of other tags for this file that are applied to 1.1 - in this case, we have
> TestOnDeleted, tag3, tag2, and atag.
> 
> Now, go through each remaining entry. Here's the next one in my list:
> 
> ===
> File: file2 Status: Up-to-date
> 
>Working revision:2.2
>Repository revision: 2.2 /cvs/cvs-test/jhyslop/file2,v
>Sticky Tag:  (none)
>Sticky Date: (none)
>Sticky Options:  (none)
> 
>Existing Tags:
> branch_from_branch  (branch: 1.1.4)
> testing (revision: 1.1)
> TestOnDeleted   (revision: 1.5)
> abranch (branch: 1.1.2)
> theHead (revision: 1.5)
> release_tag (revision: 1.1.1.1)
> vendor_tag  (branch: 1.1.1)
> tag3(revision: 1.1)
> tag2(revision: 1.1)
> atag(revision: 1.1)
> 
> Again, for this file, the branch point is 1.1. The tag TestOnDeleted is
> applied to 1.5, so you can cross that tag off the list of candidates,
> leaving tag3, tag2, and atag.
> 
> Repeat this process until you have only one candidate left, or you have
> examined all the files in the project. If you have multiple candidates after
> examining all the files, then it doesn't matter - the tags are identical.
> Pick one.


signature.asc
Description: This is a digitally signed message part
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Pankaj Garg]

I wonder why do we not CVS has a server which run with SUID (Super User ID) 
and only it can access repository. Other users can login via SSH, verify 
their credentials with our CVS Server and ask CVS Server to carry out their 
requests. They can request normal repository operations based on their 
privilege. This new CVS server will give much better control because we can 
set minute details of permissions on repository and files inside it. In fact 
we can have just One repository in all and host multiple projects under it 
and give control of these projects to different group of people.

Whats stopping people from implementing this?

Thanks
Pankaj
From: "Mark D. Baushke" <[EMAIL PROTECTED]>
To: "Pankaj Garg" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: CVS security question
Date: Tue, 03 Feb 2004 09:10:49 -0800
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pankaj Garg <[EMAIL PROTECTED]> writes:

> I am a new user of CVS. I setup CVS server on my linux box. I want two 
users
> to have check-in access to my repository and i want to use SSH. To use 
SSH i
> need to make shell accounts for those two users. Now because these two 
users
> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

This topic has been recently discussed. See the thread starting here:
  http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00188.html
Note that you can also make "anonymous cvs" access available via SSH if
you wish. Details are listed here in this article by Joey Hess:
  http://www.kitenet.net/~joey/sshcvs/

(a copy of it may also be found here if the first site is busy or down):

  http://www.blacksheepnetworks.com/security/resources/sshcvs/

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAH9YY3x41pRYZE/gRAhr0AJ9bqCrTBdBflwoUfF+zEs40wk3CHwCgma/8
1tkWzfJy7h17burPL9mM7x8=
=fsNR
-END PGP SIGNATURE-
--
Pankaj Garg
www.intellectualheaven.com
_
Learn how to choose, serve, and enjoy wine at Wine @ MSN. 
http://wine.msn.com/



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS security question

Classification: UNCLASSIFIED

> -Original Message-
> From: Pankaj Garg [mailto:[EMAIL PROTECTED]

> SSH. To use SSH i
> need to make shell accounts for those two users.

yes and no. if their repository permissions are the same then make a fake
shell user to represent the persons and then put their keys in
authorized_keys. I have any number of persons that have RW to a tree but on
the CVS server I only have one account that owns the files. I know who
connected from the ssh logs. Yes it might be really nice to know inside of
CVS who was doing what and when but for what I'm doing, it doesn't matter
and simplicity is more desirable. Not to mention like another thread that
just popped up you can't check out what some bloke did, only by time so
knowing the identity of the actor is somewhat debatable.

> have shell account and have write access to my repository, they can
> essentially login in my CVS server box and do an rm -fR on my whole
> repository. Is there a way to prevent this?

others have mentioned using ssh's tricks (~/.sshrc or something like that).
setting a shell to /bin/false keeps interactive access off but as I just
tested to make sure, doesn't actually allow you to run "cvs server" or
anything else for that matter. You need a limited shell script. I wrote one
that basically invokes 'cvs server' after setting up some environment
particulars first. It works fine.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS security question

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pankaj Garg <[EMAIL PROTECTED]> writes:

> I wonder why do we not CVS has a server which run with SUID (Super
> User ID) and only it can access repository. Other users can login via
> SSH, verify their credentials with our CVS Server and ask CVS Server
> to carry out their requests. They can request normal repository
> operations based on their privilege. This new CVS server will give
> much better control because we can set minute details of permissions
> on repository and files inside it. In fact we can have just One
> repository in all and host multiple projects under it and give control
> of these projects to different group of people.
> 
> Whats stopping people from implementing this?

You should be able to implement it if it will meet your needs.

Something like the second-to-last paragraphs of this message:
  http://mail.gnu.org/archive/html/info-cvs/2004-01/msg00163.html
is posible.

I know of a site that runs cvs as a set-gid 'cvs' program wherein all of
the files and directories are in group 'cvs' as an aid to avoid
accidental deletion. A set of periodic jobs gets run as root to chown
the files all to user cvs. No real users are in group cvs and the cvs
user does not have a real password. No file in the repository has world
read or write permissions.

Additional protection may be found by making the parent directory for
the repository is only visible to members of the 'software' group for
the software repository. So, this means that only members of the
'software' group would be able to run the set-gid cvs executable to
do any cvs operations at all.

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAIDDO3x41pRYZE/gRAmNGAJ9+6wBMVW6lIxBGiHRsZc1ODtwFEgCfcTp4
/bzSvuptRQBRKkW/dEMtIgY=
=t7dG
-END PGP SIGNATURE-


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs