Forum OpenACS Development: AOLserver et. al. RPMs available

Collapse
Posted by Bart Teeuwisse on

To ease installation on RPM based Linux distributions I'm making the following RPMs available:

I've tested the RPMs on RHE3 and RH8. I'm NOT going to make binary RPMs available. To install you'll have to recompile the above source RPMs yourself. All packages can be recompiled without root access with the following setup:

  1. mkdir -p ~/rpm/{SOURCES,RPMS,SRPMS,SPECS,BUILD}
  2. echo "%_topdir <full path to your home directory>/rpm" > ~/.rpmmacros

Then recompile the above RPMs in the order as listed above (because of build dependencies). You might wonder why I've created a tcl-threaded RPM. Well, I found that the easiest way to ensure that a threaded version of Tcl is installed. Red hat's default RPM is NOT threaded and I've experienced problems in the past re-configuring and re-compiling the package as threaded. This might be an area where these RPMs can be improved.

You'll have to install the tcl-threaded package after recompiling in order to recompile subsequent packages. The same applies to aolserver. To install binary RPMs you will need to have root access. Recompile a package like so:

rpmbuild --recompilebuild <package>

where <package> is the downloaded source RPM or if you prefer the URL to the source RPM as listed above. In the latter case rpmbuild will download the RPM for you. Recompiled binary packages will be available in ~/rpm/RPMS/, either the i386 subdirectory or the norach subdirectory.

Please post your experience with the source RPMs here. Patches for the RPM .spec files can be emailed to me directly provided you only submit the diffs.

Collapse
Posted by Bart Teeuwisse on
I'm pleased to see that Andrew is thinking what I was thinking when I made these source RPMS. Let the community compile the source RPMS for Linux distributions that the community is interested in. Then make the binary packages available as apt and yum repositories.

I don't know about apt repositories, but a yum repository is trivial to setup. The repository can be made available via FTP or HTTP. Using the latter makes more sense for a HTTP centric community like OpenACS. Adding download statistics, RSS feeds of package updates, etc to openacs.org are easily accomplished.

So have at it!

/Bart

Collapse
Posted by Randy O'Meara on
As always, an extremely useful and valuable contribution from Bart. Thank you.

BTW, it might be handy to include the daemontools manpages (http://smarden.org/pape/djb/manpages/daemontools-0.76-man.tar.gz) in your rpm.

Collapse
Posted by Bart Teeuwisse on
Randy you are too kind. I'll most certainly include the documentation. A link to the new RPM will follow when ready.

/Bart

Collapse
Posted by Don Baccus on
Bart, kudos and thanks, this is really great.
Collapse
Posted by Jade Rubick on
Bart, would you mind updating this page:

https://openacs.org/projects/openacs/installer

Collapse
Posted by Bart Teeuwisse on
Jade,

there is little that I can do to update https://openacs.org/projects/openacs/installer. As I see it, it is now time for the community to take the source RPMs and put them through the wringer. The OCT could/should lead an effort to collect resulting binaries and make them available, preferably in apt/yum repositories.

At which point the `installer' page can be updated. Right now I think that a link to this thread is sufficient.

Collapse
Posted by Jade Rubick on
What would be in involved in setting up a yum or apt-get repository? Could it be served from file-storage?

For me, the only thing beyond actually having these RPMs is having some documentation for how to produce them.

Collapse
Posted by Bart Teeuwisse on
Jade,

the first post in this thread describes how to produce binaries from the source RPMs. For an explanation of how RPMs work I refer you to http://www.rpm.org/ in particular to the book http://www.rpm.org/max-rpm-snapshot/.

Setting up a yum repository is as simple as placing all binary RPMs of a distribution (e.g. FC3) in a single directory and the run `yum-arch $directory' to make the collection a repository.

With a little thinking you setup a directory structure with one directory for each Linux distrubution. See http://servers.linux.com/article.pl?sid=04/07/22/1718242&tid=30 for step by step instructions.

How to do this from file storage requires some thinking. Will files uploaded to file storage be placed directly in the repository's directory? Should a scheduled proc place them there? Should there be some form of testing before they go into the repository? I'd like the community and the OTC to consider these questions and TIP a concensus proposal.

Collapse
Posted by Andrew Piskorski on
Bart, I think what Jade was asking for is docs on how to update these source rpms that you've built. (I don't know how to do that either...) As you say, building a binary rpm from a source rpm is pretty easy.
Collapse
Posted by Bart Teeuwisse on
The beauty of source RPMs is that they contain everything needed to build binary RPMs. If you follow the setup as described in the original post and install the source RPM like so: rpm -ivh $RPM -where $RPM is the name/location of the source RPM you like to install- then the contents of the source RPM will be installed in your %_topdir.

