Re: Default cfengine classes have changed with SL5.8

[Nico Kadel-Garcia]

On Mon, May 28, 2012 at 3:30 PM, Chris O'Regan wrote:

> We are in the process of patching our hosts, going from SL5.7 to SL5.8.
> After updating a couple of systems, we found a handful of rpmnew/rpmsave
> files for some of the files that we've customized, and so we merged the
> changes. These files are copied via cfengine, and we have some scripts
> that handle cleaning up the rpmnew/rpmsave files that we've already
> addressed. In preparation for patching the rest of our systems, we
> pushed out the new files, but to our surprise, the systems we had just
> updated to SL5.8 still had the old files! Those still at SL5.7 had
> received them as expected.
>
> After some investigation, we discovered that the default cfengine
> classes have changed in SL5.8, and as a result, some of our cfengine
> scripts were no longer functioning correctly. Here are the SL-related
> classes that are defined in SL5.7:
>
>scientific
>scientific_sl
>scientific_sl_5
>scientific_sl_5_7
>scientificsl
>scientificsl_5
>scientificsl_5_7
>scientificsl_boron
>
> And here's what are defined in SL5.8:
>
>scientific
>scientific_5
>scientific_5_8
>scientific_boron
>
> We were making use of the 'scientific_sl' and 'scientific_sl_5' classes,
> but now those no longer exist. It was simple enough to fix our cfengine
> scripts (e.g. 'scientific_sl' is now '(scientific|scientific_sl)') but
> we are puzzled as to why this would change so suddenly and quite
> concerned that such an unexpected change could possibly break our
> systems.
>
> Our version of cfengine has not changed and it is not installed as part
> of the operating system but within our own software tree. For the sake
> of completeness, however, it is v2.2.9. I'm not exactly sure how
> cfengine generates these classes, but I think it is based on the text
> in /etc/issue. I see that there has been a slight change:
>
>Scientific Linux SL release 5.7 (Boron)
>Scientific Linux release 5.8 (Boron)
>
> It neatly explains where the 'sl' went from the cfengine default
> classes! :-) While we have our work-around, I think it would be kind to
> put the 'SL' back into /etc/issue for others who may be facing a similar
> situation.
>
> Gahhh Thanks for the heads up, I was looking at cfengine for a project.

Parsing /etc/issue.net is a tradional quagmire, but much faster and lighter
weigbht than trying to run "rpm" commands. Looks like a problem to notify
the cfengine maintainers of.

Re: liveCD booting into AMD A8-3870 processor

[Tanmoy Chatterjee]

On Fri, May 25, 2012 at 2:20 PM, Akemi Yagi  wrote:
> On Thu, May 24, 2012 at 8:08 PM, zxq9  wrote:
>> On 05/25/2012 11:56 AM, Phong X Nguyen wrote:
>
>>> Can you use DKMS to automate driver building on kernel update?
>>
>> I haven't messed with it myself, but it certainly should work fine if you
>> just want to keep the same version of Catalyst around.
>>
>> Since the AMD driver release updates nearly as often as the Kernel itself,
>> I've been building new fglrx rpms with the latest driver against each new
>> kernel as they come out and keeping them in our repo. Some of the driver
>> updates bring significant performance imrovements that actually matter to
>> us, so we try not to miss any.
>
> Very true. Both the ATI driver and the kernel get updated fairly
> frequently (about once a month).
>
>> I haven't found a way to completely automate away keeping track of the new
>> AMD releases yet, though, so keeping fglrx rpms up to date is a lot like
>> packaging a high-frequency project for a distro (as in, treating AMD
>> Catalyst essentially the same way you would an upstream project).
>>
>> Anyway, DKMS is simple enough to set up that feeding it new Catalyst
>> releases as they come out shouldn't be too difficult. (Well, from my
>> understanding anyway. Again, I haven't done this myself yet, though I might
>> give it a shot if I can get some time to play with it -- though even if any
>> part of it is difficult the situation should be routine enough that wrapping
>> any needed re-configuration process in a script should be trivial.)
>
> The kernel module HowTo article has a section for DKMS :
>
> http://wiki.centos.org/HowTos/BuildingKernelModules
>
> I have not tried it myself since I originally wrote it (because kmods
> became my primary method of module building) but I believe it still
> works.
>
> Akemi

Thanks to all. Kindly check the following - there AMD admits there
shortcomings with linux support of APU.
" 
http://www.theinquirer.net/inquirer/news/2180336/amd-admits-improving-linux-opencl-support
"

Another minor issue when upgrading from SL5.7 to SL5.8

[Chris O'Regan]

We maintain our own local mirror of SL5 and update our servers from it.
We have created our own repo file in /etc/yum.repos.d/ and have disabled
everything else by setting "enable=1" to "enable=0". We do this instead
of simply deleting them in case we ever need refer to those files.

We have a cfengine script that does this and it has worked perfectly
until SL5.8. It seems that a new repo was introduced in this version
(sl-security-jdk) but the regex that matches the other repos does not
match this one. That is because there is trailing whitespace after the
"enabled=1" in that section.

I have update my regex from "^enable=1$" to "^enabled=1.*$", but I
wonder what that trailing whitespace is doing there in the first
place! ;-)


-- 
Chris O'Regan 
Senior Unix Systems Administrator, Academic IT Services
Faculty of Engineering and Computer Science
Concordia University, Montreal, Canada

Re: Another minor issue when upgrading from SL5.7 to SL5.8

[Connie Sieh]

