Updated virtio.4 man page with viogpu device
Based on this commit, https://marc.info/?l=openbsd-cvs=168201887006175=2 , add viogpu, a VirtIO GPU driver Updated virtio.4 man page with viogpu device diff -c virtio.4.orig virtio.4 *** virtio.4.orig Wed Apr 26 13:07:35 2023 --- virtio.4Wed Apr 26 13:10:31 2023 *** *** 42,47 --- 42,49 VirtIO disk .It Xr viocon 4 VirtIO console device + .It Xr viogpu 4 + VirtIO GPU device .It Xr viomb 4 VirtIO memory ballooning driver .It Xr viornd 4
Re: [EXTERNAL] Re: CVS: cvs.openbsd.org: src
Once initially defined engineid should be static, a lot of SNMP polling applications use engineid as device identifier. Consistency and uniqueness are both important. Some polling system will not allow you to add another snmp device If engineid is a duplicate. Network devices usually derive engineid from lowest "numbered" interface. Unfortunately you can manually set them, this is bad when someone creates a configuration base template which has engineid defined, then you end up with 100's of network devices with the same engineid. I've spent quite a bit of time cleaning up from the mess this created. diana
Re: [EXTERNAL] Re: Fix unsafe snmpd defaults
In my work environment SNMPv3 auth+enc is the only method allowed. -Original Message- From: owner-t...@openbsd.org On Behalf Of Stuart Henderson Sent: Tuesday, June 15, 2021 10:40 AM To: Martijn van Duren Cc: tech Subject: [EXTERNAL] Re: Fix unsafe snmpd defaults Can we take a straw poll of readers of this email who are using SNMPv3 (if any ;-) -- are you using auth+enc, just auth, or no authentication? I'm thinking that somebody who went to the trouble of using v3 probably uses auth+enc though I could be wrong..
Re: [EXTERNAL] Happy 25th Birthday OpenBSD!
Congratulations. I remember trying to install OpenBSD sometime right after Theo started it. For the at the time FreeBSD user I struggled with the OpenBSD install. I remember sending an email to Theo and he basically told me if I couldn't figure out how to install OpenBSD I shouldn't be using it. Instead of getting pissed off I figured out how to install OpenBSD and have been running it ever since. diana -Original Message- From: owner-t...@openbsd.org On Behalf Of Bob Beck Sent: Sunday, October 18, 2020 9:45 AM To: tech@openbsd.org Subject: [EXTERNAL] Happy 25th Birthday OpenBSD! Yeah, it's just a number. But it's been a pretty wild ride. Thanks everyone for 25 years. -Bob
Re: [EXTERNAL] Re: Removing PF
Oops, I think you've confused me with Miod. He's the one who wrote the vax BPF.
I was only talking to him about adding direct SIMH support in 6.6. That way
you could have many kernels
running within a kernel at boot time.
I'm looking forward to running my old HP 2115 Fortran code Who needs
toggle switches anyway?
-Original Message-
From: Alexander Nasonov
Sent: Monday, April 1, 2019 1:38 PM
To: Eichert, Diana
Cc: tech@openbsd.org
Subject: Re: [EXTERNAL] Re: Removing PF
Eichert, Diana wrote:
> I wrote a vax BPF jit as a simple exercize some time ago, so all you
> really need now is to implement vax-to-${ARCH} jit on an MD basis.
> This should be very easy to do as long as BPF does not get extended to
> use floating-point values.
I'm afraid you have to rewrite it to risv-to-${ARCH} and vectorise along the
way.
--
Alex
Re: [EXTERNAL] Re: iked curve25519
You didn't ask for an enduser opinion but you should go ahead but I suggest a hard change. I can tell you people will continue to use the old method until it no longer works. -Original Message- From: owner-t...@openbsd.org On Behalf Of Tobias Heider Sent: Saturday, March 30, 2019 1:53 PM To: tech@openbsd.org Cc: r...@openbsd.org; s...@spacehopper.org Subject: [EXTERNAL] Re: iked curve25519 +1 for adding ID 31 Maybe add the proper one but also keep the old to give people some time to update their stuff if this is a problem. There should be more than enough reserved IDs. On 3/30/19 8:35 PM, Reyk Floeter wrote: > I like the idea of switching it to the proper ID. > > Reyk > >> Am 30.03.2019 um 20:31 schrieb Stuart Henderson : >> >> curve25519 had a proper ID (31) assigned in 2016 but we still have >> the draft private-use ID in iked. Any thoughts on whether we can just >> cut across to the proper ID, or whether that will be too painful? >> Are many people using this already? >> >
Re: [EXTERNAL] Re: Removing PF
I thought you were going to deal with MD issues by adding support for SIMH into
6.6?
-Original Message-
From: owner-t...@openbsd.org On Behalf Of Miod Vallat
Sent: Monday, April 1, 2019 7:04 AM
To: tech@openbsd.org
Subject: [EXTERNAL] Re: Removing PF
> Will the bpf JIT changes be done in time for 6.6? I have no doubt
> that "pfctl -p /dev/bfp" can be made to work in time but for a truly
> performant firewall we will need bpf JIT.
I wrote a vax BPF jit as a simple exercize some time ago, so all you really
need now is to implement vax-to-${ARCH} jit on an MD basis. This should be very
easy to do as long as BPF does not get extended to use floating-point values.
Re: [EXTERNAL] Export IPsec flows via snmpd(8)
Marco's reference to RFC4807 looks interesting. I started reading it yesterday afternoon, it appears to be much more extensive, including packet filter information. -Original Message- From: Martin Pieuchot [mailto:m...@openbsd.org] Sent: Wednesday, December 20, 2017 4:22 AM To: Eichert, Diana <deic...@sandia.gov> Cc: tech@openbsd.org Subject: Re: [EXTERNAL] Export IPsec flows via snmpd(8) On 19/12/17(Tue) 13:40, Eichert, Diana wrote: > tech lurker here, long time NMS/EMS admin > > I did not see diffs to an OpenBSD MIB file. I assume that will be included > in a "more complete solution"? Yes, I did not want to spend some time writing a MIB if the format is going to change. I know that many readers on this list already have their own way to export IPsecs data via SNMP, so I hope to get some inputs/recommendations.
Re: [EXTERNAL] Export IPsec flows via snmpd(8)
tech lurker here, long time NMS/EMS admin
I did not see diffs to an OpenBSD MIB file. I assume that will be included in
a "more complete solution"?
diana
-Original Message-
From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of
Martin Pieuchot
Sent: Tuesday, December 19, 2017 4:44 AM
To: tech@openbsd.org
Subject: [EXTERNAL] Export IPsec flows via snmpd(8)
I'd like to see some information about my tunnels in my NMS. The problem is
that there's not standard MIB for this and most vendor MIBs are huge and are
not easy to implement.
So here's a diff that export the equivalent of "$ ipsecctl -s flow".
I'm basically gluing ipsecctl(8) internals into snmpd(8).
It can be considered as a first step towards a more complete solution.
So I'd like to hear from people interested to export IPsec information via
SNMP, what would like to see and do you have a preferred format?
Comments? Oks?
SNIP
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v retrieving revision 1.85 diff -u -p
-r1.85 mib.c
--- mib.c 18 Dec 2017 05:51:53 - 1.85
+++ mib.c 19 Dec 2017 11:29:01 -
@@ -1422,6 +1422,7 @@ intmib_carpifnum(struct oid *, struct
struct carpif
*mib_carpifget(u_int);
int mib_memiftable(struct oid *, struct ber_oid *, struct ber_element **);
+int mib_ipsecflow(struct oid *, struct ber_oid *, struct ber_element **);
static struct oid openbsd_mib[] = {
{ MIB(pfMIBObjects),OID_MIB },
@@ -1633,6 +1634,26 @@ static struct oid openbsd_mib[] = {
{ MIB(carpIfAdvbase), OID_TRD, mib_carpiftable },
{ MIB(carpIfAdvskew), OID_TRD, mib_carpiftable },
{ MIB(carpIfState), OID_TRD, mib_carpiftable },
+ { MIB(ipsecMIBObjects), OID_MIB },
+ { MIB(ipsecFlowSAType), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowDirection), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowFromAddr), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowFromMask), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowSPort), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowToAddr), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowToMask), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowDPort), OID_TRD, mib_ipsecflow },
+#if notyet
+ /* Unprivileged user cannot see commented out information. */
+ { MIB(ipsecFlowLocal), OID_TRD, mib_ipsecflow },
+#endif
+ { MIB(ipsecFlowPeer), OID_TRD, mib_ipsecflow },
+#if notyet
+ { MIB(ipsecFlowAuthSrcID), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowAuthDstID), OID_TRD, mib_ipsecflow },
+ { MIB(ipsecFlowAuthType), OID_TRD, mib_ipsecflow },
+#endif
+ { MIB(ipsecFlowType), OID_TRD, mib_ipsecflow },
{ MIB(memMIBObjects), OID_MIB },
{ MIB(memMIBVersion), OID_RD, mps_getint, NULL, NULL,
OIDVER_OPENBSD_MEM },
@@ -2831,7 +2852,6 @@ mib_carpiftable(struct oid *oid, struct
/* Get and verify the current row index */
idx = o->bo_id[OIDIDX_carpIfEntry];
-
if ((cif = mib_carpifget(idx)) == NULL)
return (1);
@@ -2877,10 +2897,12 @@ mib_memiftable(struct oid *oid, struct b
u_int32_tidx = 0;
struct kif *kif;
+ /* Get and verify the current row index */
idx = o->bo_id[OIDIDX_memIfEntry];
if ((kif = mib_ifget(idx)) == NULL)
return (1);
+ /* Tables need to prepend the OID on their own */
o->bo_id[OIDIDX_memIfEntry] = kif->if_index;
ber = ber_add_oid(ber, o);
@@ -2891,6 +2913,110 @@ mib_memiftable(struct oid *oid, struct b
case 2:
ber = ber_add_integer(ber, 0);
ber_set_header(ber, BER_CLASS_APPLICATION, SNMP_T_COUNTER64);
+ break;
+ default:
+ return (-1);
+ }
+
+ return (0);
+}
+
+#include "ipsec.h"
+
+int
+mib_ipsecflow(struct oid *oid, struct ber_oid *o, struct ber_element
+**elm) {
+ struct ber_element *ber = *elm;
+ struct ipsec_rule *r;
+ u_int32_tval, idx = 0;
+
+ /* Get and verify the current row index */
+ idx = o->bo_id[OIDIDX_ipsecFlowEntry];
+ if ((r = ipsec_get_rule(idx)) == NULL)
+ return (1);
+
+ /* Tables need to prepend the OID on their own */
+ o->bo_id[OIDIDX_ipsecFlowEntry] = r->nr;
+ ber = ber_add_oid(ber, o);
+
+ switch (o->bo_id[OIDIDX_ipsecFlow]) {
+ case 1: /* satype */
+ ber = ber_add_string(ber, satype[r->satype]);
+ break;
+ case 2: /* direction */
+ ber = ber_add_string(ber, direction[r->direction]);
+ break;
+ case 3: /* from address */
+ val =
Re: [EXTERNAL] Re: Mention pkg-readmes in FAQ
Point taken, but what about a readme associated with a dependency install? I've seen them buried, even scroll off screen, in pkg install with a lot of dependencies. Then again, most people don't RTFM. -Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Stuart Henderson Sent: Saturday, April 25, 2015 10:07 AM To: trondd Cc: tech@openbsd.org Subject: [EXTERNAL] Re: Mention pkg-readmes in FAQ On 2015/04/25 11:21, trondd wrote: Seems like I see a lot of people who don't know about pkg-readmes and it was a long time before I knew about them, too. Note their existence in the package/ports FAQ. I don't object to it, but when you install a package with such information, it says: # pkg_add xl2tpd quirks-2.66 signed on 2015-04-23T10:51:49Z xl2tpd-1.3.1p5: ok The following new rcscripts were installed: /etc/rc.d/xl2tpd See rcctl(8) for details. Look in /usr/local/share/doc/pkg-readmes for extra documentation. If people don't manage to find it when it's right in front of them, what hope is there of them noticing it in the FAQ? --- faq15.html 27 Feb 2015 09:16:26 - 1.105 +++ faq15.html 25 Apr 2015 15:18:01 - @@ -370,6 +370,9 @@ scaled. Below is the relevant section fr /pre/blockquote p +Additionally, some packages provide configuration and other +information in a file located in i/usr/local/share/docs/pkg-readmes/i. +p Let us now continue with an example of a package which has dependencies: blockquotepre
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote: 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. I'm no developer, but why not create an mg port where various capabilities are added via FLAVORS? diana
Re: Allegations regarding OpenBSD IPSEC
-Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Joachim Schipper Subject: Re: Allegations regarding OpenBSD IPSEC On Wed, Dec 22, 2010 at 04:29:59PM +0100, Kurt Knochner wrote: Do you have a hint, how I could emit the random values from arc4random in a clever way? This isn't even remotely clever, but printf() and some base64 encoding should work fine for a one-off experiment. There *is* a limit to how much you can print before you fill up the dmesg; if insufficient, try compiling with a CONFIG.MP_LARGEBUF like this: --- include arch/amd64/conf/GENERIC.MP option MSGBUFSIZE=131072 --- You may wish to look at misc/ent. Joachim or use syslog(3) to output to your destination of choice.
Re: document ldapd schema files
I've always thought Bob's comment from 2/11/2005, was worth adding to quotes, but it might be a bit long. Bob might even remember why I say that. diana Bob Beck said on Feb 11, 2005 in a comment Re: Star OpenBSD . OpenBSD wants even the worst nastiest anal-carotid-constriction-software-patent-loving-spam-your-grandma-for-a-doll ar-bottom-feeding-killing-babies-in-palestine-and-iraq type organizations to be able to use our codebase in whatever they like.
Re: mg + tinyscheme
Am I the only one who liked coding Forth? :-) -Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Nicholas Marriott Sent: Wednesday, January 27, 2010 12:16 PM To: Ted Unangst Cc: OpenBSD Tech Subject: Re: mg + tinyscheme Hi SNIP And at least it isn't Forth.
