Re: permissions problems after update

[Stuart Henderson]

On 2017-03-10, Allan Streib  wrote:
> Solved. As these things usually are, it was simple in hindsight.
>
> # ls -ld /
> drwxr-x---  13 root  wheel  512 Mar  7 15:09 /

Ah, I should have thought of checking directory perms. There are
definitely somesituarions where pkg_add (which is used by openup) has
problems if run with a restrictive umask, so it might be somethimg to
do with that, or it might be something to do with the script that gets
run when the binpatch package is installed. You'll have better luck with
these if you "umask 022" before running them.

Re: permissions problems after update

[Allan Streib]

Solved. As these things usually are, it was simple in hindsight.

# ls -ld /
drwxr-x---  13 root  wheel  512 Mar  7 15:09 /

I was looking at a ktrace trying to run the "doas -u im3 id -p" and saw
it trying all the possible paths, and that gave me the hunch to check
permissions on the root.

14751 doas CALL execve(0x7f7cc870,0x7f7cdfd0,0x1c5559226680)
14751 doas NAMI  "/sbin/id"
14751 doas RET   execve -1 errno 13 Permission denied
14751 doas CALL execve(0x7f7cc870,0x7f7cdfd0,0x1c5559226680)
14751 doas NAMI  "/usr/sbin/id"
14751 doas RET   execve -1 errno 13 Permission denied
14751 doas CALL execve(0x7f7cc870,0x7f7cdfd0,0x1c5559226680)
14751 doas NAMI  "/bin/id"
14751 doas RET   execve -1 errno 13 Permission denied
14751 doas CALL execve(0x7f7cc870,0x7f7cdfd0,0x1c5559226680)
14751 doas NAMI  "/usr/bin/id"
14751 doas RET   execve -1 errno 13 Permission denied
14751 doas CALL execve(0x7f7cc870,0x7f7cdfd0,0x1c5559226680)
14751 doas NAMI  "/usr/X11R6/bin/id"
14751 doas RET   execve -1 errno 13 Permission denied
14751 doas CALL execve(0x7f7cc870,0x7f7cdfd0,0x1c5559226680)
14751 doas NAMI  "/usr/local/sbin/id"
14751 doas RET   execve -1 errno 13 Permission denied
14751 doas CALL execve(0x7f7cc870,0x7f7cdfd0,0x1c5559226680)
14751 doas NAMI  "/usr/local/bin/id"
14751 doas RET   execve -1 errno 13 Permission denied
   
I have an idea how that happened, I had changed my default umask in
/etc/login.conf from 022 to 027, so that new files would get created
without any "other" permissions.

Something must have "recreated" the / directory? Thus wiping the r-x
permission for "other" users. The timestamp shown on / roughly
corresponds (from memory) to my running of the openup command.

So, changing default umask to 027 is a "bad" idea? Or is this something
that shouldn't really be happening?

Allan

Re: FFS parameters for SSD filesystem?

[Nick Holland]

On 03/09/17 15:20, Christian Weisgerber wrote:
> On 2017-03-09, Jonathan Thornburg  wrote:
> 
>> Subject: FFS parameters for SSD filesystem?
> 
> You are overthinking this.  The defaults are fine.

What he said.

An SSD is a SATA storage device.
It's the 2010s.
JUST USE IT.
Knob twisting for file systems went out with the 1990s.

It will either give you trouble in the first weeks or last until long
after you are laughing at how small a 1TB of storage is, how big a 2.5"
disk is, and how slow the SATA interface is.

FFS2 is nice for big storage areas, but NOTHING to do with SSD or non-SSD.

(ok, update the firmware for your SSD.  that's something that should
have stopped after the 1990s, too, but surprise: the computer industry
sells crap and you line up to buy it.  I've had that exact disk give me
trouble that seems to have settled down by dd'ing zeros over entire
partitions before using them.  Your milage may vary.)

Nick.

Re: OpenBSD 6.0 - Silicom PE2G4SFPI35L Intel i340AM4 based

[Stuart Henderson]

On 2017-03-09, Uday MOORJANI  wrote:
> Dear Community,
>
> Hope all is well. I'm on my last stretch to put in production our
> OpenBSD/OpenBGPd implementation. I have chosen a SuperMicro box as my
> platform, some of our transit providers at the data center come in
> through 1000-Base-LX fiber cross connects hence the search for an SFP
> and LX capable network card.
>
> My question is, does the em driver work with Intel-based network cards
> of other vendors such as the Silicom PE2G4SFPI35L or the PE2G4SFPI80L,
> both respectively are based on Intel i340AM4 and 82580EB controllers.