On Tue, 29 May 2012, Chris O'Regan wrote:


We maintain our own local mirror of SL5 and update our servers from it.
We have created our own repo file in /etc/yum.repos.d/ and have disabled
everything else by setting "enable=1" to "enable=0". We do this instead
of simply deleting them in case we ever need refer to those files.

We have a cfengine script that does this and it has worked perfectly
until SL5.8. It seems that a new repo was introduced in this version
(sl-security-jdk) but the regex that matches the other repos does not
match this one. That is because there is trailing whitespace after the
"enabled=1" in that section.

I have update my regex from "^enable=1$" to "^enabled=1.*$", but I
wonder what that trailing whitespace is doing there in the first
place! ;-)





It is a typo.  We will fix it in the next release.  Thanks for reporting 
this issue.


-Connie Sieh

Re: Difference between the various SL6 repos?

[Connie Sieh]

On Fri, 25 May 2012, Stefan Lasiewski wrote:


--e89a8f6475033424bb04c0e5ae31
Content-Type: text/plain; charset=ISO-8859-1

I have a question regarding the various RPM repos for the SL6.

Some of the repos have a major.minor version number:

ftp://ftp.scientificlinux.org/linux/scientific/6.0/
ftp://ftp.scientificlinux.org/linux/scientific/6.1/
ftp://ftp.scientificlinux.org/linux/scientific/6.2/

And then there are repos for the '6' and '6x' releases:

ftp://ftp.scientificlinux.org/linux/scientific/6/
ftp://ftp.scientificlinux.org/linux/scientific/6x/


The subdirectories of //ftp.scientificlinux.org/linux/scientific/6/ just 
point to //ftp.scientificlinux.org/linux/scientific/6x/ .  This was just 
to make it easy to find "6" .




and a repo named '6rolling':

ftp://ftp.scientificlinux.org/linux/scientific/6rolling/

My questions:

- What are the differences between these different kinds of repos?
- When should I be tracking the '6' repository vs the 6.2 repository vs.
the '6rolling' repository?


6x is a symbolic link that points to the "current" release of 6. This is 
so you always "find" the current release.  We also provide a "yum-conf" 
which which "points" to 6x.  When a new "point" release is made all the 
systems with their yum-confs "pointing" to 6x will be updated to this 
newer version.  Note the "non yum-conf 6x" will keep the system at that 
point release.



- What is 6rolling? Is it similar to the Fedora Rawhide development tree?


Yes it is similar to "Rawhide" .  "Rawhide" was the inspiration in the 
naming of this "test" tree.  So you have "Rolling Rolling Rawhide" from 
the "song".  Also "rolling things" are moving/changing so this goes with 
well with use of "rolling" for  "alpha/beta" releases .



With CentOS 5 and SL5, there was never a repository named '5' or '5x', and
I am just trying to become more familiar with the new way of doing things.

Forgive me for asking what might be a simple question. But I cannot find
any description of the 6rolling or 6x repos on www.scientificlinux.org, or
https://www.scientificlinux.org/documentation/faq/ .



We will update the faq.  This is a very good question for it.



Thank you,

-= Stefan




-Connie Sieh

Re: Difference between the various SL6 repos?

[Stefan Lasiewski]

On Tue, May 29, 2012 at 12:06 PM, Connie Sieh  wrote:

On Fri, 25 May 2012, Stefan Lasiewski wrote:
>
> I have a question regarding the various RPM repos for the SL6.
>>
>> Some of the repos have a major.minor version number:
>>
>> ftp://ftp.scientificlinux.org/**linux/scientific/6.0/
>> ftp://ftp.scientificlinux.org/**linux/scientific/6.1/
>> ftp://ftp.scientificlinux.org/**linux/scientific/6.2/
>>
>> And then there are repos for the '6' and '6x' releases:
>>
>> ftp://ftp.scientificlinux.org/**linux/scientific/6/
>> ftp://ftp.scientificlinux.org/**linux/scientific/6x/
>>
>
> The subdirectories of 
> //ftp.scientificlinux.org/**linux/scientific/6/just
>  point to //
> ftp.scientificlinux.org/**linux/scientific/6x/.
>   This was just to make it easy to find "6" .
>
>
>> and a repo named '6rolling':
>>
>> ftp://ftp.scientificlinux.org/**linux/scientific/6rolling/
>>
>> My questions:
>>
>> - What are the differences between these different kinds of repos?
>> - When should I be tracking the '6' repository vs the 6.2 repository vs.
>> the '6rolling' repository?
>>
>
> 6x is a symbolic link that points to the "current" release of 6. This is
> so you always "find" the current release.  We also provide a "yum-conf"
> which which "points" to 6x.  When a new "point" release is made all the
> systems with their yum-confs "pointing" to 6x will be updated to this newer
> version.  Note the "non yum-conf 6x" will keep the system at that point
> release.
>

I am mostly interested in security updates, and am less interested in
feature updates. Will the 6.N repositories (6.1, 6.2, etc) continue to
receive security updates for several years, or should I consider upgrading
to the next point release (From 6.1 to 6.2, for example) in order to
continue receiving security updates?


> We will update the faq.  This is a very good question for it.
>

Thank you Connie!

-= Stefan



-- 
Stefan Lasiewski Email: stef...@nersc.gov
Computer System Engineer IIIEmail: slasiew...@lbl.gov
Networking, Security, and Servers Group

National Energy Research Scientific Computing Center
Lawrence Berkeley National Laboratory