From geoffn at gnaa.net  Fri Apr  1 05:17:39 2016
From: geoffn at gnaa.net (Geoff Nordli)
Date: Thu, 31 Mar 2016 22:17:39 -0700
Subject: [OmniOS-discuss] VND and KVM
Message-ID: <56FE0473.3020402@gnaa.net>

Will the Joyent VND changes get merged into the next version of OmniOS?

It seems they were backed out the last time, and I haven't seen them 
come back in again.

thanks,

Geoff

From svavar at pipar-tbwa.is  Fri Apr  1 10:18:41 2016
From: svavar at pipar-tbwa.is (=?UTF-8?q?Svavar_=C3=96rn_Eysteinsson?=)
Date: Fri, 1 Apr 2016 10:18:41 +0000
Subject: [OmniOS-discuss] Installation Boot hangs after CPU/USB
 initialization - Intel Motherboard
In-Reply-To: <9D7D3346-F46A-40FB-A7B7-8D00746373AD@miras.org>
References: <D5E84467-BCFC-41B8-A557-43351A310103@pipar-tbwa.is>
	<10A21637-B670-4350-853E-6DA0549E8B20@omniti.com>
	<7A8A7BDC-23BB-47F6-A6A6-756D1354BE34@pipar-tbwa.is>
	<be6987720753a9468deb0d842cc6be0b@valo.at>
	<9680905E-E048-4E8E-B24C-239131BEE859@pipar-tbwa.is>
	<9D7D3346-F46A-40FB-A7B7-8D00746373AD@miras.org>
Message-ID: <F6AA5653-139E-4C5B-B2A7-7F57E4AE4F27@pipar-tbwa.is>

I installed OmniOS on another machine, with Intel cpu and SATA controllers in ACHI mode
from a USB Key. 100% success.

Moved the hard drive to the problematic machine and the same story continues.
It will boot up, but soon as the CPU initializing is done and USB controller is probed it will freeze and hang.

As the screenshot shows.

Pretty much the same if I boot the installation from USB/SATA CDROM...

https://dl.dropboxusercontent.com/u/16134/IMG_0918.JPG


So it seems that I'm stuck with running Solaris 11.3...

Svavar



> On 31. mar. 2016, at 11:16, Michael Rasmussen <mir at miras.org> wrote:
> 
> Try to disable usb in bios before installing.
> 
> On March 31, 2016 11:59:20 AM GMT+02:00, "Svavar ?rn Eysteinsson" <svavar at pipar-tbwa.is> wrote:
> So, Solaris 11.3 boots up and installs fine but not OmniOS.
> I sure would like to use OmniOS on this machine, so I ask are there any other debuging
> options for me at the installation level ?
> 
> Could I try to install OmniOS on a HDD/SSD on other machine with ACHI and boot it up on the problematic machine?
> Or is that just a no-go from the start?
> 
> Thanks again people.
> 
> Svavar
> Reykjavik - Iceland
> 
> 
> 
>  On 14. mar. 2016, at 21:28, Christian Kivalo <ml+omnios-discuss at valo.at> wrote:
>  
>  
>  
>  On 2016-03-09 11:00, Svavar ?rn Eysteinsson wrote:
>  Hi Dan.
>  Thanks for the reply.
>  I disabled all the C-states and it's the same story.
> 
> If I boot from the SATA CD-ROM installation it hangs on boot right after :
>  cpu7: Intel(r) Xeon(r) CPU E5520 @ 2.27Ghz
>  cpu6: Intel(r) Xeon(r) CPU E5520 @ 2.27Ghz
>  cpu7: initialization complete - online
>  cpu6: initialization complete - online
>  See here :
>  https://dl.dropboxusercontent.com/u/16134/omnios_intel_cstates_disabled_boot.JPG <https://dl.dropboxusercontent.com/u/16134/omnios_intel_cstates_disabled_boot.JPG>
>  If I boot from USB stick, with USB 2.0 enabled and or disabled the
>  last message is always releated to usb stuff
>  right after cpu6: initialization complete - online.
>  So my BIOS configuration right now is :
>  Intel QPI Frequency Select [Auto Max]
>  Intel Turbo Boots Technology [Enabled]
>  Enhanced Intel Speedstep Tech [Enabled]
>  Processor C3 [Disabled]
>  Processor C6 [Disabled]
>  Intel Hyper-Threading Tech [Disabled]
>  Core Multi-Processing [All]
>  Execute Disable Bit
> [Disabled]
>  Intel Virtualization Technology [Disasbled]
>  Intel VT for Directed I/O [Disabled]
>  and some more.
>  My Bios Configuration can been seen here :
>  https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios1.JPG <https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios1.JPG>
>  https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios2.JPG <https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios2.JPG>
>  https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios3.JPG <https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios3.JPG>
>  https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios4.JPG <https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios4.JPG>
>  Maybe something for you there was a thread here some months ago...
>  It starts here https://www.mail-archive.com/omnios-discuss%40lists.omniti.com/msg03194.html <https://www.mail-archive.com/omnios-discuss%40lists.omniti.com/msg03194.html>
>  
>  and some messages into the the thread X2APIC is mentioned
>  https://www.mail-archive.com/omnios-discuss%40lists.omniti.com/msg03200.html <https://www.mail-archive.com/omnios-discuss%40lists.omniti.com/msg03200.html>
>  
>  https://www.mail-archive.com/omnios-discuss%40lists.omniti.com/msg03201.html <https://www.mail-archive.com/omnios-discuss%40lists.omniti.com/msg03201.html>
>  
>  and a link a blogpost by jeff sipek
>  http://blahg.josefsipek.net/?p=488 <http://blahg.josefsipek.net/?p=488>
>  
>  
>  Best regards,
>  Svavar O
>  On 8. mar. 2016, at 15:13, Dan McDonald <danmcd at omniti.com> wrote:
>  On Mar 8, 2016, at 6:17 AM, Svavar ?rn Eysteinsson <svavar at pipar-tbwa.is> wrote:
>  Should I disable other CPU ? Should a enable C2, C3 state in BIOS or is that not relevant?
>  Disable C-states, that's general illumos advice (regardless of distro).
>  Dan
> 
>  OmniOS-discuss mailing list
>  OmniOS-discuss at lists.omniti.com
>  http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>  
>  -- 
>  Christian Kivalo
> 
>  OmniOS-discuss mailing list
>  OmniOS-discuss at lists.omniti.com
>  http://lists.omniti.com/mailman/listinfo/omnios-discuss <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 <http://lists.omniti.com/mailman/listinfo/omnios-discuss>
> 
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity. 
> ---- This mail was virus scanned and spam checked before delivery. This mail is also DKIM signed. See header dkim-signature. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160401/22f4cfc5/attachment.html>

From danmcd at omniti.com  Fri Apr  1 12:20:52 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 1 Apr 2016 08:20:52 -0400
Subject: [OmniOS-discuss] VND and KVM
In-Reply-To: <56FE0473.3020402@gnaa.net>
References: <56FE0473.3020402@gnaa.net>
Message-ID: <50259705-C588-40D0-A8BD-D38704ADA195@omniti.com>


> On Apr 1, 2016, at 1:17 AM, Geoff Nordli <geoffn at gnaa.net> wrote:
> 
> Will the Joyent VND changes get merged into the next version of OmniOS?

No.  We'll need to wait for upstreaming.

> It seems they were backed out the last time, and I haven't seen them come back in again.