I haven't tried those Silicom cards but I have a couple of 6-port
HotLava 1000base-T em(4) cards which are working nicely.

I don't see I340AM4 on the list in the em(4) manual. I can't say whether
this is just an omission from the manual, or whether it's unsupported.
82580EB is listed there.

> Or is there another card with 4-Ports 1000-Base-LX capable hardware I
> missed?
>
> Sincerely,
>
> Uday MOORJANI
>
> PS
> Loving the OS.
>
>

When I had a circuit delivered on single-mode fibre I couldn't find
a suitable 1Gb SFP card for any sensible money so I used a 10Gb card
instead (in my case some 82599-based Intel SFP+ which uses the ix(4)
driver), which also work with 1Gb SFPs.

$ ifconfig ix1 | grep -e ^ix -e media
ix1: flags=8843 mtu 1500
media: Ethernet autoselect (1000baseLX full-duplex,rxpause,txpause)

$ dmesg | grep ^ix1 | tail -1
ix1 at pci1 dev 0 function 1 "Intel 82599" rev 0x01: msi, address 
00:1b:21:c0:25:bd

Re: permissions problems after update

[Allan Streib]

Another observvation, mysqld won't start, similar issues:

170309 17:39:26 [ERROR] mysqld: Can't create/write to file '/tmp/ibMnUE5T' 
(Errcode: 13 "Permission denied")
2017-03-09 17:39:26 2739dade4e0  InnoDB: Error: unable to create temporary 
file; errno: 13
170309 17:39:26 [ERROR] Plugin 'InnoDB' init function returned error.
170309 17:39:26 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
170309 17:39:26 [ERROR] mysqld: Can't create/write to file 
'/var/mysql/aria_log_control' (Errcode: 13 "Permission denied")
170309 17:39:26 [ERROR] mysqld: Got error 'Can't create file' when trying to 
use aria control file '/var/mysql/aria_log_control'


dmesg, in case it helps

OpenBSD 6.0 (GENERIC.MP) #2: Mon Oct 17 10:22:47 CEST 2016

