Folks
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.
Background: ('ve been maintaining several remote servers since Redhat 6 days, migrating from that to Whitebox, then Centos, and things have been running as expected including the current version of Centos6. As an experiment, I've tried to play with Centos7 on an in-house virtual machine (VMWare on Win7), and have encountered a collection of annoyances greater than I've even seen. Below is a note about them. If someone has some elegant solution, I'd love to try, but Centos7 is still unusable for me.
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.
2: Apache changes These were subtle, but again were solved.
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.
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".
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.
6) Installation I have no idea why, when using the net-install, one must explicitly turn on the network. It seems unnecessary.
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.
8) And more ...
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.
David in San Francisco
On 10/31/2014 01:45 AM, david wrote:
Folks
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.
Background: ('ve been maintaining several remote servers since Redhat 6 days, migrating from that to Whitebox, then Centos, and things have been running as expected including the current version of Centos6. As an experiment, I've tried to play with Centos7 on an in-house virtual machine (VMWare on Win7), and have encountered a collection of annoyances greater than I've even seen. Below is a note about them. If someone has some elegant solution, I'd love to try, but Centos7 is still unusable for me.
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.
I used Shorewall on 5.x and 6.x so on 7.x I just disabled firewalld and installed shorewall. Btw. I haven't even tried to learn firewalld, to confusing and too lite time to waste.
2: Apache changes These were subtle, but again were solved.
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.
For me "service httpd restart" works just fine, automatic conversion works like a charm. I do get informed what command was run, but it DOES it's job.
- 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".
- 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.
I have been using Postfix from 5.x. The fact that you chose to use obsolete (from Red Hat's point of view) software should be on no one but you.
- Installation
I have no idea why, when using the net-install, one must explicitly turn on the network. It seems unnecessary.
- 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.
- And more
I would add idiotic Gnome 3 that does not have right click menu for creating launchers (copying .desktop files from /usr/share/applications? works like a charm but you need to create them manually for every launcher) and inability to place launchers and icons on top panel as infuriating.
Gnome extensions from Tweak Tool are very helpful in making Gnome 3 like home. I use about 10 of them. Adding Start Launcher tool is one of them.
...
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.
David in San Francisco
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, Oct 30, 2014 at 8:19 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
I have been using Postfix from 5.x. The fact that you chose to use obsolete (from Red Hat's point of view) software should be on no one but you.
That's just an arbitrary choice both on the default side and what you use. Both are available and usable.
- 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.
Might have something to do with using XFS as the default filesystem. It has trouble with the 4k stack choice that RH has used on 32-bit systems.
I would add idiotic Gnome 3 that does not have right click menu for creating launchers (copying .desktop files from /usr/share/applications? works like a charm but you need to create them manually for every launcher) and inability to place launchers and icons on top panel as infuriating.
More problematic, Gnome3 doesn't work remotely under x2go. You can use MATE from EPEL but even that isn't exactly like Gnome2.
Dear Experts,
On a couple of CentOS 7 workstations I noticed that user "(unknown)" is logged to local X11:
~]# last ... (unknown :0 :0 Wed Oct 15 14:40 still logged in ...
~]# who (unknown) :0 2014-10-15 14:40 (:0) ...
Of course, it is real user who is logged in, and his screen is locked (after some time of inactivity).
Is it just me, or other people saw this? Can somebody comment on this? It is quite likely that I just copied relevant to that person's account lines into /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow from different box. No, of course, not that bad, I indeed created the account, then just copied password hash. But I used /sbin/groupadd and /sbin/useradd command line utilities. Could that be the reason? If yes, are we to do everything trough GUI on CentOS 7? What do you, clever people, do to copy account from one machine (likely with different system, say, CentOS 6, or CentOS 5) to another (running CentOS 7)?
Thanks for all your answers.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, Oct 31, 2014 at 4:31 PM, Always Learning centos@u62.u22.net wrote:
On Fri, 2014-10-31 at 10:46 -0500, Les Mikesell wrote:
You can use MATE from EPEL but even that isn't exactly like Gnome2.
My impression from other posters was Mate as fairly similar to G2. Is it really much different ?
I don't use enough desktop GUI actions to be a good judge. I normally just open a bunch of terminal windows and ssh to other machines with an occasional instance of wireshark or firefox. But, for example, I thought I could just drag the terminal icon out of the Gnome2 menus onto the top menu bar or the desktop - but I couldn't do that in MATE.
On Fri, Oct 31, 2014 at 02:19:07AM +0100, Ljubomir Ljubojevic wrote:
I would add idiotic Gnome 3 that does not have right click menu for creating launchers (copying .desktop files from /usr/share/applications? works like a charm but you need to create them manually for every launcher) and inability to place launchers and icons on top panel as infuriating.
You may find https://extensions.gnome.org/extension/4/panel-favorites/ useful.
Gnome extensions from Tweak Tool are very helpful in making Gnome 3 like home. I use about 10 of them. Adding Start Launcher tool is one of them.
"Like home" is a good way of thinking about it. I use about 10 of them as well, but I bet they're very different.
On 10/31/2014 01:45 PM, david wrote:
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.
It's trivial to disable firewalld then all your old scripts will work just fine with iptables, just like they always have.
2: Apache changes These were subtle, but again were solved.
New version of apache, there have always been config changes between versions.
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.
The service command still works as a wrapper around systemctl. chkconfig won't work, but you probably won't be scripting that anyways. Other than that, I don't like systemd much either, but that topic has been talked to death.
- 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".
I have no idea bout this. Feel free to check bugzilla, and/or file a bug report.
- 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 remove postfix && yum install sendmail
Sendmail is still there, it's just not the default. If you prefer sendmail then by all means use it.
- 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.
I can understand this from RedHat's perspective, CentOS is workign on a 32 bit build, but it takes time.
Peter
On Thu, Oct 30, 2014 at 05:45:58PM -0700, david wrote:
Folks
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.
Background: ('ve been maintaining several remote servers since Redhat 6 days, migrating from that to Whitebox, then Centos, and things have been running as expected including the current version of Centos6. As an experiment, I've tried to play with Centos7 on an in-house virtual machine (VMWare on Win7), and have encountered a collection of annoyances greater than I've even seen. Below is a note about them. If someone has some elegant solution, I'd love to try, but Centos7 is still unusable for me.
<snip>
- 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.
FYI, you can install sendmail, it's still available if you want it, it is just no longer the default:
yum install sendmail
someday when I move my home system (combined workstation, play-on-it system, and server) to EL7 I'll be installing Sendmail, simply because I want to "leverage" all the pain I went through over the years to create my own sendmail.mc file, and don't feel like going thru it again with another MTA.
- Installation
I have no idea why, when using the net-install, one must explicitly turn on the network. It seems unnecessary.
I have quibbles with the new installer, and that's only a small-ish one. I think a "guided" install (like the old Anaconda) is much better because you don't have to guess what should be done next.
- 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.
I believe there are people working on this, it's just not yet ready for prime time. It's probably harder than it would have been simply becauase RH did not provide the info/scripts/tools for doing a 32-bit build.
<snip>
- 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.
I believe there are people working on this, it's just not yet ready for prime time. It's probably harder than it would have been simply becauase RH did not provide the info/scripts/tools for doing a 32-bit build.
An exercise in futility! Centos 6 will be supported until November 2020.
On Thu, Oct 30, 2014 at 05:45:58PM -0700, david wrote:
1: Firewall changes
Remove firewalld; install iptables. Problem solved. This has been discussed ad nauseum on this list recently.
2: Apache changes
Not RedHat specific issues; that's just progress from upstream.
3: Service -> systemd
This one _is_ nasty; it means you didn't properly use upstart in RH6, but then again who did? We all stuck with standard init scripts :-)
- Sendmail is out, postfix is in.
Only a default; sendmail is still there to install if you need it.
- 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,
You've misunderstood kernel support and "type" support. We've had 64bit filesizes for many years on 32bit kernels. Changing time_t to 64bits is independent of the hardware being 32 or 64 bit.
Basically, RHEL is Enterprise (the E); very very few enterprises have 32bit machines any more.
On Thu, Oct 30, 2014 at 8:33 PM, Stephen Harris lists@spuddy.org wrote:
Basically, RHEL is Enterprise (the E); very very few enterprises have 32bit machines any more.
Nobody is _buying_ 32 bit machines any more, but machines sold 10 years ago were surprisingly robust. It is just unfortunate that you can't keep software versions consistent across things even to a point where you could count on most of the same command lines working.
On 10/31/2014 08:53 AM, Les Mikesell wrote:
Nobody is_buying_ 32 bit machines any more, but machines sold 10 years ago were surprisingly robust
They were also surprisingly slow. Without any hyperbole, you could almost certainly replace an entire rack of ten year old 1U servers with a single 1U server today for a very reasonable cost and see performance that's at least equal, with a fraction of the power draw (and associated ongoing costs).
On 10/31/2014 10:48 AM, Gordon Messmer wrote:
On 10/31/2014 08:53 AM, Les Mikesell wrote:
Nobody is_buying_ 32 bit machines any more, but machines sold 10 years ago were surprisingly robust
They were also surprisingly slow. Without any hyperbole, you could almost certainly replace an entire rack of ten year old 1U servers with a single 1U server today for a very reasonable cost and see performance that's at least equal, with a fraction of the power draw (and associated ongoing costs).
easily, and even with the overhead of virtualization, have each of them be far faster.
I forcefully retired and virtualized any and all remaining 'netburst' (P4) architecture machines in my lab onto a 12 core nethalem based box and each one is way faster even when they are all being blasted at once. SAS rather than SCSI is more robust and reliable (10 year old SCSI cables are fun sources of random glitches).
On 11/01/2014 06:48 AM, Gordon Messmer wrote:
On 10/31/2014 08:53 AM, Les Mikesell wrote:
Nobody is_buying_ 32 bit machines any more, but machines sold 10 years ago were surprisingly robust
They were also surprisingly slow. Without any hyperbole, you could almost certainly replace an entire rack of ten year old 1U servers with a single 1U server today for a very reasonable cost and see performance that's at least equal, with a fraction of the power draw (and associated ongoing costs).
There is an assumption here that someone would only want to use CentOS on the server. I have at least two old laptops in my house that I would love to put CentOS 7 on, giving them decent software and then not having to worry about upgrading the distro for ten years which gives the OS a lifespan comparable to a windows version, I can't though, because they're 32 bit. This is also a good way to re-purpose an old laptop or desktop for the underprivileged to use.
Another thing to consider is that there are still people who want to put a 32 bit OS on a 64 bit VM instance, mainly because VMs tend to have a lot less RAM than you'd see on bare-metal hardware, and the savings in RAM usage of a 32 bit app vs 64 bit one can be significant. These would still be running on 64 bit hardware but using a 32 bit OS *on purpose*.
Peter
On 2014-10-31, Les Mikesell lesmikesell@gmail.com wrote:
Nobody is _buying_ 32 bit machines any more, but machines sold 10 years ago were surprisingly robust.
I am a notorious old hardware milker, and even I don't have any more 32bit hardware. By the time CentOS 6 is EOL you'd better have gotten rid of all your 32bit hardware!
--keith
On Fri, 2014-10-31 at 10:53 -0500, Les Mikesell wrote:
On Thu, Oct 30, 2014 at 8:33 PM, Stephen Harris lists@spuddy.org wrote:
Basically, RHEL is Enterprise (the E); very very few enterprises have 32bit machines any more.
Nobody is _buying_ 32 bit machines any more, but machines sold 10 years ago were surprisingly robust. It is just unfortunate that you can't keep software versions consistent across things even to a point where you could count on most of the same command lines working.
It is a shame to chuck-out perfectly good working machinery - just because someone, somewhere else, decided it should be redundant.
On 10/31/2014 2:35 PM, Always Learning wrote:
It is a shame to chuck-out perfectly good working machinery - just because someone, somewhere else, decided it should be redundant.
its a shame to waste 1000s of watts of electricity plus air conditioning on a rack full of old computers when a single new computer could replace the whole thing and only use a few 100 watts.
On Fri, 2014-10-31 at 18:32 -0700, John R Pierce wrote:
On 10/31/2014 2:35 PM, Always Learning wrote:
It is a shame to chuck-out perfectly good working machinery - just because someone, somewhere else, decided it should be redundant.
its a shame to waste 1000s of watts of electricity plus air conditioning on a rack full of old computers when a single new computer could replace the whole thing and only use a few 100 watts.
Excellent comment about rack-mounted equipment. Never-the-less, to throw-away (or recycle) working equipment seems to me to be a pity - but that is the reality.
Hopefully ? there is a Linux capable of providing conventional facilities on old, but working, 32-bit desktop and portable equipment which could be given to the needy people.
Hmm, I wonder when 128-bit processors will appear :-)
On 10/31/2014 8:38 PM, Always Learning wrote:
Hmm, I wonder when 128-bit processors will appear
a 32 bit address got us up to 4,000,000,000 (4 billion) bytes of directly addressible memory.
a 64 bit address gets you into a 18,440,000,000,000,000,000 byte address space. I think thats 18 zetabytes. It will be a long time before we'll need a larger address space.
On Fri, October 31, 2014 9:56 pm, John R Pierce wrote:
On 10/31/2014 8:38 PM, Always Learning wrote:
Hmm, I wonder when 128-bit processors will appear
a 32 bit address got us up to 4,000,000,000 (4 billion) bytes of directly addressible memory.
a 64 bit address gets you into a 18,440,000,000,000,000,000 byte address space. I think thats 18 zetabytes. It will be a long time before we'll need a larger address space.
Of course, the address space is the main consideration. There is one more property: "dynamic range" which is the ratio of maximum number you can use in operation to error (which is the value of least significant bit (LSB) multiplied by some small number the last depends on what kind of operation its is, let's say, you may loose LSB a few times during the operation). But this is really minor thing compared to the size of space one can address, as these can be achieved by programming several regular operations for each operation with "larger" numbers (or "higher precision" rather).
So, I would just echo what you said: we hardly will see the need in 128 bit CPUs soon. (BTW, I'm glad to hear the choice which is power of 2. As, in general, the length of CPU word can be anything: 17, 89, ... I'm not mentioning 1 which is used in calculators, as 1 _is_ power of 2 ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 11/3/2014 10:32 AM, Valeri Galtsev wrote:
So, I would just echo what you said: we hardly will see the need in 128 bit CPUs soon. (BTW, I'm glad to hear the choice which is power of 2. As, in general, the length of CPU word can be anything: 17, 89, ... I'm not mentioning 1 which is used in calculators, as 1_is_ power of 2;-)
I don't think any computer architectures have used word sizes other than a power of 2 multiple of bits in quite a long time, like since the 1960s. the DECsystem 10 and 20 were 36 bit word machines. The PDP8 was a 12 bit architecture. there are some low end embedded processors that are 4 bit (but thats a power of 2, also) but virtually everything resembling general purpose computing equipment in use today is 8/16/32/64 bits.
note I'm speaking of data size, I know there are numerous 'Harvard' architecture (separate code and data space) embedded machines with odd instruction word sizes. Even most of these use 4/8/16 word sizes.
On Mon, 2014-11-03 at 12:32 -0600, Valeri Galtsev wrote:
So, I would just echo what you said: we hardly will see the need in 128 bit CPUs soon. (BTW, I'm glad to hear the choice which is power of 2. As, in general, the length of CPU word can be anything: 17, 89, ... I'm not mentioning 1 which is used in calculators, as 1 _is_ power of 2 ;-)
Never experienced 17 or 89 bit machines. In the past I worked on 8 bit, 16 bit and a very large and expensive 36-bit machine (so expensive was it that the manufacturer offered bribes - my then boss's boss got caught and was allowed to resign with an unblemished record.)
Can not image cheap electronic calculators working with 1 bit CPUs.
Time to create a Centos OT mailing list ?
Once upon a time, Always Learning centos@u62.u22.net said:
Hopefully ? there is a Linux capable of providing conventional facilities on old, but working, 32-bit desktop and portable equipment which could be given to the needy people.
CentOS 6 didn't just disappear; it should still get updates through 2020 IIRC (by which time most of the 32 bit only hardware will probably have died). Just because the latest-greatest came out doesn't mean you have to upgrade to it.
On 10/31/2014 10:17 PM, Chris Adams wrote:
Once upon a time, Always Learningcentos@u62.u22.net said:
Hopefully ? there is a Linux capable of providing conventional facilities on old, but working, 32-bit desktop and portable equipment which could be given to the needy people.
CentOS 6 didn't just disappear; it should still get updates through 2020 IIRC (by which time most of the 32 bit only hardware will probably have died). Just because the latest-greatest came out doesn't mean you have to upgrade to it.
indeed. my old server at home still runs linux kernel 2.2.24, with an ipchains firewall on an old p3. it serves a few static html pages with apache 1.3. its an authoritative DNS server, with bind 9.6 that I built and configured by hand. I'm hoping to replace it with a pfSense firewall next week, and move my static webpages to my freeNAS box.
On 10/30/2014 07:45 PM, david wrote:
Folks
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.
Background: ('ve been maintaining several remote servers since Redhat 6 days, migrating from that to Whitebox, then Centos, and things have been running as expected including the current version of Centos6. As an experiment, I've tried to play with Centos7 on an in-house virtual machine (VMWare on Win7), and have encountered a collection of annoyances greater than I've even seen. Below is a note about them. If someone has some elegant solution, I'd love to try, but Centos7 is still unusable for me.
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.
2: Apache changes These were subtle, but again were solved.
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.
- 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".
- 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.
- Installation
I have no idea why, when using the net-install, one must explicitly turn on the network. It seems unnecessary.
- 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.
- And more
NOTE:
You can continue to use CentOS-6 until 2020 ... CentOS-7 is an option, not at all required for 6 more years.
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.
-
Always Learning -
Andrew Holway -
Carson Chittom -
Chris Adams -
david -
Fred Smith -
Gordon Messmer -
John R Pierce -
Johnny Hughes -
Keith Keller -
Les Mikesell -
Ljubomir Ljubojevic -
Matthew Miller -
Peter -
Stephen Harris -
Valeri Galtsev