Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
  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

share|improve this question

3 Answers 3

up vote 4 down vote accepted

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:

http://serverfault.com/questions/123144/managing-an-application-across-multiple-servers-or-pxe-vs-cfengine-chef-puppet/123153#123153

http://serverfault.com/questions/155705/automate-server-setup-with-source-builds/155713#155713

share|improve this answer
    
Thanks, very informational i will make sure to check everything out. Indeed some questions look very broad i will try to make it more strict to the idea of the post later tonight. –  Prix Oct 19 '10 at 18:53
    
both links and the book are very interesting, i was taking a look in the question and indeed this subject is very wide. The idea was to cover users preferences and ways they use to use when they need to compile and keep track of how they compiled something. Would you have any suggestion to what i could possible change on it or should i just mark it as a community wiki afterall ? I am sorry for the trouble and i really appreciate your nice post. –  Prix Oct 20 '10 at 0:29
    
I'd need more information. User environment? What are your users compiling? What kind of users? What kind of systems? –  Warner Oct 21 '10 at 13:41
    
What I meant by users was "SF community" –  Prix Oct 21 '10 at 20:17

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.

share|improve this answer
    
Nice point about using the svn to maintain everything... –  Prix Oct 19 '10 at 18:54

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.

share|improve this answer
    
Well I am aiming this question for those who use the source file to compile it by hand, but thanks. –  Prix Oct 19 '10 at 17:46
    
And you believe that using mock to generate a RPM from a SRPM doesn't count as "compiling by hand"? –  Ignacio Vazquez-Abrams Oct 19 '10 at 17:52
    
SRPM is merelly a pack of my question and you still need to configure it as you like which is why i broke down the question to phases also in some system you do need to install the rpm manager to use it or unpack the SRPM to use it. –  Prix Oct 19 '10 at 17:59
    
The rest is just FHS and Puppet. –  Ignacio Vazquez-Abrams Oct 19 '10 at 18:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.