Re: Machine age and OpenBSD - Thinkpad R51e

2021-06-15 Thread Nick Holland

On 6/15/21 8:14 PM, Thomas Vetere wrote:

Hello everyone,

I was looking to get a laptop to run OpenBSD. The one I am looking at in
particular is the Thinkpad R51e (2005). I like this particular model
because it does not come with any extra hardware that OpenBSD does not
support in the first place (bluetooth, camera, etc.) My main concern is the
longevity that this model would have going forward. I already have a '94
Thinkpad that cannot run the latest OpenBSD well because hardware support
was gradually dropped during code cleanups, etc (i.e. newer versions of X11
removed support for my ancient graphics chip because it just wasn't worth
the time to maintain the code). Does anyone know, given the age of that
model, how many years I might get out of it with OpenBSD and its packaged
software before hardware support starts to drop? What is a good rule of
thumb for selecting a machine to run OpenBSD with respect to its age?

Thank you for your help!



Well...keep in mind that laptop model numbers are marketing tags,
based on what you provided, I have no idea what's actually IN that
machine.  And I (and I suspect most people) can't predict what HW
will become unsupportable in the future or why.

But the machine you are looking at is 16 years old.  Odds are, OpenBSD
will support that machine longer than you will find the machine useful
(assuming it is usable on OpenBSD now.  If it is filled with nvidia hw,
game over). Sounds like it's a fairly limited machine -- with expansion,
MAYBE just barely enough RAM to run a modern browser, but probably not
pleasantly.  Make sure it's a SATA machine, not an IDE (IDE laptop
drives are getting hard to find) and make sure you got enough RAM,
upgrading it might be expensive.  I doubt this is going to be a
long-term machine for you.

And for what it is worth, I have a machine a few years newer than yours
that I've owned and dual-booted for well over ten years...except that even
though it's specs are "sufficient" for what I might want to do with Windows
on it, Windows 10 no longer supports the video hw it has.  OpenBSD still
does.  Surprise.

Nick.



Re: Backup OBSD router at 6.7, anyway to upgrade it to 6.9???

2021-05-17 Thread Nick Holland

On 5/17/21 9:16 PM, Jay Hart wrote:

Jay Hart  writes:


I lost internet access today for 4 hours due to a network
problem.  Trying to troubleshoot the problem I ended up placing
my backup router in service.

Its still at 6.7, it there anyway I can update it to 6.9 without
doing a full re-install, or has the only train left the station?


Any reason you don't want to go 6.7 -> 6.8 -> 6.9?

I went from 6.5 to 6.8 that way for one machine. You do have to
review the upgrade guides for any breaking changes though.

Allan



I absolutely do want to go 6.7 -> 6.8 -> 6.9.  Sysupgrade won't do
it, so I assume its a manual process at least from 6.7 to 6.8??

Jay


Naw.  sysupgrade will take 6.7 to 6.8.  Run again, you will go
from 6.8 to 6.9.  Easy, as long as the mirror you chose has all
the steps in the middle (they should all have 6.8 and 6.9, but
can be an issue for "bigger" spreads).

I, too, have done "Bigger than proper" jumps, but I know how to
clean up the mess and my backups are pretty good in case I'm wrong
about knowing how to clean up the mess. ;)

Nick.



Re: Remote wipe software

2021-04-27 Thread Nick Holland

On 4/27/21 5:41 AM, Oliver Leaver-Smith wrote:

Hello misc@

I wonder if anyone could recommend remote wipe software for OpenBSD,
should someone want to start using it in an enterprise setting where
such features are a requirement?

Thanks in advance,


Remote wiping an openbsd system...depends on your company policy, but
there are options.  I'm kinda assuming you are looking for an OpenBSD
solution, any wiping system will wipe any supported drives on any
machine.

  # dd if=/dev/random of=/dev/rsdXc bs=1m

will clear drive sdX very nicely, and quite quickly compared to other
OSs -- to the point I've often installed OpenBSD remotely, then done
this to clear other OSs from systems.  OpenBSD's performance from
its random number generator is fantastic.

IF your policy is a "multi-pass" wiping, I'd suggest doing a few
passes with /dev/random, then following up with /dev/zero, so you can
quickly and easily see if a particular drive has been cleared -- if it
is all zeros, you know you have completed the required number of
passes (it's easy to see zeros, a little harder to determine if data
is "random" or "just not understood".

If a one-pass wipe is sufficient by your company policy, a running
OpenBSD system can wipe itself.  Yes, you will get error messages
when the dd is done, but...you don't really care, right?

You can even do the dd thing from a bsd.rd kernel, network booted or
physical media.  Many years ago, I found that OpenBSD's full install
had a faster /dev/random (by a large margin) than the bsd.rd
/dev/random.  I've got no idea if that's true now.

When tasked with a number of machines to wipe, I've actually made
wipe disks -- built a CD (or other) install media with the startup
scripts set to wipe all drives in the system, unprompted.  Boot the
machine off the media, and let it run.  Label them carefully and
destroy them when done to prevent very unhappy accidents later!

Nick.



Re: The case of the phantom reboot

2021-03-29 Thread Nick Holland

On 3/28/21 12:13 PM, David Newman wrote:

On 3/28/21 4:58 AM, Kristjan Komloši wrote:


On 3/27/21 10:27 PM, David Newman wrote:

OpenBSD 6.8 GENERIC#5 i386

One of my systems rebooted at 03:01 local time today. I've seen kernel
panics and bad hardware but I've never seen OpenBSD "just reboot" by
itself, ever.


OpenBSD, not usually.  Hardware OpenBSD is running on? Sure.


There's no cron job that would do this. last(1) is no help; it shows the
reboot command but not the shutdown that preceded it:

root@ns ~ 4# last -f /var/log/wtmp.0
reboot    ~                                 
Sat Mar 27 03:01
root      ttyp0    192.168.0.132            Wed Mar 24 11:23 
- 11:23
(00:00)

wtmp.0 begins Wed Mar 24 11:23 2021
root@ns ~ 5# last -f /var/log/wtmp.1
root      ttyp0    192.168.0.132            Tue Mar 16 21:30 
- 21:30
(00:00)
root      ttyp0    75.82.86.131             Tue Mar 16 
13:14 - 21:30
(08:15)
root      ttyp0    75.82.86.131             Sun Mar 14 
21:20 - 21:29
(00:08)
root      ttyp0    75.82.86.131             Sat Mar 13 
17:42 - 21:13
(03:31)

The date gaps seem odd. I've ssh'd into this system multiple times
between March 16-27. I don't see other signs of trouble in /var/log.

I could use some help in looking for evidence of foul play, or "just" a
hardware or software problem.

Thanks in advance for further troubleshooting clues.

dn


What kind of a machine is it running on? I remember having reboot
problems on certain HP and Supermicro servers with hardware watchdogs.


This is a 10+-year-old Dell 1U server with a 2-GHz Celeron 440, part of
a pair running CARP. Aside from having to replace spinning disks with
SSDs a couple of years ago, they've been rock solid.


basic machine, worked for a long time, then starts giving problems, almost
certainly a hw problem unless you can tie the problem to a recent upgrade.
And that's not terribly likely on a "basic" hardware.

Every broken device started out "rock solid" ... until it isn't.  That's
the definition of "Broken".


I too have seen issues with Supermicros but that's with other OSs. I've
never had a spontaneous reboot, on this system, and am concerned from
the wtmp stuff above that this *may* have been triggered externally. I
could use some clues in other things to check. Thanks.


As Stuart pointed out, that comes from the boot process, not the shutdown.

If you are really curious, you could put a serial console on it and wait
for the next event.  PROBABLY won't see much, however.

Believe me, I'm all in favor of recycling computers -- in fact, as I
often tell skeptical employers, I'd rather have two ten year old systems
than one brand new system with a service contract, but computers don't
last as long as they used to, and curiously, some big-name servers seem
to sometimes have a shorter life than some desktops,  A ten year old
computer that does the job reliably is good, but not an expectation.

Nick.



Re: Installing across two SSDs, encrypted

2021-01-29 Thread Nick Holland

On 1/29/21 9:37 PM, Joe Nelson wrote:

I'd like to install obsd on a laptop that has one built-in 128GB SSD,
and a 1TB SATA SSD added in a separate bay. Was thinking of putting the
system files on the small drive, and /home, /var, /tmp, and /usr/local
on the big one. I'd like to use full-disk encryption for the big drive.

Two questions. First, will the installer set up the partitions across
the drives for me, or do I need to do a custom procedure with disklabel?
Second, how do I get the OS to prompt me during startup for a
passphrase, and mount the encrypted drive? (It's not the primary drive
with the OS on it, which seems nonstandard.)

Thanks for any help.


It takes less than 15 minutes to do an OpenBSD install, far less time than
it takes to give detailed answers to questions like this.  So, please, do
your own testing, and do it over and over until you understand how it works.

The installer won't magically read your mind and set things up on multiple
drives as you want them, but you can easily guide it along the way, or you
can come back and adjust things later as you wish.  And really, you should
spend an hour or two finding out how this is done -- it's really easy.

As for how the secondary encrypted drive is handled, again, JUST TRY IT.
If you have questions about what you see and how it happens, THEN come back
and ask those specific  questions.

For what it's worth, 120G is still huge to OpenBSD, so I'd put everything
on that, and only use the second drive for whatever it that's so big that
you need a second drive (i.e., /var/www, maybe /home/music, etc.).  And
don't allocate all of that 1T disk unless you actually need most of it.
Biggest mistake I see people making is allocating all of their disk,
"because I have it, I must allocate it, right?"  WRONG.

Nick.




Re: Managed to mess up the system encrypted disk. I can no longer boot.

2021-01-27 Thread Nick Holland

On 1/27/21 1:45 PM, Samarul Meu wrote:

mie., 27 ian. 2021, 20:24  a scris:



Ironically this is the same error I have been getting, and recently
posted about in the thread "Bootloader on USB stick fails with "root
device not found"" ...



I read your thread just now. I will try the -a option.

Interesting, but I must mention that my OpenBSD is installed on an
encrypted partition.


-a at the boot prompt is my thought, too...but the little bit of your
dmesg that you show seems to indicate you are not seeing the encrypted
drive handled by in softraid at all.  So I have my concerns this won't
do much but delay the panic (the kernel's panic.  Too late for your
panic, I'm sure).

If this doesn't work for you, I'd start by booting off a bsd.rd (USB,
CDROM, network, whatever) and looking around a bit.  What does the
fdisk of your physical drive look like?  Is your OpenBSD partition
still there?  If not, recreate it (hopefully you either used the
defaults or remember what you did).  All that really matters is the
starting sector (probably 64 assuming MBR.  UEFI is 1024, iirc, but
I'm too lazy to look this up right now.  Dammit, no I'm not, yes,
probably 1024, but I'm DEFINITELY not looking to see if that's a
hard number or if there are things that cause it to move around).

After the fdisk partitions, look at the disklabel in on the physical
drive -- should be one big RAID partition as 'a' and type RAID.

I am kinda suspicious that the bioctl command you gave was not the
culprit in this situation, but something else in your script.


As for safeguards...Well, from personal experience recently, I can
*assure* you I understand the first response when something goes
horribly wrong and your finger is the one on the (virtual) trigger
is, "Why wasn't there a safeguard??".  I get that, and I bet mine
was a bigger oops than yours.  But realistically, there are an
almost unlimited number of ways to hurt yourself, and a much smaller
number of ways to do things right, and often what to person A is
a horrible mistake, person B needs as a way to solve a big problem.
I have often needed to use an OS like OpenBSD to clean up messes in
other OSs because the safeguards in the other OS prevented me from
doing what I needed to do.  So yes, I understand, but no, I don't
want a "are you sure?" on every step of everything that could cause
an "event".

And think how much you just learned about the value of good backups...

Nick.



Re: boot_config(8) man page issue; and possibly openbsd.org/report.html

2021-01-25 Thread Nick Holland

On 1/24/21 4:02 PM, Andrew Easton wrote:
  ...> The boot_config(8) man page reads:


The Ethernet card is not detected at boot because the
kernel configuration does not match the physical
hardware configuration, e.g.  wrong IRQ in
OpenBSD/i386.  [...]
UKC> find ne
[...]
25 ne1 at isa0 port 0x300 size 0 iomem -1 iosiz 0 irq 10 drq -1 drq2 -1 flags 
0x0
[...]
ne1 seems to match the configuration except it uses
IRQ 5 instead of IRQ 10.
[...]
UKC> change ne1
[...]
irq [10] ? 5

   ...

The sentence "ne1 seems to match the configuration
except it uses IRQ 5 instead of IRQ 10" has two
ways of being interpreted: (1) the kernel
configuration is using IRQ 5 and (2) the hardware
configuration is using IRQ 5.



...ISA devices and drivers are complicated and stunningly inconsistent.

IF the developers want to improve this, I would suggest something maybe
more along the lines of:
"The ne(4) driver recognizes a card at port 300 as ne1, but expects
an IRQ of 10.  If your card is actually at port 300, IRQ 5, you can
adjust the driver as follows:"
   [...example...]

Realistically, however, you aren't likely to be very successful with
OpenBSD on an ISA machine; the people who know how to deal with ISA
cards try not to, and the hw that /requires/ them is very slow for modern
OpenBSD.  (I recently gave up on an old, faithful P90 I've used for many
years because it just took too long to just boot, and even it has PCI
slots where NICs "just work").  Also, you are generally better off moving
the HW to match OpenBSD's expectations rather than moving OpenBSD to the
HW, as that will make your next upgrade discouraging.  I'm almost more of
the opinion that this section should be removed rather than tuned up -- I
don't think ISA cards should be encouraged, I don't know that hw that can
use ISA cards should be encouraged, I certainly wouldn't recommend changing
the OS to match the card (though yes, sometimes it is required if you
really insist on using hardware that requires it).

A lot can be written about how to use an ne(4) ISA card with OpenBSD,
a lot can be written about ep(4), ec(4), we(4), but they can all be
summed up as, "here's a nickel kid, get yourself a less old computer".

Nick.



Re: How to unlock a serial port

2021-01-19 Thread Nick Holland

On 1/19/21 4:35 PM, Adam Thompson wrote:

[Replying directly as well, as I believe my MTA is still blacklisted by
the OpenBSD mail server. Guess we'll find out! -Adam]

On 2021-01-17 20:09, Tilo Stritzky wrote:

On 14/01/21 17:38  Andrew Grillet wrote:

Hi

I am running OpenBSD on a T2000 (Sparc64).
I was trying to use the serial port from the primary domain, connected 
via

ssh, and my network lost the connection.
My tty00 is now locked:
jay# stty -f /dev/tty00
stty: /dev/tty00: Device busy
I do not want to reboot the primary, as the guests are running various 
live

services. I cannot find evidence of a lock file in /dev/spool/lock.
Is there a way out of this predicament?


fstat(1) is your friend here.
Note that each tty has a corresponding cua device, they're both under 
the

same lock.

tilo


I ran into this exact problem last year.  It'll be in the list archives.
According to Theo (if I understood him correctly) it's partly due to the
way BSD serial ports have always worked, i.e. in a rather
under-specified manner.
Apparently the core tty(4) code around this particular symptom hasn't
really changed at all since OpenBSD forked.

My solution was to install Linux, sorry - I never did find a way around
the problem on OpenBSD.


I'm curious what you think "this exact problem" is.  The OP replied to
me (off list) with what the problem was, and I am 99% certain that Linux
would behave the exact same way -- and if it didn't, it would be a bug
in Linux.  Hint: the error message was dead-on accurate.  The port was
busy!

I'm not going to say serial support in OpenBSD is perfect, but it works
Darned Well, and better for me than any other OS I've used.  I've used
and have in production things ranging from 8 port USB connected devices,
single port USB serial interfaces, 20 year old ISA BOCA card and of
course, native on-board serial devices.  The USB devices sometimes need
me to reboot the machine the USB port is attached to, but otherwise, Just
Works.  OpenBSD makes an excellent terminal server (and all the tools are
in base, which really makes it simple -- well, except the boca(4), as it
requires a custom kernel).

Nick.



Re: How to unlock a serial port

2021-01-14 Thread Nick Holland

On 1/14/21 12:38 PM, Andrew Grillet wrote:

Hi

I am running OpenBSD on a T2000 (Sparc64).
I was trying to use the serial port from the primary domain, connected via
ssh, and my network lost the connection.
My tty00 is now locked:
jay# stty -f /dev/tty00
stty: /dev/tty00: Device busy
I do not want to reboot the primary, as the guests are running various live
services. I cannot find evidence of a lock file in /dev/spool/lock.
Is there a way out of this predicament?


What command were you running when you were disconnected?
is it still running?

A little pkill might do wonders for you.
I haven't used a T2000, but most of the time when I get "device busy"
I have left a program running on the port.

When I have a port actually "die" on me, it's usually a USB connected
serial device, and the behavior is quite different.  Either a physical
disconnect or a reboot is needed, but that doesn't appear to be your
situation.

Nick.



Re: RAID Question

2021-01-13 Thread Nick Holland

On 1/12/21 9:41 PM, Duncan Patton a Campbell wrote:


Howdy all?  I'm wondering if more than one RAID1 array is supported in 6.7++

I'm having problems that could be bios limitations, OS, or a bad SATA (Pwr?) 
cable.
Currently I'm going with the latter and rebuilding the RAID (again) but was
just wondering if anyone has run a config with more than one RAID array...
...

Volume  Status   Size Device
softraid0 0 Rebuild 4000786694656 sd5 RAID1 3% done
   0 Rebuild 4000786694656 0:0.0   noencl 
   1 Online  4000786694656 0:1.0   noencl 
softraid0 1 Rebuild 2000396018176 sd6 RAID1 72% done
   0 Rebuild 2000396018176 1:0.0   noencl 
   1 Online  2000396018176 1:1.0   noencl 

Thanks,

Dhu  (dmesg attached, oh and Happy New Years to you;)


/home/nick $ doas bioctl softraid0
Volume  Status   Size Device
softraid0 0 Online  6001174724608 sd5 RAID1
  0 Online  6001174724608 0:0.0   noencl 
  1 Online  6001174724608 0:1.0   noencl 
softraid0 1 Online  4000786726912 sd6 RAID1
  0 Online  4000786726912 1:0.0   noencl 
  1 Online  4000786726912 1:1.0   noencl 
softraid0 2 Online  6001174323200 sd7 CRYPTO
  0 Online  6001174323200 2:0.0   noencl 

so  ... uh...yeah.
And yes, that crypto is on top a RAID1 set.  Doing things wrong, I am. :)

What's the problem you are having?

That being said -- I did have some issues here that may have been related
to a couple old disks of uncertain history.  Pretty sure it ultimately
boiled down to bad spot on this drive, different bad spot on that drive,
and as a result, neither drive could rebuild onto the other.  That
definitely happens with RAID1.

Nick.



Re: Dissing Misks

2020-12-23 Thread Nick Holland
On 2020-12-23 11:29, James Cook wrote:
> On Wed, Dec 23, 2020 at 10:21:08AM -0500, Nick Holland wrote:
>> On 2020-12-22 23:58, Allan Streib wrote:
>> > Duncan Patton a Campbell  writes:
>> > 
>> >> fdisk seems unwilling to allow more than 2T in the partition:
>> > 
>> > Look at the b command for disklabel(8) to set the OpenBSD disk
>> > boundaries.
>> > 
>> > Allan
>> > 
>> 
>> yep.
>> fdisk can't do bigger than 2T because that's as big as the MBR tables
>> allow. But fdisk is only used to mark off the OpenBSD part of the disk
>> to keep other OSes from stomping on its space. If you are running an
>> exclusively OpenBSD system or otherwise keep the OSes from getting
>> confused, fdisk isn't used for much.  Make it as big as you can, and
>> you are fine.
>> 
>> disklabel, by default, only uses the OpenBSD fdisk partition, but you
>> can blow through that barrier with the 'b' command, as Allan indicated.
>> 
>> If you are using softraid, you will have to repeat the disklabel 'b'
>> thing for the softraid disks, too.  I usually forget that part.
>> 
>> Nick.
> 
> If you're starting fresh, isn't it simpler to use a GPT partition
> table if you want to go past that limit?
> 

IF your computer supports GPT, that's certainly an option.
However, I've yet to find anything "simpler" about GPT setups.
Whatever GPT was supposed to make better, I think they missed.

(to be fair: I understand the OpenBSD MBR boot process very well, and
I can fix just about anything that goes wrong with it.  I have NOT
figured out all of GPT booting all that well -- I can make it work,
(more accurately: I can let the OpenBSD devs make it work) but I
can't exactly tell you what is going on under the hood.  I have got
multibooting to work with GPT, and if I ever figure out all of how
THAT worked, it might be a better way of doing multibooting than
the usual MBR solutions.)

I've never regretted setting up a MBR boot system on an "either will
do" machine.  I have regretted setting up a GPT system on a machine
that became unreliable, and thus had to be replaced, and I spent too
long trying to find a new used system that was also GPT capable.

So far in my life, all my systems are MBR capable, some are also GPT
capable, but until it becomes mostly GPT and few MBR, I'm kinda fond
of the MBR setup for failure recovery reasons.

And really, the key sequence of "b" [enter] "*" [enter] is NOT a major
difficulty (other than remembering to do it.  Somehow, I keep building
systems where it is stupidly easy to forget, though that's also an
easy after-the-fact fix).

Yes, there are some GPT only computers now.  There are some dual mode
with buggy MBR support.  I'm pretty sure there are some dual mode
machines with buggy GPT support.  I do not think there's a universal
answer -- look at your situation and knowledge and proceed 
appropriately.

Nick.



Re: Dissing Misks

2020-12-23 Thread Nick Holland
On 2020-12-22 23:58, Allan Streib wrote:
> Duncan Patton a Campbell  writes:
> 
>> fdisk seems unwilling to allow more than 2T in the partition:
> 
> Look at the b command for disklabel(8) to set the OpenBSD disk
> boundaries.
> 
> Allan
> 

yep.
fdisk can't do bigger than 2T because that's as big as the MBR tables
allow. But fdisk is only used to mark off the OpenBSD part of the disk
to keep other OSes from stomping on its space. If you are running an
exclusively OpenBSD system or otherwise keep the OSes from getting
confused, fdisk isn't used for much.  Make it as big as you can, and
you are fine.

disklabel, by default, only uses the OpenBSD fdisk partition, but you
can blow through that barrier with the 'b' command, as Allan indicated.

If you are using softraid, you will have to repeat the disklabel 'b'
thing for the softraid disks, too.  I usually forget that part.

Nick.



Re: very slow scrolling in xterm

2020-12-19 Thread Nick Holland
On 2020-12-19 14:00, Claus Assmann wrote:
> On one machine the scrolling in an xterm is very slow since the upgrade
> to 6.7 and also in 6.8.
> Now that I want to use this machine a bit more I'm wondering what
> settings can be used to avoid that problem.
> dmesg and Xorg log are (hopefully) attached, what other info could
> help to track down the problem?

For Some Reason, when I saw your query, the very first thing I thought
of was, "Nvidia".

My guess wasn't wrong.
In fact, that machine is loaded with nvidia hw.  If you fixed
the video, I suspect you will slam into other walls shortly after.

Could I interest you in a new computer?  There's not much in that thing
I'd call redeeming.  In fact, I've tossed a lot of better computers years
ago.  Well, it is interesting, in that it's a ~2006 Dell with an AMD proc,
but that's "interesting" as a collector's item, not a "use it for work"
thing.  

If you really want a dab of perfume on this pig, try a cheap ATI
video card in whatever slots you have available in it.  However, once
you do that, you will probably realize you have lousy disk performance
and unreliable USB.  And you don't have much memory in the thing.

I'm a tad bit curious about your implying the X performance got bad
after 6.6...did this thing really not suck in 6.6 and before?  Maybe
there was regression in old nvidia hw with newer nvidia support?

Nick.

dmesg inlined:
OpenBSD 6.8 (GENERIC.MP) #2: Sat Dec  5 07:17:48 MST 2020

r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1055784960 (1006MB)
avail mem = 1008799744 (962MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf (63 entries)
bios0: vendor Dell Inc version "1.0.3" date 10/02/2006
bios0: Dell Inc Dimension E521
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP BOOT SSDT HPET MCFG SLIC APIC
acpi0: wakeup devices HUB0(S5) XVRA(S5) XVRB(S5) XVRC(S5) USB0(S3) USB2(S3) 
AZAD(S5) MMAC(S5) MMCI(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: disabled
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2004.47 MHz, 0f-4b-02
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2004.19 MHz, 0f-4b-02
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: disabling user TSC (skew=162915)
cpu1: smt 0, core 0, package 1
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (HUB0)
acpibtn0 at acpi0: PWRB
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
cpu0: PowerNow! K8 2004 MHz: speeds: 2000 1800 1000 MHz
pci0 at mainbus0 bus 0
"NVIDIA C51 Host" rev 0xa2 at pci0 dev 0 function 0 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 1 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 2 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 3 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 4 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 5 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 6 not configured
"NVIDIA C51 Memory" rev 0xa2 at pci0 dev 0 function 7 not configured
ppb0 at pci0 dev 2 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci1 at ppb0 bus 1
ppb1 at pci0 dev 3 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci2 at ppb1 bus 2
ppb2 at pci0 dev 4 function 0 "NVIDIA C51 PCIE" rev 0xa1
pci3 at ppb2 bus 3
vga1 at pci3 dev 0 function 0 "NVIDIA GeForce 8500 GT" rev 0xa1
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"NVIDIA MCP51 Host" rev 0xa2 at pci0 dev 9 function 0 not configured
pcib0 at pci0 dev 10 function 0 "NVIDIA MCP51 ISA" rev 

Re: www.openbsd.org unreachable for a few days

2020-12-16 Thread Nick Holland
well, someday I'll learn to send to the right target. :-/

Nick.

On 2020-12-16 08:35, Nick Holland wrote:
> On 2020-12-15 15:45, Theo de Raadt wrote:
>> I've been told something was just fixed.
>> 
>> Now is a good time to retry.
>> 
>> Reply just to me, please.
>> 
>> ONLY people who observed the problems.
> 
> a POSSIBLY related data point -- we had problems between UofA 
> and UofToronto from the end of November to Dec 5.  Our friends
> at UofT were doing what they could to see what was going on,
> but their conclusion was it was at UofA as well, and they said
> they got no response from UofT. And then suddenly, things got
> better.
> 
> The problems we had were very slow data movement with a lot of
> "stalled" (from ftp(1)) messages, where there would be seemingly
> zero progress for many seconds.
> 
> Right now, I'm getting overall, good performance, but strange
> patterns -- 
> 
> $ ftp https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install68.img
> 
> starts out with a very modest speed, but then starts going
> faster and faster, ftp updates its progress about once per second,
> the first few updates are less than 1MB/s, but by the end, it's
> doing 20MB/s.  I've attached a typescript of two pulls from
> ftp.openbsd.org to openbsd.cs.toronto.edu.
> 
> Nick.
> 



Re: www.openbsd.org unreachable for a few days

2020-12-16 Thread Nick Holland
On 2020-12-15 15:45, Theo de Raadt wrote:
> I've been told something was just fixed.
> 
> Now is a good time to retry.
> 
> Reply just to me, please.
> 
> ONLY people who observed the problems.

a POSSIBLY related data point -- we had problems between UofA 
and UofToronto from the end of November to Dec 5.  Our friends
at UofT were doing what they could to see what was going on,
but their conclusion was it was at UofA as well, and they said
they got no response from UofT. And then suddenly, things got
better.

The problems we had were very slow data movement with a lot of
"stalled" (from ftp(1)) messages, where there would be seemingly
zero progress for many seconds.

Right now, I'm getting overall, good performance, but strange
patterns -- 

$ ftp https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install68.img

starts out with a very modest speed, but then starts going
faster and faster, ftp updates its progress about once per second,
the first few updates are less than 1MB/s, but by the end, it's
doing 20MB/s.  I've attached a typescript of two pulls from
ftp.openbsd.org to openbsd.cs.toronto.edu.

Nick.


typescript
Description: Binary data


Re: OpenBSD as a NAS

2020-12-03 Thread Nick Holland
On 2020-12-02 18:19, Ashton Fagg wrote:
> Hi all,
> 
> I'm currently in the process of provisioning a new NAS for home. It's
> replacing an older Synology unit that ticks me off in so many ways.
> 
> I am looking to hear other's experiences with using OpenBSD as a NAS -
> specifically in terms of reliability, and for suggestions on how to
> provision my storage.
> 
> I have an LSI card (supported by the drivers in OpenBSD) that is
> currently flashed to IT mode, but it can of course flashed back to the
> IR firmware which lets it act as a hardware RAID controller.
> 
> My needs for the NAS are as follows: NFS and Samba share support,
> reasonable performance, some amount of tolerance to disk failure,
> reliable and trustworthy software and file system, ability to closely
> monitor disk/array health. By extension, it should also be as simple as
> possible.
> 
> It might be nice to have it be able to host an iSCSI volume, but that's
> not essential.
> 
> I don't care about bleeding edge performance, fancy web UIs or any other
> "shiny" stuff.
> 
> By my estimates, OpenBSD with softraid volumes should tick all of those
> boxes. The box will do nothing else besides be a file server. OpenBSD is
> my preferred OS nowadays, but I am open to something else if it's the
> best tool for the job. I guess I'm trying to find out if there's any
> compelling reason why I *shouldn't* use OpenBSD with softraid.
> 
> (ZFS also scares me, btw. Maybe unjustifiably so, but it seems very
> complex and I suspect much of the hype comes down to zealotry and
> fanboyism.)

that was my ZFS experience.  That, and the regular, "$PRODUCT is the
answer, what was your question?".  ZFS is one of those $PRODUCTs...

> The questions I have are:
> 
> a) Is softraid reliable enough to support my use-case? Does anyone have
> anecdotes to encourage/discourage use of softraid for this application?

I've been using it in various ways for many years. I'm happy with it.

HOWEVER, before you go live, build an array.  Replace a disk.  Rebuild
the array.  Basically do everything you might someday have to do in an
emergency...do it now before you load your data.

> b) Would I be better off using the LSI RAID controller for the arrays?

One, no.  Two, maybe.
Nice thing about software RAID in general is it's hw agnostic.  If your
system dies, it's easy to move your drives to another machine, maybe
with very different hw (for example, I've moved Softraid between pcide(4)
systems and ahci(4) systems.  Just works).  With HW raid, you really HAVE
to have a spare RAID card on the shelf ready to do use in case your
existing one fails.  You won't plug your old drives into another card
and have them recognized.

HW RAID can be fast.  It /can/ be easily managed in OpenBSD if bioctl
recognizes your controller.  But it is very dependent on the underlying
hw.  It can also bite you in the butt if it turns out to be quirkier
than you expected.

I can make a very good case for both HW and SW RAID -- and at this
point in my life, if anyone tells you one is absolutely the answer, I'm
going to say this person lacks some experience.

> c) Bearing in mind that the provisioning scheme I have in mind is to
> provision the disks in pairs (forming RAID1 arrays), thus resulting in
> 3-4 separate volumes (6-8 disks), is there any reason I should *not* use
> OpenBSD, and look more toward something like TrueNAS or FreeBSD?

If your weapon of choice is OpenBSD, you will be happy using OpenBSD
softraid, much more than trying to pick up another OS for a theoretical
advantage.

I like your plan.  With Softraid, your entire disk should be one RAID
array.  You can then slice up that RAID array into sub partitions.
(i.e., other software RAID systems are different -- for example, Solaris
would mirror individual partitions, rather than entire disks).
Keeping your arrays simple means your data is more likely to be there
when things go wrong (and they always do).

> (Before anyone mentions it - Yes, I have a proper backup system. I do
> not rely on the redundancy provided by RAID arrays in lieu of a real
> backup. I have both a local backup and offsite backup.)

Good. :)

