Re: [CentOS] recent ruby packages?

[Phil Dobbin]

On 02/05/2013 07:55 AM, pnorton3...@gmail.com wrote:

> Maybe we should think about writing the kernel in java/python/ruby/php etc?  
> Wonder why this hasn't happened before? 

Linus is on Google +. I'm sure he'd be more than happy to answer that
one for you :-)

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 5.8 & 6.3, Debian Squeeze & Wheezy, Fedora Beefy & Spherical,
Lubuntu 12.10, OS X Snow Leopard & Ubuntu Precise & Quantal
GnuPG Key : http://www.horse-latitudes.co.uk/publickey.asc


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 96, Issue 2

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CEBA-2013:0226 CentOS 5 device-mapper-multipath   Update
  (Johnny Hughes)
   2. CEBA-2013:0225  CentOS 6 wpa_supplicant Update (Johnny Hughes)


--

Message: 1
Date: Mon, 4 Feb 2013 12:33:51 +
From: Johnny Hughes 
Subject: [CentOS-announce] CEBA-2013:0226 CentOS 5
device-mapper-multipath Update
To: centos-annou...@centos.org
Message-ID: <20130204123351.ga8...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Bugfix Advisory 2013:0226 

Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-0226.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
e395a80d55cf988eb98dd34e1eefcacfd06addccf02bf0139b26ea841a239a2b  
device-mapper-multipath-0.4.7-54.el5_9.1.i386.rpm
1e79a640cd9eb694fbd67295b75752f74df345f4f823b043e263fd06036c474e  
kpartx-0.4.7-54.el5_9.1.i386.rpm

x86_64:
6ef6083633fec59e3adba1c3467161ade17b519582b3879f177426266aa300aa  
device-mapper-multipath-0.4.7-54.el5_9.1.x86_64.rpm
c172b2679de8baea077a29b45c9d88b9e42d9a956cc27491542dfaf50eec9cff  
kpartx-0.4.7-54.el5_9.1.x86_64.rpm

Source:
166e670f133c202a5a87b8a890cac7c4a28ffb78f1979e76a30c4b2266157605  
device-mapper-multipath-0.4.7-54.el5_9.1.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net



--

Message: 2
Date: Mon, 4 Feb 2013 14:56:35 +
From: Johnny Hughes 
Subject: [CentOS-announce] CEBA-2013:0225  CentOS 6 wpa_supplicant
Update
To: centos-annou...@centos.org
Message-ID: <20130204145635.ga15...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Bugfix Advisory 2013:0225 

Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-0225.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
498147d6e5691890b123be77e196d87dd79cc7f0fb8f5196647c4b83427be9cb  
wpa_supplicant-0.7.3-4.el6_3.i686.rpm

x86_64:
bd74814a2c0d0ba18f7ba447377158bdb0cf2d291641a64f060457ed40a3daa6  
wpa_supplicant-0.7.3-4.el6_3.x86_64.rpm

Source:
ed37846bd2ee704242d29e5997ba645a6e0344ca0aa3d0b3fe601efffc5225f6  
wpa_supplicant-0.7.3-4.el6_3.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net



--

___
CentOS-announce mailing list
centos-annou...@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce


End of CentOS-announce Digest, Vol 96, Issue 2
**
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[mark]

On 02/04/13 22:27, Craig White wrote:
> On Mon, 2013-02-04 at 18:01 -0600, Les Mikesell wrote:
>> On Mon, Feb 4, 2013 at 5:36 PM, Craig White
>> wrote:
>>>

> Gems however are another matter altogether and a typical ruby
> application (Rails or otherwise) is likely to require many ruby gems
> (think Perl CPAN).

Hint: most perl modules are available as rpms.

mark

-- 
"Morality is alright, but what about dividends?"
 --  Kaiser Willhem II
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[mark]

On 02/05/13 02:30, Phil Dobbin wrote:
> On 02/04/2013 11:36 PM, Craig White wrote:
>> On Feb 4, 2013, at 3:54 PM, Les Mikesell wrote:
>>> On Mon, Feb 4, 2013 at 4:41 PM, Craig
>>> White  wrote:

