Ruby for system administration

M

Martin DeMello

I was talking to a sysadmin friend, who was shopping around for a
scripting language. Naturally, I suggested ruby, and we spent a few
minutes exploring its features, but it failed his crucial requirement -
an interface to the package manager that shipped by default with the
system ruby distribution. i.e., ruby on RedHatshould come with a ruby
interface to the rpm db, etc.

It seemed like a very sensible idea to me - what do people think?

martin
 

Martin DeMello ha scritto:
I was talking to a sysadmin friend, who was shopping around for a
scripting language. Naturally, I suggested ruby, and we spent a few
minutes exploring its features, but it failed his crucial requirement -
an interface to the package manager that shipped by default with the
system ruby distribution. i.e., ruby on RedHatshould come with a ruby
interface to the rpm db, etc.

It seemed like a very sensible idea to me - what do people think?

I never had the need for this, but I think a nice binding to rpmlib
could be useful to many people.
Maybe [1] can be revived or it still works. For non rpm-based distro/OSs
The thing could be easier or harder, who knows :)

[1]http://raa.ruby-lang.org/project/ruby-rpm/
 
C

Carlos

I was talking to a sysadmin friend, who was shopping around for a
scripting language. Naturally, I suggested ruby, and we spent a few
minutes exploring its features, but it failed his crucial requirement -
an interface to the package manager that shipped by default with the
system ruby distribution. i.e., ruby on RedHatshould come with a ruby
interface to the rpm db, etc.

It seemed like a very sensible idea to me - what do people think?

There is ruby-rpm: http://www.momonga-linux.org/~muraken/ruby-rpm/

For debian, dpkg-ruby, libdpkg-ruby.
 
M

Martin DeMello

Carlos said:

Yes, but it's out of date (the header files from redhat changed between
4.0 and 4.1).
For debian, dpkg-ruby, libdpkg-ruby.

His point was that as a sysadmin he very carefully restricts himself to
stuff that comes with a stock install of the OS/distribution. I was
wondering if there were a way to work with the maintainers of Redhat,
Debian, OSX etc to make sure the appropriate tool got included with
ruby.

martin
 
D

David Ross

It is often quite hard and what I also have found with
time, silly, to even try to keep with stock from the
maintainers. Redhats, Suse, etc, ruby is seriously out
of date and they dont research each piece of thier
software to why they should upgrade, they are just
packagers. suse has ruby 1.8.1 release with thier
patches, and I am sure redhat is the same way. Are you
asking about rpm packages of ruby libraries and
programs? Try rpa-base, it might not be rpm, but its a
ruby package project designed with security in mind.
Trying to stick with the stock from the maintainers
can be quite silly for some software. --David Ross

--- Martin DeMello said:
http://www.momonga-linux.org/~muraken/ruby-rpm/

Yes, but it's out of date (the header files from
redhat changed between
4.0 and 4.1).


His point was that as a sysadmin he very carefully
restricts himself to
stuff that comes with a stock install of the
OS/distribution. I was
wondering if there were a way to work with the
maintainers of Redhat,
Debian, OSX etc to make sure the appropriate tool
got included with
ruby.

martin




__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
 
A

Ara.T.Howard

Yes, but it's out of date (the header files from redhat changed between
4.0 and 4.1).


His point was that as a sysadmin he very carefully restricts himself to
stuff that comes with a stock install of the OS/distribution. I was
wondering if there were a way to work with the maintainers of Redhat,
Debian, OSX etc to make sure the appropriate tool got included with
ruby.

this is a great idea! our sysads are the same. if ruby came with redhat in
such a capacity - it'd be a huge boost to it's popularity there.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================
 
J

James Edward Gray II

Trying to stick with the stock from the maintainers
can be quite silly for some software.

If a system administrator maintains 30+ similarly configured boxes and
decides to go with one non-standard module he gives himself 30+
installs to do immediately, 30+ versions to track, and a permanent
extra step every time a box is rebuilt or added. Naturally, this is
their job and they have the tools to help them do it (hopefully), but
it's still not a decision made lightly for obvious reasons.

