Re: flowd or similiar in base

[Heinz Kampmann]

 Hello,

thank you for the feedback. I did not know pmacct yet.
However, i can not judge whether the code provides
nearly the quality, reliability  and security, as is
the case with the OpenBSD base system.

Best Whishes,
Heinz
 

Gesendet: Mittwoch, 27. März 2019 um 13:48 Uhr
Von: "Tom Smyth" 
An: "Heinz Kampmann" 
Betreff: Re: flowd or similiar in base
http://www.pmacct.net in ports if that is any good to you ...

Thanks

Tom Smyth

On Wed, 27 Mar 2019 at 09:21, Heinz Kampmann  wrote:
>
>
> Hello misc,
>
> is there a chance that flowd or similar program
> will be included in base in the foreseeable future?
>
> Best Whishes,
> Heinz
>


--
Kindest regards,
Tom Smyth

The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Re: flowd or similiar in base

[Sebastian Benoit]

Hi,

Heinz Kampmann(h.kampm...@web.de) on 2019.03.27 10:19:26 +0100:
> 
> Hello misc,
> 
> is there a chance that flowd or similar program
> will be included in base in the foreseeable future?

No.

A note on mailing list questions like this: I usually would not comment a
question like this - i dont know what anyone else is working on at any time
- but you write 'foreseeable', so if someone commits The Perfect Flow
Collector tomorrow, i would still be correct in saying No, because it was
past my foreseeable future. Better ask: whats a good flow collector with
features x and y.

Re: openbgpd; strip private ASNs from bgp updates

[openbsd]

That will indeed help. Will check it out.

How I have solved it now is by having network statements on the edge
(/24s). To make the internal routing work I announce more specific
prefixes from the internal router, so externally I announce a /24
(from edge to peering partners) but internally I announce two /25s
(from internal to edge). That way internet knows how to find my /24
and edge knows how to find its way internally due to /25 being more
specific compared to /24.

On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit  wrote:
>
> open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100:
> > Hello,
> >
> > That would unforunately affect all the prefixes announced to the edge
> > router from the internal router. I need it to be only prefixes
> > announced to my peering partners.
> >
> > /Oscar
> >
> > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras  wrote:
> > >
> > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote:
> > > > Hello,
> > > >
> > > > Is there a way to make openbgpd strip private ASNs from updates it
> > > > sends to certain neighbors?
> > > > I am using openbgpd on my edge routers and distribute routes generated
> > > > internally to the rest of the world. However, the internal routers use
> > > > private ASNs and this is obviously frowned upon by my peering
> > > > partners.
> > > >
> > > > I can of course have network statements on my edge routers but that
> > > > assumes the prefixes will always be reachable via said edge router,
> > > > something I can never be certain of. I would rather the updates rely
> > > > on the prefix actually being announced from the source.
> > > >
> > >
> > > Perhaps with transparent-as ?
>
> In current (snapshots) there is "as-override":
>
>  as-override (yes|no)
>  If set to yes, all occurrences of the neighbor AS in the AS
>  path will be replaced with the local AS before running the
>  filters.  The Adj-RIB-In still holds the unmodified AS path.
>  The default value is no.
>
> this is a neighbor option and used on the session to a peer that uses a
> private AS.
>
> You dont say much about your network structure, but if your edge router has
> a normal As number, and your internal ebgp peers have private As numbers,
> this option will help.
>
> /Benno
>

Re: OpenBSD 6.5 on Clevo W840SU: BIOS hangs when booted via (m)SATA

[Fox Steward]

Dear Peter and all,

I could find a fix/hack for the BIOS boot problem as described.

I did not manage to file a bug report for it yet though.

After successfully installing I now have more problems such as

- zzz (suspend) and (hibernate) not working (see bug report [1])
- function keys for screen brightness not working 

@Peter: did these things work for you?

It seems the reason for all this trouble is a broken/outdated BIOS.

I wonder if Clevo - the manufacturer - would be eager to bring some fixes.

And of course, in the long run, we need a "free" BIOS for everyone. ;-)

Sincerely,

Fox


[1] https://marc.info/?t=15535409473&r=1&w=2

How to overrule bioctl "chunk already in use"

[Rachel Roch]

Hi,

I've been following the instructions here 
https://www.openbsd.org/faq/faq14.html  
to setup softraid.

Unfortunately I somehow messed up the original attempt through my own stupidity.

So I've been trying to go through the steps again.  However nothing I do can 
elminate the "softraid0 sd0a chunk already in use" message at the "bioctl -c 1 
-l sd0a,sd1a softraid0" step.

I've tried everything !  Rebooting the server, /dev/zero to the first 500MB of 
sd0 and sd1, changing uuid in disklabel, erasing and re-writing disk label.

I looked at the man page and thought "ah ha !" ... maybe "-C force", but nope !

Any ideas 

Rachel

Re: How to overrule bioctl "chunk already in use"

[Nick Holland]

On 3/28/19 10:29 AM, Rachel Roch wrote:
> Hi,
> 
> I've been following the instructions here
> https://www.openbsd.org/faq/faq14.html
>  to setup softraid.
> 
> Unfortunately I somehow messed up the original attempt through my own
> stupidity.

it happens.
And best that it happen before production than after.

> So I've been trying to go through the steps again.  However nothing
> I do can elminate the "softraid0 sd0a chunk already in use" message
> at the "bioctl -c 1 -l sd0a,sd1a softraid0" step.
> 
> I've tried everything !  Rebooting the server, /dev/zero to the
> first 500MB of sd0 and sd1, changing uuid in disklabel, erasing and
> re-writing disk label.
> 
> I looked at the man page and thought "ah ha !" ... maybe "-C force",
> but nope !

you were close with the zeroing the head of the components.  In fact,
I'm not sure what you did wrong, but that's the solution.

I'd suggest starting by zeroing the beginning of each physical disk --
using the r device and the c partition -- i.e.,

   # dd if=/dev/zero of=/dev/rsd0c
   # dd if=/dev/zero of=/dev/rsd1c

I've had enough problems, I really suggest this unless you are
absolutely sure your disk has never even heard of OpenBSD before you
install it. :)  (I think I had figured out at one point that zeroing the
RAID partitions was sufficient, but when it comes to zeroing, a little
more is never too much. :)

Now, if you were going to script this, you would put a block size and a
count in there...but since you are just typing this at the command line,
count to three and hit CTRL-C then do the next.  You really only have to
clear a megabyte or so, and probably a LOT less...you can't hit CTRL-C
fast enough, I suspect. :)

By using the 'r' device and the 'c' partion, you have wiped the very
very start of the disk -- sector zero onward.

I'd reboot after that.  I don't think it's needed, but either the
disklabel or MBR partition can be held in memory and written back out to
disk under some circumstance, I don't recall exactly what (probably
having to do with mounted partitions), so a reboot, and then verifying
that fdisk sd0 shows lots of zeros everywhere including the Signature.
NOW fdisk, create your OpenBSD partition, then your RAID disklabel
partitions, and you should be in business.

If that doesn't do it, show us your exact commands and exact output you
are seeing.

Nick.