Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?
On Tue, Jul 30, 2013 at 8:05 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Mon, Jul 29, 2013 at 1:25 PM, Lamar Owen lo...@pari.edu wrote: On 07/29/2013 10:47 AM, Pat Riehecky wrote: I believe there was some relevant information in this year's Red Hat Enterprise Linux Roadmap http://videos.cdn.redhat.com/2013-summit-platform-2.mp4 at Red Hat Summit. See https://rhsummit.files.wordpress.com/2013/06/dumas_w_0120_rhel_roadmap1.pdf See slide 11. Also includes info relevant to the large filesystem thread. Seems EL7 may ship with XFS as the default filesystem if it passes validation. (Slide 17). A very good read; time will tell how much actually comes to pass. (I'm personally looking forward to IEEE1588 PTP as shown on slide 38)... It is interesting. I also see Samba 3.x, not Samba 4.x. *Rats*. I was hoping for built-in Active Directory server replacements: guess I'll be rebundling the work I've done backporting Samba 4.0.7 to RHEL 6. And the slides don't say anything about the migration from SysV init scripts to systemd: that is going to be a *serious* adventure for 3rd-party open source components, like EPEL and Repoforge and atrpms. http://rhsummit.files.wordpress.com/2013/06/poettering_f_0945_getting_ready_for_systemd-the-new-red-hat-enterprise-linux-7-service-manager.pdf
Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?
On Tue, Jul 30, 2013 at 8:18 AM, Tom H tomh0...@gmail.com wrote: On Tue, Jul 30, 2013 at 8:05 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Mon, Jul 29, 2013 at 1:25 PM, Lamar Owen lo...@pari.edu wrote: On 07/29/2013 10:47 AM, Pat Riehecky wrote: I believe there was some relevant information in this year's Red Hat Enterprise Linux Roadmap http://videos.cdn.redhat.com/2013-summit-platform-2.mp4 at Red Hat Summit. See https://rhsummit.files.wordpress.com/2013/06/dumas_w_0120_rhel_roadmap1.pdf See slide 11. Also includes info relevant to the large filesystem thread. Seems EL7 may ship with XFS as the default filesystem if it passes validation. (Slide 17). A very good read; time will tell how much actually comes to pass. (I'm personally looking forward to IEEE1588 PTP as shown on slide 38)... It is interesting. I also see Samba 3.x, not Samba 4.x. *Rats*. I was hoping for built-in Active Directory server replacements: guess I'll be rebundling the work I've done backporting Samba 4.0.7 to RHEL 6. And the slides don't say anything about the migration from SysV init scripts to systemd: that is going to be a *serious* adventure for 3rd-party open source components, like EPEL and Repoforge and atrpms. http://rhsummit.files.wordpress.com/2013/06/poettering_f_0945_getting_ready_for_systemd-the-new-red-hat-enterprise-linux-7-service-manager.pdf Thanks, good link. I'm just concerned it's going to cause build problems for *every single open source daemon* as their SRPM's or .spec files need to have two sets of options, one for the older SysV init scripts and one for systemd, or need to be split to two different .spec files. This is going to be so much fun!
Re: Upgrade SLC5 to SLC6 ?
I would expect that amount of problems depends on what is installed. And how much /etc differs from default. One story if it is, let say, minimal install with dhcp server, another story if it is host filled with all possible software in active use. Anton. On Jul 30, 2013, at 5:58 PM, Paul Robert Marino prmari...@gmail.com wrote: gennerally its possible to upgrade from one minor release to the next but not major releases so 5.1 to say 5.9 is possible but 5.x to 6.x is not. you can attempt it through yum but you will have tons of problems. Fedora you usually can upgrade versions but even Fedora has version cut offs where you have to do a scratch install for example 16 to 17 was one of those cutoffs. On Mon, Jul 29, 2013 at 4:08 AM, Tom H tomh0...@gmail.com wrote: On Thu, Jul 25, 2013 at 12:48 PM, Lamar Owen lo...@pari.edu wrote: On 07/25/2013 01:28 AM, David G.Miller wrote: The problem of upgrading from FC-n to FC-n+1 is basically the same as upgrading EL-n to EL-n+1. No; upgrading ELx to ELx+1 is like upgrading Fn to Fn+k(x), where k(x) is an element of an array of integer constants; x is the starting EL release, so k(3)=3 [RHEL3 was based on what I'm going to call 'Fedora Core 0,' which was the pre-fedora RHL 10 beta; see footnote 1]; k(4)=3, k(5)=6 (or 7, since some F13 packages showed up in EL6), and k(6) will probably be 7 or so. Doing this without going stepwise through the Fedora releases is a challenge. I forget how large of an increment preupgrade can do, but I remember doing it F12 to F13 to F14, and it had issues even going Fn to Fn+1, especially if any part of the massive yum transaction fails for any reason (it leaves the system with a half completed yum transaction that yum-complete-transaction simply won't deal with, and then you have to finish the upgrade manually and manually remove the older packages) I have done this twice on two separate machines, one had issues going from F12 to F13 and the other one had issues going from F13 to F14. The Fn to Fn+1 upgrade path is somewhat expected to work; Fn to Fn+2 probably won't work correctly, especially if major changes are in both releases. In theory, preupgrade can upgrade a system to the latest Fedora release; I assume from a still supported release so it's Fn to Fn+2. I have a colleague who went on his laptop from 12 to 14 and you can find people skipping a release on mailing lists and forums. But they're there because they have a problem. :) Both preupgrade and fedup are the source of quite a few list and forum posts. A more usable upgrade system would be one where you could snapshot a system transparently before an upgrade and fallback to the original in case of failure, like Solaris with its Boot Environment. In the Ubuntu world, this is like taking Ubuntu LTS 6.06 straight to 8.04, or worse. I've done the 6.06 to 8.04 thing, by the way, and have no desire to repeat it. Ubuntu/Canonical support LTS-to-LTS upgrades (6.06 to 8.04 to 10.04 to 12.04) where intermediate versions are skipped (so they must be QAd quite extensively; and companies with support contracts must be on-hand for all phases of the upgrade). I've tested an 8.04 to 10.04 upgrade (as I've tested preupgrade and fedup upgrades) but I've never used Linux upgrades in a live/production setting.
Re: Upgrade SLC5 to SLC6 ?
While that's somewhat true the really concern is unresolvable conflicts between packages during the update also you may experience selinux issues among other things.-- Sent from my HP Pre3On Jul 30, 2013 12:05, Anton Starikov ant.stari...@gmail.com wrote: I would expect that amount of problems depends on what is installed. And how much /etc differs from default. One story if it is, let say, minimal install with dhcp server, another story if it is host filled with all possible software in active use. Anton. On Jul 30, 2013, at 5:58 PM, Paul Robert Marino prmari...@gmail.com wrote: gennerally its possible to upgrade from one minor release to the next but not major releases so 5.1 to say 5.9 is possible but 5.x to 6.x is not. you can attempt it through yum but you will have tons of problems. Fedora you usually can upgrade versions but even Fedora has version cut offs where you have to do a scratch install for example 16 to 17 was one of those cutoffs. On Mon, Jul 29, 2013 at 4:08 AM, Tom H tomh0...@gmail.com wrote: On Thu, Jul 25, 2013 at 12:48 PM, Lamar Owen lo...@pari.edu wrote: On 07/25/2013 01:28 AM, David G.Miller wrote: The problem of upgrading from FC-n to FC-n+1 is basically the same as upgrading EL-n to EL-n+1. No; upgrading ELx to ELx+1 is like upgrading Fn to Fn+k(x), where k(x) is an element of an array of integer constants; x is the starting EL release, so k(3)=3 [RHEL3 was based on what I'm going to call 'Fedora Core 0,' which was the pre-fedora RHL 10 beta; see footnote 1]; k(4)=3, k(5)=6 (or 7, since some F13 packages showed up in EL6), and k(6) will probably be 7 or so. Doing this without going stepwise through the Fedora releases is a challenge. I forget how large of an increment preupgrade can do, but I remember doing it F12 to F13 to F14, and it had issues even going Fn to Fn+1, especially if any part of the massive yum transaction fails for any reason (it leaves the system with a half completed yum transaction that yum-complete-transaction simply won't deal with, and then you have to finish the upgrade manually and manually remove the older packages) I have done this twice on two separate machines, one had issues going from F12 to F13 and the other one had issues going from F13 to F14. The Fn to Fn+1 upgrade path is somewhat expected to work; Fn to Fn+2 probably won't work correctly, especially if major changes are in both releases. In theory, preupgrade can upgrade a system to the latest Fedora release; I assume from a still supported release so it's Fn to Fn+2. I have a colleague who went on his laptop from 12 to 14 and you can find people skipping a release on mailing lists and forums. But they're there because they have a problem. :) Both preupgrade and fedup are the source of quite a few list and forum posts. A more usable upgrade system would be one where you could snapshot a system transparently before an upgrade and fallback to the original in case of failure, like Solaris with its "Boot Environment". In the Ubuntu world, this is like taking Ubuntu LTS 6.06 straight to 8.04, or worse. I've done the 6.06 to 8.04 thing, by the way, and have no desire to repeat it. Ubuntu/Canonical support LTS-to-LTS upgrades (6.06 to 8.04 to 10.04 to 12.04) where intermediate versions are skipped (so they must be QAd quite extensively; and companies with support contracts must be on-hand for all phases of the upgrade). I've tested an 8.04 to 10.04 upgrade (as I've tested preupgrade and fedup upgrades) but I've never used Linux upgrades in a live/production setting.
Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?
On 07/30/2013 10:26 PM, Tom H wrote:
On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcianka...@gmail.com wrote:
On Tue, Jul 30, 2013 at 8:18 AM, Tom Htomh0...@gmail.com wrote:
Thanks, good link. I'm just concerned it's going to cause build
problems for *every single open source daemon* as their SRPM's or
.spec files need to have two sets of options, one for the older SysV
init scripts and one for systemd, or need to be split to two different
.spec files. This is going to be so much fun!
You're welcome.
Very true. Similar to some current Fedora spec files:
%if 0%{?rhel}
...
%endif
%if 0%{?fedora}
...
%endif
An eyesore and a mess; until December 2020...
tl;dr, Relevant Fedora thread first:
http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
Reminds me of a dismal post from October:
http://zxq9.com/archives/711
Is CFEngine 3.5 Enterprise not possible on SL
We are attempting to use CFEngine 3.5 Enterprise on SL6x x86-64 for both the server (policyserver/hub) and client (host) systems. We have now gotten CFEngine to work except for one detail as explained from: https://cfengine.com/archive/manuals/enterprise-2-2-ownersmanual 2.2 Operating system support CFEngine can be made to run on most operating systems. For efficiency CFEngine only supports packages for a number of recent popular operating systems, which should be up to date with patches. If we don't have packages for your particular operating systems we can usually make packages by special arrangement please contact your sales representative. CFEngine 3 Free Enterprise is only available for Linux Operating Systems (both hub and client). Commercial CFEngine 3 Enterprise customers have access to all the following Operating Systems. The hub (policy server) is only available for derivatives of the top GNU/Linux distributions (Debian, Red Hat, SuSE, Ubuntu), as these make available software that the hub relies on for data storage and processing. Operating system choices for the hub are: Debian 6 Ubuntu 8.04, 10.04, 12.04 RHEL/CentOS 5, 6 Operating system choices for the clients are: AIX 5.3, 6.1, CentOS 5, 6, Debian 5, 6, Fedora 14, 15, 16, FreeBSD 7, 8, HP-UX, NetBSD 4.0, 5.0, 5.1, openSUSE 10.2, 10.3, 11.1, 11.2, 11.3, 11.4, RHEL 4, 5, 6, SLES 9, 10, 11, SUSE Linux 9.1, 9.2, 9.3, 10.0, 10.1, Solaris 8, 9, 10, Ubuntu 8.04, 8.10, 9.04, 9.10, 10.04, 10.10, 11.04, 11.10, 12.04, Windows XP, Vista, 7, Server 2003, Server 2008 End quote. The diagnostic we are getting from CFEngine is: /cfe_internal_update_bins/files/'$(local_software_dir)': Can't stat '/var/cfengine/master_software_updates/scientific_6_x86_64' in files.copyfrom promise As can be read from the (fairly well hidden) documentation supplied by CFEngine, SL is not supported per se. Nonetheless, except for some repointing of repository Internet locations and other similar minor items, as both CentOS 6 and RHEL 6 are supported, one should be able to modify the files to support SL6x. Has anyone done this? If so, the files needed for SL6x from which to work greatly would be appreciated. Otherwise, CFEngine has no business unpacking and installing if the environment is not supported.
Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?
On Tue, Jul 30, 2013 at 5:12 PM, zxq9 z...@zxq9.com wrote:
On 07/30/2013 10:26 PM, Tom H wrote:
On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcianka...@gmail.com
wrote:
On Tue, Jul 30, 2013 at 8:18 AM, Tom Htomh0...@gmail.com wrote:
Thanks, good link. I'm just concerned it's going to cause build
problems for *every single open source daemon* as their SRPM's or
.spec files need to have two sets of options, one for the older SysV
init scripts and one for systemd, or need to be split to two different
.spec files. This is going to be so much fun!
You're welcome.
Very true. Similar to some current Fedora spec files:
%if 0%{?rhel}
...
%endif
%if 0%{?fedora}
...
%endif
An eyesore and a mess; until December 2020...
tl;dr, Relevant Fedora thread first:
http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
Reminds me of a dismal post from October:
http://zxq9.com/archives/711
Yes. It's too bad that dismal poster didn't actually know more of the
history and types of daemon managers. SysV init scripts, which are
what that article so casually refer to as *nix, are actually a
massive upgrade from the old /etc/rc.local setups. But there are
problems with them: they don't maintain the states of daemons that are
likely to crash and need restart, they're used inconsistently and
erratically, and their output is not logged reliably when they're run
as a root user. So there are a compelling set of reasons to use a
better daemon and init process.
i am afraid that the systemd authors have fallen prey to the idea that
their own tool can do *everything* better than the smaller, less
flexible, but more stable and better integrated tools currently used.
NetworkManager and Gnome3 have encountered similar issues, and it
concerns me about what we will inherit from upstream for use in
Scientific Linux 7.