Nick.



Re: Large Filesystem

2020-11-27 Thread Nick Holland
On 2020-11-27 16:03, Karel Gardas wrote:
,,,
> To me this looks like too much pray for luck. With such amount of data, 
> I would stay with ZFS...

I've heard that from a lot of people.
And yet, those same people, when pressed, will tell you that a ZFS-equipped
system will crash much more often than simpler file systems.  That's one
heck of a real penalty to pay for a theoretical advantage.

ZFS is kinda the IPv6 of file systems.  A few good ideas trying to solve
a one issue... and then they went way overboard trying to pack too much
else into it.

I've setup some cool stuff using ZFS (dynamically sized partitions,
snapshots, zfs sends of snapshots to other machines, etc), but man, I
spent a comical amount of time babysitting and fixing file system
problems.  The 1980s are over, file systems should Just Work now.
If you are babysitting them constantly, something ain't right.  If 
someone wants to add a ZFS-like "scrubbing" feature to ffs, I'd be all
for it. But not for the penalties that come with ZFS.

Nick.



Re: Security & Compliance - A/V

2020-11-26 Thread Nick Holland
On 2020-11-25 17:10, Brogan Beard wrote:
> In the enterprise context, there are often extensive security compliance
> rules, which include but are not limited to anti-virus software
> requirements. There are, of course, exceptions to these rules but generally
> policies drive the technology in use or allow it to be used. I am not aware
> of any anti-virus software that supports openbsd or any bsd for that matter
> (not saying it needs it ;) ).
> 
> How does OpenBSD handle the compliance aspects of security in regards to
> A/V? Is there an, "it's already under the hood," response based on modern
> security standards?
> 
> I would like to use OpenBSD in future projects, beyond just personal
> interest. And with that, I am sure these types of questions will arise.
> 
> Thanks in advance for thoughtful comments!

Something to consider: run the AV against your boxes -- elsewhere!

I have a similar situation at $DAYJOB.  Not OpenBSD, but an OS that
similarly has little malware written for it (and an environment with
lots of softer targets than the OS anyway).  For LOTS of reasons, we
didn't want to put AV on the "important" systems, but we needed to
hit that checkbox that says, "AV scans!"

Our compliance people work with me pretty well, and what we came up
was to run the AV against our BACKUPS of those boxes.  We rsync
the data from the systems to a central backup, and we run the AV on
that box against the data.  Increased the backup by a few GB/box and
grabbed the binaries, too, and ta-da, we got a pretty good AV scan
taking place with /zero/ additional impact on the systems.

Yes, perhaps not as "real time" as a system which hooks into the OS
and watches every disk read and write, but I don't think you even
want that on a Unix-like OS (even if it was possible on many Unix-
like OSs).

Nick.



Re: softraid0 errors after 6.8 upgrade

2020-11-22 Thread Nick Holland
On 2020-11-22 06:04, Leo Unglaub wrote:
> Hi,
> i upgraded my desktop to the latest 6.8 release. I uses sysupgrade to do 
> the upgrade and everything worked fine. But now i noticed in my dmesg 
> the following error messages:
> 
>> softraid0: sd6: i/o error 5 @ CRYPTO block 475440376
>> softraid0: sd6: i/o error 5 @ CRYPTO block 475440376
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 473833936
>> softraid0: sd6: i/o error 5 @ CRYPTO block 477298832

sure sounds to me like your disk has issues.  Doesn't look related
to the upgrade process.

> This only happens when i want to read certain files in /home. I checked 
> with fsck but it reports the partition to be fine. Has this something 
> todo with the upgrade? I did not find anything in the changelog.

sounds even more like your disk isn't good.

fsck checks file *system* integrity.  It does NOT check every sector
on the disk for suitability to store data.  The percentage of the
disk that fsck reads in the process of doing its job is very small.

If you want to test your backing disk, I'd do a:
# dd if=/dev/rsdXc of=/dev/null bs=1m
where "X" is your physical disk.  If you want to see it's progress
while running:
# pkill -info dd
will tell you how much has been read so far.

IF that comes up bad, you MAY be able to "fix" your problem by
deleting the files that are bad, then write a very large file to
the entire partition where those damaged files were -- the disk
will typically read-after-write verify that the data landed on the
disk properly, and if it finds a bad spot, it will lock it out and
put the failed write on a good spot (after you fill the disk,
delete the "filler" file, of course).  But be aware, your disk may
not not healthy -- yes, bad spots and reallocated space is a normal
thing for disks, but new bad spots, not so much.

Nick.



Re: Advice on using intrusion detection

2020-11-21 Thread Nick Holland
On 2020-11-20 17:15, Erik Lauritsen wrote:
> Is it recommended to run some kind of intrusion detection on an
> OpenBSD router/firewall?
> 
> I suspect that any kind of system like Snort or Suricata will give a
> lot of false positives?

MY philosophy is it is much easier to keep 'em out than to find 'em
once they are in.  And the odds of an intruder popping you firewall's
security is relatively low.  Be far more suspect of things BEHIND your
firewall.

So...my answer to your question is, "no, I wouldn't recommend any kind
of add-on intrusion detection to an OpenBSD Firewall".  The simpler
your firewall, the better.  The only package I put on my firewalls is
rsync for backup purposes.

Application server?  Now that's another story, perhaps.  

One thing I have been doing for a while is rsync --link-dest backups of
systems, both in-house and at various workplaces.  FANTASTIC tool,
giving incredibly "useful" backups, with relatively low impact and
resource requirements.  My I use a -v on rsync to get verbose backups,
and log it to a file.

Just recently, I realized these logs are basically a "changed file"
report, which is a starting point for a file alteration reporting
tool.  Combine that with a carefully crafted "ignore" file (you
can do that with a grep -vf ignorefile logfile), and you have an
interesting file monitoring system.

The painful part with any such system is crafting the list of what
to ignore vs. what to panic over.  Everyone wants to tick the
checkbox that says "We have an intrusion detection system", and
everyone wants one of two results: "No problem" and "intruder
detected".  So far, I don't think any tool does that.  An IDS
without careful human monitoring is just for show (and it's a
potential security risk of its own), and more likely to be the
cause of a problem than a solution.  Careful monitoring takes
time and resources.

One nifty thing I have found in "rolling my own" is that I found
a lot of little oddities, no security problems, but things that
needed fixing.  I'd call that a win.

Nick.



Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

2020-11-19 Thread Nick Holland
On 2020-11-19 08:36, Roderick wrote:
> 
> broken gcc is the old gcc, the one of the package is installed as egcc.
> 
> Do only I have a broken gcc?
> 
> R.
> 
> On Thu, 19 Nov 2020, Roderick wrote:
> 
>>
>> After upgrading, I still have gcc, but no package gcc.
>>
>> I get the above error. I get it also after installing gcc, and also after
>> deinstalling it, making "pkg_delete -a" and reinstalling.
>>
>> Any hint, what can I do?

You have provided almost no info to go on.
Upgraded from what to what?  On what platform?  What process did you use?
I'm not even sure what you are wanting to do -- run base gcc?  Run a
package gcc?

I think it is very safe to say you made an error somewhere, probably in an
upgrade process.  Not necessarily in your most recent upgrade, it may just
be a problem than finally came home to roost.  Most likely (since I've
done it, I'm going to assume you did), you skipped some important step
in upgradeXX.html that wasn't unimportant.  You may have even got away with
it for a few upgrades since.

Worst case, unload all pacakges, then go through the /usr, /bin and /bin
directories looking for files older than your current install, and removing
them (most of them aren't bad.  But something isn't right).  Then do
another upgrade to whatever you want to be running, because you probably
just blew away something incorrectly.  Finally, reinstall packages you
want.

And to be clear -- I'm NOT advocating deleting old files for giggles or as
any kind of routine activity as part of an upgrade.  But on a screwed up
system, the hunt for old files often reveals what is actually going on.

(in my case, I recently found my userland and kernel were over a year out
of sync on a machine I only use occasionally, due to unsupervised upgrades
and not looking at the results.  I had not properly removed the /var/tmp
directory however long ago that was, and base unpacks a symlink
in /var/tmp to /tmp, that failed, tar bailed and much of baseXX.tgz was
never unpacked.  I'm really surprised this machine was as functional as it
was.)

Nick.



Re: suggestion for the installer

2020-10-29 Thread Nick Holland
On 2020-10-29 08:00, Harald Dunkel wrote:
> Hi folks,
> 
> do you think it would be possible for the installer to show
> an eye-catching warning, if "ifconfig" reports "no carrier"
> for the network port to configure?
> 
> Just a suggestion, of course
> Harri

Why?
What problem are you trying to solve, and how many are you
planning on making for me in the process?

I often end up setting up OpenBSD systems with no network
attached.  Nothing to warn me about.

I very often install OpenBSD configuring several NICs when
only one has a network currently.  Again, PLEASE don't give
me three, five or ten bogus warning messages.

Usually if I'm doing an install, I look to see if the link
light on the NIC and the switch port is lit.

If I'm using DHCP, I'll quickly know if there's a network
problem.  Come to think of it, if I'm NOT using DHCP, I'll
quickly know, too.

If I'm installing to an unknown system, I almost always first
drop to (s)hell from the installer, look at my dmesg, look at
the network port options and see if I'm plugged into the NIC
port I think I am (ifconfig), look at my disks to see if they
are recognized as I expect and see if I'm about to clobber
something I might consider important.

So...I think what you are trying to accomplish can be done as
things are without adding to the wonderfully simple OpenBSD
installer.  

Nick.



Re: Startx doesn't find screens

2020-10-25 Thread Nick Holland
On 2020-10-25 10:35, d.verdi wrote:
> Hi to everybody,
> I'm facing this problem after the complete installation of OpenBSD 6.7:
> if I try to launch startx, an error occur and tells that "no screens found".
...

> The Xorg.0 log file content is the below:
...
> Check that you have set 'machdep.allowaperture=1'
> in /etc/sysctl.conf and reboot your machine
> refer to xf86(4) for details

MIGHT help.
...
> [ 47.358] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
> [ 47.358] (EE) wsfb(0): no way to get depth info: Inappropriate ioctl for 
> device
> [ 47.358] (II) UnloadModule: "wsfb"
> [ 47.358] (EE) Screen(s) found, but none have a usable configuration.
...
> The dmesg content is the below:

thanks!

> OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020
previous release...
...
> vga1 at pci1 dev 0 function 0 vendor "NVIDIA", unknown product 0x0df8 rev 0xa1
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
...
> 
> Thank you very much for the support
> Dav
> 

One -- 6.8 was just released.  Don't install an old release.
Two -- you seem to have a board that hasn't been seen much in the
wild by OpenBSD developers...and an nvidia at that. 

6.8 *might* help with that.  Or better, a snapshot.  But if this is
an add-in card, I'd suggest reinstalling it to your local trash can
or maybe a windows machine and and getting a better supported, 
non-nvidia card installed.

Nick.



Re: Case of the missing softraid

2020-10-04 Thread Nick Holland
On 2020-10-03 17:45, tera torn wrote:
> Hello,
> 
> I've been a happy user of OpenBSD softraid RAID 1 mirroring, and I'm
> attemtping to migrate data off of a degraded RAID 1 mirror.
> 
> I've booted before from the 6.7 install USB (amd64) and this degraded
> chunk was detected and the volume was brought up and my data was
> there.
> 
> I'm not sure what's happened but now when I boot the same media I'm
> unable to detect the softraid volume.Â
> 
> softraid0 is listed by the kernel, but no additional sd device is
> configured for the softraid volume.Â

That is always shown, whether softraid is used on the system or not.

> Is there a way to debug this? or detect or correct disk corruption so
> that this chunk is properly recognized again?

The dmesg will give some clues as to what is going on.  Hopefully, for
Some Reason, the drive just isn't showing up to the machine, the dmesg
will show that.

Next step, if it is in the dmesg, see if you can get an fdisk and
disklabel out of it...does that look sane?

> Can the chunk be manually mounted as an ffs volume? it should still
> contain a normal ffs filesystem somewhere right?

kinda.  But rebuilding that would probably be more work than fixing
the real problem.

> Looking for any way to recover the data in this chunk! Any help
> greatly appreciated.

I think you need to start with figuring out WHY the volume vanished.
Let's hope it's an electrical or mechanical problem.

Nick.



Re: system slow down strangeness

2020-09-08 Thread Nick Holland
On 2020-09-08 04:16, Gregory Edigarov wrote:
> Hello,
> 
> from around two weeks ago I am observing the overall system slow down. 
> Everything work stable,
> but nearly every X application takes forever to open a window.
> also I am using tiling wm, and when workspace is switched,
> it takes a long time for the system to redraw a screen.
> I also noticed that some console scripts like ansible-doc
> are also starting slower then usual.
> 
> this system only has 8 Gb RAM temporarily,
> but top says:
> 
> Memory: Real: 1764M/5673M act/tot Free: 2183M Cache: 3284M Swap: 0K/32G
> 
> so I do not think it is a memory issue.
> 
> was just fine before,  so wondering what has happen.

> OpenBSD 6.8-beta (GENERIC.MP) #59: Fri Sep  4 22:46:14 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

well...that's less than two weeks old.  So I'm guessing either you had
the problem and figured, "let's upgrade, see if that fixes it" (not a
bad plan), or you are a regular upgrader (also good).  Can you say if
the problem started with an upgrade?  Or did it occur between upgrades?

...
> sd0 at scsibus1 targ 0 lun 0:  

Any possibility you have a bad disk?  A few times in my life, I
have seen a bad disk that would have issues reading from the drive,
but succeed after a few retries, before it threw an error back to
the OS.  It would then reset its retry counter, and have the same
problem on the next read...and the one after that.  Result: horrible
performance, but it "worked".  (granted, I've been doing computer
support for almost 40 years now and I can think of two cases of this
happening that left me scratching my head for a long time, and maybe
a couple others similar to this that I don't recall so vividly, so
not exactly a common problem...but not unheard of, either.)

...
Nick.



Re: mfs reported full, but empty

2020-08-19 Thread Nick Holland
On 2020-08-19 17:47, Vincent wrote:
> Hello, 
> 
> 
> After several days, I have to reboot my machine because of mfs full. This is 
> not the first time.
> I have few mfs on this machine, but I observe that this is always a full 
> filesystem on /tmp after +40 days of uptime. 
> But on other mfs, I have very low filesystem activity. 
> 
> 
> Am I the only one having such problem ? 

yes.

and no. :)  Normal Unix Behavior, and nothing to do with MFS. 
(I think)

