Everyone,
This morning I did a manual yum update on our a mail server to 7.1 without any incident or problems. A new kernel was installed, and I rebooted after the update.
When I rebooted the machine I could not gain ssh access to it from an external ip address. I was able to ssh to this mail server through a different machine on the local network.
At first I thought the problem was related to the firewall. I stopped firewalld, and fail2ban, and clear all firewall rules without being able to gain access.
I disabled firewalld, and fail2ban. I enabled iptables and started it without a problem, but I could still not gain access. I removed all entries in the host.allow and host.deny files, and this did not make a difference either.
On one of the various reboots I tried to use the previous kernel before today's update, but there was no success.
I can scan the mail server and reach it without a problem from the internal network but I am not able to reach it from outside the local network. I have the mail server behind a Centso 5.11 machine that is the gateway router for the internal network, and the mail server is nat addressed with it's external ip address to the internal machine. I have had this configuration set up for over 7 years. I tweaked the Gateway router to nat address the mail server's ip address to a different machine inside the network and everything worked perfectly like it should, and then re-adjusted the gateway router again back to the mail server and am not able to gain access from outside the local network.
"traceroute" does not get to the mail server from outside the local network, but works fine inside the local network.
Bottom line, this does not look like a host.deny, host.allow problem, nor does it look like a firewalld or iptables problem. And it does not appear to be a problem with the gateway server.
Is there another feature of CentOs 7.1 that I need to evaluate? Has anyone else had this problem after the 7.1 update?
Thank you for your help!!!!
Greg Ennis
On Sat, 2015-04-04 at 16:47 -0500, Gregory P. Ennis wrote:
Everyone,
This morning I did a manual yum update on our a mail server to 7.1 without any incident or problems. A new kernel was installed, and I rebooted after the update.
When I rebooted the machine I could not gain ssh access to it from an external ip address. I was able to ssh to this mail server through a different machine on the local network.
At first I thought the problem was related to the firewall. I stopped firewalld, and fail2ban, and clear all firewall rules without being able to gain access.
I disabled firewalld, and fail2ban. I enabled iptables and started it without a problem, but I could still not gain access. I removed all entries in the host.allow and host.deny files, and this did not make a difference either.
On one of the various reboots I tried to use the previous kernel before today's update, but there was no success.
I can scan the mail server and reach it without a problem from the internal network but I am not able to reach it from outside the local network. I have the mail server behind a Centso 5.11 machine that is the gateway router for the internal network, and the mail server is nat addressed with it's external ip address to the internal machine. I have had this configuration set up for over 7 years. I tweaked the Gateway router to nat address the mail server's ip address to a different machine inside the network and everything worked perfectly like it should, and then re-adjusted the gateway router again back to the mail server and am not able to gain access from outside the local network.
"traceroute" does not get to the mail server from outside the local network, but works fine inside the local network.
Bottom line, this does not look like a host.deny, host.allow problem, nor does it look like a firewalld or iptables problem. And it does not appear to be a problem with the gateway server.
Is there another feature of CentOs 7.1 that I need to evaluate? Has anyone else had this problem after the 7.1 update?
Thank you for your help!!!!
Greg Ennis
---------------------------------------------------------------------
I sure need some help on this one, if any of you have ideas of what to do next I would surely appreciate it. An additional aspect of this scenario is that when I have used ssh to connect to this mail server via the internal network, I am able to ssh out of the machine to one of the internal networks or remotely to a different network. If no one else has had this problem with 7.1 then it is obviously something I have done, but right now I am at a loss.
Greg
On 05 Apr 2015, at 14:35, Gregory P. Ennis PoMec@PoMec.Net wrote: I sure need some help on this one, if any of you have ideas of what to do next I would surely appreciate it. An additional aspect of this scenario is that when I have used ssh to connect to this mail server via the internal network, I am able to ssh out of the machine to one of the internal networks or remotely to a different network. If no one else has had this problem with 7.1 then it is obviously something I have done, but right now I am at a loss.
Assuming that the mail server’s routing table is correct, you will need some tcpdump to understand if the packets from outside reach the server (and then it discards them).
I would do this: 1. Ensure that the mail server still has a valid default gateway and a correct routing table 2. start tcpdump on the gateway 3. start tcpdump on the mail server 4 Try to connect to the mail server from outside.
Greg
Ciao, Andrea (just upgraded some servers, no problems)
-- Andrea Dell'Amico http://adellam.%10sevenseas.org/
On Sun, 2015-04-05 at 16:53 +0200, Andrea Dell'Amico wrote:
On 05 Apr 2015, at 14:35, Gregory P. Ennis PoMec@PoMec.Net wrote: I sure need some help on this one, if any of you have ideas of what to do next I would surely appreciate it. An additional aspect of this scenario is that when I have used ssh to connect to this mail server via the internal network, I am able to ssh out of the machine to one of the internal networks or remotely to a different network. If no one else has had this problem with 7.1 then it is obviously something I have done, but right now I am at a loss.
Assuming that the mail server’s routing table is correct, you will need some tcpdump to understand if the packets from outside reach the server (and then it discards them).
I would do this:
- Ensure that the mail server still has a valid default gateway and a correct routing table
- start tcpdump on the gateway
- start tcpdump on the mail server
4 Try to connect to the mail server from outside.
Greg
Ciao, Andrea (just upgraded some servers, no problems)
-- Andrea Dell'Amico http://adellam.%10sevenseas.org/
Andrea,
Thank you very much, I have always wanted to learn how to use that tool. Looks like I have a good opportunity. Thanks for giving me the framework as to how to use it.
Greg
On Sat, 2015-04-04 at 16:47 -0500, Gregory P. Ennis wrote:
Everyone,
This morning I did a manual yum update on our a mail server to 7.1 without any incident or problems. A new kernel was installed, and I rebooted after the update.
When I rebooted the machine I could not gain ssh access to it from an external ip address. I was able to ssh to this mail server through a different machine on the local network.
At first I thought the problem was related to the firewall. I stopped firewalld, and fail2ban, and clear all firewall rules without being able to gain access.
I disabled firewalld, and fail2ban. I enabled iptables and started it without a problem, but I could still not gain access. I removed all entries in the host.allow and host.deny files, and this did not make a difference either.
On one of the various reboots I tried to use the previous kernel before today's update, but there was no success.
I can scan the mail server and reach it without a problem from the internal network but I am not able to reach it from outside the local network. I have the mail server behind a Centso 5.11 machine that is the gateway router for the internal network, and the mail server is nat addressed with it's external ip address to the internal machine. I have had this configuration set up for over 7 years. I tweaked the Gateway router to nat address the mail server's ip address to a different machine inside the network and everything worked perfectly like it should, and then re-adjusted the gateway router again back to the mail server and am not able to gain access from outside the local network.
"traceroute" does not get to the mail server from outside the local network, but works fine inside the local network.
Bottom line, this does not look like a host.deny, host.allow problem, nor does it look like a firewalld or iptables problem. And it does not appear to be a problem with the gateway server.
Is there another feature of CentOs 7.1 that I need to evaluate? Has anyone else had this problem after the 7.1 update?
Thank you for your help!!!!
Greg Ennis
-----------------------------------------------------------------------
I am still having difficulty with this problem. Everything worked perfectly until the upgrade from 7.0 to 7.1. I attempted to use wireshark and tcpdump to analyze the packets but I do not have sufficient experience with these tools to be helpful yet.
The mail server works fine with local network access, but intermittently blocks access from eternal ip addresses. Is there a way to back down 7.1 to 7.0. When I get to the mail server by using one of the local machines to ssh in to the mail server, I am able to perform any outbound function from the mail server.
Greg
On 04/09/2015 03:50 PM, Gregory P. Ennis wrote:
I am still having difficulty with this problem.
# ip addr show
# ip route show
# iptables -L -n -v
# tcpdump -nn -i <your primary interface> host <ip.ad.dr.es>
Watch tcpdump's output and try to connect from the IP address you name on the command line. Don't ssh to that host and then back, or tcpdump will show you your outbound session. Connect to the remote host from some other system.
Tail /var/log/messages and /var/log/secure while you connect.
On Thu, 2015-04-09 at 17:02 -0700, Gordon Messmer wrote:
On 04/09/2015 03:50 PM, Gregory P. Ennis wrote:
I am still having difficulty with this problem.
# ip addr show
# ip route show
# iptables -L -n -v
# tcpdump -nn -i <your primary interface> host <ip.ad.dr.es>
Watch tcpdump's output and try to connect from the IP address you name on the command line. Don't ssh to that host and then back, or tcpdump will show you your outbound session. Connect to the remote host from some other system.
Tail /var/log/messages and /var/log/secure while you connect. _______________________________________________
Gordon,
Thank you .... will do some experimenting!!!!
Greg
On Thu, 2015-04-09 at 21:50 -0500, Gregory P. Ennis wrote:
On Thu, 2015-04-09 at 17:02 -0700, Gordon Messmer wrote:
On 04/09/2015 03:50 PM, Gregory P. Ennis wrote:
I am still having difficulty with this problem.
# ip addr show
# ip route show
# iptables -L -n -v
# tcpdump -nn -i <your primary interface> host <ip.ad.dr.es>
Watch tcpdump's output and try to connect from the IP address you name on the command line. Don't ssh to that host and then back, or tcpdump will show you your outbound session. Connect to the remote host from some other system.
Tail /var/log/messages and /var/log/secure while you connect. _______________________________________________
Gordon,
Thank you .... will do some experimenting!!!!
Greg
Gordon,
Thank you very much, the tool you gave me allowed me to see a problem related to having two ethernet cards on the mail server. I am not sure what the problem is right now, but turning off one of the cards and routing everything through the remaining card fixed the problem. Interesting thing is that this was not a problem for 7.0, but only appeared after the 7.1 upgrade.
I am going to let the mail flow for awhile before I try to figure out what is happening.
Thank you again for your help!!!!!
Greg
On 04/04/2015 04:47 PM, Gregory P. Ennis wrote:
Everyone,
This morning I did a manual yum update on our a mail server to 7.1 without any incident or problems. A new kernel was installed, and I rebooted after the update.
When I rebooted the machine I could not gain ssh access to it from an external ip address. I was able to ssh to this mail server through a different machine on the local network.
At first I thought the problem was related to the firewall. I stopped firewalld, and fail2ban, and clear all firewall rules without being able to gain access.
I disabled firewalld, and fail2ban. I enabled iptables and started it without a problem, but I could still not gain access. I removed all entries in the host.allow and host.deny files, and this did not make a difference either.
On one of the various reboots I tried to use the previous kernel before today's update, but there was no success.
I can scan the mail server and reach it without a problem from the internal network but I am not able to reach it from outside the local network. I have the mail server behind a Centso 5.11 machine that is the gateway router for the internal network, and the mail server is nat addressed with it's external ip address to the internal machine. I have had this configuration set up for over 7 years. I tweaked the Gateway router to nat address the mail server's ip address to a different machine inside the network and everything worked perfectly like it should, and then re-adjusted the gateway router again back to the mail server and am not able to gain access from outside the local network.
"traceroute" does not get to the mail server from outside the local network, but works fine inside the local network.
Bottom line, this does not look like a host.deny, host.allow problem, nor does it look like a firewalld or iptables problem. And it does not appear to be a problem with the gateway server.
Is there another feature of CentOs 7.1 that I need to evaluate? Has anyone else had this problem after the 7.1 update?
Thank you for your help!!!!
Greg Ennis
Greg, do you have access to a console for that machine .. the mechanism in RHEL (and therefore CentOS) to accept licenses changed from 7.0 to 7.1 .. before it was all firstboot, now it is a combination of firstboot and initial-setup.
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
We know this is suboptimal, but it is exactly the same is in RHEL .. we may try to remove these from CLI only machines in the future.
On 04/04/2015 04:47 PM, Gregory P. Ennis wrote:
Everyone,
This morning I did a manual yum update on our a mail server to 7.1 without any incident or problems. A new kernel was installed, and I rebooted after the update.
When I rebooted the machine I could not gain ssh access to it from an external ip address. I was able to ssh to this mail server through a different machine on the local network.
At first I thought the problem was related to the firewall. I stopped firewalld, and fail2ban, and clear all firewall rules without being able to gain access.
I disabled firewalld, and fail2ban. I enabled iptables and started it without a problem, but I could still not gain access. I removed all entries in the host.allow and host.deny files, and this did not make a difference either.
On one of the various reboots I tried to use the previous kernel before today's update, but there was no success.
I can scan the mail server and reach it without a problem from the internal network but I am not able to reach it from outside the local network. I have the mail server behind a Centso 5.11 machine that is the gateway router for the internal network, and the mail server is nat addressed with it's external ip address to the internal machine. I have had this configuration set up for over 7 years. I tweaked the Gateway router to nat address the mail server's ip address to a different machine inside the network and everything worked perfectly like it should, and then re-adjusted the gateway router again back to the mail server and am not able to gain access from outside the local network.
"traceroute" does not get to the mail server from outside the local network, but works fine inside the local network.
Bottom line, this does not look like a host.deny, host.allow problem, nor does it look like a firewalld or iptables problem. And it does not appear to be a problem with the gateway server.
Is there another feature of CentOs 7.1 that I need to evaluate? Has anyone else had this problem after the 7.1 update?
Thank you for your help!!!!
Greg Ennis
Greg, do you have access to a console for that machine .. the mechanism in RHEL (and therefore CentOS) to accept licenses changed from 7.0 to 7.1 .. before it was all firstboot, now it is a combination of firstboot and initial-setup.
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
We know this is suboptimal, but it is exactly the same is in RHEL .. we may try to remove these from CLI only machines in the future.
----------------------------------------------------------------
Johnny,
It is about 30 miles away from my location today. I did take a look at the console when the problem first started, but could not log in because of the 7.1 problem related to multiple users on the log in screen without the ability to scroll through the users. I switched to a terminal interface to try to solve the problem, and did not try to log in via the gui.
I'll take a look latter tonight to see if that will make a difference.
Thanks,
Greg
On Fri, 2015-04-10 at 16:47 -0500, Greg Ennis wrote:
On 04/04/2015 04:47 PM, Gregory P. Ennis wrote:
Everyone,
This morning I did a manual yum update on our a mail server to 7.1 without any incident or problems. A new kernel was installed, and I rebooted after the update.
When I rebooted the machine I could not gain ssh access to it from an external ip address. I was able to ssh to this mail server through a different machine on the local network.
At first I thought the problem was related to the firewall. I stopped firewalld, and fail2ban, and clear all firewall rules without being able to gain access.
I disabled firewalld, and fail2ban. I enabled iptables and started it without a problem, but I could still not gain access. I removed all entries in the host.allow and host.deny files, and this did not make a difference either.
On one of the various reboots I tried to use the previous kernel before today's update, but there was no success.
I can scan the mail server and reach it without a problem from the internal network but I am not able to reach it from outside the local network. I have the mail server behind a Centso 5.11 machine that is the gateway router for the internal network, and the mail server is nat addressed with it's external ip address to the internal machine. I have had this configuration set up for over 7 years. I tweaked the Gateway router to nat address the mail server's ip address to a different machine inside the network and everything worked perfectly like it should, and then re-adjusted the gateway router again back to the mail server and am not able to gain access from outside the local network.
"traceroute" does not get to the mail server from outside the local network, but works fine inside the local network.
Bottom line, this does not look like a host.deny, host.allow problem, nor does it look like a firewalld or iptables problem. And it does not appear to be a problem with the gateway server.
Is there another feature of CentOs 7.1 that I need to evaluate? Has anyone else had this problem after the 7.1 update?
Thank you for your help!!!!
Greg Ennis
Greg, do you have access to a console for that machine .. the mechanism in RHEL (and therefore CentOS) to accept licenses changed from 7.0 to 7.1 .. before it was all firstboot, now it is a combination of firstboot and initial-setup.
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
We know this is suboptimal, but it is exactly the same is in RHEL .. we may try to remove these from CLI only machines in the future.
Johnny,
It is about 30 miles away from my location today. I did take a look at the console when the problem first started, but could not log in because of the 7.1 problem related to multiple users on the log in screen without the ability to scroll through the users. I switched to a terminal interface to try to solve the problem, and did not try to log in via the gui.
I'll take a look latter tonight to see if that will make a difference.
Thanks,
Greg
Johnny,
When I got to the machine, I still could not log in via the gui because of the known bug with the 7.1 login screen's inability to scroll multiple users. After logging in via a terminal interface and running 'initial-setup' I found that you were correct about not having the license agreed to. However, after agreeing to the license, it did not change any of the problems I have had with the second nic card. For now, I have just turned off the nic card and have routed everything on the network through the main card. I have a couple of other ideas I am going to try when I get the time.
When I converted to 7.1 from 7.0 I just did a yum update from a remote connection, and was never prompted to accept the new license agreement.
Greg
On Fri, Apr 10, 2015 at 06:33:27AM -0500, Johnny Hughes wrote:
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
So just to be clear, some of us who installed 7.0 servers in the GUI and then carted them to a remotely colo might be screwed if the machine reboots after updating to 7.1? Are there some files I can touch (or whatever) to prevent this from happening? Or is the best solution to go to the colo and reboot?
I have consoles for all of my professional servers, but not my hobby server! Fun fun! And I feel for you guys, given that upstream was the main cause.
-- greg
On Fri, 2015-04-10 at 18:25 -0700, Greg Lindahl wrote:
On Fri, Apr 10, 2015 at 06:33:27AM -0500, Johnny Hughes wrote:
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
So just to be clear, some of us who installed 7.0 servers in the GUI and then carted them to a remotely colo might be screwed if the machine reboots after updating to 7.1? Are there some files I can touch (or whatever) to prevent this from happening? Or is the best solution to go to the colo and reboot?
I have consoles for all of my professional servers, but not my hobby server! Fun fun! And I feel for you guys, given that upstream was the main cause.
-- greg
-------------------------------------------------------------------
Greg,
After my 7.1 upgrade the login gui is no longer usable because it will not scroll. However, if you are using a remote connection all you need to do is to run 'initial-setup' and accept the license agreement. However, be careful. The first time I activated 'inital-setup' I elected not to answer the question "yes" and the machine went in to a shutdown and then reboot. At this point, I wish I had not upgraded to 7.1
Greg
On 04/13/2015 11:42 AM, Gregory P. Ennis wrote:
On Fri, 2015-04-10 at 18:25 -0700, Greg Lindahl wrote:
On Fri, Apr 10, 2015 at 06:33:27AM -0500, Johnny Hughes wrote:
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
So just to be clear, some of us who installed 7.0 servers in the GUI and then carted them to a remotely colo might be screwed if the machine reboots after updating to 7.1? Are there some files I can touch (or whatever) to prevent this from happening? Or is the best solution to go to the colo and reboot?
I have consoles for all of my professional servers, but not my hobby server! Fun fun! And I feel for you guys, given that upstream was the main cause.
-- greg
Greg,
After my 7.1 upgrade the login gui is no longer usable because it will not scroll. However, if you are using a remote connection all you need to do is to run 'initial-setup' and accept the license agreement. However, be careful. The first time I activated 'inital-setup' I elected not to answer the question "yes" and the machine went in to a shutdown and then reboot. At this point, I wish I had not upgraded to 7.1
Greg
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Having been a CentOS user since about 5.2 and a list follower also, please bear with me while I make a couple of observations. 1. The 'nature' of CentOS appears to be changing.
I, and many others on this list, came to use and love CentOS because it was a server oriented distro and had the lineage of RedHat running through its veins - i.e. corporate type applications available and support of LONG TERM stability WITH back-porting of patch updates to fix security issues.
2. Major version updates, make significant changes to how things work, minor version updates are simply 'point in time' snapshots to make life easier for new installations and gaining updates. This no longer appears to be the case!
Having worked with servers and desktop workstations with both 5.x and 6.x there were very few issues caused by a yum update. Thus one could confidently do remote installations, yum updates etc. I know this from experience, operating servers in different continents with no physical access. The only problems ever encountered that needed physical access being when hardware problems arose.
3. CentOS install, like most linux variants uses the GPL for most packages, the acceptance of these licenses never required specific mouse clicks or check boxes.
Copies of license terms were included with packages but their acceptance implied by usage. It seems the apple, microsoft, oracle, and google android "in your face" must click acceptance to install an app or package have finally arrived to linux distros.
Having only spun up CentOS 7.0 from a live DVD I can make no comments about it yet, other than it seems from the comments on the list that both items 1 & 2 above are no longer true.
I understand the idea of CentOS being bug for bug compatible with the redhat lineage, however it appears that the CentOS single version release is in fact a derivative of the multiple variants actually produced and sold by redhat - thus some of the recent arguments about naming of versions and DVDs lack authenticity.
As is my usual practice, I never install and use a x.0 release for production - far too many things have changed, dependent software has not been sufficiently tested and many add-ons are not yet available. Thus I was awaiting the release of 7.1 to move forward with some projects, already realizing that the learning curve for this major release would be longer and harder than previous releases. However, I am now wondering how to move forward at all as item 2 is a must have for me, and appears to no longer be the case.
Thus I ask the list - have I missed an announcement about these changes? are these changes real or imagined? thanks for your time and forbearance. Rob
On 04/12/2015 10:29 PM, Rob Kampen wrote:
On 04/13/2015 11:42 AM, Gregory P. Ennis wrote:
On Fri, 2015-04-10 at 18:25 -0700, Greg Lindahl wrote:
On Fri, Apr 10, 2015 at 06:33:27AM -0500, Johnny Hughes wrote:
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
So just to be clear, some of us who installed 7.0 servers in the GUI and then carted them to a remotely colo might be screwed if the machine reboots after updating to 7.1? Are there some files I can touch (or whatever) to prevent this from happening? Or is the best solution to go to the colo and reboot?
I have consoles for all of my professional servers, but not my hobby server! Fun fun! And I feel for you guys, given that upstream was the main cause.
-- greg
Greg,
After my 7.1 upgrade the login gui is no longer usable because it will not scroll. However, if you are using a remote connection all you need to do is to run 'initial-setup' and accept the license agreement. However, be careful. The first time I activated 'inital-setup' I elected not to answer the question "yes" and the machine went in to a shutdown and then reboot. At this point, I wish I had not upgraded to 7.1
Greg
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Having been a CentOS user since about 5.2 and a list follower also, please bear with me while I make a couple of observations.
- The 'nature' of CentOS appears to be changing.
CentOS Linux is CentOS Linux .. it is a rebuild of the RHEL source code. The source code for RHEL 7.1 was rebuilt and released just like the source code for RHEL 6.6 or RHEL 5.11 was. There is no difference in CentOS Linux between how RHEL 6.6 code was rebuilt and how RHEL 7.1 was rebuilt. CentOS Linux, the core distro, is NOT changing. It is now and will always be a rebuild of RHEL source code.
I, and many others on this list, came to use and love CentOS because it was a server oriented distro and had the lineage of RedHat running through its veins - i.e. corporate type applications available and support of LONG TERM stability WITH back-porting of patch updates to fix security issues.
This version is also a direct rebuild of the RHEL source code. Red Hat seems to be moving more quickly and making more rapid changes. CentOS, rebuilding RHEL sources, will obviously move at the same pace.
- Major version updates, make significant changes to how things work,
minor version updates are simply 'point in time' snapshots to make life easier for new installations and gaining updates. This no longer appears to be the case!
Having worked with servers and desktop workstations with both 5.x and 6.x there were very few issues caused by a yum update. Thus one could confidently do remote installations, yum updates etc. I know this from experience, operating servers in different continents with no physical access. The only problems ever encountered that needed physical access being when hardware problems arose.
Red Hat changed the mechanism for how they do license acceptance .. in previous CentOS versions this was done in first boot for GUI installs only, NOW they have changed it to also happen on CLI installs. We don't desire this behavior .. but the process is identical to the RHEL install. You must accept the license in CentOS-6 as well .. it is just on the first reboot after install.
We hope to be able to work around this in the future.
- CentOS install, like most linux variants uses the GPL for most
packages, the acceptance of these licenses never required specific mouse clicks or check boxes.
Copies of license terms were included with packages but their acceptance implied by usage. It seems the apple, microsoft, oracle, and google android "in your face" must click acceptance to install an app or package have finally arrived to linux distros.
Having only spun up CentOS 7.0 from a live DVD I can make no comments about it yet, other than it seems from the comments on the list that both items 1 & 2 above are no longer true.
I understand the idea of CentOS being bug for bug compatible with the redhat lineage, however it appears that the CentOS single version release is in fact a derivative of the multiple variants actually produced and sold by redhat - thus some of the recent arguments about naming of versions and DVDs lack authenticity.
This has always been the case .. in CentOS-5 Linux, the CentOS tree and install DVDs are a combination of the RHEL Source Code for Clustering, Cluster-Storage, Virtualization, Desktop, Workstation, and Server.
CentOS-6 Linux is a combination of the RHEL-6 Source Code for High Availability, High Performance Network, HPC Node, Load Balancer, Resilient Storage, Scalable File System, Desktop, Workstation, and Server.
CentOS-7 Linux is a combination of Desktop, HPC Node, Resilient Storage, Workstation, and Server.
This process has also not changed at all.
As is my usual practice, I never install and use a x.0 release for production - far too many things have changed, dependent software has not been sufficiently tested and many add-ons are not yet available. Thus I was awaiting the release of 7.1 to move forward with some projects, already realizing that the learning curve for this major release would be longer and harder than previous releases. However, I am now wondering how to move forward at all as item 2 is a must have for me, and appears to no longer be the case.
Thus I ask the list - have I missed an announcement about these changes? are these changes real or imagined? thanks for your time and forbearance.
There is no changes in how the CentOS Linux distribution is produced or released. You can continue consuming like you always have. It is being built like it always has.
There are optional monthly ISO respins, that live in a different place, which you can consume if you want. There are also docker images, AWS images, generic cloud images, openstack images, etc. Which people can choose to consume or not. None of this changes how the base CentOS Linux is built or released. Some of these images also exist for CentOS-6 and/or CentOS-5 as well. All of these are optional and for the people who need them, they are there. If you don't need them then you keep consuming the CentOS-7 tree just like you did the CentOS-6 or CentOS-5 or CentOS-4 trees.
If Red Hat changes to Gnome 3.14 in RHEL 7.2 (from Gnome 3.8 in RHEL 7.1), when they release the RHEL 7.2 source code, our rebuild will have Gnome 3.14 in it. We may or may not agree with decision to move to a new Gnome version in a 'point release' .. but we (the CentOS Project) don't make those decisions, we just build the source code.
On 04/13/2015 06:49 AM, Johnny Hughes wrote:
On 04/12/2015 10:29 PM, Rob Kampen wrote:
On 04/13/2015 11:42 AM, Gregory P. Ennis wrote:
On Fri, 2015-04-10 at 18:25 -0700, Greg Lindahl wrote:
On Fri, Apr 10, 2015 at 06:33:27AM -0500, Johnny Hughes wrote:
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
So just to be clear, some of us who installed 7.0 servers in the GUI and then carted them to a remotely colo might be screwed if the machine reboots after updating to 7.1? Are there some files I can touch (or whatever) to prevent this from happening? Or is the best solution to go to the colo and reboot?
I have consoles for all of my professional servers, but not my hobby server! Fun fun! And I feel for you guys, given that upstream was the main cause.
-- greg
Greg,
After my 7.1 upgrade the login gui is no longer usable because it will not scroll. However, if you are using a remote connection all you need to do is to run 'initial-setup' and accept the license agreement. However, be careful. The first time I activated 'inital-setup' I elected not to answer the question "yes" and the machine went in to a shutdown and then reboot. At this point, I wish I had not upgraded to 7.1
Greg
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Having been a CentOS user since about 5.2 and a list follower also, please bear with me while I make a couple of observations.
- The 'nature' of CentOS appears to be changing.
CentOS Linux is CentOS Linux .. it is a rebuild of the RHEL source code. The source code for RHEL 7.1 was rebuilt and released just like the source code for RHEL 6.6 or RHEL 5.11 was. There is no difference in CentOS Linux between how RHEL 6.6 code was rebuilt and how RHEL 7.1 was rebuilt. CentOS Linux, the core distro, is NOT changing. It is now and will always be a rebuild of RHEL source code.
I, and many others on this list, came to use and love CentOS because it was a server oriented distro and had the lineage of RedHat running through its veins - i.e. corporate type applications available and support of LONG TERM stability WITH back-porting of patch updates to fix security issues.
This version is also a direct rebuild of the RHEL source code. Red Hat seems to be moving more quickly and making more rapid changes. CentOS, rebuilding RHEL sources, will obviously move at the same pace.
- Major version updates, make significant changes to how things work,
minor version updates are simply 'point in time' snapshots to make life easier for new installations and gaining updates. This no longer appears to be the case!
Having worked with servers and desktop workstations with both 5.x and 6.x there were very few issues caused by a yum update. Thus one could confidently do remote installations, yum updates etc. I know this from experience, operating servers in different continents with no physical access. The only problems ever encountered that needed physical access being when hardware problems arose.
Red Hat changed the mechanism for how they do license acceptance .. in previous CentOS versions this was done in first boot for GUI installs only, NOW they have changed it to also happen on CLI installs. We don't desire this behavior .. but the process is identical to the RHEL install. You must accept the license in CentOS-6 as well .. it is just on the first reboot after install.
We hope to be able to work around this in the future.
- CentOS install, like most linux variants uses the GPL for most
packages, the acceptance of these licenses never required specific mouse clicks or check boxes.
Copies of license terms were included with packages but their acceptance implied by usage. It seems the apple, microsoft, oracle, and google android "in your face" must click acceptance to install an app or package have finally arrived to linux distros.
Having only spun up CentOS 7.0 from a live DVD I can make no comments about it yet, other than it seems from the comments on the list that both items 1 & 2 above are no longer true.
I understand the idea of CentOS being bug for bug compatible with the redhat lineage, however it appears that the CentOS single version release is in fact a derivative of the multiple variants actually produced and sold by redhat - thus some of the recent arguments about naming of versions and DVDs lack authenticity.
This has always been the case .. in CentOS-5 Linux, the CentOS tree and install DVDs are a combination of the RHEL Source Code for Clustering, Cluster-Storage, Virtualization, Desktop, Workstation, and Server.
CentOS-6 Linux is a combination of the RHEL-6 Source Code for High Availability, High Performance Network, HPC Node, Load Balancer, Resilient Storage, Scalable File System, Desktop, Workstation, and Server.
CentOS-7 Linux is a combination of Desktop, HPC Node, Resilient Storage, Workstation, and Server.
This process has also not changed at all.
As is my usual practice, I never install and use a x.0 release for production - far too many things have changed, dependent software has not been sufficiently tested and many add-ons are not yet available. Thus I was awaiting the release of 7.1 to move forward with some projects, already realizing that the learning curve for this major release would be longer and harder than previous releases. However, I am now wondering how to move forward at all as item 2 is a must have for me, and appears to no longer be the case.
Thus I ask the list - have I missed an announcement about these changes? are these changes real or imagined? thanks for your time and forbearance.
There is no changes in how the CentOS Linux distribution is produced or released. You can continue consuming like you always have. It is being built like it always has.
There are optional monthly ISO respins, that live in a different place, which you can consume if you want. There are also docker images, AWS images, generic cloud images, openstack images, etc. Which people can choose to consume or not. None of this changes how the base CentOS Linux is built or released. Some of these images also exist for CentOS-6 and/or CentOS-5 as well. All of these are optional and for the people who need them, they are there. If you don't need them then you keep consuming the CentOS-7 tree just like you did the CentOS-6 or CentOS-5 or CentOS-4 trees.
If Red Hat changes to Gnome 3.14 in RHEL 7.2 (from Gnome 3.8 in RHEL 7.1), when they release the RHEL 7.2 source code, our rebuild will have Gnome 3.14 in it. We may or may not agree with decision to move to a new Gnome version in a 'point release' .. but we (the CentOS Project) don't make those decisions, we just build the source code.
This is what leads me to believe there will be a Gnome rebase in RHEL 7.2:
On 04/14/2015 01:07 AM, Johnny Hughes wrote:
On 04/13/2015 06:49 AM, Johnny Hughes wrote:
On 04/12/2015 10:29 PM, Rob Kampen wrote:
On 04/13/2015 11:42 AM, Gregory P. Ennis wrote:
On Fri, 2015-04-10 at 18:25 -0700, Greg Lindahl wrote:
On Fri, Apr 10, 2015 at 06:33:27AM -0500, Johnny Hughes wrote:
What may be happening is that you may need to be on the console and accept the license on the first reboot after the update.
We tried to turn this off for CLI only installs, but in some combinations of software, you may still get the acceptance screen and have to complete it.
So just to be clear, some of us who installed 7.0 servers in the GUI and then carted them to a remotely colo might be screwed if the machine reboots after updating to 7.1? Are there some files I can touch (or whatever) to prevent this from happening? Or is the best solution to go to the colo and reboot?
I have consoles for all of my professional servers, but not my hobby server! Fun fun! And I feel for you guys, given that upstream was the main cause.
-- greg
Greg,
After my 7.1 upgrade the login gui is no longer usable because it will not scroll. However, if you are using a remote connection all you need to do is to run 'initial-setup' and accept the license agreement. However, be careful. The first time I activated 'inital-setup' I elected not to answer the question "yes" and the machine went in to a shutdown and then reboot. At this point, I wish I had not upgraded to 7.1
Greg
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Having been a CentOS user since about 5.2 and a list follower also, please bear with me while I make a couple of observations.
- The 'nature' of CentOS appears to be changing.
CentOS Linux is CentOS Linux .. it is a rebuild of the RHEL source code. The source code for RHEL 7.1 was rebuilt and released just like the source code for RHEL 6.6 or RHEL 5.11 was. There is no difference in CentOS Linux between how RHEL 6.6 code was rebuilt and how RHEL 7.1 was rebuilt. CentOS Linux, the core distro, is NOT changing. It is now and will always be a rebuild of RHEL source code.
I, and many others on this list, came to use and love CentOS because it was a server oriented distro and had the lineage of RedHat running through its veins - i.e. corporate type applications available and support of LONG TERM stability WITH back-porting of patch updates to fix security issues.
This version is also a direct rebuild of the RHEL source code. Red Hat seems to be moving more quickly and making more rapid changes. CentOS, rebuilding RHEL sources, will obviously move at the same pace.
- Major version updates, make significant changes to how things work,
minor version updates are simply 'point in time' snapshots to make life easier for new installations and gaining updates. This no longer appears to be the case!
Having worked with servers and desktop workstations with both 5.x and 6.x there were very few issues caused by a yum update. Thus one could confidently do remote installations, yum updates etc. I know this from experience, operating servers in different continents with no physical access. The only problems ever encountered that needed physical access being when hardware problems arose.
Red Hat changed the mechanism for how they do license acceptance .. in previous CentOS versions this was done in first boot for GUI installs only, NOW they have changed it to also happen on CLI installs. We don't desire this behavior .. but the process is identical to the RHEL install. You must accept the license in CentOS-6 as well .. it is just on the first reboot after install.
We hope to be able to work around this in the future.
- CentOS install, like most linux variants uses the GPL for most
packages, the acceptance of these licenses never required specific mouse clicks or check boxes.
Copies of license terms were included with packages but their acceptance implied by usage. It seems the apple, microsoft, oracle, and google android "in your face" must click acceptance to install an app or package have finally arrived to linux distros.
Having only spun up CentOS 7.0 from a live DVD I can make no comments about it yet, other than it seems from the comments on the list that both items 1 & 2 above are no longer true.
I understand the idea of CentOS being bug for bug compatible with the redhat lineage, however it appears that the CentOS single version release is in fact a derivative of the multiple variants actually produced and sold by redhat - thus some of the recent arguments about naming of versions and DVDs lack authenticity.
This has always been the case .. in CentOS-5 Linux, the CentOS tree and install DVDs are a combination of the RHEL Source Code for Clustering, Cluster-Storage, Virtualization, Desktop, Workstation, and Server.
CentOS-6 Linux is a combination of the RHEL-6 Source Code for High Availability, High Performance Network, HPC Node, Load Balancer, Resilient Storage, Scalable File System, Desktop, Workstation, and Server.
CentOS-7 Linux is a combination of Desktop, HPC Node, Resilient Storage, Workstation, and Server.
This process has also not changed at all.
As is my usual practice, I never install and use a x.0 release for production - far too many things have changed, dependent software has not been sufficiently tested and many add-ons are not yet available. Thus I was awaiting the release of 7.1 to move forward with some projects, already realizing that the learning curve for this major release would be longer and harder than previous releases. However, I am now wondering how to move forward at all as item 2 is a must have for me, and appears to no longer be the case.
Thus I ask the list - have I missed an announcement about these changes? are these changes real or imagined? thanks for your time and forbearance.
There is no changes in how the CentOS Linux distribution is produced or released. You can continue consuming like you always have. It is being built like it always has.
There are optional monthly ISO respins, that live in a different place, which you can consume if you want. There are also docker images, AWS images, generic cloud images, openstack images, etc. Which people can choose to consume or not. None of this changes how the base CentOS Linux is built or released. Some of these images also exist for CentOS-6 and/or CentOS-5 as well. All of these are optional and for the people who need them, they are there. If you don't need them then you keep consuming the CentOS-7 tree just like you did the CentOS-6 or CentOS-5 or CentOS-4 trees.
If Red Hat changes to Gnome 3.14 in RHEL 7.2 (from Gnome 3.8 in RHEL 7.1), when they release the RHEL 7.2 source code, our rebuild will have Gnome 3.14 in it. We may or may not agree with decision to move to a new Gnome version in a 'point release' .. but we (the CentOS Project) don't make those decisions, we just build the source code.
This is what leads me to believe there will be a Gnome rebase in RHEL 7.2:
thanks Johnny, you have explained exactly what my understanding was in terms much better expressed than I was able to do. I guess the telling comment for me is
Red Hat seems to be moving more quickly and making more rapid changes. CentOS, rebuilding RHEL sources, will obviously move at the same pace.
While I can understand this and even welcome this to some extent, particularly for my desktop machines, it is the "it just works" that I have grown accustomed to, and this seems to be changing. It may be just my impression, but there seem to be more significant show stopping bugs with the 7.x series of releases, and I suppose the above comment exposes the reasons - more rapid releases mean less exhaustive testing, unless more resources are deployed and I guess that is unlikely to have occurred.\
Thanks as always for what you and the rest of the CentOS team do, just appreciation and admiration for all you guys (and gals?) do for the community. Rob
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 04/13/2015 11:17 PM, Rob Kampen wrote:
On 04/14/2015 01:07 AM, Johnny Hughes wrote:
On 04/13/2015 06:49 AM, Johnny Hughes wrote:
On 04/12/2015 10:29 PM, Rob Kampen wrote:
On 04/13/2015 11:42 AM, Gregory P. Ennis wrote:
On Fri, 2015-04-10 at 18:25 -0700, Greg Lindahl wrote:
On Fri, Apr 10, 2015 at 06:33:27AM -0500, Johnny Hughes wrote:
> What may be happening is that you may need to be on the console and > accept the license on the first reboot after the update. > > We tried to turn this off for CLI only installs, but in some > combinations of software, you may still get the acceptance screen > and > have to complete it. So just to be clear, some of us who installed 7.0 servers in the GUI and then carted them to a remotely colo might be screwed if the machine reboots after updating to 7.1? Are there some files I can touch (or whatever) to prevent this from happening? Or is the best solution to go to the colo and reboot?
I have consoles for all of my professional servers, but not my hobby server! Fun fun! And I feel for you guys, given that upstream was the main cause.
-- greg
Greg,
After my 7.1 upgrade the login gui is no longer usable because it will not scroll. However, if you are using a remote connection all you need to do is to run 'initial-setup' and accept the license agreement. However, be careful. The first time I activated 'inital-setup' I elected not to answer the question "yes" and the machine went in to a shutdown and then reboot. At this point, I wish I had not upgraded to 7.1
Greg
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Having been a CentOS user since about 5.2 and a list follower also, please bear with me while I make a couple of observations.
- The 'nature' of CentOS appears to be changing.
CentOS Linux is CentOS Linux .. it is a rebuild of the RHEL source code. The source code for RHEL 7.1 was rebuilt and released just like the source code for RHEL 6.6 or RHEL 5.11 was. There is no difference in CentOS Linux between how RHEL 6.6 code was rebuilt and how RHEL 7.1 was rebuilt. CentOS Linux, the core distro, is NOT changing. It is now and will always be a rebuild of RHEL source code.
I, and many others on this list, came to use and love CentOS because it was a server oriented distro and had the lineage of RedHat running through its veins - i.e. corporate type applications available and support of LONG TERM stability WITH back-porting of patch updates to fix security issues.
This version is also a direct rebuild of the RHEL source code. Red Hat seems to be moving more quickly and making more rapid changes. CentOS, rebuilding RHEL sources, will obviously move at the same pace.
- Major version updates, make significant changes to how things work,
minor version updates are simply 'point in time' snapshots to make life easier for new installations and gaining updates. This no longer appears to be the case!
Having worked with servers and desktop workstations with both 5.x and 6.x there were very few issues caused by a yum update. Thus one could confidently do remote installations, yum updates etc. I know this from experience, operating servers in different continents with no physical access. The only problems ever encountered that needed physical access being when hardware problems arose.
Red Hat changed the mechanism for how they do license acceptance .. in previous CentOS versions this was done in first boot for GUI installs only, NOW they have changed it to also happen on CLI installs. We don't desire this behavior .. but the process is identical to the RHEL install. You must accept the license in CentOS-6 as well .. it is just on the first reboot after install.
We hope to be able to work around this in the future.
- CentOS install, like most linux variants uses the GPL for most
packages, the acceptance of these licenses never required specific mouse clicks or check boxes.
Copies of license terms were included with packages but their acceptance implied by usage. It seems the apple, microsoft, oracle, and google android "in your face" must click acceptance to install an app or package have finally arrived to linux distros.
Having only spun up CentOS 7.0 from a live DVD I can make no comments about it yet, other than it seems from the comments on the list that both items 1 & 2 above are no longer true.
I understand the idea of CentOS being bug for bug compatible with the redhat lineage, however it appears that the CentOS single version release is in fact a derivative of the multiple variants actually produced and sold by redhat - thus some of the recent arguments about naming of versions and DVDs lack authenticity.
This has always been the case .. in CentOS-5 Linux, the CentOS tree and install DVDs are a combination of the RHEL Source Code for Clustering, Cluster-Storage, Virtualization, Desktop, Workstation, and Server.
CentOS-6 Linux is a combination of the RHEL-6 Source Code for High Availability, High Performance Network, HPC Node, Load Balancer, Resilient Storage, Scalable File System, Desktop, Workstation, and Server.
CentOS-7 Linux is a combination of Desktop, HPC Node, Resilient Storage, Workstation, and Server.
This process has also not changed at all.
As is my usual practice, I never install and use a x.0 release for production - far too many things have changed, dependent software has not been sufficiently tested and many add-ons are not yet available. Thus I was awaiting the release of 7.1 to move forward with some projects, already realizing that the learning curve for this major release would be longer and harder than previous releases. However, I am now wondering how to move forward at all as item 2 is a must have for me, and appears to no longer be the case.
Thus I ask the list - have I missed an announcement about these changes? are these changes real or imagined? thanks for your time and forbearance.
There is no changes in how the CentOS Linux distribution is produced or released. You can continue consuming like you always have. It is being built like it always has.
There are optional monthly ISO respins, that live in a different place, which you can consume if you want. There are also docker images, AWS images, generic cloud images, openstack images, etc. Which people can choose to consume or not. None of this changes how the base CentOS Linux is built or released. Some of these images also exist for CentOS-6 and/or CentOS-5 as well. All of these are optional and for the people who need them, they are there. If you don't need them then you keep consuming the CentOS-7 tree just like you did the CentOS-6 or CentOS-5 or CentOS-4 trees.
If Red Hat changes to Gnome 3.14 in RHEL 7.2 (from Gnome 3.8 in RHEL 7.1), when they release the RHEL 7.2 source code, our rebuild will have Gnome 3.14 in it. We may or may not agree with decision to move to a new Gnome version in a 'point release' .. but we (the CentOS Project) don't make those decisions, we just build the source code.
This is what leads me to believe there will be a Gnome rebase in RHEL 7.2:
thanks Johnny, you have explained exactly what my understanding was in terms much better expressed than I was able to do. I guess the telling comment for me is
Red Hat seems to be moving more quickly and making more rapid changes. CentOS, rebuilding RHEL sources, will obviously move at the same pace.
While I can understand this and even welcome this to some extent, particularly for my desktop machines, it is the "it just works" that I have grown accustomed to, and this seems to be changing. It may be just my impression, but there seem to be more significant show stopping bugs with the 7.x series of releases, and I suppose the above comment exposes the reasons - more rapid releases mean less exhaustive testing, unless more resources are deployed and I guess that is unlikely to have occurred.\
Thanks as always for what you and the rest of the CentOS team do, just appreciation and admiration for all you guys (and gals?) do for the community. Rob
To be perfectly honest, I am not thrilled with the movement either from the enterprise stability point of view .. BUT .. with respect to desktop and software development it is better. I personally though the other way was better (no major version movement) .. but, that is above my paygrade :)
Thanks as always for what you and the rest of the CentOS team do, just appreciation and admiration for all you guys (and gals?) do for the community. Rob
To be perfectly honest, I am not thrilled with the movement either from the enterprise stability point of view .. BUT .. with respect to desktop and software development it is better. I personally though the other way was better (no major version movement) .. but, that is above my paygrade :)
Johnny and Rob,
I would like to give a BIG thanks to not only the CentOS team, but also to the members of this list. There is no way I would have been able to learn how to do what I have done without everyone giving me some help from time to time!!!!!
Big Thanks!!!
Greg
Awhile back the mouse wheel stopped working when trying to switch workspaces in the overview, sometime after the 7.1 udpate. Now it only works if the mouse is over a thumbnail of an application and not when its on a blank workspace if that makes any sense. I'm wondering if anyone else has seen this?
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Andrea Dell'Amico -
Gordon Messmer -
Greg Ennis -
Greg Lindahl -
Gregory P. Ennis
-
Jay Warren -
Johnny Hughes -
Rob Kampen