A better option is a passive logging server where it doesn't have an IP but
a promiscuous network interface that will snarf all of the packets going to
a bogus syslog server. That way the intruder wouldn't even know the machine
existed.
And if you're really paranoid you could always have the log
> I personally like to send my logs to the standard local log file and
> I also forward them to a remote syslog machine.
>
> I use this as a backup in case of the syslog machine being down.
Little known feature of syslog: it will send to multiple machines,
particularly easy with syslog-ng. Just
On Aug 3, 2006, at 8:10 PM, John Summerfied wrote:
What I reas reply for tho, is to say that you _can_ make your log
server
bullet-proof.
It doesn't have to accept any traffic other than incoming log packets
(and you could export the logs themselves using nfs, read-only.
Crack that without phys
Dominic Coulombe wrote:
I personally like to send my logs to the standard local log file and
I also forward them to a remote syslog machine.
I use this as a backup in case of the syslog machine being down. Of
course I have to destroy local logs after some time, but I like the
safety net it give
I personally like to send my logs to the standard local log file and
I also forward them to a remote syslog machine.
I use this as a backup in case of the syslog machine being down. Of
course I have to destroy local logs after some time, but I like the
safety net it gives me.
As you say, a hack
Thomas Kern wrote:
This sounds like a good idea for another linux appliance. A centralized
logging and log-analysis server could be a nice drop-in appliance for a
fledgling penguin network. One spot to accumulate logs, rotate logs,
analyze logs and archive logs. Sounds much better than having to
Alan Altmark wrote:
On Thursday, 08/03/2006 at 09:56 AST, David Boyes <[EMAIL PROTECTED]>
wrote:
As I understand it, SMTP is a store-and-forward proposition, Since
some
MUAs (and in particular the mail command) cannot handle failure, then
the MTA _must_ accept the initial submission.
No,
On Thursday, 08/03/2006 at 03:58 AST, David Boyes <[EMAIL PROTECTED]>
wrote:
> The applicable paragraph is in section 3.7:
[snip]
> So, I'd argue that 4.5.4.2 doesn't apply to the situation we're
> discussing.
Good enough for me! ;-)
Alan Altmark
z/VM Development
IBM Endicott
> You know, I was as positive as you are until I read what RFC 2821
(4.5.4.1
> Sending Strategies) has to say:
>"In a typical system, the program that composes a message has some
> method for requesting immediate attention for a new piece of outgoing
> mail, while mail that cannot be transmitte
On Thursday, 08/03/2006 at 09:56 AST, David Boyes <[EMAIL PROTECTED]>
wrote:
> > As I understand it, SMTP is a store-and-forward proposition, Since
> some
> > MUAs (and in particular the mail command) cannot handle failure, then
> > the MTA _must_ accept the initial submission.
>
> No, it doesn't *
server for its own log storage, rotation, anaysis and
archival.
/Tom Kern
/301-903-2211
>From: David Boyes <[EMAIL PROTECTED]>
>Subject: Re: Small Mail Transport Agent
>
> Which is why I use a central logging host, and do all the logging
> produced by clients to t
> > The command exits with a non-zero return code, and the application
> > invoking it is required to cope with the error and try a different
> > method of signaling a problem. If it doesn't cope, the message is
lost.
>
> Goodbye system logs. cron runs stuff like this:
> 2>&1 | mail ...
No argum
David Boyes wrote:
Bear in mind that the mail command isbasically a wrapper for sendmail
when used thus:
echo some messages | mail -s 'some mail' [EMAIL PROTECTED]
If [EMAIL PROTECTED] cannot he reached immediately, where does the mail
go?
The command exits with a non-zero return code, and t
> Bear in mind that the mail command isbasically a wrapper for sendmail
> when used thus:
>
> echo some messages | mail -s 'some mail' [EMAIL PROTECTED]
>
> If [EMAIL PROTECTED] cannot he reached immediately, where does the mail
go?
The command exits with a non-zero return code, and the applicat
David Boyes wrote:
You _must_ flush the queue because if you don't, and there is a
delivery
problem, mail will be queued.
Umm, no. If properly set up, queuing does *not* occur in non-daemon
mode. That's the whole point of NOT running the MTA as a daemon. There
isn't anything there to queue
Thanks to everyone for the help with my request. What I have decided
on (at least for the time being) is to install Postfix on the guests I'm
interested in and run it instead of sendmail. I can get that done with a
series of short, easy-to-document steps, whereas sendmail wasn't cooper
> You _must_ flush the queue because if you don't, and there is a
delivery
> problem, mail will be queued.
Umm, no. If properly set up, queuing does *not* occur in non-daemon
mode. That's the whole point of NOT running the MTA as a daemon. There
isn't anything there to queue anything. If immediate
David Boyes wrote:
I'm not so much interested in using an email client for
composing,
sending, and receiving email as I am in having a standardized MTA that
programs such as Tripwire, Logwatch, Nagios, and Hobbit can use for
alerts
and exceptional conditions. What I would like is
> I'm not so much interested in using an email client for
composing,
> sending, and receiving email as I am in having a standardized MTA that
> programs such as Tripwire, Logwatch, Nagios, and Hobbit can use for
alerts
> and exceptional conditions. What I would like is for them to send
their
Postfix is what I am trying right now. I have gotten one guest working
with it, but I have another which is refusing to cooperate; I'm thinking of
upgrading the version of postfix to match the one that works.
Jon
For that purpose, I use postfix listening only on the localhost.
It was
I'm not so much interested in using an email client for composing,
sending, and receiving email as I am in having a standardized MTA that programs
such as Tripwire, Logwatch, Nagios, and Hobbit can use for alerts and
exceptional conditions. What I would like is for them to send their me
Adam Thornton wrote:
On Jul 29, 2006, at 4:17 PM, Alan Cox wrote:
Ar Sad, 2006-07-29 am 14:54 -0700, ysgrifennodd Adam Thornton:
I somehow don't think that putting a thick coat of M4-flavored makeup
on the pig actually makes the pig much more attractive.
Why not ? It works for mustard. It
Alan Cox wrote:
Ar Sad, 2006-07-29 am 14:54 -0700, ysgrifennodd Adam Thornton:
I somehow don't think that putting a thick coat of M4-flavored makeup
on the pig actually makes the pig much more attractive.
Why not ? It works for mustard. It certainly makes it a lot simpler to
generate new con
On Jul 29, 2006, at 4:17 PM, Alan Cox wrote:
Ar Sad, 2006-07-29 am 14:54 -0700, ysgrifennodd Adam Thornton:
I somehow don't think that putting a thick coat of M4-flavored makeup
on the pig actually makes the pig much more attractive.
Why not ? It works for mustard. It certainly makes it a lot
Ar Sad, 2006-07-29 am 14:54 -0700, ysgrifennodd Adam Thornton:
> I somehow don't think that putting a thick coat of M4-flavored makeup
> on the pig actually makes the pig much more attractive.
Why not ? It works for mustard. It certainly makes it a lot simpler to
generate new configuration files.
On Jul 28, 2006, at 8:46 PM, John Summerfield wrote:
but that's not what you should be editing these days.
See /etc/mail/sendmail.mc
I somehow don't think that putting a thick coat of M4-flavored makeup
on the pig actually makes the pig much more attractive.
Adam
-
Adam Thornton wrote:
On Jul 27, 2006, at 5:11 PM, John Summerfied wrote:
And, I disagree with Adam - there's a lot you can configure in
sendmail,
but not much you need to for this purpose: I find sendmail just
working,
for sendimg email on the local LAN whenever I install a RHEL clone
or FC.
On Jul 27, 2006, at 5:11 PM, John Summerfied wrote:
And, I disagree with Adam - there's a lot you can configure in
sendmail,
but not much you need to for this purpose: I find sendmail just
working,
for sendimg email on the local LAN whenever I install a RHEL clone
or FC.
To be frank, sendmail.c
Ar Gwe, 2006-07-28 am 08:12 +0800, ysgrifennodd John Summerfied:
> Doesn't that risk getting mail stuck in the queue if immediate
> delivery's not possible?
It does, unless you sweep the queue from a cron job. At which point you
can decide between the cost of it ending up in swap versus the cost o
McKown, John wrote:
Why not use your Exchange server as the MTA? Configure the Linux email
client to connect to port 25 on the Exchange server's IP address (or
hostname, if you are set up to do that).
We do emails from batch jobs on z/OS. We have a free software called
XMITIP which knows the p
David Boyes wrote:
We are running RHEL4 on these particular guests, and the default
MTA
is sendmail. I would prefer to run something with a smaller memory
footprint if I can; it seems rather pointless to take up much room for
something which will only process a couple of messages per
Adam Thornton wrote:
On Jul 27, 2006, at 11:08 AM, Jon Brock wrote:
I can't think of any reason I would ever need to send any mail
from one of my VM guest to the world outside of our firewall -- I
would always be able to forward it from my Exchange email -- so any
small, efficient, easy to s
: Small Mail Transport Agent
I am planning on starting up TripWire and a couple of other
things on some of my guests, and I want to have them mail their output
to my company email address. It appears that I need an MTA for this
purpose.
We are running RHEL4 on these particular guests
> We are running RHEL4 on these particular guests, and the default
MTA
> is sendmail. I would prefer to run something with a smaller memory
> footprint if I can; it seems rather pointless to take up much room for
> something which will only process a couple of messages per day.
Configure it
For that purpose, I use postfix listening only on the localhost.
It was pretty simple to configure.
On 7/27/06, Jon Brock <[EMAIL PROTECTED]> wrote:
Any suggestions? Or am I heading in the wrong direction
entirely?
Ar Iau, 2006-07-27 am 13:19 -0500, ysgrifennodd McKown, John:
> True, but the MTA does not need to run on the same system as the MUA
> (email client).
Nor does it need to listen to the internet side. This is one reason the
default MTA setup on Red Hat boxes is not to listen to the internet
merely
> -Original Message-
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On
> Behalf Of Jon Brock
> Sent: Thursday, July 27, 2006 1:08 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Small Mail Transport Agent
>
>
> I am planning on starting up TripWire and
On Jul 27, 2006, at 11:08 AM, Jon Brock wrote:
I can't think of any reason I would ever need to send any mail
from one of my VM guest to the world outside of our firewall -- I
would always be able to forward it from my Exchange email -- so any
small, efficient, easy to set up MTA should d
I am planning on starting up TripWire and a couple of other things on
some of my guests, and I want to have them mail their output to my company
email address. It appears that I need an MTA for this purpose.
We are running RHEL4 on these particular guests, and the default MTA i
39 matches
Mail list logo