(for the record, I use mfs extensively some systems I run that get a
significant benefit from it, have done so for many many years.  Only
problem I've ever run into is being that MFS systems shine when for
with lots of tiny files, it's the ONLY time I've ever run out of
i-nodes before running out of disk space.  Not really an MFS problem,
of course.)
...
 
> obsd-fw/tmp# du -h /tmp
> 1.0K /tmp/.X11-unix
> 1.0K /tmp/.ICE-unix
> 1.0K /tmp/vi.recover
> 11.0K /tmp
> obsd-fw/tmp# df -h /tmp
> Filesystem Size Used Avail Capacity Mounted on
> mfs:71474 991M 991M -49.5M 105% /tmp
> obsd-fw/tmp# uptime
> 7:22PM up 57 days, 17:58, 1 user, load averages: 0.08, 0.16, 0.15
> obsd-fw/tmp# ps aux | grep mfs
> root 71474 0.0 12.4 1049016 1016980 ?? S 22Jun20 1:25.23 
> /sbin/mount_mfs -o rw -s 1024m swap /tmp

see... "du" and "df" show two different things.

"df" shows how much unallocated space you have.  It's very accurate.
You can create a file as big as "df" shows you have available.

"du" shows how much space normal files have taken up.  It's also very
accurate.  It will show you how much space will be freed up if you
delete those files.

However, you can have Unix do some seemingly strange stuff, at least
strange for those of us who cut our teeth on single-user systems.
Unix lets programs do funny stuff, like delete an open file.  That
removes the file handle (what "du" looks at), but does not release
disk space (what df looks at) until ALL tasks that have it open, 
close it. (man 3 unlink

In fact, I'm pretty sure one task can create a file, open it, unlink
(rm -- but the name there is wonderfully descriptive -- remove a link
(the directory entry) from a file) it, and then write and read temp
data to that file...and one can continue to do that until the task
exits...look ma, self-cleaning tmp files!

I'm pretty sure something like that is happening with you.

I was able to reproduce your "problem" easily.
I have a little machine here that has a 100MB /tmp, I created a 70MB
text file, and tried to edit it with vi.  Well...vi quickly discovered
it couldn't create its vi.recover file, /tmp showed 100% utilization,
but "du" could not show me where the last ~27mb of disk space went.
As soon as I exited vi, the space came back.

One big clue: since you are hitting 105%, that means the offending
process is running as root -- I could only take /tmp to 100% as a
non-root user, but if invoked as root, 105% (as expected).

So the first lesson is, whatever you are doing, 1G /tmp is not big
enough.
Probably more scary, though -- you have a root process spewing lots
of data into /tmp.  I don't normally see that...so I'm inclined
to think you are running something incorrectly or "solved a problem"
by running it as root.  Might be totally legit and just needs more
tmp space, but my very first thought is "YOU ARE DOING SOMETHING
WRONGLY!"

Next time you see this happen, before rebooting, ps -aux and look
at all your root processes and kill them one by one until you
suddenly see your disk space come back.  That was your offender.

Nick.



Re: nsd Will Not Start At Boot

2020-07-07 Thread Nick Holland
On 2020-07-07 15:28, ken.hendrick...@l3harris.com wrote:
...
> Unbound is still not working.
> 
> I have a hunch, but cannot find it in the man pages,
> that somehow they have to talk to each other.  Is this true?

depends on what you want them to do.

A DNS resolver and an authoritative DNS server are two different
things.  You may want your resolver to talk to your server for
some applications, other times, no.

I.e., exactly like two people in a room.  Maybe they have NEED
to talk, maybe they shouldn't talk to each other.  Getting the
job done properly depends on picking the right model. :)

> I tried a very simple unbound.conf file, and it didn't work.
> The very simple config file was from
[snip]

The unbound config file that ships with OpenBSD Just Works as
a stand-alone resolver listening on localhost.  Start there.
THEN make your changes you need.

> Any ideas?  Any help?  What should I be reading??

Unfortunately, the classic texts on DNS usually are based on
ISC BIND, which horribly munges the roles of authoritative DNS
and DNS resolver into one unified application, so going from
there to separated functions is difficult.  I learned the
separated model from Dan Bernstein's website, but in looking
it over, unfortunately, it is very much based on his DJBDNS
package, which is brilliant, but unmaintained for the last 15+
years and no longer compatible with many modern Internet
"features" everyone expects today, and uses its own file
formats, which were great, but not a standard way to 
communicate DNS info.

   http://cr.yp.to/djbdns/separation.html

Still...most of his points are valid, and he's worth a read.

Everyone's favorite error: Your DNS resolver has to bind to an IP
address.  Your authoritative DNS server has to bind to an IP
address.  They both listen on port 53 (UDP and TCP).  You can't
connect both your server and your resolver to the same IP address.
Won't work.  First gets it, second gets a port in use error.

But remember -- extra external IP addresses on your server are
easily added, and your machine has a huge number of potential
localhost addresses (127.0.0.0/8) for internal use.  Between
those and PF, you can pretty well make any kind of magic I've
ever thought of.

Nick.



Re: Dual boot problem

2020-06-28 Thread Nick Holland
On 2020-06-27 21:50, Greg Thomas wrote:
> Hey folks, I'm trying to avoid buggin y'all, but I'm down to my last two
> tasks, setting up dual boot with Windows 10 and setting up OpenVPN.  I'm
> currently trying to troubleshoot "Loading  ERR M" while using Windows
> BCD.  I can boot no problem when selecting my boot drive while starting up
> my Thinkpad X220.
> 
> I installed a couple of weeks ago using pretty much all defaults.
...
> nihilanon# fdisk sd0
> Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
>  #: id  C   H   S -  C   H   S [   start:size ]
> ---
>  0: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
> *3: A6  0   1   2 - 121600 254  63 [  64:  1953520001 ] OpenBSD

I'm not seeing a windows partition here.  And it appears your OpenBSD 
partition is using the entire disk.  Oh. Your computer has three disks
in it...your Windows install is on a second/third disk?  I don't think
that is going to work.

from your dmesg:
sd0 at scsibus1 targ 0 lun 0:  naa.5000c500b98a130c
sd0: 953869MB, 512 bytes/sector, 1953525168 sectors, thin
sd1 at scsibus1 targ 1 lun 0:  naa.500a07510369b769
sd1: 488386MB, 512 bytes/sector, 1000215216 sectors, thin
sd2 at scsibus1 targ 2 lun 0:  naa.5002538844584d30
sd2: 244198MB, 512 bytes/sector, 500118192 sectors, thin

ERR M basically means that biosboot(8), which is "tagged" with the
physical location of /boot(8) on the disk, doesn't see the marker
that indicates that what it is pointing at is actually /boot.  The
windows 10 boot loader is pulling from a disk other than sd0, the pbr
is pointing at something "correct" if it were sd0, but the Windows
boot loader is trying to pull it from whatever the new default disk
is.  Maybe.

There may be some bcdedit magic that can say "boot from this other disk"
which might solve your problem, but I have no idea.  A lame way of 
doing this might be to shrink your Windows partition by 1G, and install
your OpenBSD root partition there, and the rest on sd0.

Nick.



Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?

2020-06-23 Thread Nick Holland
On 2020-06-23 06:20, Why 42? The lists account. wrote:
> 
> Hi All,
> 
> Has anyone ever tried the Infinite Noise TRNG hardware random number generator
> with OpenBSD?

Actually...no.  Never felt any reason to.

> It's a USB stick that contains hardware to generate random numbers. See:
> https://github.com/13-37-org/infnoise
> 
> I had a couple of these working with ArchLinux and would like to try using
> them with OpenBSD.
>
> Using either 6.6 or 6.7 the device is recognised at boot time:
>> uftdi0 at uhub0 port 2 configuration 1 interface 0 "13-37.org Infinite Noise
>> TRNG" rev 2.00/10.00 addr 3 ucom0 at uftdi0 portno 1

so ... looks like is is pretending to be a serial port.  ucom0.
... 
> With libftdi1-1.4p2 installed I was able to compile the associated software
> using the supplied "Makefile.freebsd". So a pretty easy start ...

FreeBSD?
I'd be more surprised if this worked than if it didn't.

> This creates an executable "driver" called infnoise which can be run as a
> daemon e.g.

"driver" that runs as a "daemon".  I'm not entirely sure what that would
mean, to be honest.

>> doas ./infnoise -h
>> Usage: infnoise [options]
...
>> -s, --serial  - use specified device
   ^^^  Might want to play with that option.  Or not.
...
> Any suggestions? Where am I going wrong? Maybe I shouldn't have taken that
> shortcut with the freebsd makefile? Or a security issue?

First of all..what are you wanting this thing to do?  Provide random
data? how about just reading /dev/cuaU0?  And then...why not just use
/dev/random?

Or are you wanting this device to contribute to the OpenBSD random number
generator by stirring the entropy pool?

Are you expecting this /FreeBSD/ driver to reach into the /OpenBSD/
entropy pool and give it a good stir directly from ... userland?  That
sounds a bit scary.


However, I'd start by questioning the basic premise that OpenBSD needs
more entropy to seed its random number generator.  The OpenBSD developers
have spent a lot of time (and written some really good descriptions) on the
topic.  Many DIFFERENT things in OpenBSD *use* random numbers (so even if
you knew what the next "Random" number returned was going to be -- you
don't know if what task will be the one getting it!) and many DIFFERENT
things in OpenBSD agitate the entropy pool (so you aren't likely to know
what the next number returned will be), so you don't stand much of a
prayer of predicting the next result from a call to /dev/random.

Not only is the PRNG well stirred, a lot of modern hw has on-chip true
RNG noise sources which do basically the same as your little USB plug,
and OpenBSD uses at least a few of them.  Combine that with a lot of
"incredibly difficult to predict" things like hardware I/O and lots of
/dev/random data being used by things OTHER than your app...I really doubt
you will find much benefit to adding an external noise source to OpenBSD.

Nick.



Re: OpenBSD Readonly File System

2020-06-15 Thread Nick Holland
On 2020-06-13 12:56, Todd C. Miller wrote:
> On Sat, 13 Jun 2020 12:12:05 -0400, Nick Holland wrote:
> 
>> On 2020-06-11 12:07, Strahil Nikolov wrote:
>> > I always thought that 'sync' mount option  is enough  to avoid
>> > corruption of the FS. Am I just "fooling" myself  ?
>>
>> As "sync" is the default...yes, I think you are.
> 
> Actually, by default only metadata is written synchronously.  The
> "sync" mount option causes data to be written synchronously too.
> Of course, the disk *itself* has a cache so even with synchronous
> writes you can't be sure the data has actually made it to the platter.
> 
> So yes, I agree that sync mounts are not really enough to help here.
> You are probably correct that softdep is better for this kind of
> thing since it does a better job of keeping the filesystem in a
> consistent state, at the cost of missing data when there is an
> unclean shutdown.  In theory, the on-device cache can still cause
> issues when you lose power though.

Thanks for the correction!  The really embarrassing thing is I even
checked the man page, but started from the incorrect assumption that
"async" and "sync" were the only two choices and read what I expected,
not what is actually on the page. 

Nick.



Re: OpenBSD Readonly File System

2020-06-13 Thread Nick Holland
On 2020-06-11 12:07, Strahil Nikolov wrote:
> I always thought that 'sync' mount option  is enough  to avoid
> corruption of the FS. Am I just "fooling" myself  ?

As "sync" is the default...yes, I think you are.

File systems are complicated.  Making them work robustly is even
more complicated.  And the ways hardware (including power) fails
is often difficult to comprehend from a high-level language
standpoint ("I just wrote fifty bytes to the end of the file,
what's the big deal?").  All things considered, FFS works
amazingly well.


Back to the OP's question -- I'm curious why he's having trouble
I just don't have.  The vast majority of the time, my firewalls
and other OpenBSD systems just come back on their own without
intervention.  When I'm moving or otherwise maintaining an
OpenBSD system, I often just yank the power cord and let the
thing fsck itself on reboot.  I'm not going to say it ALWAYS
comes back without intervention, but I'd guess well over 90%
of the time, they just come up without help.)

So...  I'd look at what's going on more than try to change the
basic operation of OpenBSD.  Why are you writing to disk so much
that your file systems end up being trashed?

Some ideas I'd try before making a Franken-system:
* Log to another system over the network via syslog so less
writing happens locally.
* use the noatime mount option -- that reduces a lot of
unneeded writes.  
* Faster disks -- How about a small SSD?  They spend less
time writing, and often have enough on-board capacitance to
complete writes after a power interruption.
* experiment with softdeps.  Supposedly, it helps keep the
/FILE SYSTEM/ consistent.  My experience is it tends to
truncate files on unexpected power-downs, but in MOST cases,
I'd rather have a zero byte file that has obviously been
mangled than one that looks ok.  I almost always use softdeps,
maybe that's why my systems almost always come back after a
power interruption?

I have no hard facts to back up any of those helping a
system come up on its own after a impolite powerdown, but 
they all seem like they might.  And I do most of them, and
my results seem to be better than the OP's, so maybe?

Nick.



Re: Mounting encrypted drive on boot

2020-06-02 Thread Nick Holland
On 2020-06-02 19:27, Chris Narkiewicz wrote:
> My setup consist of OpenBSD 6.7 with full drive encryption using
> softraid, configured as described in FAQ:
> 
> /dev/sd0a - encrypted volume
> /dev/sd1 - decrypted 
> 
> I have additional need to mount an encrypted /var volume on boot.
> This volume is separate drive attached to be VPS "machine".
> 
> I want to mount this drive automatically on boot by adding
> relevant entries to /etc/fstab, but before this can be done,
> softraid device must be configured using bioctl.

I don't think there is a good answer to your question *as asked*,
so we just have to come up with a new question and solve your
problem. :)

I am GUESSING your real problem is "I didn't make /var big enough"
You can add a second disk.  And you did.

I would look closely at what partitions you have on /dev/sd1c.

Got a /home?  Move that to your second drive, move the /var to your
old /home.

Or..what is the real problem with /var?  Maybe /var/www?  Move
THAT to your second drive, leave /var (which is kinda important on
boot for a lot of reasons!) on sd1.  But in general, work out a
way to keep /var on your primary boot drive, and put something
that isn't needed in the first moments of boot on the secondary
drive.  Some other ideas that could be moved:
  /usr/local
  /usr/src
  /usr/bin
  /usr/ports
  /home
Most of those would provide a good basic /var

If you over-built some other partition, copy the data off, make it
smaller, reload, and use the freed space for a /var.

Nick.



Re: EFI boot on Dell PowerEdge R610

2020-05-28 Thread Nick Holland
On 2020-05-28 05:15, Johan Hattne wrote:
> On 2020-05-28 00:56, Johan Hattne wrote:
>> On 2020-05-28 00:43, YASUOKA Masahiko wrote:
>>> Hi,
>>>
>>> On Wed, 27 May 2020 22:32:58 -0700
>>> Johan Hattne  wrote:
 I've been trying to boot the 6.7 installation media from USB via EFI
 on a Dell PowerEdge R610.  The screen goes blank and then the thing
 resets (so no kernel output or anything).  I can boot the same stick
 via BIOS.

 I've been searching for a while without results.  Firmware settings
 look sane to me.  Is this something anybody has seen before?  Any hint
 on where I could even start looking for problems would be very much
 appreciated!
>>>
>>> I'd like you to try the diff attached with the following message.
>>>
>>> https://marc.info/?l=openbsd-tech=158280719421562=2
>> 
>> Thanks a lot, Yasuoka!  Is there any chance you could provide a compiled 
>> BOOTX64.EFI?  I don't have an amd64 build environment at the moment.
> 
> After a bit of off-list discussion, Yasuoka concluded that above diff 
> won't help here.  To clarify the issue: there is no output at all before 
> the machine resets, in particular there is no prompt from the EFI boot 
> program.
> 
> // Johan
> 

Have you tried firmware updates?
That machine is many years old, I'd not be the slightest bit surprised if
the firmware was buggy and didn't boot much of anything in EFI mode other
than Windows and maybe Linux.

Nick.



Re: sysupgrade confused by additional disk?

2020-05-25 Thread Nick Holland
On 2020-05-25 10:21, Why 42? The lists account. wrote:
,,,
> At some point I added a second (larger) disk to hold my user data (i.e.
> home). It seems that this new disk took over the name sd0 and the OpenBSD
> system disk itself became known as sd1.

yep.  Things like that are where the duids came in.

> The OpenBSD OS still boots and runs without issue, however this change
> seems to have confused sysupgrade. After it downloads and reboots I now
> get prompted to choose I)nstall, U)grade, etc. If I recall correctly,
> this step used to run automatically without any intervention. Is that
> right?

While OpenBSD itself is great about using duids, those are defined in
the 'a' partition of the boot disk..which is usually the first disk. But
in your case, the "first disk" doesn't include the 'a' partitionand the
/etc/fstab file...which is probably causing the upgrade kernel to choke.

> My first thought was I could fix the issue by using sysctl to reassign
> the disk name to uuid mapping (i.e. the hw.disknames values)
...
No, that won't work -- the disks are assigned at boot.  

> Any other suggestions as to how to fix this?
> 
> Thinking some more about it, shouldn't sysupgrade just use those very
> disk uuid values to identify its targets in the first place ... thus
> avoiding the whole issue in the first place?

think about that a moment.  You are running OpenBSD.  You run sysupgrade,
it pulls down all the new tgz files. And it ... REBOOTS.  I think you
are asking that the old kernel passes info to the newly rebooted kernel.

It's probably doable, or could fail earlier to let you know you have a
problem, but I'm driving myself batty thinking about the multi-platform
and edge cases.

The best solution for YOU I can think of would be to put a small 'a'
partition on your sd0 for root, and have your system boot from that,
but use sd1 for all the rest of the system file systems.  Or just do
traditional upgrades.

Nick.



Re: Kernel relinking on old boxen at every boot

2020-05-25 Thread Nick Holland
On 2020-05-25 11:35, ULF wrote:
...
> My question is:
> 
> considering that an opt out option has been already turned down, could at
> least old architectures be benefited of a "delay" option e.g. like tune2fs
> sets a fsck every n-th boot, could KARL, just for very old machines be
> tuned, say, to be applied every 10/20 boots?

oh, please no.
So you want my old machine to USUALLY boot in a minute or so...but once
in a while, you want it to take many times that long with no real warning
that "don't panic, this reboot will take many times the usual amount"?
No...we got Linux machines that do that...very horribly unpleasant.

It also disables the primary advantage of KARL -- If you find a way to
tickle a bug in the OpenBSD kernel, PROBABLY the first result will be to
crash the kernel (due to other safety things).  You WANT it to come up
on a different kernel NEXT TIME, not after a bunch more crashes while the
attacker figures out how to turn a crash-bug into an exploit-bug..  If you
really want to kill this security feature, don't pretend it's still there
helping you...turn it off and know it's off.

KARL is really easy to disable IF that's what you really want to do. You
probably want to kill the library relinking, too (if your disks don't suck,
I find the library re-linking more painful than the kernel relinking. If
your disks suck (i.e., USB thumb drive), they are both painful).  Also easy.
I, toolike running old hw, but I'd rather OpenBSD be made as good as
possible for modern stuff so people can do real work on it than to be
crippled by trying to optimize for a bunch of us old hw collectors.  We
can disable KARL and library re-linking if we want to -- and that's how it
should be, build for the productive masses, leave the edge cases to the
nut-jobs like us. :)

Nick.



Re: fw_update verify firmware?

2020-05-14 Thread Nick Holland
On 2020-05-14 11:08, i...@aulix.com wrote:
>> If that binary code was on a ROM, would it be less malicious?
> 
> Cannot more recent and up to date binary code be more malicious than
> old one in the ROM?

This has nothing to do with OpenBSD.  That can be true for any kind of
code update, whether it exists in RAM on a device that's loaded by the
OS at boot time, EEPROM that can be reprogrammed by software, or a
chip that has to be physically swapped out.

I actually had Adaptec give me a firmware update with a time bomb in
it, and didn't bother to tell me that after X days, it would brick my
adapter and prevent me from updating/downdating it.  If it had been
stored in RAM, I might have been able to recover it, but since it was
flashed into EEPROM and prevented the machine from booting, the card
had to be replaced...and my customer had an outage.
> Please take into account, I am a very noob in security area and it is
> just my IMHO.

