accidently deleted /usr/local/lib - Unix

This is a discussion on accidently deleted /usr/local/lib - Unix ; Hi, Today i have accidently deleted /usr/local/lib directory in one of the production box. It was a mistake. Actually I wanted to delete /usr/ local/lib/perl5 folder using rm -r command, i did that, just to cross check, i ran command ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: accidently deleted /usr/local/lib

  1. accidently deleted /usr/local/lib

    Hi,

    Today i have accidently deleted /usr/local/lib directory in one of the
    production box. It was a mistake. Actually I wanted to delete /usr/
    local/lib/perl5 folder using rm -r command, i did that, just to cross
    check, i ran command rm -r /usr/local/lib by just deleting trailing
    perl5, thinking im running ls -l command.

    The installed linux is suse9, on production box.
    Could someone please tell me,
    - How does this will effect?
    - Is there any way i can restore those files?
    - Is there a way i can copy required files to folder from somewhere?
    When i saw last /usr/local/lib there were following files
    libgmp.a
    libgmp.la
    libgmp.so
    libgmp.so.3
    libgmp.so.3.4.1
    libpari.so
    libpari.so.2
    libpari.so.2.3.2

    and folder,
    pari

    I really dont know how important these files and folders are, could
    someone help me here please.


    Thanks in advance,
    katharnakh.

  2. Re: accidently deleted /usr/local/lib

    On Tue, 16 Sep 2008 09:01:04 -0700, kath wrote:

    > Hi,
    >
    > Today i have accidently deleted /usr/local/lib directory in one of the
    > production box. It was a mistake. Actually I wanted to delete /usr/
    > local/lib/perl5 folder using rm -r command, i did that, just to cross
    > check, i ran command rm -r /usr/local/lib by just deleting trailing
    > perl5, thinking im running ls -l command.


    I hate when that happens. I did a "rm -rf / somefolder" once. It is
    amazing how important a space is.

    >
    > The installed linux is suse9, on production box. Could someone please
    > tell me,
    > - How does this will effect?


    GMP is a free library for arbitrary precision arithmetic, operating on
    signed integers, rational numbers, and floating point numbers.

    PARI/GP is a widely used computer algebra system designed for fast
    computations in number theory (factorizations, algebraic number theory,
    elliptic curves...)

    The importance of these files depends on what your production box is used
    for.

    > - Is there any way i can restore those files?
    >- Is there a way i can
    > copy required files to folder from somewhere?
    > When i saw last /usr/local/lib there were following files libgmp.a
    > libgmp.la
    > libgmp.so
    > libgmp.so.3
    > libgmp.so.3.4.1
    > libpari.so
    > libpari.so.2
    > libpari.so.2.3.2
    >
    > and folder,
    > pari
    >
    > I really dont know how important these files and folders are, could
    > someone help me here please.
    >

    Well, I can google the file names for you and try to answer, but I
    don't have suse9. And I have no experience with these packages.

    >
    > Thanks in advance,
    > katharnakh.


    Do you have another box with the same setup, if so just copy the
    directory.
    If not then you can probably re-install the packages pari/gp and gmp.
    You may be able to install them with your package manager. Or go to the
    source.

    http://gmplib.org/
    http://pari.math.u-bordeaux.fr/

    stonerfish

  3. Re: accidently deleted /usr/local/lib

    On Tue, 16 Sep 2008 16:50:30 GMT,
    jellybean stonerfish wrote:
    > On Tue, 16 Sep 2008 09:01:04 -0700, kath wrote:
    >> I really dont know how important these files and folders are, could
    >> someone help me here please.
    >>

    > Well, I can google the file names for you and try to answer, but I
    > don't have suse9. And I have no experience with these packages.


    I was under the impression that most if not all linux distributions[1]
    dump everything in /usr, not /usr/local, so it may be someone's
    hand-installed work that got nuked. The OP unfortunately gives no
    information regarding that possibility.

    It will be worth digging into suse's package system; make it list
    the full paths to all files it thinks it has installed and see if
    any are in /usr/local/lib. Then de/reinstall those packages.


    > Do you have another box with the same setup, if so just copy the
    > directory.


    Or restore from backups.


    [1] Other systems, like FreeBSD, put all packages in /usr/local by default,
    reserving /usr for ``the base system''.

    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  4. Placement of local customizations (was: Re: accidently deleted/usr/local/lib

    On Sep 16, 10:14 am, jpd wrote:
    > [...]
    > Other systems, like FreeBSD, put all packages in /usr/local by default,
    > reserving /usr for ``the base system''.


    Conceptually, that philosophy makes so much sense I wonder why it's
    not more widely used (recognizing that Sun, beginning with Solaris,
    uses /opt for just such "localizations", and under SunOS 3 and 4 did
    use and/or recommend /usr/local given its (then) BSD heritage).

    With everything other than the "base" system under /usr/local it's
    easy to identify, backup/restore, and duplicate/copy to additional
    and new systems that which define's a system's uniqueness; I have
    yet to find any package manager that facilitates those tasks.


  5. Re: accidently deleted /usr/local/lib

    Hi,

    On Sep 16, 10:14 pm, jpd wrote:
    > On Tue, 16 Sep 2008 16:50:30 GMT,
    > jellybean stonerfish wrote:
    > > On Tue, 16 Sep 2008 09:01:04 -0700, kath wrote:
    > >> I really dont know how important these files and folders are, could
    > >> someone help me here please.

    >
    > > Well, I can google the file names for you and try to answer, but I
    > > don't have suse9. And I have no experience with these packages.

    >
    > I was under the impression that most if not all linux distributions[1]
    > dump everything in /usr, not /usr/local, so it may be someone's
    > hand-installed work that got nuked. The OP unfortunately gives no
    > information regarding that possibility.


    May be you are right because, as stonefish was saying i checked in
    other box having suse9, but /usr/lib/local to restore same files from
    that box, but it was empty. Also one of my other colleague told he was
    installing some perl packages(for eg. Net::SSH) which resulted those
    files. Because those packages uses encryption/decryption algorithms to
    send a data, may be those files are required of the perl packages, its
    just a guess.

    > It will be worth digging into suse's package system; make it list
    > the full paths to all files it thinks it has installed and see if
    > any are in /usr/local/lib. Then de/reinstall those packages.

    Will try.

    > > Do you have another box with the same setup, if so just copy the
    > > directory.

    >
    > Or restore from backups.


    Thanks stonefish, Thanks jpd for your kind reply.

    katharnakh.


  6. Re: Placement of local customizations (was: Re: accidently deleted /usr/local/lib

    On Tue, 16 Sep 2008 16:36:49 -0700 (PDT),
    Thad Floryan wrote:
    > On Sep 16, 10:14 am, jpd wrote:
    >> [...]
    >> Other systems, like FreeBSD, put all packages in /usr/local by default,
    >> reserving /usr for ``the base system''.

    >
    > Conceptually, that philosophy makes so much sense I wonder why it's
    > not more widely used (recognizing that Sun, beginning with Solaris,
    > uses /opt for just such "localizations", and under SunOS 3 and 4 did
    > use and/or recommend /usr/local given its (then) BSD heritage).


    Actually, it's flawed in the sense that the ``local'' isn't local any
    more. For that reason, NetBSD uses /usr/pkgsrc for the same thing,
    reserving /usr/local for hand installed things.

    /usr/opt, /opt, and so on, would of course work too.


    > With everything other than the "base" system under /usr/local it's
    > easy to identify, backup/restore, and duplicate/copy to additional
    > and new systems that which define's a system's uniqueness; I have
    > yet to find any package manager that facilitates those tasks.


    Well, package managers have to know what they're packaging, so you'd at
    least have to tell them that. FreeBSD's pkg_create -b (and presumably
    the other *BSD's too) will create a package based on what's installed in
    the system, but to work it requires that the package was installed once
    (though possibly from ports, not a package tarball). It isn't especially
    difficult to create new packages using the ports tree, though.

    To answer your earlier question, on linux systems there generally[1]
    is no concept of a base system; it's ``kernel'', and ``packages'',
    without middle ground. This is more flexible, in theory, but more than
    one distribution has problems installing too many packages because
    everything interdepends on everything else.

    Also note that it would perhaps be simpler to split off /usr/local,
    /usr/opt, /opt, or what-have-you, into an indepentent filesystem, and
    dump/restore that as a whole. That still doesn't solve the entire
    problem:

    - if the binaries in there depend on shared libraries installed as
    packages you'd need to add a list of exactly what versions of what
    packages are installed
    - part of a system's uniqueness is in its configuration files, and
    restoring from base system and/or packages misses that entirely;
    dump/restore of /usr/local (or ...) misses configuration files
    stored elsewhere (/etc, for one)

    It's perhaps good to observe here that packages solve a different
    problem than storing a system's uniqueness.

    Packages are quite useful to store binaries and default configurations,
    but storing individual configurations is quite a different thing. Some
    approaches use a SCM for that (RCS, CVS, etc.[2]), others encourage you
    to write changesets for each given ``thing'' and stores and applies
    those (eg. cfengine, and arusha/ark which also uses cfengine).

    The problem with configurations is that they see minute changes quite
    often and coming up with entire packages to apply them is perhaps a
    bit much involved. Thus a SCM is a better approach, but setting up
    that is itself a bit involved again, and doesn't lend itself well to
    quick packing up and rolling out again -- it requires an existing SCM
    infrastructure.

    I think coming up with something that works well on an individual system
    then scales well to large installations is an open research problem,
    even with solaris' attempts to stuff all configuration into xml, and
    previous attmepts like next's netinfo (both of which solve a different
    problem again, but perhaps could be leveraged to make this easier too).


    [1] I know of no distribution that implements it, but that doesn't mean
    it is impossible. linux distributions just don't do it that way.
    [2] Note that RCS is actually better suited for tracking individual files
    than CVS, and that more recent SCM approaches often concentrate
    even more on file sets and might lack single file tracking entirely.

    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  7. Re: accidently deleted /usr/local/lib

    On Tue, 16 Sep 2008 20:35:47 -0700, kath wrote:

    > Thanks stonefish, Thanks jpd for your kind reply.
    >
    > katharnakh.


    Something else to think of....

    Those are library files. If they were placed there by hand, (compiled
    from source, not installed with a package manager) there is a possibility
    that there is other software that was also installed by hand, that was
    linked to those libraries when it was compiled. So you may have files in
    someplace like /usr/local/bin that will not work, even if you replace
    the /usr/local/lib files. You may have to recompile something that
    depends on those files.

    In other words, may have to redo your perl Net::SSH stuff.

    stonerfish

  8. Re: Placement of local customizations (was: Re: accidently deleted/usr/local/lib

    On Sep 16, 9:10 pm, jpd wrote:
    > [...]
    > Also note that it would perhaps be simpler to split off /usr/local,
    > /usr/opt, /opt, or what-have-you, into an indepentent filesystem, and
    > dump/restore that as a whole. That still doesn't solve the entire
    > problem:
    >
    > - if the binaries in there depend on shared libraries installed as
    > packages you'd need to add a list of exactly what versions of what
    > packages are installed
    > - part of a system's uniqueness is in its configuration files, and
    > restoring from base system and/or packages misses that entirely;
    > dump/restore of /usr/local (or ...) misses configuration files
    > stored elsewhere (/etc, for one)


    Which would imply that ideally everything needed for some unique app
    would/should be located relative to that app thus being "together"
    especially if, say, a specific-version library is required.

    I note that some apps have their own bin, etc, lib, etc. directories
    and that everything I've recently loaded on my Solaris 10 box is found
    in /opt/sfw/bin, /opt/sfw/etc, /opt/sfw/lib, etc. differentiating them
    from the system's /bin, /etc, /lib, etc.

    I've had a /usr/local/bin, /usr/local/etc, /usr/local/lib, etc. on all
    my systems for 20+ years and that has served me well developing
    software.
    When I get a new system I know exactly where to retrieve what I need
    from the older systems (followed by a recompile :-) regardless of the
    platform or specific OS -- software portability is important to me.

    A tip that might prove useful to others is that whenever I change any
    "true" system file I always backup the original file first per:

    # cp -p sysfile sysfile-ORIG

    A simple "find / -name \*-ORIG -print" quickly locates what I may
    have messed up -- stuff happens. :-)

    Colleagues who don't do that (or something similar such as maintain a
    CHANGELOG and keep a hardcopy in case the disk goes belly-up) always
    regret their inattention/laziness months later when some event forces
    a
    system reboot and the system doesn't reboot and they forgot what they
    changed. Sadly, they seldom learn from that and continue
    lackadaisical
    system modifications -- I see that everywhere, and downtime is
    expensive.

    I appreciate reading your thoughts in this regards; you've brought up
    some interesting and valid points.

    Thank you for sharing!

  9. Re: Placement of local customizations (was: Re: accidently deleted /usr/local/lib

    On Tue, 16 Sep 2008 22:28:48 -0700 (PDT),
    Thad Floryan wrote:
    [snip!]
    > Which would imply that ideally everything needed for some unique app
    > would/should be located relative to that app thus being "together"
    > especially if, say, a specific-version library is required.


    Not necessairily, though recording the relationship somewhere is good.
    But that alone doesn't cover everything.

    Apple takes that approach in an effort to allow applications to be
    ``dragged over'' entirely. One icon, one application. The downside of
    that is a lot of duplicated code. This is easy to see if you consider
    that it amounts to linking everything statically if that isn't what they
    actually do. It _does_ fit their paradigm nicely, though.

    The other extreme is the hell that is the jungle of interdependencies
    between libraries and programs of all sizes. Feed the dependency graph
    of, say, gnucash through graphviz's dot. That _is not_ fun to try and
    install, nevermind update, patch, and so on, but I digress.

    The thing is, package systems work pretty well to distribute binaries and
    keep records of what files belong to each other. But after changing the
    configuration, you can't just stuff all that back into the package and
    say that's the original. So if we're not going to integrate that into the
    package system itself, another system to keep track of the differences
    between stock, then pack those up for distribution, might be in order.


    > I note that some apps have their own bin, etc, lib, etc. directories
    > and that everything I've recently loaded on my Solaris 10 box is found
    > in /opt/sfw/bin, /opt/sfw/etc, /opt/sfw/lib, etc. differentiating them
    > from the system's /bin, /etc, /lib, etc.


    There is at least one packaging system (the name eludes me for the
    moment) that puts everything under /prefix/packagename/{bin,etc,lib,...}
    then maintains a soft link farm of all the files it installed into
    /prefix/{bin,etc,lib,...} (where prefix is /usr/local or what-have-you)
    to have both PATH not explode and keep things in one package together
    in the installed state also.


    [snip]
    > When I get a new system I know exactly where to retrieve what I need
    > from the older systems (followed by a recompile :-) regardless of the
    > platform or specific OS -- software portability is important to me.


    It's still a manual process and may not be (probably is not) suitable
    for large scale deployments like sysadmins tend to need to do.


    > A tip that might prove useful to others is that whenever I change any
    > "true" system file I always backup the original file first per:
    >
    > # cp -p sysfile sysfile-ORIG
    >
    > A simple "find / -name \*-ORIG -print" quickly locates what I may
    > have messed up -- stuff happens. :-)


    In a multi-admin environment that, or even keeping a CHANGELOG, quickly
    gets convoluted, so it isn't a bad idea at all to use a SCM and run the
    tool to tell you who last checked in something (and if it isn't checked
    in, overwrite it with the previous config -- the perp should've checked
    his stuff in, dammit). But that doesn't really pack up things neatly for
    automated rollout of new services/machines/etc. but does require the
    constant availability of a config management service.


    [more snip]
    > I appreciate reading your thoughts in this regards; you've brought up
    > some interesting and valid points.
    >
    > Thank you for sharing!


    Sure. :-)


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

+ Reply to Thread