You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Bastiaan Bakker (JIRA)" <ji...@apache.org> on 2006/09/22 15:14:22 UTC
[jira] Created: (DIRSERVER-749) fix issues with apacheds RPM to get
it working out of the box
fix issues with apacheds RPM to get it working out of the box
-------------------------------------------------------------
Key: DIRSERVER-749
URL: http://issues.apache.org/jira/browse/DIRSERVER-749
Project: Directory ApacheDS
Issue Type: Improvement
Components: installer-plugin
Affects Versions: 1.0-RC4
Environment: linux
Reporter: Bastiaan Bakker
The apacheds RPM has several issues that prevent it from running out of the box:
* the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
* the init script fails to run bevause JAVA_HOME is not defined
* the init script it is not registered to the init subsystem with chkconfig or similar
* the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
* the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
* the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
* the sources and docs are included in the rpm, even though they are not necessary for operation.
The RPM build mechanism for apacheds also has some issues:
* runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
* the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
* the sudo mechanism is totally unnecessary
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to get it working out of the box
Posted by Emmanuel Lecharny <el...@gmail.com>.
Just try a :
mvn clean
before compiling the project with
mvn install
it may - or not - work
Emmanuel
btw, thanks, maven ! ;(
On 9/29/06, Bastiaan Bakker (JIRA) <ji...@apache.org> wrote:
>
> [
> http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12438736]
>
> Bastiaan Bakker commented on DIRSERVER-749:
> -------------------------------------------
>
> 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.
>
>
> > fix issues with apacheds RPM to get it working out of the box
> > -------------------------------------------------------------
> >
> > Key: DIRSERVER-749
> > URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> > Project: Directory ApacheDS
> > Issue Type: Improvement
> > Components: installer-plugin
> > Affects Versions: 1.0-RC4
> > Environment: linux
> > Reporter: Bastiaan Bakker
> > Assigned To: Alex Karasulu
> > Fix For: 1.1.0, 1.0
> >
> > Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch,
> apacheds-daemon-trunk-rpmfix.patch
> >
> >
> > The apacheds RPM has several issues that prevent it from running out of
> the box:
> > * the init script fails to run because APACHEDS_USER is set to $USER,
> which is not defined at boot time
> > * the init script fails to run bevause JAVA_HOME is not defined
> > * the init script it is not registered to the init subsystem with
> chkconfig or similar
> > * the config files are not marked as such, causing them to be silently
> overwritten when one upgrades the RPM
> > * the RPM filename is not conform conventions:
> ${name}-${version}-${release}.${arch}.rpm
> > * the location of the files (/usr/local/apacheds-1.0_RC4) is version
> dependent, making upgrades cumbsome. The admin has to relocate the
> partitions and config files on every updgrade.
> > * the sources and docs are included in the rpm, even though they are not
> necessary for operation.
> > The RPM build mechanism for apacheds also has some issues:
> > * runs rpmbuild as root, which is frowned upon by RPM gurus for security
> and safety reasons.
> > * the generated src.rpm is not self contained, ie. one cannot do a
> 'rpmbuild --rebuild' with it.
> > * the sudo mechanism is totally unnecessary
> >
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
--
Cordialement,
Emmanuel Lécharny
[jira] Assigned: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=all ]
Alex Karasulu reassigned DIRSERVER-749:
---------------------------------------
Assignee: Alex Karasulu
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12439561 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
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
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.1.0, 1.0.1
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12439228 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
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.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.1.0, 1.0.1
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRSERVER-749) fix issues with apacheds RPM to get
it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu updated DIRSERVER-749:
------------------------------------
Affects Version/s: (was: 1.0-RC4)
1.5.0
1.0.1
Fix Version/s: (was: 1.0.1)
(was: 1.5.0)
1.0.2
1.5.1
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.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.5.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.5.1, 1.0.2
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-749) fix issues with apacheds RPM to get
it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=all ]
Bastiaan Bakker updated DIRSERVER-749:
--------------------------------------
Attachment: apacheds-daemon-trunk-rpmfix.patch
apacheds-branch-1.0-server-installers-rpmfix.patch
The attached patchs are diffs against directory/trunks/daemon/ and directory/branches/apacheds/1.0 respectively. The provide the following fixes:
* 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
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12438683 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
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.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Chris Custine (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Custine reassigned DIRSERVER-749:
---------------------------------------
Assignee: Chris Custine (was: Alex Karasulu)
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assignee: Chris Custine
> Priority: Minor
> Fix For: 1.5.1, 1.0.3
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12436853 ]
Emmanuel Lecharny commented on DIRSERVER-749:
---------------------------------------------
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 !
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Chris Custine (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Custine resolved DIRSERVER-749.
-------------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.0.3)
The new RPM installe rimplements almost all of these items. If anything else needs to be added we can add individual issues.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assignee: Chris Custine
> Priority: Minor
> Fix For: 1.5.1
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12438512 ]
Alex Karasulu commented on DIRSERVER-749:
-----------------------------------------
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?
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12436884 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
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
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494301 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
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?
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.5.1, 1.0.3
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12436893 ]
Emmanuel Lecharny commented on DIRSERVER-749:
---------------------------------------------
"* 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 !!!
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12439232 ]
Emmanuel Lecharny commented on DIRSERVER-749:
---------------------------------------------
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
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.1.0, 1.0.1
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRSERVER-749) fix issues with apacheds RPM to get
it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=all ]
Alex Karasulu updated DIRSERVER-749:
------------------------------------
Fix Version/s: 1.0.1
(was: 1.0)
Priority: Minor (was: Major)
We apply these changes later in 1.0.1.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.1.0, 1.0.1
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM
to get it working out of the box
Posted by Ole Ersoy <ol...@gmail.com>.
Creating a massive RPM is one way to go.
The one I'm creating
creates a minimal RPM that excludes
all dependencies.
The RPM Factory will package all the dependencies.
It can do this right now, but I took a break from
it to work on the DAS stuff, so I still need to "Prove It" :-)
Now I'm taking a break from the DAS to setup the test
environment for this.
yum will pull the minimal RPM and it in turn will
pull all the dependencies (Other RPM Packages).
I'll try to put the reworked shell script (Which
includes all the FHS thinking out this week)
so that others interested can have a look.
Cheers,
- Ole
Alex Karasulu wrote:
> Yeah this is bad. I figured this would be the case tho since you cannot
> install more than one version of a package and dependencies will cause
> some collisions. I don't think we can depend on this and need to
> package our dependencies into a single RPM.
>
> Alex
>
> On 5/8/07, *Ole Ersoy* <ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
> I was really excited about JPackage until I found out that they have
> 1 version of each "Package" that they support per release.
>
> Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
> of their packages. Each release should support 1 version of
> 1 package.
>
> Each such release has to have one supported version of a package.
>
> So suppose Tomcat and ApacheDS share a dependency.
>
> ApacheDS uses version 1.3 of this dependency in the current
> build.
>
> Tomcat uses 1.5.
>
> So what happens?
>
> Suppose someone at JPackage already built
> version 1.4, and they tried it with both Tomcat and ADS,
> and it looks like it works.
>
> Well, if that's the supported version in release
> 1.x of JPackage, then this dependency could end up getting shoehorned
> into a ADS install that JPackage supports.
>
> Personally I think that's really scary.
>
> Originally I was writing a Maven plugin for them to automate
> their work, but decided to go in another direction when
> I found out about this policy.
>
> Cheers,
> - Ole
>
>
>
> Alex Karasulu (JIRA) wrote:
> > [
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
> <https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305>
> ]
> >
> > Alex Karasulu commented on DIRSERVER-749:
> > -----------------------------------------
> >
> > 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.
> >
> >> fix issues with apacheds RPM to get it working out of the box
> >> -------------------------------------------------------------
> >>
> >> Key: DIRSERVER-749
> >> URL:
> https://issues.apache.org/jira/browse/DIRSERVER-749
> >> Project: Directory ApacheDS
> >> Issue Type: Improvement
> >> Components: installer-plugin
> >> Affects Versions: 1.0.1, 1.0
> >> Environment: linux
> >> Reporter: Bastiaan Bakker
> >> Assigned To: Alex Karasulu
> >> Priority: Minor
> >> Fix For: 1.5.1 , 1.0.3
> >>
> >> Attachments:
> apacheds-branch-1.0-server-installers-rpmfix.patch,
> apacheds-daemon-trunk-rpmfix.patch
> >>
> >>
> >> The apacheds RPM has several issues that prevent it from running
> out of the box:
> >> * the init script fails to run because APACHEDS_USER is set to
> $USER, which is not defined at boot time
> >> * the init script fails to run bevause JAVA_HOME is not defined
> >> * the init script it is not registered to the init subsystem
> with chkconfig or similar
> >> * the config files are not marked as such, causing them to be
> silently overwritten when one upgrades the RPM
> >> * the RPM filename is not conform conventions:
> ${name}-${version}-${release}.${arch}.rpm
> >> * the location of the files (/usr/local/apacheds-1.0_RC4) is
> version dependent, making upgrades cumbsome. The admin has to
> relocate the partitions and config files on every updgrade.
> >> * the sources and docs are included in the rpm, even though they
> are not necessary for operation.
> >> The RPM build mechanism for apacheds also has some issues:
> >> * runs rpmbuild as root, which is frowned upon by RPM gurus for
> security and safety reasons.
> >> * the generated src.rpm is not self contained, ie. one cannot do
> a 'rpmbuild --rebuild' with it.
> >> * the sudo mechanism is totally unnecessary
> >>
> >
>
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to get it working out of the box
Posted by Alex Karasulu <ak...@apache.org>.
Thanks Ole.
Alex
On 5/9/07, Ole Ersoy <ol...@gmail.com> wrote:
> Sure. What I will do is just check it into my sandbox
> along with a Eclipse Plugin User Manual and anyone who
> wants to can have a look at it.
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM
to get it working out of the box
Posted by Ole Ersoy <ol...@gmail.com>.
Alex Karasulu wrote:
> I'm of the mindset to use the FHS layout as much as possible while still
> adding all the
> dependencies with an uber RPM. The other way around might be attempted
> later since
> it's more complex and probably will lead to some breakage.
>
> So let's just go with the uber RPM now using the right layout especially
> the one that
> Chris recommends for being able to have multiple instances using the
> same software
> installation.
The way I'm doing it will also allow for
multiple instances.
This will be huge and more than enough for me.
>
> If Ole you have time to research the alternative approaches we can look
> into them but
> really it's not that critical.
I wish I had time to work on both approaches.
I invested well over 3 months solid looking into
an learning the intricacies of JPackage while
trying to create a maven plugin that automates all their work
for them.
I personally need the RPM installer I'm designing, thus
I'm proceeding full steam with it, but I'll be glad to help
transfer knowledge from this process if Chris wants to work
on the UBER RPM.
We have some major priorities that far
> supercede following
> the JPackage approach. Let's keep it simple for now.
Sure. What I will do is just check it into my sandbox
along with a Eclipse Plugin User Manual and anyone who
wants to can have a look at it.
>
> Alex
Cheers,
- Ole
>
> On 5/9/07, *Ole Ersoy* <ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
> The reason I'm putting all dependencies in
> /src/lib/java (FHS Location)
>
> is that now becomes the central location for all java libraries
> / jar artifacts.
>
> Right now if both Tomcat and ADS are running on the same machine,
> they duplicate a lot of the dependencies.
>
> With this there is no duplication.
>
> When OSGi gets going, it also makes
> /src/lib/java a "OSGi" service bundle repository,
> from which the OSGi container can load all services.
>
> The RPM Factory can insert OSGi manifests.
>
> So if it's hooked up to something like archiva it
> can convert an entire repository. Does depend
> on "Clean" pom files though.
>
> The approach also makes download more efficient since
> the ADS RPM is minimized.
>
> I think most administrators would prefer the FHS compliant approach.
>
> Anyways - I'm sure others might like the "Uber" RPM as well,
> so we could always do both.
>
> Cheers,
> - Ole
>
>
>
>
>
>
>
>
>
> Chris Custine wrote:
> > Personally, I favor the self contained, all in one RPM for
> distribution
> > where we can have better control over dependencies. I wonder if
> there
> > are any good reasons to do anything else...
> >
> > Chris
> >
> > On 5/8/07, *Alex Karasulu* <akarasulu@apache.org
> <ma...@apache.org>
> > <mailto: akarasulu@apache.org <ma...@apache.org>> > wrote:
> >
> > Yeah this is bad. I figured this would be the case tho since you
> > cannot install more than one version of a package and
> dependencies
> > will cause some collisions. I don't think we can depend on
> this and
> > need to package our dependencies into a single RPM.
> >
> > Alex
> >
> >
> > On 5/8/07, *Ole Ersoy* < ole.ersoy@gmail.com
> <ma...@gmail.com>
> > <mailto: ole.ersoy@gmail.com <ma...@gmail.com>>>
> wrote:
> >
> > I was really excited about JPackage until I found out
> that they have
> > 1 version of each "Package" that they support per release.
> >
> > Meaning they have JPackage 1.5, 1.6, 1.7...that are
> "releases"
> > of their packages. Each release should support 1 version of
> > 1 package.
> >
> > Each such release has to have one supported version of a
> package.
> >
> > So suppose Tomcat and ApacheDS share a dependency.
> >
> > ApacheDS uses version 1.3 of this dependency in the current
> > build.
> >
> > Tomcat uses 1.5 .
> >
> > So what happens?
> >
> > Suppose someone at JPackage already built
> > version 1.4, and they tried it with both Tomcat and ADS,
> > and it looks like it works.
> >
> > Well, if that's the supported version in release
> > 1.x of JPackage, then this dependency could end up getting
> > shoehorned
> > into a ADS install that JPackage supports.
> >
> > Personally I think that's really scary.
> >
> > Originally I was writing a Maven plugin for them to automate
> > their work, but decided to go in another direction when
> > I found out about this policy.
> >
> > Cheers,
> > - Ole
> >
> >
> >
> > Alex Karasulu (JIRA) wrote:
> > > [
> >
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
> > <
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305>
> > ]
> > >
> > > Alex Karasulu commented on DIRSERVER-749:
> > > -----------------------------------------
> > >
> > > 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.
> > >
> > > > fix issues with apacheds RPM to get it working out of
> the box
> > > >
> -------------------------------------------------------------
> > > >
> > > > Key: DIRSERVER-749
> > > > URL:
> > https://issues.apache.org/jira/browse/DIRSERVER-749
> <https://issues.apache.org/jira/browse/DIRSERVER-749>
> > > > Project: Directory ApacheDS
> > > > Issue Type: Improvement
> > > > Components: installer-plugin
> > > > Affects Versions: 1.0.1, 1.0
> > > > Environment: linux
> > > > Reporter: Bastiaan Bakker
> > > > Assigned To: Alex Karasulu
> > > > Priority: Minor
> > > > Fix For: 1.5.1 , 1.0.3
> > > >
> > > > Attachments:
> > apacheds-branch-1.0-server-installers-rpmfix.patch,
> > apacheds-daemon-trunk-rpmfix.patch
> > > >
> > > >
> > > > The apacheds RPM has several issues that prevent it from
> > running out of the box:
> > > > * the init script fails to run because APACHEDS_USER
> is set
> > to $USER, which is not defined at boot time
> > > > * the init script fails to run bevause JAVA_HOME is
> not defined
> > > > * the init script it is not registered to the init
> subsystem
> > with chkconfig or similar
> > > > * the config files are not marked as such, causing
> them to be
> > silently overwritten when one upgrades the RPM
> > > > * the RPM filename is not conform conventions:
> > ${name}-${version}-${release}.${arch}.rpm
> > > > * the location of the files
> (/usr/local/apacheds-1.0_RC4) is
> > version dependent, making upgrades cumbsome. The admin
> has to
> > relocate the partitions and config files on every updgrade.
> > > > * the sources and docs are included in the rpm, even
> though
> > they are not necessary for operation.
> > > > The RPM build mechanism for apacheds also has some
> issues:
> > > > * runs rpmbuild as root, which is frowned upon by RPM
> gurus
> > for security and safety reasons.
> > > > * the generated src.rpm is not self contained, ie.
> one cannot
> > do a 'rpmbuild --rebuild' with it.
> > > > * the sudo mechanism is totally unnecessary
> > > >
> > >
> >
> >
> >
>
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to get it working out of the box
Posted by Alex Karasulu <ak...@apache.org>.
I'm of the mindset to use the FHS layout as much as possible while still
adding all the
dependencies with an uber RPM. The other way around might be attempted
later since
it's more complex and probably will lead to some breakage.
So let's just go with the uber RPM now using the right layout especially the
one that
Chris recommends for being able to have multiple instances using the same
software
installation. This will be huge and more than enough for me.
If Ole you have time to research the alternative approaches we can look into
them but
really it's not that critical. We have some major priorities that far
supercede following
the JPackage approach. Let's keep it simple for now.
Alex
On 5/9/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> The reason I'm putting all dependencies in
> /src/lib/java (FHS Location)
>
> is that now becomes the central location for all java libraries
> / jar artifacts.
>
> Right now if both Tomcat and ADS are running on the same machine,
> they duplicate a lot of the dependencies.
>
> With this there is no duplication.
>
> When OSGi gets going, it also makes
> /src/lib/java a "OSGi" service bundle repository,
> from which the OSGi container can load all services.
>
> The RPM Factory can insert OSGi manifests.
>
> So if it's hooked up to something like archiva it
> can convert an entire repository. Does depend
> on "Clean" pom files though.
>
> The approach also makes download more efficient since
> the ADS RPM is minimized.
>
> I think most administrators would prefer the FHS compliant approach.
>
> Anyways - I'm sure others might like the "Uber" RPM as well,
> so we could always do both.
>
> Cheers,
> - Ole
>
>
>
>
>
>
>
>
>
> Chris Custine wrote:
> > Personally, I favor the self contained, all in one RPM for distribution
> > where we can have better control over dependencies. I wonder if there
> > are any good reasons to do anything else...
> >
> > Chris
> >
> > On 5/8/07, *Alex Karasulu* <akarasulu@apache.org
> > <ma...@apache.org> > wrote:
> >
> > Yeah this is bad. I figured this would be the case tho since you
> > cannot install more than one version of a package and dependencies
> > will cause some collisions. I don't think we can depend on this and
> > need to package our dependencies into a single RPM.
> >
> > Alex
> >
> >
> > On 5/8/07, *Ole Ersoy* < ole.ersoy@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > I was really excited about JPackage until I found out that they
> have
> > 1 version of each "Package" that they support per release.
> >
> > Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
> > of their packages. Each release should support 1 version of
> > 1 package.
> >
> > Each such release has to have one supported version of a
> package.
> >
> > So suppose Tomcat and ApacheDS share a dependency.
> >
> > ApacheDS uses version 1.3 of this dependency in the current
> > build.
> >
> > Tomcat uses 1.5.
> >
> > So what happens?
> >
> > Suppose someone at JPackage already built
> > version 1.4, and they tried it with both Tomcat and ADS,
> > and it looks like it works.
> >
> > Well, if that's the supported version in release
> > 1.x of JPackage, then this dependency could end up getting
> > shoehorned
> > into a ADS install that JPackage supports.
> >
> > Personally I think that's really scary.
> >
> > Originally I was writing a Maven plugin for them to automate
> > their work, but decided to go in another direction when
> > I found out about this policy.
> >
> > Cheers,
> > - Ole
> >
> >
> >
> > Alex Karasulu (JIRA) wrote:
> > > [
> >
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
> > <
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
> >
> > ]
> > >
> > > Alex Karasulu commented on DIRSERVER-749:
> > > -----------------------------------------
> > >
> > > 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.
> > >
> > > > fix issues with apacheds RPM to get it working out of the
> box
> > > >
> -------------------------------------------------------------
> > > >
> > > > Key: DIRSERVER-749
> > > > URL:
> > https://issues.apache.org/jira/browse/DIRSERVER-749
> > > > Project: Directory ApacheDS
> > > > Issue Type: Improvement
> > > > Components: installer-plugin
> > > > Affects Versions: 1.0.1, 1.0
> > > > Environment: linux
> > > > Reporter: Bastiaan Bakker
> > > > Assigned To: Alex Karasulu
> > > > Priority: Minor
> > > > Fix For: 1.5.1 , 1.0.3
> > > >
> > > > Attachments:
> > apacheds-branch-1.0-server-installers-rpmfix.patch,
> > apacheds-daemon-trunk-rpmfix.patch
> > > >
> > > >
> > > > The apacheds RPM has several issues that prevent it from
> > running out of the box:
> > > > * the init script fails to run because APACHEDS_USER is set
> > to $USER, which is not defined at boot time
> > > > * the init script fails to run bevause JAVA_HOME is not
> defined
> > > > * the init script it is not registered to the init subsystem
> > with chkconfig or similar
> > > > * the config files are not marked as such, causing them to
> be
> > silently overwritten when one upgrades the RPM
> > > > * the RPM filename is not conform conventions:
> > ${name}-${version}-${release}.${arch}.rpm
> > > > * the location of the files (/usr/local/apacheds-1.0_RC4) is
> > version dependent, making upgrades cumbsome. The admin has to
> > relocate the partitions and config files on every updgrade.
> > > > * the sources and docs are included in the rpm, even though
> > they are not necessary for operation.
> > > > The RPM build mechanism for apacheds also has some issues:
> > > > * runs rpmbuild as root, which is frowned upon by RPM gurus
> > for security and safety reasons.
> > > > * the generated src.rpm is not self contained, ie. one
> cannot
> > do a 'rpmbuild --rebuild' with it.
> > > > * the sudo mechanism is totally unnecessary
> > > >
> > >
> >
> >
> >
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM
to get it working out of the box
Posted by Ole Ersoy <ol...@gmail.com>.
The reason I'm putting all dependencies in
/src/lib/java (FHS Location)
is that now becomes the central location for all java libraries
/ jar artifacts.
Right now if both Tomcat and ADS are running on the same machine,
they duplicate a lot of the dependencies.
With this there is no duplication.
When OSGi gets going, it also makes
/src/lib/java a "OSGi" service bundle repository,
from which the OSGi container can load all services.
The RPM Factory can insert OSGi manifests.
So if it's hooked up to something like archiva it
can convert an entire repository. Does depend
on "Clean" pom files though.
The approach also makes download more efficient since
the ADS RPM is minimized.
I think most administrators would prefer the FHS compliant approach.
Anyways - I'm sure others might like the "Uber" RPM as well,
so we could always do both.
Cheers,
- Ole
Chris Custine wrote:
> Personally, I favor the self contained, all in one RPM for distribution
> where we can have better control over dependencies. I wonder if there
> are any good reasons to do anything else...
>
> Chris
>
> On 5/8/07, *Alex Karasulu* <akarasulu@apache.org
> <ma...@apache.org> > wrote:
>
> Yeah this is bad. I figured this would be the case tho since you
> cannot install more than one version of a package and dependencies
> will cause some collisions. I don't think we can depend on this and
> need to package our dependencies into a single RPM.
>
> Alex
>
>
> On 5/8/07, *Ole Ersoy* < ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
> I was really excited about JPackage until I found out that they have
> 1 version of each "Package" that they support per release.
>
> Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
> of their packages. Each release should support 1 version of
> 1 package.
>
> Each such release has to have one supported version of a package.
>
> So suppose Tomcat and ApacheDS share a dependency.
>
> ApacheDS uses version 1.3 of this dependency in the current
> build.
>
> Tomcat uses 1.5.
>
> So what happens?
>
> Suppose someone at JPackage already built
> version 1.4, and they tried it with both Tomcat and ADS,
> and it looks like it works.
>
> Well, if that's the supported version in release
> 1.x of JPackage, then this dependency could end up getting
> shoehorned
> into a ADS install that JPackage supports.
>
> Personally I think that's really scary.
>
> Originally I was writing a Maven plugin for them to automate
> their work, but decided to go in another direction when
> I found out about this policy.
>
> Cheers,
> - Ole
>
>
>
> Alex Karasulu (JIRA) wrote:
> > [
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
> <https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305>
> ]
> >
> > Alex Karasulu commented on DIRSERVER-749:
> > -----------------------------------------
> >
> > 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.
> >
> > > fix issues with apacheds RPM to get it working out of the box
> > > -------------------------------------------------------------
> > >
> > > Key: DIRSERVER-749
> > > URL:
> https://issues.apache.org/jira/browse/DIRSERVER-749
> > > Project: Directory ApacheDS
> > > Issue Type: Improvement
> > > Components: installer-plugin
> > > Affects Versions: 1.0.1, 1.0
> > > Environment: linux
> > > Reporter: Bastiaan Bakker
> > > Assigned To: Alex Karasulu
> > > Priority: Minor
> > > Fix For: 1.5.1 , 1.0.3
> > >
> > > Attachments:
> apacheds-branch-1.0-server-installers-rpmfix.patch,
> apacheds-daemon-trunk-rpmfix.patch
> > >
> > >
> > > The apacheds RPM has several issues that prevent it from
> running out of the box:
> > > * the init script fails to run because APACHEDS_USER is set
> to $USER, which is not defined at boot time
> > > * the init script fails to run bevause JAVA_HOME is not defined
> > > * the init script it is not registered to the init subsystem
> with chkconfig or similar
> > > * the config files are not marked as such, causing them to be
> silently overwritten when one upgrades the RPM
> > > * the RPM filename is not conform conventions:
> ${name}-${version}-${release}.${arch}.rpm
> > > * the location of the files (/usr/local/apacheds-1.0_RC4) is
> version dependent, making upgrades cumbsome. The admin has to
> relocate the partitions and config files on every updgrade.
> > > * the sources and docs are included in the rpm, even though
> they are not necessary for operation.
> > > The RPM build mechanism for apacheds also has some issues:
> > > * runs rpmbuild as root, which is frowned upon by RPM gurus
> for security and safety reasons.
> > > * the generated src.rpm is not self contained, ie. one cannot
> do a 'rpmbuild --rebuild' with it.
> > > * the sudo mechanism is totally unnecessary
> > >
> >
>
>
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to get it working out of the box
Posted by Chris Custine <ch...@gmail.com>.
Personally, I favor the self contained, all in one RPM for distribution
where we can have better control over dependencies. I wonder if there are
any good reasons to do anything else...
Chris
On 5/8/07, Alex Karasulu <akarasulu@apache.org > wrote:
>
> Yeah this is bad. I figured this would be the case tho since you cannot
> install more than one version of a package and dependencies will cause some
> collisions. I don't think we can depend on this and need to package our
> dependencies into a single RPM.
>
> Alex
>
> On 5/8/07, Ole Ersoy < ole.ersoy@gmail.com> wrote:
> >
> > I was really excited about JPackage until I found out that they have
> > 1 version of each "Package" that they support per release.
> >
> > Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
> > of their packages. Each release should support 1 version of
> > 1 package.
> >
> > Each such release has to have one supported version of a package.
> >
> > So suppose Tomcat and ApacheDS share a dependency.
> >
> > ApacheDS uses version 1.3 of this dependency in the current
> > build.
> >
> > Tomcat uses 1.5.
> >
> > So what happens?
> >
> > Suppose someone at JPackage already built
> > version 1.4, and they tried it with both Tomcat and ADS,
> > and it looks like it works.
> >
> > Well, if that's the supported version in release
> > 1.x of JPackage, then this dependency could end up getting shoehorned
> > into a ADS install that JPackage supports.
> >
> > Personally I think that's really scary.
> >
> > Originally I was writing a Maven plugin for them to automate
> > their work, but decided to go in another direction when
> > I found out about this policy.
> >
> > Cheers,
> > - Ole
> >
> >
> >
> > Alex Karasulu (JIRA) wrote:
> > > [ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
> > ]
> > >
> > > Alex Karasulu commented on DIRSERVER-749:
> > > -----------------------------------------
> > >
> > > 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.
> > >
> > >> fix issues with apacheds RPM to get it working out of the box
> > >> -------------------------------------------------------------
> > >>
> > >> Key: DIRSERVER-749
> > >> URL:
> > https://issues.apache.org/jira/browse/DIRSERVER-749
> > >> Project: Directory ApacheDS
> > >> Issue Type: Improvement
> > >> Components: installer-plugin
> > >> Affects Versions: 1.0.1, 1.0
> > >> Environment: linux
> > >> Reporter: Bastiaan Bakker
> > >> Assigned To: Alex Karasulu
> > >> Priority: Minor
> > >> Fix For: 1.5.1 , 1.0.3
> > >>
> > >> Attachments:
> > apacheds-branch-1.0-server-installers-rpmfix.patch,
> > apacheds-daemon-trunk-rpmfix.patch
> > >>
> > >>
> > >> The apacheds RPM has several issues that prevent it from running out
> > of the box:
> > >> * the init script fails to run because APACHEDS_USER is set to $USER,
> > which is not defined at boot time
> > >> * the init script fails to run bevause JAVA_HOME is not defined
> > >> * the init script it is not registered to the init subsystem with
> > chkconfig or similar
> > >> * the config files are not marked as such, causing them to be
> > silently overwritten when one upgrades the RPM
> > >> * the RPM filename is not conform conventions:
> > ${name}-${version}-${release}.${arch}.rpm
> > >> * the location of the files (/usr/local/apacheds-1.0_RC4) is version
> > dependent, making upgrades cumbsome. The admin has to relocate the
> > partitions and config files on every updgrade.
> > >> * the sources and docs are included in the rpm, even though they are
> > not necessary for operation.
> > >> The RPM build mechanism for apacheds also has some issues:
> > >> * runs rpmbuild as root, which is frowned upon by RPM gurus for
> > security and safety reasons.
> > >> * the generated src.rpm is not self contained, ie. one cannot do a
> > 'rpmbuild --rebuild' with it.
> > >> * the sudo mechanism is totally unnecessary
> > >>
> > >
> >
>
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM
to get it working out of the box
Posted by Ole Ersoy <ol...@gmail.com>.
Oh - Forgot to mention - The RPM Factory
includes the version number in the RPM package,
so all versions of a Maven artifact can exist side by side
as RPMs.
So if Tomcat depends on commons-logging 1.5.2
and ADS depends on 1.3.2, yum would pull each
of these and install the jar artifact in
/src/lib/java
...I think that's the FHS directory...
Gotta refresh myself :-)
Cheers,
- Ole
Alex Karasulu wrote:
> Yeah this is bad. I figured this would be the case tho since you cannot
> install more than one version of a package and dependencies will cause
> some collisions. I don't think we can depend on this and need to
> package our dependencies into a single RPM.
>
> Alex
>
> On 5/8/07, *Ole Ersoy* <ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
> I was really excited about JPackage until I found out that they have
> 1 version of each "Package" that they support per release.
>
> Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
> of their packages. Each release should support 1 version of
> 1 package.
>
> Each such release has to have one supported version of a package.
>
> So suppose Tomcat and ApacheDS share a dependency.
>
> ApacheDS uses version 1.3 of this dependency in the current
> build.
>
> Tomcat uses 1.5.
>
> So what happens?
>
> Suppose someone at JPackage already built
> version 1.4, and they tried it with both Tomcat and ADS,
> and it looks like it works.
>
> Well, if that's the supported version in release
> 1.x of JPackage, then this dependency could end up getting shoehorned
> into a ADS install that JPackage supports.
>
> Personally I think that's really scary.
>
> Originally I was writing a Maven plugin for them to automate
> their work, but decided to go in another direction when
> I found out about this policy.
>
> Cheers,
> - Ole
>
>
>
> Alex Karasulu (JIRA) wrote:
> > [
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
> <https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305>
> ]
> >
> > Alex Karasulu commented on DIRSERVER-749:
> > -----------------------------------------
> >
> > 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.
> >
> >> fix issues with apacheds RPM to get it working out of the box
> >> -------------------------------------------------------------
> >>
> >> Key: DIRSERVER-749
> >> URL:
> https://issues.apache.org/jira/browse/DIRSERVER-749
> >> Project: Directory ApacheDS
> >> Issue Type: Improvement
> >> Components: installer-plugin
> >> Affects Versions: 1.0.1, 1.0
> >> Environment: linux
> >> Reporter: Bastiaan Bakker
> >> Assigned To: Alex Karasulu
> >> Priority: Minor
> >> Fix For: 1.5.1 , 1.0.3
> >>
> >> Attachments:
> apacheds-branch-1.0-server-installers-rpmfix.patch,
> apacheds-daemon-trunk-rpmfix.patch
> >>
> >>
> >> The apacheds RPM has several issues that prevent it from running
> out of the box:
> >> * the init script fails to run because APACHEDS_USER is set to
> $USER, which is not defined at boot time
> >> * the init script fails to run bevause JAVA_HOME is not defined
> >> * the init script it is not registered to the init subsystem
> with chkconfig or similar
> >> * the config files are not marked as such, causing them to be
> silently overwritten when one upgrades the RPM
> >> * the RPM filename is not conform conventions:
> ${name}-${version}-${release}.${arch}.rpm
> >> * the location of the files (/usr/local/apacheds-1.0_RC4) is
> version dependent, making upgrades cumbsome. The admin has to
> relocate the partitions and config files on every updgrade.
> >> * the sources and docs are included in the rpm, even though they
> are not necessary for operation.
> >> The RPM build mechanism for apacheds also has some issues:
> >> * runs rpmbuild as root, which is frowned upon by RPM gurus for
> security and safety reasons.
> >> * the generated src.rpm is not self contained, ie. one cannot do
> a 'rpmbuild --rebuild' with it.
> >> * the sudo mechanism is totally unnecessary
> >>
> >
>
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to get it working out of the box
Posted by Alex Karasulu <ak...@apache.org>.
Yeah this is bad. I figured this would be the case tho since you cannot
install more than one version of a package and dependencies will cause some
collisions. I don't think we can depend on this and need to package our
dependencies into a single RPM.
Alex
On 5/8/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> I was really excited about JPackage until I found out that they have
> 1 version of each "Package" that they support per release.
>
> Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
> of their packages. Each release should support 1 version of
> 1 package.
>
> Each such release has to have one supported version of a package.
>
> So suppose Tomcat and ApacheDS share a dependency.
>
> ApacheDS uses version 1.3 of this dependency in the current
> build.
>
> Tomcat uses 1.5.
>
> So what happens?
>
> Suppose someone at JPackage already built
> version 1.4, and they tried it with both Tomcat and ADS,
> and it looks like it works.
>
> Well, if that's the supported version in release
> 1.x of JPackage, then this dependency could end up getting shoehorned
> into a ADS install that JPackage supports.
>
> Personally I think that's really scary.
>
> Originally I was writing a Maven plugin for them to automate
> their work, but decided to go in another direction when
> I found out about this policy.
>
> Cheers,
> - Ole
>
>
>
> Alex Karasulu (JIRA) wrote:
> > [
> https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305]
> >
> > Alex Karasulu commented on DIRSERVER-749:
> > -----------------------------------------
> >
> > 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.
> >
> >> fix issues with apacheds RPM to get it working out of the box
> >> -------------------------------------------------------------
> >>
> >> Key: DIRSERVER-749
> >> URL:
> https://issues.apache.org/jira/browse/DIRSERVER-749
> >> Project: Directory ApacheDS
> >> Issue Type: Improvement
> >> Components: installer-plugin
> >> Affects Versions: 1.0.1, 1.0
> >> Environment: linux
> >> Reporter: Bastiaan Bakker
> >> Assigned To: Alex Karasulu
> >> Priority: Minor
> >> Fix For: 1.5.1, 1.0.3
> >>
> >> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch,
> apacheds-daemon-trunk-rpmfix.patch
> >>
> >>
> >> The apacheds RPM has several issues that prevent it from running out of
> the box:
> >> * the init script fails to run because APACHEDS_USER is set to $USER,
> which is not defined at boot time
> >> * the init script fails to run bevause JAVA_HOME is not defined
> >> * the init script it is not registered to the init subsystem with
> chkconfig or similar
> >> * the config files are not marked as such, causing them to be silently
> overwritten when one upgrades the RPM
> >> * the RPM filename is not conform conventions:
> ${name}-${version}-${release}.${arch}.rpm
> >> * the location of the files (/usr/local/apacheds-1.0_RC4) is version
> dependent, making upgrades cumbsome. The admin has to relocate the
> partitions and config files on every updgrade.
> >> * the sources and docs are included in the rpm, even though they are
> not necessary for operation.
> >> The RPM build mechanism for apacheds also has some issues:
> >> * runs rpmbuild as root, which is frowned upon by RPM gurus for
> security and safety reasons.
> >> * the generated src.rpm is not self contained, ie. one cannot do a
> 'rpmbuild --rebuild' with it.
> >> * the sudo mechanism is totally unnecessary
> >>
> >
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM
to get it working out of the box
Posted by Ole Ersoy <ol...@gmail.com>.
I was really excited about JPackage until I found out that they have
1 version of each "Package" that they support per release.
Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
of their packages. Each release should support 1 version of
1 package.
Each such release has to have one supported version of a package.
So suppose Tomcat and ApacheDS share a dependency.
ApacheDS uses version 1.3 of this dependency in the current
build.
Tomcat uses 1.5.
So what happens?
Suppose someone at JPackage already built
version 1.4, and they tried it with both Tomcat and ADS,
and it looks like it works.
Well, if that's the supported version in release
1.x of JPackage, then this dependency could end up getting shoehorned
into a ADS install that JPackage supports.
Personally I think that's really scary.
Originally I was writing a Maven plugin for them to automate
their work, but decided to go in another direction when
I found out about this policy.
Cheers,
- Ole
Alex Karasulu (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305 ]
>
> Alex Karasulu commented on DIRSERVER-749:
> -----------------------------------------
>
> 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.
>
>> fix issues with apacheds RPM to get it working out of the box
>> -------------------------------------------------------------
>>
>> Key: DIRSERVER-749
>> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
>> Project: Directory ApacheDS
>> Issue Type: Improvement
>> Components: installer-plugin
>> Affects Versions: 1.0.1, 1.0
>> Environment: linux
>> Reporter: Bastiaan Bakker
>> Assigned To: Alex Karasulu
>> Priority: Minor
>> Fix For: 1.5.1, 1.0.3
>>
>> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>>
>>
>> The apacheds RPM has several issues that prevent it from running out of the box:
>> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
>> * the init script fails to run bevause JAVA_HOME is not defined
>> * the init script it is not registered to the init subsystem with chkconfig or similar
>> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
>> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
>> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
>> * the sources and docs are included in the rpm, even though they are not necessary for operation.
>> The RPM build mechanism for apacheds also has some issues:
>> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
>> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
>> * the sudo mechanism is totally unnecessary
>>
>
Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM
to get it working out of the box
Posted by Ole Ersoy <ol...@gmail.com>.
Just thought I'd add something to my previous JPackage commentary
that I think is important.
Remember that JPackage only "supports" 1 version of something
per release.
I made a quick example saying that if Tomcat uses 1.5
and ADS uses 1.3, and JPackage supports 1.4 (And does not feel
like building 1.5 since it seems to work fine for both ADS
and Tomcat) 1.4 gets shoehorned in.
In this case I'm only talking about direct dependencies.
Indirect dependencies can have the same scenario.
So what got built using Maven on the Apache end,
can end up being wildly different once JPackage
provides a set of RPMs for it.
This means people could start posting questions on the
on the Users list regarding bugs that were introduced
by JPackage due to a switch in the ADS dependencies.
We should note this, in case bizarre questions regarding bugs
start showing up, and they can't be replicated on our end.
Cheers,
- Ole
Alex Karasulu (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305 ]
>
> Alex Karasulu commented on DIRSERVER-749:
> -----------------------------------------
>
> 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.
>
>> fix issues with apacheds RPM to get it working out of the box
>> -------------------------------------------------------------
>>
>> Key: DIRSERVER-749
>> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
>> Project: Directory ApacheDS
>> Issue Type: Improvement
>> Components: installer-plugin
>> Affects Versions: 1.0.1, 1.0
>> Environment: linux
>> Reporter: Bastiaan Bakker
>> Assigned To: Alex Karasulu
>> Priority: Minor
>> Fix For: 1.5.1, 1.0.3
>>
>> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>>
>>
>> The apacheds RPM has several issues that prevent it from running out of the box:
>> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
>> * the init script fails to run bevause JAVA_HOME is not defined
>> * the init script it is not registered to the init subsystem with chkconfig or similar
>> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
>> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
>> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
>> * the sources and docs are included in the rpm, even though they are not necessary for operation.
>> The RPM build mechanism for apacheds also has some issues:
>> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
>> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
>> * the sudo mechanism is totally unnecessary
>>
>
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305 ]
Alex Karasulu commented on DIRSERVER-749:
-----------------------------------------
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.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.5.1, 1.0.3
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-749) fix issues with apacheds RPM to get
it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu updated DIRSERVER-749:
------------------------------------
Affects Version/s: (was: 1.5.0)
1.0
Fix Version/s: (was: 1.0.2)
1.0.3
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.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.5.1, 1.0.3
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490219 ]
Alex Karasulu commented on DIRSERVER-749:
-----------------------------------------
What's the status of this Bastiaan? Were we going to do small incremental patch applications?
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.5.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Priority: Minor
> Fix For: 1.5.1, 1.0.2
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12438736 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
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.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DIRSERVER-749) fix issues with apacheds RPM to get
it working out of the box
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-749.
---------------------------------------
closed
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: https://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0.1, 1.0
> Environment: linux
> Reporter: Bastiaan Bakker
> Assignee: Chris Custine
> Priority: Minor
> Fix For: 1.5.1
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Bastiaan Bakker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12437491 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
"* 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
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRSERVER-749) fix issues with apacheds RPM to get
it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=all ]
Alex Karasulu updated DIRSERVER-749:
------------------------------------
Fix Version/s: 1.1.0
1.0
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.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12438738 ]
Alex Karasulu commented on DIRSERVER-749:
-----------------------------------------
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!!!
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to
get it working out of the box
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-749?page=comments#action_12436855 ]
Emmanuel Lecharny commented on DIRSERVER-749:
---------------------------------------------
Whaoo !!
You did add some patch while I was typing to request them !!!
Man, this is great :)
Thanks a lot !
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira