From john.barfield at bissinc.com Sat Apr 1 14:25:38 2017 From: john.barfield at bissinc.com (John Barfield) Date: Sat, 1 Apr 2017 14:25:38 +0000 Subject: [OmniOS-discuss] Bug 6569 r151020 Message-ID: <10108076-F9F7-474A-9604-DA644B05A88D@bissinc.com> Good morning, Simple question today...I couldnt find an itemized list of bugfixes that are rolled into the latest release version so I wanted to see if this: https://www.illumos.org/issues/6569 Is in r151020 or if I need to wait for the next LTS release, or if I needed to backport it. Thanks and have a great weekend! John Barfield -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Sat Apr 1 15:48:37 2017 From: daleg at omniti.com (Dale Ghent) Date: Sat, 1 Apr 2017 11:48:37 -0400 Subject: [OmniOS-discuss] Bug 6569 r151020 In-Reply-To: <10108076-F9F7-474A-9604-DA644B05A88D@bissinc.com> References: <10108076-F9F7-474A-9604-DA644B05A88D@bissinc.com> Message-ID: This isn't make it in to 020. It will be in the 022, the next LTS. We plan to make an announcement on that soon regarding its availability. BTW, if you're curious if a specific commit is present in a particular branch in git, you can clone the repo and make sure the branches you're interested in are activated, and run the command: git branch --contains and it will tell you which branch(es) that commit is in. /dale > On Apr 1, 2017, at 10:25 AM, John Barfield wrote: > > Good morning, > > Simple question today...I couldnt find an itemized list of bugfixes that are rolled into the latest release version so I wanted to see if this: > > https://www.illumos.org/issues/6569 > > Is in r151020 or if I need to wait for the next LTS release, or if I needed to backport it. > > Thanks and have a great weekend! > > John Barfield > _______________________________________________ > 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 john.barfield at bissinc.com Sat Apr 1 16:07:42 2017 From: john.barfield at bissinc.com (John Barfield) Date: Sat, 1 Apr 2017 16:07:42 +0000 Subject: [OmniOS-discuss] Bug 6569 r151020 In-Reply-To: References: <10108076-F9F7-474A-9604-DA644B05A88D@bissinc.com> Message-ID: <5C07486D-388F-4A45-B490-C937C67D0916@bissinc.com> Thanks for that! John Barfield Engineering and Stuff M: +1 (214) 425-0783 O: +1 (214) 506-8354 john.barfield at bissinc.com 4925 Greenville Ave, Ste 900 Dallas, TX 75206 For Support Requests: http://support.bissinc.com or support at bissinc.com Follow us on Twitter for Network Status & Updates! On 4/1/17, 10:48 AM, "Dale Ghent" wrote: This isn't make it in to 020. It will be in the 022, the next LTS. We plan to make an announcement on that soon regarding its availability. BTW, if you're curious if a specific commit is present in a particular branch in git, you can clone the repo and make sure the branches you're interested in are activated, and run the command: git branch --contains and it will tell you which branch(es) that commit is in. /dale > On Apr 1, 2017, at 10:25 AM, John Barfield wrote: > > Good morning, > > Simple question today...I couldnt find an itemized list of bugfixes that are rolled into the latest release version so I wanted to see if this: > > https://www.illumos.org/issues/6569 > > Is in r151020 or if I need to wait for the next LTS release, or if I needed to backport it. > > Thanks and have a great weekend! > > John Barfield > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Sat Apr 1 18:01:37 2017 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 1 Apr 2017 14:01:37 -0400 Subject: [OmniOS-discuss] Bug 6569 r151020 In-Reply-To: <5C07486D-388F-4A45-B490-C937C67D0916@bissinc.com> References: <10108076-F9F7-474A-9604-DA644B05A88D@bissinc.com> <5C07486D-388F-4A45-B490-C937C67D0916@bissinc.com> Message-ID: > On Apr 1, 2017, at 12:07 PM, John Barfield wrote: > > Thanks for that! Add "-a" to that git branch: git branch -a --contains That way you don't have to check out every branch in your local repo. Dan From mir at miras.org Sun Apr 2 21:30:33 2017 From: mir at miras.org (Michael Rasmussen) Date: Sun, 2 Apr 2017 23:30:33 +0200 Subject: [OmniOS-discuss] network configuration script Message-ID: <20170402233033.0a4747bf@sleipner.datanom.net> Hi all, I think it is not very easy for new users coming to Omnios from various other distros to make the initial network configuration so I have written a small tool in Python to remedy this obstacle. The script runs on all Omnios as of r151014. I have tested on r151014 and bloody (r151021) The script is not ment to be the swiss army knife for configuring networks on Omnios so there is no support for vnic, vlan, and aggregates. It will only support configuring a single nic given the user the option for dhcp and static setup. The user is also asked whether to configure dns in which case the user is asked for an IP. Currently it will only handle ethernet but IPoIB is on my todo list. I have attached the script here but if the file is to large it can also be downloaded here: http://git.datanom.net/netconf.git/ PS. If I want to have it included in Omnios what license should I use? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: It's illegal in Wilbur, Washington, to ride an ugly horse. -------------- next part -------------- A non-text attachment was scrubbed... Name: netconf Type: application/octet-stream Size: 6200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bfriesen at simple.dallas.tx.us Sun Apr 2 23:07:49 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 2 Apr 2017 18:07:49 -0500 (CDT) Subject: [OmniOS-discuss] Continuing hung-zone problems Message-ID: Previously I reported a problem (in the 040 timeframe) in that zones are hanging when being shut down. Problems continue on that system. Today I am seeing the same issue with a different OmniOS system (version is omnios-r151020-4151d05). In this case it was after doing 'init 6' to reboot the system and the problem added about 180 seconds to the shutdown time. In three reboots, the problem happened twice. This is logged: Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] failed to open console master: Device busy Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] WARNING: could not open master side of zone console for swdev to release slave handle: Device busy Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] WARNING: console /devices//pseudo/zconsnex at 1/zcons at 0 found, but it could not be removed.: I/O error Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to unmount '/zones/swdev/root/proc' Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to unmount file systems in zone Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to destroy zone Apr 2 17:51:53 velma svc.startd[10]: [ID 122153 daemon.warning] svc:/system/zones:default: Method or service exit timed out. Killing contract 169. Apr 2 17:51:53 velma svc.startd[10]: [ID 636263 daemon.warning] svc:/system/zones:default: Method "/lib/svc/method/svc-zones stop" failed due to signal KILL. And this is the zone configuration: create -b set zonepath=/zones/swdev set brand=lipkg set autoboot=true set limitpriv=default,dtrace_proc,dtrace_user set ip-type=exclusive add fs set dir=/scratch set special=/scratch set type=lofs end add net set physical=swdev0 end The zone does not use any particular resources, although it does act as a NFS client (via automounter). The NFS should not have been mounted at the time. Any ideas? Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From johan.kragsterman at capvert.se Mon Apr 3 06:46:02 2017 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 3 Apr 2017 08:46:02 +0200 Subject: [OmniOS-discuss] Ang: network configuration script In-Reply-To: <20170402233033.0a4747bf@sleipner.datanom.net> References: <20170402233033.0a4747bf@sleipner.datanom.net> Message-ID: Hi Michael and all! I think this is a good idea, thanks, Michael, but that is not the most important reason I respond this mail: I have been thinking for a while about all the nice scripts for different solutions people have been presenting here, both bash, py, perl, DTrace, etc. The people that have been creating them keep them in different places, and some of them are public, some are not. It would be nice to have a "script-market", placed somewhere where OmniOS users/developers could easily reach them, and with some description about their use, perhaps categorized. I don't know the right place for something like that, perhaps git? With links from the OmniOS website. What do you people think about that? Regards Johan -----"OmniOS-discuss" skrev: ----- Till: "omnios-discuss at lists.omniti.com" Fr?n: Michael Rasmussen S?nt av: "OmniOS-discuss" Datum: 2017-04-02 23:33 ?rende: [OmniOS-discuss] network configuration script Hi all, I think it is not very easy for new users coming to Omnios from various other distros to make the initial network configuration so I have written a small tool in Python to remedy this obstacle. The script runs on all Omnios as of r151014. I have tested on r151014 and bloody (r151021) The script is not ment to be the swiss army knife for configuring networks on Omnios so there is no support for vnic, vlan, and aggregates. It will only support configuring a single nic given the user the option for dhcp and static setup. The user is also asked whether to configure dns in which case the user is asked for an IP. Currently it will only handle ethernet but IPoIB is on my todo list. I have attached the script here but if the file is to large it can also be downloaded here: http://git.datanom.net/netconf.git/ PS. If I want to have it included in Omnios what license should I use? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: It's illegal in Wilbur, Washington, to ride an ugly horse. _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss [bilagan "netconf" borttagen av Johan Kragsterman/Capvert] [bilagan "att0uq4e.dat" borttagen av Johan Kragsterman/Capvert] From frank at boeye.net Mon Apr 3 10:48:11 2017 From: frank at boeye.net (Frank Boeye) Date: Mon, 3 Apr 2017 10:48:11 +0000 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue Message-ID: Hi guys, Following the upgrade instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151014 I am running into the following issue: /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 Creating Plan - pkg update: No matching version of entire can be installed: Reject: pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z Reason: All versions matching 'require' dependency pkg:/library/glib2 at 2.34.1,5.11-0.151016 are rejected Reject: pkg://omnios/library/glib2 at 2.34.1,5.11-0.151016:20151102T204001Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151016 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151102T203644Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151104T132510Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20160301T161406Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/entire at 11,5.11-0.151016:20151112T204605Z pkg://omnios/entire at 11,5.11-0.151016:20151202T161203Z Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151016 are rejected Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151016:20151102T185436Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151016 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151102T203644Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151104T132510Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20160301T161406Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z It seems that this problem has occurred earlier to some people, but I cannot seem to find a posted solution anywhere. Anyone have any clue? This is a very standard install including Napp-It on a proliant microserver. Thanks! Regards, -Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Mon Apr 3 12:34:36 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 3 Apr 2017 14:34:36 +0200 (CEST) Subject: [OmniOS-discuss] Ang: network configuration script In-Reply-To: References: <20170402233033.0a4747bf@sleipner.datanom.net> Message-ID: <328159580.95876.1491222876898.JavaMail.zimbra@oetiker.ch> maybe a page on the omnios wiki with pointers would be all that is needed cheers tobi ----- On Apr 3, 2017, at 8:46 AM, Johan Kragsterman johan.kragsterman at capvert.se wrote: > Hi Michael and all! > > > I think this is a good idea, thanks, Michael, but that is not the most important > reason I respond this mail: > > > I have been thinking for a while about all the nice scripts for different > solutions people have been presenting here, both bash, py, perl, DTrace, etc. > The people that have been creating them keep them in different places, and some > of them are public, some are not. > > It would be nice to have a "script-market", placed somewhere where OmniOS > users/developers could easily reach them, and with some description about their > use, perhaps categorized. I don't know the right place for something like that, > perhaps git? With links from the OmniOS website. > > What do you people think about that? > > Regards Johan > > > > > -----"OmniOS-discuss" skrev: ----- > Till: "omnios-discuss at lists.omniti.com" > Fr?n: Michael Rasmussen > S?nt av: "OmniOS-discuss" > Datum: 2017-04-02 23:33 > ?rende: [OmniOS-discuss] network configuration script > > Hi all, > > I think it is not very easy for new users coming to Omnios from various > other distros to make the initial network configuration so I have > written a small tool in Python to remedy this obstacle. The script runs > on all Omnios as of r151014. I have tested on r151014 and bloody > (r151021) > > The script is not ment to be the swiss army knife for configuring > networks on Omnios so there is no support for vnic, vlan, and > aggregates. It will only support configuring a single nic given the > user the option for dhcp and static setup. The user is also asked > whether to configure dns in which case the user is asked for an IP. > > Currently it will only handle ethernet but IPoIB is on my todo list. I > have attached the script here but if the file is to large it can also > be downloaded here: http://git.datanom.net/netconf.git/ > > PS. If I want to have it included in Omnios what license should I use? > > -- > Hilsen/Regards > Michael Rasmussen > > Get my public GnuPG keys: > michael rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > It's illegal in Wilbur, Washington, to ride an ugly horse. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > [bilagan "netconf" borttagen av Johan Kragsterman/Capvert] > [bilagan "att0uq4e.dat" borttagen av Johan Kragsterman/Capvert] > > > _______________________________________________ > 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 daleg at omniti.com Mon Apr 3 14:31:44 2017 From: daleg at omniti.com (Dale Ghent) Date: Mon, 3 Apr 2017 10:31:44 -0400 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: References: Message-ID: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> Hi Frank, some of the package names changed after 151014. Can you try this instead: /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server I'd also like to note that 016 might not be the best choice as its it a version of Stable which is no longer supported. Currently, the supported versions of OmniOS are the current LTS (151014) and the previous and current Stable releases (151018 and 151020 respectively). 151016 will not see any security updates. If you are looking for something newer than LTS, the current Stable is always the best choice regarding updates. /dale > On Apr 3, 2017, at 6:48 AM, Frank Boeye wrote: > > Hi guys, > > Following the upgrade instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151014 I am running into the following issue: > > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 > Creating Plan - > pkg update: No matching version of entire can be installed: > Reject: pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z > Reason: All versions matching 'require' dependency pkg:/library/glib2 at 2.34.1,5.11-0.151016 are rejected > Reject: pkg://omnios/library/glib2 at 2.34.1,5.11-0.151016:20151102T204001Z > Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151016 are rejected > Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151102T203644Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151104T132510Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20160301T161406Z > Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z > Reject: pkg://omnios/entire at 11,5.11-0.151016:20151112T204605Z > pkg://omnios/entire at 11,5.11-0.151016:20151202T161203Z > Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151016 are rejected > Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151016:20151102T185436Z > Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151016 are rejected > Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151102T203644Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151104T132510Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20160301T161406Z > Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z > > It seems that this problem has occurred earlier to some people, but I cannot seem to find a posted solution anywhere. > > Anyone have any clue? > > This is a very standard install including Napp-It on a proliant microserver. > > Thanks! > > Regards, > > -Frank > _______________________________________________ > 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 frank at boeye.net Mon Apr 3 14:59:35 2017 From: frank at boeye.net (Frank Boeye) Date: Mon, 3 Apr 2017 14:59:35 +0000 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> Message-ID: Hi Dale, Thanks for the info. I'm planning on going to 151020, but need an intermediate step from 151006. 151014 is fine as well. I've did the rejections below, then tried the update again, and got this: /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server Creating Plan pkg install: The following pattern(s) did not match any allowable packages. Try using a different matching pattern, or refreshing publisher information: pkg:/service/network/ssh-common root at ant-san:~# /usr/bin/pkg unset-publisher omnios root at ant-san:~# /usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g http://pkg.omniti.com/omnios/r151014/ omnios root at ant-san:~# /usr/bin/pkg update --be-name=omnios-r151014 entire at 11,5.11-0.151014 Creating Plan | pkg update: No matching version of entire can be installed: Reject: pkg://omnios/entire at 11,5.11-0.151014:20150402T192159Z Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151014 are rejected Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151014:20150402T174104Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/entire at 11,5.11-0.151014:20150727T183612Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150402T175117Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150417T182313Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150727T054625Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150818T161010Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150913T201525Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150914T194934Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150929T225303Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151112T210017Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151215T144929Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160204T172603Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160420T161518Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160603T031037Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151006:20130507T191035Z Reason: Excluded by proposed incorporation 'incorporation/jeos/omnios-userland' This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161027T152352Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161230T212400Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20170301T162827Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/entire at 11,5.11-0.151014:20150914T123242Z pkg://omnios/entire at 11,5.11-0.151014:20151112T205709Z pkg://omnios/entire at 11,5.11-0.151014:20151202T161039Z pkg://omnios/entire at 11,5.11-0.151014:20160104T154618Z pkg://omnios/entire at 11,5.11-0.151014:20160602T180308Z pkg://omnios/entire at 11,5.11-0.151014:20160607T003721Z Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151014 are rejected Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151014:20150402T174104Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/entire at 11,5.11-0.151014:20160804T055959Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150402T175117Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150417T182313Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150727T054625Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150818T161010Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150913T201525Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150914T194934Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150929T225303Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151112T210017Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151215T144929Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160204T172603Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160420T161518Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160603T031037Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151006:20130507T191035Z Reason: Excluded by proposed incorporation 'incorporation/jeos/omnios-userland' This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161027T152352Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161230T212400Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20170301T162827Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/entire at 11,5.11-0.151014:20160810T183311Z pkg://omnios/entire at 11,5.11-0.151014:20161027T172955Z Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151014 are rejected Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151014:20150402T174104Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Thanks! Regards, -Frank -----Original Message----- From: Dale Ghent [mailto:daleg at omniti.com] Sent: maandag 3 april 2017 16:32 To: Frank Boeye Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue Hi Frank, some of the package names changed after 151014. Can you try this instead: /usr/bin/pkg install --no-backup-be --reject pkg:/network/ssh --reject pkg:/network/ssh/ssh-key --reject pkg:/service/network/ssh --reject pkg:/service/network/ssh-common pkg:/network/openssh pkg:/network/openssh-server I'd also like to note that 016 might not be the best choice as its it a version of Stable which is no longer supported. Currently, the supported versions of OmniOS are the current LTS (151014) and the previous and current Stable releases (151018 and 151020 respectively). 151016 will not see any security updates. If you are looking for something newer than LTS, the current Stable is always the best choice regarding updates. /dale > On Apr 3, 2017, at 6:48 AM, Frank Boeye wrote: > > Hi guys, > > Following the upgrade instructions at https://omnios.omniti.com/wiki.php/Upgrade_to_r151014 I am running into the following issue: > > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 > Creating Plan - pkg update: No matching version of entire can be > installed: > Reject: pkg://omnios/entire at 11,5.11-0.151016:20151102T202622Z > Reason: All versions matching 'require' dependency pkg:/library/glib2 at 2.34.1,5.11-0.151016 are rejected > Reject: pkg://omnios/library/glib2 at 2.34.1,5.11-0.151016:20151102T204001Z > Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151016 are rejected > Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151102T203644Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151104T132510Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20160301T161406Z > Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z > Reject: pkg://omnios/entire at 11,5.11-0.151016:20151112T204605Z > pkg://omnios/entire at 11,5.11-0.151016:20151202T161203Z > Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151016 are rejected > Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151016:20151102T185436Z > Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151016 are rejected > Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151102T203644Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20151104T132510Z > pkg://omnios/runtime/perl at 5.16.1,5.11-0.151016:20160301T161406Z > Reason: This version is excluded by installed incorporation > pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z > > It seems that this problem has occurred earlier to some people, but I cannot seem to find a posted solution anywhere. > > Anyone have any clue? > > This is a very standard install including Napp-It on a proliant microserver. > > Thanks! > > Regards, > > -Frank > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Mon Apr 3 15:41:15 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 11:41:15 -0400 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <20170402233033.0a4747bf@sleipner.datanom.net> References: <20170402233033.0a4747bf@sleipner.datanom.net> Message-ID: <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> I'll need to take a look at this in depth. Our preferred license is CDDL. Take a look at the prototypes directory for sample headers for each: https://github.com/omniti-labs/illumos-omnios/tree/master/usr/src/prototypes/ One thing about this, and I need to try it of course, is whether or not this could be modified to scribble commands into /mnt/.initialboot as a bonus feature of the new Kayak interactive install? Say under a "post-install extras" sub-menu or something. Pardon the latency. Today is off for a number of reasons, and I won't be fully recombobulated until Tuesday. Thanks, Dan From danmcd at omniti.com Mon Apr 3 15:46:56 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 11:46:56 -0400 Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: References: Message-ID: > On Apr 2, 2017, at 7:07 PM, Bob Friesenhahn wrote: > > Previously I reported a problem (in the 040 timeframe) in that zones are hanging when being shut down. Problems continue on that system. Today I am seeing the same issue with a different OmniOS system (version is omnios-r151020-4151d05). > > In this case it was after doing 'init 6' to reboot the system and the problem added about 180 seconds to the shutdown time. In three reboots, the problem happened twice. If you have a shell available, you should inspect the available processes to see what all is stuck in where. pgrep -z is helpful, as well as: pstack pwdx pwdx(1) shows the PWD for a process. If the process is stuck with PWD== that can't be umounted until the process exits or changes PWD. If that pstack(1) command shows NOTHING, it means it's stuck doing something in the kernel. In that case, "mdb -k" may show you the processes from the kernel's pov: ::ps -t and then you can find the stuck process, and check out its threads in "mdb -k" by: ::findstack -v > This is logged: > > Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] failed to open console master: Device busy > Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] WARNING: could not open master side of zone console for swdev to release slave handle: Device busy > Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] WARNING: console /devices//pseudo/zconsnex at 1/zcons at 0 found, but it could not be removed.: I/O error > Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to unmount '/zones/swdev/root/proc' > Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to unmount file systems in zone > Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to destroy zone > Apr 2 17:51:53 velma svc.startd[10]: [ID 122153 daemon.warning] svc:/system/zones:default: Method or service exit timed out. Killing contract 169. > Apr 2 17:51:53 velma svc.startd[10]: [ID 636263 daemon.warning] svc:/system/zones:default: Method "/lib/svc/method/svc-zones stop" failed due to signal KILL. You did say you were using that zone as an NFS client. Perhaps one of the processes wasn't really done accessing a remote filesystem? I noticed the unmountable filesystem is procfs for that zone. I can't tell you why that's interesting off the top of my head, that IS interesting to know, however. Dan From mir at miras.org Mon Apr 3 16:01:37 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 3 Apr 2017 18:01:37 +0200 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> Message-ID: <20170403180137.7854db1b@sleipner.datanom.net> On Mon, 3 Apr 2017 11:41:15 -0400 Dan McDonald wrote: > I'll need to take a look at this in depth. > Sure ;-) > Our preferred license is CDDL. Take a look at the prototypes directory for sample headers for each: > > https://github.com/omniti-labs/illumos-omnios/tree/master/usr/src/prototypes/ > I have no particular reservation against a license I was just asking not to unintentionally exclude myself. > One thing about this, and I need to try it of course, is whether or not this could be modified to scribble commands into /mnt/.initialboot as a bonus feature of the new Kayak interactive install? Say under a "post-install extras" sub-menu or something. > I forgot to mention that it is my intention to make every parameter available through command line as well. Eg. if all necessary parameter is available from command line then use them and only return status code like 0 or 1. > Pardon the latency. Today is off for a number of reasons, and I won't be fully recombobulated until Tuesday. > I will make a new version later today which supports command line. Do you need the file attached here or can you live with that you have to fetch it from git? -- 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: Quantum Mechanics is God's version of "Trust me." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Mon Apr 3 16:03:21 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 12:03:21 -0400 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> Message-ID: <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> Dumb question: Do you have any non-OmniOS publishers like ms.omniti.com on this installation? If so, let's see if one of those is incorporate-blocking you. If not, you could try, thought this will produce more output: pkg update -v --be-name=omnios-r151014 entire at 11,5.11-0.151014 The output you have indicates perl & vim, being blocked by: pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Actually, also please include the output of: pkg contents -m runtime/perl/manual Thanks, Dan From bfriesen at simple.dallas.tx.us Mon Apr 3 17:40:41 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 3 Apr 2017 12:40:41 -0500 (CDT) Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: References: Message-ID: On Mon, 3 Apr 2017, Dan McDonald wrote: > > If you have a shell available, you should inspect the available processes to see what all is stuck in where. I will try to find some time for such activities. >> Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] failed to open console master: Device busy >> Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] WARNING: could not open master side of zone console for swdev to release slave handle: Device busy >> Apr 2 17:50:13 velma zoneadmd[653]: [ID 702911 daemon.error] [zone 'swdev'] WARNING: console /devices//pseudo/zconsnex at 1/zcons at 0 found, but it could not be removed.: I/O error >> Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to unmount '/zones/swdev/root/proc' >> Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to unmount file systems in zone >> Apr 2 17:51:29 velma zoneadmd[1842]: [ID 702911 daemon.error] [zone 'swdev'] unable to destroy zone >> Apr 2 17:51:53 velma svc.startd[10]: [ID 122153 daemon.warning] svc:/system/zones:default: Method or service exit timed out. Killing contract 169. >> Apr 2 17:51:53 velma svc.startd[10]: [ID 636263 daemon.warning] svc:/system/zones:default: Method "/lib/svc/method/svc-zones stop" failed due to signal KILL. > > You did say you were using that zone as an NFS client. Perhaps one of the processes wasn't really done accessing a remote filesystem? I noticed the unmountable filesystem is procfs for that zone. I can't tell you why that's interesting off the top of my head, that IS interesting to know, however. The zone uses the automounter and NFS mounts would not have been made due to the zone simply having been booted for a minute or two. All of my zones (some of which do not use NFS and have almost every network service disabled) on my two OmniOS systems are equally plagued with this issue. I know that I am not alone since others have reported that this is happening to them. The zone configuration seems quite simple. Is there something about it which might cause an issue? The common theme is always the first message "failed to open console master: Device busy". The failure to unmount filesystems is new to me. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From frank at boeye.net Mon Apr 3 17:47:22 2017 From: frank at boeye.net (Frank Boeye) Date: Mon, 3 Apr 2017 17:47:22 +0000 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> Message-ID: <69f8728570224837ae56c5d2fd4608fd@boeye.net> No other publisher: root at ant-san:~# pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/r151014/ root at ant-san:~# I's not a dumb question, I had to google around a bit for that :) I've did a rather basic system install, then just deployed napp-it over it. I'm not really a solaris dude, so thanks for bearing with me :D Further output: root at ant-san:~# pkg update -v --be-name=omnios-r151014 entire at 11,5.11-0.151014 Creating Plan | pkg update: No matching version of entire can be installed: Reject: pkg://omnios/entire at 11,5.11-0.151014:20150402T192159Z Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151014 are rejected Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151014:20150402T174104Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/entire at 11,5.11-0.151014:20150727T183612Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150402T175117Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150417T182313Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150727T054625Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150818T161010Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150913T201525Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150914T194934Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150929T225303Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151112T210017Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151215T144929Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160204T172603Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160420T161518Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160603T031037Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151006:20130507T191035Z Reason: Excluded by proposed incorporation 'incorporation/jeos/omnios-userland' This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161027T152352Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161230T212400Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20170301T162827Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/entire at 11,5.11-0.151014:20150914T123242Z pkg://omnios/entire at 11,5.11-0.151014:20151112T205709Z pkg://omnios/entire at 11,5.11-0.151014:20151202T161039Z pkg://omnios/entire at 11,5.11-0.151014:20160104T154618Z pkg://omnios/entire at 11,5.11-0.151014:20160602T180308Z pkg://omnios/entire at 11,5.11-0.151014:20160607T003721Z Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151014 are rejected Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151014:20150402T174104Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/entire at 11,5.11-0.151014:20160804T055959Z Reason: All versions matching 'require' dependency pkg:/SUNWcs at 0.5.11,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150402T175117Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150417T182313Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150727T054625Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150818T161010Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150913T201525Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150914T194934Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20150929T225303Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151112T210017Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20151215T144929Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160204T172603Z pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160420T161518Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20160603T031037Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151006:20130507T191035Z Reason: Excluded by proposed incorporation 'incorporation/jeos/omnios-userland' This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161027T152352Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20161230T212400Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/SUNWcs at 0.5.11,5.11-0.151014:20170301T162827Z Reason: All versions matching 'require' dependency pkg:/runtime/perl are rejected Reject: pkg://omnios/entire at 11,5.11-0.151014:20160810T183311Z pkg://omnios/entire at 11,5.11-0.151014:20161027T172955Z Reason: All versions matching 'require' dependency pkg:/editor/vim at 7.3,5.11-0.151014 are rejected Reject: pkg://omnios/editor/vim at 7.4.45,5.11-0.151014:20150402T174104Z Reason: All versions matching 'require' dependency pkg:/runtime/perl at 5.16.1,5.11-0.151014 are rejected Reject: pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20150402T192953Z pkg://omnios/runtime/perl at 5.16.1,5.11-0.151014:20160301T161253Z Reason: This version is excluded by installed incorporation pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z More output: pkg contents -m runtime/perl/manual set name=pkg.fmri value=pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z set name=pkg.summary value="Perl 5.16.1 Programming Language Docs" set name=pkg.descr value="Perl 5.16.1 Programming Language Docs" set name=publisher value=sa at omniti.com file 80eb1eb144aa8dc55993e8e368ca8189e7911bb4 chash=cce029c54848ec6178ebd419fd738dd15b671f60 group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2html pkg.csize=927 pkg.size=2064 file 6360c1a609c5a72aa3380f5d2a9f1a576fb2e640 chash=be1ecb4772c547a9f7739a28303230c8aac6200b group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2latex pkg.csize=3804 pkg.size=10378 file 5d088db441e21d8faa653427ce905e7125da852e chash=0ff7255b30bd6a2e216c4b20aa6de36780863cf4 group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2man pkg.csize=4791 pkg.size=11615 file a7dd55d275470b2fca194799c30cd04cb0d53d14 chash=9d97ff341806398db56fd3b3ba5025c48cefcb08 group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2text pkg.csize=3778 pkg.size=9158 Bunch more files file 704d896209dafbb4bd55a3e054273b9ee3c2968c chash=e7cc73a54f163ad5aacf8265641bb0e9610c80d0 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/utf8.3 pkg.csize=4590 pkg.size=12203 file 658bdc92fe9df6d61b2d645be5c4e8b5f1faa68a chash=17d77b6c181ba716d8d78b862aa049d5e624e7c1 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/vars.3 pkg.csize=2370 pkg.size=5193 file 7946cf41e4289d078292daaa3a5b97e29dbd8a20 chash=0b7d398714a70ce146727254ea2542d041b5650d group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/version.3 pkg.csize=5668 pkg.size=15576 file 77cb31e7b3765e1ec0886fd8a11b5af97dda9a56 chash=38552cdd0c7e8f4ce5d1f18a40312dcfda92337c group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/version::Internals.3 pkg.csize=11021 pkg.size=31868 file 24f98111b69a8b09970c6d50765c8e0c02c93368 chash=f69e790ebd4c26817756a41cc45c4671145f3445 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/vmsish.3 pkg.csize=3298 pkg.size=7992 file b5351f32a043da6782154f3fb3b8906db003895e chash=57e11931fe6ce73af627a4652d3cbb714e7a5434 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/warnings.3 pkg.csize=2759 pkg.size=8740 file 9b9ec1c4b3b6918b873126b2a1ce76164b199bfa chash=7155a3420e0f13f2609a5a740581627c94a77af8 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/warnings::register.3 pkg.csize=1855 pkg.size=4138 license 8db6c3c8a577b36129555ff15dabf691b4a73c55 chash=8f1b2dd37aec20d7b4aaf4ae32bc7b8501678f79 license=Artistic pkg.csize=2416 pkg.size=6321 depend fmri=runtime/perl at 5.16.1,5.11-0.151006 type=incorporate depend fmri=runtime/perl at 5.16.1,5.11-0.151006 type=require Thanks! -Frank -----Original Message----- From: Dan McDonald [mailto:danmcd at omniti.com] Sent: maandag 3 april 2017 18:03 To: Frank Boeye ; Dan McDonald Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue Dumb question: Do you have any non-OmniOS publishers like ms.omniti.com on this installation? If so, let's see if one of those is incorporate-blocking you. If not, you could try, thought this will produce more output: pkg update -v --be-name=omnios-r151014 entire at 11,5.11-0.151014 The output you have indicates perl & vim, being blocked by: pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z Actually, also please include the output of: pkg contents -m runtime/perl/manual Thanks, Dan From danmcd at omniti.com Mon Apr 3 17:53:18 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 13:53:18 -0400 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <20170403180137.7854db1b@sleipner.datanom.net> References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> <20170403180137.7854db1b@sleipner.datanom.net> Message-ID: <198AF893-54B2-4B0D-9DA0-9C4E8D6B1648@omniti.com> > On Apr 3, 2017, at 12:01 PM, Michael Rasmussen wrote: > > I will make a new version later today which supports command line. Do > you need the file attached here or can you live with that you have to > fetch it from git? Git is fine assuming the URL you mentioned earlier is the correct repo. Otherwise, I'll need a URL from which I can "git clone". Dan From danmcd at omniti.com Mon Apr 3 17:59:01 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 13:59:01 -0400 Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: References: Message-ID: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> > On Apr 3, 2017, at 1:40 PM, Bob Friesenhahn wrote: > > The common theme is always the first message "failed to open console master: Device busy". The failure to unmount filesystems is new to me. That could be something from the LX code, but I'm not seeing it in my 020 zones (and I've several of them). > All of my zones (some of which do not use NFS and have almost every network service disabled) on my two OmniOS systems are equally plagued with this issue. I know that I am not alone since others have reported that this is happening to them. I've probably missed out on those mails, but who else has seen this issue (precisely zones taking forever to shutdown)? I know about the message, but I don't see zones being jammed up on shutdown. I wonder if it's "init 6" specifically? I use reboot(1M) command, so it does not go through the inittab(4) sequence. Now I'm more fascinated to know what process(es) are hanging, because I suspect they arrive via "init 6". Dan From bfriesen at simple.dallas.tx.us Mon Apr 3 18:11:35 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 3 Apr 2017 13:11:35 -0500 (CDT) Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> References: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> Message-ID: On Mon, 3 Apr 2017, Dan McDonald wrote: > >> All of my zones (some of which do not use NFS and have almost every network service disabled) on my two OmniOS systems are equally plagued with this issue. I know that I am not alone since others have reported that this is happening to them. > > I've probably missed out on those mails, but who else has seen this issue (precisely zones taking forever to shutdown)? I know about the message, but I don't see zones being jammed up on shutdown. Here is a link to the previous discussion thread: http://lists.omniti.com/pipermail/omnios-discuss/2015-December/thread.html#6073 > I wonder if it's "init 6" specifically? I use reboot(1M) command, > so it does not go through the inittab(4) sequence. Now I'm more > fascinated to know what process(es) are hanging, because I suspect > they arrive via "init 6". The problem is definintely with zone 'shutdown'. I have never seen it happen with 'reboot' or 'halt'. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Mon Apr 3 18:36:38 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 14:36:38 -0400 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: <69f8728570224837ae56c5d2fd4608fd@boeye.net> References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> <69f8728570224837ae56c5d2fd4608fd@boeye.net> Message-ID: <81CA2235-734F-4E0F-BE9A-8F8568A0684D@omniti.com> I see the problem... > On Apr 3, 2017, at 1:47 PM, Frank Boeye wrote: > > pkg contents -m runtime/perl/manual > > set name=pkg.fmri value=pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T191120Z > set name=pkg.summary value="Perl 5.16.1 Programming Language Docs" > set name=pkg.descr value="Perl 5.16.1 Programming Language Docs" > set name=publisher value=sa at omniti.com > file 80eb1eb144aa8dc55993e8e368ca8189e7911bb4 chash=cce029c54848ec6178ebd419fd738dd15b671f60 group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2html pkg.csize=927 pkg.size=2064 > file 6360c1a609c5a72aa3380f5d2a9f1a576fb2e640 chash=be1ecb4772c547a9f7739a28303230c8aac6200b group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2latex pkg.csize=3804 pkg.size=10378 > file 5d088db441e21d8faa653427ce905e7125da852e chash=0ff7255b30bd6a2e216c4b20aa6de36780863cf4 group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2man pkg.csize=4791 pkg.size=11615 > file a7dd55d275470b2fca194799c30cd04cb0d53d14 chash=9d97ff341806398db56fd3b3ba5025c48cefcb08 group=bin mode=0755 owner=root path=usr/perl5/5.16.1/bin/pod2text pkg.csize=3778 pkg.size=9158 > > Bunch more files > > file 704d896209dafbb4bd55a3e054273b9ee3c2968c chash=e7cc73a54f163ad5aacf8265641bb0e9610c80d0 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/utf8.3 pkg.csize=4590 pkg.size=12203 > file 658bdc92fe9df6d61b2d645be5c4e8b5f1faa68a chash=17d77b6c181ba716d8d78b862aa049d5e624e7c1 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/vars.3 pkg.csize=2370 pkg.size=5193 > file 7946cf41e4289d078292daaa3a5b97e29dbd8a20 chash=0b7d398714a70ce146727254ea2542d041b5650d group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/version.3 pkg.csize=5668 pkg.size=15576 > file 77cb31e7b3765e1ec0886fd8a11b5af97dda9a56 chash=38552cdd0c7e8f4ce5d1f18a40312dcfda92337c group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/version::Internals.3 pkg.csize=11021 pkg.size=31868 > file 24f98111b69a8b09970c6d50765c8e0c02c93368 chash=f69e790ebd4c26817756a41cc45c4671145f3445 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/vmsish.3 pkg.csize=3298 pkg.size=7992 > file b5351f32a043da6782154f3fb3b8906db003895e chash=57e11931fe6ce73af627a4652d3cbb714e7a5434 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/warnings.3 pkg.csize=2759 pkg.size=8740 > file 9b9ec1c4b3b6918b873126b2a1ce76164b199bfa chash=7155a3420e0f13f2609a5a740581627c94a77af8 group=bin mode=0644 owner=root path=usr/perl5/5.16.1/man/man3/warnings::register.3 pkg.csize=1855 pkg.size=4138 > license 8db6c3c8a577b36129555ff15dabf691b4a73c55 chash=8f1b2dd37aec20d7b4aaf4ae32bc7b8501678f79 license=Artistic pkg.csize=2416 pkg.size=6321 > depend fmri=runtime/perl at 5.16.1,5.11-0.151006 type=incorporate > depend fmri=runtime/perl at 5.16.1,5.11-0.151006 type=require Wow! I don't know how runtime/perl/manual ended up with an INCORPORATE dependency, but that's what happened. I have one other suggestion: - Please just do a vanilla "pkg update" of your 006 first. It may create a new BE, BUT it will update all of the packages. The revision on your runtime/perl/manual is VERY VERY OLD, and has this INCORPORATE dependency which is fixed by later revisions within 006. I should've said this earlier: You can't update to a whole new revision until your OLD revision is at its latest possible update. Please try that and report back. Thank you, Dan From danmcd at omniti.com Mon Apr 3 18:59:17 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 14:59:17 -0400 Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: References: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> Message-ID: <73AF2309-3366-462D-AEF1-463FA74EB66A@omniti.com> > On Apr 3, 2017, at 2:11 PM, Bob Friesenhahn wrote: > > The problem is definintely with zone 'shutdown'. I have never seen it happen with 'reboot' or 'halt'. Which does go through the inittab things. I've found something. I can reproduce this on bloody easily: bloody(~)[0]% sudo zoneadm -z lipkg0 shutdown zone 'lipkg0': unable to shutdown zone bloody(~)[1]% zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / ipkg shared 1 lx1 running /zones/lx1 lx excl 2 lx0 running /zones/lx0 lx excl 3 lx2 running /zones/lx2 lx excl 4 lipkg0 shutting_down /zones/lipkg0 lipkg excl bloody(~)[0]% pgrep -z lipkg0 764 bloody(~)[0]% Process 764 is a zsched process. It's here: > 0xffffff007d61fc40::findstack -v stack pointer for thread ffffff007d61fc40: ffffff007d61f950 [ ffffff007d61f950 _resume_from_idle+0x112() ] ffffff007d61f980 swtch+0x141() ffffff007d61f9c0 cv_wait+0x70(ffffff1955618148, fffffffffbcf8610) ffffff007d61fa50 zone_status_wait_cpr+0xb5(ffffff1955618000, 8, fffffffffbb82a3d) ffffff007d61fb30 zsched+0x5f0(ffffff007dfbacf0) ffffff007d61fb40 thread_start+8() Which is in this function: 3007 /* 3008 * Private CPR-safe version of zone_status_wait(). 3009 */ 3010 static void 3011 zone_status_wait_cpr(zone_t *zone, zone_status_t status, char *str) 3012 { 3013 callb_cpr_t cprinfo; 3014 3015 ASSERT(status > ZONE_MIN_STATE && status <= ZONE_MAX_STATE); 3016 3017 CALLB_CPR_INIT(&cprinfo, &zone_status_lock, callb_generic_cpr, 3018 str); 3019 mutex_enter(&zone_status_lock); 3020 while (zone->zone_status < status) { 3021 CALLB_CPR_SAFE_BEGIN(&cprinfo); 3022 cv_wait(&zone->zone_cv, &zone_status_lock); 3023 CALLB_CPR_SAFE_END(&cprinfo, &zone_status_lock); 3024 } 3025 /* 3026 * zone_status_lock is implicitly released by the following. 3027 */ 3028 CALLB_CPR_EXIT(&cprinfo); 3029 } Okay. I will be diving into this now to see WTF happened. I'm sorry for not paying closer attention to this sooner. Dan From mir at miras.org Mon Apr 3 19:00:33 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 3 Apr 2017 21:00:33 +0200 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <198AF893-54B2-4B0D-9DA0-9C4E8D6B1648@omniti.com> References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> <20170403180137.7854db1b@sleipner.datanom.net> <198AF893-54B2-4B0D-9DA0-9C4E8D6B1648@omniti.com> Message-ID: <20170403210033.793c7fc8@sleipner.datanom.net> On Mon, 3 Apr 2017 13:53:18 -0400 Dan McDonald wrote: > > Git is fine assuming the URL you mentioned earlier is the correct repo. Otherwise, I'll need a URL from which I can "git clone". > The URL is correct and works. -- 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: Real Users never use the Help key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Mon Apr 3 19:18:42 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 15:18:42 -0400 Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: <73AF2309-3366-462D-AEF1-463FA74EB66A@omniti.com> References: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> <73AF2309-3366-462D-AEF1-463FA74EB66A@omniti.com> Message-ID: > On Apr 3, 2017, at 2:59 PM, Dan McDonald wrote: > > Okay. I will be diving into this now to see WTF happened. I'm sorry for not paying closer attention to this sooner. AND THINGS GET WEIRDER. After the failure I documented earlier, I went off to do something else. When I came back, the zsched process was gone, and the zone appeared to be properly shut down. So I booted the zone, and uttered "zoneadm -z lipkg0 shutdown". THIS TIME IT WORKED! I noticed *this* in my /var/adm/messages: Apr 3 15:15:46 bloody genunix: [ID 408114 kern.info] /pseudo/zconsnex at 1/zcons at 2 (zcons2) online This makes me wonder if something happens wrong the first time a zcons is created. I'll try this again on another box I can reboot fully if need be. Dan From danmcd at omniti.com Mon Apr 3 19:35:34 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 15:35:34 -0400 Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: References: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> <73AF2309-3366-462D-AEF1-463FA74EB66A@omniti.com> Message-ID: > On Apr 3, 2017, at 3:18 PM, Dan McDonald wrote: > > AND THINGS GET WEIRDER. > > After the failure I documented earlier, I went off to do something else. When I came back, the zsched process was gone, and the zone appeared to be properly shut down. > > So I booted the zone, and uttered "zoneadm -z lipkg0 shutdown". THIS TIME IT WORKED! But trying it again failed. Okay, I see what happened. 1st shutdown failed. I tried a 2nd shutdown, which also failed, BUT managed to unwedge zsched, likely by calling zone_destroy() and having the right thing happen. Sorry for rubberducking on the public mailing list. :) Dan From bfriesen at simple.dallas.tx.us Mon Apr 3 19:38:07 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 3 Apr 2017 14:38:07 -0500 (CDT) Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: References: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> <73AF2309-3366-462D-AEF1-463FA74EB66A@omniti.com> Message-ID: On Mon, 3 Apr 2017, Dan McDonald wrote: > > This makes me wonder if something happens wrong the first time a > zcons is created. I'll try this again on another box I can reboot > fully if need be. It seems like an ordering or race condition to me. It should not be necessary to reboot the whole system in order to test. Some percentage (30%?) of zone shutdowns are afflicted. It does not seem that you obtained the same initial error message ("failed to open console master: Device busy") that I always do. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Mon Apr 3 19:50:09 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 15:50:09 -0400 Subject: [OmniOS-discuss] Continuing hung-zone problems In-Reply-To: References: <0668997A-1DC2-4D9A-9BD7-1B48512B2027@omniti.com> <73AF2309-3366-462D-AEF1-463FA74EB66A@omniti.com> Message-ID: <3BC28FA8-8C2B-431B-B923-382715EE0FD5@omniti.com> > On Apr 3, 2017, at 3:38 PM, Bob Friesenhahn wrote: > > It does not seem that you obtained the same initial error message ("failed to open console master: Device busy") that I always do. When it fails, I *DO* see this. Apr 3 15:22:16 bloody zoneadmd[3639]: [ID 702911 daemon.error] [zone 'lipkg0'] failed to open console master: Device busy Apr 3 15:22:16 bloody zoneadmd[3639]: [ID 702911 daemon.error] [zone 'lipkg0'] WARNING: could not open master side of zone console for lipkg0 to release slave handle: Device busy Apr 3 15:22:16 bloody zoneadmd[3639]: [ID 702911 daemon.error] [zone 'lipkg0'] WARNING: console /devices//pseudo/zconsnex at 1/zcons at 2 found, but it could not be removed.: I/O error And you may be right about it being a race of some sort. But between what entities I cannot tell as of yet. As of this second, I cannot get this error to manifest. Dan From frank at boeye.net Mon Apr 3 20:11:31 2017 From: frank at boeye.net (Frank Boeye) Date: Mon, 3 Apr 2017 20:11:31 +0000 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: <81CA2235-734F-4E0F-BE9A-8F8568A0684D@omniti.com> References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> <69f8728570224837ae56c5d2fd4608fd@boeye.net> <81CA2235-734F-4E0F-BE9A-8F8568A0684D@omniti.com> Message-ID: <2cf7028b5745416f91c50ed686d5a72b@boeye.net> Hi, I've had a feeling that i'd probably have to do a regular update first. I've tried this before but ran into the following: root at ant-san:~# pkg update Creating Plan - pkg update: The certificate which issued this certificate:/C=US/ST=Maryland/O=OmniTI/OU=OmniOS/CN=OmniOS r151014 Release Signing Certificate/emailAddress=omnios-support at omniti.com could not be found. The issuer is:/C=US/ST=Maryland/L=Fulton/O=OmniTI/CN=OmniTI Certificate Authority The package involved is:pkg://omnios/locale/gu at 0.5.11,5.11-0.151014:20170301T162851Z Do I need to specify an old repository or publisher first again then? Thanks! -Frank -----Original Message----- From: Dan McDonald [mailto:danmcd at omniti.com] Sent: maandag 3 april 2017 20:37 To: Frank Boeye ; Dan McDonald Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue I see the problem... > On Apr 3, 2017, at 1:47 PM, Frank Boeye wrote: > > pkg contents -m runtime/perl/manual > > set name=pkg.fmri > value=pkg://omnios/runtime/perl/manual at 5.16.1,5.11-0.151006:20130507T1 > 91120Z set name=pkg.summary value="Perl 5.16.1 Programming Language > Docs" > set name=pkg.descr value="Perl 5.16.1 Programming Language Docs" > set name=publisher value=sa at omniti.com file > 80eb1eb144aa8dc55993e8e368ca8189e7911bb4 > chash=cce029c54848ec6178ebd419fd738dd15b671f60 group=bin mode=0755 > owner=root path=usr/perl5/5.16.1/bin/pod2html pkg.csize=927 > pkg.size=2064 file 6360c1a609c5a72aa3380f5d2a9f1a576fb2e640 > chash=be1ecb4772c547a9f7739a28303230c8aac6200b group=bin mode=0755 > owner=root path=usr/perl5/5.16.1/bin/pod2latex pkg.csize=3804 > pkg.size=10378 file 5d088db441e21d8faa653427ce905e7125da852e > chash=0ff7255b30bd6a2e216c4b20aa6de36780863cf4 group=bin mode=0755 > owner=root path=usr/perl5/5.16.1/bin/pod2man pkg.csize=4791 > pkg.size=11615 file a7dd55d275470b2fca194799c30cd04cb0d53d14 > chash=9d97ff341806398db56fd3b3ba5025c48cefcb08 group=bin mode=0755 > owner=root path=usr/perl5/5.16.1/bin/pod2text pkg.csize=3778 > pkg.size=9158 Bunch more files file > 704d896209dafbb4bd55a3e054273b9ee3c2968c > chash=e7cc73a54f163ad5aacf8265641bb0e9610c80d0 group=bin mode=0644 > owner=root path=usr/perl5/5.16.1/man/man3/utf8.3 pkg.csize=4590 > pkg.size=12203 file 658bdc92fe9df6d61b2d645be5c4e8b5f1faa68a > chash=17d77b6c181ba716d8d78b862aa049d5e624e7c1 group=bin mode=0644 > owner=root path=usr/perl5/5.16.1/man/man3/vars.3 pkg.csize=2370 > pkg.size=5193 file 7946cf41e4289d078292daaa3a5b97e29dbd8a20 > chash=0b7d398714a70ce146727254ea2542d041b5650d group=bin mode=0644 > owner=root path=usr/perl5/5.16.1/man/man3/version.3 pkg.csize=5668 > pkg.size=15576 file 77cb31e7b3765e1ec0886fd8a11b5af97dda9a56 > chash=38552cdd0c7e8f4ce5d1f18a40312dcfda92337c group=bin mode=0644 > owner=root path=usr/perl5/5.16.1/man/man3/version::Internals.3 > pkg.csize=11021 pkg.size=31868 file > 24f98111b69a8b09970c6d50765c8e0c02c93368 > chash=f69e790ebd4c26817756a41cc45c4671145f3445 group=bin mode=0644 > owner=root path=usr/perl5/5.16.1/man/man3/vmsish.3 pkg.csize=3298 > pkg.size=7992 file b5351f32a043da6782154f3fb3b8906db003895e > chash=57e11931fe6ce73af627a4652d3cbb714e7a5434 group=bin mode=0644 > owner=root path=usr/perl5/5.16.1/man/man3/warnings.3 pkg.csize=2759 > pkg.size=8740 file 9b9ec1c4b3b6918b873126b2a1ce76164b199bfa > chash=7155a3420e0f13f2609a5a740581627c94a77af8 group=bin mode=0644 > owner=root path=usr/perl5/5.16.1/man/man3/warnings::register.3 > pkg.csize=1855 pkg.size=4138 license > 8db6c3c8a577b36129555ff15dabf691b4a73c55 > chash=8f1b2dd37aec20d7b4aaf4ae32bc7b8501678f79 license=Artistic > pkg.csize=2416 pkg.size=6321 depend > fmri=runtime/perl at 5.16.1,5.11-0.151006 type=incorporate depend > fmri=runtime/perl at 5.16.1,5.11-0.151006 type=require Wow! I don't know how runtime/perl/manual ended up with an INCORPORATE dependency, but that's what happened. I have one other suggestion: - Please just do a vanilla "pkg update" of your 006 first. It may create a new BE, BUT it will update all of the packages. The revision on your runtime/perl/manual is VERY VERY OLD, and has this INCORPORATE dependency which is fixed by later revisions within 006. I should've said this earlier: You can't update to a whole new revision until your OLD revision is at its latest possible update. Please try that and report back. Thank you, Dan From danmcd at omniti.com Mon Apr 3 20:15:37 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 16:15:37 -0400 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: <2cf7028b5745416f91c50ed686d5a72b@boeye.net> References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> <69f8728570224837ae56c5d2fd4608fd@boeye.net> <81CA2235-734F-4E0F-BE9A-8F8568A0684D@omniti.com> <2cf7028b5745416f91c50ed686d5a72b@boeye.net> Message-ID: <4F8EA203-BA89-4E23-8E58-922CCECEF519@omniti.com> > On Apr 3, 2017, at 4:11 PM, Frank Boeye wrote: > > Do I need to specify an old repository or publisher first again then? Yes. Sorry for not being clear about that. You need to go back to the 006 publisher and get it all-the-way updated. Dan From frank at boeye.net Mon Apr 3 20:19:22 2017 From: frank at boeye.net (Frank Boeye) Date: Mon, 3 Apr 2017 20:19:22 +0000 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: <4F8EA203-BA89-4E23-8E58-922CCECEF519@omniti.com> References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> <69f8728570224837ae56c5d2fd4608fd@boeye.net> <81CA2235-734F-4E0F-BE9A-8F8568A0684D@omniti.com> <2cf7028b5745416f91c50ed686d5a72b@boeye.net> <4F8EA203-BA89-4E23-8E58-922CCECEF519@omniti.com> Message-ID: Thought so. Can you help me in the right direction on what the correct publisher is for 006? http://pkg.omniti.com/omnios/r151006/ obviously is incorrect, and I can't seem to find it online. Thanks! -Frank -----Original Message----- From: Dan McDonald [mailto:danmcd at omniti.com] Sent: maandag 3 april 2017 22:16 To: Frank Boeye ; Dan McDonald Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue > On Apr 3, 2017, at 4:11 PM, Frank Boeye wrote: > > Do I need to specify an old repository or publisher first again then? Yes. Sorry for not being clear about that. You need to go back to the 006 publisher and get it all-the-way updated. Dan From rjahnel at ellipseinc.com Mon Apr 3 20:39:10 2017 From: rjahnel at ellipseinc.com (Richard Jahnel) Date: Mon, 3 Apr 2017 20:39:10 +0000 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> <69f8728570224837ae56c5d2fd4608fd@boeye.net> <81CA2235-734F-4E0F-BE9A-8F8568A0684D@omniti.com> <2cf7028b5745416f91c50ed686d5a72b@boeye.net> <4F8EA203-BA89-4E23-8E58-922CCECEF519@omniti.com> Message-ID: <65DC5816D4BEE043885A89FD54E273FC71D80F5F@MAIL101.Ellipseinc.com> From: http://omnios.omniti.com/wiki.php/ReleaseNotes?rev=a0d510f34690cfe285ec3a775d1f10d3464b684e OmniOS has moved to a per-release package repository setup. Each major release going forward will have its own IPS repository. The previous repo for releases (http://pkg.omniti.net/omnios/release/) will continue to serve packages for r151006 and r151008 The repo for r151010 is http://pkg.omniti.net/omnios/r151010/. See the upgrade instructions on how to move between repos if upgrading from a previous OmniOS release. So I thinking that the answer should be http://pkg.omniti.net/omnios/release/ -----Original Message----- From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Frank Boeye Sent: Monday, April 3, 2017 3:19 PM To: Dan McDonald Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue Thought so. Can you help me in the right direction on what the correct publisher is for 006? http://pkg.omniti.com/omnios/r151006/ obviously is incorrect, and I can't seem to find it online. Thanks! -Frank -----Original Message----- From: Dan McDonald [mailto:danmcd at omniti.com] Sent: maandag 3 april 2017 22:16 To: Frank Boeye ; Dan McDonald Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue > On Apr 3, 2017, at 4:11 PM, Frank Boeye wrote: > > Do I need to specify an old repository or publisher first again then? Yes. Sorry for not being clear about that. You need to go back to the 006 publisher and get it all-the-way updated. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From mir at miras.org Mon Apr 3 20:56:08 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 3 Apr 2017 22:56:08 +0200 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> Message-ID: <20170403225608.4c1dce15@sleipner.datanom.net> On Mon, 3 Apr 2017 11:41:15 -0400 Dan McDonald wrote: > > One thing about this, and I need to try it of course, is whether or not this could be modified to scribble commands into /mnt/.initialboot as a bonus feature of the new Kayak interactive install? Say under a "post-install extras" sub-menu or something. > Updated to support command line input as well. (http://git.datanom.net/netconf.git/) commit f5cdd6555a5e6d81fa8981ab39b5e918a5a0b58b Btw. What do you exactly mean by 'modified to scribble commands into /mnt/.initialboot' ? If I have a clue I could easily add what is needed. -- 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: When all else fails, read the instructions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Mon Apr 3 21:58:54 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 3 Apr 2017 17:58:54 -0400 Subject: [OmniOS-discuss] Got a larval fix for you, Bob! Message-ID: <60C5AE37-7E11-426C-B380-269E55CC7B2F@omniti.com> I would like you to go into your zones, and patch THEIR version of /usr/sbin/shutdown thusly: --- /usr/sbin/shutdown Fri Apr 22 16:36:43 2016 +++ /zones/lipkg0/root/usr/sbin/shutdown Mon Apr 3 17:54:24 2017 @@ -228,7 +228,9 @@ if [ "$pid1" ] || [ "$pid2" ] then - /usr/bin/kill $pid1 $pid2 > /dev/null 2>&1 +# XXX KEBE SAYS TRY SOMETHING DIFFERENT... + /usr/bin/pwait $pid1 $pid2 +# /usr/bin/kill $pid1 $pid2 > /dev/null 2>&1 fi /sbin/init ${initstate} I believe the shutdown script is forking procs that don't finish until AFTER zoneadmd starts to shut things down. This causes the problems you see. The global version of shutdown should not be modified for now (esp. if this doesn't work for you, you can use it to recover). Thanks, Dan From bfriesen at simple.dallas.tx.us Tue Apr 4 01:18:51 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 3 Apr 2017 20:18:51 -0500 (CDT) Subject: [OmniOS-discuss] Got a larval fix for you, Bob! In-Reply-To: <60C5AE37-7E11-426C-B380-269E55CC7B2F@omniti.com> References: <60C5AE37-7E11-426C-B380-269E55CC7B2F@omniti.com> Message-ID: Unfortunately, while the console message goes away, there is still a problem. Notice the failures to shutdown the zone: % while true while> do while> echo Boot ; time pfexec zoneadm -z swdev boot while> echo Shutdown ; time pfexec zoneadm -z swdev shutdown while> done Boot zone 'swdev': zone is already booted pfexec zoneadm -z swdev boot 0.00s user 0.00s system 0% cpu 0.015 total Shutdown pfexec zoneadm -z swdev shutdown 0.00s user 0.00s system 0% cpu 6.145 total Boot pfexec zoneadm -z swdev boot 0.01s user 0.00s system 0% cpu 1.271 total Shutdown zone 'swdev': unable to shutdown zone pfexec zoneadm -z swdev shutdown 0.00s user 0.00s system 0% cpu 1:40.08 total Boot zone 'swdev': zone is already booted pfexec zoneadm -z swdev boot 0.01s user 0.00s system 47% cpu 0.021 total Shutdown pfexec zoneadm -z swdev shutdown 0.00s user 0.00s system 0% cpu 6.135 total Boot pfexec zoneadm -z swdev boot 0.01s user 0.00s system 0% cpu 1.230 total Shutdown zone 'swdev': unable to shutdown zone pfexec zoneadm -z swdev shutdown 0.00s user 0.00s system 0% cpu 1:40.07 total Boot zone 'swdev': zone is already booted pfexec zoneadm -z swdev boot 0.01s user 0.00s system 41% cpu 0.024 total Shutdown pfexec zoneadm -z swdev shutdown 0.00s user 0.00s system 0% cpu 6.156 total Boot pfexec zoneadm -z swdev boot 0.00s user 0.00s system 0% cpu 1.154 total Shutdown ^C pfexec zoneadm -z swdev shutdown 0.00s user 0.00s system 0% cpu 33.103 total -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Tue Apr 4 05:37:31 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 4 Apr 2017 01:37:31 -0400 Subject: [OmniOS-discuss] Got a larval fix for you, Bob! In-Reply-To: References: <60C5AE37-7E11-426C-B380-269E55CC7B2F@omniti.com> Message-ID: Are you bringing up and down zones this quickly in your deployment? I appreciate the test case, and it appears that after 1:40, a second shutdown works: bloody(~)[0]% /bin/time sudo zoneadm -z lipkg0 boot ; /bin/time sudo zoneadm -z lipkg0 shutdown ; /bin/time sudo zoneadm -z lipkg0 shutdown real 0.9 user 0.0 sys 0.0 zone 'lipkg0': unable to shutdown zone real 1:40.1 user 0.0 sys 0.0 real 6.0 user 0.0 sys 0.0 bloody(~)[0]% zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / ipkg shared - lx0 installed /zones/lx0 lx excl - lx1 installed /zones/lx1 lx excl - lipkg0 installed /zones/lipkg0 lipkg excl - lx2 installed /zones/lx2 lx excl bloody(~)[0]% Alternatively, a one-second sleep appears to be enough to miss the race: bloody(~)[0]% /bin/time sudo zoneadm -z lipkg0 boot ; sleep 1 ; /bin/time sudo zoneadm -z lipkg0 shutdown real 1.1 user 0.0 sys 0.0 real 7.0 user 0.0 sys 0.0 bloody(~)[0]% zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / ipkg shared - lx0 installed /zones/lx0 lx excl - lx1 installed /zones/lx1 lx excl - lipkg0 installed /zones/lipkg0 lipkg excl - lx2 installed /zones/lx2 lx excl bloody(~)[0]% I do believe that pwaiting on forked processes /usr/sbin/shutdown launches will eliminate more times this can happen, however. I will be putting such a fix out for review tomorrow on the illumos list. Thank you for your help and sorry for the delay in addressing this, Dan From frank at boeye.net Tue Apr 4 07:49:09 2017 From: frank at boeye.net (Frank Boeye) Date: Tue, 4 Apr 2017 07:49:09 +0000 Subject: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue In-Reply-To: <65DC5816D4BEE043885A89FD54E273FC71D80F5F@MAIL101.Ellipseinc.com> References: <9CB9290F-AF1E-485A-9AFB-02B062A6EB86@omniti.com> <696C3485-30C1-4C2B-9D74-1A1691E033A3@omniti.com> <69f8728570224837ae56c5d2fd4608fd@boeye.net> <81CA2235-734F-4E0F-BE9A-8F8568A0684D@omniti.com> <2cf7028b5745416f91c50ed686d5a72b@boeye.net> <4F8EA203-BA89-4E23-8E58-922CCECEF519@omniti.com> <65DC5816D4BEE043885A89FD54E273FC71D80F5F@MAIL101.Ellipseinc.com> Message-ID: <924624ccf7274ad7b5809b64927138fe@boeye.net> Hi, Swapping back to the 151006 repo and doing a pkg update did the trick. (the repo is .com instead of .net by the way) Right now the update to 151014 is running, I'll continue on to 020 from here. Thanks a bunch everyone! -Frank -----Original Message----- From: Richard Jahnel [mailto:rjahnel at ellipseinc.com] Sent: maandag 3 april 2017 22:39 To: Frank Boeye Cc: omnios-discuss at lists.omniti.com Subject: RE: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue From: http://omnios.omniti.com/wiki.php/ReleaseNotes?rev=a0d510f34690cfe285ec3a775d1f10d3464b684e OmniOS has moved to a per-release package repository setup. Each major release going forward will have its own IPS repository. The previous repo for releases (http://pkg.omniti.net/omnios/release/) will continue to serve packages for r151006 and r151008 The repo for r151010 is http://pkg.omniti.net/omnios/r151010/. See the upgrade instructions on how to move between repos if upgrading from a previous OmniOS release. So I thinking that the answer should be http://pkg.omniti.net/omnios/release/ -----Original Message----- From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Frank Boeye Sent: Monday, April 3, 2017 3:19 PM To: Dan McDonald Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue Thought so. Can you help me in the right direction on what the correct publisher is for 006? http://pkg.omniti.com/omnios/r151006/ obviously is incorrect, and I can't seem to find it online. Thanks! -Frank -----Original Message----- From: Dan McDonald [mailto:danmcd at omniti.com] Sent: maandag 3 april 2017 22:16 To: Frank Boeye ; Dan McDonald Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] OmniOs update from 151006 to 151016 issue > On Apr 3, 2017, at 4:11 PM, Frank Boeye wrote: > > Do I need to specify an old repository or publisher first again then? Yes. Sorry for not being clear about that. You need to go back to the 006 publisher and get it all-the-way updated. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From bfriesen at simple.dallas.tx.us Tue Apr 4 13:38:42 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 4 Apr 2017 08:38:42 -0500 (CDT) Subject: [OmniOS-discuss] Got a larval fix for you, Bob! In-Reply-To: References: <60C5AE37-7E11-426C-B380-269E55CC7B2F@omniti.com> Message-ID: On Tue, 4 Apr 2017, Dan McDonald wrote: > Are you bringing up and down zones this quickly in your deployment? No. At least not necessarily. But of course it should work. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Tue Apr 4 15:42:11 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 4 Apr 2017 11:42:11 -0400 Subject: [OmniOS-discuss] Got a larval fix for you, Bob! In-Reply-To: References: <60C5AE37-7E11-426C-B380-269E55CC7B2F@omniti.com> Message-ID: <85638E25-9A5F-480C-B748-1F42A005B482@omniti.com> > On Apr 4, 2017, at 9:38 AM, Bob Friesenhahn wrote: > > No. At least not necessarily. But of course it should work. It should, but I think this problem may go back pre-r151020, hell, it may go back to the genesis of ipkg zones. Try this to see what I mean: 1.) Run "zlogin -C " in a window. 2.) Shutdown the zone. 3.) On one command line: "zoneadm -z boot ; zoneadm -z shutdown". You will see this error on the console: INIT: smf(5) repository server not running. And that's it! Since shutdown(1M) doesn't bother checking if "init {$initstate}" succeeds, it just returns, leaving the zoneadm & zoneadmd pair to wait and eventually timeout. In this situation, the zone never shuts down, but comes up all the way instead. Hope this helps, Dan From danmcd at omniti.com Wed Apr 5 01:58:14 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 4 Apr 2017 21:58:14 -0400 Subject: [OmniOS-discuss] Ang: network configuration script In-Reply-To: <328159580.95876.1491222876898.JavaMail.zimbra@oetiker.ch> References: <20170402233033.0a4747bf@sleipner.datanom.net> <328159580.95876.1491222876898.JavaMail.zimbra@oetiker.ch> Message-ID: <522A4852-E795-4290-82F0-F60705C7D264@omniti.com> > On Apr 3, 2017, at 8:34 AM, Tobias Oetiker wrote: > > maybe a page on the omnios wiki with pointers would be all that is needed I can link off the MoreInfo page: https://omnios.omniti.com/wiki.php/MoreInfo and spill on over to there. Dan From danmcd at omniti.com Wed Apr 5 05:09:05 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 5 Apr 2017 01:09:05 -0400 Subject: [OmniOS-discuss] Bloody update Message-ID: <9FBC20C6-D604-43F9-A875-942A3002CBD4@omniti.com> A new bloody update is out. All media has been updated, as has the upstream repo server. REMINDER: OmniOS repo servers can & should be accessed via https URLs from now on. Just as an extra level of protection. This will also be true for r151022 when it ships. "uname -v" shows omnios-master-0137ede omnios-build was build from commit a69bc58. New in this update: * Perl to 5.24.1!!! Update your .env files if you have your own on bloody for building illumos-gate! The sample ones we include in /opt/onbld/env have been appropriately updated. * Removal of legacy XXXXyyy packages (e.g. BRCMbnxe, SUNWdtrt, except for SUNWcs, of course). * EOF of lms and heci. * Man page cleanups. * Zone cleanups for "shutdown", thanks to Bob Friesenhahn for his finding this bug. * More /proc/sys files for LX zones (Joyent OS-6025). * Kayak build in omnios-build now less sudo-y, and cleaner. * pciutils to 3.5.4 * pcre to 8.40 * xz to 5.2.3 * nghttp2 to 1.21.0 Happy updating! Dan From bfriesen at simple.dallas.tx.us Wed Apr 5 13:22:08 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 5 Apr 2017 08:22:08 -0500 (CDT) Subject: [OmniOS-discuss] Got a larval fix for you, Bob! In-Reply-To: References: <60C5AE37-7E11-426C-B380-269E55CC7B2F@omniti.com> Message-ID: On Tue, 4 Apr 2017, Dan McDonald wrote: > Are you bringing up and down zones this quickly in your deployment? > > I appreciate the test case, and it appears that after 1:40, a second shutdown works: > > Alternatively, a one-second sleep appears to be enough to miss the race: > > bloody(~)[0]% /bin/time sudo zoneadm -z lipkg0 boot ; sleep 1 ; /bin/time sudo zoneadm -z lipkg0 shutdown A two-second sleep still encounters the failure to shutdown a zone on my system. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Wed Apr 5 16:23:16 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 5 Apr 2017 12:23:16 -0400 Subject: [OmniOS-discuss] OmniOS User Survey Message-ID: OmniTI would like to hear from OmniOS users. We have a survey that we'd appreciate you taking. There's no extra automatic emails that will result from taking this survey. Here's the link: https://www.surveymonkey.com/r/omnios Please take the survey before May 5th. Thanks, Dan From bfriesen at simple.dallas.tx.us Wed Apr 5 16:56:26 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 5 Apr 2017 11:56:26 -0500 (CDT) Subject: [OmniOS-discuss] OmniOS User Survey In-Reply-To: References: Message-ID: The intention of the 7) "Why those native zones?" question is not very clear. Is it meant as a question as to why ipkg or lipkg was selected, or is it meant to capture what services are offered by the zones? Likewise, item 12) about why services are run on the global zone does not ask why this is. For example, I run some services in the global zone due to fear about boot-time dependencies. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Wed Apr 5 17:08:36 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 5 Apr 2017 13:08:36 -0400 Subject: [OmniOS-discuss] Community help opportunity: packages with parent dependencies Message-ID: <90A8D611-0313-447E-A1BB-F7C0CDB5D6B2@omniti.com> Now that linked-image zones don't necessarily update from global without the "-r" flag, we DO need to tag certain packages as "MUST ALWAYS UPGRADE" because they have dependencies on the kernel or other global-zone goodies. Rich Lowe brought this to my attention a long while back, and now it's time to kick things off with his suggested list: http://kebe.com/~danmcd/webrevs/io-parent-deps/ Basically, any lipkg-zone package that MUST be updated when its global-zone version is should be tagged per the ones already in this webrev. I'll be going through packages myself in both illumos, and in omnios-build (if there are changes there, they will be updated in a repo called "ob-parent-deps"). If anyone wants to help, this is why I started this mail thread. :) This is the last piece of development work for this bloody cycle, and once it's done, all I have to do is finish documentation (there will be a lot with this release), find a freeze point for updates from upstream, and make sure omnios-build packages are caught up with their respective upstreams. Thank you! Dan From tom-omnios-discuss at tom.bn-ulm.de Wed Apr 5 17:24:47 2017 From: tom-omnios-discuss at tom.bn-ulm.de (Thomas Wagner) Date: Wed, 5 Apr 2017 19:24:47 +0200 Subject: [OmniOS-discuss] OmniOS User Survey In-Reply-To: References: Message-ID: <20170405172447.GO9794@wagner-net.com> Hi Dan, I would prefer to see a more detailed question about extra-packages-repo My believe is, that a well maintained repo of ready-to-use extra packages makes the Solarish OS-distros attractive to users. So if users could write a litte which software stacks they need badly, that would be cool. Regards, Thomas On Wed, Apr 05, 2017 at 12:23:16PM -0400, Dan McDonald wrote: > OmniTI would like to hear from OmniOS users. We have a survey that we'd appreciate you taking. > > There's no extra automatic emails that will result from taking this survey. > > Here's the link: > > https://www.surveymonkey.com/r/omnios > > Please take the survey before May 5th. > > Thanks, > Dan > From danmcd at omniti.com Wed Apr 5 17:43:36 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 5 Apr 2017 13:43:36 -0400 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <20170403225608.4c1dce15@sleipner.datanom.net> References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> <20170403225608.4c1dce15@sleipner.datanom.net> Message-ID: <49391B3C-6BEC-426A-A81A-B8FB3D7FEABF@omniti.com> > On Apr 3, 2017, at 4:56 PM, Michael Rasmussen wrote: > > Btw. What do you exactly mean by 'modified to scribble commands > into /mnt/.initialboot' ? Sorry for not getting back to this sooner. You have an interactive setup. It then invokes certain commands like "ipadm create-addr ....". Instead of invoking those commands, what if it wrote those commands to a file (i.e. scribbled those commands :) ) or even stdout? The file I was imagining was "/mnt/.initialboot", because after a fresh ISO/USB installation, any commands in the file are invoked once when the new system boots the first time. One could put the bring-up-networking commands on the newly installed machine using your tool and the commands it outputs. Dan From mir at miras.org Wed Apr 5 17:52:29 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 5 Apr 2017 19:52:29 +0200 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <49391B3C-6BEC-426A-A81A-B8FB3D7FEABF@omniti.com> References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> <20170403225608.4c1dce15@sleipner.datanom.net> <49391B3C-6BEC-426A-A81A-B8FB3D7FEABF@omniti.com> Message-ID: <20170405195229.4eed7afd@sleipner.datanom.net> On Wed, 5 Apr 2017 13:43:36 -0400 Dan McDonald wrote: > > You have an interactive setup. It then invokes certain commands like "ipadm create-addr ....". > > Instead of invoking those commands, what if it wrote those commands to a file (i.e. scribbled those commands :) ) or even stdout? The file I was imagining was "/mnt/.initialboot", because after a fresh ISO/USB installation, any commands in the file are invoked once when the new system boots the first time. > > One could put the bring-up-networking commands on the newly installed machine using your tool and the commands it outputs. > I see. This should be easy. Simply add a boolean command line option. Eg -r|--record which when present will output create commands to stdout. I prefer using stdout for a broader usage scenario leaving decision where to output to the invoker. What do you think? -- 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: My family history begins with me, but yours ends with you. -- Iphicrates -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Wed Apr 5 17:54:00 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 5 Apr 2017 13:54:00 -0400 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <20170405195229.4eed7afd@sleipner.datanom.net> References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> <20170403225608.4c1dce15@sleipner.datanom.net> <49391B3C-6BEC-426A-A81A-B8FB3D7FEABF@omniti.com> <20170405195229.4eed7afd@sleipner.datanom.net> Message-ID: > On Apr 5, 2017, at 1:52 PM, Michael Rasmussen wrote: > > I prefer using stdout for a broader usage scenario leaving > decision where to output to the invoker. > > What do you think? I think that's what I had in mind. :) Thanks! Dan From mir at miras.org Wed Apr 5 21:13:37 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 5 Apr 2017 23:13:37 +0200 Subject: [OmniOS-discuss] network configuration script In-Reply-To: References: <20170402233033.0a4747bf@sleipner.datanom.net> <0D32D7A6-7212-4194-8E9B-29B0038F9FCE@omniti.com> <20170403225608.4c1dce15@sleipner.datanom.net> <49391B3C-6BEC-426A-A81A-B8FB3D7FEABF@omniti.com> <20170405195229.4eed7afd@sleipner.datanom.net> Message-ID: <20170405231337.0128b53d@sleipner.datanom.net> On Wed, 5 Apr 2017 13:54:00 -0400 Dan McDonald wrote: > > On Apr 5, 2017, at 1:52 PM, Michael Rasmussen wrote: > > > > I prefer using stdout for a broader usage scenario leaving > > decision where to output to the invoker. > > > > What do you think? > > I think that's what I had in mind. :) > > Thanks! > Dan > Implemented output to stdout when option -r|--record added to command line. See git commit c050b028d64ee733e3a7e95c92505a81ace8ed70 -- 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: By working faithfully eight hours a day, you may eventually get to be boss and work twelve. -- Robert Frost -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From info.fmo at gmx.de Wed Apr 5 22:43:25 2017 From: info.fmo at gmx.de (Frank M.) Date: Thu, 6 Apr 2017 00:43:25 +0200 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <20170402233033.0a4747bf@sleipner.datanom.net> References: <20170402233033.0a4747bf@sleipner.datanom.net> Message-ID: <818292145.20170406004325@gmx.de> Hello Michael, hello Dan, I find your idea great. Because it?s annoying to do the initial network configuration again and again in my test-installations I had integrated in my own OmniOS-ISO the Solaris-vmware-tools and a shellscript for automated installation. It is not perfect but it works for me... But it is also annoying to implement this in every new release-ISO... It would be great, if you can implement something to ease the setup for the millions of vmware-omnios users. ;-) Also your idea to implement for IPoIB is great - I also use IPoIB in some test-scenarios. Greets Frank Sunday, April 2, 2017, 11:30:33 PM, you wrote: MR> Hi all, MR> I think it is not very easy for new users coming to Omnios from various MR> other distros to make the initial network configuration so I have MR> written a small tool in Python to remedy this obstacle. The script runs MR> on all Omnios as of r151014. I have tested on r151014 and bloody MR> (r151021) MR> The script is not ment to be the swiss army knife for configuring MR> networks on Omnios so there is no support for vnic, vlan, and MR> aggregates. It will only support configuring a single nic given the MR> user the option for dhcp and static setup. The user is also asked MR> whether to configure dns in which case the user is asked for an IP. MR> Currently it will only handle ethernet but IPoIB is on my todo list. I MR> have attached the script here but if the file is to large it can also MR> be downloaded here: http://git.datanom.net/netconf.git/ MR> PS. If I want to have it included in Omnios what license should I use? -- Best regards, Frank mailto:info.fmo at gmx.de From omnios at citrus-it.net Thu Apr 6 10:27:42 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 6 Apr 2017 10:27:42 +0000 (UTC) Subject: [OmniOS-discuss] OmniOS User Survey In-Reply-To: References: Message-ID: On Wed, 5 Apr 2017, Dan McDonald wrote: ; OmniTI would like to hear from OmniOS users. We have a survey that we'd appreciate you taking. Q3. I just put the slider somewhere near the right place (4 years) which resulted in 72 appearing in the box. (I see the question is fixed now). Q4. In answering this one I didn't consider things which are my favourite features of /illumos/ (zones, dtrace, crossbow, smf, zfs, ...) - wouldn't have been able to choose just one anyway. That left me with what OmniOS-specific features I like. Hope that's what you were after! 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 mir at miras.org Thu Apr 6 14:48:52 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 6 Apr 2017 16:48:52 +0200 Subject: [OmniOS-discuss] network configuration script In-Reply-To: <818292145.20170406004325@gmx.de> References: <20170402233033.0a4747bf@sleipner.datanom.net> <818292145.20170406004325@gmx.de> Message-ID: <20170406164852.43f37986@sleipner.datanom.net> Hi Frank, On Thu, 6 Apr 2017 00:43:25 +0200 "Frank M." wrote: > It would be great, if you can implement something to ease the setup > for the millions of vmware-omnios users. ;-) Dan is currently evaluating whether to use it in the new installer so hopefully your wish comes true;-) > Also your idea to implement for IPoIB is great - I also use IPoIB in > some test-scenarios. > I will do this when the ethernet part is proven stable since I rely on IPoIB too - all my Omnios boxes uses Infiniband for iSCSI and ethernet for management. -- 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: Most people prefer certainty to truth. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From softwareinforjam at gmail.com Thu Apr 6 18:16:52 2017 From: softwareinforjam at gmail.com (Software Information) Date: Thu, 6 Apr 2017 13:16:52 -0500 Subject: [OmniOS-discuss] How some services boot Message-ID: Hi All Just trying to understand how some services work under OmniOS. Please help me to understand this. I have build omnios-r151020-4151d05 and I am running a Git Server in a zone. I used packages to install Git with a pkg install. When I run svcs, I don't see the git service at all but I can use a client to connect to it and the port is open. I am trying to get better at service management. Where can I find the script that is starting this service. Best Regards Petrocelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Apr 6 18:29:29 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 6 Apr 2017 14:29:29 -0400 Subject: [OmniOS-discuss] How some services boot In-Reply-To: References: Message-ID: <52C6D091-C538-4AB3-BDD2-D993B78F6AAE@omniti.com> > On Apr 6, 2017, at 2:16 PM, Software Information wrote: > > Hi All > Just trying to understand how some services work under OmniOS. Please help me to understand this. I have build omnios-r151020-4151d05 and I am running a Git Server in a zone. I used packages to install Git with a pkg install. When I run svcs, I don't see the git service at all but I can use a client to connect to it and the port is open. I am trying to get better at service management. Where can I find the script that is starting this service. Our git package only contains the client (i.e. the git(1) command). You're on your own for configuring a git server. Sorry, Dan From natxo.asenjo at gmail.com Thu Apr 6 19:06:56 2017 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 6 Apr 2017 21:06:56 +0200 Subject: [OmniOS-discuss] How some services boot In-Reply-To: References: Message-ID: hi, On Thu, Apr 6, 2017 at 8:16 PM, Software Information < softwareinforjam at gmail.com> wrote: > Hi All > Just trying to understand how some services work under OmniOS. Please help > me to understand this. I have build omnios-r151020-4151d05 and I am running > a Git Server in a zone. I used packages to install Git with a pkg install. > When I run svcs, I don't see the git service at all but I can use a client > to connect to it and the port is open. I am trying to get better at service > management. Where can I find the script that is starting this service. > There is no 'official' git server. You can review the methods of using a bare repo specified in https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols (chapter 4 of the excellent - and free to read - git book). If what you are looking for are free alternatives to github, you could take a look at gitlab, gitbucket, gitprep (just look them up in your favorite search engine). There are obviously non-free (but excellent) alternatives as bitbucket. You can also take a look at gitolite, but it has no web frontend, it is purely an access control git shell. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.sproul at circonus.com Thu Apr 6 19:09:58 2017 From: eric.sproul at circonus.com (Eric Sproul) Date: Thu, 6 Apr 2017 15:09:58 -0400 Subject: [OmniOS-discuss] How some services boot In-Reply-To: References: Message-ID: On Thu, Apr 6, 2017 at 2:16 PM, Software Information wrote: > Hi All > Just trying to understand how some services work under OmniOS. Please help > me to understand this. I have build omnios-r151020-4151d05 and I am running > a Git Server in a zone. I used packages to install Git with a pkg install. > When I run svcs, I don't see the git service at all but I can use a client > to connect to it and the port is open. I am trying to get better at service > management. Where can I find the script that is starting this service. There are a couple of strategies. The brute-force method is to run `svcs` and look for services that recently started (by default they are sorted in time order, most recent at the end). It may be that the service has a name that you don't expect. IPS packages can deliver services that are automatically enabled, and you can discover that by examining the package contents. First, I'd look for it delivering an SMF manifest, which is an XML file that is typically installed somewhere under /var/svc/manifest: pkg contents | grep svc/manifest If that turns up something, have a look in that file for the name of the service, which will be an attribute on the node, e.g. Assuming you find that, then `svcs someservice` should return something. HTH, Eric From softwareinforjam at gmail.com Fri Apr 7 16:08:06 2017 From: softwareinforjam at gmail.com (Software Information) Date: Fri, 7 Apr 2017 11:08:06 -0500 Subject: [OmniOS-discuss] How some services boot In-Reply-To: References: Message-ID: Thanks very much for the comments. Someone else just suggested to me that I could also try pkgsrc because they have a git server. Going to check it out. Used pkgsrc on NetBSD so I am quite used to it. Will see how it works out and check back in. Thanks again. On Thu, Apr 6, 2017 at 2:09 PM, Eric Sproul wrote: > On Thu, Apr 6, 2017 at 2:16 PM, Software Information > wrote: > > Hi All > > Just trying to understand how some services work under OmniOS. Please > help > > me to understand this. I have build omnios-r151020-4151d05 and I am > running > > a Git Server in a zone. I used packages to install Git with a pkg > install. > > When I run svcs, I don't see the git service at all but I can use a > client > > to connect to it and the port is open. I am trying to get better at > service > > management. Where can I find the script that is starting this service. > > There are a couple of strategies. The brute-force method is to run > `svcs` and look for services that recently started (by default they > are sorted in time order, most recent at the end). It may be that the > service has a name that you don't expect. > > IPS packages can deliver services that are automatically enabled, and > you can discover that by examining the package contents. First, I'd > look for it delivering an SMF manifest, which is an XML file that is > typically installed somewhere under /var/svc/manifest: > > pkg contents | grep svc/manifest > > If that turns up something, have a look in that file for the name of > the service, which will be an attribute on the node, e.g. > > > > Assuming you find that, then `svcs someservice` should return something. > > HTH, > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzempek at gmail.com Fri Apr 7 19:31:01 2017 From: grzempek at gmail.com (Krzysztof Grzempa) Date: Fri, 7 Apr 2017 21:31:01 +0200 Subject: [OmniOS-discuss] Happy New Year, and Python2.7 In-Reply-To: <5FD14374-2704-4A53-A8AA-409D5F1E7DCE@omniti.com> References: <5FD14374-2704-4A53-A8AA-409D5F1E7DCE@omniti.com> Message-ID: Hello Everybody Regarding python2.7. Where can I get it from to install in stable r151014 ? I need it for django to work as it requires python2.7 or later... As i cannot find it in default publisher the only things comes to my mind is OpenCSW or complie it from scratch(i would like to avoid that to be honest...) Do you have any better source for installing python2.7 or even better python3 ? Cheers, Krzysztof Grzempa 2017-01-04 18:29 GMT+01:00 Dan McDonald : > The first of the big changes for this bloody cycle is underway internally, > i.e. the move from Python2.6 to Python2.7 for OmniOS-internal users of > Python. Those users are currently: > > pkg(5) > > traditional installer media (not kayak) > > As of now, the pkg5 test suite is mostly passing with Python2.7, and > bloody users know that Python2.7 is AVAILABLE in the main "omnios" > publisher repo. > > The installer still needs work, but I'm curious how many bloody users out > there would be comfortable with having (for now) older install media, but > when "pkg update" occurs, moving entirely to Python2.7? The possible > answers are: > > * We want both: Basically, don't jump to Python2.7 until all components > are ready. > > * We can cope: Basically, make the jump for pkg5, but for now, > traditional install media would be frozen, until the Python2.7 jump has > been completed. > > Appreciate your feedback, and I have one more longer-term question coming > later today or tomorrow. > > Thanks! > Dan > > _______________________________________________ > 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 john.barfield at bissinc.com Sat Apr 8 00:26:27 2017 From: john.barfield at bissinc.com (John Barfield) Date: Sat, 8 Apr 2017 00:26:27 +0000 Subject: [OmniOS-discuss] ZPOOL bug after upgrade to r151020 Message-ID: <68E65E7C-DBFC-4014-BE18-3DDE3FF10AF7@bissinc.com> Greetings, I just want to report that after a clean istall of r151020 I found a bug whereby importing an older zpool from r151012 and running zpool upgrade causes an SSD cache device size to be reported incorrectly. (only 1 out of 4 devices in this instance) The cache device size is 93gb and arcstat reported it to be 680gb. I confirmed by monitoring zpool iostat -v and saw the same size being reported. We've had a lot of weird io lockups (which is how I found the issue, we didnt notice it until a month after) that brings all of our NFS mounts to a screeching halt and this was the only thing I could find to be out of the ordinary on the system. CPU average @1% , 20% of ram free, no crazy processes waiting on IO. It was completely invisible. At least from my testing using several dtrace scripts from the net. I can only assume that the incorrect size reporting caused the zpool to fill the cache drive up beyond its physical capacity during periods of heavy load. I removed all cache devices and then added them back to the zpool. Then all disks reported correctly again. Format/diskinfo always reported correctly so it was specific to zfs. We're monitoring the NAS closely to see if the issues occur again. John Barfield -------------- next part -------------- An HTML attachment was scrubbed... URL: From an3s.annema at gmail.com Sat Apr 8 08:26:33 2017 From: an3s.annema at gmail.com (Andries Annema) Date: Sat, 8 Apr 2017 10:26:33 +0200 Subject: [OmniOS-discuss] Happy New Year, and Python2.7 In-Reply-To: References: <5FD14374-2704-4A53-A8AA-409D5F1E7DCE@omniti.com> Message-ID: <004c01d2b041$d4e8e000$7ebaa000$@gmail.com> Hi Krzysztof, Did you try the ms.omniti.com publisher, http://pkg.omniti.com/omniti-ms/en/index.shtml ? Python2.7 is available there, for r151014 indeed; find it under the name ?omniti/runtime/python-27?. Although not the latest version, 2.7.6 might just be sufficient. Not sure of any alternative sources/repos or even Python 3 though. Regards, Andries From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Krzysztof Grzempa Sent: vrijdag 7 april 2017 21:31 To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Happy New Year, and Python2.7 Hello Everybody Regarding python2.7. Where can I get it from to install in stable r151014 ? I need it for django to work as it requires python2.7 or later... As i cannot find it in default publisher the only things comes to my mind is OpenCSW or complie it from scratch(i would like to avoid that to be honest...) Do you have any better source for installing python2.7 or even better python3 ? Cheers, Krzysztof Grzempa 2017-01-04 18:29 GMT+01:00 Dan McDonald : The first of the big changes for this bloody cycle is underway internally, i.e. the move from Python2.6 to Python2.7 for OmniOS-internal users of Python. Those users are currently: pkg(5) traditional installer media (not kayak) As of now, the pkg5 test suite is mostly passing with Python2.7, and bloody users know that Python2.7 is AVAILABLE in the main "omnios" publisher repo. The installer still needs work, but I'm curious how many bloody users out there would be comfortable with having (for now) older install media, but when "pkg update" occurs, moving entirely to Python2.7? The possible answers are: * We want both: Basically, don't jump to Python2.7 until all components are ready. * We can cope: Basically, make the jump for pkg5, but for now, traditional install media would be frozen, until the Python2.7 jump has been completed. Appreciate your feedback, and I have one more longer-term question coming later today or tomorrow. Thanks! Dan _______________________________________________ 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 grzempek at gmail.com Sat Apr 8 09:15:42 2017 From: grzempek at gmail.com (Krzysztof Grzempa) Date: Sat, 8 Apr 2017 11:15:42 +0200 Subject: [OmniOS-discuss] Happy New Year, and Python2.7 In-Reply-To: <004c01d2b041$d4e8e000$7ebaa000$@gmail.com> References: <5FD14374-2704-4A53-A8AA-409D5F1E7DCE@omniti.com> <004c01d2b041$d4e8e000$7ebaa000$@gmail.com> Message-ID: Thanks you guys, Small tuts for whom concerns: Following your advices i did: Install omniti-ms publisher: # pkg set-publisher -g http://pkg.omniti.com/omniti-ms ms.omniti.com I found python3.4 nice packages: # pkg search python3 INDEX ACTION VALUE PACKAGE basename link opt/python34/bin/python3 pkg:/omniti/runtime/python-34 at 3.4.3-0.151014 basename link opt/python34/bin/python3 pkg:/omniti/runtime/python-34 at 3.4.0-0.151006 basename link opt/python34/bin/python3 pkg:/omniti/runtime/python-34 at 3.4.0-0.151010 basename link opt/python34/bin/python3 pkg:/omniti/runtime/python-34 at 3.4.3-0.151014 Install package of your choice: # pkg install pkg:/omniti/runtime/python-34 at 3.4.3-0.151014 Install django using pip3: # /opt/python34/bin/pip3 install django and voila: /opt/python34/bin/python3 Python 3.4.3 (default, Oct 11 2016, 13:41:40) [GCC 4.8.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import django >>> print(django.get_version()) 1.11 Thanks 2017-04-08 10:26 GMT+02:00 Andries Annema : > Hi Krzysztof, > > > > Did you try the ms.omniti.com publisher, http://pkg.omniti.com/omniti- > ms/en/index.shtml ? > > Python2.7 is available there, for r151014 indeed; find it under the name > ?omniti/runtime/python-27?. Although not the latest version, 2.7.6 might > just be sufficient. > > > > Not sure of any alternative sources/repos or even Python 3 though. > > > > Regards, > > Andries > > > > > > *From:* OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] *On > Behalf Of *Krzysztof Grzempa > *Sent:* vrijdag 7 april 2017 21:31 > *To:* omnios-discuss at lists.omniti.com > *Subject:* Re: [OmniOS-discuss] Happy New Year, and Python2.7 > > > > Hello Everybody > > Regarding python2.7. Where can I get it from to install in stable r151014 > ? I need it for django to work as it requires python2.7 or later... > > As i cannot find it in default publisher the only things comes to my mind > is OpenCSW or complie it from scratch(i would like to avoid that to be > honest...) > > Do you have any better source for installing python2.7 or even better > python3 ? > > Cheers, > > Krzysztof Grzempa > > > > 2017-01-04 18:29 GMT+01:00 Dan McDonald : > > The first of the big changes for this bloody cycle is underway internally, > i.e. the move from Python2.6 to Python2.7 for OmniOS-internal users of > Python. Those users are currently: > > pkg(5) > > traditional installer media (not kayak) > > As of now, the pkg5 test suite is mostly passing with Python2.7, and > bloody users know that Python2.7 is AVAILABLE in the main "omnios" > publisher repo. > > The installer still needs work, but I'm curious how many bloody users out > there would be comfortable with having (for now) older install media, but > when "pkg update" occurs, moving entirely to Python2.7? The possible > answers are: > > * We want both: Basically, don't jump to Python2.7 until all components > are ready. > > * We can cope: Basically, make the jump for pkg5, but for now, > traditional install media would be frozen, until the Python2.7 jump has > been completed. > > Appreciate your feedback, and I have one more longer-term question coming > later today or tomorrow. > > Thanks! > Dan > > _______________________________________________ > 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 omniti.com Sun Apr 9 23:55:47 2017 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 9 Apr 2017 19:55:47 -0400 Subject: [OmniOS-discuss] ZPOOL bug after upgrade to r151020 In-Reply-To: <68E65E7C-DBFC-4014-BE18-3DDE3FF10AF7@bissinc.com> References: <68E65E7C-DBFC-4014-BE18-3DDE3FF10AF7@bissinc.com> Message-ID: <3EE915D8-EA88-4FAD-BA99-933B01D06342@omniti.com> > On Apr 7, 2017, at 8:26 PM, John Barfield wrote: > > Greetings, > > I just want to report that after a clean istall of r151020 I found a bug whereby importing an older zpool from r151012 and running zpool upgrade causes an SSD cache device size to be reported incorrectly. (only 1 out of 4 devices in this instance) > > The cache device size is 93gb and arcstat reported it to be 680gb. > > I confirmed by monitoring zpool iostat -v and saw the same size being reported. > > We've had a lot of weird io lockups (which is how I found the issue, we didnt notice it until a month after) that brings all of our NFS mounts to a screeching halt and this was the only thing I could find to be out of the ordinary on the system. > > CPU average @1% , 20% of ram free, no crazy processes waiting on IO. It was completely invisible. At least from my testing using several dtrace scripts from the net. > > I can only assume that the incorrect size reporting caused the zpool to fill the cache drive up beyond its physical capacity during periods of heavy load. > > I removed all cache devices and then added them back to the zpool. Then all disks reported correctly again. Format/diskinfo always reported correctly so it was specific to zfs. > > We're monitoring the NAS closely to see if the issues occur again. The only thing I could find that might address the symptoms you see is this: https://illumos.org/issues/7504 Which didn't make it upstream in time to hit r151020. You should forward this on to the illumos ZFS developers' list: zfs at lists.illumos.org. Dan From john.barfield at bissinc.com Mon Apr 10 02:27:40 2017 From: john.barfield at bissinc.com (John Barfield) Date: Mon, 10 Apr 2017 02:27:40 +0000 Subject: [OmniOS-discuss] ZPOOL bug after upgrade to r151020 In-Reply-To: <3EE915D8-EA88-4FAD-BA99-933B01D06342@omniti.com> References: <68E65E7C-DBFC-4014-BE18-3DDE3FF10AF7@bissinc.com>, <3EE915D8-EA88-4FAD-BA99-933B01D06342@omniti.com> Message-ID: Thank you Dan. Do you happen to have the process or know the location of a process document for only building ZFS? Ive re-built only nfs from illumos-gate in the past to resolve a bug but im wondering how I would build and install only zfs. (if its even possible). There are 2 bugs that we're suffering with at two different customer sites that didnt get into r151020 and Im not sure that we can make it till r151022 is released. Thanks for any advice John Barfield On Apr 9, 2017, at 6:55 PM, Dan McDonald > wrote: On Apr 7, 2017, at 8:26 PM, John Barfield > wrote: Greetings, I just want to report that after a clean istall of r151020 I found a bug whereby importing an older zpool from r151012 and running zpool upgrade causes an SSD cache device size to be reported incorrectly. (only 1 out of 4 devices in this instance) The cache device size is 93gb and arcstat reported it to be 680gb. I confirmed by monitoring zpool iostat -v and saw the same size being reported. We've had a lot of weird io lockups (which is how I found the issue, we didnt notice it until a month after) that brings all of our NFS mounts to a screeching halt and this was the only thing I could find to be out of the ordinary on the system. CPU average @1% , 20% of ram free, no crazy processes waiting on IO. It was completely invisible. At least from my testing using several dtrace scripts from the net. I can only assume that the incorrect size reporting caused the zpool to fill the cache drive up beyond its physical capacity during periods of heavy load. I removed all cache devices and then added them back to the zpool. Then all disks reported correctly again. Format/diskinfo always reported correctly so it was specific to zfs. We're monitoring the NAS closely to see if the issues occur again. The only thing I could find that might address the symptoms you see is this: https://illumos.org/issues/7504 Which didn't make it upstream in time to hit r151020. You should forward this on to the illumos ZFS developers' list: zfs at lists.illumos.org. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoffn at gnaa.net Mon Apr 10 05:44:02 2017 From: geoffn at gnaa.net (Geoff Nordli) Date: Sun, 9 Apr 2017 22:44:02 -0700 Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies In-Reply-To: References: Message-ID: On 2017-03-29 11:32 AM, Andy Fiddaman wrote: > On Wed, 29 Mar 2017, Geoff Nordli wrote: > > ; Hi. > ; > ; Anyone have any luck installing VBox 5.1 on Omnios? > ; > ; I am missing: > ; > ; IPS : system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime > ; system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime > > # gtar zxvf ~/dl/VirtualBox-5.1.18-114002-SunOS.tar.gz > # ls > LICENSE > ReadMe.txt > VirtualBox-5.1.18-SunOS-amd64-r114002.pkg > autoresponse > > # sed -i 's/quit/nocheck/' autoresponse > # pkgadd -r autoresponse -d VirtualBox-5.1.18-SunOS-amd64-r114002.pkg all > > Binaries seem to run, didn't look any further. > > Andy > Hi Andy. Any thoughts on why changing the autoresponse file is still triggering the dependency error? #cat autoresponse basedir=default runlevel=nocheck conflict=nocheck setuid=nocheck action=nocheck partial=nocheck instance=unique idepend=nocheck rdepend=nocheck space=nocheck mail= # /usr/sbin/pkgadd -r autoresponse -d VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg all Processing package instance from VirtualBox-5.1.18-SunOS-amd64-r114002.pkg> Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002 Oracle Corporation ## Executing checkinstall script. Checking package dependencies... ## Missing packages: ## IPS : system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime ## SVr4: SUNWPython SUNWPython-devel ## ## Please install either the IPS or SVr4 packages before installing VirtualBox. pkgadd: ERROR: checkinstall script did not complete successfully Installation of failed. No changes were made to the system. thanks, Geoff From omnios at citrus-it.net Mon Apr 10 09:29:20 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Mon, 10 Apr 2017 09:29:20 +0000 (UTC) Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies In-Reply-To: References: Message-ID: On Sun, 9 Apr 2017, Geoff Nordli wrote: ; ; Hi Andy. ; ; Any thoughts on why changing the autoresponse file is still triggering the ; dependency error? ; ; # /usr/sbin/pkgadd -r autoresponse -d ; VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg all ; ; Processing package instance from ; VirtualBox-5.1.18-SunOS-amd64-r114002.pkg> ; ; Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002 ; Oracle Corporation ; ## Executing checkinstall script. ; Checking package dependencies... ; ## Missing packages: ; ## IPS : system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime ; system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime ; ## SVr4: SUNWPython SUNWPython-devel ; ## ; ## Please install either the IPS or SVr4 packages before installing ; VirtualBox. ; pkgadd: ERROR: checkinstall script did not complete successfully ; ; Installation of failed. ; No changes were made to the system. Ah, it's because I did the test installation in a zone. The checkinstall exits with success if the zone name is not 'global'. Try this: build# pkgtrans VirtualBox-5.1.18-SunOS-amd64-r114002.pkg . all Transferring package instance build# rm SUNWvbox/install/checkinstall build# sed -i /checkinstall/d SUNWvbox/pkgmap build# pkgadd -d . SUNWvbox Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From danmcd at omniti.com Mon Apr 10 14:00:11 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 10 Apr 2017 10:00:11 -0400 Subject: [OmniOS-discuss] ZPOOL bug after upgrade to r151020 In-Reply-To: References: <68E65E7C-DBFC-4014-BE18-3DDE3FF10AF7@bissinc.com> <3EE915D8-EA88-4FAD-BA99-933B01D06342@omniti.com> Message-ID: > On Apr 9, 2017, at 10:27 PM, John Barfield wrote: > > Thank you Dan. > > Do you happen to have the process or know the location of a process document for only building ZFS? > > Ive re-built only nfs from illumos-gate in the past to resolve a bug but im wondering how I would build and install only zfs. (if its even possible). > > There are 2 bugs that we're suffering with at two different customer sites that didnt get into r151020 and Im not sure that we can make it till r151022 is released. > > Thanks for any advice You can build zfs the way you likely built NFS. Build it, replace it on an alternate BE (in zfs's case: /kernel/fs/amd64/zfs), and reboot. The only gotcha might be if a bugfix covers more than just ZFS itself... but for 7504, that's NOT the case. :) Dan From geoffn at gnaa.net Mon Apr 10 14:54:56 2017 From: geoffn at gnaa.net (Geoff Nordli) Date: Mon, 10 Apr 2017 07:54:56 -0700 Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies In-Reply-To: References: Message-ID: <39b638dc-221d-6e83-0435-13810ffe452c@gnaa.net> On 2017-04-10 02:29 AM, Andy Fiddaman wrote: > On Sun, 9 Apr 2017, Geoff Nordli wrote: > > ; > ; Hi Andy. > ; > ; Any thoughts on why changing the autoresponse file is still triggering the > ; dependency error? > ; > ; # /usr/sbin/pkgadd -r autoresponse -d > ; VirtualBox\-5.1.18\-SunOS\-amd64\-r114002.pkg all > ; > ; Processing package instance from > ; VirtualBox-5.1.18-SunOS-amd64-r114002.pkg> > ; > ; Oracle VM VirtualBox(i386) 5.1.18,REV=2017.03.15.16.41.114002 > ; Oracle Corporation > ; ## Executing checkinstall script. > ; Checking package dependencies... > ; ## Missing packages: > ; ## IPS : system/library/gcc/gcc-c++-runtime or system/library/gcc-45-runtime > ; system/library/gcc/gcc-c-runtime or system/library/gcc-45-runtime > ; ## SVr4: SUNWPython SUNWPython-devel > ; ## > ; ## Please install either the IPS or SVr4 packages before installing > ; VirtualBox. > ; pkgadd: ERROR: checkinstall script did not complete successfully > ; > ; Installation of failed. > ; No changes were made to the system. > > Ah, it's because I did the test installation in a zone. The checkinstall > exits with success if the zone name is not 'global'. > > Try this: > > build# pkgtrans VirtualBox-5.1.18-SunOS-amd64-r114002.pkg . all > Transferring package instance > build# rm SUNWvbox/install/checkinstall > build# sed -i /checkinstall/d SUNWvbox/pkgmap > build# pkgadd -d . SUNWvbox > > Andy > Thanks Andy. That did the trick. There were no errors during installation. Now I will be able to see if vbox works OK. Have a great day!! Geoff From gearboxes at outlook.com Mon Apr 10 20:00:50 2017 From: gearboxes at outlook.com (Machine Man) Date: Mon, 10 Apr 2017 20:00:50 +0000 Subject: [OmniOS-discuss] ZeusRAM - predictive failure Message-ID: Today I received one of the ZeusRAM that I ordered, both brand new. I was struggling to find SAS SSD drives that were available in my price range as I desperately need to add a ZIL. I decided to order ZeusRAM since they had one in stock and figured I'll add it while waiting for the other one as they are really should not be prone to failure based on design. I have not used them and would normally just prefer to use regular SSD drives. Slotted ZeusRAM in and it began to rapidly blink the same as the disks that are currently in the pool on that backplain. Running the command format would never return with a list of disks. I left it for about 15 min and pulled it since it says on the disk that it can take up to 10 min for the caps. I could see there is an amber and green LED on the drive itself blinking, even when removed. I slotted it back in and the disk was then available. After a few min the fault light cam on and the disk was unavailable due to the following: Fault class : fault.io.disk.predictive-failure Affects : dev:///:devid=id1,sd at n5000a720300b3d57//pci at 0,0/pci8086,340e at 7/pci1000,3040 at 0/iport at f0/disk at w5000a72a300b3d57,0 faulted and taken out of service FRU : "Slot 09" (hc://:product-id=LSI-SAS2X36:server-id=:chassis-id=50030480178cf57f:serial=STM000****:part=STEC-ZeusRAM:revision=C025/ses-enclosure=1/bay=8/disk=0) faulty Description : SMART health-monitoring firmware reported that a disk failure is imminent. I cleared the fault and the drive was then usable again for a few min same thing happened. Eventually the amber light on the disk itself (not the enclosure disk light) no longer blinked and the disks was online for quite some time before the alert above reappeared. === START OF INFORMATION SECTION === Vendor: STEC Product: ZeusRAM Revision: C025 Compliance: SPC-4 User Capacity: 8,000,000,000 bytes [8.00 GB] Logical block size: 512 bytes Rotation Rate: Solid State Device Form Factor: 3.5 inches Logical Unit id: 0x5000a720300b3d57 Serial number: STM000****** Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Apr 10 19:17:23 2017 UTC SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled === START OF READ SMART DATA SECTION === SMART Health Status: OK Current Drive Temperature: 40 C Drive Trip Temperature: 80 C Elements in grown defect list: 0 Vendor (Seagate) cache information Blocks sent to initiator = 0 Blocks sent to initiator = 0 Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 0 0 0 0 21.323 0 write: 0 0 0 0 0 83.809 0 Non-medium error count: 0 Is there anything special that should be done for ZeusRAM in sd.conf? Its a node install and both nodes can see all the drives. I don't see any smart errors listed, but running fmadm it will show the disk as faulty due to predictive failure. OmniOS r20 all patches applied. thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Mon Apr 10 20:08:29 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 10 Apr 2017 22:08:29 +0200 Subject: [OmniOS-discuss] VirtualBox 5.1 - Missing dependencies In-Reply-To: <98FB8D41-C2A5-4D27-A03F-7292CD9D0257@omniti.com> References: <464C462F-2F37-466F-AD8E-83C4241EB003@omniti.com> <1a90f314-a446-cc2b-1a3c-b002c32a2223@gnaa.net> <22748.8305.199354.108543@urukhai.local> <98FB8D41-C2A5-4D27-A03F-7292CD9D0257@omniti.com> Message-ID: <22763.58941.361882.669921@urukhai.local> Hi Dale! Sorry, I let this slip a bit... > > On Mar 29, 2017, at 5:00 PM, Volker A. Brandt wrote: > > > > Dan McDonald writes: > >> Ideally someone would package it on OmniOS itself for OmniOS. > > > > Would that be permitted by the VirtualBox license? Shouldn't be too > > hard if it is just repackaging... > > Preferably it would also be natively built. One of the unfortunate legacy > aspects is that VirtualBox?s notion of ?SunOS? is Oracle Solaris and stays > absolutely true to that expectation. This was certainly an issue with the > vbox add-ons and the vboxfs driver no longer building or working on illumos, > as it was expecting symbols that were introduced in later versions of Oracle > Solaris 11 but are not present in illumos, which still self-identifies as > the same. The other day I installed the most recent VBox guest extensions on OmniOS bloody. They installed fine (as described in later mails in this thread), and vboxfs works flawlessly. In fact, I have used an image from my shared home folder to bring up an LX branded Centos 7.3 in Omnios in VirtualBox under macOS 10.12 without a hitch. :-) Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From richard.elling at richardelling.com Mon Apr 10 20:15:32 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 10 Apr 2017 13:15:32 -0700 Subject: [OmniOS-discuss] ZeusRAM - predictive failure In-Reply-To: References: Message-ID: <43E5F4CA-14B8-4F07-B62A-C74B9B7154ED@RichardElling.com> > On Apr 10, 2017, at 1:00 PM, Machine Man wrote: > > Today I received one of the ZeusRAM that I ordered, both brand new. I was struggling to find SAS SSD drives that were available in my price range as I desperately need to add a ZIL. > I decided to order ZeusRAM since they had one in stock and figured I'll add it while waiting for the other one as they are really should not be prone to failure based on design. I have not used them and would normally just prefer to use regular SSD drives. > > Slotted ZeusRAM in and it began to rapidly blink the same as the disks that are currently in the pool on that backplain. Running the command format would never return with a list of disks. I left it for about 15 min and pulled it since it says on the disk that it can take up to 10 min for the caps. I could see there is an amber and green LED on the drive itself blinking, even when removed. > I slotted it back in and the disk was then available. After a few min the fault light cam on and the disk was unavailable due to the following: > > Fault class : fault.io.disk.predictive-failure This occurs when the drive responds to an I/O and indicates a predictive failure or the periodic query for drives sees a predicted failure. It is the drive telling the OS that the drive thinks it will fail. There is nothing you can do on the OS to ?fix? this. It is possible that HGST (nee STEC) can help with further diagnosis using the vendor-specific log pages. Several years ago, STEC helped us with root cause of failing ultracapacitor in a drive. AFAIK, there is no publicly available decoder for those log pages. ? richard > Affects : dev:///:devid=id1,sd at n5000a720300b3d57//pci at 0,0/pci8086,340e at 7/pci1000,3040 at 0/iport at f0/disk at w5000a72a300b3d57,0 > faulted and taken out of service > FRU : "Slot 09" (hc://:product-id=LSI-SAS2X36:server-id=:chassis-id=50030480178cf57f:serial=STM000****:part=STEC-ZeusRAM:revision=C025/ses-enclosure=1/bay=8/disk=0 ) > faulty > Description : SMART health-monitoring firmware reported that a disk > failure is imminent. > > > I cleared the fault and the drive was then usable again for a few min same thing happened. Eventually the amber light on the disk itself (not the enclosure disk light) no longer blinked and the disks was online for quite some time before the alert above reappeared. > > > === START OF INFORMATION SECTION === > Vendor: STEC > Product: ZeusRAM > Revision: C025 > Compliance: SPC-4 > User Capacity: 8,000,000,000 bytes [8.00 GB] > Logical block size: 512 bytes > Rotation Rate: Solid State Device > Form Factor: 3.5 inches > Logical Unit id: 0x5000a720300b3d57 > Serial number: STM000****** > Device type: disk > Transport protocol: SAS (SPL-3) > Local Time is: Mon Apr 10 19:17:23 2017 UTC > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > Temperature Warning: Enabled > === START OF READ SMART DATA SECTION === > SMART Health Status: OK > Current Drive Temperature: 40 C > Drive Trip Temperature: 80 C > Elements in grown defect list: 0 > Vendor (Seagate) cache information > Blocks sent to initiator = 0 > Blocks sent to initiator = 0 > Error counter log: > Errors Corrected by Total Correction Gigabytes Total > ECC rereads/ errors algorithm processed uncorrected > fast | delayed rewrites corrected invocations [10^9 bytes] errors > read: 0 0 0 0 0 21.323 0 > write: 0 0 0 0 0 83.809 0 > Non-medium error count: 0 > > > > Is there anything special that should be done for ZeusRAM in sd.conf? Its a node install and both nodes can see all the drives. I don't see any smart errors listed, but running fmadm it will show the disk as faulty due to predictive failure. > OmniOS r20 all patches applied. > > > thanks, > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gearboxes at outlook.com Mon Apr 10 21:39:09 2017 From: gearboxes at outlook.com (Machine Man) Date: Mon, 10 Apr 2017 21:39:09 +0000 Subject: [OmniOS-discuss] ZeusRAM - predictive failure In-Reply-To: <43E5F4CA-14B8-4F07-B62A-C74B9B7154ED@RichardElling.com> References: , <43E5F4CA-14B8-4F07-B62A-C74B9B7154ED@RichardElling.com> Message-ID: Thank you. I am sending it back to where we purchased it from. I thought these were no longer avail, but the distributor still listed them and had in stock. I was hesitant to purchase, but I am in desperate need for a ZIL. ________________________________ From: Richard Elling Sent: Monday, April 10, 2017 4:15:32 PM To: Machine Man Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] ZeusRAM - predictive failure On Apr 10, 2017, at 1:00 PM, Machine Man > wrote: Today I received one of the ZeusRAM that I ordered, both brand new. I was struggling to find SAS SSD drives that were available in my price range as I desperately need to add a ZIL. I decided to order ZeusRAM since they had one in stock and figured I'll add it while waiting for the other one as they are really should not be prone to failure based on design. I have not used them and would normally just prefer to use regular SSD drives. Slotted ZeusRAM in and it began to rapidly blink the same as the disks that are currently in the pool on that backplain. Running the command format would never return with a list of disks. I left it for about 15 min and pulled it since it says on the disk that it can take up to 10 min for the caps. I could see there is an amber and green LED on the drive itself blinking, even when removed. I slotted it back in and the disk was then available. After a few min the fault light cam on and the disk was unavailable due to the following: Fault class : fault.io.disk.predictive-failure This occurs when the drive responds to an I/O and indicates a predictive failure or the periodic query for drives sees a predicted failure. It is the drive telling the OS that the drive thinks it will fail. There is nothing you can do on the OS to ?fix? this. It is possible that HGST (nee STEC) can help with further diagnosis using the vendor-specific log pages. Several years ago, STEC helped us with root cause of failing ultracapacitor in a drive. AFAIK, there is no publicly available decoder for those log pages. ? richard Affects : dev:///:devid=id1,sd at n5000a720300b3d57//pci at 0,0/pci8086,340e at 7/pci1000,3040 at 0/iport at f0/disk at w5000a72a300b3d57,0 faulted and taken out of service FRU : "Slot 09" (hc://:product-id=LSI-SAS2X36:server-id=:chassis-id=50030480178cf57f:serial=STM000****:part=STEC-ZeusRAM:revision=C025/ses-enclosure=1/bay=8/disk=0) faulty Description : SMART health-monitoring firmware reported that a disk failure is imminent. I cleared the fault and the drive was then usable again for a few min same thing happened. Eventually the amber light on the disk itself (not the enclosure disk light) no longer blinked and the disks was online for quite some time before the alert above reappeared. === START OF INFORMATION SECTION === Vendor: STEC Product: ZeusRAM Revision: C025 Compliance: SPC-4 User Capacity: 8,000,000,000 bytes [8.00 GB] Logical block size: 512 bytes Rotation Rate: Solid State Device Form Factor: 3.5 inches Logical Unit id: 0x5000a720300b3d57 Serial number: STM000****** Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Apr 10 19:17:23 2017 UTC SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled === START OF READ SMART DATA SECTION === SMART Health Status: OK Current Drive Temperature: 40 C Drive Trip Temperature: 80 C Elements in grown defect list: 0 Vendor (Seagate) cache information Blocks sent to initiator = 0 Blocks sent to initiator = 0 Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 0 0 0 0 21.323 0 write: 0 0 0 0 0 83.809 0 Non-medium error count: 0 Is there anything special that should be done for ZeusRAM in sd.conf? Its a node install and both nodes can see all the drives. I don't see any smart errors listed, but running fmadm it will show the disk as faulty due to predictive failure. OmniOS r20 all patches applied. thanks, _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Mon Apr 10 21:49:55 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 10 Apr 2017 14:49:55 -0700 Subject: [OmniOS-discuss] ZeusRAM - predictive failure In-Reply-To: References: <43E5F4CA-14B8-4F07-B62A-C74B9B7154ED@RichardElling.com> Message-ID: <6DDD1300-3842-40CF-9563-C712D30AEAF6@richardelling.com> > On Apr 10, 2017, at 2:39 PM, Machine Man wrote: > > Thank you. I am sending it back to where we purchased it from. I thought these were no longer avail, but the distributor still listed them and had in stock. > I was hesitant to purchase, but I am in desperate need for a ZIL. ZeusRAMs have been EOL for a year or more. AIUI, the parts are no longer available to build them. We do see better performance from the modern, enterprise-class, 12G SAS parts from HGST and Toshiba. Unfortunately, they are priced by $/GB and not $/latency, so the smaller capacity (GB) drives are also slower. ? richard > > > From: Richard Elling > Sent: Monday, April 10, 2017 4:15:32 PM > To: Machine Man > Cc: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] ZeusRAM - predictive failure > > >> On Apr 10, 2017, at 1:00 PM, Machine Man > wrote: >> >> Today I received one of the ZeusRAM that I ordered, both brand new. I was struggling to find SAS SSD drives that were available in my price range as I desperately need to add a ZIL. >> I decided to order ZeusRAM since they had one in stock and figured I'll add it while waiting for the other one as they are really should not be prone to failure based on design. I have not used them and would normally just prefer to use regular SSD drives. >> >> Slotted ZeusRAM in and it began to rapidly blink the same as the disks that are currently in the pool on that backplain. Running the command format would never return with a list of disks. I left it for about 15 min and pulled it since it says on the disk that it can take up to 10 min for the caps. I could see there is an amber and green LED on the drive itself blinking, even when removed. >> I slotted it back in and the disk was then available. After a few min the fault light cam on and the disk was unavailable due to the following: >> >> Fault class : fault.io.disk.predictive-failure > > This occurs when the drive responds to an I/O and indicates a predictive failure or > the periodic query for drives sees a predicted failure. It is the drive telling the OS that > the drive thinks it will fail. There is nothing you can do on the OS to ?fix? this. > > It is possible that HGST (nee STEC) can help with further diagnosis using the vendor-specific > log pages. Several years ago, STEC helped us with root cause of failing ultracapacitor in a drive. > AFAIK, there is no publicly available decoder for those log pages. > ? richard > > >> Affects : dev:///:devid=id1,sd at n5000a720300b3d57//pci at 0,0/pci8086,340e at 7/pci1000,3040 at 0/iport at f0/disk at w5000a72a300b3d57,0 >> faulted and taken out of service >> FRU : "Slot 09" (hc://:product-id=LSI-SAS2X36:server-id=:chassis-id=50030480178cf57f:serial=STM000****:part=STEC-ZeusRAM:revision=C025/ses-enclosure=1/bay=8/disk=0 ) >> faulty >> Description : SMART health-monitoring firmware reported that a disk >> failure is imminent. >> >> >> I cleared the fault and the drive was then usable again for a few min same thing happened. Eventually the amber light on the disk itself (not the enclosure disk light) no longer blinked and the disks was online for quite some time before the alert above reappeared. >> >> >> === START OF INFORMATION SECTION === >> Vendor: STEC >> Product: ZeusRAM >> Revision: C025 >> Compliance: SPC-4 >> User Capacity: 8,000,000,000 bytes [8.00 GB] >> Logical block size: 512 bytes >> Rotation Rate: Solid State Device >> Form Factor: 3.5 inches >> Logical Unit id: 0x5000a720300b3d57 >> Serial number: STM000****** >> Device type: disk >> Transport protocol: SAS (SPL-3) >> Local Time is: Mon Apr 10 19:17:23 2017 UTC >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> Temperature Warning: Enabled >> === START OF READ SMART DATA SECTION === >> SMART Health Status: OK >> Current Drive Temperature: 40 C >> Drive Trip Temperature: 80 C >> Elements in grown defect list: 0 >> Vendor (Seagate) cache information >> Blocks sent to initiator = 0 >> Blocks sent to initiator = 0 >> Error counter log: >> Errors Corrected by Total Correction Gigabytes Total >> ECC rereads/ errors algorithm processed uncorrected >> fast | delayed rewrites corrected invocations [10^9 bytes] errors >> read: 0 0 0 0 0 21.323 0 >> write: 0 0 0 0 0 83.809 0 >> Non-medium error count: 0 >> >> >> >> Is there anything special that should be done for ZeusRAM in sd.conf? Its a node install and both nodes can see all the drives. I don't see any smart errors listed, but running fmadm it will show the disk as faulty due to predictive failure. >> OmniOS r20 all patches applied. >> >> >> thanks, >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > -- > > Richard.Elling at RichardElling.com > +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gearboxes at outlook.com Mon Apr 10 23:30:27 2017 From: gearboxes at outlook.com (Machine Man) Date: Mon, 10 Apr 2017 23:30:27 +0000 Subject: [OmniOS-discuss] ZeusRAM - predictive failure In-Reply-To: <6DDD1300-3842-40CF-9563-C712D30AEAF6@richardelling.com> References: <43E5F4CA-14B8-4F07-B62A-C74B9B7154ED@RichardElling.com> , <6DDD1300-3842-40CF-9563-C712D30AEAF6@richardelling.com> Message-ID: Do you select drives based on DWPD? I am struggling to $500 - $700 drives in stock. I am limited to a number of distributors and pretty much unless its HP, Cisco or Dell its not kept in stock. On a number of disks options I got a ship date of late June and all 3 distributors indicating SSD drives are constrained. I am now down to adding a single SSD during busy hours or when the alerts start rolling in and removing the ZIL afterhours or when the load reduces again. My only other options for the next 3 weeks are: 1 - add 15K drives for ZIL and see if that helps. 2 - Hope for the best on the single old OCS Talos 2 3 - Mix SAS/SATA on the same backplane. I was 100% banking on the ZeusRAM since that is what I could get my hands immediately. ________________________________ From: Richard Elling Sent: Monday, April 10, 2017 5:49:55 PM To: Machine Man Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] ZeusRAM - predictive failure On Apr 10, 2017, at 2:39 PM, Machine Man > wrote: Thank you. I am sending it back to where we purchased it from. I thought these were no longer avail, but the distributor still listed them and had in stock. I was hesitant to purchase, but I am in desperate need for a ZIL. ZeusRAMs have been EOL for a year or more. AIUI, the parts are no longer available to build them. We do see better performance from the modern, enterprise-class, 12G SAS parts from HGST and Toshiba. Unfortunately, they are priced by $/GB and not $/latency, so the smaller capacity (GB) drives are also slower. ? richard ________________________________ From: Richard Elling > Sent: Monday, April 10, 2017 4:15:32 PM To: Machine Man Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] ZeusRAM - predictive failure On Apr 10, 2017, at 1:00 PM, Machine Man > wrote: Today I received one of the ZeusRAM that I ordered, both brand new. I was struggling to find SAS SSD drives that were available in my price range as I desperately need to add a ZIL. I decided to order ZeusRAM since they had one in stock and figured I'll add it while waiting for the other one as they are really should not be prone to failure based on design. I have not used them and would normally just prefer to use regular SSD drives. Slotted ZeusRAM in and it began to rapidly blink the same as the disks that are currently in the pool on that backplain. Running the command format would never return with a list of disks. I left it for about 15 min and pulled it since it says on the disk that it can take up to 10 min for the caps. I could see there is an amber and green LED on the drive itself blinking, even when removed. I slotted it back in and the disk was then available. After a few min the fault light cam on and the disk was unavailable due to the following: Fault class : fault.io.disk.predictive-failure This occurs when the drive responds to an I/O and indicates a predictive failure or the periodic query for drives sees a predicted failure. It is the drive telling the OS that the drive thinks it will fail. There is nothing you can do on the OS to ?fix? this. It is possible that HGST (nee STEC) can help with further diagnosis using the vendor-specific log pages. Several years ago, STEC helped us with root cause of failing ultracapacitor in a drive. AFAIK, there is no publicly available decoder for those log pages. ? richard Affects : dev:///:devid=id1,sd at n5000a720300b3d57//pci at 0,0/pci8086,340e at 7/pci1000,3040 at 0/iport at f0/disk at w5000a72a300b3d57,0 faulted and taken out of service FRU : "Slot 09" (hc://:product-id=LSI-SAS2X36:server-id=:chassis-id=50030480178cf57f:serial=STM000****:part=STEC-ZeusRAM:revision=C025/ses-enclosure=1/bay=8/disk=0) faulty Description : SMART health-monitoring firmware reported that a disk failure is imminent. I cleared the fault and the drive was then usable again for a few min same thing happened. Eventually the amber light on the disk itself (not the enclosure disk light) no longer blinked and the disks was online for quite some time before the alert above reappeared. === START OF INFORMATION SECTION === Vendor: STEC Product: ZeusRAM Revision: C025 Compliance: SPC-4 User Capacity: 8,000,000,000 bytes [8.00 GB] Logical block size: 512 bytes Rotation Rate: Solid State Device Form Factor: 3.5 inches Logical Unit id: 0x5000a720300b3d57 Serial number: STM000****** Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Mon Apr 10 19:17:23 2017 UTC SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled === START OF READ SMART DATA SECTION === SMART Health Status: OK Current Drive Temperature: 40 C Drive Trip Temperature: 80 C Elements in grown defect list: 0 Vendor (Seagate) cache information Blocks sent to initiator = 0 Blocks sent to initiator = 0 Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 0 0 0 0 21.323 0 write: 0 0 0 0 0 83.809 0 Non-medium error count: 0 Is there anything special that should be done for ZeusRAM in sd.conf? Its a node install and both nodes can see all the drives. I don't see any smart errors listed, but running fmadm it will show the disk as faulty due to predictive failure. OmniOS r20 all patches applied. thanks, _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Wed Apr 12 00:24:34 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Tue, 11 Apr 2017 17:24:34 -0700 Subject: [OmniOS-discuss] ZeusRAM - predictive failure In-Reply-To: References: <43E5F4CA-14B8-4F07-B62A-C74B9B7154ED@RichardElling.com> <6DDD1300-3842-40CF-9563-C712D30AEAF6@richardelling.com> Message-ID: > On Apr 10, 2017, at 4:30 PM, Machine Man wrote: > > Do you select drives based on DWPD? Not really. Inside a given product line, the difference in DWPD is a matter of overprovisioning. You can adjust the overprovisioning yourself, if needed. note to the lurkers, overprovisioning also impacts the write performance of garbage collection > I am struggling to $500 - $700 drives in stock. I am limited to a number of distributors and pretty much unless its HP, Cisco or Dell its not kept in stock. On a number of disks options I got a ship date of late June and all 3 distributors indicating SSD drives are constrained. Yes, there is a global shortage and all major vendors are on allocation. > I am now down to adding a single SSD during busy hours or when the alerts start rolling in and removing the ZIL afterhours or when the load reduces again. > > My only other options for the next 3 weeks are: > 1 - add 15K drives for ZIL and see if that helps. > 2 - Hope for the best on the single old OCS Talos 2 I have bad luck with these > 3 - Mix SAS/SATA on the same backplane. No guarantees, but for more modern expanders and HBAs, we see fewer problems mixing. I wouldn?t attempt for 3G SAS/SATA, but 12G seems more robust. ? richard > > I was 100% banking on the ZeusRAM since that is what I could get my hands immediately. > From: Richard Elling > Sent: Monday, April 10, 2017 5:49:55 PM > To: Machine Man > Cc: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] ZeusRAM - predictive failure > > >> On Apr 10, 2017, at 2:39 PM, Machine Man > wrote: >> >> Thank you. I am sending it back to where we purchased it from. I thought these were no longer avail, but the distributor still listed them and had in stock. >> I was hesitant to purchase, but I am in desperate need for a ZIL. > > ZeusRAMs have been EOL for a year or more. AIUI, the parts are no longer available to build them. > We do see better performance from the modern, enterprise-class, 12G SAS parts from HGST and Toshiba. > Unfortunately, they are priced by $/GB and not $/latency, so the smaller capacity (GB) drives are also slower. > ? richard > >> >> >> From: Richard Elling > >> Sent: Monday, April 10, 2017 4:15:32 PM >> To: Machine Man >> Cc: omnios-discuss at lists.omniti.com >> Subject: Re: [OmniOS-discuss] ZeusRAM - predictive failure >> >> >>> On Apr 10, 2017, at 1:00 PM, Machine Man > wrote: >>> >>> Today I received one of the ZeusRAM that I ordered, both brand new. I was struggling to find SAS SSD drives that were available in my price range as I desperately need to add a ZIL. >>> I decided to order ZeusRAM since they had one in stock and figured I'll add it while waiting for the other one as they are really should not be prone to failure based on design. I have not used them and would normally just prefer to use regular SSD drives. >>> >>> Slotted ZeusRAM in and it began to rapidly blink the same as the disks that are currently in the pool on that backplain. Running the command format would never return with a list of disks. I left it for about 15 min and pulled it since it says on the disk that it can take up to 10 min for the caps. I could see there is an amber and green LED on the drive itself blinking, even when removed. >>> I slotted it back in and the disk was then available. After a few min the fault light cam on and the disk was unavailable due to the following: >>> >>> Fault class : fault.io.disk.predictive-failure >> >> This occurs when the drive responds to an I/O and indicates a predictive failure or >> the periodic query for drives sees a predicted failure. It is the drive telling the OS that >> the drive thinks it will fail. There is nothing you can do on the OS to ?fix? this. >> >> It is possible that HGST (nee STEC) can help with further diagnosis using the vendor-specific >> log pages. Several years ago, STEC helped us with root cause of failing ultracapacitor in a drive. >> AFAIK, there is no publicly available decoder for those log pages. >> ? richard >> >> >>> Affects : dev:///:devid=id1,sd at n5000a720300b3d57//pci at 0,0/pci8086,340e at 7/pci1000,3040 at 0/iport at f0/disk at w5000a72a300b3d57,0 >>> faulted and taken out of service >>> FRU : "Slot 09" (hc://:product-id=LSI-SAS2X36:server-id=:chassis-id=50030480178cf57f:serial=STM000****:part=STEC-ZeusRAM:revision=C025/ses-enclosure=1/bay=8/disk=0 ) >>> faulty >>> Description : SMART health-monitoring firmware reported that a disk >>> failure is imminent. >>> >>> >>> I cleared the fault and the drive was then usable again for a few min same thing happened. Eventually the amber light on the disk itself (not the enclosure disk light) no longer blinked and the disks was online for quite some time before the alert above reappeared. >>> >>> >>> === START OF INFORMATION SECTION === >>> Vendor: STEC >>> Product: ZeusRAM >>> Revision: C025 >>> Compliance: SPC-4 >>> User Capacity: 8,000,000,000 bytes [8.00 GB] >>> Logical block size: 512 bytes >>> Rotation Rate: Solid State Device >>> Form Factor: 3.5 inches >>> Logical Unit id: 0x5000a720300b3d57 >>> Serial number: STM000****** >>> Device type: disk >>> Transport protocol: SAS (SPL-3) >>> Local Time is: Mon Apr 10 19:17:23 2017 UTC >>> SMART support is: Available - device has SMART capability. >>> SMART support is: Enabled >>> Temperature Warning: Enabled >>> === START OF READ SMART DATA SECTION === >>> SMART Health Status: OK >>> Current Drive Temperature: 40 C >>> Drive Trip Temperature: 80 C >>> Elements in grown defect list: 0 >>> Vendor (Seagate) cache information >>> Blocks sent to initiator = 0 >>> Blocks sent to initiator = 0 >>> Error counter log: >>> Errors Corrected by Total Correction Gigabytes Total >>> ECC rereads/ errors algorithm processed uncorrected >>> fast | delayed rewrites corrected invocations [10^9 bytes] errors >>> read: 0 0 0 0 0 21.323 0 >>> write: 0 0 0 0 0 83.809 0 >>> Non-medium error count: 0 >>> >>> >>> >>> Is there anything special that should be done for ZeusRAM in sd.conf? Its a node install and both nodes can see all the drives. I don't see any smart errors listed, but running fmadm it will show the disk as faulty due to predictive failure. >>> OmniOS r20 all patches applied. >>> >>> >>> thanks, >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> -- >> >> Richard.Elling at RichardElling.com >> +1-760-896-4422 -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Apr 12 15:43:07 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 12 Apr 2017 11:43:07 -0400 Subject: [OmniOS-discuss] I need a bit of testing help... Message-ID: <055496B5-2194-4AD0-AAF1-0A658EE55103@omniti.com> Does anyone have: * Working kerberos infrastructure * A non-global zone in which they can test kclient(1M)? If so, please contact me off-list. Thanks, Dan From gary at genashor.com Wed Apr 12 16:03:34 2017 From: gary at genashor.com (Gary Gendel) Date: Wed, 12 Apr 2017 12:03:34 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto Message-ID: It's been years since I played with zones (Solaris 10 Sparc ~build 187) so I've forgotten everything I learned. I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). Should I wait for 151022 (assuming it won't be too far off)? What are the steps to bring up an LX zone from scratch (i.e. create a VNIC...) and the associated commands (or pointers to documentation) Thank goodness for BEs as I went through this unsuccessfully a few times but could easily rollback whatever I messed up. Thanks, Gary -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3703 bytes Desc: not available URL: From danmcd at omniti.com Wed Apr 12 16:16:22 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 12 Apr 2017 12:16:22 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: Message-ID: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> > On Apr 12, 2017, at 12:03 PM, Gary Gendel wrote: > > It's been years since I played with zones (Solaris 10 Sparc ~build 187) so I've forgotten everything I learned. > > I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). > > Should I wait for 151022 (assuming it won't be too far off)? You will get improvements in r151022, but nothing that'll substantially improve the bringup. Two paths: 1.) Read here: https://omnios.omniti.com/wiki.php/LXZones 2.) If #1 is still too complicated, Oetiker & Partner have this tool: http://www.lxadm.org/ Dan From gary at genashor.com Wed Apr 12 16:35:01 2017 From: gary at genashor.com (Gary Gendel) Date: Wed, 12 Apr 2017 12:35:01 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> References: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> Message-ID: <5C0C5EF7B63644878C8A750176AC8B01@mail10.futurewins.com> On 04/12/2017 12:16 PM, Dan McDonald wrote: >> On Apr 12, 2017, at 12:03 PM, Gary Gendel wrote: >> >> It's been years since I played with zones (Solaris 10 Sparc ~build 187) so I've forgotten everything I learned. >> >> I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). >> >> Should I wait for 151022 (assuming it won't be too far off)? > You will get improvements in r151022, but nothing that'll substantially improve the bringup. > > Two paths: > > 1.) Read here: https://omnios.omniti.com/wiki.php/LXZones > > 2.) If #1 is still too complicated, Oetiker & Partner have this tool: http://www.lxadm.org/ > > Dan > Dan, Thanks for the second link, I hadn't come across that in my searches. It sure fits the bill for a newbie nicely. Gary -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3703 bytes Desc: not available URL: From wonko at 4amlunch.net Wed Apr 12 16:37:59 2017 From: wonko at 4amlunch.net (Brian Hechinger) Date: Wed, 12 Apr 2017 12:37:59 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: <5C0C5EF7B63644878C8A750176AC8B01@mail10.futurewins.com> References: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> <5C0C5EF7B63644878C8A750176AC8B01@mail10.futurewins.com> Message-ID: Just FYI, I set Plex on a LX zone. I used CentOS 7 and just so you know, file change notification doesn?t appear to work so checking the box in Plex to re-scan on new files doesn?t function. -brian > On Apr 12, 2017, at 12:35, Gary Gendel wrote: > > On 04/12/2017 12:16 PM, Dan McDonald wrote: >>> On Apr 12, 2017, at 12:03 PM, Gary Gendel wrote: >>> >>> It's been years since I played with zones (Solaris 10 Sparc ~build 187) so I've forgotten everything I learned. >>> >>> I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). >>> >>> Should I wait for 151022 (assuming it won't be too far off)? >> You will get improvements in r151022, but nothing that'll substantially improve the bringup. >> >> Two paths: >> >> 1.) Read here: https://omnios.omniti.com/wiki.php/LXZones >> >> 2.) If #1 is still too complicated, Oetiker & Partner have this tool: http://www.lxadm.org/ >> >> Dan >> > Dan, > > Thanks for the second link, I hadn't come across that in my searches. It sure fits the bill for a newbie nicely. > > Gary > > > _______________________________________________ > 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 omniti.com Wed Apr 12 16:49:31 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 12 Apr 2017 12:49:31 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> <5C0C5EF7B63644878C8A750176AC8B01@mail10.futurewins.com> Message-ID: > On Apr 12, 2017, at 12:37 PM, Brian Hechinger wrote: > > Just FYI, I set Plex on a LX zone. I used CentOS 7 and just so you know, file change notification doesn?t appear to work so checking the box in Plex to re-scan on new files doesn?t function. You may wish to see if bloody (soon to be r151022) may cure what ails you on this front. Some bugfixes pulled-in from SmartOS during the r151021 bloody cycle that may be relevant: OS-5900 io_getevents doesn't block when it should OS-5926 epoll mishandles excessive timeout negativity OS-5845 lx aio performance improvements and move into kernel OS-5981 move eventfd in-kernel OS-5990 fix for OS-5987 causes worker thread to mishandle some signals OS-5991 refactor aio to remove exitlwp brand hook OS-5992 harden aio worker thread signal handling OS-5261 lxbrand eventfd AIO overflow behavior is incorrect OS-6016 lxbrand poll(2) wants implicit events Can't guarantee it'll help, but it won't hurt. FYI, Dan From alka at hfg-gmuend.de Wed Apr 12 17:10:41 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Wed, 12 Apr 2017 19:10:41 +0200 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: Message-ID: <4716d30e-96e2-866b-7f5a-16cecacfc853@hfg-gmuend.de> hello Gary There are more users interested in a tested Plex Howto or a ready to use VM. For OmniOS + napp-it free I have already added a menu for an easy download + setup of SmartOS LX zones, see http://www.napp-it.org/doc/downloads/zones.pdf I have started a thread at https://forums.servethehome.com/index.php?threads/omnios-now-includes-lx-support-from-joyent-smartos.11577/ with a link to a preconfigured Plex zone for SmartOS at http://lightsandshapes.com/plex-on-smartos.html It would be nice if someone who uses and wants Plex would add some experiences and hints as I do not use Plex myself. Gea Am 12.04.2017 um 18:03 schrieb Gary Gendel: > It's been years since I played with zones (Solaris 10 Sparc ~build 187) so I've forgotten everything I learned. > > I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). > > Should I wait for 151022 (assuming it won't be too far off)? > > What are the steps to bring up an LX zone from scratch (i.e. create a VNIC...) and the associated commands (or pointers to documentation) Thank goodness for BEs as I went through this unsuccessfully a few times but could easily rollback whatever I messed up. > > Thanks, > Gary > > > > > > _______________________________________________ > 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 natxo.asenjo at gmail.com Wed Apr 12 17:19:20 2017 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 12 Apr 2017 19:19:20 +0200 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: Message-ID: hi, On Wed, Apr 12, 2017 at 6:03 PM, Gary Gendel wrote: > > I'd like to set up a Plex media server in an LX zone on Omnios 151020 . > Unfortunately, I can't seem to get the right sequence of steps to create > the LX zone and linux kernel in preparation for installing Plex. I'm not > even sure which Linux kernel would be the least problematic (I chose debian > 8). I run a centos 6 plex server at home on omnios-r151020-4151d05. The media files are in nfs exported file systems on the same host. It works fine. I just followed the instructions on the wiki and added the plex repo for centos. This is its config: zonecfg -z plex export create -b set zonepath=/tank/zones/plex set brand=lx set autoboot=true set ip-type=exclusive add net set physical=vnic2 add property (name=gateway,value="192.168.0.254") add property (name=ips,value="192.168.0.20/24") add property (name=primary,value="true") add property (name=resolver,value="192.168.0.1") end add attr set name=kernel-version set type=string set value=2.6.32 end -- regards, Natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From wonko at 4amlunch.net Wed Apr 12 17:30:44 2017 From: wonko at 4amlunch.net (Brian Hechinger) Date: Wed, 12 Apr 2017 13:30:44 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: Message-ID: <6139BD67-B822-4577-86C6-E1FC52CA1B3D@4amlunch.net> also, dhcp doesn?t appear to be working. boo! -brian > On Apr 12, 2017, at 13:19, Natxo Asenjo wrote: > > hi, > > On Wed, Apr 12, 2017 at 6:03 PM, Gary Gendel > wrote: > > I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). > > I run a centos 6 plex server at home on omnios-r151020-4151d05. The media files are in nfs exported file systems on the same host. > > It works fine. I just followed the instructions on the wiki and added the plex repo for centos. > > This is its config: > > zonecfg -z plex export > create -b > set zonepath=/tank/zones/plex > set brand=lx > set autoboot=true > set ip-type=exclusive > add net > set physical=vnic2 > add property (name=gateway,value="192.168.0.254") > add property (name=ips,value="192.168.0.20/24 ") > add property (name=primary,value="true") > add property (name=resolver,value="192.168.0.1") > end > add attr > set name=kernel-version > set type=string > set value=2.6.32 > end > > > -- > regards, > Natxo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From wonko at 4amlunch.net Wed Apr 12 17:32:06 2017 From: wonko at 4amlunch.net (Brian Hechinger) Date: Wed, 12 Apr 2017 13:32:06 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: Message-ID: <1392608C-29AB-4088-AEB2-428158CD1081@4amlunch.net> root at myzone:/root# dladm show-phys root at myzone:/root# dladm show-link LINK CLASS MTU STATE BRIDGE OVER myzone0 vnic 1500 up -- ? root at myzone:/root# ipadm show-if IFNAME STATE CURRENT PERSISTENT lo0 ok -m-v------46 --- myzone0 ok bm--------46 -46 root at myzone:/root# ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 myzone0/v4 dhcp ok ? lo0/v6 static ok ::1/128 > On Apr 12, 2017, at 13:19, Natxo Asenjo wrote: > > hi, > > On Wed, Apr 12, 2017 at 6:03 PM, Gary Gendel > wrote: > > I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). > > I run a centos 6 plex server at home on omnios-r151020-4151d05. The media files are in nfs exported file systems on the same host. > > It works fine. I just followed the instructions on the wiki and added the plex repo for centos. > > This is its config: > > zonecfg -z plex export > create -b > set zonepath=/tank/zones/plex > set brand=lx > set autoboot=true > set ip-type=exclusive > add net > set physical=vnic2 > add property (name=gateway,value="192.168.0.254") > add property (name=ips,value="192.168.0.20/24 ") > add property (name=primary,value="true") > add property (name=resolver,value="192.168.0.1") > end > add attr > set name=kernel-version > set type=string > set value=2.6.32 > end > > > -- > regards, > Natxo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary at genashor.com Wed Apr 12 17:56:32 2017 From: gary at genashor.com (Gary Gendel) Date: Wed, 12 Apr 2017 13:56:32 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> References: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> Message-ID: On 04/12/2017 12:16 PM, Dan McDonald wrote: >> On Apr 12, 2017, at 12:03 PM, Gary Gendel wrote: >> >> It's been years since I played with zones (Solaris 10 Sparc ~build 187) so I've forgotten everything I learned. >> >> I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). >> >> Should I wait for 151022 (assuming it won't be too far off)? > You will get improvements in r151022, but nothing that'll substantially improve the bringup. > > Two paths: > > 1.) Read here: https://omnios.omniti.com/wiki.php/LXZones > > 2.) If #1 is still too complicated, Oetiker & Partner have this tool: http://www.lxadm.org/ > > Dan > Thanks to everyone that replied. Using lxadm I was able to get plex running under centos-7 in a handful of minutes. I'll keep in mind that auto-scanning and other options don't work (yet). Gary -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3703 bytes Desc: not available URL: From gary at genashor.com Wed Apr 12 20:17:28 2017 From: gary at genashor.com (Gary Gendel) Date: Wed, 12 Apr 2017 16:17:28 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> Message-ID: <12B99FC4555D485E8A4302159811AA18@mail10.futurewins.com> On 04/12/2017 01:56 PM, Gary Gendel wrote: > On 04/12/2017 12:16 PM, Dan McDonald wrote: >>> On Apr 12, 2017, at 12:03 PM, Gary Gendel wrote: >>> >>> It's been years since I played with zones (Solaris 10 Sparc ~build 187) so I've forgotten everything I learned. >>> >>> I'd like to set up a Plex media server in an LX zone on Omnios 151020 . Unfortunately, I can't seem to get the right sequence of steps to create the LX zone and linux kernel in preparation for installing Plex. I'm not even sure which Linux kernel would be the least problematic (I chose debian 8). >>> >>> Should I wait for 151022 (assuming it won't be too far off)? >> You will get improvements in r151022, but nothing that'll substantially improve the bringup. >> >> Two paths: >> >> 1.) Read here: https://omnios.omniti.com/wiki.php/LXZones >> >> 2.) If #1 is still too complicated, Oetiker & Partner have this tool: http://www.lxadm.org/ >> >> Dan >> > Thanks to everyone that replied. Using lxadm I was able to get plex running under centos-7 in a handful of minutes. I'll keep in mind that auto-scanning and other options don't work (yet). > > Gary > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss As a side-note centos-7 lvmetad was sucking up cpu resources. I disabled it in lvm.conf. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3703 bytes Desc: not available URL: From danmcd at omniti.com Wed Apr 12 20:18:45 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 12 Apr 2017 16:18:45 -0400 Subject: [OmniOS-discuss] I need a bit of testing help... In-Reply-To: <055496B5-2194-4AD0-AAF1-0A658EE55103@omniti.com> References: <055496B5-2194-4AD0-AAF1-0A658EE55103@omniti.com> Message-ID: <22A84727-ADBC-44C1-A2B1-A8B96514D13D@omniti.com> It appears there's an additional requirement -- Active Directory. :(. The /dev/random check happens in the join_domain() function of kclient. Thanks and sorry, Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 12, 2017, at 11:43 AM, Dan McDonald wrote: > > Does anyone have: > > * Working kerberos infrastructure > > * A non-global zone in which they can test kclient(1M)? > > If so, please contact me off-list. > > Thanks, > Dan > From danmcd at omniti.com Fri Apr 14 02:34:27 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 13 Apr 2017 22:34:27 -0400 Subject: [OmniOS-discuss] ATTENTION ALL WHO WISH TO UPGRADE TO r151022 Message-ID: <4CEF235C-E956-4AB3-8692-55432F5807F4@omniti.com> We've changed the code-signing regimen for OmniOS r151022. To that end, if you want to be able to upgrade to r151022, you will need to update your "ca-bundle" package to include the new root CA certificates. Normally we don't update obsoleted release, but in the spirit of allowing any 014-and-later release to update to r151022, we've pushed out: pkg://omnios/web/ca-bundle at 5.11-0.151014:20170414T020006Z pkg://omnios/web/ca-bundle at 5.11-0.151016:20170414T020046Z pkg://omnios/web/ca-bundle at 5.11-0.151018:20170414T020116Z pkg://omnios/web/ca-bundle at 5.11-0.151020:20170414T020145Z to their respective repo servers. If you do NOT have the most recent ca-bundle package, you will not be able to update to r151022 when the time comes, because you will fail with a signature verification error. Thanks to Dale Ghent for strengthening the new OmniOS CA cert(s). We're now two level, and 4k RSA + SHA512. Happy updating! Dan From alka at hfg-gmuend.de Fri Apr 14 10:20:51 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Fri, 14 Apr 2017 12:20:51 +0200 Subject: [OmniOS-discuss] Setup problems with newest OmniOS 151021 on ESXi 6.5 In-Reply-To: <4CEF235C-E956-4AB3-8692-55432F5807F4@omniti.com> References: <4CEF235C-E956-4AB3-8692-55432F5807F4@omniti.com> Message-ID: <035e3a4c-adda-287a-5ef4-15c08c465fd7@hfg-gmuend.de> I found a strange behaviour with the newest 151021 when I tried to setup on ESXi 6.5 I created a new VM (Solaris 11-64) with a DVD device connected to the OS .iso. On first boot of the VM, the ESXi web console crashed completely with a required reload. After reload, the VM console shows a - configuring devices - ..requesting system maintenance, press ctrl-d to continue After ctrl-d I was able to select a bootdisk and install OmniOS After setup, reboot work A power off/on and the ESXi webconsole crashes again (mostly, not always) Gea From danmcd at omniti.com Fri Apr 14 14:14:55 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 14 Apr 2017 10:14:55 -0400 Subject: [OmniOS-discuss] Setup problems with newest OmniOS 151021 on ESXi 6.5 In-Reply-To: <035e3a4c-adda-287a-5ef4-15c08c465fd7@hfg-gmuend.de> References: <4CEF235C-E956-4AB3-8692-55432F5807F4@omniti.com> <035e3a4c-adda-287a-5ef4-15c08c465fd7@hfg-gmuend.de> Message-ID: > On Apr 14, 2017, at 6:20 AM, Guenther Alka wrote: > > I found a strange behaviour with the newest 151021 when I tried to setup on ESXi 6.5 > > I created a new VM (Solaris 11-64) with a DVD device connected to the OS .iso. > On first boot of the VM, the ESXi web console crashed completely with a required reload. > > After reload, the VM console shows a > - configuring devices > - ..requesting system maintenance, press ctrl-d to continue > > After ctrl-d I was able to select a bootdisk and install OmniOS > After setup, reboot work > > A power off/on and the ESXi webconsole crashes again (mostly, not always) Are you saying that older r151021s did not have this problem? I know Fusion has a "black screen" problem with Loader, GRUB, et. al, but that's new, and only with the combination of the latest Fusion and latest MacOS X. Dan From alka at hfg-gmuend.de Fri Apr 14 14:55:50 2017 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Fri, 14 Apr 2017 16:55:50 +0200 Subject: [OmniOS-discuss] Setup problems with newest OmniOS 151021 on ESXi 6.5 In-Reply-To: References: <4CEF235C-E956-4AB3-8692-55432F5807F4@omniti.com> <035e3a4c-adda-287a-5ef4-15c08c465fd7@hfg-gmuend.de> Message-ID: <36044ef7-8eaa-5ea3-a13c-47ac06e2e72e@hfg-gmuend.de> It was the first time I tried bloody with the new loader on ESXi to fix a Perl TTy incompatibility with napp-it Gea Am 14.04.2017 um 16:14 schrieb Dan McDonald: >> On Apr 14, 2017, at 6:20 AM, Guenther Alka wrote: >> >> I found a strange behaviour with the newest 151021 when I tried to setup on ESXi 6.5 >> >> I created a new VM (Solaris 11-64) with a DVD device connected to the OS .iso. >> On first boot of the VM, the ESXi web console crashed completely with a required reload. >> >> After reload, the VM console shows a >> - configuring devices >> - ..requesting system maintenance, press ctrl-d to continue >> >> After ctrl-d I was able to select a bootdisk and install OmniOS >> After setup, reboot work >> >> A power off/on and the ESXi webconsole crashes again (mostly, not always) > Are you saying that older r151021s did not have this problem? > > I know Fusion has a "black screen" problem with Loader, GRUB, et. al, but that's new, and only with the combination of the latest Fusion and latest MacOS X. > > Dan > From groups at tierarzt-mueller.de Fri Apr 14 16:15:03 2017 From: groups at tierarzt-mueller.de (Alexander Lesle) Date: Fri, 14 Apr 2017 18:15:03 +0200 Subject: [OmniOS-discuss] Setup problems with newest OmniOS 151021 on ESXi 6.5 In-Reply-To: References: <4CEF235C-E956-4AB3-8692-55432F5807F4@omniti.com> <035e3a4c-adda-287a-5ef4-15c08c465fd7@hfg-gmuend.de> Message-ID: <241767684.20170414181503@tierarzt-mueller.de> Hello Dan McDonald and List, On April, 14 2017, 16:14 wrote in [1]: >> On Apr 14, 2017, at 6:20 AM, Guenther Alka wrote: >> >> I found a strange behaviour with the newest 151021 when I tried to setup on ESXi 6.5 >> >> I created a new VM (Solaris 11-64) with a DVD device connected to the OS .iso. >> On first boot of the VM, the ESXi web console crashed completely with a required reload. >> >> After reload, the VM console shows a >> - configuring devices >> - ..requesting system maintenance, press ctrl-d to continue >> >> After ctrl-d I was able to select a bootdisk and install OmniOS >> After setup, reboot work >> >> A power off/on and the ESXi webconsole crashes again (mostly, not always) > Are you saying that older r151021s did not have this problem? I am using r151020 on ESXi 6.5 with no problems such as Guenther describe with r151021. -- Best Regards Alexander April, 14 2017 ........ [1] mid:AD95163F-AED0-431F-9CD6-20F35D628DF2 at omniti.com ........ From groups at tierarzt-mueller.de Fri Apr 14 16:28:46 2017 From: groups at tierarzt-mueller.de (Alexander Lesle) Date: Fri, 14 Apr 2017 18:28:46 +0200 Subject: [OmniOS-discuss] Setup problems with newest OmniOS 151021 on ESXi 6.5 In-Reply-To: <035e3a4c-adda-287a-5ef4-15c08c465fd7@hfg-gmuend.de> References: <4CEF235C-E956-4AB3-8692-55432F5807F4@omniti.com> <035e3a4c-adda-287a-5ef4-15c08c465fd7@hfg-gmuend.de> Message-ID: <167723555.20170414182846@tierarzt-mueller.de> Hello Guenther Alka and List, On April, 14 2017, 12:20 wrote in [1]: > I found a strange behaviour with the newest 151021 when I tried to setup > on ESXi 6.5 > I created a new VM (Solaris 11-64) with a DVD device connected to the > OS .iso. > On first boot of the VM, the ESXi web console crashed completely with a > required reload. G?nther, the same problem with the Sphere Client 6.0.0? You can setup the new VM with the web console first and start the VM and the console with Sphere Client. -- Best Regards Alexander April, 14 2017 ........ [1] mid:035e3a4c-adda-287a-5ef4-15c08c465fd7 at hfg-gmuend.de ........ From geoffn at gnaa.net Sat Apr 15 01:13:02 2017 From: geoffn at gnaa.net (Geoff Nordli) Date: Fri, 14 Apr 2017 18:13:02 -0700 Subject: [OmniOS-discuss] Centos 7 LX brand -- lvmetad filling the system log -- instructions to disable it Message-ID: <307536ec-81c0-0ba5-0e7d-6be373d8629f@gnaa.net> I am doing some testing on r151020 with the LX Brand. I downloaded the latest Centos7 image. https://docs.joyent.com/public-cloud/instances/infrastructure/images/centos#centos-7-20161213 I logged in and I was able to do a yum update on the image so everything looks good. One thing I noticed is the /var/log/messages is filling up with messages like: Apr 14 23:30:00 test2 lvmetad[7365]: Failed to accept connection errno 11. Apr 14 23:30:00 test2 lvmetad[7365]: Failed to accept connection errno 11. Apr 14 23:30:00 test2 lvmetad[7365]: Failed to accept connection errno 11. Apr 14 23:30:00 test2 lvmetad[7365]: Failed to accept connection errno 11. Apr 14 23:30:00 test2 lvmetad[7365]: Failed to accept connection errno 11. Apr 14 23:30:00 test2 lvmetad: select error: Invalid argument Apr 14 23:30:00 test2 lvmetad: select error: Invalid argument Apr 14 23:30:00 test2 lvmetad: select error: Invalid argument Not really sure why that daemon is required, since LX doesn't seem use LVM to manage any disks. To disable it I did the following: 1. Disable and stop the *lvm2-lvmetad service* by running the following commands: systemctl disable lvm2-lvmetad systemctl stop lvm2-lvmetad 2. Disable and stop the *lvm2-lvmetad.socket* service by running the following commands: systemctl disable lvm2-lvmetad.socket systemctl stop lvm2-lvmetad.socket 3. Disable *lvmetad* in the LVM config file by running the following command: edit /etc/lvm/lvm.conf to include use_lvmetad = 0 I am quite stoked about the LX brand!! thanks, Geoff -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary at genashor.com Sat Apr 15 02:11:00 2017 From: gary at genashor.com (gary at genashor.com) Date: Fri, 14 Apr 2017 22:11:00 -0400 Subject: [OmniOS-discuss] Centos 7 LX brand -- lvmetad filling the system log -- instructions to disable it Message-ID: An HTML attachment was scrubbed... URL: From gate03 at landcroft.co.uk Sun Apr 16 01:19:30 2017 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Sun, 16 Apr 2017 11:19:30 +1000 Subject: [OmniOS-discuss] zdb doesn't find a pool Message-ID: <20170416111930.46c24c4c@kendall> Hello and apology to Dan to whom I've already mentioned this matter on IRC. Summary: zdb doesn't see a pool specified by name. My (home) server has three pools so: ================================================ # zpool status pool: rpool state: ONLINE scan: scrub repaired 0 in 0h2m with 0 errors on Sun Feb 19 14:01:41 2017 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 c2t0d0s0 ONLINE 0 0 0 errors: No known data errors pool: vault state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM vault ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 c2t1d0s0 ONLINE 0 0 0 c2t2d0s0 ONLINE 0 0 0 c2t3d0s0 ONLINE 0 0 0 c2t5d0s0 ONLINE 0 0 0 errors: No known data errors pool: woz state: ONLINE scan: resilvered 359G in 8h21m with 0 errors on Fri Mar 17 03:16:51 2017 config: NAME STATE READ WRITE CKSUM woz ONLINE 0 0 0 c2t4d0s0 ONLINE 0 0 0 errors: No known data errors ================================================ However, zdb won't see the pool 'woz': ================================================ # zdb vault | head -4 Cached configuration: version: 5000 name: 'vault' # zdb woz zdb: can't open 'woz': No such file or directory # zdb -l /dev/rdsk/c2t4d0s0 | head -6 -------------------------------------------- LABEL 0 -------------------------------------------- version: 5000 name: 'woz' state: 0 ================================================ So zdb finds pool 'vault' alright but not 'woz'. It will however see 'woz' if it's referred-to by disk. The difference which I think might be crucial is that 'vault' was created via zpool create, whereas 'woz' was created via zpool split. In the full output of zdb -l /dev/rdsk/c2t4d0s0 (omitted here for brevity), there are four labels numbered 0 to 3. The output is much shorter as well; it doesn't list the individual file objects as zdb vault does. Is this worth a mention on https://www.illumos.org/issues ? ______________ Michael Mounteney From danmcd at omniti.com Sun Apr 16 02:31:25 2017 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 15 Apr 2017 22:31:25 -0400 Subject: [OmniOS-discuss] zdb doesn't find a pool In-Reply-To: <20170416111930.46c24c4c@kendall> References: <20170416111930.46c24c4c@kendall> Message-ID: That woz was the result of zpool split is news to me (or I missed it, in which case I apologize). I wonder if a toy test with files ala the zfs test suite can reproduce this? - create 3-way mirror - zdb - split one disk - zdb original and split-created pool Adding illumos zfs list. Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 15, 2017, at 9:19 PM, Michael Mounteney wrote: > > Hello and apology to Dan to whom I've already mentioned this matter on > IRC. > > Summary: zdb doesn't see a pool specified by name. > > My (home) server has three pools so: > > ================================================ > # zpool status > pool: rpool > state: ONLINE > scan: scrub repaired 0 in 0h2m with 0 errors on Sun Feb 19 14:01:41 > 2017 config: > > NAME STATE READ WRITE CKSUM > rpool ONLINE 0 0 0 > c2t0d0s0 ONLINE 0 0 0 > > errors: No known data errors > > pool: vault > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > vault ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > c2t1d0s0 ONLINE 0 0 0 > c2t2d0s0 ONLINE 0 0 0 > c2t3d0s0 ONLINE 0 0 0 > c2t5d0s0 ONLINE 0 0 0 > > errors: No known data errors > > pool: woz > state: ONLINE > scan: resilvered 359G in 8h21m with 0 errors on Fri Mar 17 03:16:51 > 2017 config: > > NAME STATE READ WRITE CKSUM > woz ONLINE 0 0 0 > c2t4d0s0 ONLINE 0 0 0 > > errors: No known data errors > ================================================ > > However, zdb won't see the pool 'woz': > > ================================================ > # zdb vault | head -4 > > Cached configuration: > version: 5000 > name: 'vault' > # zdb woz > zdb: can't open 'woz': No such file or directory > # zdb -l /dev/rdsk/c2t4d0s0 | head -6 > -------------------------------------------- > LABEL 0 > -------------------------------------------- > version: 5000 > name: 'woz' > state: 0 > ================================================ > > So zdb finds pool 'vault' alright but not 'woz'. It will however see > 'woz' if it's referred-to by disk. The difference which I think might > be crucial is that 'vault' was created via zpool create, whereas 'woz' > was created via zpool split. In the full output of zdb > -l /dev/rdsk/c2t4d0s0 (omitted here for brevity), there are four labels > numbered 0 to 3. The output is much shorter as well; it doesn't list > the individual file objects as zdb vault does. > > Is this worth a mention on https://www.illumos.org/issues ? > > ______________ > Michael Mounteney > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From bauernfeind at ipk-gatersleben.de Sun Apr 16 23:37:15 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Sun, 16 Apr 2017 23:37:15 +0000 Subject: [OmniOS-discuss] bloody installer system maintenance Message-ID: <1492385835.11320.8.camel@ipk-gatersleben.de> Hello, is this normal behaviour? r151021-20170405.iso Platform: VMware Workstation Player 12.5.5-5234757 on latest CentOS7 OS: Solaris 11 64bit 4GB RAM 2 CPU 30GB vDisk i entered the shell after that, but dont know where i have to look for log files, /var/adm seems to contain nothing useful. the service "console-login" is running, and no service is in maintenance state. further Installation is straight forward. -- Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: bloody-maint.png Type: image/png Size: 5227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6399 bytes Desc: not available URL: From gate03 at landcroft.co.uk Mon Apr 17 06:42:37 2017 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Mon, 17 Apr 2017 16:42:37 +1000 Subject: [OmniOS-discuss] web site seems to attack server internet connection Message-ID: <20170417164237.7ca61503@kendall> If anyone has an OmniOS machine acting as a NAT with IP forwarding (as I have) they might care to try to reproduce a circumstance I am seeing, where visiting a web site on a workstation connected THROUGH the server, brings down the server's interface. Diagrammatically: interwebs | cable-modem | e1000g0 | OmniOS | e1000g1 | workstation On the workstation: 1. Browser, visit http://www.yamaguchien.com.au/ I've used this site for several years so regard it as 'legitimate'. 2. Click Shop and order something. I ordered Sencha premium. 3. Go to Checkout. 4. Fill in some details. Dummy address: Parliament Way, Canberra, ACT 2000 (the site validates addresses). Click checkout. 5. The browser may or may not start to load paypal.com but whatever; e1000g0 (as it is on my system) appears to be down, inasmuch as I can no longer ping 89.16.167.134 (google.com) from the *server*. It is necessary to take the interface down and up, and delete and add the default route, or maybe some other fiddling, to restore the interface. Does this indicate that Something Nasty is happening? ______________ Michael Mounteney From jcoombs at staff.gwi.net Mon Apr 17 11:59:38 2017 From: jcoombs at staff.gwi.net (Josh Coombs) Date: Mon, 17 Apr 2017 07:59:38 -0400 Subject: [OmniOS-discuss] web site seems to attack server internet connection In-Reply-To: <20170417164237.7ca61503@kendall> References: <20170417164237.7ca61503@kendall> Message-ID: I would think a packet capture on e1000g0 and e1000g1 would be good places to start looking. Josh C Joshua Coombs GWI *office* 207-494-2140 www.gwi.net On Mon, Apr 17, 2017 at 2:42 AM, Michael Mounteney wrote: > If anyone has an OmniOS machine acting as a NAT with IP forwarding (as > I have) they might care to try to reproduce a circumstance I am seeing, > where visiting a web site on a workstation connected THROUGH the > server, brings down the server's interface. Diagrammatically: > > interwebs > | > cable-modem > | > e1000g0 > | > OmniOS > | > e1000g1 > | > workstation > > On the workstation: > > 1. Browser, visit http://www.yamaguchien.com.au/ I've used this site > for several years so regard it as 'legitimate'. > 2. Click Shop and order something. I ordered Sencha premium. > 3. Go to Checkout. > 4. Fill in some details. Dummy address: Parliament Way, Canberra, > ACT 2000 (the site validates addresses). Click checkout. > 5. The browser may or may not start to load paypal.com but whatever; > e1000g0 (as it is on my system) appears to be down, inasmuch as I can > no longer ping 89.16.167.134 (google.com) from the *server*. It is > necessary to take the interface down and up, and delete and add the > default route, or maybe some other fiddling, to restore the interface. > > Does this indicate that Something Nasty is happening? > > ______________ > Michael Mounteney > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Mon Apr 17 14:12:29 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 17 Apr 2017 07:12:29 -0700 Subject: [OmniOS-discuss] zdb doesn't find a pool In-Reply-To: References: <20170416111930.46c24c4c@kendall> Message-ID: <3C5A8DE4-1E26-4718-9EC6-50893940C686@richardelling.com> > On Apr 15, 2017, at 7:31 PM, Dan McDonald wrote: > > That woz was the result of zpool split is news to me (or I missed it, in which case I apologize). > > I wonder if a toy test with files ala the zfs test suite can reproduce this? > > - create 3-way mirror > - zdb > - split one disk > - zdb original and split-created pool hint: when provided a pool name, zdb looks in /etc/zfs/zpool.cache to determine the poolname to devices mapping. Using the -e (exported) option causes zdb to read ZFS labels on the disks to locate the devices mapping. Since zdb runs in userland and can be run by non-root users, it has no knowledge of internal kernel state. "zdb -C" will pretty-print the packed nvlist cachefile for your viewing pleasure -- richard > > Adding illumos zfs list. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Apr 15, 2017, at 9:19 PM, Michael Mounteney wrote: >> >> Hello and apology to Dan to whom I've already mentioned this matter on >> IRC. >> >> Summary: zdb doesn't see a pool specified by name. >> >> My (home) server has three pools so: >> >> ================================================ >> # zpool status >> pool: rpool >> state: ONLINE >> scan: scrub repaired 0 in 0h2m with 0 errors on Sun Feb 19 14:01:41 >> 2017 config: >> >> NAME STATE READ WRITE CKSUM >> rpool ONLINE 0 0 0 >> c2t0d0s0 ONLINE 0 0 0 >> >> errors: No known data errors >> >> pool: vault >> state: ONLINE >> scan: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> vault ONLINE 0 0 0 >> raidz2-0 ONLINE 0 0 0 >> c2t1d0s0 ONLINE 0 0 0 >> c2t2d0s0 ONLINE 0 0 0 >> c2t3d0s0 ONLINE 0 0 0 >> c2t5d0s0 ONLINE 0 0 0 >> >> errors: No known data errors >> >> pool: woz >> state: ONLINE >> scan: resilvered 359G in 8h21m with 0 errors on Fri Mar 17 03:16:51 >> 2017 config: >> >> NAME STATE READ WRITE CKSUM >> woz ONLINE 0 0 0 >> c2t4d0s0 ONLINE 0 0 0 >> >> errors: No known data errors >> ================================================ >> >> However, zdb won't see the pool 'woz': >> >> ================================================ >> # zdb vault | head -4 >> >> Cached configuration: >> version: 5000 >> name: 'vault' >> # zdb woz >> zdb: can't open 'woz': No such file or directory >> # zdb -l /dev/rdsk/c2t4d0s0 | head -6 >> -------------------------------------------- >> LABEL 0 >> -------------------------------------------- >> version: 5000 >> name: 'woz' >> state: 0 >> ================================================ >> >> So zdb finds pool 'vault' alright but not 'woz'. It will however see >> 'woz' if it's referred-to by disk. The difference which I think might >> be crucial is that 'vault' was created via zpool create, whereas 'woz' >> was created via zpool split. In the full output of zdb >> -l /dev/rdsk/c2t4d0s0 (omitted here for brevity), there are four labels >> numbered 0 to 3. The output is much shorter as well; it doesn't list >> the individual file objects as zdb vault does. >> >> Is this worth a mention on https://www.illumos.org/issues ? >> >> ______________ >> Michael Mounteney >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Mon Apr 17 17:09:19 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 17 Apr 2017 13:09:19 -0400 Subject: [OmniOS-discuss] bloody installer system maintenance In-Reply-To: <1492385835.11320.8.camel@ipk-gatersleben.de> References: <1492385835.11320.8.camel@ipk-gatersleben.de> Message-ID: <77949C62-ED61-4CCA-9D7A-1ED58FA67154@omniti.com> > On Apr 16, 2017, at 7:37 PM, Jens Bauernfeind wrote: > > Hello, > > is this normal behaviour? > r151021-20170405.iso > Platform: VMware Workstation Player 12.5.5-5234757 on latest CentOS7 > OS: Solaris 11 64bit > 4GB RAM > 2 CPU > 30GB vDisk I have seen this occasionally. > i entered the shell after that, but dont know where i have to look for > log files, /var/adm seems to contain nothing useful. > the service "console-login" is running, and no service is in maintenance > state. > further Installation is straight forward. By "further installation", do you mean that once you exitted the shell the installer came up? Yeah, this happened to me in this situation as well. There's a race between initial-login and login:console that sometimes makes SMF enter this state. I've not yet figured out how to deterministically reproduce it, but when I do, I can kill it. Dan From danmcd at omniti.com Mon Apr 17 17:14:34 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 17 Apr 2017 13:14:34 -0400 Subject: [OmniOS-discuss] web site seems to attack server internet connection In-Reply-To: <20170417164237.7ca61503@kendall> References: <20170417164237.7ca61503@kendall> Message-ID: <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> I'd recommend snoop -o on your NAT box/zone. I tried your steps, and did not see this problem. My NAT is more sophisticated, servicing both my home and a work-from-home segment for OmniTI, which was where I tried your reproduction. NO idea what might've happened. Are you yourself in Australia? The problem could be country-local w.r.t. any possible mischief. Dan From bauernfeind at ipk-gatersleben.de Mon Apr 17 21:31:44 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Mon, 17 Apr 2017 21:31:44 +0000 Subject: [OmniOS-discuss] bloody installer system maintenance In-Reply-To: <77949C62-ED61-4CCA-9D7A-1ED58FA67154@omniti.com> References: <1492385835.11320.8.camel@ipk-gatersleben.de> <77949C62-ED61-4CCA-9D7A-1ED58FA67154@omniti.com> Message-ID: <1492464703.11458.4.camel@ipk-gatersleben.de> Hi, yes, I can exit the maintenance shell or bypass it during ctrl+d to start the installer menu. Today it worked once without "requesting maintenance state", after that it appeared everytime. -- Jens On Mon, 2017-04-17 at 13:09 -0400, Dan McDonald wrote: > > On Apr 16, 2017, at 7:37 PM, Jens Bauernfeind wrote: > > > > Hello, > > > > is this normal behaviour? > > r151021-20170405.iso > > Platform: VMware Workstation Player 12.5.5-5234757 on latest CentOS7 > > OS: Solaris 11 64bit > > 4GB RAM > > 2 CPU > > 30GB vDisk > > I have seen this occasionally. > > > i entered the shell after that, but dont know where i have to look for > > log files, /var/adm seems to contain nothing useful. > > the service "console-login" is running, and no service is in maintenance > > state. > > further Installation is straight forward. > > By "further installation", do you mean that once you exitted the shell the installer came up? Yeah, this happened to me in this situation as well. > > There's a race between initial-login and login:console that sometimes makes SMF enter this state. I've not yet figured out how to deterministically reproduce it, but when I do, I can kill it. > > Dan > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6399 bytes Desc: not available URL: From danmcd at omniti.com Mon Apr 17 21:37:29 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 17 Apr 2017 17:37:29 -0400 Subject: [OmniOS-discuss] bloody installer system maintenance In-Reply-To: <1492464703.11458.4.camel@ipk-gatersleben.de> References: <1492385835.11320.8.camel@ipk-gatersleben.de> <77949C62-ED61-4CCA-9D7A-1ED58FA67154@omniti.com> <1492464703.11458.4.camel@ipk-gatersleben.de> Message-ID: <6E9C2368-AB00-41C9-8DEA-46F4E2A43241@omniti.com> > On Apr 17, 2017, at 5:31 PM, Jens Bauernfeind wrote: > > yes, I can exit the maintenance shell or bypass it during ctrl+d to > start the installer menu. > > Today it worked once without "requesting maintenance state", after that > it appeared everytime. I'll be working to fix this between documentation updates and omnios-build package updates. Dan From peter.tribble at gmail.com Tue Apr 18 11:28:15 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Tue, 18 Apr 2017 12:28:15 +0100 Subject: [OmniOS-discuss] Issue with java and poll Message-ID: We're seeing a very occasional (sufficiently rare that it's difficult to catch) problem with a java application (a web application using Jetty under the hood) failing. This started at the end of last year, and didn't correlate with any changes we've made. And we've changed a few things since without it going away. The java stack at failure is java.io.IOException: Bad file number at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method) at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223) at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:98) ... And after that it starts randomly dropping requests. A few weeks of waiting and I managed to catch this with truss: ioctl(146, DP_POLL, 0xFFFFBF7FD25FF2D0) Err#9 EBADF OK, so it really is the underlying ioctl that's failing. I've checked the java source and looked at the native method and the code does match up to the stack trace. But has anyone got any ideas as to why we're failing? According to ioctl(2), EBADF is returned if: EBADF The fildes argument is not a valid open file descriptor. At face value, this means the application has decided to close /dev/poll, which seems a little odd. The only other way we can get EBADF is out of the epoll stuff, I believe, and we're running r151014 which I'm not sure has that. First question: can we confirm that r151014 doesn't have epoll and we can therefore rule out any oddities from that? Second question: has anybody else come across this? According to Google, it's a pretty rare thing, so that hasn't helped much. Thanks, -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdg117 at elvis.arl.psu.edu Tue Apr 18 12:09:47 2017 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Tue, 18 Apr 2017 08:09:47 -0400 Subject: [OmniOS-discuss] MEDIA: Time, but Faster Message-ID: <201704181209.v3IC9lDg005490@elvis.arl.psu.edu> Digging thru the snail mail; for those with ACM digital library access, see Theo Schlossnagle on gethrtime(3C) in Communications: | The first observation is that Linux optimizes both of these calls | significantly more than OmniOS does. This has actually been | addressed as part of the LX brand work in SmartOS by Joyent and will | soon be upstreamed into Illumos for general consumption by OmniOS. | Alas, that isn't the worst thing: objectively determining what time | it is, is simply too slow for microsecond-level timing, even at the | lower 119.8ns/op (nanoseconds per operation) number above. Note that | gettimeofday () supports only microsecond-level accuracy and thus is | not suitable for timing faster operations. John groenveld at acm.org From danmcd at omniti.com Tue Apr 18 13:06:57 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 18 Apr 2017 09:06:57 -0400 Subject: [OmniOS-discuss] Issue with java and poll In-Reply-To: References: Message-ID: <50937BF9-3506-496D-A4F5-1C1FEB36ADDF@omniti.com> No EPOLL in r151014: commit a5eb7107f06a6e23e8e77e8d3a84c1ff90a73ac6 Author: Bryan Cantrill Date: Sat Feb 14 16:55:35 2015 -0800 5640 want epoll support Reviewed by: Jerry Jelinek Reviewed by: Robert Mustacchi Approved by: Garrett D'Amore . . . bloody(~/ws/illumos-omnios)[141]% git branch -a --contains a5eb7107f06a6e23e8e77e8d3a84c1ff90a73ac6 * master upstream remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/r151016 remotes/origin/r151018 remotes/origin/r151020 remotes/origin/r151022 remotes/origin/upstream bloody(~/ws/illumos-omnios)[0]% Dan From bfriesen at simple.dallas.tx.us Tue Apr 18 13:41:42 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 18 Apr 2017 08:41:42 -0500 (CDT) Subject: [OmniOS-discuss] MEDIA: Time, but Faster In-Reply-To: <201704181209.v3IC9lDg005490@elvis.arl.psu.edu> References: <201704181209.v3IC9lDg005490@elvis.arl.psu.edu> Message-ID: On Tue, 18 Apr 2017, John D Groenveld wrote: > | it is, is simply too slow for microsecond-level timing, even at the > | lower 119.8ns/op (nanoseconds per operation) number above. Note that > | gettimeofday () supports only microsecond-level accuracy and thus is > | not suitable for timing faster operations. I am looking forward to less overhead to get the time. The gettimeofday() function is a legacy function. The clock_gettime() function should be the preferred way to get the current time in a portable way. This can provide nanosecond precision, but there is no telling what the actual precision is (clock_getres() is supposed to reveal that). The CLOCK_HIGHRES clock is the same as that used by gethrtime(). It would be good if some of the additional clocks as provided by Linux and FreeBSD are added to Illumos. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From moo at wuffers.net Tue Apr 18 14:38:52 2017 From: moo at wuffers.net (wuffers) Date: Tue, 18 Apr 2017 10:38:52 -0400 Subject: [OmniOS-discuss] ZPOOL bug after upgrade to r151020 In-Reply-To: References: <68E65E7C-DBFC-4014-BE18-3DDE3FF10AF7@bissinc.com> <3EE915D8-EA88-4FAD-BA99-933B01D06342@omniti.com> Message-ID: I upgraded to r151020 in late Jan, and saw some strangeness with arcstat (l2size and l2asize were huge) before I did a reboot due to some instability a few weeks ago. I thought it was just a case of not using the latest arcstat, and things were running fine after a reboot so didn't pursue it. I saw this post last week, and confirmed it was within my environment, so did the remove/re-add of the cache devices, then a complete reboot as well. The cache devices reported back their actual proper size (400GB) via "zpool iostat -v". Today I checked it again and this is what I see: # arcstat read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size l2asize 465 412 53 88 53 50 3 94 230G 4.4T 3.2T # zpool iostat -v (other info snipped for brevity) cache - - - - - - c2t500117310015D579d0 816G 16.0E 54 23 2.32M 1.46M c2t50011731001631FDd0 816G 16.0E 54 23 2.32M 1.46M c12t500117310015D59Ed0 815G 16.0E 55 23 2.35M 1.46M c12t500117310015D54Ed0 816G 16.0E 55 23 2.36M 1.46M I'm just waiting for the next lockup/crash.. John, were you able to compile the fix, and if so, be able send me a copy? Thanks. On Mon, Apr 10, 2017 at 10:00 AM, Dan McDonald wrote: > > > On Apr 9, 2017, at 10:27 PM, John Barfield > wrote: > > > > Thank you Dan. > > > > Do you happen to have the process or know the location of a process > document for only building ZFS? > > > > Ive re-built only nfs from illumos-gate in the past to resolve a bug but > im wondering how I would build and install only zfs. (if its even possible). > > > > There are 2 bugs that we're suffering with at two different customer > sites that didnt get into r151020 and Im not sure that we can make it till > r151022 is released. > > > > Thanks for any advice > > You can build zfs the way you likely built NFS. Build it, replace it on > an alternate BE (in zfs's case: /kernel/fs/amd64/zfs), and reboot. > > The only gotcha might be if a bugfix covers more than just ZFS itself... > but for 7504, that's NOT the case. :) > > Dan > > _______________________________________________ > 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 john.barfield at bissinc.com Tue Apr 18 14:51:13 2017 From: john.barfield at bissinc.com (John Barfield) Date: Tue, 18 Apr 2017 14:51:13 +0000 Subject: [OmniOS-discuss] ZPOOL bug after upgrade to r151020 In-Reply-To: References: <68E65E7C-DBFC-4014-BE18-3DDE3FF10AF7@bissinc.com> <3EE915D8-EA88-4FAD-BA99-933B01D06342@omniti.com> Message-ID: I did compile it. It seems to have fixed the deadlocsk but we?re still having performance issues that we were not having before. IMHO this is some type of regression. Here is the binary location: http://download.txtelecom.net/zfs Install procedure (As root): (Props to Dan McDonald for helping me with this process) ? beadm list (Note your current BE) ? zfs snap rpool at WHATEVER ? beadm create OmniOS-r151020-cstm ? beadm mount OmniOS-r151020-cstm /mnt ? cd /mnt/kernel/fs/amd64/ ? mv zfs zfs.old ? wget download.txtelecom.net/zfs ? cd ~ ? beadm unmount /mnt ? beadm activate OmniOS-r151020 ? shutdown ?i6 ?g0 The system will reboot twice?the first SAN I did this on rebooted both times flawlessly. On the Second system it froze while shutting down and we had to power cycle it. But it still came back online using the new build. Use this at your own risk. If it does fail completely simply choose your old BE on next reboot within grub. (Step 1 you?ll have a list) However, please see the following comments from my customer which are still occurring: John, I?ve copied 6GB, 37GB, and 61GB files from the thor /mnt local disk to a location on the San. Monitoring only shell activity on a few machines, nothing locked up (except thor). Although trying a ssh to thor took a minute to connect. While the ?cp? command was working, I monitor thor using ?top? command. * Of course, the load factor started to rise from 1 to over 5 on thor. * As the file was copying, I see the destination file size increase. * However, when the destination file size reached 6 or 37 or 61GB, thor?s load factor is still very high and remained high for a while. * If logged into thor, no work can be done while the ?cp? is ongoing. * Only after the ?cp? command was completed did thor?s load factor start to drop and work could be done if logged into thor. * Other machines, e.g. flash, linux8, had no issues. . . as far as I could tell. * I did not invoke any of the EDA tools. Additionally the VMware datastore on NFS(ZFS) bug that I was hoping to fix was only ? resolved as well. We can delete large files now but it brings the SAN to a crawl. Better than it used to be when it would come to a halt. I?d love to see if I could get a kernel hacker to look at both of these issues with us. John Barfield Engineering and Stuff M: +1 (214) 425-0783 O: +1 (214) 506-8354 john.barfield at bissinc.com [cid:image001.png at 01D2B829.5033AEE0] 4925 Greenville Ave, Ste 900 Dallas, TX 75206 For Support Requests: http://support.bissinc.com or support at bissinc.com Follow us on Twitter for Network Status & Updates! [cid:image002.gif at 01D2B829.5033AEE0] From: wuffers Date: Tuesday, April 18, 2017 at 9:38 AM To: Dan McDonald Cc: John Barfield , "omnios-discuss at lists.omniti.com" Subject: Re: [OmniOS-discuss] ZPOOL bug after upgrade to r151020 I upgraded to r151020 in late Jan, and saw some strangeness with arcstat (l2size and l2asize were huge) before I did a reboot due to some instability a few weeks ago. I thought it was just a case of not using the latest arcstat, and things were running fine after a reboot so didn't pursue it. I saw this post last week, and confirmed it was within my environment, so did the remove/re-add of the cache devices, then a complete reboot as well. The cache devices reported back their actual proper size (400GB) via "zpool iostat -v". Today I checked it again and this is what I see: # arcstat read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size l2asize 465 412 53 88 53 50 3 94 230G 4.4T 3.2T # zpool iostat -v (other info snipped for brevity) cache - - - - - - c2t500117310015D579d0 816G 16.0E 54 23 2.32M 1.46M c2t50011731001631FDd0 816G 16.0E 54 23 2.32M 1.46M c12t500117310015D59Ed0 815G 16.0E 55 23 2.35M 1.46M c12t500117310015D54Ed0 816G 16.0E 55 23 2.36M 1.46M I'm just waiting for the next lockup/crash.. John, were you able to compile the fix, and if so, be able send me a copy? Thanks. On Mon, Apr 10, 2017 at 10:00 AM, Dan McDonald > wrote: > On Apr 9, 2017, at 10:27 PM, John Barfield > wrote: > > Thank you Dan. > > Do you happen to have the process or know the location of a process document for only building ZFS? > > Ive re-built only nfs from illumos-gate in the past to resolve a bug but im wondering how I would build and install only zfs. (if its even possible). > > There are 2 bugs that we're suffering with at two different customer sites that didnt get into r151020 and Im not sure that we can make it till r151022 is released. > > Thanks for any advice You can build zfs the way you likely built NFS. Build it, replace it on an alternate BE (in zfs's case: /kernel/fs/amd64/zfs), and reboot. The only gotcha might be if a bugfix covers more than just ZFS itself... but for 7504, that's NOT the case. :) Dan _______________________________________________ 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: 3510 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1353 bytes Desc: image002.gif URL: From mtalbott at lji.org Tue Apr 18 20:35:52 2017 From: mtalbott at lji.org (Michael Talbott) Date: Tue, 18 Apr 2017 13:35:52 -0700 Subject: [OmniOS-discuss] RSF-1 and Zones Message-ID: <832030C0-DE80-4716-B114-256898954AA4@lji.org> Anyone out there use RSF-1 ( http://www.high-availability.com ) for ZFS HA and have some good scripts (or best practices) for handling failing over the zones along with the storage pools? Since I started using some zones on my storage nodes, it occured to me that if a failover were to happen it'll probably hang since the zones would be in-use and there's no scripts currently in place to stop them, export the config, import the config, and start them up on the other node. Before I go and write my own implementation I figured I'd see if anyone else has a good solution already written. Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at subsignal.org Wed Apr 19 07:19:15 2017 From: paul at subsignal.org (Paul) Date: Wed, 19 Apr 2017 09:19:15 +0200 Subject: [OmniOS-discuss] pkg update fails with ImageNotFoundExeption Message-ID: <655e1c9f-1d62-e99c-3b51-84038efa30c4@subsignal.org> Hi all, I tried to upgrade 151020 and "pkg update" failed with a python exception: root at omnios:/root# pkg update Packages to update: 309 Create boot environment: Yes Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED Completed 309/309 2867/2867 93.2/93.2 514k/s pkg: An unexpected error happened during update: No image rooted at '/tmp/tmp4TusBd' Traceback (most recent call last): File "/usr/bin/pkg", line 6346, in handle_errors __ret = func(*args, **kwargs) File "/usr/bin/pkg", line 6332, in main_func pargs=pargs, **opts) File "/usr/bin/pkg", line 2147, in update reject_list=reject_pats, update_index=update_index) File "/usr/bin/pkg", line 1856, in __api_op ret_code = __api_execute_plan(_op, _api_inst) File "/usr/bin/pkg", line 1435, in __api_execute_plan api_inst.execute_plan() File "/usr/lib/python2.6/vendor-packages/pkg/client/api.py", line 2608, in execute_plan self.__be_name) File "/usr/lib/python2.6/vendor-packages/pkg/client/bootenv.py", line 439, in init_image_recovery img.find_root(self.clone_dir, exact_match=True) File "/usr/lib/python2.6/vendor-packages/pkg/client/image.py", line 524, in find_root exact_match, startd, d) ImageNotFoundException: No image rooted at '/tmp/tmp4TusBd' pkg: This is an internal error in pkg(5) version 1473694678. Please log a Service Request about this issue including the information above and this message. (Note: line numbers above might be off by one, since I added a print()...) root at omnios:/root# beadm list BE Active Mountpoint Space Policy Created omnios - - 23.4M static 2016-12-18 22:08 omniosvar - - 23.0K static 2016-12-18 22:08 omnios-1 NR / 3.67G static 2017-01-08 18:00 omnios-2 - /tmp/tmpN5q20r 129K static 2017-04-05 20:01 omnios-3 - /tmp/tmpIljvPO 129K static 2017-04-05 20:08 omnios-4 - /tmp/tmp4TusBd 134K static 2017-04-19 08:13 root at omnios:/root# zfs list -r rpool/ROOT NAME USED AVAIL REFER MOUNTPOINT rpool/ROOT 2.99G 1.02G 23K legacy rpool/ROOT/omnios 23.4M 1.02G 1.72G / rpool/ROOT/omnios-1 2.97G 1.02G 1.90G / rpool/ROOT/omnios-2 129K 1.02G 1.84G /tmp/tmpN5q20r rpool/ROOT/omnios-3 129K 1.02G 1.84G /tmp/tmpIljvPO rpool/ROOT/omnios-4 134K 1.02G 1.90G /tmp/tmp4TusBd rpool/ROOT/omniosvar 23K 1.02G 23K legacy I tried to look at /usr/lib/python2.6/vendor-packages/pkg/client/image.py with pdb but I'm missing too much of the bigger picture to make any sense of the errors. It looks like the new BE is created correctly though. Maybe someone knows the steps to manually finish the process? I would like to try the new BE and see if the error persists. Any thoughts? thanks Paul From danmcd at omniti.com Wed Apr 19 13:08:14 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 19 Apr 2017 09:08:14 -0400 Subject: [OmniOS-discuss] Reminder - r151018 has reached EOSL Message-ID: Technically it was Friday, but OmniOS r151018 has reached end-of-service-life. You should be on r151020 by now, and coming soon, r151022. I mention this because I'm about to push out curl updates for 014 and 020. Thanks, Dan From danmcd at omniti.com Wed Apr 19 13:12:09 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 19 Apr 2017 09:12:09 -0400 Subject: [OmniOS-discuss] pkg update fails with ImageNotFoundExeption In-Reply-To: <655e1c9f-1d62-e99c-3b51-84038efa30c4@subsignal.org> References: <655e1c9f-1d62-e99c-3b51-84038efa30c4@subsignal.org> Message-ID: <1390B3D8-CAF6-4BC3-B501-E044BCE963A8@omniti.com> > On Apr 19, 2017, at 3:19 AM, Paul wrote: > > I tried to look at /usr/lib/python2.6/vendor-packages/pkg/client/image.py with pdb but I'm missing too much of the bigger picture to make any sense of the errors. It looks like the new BE is created correctly though. Maybe someone knows the steps to manually finish the process? I would like to try the new BE and see if the error persists. Any thoughts? Check the contents of the new BE's mount directory. Try this too: pkg -R /tmp/ publisher and see what it says. The dump you show seems to indicate that for some reason IPS doesn't like what's rooted in it. Do you do anything weird with filesystems that are supposed to be within the BE (like having /var on a different zfs dataset)? Dan From danmcd at omniti.com Wed Apr 19 13:23:15 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 19 Apr 2017 09:23:15 -0400 Subject: [OmniOS-discuss] New cURL - 7.54.0 Message-ID: <2223E7D5-15E5-4D2C-B551-BE072ADF9153@omniti.com> Please "pkg update" your boxes to receive the latest curl version, 7.54.0. This update contains a security fix (https://curl.haxx.se/docs/adv_20170419.html). Repo servers for bloody, r151020 (Stable), and r151014 (LTS) have all been updated. Thanks, Dan From jesper.louis.andersen at gmail.com Wed Apr 19 13:39:19 2017 From: jesper.louis.andersen at gmail.com (Jesper Louis Andersen) Date: Wed, 19 Apr 2017 13:39:19 +0000 Subject: [OmniOS-discuss] web site seems to attack server internet connection In-Reply-To: <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> References: <20170417164237.7ca61503@kendall> <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> Message-ID: Australia always raises a "latency" flag for me at least. Systems can have low timeouts internally which severely impacts their ability to handle an environment with high latency. I'd try snooping around and looking at a packet trace first. Make sure nothing fishy is happening at the lowest levels first, then work upwards until you figure out where the behavior is. On Mon, Apr 17, 2017 at 7:16 PM Dan McDonald wrote: > I'd recommend snoop -o on your NAT box/zone. > > I tried your steps, and did not see this problem. My NAT is more > sophisticated, servicing both my home and a work-from-home segment for > OmniTI, which was where I tried your reproduction. NO idea what might've > happened. > > Are you yourself in Australia? The problem could be country-local w.r.t. > any possible mischief. > > Dan > > _______________________________________________ > 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 wonko at 4amlunch.net Wed Apr 19 21:01:20 2017 From: wonko at 4amlunch.net (Brian Hechinger) Date: Wed, 19 Apr 2017 17:01:20 -0400 Subject: [OmniOS-discuss] Plex on LX zone howto In-Reply-To: References: <77BA335F-3D51-4A24-A522-4683FCD095FB@omniti.com> <5C0C5EF7B63644878C8A750176AC8B01@mail10.futurewins.com> Message-ID: <21607249-C3F0-4EE2-802A-9A18CB3B4B5D@4amlunch.net> Ok, looks like it might be something with Plex itself. Chatting about it in #smartos on IRC we?ve discovered (and tested) that inotify works both from changes made inside the zone and external to the zone. -brian > On Apr 12, 2017, at 12:49, Dan McDonald wrote: > > >> On Apr 12, 2017, at 12:37 PM, Brian Hechinger wrote: >> >> Just FYI, I set Plex on a LX zone. I used CentOS 7 and just so you know, file change notification doesn?t appear to work so checking the box in Plex to re-scan on new files doesn?t function. > > You may wish to see if bloody (soon to be r151022) may cure what ails you on this front. Some bugfixes pulled-in from SmartOS during the r151021 bloody cycle that may be relevant: > > OS-5900 io_getevents doesn't block when it should > OS-5926 epoll mishandles excessive timeout negativity > OS-5845 lx aio performance improvements and move into kernel > OS-5981 move eventfd in-kernel > OS-5990 fix for OS-5987 causes worker thread to mishandle some signals > OS-5991 refactor aio to remove exitlwp brand hook > OS-5992 harden aio worker thread signal handling > OS-5261 lxbrand eventfd AIO overflow behavior is incorrect > OS-6016 lxbrand poll(2) wants implicit events > > Can't guarantee it'll help, but it won't hurt. > > FYI, > Dan > From softwareinforjam at gmail.com Thu Apr 20 03:14:55 2017 From: softwareinforjam at gmail.com (Software Information) Date: Wed, 19 Apr 2017 22:14:55 -0500 Subject: [OmniOS-discuss] Interesting Nessus Scan Result Message-ID: Hi All I have my OmniOS box up and running with the latest patches and I ran Nessus against it to see what it would find. It showed two high vulnerabilities. One for RIP but disabling the routing daemon solved that one. I am stuck on the second one. Nessus reports "Cisco ASA Software CLI Invalid Command Invocation (cisco-sa-20160817-asa-cli) (EPICBANANA)" Description The Cisco Adaptive Security Appliance (ASA) is missing a vendor-supplied security patch. It is, therefore, affected by a flaw in the command-line interface (CLI) parser related to processing invalid commands. An authenticated, local attacker can exploit this, via certain invalid commands, to cause a denial of service condition or the execution of arbitrary code. Note that this vulnerability also affects Cisco PIX Firewalls and the Cisco Firewall Services Module (FWSM). EPICBANANA is one of multiple Equation Group vulnerabilities and exploits disclosed on 2016/08/14 by a group known as the Shadow Brokers. How can I get rid of this one. Any ideas anyone? Regards. SI -------------- next part -------------- An HTML attachment was scrubbed... URL: From omnios at citrus-it.net Thu Apr 20 08:58:44 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 20 Apr 2017 08:58:44 +0000 (UTC) Subject: [OmniOS-discuss] Interesting Nessus Scan Result In-Reply-To: References: Message-ID: On Wed, 19 Apr 2017, Software Information wrote: ; Hi All ; I have my OmniOS box up and running with the latest patches and I ran ; Nessus against it to see what it would find. It showed two high ; vulnerabilities. One for RIP but disabling the routing daemon solved that ; one. I am stuck on the second one. ; ; Nessus reports "Cisco ASA Software CLI Invalid Command Invocation ; (cisco-sa-20160817-asa-cli) (EPICBANANA)" That looks like a false positive to me. I just ran Nessus against an OmniOS box running bloody from a week or so ago and got nothing above info. It detected the RIP-2 daemon but didn't complain about it. Are you running any specific compliance checks or just a standard scan? Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From omnios at citrus-it.net Thu Apr 20 10:34:50 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 20 Apr 2017 10:34:50 +0000 (UTC) Subject: [OmniOS-discuss] Bloody web/curl update. Message-ID: My OmniOS Bloody box says that there is a web/curl update available but won't install it (says no updates available). Any ideas? I'm running the debug kernel in case it's relevant. Thanks! omni# pkg refresh omni# pkg list -u NAME (PUBLISHER) VERSION IFO web/curl 7.53.0-0.151021 i-- omni# pkg update No updates available for this image. zsh: exit 4 pkg update omni# pkg update -nv No updates available for this image. zsh: exit 4 pkg update -nv omni# pkg variant VARIANT VALUE arch i386 debug.illumos true opensolaris.zone global -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From danmcd at omniti.com Thu Apr 20 12:24:13 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 20 Apr 2017 08:24:13 -0400 Subject: [OmniOS-discuss] Bloody web/curl update. In-Reply-To: References: Message-ID: <098705EB-CA07-4F82-A536-0C4EF5588B40@omniti.com> I have to push out entire and OmniOS-userland consolidation updates as well. Sorry about that - will do that later this morning. Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 20, 2017, at 6:34 AM, Andy Fiddaman wrote: > > > My OmniOS Bloody box says that there is a web/curl update available but > won't install it (says no updates available). Any ideas? I'm running the > debug kernel in case it's relevant. > > Thanks! > > omni# pkg refresh > omni# pkg list -u > NAME (PUBLISHER) VERSION IFO > web/curl 7.53.0-0.151021 i-- > omni# pkg update > No updates available for this image. > zsh: exit 4 pkg update > omni# pkg update -nv > No updates available for this image. > zsh: exit 4 pkg update -nv > > omni# pkg variant > VARIANT VALUE > arch i386 > debug.illumos true > opensolaris.zone global > > -- > 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 From danmcd at omniti.com Thu Apr 20 12:41:56 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 20 Apr 2017 08:41:56 -0400 Subject: [OmniOS-discuss] Bloody web/curl update. In-Reply-To: <098705EB-CA07-4F82-A536-0C4EF5588B40@omniti.com> References: <098705EB-CA07-4F82-A536-0C4EF5588B40@omniti.com> Message-ID: ENOCAFFEINE -- it's not because of entire or OmniOS-userland. I'll investigate this more when I get back from the Dr. Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 20, 2017, at 8:24 AM, Dan McDonald wrote: > > I have to push out entire and OmniOS-userland consolidation updates as well. > > Sorry about that - will do that later this morning. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Apr 20, 2017, at 6:34 AM, Andy Fiddaman wrote: >> >> >> My OmniOS Bloody box says that there is a web/curl update available but >> won't install it (says no updates available). Any ideas? I'm running the >> debug kernel in case it's relevant. >> >> Thanks! >> >> omni# pkg refresh >> omni# pkg list -u >> NAME (PUBLISHER) VERSION IFO >> web/curl 7.53.0-0.151021 i-- >> omni# pkg update >> No updates available for this image. >> zsh: exit 4 pkg update >> omni# pkg update -nv >> No updates available for this image. >> zsh: exit 4 pkg update -nv >> >> omni# pkg variant >> VARIANT VALUE >> arch i386 >> debug.illumos true >> opensolaris.zone global >> >> -- >> 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 From eric.sproul at circonus.com Thu Apr 20 14:08:50 2017 From: eric.sproul at circonus.com (Eric Sproul) Date: Thu, 20 Apr 2017 10:08:50 -0400 Subject: [OmniOS-discuss] Bloody web/curl update. In-Reply-To: References: Message-ID: On Thu, Apr 20, 2017 at 6:34 AM, Andy Fiddaman wrote: > > My OmniOS Bloody box says that there is a web/curl update available but > won't install it (says no updates available). Any ideas? I'm running the > debug kernel in case it's relevant. When I hit situations like this I usually try a verbose update with a specific target version, which induces pkg(1) to output more useful info: $ sudo pkg update -v curl at 7.54.0 Creating Plan (Solver setup): - pkg update: No matching version of web/curl can be installed: Reject: pkg://omnios/web/curl at 7.54.0-0.151021 Reason: No version for 'require' dependency on library/nghttp2 at 1.21.1-0.151021 can be found It looks like curl requires an unreleased update of nghttp2. Latest in the repo is 1.21.0 from 14 April. Eric From softwareinforjam at gmail.com Thu Apr 20 14:13:54 2017 From: softwareinforjam at gmail.com (Software Information) Date: Thu, 20 Apr 2017 09:13:54 -0500 Subject: [OmniOS-discuss] Interesting Nessus Scan Result In-Reply-To: References: Message-ID: Thanks for replying. I used the advanced scan (please see screenshot below) and just to note also, this showed up after I updated Nessus to version 6.10.4 yesterday and ran the scan again. [image: Inline image 1] On Thu, Apr 20, 2017 at 3:58 AM, Andy Fiddaman wrote: > > On Wed, 19 Apr 2017, Software Information wrote: > > ; Hi All > ; I have my OmniOS box up and running with the latest patches and I ran > ; Nessus against it to see what it would find. It showed two high > ; vulnerabilities. One for RIP but disabling the routing daemon solved that > ; one. I am stuck on the second one. > ; > ; Nessus reports "Cisco ASA Software CLI Invalid Command Invocation > ; (cisco-sa-20160817-asa-cli) (EPICBANANA)" > > That looks like a false positive to me. I just ran Nessus against an > OmniOS box running bloody from a week or so ago and got nothing above > info. It detected the RIP-2 daemon but didn't complain about it. > Are you running any specific compliance checks or just a standard > scan? > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 19079 bytes Desc: not available URL: From danmcd at omniti.com Thu Apr 20 14:14:33 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 20 Apr 2017 10:14:33 -0400 Subject: [OmniOS-discuss] Bloody web/curl update. In-Reply-To: References: Message-ID: Now that I'm home... > On Apr 20, 2017, at 6:34 AM, Andy Fiddaman wrote: > > My OmniOS Bloody box says that there is a web/curl update available but > won't install it (says no updates available). Any ideas? I'm running the > debug kernel in case it's relevant. > > Thanks! > > omni# pkg refresh > omni# pkg list -u > NAME (PUBLISHER) VERSION IFO > web/curl 7.53.0-0.151021 i-- > omni# pkg update > No updates available for this image. > zsh: exit 4 pkg update > omni# pkg update -nv > No updates available for this image. > zsh: exit 4 pkg update -nv > > omni# pkg variant > VARIANT VALUE > arch i386 > debug.illumos true > opensolaris.zone global variant shouldn't matter. The right thing should happen. My "user-like" bloody box was behind a whole update from what's on https://pkg.omniti.com/omnios/bloody/. And now I see the problem: # pkg list -v curl FMRI IFO pkg://omnios/web/curl at 7.53.0-0.151021:20170414T054849Z i-- # pkg update curl at 7.54 Creating Plan (Solver setup): - pkg update: No matching version of web/curl can be installed: Reject: pkg://omnios/web/curl at 7.54.0-0.151021 Reason: No version for 'require' dependency on library/nghttp2 at 1.21.1-0.151021 can be found # pkg contents -m entire | grep nghttp depend fmri=library/nghttp2 at 1.19.0,5.11-0.151021 type=require # I'm about to push out a new full update to bloody today anyway, so please watch for that. Dan From omnios at citrus-it.net Thu Apr 20 15:11:34 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 20 Apr 2017 15:11:34 +0000 (UTC) Subject: [OmniOS-discuss] Interesting Nessus Scan Result In-Reply-To: References: Message-ID: On Thu, 20 Apr 2017, Software Information wrote: ; Thanks for replying. I used the advanced scan (please see screenshot below) ; and just to note also, this showed up after I updated Nessus to version ; 6.10.4 yesterday and ran the scan again. I'm running 6.10.5 here, not sure when that was released. I'll try another scan with the default advanced settings and see if I can replicate what you're seeing. 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 bauernfeind at ipk-gatersleben.de Thu Apr 20 15:52:29 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Thu, 20 Apr 2017 15:52:29 +0000 Subject: [OmniOS-discuss] tzselect for kayak installer Message-ID: Hello all, I thought that adding a menu for the timezone selection might be an idea. As I wrote to Dan, it uses tzselect(1M) instead of entering the $TZ manually. It's only a little modification of the rpool-install.sh file, as seeing in my pull request: https://github.com/omniti-labs/kayak/pull/15 I need your opinion if this change is worth or not. - more "user-friendly" - a typo error is not possible, as tzselect builds the $TZ value for you Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From danmcd at omniti.com Thu Apr 20 15:59:05 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 20 Apr 2017 11:59:05 -0400 Subject: [OmniOS-discuss] tzselect for kayak installer In-Reply-To: References: Message-ID: <4500A3CB-FE94-4DBA-8C9B-53976B4793D8@omniti.com> > On Apr 20, 2017, at 11:52 AM, Jens Bauernfeind wrote: > > Hello all, > > I thought that adding a menu for the timezone selection might be an idea. > As I wrote to Dan, it uses tzselect(1M) instead of entering the $TZ > manually. > > It's only a little modification of the rpool-install.sh file, as seeing in > my pull request: > https://github.com/omniti-labs/kayak/pull/15 > > I need your opinion if this change is worth or not. > > - more "user-friendly" > - a typo error is not possible, as tzselect builds the $TZ value for you I haven't pulled it in yet, but I am going to. Community --> if I'm being hasty, this is the time to go to PR #15 and correct me. I think this is a generally good idea, however. ESPECIALLY since, unlike the caiman TZ selector, it doesn't use any crappy hacks to the stock TZ database (e.g. libzoneinfo). Dan From vab at bb-c.de Thu Apr 20 16:07:36 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 20 Apr 2017 18:07:36 +0200 Subject: [OmniOS-discuss] tzselect for kayak installer In-Reply-To: <4500A3CB-FE94-4DBA-8C9B-53976B4793D8@omniti.com> References: <4500A3CB-FE94-4DBA-8C9B-53976B4793D8@omniti.com> Message-ID: <22776.56520.861890.782977@shelob.bb-c.de> Dan McDonald writes: > > > On Apr 20, 2017, at 11:52 AM, Jens Bauernfeind wrote: > > > > Hello all, > > > > I thought that adding a menu for the timezone selection might be an idea. > > As I wrote to Dan, it uses tzselect(1M) instead of entering the $TZ > > manually. > > > > It's only a little modification of the rpool-install.sh file, as seeing in > > my pull request: > > https://github.com/omniti-labs/kayak/pull/15 > > > > I need your opinion if this change is worth or not. > > > > - more "user-friendly" > > - a typo error is not possible, as tzselect builds the $TZ value for you > > I haven't pulled it in yet, but I am going to. > > Community --> if I'm being hasty, this is the time to go to PR #15 and > correct me. I think this is a generally good idea, however. ESPECIALLY > since, unlike the caiman TZ selector, it doesn't use any crappy hacks to the > stock TZ database (e.g. libzoneinfo). >From looking at the screen output, +1. EXCEPT: There is the crappy "Busingen" time zone entry for Germany. Please get rid of that. First of all, the place is spelled "B?singen" with an umlaut. Then, the time zone difference was a one-off affair (in 1980). Please let the millions of OmniOS users amongst the 1350 inhabitants of B?singen select either German or Swiss time zone at their leasure. They will end up with CET either way. Thanks -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From danmcd at omniti.com Thu Apr 20 16:17:11 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 20 Apr 2017 12:17:11 -0400 Subject: [OmniOS-discuss] tzselect for kayak installer In-Reply-To: <22776.56520.861890.782977@shelob.bb-c.de> References: <4500A3CB-FE94-4DBA-8C9B-53976B4793D8@omniti.com> <22776.56520.861890.782977@shelob.bb-c.de> Message-ID: <0F4566ED-DDB0-48A3-90DE-C4A3E637638B@omniti.com> > On Apr 20, 2017, at 12:07 PM, Volker A. Brandt wrote: > > From looking at the screen output, +1. > > EXCEPT: There is the crappy "Busingen" time zone entry for Germany. > Please get rid of that. First of all, the place is spelled "B?singen" > with an umlaut. Then, the time zone difference was a one-off affair > (in 1980). Please let the millions of OmniOS users amongst the 1350 > inhabitants of B?singen select either German or Swiss time zone at > their leasure. They will end up with CET either way. This is pulled from the IANA TZ database. Ask them... Dan From vab at bb-c.de Thu Apr 20 16:24:15 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 20 Apr 2017 18:24:15 +0200 Subject: [OmniOS-discuss] tzselect for kayak installer In-Reply-To: <0F4566ED-DDB0-48A3-90DE-C4A3E637638B@omniti.com> References: <4500A3CB-FE94-4DBA-8C9B-53976B4793D8@omniti.com> <22776.56520.861890.782977@shelob.bb-c.de> <0F4566ED-DDB0-48A3-90DE-C4A3E637638B@omniti.com> Message-ID: <22776.57519.467011.698891@shelob.bb-c.de> > > EXCEPT: There is the crappy "Busingen" time zone entry for Germany. > > Please get rid of that. First of all, the place is spelled "B?singen" > > with an umlaut. Then, the time zone difference was a one-off affair > > (in 1980). Please let the millions of OmniOS users amongst the 1350 > > inhabitants of B?singen select either German or Swiss time zone at > > their leasure. They will end up with CET either way. > > This is pulled from the IANA TZ database. Ask them... So the abomination will live on. Sigh... Anyway, the rest looks good. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From danmcd at omniti.com Thu Apr 20 16:27:14 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 20 Apr 2017 12:27:14 -0400 Subject: [OmniOS-discuss] tzselect for kayak installer In-Reply-To: <22776.57519.467011.698891@shelob.bb-c.de> References: <4500A3CB-FE94-4DBA-8C9B-53976B4793D8@omniti.com> <22776.56520.861890.782977@shelob.bb-c.de> <0F4566ED-DDB0-48A3-90DE-C4A3E637638B@omniti.com> <22776.57519.467011.698891@shelob.bb-c.de> Message-ID: <079ADB4C-2A66-4AF4-8AEB-B939F7D90493@omniti.com> > On Apr 20, 2017, at 12:24 PM, Volker A. Brandt wrote: > > So the abomination will live on. Sigh... You can engage them via tz at iana.org, y'know. :) Dan From mir at miras.org Thu Apr 20 16:44:16 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 20 Apr 2017 18:44:16 +0200 Subject: [OmniOS-discuss] Kayak: netinstaller Message-ID: <20170420184416.55c91bf2@sleipner.datanom.net> Hi Dan, Have you had time looking into the latest changes? Any news on whether it have a chance of entering OmniOS? -- 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: A rolling disk gathers no MOS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Fri Apr 21 03:08:31 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 20 Apr 2017 23:08:31 -0400 Subject: [OmniOS-discuss] OmniOS bloody update -- countdown to r151022 Message-ID: <1CEDB82A-E38E-4EAB-8663-BBA12ECD910E@omniti.com> Hello! I've updated all of the omnios-build packages for bloody, in anticipation of getting r151022 ready for a release sometime in May. There's still some debugging to do for r151022 (and some PRs to accept), and a couple of more illumos merges, but with this update we have several new things to report. Speaking of debugging, a few of the debugging items involve the installer ISO, so there will not be an ISO update with this bump. uname -v shows omnios-master-c561ad5255 (Note the new, longer, hash, part of the git(1) upgrade). omnios-build was built from commit 5806fb4. New in this build: - Parent-dependent IPS packages ---> This means for some system-critical package, "pkg update" even WITHOUT "-r" will update linked-image zones. - ZFS fixes, including illumos 7885 (16.0e reported for expandsz) - zone-centered modernization of shutdown(1M) (illumos 8034) - LX improvements - illumos 8085 -- Handle RPC group lists better. - Bind to 9.10.4-P8 - NSS to 3.30.1, NSPR to 4.14 - GNU coreutils to 8.27 - Curl to 7.54 - dbus to 1.11.12 - git to 2.12.2 - GMP to 6.1.2 - gnu-grep to 3.0 - ISO-codes to 43.74 - less to 487 - libpcap to 1.8.1 - GNU m4 to 1.4.18 - Mercurial to 4.1.3 (NOTE: There have been reports via OpenIndiana that this version of hg doesn't play entirely nice with illumos) - nghttp2 to 1.21.1 - pkg-config to 0.29.2 - Various python-package updates. - screen to 4.5.1 - GNU sed to 4.4 - tcsh to 6.20 - vim 8 is now at patchlevel 567 - zsh to 5.3.1 Happy upgrading! Dan From paul at subsignal.org Fri Apr 21 08:54:03 2017 From: paul at subsignal.org (Paul) Date: Fri, 21 Apr 2017 10:54:03 +0200 Subject: [OmniOS-discuss] pkg update fails with ImageNotFoundExeption In-Reply-To: <1390B3D8-CAF6-4BC3-B501-E044BCE963A8@omniti.com> References: <655e1c9f-1d62-e99c-3b51-84038efa30c4@subsignal.org> <1390B3D8-CAF6-4BC3-B501-E044BCE963A8@omniti.com> Message-ID: <450f4a1a-2fd5-c3a4-e45f-9395e8625285@subsignal.org> Hi Dan, thanks for answering... Am 19.04.2017 um 15:12 schrieb Dan McDonald: > Check the contents of the new BE's mount directory. Try this too: > > pkg -R /tmp/ publisher Same error as above. > > Do you do anything weird with filesystems that are supposed to be within the > BE (like having /var on a different zfs dataset)? Guilty as charged ;) Moved /var/pkg due to space contraints, bad idea if you think about it... thanks again, Paul > > Dan > From robert at omniti.com Fri Apr 21 14:07:20 2017 From: robert at omniti.com (Robert Treat) Date: Fri, 21 Apr 2017 10:07:20 -0400 Subject: [OmniOS-discuss] The Future of OmniOS Message-ID: Five years ago, when we first launched OmniOS, we did it out of a direct need to push forward the OpenSolaris ecosystem that we had built into the core of several parts of our business. At the time, the illumos community was still rather new and taking direct control of our path forward was a solid next step; we had already built many of the pieces in-house that we needed to produce a complete operating system distribution, and our experiences with open sourcing software we worked on had been generally very good. While we didn't know quite what the reaction would be, there were two things internally that guided us as long term factors in our decision. First, as we have done for other open source software, we thought it made sense to offer commercial support for OmniOS, but there was no desire to "pivot" OmniTI to be an operating system vendor. We like the world of building and running high-scale software and infrastructure and that's where we wanted to stay. Hand in hand with that was the second idea, that while we felt it was important for us to take the first initial steps, in the long term we really would prefer that OmniOS become an open source project maintained by its community rather than remain as the open source product of a single commercial entity (think Debian vs Red Hat, if that helps). Five years later, we are proud to see that this software has been accepted by a wide group of companies and end users, and we think this has been a boon for the illumos community, who are the shoulders we build upon. When you see companies from all sectors and industry, both small and some orders of magnitude larger, using the technology you put forward to build even further; well, it's great to have an impact. However, even with the success we have had, there is one area we have failed to make progress on, which is the goal of making OmniOS community operated. There are many factors why this hasn't happened, but ultimately in five years of both ups and downs within OmniTI, I am left to conclude that if we are ever to change the nature of OmniOS, we need to take a radical approach. Therefore, going forward, while some of our staff may continue contributing, OmniTI will be suspending active development of OmniOS. Our next release, currently in beta, will become the final release from OmniTI. We are currently going through steps to remove any build dependencies on OmniTI or its infrastructure, and we've made some steps towards determining what potential resources we currently control which could be turned over to an open source community should one emerge; for example, we can continue running OmniOS mailing lists from OmniTI, but would eventually like to see those transitioned to something operated by the community itself. To be clear, our goal is not to abandon OmniOS, but to divest OmniTI from the open source project in order to spur others to participate more. We still run quite a bit of infrastructure on OmniOS and expect to continue contributing, but the current model does not work for OmniTI nor do we believe it is healthy for the OmniOS community as a whole. Could this mean the end of OmniOS? We can't guarantee it won't. For that matter, recent user data shows that a majority of the community still uses OmniOS primarily as a storage solution, not a platform for high-scale web computing (which was our original intent), so even if a community does form, it could move the project in a direction that doesn't align with our needs. If that happens, we feel comfortable knowing there are several other strong illumos based options available. In the end, while this rip-the-band-aid-off approach is not without risk, it is one we feel is necessary. We hope that most folks will respond to this not with fear but with the understanding that there is now an opportunity to build a broader, stronger community, and we look forward to working with others to make that a reality. Robert Treat CEO https://omniti.com From henson at acm.org Fri Apr 21 19:19:44 2017 From: henson at acm.org (Paul B. Henson) Date: Fri, 21 Apr 2017 12:19:44 -0700 Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: References: Message-ID: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> As both a home hobbyist user of OmniOS and a paid support user of OmniOS at my day job, I'd first like to thank you guys for putting together a great operating system that has served me well over the years and I hope will continue to do so. However, I would like to clarify your stance when you say you are "suspending active development" and that r151022 will be the "final release". Per your historical release cycle: https://omnios.omniti.com/wiki.php/ReleaseCycle r151022 was to be an LTS release with security/bug fix support through H1 2020. While there will be no further releases of OmniOS from OmniTI, will you continue to back port fixes and fix issues in r151022 through that timeline, or will it be released as is and then be up to the as yet undeveloped community to do so? We currently have critical production systems deployed, systems whose deployment was only approved by management due to the availability of commercial support (the wisdom of such a perspective we will not discuss), and this sudden development is potentially going to leave us in quite a pickle. While I certainly can't dictate to you how to run your business, it would have been much easier on your customers had you made this announcement with the release of r151022, and coincided the end of your support offering with the end of life of this last release. Which also ideally would have provided time for an omnios community to have developed and started producing their own releases before the last officially supported omniti version reached sunset. > -----Original Message----- > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > On Behalf Of Robert Treat > Sent: Friday, April 21, 2017 7:07 AM > To: omnios-discuss > Subject: [OmniOS-discuss] The Future of OmniOS > > Five years ago, when we first launched OmniOS, we did it out of a > direct need to push forward the OpenSolaris ecosystem that we had > built into the core of several parts of our business. At the time, the > illumos community was still rather new and taking direct control of > our path forward was a solid next step; we had already built many of > the pieces in-house that we needed to produce a complete operating > system distribution, and our experiences with open sourcing software > we worked on had been generally very good. > > While we didn't know quite what the reaction would be, there were two > things internally that guided us as long term factors in our decision. > First, as we have done for other open source software, we thought it > made sense to offer commercial support for OmniOS, but there was no > desire to "pivot" OmniTI to be an operating system vendor. We like the > world of building and running high-scale software and infrastructure > and that's where we wanted to stay. Hand in hand with that was the > second idea, that while we felt it was important for us to take the > first initial steps, in the long term we really would prefer that > OmniOS become an open source project maintained by its community > rather than remain as the open source product of a single commercial > entity (think Debian vs Red Hat, if that helps). > > Five years later, we are proud to see that this software has been > accepted by a wide group of companies and end users, and we think this > has been a boon for the illumos community, who are the shoulders we > build upon. When you see companies from all sectors and industry, both > small and some orders of magnitude larger, using the technology you > put forward to build even further; well, it's great to have an impact. > > However, even with the success we have had, there is one area we have > failed to make progress on, which is the goal of making OmniOS > community operated. There are many factors why this hasn't happened, > but ultimately in five years of both ups and downs within OmniTI, I am > left to conclude that if we are ever to change the nature of OmniOS, > we need to take a radical approach. > > Therefore, going forward, while some of our staff may continue > contributing, OmniTI will be suspending active development of OmniOS. > Our next release, currently in beta, will become the final release > from OmniTI. We are currently going through steps to remove any build > dependencies on OmniTI or its infrastructure, and we've made some > steps towards determining what potential resources we currently > control which could be turned over to an open source community should > one emerge; for example, we can continue running OmniOS mailing lists > from OmniTI, but would eventually like to see those transitioned to > something operated by the community itself. > > To be clear, our goal is not to abandon OmniOS, but to divest OmniTI > from the open source project in order to spur others to participate > more. We still run quite a bit of infrastructure on OmniOS and expect > to continue contributing, but the current model does not work for > OmniTI nor do we believe it is healthy for the OmniOS community as a > whole. Could this mean the end of OmniOS? We can't guarantee it won't. > For that matter, recent user data shows that a majority of the > community still uses OmniOS primarily as a storage solution, not a > platform for high-scale web computing (which was our original intent), > so even if a community does form, it could move the project in a > direction that doesn't align with our needs. If that happens, we feel > comfortable knowing there are several other strong illumos based > options available. In the end, while this rip-the-band-aid-off > approach is not without risk, it is one we feel is necessary. > > We hope that most folks will respond to this not with fear but with > the understanding that there is now an opportunity to build a broader, > stronger community, and we look forward to working with others to make > that a reality. > > > Robert Treat > CEO > https://omniti.com > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Fri Apr 21 20:14:36 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 21 Apr 2017 16:14:36 -0400 Subject: [OmniOS-discuss] OmniOS bloody update -- countdown to r151022 In-Reply-To: <1CEDB82A-E38E-4EAB-8663-BBA12ECD910E@omniti.com> References: <1CEDB82A-E38E-4EAB-8663-BBA12ECD910E@omniti.com> Message-ID: > On Apr 20, 2017, at 11:08 PM, Dan McDonald wrote: > > Speaking of debugging, a few of the debugging items involve the installer ISO, so there will not be an ISO update with this bump. Debugging of the installer went better than expected, AND there's a better Timezone selector now thanks to Jens Bauernfeind. This page: http://omnios.omniti.com/wiki.php/Installation now has updated ISO, USB-DD, and ZFS receive images for the new bloody. Until r151022 ships, I'm still hard at work, so please keep banging away on these as I am. Thanks, Dan From tobi at oetiker.ch Fri Apr 21 20:52:57 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Fri, 21 Apr 2017 22:52:57 +0200 (CEST) Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: References: Message-ID: <2013615491.242474.1492807977230.JavaMail.zimbra@oetiker.ch> So, there you have it ... software is not free, and for something as complex and slick as OmniOS, there is serious money involved in keeping it at its current level. It seems that OmniTI has not managed to get this message across to the many organizations relying on OmniOS to run their Servers. Robert has suggested that he hopes that 'the community' will take up the maintenance of omnios in the future ... but I wonder ... now that we know what is going to happen. Do you think your organisation would be prepared to spend some 'real bucks' on keeping OmniOS maintained professionally? I think we would be looking at something like ~500k USD per year. For 1-2 People to continue running the show. I have setup a chat on Gitter ... https://gitter.im/PostOmniOS/Lobby lets meet there and discuss. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From mtalbott at lji.org Fri Apr 21 23:50:45 2017 From: mtalbott at lji.org (Michael Talbott) Date: Fri, 21 Apr 2017 16:50:45 -0700 Subject: [OmniOS-discuss] RSF-1 and Zones In-Reply-To: <832030C0-DE80-4716-B114-256898954AA4@lji.org> References: <832030C0-DE80-4716-B114-256898954AA4@lji.org> Message-ID: <9DF6F7EA-B1BD-4C3C-8537-3FE57D2D6002@lji.org> All, I'm answering my own question here, but, a few other users reached out to me about it so I'm posting my own crafted solution below which I've found to work very well with my particular setup. The key of making an HA zone (assuming RSF-1 is already working properly) is to configure both/all nodes with the zone making sure they point to the shared storage and making sure all vnic or other networking is already in place (and make sure theres no naming conflicts). If you update the zone configuration on one node you need to do it to all of them so when a failover occurs you don't end up with a different config. I didn't bother automating that part since that can be a tricky issue that adds complexity that I don't need in my case. Here's the core of the failover logic needed: In /opt/HAC/RSF-1/etc/rc.appliance.c/ add these scripts: First, a kill script for ONLY the related zones on the shared storage going down. RSF-1 is kind enough to give us an exported variable RSF_SERVICE we can extract some important info from :D K70_zones #!/bin/bash SERVICE=${RSF_SERVICE:-"servicename"} # halt related non-global zones referencing failing service ZONES=$(zoneadm list | egrep -v '^global$') while read ZONE; do zonecfg -z $ZONE export | grep "$SERVICE" [[ "$?" == "0" ]] && zoneadm -z $ZONE halt done <<< "$ZONES" And a start script to attach and bring up any/all accessible/attached/installed zones: S70_zones #!/bin/bash # attach configured zones CZONES=$(zoneadm list -c | egrep -v '^global$') while read ZONE; do zoneadm -z $ZONE attach -F done <<< "$CZONES" # boot installed zones IZONES=$(zoneadm list -c | egrep -v '^global$') while read ZONE; do zoneadm -z $ZONE boot done <<< "$IZONES" There's obviously room for improvement, but, this is all I need in order to make my LX zones (hosting beegfs storage servers) highly available for our HPC cluster :) If anyone has any suggestions to make this better, I'm all ears. Michael > On Apr 18, 2017, at 1:35 PM, Michael Talbott wrote: > > Anyone out there use RSF-1 ( http://www.high-availability.com ) for ZFS HA and have some good scripts (or best practices) for handling failing over the zones along with the storage pools? > > Since I started using some zones on my storage nodes, it occured to me that if a failover were to happen it'll probably hang since the zones would be in-use and there's no scripts currently in place to stop them, export the config, import the config, and start them up on the other node. > > Before I go and write my own implementation I figured I'd see if anyone else has a good solution already written. > > Thanks, > > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Sun Apr 23 14:16:44 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 23 Apr 2017 09:16:44 -0500 (CDT) Subject: [OmniOS-discuss] Source for OmniOS Wiki? Message-ID: Is there a means available to capture the OmniOS Wiki content (for local reference) other than spidering the web site or saving each web page on the Wiki individually? Thanks, Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From robert at omniti.com Sun Apr 23 20:13:37 2017 From: robert at omniti.com (Robert Treat) Date: Sun, 23 Apr 2017 16:13:37 -0400 Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> Message-ID: Security updates are a little bit trickier than just pulling in general upstream changes, but I think the ideal scenario would be to form a group of interested people around the "security at omnios.org" label which would collaborate on fielding and producing security fixes for the project. Given we also have critical production systems running OmniOS (more than most I suspect), we will need to deal with security and bug fixes regardless, so we're happy to use those efforts to bootstrap things. Robert Treat On Fri, Apr 21, 2017 at 3:19 PM, Paul B. Henson wrote: > As both a home hobbyist user of OmniOS and a paid support user of OmniOS at > my day job, I'd first like to thank you guys for putting together a great > operating system that has served me well over the years and I hope will > continue to do so. > > However, I would like to clarify your stance when you say you are > "suspending active development" and that r151022 will be the "final > release". Per your historical release cycle: > > https://omnios.omniti.com/wiki.php/ReleaseCycle > > r151022 was to be an LTS release with security/bug fix support through H1 > 2020. While there will be no further releases of OmniOS from OmniTI, will > you continue to back port fixes and fix issues in r151022 through that > timeline, or will it be released as is and then be up to the as yet > undeveloped community to do so? We currently have critical production > systems deployed, systems whose deployment was only approved by management > due to the availability of commercial support (the wisdom of such a > perspective we will not discuss), and this sudden development is potentially > going to leave us in quite a pickle. While I certainly can't dictate to you > how to run your business, it would have been much easier on your customers > had you made this announcement with the release of r151022, and coincided > the end of your support offering with the end of life of this last release. > Which also ideally would have provided time for an omnios community to have > developed and started producing their own releases before the last > officially supported omniti version reached sunset. > >> -----Original Message----- >> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] >> On Behalf Of Robert Treat >> Sent: Friday, April 21, 2017 7:07 AM >> To: omnios-discuss >> Subject: [OmniOS-discuss] The Future of OmniOS >> >> Five years ago, when we first launched OmniOS, we did it out of a >> direct need to push forward the OpenSolaris ecosystem that we had >> built into the core of several parts of our business. At the time, the >> illumos community was still rather new and taking direct control of >> our path forward was a solid next step; we had already built many of >> the pieces in-house that we needed to produce a complete operating >> system distribution, and our experiences with open sourcing software >> we worked on had been generally very good. >> >> While we didn't know quite what the reaction would be, there were two >> things internally that guided us as long term factors in our decision. >> First, as we have done for other open source software, we thought it >> made sense to offer commercial support for OmniOS, but there was no >> desire to "pivot" OmniTI to be an operating system vendor. We like the >> world of building and running high-scale software and infrastructure >> and that's where we wanted to stay. Hand in hand with that was the >> second idea, that while we felt it was important for us to take the >> first initial steps, in the long term we really would prefer that >> OmniOS become an open source project maintained by its community >> rather than remain as the open source product of a single commercial >> entity (think Debian vs Red Hat, if that helps). >> >> Five years later, we are proud to see that this software has been >> accepted by a wide group of companies and end users, and we think this >> has been a boon for the illumos community, who are the shoulders we >> build upon. When you see companies from all sectors and industry, both >> small and some orders of magnitude larger, using the technology you >> put forward to build even further; well, it's great to have an impact. >> >> However, even with the success we have had, there is one area we have >> failed to make progress on, which is the goal of making OmniOS >> community operated. There are many factors why this hasn't happened, >> but ultimately in five years of both ups and downs within OmniTI, I am >> left to conclude that if we are ever to change the nature of OmniOS, >> we need to take a radical approach. >> >> Therefore, going forward, while some of our staff may continue >> contributing, OmniTI will be suspending active development of OmniOS. >> Our next release, currently in beta, will become the final release >> from OmniTI. We are currently going through steps to remove any build >> dependencies on OmniTI or its infrastructure, and we've made some >> steps towards determining what potential resources we currently >> control which could be turned over to an open source community should >> one emerge; for example, we can continue running OmniOS mailing lists >> from OmniTI, but would eventually like to see those transitioned to >> something operated by the community itself. >> >> To be clear, our goal is not to abandon OmniOS, but to divest OmniTI >> from the open source project in order to spur others to participate >> more. We still run quite a bit of infrastructure on OmniOS and expect >> to continue contributing, but the current model does not work for >> OmniTI nor do we believe it is healthy for the OmniOS community as a >> whole. Could this mean the end of OmniOS? We can't guarantee it won't. >> For that matter, recent user data shows that a majority of the >> community still uses OmniOS primarily as a storage solution, not a >> platform for high-scale web computing (which was our original intent), >> so even if a community does form, it could move the project in a >> direction that doesn't align with our needs. If that happens, we feel >> comfortable knowing there are several other strong illumos based >> options available. In the end, while this rip-the-band-aid-off >> approach is not without risk, it is one we feel is necessary. >> >> We hope that most folks will respond to this not with fear but with >> the understanding that there is now an opportunity to build a broader, >> stronger community, and we look forward to working with others to make >> that a reality. >> >> >> Robert Treat >> CEO >> https://omniti.com >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > From minikola at gmail.com Mon Apr 24 07:33:49 2017 From: minikola at gmail.com (Nikola M) Date: Mon, 24 Apr 2017 09:33:49 +0200 Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> Message-ID: <9dde4936-899b-9cf2-4f1f-d6213a58161d@gmail.com> On 04/21/17 09:19 PM, Paul B. Henson wrote: > As both a home hobbyist user of OmniOS and a paid support user of OmniOS at > my day job, I'd first like to thank you guys for putting together a great > operating system that has served me well over the years and I hope will > continue to do so. > > However, I would like to clarify your stance when you say you are > "suspending active development" and that r151022 will be the "final > release". Per your historical release cycle: > > https://omnios.omniti.com/wiki.php/ReleaseCycle > > r151022 was to be an LTS release with security/bug fix support through H1 > 2020. While there will be no further releases of OmniOS from OmniTI, will > you continue to back port fixes and fix issues in r151022 through that > timeline, or will it be released as is and then be up to the as yet > undeveloped community to do so? I suppose OmniOS community can pay 2 guys with ease to maintain it and surrounding expenses. When you look at it, it is more then cost effective to have 2 guys stay on the payroll, not to mention they are already here and Community gets ability to sell support, so that expense seems not so big even more. I suspect knowledgeable and able people are in high demand and more quickly they are re-hired the better for everyone using it. (and won't be hired by some non-illumos related company) They won't pay people doing OmniOS in OmniTI, I bet there is many others that will pay those 2 guys. Plus side is that other companies can provide and sell OmniOS support contracts and even more positive wider community influx seems more then welcome, as I read it. I also read that security and other updates after OmniOS release got to be financially organized in OmniOS support group and pay maintaining people that needs hiring. (so you also can continue having your support contract) > We currently have critical production > systems deployed, systems whose deployment was only approved by management > due to the availability of commercial support (the wisdom of such a > perspective we will not discuss), and this sudden development is potentially > going to leave us in quite a pickle. While I certainly can't dictate to you > how to run your business, it would have been much easier on your customers > had you made this announcement with the release of r151022, and coincided > the end of your support offering with the end of life of this last release. > Which also ideally would have provided time for an omnios community to have > developed and started producing their own releases before the last > officially supported omniti version reached sunset. So aether multiple companies with interest in OmniOS can step up and start accepting contracts for maintain OmniOS for their customers and quickly acquire and hire talents already available, or create a new company/support group that can accept support contracts then. Additional to that solution would be to also to provide additional developer time from the existing staff in companies using OmniOS, so that code is contributed and releases are done by a constant contribution. So companies grow out of "only a customer" role and accept an active role -it becomes product of your company too, if having at least one guy also developing/partially maintain it on the payroll. Second is more like how Openindiana functions and how illumos functions. Company/companies and community members providing infrastructure and build servers, and community including companies employees providing the code and support, build and maintain. From gate03 at landcroft.co.uk Mon Apr 24 08:34:40 2017 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Mon, 24 Apr 2017 18:34:40 +1000 Subject: [OmniOS-discuss] web site seems to attack server internet connection In-Reply-To: <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> References: <20170417164237.7ca61503@kendall> <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> Message-ID: <20170424183440.56d613e7@landcroft.co.uk> This problem remains unresolved and is increasingly baffling. It also occurs on http://www.mensbiz.com.au (SFW, despite the name). I started "snoop -d e1000g0 >snout" just before hitting the 'Checkout Now' button and again it froze up. The file snout doesn't contain anything that looks dodgy to ME (I'm a programmer, not a sysadmin or network person). Just HTTPS, ARP and DNS packets, all as expected. What seems to happen is that e1000g0 goes down entirely so that, as previously mentioned, not even "ping 89.16.167.134" works, but if you Esc on the web page so that it doesn't keep trying to send traffic, after about 45 seconds the interface recovers, by itself. At other times it recovers but the default route is lost from the routing table and I have to add it back in manually. What the two sites have in common is paypal.com, but I have successfully bought via Ebay this week, without incident. I am in Australia. ______________ Michael Mounteney From danmcd at omniti.com Mon Apr 24 14:09:02 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 24 Apr 2017 10:09:02 -0400 Subject: [OmniOS-discuss] web site seems to attack server internet connection In-Reply-To: <20170424183440.56d613e7@landcroft.co.uk> References: <20170417164237.7ca61503@kendall> <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> <20170424183440.56d613e7@landcroft.co.uk> Message-ID: <24BC03B5-1A9F-42E7-9DE1-FA52620AE8EB@omniti.com> > On Apr 24, 2017, at 4:34 AM, Michael Mounteney wrote: > > What seems to happen is that e1000g0 goes down entirely so that, as > previously mentioned, not even "ping 89.16.167.134" works, but if you > Esc on the web page so that it doesn't keep trying to send traffic, > after about 45 seconds the interface recovers, by itself. At other > times it recovers but the default route is lost from the routing table > and I have to add it back in manually. Is e1000g0 manually configured, or configured with DHCP? Dan From danmcd at omniti.com Mon Apr 24 14:09:45 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 24 Apr 2017 10:09:45 -0400 Subject: [OmniOS-discuss] web site seems to attack server internet connection In-Reply-To: <24BC03B5-1A9F-42E7-9DE1-FA52620AE8EB@omniti.com> References: <20170417164237.7ca61503@kendall> <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> <20170424183440.56d613e7@landcroft.co.uk> <24BC03B5-1A9F-42E7-9DE1-FA52620AE8EB@omniti.com> Message-ID: > On Apr 24, 2017, at 10:09 AM, Dan McDonald wrote: > > Is e1000g0 manually configured, or configured with DHCP? I'd also suggest running and capturing the output of: route -n monitor on the zone you have e1000g0 in. Dan From jdg117 at elvis.arl.psu.edu Mon Apr 24 15:27:54 2017 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Mon, 24 Apr 2017 11:27:54 -0400 Subject: [OmniOS-discuss] web site seems to attack server internet connection In-Reply-To: Your message of "Mon, 24 Apr 2017 10:09:02 EDT." <24BC03B5-1A9F-42E7-9DE1-FA52620AE8EB@omniti.com> References: <20170417164237.7ca61503@kendall> <06B9C37A-549D-4D45-9B54-665554793FB3@omniti.com> <20170424183440.56d613e7@landcroft.co.uk> <24BC03B5-1A9F-42E7-9DE1-FA52620AE8EB@omniti.com> Message-ID: <201704241527.v3OFRsfi012953@elvis.arl.psu.edu> Isolate the problem to the OmniOS firewall/NAT by moving the client workstation directly onto the cable modem LAN network and confirming client connectivity. Assuming it works when the OmniOS firewall is removed from the configuration, move the workstation back to the e1000g1 network and capture snoop(1M) on both e1000g0 and e1000g1 along with ipfstat(1M), and ipnat(1M) stats. John groenveld at acm.org From softwareinforjam at gmail.com Tue Apr 25 00:34:22 2017 From: softwareinforjam at gmail.com (Software Information) Date: Mon, 24 Apr 2017 19:34:22 -0500 Subject: [OmniOS-discuss] Interesting Nessus Scan Result In-Reply-To: References: Message-ID: Ok. Figured out what was going on. I had it running in vmware player using nat. I realized when I changed the network interface to bridged, that particular error went away. So I guess it was definitely a false positive. Thanks for the responses though. On Thu, Apr 20, 2017 at 10:11 AM, Andy Fiddaman wrote: > > > On Thu, 20 Apr 2017, Software Information wrote: > > ; Thanks for replying. I used the advanced scan (please see screenshot > below) > ; and just to note also, this showed up after I updated Nessus to version > ; 6.10.4 yesterday and ran the scan again. > > I'm running 6.10.5 here, not sure when that was released. I'll try another > scan with the default advanced settings and see if I can replicate what > you're seeing. > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkateley at kateley.com Tue Apr 25 16:11:22 2017 From: lkateley at kateley.com (Linda Kateley) Date: Tue, 25 Apr 2017 11:11:22 -0500 Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> Message-ID: <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> Robert, After reading everything I can in the last few days.. I have a couple questions which I hope you can answer honestly. This announcement on the heals of a massive change in the freenas community make me wonder if there is any "backroom" pressure coming to companies supporting zfs? The other is ... Is your hosted environment divesting from omnios? If so what os are you going to? As a consultant and supporter of all things openzfs just want to know where the best safest places for my customers. And one short comment.. I have have been watching following you guys for awhile now, and I never knew your hope or wish was for the community to pick up omnios. This surprises me. I am sure they would have if they had known. Thanks for everything you have done for this community Linda K On 4/23/17 3:13 PM, Robert Treat wrote: > Security updates are a little bit trickier than just pulling in > general upstream changes, but I think the ideal scenario would be to > form a group of interested people around the "security at omnios.org" > label which would collaborate on fielding and producing security fixes > for the project. Given we also have critical production systems > running OmniOS (more than most I suspect), we will need to deal with > security and bug fixes regardless, so we're happy to use those efforts > to bootstrap things. > > Robert Treat > > On Fri, Apr 21, 2017 at 3:19 PM, Paul B. Henson wrote: >> As both a home hobbyist user of OmniOS and a paid support user of OmniOS at >> my day job, I'd first like to thank you guys for putting together a great >> operating system that has served me well over the years and I hope will >> continue to do so. >> >> However, I would like to clarify your stance when you say you are >> "suspending active development" and that r151022 will be the "final >> release". Per your historical release cycle: >> >> https://omnios.omniti.com/wiki.php/ReleaseCycle >> >> r151022 was to be an LTS release with security/bug fix support through H1 >> 2020. While there will be no further releases of OmniOS from OmniTI, will >> you continue to back port fixes and fix issues in r151022 through that >> timeline, or will it be released as is and then be up to the as yet >> undeveloped community to do so? We currently have critical production >> systems deployed, systems whose deployment was only approved by management >> due to the availability of commercial support (the wisdom of such a >> perspective we will not discuss), and this sudden development is potentially >> going to leave us in quite a pickle. While I certainly can't dictate to you >> how to run your business, it would have been much easier on your customers >> had you made this announcement with the release of r151022, and coincided >> the end of your support offering with the end of life of this last release. >> Which also ideally would have provided time for an omnios community to have >> developed and started producing their own releases before the last >> officially supported omniti version reached sunset. >> >>> -----Original Message----- >>> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] >>> On Behalf Of Robert Treat >>> Sent: Friday, April 21, 2017 7:07 AM >>> To: omnios-discuss >>> Subject: [OmniOS-discuss] The Future of OmniOS >>> >>> Five years ago, when we first launched OmniOS, we did it out of a >>> direct need to push forward the OpenSolaris ecosystem that we had >>> built into the core of several parts of our business. At the time, the >>> illumos community was still rather new and taking direct control of >>> our path forward was a solid next step; we had already built many of >>> the pieces in-house that we needed to produce a complete operating >>> system distribution, and our experiences with open sourcing software >>> we worked on had been generally very good. >>> >>> While we didn't know quite what the reaction would be, there were two >>> things internally that guided us as long term factors in our decision. >>> First, as we have done for other open source software, we thought it >>> made sense to offer commercial support for OmniOS, but there was no >>> desire to "pivot" OmniTI to be an operating system vendor. We like the >>> world of building and running high-scale software and infrastructure >>> and that's where we wanted to stay. Hand in hand with that was the >>> second idea, that while we felt it was important for us to take the >>> first initial steps, in the long term we really would prefer that >>> OmniOS become an open source project maintained by its community >>> rather than remain as the open source product of a single commercial >>> entity (think Debian vs Red Hat, if that helps). >>> >>> Five years later, we are proud to see that this software has been >>> accepted by a wide group of companies and end users, and we think this >>> has been a boon for the illumos community, who are the shoulders we >>> build upon. When you see companies from all sectors and industry, both >>> small and some orders of magnitude larger, using the technology you >>> put forward to build even further; well, it's great to have an impact. >>> >>> However, even with the success we have had, there is one area we have >>> failed to make progress on, which is the goal of making OmniOS >>> community operated. There are many factors why this hasn't happened, >>> but ultimately in five years of both ups and downs within OmniTI, I am >>> left to conclude that if we are ever to change the nature of OmniOS, >>> we need to take a radical approach. >>> >>> Therefore, going forward, while some of our staff may continue >>> contributing, OmniTI will be suspending active development of OmniOS. >>> Our next release, currently in beta, will become the final release >>> from OmniTI. We are currently going through steps to remove any build >>> dependencies on OmniTI or its infrastructure, and we've made some >>> steps towards determining what potential resources we currently >>> control which could be turned over to an open source community should >>> one emerge; for example, we can continue running OmniOS mailing lists >>> from OmniTI, but would eventually like to see those transitioned to >>> something operated by the community itself. >>> >>> To be clear, our goal is not to abandon OmniOS, but to divest OmniTI >>> from the open source project in order to spur others to participate >>> more. We still run quite a bit of infrastructure on OmniOS and expect >>> to continue contributing, but the current model does not work for >>> OmniTI nor do we believe it is healthy for the OmniOS community as a >>> whole. Could this mean the end of OmniOS? We can't guarantee it won't. >>> For that matter, recent user data shows that a majority of the >>> community still uses OmniOS primarily as a storage solution, not a >>> platform for high-scale web computing (which was our original intent), >>> so even if a community does form, it could move the project in a >>> direction that doesn't align with our needs. If that happens, we feel >>> comfortable knowing there are several other strong illumos based >>> options available. In the end, while this rip-the-band-aid-off >>> approach is not without risk, it is one we feel is necessary. >>> >>> We hope that most folks will respond to this not with fear but with >>> the understanding that there is now an opportunity to build a broader, >>> stronger community, and we look forward to working with others to make >>> that a reality. >>> >>> >>> Robert Treat >>> CEO >>> https://omniti.com >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From tobi at oetiker.ch Tue Apr 25 16:35:43 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Tue, 25 Apr 2017 18:35:43 +0200 (CEST) Subject: [OmniOS-discuss] How much would a professionally maintained OmniOS be worth to you ? (was: Re: The Future of OmniOS) In-Reply-To: <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> Message-ID: <1420297654.366384.1493138143476.JavaMail.zimbra@oetiker.ch> Folks, so if you would rather have someone maintain omnios fulltime than relying on 'the community' todo it for free, now is the time to come forward. Write down a line in our straw poll spreadsheet ... https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0 then we will see quickly in which direction this can go ... And when you write down that number, just think about how much time you save by just going `pkg update` and be done with it ... haven't you grown to love that ? cheers tobi ----- On Apr 25, 2017, at 6:11 PM, Linda Kateley lkateley at kateley.com wrote: > Robert, > > After reading everything I can in the last few days.. I have a couple > questions which I hope you can answer honestly. > > This announcement on the heals of a massive change in the freenas > community make me wonder if there is any "backroom" pressure coming to > companies supporting zfs? > > The other is ... Is your hosted environment divesting from omnios? If so > what os are you going to? > > As a consultant and supporter of all things openzfs just want to know > where the best safest places for my customers. > > And one short comment.. I have have been watching following you guys for > awhile now, and I never knew your hope or wish was for the community to > pick up omnios. This surprises me. I am sure they would have if they had > known. > > Thanks for everything you have done for this community > > Linda K > > > On 4/23/17 3:13 PM, Robert Treat wrote: >> Security updates are a little bit trickier than just pulling in >> general upstream changes, but I think the ideal scenario would be to >> form a group of interested people around the "security at omnios.org" >> label which would collaborate on fielding and producing security fixes >> for the project. Given we also have critical production systems >> running OmniOS (more than most I suspect), we will need to deal with >> security and bug fixes regardless, so we're happy to use those efforts >> to bootstrap things. >> >> Robert Treat >> >> On Fri, Apr 21, 2017 at 3:19 PM, Paul B. Henson wrote: >>> As both a home hobbyist user of OmniOS and a paid support user of OmniOS at >>> my day job, I'd first like to thank you guys for putting together a great >>> operating system that has served me well over the years and I hope will >>> continue to do so. >>> >>> However, I would like to clarify your stance when you say you are >>> "suspending active development" and that r151022 will be the "final >>> release". Per your historical release cycle: >>> >>> https://omnios.omniti.com/wiki.php/ReleaseCycle >>> >>> r151022 was to be an LTS release with security/bug fix support through H1 >>> 2020. While there will be no further releases of OmniOS from OmniTI, will >>> you continue to back port fixes and fix issues in r151022 through that >>> timeline, or will it be released as is and then be up to the as yet >>> undeveloped community to do so? We currently have critical production >>> systems deployed, systems whose deployment was only approved by management >>> due to the availability of commercial support (the wisdom of such a >>> perspective we will not discuss), and this sudden development is potentially >>> going to leave us in quite a pickle. While I certainly can't dictate to you >>> how to run your business, it would have been much easier on your customers >>> had you made this announcement with the release of r151022, and coincided >>> the end of your support offering with the end of life of this last release. >>> Which also ideally would have provided time for an omnios community to have >>> developed and started producing their own releases before the last >>> officially supported omniti version reached sunset. >>> >>>> -----Original Message----- >>>> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] >>>> On Behalf Of Robert Treat >>>> Sent: Friday, April 21, 2017 7:07 AM >>>> To: omnios-discuss >>>> Subject: [OmniOS-discuss] The Future of OmniOS >>>> >>>> Five years ago, when we first launched OmniOS, we did it out of a >>>> direct need to push forward the OpenSolaris ecosystem that we had >>>> built into the core of several parts of our business. At the time, the >>>> illumos community was still rather new and taking direct control of >>>> our path forward was a solid next step; we had already built many of >>>> the pieces in-house that we needed to produce a complete operating >>>> system distribution, and our experiences with open sourcing software >>>> we worked on had been generally very good. >>>> >>>> While we didn't know quite what the reaction would be, there were two >>>> things internally that guided us as long term factors in our decision. >>>> First, as we have done for other open source software, we thought it >>>> made sense to offer commercial support for OmniOS, but there was no >>>> desire to "pivot" OmniTI to be an operating system vendor. We like the >>>> world of building and running high-scale software and infrastructure >>>> and that's where we wanted to stay. Hand in hand with that was the >>>> second idea, that while we felt it was important for us to take the >>>> first initial steps, in the long term we really would prefer that >>>> OmniOS become an open source project maintained by its community >>>> rather than remain as the open source product of a single commercial >>>> entity (think Debian vs Red Hat, if that helps). >>>> >>>> Five years later, we are proud to see that this software has been >>>> accepted by a wide group of companies and end users, and we think this >>>> has been a boon for the illumos community, who are the shoulders we >>>> build upon. When you see companies from all sectors and industry, both >>>> small and some orders of magnitude larger, using the technology you >>>> put forward to build even further; well, it's great to have an impact. >>>> >>>> However, even with the success we have had, there is one area we have >>>> failed to make progress on, which is the goal of making OmniOS >>>> community operated. There are many factors why this hasn't happened, >>>> but ultimately in five years of both ups and downs within OmniTI, I am >>>> left to conclude that if we are ever to change the nature of OmniOS, >>>> we need to take a radical approach. >>>> >>>> Therefore, going forward, while some of our staff may continue >>>> contributing, OmniTI will be suspending active development of OmniOS. >>>> Our next release, currently in beta, will become the final release >>>> from OmniTI. We are currently going through steps to remove any build >>>> dependencies on OmniTI or its infrastructure, and we've made some >>>> steps towards determining what potential resources we currently >>>> control which could be turned over to an open source community should >>>> one emerge; for example, we can continue running OmniOS mailing lists >>>> from OmniTI, but would eventually like to see those transitioned to >>>> something operated by the community itself. >>>> >>>> To be clear, our goal is not to abandon OmniOS, but to divest OmniTI >>>> from the open source project in order to spur others to participate >>>> more. We still run quite a bit of infrastructure on OmniOS and expect >>>> to continue contributing, but the current model does not work for >>>> OmniTI nor do we believe it is healthy for the OmniOS community as a >>>> whole. Could this mean the end of OmniOS? We can't guarantee it won't. >>>> For that matter, recent user data shows that a majority of the >>>> community still uses OmniOS primarily as a storage solution, not a >>>> platform for high-scale web computing (which was our original intent), >>>> so even if a community does form, it could move the project in a >>>> direction that doesn't align with our needs. If that happens, we feel >>>> comfortable knowing there are several other strong illumos based >>>> options available. In the end, while this rip-the-band-aid-off >>>> approach is not without risk, it is one we feel is necessary. >>>> >>>> We hope that most folks will respond to this not with fear but with >>>> the understanding that there is now an opportunity to build a broader, >>>> stronger community, and we look forward to working with others to make >>>> that a reality. >>>> >>>> >>>> Robert Treat >>>> CEO >>>> https://omniti.com >>>> _______________________________________________ >>>> OmniOS-discuss mailing list >>>> OmniOS-discuss at lists.omniti.com >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- 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 Tue Apr 25 16:37:34 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 25 Apr 2017 11:37:34 -0500 (CDT) Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> Message-ID: On Tue, 25 Apr 2017, Linda Kateley wrote: > And one short comment.. I have have been watching following you guys for > awhile now, and I never knew your hope or wish was for the community to pick > up omnios. This surprises me. I am sure they would have if they had known. This was a surprise to me as well since I have not seen any text on the OmniOS web site suggesting a desire that OmniOS be a community project and OmniOS development did not behave as a community project other than its very positive and helpful interfacing with Illumos at large, and encouraging others to build OmniOS from source code. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From mir at miras.org Tue Apr 25 17:06:03 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 25 Apr 2017 19:06:03 +0200 Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> Message-ID: <20170425190603.235f859b@sleipner.datanom.net> On Tue, 25 Apr 2017 11:11:22 -0500 Linda Kateley wrote: > > And one short comment.. I have have been watching following you guys for awhile now, and I never knew your hope or wish was for the community to pick up omnios. This surprises me. I am sure they would have if they had known. > This was not my impression as well. I once presented an idea and a solution. The idea was accepted but the implementation was rewritten from scratch providing no other features than my implementation and to the best of my knowledge more or less identical except for the copyright. -- 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: Either approach may give birth to various sorts of monstrosities. -- Larry Wall in <199710221950.MAA25210 at wall.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From softwareinforjam at gmail.com Tue Apr 25 17:29:58 2017 From: softwareinforjam at gmail.com (Software Information) Date: Tue, 25 Apr 2017 12:29:58 -0500 Subject: [OmniOS-discuss] IPFILTER Rate Limiting Message-ID: Hi All I have been trying to find some ipfilter documentation that will show me how to rate limit to a particular port in OmniOS. I really want to rate limit users logging on using ssh to seriously discourage the brute forcers. I am more used to putting lines like this in pf.conf on a BSD. 1. table persist 2. block in quick from 3. pass in on $interface proto tcp to $interface port 53 flags S/SA keep state \ (max-src-conn-rate 15/5, overload flush) Can anyone show me where some good docs are on how to accomplish this on Omni? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Apr 25 17:41:36 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 25 Apr 2017 13:41:36 -0400 Subject: [OmniOS-discuss] IPFILTER Rate Limiting In-Reply-To: References: Message-ID: Read up on flowadm(1M) - this is a better tool for rate limiting. Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 25, 2017, at 1:29 PM, Software Information wrote: > > Hi All > I have been trying to find some ipfilter documentation that will show me how to rate limit to a particular port in OmniOS. I really want to rate limit users logging on using ssh to seriously discourage the brute forcers. I am more used to putting lines like this in pf.conf on a BSD. > > 1. table persist > > 2. block in quick from > > 3. pass in on $interface proto tcp to $interface port 53 flags S/SA keep state \ > (max-src-conn-rate 15/5, overload flush) > > Can anyone show me where some good docs are on how to accomplish this on Omni? > > Regards > > _______________________________________________ > 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 bstone at aspirinsoftware.com Tue Apr 25 17:52:58 2017 From: bstone at aspirinsoftware.com (Brad Stone) Date: Tue, 25 Apr 2017 10:52:58 -0700 Subject: [OmniOS-discuss] IPFILTER Rate Limiting In-Reply-To: References: Message-ID: I could be wrong, but I think flowadm can control only the priority and max bandwidth for the traffic, not the connection rate. -Brad On Tue, Apr 25, 2017 at 10:41 AM, Dan McDonald wrote: > Read up on flowadm(1M) - this is a better tool for rate limiting. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Apr 25, 2017, at 1:29 PM, Software Information < > softwareinforjam at gmail.com> wrote: > > Hi All > I have been trying to find some ipfilter documentation that will show me > how to rate limit to a particular port in OmniOS. I really want to rate > limit users logging on using ssh to seriously discourage the brute forcers. > I am more used to putting lines like this in pf.conf on a BSD. > > 1. table persist > > > 2. block in quick from > > > 3. pass in on $interface proto tcp to $interface port 53 flags S/SA keep > state \ > (max-src-conn-rate 15/5, overload flush) > > Can anyone show me where some good docs are on how to accomplish this on > Omni? > > Regards > > _______________________________________________ > 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 jdg117 at elvis.arl.psu.edu Tue Apr 25 17:53:21 2017 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Tue, 25 Apr 2017 13:53:21 -0400 Subject: [OmniOS-discuss] IPFILTER Rate Limiting In-Reply-To: Your message of "Tue, 25 Apr 2017 12:29:58 CDT." References: Message-ID: <201704251753.v3PHrL7Q018685@elvis.arl.psu.edu> In message , Software Information writes: >I have been trying to find some ipfilter documentation that will show me >how to rate limit to a particular port in OmniOS. I really want to rate >limit users logging on using ssh to seriously discourage the brute forcers. Fail2Ban to script blacklist entries based on sshd logging: John groenveld at acm.org From doug at will.to Tue Apr 25 18:00:51 2017 From: doug at will.to (Doug Hughes) Date: Tue, 25 Apr 2017 14:00:51 -0400 Subject: [OmniOS-discuss] How much would a professionally maintained OmniOS be worth to you ? In-Reply-To: <1420297654.366384.1493138143476.JavaMail.zimbra@oetiker.ch> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> <1420297654.366384.1493138143476.JavaMail.zimbra@oetiker.ch> Message-ID: <33078a78-012b-33b7-f2ab-3bcd2f129114@will.to> Tobi, this is a great idea but let me request minor clarification. Is that the amount of money that you'd be willing to pay annually for update service, or actual amount paid previously, or something else? It may be worth having 2 columns, 1 for update services and 1 for support? I can see personal (home server) and maybe SOHO only wanting update services without support and be willing to chip something in. On 4/25/2017 12:35 PM, Tobias Oetiker wrote: > Folks, > > so if you would rather have someone maintain omnios fulltime than relying on > 'the community' todo it for free, now is the time to come forward. Write down > a line in our straw poll spreadsheet ... > > https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0 > > then we will see quickly in which direction this can go ... > > And when you write down that number, just think about how much time you save > by just going `pkg update` and be done with it ... haven't you grown to love that ? > > > cheers > tobi > > ----- On Apr 25, 2017, at 6:11 PM, Linda Kateley lkateley at kateley.com wrote: > >> Robert, >> >> After reading everything I can in the last few days.. I have a couple >> questions which I hope you can answer honestly. >> >> This announcement on the heals of a massive change in the freenas >> community make me wonder if there is any "backroom" pressure coming to >> companies supporting zfs? >> >> The other is ... Is your hosted environment divesting from omnios? If so >> what os are you going to? >> >> As a consultant and supporter of all things openzfs just want to know >> where the best safest places for my customers. >> >> And one short comment.. I have have been watching following you guys for >> awhile now, and I never knew your hope or wish was for the community to >> pick up omnios. This surprises me. I am sure they would have if they had >> known. >> >> Thanks for everything you have done for this community >> >> Linda K >> >> >> On 4/23/17 3:13 PM, Robert Treat wrote: >>> Security updates are a little bit trickier than just pulling in >>> general upstream changes, but I think the ideal scenario would be to >>> form a group of interested people around the "security at omnios.org" >>> label which would collaborate on fielding and producing security fixes >>> for the project. Given we also have critical production systems >>> running OmniOS (more than most I suspect), we will need to deal with >>> security and bug fixes regardless, so we're happy to use those efforts >>> to bootstrap things. >>> >>> Robert Treat >>> >>> On Fri, Apr 21, 2017 at 3:19 PM, Paul B. Henson wrote: >>>> As both a home hobbyist user of OmniOS and a paid support user of OmniOS at >>>> my day job, I'd first like to thank you guys for putting together a great >>>> operating system that has served me well over the years and I hope will >>>> continue to do so. >>>> >>>> However, I would like to clarify your stance when you say you are >>>> "suspending active development" and that r151022 will be the "final >>>> release". Per your historical release cycle: >>>> >>>> https://omnios.omniti.com/wiki.php/ReleaseCycle >>>> >>>> r151022 was to be an LTS release with security/bug fix support through H1 >>>> 2020. While there will be no further releases of OmniOS from OmniTI, will >>>> you continue to back port fixes and fix issues in r151022 through that >>>> timeline, or will it be released as is and then be up to the as yet >>>> undeveloped community to do so? We currently have critical production >>>> systems deployed, systems whose deployment was only approved by management >>>> due to the availability of commercial support (the wisdom of such a >>>> perspective we will not discuss), and this sudden development is potentially >>>> going to leave us in quite a pickle. While I certainly can't dictate to you >>>> how to run your business, it would have been much easier on your customers >>>> had you made this announcement with the release of r151022, and coincided >>>> the end of your support offering with the end of life of this last release. >>>> Which also ideally would have provided time for an omnios community to have >>>> developed and started producing their own releases before the last >>>> officially supported omniti version reached sunset. >>>> >>>>> -----Original Message----- >>>>> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] >>>>> On Behalf Of Robert Treat >>>>> Sent: Friday, April 21, 2017 7:07 AM >>>>> To: omnios-discuss >>>>> Subject: [OmniOS-discuss] The Future of OmniOS >>>>> >>>>> Five years ago, when we first launched OmniOS, we did it out of a >>>>> direct need to push forward the OpenSolaris ecosystem that we had >>>>> built into the core of several parts of our business. At the time, the >>>>> illumos community was still rather new and taking direct control of >>>>> our path forward was a solid next step; we had already built many of >>>>> the pieces in-house that we needed to produce a complete operating >>>>> system distribution, and our experiences with open sourcing software >>>>> we worked on had been generally very good. >>>>> >>>>> While we didn't know quite what the reaction would be, there were two >>>>> things internally that guided us as long term factors in our decision. >>>>> First, as we have done for other open source software, we thought it >>>>> made sense to offer commercial support for OmniOS, but there was no >>>>> desire to "pivot" OmniTI to be an operating system vendor. We like the >>>>> world of building and running high-scale software and infrastructure >>>>> and that's where we wanted to stay. Hand in hand with that was the >>>>> second idea, that while we felt it was important for us to take the >>>>> first initial steps, in the long term we really would prefer that >>>>> OmniOS become an open source project maintained by its community >>>>> rather than remain as the open source product of a single commercial >>>>> entity (think Debian vs Red Hat, if that helps). >>>>> >>>>> Five years later, we are proud to see that this software has been >>>>> accepted by a wide group of companies and end users, and we think this >>>>> has been a boon for the illumos community, who are the shoulders we >>>>> build upon. When you see companies from all sectors and industry, both >>>>> small and some orders of magnitude larger, using the technology you >>>>> put forward to build even further; well, it's great to have an impact. >>>>> >>>>> However, even with the success we have had, there is one area we have >>>>> failed to make progress on, which is the goal of making OmniOS >>>>> community operated. There are many factors why this hasn't happened, >>>>> but ultimately in five years of both ups and downs within OmniTI, I am >>>>> left to conclude that if we are ever to change the nature of OmniOS, >>>>> we need to take a radical approach. >>>>> >>>>> Therefore, going forward, while some of our staff may continue >>>>> contributing, OmniTI will be suspending active development of OmniOS. >>>>> Our next release, currently in beta, will become the final release >>>>> from OmniTI. We are currently going through steps to remove any build >>>>> dependencies on OmniTI or its infrastructure, and we've made some >>>>> steps towards determining what potential resources we currently >>>>> control which could be turned over to an open source community should >>>>> one emerge; for example, we can continue running OmniOS mailing lists >>>>> from OmniTI, but would eventually like to see those transitioned to >>>>> something operated by the community itself. >>>>> >>>>> To be clear, our goal is not to abandon OmniOS, but to divest OmniTI >>>>> from the open source project in order to spur others to participate >>>>> more. We still run quite a bit of infrastructure on OmniOS and expect >>>>> to continue contributing, but the current model does not work for >>>>> OmniTI nor do we believe it is healthy for the OmniOS community as a >>>>> whole. Could this mean the end of OmniOS? We can't guarantee it won't. >>>>> For that matter, recent user data shows that a majority of the >>>>> community still uses OmniOS primarily as a storage solution, not a >>>>> platform for high-scale web computing (which was our original intent), >>>>> so even if a community does form, it could move the project in a >>>>> direction that doesn't align with our needs. If that happens, we feel >>>>> comfortable knowing there are several other strong illumos based >>>>> options available. In the end, while this rip-the-band-aid-off >>>>> approach is not without risk, it is one we feel is necessary. >>>>> >>>>> We hope that most folks will respond to this not with fear but with >>>>> the understanding that there is now an opportunity to build a broader, >>>>> stronger community, and we look forward to working with others to make >>>>> that a reality. >>>>> >>>>> >>>>> Robert Treat >>>>> CEO >>>>> https://omniti.com >>>>> _______________________________________________ >>>>> OmniOS-discuss mailing list >>>>> OmniOS-discuss at lists.omniti.com >>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Tue Apr 25 18:39:12 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 25 Apr 2017 14:39:12 -0400 Subject: [OmniOS-discuss] IPFILTER Rate Limiting In-Reply-To: References: Message-ID: <0D855A84-BF23-4A28-AF28-4C4B894A08D7@omniti.com> Sorry, I didn't read deeply enough. flowadm(1M) doesn't use establishment as a flow limiter. I do wonder, though, if you couldn't use ipfilter to label inbound SYN packets with a distinct diffserv number which flowadm CAN use for limiting? Dan Sent from my iPhone (typos, autocorrect, and all) > On Apr 25, 2017, at 1:52 PM, Brad Stone wrote: > > I could be wrong, but I think flowadm can control only the priority and max bandwidth for the traffic, not > the connection rate. From bstone at aspirinsoftware.com Tue Apr 25 22:04:45 2017 From: bstone at aspirinsoftware.com (Brad Stone) Date: Tue, 25 Apr 2017 15:04:45 -0700 Subject: [OmniOS-discuss] IPFILTER Rate Limiting In-Reply-To: <0D855A84-BF23-4A28-AF28-4C4B894A08D7@omniti.com> References: <0D855A84-BF23-4A28-AF28-4C4B894A08D7@omniti.com> Message-ID: flowadm could give lower priority to a particular diffserv, but can't limit to a specific number. ipf supports a limit option, but not the max-per-src option which could be helpful to prevent DoS attacks. On Tue, Apr 25, 2017 at 11:39 AM, Dan McDonald wrote: > Sorry, I didn't read deeply enough. flowadm(1M) doesn't use establishment > as a flow limiter. I do wonder, though, if you couldn't use ipfilter to > label inbound SYN packets with a distinct diffserv number which flowadm CAN > use for limiting? > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > > On Apr 25, 2017, at 1:52 PM, Brad Stone > wrote: > > > > I could be wrong, but I think flowadm can control only the priority and > max bandwidth for the traffic, not > > the connection rate. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozkan.goksu at usishi.com Wed Apr 26 11:13:12 2017 From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=) Date: Wed, 26 Apr 2017 14:13:12 +0300 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation Message-ID: Hello. I habe hp g6 dl380 server. I was using smartos (illumos) on it, without problem. But when i try to install Ominos with usb (using dd-image) Some services not running and im getting installation fails. ScreenShot: [image: Sat?r i?i resim 1] Can you help me please? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sorun.png Type: image/png Size: 59107 bytes Desc: not available URL: From ozkan.goksu at usishi.com Wed Apr 26 11:22:48 2017 From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=) Date: Wed, 26 Apr 2017 14:22:48 +0300 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: Message-ID: I forgot to add services list. [image: Sat?r i?i resim 1] *?zkan G?KSU* | *Tekn. Geli?tirme* | ozkan.goksu at usishi.com C : +90 555 449 88 71 | T : +90 (216) 442 7070 | http://www.usishi.com 2017-04-26 14:13 GMT+03:00 ?zkan G?ksu : > Hello. > I habe hp g6 dl380 server. I was using smartos (illumos) on it, without > problem. > But when i try to install Ominos with usb (using dd-image) Some services > not running and im getting installation fails. > > > ScreenShot: > [image: Sat?r i?i resim 1] > > Can you help me please? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sorun.png Type: image/png Size: 59107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sorun2.png Type: image/png Size: 90125 bytes Desc: not available URL: From alka at hfg-gmuend.de Wed Apr 26 11:40:37 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Wed, 26 Apr 2017 13:40:37 +0200 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: Message-ID: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> propably an USB3 problem (not supported on current stable). - check if your USB stick is inserted in an USB2 port On some motherboards with special USB chipsets you must use an Sata DVD for setup. Another option is OmniOS 151021 or the next 151022 expected next days Gea Am 26.04.2017 um 13:13 schrieb ?zkan G?ksu: > Hello. > I habe hp g6 dl380 server. I was using smartos (illumos) on it, > without problem. > But when i try to install Ominos with usb (using dd-image) Some > services not running and im getting installation fails. > > > ScreenShot: > Sat?r i?i resim 1 > > Can you help me 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 59107 bytes Desc: not available URL: From ozkan.goksu at usishi.com Wed Apr 26 12:38:09 2017 From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=) Date: Wed, 26 Apr 2017 15:38:09 +0300 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: Thank you for response but HP G6 have not USB3 support also i don't use usb3 drive. 2017-04-26 14:40 GMT+03:00 Guenther Alka : > propably an USB3 problem (not supported on current stable). > - check if your USB stick is inserted in an USB2 port > > On some motherboards with special USB chipsets you must use an Sata DVD > for setup. > Another option is OmniOS 151021 or the next 151022 expected next days > > Gea > Am 26.04.2017 um 13:13 schrieb ?zkan G?ksu: > > Hello. > I habe hp g6 dl380 server. I was using smartos (illumos) on it, without > problem. > But when i try to install Ominos with usb (using dd-image) Some services > not running and im getting installation fails. > > > ScreenShot: > [image: Sat?r i?i resim 1] > > Can you help me please? > > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 59107 bytes Desc: not available URL: From ozkan.goksu at usishi.com Wed Apr 26 13:04:29 2017 From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=) Date: Wed, 26 Apr 2017 16:04:29 +0300 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: --On some motherboards with special USB chipsets you must use an Sata DVD for setup. Yes you're right. CD/DVD works. Thank you so much. *?zkan G?KSU* | *Tekn. Geli?tirme* | ozkan.goksu at usishi.com C : +90 555 449 88 71 | T : +90 (216) 442 7070 | http://www.usishi.com 2017-04-26 15:38 GMT+03:00 ?zkan G?ksu : > Thank you for response but HP G6 have not USB3 support also i don't use > usb3 drive. > > > > > 2017-04-26 14:40 GMT+03:00 Guenther Alka : > >> propably an USB3 problem (not supported on current stable). >> - check if your USB stick is inserted in an USB2 port >> >> On some motherboards with special USB chipsets you must use an Sata DVD >> for setup. >> Another option is OmniOS 151021 or the next 151022 expected next days >> >> Gea >> Am 26.04.2017 um 13:13 schrieb ?zkan G?ksu: >> >> Hello. >> I habe hp g6 dl380 server. I was using smartos (illumos) on it, without >> problem. >> But when i try to install Ominos with usb (using dd-image) Some services >> not running and im getting installation fails. >> >> >> ScreenShot: >> [image: Sat?r i?i resim 1] >> >> Can you help me please? >> >> >> >> _______________________________________________ >> 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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 59107 bytes Desc: not available URL: From danmcd at omniti.com Wed Apr 26 14:02:12 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 26 Apr 2017 10:02:12 -0400 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: > On Apr 26, 2017, at 9:04 AM, ?zkan G?ksu wrote: > > Thank you so much. > Glad GEA was able to help. Which OmniOS version were you installing? We've radically changed the installer itself for the current bloody, and the soon-to-be-release r151022. These changes have nothing to do with USB3, but early revisions went into maintenance mode sometimes. Dan From ozkan.goksu at usishi.com Wed Apr 26 14:31:02 2017 From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=) Date: Wed, 26 Apr 2017 17:31:02 +0300 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: I installed omnios-r151020-4151d05. I think you should add next release PKGIN, diskinfo, and maybe more disk utility. I'm tired every release installing these software besides almost everybody needs... I'm very sad about ending. Thank you for your all effort. *?zkan G?KSU* | *Tekn. Geli?tirme* | ozkan.goksu at usishi.com C : +90 555 449 88 71 | T : +90 (216) 442 7070 | http://www.usishi.com 2017-04-26 17:02 GMT+03:00 Dan McDonald : > > > On Apr 26, 2017, at 9:04 AM, ?zkan G?ksu wrote: > > > > Thank you so much. > > > > Glad GEA was able to help. > > Which OmniOS version were you installing? We've radically changed the > installer itself for the current bloody, and the soon-to-be-release > r151022. These changes have nothing to do with USB3, but early revisions > went into maintenance mode sometimes. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Apr 26 14:40:50 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 26 Apr 2017 10:40:50 -0400 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: > On Apr 26, 2017, at 10:31 AM, ?zkan G?ksu wrote: > > I installed omnios-r151020-4151d05. > > I think you should add next release PKGIN, diskinfo, and maybe more disk utility. diskinfo is baked-in to illumos now, and subsequently will be in r151022. The disk-selection of the new installer takes diskinfo(1M) output as its data, e.g. > I'm tired every release installing these software besides almost everybody needs... This falls back to the original OmniOS KYSTY philosophy, which I still agree with, though I understand very much your concern & frustration. After 022, I was hoping to address clearly the problem by proposing a LARGE secondary publisher that would provide the sort of extras you seek. There were questions about its construction and maintenance of course. 024 was going to have an 022-like super-sized 9-ish-month cycle (to get us back on the spring/fall 6-month cadence), which would've been partially used to solve such problems. > I'm very sad about ending. Me too, but that train has left the station (at least w.r.t. OmniTI). It's on the community now. > Thank you for your all effort. It was my pleasure. Dan From bauernfeind at ipk-gatersleben.de Wed Apr 26 15:34:46 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Wed, 26 Apr 2017 15:34:46 +0000 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: Do you used a real DVD or an ISO? For the future you could use the iso mount feature of HP ILOs so you save time to burn the iso and save blank cd/dvd. I see no reason to use a remote console just to insert a physical disk when needed ;-) Jens > -----Original Message----- > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > On Behalf Of Dan McDonald > Sent: Mittwoch, 26. April 2017 16:41 > To: ?zkan G?ksu ; Dan McDonald > > Cc: omnios-discuss > Subject: Re: [OmniOS-discuss] Requesting System Maintenance Mode at > Installation > > > > On Apr 26, 2017, at 10:31 AM, ?zkan G?ksu > wrote: > > > > I installed omnios-r151020-4151d05. > > > > I think you should add next release PKGIN, diskinfo, and maybe more disk > utility. > > diskinfo is baked-in to illumos now, and subsequently will be in r151022. The > disk-selection of the new installer takes diskinfo(1M) output as its data, e.g. > > > I'm tired every release installing these software besides almost everybody > needs... > > This falls back to the original OmniOS KYSTY philosophy, which I still agree > with, though I understand very much your concern & frustration. After 022, I > was hoping to address clearly the problem by proposing a LARGE secondary > publisher that would provide the sort of extras you seek. There were > questions about its construction and maintenance of course. 024 was going > to have an 022-like super-sized 9-ish-month cycle (to get us back on the > spring/fall 6-month cadence), which would've been partially used to solve > such problems. > > > I'm very sad about ending. > > Me too, but that train has left the station (at least w.r.t. OmniTI). It's on the > community now. > > > Thank you for your all effort. > > It was my pleasure. > > Dan > > _______________________________________________ > 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: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From danmcd at omniti.com Wed Apr 26 15:39:16 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 26 Apr 2017 11:39:16 -0400 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: <3A4A1B41-F014-4671-8C2A-C0DEA67F4561@omniti.com> > On Apr 26, 2017, at 11:34 AM, Jens Bauernfeind wrote: > > Do you used a real DVD or an ISO? > For the future you could use the iso mount feature of HP ILOs so you save time to burn the iso and save blank cd/dvd. > I see no reason to use a remote console just to insert a physical disk when needed ;-) Will that work for pre-USB3 ISO images? Dan From ozkan.goksu at usishi.com Wed Apr 26 15:47:04 2017 From: ozkan.goksu at usishi.com (=?UTF-8?B?w5Z6a2FuIEfDtmtzdQ==?=) Date: Wed, 26 Apr 2017 18:47:04 +0300 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: I used real DVD but almost everytime i was using ISO import method from ILO, IDRAC, ETC. First time i tried USB installation and it didnt work. P.S: My usb and my server both USB 2.0 *?zkan G?KSU* | *Tekn. Geli?tirme* | ozkan.goksu at usishi.com C : +90 555 449 88 71 | T : +90 (216) 442 7070 | http://www.usishi.com 2017-04-26 18:34 GMT+03:00 Jens Bauernfeind : > Do you used a real DVD or an ISO? > For the future you could use the iso mount feature of HP ILOs so you save > time to burn the iso and save blank cd/dvd. > I see no reason to use a remote console just to insert a physical disk > when needed ;-) > > Jens > > > -----Original Message----- > > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] > > On Behalf Of Dan McDonald > > Sent: Mittwoch, 26. April 2017 16:41 > > To: ?zkan G?ksu ; Dan McDonald > > > > Cc: omnios-discuss > > Subject: Re: [OmniOS-discuss] Requesting System Maintenance Mode at > > Installation > > > > > > > On Apr 26, 2017, at 10:31 AM, ?zkan G?ksu > > wrote: > > > > > > I installed omnios-r151020-4151d05. > > > > > > I think you should add next release PKGIN, diskinfo, and maybe more > disk > > utility. > > > > diskinfo is baked-in to illumos now, and subsequently will be in > r151022. The > > disk-selection of the new installer takes diskinfo(1M) output as its > data, e.g. > > > > > I'm tired every release installing these software besides almost > everybody > > needs... > > > > This falls back to the original OmniOS KYSTY philosophy, which I still > agree > > with, though I understand very much your concern & frustration. After > 022, I > > was hoping to address clearly the problem by proposing a LARGE secondary > > publisher that would provide the sort of extras you seek. There were > > questions about its construction and maintenance of course. 024 was > going > > to have an 022-like super-sized 9-ish-month cycle (to get us back on the > > spring/fall 6-month cadence), which would've been partially used to solve > > such problems. > > > > > I'm very sad about ending. > > > > Me too, but that train has left the station (at least w.r.t. OmniTI). > It's on the > > community now. > > > > > Thank you for your all effort. > > > > It was my pleasure. > > > > Dan > > > > _______________________________________________ > > 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 bauernfeind at ipk-gatersleben.de Wed Apr 26 15:54:57 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Wed, 26 Apr 2017 15:54:57 +0000 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: <3A4A1B41-F014-4671-8C2A-C0DEA67F4561@omniti.com> References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> <3A4A1B41-F014-4671-8C2A-C0DEA67F4561@omniti.com> Message-ID: It should, as it appears as a normal sata optical device in the server. Jens > -----Original Message----- > From: Dan McDonald [mailto:danmcd at omniti.com] > Sent: Mittwoch, 26. April 2017 17:39 > To: Jens Bauernfeind ; Dan McDonald > > Cc: ?zkan G?ksu ; omnios-discuss discuss at lists.omniti.com> > Subject: Re: [OmniOS-discuss] Requesting System Maintenance Mode at > Installation > > > > On Apr 26, 2017, at 11:34 AM, Jens Bauernfeind gatersleben.de> wrote: > > > > Do you used a real DVD or an ISO? > > For the future you could use the iso mount feature of HP ILOs so you save > time to burn the iso and save blank cd/dvd. > > I see no reason to use a remote console just to insert a physical disk when > needed ;-) > > Will that work for pre-USB3 ISO images? > > Dan -------------- 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 Wed Apr 26 15:57:48 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Wed, 26 Apr 2017 15:57:48 +0000 Subject: [OmniOS-discuss] Requesting System Maintenance Mode at Installation In-Reply-To: References: <17bacc11-c308-e1ea-74c3-adfa26736b75@hfg-gmuend.de> Message-ID: Ok :-) I just want to say that, as I met some people who doesn't know this feature, they just used the KVM part of an ILOM. Jens > -----Original Message----- > From: ?zkan G?ksu [mailto:ozkan.goksu at usishi.com] > Sent: Mittwoch, 26. April 2017 17:47 > To: Jens Bauernfeind > Cc: omnios-discuss > Subject: Re: [OmniOS-discuss] Requesting System Maintenance Mode at > Installation > > I used real DVD but almost everytime i was using ISO import method from > ILO, IDRAC, ETC. > First time i tried USB installation and it didnt work. > P.S: My usb and my server both USB 2.0 > > > ?zkan G?KSU | Tekn. Geli?tirme | ozkan.goksu at usishi.com > > C : +90 555 449 88 71 | T : +90 (216) 442 7070 | http://www.usishi.com > > > > > 2017-04-26 18:34 GMT+03:00 Jens Bauernfeind gatersleben.de >: > > > Do you used a real DVD or an ISO? > For the future you could use the iso mount feature of HP ILOs so you > save time to burn the iso and save blank cd/dvd. > I see no reason to use a remote console just to insert a physical disk > when needed ;-) > > Jens > > > > -----Original Message----- > > From: OmniOS-discuss [mailto:omnios-discuss- > bounces at lists.omniti.com bounces at lists.omniti.com> ] > > On Behalf Of Dan McDonald > > Sent: Mittwoch, 26. April 2017 16:41 > > To: ?zkan G?ksu >; Dan McDonald > > > > > Cc: omnios-discuss > > > Subject: Re: [OmniOS-discuss] Requesting System Maintenance > Mode at > > Installation > > > > > > > On Apr 26, 2017, at 10:31 AM, ?zkan G?ksu > > > > wrote: > > > > > > I installed omnios-r151020-4151d05. > > > > > > I think you should add next release PKGIN, diskinfo, and maybe > more disk > > utility. > > > > diskinfo is baked-in to illumos now, and subsequently will be in > r151022. The > > disk-selection of the new installer takes diskinfo(1M) output as its > data, e.g. > > > > > I'm tired every release installing these software besides almost > everybody > > needs... > > > > This falls back to the original OmniOS KYSTY philosophy, which I still > agree > > with, though I understand very much your concern & frustration. > After 022, I > > was hoping to address clearly the problem by proposing a LARGE > secondary > > publisher that would provide the sort of extras you seek. There > were > > questions about its construction and maintenance of course. 024 > was going > > to have an 022-like super-sized 9-ish-month cycle (to get us back on > the > > spring/fall 6-month cadence), which would've been partially used > to solve > > such problems. > > > > > I'm very sad about ending. > > > > Me too, but that train has left the station (at least w.r.t. OmniTI). > It's on the > > community now. > > > > > Thank you for your all effort. > > > > It was my pleasure. > > > > Dan > > > > > _______________________________________________ > > OmniOS-discuss mailing list > > OmniOS-discuss at lists.omniti.com discuss at lists.omniti.com> > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From skeltonr at btconnect.com Wed Apr 26 16:44:34 2017 From: skeltonr at btconnect.com (Richard Skelton) Date: Wed, 26 Apr 2017 17:44:34 +0100 Subject: [OmniOS-discuss] I am have a problem copying the stable repo Message-ID: <5900CE72.7020401@btconnect.com> Hi, I am have a problem copying the stable repo:-( root at ml110:~# pkgrepo create /rpool/omnios/r151020 root at ml110:~# pkgrecv -s http://pkg.omniti.com/omnios/r151020 -d /rpool/omnios/r151020 -m latest '*' pkgrecv: Framework error: code: E_SSL_CACERT (60) reason: SSL certificate problem: certificate is not yet valid URL: 'http://pkg.omniti.com/omnios/r151020/versions/0/' root at ml110:~# Have done this in the past and worked fine :-) Cheers Richard From bauernfeind at ipk-gatersleben.de Wed Apr 26 17:19:42 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Wed, 26 Apr 2017 17:19:42 +0000 Subject: [OmniOS-discuss] I am have a problem copying the stable repo In-Reply-To: <5900CE72.7020401@btconnect.com> References: <5900CE72.7020401@btconnect.com> Message-ID: <1493227182.4120.1.camel@ipk-gatersleben.de> Hi, i would check the date of your server, maybe a time problem: 8<-- # openssl s_client -showcerts -connect pkg.omniti.com:443 -servername pkg.omniti.com Hi, > I am have a problem copying the stable repo:-( > > root at ml110:~# pkgrepo create /rpool/omnios/r151020 > root at ml110:~# pkgrecv -s http://pkg.omniti.com/omnios/r151020 -d > /rpool/omnios/r151020 -m latest '*' > pkgrecv: Framework error: code: E_SSL_CACERT (60) reason: SSL > certificate problem: certificate is not yet valid > URL: 'http://pkg.omniti.com/omnios/r151020/versions/0/' > > root at ml110:~# > > Have done this in the past and worked fine :-) > > Cheers > Richard > _______________________________________________ > 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: smime.p7s Type: application/x-pkcs7-signature Size: 6399 bytes Desc: not available URL: From danmcd at omniti.com Wed Apr 26 18:37:34 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 26 Apr 2017 14:37:34 -0400 Subject: [OmniOS-discuss] I am have a problem copying the stable repo In-Reply-To: <5900CE72.7020401@btconnect.com> References: <5900CE72.7020401@btconnect.com> Message-ID: <5B9F342C-8CEA-4C12-A13D-3807F8B6BFC3@omniti.com> > On Apr 26, 2017, at 12:44 PM, Richard Skelton wrote: > > Hi, > I am have a problem copying the stable repo:-( > > root at ml110:~# pkgrepo create /rpool/omnios/r151020 > root at ml110:~# pkgrecv -s http://pkg.omniti.com/omnios/r151020 -d > /rpool/omnios/r151020 -m latest '*' > pkgrecv: Framework error: code: E_SSL_CACERT (60) reason: SSL > certificate problem: certificate is not yet valid > URL: 'http://pkg.omniti.com/omnios/r151020/versions/0/' Before you copy, make SURE you're updated to the latest ca-bundle package: r151020(~)[0]% pkg list -v ca-bundle FMRI IFO pkg://omnios/web/ca-bundle at 5.11-0.151020:20170414T020145Z i-- r151020(~)[0]% Dan From skeltonr at btconnect.com Wed Apr 26 18:53:56 2017 From: skeltonr at btconnect.com (Richard Skelton) Date: Wed, 26 Apr 2017 19:53:56 +0100 Subject: [OmniOS-discuss] I am have a problem copying the stable repo In-Reply-To: <1493227182.4120.1.camel@ipk-gatersleben.de> References: <5900CE72.7020401@btconnect.com> <1493227182.4120.1.camel@ipk-gatersleben.de> Message-ID: <5900ECC4.8020902@btconnect.com> Hi Jens, Thanks My time was miles out :-) Jens Bauernfeind wrote: > Hi, > > i would check the date of your server, maybe a time problem: > 8<-- > # openssl s_client -showcerts -connect pkg.omniti.com:443 -servername > pkg.omniti.com depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA > verify return:1 > depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA > verify return:1 > depth=0 CN = pkg.omniti.com > verify return:1 > DONE > notBefore=Apr 26 00:00:00 2016 GMT > notAfter=Apr 26 23:59:59 2019 GMT > 8<--- > > Jens > > On Wed, 2017-04-26 at 17:44 +0100, Richard Skelton wrote: > >> Hi, >> I am have a problem copying the stable repo:-( >> >> root at ml110:~# pkgrepo create /rpool/omnios/r151020 >> root at ml110:~# pkgrecv -s http://pkg.omniti.com/omnios/r151020 -d >> /rpool/omnios/r151020 -m latest '*' >> pkgrecv: Framework error: code: E_SSL_CACERT (60) reason: SSL >> certificate problem: certificate is not yet valid >> URL: 'http://pkg.omniti.com/omnios/r151020/versions/0/' >> >> root at ml110:~# >> >> Have done this in the past and worked fine :-) >> >> Cheers >> Richard >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> From lkateley at kateley.com Wed Apr 26 21:09:56 2017 From: lkateley at kateley.com (Linda Kateley) Date: Wed, 26 Apr 2017 16:09:56 -0500 Subject: [OmniOS-discuss] How much would a professionally maintained OmniOS be worth to you ? In-Reply-To: <1420297654.366384.1493138143476.JavaMail.zimbra@oetiker.ch> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> <1420297654.366384.1493138143476.JavaMail.zimbra@oetiker.ch> Message-ID: <79544d3f-b064-6ff2-5292-7a2f43a01e54@kateley.com> Sorry this is so long...Just some random ramblings.. I will also add, over the years I have had a number of opportunities to sell omni support.. The pricing on it is just way too high. If it were in 500 to 1.5k it would be much easier to advise my customers. Actually for a few of my customers I have told them there is no reason to buy support for omni because Dan is so good at community support. (Sorry Dan) I actually offer openzfs support contracts at 600-2400 depending on size.. support only for zfs.. that seems to be a responsible price for an smb, although they aren't knocking down my door at that price. Every omni zfs install I have worked with has been omni + napp-it. In the last 5 years that has only been a couple dozen. Not sure how many of them ended up buying support In OS support you look at ubuntu(150-1.5k) and rhel are in the sub 1k per server range. When you compare with some of the other openzfs based tools, napp-it is great at like $350, but nexenta, osnexus, cloudbyte, all are priced per raw TB(at least they were last i looked).. And the prices are very high, those products have lots of vc money and tons of marketing/sales available.. cloudbyte was $800 a TB last I looked... You can get oracle solaris for like 1k, but you might as well just take that 1000 out of your wallet and throw it on the ground because they will always blame you for the problem:) The primary value of omni/illumos is the mature fc and iscsi, which should drive higher pricing. You can get nas4free or freenas for $0 with community only support options(except me :)) The numbers for freenas are at about .5 million installed. Problem with both of those is that once you go in you can never come back(no cross platform export/import) The thing I find crazy about these 2 communities is that people are just fine with this level of support. And then there is the thing that always happens when there is a single company/entity driving a project, they can go crazy. For years now I have wanted to start an openzfs users community. My experience is that running zfs it is mostly the same cross platform. The developers have always had a community, but the users are fractured. Developers and end users don't always have the same requirements. The best part of zfs is that once it is setup, it just runs. It looks like datto is trying to do this. With oracle finally shutting down it's zfs-discuss, maybe it's time.. If anyone is interested in helping start an openzfs users group(globally) let me know off list. It still amazes me how little people and even the companies that sell systems running zfs actually know about how to run zfs. I would like to huddle up around one of the distro's. Either omni or OI. I like OI cuz I do like a gui(getting older)...I would have participated in community development around omni if i had known. I also thought OI had died, but I guess I was wrong. Community doesn't ever grow without dollars. Open Stack has always had a foundation and sponsors. Freebsd has a foundation and sponsors.. Sometimes you get lucky and people just do stuff for free., but you always get what you pay for.. Lk On 4/25/17 11:35 AM, Tobias Oetiker wrote: > Folks, > > so if you would rather have someone maintain omnios fulltime than relying on > 'the community' todo it for free, now is the time to come forward. Write down > a line in our straw poll spreadsheet ... > > https://docs.google.com/spreadsheets/d/1IyAI950a-JkPgRRLSezZm9-Rt8HkfO_nIkubd_m8d_0 > > then we will see quickly in which direction this can go ... > > And when you write down that number, just think about how much time you save > by just going `pkg update` and be done with it ... haven't you grown to love that ? > > > cheers > tobi > > ----- On Apr 25, 2017, at 6:11 PM, Linda Kateley lkateley at kateley.com wrote: > >> Robert, >> >> After reading everything I can in the last few days.. I have a couple >> questions which I hope you can answer honestly. >> >> This announcement on the heals of a massive change in the freenas >> community make me wonder if there is any "backroom" pressure coming to >> companies supporting zfs? >> >> The other is ... Is your hosted environment divesting from omnios? If so >> what os are you going to? >> >> As a consultant and supporter of all things openzfs just want to know >> where the best safest places for my customers. >> >> And one short comment.. I have have been watching following you guys for >> awhile now, and I never knew your hope or wish was for the community to >> pick up omnios. This surprises me. I am sure they would have if they had >> known. >> >> Thanks for everything you have done for this community >> >> Linda K >> >> >> On 4/23/17 3:13 PM, Robert Treat wrote: >>> Security updates are a little bit trickier than just pulling in >>> general upstream changes, but I think the ideal scenario would be to >>> form a group of interested people around the "security at omnios.org" >>> label which would collaborate on fielding and producing security fixes >>> for the project. Given we also have critical production systems >>> running OmniOS (more than most I suspect), we will need to deal with >>> security and bug fixes regardless, so we're happy to use those efforts >>> to bootstrap things. >>> >>> Robert Treat >>> >>> On Fri, Apr 21, 2017 at 3:19 PM, Paul B. Henson wrote: >>>> As both a home hobbyist user of OmniOS and a paid support user of OmniOS at >>>> my day job, I'd first like to thank you guys for putting together a great >>>> operating system that has served me well over the years and I hope will >>>> continue to do so. >>>> >>>> However, I would like to clarify your stance when you say you are >>>> "suspending active development" and that r151022 will be the "final >>>> release". Per your historical release cycle: >>>> >>>> https://omnios.omniti.com/wiki.php/ReleaseCycle >>>> >>>> r151022 was to be an LTS release with security/bug fix support through H1 >>>> 2020. While there will be no further releases of OmniOS from OmniTI, will >>>> you continue to back port fixes and fix issues in r151022 through that >>>> timeline, or will it be released as is and then be up to the as yet >>>> undeveloped community to do so? We currently have critical production >>>> systems deployed, systems whose deployment was only approved by management >>>> due to the availability of commercial support (the wisdom of such a >>>> perspective we will not discuss), and this sudden development is potentially >>>> going to leave us in quite a pickle. While I certainly can't dictate to you >>>> how to run your business, it would have been much easier on your customers >>>> had you made this announcement with the release of r151022, and coincided >>>> the end of your support offering with the end of life of this last release. >>>> Which also ideally would have provided time for an omnios community to have >>>> developed and started producing their own releases before the last >>>> officially supported omniti version reached sunset. >>>> >>>>> -----Original Message----- >>>>> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] >>>>> On Behalf Of Robert Treat >>>>> Sent: Friday, April 21, 2017 7:07 AM >>>>> To: omnios-discuss >>>>> Subject: [OmniOS-discuss] The Future of OmniOS >>>>> >>>>> Five years ago, when we first launched OmniOS, we did it out of a >>>>> direct need to push forward the OpenSolaris ecosystem that we had >>>>> built into the core of several parts of our business. At the time, the >>>>> illumos community was still rather new and taking direct control of >>>>> our path forward was a solid next step; we had already built many of >>>>> the pieces in-house that we needed to produce a complete operating >>>>> system distribution, and our experiences with open sourcing software >>>>> we worked on had been generally very good. >>>>> >>>>> While we didn't know quite what the reaction would be, there were two >>>>> things internally that guided us as long term factors in our decision. >>>>> First, as we have done for other open source software, we thought it >>>>> made sense to offer commercial support for OmniOS, but there was no >>>>> desire to "pivot" OmniTI to be an operating system vendor. We like the >>>>> world of building and running high-scale software and infrastructure >>>>> and that's where we wanted to stay. Hand in hand with that was the >>>>> second idea, that while we felt it was important for us to take the >>>>> first initial steps, in the long term we really would prefer that >>>>> OmniOS become an open source project maintained by its community >>>>> rather than remain as the open source product of a single commercial >>>>> entity (think Debian vs Red Hat, if that helps). >>>>> >>>>> Five years later, we are proud to see that this software has been >>>>> accepted by a wide group of companies and end users, and we think this >>>>> has been a boon for the illumos community, who are the shoulders we >>>>> build upon. When you see companies from all sectors and industry, both >>>>> small and some orders of magnitude larger, using the technology you >>>>> put forward to build even further; well, it's great to have an impact. >>>>> >>>>> However, even with the success we have had, there is one area we have >>>>> failed to make progress on, which is the goal of making OmniOS >>>>> community operated. There are many factors why this hasn't happened, >>>>> but ultimately in five years of both ups and downs within OmniTI, I am >>>>> left to conclude that if we are ever to change the nature of OmniOS, >>>>> we need to take a radical approach. >>>>> >>>>> Therefore, going forward, while some of our staff may continue >>>>> contributing, OmniTI will be suspending active development of OmniOS. >>>>> Our next release, currently in beta, will become the final release >>>>> from OmniTI. We are currently going through steps to remove any build >>>>> dependencies on OmniTI or its infrastructure, and we've made some >>>>> steps towards determining what potential resources we currently >>>>> control which could be turned over to an open source community should >>>>> one emerge; for example, we can continue running OmniOS mailing lists >>>>> from OmniTI, but would eventually like to see those transitioned to >>>>> something operated by the community itself. >>>>> >>>>> To be clear, our goal is not to abandon OmniOS, but to divest OmniTI >>>>> from the open source project in order to spur others to participate >>>>> more. We still run quite a bit of infrastructure on OmniOS and expect >>>>> to continue contributing, but the current model does not work for >>>>> OmniTI nor do we believe it is healthy for the OmniOS community as a >>>>> whole. Could this mean the end of OmniOS? We can't guarantee it won't. >>>>> For that matter, recent user data shows that a majority of the >>>>> community still uses OmniOS primarily as a storage solution, not a >>>>> platform for high-scale web computing (which was our original intent), >>>>> so even if a community does form, it could move the project in a >>>>> direction that doesn't align with our needs. If that happens, we feel >>>>> comfortable knowing there are several other strong illumos based >>>>> options available. In the end, while this rip-the-band-aid-off >>>>> approach is not without risk, it is one we feel is necessary. >>>>> >>>>> We hope that most folks will respond to this not with fear but with >>>>> the understanding that there is now an opportunity to build a broader, >>>>> stronger community, and we look forward to working with others to make >>>>> that a reality. >>>>> >>>>> >>>>> Robert Treat >>>>> CEO >>>>> https://omniti.com >>>>> _______________________________________________ >>>>> OmniOS-discuss mailing list >>>>> OmniOS-discuss at lists.omniti.com >>>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From robert at omniti.com Wed Apr 26 23:21:43 2017 From: robert at omniti.com (Robert Treat) Date: Wed, 26 Apr 2017 19:21:43 -0400 Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> Message-ID: On Tue, Apr 25, 2017 at 9:11 AM Linda Kateley wrote: > Robert, > > After reading everything I can in the last few days.. I have a couple > questions which I hope you can answer honestly. > > This announcement on the heals of a massive change in the freenas > community make me wonder if there is any "backroom" pressure coming to > companies supporting zfs? > > Honestly I don't follow the FreeNAS community, so couldn't say much about that other than I know there is some drama going on over there but it has nothing to do with us at OmniTI. The other is ... Is your hosted environment divesting from omnios? If so > what os are you going to? > As a consultant and supporter of all things openzfs just want to know > where the best safest places for my customers. > I hope the answer to the best safest place is OmniOS. To that end, we have no plans to stop running OmniOS at this time, and presuming the project can make the jump to community maintainership, we won't need to develop any. > And one short comment.. I have have been watching following you guys for > awhile now, and I never knew your hope or wish was for the community to > pick up omnios. This surprises me. I am sure they would have if they had > known. > Thanks for everything you have done for this community > Yes, this is clearly our fault, and more specifically mine. We would have conversations internally about certain projects or initiatives that we should do to open things up, but between competing company priorities and the old habits many involved have of living in a Sun/Solaris i.e. Vendor/Customer style relationship, we just never made much headway. I'm sure many would say to give it more time or try harder, but if we are being honest, short of someone showing up with a ginormous check, our priorities aren't going to change. In any case, now people know, so let's see what happens :-) Robert Treat https://omniti.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.tribble at gmail.com Thu Apr 27 20:07:16 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Thu, 27 Apr 2017 21:07:16 +0100 Subject: [OmniOS-discuss] The Future of OmniOS In-Reply-To: References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org> <62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> Message-ID: On Thu, Apr 27, 2017 at 12:21 AM, Robert Treat wrote: > I hope the answer to the best safest place is OmniOS. To that end, we have > no plans to stop running OmniOS at this time, and presuming the project can > make the jump to community maintainership, we won't need to develop any. > So, assuming such a jump were to happen, what are we talking about? (My comments here, btw, are from me as an illumos community member and maintainer of another distro, rather than as an OmniOS customer.) Some items: The OmniOS name/brand The website/wiki The illumos-omnios fork (the code) The github repos (the infrastructure) The pkg repo servers What happens to those? The real question here is whether they stay, with community maintainership, or whether the "new" regime is an independent fork? I would guess the latter to be the safest course. That's assuming a world in which OmniOS-whatever remains as a separate entity, rather than taking the view that you throw it away and replace it with a stable branch of some other distro. I'm not entirely convinced that would (a) actually work, and (b) not compromise the other distro. So that gives you a newly forked project that maintains a distro based on the current OmniOS code (preserving the effort that the likes of Dan have put in to get LX running), pulling in updates from illumos and the other upstreams, with the same sort of release cadence and update approach (so you know you're going to get security updates) we have at the moment. Ignoring the who and how for now, would that be what people actually want? Or are people looking for a different future? My personal (illumos/Tribblix) selfishness here is twofold; first, I want to ensure we keep the current codebase as a going concern (as an unmaintained museum it's not interesting), and secondly an active project shows the health of the illumos ecosystem in a better light. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbs at lean-on.com Sat Apr 29 09:05:47 2017 From: jbs at lean-on.com (=?utf-8?B?SmFrb2IgQi4gU8O4cmVuc2Vu?=) Date: Sat, 29 Apr 2017 09:05:47 +0000 Subject: [OmniOS-discuss] [NEWSENDER] - Re: The Future of OmniOS In-Reply-To: <4e742e86-d21e-4c56-980a-49579ae5ba81@lists.omniti.com> References: <00f001d2bad4$3bfc9dd0$b3f5d970$@acm.org><62387bee-9bb2-0e9e-9656-a8c9a5fc64c9@kateley.com> <4e742e86-d21e-4c56-980a-49579ae5ba81@lists.omniti.com> Message-ID: To whom it may concern I am new in this forum. Jakob Blond-Sorensen, CTO of Lean-On A/S Denmark Lean-On is a many year provider of an entire technology stack for optimized Citrix XenApp and Xendesktop use cases including high end Engineering remote desktop. As part of the Lean-On Application Accelerator Platform ? - we use Illumos as storage provider to the solution. 40G,extreme ZIL, 512+ Gbyte RAM and 40-60 VDEVS of Enterprise SAS SSD The combination of Xendesktop and Illumos has brought us many good use cases ? and happy customers. We are using OmniOS for High End Enterprise customers. We dispatch with just one single customer more data on a daily basis than a large Danish bank. Please see https://www.citrixatleanon.dk/ We have customers still using Nexenta and we have several customers using OmniOs. And we have a rather large Cloud platform in our datacenter based on OmniOS as storage provider. As such - We have a great setup working with HA, OmniOs and Napp-it. We are very sad to see Robert pulling the plug on OmniOs ? and I had hoped that he instead had called for better backup rather than dropping the support OmniOs is a great concept ? and a great platform.. and it?s an anchor used by a lot of the other distris? Some of these has been kind of hanging on the back of OmniOS?. Nice but not fair ! Dan/Robert has been doing a super job over the years ? so the real reason must be around funding for Dan & Co and an irritation of others just using rather than participate financially or code wise. But I am not in Roberts shoes. Yesterday I was approached by GEA from Napp-it. He wanted to be sure that I was aware of the discussion? so he forwarded among others the link to the excel sheet for future funding of Illumos in some form ? OmniOs or a new fork. It made me happy to see that several folks out there is seeking as we a way to continue the life of OmniOS. All of you ? get your funding heart going ! For me ? the obvious way is to have Dan continuing the great work ? that has been going on for the last years. But I am not in his shoes either?and If Dan refuses to do so?who else will take on the job?. Suggestions ? I do not expect this to be a non paid for service. We need to create funding for the right people to secure the releases. Have no doubt ? we would like to see someone to take over the things that Peter Tribble refers to? so that this great OS can grow and become a continued solid alternative to the proprietary stuff out there that we do not like. The faster this process can be executed upon ? the better. Please feel free to contact me ? I believe that if just Robert and a few others would throw some $ into the spreadsheet as well? we will see a funding fit for a solid community where some folks are paid for taking care of QA and Packaging. It might even be that Robert would change his mind ? - and keep the baby. Anyway. I have included a abstract of my mail to Gea of last night To GEA April 27 - 2017 I have just added the amount that we see doable for continued support ? but would like to emphasize that if a strong support can be enabled ? then we are willing to increase our commitment. We are backing up any initiative that will handle a continued package and license like the Current setup including handling and support like Dan/Dale has been doing it for the last several years. We paid last year 10K for licensed support/Illumos releases + 150-200 $ /hour for support in case we had trouble. Our budget for the coming year is 2-3K$ / month + support hours of which we do not use many of. I think we prepaid 10 hours last year ? and used maybe only 5 ? the remaining unused 5 hours is lost. I have suggested Dan to continue the OmniOs distri like today or in any other form that you support as well. For me it is of importance that we have you GEA backing us as well. We expect that 2018- 2019 will raise the monthly amount to around 4-5K$ /month ? maybe more if the setup looks promising. We only use OmniOs for storage ? nothing else. Our wishes are indeed limited ! Some upgrade on ISCSI and configuration support for MPIO NFS for XenServer. Well ? only using OmniOS for Storage is somewhat a shame but that is where we are at the moment. We are truly XenServer people due to us being CITRIX people? Windows App people with great skills in the CITRIX XenApp and XenDesktop world and Microsoft in general. !! So for all sorts of purposes ? yes we will back up a continued OmniOS/OI/GEA/Dan/iLLUMOS or what ever people wants to do? as long as you support it? and that a ready to deploy package, QA is in place I really like what Dan has done ? and I would like to stress that I would like to see him in the game going forward. But at the end of the day - any relative secure setup is fine for us. We are not specialist in OmniOS ? so the ?only? thing we can bring into the discussion is funding? limited but steady funding. Since we have no deep skills in ZFS ? we rather pay the community for that service as long as our customers can get their ISCSI and NFS with the speed of ZIL and ARC/L2ARC. And for anyone who wishes to involve us ? we are: Lean-On A/S Industriparken 4 2750 Ballerup Denmark Jakob Blond-Sorensen, CTO jbs at lean-on.com Mobile +45 22106554 Fra: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] P? vegne af Peter Tribble Sendt: 27. april 2017 22:07 Til: Robert Treat Cc: omnios-discuss Emne: [NEWSENDER] - Re: [OmniOS-discuss] The Future of OmniOS On Thu, Apr 27, 2017 at 12:21 AM, Robert Treat > wrote: I hope the answer to the best safest place is OmniOS. To that end, we have no plans to stop running OmniOS at this time, and presuming the project can make the jump to community maintainership, we won't need to develop any. So, assuming such a jump were to happen, what are we talking about? (My comments here, btw, are from me as an illumos community member and maintainer of another distro, rather than as an OmniOS customer.) Some items: The OmniOS name/brand The website/wiki The illumos-omnios fork (the code) The github repos (the infrastructure) The pkg repo servers What happens to those? The real question here is whether they stay, with community maintainership, or whether the "new" regime is an independent fork? I would guess the latter to be the safest course. That's assuming a world in which OmniOS-whatever remains as a separate entity, rather than taking the view that you throw it away and replace it with a stable branch of some other distro. I'm not entirely convinced that would (a) actually work, and (b) not compromise the other distro. So that gives you a newly forked project that maintains a distro based on the current OmniOS code (preserving the effort that the likes of Dan have put in to get LX running), pulling in updates from illumos and the other upstreams, with the same sort of release cadence and update approach (so you know you're going to get security updates) we have at the moment. Ignoring the who and how for now, would that be what people actually want? Or are people looking for a different future? My personal (illumos/Tribblix) selfishness here is twofold; first, I want to ensure we keep the current codebase as a going concern (as an unmaintained museum it's not interesting), and secondly an active project shows the health of the illumos ecosystem in a better light. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Sat Apr 29 22:13:07 2017 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 29 Apr 2017 18:13:07 -0400 Subject: [OmniOS-discuss] Bloody update Message-ID: This update is almost entirely illumos-omnios driven. uname -v says omnios-master-f88fa452c2, and illumos-omnios from master, commit f88fa452c2, built this release. Some bugfixes include: - Install media were missing the "xhci" USB3 driver. - Two older LX commits that I'd overlooked, involving epoll and inotify. - Some very recent LX bugfixes from Joyent. - Loader bugfixes The new media pointers can be found here: https://omnios.omniti.com/wiki.php/Installation Happy updating! Dan