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:
- 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.
- 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.
- 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.
- 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