>>  there may very well be ruby versions in EPEL, I don't know
>> and never looked.

>
> Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607)
> [x86_64-linux]' which is the latest stable version&  can be installed
> via yum.

Dunno if it'll work on CentOS, but thanks, Phil - this the first 
actually useful response to *my* issue from ruby people.

mark
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[Les Mikesell]

On Tue, Feb 5, 2013 at 7:10 AM, mark  wrote:
>
>>
>> Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607)
>> [x86_64-linux]' which is the latest stable version&  can be installed
>> via yum.
> 
> Dunno if it'll work on CentOS, but thanks, Phil - this the first
> actually useful response to *my* issue from ruby people.

But still leaves the question of why a usable version isn't maintained
for RHEL or CentOS, either in the distro or by the project.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[James B. Byrne]

On Mon, February 4, 2013 10:21, m.r...@5-cent.us wrote:
> Does anyone know of a repository that's *trustworthy* (gotta worry
> 'bout malware) with newer ruby rpm's than RHEL has?

I have not found one yet.

>
> OT: the more I deal with ruby, the less I like it. Someone here was
> ready to move to a newer version, and from the ruby.org website,
> they're apparently actively hostile to all RH-related distros,
> even though we're the most common in North America. They've got
> a how to do it from debian and arch, how to use their own installer,
> and, oh, yes, they say a lot of their community feels you should
> build from source.

As the man says, Ruby is open source.  If you have an itch then
scratch it yourself.  I had much the same issue with Ruby albeit on
three platforms simultaneously, MS-Win, Apple-OSX and RHEL-Linux.  In
the end I went with Ruby Version Manager to save my sanity.

However, RVM is a very intrusive bit of environment scripting and so I
later switched to RBENV.  That is a little lighter but I was still not
satisfied with the amount of background work required to get Rails
deployments to work with RVM/RBENV on different hosts.  For
development either RVM or RBENV is almost certainly the way to go for
non-sysadmins.  For deployments I am not so sure.

I ended up building my own rpm packages using rpmdev and mock.  After
avoiding the issue for years I discovered that rolling your own rpms
for Ruby is pretty simple, once you get a working spec file (which I
eventually discovered and stole).  If you care to go down that road I
have provided a write up (spec file included) online at:

http://byrnejb.wordpress.com/2013/01/30/building-ruby-1-9-3-for-centos-6-3/

>
> Sorry, that's not my idea of a stable language that I'd ever recommend
> to someone
>
> mark

Yeah, well I can recall spending weeks on the phone with HP's tech
response centre in Raleigh trying to get Cobol II to work as
documented.  Nobody asked me for my recommendation either.

As for providing the packages, I am willing to send them to whoever
wishes to host them.  Even to CentOS extras if anyone would be kind
enough to guide me through the administrative procedure to do so.



-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[James B. Byrne]

On Mon, February 4, 2013 19:01, Les Mikesell wrote:
> On Mon, Feb 4, 2013 at 5:36 PM, Craig White 
> wrote:
>>
>>
>> And lastly, Ruby is an ecosystem far beyond the base language. It
>> has a 'gem' package management system which again is cross platform
>> and even when you try to package ruby in rpm's, there's no way an RH
>> or EPEL will keep up with updates.
>>
>
> I guess I still don't understand why you think that is a good thing.
> If the developers didn't get it right the first dozen times, why do
> you think the next update will be better?  That is, if EPEL can't keep
> up, why would anyone want to?  If you don't have the QA that a
> packager does it means you have to do it yourself.
>

It is a good thing in the sense that the cost of entry for developers
who provide Ruby extensions is very, very, low as all platforms Ruby
runs on are essentially supported out of the box by RubyGems.  If one
becomes expert at RPM package building on RHEL/CentOS then how exactly
does that expertise translate from RHEL into say Debian; or BSD; or
OSX; or MS-Windows?  It does not.  On the other hand, any non-native
language extension released as a RubyGem and pushed to rubygems.org is
instantly available on every platform running a comparable version of
Ruby.

Further, with rubygems one has version control at the extension level
with support for concurrent versions built in.  Compare that with rpm
where one has exactly one choice of a given package for the entire
host.

The problem with system packagers like rpm from a Ruby developers
standpoint is that frequently developers are packaging language
components that are extracted from a larger application and not the
application itself. This is essentially how Ruby on Rails came to be
released.  In such cases a system level application package management
system is simultaneously too large and too small for Ruby gems.  It is
too big in that it requires too much overhead to get it to work at
all.  It is too small because it only handles one Linus distribution
and does nothing at all for any non-linux OS.

One must think in terms of plugins when considering RubyGems.  Firefox
10 ESR is packaged for CentOS as an rpm but most of the addons that
make FF valuable to me are plugins obtained directly by FF from the
Mozilla repository or from trusted third parties.  These addons are
not provided as rpms from RH and never will be.  RubyGems serve much
the same purpose as FF addons and they are implemented in a similar
fashion; an extension belongs to the application and not to the
system.

As for not getting 'it' right, whatever 'it' is, Ruby is not a single
implementation.  The baseline is the MRI but there exists several
alternative implementations including one written in Java.  Each of
these serves a different user audience while providing a common
syntax.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[m . roth]

Les Mikesell wrote:
> On Tue, Feb 5, 2013 at 7:10 AM, mark  wrote:
>>> Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607)
>>> [x86_64-linux]' which is the latest stable version&  can be installed
>>> via yum.
>> 
>> Dunno if it'll work on CentOS, but thanks, Phil - this the first
>> actually useful response to *my* issue from ruby people.
>
> But still leaves the question of why a usable version isn't maintained
> for RHEL or CentOS, either in the distro or by the project.

I agree... but if Craig's the maintainer, or representative of the team
doing that, if that's their attitude - we're so great, you should forget
everything else and do it our way - seems as though that would explain it.

Jeez, the first time I was trying out Linux, back in the mid-nineties, and
I'd "only" been programming for about 15 years, mainframes, workstations
and pc's, gcc and most other languages were slackware's idea of a package.
Certainly, when I went back to Linux again, around '98 or '99, with RH 5?
5.2? any language I needed was a package (though, as I recall, COBOL,
should I have wanted it, was a bit more problematical).

Around then, and a few years later, as I've mentioned, every python
sub-release broke a previous one... but they *wanted* their language used,
and easily accessible. This attitude of "we're *so* wonderful, that either
our Brilliance Alone (tm) will force you to do it our way, or you're an
ignorant idiot

   mark, who uses scripting languages cheerfully, but for
  *real* production work prefers a real (compiled) language)

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[m . roth]

James B. Byrne wrote:
> On Mon, February 4, 2013 19:01, Les Mikesell wrote:
>> On Mon, Feb 4, 2013 at 5:36 PM, Craig White 
>> wrote:

> It is a good thing in the sense that the cost of entry for developers
> who provide Ruby extensions is very, very, low as all platforms Ruby
> runs on are essentially supported out of the box by RubyGems.  If one
> becomes expert at RPM package building on RHEL/CentOS then how exactly
> does that expertise translate from RHEL into say Debian; or BSD; or
> OSX; or MS-Windows?  It does not.  On the other hand, any non-native
> language extension released as a RubyGem and pushed to rubygems.org is
> instantly available on every platform running a comparable version of
> Ruby.

As I keep noting, many perl CPAN packages are available as rpms - I know,
since my manager prefers we not build any from CPAN unless it's a) not
available from a trusted repository as an rpm, and b) actually required by
a developer. As an rpm, of course, if there's an update, it'll get taken
care of the next update we do; otherwise, we have to remember which of our
150 or so systems has what that has to be built. It's bad enough to have
to remember which ones I have to build the NVIDIA drivers on

> released.  In such cases a system level application package management
> system is simultaneously too large and too small for Ruby gems.  It is
> too big in that it requires too much overhead to get it to work at
> all.  It is too small because it only handles one Linus distribution
> and does nothing at all for any non-linux OS.

Most other cross-platform projects do it.

> As for not getting 'it' right, whatever 'it' is, Ruby is not a single
> implementation.  The baseline is the MRI but there exists several
> alternative implementations including one written in Java.  Each of

