|
Thanks Bastiann for this list of problem !
We definitively have to fix them. Let me just comment some of them : * JAVA_HOME : it *must* be defined before the installation, because there is no simple way to find a JVM on a server (by no mean doing a 'find / -name java" could be a solution). (The important word in this sentence is of course _simple_ :) * The location is not really important right now, because the package is not the last one. It's still a RC. Those RC are not supposed to be used in production, and it allows us to install a newer version without destroying the previous configuration file (which is a very valid concern you raised in your point #4). A symlink could help for the release... * Sources and help : yes, but when you launch the installer, you can avoid their installation. May be we can generate a pure binary RPM ? * Root : this may be a problem, as we need to install ADS as a service, with a default port value = 389 (< 1024) Can I suggest you help us improving the packaging? We are not really Linux/RPM gurus, so feel free to give us any advice and direction (even patches) which can be used to build a better RPM ! (and for those who use W$, mac and Solaris, any feedback will be warmly welcomed !) Thanks again for the time you spent on the packaging ! Whaoo !!
You did add some patch while I was typing to request them !!! Man, this is great :) Thanks a lot ! Thanks for the positive feedback.
Some comments on your comments :-) * JAVA_HOME: Currently I've set it to /usr/lib/jvm/java, because that is the location for the default Java installation with JPackages alternatives system. This is also used by Fedora and RHEL and any other distro using JPackage. I would like to set it to /usr/lib/jvm/jre, because then you would only need the JRE and not the JDK to run apacheds. But the init script puts $JAVA_HOME/lib/tools.jar in CLASSPATH, which only works when using the JDK. Does any part of the apacheds server actually need tools.jar? * location. Maybe RCs are not supposed to be used in production, but in reality they are (at least in our datacenter). In any case I would prefer to to have the RCs look like production version as much as possible (the y aren't called Release Candidated for nothing) * running non-root: which user to run as is configurable at rpm build time in pom.xml and at runtime in /etc/sysconfig/apacheds. The current server.xml listens on port 10389 so running non root isn't a problem with the default config. In cases where I need it to listen to port 389 I prefer to run it non-root with a high port and create an iptables rule to forward 389 to the high port. * sources and help: with RPM you don't launch an installer so that wouldn't be an option. But I've put them in two subpackages so users can choose whether to install sources and docs or not. On my todo / wish list: * run java in server mode * add status command to initscript * restart apacheds after upgrade * Filesystem Hierarchy Standard compliance * logging to syslog by default * fix the bogus installation check warning * create a proper src.rpm which rebuilds apacheds from source * inclusion in JPackage "* JAVA_HOME: ... Does any part of the apacheds server actually need tools.jar? "
Well, hmmm, yes. We need it to compile the schema classes if you modify the schema. Alex will confirm that, I think. * RC & Location : ok, I understand your concern. I don't think we will have a lot of RCx after RC4, so this concern will vanish in a near futur. So you are using it in production? That's quite a good news. We will really appreciate any feedback about it - pbs, of course, but also usage statistic, number of entries, and of course a testimonywe will add to the site :) * Running non-root : I didn't get it the first time. You are perfectly right. I think the best approach would be to use a port which is not 389, and use a special account like 'ldap', with a /bin/null as shell, and into a chrooted space. * Sources : Sorry, again, I have made the bad assumption you were using the .jar, which is an installer. We will try to apply your patch asap; Thanks !!! "* JAVA_HOME: ... We need it to compile the schema classes if you modify the schema. Alex will confirm that, I think. "
I see. I thought all schema classes needed to be precompiled? In any case if a compiler isn't needed now, it will be in the future. If we should depend on the JDKs compiler or use another one (like Tomcat does) is a question for another time. * Running non root: the patch uses username 'apacheds', but it's configurable in the POM. I'd rather avoid 'ldap' because at least on Fedora that one is already used by OpenLDAP. The RPM usess 'useradd -r' to create a system account, but I see that still gives it a valid shell. I'll create a separte patch to fix that. chroot would be nice but I would want to do that for a default setup because it complicates it a lot (need to replicate all JVM stuff etc. inside the chroot). * using ApacheDS in production. Currently we're using ApacheDS to connect FreeRADIUS to an internal Oracle user account DB via LDAP. For that we wrote a simple Partition implementation that looks up entries through JDBC. We have another ApacheDS backend in development for replication of LDAP trees to other database: it publishes LDAP updates to a JMS topic where they can be read by database specific update jobs. We also plan to use ApacheDS as a rewriting LDAP proxy. So, we don't store any entries in ApacheDS yet, we still use OpenLDAP for that. But maybe that we'll change once ApacheDS has proven itself. Cheers Looking through the diffs now. Looks like you've grasped how this plugin works. Seems like you know what you're doing here. I will make the changes and test it out a little bit then commit them for 1.0.
The start command is failing with your changes. Might be because jsvc is not working right with the default jvm shared libs. Did you try start and stop out?
I see there are some issues, both in the patch itself and in combination with 1.0 trunk:
* spec file misses "Requires: java-devel" (needed for tools.jar) * log4j.properies defines a rolling file appender that tries to write in installbasedir instead of installbasedir/var/log. But preferably I'd modify log4j.properties to log to syslog. If java-devel is installed the issues above don't prevent starting the service with the RPM I created from a patched 1.0-RC4 release. With 1.0 trunk however I get a NoClassDefFoundException: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:160) Caused by: java.lang.NoClassDefFoundError: edu/emory/mathcs/backport/java/util/concurrent/BlockingQueue at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at org.apache.directory.server.Service.class$(Service.java:51) at org.apache.directory.server.Service.init(Service.java:88) at org.apache.directory.daemon.Bootstrapper.callInit(Bootstrapper.java:151) at org.apache.directory.daemon.JsvcBootstrapper.init(JsvcBootstrapper.java:56) ... 5 more 29/09/2006 12:05:22 5807 jsvc.exec error: Cannot load daemon 29/09/2006 12:05:22 5806 jsvc.exec error: Service exit with a return value of 3 Is this the problem you're refering to? Also could you please describe your test platform and output. OS release, JDK version and package RPM (jpackage or SUN, etc)? I'll see if I can fix the NoClassDefFound issue. It appears to be a regression from RC4 though and not something introduced by the RPM patch, so it could have affected some of the other install methods as well. Another mostly harmless issue is the incorrect installation check in BootStrapper: [12:05:21] ERROR [org.apache.directory.daemon.Bootstrapper] - Installation verification failure! java.lang.IllegalStateException: /opt/apacheds is write protected from the current user: apacheds Doesn't prevent apacheds from running but is confusing to end users. grrmbl. 1.0 branch doesn't build for me anymore due to same problem:
/home/bastiaan/sources/svn.apache.org/1.0/directory/apacheds/server-jndi/src/main/java/org/apache/directory/server/jndi/ServerContextFactory.java:[60,30] cannot find symbol symbol : class ExecutorThreadModel location: package org.apache.mina.common /home/bastiaan/sources/svn.apache.org/1.0/directory/apacheds/server-jndi/src/main/java/org/apache/directory/server/jndi/ServerContextFactory.java:[74,54] package edu.emory.mathcs.backport.java.util.concurrent does not exist so I guess that should be fixed first. Bastiaan,
You're trying to do some good things here but you're doing several things at once. IMO it might be better if we tackled one issue of the RPM problem at a time with changes being clearer especially with the patches you provide. For example we can tackle the move to opt and make the package relocatable. Then we can focus on allowing it to run as apacheds user etc. By breaking appart each issue it's easier to swallow and we can have some discussion on each matter. Does this sound reasonable? Perhaps we can break this issue up into several smaller issues and have some dialog on each matter on the mailing list. Cool? BTW regarding the mina issue there is a dep on the concurrent backport package. Perhaps maven is not pulling that down. Perhaps you can write to the list on the specific problem and it's details so we can make sure the issue goes away for you. Since RC4 mina has transitively introduced this new dependency into ApacheDS. Also your excellent RPM enhancements can applied for 1.0.1 since we're starting to run out of time now. For now we can deal with these existing RPM issues although they're a PITA. I really liked what you tried to do and want to make sure we get there. However we can have a bug fix release within weeks to incorporate these changes correctly. There's no need to rush. It's good to have you helping out since you seem to know about this business of building RPMs. I whipped together what you see in a rush and fell really short while doing it. I'd love to have you interacting with us and on the team. Please keep up the dialog :). Thanks much!!! We apply these changes later in 1.0.1.
Alex, thanks for the postive feedback on my RPM enhancements. I'm fine with having the changes go into a 1.0.1 release instead of 1.0 if that will be released soon anyway. Don't want to hold up 1.0 :-)
I'm not sure whether JIRA would be the best way to fix the RPM incrementally: all the small patches will depend on each other, making the order in which they are applied essential. Also at the intermediate steps the RPM would still not be usable, making testing difficult for interested people. Would it be possible for me to commit changes to a subversion branch instead of submitting patches? I can commit small changes with explanation which will be easier to review than this single patch. Yet, I don't have to wait for each change to be merged into mainline before doing the next step. People interested in the end result can just check out the latest revision of the branch instead of waiting for it to appear in the mainline trunk. As for the functional changes in the current patch: the patch allows configuration of the old location and running apacheds as root through entries in the pom.xml. So, if you like, you can still switch to the old setup.... For people wanting to try out the new RPM, I've published 1.0.0 prerelease RPMs at http://www.cryptoforge.net/unofficial/apacheds/prerelease/ . They have been tested to run out of the box on a Fedora Core 5 box with jpackage JDK java-1.5.0-sun-devel-1.5.0.07-1jpp. Cheers. Hi bastiaan,
The main problem we are having right now is that we are busy closing the 1.0, and this is the reason your patches have been postponned. We would be very please to allow you to commit your changes into a branch, but you have to know that the election of a new committer is a process that is verrrrrrrryyyyyyy long (let say at least one month). We have to propose you as a committer first, then launch a vote, then wait for you to sign a CLA, then enter the Apache administrative loop, and finally, you will be drying dead in the desert before being able to commit a patch... What I could suggest is that we work in pair one of the next day to fix this issue, I have a FC5 on a computer, and as I have done my homework lately ( newer ASN.1 codec has been committed yesturday), I will be available to help out this problem. I'm in France, so my TZ is UTC + 2, but I'm working during nigh (from 8 PM to 1 AM UTC) Feel free to contact me if needed ! Emmanuel Hi Emmanuel,
A 1.0 release is joyous event and I certainly don't want to distract you, Alex or anyone else working from getting it ready! I see ASF bureacracy is an effective inhibitor of quick commit access. "you ain't in sourceforge territory no more, Bastiaan" ;-) Won't mind jumping through the hoops at a later date, though. My company is in participating in ApacheDS development. I'm in the Netherlands, so we're in the same TZ. However I'm mostly limited to working on office hours: in the evening family life is taking most of my time. Could have a try coming thursday 20:30UTC. I'll be on #apache-directory on FreeNode as well as reachable by mail. Bastiaan Again I'm really sorry to be pushing this off yet again to another release but I looked at the attachments and they're a bit out of date. Unless you can get me a patch to fix these issues in the now building 1.0 branch I'll have to engage you later after 1.0.2 is out.
Please bear with us. I know this must be frustrating. I think for 1.0.2 we really have to grapple with all these outstanding issues that have been pushed back. What's the status of this Bastiaan? Were we going to do small incremental patch applications?
I'm going to postpone this yet again because it's not absolutely critical and the RPM does work on standard RH boxes with the SUN JDK. A lot of work will be needed to get the RPM in order and some things are now being worked on by Chris and Ole but this will take some time.
Hi Alex,
Sorry for not replying sooner, I've been on holiday. We were going to do small incremental patches ( in so far possible) but neither Emmanual or you had time at that time. Unfortunately now I have less time to spend on apacheds (I'm mostly limited to spend time on this at work where other projects have gotten more priority now) :-( Also, in the mean JPackage folks appear to have RPMed apacheds-1.0 the proper way (a self contained srpm that rebuilds from source). I haven't looked at it yet though. Maybe trying to get that packaging to apacheds-1.5 is more useful than patching the original RPM hack. Have apacheds people been in contact with jpackage folks about this? NP Bastiaan, it's hard to align at times. Oh I did not know about the JPackage rpm. Perhaps we need to look at that. None of us besides Ole have been in contact with the JPackage folks. Perhaps you can point us in the right direction so we can see and discuss what they have done.
BTW Chris Custine is now looking at rewriting some of the code in the daemon and installer modules to properly generate an RPM with scripts that actually work out of the box. He's primarily focused on the 1.5 branch and will be switching us over to use the Tanuki wrapper instead of jsvc and procrun. As for 1.0 I don't think it's worth mucking with. The new RPM installe rimplements almost all of these items. If anything else needs to be added we can add individual issues.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Minor
fix issues with apacheds RPM to get it working out of the box
* added /etc/sysconfig/apacheds containing JAVA_HOME and APACHEDS_USER
* fix init scripts to set APACHEDS_USER to 'root' if not defined in /etc/sysconfig/apacheds
* marked all config files as such
* build RPM as regular user using 'rpmbuild --define "_topdir <dir>"'
* removed no longer needed option <doSudo>
* split sources and docs in subpackages
* add tag <installBase> to <rpmtarget> to specify were apacheds should be installed
* set <installBase> to '/opt/apacheds' so the location doesn't contain a version number anymore
* add tag <daemonUser> to have apacheds run as a non-root user for security reasons
* set <daemonUser> to 'apacheds'
* let RPM create daemonUser upon first install
* let $installBase/var subdirs be owned by daemonUser
* register initscript with install_initd
* stop daemon before deinstalling RPM
* start apacheds in runlevel 3,4,5