Re: build with DEBUG defined
On Aug 6, 2019 8:51 PM, Gleydson Soares wrote: > > On Tue, Aug 06, 2019 at 06:55:15PM -0500, Edgar Pettijohn wrote: > > I'm trying to build smtpd with `-g'. I tried the following: > > > > deathstar$ make -DDEBUG > > ===> smtpd > > yacc -o parse.c /usr/src/usr.sbin/smtpd/smtpd/../parse.y > > cc -O2 -pipe 1 -fstack-protector-all -I/usr/src/usr.sbin/smtpd/smtpd/.. > > -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > > -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare > > -Werror-implicit-function-declaration -DIO_TLS -DQUEUE_PROFILING -MD -MP > > -c /usr/src/usr.sbin/smtpd/smtpd/../aliases.c > > cc: error: no such file or directory: '1' > > *** Error 1 in smtpd (:87 'aliases.o') > > *** Error 1 in /usr/src/usr.sbin/smtpd (:48 'all') > > > > I then tried: > > > > deathstar$ cat /etc/mk.conf > > DEBUG=1 > > > > deathstar$ make > > ===> smtpd > > yacc -o parse.c /usr/src/usr.sbin/smtpd/smtpd/../parse.y > > cc -O2 -pipe 1 -fstack-protector-all -I/usr/src/usr.sbin/smtpd/smtpd/.. > > -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > > -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare > > -Werror-implicit-function-declaration -DIO_TLS -DQUEUE_PROFILING -MD -MP > > -c /usr/src/usr.sbin/smtpd/smtpd/../aliases.c > > cc: error: no such file or directory: '1' > > *** Error 1 in smtpd (:87 'aliases.o') > > *** Error 1 in /usr/src/usr.sbin/smtpd (:48 'all') > > > > It builds without DEBUG defined. Any suggestions? > > DEBUG=-g > see mk.conf manpage. > The manual says that defining DEBUG adds -g to assembly not that DEBUG should be set to -g. Either way I will give it a shot tomorrow. If it works seems like the manual could be a little more informative. Thanks, Edgar > > > > Thanks, > > > > Edgar > >
hw.speed=97 low values of CPU MHz in QEMU Guests
Hello, I have been doing some (very rudimentary) testing on network performance on OpenBSD guests running in a KVM Virtual Machine I was wondering does the sysctl readonly value hw.cpuspeed used as input for any drivers in OpenBSD, the reason Im asking is that the reported speed of the CPU MHz is very low hw.cpuspeed=96 where in actual fact the CPU is running at 1100-2200 MHz I have run ubench and sysbench and the cpu performance seems within 80% of the perfomance of Native Hardware.. .so I dont think it is affecting the CPU but im concerned (but dont know) wheather or not it could affect I/O and networking. I have included the dmesg, output and pci information below dmesg OpenBSD 6.5-current (GENERIC.MP) #2: Fri Aug 2 22:33:13 IST 2019 fireman@obsdcur20190730.ogmaconnect:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4278140928 (4079MB) avail mem = 4138319872 (3946MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5900 (10 entries) bios0: vendor SeaBIOS version "rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org" date 04/01/2014 bios0: QEMU Standard PC (Q35 + ICH9, 2009) acpi0 at bios0: ACPI 1.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HPET MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 96.84 MHz, 06-3e-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,FSGSBASE,TSC_ADJUST,SMEP,ERMS,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, 252.36 MHz, 06-3e-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,FSGSBASE,TSC_ADJUST,SMEP,ERMS,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured cpu0: using VERW MDS workaround pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Bochs VGA" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 10 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 0 int 10 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 0 int 10 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 0 int 10 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi azalia0: no HD-Audio codecs ppb0 at pci0 dev 28 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 10 pci1 at ppb0 bus 1 iavf0 at pci1 dev 0 function 0 "Intel XL710/X710 VF" rev 0x02, VF version 1.1, VF 0 VSI 10, msix, address aa:bb:cc:dd:ee:f0 ppb1 at pci0 dev 28 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 10 pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 10 pci3 at ppb2 bus 3 ppb3 at pci0 dev 28 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 10 pci4 at ppb3 bus 4 uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x03: apic 0 int 10 uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x03: apic 0 int 10 uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x03: apic 0 int 10 ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x03:
Re: Full path in SYNOPSIS for /usr/libexec programs
Lyndon Nerenberg wrote: > Theo de Raadt writes: > > Disagree on this. > > > > Those programs are intentionally not in the path, since you don't > > run them by hand. > > That's what I was getting at. It's not clear they are 'libexec's. > That's what confuses people. I just thought this might be a way > to make it clear(er) that you don't run these directly, but that > they are invoked by other things. Which people does it confuse? > I.e. it's easy to explain the concept of /usr/libexec to people > once, so they recognize it when they see the path spelled out. But > when we're bringing in people from Linux, their first reaction upon > not finding the documented command is to start installing packages > from hell to breakfast until something works. From an indoctrination > standpoint, there's a lot less pain (and cleanup work) if they know > right away that /usr/libexec/foo(8) is not something you run from > the shell. They are installing packages for a command that has a manual page already? Look I really doubt that is happening. > I won't push this any further, but experience shows this change > really helps guide people into the BSD filesystem hierarchy > conventions. We do not include paths in SYNOPSIS, because it isn't important (and in some cases, it would be dangerous to do so)
Re: Full path in SYNOPSIS for /usr/libexec programs
Theo de Raadt writes: > Disagree on this. > > Those programs are intentionally not in the path, since you don't > run them by hand. That's what I was getting at. It's not clear they are 'libexec's. That's what confuses people. I just thought this might be a way to make it clear(er) that you don't run these directly, but that they are invoked by other things. I.e. it's easy to explain the concept of /usr/libexec to people once, so they recognize it when they see the path spelled out. But when we're bringing in people from Linux, their first reaction upon not finding the documented command is to start installing packages from hell to breakfast until something works. From an indoctrination standpoint, there's a lot less pain (and cleanup work) if they know right away that /usr/libexec/foo(8) is not something you run from the shell. I won't push this any further, but experience shows this change really helps guide people into the BSD filesystem hierarchy conventions. --lyndon
Re: build with DEBUG defined
On Tue, Aug 06, 2019 at 06:55:15PM -0500, Edgar Pettijohn wrote: > I'm trying to build smtpd with `-g'. I tried the following: > > deathstar$ make -DDEBUG > ===> smtpd > yacc -o parse.c /usr/src/usr.sbin/smtpd/smtpd/../parse.y > cc -O2 -pipe 1 -fstack-protector-all -I/usr/src/usr.sbin/smtpd/smtpd/.. -Wall > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow > -Wpointer-arith -Wcast-qual -Wsign-compare > -Werror-implicit-function-declaration -DIO_TLS -DQUEUE_PROFILING -MD -MP -c > /usr/src/usr.sbin/smtpd/smtpd/../aliases.c > cc: error: no such file or directory: '1' > *** Error 1 in smtpd (:87 'aliases.o') > *** Error 1 in /usr/src/usr.sbin/smtpd (:48 'all') > > I then tried: > > deathstar$ cat /etc/mk.conf > DEBUG=1 > > deathstar$ make > ===> smtpd > yacc -o parse.c /usr/src/usr.sbin/smtpd/smtpd/../parse.y > cc -O2 -pipe 1 -fstack-protector-all -I/usr/src/usr.sbin/smtpd/smtpd/.. -Wall > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow > -Wpointer-arith -Wcast-qual -Wsign-compare > -Werror-implicit-function-declaration -DIO_TLS -DQUEUE_PROFILING -MD -MP -c > /usr/src/usr.sbin/smtpd/smtpd/../aliases.c > cc: error: no such file or directory: '1' > *** Error 1 in smtpd (:87 'aliases.o') > *** Error 1 in /usr/src/usr.sbin/smtpd (:48 'all') > > It builds without DEBUG defined. Any suggestions? DEBUG=-g see mk.conf manpage. > > Thanks, > > Edgar >
Re: Full path in SYNOPSIS for /usr/libexec programs
Disagree on this. Those programs are intentionally not in the path, since you don't run them by hand. I think you are making a mountain out of a molehill. Lyndon Nerenberg wrote: > For programs that live in /usr/libexec, those with manpages show > just the bare program name in the SYNOPSIS section (when there is > a SYNOPSIS section). > > There is a long-standing expectation that programs documented in > section 8 of the manual can be run from a shell with /sbin:/usr/sbin > in the $PATH. It's frustrating for newer BSD admins when foo(8) > programs aren't there, apparently, due to living in libexec. Also, > sometimes, even for the older BSD admins who expect to find these > things in *sbin from, e.g., older SunOS releases. > > What I'd like to do is fully qualify the paths to those commands in > the SYNOPSIS section, where that makes sense. E.g. for the mail.*(8) > entries, 'mail.*' becomes '/usr/libexec/mail.*' under SYNOPSIS (only). > > For entries that have a *sbin command shadowing a /usr/libexec program, > nothing changes. > > If people think this makes sense I'll sendbug a patch. > > --lyndon >
Full path in SYNOPSIS for /usr/libexec programs
For programs that live in /usr/libexec, those with manpages show just the bare program name in the SYNOPSIS section (when there is a SYNOPSIS section). There is a long-standing expectation that programs documented in section 8 of the manual can be run from a shell with /sbin:/usr/sbin in the $PATH. It's frustrating for newer BSD admins when foo(8) programs aren't there, apparently, due to living in libexec. Also, sometimes, even for the older BSD admins who expect to find these things in *sbin from, e.g., older SunOS releases. What I'd like to do is fully qualify the paths to those commands in the SYNOPSIS section, where that makes sense. E.g. for the mail.*(8) entries, 'mail.*' becomes '/usr/libexec/mail.*' under SYNOPSIS (only). For entries that have a *sbin command shadowing a /usr/libexec program, nothing changes. If people think this makes sense I'll sendbug a patch. --lyndon
Bluetooth support status
Hello, Just curious if there was any change in OpenBSD supporting bluetooth. In this commit from tedu@ it's saying that support was ripped out of the kernel because it never really worked. https://marc.info/?l=openbsd-cvs=140511572108715=2 man -k blue brings up nothing appros. Thanks, JB
build with DEBUG defined
I'm trying to build smtpd with `-g'. I tried the following: deathstar$ make -DDEBUG ===> smtpd yacc -o parse.c /usr/src/usr.sbin/smtpd/smtpd/../parse.y cc -O2 -pipe 1 -fstack-protector-all -I/usr/src/usr.sbin/smtpd/smtpd/.. -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare -Werror-implicit-function-declaration -DIO_TLS -DQUEUE_PROFILING -MD -MP -c /usr/src/usr.sbin/smtpd/smtpd/../aliases.c cc: error: no such file or directory: '1' *** Error 1 in smtpd (:87 'aliases.o') *** Error 1 in /usr/src/usr.sbin/smtpd (:48 'all') I then tried: deathstar$ cat /etc/mk.conf DEBUG=1 deathstar$ make ===> smtpd yacc -o parse.c /usr/src/usr.sbin/smtpd/smtpd/../parse.y cc -O2 -pipe 1 -fstack-protector-all -I/usr/src/usr.sbin/smtpd/smtpd/.. -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare -Werror-implicit-function-declaration -DIO_TLS -DQUEUE_PROFILING -MD -MP -c /usr/src/usr.sbin/smtpd/smtpd/../aliases.c cc: error: no such file or directory: '1' *** Error 1 in smtpd (:87 'aliases.o') *** Error 1 in /usr/src/usr.sbin/smtpd (:48 'all') It builds without DEBUG defined. Any suggestions? Thanks, Edgar
Re: Building Unbound with Python module support
Hi Stuart, Thanks for your reply. So I put in some leg work to set myself up so I could build a new release base system, and went digging. And I found “/usr/src/usr.src/unbound/Makefile.bsd-wrapper” so I think I have found the correct build options to match with the base builds CONFIGURE_OPTS_UNBOUND I will try again with these options tomorrow, and see if I have the same errors. “The default install can't include Python support, because the default install of Unbound is in the base OS, and Python isn't.” Facepalm.. Of course! Is there a C plugin library? I would like to make this project native/portable so other users can use this project without having to rebuild Unbound? Thanks Andy. Sent from a teeny tiny keyboard, so please excuse typos > On 6 Aug 2019, at 19:36, Stuart Henderson wrote: > >> On 2019-08-06, Andy Lemin wrote: >> Hi guys, >> >> I’m just after some general advice as I feel like I’m doing something wrong, >> and having to hack around too much for what I believe should be simple. >> >> I am developing a simple Python plugin for Unbound, and the default Unbound >> install on OpenBSD sadly wasn’t built with “—with-pythonmodule”. >> >> So I grabbed the Unbound source code with a git clone from GitHub, installed >> dependencies, and did “./configure —with-pythonmodule”, make, make install >> etc.. >> >> So nothing special here. It installed to /usr/local/ rather than just /usr >> etc, and so fiddled around with /etc/rc.d/unbound to make the rc scripts >> start the custom one. >> >> But I’m getting errors which requires some extra config settings to squash >> when loading the same config as with the built in Unbound. ok maybe newer >> unbound code.. >> >> But I am then also getting errors when trying to load the stock example >> python plugin as per the source built sphinx docs. >> >> I’m not at my computer at the moment so can’t share the exact errors, but >> thought I’d ask as it feels like I’m missing something obvious! >> >> Maybe I need some extra build options or static library references to make >> it as smooth as the built in Unbound? Or maybe I should be using a different >> source? >> >> Any initial thoughts? I’ll post exact errors as soon as I can. > > Initial thoughts are "did you use the same configure flags as much as possible > as the build in base". Really need to see the errors to be able to make any > more detailed suggestions. > > The default install can't include Python support, because the default install > of Unbound is in the base OS, and Python isn't. > >
Re: How do I publish default router preferences using rad?
Caleb(enlightened.des...@gmail.com) on 2019.08.06 08:05:48 -0700:
> How do I publish default router preferences as defined in RFC 4191
> (https://tools.ietf.org/html/rfc4191) using rad in OpenBSD 6.5?
> I've read the friendly rad.conf man page
> (https://man.openbsd.org/rad.conf.5) and scanned the source
> (https://github.com/openbsd/src/tree/master/usr.sbin/rad) with no
> success.
You can't, because it was not implemented.
That is, until now.
I wrote a patch, which you can test if you like. It's completly untested
though.
diff --git usr.sbin/rad/frontend.c usr.sbin/rad/frontend.c
index 8178b058629..75723797fcf 100644
--- usr.sbin/rad/frontend.c
+++ usr.sbin/rad/frontend.c
@@ -1016,6 +1016,8 @@ build_packet(struct ra_iface *ra_iface)
ra->nd_ra_flags_reserved |= ND_RA_FLAG_MANAGED;
if (ra_options_conf->o_flag)
ra->nd_ra_flags_reserved |= ND_RA_FLAG_OTHER;
+ ra->nd_ra_flags_reserved |=
+ ra_options_conf->preference;
if (ra_iface->removed)
/* tell clients that we are no longer a default router */
ra->nd_ra_router_lifetime = 0;
@@ -1048,6 +1050,8 @@ build_packet(struct ra_iface *ra_iface)
if (ra_prefix_conf->aflag)
ndopt_pi->nd_opt_pi_flags_reserved |=
ND_OPT_PI_FLAG_AUTO;
+ ndopt_pi->nd_opt_pi_flags_reserved |=
+ ra_prefix_conf->preference;
ndopt_pi->nd_opt_pi_valid_time = htonl(ra_prefix_conf->vltime);
ndopt_pi->nd_opt_pi_preferred_time =
htonl(ra_prefix_conf->pltime);
diff --git usr.sbin/rad/parse.y usr.sbin/rad/parse.y
index 004e5e22f92..b004ab37356 100644
--- usr.sbin/rad/parse.y
+++ usr.sbin/rad/parse.y
@@ -106,6 +106,7 @@ typedef struct {
union {
int64_t number;
char*string;
+ shortpref;
} v;
int lineno;
} YYSTYPE;
@@ -117,11 +118,13 @@ typedef struct {
%token CONFIGURATION OTHER LIFETIME REACHABLE TIME RETRANS TIMER
%token AUTO PREFIX VALID PREFERRED LIFETIME ONLINK AUTONOMOUS
%token ADDRESS_CONFIGURATION DNS NAMESERVER SEARCH MTU
+%token PREFERENCE LOW MEDIUM HIGH
%token STRING
%token NUMBER
%typeyesno
%typestring
+%type preftype
%%
@@ -213,6 +216,9 @@ ra_opt_block: DEFAULT ROUTER yesno {
| MTU NUMBER {
ra_options->mtu = $2;
}
+ | PREFERENCE preftype {
+ ra_options->preference = $2;
+ }
| DNS dns_block
;
@@ -298,6 +304,19 @@ ra_prefixoptsl : VALID LIFETIME NUMBER {
| AUTONOMOUS ADDRESS_CONFIGURATION yesno {
ra_prefix_conf->aflag = $3;
}
+ | PREFERENCE preftype {
+ ra_prefix_conf->preference = $2;
+ }
+ ;
+preftype : LOW {
+ $$ = RA_PREFIXOPT_PREF_LOW;
+ }
+ | MEDIUM {
+ $$ = RA_PREFIXOPT_PREF_MEDIUM;
+ }
+ | HIGH {
+ $$ = RA_PREFIXOPT_PREF_HIGH;
+ }
;
dns_block : '{' optnl dnsopts_l '}'
| '{' optnl '}'
@@ -425,17 +444,21 @@ lookup(char *s)
{"configuration", CONFIGURATION},
{"default", DEFAULT},
{"dns", DNS},
+ {"high",HIGH},
{"hop", HOP},
{"include", INCLUDE},
{"interface", RA_IFACE},
{"lifetime",LIFETIME},
{"limit", LIMIT},
+ {"low", LOW},
{"managed", MANAGED},
+ {"medium", MEDIUM},
{"mtu", MTU},
{"nameserver", NAMESERVER},
{"no", NO},
{"on-link", ONLINK},
{"other", OTHER},
+ {"preference", PREFERENCE},
{"preferred", PREFERRED},
{"prefix", PREFIX},
{"reachable", REACHABLE},
diff --git usr.sbin/rad/printconf.c usr.sbin/rad/printconf.c
index d42890da518..e063daaa19f 100644
--- usr.sbin/rad/printconf.c
+++ usr.sbin/rad/printconf.c
@@ -34,6 +34,7 @@
#include "rad.h"
const char*yesno(int);
+const char*preference(short);
void print_ra_options(const char*, const struct ra_options_conf*);
void print_prefix_options(const char*, const struct ra_prefix_conf*);
@@ -43,6 +44,21 @@ yesno(int flag)
return flag ? "yes" : "no";
}
+const
Re: Building Unbound with Python module support
On 2019-08-06, Andy Lemin wrote: > Hi guys, > > I’m just after some general advice as I feel like I’m doing something wrong, > and having to hack around too much for what I believe should be simple. > > I am developing a simple Python plugin for Unbound, and the default Unbound > install on OpenBSD sadly wasn’t built with “—with-pythonmodule”. > > So I grabbed the Unbound source code with a git clone from GitHub, installed > dependencies, and did “./configure —with-pythonmodule”, make, make install > etc.. > > So nothing special here. It installed to /usr/local/ rather than just /usr > etc, and so fiddled around with /etc/rc.d/unbound to make the rc scripts > start the custom one. > > But I’m getting errors which requires some extra config settings to squash > when loading the same config as with the built in Unbound. ok maybe newer > unbound code.. > > But I am then also getting errors when trying to load the stock example > python plugin as per the source built sphinx docs. > > I’m not at my computer at the moment so can’t share the exact errors, but > thought I’d ask as it feels like I’m missing something obvious! > > Maybe I need some extra build options or static library references to make it > as smooth as the built in Unbound? Or maybe I should be using a different > source? > > Any initial thoughts? I’ll post exact errors as soon as I can. Initial thoughts are "did you use the same configure flags as much as possible as the build in base". Really need to see the errors to be able to make any more detailed suggestions. The default install can't include Python support, because the default install of Unbound is in the base OS, and Python isn't.
vidoas script
howdee,
i know that yallve helped me so many times
and in so many ways that i thought id try to
give something back... in particular i have
run into the simple/silly problem of directly
editting the /etc/doas.conf file and making a
mistake which locks me out of fixing it...
so, i looked around for a vipw/visudo type of
script - and not seeing one; i came up with
the following variant... im sure there are other
(and better?) ways to do this task - so feel
free to do whatever you please with this script...
(ie - if there must be some-license associated,
use: https://choosealicense.com/licenses/unlicense/ ?)
hope this helps someone else... h.
#!/bin/ksh
#
# hjf latest mod: 2019-08-05 @ 10:00
#
## vidoas.sh
#
## this is a basic copy/update from eradman at
## http://eradman.com/postst/ut-shell-scripts.html
##
## GOAL try to create a vidoas pgm like visudo...
export LAUNCH_CMDS=`mktemp`
export VI_FILE=`mktemp`
export USR=`whoami`
export TTY=`tty`
export DOASFILE="/etc/doas.conf"
typeset -i test_runs=0
function try { this="$1"; }
trap 'printf "$0: exit code $? on line $LINENO\nFAIL: $this\n"; exit 1' ERR
function assert {
let tests_run+=1
[ "$1" = "$2" ] && { echo -n "."; return; }
printf "\nFAIL: $this\n'$1' != '$2'\n"; exit 1
}
try "1. create an edit-able copy..."
cat > $LAUNCH_CMDS <<-'LAUNCHER'
doas -L
doas cp $DOASFILE $VI_FILE
doas -L
LAUNCHER
# syserr catches bad passwords here...
assert "`. $LAUNCH_CMDS 2>&1`" ""
try "2. go ahead and vi-edit ..."
cat > $LAUNCH_CMDS <<-'LAUNCHER'
# dont let kshrc-stuff run...
export ENV=''
( ksh -i -c "vi $VI_FILE <$TTY >$TTY" )
doas -C $VI_FILE
LAUNCHER
# check blatant errors in editting...
assert "`. $LAUNCH_CMDS 2>&1`" ""
try "3. post-edit-check for replacement permissions..."
assert "`doas -C $VI_FILE -u $USR cp | cut -c 1-6 `" "permit"
try "4. install the latest-greatest back..."
assert "`doas cp $VI_FILE $DOASFILE 2>&1`" ""
rm -f $LAUNCH_CMDS
rm -f $VI_FILE
##echo; echo "PASS: $tests_run tests run"
echo "vidoas.sh succeeded."
Re: Best 1Gbe NIC
Thanks for your comments guys. I’ve ordered some Intel NICs :) I just wanted to make sure I was getting the best offload capability, but I agree with you Claudio ;) Cheers, Andy. Sent from a teeny tiny keyboard, so please excuse typos > On 2 Aug 2019, at 19:09, Brian Brombacher wrote: > > I find cheap PCI-Express and PCI-X em(4) cards suffice for my needs. 990-992 > Mbps with tcpbench. > > >>> On Aug 2, 2019, at 11:26 AM, Claudio Jeker wrote: >>> >>> On Fri, Aug 02, 2019 at 12:28:58PM +0100, Andy Lemin wrote: >>> Ahhh, thank you! >>> >>> I didn’t realise this had changed and now the drivers are written with >>> full knowledge of the interface. >> >> That is an overstatement but we know for sure a lot more about these cards >> then many other less open ones. >> >>> So that would make Intel Server NICs (i350 for example) some of the best >>> 1Gbe cards nowadays then? >> >> They are well supported by OpenBSD as are many other server nics like bge >> and bnx. I would not call them best, when it comes to network cards it >> seems to be a race to the bottom. All chips have stuff in them that is >> just not great. em(4) for example needs a major workaround because the >> buffersize is specified by a bitfield. >> >> My view is more pessimistic, all network cards are shit there are just >> some that are less shitty. Also I prefer to use em(4) over most other >> gigabit cards. >> >> -- >> :wq Claudio >> >>> >>> Sent from a teeny tiny keyboard, so please excuse typos >>> > On 2 Aug 2019, at 09:52, Jonathan Gray wrote: > > On Fri, Aug 02, 2019 at 09:19:09AM +0100, Andy Lemin wrote: > Hi list, > > I know this is a rather classic question, but I have searched a lot on > this again recently, and I just cannot find any conclusive up to date > information? > > I am looking to buy the best 1Gbe NIC possible for OpenBSD and the only > official comments I can find relate to 3COM for ISA, or community > consensus towards Chelsio for 10Gbe. > > I know Intel works ok and I???ve used the i350???s before, but my > understanding is that Intel still doesn???t provide the documentation for > their NICs and so the emX driver is reverse engineered. This is incorrect. Intel provides datasheets for Ethernet parts. em(4) is derived from Intel authored code for FreeBSD supplied under a permissive license. > > And if I remember correctly some offload features were also disabled in > the emX driver a while back as some functions where found to be insecure > on die and so it was deemed safer to bring the logic back on CPU. > > So I???m looking for the best 1Gbe NIC that supports the most > offloading/best driver support/performance etc. > > Thanks, Andy. > > PS; could we update the official supported hardware lists? ;) > All the best. > > > Sent from a teeny tiny keyboard, so please excuse typos > >>> >> >
Building Unbound with Python module support
Hi guys, I’m just after some general advice as I feel like I’m doing something wrong, and having to hack around too much for what I believe should be simple. I am developing a simple Python plugin for Unbound, and the default Unbound install on OpenBSD sadly wasn’t built with “—with-pythonmodule”. So I grabbed the Unbound source code with a git clone from GitHub, installed dependencies, and did “./configure —with-pythonmodule”, make, make install etc.. So nothing special here. It installed to /usr/local/ rather than just /usr etc, and so fiddled around with /etc/rc.d/unbound to make the rc scripts start the custom one. But I’m getting errors which requires some extra config settings to squash when loading the same config as with the built in Unbound. ok maybe newer unbound code.. But I am then also getting errors when trying to load the stock example python plugin as per the source built sphinx docs. I’m not at my computer at the moment so can’t share the exact errors, but thought I’d ask as it feels like I’m missing something obvious! Maybe I need some extra build options or static library references to make it as smooth as the built in Unbound? Or maybe I should be using a different source? Any initial thoughts? I’ll post exact errors as soon as I can. Thanks :) Andy. Sent from a teeny tiny keyboard, so please excuse typos
How do I publish default router preferences using rad?
How do I publish default router preferences as defined in RFC 4191 (https://tools.ietf.org/html/rfc4191) using rad in OpenBSD 6.5? I've read the friendly rad.conf man page (https://man.openbsd.org/rad.conf.5) and scanned the source (https://github.com/openbsd/src/tree/master/usr.sbin/rad) with no success. Thanks, -Caleb
Hints on understanding/solving strange behavior in OBSD@QEmu
Hi, I installed OBSD 6.5 (or upgraded from 6.4, I'm not sure...) in a qcow2 image in QEmu 3.1.0 (Xubuntu 19.04 host). I selected to run ssh & start X with xenodm. Everything went fine with the basic install. Then I installed a few packages (emacs, python, spyder3, etc) and updated everything with pkg_add -ui and (sysmerge)/syspatch. Everything still worked fine after this step too. Then I discovered about Slim and decided to install Slim+XFCE4 following: https://medium.com/@005/openbsd-6-4-installing-a-seriously-underrated-os-in-a-virtual-machine-f5848ee5a25a and: https://sohcahtoa.org.uk/openbsd.html Thus I installed a few more packages: pkg_add -ui dbus consolekit2 polkit xfce xfce-extras slim slim-themes 1) set Slim as the display manager in /etc/rc.local /etc/rc.d/slim start 2) started the required daemons in /etc/rc.conf.local pkg_scripts="dbus_daemon avahi_daemon messagebus" dbus_enable 3) set XFCE as the in .xinitrc: exec startxfce4 --with-ck-launch And then the problem occurred: I could not login (graphically) anymore. The display manager would simply restart. I tried various modifications of 2) (removing some/all the pkg_scripts, adding =YES to dbus_enable) and 3) (removing exec, removing --withxxx, replacing by dbus-launch xxx). It did not work. After investigation, I discovered that dbus was not running, and that running dbus-daemon manually led to a coredump due to a floating point exception (thus XFCE would not start neither with Slim nor with xenodm, but restoring fvwm, by renaming .xinitrc, would work). I ffsck'ed the disk, then reinstalled dbus with pkg_add -D installed -r dbus. It did not work. I ran pkg_checked and discovered a few errors, particularly "checksum for /usr/local/bin/dbus-daemon does not match". I manually deleted all the files marked as errors by pkg_checked and reinstalled the concerned packages with pkg_add -D installed -r xxx (FYI: avahi, curl, dbus, ffcall, gettext, gnutls, harfbuzz, icu4c, libffi, libpaper, p11-kit, pcre, pcre2, png, sqlite, tiff). It did not work. I installed & ran sysclean, rerun pkg_check/pkg_add -D xxx -r yyy multiple times. Some errors disappeared, but not the dbus-daemon checksum & floating point exception problem. I know I could probably solve the problem quickly by reinstalling properly the whole system, but I'm really curious about HOW I could have reached such a situation, WHY this situation still holds after multiple pkg reinstalls and IF there's a clean/simple solution. So if anymore has any idea, I'd love to learn more, just in case this happens in a more dramatic situation and I have to find a cleaner solution than just reinstalling... Thanks in advance Guillaume