r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 25739890688 (24547MB)
avail mem = 24955326464 (23799MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xcf49c000 (84 entries)
bios0: vendor Dell Inc. version "6.2.3" date 04/26/2012
bios0: Dell Inc. PowerEdge R710
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DM__ MCFG WD__ SLIC ERST HEST BERT EINJ 
SRAT TCPA SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 32 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2527.32 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 1
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 0 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 1596.00 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 0, package 0
cpu2 at mainbus0: apid 34 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2527.00 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 1
cpu3 at mainbus0: apid 2 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 1596.00 MHz
cpu3: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 1, package 0
cpu4 at mainbus0: apid 50 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2527.00 MHz
cpu4: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 9, package 1
cpu5 at mainbus0: apid 18 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 1596.00 MHz
cpu5: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 0, core 9, package 0
cpu6 at mainbus0: apid 52 (application processor)
cpu6: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2527.00 MHz
cpu6: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 0, core 10, package 1
cpu7 at mainbus0: apid 20 (application processor)
cpu7: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 1596.00 MHz
cpu7: 

Re: Please: Is there ANY chance that Linux binaries might run again???

[Stuart Henderson]

On 2017-03-09, Stefan Wollny  wrote:
>> Gesendet: Donnerstag, 09. März 2017 um 09:43 Uhr
>> Von: "Stuart Henderson" 
>> An: misc@openbsd.org
>> Betreff: Re: Please: Is there ANY chance that Linux binaries might run
> again???
>>
>> On 2017-03-07, Stefan Wollny  wrote:
>> > at home this is the way I go, too. But I have to travel to my client's
>> > place (by train!) and when working in the evening in the hotel room like
>> > tonight (as I have to leave the office building by 8 pm at the latest)
>> > it is somewhat inconvenient to take a second laptop with me.
>>
>> Is qemu any good for this or is it too slow?
> I am not at all familiar with qemu but doesn't this imply to run Win* on my
> OpenBSD-system?
> NEVER, EVER!

It's a machine emulator with BIOS etc. It's sometimes used with
a separate hypervisor like KVM to run VMs, but also emulates CPUs
in userland (which looks rather like a VM but slower).

(Though TBH I'd probably prefer recent Windows over Linux for this..)

>> Additionally, while the answer to "is there any chance" is no, the
>> answer to "any chance 32-bit Linux binaries will run on OpenBSD/amd64"
>> would be "hell no".
>:-D
> Is it correct then to imply that 64-bit binaries might run?

No, there was never any compat with other OS binaries in OpenBSD/amd64.
(And unlike Linux, 32-bit OpenBSD binaries won't run on OpenBSD/amd64).

Re: Setting rtable 0 from >1 with ping et al

[Joe Holden]

On 09/03/2017 23:02, Joe Holden wrote:

Hi,

So - it seems that pledge will deny a change of rtable to 0 when using
level SOL_SOCKET and the current rtable is >0, so eg if you're in table
1 and you do ping -V0 it will fail.

Can anyone shed any light on why this is restricted?  Especially since
the same can be achieved with route -T0 exec

Thanks!

Actually, just realised why it doesn't work - it drops privs before 
setting rtable, nevermind.

Re: Please: Is there ANY chance that Linux binaries might run again???

[Stefan Wollny]

Am 03/09/17 um 21:55 schrieb Marc Espie:
...
> In my opinion, there's more chance vmm will eventually be mature
> enough to run a virtual linux machine than the return of userland
> linux emulation.
> 
This is what I am hoping for - it is just this particular piece of
software that I need from time to time. Anything else I can achieve with
what OpenBSD offers (or more precisely: what the OpenBSD-devs kindly
provide).

But who knows - maybe some future version of LibreOffice (or any other
free/open program) is good enough to meet my requirements (in particular
formats).

Re: Please: Is there ANY chance that Linux binaries might run again???

[Stefan Wollny]

Am 03/09/17 um 22:44 schrieb bofh:
> On Tue, Mar 7, 2017 at 4:01 PM, Stefan Wollny  wrote:
> 
>> Hi there,
>>
>> I have to live up to my obligations - and one of them is to be able to
>> work with M$-Word docs. I used to do this with SoftMaker's office suite,
>> but since Linux-compat is gone I am stuck with LibreOffice which is just
>> a PITA.
>>
> 
> If you have Internet access, why not use Google Docs or one of the other
> web based apps?
> 

For the very reason I use OpenBSD: Confidentiality.

The financial industry takes 'confidentiality' quite serious - if you're
in a weak position. ;-)

Technically I may be the 'owner' of the documents but legally it is my
client. And being just a self-employed mini-business I cannot engage a
big legal dept to discuss any implications that may arise from using
web-/cloud-based office solutions.

Nevertheless: Thank you for bringing such a solution up.

Best,
STEFAN

Setting rtable 0 from >1 with ping et al

[Joe Holden]

Hi,

So - it seems that pledge will deny a change of rtable to 0 when using 
level SOL_SOCKET and the current rtable is >0, so eg if you're in table 
1 and you do ping -V0 it will fail.


Can anyone shed any light on why this is restricted?  Especially since 
the same can be achieved with route -T0 exec


Thanks!

Re: Please: Is there ANY chance that Linux binaries might run again???

[bofh]

On Tue, Mar 7, 2017 at 4:01 PM, Stefan Wollny  wrote:

> Hi there,
>
> I have to live up to my obligations - and one of them is to be able to
> work with M$-Word docs. I used to do this with SoftMaker's office suite,
> but since Linux-compat is gone I am stuck with LibreOffice which is just
> a PITA.
>

If you have Internet access, why not use Google Docs or one of the other
web based apps?

Re: Please: Is there ANY chance that Linux binaries might run again???

[Marc Espie]

To clarify, from what I remember, killing linux compat was not
a political decision per-se ("emulation is bad").

Rather, it is that the emulation was 32 bits-only, and more and
more out-of-date so completelely useless, and also not really
very maintained, so it amounted to more code with possible nasty
bugs and holes, on a subsystem that wasn't useable anymore.

It is very unlikely it will come back, because it would require
someone to do a lot of work to actually make it useful.

In my opinion, there's more chance vmm will eventually be mature
enough to run a virtual linux machine than the return of userland
linux emulation.

Re: FFS parameters for SSD filesystem?

[Christian Weisgerber]

On 2017-03-09, Jonathan Thornburg  wrote:

> Subject: FFS parameters for SSD filesystem?

You are overthinking this.  The defaults are fine.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: FFS parameters for SSD filesystem?

[Otto Moerbeek]

On Thu, Mar 09, 2017 at 12:08:56PM -0500, Jonathan Thornburg wrote:

> Hi,
> 
> I'm preparing to set up a new 1TB SSD (Samsung 850pro) for use in an
> OpenBSD laptop.  Like every other SSD I've seen, this SSD uses a 4K
> byte block size.
> 
> I'm planning to use softraid crypto for this disk, and mount all the
> main filesystems with softdep and noatime.
> 
> I understand that fdisk and disklabel partition boundaries should
> be multiples of 4K bytes (= 8 512-byte sectors), e.g., starting the
> 'a' disklabel partition at offset=64 512-byte sectors is much better
> than starting it at offset=63.
> 
> I've read the misc@ thread on "4k sector disks" from 2010,
>   http://marc.info/?l=openbsd-misc=127071305915101=1
>   http://marc.info/?l=openbsd-misc=127149466227162=1
> tedu's 2011 blog post "lessons learned about TRIM",
>   http://www.tedunangst.com/flak/post/lessons-learned-about-TRIM
> and the 2014 daemonforums thread on SSD installs,
>   http://daemonforums.org/showthread.php?t=8630
> 
> Questions:
> * Should I set the FFS fragment size (newfs -f) to 4096 or larger?

Don't think it is needed to set manyally, should be handled automatically.

> * What about the FFS sector size (newfs -S): should this be left at
>   its default, or set to 4096?

Default will be 4096 on a 4k disk.

> * Are there other fdisk and/or newfs parameters which should be set
>   differently than I'd set them for a mechanical hard disk of similar
>   size?

Nope.

> * What are the tradeoffs between FFS (newfs -O 1) and FFS2 (newfs -O 2)?
>   Since this is OpenBSD, perhaps I should rephrase this question as
>   "what Fine Manual should I have read to learn about these tradeoffs?"

If you have large partitions Lets say > 100G), go for -O2. Saves quite
some time. If you plan to store many large files and few small files,
go for a larger blocksize (and possibly fragment size).

> * Does or should using softraid crypto change the answers to any of
>   the above questions?

Cannot tell that,

-Otto

FFS parameters for SSD filesystem?

[Jonathan Thornburg]

Hi,

I'm preparing to set up a new 1TB SSD (Samsung 850pro) for use in an
OpenBSD laptop.  Like every other SSD I've seen, this SSD uses a 4K
byte block size.

I'm planning to use softraid crypto for this disk, and mount all the
main filesystems with softdep and noatime.

I understand that fdisk and disklabel partition boundaries should
be multiples of 4K bytes (= 8 512-byte sectors), e.g., starting the
'a' disklabel partition at offset=64 512-byte sectors is much better
than starting it at offset=63.

I've read the misc@ thread on "4k sector disks" from 2010,
  http://marc.info/?l=openbsd-misc=127071305915101=1
  http://marc.info/?l=openbsd-misc=127149466227162=1
tedu's 2011 blog post "lessons learned about TRIM",
  http://www.tedunangst.com/flak/post/lessons-learned-about-TRIM
and the 2014 daemonforums thread on SSD installs,
  http://daemonforums.org/showthread.php?t=8630

Questions:
* Should I set the FFS fragment size (newfs -f) to 4096 or larger?
* What about the FFS sector size (newfs -S): should this be left at
  its default, or set to 4096?
* Are there other fdisk and/or newfs parameters which should be set
  differently than I'd set them for a mechanical hard disk of similar
  size?
* What are the tradeoffs between FFS (newfs -O 1) and FFS2 (newfs -O 2)?
  Since this is OpenBSD, perhaps I should rephrase this question as
  "what Fine Manual should I have read to learn about these tradeoffs?"
* Does or should using softraid crypto change the answers to any of
  the above questions?

Thanks,
-- 
-- "Jonathan Thornburg [remove -color to reply]" 
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
at any given moment.  How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork.  It was even conceivable
that they watched everybody all the time."  -- George Orwell, "1984"

Re: File Server with OpenBSD?

[Karel Gardas]

On Thu, Mar 9, 2017 at 12:13 PM, Roderick  wrote:
> And where are the planned checksums written?

First version divided partition to data and checksum areas which means
RAID1 with checksums and RAID1 were compatible in a sense that if
something terribly happen in checksumming code, then you still may get
data while attaching as RAID1. Current version is using 512k data + 4k
checkksum scheme which makes it incompatible with plain RAID1.

> I ask this because I want to know if I will make me dependent of
> todays stand of OpenBSD.
>
> Mounting ffs partitions of OpenBSD in FreeBSD and the opposite
> is possible without big problems. Will this change with Raid?

Yes, as FreeBSD does not know anything about OpenBSD's software raid.

Karel

Re: Bizarre arp entry corruption

[Joe Holden]

On 09/03/2017 11:51, Martin Pieuchot wrote:

On 07/03/17(Tue) 19:38, Joe Holden wrote:

On 12/12/2016 16:55, Joe Holden wrote:

On 12/12/2016 10:27, Martin Pieuchot wrote:

On 11/12/16(Sun) 00:50, Joe Holden wrote:

On 10/12/2016 08:43, Mihai Popescu wrote:

seeing some bizarre behaviour on one box, on one specific interface:


Hello,

This looks like some stupid TV game, where contesters are given some
clues from time to time and they have to guess what is the real shit.

Do post your FULL dmesg and configurations for network if you really
want someone to even think at your issue. Isn't that obvious?

Bye!



Appreciate the useless response (but still better than nothing!), the
affected box has since been reverted to older snapshot and thus no more
debugging can be done - someone else will have to do it.


I'd appreciate to see the output of 'netstat -rnf inet' when it is
relevant.  Without that information it's hard to understand.

But there's a bug somewhere, it has to be fixed.


Not that dmesg is even relevant since it is a userland bug not a kernel
problem but anyway:


It's a kernel problem.


I'll see if I can recreate it but I'm not holding my breath - it only
breaks once BGP loaded the table which leads me to thing it is actually
bgpd that is updating the llinfo with bogus info and even though I have
a feed in my lab it doesn't do the same thing.


Ok so, inadvertantly recreated this (pretty much exactly the same) issue on
a lab/test setup:

For the purposes of debug, ignore the fact that the interfaces are tap
interfaces, they're still emulated ethernet...

Wall of text incoming, various info...

box#1:

tap1: flags=8843 mtu 1500
lladdr fe:e1:ba:d1:be:f3
index 7 priority 0 llprio 3
groups: tap
status: active
inet 172.20.230.72 netmask 0xfffe

box#2:

tap1: flags=8843 mtu 1500
lladdr fe:e1:ba:d1:cf:92
index 7 priority 0 llprio 3
groups: tap
status: active
inet 172.20.230.73 netmask 0xfffe

All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows
the following:

Host Ethernet AddressNetif Expire Flags
172.20.230.7200:00:00:00:20:12   ? 12m30s

# route -n get 172.20.230.72
   route to: 172.20.230.72
destination: 172.20.230.72
   mask: 255.255.255.255
  interface: tap1
 if address: 172.20.230.73
   priority: 3 ()
  flags: 
 use   mtuexpire
  20 0   702

flags destination  gateway  lpref   med aspath origin
IS*>  172.20.230.72/31 172.20.230.64  200 0 i

.64 is the loopback on one of its connected boxes that doesn't have broken
entries

tcpdump looks ok, afterwards:

19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73
19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73
19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3

but the correct entry is never installed, after I delete the broken arp
entry it never readds a new one.

This only happens with redist connected as far as I can tell, but bgpd
probably shouldn't be able to mangle arp entries and prevent the correct one
being added.


Here's the fix.

Index: net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.232
diff -u -p -r1.232 rtsock.c
--- net/rtsock.c7 Mar 2017 09:23:27 -   1.232
+++ net/rtsock.c8 Mar 2017 16:06:22 -
@@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct
}
}
 change:
