mainSavannah Administration - Support: sr #109340, Checking for new files with...

 
 

sr #109340: Checking for new files with "cvs -qn update" always times out

Submitter:  Gavin D. Smith <gavin>
Submitted:  Fri 23 Jun 2017 06:08:39 PM UTC
   
 
Category:  Webpages repositories Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 25 Jun 2017 09:39:31 PM UTC, comment #11: 

:ext: is normal. The usual thing, as far as I've seen, is to set CVS_RSH=ssh in .profile (or whatever), so that rsh is never bothered to be tried.


Karl Berry <karl>
Site Administrator
Sun 25 Jun 2017 09:17:37 AM UTC, comment #10: 

I looked at it again and found that in two of the directories, CVS/Root was

:ext:gavin@cvs.savannah.gnu.org:/web/texinfo

instead, with "ext" instead of "sshext". I am fairly sure I didn't edit these files, at least I don't remember ever doing so, so maybe they were recreated automatically at some point with the wrong contents.

Gavin D. Smith <gavin>
Sun 25 Jun 2017 08:49:13 AM UTC, comment #9: 

It looks like you have located the problem. That being that it is trying to use 'rsh' instead of 'ssh'. Good. I do not know why you would have one directory trying to incorrectly use rsh while another is correctly using ssh. That makes no sense to me.

Some background may be useful. In the beginning was the Berkey 'r'commands rlogin, rsh, rcp, and some lessor known commands such as ruptime and rwho. This was during the time when only telnet and ftp were otherwise in use. When CVS came along it used rsh. The net was a friendly place then. Encryption in the US was considered a munition and regulated.

ssh came later. Now using rsh seems crazy. Everyone and all programs should be using ssh whenever they would have used rsh back a few decades ago. On my Debian system /usr/bin/rsh is a symlink alternative pointing to ssh.

update-alternatives --display rsh

Perhaps you have something else installed and it is being pointed to by rsh?

However your transport specified in your CVS/Root file was "extssh" which is documented as:

   In the Debian and MirBSD versions of CVS, you can also specify
':extssh:' to force use of the Secure Shell, or ':ext=prog:' or
':ext=/path/to/prog:' to specify the remote shell to use without needing
to touch the 'CVS_RSH' environment variable.

I looked at that specifically but it says it forces use of ssh. Therefore if your transport is extssh then I think your client should be using ssh.  But apparently not.  Why is something you will need to track down on your system. With both extssh and with rsh being a symlink to ssh there are multiple things all configuring that any use of rsh will default to ssh. Therefore it makes no sense that you would have actually had rsh running for one of the directories.

You looked at all of your CVS/Root files and said they were all identical.  This really is confusing.  Because if one directory were doing one thing and another directory were doing another thing then I would expect that one of them would need to be different.

And with this I am offline for the night because it is very, very late here. Since we have the answer to the problem, and a workaround for you of setting CVS_RSH=ssh if nothing else, I am going to go ahead and close the ticket for housekeeping. But if you learn anything please update the ticket with the information so that we can learn something here too.



Bob Proulx <rwp>
Site Administrator
Sun 25 Jun 2017 08:47:14 AM UTC, comment #8: 

Warning: the ECDSA host key for 'git.savannah.gnu.org' differs from the key for the IP address '208.118.235.201'
Offending key for IP in /home/g/.ssh/known_hosts:23
Matching host key in /home/g/.ssh/known_hosts:25

This is line 23 in that file:

208.118.235.201 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzFQovi+67xa+wymRz9u3plx0ntQnELBoNU4SCl3RkwSFZkrZsRTC0fTpOKatQNs1r/BLFoVt21oVFwIXVevGQwB+Lf0Z+5w9qwVAQNu/YUAFHBPTqBze4wYK/gSWqQOLoj7rOhZk0xtAS6USqcfKdzMdRWgeuZ550P6gSzEHfv0=

This is line 25:

git.savannah.gnu.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBP9c1Z2f4OHxymvLxqxQ/hY1g0ol0/iiXUrVFGZBBq4h5gD05c7Gw9rRrcrvF9XvumBvOghOQzDSZZLRWvFGocA=

Should I delete line 23 from that file? But I looked at https://savannah.gnu.org/maintenance/SshAccess/ and the key listed there for "ssh-rsa" is the same.

Gavin D. Smith <gavin>
Sun 25 Jun 2017 08:32:05 AM UTC, comment #7: 

The following are the last few lines from the output of "cvs -tn update".

S -> Write_Template (texinfo/manual/texinfo-4.2/ps, /web/texinfo/texinfo/manual/texinfo-4.2/ps)
cvs update: Updating texinfo/manual/texinfo-4.2/ps
S -> Write_Template (texinfo/manual/texinfo-4.2/texi, /web/texinfo/texinfo/manual/texinfo-4.2/texi)
cvs update: Updating texinfo/manual/texinfo-4.2/texi
S -> Write_Template (texinfo/manual/texinfo-4.2/text, /web/texinfo/texinfo/manual/texinfo-4.2/text)
cvs update: Updating texinfo/manual/texinfo-4.2/text
S -> Lock_Cleanup()
S -> Simple_Lock_Cleanup()
S -> server_cleanup()
 -> main loop with CVSROOT=:ext:gavin@cvs.savannah.gnu.org:/web/texinfo
 -> Starting server: rsh -l gavin cvs.savannah.gnu.org cvs server
