From nomad at ee.washington.edu  Tue Sep  4 22:46:34 2018
From: nomad at ee.washington.edu (Lee Damon)
Date: Tue, 4 Sep 2018 15:46:34 -0700
Subject: [OmniOS-discuss] zfs receive - failed to create mountpoint
Message-ID: <ee6d52fe-4f81-dbcc-e036-9de20cfb4fa9@ee.washington.edu>

I'm doing a fairly standard zfs send | ssh host zfs receive. At least, I 
think it's fairly standard:

zfs send -R stor1/admin_homes at tobesent | ssh otherhost zfs receive -dv pool0

I believe permissions on the receiving host are correct:

---- Permissions on pool0 --------------------------------------------
Local+Descendent permissions:
 ? ? ? ? group other 
create,mount,mountpoint,nbmand,quota,receive,refquota,refreservation,reservation,setuid,sharenfs,sharesmb

Everything transfers fine but at the end I get a bunch of:

cannot mount '/pool0/admin_homes': failed to create mountpoint
cannot mount '/pool0/admin_homes/subdir1: failed to create mountpoint
cannot mount '/pool0/admin_homes/subdir2': failed to create mountpoint
...

errors.

However, I can "sudo zfs mount -a" and everything mounts fine.

I can work around this by using using -dvu instead of -dv (so I don't 
get the error) then manually mounting but I'm slightly annoyed I can't 
get this to work "right". I suspect I'm missing a permission but I'm 
swizzled if I can find it.

Any hints gratefully received.

nomad


From doug at will.to  Thu Sep  6 14:29:25 2018
From: doug at will.to (Doug Hughes)
Date: Thu, 6 Sep 2018 10:29:25 -0400
Subject: [OmniOS-discuss] zfs receive - failed to create mountpoint
In-Reply-To: <ee6d52fe-4f81-dbcc-e036-9de20cfb4fa9@ee.washington.edu>
References: <ee6d52fe-4f81-dbcc-e036-9de20cfb4fa9@ee.washington.edu>
Message-ID: <736e1bcd-1900-fd7d-ff8b-31b070221894@will.to>

I used to get this more often when I had hierarchical filesystems like this.

The problem was, (from memory here, so may be slightly off), that at 
some point a replication had behaved (through failure or some other 
means) not quite optimally and there was a spare directory created 
inside the upper level filesystem where a lower level filesystem should 
be and that causes some issues.

check on the replication target in pool0 for admin_homes directory with 
or without subdirectories and clean them up. After that, the replication 
should start behaving normally again.

Side note, I use mbuffer to do my replication transfers to avoid the 
overhead (both login and encryption) of ssh. Works well. You can also 
use one of the nice tools out there like znapzend from one of our OmniOS 
release maintainers.? (others are available too - they make the job of 
managing the number of snapshots retained on primary and secondary and 
maintenance/cleanup during errors much more automatic)



On 9/4/2018 6:46 PM, Lee Damon wrote:
> I'm doing a fairly standard zfs send | ssh host zfs receive. At least, 
> I think it's fairly standard:
>
> zfs send -R stor1/admin_homes at tobesent | ssh otherhost zfs receive -dv 
> pool0
>
> I believe permissions on the receiving host are correct:
>
> ---- Permissions on pool0 --------------------------------------------
> Local+Descendent permissions:
> ? ? ? ? group other 
> create,mount,mountpoint,nbmand,quota,receive,refquota,refreservation,reservation,setuid,sharenfs,sharesmb
>
> Everything transfers fine but at the end I get a bunch of:
>
> cannot mount '/pool0/admin_homes': failed to create mountpoint
> cannot mount '/pool0/admin_homes/subdir1: failed to create mountpoint
> cannot mount '/pool0/admin_homes/subdir2': failed to create mountpoint
> ...
>
> errors.
>
> However, I can "sudo zfs mount -a" and everything mounts fine.
>
> I can work around this by using using -dvu instead of -dv (so I don't 
> get the error) then manually mounting but I'm slightly annoyed I can't 
> get this to work "right". I suspect I'm missing a permission but I'm 
> swizzled if I can find it.
>
> Any hints gratefully received.
>
> nomad
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From pasztor at sagv5.gyakg.u-szeged.hu  Tue Sep 11 15:47:48 2018
From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=)
Date: Tue, 11 Sep 2018 17:47:48 +0200
Subject: [OmniOS-discuss] screnrc or terminfo/termcap definitions changed in
	151026
