From paladinemishakal at gmail.com Tue Feb 6 05:13:43 2018 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Tue, 6 Feb 2018 13:13:43 +0800 Subject: [OmniOS-discuss] Dell PowerEdge servers Message-ID: Hi All, I am looking at the following Dell PowerEdge server 1. R530 - Intel Xeon E5-2600v4 processor - Intel C610 chipset - PERC H330 - On-board Broadcom 5720 Quad Port 1Gb 2. R540 - Intel Xeon Scalable processor - PERC H330 - On-board Broadcom 5720 Dual Port 1Gb I would like to know if OmniOS R151014 is supported to run on these machine? Another way will be to run ESXi 6.0 on the server and then install a VM to run OmniOS. Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From groenveld at acm.org Tue Feb 6 13:43:37 2018 From: groenveld at acm.org (John D Groenveld) Date: Tue, 06 Feb 2018 08:43:37 -0500 Subject: [OmniOS-discuss] Dell PowerEdge servers In-Reply-To: Your message of "Tue, 06 Feb 2018 13:13:43 +0800." References: Message-ID: <201802061343.w16Dhbpo022852@groenveld.us> In message , Lawrence Giam writes: >I am looking at the following Dell PowerEdge server >1. R530 > - Intel Xeon E5-2600v4 processor > - Intel C610 chipset > - PERC H330 > - On-board Broadcom 5720 Quad Port 1Gb >2. R540 > - Intel Xeon Scalable processor > - PERC H330 > - On-board Broadcom 5720 Dual Port 1Gb Ask Dell to quote you the HBA330 which is the LSI SAS3008 HBA instead of the PERC. It will save you a few dollars and headaches with the RAID. The Broadcom 5720 is supported by bge(7D) John groenveld at acm.org From an3s.annema at gmail.com Tue Feb 6 20:27:43 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Tue, 6 Feb 2018 21:27:43 +0100 Subject: [OmniOS-discuss] Request advise on pool upgrade Message-ID: Hi guys, Could you please give me some advise on the best way to increase the capacity on my home server (running OmniOS obviously...)? About four years ago I started designing and building my home storage server based on a "Coolermaster Stacker" tower case by retrofitting into it three Norco SS-500 and one SS-300 hotswap modules, for a total of 18 hard drives. With this number of drive bays available, I choose to go for RAIDZ2: three vdevs of six drives each. Back in 2014, I started with only one vdev of six 4TB WD40EFRX drives. About a year later, in early 2015, I put another six of those drives in and expanded the pool. It has been humming happily ever since. Awesome. Over time however, the used pool capacity has now gone up to 86%. It's time to expand again. I see a number of possible ways to do so: 1. Get another six 4TB WD40EFRX's and fill the last open bays, adding a 3rd vdev (capacity +50%). Pros: these drives are cheap nowadays, much cheaper than they were three or four years ago. Cons: six extra spindles will increase electricity cost. 2. Get six 8TB WD80EFZX's and fill the last open bays, adding a 3rd vdev (capacity +100%). Pros: huge capacity increase. Cons: higher upgrade cost than option 1 (due to more expensive drives). Six extra spindles will increase electricity cost. 3. Get six 8TB WD80EFZX's and *replace* the first vdev with bigger disks (capacity +50%). Pros: amount of spindles doesn't change and thus electricity cost will more or less remain the same. Replaced drives can be utilized elsewhere, e.g. for offline pool-backups. Cons: higher upgrade cost than option 1 (due to more expensive drives). The first question that comes to mind for option 2 and 3: are there any disadvantages to creating a pool out of different capacity drives? The drives per vdev are identical, it's just the vdevs within the pool that aren't. Right now I am leaning towards options 2 or 3, with maybe a little preference for option 3, I think. Any thoughts you guys can share on this matter? Would appreciate it. Thanks! Regards, Andries -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Wed Feb 7 00:02:07 2018 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 6 Feb 2018 18:02:07 -0600 (CST) Subject: [OmniOS-discuss] Request advise on pool upgrade In-Reply-To: References: Message-ID: On Tue, 6 Feb 2018, Andries Annema wrote: > > Right now I am leaning towards options 2 or 3, with maybe a little preference > for option 3, I think. > > Any thoughts you guys can share on this matter? Would appreciate it. Thanks! Since your pool is already excessively full, adding a new vdev would result in most of the freshly-written data being written there. This would result in reduced performance as compared to uniformly available space in the vdevs. There are things you can do after adding another vdev to rebalance the data across the vdevs. Smaller size disks are better from a recovery/resilver standpoint. More disks are better from a performance standpoint. Replacing a drive with 8TB of data would take a very long time. 4TB disks are already huge. Larger size disks are often slower than smaller disks. Lastly, there is always the "Let sleeping dogs lie" proverb, which suggests that not touching existing disks is less likely to result in trouble than adding additional disks. I prefer option 1 to add a 3rd vdev with the 4TB disks. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From lists at marzocchi.net Wed Feb 7 10:08:27 2018 From: lists at marzocchi.net (Olaf Marzocchi) Date: Wed, 07 Feb 2018 11:08:27 +0100 Subject: [OmniOS-discuss] Request advise on pool upgrade In-Reply-To: References: Message-ID: <439E0A6E-CD29-4176-94DB-D08328955FD4@marzocchi.net> You have a big pool with many vdevs and that makes, as you noticed, upgrades difficult I guess you don't need exceptional performances, isn't it? Go then for 8 TB and option 1, creating a new pool as big as the previous one. Use the opportunity (the last one you'll have!) to move everything there, then split the previous one into two. When done, redistribute, as much as possible, the datasets between the three pools. At least in the future you will be able to use two pools as temporary backup for the third one if you need to take one offline for any reason. This trumps all the other advantages and disadvantages IMHO. Olaf Il 6 febbraio 2018 21:27:43 CET, Andries Annema ha scritto: >Hi guys, > >Could you please give me some advise on the best way to increase the >capacity on my home server (running OmniOS obviously...)? > >About four years ago I started designing and building my home storage >server based on a "Coolermaster Stacker" tower case by retrofitting >into >it three Norco SS-500 and one SS-300 hotswap modules, for a total of 18 > >hard drives. >With this number of drive bays available, I choose to go for RAIDZ2: >three vdevs of six drives each. > >Back in 2014, I started with only one vdev of six 4TB WD40EFRX drives. >About a year later, in early 2015, I put another six of those drives in > >and expanded the pool. It has been humming happily ever since. Awesome. > >Over time however, the used pool capacity has now gone up to 86%. It's >time to expand again. >I see a number of possible ways to do so: > >1. Get another six 4TB WD40EFRX's and fill the last open bays, adding a > 3rd vdev (capacity +50%). > Pros: these drives are cheap nowadays, much cheaper than they were > three or four years ago. > Cons: six extra spindles will increase electricity cost. > 2. Get six 8TB WD80EFZX's and fill the last open bays, adding a 3rd > vdev (capacity +100%). > Pros: huge capacity increase. > Cons: higher upgrade cost than option 1 (due to more expensive > drives). Six extra spindles will increase electricity cost. > 3. Get six 8TB WD80EFZX's and *replace* the first vdev with bigger > disks (capacity +50%). > Pros: amount of spindles doesn't change and thus electricity cost > will more or less remain the same. Replaced drives can be utilized > elsewhere, e.g. for offline pool-backups. >Cons: higher upgrade cost than option 1 (due to more expensive drives). > >The first question that comes to mind for option 2 and 3: are there any > >disadvantages to creating a pool out of different capacity drives? The >drives per vdev are identical, it's just the vdevs within the pool that > >aren't. > >Right now I am leaning towards options 2 or 3, with maybe a little >preference for option 3, I think. > >Any thoughts you guys can share on this matter? Would appreciate it. >Thanks! > >Regards, > >Andries -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaakko.linnosaari at polarshift.fi Wed Feb 7 13:41:20 2018 From: jaakko.linnosaari at polarshift.fi (Jaakko Linnosaari) Date: Wed, 7 Feb 2018 15:41:20 +0200 Subject: [OmniOS-discuss] Request advise on pool upgrade In-Reply-To: References: Message-ID: <792BCD45-38EE-43F7-8D1F-C099A403802B@polarshift.fi> > On 7 Feb 2018, at 2.02, Bob Friesenhahn wrote: > > There are things you can do after adding another vdev to rebalance the data across the vdevs. What are one?s options here other than zfs send / zfs recv? Is there some way to elegantly redistribute blocks ?in place?? cheers, Jaakko -------------- next part -------------- An HTML attachment was scrubbed... URL: From an3s.annema at gmail.com Wed Feb 7 18:53:52 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Wed, 7 Feb 2018 19:53:52 +0100 Subject: [OmniOS-discuss] Request advise on pool upgrade In-Reply-To: References: Message-ID: <0fef9d61-5bfc-0cba-087f-5a68202c2751@gmail.com> Hi Bob, Appreciate your thoughts! You are right that I should do something to rebalance the data across added space. Moving some datasets with zfs send| zfs receive should do the trick, right? Smaller disks perform better on resilvering, sure. But I suspect there comes a time anyhow that I will want to expand once again, so avoiding disks larger than 4TB will not go indefinitely. Therefore I was thinking I might as well skip the step to add a 3rd vdev out of 4TB drives altogether. Performance is not really an issue either. It has no difficulty saturating my gigabit-network as it is, and there are not a lot of users it has to serve either. The proverb you are referring to is a wise one, and from the beginning it has been my plan to add a third vdev out of the same drives, but looking at the line of drives currently available plus the fact that I don't expect to be able to avoid touching the first and second vdev forever anyway, I concluded I might as well start rebuilding/upgrading the pool in place. Andries On 2018-02-07 1:02, Bob Friesenhahn wrote: > On Tue, 6 Feb 2018, Andries Annema wrote: >> >> Right now I am leaning towards options 2 or 3, with maybe a little >> preference for option 3, I think. >> >> Any thoughts you guys can share on this matter? Would appreciate it. >> Thanks! > > Since your pool is already excessively full, adding a new vdev would > result in most of the freshly-written data being written there.? This > would result in reduced performance as compared to uniformly available > space in the vdevs.? There are things you can do after adding another > vdev to rebalance the data across the vdevs. > > Smaller size disks are better from a recovery/resilver standpoint. > More disks are better from a performance standpoint.? Replacing a > drive with 8TB of data would take a very long time.? 4TB disks are > already huge.? Larger size disks are often slower than smaller disks. > > Lastly, there is always the "Let sleeping dogs lie" proverb, which > suggests that not touching existing disks is less likely to result in > trouble than adding additional disks. > > I prefer option 1 to add a 3rd vdev with the 4TB disks. > > Bob From an3s.annema at gmail.com Wed Feb 7 18:59:06 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Wed, 7 Feb 2018 19:59:06 +0100 Subject: [OmniOS-discuss] Request advise on pool upgrade In-Reply-To: <792BCD45-38EE-43F7-8D1F-C099A403802B@polarshift.fi> References: <792BCD45-38EE-43F7-8D1F-C099A403802B@polarshift.fi> Message-ID: I too would love to hear any other options, if there are any! Andries On 2018-02-07 14:41, Jaakko Linnosaari wrote: > >> On 7 Feb 2018, at 2.02, Bob Friesenhahn > > wrote: >> >> There are things you can do after adding another vdev to rebalance >> the data across the vdevs. > > What are one?s options here other than zfs send / zfs recv? Is there > some way to elegantly redistribute blocks ?in place?? > > cheers, > Jaakko > > > _______________________________________________ > 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 Wed Feb 7 19:02:25 2018 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 7 Feb 2018 13:02:25 -0600 (CST) Subject: [OmniOS-discuss] Request advise on pool upgrade In-Reply-To: <0fef9d61-5bfc-0cba-087f-5a68202c2751@gmail.com> References: <0fef9d61-5bfc-0cba-087f-5a68202c2751@gmail.com> Message-ID: On Wed, 7 Feb 2018, Andries Annema wrote: > You are right that I should do something to rebalance the data across added > space. Moving some datasets with zfs send| zfs receive should do the trick, > right? This should work, keeping in mind that blocks need to be deleted or overwritten before there is opportunity to reclaim them. Snapshots will block reclaiming blocks referenced by the snapshot. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From an3s.annema at gmail.com Wed Feb 7 19:19:55 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Wed, 7 Feb 2018 20:19:55 +0100 Subject: [OmniOS-discuss] Request advise on pool upgrade In-Reply-To: <439E0A6E-CD29-4176-94DB-D08328955FD4@marzocchi.net> References: <439E0A6E-CD29-4176-94DB-D08328955FD4@marzocchi.net> Message-ID: <49cde7e1-1f62-2e27-4874-b08b4dd04f09@gmail.com> Now that, "my dear Watson", is an interesting 4th option! The usefulness of one large single pool to house all my data and never bother shoveling data around over pool borders - as I did in a previous pre-zfs era with disk partitions - has always been my goal with this build. But, maybe, a compromise is a viable option to ease the process of upgrading once in a while. Maybe, focusing on one single pool is in itself too much of a disadvantage after all. I'll give this some thought. Thanks for sharing! Cheers, Andries On 2018-02-07 11:08, Olaf Marzocchi wrote: > You have a big pool with many vdevs and that makes, as you noticed, > upgrades difficult > I guess you don't need exceptional performances, isn't it? > > Go then for 8 TB and option 1, creating a new pool as big as the > previous one. Use the opportunity (the last one you'll have!) to move > everything there, then split the previous one into two. > When done, redistribute, as much as possible, the datasets between the > three pools. > > At least in the future you will be able to use two pools as temporary > backup for the third one if you need to take one offline for any reason. > This trumps all the other advantages and disadvantages IMHO. > > Olaf > > > > Il 6 febbraio 2018 21:27:43 CET, Andries Annema > ha scritto: > > Hi guys, > > Could you please give me some advise on the best way to increase > the capacity on my home server (running OmniOS obviously...)? > > About four years ago I started designing and building my home > storage server based on a "Coolermaster Stacker" tower case by > retrofitting into it three Norco SS-500 and one SS-300 hotswap > modules, for a total of 18 hard drives. > With this number of drive bays available, I choose to go for > RAIDZ2: three vdevs of six drives each. > > Back in 2014, I started with only one vdev of six 4TB WD40EFRX > drives. About a year later, in early 2015, I put another six of > those drives in and expanded the pool. It has been humming happily > ever since. Awesome. > > Over time however, the used pool capacity has now gone up to 86%. > It's time to expand again. > I see a number of possible ways to do so: > > 1. Get another six 4TB WD40EFRX's and fill the last open bays, > adding a 3rd vdev (capacity +50%). > Pros: these drives are cheap nowadays, much cheaper than they > were three or four years ago. > Cons: six extra spindles will increase electricity cost. > 2. Get six 8TB WD80EFZX's and fill the last open bays, adding a > 3rd vdev (capacity +100%). > Pros: huge capacity increase. > Cons: higher upgrade cost than option 1 (due to more expensive > drives). Six extra spindles will increase electricity cost. > 3. Get six 8TB WD80EFZX's and *replace* the first vdev with > bigger disks (capacity +50%). > Pros: amount of spindles doesn't change and thus electricity > cost will more or less remain the same. Replaced drives can be > utilized elsewhere, e.g. for offline pool-backups. > Cons: higher upgrade cost than option 1 (due to more expensive > drives). > > The first question that comes to mind for option 2 and 3: are > there any disadvantages to creating a pool out of different > capacity drives? The drives per vdev are identical, it's just the > vdevs within the pool that aren't. > > Right now I am leaning towards options 2 or 3, with maybe a little > preference for option 3, I think. > > Any thoughts you guys can share on this matter? Would appreciate > it. Thanks! > > Regards, > > Andries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Wed Feb 7 20:40:22 2018 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 7 Feb 2018 21:40:22 +0100 (CET) Subject: [OmniOS-discuss] Finally - OmniOSce Commercial Support Message-ID: <480357446.634740.1518036022844.JavaMail.zimbra@oetiker.ch> After getting the release process up and running smoothly, the OmniOSce Association is finally ready to start that long awaited Commercial Support offering: Are you running your Servers on OmniOS Community Edition? Would you like to ensure you are not left alone if you run into trouble with the devices? Would you like to ensure the continued maintenance and development of your favorite OS? Go to our website and request an invoice to get your Organisation started on a new OmniOS support contract: https://www.omniosce.org/invoice cheers tobi oetiker OmniOSce Association Aarweg 17, 4600 Olten, Switzerland -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Wed Feb 7 20:43:49 2018 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 7 Feb 2018 21:43:49 +0100 (CET) Subject: [OmniOS-discuss] OmniOS New Homepage https://www.omniosce.org Message-ID: <912883620.635111.1518036229025.JavaMail.zimbra@oetiker.ch> If you want to explain to someone why OmniOSce is cool ... Now you CAN point them to our homepage without further confusing them :-) They might actually understand ... https://www.omniosce.org cheers tobi -- 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: From alka at hfg-gmuend.de Wed Feb 7 21:20:12 2018 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Wed, 7 Feb 2018 22:20:12 +0100 Subject: [OmniOS-discuss] Finally - OmniOSce Commercial Support In-Reply-To: <480357446.634740.1518036022844.JavaMail.zimbra@oetiker.ch> References: <480357446.634740.1518036022844.JavaMail.zimbra@oetiker.ch> Message-ID: Thanks Highly appeciated as this will strengthen the confidence into the Illumos + OmniOS platform. I recommend commercial users to accept the offer. Gea napp-it.org Am 07.02.2018 um 21:40 schrieb Tobias Oetiker: > After getting the release process up and running smoothly, the > OmniOSce Association?is finally ready to?start that long awaited > Commercial Support offering: > > Are you running your Servers on OmniOS Community Edition? Would you > like to ensure you are not left alone if you run into trouble with the > devices? Would you like to ensure the continued maintenance and > development of your favorite OS? > > Go to our website and request an invoice to get your Organisation > started on a new OmniOS support contract: > > *https://www.omniosce.org/invoice* > > cheers > tobi oetiker > > OmniOSce Association > Aarweg 17, 4600 Olten, Switzerland > > > > _______________________________________________ > 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 bwalker at musings.com Mon Feb 12 21:47:22 2018 From: bwalker at musings.com (Brad Walker) Date: Mon, 12 Feb 2018 14:47:22 -0700 Subject: [OmniOS-discuss] problems running omni cmd.. Message-ID: I'm a newbie to building OmniOSce.. In following the build instructions at the following web page: https://www.omniosce.org/dev/build_instructions.html I seem to be getting errors.. bwalker at omniosce:~/src/illumos-omnios$ sudo /opt/ooce/bin/omni setup /build BradWalker This system is running OmniOS r151024 -- By default, HTTPS will be used to access GitHub. -- If you have configured SSH keys on GitHub you can use SSH instead. Do you want to use SSH instead? (y/n) n --- Using /build for installation. -- If you intend to contribute to OmniOS development, then additional -- commands can be enabled to assist with the process. --- Enable these additional commands (y/n) y -- Additionally, if you have write access to the omniosorg organisation at -- GitHub, then the remote upstream branches can be automatically kept -- up-to-date. This access is NOT necessary in order to develop since -- all integrations are via pull requests. --- Do you have commit access to github/omniosorg? (y/n) n --- checking that extra.omnios publisher is set --- checking that developer/illumos-tools is installed --- checking that developer/omnios-build-tools is installed --- checking that ooce/developer/build/ant is installed --- checking that ooce/library/freetype2 is installed --- checking that ooce/runtime/python-36 is installed --- Cloning illumos-omnios from https://github.com/BradWalker Cloning into '/build/illumos-omnios'... fatal: Remote branch r151024 not found in upstream origin bwalker at omniosce:~/src/illumos-omnios$ sudo /opt/ooce/bin/omni setup /build BradWalker Any ideas on what I'm doing wrong? Thanks. -brad w. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Mon Feb 12 22:16:50 2018 From: henson at acm.org (Paul B. Henson) Date: Mon, 12 Feb 2018 14:16:50 -0800 Subject: [OmniOS-discuss] problems running omni cmd.. In-Reply-To: References: Message-ID: <20180212221649.GC4503@bender.it-sys.cpp.edu> On Mon, Feb 12, 2018 at 02:47:22PM -0700, Brad Walker wrote: > --- Cloning illumos-omnios from https://github.com/BradWalker > Cloning into '/build/illumos-omnios'... > fatal: Remote branch r151024 not found in upstream origin It looks like it's trying to copy the OS source from your repo rather than the omniosorg repo? And you haven't forked it... I'm not familiar with this script or build process, but just as a guess try going to https://github.com/omniosorg/illumos-omnios and fork it into your github account. Either that or tell it to get it from that repo directly. From bwalker at musings.com Mon Feb 12 23:18:12 2018 From: bwalker at musings.com (Brad Walker) Date: Mon, 12 Feb 2018 16:18:12 -0700 Subject: [OmniOS-discuss] problems running omni cmd.. In-Reply-To: <20180212221649.GC4503@bender.it-sys.cpp.edu> References: <20180212221649.GC4503@bender.it-sys.cpp.edu> Message-ID: Thanks Paul! That was the problem.. In addition, I would make the strong suggestion the following dependencies get added to the website.. illumos-omnios omnios-build kayak Once I forked these from the OmniOSce git repo, everything worked correctly.. Thanks for the help! -brad w. On Mon, Feb 12, 2018 at 3:16 PM, Paul B. Henson wrote: > On Mon, Feb 12, 2018 at 02:47:22PM -0700, Brad Walker wrote: > > > --- Cloning illumos-omnios from https://github.com/BradWalker > > Cloning into '/build/illumos-omnios'... > > fatal: Remote branch r151024 not found in upstream origin > > It looks like it's trying to copy the OS source from your repo rather > than the omniosorg repo? And you haven't forked it... > > I'm not familiar with this script or build process, but just as a guess > try going to > > https://github.com/omniosorg/illumos-omnios > > and fork it into your github account. Either that or tell it to get it > from that repo directly. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omnios at citrus-it.net Mon Feb 12 23:44:40 2018 From: omnios at citrus-it.net (Andy Fiddaman) Date: Mon, 12 Feb 2018 23:44:40 +0000 (UTC) Subject: [OmniOS-discuss] problems running omni cmd.. In-Reply-To: References: <20180212221649.GC4503@bender.it-sys.cpp.edu> Message-ID: On Mon, 12 Feb 2018, Brad Walker wrote: ; In addition, I would make the strong suggestion the following dependencies ; get added to the website.. ; ; illumos-omnios ; omnios-build ; kayak Hi Brad, The instructions on the web page you mentioned already say to do that. "First, create a GitHub account if you don't have one already and then use the web interface to fork the five repositories listed above. Once that's done.... " Had you not forked them at all or had you forked them from OmniTI's area by mistake? Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From bwalker at musings.com Tue Feb 13 17:09:55 2018 From: bwalker at musings.com (Brad Walker) Date: Tue, 13 Feb 2018 10:09:55 -0700 Subject: [OmniOS-discuss] problems running omni cmd.. In-Reply-To: References: <20180212221649.GC4503@bender.it-sys.cpp.edu> Message-ID: Andy, You are correct.. I had forked them from OmniTI's area by mistake.. Let me say that my head was spinning yesterday from trying to build illumos.. I started with the build instructions from the illumos wiki and that was a real exercise in frustration.. Then I did the OmniOS build instructions and had much more success but still a few snags. Then I found the OmniOSce web page and was working through it. The folks int he OmniOSce community seem to have put together a really good tool for building illumos as my build was successful! But, now I'm having a problem with building media.. ~/src/illumos-omnios$ ~/src/illumos-omnios$ omni build_media *** Building media... gcc -o takeover-console takeover-console.c ./build_ipcalc --2018-02-13 02:48:51-- https://mirrors.omniosce.org/ipcalc//ipcalc-0.2.0.tar.gz Resolving mirrors.omniosce.org... 129.132.2.8 Connecting to mirrors.omniosce.org|129.132.2.8|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 31750 (31K) [application/octet-stream] Saving to: 'ipcalc-0.2.0.tar.gz' ipcalc-0.2.0.tar.gz 100%[====================================================>] 31.01K 95.6KB/s in 0.3s 2018-02-13 02:48:59 (95.6 KB/s) - 'ipcalc-0.2.0.tar.gz' saved [31750/31750] gmake[1]: Entering directory '/tmp/tmp.ZnJu4M0wk5/ipcalc-0.2.0' gcc -D_KERNEL -DVERSION="\"0.2.0\"" ipcalc.c ipcalc-geoip.c ipcalc-reverse.c netsplit.c -o ipcalc -lsocket -lnsl -lresolv gmake[1]: Leaving directory '/tmp/tmp.ZnJu4M0wk5/ipcalc-0.2.0' gcc -o passutil passutil.c mkdir -p /kayak_image/tftpboot/boot/grub mkdir -p /kayak_image/tftpboot/boot/platform/i86pc/kernel/amd64 mkdir -p /kayak_image/tftpboot/kayak if test -n "`zfs list -H -t snapshot rpool/kayak_image/root at fixup 2>/dev/null`"; then \ VERSION=r151024n DEBUG= ./build_image.sh rpool/kayak_image fixup ; \ else \ VERSION=r151024n DEBUG= ./build_image.sh rpool/kayak_image begin ; \ fi Explicit checkpoint requested: 'begin' === Proceeding to phase begin === === Proceeding to phase pkg (zfs @pkg) === Creating image of omnios from file:///build/repo Variants/Facets to change: 1 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 0/0 Updating package cache 1/1 Variants/Facets to change: 1 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 0/0 Updating package cache 1/1 pkg install: The following pattern(s) did not match any allowable packages. Try using a different matching pattern, or refreshing publisher information: illumos-gate at 11-0.151024 omnios-userland at 11-0.151024 ERROR: version constraint prep gmake: *** [Makefile:105: /kayak_image/miniroot.gz] Error 1 ~/src/illumos-omnios$ ~/src/illumos-omnios$ ~/src/illumos-omnios$ So any suggestions on this would be helpful.. -brad w. On Mon, Feb 12, 2018 at 4:44 PM, Andy Fiddaman wrote: > > On Mon, 12 Feb 2018, Brad Walker wrote: > > ; In addition, I would make the strong suggestion the following > dependencies > ; get added to the website.. > ; > ; illumos-omnios > ; omnios-build > ; kayak > > Hi Brad, > > The instructions on the web page you mentioned already say to do that. > > "First, create a GitHub account if you don't have one already and then use > the > web interface to fork the five repositories listed above. > > Once that's done.... > " > > Had you not forked them at all or had you forked them from OmniTI's area > by mistake? > > Andy > > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omnios at citrus-it.net Tue Feb 13 18:44:07 2018 From: omnios at citrus-it.net (Andy Fiddaman) Date: Tue, 13 Feb 2018 18:44:07 +0000 (UTC) Subject: [OmniOS-discuss] problems running omni cmd.. In-Reply-To: References: <20180212221649.GC4503@bender.it-sys.cpp.edu> Message-ID: On Tue, 13 Feb 2018, Brad Walker wrote: ; But, now I'm having a problem with building media.. ; ; pkg install: The following pattern(s) did not match any allowable ; packages. Try ; using a different matching pattern, or refreshing publisher information: ; ; illumos-gate at 11-0.151024 ; omnios-userland at 11-0.151024 Have you built both the core illumos and OmniOS userland bits? That's: omni build_illumos omni build_omnios It looks like you're missing the second (userland) part. Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From danmcd at kebe.com Tue Feb 13 19:00:15 2018 From: danmcd at kebe.com (Dan McDonald) Date: Tue, 13 Feb 2018 14:00:15 -0500 Subject: [OmniOS-discuss] Running on latest Xeon-Skylake servers? Message-ID: <20180213190015.GA5144@everywhere.local> Curious... has anyone here in OmniOS-land run bloody or current-stable on very recent Intel Skylake server hardware? For example: https://www.supermicro.com/products/motherboard/Xeon/C620/X11DPi-NT.cfm We're seeing some weirdness with SmartOS, and wanted to know if similar weirdness was happening with anyone out there? Thanks, Dan From tobi at oetiker.ch Fri Feb 16 09:09:02 2018 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 16 Feb 2018 10:09:02 +0100 (CET) Subject: [OmniOS-discuss] OmniOS CE Support Contracts - Quotes Message-ID: <432626232.783048.1518772142233.JavaMail.zimbra@oetiker.ch> Hi All As mentioned last week, the OmniOS CE association is now offering a Support Package for organizations using OmniOS on their servers. Since many institutions need to get a quote first, in order to initiate payments, we have enhanced our invoice generator with a new 'quote' function. https://omniosce.org/invoice according to our statistics, we have now at least 500 servers running under omniosce which are downloading regular updates from our repos. if a decent number of them got a support package, this would go a long way in making omnios ce long-term viable also from a financial standpoint. -- 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: From chip at innovates.com Fri Feb 16 16:18:50 2018 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 16 Feb 2018 10:18:50 -0600 Subject: [OmniOS-discuss] FMD fails to run Message-ID: This is on OmniOS CE r151024l running in a VMware virtual machine under ESXi 6.5 with PCI pass-thru to a SAS3008 HBA. The problem is related to the HBA on pass-thru. If I disconnect it, everything starts fine, but I am not clear why or how to fix this. I have done similar VM passthrough setups with older versions of OmniOS and SAS2 HBAs without any problems. The same HBA was being used successfully in the same configuration with CentOS 7 in the VM so I know this can function. I can see all the disks, but cannot import the pool because the fault manager is not running. The logs show: [ Feb 16 10:02:14 Method "start" exited with status 1. ] [ Feb 16 10:02:14 Executing start method ("/usr/lib/fm/fmd/fmd"). ] ABORT: attempted zero-length allocation: No such device or address [ Feb 16 10:02:14 Method "start" exited with status 1. ] [ Feb 16 10:02:14 Executing start method ("/usr/lib/fm/fmd/fmd"). ] ABORT: attempted zero-length allocation: No such device or address [ Feb 16 10:02:14 Method "start" exited with status 1. ] [ Feb 16 10:05:09 Leaving maintenance because clear requested. ] [ Feb 16 10:05:09 Enabled. ] [ Feb 16 10:05:09 Executing start method ("/usr/lib/fm/fmd/fmd"). ] ABORT: attempted zero-length allocation: No such device or address [ Feb 16 10:05:10 Method "start" exited with status 1. ] Any hope of making this work? Thanks! -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Fri Feb 16 16:39:17 2018 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 16 Feb 2018 10:39:17 -0600 Subject: [OmniOS-discuss] [zfs] FMD fails to run In-Reply-To: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> Message-ID: Here's what I'm seeing: # /usr/lib/fm/fmd/fmd -o fg=true -o client.debug=true fmd: [ loading modules ... ABORT: attempted zero-length allocation: No such device or address Abort (core dumped) # mdb core Loading modules: [ fmd libumem.so.1 libc.so.1 libnvpair.so.1 libtopo.so.1 libuutil.so.1 libavl.so.1 libcmdutils.so.1 libsysevent.so.1 ld.so.1 ] > $C 08046298 libc.so.1`_lwp_kill+0x15(1, 6, 80462e8, fef42000, fef42000, 8046320) 080462b8 libc.so.1`raise+0x2b(6, 0, 80462d0, feec1b59, 0, 0) 08046308 libc.so.1`abort+0x10e(fede2a40, fef44cb8, 8046348, 6, 524f4241, 61203a54) 08046738 libses.so.1`ses_panic(fdde6758, 8046764, 80467d8, fdb6b67a, 83f1048, fdb6c398) 08046758 libses.so.1`ses_realloc(fdde6758, 0, 83f5078, fdde6130, fddf7000, fdb6658f) 08046778 libses.so.1`ses_alloc+0x27(0, feb80000, 6, 10, ee0, 80f4627) 080467a8 libses.so.1`ses_zalloc+0x1e(0, 0, 73, fdb6659d, 83f5050, 8) 08046828 ses2.so`elem_parse_aes_misc+0x91(80f44f4, 83f1048, 8, fdb65d85) 08046878 ses2.so`elem_parse_aes+0xfc(82bd388, 83f5148, 80468e8, fdb80eae) 08046898 ses2.so`ses2_fill_element_node+0x37(82bd388, 83f5148, 8303ed8, 4) 080468c8 ses2.so`ses2_node_parse+0x53(82bd388, 83f5148, e, fddf7000) 080468e8 libses.so.1`ses_fill_node+0x22(83f5148, 83f5208, fdde38ae, fdde394c) 08046908 libses.so.1`ses_fill_tree+0x21(83f5148, 82bd548, 83e9cc8, fdde394c) 08046928 libses.so.1`ses_fill_tree+0x33(82bd648, 82bd448, 8046958, fdde394c) 08046948 libses.so.1`ses_fill_tree+0x33(82bd548, 82a5270, 8046988, fdde394c) 08046968 libses.so.1`ses_fill_tree+0x33(82bd448, 0, 18, fddf7000) 08046988 libses.so.1`ses_fill_snap+0x22(82c08d0, 80, 0, fdde56eb) 080469d8 libses.so.1`ses_snap_new+0x325(82bd408, 0, 8046a08, fdde3006) 08046a08 libses.so.1`ses_open_scsi+0xc4(1, 82a51a0, 8046a90, fed71c1b, 80e9468, fede4042) 08046a58 libses.so.1`ses_open+0x98(1, 8046a90, 0, feecedd3, 43, fde1fc58) 08046ea8 ses.so`ses_process_dir+0x133(fde20159, 83d8ed8, 0, fed77e40) 08046ed8 ses.so`ses_enum+0xc1(80e9468, 83aeb58, 8356570, 0, 400, 0) 08046f28 libtopo.so.1`topo_mod_enumerate+0xc4(80e9468, 83aeb58, 82d4a88, 8356570, 0, 400) 08046f78 libtopo.so.1`enum_run+0xe9(80e9a18, 83d77c8, a, fed7b1dd) 08046fc8 libtopo.so.1`topo_xml_range_process+0x13e(80e9a18, 82bb0b0, 83d77c8, 8046ff8) 08047018 libtopo.so.1`tf_rdata_new+0x135(80e9a18, 81c8790, 82bb0b0, 83aeb58) 08047078 libtopo.so.1`topo_xml_walk+0x246(80e9a18, 81c8790, 82bb830, 83aeb58, 80e9a18, 83d5bc0) 080470d8 libtopo.so.1`topo_xml_walk+0x1b2(80e9a18, 81c8790, 82b0b28, 83aeb58) 08047118 libtopo.so.1`dependent_create+0x127(80e9a18, 81c8790, 83d6ab0, 82b0b28, 83aeb58, fed7b1f9) 08047158 libtopo.so.1`dependents_create+0x64(80e9a18, 81c8790, 83d6ab0, 82b0da8, 83aeb58, 81bd0d8) 08047208 libtopo.so.1`pad_process+0x51e(80e9a18, 83d79a8, 82b0da8, 83aeb58, 83d79d0, 8356340) 08047268 libtopo.so.1`topo_xml_range_process+0x31f(80e9a18, 82b0da8, 83d79a8, 8047298) 080472b8 libtopo.so.1`tf_rdata_new+0x135(80e9a18, 81c8790, 82b0da8, 81bd258) 08047318 libtopo.so.1`topo_xml_walk+0x246(80e9a18, 81c8790, 82a37a0, 81bd258, 80e5f40, fed8c000) 08047348 libtopo.so.1`topo_xml_enum+0x67(80e9a18, 81c8790, 81bd258, feac2000) 08047478 libtopo.so.1`topo_file_load+0x139(80e9a18, 81bd258, fe20c127, fe20bda2, 0, 82a6000) 080474a8 libtopo.so.1`topo_mod_enummap+0x26(80e9a18, 81bd258, fe20c127, fe20bda2, 80e9a18, fe20b11c) 080474f8 x86pi.so`x86pi_enum_start+0xc5(80e9a18, 8047520, 8047528, fe205580, 80e9a18, 80e9a18) 08047548 x86pi.so`x86pi_enum+0x55(80e9a18, 81bd258, 81a6a70, 0, 0, 0) 08047598 libtopo.so.1`topo_mod_enumerate+0xc4(80e9a18, 81bd258, 80cdf38, 81a6a70, 0, 0) 080475e8 libtopo.so.1`enum_run+0xe9(80e9b68, 82a5fa8, a, fed7b1dd) 08047638 libtopo.so.1`topo_xml_range_process+0x13e(80e9b68, 82a3f70, 82a5fa8, 8047668) 08047688 libtopo.so.1`tf_rdata_new+0x135(80e9b68, 81c8bd0, 82a3f70, 81bd258) 080476e8 libtopo.so.1`topo_xml_walk+0x246(80e9b68, 81c8bd0, 81c7108, 81bd258, 80e5f40, fed8c000) 08047718 libtopo.so.1`topo_xml_enum+0x67(80e9b68, 81c8bd0, 81bd258, 81a6ab0) 08047848 libtopo.so.1`topo_file_load+0x139(80e9b68, 81bd258, 80d4f38, 81a6a80, 0, 2c) 08047888 libtopo.so.1`topo_tree_enum+0x89(80e5f40, 81c5318, 80478b8, fe70e6f8, 81b5310, 80e5f40) 080478a8 libtopo.so.1`topo_tree_enum_all+0x20(80e5f40, 81b5310, 80478e8, fed71087) 080478e8 libtopo.so.1`topo_snap_create+0x13d(80e5f40, 804793c, 0, fed7118d, 807c010, 21) 08047918 libtopo.so.1`topo_snap_hold+0x56(80e5f40, 0, 804793c, 80c9f08, 0, 8047ab8) 08047958 fmd_topo_update+0x9f(80c9f08, 8085dfa, 8047a58, 80601f7, 0, 0) 08047968 fmd_topo_init+0xb(0, 0, 0, 0, 2, 80992f8) 08047a58 fmd_run+0x118(809a8c0, ffffffff, 0, 0) 08047ad8 main+0x344(8047acc, fef4f348, 8047b0c, 805fdd3, 5, 8047b18) 08047b0c _start+0x83(5, 8047c2c, 8047c40, 8047c43, 8047c4b, 8047c4e) On Fri, Feb 16, 2018 at 10:29 AM, Yuri Pankov wrote: > Schweiss, Chip wrote: > >> This is on OmniOS CE r151024l running in a VMware virtual machine under >> ESXi 6.5 with PCI pass-thru to a SAS3008 HBA. >> >> The problem is related to the HBA on pass-thru. If I disconnect it, >> everything starts fine, but I am not clear why or how to fix this. I have >> done similar VM passthrough setups with older versions of OmniOS and SAS2 >> HBAs without any problems. >> >> The same HBA was being used successfully in the same configuration with >> CentOS 7 in the VM so I know this can function. >> >> I can see all the disks, but cannot import the pool because the fault >> manager is not running. >> >> The logs show: >> >> [ Feb 16 10:02:14 Method "start" exited with status 1. ] >> [ Feb 16 10:02:14 Executing start method ("/usr/lib/fm/fmd/fmd"). ] >> ABORT: attempted zero-length allocation: No such device or address >> [ Feb 16 10:02:14 Method "start" exited with status 1. ] >> [ Feb 16 10:02:14 Executing start method ("/usr/lib/fm/fmd/fmd"). ] >> ABORT: attempted zero-length allocation: No such device or address >> [ Feb 16 10:02:14 Method "start" exited with status 1. ] >> [ Feb 16 10:05:09 Leaving maintenance because clear requested. ] >> [ Feb 16 10:05:09 Enabled. ] >> [ Feb 16 10:05:09 Executing start method ("/usr/lib/fm/fmd/fmd"). ] >> ABORT: attempted zero-length allocation: No such device or address >> [ Feb 16 10:05:10 Method "start" exited with status 1. ] >> >> Any hope of making this work? >> > > Try disabling fmd service: > > svcadm disable fmd > > Run fmd in foreground: > > /usr/lib/fm/fmd/fmd -o fg=true -o client.debug=true > > and provide the errors you are seeing, and at least stacktrace if it's > dumping core. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Fri Feb 16 16:57:34 2018 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 16 Feb 2018 10:57:34 -0600 Subject: [OmniOS-discuss] [zfs] FMD fails to run In-Reply-To: <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> References: <9abf7a48-999e-dda1-502e-56ca232917bf@yuripv.net> <75ab2e54-b0a5-0382-82db-a775ffc907a1@joyent.com> Message-ID: On Fri, Feb 16, 2018 at 10:47 AM, Robert Mustacchi wrote: > We're getting a zero length allocation here. It appears that the number > of phys that we're detecting in one of the elements is probably zero. Is > it possible to upload the core so we can confirm the data and fix the > ses module to handle this, potentially odd, case? > > Sure, where would you like me to upload the core? I've put it here if you'd like to grab it: ftp://ftp.nrg.wustl.edu/pub/zfs/fmd.core -Chip > Thanks, > Robert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Fri Feb 16 20:11:03 2018 From: henson at acm.org (Paul B. Henson) Date: Fri, 16 Feb 2018 12:11:03 -0800 Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL inheritance) Message-ID: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> After we upgraded to the latest version of OmniOSce, switching from the last OmniTI LTS release, we ran into a fairly big problem with ACL inheritance, which results in unexpectedly insecure file permissions :(. After a short discussion on the ZFS developer mailing list: https://illumos.topicbox.com/groups/zfs/discussions/Te5cbb71851130ac1-M486e4 bd93 ace9f7314003f66 We determined this was a problem introduced by issue 6764, and I opened a new issue regarding it: https://www.illumos.org/issues/8984 I asked on the ZFS developer mailing list if anyone might be willing to spend a little time fixing this regression: https://illumos.topicbox.com/groups/zfs/T821c96dfa2b1306d-M13ef4f3ea9d83b7f3 91859a1 but I haven't heard anything. It should be fairly simple, just adding back in a little bit of logic the previous change took out; however, I don't currently have an up-to-date build environment and would rather not have the overhead of putting that together right now just for this little fix. Are there perhaps any OmniOS developers who might be kind enough to squash this for us? We are getting a lot of complaints from users and potentially leaking sensitive information because of it. Thanks much. From an3s.annema at gmail.com Sat Feb 17 19:38:36 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Sat, 17 Feb 2018 20:38:36 +0100 Subject: [OmniOS-discuss] Update error Message-ID: <6f45bdc7-2f8c-82a3-fb73-35ae33e89e8e@gmail.com> Hi guys, Trying to update a r151022 (test)system with a number of lipkg and lx zones to the latest r151022al version, using "pkg update -nv", but it fails with: Planning linked: 1/7 done; 1 working: zone: Linked progress: -pkg: update failed (linked image exception(s)): A '*sync-linked*' operation failed for child 'zone:' with an unexpected return value of 1 and generated the following output: pkg: 0/1 catalogs successfully updated: The content of the catalog for publisher 'omnios' doesn't match the catalog's attributes.? This is likely the result of a mix of older and newer catalog files being provided for the publisher. When I instead run "pkg update -nrv", it fails with almost the same message: Planning linked: 1/7 done; 1 working: zone: Linked progress: |pkg: update failed (linked image exception(s)): A '*update*' operation failed for child 'zone:' with an unexpected return value of 1 and generated the following output: pkg: 0/1 catalogs successfully updated: The content of the catalog for publisher 'omnios' doesn't match the catalog's attributes.? This is likely the result of a mix of older and newer catalog files being provided for the publisher. Google-ing for this issue does give some reports, but mostly of age and a clear solution - at least to me - doesn't seem available. I have never before updated this system - since I installed this test-VM last summer - not from the GZ, nor from within any NGZ. Funny thing is that not every zone leads to such an error; for at least one other zone a nice update plan was reported before it bailed out on the next zone with the error quoted above. Other than destroying each zone for which it reports this error, any thoughts on how to solve this issue? In the past, I've never had such issues with ipkg zones; I may be doing something wrong with these lipkg zones. Cheers, Andries -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at kebe.com Sat Feb 17 19:53:08 2018 From: danmcd at kebe.com (Dan McDonald) Date: Sat, 17 Feb 2018 14:53:08 -0500 Subject: [OmniOS-discuss] Update error In-Reply-To: <6f45bdc7-2f8c-82a3-fb73-35ae33e89e8e@gmail.com> References: <6f45bdc7-2f8c-82a3-fb73-35ae33e89e8e@gmail.com> Message-ID: Check the output of "pkg publisher" in both global and each lipkg zone. Maybe you have one "omnios" publisher pointing to a different URL? Dan From an3s.annema at gmail.com Sun Feb 18 12:11:34 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Sun, 18 Feb 2018 13:11:34 +0100 Subject: [OmniOS-discuss] Update error In-Reply-To: References: <6f45bdc7-2f8c-82a3-fb73-35ae33e89e8e@gmail.com> Message-ID: Whoops! I didn't care to verify the publishers, as I was convinced I hadn't changed them. Turns out I added a local mirror of the "omnios" publisher to some zones, but that mirror does not contain the r151022 packages yet - only r151014. My bad. Thanks for pointing me in the right direction! Cheers, Andries On 2018-02-17 20:53, Dan McDonald wrote: > Check the output of "pkg publisher" in both global and each lipkg zone. Maybe you have one "omnios" publisher pointing to a different URL? > > Dan > From an3s.annema at gmail.com Sun Feb 18 16:20:43 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Sun, 18 Feb 2018 17:20:43 +0100 Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL inheritance) In-Reply-To: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> Message-ID: <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> Playing around with r151022, I may have bumped into the same issue here. The ACE's that I set on the parent directory are nicely inherited, but on top of that, another ACE for owner@, group@ and everyone@ is added. Another weird thing I noticed is that these unwanted ACE's are *only* added when the file is created directly from the command line on the server itself or from a non-global zone that has the dataset lofs-mounted; files created from a Windows client, through a CIFS/SMB mount, do *not* get the extra unwanted ACE's. Now, where the heck does that difference come from...?! I have the relevant dataset properties set to "aclinherit=passthrough-x" and "aclmode=passthrough". The top-level directory has been altered up-front with "chmod -R 2777 /tank" and, to force the group-ID, "chmod -R g+s /tank". The whole procedure of creating my datasets is not different than what I did on r151014. I also meticulously compared the settings on both releases, but can't seem to find any obvious difference. Or anything at all. Here is some example output. Notice the capital "I" at the end of each ACE line for the once that are nicely inherited, and the lack of it at the unwanted ACE lines: root at vm01omniosce ~ # /usr/bin/ls -lV /tank/media_unsorted/subdir1/subdir2/subdir3/ total 1098 drwxrwsr-x+? 2 dlmgr??? media????????? 2 Feb 16 19:49 from-ngz-over-lofs ????????????? user:an3s:rwxpdDaARWcCos:-d----I:allow ????????????? user:an3s:rw-pdDaARWc--s:f-i---I:allow ???????????? user:dlmgr:rwxp--aARWc--s:-d----I:allow ???????????? user:dlmgr:rw-p--aARWc--s:f-i---I:allow ???????????????? owner@:rwxpdDaARWcCos:-d----I:allow ???????????????? owner@:rw-pdDaARWc--s:f-i---I:allow ???????????????? group@:rwxp--aARWc--s:-d----I:allow ???????????????? group@:rw-p--aARWc--s:f-i---I:allow ????????? group:mediaro:r-x---a-R-c--s:-d----I:allow ????????? group:mediaro:r-----a-R-c--s:f-i---I:allow ????????????? everyone@:------a-R-c--s:fd----I:allow ???????????????? owner@:rwxp-DaARWcCos:-------:allow #UNWANTED ACE! ???????????????? group@:rwxp-Da-R-c--s:-------:allow #UNWANTED ACE! ????????????? everyone@:r-x---a-R-c--s:-------:allow #UNWANTED ACE! -rw-rw-r--+? 1 dlmgr??? media???? 557056 Feb 16 19:49 from-ngz-over-lofs.mp3 ????????????? user:an3s:rw-pdDaARWc--s:------I:allow ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow ???????????????? owner@:rw-pdDaARWc--s:------I:allow ???????????????? group@:rw-p--aARWc--s:------I:allow ????????? group:mediaro:r-----a-R-c--s:------I:allow ????????????? everyone@:------a-R-c--s:------I:allow ???????????????? owner@:rw-p--aARWcCos:-------:allow #UNWANTED ACE! ???????????????? group@:r-----a-R-c--s:-------:allow #UNWANTED ACE! ????????????? everyone@:r-----a-R-c--s:-------:allow #UNWANTED ACE! -rw-rw-r--+? 1 admin??? media????????? 0 Feb 16 19:56 from-omniosce-cli.txt ????????????? user:an3s:rw-pdDaARWc--s:------I:allow ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow ???????????????? owner@:rw-pdDaARWc--s:------I:allow ???????????????? group@:rw-p--aARWc--s:------I:allow ????????? group:mediaro:r-----a-R-c--s:------I:allow ????????????? everyone@:------a-R-c--s:------I:allow ???????????????? owner@:rw-p--aARWcCos:-------:allow #UNWANTED ACE! ???????????????? group@:r-----a-R-c--s:-------:allow #UNWANTED ACE! ????????????? everyone@:r-----a-R-c--s:-------:allow #UNWANTED ACE! -rw-rw----+? 1 an3s???? media????????? 0 Feb 16 19:56 from-win7.txt ????????????? user:an3s:rw-pdDaARWc--s:------I:allow ???????????? user:dlmgr:rw-p--aARWc--s:------I:allow ???????????????? owner@:rw-pdDaARWc--s:------I:allow ???????????????? group@:rw-p--aARWc--s:------I:allow ????????? group:mediaro:r-----a-R-c--s:------I:allow ????????????? everyone@:------a-R-c--s:------I:allow Can this be blamed on the same issue or am I looking at some other cause here? Any thoughts? Muchos gracias. Regards, Andries On 2018-02-16 21:11, Paul B. Henson wrote: > After we upgraded to the latest version of OmniOSce, switching from the last > OmniTI LTS release, we ran into a fairly big problem with ACL inheritance, > which results in unexpectedly insecure file permissions :(. > > After a short discussion on the ZFS developer mailing list: > > https://illumos.topicbox.com/groups/zfs/discussions/Te5cbb71851130ac1-M486e4 > bd93 > ace9f7314003f66 > > > We determined this was a problem introduced by issue 6764, and I opened a > new issue regarding it: > > https://www.illumos.org/issues/8984 > > I asked on the ZFS developer mailing list if anyone might be willing to > spend a little time fixing this regression: > > https://illumos.topicbox.com/groups/zfs/T821c96dfa2b1306d-M13ef4f3ea9d83b7f3 > 91859a1 > > but I haven't heard anything. It should be fairly simple, just adding back > in a little bit of logic the previous change took out; however, I don't > currently have an up-to-date build environment and would rather not have the > overhead of putting that together right now just for this little fix. > > Are there perhaps any OmniOS developers who might be kind enough to squash > this for us? We are getting a lot of complaints from users and potentially > leaking sensitive information because of it. > > Thanks much. > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From omnios at citrus-it.net Sun Feb 18 19:43:02 2018 From: omnios at citrus-it.net (Andy Fiddaman) Date: Sun, 18 Feb 2018 19:43:02 +0000 (UTC) Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL inheritance) In-Reply-To: <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> Message-ID: On Sun, 18 Feb 2018, Andries Annema wrote: ; Playing around with r151022, I may have bumped into the same issue here. ; The ACE's that I set on the parent directory are nicely inherited, but ; on top of that, another ACE for owner@, group@ and everyone@ is added. Hi, This does sound like the same issue and we have a fix for this currently in testing for OmniOS r151022 which we plan to upstream when it's ready. If you want to test the hot-fix, a package archive containing an updated zfs pachage is available for download at: https://downloads.omniosce.org/pkg/8984_r151022.p5p to install please proceed as follows (assuming the downloaded archive is in /root): # pkg set-publisher -g /root/8984_r151022.p5p omnios # pkg update -v --be-name=... # init 6 # pkg set-publisher -G /root/8984_r151022.p5p omnios Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From henson at acm.org Sun Feb 18 20:47:25 2018 From: henson at acm.org (Paul B. Henson) Date: Sun, 18 Feb 2018 12:47:25 -0800 Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL inheritance) In-Reply-To: <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> Message-ID: <20180218204724.GS4503@bender.it-sys.cpp.edu> On Sun, Feb 18, 2018 at 05:20:43PM +0100, Andries Annema wrote: > Playing around with r151022, I may have bumped into the same issue here. > The ACE's that I set on the parent directory are nicely inherited, but > on top of that, another ACE for owner@, group@ and everyone@ is added. Yup, that looks like it :(. > Another weird thing I noticed is that these unwanted ACE's are *only* > added when the file is created directly from the command line on the > server itself or from a non-global zone that has the dataset > lofs-mounted; files created from a Windows client, through a CIFS/SMB > mount, do *not* get the extra unwanted ACE's. Now, where the heck does > that difference come from...?! The underlying bug is a chmod is incorrectly executed during the creation of the file using the requested creation mode (modified by umask), resulting in an ACL based on your aclmode setting. If you're using the in-kernel CIFS server, that bypasses the POSIX layer, and as such the chmod isn't called and there's no brokenness to the ACL. Fortunately thanks to the great responsiveness of the omniosce team :), as posted there is a fix available for testing already. We're going to be applying it to our dev systems tomorrow to try out. From softwareinforjam at gmail.com Mon Feb 19 20:02:41 2018 From: softwareinforjam at gmail.com (Software Information) Date: Mon, 19 Feb 2018 15:02:41 -0500 Subject: [OmniOS-discuss] Cannot install Non-Global Zone Message-ID: Hi All I have been trying to understand the reason for an error I have been getting when I try to install a non-global zone. The error is below pkg install: The following pattern(s) did not match any allowable packages. Try using a different matching pattern, or refreshing publisher information: entire at 11-0.151022:20180108T221634Z ERROR: failed to install package I did some research and I still don't understand why this is happening. I did a pkg list entire in the Global and Non-Global zones and the version is the same. # pkg list entire NAME (PUBLISHER) VERSION IFO *entire 11-0.151022 i--* Could anyone help me out please? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at kebe.com Mon Feb 19 20:49:41 2018 From: danmcd at kebe.com (Dan McDonald) Date: Mon, 19 Feb 2018 15:49:41 -0500 Subject: [OmniOS-discuss] Cannot install Non-Global Zone In-Reply-To: References: Message-ID: Use the -lv flags for pkg list. Dan Sent from my iPhone (typos, autocorrect, and all) > On Feb 19, 2018, at 3:02 PM, Software Information wrote: > > Hi All > I have been trying to understand the reason for an error I have been getting when I try to install a non-global zone. The error is below > > pkg install: The following pattern(s) did not match any allowable packages. Try > using a different matching pattern, or refreshing publisher information: > > entire at 11-0.151022:20180108T221634Z > ERROR: failed to install package > > I did some research and I still don't understand why this is happening. I did a pkg list entire in the Global and Non-Global zones and the version is the same. > > # pkg list entire > NAME (PUBLISHER) VERSION IFO > entire 11-0.151022 i-- > > Could anyone help me out please? > > > _______________________________________________ > 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 softwareinforjam at gmail.com Mon Feb 19 23:26:53 2018 From: softwareinforjam at gmail.com (Software Information) Date: Mon, 19 Feb 2018 18:26:53 -0500 Subject: [OmniOS-discuss] Cannot install Non-Global Zone In-Reply-To: References: Message-ID: Thanks for replying. I did that and also ran pkgrepo rebuild -s /var/pkg/publisher/omnios as I noticed afterwards that this version was different from what I saw when I ran pkg list -v entire. Now *pkg list -v entire* and *pkgrepo list -Hs /var/pkg/publisher/omnios | grep entire *both show the same version # pkg list -Hv entire pkg://omnios/entire at 11-0.151022:20180108T221634Z # pkgrepo list -Hs /var/pkg/publisher/omnios | grep entire omnios entire 11-0.151022:20180108T221634Z Still getting the same error though when I try to reinstall the zone. pkg install: The following pattern(s) did not match any allowable packages. Try using a different matching pattern, or refreshing publisher information: entire at 11-0.151022:20180108T221634Z ERROR: failed to install package On Mon, Feb 19, 2018 at 3:49 PM, Dan McDonald wrote: > Use the -lv flags for pkg list. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Feb 19, 2018, at 3:02 PM, Software Information < > softwareinforjam at gmail.com> wrote: > > Hi All > I have been trying to understand the reason for an error I have been > getting when I try to install a non-global zone. The error is below > > pkg install: The following pattern(s) did not match any allowable > packages. Try > using a different matching pattern, or refreshing publisher information: > > entire at 11-0.151022:20180108T221634Z > ERROR: failed to install package > > I did some research and I still don't understand why this is happening. I > did a pkg list entire in the Global and Non-Global zones and the version is > the same. > > # pkg list entire > NAME (PUBLISHER) VERSION > IFO > *entire 11-0.151022 > i--* > > Could anyone help me out please? > > > _______________________________________________ > 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 Mon Feb 19 23:32:33 2018 From: danmcd at kebe.com (Dan McDonald) Date: Mon, 19 Feb 2018 18:32:33 -0500 Subject: [OmniOS-discuss] Cannot install Non-Global Zone In-Reply-To: References: Message-ID: <1CEF2366-FF0C-48B7-AB4A-4CB7BD190876@kebe.com> You may have software installed dependent on a specific version of entire. I can't tell you which one off the top of my head, but there are some well-known offenders in the old ms.omniti.com repo. Dan From softwareinforjam at gmail.com Tue Feb 20 02:54:21 2018 From: softwareinforjam at gmail.com (Software Information) Date: Mon, 19 Feb 2018 21:54:21 -0500 Subject: [OmniOS-discuss] Cannot install Non-Global Zone In-Reply-To: <1CEF2366-FF0C-48B7-AB4A-4CB7BD190876@kebe.com> References: <1CEF2366-FF0C-48B7-AB4A-4CB7BD190876@kebe.com> Message-ID: I see. Is there any way to enumerate these offending packages so I can uninstall them or will I have to do this by trial and error? Hope that doesn't sound like a silly question. On Mon, Feb 19, 2018 at 6:32 PM, Dan McDonald wrote: > You may have software installed dependent on a specific version of > entire. I can't tell you which one off the top of my head, but there are > some well-known offenders in the old ms.omniti.com repo. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omnios at citrus-it.net Tue Feb 20 08:06:11 2018 From: omnios at citrus-it.net (Andy Fiddaman) Date: Tue, 20 Feb 2018 08:06:11 +0000 (UTC) Subject: [OmniOS-discuss] Cannot install Non-Global Zone In-Reply-To: References: Message-ID: On Mon, 19 Feb 2018, Software Information wrote: ; Hi All ; I have been trying to understand the reason for an error I have been ; getting when I try to install a non-global zone. The error is below ; ; pkg install: The following pattern(s) did not match any allowable ; packages. Try ; using a different matching pattern, or refreshing publisher information: ; ; entire at 11-0.151022:20180108T221634Z ; ERROR: failed to install package Could you provide the output of the following commands from the global zone? pkg publisher pkg list -afv entire If you would like to debug this more interactively, feel free to join our gitter chat at https://gitter.im/omniosorg/Lobby or our IRC channel on freenode https://webchat.freenode.net/ - channel #omnios Thanks, Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From softwareinforjam at gmail.com Tue Feb 20 13:48:48 2018 From: softwareinforjam at gmail.com (Software Information) Date: Tue, 20 Feb 2018 08:48:48 -0500 Subject: [OmniOS-discuss] Cannot install Non-Global Zone In-Reply-To: References: Message-ID: Sure. Here is the output below. # pkg publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F https://pkg.omniosce.org/r151022/core/ # pkg list -afv entire FMRI IFO pkg://omnios/entire at 11-0.151022:20180108T221634Z i-- pkg://omnios/entire at 11-0.151022:20171031T101418Z --- pkg://omnios/entire at 11-0.151022:20170917T145315Z --- pkg://omnios/entire at 11-0.151022:20170511T002513Z --- # I don't mind joining the interactive chat at all. I am looking to really learn this OS so I put some services on it at work. I really like OmniOS. Liking it just as much as FreeBSD now and believe me, that is a huge compliment. Thanks for your assistance. On Tue, Feb 20, 2018 at 3:06 AM, Andy Fiddaman wrote: > > On Mon, 19 Feb 2018, Software Information wrote: > > ; Hi All > ; I have been trying to understand the reason for an error I have been > ; getting when I try to install a non-global zone. The error is below > ; > ; pkg install: The following pattern(s) did not match any allowable > ; packages. Try > ; using a different matching pattern, or refreshing publisher information: > ; > ; entire at 11-0.151022:20180108T221634Z > ; ERROR: failed to install package > > Could you provide the output of the following commands from the global > zone? > > pkg publisher > pkg list -afv entire > > If you would like to debug this more interactively, feel free to join our > gitter chat at https://gitter.im/omniosorg/Lobby or our IRC channel on > freenode https://webchat.freenode.net/ - channel #omnios > > Thanks, > > Andy > > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From groenveld at acm.org Tue Feb 20 14:26:25 2018 From: groenveld at acm.org (John D Groenveld) Date: Tue, 20 Feb 2018 09:26:25 -0500 Subject: [OmniOS-discuss] Cannot install Non-Global Zone In-Reply-To: Your message of "Mon, 19 Feb 2018 21:54:21 -0500." References: <1CEF2366-FF0C-48B7-AB4A-4CB7BD190876@kebe.com> Message-ID: <201802201426.w1KEQPkP013361@groenveld.us> In message , Software Information writes: >I see. Is there any way to enumerate these offending packages so I can >uninstall them or will I have to do this by trial and error? Hope that >doesn't sound like a silly question. Probably scriptable: # pkg -R /path/to/zone list -v | grep -v pkg://omnios/ # pkg -R /path/to/zone contents -m $PKG |grep depend John groenveld at acm.org From an3s.annema at gmail.com Tue Feb 20 19:18:14 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Tue, 20 Feb 2018 20:18:14 +0100 Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL inheritance) In-Reply-To: References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> Message-ID: Hi Andy, Good news help is on the way! I tried your suggestion below to install the patch, but I'm greeted with a long long list of "pkg update" rejections for at least one lipkg zone, like so: root at vm01omniosce~# pkg update -rv --be-name=omnios-patch8984 ??????????? Packages to update:??????? 1 ???? Estimated space available:? 9.59 GB Estimated space to be consumed: 19.63 MB ?????? Create boot environment:????? Yes ???? Activate boot environment:????? Yes Create backup boot environment:?????? No ????????? Rebuild boot archive:????? Yes Changed packages: omnios ? system/file-system/zfs ??? 0.5.11-0.151022:20171101T135758Z -> 0.5.11-0.151022:20180217T105027Z Planning linked: 0/8 done; 1 working: zone:vm01ngz01dns Linked progress: /pkg: update failed (linked image exception(s)): A 'update' operation failed for child 'zone:vm01ngz01dns' with an unexpected return value of 1 and generated the following output: pkg update: Package locale/gu must be uninstalled before the requested operation can be performed. ? Reject:? pkg://omnios/locale/gu at 0.5.11-0.151022 ? Reason:? No version matching 'require' dependency consolidation/osnet/osnet-incorporation can be installed Package library/libtool/libltdl must be uninstalled before the requested operation can be performed. ? Reject:? pkg://omnios/library/libtool/libltdl at 2.4.6-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 ????? ---------------------------------------- ????? Reject:? pkg://omnios/system/library 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 Package driver/network/chxge must be uninstalled before the requested operation can be performed. ? 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 <...snip...> If this report helps you guys in testing and debugging, then great! For me personally it's not a real necessity to get the hot-fix in place ASAP; I could just wait for the final fix. Thanks, Andries On 2018-02-18 20:43, Andy Fiddaman wrote: > On Sun, 18 Feb 2018, Andries Annema wrote: > > ; Playing around with r151022, I may have bumped into the same issue here. > ; The ACE's that I set on the parent directory are nicely inherited, but > ; on top of that, another ACE for owner@, group@ and everyone@ is added. > > Hi, > > This does sound like the same issue and we have a fix for this currently in > testing for OmniOS r151022 which we plan to upstream when it's ready. > > If you want to test the hot-fix, a package archive containing an updated > zfs pachage is available for download at: > > https://downloads.omniosce.org/pkg/8984_r151022.p5p > > to install please proceed as follows (assuming the downloaded archive > is in /root): > > # pkg set-publisher -g /root/8984_r151022.p5p omnios > # pkg update -v --be-name=... > # init 6 > # pkg set-publisher -G /root/8984_r151022.p5p omnios > > Andy > From an3s.annema at gmail.com Tue Feb 20 19:20:59 2018 From: an3s.annema at gmail.com (Andries Annema) Date: Tue, 20 Feb 2018 20:20:59 +0100 Subject: [OmniOS-discuss] issue 8984 (fix for 6764 breaks ACL inheritance) In-Reply-To: <20180218204724.GS4503@bender.it-sys.cpp.edu> References: <16d701d3a762$4529fe90$cf7dfbb0$@acm.org> <8f494f58-fffc-324f-affb-d0de1ddb782d@gmail.com> <20180218204724.GS4503@bender.it-sys.cpp.edu> Message-ID: <26770513-df7c-5aa9-4b15-4cc18cc53a13@gmail.com> Paul, Thanks for the insight! And thumbs up for the team working on this bug already. Cheers, On 2018-02-18 21:47, Paul B. Henson wrote: > On Sun, Feb 18, 2018 at 05:20:43PM +0100, Andries Annema wrote: >> Playing around with r151022, I may have bumped into the same issue here. >> The ACE's that I set on the parent directory are nicely inherited, but >> on top of that, another ACE for owner@, group@ and everyone@ is added. > Yup, that looks like it :(. > >> Another weird thing I noticed is that these unwanted ACE's are *only* >> added when the file is created directly from the command line on the >> server itself or from a non-global zone that has the dataset >> lofs-mounted; files created from a Windows client, through a CIFS/SMB >> mount, do *not* get the extra unwanted ACE's. Now, where the heck does >> that difference come from...?! > The underlying bug is a chmod is incorrectly executed during the > creation of the file using the requested creation mode (modified by > umask), resulting in an ACL based on your aclmode setting. If you're > using the in-kernel CIFS server, that bypasses the POSIX layer, and as > such the chmod isn't called and there's no brokenness to the ACL. > > Fortunately thanks to the great responsiveness of the omniosce team :), > as posted there is a fix available for testing already. We're going to be > applying it to our dev systems tomorrow to try out. From lists at mcintyreweb.com Fri Feb 23 08:41:37 2018 From: lists at mcintyreweb.com (Hugh McIntyre) Date: Fri, 23 Feb 2018 00:41:37 -0800 Subject: [OmniOS-discuss] Including fix for 8680 into r151022ce or r151024? Message-ID: I am seeing the same TOC clock bug described in #8680 ("Time of Day clock error"), in my case on an older non-Ryzen AMD motherboard. although NTP seems to fix the clock, it's annoying that some files early in boot may get incorrect dates. This is on r151022ce although OmniOSCE github repository contains the fixed version of usr/src/uts/i86pc/io/todpc_subr.c, so I assume this will exist in bloody releases. Can I expect this will show up in r151022ce (LTS) or r151024 automatically after some soak time though, or can I request this? It's not clear if the Gitter lobby or IRC is preferred for requests like this ... Hugh. From omnios at citrus-it.net Fri Feb 23 10:58:49 2018 From: omnios at citrus-it.net (Andy Fiddaman) Date: Fri, 23 Feb 2018 10:58:49 +0000 (UTC) Subject: [OmniOS-discuss] Including fix for 8680 into r151022ce or r151024? In-Reply-To: References: Message-ID: On Fri, 23 Feb 2018, Hugh McIntyre wrote: ; I am seeing the same TOC clock bug described in #8680 ("Time of Day clock ; error"), in my case on an older non-Ryzen AMD motherboard. although NTP seems ; to fix the clock, it's annoying that some files early in boot may get ; incorrect dates. ; ; This is on r151022ce although OmniOSCE github repository contains the fixed ; version of usr/src/uts/i86pc/io/todpc_subr.c, so I assume this will exist in ; bloody releases. ; ; Can I expect this will show up in r151022ce (LTS) or r151024 automatically ; after some soak time though, or can I request this? It's not clear if the ; Gitter lobby or IRC is preferred for requests like this ... Hi Hugh, I'll have a look at this and see whether it can be backported. Either way we will be able to provide an installable hot-fix for you early next week. The process that we use is to pull in changes from illumos gate and from Joyent's illumos fork weekly and then assess the changes for back-port, so if this is already in our bloody branch then it will not automatically appear in older versions; it was presumably not selected. The Gitter lobby is preferred for general support requests but we're also around on IRC and check the mailing list from time to time. The core team is all in Europe so there can be some latency due to time difference. Regards, Andy -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From omnios at citrus-it.net Mon Feb 26 15:35:28 2018 From: omnios at citrus-it.net (Andy Fiddaman) Date: Mon, 26 Feb 2018 15:35:28 +0000 (UTC) Subject: [OmniOS-discuss] Including fix for 8680 into r151022ce or r151024? In-Reply-To: References: Message-ID: Hugh, This fix has been included in the latest updates for r151022 & r151024 - see https://www.omniosce.org/article/releases-022ao-024q.html Andy On Fri, 23 Feb 2018, Andy Fiddaman wrote: ; On Fri, 23 Feb 2018, Hugh McIntyre wrote: ; ; ; I am seeing the same TOC clock bug described in #8680 ("Time of Day clock ; ; error"), in my case on an older non-Ryzen AMD motherboard. although NTP seems ; ; to fix the clock, it's annoying that some files early in boot may get ; ; incorrect dates. ; ; ; ; This is on r151022ce although OmniOSCE github repository contains the fixed ; ; version of usr/src/uts/i86pc/io/todpc_subr.c, so I assume this will exist in ; ; bloody releases. ; ; ; ; Can I expect this will show up in r151022ce (LTS) or r151024 automatically ; ; after some soak time though, or can I request this? It's not clear if the ; ; Gitter lobby or IRC is preferred for requests like this ... ; ; ; Hi Hugh, ; ; I'll have a look at this and see whether it can be backported. Either way ; we will be able to provide an installable hot-fix for you early next week. ; ; The process that we use is to pull in changes from illumos gate and from ; Joyent's illumos fork weekly and then assess the changes for back-port, so ; if this is already in our bloody branch then it will not automatically appear ; in older versions; it was presumably not selected. ; ; The Gitter lobby is preferred for general support requests but we're also ; around on IRC and check the mailing list from time to time. The core team ; is all in Europe so there can be some latency due to time difference. ; ; Regards, ; ; Andy ; ; -- Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From lists at mcintyreweb.com Mon Feb 26 19:04:45 2018 From: lists at mcintyreweb.com (lists at mcintyreweb.com) Date: Mon, 26 Feb 2018 11:04:45 -0800 Subject: [OmniOS-discuss] Including fix for 8680 into r151022ce or r151024? In-Reply-To: References: Message-ID: <1519671885.521210.1284066216.12A262A6@webmail.messagingengine.com> Hi Andy, Thanks! Fix installed and the error has gone away as expected. Hugh. On Mon, Feb 26, 2018, at 7:35 AM, Andy Fiddaman wrote: > > Hugh, > > This fix has been included in the latest updates for r151022 & r151024 > - see https://www.omniosce.org/article/releases-022ao-024q.html > > Andy > > On Fri, 23 Feb 2018, Andy Fiddaman wrote: > > ; On Fri, 23 Feb 2018, Hugh McIntyre wrote: > ; > ; ; I am seeing the same TOC clock bug described in #8680 ("Time of Day > clock > ; ; error"), in my case on an older non-Ryzen AMD motherboard. although > NTP seems > ; ; to fix the clock, it's annoying that some files early in boot may > get > ; ; incorrect dates. > ; ; > ; ; This is on r151022ce although OmniOSCE github repository contains > the fixed > ; ; version of usr/src/uts/i86pc/io/todpc_subr.c, so I assume this will > exist in > ; ; bloody releases. > ; ; > ; ; Can I expect this will show up in r151022ce (LTS) or r151024 > automatically > ; ; after some soak time though, or can I request this? It's not clear > if the > ; ; Gitter lobby or IRC is preferred for requests like this ... > ; > ; > ; Hi Hugh, > ; > ; I'll have a look at this and see whether it can be backported. Either > way > ; we will be able to provide an installable hot-fix for you early next > week. > ; > ; The process that we use is to pull in changes from illumos gate and > from > ; Joyent's illumos fork weekly and then assess the changes for back- > port, so > ; if this is already in our bloody branch then it will not automatically > appear > ; in older versions; it was presumably not selected. > ; > ; The Gitter lobby is preferred for general support requests but we're > also > ; around on IRC and check the mailing list from time to time. The core > team > ; is all in Europe so there can be some latency due to time difference. > ; > ; Regards, > ; > ; Andy > ; > ; > -- > Citrus IT Limited | +44 (0)333 0124 007 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 >