A version of ruby, a scripting language, written in Java? Please tell me
which one, so I can prevent ANYONE HERE from EVER looking into that

   mark "why, yes, I *do* loathe java; ruby is merely an
annoying pain"

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Java app not observing ACLs

[Nikolaos Milas]

Hello,

I have inherited a Java app, available as a jar, which has been moved 
from an HPUX server as is. [This app simply downloads a data file from 
an ftp server, processes its data and creates graph files.]

It works fine on a CentOS 5 x86_64 machine with: jre-7u9-linux-x64.rpm 
but I've noticed it does not respect Linux ACLs. When run by a user who 
has access to a directory (where the app creates a file) only via ACLs 
(and not by basic user/group permissions), then I get "permission 
denied" issues.

I've googled for the problem but have not been able to find references.

Is anyone aware of such behavior and can suggest a solution?

Thanks,
Nick

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[Les Mikesell]

On Tue, Feb 5, 2013 at 8:40 AM, James B. Byrne  wrote:
>
> One must think in terms of plugins when considering RubyGems.  Firefox
> 10 ESR is packaged for CentOS as an rpm but most of the addons that
> make FF valuable to me are plugins obtained directly by FF from the
> Mozilla repository or from trusted third parties.

And have you ever had problems with FF -  caused by plugins?   Who hasn't?

> These addons are
> not provided as rpms from RH and never will be.  RubyGems serve much
> the same purpose as FF addons and they are implemented in a similar
> fashion; an extension belongs to the application and not to the
> system.

Sure, but the kernel is like that too with a bazillion modules and
drivers written by a whole bunch of people.  And there are really,
really good reasons that you don't just grab any of it straight from
the developers and let it have its way with your servers - you run
code that has been carefully vetted and all tested together..   Perl
and CPAN is similar - if you want to devote your full time to it, you
can probably keep a system running for a few years with a bunch of
libraries updating directly from CPAN, but things will break randomly
and you'll have to fix them yourself, where that rarely happens if you
use rpms that someone else keeps in sync when the CPAN module authors
refactor things.

> As for not getting 'it' right, whatever 'it' is, Ruby is not a single
> implementation.  The baseline is the MRI but there exists several
> alternative implementations including one written in Java.  Each of
> these serves a different user audience while providing a common
> syntax.

That doesn't make it sound any more reliable - which is the real
question here.   What are the odds that letting a system update itself
in combinations that have probably never been tested together and
across platforms that aren't tested in development will keep working
for any length of time.Does the gem installation process perform
any testing to verify correctness?   Is it transactional so an update
or new install failure will back out to the previously working setup?
 RPM and yum aren't perfect but the thing that makes them work is the
human management of the combinations of things that are added to a
repository and the testing for their particular platforms.   If
someone is going to give up that human layer of testing and vetting,
there should be some better assurance than "a lot of big sites make it
work" that it is actually usable.  Not everyone wants to throw a
full-time admin at making a language work.   And when even enthusiasts
say old versions are not usable it doesn't inspire confidence.

-- 
   Les Mikesell
  lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[James Szinger]

On Tue, Feb 5, 2013 at 7:55 AM,   wrote:

> As I keep noting, many perl CPAN packages are available as rpms - I know,
> since my manager prefers we not build any from CPAN unless it's a) not
> available from a trusted repository as an rpm, and b) actually required by
> a developer. As an rpm, of course, if there's an update, it'll get taken
> care of the next update we do; otherwise, we have to remember which of our
> 150 or so systems has what that has to be built.

You should check out cpanspec, available from EPEL, which makes it easy to
package CPAN modules into RPMs.  Well-behaved modules are nearly trivial
and the Fedora Packing Guideline help make sane packages out of the more
complicated modules.  Then build with mock and put the RPM into a local
repository and manage with yum.  You might need to iterate a few time to
satisfy all the dependencies, but that's a one-time deal.

The only real problem I've encountered is a program that wants to update a
core perl module and RPM rightly complains about that.  If had used cpan
directly, I would not have been warned about the conflict and might have
ended up with a broken system.

Jim
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[Karanbir Singh]

