Hi,
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues at http://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
Regards,
Am 11.12.2013 um 16:56 schrieb Karanbir Singh mail-lists@karan.org:
Hi,
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues at http://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
cool!
-- LF
Le 11/12/2013 16:56, Karanbir Singh a écrit :
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues athttp://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
There seems to be only x86_64 release ? That would be in the current trend...
Alain
On 11/12/13 16:03, Alain Péan wrote:
Le 11/12/2013 16:56, Karanbir Singh a écrit :
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues athttp://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
There seems to be only x86_64 release ? That would be in the current trend...
Alain
Correct. RHEL7 will have support for 32-bit apps by way of 32-bit compatability libs as is currently the case on 6 (so you can run 32-bit apps on a 64-bit system), but from RHEL7 there will be no 32-bit installation option.
See the release notes here for details of major changes:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
Am 11.12.2013 um 17:03 schrieb Alain Péan alain.pean@lpn.cnrs.fr:
Le 11/12/2013 16:56, Karanbir Singh a écrit :
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues athttp://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
There seems to be only x86_64 release ? That would be in the current trend...
that is really an issue for us because we use EL for some small i586 hw (router etc.).
-- LF
Le 12/12/2013 14:49, Leon Fauster a écrit :
that is really an issue for us because we use EL for some small i586 hw (router etc.).
You can still use CentOS 6 or RHEL 6 (maintained until 2020) ? Or buy a cheap hardware. They are now all 64 bits. You cannot say your i586 hw will live this long...
Alain
On Thu, Dec 12, 2013 at 8:49 AM, Leon Fauster leonfauster@googlemail.comwrote:
Am 11.12.2013 um 17:03 schrieb Alain Péan alain.pean@lpn.cnrs.fr:
Le 11/12/2013 16:56, Karanbir Singh a écrit :
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues athttp://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
There seems to be only x86_64 release ? That would be in the current
trend...
that is really an issue for us because we use EL for some small i586 hw (router etc.).
Indeed. Now RHEL/CentOS won't be able to run on PC Engines ALIX hardware (with PAE enabled in CentOS 6 the kernel needed recompiled, but that's not too horrible). I opted to run another distro, so I never went through all the work for ALIX hardware.
In a way it's a shame... At the same time I can see why RH is going x86_64 only ... much hardware in data centers is 64bit capable and running 64bit OSes.
And they're also will be supporting three releases (5, 6, 7) for a period of time as well.
It's probably a good time to consider other alternatives. :-/ Fedora, Debian, Voyage, OpenWrt, Gentoo, etc, etc.
Unless it's embedded hardware ... by the time EL6 isn't supported I'll be you'll have a beefier x86_64 machine as a firewall! :)
-- LF
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am 12.12.2013 um 22:35 schrieb SilverTip257 silvertip257@gmail.com:
On Thu, Dec 12, 2013 at 8:49 AM, Leon Fauster leonfauster@googlemail.comwrote:
that is really an issue for us because we use EL for some small i586 hw (router etc.).
Indeed. Now RHEL/CentOS won't be able to run on PC Engines ALIX hardware (with PAE enabled in CentOS 6 the kernel needed recompiled, but that's not too horrible). I opted to run another distro, so I never went through all the work for ALIX hardware.
yep. the same hw here. i had tested openwall os some years ago. They have some correlation with rhel. Rebuilding rpms from EL should be straight forward but it will lead to more work :-)
In a way it's a shame... At the same time I can see why RH is going x86_64 only ... much hardware in data centers is 64bit capable and running 64bit OSes.
And they're also will be supporting three releases (5, 6, 7) for a period of time as well.
It's probably a good time to consider other alternatives. :-/ Fedora, Debian, Voyage, OpenWrt, Gentoo, etc, etc.
Unless it's embedded hardware ... by the time EL6 isn't supported I'll be you'll have a beefier x86_64 machine as a firewall! :)
any suggestions?
-- LF
On Thu, Dec 12, 2013 at 6:46 PM, Leon Fauster leonfauster@googlemail.comwrote:
Am 12.12.2013 um 22:35 schrieb SilverTip257 silvertip257@gmail.com:
On Thu, Dec 12, 2013 at 8:49 AM, Leon Fauster <
leonfauster@googlemail.com>wrote:
that is really an issue for us because we use EL for some small i586 hw
(router etc.).
Indeed. Now RHEL/CentOS won't be able to run on PC Engines ALIX hardware (with
PAE
enabled in CentOS 6 the kernel needed recompiled, but that's not too horrible). I opted to run another distro, so I never went through all
the
work for ALIX hardware.
yep. the same hw here. i had tested openwall os some years ago. They have some correlation with rhel. Rebuilding rpms from EL should be straight forward but it will lead to more work :-)
I have some old embedded boards (older than ALIX) lying around I figured I'd lab with... Go figure I had to recompile kernels in order to enable support for certain chips/devices.
In a way it's a shame... At the same time I can see why RH is going x86_64 only ... much hardware
in
data centers is 64bit capable and running 64bit OSes.
And they're also will be supporting three releases (5, 6, 7) for a period of time as well.
It's probably a good time to consider other alternatives. :-/ Fedora, Debian, Voyage, OpenWrt, Gentoo, etc, etc.
Unless it's embedded hardware ... by the time EL6 isn't supported I'll be you'll have a beefier x86_64 machine as a firewall! :)
any suggestions?
I was thinking maybe a Soekris board with Intel Atom CPUs can get you the 64-bit CPUs you want. But no ... once you get through the models that have AMD Geode LX CPUs (which are 486/586) you stumble into models that have Intel Atom CPUs that are in the E6xx family which are not 64-bit capable. And boy are the upper-end models a bit salty (might be a bit cheaper from a distributor/reseller).
You could build a mini-ITX system ... but you'd probably quadruple power consumption (~5w for Geode LX800 systems and likely ~20w for Atom systems).
Sorry :-(
http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors
http://soekris.com/products/net6501-30-board-case.html http://soekris.com/products/net6501-50-board-case.html http://soekris.com/products/net6501-70-board-case.html
-- LF
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am 13.12.2013 um 01:10 schrieb SilverTip257 silvertip257@gmail.com:
On Thu, Dec 12, 2013 at 6:46 PM, Leon Fauster leonfauster@googlemail.comwrote:
In a way it's a shame... At the same time I can see why RH is going x86_64 only ... much hardware in data centers is 64bit capable and running 64bit OSes.
And they're also will be supporting three releases (5, 6, 7) for a period of time as well.
It's probably a good time to consider other alternatives. :-/ Fedora, Debian, Voyage, OpenWrt, Gentoo, etc, etc.
Unless it's embedded hardware ... by the time EL6 isn't supported I'll be you'll have a beefier x86_64 machine as a firewall! :)
any suggestions?
I was thinking maybe a Soekris board with Intel Atom CPUs can get you the 64-bit CPUs you want. But no ... once you get through the models that have AMD Geode LX CPUs (which are 486/586) you stumble into models that have Intel Atom CPUs that are in the E6xx family which are not 64-bit capable. And boy are the upper-end models a bit salty (might be a bit cheaper from a distributor/reseller).
You could build a mini-ITX system ... but you'd probably quadruple power consumption (~5w for Geode LX800 systems and likely ~20w for Atom systems).
i got a response from Pcengines: "The new boards are still in the beta phase, production in february".
It looks promising especially the roadmap http://www.pcengines.ch/apu.htm :-)
-- LF
On Fri, Dec 13, 2013 at 5:19 AM, Leon Fauster leonfauster@googlemail.comwrote:
Am 13.12.2013 um 01:10 schrieb SilverTip257 silvertip257@gmail.com:
On Thu, Dec 12, 2013 at 6:46 PM, Leon Fauster <
leonfauster@googlemail.com>wrote:
Unless it's embedded hardware ... by the time EL6 isn't supported I'll
be
you'll have a beefier x86_64 machine as a firewall! :)
any suggestions?
I was thinking maybe a Soekris board with Intel Atom CPUs can get you the 64-bit CPUs you want. But no ... once you get through the models that
have
AMD Geode LX CPUs (which are 486/586) you stumble into models that have Intel Atom CPUs that are in the E6xx family which are not 64-bit capable. And boy are the upper-end models a bit salty (might be a bit cheaper from a distributor/reseller).
You could build a mini-ITX system ... but you'd probably quadruple power consumption (~5w for Geode LX800 systems and likely ~20w for Atom
systems).
i got a response from Pcengines: "The new boards are still in the beta phase, production in february".
It looks promising especially the roadmap http://www.pcengines.ch/apu.htm:-)
Sweet! That hardware is a big improvement over the current ALIX series with Geode LX800s. Gotta wonder where they come in on the pricing scale? Time will tell. ;-)
Thanks for sharing.
*If you purchase one I'd appreciate a review. :-)*
And to think I've been eyeing up the Ubiquiti Edge Routers [0] (but they're $99 USD as opposed to nearly $200 USD or more for whatever the new APU series will be). But the ERs are MIPS-64, etc so I'd run the EdgeOS or _maybe_ Debian (or anything else that supports that arch -- I've not done much research as I prefer x86/amd64).
[0] http://www.ubnt.com/edgemax#edge-router-lite
-- LF
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, Dec 12, 2013 at 3:35 PM, SilverTip257 silvertip257@gmail.com wrote:
In a way it's a shame... At the same time I can see why RH is going x86_64 only ... much hardware in data centers is 64bit capable and running 64bit OSes.
This will probably be painful for people using LTSP to boot older thin clients even if they have a hefty server.
Thanks for this, looking forward to kicking the tires to see what they did with GNOME 3.
On Wed, Dec 11, 2013 at 9:56 AM, Karanbir Singh mail-lists@karan.orgwrote:
Hi,
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues at http://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
Regards,
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Le 11/12/2013 18:26, Andrew Wyatt a écrit :
Thanks for this, looking forward to kicking the tires to see what they did with GNOME 3.
From the release notes : "Red Hat Enterprise Linux 7.0 Beta features the next major version of the GNOME Desktop, GNOME 3. The user experience of GNOME 3 is largely defined by GNOME Shell, which replaces the GNOME 2 desktop shell. Apart from window management, GNOME Shell provides the top bar on the screen, which hosts the 'system status' area in the top right, a clock, and a hot corner that switches to |Activities Overview|, which provides easy access to applications and windows.
The default GNOME Shell interface in Red Hat Enterprise Linux 7.0 Beta is GNOME Classic which features a window list at the bottom of the screen and traditional *Applications* and *Places* menus."
Am 11.12.2013 um 18:51 schrieb Alain Péan alain.pean@lpn.cnrs.fr:
Le 11/12/2013 18:26, Andrew Wyatt a écrit :
Thanks for this, looking forward to kicking the tires to see what they did with GNOME 3.
From the release notes : "Red Hat Enterprise Linux 7.0 Beta features the next major version of the GNOME Desktop, GNOME 3. The user experience of GNOME 3 is largely defined by GNOME Shell, which replaces the GNOME 2 desktop shell. Apart from window management, GNOME Shell provides the top bar on the screen, which hosts the 'system status' area in the top right, a clock, and a hot corner that switches to |Activities Overview|, which provides easy access to applications and windows.
The default GNOME Shell interface in Red Hat Enterprise Linux 7.0 Beta is GNOME Classic which features a window list at the bottom of the screen and traditional *Applications* and *Places* menus."
RHEL7 without thunderbird :-(
-- LF
I meant the actual implementation, I knew it would be GNOME Classic. This beta release is awful. I lost count of how many devel packages were missing now, I think I had to rebuild over 20 of their source rpms to get them while I was toying with Cairo Dock. Not to mention that desktop, 4 ways to close an app - that's awesome! (not)
Meh, this really should be labeled an alpha it has so many problems but I guess it's easy enough to bootstrap their sources to spit out all of the missing dependencies.
On Wed, Dec 11, 2013 at 11:51 AM, Alain Péan alain.pean@lpn.cnrs.fr wrote:
Le 11/12/2013 18:26, Andrew Wyatt a écrit :
Thanks for this, looking forward to kicking the tires to see what they
did
with GNOME 3.
From the release notes : "Red Hat Enterprise Linux 7.0 Beta features the next major version of the GNOME Desktop, GNOME 3. The user experience of GNOME 3 is largely defined by GNOME Shell, which replaces the GNOME 2 desktop shell. Apart from window management, GNOME Shell provides the top bar on the screen, which hosts the 'system status' area in the top right, a clock, and a hot corner that switches to |Activities Overview|, which provides easy access to applications and windows.
The default GNOME Shell interface in Red Hat Enterprise Linux 7.0 Beta is GNOME Classic which features a window list at the bottom of the screen and traditional *Applications* and *Places* menus." _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/16/2013 01:27 PM, Andrew Wyatt wrote:
I meant the actual implementation, I knew it would be GNOME Classic. This beta release is awful. I lost count of how many devel packages were missing now, I think I had to rebuild over 20 of their source rpms to get them while I was toying with Cairo Dock. Not to mention that desktop, 4 ways to close an app - that's awesome! (not)
Just to quantify this : you assert that there are srpm build output that is otherwise not released in this beta from red hat ?
Yes, there are many missing -devel packages. It's possible that they didn't fit on the media though, I haven't connected the system to RedHat's repositories.
On Tue, Dec 17, 2013 at 6:08 PM, Karanbir Singh mail-lists@karan.orgwrote:
On 12/16/2013 01:27 PM, Andrew Wyatt wrote:
I meant the actual implementation, I knew it would be GNOME Classic.
This
beta release is awful. I lost count of how many devel packages were missing now, I think I had to rebuild over 20 of their source rpms to get them while I was toying with Cairo Dock. Not to mention that desktop, 4 ways to close an app - that's awesome! (not)
Just to quantify this : you assert that there are srpm build output that is otherwise not released in this beta from red hat ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Dec 17, 2013 at 07:57:01PM -0600, Andrew Wyatt wrote:
Yes, there are many missing -devel packages. It's possible that they didn't fit on the media though, I haven't connected the system to RedHat's repositories.
You can just run yum update (though I think you have to manually change the enable line in the rh-beta.repo. You don't have to register in order to download from RH's repos.
On 12/17/2013 18:57, Andrew Wyatt wrote:
Yes, there are many missing -devel packages. It's possible that they didn't fit on the media though,
I've run into two of these myself: libedit and libgd. Both of these are living, useful libraries, without direct replacements.[*]
Clearly there are RPMs shipped in the distro that require these libraries. I guess Red Hat are saying that they don't intend that you develop your *own* software against these libraries.
[*] (libedit is API-compatible with readline, but most apps that use it do so in order to avoid the GPL. There are many alternatives to GD, but none are API-compatible.)
On Thu, 19 Dec 2013, Warren Young wrote:
On 12/17/2013 18:57, Andrew Wyatt wrote:
Yes, there are many missing -devel packages. It's possible that they didn't fit on the media though,
Look at
lftp ftp.redhat.com:/redhat/rhel/beta/7/x86_64/os/Packages> ls libedit* libedit-3.0-10.20121213cvs.el7.i686.rpm libedit-3.0-10.20121213cvs.el7.x86_64.rpm libedit-devel-3.0-10.20121213cvs.el7.i686.rpm libedit-devel-3.0-10.20121213cvs.el7.x86_64.rpm
# rpm -qlp libedit-3.0-10.20121213cvs.el7.x86_64.rpm /usr/lib64/libedit.so.0 /usr/lib64/libedit.so.0.0.42 /usr/share/doc/libedit-3.0 /usr/share/doc/libedit-3.0/COPYING /usr/share/doc/libedit-3.0/ChangeLog /usr/share/doc/libedit-3.0/THANKS
-Connie Sieh
I've run into two of these myself: libedit and libgd. Both of these are living, useful libraries, without direct replacements.[*]
Clearly there are RPMs shipped in the distro that require these libraries. I guess Red Hat are saying that they don't intend that you develop your *own* software against these libraries.
[*] (libedit is API-compatible with readline, but most apps that use it do so in order to avoid the GPL. There are many alternatives to GD, but none are API-compatible.) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Karanbir Singh Sent: den 11 december 2013 16:56 To: CentOS mailing list Subject: [CentOS] RHEL 7 Beta is now public
Hi,
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues at http://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
I see nobody's asked when CentOS 7 will be out yet. ;-)
Anyway, will be interesting to check out the "new" gnome.
-- //Sorin
On 12/11/2013 11:49 PM, Sorin Srbu wrote:
I see nobody's asked when CentOS 7 will be out yet.;-)
well, they can't even really start until RHEL 7 is a done deal and released. Investing too much effort in porting a beta often is wasted when the final release has structural changes.
On 12/12/2013 09:16 PM, John R Pierce wrote:
On 12/11/2013 11:49 PM, Sorin Srbu wrote:
I see nobody's asked when CentOS 7 will be out yet.;-)
well, they can't even really start until RHEL 7 is a done deal and released. Investing too much effort in porting a beta often is wasted when the final release has structural changes.
Yes, but this seems to indicate otherwise:
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam
That said, there is, of course, no way to even speculate when CentOS 7 final will be released until upstream releases 7.
Peter
Le 12/12/2013 09:28, Peter a écrit :
Within CentOS, we are going to do a CentOS7Beta1 build to match the
release upsteam
That said, there is, of course, no way to even speculate when CentOS 7 final will be released until upstream releases 7.
Yes, but experience shows it takes about 6 months after the beta release, so I expect it for ~June. CentOS 6 has been released in November 2010, so it will be 3 years and a half after this. There is about 3 years between each major release.
Alain
Le 12/12/2013 10:41, Alain Péan a écrit :
CentOS 6 has been released in November 2010
Ooops, I meant RHEL 6, of course.
On 12/12/2013 08:28 AM, Peter wrote:
well, they can't even really start until RHEL 7 is a done deal and released. Investing too much effort in porting a beta often is wasted when the final release has structural changes.
Yes, but this seems to indicate otherwise:
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam
The overall aim is to have as many people as possible test the rhel7 beta and file bugs at bugzilla.redhat.com; that way everyone is testing anf doing feedback against the same builds, and we all win with a better overall end result.
However, we are still going to - slowly maybe - get a CentOS-7 beta build going, so that CentOS users can start testing their depoyment strategies, start writing docs at wiki.centos.org, start doing migration testing etc so that when CentOS-7 comes around for release, its not all a big surprise.
The reason I say slowly, is because I would like to build a more open and more inclusive process that allows a larger audience to help build and promote the resulting distro. Lots of ideas at this point, the coming weeks should see some of them firm up into a process.
What I will say is : for anyone looking to get involved, start brushing up your git skills and hang out in irc #centos-devel as and when you can.
Greetings,
On Thu, Dec 12, 2013 at 3:35 PM, Karanbir Singh mail-lists@karan.org wrote: <snip>
strategies, start writing docs at wiki.centos.org, start doing migration
<snip>
+1 Important considering that new critical things like grub2, systemd, firewalld and the such.
With rhel7 entering many of us will be baby-sitting at least 4 releases - 4, 5, 6 and 7 at least for couple of more years
I am of course aware that there are many RHEL 2 and possilbly Redhat Linux 9 boxens out there.
Good informations. I will testing soon. I think I will installed on Virtualbox and review.
Nếu có bất cứ vấn đề gì khác, hãy cho chúng tôi biết ngay. Cám ơn bạn đã liên hệ với bộ phận chăm sóc khách hàng.
Regards,
Công Nghệ VPS - LEVU BIS Co., Ltd Website : http://congnghevps.net Email : info@congnghevps.net Phone : 055.3.842.159 Yahoo : levubis XEN VPS, Cloud VPS, Dedicated Server, Game Server
Date: Thu, 12 Dec 2013 15:58:35 +0530 From: raju.rajsand@gmail.com To: centos@centos.org Subject: Re: [CentOS] RHEL 7 Beta is now public
Greetings,
On Thu, Dec 12, 2013 at 3:35 PM, Karanbir Singh mail-lists@karan.org wrote:
<snip> > strategies, start writing docs at wiki.centos.org, start doing migration <snip>
+1 Important considering that new critical things like grub2, systemd, firewalld and the such.
With rhel7 entering many of us will be baby-sitting at least 4 releases - 4, 5, 6 and 7 at least for couple of more years
I am of course aware that there are many RHEL 2 and possilbly Redhat Linux 9 boxens out there.
-- Regards,
Rajagopal _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/12/2013 11:05 PM, Karanbir Singh wrote:
The overall aim is to have as many people as possible test the rhel7 beta and file bugs at bugzilla.redhat.com; that way everyone is testing anf doing feedback against the same builds, and we all win with a better overall end result.
I've installed RHEL7 onto a Xen VM running off a CentOS 6 host. I used yum to do the install as opposed to installing from the ISO so I've got a bit of a unique perspective on it. Anyways, I'll probably file a few bugs along the following lines:
The core group includes NetworkManager and postfix, neither should be core packages and should be excluded from a core or minimal install.
I had problems with selinux and sshd, I had to add a new policy and autorelabel before it would work with selinux in enforcing mode. I think needing to add the policy is probably a bug, but the autorelabel may be expected considering the rather unusual install method I used.
Problems with the mirrorlist, I had to comment it out and uncomment the baseurl from the repo file to get yum to work. I think this is known and will likely be resolved soon anyways.
Peter
On 12/12/2013 11:03 AM, Peter wrote:
I've installed RHEL7 onto a Xen VM running off a CentOS 6 host.
this is a great test to have done. Would really like to hear comments about process and result. I presume this is with the Xen4CentOS stack ?
- KB
On 12/13/2013 12:17 AM, Karanbir Singh wrote:
On 12/12/2013 11:03 AM, Peter wrote:
I've installed RHEL7 onto a Xen VM running off a CentOS 6 host.
this is a great test to have done. Would really like to hear comments about process and result. I presume this is with the Xen4CentOS stack ?
No, it's with CRCinAU's stack, actually, and mainly because I was running this server before Xen4CentOS was released.
Oh I forgot to mention the other issue, I'm running it under pvgrub (and it works fine with a normal grub.conf file, btw, no need to install grub2 that way), and I had to regenerate the initramfs, the one supplied with the kernel did not come with the xenblk and xennet drivers installed. That was also somewhat expected, though, and not necessarily a bug, but RHEL7 is supposed to be supported as a Xen domu, so it may be.
Peter
On 12/13/2013 12:30 AM, Peter wrote:
Oh I forgot to mention the other issue, I'm running it under pvgrub (and it works fine with a normal grub.conf file, btw, no need to install grub2 that way), and I had to regenerate the initramfs, the one supplied with the kernel did not come with the xenblk and xennet drivers installed. That was also somewhat expected, though, and not necessarily a bug, but RHEL7 is supposed to be supported as a Xen domu, so it may be.
...and speaking of upstream Xen support, RedHat have actually disabled Xen Dom0 support in the kernel. This would be something that they had to do on purpose, so I'm quite sure that it will be a waste of time to file a bug on it. It does mean that assuming that CentOS updates Xen4CentOS for CentOS 7 you'll need to once again supply the kernel for the dom0 as you can't get away with just using the stock RedHat one. On the bright side the kernel does have dom0 support and will just require a config file change to enable it, so the dom0 kernel can be just a rebuild of the stock one and not require a completely different kernel as is now the case.
Peter
On 12/12/13 11:17, Karanbir Singh wrote:
On 12/12/2013 11:03 AM, Peter wrote:
I've installed RHEL7 onto a Xen VM running off a CentOS 6 host.
this is a great test to have done. Would really like to hear comments about process and result. I presume this is with the Xen4CentOS stack ?
- KB
I intend to install it using KVM on CentOS 6.5 host.
I'll post the results.
Cheers,
Phil...
On Fri, Dec 13, 2013 at 12:03:55AM +1300, Peter wrote:
On 12/12/2013 11:05 PM, Karanbir Singh wrote:
The core group includes NetworkManager and postfix, neither should be core packages and should be excluded from a core or minimal install.
Fedora, and RedHat, apparently feel that NetworkManager is the way to go. As I never use it, I'm not sure if they ever fixed the fact that it can't handle bridges. To me (and I admit I'm an aging grouch), it's the sort of thing that RH has a bad habit of doing, taking things that aren't necessarily bad for something like Fedora, aimed at a single user laptop, and putting it into their system which is often used as a server.
(One can argue about Fedora's use case, but judging from their forums, and the various changes that have come over the years, I feel that most of its developers are thinking of a single user laptop.)
Somewhere in the release notes, it states that system-config-network is being removed in favor of some NetworkManager cli tool.
On 12/13/2013 01:04 AM, Scott Robbins wrote:
On Fri, Dec 13, 2013 at 12:03:55AM +1300, Peter wrote:
On 12/12/2013 11:05 PM, Karanbir Singh wrote:
The core group includes NetworkManager and postfix, neither should be core packages and should be excluded from a core or minimal install.
Fedora, and RedHat, apparently feel that NetworkManager is the way to go. As I never use it, I'm not sure if they ever fixed the fact that it can't handle bridges. To me (and I admit I'm an aging grouch), it's the sort of thing that RH has a bad habit of doing, taking things that aren't necessarily bad for something like Fedora, aimed at a single user laptop, and putting it into their system which is often used as a server.
(One can argue about Fedora's use case, but judging from their forums, and the various changes that have come over the years, I feel that most of its developers are thinking of a single user laptop.)
Somewhere in the release notes, it states that system-config-network is being removed in favor of some NetworkManager cli tool.
Right, but core should be just the bare minimum. NetworkManager is certainly not required to configure your network, in fact el7 runs just fine without it. Just set your ifcfg-eth0 scripts, etc, and you're good to go.
I found that I can exclude NM and postfix when group installing core from yum and it works just fine.
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter said the following on 12/12/2013 13:19:
Right, but core should be just the bare minimum. NetworkManager is certainly not required to configure your network, in fact el7 runs just fine without it. Just set your ifcfg-eth0 scripts, etc, and you're good to go.
I think that before choosing what should be included in the "minimal installation we must define the goals of the "minimal installation".
For instance the MTA is used by some programs to warn/report the SysAdmin; this could be the reason why the standard MTA is included.
Ciao, luigi
- -- / +--[Luigi Rosa]-- \
Always burn your bridges behind you. You never know who might be trying to follow. --Enabran Tain, "Improbable Cause"
On Fri, 13 Dec 2013 01:19:26 +1300 Peter peter@pajamian.dhs.org wrote:
Right, but core should be just the bare minimum. NetworkManager is certainly not required to configure your network, in fact el7 runs just fine without it. Just set your ifcfg-eth0 scripts, etc, and you're good to go.
By the same logic you could argue that a text editor is not required for a bare minimum --- namely, you can always use cat and echo from the command line to "edit" the config files.
The point of the text editor in a minimal installation is to make life easier for a sysadmin. The point of NetworkManager is the same --- it is included so that you don't have to "just set your ifcfg-eth0 scripts".
HTH, :-) Marko
Marko Vojinovic wrote:
On Fri, 13 Dec 2013 01:19:26 +1300 Peter peter@pajamian.dhs.org wrote:
Right, but core should be just the bare minimum. NetworkManager is certainly not required to configure your network, in fact el7 runs just fine without it. Just set your ifcfg-eth0 scripts, etc, and you're good to go.
By the same logic you could argue that a text editor is not required for a bare minimum --- namely, you can always use cat and echo from the command line to "edit" the config files.
The point of the text editor in a minimal installation is to make life easier for a sysadmin. The point of NetworkManager is the same --- it is included so that you don't have to "just set your ifcfg-eth0 scripts".
I disagree. NetworkManager is fine... on a laptop, where you're going to be moving it from network to network. For a wired network - that is, for any server (remember the "Enterprise" part of the name?) - it's utterly unnecessary. And it wall worked fine before NM. And NM has caused problems on occasion, before we just turned the thing *off*.
mark
On 12 December 2013 14:06, m.roth@5-cent.us wrote:
Marko Vojinovic wrote:
By the same logic you could argue that a text editor is not required for a bare minimum --- namely, you can always use cat and echo from the command line to "edit" the config files.
The point of the text editor in a minimal installation is to make life easier for a sysadmin. The point of NetworkManager is the same --- it is included so that you don't have to "just set your ifcfg-eth0 scripts".
I disagree. NetworkManager is fine... on a laptop, where you're going to be moving it from network to network. For a wired network - that is, for any server (remember the "Enterprise" part of the name?) - it's utterly unnecessary. And it wall worked fine before NM. And NM has caused problems on occasion, before we just turned the thing *off*.
The NetworkManager in EL6 is pretty poor - everyone knows that.
The NetworkManager in F19/20 (and EL7) is a vastly different beast with most of the reasons for disabling it in EL6 (bonding, bridging, vlans, etc) no longer being an issue.
Remember that the standard network service is literally source the relevant ifcfg-*, rule-* or route-* file and then using the variables just sourced run shell scripts calling ip addr, ip link, ip route, ip rule, etc to get the system into the state you want.
One of the drivers behind systemd in the beginning was to avoid arbitrary shell scripts configuring the system and resulting in the potential for confusion with selinux contexts and inherited environments when directly run by a user...
With NM handling the connection the correct details are obtained and then through the netlink APIs the interfaces configured as per the state desired without shell scripts and forking all over the place...
Read through the networking documentation, fire up a EL7 system and give it an honest try:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
Does NM need a gui to configure interfaces, etc.
On 12/12/2013 09:40 AM, James Hogarth wrote:
On 12 December 2013 14:06, m.roth@5-cent.us wrote:
Marko Vojinovic wrote:
By the same logic you could argue that a text editor is not required for a bare minimum --- namely, you can always use cat and echo from the command line to "edit" the config files.
The point of the text editor in a minimal installation is to make life easier for a sysadmin. The point of NetworkManager is the same --- it is included so that you don't have to "just set your ifcfg-eth0 scripts".
I disagree. NetworkManager is fine... on a laptop, where you're going to be moving it from network to network. For a wired network - that is, for any server (remember the "Enterprise" part of the name?) - it's utterly unnecessary. And it wall worked fine before NM. And NM has caused problems on occasion, before we just turned the thing *off*.
The NetworkManager in EL6 is pretty poor - everyone knows that.
The NetworkManager in F19/20 (and EL7) is a vastly different beast with most of the reasons for disabling it in EL6 (bonding, bridging, vlans, etc) no longer being an issue.
Remember that the standard network service is literally source the relevant ifcfg-*, rule-* or route-* file and then using the variables just sourced run shell scripts calling ip addr, ip link, ip route, ip rule, etc to get the system into the state you want.
One of the drivers behind systemd in the beginning was to avoid arbitrary shell scripts configuring the system and resulting in the potential for confusion with selinux contexts and inherited environments when directly run by a user...
With NM handling the connection the correct details are obtained and then through the netlink APIs the interfaces configured as per the state desired without shell scripts and forking all over the place...
Read through the networking documentation, fire up a EL7 system and give it an honest try:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/... _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, Dec 12, 2013 at 06:47:40PM -0500, Steve Clark wrote:
Does NM need a gui to configure interfaces, etc.
No, there's some sort of cli tool. Again, I don't use it.
You're still able to get rid of it if desired.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/12/2013 06:03 AM, Peter wrote:
On 12/12/2013 11:05 PM, Karanbir Singh wrote:
The overall aim is to have as many people as possible test the rhel7 beta and file bugs at bugzilla.redhat.com; that way everyone is testing anf doing feedback against the same builds, and we all win with a better overall end result.
I've installed RHEL7 onto a Xen VM running off a CentOS 6 host. I used yum to do the install as opposed to installing from the ISO so I've got a bit of a unique perspective on it. Anyways, I'll probably file a few bugs along the following lines:
The core group includes NetworkManager and postfix, neither should be core packages and should be excluded from a core or minimal install.
I had problems with selinux and sshd, I had to add a new policy and autorelabel before it would work with selinux in enforcing mode. I think needing to add the policy is probably a bug, but the autorelabel may be expected considering the rather unusual install method I used.
Problems with the mirrorlist, I had to comment it out and uncomment the baseurl from the repo file to get yum to work. I think this is known and will likely be resolved soon anyways.
Peter _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
What SELInux issue did you have? What policy did you need to add?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/2013 02:45 AM, Daniel J Walsh wrote:
What SELInux issue did you have? What policy did you need to add?
Unfortunately I've misplaced the audit logs and report of the problem, but this is the policy I had to add:
module mypol 1.0;
require { type unconfined_t; type sshd_net_t; type kernel_t; class process { dyntransition transition sigchld }; }
#============= kernel_t ============== allow kernel_t sshd_net_t:process dyntransition; allow kernel_t unconfined_t:process { dyntransition transition };
#============= sshd_net_t ============== allow sshd_net_t kernel_t:process sigchld;
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/12/2013 01:49 PM, Peter wrote:
On 12/13/2013 02:45 AM, Daniel J Walsh wrote:
What SELInux issue did you have? What policy did you need to add?
Unfortunately I've misplaced the audit logs and report of the problem, but this is the policy I had to add:
module mypol 1.0;
require { type unconfined_t; type sshd_net_t; type kernel_t; class process { dyntransition transition sigchld }; }
#============= kernel_t ============== allow kernel_t sshd_net_t:process dyntransition; allow kernel_t unconfined_t:process { dyntransition transition };
#============= sshd_net_t ============== allow sshd_net_t kernel_t:process sigchld;
Peter _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I actually do not think you need these, these were all caused by the originally mislabeled system. If you remove your custom policy, I bet it will work fine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/2013 08:20 AM, Daniel J Walsh wrote:
On 12/12/2013 01:49 PM, Peter wrote:
On 12/13/2013 02:45 AM, Daniel J Walsh wrote:
What SELInux issue did you have? What policy did you need to add?
Unfortunately I've misplaced the audit logs and report of the problem, but this is the policy I had to add:
module mypol 1.0;
require { type unconfined_t; type sshd_net_t; type kernel_t; class process { dyntransition transition sigchld }; }
#============= kernel_t ============== allow kernel_t sshd_net_t:process dyntransition; allow kernel_t unconfined_t:process { dyntransition transition };
#============= sshd_net_t ============== allow sshd_net_t kernel_t:process sigchld;
Peter _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I actually do not think you need these, these were all caused by the originally mislabeled system. If you remove your custom policy, I bet it will work fine.
That makes sense. I will try removing them and see how it goes (any pointers on how to remove a policy?).
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/2013 09:26 AM, Peter wrote:
I actually do not think you need these, these were all caused by the originally mislabeled system. If you remove your custom policy, I bet it will work fine.
That makes sense. I will try removing them and see how it goes (any pointers on how to remove a policy?).
I figured it out, and you are quite correct, it works fine without the policy. What I will have to remember is that from now on when doing this type of install to always do a relabel.
Thanks,
Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/12/2013 03:26 PM, Peter wrote:
On 12/13/2013 08:20 AM, Daniel J Walsh wrote:
On 12/12/2013 01:49 PM, Peter wrote:
On 12/13/2013 02:45 AM, Daniel J Walsh wrote:
What SELInux issue did you have? What policy did you need to add?
Unfortunately I've misplaced the audit logs and report of the problem, but this is the policy I had to add:
module mypol 1.0;
require { type unconfined_t; type sshd_net_t; type kernel_t; class process { dyntransition transition sigchld }; }
#============= kernel_t ============== allow kernel_t sshd_net_t:process dyntransition; allow kernel_t unconfined_t:process { dyntransition transition };
#============= sshd_net_t ============== allow sshd_net_t kernel_t:process sigchld;
Peter _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I actually do not think you need these, these were all caused by the originally mislabeled system. If you remove your custom policy, I bet it will work fine.
That makes sense. I will try removing them and see how it goes (any pointers on how to remove a policy?).
Peter _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
semodule -r POLICYNAME.
For example if you installed mypol.pp
You would probably remove
semodule -r mypol
Op 12-12-13 08:49, Sorin Srbu schreef:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Karanbir Singh Sent: den 11 december 2013 16:56 To: CentOS mailing list Subject: [CentOS] RHEL 7 Beta is now public
Hi,
http://ftp.redhat.com/redhat/rhel/beta/7/
Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production.
As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues at http://bugzilla.redhat.com/
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process.
I see nobody's asked when CentOS 7 will be out yet. ;-)
Anyway, will be interesting to check out the "new" gnome.
-- //Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
just installed it in Vurtualbox. That went fine.
greetings, J.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Johan Vermeulen Sent: den 12 december 2013 10:44 To: centos@centos.org Subject: Re: [CentOS] RHEL 7 Beta is now public
just installed it in Vurtualbox. That went fine.
I did that too, installed to VirtualBox, but didn't get a GUI for some reason...
-- //Sorin
On 12/11/2013 08:56, Karanbir Singh wrote:
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam
In the aftermath of the CentOS 6.0 trauma, I recall there being speculation that building the next major release wouldn't be as troublesome, for various reasons[*]. Did that turn out to be true?
[*] a) Improved procedures, b) grand works that, done once, don't need to be done over again as long as upstream doesn't change the world again, etc.
On 12 December 2013 15:32, Warren Young warren@etr-usa.com wrote:
On 12/11/2013 08:56, Karanbir Singh wrote:
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam
In the aftermath of the CentOS 6.0 trauma, I recall there being speculation that building the next major release wouldn't be as troublesome, for various reasons[*]. Did that turn out to be true?
[*] a) Improved procedures, b) grand works that, done once, don't need to be done over again as long as upstream doesn't change the world again, etc.
Well seeing as we haven't had a major release since then it's hard to say (although times for the point releases to come out have been markedly short)...
Guess EL7 will be a true test ;)
On 12/12/2013 09:13, James Hogarth wrote:
On 12 December 2013 15:32, Warren Young warren@etr-usa.com wrote:
On 12/11/2013 08:56, Karanbir Singh wrote:
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam
In the aftermath of the CentOS 6.0 trauma, I recall there being speculation that building the next major release wouldn't be as troublesome, for various reasons[*]. Did that turn out to be true?
[*] a) Improved procedures, b) grand works that, done once, don't need to be done over again as long as upstream doesn't change the world again, etc.
Well seeing as we haven't had a major release since then it's hard to say (although times for the point releases to come out have been markedly short)...
My assumption when asking is that they had already taken enough of a look at the RH7 beta to see if Red Hat had undone the hard work of getting CentOS 6 out the door.
On 12/12/2013 03:32 PM, Warren Young wrote:
On 12/11/2013 08:56, Karanbir Singh wrote:
Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam
In the aftermath of the CentOS 6.0 trauma, I recall there being speculation that building the next major release wouldn't be as troublesome, for various reasons[*]. Did that turn out to be true?
We will soon find out :)
-
Alain Péan -
Andrew Wyatt -
Connie Sieh -
Daniel J Walsh -
James Hogarth -
Johan Vermeulen -
John R Pierce -
Karanbir Singh -
Leon Fauster -
Les Mikesell -
LEVU BIS -
Luigi Rosa -
m.roth＠5-cent.us -
Marko Vojinovic -
Ned Slider -
Peter -
Phil Dobbin -
Rajagopal Swaminathan -
Scott Robbins -
SilverTip257 -
Sorin Srbu -
Steve Clark -
Warren Young