<<O>>  Difference Topic ServerSoftwareInstall (r1.7 - 22 Jan 2012 - BenScott)

META TOPICPARENT InternetServer
TOC: No TOC in "Organizational.ServerSoftwareInstall"
Line: 20 to 20

Repository priorities

Changed:
<
<
When a third-party repository is configured, use the yum-priorities plugin to configure the "stock" repositories to have a higher priority (lower number) than the third-party repo. This keeps the third-party repo from unexpectedly upgrading the distro beyond recognition. Make the the plugin is installed and enabled (in /etc/yum/pluginconf.d/priorities.conf)!
>
>
When a third-party repository is configured, use the yum-priorities plugin to configure the "stock" repositories to have a higher priority (lower number) than the third-party repo. This keeps the third-party repo from unexpectedly upgrading the distro beyond recognition. Make sure the plugin is installed and enabled (in /etc/yum/pluginconf.d/priorities.conf)!

Our convention for priority numbers is:

Line: 64 to 64

  1. I checked to see if there was a CentOS update that got missed somehow:
    yum list updates subversion
  2. Nope. Okay, next was to check to see if RPMForge had something newer:
Changed:
<
<
yum --enablerepos=rpmforge list subversion
>
>
yum --enablerepo=rpmforge list subversion

  1. Yup, that found a newer version than what CentOS had -- the 1.2 Paul was looking for. Okay, so after checking with Paul (and making sure no one else was logged in), I ran the update:
Changed:
<
<
yum --enablerepos=rpmforge update subversion
>
>
yum --enablerepo=rpmforge update subversion

And that was about it.

 <<O>>  Difference Topic ServerSoftwareInstall (r1.6 - 31 May 2009 - BenScott)

META TOPICPARENT InternetServer
TOC: No TOC in "Organizational.ServerSoftwareInstall"
Line: 18 to 18

Furthermore, when going outside the distribution, try looking in "big name" repositories first. For example, RPMForge provides a large number of independent packages. We even have the RPMForce repository configured for YUM on liberty; it just isn't enabled by default. By keeping the number of places we have to go to to get software to a minimum, we again make updates and upgrades easier.

Added:
>
>

Repository priorities

When a third-party repository is configured, use the yum-priorities plugin to configure the "stock" repositories to have a higher priority (lower number) than the third-party repo. This keeps the third-party repo from unexpectedly upgrading the distro beyond recognition. Make the the plugin is installed and enabled (in /etc/yum/pluginconf.d/priorities.conf)!

Our convention for priority numbers is:

base/updates 10 The distribution core should have highest priority
extras/addons 15 These should technically only enable the RHEL-to-CentOS port, but just in case, let the core win
centosplus/contrib 20 These are packages added by the CentOS team which add functionality over RHEL
third-party repos 50 Anyone else

We skip numbers to allow fine-tuning as needed in the future.


Package kit storage

For packages which are downloaded manually (i.e., not via up2date or yum), the original package file (binary RPM, source tarball, whatever) should be stored under the /usr/local/adm/pkgs/ directory. This makes reinstalls easier, and reduces duplication of download.

 <<O>>  Difference Topic ServerSoftwareInstall (r1.5 - 10 Nov 2007 - BenScott)

META TOPICPARENT InternetServer
TOC: No TOC in "Organizational.ServerSoftwareInstall"
Line: 36 to 36

Installing Perl modules is frequently needed. A third-party tool called cpan2rpm is installed to make this much easier. In short, running cpan2rpm Foo::Bar will automatically download, build, and package that module from CPAN, resulting in RPM and SRPM files which can be installed on any RPM-enabled system.

Added:
>
>

Python setup.py bdist_rpm

There is a way to build RPM packages out of Python packages, provided the Python package includes the needed "setup.py", and possibly (depending on complexity of the package) a manifest. Download and unpack the Python source kit distribution, and then issue the command python setup.py bdist_rpm. That should result in a dist subdirectory containing RPM and SRPM files.


Examples

Using RPMForge

 <<O>>  Difference Topic ServerSoftwareInstall (r1.4 - 19 Apr 2006 - BenScott)

META TOPICPARENT InternetServer
Added:
>
>
TOC: No TOC in "Organizational.ServerSoftwareInstall"

Policies

Package management

Changed:
<
<
Generally speaking, it is preferred to keep all install software under package management, i.e., RPM. Mostly because it makes software maintenance much easier. Old and obsolete files get removed during upgrades and/or uninstalls. You can verify administrative integrity easily ("rpm -V"). You can figure out where files come from ("rpm -qf").
>
>
Generally speaking, it is preferred to keep all install software under package management, i.e., RPM. Mostly because it makes software maintenance much easier. Old and obsolete files get removed during upgrades and/or uninstalls. You can verify administrative integrity easily (rpm -V). You can figure out where files come from (rpm -qf).