vcs0.savannah.gnu.org: Connection timed out
cvs [update aborted]: end of file from server (consult above messages if any)
 -> Lock_Cleanup()
U texinfo/texinfo.html


Everything up until the "Starting server" line ran quickly, then it froze for a while until saying it had timed out.

I tried this again in a subdirectory.

$ cd texinfo/manual/info-stnd/
$ cvs -tn update |& tee log
 -> main loop with CVSROOT=:extssh:gavin@cvs.sv.gnu.org:/web/texinfo
 -> Starting server: ssh -l gavin cvs.sv.gnu.org cvs server
S -> serve_directory (.)
S -> dirswitch (., /web/texinfo/texinfo/manual/info-stnd)
S -> serve_directory (html_node)
S -> dirswitch (html_node, /web/texinfo/texinfo/manual/info-stnd/html_node)
S -> serve_directory (.)

... and the output continues and finishes. Nothing about "rsh" is printed.

I went back to the top level of the checkout and printed all the "Root" files throughout the checkout with the following command:

find . -name 'Root' -execdir pwd \; -execdir cat '{}' \;

However, they were all identical.

I looked through other files under the CVS and CVSROOT directories but didn't see anything.

I tried running

export CVS_RSH=ssh

Then when I tried "cvs -tn update" again it ran fine. Where the output froze before, it now prints

S -> Write_Template (texinfo/manual/texinfo-4.2/texi, /web/texinfo/texinfo/manual/texinfo-4.2/texi)
cvs update: Updating texinfo/manual/texinfo-4.2/texi
S -> Write_Template (texinfo/manual/texinfo-4.2/text, /web/texinfo/texinfo/manual/texinfo-4.2/text)
cvs update: Updating texinfo/manual/texinfo-4.2/text
S -> Lock_Cleanup()
S -> Simple_Lock_Cleanup()
S -> server_cleanup()
 -> main loop with CVSROOT=:ext:gavin@cvs.savannah.gnu.org:/web/texinfo
 -> Starting server: ssh -l gavin cvs.savannah.gnu.org cvs server
S -> serve_directory (texinfo/manual/info)
S -> dirswitch (texinfo/manual/info, /web/texinfo/texinfo/manual/info)
S -> serve_directory (texinfo/manual/info/html_node)
S -> dirswitch (texinfo/manual/info/html_node, /web/texinfo/texinfo/manual/info/html_node)
S -> serve_directory (.)
S -> dirswitch (., /web/texinfo)
S -> do_cvs_command (update)
S -> server_notify()
U texinfo/texinfo.html

and so on. Note the "Starting server" line has "ssh" on it instead of "rsh".

Do you know why "rsh" is being used here?

Gavin D. Smith <gavin>
Sun 25 Jun 2017 08:25:53 AM UTC, comment #6: 

I don't like that you are getting host key change warnings because the host keys of git.savannah.gnu.org have not changed for years. However I think this is something funny with your ssh client because previous keys, that have not changed, are RSA keys but your client is listing a changed ECDSA key.  ECDSA keys are new with the new servers and have not changed since their creation.  Probably your client is doing something funny there.

Host key fingerprints are listed here:

https://savannah.gnu.org/maintenance/SshAccess/

I was hoping using git over ssh would show some problem and it would indicate a problem with the route to the host or a problem with ssh or with your ssh configuration.  But it did not.  You don't have specific ssh configuration for cvs.sv.gnu.org that is different from git.savannah.gnu.org?

Therefore I must suspect your cvs client software now. I would not think there would be any large difference in cvs client software because it is very mature now. No new releases in years. But if ssh is working for git then I must assume it will be working for cvs too.

Other than this I can't think of anything else to try. Anything else I think of to try is all somewhat complicated.  Such as trying through fencepost or other system with a known good cvs installation. I tried that just now and verified no problem for me.


Bob Proulx <rwp>
Site Administrator
Sun 25 Jun 2017 08:05:39 AM UTC, comment #5: 

$ git clone ssh://gavin@git.savannah.gnu.org/srv/git/hello.git
Cloning into 'hello'...
The authenticity of host 'git.savannah.gnu.org (208.118.235.201)' can't be established.
ECDSA key fingerprint is 65:b8:1c:2f:82:7c:0e:39:e1:4a:63:f2:13:10:e8:9c.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'git.savannah.gnu.org' (ECDSA) to the list of known hosts.
Warning: the ECDSA host key for 'git.savannah.gnu.org' differs from the key for the IP address '208.118.235.201'
Offending key for IP in /home/g/.ssh/known_hosts:23
Are you sure you want to continue connecting (yes/no)? yes
remote: Counting objects: 4418, done.
remote: Compressing objects: 100% (1095/1095), done.
remote: Total 4418 (delta 3295), reused 4418 (delta 3295)
Receiving objects: 100% (4418/4418), 7.59 MiB | 1.70 MiB/s, done.
Resolving deltas: 100% (3295/3295), done.
Checking connectivity... done