-   if (info->rti_info[RTAX_GATEWAY] != NULL && (error =
-   rt_setgate(rt, info->rti_info[RTAX_GATEWAY],
-   tableid)))
-   break;
+   if (info->rti_info[RTAX_GATEWAY] != NULL) {
+   /*
+* When updating the gateway, make sure it's
+* valid.
+*/
+   if (!newgate && rt->rt_gateway->sa_family !=
+   info->rti_info[RTAX_GATEWAY]->sa_family) {
+   error = EINVAL;
+   break;
+   }
+
+   error = rt_setgate(rt,
+   info->rti_info[RTAX_GATEWAY], tableid);
+   if (error)
+   break;
+   }
 #ifdef MPLS
if ((rtm->rtm_flags & RTF_MPLS) &&
info->rti_info[RTAX_SRC] != NULL) {

Re: Running OpenBSD on Hypervisor

[Phil Eaton]

Strictly speaking there is only a small subset of _Linux_ distros that are
supported. To get anything else running you need to manually install them
yourself: https://forum.linode.com/viewtopic.php?f=20=12080. But after
doing this for a long time, I set up a private ftp server to host
filesystem images for FreeBSD and OpenBSD and made a script to automate the
deploy.

This automated deploy is a work in progress (though it does work). Until
I'm able to open it up (as a community project most likely), you'll have to
do the install yourself. In both cases, you won't be able to get official
Linode support for either (among other things, this means backups and
password resets from the Manager won't work). But I'm pushing for that at
some point too and trying to build interest / awareness.

On Thu, Mar 9, 2017 at 3:29 AM, Gareth Nelson 
wrote:

> Is this something special that you had due to being staff or can regular
> customers order VMs with OpenBSD?
>
> I'm a linode customer and would love to run OpenBSD (or FreeBSD, but I do
> prefer OpenBSD) there.
>
> On Wed, Mar 8, 2017 at 3:22 PM, Phil Eaton  wrote:
>
>> I have OpenBSD (and FreeBSD) running on Linode VMs (on a KVM host) and it
>> works well enough. I'm more than hazy on the details, but the issue as far
>> as I'm aware is that OpenBSD does not yet have full support for virtio. So
>> I need to use full virtualization for it to recognize my disks and network
>> devices. Presumably this affects performance, but I haven't gotten into
>> testing it much and haven't noticed it in my (admittedly light) use so
>> far.
>>
>> At home I have FreeBSD running on Hyper-V and it works well too. But
>> FreeBSD has better support for the virtio drivers so I'd expect it to
>> perform better in both cases.
>>
>> Disclosure: I work for Linode.
>>
>> On Wed, Mar 8, 2017 at 10:07 AM, Markus Rosjat  wrote:
>>
>> > Hi there,
>> >
>> > just like to get opinions or examples of OpenBSd as guest on a
>> hypervisor.
>> > I had it running on a VMware Host but since the free version is missing
>> > quiet a lot features I was wondering where to look at. I also tried
>> Hyper-V
>> > from MS and this looks qiet ok. So if the "virtual" guys like to share
>> > there expericence it would be nice. Im open for every thing so KVM or
>> BHive
>> > are points Ive looked at but haven't tried for now.
>> >
>> > thanks for the input
>> >
>> > regards
>> > --
>> > Markus Rosjatfon: +49 351 8107223mail: 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
>> >
>> >
>>
>>
>> --
>> Phil Eaton
>>
>>
>


--
Phil Eaton

OpenBSD 6.0 - Silicom PE2G4SFPI35L Intel i340AM4 based

[Uday MOORJANI]

Dear Community,

Hope all is well. I'm on my last stretch to put in production our
OpenBSD/OpenBGPd implementation. I have chosen a SuperMicro box as my
platform, some of our transit providers at the data center come in
through 1000-Base-LX fiber cross connects hence the search for an SFP
and LX capable network card.

My question is, does the em driver work with Intel-based network cards
of other vendors such as the Silicom PE2G4SFPI35L or the PE2G4SFPI80L,
both respectively are based on Intel i340AM4 and 82580EB controllers.
Or is there another card with 4-Ports 1000-Base-LX capable hardware I
missed?

Sincerely,

Uday MOORJANI

PS
Loving the OS.

Re: Bizarre arp entry corruption

[Martin Pieuchot]

On 07/03/17(Tue) 19:38, Joe Holden wrote:
> On 12/12/2016 16:55, Joe Holden wrote:
> > On 12/12/2016 10:27, Martin Pieuchot wrote:
> > > On 11/12/16(Sun) 00:50, Joe Holden wrote:
> > > > On 10/12/2016 08:43, Mihai Popescu wrote:
> > > > > > > seeing some bizarre behaviour on one box, on one specific 
> > > > > > > interface:
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > This looks like some stupid TV game, where contesters are given some
> > > > > clues from time to time and they have to guess what is the real shit.
> > > > > 
> > > > > Do post your FULL dmesg and configurations for network if you really
> > > > > want someone to even think at your issue. Isn't that obvious?
> > > > > 
> > > > > Bye!
> > > > > 
> > > > 
> > > > Appreciate the useless response (but still better than nothing!), the
> > > > affected box has since been reverted to older snapshot and thus no more
> > > > debugging can be done - someone else will have to do it.
> > > 
> > > I'd appreciate to see the output of 'netstat -rnf inet' when it is
> > > relevant.  Without that information it's hard to understand.
> > > 
> > > But there's a bug somewhere, it has to be fixed.
> > > 
> > > > Not that dmesg is even relevant since it is a userland bug not a kernel
> > > > problem but anyway:
> > > 
> > > It's a kernel problem.
> > > 
> > I'll see if I can recreate it but I'm not holding my breath - it only
> > breaks once BGP loaded the table which leads me to thing it is actually
> > bgpd that is updating the llinfo with bogus info and even though I have
> > a feed in my lab it doesn't do the same thing.
> > 
> Ok so, inadvertantly recreated this (pretty much exactly the same) issue on
> a lab/test setup:
> 
> For the purposes of debug, ignore the fact that the interfaces are tap
> interfaces, they're still emulated ethernet...
> 
> Wall of text incoming, various info...
> 
> box#1:
> 
> tap1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d1:be:f3
> index 7 priority 0 llprio 3
> groups: tap
> status: active
> inet 172.20.230.72 netmask 0xfffe
> 
> box#2:
> 
> tap1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d1:cf:92
> index 7 priority 0 llprio 3
> groups: tap
> status: active
> inet 172.20.230.73 netmask 0xfffe
> 
> All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows
> the following:
> 
> Host Ethernet AddressNetif Expire Flags
> 172.20.230.7200:00:00:00:20:12   ? 12m30s
> 
> # route -n get 172.20.230.72
>route to: 172.20.230.72
> destination: 172.20.230.72
>mask: 255.255.255.255
>   interface: tap1
>  if address: 172.20.230.73
>priority: 3 ()
>   flags: 
>  use   mtuexpire
>   20 0   702
> 
> flags destination  gateway  lpref   med aspath origin
> IS*>  172.20.230.72/31 172.20.230.64  200 0 i
> 
> .64 is the loopback on one of its connected boxes that doesn't have broken
> entries
> 
> tcpdump looks ok, afterwards:
> 
> 19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73
> 19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
> 19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73
> 19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
> 
> but the correct entry is never installed, after I delete the broken arp
> entry it never readds a new one.
> 
> This only happens with redist connected as far as I can tell, but bgpd
> probably shouldn't be able to mangle arp entries and prevent the correct one
> being added.

Here's the fix.

Index: net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.232
diff -u -p -r1.232 rtsock.c
--- net/rtsock.c7 Mar 2017 09:23:27 -   1.232
+++ net/rtsock.c8 Mar 2017 16:06:22 -
@@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct
}
}
 change:
