Just another WordPress weblog

If you have your own shared libraries with the whole set of your favorite functions, probably you will have seen this common error:

./myapp: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or direct

Let’s take a look inside the binary:

tuxedo@host:$> ldd test
        linux-gate.so.1 =>  (0xb7ef6000)
        libatest.so => not found
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d81000)

By default the system is looking for in the paths defined in the /etc/ld.so.conf, which recursively adds the definitions in the folder /etc/ld.so.conf.d
Here’s the quick trick:

tuxedo@host:$> export LD_LIBRARY_PATH=`pwd`

I use this whereas I’m implementing my library, after that you can put it wherever you feel like.

tuxedo@host:$> ldd test
linux-gate.so.1 =>  (0xb7f5e000)
        libtest.so => /home/tuxedo/syslib/libtest.so (0xb7f56000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7de3000)
        /lib/ld-linux.so.2 (0xb7f5f000)

Now the executable will work. I’ll retake this issue, I have some interesting things to tell about shared libraries. Happy coding!!

Long time ago if you wanted to have your laptop and an external monitor working together you had to use Xinerama, lucky me, that has changed. First of all, we need to install xrandr;

 # aptitude install  x11-server-utils

If you executes xrandr, it will show you the outputs you have available:

$ xrandr VGA connected (normal left inverted right)
1280×960 60.0
1280×800 60.0
1152×768 54.8
800×600 56.2
640×480 59.9
LVDS connected 1280×800+0+0 (normal left inverted right) 0mm x 0mm
1280×800 59.9*+ 60.0
1280×768 60.0
1152×768 54.8
1024×768 85.0 75.0 70.1 60.0
832×624 74.6
800×600 85.1 72.2 75.0 60.3 56.2
640×480 85.0 72.8 75.0 59.9
720×400 85.0
640×400 85.1
640×350 85.1

To get all this working, a section must be added into /etc/X11/xorg.conf file

Section “Screen”
Identifier “Default Screen”
Monitor “Configured Monitor”
DefaultDepth 24
SubSection “Display”
Modes “1280×1024″ “1280×800″
Virtual 2560 1024
EndSubSection
EndSection

Using xrandr

Let’s to try out our configuration:

$ xrandr --output VGA --mode 1280x1024 --left-of LVDS

In fact, that is the line we need to put in our little script:

$~ vi .kde/Autostart/dual.sh

Henceforth we can work with an extended desktop, and increase our productivity.

The second part of this article is here, so if you missed the first one, you might take a look Part One.

1. Extending Schema
2. LDAP support for sudo
3. LDAP setup
4. Setting up /etc/ldap.conf and nsswitch.conf

3. LDAP setup

Let’s guess your root suffix is dc=company,dc=com , you need to append the next entry to your directory :

dn: ou=sudoers,dc=company,dc=com
  objectClass: top
  objectClass: organizationalunit
  description: Sudo Configuration
  ou: sudoers

Besides we will need a default profile:

dn: cn=defaults,ou=sudoers,dc=company,dc=com
  sudoOption: ignore_local_sudoers
  objectClass: top
  objectClass: sudoRole
  cn: defaults
  description: Our default options
  sudooption: log_host
  sudooption: logfile=/var/log/sudolog
  sudooption: !syslog

Perhaps you would like to get the most of sudo’s powder, take a look in its website. You can add as much profiles as you like, suppose you want to add one for system administration:

dn: cn=sysadmin,ou=sudoers,dc=company,dc=com
 objectClass: top
 objectClass: sudoRole
 cn: unix_admins
 sudoUser: tuxman
 sudoUser: darkman
 sudoUser: bill
 sudoHost: ALL
 sudoCommand: /usr/bin/ls

As far as I concern, how to configure sudo is out of this post, however together the source of sudo there is an utility, sudoers2ldif, a perl script that helps you to translate your sudo’s configuration file. Next step requires to modify our profile. Probably you will have a similar profile to this one:

dn: cn=default,ou=profile,dc=company,dc=com
objectClass: DUAConfigProfile
defaultSearchBase: dc=company,dc=com
cn: default
credentialLevel: proxy
defaultServerList: 192.168.76.66
profileTTL: 300
searchTimeLimit: 60
authenticationMethod: simple
serviceSearchDescriptor: passwd:cn=sudoers,dc=company,dc=com

After these modifications you must initialize your client (ldapclient).

