Libreoffice package missing in i386 tree
Hi, Is the LibreOffice package in the i386 tree expected for OpenBSD 6.4? not listed the mirrors so far. Kihaguru
Re: VMM sh: time sleep 30 takes 56 seconds
On Fri, Oct 19, 2018 at 04:16:51AM +, Mike Larkin wrote: > On Thu, Oct 18, 2018 at 10:34:20PM -0300, Daniel Bolgheroni wrote: > > On Wed, Oct 17, 2018 at 08:42:46PM +, Mike Larkin wrote: > > > A 1000Hz host helps here. I get 10.32s real time on sleep 10 with that > > > setting. > > > > > > Note that qemu behaves the same way on OpenBSD. > > > > OK, the output is still slow when on serial, but things improved > > Is the console baudrate 9600 or 115200? It's running at 115200. $ vmctl start 1 -c Connected to /dev/ttyp7 (speed 115200) [ using 2145656 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 520093696 (496MB) avail mem = 495116288 (472MB) (...) Thank you. -- db
Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)
Dear All, I have managed to configure and get the output of the serial console on KVM and here is the output (with different CPU type only the name of the CPU changes) : ~~ >> OpenBSD/amd64 CDBOOT 3.40 boot> cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/6.4/amd64/bsd.rd: 354+1500160+3892040+0+598016 [372715+111+441072+293323]=0xa208a0 entry point at 0x1000158 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.Open BSD.org OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_C D real mem = 4278030336 (4079MB) avail mem = 4144590848 (3952MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6110 (11 entries) bios0: vendor SeaBIOS version "1.11.0-2.el7" date 04/01/2014 bios0: Red Hat KVM acpi0 at bios0: rev 0 acpi0: tables DSDT FACP APIC acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Opteron 63xx class CPU, 3992.09 MHz, 15-02-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36 ,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2A PIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,PAGE1GB,LONG,LAHF,ABM,SSE4A,MASSE, 3DNOWP,XOP,FMA4,TBM cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 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 fatal protection fault in supervisor mode trap type 4 code 0 rip 811c303c cs 8 rflags 10202 cr2 0 cpl e rsp 81a06a20 gsbase 0x81872ff0 kgsbase 0x0 panic: trap type 4, code=0, pc=811c303c The operating system has halted. Please press any key to reboot. ~~ Should I report this as a bug ? Best Regards, Strahil Nikolov On Sun, 2018-10-21 at 18:07 +0300, snikolov wrote: > Hello All, > > During install of install64.iso I experience a kernel panic during > boot of the CD (pc=811c303c). > install64.iso sha256sum is > 81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2 > which > matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256 > > I have tested with various CPUs on my RHEL 7.5 and it seems that > Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the > panic,while > Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I > got the installer prompt. > > Does anyone observes the same behaviour or it is only me ? > > Best Regards, > Strahil Nikolov
Re: FAM Question
FAM/gamin execute programs when parts of the filesystem change AFAIK. My goto program for this is entr (http://entrproject.org/) available as port under sysutils/entr (http://ports.su/sysutils/entr) Markus Rosjat schrieb am So., 21. Okt. 2018 10:54: > hi Julian, > > Am 20.10.2018 um 01:01 schrieb Julian Suschlik: > > Would sysutils/entr help? > > canyou be more specific? > > thank you > > -- > Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de > > G+H Webservice GbR Gorzolla, Herrmann > Königsbrücker Str. 70, 01099 Dresden > > http://www.ghweb.de > fon: +49 351 8107220 fax: +49 351 8107227 > > Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before > you print it, think about your responsibility and commitment to the > ENVIRONMENT > >
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
Ted Unangst wrote: > Ted Unangst wrote: > > Derek wrote: > > > Adding a "#!/bin/sh" at the top of the scripts made them all work again. > > > > i don't believe this is a change; that's how it should always work. > > sorry, this appears wrong. doas actually uses execvpe() from libc, which is > supposed to do the sh interpretation thing, except now it doesn't work right. > this is a behavior change. sorry for the burst of email. i was a little out of touch about what was happening. there were changes made, but they were not entirely expected or planned. old behavior: doas uses execvpe(), which as the man page notes, follows sh behavior and will execute the command using the sh if it has the x bit but lacks a magic header. new behavior: some unveil() calls were added to doas which restricts access to /bin/sh, meaning execvpe() no longer works as before. as hinted in my original reply below, i kind of like this behavior. the change to restrict commands to only those with valid headers was inadvertent, but the outcome seems positive. we will probably stick with it. so... the behavior changed, that's probably a bug, but we're going to call it a feature. problem solved. :) some documentation changes may be forthcoming to make everything clear. thanks for finding and reporting this. > > > > > > execve() returns ENOEXEC if the file doesn't have the right magic header. sh > > will attempt to interpret the file as a script after that error, but i don't > > think doas should have such a fallback. it may not be a sh script, and then > > weird and possibly bad things will happen (has happened before).
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
Ted Unangst wrote: > Derek wrote: > > Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed. > > > > I finally solved it, but just posting here in case anyone has this problem. > > > > I had a few little shell scripts in /usr/local/sbin/ - intended to be run > > by doas : one-liners like bioctl mounting a USB stick or whatever. > > > > After upgrading to OpenBSD 6.4, all of them returned a "command not found" > > error. I tried moving them to different paths in $PATH, but no luck. > > Yet they'd work if I was root - just not via doas. > > > > Adding a "#!/bin/sh" at the top of the scripts made them all work again. > > i don't believe this is a change; that's how it should always work. sorry, this appears wrong. doas actually uses execvpe() from libc, which is supposed to do the sh interpretation thing, except now it doesn't work right. this is a behavior change. > > execve() returns ENOEXEC if the file doesn't have the right magic header. sh > will attempt to interpret the file as a script after that error, but i don't > think doas should have such a fallback. it may not be a sh script, and then > weird and possibly bad things will happen (has happened before).
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
Derek wrote: > Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed. > > I finally solved it, but just posting here in case anyone has this problem. > > I had a few little shell scripts in /usr/local/sbin/ - intended to be run > by doas : one-liners like bioctl mounting a USB stick or whatever. > > After upgrading to OpenBSD 6.4, all of them returned a "command not found" > error. I tried moving them to different paths in $PATH, but no luck. > Yet they'd work if I was root - just not via doas. > > Adding a "#!/bin/sh" at the top of the scripts made them all work again. i don't believe this is a change; that's how it should always work. execve() returns ENOEXEC if the file doesn't have the right magic header. sh will attempt to interpret the file as a script after that error, but i don't think doas should have such a fallback. it may not be a sh script, and then weird and possibly bad things will happen (has happened before).
Re: pledge & unveil
thx for the speedy answer, theo. I will learn. Gesendet: Sonntag, 21. Oktober 2018 um 23:48 Uhr Von: "Theo de Raadt" An: "Heinz Kampmann" Cc: misc@openbsd.org Betreff: Re: pledge & unveil Heinz Kampmann wrote: > is there a paper on the web that explains work and relationship > from pledge and unveil for dummies? There are some talks at openbsd.org/events.html, the manual pages, and more than 300 examples in the source tree.
Re: pledge & unveil
Heinz Kampmann wrote: > is there a paper on the web that explains work and relationship > from pledge and unveil for dummies? There are some talks at openbsd.org/events.html, the manual pages, and more than 300 examples in the source tree.
pledge & unveil
Hello, is there a paper on the web that explains work and relationship from pledge and unveil for dummies? Best wishes, Heinz
amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)
Hello All, During install of install64.iso I experience a kernel panic during boot of the CD (pc=811c303c). install64.iso sha256sum is 81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2 which matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256 I have tested with various CPUs on my RHEL 7.5 and it seems that Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the panic,while Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I got the installer prompt. Does anyone observes the same behaviour or it is only me ? Best Regards, Strahil Nikolov
Re: relayd and radius
Shawn Southern(shawn.south...@entegrus.com) on 2018.10.19 18:01:41 +:
> So apparently this works... I was expecting relayd to listen on those ports,
> but I'm guessing that since it hooks through pf, that's not necessary.
It only listens if you use "relay". If you use "redirect", it uses pf tables
with rdr rules.
You should see something like this:
# pfctl -sA
relayd
# pfctl -sA -a relayd/*
relayd/radius
# pfctl -sr -a relayd/radius
pass in quick on rdomain 0 inet proto tcp from any to xxx.xxx.xxx.xxx port =
flags S/SA keep state (tcp.established 600) rdr-to
port round-robin
# pfctl -a relayd/radius -T show -t radius
a.b.c.d
a.b.c.e
Please read the section "REDIRECTIONS" in relayd.conf(5).
I admit the line "Specify an address and a port to listen on. pf(4) will
redirect..." could be rewritten.
/Benno
> -Original Message-
> From: owner-m...@openbsd.org On Behalf Of Shawn
> Southern
> Sent: October 19, 2018 1:00 PM
> To: misc@openbsd.org
> Subject: relayd and radius
>
> We have a lot of devices that use RADIUS, but they do not allow us to specify
> a 2nd RADIUS server. Since we use OpenBSD w/ CARP as our router/firewall, we
> want to use relayd to provide some redundancy for the RADIUS servers.
>
> There are two internal subnets - 10.10.10.0/24, which has our servers, and
> 10.10.11.0/24 that has the devices using RADIUS to authenticate clients.
> 10.10.10.1 and 10.10.11.1 are both carp interfaces.
>
> When starting relayd, nothing appears to be listening on the RADIUS ports.
> Is this even possible with relayd? Is my configuration just horribly wrong?
>
> relayd.conf:
> radius1 = "10.10.10.5"
> radius2 = "10.10.10.6"
> radius_listen = "10.10.11.1"
>
> table { $radius1 }
> table { $radius2 }
>
> redirect radius {
> listen on $radius_listen udp port 1812:1813
> forward to check icmp
> forward to check icmp
> }
>
> Thanks in advance for any help!
>
--
Re: OpenSMTPd: "mail.lmtp: connect: Connection refused"
On 2018-10-21 21:17, Gilles Chehade wrote:
On Wed, Oct 17, 2018 at 10:44:19PM +0300, Atanas Vladimirov wrote:
Hi misc,
Please, let me know if this mailing list is not the right place for
this
question.
I'm following -current and I found that maybe something is wrong with
my
setup.
When the server boots the first time after an upgrade the emails from
the
installer are lost because of `result=PermFail stat=Error ("mail.lmtp:
connect: Connection refused")`.
I did a few tests and the problem appears when the dovecot is not
running
(or before it's been started during the boot cycle).
hi,
for the record, the mail.lmtp mda was being too strict about the
connect
failures.
this was not an issue before because smtpd was being extremely
cautious,
handling all MDA failures as TempFail but this came with other issues
so
in 6.4 we aligned with Postfix handling only some exit codes as
tempfail
and all others as permfail.
diff going to the tree in a minute, tested by Atanas ;-)
Thanks for your fast reaction! Case closed :)
Re: VPN over alias address
Adding the route to other side network from the alias address does work: route add 192.168.99.0/24 50.79.22.45 On Sun, Oct 21, 2018 at 1:58 PM Sonic wrote: > > On Mon, Oct 15, 2018 at 7:17 PM Stuart Henderson wrote: > > The problem is _not_ that your source address is 50.79.22.41, > > because it wouldn't work with 50.79.22.45 either, you need to be > > using an address that is covered by the flows (say 192.168.55.1). > > > > Try "ping -I $source_ip $dest_ip" with various addresses as $source_ip > > and you should see better how it works. > > Using your ping example - it does work from the alias address of > 50.79.22.45 and not from the other addresses. > > > The usual bodge around this is to have a local address within the > > VPN'd network on your router (which is normally the case anyway - > > with examples above, say 192.168.55.1) and add a route to the > > "other side" network e.g."route add 192.168.99.0/24 192.168.55.1" > > - i.e. using your *own* address as the destination). > > Adding the route does not resolve the issue. > From a totally separate remote site, with no IP aliases on the ext_if > it works just fine. No route add necessary. > > Chris
Re: OpenSMTPd: "mail.lmtp: connect: Connection refused"
On Wed, Oct 17, 2018 at 10:44:19PM +0300, Atanas Vladimirov wrote:
> Hi misc,
>
> Please, let me know if this mailing list is not the right place for this
> question.
>
> I'm following -current and I found that maybe something is wrong with my
> setup.
> When the server boots the first time after an upgrade the emails from the
> installer are lost because of `result=PermFail stat=Error ("mail.lmtp:
> connect: Connection refused")`.
> I did a few tests and the problem appears when the dovecot is not running
> (or before it's been started during the boot cycle).
>
hi,
for the record, the mail.lmtp mda was being too strict about the connect
failures.
this was not an issue before because smtpd was being extremely cautious,
handling all MDA failures as TempFail but this came with other issues so
in 6.4 we aligned with Postfix handling only some exit codes as tempfail
and all others as permfail.
diff going to the tree in a minute, tested by Atanas ;-)
--
Gilles Chehade
https://www.poolp.org @poolpOrg
Re: VPN over alias address
On Mon, Oct 15, 2018 at 7:17 PM Stuart Henderson wrote: > The problem is _not_ that your source address is 50.79.22.41, > because it wouldn't work with 50.79.22.45 either, you need to be > using an address that is covered by the flows (say 192.168.55.1). > > Try "ping -I $source_ip $dest_ip" with various addresses as $source_ip > and you should see better how it works. Using your ping example - it does work from the alias address of 50.79.22.45 and not from the other addresses. > The usual bodge around this is to have a local address within the > VPN'd network on your router (which is normally the case anyway - > with examples above, say 192.168.55.1) and add a route to the > "other side" network e.g."route add 192.168.99.0/24 192.168.55.1" > - i.e. using your *own* address as the destination). Adding the route does not resolve the issue. >From a totally separate remote site, with no IP aliases on the ext_if it works just fine. No route add necessary. Chris
Re: ThinkPad X220 Trackpoint Pointer Wheel Emulation Issues
> The jumping up and down vertically should have been fixed via this > commit from @bru: > https://github.com/openbsd/xenocara/commit/a011f4db8a6b02f5b298f8b631330764f40aa037 Confirming that installing the new 6.4 release (which includes the linked patch) fixes the issue. For the sake of future Googlers or archive readers, this is all that was required for me to get pointer wheel emulation working as it should on the Thinkpad X220 under OpenBSD 6.4: xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation" 1 xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Button" 2 Thank you Jake and Matthias for your help! Charles
Re: Graphical debugger for C/C++ ?
On 10/11/18 10:40 AM, Kevin Chadwick wrote: On Thu, 11 Oct 2018 12:32:06 +0200 The gdb from packages is then called egdb. Make sure cgdb is using egdb, if you use cgdb too. I wanted to give cgdb a shot. How do I make sure its using egdb? Documentation is required for gdb unlike eclipse and could be better but once you find the commands you need it is actually more capable than eclipse.
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
>Adding a "#!/bin/sh" at the top of the scripts made them all work >again. Sounds like now the behavior is as it should be. If you really need the old behavior back you could try running the scripts with the dot command.
Re: Benchmarking kernel, userland and Xenocara build processes
Hi again, to elaborate a bit, the reason I'm interested in getting more detailed benchmark results for the build processes is that I've noticed there are many situations where servers with less hardware resources (CPU cores and RAM in particular) often seem to finish the builds quite a lot faster than ones with 4-8 times more cores and RAM. I'm well aware that OpenBSD's SMP implementation is rather young, but I'd be curious to seeing the exact details. I have a hunch it's the disk I/O speed that's causing some of the build time differences of the servers. Are there any "in-house" benchmarking tools the OpenBSD dev team is using to measure the build times? - Jyri -- +358-404-177133 (24/7) jyri.hov...@turvamies.fi
Benchmarking kernel, userland and Xenocara build processes
Hi! I have a handful of OpenBSD (CURRENT) instances, running on different VPS and full iron platforms. Since I use CURRENT, keeping up to date means I have the opportunity to watch and compare the build process durations of the kernel, the userland, and Xenocara. For now, I've simply clocked the time it takes for the build processes to run from start to finish. I'd like to do much more detailed benchmarking, in order to see where the bottlenecks are on each different server. I'd like to receive some tips on how to do the benchmarking -- which tools to use, etc. Been doing some googling but I haven't found anything lightweight enough, and would prefer using OpenBSD's built-in tools instead of any third-party stuff. - Jyri -- +358-404-177133 (24/7) jyri.hov...@turvamies.fi
cert is not valid for https://cloudflare.cdn.openbsd.org
Hi. Certificate is not valid from 20 Oct. for https://cloudflare.cdn.openbsd.org. Thank you, OpenBSD team! ) Regards, Alex Fedorov
Re: FAM Question
hi Julian, Am 20.10.2018 um 01:01 schrieb Julian Suschlik: Would sysutils/entr help? canyou be more specific? thank you -- Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
6.4 doas gives "command not found" if no #!/bin/sh up top
Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed. I finally solved it, but just posting here in case anyone has this problem. I had a few little shell scripts in /usr/local/sbin/ - intended to be run by doas : one-liners like bioctl mounting a USB stick or whatever. After upgrading to OpenBSD 6.4, all of them returned a "command not found" error. I tried moving them to different paths in $PATH, but no luck. Yet they'd work if I was root - just not via doas. Adding a "#!/bin/sh" at the top of the scripts made them all work again. Just FYI. - Derek
