manage syncdb (first time) in a small chrooted environment for example don't give defaultuser...

[ClaesBas]

What a about this patch?

Index: django/contrib/auth/create_superuser.py
===================================================================
--- django/contrib/auth/create_superuser.py     (revision 6507)
+++ django/contrib/auth/create_superuser.py     (working copy)
@@ -22,7 +22,10 @@
         default_username = ''
     else:
         # Determine the current system user's username, to use as a default.
-        default_username = pwd.getpwuid(os.getuid())[0].replace(' ', '').lower()
+        try:
+            default_username = pwd.getpwuid(os.getuid())[0].replace(' ', '').lower()
+        except KeyError:
+            default_username = 'admin'
 
     # Determine whether the default username is taken, so we don't display
     # it as an option.

[Malcolm Tredinnick]

[For other readers wondering what this is about: if you have a really minimal environ with no auth support, then getuid() may fail to return a username. This usually means you need at least /etc/passwd.]

I would think there's going to be a fair bit of stuff that will cause problems if there's no /etc/passwd or other way for things like getuid() to work, so you're not really solving the root problem here. Still, it's probably a relatively harmless fix, but it needs a comment about why it can fail.

I'd probably prefer that we just didn't display a default username in this case, too, if we go down this path.

In future, please give an explanation of what you're trying to fix. I've had enough experience with setting up chroot environments to recognise the problem, but not everybody is going to have been that unlucky in the past and you really are talking about a far-out edge case here.

[Malcolm Tredinnick]

(In [9158]) Fixed #5753 -- Allow createsuperuser to work in situations where there
might be a valid password database entry for the current user id.

[Malcolm Tredinnick]

(In [9159]) [1.0.X] Fixed #5753 -- Allow createsuperuser to work in situations where there
might be a valid password database entry for the current user id.

Backport of r9158 from trunk.

[Malcolm Tredinnick]

Since there are situations where normal usage or Django (using "createsuperuser") could lead to a crash before this change, I decided to also commit it on the branch. If it causes any trouble, though, we could safely remove it from there. It's pretty borderline, as indicated in my first comment on this ticket.