cvsup trouble

Okay, that is fixed ... for some reason, it didn't restart on last reboot,
have to watch that one ...

On Thu, 20 Sep 2001, Thomas Lockhart wrote:

Okay, that is fixed ... for some reason, it didn't restart on last reboot,
have to watch that one ...

Thanks for fixing it. Now of course the machine does not seem to be
visible. That was the case yesterday too; are these planned outages, is
it still bouncing up and down as it is configured, or is it flakey? I
can see postgresql.org pretty consistantly, but cvsup.postgresql.org is
not visible at the same time.

- Thomas

just checked, and the machine has been up 14days now ... I can ssh into it
from cvs.postgresql.org, and the last cvsup connection was about 5 minutes
ago:

Sep 21 09:10:42 server1 cvsupd[50149]: +3 otto@host115.olabinc.com (fs1.olabinc.com) [SNAP_16_1e/16.1]
Sep 21 09:11:53 server1 cvsupd[50149]: -3 [165Kin+275Kout] Finished successfully

nslookup for it should return:

Name: rs.postgresql.org
Address: 64.39.15.238
Aliases: cvsup.postgresql.org

On Fri, 21 Sep 2001, Thomas Lockhart wrote:

Two points

1) I think that the problem with restarting at boot has occurred before.
2) I just sync'ed via cvsup at cvsup.postgresql.org and it deleted all
under pgsql/src/interfaces/odbc/*. It also does not seem to appear
anywhere else. What's up?

This is my client version:
(193)-> cvsup -v
CVSup client, GUI version
Copyright 1996-2001 John D. Polstra
Software version: SNAP_16_1e
Protocol version: 17.0
Operating system: FreeBSD4
http://www.polstra.com/projects/freeware/CVSup/
Report problems to cvsup-bugs@polstra.com

This is the start of the output of the session:
(195)-> head -20 !$
head -20 20010921.out
Parsing supfile "cvsup_config"
Connecting to cvsup.postgresql.org
Connected to cvsup.postgresql.org
Server software version: REL_16_1p3
Falling back to protocol version 16.1
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Updating collection pgsql/cvs

Thomas Lockhart <lockhart@fourpalms.org> writes:

Thanks for fixing it. Now of course the machine does not seem to be
visible. That was the case yesterday too; are these planned outages, is
it still bouncing up and down as it is configured, or is it flakey?

Looks fine from here:

$ ping cvsup.postgresql.org
PING rs.postgresql.org: 64 byte packets
64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms

Perhaps there is a routing problem somewhere between you and 64.39.15.238?
That machine is not physically at hub (looks like it's a Rackspace site)
so there might be connectivity issues that are different from hub's.
What do you get from tracerouting to cvsup.postgresql.org?

regards, tom lane

$ ping cvsup.postgresql.org
PING rs.postgresql.org: 64 byte packets
64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms
Perhaps there is a routing problem somewhere between you and 64.39.15.238?
That machine is not physically at hub (looks like it's a Rackspace site)
so there might be connectivity issues that are different from hub's.
What do you get from tracerouting to cvsup.postgresql.org?

*slaps forehead*

I didn't catch on to the different network, and 64.x has always been a
problem on my firewall/masquerading box since I'm also on a 64.x subnet
and it keeps wanting to put in default routes for a class A network. So
it is all a problem on my end.

I had done some testing at another location yesterday, when I was
finding that cvsup connections were being rejected.

Any hints on how to supress this default route when the network is
configured?

Sorry Marc for the false alarm (today anyway ;)

- Thomas

On Fri, 21 Sep 2001, Thomas Lockhart wrote:

$ ping cvsup.postgresql.org
PING rs.postgresql.org: 64 byte packets
64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms
Perhaps there is a routing problem somewhere between you and 64.39.15.238?
That machine is not physically at hub (looks like it's a Rackspace site)
so there might be connectivity issues that are different from hub's.
What do you get from tracerouting to cvsup.postgresql.org?

*slaps forehead*

I didn't catch on to the different network, and 64.x has always been a
problem on my firewall/masquerading box since I'm also on a 64.x subnet
and it keeps wanting to put in default routes for a class A network. So
it is all a problem on my end.

I had done some testing at another location yesterday, when I was
finding that cvsup connections were being rejected.

Any hints on how to supress this default route when the network is
configured?

Best suggestion: Renumber your internal network into one of private
networks (10.*, 192.168.*, 172.16.*).

Alternate suggestion: configure correct netmask for your internal network
(such as, if you choose to be 64.1.1.1 with netmask 255.255.255.0, you
will only lose connectivity to 64.1.1.*, not entire 64.*)

-alex

2) I just sync'ed via cvsup at cvsup.postgresql.org and it deleted all
under pgsql/src/interfaces/odbc/*. It also does not seem to appear
anywhere else. What's up?

I see this too. I blew away my repository and populated it from scratch,
and still see the problem. In fact, the odbc directory doesn't even
appear in (my replicated) repository at all, let alone moving to the
attic.

Marc, can we verify that the ODBC directory actually exists in the
replicated cvs repository? Can we please get a site map to help us
navigate around to help diagnose problems?

myst$ cvsup -v
CVSup client, non-GUI version
Copyright 1996-2001 John D. Polstra
Software version: SNAP_16_1d
Protocol version: 16.1
Operating system: LINUXLIBC6
http://www.polstra.com/projects/freeware/CVSup/
Report problems to cvsup-bugs@polstra.com

and the server is running

Server software version: REL_16_1p3

This does *not* seem to be fresh enough. JDP recommends installing
REL_16_1e, and REL_16_1d was the first with bug fixes for the time tag
problem. Not sure what REL_16_1p3 is, but it does not seem to be in the
same line of fixed code (maybe a preliminary or patch release from
sometime in the past??).

Marc, help!! Check http://people.freebsd.org/~jdp/s1g/ for details on
the bug and FreeBSD package files which fix it.

- Thomas

Fixed ... my exclude file had a rule in it that prevented odbc from being
rsync'd down ... all should be downloaded now ...

as for a 'sitemap', the server that all of this is on is meant to be
purelya 'mirror' of the central one on mail.postgresql.org, except there
are no accounts on the machine for you to go looking around it with ...

as for a sitemap of the central site ... all the web related stuff is in
/usr/local/www, and cvsroot is /cvsroot ...

On Sat, 22 Sep 2001, Thomas Lockhart wrote:

Thanks Marc !

I just cvsup'ed and odbc seems to be all back.

Thanks !

Best regards,

.. Otto

Otto Hirr
OLAB Inc
503.617.6595
otto.hirr@olabinc.com

Fixed ... my exclude file had a rule in it that prevented odbc from being
rsync'd down ... all should be downloaded now ...

Great! Haven't tested it yet, but Otto is happy so I'm sure I'll be
too...

Server software version: REL_16_1p3
This does *not* seem to be fresh enough. JDP recommends installing
REL_16_1e, and REL_16_1d was the first with bug fixes for the time tag
problem. Not sure what REL_16_1p3 is, but it does not seem to be in the
same line of fixed code (maybe a preliminary or patch release from
sometime in the past??).

What about the server versioning issue? I see no mention of
REL_16_1p<anything> as being safe to use. Please confirm that this is in
fact the 16_1d or 16_1e release!!

- Thomas

On Sat, 22 Sep 2001, Thomas Lockhart wrote:

Fixed ... my exclude file had a rule in it that prevented odbc from being
rsync'd down ... all should be downloaded now ...

Great! Haven't tested it yet, but Otto is happy so I'm sure I'll be
too...

Server software version: REL_16_1p3
This does *not* seem to be fresh enough. JDP recommends installing
REL_16_1e, and REL_16_1d was the first with bug fixes for the time tag
problem. Not sure what REL_16_1p3 is, but it does not seem to be in the
same line of fixed code (maybe a preliminary or patch release from
sometime in the past??).

What about the server versioning issue? I see no mention of
REL_16_1p<anything> as being safe to use. Please confirm that this is in
fact the 16_1d or 16_1e release!!

This is what is/was latest in ports after you mentioned the problem ...
I'll check ports again over the next day or so to see if John has oploaded
something even newer ....

What about the server versioning issue? I see no mention of
REL_16_1p<anything> as being safe to use. Please confirm that this is in
fact the 16_1d or 16_1e release!!

This is what is/was latest in ports after you mentioned the problem ...
I'll check ports again over the next day or so to see if John has oploaded
something even newer ....

Ack! That's the whole point! This is a critical bug fix for which John
Polstra has posted the required binaries, including for FreeBSD. If it
isn't the right version, we get time-corrupted CVS repositories. The URL
is http://people.freebsd.org/~jdp/s1g/ and for all I know that is the
only source of packages which contain the fixes. If it isn't the right
package, it doesn't fix the problem.

I'd really like this so that I can finish the date/time improvements for
the beta freeze.

- Thomas

Please confirm that this is in
fact the 16_1d or 16_1e release!!

Thank you thank you thank you!!! I see that 16_1e is now installed on
the server, and the world is good again.

I'm about done with extensive patches on date/time support, though I
think I won't be ready to commit them before I leave town for work. I
*should* be able to commit things remotely, and expect to do so Thursday
or Friday after merging with the current cvs tree.

Thanks again for updating the server.

- Thomas

ps. Thank you