Passed – RH423 Red Hat Enterprise Directory Services and Authentication

This week I had the “Red Hat Enterprise Directory Services and Authentication” course and exam in Amsterdam.

In the course we had some very nice stuff, like Red Hat DS and at the end Red Hat Enterprise IPA… all very cool… but today I had the exam (due to the RedHat NDA I am not allowed to say anything about the exam, so I won’t do it)… but a few hours after the exam I received my results… and I passed the exam :-D

Issues with connectivity on MORPHEUS

As you might have noticed, the last few weeks we had issues with the connectivity of morpheus.adslweb.net. We changed the contract (so we got physical connected to another network, but still from XS4ALL) and we installed a new ADSL-modem (a Fritz!…

Why is the script slow… (part 2)

In my previous post I wrote some about a script which was running slow. After a chat with a colleague he pointed me on the paging and there is a PERL module for LDAP-paging. So I implemented this in the script I was working on. See the next result…

Why is the script slow…

For a project I am working on migrating UNIX applications to Linux. Most of the scripting work supposed to be done in India, and that is where the issues came in. First you have a developer who knows how to work with M$ Technet and never worked with PERL before (at least 80% of the scripts is written in PERL).

First of all I introduced the user Net::LDAP within PERL, because they first did a ldapsearch, put the output into a ASCII file… and with a PERL script they structured the data… and loaded it into a Oracle database… so that was the first improvement.

Next there were several issues, like not good reading or understanding LDAP/PERL at all…

But at a certain moment, they start complaining about the fact that one of the scripts was slow… on the old system the script had a run time of 4 hours… and now it is up to 28 hours(!!!) :-( So they requested me to investigate this.

First I found a ‘main’ kornshell script doing the next thing:


for VAR in a b d e f g i j k m n o p q r s t u v w x y z
do
   for NAME in “‘” a b c d e f g h i j k l m n o p q r s t u v w x y z
   do
     ldap_script.pl $NAME $VAR
   done
done


The content of the ldap_script.pl was something like:


#!/usr/bin/perl
use Net::LDAP;
$ldap = Net::LDAP->new($LDAP_SERVER);
$ldap->bind($LDAP_DN, password=>$LDAP_PASSWD) or die “Cannot connect”;
$LDAP_FILTER=”(&(sn=$ARGV[0]*)(OfficeName=$ARGV[1]*))”;
$mesg = $ldap->search(base=>$LDAP_BASE,
                      filter=>$LDAP_FILTER,
                     ) or die “Cannot connect”;
push(@ENTRIES,$mesg->entries);
$ldap->unbind;


I thought that this costs a lot… loading PERL script, connecting to server, binding to it… et cetera… :-( And this was done in the original script > 2000 times :-|

So… I removed the loop out of the mainscript… and implemented it into the PERL-script, like this:


#!/usr/bin/perl

use Net::LDAP;

$ldap = Net::LDAP->new($LDAP_SERVER);
@LOOP=(“a”,”b”,”c”,”d”,”e”,”f”,”g”,”h”,”i”,”j”,”k”,”l”,”m”,”n”,”o”,
       “p”,”q”,”r”,”s”,”t”,”u”,”v”,”w”,”x”,”y”,”z”, “‘”);

$ldap->bind($LDAP_DN, password=>$LDAP_PASSWD) or die “Cannot connect”;

foreach $LOOP1 (@LOOP)
{
  foreach $LOOP2 (@LOOP)
  {
     $LDAP_FILTER=”(&(sn=$LOOP1*)(OfficeName=$LOOP2*))”;
     $mesg = $ldap->search(base=>$LDAP_BASE,
                           filter=>$LDAP_FILTER,
                          ) or die “Cannot connect”;
     push(@ENTRIES,$mesg->entries);
  }
}

$ldap->unbind;


And this runs within 3 hours!!! And it is flying! :-D

There can be done more performance tuning… but that will be another project!

Fedora directory server

Yesterday evening I start playing with Fedora Directory Server

So first I setup Fedora Core 8 as a VMWare-instance… But after some playing around, I had the next message:

“Server failed to start !!! Please check errors log for problems”

And guess what… no information at all in the logs :-( So removed the packages and the next directories:

/etc/dirsrv
/etc/sysconfig/dirsrv
/var/lock/dirsrv
/var/lib/dirsrv

So no information… then strace will be your best friend :-D

So I started:

[root@fedora-ds debug]# strace -o ~/debug/setup -ff /usr/sbin/setup-ds.pl

And guess what… I had the error again… So I went to the ~/debug folder on another terminal and did:

[root@fedora-ds debug]# grep “failed” *
setup.31676:read(4, “Server failed to start !!! Pleas”…, 4096) = 64
setup.31676:write(2, “Server failed to start !!! Pleas”…, 64) = 64
setup.31711:write(1, “Server failed to start !!! Pleas”…, 64) = 64
[root@fedora-ds debug]#

When I digged into setup.31711 I found:
read(255, “if test ! -f $STARTPIDFILE ; the”…, 2220) = 663
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64(“/var/run/dirsrv/slapd-fedora-ds.startpid”, 0xbfcd8eb8) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8-) = 0
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, …}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f7c000
write(1, “Server failed to start !!! Pleas”…, 64) = 64

So this is a nice clue… /var/run/dirsrv… and guess what… the owner of this directory was fedora-ds (a user I set up initially for testing purposes for the Directory Server :-( ) With the comment chown I corrected the owner of this folder… and now service dirsrv start works :-P

Conclusion… strace is your best friend :-D

Gentoo Firefox phones home

Some while ago, I submitted a bug to the Gentoo Bug-trac. I had trouble with Firefox 2.0.0.2 when switching from non-proxy to a proxy-network.

http://bugs.gentoo.org/show_bug.cgi?id=169155

I found that when starting firefox (note: not firefox-bin) the proces wants to connect to www.gentoo.org :-(

Now someone found the issue:

I have the same problem with mozilla-firefox-2.0.0.13.
Firefox tries to connect to the page mentioned in
/usr/lib/mozilla-firefox/defaults/pref/all-gentoo.js:
pref("browser.startup.homepage", "http://www.gentoo.org/");
If DNS or the page itself is unreachable firefox waits until the request
timeouts.

I haven’t test it yet… but it might solve the issue… ;-)