Ruby for system administration

Discussion in 'Ruby' started by Martin DeMello, Aug 31, 2004.

  1. 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, Aug 31, 2004
    #1
    1. Advertising

  2. 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/
     
    @(remove)yahoo.it, Aug 31, 2004
    #2
    1. Advertising

  3. Martin DeMello

    Carlos Guest

    [Martin DeMello <>, 2004-08-31 11.40 CEST]
    > 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.
     
    Carlos, Aug 31, 2004
    #3
  4. Carlos <> wrote:
    >
    > There is ruby-rpm: 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).

    > 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
     
    Martin DeMello, Aug 31, 2004
    #4
  5. Martin DeMello

    David Ross Guest

    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 <> wrote:

    > Carlos <> wrote:
    > >
    > > There is ruby-rpm:

    > 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).
    >
    > > 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
    >
    >





    __________________________________
    Do you Yahoo!?
    Read only the mail you want - Yahoo! Mail SpamGuard.
    http://promotions.yahoo.com/new_mail
     
    David Ross, Aug 31, 2004
    #5
  6. Martin DeMello

    Guest

    On Tue, 31 Aug 2004, Martin DeMello wrote:

    > Carlos <> wrote:
    >>
    >> There is ruby-rpm: 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).
    >
    >> 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.


    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
    ===============================================================================
     
    , Aug 31, 2004
    #6
  7. On Aug 31, 2004, at 7:43 AM, David Ross wrote:

    > 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
     
    James Edward Gray II, Aug 31, 2004
    #7
  8. Martin DeMello

    David Morton Guest

    Martin DeMello wrote:
    > 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.
     
    David Morton, Aug 31, 2004
    #8
  9. On Aug 31, 2004, at 6:53 AM, James Edward Gray II wrote:

    > On Aug 31, 2004, at 7:43 AM, David Ross wrote:
    >
    >> 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.
    >


    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
     
    Robert Nesius, Aug 31, 2004
    #9
  10. On Aug 31, 2004, at 2:40 AM, Martin DeMello wrote:

    > 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
     
    Robert Nesius, Aug 31, 2004
    #10
  11. On Aug 31, 2004, at 10:57 AM, Robert Nesius wrote:

    > He should use whatever the group uses, and in most places that is perl.


    I don't believe Perl passes his test either.

    James Edward Gray II
     
    James Edward Gray II, Aug 31, 2004
    #11
  12. 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.

    --
    Lennon
    rcoder.net
     
    Lennon Day-Reynolds, Aug 31, 2004
    #12
  13. Martin DeMello

    David Ross Guest

    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 <> wrote:

    > Martin DeMello wrote:
    > > 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.
    >
    >






    __________________________________
    Do you Yahoo!?
    New and Improved Yahoo! Mail - 100MB free storage!
    http://promotions.yahoo.com/new_mail
     
    David Ross, Aug 31, 2004
    #13
  14. Martin DeMello

    David Ross Guest

    --- Robert Nesius <> wrote:

    > 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. :)


    >
    > -Rob
    >
    >
    >


    --David Ross



    __________________________________
    Do you Yahoo!?
    New and Improved Yahoo! Mail - Send 10MB messages!
    http://promotions.yahoo.com/new_mail
     
    David Ross, Aug 31, 2004
    #14
  15. Martin DeMello

    Guest

    On Wed, 1 Sep 2004, Robert Nesius wrote:

    > 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
    ===============================================================================
     
    , Aug 31, 2004
    #15
  16. On Wed 01 Sep 2004 at 00:57:35 +0900, Robert Nesius wrote:

    > 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 |
    |
    http://www.caliban.org |
    |
     
    Ian Macdonald, Sep 8, 2004
    #16
  17. ruby-sysutils (was Ruby for system administration)

    Ian Macdonald <> wrote in message news:<>...
    > On Wed 01 Sep 2004 at 00:57:35 +0900, Robert Nesius wrote:

    <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
     
    Daniel Berger, Sep 9, 2004
    #17
  18. Martin DeMello

    vruz Guest

    Re: ruby-sysutils (was Ruby for system administration)

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

    --
    --- vruz
     
    vruz, Sep 9, 2004
    #18
  19. 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
     
    Keith P Hodges, Sep 9, 2004
    #19
  20. Martin DeMello

    Phil Tomson Guest

    In article <a0611044ebd6643589e7b@[192.168.0.100]>,
    Keith P Hodges <> wrote:
    >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
     
    Phil Tomson, Sep 9, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Benjamin

    Tkinter for system administration?

    Dave Benjamin, Nov 6, 2004, in forum: Python
    Replies:
    4
    Views:
    305
    Stephen Ferg
    Nov 9, 2004
  2. Ross Culver
    Replies:
    1
    Views:
    1,121
    Ross Culver
    Aug 21, 2007
  3. Krishna Kirti Das
    Replies:
    3
    Views:
    454
    Martin v. Löwis
    Feb 26, 2008
  4. Steve Holden
    Replies:
    2
    Views:
    1,014
    Mike Driscoll
    Oct 7, 2008
  5. Tassilo Horn

    Ruby for system administration

    Tassilo Horn, Apr 4, 2006, in forum: Ruby
    Replies:
    4
    Views:
    143
    Florian Frank
    Apr 5, 2006
Loading...

Share This Page