david david@daku.org writes:
I'm sure the Centos team has done a yeoman's job getting Centos7 ready, and that the Redhat team has done marvels in creating rhel7, but here's a little voice from a personal hobbyist user.
I'm not sure why you're voicing these here. Since CentOS matches RHEL bug-for-bug, you'd stand a better chance of getting your voice heard by talking to Red Hat.
If someone has some elegant solution, I'd love to try, but Centos7 is still unusable for me.
Define "unusable". Clearly it's objectively untrue that it's "unusable" because many people are in fact using it.
1: Firewall changes The change in firewall technology forced a complete re-do of my scripts which maintain firewalls, respond to attacks, etc. I think I've programmed my way around the issues, but it wasn't easy.
So...you've already done the work to adapt your current setup.
2: Apache changes These were subtle, but again were solved.
Not sure what you're referring to here, but again, you've already done the work.
3: Service -> systemd The change from object-oriented view of service: (service httpd restart) to function-oriented (systemctl restart firewall) seems to be unnecessary, and counter to the way stuff is generally done in the modern world. Nonetheless, it was possible to solve that with some adaptive script programming.
systemd, like it or not, appears to be the current future of Linux, with essentially every distribution adopting it. I can't say I'm a huge fan of this trend, but it is what it is. And again, you've already done the work.
- Something with Unknown lvalue 'ControlGroup' in section 'Service'
I don't know what to do with this. I constantly get the diagnostic: [/usr/lib/systemd/system/rtkit-daemon.service:32] Unknown lvalue ControlGroup' in section 'Service' and attempts to browse the internet for solutions come across barriers that require some paid subscription to view. This is currently a progress-stopper. The messages I see deal with boinc, which does not show up on my system using "rpm -qa | grep -i boinc".
A quick glance at https://bugzilla.redhat.com/show_bug.cgi?id=999986 makes this look to be primarily a logging issue. Obviously it should get fixed, since it's a bug, but I don't understand why this is a "progress-stopper". Or am I misreading?
- Sendmail is out, postfix is in.
This is a huge change, since I had lots of scripts that tailored the Sendmail system for spam protection, dealing with SmartHosts that required SMTP-AUTH and others required weird configurations, etc. Whether this is working yet I don't quite know, but it seems the scripts can accommodate the change.
# yum install sendmail{,-cf,-doc}
- Installation
I have no idea why, when using the net-install, one must explicitly turn on the network. It seems unnecessary.
That's a fair point, but presumably one Red Hat would have to answer.
- Lack of 32-bit support
I think I understand this. After all, 32-bit machines may become "unusable" when the clock overflows, but isn't that a few years away, and couldn't some solution be found, even if kludgy? Some of the 32-bit hardware was of very high quality, and still runs perfectly. I'd hate to spend a few hundred dollars each to replace all those systems.
As far as I know, there's no solution to be found. The 32-bit address space is just too small. Wikipedia says that 64-bit processors have been around since 1961, though for most uses (i.e., Intel/AMD) they only became practical starting in 2003, which is still over a decade ago.
Practically speaking, at some point you'll inevitably have to replace those systems anyway. Wouldn't you rather do it on a planned schedule than as disaster recovery when something fails? When doing so, you might as well go to 64-bit.
- And more
Don't know what this means.
I haven't got a server or desktop running to my satisfaction yet, so I don't yet know what pitfalls await. Any advice would be appreciated.
My advice is to read the documentation.