Message-ID: <20180911154748.GA21503@linux.gyakg.u-szeged.hu>

Hi!

Can someone tell me, what changed in screenrc or termcap between 151022 and
151026?
When I pressed the usual ^a d to detach from my screen session, on the '22
it clears the screen before screen command would exit while on the '26 it
leaves garbage on my terminal.
Terminal type: xterm (linux, mate-terminal)

I don't even have an idea where to check for differences? The terminfo db,
or in /etc/screenrc?

If it helps, some comparation between '22 and '26:
[pasztor at nuc ~]$ diff -u <(ssh endor cat /etc/screenrc | grep -vE '^(#.*|)$' | sort ) <(ssh iroh cat /etc/screenrc | grep -vE '^(#.*|)$' | sort )
--- /dev/fd/63	2018-09-11 17:30:58.174232095 +0200
+++ /dev/fd/62	2018-09-11 17:30:58.177565428 +0200
@@ -1,36 +1,31 @@
 autodetach on
 bind ^\
-bind .
-bind \\
-bind h
-bind ^h
-bind '}' history
-bind 'I' login on
-bind k
+bind } history
+bind I login on
 bind ^k
-bind 'K' kill
-bind 'O' login off
-bind ^] paste [.]
+bind K kill
+bind O login off
+bind \\ quit
+deflogin on
 defscrollback 1000
