david <david@xxxxxxxx> 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.
> 4) 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?
> 5) 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}
> 6) 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.
> 7) 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.
> 8) 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