-   if (info->rti_info[RTAX_GATEWAY] != NULL && (error =
-   rt_setgate(rt, info->rti_info[RTAX_GATEWAY],
-   tableid)))
-   break;
+   if (info->rti_info[RTAX_GATEWAY] != NULL) {
+   /*
+* When updating the gateway, make sure it's
+* valid.
+*/
+   if (!newgate && rt->rt_gateway->sa_family !=
+   info->rti_info[RTAX_GATEWAY]->sa_family) {
+   error = EINVAL;
+   break;
+   }
+
+   error = 

Re: Please: Is there ANY chance that Linux binaries might run again???

[Stefan Wollny]

> Gesendet: Donnerstag, 09. März 2017 um 09:43 Uhr
> Von: "Stuart Henderson" 
> An: misc@openbsd.org
> Betreff: Re: Please: Is there ANY chance that Linux binaries might run
again???
>
> On 2017-03-07, Stefan Wollny  wrote:
> > at home this is the way I go, too. But I have to travel to my client's
> > place (by train!) and when working in the evening in the hotel room like
> > tonight (as I have to leave the office building by 8 pm at the latest)
> > it is somewhat inconvenient to take a second laptop with me.
>
> Is qemu any good for this or is it too slow?
I am not at all familiar with qemu but doesn't this imply to run Win* on my
OpenBSD-system?
NEVER, EVER!

>
> Otherwise the easiest way at present is probably to dual-boot or boot
> Linux from a USB stick, or run it on a remote system.
Shorthandedly this is my way to get the job done: Installed Linux on a
USB3-Stick with dd-comand from iso. Runs acceptably fast. Just need to switch
from BIOS to UEFI.

The only thing I noticed: Working at some distance to the WLAN access point
with OpenBSD I have a connection but not with Linux though using the same
hardware (iwm0).
Another good reason to stick with OpenBSD and donate (already I miss the
anticipation of receiving another set of CDs).

>
> Additionally, while the answer to "is there any chance" is no, the
> answer to "any chance 32-bit Linux binaries will run on OpenBSD/amd64"
> would be "hell no".
:-D
Is it correct then to imply that 64-bit binaries might run?

>
> > Yes - I will (again) contact SoftMaker trying to persuade them to
> > provide an OpenBSD-version of their office suite. But they seem to have
> > none with some decent Unix/OpenBSD-knowledge, just Linux. Sigh...
>
> They'll need a new binary for every OS uodate, and a different one for
> 32/64 bit. While I'd love to see it (I paid for softmaker office and prefer
> it over libreoffice or MSWord), I think this is unrealistic.
>
Yupp - I know why I asked here. I've used it on OpenBSD until Linux-compat was
gone and everytime I tried to work with LibreOffice since I missed Softmake's
office tools even more.
(BTW - if the city of Munich had chosen to use Softmaker's office with LiMux I
bet there would habe been less complaints about compatability with
M$-documents. My 2c.)