Changed:
<
<
When building packages from source, it is thus considered a best practice to build an RPM package and install that, rather then using a simple "make install". These days, many upstream authors provide the RPM .spec files needed in their source distribution. In other cases, one can find a third-party who provides a .spec or SRPM file. In these cases, buidling an RPM becomes almost trivial.
>
>
When building packages from source, it is thus considered a best practice to build an RPM package and install that, rather then using a simple make install. These days, many upstream authors provide the RPM .spec files needed in their source distribution. In other cases, one can find a third-party who provides a .spec or .srpm file. In these cases, buidling an RPM becomes almost trivial.

Changed:
<
<
For Perl modules, see "cpan2rpm", below.
>
>
For Perl modules, see cpan2rpm, below.

Package repositories

Line: 16 to 18

Furthermore, when going outside the distribution, try looking in "big name" repositories first. For example, RPMForge provides a large number of independent packages. We even have the RPMForce repository configured for YUM on liberty; it just isn't enabled by default. By keeping the number of places we have to go to to get software to a minimum, we again make updates and upgrades easier.

Added:
>
>

Package kit storage

For packages which are downloaded manually (i.e., not via up2date or yum), the original package file (binary RPM, source tarball, whatever) should be stored under the /usr/local/adm/pkgs/ directory. This makes reinstalls easier, and reduces duplication of download.

Unmanaged installs

For software which is not under package management (e.g., installed via make install), the software should either be installed into the integrated /usr/local/ tree, or under a directory under /opt/. For example, if we had to build Apache from source, we whould end up with one of /usr/local/sbin/httpd or /opt/apache/bin/httpd for the main binary. As of this writing, a preference between the two has not been established. However, unmanaged software should not be installed under /usr/ (which is reserved for managed software).


Tools

rpm, yum, and up2date

Changed:
<
<
The standard tool for package management on Red Hat-derived systems is "rpm". For dependency management and package retrieval, Red Hat provided "up2date", which works just fine on CentOS. The third-party "yum" tool is also provided with CentOS. Both "up2date" and "yum" are configured to pull from the same CentOS repository mirrors, and can be used interchangeably.
>
>
The standard tool for package management on Red Hat-derived systems is rpm. For dependency management and package retrieval, Red Hat provided up2date, which works just fine on CentOS. The third-party yum tool is also provided with CentOS. Both up2date and yum are configured to pull from the same CentOS repository mirrors, and can be used interchangeably.

cpan2rpm

Changed:
<
<
Installing Perl modules is frequently needed. A third-party tool called "cpan2rpm" is installed to make this much easier. In short, running "cpan2rpm Foo::Bar" will automatically download, build, and package that module from CPAN, resulting in RPM and SRPM files which can be installed on any RPM-enabled system.
>
>
Installing Perl modules is frequently needed. A third-party tool called cpan2rpm is installed to make this much easier. In short, running cpan2rpm Foo::Bar will automatically download, build, and package that module from CPAN, resulting in RPM and SRPM files which can be installed on any RPM-enabled system.

Examples

Line: 34 to 44

Since not everyone here is familiar with yum, here is how it was done:

Changed:
<
<
  1. I checked to see if there was a CentOS update that got missed somehow: yum list updates subversion
  2. Nope. Okay, next was to check to see if RPMForge had something newer: yum --enablerepos=rpmforge list subversion
  3. Yup, that found a newer version than what CentOS had -- the 1.2 Paul was looking for. Okay, so after checking with Paul (and making sure no one else was logged in), I ran the update: yum --enablerepos=rpmforge update subversion
>
>
  1. I checked to see if there was a CentOS update that got missed somehow:
    yum list updates subversion
  2. Nope. Okay, next was to check to see if RPMForge had something newer:
    yum --enablerepos=rpmforge list subversion
  3. Yup, that found a newer version than what CentOS had -- the 1.2 Paul was looking for. Okay, so after checking with Paul (and making sure no one else was logged in), I ran the update:
    yum --enablerepos=rpmforge update subversion

And that was about it.

 <<O>>  Difference Topic ServerSoftwareInstall (r1.3 - 18 Apr 2006 - BenScott)

META TOPICPARENT InternetServer

Policies

Package management

Changed:
<
<
Generally speaking, it is preferred to keep all install software under package management, i.e., RPM. Mostly because it makes software maintenance much easier. Old and obsolete files get removed during upgrades and/or uninstalls. You can verify administrative integrity easily ("rpm -V"). You can figure out where files come from ("rpm -qf"). And so on.
>
>
Generally speaking, it is preferred to keep all install software under package management, i.e., RPM. Mostly because it makes software maintenance much easier. Old and obsolete files get removed during upgrades and/or uninstalls. You can verify administrative integrity easily ("rpm -V"). You can figure out where files come from ("rpm -qf").

