Re: current 0.9.4

On Fri, 2002-02-01 at 16:18, Rob Hagopian wrote:
> Works great for me, thanks as always :-)
> 
> FYI, I've been watching our server during some mass simultaneous updates,
> current is rarely the bottleneck, but stunnel cranks away during the data
> xfers... the pitfalls of encryption... on the other hand, that works to my
> benefit as I can have tons of clients updating all at once but it won't
> overload the server (as long as the clients don't time out)...

Being a single threaded daemon, I am _amazed_ at your success with it.
:)

 
> The only thing that still causes communications to blow up that I've seen is
> missynchronized clocks... both server/client print out unhelpful error
> messages (I believe this is the server one):
> 
> requesthandler.log_error(): code 400, message Bad request syntax ("GET
> https://x2hvd.directhit.com/XMLRPC/$RHN/{'X-RHN-Auth-Channels':
> [['dh-i386-7.2', '20020131160604']], 'X-RHN-Server-Id': 'x2hvd',
> 'X-RHN-Auth-Expiration': '1012496874', 'X-RHN-Auth':
> '3ce67ebbf54a383b43684c5aa482633ddfca0c22', 'X-RHN-Auth-User-Id':
> 'dhinternal'}/set_headers HTTP/1.0")
> /usr/share/current/standalone.py:do_POST(None)

I believe set_headers() to be a bug in 2.7.x up2date clients. Its
triggered by clocks wildly out of sync, as you found. 

set_headers() looks like it should be a non-network related call, but it
hits the server, which I beleive to be the bug. 

Being (I believe) to be a client side bug, there's not much I can do
about it, except to say make sure your clocks are all the same +/- 5
minutes. (They have to be off by more than 50 minutes to trigger this)

Both rdate and ntp solve this problem. rdate is simpler to setup, ntp
works better in the long run.

 
> (Then the client dies not knowing what to do with the None)

Actually, the server is near-death trying to deal with that mucked up
request from the client. Its just bogus say I.

 Also, just a side question, but did you consider using berkeley db (well,
> sleepycat now) instead of a full blown sql backend for the future
> implementations? Does it not provide the features you need?

We use shelves now, which are actually built on top of db. And no, it
really doesn't provide the features we need. The problem is best
exhibited when you try to code up full client support, which for deletes
requires single row (entry) to be VERY long, containing the keys of all
the packages installed on a client. 

With sql, you can simply have 1500 rows per client, and then do a query
of 
SELECT * WHERE client = foo.biology.duke.edu blah blah blah.

There are some other areas, including dependancies, where db _works_ but
is fairly painful to program.

-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.