Please read your own statement.  You aren't qualified to assert your
opinion in this group, humble or not.  It's not our job to turn you
into a security expert.  If you value the work that OpenBSD does to
protect your security, use it.  If you don't, use something else.
Please.  We aren't here to win you over.  Some of us are kinda tired
of your flood of queries asking for yet another opinion on often and
widely discussed topics.

> Anyway there was another distro like LibertyBSD which was an OpenBSD
> without some already seldom blobs like firmwares. And another OpenBSD
> fork is declared to be going to appear: Hyperbola (it is Linux based
> yet for now), completely pure from BLOBs too.

...and you won't find much modern hardware that it works on.  You can
achieve your goal (including the "not working on your hardware"
feature) with OpenBSD by just removing the contents of the
/etc/firmware directory.  If the firmware isn't needed on your machine.
it's not loaded.  Concern about firmware binaries is not incorrect, but
it is horribly missing a lot of points about how modern computers work.
It's kinda like putting six bullets in a revolver, and obsessing about
the third one.  Yes, sure...that third one may blow a hole in your head
or protect you from the rabid wolf, but the other five could do very
much the same.  And in most cases, you have far bigger security
concerns than malicious firmware.  Here's a free security lesson: If I
want to take control of your machine, I'll use the easiest route; that
won't be malicious firmware.

Oh, btw...if I recall properly, a lot of CPU security fixes are
distributed as firmware microcode updates that have to be loaded by the
OS.  So... being inappropriately paranoid about firmware could
compromise your security.  

Nick.



Re: OpenBSD insecurity rumors from isopenbsdsecu.re

2020-05-07 Thread Nick Holland
On 2020-05-07 10:00, i...@aulix.com wrote:
> Dear OpenBSD fans,
> 
> Can you please comment negative appraisal from the following
> website:
> 
> https://isopenbsdsecu.re/quotes/
> 
> I did not want to hurt anyone, just looking for a secure OS and
> OpenBSD looked very nice to me before I have found this website.

Rule of life #1: when lots of people hate you, you are either doing
something very wrong...or very right.  People don't waste their time
on people who are average-ish.

That's actually how I found OpenBSD -- reading through a once
popular chat website, saw people spending a lot of time throwing a
lot of hate and personal attacks at Theo and his team.  Well, by my
figuring, anyone who gets that much venom tossed at them needs a
looking at!  That was 22+ years ago. No regrets.  You have to decide
for yourself if OpenBSD is very right or very wrong for you (not a
lot of people in the middle, and that's fine.)


Looking at the quotes, I see...
* Jealousy
* competitors
* broad, general statements
* Blablabla
* People with a self contradictory titles.
* people hiding behind pseudonyms
* People that have All The Answers, just waiting for someone to
do what they say.
* Name callers
* "No shit Sherlock"ers
* "OpenBSD sucks, I like your website!"
* "OpenBSD does what it set out to do, I like your website"
* People "removing all doubt" (as in, "Better to be thought a
fool than to open your mouth and remove all doubt")
* "if it isn't popular, it's not good"er
* unbacked claims.
* another, this one thinks only about fighting the past wars.
* more unbacked claims, this one, totally anonymous. 
* A person wanting YOU to find exploits in OSs.  Guess they are all
pretty secure if they aren't finding them themselves.

Seriously, if you understand OpenBSD's work, you would take
many of those quotes as complements.  OpenBSD's security mitigations
broke a "secure" language?  Maybe you should check your assumptions.
Elsewhere on that website, he mocks OpenBSD for calling someone
"inaccurate jerks" -- I happened to click on that, since it didn't
exactly roll off the tongue, and what is the actual context?  Theo
saying, "No, that's not a hardware problem, that's an OpenBSD problem
and it should be fixed".  You were not supposed to look at the
context, I guess.  The line about "Insults" is actually someone mock-
complaining about doas not insulting users like sudo does.The
more stuff I click on, the more I start to think, this is an irony
site!  This guy LOVES OpenBSD!  Well, fudge.  I just wasted a lot of
time writing this!)

Nick.



Re: dynamic dns updates for clients in my home network?

2020-04-25 Thread Nick Holland
On 2020-04-25 15:00, bofh wrote:
> Hi,
> I searched through the archives and saw a couple of discussions about using
> Dnsmasq from a long time ago.
> 
> Is that the best way to let the stuff in my home to have valid dns entries
> in my home network?
> 
> How difficult is it to get the OpenBSD provided dhcpd and unbound to do
> this?
> 
> Thanks.

https://web.archive.org/web/20160310223857/http://www.thismetalsky.org/files/dhcp_dns/dhcp_dns/

This person wrote a little perl script that parsed the dhcpd lease file
and wrote a Dan Bernstein TinyDNS data file.  A number of years ago, he
put an ISC license on it...and apparently since took it off his website.

I managed to rework it to put out NSD compatible zone files,

I think this is much preferable to running a package for this, but your
opinion may vary.  I'd show my code, but it currently runs as root, and
that's just wrong (it should probably use nsd-control(8) to reload nsd.
My code should probably also create a reverse DNS file, but I've not missed
that enough to worry about it). I've been using this script, first As Is,
but now with NSD for over 15 years.

Nick.



Maintenance: (man|cvsweb).openbsd.org, (openbsd|obsdacvs).cs.toronto.edu

2020-04-13 Thread Nick Holland
hi.

The following servers will likely be inaccessible at times or
completely, April 14, from 7am to 8pm Eastern Daylight Time (UTC-4)
(yes -- 13 hour window) for site network maintenance.

  * man.openbsd.org
  * cvsweb.openbsd.org
  * obsdacvs.cs.toronto.edu
  * openbsd.cs.toronto.edu

Nick.



Re: i386 kernel relinking

2020-04-10 Thread Nick Holland



On 2020-04-10 10:10, Stefan Sperling wrote:
> On Fri, Apr 10, 2020 at 09:35:16AM -0400, Nick Holland wrote:
>> Question about kernel randomization and relinking...
>> 
>> It seems to take a fair amount of RAM, at least for systems that
>> are forced to run i386.  And I mean real RAM -- swap doesn't seem
>> to cut it.  
>> 
>> I discovered that several machines I was intending on using for
>> minimal purposes just couldn't complete relinking.  So I built a
>> VM and started playing with the RAM.
>> 
>> Built with 1G RAM, default was a 1.2G swap, worked fine.
>> Reduced to 256MB RAM, Kernel failed to relink.  As with my old
>> junk.
>>
>> The magic number seemed to be between 320MB (failed) and 384MB 
>> (worked) of RAM.  Ok, fine.  
> 
> FWIW, my soekris net5501 with 256MB of RAM and 512MB swap does manage
> to relink a kernel (on 6.6 + syspatches).

Whoops.  Guess I should have mentioned, that was -current, as of
yesterday 
OpenBSD 6.7-beta (GENERIC.MP) #110: Thu Apr  9 01:20:52 MDT 2020
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem  = 334970880 (319MB)
avail mem = 313077760 (298MB)

and probably a couple weeks ago for the real (old) hw.

I'm curious if your Soekris can handle 6.7-beta.

Nick.


> 
> # ls -l relink.log
> -rw-r--r--  1 root  wheel  -  507B Apr 10 13:33 relink.log
> # cat relink.log   
> (SHA256) /bsd: OK
> LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
> ${OBJS}
> textdatabss dec hex
> 11815507267748  1101824 13185079c93037
> mv newbsd newbsd.gdb
> ctfstrip -S -o newbsd newbsd.gdb
> rm -f bsd.gdb
> mv -f newbsd bsd
> install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd
> 
> Kernel has been relinked and is active on next reboot.
> 
> SHA256 (/bsd) = 
> a940ce989d708e5b87a1186ee81bd624066baeabe67b8405b52e4fa2988b565
> 
> 
> # dislabel -pm wd0
> #size   offset  fstype [fsize bsize   cpg]
>   a:   353.0M   64  4.2BSD   2048 16384  5624 # /
>   b:   511.1M   722944swap# none
>   c: 15280.0M0  unused
>   d:   444.8M  1769728  4.2BSD   2048 16384  7116 # /tmp
>   e:   607.7M  2680576  4.2BSD   2048 16384  9685 # /var
>   f:  1703.0M  3925216  4.2BSD   2048 16384 12958 # /usr
>   g:   505.8M  7412896  4.2BSD   2048 16384  8060 # /usr/X11R6
>   h:  1632.9M  8448736  4.2BSD   2048 16384 12958 # /usr/local
>   i:  1381.2M 11792960  4.2BSD   2048 16384 12958 # /usr/src
>   j:  5282.4M 14621632  4.2BSD   2048 16384 12958 # /usr/obj
>   k:  2850.9M 25439936  4.2BSD   2048 16384 12958 # /home
> 



i386 kernel relinking

2020-04-10 Thread Nick Holland
Question about kernel randomization and relinking...

It seems to take a fair amount of RAM, at least for systems that
are forced to run i386.  And I mean real RAM -- swap doesn't seem
to cut it.  

I discovered that several machines I was intending on using for
minimal purposes just couldn't complete relinking.  So I built a
VM and started playing with the RAM.

Built with 1G RAM, default was a 1.2G swap, worked fine.
Reduced to 256MB RAM, Kernel failed to relink.  As with my old
junk.

The magic number seemed to be between 320MB (failed) and 384MB 
(worked) of RAM.  Ok, fine.  

Kernel relinking is important, I get that.  Probably time to
start tossing old junk.  I get that, too.  I'm not complaining
about the forcible retirement of some of my old junk.  I'm just
curious why swap didn't "fix" this problem.

But that VM failed at 320MB RAM, even though it had 1.2G of swap,
mostly unused (MOSTLY.  Yes, it was going into swap).  Is there a
semi-layperson's explanation of this?  Or is this a "if you got
to ask, you won't understand" kind of thing?

And here's the relink log from my VM, but the ones from my physical
boxes looked pretty similiar.

$ cat relink.log   
(SHA256) /bsd: OK
LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
0   0   0   0   0
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
strip: there are no sections to be copied!
rm -f bsd.gdb
mv -f newbsd bsd
mv: newbsd: No such file or directory
*** Error 1 in /usr/share/relink/kernel/GENERIC.MP (Makefile:1131 'newbsd')

I also found that a 320MB machine could not build the kernel from scratch.
Nothing used much memory until the ld step, which started using large amounts
of memory and some swap, and errored out the same way:

LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
0   0   0   0   0
mv bsd bsd.gdb
ctfstrip -S -o bsd bsd.gdb
strip: there are no sections to be copied!

Thanks!

Nick.



i386/amd64 boot (and pxeboot) compatibility

2020-04-06 Thread Nick Holland
Hi,

For a long time, the /boot and pxeboot of i386 would boot amd64's
kernel and amd64's would boot i386's kernel.

My tftp server had both amd64 and i386 bsd.rd files named
"bsdamd64.rd" and "bsdi386.rd", snapshots downloaded daily.  But
recently, I discovered I could not PXE boot i386's bsd.rd from the
amd64 pxeboot.  

I then grabbed a spare laptop, and confirmed this problem happened
the other way as well -- an amd64 installed machine could not boot
i386 from the amd64 /boot file.

I also see the i386 and amd64 boot files have different version
numbers now.  So...I'm kinda inclined to guess this is not an
accident, but figured I'd ask just in case it is.

Nick.



Re: upgrade i386 kernel to amd64

2020-03-02 Thread Nick Holland
On 2020-03-02 18:14, Justin Muir wrote:
> Hello all,
> 
> Running GENERIC i386 kernel on on a 64-bit amd machine. Just wondering
> whether an upgrade amd64 is warranted. Any opinions?

yes.
At this point, most OpenBSD development starts on amd64 systems, then
moves to other platforms.  Plus, the AMD64 platform offers some magic
tricks that help improve security, and I do believe generally better
package support.

amd64 systems have been around for over 15 years.  i386 is really
almost a "legacy" platform now.  If you gotta use it, ok...but otherwise,
no.

The only reason I can think of to run i386 code on an amd64 system is if
your i386 system failed and you moved the disk to an amd64 capable
system.  
 
> If so, just upgrade system? Re-compile kernel? Other options?

DO NOT UPGRADE.
No idea what you are even dreaming of by "recompiling the kernel",
that makes the bad idea of an upgrade look good (it isn't).

Reinstall from scratch.  Good time to look at how you used disk and
partition better this time.

Nick.



Re: openbsd.org - certain https URLs downgraded to http in redirection

2020-02-24 Thread Nick Holland
Sorry, took a look at this a while back when I didn't have time to
fully work through it...and then forgot about it. ;-/

On 2020-02-12 04:34, Aham Brahmasmi wrote:
> Namaste misc,
> 
> Overview:
> Certain https URLs on openbsd.org get downgraded to http in redirection.
> 
> Steps:
> When navigating to https://www.openbsd.org/cgi-bin/man.cgi [1] from a
> browser, one ends up on http://man.openbsd.org/cgi-bin/man.cgi.
>
> Same with https://www.openbsd.org/cgi-bin/cvsweb [1], which ends up on
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/.

I Google for "openbsd man", I end up with a link to 
httpS://man.openbsd.org.
and it takes me to man.openbsd.org via httpS.

I duckduckgo.com for "openbsd man", same thing.
(yay.  I just used a website as a verb.)

Google does seem to show a link for httpS://cvsweb.openbsd.org, but
tosses the browser at http://cvsweb.openbsd.org. DuckDuckGo does not
and does what you would expect and hope.

Looking at the page source for the google return, it DOES appear to
be sending the browser to http://, so everything is working as
designed.  Is there a problem?  Yes -- google is aware https:// 
those sites exists, but doesn't actually send users to them.
Apparently your favorite search engine does as well.  Perhaps it
isn't as privacy friendly as you are thinking it is.  The problem
isn't with the websites, it's with where the search engine is 
sending the user.

You want it changed so that when someone clicks on a link, they go
somewhere OTHER than where that link sends them?  I understand your
goal (everything should be HTTPS!!), but I don't really like the
idea of "click here, go elsewhere".

Want https? great. use it.  There are times when it's handy to NOT
be obsessed with https (i.e., clock is hosed on your computer).  

So ... unless some developer I really respect (which is just about
all of them1) tells me to change this, I'm not planning on
changing the behavior of the machines.

Nick.



Re: Server 5 SSD/best practice

2020-02-21 Thread Nick Holland
On 2020-02-20 11:22, Oliver Marugg wrote:
> Hi
> 
> I’ve got a Supermicro 5028D desktop server with 5 identical SATA SSDs, 
> there is no HBA no RAID card in. The purpose of the server is intended 
> as web/smtp and some vmm vms (os plus /home & /var storage).
> What are your suggestions or best practices configuring the device 
> arrangement (eg. sofraid(4), bio(4),bioctl(4) OS 2x on 2x ssd raid1, 
> data 3xssd raid5 or 1x single ssd for OS and 4x ssd raid5/10 or better 
> ideas)?
> 
> many thanks
> -oliver
> 

set it up as you need it... 
If you think your description is anything close to specific for specific
recommendations, you need to get out more.  Everything you said could 
vary in demand by many orders of magnitude, except for the model number
the server...a curious thing to be specific about.

E-mail is one of those things that's really hard to get a good backup
of, as it changes minute by minute and is considered fairly important,
so I'd consider a three disk RAID1 for the mail store, as a disk system
failure invariably means "lost data", even with frequent backups.
Three disk RAID1 gives you a simple disk structure that can tolerate
a disk failure and still provide redundancy.  (some people will tell
you that RAID1 is only two disks.  These people are wrong, but often
include HW RAID controller makers.  Three disk RAID1 examples are in
the man pages). 

As for the rest...it's a matter of how much space you need and how
much down time you can tolerate, and how you are set up to deal with
that downtime.  And I'm assuming you aren't combining external and
internal services on one box.  I suspect that's a bad assumption.

And even after much careful analysis it's a bit of a guess.
Sometimes you guess wrong.  So keep your design flexible and be
willing and able to say, "Well, this isn't working, let's rebuild
it with the knowledge we now have".  This idea that you have to have
the perfect build the first time out is ... well, just wrong.

Nick.



Re: automounter (amd) local file system issue

2020-01-16 Thread Nick Holland
On 2020-01-15 11:05, Strahil Nikolov wrote:
> On January 13, 2020 5:40:06 AM GMT+02:00, Nick Holland 
>  wrote:
>>On 2020-01-12 15:39, Antoine Jacoutot wrote:
>>> Sounds like something is keeping your fs busy. Could be gio-kqueue,
>>do you have glib2 installed?
>>
>>That would be my first guess, too -- it's not unmounting because it
>>shouldn't.  But ... this is a VERY single purpose machine (backups
>>via rsync --link-dest), and the only third party package is rsync
>>and my scripts to do the backups.  X is installed, but not running.
>>
>>$ pkg_info
>>intel-firmware-20191115p0v0 microcode update binaries for Intel CPUs
>>inteldrm-firmware-20181218 firmware binary images for inteldrm(4)
>>driver
>>quirks-3.216exceptions to pkg_add rules
>>rsync-3.1.3 mirroring/synchronization over low bandwidth links
>>vmm-firmware-1.11.0p2 firmware binary images for vmm(4) driver
>>
>>I was careful to access the amd mounts by ls , while
>>sitting in my home directory, which is NOT part of the amd, so I
>>didn't have a task under a doas or su camped out on the amd vols.
>>
>>I've tesed a lot of ways, but I just did an upgrade to -current and
>>immediately "looked" at the amd mount, so even my backup scripts
>>haven't run.
>>
>>Plus -- as a control, /v/2 has absolutely nothing on it, and it
>>behaves the same way.  Not that something couldn't camp out on the
>>empty file system, but not much reason for something to do so.
>>
>>Thanks for looking!
>>
>>Nick.
>>
>> 
>>> —
>>> Antoine
>>> 
>>>> On 13 Jan 2020, at 06:01, Nick Holland 
>>wrote:
>>>> 
>>>> Hiya.
>>>> 
>>>> I'd like to use amd(8) to automatically mount and dismount local
>>file
>>>> systems.  The file systems in question are big, lots of complicated
>>>> links, lots of files, and take a while to fsck if the power goes out
>>>> unexpectedly, and are used relatively rarely (maybe an hour a day).
>>>> Sounds like a perfect job for amd(8)!
>>>> 
>>>> The file systems in question are mounted to /v/1 and /v/2
>>>> 
>>>> I've got the following set up:
>>>> 
>>>>  $ cat /etc/rc.conf.local   
>>
>>>>  amd_flags=-l syslog -x all -c 10 -w 10
>>>>  lockd_flags=
>>>>  portmap_flags=
>>>> 
>>>>  $ cat /etc/amd/master  
>>
>>>>  /v  amd.v
>>>> 
>>>>  $ cat /etc/amd/amd.v   
>>>>  1   type:=ufs;dev:=/dev/sd2i
>>>>  2   type:=ufs;dev:=/dev/sd2j
>>>> 
>>>> 
>>>> ANDit works!
>>>> 
>>>> start the system up, I get this:
>>>> 
>>>>  $ df
>>>>  Filesystem  512-blocks  Used Avail Capacity  Mounted on
>>>>  /dev/sd2a  101167620381275728421%/
>>>>  /dev/sd2h 1031983648   9803800 0%/home
>>>>  /dev/sd2f  413682820   3929968 0%/tmp
>>>>  /dev/sd2d  8264188   2369920   548106030%/usr
>>>>  /dev/sd2e  2065116  2104   1959760 0%/usr/local
>>>>  /dev/sd2g  4136828 64920   3865068 2%/var
>>>>  amd:365830 0 0   100%/v
>>>> 
>>>>  $ ls /v/1/
>>>> [...expected output from files and directories on that file
>>system...]
>>>> 
>>>>  $ df
>>>>  Filesystem  1K-blocks  Used Avail Capacity  Mounted on
>>>>  /dev/sd2a  505838 8360239694617%/
>>>>  /dev/sd2h 515991824   4901900 0%/home
>>>>  /dev/sd2f 206841410   1964984 0%/tmp
>>>>  /dev/sd2d 4132094   1280264   264522633%/usr
>>>>  /dev/sd2e 1032558  1052979880 0%/usr/local
>>>>  /dev/sd2g 2068414 32572   1932422 2%/var
>>>>  amd:92953   0 0 0   100%/v
>>>>  /dev/sd2i   2106117872 298739480 170207250415%   
>>/tmp_mnt/dbu/v/1
>>>> 
>>>> Success!!
>>>> well...no.  Seems it never umounts the amd file systems.  And that
>>is
>>>> basically the point of this exercise -- to increase the odds that a
>>FS
>>>> isn't mounted when the power goes out.
>>>> 
>>>> Am I doing something wrong?  Do I have inaccurate expectations of
>>>> what amd(8) does with local file systems? 
>>>> 
>>>> Nick.
>>>>

 ...

> Hi Nick,
> 
> Can you test removing '-w 10' from the daemon's flags in order to test with 
> the default 2min timeout.
> 
> I have a vague feeling that 10 seconds is way too short...

You are right -- that was something I tried so I quit having to
wait 5+ minutes every time I tried something different, so I stuffed
absurdly short timeouts in place for testing, but there was no change.
I've reverted those changes, and (as I expected), it is still not
unmounting.

New:
   $ cat /etc/rc.conf.local   
   amd_flags=-l syslog -x all
   lockd_flags=
   portmap_flags=

(the -x all was added to see if amd logged any dismount attempts or why
they failed...nothing)

So thanks, but ... no change. :-/

Nick.



Re: automounter (amd) local file system issue

2020-01-12 Thread Nick Holland
On 2020-01-12 15:39, Antoine Jacoutot wrote:
> Sounds like something is keeping your fs busy. Could be gio-kqueue, do you 
> have glib2 installed?

That would be my first guess, too -- it's not unmounting because it
shouldn't.  But ... this is a VERY single purpose machine (backups
via rsync --link-dest), and the only third party package is rsync
and my scripts to do the backups.  X is installed, but not running.

$ pkg_info
intel-firmware-20191115p0v0 microcode update binaries for Intel CPUs
inteldrm-firmware-20181218 firmware binary images for inteldrm(4) driver
quirks-3.216exceptions to pkg_add rules
rsync-3.1.3 mirroring/synchronization over low bandwidth links
vmm-firmware-1.11.0p2 firmware binary images for vmm(4) driver