On 02/04/2013 03:21 PM, m.r...@5-cent.us wrote:
> Does anyone know of a repository that's *trustworthy* (gotta worry 'bout
> malware) with newer ruby rpm's than RHEL has?

This thread is so full of fail and FUD.

Long story short, http://people.redhat.com/bkabrda/ruby193-rhel-6/

a longer story, go readup about collections

an even longer story : I have been working on a ruby193 stack that
replaces the system ruby, and another one that goes into /opt/; time and
other issues prevent that project from getting 'there'. All forms of
help appreciated.

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

Re: [CentOS] recent ruby packages?

[Karanbir Singh]

On 02/04/2013 03:37 PM, Phil Dobbin wrote:
> I've used the Ruby Version Manager  for all things Ruby
> for a few years now & can highly recommend it.

Rvm is good for developer instances, but dont ever put rvm into a
production or testing node. Many reasons for that, the biggest and
killer 'feature' of rvm that makes it totally unsuiteable for production
is that it builds on the fly, therefore links into and delivers a ruby
stack that has random and totally unpredictable abi's and functions.

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

Re: [CentOS] recent ruby packages?

[Les Mikesell]

On Tue, Feb 5, 2013 at 10:22 AM, James Szinger  wrote:
>
>> As I keep noting, many perl CPAN packages are available as rpms - I know,
>> since my manager prefers we not build any from CPAN unless it's a) not
>> available from a trusted repository as an rpm, and b) actually required by
>> a developer. As an rpm, of course, if there's an update, it'll get taken
>> care of the next update we do; otherwise, we have to remember which of our
>> 150 or so systems has what that has to be built.
>
> You should check out cpanspec, available from EPEL, which makes it easy to
> package CPAN modules into RPMs.  Well-behaved modules are nearly trivial
> and the Fedora Packing Guideline help make sane packages out of the more
> complicated modules.  Then build with mock and put the RPM into a local
> repository and manage with yum.  You might need to iterate a few time to
> satisfy all the dependencies, but that's a one-time deal.

That keeps your rpm database happy, but it doesn't solve the real
problem which is that CPAN modules can and do change in ways that make
previously working combinations break.  It may be rare these days, but
it happens.   And the value of having centrally packaged modules is
that (a) the versions released together are generally tested together
and (b) even if some bug slips by the release process, a lot of other
people will be using the same set and can share the debugging effort
and knowledge of the fix.

> The only real problem I've encountered is a program that wants to update a
> core perl module and RPM rightly complains about that.  If had used cpan
> directly, I would not have been warned about the conflict and might have
> ended up with a broken system.

That's just one of the ways things can break, though.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[m . roth]

James Szinger wrote:
> On Tue, Feb 5, 2013 at 7:55 AM,   wrote:
>
>> As I keep noting, many perl CPAN packages are available as rpms - I
>> know, since my manager prefers we not build any from CPAN unless it's
a) not
>> available from a trusted repository as an rpm, and b) actually required
>> by a developer. As an rpm, of course, if there's an update, it'll get
taken
>> care of the next update we do; otherwise, we have to remember which of
>> our 150 or so systems has what that has to be built.
>
> You should check out cpanspec, available from EPEL, which makes it easy to
> package CPAN modules into RPMs.  Well-behaved modules are nearly trivial
> and the Fedora Packing Guideline help make sane packages out of the more
> complicated modules.  Then build with mock and put the RPM into a local
> repository and manage with yum.  You might need to iterate a few time to
> satisfy all the dependencies, but that's a one-time deal.

Why do I want to do that? I have enough systems to update, and I *try* to
do it regularly, but most have unique requirements (say, the compute
clusters, or the systems that the *one* project built in ruby uses). I'd
much rather use yum update to deal with packages that the CentOS team,
following on upstream themselves, have vetted, and have a very high
probability of *not* breaking things.

Of course I've used CPAN, and have done it on request, for very specific
software that someone wanted, with my manager's approval, because we
*don't* want to have to have a larger laundry list than we have.  I like
CPAN... but I like yum update better.

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[m . roth]