4. Setting up /etc/ldap.conf and nsswitch.conf

It’s time to tell our client where to find sudoers file, by means of /etc/ldap.conf, that looks something like this.

uri ldap://192.168.76.66
sudoers_base ou=sudoers,dc=company,dc=com
bindpw cn=proxyagent,ou=profile,dc=company,dc=com
binddn password
sudoers_debug 0

You might use anonymous access, that’s your choice, just remember to check your ACI’s. Pretty interesting the option sudoers_debug which helps you to debug, at level 3 will show you as much information as possible. The last step, how to find our sudoers’ profile, nsswitch.conf

  sudoers: ldap

Let’s check if is working:

tuxman@host:$> sudo ls
[sudo] password for client: 

sudo ls
LDAP Config Summary
===================
uri              ldap://192.168.76.66
ldap_version     3
sudoers_base     ou=sudoers,dc=company,dc=com
binddn           (anonymous)
bindpw           (anonymous)
ssl              (no)
===================
sudo: ldap_initialize(ld, ldap://192.168.76.66)
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_sasl_bind_s() ok
sudo: found:cn=defaults,ou=sudoers,dc=company,dc=com
sudo: ldap sudoOption: 'ignore_local_sudoers'
sudo: ldap sudoOption: 'log_host'
sudo: ldap sudoOption: 'logfile=/var/log/sudolog'
sudo: ldap sudoOption: '!syslog'
sudo: ldap search '(|(sudoUser=tuxman)(sudoUser=%other)(sudoUser=ALL))'
sudo: found:cn=sysadmin,ou=sudoers,dc=company,dc=com
sudo: ldap sudoHost 'ALL' ... MATCH!
sudo: ldap sudoCommand '/usr/bin/ls' ... MATCH!
sudo: Command allowed
sudo: user_matches=1
sudo: host_matches=1
sudo: sudo_ldap_lookup(0)=0x02
tuxman@host:$> files/  sudoers2ldif.pl

At this point everything should be working. Last step, to translate our sudoers file.

I’ve just had a problem trying to compile sudo in Sparc, even I had the right paths to my libraries, I couldn’t get sudo working. Here’s what I did:

I realized that if I took the socket library off, (in bold) the error points me out where the library was (for socket), but not for the intl library. Somehow the path wasn’t set properly.

I thought could be that, so I just told the compiler where to find, instead of looking for in library paths. I directly passed the parameters, -L/usr/local/lib -lint (your path might be different, it depends on where you installed it) and everything worked fine.

gcc -o sudo gram.o alias.o alloc.o defaults.o error.o list.o match.o \
toke.o redblack.o zero_bytes.o sudo_auth.o pam.o ldap.o \
audit.o check.o env.o getspwuid.o gettime.o goodpath.o \
fileops.o find_path.o interfaces.o lbuf.o logging.o parse.o pwutil.o \
set_perms.o sudo.o sudo_edit.o sudo_nss.o term.o tgetpass.o glob.o\
fnmatch.o memrchr.o snprintf.o getprogname.o \
-lintl -lpam -ldl -lsocket -lldap -lnsl
Undefined first referenced
symbol in file
socket interfaces.o (symbol belongs to implicit dependency /usr/lib/libsocket.so.1)
libintl_dgettext pam.o
ld: fatal: Symbol referencing errors. No output written to sudo
collect2: ld returned 1 exit status

Now it works :=)

UPDATE: I found out an option that sets another library path: –with-path=/usr/local/lib.

Today I’ve made some simple scripts to get my backups update. Two entries in our crontab will make the rest of work for us.

The first one gets a backup of our database, the second rotates the files. I also add support to Syslog, because I would like to know if my script worked out.

#!/bin/bash
DATE=$(date +%Y-%m-%d)
mysqldump -h host userdb  database  --password=1234 | gzip > \
 ${HOME}/path/files/file-${DATE}.gz

Crontab

Let’s add some entries to our crontab:

user@home:~> crontab -e

As far as I concern I would review the entries, it’s pretty easy to make some mistakes while we’re writing, besides I guess it’s a best practice.

user@home:~> crontab -l

The above command will show our entries.

# m h  dom mon dow   command
HOME=/path/user/home
PATH=PATH:/path/to/ruby

0 00 * * * ${HOME}/scripts/backup_db_blog.sh
0 00 * * * ${HOME}/scripts/rotatedb.rb

