Forum OpenACS Q&A: Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1

1: Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1

Posted by Jonathan Marsden on 07/29/01 01:06 AM

I have just uploaded changed instructions for installing OpenACS using RPMs that make the process as simple for RH 7.1 users as it has been for RH 6.2 users. This includes my own recompile of libxml2 for RH 7.1, so OpenACS installers don't need to do any compiling.

A move from aolserver-3.2+ad12 to aolserver-3.3+ad13 might be the next update... is such a change likely to be useful? Have enough people used aolserver 3.3+ad13 with OpenACS that there is a high degree of confidence with it? I may also remove the somewhat unnecessary dependency on libxml2 by making the nsxml aolserver module into its own separate RPM.

As before, the information on how to install OpenACS from RPMs on RH 6.2 or 7.1 is at http://www.xc.org/jonathan/openacs/whichfilesdoineed.html

If you try this out and run into an installation problem, please let me know. Thanks!

2: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Don Baccus on 07/29/01 01:12 AM

aD is apparently useing aolserver-3.3+ad13 so I think we may want to recommend the same and use this in your RPMs. 3.2+ad12 still has a messy memory leak problem (every time an AOLserver thread dies, memory
is leaked if it is running a Tcl 8.x rather than Tcl 7.x interpreter) and 3.3 should fix it. ad13 is necessary to make 3.3 safe and sane for other reasons, but I've not investigated.

I think your notion of moving nsxml into its own RPM makes sense.

Thanks for doing this work! Someone should tell those folks at NOSI who complain about the difficulty in getting OpenACS up where to find
your RPMs!

3: nsxml for OpenACS4 - is XSLT needed? (response to 1)

Posted by Jonathan Marsden on 07/29/01 06:27 PM

OK, thanks for the input. I have an initial aolserver-3.3+ad13 RPM already. For nsxml, I have some questions...

Q1: Which version is the latest and where should it be obtained from?

I think the answer is nsxml 1.4, at http://acs-misc.sourceforge.net/dl/nsxml.tgz

Q2: Does or will OpenACS4 make use of the XSLT option?

That will require a minor Makefile edit (simple enough), but also will mean we have a new dependency on libxslt... so then I'd have yet another pair of binary RPMs to create (for RH 6.2 and RH 7.1), since xmlsoft doesn't seem to offer those, just the SRPM.

I'm tempted to just build nsxml without the XSLT support for the moment, as far as I can tell that will be all OpenACS4 currently requires...?

4: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by G. Armour Van Horn on 07/29/01 06:49 PM

This is great news, since it was installing libxml2 that seemed to cause all the problems in the last attempt. So, next question:

The target server has a 2GB boot disk and an 18GB RAID 5 array. The array is both faster and more reliable, but you have to have it running to use it at all, so at least some stuff has to stay on the single drive. Given that, what should my partitioning look like?

Van

5: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Don Baccus on 07/29/01 07:23 PM

Jonathan - e-mail Ben directly about nsxml requirements.

6: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Roberto Mello on 07/29/01 07:31 PM

Jonathan, I recall people commenting how nice it was to have XSLT support in nsxml, in the #openacs IRC channel. If it's not too much inconvenience for you, and Ben gives his approval, I think it's a good idea.

BTW, there doesn't seem to be an aolserver-postgresql RPM on openacs.org. Should we create another SDM project for it, or are you going to bundle the driver with the AOLserver RPM?

7: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Jonathan Marsden on 07/30/01 12:58 AM

Roberto: OK, I'll look at the XSLT stuff some more, if it is likely to be useful.

The lack of some of my RPMs on openacs.org is in part because of my inability to use the SDM sensibly for RPMs, because it wants version numbers of a very fixed format, and in part because I can't use lynx to get at openacs.org (there was a patch posted regarding quoting of cookies... maybe it needs to go into 3.2.6?), and in part because it's just easier for me to scp files from here to my own web server space, and sometimes I get lazy!