Karanbir Singh wrote:
> On 02/04/2013 03:37 PM, Phil Dobbin wrote:
>> I've used the Ruby Version Manager  for all things Ruby
>> for a few years now & can highly recommend it.
>
> Rvm is good for developer instances, but dont ever put rvm into a
> production or testing node. Many reasons for that, the biggest and
> killer 'feature' of rvm that makes it totally unsuiteable for production
> is that it builds on the fly, therefore links into and delivers a ruby
> stack that has random and totally unpredictable abi's and functions.
>
Karanbir, thank you *very* much for this info.

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[Phil Dobbin]

On 02/05/2013 04:26 PM, Karanbir Singh wrote:

> On 02/04/2013 03:37 PM, Phil Dobbin wrote:
>> I've used the Ruby Version Manager  for all things Ruby
>> for a few years now & can highly recommend it.
> 
> Rvm is good for developer instances, but dont ever put rvm into a
> production or testing node. Many reasons for that, the biggest and
> killer 'feature' of rvm that makes it totally unsuiteable for production
> is that it builds on the fly, therefore links into and delivers a ruby
> stack that has random and totally unpredictable abi's and functions.

Karanbir,

Would you mind if I passed on this information to Michal Papis who's one
of the lead developers of RVM? He's always on the lookout for feedback &
I know he has no access to a CentOS machine to test against (I sometimes
help him out in this respect).

He'd be very grateful, I'm sure.

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 5.8 & 6.3, Debian Squeeze & Wheezy, Fedora Beefy & Spherical,
Lubuntu 12.10, OS X Snow Leopard & Ubuntu Precise & Quantal
GnuPG Key : http://www.horse-latitudes.co.uk/publickey.asc


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[Karanbir Singh]

On 02/05/2013 05:38 PM, Phil Dobbin wrote:
> Would you mind if I passed on this information to Michal Papis who's one
> of the lead developers of RVM? He's always on the lookout for feedback &

absolutely.

Its not rvm thats at fault, its the build-from-source in changing
environs that breaks down any level of trust you can have in that binary
build.

ofcourse, that isnt a problem in dev environments or when one dev is
looking at testing multiple ruby versions etc.


- KB
-- 
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

Re: [CentOS] recent ruby packages?

[Phil Dobbin]

On 02/05/2013 05:49 PM, Karanbir Singh wrote:

> On 02/05/2013 05:38 PM, Phil Dobbin wrote:
>> Would you mind if I passed on this information to Michal Papis who's one
>> of the lead developers of RVM? He's always on the lookout for feedback &
> 
> absolutely.
> 
> Its not rvm thats at fault, its the build-from-source in changing
> environs that breaks down any level of trust you can have in that binary
> build.
> 
> ofcourse, that isnt a problem in dev environments or when one dev is
> looking at testing multiple ruby versions etc.

OK. That's great. I will make him aware of the misgivings concerning
production deployment.

Thanks.

Cheers,

  Phil...

-- 
currently (ab)using
CentOS 5.8 & 6.3, Debian Squeeze & Wheezy, Fedora Beefy & Spherical,
Lubuntu 12.10, OS X Snow Leopard & Ubuntu Precise & Quantal
GnuPG Key : http://www.horse-latitudes.co.uk/publickey.asc


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[m . roth]

Phil Dobbin wrote:
> On 02/05/2013 05:49 PM, Karanbir Singh wrote:
>> On 02/05/2013 05:38 PM, Phil Dobbin wrote:
>>> Would you mind if I passed on this information to Michal Papis who's
>>> one of the lead developers of RVM? He's always on the lookout for
feedback
>>> &
>>
>> absolutely.
>>
>> Its not rvm thats at fault, its the build-from-source in changing
>> environs that breaks down any level of trust you can have in that binary
>> build.
>>
>> ofcourse, that isnt a problem in dev environments or when one dev is
>> looking at testing multiple ruby versions etc.
>
> OK. That's great. I will make him aware of the misgivings concerning
> production deployment.
>
Phil, let me add this: I don't know you, or what environment you work in,
but I've worked in a lot of environments, and in a large organization that
has a really professional environment, developers *NEVER* get to touch
production. They provide the software to testing, and testing provides it
to whoever the gatekeeper is for production, usually the production
admins. They move the package(s) into the right place. In addition, the
package(s) should be 100% reproducable... and back outable at a moment's
notice, should a show-stopping problem suddenly appear.

