On Tue, Feb 18, 2003, Vinod Kutty wrote:
> Just looking for suggestions on:
>
> 1. Naming the root dir of an openpkg installation?
>
Re Vinod,
i already tried some variants in the past and here's my current personal
proposal. It's all based around the factors
- OpenPKG's location id that makes it into the filename of binary RPMs
- my lazyness when typing path names in bash and
- availability (!downtime) of a project's software environment.
If the installation path is directly under the root, the location id is
build from the first letters of this pathname.
Otherwise if the installation path involves subdirectories it is build
by concatenating the first letter of the subdirectory names along the
path.
Anyway, the location id is cut off after three characters max. This
enforces uniqness within the first three letters in flat root instances
or the first letter of the first three directory names in hierarchical
instances.
1st character
I install the OS and try to stick with the defauls wherever
possible. The rule is that defaults don't have to be documented :-)
In addition to the default OS filesytem layout, a large working disk
space makes it into a separate filesystem which is mounted to a very
short, usually one-letter, path. This can be networked filesystem.
Example: /c
2nd charcater
Every project get's a name and this makes up the directory name.
The first letter should be unique across projects, guess why ...
The project directory holds the actual data in properly structured
subdirectories and that structure is entirely depend on the project.
This could be a document_root/ folder with HTML files and CGI
scripts, a CVS checkout directory, sometimes it's only symlinks to
other places in the system or network etc.
Example: /c/development/ with
/c/development/sources/ and
/c/development/ftp/ and
/c/development/www/
3rd character
Inside every project there is at least one directory dedicated to
the software needed by the project. Of course, the software is
managed by OpenPKG. The name of the instance is "1sw" for the first,
"2sw" for the second attempt etc.
Example: /c/development/1sw/
Gain in Bash
I only have to type "/c/d" TAB "1" TAB to get to the correct OpenPKG
path.
Gain for Backup
The wholly project data can be backed up by saving /c/development/.
The configuration of the project software can be backed up by saving
/c/development/[0-9]sw/etc/.
Gain for OpenPKG location id
The /c/development/1sw/ examples above lead to the OpenPKG location
id -cd1- which is unique across the wholly deployment as long as all
rules above have been taken into account.
Gain for OpenPKG upgrades
If the software required to run a project is easy and simple to
maintain, it's availablilty is totally noncritical and the knowledge
of the OpenPKG adminstrator is high than any upgrade of OpenPKG
software just means upgrading the OpenPKG package(s) on the fly.
However, if the behaviour of the upgrade cannot be easily determined
or the presence of the project is critical it's time for a "2sw"
instance to be build and configured in parallel. It's easy to start
configuration as it can be done by diffing between "1sw/etc/*" and
"2sw/etc/*". Both installations might point to the same real data
through links or copies of the data can be used easily as well.
Depending on the lessons learned when creating the "2sw" hierarchy,
the "1sw" later needs to be upgraded or the "2sw" can take over. The
latter allows to go back if real live experience would require it.
My past experience was that it is very helpful that OpenPKG supports
running multiple similar, in fact identical up to the IP address,
instances at the same time. I consider this a major underestimated
opportunity for OpenPKG administrators.
The same is true when it comes to finding the correct configuration
files. They can always be found at a easily predetermined location.
And finally this is also true for variable data like logfiles, which the
fake syslog library forces to be written to a predetermind location as
well.
Regarding major upgrades, independent if they're major OpenPKG or major
vendor upgrades, my structure described above supports both the
adventurer and the reluctant administrator. I've successfully upgraded
some typical tools-mail-web-cvs installations from OpenPKG v1.1 to v1.2
by just installing "openpkg-tool" from v1.2 into the existing v1.1
instance and let it go. A little hunt for "*.rpmsave" files and some
manual tweaking and it was done.
I would not recommend naming any hierarchy by it's OpenPKG version
number unless the version itself is the goal of the game, i.e. when
you're doing OpenPKG packaging and want to see whether your package
(change) smoothly runs on different OpenPKG versions. The OpenPKG team
has to do this when creating security advisories for a package or when
it's doing compatiblity testing accross platforms and versions (poor
man's quality assurance).
> 2. Customized rpm naming
>
I gave up on this and stick to the RPM querying for detailed build
options which have been used to build a binary. Seeing the options
which have been used is not required for unique project installations
anyway. However, i understand it will be useful in "build binary once,
deploy multiple times" scenarios. But even then, the multiple similar
installations must have an identical directory structure so thinking
about the location id would be useful here as well.
--
[EMAIL PROTECTED]
Development Team, Operations Northern Europe, Cable & Wireless
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
