Thank you Joerg for your comments on the manpage diff. But it looks like
Gilles has already committed the diff according to his previous response.
Thank you Gilles!
Just in case, I am including the updated diff as I reworded it as well.
Gilles, Joerg, could you please see if rewording makes the li
On Sat, Feb 13, 2016 at 2:45 AM, Otto Moerbeek wrote:
> On Fri, Feb 12, 2016 at 11:48:11PM -0500, Peter Bisroev wrote:
>
> ...
>
> This problem is already being discussed on bugs@ (with a different diff).
> I suggest to send this diff to bugs@ to keep the converation in
Dear Developers,
I believe there is an issue with pax when it tries to archive path names that
are exactly 101 bytes long and start with a slash. For example (sorry for
long lines)
$ pax -x ustar -w -f ./test.tar
/pax_test/sp1/sp22/sp333/sp/sp/this_name_including_path_is_101_bytes_long__
> Just in case the previous diff is OK, I am attaching the patch to the
> smtpd.conf man page.
Hi Gilles,
I apologize, my previous manpage diff did not include the information regarding
the fact that connections through local socket will always be tagged 'local'.
Please find the corrected manpag
Hi Gilles,
While looking over smtp_enqueue(), I have noticed that setting of
hostname is a noop. It looks like a leftover code from a bugfix in here
(http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/smtp.c.diff?r2=1.141&r1=1.140&f=u)
I am including a diff to smtp.c below that includes
> I only skimmed through your diff, I need to apply it and read in
> context but I like it a lot.
>
> I'll test today and come back with comments once I've spent more
> time reading it ;-)
>
> Thanks
Awesome, thank you Gilles!
Just in case the previous diff is OK, I am attaching the patch to th
Hi Gilles,
Please find my diff inline to enable "listen on socket" feature that we have
discussed. I have tested the diff with currently two supported listen options
for this listener, mask-sender and filter. Everything seems to be working OK.
These are the summary of the changes:
* Parser was ad
> Well your idea for a "listen on local" is very valid and the way to go
> in my opinion, however the keyword "local" is inappropriate here as we
> have a very different meaning for it: a message coming from an address
> that is also the address of a listener.
>
> A network connection from 127.0.0.
Hi Gilles
> We have faced a similar issue with filters and my thoughts are that we need a
> listen on socket of some kind, similar to your listen on local.
>
> This has several benefits over "listen on local", both in ambiguity and it
> new ways the ruleset can match sessions.
>
> If you're inte
Dear OpenSMTPD Developers!
I think there is a little "bug/feature" with respect to handling "mask-source"
parameter with "listen on" directive in smtpd.conf. The behavior makes perfect
sense from the perspective of documentation. Unfortunately it is not uniform
from the perspective of the client.
On Wed, Jun 6, 2012 at 5:29 PM, Peter Bisroev wrote:
> Thanks Stuart. I'll try running 'make release' again, and if that does not
> work
> I'll modify the Makefile. But before I do that, is there anything I
> can do to help
> troubleshoot this issue?
I have tr
On Wed, Jun 6, 2012 at 5:20 PM, Stuart Henderson wrote:
> On 2012/06/06 16:24, Peter Bisroev wrote:
>> Thank you Ted. That makes sense. So what is the best way to skip making
the
>> floppy image when doing 'make release'?
>
> iirc, just edit SUBDIR in distrib/amd
On Wed, Jun 6, 2012 at 4:32 PM, Maurice Janssen wrote:
> I suspect there's something else causing your problem. I've also built
> 5.1-stable release for amd64 and didn't see this.
>
> Did you by any chance upgrade this system from i386 to amd64? Or some
other
> unsupported upgrade?
>
> Maurice
Thank you Ted. That makes sense. So what is the best way to skip making the
floppy image when doing 'make release'?
--peter
On Wed, Jun 6, 2012 at 4:13 PM, Ted Unangst wrote:
> On Wed, Jun 06, 2012 at 12:26, Peter Bisroev wrote:
>> Hi All!
>>
>> I am having an is
Hi All!
I am having an issue making a 5.1 stable release using a patch branch synced on
2012-06-05 using:
"cvs -q -d$CVSROOT checkout -P -rOPENBSD_5_1 src ports xenocara".
amd64/ramdiskA kernel seems to be too big to fit on the default floppy image.
Please see the relevant part of the build log
On Fri, Jan 6, 2012 at 14:16, Chris Cappuccio wrote:
> Peter Bisroev [pe...@int19h.net] wrote:
>>
>> Thank you for a quick response guys! Chris if you are talking about
>> modifying /etc/rc does that mean that there could be a plan in the
>> future to add that to the CV
On Thu, Jan 5, 2012 at 04:17, Chris Cappuccio wrote:
> Stuart Henderson [s...@spacehopper.org] wrote:
>>
>> Alternatively I think it would work to add "!/etc/rc.d/unbound start"
>> to a suitable hostname.if file, though that's a bit of a hack and this
>> seems like a useful additioto use an altern
Hi All,
I have tried searching the mailing lists but did not seem to find the answer to
the problem that I am having. If someone can point me in the right direction I
will really appreciate it.
Currently I am testing this on OpenBSD 5.0 release. I am trying to use unbound
from ports as a recursiv
Hi All,
I am testing a redundant firewall setup where I am trying to use
relayd to make sure that the uplinks are reachable.
The relayd.conf is very simple:
---
# cat /etc/relayd.conf
interval 5
table {
B B B B 10.0.0.1 ip ttl 1 retry 2
}
router "upli
id 27504, len 70, bad cksum 18ba!)
--
Thanks!
--peter
On Mon, Oct 11, 2010 at 15:17, Peter Bisroev wrote:
> It looks like the latest checkout (2010-10-11) fixes the issues on amd64
arch.
>
> The only strange thing that I am seeing now is that carp and pfsync
> packets
rote:
> * Stuart Henderson [2010-10-07 22:17]:
>> On 2010/10/07 14:30, Peter Bisroev wrote:
>> > This problem comes up in 4.8-current snapshot from 2010.10.04 and
the
>> > -current from CVS dated 2010.10.06. When performing tcpdump on
pflog0
>> > the o
Stuart, that is correct, the are in sync. Clean CVS checkouts, and
snapshots from FTP. i386 builds do not show this problem.
--peter
On Thu, Oct 7, 2010 at 16:14, Stuart Henderson wrote:
> On 2010/10/07 14:30, Peter Bisroev wrote:
>> This problem comes up in 4.8-current snap
Thanks Henning! Please let me know what testing I can help with.
--peter
On Fri, Oct 8, 2010 at 04:07, Henning Brauer
wrote:
> * Stuart Henderson [2010-10-07 22:17]:
>> On 2010/10/07 14:30, Peter Bisroev wrote:
>> > This problem comes up in 4.8-current snapshot from
>Synopsis: 4.8-current, tcpdump on pflog with the latest snapshot problems
>Category: system, library
>Environment:
System : OpenBSD 4.8
Details : OpenBSD 4.8-current (GENERIC) #271: Mon Oct 4 12:19:02
MDT 2010
dera...@amd64.openbsd.org
Hi Claudio,
> Yes, since you disconnected the link between the carp interfaces without
> dropping their physical connections both will become MASTER.
> This normaly results in havoc since bad luck will flow all traffic to the
> wrong box. This is the typical problem with too much redundancy (the
>
Hi All,
I have tried searching the mailing lists but did not seem to find the
answer to the issue that I am seeing. I apologize for the long email,
but more info is better than less :)
For testing I have two OpenBSD 4.7-stable firewalls, and each has a
PCIe quad port Intel PRO/1000 QP (82571EB).
Hi All,
I am testing a redundant firewall setup where I am trying to use
relayd to make sure that the uplinks are reachable.
The relayd.conf is very simple:
---
# cat /etc/relayd.conf
interval 5
table {
10.0.0.1 ip ttl 1 retry 2
}
router "uplinks"
27 matches
Mail list logo
