[rt-users] CPU is going wild

[Marcus Pauli]

Hello *,

after managing to authenticate against LDAP, I faced another issue:
After logging in, the CPU gets extremely occupied. As the System is a
Dual Intel(R) Pentium(R) 4 CPU 2.80GHz I don't think, that this
behaviour is normal. :-)

BTW: The problem occurs with both mod_perl and fastcgi.

Apache is 2.0.58-r2, mod_perl is 2.0.3-r2, perl is 5.8.8, linux is
2.6.17-gentoo

Here's what RT's log is telling me (I can't find anything suspicious)

---8<---
Jan 19 17:53:02 ganymed RT: Working around bug in RT and reloading
RT::User
(/var/www/myhost/rt-3.8.2/local/plugins/RT-Authen-ExternalAuth/html/Callbacks/ExternalAuth/autohandler/Auth:12)
Jan 19 17:53:02 ganymed
Log::Dispatch::__ANON__('Log::Dispatch=HASH(0xfc8ab88)', 'Working around
bug in RT and reloading RT::User') called at
/var/www/myhost/rt-3.8.2/local/plugins/RT-Authen-ExternalAuth/html/Callbacks/ExternalAuth/autohandler/Auth
line 12
Jan 19 17:53:02 ganymed
RT::Interface::Web::Request::callback('RT::Interface::Web::Request=HASH(0xfeb72f4)',
'CallbackName', 'Auth') called at /var/www/myhost/htdocs/autohandler
line 256
Jan 19 17:53:02 ganymed
HTML::Mason::Request::exec('RT::Interface::Web::Request=HASH(0xfeb72f4)')
called at /usr/lib/perl5/vendor_perl/5.8.8/HTML/Mason/ApacheHandler.pm
line 168
Jan 19 17:53:02 ganymed
HTML::Mason::Request::ApacheHandler::exec('RT::Interface::Web::Request=HASH(0xfeb72f4)')
called at /usr/lib/perl5/vendor_perl/5.8.8/HTML/Mason/ApacheHandler.pm
line 826
HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x912a20c)',
'Apache2::RequestRec=SCALAR(0xe580080)') called at
/var/www/myhost/rt-3.8.2/bin/webmux.pl line 149 eval {...} at
/var/www/myhost/rt-3.8.2/bin/webmux.pl line 149
RT::Mason::handler('Apache2::RequestRec=SCALAR(0xe580080)') called at -e
line 0 eval {...} at -e line 0
--->8---

---8<---
package RT;
use RT::Config;

Set($rtname , "myhost");
Set($EmailSubjectTagRegex, qr/\Q$rtname\E/i );
Set($Organization , "myhost");
Set($MinimumPasswordLength , "0");
Set($Timezone , 'Europe/Berlin');

Set($DatabaseType , 'mysql');
Set($DatabaseHost   , '');
Set($DatabaseRTHost , '');
Set($DatabasePort , '');
Set($DatabaseUser , 'tasks');
Set($DatabasePassword , 'myhost');
Set($DatabaseName , 'tasks');
Set($UseSQLForACLChecks, '1');

Set($RTAddressRegexp , '^rt\@lessrain.net$');

Set($CanonicalizeOnCreate, 0);

Set($MailCommand , 'smtp');

Set($SMTPServer, 'mail.lessrain.net');
Set($SMTPDebug, 1);

Set( @Plugins, qw(RT::Authen::ExternalAuth) );

# The order in which the services defined in ExternalSettings
# should be used to authenticate users. User is authenticated
# if successfully confirmed by any service - no more services
# are checked.
Set($ExternalAuthPriority,  [ 'less rain ldap' ]);

# The order in which the services defined in ExternalSettings
# should be used to get information about users. This includes
# RealName, Tel numbers etc, but also whether or not the user
# should be considered disabled.
# Once user info is found, no more services are checked.
Set($ExternalInfoPriority,  [ 'less rain ldap' ]);

# If this is set to true, then the relevant packages will
# be loaded to use SSL/TLS connections. At the moment,
# this just means "use Net::SSLeay;"
Set($ExternalServiceUsesSSLorTLS,    0);

# If this is set to 1, then users should be autocreated by RT
# as internal users if they fail to authenticate from an
# external service.
Set($AutoCreateNonExternalUsers,   0 );
###Set($AutoCreate, {Privileged => 1});
# These are the full settings for each external service as a HashOfHashes
# Note that you may have as many external services as you wish. They will
# be checked in the order specified in the Priority directives above.
# e.g.
#   Set(ExternalAuthPriority,['less rain
ldap','My_MySQL','My_Oracle','SecondaryLDAP','Other-DB']);
#


