Create account / Log in
Bug 4091 - Brent's name keeps getting set to "unknown" in Bugzilla
: Brent's name keeps getting set to "unknown" in Bugzilla
Status: RESOLVED FIXED
Product: Website
Classification: Website
Component: Tracker
: unspecified
: PC Linux
: high normal
: ---
Assigned To: Joel Uckelman
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-27 12:47 CEST by Joel Uckelman
Modified: 2012-07-25 04:16 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joel Uckelman 2011-10-27 12:47:45 CEST
No idea why this is happening. Must investigate.
Comment 1 Jon Test 2011-11-04 00:12:40 CET
Hi all. What's the version of the Bugzilla we're using?

Also, did you try a manual write into the database?
Comment 2 Joel Uckelman 2011-11-07 14:24:03 CET
(In reply to comment #1)
> Hi all. What's the version of the Bugzilla we're using?
> 

3.6.6
 
> Also, did you try a manual write into the database?

Yes. When I do that, Brent's name shows up properly until the next time Brent logs in.
Comment 3 Jon Test 2011-11-07 21:32:38 CET
(In reply to comment #2)
> 3.6.6
Ok. I looked at the source code.

> > Also, did you try a manual write into the database?
> 
> Yes. When I do that, Brent's name shows up properly until the next time Brent
> logs in.
I ran through the login code and check for when it links to "unknown". Seems something else (not login code) is causing this problem.

A few more questions.

Which DB field did you update? Is it profiles.realname?

After Brent logs in, are those fields re-updated (reverted)? Which means you'll see the value "unknown" in the fields concerned? Between user.html.tmpl and User.pm, I'd say there definitely is a value "unknown" written directly into Brent's "profiles.realname" record.

Is "b.easton@exemail.com.au" in DB field logincookies.userid?

Are you using LDAP? Did you activate LDAP user sync operations? The operations are in bugzilla_ldapsync.rb and syncLDAP.pl . Does it have anything to do with this: https://bugzilla.mozilla.org/show_bug.cgi?id=201069

I've scanned all the codes (without debugging). Nowhere can I see any update to profiles.realname upon login. One possibility could be that someone else has Brent's password, and is constantly changing his realname to "unknown".

A few things I need you to do:
- Duplicate the tracker wholesale, codes and DB
- In the duplicate...
  - delete everything except 1 bug
  - delete all users except admin and Brent
  - change any personal info you don't want me to see
- Send that duplicate to me.

Can you do that?
Comment 4 Jon Test 2011-11-07 21:33:56 CET
(In reply to comment #2)
Oh, and lastly, do a SHA1 checksum to confirm that no 3.3.6 codes were changed?
Comment 5 Joel Uckelman 2011-11-09 15:53:32 CET
(In reply to comment #3)
> 
> Which DB field did you update? Is it profiles.realname?

Yes, profile.realname.

> After Brent logs in, are those fields re-updated (reverted)? Which means you'll
> see the value "unknown" in the fields concerned? Between user.html.tmpl and
> User.pm, I'd say there definitely is a value "unknown" written directly into
> Brent's "profiles.realname" record.

Yes, it's reset to "unknown" after Brent logs in.

> Is "b.easton@exemail.com.au" in DB field logincookies.userid?

No. logincookies.userid is a numeric field storing the same data as profiles.userid. (Brent has userid == 2.)
 
> Are you using LDAP? Did you activate LDAP user sync operations? The operations
> are in bugzilla_ldapsync.rb and syncLDAP.pl . 

Yes, we're using LDAP. I don't see why we would need to use either of those scripts. I thought I had Bugzilla set to automatically create accounts on login for users appearing in LDAP.

> Does it have anything to do with
> this: https://bugzilla.mozilla.org/show_bug.cgi?id=201069

I think this is unrelated. Brent has logged in many times before.

> I've scanned all the codes (without debugging). Nowhere can I see any update to
> profiles.realname upon login. One possibility could be that someone else has
> Brent's password, and is constantly changing his realname to "unknown".

I think this is unlikely. Brent and I were in the IRC channel testing this shortly before I added the bug. An attacker would have to have been monitoring the channel in order to reset Brent's account at the right times.

> A few things I need you to do:
> - Duplicate the tracker wholesale, codes and DB
> - In the duplicate...
>   - delete everything except 1 bug
>   - delete all users except admin and Brent
>   - change any personal info you don't want me to see
> - Send that duplicate to me.
> 
> Can you do that?

I won't be able to do this until tomorrow at the earliest.
Comment 6 Joel Uckelman 2011-11-09 15:56:44 CET
(In reply to comment #4)
> (In reply to comment #2)
> Oh, and lastly, do a SHA1 checksum to confirm that no 3.3.6 codes were changed?

Which files would you like me to checksum?
Comment 7 Jon Test 2011-11-09 20:47:46 CET
(In reply to comment #6)
> Which files would you like me to checksum?
Possibly the whole of 3.6.6 build? Try http://sourceforge.net/projects/fsumfe/

Actually, the first thing to check is that no files were changed. Just do a recursive md5sum will do, actually.
Comment 8 Joel Uckelman 2011-11-10 09:39:56 CET
(In reply to comment #7)
> (In reply to comment #6)
> > Which files would you like me to checksum?
> Possibly the whole of 3.6.6 build? Try http://sourceforge.net/projects/fsumfe/
> 
> Actually, the first thing to check is that no files were changed. Just do a
> recursive md5sum will do, actually.

I looked in the spec file for the SRPM, and found these two patches being applied:

--- bugzilla-3.6.5/Bugzilla/Install/Requirements.pm.orig        2011-01-24 23:05:19.000000000 +0100
+++ bugzilla-3.6.5/Bugzilla/Install/Requirements.pm     2011-05-01 18:06:34.000000000 +0200
@@ -483,7 +483,7 @@
     if ($output && $check_results->{any_missing} && !ON_WINDOWS
         && !$check_results->{hide_all}) 
     {
-        print install_string('install_all', { perl => $^X });
+        # print install_string('install_all', { perl => $^X });
     }
     if (!$check_results->{pass}) {
         print colored(install_string('installation_failed'), 'red') . "\n\n";
@@ -599,7 +599,7 @@
         $package = $module->{package};
     }
     else {
-        $command = "$^X install-module.pl \%s";
+        $command = "yum install \"perl(\%s)\"";
         # Non-Windows installations need to use module names, because
         # CPAN doesn't understand package names.
         $package = $module->{module};

--- bugzilla-3.6.6/Bugzilla/Constants.pm        2011-08-05 15:42:01.768441860 +0200
+++ bugzilla-3.6.6-rw/Bugzilla/Constants.pm     2011-08-05 15:44:50.342628808 +0200
@@ -539,18 +539,18 @@ sub bz_locations {
         'cgi_path'    => $libpath,
         'templatedir' => "$libpath/template",
         'project'     => $project,
-        'localconfig' => "$libpath/$localconfig",
-        'datadir'     => "$libpath/$datadir",
-        'attachdir'   => "$libpath/$datadir/attachments",
+        'localconfig' => "/etc/bugzilla/$localconfig",
+        'datadir'     => "/var/lib/bugzilla/$datadir",
+        'attachdir'   => "/var/lib/bugzilla/$datadir/attachments",
         'skinsdir'    => "$libpath/skins",
-        'graphsdir'   => "$libpath/graphs",
+        'graphsdir'   => "/var/lib/bugzilla/graphs",
         # $webdotdir must be in the web server's tree somewhere. Even if you use a 
         # local dot, we output images to there. Also, if $webdotdir is 
         # not relative to the bugzilla root directory, you'll need to 
         # change showdependencygraph.cgi to set image_url to the correct 
         # location.
         # The script should really generate these graphs directly...
-        'webdotdir'   => "$libpath/$datadir/webdot",
+        'webdotdir'   => "/var/lib/bugzilla/$datadir/webdot",
         'extensionsdir' => "$libpath/extensions",
     };
 }

Otherwise, the source is stock.
Comment 9 Joel Uckelman 2011-11-10 09:43:28 CET
Some things I've only realized now that I haven't mentioned before:

* Our template customizations are here:

http://vassalengine.git.sourceforge.net/git/gitweb.cgi?p=vassalengine/site-src;a=tree;f=bugzilla;h=7ea00b3318f5b6865d18893b3bbebf471ecde52a;hb=HEAD

* Login/logout takes place via the SSO system I built, not via the login/logout normally displayed by Bugzilla. The SSO code is here, in login.php, logout.php, and in the sso directory:

http://vassalengine.git.sourceforge.net/git/gitweb.cgi?p=vassalengine/site;a=tree
Comment 10 Joel Uckelman 2011-11-10 12:42:31 CET
(In reply to comment #3)
>
> A few things I need you to do:
> - Duplicate the tracker wholesale, codes and DB
> - In the duplicate...
>   - delete everything except 1 bug
>   - delete all users except admin and Brent
>   - change any personal info you don't want me to see
> - Send that duplicate to me.
> 
> Can you do that?

You just want a copy of the code and DB, not a working instance on another VM?
Comment 11 Jon Test 2011-11-10 22:34:08 CET
(In reply to comment #10)
Wait! Don't bother with duplicating your website yet. Sorry for my haphazard diagnoses.

Just a quick hopeful potshot here...

In Brent's LDAP account: username is what? displayName is what? cn is what?
Take a look at Bugzilla::Auth::Verify->create_or_update_user(), line 121:
if ($real_name && $user->name ne $real_name) {

(Logic goes like this. If LDAP's displayName or cn is not empty, AND Bugzilla's profiles.realname is not empty, then compare Bugzilla's profiles.realname with LDAP's displayName or cn. Compare with displayName if it is not empty, else compare with cn.)

Note that LDAP's displayName (or cn) always overwrites Bugzilla's profiles.realname.

And other potshots, just in case...

Did Brent logout first before you database-corrected his displayName? (I suppose so, since you said "problem occurs when he first logs in again"). Did Brent clear his browser cache before logging in again?

Did you try to:
1. Correct Brent's LDAP displayName and Bugzilla's profiles.realname.
2. Change Brent's password to something temporary.
3. Login witth Brent's account and temporary password?

And if the above all fail...

Can you try to update my LDAP account's displayName and cn, and see if my tracker display name changes? I'm gonna log out after this, so we can test for my re-login later.

Has modify.php tested to be working, including for the updating of "Real name" only (without typing in email address)? Did Brent try to update his own "Real name" via modify.php? Not that we need to correct modify.php now; personally I don't use it.

> > A few things I need you to do:
> > - Duplicate the tracker wholesale, codes and DB
> > - In the duplicate...
> > 
> > Can you do that?
> 
> You just want a copy of the code and DB, not a working instance on another VM?
Yikes, I just realized it's NOT merely Bugzilla. Yeah, if you can provide a VM, that'll be good. We can debug together. Easier for me to replicate the on-site issues too.

If no VM for me, I'll have to install OpenLDAP (for Windows) and all.

Seems unlikely the issue is in the SSO login. Thin wrapper only. I would check from Bugzilla's Bugzilla::Auth::Verify::LDAP. And then Bugzilla::Auth::Verify->create_or_update_user().

> I looked in the spec file for the SRPM, and found these two patches
> being applied
Those 2 patches don't seem like what we're looking for. Ok, so the Bugzilla files weren't hacked. Let's move on.

> Our template customizations are here
Unlikely too. I believe you only touched the "View" and not any logics. Still, I'll check this last.
Comment 12 Joel Uckelman 2012-07-24 15:33:50 CEST
Hmm. It looks like Brent's name is shown correctly now. I wonder if there was a bug in the previous version of Bugzilla we were using.

Brent, do you concur that it's working now?
Comment 13 Brent Easton 2012-07-24 17:38:55 CEST
I have had no problems in the week, it's looking good now.