[Matt Wynne]

Hi Dave

Has the IP address changed? Everything you do under an ODM is bound to an ip address, so even if it’s not changed I’d be inclined to run the changeip command:

Usage: changeip

[ ]
eg: changeip /LDAPv3/127.0.0.1 11.0.1.10 11.0.1.12 server10.example.com server12.example.com
And see if that resolves the problem

Cheers

[Matt Wynne]

Thanks Joel! 🙁

That’s the conclusion I’d come to after getting back to work today after the holidays. Do you/anyone else know of specific hardware devices that would do this? It would save us a lot of searching.

Cheers

[Matt Wynne]

Having played around a bit with the routing table and using tcpdump to monitor the incoming connections, it seems that the packets that are being passed from the router retain their original IP address/port number. I was under the impression that a NAT router made the packets appear to come from it self, not from the original source. I’ve tried this on 2 different routers and also using the DMZ method and plain old port forwarding, see the following:

Making an ssh connection from a remote ip address (195.172.14.194) to the external ip address of number 2 router (217.36.219.96) with ssh port forwarded to our xserve (10.1.0.3) results in output:

14:34:10.983759 IP 195.172.14.194.50765 > 10.1.0.3.ssh: S 1964128251:1964128251(0) win 65535

See the source? 195.172.14.194!! Not 10.1.0.1. It’s no wonder the route isn’t working because 10.1.0.1 doesn’t appear anywhere. To just to prove the point I added 195.172.14.194 as a static route and it went straight in.

Can someone tell me if I’ve gone completely mad but I thought the whole point of NAT is that it breaks the end-to-end nature of IP addressing? And if so why don’t 2 very popular routers (ZyXel and Draytek) both not work this way.

In the mean time I’m going to have a long bath and read the RFC on NAT!

[Matt Wynne]

Thanks for the info but I’ve tried that already – route -n add 10.1.0.1/24 10.1.0.1 results in it reporting that this route already exists. And it does, because I have en1 set to 10.1.0.3, it’s dynamically set the routing table accordingly – and only unknown packets should be going to the the default gateway (192.168.1.249).

And that’s the point, these shouldn’t be unknown packets. If they come from a device in the 10.1.0.1/24 range then by all the IP rules I can find, they should go back to the device that sent them as long as that device has a valid entry in the arp table.

[Matt Wynne]

Have you tried using the Automatic naming function in System Image Utility? We’ve found it works well, especially if you already have a list of MAC addresses handy from an Asset List or similar.

[Matt Wynne]

Thanks Joel – we’re doing that now and what’s even weirder is we’ve discovered, by sending back and forth, that it only happens to replies. If they send a fresh mail to us or vice versa, it’s fine. If they reply to a message we’ve sent them, it bounces. I’m getting them to send over the error message and replies to my .Mac account.

[Matt Wynne]

[QUOTE BY= PopeOfBrooklyn] Well, I’ve gone through MacTroll’s initial instructions and Epaulsen5’s further refinements (on Page 8 of this forum) but I’m still having troubles. I’ve added the avelsieve plugin to SquirrelMail, but when I click on the Filters link I get the dreaded

Warning: split(): REG_EMPTY in /usr/share/squirrelmail/plugins/avelsieve/lib/sieve-php.lib.php on line 427

Checking my console.log I get an endless procession of

Sep 4 13:21:35 mail crashdump: Couldn’t find or create: /var/imap/Library/Logs/CrashReporter (euid: 77)
Sep 4 13:21:35 mail crashdump: Started writing crash report to: /Library/Logs/CrashReporter/timsieved.crash.log
Sep 4 13:21:35 mail sieve[28572]: incorrect version of Berkeley db: compiled against 4.1.25, linked against 4.3.28
Sep 4 13:21:35 mail crashdump: Finished writing crash report to: /Library/Logs/CrashReporter/timsieved.crash.log
Sep 4 13:21:35 mail crashdump: Unable to determine CPSProcessSerNum pid: 28572 name: timsieved
Sep 4 13:21:35 mail master[26819]: process 28572 exited, signaled to death by 10

I’m figuring that the compiled vs. linked to BerkeleyDB is the problem but I don’t know how to fix it. I’ve checked the permissions to pwauxprop.la and pwauxprop.so and /usr/sieve and they’re set to what’s been suggested in this forum. I must have missed something, but I’m pretty well stumped as to what. Any ideas?

This is on a 10.3.9 box with all updates except the Security Update 2005-007 and the Safari 1.3.1.
[/QUOTE]

I had exactly the same thing on one server recently that refused to play ball, even though another server that I’d set up using the same method worked perfectly. After ruling out everything else, I tried deleting every related .pkg and .tar.gz file I had on that server and re-downloading them, clear any receipts. Bingo, installed them (Joel’s bit first then epaulsens fix for 10.3.9 after) and it worked first time.

[Matt Wynne]

[QUOTE BY= boardwalk2] Went throught steps to 1 through 6.
The messages on terminal seemed to be what is expected
from the make and install steps.
Restarted the mail service.
Logged in as an user from squirrelmail.
Do not see the ‘Filter’ menu on top.

Any suggestions on what to check? Maybe missed a step?

Thank you in advance.[/QUOTE]

Even though I’d done this install on about 8 or 9 servers I missed out one step recently that did this so it’s worth checking. It’s in Step 3 of Joel’s original check list –
3 . Install AvelSieve pkg, and configure squirrelmail to use the new avelsieve plugin.

It’s this last bit, you need to run /etc/squirrlemail/config/conf.pl as root and enable the AvelSieve plugin.

Easily missed!

[Matt Wynne]

Phips

Your problem may be one of many things bu the error message you’re getting is known about and is because the pwauxprop.la and .so files have permissions that the system doesn’t like, not because they are wrong. They are set like this so that the mail group doesn’t have access to them. These errors are normal.

The comments to that particular article are very long but try some of these to point you in the right direction;

Pg 1 for the initial fix AND most of the common faults. See especially about Troubleshooting 1-7.

Pg 8 for epaulsen’s fixes for the changes Apple made in 10.3.9.

This should get you on the right track as to why your vacation messages won’t work.

[Matt Wynne]

Was this first time you’ve tried to run mail on tiger? If not what did you change? I’ve got a similar problem on a a test Tiger server I’m running here – happened after upgrading to 10.4.1!

[Matt Wynne]

V.Tired – thanks for the heads up. Basically it appears that Apple recompiled the reconstruct utility to include the -i switch not only to enable the import into mailboxes.db in a repair situationsbut ALSO in the once-only time migration from AMS! The IMAP flag INTERNALDATE gets set to 0, which is never correct, and would cause an error with any mail client that asked for it. Thunderbird, however, seems unique amongst most mainstream IMAP clients in not asking for this flag, hence no problem! A chap from Brighton – James Goodlet – has recompiled versions for 10.3.9 and 10.4 to stop/fix the problem happening.

Thread at Apple Discussion here

Link to James’ recompiled version of reconstruct here and more instructions here

UPDATED – John Thompson has put an article on the front page (if like me you came straight here you might have missed it!) go to it here

[Matt Wynne]

You can enter multiple addresses into the forward box in the users mail section in WGM – just separate them with commas.

Chapter 1 Pg 27 of the Mail Admin Guide here

[Matt Wynne]

Ermm… did all this and get the following in System.log

: could not lock pid file /var/state/saslauthd/saslauthd.pid: Resource temporarily unavailable

Killing the exisiting 5 instance of saslauthd and then manually relaunching it with /usr/local/saslauthd -a PAM gets rid of that but then
when accessing the filters you still get:

incorrect version of Berkeley db: compiled against 4.1.25, linked against 4.3.27

What follows is an unending sequence of the master and sieve processes failing until you restart mail.

This is odd – so just to be on the safe side I reinstalled BDB4.1 but still the same.

Just wish my idiot assistant had’t taken it upon himself to update the server!!! It’s been working great since last August.

Any ideas?

[Matt Wynne]

Thanks Joel but they want users to actually be in more than one Workgroup (obviously not at the same time) but to log into one automatically unless they choose not to – I guess it’s akin to have auto-login on a client but if you hold shift down you get the user list up. They’ll just have to tell the user which one to log into first time and get them to select the remember option for future log-ins.

Cheers anyway.

[Matt Wynne]

Aaaaaarggh! Back to basics – NeST -hostpasswordserver wasn’t working because, for some reason, AUTHSERVER=-NO- was in /etc/hostconfig. Either used NeST -authserver or simply modifing /etc/hostconfig, that then allows NeST -hostpasswordserver …. to do it’s thing!!

Weird but fixed – phewww!

[Author]

Posts