Again, I refer you to http://www.rpm.org/ to learn about using/creating RPMs. The topic is too fast to be explained here. In a nutshell though, each source RPM consists of a tarball of the original source code and a spec file with instructions how to compile the source code and where to install the resulting binaries. The RPM package manager does the rest. It will bundle the binaries into a new binary RPM along with dependecy requirements.

To get started I recommend you install the http://www.thecodemill.biz/repository/aolserver-4.0.10-2.src.rpm and inspect the aolserver.spec file while you read all there is to know about RPMs at http://www.rpm.org/.

For now the procedure to maintain these RPMs is to email me patches to their spec file. Once there are several developers actively involved we can think about different ways of organizing maintenance.

I'll be touching on these topics during Fri's Boston OpenACS meeting.

Collapse
Posted by Lamar Owen on
Is there a particular reason tcl 8.4.6 is being used instead of 8.4.9?
Collapse
Posted by Bart Teeuwisse on
Lamar,

no particular reason other then that 8.4.6 was the latest version when I started out with these source RPMs.

Collapse
Posted by Lamar Owen on
I have rebuilt the rpms for RHEL4/CentOS 4. Rebuild was uneventful. I'm not real thrilled with daemontools, but such is life. The rebuild and install was simple enough to not even worry about using a depsolver like apt or yum. Apt and yum are convenient, yes, but necessary they are not.

OpenACS itself is not yet represented, and I'm pretty sure I know why. OpenACS per se needs to be available to be installed in multiple places as normally installed. A set of scripts to set up an OpenACS instance seeded from a prebuilt CVS repository or something similar could be done; I think I kindof like that approach. Ideas?

Other than daemontools, I am willing to put up a yum repository on an apache HTTP server. Why not AOLserver? AOLserver cannot serve an RPM with a '+' in the filename; so I have an apache instance for all my yum needs, and have a pretty much centralized setup up here that is more or less automated. Now, I know there is no rpm here with a +, but that's irrelevant from my point of view for my purposes.