Set($ExternalSettings,     
    {  
    'less rain ldap'       =>  {   ## GENERIC SECTION
       # The type of service (db/ldap/cookie)
      'type'                      =>  'ldap',
      # Should the service be used for authentication?
      'auth'                      =>  1,
      # Should the service be used for information?
      'info'                      =>  1,
      # The server hosting the service
      'server'                    =>  'localhost',
      ## SERVICE-SPECIFIC SECTION
      # If you can bind to your LDAP server anonymously you should
      # remove the user and pass config lines, otherwise specify them here:
      #
      # The username RT should use to connect to the LDAP server
      'user'                      =>  'username',
      # The password RT should use to connect to the LDAP server
      'pass'                    =>  'password',
      #
      # The LDAP search base
      'base'                      =>  'ou=People,...',
      #
      # ALL FILTERS MUST BE VALID LDAP FILTERS ENCASED IN PARENTHESES!
      # YOU **MUST** SPECIFY A filter AND A d_filter!!
      #
      # The filter to use to match RT-Users
      'filter'                    => 
'(|(siczbService=all)(siczbService=tasks))',
      # A catch-all example filter: '(objectClass=*)'
      #
      # The filter that will only match disabled users
      'd_filter'                  =>  '(siczbService=none)',
      # A catch-none example d_filter: '(objectClass=FooBarBaz)'
      #
      # Should we try to use TLS to encrypt connections?
      'tls'                       =>  0,
      # What other args should I pass to Net::LDAP->new($host, at args)?
      'net_ldap_args'             => [    version =>  3   ],

      ## RT ATTRIBUTE MATCHING SECTION
      # The list of RT attributes that uniquely identify a user
                            # This example shows what you *can*
specify.. I recommend reducing this
      # to just the Name and EmailAddress to save encountering problems
later.
      'attr_match_list'           => [    'Name'
                                      ],
      # The mapping of RT attributes on to LDAP attributes
      'attr_map'                  =>  {   'ExternalAuthId' => 'uid',
                                                        'Name' => 'uid',
                                          'EmailAddress' => 'mail',
                                          'Organization' => 'o',
                                          'RealName' => 'displayName',
                                          'WorkPhone' => 'telephoneNumber',
                                          'Address1' => 'street',
                                          'City' => 'l',
                                          'State' => 'st',
                                          'Zip' => 'postalCode',
                                          'Country' => 'c',
                                                        'Password' =>
'userPassword'
                                      }
          }
   }
);

=head1 Logging Configuration

The default is to log anything except debugging
information to syslog.  Check the L<Log::Dispatch> POD for
information about how to get things by syslog, mail or anything
else, get debugging info in the log, etc.

It might generally make sense to send error and higher by email to
some administrator.  If you do this, be careful that this email
isn't sent to this RT instance.  Mail loops will generate a critical
log message.

=over 4

=item C<$LogToSyslog>, C<$LogToScreen>

The minimum level error that will be logged to the specific device.
>From lowest to highest priority, the levels are:
 debug info notice warning error critical alert emergency

=cut

Set($LogToSyslog    , 'debug');
Set($LogToScreen    , 'critical');

=item C<$LogToFile>, C<$LogDir>, C<$LogToFileNamed>

Logging to a standalone file is also possible, but note that the
file should needs to both exist and be writable by all direct users
of the RT API.  This generally include the web server, whoever
rt-crontool runs as.  Note that as rt-mailgate and the RT CLI go
through the webserver, so their users do not need to have write
permissions to this file. If you expect to have multiple users of
the direct API, Best Practical recommends using syslog instead of
direct file logging.

=cut

Set($LogToFile      , "1");
Set($LogDir, '//var/www/myhost/rt-3.8.2/var/log');
Set($LogToFileNamed , "rt.log");    #log to rt.log

=item C<$LogStackTraces>

If set to a log level then logging will include stack
traces for messages with level equal to or greater than
specified.

=cut

Set($LogStackTraces, 'debug');

=item C<@LogToSyslogConf>

On Solaris or UnixWare, set to ( socket => 'inet' ).  Options here
override any other options RT passes to L<Log::Dispatch::Syslog>.
Other interesting flags include facility and logopt.  (See the
L<Log::Dispatch::Syslog> documentation for more information.)  (Maybe
ident too, if you have multiple RT installations.)

=cut

Set(@LogToSyslogConf, ());

=item C<$StatementLog>,

RT has rudimentary SQL statement logging support if you have
DBIx-SearchBuilder 1.31_1 or higher; simply set C<$StatementLog> to be
the level that you wish SQL statements to be logged at.

=cut

Set($StatementLog, undef);

=back
Set($DevelMode, "1");

1;
--->8---

What did I do wrong?

cheers

marcus

-- 
Less Rain GmbH
Linienstr. 154A
10115 Berlin
Germany

T +49 30 2809 5020
F +49 30 2809 5023

www.lessrain.de
blog.lessrain.com


Latest projects:
www.redbull.com/flightlab
www.stofanel.com
www.redbull.com/#page=MediaSectionPage
www.uliheckmann.de
www.haunchofvenison.com