Under no circumstances should it be "we'll have to rebuild the
environment". Building in production means that every minute it takes,
that's another minute that the organization is offline, and you can
imagine management's reaction.

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] pymol

[m . roth]

Anyone familiar with pymol?

We're getting an error I find references to from a few years ago when we
try to run remotely on a headless server. I can run it fine on my machine
(CentOS 6.3, NVidia video), and on another person's workstation remotely,
with other make video, but the server's got a Matrox - which shouldn't
matter, since I'm running this after ssh -Y. pymol yum installed fine, no
problems.

I found, and did a export LIBGL_ALWAYS_INDIRECT=1, which allowed glxgears
to work, albeit slowly and unevenly, but pymol always gives me
freeglut (pymol):  ERROR:  Internal error  in function fgOpenWindow
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  4 (X_DestroyWindow)
  Resource id in failed request:  0x0
  Serial number of failed request:  24
  Current serial number in output stream:  27
 PyMOL: abrupt program termination.

I read that this is two errors, not one, but other than the environment
variable, can't find any other fix.

Anyone?

mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] pymol

[James A. Peltier]

- Original Message -
| Anyone familiar with pymol?
| 
| We're getting an error I find references to from a few years ago when
| we
| try to run remotely on a headless server. I can run it fine on my
| machine
| (CentOS 6.3, NVidia video), and on another person's workstation
| remotely,
| with other make video, but the server's got a Matrox - which
| shouldn't
| matter, since I'm running this after ssh -Y. pymol yum installed
| fine, no
| problems.
| 
| I found, and did a export LIBGL_ALWAYS_INDIRECT=1, which allowed
| glxgears
| to work, albeit slowly and unevenly, but pymol always gives me
| freeglut (pymol):  ERROR:  Internal error  in function fgOpenWindow
| X Error of failed request:  BadWindow (invalid Window parameter)
|   Major opcode of failed request:  4 (X_DestroyWindow)
|   Resource id in failed request:  0x0
|   Serial number of failed request:  24
|   Current serial number in output stream:  27
|  PyMOL: abrupt program termination.
| 
| I read that this is two errors, not one, but other than the
| environment
| variable, can't find any other fix.
| 
| Anyone?
| 
| mark
| 

Try running it through TurboVNC  We've used it rather successfully with a boat 
load of OpenGL software such as Amira.

-- 
James A. Peltier
Manager, IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax : 778-782-3045
E-Mail  : jpelt...@sfu.ca
Website : http://www.sfu.ca/itservices
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS on IBM Z Series.

[Rafał Radecki]

Hi All.

I manage some IBM Z Series servers. But currently there are no system
tools (like OMSA tools for Dell servers) installed. Is there a
repository with tools/firmware updates for IBM servers for
Linux/RHEL/CentOS? I've googled around but with no luck. I have found
only this for power servers:
http://www-304.ibm.com/webapp/set2/sas/f/lopdiags/yum.html

Best regards,
Rafal Radecki.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] pymol

[m . roth]

James A. Peltier wrote:
> mark wrote:
> | Anyone familiar with pymol?
> |
> | We're getting an error I find references to from a few years ago when
> | we try to run remotely on a headless server. I can run it fine on my
> | machine (CentOS 6.3, NVidia video), and on another person's workstation
> | remotely, with other make video, but the server's got a Matrox - which
> | shouldn't matter, since I'm running this after ssh -Y. pymol yum
installed
> | fine, no problems.
> |
> | I found, and did a export LIBGL_ALWAYS_INDIRECT=1, which allowed
> | glxgears to work, albeit slowly and unevenly, but pymol always gives me
> | freeglut (pymol):  ERROR:  Internal error  | capabilities not found> in function fgOpenWindow
> | X Error of failed request:  BadWindow (invalid Window parameter)
> |   Major opcode of failed request:  4 (X_DestroyWindow)
> |   Resource id in failed request:  0x0
> |   Serial number of failed request:  24
> |   Current serial number in output stream:  27
> |  PyMOL: abrupt program termination.
> |
> | I read that this is two errors, not one, but other than the
> | environment variable, can't find any other fix.
>
> Try running it through TurboVNC  We've used it rather successfully with a
> boat load of OpenGL software such as Amira.