At one stage we talked about using SDM on opennsd.org for the aolserver-* RPMs I think...? But that would have the same version numbering restrictions as SDM on openacs.org anyway.

Someone will suggest I hack on the SDM to do what I want... for now I'd prefer to avoid that.
I'm uploading my first-cut aolserver-3.3+ad13 RPMs (with nsxml 1.4 packaged as a separate aolserver-nsxml RPM) as I type... but I'm uploading them to www.xc.org. Once we sort out the XSLT stuff, and I test them a little, I'll edit whichfilesdoineed.html to point at them.

Hmmm... is there a way to have new-file-storage mirror a subdirectory of a web site and import the result into a new-file-storage folder?

8: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Jonathan Marsden on 07/30/01 01:28 AM

Van: You might want to ask about RH partitioning in a separate thread, and I'm not a large server hardware performance expert, but I'd think that putting / and /boot on the boot drive, and everything else (including /usr and /var and /home) on the RAID array would make sense? So (just as an example) you might consider:

  /boot 64MB on boot disk
  /     rest of boot disk

  /usr  3GB  on RAID
  /home 2GB  on RAID
  /tmp  2GB  on RAID
  swap  (2x RAM) on RAID
  /altboot 64MB on RAID
  /altroot 2GB on RAID
  /var rest of RAID

as a more or less reasonable starting point?

The idea of /altroot and /altboot partitions on the RAID is that you would backup / and /boot to them very often (say every 12 hours or whatever), automatically, so that recovery from a boot disk failure would be simplified? Better still would be to mirror (RAID1) the boot disk, if that is a real concern.

I suspect that for many moderately sized OpenACS sites, with a modern 800MHz+ x86 CPU, adding RAM may well boost performance and scalability for your site more than going to RAID? If you think you'll be adding more RAM later, for a 2.4.x Linux kernel, consider providing 4x current RAM size for swap, so when you double the RAM later you'll still have 2x RAM for swap space...

And be sure you use Don's PG parameter tweaks so PG uses more RAM buffer space than its miserly defaults, too.

BTW, it looks like the separate aolserver-nsxml RPM idea is going to work fine -- I wish I'd thought of doing it that way (via the %package command in the .spec file) much sooner!

9: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Roberto Mello on 07/30/01 01:56 AM

Jonathan,

I'm pretty sure we can work around SDM's version number limitations. Just upload your RPM and give it a close-enough release number. It doesn't need to match your RPMs _exactly_. I don't see any problems with that approach, do you?

Instead, let's focus on SDM's strengths instead:

a) Track bugs/suggestions/feature requests

b) Inform those interested of new releases

c) Make downloading the latest version easily accessible.

Right now when I tell people about the RPMs I have to tell them to go to 2 places, which is not the best situation. I didn't even know the driver came in a separate RPM until I pointed a friend to your RPM and he said "it keeps asking for an aolserver-postgresql".

I was hoping we could solve this by letting everything one person needs to install OpenACS available from the software.adp page.

10: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Don Baccus on 07/30/01 02:01 AM

Yes, please, Roberto's "use a version number close enough" should work for now, no? Roberto lists all the advantages, and we can whack on the SDM to make it accept less rigidly-restricted version numbers in the future.

11: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by G. Armour Van Horn on 07/30/01 02:44 AM

Alas, I didn't see that message until I'd taken another whack at it, but fear not, I'm sure I'll be back over this ground soon enough.

Two things about the links from your whatfilesdoIneed page:

Your link shows redHat (with an infix cap) and their site doesn't, also, the files all include "7.1.2-5PGDG.i386.rpm" instead of 7.1.2-4 as you linked it.

At least I momentarily have AOLServer running, although I can only get it from localhost - I probably don't have my firewalls setup to handle port 8000.

Van

12: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Jonathan Marsden on 07/30/01 10:11 PM

Van: Thanks for the feedback. The 'redHat' was 100% my mistake, the 4PGDG was and remains correct for redhat-6.2, but the 7.1 RPMs there are now -5PGDG. Both should now be corrected in my whichfilesdoineed.html page.