I was careful to access the amd mounts by ls , while
sitting in my home directory, which is NOT part of the amd, so I
didn't have a task under a doas or su camped out on the amd vols.

I've tesed a lot of ways, but I just did an upgrade to -current and
immediately "looked" at the amd mount, so even my backup scripts
haven't run.

Plus -- as a control, /v/2 has absolutely nothing on it, and it
behaves the same way.  Not that something couldn't camp out on the
empty file system, but not much reason for something to do so.

Thanks for looking!

Nick.

 
> —
> Antoine
> 
>> On 13 Jan 2020, at 06:01, Nick Holland  wrote:
>> 
>> Hiya.
>> 
>> I'd like to use amd(8) to automatically mount and dismount local file
>> systems.  The file systems in question are big, lots of complicated
>> links, lots of files, and take a while to fsck if the power goes out
>> unexpectedly, and are used relatively rarely (maybe an hour a day).
>> Sounds like a perfect job for amd(8)!
>> 
>> The file systems in question are mounted to /v/1 and /v/2
>> 
>> I've got the following set up:
>> 
>>  $ cat /etc/rc.conf.local
>>  amd_flags=-l syslog -x all -c 10 -w 10
>>  lockd_flags=
>>  portmap_flags=
>> 
>>  $ cat /etc/amd/master   
>>  /v  amd.v
>> 
>>  $ cat /etc/amd/amd.v   
>>  1   type:=ufs;dev:=/dev/sd2i
>>  2   type:=ufs;dev:=/dev/sd2j
>> 
>> 
>> ANDit works!
>> 
>> start the system up, I get this:
>> 
>>  $ df
>>  Filesystem  512-blocks  Used Avail Capacity  Mounted on
>>  /dev/sd2a  101167620381275728421%/
>>  /dev/sd2h 1031983648   9803800 0%/home
>>  /dev/sd2f  413682820   3929968 0%/tmp
>>  /dev/sd2d  8264188   2369920   548106030%/usr
>>  /dev/sd2e  2065116  2104   1959760 0%/usr/local
>>  /dev/sd2g  4136828 64920   3865068 2%/var
>>  amd:365830 0 0   100%/v
>> 
>>  $ ls /v/1/
>> [...expected output from files and directories on that file system...]
>> 
>>  $ df
>>  Filesystem  1K-blocks  Used Avail Capacity  Mounted on
>>  /dev/sd2a  505838 8360239694617%/
>>  /dev/sd2h 515991824   4901900 0%/home
>>  /dev/sd2f 206841410   1964984 0%/tmp
>>  /dev/sd2d 4132094   1280264   264522633%/usr
>>  /dev/sd2e 1032558  1052979880 0%/usr/local
>>  /dev/sd2g 2068414 32572   1932422 2%/var
>>  amd:92953   0 0 0   100%/v
>>  /dev/sd2i   2106117872 298739480 170207250415%/tmp_mnt/dbu/v/1
>> 
>> Success!!
>> well...no.  Seems it never umounts the amd file systems.  And that is
>> basically the point of this exercise -- to increase the odds that a FS
>> isn't mounted when the power goes out.
>> 
>> Am I doing something wrong?  Do I have inaccurate expectations of
>> what amd(8) does with local file systems? 
>> 
>> Nick.
>> 
>> OpenBSD 6.6-current (GENERIC.MP) #599: Sat Jan 11 18:52:00 MST 2020
>>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 2038652928 (1944MB)
>> avail mem = 1964462080 (1873MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebd30 (52 entries)
>> bios0: vendor American Megatrends Inc. version "1020" date 12/15/2014
>> bios0: PowerSpec V400
>> acpi0 at bios0: ACPI 5.0
>> acpi0: sleep states S0 S3 S4 S5
>> acpi0: tables DSDT FACP APIC FPDT MSDM MCFG LPIT SLIC HPET SSDT SSDT SSDT 
>> UEFI
>> acpi0: wakeup devices XHC1(S3) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0)
>> a

automounter (amd) local file system issue

2020-01-12 Thread Nick Holland
Hiya.

I'd like to use amd(8) to automatically mount and dismount local file
systems.  The file systems in question are big, lots of complicated
links, lots of files, and take a while to fsck if the power goes out
unexpectedly, and are used relatively rarely (maybe an hour a day).
Sounds like a perfect job for amd(8)!

The file systems in question are mounted to /v/1 and /v/2

I've got the following set up:

  $ cat /etc/rc.conf.local
  amd_flags=-l syslog -x all -c 10 -w 10
  lockd_flags=
  portmap_flags=

  $ cat /etc/amd/master   
  /v  amd.v

  $ cat /etc/amd/amd.v   
  1   type:=ufs;dev:=/dev/sd2i
  2   type:=ufs;dev:=/dev/sd2j


ANDit works!

start the system up, I get this:

  $ df
  Filesystem  512-blocks  Used Avail Capacity  Mounted on
  /dev/sd2a  101167620381275728421%/
  /dev/sd2h 1031983648   9803800 0%/home
  /dev/sd2f  413682820   3929968 0%/tmp
  /dev/sd2d  8264188   2369920   548106030%/usr
  /dev/sd2e  2065116  2104   1959760 0%/usr/local
  /dev/sd2g  4136828 64920   3865068 2%/var
  amd:365830 0 0   100%/v

  $ ls /v/1/
[...expected output from files and directories on that file system...]

  $ df
  Filesystem  1K-blocks  Used Avail Capacity  Mounted on
  /dev/sd2a  505838 8360239694617%/
  /dev/sd2h 515991824   4901900 0%/home
  /dev/sd2f 206841410   1964984 0%/tmp
  /dev/sd2d 4132094   1280264   264522633%/usr
  /dev/sd2e 1032558  1052979880 0%/usr/local
  /dev/sd2g 2068414 32572   1932422 2%/var
  amd:92953   0 0 0   100%/v
  /dev/sd2i   2106117872 298739480 170207250415%/tmp_mnt/dbu/v/1

Success!!
well...no.  Seems it never umounts the amd file systems.  And that is
basically the point of this exercise -- to increase the odds that a FS
isn't mounted when the power goes out.

Am I doing something wrong?  Do I have inaccurate expectations of
what amd(8) does with local file systems? 

Nick.

OpenBSD 6.6-current (GENERIC.MP) #599: Sat Jan 11 18:52:00 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2038652928 (1944MB)
avail mem = 1964462080 (1873MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebd30 (52 entries)
bios0: vendor American Megatrends Inc. version "1020" date 12/15/2014
bios0: PowerSpec V400
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MSDM MCFG LPIT SLIC HPET SSDT SSDT SSDT UEFI
acpi0: wakeup devices XHC1(S3) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0)
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) Pentium(R) CPU J2900 @ 2.41GHz, 2417.12 MHz, 06-37-08
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 2416.67 MHz, 06-37-08
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 2416.69 MHz, 06-37-08
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 2416.68 MHz, 06-37-08
cpu3: 

Re: Odd /tmp behavior

2020-01-08 Thread Nick Holland
On 2020-01-07 14:06, Karel Gardas wrote:
> 
> 
> On 1/7/20 7:38 PM, Jordan Geoghegan wrote:
>>  > Using softdep on /tmp is a silly idea. >
> Why? To naive eyes it may look like a natural solution: e.g. before temp 
> file is even created (on drive), it may be deleted which means there is 
> no meta-data change hence speedup of operation on /tmp. In case of 
> classical ffs, you will need to create file (sync meta-data update), 
> save some data (async), delete file (sync meta-data update). But 
> honestly still need to read the code...
> 

I'm not going to go nearly as far as to say it's a silly idea (as I
do it myself) but ... be aware softdep is funky.  Weird stuff happens
when Softdeps are working as designed.

When you do things out of order, things happen...well, out of order.
So ...
  create file
  delete file
  create file
  delete file 
  create file
  delete file
  create file
  delete file 
  create file
  delete file
sounds perfectly safe, as long as "file" is smaller than available
disk space, right?  Softdeps...no so much.  This can actually result
in running out of disk space, as the deletes may not happen until
after the creates.  

Another place where softdeps will sometimes bite you is when you
unpack tar balls that overwrite existing files -- simple thought
process says, "as long as you have enough space to cover the growth,
fine".  Softdeps might surprise you.  You may get an "out of disk
space" error, and a minute later, see much more space than you
thought you could ever need to accomplish the task, once the deletions
have time to take effect.

So ... make sure you have lots of extra disk space...if things are
snug, it's a bad place to use softdeps.

Nick.



Re: Boot fail using internal SATA port, success using USB port.

2020-01-07 Thread Nick Holland
On 2020-01-05 12:29, hkew...@cock.li wrote:
> summary: OpenBSD installs to internal HDD from external USB but fails
> to load after the first reboot. If the HDD is removed from the internal
> port and is connected via a "SATA to USB" cable it boots succesfully.
> 
> I am a new and inexperienced user, excuse my ignorance.
> 
> All the details and things I have tried so far:
> 
> -All relevant UEFI options configured to legacy mode.

careful with this.  Just because it says it supports legacy mode doesn't
mean the BIOS was extensively tested in legacy mode.  I'd try both modes,
just for giggles.

> -minirootXX.fs copied to USB using rufus.
> -USB boot using legacy mode.
> -In install: whole disk mbr-auto config.

see above. :)

> -After reboot DELL logo is displayed 3 times. On the 3rd time it stays
> static.
> --Using gpt format instead results in an infinite boot loop.

oh. you did try GPT.  nevermind.

> -Starting UEFI-menu(f2) or diagnostics(f5) or boot-menu(f12) appear to
> initiate but then stay static. The UEFI appears to be completely
> "bricked". There is no way to proceed.
> --Resetting UEFI using CMOS and booting with the HDD in internal port
> still renders UEFI "bricked" although it gives a PXE option because it
> is enabled by default in the now reset UEFI.
> --Merely performing a "clean" on diskpart(win7) to the HDD and plugging
> it back "unbricks" the UEFI.
> --Merely removing the HDD "unbricks" the UEFI.
> -Connecting HDD using "SATA to USB" cable(even without CMOS reset)
> works and OpenBSD boots.
> -Installing Windows 7(in the same manner OpenBSD was) works and boots
> from the internal SATA port.
> 
> Deduction: There seems to be something not allowing OpenBSD to boot
> from the internal SATA port, in addition to it rendering the laptop
> unusable until the HDD is removed, cleaned or connected via USB port.
> 
> I have taken the time to write all the UEFI configuration I use. Please
> check it if you think the problem stems from there.

ouch.  However, the effort is appreciated.
 
> hardware: DELL Latitude e5440

Pretty sure I've tested one of those, they work.

As I recall, the E5440 is a few years old, and if I recall properly, the
battery wasn't very long-lived in it.  And the Dells of that vintage had
a really wacked default -- someone decided it would be best to default
to "RAID" for disk mode.  Yes, on a one drive laptop.  For safety reasons,
OpenBSD (and many other non-windows OSs) disable disk access if the disk
controller is in RAID mode rather than ACHI or "legacy" mode.  

So ... is it possible the CMOS battery is bad on your machine?  This would
explain a "Power up, set up machine, install, reboot  -- ok".  "power off,
power back on later, won't successfully boot" (the kernel would load, but
be unable to access the disks and then panic).  I'm not convinced this is
the problem, but might be.

Nick.



Re: Hardware for Access Point on OpenBSD

2020-01-01 Thread Nick Holland
On 2020-01-01 13:42, Zé Loff wrote:
> 
> On Wed, Jan 01, 2020 at 08:54:46AM -0700, List wrote:
>> Hi *, 
>> I am currently building a home router based upon OpenBSD. 
>> I therefore need some kind of WIFI Hardware. This piece of hardware
>> needs to be connected over usb. 
>> Do you have any suggestions or recommendations ? As far as I can see
>> it's pretty hard  to find an antenna which is connected  via USB an runs
>> on a supported chipset. It is  easy to get your hands on a
>> realtek-chipset driven device. But urtw(4) doesn't support  Host AP
>> mode. Only ones that do are: athn(4),  ral(4), ath(4). 
>> Finding those is hard. 
>> 
>> Maybe you guys know things I couldn't find ? 
>> 
>> g, 
>> Stephan
>> 
> 
> In all honesty, and I've tried what you are aiming for a couple of times
> in the past, it's just easier to get a dedicated AP (or a cheap wifi
> router with a cable on the ethernet switch, which is usually bridged
> with the wifi interface) and connect to an OpenBSD router which will
> do all the necessary packet filtering (including keeping the AP/router's
> firmware from reaching the internet, if needed be).  IMHO this will be
> stabler and faster than trying to find an adequate wifi board.  And
> these days you're bound to get nice perks like multiple SSIDs and
> 802.11ac speeds (or whatever the latest 802.11* protocol is), which
> AFAIK aren't available on OpenBSD yet.  Also, note that (if I am not
> mistaken) ural(4) are the only USB Wi-Fi interfaces that can handle Host
> AP mode, and they only do 802.11b/g which is kind of slow by today's
> standards.

Agreed.
Not only does the SW/HW work better, usually the best place to put an AP
is not the best place to put a router.  My AP is in my attic, my router
is in my basement, with one chunk of CAT6 between them.  
 
Putting an important radio receiver next to a bunch of RF-noisy computers
doesn't work so hot. :)

Nick.



Re: Hyperbola Gnu Linux changing to Bsd

2019-12-30 Thread Nick Holland
On 2019-12-30 14:31, SOUL_OF_ROOT 55 wrote:
...
> What are the opinions of the OpenBSD developers about Hiperbola GNU/Linux?

Just my opinion...

A linux distribution (repacking other people's stuff) that I never
heard of is going to abandon their old work and users in favor of
actually making a new operating system, which will involve actually
making code and making it work "some day".  What could go wrong?

Other than their rather twisted definition of "free", which has
been sufficiently hashed and rehashed, I don't see anything there
to think about.  There's no product.  Just a lot of words.  And
most of them are stupid words.  I just spot checked one of the
"license problems" they think they spotted in the OpenBSD tree.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/landisk/include/endian.h?rev=1.2

What exactly are they planning on licensing in that?

When they have something to show...let's be real, I'll probably
ignore that, too.  There's nothing about their goals and
objectives that interests me at all.

Nick.



Re: cvs checkout of src,ports and xenocara gives duplicate key msg

2019-12-15 Thread Nick Holland
On 2019-12-15 09:42, putridsou...@gmail.com wrote:
> I recently did a checkout of the src,ports and xenocara
> repositories and was greeted by the following message on 
> each checkout. After this the command proceeds smoothly.
> Also doing "echo $?" gives "0" so it's not a error.
> 
> cvs server: duplicate key found for 'y'
> 
> A quick search online tied this message to file corruption.
> On further testing, the message repeated itself. Can anyone
> indicate if this has something to do with my hard disk or
> anoncvs server.

You left out an incredible amount of information and context
here, so I'm going to say there's a PEBKAC here somewhere.

Now, if you want to tell us in detail what you are doing and
what is actually happening.  Otherwise, best I can say is
something ain't right.

Nick.



Re: Third server now locked up after reboot due to no keyboard attached

2019-12-15 Thread Nick Holland
On 2019-12-14 14:28, Alfred Morgan wrote:
> I have now another machine running OpenBSD not recover from a reboot. I
> thought I was having hardware issues with my two other servers (both zbox)
> and now this third one (Dell) with totally different hardware is having the
> same problem getting stuck at the boot> prompt. The problem goes away and
> boots continue normally if I attach a USB keyboard in all three cases. I
> feel like this problem started showing up around OpenBSD 6.4. Is this a
> known issue?

certainly not a universal issue...(i.e., I haven't experienced it)

> When there is no keyboard attached the boot> prompt shows a box with a
> question mark in it looking like an unknown character. Picture showing this
> on bootx64 3.46:
> https://photos.app.goo.gl/7HAqQic6GArLGzaXA

Well...yeah.
If the boot loader echoed anything, it's behaving As Desired -- a char at
the command line means "STOP ALL BOOTING, I have something special I want
you to do".

The boot loader is entirely depenedent upon the firmware (BIOS), the kernel
isn't loaded, OpenBSD isn't running.  There's not a lot that OpenBSD
can do about this -- the boot loader could "eat" all chars sitting in the
buffer, but that would make interrupting the boot process just a little
more difficult when you DO want to stop it.

However, I think there are a few things you might be able to do to solve
your problem...

1) BIOS upgrade.  Long shot, but maybe?
2) BIOS config option?  Also a long shot, but since I'd call this a
boot firmware bug, maybe some combination of USB related options would
fix this?
3) a boot.conf file should fix -- simply putting "boot" in /etc/boot.conf
should override anything in the keyboard buffer.  Need to "control" the
boot?  plug in a keyboard and hold down either CTRL key, and you will be
given the boot> prompt.

Nick.


> Here is the dmesg from my latest Dell server:
> 
> OpenBSD 6.6 (GENERIC.MP) #3: Thu Nov 21 03:20:01 MST 2019
> r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> GENERIC.MP
> real mem = 8487182336 (8094MB)
> avail mem = 8217251840 (7836MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe (71 entries)
> bios0: vendor Dell Inc. version "A02" date 11/14/2014
> bios0: Dell Inc. OptiPlex 3020M
...



Re: Softdep and noatime

2019-12-01 Thread Nick Holland
On 2019-11-30 08:12, Raymond, David wrote:
> I am switching to OpenBSD from Linux and I have questions about the
> use of softdep and noatime in mounting disks.  I have a variety of
> systems with a mix of SSDs and rotating disks.
> 
> Softdep seems to have some advantages in speeding file access, but it
> is not the default.  Are there any downsides in using softdep?

it's more complicated, and thus, will have more bugs.
My personal experience: I'd trust softdep more than any modern Linux
filesystem, BUT its still more complicated, and thus will have more
bugs than the default FFS.

> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?

Nothing to do with SSDs, as your quest to minimize writes on SSDs is
demonstrated stupid and pointless.  SSDs fail much more often for
reasons other than write fatigue, Optimizing for write fatigue is
like protecting your ship against icebergs hitting the propeller.

VERY VERY few applications use atime, and yet, it requires an update
to the directory for EVERY SINGLE ACCESS.  Ouch.  So, it's a
non-trivial performance gain if you turn it off.  That's a great
reason to turn it off.  Not SSDs.

HOWEVER...if you don't need performance and you can't point to a
real benefit, as always, keep it on the default.

Nick.



Re: Installing OpenBSD -current snapshots

2019-11-29 Thread Nick Holland
On 2019-11-29 02:26, Clay Daniels wrote:
> Nick, thanks for straightening me out about what is actually going on here
> with the install. I see that there is now a fresh snapshot with today's
> date, not the one I downloaded and ran yesterday. This might tend to keep
> one busy. I'm not sure I would not be better off doing what Bruno & Marc
> suggested and run sysupgrade. Thanks to them for the advice.

sysupgrade does upgrades of existing systems.  Very slick.  However, it
isn't for fresh installs, and if you have convenient console access, it's
not the preferred way of doing it.  And based on the questions here,
NO WAY.  You need to understand what's going on before you start doing
unattended upgrades.

It also (by default) assumes network upgrades, and if you are wanting
everything on local media, there are existing better solutions.

And yes, following current is a never-ending quest.  However, problems
are relatively rare and usually not a big deal, and generally fixed on
the next snapshot.
 
> If I do decide to put the filesets on the the install thumbdrive, I see a
> total of 26 files in the directory. Obviously some are not necessary like
> the floppy or both the .fs & .iso (just one needed), nor the test
> instructions, etc.
> So which files do I REALLY need on my usb thumbdrive to get a complete
> install, x included?


STOP STOP STOP STOP.
You need to re-read what I wrote and the install part of the FAQ some
more times.
The install66.fs file is an image with the *entire install set included*.
You do not want to add things.  You COULD do some voodoo to add stuff to
the miniroot66.fs, but PLEASE DON'T...you would just be re-inventing the
install66.fs, poorly and with more difficulty.

> 
> Please excuse the "top-posting". That's the only way my darn google mail
> does reply's. Kind of irritating, to me and the reader too.
 
Bottom posting was invented for those who can't write in complete thoughts
with context.  You know, like most of the computer world. :-/

Nick.




> Clay
> 
> 
> 
> 
> On Thu, Nov 28, 2019 at 12:34 PM Nick Holland 
> wrote:
> 
>> On 2019-11-27 21:29, Edgar Pettijohn wrote:
>> > On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote:
>> >> I have successfully installed OpenBSD 6.6 release and would like to give
>> >> the Current Snapshots a try. I went to a mirror, and to:
>> >>
>> >> Index of /pub/OpenBSD/snapshots/amd64/
>> >>
>> >> I saw install66.fs (probably for usb memstick) and install66.iso (surely
>> >> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb
>> >> thumbdrive, and it starts the install. When i get into the install it
>> asks
>> >> where are the file sets? Humm, maybe it gets these online and it tries
>> to
>> >> do this but no luck. It was late last night, and I checked to see if it
>> had
>> >> written anything to my disk, which it had not, and went to bed. This
>> >> evening I'm looking a bit deeper at the snapshot directory and I
>> suspect I
>> >> need to provide the install with base66.tzg at ~239Mb.
>>
>> NO!
>>
>> [snip misleading stuff]
>> > I noticed this also, but hadn't had time to figure out if I had messed
>> up or
>> > the installer had. As a general rule I assume its me that messed up. Its
>> odd
>> > if you mount the install66.fs you can see the pub/amd64 directory, but
>> during
>> > installation it can't seem to find the directory regardless of what I
>> have
>> > tried.
>> >
>> > Edgar
>>
>> First of all...nothing at all to do about snapshots -- the OpenBSD
>> installation process has remained amazingly stable over the last 20
>> years.
>> New options here and there, but overall, very similar.  Unless something
>> changed in the last few days, installing a snapshot is identical to
>> installing 6.6.
>>
>> The installXX.iso and installXX.fs are complete, stand-alone installation
>> kits.  Everything you need is on them.  You can boot from them, and all
>> the installation files are right there.  Look Ma!  No network needed!
>> ...well...unfortunately there is the issue of firmware files, which are
>> legally not feasible to put on the install media, so you will need network
>> for most machines eventually.  But let's ignore that for now. :)
>>
>> Once the system has booted on the install kernel, you have three devices
>> you are working with:
>> 1) the install kernel's internal "RAM disk" that is part of bsd.rd which
>>   you booted from,
>> 2) your target disk
>> 3) the USB drive with the install f

