Softraid0-Problem: Inappropriate file type or format (Was: KDE-apps okular, kmahjongg)
Hi there! Unfortunately I have to hijack my own thread as it has the last working dmesg. Right after I had asked on misc@ about those KDE-apps I upgraded to the latest snapshot for amd64-current. By this I was hit by the "libxshmfence.so.0.0-issue". https://marc.info/?l=openbsd-tech=153003604704089=2 Well - running -current is usually rock-solid, but I am well aware that every now-and-then things might go wrong and will be corrected by the devs with the next snapshot (or the one thereafter). Happens remarkably seldom but obviously here I had to make use of the next snapshot, which I did: Wham! I cannot log-in to the system any more! "booting sr0a:/bsd: sr0a:/bsd: Inappropriate file type or format failed(79). will try /bsd" Yes - this system is fully encrypted, secured by a key-disk. I have dd'ed two more copies of this key, both behave the same. Thus I dare to suppose that there is no technical issue with the key (in particular as the other two USB-keys have not been attached at the time of the last upgrade). Most likely I did unknowingly s.th. really dumb. OK - how to proceed? Yes - I am lucky having backed up the relevant data the night before. My fallback solution is to simply reinstall everything. Annoying, as it will take a little time, but I will survive. My question is, as I can boot into 'bsd.rd', what alternative(s) I have to '# bioctl -c C -k /dev/sd1a -l /sd0a softraid0' softraid0: chunk sd0a already in use bsd.rd-dmesg shows at the end sd1 being the USB-key-disk and sd2 being the unencrypted OpenBSD-crypto-file, thus I used sd0 with 'bioctl'. Anyone a clue what might have gone wrong and how to proceed (except reinstallation)? TIA! Best, STEFAN Am 25.06.2018 um 22:36 schrieb Stefan Wollny: > Hi there, > > I run amd64-current with the latest public snapshots: > $ dmesg | grep Open > OpenBSD 6.3-current (GENERIC.MP) #52: Sun Jun 24 09:59:46 MDT 2018 > < Full dmesg at the end > > > [ ... ] > > > > OpenBSD 6.3-current (GENERIC.MP) #52: Sun Jun 24 09:59:46 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17079074816 (16287MB) > avail mem = 16420831232 (15660MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (35 entries) > bios0: vendor American Megatrends Inc. version "1.03.06" date 06/25/2014 > bios0: Notebook W65_67SZ > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT ASF! SSDT SSDT SSDT MCFG HPET SSDT > SSDT SSDT DMAR > acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) > PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) > EHC2(S3) XHC_(S3) HDEF(S4) [...] > 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) Core(TM) i5-4210M CPU @ 2.60GHz, 3093.34 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.85 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 1 (application processor) > cpu2: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 1, core 0, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 3092.84 MHz > cpu3: >
Re: 4k display on integrated Intel graphics?
On Thu, Jun 28, 2018 at 07:49:20PM +0200, Maximilian Pichler wrote: > Can OpenBSD drive a 4k display on integrated Intel graphics via HDMI > these days? Specifically, I'm hoping to connect it to my laptop's > "Intel HD Graphics 620" (Kaby Lake) via a single HDMI cable (which > would go into a USB-C-to-HDMI adapter). > > (I'm aware something similar has been asked two years ago, but am > guessing the bleeding edge has moved on a bit since then...) > > Thanks > Oh, just noticed the USB-C bit. You're on your own. My machine has integrated HDMI.
Re: 4k display on integrated Intel graphics?
On Thu, Jun 28, 2018 at 07:49:20PM +0200, Maximilian Pichler wrote: > Can OpenBSD drive a 4k display on integrated Intel graphics via HDMI > these days? Specifically, I'm hoping to connect it to my laptop's > "Intel HD Graphics 620" (Kaby Lake) via a single HDMI cable (which > would go into a USB-C-to-HDMI adapter). > > (I'm aware something similar has been asked two years ago, but am > guessing the bleeding edge has moved on a bit since then...) > > Thanks > It worked for me last time I tried, but I could only drive 30Hz. Probably an adapter limitation. -ml
Re: How to copy n bytes from stdin to stdout?
On Wed, 27 Jun 2018 10:06:40 -0700
xi wrote:
> > On Jun 25, 2018, at 16:19, Tomasz Rola wrote:
> >
> > On Sun, Jun 24, 2018 at 10:53:37PM -0400, Steve Litt wrote:
> >> On Thu, 21 Jun 2018 00:56:04 +0200
> >> Tomasz Rola wrote:
> >>
> > [...]
> >>> Craps. I have consulted OpenBSD's manpage for dd and there is no
> >>> mention of iflag. So this will not work on OpenBSD. I will have to
> >>> rethink this, sorry.
> >>>
> >>
> >> Untested...
> >>
> >> int main(int argc, char* argv[]){
> >> long l = atod(argv[1]);
> >> while(l--){
> >>if (c = getc(STDIN) != EOF)
> >>putc(c, STDOUT);
> >>else
> >>break;
> >> }
> >> return 0;
> >> }
> >>
> >> I haven't tested it so it might not be exactly right, and of course
> >> error handling would need to be added, but you know what I mean.
> >> IIRC getc() and putc() are very well buffered so it will be fast.
> >> In my youth I wrote similar functions using low level read() and
> >> write() and doing my own buffering, and those things were *really*
> >> fast, but I think that's overkill in this century.
> >>
> >> As far as finding command line tools that do it, if that's becoming
> >> hard to do, why not just write a 10 line program?
> >
> > Actually, I have written few such programs to satiate my own
> > curiosity
> > - I was dragged away from computer and in the meantime, others
> > joined thread and even wrote nice buffered version of solution in
> > C. I pitted this solution against my programs (in C, with
> > fgetc/fputc and Common Lisp, with read-sequence/write-sequence) and
> > head-c.c was many times faster (about hundred or more times) than
> > my programs.
> >
> > I am not sure if there is performance difference between fgetc/fputc
> > and getc/putc. Man says getc are macros around fgetc. Might be worth
> > checking, but I guess no difference.
> >
> > My curiosity also "wanted" to know how much of performance hit was
> > to be expected when writing best to my knowledge optimised Common
> > Lisp vs simplistic C - they were similar in performance, with CL
> > compiled by SBCL and few times slower, and head-c.c had beaten them
> > both by many lengths. I am a bit surprised that in CL, performance
> > was about the same, whether reading one byte or many at once.
> > Perhaps I will find a way to speed it up some more.
> >
> > As of finding command line tools, I had working script in about an
> > hour (and buggy one in few minutes). Buggy, because "dd | dd" is bad
> > idea, and after finding better options for using dd in my script -
> > which worked, but under Linux - I had also found out they would not
> > work in OpenBSD.
> >
> > So, I consider it a worthy lesson for myself. Next time, I might
> > just fire up Emacs and write a script in CL (mostly, because this
> > is what is comfy for me nowadays, and I will not object against
> > having compiled script for free). Or something similar, or maybe
> > even do it in C, why not.
> >
> > BTW, the version of nread.sh (improved options) was on par with
> > head-c.c, so writing a script with right things inside is very good
> > choice, too. If the script actually works :-) .
> >
> > While the speed is not big problem for input of about 1 megabyte, it
> > becomes a problem when gigabytes are copied.
> >
> > --
> > Regards,
> > Tomasz Rola
> >
> > --
> > ** A C programmer asked whether computer had Buddha's nature.
> > ** ** As the answer, master did "rm -rif" on the programmer's
> > home** ** directory. And then the C programmer became
> > enlightened... **
> > **
> > ** ** Tomasz Rola
> > mailto:tomasz_r...@bigfoot.com **
>
> If you want to do this in C, you can also simply take advantage of
> the fact that read(2) takes a number of bytes as argument and stops
> reading at EOF:
>
> #include
> #include
> #include
>
> int
> main(int argc, char *argv[])
> {
> if (argc < 2)
> return 1;
>
> size_t n;
> char *argend = argv[1] + strlen(argv[1]);
> if (!(n = strtoull(argv[1], , 10)))
> return 1;
>
> char *buf = malloc(n);
> size_t nr = read(0, buf, n);
> write(1, buf, nr);
> free(buf);
>
> return 0;
> }
>
> This is probably as fast as it gets for a task this simple, and it
> copies as many bytes as malloc is willing to allocate.
This is how I did it, both in C and in Turbo Pascal 3.0, back in the
1980's before getc() and putc() were well buffered, except I had the
read and write in a loop. If the buffer is a multiple of sector length,
it's remarkably fast. My findings were that a 64KB buffer was lightning
fast. In Turbo Pascal, a 512KB buffer was about 10% faster.
In this and successive threads people were talking about speed and
visual progress indicator. It's trivial to add nr to the total after
each write, and indicate with:
printf("%ld bytes written.\r", nr);
If that slows too much, do it on 1 out of every 100 writes.
By the mid 1990's, I noticed that
4k display on integrated Intel graphics?
Can OpenBSD drive a 4k display on integrated Intel graphics via HDMI these days? Specifically, I'm hoping to connect it to my laptop's "Intel HD Graphics 620" (Kaby Lake) via a single HDMI cable (which would go into a USB-C-to-HDMI adapter). (I'm aware something similar has been asked two years ago, but am guessing the bleeding edge has moved on a bit since then...) Thanks
Re: Is Intel PRO/1000 CT Desktop Adapter supported on amd64?
On Thu, 2018-06-28 at 09:32 +0300, Manolis Tzanidakis wrote: > On Wed (27/06/18), Vijay Sankar wrote: > > > > Quoting John Long : > > > I found a lot of PRO/1000 adapters listed in the em driver man > > > page but > > > CT version is not included. > > > > Since the CT version uses the Intel 82574L Controller, I think it > > will work. > > Indeed. I've got a couple of those and work just fine: > > $ sysctl kern.version > kern.version=OpenBSD 6.3 (GENERIC.MP) #4: Sun Jun 17 11:22:20 CEST > 2018 > r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compil > e/GENERIC.MP > > $ dmesg | grep ^em > em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address > xx:xx:xx:xx:xx:xx Thanks Manolis, the card will be here hopefully in the next week or two. /jl >
Re: FAQ: dmesg archive
Addenda http://patchwork.dpdk.org/patch/7639/ On Thu, Jun 28, 2018 at 15:10, Rupert Gallagher wrote: > This is the linux driver. I do not have the board yet, so no dmesgs. > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/phy/marvell.c?h=v4.17.3 > https://github.com/olerem/barebox/blob/master/drivers/net/phy/marvell.c > http://lists.infradead.org/pipermail/barebox/2014-November/021362.html Sent > from ProtonMail Mobile On Tue, Jun 26, 2018 at 20:50, Bryan Vyhmeister wrote: > > Looking at Supermicro's page, it's pretty easy to get some answers. > http://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9A-8CN8.cfm The 4 > gigabit Intel i350-AM4 controllers should work fine since they do on other > systems of the previous C2xxx systems. However, the 4 gigabit Marvell 88E1543 > controllers are unlikely to work as best I can tell. Doing an apropos search > for Marvell does not yield a man page that mentions this chipset. Not much > has happened with msk(4) or sk(4) recently. > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_msk.c > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_sk.c So you > probably will not have great support at this time. Something like the E300-8D > might be a better choice. I have been looking at the X10SDV boards > (especially the X10SDV-2C-TP4F and X10SDV-2C-TP8F) personally and will be > building some firewalls with them soon. Bryan @bsdjournal.net>
Re: FAQ: dmesg archive
This is the linux driver. I do not have the board yet, so no dmesgs. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/phy/marvell.c?h=v4.17.3 https://github.com/olerem/barebox/blob/master/drivers/net/phy/marvell.c http://lists.infradead.org/pipermail/barebox/2014-November/021362.html Sent from ProtonMail Mobile On Tue, Jun 26, 2018 at 20:50, Bryan Vyhmeister wrote: > Looking at Supermicro's page, it's pretty easy to get some answers. > http://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9A-8CN8.cfm The 4 > gigabit Intel i350-AM4 controllers should work fine since they do on other > systems of the previous C2xxx systems. However, the 4 gigabit Marvell 88E1543 > controllers are unlikely to work as best I can tell. Doing an apropos search > for Marvell does not yield a man page that mentions this chipset. Not much > has happened with msk(4) or sk(4) recently. > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_msk.c > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_sk.c So you > probably will not have great support at this time. Something like the E300-8D > might be a better choice. I have been looking at the X10SDV boards > (especially the X10SDV-2C-TP4F and X10SDV-2C-TP8F) personally and will be > building some firewalls with them soon. Bryan
Re: how to know the progressive state of dd
On Mon, Jun 25, 2018 at 06:07:23PM -0600, Todd C. Miller wrote: > As someone else mentioned you would use pkill on OpenBSD. > > However, you will also need to use SIGINFO, not SIGUSR1, to get > dd's status. BSD systems have traditionally used SIGINFO for this > purpose. Linux lacks SIGINFO so there is no consistent signal for > this kind of a thing there. > > - todd ... and do not send random signals to all processes. Find some way to target the right signal to the right process. For example from a shell script starting a dd background process use kill $! which will send a signal to the most recent background command. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
OpenIKED match on user/cert instead of gateway
hello misc, I got the requirement for a more exotic setup in which some road warriors are required to be in a different network segment. From strongSWAN I know it is possible to match connections based on userid/cert. iked.conf(5) only gives examples for different gateways. To cut a long story short - is it possible to do this in openiked or do I need to setup a separate instance? Cheers, Kim smime.p7s Description: S/MIME Cryptographic Signature
Re: Enabling ngx_http_addition_module on OpenBSD?
On Thu, Jun 28, 2018 at 10:26:12AM +0300, Özgür Kazancci wrote: > I don't want to build Nginx from source. I cannot do that - it's a > production server. > If this server is that important, that you can't afford the downtime for a restart (to load the new binaries), you should consider a loadbalancer and a second nginx, which you can update. If you update the other, the loadbalancer should recognize and don't forward any traffic. If you don't have machines for this, you could even do it on the same machine. Setup a local loadbalancer and two nginx instances to loadbalance. If the hardware dies, you will have your downtime anyways. But remember: Every downtime is your maintenance window ;). hth, Marc
Re: arpalert eating disk space until process is stopped
Hi, I have contacted author of the program and send him ktrace and fstat data, hoping he will find time to check where the problem might be. arpalert is running from root partition and do not write any files to this partition. Log is writen to /var partition and even if I disable all writes to disk (lease file, log file) space on root partition is still being consumed. If I stop the program and wait exactly 60 seconds, the space will be freed. fstat info: router2# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0a 300M 96.8M188M34%/ /dev/sd0d 4.9G176M4.5G 4%/home /dev/sd0e 4.9G1.1G3.6G23%/usr /dev/sd0f 4.9G530M4.1G11%/var mfs:29883 961M 22.0K913M 0%/tmp router2# fstat -p 2250 -s USER CMD PID FD MOUNTINUM MODE R/W SZ|DVXFERS KBYTES root arpalert2250 text / 31197 -rwxr-xr-x r 15407300 root arpalert2250 wd / 29572 drwx-- r 51200 root arpalert22500 / 30780 crw-rw-rw-rw null00 root arpalert22501 / 30780 crw-rw-rw-rw null00 root arpalert22502 / 30780 crw-rw-rw-rw null00 root arpalert22503 /var 311811 -rw-r--r-- w 1092610 root arpalert22504 clone 30396 crw---rw bpf0 180 42 root arpalert22505 / 31206 -rw-r-rw 610 router2# fstat -p 2250 -s USER CMD PID FD MOUNTINUM MODE R/W SZ|DVXFERS KBYTES root arpalert2250 text / 31197 -rwxr-xr-x r 15407300 root arpalert2250 wd / 29572 drwx-- r 51200 root arpalert22500 / 30780 crw-rw-rw-rw null00 root arpalert22501 / 30780 crw-rw-rw-rw null00 root arpalert22502 / 30780 crw-rw-rw-rw null00 root arpalert22503 /var 311811 -rw-r--r-- w 1092610 root arpalert22504 clone 30396 crw---rw bpf0 232 49 root arpalert22505 / 31206 -rw-r-rw 610 router2# fstat -p 2250 -s USER CMD PID FD MOUNTINUM MODE R/W SZ|DVXFERS KBYTES root arpalert2250 text / 31197 -rwxr-xr-x r 15407300 root arpalert2250 wd / 29572 drwx-- r 51200 root arpalert22500 / 30780 crw-rw-rw-rw null00 root arpalert22501 / 30780 crw-rw-rw-rw null00 root arpalert22502 / 30780 crw-rw-rw-rw null00 root arpalert22503 /var 311811 -rw-r--r-- w 1092610 root arpalert22504 clone 30396 crw---rw bpf0 237 50 root arpalert22505 / 31206 -rw-r-rw 610 router2# find / -inum 31197 /root/opt_arpalert/sbin/arpalert -- router2# find / -inum 29572 /root -- router2# find / -inum 30780 /dev/null -- router2# find /var -inum 311811 /var/log/arpalert.log -- router2# find / -inum 31206 /root/opt_arpalert/var/run/arpalert.pid only thing that grows is: root arpalert22504 clone 30396 crw---rw bpf0 237 50 best regards, RLW W dniu 2018-06-27 o 18:59, Stuart Henderson pisze: On 2018-06-26, RLW wrote: Hello, info: OpenBSD 4.8 (em interface) and 6.3 (ix interface), arpalert-2.0.12 (downloaded and compiled). Not related to this problem, but 4.8 is *really* old now, there have been many security fixes since then. problem: When arpalert is running disk space is being consumed, when arpalert is stopped (after 20 minutes of being active) disk space is freed (~3MB) (~10mb per hour). Is there something wrong with this program or is it a normal behavior when bpf is used? (some buffer grows??) I don't know arpalert, but that's not normal for things using bpf. What files does it have open? You can run fstat and get the filesystem mountpoint and inode number of any open files, then use find to locate them: # find /mountpoint -inum 1234 That might give some clues as to what's happening.
Re: Enabling ngx_http_addition_module on OpenBSD?
On 06/28/18 19:43, Stuart Henderson wrote: On 2018-06-28, Özgür Kazancci wrote: I need to use "add_before_body" and "add_after_body" directives for Nginx for my personal webpage, by setting them in nginx.conf. However, it seems that my Nginx installation (from OpenBSD packages) doesn't support these directives: a 'cat' to log file reports; "2018/06/28 09:14:09 [emerg] 52287#0: unknown directive "add_before_body" in /etc/nginx/nginx.conf:162" These directives probably belong to the module: ngx_http_addition_module. So, is there any way to dynamically activate that module without manually fetching and compiling Nginx on the system? I don't want to build Nginx from source. I cannot do that - it's a production server. Not sure how much work would be involved ... but I think that you could build and test on a machine set up as per your production machine? Then copy across the binary file(s). The module selection is part of the nginx build system - you can't do this without building nginx.
automatically rotate isakmpd.pcap
Hi all, I'm trying to rotate /var/run/isakmpd.pcap log, keeping 30 days of log files and rotating then everyday. With newsyslog, logs are being rotated, but new file "isakmpd.pcap" is not usable with tcpdump (message is "tcpdump: bad dump file format"). I've also tried to stop isakmpd writing isakmpd.pcap (echo p > isakmpd.fifo), but it didn't work. I tried also to SIGHUP isakmpd, but with bad results (IPSec stop working and had to restart isakmpd). This is the setup: # uname -a OpenBSD 6.1 GENERIC.MP#24 amd64 # cat newsyslog_ipsec.conf /var/run/isakmpd.pcap root:wheel 600 30* $D0 ZB "" This is the last test: echo p off > /var/run/isakmpd.fifo && newsyslog -Ff newsyslog_ipsec.conf && echo p on > /var/run/isakmpd.fifo Do you have any suggestion? Thank you in advance.
Re: Enabling ngx_http_addition_module on OpenBSD?
On 2018-06-28, Özgür Kazancci wrote: > I need to use "add_before_body" and "add_after_body" directives for Nginx > for my personal webpage, by setting them in nginx.conf. However, it seems > that my Nginx installation (from OpenBSD packages) doesn't support these > directives: > > a 'cat' to log file reports; > > "2018/06/28 09:14:09 [emerg] 52287#0: unknown directive "add_before_body" > in /etc/nginx/nginx.conf:162" > > These directives probably belong to the module: ngx_http_addition_module. So, > is there any way to dynamically activate that module without manually > fetching and compiling Nginx on the system? > > I don't want to build Nginx from source. I cannot do that - it's a > production server. The module selection is part of the nginx build system - you can't do this without building nginx.
Re: Is Intel PRO/1000 CT Desktop Adapter supported on amd64?
On Wed (27/06/18), Vijay Sankar wrote: > > Quoting John Long : > > I found a lot of PRO/1000 adapters listed in the em driver man page but > > CT version is not included. > > Since the CT version uses the Intel 82574L Controller, I think it will work. Indeed. I've got a couple of those and work just fine: $ sysctl kern.version kern.version=OpenBSD 6.3 (GENERIC.MP) #4: Sun Jun 17 11:22:20 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ dmesg | grep ^em em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address xx:xx:xx:xx:xx:xx