As to daemontools, its license does not allow me to distribute modified compiled binaries for RHEL4/CentOS 4 (or Fedora Core 3, for that matter). Specifically, RHEL4, and its rebuilt work-alikes like CentOS4, incorporates SELinux. SELinux will change the way the DJB programs operate, by design; thus: "All installations must work the same way; any variation is a bug. If there's something about a system (compiler, libraries, kernel, hardware, whatever) that changes the behavior of my package, then that platform is not supported, and you are not permitted to distribute binaries for it." (Quoted from DJB's website). This is why I don't use daemontools, period. I understand his reasons, but vehemently disagree with his assertion that all installations MUST operate the same way. It's his software, so he has that right, and if I disagree I don't have to use it. So I don't use it. And the need for directories directly off the root filesystem is ludicrous, IMO.

And even then I'd have to remove it after July 1. (read his page; the right to redistribute source and/or binaries of daemontools, which he considers a testing package, EXPIRES on 7/1/2005)

No, I'm not a fan of daemontols due to its quirky license, even though it is a fine program just as a program.

Collapse
Posted by Bart Teeuwisse on
With a small patch AOLserver can handle '+' in URLs. Download openacs.org/storage/view/aolserver/aolserver-4.0-plus-sign-encoding.patch and apply.

Yes, daemontools's license is quirky. Maybe we should only make the source RPM available. As as side notes, we can setup a yum repository of source RPMs too.

Collapse
Posted by Bart Teeuwisse on
Lamar,

I almost forgot to thank you for testing the RPMs. I'll make a new source RPM available of tcl-threaded 8.4.9 soon. And yes, daemontools has its disadvantages, yet, OpenACS has more or less standardized on deamontools. Hence the inclusion of daemontools.

Also thanks for your offer to setup a yum repository, however in the best interest I think the repository should be hosted by openacs.org (or some subdomain). Of course credit for those who maintain the repository. Last but not least is that I hope the repository will contain server Linux distributions. So far we have RH 7.3, RH 8, RHE3 and CentOS 4.

Keep em coming!

Collapse
Posted by Jade Rubick on
I think if anyone wants to host them on openacs.org, the OCT will be happy to have someone take this on.
Collapse
Posted by Michael A. Williams on
Hello Bart,

Thanks for the rpms and the sites about rpms. I'm trying to get up to speed on rpms and have gone through recompiling daemon tools and tcl8.4.9 on a box running Mandrake Linux 9.2. I think I hit a snag though.

It seems that the both tcl and daemontools have been installed to /var/tmp instead of /package/admin/daemontools for dtools and /usr/lib/tcl8.4 for tcl.

Did I improperly configure the rpm macros when I set the %_topdir using
echo "%_topdir <full path to your home directory>/rpm" > ~/.rpmmacros ?
I was logged in as root during the recompile of tcl and daemontools.

Daemontools-0.76-5patch also did not add svscanboot to /etc/inittab. Does this mean that it did not completely install?
Does the location of tcl in /var/tmp mean that it also did not install?
I have not yet recompiled the remaining rpms (aolserver etc...).

Collapse
Posted by Bart Teeuwisse on
Michael,

rebuilding a binary RPM from a source RPM takes place in a sandbox during which files are installed in a safe location, i.e. /var/tmp.

Upon completion of creating the binary RPM you then install the binary RPM (as root) onto your system. Only when you install the binary daemontools RPM will the content of the RPM installed in /package.

Collapse
Posted by Lamar Owen on
[Running up against the limitations of a web forum versus a threaded mailing list...]

Several replies here:

Bart, as just a minor point of information, CentOS 4 is a RHEL4 rebuild, so binaries built on CentOS4 in theory should run unmodified on Red Hat Enterprise Linux 4.

On the Mandrake questions, when rebuilding on CentOS 4 the only thing that I had to make sure I did was set the unpackaged files macro to 0 instead of the default of 1.

My rebuild of Bart's daemontools package installs thusly:
[root@www ~]# rpm -ql daemontools
/command
/command/envdir
/command/envuidgid
/command/fghack
/command/multilog
/command/pgrphack
/command/readproctitle
/command/setlock
/command/setuidgid
/command/softlimit
/command/supervise
/command/svc
/command/svok
/command/svscan
/command/svscanboot
/command/svstat
/command/tai64n
/command/tai64nlocal
/package
/package/admin/daemontools
/package/admin/daemontools-0.76/command
[snip]
/package/admin/daemontools-0.76/src/warn-shsgr
/package/admin/daemontools-0.76/src/x86cpuid.c
/service
/usr/local/bin/envdir
/usr/local/bin/envuidgid
/usr/local/bin/fghack
/usr/local/bin/multilog
/usr/local/bin/pgrphack
/usr/local/bin/readproctitle
/usr/local/bin/setlock
/usr/local/bin/setuidgid
/usr/local/bin/softlimit
/usr/local/bin/supervise
/usr/local/bin/svc
/usr/local/bin/svok
/usr/local/bin/svscan
/usr/local/bin/svscanboot
/usr/local/bin/svstat
/usr/local/bin/tai64n
/usr/local/bin/tai64nlocal
/usr/sbin
/usr/sbin/svcgroup
/usr/share/doc/daemontools-0.76/CHANGES
/usr/share/doc/daemontools-0.76/README
/usr/share/doc/daemontools-0.76/README_rpm
/usr/share/doc/daemontools-0.76/TODO
[root@www ~]#

And Bart, you're welcome. I have a few years of packaging experience for PostgreSQL under my belt; getting RPM's right is nontrivial.

Collapse
Posted by Michael A. Williams on
Thanks for the speedy replies guys. Actually after I recompiled the rpms, I didn't find any binaries created in the ~rpm/i386 or noarch directory. So what I did was go to
/var/tmp/...admin/daemontools-0.76/ and used
package/install while in that dir. Is there a switch I need to use with rpmbuild to make the binary file. I used this command to recompile the rpms.

rpmbuild --recompile daemontools-0.76-5patch.src.rpm

rpmbuild --recompile tcl-threaded-8.4.6-2.src.rpm

A binary was not created in either case, or maybe I am confused with what the binary should look like. I am wrong in thinking that they should be sinlge file of the style

- daemontools-0.76-5patch.i386.rpm

- tcl-threaded-8.4.6-2.i386.rpm

A quick aside. How can I tell if tcl8.4 installed?

Thanks again.

Collapse
Posted by Michael A. Williams on
Aha, checking the version of tcl is explained in the aolserver installation guide.

https://openacs.org/doc/current/aolserver4.html

or simply:

[root root]$ tclsh
[root root]% info exists tcl_platform(threaded)
1
#This is to check that it is threaded.

[root root]% info patchlevel
8.4.7
[root root]%

Collapse
Posted by Rick Cogley on
Thank you for making these available, Bart.

The RPM of daemontools you have up errors out due to some error in gclib implementations, and has never been patched on the creator's site, apparently (http://homepages.tesco.net./~J.deBoynePollard/FGA/djbdns-problems.html#errno)

However, here's some info about it, and a working RPM, for everyone's info -

The patch itself:
http://megaz.arbuz.com/download/daemontools-0.76.errno.patch

Ref to installing daemontools prior to CLAMAV:
http://www.hostbird.com/index.php?mi=open-source-antivir1&ri=open-source-antivir3

Download location for working RPM (works on FC3):
http://www.hostbird.com/projects/qscanq-psa/daemontools-0.76-1.i386.rpm

Hope this helps someone. It worked for me.

Collapse
Posted by Rick Cogley on
Also - Bart tells me that his source RPM for daemontools is already patched. It must have been my system, but the above may help others.

br,
Rick