On Wed, Mar 14, Ivan Sagalaev wrote: > I've just recalled a case... I was using Django's randomly generated > passwords and it worked fine under mod_python. Then I switched to > FastCGI and from some moment *all* passwords started being generated > absolutely equal. The thing was that mod_python was reloaded from time > to time by Apache (using MaxRequestsPerChild) and flup-based FastCGI > were never reloaded. Over long time Python's random generator just > degenerated into giving out exact values (this was Python 2.4 on Debian).
Fascinating. `manage.py runfcgi` now has a parameter `maxrequests`, so you can force it to restart, too. In python 2.3, the random generator seems to be seeded at the time when the module `random` is imported for the first time. I suspect that when all the Apache child processes are forked, that it's possible that a few get seeded with the same system time. Same for fastcgi. Beginning with python2.4, the seed also uses os.urandom() when available, so it starts to get safer. How about this: We could fix this for python 2.3 by seeding the random generator on django startup using the random function of the database together with urandom (when available) and the system time. I'm not sure whether it's a good idea to add periodic reseeding. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
