Apache Directory Project - [Installer] Possible Bug - apacheds start fails because it cannot

Author

[Installer] Possible Bug - apacheds start fails because it cannot

Ole Ersoy

2007-05-13, 7:11 pm

This is interesting.

After installing a fresh RPM (And deleting the old files
manually)
if I try to start ADS as root using

/etc/init.d/apacheds start
I get an OK but the server just exits right
away.

I think the reason is this:

log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: apacheds-rolling.log (Permission denied)
at java.io.FileOutputStream.openAppend(Native Method)

So somehow it's not able to create the rolling log. I verified
this by looking in /usr/local/apacheds-1.5.0/
and there's no apacheds-rolling.log

However if I start the server like this:
/etc/init.d/apacheds debug

it starts fine.

I thought this was because it prints the log
to the screen so that it does not attempt to open it.
However it's also able to create the rolling log now.

I verified this. /usr/local/apacheds-1.5.0/apacheds-rolling.log
exists.

I'm surprised that only I'm getting this though. I'm running
Fedora 6 x86_64.

Cheers,
- Ole

Andrew C. Oliver

2007-05-14, 7:11 am

this is pretty simply caused by the RPM command running as root and then
the dir is owned by root...then if you start it as another user, that
user doesn't have permission (and shouldn't) to the dir.

If you install as root (with RPM you have to) you need to run as root or
the RPM needs to change permissions to a user which means it pretty much
has to create the user.

-Andy

Emmanuel Lecharny wrote:
> Hi Ole,
>
> can you fill a JIRA for this issue?
>
> Thanks !
>
> On 5/13/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>

Ole Ersoy

2007-05-14, 1:11 pm

Hey Emmanuel,

I think I found the cause.
I'll append this message to the JIRA you sent me.

The startup code (Shell script) for the
start argument to apacheds looks like this:

$DAEMON_HOME/apacheds \
-user $APACHEDS_USER \
-home $JAVA_HOME \
-Djava.io.tmpdir=$TMP_DIR \
-Dlog4j.configuration=file://$SERVER_HOME/conf/log4j.properties\
-Xms384m -Xmx384m \
-pidfile $PID_FILE \
-outfile $SERVER_HOME/var/log/apacheds-stdout.log \
-errfile $SERVER_HOME/var/log/apacheds-stderr.log \
-cp $CLASSPATH \
org.apache.directory.daemon.JsvcBootstrapper \
$APACHEDS_HOME start

And the debug looks like this:

$JAVA_HOME/bin/java\
-Dlog4j.configuration=file://$SERVER_HOME/conf/log4j.properties\
-Xms384m -Xmx384m \
-Dcom.sun.management.jmxremote \
-Xdebug -Xnoagent -Djava.compiler=NONE\
- Xrunjdwp:transport=dt_socket,server=y,su
spend=n,address=$DEBUG_PORT\
-jar $DAEMON_HOME/bootstrapper.jar \
$APACHEDS_HOME start
;;

*)
echo "Usage apacheds [start|stop|debug]"
exit 1;;

I looked in /etc/passwd and I don't have a user
called "apacheds". I need to look at the apacheds
script in more detail, but I'm assuming $APACHEDS_USER
refers to such a user. The RPM spec file should
have created this user when ADS was installed.
Also, all the files are still owned by root post
install, so the rpm spec file needs to change
over the ownership in the install section of the spec.

I'll be double checking all this when I finish up the installer work.

Anyways, I removed the -user option
from the shell script and
now I can start and stop fine.

Cheers,
- Ole

Emmanuel Lecharny wrote:
> Andy,
>
> I think you have missed something : Ole is starting the server *as
> root*. There is another issue, and we have to figure out what it is
>
> Ole, I have found a JIRA I filled weeks ago which has been closed :
> https://issues.apache.org/jira/browse/DIRSERVER-862
>
> Can you check if this is exactly the same problem you have, and if so
> repoen the issue ?
>
> Thanks !
>
> On 5/14/07, *Andrew C. Oliver* <acoliver-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org
> <mailto:acoliver-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org>> wrote:
>
> this is pretty simply caused by the RPM command running as root and then
> the dir is owned by root...then if you start it as another user, that
> user doesn't have permission (and shouldn't) to the dir.
>
> If you install as root (with RPM you have to) you need to run as root or
> the RPM needs to change permissions to a user which means it pretty much
> has to create the user.
>
> -Andy
>
> Emmanuel Lecharny wrote:
> <mailto:ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
> denied)
>
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>