Just to be clear: LibreOffice is accaptable as long as it is LibreOffice
only!

Even though I am aware of the implications that come with an OpenBSD-version
for Softmaker I will still ask - sometimes one has to try the unrelistic to
make a progress. ;-)
(As they support Mozilla's Thunderbird I hope they will at least listen before
saying NO.)

Re: permissions problems after update

[Allan Streib]

Stuart Henderson  writes:

> Seems odd. Let's check the permissions on things needed for ftp...
> Can you show the output from this (as root if necessary),
>
> ls -l $(ldd /usr/bin/ftp | awk '/\// { print $7 }')
>

$ ls -l $(ldd /usr/bin/ftp | awk '/\// { print $7 }')
-r-xr-xr-x  1 root  bin   151168 Jul 26  2016 /usr/bin/ftp
-r--r--r--  1 root  bin  3340978 Mar  8 09:44 /usr/lib/libc.so.88.0
-r--r--r--  1 root  bin  6747408 Sep 23 03:06 /usr/lib/libcrypto.so.38.0
-r--r--r--  5 root  bin  1436630 Jul 26  2016 /usr/lib/libcurses.so.14.0
-r--r--r--  1 root  bin   600928 Jul 26  2016 /usr/lib/libedit.so.5.2
-r--r--r--  1 root  bin  1476507 Nov  6 05:32 /usr/lib/libssl.so.39.0
-r--r--r--  1 root  bin   241742 Jul 26  2016 /usr/lib/libtls.so.11.0
-r--r--r--  1 root  bin   144142 Jul 26  2016 /usr/lib/libutil.so.12.1
-r--r--r--  1 root  bin   221586 Jul 26  2016 /usr/libexec/ld.so


