qmail Digest 19 Sep 1999 10:00:00 -0000 Issue 764
Topics (messages 30445 through 30472):
Re: US encyrption laws relaxed - way to go Dan!
30445 by: craig.jcb-sc.com
qmail LWQ installation problem - qmail doesn't seem executable
30446 by: Warren 'Llama' Ernst
30447 by: Bryan J. Ischo
30448 by: Bryan J. Ischo
Re: http://pobox.com/~djb/ezmlm.html
30449 by: Mark Thomas
Re: When will qmail back off to the next MX?
30450 by: Strange
30451 by: Racer X
30452 by: Racer X
30453 by: Adam D . McKenna
30464 by: phil.ipal.net
30466 by: phil.ipal.net
Trivial Messages from Qmail
30454 by: Subba Rao
Qmail as a forwarder
30455 by: Julian L. Cardarelli
setuser command not found
30456 by: Subba Rao
30458 by: Russell P. Sutherland
30459 by: Subba Rao
30460 by: James J. Lippard
30461 by: Subba Rao
30462 by: James J. Lippard
30463 by: Subba Rao
Virtual hosts
30457 by: Marek Narkiewicz
Installation Quesiton on Qmail. init.d directory and qmail script file.
30465 by: Mark Thomas
30467 by: Sam
30469 by: Dave Sill
maildir structure
30468 by: LRiva
<> question
30470 by: sean
Re: (Clarification) Installation Quesiton on Qmail. init.d directory and qmail
script file.
30471 by: Mark Thomas
30472 by: Rick Myers
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
>>>http://www.wired.com/news/news/politics/story/21790.html
>>
>> I think that's the article forwarded to this list that I just read
>[...]
>
>That's what I thought when I first saw it posted, but it's a different
>article with a different slant. It is referenced in the one posted tho.
Thanks, I just read that one! Indeed, it's the only one that forthrightly
dealt with *my* big concern, which is, does this mean free software
can include crypto without concern? Answer: no.
(I should have realized the from the other articles, of course, but
didn't really grok the gummint-review requirement as limiting free
software. Mostly I was thinking about how the concern about
proprietary software being wilfully broken by agreement between
the vendor and the gummint to ensure back-door access would make
free-software, i.e. OS, products *that* much more attractive: it's
harder to hide bugs in source code, especially when anyone can read
it.)
tq vm, (burley)
All,
So I'm installing qmail on my RedHat 6 distrubution a la the "Life with
qmail" document, and its going great (I've been doing a little each day all
week) until section 2.8.2 when I am suppposed to type "/usr/local/sbin/qmail
cdb"
Well, I do this, and I get "bash: /usr/local/sbin/qmail: No such file or
directory"
So I do an ls -l and see the qmail entry in /usr/local/sbin is the link to:
"qmail -> /etc/rc.d/init.d/qmail" and its permission is "lrwxrwxrwx"
In checking /etc/rc.d/init.d/, i see that qmail is the executable script
"qmail" frmom the beginning of section 2.8.2, but I can't execute it here
either. It looks like:
[root@lllama init.d]# qmail
bash: qmail: command not found
[root@lllama init.d]# ./qmail
bash: ./qmail: No such file or directory
[root@lllama init.d]# ls
apmd functions inet linuxconf network qmail rusersd smb
syslog
atd gpm innd lpd nfs random rwhod snmpd xfs
core halt keytable named pcmcia routed sendmail sound
ypbind
crond httpd killall netfs portmap rstatd single sshd
See? There is is. qmail. With -rwxr-xr-x permissions.
Can anybody suggest where I should go from here? If I just pretend this step
went ok and keep going, it doesn't even start up. (I'ce reboot to make sure
things are clean-ish). See?
[root@lllama init.d]# /usr/local/sbin/qmail start
bash: /usr/local/sbin/qmail: No such file or directory
Any thoughts anyone?
Virtually,
Warr
[EMAIL PROTECTED]
Warren 'Llama' Ernst wrote:
>
> All,
>
> So I'm installing qmail on my RedHat 6 distrubution a la the "Life with
> qmail" document, and its going great (I've been doing a little each day all
> week) until section 2.8.2 when I am suppposed to type "/usr/local/sbin/qmail
> cdb"
>
> Well, I do this, and I get "bash: /usr/local/sbin/qmail: No such file or
> directory"
>
> So I do an ls -l and see the qmail entry in /usr/local/sbin is the link to:
> "qmail -> /etc/rc.d/init.d/qmail" and its permission is "lrwxrwxrwx"
>
> In checking /etc/rc.d/init.d/, i see that qmail is the executable script
> "qmail" frmom the beginning of section 2.8.2, but I can't execute it here
> either. It looks like:
> [root@lllama init.d]# qmail
> bash: qmail: command not found
> [root@lllama init.d]# ./qmail
> bash: ./qmail: No such file or directory
> [root@lllama init.d]# ls
> apmd functions inet linuxconf network qmail rusersd smb
> syslog
> atd gpm innd lpd nfs random rwhod snmpd xfs
> core halt keytable named pcmcia routed sendmail sound
> ypbind
> crond httpd killall netfs portmap rstatd single sshd
>
> See? There is is. qmail. With -rwxr-xr-x permissions.
>
> Can anybody suggest where I should go from here? If I just pretend this step
> went ok and keep going, it doesn't even start up. (I'ce reboot to make sure
> things are clean-ish). See?
> [root@lllama init.d]# /usr/local/sbin/qmail start
> bash: /usr/local/sbin/qmail: No such file or directory
>
> Any thoughts anyone?
>
> Virtually,
> Warr
> [EMAIL PROTECTED]
Warr,
Check the top line of the qmail file. It will name a program to be run
to process the qmail script. Check to make sure that this program
exists on your
system and is runnable.
For example, if the program is named as:
#!/bin/sh
Make sure that /bin/bash exists and is runnable on your system.
Linux will report "no such file or directory" for a script which names
an
interpreter which does not exist or is not runnable. It's cryptic, I
know.
Someone should fix it :) ...
Best wishes,
Bryan
--
------------------------------------------------------------------------
Bryan Ischo [EMAIL PROTECTED] 1995 Honda VFR750
Yonkers, NY, USA http://www.ischo.com RedHat Linux 6.0
------------------------------------------------------------------------
"Bryan J. Ischo" wrote:
> Warr,
>
> Check the top line of the qmail file. It will name a program to be run
> to process the qmail script. Check to make sure that this program
> exists on your
> system and is runnable.
>
> For example, if the program is named as:
>
> #!/bin/sh
>
> Make sure that /bin/bash exists and is runnable on your system.
>
> Linux will report "no such file or directory" for a script which names
> an
> interpreter which does not exist or is not runnable. It's cryptic, I
> know.
> Someone should fix it :) ...
Sorry everyone, in my haste to get the email out I made a
typographical error ... it should read:
For example, if the program is named as:
#!/bin/sh
Make sure that /bin/sh exists and is runnable on your system.
On Linux it's all /bin/bash anyway. I'd be surprised if Warr's
Linux box didn't have a working /bin/bash, or /bin/sh wasn't
properly linked to /bin/bash, but ... it's an easy thing to check.
Thanks,
Bryan
--
------------------------------------------------------------------------
Bryan Ischo [EMAIL PROTECTED] 1995 Honda VFR750
Yonkers, NY, USA http://www.ischo.com RedHat Linux 6.0
------------------------------------------------------------------------
Hold on a minute! I you said what I think you said, I have a really odd
problem here. I am reading the installation documentation for Qmail 1.03.
All over the document, it says to go read this or that, or download this or
that from the Pobox.com address.
When you double click on this address(or cut and paste it), do you get to
this site, or do you get errors. Http://www.pobox.com/~djb/qmail.html
Because, if you can get there, I have a real funny problem. Because I use
Pobox.com for my mail redirector, and I frequent their site, I just can't
get to ~djb/ under pobox.com.
Please clarify,,
MarkT.
Thanks,
-----Original Message-----
From: Chris Johnson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 18, 1999 2:52 AM
To: Mark Thomas
Cc: [EMAIL PROTECTED]
Subject: Re: http://pobox.com/~djb/ezmlm.html
On Sat, Sep 18, 1999 at 01:54:40AM -0500, Mark Thomas wrote:
> I am trying to setup qmail for the first time. Being a newbie to Linux, I
> need all of the help I can get. I keep seing references to this, but I
> cannot see anything under pobox.com/.
>
> I even got this message after signing up to this mailing list.
> See http://pobox.com/~djb/qmail.html for more information about qmail.
> Please read http://pobox.com/~djb/qmail/faq.html before sending your
> question to the qmail mailing list.
Just follow these instructions literally. Don't try to "see anything under
pobox.com," whatever that might mean. Access the cited URLs, and there you
will
find the desired information.
Chris
On Fri, 17 Sep 1999, Greg Owen wrote:
> But the Xerox servers aren't accepting a connection. The apparent
> accepted connection is a side effect of the Raptor proxy firewall. If that
> firewall wasn't in the way, they'd just refuse connection and qmail would
> back off to the next MX immediately.
What is an "apparent accepted connection?" The connection is accepted
when the TCP handshake completes -- what has not happened is an SMTP
session. The Raptor is then slamming the door post-connection, in the
same manner as a TCP wrapper might. The correct behavior would be to
return a RST rather than do the handshake at all. That the Raptor is
accepting the connect for the MX's IP address is no excuse -- indeed, it's
the problem.
I have verified that Gauntlet does not show this behavior. It's a Raptor
thing (and possibly one of other proxy firewalls that launch each proxy on
all interfaces as if using inetd). Moreover, it could be looked at as a
misconfigured Raptor thing, since Raptor has IP-level packet filters that
could easily be used to drop the inbound packets before they reach the
Raptor's listening application on the "wrong" interface, or (perhaps - I
don't know how fancy that filtering is) RST on the attempted connect.
The Raptor tech we talked with said one has to use the filters to prevent
listening ports from being reached on untrusted interfaces.
> > Tell them to fix their SMTP servers, don't work around their
> > breakage.
>
> If anyone is broken here, its my firewall, not their mail setup. No
> one here LIKES their mail setup, but that doesn't make it broken; it
> conforms with all relevant RFCs that I'm aware of.
Now, THAT I will agree with, mostly. What is broken is the aggregate
setup - one side or the other should be adjusted. If you want an
unreachable MX, then the firewall should not act like a broken mail
server. OTOH, as is often done with Gauntlet, you can have the firewall
accept, proxy the mail service, accept as if it were the primary MX and
then move it along to the real primary.
-M
Michael Brian Scher (MS683/MS3213) Anthropologist, Attorney, Policy Analyst
Mainlining Internet Connectivity for Fun and Profit
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Give me a compiler and a box to run it, and I can move the mail.
> Make it configurable.
ok, i get the point. i would say that it IS configurable in that different
MTA's can handle it however they want. making it configurable at an even
lower level would seem to be a rather difficult project and not something
you could do without at least patching and rebuilding. that is, i don't
think you could just have a simple qmail control file that detailed MX
handling unless all the policies were already built into the source anyway.
i do agree that fallback MX handling is an issue of policy and not function.
> > an RFC would be the ideal way to answer these. doing it "like everyone
else
> > does" isn't valid. doing it "the way sendmail does" is even worse.
>
> Agreed. But in some cases I have found things can work better by
violating
> RFCs. I don't like to distribute software that violates the RFCs, unless
it
> would do so only if the administrator gets to choose to do so, and is
aware
> that such a choice is a violation. I have no qualms about distributing or
> using any software that works that way.
that's fine except in this case there IS no rfc to provide a baseline.
there's "the way sendmail does it", which is in a sense a de facto standard,
but it's only a standard because way back when, Eric Allman made some
decisions about MX handling and for better or worse we're stuck with his
decisions.
> Sticking to standards does have an important purpose. Deviating from them
> should never be done lightly. But it should not be ruled out, either. In
> many cases, such deviations have to be done to fully evaluate a proposed
> change in the standards. And sometimes, old standards are not re-visited
> because de-factor standards born out of deviant usage have established
> themselves and there is no pressure to formalize them when other standards
> work is more pressing.
qmail is deviating from the established standard and handling things its own
way. is it better or right? i don't know, there really hasn't been enough
discussion.
> There is also another saying common in computers and networking,
especially
> in regard to conformance to standards: Be conservative in what you
produce
> and be liberal in what you accept.
>
> I have interpreted that to mean that if something does not conform to the
> standard, but I also don't have to go out of my way to detect and
understand
> what is meant, I _may_ (and some would like this to be _should_) go ahead
> and accept it with the obvious semantics.
the first part i agree with. the second part i'm not so sure about. my
take on it is that programs should be prepared to handle any input.
"handle" does not mean process necessarily, it just means that for any
input, the program should have defined behavior. this means that the
program has a very limited set of inputs and very well defined behaviors.
if the inputs are bad, the program refuses the input.
i do NOT believe that "liberal" means "should attempt to rectify problems
automatically." report the problem, sure, and don't crash because the input
is too big or malformed, but don't attempt to fix the problem. GIGO.
> I don't know of any protocol that specifically says that accepting a
> connection and then summarily dropping it with no output has any
particular
> meaning in that standard. But I would readily classify this as a failure
> not unlike a connection refusal. I recognize this because I happen to
know
> that there are cases where this is unavoidable. One example is that the
> UNIX socket API is a deficient standard for lacking the ability to allow
> user space processes to act on an incoming connection in a way that is
seen
> as a connection refusal.
how fast does it have to be dropped to be "summarily" dropped? 1 second?
5? 30? at what point does the connection become "established, but timed
out, will try later" instead of "connection refused or immediately dropped?"
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
> Now you can just requeue the mail and try again later. If you do, then
> you are presuming that perhaps it will be fixed later on, but before the
> expiration of the mail.
>
> So why not send the mail on to at least the WORKING secondary MX? That
> at least gets it out of your queue, putting the storage burden on whoever
> is supposedly doing queueing service for the crappy server.
part of the problem, for me at least, is that it is impossible to guarantee
that secondary MX's will, in fact, accept mail for the domain they are
supposed to be MX'ing for. i'd rather hold the mail for a couple days in my
queue and deliver it directly to the host than pass it off to a secondary
that may or may not handle it correctly. at least if i pass it directly to
the host i can guarantee that it's his fault if he loses it then, as opposed
to getting a third party involved.
the more i think about this, the more i think that fallback MX records
aren't really necessary anymore. having 3 or 4 fallback MX hosts was nice
10 years ago when mail could be passed in pony express format, eventually
making its way across the country by store-and-forward, when everyone ran
open relays and cooperated to help the mail get through. that really just
isn't the case anymore for a large part of the world.
there is very little reason for most MTAs to pass mail to a secondary MX
host. if it can't be delivered to the primary, it's fairly likely that it
can't be delivered to the secondary either. moreover, today anyway, it's
likely that the secondary will be improperly configured and will refuse to
accept mail for a domain it's supposed to be MX'ing for. further, it's
quite possible that the secondary won't be able to deliver any sooner and
may ultimately take longer to deliver.
> How is it that people won't notice the breakage if the primary mail server
> isn't accepting mail? If the server accepts connections, and then keeps
> closing them, it's not going to get its mail even from then secondary MX.
so why even attempt to pass the mail to the secondary in that case?
ignoring the firewall issue, to qmail it looks like the primary host
accepted a connection and then dropped it abruptly. why should qmail think
the secondary MX will have better luck?
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
On Sat, Sep 18, 1999 at 11:45:23AM -0700, Racer X wrote:
> part of the problem, for me at least, is that it is impossible to guarantee
> that secondary MX's will, in fact, accept mail for the domain they are
> supposed to be MX'ing for. i'd rather hold the mail for a couple days in my
> queue and deliver it directly to the host than pass it off to a secondary
> that may or may not handle it correctly. at least if i pass it directly to
> the host i can guarantee that it's his fault if he loses it then, as opposed
> to getting a third party involved.
That's not your problem though. If they advertise a secondary MX, it should
be configured properly to accept mail. The problem here is really teh
behavior of the raptor firewall. Connections that should be refused or
dropped are being accepted. Raptor should either change this policy or proxy
MX correctly.
--Adam
Racer X wrote:
> ok, i get the point. i would say that it IS configurable in that different
> MTA's can handle it however they want. making it configurable at an even
> lower level would seem to be a rather difficult project and not something
> you could do without at least patching and rebuilding. that is, i don't
> think you could just have a simple qmail control file that detailed MX
> handling unless all the policies were already built into the source anyway.
It really wouldn't be that hard to implement a configurable way to fallback.
One simple boolean would cover a lot of cases, that being whether or not a
dropped connection is to be treated just like a connect that was not made.
More involved configuration would allow choosing discrete behaviour over the
different failure cases, but that may be a bit extreme.
> that's fine except in this case there IS no rfc to provide a baseline.
> there's "the way sendmail does it", which is in a sense a de facto standard,
> but it's only a standard because way back when, Eric Allman made some
> decisions about MX handling and for better or worse we're stuck with his
> decisions.
Then Dan gets to do it however he wants, and for whatever reason he wants.
Which is probably the case as it stands.
It just bugs me when people say a connection refused is a broken server and
a connectiond dropped is not.
> qmail is deviating from the established standard and handling things its own
> way. is it better or right? i don't know, there really hasn't been enough
> discussion.
Well, if we do discuss it, I'd prefer to move the discussion forward to how
the decision will really affect the proper delivery of mail, rather that why
such and such server is a bad server.
> > There is also another saying common in computers and networking,
> especially
> > in regard to conformance to standards: Be conservative in what you
> produce
> > and be liberal in what you accept.
> >
> > I have interpreted that to mean that if something does not conform to the
> > standard, but I also don't have to go out of my way to detect and
> understand
> > what is meant, I _may_ (and some would like this to be _should_) go ahead
> > and accept it with the obvious semantics.
>
> the first part i agree with. the second part i'm not so sure about. my
> take on it is that programs should be prepared to handle any input.
> "handle" does not mean process necessarily, it just means that for any
> input, the program should have defined behavior. this means that the
> program has a very limited set of inputs and very well defined behaviors.
> if the inputs are bad, the program refuses the input.
There should be a defined behaviour for different kinds of failures on the
part of servers being connected to for mail delivery. Most certainly it
should not crash if the connection just gets dropped. The question is what
should be the reasonable range of choices for things it may do.
> i do NOT believe that "liberal" means "should attempt to rectify problems
> automatically." report the problem, sure, and don't crash because the input
> is too big or malformed, but don't attempt to fix the problem. GIGO.
Is a connection refused a problem to be rectified?
Is a connection dropped a problem to be rectified?
> how fast does it have to be dropped to be "summarily" dropped? 1 second?
> 5? 30? at what point does the connection become "established, but timed
> out, will try later" instead of "connection refused or immediately dropped?"
What was in my mind by "summarily dropped" was the receiving server closing
the TCP connection before outputting anything at all. I didn't consider time
to be a factor unless the drop occurs after the point in time in which the
sending server times out due to an idle connection. But the sender will be
doing the connection dropping, so it won't see anything else.
There are a lot of failure scenarios that can occur. Connection refused.
Connection timed out. Various network failures (no route, no interface).
Communications timed out. Communications severed (peer dropped, network
failures, etc). In general I would tend to prefer to treat them all the
same unless there is some compelling reason to do otherwise. Such reasons
can be protocol standards or just a reasonable argument in favor of some
other way to do it.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Racer X wrote:
> part of the problem, for me at least, is that it is impossible to guarantee
> that secondary MX's will, in fact, accept mail for the domain they are
> supposed to be MX'ing for. i'd rather hold the mail for a couple days in my
> queue and deliver it directly to the host than pass it off to a secondary
> that may or may not handle it correctly. at least if i pass it directly to
> the host i can guarantee that it's his fault if he loses it then, as opposed
> to getting a third party involved.
So in all scenarios, you'd prefer to ignore all MX entries but the lowest?
Wouldn't your argument apply equally to every failure scenario?
I see the merit in your argument. I don't see how it distiguishes between
differnet failure scenarios that need to be acted on differently.
> the more i think about this, the more i think that fallback MX records
> aren't really necessary anymore. having 3 or 4 fallback MX hosts was nice
> 10 years ago when mail could be passed in pony express format, eventually
> making its way across the country by store-and-forward, when everyone ran
> open relays and cooperated to help the mail get through. that really just
> isn't the case anymore for a large part of the world.
This is a good point for most servers.
Many people are still running servers on dialups that don't get connected
all the time. I do MX-ing for a couple of them. When they are connected,
it's for a few hours or more at a time, so they will soon get their mail.
It can be argued that they should pick up their mail from my server instead.
But the way it works now works just fine and is the least administrative
burden (I don't have to add all their userids and worry about collisions).
Probably the best counter argument is that the world should see my server
for their domain as the only one, and my server should see their server
as the one. It's a fair argument. I just haven't put it up like that as
I am still thinking about what is the best way to manage more than one
DNS server with different data for the "same" zones.
> there is very little reason for most MTAs to pass mail to a secondary MX
> host. if it can't be delivered to the primary, it's fairly likely that it
> can't be delivered to the secondary either. moreover, today anyway, it's
> likely that the secondary will be improperly configured and will refuse to
> accept mail for a domain it's supposed to be MX'ing for. further, it's
> quite possible that the secondary won't be able to deliver any sooner and
> may ultimately take longer to deliver.
I also find it quite likely these days that the _primary_ is also misconfigured.
It is a fair argument to suggest that an effort be made to ensure reliable
delivery even in the face of the recipient's server's being misconfigured.
I would also suggest that they should remove their secondary MX record if
they don't have a procedure in place to verify that the secondary host is
correctly configured.
OTOH, if we always skip the primary and go only to the last secondary, then
they will be forced to be sure all their servers are up to snuff.
> > How is it that people won't notice the breakage if the primary mail server
> > isn't accepting mail? If the server accepts connections, and then keeps
> > closing them, it's not going to get its mail even from then secondary MX.
>
> so why even attempt to pass the mail to the secondary in that case?
> ignoring the firewall issue, to qmail it looks like the primary host
> accepted a connection and then dropped it abruptly. why should qmail think
> the secondary MX will have better luck?
In some situations, the secondary may have a means to ensure that it can get
connected. Maybe the source IP address is used by the primary to decide.
In other situations, the secondary may not be able to do any better right now,
but it might be able to later on at a time when you cannot even reach either
(for perhaps unrelated reasons).
The set of possibilities is at least large. I just tend to favor the notion
of getting the mail as close to its destination as soon as possible.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
I have installed Qmail on my system and in the process for tweaking it.
The TEST.deliver document says, I should expect to see the following
messages in the SYSLOG.
qmail: new msg 53
qmail: info msg 53: bytes 246 from <me@domain> qp 20345 uid 666
qmail: starting delivery 1: msg 53 to local me@domain
qmail: status: local 1/10 remote 0/20
qmail: delivery 1: success: did_1+0+0/
qmail: status: local 0/10 remote 0/20
qmail: end msg 53
My SYSLOG, however, shows the following messages.
Sep 18 14:27:18 myhost qmail: 937679238.126089 new msg 1756430
Sep 18 14:27:18 myhost qmail: 937679238.127301 info msg 1756430: bytes 772 from <> qp
8948 uid 1011
Sep 18 14:27:18 myhost qmail: 937679238.129305 starting delivery 4: msg 1756430 to
local
[EMAIL PROTECTED]
Sep 18 14:27:18 myhost qmail: 937679238.130491 status: local 1/10 remote 0/20
Sep 18 14:27:18 myhost qmail: 937679238.357111 delivery 4: success: did_1+0+0/
Sep 18 14:27:18 myhost qmail: 937679238.358461 status: local 0/10 remote 0/20
Sep 18 14:27:18 myhost qmail: 937679238.358690 end msg 1756430
My concern is the numbers. For example 53 as opposed to 1756430.
What are the number 937679238.126089?
Can anyone explain this please?
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
|
Dear group,
I was wondering how can I setup Qmail so that it forwards
all incoming mail to another host.. I have a firewall and it would be useful to
have a non-mission-critical mail server acting as the smtp server for our
domain. The other mail machine we have is an exchange box and if it were
attacked we would lose the ability to communicate both internally &
externally.. Any ideas?
Julian
|
I am following the instruction in 10b of the FAQ. When I try the command with
"supervise ......"
I get the message saying,
bash: setuser: command not found
Any idea, which package has the "setuser" command?
THank you in advance for any help.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
* Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]:
> I am following the instruction in 10b of the FAQ. When I try the command with
>"supervise ......"
> I get the message saying,
>
> bash: setuser: command not found
>
> Any idea, which package has the "setuser" command?
It is part of the daemontools 0.53 package.
The newer 0.61 version is completely different
and uses setuidgid.
--
Quist Consulting Email: [EMAIL PROTECTED]
219 Donlea Drive Voice: +1.416.696.7600
Toronto ON M4G 2N1 Fax: +1.416.978.6620
CANADA WWW: http://www.quist.on.ca
What about "accustamp" and "cyclog"?
I can't seem to find them. If they are under different names, what could they be.
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
On Sat, 18 Sep 1999 16:35:43 -0400, Russell P. Sutherland wrote:
>* Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]:
>
>> I am following the instruction in 10b of the FAQ. When I try the command with
>"supervise ......"
>> I get the message saying,
>>
>> bash: setuser: command not found
>>
>> Any idea, which package has the "setuser" command?
>
>It is part of the daemontools 0.53 package.
>The newer 0.61 version is completely different
>and uses setuidgid.
>
>--
>Quist Consulting Email: [EMAIL PROTECTED]
>219 Donlea Drive Voice: +1.416.696.7600
>Toronto ON M4G 2N1 Fax: +1.416.978.6620
>CANADA WWW: http://www.quist.on.ca
>
accustamp is replaced with tai64n, and cyclog has been replaced with
multilog. multilog does timestamps itself, too, so you don't actually
need tai64n.
Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
Unsolicited bulk email charge: $500/message. Don't send me any.
PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
On Sat, 18 Sep 1999, Subba Rao wrote:
> What about "accustamp" and "cyclog"?
> I can't seem to find them. If they are under different names, what could they be.
>
> Thank you in advance.
>
> Subba Rao
> [EMAIL PROTECTED]
> ==============================================================
> Disclaimer - I question and speak for myself.
>
> http://pws.prserv.net/truemax/
> ______________________________________________________________
> On Sat, 18 Sep 1999 16:35:43 -0400, Russell P. Sutherland wrote:
>
> >* Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]:
> >
> >> I am following the instruction in 10b of the FAQ. When I try the command with
>"supervise ......"
> >> I get the message saying,
> >>
> >> bash: setuser: command not found
> >>
> >> Any idea, which package has the "setuser" command?
> >
> >It is part of the daemontools 0.53 package.
> >The newer 0.61 version is completely different
> >and uses setuidgid.
> >
> >--
> >Quist Consulting Email: [EMAIL PROTECTED]
> >219 Donlea Drive Voice: +1.416.696.7600
> >Toronto ON M4G 2N1 Fax: +1.416.978.6620
> >CANADA WWW: http://www.quist.on.ca
> >
>
>
>
>
Thank you. The commands suggested in 10b. rblsmtpd,
should they be executed as root or a qmail account (which one?)?
Thank you once again.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
On Sat, 18 Sep 1999 14:00:02 -0700 (MST), James J. Lippard wrote:
>accustamp is replaced with tai64n, and cyclog has been replaced with
>multilog. multilog does timestamps itself, too, so you don't actually
>need tai64n.
>
>Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
>Unsolicited bulk email charge: $500/message. Don't send me any.
>PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
>
>On Sat, 18 Sep 1999, Subba Rao wrote:
>
>> What about "accustamp" and "cyclog"?
>> I can't seem to find them. If they are under different names, what could they be.
>>
>> Thank you in advance.
>>
>> Subba Rao
>> [EMAIL PROTECTED]
>> ==============================================================
>> Disclaimer - I question and speak for myself.
>>
>> http://pws.prserv.net/truemax/
>> ______________________________________________________________
>> On Sat, 18 Sep 1999 16:35:43 -0400, Russell P. Sutherland wrote:
>>
>> >* Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]:
>> >
>> >> I am following the instruction in 10b of the FAQ. When I try the command with
>"supervise ......"
>> >> I get the message saying,
>> >>
>> >> bash: setuser: command not found
>> >>
>> >> Any idea, which package has the "setuser" command?
>> >
>> >It is part of the daemontools 0.53 package.
>> >The newer 0.61 version is completely different
>> >and uses setuidgid.
>> >
>> >--
>> >Quist Consulting Email: [EMAIL PROTECTED]
>> >219 Donlea Drive Voice: +1.416.696.7600
>> >Toronto ON M4G 2N1 Fax: +1.416.978.6620
>> >CANADA WWW: http://www.quist.on.ca
>> >
>>
>>
>>
>>
>
>
rblsmtpd/qmail-smtpd should be run as user qmaild; that is usually done
using tcpserver.
Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
Unsolicited bulk email charge: $500/message. Don't send me any.
PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
On Sat, 18 Sep 1999, Subba Rao wrote:
> Thank you. The commands suggested in 10b. rblsmtpd,
> should they be executed as root or a qmail account (which one?)?
>
> Thank you once again.
>
> Subba Rao
> [EMAIL PROTECTED]
> ==============================================================
> Disclaimer - I question and speak for myself.
>
> http://pws.prserv.net/truemax/
> ______________________________________________________________
> On Sat, 18 Sep 1999 14:00:02 -0700 (MST), James J. Lippard wrote:
>
> >accustamp is replaced with tai64n, and cyclog has been replaced with
> >multilog. multilog does timestamps itself, too, so you don't actually
> >need tai64n.
> >
> >Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
> >Unsolicited bulk email charge: $500/message. Don't send me any.
> >PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
> >
> >On Sat, 18 Sep 1999, Subba Rao wrote:
> >
> >> What about "accustamp" and "cyclog"?
> >> I can't seem to find them. If they are under different names, what could they be.
> >>
> >> Thank you in advance.
> >>
> >> Subba Rao
> >> [EMAIL PROTECTED]
> >> ==============================================================
> >> Disclaimer - I question and speak for myself.
> >>
> >> http://pws.prserv.net/truemax/
> >> ______________________________________________________________
> >> On Sat, 18 Sep 1999 16:35:43 -0400, Russell P. Sutherland wrote:
> >>
> >> >* Subba Rao ([EMAIL PROTECTED]) [18 Sep 1999 16:25]:
> >> >
> >> >> I am following the instruction in 10b of the FAQ. When I try the command with
>"supervise ......"
> >> >> I get the message saying,
> >> >>
> >> >> bash: setuser: command not found
> >> >>
> >> >> Any idea, which package has the "setuser" command?
> >> >
> >> >It is part of the daemontools 0.53 package.
> >> >The newer 0.61 version is completely different
> >> >and uses setuidgid.
> >> >
> >> >--
> >> >Quist Consulting Email: [EMAIL PROTECTED]
> >> >219 Donlea Drive Voice: +1.416.696.7600
> >> >Toronto ON M4G 2N1 Fax: +1.416.978.6620
> >> >CANADA WWW: http://www.quist.on.ca
> >> >
> >>
> >>
> >>
> >>
> >
> >
>
>
>
>
On Sat, 18 Sep 1999 14:10:21 -0700 (MST), James J. Lippard wrote:
>rblsmtpd/qmail-smtpd should be run as user qmaild; that is usually done
>using tcpserver.
>
>Jim Lippard [EMAIL PROTECTED] http://www.discord.org/
Thanks again for replying. Each time I make progress, I seem to be hitting
a new road block.
The following are the contents of my /var/qmail directory
total 12
drwxr-xr-x 10 root qmail 1024 Sep 18 17:20 ./
drwxr-xr-x 20 root root 1024 Aug 28 17:52 ../
drwxr-sr-x 2 alias qmail 1024 Aug 29 07:03 alias/
drwxr-xr-x 2 root qmail 1024 Aug 28 17:59 bin/
drwxr-xr-x 2 root qmail 1024 Aug 28 17:59 boot/
drwxr-xr-x 2 root qmail 1024 Aug 28 18:00 control/
drwxr-xr-x 2 root qmail 1024 Aug 28 17:59 doc/
-rw-r--r-- 1 root root 0 Sep 18 17:20 list.txt
drwxr-xr-x 10 root qmail 1024 Aug 28 17:59 man/
-rwx------ 1 qmaild qmail 223 Sep 18 17:02 qt*
drwxr-x--- 11 qmailq qmail 1024 Aug 28 17:59 queue/
-rwxr-xr-x 1 root root 204 Aug 30 11:21 rc*
drwxr-xr-x 2 root qmail 1024 Aug 28 17:59 users/
Contents of rc file
===================
#!/bin/sh
# Using splogger to send the log through syslog.
# Using qmail-local to deliver messages to ~/Mailbox by default.
exec env - PATH="/var/qmail/bin:$PATH" \
qmail-start ./Mailbox splogger qmail
Contents of qt file
===================
supervise /var/lock/qmail-smtpd tcpserver -v -x/etc/tcp.smtp.cdb -u71 -g1001 0 25 \
rblsmtpd qmail-smtpd 2>&1 | setuidgid qmaill multilog | \
setuidgid qmaill multilog -s5000000 -n5 /var/log/qmail/qmail-smtpd &
After switching to user qmaild, I ran the "qt" script. After a little while tinkering
with other system,
I executed "qt" again and got the message
"/usr/local/bin/setuidgid: Permission denied"
Do I need to restart the system?
I have also issued the command "telnet localhost 25" and got the following response.
Trying 127.0.0.1
telnet: Unabel to connect to remote host: Connection refused.
I have followed line by line through the spageti documentation (more like basic
programing).
Please let me know where or what I am doing wrong!!
Thank you in advance.
Subba Rao
[EMAIL PROTECTED]
==============================================================
Disclaimer - I question and speak for myself.
http://pws.prserv.net/truemax/
______________________________________________________________
I'm setting up a pop server for remote hosts and as I have a lot of domain names I
need to
use virtual hosts. What should I use for the address in the me file in
/var/qmail/control?
I currently have my IP only in there and my Vhosts are in rcpthosts and virtualhosts
Cheers,
--
Marek Narkiewicz, Webmaster Intercreations
Reply to <-marek @ intercreations . com->
"Ticking away, the moments that make up a dull day"
Pink Floyd
Time
I Have a couple of questions about the qmail install. What I have doesn't
look right to me.
I). I am installing qmail 1.03 from Dave Sill's "Life with Qmail" dated July
21, 1999. I am in section # 2.8.2 System Startup Files, and it says to
install a script file I just created "qmail" to launch qmail at boot into my
init.d directory.
The document says it should be in one of the following locations:
/etc/init.d
/etc/rc.d/init.d
/sbin/init.d
I have no such directory on my system. (Slackware 3.6)
It appears that Slackware uses /etc/rc.d for the initialization files. I
think the qmail script file that will start qmail on boot should be located
here? Can anyone verify this for me?
II). Should I Chmod this file for X execute privledges? The document didn't
say.
III). I looked over the script and it references several files and
subdirectories that don't exist. I have not received any errors in the
install up to this point.
I have attached the script file, and have put directories and files that
don't exist here in (file/dir) (parenthesis)..
case "$1" in
start)
echo -n "Starting qmail: qmail-send"
supervise /var/(supervise)/qmail/send /var/qmail/rc | ****** I don't
have supervise directory
setuser (qmaill) cyclog /var/log/qmail & ****** Is
qmaill a typo, or variable of somekind?
echo -n " qmail-smtpd"
supervise /var/supervise/qmail/smtpd tcpserver -v -x/etc/(tcp.smtp.cdb)
\ ** This file doesn't exist.
-u$QMAILDUID -g$NOFILESGID 0 smtp \
/var/qmail/bin/(qmail-smtpd-wrapper) 2>&1 | setuser qmaill accustamp
| \ ** I have qmail-smtpd but no wrapper.
setuser qmaill cyclog /var/log/qmail/(smtpd &) ***********
I have a qmail-smtpd file here.
I'm a bit confused here!
I am running Slackware 3.6 on Kernel 2.0.35 on a 486/66Dx with 32Meg Ram. I
have two NICS, both setup and working. I can ping local network and
internet by name or IP address. I have the Samba Server 1.9.18p10 running.
Everything working fine.
I am going to continue with the install, and hope I don't hose anything, but
I just don't think its going to work.
ANY COMMENTS WOULD BE GREATLY APPRECIATED.
TIA
MarkT.
qmail
On Sat, 18 Sep 1999, Mark Thomas wrote:
> I Have a couple of questions about the qmail install. What I have doesn't
> look right to me.
>
> I). I am installing qmail 1.03 from Dave Sill's "Life with Qmail" dated July
> 21, 1999. I am in section # 2.8.2 System Startup Files, and it says to
> install a script file I just created "qmail" to launch qmail at boot into my
> init.d directory.
> The document says it should be in one of the following locations:
> /etc/init.d
> /etc/rc.d/init.d
> /sbin/init.d
> I have no such directory on my system. (Slackware 3.6)
> It appears that Slackware uses /etc/rc.d for the initialization files. I
> think the qmail script file that will start qmail on boot should be located
> here? Can anyone verify this for me?
Slackware doesn't use the System V-style init scripts that this
documentation refers to. Slackware uses old-style /etc/rc.d scripts.
What this probably means is that you need to stick your qmail start/stop
script somewhere else, then manually edit by hand the various scripts in
/etc/rc.d to run the qmail start/stop script. Going from memory,
/etc/rc.d/rc.local would be a good place to stick in the start script. I
think /etc/rc.d/rc.shutdown would be a good place to stick in the stop
script, to bring the system down during system shutdown.
In any case, you should read the contents of your /etc/inittab to see
which /etc/rc.d scripts get invoked at which time. Then make appropriate
changes.
Mark Thomas <[EMAIL PROTECTED]> wrote:
>
> I). I am installing qmail 1.03 from Dave Sill's "Life with Qmail" dated July
> 21, 1999. I am in section # 2.8.2 System Startup Files, and it says to
> install a script file I just created "qmail" to launch qmail at boot into my
> init.d directory.
> The document says it should be in one of the following locations:
> /etc/init.d
> /etc/rc.d/init.d
> /sbin/init.d
> I have no such directory on my system. (Slackware 3.6)
LWQ says "should" because it's impossible to cover every possibility.
> It appears that Slackware uses /etc/rc.d for the initialization files. I
> think the qmail script file that will start qmail on boot should be located
> here? Can anyone verify this for me?
What's the structure of /etc/rc.d? What subdirectories does it have?
> II). Should I Chmod this file for X execute privledges? The document didn't
> say.
Yes it does. It says:
Make the startup script executable and link it to a directory in your path:
# substitute the correct location of your rc dir on the next two lines
chmod 755 /etc/init.d/qmail
ln -s /etc/init.d/qmail /usr/local/sbin
This is in section 2.8.2.
> III). I looked over the script and it references several files and
> subdirectories that don't exist. I have not received any errors in the
> install up to this point.
At the completion of section 2.8.2, all necessary files and directories will
be there.
> I have attached the script file, and have put directories and files that
> don't exist here in (file/dir) (parenthesis)..
>
> case "$1" in
> start)
> echo -n "Starting qmail: qmail-send"
> supervise /var/(supervise)/qmail/send /var/qmail/rc | ****** I don't
> have supervise directory
Created later in 2.8.2.
> setuser (qmaill) cyclog /var/log/qmail & ****** Is
> qmaill a typo, or variable of somekind?
qmaill is a user (in /etc/passwd) which you should have set up in 2.5.4.
> supervise /var/supervise/qmail/smtpd tcpserver -v -x/etc/(tcp.smtp.cdb)
> \ ** This file doesn't exist.
Created later in 2.8.2.
> -u$QMAILDUID -g$NOFILESGID 0 smtp \
> /var/qmail/bin/(qmail-smtpd-wrapper) 2>&1 | setuser qmaill accustamp
> | \ ** I have qmail-smtpd but no wrapper.
Created later in 2.8.2.
> setuser qmaill cyclog /var/log/qmail/(smtpd &) ***********
> I have a qmail-smtpd file here.
Are you sure about that? LWQ certainly doesn't create a qmail-smtpd file
under /var/log/qmail.
> I am going to continue with the install, and hope I don't hose anything, but
> I just don't think its going to work.
>
> ANY COMMENTS WOULD BE GREATLY APPRECIATED.
It's probably a good idea to read through the entire Installation section
before attempting one's first installation. I'll add a note to that effect.
-Dave
Hello.
I have two rather stupid questions as I'm a newbie with Qmail.
I've just installed Qmail and set it to use maildir-like mailboxes.
The question is:
Mutt ask me to specify a file to use as spool mailbox: how should I set this ?
What are the function of the /tmp and /cur maildir subdirectories ?
Excuse me if they're RTFM, but I didn't found the answers in the manuals...
bye,
Lorenzo
Hello,
I use qmail and have noticed that the vast majority of spam that comes
through is from <>
Is there an a means by which I can reject mail from <> or is there any
problems associated with this?
Thank you,
First Time poster / Sean
Thanks for your reply, you are correct at all points.
We all appreciate the time you guys spend documenting these things for the
community. I chose your document because I have little or no Linux
experience (1Week), and the INSTALL and FAQ documents were a bit above my
head. Thanks for your HOWTO!
I have included some info on my Slackware file structure. It may help
clarify the document for Slackware users. qmail-start-stop-script.txt and
support files of the /etc/rc.d directory. rc.local-Startup file and
rc.0-stop script.
I also have some issues with the links, since the rc.? are files and not
directories.
I appreciate your help.
Mark Thomas.
See Below: ((((((---->>>>
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Dave Sill
Sent: Saturday, September 18, 1999 1:27 PM
To: [EMAIL PROTECTED]
Cc: Mark Thomas
Subject: Re: Installation Quesiton on Qmail. init.d directory and qmail
script file.
Mark Thomas <[EMAIL PROTECTED]> wrote:
>
> I). I am installing qmail 1.03 from Dave Sill's "Life with Qmail" dated
July
> 21, 1999. I am in section # 2.8.2 System Startup Files, and it says to
> install a script file I just created "qmail" to launch qmail at boot into
my
> init.d directory.
> The document says it should be in one of the following locations:
> /etc/init.d
> /etc/rc.d/init.d
> /sbin/init.d
> I have no such directory on my system. (Slackware 3.6)
LWQ says "should" because it's impossible to cover every possibility.
((((((---->>>> I attached a text file with info about the rc.d directory
((((((---->>>> structure on Slackware. Please review!
> It appears that Slackware uses /etc/rc.d for the initialization files. I
> think the qmail script file that will start qmail on boot should be
located
> here? Can anyone verify this for me?
What's the structure of /etc/rc.d? What subdirectories does it have?
((((((---->>>> Structure included in the text file with info from above.
> setuser (qmaill) cyclog /var/log/qmail & ****** Is
> qmaill a typo, or variable of somekind?
qmaill is a user (in /etc/passwd) which you should have set up in 2.5.4.
((((((---->>>> Yes, it was. I cut and pasted the text and didn't notice the
extra ((((((---->>>> character, in qmail(l)
> setuser qmaill cyclog /var/log/qmail/(smtpd &) ***********
> I have a qmail-smtpd file here.
Are you sure about that? LWQ certainly doesn't create a qmail-smtpd file
under /var/log/qmail.
((((((---->>>> Right again-> I guess I was just about frazzeled here! <g>
It's probably a good idea to read through the entire Installation section
before attempting one's first installation. I'll add a note to that effect.
((((((---->>>> All except whats left could have been answered if I
((((((---->>>> would have read the entire section prior to the sections
install.
((((((---->>>> MarkT.
inittab
rc.0
rc.local
**********************************************************************
Would it be appropriate to add the:
"qmail start" somewhere in the rc.local script (bottom section of file)?
"qmail stop" somewhere in the rc.0 or rc.6 local script (top section)?
ALSO:
Creating links at the bottom of 2.8.2:
ln -s ../init.d/qmail RCDIR/rc0.d/K30qmail
ln -s ../init.d/qmail RCDIR/rc1.d/K30qmail
ln -s ../init.d/qmail RCDIR/rc2.d/K30qmail
ln -s ../init.d/qmail RCDIR/rc3.d/K30qmail
ln -s ../init.d/qmail RCDIR/rc4.d/K30qmail
ln -s ../init.d/qmail RCDIR/rc5.d/K30qmail
ln -s ../init.d/qmail RCDIR/rc6.d/K30qmail
With Slackware:
ln -s /etc/rc.d/qmail /etc/rc.d/rc.0 (K30qmail)
rc.0,4,6,K,N, and S are files.
Do I need to manually enter some data in the rc.? files, or create some files in a
location for the links?
***********************************************************************
--------------------------------------------------------------------------------
If Sendmail is currently installed, running the command
"find RCDIR -name "*sendmail" -print" will give you numbers
that should work for your system.
I tried this also, the only files I have on my system that fit the
*sendmail criteria was sendmail, setup.sendmail and REMOVE.sendmail.
--------------------------------------------------------------------------------
**I received this reply from my previous post. It gives some info on Slackware.
Slackware doesn't use the System V-style init scripts that this
documentation refers to. Slackware uses old-style /etc/rc.d scripts.
What this probably means is that you need to stick your qmail start/stop script
somewhere else, then manually edit by hand the various scripts in /etc/rc.d to run the
qmail start/stop script.
Going from memory, /etc/rc.d/rc.local would be a good place to stick in the start
script.
I think /etc/rc.d/rc.shutdown would be a good place to stick in the stop script, to
bring the system down during system shutdown.
In any case, you should read the contents of your /etc/inittab to see
which /etc/rc.d scripts get invoked at which time. Then make appropriate changes.
---------------------------------------------------------------------
I found this documentation on Slackwares site: There are other files that I didn't
list here, you can see them at the bottom.
http://www.slackware.com/config/init.shtml
Slackware Linux uses the BSD-style file layout for its system initialization files.
These files are organized and easy to edit. All of the system initialization files are
stored in the /etc/rc.d directory. To prevent a script from executing at startup you
can remove the execute permission on the file and Slackware will not execute it.
rc.6 (also called rc.0)
This file is run when you shutdown or reboot the system. It unmounts all devices and
stops daemons before rebooting or halting.
rc.local
Local system initialization script. You can add to this file to execute something at
the end of the boot process.
-----------------------------------------------------------------------
Here is the directory structure under /etc/rc.d
drwxr-xr-x 11 root root 3072 Sep 18 19:52 ../
-rwxr-xr-x 1 root root 2804 Sep 18 13:43 qmail*
drwxr-xr-x 2 root root 1024 Sep 18 13:25 ./
-rwxr-xr-x 1 root root 2387 Sep 18 13:25 #rc.6#*
-rwxr-xr-x 1 root root 2336 Sep 15 03:44 rc.inet1*
-rwxr-xr-x 1 root root 933 Sep 12 21:57 rc.local*
-rwxr-xr-x 1 root root 122 Sep 12 21:51 rc.font*
-rwxr-xr-x 1 root root 3139 Sep 12 21:37 rc.inet2*
-rwxr-xr-x 1 root root 158 Sep 12 21:37 rc.samba*
-rwxr-xr-x 1 root root 946 Sep 12 21:37 rc.atalk*
-rwxr-xr-x 1 root root 37 Sep 12 21:37 rc.httpd*
-rwxr-xr-x 1 root root 9059 Sep 12 21:35 rc.serial*
-rwxr-xr-x 1 root root 2376 Sep 12 21:35 rc.6*
-rwxr-xr-x 1 root root 1244 Sep 12 21:35 rc.K*
-rwxr-xr-x 1 root root 3770 Sep 12 21:35 rc.M*
-rwxr-xr-x 1 root root 5453 Sep 12 21:35 rc.S*
-rw-r--r-- 1 root root 2239 Sep 12 21:35 rc.cdrom
-rwxr-xr-x 1 root root 396 Sep 12 21:35 rc.4*
lrwxrwxrwx 1 root root 4 Sep 12 21:35 rc.0 -> rc.6*
-rwxr-xr-x 1 root root 4000 Sep 12 21:35 rc.pcmcia*
-rwxr-xr-x 1 root root 64 Sep 12 21:35 rc.ibcs2*
-rwxr-xr-x 1 root root 9669 Sep 12 16:06 rc.modules*
darkstar:/etc/rc.d#
On Sep 19, 1999 at 03:09:18 -0500, Mark Thomas twiddled the keys to say:
> Would it be appropriate to add the:
> "qmail start" somewhere in the rc.local script (bottom section of file)?
That would work, but the proper place is in rc.M just below where you
comment out the original sendmail startup.
> "qmail stop" somewhere in the rc.0 or rc.6 local script (top section)?
That would go in rc.6, and again in rc.K, both at the top before the
original script kills all processes. (BTW, rc.0 should already be a
symlink to rc.6.)
> ALSO:
> Creating links at the bottom of 2.8.2:
> ln -s ../init.d/qmail RCDIR/rc0.d/K30qmail
> ln -s ../init.d/qmail RCDIR/rc1.d/K30qmail
> ln -s ../init.d/qmail RCDIR/rc2.d/K30qmail
> ln -s ../init.d/qmail RCDIR/rc3.d/K30qmail
> ln -s ../init.d/qmail RCDIR/rc4.d/K30qmail
> ln -s ../init.d/qmail RCDIR/rc5.d/K30qmail
> ln -s ../init.d/qmail RCDIR/rc6.d/K30qmail
This is for the new style init. I doubt seriously you get anything but
error messages if you attempt this.
> With Slackware:
> ln -s /etc/rc.d/qmail /etc/rc.d/rc.0 (K30qmail)
> rc.0,4,6,K,N, and S are files.
> Do I need to manually enter some data in the rc.? files, or create some files in a
>location for the links?
Edit as mentioned above. Forget the symlink, it'll break your shutdown.
> darkstar:/etc/rc.d#
You should give your system it's own hostname. ;-)
Rick Myers [EMAIL PROTECTED]
----------------------------------------------------
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