When building packages from source, it is thus considered a best practice to build an RPM package and install that, rather then using a simple "make install". These days, many upstream authors provide the RPM .spec files needed in their source distribution. In other cases, one can find a third-party who provides a .spec or SRPM file. In these cases, buidling an RPM becomes almost trivial.

Added:
>
>
For Perl modules, see "cpan2rpm", below.

Package repositories

Generally speaking, it is preferred to stick with the software the distribution provides, unless there are good reasons to use a third-party package. Sticking to a single source of software means security updates and system upgrades become hugely easier. There will, of course, be reasons to go outside the distribution.

Changed:
<
<
Furthermore, when going outside the distribution, try looking in "big name" repositories first. For example, RPMForge provides a large number of independent packages. We even have the RPMForce repository configured for YUM on liberty; it just isn't enabled by default. By keeping the number of places we have to go to to get software to a minimum, we again make system upgrades easier.
>
>
Furthermore, when going outside the distribution, try looking in "big name" repositories first. For example, RPMForge provides a large number of independent packages. We even have the RPMForce repository configured for YUM on liberty; it just isn't enabled by default. By keeping the number of places we have to go to to get software to a minimum, we again make updates and upgrades easier.

Tools

rpm, yum, and up2date

The standard tool for package management on Red Hat-derived systems is "rpm". For dependency management and package retrieval, Red Hat provided "up2date", which works just fine on CentOS. The third-party "yum" tool is also provided with CentOS. Both "up2date" and "yum" are configured to pull from the same CentOS repository mirrors, and can be used interchangeably.

cpan2rpm

Installing Perl modules is frequently needed. A third-party tool called "cpan2rpm" is installed to make this much easier. In short, running "cpan2rpm Foo::Bar" will automatically download, build, and package that module from CPAN, resulting in RPM and SRPM files which can be installed on any RPM-enabled system.


Examples

 <<O>>  Difference Topic ServerSoftwareInstall (r1.2 - 02 Apr 2006 - BenScott)

META TOPICPARENT InternetServer
Added:
>
>

Policies


Changed:
<
<
Subversion has been updated to 1.2.1-0.1.2.el4.rf from RPMForge.
>
>

Package management


Changed:
<
<
Since not everyone here is familiar with yum, here's how I did it:
>
>
Generally speaking, it is preferred to keep all install software under package management, i.e., RPM. Mostly because it makes software maintenance much easier. Old and obsolete files get removed during upgrades and/or uninstalls. You can verify administrative integrity easily ("rpm -V"). You can figure out where files come from ("rpm -qf"). And so on.

When building packages from source, it is thus considered a best practice to build an RPM package and install that, rather then using a simple "make install". These days, many upstream authors provide the RPM .spec files needed in their source distribution. In other cases, one can find a third-party who provides a .spec or SRPM file. In these cases, buidling an RPM becomes almost trivial.

Package repositories

Generally speaking, it is preferred to stick with the software the distribution provides, unless there are good reasons to use a third-party package. Sticking to a single source of software means security updates and system upgrades become hugely easier. There will, of course, be reasons to go outside the distribution.

Furthermore, when going outside the distribution, try looking in "big name" repositories first. For example, RPMForge provides a large number of independent packages. We even have the RPMForce repository configured for YUM on liberty; it just isn't enabled by default. By keeping the number of places we have to go to to get software to a minimum, we again make system upgrades easier.

Examples

Using RPMForge

Subversion was, on one iteration of the system, upgraded to 1.2.1-0.1.2.el4.rf from RPMForge.

Since not everyone here is familiar with yum, here is how it was done:


  1. I checked to see if there was a CentOS update that got missed somehow: yum list updates subversion
  2. Nope. Okay, next was to check to see if RPMForge had something newer: yum --enablerepos=rpmforge list subversion
Line: 11 to 28

And that was about it.

Added:
>
>
META TOPICMOVED BenScott? date="1144035907" from="Organizational.ServerPackageUpdating" to="Organizational.ServerSoftwareInstall"
 <<O>>  Difference Topic ServerSoftwareInstall (r1.1 - 23 Feb 2006 - BruceDawson)
Line: 1 to 1
Added:
>
>
META TOPICPARENT InternetServer

Subversion has been updated to 1.2.1-0.1.2.el4.rf from RPMForge.

Since not everyone here is familiar with yum, here's how I did it:

  1. I checked to see if there was a CentOS update that got missed somehow: yum list updates subversion
  2. Nope. Okay, next was to check to see if RPMForge had something newer: yum --enablerepos=rpmforge list subversion
  3. Yup, that found a newer version than what CentOS had -- the 1.2 Paul was looking for. Okay, so after checking with Paul (and making sure no one else was logged in), I ran the update: yum --enablerepos=rpmforge update subversion

And that was about it.

View topic | Diffs | r1.7 | > | r1.6 | > | r1.5 | More
Revision r1.1 - 23 Feb 2006 - 10:20 - BruceDawson
Revision r1.7 - 22 Jan 2012 - 23:16 - BenScott