#422 389-ds-base - Can't call method "getText"
Closed: Fixed None Opened 7 years ago by rmeggins.

https://bugzilla.redhat.com/show_bug.cgi?id=827572 (Fedora)

Description of problem:

Falla el setup Express (2)

Are you ready to set up your servers? [yes]:
Creating directory server . . .
Can't call method "getText" on an undefined value at
/usr/lib64/dirsrv/perl/DSUtil.pm line 232, <STDIN> line 14.


Version-Release number of selected component (if applicable):
389-admin-1.1.29-1.fc17.x86_64

How reproducible:
always

Steps to Reproduce:
1. run setup-ds-admin.pl
2. Select Express setup

set default ticket origin to Community

Added initial screened field value.

I tried to duplicate the problem, but I could not.

Based upon the bug report:

Can't call method "getText" on an undefined value at
/usr/lib64/dirsrv/perl/DSUtil.pm line 232, <stdin> line 14.

Line 232 is for 'warning_no_such_hostname'.
231 if ($err) {
232 return $res->getText('warning_no_such_hostname', $hn);
233 }

In setup-ds.res,
warning_no_such_hostname = Could not find an address for hostname '%s'.\n

My build is from 1.3.0, and I tested it on f17.
I ran setup-ds-admin.pl -s -f /path/to/inffile.
And the error message is printed as expected...
WARNING: There are problems with the hostname.
Could not find an address for hostname '<...>'.

The error message means that $res is not set (that it is undefined). I guess the next step would be to see where checkHostname is called, and how/why $res could be unset in those places. I see this:

DSCreate.pm.in:153
{{{
my $str = checkHostname($inf->{General}->{FullMachineName});
}}}
This does not have the $res parameter.

Updating the summary since this is not a bug in 389-admin, but in the admin script in 389-ds-base.

Bug description: If a hostname which has no corresponding IP
address associated is given to the setup-ds-admin.pl or
setup-ds.pl (e.g., bogus.bogus.bogus.com), then DSUtil.pm
complains with "Can't call method "getText" on an undefined
value".

Fix description: There were 2 missing checks in perl subroutine
checkHostname in DSUtil.pm whether the dialog resource is given
or not.

This is a bit tricky, because checkHostname is called from two completely different contexts. When called from SetupDialogs, it will have a $res that can call getText to get a localized string. But when called from sanityCheckParams, there is no $res. It should instead return a list that will eventually be used with getText. For example, we should really do something like this:
{{{
...
if ($res) {
return $res->getText('warning_hostname_not_fully_qualified', $hn);
} else {
return ('warning_hostname_not_fully_qualified', $hn);
}
...
if ($err) {
if ($res) {
return $res->getText('warning_no_such_hostname', $hn);
} else {
return ('warning_no_such_hostname', $hn);
}
}
...
}}}
etc. If $res, return a string returned by $res->getText, otherwise, return a list that will eventually be passed to $res->getText at a higher level.

This also means sanityCheckParams will need to change:
{{{
if (@errs = checkHostname($inf->{General}->{FullMachineName}, 0)) {
debug(1, @errs);
return @errs;
}

return ();

}}}

Bug description: If a hostname which has no corresponding IP
address associated is given to the setup-ds-admin.pl or
setup-ds.pl (e.g., bogus.bogus.bogus.com), then DSUtil.pm
complains with "Can't call method "getText" on an undefined
value".

Fix description: Thanks to Rich for his comments. Following
his suggestions, this patch prepares 2 different return types
in checkHostname depending upon the existence of the resource
object. If the resource is given, the subroutine returns the
error message. Otherwise, it returns the array of error message.

Reviewed by Rich and Mark (Thank you!!!)

Pushed to master: commit d8cdb35

To ssh://git.fedorahosted.org/git/389/ds.git
63274be..87a069c 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 87a069c
Author: Noriko Hosoi nhosoi@redhat.com
Date: Fri Dec 21 10:31:24 2012 -0800
aa19f9a..82a50df 389-ds-base-1.3.0 -> 389-ds-base-1.3.0
commit 82a50df
Author: Noriko Hosoi nhosoi@redhat.com
Date: Fri Dec 21 10:31:24 2012 -0800

Metadata Update from @rmeggins:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.1

2 years ago

Login to comment on this ticket.

Metadata