A WHILE ago I experimented with them, found bugs (relating to zone shutdown destroying vNICs when it should've not done so), and let Joyent know.  Everyone's got more work to do than time&people, and upstreaming VND just hasn't happened yet.

Sorry,
Dan


From geoffn at gnaa.net  Fri Apr  1 19:36:43 2016
From: geoffn at gnaa.net (Geoff Nordli)
Date: Fri, 1 Apr 2016 12:36:43 -0700
Subject: [OmniOS-discuss] VND and KVM
In-Reply-To: <50259705-C588-40D0-A8BD-D38704ADA195@omniti.com>
References: <56FE0473.3020402@gnaa.net>
	<50259705-C588-40D0-A8BD-D38704ADA195@omniti.com>
Message-ID: <56FECDCB.8070102@gnaa.net>

On 16-04-01 05:20 AM, Dan McDonald wrote:
>> On Apr 1, 2016, at 1:17 AM, Geoff Nordli<geoffn at gnaa.net>  wrote:
>>
>> Will the Joyent VND changes get merged into the next version of OmniOS?
> No.  We'll need to wait for upstreaming.
>
>> It seems they were backed out the last time, and I haven't seen them come back in again.
> A WHILE ago I experimented with them, found bugs (relating to zone shutdown destroying vNICs when it should've not done so), and let Joyent know.  Everyone's got more work to do than time&people, and upstreaming VND just hasn't happened yet.
>
> Sorry,
> Dan
>

Thanks Dan.  I was just wondering what the status was.  I have been 
using VirtualBox, but I just bought a new server with a SLOG on it so 
KVM is now an option for me.

Any thoughts on what the network performance is currently like.

Happy Friday!!

Geoff



From peter.tribble at gmail.com  Mon Apr  4 21:15:12 2016
From: peter.tribble at gmail.com (Peter Tribble)
Date: Mon, 4 Apr 2016 22:15:12 +0100
Subject: [OmniOS-discuss] OpenSSL futures
In-Reply-To: <90D036FC-34E8-412A-828A-4ECC6CB1907A@omniti.com>
References: <90D036FC-34E8-412A-828A-4ECC6CB1907A@omniti.com>
Message-ID: <CAEgYsbHVuvUiRET=QrPKbk7jjuyCF6M0jtHQ3EAQZaAZxixuuQ@mail.gmail.com>

On Thu, Mar 31, 2016 at 3:40 PM, Dan McDonald <danmcd at omniti.com> wrote:

> As I'm updating and checking packages for r151018's release, I notice that
> OpenSSL is rapidly approaching a 1.1.0 release.  I visited their Release
> Strategy page:
>
>         http://openssl.org/policies/releasestrat.html
>
> And noticed that 1.0.2 is LTS until 2019.  OTOH, 1.1.x will likely become
> LTS for some x,


For x > 0 and as yet unannounced. Although the policy tells us roughly when
the next LTS is announced, end 2018 would seem reasonable.

What this tells me is to stick to 1.0.2 as the supported branch until the
next LTS
is decided. I'm presuming everything is going to be properly versioned so
that
one can ship two versions of the shared library in parallel for a
transitional period.

(Hm. Sounds rather like the libpng story in terms of evolving the API by
making
structures opaque. Although libpng changes the library name as well as the
version number of the .so. But my experience there was that the transition
was pretty ugly.)


> and there's also LibreSSL...
>

Not to mention PolarSSL and WolfSSL and ...

None of which are binary compatible with the current openssl (by which I
mean
you can use them as shared-library replacements). Although recent events
have
shown that openssl releases aren't quite as binary compatible as one would
like.


> I'm starting this thread to hear what the community has to say about where
> OmniOS should go w.r.t. its OpenSSL release.  I have internal customers
> too, of course, but I'll engage them separately.  We need to have an
> OpenSSL because illumos requires one.  We *could* do the SmartOS thing and
> keep our own SUNW/OMNI*...() api set, though.
>

They have to play those games because they ship 2 different openssl
instances,
though. (One with the platform, one via pkgsrc or whatever.) If you hide
the internal
copy, you still have to manage (or someone does, at any rate) compatibility
and
releases of the public copy. The problem doesn't go away, you just sweep it
under
someone else's carpet.

Users will have binaries linked against the existing openssl libraries, and
those
need to continue to run.


> I can't guarantee what I'll ultimately decide, but knowing what people
> think can't hurt.
>

Thanks for asking!

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160404/b3ebf8b1/attachment-0001.html>

From lotheac at iki.fi  Tue Apr  5 03:58:51 2016
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Tue, 5 Apr 2016 06:58:51 +0300
Subject: [OmniOS-discuss] OpenSSL futures
In-Reply-To: <CAEgYsbHVuvUiRET=QrPKbk7jjuyCF6M0jtHQ3EAQZaAZxixuuQ@mail.gmail.com>
References: <90D036FC-34E8-412A-828A-4ECC6CB1907A@omniti.com>
	<CAEgYsbHVuvUiRET=QrPKbk7jjuyCF6M0jtHQ3EAQZaAZxixuuQ@mail.gmail.com>
Message-ID: <20160405035851.GA21766@kekkonen.niksula.hut.fi>

On Mon, Apr 04 2016 22:15:12 +0100, Peter Tribble wrote:
> On Thu, Mar 31, 2016 at 3:40 PM, Dan McDonald <danmcd at omniti.com> wrote:
> > I'm starting this thread to hear what the community has to say about where
> > OmniOS should go w.r.t. its OpenSSL release.  I have internal customers
> > too, of course, but I'll engage them separately.  We need to have an
> > OpenSSL because illumos requires one.  We *could* do the SmartOS thing and
> > keep our own SUNW/OMNI*...() api set, though.
> >
> 
> They have to play those games because they ship 2 different openssl
> instances,
> though. (One with the platform, one via pkgsrc or whatever.) If you hide
> the internal
> copy, you still have to manage (or someone does, at any rate) compatibility
> and
> releases of the public copy. The problem doesn't go away, you just sweep it
> under
> someone else's carpet.

Here's another viewpoint though: I would like to choose the SSL
implementation used in my application stack, so I want this problem
under my carpet. Not just because I believe it has security benefits
(eg. getting ssl2 *actually* disabled; it couldn't be disabled in the
OmniOS shipped OpenSSL because that broke binary compatibility), but
also because my SSL library of choice ships a sane API (libtls [0]). If
OmniOS keeps shipping OpenSSL as a mandatory component *without*
changing its symbol names, I can't do what I want in my application
stack.

> Users will have binaries linked against the existing openssl libraries, and
> those
> need to continue to run.

OmniOS has removed (ie. stopped shipping) some other libraries in the
past [1], but I understand the OpenSSL story might be a little
different. Perhaps there's a middle ground here though: it seems like
you and I would both be happy if OmniOS kept shipping OpenSSL, but made
it optional (although then obviously it would have to have another copy
with mangled symbol names for the things illumos needs it for).

[0]: http://man.openbsd.org/OpenBSD-current/man3/tls_accept_fds.3
[1]: eg. 151006 removed several libraries, including libgnutls and
libgcrypt. http://omnios.omniti.com/wiki.php/ReleaseNotes/r151006

-- 
Lauri Tirkkonen | lotheac @ IRCnet

From mtalbott at lji.org  Wed Apr  6 06:02:18 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Tue, 5 Apr 2016 23:02:18 -0700
Subject: [OmniOS-discuss] pkg repos broken?
Message-ID: <84E78FAA-2B4D-4DEB-AB26-E2AB6EFC4A6D@lji.org>

All of a sudden I started getting the below errors on all of my OmniOS boxes when using pkg. Are the repos broken or did all of my servers break somehow at the same time?

I've removed each of the publishers and re-added them one at a time thinking maybe it's a particular one, but, I can't seem to isolate it to just one of them, so I suspect there might be something that broke on my end.. But it's happening on multiple boxes which makes me very suspicious.

pkg output says "caching catalogs..." then disappears right before the error message kicks out.

Suggestions?

Thanks,

Michael



root at store1:/root# cat /etc/release 
  OmniOS v11 r151014
  Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.
root at store1:/root# pkg update -nv
pkg: 2/3 catalogs successfully updated:
   
Invalid contentpath /var/pkg/cache/incoming-1202/catalog.attrs: CatalogPart failed validation: Catalog file '/var/pkg/cache/incoming-1202/catalog.attrs' is invalid.
Use 'pkgrepo rebuild' to create a new package catalog.. (happened 4 times)

root at store1:/root# pkg refresh --full
pkg: 2/3 catalogs successfully updated:
   
Invalid contentpath /var/pkg/cache/incoming-1214/catalog.attrs: CatalogPart failed validation: Catalog file '/var/pkg/cache/incoming-1214/catalog.attrs' is invalid.
Use 'pkgrepo rebuild' to create a new package catalog.. (happened 4 times)

root at store1:/root# pkg publisher
PUBLISHER                   TYPE     STATUS P LOCATION
omnios                      origin   online F http://pkg.omniti.com/omnios/r151014/
ms.omniti.com               origin   online F http://pkg.omniti.com/omniti-ms/
perl.omniti.com              origin   online F http://pkg.omniti.com/omniti-perl/
root at store1:/root# 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160405/1e3e5c37/attachment.html>

From danmcd at omniti.com  Wed Apr  6 13:16:01 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 6 Apr 2016 09:16:01 -0400
Subject: [OmniOS-discuss] pkg repos broken?
In-Reply-To: <84E78FAA-2B4D-4DEB-AB26-E2AB6EFC4A6D@lji.org>
References: <84E78FAA-2B4D-4DEB-AB26-E2AB6EFC4A6D@lji.org>
Message-ID: <EE0342F0-70EE-4E9D-B42D-B9938286F563@omniti.com>


> On Apr 6, 2016, at 2:02 AM, Michael Talbott <mtalbott at lji.org> wrote:
> 
> But it's happening on multiple boxes which makes me very suspicious.
> 
> pkg output says "caching catalogs..." then disappears right before the error message kicks out.
> 

This is something weird happening at our load-balancers, I've verified the actual source of bits is intact.  Also, I believe this only affects the OmniOS r151014 repo, as I could not reproduce your problem on my r151016 home server.

Thanks for reporting this.  I'll ping this thread when our ops folks have whacked the load-balancer upside the head.

Dan


From danmcd at omniti.com  Wed Apr  6 14:56:11 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 6 Apr 2016 10:56:11 -0400
Subject: [OmniOS-discuss] pkg repos broken?
In-Reply-To: <EE0342F0-70EE-4E9D-B42D-B9938286F563@omniti.com>
References: <84E78FAA-2B4D-4DEB-AB26-E2AB6EFC4A6D@lji.org>
	<EE0342F0-70EE-4E9D-B42D-B9938286F563@omniti.com>
Message-ID: <4E9045F4-67D5-40DF-A774-B237B79A1ADB@omniti.com>


> On Apr 6, 2016, at 9:16 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> Thanks for reporting this.  I'll ping this thread when our ops folks have whacked the load-balancer upside the head.

The OmniTI ops staff has fixed the problem - thanks folks!  The r151014 repo is serving requests again.

Thanks all for your patience, and thanks for reporting it in the first place.

Dan


From Josh.Barton at usurf.usu.edu  Wed Apr  6 17:23:51 2016
From: Josh.Barton at usurf.usu.edu (Josh Barton)
Date: Wed, 6 Apr 2016 17:23:51 +0000
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk Controller
	Recommendations
Message-ID: <1459963432173.44935@usurf.usu.edu>

I am hoping to build a server with 15+ drives managed in ZFS that will run a 1TB+ postgres database.


[NEEDS]

15-20 drive bays (ideally SFF/2.5")

JBOD disk controller ideal for running ZFS


In the past I purchased an HP Proliant DL380P Gen 8 but it had a "Smart Array Controller" that prevented us from hot swapping drives. It also seemed to haveless IO channels than might be good when running a box with 16 drives.


What would you recommend for  either a complete server configuration or at the very least  a disk controller for running this environment?


Thank you,


Josh Barton

Systems Admin/Developer

USU Research Foundation

From mir at miras.org  Wed Apr  6 17:45:03 2016
From: mir at miras.org (Michael Rasmussen)
Date: Wed, 6 Apr 2016 19:45:03 +0200
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk
 Controller Recommendations
In-Reply-To: <1459963432173.44935@usurf.usu.edu>
References: <1459963432173.44935@usurf.usu.edu>
Message-ID: <20160406194503.4af839d4@sleipner.datanom.net>

On Wed, 6 Apr 2016 17:23:51 +0000
Josh Barton <Josh.Barton at usurf.usu.edu> wrote:

> 
> What would you recommend for  either a complete server configuration or at the very least  a disk controller for running this environment?
> 
This controller is known to work and provide support for 16 disks:
http://www.avagotech.com/products/server-storage/host-bus-adapters/sas-9201-16i
and this newer one:
http://www.avagotech.com/products/server-storage/host-bus-adapters/sas-9300-16i

There is also a controller for 24 disks, but I don't know whether it is
supported by 141014:
http://www.avagotech.com/products/server-storage/host-bus-adapters/sas-9305-24i

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Debian Hint #33: The package 'devscripts' contains some useful scripts
for users who want to help to improve Debian, e.g. wnpp-alert, rc-alert
and bts.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160406/bb2901fe/attachment-0001.bin>

From peter.tribble at gmail.com  Wed Apr  6 17:56:53 2016
From: peter.tribble at gmail.com (Peter Tribble)
Date: Wed, 6 Apr 2016 18:56:53 +0100
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk
	Controller Recommendations
In-Reply-To: <1459963432173.44935@usurf.usu.edu>
References: <1459963432173.44935@usurf.usu.edu>
Message-ID: <CAEgYsbEo1ichnED+zHHSGTEjKY03uT2PAhW1o5+CwM=r-5k-dA@mail.gmail.com>

On Wed, Apr 6, 2016 at 6:23 PM, Josh Barton <Josh.Barton at usurf.usu.edu>
wrote:

> I am hoping to build a server with 15+ drives managed in ZFS that will run
> a 1TB+ postgres database.
>
>
> [NEEDS]
>
> 15-20 drive bays (ideally SFF/2.5")
>
> JBOD disk controller ideal for running ZFS
>
>
> In the past I purchased an HP Proliant DL380P Gen 8 but it had a "Smart
> Array Controller" that prevented us from hot swapping drives. It also
> seemed to haveless IO channels than might be good when running a box with
> 16 drives.
>
>
> What would you recommend for  either a complete server configuration or at
> the very least  a disk controller for running this environment?
>

We've just gone for something similar. I've covered it in longer form here:


http://ptribble.blogspot.co.uk/2016/03/supermicro-illumos-compatible-server.html

But basically, we've got the Supermicro SC216BAC-R920LPB
<http://www.supermicro.co.uk/products/chassis/2U/216/SC216BAC-R920LP.cfm>
chassis with
the X10DRi-T4+
<http://www.supermicro.co.uk/products/motherboard/Xeon/C600/X10DRi-T4_.cfm>
motherboard and 3 LSI 9300-8i HBAs; then Intel 3510 boot
drives and 3610 data drives. Built last week, but everything's working fine
so far.

(Question: why 15+ drives? Given that you can easily get 1.8TB SSDs these
days, I'm not sure why you need so many drives.)

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160406/21d1bbae/attachment.html>

From chip at innovates.com  Thu Apr  7 15:52:55 2016
From: chip at innovates.com (Schweiss, Chip)
Date: Thu, 7 Apr 2016 10:52:55 -0500
Subject: [OmniOS-discuss] Routing challlenges
Message-ID: <CALeZrrTju23mHj6Aip9mO3uy4heb_ewUnkkusyXdDjLLB065fw@mail.gmail.com>

On several of my OmniOS hosts I have a setup a management interface for SSH
access on an independent VLAN.   There are service vlans attached to other
nics.

The problem I am having is that when on privileged machine on one of the
vlans also on the service side that has access to the management SSH port
the TCP SYN comes in the management VLAN but the SYNACK goes out the
service VLAN instead of routing back out its connecting port.   This causes
a split route and the firewall blocks the connection because the connection
never appears complete.

Traffic is flowing like this:
client                   firewall                 omnnios
10.28.0.106 ->   10.28.0.254->10.28.125.254  -> 10.28.125.44

10.28.0.106  <--------------------------------- 10.28.0.44

How can I cause connections to only communicate on the vlan that the
connection is initiated from?

I don't want to use the 10.28.0.44 interface because that is a virtual IP
and will not always be on the same host.

-Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/e750083c/attachment.html>

From jeff at 1beyond.com  Thu Apr  7 17:14:02 2016
From: jeff at 1beyond.com (Jeff Berkembrock)
Date: Thu, 7 Apr 2016 13:14:02 -0400
Subject: [OmniOS-discuss] OmniOS and USGv6 compliance
Message-ID: <CAEGbm657KbXay=6B+qjN2FykRazTwus+_fW3o4MkzEj=++oqdA@mail.gmail.com>

Hello,

I learned recently that US government agencies cannot purchase equipment
that connects to their network unless said equipment is proven to work with
IPv6.

Suppliers must submit a Supplier's Declaration of Conformity (SDOC) which
shows that an accredited testing lab has qualified various IPv6
functionality. You can read more about it here:
http://www-x.antd.nist.gov/usgv6/index.html

Our company won a bid to sell a storage server to a government agency.
We were planning on supplying a system built on OmniOS. I've just learned
from one of these accredited testing labs (UNH InterOperability Lab) that
OmniOS does not have an SDOC.

If we were to sell an Omni server to this government agency then OmniOS
would need to be tested at UNH IOL to produce an SDOC.

Has anyone in this list run into this issue before?
Is there any way around it?
We'd really prefer to use OmniOS in this particular build. I'd love to hear
your ideas.

Best Regards,

Jeff Berkembrock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/a755dcf1/attachment.html>

From mtalbott at lji.org  Thu Apr  7 17:25:48 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 7 Apr 2016 10:25:48 -0700
Subject: [OmniOS-discuss] Routing challlenges
In-Reply-To: <CALeZrrTju23mHj6Aip9mO3uy4heb_ewUnkkusyXdDjLLB065fw@mail.gmail.com>
References: <CALeZrrTju23mHj6Aip9mO3uy4heb_ewUnkkusyXdDjLLB065fw@mail.gmail.com>
Message-ID: <97237967-526F-483A-BE71-9F34383A7FAC@lji.org>

It sounds like you're using the same subnet for management and service traffic, that would be the problem causing the split route. Give each vlan a unique subnet and traffic should flow correctly.

Michael
Sent from my iPhone

> On Apr 7, 2016, at 8:52 AM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> On several of my OmniOS hosts I have a setup a management interface for SSH access on an independent VLAN.   There are service vlans attached to other nics.
> 
> The problem I am having is that when on privileged machine on one of the vlans also on the service side that has access to the management SSH port the TCP SYN comes in the management VLAN but the SYNACK goes out the service VLAN instead of routing back out its connecting port.   This causes a split route and the firewall blocks the connection because the connection never appears complete.
> 
> Traffic is flowing like this:
> client                   firewall                 omnnios
> 10.28.0.106 ->   10.28.0.254->10.28.125.254  -> 10.28.125.44
> 
> 10.28.0.106  <--------------------------------- 10.28.0.44         
> 
> How can I cause connections to only communicate on the vlan that the connection is initiated from?   
> 
> I don't want to use the 10.28.0.44 interface because that is a virtual IP and will not always be on the same host.
> 
> -Chip
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/535b3e65/attachment.html>

From mtalbott at lji.org  Thu Apr  7 17:51:16 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 7 Apr 2016 10:51:16 -0700
Subject: [OmniOS-discuss] Routing challlenges
In-Reply-To: <97237967-526F-483A-BE71-9F34383A7FAC@lji.org>
References: <CALeZrrTju23mHj6Aip9mO3uy4heb_ewUnkkusyXdDjLLB065fw@mail.gmail.com>
	<97237967-526F-483A-BE71-9F34383A7FAC@lji.org>
Message-ID: <0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org>

Oh, I see. Sorry about that, reading it on my phone didn't render your diagram properly ;)

The reason this is happening is because the omnios box has knowledge of both subnets in its routing table and it always takes the shortest path to reach an ip destination.

So you will need to put the "clients" in a unique subnet that always passes through the firewall in both directions (in a subnet that's not shared by the omnios machines). Any attempt to add/modify a static route to the omnios box to resolve this will likely fail (it'll just move the problem from one network to the other one and cause your "services" network to route improperly).

Either that, or remove the firewall as a hop, set sshd to listen only on the management IP, and add a management vlan interface to the clients allowed to connect.

Michael


> On Apr 7, 2016, at 10:25 AM, Michael Talbott <mtalbott at lji.org> wrote:
> 
> It sounds like you're using the same subnet for management and service traffic, that would be the problem causing the split route. Give each vlan a unique subnet and traffic should flow correctly.
> 
> Michael
> Sent from my iPhone
> 
> On Apr 7, 2016, at 8:52 AM, Schweiss, Chip <chip at innovates.com <mailto:chip at innovates.com>> wrote:
> 
>> On several of my OmniOS hosts I have a setup a management interface for SSH access on an independent VLAN.   There are service vlans attached to other nics.
>> 
>> The problem I am having is that when on privileged machine on one of the vlans also on the service side that has access to the management SSH port the TCP SYN comes in the management VLAN but the SYNACK goes out the service VLAN instead of routing back out its connecting port.   This causes a split route and the firewall blocks the connection because the connection never appears complete.
>> 
>> Traffic is flowing like this:
>> client                   firewall                 omnnios
>> 10.28.0.106 ->   10.28.0.254->10.28.125.254  -> 10.28.125.44
>> 
>> 10.28.0.106  <--------------------------------- 10.28.0.44         
>> 
>> How can I cause connections to only communicate on the vlan that the connection is initiated from?   
>> 
>> I don't want to use the 10.28.0.44 interface because that is a virtual IP and will not always be on the same host.
>> 
>> -Chip
>> 
>> 
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/c9f5bec2/attachment-0001.html>

From chip at innovates.com  Thu Apr  7 18:50:13 2016
From: chip at innovates.com (Schweiss, Chip)
Date: Thu, 7 Apr 2016 13:50:13 -0500
Subject: [OmniOS-discuss] Routing challlenges
In-Reply-To: <0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org>
References: <CALeZrrTju23mHj6Aip9mO3uy4heb_ewUnkkusyXdDjLLB065fw@mail.gmail.com>
	<97237967-526F-483A-BE71-9F34383A7FAC@lji.org>
	<0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org>
Message-ID: <CALeZrrRyhSvCr24+BPQ=LOOsUb2CU16WV1qK2sCLptFzt2a+MQ@mail.gmail.com>

On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott <mtalbott at lji.org> wrote:

> Oh, I see. Sorry about that, reading it on my phone didn't render your
> diagram properly ;)
>
> The reason this is happening is because the omnios box has knowledge of
> both subnets in its routing table and it always takes the shortest path to
> reach an ip destination.
>

That's definitely the reason, but not correct when stateful firewalls are
involved.

>
> So you will need to put the "clients" in a unique subnet that always
> passes through the firewall in both directions (in a subnet that's not
> shared by the omnios machines). Any attempt to add/modify a static route to
> the omnios box to resolve this will likely fail (it'll just move the
> problem from one network to the other one and cause your "services" network
> to route improperly).
>

The problem is each person who manages these (there are 4) are also clients
of the services (SMB, NFS).

For management, going through the firewall is fine, it is low volume, but
the services need to be on the same VLAN or else the 1gb firewall will
choke on the 10gb services.


> Either that, or remove the firewall as a hop, set sshd to listen only on
> the management IP, and add a management vlan interface to the clients
> allowed to connect.
>
>
I've considered this too, but I have some floating IP attached to zfs pools
in an HA cluster that SSH needs to bind to.

Unless I can get the network stack on the management vlan to act
independently of the other interfaces, it may come to modifying the
sshd_config and restarting ssh each time a pool is started or stopped on a
host.

-Chip



> Michael
>
>
> On Apr 7, 2016, at 10:25 AM, Michael Talbott <mtalbott at lji.org> wrote:
>
> It sounds like you're using the same subnet for management and service
> traffic, that would be the problem causing the split route. Give each vlan
> a unique subnet and traffic should flow correctly.
>
> Michael
> Sent from my iPhone
>
> On Apr 7, 2016, at 8:52 AM, Schweiss, Chip <chip at innovates.com> wrote:
>
> On several of my OmniOS hosts I have a setup a management interface for
> SSH access on an independent VLAN.   There are service vlans attached to
> other nics.
>
> The problem I am having is that when on privileged machine on one of the
> vlans also on the service side that has access to the management SSH port
> the TCP SYN comes in the management VLAN but the SYNACK goes out the
> service VLAN instead of routing back out its connecting port.   This causes
> a split route and the firewall blocks the connection because the connection
> never appears complete.
>
> Traffic is flowing like this:
> client                   firewall                 omnnios
> 10.28.0.106 ->   10.28.0.254->10.28.125.254  -> 10.28.125.44
>
> 10.28.0.106  <--------------------------------- 10.28.0.44
>
> How can I cause connections to only communicate on the vlan that the
> connection is initiated from?
>
> I don't want to use the 10.28.0.44 interface because that is a virtual IP
> and will not always be on the same host.
>
> -Chip
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/aa241458/attachment.html>

From pasztor at sagv5.gyakg.u-szeged.hu  Thu Apr  7 19:38:19 2016
From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=)
Date: Thu, 7 Apr 2016 21:38:19 +0200
Subject: [OmniOS-discuss] [FWD] Re:  Routing challlenges
Message-ID: <20160407193819.GD19684@linux.gyakg.u-szeged.hu>

Hi, sorry, I forget to modify the "to", to the list..

----- Forwarded message from P?SZTOR Gy?rgy <pasztor at linux.gyakg.u-szeged.hu> -----

Date: Thu, 7 Apr 2016 21:36:55 +0200
From: P?SZTOR Gy?rgy <pasztor at linux.gyakg.u-szeged.hu>
To: "Schweiss, Chip" <chip at innovates.com>

Hi,

"Schweiss, Chip" <chip at innovates.com> ?rta 2016-04-07 10:52-kor:
> The problem I am having is that when on privileged machine on one of the
> vlans also on the service side that has access to the management SSH port
> the TCP SYN comes in the management VLAN but the SYNACK goes out the
> service VLAN instead of routing back out its connecting port.   This causes
> a split route and the firewall blocks the connection because the connection
> never appears complete.
> 
> Traffic is flowing like this:
> client                   firewall                 omnnios
> 10.28.0.106 ->   10.28.0.254->10.28.125.254  -> 10.28.125.44
> 
> 10.28.0.106  <--------------------------------- 10.28.0.44
> 
> How can I cause connections to only communicate on the vlan that the
> connection is initiated from?

The problem pretty much sounds, ... to that, where the solution would be
this, if it were a linux:
http://lartc.org/howto/lartc.rpdb.multiple-links.html

I do not know, if there is similar solution in illumos based systems.
I mean: Policy based routing. If there, then, that is the solution.

Other possible working solution:
As far as I understood the requirements, you want to serve nfs, and other
things on one 10ge interface, but let in ssh only on another subnet on a
1ge interface.
Solution a;
* create a "stub network", which is only available on the host, and zones,
* create a zone for ssh (let's call it jumpzone): which access the 1ge port
and the stub network,
* put the hosts sshd to listen only on localhost, and on the stub network
interface

Solution b;
* do not configure 10ge interface on the "host"
* create a "service" zone, which exclusively accesses the 10ge interface.
* "service" zone would be only configured to access 10.28.0

At solution b: as far as I know, newer illumos kernels supports to export
nfs and smbfs from zones, so it may work. But it may contain other gotchas
which we may not foreseen.

Or,... find docs about policy based routing on illumos.

Cheers,
Gyu

----- End forwarded message -----

From mtalbott at lji.org  Thu Apr  7 19:41:28 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 7 Apr 2016 12:41:28 -0700
Subject: [OmniOS-discuss] Routing challlenges
In-Reply-To: <CALeZrrRyhSvCr24+BPQ=LOOsUb2CU16WV1qK2sCLptFzt2a+MQ@mail.gmail.com>
References: <CALeZrrTju23mHj6Aip9mO3uy4heb_ewUnkkusyXdDjLLB065fw@mail.gmail.com>
	<97237967-526F-483A-BE71-9F34383A7FAC@lji.org>
	<0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org>
	<CALeZrrRyhSvCr24+BPQ=LOOsUb2CU16WV1qK2sCLptFzt2a+MQ@mail.gmail.com>
Message-ID: <17A05815-F6B5-494A-9FCD-9F1589BA9C77@lji.org>

I see. I know in the linux world, one could use iptables to tag packets coming in on an interface and then route the response back out of the interface they came in which would solve the issue (which I've done before to work around a similar oddball issue), but, I have no idea if that sort of low level packet manipulation is something OmniOS is capable of. If so, that'd solve the problem.

A different and ugly approach would be to have the OmniOS box use a software firewall to only allow ssh on the desired VLAN interface, enable ip forwarding in OmniOS, and then add static routes (yes plural) to your client machines as needed to use each OmniOS server as it's very own gateway to it's own management vlan ip. It's ugly, but, it could work.

The only other way I could think of is maybe you could run ssh in a zone and maybe that zone can have it's own independent network stack? I'm not very familiar with zone networking, so maybe it can do that, maybe not?

Michael


> On Apr 7, 2016, at 11:50 AM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> 
> 
> On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott <mtalbott at lji.org <mailto:mtalbott at lji.org>> wrote:
> Oh, I see. Sorry about that, reading it on my phone didn't render your diagram properly ;)
> 
> The reason this is happening is because the omnios box has knowledge of both subnets in its routing table and it always takes the shortest path to reach an ip destination.
> 
> That's definitely the reason, but not correct when stateful firewalls are involved.
> 
> So you will need to put the "clients" in a unique subnet that always passes through the firewall in both directions (in a subnet that's not shared by the omnios machines). Any attempt to add/modify a static route to the omnios box to resolve this will likely fail (it'll just move the problem from one network to the other one and cause your "services" network to route improperly).
> 
> The problem is each person who manages these (there are 4) are also clients of the services (SMB, NFS).  
> 
> For management, going through the firewall is fine, it is low volume, but the services need to be on the same VLAN or else the 1gb firewall will choke on the 10gb services.
> 
> 
> Either that, or remove the firewall as a hop, set sshd to listen only on the management IP, and add a management vlan interface to the clients allowed to connect.
> 
> 
> I've considered this too, but I have some floating IP attached to zfs pools in an HA cluster that SSH needs to bind to.   
> 
> Unless I can get the network stack on the management vlan to act independently of the other interfaces, it may come to modifying the sshd_config and restarting ssh each time a pool is started or stopped on a host.  
> 
> -Chip
> 
>  
> Michael
> 
> 
>> On Apr 7, 2016, at 10:25 AM, Michael Talbott <mtalbott at lji.org <mailto:mtalbott at lji.org>> wrote:
>> 
>> It sounds like you're using the same subnet for management and service traffic, that would be the problem causing the split route. Give each vlan a unique subnet and traffic should flow correctly.
>> 
>> Michael
>> Sent from my iPhone
>> 
>> On Apr 7, 2016, at 8:52 AM, Schweiss, Chip <chip at innovates.com <mailto:chip at innovates.com>> wrote:
>> 
>>> On several of my OmniOS hosts I have a setup a management interface for SSH access on an independent VLAN.   There are service vlans attached to other nics.
>>> 
>>> The problem I am having is that when on privileged machine on one of the vlans also on the service side that has access to the management SSH port the TCP SYN comes in the management VLAN but the SYNACK goes out the service VLAN instead of routing back out its connecting port.   This causes a split route and the firewall blocks the connection because the connection never appears complete.
>>> 
>>> Traffic is flowing like this:
>>> client                   firewall                 omnnios
>>> 10.28.0.106 ->   10.28.0.254->10.28.125.254  -> 10.28.125.44
>>> 
>>> 10.28.0.106  <--------------------------------- 10.28.0.44         
>>> 
>>> How can I cause connections to only communicate on the vlan that the connection is initiated from?   
>>> 
>>> I don't want to use the 10.28.0.44 interface because that is a virtual IP and will not always be on the same host.
>>> 
>>> -Chip
>>> 
>>> 
>>> _______________________________________________
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/1c2c91df/attachment-0001.html>

From jimklimov at cos.ru  Thu Apr  7 20:28:04 2016
From: jimklimov at cos.ru (Jim Klimov)
Date: Thu, 07 Apr 2016 22:28:04 +0200
Subject: [OmniOS-discuss] Routing challlenges
In-Reply-To: <CALeZrrRyhSvCr24+BPQ=LOOsUb2CU16WV1qK2sCLptFzt2a+MQ@mail.gmail.com>
References: <CALeZrrTju23mHj6Aip9mO3uy4heb_ewUnkkusyXdDjLLB065fw@mail.gmail.com>
	<97237967-526F-483A-BE71-9F34383A7FAC@lji.org>
	<0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org>
	<CALeZrrRyhSvCr24+BPQ=LOOsUb2CU16WV1qK2sCLptFzt2a+MQ@mail.gmail.com>
Message-ID: <303528CE-CF9A-40CE-8702-E817554E49F6@cos.ru>

7 ?????? 2016??. 20:50:13 CEST, "Schweiss, Chip" <chip at innovates.com> ?????:
>On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott <mtalbott at lji.org>
>wrote:
>
>> Oh, I see. Sorry about that, reading it on my phone didn't render
>your
>> diagram properly ;)
>>
>> The reason this is happening is because the omnios box has knowledge
>of
>> both subnets in its routing table and it always takes the shortest
>path to
>> reach an ip destination.
>>
>
>That's definitely the reason, but not correct when stateful firewalls
>are
>involved.
>
>>
>> So you will need to put the "clients" in a unique subnet that always
>> passes through the firewall in both directions (in a subnet that's
>not
>> shared by the omnios machines). Any attempt to add/modify a static
>route to
>> the omnios box to resolve this will likely fail (it'll just move the
>> problem from one network to the other one and cause your "services"
>network
>> to route improperly).
>>
>
>The problem is each person who manages these (there are 4) are also
>clients
>of the services (SMB, NFS).
>
>For management, going through the firewall is fine, it is low volume,
>but
>the services need to be on the same VLAN or else the 1gb firewall will
>choke on the 10gb services.
>
>
>> Either that, or remove the firewall as a hop, set sshd to listen only
>on
>> the management IP, and add a management vlan interface to the clients
>> allowed to connect.
>>
>>
>I've considered this too, but I have some floating IP attached to zfs
>pools
>in an HA cluster that SSH needs to bind to.
>
>Unless I can get the network stack on the management vlan to act
>independently of the other interfaces, it may come to modifying the
>sshd_config and restarting ssh each time a pool is started or stopped
>on a
>host.
>
>-Chip
>
>
>
>> Michael
>>
>>
>> On Apr 7, 2016, at 10:25 AM, Michael Talbott <mtalbott at lji.org>
>wrote:
>>
>> It sounds like you're using the same subnet for management and
>service
>> traffic, that would be the problem causing the split route. Give each
>vlan
>> a unique subnet and traffic should flow correctly.
>>
>> Michael
>> Sent from my iPhone
>>
>> On Apr 7, 2016, at 8:52 AM, Schweiss, Chip <chip at innovates.com>
>wrote:
>>
>> On several of my OmniOS hosts I have a setup a management interface
>for
>> SSH access on an independent VLAN.   There are service vlans attached
>to
>> other nics.
>>
>> The problem I am having is that when on privileged machine on one of
>the
>> vlans also on the service side that has access to the management SSH
>port
>> the TCP SYN comes in the management VLAN but the SYNACK goes out the
>> service VLAN instead of routing back out its connecting port.   This
>causes
>> a split route and the firewall blocks the connection because the
>connection
>> never appears complete.
>>
>> Traffic is flowing like this:
>> client                   firewall                 omnnios
>> 10.28.0.106 ->   10.28.0.254->10.28.125.254  -> 10.28.125.44
>>
>> 10.28.0.106  <--------------------------------- 10.28.0.44
>>
>> How can I cause connections to only communicate on the vlan that the
>> connection is initiated from?
>>
>> I don't want to use the 10.28.0.44 interface because that is a
>virtual IP
>> and will not always be on the same host.
>>
>> -Chip
>>
>>
>> _______________________________________________
>> 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

Just in case, remember that with ipfikter on the host you can effect 'source-routing' and assign (at least non-dynamically) what router should be taken for what sort of connections. It works by blocking 'destination-routed' packets if they match your rule, and rewriting them as destined to go out of another NIC and to another gateway.

Example from work (I think I posted it more than once in the past - then if you find those discussions, they might also hold some neat ideas), this is essentially the first rule in /etc/ipf/ipf.conf (before loopbacks, allow-all-for-some and head's for complicated other rule trees):

# enforce that packets coming out of an interface go to the correct subnet
# rhetoric question: does this skip the firewall rules below in the file?
block out quick on vlan186 to vlan81:81.X.Y.1 from 81.X.Y.0/24 to any
block out quick on vlan81 to vlan186:192.168.186.1 from ! 81.X.Y.0/24 to any

Note the "!" negation in the second rule.

HTH,
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From danmcd at omniti.com  Fri Apr  8 00:58:15 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 7 Apr 2016 20:58:15 -0400
Subject: [OmniOS-discuss] Caiman issues with certain timezones
Message-ID: <30FEDF6B-1A5B-46A1-9B31-0BB853D73C91@omniti.com>

A repeating problem has been with the ISO/USB "Caiman" installer barfing out upon selecting a timezone in Europe, Asia, or Africa.  All of these have timezones that use non-ASCII characters in one of their zone names.

I've finally (and sorry for the delay) worked out a solution:  Have the installer run with LANG=en_US.UTF-8, so it can handle the characters.  The problem is, caiman's display doesn't cope with it very well, and draws letters where there used to be line/drawing characters.

So my quick question to you all:  for r151018 (and backporting), do you prefer a nicer-looking installer that craps out if you select Africa, Europe, or Asia?  Or do you prefer a sketchier-looking one that works for all timezones out of the box?  I'm cutting the last 017 bloody with this, so you can try it out yourself when it shows up.

Some people set their timezones in /etc/default/init AFTER installation, so I'm asking, instead of just making the decision.  I'm attaching a screenshot of the en_US.UTF-8 one.  Note the letter q where there should be a left-to-right bar:



Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/40a21686/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-04-07 at 8.55.40 PM.png
Type: image/png
Size: 30088 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/40a21686/attachment-0001.png>

From jcoombs at staff.gwi.net  Fri Apr  8 03:35:33 2016
From: jcoombs at staff.gwi.net (Josh Coombs)
Date: Thu, 7 Apr 2016 23:35:33 -0400
Subject: [OmniOS-discuss] NVMe Performance
Message-ID: <CACcUnf8G1DDZ_eC_nbX6xbPcpSdQ0AUAWBrhJWs_xk82r_PGwA@mail.gmail.com>

Hi all,

I just recently kitbashed a backup storage dump based on OmniOS, a couple
retired servers and a few new bits to improve it's perf.

- HP DL360 G6 with dual Xeon 5540s, 80GB RAM
- The onboard HP SAS is hosting the root pool on it's RAID 5 of SAS disks,
not ideal but the card doesn't have an IT mode.
- LSI 9208e for main storage
- - Chenbro SAS expander in an Addonics 20 bay SATA shelf
- - 5 x WD 6TB Red drives in a RAIDz3 pool
- 4 x onboard GigE, LAG'd together
- dual port QLogic 4GB FC card for later use with my VMWare farm

As I noted I was able to get a few new bits for the box, three Intel DC3600
400GB PCIe NVMe SSDs.  I figured I could use two for log in a mirror setup,
and one for cache and have a lovely setup.

Initial testing without the NVMe drives setup with dd shows I can slam a
sustained 300MB/s to the SATA pool when dumping to a file in one of my zfs
repositories:

# dd if=/dev/zero of=bigfile bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 37.3299 s, 288 MB/s

# dd if=/dev/zero of=bigfile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.593213 s, 1.8 GB/s

For short bursts, the box caches nicely with the ram I was able to scrounge
up.  I forgot I had one zfs set for gzip-9 compression and was very
impressed to see it sustained 1.7 GB/s over the course of dumping 107 GB of
zeros, nice!

Setting up a simple pool using one NVMe card with one volume and repeating
the test on it I get:

# dd if=/dev/zero of=bigfile bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 16.1904 s, 663 MB/s

Not quite the blazing performance I was expecting.  I was hoping they could
sustain at least twice that.  If I make a zpool out of all three and bump
my test to 53GB it sustains 1.1 GB/s, so there is a little performance
scaling by spreading the work across all three but again no where near what
I was anticipating.

I also did a raw write to one of the units after making sure it wasn't in
use by any pools:
# dd if=/dev/zero of=/dev/rdsk/c3t1d0 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 22.2461 s, 483 MB/s

If I get the system loaded enough, doing that results in transport errors
being logged for the unit while I'm hammering it with dd.

Digging around I found some FreeBSD discussions where they observed their
NVMe driver rolling back to legacy interrupt mode on systems with lots of
cpu cores as they ran out of MSIx slots.  Given I've got 8 physical cores
and I've got a lot of devices on the PCIe bus I don't know if that is a
possibility here or not.  I've not poked at the driver source yet as to be
honest I wouldn't know what I was looking for.

I also understand that the driver is pretty new to Illumos so I shouldn't
expect it to be a rocket yet.  I just figured I'd share what I've observed
so far to see if that matches what I should expect or if there is
additional testing work I can do to help improve the driver's performance
down the road.

Josh Coombs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160407/d0918e6b/attachment.html>

From danmcd at omniti.com  Fri Apr  8 05:16:55 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 8 Apr 2016 01:16:55 -0400
Subject: [OmniOS-discuss] NVMe Performance
In-Reply-To: <CACcUnf8G1DDZ_eC_nbX6xbPcpSdQ0AUAWBrhJWs_xk82r_PGwA@mail.gmail.com>
References: <CACcUnf8G1DDZ_eC_nbX6xbPcpSdQ0AUAWBrhJWs_xk82r_PGwA@mail.gmail.com>
Message-ID: <0D7DCD1D-8B1A-47D0-A810-865C9E5B80A3@omniti.com>

Thanks for these measurements and observations.  I will suggest you forward this mail to the Illumos developer list, for a wider audience.

Thanks!
Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Apr 7, 2016, at 11:35 PM, Josh Coombs <jcoombs at staff.gwi.net> wrote:
> 
> Hi all,
> 
> I just recently kitbashed a backup storage dump based on OmniOS, a couple retired servers and a few new bits to improve it's perf.
> 
> - HP DL360 G6 with dual Xeon 5540s, 80GB RAM
> - The onboard HP SAS is hosting the root pool on it's RAID 5 of SAS disks, not ideal but the card doesn't have an IT mode.
> - LSI 9208e for main storage
> - - Chenbro SAS expander in an Addonics 20 bay SATA shelf
> - - 5 x WD 6TB Red drives in a RAIDz3 pool
> - 4 x onboard GigE, LAG'd together
> - dual port QLogic 4GB FC card for later use with my VMWare farm
> 
> As I noted I was able to get a few new bits for the box, three Intel DC3600 400GB PCIe NVMe SSDs.  I figured I could use two for log in a mirror setup, and one for cache and have a lovely setup.
> 
> Initial testing without the NVMe drives setup with dd shows I can slam a sustained 300MB/s to the SATA pool when dumping to a file in one of my zfs repositories:
> 
> # dd if=/dev/zero of=bigfile bs=1M count=10240
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 37.3299 s, 288 MB/s
> 
> # dd if=/dev/zero of=bigfile bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 0.593213 s, 1.8 GB/s
> 
> For short bursts, the box caches nicely with the ram I was able to scrounge up.  I forgot I had one zfs set for gzip-9 compression and was very impressed to see it sustained 1.7 GB/s over the course of dumping 107 GB of zeros, nice!
> 
> Setting up a simple pool using one NVMe card with one volume and repeating the test on it I get:
> 
> # dd if=/dev/zero of=bigfile bs=1M count=10240
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 16.1904 s, 663 MB/s
> 
> Not quite the blazing performance I was expecting.  I was hoping they could sustain at least twice that.  If I make a zpool out of all three and bump my test to 53GB it sustains 1.1 GB/s, so there is a little performance scaling by spreading the work across all three but again no where near what I was anticipating.
> 
> I also did a raw write to one of the units after making sure it wasn't in use by any pools:
> # dd if=/dev/zero of=/dev/rdsk/c3t1d0 bs=1M count=10240
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 22.2461 s, 483 MB/s
> 
> If I get the system loaded enough, doing that results in transport errors being logged for the unit while I'm hammering it with dd.
> 
> Digging around I found some FreeBSD discussions where they observed their NVMe driver rolling back to legacy interrupt mode on systems with lots of cpu cores as they ran out of MSIx slots.  Given I've got 8 physical cores and I've got a lot of devices on the PCIe bus I don't know if that is a possibility here or not.  I've not poked at the driver source yet as to be honest I wouldn't know what I was looking for.
> 
> I also understand that the driver is pretty new to Illumos so I shouldn't expect it to be a rocket yet.  I just figured I'd share what I've observed so far to see if that matches what I should expect or if there is additional testing work I can do to help improve the driver's performance down the road.
> 
> Josh Coombs
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From phil.harman at gmail.com  Fri Apr  8 05:36:27 2016
From: phil.harman at gmail.com (Phil Harman)
Date: Fri, 8 Apr 2016 06:36:27 +0100
Subject: [OmniOS-discuss] NVMe Performance
In-Reply-To: <CACcUnf8G1DDZ_eC_nbX6xbPcpSdQ0AUAWBrhJWs_xk82r_PGwA@mail.gmail.com>
References: <CACcUnf8G1DDZ_eC_nbX6xbPcpSdQ0AUAWBrhJWs_xk82r_PGwA@mail.gmail.com>
Message-ID: <C85209C8-035E-4B95-9A15-AE6D8344E485@gmail.com>

Oh, the perils of dd microbenchmarks! You've already demonstrated the /dev/zero compression trap, but there's more...

It's not just compression you have to consider - e.g. something in your stack may be converting regions of zeros to holes (though this doesn't appear to be an issue for you this time around).

If I have no other option than dd, I prefer to use cached source files, pre-built from /dev/urandom (which is too slow to use directly). If dedup is on, I take even more care not to use simple copies of anything (unless I'm trying to force dedup to kick in).

You also need to consider latency vs throughput. Most devices work better with a queue depth greater than one. Don't forget that dd is single threaded (it doesn't even interleave its input and output), so use multiple instances of dd in parallel (hint: you may need to use the skip and/or seek options when working with single devices or files).

You should also experiment with different block sizes.

When using novel or niche devices with ZFS you also need to ensure that an appropriate ashift value is being applied (e.g. a lot of SSDs have an 8K page size). It's always good to check, in any case.

If you're reusing using a flash device that has been badly treated (e.g with badly aligned data), you'll probably want to ensure that it gets reinitialised (though exactly how depends on the device).

And it's always a good idea to validate your actual IO (operations, throughput, block size, queue depth, latency, alignment etc) with tools like iostat and dtrace.

If in doubt, hire an expert ;)

> On 8 Apr 2016, at 04:35, Josh Coombs <jcoombs at staff.gwi.net> wrote:
> 
> Hi all,
> 
> I just recently kitbashed a backup storage dump based on OmniOS, a couple retired servers and a few new bits to improve it's perf.
> 
> - HP DL360 G6 with dual Xeon 5540s, 80GB RAM
> - The onboard HP SAS is hosting the root pool on it's RAID 5 of SAS disks, not ideal but the card doesn't have an IT mode.
> - LSI 9208e for main storage
> - - Chenbro SAS expander in an Addonics 20 bay SATA shelf
> - - 5 x WD 6TB Red drives in a RAIDz3 pool
> - 4 x onboard GigE, LAG'd together
> - dual port QLogic 4GB FC card for later use with my VMWare farm
> 
> As I noted I was able to get a few new bits for the box, three Intel DC3600 400GB PCIe NVMe SSDs.  I figured I could use two for log in a mirror setup, and one for cache and have a lovely setup.
> 
> Initial testing without the NVMe drives setup with dd shows I can slam a sustained 300MB/s to the SATA pool when dumping to a file in one of my zfs repositories:
> 
> # dd if=/dev/zero of=bigfile bs=1M count=10240
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 37.3299 s, 288 MB/s
> 
> # dd if=/dev/zero of=bigfile bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 0.593213 s, 1.8 GB/s
> 
> For short bursts, the box caches nicely with the ram I was able to scrounge up.  I forgot I had one zfs set for gzip-9 compression and was very impressed to see it sustained 1.7 GB/s over the course of dumping 107 GB of zeros, nice!
> 
> Setting up a simple pool using one NVMe card with one volume and repeating the test on it I get:
> 
> # dd if=/dev/zero of=bigfile bs=1M count=10240
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 16.1904 s, 663 MB/s
> 
> Not quite the blazing performance I was expecting.  I was hoping they could sustain at least twice that.  If I make a zpool out of all three and bump my test to 53GB it sustains 1.1 GB/s, so there is a little performance scaling by spreading the work across all three but again no where near what I was anticipating.
> 
> I also did a raw write to one of the units after making sure it wasn't in use by any pools:
> # dd if=/dev/zero of=/dev/rdsk/c3t1d0 bs=1M count=10240
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes (11 GB) copied, 22.2461 s, 483 MB/s
> 
> If I get the system loaded enough, doing that results in transport errors being logged for the unit while I'm hammering it with dd.
> 
> Digging around I found some FreeBSD discussions where they observed their NVMe driver rolling back to legacy interrupt mode on systems with lots of cpu cores as they ran out of MSIx slots.  Given I've got 8 physical cores and I've got a lot of devices on the PCIe bus I don't know if that is a possibility here or not.  I've not poked at the driver source yet as to be honest I wouldn't know what I was looking for.
> 
> I also understand that the driver is pretty new to Illumos so I shouldn't expect it to be a rocket yet.  I just figured I'd share what I've observed so far to see if that matches what I should expect or if there is additional testing work I can do to help improve the driver's performance down the road.
> 
> Josh Coombs
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From jimklimov at cos.ru  Fri Apr  8 07:50:09 2016
From: jimklimov at cos.ru (Jim Klimov)
Date: Fri, 08 Apr 2016 09:50:09 +0200
Subject: [OmniOS-discuss] Caiman issues with certain timezones
In-Reply-To: <30FEDF6B-1A5B-46A1-9B31-0BB853D73C91@omniti.com>
References: <30FEDF6B-1A5B-46A1-9B31-0BB853D73C91@omniti.com>
Message-ID: <52DEF209-CBC1-4473-A4A2-067DFFB02C3B@cos.ru>

8 ?????? 2016??. 2:58:15 CEST, Dan McDonald <danmcd at omniti.com> ?????:
>A repeating problem has been with the ISO/USB "Caiman" installer
>barfing out upon selecting a timezone in Europe, Asia, or Africa.  All
>of these have timezones that use non-ASCII characters in one of their
>zone names.
>
>I've finally (and sorry for the delay) worked out a solution:  Have the
>installer run with LANG=en_US.UTF-8, so it can handle the characters. 
>The problem is, caiman's display doesn't cope with it very well, and
>draws letters where there used to be line/drawing characters.
>
>So my quick question to you all:  for r151018 (and backporting), do you
>prefer a nicer-looking installer that craps out if you select Africa,
>Europe, or Asia?  Or do you prefer a sketchier-looking one that works
>for all timezones out of the box?  I'm cutting the last 017 bloody with
>this, so you can try it out yourself when it shows up.
>
>Some people set their timezones in /etc/default/init AFTER
>installation, so I'm asking, instead of just making the decision.  I'm
>attaching a screenshot of the en_US.UTF-8 one.  Note the letter q where
>there should be a left-to-right bar:
>
>
>
>Dan
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

Certainly you can also iconv the timezone files back to ASCII to chop off the diacritics, as they were until a couple years ago when somebody decided UTF would be a good idea? ;) That's what my build scripts did when updating timezones on older solaris/linux setups.

And beware of the 'factory' (iirc) timezone that does not pass the project's own schema verification (too long to be an abbreviation) - so might be nice to trim or exclude it during a conversion pass.

As for the installer - you might convert it to use ASCII bars, pluses and minuses? Midnight Commander might be an inspiration, they often have to solve similar problems. Although "qqqq" lines happen to pop up in bad combinations of heuristics and locales.

HTH, Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From bfriesen at simple.dallas.tx.us  Fri Apr  8 13:56:55 2016
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 8 Apr 2016 08:56:55 -0500 (CDT)
Subject: [OmniOS-discuss] NVMe Performance
In-Reply-To: <C85209C8-035E-4B95-9A15-AE6D8344E485@gmail.com>
References: <CACcUnf8G1DDZ_eC_nbX6xbPcpSdQ0AUAWBrhJWs_xk82r_PGwA@mail.gmail.com>
	<C85209C8-035E-4B95-9A15-AE6D8344E485@gmail.com>
Message-ID: <alpine.GSO.2.20.1604080852540.23612@freddy.simplesystems.org>

On Fri, 8 Apr 2016, Phil Harman wrote:
>
> You also need to consider latency vs throughput. Most devices work better with a queue depth greater than one.

NVMe's claim to fame is its multi-threaded performance in that it is 
able to effectively read/write many blocks in parallel.  SATA and NVMe 
seem to be equivalent in performance for single-threaded sequential 
I/O.

It is often assumed that NVMe is ideal for a zfs intent log, but the 
required sequential nature of the intent log seems to not benefit from 
NVMe.

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

From cks at cs.toronto.edu  Fri Apr  8 14:58:22 2016
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Fri, 08 Apr 2016 10:58:22 -0400
Subject: [OmniOS-discuss] Caiman issues with certain timezones
In-Reply-To: Your message of Thu, 07 Apr 2016 20:58:15 -0400.
	<30FEDF6B-1A5B-46A1-9B31-0BB853D73C91@omniti.com>
Message-ID: <20160408145822.26FEF7A042E@apps0.cs.toronto.edu>

> So my quick question to you all: for r151018 (and backporting), do you
> prefer a nicer-looking installer that craps out if you select Africa,
> Europe, or Asia?  Or do you prefer a sketchier-looking one that works
> for all timezones out of the box?  I'm cutting the last 017 bloody
> with this, so you can try it out yourself when it shows up.

 In the picture you attached, it's fairly hard to follow what's going on
and what you should do. My gut feeling is that it would be relatively
unpleasant to use even for people familiar with the OmniOS installer.

 Of course, I'm not being affected by the timezone issue so it's easy
for me to prioritize being able to follow what the installer wants over
'not crashing when I try to install'. But that's my selfish bias.

	- cks

From danmcd at omniti.com  Fri Apr  8 20:15:58 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 8 Apr 2016 16:15:58 -0400
Subject: [OmniOS-discuss] Caiman issues with certain timezones
In-Reply-To: <30FEDF6B-1A5B-46A1-9B31-0BB853D73C91@omniti.com>
References: <30FEDF6B-1A5B-46A1-9B31-0BB853D73C91@omniti.com>
Message-ID: <3FDB4F9F-857A-4167-8F5B-461309A7C492@omniti.com>


> On Apr 7, 2016, at 8:58 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> So my quick question to you all:  for r151018 (and backporting), do you prefer a nicer-looking installer that craps out if you select Africa, Europe, or Asia?  Or do you prefer a sketchier-looking one that works for all timezones out of the box?  I'm cutting the last 017 bloody with this, so you can try it out yourself when it shows up.

So far my answers seem to be:

* Just iconv the source files!  My experience with that shows "C?te d'Ivoire" becomes "C?te d'Ivoire", which is also annoying.  OTOH, it appears that "country.tab" is the only one I really need to mess-with.

* It looks really ugly, but I'm not affected by foreign timezones so I'm not the best to ask.

IF I can get country.tab to show up ONLY on the ISO as iconv'ed, I might do that.

More opinions welcome, and help also welcome, as I don't know enough about distro_const to make this happen painlessly.

Dan


From jcoombs at staff.gwi.net  Fri Apr  8 20:35:38 2016
From: jcoombs at staff.gwi.net (Josh Coombs)
Date: Fri, 8 Apr 2016 16:35:38 -0400
Subject: [OmniOS-discuss] [developer] NVMe Performance
In-Reply-To: <57081193.9050603@multiplay.co.uk>
References: <CACcUnf_cZhQ7-iC7EWnsC0KHsoBgWPuXsRqk7vNiKqDgPH-sbw@mail.gmail.com>
	<5707BDCF.3020809@joyent.com>
	<CACcUnf-QD6H2jhWzv4R5dXZgVmW_=o+F_WrhpOHV3GmjrsEw7Q@mail.gmail.com>
	<CAAYoGd8q9d8=vGxsu3n_Pd=uR0g+WFW84=1rjuY67FxJF21GEA@mail.gmail.com>
	<57081193.9050603@multiplay.co.uk>
Message-ID: <CACcUnf8jUPBpy+OWcbuhxhn53iuhAm3FXc6KGiop1gLaOdTKUg@mail.gmail.com>

Did some digging myself trying to find out the block size of the DC P3600
line and found that intel only specs the 400GB unit at 500MB/s for
sequential writes, every other model in the DC line does 1000MB/s minimum.
So the numbers I'm seeing are in line with what they should be capable of.

So, I have to re-eval using them as log/cache devices as they potentially
are going to be a bottle neck.  At least now I know it's not the OS it's
the Hardware that's causing the numbers I saw.  Sorry for the false alarm.

Josh C

On Fri, Apr 8, 2016 at 4:16 PM, Steven Hartland <killing at multiplay.co.uk>
wrote:

> As a data point for you I just tried this on our NVMe box here and got:
> dd if=/dev/zero of=bigfile1 bs=1M count=10240
> 10240+0 records in
> 10240+0 records out
> 10737418240 bytes transferred in 4.088757 secs (2626083707 bytes/sec)
>
> So ~2.6GB/s setup is a RAID2Z on 6 x Intel SSDPE2MD400G4 running FreeBSD
> 10.2.
>
> During the test each disk does about 600-800MB/s
>
>     Regards
>     Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160408/98073275/attachment.html>

From alka at hfg-gmuend.de  Sun Apr 10 10:05:47 2016
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Sun, 10 Apr 2016 12:05:47 +0200
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk
 Controller Recommendations
In-Reply-To: <1459963432173.44935@usurf.usu.edu>
References: <1459963432173.44935@usurf.usu.edu>
Message-ID: <570A257B.9090807@hfg-gmuend.de>

Check this prebuild machine as a reference
http://www.supermicro.com/products/system/2U/2028/SSG-2028R-ACR24L.cfm

it comes with 3 x Avago 3008 HBAs in IT mode and 2 X 10 GbE Ethernet
This allows using Sata disks instead of SAS that you should use with 
Expander based solutions.

For database use, I would insist on SSDs like Intel S3610/S3710 or 
Samsung SM/PM 863 due their reliability with powerloss protection. 
Decide based on needs of write iops under load.Due the high iops (up to 
50k per SSD under constant load compared to 100 iops of a spindle), you 
do not need mirrors but can use a more cost effective n x Raid-Z2 config 
with 6 SSD per vdev.Add as much RAM as needed. (ex 128 GB up, the board 
can hold up to 2TB ECC what is more than your database). Use any Xeons, 
prefer frequency over number of cores.

With very fast SSDs in a pool, you can skip the extra Slog for sync 
write unless you use an NVMe like an Intel P3700 that is much faster 
than the Sata SSD.


Gea


Am 06.04.2016 um 19:23 schrieb Josh Barton:
> I am hoping to build a server with 15+ drives managed in ZFS that will run a 1TB+ postgres database.
>
>
> [NEEDS]
>
> 15-20 drive bays (ideally SFF/2.5")
>
> JBOD disk controller ideal for running ZFS
>
>
> In the past I purchased an HP Proliant DL380P Gen 8 but it had a "Smart Array Controller" that prevented us from hot swapping drives. It also seemed to haveless IO channels than might be good when running a box with 16 drives.
>
>
> What would you recommend for  either a complete server configuration or at the very least  a disk controller for running this environment?
>
>
> Thank you,
>
>
> Josh Barton
>
> Systems Admin/Developer
>
> USU Research Foundation
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From mir at miras.org  Sun Apr 10 10:23:32 2016
From: mir at miras.org (Michael Rasmussen)
Date: Sun, 10 Apr 2016 12:23:32 +0200
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk
 Controller Recommendations
In-Reply-To: <570A257B.9090807@hfg-gmuend.de>
References: <1459963432173.44935@usurf.usu.edu>
	<570A257B.9090807@hfg-gmuend.de>
Message-ID: <20160410122332.552956a2@sleipner.datanom.net>

On Sun, 10 Apr 2016 12:05:47 +0200
Guenther Alka <alka at hfg-gmuend.de> wrote:

> Use any Xeons, prefer frequency over number of cores.
Is that a general recommendation or only for this specific setup?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Deprive a mirror of its silver and even the Czar won't see his face.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160410/bad05f7e/attachment.bin>

From alka at hfg-gmuend.de  Sun Apr 10 12:41:07 2016
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Sun, 10 Apr 2016 14:41:07 +0200
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk
 Controller Recommendations
In-Reply-To: <20160410122332.552956a2@sleipner.datanom.net>
References: <1459963432173.44935@usurf.usu.edu>
	<570A257B.9090807@hfg-gmuend.de>
	<20160410122332.552956a2@sleipner.datanom.net>
Message-ID: <570A49E3.1010802@hfg-gmuend.de>

I would suggest this in general for pure filer
where you do not have that many parallel threads.
Processing a thread faster than the ability to run more simulatiously
seems more efficient.

For an ESXi box with a virtualized ZFS storage VM that runs
together with other VMs, this is different. In such a situation I would
prefer more cores over a higher frequency for a similar price.



Am 10.04.2016 um 12:23 schrieb Michael Rasmussen:
> On Sun, 10 Apr 2016 12:05:47 +0200
> Guenther Alka <alka at hfg-gmuend.de> wrote:
>
>> Use any Xeons, prefer frequency over number of cores.
> Is that a general recommendation or only for this specific setup?
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160410/59f9ae65/attachment.html>

From mir at miras.org  Sun Apr 10 15:06:01 2016
From: mir at miras.org (Michael Rasmussen)
Date: Sun, 10 Apr 2016 17:06:01 +0200
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk
 Controller Recommendations
In-Reply-To: <570A49E3.1010802@hfg-gmuend.de>
References: <1459963432173.44935@usurf.usu.edu>
	<570A257B.9090807@hfg-gmuend.de>
	<20160410122332.552956a2@sleipner.datanom.net>
	<570A49E3.1010802@hfg-gmuend.de>
Message-ID: <20160410170601.2910c6d2@sleipner.datanom.net>

On Sun, 10 Apr 2016 14:41:07 +0200
Guenther Alka <alka at hfg-gmuend.de> wrote:

> I would suggest this in general for pure filer
> where you do not have that many parallel threads.
> Processing a thread faster than the ability to run more simulatiously
> seems more efficient.
> 
> For an ESXi box with a virtualized ZFS storage VM that runs
> together with other VMs, this is different. In such a situation I would
> prefer more cores over a higher frequency for a similar price.
> 
This is also my impression and also in accordance with wmware
recommendations.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Hi Jimbo.  Dennis.  Really appreciate the help on the income tax.  You
wanna help on the audit now?
		-- "The Rockford Files"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160410/cb4c0cba/attachment-0001.bin>

From richard.elling at richardelling.com  Mon Apr 11 00:02:24 2016
From: richard.elling at richardelling.com (Richard Elling)
Date: Sun, 10 Apr 2016 17:02:24 -0700
Subject: [OmniOS-discuss] Optimal Server Configuration or Disk
	Controller Recommendations
In-Reply-To: <570A257B.9090807@hfg-gmuend.de>
References: <1459963432173.44935@usurf.usu.edu>
	<570A257B.9090807@hfg-gmuend.de>
Message-ID: <729B065C-A661-495C-AB60-956157B07D6E@RichardElling.com>


> On Apr 10, 2016, at 3:05 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:
> 
> Check this prebuild machine as a reference
> http://www.supermicro.com/products/system/2U/2028/SSG-2028R-ACR24L.cfm
> 
> it comes with 3 x Avago 3008 HBAs in IT mode and 2 X 10 GbE Ethernet

FYI, Avago bought Broadcom, then changed their name to Broadcom.
Qlogic and Marvell are seeking acquirers. The number of suppliers of chipsets 
will continue to dwindle.
 ? richard

> This allows using Sata disks instead of SAS that you should use with Expander based solutions.
> 
> For database use, I would insist on SSDs like Intel S3610/S3710 or Samsung SM/PM 863 due their reliability with powerloss protection. Decide based on needs of write iops under load.Due the high iops (up to 50k per SSD under constant load compared to 100 iops of a spindle), you do not need mirrors but can use a more cost effective n x Raid-Z2 config with 6 SSD per vdev.Add as much RAM as needed. (ex 128 GB up, the board can hold up to 2TB ECC what is more than your database). Use any Xeons, prefer frequency over number of cores.
> 
> With very fast SSDs in a pool, you can skip the extra Slog for sync write unless you use an NVMe like an Intel P3700 that is much faster than the Sata SSD.
> 
> 
> Gea
> 
> 
> Am 06.04.2016 um 19:23 schrieb Josh Barton:
>> I am hoping to build a server with 15+ drives managed in ZFS that will run a 1TB+ postgres database.
>> 
>> 
>> [NEEDS]
>> 
>> 15-20 drive bays (ideally SFF/2.5")
>> 
>> JBOD disk controller ideal for running ZFS
>> 
>> 
>> In the past I purchased an HP Proliant DL380P Gen 8 but it had a "Smart Array Controller" that prevented us from hot swapping drives. It also seemed to haveless IO channels than might be good when running a box with 16 drives.
>> 
>> 
>> What would you recommend for  either a complete server configuration or at the very least  a disk controller for running this environment?
>> 
>> 
>> Thank you,
>> 
>> 
>> Josh Barton
>> 
>> Systems Admin/Developer
>> 
>> USU Research Foundation
>> _______________________________________________
>> 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

--

Richard.Elling at RichardElling.com
+1-760-896-4422



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160410/14203ac2/attachment.html>

From geoffn at gnaa.net  Mon Apr 11 00:54:58 2016
From: geoffn at gnaa.net (Geoff Nordli)
Date: Sun, 10 Apr 2016 17:54:58 -0700
Subject: [OmniOS-discuss] NVMe interface reliable?
Message-ID: <570AF5E2.7040909@gnaa.net>

Is the NVMe interface reliable option now?

thanks,

Geoff



From eric.sproul at circonus.com  Mon Apr 11 16:31:18 2016
From: eric.sproul at circonus.com (Eric Sproul)
Date: Mon, 11 Apr 2016 12:31:18 -0400
Subject: [OmniOS-discuss] NVMe interface reliable?
In-Reply-To: <570AF5E2.7040909@gnaa.net>
References: <570AF5E2.7040909@gnaa.net>
Message-ID: <CAO8hXRAwOA_HphLm55tfpk8nex7J8uTwttnk9+iQRS-ZmiDMEQ@mail.gmail.com>

On Sun, Apr 10, 2016 at 8:54 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
> Is the NVMe interface reliable option now?

I've tested it, and it works great.  However, a possible shortcoming
is that there is currently no hot-swap support for nvme(7D) devices.
This isn't an issue if you're doing the PCIe-card form-factor, as
those generally don't get hot-swapped anyway, but is an issue for 2.5"
disk form-factor devices.  These are physically capable of being
hot-swapped (they use the same SFF connectors as SAS/SATA), and at
least Intel says that their drives are "suprise-hot-plug-ready" [1].
At this time, for any NVMe deployment, plan to shut down the system to
perform drive replacements.

That said, it sounds like a lot of folks are deploying these as cache
and log devices, which is less critical for replacing than primary
storage.

It's unknown at this time whether nvme(7D) will gain hot-plug support.
I'm not aware of anyone working on it (including the Nexenta engineer
who wrote the current driver.)

Eric

[1] http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/333596-hot-plug-capability-nvme-ssds-paper.pdf

From pasztor at sagv5.gyakg.u-szeged.hu  Mon Apr 11 17:11:18 2016
From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=)
Date: Mon, 11 Apr 2016 19:11:18 +0200
Subject: [OmniOS-discuss] Introducing io-lx -- an attempt to port LX
	Zones to OmniOS
In-Reply-To: <49C794E2-9B2F-4D6F-9240-13A946651243@omniti.com>
References: <49C794E2-9B2F-4D6F-9240-13A946651243@omniti.com>
Message-ID: <20160411171118.GA17187@linux.gyakg.u-szeged.hu>

Hi,

"Dan McDonald" <danmcd at omniti.com> ?rta 2016-03-07 21:47-kor:
> After I'm comfortable with no ipkg/lipkg regressions, I will need to spend some design time figuring out how LX zones will look on OmniOS.  I will not be porting vmadm(1M) over from SmartOS, so I need to think about how LX will fit in with traditional zone tools.  I may discover other problems, but until I start the '018 process, and immediately after '018 ships, I will need to ensure no ipkg/lipkg regressions first and foremost.
> 
> It's not much, but it's a start.

Is there any news about this io-lx project?
Will that get into 018?
Can I test it somewhere already? eg. in a fresh 017?
Or should I ONU to oi-lx? Is there a howto online how should I do that?

Cheers,
Gyu

From danmcd at omniti.com  Mon Apr 11 17:51:12 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 11 Apr 2016 13:51:12 -0400
Subject: [OmniOS-discuss] Introducing io-lx -- an attempt to port LX
	Zones to OmniOS
In-Reply-To: <20160411171118.GA17187@linux.gyakg.u-szeged.hu>
References: <49C794E2-9B2F-4D6F-9240-13A946651243@omniti.com>
	<20160411171118.GA17187@linux.gyakg.u-szeged.hu>
Message-ID: <5E35A80C-400C-4799-A7C4-C8C7657F7FB4@omniti.com>


> On Apr 11, 2016, at 1:11 PM, P?SZTOR Gy?rgy <pasztor at linux.gyakg.u-szeged.hu> wrote:
> 
> Hi,
> 
> "Dan McDonald" <danmcd at omniti.com> ?rta 2016-03-07 21:47-kor:
>> After I'm comfortable with no ipkg/lipkg regressions, I will need to spend some design time figuring out how LX zones will look on OmniOS.  I will not be porting vmadm(1M) over from SmartOS, so I need to think about how LX will fit in with traditional zone tools.  I may discover other problems, but until I start the '018 process, and immediately after '018 ships, I will need to ensure no ipkg/lipkg regressions first and foremost.
>> 
>> It's not much, but it's a start.
> 
> Is there any news about this io-lx project?

It's been on hold while the 018 ramp-up occurs.

> Will that get into 018?

NO!  We're not close to ready.

> Can I test it somewhere already? eg. in a fresh 017?

You can take the io-lx repo and compile it, and then ONU.  I can tell you that ipkg & lipkg zones are broken currently, so there's a LOT of work.

Furthermore, there's been some joyent upstreaming since last I froze the public io-lx repo, so I may need to start over with a fresh pull of the Joyent bits.

> Or should I ONU to oi-lx? Is there a howto online how should I do that?

You can ONU to io-lx like you ONU to any other illumos-{gate,omnios} build.  Same warnings for env files, etc. etc.

Dan


From geoffn at gnaa.net  Mon Apr 11 19:05:29 2016
From: geoffn at gnaa.net (Geoff Nordli)
Date: Mon, 11 Apr 2016 12:05:29 -0700
Subject: [OmniOS-discuss] NVMe interface reliable?
In-Reply-To: <CAO8hXRAwOA_HphLm55tfpk8nex7J8uTwttnk9+iQRS-ZmiDMEQ@mail.gmail.com>
References: <570AF5E2.7040909@gnaa.net>
	<CAO8hXRAwOA_HphLm55tfpk8nex7J8uTwttnk9+iQRS-ZmiDMEQ@mail.gmail.com>
Message-ID: <570BF579.5090400@gnaa.net>

On 16-04-11 09:31 AM, Eric Sproul wrote:
> On Sun, Apr 10, 2016 at 8:54 PM, Geoff Nordli <geoffn at gnaa.net> wrote:
>> Is the NVMe interface reliable option now?
> I've tested it, and it works great.  However, a possible shortcoming
> is that there is currently no hot-swap support for nvme(7D) devices.
> This isn't an issue if you're doing the PCIe-card form-factor, as
> those generally don't get hot-swapped anyway, but is an issue for 2.5"
> disk form-factor devices.  These are physically capable of being
> hot-swapped (they use the same SFF connectors as SAS/SATA), and at
> least Intel says that their drives are "suprise-hot-plug-ready" [1].
> At this time, for any NVMe deployment, plan to shut down the system to
> perform drive replacements.
>
> That said, it sounds like a lot of folks are deploying these as cache
> and log devices, which is less critical for replacing than primary
> storage.
>
> It's unknown at this time whether nvme(7D) will gain hot-plug support.
> I'm not aware of anyone working on it (including the Nexenta engineer
> who wrote the current driver.)
>
> Eric
>
> [1] http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/333596-hot-plug-capability-nvme-ssds-paper.pdf

Thanks Eric.

On a mailing list people don't post their success that often so it takes 
a while before you get enough feedback before you trust it.





From bfriesen at simple.dallas.tx.us  Mon Apr 11 19:15:32 2016
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Mon, 11 Apr 2016 14:15:32 -0500 (CDT)
Subject: [OmniOS-discuss] NVMe interface reliable?
In-Reply-To: <570BF579.5090400@gnaa.net>
References: <570AF5E2.7040909@gnaa.net>
	<CAO8hXRAwOA_HphLm55tfpk8nex7J8uTwttnk9+iQRS-ZmiDMEQ@mail.gmail.com>
	<570BF579.5090400@gnaa.net>
Message-ID: <alpine.GSO.2.20.1604111411020.21740@freddy.simplesystems.org>

On Mon, 11 Apr 2016, Geoff Nordli wrote:
>
> On a mailing list people don't post their success that often so it takes a 
> while before you get enough feedback before you trust it.

There have been some postings regarding problems.  The driver was 
developed for NVMe 1.0 and possibly only tested with Intel products. 
At least one user found that the driver had issues (checksum/fail 
issues) with a Samsung drive compliant with NVMe 1.1.

Check the illumos 'developer' and illumos 'discuss' lists.

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

From danmcd at omniti.com  Mon Apr 11 19:45:18 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 11 Apr 2016 15:45:18 -0400
Subject: [OmniOS-discuss] Caiman issues with certain timezones
In-Reply-To: <3FDB4F9F-857A-4167-8F5B-461309A7C492@omniti.com>
References: <30FEDF6B-1A5B-46A1-9B31-0BB853D73C91@omniti.com>
	<3FDB4F9F-857A-4167-8F5B-461309A7C492@omniti.com>
Message-ID: <AB8A65A5-2E58-4021-9C49-96F861CC44A2@omniti.com>


> On Apr 8, 2016, at 4:15 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> * It looks really ugly, but I'm not affected by foreign timezones so I'm not the best to ask.

Okay, I've fixed the problem.  It's ugly, but on the inside (specifically a country.tab hack that only fresh installs will notice, and is fixable by "pkg fix" or "pkg update").

New (pre-018) bloody bits will be out tonight, stay tuned.

Dan


From geoffn at gnaa.net  Mon Apr 11 21:11:47 2016
From: geoffn at gnaa.net (Geoff Nordli)
Date: Mon, 11 Apr 2016 14:11:47 -0700
Subject: [OmniOS-discuss] NVMe interface reliable?
In-Reply-To: <alpine.GSO.2.20.1604111411020.21740@freddy.simplesystems.org>
References: <570AF5E2.7040909@gnaa.net>
	<CAO8hXRAwOA_HphLm55tfpk8nex7J8uTwttnk9+iQRS-ZmiDMEQ@mail.gmail.com>
	<570BF579.5090400@gnaa.net>
	<alpine.GSO.2.20.1604111411020.21740@freddy.simplesystems.org>
Message-ID: <570C1313.5070103@gnaa.net>

On 16-04-11 12:15 PM, Bob Friesenhahn wrote:
> On Mon, 11 Apr 2016, Geoff Nordli wrote:
>>
>> On a mailing list people don't post their success that often so it 
>> takes a while before you get enough feedback before you trust it.
>
> There have been some postings regarding problems.  The driver was 
> developed for NVMe 1.0 and possibly only tested with Intel products. 
> At least one user found that the driver had issues (checksum/fail 
> issues) with a Samsung drive compliant with NVMe 1.1.
>
> Check the illumos 'developer' and illumos 'discuss' lists.
>
> Bob

Hi Bob.

I saw those messages.  I also see some people posting configs with the 
NVMe drives.   So people seem to be using them, but people generally 
don't post about their success, just failures.




From danmcd at omniti.com  Wed Apr 13 04:52:42 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 13 Apr 2016 00:52:42 -0400
Subject: [OmniOS-discuss] Pre-018 bloody now out
Message-ID: <D1219F69-081F-4A19-968B-12EABE90ED3A@omniti.com>

In anticipation of r151018's release, the bloody that will essentially comprise r151018 is now available for "pkg update" and for ISO/USB/Kayak download from the OmniOS Installation page:

	http://omnios.omniti.com/wiki.php/Installation

This update includes all of the non-illumos OmniOS package updates (of which there are a lot), and catching up to illumos-gate commit 62dadd6, which includes the vmxnet3s driver, some OmniOS-customer-reported ZFS fixes, and other small things.

I'll now be preparing r151018 for shipping.  This bloody is essentially a non-signed preview of it.

Thanks,
Dan


From omnios at citrus-it.net  Wed Apr 13 11:44:25 2016
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Wed, 13 Apr 2016 11:44:25 +0000 (UTC)
Subject: [OmniOS-discuss] Pre-018 bloody now out
In-Reply-To: <D1219F69-081F-4A19-968B-12EABE90ED3A@omniti.com>
References: <D1219F69-081F-4A19-968B-12EABE90ED3A@omniti.com>
Message-ID: <alpine.GSO.2.00.1604131133560.15313@erncre.pvgehf-vg.arg>


On Wed, 13 Apr 2016, Dan McDonald wrote:

; In anticipation of r151018's release, the bloody that will essentially comprise r151018 is now available for "pkg update" and for ISO/USB/Kayak download from the OmniOS Installation page:
;
; 	http://omnios.omniti.com/wiki.php/Installation

Thanks Dan, I've just upgraded one of our test servers to this with no
problems using the following process. I'll do some more testing but it
looks good so far. There are no non-global zones on this server however.

  beadm create bloody
  mkdir /tmp/bloody
  beadm mount bloody /tmp/bloody
  pkg -R /tmp/bloody set-publisher \
        -G http://pkg.omniti.com/omnios/r151016/ \
        -g http://pkg.omniti.com/omnios/bloody/ \
	--unset-property signature-policy \
	omnios
  pkg -R /tmp/bloody update
  beadm umount bloody
  beadm activate bloody

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


From omnios at citrus-it.net  Wed Apr 13 12:09:57 2016
From: omnios at citrus-it.net (Andy Fiddaman)
Date: Wed, 13 Apr 2016 12:09:57 +0000 (UTC)
Subject: [OmniOS-discuss] Pre-018 bloody now out
In-Reply-To: <alpine.GSO.2.00.1604131133560.15313@erncre.pvgehf-vg.arg>
References: <D1219F69-081F-4A19-968B-12EABE90ED3A@omniti.com>
	<alpine.GSO.2.00.1604131133560.15313@erncre.pvgehf-vg.arg>
Message-ID: <alpine.GSO.2.00.1604131208310.18900@erncre.pvgehf-vg.arg>


Just one oddity:

# pkg update
No updates available for this image.
zsh: exit 4     pkg update
# pkg list -u
NAME (PUBLISHER)                  VERSION                    IFO
developer/gnu-binutils            2.25-0.151017              i--


On Wed, 13 Apr 2016, Andy Fiddaman wrote:

;
; On Wed, 13 Apr 2016, Dan McDonald wrote:
;
; ; In anticipation of r151018's release, the bloody that will essentially comprise r151018 is now available for "pkg update" and for ISO/USB/Kayak download from the OmniOS Installation page:
; ;
; ; 	http://omnios.omniti.com/wiki.php/Installation
;
; Thanks Dan, I've just upgraded one of our test servers to this with no
; problems using the following process. I'll do some more testing but it
; looks good so far. There are no non-global zones on this server however.
;
;   beadm create bloody
;   mkdir /tmp/bloody
;   beadm mount bloody /tmp/bloody
;   pkg -R /tmp/bloody set-publisher \
;         -G http://pkg.omniti.com/omnios/r151016/ \
;         -g http://pkg.omniti.com/omnios/bloody/ \
; 	--unset-property signature-policy \
; 	omnios
;   pkg -R /tmp/bloody update
;   beadm umount bloody
;   beadm activate bloody
;
; Andy
;
-- 
Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk
Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ
Registered in England and Wales | Company number 4899123


From danmcd at omniti.com  Wed Apr 13 13:52:48 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 13 Apr 2016 09:52:48 -0400
Subject: [OmniOS-discuss] Pre-018 bloody now out
In-Reply-To: <alpine.GSO.2.00.1604131208310.18900@erncre.pvgehf-vg.arg>
References: <D1219F69-081F-4A19-968B-12EABE90ED3A@omniti.com>
	<alpine.GSO.2.00.1604131133560.15313@erncre.pvgehf-vg.arg>
	<alpine.GSO.2.00.1604131208310.18900@erncre.pvgehf-vg.arg>
Message-ID: <E529F45A-13C7-4805-A4AA-EA6DE9C6B7D4@omniti.com>


> On Apr 13, 2016, at 8:09 AM, Andy Fiddaman <omnios at citrus-it.net> wrote:
> 
> 
> Just one oddity:
> 
> # pkg update
> No updates available for this image.
> zsh: exit 4     pkg update
> # pkg list -u
> NAME (PUBLISHER)                  VERSION                    IFO
> developer/gnu-binutils            2.25-0.151017              i--

Yeah... that is weird.  Weirder still, if you invoke -v they're actually the same version.

# pkg update
No updates available for this image.
Planning linked: 0/1 done; 1 working: zone:tz2
Linked image 'zone:tz2' output:
| No updates available for this image. (zone:tz2)
`
Planning linked: 1/1 done
# pkg list -v gnu-binutils
FMRI                                                                         IFO
pkg://omnios/developer/gnu-binutils at 2.25-0.151017:20160211T235935Z           i--
# pkg list -uv
FMRI                                                                         IFO
pkg://omnios/developer/gnu-binutils at 2.25-0.151017:20160211T235935Z           i--
# 

I wonder if this is a "pkgrepo rebuild" or "pkgrepo refresh" problem on our end.  I hadn't done that.

Anyway, thanks for the warning.  Luckily, the package you have IS the latest... just not sure why -u thinks you need it again.

Dan


From matej at zunaj.si  Wed Apr 13 14:07:13 2016
From: matej at zunaj.si (=?utf-8?Q?Matej_=C5=BDerovnik?=)
Date: Wed, 13 Apr 2016 16:07:13 +0200
Subject: [OmniOS-discuss] [discuss] COMSTAR hanging
In-Reply-To: <867309FA36CA349E.0C1F93E3-1045-4C65-9084-870490D3BF34@mail.outlook.com>
References: <0C7A62FA-5D1C-42A4-B171-FAA3AC34AC3D@4amlunch.net>
	<CAAYoGd_dU4E48PikupiD6TrV85urhHiXGx692mA8E=jAYMia-A@mail.gmail.com>
	<97F9575A-C086-4862-B5CA-BA2893E48C08@4amlunch.net>
	<A16F5BDE-472C-4D8D-A654-0FB5A84A9B15@zunaj.si>
	<6D6F42AE-611E-4C7C-88AE-23543CA66DA4@4amlunch.net>
	<B99F52AF-6272-47FE-B4E6-F0DAB6766E1C@omniti.com>
	<2F515DC7-7803-4814-99D1-06AE3E3A196C@4amlunch.net>
	<52C14C1A-80F1-4B5D-AE7D-9999AB1B758F@omniti.com>
	<D2B5448A.36011D%dave-lists@pooserville.com>
	<90EFFEAE-2967-49C7-80F1-AB82E95CB52E@zunaj.si>
	<11A7C643-506B-441D-B320-79C75B8EAFCE@4amlunch.net>
	<65DC5816D4BEE043885A89FD54E273FC6CF6BC33@MAIL101.Ellipseinc.com>
	<FCB546AB-F8CC-4CAC-803C-DB931B2FAE99@4amlunch.net>
	<D7A63329-1098-4B06-85FE-FB175E0A6B1A@zunaj.si>
	<CF9A59F1-58EB-4533-B06B-F5A1D4393536@4amlunch.net>
	<FDBF00AC-6865-49EE-B1BF-75E9D9264BF2@4amlunch.net>
	<867309FA36CA349E.2808DEE6-8CB2-4717-B123-26F8E9BF10C5@mail.outlook.com>
	<867309FA36CA349E.A61AF59B-1738-47A9-8918-7281B3A691CA@mail.outlook.com>
	<ECF358AE-ABC9-4F43-819B-1EC88BCDDF23@4amlunch.net>
	<867309FA36CA349E.0C1F93E3-1045-4C65-9084-870490D3BF34@mail.outlook.com>
Message-ID: <A2FA4C34-5DA9-4922-812A-C4B312BAAA1D@zunaj.si>

Hey there,

we were having the same problems with an old storage with SATA drives and a new one with SAS drives and all HW from Nexenta HCL list, so everything should work. Yet iSCSI target died every 2-6 days nonetheless. With the help of memory dump and Dan, it looks like, we managed to solve the issue.

In my case, one of the threads was waiting for memory to free. I remembered I hadn?t set max ARC sizeon my system, so it was possible for ARC to eat all my free memory and could not release it quick enough. After settings max ARC size, everything works for the last month. I still can?t say if this really fixed the problem or not, but so far so good:)

Matej


> On 13 Jan 2016, at 05:52, John Barfield <john.barfield at bissinc.com> wrote:
> 
> Oh I didnt catch that detail. 
> 
> Okay well nevermind :)
> 
> 
> Sent from Outlook Mobile <https://aka.ms/qtex0l>
> 
> 
> 
> On Tue, Jan 12, 2016 at 8:21 PM -0800, "Brian Hechinger" <wonko at 4amlunch.net <mailto:wonko at 4amlunch.net>> wrote:
> 
> In my case the SATA disks aren?t on the 1068E.
> 
> -brian
> 
>> On Jan 12, 2016, at 11:19 PM, John Barfield <john.barfield at bissinc.com <mailto:john.barfield at bissinc.com>> wrote:
>> 
>> BTW I left off that it has the same LSI controller chipset
>> 
>> Sent from Outlook Mobile <https://aka.ms/qtex0l>
>> _____________________________
>> From: John Barfield <john.barfield at bissinc.com <mailto:john.barfield at bissinc.com>>
>> Sent: Tuesday, January 12, 2016 10:17 PM
>> Subject: Re: [OmniOS-discuss] [discuss] COMSTAR hanging
>> To: <discuss at lists.illumos.org <mailto:discuss at lists.illumos.org>>, omnios-discuss <omnios-discuss at lists.omniti.com <mailto:omnios-discuss at lists.omniti.com>>
>> 
>> 
>> My input may or may not be valid but Im going to throw it out there anyway :)
>> 
>> do you have any Mpt disconnect errors in /var/adm/messages? 
>> 
>> Also do you have smartmontools installed? 
>> 
>> I ran into similiar issues just booting a sunfire x4540 recently off of OmniOS live, i/o would just hang while probing device nodes.
>> 
>> I found the drive that was acting up and pulled it. 
>> 
>> All of a sudden everything miraculously worked amazing. 
>> 
>> I compiled smartmontools after I got it to boot and found 10 drives out of 48 with bad sectors in prefail state.
>> 
>> I dont know if this happens with SAS drives or not but Im using SATA and saw this was a common issue in old opensolaris threads. 
>> 
>> -barfield 
>> 
>> Sent from Outlook Mobile <https://aka.ms/qtex0l>
>> 
>> 
>> 
>> On Tue, Jan 12, 2016 at 8:08 PM -0800, "Brian Hechinger" <wonko at 4amlunch.net <mailto:wonko at 4amlunch.net>> wrote: 
>> 
>> In the meantime I?ve removed the SLOG and L2ARC just in case. I don?t think that?s it though. At least will have some sort of data point to work with here. :) 
>> 
>> -brian 
>> 
>> > On Jan 12, 2016, at 10:55 PM, Brian Hechinger <wonko at 4amlunch.net <mailto:wonko at 4amlunch.net>> wrote: 
>> > 
>> > Ok, it has happened. 
>> > 
>> > Checking this here, the pool seems to be fine. I can read and write files. 
>> > 
>> > except ?zpool status? is now currently hanging. I can still read/write from the pool, however. 
>> > 
>> > I can telnet to port 3260, but restarting target services has hung. 
>> > 
>> > root at basket1:/tank/Share# svcs -a | grep stmf 
>> > online         Jan_05   svc:/system/stmf:default 
>> > root at basket1:/tank/Share# svcs -a | grep target 
>> > disabled       Jan_05   svc:/system/fcoe_target:default 
>> > online         Jan_05   svc:/network/iscsi/target:default 
>> > online         Jan_05   svc:/system/ibsrp/target:default 
>> > root at basket1:/tank/Share# svcadm restart /system/ibsrp/target 
>> > root at basket1:/tank/Share# svcadm restart /network/iscsi/target 
>> > root at basket1:/tank/Share# svcadm restart /system/stmf 
>> > root at basket1:/tank/Share# svcs -a | grep target 
>> > disabled       Jan_05   svc:/system/fcoe_target:default 
>> > online*        22:43:03 svc:/system/ibsrp/target:default 
>> > online*        22:43:13 svc:/network/iscsi/target:default 
>> > root at basket1:/tank/Share# svcs -a | grep stmf 
>> > online*        22:43:18 svc:/system/stmf:default 
>> > root at basket1:/tank/Share# 
>> > 
>> > I?m doing a crash dump reboot. I?ll post the output somewhere. 
>> > 
>> > The output of echo '$<threadlist' | mdb -k is attached. 
>> > 
>> > <threadlist.out> 
>> > 
>> >> On Jan 8, 2016, at 3:11 PM, Matej Zerovnik <matej at zunaj.si <mailto:matej at zunaj.si>> wrote: 
>> >> 
>> >> Is the pool usable during comstar hang? 
>> >> Can you write and read from the pool (test both, in my case, when pool froze, I wasn?t able to write to the pool, but I could read). 
>> >> 
>> >> Again, this might not be connected with Comstar, but in my case, Comstar and pool hang were exchanging. 
>> >> 
>> >> Matej 
>> >> 
>> >>> On 08 Jan 2016, at 20:11, Brian Hechinger <wonko at 4amlunch.net <mailto:wonko at 4amlunch.net>> wrote: 
>> >>> 
>> >>> Yeah, I?m using the 1068E to boot from (this has been supported since before Illumos) but that doesn?t have anything accessed by COMSTAR. 
>> >>> 
>> >>> It?s the ICH10R SATA that hosts the disks that COMSTAR shares out space from. 
>> >>> 
>> >>> -brian 
>> >>> 
>> >>>> On Jan 8, 2016, at 1:31 PM, Richard Jahnel <rjahnel at ellipseinc.com <mailto:rjahnel at ellipseinc.com>> wrote: 
>> >>>> 
>> >>>> First off, love SuperMicro good choice IMHO. 
>> >>>> 
>> >>>> This board has two on board controllers. 
>> >>>> 
>> >>>> LSI SAS1068E (not 100% sure there are working illumos drivers for this one) 
>> >>>> 
>> >>>> And 
>> >>>> 
>> >>>> Intel ICH10R SATA (So I'm guessing your using this one.) 
>> >>>> 
>> >>>> -----Original Message----- 
>> >>>> From: OmniOS-discuss [ mailto:omnios-discuss-bounces at lists.omniti.com <mailto:omnios-discuss-bounces at lists.omniti.com>] On Behalf Of Brian Hechinger 
>> >>>> Sent: Friday, January 08, 2016 12:16 PM 
>> >>>> To: Matej Zerovnik <matej at zunaj.si <mailto:matej at zunaj.si>> 
>> >>>> Cc: omnios-discuss <omnios-discuss at lists.omniti.com <mailto:omnios-discuss at lists.omniti.com>> 
>> >>>> Subject: Re: [OmniOS-discuss] [discuss] COMSTAR hanging 
>> >>>> 
>> >>>> 
>> >>>>> Which controller exactly do you have? 
>> >>>> 
>> >>>> Whatever ACHI stuff is built into the motherboard. Motherboard is X8DTL-3F. 
>> >>>> 
>> >>>>> Do you know firmware version? 
>> >>>> 
>> >>>> I?m assuming this is linked to the BIOS version? 
>> >>>> 
>> >>>>> Which hard drives? 
>> >>>> 
>> >>>> Hitachi-HUA723030ALA640-MKAOAA50-2.73TB 
>> >>>> 
>> >>>>> It might not tell much, but it?s good to have as much information as possible. 
>> >>>>> 
>> >>>>> When comstar hangs, can you telnet to the iSCSI port? 
>> >>>>> What does svcs says, is the service running? 
>> >>>>> What happens in you try to restart it? 
>> >>>>> How do you restart it? 
>> >>>> 
>> >>>> I?ll try all these things next time. 
>> >>>> 
>> >>>>> In my case, svcs reported service running, but when I tried to telnet, there was no connection as well as there was no listening port opened when checking with 'netstat -an'. If I tried to restart target and stmf service, but stmf service got stucked in online* state and would not start. Reboot was the only solution in my case, but as I said, latest 014 release is working OK (but then again, load got reduced). 
>> >>>> 
>> >>>> All good info. Thanks! 
>> >>>> 
>> >>>> -brian 
>> >>>> 
>> >>>>> 
>> >>>>> Matej 
>> >>>>> 
>> >>>>>> On 08 Jan 2016, at 17:50, Dave Pooser <dave-oo at pooserville.com <mailto:dave-oo at pooserville.com>> wrote: 
>> >>>>>> 
>> >>>>>>>> On Jan 8, 2016, at 11:22 AM, Brian Hechinger <wonko at 4amlunch.net <mailto:wonko at 4amlunch.net>> wrote: 
>> >>>>>>>> 
>> >>>>>>>> No, ZFS raid10 
>> >>>>>>> 
>> >>>>>>> Saw the HW-RAID term, and got concerned.  That's what, raidz2 in ZFS-ese? 
>> >>>>>> 
>> >>>>>> It's a zpool with multiple mirror vdevs. 
>> >>>>>> 
>> >>>>>> -- 
>> >>>>>> Dave Pooser 
>> >>>>>> Cat-Herder-in-Chief, Pooserville.com <http://pooserville.com/> 
>> >>>>>> 
>> >>>>>> 
>> >>>>>> _______________________________________________ 
>> >>>>>> OmniOS-discuss mailing list 
>> >>>>>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com> 
>> >>>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss> 
>> >>>>> 
>> >>>>> _______________________________________________ 
>> >>>>> OmniOS-discuss mailing list 
>> >>>>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com> 
>> >>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss> 
>> >>>> 
>> >>>> _______________________________________________ 
>> >>>> OmniOS-discuss mailing list 
>> >>>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com> 
>> >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss> 
>> >>> 
>> >> 
>> > 
>> 
>> 
>> 
>> http://www.listbox.com <http://www.listbox.com/> 
>> illumos-discuss | Archives <https://www.listbox.com/member/archive/182180/=now>  <https://www.listbox.com/member/archive/rss/182180/26677440-40b316d8> | Modify <https://www.listbox.com/member/?member_id=26677440&id_secret=26677440-8fd7f4fe> Your Subscription	 <http://www.listbox.com/>
>> 
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160413/7f57851b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3468 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160413/7f57851b/attachment-0001.bin>

From gordon.w.ross at gmail.com  Wed Apr 13 14:12:33 2016
From: gordon.w.ross at gmail.com (Gordon Ross)
Date: Wed, 13 Apr 2016 10:12:33 -0400
Subject: [OmniOS-discuss] Badlock -- illumos Native SMB server is not
	affected
Message-ID: <CAD0Ztp1PtX9pPL5scCMn63ZHZRrtKxkw8PvypFWEd6mGy4MQOQ@mail.gmail.com>

Some of you may have heard about the vulnerability in SMB that affects
Windows and Samba systems, disclosed on April 12 and named "BadLock"
(www.badlock.org).
The native SMB service in Illumos is not subject to the Badlock vulnerabilities.

The main issues discovered by badlock.org relate to downgrade
opportunities using "man in the middle" attacks where DCERPC traffic
is supported over "plain TCP". The Native SMB server in illumos does
not support DCERPC over "plain TCP" (electing to support  DCERPC only
over "SMB named pipes") and is therefore not affected.

For more detailed information about the CVEs, refer to this wiki page:
http://wiki.illumos.org/display/illumos/Response+to+the+badlock.org+CVEs

From danmcd at omniti.com  Thu Apr 14 18:47:13 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 14 Apr 2016 14:47:13 -0400
Subject: [OmniOS-discuss] OmniOS r151018 is now out!
Message-ID: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>

Start with the release notes:

	http://omnios.omniti.com/wiki.php/ReleaseNotes/r151018

The big highlights include:

	- The ability to use pkg(1) to switch between non-DEBUG and DEBUG kernels.

	- Lots of goodies from upstream like SMB2, Intel I219, vmxnet3s, and more.

	- Synched with illumos-gate as of the of March (plus a couple of fixes I upstreamed post-March).

	- OpenSSH (7.2p2 with ALL of the Joyent parity-with-SunSSH fixes) is now installed by default on new ISO, USB, or Kayak installations. The release notes above document how to switch between SunSSH and OpenSSH.

	- Starting with this release, "uname -v" shows the actual release (as pulled from the git branch).  This makes identifying a system a one-step process, instead of the two-step process it was.

OmniOS r151018 is the new stable release.  OmniOS r151016 becomes the "old stable" and will receive critical bugfixes and/or security patches for another six months.  OmniOS r151014 continues to be the long-term-support (LTS) release.  OmniOS r151006 has officially reached END OF SERVICE LIFE, and will get its own e-mail after this.

Upgrading to r151018 should be no different than the upgrade to r151016 was.

Thank you to the OmniOS community for your feedback and support!
Dan McDonald -- OmniOS Engineering


From danmcd at omniti.com  Thu Apr 14 18:47:18 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 14 Apr 2016 14:47:18 -0400
Subject: [OmniOS-discuss] OmniOS r151006 (old LTS) HAS REACHED END OF
	SERVICE LIFE
Message-ID: <76C47141-47A0-4237-B67B-07B27F7C3A53@omniti.com>

I've been warning folks about this for a while:

Last month:

	http://lists.omniti.com/pipermail/omnios-discuss/2016-March/006476.html

And six months ago:

	http://lists.omniti.com/pipermail/omnios-discuss/2015-October/005815.html

It's official now, r151006 will not receive any further updates or other support.  Paying customers should already have been off r151006, and community users will not receive any assistance on r151006 machines.

Onward, with r15014 and beyond!

Thanks,
Dan McDonald -- OmniOS Engineering


From natxo.asenjo at gmail.com  Fri Apr 15 09:40:02 2016
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 15 Apr 2016 11:40:02 +0200
Subject: [OmniOS-discuss] OmniOS r151018 is now out!
In-Reply-To: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>
References: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>
Message-ID: <CAHBEJzV4omdm3fV-nRgg4UhJhmeVcfUMSvW8cnmXzzDis_RZ7A@mail.gmail.com>

On Thu, Apr 14, 2016 at 8:47 PM, Dan McDonald <danmcd at omniti.com> wrote:

> Start with the release notes:
>
>         http://omnios.omniti.com/wiki.php/ReleaseNotes/r151018
>

home box upgraded, zero problems ;-)

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160415/39f50bfe/attachment.html>

From stephan.budach at JVM.DE  Fri Apr 15 16:57:36 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Fri, 15 Apr 2016 18:57:36 +0200
Subject: [OmniOS-discuss] OmniOS r151018 is now out!
In-Reply-To: <CAHBEJzV4omdm3fV-nRgg4UhJhmeVcfUMSvW8cnmXzzDis_RZ7A@mail.gmail.com>
References: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>
	<CAHBEJzV4omdm3fV-nRgg4UhJhmeVcfUMSvW8cnmXzzDis_RZ7A@mail.gmail.com>
Message-ID: <57111D80.7010004@jvm.de>

Hi Dan,

I actually ran into this issue, when tying to upgrade my 016 to 018:

root at zfsha01colt:/root# pkg update -v --be-name=OmniOS-r151018 entire
Creating Plan (Es wird auf widerspr?chliche Aktionen gepr?ft): /
pkg update: Folgende Pakete stellen widerspr?chliche Aktionstypen in 
usr/share/man/man4/ssh_config.4 bereit:

   link:
pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20160412T195038Z
   file:
pkg://omnios/network/openssh at 7.1.2,5.11-0.151016:20160114T155110Z


How can I resolve this issue?

Thanks,
Stephan

From danmcd at omniti.com  Fri Apr 15 18:20:58 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 15 Apr 2016 14:20:58 -0400
Subject: [OmniOS-discuss] OmniOS r151018 is now out!
In-Reply-To: <57111D80.7010004@jvm.de>
References: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>
	<CAHBEJzV4omdm3fV-nRgg4UhJhmeVcfUMSvW8cnmXzzDis_RZ7A@mail.gmail.com>
	<57111D80.7010004@jvm.de>
Message-ID: <1D173791-5F4B-4976-9CCE-978DFC352011@omniti.com>

Follow the "change to openssh or sunssh" instructions on the 016 release notes.  You appear to have conflicting packages, one from each, which was a bug in the 016 installer.

Or you can add "--exclude ssh-common" to your pkg update.

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Apr 15, 2016, at 12:57 PM, Stephan Budach <stephan.budach at JVM.DE> wrote:
> 
> Hi Dan,
> 
> I actually ran into this issue, when tying to upgrade my 016 to 018:
> 
> root at zfsha01colt:/root# pkg update -v --be-name=OmniOS-r151018 entire
> Creating Plan (Es wird auf widerspr?chliche Aktionen gepr?ft): /
> pkg update: Folgende Pakete stellen widerspr?chliche Aktionstypen in usr/share/man/man4/ssh_config.4 bereit:
> 
>  link:
> pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20160412T195038Z
>  file:
> pkg://omnios/network/openssh at 7.1.2,5.11-0.151016:20160114T155110Z
> 
> 
> How can I resolve this issue?
> 
> Thanks,
> Stephan
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From natxo.asenjo at gmail.com  Fri Apr 15 20:05:46 2016
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 15 Apr 2016 22:05:46 +0200
Subject: [OmniOS-discuss] cifs anonymous troubles
Message-ID: <CAHBEJzWHyXqnG4cEzOV7Jbq6d9LQhjdS_4X5mFV8B+1tk4_8xg@mail.gmail.com>

hi,

trying to set up an anonymous share on workgroup mode  I do not get it
working.

I have a dataset tank/test with these sharesmb properties:

zfs get sharesmb tank/testshare
NAME            PROPERTY  VALUE                   SOURCE
tank/testshare  sharesmb  name=test,guestok=true  local

These are the permissions on that path:

# /usr/bin/ls -Vd /tank/testshare/
drwxrwxrwx+ 14 root     root          14 Sep 11  2015 /tank/testshare/
              everyone@:rwxpdDaARWcCos:fd-----:allow

Both using a windows client (win 2012r2) as a linux smbclient (fedora 23),
both quite modern, I cannot access the share:

Linux smbclient:
$ smbclient -U " " -L //192.168.0.172 -N
Anonymous login successful
Domain=[WORKGROUP] OS=[SunOS 5.11 omnios-r151018-ae314] Server=[Native SMB
service]

    Sharename       Type      Comment
    ---------       ----      -------
    c$              Disk      Default Share

    test            Disk
Connection to 192.168.0.172 failed (Error NT_STATUS_CONNECTION_REFUSED)
NetBIOS over TCP disabled -- no workgroup available


Windows client:
C:\Users\Administrator>net view \\192.168.0.172
System error 5 has occurred.

Access is denied.


Using a local user works, with smb2 ;-)

Any one success with guestok=true and cifs?

--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160415/e96fec9d/attachment-0001.html>

From stephan.budach at JVM.DE  Fri Apr 15 20:07:04 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Fri, 15 Apr 2016 22:07:04 +0200
Subject: [OmniOS-discuss] OmniOS r151018 is now out!
In-Reply-To: <1D173791-5F4B-4976-9CCE-978DFC352011@omniti.com>
References: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>
	<CAHBEJzV4omdm3fV-nRgg4UhJhmeVcfUMSvW8cnmXzzDis_RZ7A@mail.gmail.com>
	<57111D80.7010004@jvm.de>
	<1D173791-5F4B-4976-9CCE-978DFC352011@omniti.com>
Message-ID: <571149E8.5000002@jvm.de>

Hi Dan,

Am 15.04.16 um 20:20 schrieb Dan McDonald:
> Follow the "change to openssh or sunssh" instructions on the 016 release notes.  You appear to have conflicting packages, one from each, which was a bug in the 016 installer.
>
> Or you can add "--exclude ssh-common" to your pkg update.
>
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
>> On Apr 15, 2016, at 12:57 PM, Stephan Budach <stephan.budach at JVM.DE> wrote:
>>
>> Hi Dan,
>>
>> I actually ran into this issue, when tying to upgrade my 016 to 018:
>>
>> root at zfsha01colt:/root# pkg update -v --be-name=OmniOS-r151018 entire
>> Creating Plan (Es wird auf widerspr?chliche Aktionen gepr?ft): /
>> pkg update: Folgende Pakete stellen widerspr?chliche Aktionstypen in usr/share/man/man4/ssh_config.4 bereit:
>>
>>   link:
>> pkg://omnios/service/network/ssh-common at 0.5.11,5.11-0.151018:20160412T195038Z
>>   file:
>> pkg://omnios/network/openssh at 7.1.2,5.11-0.151016:20160114T155110Z
>>
>>
>> How can I resolve this issue?
>>
>> Thanks,
>> Stephan
>> _______________________________________________
>>
>>
>>
thanks, I already thought to try that and now both of my RSF-1 hosts are 
happy on r018.

Cheers,
Stephan


From jeff at 1beyond.com  Sat Apr 16 01:38:51 2016
From: jeff at 1beyond.com (Jeff Berkembrock)
Date: Fri, 15 Apr 2016 21:38:51 -0400
Subject: [OmniOS-discuss] cifs anonymous troubles
In-Reply-To: <CAHBEJzWHyXqnG4cEzOV7Jbq6d9LQhjdS_4X5mFV8B+1tk4_8xg@mail.gmail.com>
References: <CAHBEJzWHyXqnG4cEzOV7Jbq6d9LQhjdS_4X5mFV8B+1tk4_8xg@mail.gmail.com>
Message-ID: <CAEGbm65mt_gee7BK-SrCqUEQRitqMtOcMwHnun3FwptXAhZmLQ@mail.gmail.com>

Hello,

I wanted to chime in and say I also experienced this. Guest smb access
seems broken both when I upgrade to 18 as well as when I perform a fresh
install and create new pool & share.

Best Regards,

Jeff Berkembrock
On Apr 15, 2016 1:06 PM, "Natxo Asenjo" <natxo.asenjo at gmail.com> wrote:

> hi,
>
> trying to set up an anonymous share on workgroup mode  I do not get it
> working.
>
> I have a dataset tank/test with these sharesmb properties:
>
> zfs get sharesmb tank/testshare
> NAME            PROPERTY  VALUE                   SOURCE
> tank/testshare  sharesmb  name=test,guestok=true  local
>
> These are the permissions on that path:
>
> # /usr/bin/ls -Vd /tank/testshare/
> drwxrwxrwx+ 14 root     root          14 Sep 11  2015 /tank/testshare/
>               everyone@:rwxpdDaARWcCos:fd-----:allow
>
> Both using a windows client (win 2012r2) as a linux smbclient (fedora 23),
> both quite modern, I cannot access the share:
>
> Linux smbclient:
> $ smbclient -U " " -L //192.168.0.172 -N
> Anonymous login successful
> Domain=[WORKGROUP] OS=[SunOS 5.11 omnios-r151018-ae314] Server=[Native SMB
> service]
>
>     Sharename       Type      Comment
>     ---------       ----      -------
>     c$              Disk      Default Share
>
>     test            Disk
> Connection to 192.168.0.172 failed (Error NT_STATUS_CONNECTION_REFUSED)
> NetBIOS over TCP disabled -- no workgroup available
>
>
> Windows client:
> C:\Users\Administrator>net view \\192.168.0.172
> System error 5 has occurred.
>
> Access is denied.
>
>
> Using a local user works, with smb2 ;-)
>
> Any one success with guestok=true and cifs?
>
> --
> Groeten,
> natxo
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160415/e5f60690/attachment.html>

From jcoombs at staff.gwi.net  Sat Apr 16 02:24:44 2016
From: jcoombs at staff.gwi.net (Josh Coombs)
Date: Fri, 15 Apr 2016 22:24:44 -0400
Subject: [OmniOS-discuss] [developer] NVMe Performance
In-Reply-To: <C8EDFB0A-D114-4581-A4B8-56BB2DB524B0@gentoo.org>
References: <CACcUnf_cZhQ7-iC7EWnsC0KHsoBgWPuXsRqk7vNiKqDgPH-sbw@mail.gmail.com>
	<5707BDCF.3020809@joyent.com>
	<CACcUnf-QD6H2jhWzv4R5dXZgVmW_=o+F_WrhpOHV3GmjrsEw7Q@mail.gmail.com>
	<CAAYoGd8q9d8=vGxsu3n_Pd=uR0g+WFW84=1rjuY67FxJF21GEA@mail.gmail.com>
	<57081193.9050603@multiplay.co.uk>
	<CACcUnf8jUPBpy+OWcbuhxhn53iuhAm3FXc6KGiop1gLaOdTKUg@mail.gmail.com>
	<C8EDFB0A-D114-4581-A4B8-56BB2DB524B0@gentoo.org>
Message-ID: <CACcUnf_pb7O89pTTKfNHVAOtEDKMp6supHuCsN7m8g19kag7GA@mail.gmail.com>

On Fri, Apr 15, 2016 at 9:26 PM, Richard Yao <ryao at gentoo.org> wrote:

>
> The first is to make sure that ZFS uses proper alignment on the device.
> According to what I learned via Google searches, the Intel DC P3600
> supports both 512-byte sectors and 4096-byte sectors, but is low leveled
> formatted to 512-byte sectors by default. You could run fio to see how the
> random IO performance differs on 512-byte IOs at 512-byte formatting vs 4KB
> IOs at 4KB formatting, but I expect that you will find it performs best in
> the 4KB case like Intel's enterprise SATA SSDs do. If the 512-byte random
> IO performance was notable, Intel would have advertised it, but they did
> not do that:
>
>
> http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-dc-p3600-spec.pdf
>
> http://www.cadalyst.com/%5Blevel-1-with-primary-path%5D/how-configure-oracle-redo-intel-pcie-ssd-dc-p3700-23534
>
> So, I played around with this.  Intel's isdct tool will let you secure
erase the P3600 and set it up as a 4k sector device, or a 512, with a few
other options as well.  I have to re-look but it might support 8k sectors
too.  Unfortunately the NVMe driver doesn't play well with the SSD
formatted for anything other than 512 byte sectors.  I noted my findings in
Illumos bug #6912.

I need to look at how Illumos partitions the devices if you just feed zpool
the device rather than a partition, I didn't look to see if it was aligning
things correctly or not on it's own.

The second is that it is possible to increase IOPS beyond Intel's
> specifications by doing a secure erase, giving SLOG a tiny 4KB aligned
> partition and leaving the rest of the device unused. Intel's numbers are
> for steady state performance where almost every flash page is dirty. If you
> leave a significant number of pages clean (i.e. unused following a secure
> erase), the drive should perform better than what Intel claims by virtue of
> the internal book keeping and garbage collection having to do less. Anandtech
> has benchmarks numbers showing this effect on older consumer SSDs on
> Windows in a comparison with the Intel DC S3700:
>

Using isdct I have mine set to 50% over-provisioning, so they show up as
200GB devices now.  As noted in bug 6912 you have to secure erase after
changing that setting or the NVMe driver REALLY gets unhappy.

Josh C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160415/4a51164f/attachment.html>

From stephan.budach at JVM.DE  Sat Apr 16 11:30:04 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Sat, 16 Apr 2016 13:30:04 +0200
Subject: [OmniOS-discuss] Panic when trying to remove an unused LUN with
	stmfadm
Message-ID: <5712223C.8000208@jvm.de>

Hi,

I have experienced this issue a couple of times now. First in r016 but 
just today on r018, too. When trying to remove a LUN by issueing 
something like

root at nfsvmpool05:/root# stmfadm delete-lu 600144F04E4653564D504F4F4C303538
packet_write_wait: Connection to 10.11.14.49: Broken pipe
Shared connection to nfsvmpool05 closed.

the system hung up. When it came back online, I was able to remove that 
LUN without any issue. The fun thing is, that I created that LUN just 
before and it hadn't even been in use, as it hadn't been attached to any 
view.

The syslog shows the usual COMSTAR thingy about kernel heap corruption, 
which I encountered already a couple of times, although in rather normal 
operation mode.

Apr 16 10:17:15 nfsvmpool05 genunix: [ID 478202 kern.notice] kernel 
memory allocator:
Apr 16 10:17:15 nfsvmpool05 unix: [ID 836849 kern.notice]
Apr 16 10:17:15 nfsvmpool05 ^Mpanic[cpu6]/thread=ffffff0e495c4880:
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 812275 kern.notice] kernel heap 
corruption detected
Apr 16 10:17:15 nfsvmpool05 unix: [ID 100000 kern.notice]
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 802836 kern.notice] 
ffffff003df44ae0 fffffffffba4e8d4 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44b20 genunix:kmem_free+1a8 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44b60 stmf:stmf_deregister_lu+1a7 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44ba0 stmf_sbd:sbd_delete_locked_lu+95 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44c00 stmf_sbd:sbd_delete_lu+a9 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44c80 stmf_sbd:stmf_sbd_ioctl+292 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44cc0 genunix:cdev_ioctl+39 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44d10 specfs:spec_ioctl+60 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44da0 genunix:fop_ioctl+55 ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44ec0 genunix:ioctl+9b ()
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 655072 kern.notice] 
ffffff003df44f10 unix:brand_sys_sysenter+1c9 ()
Apr 16 10:17:15 nfsvmpool05 unix: [ID 100000 kern.notice]
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 672855 kern.notice] syncing 
file systems...
Apr 16 10:17:15 nfsvmpool05 genunix: [ID 904073 kern.notice]  done
Apr 16 10:17:16 nfsvmpool05 genunix: [ID 111219 kern.notice] dumping to 
/dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
Apr 16 10:17:16 nfsvmpool05 ahci: [ID 405573 kern.info] NOTICE: ahci0: 
ahci_tran_reset_dport port 1 reset port
Apr 16 10:20:46 nfsvmpool05 genunix: [ID 100000 kern.notice]
Apr 16 10:20:46 nfsvmpool05 genunix: [ID 665016 kern.notice] ^M100% 
done: 1153955 pages dumped,
Apr 16 10:20:46 nfsvmpool05 genunix: [ID 851671 kern.notice] dump succeeded

Fortuanetly this time, there has been a debug kernel running, as Dan 
suggested on former occurances and I do have a dump at hand, which I 
could upload to uploads.omniti.com, if I'd get a token to do so.

@Dan, may I get one?

Thanks,
Stephan

From alka at hfg-gmuend.de  Sat Apr 16 15:35:30 2016
From: alka at hfg-gmuend.de (Guenther Alka)
Date: Sat, 16 Apr 2016 17:35:30 +0200
Subject: [OmniOS-discuss] OmniOS 151016/ 151017 not listed in network
 environment
In-Reply-To: <56FD6CC0.50508@hfg-gmuend.de>
References: <56FD4653.6060806@hfg-gmuend.de>
	<4C8EDCED-A272-43D7-A30E-DAF2771968A9@omniti.com>
	<56FD6CC0.50508@hfg-gmuend.de>
Message-ID: <57125BC2.60203@hfg-gmuend.de>

update

OmniOS is listed on a Windows machine (tried in 151018)
when you set the smbshare propertynetbios_enable=true

Could this be re-enabled as default as this is an expected behaviour?

thanks


Gea



Am 31.03.2016 um 20:30 schrieb Guenther Alka:
> Hallo Dan
> This is not related to Windows AD but a problem that the Solarish 
> kernel SMB server does not offer a master browser capability that is 
> needed to provide the list of SMB servers in Windows "network 
> neighborhood".
>
> So you need a Windows or SAMBA server in the subnet that provides this 
> feature.
> This worked together with my 151014 boxes that are listed in network 
> neighborhood
>
> see
> https://docs.oracle.com/cd/E36784_01/html/E36832/winclientcannotcontactbynetbios.html 
>
>
> thanks
>
> Gea
>
> Am 31.03.2016 um 19:02 schrieb Dan McDonald:
>>> On Mar 31, 2016, at 11:46 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:
>>>
>>> We have an AD environment where the AD server is the master browser
>>> to list all servers and workstations on our Windows machines under 
>>> network
>>>
>>> This works for a couple of OmniOS 151014 servers but not for my 
>>> 151016/ 151017 testservers. Is this a known problem or is there 
>>> something that I should consider?
>> Are you using the in-kernel SMB service?  That got updated in a big 
>> way as part of 016 (non-global-zone SMB serving), and more is coming 
>> in 018.
>>
>> I'm not a Windows/AD expert, so please, when reporting AD issues, be 
>> a bit more pedantic in your explanation.  You should also check the 
>> illumos mailing list archives as well.
>>
>> Thanks,
>> Dan
>>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
H          f   G
Hochschule f?r Gestaltung
university of design

Schw?bisch Gm?nd
Rektor-Klaus Str. 100
73525 Schw?bisch Gm?nd

Guenther Alka, Dipl.-Ing. (FH)
Leiter des Rechenzentrums
head of computer center

Tel 07171 602 627
Fax 07171 69259
guenther.alka at hfg-gmuend.de
http://rz.hfg-gmuend.de


From richard.elling at richardelling.com  Sun Apr 17 02:15:50 2016
From: richard.elling at richardelling.com (Richard Elling)
Date: Sat, 16 Apr 2016 19:15:50 -0700
Subject: [OmniOS-discuss] [developer] NVMe Performance
In-Reply-To: <5711A822.1030505@gentoo.org>
References: <CACcUnf_cZhQ7-iC7EWnsC0KHsoBgWPuXsRqk7vNiKqDgPH-sbw@mail.gmail.com>
	<5707BDCF.3020809@joyent.com>
	<CACcUnf-QD6H2jhWzv4R5dXZgVmW_=o+F_WrhpOHV3GmjrsEw7Q@mail.gmail.com>
	<CAAYoGd8q9d8=vGxsu3n_Pd=uR0g+WFW84=1rjuY67FxJF21GEA@mail.gmail.com>
	<57081193.9050603@multiplay.co.uk>
	<CACcUnf8jUPBpy+OWcbuhxhn53iuhAm3FXc6KGiop1gLaOdTKUg@mail.gmail.com>
	<C8EDFB0A-D114-4581-A4B8-56BB2DB524B0@gentoo.org>
	<CACcUnf_pb7O89pTTKfNHVAOtEDKMp6supHuCsN7m8g19kag7GA@mail.gmail.com>
	<5711A822.1030505@gentoo.org>
Message-ID: <21906461-4340-4E36-A3C0-8DB075348654@RichardElling.com>


> On Apr 15, 2016, at 7:49 PM, Richard Yao <ryao at gentoo.org> wrote:
> 
> On 04/15/2016 10:24 PM, Josh Coombs wrote:
>> On Fri, Apr 15, 2016 at 9:26 PM, Richard Yao <ryao at gentoo.org> wrote:
>> 
>>> 
>>> The first is to make sure that ZFS uses proper alignment on the device.
>>> According to what I learned via Google searches, the Intel DC P3600
>>> supports both 512-byte sectors and 4096-byte sectors, but is low leveled
>>> formatted to 512-byte sectors by default. You could run fio to see how the
>>> random IO performance differs on 512-byte IOs at 512-byte formatting vs 4KB
>>> IOs at 4KB formatting, but I expect that you will find it performs best in
>>> the 4KB case like Intel's enterprise SATA SSDs do. If the 512-byte random
>>> IO performance was notable, Intel would have advertised it, but they did
>>> not do that:
>>> 
>>> 
>>> http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-dc-p3600-spec.pdf
>>> 
>>> http://www.cadalyst.com/%5Blevel-1-with-primary-path%5D/how-configure-oracle-redo-intel-pcie-ssd-dc-p3700-23534
>>> 
>> So, I played around with this.  Intel's isdct tool will let you secure
>> erase the P3600 and set it up as a 4k sector device, or a 512, with a few
>> other options as well.  I have to re-look but it might support 8k sectors
>> too.  Unfortunately the NVMe driver doesn't play well with the SSD
>> formatted for anything other than 512 byte sectors.  I noted my findings in
>> Illumos bug #6912.
> 
> The documentation does not say that it will do 8192-byte sectors,
> although ZFS in theory should be okay with them. My tests on the Intel
> DC S3700 suggested that 4KB vs 8KB was too close to tell. I recall
> deciding that Intel did a good enough job at 4KB that it should go into
> ZoL's quirks list as a 4KB drive.

ZIL traffic is all 4K, unless phys blocksize is larger. There are a number of Flash SSDs
that prefer 8k, and you can tell by the ?optimal transfer size.? Since the bulk of the market
driving SSD sales is running NTFS, 4K is the market sweet spot.

> 
> The P3600 is probably similar because its NAND flash controller "is an
> evolution of the design used in the S3700/S3500":
> 
> http://www.anandtech.com/show/8104/intel-ssd-dc-p3700-review-the-pcie-ssd-transition-begins-with-nvme <http://www.anandtech.com/show/8104/intel-ssd-dc-p3700-review-the-pcie-ssd-transition-begins-with-nvme>
> 
>> I need to look at how Illumos partitions the devices if you just feed zpool
>> the device rather than a partition, I didn't look to see if it was aligning
>> things correctly or not on it's own.
> 
> It will put the first partition at a 1MB boundary and set an internal
> alignment shift consistent with what the hardware reports.
> 
>> The second is that it is possible to increase IOPS beyond Intel's
>>> specifications by doing a secure erase, giving SLOG a tiny 4KB aligned
>>> partition and leaving the rest of the device unused. Intel's numbers are
>>> for steady state performance where almost every flash page is dirty. If you
>>> leave a significant number of pages clean (i.e. unused following a secure
>>> erase), the drive should perform better than what Intel claims by virtue of
>>> the internal book keeping and garbage collection having to do less. Anandtech
>>> has benchmarks numbers showing this effect on older consumer SSDs on
>>> Windows in a comparison with the Intel DC S3700:
>>> 
>> 
>> Using isdct I have mine set to 50% over-provisioning, so they show up as
>> 200GB devices now.  As noted in bug 6912 you have to secure erase after
>> changing that setting or the NVMe driver REALLY gets unhappy.
> 
> If you are using it as a SLOG, you would probably want something like
> 98% overprovisioning to match the ZeusRAM, which was designed for use as
> a ZFS SLOG device and was very well regarded until it was discontinued:
> 
> https://www.hgst.com/sites/default/files/resources/[FAQ]_ZeusRAM_FQ008-EN-US.pdf <https://www.hgst.com/sites/default/files/resources/[FAQ]_ZeusRAM_FQ008-EN-US.pdf>

ZeusRAM was great for its time, but the 12G replacements perform similarly. The
biggest difference between ZeusRAMs and Flash SSDs seems to be in the garbage
collection. In my testing, low DWPD drives have less consistent performance as the
garbage collection is less optimized. For the 3 DWPD drives we?ve tested, the performance
for slog workloads is more consistent than the 1 DWPD drives.

> 
> ZFS generally does not need much more from a SLOG device. The way to
> ensure that you do not overprovision more/less than ZFS is willing to
> use on your system would be to look at zfs_dirty_data_max
> 
> That being said, you likely will want to run fio random IO benchmarks at
> different overprovisioning levels after a secure erase and a dd
> if=/dev/urandom of=/path/to/device so you can see the difference in
> performance yourself. Happy benchmarking. :)

/dev/urandom is too (intentionally) slow. You?ll bottleneck there.

Richard?s advice is good: test with random workloads. Contrary to popular believe, the ZIL
workload is not contiguous for most environments. So testing with ?sequential? tests will not
deliver good results.

The other unfortunate problem with Flash SSDs is the parallelism. For a given product line,
the smaller drives also have lower performance. This is particularly important for slogs because
you think that the smaller size is what you need, but the published benchmarks are for the
largest size in the product line, and can be 2x or 4x faster (latency) than the smaller versions.
 ? richard

--

Richard.Elling at RichardElling.com
+1-760-896-4422



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160416/516035d1/attachment-0001.html>

From stephan.budach at JVM.DE  Sun Apr 17 12:07:06 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Sun, 17 Apr 2016 14:07:06 +0200
Subject: [OmniOS-discuss] Slow scrub  on SSD-only pool
Message-ID: <57137C6A.7050505@jvm.de>

Hi all,

I am running a scrub on a SSD-only zpool on r018. This zpool consists of 
16 iSCSI targets, which are served from two other OmniOS boxes - 
currently still running r016 over 10GbE connections.

This zpool serves as a NFS share for my Oracle VM cluster and it 
delivers reasonable performance. Even while the scrub is running, I can 
get approx 1200MB/s throughput when dd'ing a vdisk from the ZFS to 
/dev/null.

However, the running scrub is only progressing like this:

root at zfsha02gh79:/root# zpool status ssdTank
   pool: ssdTank
  state: ONLINE
   scan: scrub in progress since Sat Apr 16 23:37:52 2016
     68,5G scanned out of 1,36T at 1,36M/s, 276h17m to go
     0 repaired, 4,92% done
config:

         NAME STATE     READ WRITE CKSUM
         ssdTank ONLINE       0     0     0
           mirror-0 ONLINE       0     0     0
             c3t600144F090D09613000056B8A76C0001d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A93C0009d0 ONLINE       0     
0     0
           mirror-1 ONLINE       0     0     0
             c3t600144F090D09613000056B8A7BE0002d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A948000Ad0 ONLINE       0     
0     0
           mirror-2 ONLINE       0     0     0
             c3t600144F090D09613000056B8A7F10003d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A958000Bd0 ONLINE       0     
0     0
           mirror-3 ONLINE       0     0     0
             c3t600144F090D09613000056B8A7FC0004d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A964000Cd0 ONLINE       0     
0     0
           mirror-4 ONLINE       0     0     0
             c3t600144F090D09613000056B8A8210005d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A96E000Dd0 ONLINE       0     
0     0
           mirror-5 ONLINE       0     0     0
             c3t600144F090D09613000056B8A82E0006d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A978000Ed0 ONLINE       0     
0     0
           mirror-6 ONLINE       0     0     0
             c3t600144F090D09613000056B8A83B0007d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A983000Fd0 ONLINE       0     
0     0
           mirror-7 ONLINE       0     0     0
             c3t600144F090D09613000056B8A84A0008d0 ONLINE       0     
0     0
             c3t600144F090D09613000056B8A98E0010d0 ONLINE       0     
0     0

errors: No known data errors

These are all Intel S3710s with 800GB and I can't seem to find out why 
it's moving so slowly.
Anything I can look at specifically?

Thanks,
Stephan

From stephan.budach at JVM.DE  Sun Apr 17 13:07:12 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Sun, 17 Apr 2016 15:07:12 +0200
Subject: [OmniOS-discuss] Slow scrub  on SSD-only pool
In-Reply-To: <57137C6A.7050505@jvm.de>
References: <57137C6A.7050505@jvm.de>
Message-ID: <57138A80.6030203@jvm.de>

Am 17.04.16 um 14:07 schrieb Stephan Budach:
> Hi all,
>
> I am running a scrub on a SSD-only zpool on r018. This zpool consists 
> of 16 iSCSI targets, which are served from two other OmniOS boxes - 
> currently still running r016 over 10GbE connections.
>
> This zpool serves as a NFS share for my Oracle VM cluster and it 
> delivers reasonable performance. Even while the scrub is running, I 
> can get approx 1200MB/s throughput when dd'ing a vdisk from the ZFS to 
> /dev/null.
>
> However, the running scrub is only progressing like this:
>
> root at zfsha02gh79:/root# zpool status ssdTank
>   pool: ssdTank
>  state: ONLINE
>   scan: scrub in progress since Sat Apr 16 23:37:52 2016
>     68,5G scanned out of 1,36T at 1,36M/s, 276h17m to go
>     0 repaired, 4,92% done
> config:
>
>         NAME STATE     READ WRITE CKSUM
>         ssdTank ONLINE       0     0     0
>           mirror-0 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A76C0001d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A93C0009d0 ONLINE 0     0     0
>           mirror-1 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A7BE0002d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A948000Ad0 ONLINE 0     0     0
>           mirror-2 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A7F10003d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A958000Bd0 ONLINE 0     0     0
>           mirror-3 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A7FC0004d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A964000Cd0 ONLINE 0     0     0
>           mirror-4 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A8210005d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A96E000Dd0 ONLINE 0     0     0
>           mirror-5 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A82E0006d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A978000Ed0 ONLINE 0     0     0
>           mirror-6 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A83B0007d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A983000Fd0 ONLINE 0     0     0
>           mirror-7 ONLINE       0     0     0
>             c3t600144F090D09613000056B8A84A0008d0 ONLINE 0     0     0
>             c3t600144F090D09613000056B8A98E0010d0 ONLINE 0     0     0
>
> errors: No known data errors
>
> These are all Intel S3710s with 800GB and I can't seem to find out why 
> it's moving so slowly.
> Anything I can look at specifically?
>
> Thanks,
> Stephan
>
Well? searching the net somewhat more thoroughfully, I came across an 
archived discussion which deals also with a similar issue. Somewhere 
down the conversation, this parameter got suggested:

echo "zfs_scrub_delay/W0" | mdb -kw

I just tried that as well and although the caculated speed climbs rathet 
slowly up, iostat now shows  approx. 380 MB/s read from the devices, 
which rates  at 24 MB/s per single device * 8 *2.

Being curious, I issued a echo "zfs_scrub_delay/W1" | mdb -kw to see 
what would happen and that command immediately drowned the rate on each 
device down to 1.4 MB/s?

What is the rational behind that? Who wants to wait for weeks for a 
scrub to finish? Usually, I am having znapzend run as well, creating 
snapshots on a regular basis. Wouldn't that hurt scrub performance even 
more?

Cheers,
Stephan

From gordon.w.ross at gmail.com  Sun Apr 17 15:38:54 2016
From: gordon.w.ross at gmail.com (Gordon Ross)
Date: Sun, 17 Apr 2016 11:38:54 -0400
Subject: [OmniOS-discuss] cifs anonymous troubles
In-Reply-To: <CAHBEJzWHyXqnG4cEzOV7Jbq6d9LQhjdS_4X5mFV8B+1tk4_8xg@mail.gmail.com>
References: <CAHBEJzWHyXqnG4cEzOV7Jbq6d9LQhjdS_4X5mFV8B+1tk4_8xg@mail.gmail.com>
Message-ID: <CAD0Ztp0+HQ0L=wsJY969wR173YCaoBt4Bmd5xni23WfFg_tXdw@mail.gmail.com>

Hi Dan,

I can take a guess what this might be about.

There were several bugs fixed as part of the "extended security" work:
1122 smbsrv should use SPNEGO (inbound authentication)

One of those was that we used to give a client a "guest" logon
if they tried to logon to SMB with _any_ unrecognized account.
No, that was never a good idea. Not only was it questionable
for security, but it confused issues about failed logon.  Example:
Windows user does NOT get the expected pop-up dialog asking
for new credentials when they try to connect to a share using
an invalid user name.  Instead, they would get connected,
but would fail to have access to anything in the share.

So with that bug fixed, one can logon as "guest" only if:
(1) you actually ask for guest in your logon request,
(2) a local Unix account named "guest" exists, and
(3) the guest account is enabled for SMB

Therefore, if you were using guest access before 1122 was fixed,
(and were depending on accidental guest access working),
you'll need to do the following to re-enable guest access:

    useradd (options] guest
    smbadm enable-user guest

The guest account password is ignored by SMB, so
all that matters to SMB is whether that account is
marked as enabled in /var/smb/smbpasswd

To keep Unix users from using guest for login, you can
set the Unix password hash to something invalid, etc.

On Fri, Apr 15, 2016 at 4:05 PM, Natxo Asenjo <natxo.asenjo at gmail.com> wrote:
> hi,
>
> trying to set up an anonymous share on workgroup mode  I do not get it
> working.
>
> I have a dataset tank/test with these sharesmb properties:
>
> zfs get sharesmb tank/testshare
> NAME            PROPERTY  VALUE                   SOURCE
> tank/testshare  sharesmb  name=test,guestok=true  local
>
> These are the permissions on that path:
>
> # /usr/bin/ls -Vd /tank/testshare/
> drwxrwxrwx+ 14 root     root          14 Sep 11  2015 /tank/testshare/
>               everyone@:rwxpdDaARWcCos:fd-----:allow
>
> Both using a windows client (win 2012r2) as a linux smbclient (fedora 23),
> both quite modern, I cannot access the share:
>
> Linux smbclient:
> $ smbclient -U " " -L //192.168.0.172 -N
> Anonymous login successful
> Domain=[WORKGROUP] OS=[SunOS 5.11 omnios-r151018-ae314] Server=[Native SMB
> service]
>
>     Sharename       Type      Comment
>     ---------       ----      -------
>     c$              Disk      Default Share
>
>     test            Disk
> Connection to 192.168.0.172 failed (Error NT_STATUS_CONNECTION_REFUSED)
> NetBIOS over TCP disabled -- no workgroup available
>
>
> Windows client:
> C:\Users\Administrator>net view \\192.168.0.172
> System error 5 has occurred.
>
> Access is denied.
>
>
> Using a local user works, with smb2 ;-)
>
> Any one success with guestok=true and cifs?
>
> --
> Groeten,
> natxo
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From natxo.asenjo at gmail.com  Sun Apr 17 17:43:23 2016
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sun, 17 Apr 2016 19:43:23 +0200
Subject: [OmniOS-discuss] cifs anonymous troubles
In-Reply-To: <CAD0Ztp0+HQ0L=wsJY969wR173YCaoBt4Bmd5xni23WfFg_tXdw@mail.gmail.com>
References: <CAHBEJzWHyXqnG4cEzOV7Jbq6d9LQhjdS_4X5mFV8B+1tk4_8xg@mail.gmail.com>
	<CAD0Ztp0+HQ0L=wsJY969wR173YCaoBt4Bmd5xni23WfFg_tXdw@mail.gmail.com>
Message-ID: <CAHBEJzVt-n65CuCjhbRUMWW+p2kESUyO9SRcy2bnM+JtVsU5uw@mail.gmail.com>

hi Gordon,

On Sun, Apr 17, 2016 at 5:38 PM, Gordon Ross <gordon.w.ross at gmail.com>
wrote:

> Hi Dan,
>
> So with that bug fixed, one can logon as "guest" only if:
> (1) you actually ask for guest in your logon request,
> (2) a local Unix account named "guest" exists, and
> (3) the guest account is enabled for SMB
>
> Therefore, if you were using guest access before 1122 was fixed,
> (and were depending on accidental guest access working),
> you'll need to do the following to re-enable guest access:
>
>     useradd (options] guest
>     smbadm enable-user guest


I confirm this works. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160417/3fdd0410/attachment.html>

From daleg at omniti.com  Sun Apr 17 18:42:21 2016
From: daleg at omniti.com (Dale Ghent)
Date: Sun, 17 Apr 2016 14:42:21 -0400
Subject: [OmniOS-discuss] Slow scrub  on SSD-only pool
In-Reply-To: <57138A80.6030203@jvm.de>
References: <57137C6A.7050505@jvm.de> <57138A80.6030203@jvm.de>
Message-ID: <16613422-27A5-4C0B-A76D-12079DFE991C@omniti.com>


> On Apr 17, 2016, at 9:07 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
> 
> Well? searching the net somewhat more thoroughfully, I came across an archived discussion which deals also with a similar issue. Somewhere down the conversation, this parameter got suggested:
> 
> echo "zfs_scrub_delay/W0" | mdb -kw
> 
> I just tried that as well and although the caculated speed climbs rathet slowly up, iostat now shows  approx. 380 MB/s read from the devices, which rates  at 24 MB/s per single device * 8 *2.
> 
> Being curious, I issued a echo "zfs_scrub_delay/W1" | mdb -kw to see what would happen and that command immediately drowned the rate on each device down to 1.4 MB/s?
> 
> What is the rational behind that? Who wants to wait for weeks for a scrub to finish? Usually, I am having znapzend run as well, creating snapshots on a regular basis. Wouldn't that hurt scrub performance even more?

zfs_scrub_delay is described here:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#63

How busy are your disks if you subtract the IO caused by a scrub? Are you doing these scrubs with your VMs causing normal IO as well?

Scrubbing, overall, is treated as a background maintenance process. As such, it is designed to not interfere with "production IO" requests. It used to be that scrubs ran as fast as disk IO and bus bandwidth would allow, which in turn severely impacted the IO performance of running applications, and in some cases this would cause problems for production or user services.  The scrub delay setting which you've discovered is the main governor of this scrub throttle code[1], and by setting it to 0, you are effectively removing the delay it imposes on itself to allow non-scrub/resilvering IO requests to finish.

The solution in your case is specific to yourself and how you operate your servers and services. Can you accept degraded application IO while a scrub or resilver is running? Can you not? Maybe only during certain times?

/dale

[1] http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#1841
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160417/d6e7d7f3/attachment.bin>

From stephan.budach at JVM.DE  Sun Apr 17 20:07:37 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Sun, 17 Apr 2016 22:07:37 +0200
Subject: [OmniOS-discuss] Slow scrub  on SSD-only pool
In-Reply-To: <16613422-27A5-4C0B-A76D-12079DFE991C@omniti.com>
References: <57137C6A.7050505@jvm.de> <57138A80.6030203@jvm.de>
	<16613422-27A5-4C0B-A76D-12079DFE991C@omniti.com>
Message-ID: <5713ED09.4000206@jvm.de>

Am 17.04.16 um 20:42 schrieb Dale Ghent:
>> On Apr 17, 2016, at 9:07 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
>>
>> Well? searching the net somewhat more thoroughfully, I came across an archived discussion which deals also with a similar issue. Somewhere down the conversation, this parameter got suggested:
>>
>> echo "zfs_scrub_delay/W0" | mdb -kw
>>
>> I just tried that as well and although the caculated speed climbs rathet slowly up, iostat now shows  approx. 380 MB/s read from the devices, which rates  at 24 MB/s per single device * 8 *2.
>>
>> Being curious, I issued a echo "zfs_scrub_delay/W1" | mdb -kw to see what would happen and that command immediately drowned the rate on each device down to 1.4 MB/s?
>>
>> What is the rational behind that? Who wants to wait for weeks for a scrub to finish? Usually, I am having znapzend run as well, creating snapshots on a regular basis. Wouldn't that hurt scrub performance even more?
> zfs_scrub_delay is described here:
>
> http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#63
>
> How busy are your disks if you subtract the IO caused by a scrub? Are you doing these scrubs with your VMs causing normal IO as well?
>
> Scrubbing, overall, is treated as a background maintenance process. As such, it is designed to not interfere with "production IO" requests. It used to be that scrubs ran as fast as disk IO and bus bandwidth would allow, which in turn severely impacted the IO performance of running applications, and in some cases this would cause problems for production or user services.  The scrub delay setting which you've discovered is the main governor of this scrub throttle code[1], and by setting it to 0, you are effectively removing the delay it imposes on itself to allow non-scrub/resilvering IO requests to finish.
>
> The solution in your case is specific to yourself and how you operate your servers and services. Can you accept degraded application IO while a scrub or resilver is running? Can you not? Maybe only during certain times?
>
> /dale
>
> [1] http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#1841
I do get the notion if this, but if the increase from 0 to 1 reduces the 
throughput from 24Mb/s to 1MB/s, this seems way overboard to me. Having 
to wait for a couple of hours when running with 0 as opposed to days (up 
to 10) when running at 1  - on a 1.3 TB zpool - doesn't seem to be the 
right choice. If this tunable offered some more room for choice,  that 
would be great, but it obviously doesn't.

It's the weekend and my VMs aren't excatly hogging their disks, so there 
was plenty of I/O available? I'd wish for a more granular setting 
regarding this setting.

Anyway, the scrub finished a couple of hours later and of course, I can 
always set this tunable to 0, should I need it,

Thanks,
Stephan

From doug at will.to  Sun Apr 17 21:00:52 2016
From: doug at will.to (Doug Hughes)
Date: Sun, 17 Apr 2016 17:00:52 -0400
Subject: [OmniOS-discuss] heavy NFS load causing server to become
 unavailable from memory starvation.
In-Reply-To: <5713ED09.4000206@jvm.de>
References: <57137C6A.7050505@jvm.de> <57138A80.6030203@jvm.de>
	<16613422-27A5-4C0B-A76D-12079DFE991C@omniti.com>
	<5713ED09.4000206@jvm.de>
Message-ID: <5713F984.2020200@will.to>

Been seeing this a bit lately on a server with 96GB ram where the zil is 
limited to 48GB. Under heavy NFS load (caused by user running parallel 
find/xargs/rm clean job), it sends the machine into desparation memory 
and causes it to be unreachable for a while. (the server is 24 x SSD, 
and I/O load is ok)

I have some mdb/kmastat/kmausers/memstat output.

here's the kmastat break down.

Total [hat_memload] 15.8M    5155240     0
Total [kmem_msb] 22.0G  987112603     0
Total [kmem_firewall] 271M  411704261   895
Total [kmem_va] 40.8G   22314937     0
Total [kmem_default] 31.8G 4275706645   619
Total [kmem_io_4P] 44.7M   26714639     0
Total [kmem_io_4G] 108K        908     0
Total [kmem_io_2G] 100K         68     0
Total [bp_map]                                                0 7251     0
Total [umem_np]                                               0 728     0
Total [zfs_file_data] 118M      93380     0
Total [zfs_file_data_buf] 19.4G   22030035     0
Total [segkp] 256K       6787     0
Total [ip_minor_arena_sa] 512      72304     0
Total [ip_minor_arena_la]                                    64 29350     0
Total [spdsock]                                               0 1     0
Total [namefs_inodes]                                        64 27     0
------------------------------ ----- --------- --------- ------ 
---------- -----

the kmausers is almost 1MB.


From mark at kushigian.com  Mon Apr 18 02:05:30 2016
From: mark at kushigian.com (Mark Kushigian)
Date: Mon, 18 Apr 2016 02:05:30 +0000 (UTC)
Subject: [OmniOS-discuss] OmniOS r151018 is now out!
References: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>
Message-ID: <loom.20160418T035556-518@post.gmane.org>

There seems to be an issue with time zones. During a fresh installation,
I attempted to choose US Eastern time zone. In the first place, it is not
listed, it only says "(most areas)". I choose it anyway and then the
installation fails, reporting "Timezone value specified (Eastern) is not
valid". If I just choose UTC it installs fine. I have screenshots but I'm
new to this forum and don't know how to include them.


From danmcd at omniti.com  Mon Apr 18 16:45:34 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 18 Apr 2016 12:45:34 -0400
Subject: [OmniOS-discuss] Timezone zone_sun.tab mismerge (was Re: OmniOS
	r151018 is now out!)
In-Reply-To: <loom.20160418T035556-518@post.gmane.org>
References: <AEF976C0-02F9-46A7-8D17-16CB28922F14@omniti.com>
	<loom.20160418T035556-518@post.gmane.org>
Message-ID: <C2400B8B-C71E-4B12-8DFC-F57C70BEF689@omniti.com>


> On Apr 17, 2016, at 10:05 PM, Mark Kushigian <mark at kushigian.com> wrote:
> 
> There seems to be an issue with time zones. During a fresh installation,
> I attempted to choose US Eastern time zone. In the first place, it is not
> listed, it only says "(most areas)". I choose it anyway and then the
> installation fails, reporting "Timezone value specified (Eastern) is not
> valid". If I just choose UTC it installs fine. I have screenshots but I'm
> new to this forum and don't know how to include them.

Don't worry about it.  I took another look and I mismerged zone_sun.tab during the last TZ update.

The Caiman installer uses the very old & crufty "libzoneinfo" for its TZ selection screen, which uses the special zone_sun.tab file instead of the standard timezone database.  There was one GLARING bug from last time where UTF-8 characters in the timezone database broke Caiman.  I fixed that, and focussed my testing on unscrewing UTF-8.  I overlooked existing known-to-previously-work timezones after the 2016c merge, and thanks to your report, now I know I botched the zone_sun.tab merge.

I'm spinning a test installer for 018 today today see if I've fixed it.  For now, pick UTC/GMT and edit /etc/default/init after your first installed boot.

Thanks!
Dan


From moo at wuffers.net  Tue Apr 19 21:31:30 2016
From: moo at wuffers.net (wuffers)
Date: Tue, 19 Apr 2016 17:31:30 -0400
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <5713ED09.4000206@jvm.de>
References: <57137C6A.7050505@jvm.de> <57138A80.6030203@jvm.de>
	<16613422-27A5-4C0B-A76D-12079DFE991C@omniti.com>
	<5713ED09.4000206@jvm.de>
Message-ID: <CA+tR_Kwce_=qierL8oBBQVmHp5Rx6dLJZTqiN+dHndR-2-uPGA@mail.gmail.com>

You might want to check this old thread:

http://lists.omniti.com/pipermail/omnios-discuss/2014-July/002927.html

Richard Elling had some interesting insights on how the scrub works:

"So I think the pool is not scheduling scrub I/Os very well. You can
increase the number of
scrub I/Os in the scheduler by adjusting the zfs_vdev_scrub_max_active
tunable. The
default is 2, but you'll have to consider that a share (in the stock market
sense) where
the active sync reads and writes are getting 10 each. You can try bumping
up the value
and see what happens over some time, perhaps 10 minutes or so -- too short
of a time
and you won't get a good feeling for the impact (try this in off-peak time).
echo zfs_vdev_scrub_max_active/W0t5 | mdb -kw
will change the value from 2 to 5, increasing its share of the total I/O
workload.

You can see the progress of scan (scrubs do scan) workload by looking at
the ZFS
debug messages.
echo ::zfs_dbgmsg | mdb -k
These will look mysterious... they are. But the interesting bits are about
how many blocks
are visited in some amount of time (txg sync interval). Ideally, this will
change as you
adjust zfs_vdev_scrub_max_active."

I had to increase my zfs_vdev_scrub_max_active parameter higher than 5, but
it sounds like the default setting for that tunable is no longer
satisfactory for today's high performance systems.

On Sun, Apr 17, 2016 at 4:07 PM, Stephan Budach <stephan.budach at jvm.de>
wrote:

> Am 17.04.16 um 20:42 schrieb Dale Ghent:
>
> On Apr 17, 2016, at 9:07 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
>>>
>>> Well? searching the net somewhat more thoroughfully, I came across an
>>> archived discussion which deals also with a similar issue. Somewhere down
>>> the conversation, this parameter got suggested:
>>>
>>> echo "zfs_scrub_delay/W0" | mdb -kw
>>>
>>> I just tried that as well and although the caculated speed climbs rathet
>>> slowly up, iostat now shows  approx. 380 MB/s read from the devices, which
>>> rates  at 24 MB/s per single device * 8 *2.
>>>
>>> Being curious, I issued a echo "zfs_scrub_delay/W1" | mdb -kw to see
>>> what would happen and that command immediately drowned the rate on each
>>> device down to 1.4 MB/s?
>>>
>>> What is the rational behind that? Who wants to wait for weeks for a
>>> scrub to finish? Usually, I am having znapzend run as well, creating
>>> snapshots on a regular basis. Wouldn't that hurt scrub performance even
>>> more?
>>>
>> zfs_scrub_delay is described here:
>>
>>
>> http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#63
>>
>> How busy are your disks if you subtract the IO caused by a scrub? Are you
>> doing these scrubs with your VMs causing normal IO as well?
>>
>> Scrubbing, overall, is treated as a background maintenance process. As
>> such, it is designed to not interfere with "production IO" requests. It
>> used to be that scrubs ran as fast as disk IO and bus bandwidth would
>> allow, which in turn severely impacted the IO performance of running
>> applications, and in some cases this would cause problems for production or
>> user services.  The scrub delay setting which you've discovered is the main
>> governor of this scrub throttle code[1], and by setting it to 0, you are
>> effectively removing the delay it imposes on itself to allow
>> non-scrub/resilvering IO requests to finish.
>>
>> The solution in your case is specific to yourself and how you operate
>> your servers and services. Can you accept degraded application IO while a
>> scrub or resilver is running? Can you not? Maybe only during certain times?
>>
>> /dale
>>
>> [1]
>> http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#1841
>>
> I do get the notion if this, but if the increase from 0 to 1 reduces the
> throughput from 24Mb/s to 1MB/s, this seems way overboard to me. Having to
> wait for a couple of hours when running with 0 as opposed to days (up to
> 10) when running at 1  - on a 1.3 TB zpool - doesn't seem to be the right
> choice. If this tunable offered some more room for choice,  that would be
> great, but it obviously doesn't.
>
> It's the weekend and my VMs aren't excatly hogging their disks, so there
> was plenty of I/O available? I'd wish for a more granular setting regarding
> this setting.
>
> Anyway, the scrub finished a couple of hours later and of course, I can
> always set this tunable to 0, should I need it,
>
> Thanks,
>
> Stephan
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160419/fb22b860/attachment.html>

From lists at marzocchi.net  Wed Apr 20 22:28:40 2016
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Thu, 21 Apr 2016 00:28:40 +0200
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
Message-ID: <57180298.1080808@marzocchi.net>

I updated as indicated in the guide and to do that I had to uninstall 
some packages:

serf at 1.3.8,5.11-0.151014:20151015T214958Z
apr-util at 1.4.1,5.11-0.151014:20150508T204811Z 
apr at 1.5.1,5.11-0.151014:20150529T175834Z
uuid at 1.41.14,5.11-0.151014:20150508T153803Z

After reboot I got two main issues.

1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I usually 
did in the past, both for SMB, local webserver/services, ... but I can 
still access the box when I use the plain IP.

OmniOS-Xeon:~ olaf$ cat /etc/nodename
OmniOS-Xeon


2) I cannot access one specific SMB share ("olaf") that was working 
perfectly before the update. Using the IP of the machine allows me to 
access the other shares, but not this one. It was also the one with the 
most restrictive access ACLs, but they look fine to me.

OmniOS-Xeon:~ olaf$ sharemgr show
...
zfs
     zfs/tank/home/olaf
           /tank/home/olaf
[and more shares, all working]

OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
total 34
drwx------+ 15 olaf     olaf          15 Oct 25 11:27 olaf
               user:olaf:rwxpdDaARWcCos:fd-----:allow
        group:2147483648:rwxpdDaARWcCos:fd-----:allow
               everyone@:rwxpdDaARWcCos:fd-----:deny

OmniOS-Xeon:~ olaf$ tail /var/adm/messages
Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE: 
smbd[OMNIOS-XEON\olaf]: temporar share not found
Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE: 
smbd[OMNIOS-XEON\olaf]: olaf share not found
Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times

As you can see, the last letter of the share name in /var/adm/messages 
gets cut for the share "temporary", but not for my own share "olaf". 
However, my own share is neither visible nor accessible, while the other 
ones are.

Has anything changed about permissions with SMB2?

Thanks
Olaf

From danmcd at omniti.com  Wed Apr 20 23:25:20 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 20 Apr 2016 19:25:20 -0400
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <57180298.1080808@marzocchi.net>
References: <57180298.1080808@marzocchi.net>
Message-ID: <A71388AC-93ED-4C6C-8E88-5B1115AE51CD@omniti.com>

Yes it has.  Did you see Gordon Ross's mail about it?

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Apr 20, 2016, at 6:28 PM, Olaf Marzocchi <lists at marzocchi.net> wrote:
> 
> Has anything changed about permissions with SMB2?

From sford123 at ibbr.umd.edu  Thu Apr 21 01:48:31 2016
From: sford123 at ibbr.umd.edu (Steven Ford)
Date: Wed, 20 Apr 2016 21:48:31 -0400
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <57180298.1080808@marzocchi.net>
References: <57180298.1080808@marzocchi.net>
Message-ID: <CABrseZZHg0eraePFWvkK-wWxnCP5RvZC9mMoyBRqNodF7PuqGA@mail.gmail.com>

Olaf,

This reminds me a a problem I was having after updating to 151016. I posted
about it on stack exchange.
http://serverfault.com/questions/762160/where-is-my-zfs-smb-share. My
problem boiled down to the folder had needed everybody to have read
permissions for the SMB share to appear.


Hope this helps,

Steve

On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi <lists at marzocchi.net> wrote:

> I updated as indicated in the guide and to do that I had to uninstall some
> packages:
>
> serf at 1.3.8,5.11-0.151014:20151015T214958Z
> apr-util at 1.4.1,5.11-0.151014:20150508T204811Z apr at 1.5.1
> ,5.11-0.151014:20150529T175834Z
> uuid at 1.41.14,5.11-0.151014:20150508T153803Z
>
> After reboot I got two main issues.
>
> 1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I usually did
> in the past, both for SMB, local webserver/services, ... but I can still
> access the box when I use the plain IP.
>
> OmniOS-Xeon:~ olaf$ cat /etc/nodename
> OmniOS-Xeon
>
>
> 2) I cannot access one specific SMB share ("olaf") that was working
> perfectly before the update. Using the IP of the machine allows me to
> access the other shares, but not this one. It was also the one with the
> most restrictive access ACLs, but they look fine to me.
>
> OmniOS-Xeon:~ olaf$ sharemgr show
> ...
> zfs
>     zfs/tank/home/olaf
>           /tank/home/olaf
> [and more shares, all working]
>
> OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
> total 34
> drwx------+ 15 olaf     olaf          15 Oct 25 11:27 olaf
>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>               everyone@:rwxpdDaARWcCos:fd-----:deny
>
> OmniOS-Xeon:~ olaf$ tail /var/adm/messages
> Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: temporar share not found
> Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
> Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: olaf share not found
> Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>
> As you can see, the last letter of the share name in /var/adm/messages
> gets cut for the share "temporary", but not for my own share "olaf".
> However, my own share is neither visible nor accessible, while the other
> ones are.
>
> Has anything changed about permissions with SMB2?
>
> Thanks
> Olaf
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160420/24a57a79/attachment.html>

From stephan.budach at JVM.DE  Thu Apr 21 10:41:55 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Thu, 21 Apr 2016 12:41:55 +0200
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <CA+tR_Kwce_=qierL8oBBQVmHp5Rx6dLJZTqiN+dHndR-2-uPGA@mail.gmail.com>
References: <57137C6A.7050505@jvm.de>	<57138A80.6030203@jvm.de>	<16613422-27A5-4C0B-A76D-12079DFE991C@omniti.com>	<5713ED09.4000206@jvm.de>
	<CA+tR_Kwce_=qierL8oBBQVmHp5Rx6dLJZTqiN+dHndR-2-uPGA@mail.gmail.com>
Message-ID: <5718AE73.5010703@jvm.de>

Am 19.04.16 um 23:31 schrieb wuffers:
> You might want to check this old thread:
>
> http://lists.omniti.com/pipermail/omnios-discuss/2014-July/002927.html
>
> Richard Elling had some interesting insights on how the scrub works:
>
> "So I think the pool is not scheduling scrub I/Os very well. You can 
> increase the number of
> scrub I/Os in the scheduler by adjusting the zfs_vdev_scrub_max_active 
> tunable. The
> default is 2, but you'll have to consider that a share (in the stock 
> market sense) where
> the active sync reads and writes are getting 10 each. You can try 
> bumping up the value
> and see what happens over some time, perhaps 10 minutes or so -- too 
> short of a time
> and you won't get a good feeling for the impact (try this in off-peak 
> time).
> echo zfs_vdev_scrub_max_active/W0t5 | mdb -kw
> will change the value from 2 to 5, increasing its share of the total 
> I/O workload.
>
> You can see the progress of scan (scrubs do scan) workload by looking 
> at the ZFS
> debug messages.
> echo ::zfs_dbgmsg | mdb -k
> These will look mysterious... they are. But the interesting bits are 
> about how many blocks
> are visited in some amount of time (txg sync interval). Ideally, this 
> will change as you
> adjust zfs_vdev_scrub_max_active."
>
> I had to increase my zfs_vdev_scrub_max_active parameter higher than 
> 5, but it sounds like the default setting for that tunable is no 
> longer satisfactory for today's high performance systems.
>
> On Sun, Apr 17, 2016 at 4:07 PM, Stephan Budach <stephan.budach at jvm.de 
> <mailto:stephan.budach at jvm.de>> wrote:
>
>     Am 17.04.16 um 20:42 schrieb Dale Ghent:
>
>             On Apr 17, 2016, at 9:07 AM, Stephan Budach
>             <stephan.budach at JVM.DE <mailto:stephan.budach at JVM.DE>> wrote:
>
>             Well? searching the net somewhat more thoroughfully, I
>             came across an archived discussion which deals also with a
>             similar issue. Somewhere down the conversation, this
>             parameter got suggested:
>
>             echo "zfs_scrub_delay/W0" | mdb -kw
>
>             I just tried that as well and although the caculated speed
>             climbs rathet slowly up, iostat now shows approx. 380 MB/s
>             read from the devices, which rates at 24 MB/s per single
>             device * 8 *2.
>
>             Being curious, I issued a echo "zfs_scrub_delay/W1" | mdb
>             -kw to see what would happen and that command immediately
>             drowned the rate on each device down to 1.4 MB/s?
>
>             What is the rational behind that? Who wants to wait for
>             weeks for a scrub to finish? Usually, I am having znapzend
>             run as well, creating snapshots on a regular basis.
>             Wouldn't that hurt scrub performance even more?
>
>         zfs_scrub_delay is described here:
>
>         http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#63
>
>         How busy are your disks if you subtract the IO caused by a
>         scrub? Are you doing these scrubs with your VMs causing normal
>         IO as well?
>
>         Scrubbing, overall, is treated as a background maintenance
>         process. As such, it is designed to not interfere with
>         "production IO" requests. It used to be that scrubs ran as
>         fast as disk IO and bus bandwidth would allow, which in turn
>         severely impacted the IO performance of running applications,
>         and in some cases this would cause problems for production or
>         user services.  The scrub delay setting which you've
>         discovered is the main governor of this scrub throttle
>         code[1], and by setting it to 0, you are effectively removing
>         the delay it imposes on itself to allow non-scrub/resilvering
>         IO requests to finish.
>
>         The solution in your case is specific to yourself and how you
>         operate your servers and services. Can you accept degraded
>         application IO while a scrub or resilver is running? Can you
>         not? Maybe only during certain times?
>
>         /dale
>
>         [1]
>         http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#1841
>
>     I do get the notion if this, but if the increase from 0 to 1
>     reduces the throughput from 24Mb/s to 1MB/s, this seems way
>     overboard to me. Having to wait for a couple of hours when running
>     with 0 as opposed to days (up to 10) when running at 1  - on a 1.3
>     TB zpool - doesn't seem to be the right choice. If this tunable
>     offered some more room for choice, that would be great, but it
>     obviously doesn't.
>
>     It's the weekend and my VMs aren't excatly hogging their disks, so
>     there was plenty of I/O available? I'd wish for a more granular
>     setting regarding this setting.
>
>     Anyway, the scrub finished a couple of hours later and of course,
>     I can always set this tunable to 0, should I need it,
>
>     Thanks,
>
>     Stephan
>

Interesting read - and it surely works. If you set the tunable before 
you start the scrub you can immediately see the thoughput being much 
higher than with the standard setting. Now, what would be the tunable to 
use zfs_vdev_scrub_max_active or zfs_scrub_delay?

Cheers,
Stephan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/71c35ae2/attachment-0001.html>

From cks at cs.toronto.edu  Thu Apr 21 14:47:14 2016
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Thu, 21 Apr 2016 10:47:14 -0400
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: Your message of Thu, 21 Apr 2016 12:41:55 +0200.
	<5718AE73.5010703@jvm.de>
Message-ID: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>

[About ZFS scrub tunables:]
> Interesting read - and it surely works. If you set the tunable before
> you start the scrub you can immediately see the thoughput being much
> higher than with the standard setting. [...]

 It's perhaps worth noting here that the scrub rate shown in 'zpool
status' is a cumulative one, ie the average scrub rate since the scrub
started. As far as I know the only way to get the current scrub rate is
run 'zpool status' twice with some time in between and then look at how
much progress the scrub's made during that time.

 As such, increasing the scrub speed in the middle of what had been a
slow scrub up to that point probably won't make a massive or immediate
difference in the reported scrub rate. You should see it rising over
time, especially if you drastically speeded it up, but it's not any sort
of instant jump.

(You can always monitor iostat, but that mixes in other pool IO. There's
probably something clever that can be done with DTrace.)

 This may already be obvious and well known to people, but I figured
I'd mention it just in case.

	- cks

From richard.elling at richardelling.com  Thu Apr 21 16:36:10 2016
From: richard.elling at richardelling.com (Richard Elling)
Date: Thu, 21 Apr 2016 09:36:10 -0700
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>
References: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>
Message-ID: <012E847E-F393-4246-B538-AFBFE53A86C5@richardelling.com>


> On Apr 21, 2016, at 7:47 AM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
> 
> [About ZFS scrub tunables:]
>> Interesting read - and it surely works. If you set the tunable before
>> you start the scrub you can immediately see the thoughput being much
>> higher than with the standard setting. [...]
> 
> It's perhaps worth noting here that the scrub rate shown in 'zpool
> status' is a cumulative one, ie the average scrub rate since the scrub
> started. As far as I know the only way to get the current scrub rate is
> run 'zpool status' twice with some time in between and then look at how
> much progress the scrub's made during that time.

Scrub rate measured in IOPS or bandwidth is not useful. Neither is a reflection
of the work being performed in ZFS nor the drives.

> 
> As such, increasing the scrub speed in the middle of what had been a
> slow scrub up to that point probably won't make a massive or immediate
> difference in the reported scrub rate. You should see it rising over
> time, especially if you drastically speeded it up, but it's not any sort
> of instant jump.
> 
> (You can always monitor iostat, but that mixes in other pool IO. There's
> probably something clever that can be done with DTrace.)

I've got some dtrace that will show progress. However, it is only marginally
useful when you've got multiple datasets.

> 
> This may already be obvious and well known to people, but I figured
> I'd mention it just in case.

People fret about scrubs and resilvers, when they really shouldn't. In ZFS
accessing data also checks and does recovery, so anything they regularly
access will be unaffected by the subsequent scan. Over the years, I've tried
several ways to approach teaching people about failures and scrubs/resilvers,
but with limited success: some people just like to be afraid... Hollywood makes
a lot of money on them :-)
 -- richard



From lists at marzocchi.net  Thu Apr 21 17:40:19 2016
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Thu, 21 Apr 2016 19:40:19 +0200
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <A71388AC-93ED-4C6C-8E88-5B1115AE51CD@omniti.com>
References: <57180298.1080808@marzocchi.net>
	<A71388AC-93ED-4C6C-8E88-5B1115AE51CD@omniti.com>
Message-ID: <57191083.3020307@marzocchi.net>

Yes I saw it but it was about guest access, while my case is about a 
share restricted only to its owner because I wanted to be sure that 
private data stay private:

OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
total 34
drwx------+ 15 olaf     olaf          15 Oct 25 11:27 olaf
               user:olaf:rwxpdDaARWcCos:fd-----:allow
        group:2147483648:rwxpdDaARWcCos:fd-----:allow
               everyone@:rwxpdDaARWcCos:fd-----:deny


Olaf


On 21/04/2016 01:25, Dan McDonald wrote:
> Yes it has.  Did you see Gordon Ross's mail about it?
>
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
>> On Apr 20, 2016, at 6:28 PM, Olaf Marzocchi <lists at marzocchi.net> wrote:
>>
>> Has anything changed about permissions with SMB2?

From lists at marzocchi.net  Thu Apr 21 18:31:43 2016
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Thu, 21 Apr 2016 20:31:43 +0200
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <CABrseZZHg0eraePFWvkK-wWxnCP5RvZC9mMoyBRqNodF7PuqGA@mail.gmail.com>
References: <57180298.1080808@marzocchi.net>
	<CABrseZZHg0eraePFWvkK-wWxnCP5RvZC9mMoyBRqNodF7PuqGA@mail.gmail.com>
Message-ID: <57191C8F.5080000@marzocchi.net>

Thanks for the help.
Well first of all, how can the SMB server require everyone to have 
read/execute access? no more private shares?

Anyway, I got it working (for now) with:

drwxr-xr-x+ 16 olaf     olaf          16 Apr 21 20:25 olaf
               user:olaf:rwxpdDaARWcCos:fd-----:allow
        group:2147483648:rwxpdDaARWcCos:fd-----:allow
               everyone@:r-x---a-R-c--s:-------:allow
               everyone@:rwxpdDaARWcCos:fd-----:deny

Still, why am I able to access without issues another share that has 
(basically) the same permissions as I had on my folder?

d-----S---+ 27 root     temps        170 Apr 20 23:10 Temporary
               user:olaf:rwxpdDaARWcCos:fd-----:allow
        group:2147483648:rwxpdDaARWcCos:fd-----:allow
           user:transmis:--x---a-R-c--s:-------:allow
               everyone@:rwxpdDaARWcCos:fd-----:deny

I am member of group "temps" too.
This seems strange to me... it doesn't make sense.

It is working now, but any explanation? I don't like to have everyone rx 
permissions on my private folder, even if the ACLs will not propagate 
said permissions to its contents.

Thanks
Olaf




On 21/04/2016 03:48, Steven Ford wrote:
> Olaf,
>
> This reminds me a a problem I was having after updating to 151016. I
> posted about it on stack exchange.
> http://serverfault.com/questions/762160/where-is-my-zfs-smb-share. My
> problem boiled down to the folder had needed everybody to have read
> permissions for the SMB share to appear.
>
>
> Hope this helps,
>
> Steve
>
>
> On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi <lists at marzocchi.net
> <mailto:lists at marzocchi.net>> wrote:
>
>     I updated as indicated in the guide and to do that I had to
>     uninstall some packages:
>
>     serf at 1.3.8,5.11-0.151014:20151015T214958Z
>     apr-util at 1.4.1,5.11-0.151014:20150508T204811Z
>     apr at 1.5.1,5.11-0.151014:20150529T175834Z
>     uuid at 1.41.14,5.11-0.151014:20150508T153803Z
>
>     After reboot I got two main issues.
>
>     1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I
>     usually did in the past, both for SMB, local webserver/services, ...
>     but I can still access the box when I use the plain IP.
>
>     OmniOS-Xeon:~ olaf$ cat /etc/nodename
>     OmniOS-Xeon
>
>
>     2) I cannot access one specific SMB share ("olaf") that was working
>     perfectly before the update. Using the IP of the machine allows me
>     to access the other shares, but not this one. It was also the one
>     with the most restrictive access ACLs, but they look fine to me.
>
>     OmniOS-Xeon:~ olaf$ sharemgr show
>     ...
>     zfs
>          zfs/tank/home/olaf
>                /tank/home/olaf
>     [and more shares, all working]
>
>     OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
>     total 34
>     drwx------+ 15 olaf     olaf          15 Oct 25 11:27 olaf
>                    user:olaf:rwxpdDaARWcCos:fd-----:allow
>             group:2147483648 <tel:2147483648>:rwxpdDaARWcCos:fd-----:allow
>                    everyone@:rwxpdDaARWcCos:fd-----:deny
>
>     OmniOS-Xeon:~ olaf$ tail /var/adm/messages
>     Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>     smbd[OMNIOS-XEON\olaf]: temporar share not found
>     Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
>     Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>     smbd[OMNIOS-XEON\olaf]: olaf share not found
>     Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>
>     As you can see, the last letter of the share name in
>     /var/adm/messages gets cut for the share "temporary", but not for my
>     own share "olaf". However, my own share is neither visible nor
>     accessible, while the other ones are.
>
>     Has anything changed about permissions with SMB2?
>
>     Thanks
>     Olaf
>     _______________________________________________
>     OmniOS-discuss mailing list
>     OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>

From sford123 at ibbr.umd.edu  Thu Apr 21 18:59:40 2016
From: sford123 at ibbr.umd.edu (Steven Ford)
Date: Thu, 21 Apr 2016 14:59:40 -0400
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <57191C8F.5080000@marzocchi.net>
References: <57180298.1080808@marzocchi.net>
	<CABrseZZHg0eraePFWvkK-wWxnCP5RvZC9mMoyBRqNodF7PuqGA@mail.gmail.com>
	<57191C8F.5080000@marzocchi.net>
Message-ID: <CABrseZaQtNizhnpRBpWLhA_hpdHynh83-n0Z_bGHG3e8au4bwg@mail.gmail.com>

Olaf,

The large number of changes between the version of OpenIndiana I was
running and r151016 made it daunting to pinpoint the problem. If this is
the same problem, I think it's safe to say the change was between r151014
and r151016. I'm not very savvy with the source code but I'll take a look.

Regards,

Steve

On Thu, Apr 21, 2016 at 2:31 PM, Olaf Marzocchi <lists at marzocchi.net> wrote:

> Thanks for the help.
> Well first of all, how can the SMB server require everyone to have
> read/execute access? no more private shares?
>
> Anyway, I got it working (for now) with:
>
> drwxr-xr-x+ 16 olaf     olaf          16 Apr 21 20:25 olaf
>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>               everyone@:r-x---a-R-c--s:-------:allow
>               everyone@:rwxpdDaARWcCos:fd-----:deny
>
> Still, why am I able to access without issues another share that has
> (basically) the same permissions as I had on my folder?
>
> d-----S---+ 27 root     temps        170 Apr 20 23:10 Temporary
>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>           user:transmis:--x---a-R-c--s:-------:allow
>               everyone@:rwxpdDaARWcCos:fd-----:deny
>
> I am member of group "temps" too.
> This seems strange to me... it doesn't make sense.
>
> It is working now, but any explanation? I don't like to have everyone rx
> permissions on my private folder, even if the ACLs will not propagate said
> permissions to its contents.
>
> Thanks
> Olaf
>
>
>
>
> On 21/04/2016 03:48, Steven Ford wrote:
>
>> Olaf,
>>
>> This reminds me a a problem I was having after updating to 151016. I
>> posted about it on stack exchange.
>> http://serverfault.com/questions/762160/where-is-my-zfs-smb-share. My
>> problem boiled down to the folder had needed everybody to have read
>> permissions for the SMB share to appear.
>>
>>
>> Hope this helps,
>>
>> Steve
>>
>>
>> On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi <lists at marzocchi.net
>> <mailto:lists at marzocchi.net>> wrote:
>>
>>     I updated as indicated in the guide and to do that I had to
>>     uninstall some packages:
>>
>>     serf at 1.3.8,5.11-0.151014:20151015T214958Z
>>     apr-util at 1.4.1,5.11-0.151014:20150508T204811Z
>>     apr at 1.5.1,5.11-0.151014:20150529T175834Z
>>     uuid at 1.41.14,5.11-0.151014:20150508T153803Z
>>
>>     After reboot I got two main issues.
>>
>>     1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I
>>     usually did in the past, both for SMB, local webserver/services, ...
>>     but I can still access the box when I use the plain IP.
>>
>>     OmniOS-Xeon:~ olaf$ cat /etc/nodename
>>     OmniOS-Xeon
>>
>>
>>     2) I cannot access one specific SMB share ("olaf") that was working
>>     perfectly before the update. Using the IP of the machine allows me
>>     to access the other shares, but not this one. It was also the one
>>     with the most restrictive access ACLs, but they look fine to me.
>>
>>     OmniOS-Xeon:~ olaf$ sharemgr show
>>     ...
>>     zfs
>>          zfs/tank/home/olaf
>>                /tank/home/olaf
>>     [and more shares, all working]
>>
>>     OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
>>     total 34
>>     drwx------+ 15 olaf     olaf          15 Oct 25 11:27 olaf
>>                    user:olaf:rwxpdDaARWcCos:fd-----:allow
>>             group:2147483648 <tel:2147483648
>> >:rwxpdDaARWcCos:fd-----:allow
>>                    everyone@:rwxpdDaARWcCos:fd-----:deny
>>
>>     OmniOS-Xeon:~ olaf$ tail /var/adm/messages
>>     Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>>     smbd[OMNIOS-XEON\olaf]: temporar share not found
>>     Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
>>     Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>>     smbd[OMNIOS-XEON\olaf]: olaf share not found
>>     Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>>
>>     As you can see, the last letter of the share name in
>>     /var/adm/messages gets cut for the share "temporary", but not for my
>>     own share "olaf". However, my own share is neither visible nor
>>     accessible, while the other ones are.
>>
>>     Has anything changed about permissions with SMB2?
>>
>>     Thanks
>>     Olaf
>>     _______________________________________________
>>     OmniOS-discuss mailing list
>>     OmniOS-discuss at lists.omniti.com <mailto:
>> OmniOS-discuss at lists.omniti.com>
>>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/67cbba4b/attachment-0001.html>

From sford123 at ibbr.umd.edu  Thu Apr 21 19:21:17 2016
From: sford123 at ibbr.umd.edu (Steven Ford)
Date: Thu, 21 Apr 2016 15:21:17 -0400
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <CABrseZaQtNizhnpRBpWLhA_hpdHynh83-n0Z_bGHG3e8au4bwg@mail.gmail.com>
References: <57180298.1080808@marzocchi.net>
	<CABrseZZHg0eraePFWvkK-wWxnCP5RvZC9mMoyBRqNodF7PuqGA@mail.gmail.com>
	<57191C8F.5080000@marzocchi.net>
	<CABrseZaQtNizhnpRBpWLhA_hpdHynh83-n0Z_bGHG3e8au4bwg@mail.gmail.com>
Message-ID: <CABrseZZwhz-MTmm=GaCXuXnojjwSp_kAFf35VmofpjbSgVn-9A@mail.gmail.com>

Between r151014 and r151016, the only commits that look relevant to me are:

https://github.com/omniti-labs/illumos-omnios/commit/8f5190a540d64d2debee6664bbc740e4c38f5b7f
https://github.com/omniti-labs/illumos-omnios/commit/0f92170f1ec2737ee5a0e51b5f74093904811452

However, I am not familiar with the source code nor with system programming
in general.

Dan, since you made these commits, do you have any thoughts? Could these be
related?

Thanks,

Steve


On Thu, Apr 21, 2016 at 2:59 PM, Steven Ford <sford123 at ibbr.umd.edu> wrote:

> Olaf,
>
> The large number of changes between the version of OpenIndiana I was
> running and r151016 made it daunting to pinpoint the problem. If this is
> the same problem, I think it's safe to say the change was between r151014
> and r151016. I'm not very savvy with the source code but I'll take a look.
>
> Regards,
>
> Steve
>
> On Thu, Apr 21, 2016 at 2:31 PM, Olaf Marzocchi <lists at marzocchi.net>
> wrote:
>
>> Thanks for the help.
>> Well first of all, how can the SMB server require everyone to have
>> read/execute access? no more private shares?
>>
>> Anyway, I got it working (for now) with:
>>
>> drwxr-xr-x+ 16 olaf     olaf          16 Apr 21 20:25 olaf
>>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>>               everyone@:r-x---a-R-c--s:-------:allow
>>               everyone@:rwxpdDaARWcCos:fd-----:deny
>>
>> Still, why am I able to access without issues another share that has
>> (basically) the same permissions as I had on my folder?
>>
>> d-----S---+ 27 root     temps        170 Apr 20 23:10 Temporary
>>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>>           user:transmis:--x---a-R-c--s:-------:allow
>>               everyone@:rwxpdDaARWcCos:fd-----:deny
>>
>> I am member of group "temps" too.
>> This seems strange to me... it doesn't make sense.
>>
>> It is working now, but any explanation? I don't like to have everyone rx
>> permissions on my private folder, even if the ACLs will not propagate said
>> permissions to its contents.
>>
>> Thanks
>> Olaf
>>
>>
>>
>>
>> On 21/04/2016 03:48, Steven Ford wrote:
>>
>>> Olaf,
>>>
>>> This reminds me a a problem I was having after updating to 151016. I
>>> posted about it on stack exchange.
>>> http://serverfault.com/questions/762160/where-is-my-zfs-smb-share. My
>>> problem boiled down to the folder had needed everybody to have read
>>> permissions for the SMB share to appear.
>>>
>>>
>>> Hope this helps,
>>>
>>> Steve
>>>
>>>
>>> On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi <lists at marzocchi.net
>>> <mailto:lists at marzocchi.net>> wrote:
>>>
>>>     I updated as indicated in the guide and to do that I had to
>>>     uninstall some packages:
>>>
>>>     serf at 1.3.8,5.11-0.151014:20151015T214958Z
>>>     apr-util at 1.4.1,5.11-0.151014:20150508T204811Z
>>>     apr at 1.5.1,5.11-0.151014:20150529T175834Z
>>>     uuid at 1.41.14,5.11-0.151014:20150508T153803Z
>>>
>>>     After reboot I got two main issues.
>>>
>>>     1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I
>>>     usually did in the past, both for SMB, local webserver/services, ...
>>>     but I can still access the box when I use the plain IP.
>>>
>>>     OmniOS-Xeon:~ olaf$ cat /etc/nodename
>>>     OmniOS-Xeon
>>>
>>>
>>>     2) I cannot access one specific SMB share ("olaf") that was working
>>>     perfectly before the update. Using the IP of the machine allows me
>>>     to access the other shares, but not this one. It was also the one
>>>     with the most restrictive access ACLs, but they look fine to me.
>>>
>>>     OmniOS-Xeon:~ olaf$ sharemgr show
>>>     ...
>>>     zfs
>>>          zfs/tank/home/olaf
>>>                /tank/home/olaf
>>>     [and more shares, all working]
>>>
>>>     OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
>>>     total 34
>>>     drwx------+ 15 olaf     olaf          15 Oct 25 11:27 olaf
>>>                    user:olaf:rwxpdDaARWcCos:fd-----:allow
>>>             group:2147483648 <tel:2147483648
>>> >:rwxpdDaARWcCos:fd-----:allow
>>>                    everyone@:rwxpdDaARWcCos:fd-----:deny
>>>
>>>     OmniOS-Xeon:~ olaf$ tail /var/adm/messages
>>>     Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>>>     smbd[OMNIOS-XEON\olaf]: temporar share not found
>>>     Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
>>>     Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>>>     smbd[OMNIOS-XEON\olaf]: olaf share not found
>>>     Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>>>
>>>     As you can see, the last letter of the share name in
>>>     /var/adm/messages gets cut for the share "temporary", but not for my
>>>     own share "olaf". However, my own share is neither visible nor
>>>     accessible, while the other ones are.
>>>
>>>     Has anything changed about permissions with SMB2?
>>>
>>>     Thanks
>>>     Olaf
>>>     _______________________________________________
>>>     OmniOS-discuss mailing list
>>>     OmniOS-discuss at lists.omniti.com <mailto:
>>> OmniOS-discuss at lists.omniti.com>
>>>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/7097ddfc/attachment.html>

From natxo.asenjo at gmail.com  Thu Apr 21 19:29:53 2016
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Thu, 21 Apr 2016 21:29:53 +0200
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <57191C8F.5080000@marzocchi.net>
References: <57180298.1080808@marzocchi.net>
	<CABrseZZHg0eraePFWvkK-wWxnCP5RvZC9mMoyBRqNodF7PuqGA@mail.gmail.com>
	<57191C8F.5080000@marzocchi.net>
Message-ID: <CAHBEJzW6SSz7qU_nm77FH6oxVF1x9FRQhnAm0KvL5KK2kksgfA@mail.gmail.com>

Hi Olaf

On Thu, Apr 21, 2016 at 8:31 PM, Olaf Marzocchi <lists at marzocchi.net> wrote:

> Thanks for the help.
> Well first of all, how can the SMB server require everyone to have
> read/execute access? no more private shares?
>
> Anyway, I got it working (for now) with:
>
> drwxr-xr-x+ 16 olaf     olaf          16 Apr 21 20:25 olaf
>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>               everyone@:r-x---a-R-c--s:-------:allow
>               everyone@:rwxpdDaARWcCos:fd-----:deny
>
> Still, why am I able to access without issues another share that has
> (basically) the same permissions as I had on my folder?
>
> d-----S---+ 27 root     temps        170 Apr 20 23:10 Temporary
>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>           user:transmis:--x---a-R-c--s:-------:allow
>               everyone@:rwxpdDaARWcCos:fd-----:deny
>
> I am member of group "temps" too.
> This seems strange to me... it doesn't make sense.
>
> It is working now, but any explanation? I don't like to have everyone rx
> permissions on my private folder, even if the ACLs will not propagate said
> permissions to its contents.
>

I do not know exactly what has changed but I can tell you private shares
still work.

This share is only accessible for one one user:

root at zfstank:/root# /usr/bin/ls -Vd /tank/fotos/
d---------+311 root     root         322 Mar 11 14:00 /tank/fotos/
              user:username:rwxpdDaARWcCos:fd-----:allow
root at zfstank:/root# ls -ld /tank/fotos/
d---------+ 311 root root 322 Mar 11 14:00 /tank/fotos/

I do not remember exactly when I set it up, but it has been working at
least since version 151014

HTH,

-- 
regards,
Natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/20869924/attachment.html>

From danmcd at omniti.com  Thu Apr 21 19:49:00 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 21 Apr 2016 15:49:00 -0400
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <CABrseZZwhz-MTmm=GaCXuXnojjwSp_kAFf35VmofpjbSgVn-9A@mail.gmail.com>
References: <57180298.1080808@marzocchi.net>
	<CABrseZZHg0eraePFWvkK-wWxnCP5RvZC9mMoyBRqNodF7PuqGA@mail.gmail.com>
	<57191C8F.5080000@marzocchi.net>
	<CABrseZaQtNizhnpRBpWLhA_hpdHynh83-n0Z_bGHG3e8au4bwg@mail.gmail.com>
	<CABrseZZwhz-MTmm=GaCXuXnojjwSp_kAFf35VmofpjbSgVn-9A@mail.gmail.com>
Message-ID: <8AE85116-3B46-4F43-8DDD-126A2CFDBDA8@omniti.com>


> On Apr 21, 2016, at 3:21 PM, Steven Ford <sford123 at ibbr.umd.edu> wrote:
> 
> Dan, since you made these commits, do you have any thoughts? Could these be related?
> 

Those are both kernel panic fixers (improper release after failure).

The non-global-zone SMB/CIFS fixes went into r151016, along with other fixes.

	https://www.listbox.com/member/archive/182179/2015/04/sort/time_rev/page/1/entry/5:475/20150428134823:C190ED2C-EDCE-11E4-98D2-8987C5A0D07F/

That's the illumos-gate flag day for SMB-in-a-zone.  There are other fixes around that time in illumos-gate that got sucked into illumos-omnios as well.  I'd investigate those.

Dan


From danmcd at omniti.com  Thu Apr 21 21:17:32 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 21 Apr 2016 17:17:32 -0400
Subject: [OmniOS-discuss] LTS (r151014) April 21st update
Message-ID: <4BB1B57F-030A-422A-A183-685A06D75BA0@omniti.com>

The Long-Term Stable release (r151014) has received an update.  The release notes for r151014:

	http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014

have the details.  A customer-critical ZFS bugfix suite (illumos 6841-6843) and some HW bumps highlight this update.

It's a rebuild of illumos-omnios, so a reboot will be necessary.  Release media (USB-DD, ISO, Kayak) has been updated too.

Dan


From mir at miras.org  Thu Apr 21 21:50:52 2016
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 21 Apr 2016 23:50:52 +0200
Subject: [OmniOS-discuss] LTS (r151014) April 21st update
In-Reply-To: <4BB1B57F-030A-422A-A183-685A06D75BA0@omniti.com>
References: <4BB1B57F-030A-422A-A183-685A06D75BA0@omniti.com>
Message-ID: <20160421235052.445e0b77@sleipner.datanom.net>

On Thu, 21 Apr 2016 17:17:32 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> 
> have the details.  A customer-critical ZFS bugfix suite (illumos 6841-6843) and some HW bumps highlight this update.
> 
> It's a rebuild of illumos-omnios, so a reboot will be necessary.  Release media (USB-DD, ISO, Kayak) has been updated too.
> 
The only changes/fix of importance to me is this:
OpenSSH 7.2p2 fixes for GSSAPI key exchange

Provided we have disabled GSSAPI authorization how important will it be
to update OpenSSH?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
  It's more than magnificent-it's mediocre. -Samuel Goldwyn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/22e44c20/attachment.bin>

From mir at miras.org  Thu Apr 21 21:56:19 2016
From: mir at miras.org (Michael Rasmussen)
Date: Thu, 21 Apr 2016 23:56:19 +0200
Subject: [OmniOS-discuss] Wiki is slightly broken
Message-ID: <20160421235619.155ea112@sleipner.datanom.net>

Hi Dan,

The following error prevents the wiki to function under webkit based
browsers:

Mixed Content: The page at 'https://omnios.omniti.com/wiki.php/WikiStart' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'http://omnios.omniti.com/post-attachment.php'. This endpoint should be made available over a secure connection.
about:blank:1 Mixed Content: The page at 'https://omnios.omniti.com/wiki.php/WikiStart' was loaded over HTTPS, but requested an insecure resource 'http://omnios.omniti.com//mtrack.css'. This request has been blocked; the content must be served over HTTPS.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
The sheep that fly over your head are soon to land.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/bb7b0680/attachment.bin>

From danmcd at omniti.com  Thu Apr 21 22:54:47 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 21 Apr 2016 18:54:47 -0400
Subject: [OmniOS-discuss] LTS (r151014) April 21st update
In-Reply-To: <20160421235052.445e0b77@sleipner.datanom.net>
References: <4BB1B57F-030A-422A-A183-685A06D75BA0@omniti.com>
	<20160421235052.445e0b77@sleipner.datanom.net>
Message-ID: <4844C329-6A50-4700-9C5D-0B7BF9A31750@omniti.com>

It's not critical for people who don't use the GSSAPI *Key exchange*.

You're good.

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Apr 21, 2016, at 5:50 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Thu, 21 Apr 2016 17:17:32 -0400
> Dan McDonald <danmcd at omniti.com> wrote:
> 
>> 
>> have the details.  A customer-critical ZFS bugfix suite (illumos 6841-6843) and some HW bumps highlight this update.
>> 
>> It's a rebuild of illumos-omnios, so a reboot will be necessary.  Release media (USB-DD, ISO, Kayak) has been updated too.
> The only changes/fix of importance to me is this:
> OpenSSH 7.2p2 fixes for GSSAPI key exchange
> 
> Provided we have disabled GSSAPI authorization how important will it be
> to update OpenSSH?
> 
> -- 
> Hilsen/Regards
> Michael Rasmussen
> 
> Get my public GnuPG keys:
> michael <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
>  It's more than magnificent-it's mediocre. -Samuel Goldwyn
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From mtalbott at lji.org  Fri Apr 22 01:27:54 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 21 Apr 2016 18:27:54 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory rfc2307
Message-ID: <042D5730-31FC-40BD-A7EC-A150FE67DBB7@lji.org>

I hope someone out there can help me solve the last piece of a puzzle I've been banging my head over getting OmniOS to cooperate with an Active Directory LDAP setup with uid/gid mapping set via AD Unix Attributes. I've been using winbind previously to do this mapping via rfc2307, but, I'd like to get rid of it and use LDAP instead. I seem to have all usernames/uids/gids mapping correctly thus far, but, the problem is none of the groups have any members shown via getent group. It'll list the groups and the proper group IDs as set in AD, but, no members :( I know there's gotta be some simple mapping I'm missing or set incorrectly, but I just can't seem to find it.

Any help is appreciated.

By the way, once the problem is fixed here, maybe it should be added to http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP <http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP> since it's still "TODO" ;)

Here's the binding method I'm using:

#####

ldapclient manual \
 -a credentialLevel=proxy \
 -a authenticationMethod=simple \
 -a "proxyDN=cn=ldap_service_user,cn=Users,dc=ad,dc=xyz,dc=com" \
 -a defaultSearchBase=dc=ad,dc=xyz,dc=com \
 -a domainName=ad.xyz.com \
 -a "defaultServerList=10.x.x.x" \
 -a attributeMap=passwd:gecos=cn \
 -a attributeMap=shadow:gecos=cn \
 -a attributeMap=group:gecos=cn \
 -a attributeMap=passwd:uid=sAMAccountName \
 -a attributeMap=shadow:uid=sAMAccountName \
 -a attributeMap=passwd:homedirectory=unixHomeDirectory \
 -a attributeMap=shadow:shadowLastChange=pwdLastSet \
 -a attributeMap=group:uniqueMember=member \
 -a objectClassMap=passwd:posixAccount=user \
 -a objectClassMap=shadow:shadowAccount=user \
 -a objectClassMap=group:posixGroup=group \
 -a "serviceSearchDescriptor=group:dc=ad,dc=xyz,dc=com?sub?(&(objectClass=group)(gidNumber=*))" \
 -a "serviceSearchDescriptor=passwd:cn=users,dc=ad,dc=xyz,dc=com?sub?(&(objectClass=user)(uidNumber=*))"

# I've also tried adding this to no avail:
# -a attributeMap=group:gid=sAMAccountName \

# fix nsswitch
cp /etc/nsswitch.dns /etc/nsswitch.conf
sed -i 's at passwd:     files at passwd:     files ldap at g' /etc/nsswitch.conf
sed -i 's at group:      files at group:      files ldap at g' /etc/nsswitch.conf

# reset the client and flush cache
svcadm disable svc:/network/ldap/client:default
sleep 2
svcadm enable svc:/network/ldap/client:default
sleep 1
svcs svc:/network/ldap/client:default
nscd -i passwd

# show connection sanity
/usr/lib/ldap/ldap_cachemgr -g

# profit
getent passwd
getent group

#####

I've also set this in /etc/system so it'll handle more than the 16 group limit (which previously solved issues I was having in winbind)

set ngroups_max = 1024 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/9f8b4e24/attachment.html>

From mtalbott at lji.org  Fri Apr 22 01:27:54 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 21 Apr 2016 18:27:54 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory rfc2307
Message-ID: <042D5730-31FC-40BD-A7EC-A150FE67DBB7@lji.org>

I hope someone out there can help me solve the last piece of a puzzle I've been banging my head over getting OmniOS to cooperate with an Active Directory LDAP setup with uid/gid mapping set via AD Unix Attributes. I've been using winbind previously to do this mapping via rfc2307, but, I'd like to get rid of it and use LDAP instead. I seem to have all usernames/uids/gids mapping correctly thus far, but, the problem is none of the groups have any members shown via getent group. It'll list the groups and the proper group IDs as set in AD, but, no members :( I know there's gotta be some simple mapping I'm missing or set incorrectly, but I just can't seem to find it.

Any help is appreciated.

By the way, once the problem is fixed here, maybe it should be added to http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP <http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP> since it's still "TODO" ;)

Here's the binding method I'm using:

#####

ldapclient manual \
 -a credentialLevel=proxy \
 -a authenticationMethod=simple \
 -a "proxyDN=cn=ldap_service_user,cn=Users,dc=ad,dc=xyz,dc=com" \
 -a defaultSearchBase=dc=ad,dc=xyz,dc=com \
 -a domainName=ad.xyz.com \
 -a "defaultServerList=10.x.x.x" \
 -a attributeMap=passwd:gecos=cn \
 -a attributeMap=shadow:gecos=cn \
 -a attributeMap=group:gecos=cn \
 -a attributeMap=passwd:uid=sAMAccountName \
 -a attributeMap=shadow:uid=sAMAccountName \
 -a attributeMap=passwd:homedirectory=unixHomeDirectory \
 -a attributeMap=shadow:shadowLastChange=pwdLastSet \
 -a attributeMap=group:uniqueMember=member \
 -a objectClassMap=passwd:posixAccount=user \
 -a objectClassMap=shadow:shadowAccount=user \
 -a objectClassMap=group:posixGroup=group \
 -a "serviceSearchDescriptor=group:dc=ad,dc=xyz,dc=com?sub?(&(objectClass=group)(gidNumber=*))" \
 -a "serviceSearchDescriptor=passwd:cn=users,dc=ad,dc=xyz,dc=com?sub?(&(objectClass=user)(uidNumber=*))"

# I've also tried adding this to no avail:
# -a attributeMap=group:gid=sAMAccountName \

# fix nsswitch
cp /etc/nsswitch.dns /etc/nsswitch.conf
sed -i 's at passwd:     files at passwd:     files ldap at g' /etc/nsswitch.conf
sed -i 's at group:      files at group:      files ldap at g' /etc/nsswitch.conf

# reset the client and flush cache
svcadm disable svc:/network/ldap/client:default
sleep 2
svcadm enable svc:/network/ldap/client:default
sleep 1
svcs svc:/network/ldap/client:default
nscd -i passwd

# show connection sanity
/usr/lib/ldap/ldap_cachemgr -g

# profit
getent passwd
getent group

#####

I've also set this in /etc/system so it'll handle more than the 16 group limit (which previously solved issues I was having in winbind)

set ngroups_max = 1024 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160421/9f8b4e24/attachment-0003.html>

From mtalbott at lji.org  Fri Apr 22 01:39:08 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 21 Apr 2016 18:39:08 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
Message-ID: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>

I've been trying to figure out where I'm going wrong and just can't seem to pinpoint the problem. I'm trying to move a few servers away from winbind which was using rfc2307 mappings for uid/gid mapping and use LDAP instead. Using the below configuration username/userid groupname/groupid match the ids set in AD. However, for some reason, getent group shows all the groups with proper ids, but, none of the groups have any members in there :( getent passwd seems to work fine. So I'm thinking I'm missing some critical mapping to make this happen, but, just can't seem to figure out where I'm going wrong. Oh, and I'm running r151018.

Any help is much appreciated.

By the way, once this is resolved, maybe it should get posted under here: http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP


Here's what I use to bind:

# setup ldap like so
ldapclient uninit
ldapclient manual \
 -a credentialLevel=proxy \
 -a authenticationMethod=simple \
 -a "proxyDN=cn=xyz_ldap_service,cn=Users,dc=ad,dc=xyz,dc=com" \
 -a defaultSearchBase=dc=ad,dc=xyz,dc=com \
 -a domainName=ad.xyz.com \
 -a "defaultServerList=10.x.x.x" \
 -a attributeMap=passwd:gecos=cn \
 -a attributeMap=shadow:gecos=cn \
 -a attributeMap=group:gecos=cn \
 -a attributeMap=passwd:uid=sAMAccountName \
 -a attributeMap=shadow:uid=sAMAccountName \
 -a attributeMap=passwd:homedirectory=unixHomeDirectory \
 -a attributeMap=shadow:shadowLastChange=pwdLastSet \
 -a attributeMap=group:uniqueMember=member \
 -a objectClassMap=passwd:posixAccount=user \
 -a objectClassMap=shadow:shadowAccount=user \
 -a objectClassMap=group:posixGroup=group \
 -a "serviceSearchDescriptor=group:dc=ad,dc=xyz,dc=com?sub?(&(objectClass=group)(gidNumber=*))" \
 -a "serviceSearchDescriptor=passwd:cn=users,dc=ad,dc=xyz,dc=com?sub?(&(objectClass=user)(uidNumber=*))"

#enter password when prompted

# remove "ldap" from all entries in /etc/nsswitch.conf except for passwd and group
cp /etc/nsswitch.dns /etc/nsswitch.conf
sed -i 's at passwd:     files at passwd:     files ldap at g' /etc/nsswitch.conf
sed -i 's at group:      files at group:      files ldap at g' /etc/nsswitch.conf

# restart ldap client
svcadm disable svc:/network/ldap/client:default
sleep 2
svcadm enable svc:/network/ldap/client:default
sleep 1
svcs svc:/network/ldap/client:default
nscd -i passwd

# sanity checks
/usr/lib/ldap/ldap_cachemgr -g
svcs \*ldap\*
svcs -l network/ldap/client:default
nscd -i passwd
ldapclient list
ldaplist passwd
ldaplist group
/usr/lib/ldap/ldap_cachemgr -g

# profit
getent passwd
getent group


From mtalbott at lji.org  Fri Apr 22 01:43:29 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 21 Apr 2016 18:43:29 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
Message-ID: <F4F100F3-F466-42E6-939B-90D510569B08@lji.org>

Sorry for the duplicate thread. My email client died when I hit send and I thought it didn't go the first time, but I guess it did :(


> On Apr 21, 2016, at 6:39 PM, Michael Talbott <mtalbott at lji.org> wrote:
> 
> I've been trying to figure out where I'm going wrong and just can't seem to pinpoint the problem. I'm trying to move a few servers away from winbind which was using rfc2307 mappings for uid/gid mapping and use LDAP instead. Using the below configuration username/userid groupname/groupid match the ids set in AD. However, for some reason, getent group shows all the groups with proper ids, but, none of the groups have any members in there :( getent passwd seems to work fine. So I'm thinking I'm missing some critical mapping to make this happen, but, just can't seem to figure out where I'm going wrong. Oh, and I'm running r151018.
> 
> Any help is much appreciated.
> 
> By the way, once this is resolved, maybe it should get posted under here: http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP
> 
> 
> Here's what I use to bind:
> 
> # setup ldap like so
> ldapclient uninit
> ldapclient manual \
> -a credentialLevel=proxy \
> -a authenticationMethod=simple \
> -a "proxyDN=cn=xyz_ldap_service,cn=Users,dc=ad,dc=xyz,dc=com" \
> -a defaultSearchBase=dc=ad,dc=xyz,dc=com \
> -a domainName=ad.xyz.com \
> -a "defaultServerList=10.x.x.x" \
> -a attributeMap=passwd:gecos=cn \
> -a attributeMap=shadow:gecos=cn \
> -a attributeMap=group:gecos=cn \
> -a attributeMap=passwd:uid=sAMAccountName \
> -a attributeMap=shadow:uid=sAMAccountName \
> -a attributeMap=passwd:homedirectory=unixHomeDirectory \
> -a attributeMap=shadow:shadowLastChange=pwdLastSet \
> -a attributeMap=group:uniqueMember=member \
> -a objectClassMap=passwd:posixAccount=user \
> -a objectClassMap=shadow:shadowAccount=user \
> -a objectClassMap=group:posixGroup=group \
> -a "serviceSearchDescriptor=group:dc=ad,dc=xyz,dc=com?sub?(&(objectClass=group)(gidNumber=*))" \
> -a "serviceSearchDescriptor=passwd:cn=users,dc=ad,dc=xyz,dc=com?sub?(&(objectClass=user)(uidNumber=*))"
> 
> #enter password when prompted
> 
> # remove "ldap" from all entries in /etc/nsswitch.conf except for passwd and group
> cp /etc/nsswitch.dns /etc/nsswitch.conf
> sed -i 's at passwd:     files at passwd:     files ldap at g' /etc/nsswitch.conf
> sed -i 's at group:      files at group:      files ldap at g' /etc/nsswitch.conf
> 
> # restart ldap client
> svcadm disable svc:/network/ldap/client:default
> sleep 2
> svcadm enable svc:/network/ldap/client:default
> sleep 1
> svcs svc:/network/ldap/client:default
> nscd -i passwd
> 
> # sanity checks
> /usr/lib/ldap/ldap_cachemgr -g
> svcs \*ldap\*
> svcs -l network/ldap/client:default
> nscd -i passwd
> ldapclient list
> ldaplist passwd
> ldaplist group
> /usr/lib/ldap/ldap_cachemgr -g
> 
> # profit
> getent passwd
> getent group
> 


From gordon.w.ross at gmail.com  Fri Apr 22 01:53:18 2016
From: gordon.w.ross at gmail.com (Gordon Ross)
Date: Thu, 21 Apr 2016 21:53:18 -0400
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <57180298.1080808@marzocchi.net>
References: <57180298.1080808@marzocchi.net>
Message-ID: <CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>

I'm not sure how anyone ever gets access when your ACL has this ACE:
        everyone@:rwxpdDaARWcCos:fd-----:deny

Every long has the group "everyone" as a member, therefore that ACE
will match every logon.  The ace also lists every possible permission,
so nothing should get through, no matter what allow ACEs might also
exist.

One thing to be aware of is that ZFS (and Unix in general) checks
Execute access when you try to "traverse" through a directory (path
name resolution).  If you're copying ACLs from a Windows server, you
may need to add some ACEs at various levels in your file hierarchy to
grant execute to whatever users and/or groups should be able to
traverse.
(The easiest way would be: chmod A+everyone@:x:fd:allow)

Windows servers normally run with a special privilege that makes the
SMB server threads exempt from traverse permission checking, for
reasons of efficiency.

On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi <lists at marzocchi.net> wrote:
> I updated as indicated in the guide and to do that I had to uninstall some
> packages:
>
> serf at 1.3.8,5.11-0.151014:20151015T214958Z
> apr-util at 1.4.1,5.11-0.151014:20150508T204811Z
> apr at 1.5.1,5.11-0.151014:20150529T175834Z
> uuid at 1.41.14,5.11-0.151014:20150508T153803Z
>
> After reboot I got two main issues.
>
> 1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I usually did in
> the past, both for SMB, local webserver/services, ... but I can still access
> the box when I use the plain IP.
>
> OmniOS-Xeon:~ olaf$ cat /etc/nodename
> OmniOS-Xeon
>
>
> 2) I cannot access one specific SMB share ("olaf") that was working
> perfectly before the update. Using the IP of the machine allows me to access
> the other shares, but not this one. It was also the one with the most
> restrictive access ACLs, but they look fine to me.
>
> OmniOS-Xeon:~ olaf$ sharemgr show
> ...
> zfs
>     zfs/tank/home/olaf
>           /tank/home/olaf
> [and more shares, all working]
>
> OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
> total 34
> drwx------+ 15 olaf     olaf          15 Oct 25 11:27 olaf
>               user:olaf:rwxpdDaARWcCos:fd-----:allow
>        group:2147483648:rwxpdDaARWcCos:fd-----:allow
>               everyone@:rwxpdDaARWcCos:fd-----:deny
>
> OmniOS-Xeon:~ olaf$ tail /var/adm/messages
> Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: temporar share not found
> Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
> Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: olaf share not found
> Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>
> As you can see, the last letter of the share name in /var/adm/messages gets
> cut for the share "temporary", but not for my own share "olaf". However, my
> own share is neither visible nor accessible, while the other ones are.
>
> Has anything changed about permissions with SMB2?
>
> Thanks
> Olaf
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From gordon.w.ross at gmail.com  Fri Apr 22 01:55:45 2016
From: gordon.w.ross at gmail.com (Gordon Ross)
Date: Thu, 21 Apr 2016 21:55:45 -0400
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>
References: <57180298.1080808@marzocchi.net>
	<CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>
Message-ID: <CAD0Ztp0owB1i3Rdh9am4rsTZb5UNLYsKDTjn0=TCTJURMdhfFQ@mail.gmail.com>

On Thu, Apr 21, 2016 at 9:53 PM, Gordon Ross <gordon.w.ross at gmail.com> wrote:
> I'm not sure how anyone ever gets access when your ACL has this ACE:
>         everyone@:rwxpdDaARWcCos:fd-----:deny
>
> Every long has the group ...

Hah!   Spell checkers - Grrrrr!   That should have read:

Every logon  has the group...

From henson at acm.org  Fri Apr 22 03:15:56 2016
From: henson at acm.org (Paul B. Henson)
Date: Thu, 21 Apr 2016 20:15:56 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
Message-ID: <20160422031556.GP16306@bender.unx.cpp.edu>

On Thu, Apr 21, 2016 at 06:39:08PM -0700, Michael Talbott wrote:

>  -a attributeMap=group:uniqueMember=member \

Pretty sure this should be "group:memberUid=member"...


From mtalbott at lji.org  Fri Apr 22 06:35:56 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Thu, 21 Apr 2016 23:35:56 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <20160422031556.GP16306@bender.unx.cpp.edu>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
Message-ID: <6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>

Ah ha. Right you are. Groups now list all the members, but, it seems all the group members are listed as "John Doe" rather than jdoe which means that when jdoe logs in, he can't access his groups due to the naming disconnect. Any ideas of how to fix that? Somehow map the group members to samAccountName rather than the DN?

getent passwd;
jdoe:x:11439:10000:John Doe:/home/johndoe:/bin/bash

getent group;
testgroup::12345:John Doe

su jdoe;
newgrp testgroup;
  newgrp: Sorry


> On Apr 21, 2016, at 8:15 PM, Paul B. Henson <henson at acm.org> wrote:
> 
> On Thu, Apr 21, 2016 at 06:39:08PM -0700, Michael Talbott wrote:
> 
>> -a attributeMap=group:uniqueMember=member \
> 
> Pretty sure this should be "group:memberUid=member"...
> 


From natxo.asenjo at gmail.com  Fri Apr 22 07:51:33 2016
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Fri, 22 Apr 2016 09:51:33 +0200
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>
References: <57180298.1080808@marzocchi.net>
	<CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>
Message-ID: <CAHBEJzWnH9mgk18NXKDcDL=e1+LkFpPA0Pr=ysTvPmOvo=+qug@mail.gmail.com>

On Fri, Apr 22, 2016 at 3:53 AM, Gordon Ross <gordon.w.ross at gmail.com>
wrote:

> I'm not sure how anyone ever gets access when your ACL has this ACE:
>         everyone@:rwxpdDaARWcCos:fd-----:deny


excellent catch! Deny ace's always get processed first in cifs, how could I
miss that ;-)

-- 
regards,
Natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160422/f5168342/attachment-0001.html>

From lists at marzocchi.net  Fri Apr 22 10:20:49 2016
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Fri, 22 Apr 2016 12:20:49 +0200
Subject: [OmniOS-discuss] SMB issues after r151014 -> r151018
In-Reply-To: <CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>
References: <57180298.1080808@marzocchi.net>
	<CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>
Message-ID: <37C9423A-2B64-49C8-89B8-5D2C81D2EF09@marzocchi.net>

Thanks,
I didn't know that. I thought that it was better not to leave anything undefined, so after a positive match for the intended user, I added a deny for everyone else, thinking that the order of the ACLs also gave priority to the allow statements.

After your explanation, I will just remove the deny ACL, it's not needed in my case.

Olaf



Il 22 aprile 2016 03:53:18 CEST, Gordon Ross <gordon.w.ross at gmail.com> ha scritto:
>I'm not sure how anyone ever gets access when your ACL has this ACE:
>        everyone@:rwxpdDaARWcCos:fd-----:deny
>
>Every logon has the group "everyone" as a member, therefore that ACE
>will match every logon.  The ace also lists every possible permission,
>so nothing should get through, no matter what allow ACEs might also
>exist.


From stephan.budach at JVM.DE  Fri Apr 22 12:00:33 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Fri, 22 Apr 2016 14:00:33 +0200
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <012E847E-F393-4246-B538-AFBFE53A86C5@richardelling.com>
References: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>
	<012E847E-F393-4246-B538-AFBFE53A86C5@richardelling.com>
Message-ID: <571A1261.7010200@jvm.de>

Am 21.04.16 um 18:36 schrieb Richard Elling:
>> On Apr 21, 2016, at 7:47 AM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
>>
>> [About ZFS scrub tunables:]
>>> Interesting read - and it surely works. If you set the tunable before
>>> you start the scrub you can immediately see the thoughput being much
>>> higher than with the standard setting. [...]
>> It's perhaps worth noting here that the scrub rate shown in 'zpool
>> status' is a cumulative one, ie the average scrub rate since the scrub
>> started. As far as I know the only way to get the current scrub rate is
>> run 'zpool status' twice with some time in between and then look at how
>> much progress the scrub's made during that time.
> Scrub rate measured in IOPS or bandwidth is not useful. Neither is a reflection
> of the work being performed in ZFS nor the drives.
>
>> As such, increasing the scrub speed in the middle of what had been a
>> slow scrub up to that point probably won't make a massive or immediate
>> difference in the reported scrub rate. You should see it rising over
>> time, especially if you drastically speeded it up, but it's not any sort
>> of instant jump.
>>
>> (You can always monitor iostat, but that mixes in other pool IO. There's
>> probably something clever that can be done with DTrace.)
> I've got some dtrace that will show progress. However, it is only marginally
> useful when you've got multiple datasets.
>
>> This may already be obvious and well known to people, but I figured
>> I'd mention it just in case.
> People fret about scrubs and resilvers, when they really shouldn't. In ZFS
> accessing data also checks and does recovery, so anything they regularly
> access will be unaffected by the subsequent scan. Over the years, I've tried
> several ways to approach teaching people about failures and scrubs/resilvers,
> but with limited success: some people just like to be afraid... Hollywood makes
> a lot of money on them :-)
>   -- richard
>
>
No? not afraid, but I actually do think, that I can judge whether or not 
I want to speed scrubs up and trade in some performance for that. As 
long as I can do that, I am fine with it. And the same applies for 
resilvers, I guess. If you need to resilver one half of a mirrored 
zpool, most people will want that to run as fast as feasible, don't they?

Thanks,
Stephan


From doug at will.to  Fri Apr 22 16:05:31 2016
From: doug at will.to (Doug Hughes)
Date: Fri, 22 Apr 2016 12:05:31 -0400
Subject: [OmniOS-discuss] Heavy NFS load causing OmniOS server to become
 unresponsive (kernel memory)
In-Reply-To: <CAHBEJzWnH9mgk18NXKDcDL=e1+LkFpPA0Pr=ysTvPmOvo=+qug@mail.gmail.com>
References: <57180298.1080808@marzocchi.net>
	<CAD0Ztp0mhyJnQT0OiPXP3uXaDDeCsFTtOkf1NkW5bCXf2Vd0WA@mail.gmail.com>
	<CAHBEJzWnH9mgk18NXKDcDL=e1+LkFpPA0Pr=ysTvPmOvo=+qug@mail.gmail.com>
Message-ID: <571A4BCB.5030009@will.to>

I didn't see this show up on the list, so I'm trying again.

----

Been seeing this a bit lately on a server with 96GB ram where the zil is 
limited to 48GB. Under heavy NFS load (caused by user running parallel 
find/xargs/rm clean job), it sends the machine into desparation memory 
and causes it to be unreachable for a while. (the server is 24 x SSD, 
and internal I/O load is ok, but the many concurrent NFS requests cause 
it to die, sometimes requiring a reset. usually it recovers in a few 
minutes, but it becomes unservicible from memory shortage.

I have some mdb/kmastat/kmausers/memstat output.

here's the kmastat break down.

Total [hat_memload] 15.8M    5155240     0
Total [kmem_msb] 22.0G  987112603     0
Total [kmem_firewall] 271M  411704261   895
Total [kmem_va] 40.8G   22314937     0
Total [kmem_default] 31.8G 4275706645   619
Total [kmem_io_4P] 44.7M   26714639     0
Total [kmem_io_4G] 108K        908     0
Total [kmem_io_2G] 100K         68     0
Total [bp_map]                                                0 7251     0
Total [umem_np]                                               0 728     0
Total [zfs_file_data] 118M      93380     0
Total [zfs_file_data_buf] 19.4G   22030035     0
Total [segkp] 256K       6787     0
Total [ip_minor_arena_sa] 512      72304     0
Total [ip_minor_arena_la]                                    64 29350     0
Total [spdsock]                                               0 1     0
Total [namefs_inodes]                                        64 27     0
------------------------------ ----- --------- --------- ------ 
---------- -----

the kmausers is almost 1MB.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160422/4cae3ab6/attachment.html>

From richard.elling at richardelling.com  Fri Apr 22 17:13:18 2016
From: richard.elling at richardelling.com (Richard Elling)
Date: Fri, 22 Apr 2016 10:13:18 -0700
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <571A1261.7010200@jvm.de>
References: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>
	<012E847E-F393-4246-B538-AFBFE53A86C5@richardelling.com>
	<571A1261.7010200@jvm.de>
Message-ID: <6B9420C7-580C-45B9-80A5-C8338864C76E@richardelling.com>


> On Apr 22, 2016, at 5:00 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> Am 21.04.16 um 18:36 schrieb Richard Elling:
>>> On Apr 21, 2016, at 7:47 AM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
>>> 
>>> [About ZFS scrub tunables:]
>>>> Interesting read - and it surely works. If you set the tunable before
>>>> you start the scrub you can immediately see the thoughput being much
>>>> higher than with the standard setting. [...]
>>> It's perhaps worth noting here that the scrub rate shown in 'zpool
>>> status' is a cumulative one, ie the average scrub rate since the scrub
>>> started. As far as I know the only way to get the current scrub rate is
>>> run 'zpool status' twice with some time in between and then look at how
>>> much progress the scrub's made during that time.
>> Scrub rate measured in IOPS or bandwidth is not useful. Neither is a reflection
>> of the work being performed in ZFS nor the drives.
>> 
>>> As such, increasing the scrub speed in the middle of what had been a
>>> slow scrub up to that point probably won't make a massive or immediate
>>> difference in the reported scrub rate. You should see it rising over
>>> time, especially if you drastically speeded it up, but it's not any sort
>>> of instant jump.
>>> 
>>> (You can always monitor iostat, but that mixes in other pool IO. There's
>>> probably something clever that can be done with DTrace.)
>> I've got some dtrace that will show progress. However, it is only marginally
>> useful when you've got multiple datasets.
>> 
>>> This may already be obvious and well known to people, but I figured
>>> I'd mention it just in case.
>> People fret about scrubs and resilvers, when they really shouldn't. In ZFS
>> accessing data also checks and does recovery, so anything they regularly
>> access will be unaffected by the subsequent scan. Over the years, I've tried
>> several ways to approach teaching people about failures and scrubs/resilvers,
>> but with limited success: some people just like to be afraid... Hollywood makes
>> a lot of money on them :-)
>>  -- richard
>> 
>> 
> No? not afraid, but I actually do think, that I can judge whether or not I want to speed scrubs up and trade in some performance for that. As long as I can do that, I am fine with it. And the same applies for resilvers, I guess.

For current OmniOS the priority scheduler can be adjusted using mdb to change
the priority for scrubs vs other types of I/O. There is no userland interface. See Adam's
blog for more details.
http://dtrace.org/blogs/ahl/2014/08/31/openzfs-tuning/ <http://dtrace.org/blogs/ahl/2014/08/31/openzfs-tuning/>

If you're running Solaris 11 or pre-2015 OmniOS, then the old write throttle is impossible
to control and you'll chase your tail trying to balance scrubs/resilvers against any other
workload. From a control theory perspective, it is unstable.

> If you need to resilver one half of a mirrored zpool, most people will want that to run as fast as feasible, don't they?

It depends. I've had customers on both sides of the fence and one customer for whom we
cron'ed the priority changes to match their peak. Suffice to say, nobody seems to want 
resilvers to dominate real work.
 -- richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160422/937cdd4c/attachment.html>

From danmcd at omniti.com  Fri Apr 22 17:28:09 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 22 Apr 2016 13:28:09 -0400
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <6B9420C7-580C-45B9-80A5-C8338864C76E@richardelling.com>
References: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>
	<012E847E-F393-4246-B538-AFBFE53A86C5@richardelling.com>
	<571A1261.7010200@jvm.de>
	<6B9420C7-580C-45B9-80A5-C8338864C76E@richardelling.com>
Message-ID: <0A8024AA-3633-4CE5-9208-3C43F90CEE8A@omniti.com>


> On Apr 22, 2016, at 1:13 PM, Richard Elling <richard.elling at richardelling.com> wrote:
> 
> If you're running Solaris 11 or pre-2015 OmniOS, then the old write throttle is impossible
> to control and you'll chase your tail trying to balance scrubs/resilvers against any other
> workload. From a control theory perspective, it is unstable.

pre-2015 can be clarified a bit:  r151014 and later has the modern ZFS write throttle.  Now I know that Stephen is running later versions of OmniOS, so you can be guaranteed it's the modern write-throttle.

Furthermore, anyone running any OmniOS EARLIER than r151014 is not supportable, and any pre-014 release is not supported.

Dan


From richard.elling at richardelling.com  Fri Apr 22 17:31:50 2016
From: richard.elling at richardelling.com (Richard Elling)
Date: Fri, 22 Apr 2016 10:31:50 -0700
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <0A8024AA-3633-4CE5-9208-3C43F90CEE8A@omniti.com>
References: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>
	<012E847E-F393-4246-B538-AFBFE53A86C5@richardelling.com>
	<571A1261.7010200@jvm.de>
	<6B9420C7-580C-45B9-80A5-C8338864C76E@richardelling.com>
	<0A8024AA-3633-4CE5-9208-3C43F90CEE8A@omniti.com>
Message-ID: <AFBD72D2-5838-4352-B70B-0564AEEC0809@richardelling.com>


> On Apr 22, 2016, at 10:28 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Apr 22, 2016, at 1:13 PM, Richard Elling <richard.elling at richardelling.com> wrote:
>> 
>> If you're running Solaris 11 or pre-2015 OmniOS, then the old write throttle is impossible
>> to control and you'll chase your tail trying to balance scrubs/resilvers against any other
>> workload. From a control theory perspective, it is unstable.
> 
> pre-2015 can be clarified a bit:  r151014 and later has the modern ZFS write throttle.  Now I know that Stephen is running later versions of OmniOS, so you can be guaranteed it's the modern write-throttle.
> 
> Furthermore, anyone running any OmniOS EARLIER than r151014 is not supportable, and any pre-014 release is not supported.

Thanks for the clarification Dan!
 -- richard


From stephan.budach at JVM.DE  Fri Apr 22 17:45:51 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Fri, 22 Apr 2016 19:45:51 +0200
Subject: [OmniOS-discuss] Slow scrub on SSD-only pool
In-Reply-To: <0A8024AA-3633-4CE5-9208-3C43F90CEE8A@omniti.com>
References: <20160421144714.9A0707A0421@apps0.cs.toronto.edu>
	<012E847E-F393-4246-B538-AFBFE53A86C5@richardelling.com>
	<571A1261.7010200@jvm.de>
	<6B9420C7-580C-45B9-80A5-C8338864C76E@richardelling.com>
	<0A8024AA-3633-4CE5-9208-3C43F90CEE8A@omniti.com>
Message-ID: <571A634F.10008@jvm.de>

Am 22.04.16 um 19:28 schrieb Dan McDonald:
>> On Apr 22, 2016, at 1:13 PM, Richard Elling <richard.elling at richardelling.com> wrote:
>>
>> If you're running Solaris 11 or pre-2015 OmniOS, then the old write throttle is impossible
>> to control and you'll chase your tail trying to balance scrubs/resilvers against any other
>> workload. From a control theory perspective, it is unstable.
> pre-2015 can be clarified a bit:  r151014 and later has the modern ZFS write throttle.  Now I know that Stephen is running later versions of OmniOS, so you can be guaranteed it's the modern write-throttle.
>
> Furthermore, anyone running any OmniOS EARLIER than r151014 is not supportable, and any pre-014 release is not supported.
>
> Dan
>
?and I am actually fine with the new controls/tunables, so there's 
aboslutely no fuss here. ;) Plus, I actually understood, how both work, 
which is a plus?

Cheers,
Stephan

From henson at acm.org  Fri Apr 22 18:27:46 2016
From: henson at acm.org (Paul B. Henson)
Date: Fri, 22 Apr 2016 11:27:46 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
Message-ID: <20160422182745.GQ16306@bender.unx.cpp.edu>

On Thu, Apr 21, 2016 at 11:35:56PM -0700, Michael Talbott wrote:

> all the group members are listed as "John Doe" rather than jdoe which
> means that when jdoe logs in, he can't access his groups due to the
> naming disconnect. Any ideas of how to fix that? Somehow map the group
> members to samAccountName rather than the DN?

How is your AD structured? It sounds like it's using full names for DN's
rather than usernames? If so, that's not going to work.

Our AD uses usernames for DN's; for example, I'm:

dn: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
cn: henson
sn: Henson
givenName: Paul
initials: B.
distinguishedName: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
displayName: Paul B. Henson
sAMAccountName: henson

and if you look at a group I'm in:

dn: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
cn: netadmin
description: Network admins
member: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
distinguishedName: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
sAMAccountName: netadmin

So the RDN for both users and groups is the short name that a unix box
expects to see, and the long name is in the displayName or description.
I'm guessing you're using the full name as the CN and your users look
like:

dn: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu

so your group members look like:

member: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu

If that's the case, I don't think there's any way you can get it to
work. The rfc2307bis group support expects the RDN to be the username,
there's no way to get it to look up some other attribute of the entry
and use it instead.

From mtalbott at lji.org  Fri Apr 22 19:58:18 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Fri, 22 Apr 2016 12:58:18 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <20160422182745.GQ16306@bender.unx.cpp.edu>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
	<20160422182745.GQ16306@bender.unx.cpp.edu>
Message-ID: <60A531D6-089F-4130-A18D-230886523A94@lji.org>

You're exactly right. The DN in ad is the full name and if I create a user where the DN and shortname match, then everything works great. Unfortunately, I'm not sure if updating all the DNs to match the short name will break other dependancies of it deployed in existing software elsewhere. One day when I'm feeling brave and have a little downtime scheduled, I'll batch update all the entries and see if anything breaks. But, I suppose I'm stuck with winbind for the time being. But thank you for all the help.


 
> On Apr 22, 2016, at 11:27 AM, Paul B. Henson <henson at acm.org> wrote:
> 
> On Thu, Apr 21, 2016 at 11:35:56PM -0700, Michael Talbott wrote:
> 
>> all the group members are listed as "John Doe" rather than jdoe which
>> means that when jdoe logs in, he can't access his groups due to the
>> naming disconnect. Any ideas of how to fix that? Somehow map the group
>> members to samAccountName rather than the DN?
> 
> How is your AD structured? It sounds like it's using full names for DN's
> rather than usernames? If so, that's not going to work.
> 
> Our AD uses usernames for DN's; for example, I'm:
> 
> dn: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> cn: henson
> sn: Henson
> givenName: Paul
> initials: B.
> distinguishedName: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> displayName: Paul B. Henson
> sAMAccountName: henson
> 
> and if you look at a group I'm in:
> 
> dn: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
> cn: netadmin
> description: Network admins
> member: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> distinguishedName: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
> sAMAccountName: netadmin
> 
> So the RDN for both users and groups is the short name that a unix box
> expects to see, and the long name is in the displayName or description.
> I'm guessing you're using the full name as the CN and your users look
> like:
> 
> dn: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
> 
> so your group members look like:
> 
> member: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
> 
> If that's the case, I don't think there's any way you can get it to
> work. The rfc2307bis group support expects the RDN to be the username,
> there's no way to get it to look up some other attribute of the entry
> and use it instead.


From ikaufman at eng.ucsd.edu  Fri Apr 22 20:18:14 2016
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Fri, 22 Apr 2016 13:18:14 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <60A531D6-089F-4130-A18D-230886523A94@lji.org>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
	<20160422182745.GQ16306@bender.unx.cpp.edu>
	<60A531D6-089F-4130-A18D-230886523A94@lji.org>
Message-ID: <CAPJtH1j1wS51R9Y2Th3cpQ1gYaOAxS8iKO2XGbXpFG=z17dx7A@mail.gmail.com>

Does your AD have SFU (or whatever it is called these days) set up?

Ian

On Fri, Apr 22, 2016 at 12:58 PM, Michael Talbott <mtalbott at lji.org> wrote:

> You're exactly right. The DN in ad is the full name and if I create a user
> where the DN and shortname match, then everything works great.
> Unfortunately, I'm not sure if updating all the DNs to match the short name
> will break other dependancies of it deployed in existing software
> elsewhere. One day when I'm feeling brave and have a little downtime
> scheduled, I'll batch update all the entries and see if anything breaks.
> But, I suppose I'm stuck with winbind for the time being. But thank you for
> all the help.
>
>
>
> > On Apr 22, 2016, at 11:27 AM, Paul B. Henson <henson at acm.org> wrote:
> >
> > On Thu, Apr 21, 2016 at 11:35:56PM -0700, Michael Talbott wrote:
> >
> >> all the group members are listed as "John Doe" rather than jdoe which
> >> means that when jdoe logs in, he can't access his groups due to the
> >> naming disconnect. Any ideas of how to fix that? Somehow map the group
> >> members to samAccountName rather than the DN?
> >
> > How is your AD structured? It sounds like it's using full names for DN's
> > rather than usernames? If so, that's not going to work.
> >
> > Our AD uses usernames for DN's; for example, I'm:
> >
> > dn: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> > cn: henson
> > sn: Henson
> > givenName: Paul
> > initials: B.
> > distinguishedName: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> > displayName: Paul B. Henson
> > sAMAccountName: henson
> >
> > and if you look at a group I'm in:
> >
> > dn: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
> > cn: netadmin
> > description: Network admins
> > member: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> > distinguishedName: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
> > sAMAccountName: netadmin
> >
> > So the RDN for both users and groups is the short name that a unix box
> > expects to see, and the long name is in the displayName or description.
> > I'm guessing you're using the full name as the CN and your users look
> > like:
> >
> > dn: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
> >
> > so your group members look like:
> >
> > member: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
> >
> > If that's the case, I don't think there's any way you can get it to
> > work. The rfc2307bis group support expects the RDN to be the username,
> > there's no way to get it to look up some other attribute of the entry
> > and use it instead.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160422/a856deee/attachment.html>

From danmcd at omniti.com  Fri Apr 22 21:06:39 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 22 Apr 2016 17:06:39 -0400
Subject: [OmniOS-discuss] New bloody (r151019) out
Message-ID: <75C8A44B-206D-4C0F-A953-691EBD8EDA67@omniti.com>

This is the first r151019 bloody for OmniOS.  The installation page has the download links for the new bloody release media:

	http://omnios.omniti.com/wiki.php/Installation

Last merged with illumos-gate as of revision cec7ac1.  This time around it's mostly just some fixes in ZFS, including the new per-vdev ZAPs.

Mostly this is to reset the bean counter to r151019 for bloody.

Thanks,
Dan


From mtalbott at lji.org  Fri Apr 22 21:37:15 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Fri, 22 Apr 2016 14:37:15 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <CAPJtH1j1wS51R9Y2Th3cpQ1gYaOAxS8iKO2XGbXpFG=z17dx7A@mail.gmail.com>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
	<20160422182745.GQ16306@bender.unx.cpp.edu>
	<60A531D6-089F-4130-A18D-230886523A94@lji.org>
	<CAPJtH1j1wS51R9Y2Th3cpQ1gYaOAxS8iKO2XGbXpFG=z17dx7A@mail.gmail.com>
Message-ID: <4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org>

It does have the unix extensions on it which is how I was able to get this far (set uids/gids/etc in AD). But I don't have the old windows NIS service running though, so I don't use the SFU30 or whatever attributes since I believe those are all obsoleted and will soon likely disappear.

________________________
Michael Talbott
Systems Administrator
La Jolla Institute

> On Apr 22, 2016, at 1:18 PM, Ian Kaufman <ikaufman at eng.ucsd.edu> wrote:
> 
> Does your AD have SFU (or whatever it is called these days) set up? 
> 
> Ian
> 
> On Fri, Apr 22, 2016 at 12:58 PM, Michael Talbott <mtalbott at lji.org <mailto:mtalbott at lji.org>> wrote:
> You're exactly right. The DN in ad is the full name and if I create a user where the DN and shortname match, then everything works great. Unfortunately, I'm not sure if updating all the DNs to match the short name will break other dependancies of it deployed in existing software elsewhere. One day when I'm feeling brave and have a little downtime scheduled, I'll batch update all the entries and see if anything breaks. But, I suppose I'm stuck with winbind for the time being. But thank you for all the help.
> 
> 
> 
> > On Apr 22, 2016, at 11:27 AM, Paul B. Henson <henson at acm.org <mailto:henson at acm.org>> wrote:
> >
> > On Thu, Apr 21, 2016 at 11:35:56PM -0700, Michael Talbott wrote:
> >
> >> all the group members are listed as "John Doe" rather than jdoe which
> >> means that when jdoe logs in, he can't access his groups due to the
> >> naming disconnect. Any ideas of how to fix that? Somehow map the group
> >> members to samAccountName rather than the DN?
> >
> > How is your AD structured? It sounds like it's using full names for DN's
> > rather than usernames? If so, that's not going to work.
> >
> > Our AD uses usernames for DN's; for example, I'm:
> >
> > dn: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> > cn: henson
> > sn: Henson
> > givenName: Paul
> > initials: B.
> > distinguishedName: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> > displayName: Paul B. Henson
> > sAMAccountName: henson
> >
> > and if you look at a group I'm in:
> >
> > dn: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
> > cn: netadmin
> > description: Network admins
> > member: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
> > distinguishedName: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
> > sAMAccountName: netadmin
> >
> > So the RDN for both users and groups is the short name that a unix box
> > expects to see, and the long name is in the displayName or description.
> > I'm guessing you're using the full name as the CN and your users look
> > like:
> >
> > dn: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
> >
> > so your group members look like:
> >
> > member: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
> >
> > If that's the case, I don't think there's any way you can get it to
> > work. The rfc2307bis group support expects the RDN to be the username,
> > there's no way to get it to look up some other attribute of the entry
> > and use it instead.
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss>
> 
> 
> 
> -- 
> Ian Kaufman
> Research Systems Administrator
> UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160422/b4b1b0c9/attachment.html>

From ikaufman at eng.ucsd.edu  Fri Apr 22 21:46:32 2016
From: ikaufman at eng.ucsd.edu (Ian Kaufman)
Date: Fri, 22 Apr 2016 14:46:32 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
	<20160422182745.GQ16306@bender.unx.cpp.edu>
	<60A531D6-089F-4130-A18D-230886523A94@lji.org>
	<CAPJtH1j1wS51R9Y2Th3cpQ1gYaOAxS8iKO2XGbXpFG=z17dx7A@mail.gmail.com>
	<4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org>
Message-ID: <CAPJtH1jc6injeS0iNcSsBkro=Y513oV7WLDymRj_ytETqcShVA@mail.gmail.com>

Can you pull an complete user object via LDAP query? There might be
secondary attributes that include a POSIX compliant short name.

Ian

On Fri, Apr 22, 2016 at 2:37 PM, Michael Talbott <mtalbott at lji.org> wrote:

> It does have the unix extensions on it which is how I was able to get this
> far (set uids/gids/etc in AD). But I don't have the old windows NIS service
> running though, so I don't use the SFU30 or whatever attributes since I
> believe those are all obsoleted and will soon likely disappear.
>
> ________________________
> Michael Talbott
> Systems Administrator
> La Jolla Institute
>
> On Apr 22, 2016, at 1:18 PM, Ian Kaufman <ikaufman at eng.ucsd.edu> wrote:
>
> Does your AD have SFU (or whatever it is called these days) set up?
>
> Ian
>
> On Fri, Apr 22, 2016 at 12:58 PM, Michael Talbott <mtalbott at lji.org>
> wrote:
>
>> You're exactly right. The DN in ad is the full name and if I create a
>> user where the DN and shortname match, then everything works great.
>> Unfortunately, I'm not sure if updating all the DNs to match the short name
>> will break other dependancies of it deployed in existing software
>> elsewhere. One day when I'm feeling brave and have a little downtime
>> scheduled, I'll batch update all the entries and see if anything breaks.
>> But, I suppose I'm stuck with winbind for the time being. But thank you for
>> all the help.
>>
>>
>>
>> > On Apr 22, 2016, at 11:27 AM, Paul B. Henson <henson at acm.org> wrote:
>> >
>> > On Thu, Apr 21, 2016 at 11:35:56PM -0700, Michael Talbott wrote:
>> >
>> >> all the group members are listed as "John Doe" rather than jdoe which
>> >> means that when jdoe logs in, he can't access his groups due to the
>> >> naming disconnect. Any ideas of how to fix that? Somehow map the group
>> >> members to samAccountName rather than the DN?
>> >
>> > How is your AD structured? It sounds like it's using full names for DN's
>> > rather than usernames? If so, that's not going to work.
>> >
>> > Our AD uses usernames for DN's; for example, I'm:
>> >
>> > dn: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
>> > cn: henson
>> > sn: Henson
>> > givenName: Paul
>> > initials: B.
>> > distinguishedName: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
>> > displayName: Paul B. Henson
>> > sAMAccountName: henson
>> >
>> > and if you look at a group I'm in:
>> >
>> > dn: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
>> > cn: netadmin
>> > description: Network admins
>> > member: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
>> > distinguishedName: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
>> > sAMAccountName: netadmin
>> >
>> > So the RDN for both users and groups is the short name that a unix box
>> > expects to see, and the long name is in the displayName or description.
>> > I'm guessing you're using the full name as the CN and your users look
>> > like:
>> >
>> > dn: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
>> >
>> > so your group members look like:
>> >
>> > member: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
>> >
>> > If that's the case, I don't think there's any way you can get it to
>> > work. The rfc2307bis group support expects the RDN to be the username,
>> > there's no way to get it to look up some other attribute of the entry
>> > and use it instead.
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>
>
>
> --
> Ian Kaufman
> Research Systems Administrator
> UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
>
>
>


-- 
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160422/63ca9193/attachment.html>

From mtalbott at lji.org  Fri Apr 22 22:02:20 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Fri, 22 Apr 2016 15:02:20 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <CAPJtH1jc6injeS0iNcSsBkro=Y513oV7WLDymRj_ytETqcShVA@mail.gmail.com>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
	<20160422182745.GQ16306@bender.unx.cpp.edu>
	<60A531D6-089F-4130-A18D-230886523A94@lji.org>
	<CAPJtH1j1wS51R9Y2Th3cpQ1gYaOAxS8iKO2XGbXpFG=z17dx7A@mail.gmail.com>
	<4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org>
	<CAPJtH1jc6injeS0iNcSsBkro=Y513oV7WLDymRj_ytETqcShVA@mail.gmail.com>
Message-ID: <4857C205-6908-406C-BA8C-79A2D73E5ABE@lji.org>

I can. But the problem lies with how the unix group membership expects usernames to be presented. It is grabbing the DN by for the username and it appears it can not be set to any other attribute (or at least I can't find a way to do so).

________________________
Michael Talbott
Systems Administrator
La Jolla Institute

> On Apr 22, 2016, at 2:46 PM, Ian Kaufman <ikaufman at eng.ucsd.edu> wrote:
> 
> Can you pull an complete user object via LDAP query? There might be secondary attributes that include a POSIX compliant short name.
> 
> Ian
> 
> On Fri, Apr 22, 2016 at 2:37 PM, Michael Talbott <mtalbott at lji.org <mailto:mtalbott at lji.org>> wrote:
> It does have the unix extensions on it which is how I was able to get this far (set uids/gids/etc in AD). But I don't have the old windows NIS service running though, so I don't use the SFU30 or whatever attributes since I believe those are all obsoleted and will soon likely disappear.
> 
> ________________________
> Michael Talbott
> Systems Administrator
> La Jolla Institute
> 
>> On Apr 22, 2016, at 1:18 PM, Ian Kaufman <ikaufman at eng.ucsd.edu <mailto:ikaufman at eng.ucsd.edu>> wrote:
>> 
>> Does your AD have SFU (or whatever it is called these days) set up? 
>> 
>> Ian
>> 
>> On Fri, Apr 22, 2016 at 12:58 PM, Michael Talbott <mtalbott at lji.org <mailto:mtalbott at lji.org>> wrote:
>> You're exactly right. The DN in ad is the full name and if I create a user where the DN and shortname match, then everything works great. Unfortunately, I'm not sure if updating all the DNs to match the short name will break other dependancies of it deployed in existing software elsewhere. One day when I'm feeling brave and have a little downtime scheduled, I'll batch update all the entries and see if anything breaks. But, I suppose I'm stuck with winbind for the time being. But thank you for all the help.
>> 
>> 
>> 
>> > On Apr 22, 2016, at 11:27 AM, Paul B. Henson <henson at acm.org <mailto:henson at acm.org>> wrote:
>> >
>> > On Thu, Apr 21, 2016 at 11:35:56PM -0700, Michael Talbott wrote:
>> >
>> >> all the group members are listed as "John Doe" rather than jdoe which
>> >> means that when jdoe logs in, he can't access his groups due to the
>> >> naming disconnect. Any ideas of how to fix that? Somehow map the group
>> >> members to samAccountName rather than the DN?
>> >
>> > How is your AD structured? It sounds like it's using full names for DN's
>> > rather than usernames? If so, that's not going to work.
>> >
>> > Our AD uses usernames for DN's; for example, I'm:
>> >
>> > dn: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
>> > cn: henson
>> > sn: Henson
>> > givenName: Paul
>> > initials: B.
>> > distinguishedName: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
>> > displayName: Paul B. Henson
>> > sAMAccountName: henson
>> >
>> > and if you look at a group I'm in:
>> >
>> > dn: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
>> > cn: netadmin
>> > description: Network admins
>> > member: CN=henson,OU=user,DC=ad,DC=cpp,DC=edu
>> > distinguishedName: CN=netadmin,OU=group,DC=ad,DC=cpp,DC=edu
>> > sAMAccountName: netadmin
>> >
>> > So the RDN for both users and groups is the short name that a unix box
>> > expects to see, and the long name is in the displayName or description.
>> > I'm guessing you're using the full name as the CN and your users look
>> > like:
>> >
>> > dn: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
>> >
>> > so your group members look like:
>> >
>> > member: CN=Paul B. Henson,OU=user,DC=ad,DC=cpp,DC=edu
>> >
>> > If that's the case, I don't think there's any way you can get it to
>> > work. The rfc2307bis group support expects the RDN to be the username,
>> > there's no way to get it to look up some other attribute of the entry
>> > and use it instead.
>> 
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com <mailto:OmniOS-discuss at lists.omniti.com>
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss>
>> 
>> 
>> 
>> -- 
>> Ian Kaufman
>> Research Systems Administrator
>> UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu 
> 
> 
> 
> 
> -- 
> Ian Kaufman
> Research Systems Administrator
> UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160422/6e0a69bf/attachment-0001.html>

From henson at acm.org  Fri Apr 22 22:34:53 2016
From: henson at acm.org (Paul B. Henson)
Date: Fri, 22 Apr 2016 15:34:53 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <4857C205-6908-406C-BA8C-79A2D73E5ABE@lji.org>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
	<20160422182745.GQ16306@bender.unx.cpp.edu>
	<60A531D6-089F-4130-A18D-230886523A94@lji.org>
	<CAPJtH1j1wS51R9Y2Th3cpQ1gYaOAxS8iKO2XGbXpFG=z17dx7A@mail.gmail.com>
	<4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org>
	<CAPJtH1jc6injeS0iNcSsBkro=Y513oV7WLDymRj_ytETqcShVA@mail.gmail.com>
	<4857C205-6908-406C-BA8C-79A2D73E5ABE@lji.org>
Message-ID: <20160422223452.GR16306@bender.unx.cpp.edu>

On Fri, Apr 22, 2016 at 03:02:20PM -0700, Michael Talbott wrote:
> I can. But the problem lies with how the unix group membership expects
> usernames to be presented. It is grabbing the DN by for the username
> and it appears it can not be set to any other attribute (or at least I
> can't find a way to do so).

As the guy who added rfc2307bis group support to the illumos ldap naming
services integration code (previously it only supported rfc2307), I can
say fairly authoritatively there's no way to do so :). Sorry.

This is the same behavior as nss_ldap and sssd under linux, I'm not
aware of any rfc2307bis implementation that allows you to specify an
alternate attribute rather than using the RDN as the member name. I
suppose it would be possible, but would certainly increase the
complexity as for each member you'd need to look up their entry to find
that alternate attribute to do the substitution. Hopefully you'll be
able to restructure your AD to use usernames as RDN's...

From mtalbott at lji.org  Fri Apr 22 23:00:57 2016
From: mtalbott at lji.org (Michael Talbott)
Date: Fri, 22 Apr 2016 16:00:57 -0700
Subject: [OmniOS-discuss] LDAP and Active Directory via rfc2307
In-Reply-To: <20160422223452.GR16306@bender.unx.cpp.edu>
References: <072B25E0-BADF-4ABE-819B-9A1EDBF871B0@lji.org>
	<20160422031556.GP16306@bender.unx.cpp.edu>
	<6BF21720-BB5E-4367-B306-82E19F7FD76C@lji.org>
	<20160422182745.GQ16306@bender.unx.cpp.edu>
	<60A531D6-089F-4130-A18D-230886523A94@lji.org>
	<CAPJtH1j1wS51R9Y2Th3cpQ1gYaOAxS8iKO2XGbXpFG=z17dx7A@mail.gmail.com>
	<4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org>
	<CAPJtH1jc6injeS0iNcSsBkro=Y513oV7WLDymRj_ytETqcShVA@mail.gmail.com>
	<4857C205-6908-406C-BA8C-79A2D73E5ABE@lji.org>
	<20160422223452.GR16306@bender.unx.cpp.edu>
Message-ID: <C2BBB8B4-9CE3-4322-8395-AE7958912000@lji.org>

I wonder how winbind accomplishes this, maybe it does the lookups and cross references you mentioned.. which is probably why it's so slow by comparison to ldap ;)

Thanks for all the help Paul. It's just too bad that Windows uses the full name to create the user dn by default which is really the cause of the problem.. Now I just need to find out who it was that wrote that chunk of code in AD ;)


> On Apr 22, 2016, at 3:34 PM, Paul B. Henson <henson at acm.org> wrote:
> 
> On Fri, Apr 22, 2016 at 03:02:20PM -0700, Michael Talbott wrote:
>> I can. But the problem lies with how the unix group membership expects
>> usernames to be presented. It is grabbing the DN by for the username
>> and it appears it can not be set to any other attribute (or at least I
>> can't find a way to do so).
> 
> As the guy who added rfc2307bis group support to the illumos ldap naming
> services integration code (previously it only supported rfc2307), I can
> say fairly authoritatively there's no way to do so :). Sorry.
> 
> This is the same behavior as nss_ldap and sssd under linux, I'm not
> aware of any rfc2307bis implementation that allows you to specify an
> alternate attribute rather than using the RDN as the member name. I
> suppose it would be possible, but would certainly increase the
> complexity as for each member you'd need to look up their entry to find
> that alternate attribute to do the substitution. Hopefully you'll be
> able to restructure your AD to use usernames as RDN's...


From richard at netbsd.org  Sun Apr 24 06:22:48 2016
From: richard at netbsd.org (Richard PALO)
Date: Sun, 24 Apr 2016 08:22:48 +0200
Subject: [OmniOS-discuss] mDNSResponder: [ID 702911 daemon.error]
 CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP
 & NAT-PMP announcements,
 messages:Apr 24 07:24:57 omnis mDNSResponder: [ID 702911 daemon.error]
 CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP
 & NAT-PMP announcements,
 messages.1:Apr 8 18:01:31 omnis mDNSResponder: [ID 702911 daemon.error]
 CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP
 & NAT-PMP announcements
Message-ID: <nfhoma$fa0$1@ger.gmane.org>

Happened to notice these in messages since a short while, anything to be worried about?
> messages:Apr 22 07:58:54 omnis mDNSResponder: [ID 702911 daemon.error] CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements
> messages:Apr 24 07:24:57 omnis mDNSResponder: [ID 702911 daemon.error] CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements
> messages.1:Apr  8 18:01:31 omnis mDNSResponder: [ID 702911 daemon.error] CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements

also, I don't believe mdns is working very well any longer...
with ipfilter disabled, just in case:
these commands 
> richard at omnis:/home/richard$ uname -a
> SunOS omnis 5.11 omnios-master-5409e8f i86pc i386 i86pc
> richard at omnis:/home/richard$ pfexec /usr/bin/dns-sd -V
> Currently running daemon (system service) is version 576.30.4
> richard at omnis:/home/richard$ pfexec /usr/bin/dns-sd -g v4 omnis.local
> DATE: ---Sun 24 Apr 2016---
>  8:12:17.837  ...STARTING...
> Timestamp     A/R if Hostname                  Address                                      DNSSECStatus      
>  8:12:17.993  Add  2 omnis.local.              192.168.0.6                                  Unknown           
> ^C
> richard at omnis:/home/richard$ pfexec /usr/bin/dns-sd -G v4 omnis.local
> DATE: ---Sun 24 Apr 2016---
>  8:12:35.543  ...STARTING...
> Timestamp     A/R Flags if Hostname                               Address                                      TTL
>  8:12:35.543  Add     2  2 omnis.local.                           192.168.0.6                                  120
> ^C
> richard at omnis:/home/richard$ svcs  -a |grep network\/dns
> disabled        7:24:49 svc:/network/dns/install:default
> online          7:24:54 svc:/network/dns/client:default
> online          7:24:57 svc:/network/dns/multicast:default

any hints?
-- 
Richard PALO



From contact at jacobvosmaer.nl  Sun Apr 24 10:31:40 2016
From: contact at jacobvosmaer.nl (Jacob Vosmaer)
Date: Sun, 24 Apr 2016 12:31:40 +0200
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <20160421235619.155ea112@sleipner.datanom.net>
References: <20160421235619.155ea112@sleipner.datanom.net>
Message-ID: <CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>

Hi all,

I would put this a little more strongly. In Chrome (OS X), the wiki renders
without CSS, and with only some navigation links (no actual content!).
Loading it in Firefox works fine.

>From the perspective of this Chrome user, the wiki is not 'slightly
broken', but completely broken.

Cheers, Jacob

2016-04-21 23:56 GMT+02:00 Michael Rasmussen <mir at miras.org>:

> Hi Dan,
>
> The following error prevents the wiki to function under webkit based
> browsers:
>
> Mixed Content: The page at 'https://omnios.omniti.com/wiki.php/WikiStart'
> was loaded over a secure connection, but contains a form which targets an
> insecure endpoint 'http://omnios.omniti.com/post-attachment.php'. This
> endpoint should be made available over a secure connection.
> about:blank:1 Mixed Content: The page at '
> https://omnios.omniti.com/wiki.php/WikiStart' was loaded over HTTPS, but
> requested an insecure resource 'http://omnios.omniti.com//mtrack.css'.
> This request has been blocked; the content must be served over HTTPS.
>
> --
> Hilsen/Regards
> Michael Rasmussen
>
> Get my public GnuPG keys:
> michael <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> The sheep that fly over your head are soon to land.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160424/080cf7fd/attachment.html>

From richard at netbsd.org  Sun Apr 24 16:36:02 2016
From: richard at netbsd.org (Richard PALO)
Date: Sun, 24 Apr 2016 18:36:02 +0200
Subject: [OmniOS-discuss] mDNSResponder: [ID 702911 daemon.error]
 CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP
 & NAT-PMP announcements,
 messages:Apr 24 07:24:57 omnis mDNSResponder: [ID 702911 daemon.error]
 CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP
 & NAT-PMP announcements,
 messages.1:Apr 8 18:01:31 omnis mDNSResponder: [ID 702911 daemon.error]
 CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP
 & NAT-PMP announcements
In-Reply-To: <nfhoma$fa0$1@ger.gmane.org>
References: <nfhoma$fa0$1@ger.gmane.org>
Message-ID: <nfisk2$h03$1@ger.gmane.org>

Le 24/04/16 08:22, Richard PALO a ?crit :
> Happened to notice these in messages since a short while, anything to be worried about?
>> messages:Apr 22 07:58:54 omnis mDNSResponder: [ID 702911 daemon.error] CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements
>> messages:Apr 24 07:24:57 omnis mDNSResponder: [ID 702911 daemon.error] CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements
>> messages.1:Apr  8 18:01:31 omnis mDNSResponder: [ID 702911 daemon.error] CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements
> 
> also, I don't believe mdns is working very well any longer...
> with ipfilter disabled, just in case:
> these commands 
>> richard at omnis:/home/richard$ uname -a
>> SunOS omnis 5.11 omnios-master-5409e8f i86pc i386 i86pc
>> richard at omnis:/home/richard$ pfexec /usr/bin/dns-sd -V
>> Currently running daemon (system service) is version 576.30.4
>> richard at omnis:/home/richard$ pfexec /usr/bin/dns-sd -g v4 omnis.local
>> DATE: ---Sun 24 Apr 2016---
>>  8:12:17.837  ...STARTING...
>> Timestamp     A/R if Hostname                  Address                                      DNSSECStatus      
>>  8:12:17.993  Add  2 omnis.local.              192.168.0.6                                  Unknown           
>> ^C
>> richard at omnis:/home/richard$ pfexec /usr/bin/dns-sd -G v4 omnis.local
>> DATE: ---Sun 24 Apr 2016---
>>  8:12:35.543  ...STARTING...
>> Timestamp     A/R Flags if Hostname                               Address                                      TTL
>>  8:12:35.543  Add     2  2 omnis.local.                           192.168.0.6                                  120
>> ^C
>> richard at omnis:/home/richard$ svcs  -a |grep network\/dns
>> disabled        7:24:49 svc:/network/dns/install:default
>> online          7:24:54 svc:/network/dns/client:default
>> online          7:24:57 svc:/network/dns/multicast:default
> 
> any hints?
> 



I notice now, after the above, the following sort of errors in messages:
> Apr 24 07:57:56 omnis mDNSResponder: [ID 702911 daemon.error] mDNS_Register_internal: ERROR!! Tried to register AuthRecord 080E9F54 omnis.local. (Addr) that's already in the list
> Apr 24 07:57:56 omnis mDNSResponder: [ID 702911 daemon.error] mDNS_Register_internal: ERROR!! Tried to register AuthRecord 080EA2D8 6.0.168.192.in-addr.arpa. (PTR) that's already in the list
> Apr 24 07:57:56 omnis mDNSResponder: [ID 702911 daemon.error]  10: ERROR: could not set control socket to non-blocking mode errno 9 (Bad file number)

the last message is probably the most relevant...




-- 
Richard PALO



From stephan.budach at JVM.DE  Mon Apr 25 07:27:10 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Mon, 25 Apr 2016 09:27:10 +0200
Subject: [OmniOS-discuss] R151018: kernel panic when iSCSI target goes south
Message-ID: <571DC6CE.601@jvm.de>

Hi,

I have been struck by kernel panics on my OmniOS boxes lateley, when any 
one of the target hosts, where the system get it's LUNs from, 
experiences a kernel panic itself. When this happens, my RSF-1 node 
immediately panics as well. Looking at the vmdump, it shows this:

root at zfsha02gh79:/var/crash/unknown# mdb -k unix.0 vmcore.0
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix 
scsi_vhci zfs sata sd ip hook neti sockfs arp usba stmf stmf_sbd mm md 
lofs random idm crypto cpc kvm ufs logindmux nsmb ptm smbsrv nfs ipc mpt 
mpt_sas pmcs emlxs ]
 > ::status
debugging crash dump vmcore.0 (64-bit) from zfsha02gh79
operating system: 5.11 omnios-r151018-ae3141d (i86pc)
image uuid: 18d57565-8b91-46ea-9469-fb0518d35e30
panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff00f8b5e590 
addr=10 occurred in module "scsi_vhci" due to a NULL pointer dereference
dump content: kernel pages only
 > ::stack
vhci_scsi_reset_target+0x75(ffffff2c7b200b88, 1, 1)
vhci_recovery_reset+0x7d(ffffff2c7ac9d080, ffffff2c7b200b88, 1, 2)
vhci_pathinfo_offline+0xe5(ffffff21d3288550, ffffff2273530838, 0)
vhci_pathinfo_state_change+0xd5(ffffff21d3288550, ffffff2273530838, 4, 0, 0)
i_mdi_pi_state_change+0x16a(ffffff2273530838, 4, 0)
mdi_pi_offline+0x39(ffffff2273530838, 0)
iscsi_lun_offline+0xb3(ffffff21f1bd4580, ffffff2c084f5d60, 0)
iscsi_sess_offline_luns+0x4d(ffffff27fea82000)
iscsi_sess_state_failed+0x6f(ffffff27fea82000, 3, 2a)
iscsi_sess_state_machine+0x156(ffffff27fea82000, 3, 2a)
iscsi_login_end+0x18f(ffffff286c8d6000, 15, ffffff22724e1158)
iscsi_login_start+0x318(ffffff22724e1158)
taskq_thread+0x2d0(ffffff2270a7cb50)
thread_start+8()
 >

The vmdump is really big, approx 5GB compressed, but I could share that 
if necessary.

Thanks,
Stephan

From eric.sproul at circonus.com  Mon Apr 25 14:09:57 2016
From: eric.sproul at circonus.com (Eric Sproul)
Date: Mon, 25 Apr 2016 10:09:57 -0400
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
Message-ID: <CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>

FYI, the OmniOS wiki is not officially https-enabled.  There is https
on the host where the site resides, but the wiki itself isn't
configured to generate the proper links.  The missing CSS is likely a
side-effect of Chrome refusing to load non-https content.

If you are using a plugin like HTTPS Everywhere, you'll need to set an
exception for http://omnios.omniti.com

Eric

On Sun, Apr 24, 2016 at 6:31 AM, Jacob Vosmaer <contact at jacobvosmaer.nl> wrote:
> Hi all,
>
> I would put this a little more strongly. In Chrome (OS X), the wiki renders
> without CSS, and with only some navigation links (no actual content!).
> Loading it in Firefox works fine.
>
> From the perspective of this Chrome user, the wiki is not 'slightly broken',
> but completely broken.
>
> Cheers, Jacob
>
> 2016-04-21 23:56 GMT+02:00 Michael Rasmussen <mir at miras.org>:
>>
>> Hi Dan,
>>
>> The following error prevents the wiki to function under webkit based
>> browsers:
>>
>> Mixed Content: The page at 'https://omnios.omniti.com/wiki.php/WikiStart'
>> was loaded over a secure connection, but contains a form which targets an
>> insecure endpoint 'http://omnios.omniti.com/post-attachment.php'. This
>> endpoint should be made available over a secure connection.
>> about:blank:1 Mixed Content: The page at
>> 'https://omnios.omniti.com/wiki.php/WikiStart' was loaded over HTTPS, but
>> requested an insecure resource 'http://omnios.omniti.com//mtrack.css'. This
>> request has been blocked; the content must be served over HTTPS.
>>
>> --
>> Hilsen/Regards
>> Michael Rasmussen
>>
>> Get my public GnuPG keys:
>> michael <at> rasmussen <dot> cc
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>> mir <at> datanom <dot> net
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>> mir <at> miras <dot> org
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
>> --------------------------------------------------------------
>> /usr/games/fortune -es says:
>> The sheep that fly over your head are soon to land.
>>
>> _______________________________________________
>> 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 danmcd at omniti.com  Mon Apr 25 14:23:18 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 25 Apr 2016 10:23:18 -0400
Subject: [OmniOS-discuss] R151018: kernel panic when iSCSI target goes
	south
In-Reply-To: <571DC6CE.601@jvm.de>
References: <571DC6CE.601@jvm.de>
Message-ID: <836A4BB6-1E81-4109-950E-7F274C0149DB@omniti.com>

This one is a NULL pointer dereference. If you're still running with kmem_flags = 0xf, the dump will be especially useful.

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Apr 25, 2016, at 3:27 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
> 
> Hi,
> 
> I have been struck by kernel panics on my OmniOS boxes lateley, when any one of the target hosts, where the system get it's LUNs from, experiences a kernel panic itself. When this happens, my RSF-1 node immediately panics as well. Looking at the vmdump, it shows this:
> 
> root at zfsha02gh79:/var/crash/unknown# mdb -k unix.0 vmcore.0
> Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix scsi_vhci zfs sata sd ip hook neti sockfs arp usba stmf stmf_sbd mm md lofs random idm crypto cpc kvm ufs logindmux nsmb ptm smbsrv nfs ipc mpt mpt_sas pmcs emlxs ]
> > ::status
> debugging crash dump vmcore.0 (64-bit) from zfsha02gh79
> operating system: 5.11 omnios-r151018-ae3141d (i86pc)
> image uuid: 18d57565-8b91-46ea-9469-fb0518d35e30
> panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff00f8b5e590 addr=10 occurred in module "scsi_vhci" due to a NULL pointer dereference
> dump content: kernel pages only
> > ::stack
> vhci_scsi_reset_target+0x75(ffffff2c7b200b88, 1, 1)
> vhci_recovery_reset+0x7d(ffffff2c7ac9d080, ffffff2c7b200b88, 1, 2)
> vhci_pathinfo_offline+0xe5(ffffff21d3288550, ffffff2273530838, 0)
> vhci_pathinfo_state_change+0xd5(ffffff21d3288550, ffffff2273530838, 4, 0, 0)
> i_mdi_pi_state_change+0x16a(ffffff2273530838, 4, 0)
> mdi_pi_offline+0x39(ffffff2273530838, 0)
> iscsi_lun_offline+0xb3(ffffff21f1bd4580, ffffff2c084f5d60, 0)
> iscsi_sess_offline_luns+0x4d(ffffff27fea82000)
> iscsi_sess_state_failed+0x6f(ffffff27fea82000, 3, 2a)
> iscsi_sess_state_machine+0x156(ffffff27fea82000, 3, 2a)
> iscsi_login_end+0x18f(ffffff286c8d6000, 15, ffffff22724e1158)
> iscsi_login_start+0x318(ffffff22724e1158)
> taskq_thread+0x2d0(ffffff2270a7cb50)
> thread_start+8()
> >
> 
> The vmdump is really big, approx 5GB compressed, but I could share that if necessary.
> 
> Thanks,
> Stephan
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From stephan.budach at JVM.DE  Mon Apr 25 14:46:24 2016
From: stephan.budach at JVM.DE (Stephan Budach)
Date: Mon, 25 Apr 2016 16:46:24 +0200
Subject: [OmniOS-discuss] R151018: kernel panic when iSCSI target goes
 south
In-Reply-To: <836A4BB6-1E81-4109-950E-7F274C0149DB@omniti.com>
References: <571DC6CE.601@jvm.de>
	<836A4BB6-1E81-4109-950E-7F274C0149DB@omniti.com>
Message-ID: <571E2DC0.7060301@jvm.de>

Hi Dan,

Am 25.04.16 um 16:23 schrieb Dan McDonald:
> This one is a NULL pointer dereference. If you're still running with kmem_flags = 0xf, the dump will be especially useful.
>
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
>> On Apr 25, 2016, at 3:27 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
>>
>> Hi,
>>
>> I have been struck by kernel panics on my OmniOS boxes lateley, when any one of the target hosts, where the system get it's LUNs from, experiences a kernel panic itself. When this happens, my RSF-1 node immediately panics as well. Looking at the vmdump, it shows this:
>>
>> root at zfsha02gh79:/var/crash/unknown# mdb -k unix.0 vmcore.0
>> Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix scsi_vhci zfs sata sd ip hook neti sockfs arp usba stmf stmf_sbd mm md lofs random idm crypto cpc kvm ufs logindmux nsmb ptm smbsrv nfs ipc mpt mpt_sas pmcs emlxs ]
>>> ::status
>> debugging crash dump vmcore.0 (64-bit) from zfsha02gh79
>> operating system: 5.11 omnios-r151018-ae3141d (i86pc)
>> image uuid: 18d57565-8b91-46ea-9469-fb0518d35e30
>> panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff00f8b5e590 addr=10 occurred in module "scsi_vhci" due to a NULL pointer dereference
>> dump content: kernel pages only
>>> ::stack
>> vhci_scsi_reset_target+0x75(ffffff2c7b200b88, 1, 1)
>> vhci_recovery_reset+0x7d(ffffff2c7ac9d080, ffffff2c7b200b88, 1, 2)
>> vhci_pathinfo_offline+0xe5(ffffff21d3288550, ffffff2273530838, 0)
>> vhci_pathinfo_state_change+0xd5(ffffff21d3288550, ffffff2273530838, 4, 0, 0)
>> i_mdi_pi_state_change+0x16a(ffffff2273530838, 4, 0)
>> mdi_pi_offline+0x39(ffffff2273530838, 0)
>> iscsi_lun_offline+0xb3(ffffff21f1bd4580, ffffff2c084f5d60, 0)
>> iscsi_sess_offline_luns+0x4d(ffffff27fea82000)
>> iscsi_sess_state_failed+0x6f(ffffff27fea82000, 3, 2a)
>> iscsi_sess_state_machine+0x156(ffffff27fea82000, 3, 2a)
>> iscsi_login_end+0x18f(ffffff286c8d6000, 15, ffffff22724e1158)
>> iscsi_login_start+0x318(ffffff22724e1158)
>> taskq_thread+0x2d0(ffffff2270a7cb50)
>> thread_start+8()
>> The vmdump is really big, approx 5GB compressed, but I could share that if necessary.
>>
>> Thanks,
>> Stephan

I sure do, if you'd grant me an upload token, I will upload that zip 
file of 4GB. This will expand to a 18GB vmdump?

Cheers,
Stephan

From contact at jacobvosmaer.nl  Mon Apr 25 18:55:14 2016
From: contact at jacobvosmaer.nl (Jacob Vosmaer)
Date: Mon, 25 Apr 2016 20:55:14 +0200
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>
	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
Message-ID: <CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>

Thanks Eric!

It seems like I accidentally took this thread off-list. I think the summary
for everyone else is: HSTS on omniti.com accidentally trickled down to
omnios.omniti.com, affecting visitors who loaded up omnios.omniti.com at
just the right (wrong) time. HSTS headers should have been fixed now.

2016-04-25 20:46 GMT+02:00 Eric Sproul <eric.sproul at circonus.com>:

> Hi Jacob,
> The OmniTI folks did roll out HSTS recently, but (as I'm sure many
> others have) quickly realized that including all subdomains wasn't
> feasible.  They now no longer set that for omniti.com, and have set
> the max-age parameter to 1 second.  I'm not sure how you go about
> clearing the HSTS info from your browser, but if you do that, you
> should be good.
>
> Eric
>
> On Mon, Apr 25, 2016 at 10:35 AM, Eric Sproul <eric.sproul at circonus.com>
> wrote:
> > On Mon, Apr 25, 2016 at 10:26 AM, Jacob Vosmaer <contact at jacobvosmaer.nl>
> wrote:
> >> Thanks Eric.
> >>
> >> I am not using HTTPS Everywhere. According to
> chrome://net-internals/#hsts
> >> omnios.omniti.com my Chrome thinks omnios.omniti.com wants 'Strict
> Transport
> >> Security'.
> >>
> >> static_sts_domain: omniti.com
> >> static_upgrade_mode: STRICT
> >> static_sts_include_subdomains: true
> >> static_sts_observed: 1461128400
> >>
> >> That timestamp is about five days ago. Could it be that OmniTI
> temporarily
> >> deployed HSTS and I got unlucky?
> >
> > Interesting... I'll ask my OmniTI colleagues.
> >
> > Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160425/e61d9fc4/attachment.html>

From eric.sproul at circonus.com  Mon Apr 25 19:16:08 2016
From: eric.sproul at circonus.com (Eric Sproul)
Date: Mon, 25 Apr 2016 15:16:08 -0400
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>
	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
	<CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>
Message-ID: <CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>

On Mon, Apr 25, 2016 at 2:55 PM, Jacob Vosmaer <contact at jacobvosmaer.nl> wrote:
> Thanks Eric!
>
> It seems like I accidentally took this thread off-list. I think the summary
> for everyone else is: HSTS on omniti.com accidentally trickled down to
> omnios.omniti.com, affecting visitors who loaded up omnios.omniti.com at
> just the right (wrong) time. HSTS headers should have been fixed now.

Thanks for the summary Jacob-- can you confirm that you're no longer
seeing the issue?  If so, we can call this one "explained".  :)

Eric

From contact at jacobvosmaer.nl  Mon Apr 25 19:50:06 2016
From: contact at jacobvosmaer.nl (Jacob Vosmaer)
Date: Mon, 25 Apr 2016 21:50:06 +0200
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>
	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
	<CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>
	<CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>
Message-ID: <CAHG0V4fN0U1shVbwijogmvRJvFHNQEgBDxcmjOpPGP=WaHqviA@mail.gmail.com>

Hi Eric,

All may not be well after all: I was having a hard time clearing omniti.com
from my Chrome's local HSTS list... turns out omniti.com is hard-coded in
Chromium(!).

https://chromium.googlesource.com/chromium/src/+/41f8478faaf6c41b2b484e167b3dbb6a95674839/net/http/transport_security_state_static.json#5796

I suspect somebody submitted omniti.com via https://hstspreload.appspot.com/
.


2016-04-25 21:16 GMT+02:00 Eric Sproul <eric.sproul at circonus.com>:

> On Mon, Apr 25, 2016 at 2:55 PM, Jacob Vosmaer <contact at jacobvosmaer.nl>
> wrote:
> > Thanks Eric!
> >
> > It seems like I accidentally took this thread off-list. I think the
> summary
> > for everyone else is: HSTS on omniti.com accidentally trickled down to
> > omnios.omniti.com, affecting visitors who loaded up omnios.omniti.com at
> > just the right (wrong) time. HSTS headers should have been fixed now.
>
> Thanks for the summary Jacob-- can you confirm that you're no longer
> seeing the issue?  If so, we can call this one "explained".  :)
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160425/b5d59e96/attachment-0001.html>

From eric.sproul at circonus.com  Mon Apr 25 19:59:53 2016
From: eric.sproul at circonus.com (Eric Sproul)
Date: Mon, 25 Apr 2016 15:59:53 -0400
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAHG0V4fN0U1shVbwijogmvRJvFHNQEgBDxcmjOpPGP=WaHqviA@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>
	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
	<CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>
	<CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>
	<CAHG0V4fN0U1shVbwijogmvRJvFHNQEgBDxcmjOpPGP=WaHqviA@mail.gmail.com>
Message-ID: <CAO8hXRABJiFF_ZvMPpJn7G=7gK=Ceoo39+dj5p58+CrA8Eoxew@mail.gmail.com>

On Mon, Apr 25, 2016 at 3:50 PM, Jacob Vosmaer <contact at jacobvosmaer.nl> wrote:
> https://chromium.googlesource.com/chromium/src/+/41f8478faaf6c41b2b484e167b3dbb6a95674839/net/http/transport_security_state_static.json#5796
>
> I suspect somebody submitted omniti.com via https://hstspreload.appspot.com/

I've passed that along.  If you go directly to
http://omnios.omniti.com/wiki.php/WikiStart do you get forced to
https?  I don't (Chrome 49, OSX 10.9) but I'm curious.

Eric

From contact at jacobvosmaer.nl  Mon Apr 25 20:06:05 2016
From: contact at jacobvosmaer.nl (Jacob Vosmaer)
Date: Mon, 25 Apr 2016 22:06:05 +0200
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAO8hXRABJiFF_ZvMPpJn7G=7gK=Ceoo39+dj5p58+CrA8Eoxew@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>
	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
	<CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>
	<CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>
	<CAHG0V4fN0U1shVbwijogmvRJvFHNQEgBDxcmjOpPGP=WaHqviA@mail.gmail.com>
	<CAO8hXRABJiFF_ZvMPpJn7G=7gK=Ceoo39+dj5p58+CrA8Eoxew@mail.gmail.com>
Message-ID: <CAHG0V4cCC64ouf9r5JrUa-xkLE-v3dR-3X_=yV3W44xwLgb86A@mail.gmail.com>

When I load that HTTP link with the 'Network' tab of the Chrome dev tools
open I first see a '307 internal redirect response' which takes me to
https://omnios.omniti.com/wiki.php/WikiStart , which then loads without CSS
(i.e. the 'broken' state). If I click where the Green Lock of Trust should
be I read 'Your connection to this site is private, but someone on the
network might be able to change the look of the page.'

Chrome 50.0.2661.86 (64-bit), OS X 10.11.4.

If omniti.com was added to the HSTS preload list very recently it may not
be hard-coded in Chrome 49 yet?

2016-04-25 21:59 GMT+02:00 Eric Sproul <eric.sproul at circonus.com>:

> On Mon, Apr 25, 2016 at 3:50 PM, Jacob Vosmaer <contact at jacobvosmaer.nl>
> wrote:
> >
> https://chromium.googlesource.com/chromium/src/+/41f8478faaf6c41b2b484e167b3dbb6a95674839/net/http/transport_security_state_static.json#5796
> >
> > I suspect somebody submitted omniti.com via
> https://hstspreload.appspot.com/
>
> I've passed that along.  If you go directly to
> http://omnios.omniti.com/wiki.php/WikiStart do you get forced to
> https?  I don't (Chrome 49, OSX 10.9) but I'm curious.
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160425/2e48c8a7/attachment.html>

From eric.sproul at circonus.com  Mon Apr 25 20:13:31 2016
From: eric.sproul at circonus.com (Eric Sproul)
Date: Mon, 25 Apr 2016 16:13:31 -0400
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAHG0V4cCC64ouf9r5JrUa-xkLE-v3dR-3X_=yV3W44xwLgb86A@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>
	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
	<CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>
	<CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>
	<CAHG0V4fN0U1shVbwijogmvRJvFHNQEgBDxcmjOpPGP=WaHqviA@mail.gmail.com>
	<CAO8hXRABJiFF_ZvMPpJn7G=7gK=Ceoo39+dj5p58+CrA8Eoxew@mail.gmail.com>
	<CAHG0V4cCC64ouf9r5JrUa-xkLE-v3dR-3X_=yV3W44xwLgb86A@mail.gmail.com>
Message-ID: <CAO8hXRBhb+RDmvFZdq6gkuTCVdr+m3RBHJvpFnb5P-5-jaY5jg@mail.gmail.com>

On Mon, Apr 25, 2016 at 4:06 PM, Jacob Vosmaer <contact at jacobvosmaer.nl> wrote:
> Chrome 50.0.2661.86 (64-bit), OS X 10.11.4.
>
> If omniti.com was added to the HSTS preload list very recently it may not be
> hard-coded in Chrome 49 yet?

That could well be.  Lucky me, I guess.

From mir at miras.org  Mon Apr 25 20:44:08 2016
From: mir at miras.org (Michael Rasmussen)
Date: Mon, 25 Apr 2016 22:44:08 +0200
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAHG0V4cCC64ouf9r5JrUa-xkLE-v3dR-3X_=yV3W44xwLgb86A@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>
	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
	<CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>
	<CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>
	<CAHG0V4fN0U1shVbwijogmvRJvFHNQEgBDxcmjOpPGP=WaHqviA@mail.gmail.com>
	<CAO8hXRABJiFF_ZvMPpJn7G=7gK=Ceoo39+dj5p58+CrA8Eoxew@mail.gmail.com>
	<CAHG0V4cCC64ouf9r5JrUa-xkLE-v3dR-3X_=yV3W44xwLgb86A@mail.gmail.com>
Message-ID: <20160425224408.508071af@sleipner.datanom.net>

On Mon, 25 Apr 2016 22:06:05 +0200
Jacob Vosmaer <contact at jacobvosmaer.nl> wrote:

> 
> Chrome 50.0.2661.86 (64-bit), OS X 10.11.4.
> 
> If omniti.com was added to the HSTS preload list very recently it may not
> be hard-coded in Chrome 49 yet?
> 
Same here:
Chrome Version 50.0.2661.86 (64-bit), OS Debian Sid.

Works with Opera 36 which is based on Chrome/49.0.2623.110 

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Humorists always sit at the children's table.
		-- Woody Allen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160425/24ca93ac/attachment.bin>

From johan.kragsterman at capvert.se  Mon Apr 25 20:45:12 2016
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Mon, 25 Apr 2016 22:45:12 +0200
Subject: [OmniOS-discuss] Ang: Re:  Wiki is slightly broken
In-Reply-To: <CAO8hXRABJiFF_ZvMPpJn7G=7gK=Ceoo39+dj5p58+CrA8Eoxew@mail.gmail.com>
References: <CAO8hXRABJiFF_ZvMPpJn7G=7gK=Ceoo39+dj5p58+CrA8Eoxew@mail.gmail.com>,
	<20160421235619.155ea112@sleipner.datanom.net>	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>	<CAHG0V4e3EZm0PNj9kLHD6M_GBHRwM=a9Jqei2mHkZM8esmJsdA@mail.gmail.com>
	<CAO8hXRBUpwZR2jW7TG24Gh3SX=fmYBCr_4VY8kubeSF-gLQ_uQ@mail.gmail.com>	<CAO8hXRC1Hgs0OKccOTVrJXGoHyEYzNn3TH4gFzyFDBe4TSFJcw@mail.gmail.com>
	<CAHG0V4cSjE8PoSPkuA11twfkdsy381yqwC9VawG6VFpnD5PO-Q@mail.gmail.com>	<CAO8hXRC8YxqwkVQ16v=PNe147YRa7m3fQ4WwG81Fq+4penm4xg@mail.gmail.com>
	<CAHG0V4fN0U1shVbwijogmvRJvFHNQEgBDxcmjOpPGP=WaHqviA@mail.gmail.com>
Message-ID: <OFF731427D.34DD93B1-ONC1257FA0.00720092-C1257FA0.00720093@inse.com>


Hi!


-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: Jacob Vosmaer <contact at jacobvosmaer.nl>
Fr?n: Eric Sproul 
S?nt av: "OmniOS-discuss" 
Datum: 2016-04-25 22:01
Kopia: omnios-discuss <omnios-discuss at lists.omniti.com>
?rende: Re: [OmniOS-discuss] Wiki is slightly broken

On Mon, Apr 25, 2016 at 3:50 PM, Jacob Vosmaer <contact at jacobvosmaer.nl> wrote:
> https://chromium.googlesource.com/chromium/src/+/41f8478faaf6c41b2b484e167b3dbb6a95674839/net/http/transport_security_state_static.json#5796
>
> I suspect somebody submitted omniti.com via https://hstspreload.appspot.com/

I've passed that along. ?If you go directly to
http://omnios.omniti.com/wiki.php/WikiStart?do you get forced to
https? ?I don't (Chrome 49, OSX 10.9) but I'm curious.

Eric


I get forced to https as well. Chrome Version 50.0.2661.86 (64-bit) on Linux.

Need to use firefox instead...

/J


_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss




From shaun at rackcentral.com  Wed Apr 27 02:47:20 2016
From: shaun at rackcentral.com (Shaun McGuane)
Date: Wed, 27 Apr 2016 02:47:20 +0000
Subject: [OmniOS-discuss] Supermicro X9DR3-F PCI Bus reported fault.
Message-ID: <E1261027-F532-4967-A895-796AD31C1326@rackcentral.com>

Hi OmniOS list,

I am wondering if anyone has had any experience with the Supermicro boards for OmniOS in particular Model X9DR3-F
I have it setup with 2x Intel E5-2670 processors (so I can use all the pci-e slots) and 256GB DDR3 ECC Ram as a base.

I have then tried to run this with LSI 9207-8i Cards x3 for the complete setup, started off with none to get a base OmniOS
Install on the server to ensure all is working OK before adding cards and drives.

The OmniOS version I am running is r151014 ? I have also tried the latest current build from 2016 and I get the same result

I am getting the following error when performing : fmadm faulty

Fault class: fault.io.pciex.device-interr
Affects: dev:////pci at 78,0/pci8086,3c08 at 3/pci8086,a21f at 0 faulted and taken out of service
FRU: ?CPU2_SLOT6?

This slot being reported is the slot closest to the cpu.

The problem that I have is that I have 2 of these boards are showing the same error and I have tested these boards running
Ubuntu 14.04 and Windows and I do not have any errors or issues using this slot. I am new to using super micro boards for
my ZFS arrays and are used to using HP Servers (DL180 G6, etc)

I don?t necessarily need to use this slot, but I am seeing strange issues with removing and re-inserting drives where drives
Show up when running "iostat ?En? but not when I run format to label them.

I thought the 2 issues maybe connected.

Kind Regards
Shaun McGuane


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160427/1faa8240/attachment-0001.html>

From henson at acm.org  Wed Apr 27 02:53:14 2016
From: henson at acm.org (Paul B. Henson)
Date: Tue, 26 Apr 2016 19:53:14 -0700
Subject: [OmniOS-discuss] Dfs root with in-kernel SMB server?
Message-ID: <171c01d1a02f$f1c40ec0$d54c2c40$@acm.org>

I was curious if it is possible to set up a share that acts as a Windows Dfs
root using the illumos in-kernel SMB server, similar to what samba allows
you to do. I found some less than helpful Solaris 11 documentation that
mentioned it in passing, but I don't know if that's a pre or post lawnmower
breakup feature, and it also said something about having to manage it from a
Windows server with Windows tools, which would be a no go from my
perspective 8-/. With the release of SMB2 support in 018, we are looking at
migrating our filesharing services away from samba, but we also use it for
Dfs root purposes.

Thanks.


From mailinglists at qutic.com  Wed Apr 27 08:31:36 2016
From: mailinglists at qutic.com (qutic development)
Date: Wed, 27 Apr 2016 10:31:36 +0200
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
Message-ID: <66EBFB85-D849-482F-A4F2-8AF6349AAC68@qutic.com>


> Am 25.04.2016 um 16:09 schrieb Eric Sproul <eric.sproul at circonus.com>:
> 
> If you are using a plugin like HTTPS Everywhere, you'll need to set an
> exception for http://omnios.omniti.com

Thanks Eric for your clarification.

Would it be possible to get the omnios page and all repos https only?

- Stefan


From chip at innovates.com  Wed Apr 27 11:34:55 2016
From: chip at innovates.com (Schweiss, Chip)
Date: Wed, 27 Apr 2016 06:34:55 -0500
Subject: [OmniOS-discuss] Supermicro X9DR3-F PCI Bus reported fault.
In-Reply-To: <E1261027-F532-4967-A895-796AD31C1326@rackcentral.com>
References: <E1261027-F532-4967-A895-796AD31C1326@rackcentral.com>
Message-ID: <CALeZrrQSnEZ84GmKewsxAQj+0XNmn6QB1bM_jB5Dpcm6tV233w@mail.gmail.com>

I've run many Supermicro servers in the X9 and X10 series.   It sounds like
you have a bad board, or at the minimum a bad slot.   If it's under
warranty get it exchanged.

-Chip

On Tue, Apr 26, 2016 at 9:47 PM, Shaun McGuane <shaun at rackcentral.com>
wrote:

> Hi OmniOS list,
>
> I am wondering if anyone has had any experience with the Supermicro boards
> for OmniOS in particular Model X9DR3-F
> I have it setup with 2x Intel E5-2670 processors (so I can use all the
> pci-e slots) and 256GB DDR3 ECC Ram as a base.
>
> I have then tried to run this with LSI 9207-8i Cards x3 for the complete
> setup, started off with none to get a base OmniOS
> Install on the server to ensure all is working OK before adding cards and
> drives.
>
> The OmniOS version I am running is r151014 ? I have also tried the latest
> current build from 2016 and I get the same result
>
> I am getting the following error when performing : fmadm faulty
>
> Fault class: fault.io.pciex.device-interr
> Affects: dev:////pci at 78,0/pci8086,3c08 at 3/pci8086,a21f at 0 faulted and taken
> out of service
> FRU: ?CPU2_SLOT6?
>
> This slot being reported is the slot closest to the cpu.
>
> The problem that I have is that I have 2 of these boards are showing the
> same error and I have tested these boards running
> Ubuntu 14.04 and Windows and I do not have any errors or issues using this
> slot. I am new to using super micro boards for
> my ZFS arrays and are used to using HP Servers (DL180 G6, etc)
>
> I don?t necessarily need to use this slot, but I am seeing strange issues
> with removing and re-inserting drives where drives
> Show up when running "iostat ?En? but not when I run format to label them.
>
> I thought the 2 issues maybe connected.
>
> Kind Regards
> Shaun McGuane
>
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160427/030a894f/attachment.html>

From shaun at rackcentral.com  Wed Apr 27 11:36:36 2016
From: shaun at rackcentral.com (Shaun McGuane)
Date: Wed, 27 Apr 2016 11:36:36 +0000
Subject: [OmniOS-discuss] Supermicro X9DR3-F PCI Bus reported fault.
In-Reply-To: <CALeZrrQSnEZ84GmKewsxAQj+0XNmn6QB1bM_jB5Dpcm6tV233w@mail.gmail.com>
References: <E1261027-F532-4967-A895-796AD31C1326@rackcentral.com>
	<CALeZrrQSnEZ84GmKewsxAQj+0XNmn6QB1bM_jB5Dpcm6tV233w@mail.gmail.com>
Message-ID: <2C84AC39-2FE9-4410-A3DE-B27F02D9385F@rackcentral.com>

Hi Chip,

After several hours ? I have discovered we have 2 faulty boards from the same supplier.

I got a third board from another vendor as a test and this did not have the issue.

What are the odds!

Thanks for your response.

Kind Regards
Shaun McGuane


From: "Schweiss, Chip" <chip at innovates.com<mailto:chip at innovates.com>>
Date: Wednesday, 27 April 2016 at 9:34 PM
To: Shaun McGuane <shaun at rackcentral.com<mailto:shaun at rackcentral.com>>
Cc: "omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>" <omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>>
Subject: Re: [OmniOS-discuss] Supermicro X9DR3-F PCI Bus reported fault.

I've run many Supermicro servers in the X9 and X10 series.   It sounds like you have a bad board, or at the minimum a bad slot.   If it's under warranty get it exchanged.

-Chip

On Tue, Apr 26, 2016 at 9:47 PM, Shaun McGuane <shaun at rackcentral.com<mailto:shaun at rackcentral.com>> wrote:
Hi OmniOS list,

I am wondering if anyone has had any experience with the Supermicro boards for OmniOS in particular Model X9DR3-F
I have it setup with 2x Intel E5-2670 processors (so I can use all the pci-e slots) and 256GB DDR3 ECC Ram as a base.

I have then tried to run this with LSI 9207-8i Cards x3 for the complete setup, started off with none to get a base OmniOS
Install on the server to ensure all is working OK before adding cards and drives.

The OmniOS version I am running is r151014 ? I have also tried the latest current build from 2016 and I get the same result

I am getting the following error when performing : fmadm faulty

Fault class: fault.io.pciex.device-interr
Affects: dev:////pci at 78,0/pci8086,3c08 at 3/pci8086,a21f at 0 faulted and taken out of service
FRU: ?CPU2_SLOT6?

This slot being reported is the slot closest to the cpu.

The problem that I have is that I have 2 of these boards are showing the same error and I have tested these boards running
Ubuntu 14.04 and Windows and I do not have any errors or issues using this slot. I am new to using super micro boards for
my ZFS arrays and are used to using HP Servers (DL180 G6, etc)

I don?t necessarily need to use this slot, but I am seeing strange issues with removing and re-inserting drives where drives
Show up when running "iostat ?En? but not when I run format to label them.

I thought the 2 issues maybe connected.

Kind Regards
Shaun McGuane



_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160427/35e60826/attachment.html>

From ergi.thanasko at avsquad.com  Wed Apr 27 13:40:58 2016
From: ergi.thanasko at avsquad.com (Ergi Thanasko)
Date: Wed, 27 Apr 2016 13:40:58 +0000
Subject: [OmniOS-discuss] Supermicro X9DR3-F PCI Bus reported fault.
In-Reply-To: <2C84AC39-2FE9-4410-A3DE-B27F02D9385F@rackcentral.com>
References: <E1261027-F532-4967-A895-796AD31C1326@rackcentral.com>
	<CALeZrrQSnEZ84GmKewsxAQj+0XNmn6QB1bM_jB5Dpcm6tV233w@mail.gmail.com>,
	<2C84AC39-2FE9-4410-A3DE-B27F02D9385F@rackcentral.com>
Message-ID: <9D9A1BE7-3FE2-4E8A-A2E3-EFE3EC7E2475@avsquad.com>

You can also try the SUPERMICRO BMC port to see if any errors shows up in the logs

Sent from my iPhone

On Apr 27, 2016, at 4:37 AM, Shaun McGuane <shaun at rackcentral.com<mailto:shaun at rackcentral.com>> wrote:

Hi Chip,

After several hours - I have discovered we have 2 faulty boards from the same supplier.

I got a third board from another vendor as a test and this did not have the issue.

What are the odds!

Thanks for your response.

Kind Regards
Shaun McGuane


From: "Schweiss, Chip" <chip at innovates.com<mailto:chip at innovates.com>>
Date: Wednesday, 27 April 2016 at 9:34 PM
To: Shaun McGuane <shaun at rackcentral.com<mailto:shaun at rackcentral.com>>
Cc: "omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>" <omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>>
Subject: Re: [OmniOS-discuss] Supermicro X9DR3-F PCI Bus reported fault.

I've run many Supermicro servers in the X9 and X10 series.   It sounds like you have a bad board, or at the minimum a bad slot.   If it's under warranty get it exchanged.

-Chip

On Tue, Apr 26, 2016 at 9:47 PM, Shaun McGuane <shaun at rackcentral.com<mailto:shaun at rackcentral.com>> wrote:
Hi OmniOS list,

I am wondering if anyone has had any experience with the Supermicro boards for OmniOS in particular Model X9DR3-F
I have it setup with 2x Intel E5-2670 processors (so I can use all the pci-e slots) and 256GB DDR3 ECC Ram as a base.

I have then tried to run this with LSI 9207-8i Cards x3 for the complete setup, started off with none to get a base OmniOS
Install on the server to ensure all is working OK before adding cards and drives.

The OmniOS version I am running is r151014 - I have also tried the latest current build from 2016 and I get the same result

I am getting the following error when performing : fmadm faulty

Fault class: fault.io.pciex.device-interr
Affects: dev:////pci at 78,0/pci8086,3c08 at 3/pci8086,a21f at 0 faulted and taken out of service
FRU: "CPU2_SLOT6"

This slot being reported is the slot closest to the cpu.

The problem that I have is that I have 2 of these boards are showing the same error and I have tested these boards running
Ubuntu 14.04 and Windows and I do not have any errors or issues using this slot. I am new to using super micro boards for
my ZFS arrays and are used to using HP Servers (DL180 G6, etc)

I don't necessarily need to use this slot, but I am seeing strange issues with removing and re-inserting drives where drives
Show up when running "iostat -En" but not when I run format to label them.

I thought the 2 issues maybe connected.

Kind Regards
Shaun McGuane



_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss


_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160427/290341c4/attachment-0001.html>

From eric.sproul at circonus.com  Wed Apr 27 13:42:00 2016
From: eric.sproul at circonus.com (Eric Sproul)
Date: Wed, 27 Apr 2016 09:42:00 -0400
Subject: [OmniOS-discuss] Wiki is slightly broken
In-Reply-To: <66EBFB85-D849-482F-A4F2-8AF6349AAC68@qutic.com>
References: <20160421235619.155ea112@sleipner.datanom.net>
	<CAHG0V4eMS3Vha9VQJogP47p6_=Eap+nrvhvgfW7okyej-Qz3KA@mail.gmail.com>
	<CAO8hXRDMGUc5nz+7KY_aDnyqo5vjxyU1p8bjzwM7=CjJszDN2A@mail.gmail.com>
	<66EBFB85-D849-482F-A4F2-8AF6349AAC68@qutic.com>
Message-ID: <CAO8hXRAHpb76WyiqyP2FTk6ZMSwBJy_FUvmcb8hHLCHnVdHGYw@mail.gmail.com>

On Wed, Apr 27, 2016 at 4:31 AM, qutic development
<mailinglists at qutic.com> wrote:
>
>> Am 25.04.2016 um 16:09 schrieb Eric Sproul <eric.sproul at circonus.com>:
>>
>> If you are using a plugin like HTTPS Everywhere, you'll need to set an
>> exception for http://omnios.omniti.com
>
> Thanks Eric for your clarification.
>
> Would it be possible to get the omnios page and all repos https only?

Hi Stefan,
I'll defer to OmniTI on that, though I think that might be the way
things are going.

Eric

From bfriesen at simple.dallas.tx.us  Wed Apr 27 13:52:17 2016
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 27 Apr 2016 08:52:17 -0500 (CDT)
Subject: [OmniOS-discuss] GCC 6 + GOMP runtime
Message-ID: <alpine.GSO.2.20.1604270848090.23612@freddy.simplesystems.org>

OmniOS has done well with keeping GCC current in that it offers GCC 
5.1.  Today GCC 6.1 was released.  Does OmniOS plan to continue to 
introduce/track new major GCC releases?

We still need the GOMP runtime libraries included in 
system/library/gcc-5-runtime so that OpenMP enabled binaries can run 
without installing the full developer/gcc51 developer package.  Is 
there a plan for how/when this will happen?

Thanks,

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

From danmcd at omniti.com  Wed Apr 27 17:18:07 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 27 Apr 2016 13:18:07 -0400
Subject: [OmniOS-discuss] Dfs root with in-kernel SMB server?
In-Reply-To: <171c01d1a02f$f1c40ec0$d54c2c40$@acm.org>
References: <171c01d1a02f$f1c40ec0$d54c2c40$@acm.org>
Message-ID: <B25E867C-F999-426C-89F3-17F7ABDF1EE5@omniti.com>

If you don't get bites here, you may wish to ask the illumos list.  The SMB clue is mostly/all Nexenta, and I know they pay attention to illumos.

Sorry I can't immediately help,
Dan


From danmcd at omniti.com  Wed Apr 27 17:28:54 2016
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 27 Apr 2016 13:28:54 -0400
Subject: [OmniOS-discuss] GCC 6 + GOMP runtime
In-Reply-To: <alpine.GSO.2.20.1604270848090.23612@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1604270848090.23612@freddy.simplesystems.org>
Message-ID: <C515AEA7-AF3B-4438-A027-AA173407B141@omniti.com>


> On Apr 27, 2016, at 9:52 AM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:
> 
> OmniOS has done well with keeping GCC current in that it offers GCC 5.1.  Today GCC 6.1 was released.  Does OmniOS plan to continue to introduce/track new major GCC releases?

Yes, but probably not in a timeframe you'll want.  We picked up gcc5 as part of r151016 (first post-LTS stable).  This will likely be frozen until after the next LTS (next LTS is r151022).

> We still need the GOMP runtime libraries included in system/library/gcc-5-runtime so that OpenMP enabled binaries can run without installing the full developer/gcc51 developer package.  Is there a plan for how/when this will happen?

I remember this from earlier... you basically want this:

bloody(build/gcc51)[0]% pkg contents gcc-5-runtime
PATH
usr/lib/amd64
usr/lib/amd64/libgcc_s.so
usr/lib/amd64/libgcc_s.so.1
usr/lib/libgcc_s.so
usr/lib/libgcc_s.so.1
bloody(build/gcc51)[0]% 

To now include usr/lib/{,amd64/}libgomp.so* ?!?

I take it these binaries do dlopen() to find libgomp...

Thanks,
Dan


From bfriesen at simple.dallas.tx.us  Wed Apr 27 17:33:57 2016
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 27 Apr 2016 12:33:57 -0500 (CDT)
Subject: [OmniOS-discuss] GCC 6 + GOMP runtime
In-Reply-To: <C515AEA7-AF3B-4438-A027-AA173407B141@omniti.com>
References: <alpine.GSO.2.20.1604270848090.23612@freddy.simplesystems.org>
	<C515AEA7-AF3B-4438-A027-AA173407B141@omniti.com>
Message-ID: <alpine.GSO.2.20.1604271231090.9720@freddy.simplesystems.org>

On Wed, 27 Apr 2016, Dan McDonald wrote:
>
>> We still need the GOMP runtime libraries included in system/library/gcc-5-runtime so that OpenMP enabled binaries can run without installing the full developer/gcc51 developer package.  Is there a plan for how/when this will happen?
>
> I remember this from earlier... you basically want this:
>
> bloody(build/gcc51)[0]% pkg contents gcc-5-runtime
> PATH
> usr/lib/amd64
> usr/lib/amd64/libgcc_s.so
> usr/lib/amd64/libgcc_s.so.1
> usr/lib/libgcc_s.so
> usr/lib/libgcc_s.so.1
> bloody(build/gcc51)[0]%
>
> To now include usr/lib/{,amd64/}libgomp.so* ?!?

Yes.  It seems to me that this could be rolled out as a normal update.

> I take it these binaries do dlopen() to find libgomp...

The dependent application or library links directly with libgomp as a 
normal shared library.  No special dlopen() is required.

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

From martin.truhlar at archcon.cz  Thu Apr 28 08:09:48 2016
From: martin.truhlar at archcon.cz (=?iso-8859-2?Q?Martin_Truhl=E1=F8?=)
Date: Thu, 28 Apr 2016 10:09:48 +0200
Subject: [OmniOS-discuss] CKSUM error
Message-ID: <F28EF524B0C97740B772BE85DAD0850501B8ED4810D8@SERVER.archcon.local>

Hello,

Should I be worried, that one of my mirrored disks gave me checksum error? (mirror 3) Is any reaction required?

NAME                       STATE     READ WRITE CKSUM      CAP            Product /napp-it   IOstat mess
	dpool                      ONLINE       0     0     0
	  mirror-0                 ONLINE       0     0     0
	    c1t50014EE00400FA16d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	    c1t50014EE2B40F14DBd0  ONLINE       0     0     0      1 TB           WDC WD1003FBYX-0   S:0 H:0 T:0
	  mirror-1                 ONLINE       0     0     0
	    c1t50014EE05950B131d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	    c1t50014EE2B5E5A6B8d0  ONLINE       0     0     0      1 TB           WDC WD1003FBYZ-0   S:0 H:0 T:0
	  mirror-2                 ONLINE       0     0     0
	    c1t50014EE05958C51Bd0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	    c1t50014EE0595617ACd0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	  mirror-3                 ONLINE       0     0     0
	    c1t50014EE0596B5DF9d0  ONLINE       0     0     1      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	    c1t50014EE0AEAE9B65d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	  mirror-5                 ONLINE       0     0     0
	    c1t50014EE0AEABB8E7d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	    c1t50014EE0AEB44327d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
	logs
	  c1t55CD2E4000050AC9d0    ONLINE       0     0     0      240.1 GB       INTEL SSDSC2CW24   S:0 H:0 T:0
	cache
	  c1t55CD2E4000339A59d0    ONLINE       0     0     0      180 GB         INTEL SSDSC2BW18   S:0 H:0 T:0
	spares
	  c2t2d0                   AVAIL         1 TB           WDC WD10EFRX-68F   S:0 H:0 T:0

Thank you in advance for any advice
Martin

From illumos at cucumber.demon.co.uk  Thu Apr 28 11:38:39 2016
From: illumos at cucumber.demon.co.uk (Andrew Gabriel)
Date: Thu, 28 Apr 2016 12:38:39 +0100
Subject: [OmniOS-discuss] CKSUM error
In-Reply-To: <F28EF524B0C97740B772BE85DAD0850501B8ED4810D8@SERVER.archcon.local>
References: <F28EF524B0C97740B772BE85DAD0850501B8ED4810D8@SERVER.archcon.local>
Message-ID: <5721F63F.1010201@cucumber.demon.co.uk>

I had to wait for 5 years before I got my first real checksum error, and 
then two came along at once!
I really wanted some well before that, so I could claim ZFS was 
protecting me from data corruption in my presentations.
;-)

I would check back in logs, FMA, etc to see if anything else was logged.
But for one or two errors, don't worry unless there's some other related 
error report which needs attention.
Drives are spec'ed to return the very occasional uncorrected error (a 
single misdirected write would give you two corrupt blocks). Keep an eye 
on it in case the number starts escalating.

On 28/04/2016 09:09, Martin Truhl?? wrote:
> Hello,
>
> Should I be worried, that one of my mirrored disks gave me checksum error? (mirror 3) Is any reaction required?
>
> NAME                       STATE     READ WRITE CKSUM      CAP            Product /napp-it   IOstat mess
> 	dpool                      ONLINE       0     0     0
> 	  mirror-0                 ONLINE       0     0     0
> 	    c1t50014EE00400FA16d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	    c1t50014EE2B40F14DBd0  ONLINE       0     0     0      1 TB           WDC WD1003FBYX-0   S:0 H:0 T:0
> 	  mirror-1                 ONLINE       0     0     0
> 	    c1t50014EE05950B131d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	    c1t50014EE2B5E5A6B8d0  ONLINE       0     0     0      1 TB           WDC WD1003FBYZ-0   S:0 H:0 T:0
> 	  mirror-2                 ONLINE       0     0     0
> 	    c1t50014EE05958C51Bd0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	    c1t50014EE0595617ACd0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	  mirror-3                 ONLINE       0     0     0
> 	    c1t50014EE0596B5DF9d0  ONLINE       0     0     1      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	    c1t50014EE0AEAE9B65d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	  mirror-5                 ONLINE       0     0     0
> 	    c1t50014EE0AEABB8E7d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	    c1t50014EE0AEB44327d0  ONLINE       0     0     0      1 TB           WDC WD1002F9YZ-0   S:0 H:0 T:0
> 	logs
> 	  c1t55CD2E4000050AC9d0    ONLINE       0     0     0      240.1 GB       INTEL SSDSC2CW24   S:0 H:0 T:0
> 	cache
> 	  c1t55CD2E4000339A59d0    ONLINE       0     0     0      180 GB         INTEL SSDSC2BW18   S:0 H:0 T:0
> 	spares
> 	  c2t2d0                   AVAIL         1 TB           WDC WD10EFRX-68F   S:0 H:0 T:0
>
> Thank you in advance for any advice
> Martin


From martin.truhlar at archcon.cz  Thu Apr 28 11:44:43 2016
From: martin.truhlar at archcon.cz (=?utf-8?B?TWFydGluIFRydWhsw6HFmQ==?=)
Date: Thu, 28 Apr 2016 13:44:43 +0200
Subject: [OmniOS-discuss] CKSUM error
In-Reply-To: <CAD5FWDdJTPwK4UtOmmw2-TQ1pfjwhLUdYEdBwdE2NGD5tt9a8g@mail.gmail.com>
References: <F28EF524B0C97740B772BE85DAD0850501B8ED4810D8@SERVER.archcon.local>
	<CAD5FWDdJTPwK4UtOmmw2-TQ1pfjwhLUdYEdBwdE2NGD5tt9a8g@mail.gmail.com>
Message-ID: <F28EF524B0C97740B772BE85DAD0850501B8ED4810F7@SERVER.archcon.local>

root at archnas:/root# zpool status -x
  pool: dpool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 0 in 15h7m with 0 errors on Sun Apr 24 10:07:38 2016
config:

        NAME                       STATE     READ WRITE CKSUM
        dpool                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            c1t50014EE00400FA16d0  ONLINE       0     0     0
            c1t50014EE2B40F14DBd0  ONLINE       0     0     0
          mirror-1                 ONLINE       0     0     0
            c1t50014EE05950B131d0  ONLINE       0     0     0
            c1t50014EE2B5E5A6B8d0  ONLINE       0     0     0
          mirror-2                 ONLINE       0     0     0
            c1t50014EE05958C51Bd0  ONLINE       0     0     0
            c1t50014EE0595617ACd0  ONLINE       0     0     0
          mirror-3                 ONLINE       0     0     0
            c1t50014EE0596B5DF9d0  ONLINE       0     0     1
            c1t50014EE0AEAE9B65d0  ONLINE       0     0     0
          mirror-5                 ONLINE       0     0     0
            c1t50014EE0AEABB8E7d0  ONLINE       0     0     0
            c1t50014EE0AEB44327d0  ONLINE       0     0     0
        logs
          c1t55CD2E4000050AC9d0    ONLINE       0     0     0
        cache
          c1t55CD2E4000339A59d0    ONLINE       0     0     0
        spares
          c2t2d0                   AVAIL

errors: No known data errors



root at archnas:/root# zpool iostat -v
                              capacity     operations    bandwidth
pool                       alloc   free   read  write   read  write
-------------------------  -----  -----  -----  -----  -----  -----
dpool                      2.48T  2.05T    567    214  4.42M  1.74M
  mirror                    533G   395G    112     20   896K   137K
    c1t50014EE00400FA16d0      -      -     20      7   746K   139K
    c1t50014EE2B40F14DBd0      -      -     16      6   743K   139K
  mirror                    519G   409G    110     34   885K   243K
    c1t50014EE05950B131d0      -      -     19     10   774K   245K
    c1t50014EE2B5E5A6B8d0      -      -     17     10   774K   245K
  mirror                    518G   410G    112     35   896K   251K
    c1t50014EE05958C51Bd0      -      -     19     10   776K   252K
    c1t50014EE0595617ACd0      -      -     20     10   778K   252K
  mirror                    519G   409G    112     38   897K   265K
    c1t50014EE0596B5DF9d0      -      -     19     11   779K   267K
    c1t50014EE0AEAE9B65d0      -      -     19     11   777K   266K
  mirror                    454G   474G    119     39   956K   274K
    c1t50014EE0AEABB8E7d0      -      -     20     10   762K   276K
    c1t50014EE0AEB44327d0      -      -     20     10   763K   276K
logs                           -      -      -      -      -      -
  c1t55CD2E4000050AC9d0    52.7M   222G      0     45      1   614K
cache                          -      -      -      -      -      -
  c1t55CD2E4000339A59d0     147G  21.1G     19      2   159K   287K
-------------------------  -----  -----  -----  -----  -----  -----
epool                      2.37T  8.50T    162    181  1.27M  3.35M
  raidz1                   2.37T  8.50T    162    181  1.27M  3.35M
    c1t50014EE20CA7D920d0      -      -     36     20   714K  1.35M
    c1t50014EE20CF9CAD6d0      -      -     18     17   352K  1.02M
    c1t50014EE20CF9E0D8d0      -      -     36     20   714K  1.35M
    c1t50014EE2B7A5FDF7d0      -      -     18     17   354K  1.03M
-------------------------  -----  -----  -----  -----  -----  -----
rpool                      18.8G   445G      0      0  19.9K  2.28K
  mirror                   18.8G   445G      0      0  19.9K  2.28K
    c2t5d0s0                   -      -      0      0  19.8K  2.89K
    c2t0d0s0                   -      -      0      0    352  21.7K
-------------------------  -----  -----  -----  -----  -----  -----


From: Jozsef Brogyanyi [mailto:brogyi at gmail.com] 
Sent: Thursday, April 28, 2016 1:06 PM
To: Martin Truhl?? <martin.truhlar at archcon.cz>
Subject: Re: [OmniOS-discuss] CKSUM error

Hi Martin
Can you try the scrub command on your system? Can you issue the zpool status -x ? Please send me the next command output zpool iostat -v. I'm curious about something. Thanks.
Disk error or cable error if the scrub not help.

Brogyi

2016-04-28 10:09 GMT+02:00 Martin Truhl?? <martin.truhlar at archcon.cz>:
Hello,

Should I be worried, that one of my mirrored disks gave me checksum error? (mirror 3) Is any reaction required?

NAME? ? ? ? ? ? ? ? ? ? ? ?STATE? ? ?READ WRITE CKSUM? ? ? CAP? ? ? ? ? ? Product /napp-it? ?IOstat mess
? ? ? ? dpool? ? ? ? ? ? ? ? ? ? ? ONLINE? ? ? ?0? ? ?0? ? ?0
? ? ? ? ? mirror-0? ? ? ? ? ? ? ? ?ONLINE? ? ? ?0? ? ?0? ? ?0
? ? ? ? ? ? c1t50014EE00400FA16d0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? ? ? c1t50014EE2B40F14DBd0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1003FBYX-0? ?S:0 H:0 T:0
? ? ? ? ? mirror-1? ? ? ? ? ? ? ? ?ONLINE? ? ? ?0? ? ?0? ? ?0
? ? ? ? ? ? c1t50014EE05950B131d0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? ? ? c1t50014EE2B5E5A6B8d0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1003FBYZ-0? ?S:0 H:0 T:0
? ? ? ? ? mirror-2? ? ? ? ? ? ? ? ?ONLINE? ? ? ?0? ? ?0? ? ?0
? ? ? ? ? ? c1t50014EE05958C51Bd0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? ? ? c1t50014EE0595617ACd0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? ? mirror-3? ? ? ? ? ? ? ? ?ONLINE? ? ? ?0? ? ?0? ? ?0
? ? ? ? ? ? c1t50014EE0596B5DF9d0? ONLINE? ? ? ?0? ? ?0? ? ?1? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? ? ? c1t50014EE0AEAE9B65d0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? ? mirror-5? ? ? ? ? ? ? ? ?ONLINE? ? ? ?0? ? ?0? ? ?0
? ? ? ? ? ? c1t50014EE0AEABB8E7d0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? ? ? c1t50014EE0AEB44327d0? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 1 TB? ? ? ? ? ?WDC WD1002F9YZ-0? ?S:0 H:0 T:0
? ? ? ? logs
? ? ? ? ? c1t55CD2E4000050AC9d0? ? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 240.1 GB? ? ? ?INTEL SSDSC2CW24? ?S:0 H:0 T:0
? ? ? ? cache
? ? ? ? ? c1t55CD2E4000339A59d0? ? ONLINE? ? ? ?0? ? ?0? ? ?0? ? ? 180 GB? ? ? ? ?INTEL SSDSC2BW18? ?S:0 H:0 T:0
? ? ? ? spares
? ? ? ? ? c2t2d0? ? ? ? ? ? ? ? ? ?AVAIL? ? ? ? ?1 TB? ? ? ? ? ?WDC WD10EFRX-68F? ?S:0 H:0 T:0

Thank you in advance for any advice
Martin
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