Re: Installing OpenBSD -current snapshots

2019-11-28 Thread Nick Holland
On 2019-11-27 21:29, Edgar Pettijohn wrote:
> On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote:
>> I have successfully installed OpenBSD 6.6 release and would like to give
>> the Current Snapshots a try. I went to a mirror, and to:
>> 
>> Index of /pub/OpenBSD/snapshots/amd64/
>> 
>> I saw install66.fs (probably for usb memstick) and install66.iso (surely
>> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb
>> thumbdrive, and it starts the install. When i get into the install it asks
>> where are the file sets? Humm, maybe it gets these online and it tries to
>> do this but no luck. It was late last night, and I checked to see if it had
>> written anything to my disk, which it had not, and went to bed. This
>> evening I'm looking a bit deeper at the snapshot directory and I suspect I
>> need to provide the install with base66.tzg at ~239Mb.

NO!

[snip misleading stuff]
> I noticed this also, but hadn't had time to figure out if I had messed up or
> the installer had. As a general rule I assume its me that messed up. Its odd
> if you mount the install66.fs you can see the pub/amd64 directory, but during
> installation it can't seem to find the directory regardless of what I have 
> tried.
> 
> Edgar

First of all...nothing at all to do about snapshots -- the OpenBSD
installation process has remained amazingly stable over the last 20 years.  
New options here and there, but overall, very similar.  Unless something
changed in the last few days, installing a snapshot is identical to
installing 6.6.

The installXX.iso and installXX.fs are complete, stand-alone installation
kits.  Everything you need is on them.  You can boot from them, and all
the installation files are right there.  Look Ma!  No network needed!
...well...unfortunately there is the issue of firmware files, which are
legally not feasible to put on the install media, so you will need network
for most machines eventually.  But let's ignore that for now. :)

Once the system has booted on the install kernel, you have three devices
you are working with:
1) the install kernel's internal "RAM disk" that is part of bsd.rd which
  you booted from,
2) your target disk 
3) the USB drive with the install files on it.

The reason you can't see the install files on the USB stick from the
install kernel is they aren't mounted.  You didn't boot from the entire
USB stick, you booted from ONE TINY LITTLE bsd.rd file, that just happened
to be sitting on the big USB stick...but as far as bsd.rd is concerned,
the USB stick isn't part of the booted environment (yet).

You aren't booting from a "Live Media".  You are booting from a tiny kernel
with a built in file system that's sitting on the same inert file system as
the install files.

Read that over and over until you understand what I'm saying, not what you
are assuming is going on.  It's really important to understand.  It's very
different from many Linux installation processes -- you are running off a
file only 10MB in size which is now completely in RAM.  That file JUST
HAPPENED to come from a USB stick that's much bigger.

So, when it comes to answering where your install files are, they are on
a disk, but it's NOT a mounted disk.  It's on your USB drive that's not
mounted now, and won't be after installation, but could be useful shortly.

Your next problem is...WHICH disk?  On a minimal system, it would be the
next sd device after your install disk -- assuming you are installing to
sd0, your USB stick might be sd1.  HOWEVER, if you have a flash media reader
on your system, who knows where it is.  One trick would be to unplug your
USB drive and plug it back in and look at the white-on-blue console message
that come up at you.  Yes, you are unpluging your boot device, sounds bad,
but read what I wrote earlier, it's no longer using that -- the boot has
completed, and it's running from RAM now, it's completely ignoring that
USB drive.  So let's say you do this and you see it's sd4.  Tell the
installer the files are coming from a file system not currently mounted
and when it asks, tell it "sd4"

Nick.



Re: Deleting softraid Devices Fujitsu Sparc

2019-11-28 Thread Nick Holland
On 2019-11-27 11:23, Kihaguru Gathura wrote:
> Hi,
> 
> An error while deleting softraid device follows
> 
> --
> Available disks are: sd0 sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd0] ?
> sd0: FUJITSU, MAT3073N SUN72G, 0602
> serial.FUJITSU_MAT3073N_SUN72G_000506B00RAR_AAN0P5200RAR (68.4G)
> sd1: FUJITSU, MAT3073N SUN72G, 0602
> serial.FUJITSU_MAT3073N_SUN72G_000506B00SSL_AAN0P5200SSL (68.4G)
> sd2: OPENBSD, SR RAID 1, 006  (68.4G)
> Available disks are: sd0 sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd0] !
> Type 'exit' to return to install.
> www# bioctl -d sd2
> bioctl: Can't locate sd2 device via /dev/bio
> 
> 
> The aim is to remove the device from the system and then:
> 
> # dd if=/dev/zero of=/dev/rsd0c bs=1m count=1
> # dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
> 
> to reuse the disks.
> 
> Thanks,
> 
> Kihaguru
> 

The install kernels have very minimal disk support.  In the case of
amd64/i386, it's one wd device -- wd0, not sure about sparc64, but
I'd bet a cheap lunch that sd2 is not there. :)

After booting your install kernel, do this:
   # cd /dev
   # sh MAKEDEV sd0 sd1 sd2
or whatever you need to accomplish your task at hand.

NOW you will be able to do what you wish.  Yes, the installer script 
does this for you.  And yes, this is a common issue regardless of
platform.

Nick.



Re: Home NAS

2019-11-18 Thread Nick Holland
On 2019-11-17 11:39, Jean-François Simon wrote:
> Hi,
> 
> I found it, there exist glastree which is available from ports.
> 
> Nice small "poor man's" backup as the author qualifies,
> though makes incremental backup through hard links:
> 
>   # if yesterday does not exist or today is newer, copy the file
>   # else hard link the file to yesterday

rsync --link-dest -- it's been in rsync for well over 10 years at this
point.  Little wrapper shell script and away you go...

Nick.



Re: OpenBSD and solid state disks

2019-11-03 Thread Nick Holland
On 2019-11-02 16:10, Raymond, David wrote:
> I recently installed OpenBSD on a Lenovo X1 Carbon with a solid state
> drive and it works great.

yep.

> My question is whether OpenBSD addresses the special characteristics
> of solid state drives, especially those having to do with longevity
> and reliability.

Just Use them, and plan on replacing them when they need to be replaced,
or at least demoting them to "when this fails, I won't cry" uses.

In other words, treat them JUST LIKE EVERY OTHER DRIVE.

If I hand you a five year old magnetic drive, would you put it in a
mission critical application?  Probably not.  If you have five year
old hardware in a mission critical application, you should be looking
at replacement.  Treat your SSDs exactly the same way, you will
have no problems.  Used very hard, SSDs last many years.  Used like
most people use a laptop, you will be replacing for other reasons
(capacity, hw it is in is uselessly old, etc.) long before the drives
wear out.

The obsession with SSD write fatigue is silly.  All drives can (and
do) fail, you must have a plan to deal with that, and in my 
experience with SSDs, write fatigue is NOT the primary killer, it's
just a predictable one.

Nick.



Re: Will Theo de Raadt and other OpenBSD developer answer this topic (https://marc.info/?l=openbsd-misc=157234932505571=2)?

2019-10-30 Thread Nick Holland
On 2019-10-29 23:50, Clark Block wrote:
> Will Theo de Raadt and other OpenBSD developer answer this topic (
[...link to drivel deleted...]

What, are you looking for someone to provide comments on your
term paper?  Ok, You did cite a reference, not proper bibliography
format.  It's been a long time, but I thought they did teach proper
citing of references in sixth grade.  Bonus points for reading a
book.  Lost points for only one source.  But nothing you have said
qualifies as profound for anything above primary school level. 
Nothing indicates you actually KNOW anything about the topics you
write.

Dude.  You post meaningless crap on this list and yet show no
evidence of actually being an OpenBSD user.  You think you
have great ideas about how things should be done?  Prove it.
DO something.  Don't talk about it.  If your desire in life is
to argue about the number of angels that can dance on the head
of a pin or "best programming languages" or "desktop experience",
please, go elsewhere.

Nick.



Re: Misc i386 questions

2019-10-14 Thread Nick Holland
On 10/13/19 12:39 AM, Sean Kamath wrote:
> Doh!
> 
> set tty com0
> 
> Alix is coming along OK now.  Still have questions about i386 and
> SCSI. . .
> 
> Sean
> 
> 
>> On Oct 12, 2019, at 23:13, Sean Kamath 
>> wrote:
>> 
>> Hi.
>> 
>> In my odyssey to get larger disks on my Alix machines, I bought
>> some 16G CompactFlash cards. I put install65.fs on a card and tried
>> to boot it on the Alix, but it just reboots after it loads the
>> kernel.
>> 
>> Meanwhile, the VM I used to dd the install65.fs file to the CF card
>> is running 6.0, so figured I should update it (with a reinstall,
>> rather than updates).  I tried to boot bsd.rd and install 6.5, but
>> it didn’t see the SCSI drive on the VM (but 6.0 did with no
>> issue).  I even downloaded install65.iso and tried to install on a
>> brand new VM (VMware Fusion 11.5 on a Mac running Mojave) with a
>> SCSI drive, but nope.  IDE drives are seen just fine.
>> 
>> So. . . did I just miss something about i386 and SCSI support?

What SCSI hw are you emulating in your VM?
What happens if you change that?

And to be clear -- when you say it doesn't see the SCSI drive, how
are you not seeing it (i.e., what did you do to "see it" and what
was the result?).

Nick.



Re: BACK TO BASICS

2019-10-09 Thread Nick Holland
On 10/9/19 11:19 AM, openbsd.s...@0sg.net wrote:
> Here's what I think.
...[bla bla bla]...
> Amirite ? ;)

I don't know.  Let's see your work.

I don't care what your theoretical arguments are, I want to see
results.

Nick.



Re: A sad raid/fsck story

2019-10-05 Thread Nick Holland
On 10/4/19 8:37 AM, sven falempin wrote:
...
> How [do I] check the state of the MIRROR raid array , to detect large
> amount of failures on one of the two disk ?
> 
> Best.
> 

fsck has NOTHING to do with the status of your drives.
It's a File System ChecKer.  Your disk can be covered with unreadable
sectors but if the file system on that disk is intact, fsck reports
no problem.  Conversely, your disks can be fine, but your file system
can be scrambled beyond recognition; bad news from fsck doesn't mean
your drive is bad.

To check the status of the disks, you probably want to slip a call
to bioctl into /etc/daily.local:

# bioctl softraid0
Volume  Status   Size Device  
softraid0 0 Online  7945693712896 sd2 RAID1 
  0 Online  7945693712896 0:0.0   noencl 
  1 Online  7945693712896 0:1.0   noencl 

This is a happy array.  If you have a bad drive, one of those 
physical drives is going to not be online.

Nick.



Re: A sad raid/fsck story

2019-10-04 Thread Nick Holland
On 10/3/19 10:01 AM, sven falempin wrote:
> Dear readers,
> 
> I was running a OpenBSD (6.4) device, with a raid mirror array.
> One of the disk failed, so the system ask me to fsck,

Probably not quite that simple.  More likely, the disk failed,
that took the system down hard, and it needed an fsck on reboot.
Which is normal, RAID or otherwise. 

> which I did before checking the raid status manually ( :'( ) ,
> THEN I rebooted and softraid told me: one of the hard drive is dead.
> 
> But fsck already destroyed a few file on the mirror.

that seems unlikely.  that's not what fsck does -- fsck's job is to
repair a file system.  If it removes a file, the file is already
damaged.

> Probably a user error, nevertheless, In openbsd 'simply work' mindset,
> maybe the /etc/rc could warn or even perform some bioctl check on raid
> array when first fsck / mount
> fails.

I'm not seeing what this has to do with RAID, soft or otherwise.  If your
system needed an fsck, it needed it whether it was a simple drive or a
RAID array.  If you need an fsck, you are likely to have lost data.

> ( Lost data recovered from backup )

And again...nothing to do with either fsck or RAID -- you have to have
a backup.  RAID doesn't change that.

Nick.



Re: How can I contribute code to openbsd

2019-09-30 Thread Nick Holland
subject fixed, hopefully. :)

On 9/28/19 7:05 PM, cc wrote:
> 
> Hello,
> 
> 
> I recently started to study openbsd. I am a computer major student. How can I 
> contribute to openbsd?
> 

while ! dead; do
DoSomething.
submission="sucks" # Accept this. It's probably true.
while [[ $submission == "sucks" ]]; do
SubmitIt
AcceptCriticism
learn
if [[ $criticism == "no way" ]]; do
break # not everything is appropriate.
fi
reviseBasedOnCriticism 
done # Congrats, your submission was accepted! 
done # not dead yet.


People usually screw up on accepting that their first
submission sucks.  And they really get confused
when they are told what to fix and resubmit it, "why 
doesn't the committer just do it?"  That's where the
"learn" step comes in -- the committer is trying to
help you get a point your submissions DON'T suck
initially.

Find something you want to fix or improve...do it,
and enter the loop. :)

Nick.



Re: How can I remove sets installed by sysupgrade?

2019-09-18 Thread Nick Holland
On 9/17/19 12:23 PM, Marc Espie wrote:
> On Tue, Sep 17, 2019 at 02:31:59PM -, Stuart Henderson wrote:
>> (To be clear, I think installing a restricted subset of the OS for
>> security reasons is pointless here, but can be really helpful when you
>> have to deal with limited space in partitions - and those just saying
>> "storage is cheap" are ignoring the often very real cost of getting
>> to the machine to replace the storage :)
> 
> Ditto.
> 
> We still run on somewhat cramped machines, and even replacing an SD card
> with a bigger model might sometimes be an issue because of various reasons.
> 
> ... or stuff with utterly outdated controler formats, where you may
> get in situations that your SCSI3 disk buys it and that's it, no more
> full installs for you.
> 

Ditto followed by a single quote?

We also work great on some really slow storage, like USB flash drives.
Leaving out x*tgz, and compXX.tgz are big time savers when upgrading
a flash based install.

On the other hand, KARL and library randomization are also killing those
solutions...so I guess it might be time to move on?

Nick.



Re: authpf unable to exit ssh without control C

2019-09-16 Thread Nick Holland
On 9/15/19 7:31 AM, shadrock uhuru wrote:
> hi everyone
> i can login with authpf but unable to exit or control D out of the ssh
> session
> the only way out is to control C which also kills any other ordinary ssh
> user connected to the server
> my authpf user has authpf as its login shell and login class,
> is this normal behaviour  ?
> shadrock
> 

If I understand your request, you want someone to log into your system,
which brings up authpf, and you want them to be able to do something to
exit to a shell prompt on that server and still leave the authpf rules
in place?

That's not the way authpf was designed.

The idea is that when authpf is invoked, it activates certain rules,
presumably regarding the IP address in question, and when authpf exits,
it removes those changes.  Connect to authpf, now you can access the
web site, or FTP or whatever it is you need, terminate authpf, and no
one else at your IP can do those things.  If you are letting these same
users access the shell prompt, your usage is not as paranoid as authpf
was designed to deal with, it's probably not the right tool for the job,
or your expectations are wrong.

I run a private IRC server, which is blocked on the 'net by PF, but as
all the users are people I know in real life and friends, I trust them
to be able to activate their own IP addresses, so I just wrote a simple
(and surely insecure) script to add that user's IP address to the PF
table that permits them access to the system.  What this doesn't do
(and I'm not sure how you expect to do this) is clear the connections
when they leave.  In my case, I don't care -- the odds that after Fred
gets a new IP address that his old IP address will end up in the hands
of someone wanting to have access to my IRC server for malicious
reasons (and they find it!) is pretty small.  But that might not be
your use case.  If you need to close those openings...you had best
think hard about how you expect that to happen.

Nick.



Re: handling snapshot installation in production environment

2019-09-02 Thread Nick Holland
On 9/2/19 6:48 AM, Marcus MERIGHI wrote:
> Hello Joerg, 
> 
> just passing on my user experience...:
> 
> streckf...@dfn-cert.de (Joerg Streckfuss), 2019.09.02 (Mon) 10:15 (CEST):
>> Furthermore I'm not sure which snapshot should I run. Almost every day
>> there will be a fresh one. 
> 
> you seem to be watching closely, therefore you will notice a time when
> there are no new daily snapshots for a couple of days. this is usually
> when the next release is tagged/built. additionally you can monitor
> ports@ to see when the ports tree gets locked for the next release. 

Careful with this ...  While this is what I used to do (which is kinda odd,
since I only run snapshots!), in recent releases, especially since the 
CD production was cut out of the release process, the time between
"tagging" and resumed development and new snapshots has dropped a LOT
to the point that it's difficult to catch.  I think Ian's tip is a bit
safer.

Nick.



Re: obsd web server

2019-09-02 Thread Nick Holland
On 9/1/19 5:49 PM, Gustavo Rios wrote:
> Hi folks,
> 
> i would like to confgiure my obsd server as a web server.
> 
> I would like to configure my web server to handle multiple domains
> without having to set each domain one by one.
> 
> I mean:
>   Every request for www.x.com is mapped into the root directory
> /var/web/www.x.com
> 
> Got the idea ? If a new server is required,  All i needed to do would
> create a directory inside /var/web with the full access string :
> 
> mkdir /var/web/www.newdomain.com
> 
> And i should not need to manipulate config files.
> 
> Thanks in advance
 
I don't think that's doable as you request, nor do I think it is a
noble goal. , Unless you have a really really unusual use case, you
will have per-site specific settings -- for example, HTTPS
certificates.

HOWEVER, with some trivial scripting, you can easily accomplish something
that appears to be what you request.  When you have a lot of similar
things to manage, think scripts. :)   Here's a primitive and untested
concept:

newweb:

#!/bin/ksh

mkdir -m755 /var/www/$1
chown (whomwever) /var/www/$1

cat >>/etc/httpd <<__ENDSITE

server "$1" {
alias "www.$1"
listen on $ext_addr port 80
log style combined 
log access $1.access
log error $1.error
root /$1
}
__ENDSITE   

/etc/rc.d/httpd reload


Now, in real life, you would want to flesh out that config a bit
more, and you would probably want to save a copy of the httpd.conf
file, and check if httpd errored, and if so, restore the old copy.
Lots of other error checking would be appropriate as well.

You could also just do something more sophisticated, like create 
an httpd.d directory and create a template domain.conf file in 
there for each one, and just add an "include" line in your 
httpd.conf for each new domain.  Now when you decide that all your
domains are NOT just alike, you can easily rev the ones that are
different.

Nick.



Re: Recommended web and database server specification

2019-08-15 Thread Nick Holland
On 8/14/19 9:20 PM, Aaron Mason wrote:
> Hi Tito
> 
> Can you tell us more about the database?  How often will its data be
> changed, added to, etc? How much data do you have?  How complex are
> your DB queries?  These answers will help determine the RAM and
> processor requirements for the database.
> 
> As for the web server daemon itself, I think Reyk Floeter would be the
> best placed to answer that question - also paging Nick Holland for
> more hardware expertise.
> 
> On Thu, Aug 15, 2019 at 12:57 PM Tito Mari Francis Escano
>  wrote:
>>
>> Hi to everyone at misc,
>>
>> I'm recently working on an OpenBSD-based PHP7 web application with
>> PostgreSQL-backend for a local government agency and was wondering what
>> would you recommend as the acceptable server specification. This web
>> application won't reach the Google or Facebook level of visits per day,
>> but I was hoping to prepare this be deployed and run for quite a long
>> time and ready for about 60,000 visits per day at most.
>>
>> Your advise and recommendation would be greatly appreciated. Thanks so much.

Dang, somehow, I've got a bad habit of hitting CTRL-ENTER at the end of 
lines, and that's "SEND" on some mail clients.  Did that twice in the
24 hours on two different mail clients.  sigh.

ANYWAY...

60,000 hits per day isn't the question.  Rarely does load come in evenly
spread out, usual things are spikey -- after school, after work, before
work, whatever.  So the scaling question is "how many hits per second
can you expect peak?" and "how much delay will your users tolerate at
that peak moment?"

And really, you need to test your own app in your own environment with
your expected peak load.

IF your bosses are insisting on "buy once for five years", you are going
to horribly overspend.  They are damn fools.  But, they are also "The
Boss", so you live by 'em.  You will save a lot of money by buying
something that will PROBABLY work for a year or so, and replace it *IF*
it turns out to be undersized.

If you want to do it right, take an old pc with a standard SATA disk,
build it out as a web server, and load test it with your peak expected
load with your application being used in a realistic way.  If it works,
get a faster server with more memory and use SSDs, and you will be in
great shape. 

Nick.



Re: Recommended web and database server specification

2019-08-15 Thread Nick Holland
On 8/14/19 9:20 PM, Aaron Mason wrote:
> Hi Tito
> 
> Can you tell us more about the database?  How often will its data be
> changed, added to, etc? How much data do you have?  How complex are
> your DB queries?  These answers will help determine the RAM and
> processor requirements for the database.
> 
> As for the web server daemon itself, I think Reyk Floeter would be the
> best placed to answer that question - also paging Nick Holland for
> more hardware expertise.
> 
> On Thu, Aug 15, 2019 at 12:57 PM Tito Mari Francis Escano
>  wrote:
>>
>> Hi to everyone at misc,
>>
>> I'm recently working on an OpenBSD-based PHP7 web application with
>> PostgreSQL-backend for a local government agency and was wondering what
>> would you recommend as the acceptable server specification. This web
>> application won't reach the Google or Facebook level of visits per day,
>> but I was hoping to prepare this be deployed and run for quite a long
>> time and ready for about 60,000 visits per day at most.
>>
>> Your advise and recommendation would be greatly appreciated. Thanks so much.

heh.  got called out, doesn't take much to make me start talking. :)



Re: Multiple video cards in X?

