[I don''t really have a good description of the focus of this list.
However this stuff I think is relevant to the installation/configuration
of servers under RH (and I want all servers to be secure), so I''ll air
it
here and see how well I get toasted :-) ]
[copied to EWT directly]
We run a lot of servers under Red Hat, currently using 4.2 through 5.1 on
3 architectures.
One of the standard problems is installing the systems is getting a good
OS base to build on the application set we want. Ideally this should be
as far as possible be a standard RH package set rather than a custom
install image with lots of locally prepared RPMs (I''m not in the
business
of making and maintaining lots of base RPMs as well as our application
set).
I think that with a little care, the package set offered by RH could be
made more suitable for server use without degrading its utility for
desktop use.
So here are my current wishes for the RH distribution to make it better
fit our needs - I hope they gel with what other people need:-
1. Smaller packages - ie finer granularity, specifics for this are:-
a. findutils - split the locate/updatedb bits into a sub-package
[we upgraded some packages on a news server which then ran the
daily updatedb script which is a seriously bad idea on a huge fs]
b. netkit-base - ping is fine, but can inetd be split out
additionally can the inetd config file start inetd
*only* if /etc/inetd.conf exists.
2. Config decisions. Having xntp3 is great. Having a sneaky hard wired
set of servers in the startup file (not even the config) is less good.
Since all our boxes except special cases are slaves I tend to have
a set of server lines in ntp.conf and awk them into a list of servers
to ntpdate against in the startup script [incidently, setting the
hardware clock immediately after a successful ntpdate is useful]
Incidently, startup order: network->named->xntpd->crond is best
(otherwise cron can get upset if the time changes).
There are other examples of this... config items should be exposed
into config files clearly.
3. logrotate. Would be nice to be able to get old logfiles shoved into
a different directory (even just a subdirectory) [we keep lots of logs]
Also ability to cluster a set of logs - ie I want to rotate all the
apache logs then kill -HUP - sending a whole series of HUPs in a row
can upset (eg) mod_perl. [yes you can effectively do this by ordering
the statements correctly, but if logrotate changes it will break]
Other recent changes are *great* - we now actually use it all over.
4. X. I don''t think its possible to install a system that has X
clients
but no X servers at all. Also too many things seem to pull in X.
5. Dependencies. There are some weird ones around. The
lpr/print-filters/xbanner/xdm one is a touch odd (this is from memory,
so details may be wrong).
6. Base packages. Some are less base than others. I really hate the way
I get sendmail smashing a perfectly good mail config after an upgrade
because sendmail is in Base and all Base stuff is installed even where
it
conflicts with an existing package.
Really the fundamental point is that packages should be as small as
sensibly possible - OK having ls, df etc each in a separate package does
not make sense. However neither does having ping and inetd in the same
package make sense to us. Small packages with clearly thought out
dependencies would make things much cleaner...
Nigel.
--
[ Nigel.Metheringham@theplanet.net - Systems Software Engineer ]
[ Tel : +44 113 207 6112 Fax : +44 113 234 6065 ]
[ Real life is but a pale imitation of a Dilbert strip ]