From mailinglists at qutic.com Thu Jun 1 10:49:37 2017 From: mailinglists at qutic.com (qutic development) Date: Thu, 1 Jun 2017 12:49:37 +0200 Subject: [OmniOS-discuss] To the OmniOS Community In-Reply-To: References: <20170515053722.7c509bca@landcroft.co.uk> Message-ID: <2873C560-1FCC-4D2C-AB9E-B8D319C0D91E@qutic.com> Hi Theo, that is a word! > I was hoping not to be the first, but I will attempt to lead by example. I'll pledge my time to do required security package publications on 014 and 022. As security issues with packages in core arise, I will update the build system, re-roll the packages and publish them. There are a few security related releases since Dan left: - sudo - openssl (bugfix) - openjdk 7 - bind 9 - ldap As 014 and 022 have signed packages, nobody else than OmniTi can build packages for these, right? > If this will be successful, other people will need to commit to do the work and we will democratize the access to make that work possible. We do have one of the most current userland repos for omnios and are willing to contribute for core. I think we need an omnios build and release structure for the future. What do you think? - Stefan From omnios at citrus-it.net Thu Jun 1 11:07:53 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 1 Jun 2017 11:07:53 +0000 (UTC) Subject: [OmniOS-discuss] To the OmniOS Community In-Reply-To: <2873C560-1FCC-4D2C-AB9E-B8D319C0D91E@qutic.com> References: <20170515053722.7c509bca@landcroft.co.uk> <2873C560-1FCC-4D2C-AB9E-B8D319C0D91E@qutic.com> Message-ID: On Thu, 1 Jun 2017, qutic development wrote: ; Hi Theo, ; ; that is a word! ; ; > I was hoping not to be the first, but I will attempt to lead by example. I'll pledge my time to do required security package publications on 014 and 022. As security issues with packages in core arise, I will update the build system, re-roll the packages and publish them. ; ; There are a few security related releases since Dan left: ; ; - sudo ; - openssl (bugfix) ; - openjdk 7 ; - bind 9 ; - ldap ; ; As 014 and 022 have signed packages, nobody else than OmniTi can build packages for these, right? I have added a pull request for the openssl update to omnios-build, just to see if anyone was picking these up. https://github.com/omniti-labs/omnios-build/pull/105 I've updated my local omnios r22 package mirror and updated our servers too but I've obviously had to disable package signatures. Seems we don't currently have a maintained package repository although people (including me) have volunteered to maintain it. 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 tobi at oetiker.ch Thu Jun 1 11:44:22 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Thu, 1 Jun 2017 13:44:22 +0200 (CEST) Subject: [OmniOS-discuss] To the OmniOS Community In-Reply-To: References: <20170515053722.7c509bca@landcroft.co.uk> <2873C560-1FCC-4D2C-AB9E-B8D319C0D91E@qutic.com> Message-ID: <1207789113.792750.1496317462860.JavaMail.zimbra@oetiker.ch> Hi Andy I have no 'power' but I have created omniosorg on github and invited you qutic theo robert dan ... so depending on what happens in the next few days we could just start updating a copy of omnios there ... so that nothing gets lost until things settel in a new rythem ... cheers tobi ----- On Jun 1, 2017, at 1:07 PM, Andy Fiddaman omnios at citrus-it.net wrote: > On Thu, 1 Jun 2017, qutic development wrote: > > ; Hi Theo, > ; > ; that is a word! > ; > ; > I was hoping not to be the first, but I will attempt to lead by example. > I'll pledge my time to do required security package publications on 014 and > 022. As security issues with packages in core arise, I will update the build > system, re-roll the packages and publish them. > ; > ; There are a few security related releases since Dan left: > ; > ; - sudo > ; - openssl (bugfix) > ; - openjdk 7 > ; - bind 9 > ; - ldap > ; > ; As 014 and 022 have signed packages, nobody else than OmniTi can build > packages for these, right? > > I have added a pull request for the openssl update to omnios-build, just to > see if anyone was picking these up. > > https://github.com/omniti-labs/omnios-build/pull/105 > > I've updated my local omnios r22 package mirror and updated our servers too > but I've obviously had to disable package signatures. > > Seems we don't currently have a maintained package repository although > people (including me) have volunteered to maintain it. > > 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 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From bfriesen at simple.dallas.tx.us Thu Jun 1 13:16:17 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Thu, 1 Jun 2017 08:16:17 -0500 (CDT) Subject: [OmniOS-discuss] To the OmniOS Community In-Reply-To: <2873C560-1FCC-4D2C-AB9E-B8D319C0D91E@qutic.com> References: <20170515053722.7c509bca@landcroft.co.uk> <2873C560-1FCC-4D2C-AB9E-B8D319C0D91E@qutic.com> Message-ID: On Thu, 1 Jun 2017, qutic development wrote: > > As 014 and 022 have signed packages, nobody else than OmniTi can build packages for these, right? Is it not possible for users to add a publisher and then that publisher acts as an overlay, with updated packages from the higher-priority publisher replacing the original packages? Does package signing prevent that or is this not something supported by IPS? Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From apenner.it at gmail.com Thu Jun 1 14:36:55 2017 From: apenner.it at gmail.com (Artem Penner) Date: Thu, 01 Jun 2017 14:36:55 +0000 Subject: [OmniOS-discuss] is zil mirrored within pool Message-ID: Hi, if I hadn't separate log device, is zfs intent log is mirrored inside raidz pool? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafapi at gmail.com Thu Jun 1 14:45:25 2017 From: rafapi at gmail.com (Rafael Pardinas) Date: Thu, 01 Jun 2017 14:45:25 +0000 Subject: [OmniOS-discuss] is zil mirrored within pool In-Reply-To: References: Message-ID: By default, ZFS stores the ZIL in the pool with all the data, so yes. On Thu, 1 Jun 2017 at 15:39 Artem Penner wrote: > Hi, if I hadn't separate log device, is zfs intent log is mirrored inside > raidz pool? > > _______________________________________________ > 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 apenner.it at gmail.com Thu Jun 1 14:55:54 2017 From: apenner.it at gmail.com (Artem Penner) Date: Thu, 01 Jun 2017 14:55:54 +0000 Subject: [OmniOS-discuss] is zil mirrored within pool In-Reply-To: References: Message-ID: are *zfs intent log* data will be striped across all disk in pool without redundancy? If hard drive fail and this cause kernel panic, can I lose my data? ??, 1 ???. 2017 ?. ? 17:45, Rafael Pardinas : > By default, ZFS stores the ZIL in the pool with all the data, so yes. > > On Thu, 1 Jun 2017 at 15:39 Artem Penner wrote: > >> Hi, if I hadn't separate log device, is zfs intent log is mirrored inside >> raidz pool? >> >> _______________________________________________ >> 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 bfriesen at simple.dallas.tx.us Thu Jun 1 15:15:49 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Thu, 1 Jun 2017 10:15:49 -0500 (CDT) Subject: [OmniOS-discuss] is zil mirrored within pool In-Reply-To: References: Message-ID: On Thu, 1 Jun 2017, Artem Penner wrote: > are *zfs intent log* data will be striped across all disk in pool without > redundancy? If hard drive fail and this cause kernel panic, can I lose my > data? You will not lose data if sufficient hard drives are working properly. That is the purpose of zfs and its intent log as well. Normally hard drive failures do not cause kernel panics if sufficient redundancy remains. If the kernel panics for some other reason (e.g. RAM failure or a software bug), it is possible for zfs corruption or data loss to occur since zfs is based on software and zfs stores quite a lot of data in cache. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From henson at acm.org Thu Jun 1 20:01:49 2017 From: henson at acm.org (Paul B. Henson) Date: Thu, 1 Jun 2017 13:01:49 -0700 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> Message-ID: <0b4e01d2db11$e8330370$b8990a50$@acm.org> > From: Geoff Nordli > Sent: Tuesday, May 30, 2017 7:57 PM > > Right, it will not boot after upgrading to the new loader; even if the > 4K disks are not part of the rpool. Yikes 8-/, I'm glad I hadn't got around to updating; my data pool consists of 13 WD Red 3TB drives which are 4K native. I'm surprised this deficiency wasn't noticed during development or testing, aren't 4K native drives fairly common nowadays? I deployed my pool back in 2009. Hmm, fortunately, it looks like you can stick with grub: https://omnios.omniti.com/wiki.php/BSDLoader So until the bug you referenced is fixed upstream and back ported to r151022 (if it ever is, given the current instability of maintenance ), people with 4K drives will need to be sure to *not* migrate to loader. Perhaps somebody with privs to update the wiki would be kind enough to put a large bold warning on the release notes to make sure no one else gets themselves in the position of a non-bootable system? Hmm, wait, I think I have wiki edit privs... Yup, warning added. From danmcd at kebe.com Thu Jun 1 20:45:41 2017 From: danmcd at kebe.com (Dan McDonald) Date: Thu, 1 Jun 2017 16:45:41 -0400 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: <0b4e01d2db11$e8330370$b8990a50$@acm.org> References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> Message-ID: <20170601204541.GA5499@everywhere.local> On Thu, Jun 01, 2017 at 01:01:49PM -0700, Paul B. Henson wrote: > > From: Geoff Nordli > > Sent: Tuesday, May 30, 2017 7:57 PM > > > > Right, it will not boot after upgrading to the new loader; even if the > > 4K disks are not part of the rpool. > > Yikes 8-/, I'm glad I hadn't got around to updating; my data pool consists > of 13 WD Red 3TB drives which are 4K native. I'm surprised this deficiency > wasn't noticed during development or testing, aren't 4K native drives fairly > common nowadays? I deployed my pool back in 2009. WAIT A MINUTE. I thought it wasn't 4k, but "4K" that actually had more bytes on them (some sort of T.10 thing). I'm on the road right now, but I'm pretty sure I have 4k data disks and I'm on 022 + loader Just Fine (TM). Here's the relevant mail: http://lists.omniti.com/pipermail/omnios-discuss/2017-May/008906.html I can confirm/deny this when I get home. Dan From robert at omniti.com Thu Jun 1 21:36:10 2017 From: robert at omniti.com (Robert Treat) Date: Thu, 1 Jun 2017 17:36:10 -0400 Subject: [OmniOS-discuss] Pull request? In-Reply-To: <22823.17350.806040.749253@shelob.bb-c.de> References: <22823.17350.806040.749253@shelob.bb-c.de> Message-ID: On Thu, May 25, 2017 at 4:51 PM, Volker A. Brandt wrote: > Hello all! > > > As I pointed out in March, the package service/network/ntp is broken. > Back then, I was told to submit a pull request. Even though I find it > a bit much to deal with setting up all that infrastrucure at Github > for 14 characters (" overlay=allow") in an IPS manifest, I guess it > is a given that further OmniOS development happens in Github, so there > is no way around it. > I'm not sure this is so much about github as it is about tracking a change. If you can convince someone else to write up the patch for you that's great I guess, but having folks generate their own PR's helps distribute the load a bit... > Assuming I do have a pull request, what would happen then? Would > someone be willing and able to accept it? Speaking generally (as this seems like an open question for all changes at the moment) I think we would want to have others review and vote on the PR wrt to merging it in. Once we have enough votes of confidence, then it can be merged in. Presumably, we'll eventually get some additional folks with commit bits (ie. a core team of developers) who might be able to fast track smaller changes like this. > Would the fix have to go > into Bloody first? Would there be an eventual update to 022 at some > later date? I think this can be somewhat dependent on the nature of the fix, but generally a merge into master, then a cut of bloody, with eventual backport into 022 for a bugfix. Again, these steps can be reasonably compressed depending on the nature of the change. For feature related work, it'd be similar, but things wouldn't be backpatched, just released into newer versions. > Who would build and sign the package and roll it out > into the repository? > I've talked to a few people about this but haven't heard of a particularly good way to do community signed packages. I think the answer will be to have a community-owned machine with rather restricted access of some sort to be used for this purpose. In the meantime, I suspect OmniTI will be signing things, but I'd like to open it up if we can find a reasonable alternative. Robert Treat https://omniti.com From henson at acm.org Thu Jun 1 21:59:52 2017 From: henson at acm.org (Paul B. Henson) Date: Thu, 1 Jun 2017 14:59:52 -0700 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: <20170601204541.GA5499@everywhere.local> References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> <20170601204541.GA5499@everywhere.local> Message-ID: <20170601215951.GQ20300@bender.unx.cpp.edu> On Thu, Jun 01, 2017 at 04:45:41PM -0400, Dan McDonald wrote: > WAIT A MINUTE. I thought it wasn't 4k, but "4K" that actually had more bytes > on them (some sort of T.10 thing). Hmm, in that case I guess my warning should be removed 8-/. But the bug: https://www.illumos.org/issues/8303 Says: "The current biosdisk interface is implemented assuming 512B sector size, with 8+TB disks, there are already systems reporting 4096B sectors and this does break the gptzfsboot and loader as both are using libi386 biosdisk interface." Which seems to pretty clearly implicate bog-standard 4k sector disks... > I can confirm/deny this when I get home. Unless yours are 4k physical 512b logical? Dunno, clarification much appreciated as non-booting systems cause much sadness :(. Thanks... From moo at wuffers.net Sun Jun 4 05:16:56 2017 From: moo at wuffers.net (wuffers) Date: Sun, 4 Jun 2017 01:16:56 -0400 Subject: [OmniOS-discuss] l2arc 16.0E accounting leak In-Reply-To: References: <65DC5816D4BEE043885A89FD54E273FC71DA3B49@MAIL101.Ellipseinc.com> Message-ID: I finally pulled the trigger on r151022, and am still experiencing this after re-adding the cache devices. I had previously removed my l2arc in r151020. I see the bug documented here: https://www.illumos.org/issues/5701 to https://www.illumos.org/issues/7410 https://www.illumos.org/issues/7867 Is anyone else still seeing this in r151022? My cache devices are 400G each: # zpool iostat -v [snip] cache - - - - - - c2t500117310015D579d0 736G 16.0E 46 125 2.07M 7.98M c2t50011731001631FDd0 735G 16.0E 45 125 2.05M 7.97M c12t500117310015D59Ed0 735G 16.0E 46 125 2.07M 7.98M c12t500117310015D54Ed0 736G 16.0E 46 125 2.07M 7.98M arcstat output: read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size l2asize 4.0K 2.7K 1.3K 66 1.3K 134 1.2K 10 223G 4.3T 2.9T On Fri, May 5, 2017 at 11:30 AM, Dan McDonald wrote: > The next stable and LTS, r151022, will arrive this month and it has this > fix. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On May 5, 2017, at 11:06 AM, Richard Jahnel > wrote: > > Does anyone know if we pulled or backported the https://www.illumos.org/ > issues/7867 into r151020 yet? > > > > We are suffering from this bug now. I?m pulling out my l2arc devices until > a fix is in place, which makes me sad. > > _______________________________________________ > 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 sriramnrn at gmail.com Sun Jun 4 09:59:14 2017 From: sriramnrn at gmail.com (Sriram Narayanan) Date: Sun, 4 Jun 2017 17:59:14 +0800 Subject: [OmniOS-discuss] prtconf -v output of a Hetzner PX61-NVMe server Message-ID: Hello all: I've just installed SmartOS on a "PX61-NVMe" at Hetzner. ( https://www.hetzner.de/us/hosting/produkte_rootserver/px61nvme) The prtconf -v output is here: https://gist.github.com/sriramnrn/5d9eb06f69cab3369f9c0ea75cd3ecad I expect others may want to know more about this server model especially since it supports NVMe. If you'd like any other diagnostic output, do let me know. -- Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriramnrn at gmail.com Sun Jun 4 10:00:02 2017 From: sriramnrn at gmail.com (Sriram Narayanan) Date: Sun, 4 Jun 2017 18:00:02 +0800 Subject: [OmniOS-discuss] prtconf -v output of a Hetzner PX61-NVMe server In-Reply-To: References: Message-ID: uname -a yields "SunOS mithila 5.11 joyent_20170511T001921Z i86pc i386 i86pc" On Sun, Jun 4, 2017 at 5:59 PM, Sriram Narayanan wrote: > Hello all: > > I've just installed SmartOS on a "PX61-NVMe" at Hetzner. ( > https://www.hetzner.de/us/hosting/produkte_rootserver/px61nvme) > > The prtconf -v output is here: https://gist.github.com/sriramnrn/ > 5d9eb06f69cab3369f9c0ea75cd3ecad > > I expect others may want to know more about this server model especially > since it supports NVMe. > > If you'd like any other diagnostic output, do let me know. > > -- Ram > -------------- next part -------------- An HTML attachment was scrubbed... URL: From an3s.annema at gmail.com Sun Jun 4 15:15:58 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Sun, 4 Jun 2017 17:15:58 +0200 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: <20170601215951.GQ20300@bender.unx.cpp.edu> References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> <20170601204541.GA5499@everywhere.local> <20170601215951.GQ20300@bender.unx.cpp.edu> Message-ID: <1385383c-6aa4-0bab-6a38-6e2542a0c5f8@gmail.com> Hi guys, Can someone please clarify this matter? Does this boot problem apply only to Advanced Format SAS drives or also to their SATA counterparts? And what does the "native" mean: is that "4kB physical AND 4kB logical block size" as opposed to "4kB physical with 512B logical block size"? Following the discussion below I'm getting more and more confused. It looks to me that the T10-thingy (as can only be used on SAS-drives, right?) changes the block size to something other than 512/4096 bytes which, in turn, is not recognized by the new loader. But is the loader also unable to handle Advanced Format drives that do NOT use that T10-thingy and thus report 512 or 4096 byte block sizes? More specific to my use case, if I may: I am running WD Red SATA drives (4TB and 6TB, WDxxEFRX) which report "512 byte logical / 4096 physical" block size. Would it be a death sentence when I upgrade my r151014's to 022 before this loader bug has been resolved? With such a seemingly high risk of a non-booting system after upgrade, one cannot get too much clarification beforehand, I'd say. Any help is much appreciated. Regards, Andries On 2017-06-01 23:59, Paul B. Henson wrote: > On Thu, Jun 01, 2017 at 04:45:41PM -0400, Dan McDonald wrote: > >> WAIT A MINUTE. I thought it wasn't 4k, but "4K" that actually had more bytes >> on them (some sort of T.10 thing). > Hmm, in that case I guess my warning should be removed 8-/. > > But the bug: > > https://www.illumos.org/issues/8303 > > Says: > > "The current biosdisk interface is implemented assuming 512B sector > size, with 8+TB disks, there are already systems reporting 4096B sectors > and this does break the gptzfsboot and loader as both are using libi386 > biosdisk interface." > > Which seems to pretty clearly implicate bog-standard 4k sector disks... > >> I can confirm/deny this when I get home. > Unless yours are 4k physical 512b logical? Dunno, clarification much > appreciated as non-booting systems cause much sadness :(. > > Thanks... > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From grzempek at gmail.com Sun Jun 4 19:59:51 2017 From: grzempek at gmail.com (Krzysztof Grzempa) Date: Sun, 4 Jun 2017 21:59:51 +0200 Subject: [OmniOS-discuss] Error during Pillow (python image library) installation with pkgsrc Message-ID: Hi, I'm trying to install Pillow library from pkgsrc. Without it i cannot make migrations in my django app deployment. I tried to install it from pip but it throws me an error: pip3.6 install Pillow (...) ---------------------------------------- Command "/opt/local/bin/python3.6 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-luu6n5q1/Pillow/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-fcwc1p7f-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-luu6n5q1/Pillow/ So i found prepared package in pkgsrc. But installing it ends with error: pkgin install py36-Pillow-4.0.0nb2 calculating dependencies... done. nothing to upgrade. 2 packages to be installed (0B to download, 2599K to install): py36-olefile-0.44 py36-Pillow-4.0.0nb2 proceed ? [Y/n] Y downloading packages... installing packages... installing py36-olefile-0.44... installing py36-Pillow-4.0.0nb2... pkg_install warnings: 0, errors: 3 pkg_install error log can be found in /var/db/pkgin/pkg_install-err.log ---Jun 04 21:57:43: installing py36-olefile-0.44... pkg_add: Failed to write lib/python3.6/site-packages/olefile-0.44-py3.6.egg-info for py36-olefile-0.44: Could not unlink pkg_add: attempting to delete directory `/opt/local/lib/python3.6/site-packages/olefile-0.44-py3.6.egg-info' as a file this packing list is incorrect - ignoring delete request pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/CONTRIBUTORS.txt pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/LICENSE.txt pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/README.html pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/README.rst pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/__init__.py pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/__pycache__/__init__.cpython-36.pyc pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/__pycache__/__init__.cpython-36.opt-1.pyc pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/olefile.py pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/__pycache__/olefile.cpython-36.pyc pkg_add: Couldn't remove /opt/local/lib/python3.6/site-packages/olefile/__pycache__/olefile.cpython-36.opt-1.pyc pkg_add: 1 package addition failed ---Jun 04 21:57:43: installing py36-Pillow-4.0.0nb2... pkg_add: Conflicting PLIST with py36-olefile-0.44: lib/python3.6/site-packages/olefile-0.44-py3.6.egg-info pkg_add: Can't install dependency py36-olefile-* pkg_add: 1 package addition failed The problem seems to be with olefile-0.44-py3.6...How to deal with it ? regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Mon Jun 5 03:00:47 2017 From: henson at acm.org (Paul B. Henson) Date: Sun, 4 Jun 2017 20:00:47 -0700 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: <1385383c-6aa4-0bab-6a38-6e2542a0c5f8@gmail.com> References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> <20170601204541.GA5499@everywhere.local> <20170601215951.GQ20300@bender.unx.cpp.edu> <1385383c-6aa4-0bab-6a38-6e2542a0c5f8@gmail.com> Message-ID: <20170605030046.GS20300@bender.unx.cpp.edu> On Sun, Jun 04, 2017 at 05:15:58PM +0200, Andries Annema wrote: > Can someone please clarify this matter? Does this boot problem apply > only to Advanced Format SAS drives or also to their SATA counterparts? I'm guessing here, so take it for what it's not worth ;). But I'm pretty sure it would apply to disks in general. > And what does the "native" mean: is that "4kB physical AND 4kB logical > block size" as opposed to "4kB physical with 512B logical block size"? At this point I'm thinking the loader is only broken for disks that have a *logical* sector size of 4k, as opposed to those that have a physical sector size of 4k but still maintain a logical sector size of 512b. > It looks to me that the T10-thingy (as can only be used on SAS-drives, > right?) changes the block size to something other than 512/4096 bytes > which, in turn, is not recognized by the new loader. I'm not sure if that's because it's an oddball size or just because it's not 512 bytes. Those might still be broken even once they fix it for 4k sectors. > More specific to my use case, if I may: I am running WD Red SATA drives > (4TB and 6TB, WDxxEFRX) which report "512 byte logical / 4096 physical" > block size. Would it be a death sentence when I upgrade my r151014's to > 022 before this loader bug has been resolved? Dan said he upgraded his system with WD red drives with no issues, we're still waiting to hear back from him to confirm that. I was initially surprised that nobody would have caught a loader issue with 4k drives, as they're been around forever in technology terms, my system with WD reds was build almost 9 years ago. On the other hand, drives that both have physical 4k sectors *and* report logical 4k sectors are much less common AFAIK. I'm betting *those* are the ones that the loader doesn't support. Which makes sense, as the bug report indicates that the loader assumes sectors are 512b, and 4k physical/512b logical drives can still be read by the bios in 512b chunks. As opposed to 4k logical sector drives, which can't be. > With such a seemingly high risk of a non-booting system after upgrade, > one cannot get too much clarification beforehand, I'd say. Any help is > much appreciated. You don't *have* to switch to loader as part of the upgrade. You can stick with trusty old grub for now and then migrate to loader later once this is all sorted out. That's probably what I'm going to do for now. The warning I added to the wiki should probably be narrowed to warn just people with 4k physical sector drives, but it doesn't hurt anything to wait to migrate to loader (unless you're a BE maniac) so pending news from a more authoritive source I think I'll let it be better safe than sorry for now. From nagele at wildbit.com Mon Jun 5 15:29:09 2017 From: nagele at wildbit.com (Chris Nagele) Date: Mon, 5 Jun 2017 11:29:09 -0400 Subject: [OmniOS-discuss] Log device options Message-ID: I'm looking at log devices for a new storage build. In the past I've used ZeusRAM, but more recently the HGST SSD800MH.B (100GB). It looks like the HGST is on back order for a while. Has anyone had luck with other low latency devices that might be in stock? Chris From apenner.it at gmail.com Mon Jun 5 15:51:04 2017 From: apenner.it at gmail.com (Artem Penner) Date: Mon, 05 Jun 2017 15:51:04 +0000 Subject: [OmniOS-discuss] Log device options In-Reply-To: References: Message-ID: We use PX04SMB series, avg.latency about 75 microseconds https://toshiba.semicon-storage.com/us/product/storage-products/enterprise-ssd.html ??, 5 ???. 2017 ?., 18:31 Chris Nagele : > I'm looking at log devices for a new storage build. In the past I've > used ZeusRAM, but more recently the HGST SSD800MH.B (100GB). It looks > like the HGST is on back order for a while. Has anyone had luck with > other low latency devices that might be in stock? > > Chris > _______________________________________________ > 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 danmcd at kebe.com Wed Jun 7 00:54:00 2017 From: danmcd at kebe.com (Dan McDonald) Date: Tue, 6 Jun 2017 20:54:00 -0400 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: <20170605030046.GS20300@bender.unx.cpp.edu> References: <9f0a79b2-6e3d-ea32-c97a-2a23843c0d75@gnaa.net> <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> <20170601204541.GA5499@everywhere.local> <20170601215951.GQ20300@bender.unx.cpp.edu> <1385383c-6aa4-0bab-6a38-6e2542a0c5f8@gmail.com> <20170605030046.GS20300@bender.unx.cpp.edu> Message-ID: > On Jun 4, 2017, at 11:00 PM, Paul B. Henson wrote: > >> >> And what does the "native" mean: is that "4kB physical AND 4kB logical >> block size" as opposed to "4kB physical with 512B logical block size"? > > At this point I'm thinking the loader is only broken for disks that have > a *logical* sector size of 4k, as opposed to those that have a physical > sector size of 4k but still maintain a logical sector size of 512b. Sorry for the VERY long latency. Started Joyent last week, attended a funeral yesterday, and more. I apologize if I'm missing something. Here's my home system: (0)# diskinfo TYPE DISK VID PID SIZE RMV SSD UNKNOWN c5t0d0 INTEL SSDSC2BB080G4 74.53 GiB no yes UNKNOWN c5t1d0 INTEL SSDSC2BB080G4 74.53 GiB no yes UNKNOWN c5t2d0 HGST HDN726060ALE610 5589.03 GiB no no UNKNOWN c5t3d0 HGST HDN726060ALE610 5589.03 GiB no no (0)# zpool list -v NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT rpool 51.5G 25.6G 25.9G - 37% 49% 1.00x ONLINE - mirror 51.5G 25.6G 25.9G - 37% 49% c5t0d0s0 - - - - - - c5t1d0s0 - - - - - - tank 5.44T 2.08T 3.36T - 20% 38% 1.00x ONLINE - mirror 5.44T 2.08T 3.36T - 20% 38% c5t2d0 - - - - - - c5t3d0 - - - - - - log - - - - - - mirror 3.97G 768K 3.97G - 52% 0% c5t0d0s4 - - - - - - c5t1d0s4 - - - - - - (0)# uname -a SunOS neuromancer 5.11 omnios-r151022-f9693432c2 i86pc i386 i86pc (0)# The INTEL drives are 512b sectors. The HGST drives (which are NOT boot disks) have 4kb sectors. zdb shows this with ashift. I thought this problem manifested with ANY 4k disk on your system, even if it wasn't the boot drive?! Or am I missing something from the back discussions? And yes, this server boots with Loader (off a old-school Solaris-partitioned INTEL SSDs). Dan From henson at acm.org Wed Jun 7 01:47:08 2017 From: henson at acm.org (Paul B. Henson) Date: Tue, 6 Jun 2017 18:47:08 -0700 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: References: <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> <20170601204541.GA5499@everywhere.local> <20170601215951.GQ20300@bender.unx.cpp.edu> <1385383c-6aa4-0bab-6a38-6e2542a0c5f8@gmail.com> <20170605030046.GS20300@bender.unx.cpp.edu> Message-ID: <20170607014707.GV20300@bender.unx.cpp.edu> On Tue, Jun 06, 2017 at 08:54:00PM -0400, Dan McDonald wrote: > Sorry for the VERY long latency. Started Joyent last week, attended a > funeral yesterday, and more. Congrats on the new job; my condolences on the funeral :(. > The INTEL drives are 512b sectors. The HGST drives (which are NOT > boot disks) have 4kb sectors. zdb shows this with ashift. Yes, they have 4k physical sectors. But do they have 4k or 512b logical sectors? My theory (and I guess somebody should just ask Toomas to sort it out by now :) ) is that loader is only broken for 4k drives that have 4k logical sectors too, not 4k physical sector drives that expose 512b logical sectors. What does # echo ::sd_state | mdb -k | egrep '(^un|_blocksize)' show for your drives? For my WD red drives, it's: un 19: ffffff133905b640 un_sys_blocksize = 0x200 un_tgt_blocksize = 0x200 un_phy_blocksize = 0x1000 un_f_tgt_blocksize_is_valid = 0x1 Which I believe indicates they have a physical sector size of 4k and a logical sector size of 512b. So they should work with loader. But I'm guessing Geoff's disks have both a physical *and* logical sector size of 4k, and *those* are the disks that are currently broken... From danmcd at kebe.com Wed Jun 7 01:48:20 2017 From: danmcd at kebe.com (Dan McDonald) Date: Tue, 6 Jun 2017 21:48:20 -0400 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: <20170607014707.GV20300@bender.unx.cpp.edu> References: <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> <20170601204541.GA5499@everywhere.local> <20170601215951.GQ20300@bender.unx.cpp.edu> <1385383c-6aa4-0bab-6a38-6e2542a0c5f8@gmail.com> <20170605030046.GS20300@bender.unx.cpp.edu> <20170607014707.GV20300@bender.unx.cpp.edu> Message-ID: <4C6D2B0C-766F-457A-9A30-FD26695B8D5B@kebe.com> > On Jun 6, 2017, at 9:47 PM, Paul B. Henson wrote: > > echo ::sd_state | mdb -k | egrep '(^un|_blocksize)' Shit, you're right: (2)# echo ::sd_state | mdb -k | egrep '(^un|_blocksize)' un 0: ffffff0d0c58d9c0 un_sys_blocksize = 0x200 un_tgt_blocksize = 0x200 un_phy_blocksize = 0x200 un_f_tgt_blocksize_is_valid = 0x1 un 1: ffffff0d0c58cd40 un_sys_blocksize = 0x200 un_tgt_blocksize = 0x200 un_phy_blocksize = 0x1000 un_f_tgt_blocksize_is_valid = 0x1 un 2: ffffff0d0c58d380 un_sys_blocksize = 0x200 un_tgt_blocksize = 0x200 un_phy_blocksize = 0x200 un_f_tgt_blocksize_is_valid = 0x1 un 3: ffffff0d0c58c700 un_sys_blocksize = 0x200 un_tgt_blocksize = 0x200 un_phy_blocksize = 0x1000 un_f_tgt_blocksize_is_valid = 0x1 Dan From danmcd at kebe.com Wed Jun 7 21:20:44 2017 From: danmcd at kebe.com (Dan McDonald) Date: Wed, 7 Jun 2017 17:20:44 -0400 Subject: [OmniOS-discuss] ms.omniti.com needs "pkgrepo -s ... rebuild" Message-ID: <84470055-8CE3-4931-9D48-37198B45E3FB@kebe.com> (1)# pkg update -rnv pkg: 1/2 catalogs successfully updated: 1: http protocol error: Unknown error code: 404 reason: Not Found URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170515T21Z.C' 2: http protocol error: Unknown error code: 404 reason: Not Found URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170607T14Z.C' (happened 3 times) 3: http protocol error: Unknown error code: 404 reason: Not Found URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170607T15Z.C' (happened 4 times) 4: http protocol error: Unknown error code: 404 reason: Not Found URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170605T18Z.C' (happened 3 times) 5: http protocol error: Unknown error code: 404 reason: Not Found URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170605T20Z.C' (happened 3 times) 6: http protocol error: Unknown error code: 404 reason: Not Found URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/catalog/1/update.20170606T21Z.C' (happened 3 times) (1)# I think an internal "pkgrepo -s rebuild" will cure this. Dan From henson at acm.org Thu Jun 8 00:19:51 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 7 Jun 2017 17:19:51 -0700 Subject: [OmniOS-discuss] panic: bd_strategy after new loader installed In-Reply-To: <4C6D2B0C-766F-457A-9A30-FD26695B8D5B@kebe.com> References: <9b70cff1-a97a-9269-33aa-79237e593ec6@gnaa.net> <20170530222354.GM20300@bender.unx.cpp.edu> <0b4e01d2db11$e8330370$b8990a50$@acm.org> <20170601204541.GA5499@everywhere.local> <20170601215951.GQ20300@bender.unx.cpp.edu> <1385383c-6aa4-0bab-6a38-6e2542a0c5f8@gmail.com> <20170605030046.GS20300@bender.unx.cpp.edu> <20170607014707.GV20300@bender.unx.cpp.edu> <4C6D2B0C-766F-457A-9A30-FD26695B8D5B@kebe.com> Message-ID: <11f801d2dfec$f26bc270$d7434750$@acm.org> > From: Dan McDonald > Sent: Tuesday, June 6, 2017 6:48 PM > > Shit, you're right: I went ahead and updated the warning I had put on the wiki to clarify that the bug only applies to 4k logical sector disks. I'm not sure how common those are? Hopefully it will keep anybody else from unexpectedly running into a nonbootable system. Fortunately I don't think it's going to be too likely of a scenario... > (2)# echo ::sd_state | mdb -k | egrep '(^un|_blocksize)' > un 0: ffffff0d0c58d9c0 > un_sys_blocksize = 0x200 > un_tgt_blocksize = 0x200 > un_phy_blocksize = 0x200 > un_f_tgt_blocksize_is_valid = 0x1 > un 1: ffffff0d0c58cd40 > un_sys_blocksize = 0x200 > un_tgt_blocksize = 0x200 > un_phy_blocksize = 0x1000 > un_f_tgt_blocksize_is_valid = 0x1 > un 2: ffffff0d0c58d380 > un_sys_blocksize = 0x200 > un_tgt_blocksize = 0x200 > un_phy_blocksize = 0x200 > un_f_tgt_blocksize_is_valid = 0x1 > un 3: ffffff0d0c58c700 > un_sys_blocksize = 0x200 > un_tgt_blocksize = 0x200 > un_phy_blocksize = 0x1000 > un_f_tgt_blocksize_is_valid = 0x1 From aurelien.larcher at gmail.com Fri Jun 9 15:21:59 2017 From: aurelien.larcher at gmail.com (=?UTF-8?Q?Aur=C3=A9lien_Larcher?=) Date: Fri, 9 Jun 2017 17:21:59 +0200 Subject: [OmniOS-discuss] p7zip: CVE 2016-9296 Message-ID: Hi, when I bumped p7zip in oi-userland I noticed that CVE 2016-9296 still affects 16.02: we had this patch against 15.14.1 and I was surprised that it was still valid, then I checked it on the usual websites. Out of curiosity I looked if you have it in omnios-build and it is apparently missing. Kind regards, Aur?lien -- --- Praise the Caffeine embeddings -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwq at xmweixun.com Mon Jun 12 01:20:16 2017 From: dwq at xmweixun.com (=?gb2312?B?tcvOsMio?=) Date: Mon, 12 Jun 2017 09:20:16 +0800 Subject: [OmniOS-discuss] Fwd: Kayak failed to make the release images of 151022 by the local Repos References: <2017061017181217298915@amoyun.com> Message-ID: <4D0F593A-4C6C-4E13-95E3-88D8376C1A7A@xmweixun.com> > > > Hi Guys, > > Can help to advice if anyone encounter such issue? I have follow the build instruction to compile the pkgs to local Repos. But when I using the local repos to build the release images by Kayak, I encounter below errors. > > Any hints are appreciated, Thanks. > > root at sca:/code/kayak# zfs destroy -R rpool/kayak_image > root at sca:/code/kayak# zfs create rpool/kayak_image > root at sca:/code/kayak# set PKGURL=file:///code/omnios/ > root at sca:/code/kayak# export PGKURL > root at sca:/code/kayak# export > declare -x HOME="/root" > declare -x LOGNAME="root" > declare -x MAIL="/var/mail/root" > declare -x OLDPWD="/root" > declare -x PAGER="/usr/bin/less -ins" > declare -x PATH="/usr/sbin:/sbin:/usr/bin" > declare -x PGKURL > declare -x PS1="\\u@\\h:\\w\\\$ " > declare -x PWD="/code/kayak" > declare -x SHELL="/usr/bin/bash" > declare -x SHLVL="1" > declare -x SSH_CLIENT="10.1.1.18 53257 22" > declare -x SSH_CONNECTION="10.1.1.18 53257 10.1.1.119 22" > declare -x SSH_TTY="/dev/pts/4" > declare -x TERM="xterm" > declare -x TZ="Asia/Shanghai" > declare -x USER="root" > root at sca:/code/kayak# PKGURL=file:///code/omnios/ > root at sca:/code/kayak# export PKGURL > root at sca:/code/kayak# export > declare -x HOME="/root" > declare -x LOGNAME="root" > declare -x MAIL="/var/mail/root" > declare -x OLDPWD="/root" > declare -x PAGER="/usr/bin/less -ins" > declare -x PATH="/usr/sbin:/sbin:/usr/bin" > declare -x PGKURL > declare -x PKGURL="file:///code/omnios/ " > declare -x PS1="\\u@\\h:\\w\\\$ " > declare -x PWD="/code/kayak" > declare -x SHELL="/usr/bin/bash" > declare -x SHLVL="1" > declare -x SSH_CLIENT="10.1.1.18 53257 22" > declare -x SSH_CONNECTION="10.1.1.18 53257 10.1.1.119 22" > declare -x SSH_TTY="/dev/pts/4" > declare -x TERM="xterm" > declare -x TZ="Asia/Shanghai" > declare -x USER="root" > root at sca:/code/kayak# gmake install-usb > mkdir -p /tftpboot/boot/grub > mkdir -p /tftpboot/boot/platform/i86pc/kernel/amd64 > mkdir -p /tftpboot/kayak > if test -n "`zfs list -H -t snapshot rpool/kayak_image/root at fixup 2>/dev/null`"; then \ > VERSION=r151022 DEBUG= ./build_image.sh rpool/kayak_image fixup ; \ > else \ > VERSION=r151022 DEBUG= ./build_image.sh rpool/kayak_image begin ; \ > fi > WARNING -- Not using 'native' svccfg, may hang on build. > We recommend a pre-built illumos's svccfg-native. > Set PREBUILT_ILLUMOS in your environment to point > to a built illumos-omnios repository. > Explicit checkpoint requested: 'begin' > === Proceeding to phase begin === > === Proceeding to phase pkg (zfs @pkg) === > Creating image of omnios from file:///code/omnios/ > > Packages to install: 2 > > PHASE ITEMS > Installing new actions 604/604 > Updating package state database Done > Updating package cache 0/0 > Updating image state Done > Creating fast lookup database Done > Reading search index Done > Updating search index 2/2 > Updating package cache 1/1 > Creating Plan (Solver setup): / > pkg install: No matching version of system/library can be installed: > Reject: pkg://omnios/system/library at 0.5.11-0.151022 > pkg://omnios/system/library at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/ses can be installed: > Reject: pkg://omnios/driver/storage/ses at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/kernel at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/graphics/agpgart at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/graphics/agpgart at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel can be installed > ---------------------------------------- > Reject: pkg://omnios/system/kernel at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel/platform at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/kernel/platform at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/serial/usbser at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/serial/usbser at 0.5.11-0.151022 > pkg://omnios/driver/serial/usbser at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/system/kernel/platform at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/serial/usbser at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > ---------------------------------------- > ---------------------------------------- > Reject: pkg://omnios/driver/graphics/agpgart at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel can be installed > ---------------------------------------- > Reject: pkg://omnios/system/kernel at 0.5.11-0.151022 > Reason: [already rejected; see above] > ---------------------------------------- > Reject: pkg://omnios/driver/storage/ses at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/ixgb can be installed: > Reject: pkg://omnios/driver/network/ixgb at 0.5.11-0.151022 > pkg://omnios/driver/network/ixgb at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/storage/aac can be installed: > Reject: pkg://omnios/driver/storage/aac at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/aac at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of system/kernel/security/gss can be installed: > Reject: pkg://omnios/system/kernel/security/gss at 0.5.11-0.151022 > pkg://omnios/system/kernel/security/gss at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/fcsm can be installed: > Reject: pkg://omnios/driver/network/fcsm at 0.5.11-0.151022 > pkg://omnios/driver/network/fcsm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/ibdma can be installed: > Reject: pkg://omnios/driver/network/ibdma at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/network/ib at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/network/ib at 0.5.11-0.151022 > pkg://omnios/driver/network/ib at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/network/ibdma at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/network/ib at 0.5.11-0.151022 can be installed > No matching version of driver/serial/usbser_edge can be installed: > Reject: pkg://omnios/driver/serial/usbser_edge at 0.5.11-0.151022 > pkg://omnios/driver/serial/usbser_edge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/tavor can be installed: > Reject: pkg://omnios/driver/network/tavor at 0.5.11-0.151022 > pkg://omnios/driver/network/tavor at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/ahci can be installed: > Reject: pkg://omnios/driver/storage/ahci at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/storage/ahci at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/storage/mpt_sas can be installed: > Reject: pkg://omnios/driver/storage/mpt_sas at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/mpt_sas at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of service/picl can be installed: > Reject: pkg://omnios/service/picl at 0.5.11-0.151022 > pkg://omnios/service/picl at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/pmcs can be installed: > Reject: pkg://omnios/driver/storage/pmcs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/storage/pmcs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/library/zlib at 1.2.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > ---------------------------------------- > No matching version of driver/storage/bcm_sata can be installed: > Reject: pkg://omnios/driver/storage/bcm_sata at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/bcm_sata at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/data/zoneinfo can be installed: > Reject: pkg://omnios/system/data/zoneinfo at 2017.2-0.151022 > pkg://omnios/system/data/zoneinfo at 2017.2-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/serial/usbftdi can be installed: > Reject: pkg://omnios/driver/serial/usbftdi at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/usb at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/usb at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/audio at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/audio at 0.5.11-0.151022 > pkg://omnios/driver/audio at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/usb at 0.5.11-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/serial/usbftdi at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of network/openssh can be installed: > Reject: pkg://omnios/network/openssh at 7.4.1-0.151022 > Reason: No version matching 'require' dependency library/security/openssl at 1.0.2.11 -0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/library/security/openssl at 1.0.2.11-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11 can be installed > Reject: pkg://omnios/library/security/openssl at 1.0.2.11-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/SUNWcs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency service/fault-management at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/service/fault-management at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/libxml2 at 2.9.4-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/library/libxml2 at 2.9.4-0.151022 > pkg://omnios/library/libxml2 at 2.9.4-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/service/fault-management at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > Reason: No version matching 'require' dependency system/file-system/zfs at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/file-system/zfs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency runtime/python-27 can be installed > ---------------------------------------- > Reject: pkg://omnios/runtime/python-27 at 2.7.13-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency library/libffi at 3.2.1 can be installed > ---------------------------------------- > Reject: pkg://omnios/library/libffi at 3.2.1-0.151022 > pkg://omnios/library/libffi at 3.2.1-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/runtime/python-27 at 2.7.13-0.151022 > Reason: No version matching 'require' dependency library/libffi at 3.2.1 can be installed > Reason: No version matching 'require' dependency library/libxml2 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/file-system/zfs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency runtime/python-27 can be installed > ---------------------------------------- > Reject: pkg://omnios/SUNWcs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency install/beadm at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/install/beadm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reject: pkg://omnios/install/beadm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency package/svr4 at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/package/svr4 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/package/svr4 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > ---------------------------------------- > ---------------------------------------- > ---------------------------------------- > Reason: No version matching 'require' dependency library/zlib at 1.2.11 can be installed > ---------------------------------------- > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/network/openssh at 7.4.1-0.151022 > Reason: No version matching 'require' dependency library/security/openssl at 1.0.2.11 -0.151022 can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of system/boot/wanboot/internal can be installed: > Reject: pkg://omnios/system/boot/wanboot/internal at 0.5.11-0.151022 > pkg://omnios/system/boot/wanboot/internal at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/library/storage/fibre-channel/hbaapi can be installed: > Reject: pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/system/library/storage/fibre-channel/hbaapi at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/network/vioif can be installed: > Reject: pkg://omnios/driver/network/vioif at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/misc/virtio at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/misc/virtio at 0.5.11-0.151022 > pkg://omnios/driver/misc/virtio at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/network/vioif at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/library/policykit can be installed: > Reject: pkg://omnios/system/library/policykit at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/glib2 at 2.34.3-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/library/glib2 at 2.34.3-0.151022 > pkg://omnios/library/glib2 at 2.34.3-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency library/libffi at 3.2.1 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/library/policykit at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/glib2 at 2.34.3-0.151022 can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/crypto/tpm can be installed: > Reject: pkg://omnios/driver/crypto/tpm at 0.5.11-0.151022 > pkg://omnios/driver/crypto/tpm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/graphics/agpgart can be installed: > Reject: pkg://omnios/driver/graphics/agpgart at 0.5.11-0.151022 > pkg://omnios/driver/graphics/agpgart at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/network/ixgbe can be installed: > Reject: pkg://omnios/driver/network/ixgbe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/ixgbe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of install/beadm can be installed: > Reject: pkg://omnios/install/beadm at 0.5.11-0.151022 > pkg://omnios/install/beadm at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/network/nge can be installed: > Reject: pkg://omnios/driver/network/nge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/nge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of file/gnu-coreutils can be installed: > Reject: pkg://omnios/file/gnu-coreutils at 8.27-0.151022 > Reason: No version matching 'require' dependency library/gmp at 6.1.2-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/library/gmp at 6.1.2-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reject: pkg://omnios/library/gmp at 6.1.2-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library/gcc-5-runtime at 5.1.0-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/library/gcc-5-runtime at 5.1.0-0.151022 > pkg://omnios/system/library/gcc-5-runtime at 5.1.0-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > ---------------------------------------- > ---------------------------------------- > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/file/gnu-coreutils at 8.27-0.151022 > Reason: No version matching 'require' dependency library/gmp at 6.1.2-0.151022 can be installed > Reason: No version matching 'require' dependency library/security/openssl at 1.0.2.11 -0.151022 can be installed > No matching version of driver/serial/usbsksp/usbs49_fw can be installed: > Reject: pkg://omnios/driver/serial/usbsksp/usbs49_fw at 0.5.11-0.151022 > pkg://omnios/driver/serial/usbsksp/usbs49_fw at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/glm can be installed: > Reject: pkg://omnios/driver/storage/glm at 0.5.11-0.151022 > pkg://omnios/driver/storage/glm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/file-system/smb can be installed: > Reject: pkg://omnios/system/file-system/smb at 0.5.11-0.151022 > pkg://omnios/system/file-system/smb at 0.5.11-0.151022 > Reason: No version for 'require' dependency on system/library/iconv/utf-8 can be found > No matching version of system/extended-system-utilities can be installed: > Reject: pkg://omnios/system/extended-system-utilities at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library/math at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/library/math at 0.5.11-0.151022 > pkg://omnios/system/library/math at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > Reject: pkg://omnios/system/extended-system-utilities at 0.5.11-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/library/storage/libmpscsi_vhci can be installed: > Reject: pkg://omnios/system/library/storage/libmpscsi_vhci at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reject: pkg://omnios/system/library/storage/libmpscsi_vhci at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/file-system/udfs can be installed: > Reject: pkg://omnios/system/file-system/udfs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/system/file-system/udfs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/nv_sata can be installed: > Reject: pkg://omnios/driver/storage/nv_sata at 0.5.11-0.151022 > pkg://omnios/driver/storage/nv_sata at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/graphics/atiatom can be installed: > Reject: pkg://omnios/driver/graphics/atiatom at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/graphics/atiatom at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel/platform at 0.5.11-0.151022 can be installed > No matching version of driver/network/myri10ge can be installed: > Reject: pkg://omnios/driver/network/myri10ge at 0.5.11-0.151022 > pkg://omnios/driver/network/myri10ge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/ofk can be installed: > Reject: pkg://omnios/driver/network/ofk at 0.5.11-0.151022 > pkg://omnios/driver/network/ofk at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/xvm/pv can be installed: > Reject: pkg://omnios/driver/xvm/pv at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/xvm/pv at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/i86pc/platform at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/i86pc/platform at 0.5.11-0.151022 > pkg://omnios/driver/i86pc/platform at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > No matching version of system/fru-id can be installed: > Reject: pkg://omnios/system/fru-id at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/system/fru-id at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library/g++-5-runtime at 5.1.0-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/library/g++-5-runtime at 5.1.0-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library/gcc-5-runtime at 5.1.0-0.151022 can be installed > Reject: pkg://omnios/system/library/g++-5-runtime at 5.1.0-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > ---------------------------------------- > Reason: No version matching 'require' dependency system/library/gcc-5-runtime at 5.1.0-0.151022 can be installed > No matching version of system/library/storage/scsi-plugins can be installed: > Reject: pkg://omnios/system/library/storage/scsi-plugins at 0.5.11-0.151022 > pkg://omnios/system/library/storage/scsi-plugins at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > No matching version of system/ipc can be installed: > Reject: pkg://omnios/system/ipc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/system/ipc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/sdp can be installed: > Reject: pkg://omnios/driver/network/sdp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/network/sdpib at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/network/sdpib at 0.5.11-0.151022 > pkg://omnios/driver/network/sdpib at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/network/sdp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of system/flash/fwflash can be installed: > Reject: pkg://omnios/system/flash/fwflash at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/system/flash/fwflash at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/storage/mega_sas can be installed: > Reject: pkg://omnios/driver/storage/mega_sas at 0.5.11-0.151022 > pkg://omnios/driver/storage/mega_sas at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/emlxs can be installed: > Reject: pkg://omnios/driver/network/emlxs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/emlxs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/network/rtls can be installed: > Reject: pkg://omnios/driver/network/rtls at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/rtls at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/ata can be installed: > Reject: pkg://omnios/driver/storage/ata at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/storage/ata at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of system/library/storage/ima can be installed: > Reject: pkg://omnios/system/library/storage/ima at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/system/library/storage/ima at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > No matching version of system/boot/wanboot can be installed: > Reject: pkg://omnios/system/boot/wanboot at 0.5.11-0.151022 > pkg://omnios/system/boot/wanboot at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/fru-id/platform can be installed: > Reject: pkg://omnios/system/fru-id/platform at 0.5.11-0.151022 > pkg://omnios/system/fru-id/platform at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/yge can be installed: > Reject: pkg://omnios/driver/network/yge at 0.5.11-0.151022 > pkg://omnios/driver/network/yge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/arcmsr can be installed: > Reject: pkg://omnios/driver/storage/arcmsr at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/arcmsr at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/i86pc/fipe can be installed: > Reject: pkg://omnios/driver/i86pc/fipe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/i86pc/ioat at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/i86pc/ioat at 0.5.11-0.151022 > pkg://omnios/driver/i86pc/ioat at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/i86pc/fipe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/blkdev can be installed: > Reject: pkg://omnios/driver/storage/blkdev at 0.5.11-0.151022 > pkg://omnios/driver/storage/blkdev at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/library/storage/libmpapi can be installed: > Reject: pkg://omnios/system/library/storage/libmpapi at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library/storage/libmpscsi_vhci can be installed > Reject: pkg://omnios/system/library/storage/libmpapi at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/storage/adpu320 can be installed: > Reject: pkg://omnios/driver/storage/adpu320 at 0.5.11-0.151022 > pkg://omnios/driver/storage/adpu320 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/network can be installed: > Reject: pkg://omnios/system/network at 0.5.11-0.151022 > Reason: No version matching 'require' dependency network/bridging at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/network/bridging at 0.5.11-0.151022 > pkg://omnios/network/bridging at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/system/network at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/library/math can be installed: > Reject: pkg://omnios/system/library/math at 0.5.11-0.151022 > pkg://omnios/system/library/math at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/firewire can be installed: > Reject: pkg://omnios/driver/firewire at 0.5.11-0.151022 > pkg://omnios/driver/firewire at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/file-system/zfs can be installed: > Reject: pkg://omnios/system/file-system/zfs at 0.5.11-0.151022 > pkg://omnios/system/file-system/zfs at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/network/mxfe can be installed: > Reject: pkg://omnios/driver/network/mxfe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/mxfe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/crypto/dca can be installed: > Reject: pkg://omnios/driver/crypto/dca at 0.5.11-0.151022 > pkg://omnios/driver/crypto/dca at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/storage/fibre-channel/port-utility can be installed: > Reject: pkg://omnios/system/storage/fibre-channel/port-utility at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library/storage/fibre-channel/hbaapi at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/system/storage/fibre-channel/port-utility at 0.5.11-0.151022 > Reason: No version matching 'require' dependency service/storage/fibre-channel/fc-fabric can be installed > ---------------------------------------- > Reject: pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11-0.151022 > pkg://omnios/service/storage/fibre-channel/fc-fabric at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ---------------------------------------- > No matching version of driver/storage/smp can be installed: > Reject: pkg://omnios/driver/storage/smp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/storage/smp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/storage/mr_sas can be installed: > Reject: pkg://omnios/driver/storage/mr_sas at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/storage/mr_sas at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of system/library/storage/fibre-channel/libsun_fc can be installed: > Reject: pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library/gcc-5-runtime at 5.1.0-0.151022 can be installed > Reject: pkg://omnios/system/library/storage/fibre-channel/libsun_fc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/network/sfxge can be installed: > Reject: pkg://omnios/driver/network/sfxge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/sfxge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/igb can be installed: > Reject: pkg://omnios/driver/network/igb at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/igb at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/i86pc/platform can be installed: > Reject: pkg://omnios/driver/i86pc/platform at 0.5.11-0.151022 > pkg://omnios/driver/i86pc/platform at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/usb can be installed: > Reject: pkg://omnios/driver/usb at 0.5.11-0.151022 > pkg://omnios/driver/usb at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/network/rpcib can be installed: > Reject: pkg://omnios/driver/network/rpcib at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/network/ib at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/rpcib at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/serial/usbsprl can be installed: > Reject: pkg://omnios/driver/serial/usbsprl at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/serial/usbser at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/serial/usbsprl at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/serial/usbser at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency driver/usb at 0.5.11-0.151022 can be installed > No matching version of system/data/keyboard/keytables can be installed: > Reject: pkg://omnios/system/data/keyboard/keytables at 0.5.11-0.151022 > pkg://omnios/system/data/keyboard/keytables at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/pcn can be installed: > Reject: pkg://omnios/driver/network/pcn at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/pcn at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/iprb can be installed: > Reject: pkg://omnios/driver/network/iprb at 0.5.11-0.151022 > pkg://omnios/driver/network/iprb at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/misc/virtio can be installed: > Reject: pkg://omnios/driver/misc/virtio at 0.5.11-0.151022 > pkg://omnios/driver/misc/virtio at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/network/rdsv3 can be installed: > Reject: pkg://omnios/driver/network/rdsv3 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/rdsv3 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/file-system/autofs can be installed: > Reject: pkg://omnios/system/file-system/autofs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/system/file-system/autofs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/network/bnx can be installed: > Reject: pkg://omnios/driver/network/bnx at 0.5.11-0.151022 > pkg://omnios/driver/network/bnx at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of web/curl can be installed: > Reject: pkg://omnios/web/curl at 7.54.0-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency library/libidn can be installed > ---------------------------------------- > Reject: pkg://omnios/library/libidn at 1.33-0.151022 > pkg://omnios/library/libidn at 1.33-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/web/curl at 7.54.0-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency library/libidn can be installed > No matching version of driver/network/vr can be installed: > Reject: pkg://omnios/driver/network/vr at 0.5.11-0.151022 > pkg://omnios/driver/network/vr at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/pvscsi can be installed: > Reject: pkg://omnios/driver/storage/pvscsi at 0.5.11-0.151022 > pkg://omnios/driver/storage/pvscsi at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/afe can be installed: > Reject: pkg://omnios/driver/network/afe at 0.5.11-0.151022 > pkg://omnios/driver/network/afe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/i40e can be installed: > Reject: pkg://omnios/driver/network/i40e at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/i40e at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/amd8111s can be installed: > Reject: pkg://omnios/driver/network/amd8111s at 0.5.11-0.151022 > pkg://omnios/driver/network/amd8111s at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/sfe can be installed: > Reject: pkg://omnios/driver/network/sfe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/sfe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/serial/usbsksp can be installed: > Reject: pkg://omnios/driver/serial/usbsksp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/serial/usbsksp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/serial/usbser at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency driver/usb at 0.5.11-0.151022 can be installed > No matching version of driver/usb/ugen can be installed: > Reject: pkg://omnios/driver/usb/ugen at 0.5.11-0.151022 > pkg://omnios/driver/usb/ugen at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/hme can be installed: > Reject: pkg://omnios/driver/network/hme at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/hme at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/platform can be installed: > Reject: pkg://omnios/driver/network/platform at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/network/pcn can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/platform at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/network/pcn can be installed > No matching version of driver/network/fcp can be installed: > Reject: pkg://omnios/driver/network/fcp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/fcp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/network/fp at 0.5.11-0.151022 can be installed > ---------------------------------------- > Reject: pkg://omnios/driver/network/fp at 0.5.11-0.151022 > pkg://omnios/driver/network/fp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > ---------------------------------------- > No matching version of developer/linker can be installed: > Reject: pkg://omnios/developer/linker at 0.5.11-0.151022 > pkg://omnios/developer/linker at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/pcmcia can be installed: > Reject: pkg://omnios/driver/pcmcia at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/pcmcia at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/data/hardware-registry can be installed: > Reject: pkg://omnios/system/data/hardware-registry at 0.5.11-0.151022 > pkg://omnios/system/data/hardware-registry at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/nxge can be installed: > Reject: pkg://omnios/driver/network/nxge at 0.5.11-0.151022 > pkg://omnios/driver/network/nxge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/elxl can be installed: > Reject: pkg://omnios/driver/network/elxl at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/elxl at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/atge can be installed: > Reject: pkg://omnios/driver/network/atge at 0.5.11-0.151022 > pkg://omnios/driver/network/atge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/bnxe can be installed: > Reject: pkg://omnios/driver/network/bnxe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/bnxe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/nvme can be installed: > Reject: pkg://omnios/driver/storage/nvme at 0.5.11-0.151022 > pkg://omnios/driver/storage/nvme at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/chxge can be installed: > Reject: pkg://omnios/driver/network/chxge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/chxge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/fcip can be installed: > Reject: pkg://omnios/driver/network/fcip at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/fcip at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/bpf can be installed: > Reject: pkg://omnios/driver/network/bpf at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/bpf at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/fp can be installed: > Reject: pkg://omnios/driver/network/fp at 0.5.11-0.151022 > pkg://omnios/driver/network/fp at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of system/library/platform can be installed: > Reject: pkg://omnios/system/library/platform at 0.5.11-0.151022 > pkg://omnios/system/library/platform at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/hxge can be installed: > Reject: pkg://omnios/driver/network/hxge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/hxge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/e1000g can be installed: > Reject: pkg://omnios/driver/network/e1000g at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/e1000g at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of shell/pipe-viewer can be installed: > Reject: pkg://omnios/shell/pipe-viewer at 1.6.0-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reject: pkg://omnios/shell/pipe-viewer at 1.6.0-0.151022 > Reason: No version matching 'require' dependency library/zlib at 1.2.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of system/library/storage/ima/header-ima can be installed: > Reject: pkg://omnios/system/library/storage/ima/header-ima at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/library/storage/ima can be installed > Reject: pkg://omnios/system/library/storage/ima/header-ima at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/usbecm can be installed: > Reject: pkg://omnios/driver/network/usbecm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/usbecm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/boot/loader can be installed: > Reject: pkg://omnios/system/boot/loader at 1.1-0.151022 > pkg://omnios/system/boot/loader at 1.1-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/data/terminfo can be installed: > Reject: pkg://omnios/system/data/terminfo at 0.5.11-0.151022 > pkg://omnios/system/data/terminfo at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of library/libidn can be installed: > Reject: pkg://omnios/library/libidn at 1.33-0.151022 > pkg://omnios/library/libidn at 1.33-0.151022 > Reason: [already rejected; see above] > No matching version of driver/network/ibp can be installed: > Reject: pkg://omnios/driver/network/ibp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/ibp at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/network/xge can be installed: > Reject: pkg://omnios/driver/network/xge at 0.5.11-0.151022 > pkg://omnios/driver/network/xge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/audio can be installed: > Reject: pkg://omnios/driver/audio at 0.5.11-0.151022 > pkg://omnios/driver/audio at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of system/boot/real-mode can be installed: > Reject: pkg://omnios/system/boot/real-mode at 0.5.11-0.151022 > pkg://omnios/system/boot/real-mode at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/ib can be installed: > Reject: pkg://omnios/driver/network/ib at 0.5.11-0.151022 > pkg://omnios/driver/network/ib at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of SUNWcs can be installed: > Reject: pkg://omnios/SUNWcs at 0.5.11-0.151022 > pkg://omnios/SUNWcs at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/network/qlc can be installed: > Reject: pkg://omnios/driver/network/qlc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency driver/network/fp at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/qlc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/graphics/drm can be installed: > Reject: pkg://omnios/driver/graphics/drm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library can be installed > Reject: pkg://omnios/driver/graphics/drm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/graphics/agpgart can be installed > Reason: No version matching 'require' dependency system/kernel/platform can be installed > No matching version of system/file-system/nfs can be installed: > Reject: pkg://omnios/system/file-system/nfs at 0.5.11-0.151022 > pkg://omnios/system/file-system/nfs at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/serial/usbser can be installed: > Reject: pkg://omnios/driver/serial/usbser at 0.5.11-0.151022 > pkg://omnios/driver/serial/usbser at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of SUNWcsd can be installed: > Reject: pkg://omnios/SUNWcsd at 0.5.11-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/SUNWcsd at 0.5.11-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/serial/usbsacm can be installed: > Reject: pkg://omnios/driver/serial/usbsacm at 0.5.11-0.151022 > pkg://omnios/driver/serial/usbsacm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/serial/usbser at 0.5.11-0.151022 can be installed > No matching version of driver/network/bge can be installed: > Reject: pkg://omnios/driver/network/bge at 0.5.11-0.151022 > pkg://omnios/driver/network/bge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of system/storage/luxadm can be installed: > Reject: pkg://omnios/system/storage/luxadm at 0.5.11-0.151022 > pkg://omnios/system/storage/luxadm at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/vioblk can be installed: > Reject: pkg://omnios/driver/storage/vioblk at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/storage/blkdev at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/vioblk at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/misc/virtio at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency driver/storage/blkdev at 0.5.11-0.151022 can be installed > No matching version of driver/storage/scsa1394 can be installed: > Reject: pkg://omnios/driver/storage/scsa1394 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/scsa1394 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/sbp2 can be installed: > Reject: pkg://omnios/driver/storage/sbp2 at 0.5.11-0.151022 > pkg://omnios/driver/storage/sbp2 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/rds can be installed: > Reject: pkg://omnios/driver/network/rds at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/network/ib at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/rds at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/hermon can be installed: > Reject: pkg://omnios/driver/network/hermon at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/network/ib at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/hermon at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/dmfe can be installed: > Reject: pkg://omnios/driver/network/dmfe at 0.5.11-0.151022 > pkg://omnios/driver/network/dmfe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/sdpib can be installed: > Reject: pkg://omnios/driver/network/sdpib at 0.5.11-0.151022 > pkg://omnios/driver/network/sdpib at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/storage/sdcard can be installed: > Reject: pkg://omnios/driver/storage/sdcard at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/storage/sdcard at 0.5.11-0.151022 > Reason: No version matching 'require' dependency driver/storage/blkdev at 0.5.11-0.151022 can be installed > No matching version of diagnostic/diskinfo can be installed: > Reject: pkg://omnios/diagnostic/diskinfo at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency service/fault-management at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/diagnostic/diskinfo at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of network/openssh-server can be installed: > Reject: pkg://omnios/network/openssh-server at 7.4.1-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/network/openssh-server at 7.4.1-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > Reason: No version matching 'require' dependency system/library at 0.5.11-0.151022 can be installed > No matching version of driver/network/eoib can be installed: > Reject: pkg://omnios/driver/network/eoib at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/eoib at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/network/ntxn can be installed: > Reject: pkg://omnios/driver/network/ntxn at 0.5.11-0.151022 > pkg://omnios/driver/network/ntxn at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of editor/vim can be installed: > Reject: pkg://omnios/editor/vim at 8.0.567-0.151022 > pkg://omnios/editor/vim at 8.0.567-0.151022 > Reason: No version matching 'require' dependency SUNWcs at 0.5.11-0.151022 can be installed > No matching version of driver/storage/si3124 can be installed: > Reject: pkg://omnios/driver/storage/si3124 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/si3124 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/rge can be installed: > Reject: pkg://omnios/driver/network/rge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/rge at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/storage/lsimega can be installed: > Reject: pkg://omnios/driver/storage/lsimega at 0.5.11-0.151022 > pkg://omnios/driver/storage/lsimega at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/storage/marvell88sx can be installed: > Reject: pkg://omnios/driver/storage/marvell88sx at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/marvell88sx at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of system/library/processor can be installed: > Reject: pkg://omnios/system/library/processor at 0.5.11-0.151022 > pkg://omnios/system/library/processor at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/i86pc/ioat can be installed: > Reject: pkg://omnios/driver/i86pc/ioat at 0.5.11-0.151022 > pkg://omnios/driver/i86pc/ioat at 0.5.11-0.151022 > Reason: [already rejected; see above] > No matching version of driver/storage/amr can be installed: > Reject: pkg://omnios/driver/storage/amr at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/storage/amr at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of system/kernel/dynamic-reconfiguration/i86pc can be installed: > Reject: pkg://omnios/system/kernel/dynamic-reconfiguration/i86pc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency system/kernel/platform at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/system/kernel/dynamic-reconfiguration/i86pc at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel/platform at 0.5.11-0.151022 can be installed > No matching version of text/less can be installed: > Reject: pkg://omnios/text/less at 487-0.151022 > pkg://omnios/text/less at 487-0.151022 > Reason: No version matching 'require' dependency SUNWcs can be installed > No matching version of driver/network/bfe can be installed: > Reject: pkg://omnios/driver/network/bfe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reject: pkg://omnios/driver/network/bfe at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > No matching version of driver/storage/cpqary3 can be installed: > Reject: pkg://omnios/driver/storage/cpqary3 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/storage/cpqary3 at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > No matching version of driver/network/vmxnet3s can be installed: > Reject: pkg://omnios/driver/network/vmxnet3s at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > Reason: No version matching 'require' dependency system/kernel at 0.5.11-0.151022 can be installed > Reject: pkg://omnios/driver/network/vmxnet3s at 0.5.11-0.151022 > Reason: No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed > ERROR: install > gmake: *** [Makefile:89: /rpool/kayak_image/miniroot.gz] Error 1 > root at sca:/code/kayak# > > wetong at amoyun.com > > From: wetong at amoyun.com > Date: 2017-06-05 10:30 > To: weicong_deng > Subject: compile error > > root at sca:/code/kayak# PKGURL=file:///code/ywos/ > root at sca:/code/kayak# export PKGURL > root at sca:/code/kayak# gmake install-usb > mkdir -p /tftpboot/boot/grub > mkdir -p /tftpboot/boot/platform/i86pc/kernel/amd64 > mkdir -p /tftpboot/kayak > if test -n "`zfs list -H -t snapshot rpool/kayak_image/root at fixup 2>/dev/null`"; then \ > VERSION=r151022 DEBUG= ./build_image.sh rpool/kayak_image fixup ; \ > else \ > VERSION=r151022 DEBUG= ./build_image.sh rpool/kayak_image begin ; \ > fi > WARNING -- Not using 'native' svccfg, may hang on build. > We recommend a pre-built illumos's svccfg-native. > Set PREBUILT_ILLUMOS in your environment to point > to a built illumos-omnios repository. > Explicit checkpoint requested: 'begin' > === Proceeding to phase begin === > === Proceeding to phase pkg (zfs @pkg) === > Creating image of omnios from file:///code/ywos/ > > > pkg install: The following pattern(s) did not match any allowable packages. Try > using a different matching pattern, or refreshing publisher information: > > omnios-userland at 11-0.151022 > illumos-gate at 11-0.151022 > ERROR: version constraint prep > gmake: *** [Makefile:89: /rpool/kayak_image/miniroot.gz] Error 1 > root at sca:/code/kayak# > > > > dwq at xmweixun.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at kebe.com Mon Jun 12 01:36:02 2017 From: danmcd at kebe.com (Dan McDonald) Date: Sun, 11 Jun 2017 21:36:02 -0400 Subject: [OmniOS-discuss] Fwd: Kayak failed to make the release images of 151022 by the local Repos In-Reply-To: <4D0F593A-4C6C-4E13-95E3-88D8376C1A7A@xmweixun.com> References: <2017061017181217298915@amoyun.com> <4D0F593A-4C6C-4E13-95E3-88D8376C1A7A@xmweixun.com> Message-ID: <20170612013602.GA21799@everywhere.local> It's like you're missing packages. Did you populate it with both illumos-omnios AND omnios-build packages? Dan From omnios at citrus-it.net Wed Jun 14 08:06:25 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Wed, 14 Jun 2017 08:06:25 +0000 (UTC) Subject: [OmniOS-discuss] p7zip: CVE 2016-9296 In-Reply-To: References: Message-ID: On Fri, 9 Jun 2017, Aur?lien Larcher wrote: ; Hi, ; when I bumped p7zip in oi-userland I noticed that CVE 2016-9296 still ; affects 16.02: we had this patch against 15.14.1 and I was surprised that ; it was still valid, then I checked it on the usual websites. ; Out of curiosity I looked if you have it in omnios-build and it is ; apparently missing. ; Kind regards, ; ; Aur?lien Thanks for this, I've updated my fork of omnios-build. I could raise a pull request against omnios-build but I don't think anyone is looking at these yet. 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 ozkan.goksu at usishi.com Wed Jun 14 15:44:10 2017 From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=) Date: Wed, 14 Jun 2017 18:44:10 +0300 Subject: [OmniOS-discuss] NFS mounts seems as nobody on Centos6 Message-ID: Hello. I have a nfs share and zfs settings like= "sharenfs anon=root,rw=* " When i mount it from Centos, owner changes as nobody. (yes im root on Centos) But in omnios or ubuntu i see as root when i mount it. What is the cause of this problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From info.fmo at gmx.de Wed Jun 14 17:13:55 2017 From: info.fmo at gmx.de (Frank M.) Date: Wed, 14 Jun 2017 19:13:55 +0200 Subject: [OmniOS-discuss] HBA Broadcom SAS 9305-16i (SAS3224) Message-ID: <189281273.20170614191355@gmx.de> Hi, anybody knows, if HBA Broadcom SAS 9305-16i (SAS3224) works properly? Best regards, Frank From danmcd at kebe.com Wed Jun 14 17:31:28 2017 From: danmcd at kebe.com (Dan McDonald) Date: Wed, 14 Jun 2017 13:31:28 -0400 Subject: [OmniOS-discuss] HBA Broadcom SAS 9305-16i (SAS3224) In-Reply-To: <189281273.20170614191355@gmx.de> References: <189281273.20170614191355@gmx.de> Message-ID: <20170614173128.GA25005@everywhere.local> On Wed, Jun 14, 2017 at 07:13:55PM +0200, Frank M. wrote: > Hi, > > anybody knows, if HBA Broadcom SAS 9305-16i (SAS3224) works properly? The 16-port one, no. Sorry, Dan From bfriesen at simple.dallas.tx.us Wed Jun 14 17:33:28 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 14 Jun 2017 12:33:28 -0500 (CDT) Subject: [OmniOS-discuss] HBA Broadcom SAS 9305-16i (SAS3224) In-Reply-To: <189281273.20170614191355@gmx.de> References: <189281273.20170614191355@gmx.de> Message-ID: On Wed, 14 Jun 2017, Frank M. wrote: > Hi, > > anybody knows, if HBA Broadcom SAS 9305-16i (SAS3224) works properly? I am using a SAS 9300-16i successfully. Obtaining a stable boot required disabling the adaptor BIOS on each of the logical HBAs so that it did not advertise the 16 drives to the Supermicro BIOS. No idea about the 9305-16i or how it relates to what I am using. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From aurelien.larcher at gmail.com Thu Jun 15 04:49:58 2017 From: aurelien.larcher at gmail.com (=?UTF-8?Q?Aur=C3=A9lien_Larcher?=) Date: Thu, 15 Jun 2017 06:49:58 +0200 Subject: [OmniOS-discuss] p7zip: CVE 2016-9296 In-Reply-To: References: Message-ID: On Wed, Jun 14, 2017 at 10:06 AM, Andy Fiddaman wrote: > > On Fri, 9 Jun 2017, Aur?lien Larcher wrote: > > ; Hi, > ; when I bumped p7zip in oi-userland I noticed that CVE 2016-9296 still > ; affects 16.02: we had this patch against 15.14.1 and I was surprised that > ; it was still valid, then I checked it on the usual websites. > ; Out of curiosity I looked if you have it in omnios-build and it is > ; apparently missing. > ; Kind regards, > ; > ; Aur?lien > > Thanks for this, I've updated my fork of omnios-build. I could raise a pull > request against omnios-build but I don't think anyone is looking at these > yet. > Happy to help. That's one reason why I advocated a common userland recently, maybe something to ponder in the future. Kind regards Aur?lien > > 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 > > -- --- Praise the Caffeine embeddings -------------- next part -------------- An HTML attachment was scrubbed... URL: From filip.marvan at aira.cz Thu Jun 15 10:43:04 2017 From: filip.marvan at aira.cz (Filip Marvan) Date: Thu, 15 Jun 2017 12:43:04 +0200 Subject: [OmniOS-discuss] Python conflicts in upgrade from 20 to 22 Message-ID: <3BE0DEED8863E5429BAE4CAEDF62456504048D050D1A@AIRA-SRV.aira.local> Hello, I'm doing upgrade from version 20 to 22 LTS, and when I run pkg updade (after changing Publisher), I'm receiving many conflicts between Python 2.6 and 2.7 which prevents me in upgrade. Can anyone please help me, how to correctly do upgrade with replacing Python 2.6 with Python 2.7? Thank you very much, Filip ---- pkg update: The requested change to the system attempts to install multiple actions for link 'usr/bin/amd64/python-config' with conflicting attributes: 1 package delivers 'link path=usr/bin/amd64/python-config target=python2-config': pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z 1 package delivers 'link path=usr/bin/amd64/python-config target=python2.6-config': pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. The following packages all deliver file actions to usr/bin/smtpd.py: pkg://omnios/runtime/python-27 at 2.7.13,5.11-0.151022:20170511T005259Z pkg://omnios/runtime/python-26 at 2.6.8,5.11-0.151020:20161102T021635Z ...and many more --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From an3s.annema at gmail.com Thu Jun 15 18:18:42 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Thu, 15 Jun 2017 20:18:42 +0200 Subject: [OmniOS-discuss] NFS mounts seems as nobody on Centos6 In-Reply-To: References: Message-ID: <520c4a65-6f77-75a9-d9a1-62eb52c943b9@gmail.com> Hi ?zkan, The first thing that comes to mind is "no_root_squash" and, based on your example setting with options like "anon=root", I assume this option can be set as well on OmniOS with the "sharenfs" setting. Maybe these will help: https://serverfault.com/questions/364613/centos-6-ldap-nfs-file-ownership-is-stuck-on-nobody http://www.linuxtopia.org/online_books/rhel6/rhel_6_storage_admin/rhel_6_storage_s2-nfs-security-files.html Disclaimer: I am not an expert on NFS! Far from it. The above suggestion is based on some personal experience where I needed that "no_root_squash" option (although that was with some Linux distro's), and some Google-fu. With that said, I am not sure if it adds a security threat or something. Anyway, my two cents. Regards, Andries On 2017-06-14 17:44, ?zkan G?ksu wrote: > Hello. > > I have a nfs share and zfs settings like= "sharenfs anon=root,rw=* " > When i mount it from Centos, owner changes as nobody. (yes im root on > Centos) > But in omnios or ubuntu i see as root when i mount it. > > What is the cause of this problem? > > > > > _______________________________________________ > 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 ikaufman at eng.ucsd.edu Thu Jun 15 18:47:23 2017 From: ikaufman at eng.ucsd.edu (Ian Kaufman) Date: Thu, 15 Jun 2017 11:47:23 -0700 Subject: [OmniOS-discuss] NFS mounts seems as nobody on Centos6 In-Reply-To: <520c4a65-6f77-75a9-d9a1-62eb52c943b9@gmail.com> References: <520c4a65-6f77-75a9-d9a1-62eb52c943b9@gmail.com> Message-ID: Are you using NFSv4? Are all machines using the same idmap domain? Ian On Thu, Jun 15, 2017 at 11:18 AM, Andries Annema wrote: > Hi ?zkan, > > The first thing that comes to mind is "no_root_squash" and, based on your > example setting with options like "anon=root", I assume this option can be > set as well on OmniOS with the "sharenfs" setting. > > Maybe these will help: > https://serverfault.com/questions/364613/centos-6- > ldap-nfs-file-ownership-is-stuck-on-nobody > http://www.linuxtopia.org/online_books/rhel6/rhel_6_ > storage_admin/rhel_6_storage_s2-nfs-security-files.html > > > Disclaimer: I am not an expert on NFS! Far from it. The above suggestion > is based on some personal experience where I needed that "no_root_squash" > option (although that was with some Linux distro's), and some Google-fu. > With that said, I am not sure if it adds a security threat or something. > > Anyway, my two cents. > > Regards, > Andries > > > On 2017-06-14 17:44, ?zkan G?ksu wrote: > > Hello. > > I have a nfs share and zfs settings like= "sharenfs anon=root,rw=* " > When i mount it from Centos, owner changes as nobody. (yes im root on > Centos) > But in omnios or ubuntu i see as root when i mount it. > > What is the cause of this problem? > > > > > _______________________________________________ > OmniOS-discuss mailing listOmniOS-discuss at lists.omniti.comhttp://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 > > -- 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 lkateley at kateley.com Thu Jun 15 18:57:26 2017 From: lkateley at kateley.com (Linda Kateley) Date: Thu, 15 Jun 2017 13:57:26 -0500 Subject: [OmniOS-discuss] NFS mounts seems as nobody on Centos6 In-Reply-To: References: <520c4a65-6f77-75a9-d9a1-62eb52c943b9@gmail.com> Message-ID: <105d2ed7-fdc8-2b16-13c4-324cd95f56ca@kateley.com> this might not answer your question but.. anon=root means that any user that tries to mount that is unknown to the server will be treated as if they are root and root from another system will be given the permission of nobody.. what you want is root=someuser.. In nfs root from another system is almost always seen as hostile by default. On 6/15/17 1:47 PM, Ian Kaufman wrote: > Are you using NFSv4? Are all machines using the same idmap domain? > > Ian > > On Thu, Jun 15, 2017 at 11:18 AM, Andries Annema > > wrote: > > Hi ?zkan, > > The first thing that comes to mind is "no_root_squash" and, based > on your example setting with options like "anon=root", I assume > this option can be set as well on OmniOS with the "sharenfs" setting. > > Maybe these will help: > https://serverfault.com/questions/364613/centos-6-ldap-nfs-file-ownership-is-stuck-on-nobody > > > http://www.linuxtopia.org/online_books/rhel6/rhel_6_storage_admin/rhel_6_storage_s2-nfs-security-files.html > > > > Disclaimer: I am not an expert on NFS! Far from it. The above > suggestion is based on some personal experience where I needed > that "no_root_squash" option (although that was with some Linux > distro's), and some Google-fu. With that said, I am not sure if it > adds a security threat or something. > > Anyway, my two cents. > > Regards, > Andries > > > On 2017-06-14 17:44, ?zkan G?ksu wrote: >> Hello. >> >> I have a nfs share and zfs settings like= "sharenfs anon=root,rw=* " >> When i mount it from Centos, owner changes as nobody. (yes im >> root on Centos) >> But in omnios or ubuntu i see as root when i mount it. >> >> What is the cause of this problem? >> >> >> >> >> _______________________________________________ >> 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 > > > > > > -- > Ian Kaufman > Research Systems Administrator > UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu > > > _______________________________________________ > 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 paladinemishakal at gmail.com Mon Jun 19 08:51:02 2017 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Mon, 19 Jun 2017 16:51:02 +0800 Subject: [OmniOS-discuss] Intel C612 chipset Message-ID: Hi All, I am planning to get this SuperMicro server SSG-2028R-E1CR24L and I am wondering if there is any problem associated with Intel C612 chipset and Intel X540 Dual Port 10GBase-T? Planning to use Seagate ST1200MM00 10KRPM 512E 2.5" SAS HDD. Any comment? Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at kebe.com Mon Jun 19 12:50:40 2017 From: danmcd at kebe.com (Dan McDonald) Date: Mon, 19 Jun 2017 08:50:40 -0400 Subject: [OmniOS-discuss] Intel C612 chipset In-Reply-To: References: Message-ID: <2D5D0ACA-A59C-4FF1-B269-7C27C03EF86F@kebe.com> > On Jun 19, 2017, at 4:51 AM, Lawrence Giam wrote: > > Hi All, > > I am planning to get this SuperMicro server SSG-2028R-E1CR24L and I am wondering if there is any problem associated with Intel C612 chipset and Intel X540 Dual Port 10GBase-T? > > Planning to use Seagate ST1200MM00 10KRPM 512E 2.5" SAS HDD. > > Any comment? Looks like a good pick. It has the 3008 set to the IT firmware already (check the illumos mailing list for what the best revision of said FW should be), and the X540 is also been supported. Dan From oliver.weinmann at telespazio-vega.de Thu Jun 22 06:45:14 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 22 Jun 2017 06:45:14 +0000 Subject: [OmniOS-discuss] Loosing NFS shares Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> Hi, we are using OmniOS for a few months now and have big trouble with stability. We mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS datastores and VMs stopped running. I noticed that even though zfs get sharenfs shows folders as shared they become inaccessible. Setting sharenfs to off and sharing again solves the issue. I have no clue where to start. I'm fairly new to OmniOS. Any help would be highly appreciated. Thanks and Best Regards, Oliver [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From tobi at oetiker.ch Thu Jun 22 07:11:29 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Thu, 22 Jun 2017 09:11:29 +0200 (CEST) Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> Message-ID: <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> Oliver, are you running rcapd ? we found that (at least of the box) this thing wrecks havoc to both nfs and iscsi sharing ... cheers tobi ----- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann wrote: > Hi, > we are using OmniOS for a few months now and have big trouble with stability. We > mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS > datastores and VMs stopped running. I noticed that even though zfs get sharenfs > shows folders as shared they become inaccessible. Setting sharenfs to off and > sharing again solves the issue. I have no clue where to start. I?m fairly new > to OmniOS. > Any help would be highly appreciated. > Thanks and Best Regards, > Oliver > Oliver Weinmann > Senior Unix VMWare, Storage Engineer > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > [ mailto:oliver.weinmann at telespazio-vega.de | oliver.weinmann at telespazio-vega.de > ] > [ http://www.telespazio-vega.de/ | http://www.telespazio-vega.de ] > Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From oliver.weinmann at telespazio-vega.de Thu Jun 22 07:13:27 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 22 Jun 2017 07:13:27 +0000 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> Hi, Don?t think so: svcs -vx rcapd shows nothing. [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Tobias Oetiker [mailto:tobi at oetiker.ch] Sent: Donnerstag, 22. Juni 2017 09:11 To: Oliver Weinmann Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Loosing NFS shares Oliver, are you running rcapd ? we found that (at least of the box) this thing wrecks havoc to both nfs and iscsi sharing ... cheers tobi ----- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann > wrote: Hi, we are using OmniOS for a few months now and have big trouble with stability. We mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS datastores and VMs stopped running. I noticed that even though zfs get sharenfs shows folders as shared they become inaccessible. Setting sharenfs to off and sharing again solves the issue. I have no clue where to start. I?m fairly new to OmniOS. Any help would be highly appreciated. Thanks and Best Regards, Oliver [cid:image001.png at 01D2EB37.CE643CD0] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7535 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From stephan.budach at jvm.de Thu Jun 22 07:19:51 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 22 Jun 2017 09:19:51 +0200 (CEST) Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> Message-ID: <558219886.865.1498116003981.JavaMail.stephan.budach@stephanbudach.local> Hi Oliver, ----- Urspr?ngliche Mail ----- > Von: "Oliver Weinmann" > An: omnios-discuss at lists.omniti.com > Gesendet: Donnerstag, 22. Juni 2017 08:45:14 > Betreff: [OmniOS-discuss] Loosing NFS shares > Hi, > we are using OmniOS for a few months now and have big trouble with > stability. We mainly use it for VMware NFS datastores. The last 3 > nights we lost all NFS datastores and VMs stopped running. I noticed > that even though zfs get sharenfs shows folders as shared they > become inaccessible. Setting sharenfs to off and sharing again > solves the issue. I have no clue where to start. I?m fairly new to > OmniOS. > Any help would be highly appreciated. > Thanks and Best Regards, > Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From stephan.budach at jvm.de Thu Jun 22 07:30:28 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 22 Jun 2017 09:30:28 +0200 (CEST) Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> Message-ID: <1052097059.4254122.1498116628307.JavaMail.zimbra@jvm.de> Hi Oliver, Von: "Oliver Weinmann" An: "Tobias Oetiker" CC: "omnios-discuss" Gesendet: Donnerstag, 22. Juni 2017 09:13:27 Betreff: Re: [OmniOS-discuss] Loosing NFS shares Hi, Don?t think so: svcs -vx rcapd shows nothing. Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 [ mailto:oliver.weinmann at telespazio-vega.de | oliver.weinmann at telespazio-vega.de ] [ http://www.telespazio-vega.de/ | http://www.telespazio-vega.de ] Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Tobias Oetiker [mailto:tobi at oetiker.ch] Sent: Donnerstag, 22. Juni 2017 09:11 To: Oliver Weinmann Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Loosing NFS shares Oliver, are you running rcapd ? we found that (at least of the box) this thing wrecks havoc to both nfs and iscsi sharing ... cheers tobi ----- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann < [ mailto:oliver.weinmann at telespazio-vega.de | oliver.weinmann at telespazio-vega.de ] > wrote: Hi, we are using OmniOS for a few months now and have big trouble with stability. We mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS datastores and VMs stopped running. I noticed that even though zfs get sharenfs shows folders as shared they become inaccessible. Setting sharenfs to off and sharing again solves the issue. I have no clue where to start. I?m fairly new to OmniOS. Any help would be highly appreciated. Thanks and Best Regards, Oliver Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 [ mailto:oliver.weinmann at telespazio-vega.de | oliver.weinmann at telespazio-vega.de ] [ http://www.telespazio-vega.de/ | http://www.telespazio-vega.de ] Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller What is the output from fmdump / fmdump -v? Also, it would be good to have a better understanding of your setup. We have been using NFS shares from OmniOS since r006 on OVM and also VMWare and at least the NFS part has always been very solid for us. So, how did you setup your storage and how many NFS clients do you have? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7535 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From oliver.weinmann at telespazio-vega.de Thu Jun 22 07:36:53 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 22 Jun 2017 07:36:53 +0000 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <1052097059.4254122.1498116628307.JavaMail.zimbra@jvm.de> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> <1052097059.4254122.1498116628307.JavaMail.zimbra@jvm.de> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BC8E56@GEDAEVW01.a.space.corp> Hi Stephan, It seems that the problem is not VMware related as we also have non VMware NFS shares that are disappearing too. We have joined the omnios to our win2k8 r2 domain. Previously we also setup ldap client but we had several problems with it as you can see from the fmdump and so we decieded to stop using ldap client. What is the output from fmdump / fmdump -v? >> TIME UUID SUNW-MSG-ID EVENT Jan 17 18:38:07.0648 a82e5b3d-217f-ecc6-e2d0-81f52d21798b SMF-8000-YX Diagnosed Jan 17 18:51:46.6008 a82e5b3d-217f-ecc6-e2d0-81f52d21798b FMD-8000-4M Repaired Jan 17 18:51:46.6017 a82e5b3d-217f-ecc6-e2d0-81f52d21798b FMD-8000-6U Resolved Jan 17 19:07:25.0795 4a1ea04f-3b1f-6d80-ae6c-eafb51341197 SMF-8000-YX Diagnosed Jan 17 12:44:18.0553 4a1ea04f-3b1f-6d80-ae6c-eafb51341197 FMD-8000-4M Repaired Jan 17 12:44:18.0563 4a1ea04f-3b1f-6d80-ae6c-eafb51341197 FMD-8000-6U Resolved Jan 19 10:21:58.4380 b55dcffb-d60f-c9a3-e94e-b1c753998ab0 SMF-8000-YX Diagnosed Jan 19 10:21:59.1993 b55dcffb-d60f-c9a3-e94e-b1c753998ab0 FMD-8000-4M Repaired Jan 19 10:21:59.2000 b55dcffb-d60f-c9a3-e94e-b1c753998ab0 FMD-8000-6U Resolved Jan 19 17:09:38.1130 eeb1742a-c5f5-6e28-bf26-8cdf08924432 SMF-8000-YX Diagnosed Jan 19 17:10:31.6057 eeb1742a-c5f5-6e28-bf26-8cdf08924432 FMD-8000-4M Repaired Jan 19 17:10:31.6071 eeb1742a-c5f5-6e28-bf26-8cdf08924432 FMD-8000-6U Resolved May 23 12:47:27.8159 685b232f-638c-cacf-cee9-98430dbdb97c SMF-8000-YX Diagnosed May 23 12:47:33.2961 685b232f-638c-cacf-cee9-98430dbdb97c FMD-8000-4M Repaired May 23 12:47:33.2974 685b232f-638c-cacf-cee9-98430dbdb97c FMD-8000-6U Resolved May 23 12:53:46.2183 7bb2784a-9a50-6fd8-f25a-8043060a883a SMF-8000-YX Diagnosed May 23 12:53:46.2245 7bb2784a-9a50-6fd8-f25a-8043060a883a FMD-8000-4M Repaired May 23 12:53:46.2252 7bb2784a-9a50-6fd8-f25a-8043060a883a FMD-8000-6U Resolved May 23 12:56:14.3915 d2294c05-5f95-e8dd-ea58-9bb31c11d519 SMF-8000-YX Diagnosed May 23 12:57:21.8437 d2294c05-5f95-e8dd-ea58-9bb31c11d519 FMD-8000-4M Repaired May 23 12:57:21.8452 d2294c05-5f95-e8dd-ea58-9bb31c11d519 FMD-8000-6U Resolved May 23 12:59:22.2249 7d95a15a-ce83-4fd6-976c-c67fe15cd9ca SMF-8000-YX Diagnosed May 23 12:59:22.2266 7d95a15a-ce83-4fd6-976c-c67fe15cd9ca FMD-8000-4M Repaired May 23 12:59:22.2273 7d95a15a-ce83-4fd6-976c-c67fe15cd9ca FMD-8000-6U Resolved May 23 16:58:42.2836 af1d96ae-489e-46cb-b4da-b5adf5780018 SMF-8000-YX Diagnosed May 23 17:01:53.4846 af1d96ae-489e-46cb-b4da-b5adf5780018 FMD-8000-4M Repaired May 23 17:01:53.4857 af1d96ae-489e-46cb-b4da-b5adf5780018 FMD-8000-6U Resolved May 24 10:04:18.5145 34f126dd-fd71-4de2-cafd-dd084438d63a SMF-8000-YX Diagnosed May 24 12:15:47.8823 34f126dd-fd71-4de2-cafd-dd084438d63a FMD-8000-4M Repaired May 24 12:15:47.8838 34f126dd-fd71-4de2-cafd-dd084438d63a FMD-8000-6U Resolved root at omnios01:/hgst4u60/ReferenceAC/AGDEMO# fmdump -v TIME UUID SUNW-MSG-ID EVENT Jan 17 18:38:07.0648 a82e5b3d-217f-ecc6-e2d0-81f52d21798b SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ntp:default Affects: svc:///network/ntp:default FRU: - Location: - Jan 17 18:51:46.6008 a82e5b3d-217f-ecc6-e2d0-81f52d21798b FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ntp:default Affects: svc:///network/ntp:default FRU: - Location: - Jan 17 18:51:46.6017 a82e5b3d-217f-ecc6-e2d0-81f52d21798b FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ntp:default Affects: svc:///network/ntp:default FRU: - Location: - Jan 17 19:07:25.0795 4a1ea04f-3b1f-6d80-ae6c-eafb51341197 SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ntp:default Affects: svc:///network/ntp:default FRU: - Location: - Jan 17 12:44:18.0553 4a1ea04f-3b1f-6d80-ae6c-eafb51341197 FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ntp:default Affects: svc:///network/ntp:default FRU: - Location: - Jan 17 12:44:18.0563 4a1ea04f-3b1f-6d80-ae6c-eafb51341197 FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ntp:default Affects: svc:///network/ntp:default FRU: - Location: - Jan 19 10:21:58.4380 b55dcffb-d60f-c9a3-e94e-b1c753998ab0 SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - Jan 19 10:21:59.1993 b55dcffb-d60f-c9a3-e94e-b1c753998ab0 FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - Jan 19 10:21:59.2000 b55dcffb-d60f-c9a3-e94e-b1c753998ab0 FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - Jan 19 17:09:38.1130 eeb1742a-c5f5-6e28-bf26-8cdf08924432 SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - Jan 19 17:10:31.6057 eeb1742a-c5f5-6e28-bf26-8cdf08924432 FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - Jan 19 17:10:31.6071 eeb1742a-c5f5-6e28-bf26-8cdf08924432 FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:47:27.8159 685b232f-638c-cacf-cee9-98430dbdb97c SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:47:33.2961 685b232f-638c-cacf-cee9-98430dbdb97c FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:47:33.2974 685b232f-638c-cacf-cee9-98430dbdb97c FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:53:46.2183 7bb2784a-9a50-6fd8-f25a-8043060a883a SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:53:46.2245 7bb2784a-9a50-6fd8-f25a-8043060a883a FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:53:46.2252 7bb2784a-9a50-6fd8-f25a-8043060a883a FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:56:14.3915 d2294c05-5f95-e8dd-ea58-9bb31c11d519 SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:57:21.8437 d2294c05-5f95-e8dd-ea58-9bb31c11d519 FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:57:21.8452 d2294c05-5f95-e8dd-ea58-9bb31c11d519 FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:59:22.2249 7d95a15a-ce83-4fd6-976c-c67fe15cd9ca SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:59:22.2266 7d95a15a-ce83-4fd6-976c-c67fe15cd9ca FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 12:59:22.2273 7d95a15a-ce83-4fd6-976c-c67fe15cd9ca FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 16:58:42.2836 af1d96ae-489e-46cb-b4da-b5adf5780018 SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 17:01:53.4846 af1d96ae-489e-46cb-b4da-b5adf5780018 FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 23 17:01:53.4857 af1d96ae-489e-46cb-b4da-b5adf5780018 FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 24 10:04:18.5145 34f126dd-fd71-4de2-cafd-dd084438d63a SMF-8000-YX Diagnosed 100% defect.sunos.smf.svc.maintenance Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 24 12:15:47.8823 34f126dd-fd71-4de2-cafd-dd084438d63a FMD-8000-4M Repaired 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - May 24 12:15:47.8838 34f126dd-fd71-4de2-cafd-dd084438d63a FMD-8000-6U Resolved 100% defect.sunos.smf.svc.maintenance Repair Attempted Problem in: svc:///network/ldap/client:default Affects: svc:///network/ldap/client:default FRU: - Location: - I do see a lot errors from mountd in /var/adm/messages: e.g. Jun 21 15:01:22 omnios01 mountd[766]: [ID 801587 daemon.notice] /hgst4u60/ReferenceAC/AGDEMO/Software/Unix: No such file or directory While these exist and I can access them just fine. root at omnios01:/hgst4u60# zfs list hgst4u60/ReferenceAC/AGDEMO NAME USED AVAIL REFER MOUNTPOINT hgst4u60/ReferenceAC/AGDEMO 256K 5.00G 256K /hgst4u60/ReferenceAC/AGDEMO root at omnios01:/hgst4u60/ReferenceAC/AGDEMO# df -h . Filesystem Size Used Available Capacity Mounted on hgst4u60/ReferenceAC/AGDEMO 5.0G 256K 5.0G 1% /hgst4u60/ReferenceAC/AGDEMO Also there is an error for smbd shown on the console very often: Jun 21 16:26:46 omnios01 smbd[628]: [ID 160719 auth.alert] adt_set_user: Invalid argument From: Stephan Budach [mailto:stephan.budach at jvm.de] Sent: Donnerstag, 22. Juni 2017 09:30 To: Oliver Weinmann Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Loosing NFS shares Hi Oliver, _____ Von: "Oliver Weinmann" > An: "Tobias Oetiker" > CC: "omnios-discuss" > Gesendet: Donnerstag, 22. Juni 2017 09:13:27 Betreff: Re: [OmniOS-discuss] Loosing NFS shares Hi, Don?t think so: svcs -vx rcapd shows nothing. Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Tobias Oetiker [mailto:tobi at oetiker.ch] Sent: Donnerstag, 22. Juni 2017 09:11 To: Oliver Weinmann > Cc: omnios-discuss > Subject: Re: [OmniOS-discuss] Loosing NFS shares Oliver, are you running rcapd ? we found that (at least of the box) this thing wrecks havoc to both nfs and iscsi sharing ... cheers tobi ----- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann > wrote: Hi, we are using OmniOS for a few months now and have big trouble with stability. We mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS datastores and VMs stopped running. I noticed that even though zfs get sharenfs shows folders as shared they become inaccessible. Setting sharenfs to off and sharing again solves the issue. I have no clue where to start. I?m fairly new to OmniOS. Any help would be highly appreciated. Thanks and Best Regards, Oliver Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller What is the output from fmdump / fmdump -v? Also, it would be good to have a better understanding of your setup. We have been using NFS shares from OmniOS since r006 on OVM and also VMWare and at least the NFS part has always been very solid for us. So, how did you setup your storage and how many NFS clients do you have? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7535 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4970 bytes Desc: not available URL: From oliver.weinmann at telespazio-vega.de Thu Jun 22 07:45:53 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 22 Jun 2017 07:45:53 +0000 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <1052097059.4254122.1498116628307.JavaMail.zimbra@jvm.de> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> <1052097059.4254122.1498116628307.JavaMail.zimbra@jvm.de> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BC8E70@GEDAEVW01.a.space.corp> One more thing I just noticed is that the system seems to be unable to mount directories: root at omnios01:/hgst4u60/ReferenceAC/AGDEMO# /usr/sbin/zfs mount -a cannot mount '/hgst4u60/ReferenceAC': directory is not empty cannot mount '/hgst4u60/ReferenceDF': directory is not empty cannot mount '/hgst4u60/ReferenceGI': directory is not empty cannot mount '/hgst4u60/ReferenceJL': directory is not empty cannot mount '/hgst4u60/ReferenceMO': directory is not empty cannot mount '/hgst4u60/ReferencePR': directory is not empty cannot mount '/hgst4u60/ReferenceSU': directory is not empty cannot mount '/hgst4u60/ReferenceVX': directory is not empty cannot mount '/hgst4u60/ReferenceYZ': directory is not empty Maybe this is where all problems are coming from? From: Stephan Budach [mailto:stephan.budach at jvm.de] Sent: Donnerstag, 22. Juni 2017 09:30 To: Oliver Weinmann Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Loosing NFS shares Hi Oliver, _____ Von: "Oliver Weinmann" < oliver.weinmann at telespazio-vega.de> An: "Tobias Oetiker" < tobi at oetiker.ch> CC: "omnios-discuss" < omnios-discuss at lists.omniti.com> Gesendet: Donnerstag, 22. Juni 2017 09:13:27 Betreff: Re: [OmniOS-discuss] Loosing NFS shares Hi, Don?t think so: svcs -vx rcapd shows nothing. Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Tobias Oetiker [mailto:tobi at oetiker.ch] Sent: Donnerstag, 22. Juni 2017 09:11 To: Oliver Weinmann > Cc: omnios-discuss > Subject: Re: [OmniOS-discuss] Loosing NFS shares Oliver, are you running rcapd ? we found that (at least of the box) this thing wrecks havoc to both nfs and iscsi sharing ... cheers tobi ----- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann < oliver.weinmann at telespazio-vega.de> wrote: Hi, we are using OmniOS for a few months now and have big trouble with stability. We mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS datastores and VMs stopped running. I noticed that even though zfs get sharenfs shows folders as shared they become inaccessible. Setting sharenfs to off and sharing again solves the issue. I have no clue where to start. I?m fairly new to OmniOS. Any help would be highly appreciated. Thanks and Best Regards, Oliver Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller What is the output from fmdump / fmdump -v? Also, it would be good to have a better understanding of your setup. We have been using NFS shares from OmniOS since r006 on OVM and also VMWare and at least the NFS part has always been very solid for us. So, how did you setup your storage and how many NFS clients do you have? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7535 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4970 bytes Desc: not available URL: From sriramnrn at gmail.com Thu Jun 22 08:25:32 2017 From: sriramnrn at gmail.com (Sriram Narayanan) Date: Thu, 22 Jun 2017 16:25:32 +0800 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BC8E70@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> <1052097059.4254122.1498116628307.JavaMail.zimbra@jvm.de> <767138E0D064A148B03FE8EC1E9325A20125BC8E70@GEDAEVW01.a.space.corp> Message-ID: On Thu, Jun 22, 2017 at 3:45 PM, Oliver Weinmann < oliver.weinmann at telespazio-vega.de> wrote: > One more thing I just noticed is that the system seems to be unable to > mount directories: > > > > root at omnios01:/hgst4u60/ReferenceAC/AGDEMO# /usr/sbin/zfs mount -a > > cannot mount '/hgst4u60/ReferenceAC': directory is not empty > > cannot mount '/hgst4u60/ReferenceDF': directory is not empty > > cannot mount '/hgst4u60/ReferenceGI': directory is not empty > > cannot mount '/hgst4u60/ReferenceJL': directory is not empty > > cannot mount '/hgst4u60/ReferenceMO': directory is not empty > > cannot mount '/hgst4u60/ReferencePR': directory is not empty > > cannot mount '/hgst4u60/ReferenceSU': directory is not empty > > cannot mount '/hgst4u60/ReferenceVX': directory is not empty > > cannot mount '/hgst4u60/ReferenceYZ': directory is not empty > > > > Maybe this is where all problems are coming from? > Please issue the zfs mount -a command from elsewhere rather than from within "/hgst4u60/ReferenceAC" It also seems that "" and the others may already have local files. If possible, then rename those Reference* directories and issue the zfs mount -a again. > > > *From:* Stephan Budach [mailto:stephan.budach at jvm.de] > *Sent:* Donnerstag, 22. Juni 2017 09:30 > *To:* Oliver Weinmann > *Cc:* omnios-discuss > *Subject:* Re: [OmniOS-discuss] Loosing NFS shares > > > > Hi Oliver, > > > ------------------------------ > > *Von: *"Oliver Weinmann" > *An: *"Tobias Oetiker" > *CC: *"omnios-discuss" > *Gesendet: *Donnerstag, 22. Juni 2017 09:13:27 > *Betreff: *Re: [OmniOS-discuss] Loosing NFS shares > > > > Hi, > > > > Don?t think so: > > > > svcs -vx rcapd > > > > shows nothing. > > > > > > [image: cid:image001.png at 01D2EB3B.A023E330] > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 <+49%206151%208257744> | Fax: +49 (0)6151 8257 > 799 <+49%206151%208257799> > oliver.weinmann at telespazio-vega.de > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > *From:* Tobias Oetiker [mailto:tobi at oetiker.ch ] > *Sent:* Donnerstag, 22. Juni 2017 09:11 > *To:* Oliver Weinmann > *Cc:* omnios-discuss > *Subject:* Re: [OmniOS-discuss] Loosing NFS shares > > > > Oliver, > > > > are you running rcapd ? we found that (at least of the box) this thing > wrecks havoc to both > > nfs and iscsi sharing ... > > > > cheers > > tobi > > > > ----- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann < > oliver.weinmann at telespazio-vega.de> wrote: > > Hi, > > > > we are using OmniOS for a few months now and have big trouble with > stability. We mainly use it for VMware NFS datastores. The last 3 nights we > lost all NFS datastores and VMs stopped running. I noticed that even though > zfs get sharenfs shows folders as shared they become inaccessible. Setting > sharenfs to off and sharing again solves the issue. I have no clue where to > start. I?m fairly new to OmniOS. > > > > Any help would be highly appreciated. > > > > Thanks and Best Regards, > > Oliver > > > > [image: cid:image001.png at 01D2EB3B.A023E330] > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 <+49%206151%208257744> | Fax: +49 (0)6151 8257 > 799 <+49%206151%208257799> > oliver.weinmann at telespazio-vega.de > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > > > What is the output from fmdump / fmdump -v? Also, it would be good to have > a better understanding of your setup. We have been using NFS shares from > OmniOS since r006 on OVM and also VMWare and at least the NFS part has > always been very solid for us. So, how did you setup your storage and how > many NFS clients do you have? > > > > Cheers, > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7535 bytes Desc: not available URL: From oliver.weinmann at telespazio-vega.de Thu Jun 22 08:51:07 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 22 Jun 2017 08:51:07 +0000 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> <1052097059.4254122.1498116628307.JavaMail.zimbra@jvm.de> <767138E0D064A148B03FE8EC1E9325A20125BC8E70@GEDAEVW01.a.space.corp> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BCAED5@GEDAEVW01.a.space.corp> Hi, Running the zfs mount ?a from / shows the same errors. I now ran the following commands to correct the mountpoints: Re-enable inheritance: zfs inherit -r mountpoint hgst4u60/ReferencePR Reset mountpoint on the root folder: zfs set mountpoint=/hgst4u60/ReferencePR hgst4u60/ReferencePR unmount all subfolders: for fs in `zfs mount | grep ReferencePR | awk '{print $2}'`; do zfs unmount $fs; done Check that all subfolders are unmounted: zfs mount | grep ReferencePR Check that all folders are empty, just to be sure!!!: du /hgst4u60/ReferencePR If they are empty remove the root folder: rm -rf /hgst4u60/ReferencePR Finally remount: zfs mount ?a This solves the mount issues but I wonder why this has happened? And hopefully this doesn?t happen again? [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Sriram Narayanan [mailto:sriramnrn at gmail.com] Sent: Donnerstag, 22. Juni 2017 10:26 To: Oliver Weinmann Cc: Stephan Budach ; omnios-discuss Subject: Re: [OmniOS-discuss] Loosing NFS shares On Thu, Jun 22, 2017 at 3:45 PM, Oliver Weinmann > wrote: One more thing I just noticed is that the system seems to be unable to mount directories: root at omnios01:/hgst4u60/ReferenceAC/AGDEMO# /usr/sbin/zfs mount -a cannot mount '/hgst4u60/ReferenceAC': directory is not empty cannot mount '/hgst4u60/ReferenceDF': directory is not empty cannot mount '/hgst4u60/ReferenceGI': directory is not empty cannot mount '/hgst4u60/ReferenceJL': directory is not empty cannot mount '/hgst4u60/ReferenceMO': directory is not empty cannot mount '/hgst4u60/ReferencePR': directory is not empty cannot mount '/hgst4u60/ReferenceSU': directory is not empty cannot mount '/hgst4u60/ReferenceVX': directory is not empty cannot mount '/hgst4u60/ReferenceYZ': directory is not empty Maybe this is where all problems are coming from? Please issue the zfs mount -a command from elsewhere rather than from within "/hgst4u60/ReferenceAC" It also seems that "" and the others may already have local files. If possible, then rename those Reference* directories and issue the zfs mount -a again. From: Stephan Budach [mailto:stephan.budach at jvm.de] Sent: Donnerstag, 22. Juni 2017 09:30 To: Oliver Weinmann > Cc: omnios-discuss > Subject: Re: [OmniOS-discuss] Loosing NFS shares Hi Oliver, ________________________________ Von: "Oliver Weinmann" > An: "Tobias Oetiker" > CC: "omnios-discuss" > Gesendet: Donnerstag, 22. Juni 2017 09:13:27 Betreff: Re: [OmniOS-discuss] Loosing NFS shares Hi, Don?t think so: svcs -vx rcapd shows nothing. [cid:image001.png at 01D2EB3B.A023E330] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Tobias Oetiker [mailto:tobi at oetiker.ch] Sent: Donnerstag, 22. Juni 2017 09:11 To: Oliver Weinmann > Cc: omnios-discuss > Subject: Re: [OmniOS-discuss] Loosing NFS shares Oliver, are you running rcapd ? we found that (at least of the box) this thing wrecks havoc to both nfs and iscsi sharing ... cheers tobi ----- On Jun 22, 2017, at 8:45 AM, Oliver Weinmann > wrote: Hi, we are using OmniOS for a few months now and have big trouble with stability. We mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS datastores and VMs stopped running. I noticed that even though zfs get sharenfs shows folders as shared they become inaccessible. Setting sharenfs to off and sharing again solves the issue. I have no clue where to start. I?m fairly new to OmniOS. Any help would be highly appreciated. Thanks and Best Regards, Oliver [cid:image001.png at 01D2EB3B.A023E330] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller What is the output from fmdump / fmdump -v? Also, it would be good to have a better understanding of your setup. We have been using NFS shares from OmniOS since r006 on OVM and also VMWare and at least the NFS part has always been very solid for us. So, how did you setup your storage and how many NFS clients do you have? Cheers, 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7535 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From danmcd at kebe.com Thu Jun 22 12:10:00 2017 From: danmcd at kebe.com (Dan McDonald) Date: Thu, 22 Jun 2017 08:10:00 -0400 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> Message-ID: <8C407288-25ED-4A55-A34C-2F328932733F@kebe.com> > On Jun 22, 2017, at 3:13 AM, Oliver Weinmann wrote: > > Hi, > > Don?t think so: > > svcs -vx rcapd > > shows nothing. You're not looking for the right thing. neuromancer(~)[0]% pgrep rcapd 340 neuromancer(~)[0]% svcs -a | grep cap online May_12 svc:/system/rcap:default neuromancer(~)[0]% svcs -xv rcap svc:/system/rcap:default (resource capping daemon) State: online since Fri May 12 02:12:40 2017 See: man -M /usr/share/man -s 1M rcapd See: man -M /usr/share/man -s 1M rcapstat See: man -M /usr/share/man -s 1M rcapadm See: /var/svc/log/system-rcap:default.log Impact: None. neuromancer(~)[0]% su troot Password: OmniOS 5.11 omnios-r151022-f9693432c2 May 2017 (0)# svcadm disable rcap (0)# Hope this helps, Dan From oliver.weinmann at telespazio-vega.de Thu Jun 22 12:14:55 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 22 Jun 2017 12:14:55 +0000 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <8C407288-25ED-4A55-A34C-2F328932733F@kebe.com> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> <8C407288-25ED-4A55-A34C-2F328932733F@kebe.com> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BCD000@GEDAEVW01.a.space.corp> Hi Dan, Thanks for pointing this out. No the service is not running: svcs -a | grep cap Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller-----Original Message----- From: Dan McDonald [mailto:danmcd at kebe.com] Sent: Donnerstag, 22. Juni 2017 14:10 To: Oliver Weinmann ; Dan McDonald Cc: Tobias Oetiker ; omnios-discuss Subject: Re: [OmniOS-discuss] Loosing NFS shares > On Jun 22, 2017, at 3:13 AM, Oliver Weinmann wrote: > > Hi, > > Don?t think so: > > svcs -vx rcapd > > shows nothing. You're not looking for the right thing. neuromancer(~)[0]% pgrep rcapd 340 neuromancer(~)[0]% svcs -a | grep cap online May_12 svc:/system/rcap:default neuromancer(~)[0]% svcs -xv rcap svc:/system/rcap:default (resource capping daemon) State: online since Fri May 12 02:12:40 2017 See: man -M /usr/share/man -s 1M rcapd See: man -M /usr/share/man -s 1M rcapstat See: man -M /usr/share/man -s 1M rcapadm See: /var/svc/log/system-rcap:default.log Impact: None. neuromancer(~)[0]% su troot Password: OmniOS 5.11 omnios-r151022-f9693432c2 May 2017 (0)# svcadm disable rcap (0)# Hope this helps, Dan From lkateley at kateley.com Thu Jun 22 15:43:57 2017 From: lkateley at kateley.com (Linda Kateley) Date: Thu, 22 Jun 2017 10:43:57 -0500 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BCD000@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <1401729883.280838.1498115489232.JavaMail.zimbra@oetiker.ch> <767138E0D064A148B03FE8EC1E9325A20125BC8E20@GEDAEVW01.a.space.corp> <8C407288-25ED-4A55-A34C-2F328932733F@kebe.com> <767138E0D064A148B03FE8EC1E9325A20125BCD000@GEDAEVW01.a.space.corp> Message-ID: <45498e2f-cd23-0346-bcf0-cbe0a735e208@kateley.com> Oliver, I my like 20 plus years of running solaris/omni, never have seen the nfs daemon die. Especially since the service restart framework came in .. Most likely it is was a network connection issue. You can check logs for network up/downs to see if there was a connection issue. Used to never have issue with switches, now lately(last couple years) have seen a ton of them.. especially inside the virtual networking inside of vmware. To really understand cause though, thorough analysis would need to be done. lk On 6/22/17 7:14 AM, Oliver Weinmann wrote: > Hi Dan, > > Thanks for pointing this out. No the service is not running: > > svcs -a | grep cap > > > > Oliver Weinmann > Senior Unix VMWare, Storage Engineer > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > http://www.telespazio-vega.de > Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller-----Original Message----- > From: Dan McDonald [mailto:danmcd at kebe.com] > Sent: Donnerstag, 22. Juni 2017 14:10 > To: Oliver Weinmann ; Dan McDonald > Cc: Tobias Oetiker ; omnios-discuss > Subject: Re: [OmniOS-discuss] Loosing NFS shares > > >> On Jun 22, 2017, at 3:13 AM, Oliver Weinmann wrote: >> >> Hi, >> >> Don?t think so: >> >> svcs -vx rcapd >> >> shows nothing. > You're not looking for the right thing. > > neuromancer(~)[0]% pgrep rcapd > 340 > neuromancer(~)[0]% svcs -a | grep cap > online May_12 svc:/system/rcap:default > neuromancer(~)[0]% svcs -xv rcap > svc:/system/rcap:default (resource capping daemon) > State: online since Fri May 12 02:12:40 2017 > See: man -M /usr/share/man -s 1M rcapd > See: man -M /usr/share/man -s 1M rcapstat > See: man -M /usr/share/man -s 1M rcapadm > See: /var/svc/log/system-rcap:default.log > Impact: None. > neuromancer(~)[0]% su troot > Password: > OmniOS 5.11 omnios-r151022-f9693432c2 May 2017 > (0)# svcadm disable rcap > (0)# > > > Hope this helps, > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From chip at innovates.com Thu Jun 22 15:54:25 2017 From: chip at innovates.com (Schweiss, Chip) Date: Thu, 22 Jun 2017 10:54:25 -0500 Subject: [OmniOS-discuss] scsi command timeouts Message-ID: When ever a disk goes south, several disk related takes become painfully slow. Boot up times can jump into the hours to complete the disk scans. The logs slowly get these type messages: genunix: WARNING /pci at 0,0/pci8086,340c at 5/pci15d9,400 at 0 (mpt_sas0): Timeout of 60 seconds expired with 1 commands on target 16 lun 0 I thought this /etc/system setting would reduce the timeout to 5 seconds: set sd:sd_io_time = 5 But this doesn't seem to change anything. Is there anyway to make this a more reasonable timeout, besides pulling the disk that's causing it? Just locating the defective disk is also painfully slow because of this problem. -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Thu Jun 22 16:05:43 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 22 Jun 2017 18:05:43 +0200 Subject: [OmniOS-discuss] scsi command timeouts In-Reply-To: References: Message-ID: <20170622180543.7ccd85e3@sleipner.datanom.net> On Thu, 22 Jun 2017 10:54:25 -0500 "Schweiss, Chip" wrote: > I thought this /etc/system setting would reduce the timeout to 5 seconds: > set sd:sd_io_time = 5 > I think it expects a hex value so try 0x5 instead. -- 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: Look, we play the Star Spangled Banner before every game. You want us to pay income taxes, too? -- Bill Veeck, Chicago White Sox -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From chip at innovates.com Thu Jun 22 18:48:55 2017 From: chip at innovates.com (Schweiss, Chip) Date: Thu, 22 Jun 2017 13:48:55 -0500 Subject: [OmniOS-discuss] scsi command timeouts In-Reply-To: <20170622180543.7ccd85e3@sleipner.datanom.net> References: <20170622180543.7ccd85e3@sleipner.datanom.net> Message-ID: On Thu, Jun 22, 2017 at 11:05 AM, Michael Rasmussen wrote: > > > I thought this /etc/system setting would reduce the timeout to 5 seconds: > > set sd:sd_io_time = 5 > > > I think it expects a hex value so try 0x5 instead. > > Unfortunately, no, I've tried that too. -Chip > -- > 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: > Look, we play the Star Spangled Banner before every game. You want us > to pay income taxes, too? > -- Bill Veeck, Chicago White Sox > > _______________________________________________ > 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 daleg at omniti.com Thu Jun 22 20:12:07 2017 From: daleg at omniti.com (Dale Ghent) Date: Thu, 22 Jun 2017 16:12:07 -0400 Subject: [OmniOS-discuss] scsi command timeouts In-Reply-To: References: Message-ID: <0BA43604-1901-4B3C-ACE4-39FA476CB7C8@omniti.com> Have you able to and have tried offlining it in the zpool? zpool offline thepool I'm assuming the pool has some redundancy which would allow for this. /dale > On Jun 22, 2017, at 11:54 AM, Schweiss, Chip wrote: > > When ever a disk goes south, several disk related takes become painfully slow. Boot up times can jump into the hours to complete the disk scans. > > The logs slowly get these type messages: > > genunix: WARNING /pci at 0,0/pci8086,340c at 5/pci15d9,400 at 0 (mpt_sas0): > Timeout of 60 seconds expired with 1 commands on target 16 lun 0 > > I thought this /etc/system setting would reduce the timeout to 5 seconds: > set sd:sd_io_time = 5 > > But this doesn't seem to change anything. > > Is there anyway to make this a more reasonable timeout, besides pulling the disk that's causing it? Just locating the defective disk is also painfully slow because of this problem. > > -Chip > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From chip at innovates.com Thu Jun 22 20:41:29 2017 From: chip at innovates.com (Schweiss, Chip) Date: Thu, 22 Jun 2017 15:41:29 -0500 Subject: [OmniOS-discuss] scsi command timeouts In-Reply-To: <0BA43604-1901-4B3C-ACE4-39FA476CB7C8@omniti.com> References: <0BA43604-1901-4B3C-ACE4-39FA476CB7C8@omniti.com> Message-ID: I'm talking about an offline pool. I started this thread after rebooting a server that is part of an HA pair. The other server has the pools online. It's been over 4 hours now and it still hasn't completed its disk scan. Every tool I have that helps me locate disks, suffers from the same insane command timeout to happen many times before moving on. Operations that typically take seconds blow up to hours really fast because of a few dead disks. -Chip On Thu, Jun 22, 2017 at 3:12 PM, Dale Ghent wrote: > > Have you able to and have tried offlining it in the zpool? > > zpool offline thepool > > I'm assuming the pool has some redundancy which would allow for this. > > /dale > > > On Jun 22, 2017, at 11:54 AM, Schweiss, Chip wrote: > > > > When ever a disk goes south, several disk related takes become painfully > slow. Boot up times can jump into the hours to complete the disk scans. > > > > The logs slowly get these type messages: > > > > genunix: WARNING /pci at 0,0/pci8086,340c at 5/pci15d9,400 at 0 (mpt_sas0): > > Timeout of 60 seconds expired with 1 commands on target 16 lun 0 > > > > I thought this /etc/system setting would reduce the timeout to 5 seconds: > > set sd:sd_io_time = 5 > > > > But this doesn't seem to change anything. > > > > Is there anyway to make this a more reasonable timeout, besides pulling > the disk that's causing it? Just locating the defective disk is also > painfully slow because of this problem. > > > > -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 jeffry.molanus at gmail.com Thu Jun 22 20:55:14 2017 From: jeffry.molanus at gmail.com (Jeffry Molanus) Date: Thu, 22 Jun 2017 22:55:14 +0200 Subject: [OmniOS-discuss] scsi command timeouts In-Reply-To: <0BA43604-1901-4B3C-ACE4-39FA476CB7C8@omniti.com> References: <0BA43604-1901-4B3C-ACE4-39FA476CB7C8@omniti.com> Message-ID: Hi, Certain commands (in particular during attach) are send by mptsas itself, these have a timeout set in the driver and are not issued by SD hence these commands are not affected by changing those values. See for example, mptsas_access_config_page() - Jeffry On Thu, Jun 22, 2017 at 10:12 PM, Dale Ghent wrote: > > Have you able to and have tried offlining it in the zpool? > > zpool offline thepool > > I'm assuming the pool has some redundancy which would allow for this. > > /dale > > > On Jun 22, 2017, at 11:54 AM, Schweiss, Chip wrote: > > > > When ever a disk goes south, several disk related takes become painfully > slow. Boot up times can jump into the hours to complete the disk scans. > > > > The logs slowly get these type messages: > > > > genunix: WARNING /pci at 0,0/pci8086,340c at 5/pci15d9,400 at 0 (mpt_sas0): > > Timeout of 60 seconds expired with 1 commands on target 16 lun 0 > > > > I thought this /etc/system setting would reduce the timeout to 5 seconds: > > set sd:sd_io_time = 5 > > > > But this doesn't seem to change anything. > > > > Is there anyway to make this a more reasonable timeout, besides pulling > the disk that's causing it? Just locating the defective disk is also > painfully slow because of this problem. > > > > -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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Thu Jun 22 22:07:50 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Thu, 22 Jun 2017 17:07:50 -0500 (CDT) Subject: [OmniOS-discuss] scsi command timeouts In-Reply-To: References: <0BA43604-1901-4B3C-ACE4-39FA476CB7C8@omniti.com> Message-ID: On Thu, 22 Jun 2017, Schweiss, Chip wrote: > I'm talking about an offline pool. I started this thread after rebooting > a server that is part of an HA pair. The other server has the pools > online. It's been over 4 hours now and it still hasn't completed its disk > scan. > > Every tool I have that helps me locate disks, suffers from the same insane > command timeout to happen many times before moving on. Operations that > typically take seconds blow up to hours really fast because of a few dead > disks. You forgot to describe your storage topology and the type of drives (SAS/SATA) involved. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From mtalbott at lji.org Thu Jun 22 22:22:11 2017 From: mtalbott at lji.org (Michael Talbott) Date: Thu, 22 Jun 2017 15:22:11 -0700 Subject: [OmniOS-discuss] scsi command timeouts In-Reply-To: References: <0BA43604-1901-4B3C-ACE4-39FA476CB7C8@omniti.com> Message-ID: A couple things that I've discovered over time that might help: Don't ever use the root user for zpool queries such as "zpool status". If you have a really bad failing disk a zpool status command can take forever to complete when ran as root. A "su nobody -c 'zpool status'" will return results almost instantly. So if your device discovery script(s) use zpool commands, that might be a choking point. # make sure to prevent scsi bus resets (in /kernel/drv/sd.conf) especially in an HA environment allow-bus-device-reset=0; Also, depending on the disk model, I've found that some of them wreak havoc on the SAS topology itself when they start to fail. Some just handle errors really badly and can flood the SAS channel. If you have a SAS switch in between, you might be able to get an idea of which device is causing the grief from there based on the counts. In my case I have had horrible experiences with the WD WD4001FYYG. That model of drive has caused me an insane amount of headache. The disk scan on boot literally takes 13 seconds per-disk (when the disks are perfectly good and much much longer when one is dying). If I replace them with another make/model drive, the disk scan is done in a fraction of a second. Also, booting the same machine into any linux os the scan completes in a fraction of a second. Must be something about that model's firmware that doesn't play nicely with Illumos's driver. Anyway, that's a story for another time ;) I've reduced the drive scan time at boot down to 5 seconds per disk instead of the 13 seconds per disk for that horrible accursed drive by adding this to /kernel/drv/sd.conf sd-config-list= "WD WD4001FYYG","power-condition:false"; Followed by this command to commit it: update_drv -vf sd Hope this helps. Michael > On Jun 22, 2017, at 1:41 PM, Schweiss, Chip wrote: > > I'm talking about an offline pool. I started this thread after rebooting a server that is part of an HA pair. The other server has the pools online. It's been over 4 hours now and it still hasn't completed its disk scan. > > Every tool I have that helps me locate disks, suffers from the same insane command timeout to happen many times before moving on. Operations that typically take seconds blow up to hours really fast because of a few dead disks. > > -Chip > > > > On Thu, Jun 22, 2017 at 3:12 PM, Dale Ghent > wrote: > > Have you able to and have tried offlining it in the zpool? > > zpool offline thepool > > I'm assuming the pool has some redundancy which would allow for this. > > /dale > > > On Jun 22, 2017, at 11:54 AM, Schweiss, Chip > wrote: > > > > When ever a disk goes south, several disk related takes become painfully slow. Boot up times can jump into the hours to complete the disk scans. > > > > The logs slowly get these type messages: > > > > genunix: WARNING /pci at 0,0/pci8086,340c at 5/pci15d9,400 at 0 (mpt_sas0): > > Timeout of 60 seconds expired with 1 commands on target 16 lun 0 > > > > I thought this /etc/system setting would reduce the timeout to 5 seconds: > > set sd:sd_io_time = 5 > > > > But this doesn't seem to change anything. > > > > Is there anyway to make this a more reasonable timeout, besides pulling the disk that's causing it? Just locating the defective disk is also painfully slow because of this problem. > > > > -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.weinmann at telespazio-vega.de Fri Jun 23 06:59:42 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Fri, 23 Jun 2017 06:59:42 +0000 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BD4619@GEDAEVW01.a.space.corp> Hi, We have a hyperconverged setup. ESXi 6.0 -> OmniOS VM -> Storage Passthrough. The 10GB Nics are in configured in Active / Standby. For NFS I use a dedicated /24 VLAN. I wonder if ZFS replication or snapshotting could be the reason for the problems we are seeing. The system fails at night time. We have several auto-sync jobs from a Nexenta system to this system. I have now disabled these jobs. I just wonder where logs etc. I can find any information on what is going on on the system when it fails. The symtoms are always the same. The vmware nfsshare disappear. So I just reshare them (nfs set nfsshare=?. /hgst4u60/vmware-ds-1. Then the root ZFS folders of all local drives that I think have snapshots enabled are unmounted. So I have to unmount them all hard and remount them. Also the root ZFS folders from replicated ZFS folders are unmounted. This is why I assume that there is a link between the problems and auto-sync or snapshotting. [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Lawrence Giam [mailto:paladinemishakal at gmail.com] Sent: Freitag, 23. Juni 2017 05:00 To: Oliver Weinmann Subject: Re: [OmniOS-discuss] Loosing NFS shares Hi Oliver, What is your network setup in relationship to NFS file server and VM Host? Is your backdone using 10Gbe network and are they setup with redundancy (eg. MLAG)? Regards. On Thu, Jun 22, 2017 at 2:45 PM, Oliver Weinmann > wrote: Hi, we are using OmniOS for a few months now and have big trouble with stability. We mainly use it for VMware NFS datastores. The last 3 nights we lost all NFS datastores and VMs stopped running. I noticed that even though zfs get sharenfs shows folders as shared they become inaccessible. Setting sharenfs to off and sharing again solves the issue. I have no clue where to start. I?m fairly new to OmniOS. Any help would be highly appreciated. Thanks and Best Regards, Oliver [cid:image001.png at 01D2EBFF.0D6B4F50] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller _______________________________________________ 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: image001.png Type: image/png Size: 7535 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From alka at hfg-gmuend.de Fri Jun 23 07:27:43 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 23 Jun 2017 09:27:43 +0200 Subject: [OmniOS-discuss] Loosing NFS shares In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BD4619@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BC6DD9@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD4619@GEDAEVW01.a.space.corp> Message-ID: <49ea1882-f7d0-416f-f1e5-df62dc1d926d@hfg-gmuend.de> With ESXi 6.0 I have had NFS problems as well. You should use at least 6.0U2(or 6.5.0d with the 6.5 line) Another problem may be timeouts. ZFS will wait longer for a disk than ESXi for NFS. What you can do is reducing disk timeout time in /etc/system with set sd:sd_io_time=0xF (=15s, default is 60s). Check system-logs for disk related problems (/var/adm/messages). You should also use vmxnet3s for OmniOS with increased buffer settings for vmxnet3, tcp and NFS for 10G networking.Snaps and replication itself are uncritical as long as you do not have disk or network problems. Ex MTU 9000 can give problems. Enough RAM may be another item. You should give 8GB or more to OmniOS. Gea napp-it Am 23.06.2017 um 08:59 schrieb Oliver Weinmann: > > Hi, > > We have a hyperconverged setup. > > ESXi 6.0 -> OmniOS VM -> Storage Passthrough. The 10GB Nics are in > configured in Active / Standby. For NFS I use a dedicated /24 VLAN. > > I wonder if ZFS replication or snapshotting could be the reason for > the problems we are seeing. The system fails at night time. We have > several auto-sync jobs from a Nexenta system to this system. I have > now disabled these jobs. I just wonder where logs etc. I can find any > information on what is going on on the system when it fails. > > The symtoms are always the same. The vmware nfsshare disappear. So I > just reshare them (nfs set nfsshare=?. /hgst4u60/vmware-ds-1. Then the > root ZFS folders of all local drives that I think have snapshots > enabled are unmounted. So I have to unmount them all hard and remount > them. Also the root ZFS folders from replicated ZFS folders are > unmounted. This is why I assume that there is a link between the > problems and auto-sync or snapshotting. > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > *From:*Lawrence Giam [mailto:paladinemishakal at gmail.com] > *Sent:* Freitag, 23. Juni 2017 05:00 > *To:* Oliver Weinmann > *Subject:* Re: [OmniOS-discuss] Loosing NFS shares > > Hi Oliver, > > What is your network setup in relationship to NFS file server and VM > Host? Is your backdone using 10Gbe network and are they setup with > redundancy (eg. MLAG)? > > Regards. > > On Thu, Jun 22, 2017 at 2:45 PM, Oliver Weinmann > > wrote: > > Hi, > > we are using OmniOS for a few months now and have big trouble with > stability. We mainly use it for VMware NFS datastores. The last 3 > nights we lost all NFS datastores and VMs stopped running. I > noticed that even though zfs get sharenfs shows folders as shared > they become inaccessible. Setting sharenfs to off and sharing > again solves the issue. I have no clue where to start. I?m fairly > new to OmniOS. > > Any help would be highly appreciated. > > Thanks and Best Regards, > > Oliver > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 > (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > > _______________________________________________ > 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: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7535 bytes Desc: not available URL: From bardishe at gmail.com Fri Jun 23 14:13:52 2017 From: bardishe at gmail.com (Artyom Zhandarovsky) Date: Fri, 23 Jun 2017 17:13:52 +0300 Subject: [OmniOS-discuss] Fragmentation Message-ID: disk errors: none --------- CAP Alert --------- Is there any way to decrease fragmentation of dr_tank ? ------------------------------ zpool list (Sum of RAW disk capacity without redundancy counted) ------------------------------ NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT dr_slow 9.06T 77.6M 9.06T - 0% 0% 1.00x ONLINE - dr_tank 48.9T 35.1T 13.9T - 23% 71% 1.00x ONLINE - rpool 272G 42.1G 230G - 10% 15% 1.00x ONLINE - Real Pool capacity from zfs list ------------------------------ NAME USED AVAIL MOUNTPOINT % dr_slow 7.69T 1.26T /dr_slow 14%! dr_tank 41.6T 6.33T /dr_tank 13%! rpool 45.6G 218G /rpool 83% -------------- next part -------------- An HTML attachment was scrubbed... URL: From cks at cs.toronto.edu Fri Jun 23 15:07:11 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Fri, 23 Jun 2017 11:07:11 -0400 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: Your message of Fri, 23 Jun 2017 17:13:52 +0300. Message-ID: <20170623150711.537065A03F9@apps1.cs.toronto.edu> > Is there any way to decrease fragmentation of dr_tank ? > > ------------------------------ > > zpool list (Sum of RAW disk capacity without redundancy counted) > > ------------------------------ > > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > > dr_slow 9.06T 77.6M 9.06T - 0% 0% 1.00x ONLINE - > dr_tank 48.9T 35.1T 13.9T - 23% 71% 1.00x ONLINE - > rpool 272G 42.1G 230G - 10% 15% 1.00x ONLINE - Note that 'FRAG' probably doesn't mean what you expect it to mean, and you probably don't need to worry about it. The ZFS FRAG percentage here is how fragmented *free space* is, not how fragmented your data is, and the details are arcane. A pool with low FRAG has most of its free space in large contiguous segments; a pool with high FRAG has most of the free space broken up into small pieces. FRAG is essentially a measure of how hard ZFS will have to work to find space for new data. For more details, you can read: https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSZpoolFragmentationMeaning https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSZpoolFragmentationDetails (These were current as of late 2015, but the details might have changed slightly since then.) - cks From alka at hfg-gmuend.de Fri Jun 23 15:09:46 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 23 Jun 2017 17:09:46 +0200 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: References: Message-ID: <54d75c7e-49e2-3cc1-8745-7c8c002f8cf0@hfg-gmuend.de> The fragmentation info does not describe the fragmentation of the data on pool but the fragmentation of the free space. A high fragmentation value will result in high data fragmentation only when you write or modify data. https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSZpoolFragmentationMeaning So the best and only way to reduce data fragmentation is not to fill up a pool say over 70-80%. You should also know that CopyOnWrite filesystems where a complete datablock ex 128k is written newly even if you change a "house" to a "mouse" in a textfile are more vulnerable to fragmentation than older filesystems. This is the price for the crash resitency where a power outage during a write cannot lead to a corrupted filesystem like with older filesystems where it can happen that the data is modified "infile" while the according metadata update is not happening. ZFS over-compensates this with its advanced rambased read and write caches. A "defrag tool" is not available for ZFS. Gea Am 23.06.2017 um 16:13 schrieb Artyom Zhandarovsky: > there any way to decrease fragmentation of dr_tank ? -- From bardishe at gmail.com Fri Jun 23 15:19:33 2017 From: bardishe at gmail.com (Artyom Zhandarovsky) Date: Fri, 23 Jun 2017 18:19:33 +0300 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: <54d75c7e-49e2-3cc1-8745-7c8c002f8cf0@hfg-gmuend.de> References: <54d75c7e-49e2-3cc1-8745-7c8c002f8cf0@hfg-gmuend.de> Message-ID: So basically i need to add just more drives... ? 2017-06-23 18:09 GMT+03:00 Guenther Alka : > The fragmentation info does not describe the fragmentation of the data on > pool but the fragmentation of the free space. A high fragmentation value > will result in high data fragmentation only when you write or modify data. > > https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSZpoolFra > gmentationMeaning > So the best and only way to reduce data fragmentation is not to fill up a > pool say over 70-80%. > > You should also know that CopyOnWrite filesystems where a complete > datablock ex 128k is written newly even if you change a "house" to a > "mouse" in a textfile are more vulnerable to fragmentation than older > filesystems. This is the price for the crash resitency where a power outage > during a write cannot lead to a corrupted filesystem like with older > filesystems where it can happen that the data is modified "infile" while > the according metadata update is not happening. ZFS over-compensates this > with its advanced rambased read and write caches. A "defrag tool" is not > available for ZFS. > > Gea > > > Am 23.06.2017 um 16:13 schrieb Artyom Zhandarovsky: > >> there any way to decrease fragmentation of dr_tank ? >> > > -- > > _______________________________________________ > 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 alka at hfg-gmuend.de Fri Jun 23 15:25:25 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 23 Jun 2017 17:25:25 +0200 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: References: <54d75c7e-49e2-3cc1-8745-7c8c002f8cf0@hfg-gmuend.de> Message-ID: <0edf4612-41fc-4f70-8c58-b096df534dc2@hfg-gmuend.de> Yes, but If you increase your pool by adding a new vdev, your current data are not auto-rebalanced. This will only happen over time with new or modified data. If you want the best performance then, you must copy over current data ex by renaming a filesystem, replicate it to the former name and delete it then. Gea Am 23.06.2017 um 17:19 schrieb Artyom Zhandarovsky: > So basically i need to add just more drives... ? > > 2017-06-23 18:09 GMT+03:00 Guenther Alka >: > > The fragmentation info does not describe the fragmentation of the > data on pool but the fragmentation of the free space. A high > fragmentation value will result in high data fragmentation only > when you write or modify data. > > https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSZpoolFragmentationMeaning > > So the best and only way to reduce data fragmentation is not to > fill up a pool say over 70-80%. > > You should also know that CopyOnWrite filesystems where a complete > datablock ex 128k is written newly even if you change a "house" to > a "mouse" in a textfile are more vulnerable to fragmentation than > older filesystems. This is the price for the crash resitency where > a power outage during a write cannot lead to a corrupted > filesystem like with older filesystems where it can happen that > the data is modified "infile" while the according metadata update > is not happening. ZFS over-compensates this with its advanced > rambased read and write caches. A "defrag tool" is not available > for ZFS. > > Gea > > > Am 23.06.2017 um 16:13 schrieb Artyom Zhandarovsky: > > there any way to decrease fragmentation of dr_tank ? > > > -- > > _______________________________________________ > 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 Fri Jun 23 15:32:04 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Fri, 23 Jun 2017 15:32:04 +0000 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: References: Message-ID: On June 23, 2017 4:13:52 PM GMT+02:00, Artyom Zhandarovsky wrote: >disk errors: none > > > > > >--------- > >CAP Alert > >--------- > > > > Is there any way to decrease fragmentation of dr_tank ? > >------------------------------ > >zpool list (Sum of RAW disk capacity without redundancy counted) > >------------------------------ > >NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH >ALTROOT > >dr_slow 9.06T 77.6M 9.06T - 0% 0% 1.00x ONLINE - > >dr_tank 48.9T 35.1T 13.9T - 23% 71% 1.00x ONLINE - > >rpool 272G 42.1G 230G - 10% 15% 1.00x ONLINE - > > > >Real Pool capacity from zfs list > >------------------------------ > >NAME USED AVAIL MOUNTPOINT % > >dr_slow 7.69T 1.26T /dr_slow 14%! > >dr_tank 41.6T 6.33T /dr_tank 13%! > >rpool 45.6G 218G /rpool 83% The issue of zfs fragmentation is that at some point it becomes hard to find free spots to write into, as well as to do large writes contiguously, so performance suddenly and noticeably drops. This can impact reads as well, especially if atime=on is left as default. To recover from existing fragmentation you must free up space, perhaps zfs-send datasets to another pool, empty as much as you can on this one, and send data back - so it lands in large contiguous writes. To prevent it, a ZIL caching all writes (including sync ones, e.g. nfs) can help. Perhaps a DDR drive (or mirror of these) with battery and flash protection from poweroffs, so it does not wear out like flash would. In this case, how-ever random writes come, ZFS does not have to put them on media asap - so it can do larger writes later. This can also protect SSD arrays from excessive small writes and wear-out, though there a bad(ly sized) ZIL can become a bottleneck. Hope this helps, Jim -- Typos courtesy of K-9 Mail on my Redmi Android From alka at hfg-gmuend.de Fri Jun 23 15:56:11 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 23 Jun 2017 17:56:11 +0200 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: References: Message-ID: <2a9d9009-7e6d-a13e-2184-187e6fbb2da1@hfg-gmuend.de> A Zil or better dedicated Slog device will not help as this is not a write cache but a logdevice. Its only there to commit every written datablock and to put it onto stable storage. It is read only after a crash to redo a missing committed write. All writes, does not matter if sync or not, are going over the rambased write cache (per default up to 4GB). This is flushed from time to time as a large sequential write. Writes are fragmented then depending on the fragmentation of the free space. Gea > To prevent it, a ZIL caching all writes (including sync ones, e.g. nfs) can help. Perhaps a DDR drive (or mirror of these) with battery and flash protection from poweroffs, so it does not wear out like flash would. In this case, how-ever random writes come, ZFS does not have to put them on media asap - so it can do larger writes later. This can also protect SSD arrays from excessive small writes and wear-out, though there a bad(ly sized) ZIL can become a bottleneck. > > Hope this helps, > Jim > -- From richard.elling at richardelling.com Fri Jun 23 17:30:43 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 23 Jun 2017 10:30:43 -0700 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: <2a9d9009-7e6d-a13e-2184-187e6fbb2da1@hfg-gmuend.de> References: <2a9d9009-7e6d-a13e-2184-187e6fbb2da1@hfg-gmuend.de> Message-ID: <846C6DA8-32B0-4800-88D1-E3967E8D35AE@richardelling.com> A slog helps fragmentation because the space for ZIL is pre-allocated based on a prediction of how big the write will be. The pre-allocated space includes a physical-block-sized chain block for the ZIL. An 8k write can allocate 12k for the ZIL entry that is freed when the txg commits. Thus, a slog can help decrease free space fragmentation in the pool. ? richard > On Jun 23, 2017, at 8:56 AM, Guenther Alka wrote: > > A Zil or better dedicated Slog device will not help as this is not a write cache but a logdevice. Its only there to commit every written datablock and to put it onto stable storage. It is read only after a crash to redo a missing committed write. > > All writes, does not matter if sync or not, are going over the rambased write cache (per default up to 4GB). This is flushed from time to time as a large sequential write. Writes are fragmented then depending on the fragmentation of the free space. > > Gea > > >> To prevent it, a ZIL caching all writes (including sync ones, e.g. nfs) can help. Perhaps a DDR drive (or mirror of these) with battery and flash protection from poweroffs, so it does not wear out like flash would. In this case, how-ever random writes come, ZFS does not have to put them on media asap - so it can do larger writes later. This can also protect SSD arrays from excessive small writes and wear-out, though there a bad(ly sized) ZIL can become a bottleneck. >> >> Hope this helps, >> Jim >> -- > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From alka at hfg-gmuend.de Fri Jun 23 18:30:23 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Fri, 23 Jun 2017 20:30:23 +0200 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: <846C6DA8-32B0-4800-88D1-E3967E8D35AE@richardelling.com> References: <2a9d9009-7e6d-a13e-2184-187e6fbb2da1@hfg-gmuend.de> <846C6DA8-32B0-4800-88D1-E3967E8D35AE@richardelling.com> Message-ID: <1c684975-e475-584e-4d97-87ba8e012093@hfg-gmuend.de> hello Richard I can follow that the Zil does not add more fragmentation to the free space but is this effect relevant? If a ZIL pre-allocates say 4G and the remaining fragmented poolsize for regular writes is 12T Gea Am 23.06.2017 um 19:30 schrieb Richard Elling: > A slog helps fragmentation because the space for ZIL is pre-allocated based on a prediction of > how big the write will be. The pre-allocated space includes a physical-block-sized chain block for the > ZIL. An 8k write can allocate 12k for the ZIL entry that is freed when the txg commits. Thus, a slog > can help decrease free space fragmentation in the pool. > ? richard > > >> On Jun 23, 2017, at 8:56 AM, Guenther Alka wrote: >> >> A Zil or better dedicated Slog device will not help as this is not a write cache but a logdevice. Its only there to commit every written datablock and to put it onto stable storage. It is read only after a crash to redo a missing committed write. >> >> All writes, does not matter if sync or not, are going over the rambased write cache (per default up to 4GB). This is flushed from time to time as a large sequential write. Writes are fragmented then depending on the fragmentation of the free space. >> >> Gea >> >> >>> To prevent it, a ZIL caching all writes (including sync ones, e.g. nfs) can help. Perhaps a DDR drive (or mirror of these) with battery and flash protection from poweroffs, so it does not wear out like flash would. In this case, how-ever random writes come, ZFS does not have to put them on media asap - so it can do larger writes later. This can also protect SSD arrays from excessive small writes and wear-out, though there a bad(ly sized) ZIL can become a bottleneck. >>> >>> Hope this helps, >>> Jim >>> -- >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss -- From richard.elling at richardelling.com Fri Jun 23 19:01:20 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 23 Jun 2017 12:01:20 -0700 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: <1c684975-e475-584e-4d97-87ba8e012093@hfg-gmuend.de> References: <2a9d9009-7e6d-a13e-2184-187e6fbb2da1@hfg-gmuend.de> <846C6DA8-32B0-4800-88D1-E3967E8D35AE@richardelling.com> <1c684975-e475-584e-4d97-87ba8e012093@hfg-gmuend.de> Message-ID: <4D811B36-27BC-4A68-B6F1-169457D1791F@richardelling.com> ZIL pre-allocates at the block level, so think along the lines of 12k or 132k. ? richard > On Jun 23, 2017, at 11:30 AM, G?nther Alka wrote: > > hello Richard > > I can follow that the Zil does not add more fragmentation to the free space but is this effect relevant? > If a ZIL pre-allocates say 4G and the remaining fragmented poolsize for regular writes is 12T > > Gea > > Am 23.06.2017 um 19:30 schrieb Richard Elling: >> A slog helps fragmentation because the space for ZIL is pre-allocated based on a prediction of >> how big the write will be. The pre-allocated space includes a physical-block-sized chain block for the >> ZIL. An 8k write can allocate 12k for the ZIL entry that is freed when the txg commits. Thus, a slog >> can help decrease free space fragmentation in the pool. >> ? richard >> >> >>> On Jun 23, 2017, at 8:56 AM, Guenther Alka wrote: >>> >>> A Zil or better dedicated Slog device will not help as this is not a write cache but a logdevice. Its only there to commit every written datablock and to put it onto stable storage. It is read only after a crash to redo a missing committed write. >>> >>> All writes, does not matter if sync or not, are going over the rambased write cache (per default up to 4GB). This is flushed from time to time as a large sequential write. Writes are fragmented then depending on the fragmentation of the free space. >>> >>> Gea >>> >>> >>>> To prevent it, a ZIL caching all writes (including sync ones, e.g. nfs) can help. Perhaps a DDR drive (or mirror of these) with battery and flash protection from poweroffs, so it does not wear out like flash would. In this case, how-ever random writes come, ZFS does not have to put them on media asap - so it can do larger writes later. This can also protect SSD arrays from excessive small writes and wear-out, though there a bad(ly sized) ZIL can become a bottleneck. >>>> >>>> Hope this helps, >>>> Jim >>>> -- >>> _______________________________________________ >>> 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 jimklimov at cos.ru Sun Jun 25 19:36:38 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Sun, 25 Jun 2017 19:36:38 +0000 Subject: [OmniOS-discuss] Fragmentation In-Reply-To: <4D811B36-27BC-4A68-B6F1-169457D1791F@richardelling.com> References: <2a9d9009-7e6d-a13e-2184-187e6fbb2da1@hfg-gmuend.de> <846C6DA8-32B0-4800-88D1-E3967E8D35AE@richardelling.com> <1c684975-e475-584e-4d97-87ba8e012093@hfg-gmuend.de> <4D811B36-27BC-4A68-B6F1-169457D1791F@richardelling.com> Message-ID: <149A9E5A-E007-4DEB-975A-CFBCBA6376AC@cos.ru> On June 23, 2017 9:01:20 PM GMT+02:00, Richard Elling wrote: >ZIL pre-allocates at the block level, so think along the lines of 12k >or 132k. > ? richard > >> On Jun 23, 2017, at 11:30 AM, G?nther Alka >wrote: >> >> hello Richard >> >> I can follow that the Zil does not add more fragmentation to the free >space but is this effect relevant? >> If a ZIL pre-allocates say 4G and the remaining fragmented poolsize >for regular writes is 12T >> >> Gea >> >> Am 23.06.2017 um 19:30 schrieb Richard Elling: >>> A slog helps fragmentation because the space for ZIL is >pre-allocated based on a prediction of >>> how big the write will be. The pre-allocated space includes a >physical-block-sized chain block for the >>> ZIL. An 8k write can allocate 12k for the ZIL entry that is freed >when the txg commits. Thus, a slog >>> can help decrease free space fragmentation in the pool. >>> ? richard >>> >>> >>>> On Jun 23, 2017, at 8:56 AM, Guenther Alka >wrote: >>>> >>>> A Zil or better dedicated Slog device will not help as this is not >a write cache but a logdevice. Its only there to commit every written >datablock and to put it onto stable storage. It is read only after a >crash to redo a missing committed write. >>>> >>>> All writes, does not matter if sync or not, are going over the >rambased write cache (per default up to 4GB). This is flushed from time >to time as a large sequential write. Writes are fragmented then >depending on the fragmentation of the free space. >>>> >>>> Gea >>>> >>>> >>>>> To prevent it, a ZIL caching all writes (including sync ones, e.g. >nfs) can help. Perhaps a DDR drive (or mirror of these) with battery >and flash protection from poweroffs, so it does not wear out like flash >would. In this case, how-ever random writes come, ZFS does not have to >put them on media asap - so it can do larger writes later. This can >also protect SSD arrays from excessive small writes and wear-out, >though there a bad(ly sized) ZIL can become a bottleneck. >>>>> >>>>> Hope this helps, >>>>> Jim >>>>> -- >>>> _______________________________________________ >>>> 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 @Gea, IIRC one can set sync mode on a dataset, effectively forcing all writes to go to (dedicated) ZIL, and data remains in memory until flushed to persistent bulk storage like normal pool writes go. This way more consolidated writes can be sent to disks of the pool, rather than forcing many small (sync) allocations and deallocations if (sync) writes are small and intensive enough, e.g. appending log files, etc. For SSD pools this is thought to also ease the wear due to ability to reprogram whole pages, compensating also for small intensive random writes since random LBAs can live in same page. Jim Hope Richard would correct me if I got something wrong ;) -- Typos courtesy of K-9 Mail on my Redmi Android From oliver.weinmann at telespazio-vega.de Tue Jun 27 06:24:49 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Tue, 27 Jun 2017 06:24:49 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> Hi, we are currently migrating all our data from a NetAPP system to an OmniOS sytem. The OmniOS system is joined to AD and LDAP client is configured to pull LDAP info from AD / IDMU. This works fine. However we can't manage to have access on folders where we have Unix permissions from windows (CIFS). e.g. the user utest2 is member of the goup "Up BCSIM De_Dt Da Lg": root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups utest2 10000 Up BCSIM De_Dt Da Lg The folder Unix has the following permissions set: root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al total 47 d---------+ 4 root 2147483653 4 Apr 25 05:37 . d---------+ 4 root 2147483659 4 Apr 25 05:35 .. drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows so User bcsim and all members of group "Up BCSIM De_Dt Da Lg" can access the folder just fine via NFS. If the user utest2 tries to access this folder from windows via CIFS he gets access denied. If I change the permissions so that other have r-x he can access the folder but then I have no control on who can access the folder. On our NetApp system this was working fine. I assume it has to do with the IDMAP daemon using ephemeral mappings instead of pulling the uidnumber and gidnumber from AD? I don't want to use extended ACLs on this folder. Any ideas? [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From bauernfeind at ipk-gatersleben.de Tue Jun 27 07:37:07 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Tue, 27 Jun 2017 07:37:07 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> Message-ID: Hi, I fixed this problem after executing this: idmap add winname:"*@" unixuser:"*" idmap add wingroup:"*@ " unixgroup:"*" svcadm restart idmap All new created files has now the uid and gid from the IDMU Jens > -----Original Message----- > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > On Behalf Of Oliver Weinmann > Sent: Dienstag, 27. Juni 2017 08:25 > To: omnios-discuss > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Hi, > > > > we are currently migrating all our data from a NetAPP system to an OmniOS > sytem. > > > > The OmniOS system is joined to AD and LDAP client is configured to pull LDAP > info from AD / IDMU. This works fine. > > > > However we can?t manage to have access on folders where we have Unix > permissions from windows (CIFS). > > > > e.g. > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups utest2 > > 10000 Up BCSIM De_Dt Da Lg > > > > The folder Unix has the following permissions set: > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > total 47 > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can access > the folder just fine via NFS. > > > > If the user utest2 tries to access this folder from windows via CIFS he gets > access denied. > > > > If I change the permissions so that other have r-x he can access the folder > but then I have no control on who can access the folder. > > > > On our NetApp system this was working fine. I assume it has to do with the > IDMAP daemon using ephemeral mappings instead of pulling the uidnumber > and gidnumber from AD? > > > > I don?t want to use extended ACLs on this folder. > > > > Any ideas? > > > > > > Oliver Weinmann > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de vega.de> > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From bauernfeind at ipk-gatersleben.de Tue Jun 27 12:47:10 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Tue, 27 Jun 2017 12:47:10 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> Message-ID: Hm, maybe I should share my ldap config. ldapclient -v manual \ -a credentialLevel=proxy \ -a authenticationMethod=simple \ -a proxyDN="cn=XXX" \ -a proxyPassword=SECRET \ -a defaultSearchBase=dc=ipk=de \ -a domainName=DOMAINNAME \ -a defaultServerList= \ -a attributeMap=group:userpassword=userPassword \ -a attributeMap=group:uniqueMember=member \ -a attributeMap=group:gidnumber=gidNumber \ -a attributeMap=passwd:gecos=cn \ -a attributeMap=passwd:gidnumber=gidNumber \ -a attributeMap=passwd:uidnumber=uidNumber \ -a attributeMap=passwd:uid=sAMAccountName \ -a attributeMap=passwd:homedirectory=unixHomeDirectory \ -a attributeMap=passwd:loginshell=loginShell \ -a attributeMap=shadow:shadowflag=shadowFlag \ -a attributeMap=shadow:userpassword=userPassword \ -a objectClassMap=group:posixGroup=group \ -a objectClassMap=passwd:posixAccount=user \ -a objectClassMap=shadow:shadowAccount=user \ -a serviceSearchDescriptor="passwd:" \ -a serviceSearchDescriptor=group: \ -a followReferrals=true Maybe also a restart of the smb service? Jens > -----Original Message----- > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > Sent: Dienstag, 27. Juni 2017 14:40 > To: Jens Bauernfeind > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Hi, > > > > Now I get can?t access domain info in the smb log and users are prompted to > enter a password when accessing the shares. :( > > > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > Sent: Dienstag, 27. Juni 2017 09:37 > To: Oliver Weinmann > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > > > Hi, > > > > I fixed this problem after executing this: > > idmap add winname:"*@" unixuser:"*" > > idmap add wingroup:"*@ " unixgroup:"*" > > svcadm restart idmap > > All new created files has now the uid and gid from the IDMU > > > > Jens > > > > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > On Behalf Of Oliver Weinmann > Sent: Dienstag, 27. Juni 2017 08:25 > To: omnios-discuss discuss at lists.omniti.com> > > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > > > Hi, > > > > we are currently migrating all our data from a NetAPP system to an OmniOS > sytem. > > > > The OmniOS system is joined to AD and LDAP client is configured to pull LDAP > info from AD / IDMU. This works fine. > > > > However we can?t manage to have access on folders where we have Unix > permissions from windows (CIFS). > > > > e.g. > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups utest2 > > 10000 Up BCSIM De_Dt Da Lg > > > > The folder Unix has the following permissions set: > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > total 47 > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can access > the folder just fine via NFS. > > > > If the user utest2 tries to access this folder from windows via CIFS he gets > access denied. > > > > If I change the permissions so that other have r-x he can access the folder > but then I have no control on who can access the folder. > > > > On our NetApp system this was working fine. I assume it has to do with the > IDMAP daemon using ephemeral mappings instead of pulling the uidnumber > and gidnumber from AD? > > > > I don?t want to use extended ACLs on this folder. > > > > Any ideas? > > > > > > Oliver Weinmann > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de vega.de> > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From oliver.weinmann at telespazio-vega.de Tue Jun 27 12:49:07 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Tue, 27 Jun 2017 12:49:07 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> What version of omnios are you using? I'm using R151022. -----Original Message----- From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] Sent: Dienstag, 27. Juni 2017 14:47 To: Oliver Weinmann Cc: omnios-discuss Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions Hm, maybe I should share my ldap config. ldapclient -v manual \ -a credentialLevel=proxy \ -a authenticationMethod=simple \ -a proxyDN="cn=XXX" \ -a proxyPassword=SECRET \ -a defaultSearchBase=dc=ipk=de \ -a domainName=DOMAINNAME \ -a defaultServerList= \ -a attributeMap=group:userpassword=userPassword \ -a attributeMap=group:uniqueMember=member \ -a attributeMap=group:gidnumber=gidNumber \ -a attributeMap=passwd:gecos=cn \ -a attributeMap=passwd:gidnumber=gidNumber \ -a attributeMap=passwd:uidnumber=uidNumber \ -a attributeMap=passwd:uid=sAMAccountName \ -a attributeMap=passwd:homedirectory=unixHomeDirectory \ -a attributeMap=passwd:loginshell=loginShell \ -a attributeMap=shadow:shadowflag=shadowFlag \ -a attributeMap=shadow:userpassword=userPassword \ -a objectClassMap=group:posixGroup=group \ -a objectClassMap=passwd:posixAccount=user \ -a objectClassMap=shadow:shadowAccount=user \ -a serviceSearchDescriptor="passwd:" \ -a serviceSearchDescriptor=group: \ -a followReferrals=true Maybe also a restart of the smb service? Jens > -----Original Message----- > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > Sent: Dienstag, 27. Juni 2017 14:40 > To: Jens Bauernfeind > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Hi, > > > > Now I get can?t access domain info in the smb log and users are prompted to > enter a password when accessing the shares. :( > > > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > Sent: Dienstag, 27. Juni 2017 09:37 > To: Oliver Weinmann > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > > > Hi, > > > > I fixed this problem after executing this: > > idmap add winname:"*@" unixuser:"*" > > idmap add wingroup:"*@ " unixgroup:"*" > > svcadm restart idmap > > All new created files has now the uid and gid from the IDMU > > > > Jens > > > > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > On Behalf Of Oliver Weinmann > Sent: Dienstag, 27. Juni 2017 08:25 > To: omnios-discuss discuss at lists.omniti.com> > > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > > > Hi, > > > > we are currently migrating all our data from a NetAPP system to an OmniOS > sytem. > > > > The OmniOS system is joined to AD and LDAP client is configured to pull LDAP > info from AD / IDMU. This works fine. > > > > However we can?t manage to have access on folders where we have Unix > permissions from windows (CIFS). > > > > e.g. > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups utest2 > > 10000 Up BCSIM De_Dt Da Lg > > > > The folder Unix has the following permissions set: > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > total 47 > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can access > the folder just fine via NFS. > > > > If the user utest2 tries to access this folder from windows via CIFS he gets > access denied. > > > > If I change the permissions so that other have r-x he can access the folder > but then I have no control on who can access the folder. > > > > On our NetApp system this was working fine. I assume it has to do with the > IDMAP daemon using ephemeral mappings instead of pulling the uidnumber > and gidnumber from AD? > > > > I don?t want to use extended ACLs on this folder. > > > > Any ideas? > > > > > > Oliver Weinmann > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de vega.de> > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4970 bytes Desc: not available URL: From bauernfeind at ipk-gatersleben.de Tue Jun 27 13:19:01 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Tue, 27 Jun 2017 13:19:01 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> Message-ID: also r151022 What is your /etc/nsswitch.conf saying? Mine has nearly everywhere "files ldap", except hosts and ipnodes. > -----Original Message----- > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > Sent: Dienstag, 27. Juni 2017 14:49 > To: Jens Bauernfeind > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > What version of omnios are you using? I'm using R151022. > > -----Original Message----- > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > Sent: Dienstag, 27. Juni 2017 14:47 > To: Oliver Weinmann > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Hm, > > maybe I should share my ldap config. > ldapclient -v manual \ > -a credentialLevel=proxy \ > -a authenticationMethod=simple \ > -a proxyDN="cn=XXX" \ > -a proxyPassword=SECRET \ > -a defaultSearchBase=dc=ipk=de \ > -a domainName=DOMAINNAME \ > -a defaultServerList= \ > -a attributeMap=group:userpassword=userPassword \ > -a attributeMap=group:uniqueMember=member \ > -a attributeMap=group:gidnumber=gidNumber \ > -a attributeMap=passwd:gecos=cn \ > -a attributeMap=passwd:gidnumber=gidNumber \ > -a attributeMap=passwd:uidnumber=uidNumber \ > -a attributeMap=passwd:uid=sAMAccountName \ > -a attributeMap=passwd:homedirectory=unixHomeDirectory \ > -a attributeMap=passwd:loginshell=loginShell \ > -a attributeMap=shadow:shadowflag=shadowFlag \ > -a attributeMap=shadow:userpassword=userPassword \ > -a objectClassMap=group:posixGroup=group \ > -a objectClassMap=passwd:posixAccount=user \ > -a objectClassMap=shadow:shadowAccount=user \ > -a serviceSearchDescriptor="passwd:" \ > -a serviceSearchDescriptor=group: \ > -a followReferrals=true > > Maybe also a restart of the smb service? > > Jens > > > -----Original Message----- > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > Sent: Dienstag, 27. Juni 2017 14:40 > > To: Jens Bauernfeind > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > Hi, > > > > > > > > Now I get can?t access domain info in the smb log and users are prompted > to > > enter a password when accessing the shares. :( > > > > > > > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > Sent: Dienstag, 27. Juni 2017 09:37 > > To: Oliver Weinmann > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > > > > > Hi, > > > > > > > > I fixed this problem after executing this: > > > > idmap add winname:"*@" unixuser:"*" > > > > idmap add wingroup:"*@ " unixgroup:"*" > > > > svcadm restart idmap > > > > All new created files has now the uid and gid from the IDMU > > > > > > > > Jens > > > > > > > > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > > On Behalf Of Oliver Weinmann > > Sent: Dienstag, 27. Juni 2017 08:25 > > To: omnios-discuss > discuss at lists.omniti.com> > > > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > > > > > Hi, > > > > > > > > we are currently migrating all our data from a NetAPP system to an OmniOS > > sytem. > > > > > > > > The OmniOS system is joined to AD and LDAP client is configured to pull > LDAP > > info from AD / IDMU. This works fine. > > > > > > > > However we can?t manage to have access on folders where we have Unix > > permissions from windows (CIFS). > > > > > > > > e.g. > > > > > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups utest2 > > > > 10000 Up BCSIM De_Dt Da Lg > > > > > > > > The folder Unix has the following permissions set: > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > > > total 47 > > > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can > access > > the folder just fine via NFS. > > > > > > > > If the user utest2 tries to access this folder from windows via CIFS he > gets > > access denied. > > > > > > > > If I change the permissions so that other have r-x he can access the > folder > > but then I have no control on who can access the folder. > > > > > > > > On our NetApp system this was working fine. I assume it has to do with the > > IDMAP daemon using ephemeral mappings instead of pulling the > uidnumber > > and gidnumber from AD? > > > > > > > > I don?t want to use extended ACLs on this folder. > > > > > > > > Any ideas? > > > > > > > > > > > > Oliver Weinmann > > Senior Unix VMWare, Storage Engineer > > > > Telespazio VEGA Deutschland GmbH > > Europaplatz 5 - 64293 Darmstadt - Germany > > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > > oliver.weinmann at telespazio-vega.de > > vega.de> > > http://www.telespazio-vega.de > > > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, > > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From oliver.weinmann at telespazio-vega.de Tue Jun 27 13:20:45 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Tue, 27 Jun 2017 13:20:45 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> Mine has ldap only for passwd and group. So on your system it really works with just having the traditional unix permissions set. There are no ACLs in place? Do you have an Active Directory domain with IDMU? -----Original Message----- From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] Sent: Dienstag, 27. Juni 2017 15:19 To: Oliver Weinmann Cc: omnios-discuss Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions also r151022 What is your /etc/nsswitch.conf saying? Mine has nearly everywhere "files ldap", except hosts and ipnodes. > -----Original Message----- > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > Sent: Dienstag, 27. Juni 2017 14:49 > To: Jens Bauernfeind > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > What version of omnios are you using? I'm using R151022. > > -----Original Message----- > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > Sent: Dienstag, 27. Juni 2017 14:47 > To: Oliver Weinmann > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Hm, > > maybe I should share my ldap config. > ldapclient -v manual \ > -a credentialLevel=proxy \ > -a authenticationMethod=simple \ > -a proxyDN="cn=XXX" \ > -a proxyPassword=SECRET \ > -a defaultSearchBase=dc=ipk=de \ > -a domainName=DOMAINNAME \ > -a defaultServerList= \ > -a attributeMap=group:userpassword=userPassword \ > -a attributeMap=group:uniqueMember=member \ > -a attributeMap=group:gidnumber=gidNumber \ > -a attributeMap=passwd:gecos=cn \ > -a attributeMap=passwd:gidnumber=gidNumber \ > -a attributeMap=passwd:uidnumber=uidNumber \ > -a attributeMap=passwd:uid=sAMAccountName \ > -a attributeMap=passwd:homedirectory=unixHomeDirectory \ > -a attributeMap=passwd:loginshell=loginShell \ > -a attributeMap=shadow:shadowflag=shadowFlag \ > -a attributeMap=shadow:userpassword=userPassword \ > -a objectClassMap=group:posixGroup=group \ > -a objectClassMap=passwd:posixAccount=user \ > -a objectClassMap=shadow:shadowAccount=user \ > -a serviceSearchDescriptor="passwd:" \ > -a serviceSearchDescriptor=group: \ > -a followReferrals=true > > Maybe also a restart of the smb service? > > Jens > > > -----Original Message----- > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > Sent: Dienstag, 27. Juni 2017 14:40 > > To: Jens Bauernfeind > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > Hi, > > > > > > > > Now I get can?t access domain info in the smb log and users are prompted > to > > enter a password when accessing the shares. :( > > > > > > > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > Sent: Dienstag, 27. Juni 2017 09:37 > > To: Oliver Weinmann > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > > > > > Hi, > > > > > > > > I fixed this problem after executing this: > > > > idmap add winname:"*@" unixuser:"*" > > > > idmap add wingroup:"*@ " unixgroup:"*" > > > > svcadm restart idmap > > > > All new created files has now the uid and gid from the IDMU > > > > > > > > Jens > > > > > > > > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > > On Behalf Of Oliver Weinmann > > Sent: Dienstag, 27. Juni 2017 08:25 > > To: omnios-discuss > discuss at lists.omniti.com> > > > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > > > > > Hi, > > > > > > > > we are currently migrating all our data from a NetAPP system to an OmniOS > > sytem. > > > > > > > > The OmniOS system is joined to AD and LDAP client is configured to pull > LDAP > > info from AD / IDMU. This works fine. > > > > > > > > However we can?t manage to have access on folders where we have Unix > > permissions from windows (CIFS). > > > > > > > > e.g. > > > > > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups utest2 > > > > 10000 Up BCSIM De_Dt Da Lg > > > > > > > > The folder Unix has the following permissions set: > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > > > total 47 > > > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can > access > > the folder just fine via NFS. > > > > > > > > If the user utest2 tries to access this folder from windows via CIFS he > gets > > access denied. > > > > > > > > If I change the permissions so that other have r-x he can access the > folder > > but then I have no control on who can access the folder. > > > > > > > > On our NetApp system this was working fine. I assume it has to do with the > > IDMAP daemon using ephemeral mappings instead of pulling the > uidnumber > > and gidnumber from AD? > > > > > > > > I don?t want to use extended ACLs on this folder. > > > > > > > > Any ideas? > > > > > > > > > > > > Oliver Weinmann > > Senior Unix VMWare, Storage Engineer > > > > Telespazio VEGA Deutschland GmbH > > Europaplatz 5 - 64293 Darmstadt - Germany > > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > > oliver.weinmann at telespazio-vega.de > > vega.de> > > http://www.telespazio-vega.de > > > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, > > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4970 bytes Desc: not available URL: From bauernfeind at ipk-gatersleben.de Wed Jun 28 06:08:40 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Wed, 28 Jun 2017 06:08:40 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> Message-ID: Yeah, AD with IDMU According to this page (very old, but still the truth), you can't live without ACLs. https://mattwilson.org/blog/solaris/solaris-cifs-server-and-zfs-acls-the-pro blem/ You have to inherit the ACLs to newly created files. At first I switched to the passthrough acl properties: zfs set aclmode=passthrough tank zfs set aclinherit=passthrough tank Then you have to define an initial ACL for your datasets For this example I just assume you have the pool tank and one dataset test - first set your sticky bit chmod g+s /tank/test - then set the ACLs chmod A=owner@:rwxp-DaARWcCos:df:allow,group@:rwxp-DaARWcCos:df:allow,everyone@::d f:allow /tank/test so nearly full permission for the owner and the group, and nothing for others; all ACLs are inherited to new created files and directories [the "df"] 8<--- ls -Vd /tank/test drwxrws---+ 5 root IT 5 Jun 28 07:55 /tank/test owner@:rwxp-DaARWcCos:fd-----:allow group@:rwxp-DaARWcCos:fd-----:allow everyone@:--------------:fd-----:allow 8<--- (This inheritance doesnt apply to new datesets you create via zfs, btw) But care: When you ever doing a chmod operation or a chgrp on /tank/test (or every other dateset,), the owner,group and everyone ACEs get overwritten (according to http://docs.oracle.com/cd/E36784_01/html/E36835/gbaaz.html) 8<--- chgrp 0 /tank/test ls -Vd /tank/test drwxrws--- 5 root root 5 Jun 28 07:55 /tank/test owner@:rwxp-DaARWcCos:-------:allow group@:rwxp-Da-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow See the missing "+" and "fd"? 8<--- (This doesn't apply to folders or files) I hope this helps and I'm not telling lies here. But that is my experience with that. Jens > -----Original Message----- > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > Sent: Dienstag, 27. Juni 2017 15:21 > To: Jens Bauernfeind > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Mine has ldap only for passwd and group. > > So on your system it really works with just having the traditional unix > permissions set. There are no ACLs in place? > > Do you have an Active Directory domain with IDMU? > > -----Original Message----- > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > Sent: Dienstag, 27. Juni 2017 15:19 > To: Oliver Weinmann > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > also r151022 > > What is your /etc/nsswitch.conf saying? > Mine has nearly everywhere "files ldap", except hosts and ipnodes. > > > -----Original Message----- > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > Sent: Dienstag, 27. Juni 2017 14:49 > > To: Jens Bauernfeind > > Cc: omnios-discuss > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > What version of omnios are you using? I'm using R151022. > > > > -----Original Message----- > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > Sent: Dienstag, 27. Juni 2017 14:47 > > To: Oliver Weinmann > > Cc: omnios-discuss > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > Hm, > > > > maybe I should share my ldap config. > > ldapclient -v manual \ > > -a credentialLevel=proxy \ > > -a authenticationMethod=simple \ > > -a proxyDN="cn=XXX" \ > > -a proxyPassword=SECRET \ > > -a defaultSearchBase=dc=ipk=de \ > > -a domainName=DOMAINNAME \ > > -a defaultServerList= \ > > -a attributeMap=group:userpassword=userPassword \ > > -a attributeMap=group:uniqueMember=member \ > > -a attributeMap=group:gidnumber=gidNumber \ > > -a attributeMap=passwd:gecos=cn \ > > -a attributeMap=passwd:gidnumber=gidNumber \ > > -a attributeMap=passwd:uidnumber=uidNumber \ > > -a attributeMap=passwd:uid=sAMAccountName \ > > -a attributeMap=passwd:homedirectory=unixHomeDirectory \ > > -a attributeMap=passwd:loginshell=loginShell \ > > -a attributeMap=shadow:shadowflag=shadowFlag \ > > -a attributeMap=shadow:userpassword=userPassword \ > > -a objectClassMap=group:posixGroup=group \ > > -a objectClassMap=passwd:posixAccount=user \ > > -a objectClassMap=shadow:shadowAccount=user \ > > -a serviceSearchDescriptor="passwd:" \ > > -a serviceSearchDescriptor=group: \ > > -a followReferrals=true > > > > Maybe also a restart of the smb service? > > > > Jens > > > > > -----Original Message----- > > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > > Sent: Dienstag, 27. Juni 2017 14:40 > > > To: Jens Bauernfeind > > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > Hi, > > > > > > > > > > > > Now I get can?t access domain info in the smb log and users are prompted > > to > > > enter a password when accessing the shares. :( > > > > > > > > > > > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > > Sent: Dienstag, 27. Juni 2017 09:37 > > > To: Oliver Weinmann > > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > > > > > > > Hi, > > > > > > > > > > > > I fixed this problem after executing this: > > > > > > idmap add winname:"*@" unixuser:"*" > > > > > > idmap add wingroup:"*@ " unixgroup:"*" > > > > > > svcadm restart idmap > > > > > > All new created files has now the uid and gid from the IDMU > > > > > > > > > > > > Jens > > > > > > > > > > > > From: OmniOS-discuss [mailto:omnios-discuss- > bounces at lists.omniti.com] > > > On Behalf Of Oliver Weinmann > > > Sent: Dienstag, 27. Juni 2017 08:25 > > > To: omnios-discuss > > discuss at lists.omniti.com> > > > > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > > > > > > > Hi, > > > > > > > > > > > > we are currently migrating all our data from a NetAPP system to an > OmniOS > > > sytem. > > > > > > > > > > > > The OmniOS system is joined to AD and LDAP client is configured to pull > > LDAP > > > info from AD / IDMU. This works fine. > > > > > > > > > > > > However we can?t manage to have access on folders where we have Unix > > > permissions from windows (CIFS). > > > > > > > > > > > > e.g. > > > > > > > > > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups > utest2 > > > > > > 10000 Up BCSIM De_Dt Da Lg > > > > > > > > > > > > The folder Unix has the following permissions set: > > > > > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > > > > > total 47 > > > > > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > > > > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > > > > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > > > > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > > > > > > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can > > access > > > the folder just fine via NFS. > > > > > > > > > > > > If the user utest2 tries to access this folder from windows via CIFS he > > gets > > > access denied. > > > > > > > > > > > > If I change the permissions so that other have r-x he can access the > > folder > > > but then I have no control on who can access the folder. > > > > > > > > > > > > On our NetApp system this was working fine. I assume it has to do with > the > > > IDMAP daemon using ephemeral mappings instead of pulling the > > uidnumber > > > and gidnumber from AD? > > > > > > > > > > > > I don?t want to use extended ACLs on this folder. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > Oliver Weinmann > > > Senior Unix VMWare, Storage Engineer > > > > > > Telespazio VEGA Deutschland GmbH > > > Europaplatz 5 - 64293 Darmstadt - Germany > > > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > > > oliver.weinmann at telespazio-vega.de > > > > vega.de> > > > http://www.telespazio-vega.de > > > > > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > > Darmstadt, > > > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From oliver.weinmann at telespazio-vega.de Wed Jun 28 08:52:10 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Wed, 28 Jun 2017 08:52:10 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BD9828@GEDAEVW01.a.space.corp> Hi Jens, Thanks a lot for your support. I really appreciate it. :) I will test this on my fresh install of omnios 151022 and report back. It's really a pity that it only works If I do touch the ZFS ACLs. :( -----Original Message----- From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] Sent: Mittwoch, 28. Juni 2017 08:09 To: Oliver Weinmann Cc: omnios-discuss Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions Yeah, AD with IDMU According to this page (very old, but still the truth), you can't live without ACLs. https://mattwilson.org/blog/solaris/solaris-cifs-server-and-zfs-acls-the-pro blem/ You have to inherit the ACLs to newly created files. At first I switched to the passthrough acl properties: zfs set aclmode=passthrough tank zfs set aclinherit=passthrough tank Then you have to define an initial ACL for your datasets For this example I just assume you have the pool tank and one dataset test - first set your sticky bit chmod g+s /tank/test - then set the ACLs chmod A=owner@:rwxp-DaARWcCos:df:allow,group@:rwxp-DaARWcCos:df:allow,everyone@::d f:allow /tank/test so nearly full permission for the owner and the group, and nothing for others; all ACLs are inherited to new created files and directories [the "df"] 8<--- ls -Vd /tank/test drwxrws---+ 5 root IT 5 Jun 28 07:55 /tank/test owner@:rwxp-DaARWcCos:fd-----:allow group@:rwxp-DaARWcCos:fd-----:allow everyone@:--------------:fd-----:allow 8<--- (This inheritance doesnt apply to new datesets you create via zfs, btw) But care: When you ever doing a chmod operation or a chgrp on /tank/test (or every other dateset,), the owner,group and everyone ACEs get overwritten (according to http://docs.oracle.com/cd/E36784_01/html/E36835/gbaaz.html) 8<--- chgrp 0 /tank/test ls -Vd /tank/test drwxrws--- 5 root root 5 Jun 28 07:55 /tank/test owner@:rwxp-DaARWcCos:-------:allow group@:rwxp-Da-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow See the missing "+" and "fd"? 8<--- (This doesn't apply to folders or files) I hope this helps and I'm not telling lies here. But that is my experience with that. Jens > -----Original Message----- > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > Sent: Dienstag, 27. Juni 2017 15:21 > To: Jens Bauernfeind > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Mine has ldap only for passwd and group. > > So on your system it really works with just having the traditional unix > permissions set. There are no ACLs in place? > > Do you have an Active Directory domain with IDMU? > > -----Original Message----- > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > Sent: Dienstag, 27. Juni 2017 15:19 > To: Oliver Weinmann > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > also r151022 > > What is your /etc/nsswitch.conf saying? > Mine has nearly everywhere "files ldap", except hosts and ipnodes. > > > -----Original Message----- > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > Sent: Dienstag, 27. Juni 2017 14:49 > > To: Jens Bauernfeind > > Cc: omnios-discuss > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > What version of omnios are you using? I'm using R151022. > > > > -----Original Message----- > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > Sent: Dienstag, 27. Juni 2017 14:47 > > To: Oliver Weinmann > > Cc: omnios-discuss > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > Hm, > > > > maybe I should share my ldap config. > > ldapclient -v manual \ > > -a credentialLevel=proxy \ > > -a authenticationMethod=simple \ > > -a proxyDN="cn=XXX" \ > > -a proxyPassword=SECRET \ > > -a defaultSearchBase=dc=ipk=de \ > > -a domainName=DOMAINNAME \ > > -a defaultServerList= \ > > -a attributeMap=group:userpassword=userPassword \ > > -a attributeMap=group:uniqueMember=member \ > > -a attributeMap=group:gidnumber=gidNumber \ > > -a attributeMap=passwd:gecos=cn \ > > -a attributeMap=passwd:gidnumber=gidNumber \ > > -a attributeMap=passwd:uidnumber=uidNumber \ > > -a attributeMap=passwd:uid=sAMAccountName \ > > -a attributeMap=passwd:homedirectory=unixHomeDirectory \ > > -a attributeMap=passwd:loginshell=loginShell \ > > -a attributeMap=shadow:shadowflag=shadowFlag \ > > -a attributeMap=shadow:userpassword=userPassword \ > > -a objectClassMap=group:posixGroup=group \ > > -a objectClassMap=passwd:posixAccount=user \ > > -a objectClassMap=shadow:shadowAccount=user \ > > -a serviceSearchDescriptor="passwd:" \ > > -a serviceSearchDescriptor=group: \ > > -a followReferrals=true > > > > Maybe also a restart of the smb service? > > > > Jens > > > > > -----Original Message----- > > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > > Sent: Dienstag, 27. Juni 2017 14:40 > > > To: Jens Bauernfeind > > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > Hi, > > > > > > > > > > > > Now I get can?t access domain info in the smb log and users are prompted > > to > > > enter a password when accessing the shares. :( > > > > > > > > > > > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > > Sent: Dienstag, 27. Juni 2017 09:37 > > > To: Oliver Weinmann > > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > > > > > > > Hi, > > > > > > > > > > > > I fixed this problem after executing this: > > > > > > idmap add winname:"*@" unixuser:"*" > > > > > > idmap add wingroup:"*@ " unixgroup:"*" > > > > > > svcadm restart idmap > > > > > > All new created files has now the uid and gid from the IDMU > > > > > > > > > > > > Jens > > > > > > > > > > > > From: OmniOS-discuss [mailto:omnios-discuss- > bounces at lists.omniti.com] > > > On Behalf Of Oliver Weinmann > > > Sent: Dienstag, 27. Juni 2017 08:25 > > > To: omnios-discuss > > discuss at lists.omniti.com> > > > > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > > > > > > > Hi, > > > > > > > > > > > > we are currently migrating all our data from a NetAPP system to an > OmniOS > > > sytem. > > > > > > > > > > > > The OmniOS system is joined to AD and LDAP client is configured to pull > > LDAP > > > info from AD / IDMU. This works fine. > > > > > > > > > > > > However we can?t manage to have access on folders where we have Unix > > > permissions from windows (CIFS). > > > > > > > > > > > > e.g. > > > > > > > > > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups > utest2 > > > > > > 10000 Up BCSIM De_Dt Da Lg > > > > > > > > > > > > The folder Unix has the following permissions set: > > > > > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > > > > > total 47 > > > > > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > > > > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > > > > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > > > > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > > > > > > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can > > access > > > the folder just fine via NFS. > > > > > > > > > > > > If the user utest2 tries to access this folder from windows via CIFS he > > gets > > > access denied. > > > > > > > > > > > > If I change the permissions so that other have r-x he can access the > > folder > > > but then I have no control on who can access the folder. > > > > > > > > > > > > On our NetApp system this was working fine. I assume it has to do with > the > > > IDMAP daemon using ephemeral mappings instead of pulling the > > uidnumber > > > and gidnumber from AD? > > > > > > > > > > > > I don?t want to use extended ACLs on this folder. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > Oliver Weinmann > > > Senior Unix VMWare, Storage Engineer > > > > > > Telespazio VEGA Deutschland GmbH > > > Europaplatz 5 - 64293 Darmstadt - Germany > > > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > > > oliver.weinmann at telespazio-vega.de > > > > vega.de> > > > http://www.telespazio-vega.de > > > > > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > > Darmstadt, > > > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4970 bytes Desc: not available URL: From oliver.weinmann at telespazio-vega.de Wed Jun 28 10:22:33 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Wed, 28 Jun 2017 10:22:33 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BD9878@GEDAEVW01.a.space.corp> Hi again, You're the man. This looks very promising. If I get this right the ZFS ACEs are behaving more like a (u)mask to newly created files via CIFS on folder with traditional Unix permissions. So there are really no additional ACEs required. This is perfect. E.g. If I remove all ACEs on the subfolder Unix root at omnios02:/tank/ReferenceSU/TEST/Software# chmod A- Unix/ It will leave just the default ones: root at omnios02:/tank/ReferenceSU/TEST/Software# ls -V total 1 drwxrws--- 4 tuser Up TEST de_dt Da Lg 6 Jun 28 11:42 Unix owner@:rwxp-DaARWcCos:-------:allow group@:rwxp-Da-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow Trying to access the folder Unix via CIFS works fine as user utest2 as he is a member of the " Up TEST de_dt Da Lg" group and this groups has rws unix permissions. Excellent. :) root at omnios02:/tank/ReferenceSU/TEST/Software# groups utest2 10000 Up TEST de_dt Da Lg Now I can control the access fine using the normal traditional unix permissions. If I change the group to a group that he is not a member of his access is denied. Excellent again :) root at omnios02:/tank/ReferenceSU/TEST/Software# chgrp "Up BCSIM De_dt Da Lg" Unix root at omnios02:/tank/ReferenceSU/TEST/Software# ls -al total 3 drwxr-xr-x+ 3 root root 3 Jun 27 15:03 . d---------+ 4 root root 4 Jun 27 15:04 .. drwxrws--- 4 tuser Up BCSIM De_Dt Da Lg 6 Jun 28 11:42 Unix Switching back to the "Up test ..." group and creating a file "testcifs.txt" via CIFS. root at omnios02:/tank/ReferenceSU/TEST/Software# chgrp "Up TEST De_dt Da Lg" Unix root at omnios02:/tank/ReferenceSU/TEST/Software# ls -al total 3 drwxr-xr-x+ 3 root root 3 Jun 27 15:03 . d---------+ 4 root root 4 Jun 27 15:04 .. drwxrws--- 4 tuser Up TEST de_dt Da Lg 6 Jun 28 11:42 Unix The file gets the following traditional Unix permissions: root at omnios02:/tank/ReferenceSU/TEST/Software/Unix# ls -al total 4 drwxrws--- 2 tuser Up TEST de_dt Da Lg 4 Jun 28 12:00 . drwxr-xr-x+ 3 root root 3 Jun 27 15:03 .. -rwx------+ 1 utest2 Up TEST de_dt Da Lg 14 Jun 28 12:00 testcifs.txt Only the owner can rwx. Not so good. But with your awesome chmod command applied to the Unix folder. chmod A- Unix chmod A=owner@:rwxp-DaARWcCos:df:allow,group@:rwxp-DaARWcCos:df:allow,everyone@::d f:allow Unix The permissions are just right when creating a file from CIFS: root at omnios02:/tank/ReferenceSU/TEST/Software/Unix# ls -al total 4 drwxrws---+ 3 tuser Up TEST de_dt Da Lg 4 Jun 28 12:20 . drwxr-xr-x+ 3 root root 3 Jun 27 15:03 .. drwxrws---+ 2 utest2 Up TEST de_dt Da Lg 2 Jun 28 12:20 New folder -rwxrwx---+ 1 utest2 Up TEST de_dt Da Lg 3 Jun 28 12:20 testcifs_aclset.txt root at omnios02:/tank/ReferenceSU/TEST/Software/Unix# ls -V total 2 drwxrws---+ 2 utest2 Up TEST de_dt Da Lg 2 Jun 28 12:20 New folder owner@:rwxp-DaARWcCos:fd----I:allow group@:rwxp-DaARWcCos:fd----I:allow everyone@:--------------:fd----I:allow -rwxrwx---+ 1 utest2 Up TEST de_dt Da Lg 3 Jun 28 12:20 testcifs_aclset.txt owner@:rwxp-DaARWcCos:------I:allow group@:rwxp-DaARWcCos:------I:allow everyone@:--------------:------I:allow root at omnios02:/tank/ReferenceSU/TEST/Software/Unix# This looks perfect. I will need to do some more testing. Especially with aclmode and aclinherit. But so far this could be the solution I was looking for. :) -----Original Message----- From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] Sent: Mittwoch, 28. Juni 2017 08:09 To: Oliver Weinmann Cc: omnios-discuss Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions Yeah, AD with IDMU According to this page (very old, but still the truth), you can't live without ACLs. https://mattwilson.org/blog/solaris/solaris-cifs-server-and-zfs-acls-the-pro blem/ You have to inherit the ACLs to newly created files. At first I switched to the passthrough acl properties: zfs set aclmode=passthrough tank zfs set aclinherit=passthrough tank Then you have to define an initial ACL for your datasets For this example I just assume you have the pool tank and one dataset test - first set your sticky bit chmod g+s /tank/test - then set the ACLs chmod A=owner@:rwxp-DaARWcCos:df:allow,group@:rwxp-DaARWcCos:df:allow,everyone@::d f:allow /tank/test so nearly full permission for the owner and the group, and nothing for others; all ACLs are inherited to new created files and directories [the "df"] 8<--- ls -Vd /tank/test drwxrws---+ 5 root IT 5 Jun 28 07:55 /tank/test owner@:rwxp-DaARWcCos:fd-----:allow group@:rwxp-DaARWcCos:fd-----:allow everyone@:--------------:fd-----:allow 8<--- (This inheritance doesnt apply to new datesets you create via zfs, btw) But care: When you ever doing a chmod operation or a chgrp on /tank/test (or every other dateset,), the owner,group and everyone ACEs get overwritten (according to http://docs.oracle.com/cd/E36784_01/html/E36835/gbaaz.html) 8<--- chgrp 0 /tank/test ls -Vd /tank/test drwxrws--- 5 root root 5 Jun 28 07:55 /tank/test owner@:rwxp-DaARWcCos:-------:allow group@:rwxp-Da-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow See the missing "+" and "fd"? 8<--- (This doesn't apply to folders or files) I hope this helps and I'm not telling lies here. But that is my experience with that. Jens > -----Original Message----- > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > Sent: Dienstag, 27. Juni 2017 15:21 > To: Jens Bauernfeind > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > Mine has ldap only for passwd and group. > > So on your system it really works with just having the traditional unix > permissions set. There are no ACLs in place? > > Do you have an Active Directory domain with IDMU? > > -----Original Message----- > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > Sent: Dienstag, 27. Juni 2017 15:19 > To: Oliver Weinmann > Cc: omnios-discuss > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > (owner:group:other) Unix permissions > > also r151022 > > What is your /etc/nsswitch.conf saying? > Mine has nearly everywhere "files ldap", except hosts and ipnodes. > > > -----Original Message----- > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > Sent: Dienstag, 27. Juni 2017 14:49 > > To: Jens Bauernfeind > > Cc: omnios-discuss > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > What version of omnios are you using? I'm using R151022. > > > > -----Original Message----- > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > Sent: Dienstag, 27. Juni 2017 14:47 > > To: Oliver Weinmann > > Cc: omnios-discuss > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > (owner:group:other) Unix permissions > > > > Hm, > > > > maybe I should share my ldap config. > > ldapclient -v manual \ > > -a credentialLevel=proxy \ > > -a authenticationMethod=simple \ > > -a proxyDN="cn=XXX" \ > > -a proxyPassword=SECRET \ > > -a defaultSearchBase=dc=ipk=de \ > > -a domainName=DOMAINNAME \ > > -a defaultServerList= \ > > -a attributeMap=group:userpassword=userPassword \ > > -a attributeMap=group:uniqueMember=member \ > > -a attributeMap=group:gidnumber=gidNumber \ > > -a attributeMap=passwd:gecos=cn \ > > -a attributeMap=passwd:gidnumber=gidNumber \ > > -a attributeMap=passwd:uidnumber=uidNumber \ > > -a attributeMap=passwd:uid=sAMAccountName \ > > -a attributeMap=passwd:homedirectory=unixHomeDirectory \ > > -a attributeMap=passwd:loginshell=loginShell \ > > -a attributeMap=shadow:shadowflag=shadowFlag \ > > -a attributeMap=shadow:userpassword=userPassword \ > > -a objectClassMap=group:posixGroup=group \ > > -a objectClassMap=passwd:posixAccount=user \ > > -a objectClassMap=shadow:shadowAccount=user \ > > -a serviceSearchDescriptor="passwd:" \ > > -a serviceSearchDescriptor=group: \ > > -a followReferrals=true > > > > Maybe also a restart of the smb service? > > > > Jens > > > > > -----Original Message----- > > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] > > > Sent: Dienstag, 27. Juni 2017 14:40 > > > To: Jens Bauernfeind > > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > Hi, > > > > > > > > > > > > Now I get can?t access domain info in the smb log and users are prompted > > to > > > enter a password when accessing the shares. :( > > > > > > > > > > > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] > > > Sent: Dienstag, 27. Juni 2017 09:37 > > > To: Oliver Weinmann > > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > > > > > > > Hi, > > > > > > > > > > > > I fixed this problem after executing this: > > > > > > idmap add winname:"*@" unixuser:"*" > > > > > > idmap add wingroup:"*@ " unixgroup:"*" > > > > > > svcadm restart idmap > > > > > > All new created files has now the uid and gid from the IDMU > > > > > > > > > > > > Jens > > > > > > > > > > > > From: OmniOS-discuss [mailto:omnios-discuss- > bounces at lists.omniti.com] > > > On Behalf Of Oliver Weinmann > > > Sent: Dienstag, 27. Juni 2017 08:25 > > > To: omnios-discuss > > discuss at lists.omniti.com> > > > > Subject: [OmniOS-discuss] CIFS access to a folder with traditional > > > (owner:group:other) Unix permissions > > > > > > > > > > > > Hi, > > > > > > > > > > > > we are currently migrating all our data from a NetAPP system to an > OmniOS > > > sytem. > > > > > > > > > > > > The OmniOS system is joined to AD and LDAP client is configured to pull > > LDAP > > > info from AD / IDMU. This works fine. > > > > > > > > > > > > However we can?t manage to have access on folders where we have Unix > > > permissions from windows (CIFS). > > > > > > > > > > > > e.g. > > > > > > > > > > > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: > > > > > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups > utest2 > > > > > > 10000 Up BCSIM De_Dt Da Lg > > > > > > > > > > > > The folder Unix has the following permissions set: > > > > > > > > > > > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al > > > > > > total 47 > > > > > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . > > > > > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. > > > > > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 Unix > > > > > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows > > > > > > > > > > > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can > > access > > > the folder just fine via NFS. > > > > > > > > > > > > If the user utest2 tries to access this folder from windows via CIFS he > > gets > > > access denied. > > > > > > > > > > > > If I change the permissions so that other have r-x he can access the > > folder > > > but then I have no control on who can access the folder. > > > > > > > > > > > > On our NetApp system this was working fine. I assume it has to do with > the > > > IDMAP daemon using ephemeral mappings instead of pulling the > > uidnumber > > > and gidnumber from AD? > > > > > > > > > > > > I don?t want to use extended ACLs on this folder. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > Oliver Weinmann > > > Senior Unix VMWare, Storage Engineer > > > > > > Telespazio VEGA Deutschland GmbH > > > Europaplatz 5 - 64293 Darmstadt - Germany > > > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > > > oliver.weinmann at telespazio-vega.de > > > > vega.de> > > > http://www.telespazio-vega.de > > > > > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > > Darmstadt, > > > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4970 bytes Desc: not available URL: From alka at hfg-gmuend.de Wed Jun 28 10:45:03 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Wed, 28 Jun 2017 12:45:03 +0200 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BD9828@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9828@GEDAEVW01.a.space.corp> Message-ID: > It's really a pity that it only works If I do touch the ZFS ACLs. :( > Not at all. I made several approaches years ago to replace our Windows filers with Unix/Linux systems and failed always because permission wise it was impossible to create permissions comparable to what is possible with Windows and NTFS. Solaris CIFS was the first working Unix solution. It was able to use permission inheritance on files or folders with fine granular NTFS alike permissions, SMB compatible user groups, really working "previous versions" or using Windows SID in an AD environment what makes it possible to resore a filesystem to another AD server with permissions intact. This is not a ZFS item. ZFS is a Unix filesystem relying in UID and GID. If you use SAMBA you have what you may want. The real question is therefor if you want a filer with a behaviour like a conventional Linux/Unix filer or one that behaves like Windows and ntfs. Solaris CIFS is ACL only like Windows with ntfs what gives more powerfull options than with classical Unix permissions. You must only accept that you should not set permissions via commandline (best is using a Windows client). You should know the meaning of the ZFS properties aclinherit and aclmode. Unix alike behaviours (without the inheritance question) is achieveable with the trivial ACLs owner@, group@ and everyone@ see http://docs.oracle.com/cd/E19253-01/819-5461/gbace/index.html Gea -- From jimklimov at cos.ru Wed Jun 28 11:00:08 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Wed, 28 Jun 2017 11:00:08 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> Message-ID: <5B89DFC1-091B-44DA-862E-B626937DDB21@cos.ru> On June 28, 2017 8:08:40 AM GMT+02:00, Jens Bauernfeind wrote: >Yeah, AD with IDMU > >According to this page (very old, but still the truth), you can't live >without ACLs. >https://mattwilson.org/blog/solaris/solaris-cifs-server-and-zfs-acls-the-pro >blem/ > >You have to inherit the ACLs to newly created files. >At first I switched to the passthrough acl properties: >zfs set aclmode=passthrough tank >zfs set aclinherit=passthrough tank >Then you have to define an initial ACL for your datasets > >For this example I just assume you have the pool tank and one dataset >test >- first set your sticky bit >chmod g+s /tank/test >- then set the ACLs >chmod >A=owner@:rwxp-DaARWcCos:df:allow,group@:rwxp-DaARWcCos:df:allow,everyone@::d >f:allow /tank/test >so nearly full permission for the owner and the group, and nothing for >others; all ACLs are inherited to new created files and directories >[the >"df"] >8<--- >ls -Vd /tank/test >drwxrws---+ 5 root IT 5 Jun 28 07:55 /tank/test > owner@:rwxp-DaARWcCos:fd-----:allow > group@:rwxp-DaARWcCos:fd-----:allow > everyone@:--------------:fd-----:allow >8<--- >(This inheritance doesnt apply to new datesets you create via zfs, btw) > >But care: When you ever doing a chmod operation or a chgrp on >/tank/test (or >every other dateset,), the owner,group and everyone ACEs get >overwritten >(according to >http://docs.oracle.com/cd/E36784_01/html/E36835/gbaaz.html) >8<--- >chgrp 0 /tank/test >ls -Vd /tank/test >drwxrws--- 5 root root 5 Jun 28 07:55 /tank/test > owner@:rwxp-DaARWcCos:-------:allow > group@:rwxp-Da-R-c--s:-------:allow > everyone@:------a-R-c--s:-------:allow >See the missing "+" and "fd"? >8<--- >(This doesn't apply to folders or files) > >I hope this helps and I'm not telling lies here. >But that is my experience with that. > >Jens > >> -----Original Message----- >> From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] >> Sent: Dienstag, 27. Juni 2017 15:21 >> To: Jens Bauernfeind >> Cc: omnios-discuss >> Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> (owner:group:other) Unix permissions >> >> Mine has ldap only for passwd and group. >> >> So on your system it really works with just having the traditional >unix >> permissions set. There are no ACLs in place? >> >> Do you have an Active Directory domain with IDMU? >> >> -----Original Message----- >> From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] >> Sent: Dienstag, 27. Juni 2017 15:19 >> To: Oliver Weinmann >> Cc: omnios-discuss >> Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> (owner:group:other) Unix permissions >> >> also r151022 >> >> What is your /etc/nsswitch.conf saying? >> Mine has nearly everywhere "files ldap", except hosts and ipnodes. >> >> > -----Original Message----- >> > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] >> > Sent: Dienstag, 27. Juni 2017 14:49 >> > To: Jens Bauernfeind >> > Cc: omnios-discuss >> > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > (owner:group:other) Unix permissions >> > >> > What version of omnios are you using? I'm using R151022. >> > >> > -----Original Message----- >> > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] >> > Sent: Dienstag, 27. Juni 2017 14:47 >> > To: Oliver Weinmann >> > Cc: omnios-discuss >> > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > (owner:group:other) Unix permissions >> > >> > Hm, >> > >> > maybe I should share my ldap config. >> > ldapclient -v manual \ >> > -a credentialLevel=proxy \ >> > -a authenticationMethod=simple \ >> > -a proxyDN="cn=XXX" \ >> > -a proxyPassword=SECRET \ >> > -a defaultSearchBase=dc=ipk=de \ >> > -a domainName=DOMAINNAME \ >> > -a defaultServerList= \ >> > -a attributeMap=group:userpassword=userPassword \ >> > -a attributeMap=group:uniqueMember=member \ >> > -a attributeMap=group:gidnumber=gidNumber \ >> > -a attributeMap=passwd:gecos=cn \ >> > -a attributeMap=passwd:gidnumber=gidNumber \ >> > -a attributeMap=passwd:uidnumber=uidNumber \ >> > -a attributeMap=passwd:uid=sAMAccountName \ >> > -a attributeMap=passwd:homedirectory=unixHomeDirectory \ >> > -a attributeMap=passwd:loginshell=loginShell \ >> > -a attributeMap=shadow:shadowflag=shadowFlag \ >> > -a attributeMap=shadow:userpassword=userPassword \ >> > -a objectClassMap=group:posixGroup=group \ >> > -a objectClassMap=passwd:posixAccount=user \ >> > -a objectClassMap=shadow:shadowAccount=user \ >> > -a serviceSearchDescriptor="passwd:" >\ >> > -a serviceSearchDescriptor=group: >\ >> > -a followReferrals=true >> > >> > Maybe also a restart of the smb service? >> > >> > Jens >> > >> > > -----Original Message----- >> > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] >> > > Sent: Dienstag, 27. Juni 2017 14:40 >> > > To: Jens Bauernfeind >> > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > > (owner:group:other) Unix permissions >> > > >> > > Hi, >> > > >> > > >> > > >> > > Now I get can?t access domain info in the smb log and users are >prompted >> > to >> > > enter a password when accessing the shares. :( >> > > >> > > >> > > >> > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] >> > > Sent: Dienstag, 27. Juni 2017 09:37 >> > > To: Oliver Weinmann >> > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > > (owner:group:other) Unix permissions >> > > >> > > >> > > >> > > Hi, >> > > >> > > >> > > >> > > I fixed this problem after executing this: >> > > >> > > idmap add winname:"*@" unixuser:"*" >> > > >> > > idmap add wingroup:"*@ " unixgroup:"*" >> > > >> > > svcadm restart idmap >> > > >> > > All new created files has now the uid and gid from the IDMU >> > > >> > > >> > > >> > > Jens >> > > >> > > >> > > >> > > From: OmniOS-discuss [mailto:omnios-discuss- >> bounces at lists.omniti.com] >> > > On Behalf Of Oliver Weinmann >> > > Sent: Dienstag, 27. Juni 2017 08:25 >> > > To: omnios-discuss > > > discuss at lists.omniti.com> > >> > > Subject: [OmniOS-discuss] CIFS access to a folder with >traditional >> > > (owner:group:other) Unix permissions >> > > >> > > >> > > >> > > Hi, >> > > >> > > >> > > >> > > we are currently migrating all our data from a NetAPP system to >an >> OmniOS >> > > sytem. >> > > >> > > >> > > >> > > The OmniOS system is joined to AD and LDAP client is configured >to >pull >> > LDAP >> > > info from AD / IDMU. This works fine. >> > > >> > > >> > > >> > > However we can?t manage to have access on folders where we have >Unix >> > > permissions from windows (CIFS). >> > > >> > > >> > > >> > > e.g. >> > > >> > > >> > > >> > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: >> > > >> > > >> > > >> > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups >> utest2 >> > > >> > > 10000 Up BCSIM De_Dt Da Lg >> > > >> > > >> > > >> > > The folder Unix has the following permissions set: >> > > >> > > >> > > >> > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al >> > > >> > > total 47 >> > > >> > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . >> > > >> > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. >> > > >> > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 >Unix >> > > >> > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows >> > > >> > > >> > > >> > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can >> > access >> > > the folder just fine via NFS. >> > > >> > > >> > > >> > > If the user utest2 tries to access this folder from windows via >CIFS >he >> > gets >> > > access denied. >> > > >> > > >> > > >> > > If I change the permissions so that other have r-x he can access >the >> > folder >> > > but then I have no control on who can access the folder. >> > > >> > > >> > > >> > > On our NetApp system this was working fine. I assume it has to do >with >> the >> > > IDMAP daemon using ephemeral mappings instead of pulling the >> > uidnumber >> > > and gidnumber from AD? >> > > >> > > >> > > >> > > I don?t want to use extended ACLs on this folder. >> > > >> > > >> > > >> > > Any ideas? >> > > >> > > >> > > >> > > >> > > >> > > Oliver Weinmann >> > > Senior Unix VMWare, Storage Engineer >> > > >> > > Telespazio VEGA Deutschland GmbH >> > > Europaplatz 5 - 64293 Darmstadt - Germany >> > > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 >> > > oliver.weinmann at telespazio-vega.de >> > > > > vega.de> >> > > http://www.telespazio-vega.de >> > > >> > > Registered office/Sitz: Darmstadt, Register >court/Registergericht: >> > Darmstadt, >> > > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller Just one addition quickly comes to mind: when dealing with ACLs and similar advanced features, and if your setup includes GNU userland programs, be sure to use illumos /bin/chmod (perhaps explicitly). Jim -- Typos courtesy of K-9 Mail on my Redmi Android From oliver.weinmann at telespazio-vega.de Wed Jun 28 12:18:53 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Wed, 28 Jun 2017 12:18:53 +0000 Subject: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions In-Reply-To: <5B89DFC1-091B-44DA-862E-B626937DDB21@cos.ru> References: <767138E0D064A148B03FE8EC1E9325A20125BD83C8@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9514@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD9542@GEDAEVW01.a.space.corp> <767138E0D064A148B03FE8EC1E9325A20125BD956A@GEDAEVW01.a.space.corp> <5B89DFC1-091B-44DA-862E-B626937DDB21@cos.ru> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BD98FA@GEDAEVW01.a.space.corp> Hi, Thanks for pointing this out. Basically I would do the chmod on a Linux system where NFS share is mounted as root. Now that I have this working on my test system I have lots of problems on my production system. I can join it to AD but I get lots of errors like this: gedaspw02.a.space.corp: additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Client not found in Kerberos database) smbd.info: logon[A\someuser]: CANT_ACCESS_DOMAIN_INFO smbd.info: logon[A\someuser]: LOGON_FAILURE I checked all possible settings and compared them to my test system but can't find any difference. The only difference is that the production system was upgraded twice from 1510xx to 1510xx to 151022. I even deleted the computer object in AD and rejoined the domain but still the same errors occur. Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller-----Original Message----- From: Jim Klimov [mailto:jimklimov at cos.ru] Sent: Mittwoch, 28. Juni 2017 13:00 To: omnios-discuss at lists.omniti.com; Jens Bauernfeind ; Oliver Weinmann Cc: omnios-discuss Subject: Re: [OmniOS-discuss] CIFS access to a folder with traditional (owner:group:other) Unix permissions On June 28, 2017 8:08:40 AM GMT+02:00, Jens Bauernfeind wrote: >Yeah, AD with IDMU > >According to this page (very old, but still the truth), you can't live >without ACLs. >https://mattwilson.org/blog/solaris/solaris-cifs-server-and-zfs-acls-th >e-pro >blem/ > >You have to inherit the ACLs to newly created files. >At first I switched to the passthrough acl properties: >zfs set aclmode=passthrough tank >zfs set aclinherit=passthrough tank >Then you have to define an initial ACL for your datasets > >For this example I just assume you have the pool tank and one dataset >test >- first set your sticky bit >chmod g+s /tank/test >- then set the ACLs >chmod >A=owner@:rwxp-DaARWcCos:df:allow,group@:rwxp-DaARWcCos:df:allow,everyon >e@::d >f:allow /tank/test >so nearly full permission for the owner and the group, and nothing for >others; all ACLs are inherited to new created files and directories >[the "df"] >8<--- >ls -Vd /tank/test >drwxrws---+ 5 root IT 5 Jun 28 07:55 /tank/test > owner@:rwxp-DaARWcCos:fd-----:allow > group@:rwxp-DaARWcCos:fd-----:allow > everyone@:--------------:fd-----:allow >8<--- >(This inheritance doesnt apply to new datesets you create via zfs, btw) > >But care: When you ever doing a chmod operation or a chgrp on >/tank/test (or every other dateset,), the owner,group and everyone ACEs >get overwritten (according to >http://docs.oracle.com/cd/E36784_01/html/E36835/gbaaz.html) >8<--- >chgrp 0 /tank/test >ls -Vd /tank/test >drwxrws--- 5 root root 5 Jun 28 07:55 /tank/test > owner@:rwxp-DaARWcCos:-------:allow > group@:rwxp-Da-R-c--s:-------:allow > everyone@:------a-R-c--s:-------:allow >See the missing "+" and "fd"? >8<--- >(This doesn't apply to folders or files) > >I hope this helps and I'm not telling lies here. >But that is my experience with that. > >Jens > >> -----Original Message----- >> From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] >> Sent: Dienstag, 27. Juni 2017 15:21 >> To: Jens Bauernfeind >> Cc: omnios-discuss >> Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> (owner:group:other) Unix permissions >> >> Mine has ldap only for passwd and group. >> >> So on your system it really works with just having the traditional >unix >> permissions set. There are no ACLs in place? >> >> Do you have an Active Directory domain with IDMU? >> >> -----Original Message----- >> From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] >> Sent: Dienstag, 27. Juni 2017 15:19 >> To: Oliver Weinmann >> Cc: omnios-discuss >> Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> (owner:group:other) Unix permissions >> >> also r151022 >> >> What is your /etc/nsswitch.conf saying? >> Mine has nearly everywhere "files ldap", except hosts and ipnodes. >> >> > -----Original Message----- >> > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] >> > Sent: Dienstag, 27. Juni 2017 14:49 >> > To: Jens Bauernfeind >> > Cc: omnios-discuss >> > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > (owner:group:other) Unix permissions >> > >> > What version of omnios are you using? I'm using R151022. >> > >> > -----Original Message----- >> > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] >> > Sent: Dienstag, 27. Juni 2017 14:47 >> > To: Oliver Weinmann >> > Cc: omnios-discuss >> > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > (owner:group:other) Unix permissions >> > >> > Hm, >> > >> > maybe I should share my ldap config. >> > ldapclient -v manual \ >> > -a credentialLevel=proxy \ >> > -a authenticationMethod=simple \ >> > -a proxyDN="cn=XXX" \ >> > -a proxyPassword=SECRET \ >> > -a defaultSearchBase=dc=ipk=de \ >> > -a domainName=DOMAINNAME \ >> > -a defaultServerList= \ -a >> > attributeMap=group:userpassword=userPassword \ -a >> > attributeMap=group:uniqueMember=member \ -a >> > attributeMap=group:gidnumber=gidNumber \ -a >> > attributeMap=passwd:gecos=cn \ -a >> > attributeMap=passwd:gidnumber=gidNumber \ -a >> > attributeMap=passwd:uidnumber=uidNumber \ -a >> > attributeMap=passwd:uid=sAMAccountName \ -a >> > attributeMap=passwd:homedirectory=unixHomeDirectory \ -a >> > attributeMap=passwd:loginshell=loginShell \ -a >> > attributeMap=shadow:shadowflag=shadowFlag \ -a >> > attributeMap=shadow:userpassword=userPassword \ -a >> > objectClassMap=group:posixGroup=group \ -a >> > objectClassMap=passwd:posixAccount=user \ -a >> > objectClassMap=shadow:shadowAccount=user \ -a >> > serviceSearchDescriptor="passwd:" >\ >> > -a serviceSearchDescriptor=group: >\ >> > -a followReferrals=true >> > >> > Maybe also a restart of the smb service? >> > >> > Jens >> > >> > > -----Original Message----- >> > > From: Oliver Weinmann [mailto:oliver.weinmann at telespazio-vega.de] >> > > Sent: Dienstag, 27. Juni 2017 14:40 >> > > To: Jens Bauernfeind >> > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > > (owner:group:other) Unix permissions >> > > >> > > Hi, >> > > >> > > >> > > >> > > Now I get can?t access domain info in the smb log and users are >prompted >> > to >> > > enter a password when accessing the shares. :( >> > > >> > > >> > > >> > > From: Jens Bauernfeind [mailto:bauernfeind at ipk-gatersleben.de] >> > > Sent: Dienstag, 27. Juni 2017 09:37 >> > > To: Oliver Weinmann >> > > Subject: RE: [OmniOS-discuss] CIFS access to a folder with >traditional >> > > (owner:group:other) Unix permissions >> > > >> > > >> > > >> > > Hi, >> > > >> > > >> > > >> > > I fixed this problem after executing this: >> > > >> > > idmap add winname:"*@" unixuser:"*" >> > > >> > > idmap add wingroup:"*@ " unixgroup:"*" >> > > >> > > svcadm restart idmap >> > > >> > > All new created files has now the uid and gid from the IDMU >> > > >> > > >> > > >> > > Jens >> > > >> > > >> > > >> > > From: OmniOS-discuss [mailto:omnios-discuss- >> bounces at lists.omniti.com] >> > > On Behalf Of Oliver Weinmann >> > > Sent: Dienstag, 27. Juni 2017 08:25 >> > > To: omnios-discuss > > > discuss at lists.omniti.com> > >> > > Subject: [OmniOS-discuss] CIFS access to a folder with >traditional >> > > (owner:group:other) Unix permissions >> > > >> > > >> > > >> > > Hi, >> > > >> > > >> > > >> > > we are currently migrating all our data from a NetAPP system to >an >> OmniOS >> > > sytem. >> > > >> > > >> > > >> > > The OmniOS system is joined to AD and LDAP client is configured >to >pull >> > LDAP >> > > info from AD / IDMU. This works fine. >> > > >> > > >> > > >> > > However we can?t manage to have access on folders where we have >Unix >> > > permissions from windows (CIFS). >> > > >> > > >> > > >> > > e.g. >> > > >> > > >> > > >> > > the user utest2 is member of the goup ?Up BCSIM De_Dt Da Lg?: >> > > >> > > >> > > >> > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# groups >> utest2 >> > > >> > > 10000 Up BCSIM De_Dt Da Lg >> > > >> > > >> > > >> > > The folder Unix has the following permissions set: >> > > >> > > >> > > >> > > root at omnios01:/hgst4u60/ReferenceAC/BCSIM/Software# ls -al >> > > >> > > total 47 >> > > >> > > d---------+ 4 root 2147483653 4 Apr 25 05:37 . >> > > >> > > d---------+ 4 root 2147483659 4 Apr 25 05:35 .. >> > > >> > > drwxrws--- 9 bcsim Up BCSIM De_Dt Da Lg 11 Mar 9 10:40 >Unix >> > > >> > > d---------+ 6 root 2147483653 6 Apr 25 05:37 Windows >> > > >> > > >> > > >> > > so User bcsim and all members of group ?Up BCSIM De_Dt Da Lg? can >> > access >> > > the folder just fine via NFS. >> > > >> > > >> > > >> > > If the user utest2 tries to access this folder from windows via >CIFS >he >> > gets >> > > access denied. >> > > >> > > >> > > >> > > If I change the permissions so that other have r-x he can access >the >> > folder >> > > but then I have no control on who can access the folder. >> > > >> > > >> > > >> > > On our NetApp system this was working fine. I assume it has to do >with >> the >> > > IDMAP daemon using ephemeral mappings instead of pulling the >> > uidnumber >> > > and gidnumber from AD? >> > > >> > > >> > > >> > > I don?t want to use extended ACLs on this folder. >> > > >> > > >> > > >> > > Any ideas? >> > > >> > > >> > > >> > > >> > > >> > > Oliver Weinmann >> > > Senior Unix VMWare, Storage Engineer >> > > >> > > Telespazio VEGA Deutschland GmbH >> > > Europaplatz 5 - 64293 Darmstadt - Germany >> > > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 >> > > oliver.weinmann at telespazio-vega.de >> > > > > vega.de> >> > > http://www.telespazio-vega.de >> > > >> > > Registered office/Sitz: Darmstadt, Register >court/Registergericht: >> > Darmstadt, >> > > HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller Just one addition quickly comes to mind: when dealing with ACLs and similar advanced features, and if your setup includes GNU userland programs, be sure to use illumos /bin/chmod (perhaps explicitly). Jim -- Typos courtesy of K-9 Mail on my Redmi Android From oliver.weinmann at telespazio-vega.de Thu Jun 29 06:29:59 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 29 Jun 2017 06:29:59 +0000 Subject: [OmniOS-discuss] Bug ? Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> Hi, What if I would like to report a possible bug? Do I need a valid support contract for this? Best Regards, Oliver [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From henson at acm.org Thu Jun 29 06:50:48 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 28 Jun 2017 23:50:48 -0700 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> Message-ID: <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> Unfortunately OmniTI no longer offers support contracts for OmniOS. We actually have a contract that's still good through I think November, but given their main support engineer is no longer with the company and the OS appears to be in limbo at the moment I'm not sure what good that does us ;). If you think you've found a bug, your best bet at the moment is to just report it to this list, possibly to the upstream illumos developer list if you can detail it reasonably technically, and perhaps open an issue on the illumos issue tracker. > On Jun 28, 2017, at 11:29 PM, Oliver Weinmann wrote: > > Hi, > > What if I would like to report a possible bug? Do I need a valid support contract for this? > > Best Regards, > Oliver > > > > > Oliver Weinmann > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > _______________________________________________ > 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 oliver.weinmann at telespazio-vega.de Thu Jun 29 07:14:29 2017 From: oliver.weinmann at telespazio-vega.de (Oliver Weinmann) Date: Thu, 29 Jun 2017 07:14:29 +0000 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> Message-ID: <767138E0D064A148B03FE8EC1E9325A20125BE86A9@GEDAEVW01.a.space.corp> Ohh that is bad news. I have a productions system that somehow fails to join AD and I don?t know what is causing this. We had a similar issue on our nexenta system and they provided us a patch that solved it. Idmap: additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Client not found in Kerberos database) adutils: ldap_lookup_init failed [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png] Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller From: Paul B. Henson [mailto:henson at acm.org] Sent: Donnerstag, 29. Juni 2017 08:51 To: Oliver Weinmann Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Bug ? Unfortunately OmniTI no longer offers support contracts for OmniOS. We actually have a contract that's still good through I think November, but given their main support engineer is no longer with the company and the OS appears to be in limbo at the moment I'm not sure what good that does us ;). If you think you've found a bug, your best bet at the moment is to just report it to this list, possibly to the upstream illumos developer list if you can detail it reasonably technically, and perhaps open an issue on the illumos issue tracker. On Jun 28, 2017, at 11:29 PM, Oliver Weinmann > wrote: Hi, What if I would like to report a possible bug? Do I need a valid support contract for this? Best Regards, Oliver Oliver Weinmann Senior Unix VMWare, Storage Engineer Telespazio VEGA Deutschland GmbH Europaplatz 5 - 64293 Darmstadt - Germany Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 oliver.weinmann at telespazio-vega.de http://www.telespazio-vega.de Registered office/Sitz: Darmstadt, Register court/Registergericht: Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller _______________________________________________ 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: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png URL: From alka at hfg-gmuend.de Thu Jun 29 07:33:00 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Thu, 29 Jun 2017 09:33:00 +0200 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> Message-ID: Unless there are news regarding OmniOS my stance is - OmniOS 151022 is a freeze of current Illumos + LX. At the moment it is the most stable and feature rich free Illumos general use server distribution with the addition LX zones. As there is no repo and development outside OmniTi it is freezed. There are no signs from OmniTi to add any fixes. As packages are signed it does not work outside OmniTi. As OmniOS 151023 is identical without signed packages a community based repo based on it with possible fixes as 151022ce (community edition) is a suggestion (but sadly I am not an OS developer). Without LX and a former OmniOS alike support option available you can move to OpenIndiana as a 1:1 replacement. OpenIndiana (current is 2017.04) is more or less pure Illumos + an optional GUI + a lot of services in the repo. OpenIndiana is the idea to continue OpenSolaris. The OpenIndiana textedition is nearly identical to OmniOS beside LX. There is also a GUI option with Mate. If you avoid the bunch of extra services, media tools and office tools its a very stable option, just like OmniOS is/was. As there is no long term stable with backporting fixes you can use a snapshot like the 2017.04 and update single packages on OpenIndiana when needed. A pkg update gives you the whole newest Illumos similar to OmniOS bloody. Like OmniOS OpenIndiana offers a new snapshot + iso every 6 months. If there are bugs fixed in Illumos you get them on OI. - You can report bugs regarding the distribution to the OpenIndiana list. Bugs that are related to core Illumos functionalities (OS, ZFS, drivers, core services like iSCSI, NFS, SMB) should be reported to the Illumos list optionally as an issue at https://www.illumos.org/issues (was the same with OmniOS). They get fixed there like it was with OmniOS. setup of the different OI distributions http://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf Gea @napp-it.org Am 29.06.2017 um 08:50 schrieb Paul B. Henson: > Unfortunately OmniTI no longer offers support contracts for OmniOS. We > actually have a contract that's still good through I think November, > but given their main support engineer is no longer with the company > and the OS appears to be in limbo at the moment I'm not sure what good > that does us ;). > > If you think you've found a bug, your best bet at the moment is to > just report it to this list, possibly to the upstream illumos > developer list if you can detail it reasonably technically, and > perhaps open an issue on the illumos issue tracker. > > On Jun 28, 2017, at 11:29 PM, Oliver Weinmann > > wrote: > >> Hi, >> >> What if I would like to report a possible bug? Do I need a valid >> support contract for this? >> >> Best Regards, >> >> Oliver >> >> >> >> *Oliver Weinmann* >> Senior Unix VMWare, Storage Engineer >> >> Telespazio VEGA Deutschland GmbH >> Europaplatz 5 - 64293 Darmstadt - Germany >> Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 >> oliver.weinmann at telespazio-vega.de >> >> http://www.telespazio-vega.de >> >> Registered office/Sitz: Darmstadt, Register court/Registergericht: >> Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller >> >> _______________________________________________ >> 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.o -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Thu Jun 29 20:07:10 2017 From: henson at acm.org (Paul B. Henson) Date: Thu, 29 Jun 2017 13:07:10 -0700 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BE86A9@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <767138E0D064A148B03FE8EC1E9325A20125BE86A9@GEDAEVW01.a.space.corp> Message-ID: <276701d2f113$4ae3ee50$e0abcaf0$@acm.org> > From: Oliver Weinmann > Sent: Thursday, June 29, 2017 12:14 AM > > Ohh that is bad news. Yes, it was quite disappointing :(, I really liked OmniOS. > I have a productions system that somehow fails to join AD and I don?t know > what is causing this. We had a similar issue on our nexenta system and they > provided us a patch that solved it. How recently was that? There are nexenta people on this list, but more so on the illumos developer list, you might be able to get more details on specifically what that patch involved. We currently use samba for CIFS under OmniOS as we need CIFS to hit AD and NFSv4 to use mit kerberos and currently the in kernel CIFS server won't do that; but in past testing we were able to connect the kernel CIFS server to AD without issue. From henson at acm.org Thu Jun 29 20:12:59 2017 From: henson at acm.org (Paul B. Henson) Date: Thu, 29 Jun 2017 13:12:59 -0700 Subject: [OmniOS-discuss] Bug ? In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> Message-ID: <277101d2f114$1ae1a0c0$50a4e240$@acm.org> > From: Guenther Alka > Sent: Thursday, June 29, 2017 12:33 AM > > There are no signs from OmniTi to add any fixes. An OmniTI person posted an intention to back port security fixes to r151022 for one year, although I'm not sure whether that was under the auspices of OmniTI employment or just on his personal time. So far though, there have been no new commits in the r151022 repo since Dan's last one on 5/10.. From info at houseofancients.nl Thu Jun 29 20:30:49 2017 From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..) Date: Thu, 29 Jun 2017 20:30:49 +0000 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <277101d2f114$1ae1a0c0$50a4e240$@acm.org> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <277101d2f114$1ae1a0c0$50a4e240$@acm.org> Message-ID: <04B0A5C1206D824F8D310C5B3DB28CC920270706@vEX01.mindstorm-internet.local> Hi All, With pain in my heart, i fear OmniOs has started it's slow descent to death :-( -----Oorspronkelijk bericht----- Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Namens Paul B. Henson Verzonden: donderdag 29 juni 2017 22:13 Aan: 'Guenther Alka' ; omnios-discuss at lists.omniti.com Onderwerp: Re: [OmniOS-discuss] Bug ? > From: Guenther Alka > Sent: Thursday, June 29, 2017 12:33 AM > > There are no signs from OmniTi to add any fixes. An OmniTI person posted an intention to back port security fixes to r151022 for one year, although I'm not sure whether that was under the auspices of OmniTI employment or just on his personal time. So far though, there have been no new commits in the r151022 repo since Dan's last one on 5/10.. _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ...:: House of Ancients ::... American Staffordshire Terriers +31-628-161-350 +31-614-198-389 Het Perk 48 4903 RB Oosterhout Netherlands www.houseofancients.nl From davide.poletto at gmail.com Thu Jun 29 20:42:56 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 29 Jun 2017 22:42:56 +0200 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <04B0A5C1206D824F8D310C5B3DB28CC920270706@vEX01.mindstorm-internet.local> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <277101d2f114$1ae1a0c0$50a4e240$@acm.org> <04B0A5C1206D824F8D310C5B3DB28CC920270706@vEX01.mindstorm-internet.local> Message-ID: The more I think *how fast* that's (supposedly) happening the more I feel shocked. On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients Amstafs ::.." wrote: Hi All, With pain in my heart, i fear OmniOs has started it's slow descent to death :-( -----Oorspronkelijk bericht----- Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Namens Paul B. Henson Verzonden: donderdag 29 juni 2017 22:13 Aan: 'Guenther Alka' ; omnios-discuss at lists.omniti.com Onderwerp: Re: [OmniOS-discuss] Bug ? > From: Guenther Alka > Sent: Thursday, June 29, 2017 12:33 AM > > There are no signs from OmniTi to add any fixes. An OmniTI person posted an intention to back port security fixes to r151022 for one year, although I'm not sure whether that was under the auspices of OmniTI employment or just on his personal time. So far though, there have been no new commits in the r151022 repo since Dan's last one on 5/10.. _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ...:: House of Ancients ::... American Staffordshire Terriers +31-628-161-350 +31-614-198-389 Het Perk 48 4903 RB Oosterhout Netherlands www.houseofancients.nl _______________________________________________ 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 2232491716 at qq.com Fri Jun 30 16:53:04 2017 From: 2232491716 at qq.com (=?ISO-8859-1?B?QXJpZXM=?=) Date: Sat, 1 Jul 2017 00:53:04 +0800 Subject: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 Message-ID: Hello, I noticed that the r151022 starts to support the Dell H330 via mpt_sas driver. So I installed the r151022 fresh on my Dell T630 server with H330 as a VM on ESXi. The H330 was PCI-E passthrough with 8x 7k2 disks in raid z2. However when I ran the command dmesg | grep sas, it seems that the mr_sas was used for the H330 adapter which is just as same as the r151020 and r151014 version. I also discovered that the disk performance was worse than the r151020. To compare, I ran all the tests via napp-it filebench. For example, for the fivestreamwrite test, the result of r151020 and r151014 is around 1100mb/s, but the r151022 only shows 650mb/s. I tried multiple combinations like creating the pool in one version and import into another version. The issue seems not related to the creation of the pool but the version which runs the pool. Did I miss something in the setup that leads the H330 to run with the wrong driver? Could you please give me some advices? Thank you in advance. Best regards, Aries -------------- next part -------------- An HTML attachment was scrubbed... URL: From alka at hfg-gmuend.de Fri Jun 30 19:34:07 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Fri, 30 Jun 2017 21:34:07 +0200 Subject: [OmniOS-discuss] Dell H330 and mpt_sas on r151022 In-Reply-To: References: Message-ID: <09d0dbec-20e9-d1d7-68ef-6dce71515a8b@hfg-gmuend.de> The driver is related to the firmware. I suppose you are on an IR/Raid firmware. The better one would be a raidless and often faster IT firmware (mpt_sas). But I cannot say if its available from Dell or if the one from LSI is working. Gea @napp-it.org Am 30.06.2017 um 18:53 schrieb Aries: > Hello, > > I noticed that the r151022 starts to support the Dell H330 via mpt_sas > driver. So I installed the r151022 fresh on my Dell T630 server with > H330 as a VM on ESXi. The H330 was PCI-E passthrough with 8x 7k2 disks > in raid z2. > > However when I ran the command dmesg | grep sas, it seems that the > mr_sas was used for the H330 adapter which is just as same as the > r151020 and r151014 version. > > I also discovered that the disk performance was worse than the > r151020. To compare, I ran all the tests via napp-it filebench. For > example, for the fivestreamwrite test, the result of r151020 and > r151014 is around 1100mb/s, but the r151022 only shows 650mb/s. I > tried multiple combinations like creating the pool in one version and > import into another version. The issue seems not related to the > creation of the pool but the version which runs the pool. > > Did I miss something in the setup that leads the H330 to run with the > wrong driver? Could you please give me some advices? Thank you in advance. > > Best regards, > Aries > > > _______________________________________________ > 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 aurelien.larcher at gmail.com Fri Jun 30 23:02:30 2017 From: aurelien.larcher at gmail.com (=?UTF-8?Q?Aur=C3=A9lien_Larcher?=) Date: Sat, 1 Jul 2017 01:02:30 +0200 Subject: [OmniOS-discuss] Bug ? In-Reply-To: References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <277101d2f114$1ae1a0c0$50a4e240$@acm.org> <04B0A5C1206D824F8D310C5B3DB28CC920270706@vEX01.mindstorm-internet.local> Message-ID: I guess one should remind the little elves of the magical forest that they need to take over the maintenance, they were quite busy with Midsummer apparently. Otherwise, basically Guenther's advice is the way to go: - for illumos specific issues: https://www.illumos.org/issues, - for software package bugs we could look at it in OpenIndiana and someone could backport the fix to OmniOS afterwards (when infrastructure is fixed). I hoped that we could have a virtuous relationship with OpenIndiana Hipster acting as a "bloody" and OmniOS continuing as a stable subset, similarly to the current scheme (also benefiting from the current Hipster CI setup to avoid losing momentum). There is apparently no interest following the discussion which was initiated right after the announcement, this is a bit disappointing. I hope that people will join forces to consolidate the landscape of community-supported illumos distros. At some point one needs to stop talking theory and tragedy, there are pragmatic solutions to implement: there are infrastructures in place in both OI and OmniOS-land, there are overall directions and goals in both (rolling dev vs stable), there is a solid release engineering practice in OmniOS, it does not seem like we swim in complete abstraction. Contributing software packages can be easy, the difficulty seems to get people to figure out that maintaining even one package is a meaningful contribution. (I maintain a bunch of packages for OpenIndiana and I do not work in IT) Kind regards, ? Jeudi 29 juin 2017, Davide Poletto a ?crit : > The more I think *how fast* that's (supposedly) happening the more I feel > shocked. > > On Jun 29, 2017 10:33 PM, "Floris van Essen ..:: House of Ancients Amstafs > ::.." wrote: > > Hi All, > > With pain in my heart, i fear OmniOs has started it's slow descent to death > :-( > > > > -----Oorspronkelijk bericht----- > Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Namens > Paul B. Henson > Verzonden: donderdag 29 juni 2017 22:13 > Aan: 'Guenther Alka' ; omnios-discuss at lists.omniti.com > Onderwerp: Re: [OmniOS-discuss] Bug ? > > > From: Guenther Alka > > Sent: Thursday, June 29, 2017 12:33 AM > > > > There are no signs from OmniTi to add any fixes. > > An OmniTI person posted an intention to back port security fixes to r151022 > for one year, although I'm not sure whether that was under the auspices of > OmniTI employment or just on his personal time. So far though, there have > been no new commits in the r151022 repo since Dan's last one on 5/10.. > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ...:: House of Ancients ::... > American Staffordshire Terriers > > +31-628-161-350 > +31-614-198-389 > Het Perk 48 > 4903 RB > Oosterhout > Netherlands > www.houseofancients.nl > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -- Thanks for sailing Jolla :) From miniflowtrader at gmail.com Fri Jun 30 23:36:52 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Fri, 30 Jun 2017 23:36:52 +0000 Subject: [OmniOS-discuss] Bug ? In-Reply-To: <767138E0D064A148B03FE8EC1E9325A20125BE86A9@GEDAEVW01.a.space.corp> References: <767138E0D064A148B03FE8EC1E9325A20125BE7679@GEDAEVW01.a.space.corp> <6B493742-4EFF-4E75-83F5-E4B6E63EE99F@acm.org> <767138E0D064A148B03FE8EC1E9325A20125BE86A9@GEDAEVW01.a.space.corp> Message-ID: Is it going to be FreeBSD or Linux? On Thu, Jun 29, 2017 at 3:16 AM Oliver Weinmann < oliver.weinmann at telespazio-vega.de> wrote: > Ohh that is bad news. > > > > I have a productions system that somehow fails to join AD and I don?t know > what is causing this. We had a similar issue on our nexenta system and > they provided us a patch that solved it. > > > > Idmap: > > > > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Client not found in > Kerberos database) > > adutils: ldap_lookup_init failed > > > > > > > > > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > *From:* Paul B. Henson [mailto:henson at acm.org] > *Sent:* Donnerstag, 29. Juni 2017 08:51 > *To:* Oliver Weinmann > *Cc:* omnios-discuss > *Subject:* Re: [OmniOS-discuss] Bug ? > > > > Unfortunately OmniTI no longer offers support contracts for OmniOS. We > actually have a contract that's still good through I think November, but > given their main support engineer is no longer with the company and the OS > appears to be in limbo at the moment I'm not sure what good that does us ;). > > > > If you think you've found a bug, your best bet at the moment is to just > report it to this list, possibly to the upstream illumos developer list if > you can detail it reasonably technically, and perhaps open an issue on the > illumos issue tracker. > > > On Jun 28, 2017, at 11:29 PM, Oliver Weinmann < > oliver.weinmann at telespazio-vega.de> wrote: > > Hi, > > > > What if I would like to report a possible bug? Do I need a valid support > contract for this? > > > > Best Regards, > > Oliver > > > > > > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinmann at telespazio-vega.de > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Gesch?ftsf?hrer: Sigmar Keller > > _______________________________________________ > 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: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png Type: image/png Size: 7535 bytes Desc: not available URL: