Re: Local delivery with Cyrus
Todd Nemanich wrote: > But when I try this I get: > - The following addresses had permanent fatal errors - > addr"|/bin/cat>/path/to/dump/email.data" > (reason: service unavailable) > (expanded from: <[EMAIL PROTECTED]>) >- Transcript of session follows - > smrsh: email.data not available for sendmail programs > 554 5.0.0 > "|/bin/cat>/path/to/dump/email.data"... > Service unavailable This looks more like an smrsh configuration problem, as it's getting as far as executing smrsh, but bailing out at that point. Last time I tried to get something like this to work, I had to install a script in /etc/smrsh, something like this: foo:/etc/smrsh/foo.sh Then in your foo script you would have: /bin/cat>/path/to/dump/email.data -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "MS Linux is released under the provisions of the Gates Private License, which means you can freely use this Software on a single machine without warranty after having paid the purchase price and annual renewal fees." -- mslinux.org
Re: Proper way to repair and remove quota in Cyrus 1.6.24
Paul Wiechman wrote: > That didn't work. Gave Linux 65535 FD's and quota still gives 'quota: > System I/O error Too many open files'. _Where_ (and how) did you give Linux that many file descriptors? There is a system wide limit defined (in fs.file-max and fs.inode-max in sysctl naming convention, from memory), and a per-process limit defined by ulimit. And I believe with the system wide limit, fs.inode-max >= 3 * fs.file-max. -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "Who knows what men lurk in the heart of eval?"
Re: Proper way to repair and remove quota in Cyrus 1.6.24
Paul Wiechman wrote: > edited it in /proc/sys/fs/file-max > > Went to the extreme to try to get it to work. Well, as I said, you need to bump up fs.inode-max (/proc/sys/fs/inode-max in old-speak) as well, plus you neet to bump up your per-process limit (the kernel documentation in Documentation/proc.txt mentions this). On my RedHat 6.1 box, ulimit -Sn and -Hn return 1024, so unless you've adjusted those as well, you'll still strike this limit. -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "Who knows what men lurk in the heart of eval?"
Re: Socket operation on non-socket
"Francesc Guasch" <[EMAIL PROTECTED]> wrote: > imapd[21647]: accept failed: Socket operation on non-socket [...] > ls -ld /var/pwcheck/pwcheck > prwxrwxrwx 1 root other 0 Apr 19 12:20 /var/pwcheck/pwcheck That's a pipe, not a socket, so the error message is valid. You'll need to shutdown your mail system, rm /var/pwcheck/pwcheck, then restart the mail system (sorry I can't be more specific about the "mail system" part; I can't remember how pwcheck and friends interact, but pwcheck should create a unix domain socket). Regards, Daryl Tester
Re: Socket operation on non-socket
"Francesc Guasch" <[EMAIL PROTECTED]> wrote: > I already tried this. When pwcheck creates the socket it's made > this way. Then I'd suggest something is wrong with the pwcheck that you're running. From the last of my 1.5 cyrus machines (1.5.14, according to the machine log) - # ls -l /var/pwcheck/pwcheck srwxrwxrwx 1 root root0 Mar 26 20:15 /var/pwcheck/pwcheck Regards, Daryl Tester
Re: Socket operation on non-socket
John Hughes wrote: > "Daryl Tester" <[EMAIL PROTECTED]> writes: >> # ls -l /var/pwcheck/pwcheck >> srwxrwxrwx 1 root root 0 Mar 26 20:15 /var/pwcheck/pwcheck > On what OS? Good point. The systems tend to be more BSD (FreeBSD, Linux, OSF/1) in nature. > On some (many?) SVR4 derived systems unix domain sockets are > implemented using "ticots" and the filename is just a place holder which > happens to be created as a named pipe. Would that cause the accept failure the original sender was seeing? -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "You shouldn't mix meditation with management. The mind gets too empty." -- Dilbert
Re: connect(/var/imap/socket/lmtp) failed
"Tom Corner" <[EMAIL PROTECTED]> wrote: > I Listed all the directories as imap: > > imap@www:~/cyrus-imapd-2.0.14$ ls -ld /var/imap/socket/lmtp > srwxrwxrwx 1 imap imap0 May 30 22:33 /var/imap/socket/lmtp= > imap@www:~/cyrus-imapd-2.0.14$ ls -ld /var/imap/socket > drwxr-xr-x 2 imap imap 4096 May 30 22:33 /var/imap/socket/ > imap@www:~/cyrus-imapd-2.0.14$ ls -ld /var/imap > drwxr-x--- 13 imap imap 4096 May 30 03:28 /var/imap/ > imap@www:~/cyrus-imapd-2.0.14$ ls -ld /var > drwxr-xr-x 19 root root 4096 May 29 19:01 /var/ OK, these permissions show that only processes of user OR group imap can get access to that socket (or root, but that can get to anything :-). I haven't used deliver, so I don't know if it runs setuid, but do an ls -l on that executable for its flags. BTW, what's invoking deliver? Sendmail or something similar? Regards, Daryl Tester
Re: connect(/var/imap/socket/lmtp) failed
Tom Corner wrote: > May 31 12:00:07 www sendmail[281]: f4VA06b00279: to=corner, ctladdr=corner > (1001/100), delay=00:00:01, xdelay=00:00:00, mailer=cyrus, pri=30094, > dsn=4.0.0, stat=Deferred: cyrus mailer (/usr/cyrus/bin/deliver) exited with > EX_TEMPFAIL > > I guess it shows that sendmail is trying to pass mail to deliver and > deliver is exiting with an error. But I sure can't see why. Well, the other syslog entry showed you the symptom. Time to dive into your sendmail.cf file, locate the entry for "Mcyrus", and post what the "U=" line is set to. Actually, a dump of the entire Mcyrus entry might be better, plus the version number of your sendmail. Regards, Daryl Tester
Re: connect(/var/imap/socket/lmtp) failed
"Tom Corner" <[EMAIL PROTECTED]> wrote: > I have just changed my sendmail.cf. Attached is the entire file. > This time I used cyrusv2.mc which I edited the mailer def, > adding U=imap:imap. Urm, OK, but I wish you wouldn't - it's hard to fix a configuration if you're changing it. For instance: > Mcyrus, P=[IPC], F=lsDFMnqA@/:|SmXz, E=\r\n, > S=EnvFromL, R=EnvToL/HdrToL, T=DNS/RFC822/X-Unix, > U=imap:imap,A=FILE /var/imap/socket/lmtp shows that you aren't using deliver at all, so those messages from deliver shouldn't be making an appearance in your syslog. I'm not sure if U= is appropriate for delivery to a local socket, but I'd leave it off (it should then run as root, but I'm not 100% certain of this - my sendmail doco is elsewhere at the moment). Another point is that you shouldn't be editing sendmail.cf directly unless you have Sendmail Zen; you should make your changes to the .mc file and use that to generate your .cf file. > I am just > starting to test this new configuration. Make sure you stop/start sendmail with changes to its config. Regards, Daryl Tester
RE: Duh, Hello McFly! (was Re: LMTP - getting in the way)
Louis LeBlanc wrote: > The log entries are still blowing out to every freakin' xterm I > have up tho. > Maybe changing the syslog entries to local6.* would help? Yes. I'm not near a Unix box at the moment (more's the pity), but in /etc/syslog.conf you'll have an entry for either local6.* or *.something, and it's most likely writing to something other than a file. Rip it out and restart syslogd. Regards, Daryl Tester
Re: lmtp again.
Louis LeBlanc wrote: > Jul 4 22:17:15 acadia deliver[2376]: connect(/home/mail/socket/lmtp) failed: >Permission denied > > However, > # ls -l /home/mail/socket > total 0 > srwxrwxrwx 1 root mail 0 Jul 4 20:20 lmtp And what about the permissions on /home/mail/socket, and /home/mail (and ultimately, /home)? Remember that you need permission through the entire path, not just for the last component. Regards, Daryl Tester
Re: Newbie struggling with sendmail config
Fred Ball wrote:
> It instructs me to add the following two lines to cyrusproto.mc:
>
> OSTYPE(freebsd4)
> DOMAIN('DOMAIN.COM')
That should be
DOMAIN(`DOMAIN.COM')
Note that the first quote character should be a backtick (located
under the ~ on this keyboard, if that helps), not a single quote
character.
Regards,
Daryl Tester
Re: Signaled to death by 11 - Don't know what else to try
John Riganati wrote: Not sure if this is significant or not, but ... > My ld.so.conf file looks like this: > [root@vmsurfrider Docs]# more /etc/ld.so.conf > /usr/local/BerkeleyDB.3.2/lib [...] > [root@vmsurfrider bin]# ldd master > libdb-3.1.so => /lib/libdb-3.1.so (0x4010d000) > [root@vmsurfrider bin]# ldd imapd > libdb-3.1.so => /lib/libdb-3.1.so (0x401af000) > [root@vmsurfrider bin]# ldd pop3d > libdb-3.1.so => /lib/libdb-3.1.so (0x401af000) Those binaries don't appear to be pointing to your newly built Berkeley DB library (particularly as the version numbers are different). Regards, Daryl Tester
Re: Signaled to death by 11 - Don't know what else to try
Levent G|ndogdu wrote: >>> [root@vmsurfrider bin]# ldd master >>> libdb-3.1.so => /lib/libdb-3.1.so (0x4010d000) >> >>> [root@vmsurfrider bin]# ldd imapd >>> libdb-3.1.so => /lib/libdb-3.1.so (0x401af000) >> >>> [root@vmsurfrider bin]# ldd pop3d >>> libdb-3.1.so => /lib/libdb-3.1.so (0x401af000) >> >> Those binaries don't appear to be pointing to your newly built >> Berkeley DB library (particularly as the version numbers are >> different). > Are you sure that the values in parantheses really describe the version > numbers? I wasn't referring to the offsets, but to the file names that were linked to (and the version numbers embedded in that). In addition, John also implied (in his ld.so.conf) that he built the DB libs in /usr/local/BerkeleyDB.3.2/lib, yet those libraries above point to /lib (and version 3.1). > I thought it's some offset information, correct me, if I'm > wrong. Yes, the bracketed values are offsets, but I wasn't referring to them. > Everything is configured and built without > any further user interaction. ldd displays different values for almost > any library. They do match in this case, but I'm not familiar enough with Cyrus 2.x to see if he has missed out any executables that are needed. -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "You shouldn't mix meditation with management. The mind gets too empty." -- Dilbert
Re: Quota warnings
Lawrence Greenfield wrote: >Notifying the user who has exceeded quota so they can fix the problem >immediately, instead of wondering why they haven't any messages for two >days, and then calling tech support complaining that "their account is >broken". [...] > Cyrus sends out ALERTs when the user is over quota, but some clients > may not display them. I think Jules was after a text email message being sent to the user (which brings about its own problems, because the account is already over-quota, and how do you stop at just one message). My understanding[1] is that the ALERT occurs at IMAP protocol level. [1] Which could be wrong - I haven't looked at IMAP as a protocol for a while. -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "Now is the Winter of our Discount Tent." -- The Red Green Show
Re: FAQ: What is saslauthd?
Ken Murchison wrote: >> Hey, it's no big deal--I'm sure I can handle counting characters ;-) But if >> it ain't broke, don't fix it, huh? > I think this is more of a move forward and a preemptive thing. Let's > change it now before we realize that it is broken down the road. I guess it's the old "in-band vs. out-of-band signalling" thing. Squid's external authenticators communicated in a similar way, and had an issue when someone figured out how to inject "\n"'s (Squid's string separators) into the string. -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "Now is the Winter of our Discount Tent." -- The Red Green Show
Re: Reliable mailstore
Mark Newton wrote: > In any case, what I'm trying to end up with is a system built around a > large filestore (suitably RAIDed for reliability) with multiple front-end > systems (for scalability). > > I've noticed in the Cyrus documentation that NFS is not an option for > doing this kind of thing, so I'm left wondering if there's some other way > to do it. Coupla thing re: Cyrus. One method for scaling under Cyrus is to use an special front end to IMAP, of which a couple leap to mind - The Murder IMAP Aggregator at http://asg.web.cmu.edu/cyrus/ag.html, or Perdition, the mail retrieval proxy at http://www.vergenet.net/linux/perdition/ . Not that I've (had to) use either of these products, just that I'm aware of them. The other thing is that CMU still run their campus wide Cyrus installation on one machine, the specs of which escape me (but supports something like 100K users under Solaris? Ahh, here it is, see [1]). -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "Now is the Winter of our Discount Tent." -- The Red Green Show [1] http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&searchterm=200%2C000&msg=3698
Re: imap:admin ?
Not sure if this has been answered yet - I just saw the list go
bunta from backlog, but anyways ...
Lance Hoffmeyer wrote:
> I wrote a script that moves and renames folders and the beginning
> of each month.
> The problem is that when I print the new names out they appear as
>
> Listserv.Info-Cyrus.2002-January
>
> but when the program actually runs the names come out as
>
> Listserv.Info-Cyrus.2002-0
[Snippity]
> my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isday) = localtime(time);
> $year +=1900;
> if ($mon==1){$cmonth='January'};
Ahem. $mon runs from 0..11, not 1..12.
> my $date=$year.-$cmonth;
$cmonth wasn't being set. For defensive programming, initialising
$cmonth to "Not Set" before your multiway "if" would have shown
you the problem.
--
Regards,
Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd.
"Now is the Winter of our Discount Tent." -- The Red Green Show
Re: bind error while running imspd 1.6a3 from inetd
Alan Thew wrote: > We are seeing the following error a few times a day on our student mail > server. > > imspd exiting: bind: Permission denied > > We are running from inetd. This seems a little odd, but if you're running imspd from inetd, then why is it trying to bind to a port? Daemons that are started from inetd normally talk via inherited file descriptors. -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "Now is the Winter of our Discount Tent." -- The Red Green Show