Oy - vnc on one subnet, from CentOS to CentOS? And the real annoyance is
that all involved are 6.3, and I believe all the correct libraries are
installed. I also updated glibc and xorg-x11 - there were three packages
due.

mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 2way authentication for SSH?

[Joe Pruett]

On 01/30/2013 09:44 AM, SilverTip257 wrote:
> On Wed, Jan 30, 2013 at 8:40 AM, Nux!  wrote:
>
>> On 28.01.2013 13:07, SilverTip257 wrote:
>>> Google Auth
>>> http://www.noktec.be/archives/1351
>>>
>> http://zonereseau.com/en/post/two-factor-ssh-authentication-via-google-secures-linux-logins-392
>>> http://prasys.info/2012/10/two-way-authentication-for-wordpress/
>> How can one be concerned with security AND put his login at the mercy
>> of google (or any other 3rd party)??
>>
>>
> That's a good point to question.
>
> I was in no way endorsing that one should use Google's Auth services.
> (Just that it exists and has been written about numerous times.)
>
> Personally I do not use it now and would not use it for any systems that
> need to be secure.  Which pretty much means unless I can run the auth
> daemons on a server I control, I won't be using it.
>

after seeing this thread, i looked at the google auth stuff since i had
been using that with dropbox and happy so far with it.

google is not in the auth chain at all. what they have done is take a
standard algorithm for time based keys and made an android app and pam
module that work together to allow for two factor auth. basically you
are creating a shared secret that is combined with a timestamp and that
computed value is used to confirm that the user authenticating knows
that shared secret. very similar to the rsa fobs, but all done with open
software. and yes, it is only as secure as your file storage is on the
server being connected to because each users' shared secret is stored in
their home folder. if you add the epel repo, it is available from them.
tweak your ssh config to allow challenge/response and pam to require
google auth and then each user creates their own secret. because of how
ssh works, this only happens if you don't have a keypair in place, so it
lets you fall back to password combined with the auth token.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] recent ruby packages?

[James Szinger]

On Tue, 5 Feb 2013 10:47:11 -0600
Les Mikesell  wrote:

> On Tue, Feb 5, 2013 at 10:22 AM, James Szinger 
> wrote:
> > You should check out cpanspec, available from EPEL, which makes it
> > easy to package CPAN modules into RPMs.  Well-behaved modules are
> > nearly trivial and the Fedora Packing Guideline help make sane
> > packages out of the more complicated modules.  Then build with mock
> > and put the RPM into a local repository and manage with yum.  You
> > might need to iterate a few time to satisfy all the dependencies,
> > but that's a one-time deal.
> 
> That keeps your rpm database happy, but it doesn't solve the real
> problem which is that CPAN modules can and do change in ways that make
> previously working combinations break.  It may be rare these days, but
> it happens.   And the value of having centrally packaged modules is
> that (a) the versions released together are generally tested together
> and (b) even if some bug slips by the release process, a lot of other
> people will be using the same set and can share the debugging effort
> and knowledge of the fix.

Any program or library can break---that's why we test and verify.  A
proper package management system helps, but is not a panacea.

I only do this if I can't find a package from a trusted repository.  I 
even try to rebuild the Fedora RPMs if they are available.  Once I have
an RPM, I can test it and then deploy to production.  The spec
file is record of how the package is built and mock helps protect
against hidden dependecies.  Having an RPM also allows for a broken
package to be downgraded or removed.  I have suffered enough problems
from source installs and don't want to do it that way again.

> 
> > The only real problem I've encountered is a program that wants to
> > update a core perl module and RPM rightly complains about that.  If
> > had used cpan directly, I would not have been warned about the
> > conflict and might have ended up with a broken system.
> 
> That's just one of the ways things can break, though.

It was enough to get me to drop back and punt and wait until upstream
fixes their code or I can develop a patch.

Jim
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos