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: <10A21637-B670-4350-853E-6DA0549E8B20@omniti.com> <7A8A7BDC-23BB-47F6-A6A6-756D1354BE34@pipar-tbwa.is> <9680905E-E048-4E8E-B24C-239131BEE859@pipar-tbwa.is> <9D7D3346-F46A-40FB-A7B7-8D00746373AD@miras.org> Message-ID: 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 wrote: > > Try to disable usb in bios before installing. > > On March 31, 2016 11:59:20 AM GMT+02:00, "Svavar ?rn Eysteinsson" 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 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 > 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_bios2.JPG > https://dl.dropboxusercontent.com/u/16134/omnios_intel_bios3.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 > > 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/msg03201.html > > and a link a blogpost by jeff sipek > http://blahg.josefsipek.net/?p=488 > > > Best regards, > Svavar O > On 8. mar. 2016, at 15:13, Dan McDonald wrote: > On Mar 8, 2016, at 6:17 AM, Svavar ?rn Eysteinsson 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 > > -- > Christian Kivalo > > 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 > > -- > 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: 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 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 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: On Thu, Mar 31, 2016 at 3:40 PM, Dan McDonald 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: 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: References: <90D036FC-34E8-412A-828A-4ECC6CB1907A@omniti.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 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: 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: > On Apr 6, 2016, at 2:02 AM, Michael Talbott 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: References: <84E78FAA-2B4D-4DEB-AB26-E2AB6EFC4A6D@lji.org> Message-ID: <4E9045F4-67D5-40DF-A774-B237B79A1ADB@omniti.com> > On Apr 6, 2016, at 9:16 AM, Dan McDonald 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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: On Wed, Apr 6, 2016 at 6:23 PM, Josh Barton 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 chassis with the X10DRi-T4+ 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: 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: 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: 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: 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: 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: References: 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 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: 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: <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 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 > 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: 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: <97237967-526F-483A-BE71-9F34383A7FAC@lji.org> <0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org> Message-ID: On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott 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 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 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: 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 ----- Date: Thu, 7 Apr 2016 21:36:55 +0200 From: P?SZTOR Gy?rgy To: "Schweiss, Chip" Hi, "Schweiss, Chip" ?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: References: <97237967-526F-483A-BE71-9F34383A7FAC@lji.org> <0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org> 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 wrote: > > > > On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott > 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 > 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 > 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: 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: References: <97237967-526F-483A-BE71-9F34383A7FAC@lji.org> <0750E77A-FBD3-4D2A-8CA8-91B72351ED6F@lji.org> Message-ID: <303528CE-CF9A-40CE-8702-E817554E49F6@cos.ru> 7 ?????? 2016??. 20:50:13 CEST, "Schweiss, Chip" ?????: >On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott >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 >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 >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: -------------- 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: 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: 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: 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: References: 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 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: References: Message-ID: 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 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 ?????: >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: References: Message-ID: 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 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: <5707BDCF.3020809@joyent.com> <57081193.9050603@multiplay.co.uk> Message-ID: 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 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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 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: 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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 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: 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: On Sun, Apr 10, 2016 at 8:54 PM, Geoff Nordli 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" ?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 wrote: > > Hi, > > "Dan McDonald" ?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: References: <570AF5E2.7040909@gnaa.net> 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 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> <570BF579.5090400@gnaa.net> Message-ID: 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: > On Apr 8, 2016, at 4:15 PM, Dan McDonald 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: References: <570AF5E2.7040909@gnaa.net> <570BF579.5090400@gnaa.net> 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: > On Apr 13, 2016, at 8:09 AM, Andy Fiddaman 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> <97F9575A-C086-4862-B5CA-BA2893E48C08@4amlunch.net> <6D6F42AE-611E-4C7C-88AE-23543CA66DA4@4amlunch.net> <2F515DC7-7803-4814-99D1-06AE3E3A196C@4amlunch.net> <52C14C1A-80F1-4B5D-AE7D-9999AB1B758F@omniti.com> <90EFFEAE-2967-49C7-80F1-AB82E95CB52E@zunaj.si> <11A7C643-506B-441D-B320-79C75B8EAFCE@4amlunch.net> <65DC5816D4BEE043885A89FD54E273FC6CF6BC33@MAIL101.Ellipseinc.com> <867309FA36CA349E.2808DEE6-8CB2-4717-B123-26F8E9BF10C5@mail.outlook.com> <867309FA36CA349E.A61AF59B-1738-47A9-8918-7281B3A691CA@mail.outlook.com> <867309FA36CA349E.0C1F93E3-1045-4C65-9084-870490D3BF34@mail.outlook.com> Message-ID: 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 wrote: > > Oh I didnt catch that detail. > > Okay well nevermind :) > > > Sent from Outlook Mobile > > > > On Tue, Jan 12, 2016 at 8:21 PM -0800, "Brian Hechinger" > wrote: > > In my case the SATA disks aren?t on the 1068E. > > -brian > >> On Jan 12, 2016, at 11:19 PM, John Barfield > wrote: >> >> BTW I left off that it has the same LSI controller chipset >> >> Sent from Outlook Mobile >> _____________________________ >> From: John Barfield > >> Sent: Tuesday, January 12, 2016 10:17 PM >> Subject: Re: [OmniOS-discuss] [discuss] COMSTAR hanging >> To: >, omnios-discuss > >> >> >> 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 >> >> >> >> On Tue, Jan 12, 2016 at 8:08 PM -0800, "Brian Hechinger" > 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 > 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 '$> > >> > >> > >> >> On Jan 8, 2016, at 3:11 PM, Matej Zerovnik > 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 > 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 > 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 ] On Behalf Of Brian Hechinger >> >>>> Sent: Friday, January 08, 2016 12:16 PM >> >>>> To: Matej Zerovnik > >> >>>> Cc: omnios-discuss > >> >>>> 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 > wrote: >> >>>>>> >> >>>>>>>> On Jan 8, 2016, at 11:22 AM, Brian Hechinger > 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 >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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 >> >>>> >> >>>> _______________________________________________ >> >>>> OmniOS-discuss mailing list >> >>>> OmniOS-discuss at lists.omniti.com >> >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >>> >> >> >> > >> >> >> >> http://www.listbox.com >> illumos-discuss | Archives | Modify Your Subscription >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3468 bytes Desc: not available URL: 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: 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: 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: References: Message-ID: On Thu, Apr 14, 2016 at 8:47 PM, Dan McDonald 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: 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: References: 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: <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 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: 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: 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: <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 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: References: Message-ID: 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" 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: 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: References: <5707BDCF.3020809@joyent.com> <57081193.9050603@multiplay.co.uk> Message-ID: On Fri, Apr 15, 2016 at 9:26 PM, Richard Yao 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: 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 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: <5707BDCF.3020809@joyent.com> <57081193.9050603@multiplay.co.uk> <5711A822.1030505@gentoo.org> Message-ID: <21906461-4340-4E36-A3C0-8DB075348654@RichardElling.com> > On Apr 15, 2016, at 7:49 PM, Richard Yao wrote: > > On 04/15/2016 10:24 PM, Josh Coombs wrote: >> On Fri, Apr 15, 2016 at 9:26 PM, Richard Yao 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 > >> 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 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: 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: References: Message-ID: 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 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: References: Message-ID: hi Gordon, On Sun, Apr 17, 2016 at 5:38 PM, Gordon Ross 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: 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 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: 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 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: Message-ID: 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: References: Message-ID: > On Apr 17, 2016, at 10:05 PM, Mark Kushigian 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: 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 wrote: > Am 17.04.16 um 20:42 schrieb Dale Ghent: > > On Apr 17, 2016, at 9:07 AM, Stephan Budach 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: 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: 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 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: 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 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: 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: References: <57137C6A.7050505@jvm.de> <57138A80.6030203@jvm.de> <16613422-27A5-4C0B-A76D-12079DFE991C@omniti.com> <5713ED09.4000206@jvm.de> 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 > wrote: > > Am 17.04.16 um 20:42 schrieb Dale Ghent: > > On Apr 17, 2016, at 9:07 AM, Stephan Budach > > 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: 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 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: References: <57180298.1080808@marzocchi.net> 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 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: References: <57180298.1080808@marzocchi.net> 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 > 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 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> <57191C8F.5080000@marzocchi.net> Message-ID: 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 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 > > 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 > OmniOS-discuss at lists.omniti.com> >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <57180298.1080808@marzocchi.net> <57191C8F.5080000@marzocchi.net> Message-ID: 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 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 > 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 >> > 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 >> OmniOS-discuss at lists.omniti.com> >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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> <57191C8F.5080000@marzocchi.net> Message-ID: Hi Olaf On Thu, Apr 21, 2016 at 8:31 PM, Olaf Marzocchi 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: 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: References: <57180298.1080808@marzocchi.net> <57191C8F.5080000@marzocchi.net> Message-ID: <8AE85116-3B46-4F43-8DDD-126A2CFDBDA8@omniti.com> > On Apr 21, 2016, at 3:21 PM, Steven Ford 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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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 wrote: > > On Thu, 21 Apr 2016 17:17:32 -0400 > Dan McDonald 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 rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras 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 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: 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 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: 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: 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 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: 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 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: References: <57180298.1080808@marzocchi.net> Message-ID: On Thu, Apr 21, 2016 at 9:53 PM, Gordon Ross 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 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: References: <57180298.1080808@marzocchi.net> Message-ID: On Fri, Apr 22, 2016 at 3:53 AM, Gordon Ross 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: 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: References: <57180298.1080808@marzocchi.net> 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 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 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: References: <57180298.1080808@marzocchi.net> 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: 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 wrote: > > Am 21.04.16 um 18:36 schrieb Richard Elling: >>> On Apr 21, 2016, at 7:47 AM, Chris Siebenmann 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/ 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: 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 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: > On Apr 22, 2016, at 10:28 AM, Dan McDonald wrote: > > >> On Apr 22, 2016, at 1:13 PM, Richard Elling 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 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 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: 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 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 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: 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: 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: <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 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 > 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 > 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: 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> <4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org> Message-ID: 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 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 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 > 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 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: 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: 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> <4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org> 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 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 > 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 > 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 > 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 > 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: 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> <4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org> <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> <4FBB82DE-07DA-42F2-B9BB-E1B0CA13D8AE@lji.org> <4857C205-6908-406C-BA8C-79A2D73E5ABE@lji.org> <20160422223452.GR16306@bender.unx.cpp.edu> Message-ID: 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 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: 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: 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 : > 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 rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras 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: 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: References: Message-ID: 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: 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 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 : >> >> 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 rasmussen cc >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E >> mir datanom net >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C >> mir miras 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 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 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: 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 : > 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 > wrote: > > On Mon, Apr 25, 2016 at 10:26 AM, Jacob Vosmaer > 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: 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: On Mon, Apr 25, 2016 at 2:55 PM, Jacob Vosmaer 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: 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 : > On Mon, Apr 25, 2016 at 2:55 PM, Jacob Vosmaer > 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: 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: On Mon, Apr 25, 2016 at 3:50 PM, Jacob Vosmaer 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: 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 : > On Mon, Apr 25, 2016 at 3:50 PM, Jacob Vosmaer > 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: 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: On Mon, Apr 25, 2016 at 4:06 PM, Jacob Vosmaer 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: <20160425224408.508071af@sleipner.datanom.net> On Mon, 25 Apr 2016 22:06:05 +0200 Jacob Vosmaer 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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: References: , <20160421235619.155ea112@sleipner.datanom.net> Message-ID: Hi! -----"OmniOS-discuss" skrev: ----- Till: Jacob Vosmaer Fr?n: Eric Sproul S?nt av: "OmniOS-discuss" Datum: 2016-04-25 22:01 Kopia: omnios-discuss ?rende: Re: [OmniOS-discuss] Wiki is slightly broken On Mon, Apr 25, 2016 at 3:50 PM, Jacob Vosmaer 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: 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: 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: References: <20160421235619.155ea112@sleipner.datanom.net> Message-ID: <66EBFB85-D849-482F-A4F2-8AF6349AAC68@qutic.com> > Am 25.04.2016 um 16:09 schrieb Eric Sproul : > > 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: References: Message-ID: 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 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: 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: References: 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" > Date: Wednesday, 27 April 2016 at 9:34 PM To: Shaun McGuane > Cc: "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 > 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: 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: , <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 > 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" > Date: Wednesday, 27 April 2016 at 9:34 PM To: Shaun McGuane > Cc: "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 > 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 _______________________________________________ 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: 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> <66EBFB85-D849-482F-A4F2-8AF6349AAC68@qutic.com> Message-ID: On Wed, Apr 27, 2016 at 4:31 AM, qutic development wrote: > >> Am 25.04.2016 um 16:09 schrieb Eric Sproul : >> >> 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: 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: 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: References: Message-ID: > On Apr 27, 2016, at 9:52 AM, Bob Friesenhahn 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: References: Message-ID: 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: 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: References: 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: References: Message-ID: 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?? 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?? : 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