Topic: LDAP not working after upgrade, and strange mail-delay

[Lasse Johansson]

I've upgraded a server from 4.1.2 up to 5.6u4

I did a very careful upgrade step-by-step (4.1.2->5.0 etc etc)

I have found TWO strange behaviours:


1:

Now the server is running, but somehow the LDAP-deamon doesn't seem to work correctly.

Extract from /var/log/messages during startup:

Jun  3 20:11:21 server ldap: Starting slapd:
Jun  3 20:11:22 server slapd[1265]: daemon: socket() failed errno=97 (Address family not supported by protocol)

Anyone???????




2:

Now, when a user sends a mail, it takes about 10 seconds from clicking on "send" until the mail seems to "leave the client station"
(i.e The mail client shows "delivering mail" for about 10 seconds...)

in /var/log/qmail, every send message ends with a "success: did_1+0+0/"

Example:

"@400000003edce72812f54774 delivery 7: success: did_1+0+0/"

Is this normal, or where should I look for a solution???

[Lasse Johansson]

One more finding!

In /var/log/smtpfront-qmail/current almost every delivery seems to include the line

"bytes out: 167", - no matter the size of the mail.

Examples:

@400000003edbea66150e4fec smtpfront-qmail[28969]: Accepted message qp 28970 bytes 1237567
@400000003edbea66151c2eb4 smtpfront-qmail[28969]: bytes in: 1254508 bytes out: 167


..just thought someone could use this as a clue...?

[Steven]

I have the same problem with the mail delay.  If you have an attachment of say 1mb does it take about 10 mins? mine does.
I posted about a month ago with this query, and no one seemed to know the answere.
Sorry I can't help.
Let me know if you find a solution

Steven

[Lasse Johansson]

Accoirding to http://www.openldap.org/faq/data/cache/652.html, the explanation of the message:

daemon: socket() failed errno=97 (Address family not supported)

is:

"This message indicates that the operating system does not support one of the (protocol) address families which slapd( was configured to support. Most commonly, this occurs when slapd( was configured to support IPv6 yet the operating system kernel wasn't. In such cases, the message can be ignored. "

Could anybody else out there please confirm if this is to be considered as "normal" in SME 5.6u4 ???

[Lasse Johansson]

So, no one seems to know the answer for my previous questions, - perhaps quite understandable...

However, I *NEED* to restore the mentioned system into a workable system again, and therefore I would like to share some thoughts and findings here for you to comment:

First a few words about the system:

It's the main server system used in a medium sized company (around 40 users) and it contains somewhere around 30 GB very important data at the moment.

Previously, it's been running (very well in fact!) on a 450 MHz, 3xx MB, AMD platform equipped with Adaptec 29040 SCSI host adapters and SCSI disks.

I moved the system to an Intel platform, 2.4 GHz, 1024 MB RAM, 146 GB SCSI-disks and 29160 host adapters, and during this move I also upgraded the system from ESS&G 4.1.2 to SME 5.6u4 (step-by-step, as described erlier).  Since I have "mirrors" of the disks, I did the whole upgrade "off-line" just for testing purposes twice before I did the "real upgrade". I found that all deamons seems to be running, and to my best knowledge, the final system seemed and looked like a correctly running system...

After having done the "real upgrade", and used the new server "live" for almost one week, I have found that several things in the system seems to be "corrupted".

For example, if I add a new user "test" to a group, the user doesn't appear in LDAP, after deleting that user "test" again, he no longer appears in the server-manager among users, nor as a member of that group, but if I send a mail to the group address, the server responds that it cannot deliver the mail to the user "test"...

Many other similar findings makes me feel that "something wicked happened" with the master configuration file or somewhere around that...

We have tape backups, but since the problem probably is included in the tape backup as well, I don't want to use it here.

I'm about to try another approach instead:

Since I have several "mirrors" (physical disks) of the system, I could:

1. Sync all the mirror disks (I have three of them)
2. Start up the system on one of the other mirrors
3. DELETE all user files, and every file in every IBAY!!!
(Otherwhise, "backup to desktop" can't be done, since the file size is going to be somewhere around 30 GB or so...)
4. Make a "backup to desktop", and a "reinstallation floppy"
5. Install a new fresh 5.6u4 on a new disk, (using the "reinstallation floppy" to save a few minutes)
6. Do a "restore from desktop" into the new, fresh system
7. Now, if I'm correct, I should have a new system with all my previous users/groups intack, right?
8. Finally mount the "orginal disk", - in order to move back (cp -p ?) all the files deleted in # 3 above

My questions to you gurus are:

Would this, in your opinion, be an approach even worth trying?

When "restoring from desktop" into a new fresh system, are the master configuration files REBUILD or just "RESTORED", anyone???

Any opinions, comments or experiences regarding any of the steps described above would be warmly welcomed!

Regards:

Lasse Johansson

[Steve Bush]

Are you able to add new groups to your system?

[Lasse Johansson]

Really, I'm not really keen on testing those featurer on the running system right now, since the server is really critical.....

Why're U asking? Can I find any hint of any possible situation by examine some files somewhere???

[Steve Bush]

I'm not able to add new groups or modify existing groups on two of my SME56U4 servers.  Strangely they are the two that I installed and then restored from tape backup (one was SME55, the other was SME50.

I was curious to see if you were seeing the same problem.

fyi - one of my servers' LDAP is hosed as well.

I have pinpointed the problem to the event:
/etc/e-smith/events/group-create/S15group-create-unix