However, in this case, the requirement seems a touch unreasonable to
me. I'm not familiar with any scripting language that does this,
though my experience is far from all-encompassing. Ruby's system() or
backticks could obviously call out to rpm as needed.

These modules definitely do not belong in the Standard Library, because
not a high enough percentage of users has need for them and of those
that do, needs vary. Being a Mac OS X user, all of the packages listed
earlier in this thread are useless to me, by way of example.

James Edward Gray II
 
D

David Morton

Martin said:
His point was that as a sysadmin he very carefully restricts himself to
stuff that comes with a stock install of the OS/distribution. I was

oof. I'm exactly opposite. RedHat screwed up so many packages with
their own patches that many applications failed to compile properly.
If it is a primary service of the server, I compile it by hand. That
way I know that it is installed the way the orignal authors designed it,
and when I need to ask for help, they can actually help.
 
R

Robert Nesius

If a system administrator maintains 30+ similarly configured boxes and
decides to go with one non-standard module he gives himself 30+
installs to do immediately, 30+ versions to track, and a permanent
extra step every time a box is rebuilt or added. Naturally, this is
their job and they have the tools to help them do it (hopefully), but
it's still not a decision made lightly for obvious reasons.

No sane sys admin would administrate an environment this way.
Okay.. *I* would never administrate an environment this way.
I do administrate an environment with 8000 machines and five different
Arch/OS combinations.
Even if I kept the tools local to the machine, I'd never do this by
hand. I'd automate it.

-Rob
 
R

Robert Nesius

I was talking to a sysadmin friend, who was shopping around for a
scripting language. Naturally, I suggested ruby, and we spent a few
minutes exploring its features, but it failed his crucial requirement -
an interface to the package manager that shipped by default with the
system ruby distribution. i.e., ruby on RedHatshould come with a ruby
interface to the rpm db, etc.

It seemed like a very sensible idea to me - what do people think?

martin
Now that I've read the rest of the thread and added a few comments, I'd
say if your friend is the only person responsible for his box(s) no big
deal. But if he is part of a larger team, and he is the only ruby
scripter around, he should not use ruby at all. Because after he's
gone,
it is going to be difficult for anyone to fix/change/maintain his code.
He should use whatever the group uses, and in most places that is perl.

Heretic, I know. :) The point is he works in a group and other people
will have to maintain his code after he's moved on to other groups or
duties within his group, if he's the only ruby scripter, he's causing
a problem. If he's the only ruby scripter but he's going to train
his colleagues on how to write/maintain ruby, that's ok then.


-Rob
 
L

Lennon Day-Reynolds

As a matter of fact, on recent Red Hat systems, only Python is likely
to succeed in the requirement of having a current RPM binding
available, as RH uses it for their configuration and administration
tools.

IMHO, a good systems administration language should provide a nice
high-level logic layer *on top* of the existing OS, shell, and admin
tools, not a ground-up replacement. That makes Ruby fine for my uses,
and I would imagine for most potential users out there, as well.
 
D

David Ross

I am partly the same way, except what I need to get on
each is performed by a script on each machine that
fetches instructions from my remote server. --David

--- David Morton said:
OS/distribution. I was

oof. I'm exactly opposite. RedHat screwed up so
many packages with
their own patches that many applications failed to
compile properly.
If it is a primary service of the server, I compile
it by hand. That
way I know that it is installed the way the orignal
authors designed it,
and when I need to ask for help, they can actually
help.





__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
 
D

David Ross

--- Robert Nesius said:
Now that I've read the rest of the thread and added
a few comments, I'd
say if your friend is the only person responsible
for his box(s) no big
deal. But if he is part of a larger team, and he is
the only ruby
scripter around, he should not use ruby at all.
Because after he's
gone,
it is going to be difficult for anyone to
fix/change/maintain his code.
He should use whatever the group uses, and in most
places that is perl.

