Re: 1.6.0a3 Denying repeated connection and Copy type

[Alan Sparks]

Solaris 2.7, you say?  Wow, I had problems there.  Very
similar problems... files copying when they hadn't been
touched...

Mark released (is releasing?) version 1.6.3, which he
mentioned to me had patches intended for Tru64 UNIX... had
to do with 64bit problems interpreting timestamps.  Don;t
know why, but that version cleared up the problems for me.
Perhaps because of 64bit Solaris?  Dunno.

I also had some problems w/ cfd, with it failing host auth
when the cfd.conf file changed.  Guess Mark tracked it down
to a threading issue, and gave me a copy that sequenced
things better when the file is reloading.  Fixed that
problem too.  Don't know if Mark will be releasing that
fixed cfd soon...

Definitely look into 1.6.3.  Downside is you need to upgrade
your Berkeley DB stuff to 3.x to compile (if you want the db
support).  Upside is it may very well solve your problem.
-Alan


On Mon, 12 Mar 2001 15:56:27 -0800
 Jerry Christopher <jchristo@amcc.com> wrote:
> I have been searching gnu.cfengine.help for someone with
> a similar
> problem, but now I turn to the list...
> 
> Using cfengine 1.6.0a3 on the server and client, Solaris
> 2.7 on both.
> 
> We were getting the following in /var/adm/messages on the
> server:
> 
> Mar 11 07:45:32 gold gold[11705]: Denying repeated
> connection from
> 10.101.101.25
> Mar 11 11:45:31 gold gold[11705]: Denying repeated
> connection from
> 10.101.101.25
> Mar 11 14:45:29 gold gold[11705]: Denying repeated
> connection from
> 10.101.101.25
> 
> The log messages coincide with 8:45, 12:45, and 15:45
> cron entries on
> the client which resides one timezone away.  The
> cfengine.log on the
> client shows the denied connection from the server.  So
> these runs go
> across the WAN.  We determined the link does not have the
> bandwidth for
> all the updates that were going across.  Several hundred
> Mb were being
> transferred and the current run was not finishing before
> the next
> started.
> 
> Further investigation showed that files that were up to
> date on the
> client were being transferred each day.  I'd look at our
> cfengine.log
> and see that the 8:45 client run "updated images" for
> files that
> definitely haven't been changed on the server in months.
> I commented
> the cron entries and let this run to completion -
> sometime after 12:45,
> but before 15:45.  After the 15:45 run, the log shows the
> files not
> being updated as we would expect.   In the morning, 8:45,
> the "updating
> images" for the exact same files happens again and
> several hundred Mb
> are started for copying across the WAN.
> 
> >From the cfengine reference, I read that cfengine uses
> the ctime
> date-stamps on files to determine whether a file needs to
> be copied: a
> file is only copied if the master is newer than the copy
> of if the copy
> doesn't exist. Here is one copy statement intended to
> copy the trees
> beneath /distrib/desktop to / on each client. 
> 
>         /distrib/desktop
>                 dest=/
>                 server=$(MYDISTRIB)
>                 backup=false
>                 recurse=inf
> 
> 
> >From what I've been reading in the newsgroup, should we
> be using
> type=checksum or byte rather than the default of ctime?  
> 
> We want the client to get any file changed on the master,
> plus the
> client should be updated if it's copy differs from the
> master.  Sounds
> like checksum is what we are after.  If you are using
> type=checksum or
> byte, can you please comment briefly on performance over
> the default of
> ctime?
> 
> 
> Thank you for your time,
> 
> Jerry Christopher
> Applied Micro Circuits Corp.
> 6290 Sequence Dr
> San Diego, CA 92121
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine