directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <>
Subject Re: [Apache DS] Thoughts on Apache DS installation layouts
Date Fri, 07 Mar 2008 18:50:57 GMT
On Fri, Mar 7, 2008 at 10:51 AM, Pierre-Arnaud Marcelot <>

> On Fri, Mar 7, 2008 at 6:25 PM, Alex Karasulu <>
> wrote:
> > I guess each instance can have it's own Windows service right?
> >
> I think so. Although, I'm not completely sure. Chris ?
Yes, the way it works in windows is that you create a new instance config
file and run the apacheds (Tanuki wrapper native exe) with a special command
line and it installs a service specifically for this instance.  We were
going to create some little Windows native GUI for creating new instances
from templates similar to the Cocoa config pane that Pierre-Arnaud is
talking about.  This is fairly trivial to do, and it would be really awesome
to do something as a lightweight Swing GUI or something that can be
portable, but this will be a lot of work to account for platform differences
in config stuff.  On another note, this is why I was looking at
OpenInstaller, because you can create Java plugins for the installer that
can run at install time (starting the server to pre-load data, etc.).

> > That's cool.  Also this might be totally off but is there any way we can
> > have some kind of configuration thingy like the ones you see in the system
> > configuration menus for ApacheDS or is that way hard to do?  Was wondering
> > if we can control some things in ApacheDS through there.
> >
> Yeah I was thinking to do a little PreferencePane that could look like the
> MySQL prefpane -><>
> In this prefpane you could see the status of the server (running or not),
> toggle between Start and Stop, and also choose to automatically launch the
> server when the machine boots.
> > I think we should have an init script for each instance.  Perhaps
> > /etc/init.d/ads-${instanace-name} might be a good idea WDYT?
> >
> Yep, this is almost exactly what I was thinking.  The current method can't
autostart on Linux because you have to name the instance as argument and
that is a bad oversight on my part.  I was thinking that we can have a
single script that gets symlinked for each instance (
apacheds_myinstance->/etc/init.d/apacheds) and the script can parse the
symlink name and derive the instance name.  That way we can update the
script on new releases without affecting the instances.  The config GUI or a
script could be used to maintain these types of things.

> Sounds like a good idea.
> /etc/init.d/apacheds-${version}-${instance) or something to that effect.
> > WDYT?
> >
> Good idea. It's the cleanest solution I think.

Related to the above idea, I was wondering if it would be better to have the
version tied to the target of the symlink... so that upgrading is just a
matter of a new symlink to the script for the new apacheds version that was
installed.  Another option is to make this part of the instance
configuration (apacheds.conf for the instance could specify
version=1.5.2and we could use that in variable substitution within the
scripts.  Just
ideas here, I am sure there are other options.

> > Also I'd love to see a Solaris pkg so we can make some Apache folks who
> > wanted to use ADS in zones here at the ASF happy.  That would be awesome but
> > am just greatful to have what we have.
> >
> > Thanks Pierre, this is so wonderful we finally have installers coming
> > again and can do a real release.  We were stuck in the longest period ever
> > without a release and for some reason with me it was due to knowing our
> > installers were not up to par yet.  Thanks for picking this up.
> >
> Well for now, I only added the Mac OS X installer and corrected a bug
> introduced in a refactoring which prevented the build of installers from
> working.
> All the credits go to Chris who did an amazing job with the Windows
> installer and RPM package too.
> I didn't touch them at all.
> I think a good documentation on our installer is lacking. It was not easy
> at first to figure how they worked and how they were built.
> I'm going to document them on the wiki so everyone interested can easily
> jump in and improve/fix the installers.
> We can now be good with the 5 minute download install tests that are
> > critical for how effective a project is considered.  This is a big exposure
> > area.
> >
> Exactly, I think this is an important point and that's why I tend to
> prefer native installers instead of a unique multi-platform installer.
> Users are really used to working with native installers. This is something
> they apprehend easily and they feel safe with it.
> So I think that with a Windows installer, RPM package, DEB package, PKG
> package, Binary installer, Apache DS will really cover a large set of OSes
> and people.
> As you say, maybe the remaining one could the Solaris one.
> Pierre-Arnaud

View raw message