MANEJO DE LIBRERA SOLARIS 11

Managing Library Paths with crle

By Sandra Henry-Stocker, ITworld.com | Hardware
Add a comment
April 13, 2005, 8:53 AM Definitely NOT one of the first dozen Unix commands that
a person learns, the crle command is so infrequently discussed in the hallways of
software development companies that even I don't know how to pronounce it. Is it "see
are elle ee" (phonetically "si ar el i") or am I supposed to say "curly"? After all, Unix
offers few clues in such matters. We have the likes of vi ("vee eye" and awk (which
rhymes with "talk") as two of many examples illustrating that there is no general
pronunciation rule that governs our favorite OS. But, fortunately, since I don't have to
read this column to you, let's move on to the more important issue -- what does this
command do and how can you use it in managing your systems?
To begin with, crle stands for "configure runtime linking environment". It is a command
that allows Solaris sysadmins to better manage their dynamic linker. Specifically, it
allows you to configure library paths so that programs run on a system will have as
easy access to shared library files in locations like /usr/local/lib or /opt/lib as they do to
/usr/lib. Instead of configuring a LD_LIBRARY_PATH to give these lib directories
visibility, you run the crle command and augment the load library path on a system-
wide basis. In other words, the crle command is basically the equivalent of updating
ld.config.
What's Configured Now?
To view the system library path on a Solaris system, you can issue the crle command
on a line by itself:
# crle

Default configuration file (/var/ld/ld.config) not found
Default Library Path (ELF): /usr/lib (system default)
Trusted Directories (ELF): /usr/lib/secure (system default)
Notice that, in the absence of an ld.config file, a limited library search path is
established containing only /usr/lib for normal usage.
This library path setting is independent of any paths you may have added to your
LD_LIBRARY_PATH interactively or through settings in your dot files. The paths
shown are the paths that binaries on your system will use regardless of the
LD_LIBRARY_PATH setting.
How to Configure New Paths
To add a new path to your dynamic linker, you would use the crle -l command, but this
command overwrites the existing path. In other words, you need to repeat the existing
path elements so as not to remove them. For example, you might type the following
command to add /usr/local/lib to what is shown above:
# crle -l /usr/lib:/usr/local/lib
Afterwards, you should verify the new settings:
# crle

Configuration file [2]: /var/ld/ld.config
Default Library Path (ELF): /usr/lib:/usr/local/lib
Trusted Directories (ELF): /usr/lib/secure (system default)

Command line:
crle -c /var/ld/ld.config -l /usr/lib:/usr/local/lib
What should you do if You Break It?
If you type your crle command carefully, you should have an easy time augmenting
your dynamic loader's search path. If, on the other hand, you break the path -- for
example, by typing crle -l followed only by the paths you intend to add -- you can send
your Solaris system into a very troublesome state. The reason is simple; just about
every command that you type on your Unix system depends on shared object files
stored in /usr/lib -- including commands as benign as ls. So, if /usr/lib disappears from
your linker's search path, your ability to work wonders on the command line will come
to an abrupt end -- at least until you type the command again. The breakage will be
illustrated with errors such as this:
$ ls
ld.so.1: ls: fatal: libc.so.1: open failed: No such file or directory
Killed
Normal Unix command functionality can be restored by typing a second crle command.
While you could also fix the problem for yourself by setting your LD_LIBRARY_PATH
as shown below, this wouldn't help anyone else who logs into the system.
LD_LIBRARY_PATH=/lib:/usr/lib;export LD_LIBRARY_PATH
Typing the crle command with the complete library path should fix the problem
immediately and easily -- except when you can't issue it.
What should you do if You Break It with sudo?
A second crle won't help you out of the pit that you inadvertently created if your super
powers are bequeathed through sudo. In this case, you won't be able to reproduce the
linker's path with a "sudo crle" command because sudo itself depends on /usr/lib.
$ sudo crle -l /lib:/usr/lib:/usr/local/lib
ld.so.1: sudo: fatal: libdl.so.1: open failed: No such file or directory
Killed
In fact, remote access to the box will also fail because telnet, ftp and ssh will try to
access shared libraries which are no longer in the path.
$ telnet boson
Trying 10.11.11.51...
Connected to boson.particles.org.
Escape character is '^]'.
ld.so.1: in.telnetd: fatal: libdl.so.1: open failed: No such file or
directory
Connection closed by foreign host.
And, while you can restore the functionality of many commands by setting your
LD_LIBRARY_PATH, this won't restore remote access -- and it won't restore your
sudo privileges because sudo, for fairly obvious security reasons, doesn't pay attention
to this environment variable.
While you can appeal to a higher authority (the guy who can exercise superuser
privilege without using sudo), there's also a workaround that you can use to regain
your superuser access without having to wait for someone with the root password to
come to your rescue.
The crle command had existed in Solaris since Solaris 7, but it most familiar to
systems administrators who need to augment library paths when installing applications
that install libraries in non-system locations such as /usr/local/lib or /opt/lib. Since it
established system-wide library paths, it is recommended over LD_LIBRARY_PATH
settings.

Para que arranque de Nuevo apache
crle -l /usr/lib:/usr/local/lib:/opt/mysql/mysql/lib/ (se realiza esto para que cargue las librerias de
mysql y pueda arrancar apache)
crle l /usr/lib:/usr/local/lib esto se realiza para que al reiniciar el servidor cargue las libreras de
inicia y salir del modo de mantenimiento