There is another thing to take into account, PATHS. Don’t forget to set them.

Syslog

Due to I wanted support Syslog, I had to set it up correctly in my /etc/syslog.conf

local7.*                        /var/log/backups.log
 

Aside to create the above file, you must reload syslog daemon. Afterwards, I wanted to know if that configuration would work. There is a command that will help you:

user@home:~> logger -p local7.debug "Sending a message to debug"
user@home:~> more /var/log/backups.log
Aug  6 20:31:22 home user: Sending a message to debug

The first argument local7 is the Syslog’s FACILITY and the other one is the PRIORITY. You must adapt to your own script.
Here is the script to rotate. After then days, will remove only the four oldest backups.

#!/usr/bin/env ruby
%w(syslog).each {|c| require c }

BACKUP='/path/to/backup/directory'

module SyslogMsg
  Syslog.open("rotatedb", Syslog::LOG_PID | Syslog::LOG_CONS ,  Syslog::LOG_LOCAL7 )
  def send(msg="Message sent")
    Syslog.log(Syslog::LOG_DEBUG, msg)
  end
end

include SyslogMsg
files = []

Dir.entries(BACKUP).each do |e|
  if e !~ /^\./
    files << e
  end
end
files.sort!

if files.length > 10
  0.upto(4) do |index|
    File.delete( BACKUP + "/" + files[index] )
  end
  SyslogMsg::send("Backups for mysql rotated.")
end

Finally, if you get some troubles, review the above steps, check that you have the right permissions and you have reloaded your syslog configuration. If you try the logger command and you see the message you have just sent, everything should work out.

When I’m doing port forwarding I always get the same annoying message

tuxman@athome:> ssh -p 3000 someuser@localhost

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
22:ce:a2:e1:fe:cc:e6:73:cb:03:96:1e:23:3c:5b:55.
Please contact your system administrator.
Add correct host key in /home/tuxman/.ssh/known_hosts to get rid of this message.
Offending key in /home/tuxman/.ssh/known_hosts:159
RSA host key for [localhost]:4000 has changed and you have requested strict checking.
Host key verification failed.

appending some lines to the ~/.ssh/config file, solves the issue

Host localhost
HostKeyAlias youralias

The HostKeyAlias keyword allows us to define an alias and use it instead of the real name. I frequently use ssh port forwarding and I wanted to get rid of this message.

Last day at work I had to get working sudo and ldap. I’m not gonna get into a discussion about if it’s worth or not to use sudo. I can just say from my own experience, if you have a large number of users and hosts, they are clearly distinguishable and you are using roles (i.e: sysadmin, backup, any kind of group…) it’s totally worth.

Moreover, take into account you would have to update every sudo config file , definitely would be tedious, and here’s when LDAP gets in.

I brought into play two virtual machines, both of them running Solaris 10. Commonly I prefer doing that before making some huge mistake in a real environment, so here’s what I did. I called box0 to the client and ldapbox to the server. The rest of the post, I’ll assume you have set up a Directory Server and Native LDAP client service working fine. Summary :

1. Extending Schema
2. LDAP support for sudo
3. Structure of LDAP
4. Setting up /etc/ldap.conf and nsswitch.conf

1. Extending Schema

This step is pretty straightforward, you only need to add the schema to your directory instance, and restart the server. Assuming your instance might be in the default path /var/opt/SUNWdsee/dsins1/config/schema/99users.ldif.

attributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME ‘sudoUser’ DESC ‘User(s) who may run sudo’ EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN ‘SUDO’ )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.2 NAME ‘sudoHost’ DESC ‘Host(s) who may run sudo’ EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN ‘SUDO’ )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.3 NAME ‘sudoCommand’ DESC ‘Command(s) to be executed by sudo’ EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN ‘SUDO’ )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.4 NAME ‘sudoRunAs’ DESC ‘User(s) impersonated by sudo’ EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN ‘SUDO’ )
attributeTypes: ( 1.3.6.1.4.1.15953.9.1.5 NAME ‘sudoOption’ DESC ‘Options(s) followed by sudo’ EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN ‘SUDO’ )
objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME ‘sudoRole’ SUP top STRUCTURAL DESC ‘Sudoer Entries’ MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoOption $ description ) X-ORIGIN ‘SUDO’ )

Now you only need to restart the server.Why do I need to restart my server? The matter is, the first time you started your server, the file was read into memory, so any change you make later will not have effect, at least you restart the instance.

