Taylan Yetkin wrote:
> Sure. But then how can I commit codes I develop at fermi machines to my
> local cvs server? This is almost the whole reason that I'm trying to
> setup a remote cvs repository.
I am just suggesting a "workaround"
you decide on how to use it if at all...
> Maxim kovgan wrote:
>> Taylan Yetkin wrote:
>>> yes, I can.
>> If so, why don't you setup CVS via ssh tunnel:
>>
>> connect like this:
>>
>> ssh myuser@mysshserver -L 2401:<remote IP>:2401
>>
>>
>> after you've connected on your local machine you can setup the
>> CVSROOT=:pserver:anoncvs@localhost:2401/var/lib/cvsroot
>>
>> and then you can:
>> cvs login
>>
>> BTW, maybe you can use IP for your thing too via the regular CVS.
>>
>> Cheers.
>>
>>
>>
>>>
>>> Maxim kovgan wrote:
>>>> Taylan Yetkin wrote:
>>>>> I would like to give some update and ask help again:
>>>>> problem: unable to access remote cvs server (my desktop) from
>>>>> fermi machines
>>>>>
>>>>> [cmswn082] cvs login
>>>>> Logging in to
>>>>> :pserver:[log in to unmask]:2401/var/lib/cvsroot
>>>>> CVS password:
>>>>> cvs [login aborted]: connect to
>>>>> neutralino.physics.uiowa.edu(128.255.34.167):2401 failed: No route
>>>>> to host
>>>>>
>>>>> [cmswn082] telnet neutralino.physics.uiowa.edu 2401
>>>>> Trying 128.255.34.167...
>>>>> telnet: Unable to connect to remote host: No route to host
>>>>>
>>>>>
>>>>> When I tried to see if port 2401 listens, I see that it does
>>>>> [root@neutralino]# netstat -an | grep LISTEN | grep 2401
>>>>> tcp 0 0 0.0.0.0:2401
>>>>> 0.0.0.0:* LISTEN
>>>>>
>>>>> [root@neutralino]# /sbin/chkconfig --list cvspserver
>>>>> cvspserver on
>>>>>
>>>>>
>>>>> My /etc/xinetd.d/cvspserver looks like
>>>>> service cvspserver
>>>>> {
>>>>> port = 2401
>>>>> socket_type = stream
>>>>> protocol = tcp
>>>>> wait = no
>>>>> user = root
>>>>> passenv = PATH
>>>>> server = /usr/bin/cvs
>>>>> server_args = -f --allow-root=/var/lib/cvsroot pserver
>>>>> log_type = FILE /var/log/cvspserver
>>>>> env = HOME=/usr/cvs
>>>>> disable = no
>>>>> }
>>>>>
>>>>> and hosts.allow and host.deny
>>>>>
>>>>> hosts.allow:
>>>>>
>>>>> cvs: LOCAL
>>>>>
>>>>> hosts.deny: empty
>>>>>
>>>>>
>>>>> How can I find out the reason for no connection?
>>>>
>>>> can you connect to that machine via SSH ?
>>>>
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Taylan
>>>>>
>>>>>
>>>>>
>>>>> Maxim kovgan wrote:
>>>>>> well, go and search for the firewalls on the way now.
>>>>>> with a clear conscience.
>>>>>> :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Taylan Yetkin wrote:
>>>>>>> I couldn't find how to capture ipv6 packets but I disabled it to
>>>>>>> see if it makes any difference. Actually I still get the same
>>>>>>>
>>>>>>
>>>>>>
>>>>>> assuming your interface of question is eth0:
>>>>>> tcpdump -vvv -i eth0 -w results.tcpdump ip6
>>>>>>
>>>>>> this will run as much as you want, and will print how many
>>>>>> packets has it got, once in a while.
>>>>>>
>>>>>> when you have enough, you stop it with ^C, and go and watch the
>>>>>> results of the capture via wireshark, or ethereal or any other
>>>>>> graphical tool.
>>>>>>
>>>>>> regards.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> cvs [login aborted]: connect to
>>>>>>> neutralino.physics.uiowa.edu(128.255.34.167):2401 failed: No
>>>>>>> route to host
>>>>>>>
>>>>>>> message. telnet is also giving similar problem:
>>>>>>>
>>>>>>> telnet neutralino.physics.uiowa.edu 2401
>>>>>>> Trying 128.255.34.167...
>>>>>>> telnet: Unable to connect to remote host: No route to host
>>>>>>>
>>>>>>> :
>>>>>>>
>>>>>>>
>>>>>>> Maxim kovgan wrote:
>>>>>>>> Can you try and capture any ipv6 packets trying to leave your
>>>>>>>> computer when you're trying to login into cvs or to do other
>>>>>>>> things with cvs ?
>>>>>>>>
>>>>>>>>
>>>>>>>> IF you find anything running, disable ipv6.
>>>>>>>> (refer to your distribution's manual on how to do this.)
>>>>>>>>
>>>>>>>> Cheers.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Taylan Yetkin wrote:
>>>>>>>>> Hi,
>>>>>>>>> ifconfig in the host returns:
>>>>>>>>>
>>>>>>>>> eth0 Link encap:Ethernet HWaddr 00:19:D1:25:1F:C9
>>>>>>>>> inet addr:128.255.34.167 Bcast:128.255.35.255
>>>>>>>>> Mask:255.255.252.0
>>>>>>>>> inet6 addr: fe80::219:d1ff:fe25:1fc9/64 Scope:Link
>>>>>>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>>>>>>>> RX packets:190785 errors:0 dropped:0 overruns:0 frame:0
>>>>>>>>> TX packets:55961 errors:0 dropped:0 overruns:0 carrier:0
>>>>>>>>> collisions:0 txqueuelen:100
>>>>>>>>> RX bytes:57983176 (55.2 MiB) TX bytes:11357915 (10.8
>>>>>>>>> MiB)
>>>>>>>>> Base address:0xecc0 Memory:dffe0000-e0000000
>>>>>>>>>
>>>>>>>>> lo Link encap:Local Loopback
>>>>>>>>> inet addr:127.0.0.1 Mask:255.0.0.0
>>>>>>>>> inet6 addr: ::1/128 Scope:Host
>>>>>>>>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>>>>>>>>> RX packets:5670 errors:0 dropped:0 overruns:0 frame:0
>>>>>>>>> TX packets:5670 errors:0 dropped:0 overruns:0 carrier:0
>>>>>>>>> collisions:0 txqueuelen:0
>>>>>>>>> RX bytes:10405386 (9.9 MiB) TX bytes:10405386 (9.9 MiB)
>>>>>>>>>
>>>>>>>>> while netstat -nr returns
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Kernel IP routing table
>>>>>>>>> Destination Gateway Genmask Flags MSS
>>>>>>>>> Window irtt Iface
>>>>>>>>> 128.255.32.0 0.0.0.0 255.255.252.0 U 0
>>>>>>>>> 0 0 eth0
>>>>>>>>> 169.254.0.0 0.0.0.0 255.255.0.0 U 0
>>>>>>>>> 0 0 eth0
>>>>>>>>> 0.0.0.0 128.255.32.1 0.0.0.0 UG 0
>>>>>>>>> 0 0 eth0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Taylan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maxim kovgan wrote:
>>>>>>>>>> Taylan Yetkin wrote:
>>>>>>>>>>> Both ping and traceroute the host from fermi machines
>>>>>>>>>>> returns success. I need some time to understand the use of
>>>>>>>>>>> tcpdump.
>>>>>>>>>>> thanks,
>>>>>>>>>>> Taylan
>>>>>>>>>>
>>>>>>>>>> can you post your ifconfig of the listening interface ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> a routing table would be nice too:
>>>>>>>>>> netstat -nr
>>>>>>>>>>
>>>>>>>>>> you can of course scramble the IP addresses.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Maxim kovgan wrote:
>>>>>>>>>>>> John Summerfield wrote:
>>>>>>>>>>>>> Maxim kovgan wrote:
>>>>>>>>>>>>>> John Summerfield wrote:
>>>>>>>>>>>>>>> Taylan Yetkin wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>> I installed a cvs repository in my local SL machine and
>>>>>>>>>>>>>>>> trying to connect
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> from fermi machines. I get the following error:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [cmswn085> cvs login
>>>>>>>>>>>>>>>> Logging in to
>>>>>>>>>>>>>>>> :pserver:[log in to unmask]:2401/var/lib/
>>>>>>>>>>>>>>>> cvsroot
>>>>>>>>>>>>>>>> CVS password:
>>>>>>>>>>>>>>>> cvs [login aborted]: connect to
>>>>>>>>>>>>>>>> neutralino.physics.uiowa.edu(128.255.34.167):2401
>>>>>>>>>>>>>>>> failed: No route to hos
>>>>>>>>>>>>>>>> t
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is a routing/firewall problem. the cvs command asks
>>>>>>>>>>>>>>> for the password before trying to connect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 07:02 [summer@numbat ~]$ cvs -d
>>>>>>>>>>>>>>> :pserver:anoncvs@localhost:2401/var/lib/ login
>>>>>>>>>>>>>>> Logging in to :pserver:anoncvs@localhost:2401/var/lib
>>>>>>>>>>>>>>> CVS password:
>>>>>>>>>>>>>>> cvs [login aborted]: connect to [localhost]:2401 failed:
>>>>>>>>>>>>>>> Connection refused
>>>>>>>>>>>>>>> 07:03 [summer@numbat ~]$
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's most probably tcpwrappers
>>>>>>>>>>>>>
>>>>>>>>>>>>> No. That allows a connexion, then rejects it. You don't get
>>>>>>>>>>>>> "no route" or "refused messages."
>>>>>>>>>>>>
>>>>>>>>>>>> AFAIK tcpwrappers refuse too.
>>>>>>>>>>>> but I somehow missed the no route to.. :)
>>>>>>>>>>>> and you're right! it needs some investigation:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. ping to the host
>>>>>>>>>>>> 2. traceroute to the host.
>>>>>>>>>>>>
>>>>>>>>>>>> if you sporadically get the no route problem, it means you
>>>>>>>>>>>> have ... a routing problem :)
>>>>>>>>>>>>
>>>>>>>>>>>> after you finished up with it, you can continue and trouble
>>>>>>>>>>>> shoot.
>>>>>>>>>>>> routing problem can be cause by your university/enterprise
>>>>>>>>>>>> firewall too.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> you can also investigate with tcpdump, which is a great
>>>>>>>>>>>> sniffer.
>>>>>>>>>>>>
>>>>>>>>>>>> Good luck!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> "reset" is more probable.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Maxim Kovgan,
Distributed Systems and Data Mining Laboratory
Computer Science, Technion
http://dsl.cs.technion.ac.il
|