Carsten,
I have them both:
% echo $USER
root
% echo $LOGNAME
root
Jovan
From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org]
On Behalf Of Carsten Grzemba
Sent: Tuesday, January 29, 2013 5:39 PM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] setup-ds-admin.pl failure
The problem is that the scripts use a env variable USER which is commonly not set in Solaris (there is LOGNAME common). It try to work arround this by setting this in:
/etc/opt/csw/default/dirsrv
So I guess if USER not set will the perl function (DSutil.pm)
sub getLogin {
return (getpwuid($>))[0] || $ENV{USER} || confess "Error: could not determine the current user ID: $!";
}
not work and than the function (DSCreate.pm)
sub get_initconfigdir {
# determine initconfig_dir
if (getLogin eq 'root') {
return "/etc/opt/csw/default";
} else {
return "$ENV{HOME}/.dirsrv";
}
}
also not return the correct value. I will fix this tomorrow.
~Carsten
Am 29.01.13 schrieb Jovan.VUKOTIC@sungard.com:
|
I have attempted to install1.2.10.7 version of the server: % pkgutil -c CSW389-ds-base package installed catalog CSW389-ds-base 1.2.10.7,REV=2012.05.02 SAME On Solaris, configuration directory for opencsw packages are at
/etc/opt/csw In particular, for DS, all instances are at /etc/opt/csw/dirsrv/ The strange thing is that for the given instance, the setup script did create
/etc/opt/csw/dirsrv/slapd-instance-name
directory even after the failure I described, as well as all the directories under
/var/opt/csw/lib /var/opt/csw/lock /var/opt/csw/log I really do not know why it is looking in root’s home for dirsrv-instance-name Thanks, From: 389-users-bounces@lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Carsten Grzemba Hi,
|
--
Carsten Grzemba
Tel.: +49 3677 64740
Mobil: +49 171 9749479
Fax: +49 3677 6474111
Email: carsten.grzemba@contac-dt.de
contac Datentechnik GmbH