how to setup multiboot with a shared /home?

[Jonathan Thornburg]

I'm trying to set up a disk so that it can multiboot either of two
distinct amd64 OpenBSD installations (I'll call them A and B).  Reading
the Fine FAQ suggests that a relatively straightforward way to do this
is to put the two OpenBSD installations inside distinct fdisk partitions,
and use the fdisk 'flag' command to select which fdisk partition
(and hence OpenBSD installation) is booted by default.  For example,
I could put OpenBSD installation A inside fdisk partition 0, and OpenBSD
installation B inside fdisk partition 1.

[Of course, to make this work I need to ensure that both root filesystems
are close enough to the start of the physical disk that I don't run into
BIOS disk addressing limits.]

My questions concern an extension of this setup: I'd like the two
installations to share a (large) common /home filesystem.  Because of BIOS
disk addressing limits, the large /home filesysgtem must be *after* both
the A and the B root filesystems on the physical disk.  This suggests a
disk layout like this:

OpenBSD A OSOpenBSD B OS
partitions  partitions   shared /home partition
 |---||--|
disk w x  y z   disk
startend

My question is, what sort of fdisk partition layout do I want here?

One possibility is to use overlapping fdisk partitions:
* fdisk partition 0 = sectors 64 to disk-end
* fdisk partition 1 = sectors x to disk-end (or maybe x+64 to disk-end)
Here the disklabel partitions inside fdisk partition 0 are set up
to contain the OpenBSD A OS filesystems and the shared /home, and
the disklabel partitions inside fdisk partition 1 are set up
to contain the OpenBSD B OS filesystems and the shared /home.

Another possibility is to use non-overlapping fdisk partitions,
and disklabel offsets which extend outside their fdisk "owners", as per
/usr/src/distrib/amd64/common/install.md:
> The offsets used in the disklabel are ABSOLUTE, i.e. relative to the
> start of the disk, NOT the start of the OpenBSD MBR partition.
That is,
* fdisk partition 0 = sectors 64 to w
* fdisk partition 1 = sectors x to y (or maybe x+64 to y)
* fdisk partition 2 = sectors z to disk-end (or maybe z+64 to disk-end)
Here the disklabel partitions inside fdisk partition 0 are set up
to contain the OpenBSD A OS filesystems and the shared /home, with
the latter having disklabel offsets pointing to fdisk partition 2.
Similarly, the disklabel partitions inside fdisk partition 1 are set up
to contain the OpenBSD B OS filesystems and the shared /home, with
the latter having disklabel offsets pointing to fdisk partition 2.

Clearly, both of these layouts require very careful setup of the disk
offsets -- if I miscalculate then all bets are off.  But, assuming that
I calculate correctly

Question: are there reasons why one or the other of these layouts is
preferable?  Or is there some other layout which would be better?

Question: are there any unobvious obstacles to making any/all of
the OpenBSD A OS partitions, the OpenBSD B OS partitions, and/or the
shared /home partition, softraid-crypto?

thanks,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" 

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

Re: is 'set prio' in pf unidirectional or bidirectional?

[lists]

Sat, 18 Jun 2016 11:29:50 + (UTC) Bohdan Tashchuk

> On Fri, 6/17/16, Marko Cupać  wrote:
>      
> > Perhaps it would be useful to add that 'set prio' does nothing
> > unless "hardware is slower at transmitting packets than the
> > thing that generates these packets to send", as stated here:
> >
> >  [http://marc.info/?l=openbsd-misc=145257356119612=2]
> >
> > ... thus making it inappropriate for solution of OP's problem.
>
> Hi,
>
> I'm the OP. I agree that a single VoIP session doesn't need
> 'set prio' in normal circumstances.
>
> The reason I want to implement it in my home network is
> because, occasionally, one of the kids will upload
> something big, e.g. a few hundred megabytes of pictures,
> to some social network.
>
> When that happens, my Internet "goes to shit" for the
> duration. The upload attempts to push 100 Mbit/sec
> or more to my firewall. Which then tries to push
> to the Internet over the 5 Mbit/sec uplink speed of my
> cable modem. Which immediately saturates. Which results
> in the usual problems, such as 2000 msec or longer ping
> times. Etc. Of course, TCP eventually backs off, but things
> remain quite unpleasant for the duration of the upload.

Actually, it's not exactly this what causes, but this is exactly what
happens as you describe it.  It is very disappointing to have to deal
with this while trying to get work done.  Please see Daniel Hartmeier
has a page with details what you can actually do to sort it out.  It
is frustrating that the CPE (cable, aDSL and various other typically
asymmetric broadband Client Premises Equipment) don't try an inch to
help you out with their default configurations.  Pretty useless, huh?

Prioritizing empty TCP ACKs with pf and ALTQ
[http://www.benzedrine.ch/ackpri.html]

I can't tell if this still applies and if the configuration snippets
will be exactly as is, the page is dated and pf got several reworks.

But you'll get the idea pretty well, and understand how to solve it.
I can attest this worked for me several times in the past very fine.

> I don't want VoIP to suffer under those circumstances. So
> if I can work around this with 'set prio' (and not need to
> get queues involved), then it's certainly worth trying to do it.
>
> I will, of course, do some tcpdump monitoring in the near
> future, and report back to the list as to how successful I
> was in solving my problem by simply using 'set prio'.

Re: is 'set prio' in pf unidirectional or bidirectional?

[lists]

Sat, 18 Jun 2016 17:54:04 +0200 Marko Cupać 
> I am not a developer, just a guy who tries to achieve similar goal as
> you.

You're doing a good job with the mailing list posts on progress reports.

You can still help by testing the program via configuration changes, and
real usage reports.  The mailing list feedback is therefore very welcome.
If somebody not part of the developers snaps at you, ignore them and ask
again rephrasing your report.  You could submit your findings as patches
to the docs to begin with the FAQ, and match that against the real world
usage edge cases, especially if not directly applicable to a manual page.

> I am writing you in private because I've been asking basically the same
> questions here on misc@ a few months ago, eg:
>
> [http://marc.info/?l=openbsd-misc=145219178028408=2]
>
> To cut the long story short, after almost 10 years of successfully using
> OpenBSD's PF for traffic shaping, I can't make it work anymore since
> ALTQ was thrown out and new queuing mechanism was introduced in 5.5.

This is a reminder that the queuing section of the packet filter FAQ is
now in the attic as it's not been updated, it is just not so useful now.

[http://cvsweb.openbsd.org/cgi-bin/cvsweb/www/faq/pf/queueing.html]

If someone wants to really help, I suggest this document is brought back
from the out-of-date state and polished to match reality.  Until the day,
just consult the manual page queuing section (or ultimately the sources):

[http://man.openbsd.org/pf.conf.5#QUEUEING]

To gain more insight into this, keep working on it just like Marko tries.

> All the resources about current state of queuing in PF, including FAQ,
> manpages, and latest edition of "Book of PF" claim that what you
> (and I) need to achieve is done with a few simple lines, as it was in
> ALTQ days. It is not true. I came to conclusion that queuing in PF is
> broken, but there is no one who will fix it.

Source plunge may be required to be able to tame the FAQ queuing section.

> If you manage to achieve your goal (throttling one kind of traffic to
> prioritize other kind of traffic), please let me know.

Here is a free verse from the UNIX main book of revelations: if one
program does not possess a special dynamic quality you seek from it,
you shall write a program to change dynamically that program config
file and properly signal that program to continue performing duties.

> Regards,
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/

Corrections to the Release Song Lyrics page

[Tae Wong]

The source page I provided here is http://www.openbsd.org/lyrics.html

In this page, I've found the following errors.
• In the "I'm still here" song credits, Jonathan Lewis is displayed as
Jonathan D. Lewis (middle initial?)
• In the "11 1010101" song credits, Duncan McDonald is spelled as
Duncan McDonnald. His last name should have only one n.
• In the OpenBSD 3.5 song lyrics, the word vis a vis should be
displayed as vis-a-vis (hyphenated).

I don't have a patch created so someone should create it and commit it.

Hi

[outro pessoa]

Have a blessed day.

Re: is 'set prio' in pf unidirectional or bidirectional?

[Marko Cupać]

On Sat, 18 Jun 2016 11:29:50 + (UTC)
Bohdan Tashchuk  wrote:

> On Fri, 6/17/16, Marko Cupać  wrote:
>      
> > Perhaps it would be useful to add that 'set prio' does nothing
> > unless "hardware is slower at transmitting packets than the
> > thing that generates these packets to send", as stated here:
> >
> >  [http://marc.info/?l=openbsd-misc=145257356119612=2]
> >
> > ... thus making it inappropriate for solution of OP's problem.
>
> Hi,
>
> I'm the OP. I agree that a single VoIP session doesn't need
> 'set prio' in normal circumstances.
>
> The reason I want to implement it in my home network is
> because, occasionally, one of the kids will upload
> something big, e.g. a few hundred megabytes of pictures,
> to some social network.
>
> When that happens, my Internet "goes to shit" for the
> duration. The upload attempts to push 100 Mbit/sec
> or more to my firewall. Which then tries to push
> to the Internet over the 5 Mbit/sec uplink speed of my
> cable modem. Which immediately saturates. Which results
> in the usual problems, such as 2000 msec or longer ping
> times. Etc. Of course, TCP eventually backs off, but things
> remain quite unpleasant for the duration of the upload.
>
> I don't want VoIP to suffer under those circumstances. So
> if I can work around this with 'set prio' (and not need to
> get queues involved), then it's certainly worth trying to do it.
>
> I will, of course, do some tcpdump monitoring in the near
> future, and report back to the list as to how successful I
> was in solving my problem by simply using 'set prio'.

I was trying to achieve the same goal the same way as you, as it came
to me as a common sense that packets with higher prio would be processed
first. However, I found out this is not how things work. Prio does not
respect bandwidth set on queue. It starts to discard packets with lower
prio value when interface's physical bandwidth is saturated, which - in
your and my case - means never.

Maybe you will have better luck with queues. Make sure you set max
bandwidth on parent queue. I prefer to set also min:

# QUEUES
queue ul on $if_extbandwidth 800K min 800K max 800K
   queue hi  parent ul bandwidth 100K
   queue std parent ul bandwidth 600K default
   queue low parent ul bandwidth 100K

This work on traffic leaving external interface - traffic in low queue
will get 800K, but once traffic in std queue kicks in, low will get
throttled to 100K.

I haven't managed to make it work as expected for traffic leaving
internal interface (eg. replies from the Internet to requests from
local network).

Regards,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: is 'set prio' in pf unidirectional or bidirectional?

[Marko Cupać]

Bohdan,

I am not a developer, just a guy who tries to achieve similar goal as
you.

I am writing you in private because I've been asking basically the same
questions here on misc@ a few months ago, eg:

[http://marc.info/?l=openbsd-misc=145219178028408=2]

To cut the long story short, after almost 10 years of successfully using
OpenBSD's PF for traffic shaping, I can't make it work anymore since
ALTQ was thrown out and new queuing mechanism was introduced in 5.5.

All the resources about current state of queuing in PF, including FAQ,
manpages, and latest edition of "Book of PF" claim that what you
(and I) need to achieve is done with a few simple lines, as it was in
ALTQ days. It is not true. I came to conclusion that queuing in PF is
broken, but there is no one who will fix it.

As I said, prio does not respect queue bandwidth set by admin, it
starts to discard packets with lowest prio only when physical interface
gets saturated. In world of 1Gb NICs this is almost never.

I managed to make queuing work with as expected with fixed bandwidth
queues only (meaning set target, min and max values) for all queues
(parents and children).

If you manage to achieve your goal (throttling one kind of traffic to
prioritize other kind of traffic), please let me know.

Regards,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: sshfs key exchange fails

[Darren Tucker]

On Sat, Jun 18, 2016 at 6:11 PM, Dennis Matthiesen
 wrote:
> Hi Darren,
>
> Thanks for the right syntax, sshd is now coming up but the initial problem
> persists. Same picture in the packet capture.

The packet capture didn't make it to the list, the attachment got stripped.

> Problem: OpenBSD SSH server isn't responding to the 'Diffie-Hellman Group
> Exchange Request' with 'Diffie-Hellman Group Exchange Group'. Server is
> sending a FIN ACK instead.

Try running the server in debug mode (eg "/usr/sbin/sshd -ddde -p 222"
to run it on port 222) and if the reason isn't obvious from the log
please post it to the list.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: is 'set prio' in pf unidirectional or bidirectional?

[Bohdan Tashchuk]

On Fri, 6/17/16, Marko Cupać  wrote:
     
> Perhaps it would be useful to add that 'set prio' does nothing
> unless "hardware is slower at transmitting packets than the
> thing that generates these packets to send", as stated here:
>
>  [http://marc.info/?l=openbsd-misc=145257356119612=2]
>
> ... thus making it inappropriate for solution of OP's problem.

Hi,

I'm the OP. I agree that a single VoIP session doesn't need
'set prio' in normal circumstances.

The reason I want to implement it in my home network is
because, occasionally, one of the kids will upload
something big, e.g. a few hundred megabytes of pictures,
to some social network.

When that happens, my Internet "goes to shit" for the
duration. The upload attempts to push 100 Mbit/sec
or more to my firewall. Which then tries to push
to the Internet over the 5 Mbit/sec uplink speed of my
cable modem. Which immediately saturates. Which results
in the usual problems, such as 2000 msec or longer ping
times. Etc. Of course, TCP eventually backs off, but things
remain quite unpleasant for the duration of the upload.

I don't want VoIP to suffer under those circumstances. So
if I can work around this with 'set prio' (and not need to
get queues involved), then it's certainly worth trying to do it.

I will, of course, do some tcpdump monitoring in the near
future, and report back to the list as to how successful I
was in solving my problem by simply using 'set prio'.

Re: sshfs key exchange fails

[Dennis Matthiesen]

Hi Darren, Thanks for the right syntax, sshd is now coming up but the
initial problem persists. Same picture in the packet capture. Problem:
OpenBSD SSH server isn't responding to the 'Diffie-Hellman Group Exchange
Request' with 'Diffie-Hellman Group Exchange Group'. Server is sending a
FIN ACK instead. I added the following line to sshd_config to allow weak
key exchange algorithms: KexAlgorithms
+diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1 Dennis
Sent: Saturday, June 18, 2016 at 3:19 AM
From: "Darren Tucker" 
To: "Dennis Matthiesen" 
Cc: "Todd C. Miller" , "OpenBSD Misc List"

Subject: Re: sshfs key exchange failsOn Sat, Jun 18, 2016 at 6:08 AM,
Dennis Matthiesen
 wrote:
> Thanks Todd, Did a fresh install. Added the following line to
sshd_config
> but then sshd won't come up: KexAlgorithms +diffie-hellman-group1-sha1,
> +diffie-hellman-group-exchange-sha1

The first "+" means "append this to the list of accepted algorithms".
The second "+" doesn't mean anything so sshd is trying to parse that
as an algorithm name and failing (this should be obvious from the log
message). Try:

KexAlgorithms
+diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.