Compiling and maintaining applications?

Question

1. What configure format do you use for compiling and why ?

   Example (you don't have to reply as the example but do state your directory setup):

   <Layout MyPersonalizedLayout>
       prefix:          /usr
       exec_prefix:     ${prefix}
       bindir:          ${prefix}/bin
       sbindir:         ${prefix}/sbin
       libdir:          ${prefix}/lib/application_name
       libexecdir:      ${prefix}/lib/application_name/modules
       installbuilddir: ${prefix}/lib/application_name/build
       mandir:          ${prefix}/man
       sysconfdir:      /etc/application_name
       includedir:      ${prefix}/include/application_name
       localstatedir:   /var
       runtimedir:      ${localstatedir}/run/application_name
       logfiledir:      ${localstatedir}/log/application_name
   </Layout>
   

2. What steps do you consider and what messures you do before recompiling or upgrading an application ?

3. How do you keep track of all the configure options you last used to compile an application ?

4. Do you take periodically backups from the configuration files ? how often ?

5. Do you have a special/different upgrading system so you can maintain the last working application until the new one is ready to roll ?

6. Do you generally test a compilation before putting it to pratice on your production server, what are you considerations before doing so ?

---

I am not much of a person that uses instaling managers such as yum, apt-get and others alike, while I do belive they are great for some stuff I prefer having my own control and possibilities within the applications i need to manage so I would like to know how everyone threat this.

If this question gets more then 3 answers I will make it a community wiki until then I ask you not to make it into one

Answer 1

I tend to prefer to standardize my system builds using primarily scripting and source. Others often like to use configuration management tools and creating their own packages from source for their distributions native package manager. If you standardize your build properly, these methods largely provide the same results and they are simply different ways of doing things.

I still use system packages and native system building utilities. With RHEL, Kickstart is absolutely essential to the initial build. For common userland utilities, I tend to default to packages. I only compile from source for the primary server role. For example: database, Web server, proxy server, load balancer, and so forth.

A1: I prefer to follow the Filesystem Hierarchy Standard whenever possible.

A2: This is a complex topic. If the upgrade requires upgraded libraries, other software may require those libraries as well. All core requirements of a build role I tend to compile by source. Libraries I will often share between builds and recompile any software that is compiled against them, as I rarely compiled statically. If your changes are tested and staged properly to production, you can minimize most risk.

A3: Configuration options are typically specified in the build when they apply across all servers. In the case of unique configuration, such as a specific VirtualHost on a cluster of Web servers, I will maintain those configuration files within a Revision Control System. After a server is programatically built, a system checklist is completed for a sanity check and configuring any options that are best handled manually. You could also use a configuration management system to help here but depending on how well your build is standardized, it could be rendered obsolete.

A4: Yes. Nightly backups of all configuration files that are unique.

A5: The upgrading system is primarily logic that is built into the initial script, with a wrapper script around it. This allows upgrades to be maintained as part of the build. Sometimes, a simpler set of scripts using for loops in bash and piping changes through ssh. The idea is for all changes to be properly standardized above all.

A6: All changes are tested and verified in a test environment before staging to production. All expected functionality should be verified to be operable.

Honestly, I could write a book about this subject based on your question as it is. You are essentially asking how to properly architect, standardize, and maintain a production environment. My answer is not exhaustive and there are fundamental standards that should apply across all approaches. You would likely benefit from the foundation established in the book the Practice of Systems and Network Administration.

I have also written other answers on this subject. See also:

Managing an application across multiple servers, or PXE vs cfEngine/Chef/Puppet

automate server setup with source builds

Answer 2

How do you keep track of all the configure options you last used to compile an application?

It depends on how I am building the application. If I am building a Debian package I will store the contents if the debian/ folder in SVN.

If I building to install without a package manager I will build a script or a makefile and store that in the SVN.

Do you take periodically backups from the configuration files?

The SVN repository is backed up daily.

Do you generally test a compilation before putting it to pratice on your production server, what are you considerations before doing so?

I almost always test, but exactly how I test depends on the application and how what it is for.

Answer 3

I build SRPMs for the software I use and then back those up. That way I have an infinitely reproducible method of cleanly building any code I use on any system I have.