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: 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: References: 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: 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: 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: References: <20180911154748.GA21503@linux.gyakg.u-szeged.hu> Message-ID: <20180912210541.GA8535@linux.gyakg.u-szeged.hu> Hi, "Andy Fiddaman" ?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: 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: 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: References: Message-ID: 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: References: <20180911154748.GA21503@linux.gyakg.u-szeged.hu> Message-ID: <20180922145203.GB30073@linux.gyakg.u-szeged.hu> Hi, "Andy Fiddaman" ?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: 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: References: <20180922144703.GA30073@linux.gyakg.u-szeged.hu> <20ecf94e-684c-a1b3-72f8-f27f19f8ae3e@gmail.com> Message-ID: <20180924223502.GA2326@linux.gyakg.u-szeged.hu> Hi all, "Gary Gendel" ?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