2. LDAP support for sudo

You will need to get the source code of sudo and at least 1.7 version or upper. The reason is because earlier versions will not read nsswitch.conf. I used sudo-1.7.2p7, you can get it from Sunfreeware. Of course if you want to compile you will need to solve some dependencies, here is the list, however you had better confirm by yourself.

/—|(Sudo)
|-* gcc-3.4.6-sol10-x86-local
|-* libiconv-1.13.1-sol10-x86-local
|-* libintl-3.4.0-sol10-x86-local
|-* openssl-1.0.0a-sol10-x86-local

/—|( OpenLdap )
|- * db-4.7.25.NC-sol10-x86-local
|- * libtool-2.2.6b-sol10-x86-local
|- * sasl-2.1.21-sol10-x86-local
|- * openldap-2.4.22-sol10-x86-local

At this point and after installing all the dependencies we just need to compile:

./configure --with-ldap && make

Those people who like tinkering with Unix tools, is time to call ldd and take a look into sudo.

libpam.so.1 =>   /lib/libpam.so.1
        libdl.so.1 =>    /lib/libdl.so.1
*       libldap-2.4.so.2 =>      (/usr/local/lib/libldap-2.4.so.2)
*       liblber-2.4.so.2 =>      (/usr/local/lib/liblber-2.4.so.2)
        libintl.so.8 =>  /usr/local/lib/libintl.so.8
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libc.so.1 =>     /lib/libc.so.1
        libcmd.so.1 =>   /lib/libcmd.so.1
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libsasl2.so.2 =>         /usr/local/lib/libsasl2.so.2
        libssl.so.1.0.0 =>       /usr/local/ssl/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>    /usr/local/ssl/lib/libcrypto.so.1.0.0
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libsec.so.1 =>   /usr/lib/libsec.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        libavl.so.1 =>   /lib/libavl.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libm.so.2 =>     /lib/libm.so.2

If the LDAP libraries does not appear remember to add the path:

# crle -l -u  PATH_TO_LIBRARIES

Obviously I wouldn’t like having to install OpenLdap in all my clients ( if you want to apply to more than one ), so I thought to carry just with the libraries I needed. In a nutshell, we have just extended the schema and also enabled ldap support for sudo. The two last points for the next post.

In most cases when I’m working with the shell, I send my applications to background, mostly my emacs. Nonetheless I forget quickly, and I open too many times the same file.

Due to my lack of memory I decided to make a function that shows me how many programs I have in background, here is the function:

function get_njobs {
 njobs=$(jobs | wc -l)

 if [ $njobs -gt "0" ];
 then
        echo $njobs |  sed -e 's/\([0-9]*\)/(\1)/g'
 fi
}

function prompt {

#  Shell into Emacs
 if [ $TERM != "dumb" ];
 then
    alias ls='ls --color=auto'
    PS1="${purpple}\u@${close}${YELLOW}\h${close}:{\W}\$(get_njobs)"
 else
        PS1="[\u@\h:\w]"
 fi
}

user@host:{~} emacs &
user@host:{~}(1)

As you may notice, the number inside the brackets remembers me if there is some program running in background. Do not forget to add the function at the end of your bashrc.

Last day I ran into a trouble with my subversion repositories, somebody changed the port I was using, somehow my repositories were not able of finding the original url, and here is the way how sorted it out:

user@host:/myrepo/svn switch –relocate http://mysite.com/myrepo http://mysite.com:7777/myrepo

Now you can do commits.

This entry will explain two troubles that I found while I was using
Vmware Server 2 :

1. Initialized monitor device

   If you see an image like shown below,

   

   you had better check if you have “kvm” modules loaded

   # lsmod | grep kvm
   kvm_intel 31168 0
   kvm 106620 1 kvm_intel

   Now yo have to unload the modules, first “kvm_intel”, if you try to unload kvm you will not be able due to dependency between them.
   At this point it turns out that you can start your virtual machine, but maybe you can not open the virtual console, so let’s go next point.

2. Remote console plug-in error

If you are trying out to get a console and it shows up a window like this one, you only need to get an earlier version, for me worked out with Firefox 3.5.7. I even tried an upper version, but it did not work out. I guess there are some troubles
with the last version of Firefox and the plugin.



That’s all, hopefully it will not take long to solve the problem.