Thank you for all that detail Chris. I manually installed the program onto my Ubuntu PPC box and only changed the /opt/* directory to /usr/local/* and /var/run to /var/lock. I followed the instructions generated by using the alien program and the i386 RPM.
At this point, I believe I am running into a 386/ppc problem. When the start script attempts to launch /usr/local/apacheds-1.5.1/bin/apacheds, I get: : cannot execute binary file At first I thought this may be a permission problem, but I ensured the script was running under the correct user (apacheds) and the owner and group permissions are set to this user. I assume the file is an i386 binary and that is the problem. At this point, I suppose I should try invoking the java program directly instead of depending on this launcher script? -- jim Chris Custine-2 wrote: > > On Nov 12, 2007 8:53 AM, chago <[EMAIL PROTECTED]> wrote: > >> >> I know nearly nothing about linux, although I am running Ubuntu on my mac >> TiBook (ppc). >> >> I installed alien which can install rpms and convert between many install >> packages. I used it to generate a pre/post scripts and unpack the rpm >> into >> a >> local directory. I can also use alien to install the rpm. Other than some >> inappropriate (for ubuntu) directories, it seems like it would install >> fine. >> >> I really don't have the skill to write an install script. I was baffled >> by >> a >> lot of the /etc/init.d/apacheds file, especially the recursive launch of >> the >> script when run-as does not match current user. I'm not even sure what > > > This was inherited from the Tanuki wrapper daemon and is basically a > mechanism to launch the java program as a different user. This is a > necessary hack since Java doesn't do setuid I didn't like a lot of that > either, but the Tanuki wrapper works really well and has a lot of > potential. Maybe we can make some improvements or suggestions to them. > > >> directories are preferred when installing the different sections of the >> code. For example, the current codebase works with these separate >> directories... >> >> /etc/init.d - Used for apacheds start/stop script (same for ubuntu) >> /etc/sysconfig - Used for specifying a couple directory paths (don't know >> where ubuntu would want these. Seems like a waste of a folder for just >> storing some "conf" data. I suppose they exist because they are conf data >> for the server proper and not the server instance.) > > > Exactly... this is just to have a place to set global env data before the > rest of the script runs so that the admin doesn't have to edit the init > script. This lets these customizations survive upgrades. > > >> /var/lib/apacheds - Used for configuration and runtime data (partitions). >> Also holds subdirectories for different configurations of apacheds. Comes >> with a 'default' config. (Maybe /usr/local/apacheds/configs?) > > > This directory is specified by the FHS specs ( > http://www.pathname.com/fhs/) and is used by many other programs that > have data storage needs (MySQL, > Postgres, etc.) > > >> /var/run - Holds the pid apacheds is running on. (/var/lock in ubuntu) >> /opt/apacheds-1.5.1 - Holds the implementation of the server, including >> the >> bin directory for launching. (not sure where this should go, maybe >> /usr/local/apacheds-1.5.1?) > > > This is again specified by FHS, but as long as the location is reflected > in > the init script, it can go anywhere. > > >> >> >> So, you can see I don't know much about it, but I may know enough to get >> it >> up and running although in a very manual manner. Assuming the >> init.dscript >> works on Ubuntu. The init.d script wants the name of an instance when >> starting/stopping. How does it find this name parameter when the system >> is >> starting up the server? It doesn't seem to default to anything... > > > Yeah, this was an oversight and I think we are going to have to figure out > a > better way to do this in the next release. There are basically 2 options: > we create a config that says which instances get started by default (so > starting stopping the service starts/stops all named instances ), or we > create a new init for each instance. I have seen it done both ways so > suggestions are welcome. > > >> >> >> FWIW, the i386 rpm seems to work OK on my PPC architecture. >> > Yes, with the Java installers, the platform id is largely irrelevant since > Java has to be there seperately. So I guess we could just make copies for > the other platforms in case we ever do a yum repo or any of the other > distro > repos. > > Thanks for the discussion. Like Alex said, any help in this area is > welcome. > > Chris > > >> >> Alex Karasulu wrote: >> > >> > You're right. It's lame that we have all these GUI installers and no >> > tarball. Someone has to >> > scratch this itch. Wanna give it a try? >> > >> >> -- >> View this message in context: >> http://www.nabble.com/-ApacheDS--In-preparation-for-1.0.1-release%3A-candidates-available-tf3268468.html#a13708105 >> Sent from the Apache Directory Project mailing list archive at >> Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/-ApacheDS--In-preparation-for-1.0.1-release%3A-candidates-available-tf3268468.html#a13712005 Sent from the Apache Directory Project mailing list archive at Nabble.com.
