Deploying a JAR + script + directories as RPM - One command install

Posted on 2008-11-17
Last Modified: 2013-12-15
I need a piece of advice. I have a piece of software that in made up of a runnable JAR file, and a directory structure with supporting files. I also have a script that needs to run the first time the software is deployed.
I need to set it up in such a way that installation is entirely automatic. That is, this software will be installing on Fedora Code based servers that will automatically download it and run it. Because this is an automatic process, the servers need to be able basically to deploy the software as in unattended RPM.
It seems to me that I need to:
1. Package the entire software into one file (directories and all)
2. Have the server execute the file, expanding the directories. (IE the file must be something like an RPM, not a .tar.gz)
3. Have the server automatically install dependencies (including the Java JRE) either from the net or my file
4. Have the server launch a setup script.

The immediate thinking here suggest an RPM, but I've never worked with ANY Linux packaging or installation process (like configure or make) so I don't know how to create one, let alone one that does all this stuff. Any help would be great!

Question by:bored_shiva
    LVL 7

    Expert Comment

    RPM is absolutely the answer.  A few comments:

    Pick up a copy of Maximum RPM.  It's dated, but it'll give you an excellent start on what RPM is and isn't, and how to use it.
    RPM will define dependencies, but auto-installation is left to other tools, like yum.  I.e. you can define in your RPM what it needs, but JRE is separate; auto-install depends on the users' configuration.
    Goals 1, 2 and 4 are all reasonable and achievable

    It's really not practical to say "here's how to make RPM's" in a single answer here, after all, they've written entire books on it.. but I can give an overview as it pertains to you:

    There's two kinds of RPM's.  Source RPM and Binary RPM.

    A Source RPM contains a tarball of source code (e.g. makefile), patches, etc., and basically defines how to compile the software in order to produce a Binary RPM.

    The Binary RPM is similar to a tarball of binaries, but also with some scripts and definitions to say what file goes where, what the permissions should be, what packages, objects or files are required, what objects or files this package provides (to other packages), and pre/post-install actions.

    The RPM is built with two things: a spec file, and the files contained within it.

    The spec file has the sections I mentioned previously; a list of requisites, things provided, description, list of files, permissions, etc.; RPM takes the spec file, makes sure all the files are accounted for, and builds an RPM.  You can also do things like sign the RPM with a cryptographic signature (GPG signature) to verify it's authenticity, etc.

    Some RPM commands that will give you ideas:

    rpm -qpi filename.rpm
    rpm -qpl filename.rpm
    rpm -qp --scripts filename.rpm
    rpm -i filename.srpm

    The first two are for Query mode, as denoted by -q.  -p, as a modifier to -q, indicates to use a file, rather than an installed package; omit the -p if you want to query an installed package.  -l, as a modifier to -q,  is to list the files provided by the package.  -i, as a modifier to -q, gives a description of the package. The third will show you the scripts a package has, pre-install or post-install, to see what commands it will run when you install (or uninstall) the package.  Note: a common cop-out of many novices is to (ab)use the scripts section to perform actions that RPM supports.  Don't do this!  The better defined your spec file, the better RPM can detect incorrect system configurations, and generally make life easier for sysadmins everywhere.

    The fourth command is to do an rpm Install.  You could also do -U to Upgrade.  If you install a Source RPM (srpm), it'll unpack the files into the /usr/src/redhat/ directories.  Look at the /usr/src/redhat/SPECS/ directory after installing a source RPM, and look at the .spec file.  Start with a simple RPM, like gpm, not a complex RPM, like Apache; spec files for packages like Apache demonstrate how complex RPM's can become, in trying to support a Source RPM that will build in any environment.

    Author Comment

    Thank you for your comment. Sorry I hadn't had a chance to reply to it sooner - I was playing with RPM (actually, rpmbuild, as it turns out.) For the most part, I think I got it working, but there's one thing I haven't been able to solve: How do you specify a particular package dependency?

    It seems that RPM does a pretty good job discerning dependencies automatically based on the .so files and whatnot. But the program requires Java 1.6, and so far, I haven't found a way to make rpm install it automatically if it's not present. - A big problem when the software is suppose to be installed on a VM without native Java. Any thoughts?
    LVL 7

    Accepted Solution

    The spec file should contain a stanza for "requires"


    Maximum RPM is the best place to start, and while it's a bit dated, it remains one of the best references on the subject.

    Auto-install is going to be an issue, and could be addressed by a wrapper script and a tar, though at that point, you may run into licensing issues with java that could prevent you from distributing it with your package.  Proceed with caution.  The best solution is user documentation; if it fails to install, maybe the user will read the README. :)

    Author Comment

    Hehehe. The user is an automatic VM deployer that NEVER reads readmes...
    Thanks a lot, I think I have what I need now. I saw the "requires" thing in Maximum RPM, but I didn't see any GOOD examples. Oh well, I ended up doing a script anyway, so it's all good. BTW, Sun has made it legal to redistribute the JRE sometime last year.
    Thanks again.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How your wiki can always stay up-to-date

    Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
    - Increase transparency
    - Onboard new hires faster
    - Access from mobile/offline

    Suggested Solutions

    Linux users are sometimes dumbfounded by the severe lack of documentation on a topic. Sometimes, the documentation is copious, but other times, you end up with some obscure "it varies depending on your distribution" over and over when searching for …
    Introduction This article is the last of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers our test design approach and then goes through a simple test case example, how …
    This video teaches viewers about errors in exception handling.
    Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

    759 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    13 Experts available now in Live!

    Get 1:1 Help Now