I had to type "yes" to proceed, but after that it completed.

Gavin D. Smith <gavin>
Sun 25 Jun 2017 07:55:26 AM UTC, comment #4: 

The CVS/Root file looks okay. And with that exact repository everything is still working okay for me with 'cvs -qn up' and so there doesn't seem to be anything wrong with the savannah repository lock files. I also couldn't find anything in logs around that time that would indicate a problem.

The DNS looks okay. cvs.savannah.gnu.org (and all of the aliases for it) point to 208.118.235.201 correctly. The FSF has had one DNS nameserver ns3.gnu.org offline for as long as I can remember. This has been reported and is known by the FSF admins.

The system vcs.savannah.gnu.org is the old cvs server and it should no longer be reachable from the outside world since when we moved the cvs service to vcs0 earlier this year. The system itself is still up an online hosting the data but is now an NFS server serving the data to vcs0 for cvs hosting.

With all of the above checking out okay I don't know what is the problem.  So we should continue to debug things.  I am not sure the most efficient twenty questions to ask.  So will ask some questions but not necessarily in a good order.

Can you access other repositories such as git, svn, or other? All of those would use ssh and if it works or fails would give a good clue as to whether this is specific to cvs or if it is a network routing problem or perhaps an ssh problem. I'll suggest 'hello' but any project is okay as long as it is by ssh.

git clone ssh://gavin@git.savannah.gnu.org/srv/git/hello.git


Bob Proulx <rwp>
Site Administrator
Fri 23 Jun 2017 09:42:18 PM UTC, comment #3: 

looks like a dns problem. cvs.sv.gnu.org resolves to 208.118.235.201 from both ns1.gnu.org and ns3.gnu.org, which is also what vcs0 resolves to. whereas the current vcs.sv.gnu.org resolves to 208.118.235.72.

incidentally, ns2.gnu.org did not respond. something for the fsf...

Karl Berry <karl>
Site Administrator
Fri 23 Jun 2017 08:40:28 PM UTC, comment #2: 


>Please say what the contents of one of your CVS/Root files is in your working copy. I see vcs0 in the error output and that should not be there, but is not likely to be the root problem.


:extssh:gavin@cvs.sv.gnu.org:/web/texinfo

>Do you have a timestamp near when this problem is occuring so that I can possibly correlate that with anything happening on the system?


I just tried it again:

$ date
Fri Jun 23 21:35:59 BST 2017
$ cvs -qn up
U texinfo.html
vcs0.savannah.gnu.org: Connection timed out
cvs [update aborted]: end of file from server (consult above messages if any)
$ date
Fri Jun 23 21:39:32 BST 2017

BST is one hour ahead so this is 20:39 UTC.

Gavin D. Smith <gavin>
Fri 23 Jun 2017 07:30:19 PM UTC, comment #1: 

"cvs -qn up" is the standard get status command for cvs.  In a somewhat roundabout way.

This is working okay for me on the cvs repositories I use and therefore I want to jump to conclusions.  But first let's get some debug data from you.

Please say what the contents of one of your CVS/Root files is in your working copy.  I see vcs0 in the error output and that should not be there, but is not likely to be the root problem.

cat CVS/Root

Also your error starts talking to vcs0 and then times out. This is likely to indicate a networking problem between you and vcs0. Do you have a timestamp near when this problem is occuring so that I can possibly correlate that with anything happening on the system?

Bob Proulx <rwp>
Site Administrator
Fri 23 Jun 2017 06:08:39 PM UTC, original submission:  

I would like to know if there are new pages I need to track with "cvs add" for a new version of a manual. I have seen "cvs -qn update" as the recommended command to do this, but it doesn't work very well.

$ cvs -qn update
? texinfo/html_node/Obsolete-_0040_002dCommands.html
? texinfo/html_node/texi2any-Environment-Variables.html
vcs0.savannah.gnu.org: Connection timed out
cvs [update aborted]: end of file from server (consult above messages if any)
$ cvs -qn update
vcs0.savannah.gnu.org: Connection timed out
cvs [update aborted]: end of file from server (consult above messages if any)
$ cvs -qn update
vcs0.savannah.gnu.org: Connection timed out
cvs [update aborted]: end of file from server (consult above messages if any)

As you see above, I got told about two files I needed to add, but then it timed out, so I didn't know if there were any more. I tried it again twice and it timed out both times.

I found a work-around to do it in a lower level of directory:

$ cd texinfo/html_node/
$ cvs -qn update

This completed without any error being printed. So I would have to know which subdirectories could have updated files and run "cvs -qn update" in each one. In my case, this is not difficult to do.

Gavin D. Smith <gavin>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by karl (Posted a comment)
  • -email is unavailable- added by rwp (Posted a comment)
  • -email is unavailable- added by gavin (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-06-25 rwp Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code