Talk:Qmail, Mail toaster
(→Checking Environment Variables) |
(→Checking Environment Variables) |
||
| Line 185: | Line 185: | ||
ENVs to particularly note: TCPREMOTEINFO, TCPREMOTEIP | ENVs to particularly note: TCPREMOTEINFO, TCPREMOTEIP | ||
| + | |||
| + | Final note for the night: don't see why not do my own standalone wrapper; mail got delivered fine while I was piping environment variables to a text file and piping STDIN to qmail-queue just now. No black magic a'tall, I don't know why wrapping qmail-queue wasn't seeming to work for me the last time I tried it; maybe I just didn't have the permissions set so that my wrapper would execute then? | ||
| + | |||
--[[User:Jimbo|Jimbo]] 02:58, 21 Feb 2006 (EST) | --[[User:Jimbo|Jimbo]] 02:58, 21 Feb 2006 (EST) | ||
Revision as of 03:00, 21 February 2006
no, really, the comma shouldn't be there. (or the title should be "what it is, and what we are doing here" without the question mark). I used to be a spelling and grammar nazi in a past life.
-d.
You're going to have to back that up with an external link to a well-accepted style guide that clearly states that using a comma there is wrong, and even then I don't promise to care. =) --Jimbo 20:36, 15 Dec 2004 (EST)
http://cctc2.commnet.edu/grammar/commas.htm
while not incorrect to use the comma there, it makes for bad scanning.
-d.
I'm not well up on wiki etiquette so I just thought I'd add a comment here on a small change I made.
I added two /etc/ to the following section to ensure the command will work correctly when executed outside of the /etc directory
ph34r# rehash ph34r# cat /etc/tcp.smtp | tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp
Also for some reason I couldn't get make enable-qmail to execute. It was probably something I was doing wrong but should anyone run into similar difficulty just check out the file work/qmail-enable inside the qmail+smtp_auth+tls ports directory.
Its easy enough to read what it does and then execute the commands for disabling sendmail and enabling qmail manually.
P.S. Great guide, it was very helpful, Eoin
Huh - that's odd (that make qmail-enable ran into problems). Never seen that before. And your change was good, thanks. =) --Jimbo 10:59, 7 Jun 2005 (EDT)
Contents |
oddly enough
so for giggles, i'm installing a listserv (using mailman...i'll let you know how ti works out) and I'm using FreeBSD for the hell of it. and I am also having problems doing a make enable-qmail. going into the work dir doesn't shed any light on the matter as the only thing in there is:
# ls -la total 28 drwxr-xr-x 3 root wheel 512 Jul 13 16:18 . drwxr-xr-x 3 root wheel 512 Jul 13 16:18 .. -rw-r--r-- 1 root wheel 0 Jul 13 16:18 .build_done.qmail-smtp_auth+tls-1.03.20020519_1._var_qmail -rw-r--r-- 1 root wheel 0 Jul 13 16:18 .configure_done.qmail-smtp_auth+tls-1.03.20020519_1._var_qmail -rw-r--r-- 1 root wheel 0 Jul 13 16:18 .extract_done.qmail-smtp_auth+tls-1.03.20020519_1._var_qmail -rw-r--r-- 1 root wheel 0 Jul 13 16:18 .patch_done.qmail-smtp_auth+tls-1.03.20020519_1._var_qmail -rw-r--r-- 1 root wheel 311 Jul 13 16:18 SMTP_AUTH+TLS.readme -rw-r--r-- 1 root wheel 2639 Jul 13 16:18 pkg-install drwxr-xr-x 2 root wheel 16896 Jul 13 16:18 qmail-1.03
so what does enable-qmail do (as a target to make) that just a make install doesn't?
See the directory that I bolded in your ls output there? That's where the goodies are. That's how the work directory from a built port always looks. But in this case, what you actually want to look at is files/enable-qmail.in. What it does is, so far as I can tell, is just make sure that the mail command gets realiased to qmail from whatever it was aliased to before, by the means of copying a conf file. From looking at the Makefile, though, it looks as though the qmail-enable target may not even exist anymore; it looks like an installation of qmail since 1.03_3 will probably make a /var/qmail/scripts directory instead, from which you can run the script /var/qmail/scripts/enable-qmail. Lemme know what you find out, okay? --Jimbo 00:00, 14 Jul 2005 (EDT)
It might be worth mentioning that if vpopmail is ever upgraded then you need to manually reset the file attributes of /usr/local/vpopmail/bin/vchkpw or users will have login troubles.
-Eoin
Great Guide but I am having problems with SqWebmail Portion, it seems now that the in the ports tree when you install sqwebmail you get courier-authdaemond installed instead of sqwebmail-authdaemond, and I can not find anywhere the PREFIX script I need to replace in the .sh files, and I notice that courier-authdaemond has PREFIX already set to /usr/local already.......so I thought I was good to go.
but after I start the daemons and point my browser to Sqwebmail I get a 500 error with: The webmail system is temporarily unavailable. An error occured in function write: Socket is not connected?
I notice that in the courier-authdaemond.sh there is a setting for socket with the base directory being $authbase/run/socket however there is not a socket file or folder in /var/run
Any Thoughts?
- J
are you sure that $authbase == /var/run? I'd do a "find / | grep socket" to see where it might be..
--Dave 23:42, 14 Sep 2005 (EDT)
Here is the output:
nusparky# find / | grep socket /usr/include/netgraph/bluetooth/include/ng_btsocket.h /usr/include/netgraph/bluetooth/include/ng_btsocket_hci_raw.h /usr/include/netgraph/bluetooth/include/ng_btsocket_l2cap.h /usr/include/netgraph/bluetooth/include/ng_btsocket_rfcomm.h /usr/include/netgraph/ng_ksocket.h /usr/include/netgraph/ng_socket.h /usr/include/netgraph/ng_socketvar.h /usr/include/sys/socket.h /usr/include/sys/socketvar.h /usr/local/man/man1/socket.1.gz /usr/local/bin/socket /usr/local/lib/perl5/site_perl/5.8.7/mach/sys/socket.ph /usr/local/lib/perl5/site_perl/5.8.7/mach/sys/socketvar.ph /usr/local/share/doc/socket /usr/local/share/doc/socket/README / ......the rest are documents or in the ports tree ^C nusparky# nusparky# nusparky#
Any ideas?
-J
maybe something else is holding the socket open? I'm guessing you've got sqwebmail tied into apache -- is your apache config ok? I don't run webmail myself so I probably won't be much help.
--Dave 09:47, 15 Sep 2005 (EDT)
have you tried to ps waux | grep authdaemon?
Try to start the authdaemon - /usr/local/etc/rc.d/(whatever)daemond.sh start - and then ps waux | grep authdaemon. Is it running?
If it isn't, you're going to need to figure out why. Usually the easiest way to deal with that PREFIX crap is just to snip it out and sub in the /usr/local/ hard-coded. --Jimbo 02:07, 16 Sep 2005 (EDT)
lsof to find open sockets maybe
might want to use lsof to see what's holding the socket open too...
--Dave 11:56, 17 Sep 2005 (EDT)
this article should be updated...
...unfortunately, until i reinstall freebsd on a sparc at work, i have no bsd to do it with; the make qmail-enable thing doesn't work (i do the qmailrocks.org install myself....although i've been playing with postfix recently, and i'm going to install zimbra on my new listserver (why i moved my x86-64 box to CentOS instead of FreeBSD)....
--Dave 23:56, 3 Jan 2006 (EST)
Checking Environment Variables
Note to self: checking the environment variable TCPREMOTEINFO is a better way to check for authenticated SMTP, but qsheff doesn't pass that along - you'd need to wrap BEFORE qsheff, not after, in order to pick up on that. Which is beginning to beg the point of using qsheff at all... here is a complete list of environment variables present when qmail-queue is run:
TCPLOCALPORT=2525 USER=yourmom SSH_CLIENT='24.168.100.50 3295 22' MACHTYPE=i386 MAIL=/var/mail/mom TCPREMOTEIP=70.150.138.10 VENDOR=intel SHLVL=2 HOME=/root PROTO=TCP SSH_TTY=/dev/ttyp0 PAGER=more PS1='$ ' OPTIND=1 PS2='> ' GROUP=wheel LOGNAME=mom TERM=xterm BLOCKSIZE=K TCPREMOTEPORT=1935 PPID=92605 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin REMOTEHOST=24.168.100.50 TCPLOCALIP=66.154.114.98 SHELL=/bin/csh HOST=blackbox.tehinterweb.net IFS=' ' OSTYPE=FreeBSD TCPLOCALHOST=mail.jrssystems.net PWD=/home/mom TCPREMOTEINFO=jim@jrssystems.net SSH_CONNECTION='24.168.100.50 3295 66.154.114.98 22' FTP_PASSIVE_MODE=YES HOSTTYPE=FreeBSD EDITOR=vi
No black magic. So - ditch qsheff entirely and simply wrap qmail-queue itself?
ENVs to particularly note: TCPREMOTEINFO, TCPREMOTEIP
Final note for the night: don't see why not do my own standalone wrapper; mail got delivered fine while I was piping environment variables to a text file and piping STDIN to qmail-queue just now. No black magic a'tall, I don't know why wrapping qmail-queue wasn't seeming to work for me the last time I tried it; maybe I just didn't have the permissions set so that my wrapper would execute then?
--Jimbo 02:58, 21 Feb 2006 (EST)