2019-08-05 Thread Nick Holland
On 6/28/19 5:01 AM, Joe M wrote:
(yes, over a month ago...) 
> Hello,
> 
> I have multiple video cards (AMD Radeon) cards working with OpenBSD.
>  I have 2 monitors connected to each card (HDMI and DVI ports).
> 
> The issues are that I can use only fvwm and I cannot move x windows 
> across the video cards. I can move x windows across monitors 
> connected to the same video card though.
> 
> I tried to hack around the Xenocara codebase to figure out if I can 
> fix it. During my adventures, I realized that though Xenocara can be 
> modified to support this, the issue is in the radeon driver 
> (radeondrm, I think). At that point, I gave up as I did not have the 
> bandwidth to figure out how radeondrm works.
> 
> It took me quite a lot of time to figure out the correct 
> configuration. I was hoping that I could get cwm to work. But, I 
> could not. Only fvwm works. I did not bother to dig through why.
> 
> joe:10114$ cat /etc/X11/xorg.conf
> 
> # get the xorg.conf.firstcard and xorg.conf.secondcard to work # 
> startx # uses xorg.conf # cd /etc/X11; start -- :1 -config 
> xorg.conf.secondcard # to get the second card working # once both of
>  them work, below is bringing them together to show all monitors at 
> the same time
> 
> # leave out the monitor sections as the X fills up the holes
> 
> Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen 
> 0" Screen 1 "Screen 1" RightOf "Screen 0" EndSection
> 
> Section "Screen" Identifier "Screen 0" Device "Card 0" EndSection
> 
> Section "Device" Identifier "Card 0" Driver "radeon" BusID 
> "PCI:1:0:0" #Option "Monitor-HDMI-0" "HG281D" Option "Monitor-DVI-0"
>  "AL2223W" EndSection
> 
> Section "Monitor" Identifier "AL2223W" Option "LeftOf" "HDMI-0" 
> EndSection
> 
> Section "Screen" Identifier "Screen 1" Device "Card 1" EndSection
> 
> Section "Device" Identifier "Card 1" Driver "radeon" BusID 
> "PCI:11:0:0" EndSection
> 
> joe:10131$ tail -5 /home/j/.xsession
> 
> # cwm cannot spawn multiple cards # exec /usr/X11R6/bin/cwm exec 
> fvwm
> 
> Hope it helps.

Quite a bit, if nothing else, just gave me hope and a starting 
place!

Here's what I ended up with as a MINIMAL xorg.conf that seems to work
for me, with the same quirks you describe:
==
Section "ServerLayout"
Identifier "Default Layout"
Screen 0 "Screen 0"
Screen 1 "Screen 1" Above "Screen 0"
EndSection

Section "Screen"
Identifier "Screen 0"
Device "Card 0"
EndSection

Section "Screen"
Identifier "Screen 1"
Device "Card 1"
EndSection

Section "Device"
Identifier "Card 0"
Driver "radeon"
BusID "PCI:3:0:0"
EndSection

Section "Device"
Identifier "Card 1"
Driver "radeon"
BusID "PCI:4:0:0"
EndSection
==

I added some monitor sections and not only did it work exactly
as it does with this, I couldn't make it do anything better or
different.

Key parts:
* the BusID lines seem critical.  Otherwise, just get first card.
* a "Screen" appears to be all monitors attached to one Device.
* My primary video card ("Screen 0" is attached to two monitors
on my desk, the secondary video card ("Screen 1") is attached to
two monitors above them.  Hence, the "Screen 1" Above "Screen 0"

I found Fluxbox seems to work with all four monitors as you
described fvwm doing.  The mouse can move appropriately between
all four monitors, but tasks can only go side-to-side in one
"screen" (two monitors).  This, I was actually excited about, as
I wanted to be able to have multiple INDEPENDENT desktops between
monitors. Ok, I got it between PAIRS of monitors.  Doesn't suck.

What DOES suck is some of the apps I wanted on both screens...don't.
Firefox and Chrome both refuse to start a new instance in the other
screen.  Not the end of the world, there are more browsers out there,
I suspect I can run iridium or something similar in one "screen" and
a cousin in the other.

My "screens" are slightly dissimilar -- screen 0 is two 1920x1200 
monitors, screen 1 is two 1920x1080 monitors.  No issues noted.

The login box and the ssh key box are centered between two monitors.
Annoying, but not a show stopper.  In general, while two monitors on
one card seemed to keep track of 

Re: problem to copy a (possibly large) file over a network device

2019-08-01 Thread Nick Holland
On 7/31/19 3:45 AM, Rudolf Sykora wrote:
> Dear list,

[probably irrelevant stuff snipped]

> I actually wanted to do a backup of the subtree with rsync over the
> network, but that didn't work, spitting sth. like
> 
> rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.3]
> [sender] _exit_cleanup(code=10, file=io.c, line=820): about to call
> exit(255)
...

Well, that looks broke.  Not supposed to do that.

> As I have no idea what can cause this behaviour, I am asking for any
> help.

Well, looking at the version of OpenBSD that you are using ... oh.
Well, your dmesg shows ... hmm.
Looking at your rsync command line I see ... well...
Your environment is ... hm. no idea about that either.

Not much to work with you on here other than you got an error message
you probably shouldn't have got.  

As for your follow up, no, there is no setting deliberately set to,
"don't work properly" you need to change to "work correctly" in OpenBSD.

Nick.



Multiple video cards in X?

2019-06-27 Thread Nick Holland
Hiya.

Before I spend a lot of time on what might be impossible, is it likely I
could succeed at getting multiple multi-head video cards working on
OpenBSD (amd64, radeon cards)?

I've got this in the machine:
OpenBSD 6.5-current (GENERIC.MP) #2: Sun Jun  2 00:29:17 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

ppb2 at pci0 dev 3 function 0 "Intel X58 PCIE" rev 0x22: msi
pci3 at ppb2 bus 3
radeondrm0 at pci3 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
ppb3 at pci0 dev 7 function 0 "Intel X58 PCIE" rev 0x22: msi
pci4 at ppb3 bus 4
radeondrm1 at pci4 dev 0 function 0 "ATI Radeon HD 3450" rev 0x00
drm1 at radeondrm1
radeondrm1: msi
...

so I got a pair of cards recognized.  Two monitors on one card Just Work
with X with no xorg.conf file.  xrandr sees the config and seems to
work, driving the monitors at full resolution.

But the other card is ... idle.

Is it possible to use my other monitors in X on OpenBSD?  Any Broad
General Tips in doing so?  Man pages to read?  Authoritative tips,
including "Don't be an idiot, it's easy" to "it's not possible"?

To save 45k per copy of this message, links to dmesg and xorg log:

 http://nickh.org/Xorg.0.log.txt
 http://nickh.org/dmesg.txt

Nick.



Re: HIPPA supported ciphers

2019-06-21 Thread Nick Holland
On 6/21/19 12:43 AM, Kihaguru Gathura wrote:
> OpenBSD 6.5 (GENERIC.MP) #84: Wed Apr 17 05:53:43 MDT 2019
> 
> Hi,
> 
> SSL compliance tests below refers. (htbridge)
> 
> 
> 2:SUPPORTED CIPHERS
> TLSv1.2
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 Non-compliant with HIPAA guidance
> TLS_RSA_WITH_CAMELL TLS_RSA_WITH_CAMELLIA_128_CBC_SHA Non-compliant
> with HIPAA guidance
> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA Non-compliant with HIPAA guidance
> 
> Under what circumstances could these ciphers be not considered for
> HIPPA compliance?

They could be things that aren't on the list that was compiled ten years
ago, they could be sub-optimal options that are still in widespread use
today.  You are asking the wrong people.  Talk to your compliance people
and/or auditors.

Do what they tell you to do, it's easier than reasoning with them.

Remember: Security is important for ethical reasons.  Compliance is
important for legal reasons.  The key to workplace contentment is
understanding they are unrelated to each other.  Both are important, but
one does not lead to the other.

And audits go better when the auditor finds something to complain about
and get you to change.

Nick.



Re: Filesystem corruption on OpenBSD routers after power outage?

2019-06-04 Thread Nick Holland
On 6/4/19 1:29 PM, Mogens Jensen wrote:
> I'm going to build a router for use in a remote location, and I have
> chosen OpenBSD 6.5 for the task. Unfortunately, it's not possible to
> protect the router with an UPS, so it will have to be resilient enough
> to survive sudden power outages and still boot without manual
> intervention.
> 
> In the past I have built a few Linux based routers and they were
> configured to run from RAM. I have made some research to see if this is
> also possible on OpenBSD and found that, while there are solutions to
> have / read-only, none of this is officially supported.
> 
> Can anyone with experience running OpenBSD routers without UPS, tell if
> filesystem corruption is going to be a problem after power outages, or
> if there are any officially supported ways to make the system resilient
> enough to not break after a power outage?
> 
> I'm using an mSATA disk with MLC flash in the router.

I realized a few decades ago that consumer UPSs are a bad investment.
Industrial UPSs are a dubious idea in business unless you have a
dual-power supply machine and can hook each PS to a DIFFERENT UPS -- in
my area, grid power is more reliable than cheap UPSes (your mileage may
vary).  And you have to MAINTAIN your UPSs, otherwise after a few years,
UPSs turn minor glitches into power outages (thank you very much).

I'm also fond of proving my own claims, so I very often just yank the
cord on my systems rather than doing orderly shutdowns.

Yes, if you drop power on an OpenBSD system, you will get an fsck on
reboot.  Solution: Make your partitions as small as reasonable.  Just
because you got a 500G disk for cheap, no reason to allocate all 500G.
For a router, 10G is PLENTY, and will fsck quickly.  If you have slow
media (i.e., flash drives), you might want to aim for 1G.  Every once in
a long while, you might catch a really bad time for the power to go out,
and have to manually say "Fix it!" to fsck, but for the most part, the
system will just come back up after the power comes back on.

The less you write to disk, the less risk you have of having to manually
intervene in your system's reboot.  IF you want to do some fancy
logging, keep the logging partition out of the fstab file, and have a
script that brings it up with a "fsck -y" AFTER the system comes up, and
start the fancy logging AFTER the big logging partition successfully mounts.

But don't do stupid games to try to improve your chances, just make sure
there's a monitor and keyboard available to fix any problems that might
happen.  Simple systems have simple problems.  Complex systems break in
complex ways.  You want me to swear you'll never have to manually
intervene in boot after an "event"?  Nope.  But I've walked
non-technical people through single-user fsck's over the phone; when
your bastardized system breaks, you will be down for a lot longer and
you will be going on-site to fix.

Nick.



Re: mounting an existing softraid/crypto partition for install/update

2019-06-03 Thread Nick Holland
On 6/3/19 8:17 PM, Bryan Stenson wrote:
> Hi all -
> 
> I'm running -CURRENT on a SSD with FDE encryption using softraid/crypto
> with a passphrase entered via the keyboard at boot.  It worked great.
> Then, I upgraded to a build that had a broken bootloader (reported to be
> fixed now: "Re: amd64 snapshot very broken (Jun 1 02:24:13)").  Per that
> thread, I'm trying to boot from temp boot media to update to the fixed
> image.

ouch. :(

> I've tried booting both snapshots/amd64/install65.fs and
> snapshots/amd64/miniroot65.fs, and while it appears the bootloader
> recognizes my softraid crypto device, it's clearly not mounting the crypto
> device (I'm not prompted for a passphrase), and by the time I get to the
> install script, it shows:
> 
> Available disks are: .
> Which disk is the root disk? ('?' for details)
> 
> Asking for details, both my SSD (sd0) and temp boot media (sd1) are shown,
> but I'm not able to see the encrypted device.
> 
> I've dropped to a shell, and created the device (it wasn't there) via "cd
> /dev && sh MAKEDEV sd0", and can see my RAID partition via "disklabel sd0".

You probably need to make sd1 and sd2, as well (sd1 your install media,
will probably be made for you, but as long as you are in the
neighborhood...  sd2 will hold the actual file systems on the encrypted
"disk" that you will be installing to.

> But, now I'm stuck/confused...I'm trying to figure it out by following:
> https://www.openbsd.org/faq/faq14.html#softraidFDE
> 
> Do I re-create the softraid/crypto with something like "bioctl -c C sd0a
> softraid0"?  Or, will this will wipe out the existing data and give me a
> fresh new partition to install to?

yep.
bioctl -c C -l /dev/sd0a softraid0

should do it.  I'm just peeking at a script I use to manually mount an
encrypted file system post-boot.

> How can I mount the existing crypto volume for use by the installer?
> (Also, am I asking the right questions here?)

Once you have "unlocked" the encryped partition and it becomes a new
logical drive, make note of that, and answer that drive to the installer
if it doesn't figure it out on its own.

Nick.



Re: Upgrade procedure (6.4 -> 6.5)

2019-05-07 Thread Nick Holland
On 5/7/19 8:32 AM, Dumitru Moldovan wrote:
> On Sun, May 05, 2019 at 05:05:11PM +0200, Ingo Schwarze wrote:
>>Hi,
>>
>>Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300:
>>
>>> Maybe it's a good idea to note this on the upgrade page? Something like
>>> "the upgrade procedure may leave some files behing; you can manually
>>> clean them up using sysclean package"?
>>
> 
> [...]
> 
>>
>>For example, it is definitely useful to remove stale Perl libraries.
>>It is also useful for stale header files if you compile software
>>from source.  It is useful (but not terribly important) for stale
>>manual pages.  It is usually detrimental for old versions of shared
>>libraries, unless you are *really* short on disk space (which is getting
>>less common nowadays) *and* you are very careful.
>>
>>For most use cases, we do not recommend using sysclean.
> 
> I think there's a less common scenario not covered in this thread.
> Suppose you have locally-compiled binaries, linked to previous versions
> of libraries, belonging to an older version of the OS.  Those libs will
> never get patched after you upgrade, so any vulnerabilities they expose
> will remain exploitable in the binaries linked to them.

Ok, I admire your confidence that the problem in your local binaries
are the OpenBSD libraries. :D

This swings both ways.  When doing an upgrade, if the upgrade deleted
all those libraries BEFORE you had a chance to upgrade that binary, it
would quit working.  While I'm all for "Fail Closed", it might be
premature to call it a failure.  Or not.

It is very hard to please all, and even harder to cover all possible
situations.

Nick.



Re: Upgrade procedure (6.4 -> 6.5)

2019-05-03 Thread Nick Holland
On 5/3/19 2:32 PM, Strahil Nikolov wrote:
> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
>  wrote:
>> On 5/2/19 1:52 AM, Consus wrote:
>>> Hi,
>>> 
>>> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I
>>> see that /etc/networks and some other files (like malloc.conf.5)
>>> are
>> still
>>> present, although there is no use for them in the new release.
>>> 
>>> Is there a reason why these files are not listed in "FIles to
>> remove"?
>>> Is there a way to track them? It's not like something gonna
>>> break,
>> but
>>> old configuration files (and manual pages) lying around can make 
>>> someone's life harder during the debug session.
>> 
>> There is no promise that an upgraded machine will be file-for-file 
>> identical to a fresh install.  Here is the list of problems this
>> might cause you, as you can see, it's a long list and quite
>> horrible:
>> 
>> * If you use the same hw for 20 years, you might run out of disk
>> space?
>> 
>> Ok, not very long and not very horrible.
>> 
>> You are trying to solve a non-problem.  And sometimes, 'specially
>> on an upgraded machine, it's great to see how things WERE when the
>> machine was set up.  If you really care, go ahead, delete stuff.
>> 
>> Nick.
> 
> Hi All,
> 
> As I linux guy (my experience in openBSD can be easily measured in
> days) I can share the view  of less experienced user that was planing
> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
> 
> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
> 6.5  and thus it seemed that booting from the 6.5 DVD will do the
> trick. Sadly the installer never checked the avalable space , but
> just started to do it's stuff until reporting that not enough space
> is available.

The installer didn't check. Neither did you.  Let's blame the installer.

Ok, sure, might be nice, but when there are a snootload of different
platforms with radically different size binaries, it's not trivial.  But
feel free to send in a patch.  Test on two or three different platforms,
first, though, please.

And ... considering the number of times I've seen and heard about Linux
systems hose themselves with upgrades, I question your implication.
Major Linux upgrade?  Most people I know just say "Screw it.  Rebuild,
reload".  Linux might have the edge on incremental upgrades, but
eventually, you are going to need to move to the more current
release...and then OpenBSD starts looking REALLY GOOD.

10g disk?  When I first started working with OpenBSD, that was really
big.  But then, I had to manually partition the disk.  20 years later,
10G is tiny.  The installer auto-partioner is really intended for bigger
disks.   Yeah, you are in "Special Case" territory, which isn't a good
spot to be as a new user.

> Why did the installer allow installation despite the available space
> is low ( even windows checks available space :) )???

The average windows user doesn't know what the units of storage mean.

> Why should the end-user delete old unnecessary/problematic files ?

That's my question.  What's the big deal?  On a modern disk, just ignore
them.  They won't be a problem until long after your rotate out the hw.
 Problem is, you used a 2001 vintage size disk.  You should have rotated
that out around 2005.

And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G
disk.  I have my suspicions, and I suspect it would be entertaining to
watch...assuming it wasn't something you were dependent upon.

> Usually we do have package management system to take care of that (or
> at least to rename those files in case we really need them).

Yeah, you need to wait until Linux "package management" screws itself
into a knot for you.

> For me, system upgrade is a very complicated  and  error prone
> procedure.

OpenBSD has what I call a "Learning Curb".  You gotta lift your feet.
Not a lot, it's not hard, but you can't just shuffle along mindlessly
and expect to be carried to the next level without your engaging your brain

If you used Linux for a little bit and figured that OpenBSD is "just
like Linux, but different", yeah, no, you are going to be disappointed.
 Different beast.  From a management perspective, I'd say Linux and
Windows are much more alike than Linux and OpenBSD.  Linux is written
for and by those frustrated with Windows ("Reinventing Windows,
poorly").  OpenBSD is Unix.  It's probably the simplest Unix out there
to use and manage, but it's not Windows (or Linux).

Or...  Think of Linux (and windows) as the big cushy luxury car.  Easy
to drive, assuming you work within the anticipated parameters, but you
really have no id

Re: User who invoke doas

2019-05-02 Thread Nick Holland
On 5/2/19 8:04 AM, Ted Unangst wrote:
> Nick Holland wrote:
>> > In a shell script invoked by doas, is it possible to find which user
>> > invoke the script? my search a the moment has come up empty.
>> 
>> most likely place would be an environment variable, right?
> 
>> 
>> # echo "I started out as $LOGNAME"
>> I started out as nick
> 
> Note that LOGNAME and other variables can be set by the user to indicate a
> different user name.
> 
> $ env LOGNAME=somebody doas sh -c 'echo $LOGNAME'
> somebody

And that's important -- I (silently) assumed a semi-friendly
environment, not a good idea.  Evaluate my suggestion based on your
actual needs and risks.

But then, if the wrong person has sudo access on your box, this may not
be your biggest problem of the day.

Nick.



Re: User who invoke doas

2019-05-02 Thread Nick Holland
On 5/1/19 10:28 PM, Adam Steen wrote:
> Hi
> 
> In a shell script invoked by doas, is it possible to find which user
> invoke the script? my search a the moment has come up empty.

most likely place would be an environment variable, right?

So ...

$ whoami
nick

$ doas -s

# whoami
root

# env |grep nick
LOGNAME=nick
HOME=/home/nick
MAIL=/var/mail/nick

PATH=/home/nick/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
USER=nick

# echo "I started out as $LOGNAME"
I started out as nick

'dar ya go.

Nick.



Re: Upgrade procedure (6.4 -> 6.5)

2019-05-02 Thread Nick Holland
On 5/2/19 1:52 AM, Consus wrote:
> Hi,
> 
> I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see
> that /etc/networks and some other files (like malloc.conf.5) are still
> present, although there is no use for them in the new release.
> 
> Is there a reason why these files are not listed in "FIles to remove"?
> Is there a way to track them? It's not like something gonna break, but
> old configuration files (and manual pages) lying around can make
> someone's life harder during the debug session.

There is no promise that an upgraded machine will be file-for-file
identical to a fresh install.  Here is the list of problems this might
cause you, as you can see, it's a long list and quite horrible:

* If you use the same hw for 20 years, you might run out of disk space?

Ok, not very long and not very horrible.

You are trying to solve a non-problem.  And sometimes, 'specially on an
upgraded machine, it's great to see how things WERE when the machine was
set up.  If you really care, go ahead, delete stuff.

Nick.



Re: 6.5 auto_install fails due to custom /var/tmp?

2019-04-29 Thread Nick Holland
On 4/29/19 6:09 PM, Lyndon Nerenberg wrote:
> While trying to PXE install a 6.5 machine I was hit with this failure:
> 
>  Installing bsd  100% |**| 15163 KB00:00  
>   
>  Installing bsd.mp   100% |**| 15248 KB00:00  
>   
>  Installing bsd.rd   100% |**|  9984 KB00:00  
>   
>  Installing base65.tgz99% |* |   189 MB00:00 
> ETAtar: Unable to remove directory ./var/tmp: Device busy
>  Installing base65.tgz   100% |**|   190 MB00:14  
>   
>  Installation of base65.tgz failed. Continue anyway? [no] no
> 
> which I suspect is related to this:
> 
>  /   1G
>  swap4G-16G 10%
>  /tmp2G
>  /usr4G
>  /usr/local  2-6G 10%
>  /var10-20G 20%
>  /var/tmp10-20G 15%
>  /var/log20-40G 30%
>  /u  1G-*

yeah.

> I've never run into this until today, when I tried to carve out an explicit
> /var/tmp.  Autopartitioning be able to handle /var/tmp, no?

normally, /var/tmp is a symlink to /tmp.
It can't make the link.  No surprise.
Answer "Yes" to the "Continue anyway?" prompt, and all will be fine, I
believe.

Nick.



Re: chromium OpenBSD defaults

2019-04-18 Thread Nick Holland
On 4/17/19 4:01 PM, Tom Smyth wrote:
> Hello,
> 
> I was wondering what people would think of disabling chromium offering
> to save passwords for sites... it is a default in browsers in other operating
> systems that gives me a rash...  it is also a likely attack surface...
> I would rather have it disabled and if people need / want it they can
> enable it ?

Personally, no, I don't like that at all.

A couple reasons pop into mind quickly:

1) It doesn't save passwords without asking your permission.  So Just
Answer No.  And unless you disable it completely and irreversibly,
people can just turn it back on.
2) It's useful for sites that insist on passwords for idiotic reasons --
i.e., patches and documentation downloads.  Makes it much easier to use
one-site passwords, and if someone pops my machine, the last thing in
the world I care about is someone can read docs on some piece of sh**
software.  I'm much more concerned /when their/ site gets popped, and
they thought "rot13" a good password hash, I had no reason to use a
common password on multiple sites.

