Re: 1.12.5 pserver /var/adm/messages

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mark,

Mark <[email protected]> writes:

> It happens consistently on the hour and half hour. So I am 
> guessing its a cvs client cronjob from somewhere. I checked the 
> /var/adm/messages logs for the past few weeks on that server and 
> there are no such entries to be found prior to the upgrade of 
> server from 1.11.1p1 to 1.12.5. Since I have a dedicated 
> filesystem for pserver tmp directory (-T in inetd.conf, now 
> using --with-tmp in configure), I would have noticed the 
> cvs-serv* directories bulding up in the tmp filesystem, so my 
> guess is that the infinite loop core dump thing was fixed prior 
> to 1.11.1p1. Which leaves the question as to why these messages 
> are being generated with the 1.12.5 pserver?

I am not sure. The broken pipe error message should mean that the tcp
connection between the client and the server was broken. How it was
broken is harder to guess... :-(

> Are there any backward compatibility issues with 1.12.5 pserver 
> to older clients?

There are not supposed to be any, but there are a few options that have
been introduced since 1.11.1p1 such as needing the -B flag in the tag
and rtag commands for moving or deleting a branch tag. However, old
clients should get a warning message about the problem. Old clients will
also get a warning message if they do something like a 'cvs -n diff' in
that the old clients would pass the now obsolete -l flag which sends a
warning back to the client about an obsolete flag.

> Also, we got about 18 of the following in the /var/adm/messages 
> as well today, again starting with the 1.12.5 upgrade.... no 
> time pattern to these entries.....
> 
> messages:Dec 30 09:29:14 batman cvs[12093]: [ID 666953 
> daemon.notice] bad auth protocol start: EOF
> messages:Dec 30 09:32:42 batman cvs[13517]: [ID 666953 
> daemon.notice] bad auth protocol start: EOF

Well, bad auth protocol is at least a different message...

> What would really help is having the cvs username (I use a 
> non-root pserver) and the client machine/IP in the messages log 
> for these errors. Hopefully a user and/or machine pattern will 
> show up.
> 
>  From the looks of it, I should be able to use CVS_Username in 
> main.c and add about another %s for CVS_Username variable to 
> that error call.

Yes.

> How would I print out the machine name/ip address of the client? 

Hmmm... tricky. We don't have that information around anywhere. I
suppose a hack to pserver_authenticate_connection to call getsockname()
on stdin (fd=0) might do the trick for you. I have not tried it myself.

Failing that, you could put the tcp_wrapper code around it in your
inetd.conf file and have the connection logged to syslog too.

> Is it anywhere in the code (what I am afraid of is the account 
> will end up to being the readonly anon account projects use for 
> shared build/staging areas and website cron updates...)
> 
> Any ideas on how these /var/adm/messages came into play on the 
> pserver upgrade?

Not really. I don't recall any changes other than the reorganization of
the error path that allows things to fail more cleanly now.

I don't use pserver myself for anything (I do not trust it
for any kind of authentication). Larry might know more. Or, Derek will
be back on-line next week...

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

iD8DBQE/8k0/3x41pRYZE/gRAujFAKCIst44Wwyc3hlnCwKEbyuqlsrMJACfR+ca
fVg3cY7yIaXv33IMxR8j9nY=
=Brpx
-----END PGP SIGNATURE-----