Allan

Re: File Server with OpenBSD?

[Roderick]

I want to make my questions below more concrete.

Let us suppose, I boot from wd0 and want to make a Raid 1
with wd1 and wd2, and that I follow the instructions in "man softraid":

# printf "a\n\n\n\nRAID\nw\nq\n\n" | disklabel -E wd1
# printf "a\n\n\n\nRAID\nw\nq\n\n" | disklabel -E wd2
# bioctl -c 1 -l /dev/wd1a,/dev/wd2a softraid0
# dd if=/dev/zero of=/dev/rsd0c bs=1m count=1
# ... disklabel in sd0 , new ffs there, ...

What did happen?

Where did bioctl wrote data?

Where is written the new label in sd0?

I will not be able to mount wd1 or wd2 as a single disc with ffs, but
perhaps modifying the label?

And where are the planned checksums written?

I ask this because I want to know if I will make me dependent of
todays stand of OpenBSD.

Mounting ffs partitions of OpenBSD in FreeBSD and the opposite
is possible without big problems. Will this change with Raid?

Thanks
Rodrigo.





On Wed, 8 Mar 2017, Roderick wrote:


Few questions:

(1) Where are the checksums written?

(2) Where are the metadata of Raid 1 / Raid 1 with Checksum written?

(3) Can I take a disc from the Raid array and mount it somewhere else
   as a normal ufs single disk?