-pow_detach_msg "Screen session of \$LOGNAME \$:cr:\$:nl:ended."
-register ] "\033:se ai\015a"
-register [ "\033:se noai\015a"
 startup_message off
-termcapinfo  hp700 'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$}:fs=\E[0}\E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@'
-termcapinfo linux C8
-termcapinfo wy75-42 xo:hs@
-termcapinfo wy* CS=\E[?1h:CE=\E[?1l:vi=\E[?25l:ve=\E[?25h:VR=\E[?5h:VN=\E[?5l:cb=\E[1K:CD=\E[1J
-termcapinfo xterm* be
-termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'
-termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~'
-termcapinfo xterm 'kh=\EOH:kI=\E[2~:kD=\E[3~:kH=\EOF:kP=\E[5~:kN=\E[6~'
-termcapinfo xterm* OL=100
-termcapinfo xterm 'vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l'
-termcapinfo xterm 'VR=\E[?5h:VN=\E[?5l'
-termcapinfo   xterm 'XC=K%,%\E(B,[\304,\\\\\326,]\334,{\344,|\366,}\374,~\337'
-termcapinfo  xterm Z0=\E[?3h:Z1=\E[?3l:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l
-termcap  vt100* ms:AL=\E[%dL:DL=\E[%dM:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC
-termcap  xterm hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
-terminfo vt100* ms:AL=\E[%p1%dL:DL=\E[%p1%dM:UP=\E[%p1%dA:DO=\E[%p1%dB:LE=\E[%p1%dD:RI=\E[%p1%dC
-terminfo xterm hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
+termcap  facit al=\E[L\E[K:AL@:dl@:DL@:cs=\E[%i%d;%dr:ic@
+termcap  facit|vt100|xterm LP:G0
+termcap  hp700 'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$}:fs=\E[0}\E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@'
+termcap  sun 'up=^K:AL=\E[%dL:DL=\E[%dM:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:IC=\E[%d@:WS=1000\E[8;%d;%dt'
+termcap  vt100 dl=5\E[M
+termcap wy75-42 nx:xo:Z0=\E[?3h\E[31h:Z1=\E[?3l\E[31h
+termcap  xterm|fptwist hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
+termcap xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'
+termcap xterm|xterms|xs ti=\E7\E[?47l
+terminfo facit al=\E[L\E[K:AL@:dl@:DL@:cs=\E[%i%p1%d;%p2%dr:ic@
+terminfo facit|vt100|xterm LP:G0
+terminfo hp700 'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$}:fs=\E[0}\E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@'
+terminfo sun 'up=^K:AL=\E[%p1%dL:DL=\E[%p1%dM:UP=\E[%p1%dA:DO=\E[%p1%dB:LE=\E[%p1%dD:RI=\E[%p1%dC:IC=\E[%p1%d@:WS=\E[8;%p1%d;%p2%dt$<1000>'
+terminfo vt100 dl=5\E[M
+terminfo wy75-42 nx:xo:Z0=\E[?3h\E[31h:Z1=\E[?3l\E[31h
+terminfo xterm|fptwist hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
+terminfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'
+terminfo xterm|xterms|xs ti=\E7\E[?47l
+vbell_msg "   Wuff  ----  Wuff!!  "
 vbell on


If it would not be clear: endor is the '22, and iroh is the '26.
I tried to add these to the end of my screenrc:
$ tail -15 /etc/screenrc
# ---
pow_detach_msg "Screen session of \$LOGNAME \$:cr:\$:nl:ended."
register ] "\033:se ai\015a"
register [ "\033:se noai\015a"
termcapinfo xterm* be
termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'
termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~'
termcapinfo xterm 'kh=\EOH:kI=\E[2~:kD=\E[3~:kH=\EOF:kP=\E[5~:kN=\E[6~'
termcapinfo xterm* OL=100
termcapinfo xterm 'vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l'
termcapinfo xterm 'VR=\E[?5h:VN=\E[?5l'
termcapinfo   xterm 'XC=K%,%\E(B,[\304,\\\\\326,]\334,{\344,|\366,}\374,~\337'
termcapinfo  xterm Z0=\E[?3h:Z1=\E[?3l:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l
termcap  xterm hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
terminfo xterm hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l

But this also not helped to solve the problem.

Any ideas?

Regards,
Gyu

From bfriesen at simple.dallas.tx.us  Tue Sep 11 16:17:43 2018
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Tue, 11 Sep 2018 11:17:43 -0500 (CDT)
Subject: [OmniOS-discuss] screnrc or terminfo/termcap definitions
 changed in 151026
In-Reply-To: <20180911154748.GA21503@linux.gyakg.u-szeged.hu>
References: <20180911154748.GA21503@linux.gyakg.u-szeged.hu>
Message-ID: <alpine.GSO.2.20.1809111114570.26069@scrappy.simplesystems.org>

On Tue, 11 Sep 2018, P?SZTOR Gy?rgy wrote:

> Can someone tell me, what changed in screenrc or termcap between 151022 and
> 151026?

I have seen strange issues with recent 151022 when editing a file 
using vim.  WYSIWYG definitely did not apply.  There does appear to be 
strangeness with terminal codes or even in vim/curses itself.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From omnios at citrus-it.net  Tue Sep 11 22:16:46 2018
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Tue, 11 Sep 2018 22:16:46 +0000 (UTC)
Subject: [OmniOS-discuss] screnrc or terminfo/termcap definitions
 changed in	151026
In-Reply-To: <20180911154748.GA21503@linux.gyakg.u-szeged.hu>
References: <20180911154748.GA21503@linux.gyakg.u-szeged.hu>
Message-ID: <nycvar.TFB.7.76.1809112212250.855@erncre.pvgehf-vg.arg>


On Tue, 11 Sep 2018, P?SZTOR Gy?rgy wrote:

; Hi!
;
; Can someone tell me, what changed in screenrc or termcap between 151022 and
; 151026?

According to the release notes at https://omniosce.org/releasenotes

o The /etc/screenrc file delivered by the screen package is now based on the
  recommended global template as delivered by the authors; you may wish to check
  that it still meets your needs. If you have previously customised this file
  then it will not be updated but the new template file will be installed as
  /etc/screenrc.new.

o screen is now linked against ncurses in order to support more terminal
  types (e.g. iterm)

Andy

-- 
Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From pasztor at sagv5.gyakg.u-szeged.hu  Wed Sep 12 21:05:42 2018
From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=)
Date: Wed, 12 Sep 2018 23:05:42 +0200
Subject: [OmniOS-discuss] screnrc or terminfo/termcap definitions
	changed in	151026
In-Reply-To: <nycvar.TFB.7.76.1809112212250.855@erncre.pvgehf-vg.arg>
References: <20180911154748.GA21503@linux.gyakg.u-szeged.hu>
	<nycvar.TFB.7.76.1809112212250.855@erncre.pvgehf-vg.arg>
Message-ID: <20180912210541.GA8535@linux.gyakg.u-szeged.hu>

Hi,

"Andy Fiddaman" <omnios at citrus-it.net> ?rta 2018-09-11 22:16-kor:
> 
> On Tue, 11 Sep 2018, P?SZTOR Gy?rgy wrote:
> ; Can someone tell me, what changed in screenrc or termcap between 151022 and
> ; 151026?
> 
> According to the release notes at https://omniosce.org/releasenotes
> 
> o The /etc/screenrc file delivered by the screen package is now based on the
>   recommended global template as delivered by the authors; you may wish to check
>   that it still meets your needs. If you have previously customised this file
>   then it will not be updated but the new template file will be installed as
>   /etc/screenrc.new.

Ok, maybe It was not obvious from my e-mail: I used screen with default
settings. No local change were made originally.

> o screen is now linked against ncurses in order to support more terminal
>   types (e.g. iterm)

This may explain why screen broke. At least the way it exits and cleans the
screen. It still jumps back to the right upper corner, just leave the
garbage on your terminal.

Regards,
Gyu

From nomad at ee.washington.edu  Mon Sep 17 16:16:58 2018
From: nomad at ee.washington.edu (Lee Damon)
Date: Mon, 17 Sep 2018 09:16:58 -0700
Subject: [OmniOS-discuss] slowness in aggr - bonded 10G
Message-ID: <CABXAO0+UVX3ZVu-1bzuZdcjyWcsLLZPj0YedimsMC=XDAD_rCw@mail.gmail.com>

I have four file servers all of which have at least two (some three)
aggregates made of two 10GB lines.  Three of the four servers are getting
pretty good throughput as reported by iperf:

(hvfs1 has iperf -s, other hosts iperf -c)
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.00  sec  8.04 GBytes  6.91 Gbits/sec                  sender
[  5]   0.00-10.00  sec  8.04 GBytes  6.91 Gbits/sec
receiver

but one, fs2, is getting roughly half that speed when it is running iperf
-c:

[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  3.81 GBytes  3.27 Gbits/sec                  sender
[  4]   0.00-10.00  sec  3.81 GBytes  3.27 Gbits/sec
receiver
(with occasional bumps to 4.05 Gb/s)

Even stranger, when I run iperf -c on fs2 and iperf -s on hvfs1 I get a
better (though still not as good) result bouncing between 4.6 Gb/s and 5.2
Gb/s.

It doesn't matter if I test via aggr0 or aggr_nas0, I get roughly the same
numbers. It also doesn't make any difference if aggr0 is dual-i40e or
dual-ixgbe devices.

Tests were done with hvfs1 acting as the iperf -s server via aggr_front0
(the equivalent to aggr0 on the other hosts) or aggr_nas0 as appropriate.
All hosts are directly connected to the same Juniper switch. (aggr info is
postpended at the end of this email.)

One theory I had was that fs2 wasn't actually using the full throughput of
the bond so I physically removed one of the two cables. Sure enough, the
bandwidth reported by iperf remained around 3.2Gb/s. I tested this with
both aggr0 and aggr_nas0 with the same result. There are times where it
gets closer to the 6Gb of the other hosts so it is clearly getting more
than just one link's worth but not often.

Unlike the other servers, fs2 is running 151026. The rest are all on
151022. I didn't see any references to aggr in the release notes for 151024
or 151026 but I'm not going to claim exhaustive search.

Aggregates were created with the device equivalent of

   dladm create-aggr -L active -l i40e0 -l i40e1 aggr0

My question is, what blatantly obvious thing did I miss in creating the
aggregates on fs2?

thanks,
nomad


aggr info:

fs1 (omnios-r151022-5e982daae6):
LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER
 FLAGS
aggr0           L4       auto                 passive       short
 -----  (not used for this test)
aggr_nas0       L4       auto                 active        short
 -----
aggr_front0     L4       auto                 active        short
 -----

LINK        CLASS     MTU    STATE    BRIDGE     OVER
e1000g1     phys      1500   up       --         --
e1000g0     phys      1500   up       --         --
aggr0       aggr      1500   up       --         e1000g0,e1000g1
ixgbe0      phys      1500   up       --         --
ixgbe1      phys      1500   up       --         --
aggr_nas0   aggr      1500   up       --         ixgbe0,ixgbe1
ixgbe2      phys      1500   up       --         --
ixgbe3      phys      1500   up       --         --
aggr_front0 aggr      1500   up       --         ixgbe2,ixgbe3


fs2 (omnios-r151026-51c7d6fd75):
LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER
 FLAGS
aggr_nas0       L4       auto                 active        short
 -----
aggr_net10      L4       auto                 active        short
 -----  (not used for this test)
aggr0           L4       auto                 active        short
 -----

LINK        CLASS     MTU    STATE    BRIDGE     OVER
i40e2       phys      1500   up       --         --
igb0        phys      1500   up       --         --
i40e0       phys      1500   up       --         --
i40e3       phys      1500   up       --         --
igb1        phys      1500   up       --         --
i40e1       phys      1500   up       --         --
ixgbe0      phys      1500   unknown  --         --
ixgbe1      phys      1500   unknown  --         --
aggr_nas0   aggr      1500   up       --         i40e2,i40e3
aggr_net10  aggr      1500   up       --         igb0,igb1
aggr0       aggr      1500   up       --         i40e0,i40e1


hvfs1 (omnios-r151022-5e982daae6):
LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER
 FLAGS
aggr0           L4       auto                 active        short
 -----  (not used for this test)
aggr_front0     L4       auto                 active        short
 -----
aggr_nas0       L4       auto                 active        short
 -----

LINK        CLASS     MTU    STATE    BRIDGE     OVER
ixgbe0      phys      1500   up       --         --
igb0        phys      1500   up       --         --
igb1        phys      1500   up       --         --
igb2        phys      1500   unknown  --         --
oce0        phys      1500   up       --         --
igb3        phys      1500   unknown  --         --
ixgbe1      phys      1500   up       --         --
oce1        phys      1500   up       --         --
aggr0       aggr      1500   up       --         igb0,igb1
aggr_front0 aggr      1500   up       --         ixgbe0,ixgbe1
aggr_nas0   aggr      1500   up       --         oce0,oce1


hvfs2 (omnios-r151022-89f6242508):
LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER
 FLAGS
aggr_nas0       L4       auto                 active        short
 -----
aggr0           L4       auto                 active        short
 -----

LINK        CLASS     MTU    STATE    BRIDGE     OVER
ixgbe2      phys      1500   up       --         --
ixgbe0      phys      1500   up       --         --
ixgbe3      phys      1500   up       --         --
ixgbe1      phys      1500   up       --         --
aggr_nas0   aggr      1500   up       --         ixgbe0,ixgbe1
aggr0       aggr      1500   up       --         ixgbe3,ixgbe2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180917/a03e8cef/attachment-0001.html>

From bfriesen at simple.dallas.tx.us  Mon Sep 17 16:37:18 2018
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Mon, 17 Sep 2018 11:37:18 -0500 (CDT)
Subject: [OmniOS-discuss] slowness in aggr - bonded 10G
In-Reply-To: <CABXAO0+UVX3ZVu-1bzuZdcjyWcsLLZPj0YedimsMC=XDAD_rCw@mail.gmail.com>
References: <CABXAO0+UVX3ZVu-1bzuZdcjyWcsLLZPj0YedimsMC=XDAD_rCw@mail.gmail.com>
Message-ID: <alpine.GSO.2.20.1809171125440.24642@scrappy.simplesystems.org>

On Mon, 17 Sep 2018, Lee Damon wrote:
>
> One theory I had was that fs2 wasn't actually using the full throughput of
> the bond so I physically removed one of the two cables. Sure enough, the
> bandwidth reported by iperf remained around 3.2Gb/s. I tested this with
> both aggr0 and aggr_nas0 with the same result. There are times where it
> gets closer to the 6Gb of the other hosts so it is clearly getting more
> than just one link's worth but not often.

Other than the bond group not forming properly, the most likely cause 
of only one link being used is that the involved hardware attempts to 
avoid out of order packet delivery, and achieve useful 
(connection/client) load sharing, by using a policy based on the MAC 
addresses on both ends, the IP addresses on both ends, or the 
properties of the TCP connection.

Your speed test is using one TCP connection between two hosts (similar 
to a client NFS mount) so the policy may result in all the data using 
just one link.

Take a close look at what POLICY/ADDRPOLICY are doing on the Juniper 
switch.  Perhaps the newer Illumos kernel has changed its defaults in 
this area.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From pasztor at sagv5.gyakg.u-szeged.hu  Sat Sep 22 14:47:03 2018
From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=)
Date: Sat, 22 Sep 2018 16:47:03 +0200
Subject: [OmniOS-discuss] dns howto
Message-ID: <20180922144703.GA30073@linux.gyakg.u-szeged.hu>

Hi,

Do someone have any best practice how to serve dns from omnios?
I'm migrating my home nas from my old N54L box to a custom built nas pc.
On the old box I have omnios 151014, where I served dns requests in my home
lan via an old zone migrated from the earlier openindiana 151a9 zone.
The 151a9 zone worked without any problem on the 151014 omnious without a
problem.
But I assume, some changes happened between 014 and 026 which broke binary
compatibility because neither my old 014 zone, neither my old 151a9 zone
was not able to start on the 026.
The 014 was not a big problem, even if there were no upgrade path.
I started with a clean zone, and moved there the other stuff (eg. nginx).
But the dns is kind a tricky. I checked how I served dns, and it seems
bind9 was part of the openindiana.org repo, while I was not able to find
any dns-related solution for current omnios releases.
I thought I'll do that with a debian9 lx zone.
Well, it's more or less work, but this error messages worries me in bind9's
log:
root at dns:/var/log/bind9# tail bind.log 
22-Sep-2018 14:39:31.166 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:31.167 general: error: setsockopt(520, IP_RECVTOS) failed: Protocol not available
22-Sep-2018 14:39:31.167 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:31.167 general: error: setsockopt(521, IP_RECVTOS) failed: Protocol not available
22-Sep-2018 14:39:44.555 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:44.555 general: error: setsockopt(520, IP_RECVTOS) failed: Protocol not available
22-Sep-2018 14:39:44.582 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:44.583 general: error: setsockopt(520, IP_RECVTOS) failed: Protocol not available
22-Sep-2018 14:39:44.711 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
22-Sep-2018 14:39:44.711 general: error: setsockopt(24, IP_RECVTOS) failed: Protocol not available

relevant logging config:
root at dns:/etc/bind# grep -A 7 logging named.conf.options 
logging {
        channel b_log {
                file "/var/log/bind9/bind.log" versions 30 size 1m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };


Does anyone have any idea how to solve this?
I already added the -4 option to /etc/default/bind9.
I found this conversation regarding the topic:
https://echelog.com/logs/browse/smartos/1477605600
This is from 2 years ago, and doesn't seem helpful by now, since bind
starts, just it dumps an insane amount of log about this protocol
unavailable. My eyes are bleeding, I barely see what protocol is missing
here. As I wrote, I tried the obvious: adding -4 to the options, and I see
that amongs the running process's arguments.

Thanks for every help!

Regards,
Gyu

From pasztor at sagv5.gyakg.u-szeged.hu  Sat Sep 22 14:52:03 2018
From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=)
Date: Sat, 22 Sep 2018 16:52:03 +0200
Subject: [OmniOS-discuss] screnrc or terminfo/termcap definitions
	changed in	151026
In-Reply-To: <nycvar.TFB.7.76.1809112212250.855@erncre.pvgehf-vg.arg>
References: <20180911154748.GA21503@linux.gyakg.u-szeged.hu>
	<nycvar.TFB.7.76.1809112212250.855@erncre.pvgehf-vg.arg>
Message-ID: <20180922145203.GB30073@linux.gyakg.u-szeged.hu>

Hi,

"Andy Fiddaman" <omnios at citrus-it.net> ?rta 2018-09-11 22:16-kor:
> According to the release notes at https://omniosce.org/releasenotes

Well, it's not a solution, but finally I "solved" the problem with a
workaround: I started to learn tmux instead.
It seams tmux works more flawless in 026.
I added some entry to my .tmux.conf to make my most often used keys
similar to the original screen behaviour:
unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix
bind ' ' next-window
bind n next-layout
bind BSpace previous-window

Cheers,
Gyu

From an3s.annema at gmail.com  Sun Sep 23 13:40:25 2018
From: an3s.annema at gmail.com (Andries Annema)
Date: Sun, 23 Sep 2018 15:40:25 +0200
Subject: [OmniOS-discuss] dns howto
In-Reply-To: <20180922144703.GA30073@linux.gyakg.u-szeged.hu>
References: <20180922144703.GA30073@linux.gyakg.u-szeged.hu>
Message-ID: <20ecf94e-684c-a1b3-72f8-f27f19f8ae3e@gmail.com>

Hi Gyu,

Maybe not a direct answer to your question, but might it be an option to 
use BIND from the 'pkgsrc' repository?
http://pkgsrc.joyent.com/install-on-illumos/

To me that repo seems quite future-proof for packages to be used in 
non-lx zones.

Regards,

Andries


On 2018-09-22 16:47, P?SZTOR Gy?rgy wrote:
> Hi,
>
> Do someone have any best practice how to serve dns from omnios?
> I'm migrating my home nas from my old N54L box to a custom built nas pc.
> On the old box I have omnios 151014, where I served dns requests in my home
> lan via an old zone migrated from the earlier openindiana 151a9 zone.
> The 151a9 zone worked without any problem on the 151014 omnious without a
> problem.
> But I assume, some changes happened between 014 and 026 which broke binary
> compatibility because neither my old 014 zone, neither my old 151a9 zone
> was not able to start on the 026.
> The 014 was not a big problem, even if there were no upgrade path.
> I started with a clean zone, and moved there the other stuff (eg. nginx).
> But the dns is kind a tricky. I checked how I served dns, and it seems
> bind9 was part of the openindiana.org repo, while I was not able to find
> any dns-related solution for current omnios releases.
> I thought I'll do that with a debian9 lx zone.
> Well, it's more or less work, but this error messages worries me in bind9's
> log:
> root at dns:/var/log/bind9# tail bind.log
> 22-Sep-2018 14:39:31.166 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
> 22-Sep-2018 14:39:31.167 general: error: setsockopt(520, IP_RECVTOS) failed: Protocol not available
> 22-Sep-2018 14:39:31.167 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
> 22-Sep-2018 14:39:31.167 general: error: setsockopt(521, IP_RECVTOS) failed: Protocol not available
> 22-Sep-2018 14:39:44.555 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
> 22-Sep-2018 14:39:44.555 general: error: setsockopt(520, IP_RECVTOS) failed: Protocol not available
> 22-Sep-2018 14:39:44.582 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
> 22-Sep-2018 14:39:44.583 general: error: setsockopt(520, IP_RECVTOS) failed: Protocol not available
> 22-Sep-2018 14:39:44.711 general: error: ../../../../lib/isc/unix/socket.c:2881: unexpected error:
> 22-Sep-2018 14:39:44.711 general: error: setsockopt(24, IP_RECVTOS) failed: Protocol not available
>
> relevant logging config:
> root at dns:/etc/bind# grep -A 7 logging named.conf.options
> logging {
>          channel b_log {
>                  file "/var/log/bind9/bind.log" versions 30 size 1m;
>                  print-time yes;
>                  print-category yes;
>                  print-severity yes;
>                  severity info;
>          };
>
>
> Does anyone have any idea how to solve this?
> I already added the -4 option to /etc/default/bind9.
> I found this conversation regarding the topic:
> https://echelog.com/logs/browse/smartos/1477605600
> This is from 2 years ago, and doesn't seem helpful by now, since bind
> starts, just it dumps an insane amount of log about this protocol
> unavailable. My eyes are bleeding, I barely see what protocol is missing
> here. As I wrote, I tried the obvious: adding -4 to the options, and I see
> that amongs the running process's arguments.
>
> Thanks for every help!
>
> Regards,
> Gyu
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From gary at genashor.com  Sun Sep 23 19:20:37 2018
From: gary at genashor.com (Gary Gendel)
Date: Sun, 23 Sep 2018 15:20:37 -0400
Subject: [OmniOS-discuss] dns howto
In-Reply-To: <20ecf94e-684c-a1b3-72f8-f27f19f8ae3e@gmail.com>
References: <20180922144703.GA30073@linux.gyakg.u-szeged.hu>
	<20ecf94e-684c-a1b3-72f8-f27f19f8ae3e@gmail.com>
Message-ID: <c7586b5c-bff3-8174-c2f8-565751187d71@genashor.com>

Or use another option like "unbound" available from pkgsrc.? I use a 
split-horizon setup where requests from the internal network get local 
NAT addresses so they aren't going through the external address. I find 
that unbound is much easier to configure than bind.

I second using pkgsrc as a primary repository, it provides just about 
everything? you could want.

On 9/23/2018 9:40 AM, Andries Annema wrote:
> Hi Gyu,
>
> Maybe not a direct answer to your question, but might it be an option 
> to use BIND from the 'pkgsrc' repository?
> http://pkgsrc.joyent.com/install-on-illumos/
>
> To me that repo seems quite future-proof for packages to be used in 
> non-lx zones.
>
> Regards,
>
> Andries
>
>
> On 2018-09-22 16:47, P?SZTOR Gy?rgy wrote:
>> Hi,
>>
>> Do someone have any best practice how to serve dns from omnios?
>> I'm migrating my home nas from my old N54L box to a custom built nas pc.
>> On the old box I have omnios 151014, where I served dns requests in 
>> my home
>> lan via an old zone migrated from the earlier openindiana 151a9 zone.
>> The 151a9 zone worked without any problem on the 151014 omnious 
>> without a
>> problem.
>> But I assume, some changes happened between 014 and 026 which broke 
>> binary
>> compatibility because neither my old 014 zone, neither my old 151a9 zone
>> was not able to start on the 026.
>> The 014 was not a big problem, even if there were no upgrade path.
>> I started with a clean zone, and moved there the other stuff (eg. 
>> nginx).
>> But the dns is kind a tricky. I checked how I served dns, and it seems
>> bind9 was part of the openindiana.org repo, while I was not able to find
>> any dns-related solution for current omnios releases.
>> I thought I'll do that with a debian9 lx zone.
>> Well, it's more or less work, but this error messages worries me in 
>> bind9's
>> log:
>> root at dns:/var/log/bind9# tail bind.log
>> 22-Sep-2018 14:39:31.166 general: error: 
>> ../../../../lib/isc/unix/socket.c:2881: unexpected error:
>> 22-Sep-2018 14:39:31.167 general: error: setsockopt(520, IP_RECVTOS) 
>> failed: Protocol not available
>> 22-Sep-2018 14:39:31.167 general: error: 
>> ../../../../lib/isc/unix/socket.c:2881: unexpected error:
>> 22-Sep-2018 14:39:31.167 general: error: setsockopt(521, IP_RECVTOS) 
>> failed: Protocol not available
>> 22-Sep-2018 14:39:44.555 general: error: 
>> ../../../../lib/isc/unix/socket.c:2881: unexpected error:
>> 22-Sep-2018 14:39:44.555 general: error: setsockopt(520, IP_RECVTOS) 
>> failed: Protocol not available
>> 22-Sep-2018 14:39:44.582 general: error: 
>> ../../../../lib/isc/unix/socket.c:2881: unexpected error:
>> 22-Sep-2018 14:39:44.583 general: error: setsockopt(520, IP_RECVTOS) 
>> failed: Protocol not available
>> 22-Sep-2018 14:39:44.711 general: error: 
>> ../../../../lib/isc/unix/socket.c:2881: unexpected error:
>> 22-Sep-2018 14:39:44.711 general: error: setsockopt(24, IP_RECVTOS) 
>> failed: Protocol not available
>>
>> relevant logging config:
>> root at dns:/etc/bind# grep -A 7 logging named.conf.options
>> logging {
>> ???????? channel b_log {
>> ???????????????? file "/var/log/bind9/bind.log" versions 30 size 1m;
>> ???????????????? print-time yes;
>> ???????????????? print-category yes;
>> ???????????????? print-severity yes;
>> ???????????????? severity info;
>> ???????? };
>>
>>
>> Does anyone have any idea how to solve this?
>> I already added the -4 option to /etc/default/bind9.
>> I found this conversation regarding the topic:
>> https://echelog.com/logs/browse/smartos/1477605600
>> This is from 2 years ago, and doesn't seem helpful by now, since bind
>> starts, just it dumps an insane amount of log about this protocol
>> unavailable. My eyes are bleeding, I barely see what protocol is missing
>> here. As I wrote, I tried the obvious: adding -4 to the options, and 
>> I see
>> that amongs the running process's arguments.
>>
>> Thanks for every help!
>>
>> Regards,
>> Gyu
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From pasztor at sagv5.gyakg.u-szeged.hu  Mon Sep 24 22:35:02 2018
From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=)
Date: Tue, 25 Sep 2018 00:35:02 +0200
Subject: [OmniOS-discuss] dns howto
In-Reply-To: <c7586b5c-bff3-8174-c2f8-565751187d71@genashor.com>
References: <20180922144703.GA30073@linux.gyakg.u-szeged.hu>
	<20ecf94e-684c-a1b3-72f8-f27f19f8ae3e@gmail.com>
	<c7586b5c-bff3-8174-c2f8-565751187d71@genashor.com>
Message-ID: <20180924223502.GA2326@linux.gyakg.u-szeged.hu>

Hi all,

"Gary Gendel" <gary at genashor.com> ?rta 2018-09-23 15:20-kor:
> Or use another option like "unbound" available from pkgsrc.? I use a 
> split-horizon setup where requests from the internal network get local 
> NAT addresses so they aren't going through the external address. I find 
> that unbound is much easier to configure than bind.

Well, if you learn both from scratch, maybe you are right.
But after years of bind administration, I would not change just for some no
extra effort worth home environment.
But the pkgsrc idea was quite good!

My BSD user friends mentioned this a lot; just until this point there were no
use case for me to try this stuff.
Well, I have to admit this was just the right place to try pkgsrc.
It's quite good stuff.
Also started to play with ansible at the same time to automate the
installation and maintenance of zones. It's a nice thing that ansible has
modules to manage pkgin, pkg5, and smf services.

Cheers,
Gyu