Ole Ersoy

2007-05-14, 1:11 pm

Hi Andy,

Thanks for taking a shot. I think we found it, although
I have to review the spec again to validate it.

Cheers,
- Ole

Andrew C. Oliver wrote:
> this is pretty simply caused by the RPM command running as root and then
> the dir is owned by root...then if you start it as another user, that
> user doesn't have permission (and shouldn't) to the dir.
>
> If you install as root (with RPM you have to) you need to run as root or
> the RPM needs to change permissions to a user which means it pretty much
> has to create the user.
>
> -Andy
>
> Emmanuel Lecharny wrote:
>
>

Andrew C. Oliver

2007-05-14, 1:11 pm

oh. My bad. I run Ubuntu. I only got something like that when I
accidentally picked the wrong session window.

-Andy

Emmanuel Lecharny wrote:
> Andy,
>
> I think you have missed something : Ole is starting the server *as root*.
> There is another issue, and we have to figure out what it is
>
> Ole, I have found a JIRA I filled weeks ago which has been closed :
> https://issues.apache.org/jira/browse/DIRSERVER-862
>
> Can you check if this is exactly the same problem you have, and if so
> repoen
> the issue ?
>
> Thanks !
>
> On 5/14/07, Andrew C. Oliver <acoliver-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>

Ole Ersoy

2007-05-14, 1:11 pm

Yup - It's in there.

Also - Here is how the JPackage
creates the user for the Tomcat install
(I'm guessing you are going to ask me to add
this to the JIRA next, so I'll go ahead and add it :-) ):

%pre
# Add the "tomcat" user and group
# we need a shell to be able to use su - later
if grep ^tomcat: /etc/group 1>/dev/null 2>/dev/null; then
echo Group tomcat already exists, not adding group
else
if grep :%{tcuid}: /etc/group 1>/dev/null 2>/dev/null; then
echo GID %{tcuid} already exists, not adding group
else
%{_sbindir}/groupadd -g %{tcuid} -r tomcat 2> /dev/null || :
fi
fi
if grep ^tomcat: /etc/passwd 1>/dev/null 2>/dev/null; then
echo User tomcat already exists, not adding user
else
if grep x:%{tcuid}: /etc/passwd 1>/dev/null 2>/dev/null; then
echo UID %{tcuid} already exists, not adding user
else
%{_sbindir}/useradd -c "Tomcat" -u %{tcuid} -g tomcat \
-s /bin/sh -r -d %{homedir} tomcat 2> /dev/null || :
fi
fi

Also - Here's a sampling of how JPackage assigns file
ownership:

# Directories with special permissions
%attr(775,root,tomcat) %dir %{appdir}
%attr(775,root,tomcat) %dir %{confdir}
%attr(775,root,tomcat) %dir %{tempdir}
%attr(775,root,tomcat) %dir %{workdir}
%attr(755,tomcat,tomcat) %dir %{logdir}
%attr(775,root,tomcat) %dir %{confdir}/Catalina
%attr(775,root,tomcat) %dir %{confdir}/Catalina/localhost
%attr(755,root,root) %{_bindir}/*
%attr(755,root,root) %{bindir}/*
%attr(755,root,root) %{_sysconfdir}/init.d/%{name}
%attr(644,root,tomcat) %config(noreplace) %{confdir}/catalina.policy
%attr(644,root,tomcat) %config(noreplace) %{confdir}/catalina.properties
%attr(660,root,tomcat) %config(noreplace) %{confdir}/jk2.properties
%attr(660,root,tomcat) %config(noreplace) %{confdir}/logging.properties
%attr(660,root,tomcat) %config(noreplace) %{confdir}/tomcat-users.xml

So if we converted our spec over to something similar to this,
and then fix the uninstall part (Still looking into)
I think we should have a pretty solid RPM.

SNIP

Cheers,
- Ole