You are trying for "sounds good, make it painful security", whereas this
feature is useful for real security reasons.  You can't fix stupid
behavior with technology.

Nick.



Re: How to overrule bioctl "chunk already in use"

2019-03-28 Thread Nick Holland
On 3/28/19 10:29 AM, Rachel Roch wrote:
> Hi,
> 
> I've been following the instructions here
> https://www.openbsd.org/faq/faq14.html
>  to setup softraid.
> 
> Unfortunately I somehow messed up the original attempt through my own
> stupidity.

it happens.
And best that it happen before production than after.

> So I've been trying to go through the steps again.  However nothing
> I do can elminate the "softraid0 sd0a chunk already in use" message
> at the "bioctl -c 1 -l sd0a,sd1a softraid0" step.
> 
> I've tried everything !  Rebooting the server, /dev/zero to the
> first 500MB of sd0 and sd1, changing uuid in disklabel, erasing and
> re-writing disk label.
> 
> I looked at the man page and thought "ah ha !" ... maybe "-C force",
> but nope !

you were close with the zeroing the head of the components.  In fact,
I'm not sure what you did wrong, but that's the solution.

I'd suggest starting by zeroing the beginning of each physical disk --
using the r device and the c partition -- i.e.,

   # dd if=/dev/zero of=/dev/rsd0c
   # dd if=/dev/zero of=/dev/rsd1c

I've had enough problems, I really suggest this unless you are
absolutely sure your disk has never even heard of OpenBSD before you
install it. :)  (I think I had figured out at one point that zeroing the
RAID partitions was sufficient, but when it comes to zeroing, a little
more is never too much. :)

Now, if you were going to script this, you would put a block size and a
count in there...but since you are just typing this at the command line,
count to three and hit CTRL-C then do the next.  You really only have to
clear a megabyte or so, and probably a LOT less...you can't hit CTRL-C
fast enough, I suspect. :)

By using the 'r' device and the 'c' partion, you have wiped the very
very start of the disk -- sector zero onward.

I'd reboot after that.  I don't think it's needed, but either the
disklabel or MBR partition can be held in memory and written back out to
disk under some circumstance, I don't recall exactly what (probably
having to do with mounted partitions), so a reboot, and then verifying
that fdisk sd0 shows lots of zeros everywhere including the Signature.
NOW fdisk, create your OpenBSD partition, then your RAID disklabel
partitions, and you should be in business.

If that doesn't do it, show us your exact commands and exact output you
are seeing.

Nick.



Re: using an USB stick with "openbsd" type partition/slices

2019-03-21 Thread Nick Holland
On 3/21/19 6:49 AM, Mihai Popescu wrote:
> Hello,
> 
> I want to move my usb stick from msdos partition to more specific to
> OpenBSD. I use this stick to keep some configuration files and
> documents on it.
> 
> sd1 at scsibus2 targ 1 lun 0:  SCSI4
> 0/direct fixed serial.07815571010812120514
> sd1: 30532MB, 512 bytes/sector, 62530624 sectors
> 
> Steps I've done to achieve this:
> 
> # fdisk -e sd1
>> reinit
...
> # disklabel -E sd1
> Label editor (enter '?' for help at any prompt)
...[create an a partition, proper starting offset, etc.]


> # newfs sd1a
...

> 
> For mount I use mount /dev/sd1a /mnt. (no options yet!)
> 
> I want to ask if there are some suggestions in creating
> partition(s)/slice(s), types and mount options, please. I don't need
> softupdates. Files used are small and I copy a few at the time.

Well...if you are just moving files around, I wouldn't worry much about
partitioning.  If you want to actually make it bootable, that's a
different discussion.

Only exception I can think of -- if you want to split it between OpenBSD
and Windows use, fdisk to make a DOS partition (first) and an OpenBSD
fdisk partition (physically after the DOS/FAT partition), disklabel it
and format it on Windows, then format it on OpenBSD.

Few small files a few at a time?  Just use the defaults.

If performance matters, mounting with "noatime" and "softdep" are HUGE
wins.  If you aren't waiting, though, you won't get any benefit, so just
use the defaults.

Nick.



Re: Support for Nvidia chipsets, never running X

2019-03-07 Thread Nick Holland
On 3/7/19 7:19 AM, Chris Bennett wrote:
> I've avoided anything with Nvidia like the plague.
> But it just occurred to me to ask, ignoring X completely and never
> running it, are the rest of the Nvidia parts supported or is Nvidia
> anything a total no-go?
> 
> Thanks,
> Chris Bennett
> 
> 

it..varies.
A few couple years ago, I retired an nvidia chipped system I used as a
firewall for a few years.  Disk I/O was slow, USB support seemed slow (I
was booting from a USB flash drive).  NICs were some em(4) and dc(4)
add-in cards.  However, it pumped packets around just fine, but the rest
of the machine was "eh".

So...  If you end up with an nvidia powered machine in your pile, give
it a try and see how it works for *your application*.  If you are
buying, no, I'd just avoid it, the alternatives work better.

Nick.



Re: cvsweb.openbsd.org - same as cvsweb in ports?

2019-02-21 Thread Nick Holland
On 2/21/19 5:52 PM, Nam Nguyen wrote:
> Adam Thompson  writes:
> 
>> What version of cvsweb does cvsweb.openbsd.org run?  And where is that
>> software available?  It appears to not quite be the same as cvsweb in
>> ports, so... ?
> 
> It looks the same to me, other than some customized CSS.
> 
> You can see the log here: 
> https://cvsweb.openbsd.org/ports/devel/cvsweb/Makefile
> 

customized CSS?  You have more faith in my skills than you should. :)

It's the stock ports, with a few knobs twisted in the config file.

Nick.



Re: ssd drive disappears when booting

2019-02-18 Thread Nick Holland
On 2/17/19 2:57 AM, Jason McIntyre wrote:
> On Sun, Feb 17, 2019 at 01:23:44AM +, tfrohw...@fastmail.com wrote:
...
>> This sounds like the problem that I (and others) have seen when the hard 
>> drive is set to RAID in the Bios/firmware. Try setting it to AHCI if your 
>> bios lets you.
>> 
> 
> wow, that was exactly it! i don;t understand how it was running one
> minute, and then changed, but setting the drive to ahci worked (it was
> indeed parked on raid).
> 
> thanks so much - you just saved me a ton of hassle.
> 
> jmc
> 
> OpenBSD 6.4-current (GENERIC.MP) #713: Wed Feb 13 22:35:28 MST 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
...
> bios0: vendor Dell Inc. version "A15" date 08/15/2012

Your CMOS battery is dying.
I've got a Dell a bit newer than yours with the same problem -- under
circumstances I haven't quite figured out, the CMOS resets to default,
which, oddly, is RAID.

Nick.



Re: dell universal d6000 dock

2019-02-12 Thread Nick Holland
On 2/12/19 3:19 AM, ¯\_(ツ)_/¯ ¯\_(ツ)_/¯ wrote:
> try running stable.
> 

Stunningly bad advice for a hardware problem.

There's literally nothing in -stable that isn't in -current, and when it
comes to hardware support, a most recent snapshot is always the best.

Nick.



Re: CPU platform

2019-02-10 Thread Nick Holland
On 2/10/19 8:41 AM, Mihai Popescu wrote:
> Hello all,
> 
> I usually take my computers for OpenBSD from used/refurbished market
> since they are much cheaper and I don't need edge hardware. Lately,
> AMD processors platforms are not so easy to find ( I prefer a
> combination of cpu + video + brand name).
> I have a much bigger offer from Intel side. There are many options.
> Regarding the Meltdown and Spectre issues, is it still fine to go for
> an Intel platform?
> How did you folks with Intel based production systems mitigated this?

Most likely, you are going to start by panicking about Meltdown and
Spectre.  Then you are going to go load up your system with poorly
written software which is far more likely to be the REAL cause of a breach.

OpenBSD Developers are on the problems as well or better than anyone
else.  At this point, worry much more about the decisions you make OTHER
than HW platform, as they matter far more.

Nick.



Re: vultr

2019-01-07 Thread Nick Holland
On 1/5/19 5:22 PM, ed...@pettijohn-web.com wrote:
> I was thinking about spinning up a new instance on vultr to play with.
> They have an option to install OBSD 6.3/4. Has anyone tried these? I 
> attempted the FBSD one in the past, but the default install was all
> whacked out and I had to start over with a fresh install.

as others have said, they support OpenBSD, that's enough.  Don't expect
perfection on their install, it sucks actually.  But their SW supports
OpenBSD.

Use their install ONLY to put your own bsd.rd in root (everyone seems to
obsess over loading an ISO.  Who cares?  Just use a -current bsd.rd!),
boot off that, reinstall exactly as you want it.  The Vultr console
works great on OpenBSD chrome and firefox browsers.  Use DHCP for
network.  Done.

If you have ever used VMWare's craptastic management clients, you will
be amazed how well Vultr works.

Nick.



Re: Advice on Security Cameras

2019-01-01 Thread Nick Holland
On 1/1/19 12:46 PM, Elias M. Mariani wrote:
> Hi list,
> I'm thinking in installing some cameras in my private home, I have
> been looking for solutions, my concern is that I wish to be able to
> look the videos from outside the house and I'm a little paranoid about
> the quality of the software that the different vendors use.

you've seen any sign of quality in those things? :)

> I have
> seen clusters of camaras that only work over ActiveX...
> I know that is a little off-topic but maybe someone knows about a good
> brand of cameras.
> Of-course one can always set a VPN tunnel trough OpenBSD for the
> security matter, OpenVPN works on Android so is easy to access from a
> smartphone. But I would prefer to have a single secure service running
> that adding a layer of complexity with the VPN.
>
> I'm looking for:
> - Not overpriced cameras.
> - They don't need to be "external cameras", they will be covered under a roof.
> - I need to set at least 4, so I need them to be accessible from a
> single platform.
> - Android / Browser friendly (not only IE plz...)
> - WiFi is not needed, I have a 12v supply and Ethernet connections for
> each camera.
> - Good video quality but I'm not looking for anything super great...
> - the ability to centralize recording and access to view the cameras is a 
> must.

Bringing it back to OpenBSD,

... just use SSH and port forwarding and an otherwise off-the-shelf
solution.  No add-on SW needed.

Did this with a friend's business.  Little OpenBSD box in their office
as a gateway, the DVR on one port (don't trust the security of the damn
things, so keep it off the business network) and the owner can click on
a PuTTY icon on their Windows desktop (or android or ...) to establish
the SSH connection (key, no PW to enter, yes I set this up for them,
took just a few minutes in their house), and a second click to bring up
the bookmarked browser-based app the thing used.  Neat thing is you
don't have to change the default PWs on the DVR now, so that's one less
thing to worry about.  Very non-computer-person user friendly -- "Click
here to connect to your office, then connect here to view the cameras".

Yes, I'd suggest an OpenBSD gateway to a commercial DVR security system
rather than rolling your own, if it is really to be a security system
(as opposed to maybe a, "who's at my front door?" or "what are the local
wildlife doing when I'm asleep?" cameras).  The police may need to
extract the video from it without your assistance if you are unavailable
(or worse) as part of whatever they are investigating and maintain a
chain of custody; this won't happen if you roll your own.  I'll admit I
hadn't thought of that until a police officer friend of mine started
telling me about the training he was taking on exactly this topic --
*they* need to be able to get the video out of the device in a timely
manner, and they have to explain to the judge and jury how it was done.

Nick.



Re: ahci error during install of 6.4

2018-12-29 Thread Nick Holland
On 12/28/18 5:37 PM, Juan Francisco Cantero Hurtado wrote:
> On Fri, Dec 28, 2018 at 08:18:38AM +, Paul Swanson wrote:
>> Hi,
>> 
>> I'm currently trying to install 6.4 on a Dell Latitude E7470 laptop (Intel 
>> Skylake).
>> 
>> During the whole disk (G) partitioning process, setup fails with the 
>> following messages:
>> 
>> newfs: wtfs: write error on block 8352576: Input / output error
>> ahci0: attempting to idle devices
>> atascsi_disk_sync_done: error
>> ahci0: NCQ errored slot 14 is idle (2000 active)
>> 
>> Assuming that perhaps there might be a bad block on the drive (nvme ssd) 
>> I've run read / write bad block tests on the whole drive, but nothing showed.
>> 
>> The drive has had a working install of Ubuntu up till now, and I've 
>> subsequently installed Xubuntu on it successfully.
>> 
>> As it stands I can't proceed with the install; very sad.
>> 
>> Any help would be appreciated.
> 
> Install OpenBSD on a usb stick, run OpenBSD from there and use dd to
> write zeroes to the disk. If the disk has bad blocks you will see
> similar errors in the dmesg. You can do the same with linux.
> 
> Sometimes bad units pass the checks of badblocks programs because these
> run read-only tests by default and the flash controller lies. You only
> see the bad sectors when you try to write to the disk.

Actually...you won't see most SSD style write errors --they will be
silently remapped.

After writing zeros with dd, do it again with 0xff (377 octal) --

tr '\0' '\377' < /dev/zero | dd bs=1m if=- of=/dev/rsdXc

That will run a lot slower than the zeros, but now you have tested every
bit of the disk for one and zero storage and remapped them.

Did this recently with some annoying SSDs that have been bugging me for
years, and the results have been ... promising (NO problems since).

Nick.



Re: Best way to change disk layout?

2018-12-24 Thread Nick Holland
On 12/23/18 3:16 PM, John Long wrote:
> I'm running release instead of stable like I did years ago. Syspatch is
> a better solution for me than building from source. I want to change my
> disk layout because when I set up this box I was thinking of building
> from source like the old days. I want to eliminate some filesystems and
> move /var and resize it. I can't growfs where /var is right now, the
> filesystems I want to get rid of precede it.
> 
> Is it better to do this kind of thing single-user (is it even possible
> to run without /var) or is it better to boot the installer disk and do
> it from a shell without anything mounted?

It depends.
If you have to ask the question, the answer is probably you shouldn't.

You don't want to run with a /var directory.  You can't easily populate
a /var directory from a mounted /var.  You can't umount /var and have a
happy day (guess how I know).

IF you have a drive with some free space, there are lots of options,
including making or recycling partitions and shuffling things around
until you get what you want.  For example, you could maybe copy /var to
/tmp, change fstab so your old /tmp is /var on reboot, reboot, then you
can do what you want with the old /var.  When done, copy the data from
your tmp var to the goal var, and change fstab again, reboot, ta-da.
(note: you want to make sure only you are on the box and no exposed
services are running when you do things that hose the OpenBSD security
models!)

You can't use growfs on a live file system, but if you plan/work things
out right, there's a lot you can often do without even having a remote
console.

This is again why I argue, just because you got a 500g drive on your
firewall doesn't mean you need to allocate all of it.  Give me 20g spare
space and there isn't much I couldn't shuffle on a system, even remotely
(I can't move /.  I can't necessarily save data without someplace else
to put it).

Nick.



Re: SSH server immediately closes connection

2018-12-14 Thread Nick Holland
On 12/14/18 00:27, Максим wrote:
> Hello,
> I've got a PC running OpenBSD current.
> After the latest upgrade I cannot ssh to it.
>
> When I run "ssh 10.26.5.70"
> I get this:
> "Connection to 10.26.5.70 closed by remote host.
>  Connection to 10.26.5.70 closed."
> As an SSH client I use another OpenBSD box and a Linux machine
> with the same result.
> When I run "ssh -vvv 10.26.5.70"
> the last messages are:
> 
> "debug3: receive packet: type 52
> debug1: Authentication succeeded (publickey).
> Authenticated to 10.26.5.70 ([10.26.5.70]:22).
> debug1: channel 0: new [client-session]
> debug3: ssh_session2_open: channel_new: 0
> debug2: channel 0: send open
> debug3: send packet: type 90
> debug1: Requesting no-more-sessi...@openssh.com
> debug3: send packet: type 80
> debug1: Entering interactive session.
> debug1: pledge: network
> debug3: send packet: type 1
> debug1: channel 0: free: client-session, nchannels 1
> debug3: channel 0: status: The following connections are open:
>   #0 client-session (t3 nr0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1)
> 
> debug3: fd 1 is not O_NONBLOCK
> Connection to 10.26.5.70 closed by remote host.
> Connection to 10.26.5.70 closed.
> Transferred: sent 2644, received 1932 bytes, in 0.0 seconds
> Bytes per second: sent 1085498.2, received 793185.5
> debug1: Exit status -1"
> 
> 
> No errors in /var/log/daemon
> No errors in /var/log/authlog
> 
> The result doesn't depend on the user which I use to login.

I just happened to have upgraded a system last night to the most recent
snapshot, I am NOT having any such problem.
OpenBSD 6.4-current (GENERIC.MP) #510: Thu Dec 13 06:20:42 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

So ... Doesn't appear to be a systemic problem, most likely either a
knob you twisted before the upgrade or something about your upgrade process.

You need to provide more details about what you did...both before and
during the upgrade...and some indication of what platform you are
running and the snapshot you upgraded to.

Nick.



Re: Core Dev?

2018-12-04 Thread Nick Holland
On 12/04/18 01:47, Ahmad Bilal wrote:
...
> Does anyone has any suggestions for me? 

Yes.  Read your request carefully to yourself...

> I want OpenBSD due to reliability and security issues.

Good plan.

> AWS is the leader in hosting market.

but ... not security.
By that reasoning, we should all be using Windows XP.

> It is only natural to expect at least a FAQ or HOW-TO from openbsd
> team on this topic.

Sometimes "don't", or "if you do, you get to keep all the pieces" is a
good answer.  Sometimes "no comment" is even better.

Hey, I run OpenBSD on a chunk of rented HW myself, but I don't pretend
it is as secure as a real box in my environment that I control.  But I
picked my hosting provider based on ease and support of getting OpenBSD
working, not "leadership".

"cloud" hosting is a bit like living in a building with randomly
assigned people and sharing a bathroom.  You may end up learning things
about others you may not want to know.

Nick.



Re: Boot reboot issue after upgrade to 6.4 on amd64

2018-11-27 Thread Nick Holland
On 11/27/18 05:48, Riccardo Mottola wrote:
> Hi all,
> 
> I have a strange and blocking issue after upgrade to 6.4 on my x86-64 
> laptop, which was running 6.3 just fine.
> 
> I got the bsd.rd kernel, booted it and installed, quick, easy no issue.
> Now, if I reboot, the kernel will reboot just after having written the 
> first line of numbers on the screen.

So far, with one or two exceptions, everyone complaining about this has
a One Big Partition disk layout.  A bad idea, not suggested, and I don't
think you will get much sympathy.

I know of one machine that behaves as you describe with a very modest
(smaller than suggested) root partition, but I'm feeling very alone
here. :D

Nick.



Re: With all this CPU/hardware mess, any advice on what to use for an organization?

2018-11-20 Thread Nick Holland
On 11/20/18 11:43, Chris Bennett wrote:
> I am almost certainly going to be replacing with a new server for an
> organization I am a member of.
> With all of this mess with Meltdown, Spectre, insecure motherboard
> chips,etc.
> I am pretty clueless on exactly what is going to be a secure set of
> server hardware.
> Intel, well no.
> AMD? I have read about problems with non-CPU chips being compromised.
> Another architecture? I have never used anything other than Intel/AMD.
> 
> The server will run httpd, mailserver, PostgreSQL and somehow a good way
> for well encrypted messaging at times.

all on one server?

And as someone who has run a number of mail servers for a number of
companies ... don't.  Just don't.  Running your own mail server is a
good way to accomplish nothing except wasting a lot of time and making
people hate you.

> It is very likely to run out of Austin, Texas.
> I think that having a direct connection would be best, but would a
> proper setup make collocation OK?

You are using poorly defined buzzwords.  What you mean by a "direct
connection", "proper setup", "collocation" and what I mean are likely
very different.

> This isn't going to be my server, I will just be in charge. That's
> completely new for me.
> Any advice is really welcome, everywhere I read anything, hardware seems
> broken and insecure.

Pretty much all new HW is optimized in ways that we are now learning
(and has been known for a long time) introduce security problems.
However, most of the problems boil down to having malicious software
running in the control of someone else on the same physical machine YOUR
code is running on.

In short: No news.  Really.

If someone that wanted to do you evil lived in the same house as you,
you would not be comfortable, right?  What if you put up walls
(virtualization) that have proven to to be about as robust as paper?
That make you feel any better?  Probably not.  Virtualization has been
proven -- over and over -- not terribly secure.  Now we got
cross-virtualization platforms ways of stealing data from other
processes.  Important? yes.  But in the big picture, it's similar to Yet
Another buffer overflow.

So...split your tasks on different physical systems as much as possible.
 If your webserver is serving static pages, it's probably pretty robust.
 If it's running Wordpress or any other "any idiot can manage the web
page" apps or dynamic web pages for other reasons, it should be a
machine of its own and have no other important data on it.
Your primary goal should be to keep the bad guys off your computer in
every sense.  And again...nothing new here.

But if security is your concern, you want real hw you control in every
sense.

Unfortunately, if you have performance requirements, your choices are
AMD and Intel.  Older Intel and AMD chips aren't getting any support to
deal with these problems, so your choices are incredibly old chips which
are probably not in the most reliable hardware, and a whole bunch of
other old, unreliable, and slow hardware platforms.  But be realistic.
Your bosses will probably mandate a VM on someone else's hw, a wordpress
website, one box for everything, and that you give him the root password
which he'll e-mail to himself to keep it "secure".  Your most likely
breach points will be an easily guessed password (usually, a manager's),
a bug in a web content management system, or someone believing that
"secure e-mail" is a thing.  In other words, Same Old Shit.  It probably
won't be breached by a Spectre or Meltdown-like attack.  But it MIGHT
be.  Obsessing about them is generally missing the real day-to-day risks.

Nick.



  1   2   3   4   5   6   7   8   9   10   >