(4) Well, sooner than Hammer2, but when? :)

Re: permissions problems after update

[Stuart Henderson]

On 2017-03-08, Allan Streib  wrote:
> $ doas openup
> ===> Checking for openup update
> ===> Installing/updating binpatch(es)
> quirks-2.241 signed on 2016-07-26T16:56:10Z
> binpatch60-amd64-httpd-1.0: ok
> Error from 
> https://stable.mtier.org/updates/6.0/amd64/binpatch60-amd64-iked-1.0.tgz
> Can't exec "/usr/bin/ftp": Permission denied at 
> /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 641.
> Fatal error: Can't run /usr/bin/ftp: Permission denied
>  at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 641.

Seems odd. Let's check the permissions on things needed for ftp...
Can you show the output from this (as root if necessary),

ls -l $(ldd /usr/bin/ftp | awk '/\// { print $7 }')

Re: Please: Is there ANY chance that Linux binaries might run again???

[Stuart Henderson]

On 2017-03-07, Stefan Wollny  wrote:
> at home this is the way I go, too. But I have to travel to my client's
> place (by train!) and when working in the evening in the hotel room like
> tonight (as I have to leave the office building by 8 pm at the latest)
> it is somewhat inconvenient to take a second laptop with me.

Is qemu any good for this or is it too slow?

Otherwise the easiest way at present is probably to dual-boot or boot
Linux from a USB stick, or run it on a remote system.

Additionally, while the answer to "is there any chance" is no, the
answer to "any chance 32-bit Linux binaries will run on OpenBSD/amd64"
would be "hell no".

> Yes - I will (again) contact SoftMaker trying to persuade them to
> provide an OpenBSD-version of their office suite. But they seem to have
> none with some decent Unix/OpenBSD-knowledge, just Linux. Sigh...

They'll need a new binary for every OS uodate, and a different one for
32/64 bit. While I'd love to see it (I paid for softmaker office and prefer
it over libreoffice or MSWord), I think this is unrealistic.