Yes that is true, but think about how those languages
started to get popular in the first place. People used
them even if the rest of the team didn't so they have
to get another person who does know ruby, learn ruby
themselves, or convert the ruby code. I think that its
a good thing to be different with choosing the
language to code in whether it be scripting or
programming.
Heretic, I know. :) The point is he works in a
group and other people
will have to maintain his code after he's moved on
to other groups or
duties within his group, if he's the only ruby
scripter, he's causing
a problem. If he's the only ruby scripter but he's
going to train
his colleagues on how to write/maintain ruby, that's
ok then.

Let hope he can teach them and use a bit of material
called books. :)


--David Ross



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
 
A

Ara.T.Howard

Now that I've read the rest of the thread and added a few comments, I'd say
if your friend is the only person responsible for his box(s) no big deal.
But if he is part of a larger team, and he is the only ruby scripter around,
he should not use ruby at all. Because after he's gone, it is going to be
difficult for anyone to fix/change/maintain his code. He should use
whatever the group uses, and in most places that is perl.

i wrote a very large database system for tracking meteorlogical metadata. it
was in alpha when i left for another job, there were no docs. a friend (perl
guru) of mine took over the project. he used to ping me with comments like
"there are no docs - so how can do XXX?". i would say - "read the source".
eventually he did and then sent me this:

Hi Ara,

After looking through pds.rb to learn about how to install a changed
format, I just wanted to say this is some pretty nice programming on
your part. It looks like it's written to make sense rather than to
impress. Coding, like music, is so much nicer without excessive use
of heavy metal licks.

Hey, what does the ``<< self'' syntax mean here?

module PDS

class << self
# assumes $pgconn is connected to correct db
def pgconn
raise 'NO CONNECTION FOUND ($pgconn)!' unless $pgconn
$pgconn
end
end
....


Thanks,
R

now, this was pretty straightforward ruby so the compliment is truely aimed at
ruby, not me. the point being, after a few lessons in things like 'what does
class << self mean' he did fine. and that's all without docs. in summary i
think that 90% of the ruby code out there is more readable than perl code -
even to perl coders! consider how you would feel if someone made the same
argument you are making when perl was the new alternative to doing everything
in sh!
Heretic, I know. :) The point is he works in a group and other people will
have to maintain his code after he's moved on to other groups or duties
within his group, if he's the only ruby scripter, he's causing a problem.
If he's the only ruby scripter but he's going to train his colleagues on how
to write/maintain ruby, that's ok then.

yeah - we are in agreement here then and that is the path i have taken. i
will say that any __decent__ perl programmer (understands closures,
references, OO perl, interface polymorphism, etc.) should be able to pick up
ruby in under 24 hours or one complete program - whichever comes first.

kind regards.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================
 
I

Ian Macdonald

Now that I've read the rest of the thread and added a few comments, I'd
say if your friend is the only person responsible for his box(s) no big
deal. But if he is part of a larger team, and he is the only ruby
scripter around, he should not use ruby at all. Because after he's
gone,
it is going to be difficult for anyone to fix/change/maintain his code.
He should use whatever the group uses, and in most places that is perl.

Heretic, I know. :) The point is he works in a group and other people
will have to maintain his code after he's moved on to other groups or
duties within his group, if he's the only ruby scripter, he's causing
a problem. If he's the only ruby scripter but he's going to train
his colleagues on how to write/maintain ruby, that's ok then.

I went through exactly the same problem at my place of work.

I was the first sysadmin to 'discover' Ruby at the end of 2001 and I was
working in an environment that was largely Perl-based. I, myself, was a
Perl programmer through and through at the time, but I was immediately
enchanted by Ruby's graceful style, flexibility and ease of use.

Unfortunately, all revolutions necessarily start with a single act of
rebellion, so I started to use Ruby for small projects that no-one else
was ever likely to touch. I used Ruby solely for systems and projects in
the corporate environment, knowing that I would be quickly shot down if
I tried to put any Ruby code on the production site.

At this time, I was very vulnerable, because I was the only Ruby coder
and I no argument I could have come up with would have countered the
very strong argument that a single sysadmin coding in a language no-one
else knows is a big liability.

At the same time, however, I realised that the alternative was for the
whole department to keep adding to an already crufty Perl code base and
that Perl's star seemed to be on the wane. I did not want the company to
get stuck with a mammoth legacy code base years from now.