Of course, I'll probably find out that the RH 6.2 versions all switch to -5PGDG too, and then I'll have to update the page yet again...!

13: RPM locations and the SDM (response to 1)

Posted by Jonathan Marsden on 07/30/01 10:54 PM

Roberto and Don: For now we can tell people to go to http://www.xc.org/jonathan/openacs/whichfilesdoineed.html and that's just one place. This is what has been the case for some few months now.

However, I'lll try the "invent a sortof close version number" and see what happens. It should allow me to upload an openacs RPM into SDM, I think.

Next SDM-related issue... I have (i) two sets of PG RPMs to point at; (ii) my own aolserver RPM and SRPM ; (iii) my own aolserver-postgresql RPM and SRPM; (iv) my new aolserver-nsxml RPM (no separate SRPM for this, it is built when you build aolserver); (v) my own recompiled libxml2 RPMs for 6.2 and 7.1, and a pointer to the official SRPM; (vi) probably soon recompiled libxslt RPMs for 6.2 and 7.1, and a pointer to the official SRPM.

Question: Do I need one SDM 'package' for each SRPM, each RPM, or what? It's not clear to me how to achieve Roberto's goal of "everything you need for an OpenACS install in one place" using SDM. Do I just need some static webspace under openacs.org where I can put groups of files??

I'm perfectly willing to put everything onto openacs.org so it is all "in one place" and can use the SDM bug and release tracking facilities... but I don't have a clear idea of the appropriate mapping between SDM concepts and a set of RPMs and SRPMs, some of which are mine, some of which are recompiled from other folk's unchanged SRPMs, and some of which are completely maintained by others. Oh, and some are specific to a particular version of Red Hat, and some are not.

Honest question: How would you like me to proceed?

14: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Don Baccus on 07/30/01 11:56 PM

Musea is hoping to get the new, 4.x site up in a few weeks, and with that will come the download package (already ported) and the ability for us to set up a repository. We could set up separate 3.x RPM and 4.x RPM repositories with the various downloads you mention available under them.

You're right, the SDM doesn't cover the kind of release scenario you're painting well. But we could set up SDM packages for the 3.x and 4.x RPMs in order to give folks a central place to report bugs, and include a pointer as to where to go to dig out the exact set of RPMs they need to download.

I've already been thinking about the need to integrate the SDM with the download package. aD may've already done this a bit with their work on the SDM.

15: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Roberto Mello on 07/31/01 12:10 AM

Jonathan,

When I mentioned "everything in one place", I was referring to the software.adp page on Openacs.org. That's the page that the link "Software" (that appears on all openacs pages) points to.

It's an adp page that finds the latest of a bunch of SDM packages, and presents the user with a download link, and a link to get release information.

So yes, I guess you could have one RPM for each main package. If you prefer us to link your website, then I guess that's also fine, but then also lose on the reporting (and the "nice" look of having everything in one place).

So tell us what you'd prefer and we'll do it (if the others agree), as long as we are consistent in pointing the user to one place for RPMs.

16: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Talli Somekh on 07/31/01 12:16 AM

I'm working on the specs for developer.openacs.org, the part of the new site that should contain all of these points. Please continue to post thoughts and ideas about this stuff. I've chatted with a few of you, notably with Kapil, but I'm dying for more ideas. I will try and post my spec within the next couple of days.

talli

17: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Jonathan Marsden on 08/02/01 12:35 AM

I don't know SDM even close to well enough to decide how best to "make it fit" this multiple-RPM kind of setup.

Even bug reports get fun... is the report against the nsxml.so driver, or against my aolserver-nsxml binary RPM for a particular version of Red Hat, or againt my packaging of aolserver-nsxml binary RPMs in general, or against my aolserver SRPM which generates those binary RPMs... and some users may just report that "OpenACS4.x didn't install" against OpenACS4.x anyway!?

An admin interface that lets admins move a bug report from one product /package/module to another easily (and ideally tracks such moves as comments to the bug report or something) would be required.

Bugzilla isn't too bad at dealing with this, you can say that this bug report is against aolserver-nsxml version whatever, on Red Hat Linux 6.2. It's straightforward to query for all bugs against aolserver-nsxml on any platform, or just those on multiple RH versions, etc. and each user can name and store their own custom queries (using cookies). All the bug reports are in "one place" from a user perspective, and adding new products does not divide that up at all.

As far as I can see, SDM considers 'packages' to be totally distinct, and you (currently on openacs.org) only query within one package, so you can't ask for "all queries in all packages that have the word RPM somewhere in their subject line" or whatever. And there is only one subdivision (into modules) of a package. There's no explicit info on what hardware, or OS, or related subsystem(s) (Oracle or PG, and perhaps what version of each, will soon be vital info during OpenACS4.x testing, and if people are not specifically asked for that info, sometimes they will fail to provide it) the bug is being reported against.

If I used just a single SDM 'package' for all this stuff, and SDM 'modules', that works for bug reporting, but the download management stuff fails because the package has a single download link for a 'latest version'. Conversely, creating one SDM 'package' per binary RPM, or even one per RM per OS variant, allows download links to work well, but bugs will likely be reported across several packages in a way that might be hard to work with. And this would get people looking for the software not one 'place' to download the stuff from, but many links, they'd have to work out which subset of these packages they need for their particular setup. Until I split my own web page into two chunks, one for RH 6.2 and one for RH 7.1 (at the suggestion of someone who tried to use it!), some folks found doing that confusing even just within my page.

Stepping back a little, I think trying to build a combination bug-tracking system *and* a download manager as one unit may be hard to do well. If that is attempted, then I think the "download" link for a given 'package' needs to be able to ask questions of the downloading user (hardware, OS, database preference maybe, packaging preference maybe...) to guide them to the correct subset from among a potentially quite large group of files they should download. Links to some of those files may be "external" (ie not part of the ACS server concerned at all).

Hmm, if we did that, OpenACS 3.x RPM-related bugs could just be handled along with all other OpenACS 3.x bugs (maybe under an RPM 'module'), and there'd be no need for a separate download link from the software page just for RPMs. Requesting a download of OpenACS 3.x would offer you that as one choice among several, if RPMs exist for your particular hardware and OS combination. That would be nice!

But we don't have that right now... is it worth the work it would take to build?

Maybe the best option for now could be to set up just two packages (Aolserver RPMs and OpenACS RPMs), and have the 'download' link on /software for each of them point to a page something like my current whichfilesdoineed.html document, which could be on openacs.org too, say in file-storage or something, along with the RPMs themselves?

Pointers from one file-storage object to other such objects (the actual RPMs) seem sort of strange though ... easy to make mistakes with?

Are we seeking mainly to get the benefits of the bug tracking stuff from the SDM, or the benefits of its download management? Trying to get both from the current SDM for this collection of RPMs may be asking too much of it?

BTW, SDM seems to fit the OpenACS development setup much better than it fits my bunch of RPMs... it scratches the itch it was intended to scratch pretty well. Enhancing it to better handle RPM (or .deb, or even self-installing .exe for Windows users) packaged software sounds good to me... but if it would be a lot of work, or if doing so would make SDM less easy to use for OpenACS itself, that may not actually be the best way forward.

Final comment for tonight: getting OpenACS4 out the door, working well, and documented, is a lot more important than any of this 😊

18: Response to Improved RPM-based OpenACS 3.2.5 install for Red Hat 7.1 (response to 1)

Posted by Jonathan Marsden on 08/08/01 07:18 PM

I now have a newer RPM set aolserver-3.3-2+ad13 which has the XSLT support in its companion aolserver-nsxml-3.3-2+ad13 RPM. It works OK on my (RH 6.2 with lots of updates) workstation, and on a stock RH 7.1 machine. I need to rebuild and retest on a stock RH 6.2 machine, and then I'll upload to my site for folks to try out.