On Thu, 25 Apr 2002, James Olin Oden wrote:
> >
> > On Thu, 25 Apr 2002, James Olin Oden wrote:
> > >
> > The /opt/package/{etc,bin,man} practise can lead to quite riducule
> > length with PATH, MANPATH etc. components when you have plenty
> > of softare in your system, so beware.
> >
> Agreed, but there are times when you don't want your stuff to go in the
> same place as a distributions stuff, if only to keep a serperate "namespace"
> for your applications.
>
Exactly, the three separate domains; system distribution,
third party and local stuff should all be kept separate.
See http://www.pathname.com/fsh/ unless you haven't yet.
My point is that some care should be taken with
deploying /opt too, it's no panacea per se.
I've done quite large NMS setup with HP-UX and Solaris,
(set up NOC for large a telecom from ground up) and seen
what kind of problems /opt, /etc/opt, /var/opt scheme can
lead with shared volumes on a cluster. No fun, seriously.
But the largest problem with Red Hat & RPM system usage I see
is that most third party packages (contribs etc) still goes
under system distribution filespace, usually at /usr :(
Somehow the usage of /opt seem to be either too difficult or
unknown to many.
I don't know what would be best way promoting /opt use to
packagers, possibly some kind of consistency check-tool from
system distributor that would check wether the system and
package is tainted unless it follows FHS.
The tool would simply verify that package signature matches on
system distributor signature and if not it would check if it does
have files placed proper places or not.
Dunno, someone else has better idea?
The best point of keeping things separate is that it
provides best means for planning the disk usage for
long term and not running in to the large problems with
patches and upgrades in future.
LVM will ofcourse help you with that, but will cause some
suffling and juggling unless you have spare extents and need
to resize existing partitions. Here LVM is no solution, it's
just nice workaround for the problem, the real problem still
persists and will bite you later :/
> > Most common problems I have met are:
> >
> > - when reinstalling you often have duplicate paths added.
> >
> > - I've met many times // had been added there.
> >
> > - does not provide means of checking first that the
> > filesystem is mounted before reference to path is added
> >
> > This was just to point that the HP-UX practis IMHO is far
> > from ideal.
> >
> Sure, and that is why I was suggesting some sort of distribution tool
> to help handle this. In this way the packager does not right his or her
> own possbibly buggy tool handle this, but the maintner of the distribution
> provides a utility that handles this bug free (OK I'm dreaming).
>
Sure you are dreaming ;)
The same problem exist with *many* files especially under /etc,
think /etc/services, /etc/rpc, etc. xinetd has made life little
easier than it was with /etc/inetd.conf though.
> > I don't think you need that stuff at all ...
> >
> > I'd prefer this stuff done at /etc/profile.d/ with appropriate
> > scripts, those are executed after login.
> >
> I would prefere this too, but after re-reading the gnu man.config and man
> man pages, and the comments in /etc/man.config, I am positive that the
> behaviour you get from the man is if the MANPATH is set (which you would do
> in a /etc/profile.d script) it will ignore man.config. I do not want
> /etc/man.config ignored. I want to inherit the good work at RedHat, not
> go on my own. If on the other hand one in their RPM (because profile.d
> will not get you there) edits the /etc/man.config file you run into the
> same issues you mentioned with programs on HP that each on their own
> (rather than through a distribution supplied program) edit the MANPATH
> file.
>
IMHO, best way I can think would be to enhance GNU man to
support include directory, like xinetd with /etc/xinetd.d,
logrotate with /etc/logrotate.d etc.
Thus patch it use /etc/man.config.d if it already doesn't
and contrib to project :)
> > esac
> >
> Nice code, but it assumes that you know what should be on the system before
> you alter things (at least thast was my cursory reading). At best you could
> get it tuned to a particular release of a distribution, but as soon as the
> maintaineers of the distribution alter man.config or the sysadmin does
> all bets are off.
>
See my suggestion of /etc/man.config.d above.
The code was just simple example how to edit PATH style
variables preserving portability. Not 1:1 solution to
your answer. Sorry if I wasn't clear on it.
I'm often more on design than a straight forward solution,
but you are right GNU man does not support /opt/*/man well,
hey that could be another way, enhance the GNU man to support
wildcards with glob() ... something like this
$ cat <<EOF >globtest.c
#include <stdio.h>
#include <glob.h>
int main(int argc, char *argv[])
{
glob_t foo;
char **t, *prog;
while (*++argv) {
if (!glob(*argv,0, NULL, &foo)) {
for (t = foo.gl_pathv; *t ; t++)
printf("%s\n",*t);
} else
printf("%s\n",*argv);
globfree(&foo);
}
return 0;
}
EOF
$ make globtest
$ make globtest
cc globtest.c -o globtest
$ ./globtest "/opt/*/man"
/opt/tcm/man
Glob support together with /etc/man.config.d would
solve the problem nicely, right?
Anyone can find possible security implications of adding
glob support to MANPATH and root writable /etc/man.config.d?
Don't think GNU man is not SUID-root or SGID-man any
recent distribution or is it?
> > It's shame that all Unix vendors have not yet
> > picked setting the POSIX shell for root, it
> > would make our lives much easier :|
> >
> Of topic, but yeah I agree. You know the only problem is you could use
> the other shells, but Sun only provides sh statically linked (and in
> a bad situation that is _so_ very important.
>
Right OT, but the HP-UX root shell is a /sbin/sh, which is
*statically linked* POSIX shell, I don't see any problem
with that :)
The /bin/sh is the dynamically linked POSIX shell like the
/usr/bin/ksh (Version M-11/16/88i) is the Korn 88 shell,
and /usr/dt/bin/dtksh (Version M-12/28/93d) aka Korn 93
shell.
I just wish that Sun would follow HP and replace /sbin/sh
with *real* POSIX compatible shell on Solaris 9, another
matter would be to finally clean up the /etc/rc[0-6].d and
/etc/init.d mess, it would be about the time!
:-) riku
--
[ This .signature intentionally left blank ]
