freebsd-questions Digest, Vol 304, Issue 11
freebsd-ques...@freebsd.org
freebsd-...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
or, via email, send a message with subject or body 'help' to
freebsd-ques...@freebsd.org
You can reach the person managing the list at
freebsd-que...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-questions digest..."
Today's Topics:
1. Re: Sendmail Five Second Greeting Delay (David Allen)
2. Re: Sendmail Five Second Greeting Delay (Jon Radel)
3. Combining SSL certificates (Jerry)
4. what means: route: writing to routing socket: No such process
? (Matthias Apitz)
5. Re: Compiling kernel with gcc43 [SOLVED] (Mario Lobo)
6. Re: Sendmail Five Second Greeting Delay (Norbert Papke)
7. Re: Sendmail Five Second Greeting Delay (David Allen)
8. Re: Combining SSL certificates (Adam Vande More)
9. Re: Sendmail Five Second Greeting Delay (Jon Radel)
10. Re: Compiling kernel with gcc43 [SOLVED] -ADDENDUM (Mario Lobo)
11. Freebsd-update issues (Graeme Dargie)
12. Re: Combining SSL certificates (Matthew Seaman)
13. Re: Sendmail Five Second Greeting Delay (Matthew Seaman)
14. Re: Sendmail Five Second Greeting Delay (Matthew Seaman)
15. Re: Sendmail Five Second Greeting Delay (Lowell Gilbert)
16. Re: skype webcam no device found (Paul Procacci)
17. Re: skype webcam no device found (Programmer In Training)
18. Re: Fwd: mkuzip and/or geom_uzip changes? - SOLVED (Tim Judd)
19. Re: Sendmail Five Second Greeting Delay (per...@pluto.rain.com)
20. make delete-old question (removing old binaries)
(Ihsan Junaidi Ibrahim)
21. IPFW and Fail2Ban (Carmel NY)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Apr 2010 04:33:09 -0800
From: David Allen <the.real.d...@gmail.com>
Subject: Re: Sendmail Five Second Greeting Delay
To: Matthew Seaman <m.se...@infracaninophile.co.uk>
Cc: freebsd-...@freebsd.org
Message-ID:
<p2y2daa8b4e1004020533u1...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/1/10, Matthew Seaman wrote:
>
> On 02/04/2010 01:51:27, Norbert Papke wrote:
>> When I connect to sendmail on a local interface, sendmail responds to the
>> connection with its "220" greeting immediately. If I connect to sendmail
>> from
>> another machine on my (home) LAN, sendmail delays five seconds before
>> sending
>> the greeting. I would like it to respond immediately.
>
>> A quick search turned up a "greet_delay" feature in sendmail that would
>> cause
>> this type of behavior. To the best of my knowledge, I do not use this
>> feature. Just to be sure, I tried to explicitly enable it with both a
>> default
>> 0 second timeout and an explicit 0 second access rule. This did not the
>> resolve the issue.
>
> For the sake of the archives, I'd like to note that the `greet_pause'
> feature is actually a pretty effective and very cheap to implement
> anti-spam measure. You need:
>
> FEATURE(greet_pause, `5000')dnl ## 5 seconds
>
> in your $(hostname).mc file -- this gives you a default 5 second delay.
> If you also have
>
> FEATURE(`access_db')
>
> you can override that value for particular IP ranges or domain names.
>
> This is also a handy addition to the .mc file:
>
> LOCAL_RULESETS
> SLocal_greet_pause
> R$* $: $&{daemon_flags}
> R$* a $* $# 0
>
> This turns off greet_pause on network ports where authentication is
> required, ie. if you use port 587 for submitting new mail and reserve
> port 25 for MTA to MTA mail transfers.
>
> The way this works is that it requires the sending side to wait until
> your system prints out the greeting banner. If the sending side starts
> speaking before then, sendmail will refuse to accept any mail during
> that session. All real MTAs will get this right, as it is part of the
> SMTP specification in the RFCs. Many spambots on the other hand, send
> e-mail by simply replaying one side of a recorded SMTP conversation
> without reguard for what the other side says. This feature weeds out
> that sort of spambot with very little effort.
Useful reading. Two questions ...
First, I'm wondering what is logged as a result of using greet_pause when
getting slammed by a bot. Is it something along the lines of "User did
not issue...", "LA LA LA I wasn't listening", or nothing at all?
Secondly, it seems the cause of the OP's problem was a delay associated
with an IDENT query. Specificially
confTO_IDENT Timeout.ident [5s] The timeout waiting for a
response to an IDENT query.
If he had local DNS configured, there would be no query, and therefore no
issue, but setting the timeout to 0 seconds using
define(`confTO_IDENT', 0s)
does remove the delay, but not the underlying problem.
Put another way, I'm wondering why IDENT queries are made? My knowledge
of that protocol is superficial, but my understanding is that running an
identity service is widely considered a security problem. FreeBSD doesn't
run identd by default, for example, but it's possible that some Linux
distros do. The Wikipedia article suggests "It's an IRC thing", but that
doesn't address the default sendmail behavior.
Thanks.
------------------------------
Message: 2
Date: Fri, 02 Apr 2010 10:12:33 -0400
From: Jon Radel <j...@radel.com>
Subject: Re: Sendmail Five Second Greeting Delay
To: freebsd-...@freebsd.org
Message-ID: <4BB5FB5...@radel.com>
Content-Type: text/plain; charset="iso-8859-1"
On 4/2/10 8:33 AM, David Allen wrote:
> Secondly, it seems the cause of the OP's problem was a delay associated
> with an IDENT query. Specificially
>
> confTO_IDENT Timeout.ident [5s] The timeout waiting for a
> response to an IDENT query.
>
> If he had local DNS configured, there would be no query, and therefore no
> issue, but setting the timeout to 0 seconds using
>
> define(`confTO_IDENT', 0s)
>
> does remove the delay, but not the underlying problem.
You sure? IDENT has nothing to do with DNS, and I don't know of any
program that does an IDENT query solely if DNS data is not available. I
can't see why that would make any sense.
What is most likely the OP's root problem is that he's sending e-mail
from a machine that's on the other side of a firewall that blocks IDENT
traffic but doesn't actively reject it. So sendmail has to sit around
and wait for the query to time out.
This is why there's a school of thought that even if your default for
firewall configuration is to quietly drop unwanted packets, IDENT is a
protocol that you should actively reject. It makes things move along
more quickly.
>
> Put another way, I'm wondering why IDENT queries are made? My knowledge
> of that protocol is superficial, but my understanding is that running an
> identity service is widely considered a security problem. FreeBSD doesn't
> run identd by default, for example, but it's possible that some Linux
> distros do. The Wikipedia article suggests "It's an IRC thing", but that
> doesn't address the default sendmail behavior.
Things can make more sense when you realize that TCP/IP networks have
changed over the years. Long ago, when dinosaurs roamed the earth, and
timesharing servers were big things with professional admins and lots of
users, it could be helpful to know that if you got an irritating
connection from the Math Dept. server using source port X, and IDENT
said the owner of the process that was using port X was a user called
Jimbob, that you could go to the admin of that server and tell him to
slap Jimbob upside the head. After all, if his IDENT server had been
subverted, he would have mentioned it when you had a beer with him last
night.
These days, when so much traffic comes from individual workstations
where the user can frequently arrange for an IDENT server to return any
fool information they want, if they have it running at all, the value
added is much less.
Do remember that some of these things date from back when Linus was
still in diapers (well, actually, he was about 15 when the earliest RFC
with the genesis of IDENT was published), so trying to figure out why
they make sense based solely on what Linux does can be futile. ;-)
--
--Jon Radel
j...@radel.com
------------------------------
Message: 3
Date: Fri, 2 Apr 2010 11:04:30 -0400
From: Jerry <freebs...@seibercom.net>
Subject: Combining SSL certificates
To: freebsd-...@freebsd.org
Message-ID: <20100402110...@scorpio.seibercom.net>
Content-Type: text/plain; charset=UTF-8
Is it possible to combine all of the certificates in a chain into one
*.pem file?
EXAMPLE:
openssl s_client -connect imap.gmail.com:993 -crlf -showcerts
This would show, in this case anyway, two certificates. Could I combine
both certs into on file, example: gmail-imap.pem and then run
'c_rehash' on the file or do I have to save both certs in separate
files to complete the chain?
--
Jerry
FreeBS...@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________
------------------------------
Message: 4
Date: Fri, 2 Apr 2010 17:07:00 +0200
From: Matthias Apitz <gu...@unixarea.de>
Subject: what means: route: writing to routing socket: No such process
?
To: freebsd-...@freebsd.org
Message-ID: <2010040215...@current.Sisis.de>
Content-Type: text/plain; charset=iso-8859-1
Hello,
It seems that deleting a route which does not exist gives some message
about "writing to routing socket: No such process":
# route delete xxx.xxx.xxx.xxx/27
delete net xxx.xxx.xxx.xxx
# route delete xxx.xxx.xxx.xxx/27
route: writing to routing socket: No such process
delete net xxx.xxx.xxx.xxx: not in table
The man page does not explain this. What does this mean exactly? Thanks
matthias
--
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@unixarea.de> - w http://www.unixarea.de/
Solidarity with the imperialistic Israel? Not in my name!
¿Solidaridad con el imperialismo de Israel? ¡No en mi nombre!
------------------------------
Message: 5
Date: Fri, 2 Apr 2010 12:39:44 +0000
From: Mario Lobo <lo...@bsd.com.br>
Subject: Re: Compiling kernel with gcc43 [SOLVED]
To: Pegasus Mc Cleaft <k...@mthelicon.com>
Cc: freebsd...@freebsd.org, FreeBSD-...@freebsd.org
Message-ID: <20100402123...@bsd.com.br>
Content-Type: Text/Plain; charset="iso-8859-1"
On Thursday 01 April 2010 16:53:36 Pegasus Mc Cleaft wrote:
> On Thursday 01 April 2010 15:27:41 Oliver Fromme wrote:
> > Mario Lobo <lo...@bsd.com.br> wrote:
> > > [...]
> > > It's compiling right now.
> > >
> > > I'll post my findings and impressions on results and performance right
> > > after the next reboot.
> >
> > So, how is it going? Any benchmarks yet? I'm curious
> > if the new gcc version will really make a significant
> > difference.
>
> I would love to see the /etc/make.conf, /etc/src.conf and
> /etc/libmap.conf files that were used for the build. I have tried compiling
> in VBox a current kernel and world, but it usually just bombs out for me.
> I would like to give this a go as well.
>
> Peg
>
Well, to tell the truth I wasn't that thrilled with the results. I didn't
benchmark anything by my impressions were that at least disk access was a bit
slower not only during booting but it was more noticeable to me particularly
on a burning DVD session. Of course this is ultra abstract.
In all previous experiences I had in burning CD/DVD with k3b, I recollect that
during burning, the software buffer and device buffer gouges were always 100%,
with the software buffer gouge dropping down occasionally to 89/92%.
After recompiling the kernel with gcc43, the software buffer was always empty
and the device buffer rarely reached 40/50%. I think (if not mistaken) this
means that the device is asking "where is my data??" and the OS is not
providing it fast enough.
I could not get world to build with gcc43 so I gave that up. Then I moved on
to VirtualBox. I managed to have it compiled and running. After long trial and
error sessions, I could pin point what was breaking compilation and fixed it.
Here are the steps:
------------------------------------------------------------------------------
Compiling vbox/vbox-devel with gcc43
1) /usr/include/cam/cam.h needed #include <stdio.h> for FILE define,
complained by:
work/VirtualBox-3.1.51.r27657_OSE/src/VBox/Main/freebsd/HostHardwareFreeBSD.cpp:47:
/usr/include/cam/cam.h:246: error: 'FILE' has not been declared
2)/usr/ports/emulators/virtualbox-
ose/work/VirtualBox-3.1.6_OSE/src/VBox/Main/generic/NetIf-generic.cpp
needed #include <stdio.h> because of popen() (this step is ONLY for
virtualbox-ose)
3)/usr/ports/emulators/virtualbox-ose(-
devel)/work/VirtualBox-3.1.6_OSE/src/VBox/Main/freebsd/NetIf-freebsd.cpp
needed #include <stdlib.h> because of malloc()/free()
4) Config.kmk needed some tweaks:
a) line 1750 - $(APPEND) '$@' 'VBOX_GCC_mtune-generic ?= $(call
VBOX_GCC_CHECK_CC,-mtune=amdfam10 -D__FreeBSD_cc_version=0,)'
to use instructions closer to Phenom and avoid cc complains.
b) took out all references to "-fformat-extensions" and "-fno_format-
extensions"
c) Preceeded all relevant locations of "/usr/lib \" with
"/usr/local/lib/gcc43 \" so kbuild searched there for libraries first.
(except TEMPLATE_VBOXQT4GUIEXE_LIBPATH !)
d) You can use the same Config.kmk for building kmods as well
5) took out -fformat-extensions from src/sys/conf/kern.mk
And I left /etc/libmap.conf
libgcc_s.so.1 gcc43/libgcc_s.so.1
libgomp.so.1 gcc43/libgomp.so.1
libobjc.so.3 gcc43/libobjc.so.2
libssp.so.0 gcc43/libssp.so.0
libstdc++.so.6 gcc43/libstdc++.so.6
/etc/make.conf
CC=/usr/local/bin/gcc43
CXX=/usr/local/bin/g++43
CPP=/usr/local/bin/cpp43
CFLAGS+=-mssse3 -D__FreeBSD_cc_version=0
CXXFLAGS+=-D__FreeBSD_cc_version=0
CPUTYPE=amdfam10
#MAKEOPTS+= -j4
and /etc/src.conf
NO_WERROR=
WERROR=
------------------------------------------------------------------------------
New problems started to come when I tried to extend this to other ports,
breaking a lot of them, to point of making me revert everything back to what
it was. In fact I am still in this process right now, and reving a lot of
problems to rebuild kde4.
This is it for now, guys. If you find anything new, please post.
Best of luck,
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winfoes FREE)
------------------------------
Message: 6
Date: Fri, 2 Apr 2010 08:48:45 -0700
From: Norbert Papke <npa...@acm.org>
Subject: Re: Sendmail Five Second Greeting Delay
To: freebsd-...@freebsd.org
Message-ID: <201004020848...@acm.org>
Content-Type: Text/Plain; charset="us-ascii"
On April 2, 2010, Jon Radel wrote:
> On 4/2/10 8:33 AM, David Allen wrote:
> > Secondly, it seems the cause of the OP's problem was a delay associated
> > with an IDENT query. Specificially
> >
> > confTO_IDENT Timeout.ident [5s] The timeout waiting for a
> > response to an IDENT query.
> >
> > If he had local DNS configured, there would be no query, and therefore no
> > issue, but setting the timeout to 0 seconds using
> >
> > define(`confTO_IDENT', 0s)
> >
> > does remove the delay, but not the underlying problem.
>
> You sure? IDENT has nothing to do with DNS, and I don't know of any
> program that does an IDENT query solely if DNS data is not available. I
> can't see why that would make any sense.
>
> What is most likely the OP's root problem is that he's sending e-mail
> from a machine that's on the other side of a firewall that blocks IDENT
> traffic but doesn't actively reject it. So sendmail has to sit around
> and wait for the query to time out.
Allow me to clarify the scenario. The intent is for a local Windows box to
relay outgoing SMTP through the FreeBSD box. Both machines are on the same
LAN segment. No intervening Firewalls (except software firewalls on the boxes).
Without the IDENT timeout, this is the traffic.
FreeBSD box on 172.16.0.3, Windows box on 172.16.0.11.
No. Time Source Destination Protocol Info
10844 18.153005 172.16.0.11 172.16.0.3 TCP 55100 > smtp [SYN] Seq=0 Win=8192 Len=0
MSS=1460
10845 18.153031 172.16.0.3 172.16.0.11 TCP smtp > 55100 [SYN, ACK] Seq=0 Ack=1 Win=65535
Len=0 MSS=1460
10846 18.153306 172.16.0.11 172.16.0.3 TCP 55100 > smtp [ACK] Seq=1 Ack=1 Win=64240 Len=0
10847 18.153944 172.16.0.3 172.16.0.254 DNS Standard query PTR 11.0.16.172.in-addr.arpa
10849 18.163505 172.16.0.254 172.16.0.3 DNS Standard query response PTR
tiggr.lan.provenpath.ca
10850 18.163690 172.16.0.3 172.16.0.254 DNS Standard query PTR 3.0.16.172.in-addr.arpa
10856 18.173804 172.16.0.254 172.16.0.3 DNS Standard query response PTR
proven.lan.provenpath.ca
10857 18.173943 172.16.0.3 172.16.0.254 DNS Standard query A tiggr.lan.provenpath.ca
10860 18.176306 172.16.0.254 172.16.0.3 DNS Standard query response A 172.16.0.11
10861 18.176532 172.16.0.3 172.16.0.11 TCP 57889 > ident [SYN] Seq=0 Win=65535 Len=0
MSS=1460 WS=3 TSV=142487140 TSER=0
12402 21.156922 172.16.0.3 172.16.0.11 TCP 57889 > ident [SYN] Seq=0 Win=65535 Len=0
MSS=1460 WS=3 TSV=142490140 TSER=0
13637 23.145692 172.16.0.3 172.16.0.11 SMTP S: 220 proven.lan.provenpath.ca ESMTP Sendmail
8.14.4/8.14.4; Fri, 2 Apr 2010 08:26:47 -0700 (PDT)
13741 23.337234 172.16.0.11 172.16.0.3 TCP 55100 > smtp [ACK] Seq=1 Ack=98 Win=64143
Len=0
Basically, sendmail performs and IDENT even though the DNS lookup seems to have
succeeded. The Windows box does not reject the IDENT.
Cheers,
-- Norbert Papke.
npa...@acm.org
------------------------------
Message: 7
Date: Fri, 2 Apr 2010 07:49:10 -0800
From: David Allen <the.real.d...@gmail.com>
Subject: Re: Sendmail Five Second Greeting Delay
To: Jon Radel <j...@radel.com>
Cc: freebsd-...@freebsd.org
Message-ID:
<g2m2daa8b4e1004020849j6...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/2/10, Jon Radel <j...@radel.com> wrote:
> On 4/2/10 8:33 AM, David Allen wrote:
>
>> Secondly, it seems the cause of the OP's problem was a delay associated
>> with an IDENT query. Specificially
>>
>> confTO_IDENT Timeout.ident [5s] The timeout waiting for a
>> response to an IDENT query.
>>
>> If he had local DNS configured, there would be no query, and therefore no
>> issue, but setting the timeout to 0 seconds using
>>
>> define(`confTO_IDENT', 0s)
>>
>> does remove the delay, but not the underlying problem.
>
> You sure? IDENT has nothing to do with DNS, and I don't know of any
> program that does an IDENT query solely if DNS data is not available. I
> can't see why that would make any sense.
Well, I'm sure that on a network with functional DNS, sendmail sends
no IDENT queries. And by extension, there are no delays due to
timeouts of unaswered queries .
> What is most likely the OP's root problem is that he's sending e-mail
> from a machine that's on the other side of a firewall that blocks IDENT
> traffic but doesn't actively reject it. So sendmail has to sit around
> and wait for the query to time out.
That much I get, but the question is why sendmail, by default sends
those queries?
> This is why there's a school of thought that even if your default for
> firewall configuration is to quietly drop unwanted packets, IDENT is a
> protocol that you should actively reject. It makes things move along
> more quickly.
Fair enough. But that reasoning is based on a premise that IDENT is
widely depended upon (and implicitly widely used), yes?
>> Put another way, I'm wondering why IDENT queries are made? My knowledge
>> of that protocol is superficial, but my understanding is that running an
>> identity service is widely considered a security problem. FreeBSD doesn't
>> run identd by default, for example, but it's possible that some Linux
>> distros do. The Wikipedia article suggests "It's an IRC thing", but that
>> doesn't address the default sendmail behavior.
>
> Things can make more sense when you realize that TCP/IP networks have
> changed over the years. Long ago, when dinosaurs roamed the earth, and
> timesharing servers were big things with professional admins and lots of
> users, it could be helpful to know that if you got an irritating
> connection from the Math Dept. server using source port X, and IDENT
> said the owner of the process that was using port X was a user called
> Jimbob, that you could go to the admin of that server and tell him to
> slap Jimbob upside the head. After all, if his IDENT server had been
> subverted, he would have mentioned it when you had a beer with him last
> night.
>
> These days, when so much traffic comes from individual workstations
> where the user can frequently arrange for an IDENT server to return any
> fool information they want, if they have it running at all, the value
> added is much less.
>
> Do remember that some of these things date from back when Linus was
> still in diapers (well, actually, he was about 15 when the earliest RFC
> with the genesis of IDENT was published), so trying to figure out why
> they make sense based solely on what Linux does can be futile. ;-)
Interesting reading. Thanks for elaborating.
So the IDENT protocol was relied on in the time of the dinosaurs, it's
value today is "so much less" (a polite way of saying "not used at
all"?), and IDENT packets are commonly dropped by firewalls. Do I
have that right? If so, then a reasonable conclusion is that the
default sendmail behaviour with respect to IDENT (sending queries and
then waiting for a reply) is an anachronism. And the workaround
(setting a timeout of zero) is a fix for that anachronism. Should I
consider those two points as "features", or should I just get off your
lawn before I get yelled at? ;-)
--
David
Off to reconfigure the firewall not to silently drop port 113 traffic.
And 70 and 79, just in case.
------------------------------
Message: 8
Date: Fri, 2 Apr 2010 10:19:02 -0600
From: Adam Vande More <amvan...@gmail.com>
Subject: Re: Combining SSL certificates
To: freebsd-...@freebsd.org
Message-ID:
<z2r6201873e1004020919o1...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Apr 2, 2010 at 9:04 AM, Jerry <freebs...@seibercom.net> wrote:
> Is it possible to combine all of the certificates in a chain into one
> *.pem file?
>
> EXAMPLE:
>
> openssl s_client -connect imap.gmail.com:993 -crlf -showcerts
>
> This would show, in this case anyway, two certificates. Could I combine
> both certs into on file, example: gmail-imap.pem and then run
> 'c_rehash' on the file or do I have to save both certs in separate
> files to complete the chain?
>
Doesn't it work to simply concatenate pem's together? I was my
understanding it was possible to do that, but perhaps order of concatenation
matters. So make sure you're dealing with pem's and cat together with root
being last and I think it should work.
--
Adam Vande More
------------------------------
Message: 9
Date: Fri, 02 Apr 2010 12:46:24 -0400
From: Jon Radel <j...@radel.com>
Subject: Re: Sendmail Five Second Greeting Delay
To: David Allen <the.real.d...@gmail.com>
Cc: freebsd-...@freebsd.org
Message-ID: <4BB61F60...@radel.com>
Content-Type: text/plain; charset="iso-8859-1"
On 4/2/10 11:49 AM, David Allen wrote:
>
> On 4/2/10, Jon Radel<j...@radel.com> wrote:
>> On 4/2/10 8:33 AM, David Allen wrote:
>>
>>> Secondly, it seems the cause of the OP's problem was a delay associated
>>> with an IDENT query. Specificially
>>>
>>> confTO_IDENT Timeout.ident [5s] The timeout waiting for a
>>> response to an IDENT query.
>>>
>>> If he had local DNS configured, there would be no query, and therefore no
>>> issue, but setting the timeout to 0 seconds using
>>>
>>> define(`confTO_IDENT', 0s)
>>>
>>> does remove the delay, but not the underlying problem.
>>
>> You sure? IDENT has nothing to do with DNS, and I don't know of any
>> program that does an IDENT query solely if DNS data is not available. I
>> can't see why that would make any sense.
>
> Well, I'm sure that on a network with functional DNS, sendmail sends
> no IDENT queries. And by extension, there are no delays due to
> timeouts of unaswered queries .
Very odd. Why on earth would that be the case?
>
>> What is most likely the OP's root problem is that he's sending e-mail
>> from a machine that's on the other side of a firewall that blocks IDENT
>> traffic but doesn't actively reject it. So sendmail has to sit around
>> and wait for the query to time out.
>
> That much I get, but the question is why sendmail, by default sends
> those queries?
Historical reasons. So that you know, when bad mail is sent to you from
the Math Dept. server by Jimbob playing around with his own SMTP
program, whom to yell at. (See below for references.)
Please don't make out like I'm advocating as this being of much utility
these days; I'm not. You can find all sorts of recommendations to turn
this off if you look around.
>
>> This is why there's a school of thought that even if your default for
>> firewall configuration is to quietly drop unwanted packets, IDENT is a
>> protocol that you should actively reject. It makes things move along
>> more quickly.
>
> Fair enough. But that reasoning is based on a premise that IDENT is
> widely depended upon (and implicitly widely used), yes?
It's still deployed enough to result in tedious discussions, such as
this one, coming up fairly frequently. None of this is a problem until
you have people who drop ident packets *and* get upset that there are
servers out there that wait for a timeout.
And just think, we could be in the bad old days, when you *had* to wait
for the IP stack to timeout and sendmail didn't have a handy place to
set the timeout to a short value.
To paraphrase: One of the underlying rules of getting along on the
Internet is to be strict in what you send and forgiving in what you
accept. So do something sensible with IDENT requests or expect odd
delays, and don't waste time wondering why there are still servers out
there that do things that don't really make a lot of sense anymore.
>
>>> Put another way, I'm wondering why IDENT queries are made? My knowledge
>>> of that protocol is superficial, but my understanding is that running an
>>> identity service is widely considered a security problem. FreeBSD doesn't
>>> run identd by default, for example, but it's possible that some Linux
>>> distros do. The Wikipedia article suggests "It's an IRC thing", but that
>>> doesn't address the default sendmail behavior.
>>
>> Things can make more sense when you realize that TCP/IP networks have
>> changed over the years. Long ago, when dinosaurs roamed the earth, and
>> timesharing servers were big things with professional admins and lots of
>> users, it could be helpful to know that if you got an irritating
>> connection from the Math Dept. server using source port X, and IDENT
>> said the owner of the process that was using port X was a user called
>> Jimbob, that you could go to the admin of that server and tell him to
>> slap Jimbob upside the head. After all, if his IDENT server had been
>> subverted, he would have mentioned it when you had a beer with him last
>> night.
>>
>> These days, when so much traffic comes from individual workstations
>> where the user can frequently arrange for an IDENT server to return any
>> fool information they want, if they have it running at all, the value
>> added is much less.
>>
>> Do remember that some of these things date from back when Linus was
>> still in diapers (well, actually, he was about 15 when the earliest RFC
>> with the genesis of IDENT was published), so trying to figure out why
>> they make sense based solely on what Linux does can be futile. ;-)
>
> Interesting reading. Thanks for elaborating.
>
> So the IDENT protocol was relied on in the time of the dinosaurs, it's
> value today is "so much less" (a polite way of saying "not used at
> all"?), and IDENT packets are commonly dropped by firewalls. Do I
> have that right?
Yes, except for the "not used at all" bit.
> If so, then a reasonable conclusion is that the
> default sendmail behaviour with respect to IDENT (sending queries and
> then waiting for a reply) is an anachronism. And the workaround
> (setting a timeout of zero) is a fix for that anachronism. Should I
> consider those two points as "features", or should I just get off your
> lawn before I get yelled at? ;-)
>
People who get all bent out of shape about 5 second delays in e-mail
delivery deserve to suffer, therefore I personally think the default
behavior is fine the way it is. But as I said, you can find many
sendmail "cookbooks" on the Internet that recommend that you set it to 0
sec and get on with your life.
Or you could just set all your firewalls to reject the traffic with much
the same end result.
--
--Jon Radel
j...@radel.com
------------------------------
Message: 10
Date: Fri, 2 Apr 2010 13:47:43 +0000
From: Mario Lobo <lo...@bsd.com.br>
Subject: Re: Compiling kernel with gcc43 [SOLVED] -ADDENDUM
To: Pegasus Mc Cleaft <k...@mthelicon.com>
Cc: freebsd...@freebsd.org, FreeBSD-...@freebsd.org
Message-ID: <20100402134...@bsd.com.br>
Content-Type: Text/Plain; charset="iso-8859-1"
Well, to tell the truth I wasn't that thrilled with the results. I didn't
[snip]
------------------------------------------------------------------------------
Compiling vbox/vbox-devel with gcc43
1) /usr/include/cam/cam.h needed #include <stdio.h> for FILE define,
complained by:
[snip]
and /etc/src.conf
NO_WERROR=
WERROR=
------------------------------------------------------------------------------
New problems started to come when I tried to extend this to other ports,
[snip]
You have to:
1) make patch
2) apply the mods
3) make
Best of luck, again
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winfoes FREE)
------------------------------
Message: 11
Date: Fri, 2 Apr 2010 18:01:49 +0100
From: "Graeme Dargie" <ar...@tangerine-army.co.uk>
Subject: Freebsd-update issues
To: <freebsd-...@freebsd.org>
Message-ID:
<01FB8F39BAD0BD49A6D...@Mercury.galaxy.lan.lcl>
Content-Type: text/plain; charset="us-ascii"
Hello All
I have an issue with freebsd-update, I will back track a few steps to
give you some background as to what I was doing prior to using
freebsd-update.
I have been trying to get half-life dedicated server working on one of
my machines, seemed to install ok from games/linux-steam but on running
it would crash then hang the machine.
After a bit of digging about it was suggested that I needed to modify
the kernel to have the CPU_ENABLE_SSE option it seemed to go through #
make buildkernel KERNCONF=MYKERNEL ok but then went belly up make
installkernel KERNCONF=MYKERNEL failed. I re-read the man page, and
tried again today, for it to fail at the buildkernel stage saying
CPU_ENABLE_SSE was not an valid option. So I thought ok I will just
rebuild the generic kernel using the above steps. That worked fine,
system rebooted and from what I can tell works as it should.
Now on to the issue, doing freebsd-update fetch works ok, but the inital
run of the freebsd-update install complained about lack of disk space,
looking in to /boot there was a 230mb folder called GENERIC, I checked
my other two machines and this was not present of either, so I moved the
folder out of /boot and re-ran freebsd-update install now it complains
that /boot/GENERIC is missing.
I`ll freely confess to not knowing much about this kind of thing but to
me it looks like freebsd-update thinks my kernel is /boot/GENERIC and
not /boot/KERNEL
Anyone know what I have done wrong and how to fix this ? if anyone out
there knows how to get HLDS working that would be a great help as well
eris# uname -a
FreeBSD eris.galaxy.lan.lcl 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Apr
2 16:14:18 BST 2010
gra...@eris.galaxy.lan.lcl:/usr/obj/usr/src/sys/ERISGEN amd64
eris# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/mirror/gm0s1a 496M 270M 186M 59% /
devfs 1.0K 1.0K 0B 100% /dev
Regards
Graeme
------------------------------
Message: 12
Date: Fri, 02 Apr 2010 18:34:35 +0100
From: Matthew Seaman <m.se...@infracaninophile.co.uk>
Subject: Re: Combining SSL certificates
To: Adam Vande More <amvan...@gmail.com>
Cc: freebsd-...@freebsd.org
Message-ID: <4BB62AAB...@infracaninophile.co.uk>
Content-Type: text/plain; charset=UTF-8
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/04/2010 17:19:02, Adam Vande More wrote:
> On Fri, Apr 2, 2010 at 9:04 AM, Jerry <freebs...@seibercom.net> wrote:
>
>> Is it possible to combine all of the certificates in a chain into one
>> *.pem file?
>>
>> EXAMPLE:
>>
>> openssl s_client -connect imap.gmail.com:993 -crlf -showcerts
>>
>> This would show, in this case anyway, two certificates. Could I combine
>> both certs into on file, example: gmail-imap.pem and then run
>> 'c_rehash' on the file or do I have to save both certs in separate
>> files to complete the chain?
>>
>
> Doesn't it work to simply concatenate pem's together? I was my
> understanding it was possible to do that, but perhaps order of concatenation
> matters. So make sure you're dealing with pem's and cat together with root
> being last and I think it should work.
Depends on the application I think. Some applications like SSL key and
cert in the same file. Some applications want them separate. Some
applications like SSL Certs and all of the CA-Cert keys used to sign it
concatenated together; others like separate files for CA-Certs; yet
others only want CA Certs which aren't from one of the well-known root CAs.
Can't say as I've ever run into an app that likes several different keys
or certs in the same file [well, except for Java keystores, but in that
case the appropriate response is to scream and run away very quickly]
You pays your money, and you takes your choice.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku2KqsACgkQ8Mjk52CukIzvPACfSvTA+XgWmJF0Fl6g36y5UJPc
U0oAn0lmHLo1FUdzMV/Tj4DmZ7JqTJ13
=U+kz
-----END PGP SIGNATURE-----
------------------------------
Message: 13
Date: Fri, 02 Apr 2010 18:37:38 +0100
From: Matthew Seaman <m.se...@infracaninophile.co.uk>
Subject: Re: Sendmail Five Second Greeting Delay
To: Jon Radel <j...@radel.com>
Cc: freebsd-...@freebsd.org
Message-ID: <4BB62B62...@infracaninophile.co.uk>
Content-Type: text/plain; charset=UTF-8
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/04/2010 15:12:33, Jon Radel wrote:
> This is why there's a school of thought that even if your default for
> firewall configuration is to quietly drop unwanted packets, IDENT is a
> protocol that you should actively reject. It makes things move along
> more quickly.
That, and the fact that the ident protocol is utterly pointless -- it's
trivially easy for a server to lie about the owner of the other end of a
TCP connection. In fact, doing that is a standard part of the
functionality of identd implementations. Just a waste of packets.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku2K2IACgkQ8Mjk52CukIyriQCfWZc/AzYIS/38IVFScCG6jkYb
tTMAoItnWUk1g2ClDTR/CWMk47lTdj1B
=WYGc
-----END PGP SIGNATURE-----
------------------------------
Message: 14
Date: Fri, 02 Apr 2010 18:50:21 +0100
From: Matthew Seaman <m.se...@infracaninophile.co.uk>
Subject: Re: Sendmail Five Second Greeting Delay
To: David Allen <the.real.d...@gmail.com>
Cc: freebsd-...@freebsd.org
Message-ID: <4BB62E5D...@infracaninophile.co.uk>
Content-Type: text/plain; charset=UTF-8
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/04/2010 13:33:09, David Allen wrote:
> Secondly, it seems the cause of the OP's problem was a delay associated
> with an IDENT query. Specificially
>
> confTO_IDENT Timeout.ident [5s] The timeout waiting for a
> response to an IDENT query.
>
> If he had local DNS configured, there would be no query, and therefore no
> issue, but setting the timeout to 0 seconds using
Ident queries like this will cause a delay if the other side doesn't
respond respond to the ident query. That's typical behaviour for most
machines that run firewalls nowadays. Given that ident is broken as
designed (see rant in other post) turning it off is a good idea in my book.
Note that the 5s delay produced by ident-flail doesn't prevent ultimate
delivery of the message. FEATURE('greet_pause', ...) does when the
other side is rude enough not to play by the rules.
As far as I know, the ident protocol doesn't depend on the availability
of DNS -- mind you, SMTP really really does depend on working DNS, so it
would be pretty broken anyhow.
> define(`confTO_IDENT', 0s)
>
> does remove the delay, but not the underlying problem.
Should disable use of the ident protocol with sendmail.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku2Ll0ACgkQ8Mjk52CukIybUQCfUS1juVDpbmEVuZ1K9LhZGiBo
PxwAoJSXWMl0wPqIx/co7cNjp2dNXyoU
=+PB0
-----END PGP SIGNATURE-----
------------------------------
Message: 15
Date: Fri, 02 Apr 2010 14:13:08 -0400
From: Lowell Gilbert <freebsd-que...@be-well.ilk.org>
Subject: Re: Sendmail Five Second Greeting Delay
To: Matthew Seaman <m.se...@infracaninophile.co.uk>
Cc: freebsd-...@freebsd.org, David Allen
<the.real.d...@gmail.com>
Message-ID: <44iq89l...@be-well.ilk.org>
Content-Type: text/plain; charset=us-ascii
Matthew Seaman <m.se...@infracaninophile.co.uk> writes:
> Ident queries like this will cause a delay if the other side doesn't
> respond respond to the ident query. That's typical behaviour for most
> machines that run firewalls nowadays. Given that ident is broken as
> designed (see rant in other post) turning it off is a good idea in my book.
I consider it polite for firewalls to actively refuse to open the
connection (TCP reset) rather than just dropping the request, though.
There's really no downside to doing so.
--
Lowell Gilbert, embedded/networking software engineer, Boston area
http://be-well.ilk.org/~lowell/
------------------------------
Message: 16
Date: Sat, 3 Apr 2010 03:41:53 +0000 (UTC)
From: Paul Procacci <ppro...@gmail.com>
Subject: Re: skype webcam no device found
To: freebsd-...@freebsd.org
Message-ID: <loom.201004...@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
I'm in the same boat as you. I just finished installing video4bsd + webcamd +
skype, and skype isn't able to detect the webcam, while pwcview works fine.
Anyone have any thoughts on the matter?
------------------------------
Message: 17
Date: Fri, 02 Apr 2010 23:15:32 -0500
From: Programmer In Training <p...@joseph-a-nagy-jr.us>
Subject: Re: skype webcam no device found
To: freebsd-...@freebsd.org
Message-ID: <4BB6C0E4...@joseph-a-nagy-jr.us>
Content-Type: text/plain; charset="utf-8"
On 04/02/10 22:41, Paul Procacci wrote:
>
>
> I'm in the same boat as you. I just finished installing video4bsd + webcamd +
> skype, and skype isn't able to detect the webcam, while pwcview works fine.
>
> Anyone have any thoughts on the matter?
>
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>
Wait, you just finished installing Skype? From where? The port is broken
because the package isn't retrievable. Do you have a copy you'd be
willing to share (you can send it directly to my email address, I have
no (known) limits and no box quotas).
--
Yours In Christ,
PIT
Emails are not formal business letters, whatever businesses may want.
Original content copyright under the OWL http://owl.apotheon.org
Please do not CC me. If I'm posting to a list it is because I am subscribed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100403/9751da97/signature-0001.pgp
------------------------------
Message: 18
Date: Sat, 3 Apr 2010 02:02:36 -0600
From: Tim Judd <taj...@gmail.com>
Subject: Re: Fwd: mkuzip and/or geom_uzip changes? - SOLVED
To: John Baldwin <j...@freebsd.org>
Cc: freebsd...@freebsd.org, freebsd-...@freebsd.org
Message-ID:
<k2tade45ae91004030102m9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/1/10, Tim Judd <taj...@gmail.com> wrote:
> On 4/1/10, Tim Judd <taj...@gmail.com> wrote:
>> On 4/1/10, John Baldwin <j...@freebsd.org> wrote:
>>> On Wednesday 31 March 2010 6:32:09 pm Tim Judd wrote:
>>>> Hi All,
>>>>
>>>> Just starting to see if I can find other reports. You all probably
>>>> have had the "more than one pair of eyes looking at a thing is better
>>>> than my eyes alone." This is why I'm writing now, as I'm starting the
>>>> discovery.
>>>>
>>>> Let me background this a little bit. I only started looking into this
>>>> because mkuzip and it's counterpart, geom_uzip are throwing errors on
>>>> FreeBSD8 i386
>>>>
>>>>
>>>> scenario (/etc/src.conf in effect, removing *LOTS* of stuff with
>>>> knobs):
>>>> make DESTDIR=/home/small8 installworld installkernel distribution
>>>> mv /home/small8/boot /home/small8-boot/
>>>> makefs -t ffs /home/small8/usr.img /home/small8/usr/
>>>> mkuzip -o /home/small8/usr.uzip /home/small8/usr.img
>>>> [*]
>>>> chflags -R noschg /home/small8/usr/*
>>>> rm -rf /home/small8/usr/* /home/small8/usr.img
>>>> ee /home/small8/etc/rc.d/mountcritlocal
>>>> [**]
>>>> makefs -t ffs /home/small8-boot/mfsroot /home/small8/
>>>> gzip --best /home/small8-boot/mfsroot
>>>> ee /home/small8-boot/boot/loader.conf
>>>> [***]
>>>> rm /home/small8-boot/boot/kernel/*.symbols
>>>> gzip --best /home/small8-boot/boot/kernel/kernel
>>>> mkisofs -U -J -r -V "FreeBSD8" -b boot/cdboot -no-emul-boot
>>>> -iso-level 4 -o /home/small8.iso /home/small8-boot/
>>>>
>>>>
>>>> [*]: mkuzip inserts a script header that is broken. module name it's
>>>> searching for may have been renamed?
>>>> [**]: Edited mountcritlocal to mount the usr.uzip file as by using the
>>>> above script header, throws errors
>>>> [***]: added zlib and geom_uzip modules to load to the boot image, to
>>>> satisfy the script header's requirements.
>>>>
>>>> OK, the above scenario creates about a 33MB usr.uzip, and a 68MB iso.
>>>> Small enough to apparently fit into the undocumented 50 or 100MB size
>>>> limit of mfs_root module
>>>
>>> BTW, you can raise this limit by changing NKPT.
>>>
>>>> The problem:
>>>> mkuzip generates a few lines as a script in the head of the
>>>> resulting *.uzip file. Two problems...
>>>> 1) the module it queries for is geom_uzip (kldstat -m $m), but
>>>> FreeBSD8 names the geom_uzip module (i guess, internally) as g_uzip.
>>>> mkuzip's generated image will never find the module if they're not
>>>> named the same.
>>>
>>> It is g_uzip even in 7:
>>>
>>> DECLARE_GEOM_CLASS(g_uzip_class, g_uzip);
>>> MODULE_DEPEND(g_uzip, zlib, 1, 1, 1);
>>>
>>> This has probably just been broken from the start. If it used 'kldstat
>>> -n'
>>> then it might work. Well, it probably works (modulo a warning) by
>>> accident
>>> as
>>> it doesn't hurt to kldload an already-loaded module. Note though that
>>> it
>>> assumes the raw usr.img is an ISO image, not a UFS filesystem.
>>>
>>>> 2) even with geom_uzip module and it's dependency zlib loaded, i don't
>>>> get a mdconfig node '/dev/md?.uzip' to appear.
>>>>
>>>> It's been forever since I touched uzip, so I have to ask.
>>>
>>> Do you have a md0 device at all? I think you want to hack the script to
>>> do
>>> something like this:
>>>
>>> disk=`mdconfig -af /path/to/usr.img`
>>> mount -r /dev/$disk.uzip /usr
>>>
>>> --
>>> John Baldwin
>>>
>>
>>
>>
>> booted single-user
>> md0 is the mfs_root
>>
>> here is the manual attachment of an mdconfig...
>> # mdconfig -af /usr.uzip
>> WARNING: opening backing store: /usr.uzip readonly
>> md1.uzip: block size (24) should be a multiple of 512.
>> md1
>> # ls /dev/md1*
>> /dev/md1
>> #
>>
>
> Forgot the kldstat, which was obviously omitted
>
> # kldstat
> Id Refs Address Size Name
> 1 5 0xc0400000 b6e060 kernel
> 2 1 0xc0f6f000 3ffc geom_uzip.ko
> 3 2 -xc0f73000 ac20 zlib.ko
>
John, All:
Don't spend any more time on this issue as a show-stopper anymore. I
understand what was going on enough to realize that the middle line,
rather than a warning, was an outright error and the md?.uzip device
cannot be presented.
When I was trying to diagnose my cascading problems, one of the items
I did was to edit (with ee) the usr.uzip binary file. I only used the
cursor in the script header part, saved it and tried it out.
Evidentally, that screwed the file up.
Recreating the .img, converting to a .uzip is working.
I'm back on track, no need to continue to search this.
enjoy!
------------------------------
Message: 19
Date: Sat, 03 Apr 2010 00:59:54 -0700
From: per...@pluto.rain.com
Subject: Re: Sendmail Five Second Greeting Delay
To: m.se...@infracaninophile.co.uk,
freebsd-que...@be-well.ilk.org
Cc: freebsd-...@freebsd.org
Message-ID: <4bb6f57a.wld7n7exwvUX7+a9%per...@pluto.rain.com>
Content-Type: text/plain; charset=us-ascii
Lowell Gilbert <freebsd-que...@be-well.ilk.org> wrote:
> Matthew Seaman <m.se...@infracaninophile.co.uk> writes:
> > Ident queries like this will cause a delay if the other side
> > doesn't respond respond to the ident query ...
> I consider it polite for firewalls to actively refuse to open
> the connection (TCP reset) rather than just dropping the request,
> though. There's really no downside to doing so.
Other than giving port-scanners an affirmative indication that
there is a device of some sort at the IP address involved.
Some firewalls even drop pings for exactly this reason.
If the request comes from an address to which I've recently*
initiated a connection -- so he already knows that my address
is currently alive -- I ought to either respond per protocol
or reset. If it comes from who-knows-where, it may be safer
to drop it.
The ident protocol is useful for the purpose for which it was
designed: to pass "whom to blame" info between servers which have
reason to trust one another's identity (based on, e.g., stable IP
addresses) and administration. Granted the circumstances in which
these conditions are met are a lot less prevalent than they once
were.
* for some resonable definition of recently
------------------------------
Message: 20
Date: Sat, 3 Apr 2010 18:04:37 +0800
From: Ihsan Junaidi Ibrahim <ihsan....@gmail.com>
Subject: make delete-old question (removing old binaries)
To: freebsd-...@freebsd.org
Message-ID:
<n2i829875541004030304w9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi folks,
I've rebuild my world with NO_MAIL (in src.conf) and a few other NO_
options however I noticed that related binaries are not removed
entirely i.e. mailwrapper when I ran make delete-old /
delete-old-libs. I can see that the old binaries have a timestamp
older than the binaries rebuilt by the make world process.
[anggerik:/usr/sbin]# ls -l mailwrapper
-r-xr-xr-x 1 root wheel 7808 Nov 21 22:31 mailwrapper
[anggerik:/usr/sbin]# ls -l trac
traceroute* traceroute6*
[anggerik:/usr/sbin]# ls -l traceroute
-r-sr-xr-x 1 root wheel 28240 Apr 3 08:54 traceroute
Is this simply a cosmetic issue and I can just remove those binaries
manually or if not so, is there a special configs needed to remove
them.
Apologize if this question has been asked before.
--
Thank you for your time,
Ihsan Junaidi Ibrahim
------------------------------
Message: 21
Date: Sat, 3 Apr 2010 06:29:45 -0400
From: Carmel NY <carm...@hotmail.com>
Subject: IPFW and Fail2Ban
To: freebsd-...@freebsd.org
Message-ID: <BLU0-SMTP13657371D...@phx.gbl>
Content-Type: text/plain; charset=UTF-8
I am having an exceedingly hard time finding documentation on Fail2Ban
on FreeBSD. In fact, documentation on Fail2Ban seems rather sparse to
begin with.
In any case, does Fail2Ban work with the IPFW firewall on FreeBSD? Does
it do it natively, or does it require a special configuration?
I presently have 'denyhost' up and running. If I get Fail2Ban working
correctly, I assume I can remove 'denyhost'. Again, I am assuming that
the two program would interact badly with each other.
--
Carmel
carm...@hotmail.com
|::::=======
|::::=======
|===========
|===========
|
Your fault - core dumped
------------------------------
End of freebsd-questions Digest, Vol 304, Issue 11
**************************************************