On Thu, Jul 10, 2008 at 6:41 AM, Janne Blomqvist <[EMAIL PROTECTED]> wrote: > Jay Turner wrote: >> >> Anyway, I would like to take this opportunity to offer a side trip with >> this thread. What do people need/want in RHEL6? > > - Minimal install. I suppose for a workstation (especially if they are > end-user installed/managed) a "batteries included" approach makes sense. But > IMHO for servers it's better to start with a barebones install and add stuff > on top as needed. E.g. over here we like to install servers by starting with > a generic base install, and then have each server install and configure > additional stuff via cfengine. >
having a clear build process. sure we can use rhn (if our networks can reach it)... but having cobbler be a first class citizen and a post config management would be helpful for those who can't. > - From a security standpoint, in addition to the minimal install above, make > SELinux easier to use and manage. Too often it seems that disabling selinux > completely is the first thing people suggest when they hear of some problem, > whether it actually helps or not. This is the equivalent to the "chmod 777 > -R" school of fixing permission problems. > actually the one I run into is chmod 1777 /bin/*sh or echo "fixunix::0:0:FixStupidUnixCrap:/:/bin/bash >> /etc/passwd > - Make it easier to run a "domain" with centralized pam & nss databases. I > suppose integrating IPA would be the solution to this. I can only wonder why > it has taken so long, for something which must be standard operating > procedure for any network bigger than "a few boxes in mommy's basement". In my experience, every site does it differently and wants their site's way being the one true way of doing it. I have NIS, NIS+, AD, LDAP, Andrews, and god knows what else running at various sites I have been at with each person saying their way is better than the others. And every time a Linux vendor 'chooses' one solution you get an immediate backlash from all the sides that didn't get chosen. [SuSE had this happen a long time back...] > Also on the client end there is lots of stuff to do in addition to just > configuring pam_krb5/pam_ldap and nss_ldap. E.g. tools that expect > everything to be in the /etc plain text files such as useradd, chage etc (or > does IPA already include replacements for these?). And nss_ldap + nscd seems > quite flaky, both due to bugs and deficiencies in the POSIX API; perhaps > nsscache (http://code.google.com/p/nsscache/) could be the solution here? > > - With IPA available, it would be nice if kerberized NFSv4 would be the > default for NFS, and easy as pie. AUTH_SYS is just a travesty.. > > - Tools to manage multiple machines. While we use cfengine here, puppet as > the heir apparent to cfengine seems to be the obvious choice. It seems RHN > satellite had some config management functionality as well, but when we > evaluated it, it lacked some critical functionality so we went with cfengine > instead. Going from the pragmatic into pipe dream territory, it would be > nice to configure services without having to learn a different config syntax > for every service, some support for sanity checking (e.g. parameter foo must > be an integer between 0 and N). There is this whole WBEM thing, and RHEL has > the pegasus and sblim stuff, but does anyone use it? > I would like func to get a deep down security audit to make sure various paranoids feel ok with it. > - ext4 and/or btrfs. In general we're content with ext3, the 16 TB limit is > getting closer but we can work around it with a moderate amount of pain. But > fsck time for a big fs is a real concern. ext4 will apparently have some > moderate fsck improvements, but the real deal seems to be btrfs which > promises online fsck (and very fast offline fsck) as well as checksumming > of both data and metadata. Though I'd be surprised if btrfs is deemed > production ready in time for RHEL6. > > - Rethink the server/client split. Sometimes it would be useful to have the > client packages available for server, e.g. shell servers. Conversely, > developers/admins might need the server stuff to experiment with on their > workstations. E.g. make a common base channel, and allow a single system to > subscribe to, say, base+server, or base+workstation+server, > base+server+clustering or whatever. > > -- > Janne Blomqvist > > _______________________________________________ > rhelv5-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv5-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
