On 08/31/2010 12:19 PM, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 31 August 2010 at 11:35, Leam Hall wrote:
[...]
> Long term support would be very useful, as would:
>
> 1. Minimal OS build that fit onto one CD per ARCH.
> a. That build allowed ssh, vi, yum, and networking so updates and adds
> were easy.
> b. That build had a kernel that was less full. Most servers don't use
> Bluetooth, for example.
A quick idea: join the kernel maintainers team and create
a kernel-server subpackage with a minimal config.
The server is much more than the kernel. However, good idea and
something to keep in mind.
> 2. Application packages that installed in FHS compliant
application
> filesystems vice OS filesystems. For example, apachectl should not be in
> /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in
> /opt/httpd/logs.
Um, no. There are reasons why we don't package anything in /opt.
Compared to /usr? I've not found a single one. Anything that the server
must have to boot, care for itself, and let you log in and edit config
files should be in /bin:/sbin:/usr/bin:/usr/sbin. Everything else goes
in /opt. The point being that /opt is a seperate filesystem and you can
unmount it, fsck it, and do whatever with it without taking down the server.
> a. Those filesystems, like "/opt" and /srv", should be seperate
> filesystems.
> b. Applications that fill up their own space do not crash the server.
I think you've just reinvented quotas, badly.
Nope. Think of it like this. Your OS is X gig of space. If you use LVM
then it's in a VG. The average hard drive today is huge. Allocate ~20G
for the OS (using curently overly large F13 installs) and everything
else for the applications. The app buys whatever space they need outside
of the base disks. That lets you export your apps to, if you like, :)
> c. Applications can be backed-up seperately from the OS and
then moved
> quickly in case of disaster recovery or server consolidation.
With rpm packages you don't need to back-up the applications, only
configuration files, data and logs. Installing applications in separate
directory trees doesn't improve the situation a lot.
It improves it tremendously. Not all applications are in RPM format. Not
all applications fit best with the latest version so that means you have
to set up your own repositroy using just the versions you want. Besides,
if I have to back up config files, data, and logs, why not the entire
bundle? Saves time and hassle in a recovery.
> 3. Base OS packages that needed very little outside what was in
the Base
> OS enclave.
> a. There would probably be multiple levels of inclusion. For example,
> Python should not be in the base OS but should be one of the first tools
> installed afterwards.
A rephrasing of 1.a.?
Extension, though driving in to work I rememberd that yum is python
based. The core gets the server up and accessible. The next layer gets
the server tols like python, yum, kernel src, etc. Stuff that's nice to
have but you can live without it if necessary.
> 4. Documentation that favored command line solutions vice GUI
tools.
Well, someone needs to write that documentation.
Yup.
I think the low-hanging fruit is working on reducing package
interdependencies. There's an ongoing effort, which is and will be of
benefit to both Server and Mini SIGs.
Agreed.
> Interestingly, I can see one advantage Fedora-Server would have over
> something like CentOS; more frequent critical OS updates would allow
> usage in secure environments where latest kernel and other security
> patches must be applied soon after their availability.
RHEL solves that by backporting. We can't and won't do that due to
lack of manpower, so yes, it can be seen as an advantage.
On the other hand, new versions sometimes come with new bugs,
so I wouldn't push the "enterprise" angle too much. :)
Problem is not solved when you have to document that you're using
version SomePackage 3.5.4 or higher. THere are places that just have no
awareness and I've been in a few. Also, note that security
vulnerabilities still come out after RHEL/CentOS is no longer providing
or prioritizing those back ports.
Leam