So, I trusted my experience, which was telling me that this was
something we needed to do, and I kept coding in Ruby, making gentle
efforts from time to time to introduce the other sysadmins in the
department to it.

To cut a long story short, we're nearly three years down the road since
then and Ruby is now used by a good six or seven sysadmins in the
department. It hasn't replaced Perl, but it has shown itself to be a
worthy alternative and, in some cases, clearly superior for the task at
hand. In such cases, we have even had management encouragement to use
it.

The success hasn't been without pain, though. Once the number of
sysadmins using Ruby had risen to about three, we became visible and
management came down on us very hard. It has been an uphill battle to
reach the uneasy acceptance we have now. The departmental managers are
now fully behind us, however, leaving only upper Engineering management
unconvinced.

I used to put quite a lot of effort into putting Ruby under the nose of
the new sysadmins, but I no longer have to do that. There are enough
other sysadmins now wildly enthusiastic about the language that the
impetus at my company seems to have reached the critical threshold at
which it no longer needs to be nurtured. It now fuels itself and Ruby is
growing organically within the department without any input from me.

This is particularly nice for me, as I no longer need to feel that I'm
engaging in subversive activity when I introduce new employees to Ruby.
Nor do I have the burden of knowing that the language will forever have
marginal status if I don't make the effort to promote it.

In conclusion, the hardest part is going out on a limb and using Ruby
when there's little or no justification for doing so and you are the
only one doing it. Then follows a phase of vulnerability, when the group
of Ruby users is too small to be justifiable, but too large to remain
invisible to management. It's a very unpleasant feeling to be part of a
coding underground.

The only thing that gave me the will to indulge in all of the heated
internal debate and continue to fly in the face of management was the
belief that I was doing the right thing and that Ruby would, within a
few years, become a force to be reckoned with in the field of system
administration. We're not there yet, but the signs are definitely
visible.

It helps to be in good standing with management, too, I must say. If you
believe you were hired because you're an expert in your field and
people believe you make smart decisions, based on experience and good
judgement, then you have a good basis on which to build.

Ian
--
Ian Macdonald | Microbiology Lab: Staph Only!
System Administrator |
(e-mail address removed) |
http://www.caliban.org |
|
 
D

Daniel Berger

<big snip>

One of the reasons I created the ruby-sysutils project
(http://ruby-sysutils.sf.net) was for system administration related
stuff done in Ruby.

If there's anyone interested in joining the project, or who has
packages/features they would like to see added, please let me know, or
put in a feature request on the page. :)

Regards,

Dan
 
V

vruz

If there's anyone interested in joining the project, or who has
packages/features they would like to see added, please let me know, or
put in a feature request on the page. :)

Thanks Ian, it's good to have all these utils at hand.

Just a minor correction, Mike Hall's homepage is now at:
http://users.rcn.com/m3ha11/

(your sys-utils project page points to an old, no longer available
homepage of Mike)

cheers,
 
K

Keith P Hodges

Being subversive tip - dont forget to change the name of your
executable to perl.

I used to find my subversive activities were quite processor
intensive and would attract attention at the top of `top`, especially
when the name of my executable was "squeak".

Easily solved - change the name of your executable to perl and no one
bats an eyelid if it hogs the cpu :)

Keith
 
P

Phil Tomson

Being subversive tip - dont forget to change the name of your
executable to perl.

I used to find my subversive activities were quite processor
intensive and would attract attention at the top of `top`, especially
when the name of my executable was "squeak".

Easily solved - change the name of your executable to perl and no one
bats an eyelid if it hogs the cpu :)

I suspect that this is a tongue-in-cheek suggestion since renaming the
ruby executable to perl would break some things that might actually need perl.

But I wonder... Is there a way to 'spoof' what shows up in top (without
renaming the exectuable)?

sort of like sudo, but something like:
runas perl ruby foo.rb ?

runas <name of program you want to show in process table> command

....not that I'm trying to promote subversiveness; just curious.


Phil
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,051
Latest member
CarleyMcCr

Latest Threads

Top