From stephan.budach at JVM.DE Mon Feb 1 08:29:07 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Mon, 1 Feb 2016 09:29:07 +0100 Subject: [OmniOS-discuss] OmniOS r151016 crashed and rebootet In-Reply-To: <213D3342-ABEA-4AA1-A8B5-773940300451@omniti.com> References: <56771AA6.90501@jvm.de> <213D3342-ABEA-4AA1-A8B5-773940300451@omniti.com> Message-ID: <56AF1753.9090306@jvm.de> Hi Dan, yesterday, I had been struck by the very same fault, at least this is my guess, which caused my system to reboot. This actually happened shortly after I performed some network/MTU reconfiguration on my ixgbe NICs and the assiciated aggregation. I have compared the two fmdump instances and they nearly look like twins: root at nfsvmpool08:/var/crash/unknown# fmdump -Vp -u d02238fa-4892-6c21-cd77-e5e70d20e9b1 TIME UUID SUNW-MSG-ID Jan 31 2016 17:20:33.177419000 d02238fa-4892-6c21-cd77-e5e70d20e9b1 SUNOS-8000-KL TIME CLASS ENA Jan 31 17:20:33.1634 ireport.os.sunos.panic.dump_available 0x0000000000000000 Jan 31 17:17:36.1766 ireport.os.sunos.panic.dump_pending_on_device 0x0000000000000000 nvlist version: 0 version = 0x0 class = list.suspect uuid = d02238fa-4892-6c21-cd77-e5e70d20e9b1 code = SUNOS-8000-KL diag-time = 1454257233 164636 de = fmd:///module/software-diagnosis fault-list-sz = 0x1 fault-list = (array of embedded nvlists) (start fault-list[0]) nvlist version: 0 version = 0x0 class = defect.sunos.kernel.panic certainty = 0x64 asru = sw:///:path=/var/crash/unknown/.d02238fa-4892-6c21-cd77-e5e70d20e9b1 resource = sw:///:path=/var/crash/unknown/.d02238fa-4892-6c21-cd77-e5e70d20e9b1 savecore-succcess = 1 dump-dir = /var/crash/unknown dump-files = vmdump.0 os-instance-uuid = d02238fa-4892-6c21-cd77-e5e70d20e9b1 panicstr = kernel heap corruption detected panicstack = fffffffffba4e8d4 () | genunix:kmem_slab_free+c1 () | genunix:kmem_magazine_destroy+6e () | genunix:kmem_cache_magazine_purge+dc () | genunix:kmem_cache_magazine_resize+40 () | genunix:taskq_thread+2d0 () | unix:thread_start+8 () | crashtime = 1454255408 panic-time = Sun Jan 31 16:50:08 2016 CET (end fault-list[0]) fault-status = 0x1 severity = Major __ttl = 0x1 __tod = 0x56ae3451 0xa9332f8 Last time you mentioned setting kmem_flags=0xf in /etc/system, but you also noted that it would cause a performance impact. Can you judge on that performance impact? Thanks, Stephan From danmcd at omniti.com Mon Feb 1 18:56:37 2016 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 1 Feb 2016 13:56:37 -0500 Subject: [OmniOS-discuss] OmniOS r151016 crashed and rebootet In-Reply-To: <56AF1753.9090306@jvm.de> References: <56771AA6.90501@jvm.de> <213D3342-ABEA-4AA1-A8B5-773940300451@omniti.com> <56AF1753.9090306@jvm.de> Message-ID: kmem_flags = 0xf will noticeably impact your configuration. If you can reproduce this at will with ixgbe changes, though, it will be worth it to see. Dan From miniflowtrader at gmail.com Tue Feb 2 01:01:17 2016 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 1 Feb 2016 20:01:17 -0500 Subject: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter In-Reply-To: References: <2137BF9A-A40B-43D8-81D2-069C09CDB3AB@omniti.com> <56AA860B.8060506@hfg-gmuend.de> <56AB252F.5050302@hfg-gmuend.de> Message-ID: Perhaps it was too good to be true. It seems that one of the parameters is being disregarded for CIFS shares. 1. When the system first starts and I download from my CIFS share, the transfer rates are good, around 95mb/sec. 2. If I restart CIFS the rates are good. 3. If I wait sometime after the restart or the system has been connected for a few hours and I attempt to download the rates are bad, around 20mb/sec! 4. If I run iperf when CIFS rates are bad, my speed is good, over 900megabit. What is going on with CIFS that is causing the client to have slow download speeds? It's like CIFS is forgetting the buffer values because whenever I restart it I am back to good downloads on my client for a brief period. I appreciate any suggestions. On Fri, Jan 29, 2016 at 3:09 PM, Bob Friesenhahn < bfriesen at simple.dallas.tx.us> wrote: > On Fri, 29 Jan 2016, Guenther Alka wrote: > > With the default mtu 1500 you can max out 1G networks but on 10G you are >> limited to about 300-400 MB/s. >> With mtu 9000 that is supported on all of my switches and computers the >> SMB2 limit is near the limit of 10G >> > > Since this topic started about Moca 2.0, its worth mentioning that this > consumer-grade networking technology might not adequately support large > MTUs. A particular Moca 2.0 device might support large MTUs, but this is > likely atypical. > > Hardware that I am working with does support a somewhat elevated MTU (e.g. > 2k) with Moca 2.0 but that is because we wrote code to support it and > tested it between two units of our hardware. With limited interoperability > testing, we have not encountered other Moca 2.0 hardware which supports MTU > over 1500 bytes. > > Bob > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > _______________________________________________ > 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 Thu Feb 4 21:27:31 2016 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 4 Feb 2016 16:27:31 -0500 Subject: [OmniOS-discuss] Updates for Stable (r151016) and LTS (r151014) Message-ID: <1971D4FA-E4A5-4C7E-966F-4BEFD183B5AB@omniti.com> Hello! I've pushed out updates for both install media and on the IPS repos for Stable and LTS. Two things: * ZFS receive now can cope with refquota overages. There's still an issue with creating a new-by-receiving filesystem with a full refquota, but it does not prevent the receive, just makes it noisier (and the new filesystem needs a refquota set). * DTrace has been hardened against some unusual corner cases found during testing. This update will require a reboot. Thanks! Dan From tim at multitalents.net Fri Feb 5 06:05:35 2016 From: tim at multitalents.net (Tim Rice) Date: Thu, 4 Feb 2016 22:05:35 -0800 (PST) Subject: [OmniOS-discuss] Update BIND to 9.10.3-P3? In-Reply-To: References: Message-ID: Hi Dan, On Wed, 20 Jan 2016, Dan McDonald wrote: | | > On Jan 20, 2016, at 11:12 AM, Dan McDonald wrote: | > | > This afternoon, US/Eastern. I just found out about this via you. Usually I find out other ways, but I've been deep in something, and I'm trying not to break my concentration. | | BTW, the bind we ship via the omnios publisher doesn't have named in it, just the client-side. | | Since I said I'd update, however, I will do so, but in the future, remember that the omnios publisher (i.e. what we officially support) doesn't have named in it. | | Dan | I'm curious as to the rationale for not including named. It is hard to imagine a server OS without a name server. Is there something you prefer to use instead? -- Tim Rice Multitalents tim at multitalents.net From bfriesen at simple.dallas.tx.us Fri Feb 5 14:25:09 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 5 Feb 2016 08:25:09 -0600 (CST) Subject: [OmniOS-discuss] Update BIND to 9.10.3-P3? In-Reply-To: References: Message-ID: On Thu, 4 Feb 2016, Tim Rice wrote: > > I'm curious as to the rationale for not including named. It is hard > to imagine a server OS without a name server. Is there something > you prefer to use instead? I was caught unawares by OmniOS not providing named since I saw that it included a 'bind' package and assumed that named (the most significant component of BIND) was included. I use my own private build of BIND in order to obtain named. Regardless, if named is added, it should be via a separate package from the resolver and utilities. 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 Fri Feb 5 15:42:29 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 5 Feb 2016 10:42:29 -0500 Subject: [OmniOS-discuss] Update BIND to 9.10.3-P3? In-Reply-To: References: Message-ID: In the early days of OmniOS, people decided that most built their own version of named, and so it got moved out following the KYSTY principle. Given you can get bind/named from any other number of sources (pkgsrc, ms.omniti.com, sfe, more), I'm not inclined to increase the base's support burden. Dan From hazzino at gmail.com Fri Feb 5 19:08:55 2016 From: hazzino at gmail.com (=?UTF-8?Q?cristian_panci=C3=A0?=) Date: Fri, 5 Feb 2016 20:08:55 +0100 Subject: [OmniOS-discuss] Gimmie a Connection Message-ID: Tried smartOs just as a virtualized SO, i wanna get a step forward.Installed OmniOS, on my Laptop https://www.asus.com/support/Download/3/390/0/2/dQ05pflVfztxEczD/36/ On the chat some friendly guy suggested to put the Vendor and Product info into the file /etc/driver_aliases done at the level of atge, inserted the text, but after the reboot i had a strange error like product not reckognized and card with reciving errors so i could ping or transmit but no way to establish a connection. My questions or request 1 Why the Distro gives install more drivers doesn't work if not why keeping on that option? 2 Has someone a working atge driver to post me no package cause i can't connect to the web and doing a repo on my hard disk is too huge or do you have any idea for a simple one?with tips? 3 I spent 30Euro for a USB3toGigabit ( http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112) presuming it would work but i haven't see any driver around, if yes binary? Now i will appreciate everyone who could help me. thank you PS is vmadm full functional as in smartOS is imgadm present too? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Feb 5 19:14:40 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 5 Feb 2016 14:14:40 -0500 Subject: [OmniOS-discuss] Gimmie a Connection In-Reply-To: References: Message-ID: <14CFA298-5C66-4158-81E7-1457A7C39D61@omniti.com> > On Feb 5, 2016, at 2:08 PM, cristian panci? wrote: > > Tried smartOs just as a virtualized SO, i wanna get a step forward.Installed OmniOS, on my Laptop > > https://www.asus.com/support/Download/3/390/0/2/dQ05pflVfztxEczD/36/ > > On the chat some friendly guy suggested to put the Vendor and Product info into the file /etc/driver_aliases done at the level of atge, inserted the text, but after the reboot i had a strange error like product not reckognized and card with reciving errors so i could ping or transmit but no way to establish a connection. > My questions or request > 1 Why the Distro gives install more drivers doesn't work if not why keeping on that option? > 2 Has someone a working atge driver to post me no package cause i can't connect to the web and doing a repo on my hard disk is too huge or do you have any idea for a simple one?with tips? You should ping illumos (upstream) about atge. I'm not sure which hardware you exactly have, but it's possible upstream illumos will need more atge support than what's there. > 3 I spent 30Euro for a USB3toGigabit (http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112) presuming it would work but i haven't see any driver around, if yes binary? USB3 doesn't work on illumos. You have to stick with USB2. > PS is vmadm full functional as in smartOS is imgadm present too? No. vmadm & imgadm are SmartOS-only. Dan From johan.kragsterman at capvert.se Fri Feb 5 19:43:23 2016 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Fri, 5 Feb 2016 20:43:23 +0100 Subject: [OmniOS-discuss] Ang: Re: Gimmie a Connection In-Reply-To: <14CFA298-5C66-4158-81E7-1457A7C39D61@omniti.com> References: <14CFA298-5C66-4158-81E7-1457A7C39D61@omniti.com>, Message-ID: Hi! -----"OmniOS-discuss" skrev: ----- Till: cristian panci? , Dan McDonald Fr?n: Dan McDonald S?nt av: "OmniOS-discuss" Datum: 2016-02-05 20:15 Kopia: omnios-discuss at lists.omniti.com ?rende: Re: [OmniOS-discuss] Gimmie a Connection > PS is vmadm full functional as in smartOS is imgadm present too? No. ?vmadm & imgadm are SmartOS-only. Dan About vmadm/imgadm: I think you instead should have a look on project FiFo for managing zones(and perhaps VM's?) on OmniOS. Dan, I think you were involved in this? Some more info? /Johan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Fri Feb 5 19:48:18 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 5 Feb 2016 14:48:18 -0500 Subject: [OmniOS-discuss] Ang: Re: Gimmie a Connection In-Reply-To: References: <14CFA298-5C66-4158-81E7-1457A7C39D61@omniti.com> Message-ID: > On Feb 5, 2016, at 2:43 PM, Johan Kragsterman wrote: > > I think you instead should have a look on project FiFo for managing zones(and perhaps VM's?) on OmniOS. > > Dan, I think you were involved in this? Some more info? I helped Heinz a little in his efforts to make FiFo happen for OmniOS. There's one library we need to port from SmartOS (which I have lying in a workspace somewhere), but once that's up, one could just run it. it's also possible that Heinz includes that library for the OmniOS version... I can't remember. Dan From bfriesen at simple.dallas.tx.us Fri Feb 5 20:06:39 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 5 Feb 2016 14:06:39 -0600 (CST) Subject: [OmniOS-discuss] Update BIND to 9.10.3-P3? In-Reply-To: References: Message-ID: On Fri, 5 Feb 2016, Dan McDonald wrote: > In the early days of OmniOS, people decided that most built their own version of named, and so it got moved out following the KYSTY principle. > > Given you can get bind/named from any other number of sources > (pkgsrc, ms.omniti.com, sfe, more), I'm not inclined to increase the > base's support burden. Many/most of these sources may not work properly or as well due to being built against some OmniOS release which does not match the OmniOS release the user is using. The end result is duplicate installed software or conflicting packages. These sources also do not necessarily issue new versions when there is a new release, or security fix, or provide notifications thereof. It would be good to add a list of common services that OmniOS does not include to the OmniOS web page. Otherwise the naive new user may start with the expectation that basic servers like Apache and BIND are included because every other server OS provides these. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From peter.tribble at gmail.com Sat Feb 6 15:27:48 2016 From: peter.tribble at gmail.com (Peter Tribble) Date: Sat, 6 Feb 2016 15:27:48 +0000 Subject: [OmniOS-discuss] Update BIND to 9.10.3-P3? In-Reply-To: References: Message-ID: On Fri, Feb 5, 2016 at 3:42 PM, Dan McDonald wrote: > In the early days of OmniOS, people decided that most built their own > version of named, and so it got moved out following the KYSTY principle. > Well, partly. The way this works for me is that if I'm running a public-facing DNS server then I want to build and configure it myself. If I'm setting a system up with a local caching-only resolver, then I would expect the system to provide me with a copy of named to use. > Given you can get bind/named from any other number of sources (pkgsrc, > ms.omniti.com, sfe, more), I'm not inclined to increase the base's > support burden. Confusion arises because you supply a bind package that isn't really bind. In fact, you're increasing your support burden, and the burden on users, by supplying a partial package - because you have to build some bits you don't ship, so you have to have a custom set of rules to split the files up, which you have to maintain. And users who do use bind have the potential to get confused by some bits being present but not others. Such as supplying rndc, which occasionally trips me up by running the wrong one. I would have thought it would be much easier to simply ship the whole package rather than a subset, but that's just me. (Oh, and I notice that tsig-keygen and its manpage are shipped as dangling links, and you ship the manpage for named-rrchecker when you probably shouldn't.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschauma at netmeister.org Sat Feb 6 18:25:05 2016 From: jschauma at netmeister.org (Jan Schaumann) Date: Sat, 6 Feb 2016 13:25:05 -0500 Subject: [OmniOS-discuss] OmniOS 014 EC2 AMI In-Reply-To: References: Message-ID: <20160206182505.GC4799@netmeister.org> Marissa Murphy wrote: > Just wanted to mention that two new OmniOS r151014 EC2 AMIs have been made > public. They are: > > ami-9fbbfaf5 - OmniOS r151014 LTS running SunSSH (November 12th release) > ami-15bffe7f - OmniOS r151014 LTS running OpenSSH (November 12th release) Would it be possible to have these images print out their ssh hostkey fingerprint to the console? Right now, I don't see a way to verify the fingerprint presented to me by such an instance, requiring TOFU. EC2 instances of some other OS helpfully include the ssh host key fingerprint in their console output, so you can 'aws ec2 get-console-output' and verify the host key fingerprint. -Jan From bfriesen at simple.dallas.tx.us Sun Feb 7 21:03:28 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 7 Feb 2016 15:03:28 -0600 (CST) Subject: [OmniOS-discuss] OmniOS sendmail suitable for Internet mail hub? Message-ID: Perhaps being naive, yesterday I switched my Internet mail server from Solaris 10 to OmniOS r151016, using OmniOS sendmail, self-built Dovecot, self-built bogofilter, and self-built milter-greylist. These components are running in an isolated zone. A self-built BIND named runs in the global zone. While the sendmail version and sendmail features seem to be very similar compared with Solaris 10, I have noticed at least one difference, which was that SMTP does not support user authentication (I saw a post on a Illumos list that Dale Ghent is working to improve this). I have heard from a Comcast user that Comcast refused to send email to me. Sometime later, I did see an email arrive from this user. It is not clear to me if there is a problem on my end. He tells me that he is able to ping the IP address but telnet to port 25 hung forever without any smtp hello string (might be a Comcast filter). I see that TLS is not working/enabled. The feature list and package dependencies suggest that I should be able to get this working. Many suggest using Postfix but I have been using sendmail successfully for many years and have a simple configuration which has been working for me. Are there any known issues with OmniOS sendmail with regards to receipt of messages from the Internet at large? Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From daleg at omniti.com Sun Feb 7 21:23:49 2016 From: daleg at omniti.com (Dale Ghent) Date: Sun, 7 Feb 2016 16:23:49 -0500 Subject: [OmniOS-discuss] OmniOS sendmail suitable for Internet mail hub? In-Reply-To: References: Message-ID: <69F44698-1505-4321-BF7F-B51508B26C64@omniti.com> > On Feb 7, 2016, at 4:03 PM, Bob Friesenhahn wrote: > > Perhaps being naive, yesterday I switched my Internet mail server from Solaris 10 to OmniOS r151016, using OmniOS sendmail, self-built Dovecot, self-built bogofilter, and self-built milter-greylist. These components are running in an isolated zone. A self-built BIND named runs in the global zone. > > While the sendmail version and sendmail features seem to be very similar compared with Solaris 10, I have noticed at least one difference, which was that SMTP does not support user authentication (I saw a post on a Illumos list that Dale Ghent is working to improve this). > > I have heard from a Comcast user that Comcast refused to send email to me. Sometime later, I did see an email arrive from this user. It is not clear to me if there is a problem on my end. He tells me that he is able to ping the IP address but telnet to port 25 hung forever without any smtp hello string (might be a Comcast filter). > > I see that TLS is not working/enabled. The feature list and package dependencies suggest that I should be able to get this working. > > Many suggest using Postfix but I have been using sendmail successfully for many years and have a simple configuration which has been working for me. > > Are there any known issues with OmniOS sendmail with regards to receipt of messages from the Internet at large? Being on comcast's network who, like most consumer ISPs (outside of business accounts) generally block port 25 in and out; which is why if you're sending to a mail server, you should be using the MSP port anyway (port 587) ... but this is something that the stock sendmail in OmniOS, which comes straight out of illumos-gate, doesn't have configured by default. Future plans and thoughts on MTAs in OmniOS specifically: You mentioned my mail, maybe you saw the one last night where I proposed cutting sendmail out of illumos-gate entirely (in due time). Right now my plans are to cease the inclusion and use of illumos-gate's sendmail in OmniOS, and replace it with a small, lightweight MTA called DMA (Dragonfly Mail Agent.) The only thing this will do is send mails to either the local user's spool in /var/mail, or to a remote host via MX record lookup or defined smarthost with TLS/SMTP-AUTH as an option. It also does basic /etc/mail/aliases lookups and a outgoing queuing ability. That's it, and a solution that I believe is suitable for /most/ OmniOS use-cases (ie; 1 of many servers in a datacenter which never accept incoming mail, but may send a lot to somewhere remotely.) This DMA package will be mediated under IPS, and provide the usual /usr/lib/sendmail, /usr/sbin/sendmail, /usr/bin/mailq symlinks to itself. The reason why these links will be mediated is because my plan is to provide a better sendmail, also IPS-mediatetd, than is what on current offer from illumos-gate. This sendmail will continue to have all the SUN_* options enabled in the code, but it being freed from illumos-gate means we can flush out additional features in it and track newer versions faster. Because of the MTA mediation in IPS, one can even implement other MTAs, such as postfix or opensmtpd or ... whatever your heart wants. Sound reasonable? /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bfriesen at simple.dallas.tx.us Sun Feb 7 22:36:49 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 7 Feb 2016 16:36:49 -0600 (CST) Subject: [OmniOS-discuss] OmniOS sendmail suitable for Internet mail hub? In-Reply-To: <69F44698-1505-4321-BF7F-B51508B26C64@omniti.com> References: <69F44698-1505-4321-BF7F-B51508B26C64@omniti.com> Message-ID: On Sun, 7 Feb 2016, Dale Ghent wrote: > Future plans and thoughts on MTAs in OmniOS specifically: > > You mentioned my mail, maybe you saw the one last night where I > proposed cutting sendmail out of illumos-gate entirely (in due > time). Right now my plans are to cease the inclusion and use of > illumos-gate's sendmail in OmniOS, and replace it with a small, > lightweight MTA called DMA (Dragonfly Mail Agent.) The only thing > this will do is send mails to either the local user's spool in > /var/mail, or to a remote host via MX record lookup or defined > smarthost with TLS/SMTP-AUTH as an option. It also does basic > /etc/mail/aliases lookups and a outgoing queuing ability. That's it, > and a solution that I believe is suitable for /most/ OmniOS > use-cases (ie; 1 of many servers in a datacenter which never accept > incoming mail, but may send a lot to somewhere remotely.) The above sounds reasonable. The sendmail rules below are what I am using (for many years) to create a simple forwarding mailer on all but a true 'mailhost': divert(0)dnl VERSIONID(`@(#)simplesystems-subordinate.mc February 1, 2014') OSTYPE(`solaris8')dnl DOMAIN(`solaris-generic')dnl FEATURE(`nullclient', `mailhost$?m.$m$.')dnl LOCAL_NET_CONFIG R$* < @ $* .$m. > $* $#esmtp $@ $2.$m $: $1 < @ $2.$m. > $3 Your approach avoids the nasty mess of sendmail related files (and dependencies), which pollute zones and systems intended only to provide storage access. > This DMA package will be mediated under IPS, and provide the usual > /usr/lib/sendmail, /usr/sbin/sendmail, /usr/bin/mailq symlinks to > itself. The reason why these links will be mediated is because my > plan is to provide a better sendmail, also IPS-mediatetd, than is > what on current offer from illumos-gate. This sendmail will continue > to have all the SUN_* options enabled in the code, but it being > freed from illumos-gate means we can flush out additional features > in it and track newer versions faster. Because of the MTA mediation > in IPS, one can even implement other MTAs, such as postfix or > opensmtpd or ... whatever your heart wants. > > Sound reasonable? Your approach sounds reasonable as long as the larger improved sendmail is available (as an OmniOS package) to optionally install in place of the tiny MTA. The tiny MTA should be the default. Many of us have working sendmail setups and want to avoid the time and risk of needing to compile a sendmail package for ourselves or switch to a different mail system, even if the different mail system does not require 1200 pages to describe it. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From jdg117 at elvis.arl.psu.edu Sun Feb 7 22:48:47 2016 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Sun, 07 Feb 2016 17:48:47 -0500 Subject: [OmniOS-discuss] OmniOS sendmail suitable for Internet mail hub? In-Reply-To: Your message of "Sun, 07 Feb 2016 16:23:49 EST." <69F44698-1505-4321-BF7F-B51508B26C64@omniti.com> References: <69F44698-1505-4321-BF7F-B51508B26C64@omniti.com> Message-ID: <201602072248.u17MmlNt022435@elvis.arl.psu.edu> In message <69F44698-1505-4321-BF7F-B51508B26C64 at omniti.com>, Dale Ghent writes : >Being on comcast's network who, like most consumer ISPs (outside of = >business accounts) generally block port 25 in and out; which is why if = >you're sending to a mail server, you should be using the MSP port anyway = >(port 587) ... but this is something that the stock sendmail in OmniOS, = >which comes straight out of illumos-gate, doesn't have configured by = >default. Great to read about nanny-grade ISPs who offer nanny-grade supervision of their customers. >Future plans and thoughts on MTAs in OmniOS specifically: > >You mentioned my mail, maybe you saw the one last night where I proposed = >cutting sendmail out of illumos-gate entirely (in due time). Right now = >my plans are to cease the inclusion and use of illumos-gate's sendmail = >in OmniOS, and replace it with a small, lightweight MTA called DMA = >(Dragonfly Mail Agent.) The only thing this will do is send mails to = >either the local user's spool in /var/mail, or to a remote host via MX = >record lookup or defined smarthost with TLS/SMTP-AUTH as an option. It = >also does basic /etc/mail/aliases lookups and a outgoing queuing = >ability. That's it, and a solution that I believe is suitable for /most/ = >OmniOS use-cases (ie; 1 of many servers in a datacenter which never = >accept incoming mail, but may send a lot to somewhere remotely.) I'm all in favor of OmniOS and other Illumos-based distros using smartly designed and implemented *BSD bits (Oracle is wisely migrating from Darren Reed's IPF to OpenBSD PF for Solaris), but how is DMA more secure than sendmail configured to only listen on localhost? >This DMA package will be mediated under IPS, and provide the usual = >/usr/lib/sendmail, /usr/sbin/sendmail, /usr/bin/mailq symlinks to = >itself. The reason why these links will be mediated is because my plan = >is to provide a better sendmail, also IPS-mediatetd, than is what on = >current offer from illumos-gate. This sendmail will continue to have all = >the SUN_* options enabled in the code, but it being freed from = >illumos-gate means we can flush out additional features in it and track = >newer versions faster. Because of the MTA mediation in IPS, one can even = >implement other MTAs, such as postfix or opensmtpd or ... whatever your = >heart wants. That works for me. Keep up the great work, OmniTI! John groenveld at acm.org From daleg at omniti.com Mon Feb 8 00:10:45 2016 From: daleg at omniti.com (Dale Ghent) Date: Sun, 7 Feb 2016 19:10:45 -0500 Subject: [OmniOS-discuss] OmniOS sendmail suitable for Internet mail hub? In-Reply-To: <201602072248.u17MmlNt022435@elvis.arl.psu.edu> References: <69F44698-1505-4321-BF7F-B51508B26C64@omniti.com> <201602072248.u17MmlNt022435@elvis.arl.psu.edu> Message-ID: <11CDB824-E0E8-4BD3-93BD-225AD584A498@omniti.com> > On Feb 7, 2016, at 5:48 PM, John D Groenveld wrote: > > I'm all in favor of OmniOS and other Illumos-based distros using > smartly designed and implemented *BSD bits (Oracle is wisely migrating > from Darren Reed's IPF to OpenBSD PF for Solaris), but how is DMA > more secure than sendmail configured to only listen on localhost? Sendmail itself never claims to be secure in any form, and thinking that it is "more secure" in any quantifiable way than any other given MTA is a fallacy, in my opinion. On any given day, there's the chance that one can wake up to find a fresh CVE for sendmail, DMA, or any other piece of software for that matter in their inbox. We even find that in pieces of software where security is a foremost principle - take OpenSSH for example. S*** happens, as they say. So while sendmail might be used widely enough to - in theory - afford it more scrutiny as to the efficacy of its code, the fact of the matter remains that it makes no such claims and it being the subject of a new CVE on a random, future day is still very much a possibility. Regarding OmniOS, the goal with DMA is to provide not so much a "more secure" MTA in a out-of-the-box OmniOS installation, but rather a far more simple and staight-forward one to handle. For the vast majority of situations where OmniOS (or any other general-purpose service/server OS) is employed, these boxes don't act as email endpoints. They're web servers, storage servers, dev boxes, database servers... if they have anything to do with email, it's only to emit it, either into a local user's spool, or immediately passed on up to a smarthost or otherwise proper mail server. In these cases, even a sendmail that's running in Submission Agent mode is a tad too much, and (in my own opinion) it has always seemed like a role that it was shoehorned into rather than something it accomplishes elegantly by design. That said, when the requirements surpass DMA's capabilities (as they do - personally, I run my own mail server with mailman lists, cyrus-imap, and a long list of various milters to host mail for various friends and family - a real menagerie of SMTP software), OmniOS *has* to make it easy/easier to replace DMA with a more capable MTA such as sendmail, postfix, or whathaveyou. This is where we take advantage of IPS's package mediation capabilities, and as such gives us the ability to also continue to ship (a better) sendmail so that it may be employed in those instances without making users gnash their teeth while attempting strange acrobatics around package uninstallation/reinstalls just to get what they need on-disk. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From danmcd at omniti.com Mon Feb 8 16:03:55 2016 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 8 Feb 2016 11:03:55 -0500 Subject: [OmniOS-discuss] Update BIND to 9.10.3-P3? In-Reply-To: References: Message-ID: <6F7B38A1-71ED-4E01-84DE-B1747AB5F4B3@omniti.com> > On Feb 6, 2016, at 10:27 AM, Peter Tribble wrote: > > (Oh, and I notice that tsig-keygen and its manpage are shipped as dangling links, > and you ship the manpage for named-rrchecker when you probably shouldn't.) The former (tsig-keygen) is fixed in bloody: commit 3e0211127392224c7e15cbcd0abbdc3115fbe527 Author: Dale Ghent Date: Tue Dec 1 00:14:17 2015 -0500 bind: catman complains about missing man page file due to dangling symlink We drop /usr/share/man/man8/ddns-confgen.8 but /usr/share/man/man8/tsig-keygen.8 is created as a symlink to it. The result is a dangling symlink. So we need to drop the tsig-keygen.8 man page as well. And I'm fixing the named-rrchecker as well. Thanks, Dan From chip at innovates.com Wed Feb 10 16:26:54 2016 From: chip at innovates.com (Schweiss, Chip) Date: Wed, 10 Feb 2016 10:26:54 -0600 Subject: [OmniOS-discuss] Updating to r15016 Message-ID: I'm updating one of my systems to r151016. When I use: /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 I get: pkg update: 'entire at 11,5.11-0.151016' matches no installed packages I'm ignorant of what the entire@ portion does as I've been script kidding my way through upgrades. Can someone explain what this is supposed to be? Thanks! -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Wed Feb 10 16:43:03 2016 From: vab at bb-c.de (Volker A. Brandt) Date: Wed, 10 Feb 2016 17:43:03 +0100 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: References: Message-ID: <22203.26775.972128.906616@glaurung.bb-c.de> Schweiss, Chip writes: > I'm updating one of my systems to r151016. When I use: > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 > > I get: > pkg update: 'entire at 11,5.11-0.151016' matches no installed packages ...which tells you that no package named "entire at 11,5.11-0.151016" exists. Where did you get that command line from? :-) The current version is entire at 11-0.151016:20151202T161203Z, but "pkg update" will figure that out by itself, so just omit the package. Do a dry run to see what will happen by running pkg update -n -v --be-name=omnios-r151016 Make sure that you have the publisher set correctly. If you don't have a local repository, it should point to: http://pkg.omniti.com/omnios/r151016/ When you are happy with the results, leave out the "-n" parameter. HTH! 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 daleg at omniti.com Wed Feb 10 17:19:47 2016 From: daleg at omniti.com (Dale Ghent) Date: Wed, 10 Feb 2016 12:19:47 -0500 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: References: Message-ID: > On Feb 10, 2016, at 11:26 AM, Schweiss, Chip wrote: > > I'm updating one of my systems to r151016. When I use: > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 > > I get: > pkg update: 'entire at 11,5.11-0.151016' matches no installed packages > > I'm ignorant of what the entire@ portion does as I've been script kidding my way through upgrades. Can someone explain what this is supposed to be? Did you change your omnios repo to the one for r151016? Different versions of OmniOS reside in their own repos now, so first you must switch the omnios publisher, then you can just run 'pkg upgrade' pkg set-publisher -G http://pkg.omniti.com/omnios/r151014/ -g http://pkg.omniti.com/omnios/r151016/ omnios pkg update -v /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chip at innovates.com Wed Feb 10 17:22:08 2016 From: chip at innovates.com (Schweiss, Chip) Date: Wed, 10 Feb 2016 11:22:08 -0600 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: References: Message-ID: On Wed, Feb 10, 2016 at 11:19 AM, Dale Ghent wrote: > > > On Feb 10, 2016, at 11:26 AM, Schweiss, Chip wrote: > > > > I'm updating one of my systems to r151016. When I use: > > > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 > > > > I get: > > pkg update: 'entire at 11,5.11-0.151016' matches no installed packages > > > > I'm ignorant of what the entire@ portion does as I've been script > kidding my way through upgrades. Can someone explain what this is > supposed to be? > > Did you change your omnios repo to the one for r151016? Different versions > of OmniOS reside in their own repos now, so first you must switch the > omnios publisher, then you can just run 'pkg upgrade' > Yes. That was my first step. Been through this many times on OmniOS, but this time the entire@ seems to be cause a problem and I'm not clear why. -Chip > > pkg set-publisher -G http://pkg.omniti.com/omnios/r151014/ -g > http://pkg.omniti.com/omnios/r151016/ omnios > pkg update -v > > /dale > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffpc at josefsipek.net Wed Feb 10 17:57:55 2016 From: jeffpc at josefsipek.net (Josef 'Jeff' Sipek) Date: Wed, 10 Feb 2016 12:57:55 -0500 Subject: [OmniOS-discuss] pkg.depot leaves trash in /tmp Message-ID: <20160210175754.GA1458@meili.valhalla.31bits.net> It looks like every time I restart one of my pkg.depot services (via SMF of course) it leaves an empty tmp dir in /tmp. E.g., currently I have: root at pkg:/root# ls /tmp/ jam56725b1b.000 tmp5iDpG8 tmpIo_2sK tmpPHwxZq tmp_BxvKY tmpczrTLp tmphSuu64 tmpqmn5U1 tmpvtu316 jam56725b1c.000 tmp9HBNSq tmpItXZJG tmpPg1uCe tmp_dgRyo tmpd3G9Ig tmpkmyfin tmprYp7w8 tmpySkpaw jam56725b1d.000 tmpA9iuu9 tmpJRKIpV tmpQHghRG tmpa6uWks tmpd6YxZq tmplzKPzY tmpsWzIgs tmpzadiAf screens tmpAoCZ2V tmpLB0kvW tmpV2qCK0 tmpaplUoo tmpeVifyW tmpneFKh_ tmpslF8tC tmp0gvvKf tmpEsje8p tmpLo0DtX tmpVDRHZ2 tmpaqLWSe tmpekH4qZ tmpo1aPMW tmpt7Ucwe tmp1ZrOC5 tmpFztsMb tmpMeOoTb tmpXXQU7B tmpbnHKKr tmpfi02rF tmpo7vEWI tmpt_15kP tmp3LrDfB tmpG0u0U4 tmpNRp5gs tmpXa2l5Z tmpboqm_o tmpgGWPdL tmpofQC_p tmpvHSd0v tmp4vXC5M tmpH9j286 tmpNYOs87 tmpZtAcH0 tmpciYGBk tmph292N2 tmpqfz2HY tmpvmAscD Since they are just empty dirs, it's just annoying and unexpected. (Instead of actually taking up valuable /tmp space.) Given that my best python still looks like C, I'm staying away from the pkg source code and just mentioning it here. Thanks, Jeff. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds From danmcd at omniti.com Wed Feb 10 19:11:23 2016 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 10 Feb 2016 14:11:23 -0500 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: References: Message-ID: <85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com> > On Feb 10, 2016, at 11:26 AM, Schweiss, Chip wrote: > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 Lose the "5."... r151016(~)[0]% pkg list -v entire FMRI IFO pkg://omnios/entire at 11-0.151016:20151202T161203Z i-- r151016(~)[0]% Do we need to update a wiki page about that? Also, you could just specify "entire" if the publisher's set right. Dan From lotheac at iki.fi Wed Feb 10 19:25:04 2016 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 10 Feb 2016 21:25:04 +0200 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: References: Message-ID: <20160210192504.GB22542@kekkonen.niksula.hut.fi> On Wed, Feb 10 2016 10:26:54 -0600, Schweiss, Chip wrote: > I'm updating one of my systems to r151016. When I use: > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 > > I get: > pkg update: 'entire at 11,5.11-0.151016' matches no installed packages Is 'entire' installed? 'pkg install entire' before trying to update it. -- Lauri Tirkkonen | lotheac @ IRCnet From chip at innovates.com Wed Feb 10 20:12:16 2016 From: chip at innovates.com (Schweiss, Chip) Date: Wed, 10 Feb 2016 14:12:16 -0600 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: <85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com> References: <85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com> Message-ID: On Wed, Feb 10, 2016 at 1:11 PM, Dan McDonald wrote: > > > On Feb 10, 2016, at 11:26 AM, Schweiss, Chip wrote: > > > > /usr/bin/pkg update --be-name=omnios-r151016 entire at 11,5.11-0.151016 > > Lose the "5."... > > r151016(~)[0]% pkg list -v entire > FMRI > IFO > pkg://omnios/entire at 11-0.151016:20151202T161203Z > i-- > r151016(~)[0]% > > Do we need to update a wiki page about that? > Possibly. I may be the odd user who doesn't understand what 'entire' on the update is doing or how to correct it when my syntax is wrong. > > Also, you could just specify "entire" if the publisher's set right. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Wed Feb 10 20:24:30 2016 From: mir at miras.org (Michael Rasmussen) Date: Wed, 10 Feb 2016 21:24:30 +0100 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: References: <85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com> Message-ID: <20160210212430.70e1a582@sleipner.datanom.net> On Wed, 10 Feb 2016 14:12:16 -0600 "Schweiss, Chip" wrote: > > Possibly. I may be the odd user who doesn't understand what 'entire' on > the update is doing or how to correct it when my syntax is wrong. > My understanding of entire is that of a meta package which controls a specific version of Omnios. You can compare it to a git branch, a zfs snapshot, or a materialized view in a database. -- 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: Would it help if I got out and pushed? -- Princess Leia Organa -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Wed Feb 10 20:44:04 2016 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 10 Feb 2016 15:44:04 -0500 Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: <20160210212430.70e1a582@sleipner.datanom.net> References: <85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com> <20160210212430.70e1a582@sleipner.datanom.net> Message-ID: <4924FFD4-666E-4B0A-A467-DFDF1CB6AAD5@omniti.com> > On Feb 10, 2016, at 3:24 PM, Michael Rasmussen wrote: > > On Wed, 10 Feb 2016 14:12:16 -0600 > "Schweiss, Chip" wrote: > >> >> Possibly. I may be the odd user who doesn't understand what 'entire' on >> the update is doing or how to correct it when my syntax is wrong. >> > My understanding of entire is that of a meta package which controls a > specific version of Omnios. You can compare it to a git branch, a zfs > snapshot, or a materialized view in a database. It needs more than a bit of fixing. For now, it includes way too many dependencies, and blocks unnecessary bits from being uninstallable. Its history predates my arrival at OmniTI, never mind my familiarity with pkg(5) (which took me a bit). Can't make promises, but reforming what "entire" and some of the other metapackages are is something on people's radars. For example, I hope that the "illumos-tools" metapackage is a better example of how to do things right. Dan From bfriesen at simple.dallas.tx.us Wed Feb 10 21:05:55 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 10 Feb 2016 15:05:55 -0600 (CST) Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: <20160210212430.70e1a582@sleipner.datanom.net> References: <85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com> <20160210212430.70e1a582@sleipner.datanom.net> Message-ID: On Wed, 10 Feb 2016, Michael Rasmussen wrote: > My understanding of entire is that of a meta package which controls a > specific version of Omnios. You can compare it to a git branch, a zfs > snapshot, or a materialized view in a database. The 'entire' package is what makes your zones unexpectedly large. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From bfriesen at simple.dallas.tx.us Wed Feb 10 21:21:24 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 10 Feb 2016 15:21:24 -0600 (CST) Subject: [OmniOS-discuss] Updating to r15016 In-Reply-To: References: Message-ID: On Wed, 10 Feb 2016, Schweiss, Chip wrote: > I'm updating one of my systems to r151016.?? When I use: Take care about updating to r151016 if you are using zones that need to preserve state when shut down (like a database) since there is a spurious issue with using 'zoneadm -z foo shutdown'. Sometimes the zone shutdown hangs. Presumably this could cause a database to be corrupted or lose recent updates. Otherwise I have been happy with r151016. 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 Thu Feb 11 20:19:34 2016 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 11 Feb 2016 15:19:34 -0500 Subject: [OmniOS-discuss] "pkg update" NOW for KVM security fixes! References: Message-ID: Pardon the top-post folks. If you're running KVM, ESPECIALLY if it's in your global zone, you should update your KVM packages now. As Joshua from Joyent points out below, there are several CVEs that are addressed with this update. Thanks to Joshua for putting these to bed quickly. "pkg update" is your friend for LTS (r151014) and Stable (r151016). My own r151014 build machine has a KVM-in-a-zone instance (running OpenIndiana), which seems to work just fine after this update. If you're not running KVM on OmniOS, don't sweat this. If you're running KVM on Bloody, expect this as part of a larger update to bloody tonight or tomorrow. Thanks, Dan > Begin forwarded message: > > From: "Joshua M. Clulow" > Subject: [HEADS-UP] QEMU CVE fixes have been put back (was: [USN-2891-1] QEMU vulnerabilities) > Date: February 11, 2016 at 2:50:25 PM EST > To: Dan McDonald > Cc: Robert Mustacchi > > Hi Dan, > I have pushed fixes for the five applicable CVEs. The SmartOS tickets are: > > https://smartos.org/bugview/HVM-841 (CVE-2015-8504) > https://smartos.org/bugview/HVM-842 (CVE-2015-8550) > https://smartos.org/bugview/HVM-843 (CVE-2015-8743) > https://smartos.org/bugview/HVM-844 (CVE-2016-1714) > https://smartos.org/bugview/HVM-845 (CVE-2016-1981) > > The changes are all in the "master" branch of "kvm-cmd.git". I have > done a build, and some basic testing of the "e1000" NIC emulation and > the VNC emulated display driver. > > > Cheers. > > -- > Joshua M. Clulow > Software Engineer @ Joyent > mail: jmc at joyent.com From mir at miras.org Fri Feb 12 00:30:36 2016 From: mir at miras.org (Michael Rasmussen) Date: Fri, 12 Feb 2016 01:30:36 +0100 Subject: [OmniOS-discuss] Intel Skylake Message-ID: <20160212013036.75101f6c@sleipner.datanom.net> Hi all, Does Omnios 151014 support intel skylake? -- 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: If a camel is a horse designed by a committee, then a consensus forecast is a camel's behind. -- Edgar R. Fiedler -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Fri Feb 12 14:56:30 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 12 Feb 2016 09:56:30 -0500 Subject: [OmniOS-discuss] Intel Skylake In-Reply-To: <20160212013036.75101f6c@sleipner.datanom.net> References: <20160212013036.75101f6c@sleipner.datanom.net> Message-ID: <51E77128-CC3C-471E-AF04-61735A63E508@omniti.com> > On Feb 11, 2016, at 7:30 PM, Michael Rasmussen wrote: > > Hi all, > > Does Omnios 151014 support intel skylake? I know it boots and runs on new Xeon-D chips (though it does not yet support those chips' X550 10GigE). I *suspect* the answer is yes, but I have no Skylake machines handy to confirm/deny for certain. Dan From lists at marzocchi.net Fri Feb 12 15:06:51 2016 From: lists at marzocchi.net (Olaf Marzocchi) Date: Fri, 12 Feb 2016 16:06:51 +0100 Subject: [OmniOS-discuss] Intel Skylake In-Reply-To: <51E77128-CC3C-471E-AF04-61735A63E508@omniti.com> References: <20160212013036.75101f6c@sleipner.datanom.net> <51E77128-CC3C-471E-AF04-61735A63E508@omniti.com> Message-ID: <0650CB46-69A1-44C4-AA66-128AEFB5CBB4@marzocchi.net> Well x86 and x86_64 are backward compatible, they should always work with older version of the operating system, as long as the devices are compatible with the drivers provided. I guess you would have no problems running even XP on it... No additional specific feature of Skylake will however be available, like the advanced power saving and processor-managed speedstep. http://www.anandtech.com/show/9751/examining-intel-skylake-speed-shift-more-responsive-processors Olaf Il 12 febbraio 2016 15:56:30 CET, Dan McDonald ha scritto: > >> On Feb 11, 2016, at 7:30 PM, Michael Rasmussen wrote: >> >> Hi all, >> >> Does Omnios 151014 support intel skylake? > >I know it boots and runs on new Xeon-D chips (though it does not yet >support those chips' X550 10GigE). > >I *suspect* the answer is yes, but I have no Skylake machines handy to >confirm/deny for certain. > >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 Fri Feb 12 22:22:59 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 12 Feb 2016 17:22:59 -0500 Subject: [OmniOS-discuss] New bloody (IPS only this time) Message-ID: Based on illumos-omnios master commit cc70d5b, uname -v reports "omnios-cc70d5b". And omnios-build master commit 45f0d7b. New with this update: - Case-sensitivity now in ZFS test suite. - GLDv3 improvement (by OmniTI's own Dale Ghent) which should produce less confusing dladm(1M) output. - SunSSH and sudo now honor the illumos-bug-6057 ways of doing things. Please PLEASE look for other "last login" weirdness, but there shouldn't be any. If there is, PLEASE report it to this list ASAP. - Speaking of SSH, OpenSSH now includes the full wad of Joyent work (modulo 1-2 small differences) to be more of a SunSSH replacement. If you haven't tried OpenSSH because you needed something from SunSSH, PLEASE try it now. There is no new release media for this update, but I did update all of the packages, so you'll need to create a new BE and reboot. Thanks, Dan From mailinglists at qutic.com Sat Feb 13 11:45:12 2016 From: mailinglists at qutic.com (qutic development) Date: Sat, 13 Feb 2016 12:45:12 +0100 Subject: [OmniOS-discuss] "pkg update" NOW for KVM security fixes! In-Reply-To: References: Message-ID: Hi Dan, > "pkg update" is your friend for LTS (r151014) and Stable (r151016). will this fix be part of r151006 LTS as well? - Stefan From alka at hfg-gmuend.de Sat Feb 13 20:56:58 2016 From: alka at hfg-gmuend.de (=?UTF-8?Q?G=c3=bcnther_Alka?=) Date: Sat, 13 Feb 2016 21:56:58 +0100 Subject: [OmniOS-discuss] New bloody (IPS only this time) In-Reply-To: References: Message-ID: <56BF989A.1080402@hfg-gmuend.de> Thanks napp-it is working again with this sudo fix Gea Am 12.02.2016 um 23:22 schrieb Dan McDonald: > Based on illumos-omnios master commit cc70d5b, uname -v reports "omnios-cc70d5b". > > And omnios-build master commit 45f0d7b. > > New with this update: > > - Case-sensitivity now in ZFS test suite. > > - GLDv3 improvement (by OmniTI's own Dale Ghent) which should produce less confusing dladm(1M) output. > > - SunSSH and sudo now honor the illumos-bug-6057 ways of doing things. Please PLEASE look for other "last login" weirdness, but there shouldn't be any. If there is, PLEASE report it to this list ASAP. > > - Speaking of SSH, OpenSSH now includes the full wad of Joyent work (modulo 1-2 small differences) to be more of a SunSSH replacement. If you haven't tried OpenSSH because you needed something from SunSSH, PLEASE try it now. > > > There is no new release media for this update, but I did update all of the packages, so you'll need to create a new BE and reboot. > > Thanks, > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Guenther Alka, Dipl.-Ing. (FH) Leiter des Rechenzentrums head of computer center Tel 07171 602 627 Fax 07171 69259 guenther.alka at hfg-gmuend.de http://rz.hfg-gmuend.de From daleg at omniti.com Sun Feb 14 01:13:24 2016 From: daleg at omniti.com (Dale Ghent) Date: Sat, 13 Feb 2016 20:13:24 -0500 Subject: [OmniOS-discuss] Intel Skylake In-Reply-To: <20160212013036.75101f6c@sleipner.datanom.net> References: <20160212013036.75101f6c@sleipner.datanom.net> Message-ID: <3265585C-21B5-4260-84EE-FECCFF455F8A@omniti.com> > On Feb 11, 2016, at 7:30 PM, Michael Rasmussen wrote: > > Hi all, > > Does Omnios 151014 support intel skylake? The CPU itself, yes. However the series 100/C230 chipset's integrated i219 ethernet isn't likely to be picked up by the igb driver. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bfriesen at simple.dallas.tx.us Sun Feb 14 01:51:32 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sat, 13 Feb 2016 19:51:32 -0600 (CST) Subject: [OmniOS-discuss] Zones Backup Message-ID: My microserver project (Xeon D based) is almost completely done now. All services are partitioned into zones. I created a base zone and then cloned that zone to create the other zones. All 'data' used by a zone is external via lofs mounts with only configuration and services being in the zone. While there is already backup of the 'data' using my existing methods (zfs send to live fs on another system + rsync from a different system), I have not yet come up with the best way to back up zones. It is very easy to back up zones as long as one is willing to replicate all the data in the zone. Plenty of documentation exists for how to do this. Since OmniOS uses "big" zones, this results in excessive redundant data (e.g. OmniOS distribution files) being backed up. Backing up unneeded files wastes space and makes restoration more complicated. Effort to restore a whole system from scratch needs to be minimized. using GNU diff I can do something like: diff -r -q /zones/base/root /zones/web/root and see differences between my base zone and a 'web' zone. Most differences are due to spurious differences in OmniOS itself. If there was a manifest available for the whole installed system (perhaps possible to derive from IPS), then it could be used to determine the files to ignore, and the files changed or added outside of OmniOS. This could be used to drive a backup system which only emits added or changed files from the base. Does anyone have an effective zone backup method they can share which strips out all the cruft and retains only key files such as configuration files? Thanks, Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From gate03 at landcroft.co.uk Sun Feb 14 05:37:48 2016 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Sun, 14 Feb 2016 15:37:48 +1000 Subject: [OmniOS-discuss] Zones Backup In-Reply-To: References: Message-ID: <20160214153748.27c8fdf0@punda-mlia> On Sat, 13 Feb 2016 19:51:32 -0600 (CST) Bob Friesenhahn wrote: > Does anyone have an effective zone backup method they can share which > strips out all the cruft and retains only key files such as > configuration files? I'll put this on the table in case it fits: I have a master installation script which starts with a fresh installation and performs all my customisation including installing and configuring zones. I don't back up the zones themselves; just the reconfiguration information. It's almost automatic; the only part that requires manual intervention is running 'passwd' within a zone, since that requires console access and won't accept redirected input from a file. In due course I'll go to LDAP and that problem with disappear. In practice I don't have the nerve to run the entire script from start to finish but tend to chop it up and run bits; nevertheless it is complete. I use type=zfs for mounting zone data like /var/postgres and Dovecot's IMAP store. Each of those data-sets have set mountpoint=legacy and cannot be viewed in the global zone. They are 'important' of course, and backed-up. The long-running part of my script is a loop which starts: # for ZONE in person diener KVM DHCP ; do ... which creates and installs the zones. To run a configuration script in a zone: # cp -pr /support/omnios/zone/somezone/setupaservice /zone/somezone/root/tmp/ # zlogin somezone /tmp/setupaservice # rm /zone/somezone/root/tmp/ and pkg -R to install packages into zones. This does require the discipline to record your changes in your setup script, but the benefit is that your zones are entirely recreatable and don't have to be backed-up. It seems long-winded but I reckon it's a lot quicker and tidier to apply a customisation script to a fresh installation than it is to splice-in stuff from /etc etc. from a back-up. If you go for this, you will probably have to set up a parallel set of zones as you develop your customisation script, to compare new with old until your script is complete. The above serves to preserve state for a planned upgrade as well. The only 'extras' FOR ME in that case are: # pg_dumpall to prepare for a Postgres upgrade. # slapcat to prepare for an OpenLDAP upgrade. Hopefully the above gives you enough information to do it for yourself. ______________ Michael Mounteney From bfriesen at simple.dallas.tx.us Sun Feb 14 16:36:04 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 14 Feb 2016 10:36:04 -0600 (CST) Subject: [OmniOS-discuss] Zones Backup In-Reply-To: <20160214153748.27c8fdf0@punda-mlia> References: <20160214153748.27c8fdf0@punda-mlia> Message-ID: On Sun, 14 Feb 2016, Michael Mounteney wrote: > > This does require the discipline to record your changes in your setup > script, but the benefit is that your zones are entirely recreatable and > don't have to be backed-up. > > It seems long-winded but I reckon it's a lot quicker and tidier to apply > a customisation script to a fresh installation than it is to splice-in > stuff from /etc etc. from a back-up. > > If you go for this, you will probably have to set up a parallel set of > zones as you develop your customisation script, to compare new with old > until your script is complete. This seems like a good plan to me. Approaches which result in a "carbon copy" of a zone don't work so well when the "carbon copy" is not a good match for the host system when it is restored. A backup approach which also serves as documentation for later about what was changed is very useful. It does seem like IPS should be able to produce the list of files provided by the OS, as well as any files which were subsequently changed, since it already knows how to not overwrite files which were changed. 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 Sun Feb 14 20:31:32 2016 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 14 Feb 2016 15:31:32 -0500 Subject: [OmniOS-discuss] Intel Skylake In-Reply-To: <3265585C-21B5-4260-84EE-FECCFF455F8A@omniti.com> References: <20160212013036.75101f6c@sleipner.datanom.net> <3265585C-21B5-4260-84EE-FECCFF455F8A@omniti.com> Message-ID: > On Feb 13, 2016, at 8:13 PM, Dale Ghent wrote: > > >> On Feb 11, 2016, at 7:30 PM, Michael Rasmussen wrote: >> >> Hi all, >> >> Does Omnios 151014 support intel skylake? > > The CPU itself, yes. However the series 100/C230 chipset's integrated i219 ethernet isn't likely to be picked up by the igb driver. Is that a missing-PCI-ID? Or do we need to merge "e1000api" from FreeBSD/upstream? Dan From bfriesen at simple.dallas.tx.us Sun Feb 14 21:25:12 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 14 Feb 2016 15:25:12 -0600 (CST) Subject: [OmniOS-discuss] Semi-automated conversion from Sun DHCP to ISC DHCP? Message-ID: While it is not too difficult to accomplish manually, I am looking for an automation script to help convert from Sun DHCP to ISC DHCP configuration formats. The existing configuration is no more than what was easily accomplished via the dhcpmgr GUI so it is not complex. I have been asking Google but all I am finding are questions such as this one: https://lists.isc.org/pipermail/dhcp-hackers/2014-November/002098.html The configuration to be migrated is a simple subnet configuration plus MAC to IP fixed mappings. Since I am apparently the last in the whole world to start this migration, there must surely be a handy script by now. Does such a script exist? Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From daleg at omniti.com Mon Feb 15 04:31:25 2016 From: daleg at omniti.com (Dale Ghent) Date: Sun, 14 Feb 2016 23:31:25 -0500 Subject: [OmniOS-discuss] Intel Skylake In-Reply-To: References: <20160212013036.75101f6c@sleipner.datanom.net> <3265585C-21B5-4260-84EE-FECCFF455F8A@omniti.com> Message-ID: <1FA8419D-96F7-46DC-BD44-20DE54245879@omniti.com> > On Feb 14, 2016, at 3:31 PM, Dan McDonald wrote: > > >> On Feb 13, 2016, at 8:13 PM, Dale Ghent wrote: >> >> >>> On Feb 11, 2016, at 7:30 PM, Michael Rasmussen wrote: >>> >>> Hi all, >>> >>> Does Omnios 151014 support intel skylake? >> >> The CPU itself, yes. However the series 100/C230 chipset's integrated i219 ethernet isn't likely to be picked up by the igb driver. > > Is that a missing-PCI-ID? Or do we need to merge "e1000api" from FreeBSD/upstream? It requires a rather hefty e1000 update to gain. Sadly not just a case of adding a PCI ID. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gordon at hafnia.dk Mon Feb 15 12:27:13 2016 From: gordon at hafnia.dk (Gordon Selisek) Date: Mon, 15 Feb 2016 13:27:13 +0100 Subject: [OmniOS-discuss] How to do networking between host and KVM guest? In-Reply-To: <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> References: <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> Message-ID: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk> Hi all, I ran into a problem, how to do networking between host and KVM guest? I read a lot of oracle documentation, but the virtual networking seems to be enough differently implemented, so that i can't wrap my head around it and apply it to omniOS. This is what i have, and the guest can communicate with the outside world and the host. The host communicate with the outside world, but not the guest. And if i assaign an address to vnic0, then the guest can not communicate with the host. dladm show-link LINK CLASS MTU STATE BRIDGE OVER e1000g0 phys 1500 up -- -- vnic0 vnic 1500 up -- e1000g0 ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 e1000g0/lan static ok 192.168.200.190/24 lo0/v6 static ok ::1/128 Any hints? please? Cordial regards Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasslerd at gmx.li Mon Feb 15 12:40:09 2016 From: hasslerd at gmx.li (Dominik Hassler) Date: Mon, 15 Feb 2016 13:40:09 +0100 Subject: [OmniOS-discuss] zpool fragmentation question Message-ID: Hi there, on my server at home (OmniOS r16, patched to the latest version) I added a brand new zpool (simple 2 HDD mirror). zpool list shows a fragmentation of 14% on my main pool. I did a recursive snapshot on a dataset on the main pool. transferred the dataset via replication stream to the new pool (zfs send -R mainpool/dataset at backup | zfs recv -F newpool/dataset). now zpool list shows a fragmentation of 27% on the *newpool* (no other data have ever been written to that pool). How can this be? Was my assumption wrong that send/recv acts like defrag on the receiving end? From johan.kragsterman at capvert.se Mon Feb 15 13:47:29 2016 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 15 Feb 2016 14:47:29 +0100 Subject: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? In-Reply-To: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk> References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>, <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> Message-ID: Hi! -----"OmniOS-discuss" skrev: ----- Till: "omnios-discuss at lists.omniti.com" Fr?n: Gordon Selisek S?nt av: "OmniOS-discuss" Datum: 2016-02-15 13:28 ?rende: [OmniOS-discuss] How to do networking between host and KVM guest? Hi all, I ran into a problem, how to do networking between host and KVM guest? I read a lot of oracle documentation, but the virtual networking seems to be enough differently implemented, so that i can't wrap my head around it and apply it to omniOS. This is what i have, and the guest can communicate with the outside world and the host. The host communicate with the outside world, but not the guest. And if i assaign an address to vnic0, then the guest can not communicate with the host. dladm show-link LINK??????? CLASS???? MTU??? STATE??? BRIDGE???? OVER e1000g0???? phys????? 1500?? up?????? --???????? -- vnic0?????? vnic????? 1500?? up?????? --???????? e1000g0 ipadm show-addr ADDROBJ?????????? TYPE???? STATE??????? ADDR lo0/v4??????????? static?? ok?????????? 127.0.0.1/8 e1000g0/lan?????? static?? ok?????????? 192.168.200.190/24 lo0/v6??????????? static?? ok?????????? ::1/128 Any hints? please? Cordial regards Gordon You need an internal virtual network, which you get with an internal virtual switch: Etherstub. To the etherstub you can connect any virtual interface from your host or your guest. /Johan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From gordon at hafnia.dk Mon Feb 15 13:55:19 2016 From: gordon at hafnia.dk (Gordon Selisek) Date: Mon, 15 Feb 2016 14:55:19 +0100 Subject: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? In-Reply-To: <152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk> References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>, <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> <152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk> Message-ID: <152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk> Johan, Thank you, i thought of that, but it's mentioned in oracle docs that Etherstubs are a pure software implementation of nics, so the can't communicate with the outside word, only and i need that both host and guest can do that, or did i misunderstand something? https://docs.oracle.com/cd/E26502_01/html/E28992/gmhfi.html says: # dladm create-etherstub etherstub Perform this step only if you are creating a private virtual network which you want to restrict from being accessed by external systems. For a description of a private virtual network, see Overview of Network Virtualization. ---- On Mon, 15 Feb 2016 14:47:29 +0100 Johan Kragsterman <johan.kragsterman at capvert.se>wrote ---- Hi! -----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: ----- Till: "omnios-discuss at lists.omniti.com" <omnios-discuss at lists.omniti.com> Fr?n: Gordon Selisek S?nt av: "OmniOS-discuss" Datum: 2016-02-15 13:28 ?rende: [OmniOS-discuss] How to do networking between host and KVM guest? Hi all, I ran into a problem, how to do networking between host and KVM guest? I read a lot of oracle documentation, but the virtual networking seems to be enough differently implemented, so that i can't wrap my head around it and apply it to omniOS. This is what i have, and the guest can communicate with the outside world and the host. The host communicate with the outside world, but not the guest. And if i assaign an address to vnic0, then the guest can not communicate with the host. dladm show-link LINK CLASS MTU STATE BRIDGE OVER e1000g0 phys 1500 up -- -- vnic0 vnic 1500 up -- e1000g0 ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 e1000g0/lan static ok 192.168.200.190/24 lo0/v6 static ok ::1/128 Any hints? please? Cordial regards Gordon You need an internal virtual network, which you get with an internal virtual switch: Etherstub. To the etherstub you can connect any virtual interface from your host or your guest. /Johan _______________________________________________ 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 hasslerd at gmx.li Mon Feb 15 14:12:10 2016 From: hasslerd at gmx.li (Dominik Hassler) Date: Mon, 15 Feb 2016 15:12:10 +0100 Subject: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? In-Reply-To: <152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk> References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>, <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> <152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>, <152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk> Message-ID: there is no need for an etherstub for your setup. I am running the same setup as you mentioned for several kvms (GZ and NGZ) in your first e-mail and no issues from guest to {host, outside} or from host {guest, outside}. you shold not assign an address to the vnic that will be used by the kvm. ? can you ping your guest from the host (hostname and/or IP)? might be a hostname resulution problem. Gesendet:?Montag, 15. Februar 2016 um 14:55 Uhr Von:?"Gordon Selisek" An:?"omnios-discuss at lists.omniti.com" Betreff:?Re: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? Johan, ? Thank you, i thought of that, but it's mentioned in oracle docs that Etherstubs are a pure software implementation of nics, so the can't communicate with the outside word, only and i need that both host and guest can do that, or did i misunderstand something? ? https://docs.oracle.com/cd/E26502_01/html/E28992/gmhfi.html? ? says: # dladm create-etherstub etherstub Perform this step only if you are creating a private virtual network which you want to restrict from being accessed by external systems. For a description of a private virtual network, see Overview of Network Virtualization[https://docs.oracle.com/cd/E26502_01/html/E28992/gfkbw.html#scrolltoc]. ? ? ---- On Mon, 15 Feb 2016 14:47:29 +0100 Johan Kragsterman wrote ---- ? ? Hi! ? ? ? ? -----"OmniOS-discuss" skrev: ----- Till: "omnios-discuss at lists.omniti.com[omnios-discuss at lists.omniti.com]" Fr?n: Gordon Selisek S?nt av: "OmniOS-discuss" Datum: 2016-02-15 13:28 ?rende: [OmniOS-discuss] How to do networking between host and KVM guest? ? Hi all, ? I ran into a problem, how to do networking between host and KVM guest? ? I read a lot of oracle documentation, but the virtual networking seems to be enough differently implemented, so that i can't wrap my head around it and apply it to omniOS. ? This is what i have, and the guest can communicate with the outside world and the host. The host communicate with the outside world, but not the guest. And if i assaign an address to vnic0, then the guest can not communicate with the host. ? dladm show-link LINK??????? CLASS???? MTU??? STATE??? BRIDGE???? OVER e1000g0???? phys????? 1500?? up?????? --???????? -- vnic0?????? vnic????? 1500?? up?????? --???????? e1000g0 ? ipadm show-addr ADDROBJ?????????? TYPE???? STATE??????? ADDR lo0/v4??????????? static?? ok?????????? 127.0.0.1/8 e1000g0/lan?????? static?? ok?????????? 192.168.200.190/24 lo0/v6??????????? static?? ok?????????? ::1/128 ? ? ? Any hints? please? ? Cordial regards ? Gordon ? ? ? You need an internal virtual network, which you get with an internal virtual switch: Etherstub. To the etherstub you can connect any virtual interface from your host or your guest. ? /Johan ? ? ? ? ? ? _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com[OmniOS-discuss at lists.omniti.com] http://lists.omniti.com/mailman/listinfo/omnios-discuss ? ? ? ?_______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss[http://lists.omniti.com/mailman/listinfo/omnios-discuss] From gordon at hafnia.dk Mon Feb 15 14:29:10 2016 From: gordon at hafnia.dk (Gordon Selisek) Date: Mon, 15 Feb 2016 15:29:10 +0100 Subject: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? In-Reply-To: References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>, <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> <152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>, <152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk> Message-ID: <152e555cab6.f05c31c3110523.6316636820069675438@hafnia.dk> Dominik, Thanks, but, no i can't even ping by hostname or ip. netstat -rn -finet Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 192.168.200.1 UG 2 1 e1000g0 127.0.0.1 127.0.0.1 UH 2 0 lo0 192.168.200.0 192.168.200.190 U 8 108532 e1000g0 I read here that "By default, networking between the control domain and other domains in the system is disabled." https://docs.oracle.com/cd/E19608-01/html/821-1485/enablenetworkbtwncsdomainandotherdomains.html And here you need to do some etherstub plumbing with ifconfig, whcich i don't believe omniOS can do. ---- On Mon, 15 Feb 2016 15:12:10 +0100 Dominik Hassler <hasslerd at gmx.li>wrote ---- there is no need for an etherstub for your setup. I am running the same setup as you mentioned for several kvms (GZ and NGZ) in your first e-mail and no issues from guest to {host, outside} or from host {guest, outside}. you shold not assign an address to the vnic that will be used by the kvm. can you ping your guest from the host (hostname and/or IP)? might be a hostname resulution problem. Gesendet: Montag, 15. Februar 2016 um 14:55 Uhr Von: "Gordon Selisek" <gordon at hafnia.dk> An: "omnios-discuss at lists.omniti.com" <omnios-discuss at lists.omniti.com> Betreff: Re: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? Johan, Thank you, i thought of that, but it's mentioned in oracle docs that Etherstubs are a pure software implementation of nics, so the can't communicate with the outside word, only and i need that both host and guest can do that, or did i misunderstand something? https://docs.oracle.com/cd/E26502_01/html/E28992/gmhfi.html says: # dladm create-etherstub etherstub Perform this step only if you are creating a private virtual network which you want to restrict from being accessed by external systems. For a description of a private virtual network, see Overview of Network Virtualization[https://docs.oracle.com/cd/E26502_01/html/E28992/gfkbw.html#scrolltoc]. ---- On Mon, 15 Feb 2016 14:47:29 +0100 Johan Kragsterman <johan.kragsterman at capvert.se[johan.kragsterman at capvert.se]>wrote ---- Hi! -----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com[omnios-discuss-bounces at lists.omniti.com]> skrev: ----- Till: "omnios-discuss at lists.omniti.com[omnios-discuss at lists.omniti.com]" <omnios-discuss at lists.omniti.com[omnios-discuss at lists.omniti.com]> Fr?n: Gordon Selisek S?nt av: "OmniOS-discuss" Datum: 2016-02-15 13:28 ?rende: [OmniOS-discuss] How to do networking between host and KVM guest? Hi all, I ran into a problem, how to do networking between host and KVM guest? I read a lot of oracle documentation, but the virtual networking seems to be enough differently implemented, so that i can't wrap my head around it and apply it to omniOS. This is what i have, and the guest can communicate with the outside world and the host. The host communicate with the outside world, but not the guest. And if i assaign an address to vnic0, then the guest can not communicate with the host. dladm show-link LINK CLASS MTU STATE BRIDGE OVER e1000g0 phys 1500 up -- -- vnic0 vnic 1500 up -- e1000g0 ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 e1000g0/lan static ok 192.168.200.190/24 lo0/v6 static ok ::1/128 Any hints? please? Cordial regards Gordon You need an internal virtual network, which you get with an internal virtual switch: Etherstub. To the etherstub you can connect any virtual interface from your host or your guest. /Johan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com[OmniOS-discuss at lists.omniti.com] http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss[http://lists.omniti.com/mailman/listinfo/omnios-discuss] -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Feb 15 15:50:18 2016 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 15 Feb 2016 10:50:18 -0500 Subject: [OmniOS-discuss] pkg.depot leaves trash in /tmp In-Reply-To: <20160210175754.GA1458@meili.valhalla.31bits.net> References: <20160210175754.GA1458@meili.valhalla.31bits.net> Message-ID: > On Feb 10, 2016, at 12:57 PM, Josef 'Jeff' Sipek wrote: > > It looks like every time I restart one of my pkg.depot services (via SMF of > course) it leaves an empty tmp dir in /tmp. E.g., currently I have: > > root at pkg:/root# ls /tmp/ > jam56725b1b.000 tmp5iDpG8 tmpIo_2sK tmpPHwxZq tmp_BxvKY tmpczrTLp tmphSuu64 tmpqmn5U1 tmpvtu316 > jam56725b1c.000 tmp9HBNSq tmpItXZJG tmpPg1uCe tmp_dgRyo tmpd3G9Ig tmpkmyfin tmprYp7w8 tmpySkpaw > jam56725b1d.000 tmpA9iuu9 tmpJRKIpV tmpQHghRG tmpa6uWks tmpd6YxZq tmplzKPzY tmpsWzIgs tmpzadiAf > screens tmpAoCZ2V tmpLB0kvW tmpV2qCK0 tmpaplUoo tmpeVifyW tmpneFKh_ tmpslF8tC > tmp0gvvKf tmpEsje8p tmpLo0DtX tmpVDRHZ2 tmpaqLWSe tmpekH4qZ tmpo1aPMW tmpt7Ucwe > tmp1ZrOC5 tmpFztsMb tmpMeOoTb tmpXXQU7B tmpbnHKKr tmpfi02rF tmpo7vEWI tmpt_15kP > tmp3LrDfB tmpG0u0U4 tmpNRp5gs tmpXa2l5Z tmpboqm_o tmpgGWPdL tmpofQC_p tmpvHSd0v > tmp4vXC5M tmpH9j286 tmpNYOs87 tmpZtAcH0 tmpciYGBk tmph292N2 tmpqfz2HY tmpvmAscD > > Since they are just empty dirs, it's just annoying and unexpected. (Instead > of actually taking up valuable /tmp space.) > > Given that my best python still looks like C, I'm staying away from the pkg > source code and just mentioning it here. Something deep in pkg5 or even generic python is doing this. A full OmniOS-on-demand build leaves a ton of empty tmp files around as well. :-/ Thanks for the heads-up on this. Dan From vab at bb-c.de Mon Feb 15 16:02:30 2016 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 15 Feb 2016 17:02:30 +0100 Subject: [OmniOS-discuss] pkg.depot leaves trash in /tmp In-Reply-To: References: <20160210175754.GA1458@meili.valhalla.31bits.net> Message-ID: <22209.63126.285227.261283@glaurung.bb-c.de> > > It looks like every time I restart one of my pkg.depot services (via SMF of > > course) it leaves an empty tmp dir in /tmp. E.g., currently I have: > > > > root at pkg:/root# ls /tmp/ > > jam56725b1b.000 tmp5iDpG8 tmpIo_2sK tmpPHwxZq tmp_BxvKY tmpczrTLp > > tmphSuu64 tmpqmn5U1 tmpvtu316 [...] > > Something deep in pkg5 or even generic python is doing this. A full OmniOS-on-demand build leaves a ton of empty tmp files around as well. :-/ Stock Solaris also does this. This behavior is quite annoying and has been on my "must-track-down-and-destroy-if-ever-I-find-the-time" list for many months now. :-( Maybe it will go away eventually in upstream IPS... 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 Mon Feb 15 19:41:17 2016 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 15 Feb 2016 14:41:17 -0500 Subject: [OmniOS-discuss] pkg.depot leaves trash in /tmp In-Reply-To: References: <20160210175754.GA1458@meili.valhalla.31bits.net> Message-ID: > On Feb 15, 2016, at 10:50 AM, Dan McDonald wrote: > > Something deep in pkg5 or even generic python is doing this. A full OmniOS-on-demand build leaves a ton of empty tmp files around as well. :-/ I think I figured out the OmniOS-on-demand one. The 1.10.0 version of "numpy" generates a TON during its build. Updating that to 1.10.2 eliminates a good chunk of them. https://github.com/numpy/numpy/commit/381d67126b6ed1b4f36943bd147e208e8e57371b I do suspect the tempdirs Python API is being improperly used in other areas as well. Dan From richard.elling at richardelling.com Mon Feb 15 22:11:40 2016 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 15 Feb 2016 14:11:40 -0800 Subject: [OmniOS-discuss] zpool fragmentation question In-Reply-To: References: Message-ID: > On Feb 15, 2016, at 4:40 AM, Dominik Hassler wrote: > > Hi there, > > on my server at home (OmniOS r16, patched to the latest version) I added a brand new zpool (simple 2 HDD mirror). > > zpool list shows a fragmentation of 14% on my main pool. I did a recursive snapshot on a dataset on the main pool. transferred the dataset via replication stream to the new pool (zfs send -R mainpool/dataset at backup | zfs recv -F newpool/dataset). > > now zpool list shows a fragmentation of 27% on the *newpool* (no other data have ever been written to that pool). > > How can this be? Was my assumption wrong that send/recv acts like defrag on the receiving end? The pool?s fragmentation is a roll-up of the metaslab fragmentation. A metaslab?s fragmentation metric is a weighted estimate of the number of small unallocated spaces in the metaslab. As such, a 100% free metaslab has no fragmentation. Similarly, a metaslab with a lot of 512-byte spaces free has a higher fragmentation metric. To get a better idea of the layout, free space, and computed fragmentation metric, use ?zdb -mm poolname? It is not clear how useful the metric is in practice, particularly when comparing pools of different size and metaslab counts. IMHO, the zdb -mm output is much more useful than the aggregate metric. ? richard -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Tue Feb 16 00:08:10 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 15 Feb 2016 18:08:10 -0600 (CST) Subject: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? In-Reply-To: <152e555cab6.f05c31c3110523.6316636820069675438@hafnia.dk> References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>, <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> <152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>, <152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk> <152e555cab6.f05c31c3110523.6316636820069675438@hafnia.dk> Message-ID: On Mon, 15 Feb 2016, Gordon Selisek wrote: > > I read here that "By default, networking between the control domain and other domains in the system is disabled." > > https://docs.oracle.com/cd/E19608-01/html/821-1485/enablenetworkbtwncsdomainandotherdomains.html > > And here you need to do some etherstub plumbing with ifconfig, whcich i don't believe omniOS can do. This is Oracle documentation for logical domains on SPARC (Oracle VM Server for SPARC 2.0 Administration Guide), which you likely do not have, particularly since you are using OmniOS. You should remove the IP address assignment on the vnic which was assigned by the host, as was suggested by Dominik Hassler. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From gordon at hafnia.dk Tue Feb 16 08:22:27 2016 From: gordon at hafnia.dk (Gordon Selisek) Date: Tue, 16 Feb 2016 09:22:27 +0100 Subject: [OmniOS-discuss] Ang: How to do networking between host and KVM guest? In-Reply-To: References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>, <152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk> <152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>, <152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk> <152e555cab6.f05c31c3110523.6316636820069675438@hafnia.dk> Message-ID: <152e92c66c4.e10a8651138991.8491711277099761137@hafnia.dk> Bob, Thanks - I already did remove the ip address assignment, and then my trouble started with the host not being able to reach the guest. I "solved" my problem by a reinstall of omniOS, and everything reverted to normal. Not my favorite MO, but I didn't have time to do in-depth debug. Thank you all for your suggestions. ---- On Tue, 16 Feb 2016 01:08:10 +0100 Bob Friesenhahn <bfriesen at simple.dallas.tx.us>wrote ---- On Mon, 15 Feb 2016, Gordon Selisek wrote: > > I read here that "By default, networking between the control domain and other domains in the system is disabled." > > https://docs.oracle.com/cd/E19608-01/html/821-1485/enablenetworkbtwncsdomainandotherdomains.html > > And here you need to do some etherstub plumbing with ifconfig, whcich i don't believe omniOS can do. This is Oracle documentation for logical domains on SPARC (Oracle VM Server for SPARC 2.0 Administration Guide), which you likely do not have, particularly since you are using OmniOS. You should remove the IP address assignment on the vnic which was assigned by the host, as was suggested by Dominik Hassler. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafibeyli at gmail.com Tue Feb 16 15:45:14 2016 From: rafibeyli at gmail.com (Hafiz Rafiyev) Date: Tue, 16 Feb 2016 17:45:14 +0200 (EET) Subject: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy Message-ID: <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> I now its OmniOs forum,question about Nexenta v4.0.4FP02. Maybe issue is common to illumos, Getting below error when trying to rollback zvol snapshot,zvol unshared before rollback operation,system rebooted but result was same. any sugesttions? zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002 cannot rollback 'OPOOL/DATA': dataset is busy Nexenta log: Feb 16 15:35:47 xxx nms[966]: [ID 702911 local0.error] (:1.12) EXCEPTION: SystemCallError: SnapshotContainer::rollback(OPOOL/DATA at snap-hourly-1-2016-02-16-130002,-r): [zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002] cannot rollback 'OPOOL/DATA': dataset is busy -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.kragsterman at capvert.se Tue Feb 16 16:11:33 2016 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Tue, 16 Feb 2016 17:11:33 +0100 Subject: [OmniOS-discuss] Ang: zvol snapshot rollback issue,dataset busy In-Reply-To: <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> References: <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> Message-ID: Hi! -----"OmniOS-discuss" skrev: ----- Till: omnios-discuss Fr?n: Hafiz Rafiyev S?nt av: "OmniOS-discuss" Datum: 2016-02-16 16:47 ?rende: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy I now its OmniOs forum,question about Nexenta v4.0.4FP02. Maybe issue is common to illumos, Getting below error when trying to rollback zvol snapshot,zvol unshared before rollback operation,system rebooted but result was same. ? any sugesttions? zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002 cannot rollback 'OPOOL/DATA': dataset is busy ? Nexenta log: Feb 16 15:35:47 xxx nms[966]: [ID 702911 local0.error] (:1.12) EXCEPTION: SystemCallError: SnapshotContainer::rollback(OPOOL/DATA at snap-hourly-1-2016-02-16-130002,-r): [zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002] cannot rollback 'OPOOL/DATA': dataset is busy My guess is that the volume you want to roll it back to is registred as an LU with stmf...is it? If so, you need to delete it first. But be aware, before you delete the LU you need to delete any view for that LU. Otherwise you get views "hanging in the air" which is difficult to get rid of. Johan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From stephan.budach at JVM.DE Tue Feb 16 16:43:32 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Tue, 16 Feb 2016 17:43:32 +0100 Subject: [OmniOS-discuss] Ang: zvol snapshot rollback issue, dataset busy In-Reply-To: References: <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <56C351B4.4000505@jvm.de> Am 16.02.16 um 17:11 schrieb Johan Kragsterman: > Hi! > > > -----"OmniOS-discuss" skrev: ----- > Till: omnios-discuss > Fr?n: Hafiz Rafiyev > S?nt av: "OmniOS-discuss" > Datum: 2016-02-16 16:47 > ?rende: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy > > I now its OmniOs forum,question about Nexenta v4.0.4FP02. > Maybe issue is common to illumos, > > Getting below error when trying to rollback zvol snapshot,zvol unshared before rollback operation,system rebooted but result was same. > > any sugesttions? > > zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002 > > cannot rollback 'OPOOL/DATA': dataset is busy > > > Nexenta log: > > Feb 16 15:35:47 xxx nms[966]: [ID 702911 local0.error] (:1.12) EXCEPTION: SystemCallError: SnapshotContainer::rollback(OPOOL/DATA at snap-hourly-1-2016-02-16-130002,-r): > > [zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002] cannot rollback 'OPOOL/DATA': dataset is busy > > > > > My guess is that the volume you want to roll it back to is registred as an LU with stmf...is it? If so, you need to delete it first. But be aware, before you delete the LU you need to delete any view for that LU. Otherwise you get views "hanging in the air" which is difficult to get rid of. > > > Johan > I'd say, it's the other way round? if you delete a LUN via stmfadm delete-lu, that will also delete it's views, which can be annoying, if you then want to re-import the LUN from the rolled back snapshot, no? If you want to keep the view, which is what I usually want to do, just run stmfadm delete-lu -k to keep the view. That way, you can then re-import the LUN on the rolled back dataset and won't have to re-create the view for it. Cheers, Stephan > From johan.kragsterman at capvert.se Tue Feb 16 17:58:09 2016 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Tue, 16 Feb 2016 18:58:09 +0100 Subject: [OmniOS-discuss] Ang: Re: Ang: zvol snapshot rollback issue, dataset busy In-Reply-To: <56C351B4.4000505@jvm.de> References: <56C351B4.4000505@jvm.de>, <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> Message-ID: Hi! -----"OmniOS-discuss" skrev: ----- Till: Fr?n: Stephan Budach S?nt av: "OmniOS-discuss" Datum: 2016-02-16 17:44 ?rende: Re: [OmniOS-discuss] Ang: zvol snapshot rollback issue, dataset busy Am 16.02.16 um 17:11 schrieb Johan Kragsterman: > Hi! > > > -----"OmniOS-discuss" skrev: ----- > Till: omnios-discuss > Fr?n: Hafiz Rafiyev > S?nt av: "OmniOS-discuss" > Datum: 2016-02-16 16:47 > ?rende: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy > > I now its OmniOs forum,question about Nexenta v4.0.4FP02. > Maybe issue is common to illumos, > > Getting below error when trying to rollback zvol snapshot,zvol unshared before rollback operation,system rebooted but result was same. > ? > any sugesttions? > > zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002 > > cannot rollback 'OPOOL/DATA': dataset is busy > ? > > Nexenta log: > > Feb 16 15:35:47 xxx nms[966]: [ID 702911 local0.error] (:1.12) EXCEPTION: SystemCallError: SnapshotContainer::rollback(OPOOL/DATA at snap-hourly-1-2016-02-16-130002,-r): > > [zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002] cannot rollback 'OPOOL/DATA': dataset is busy > > > > > My guess is that the volume you want to roll it back to is registred as an LU with stmf...is it? If so, you need to delete it first. But be aware, before you delete the LU you need to delete any view for that LU. Otherwise you get views "hanging in the air" which is difficult to get rid of. > > > Johan > I'd say, it's the other way round… if you delete a LUN via stmfadm delete-lu, that will also delete it's views, which can be annoying, if you then want to re-import the LUN from the rolled back snapshot, no? If you want to keep the view, which is what I usually want to do, just run stmfadm delete-lu -k to keep the view. That way, you can then re-import the LUN on the rolled back dataset and won't have to re-create the view for it. Cheers, Stephan Is that so? I have been annoyed by this for a long time, that I needed to delete the view as well. But actually this was not the case some years ago when I discovered how I needed to do this. At this time I had views "hanging in the air" without connection to a LU, and difficulties to remove them. Happy to see that this is working the way it should... But I am not familiar with this -k option, where is that one documented? Can't find it on Illumos man page for stmf, nor can I find it on Oracle. /Johan > _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From rafibeyli at gmail.com Tue Feb 16 18:55:14 2016 From: rafibeyli at gmail.com (Hafiz Rafiyev) Date: Tue, 16 Feb 2016 20:55:14 +0200 (EET) Subject: [OmniOS-discuss] Ang: zvol snapshot rollback issue, dataset busy In-Reply-To: References: <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <1521758439.1301239.1455648914180.JavaMail.zimbra@cantekstil.com.tr> Johan thank you for quick response, I deleted views,but will try delete LU too, will inform abot result, Regads, Hafiz ----- Orijinal Mesaj ----- Kimden: "Johan Kragsterman" Kime: "Hafiz Rafibeyli" Kk: "omnios-discuss" G?nderilenler: 16 ?ubat Sal? 2016 18:11:33 Konu: Ang: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy Hi! -----"OmniOS-discuss" skrev: ----- Till: omnios-discuss Fr?n: Hafiz Rafiyev S?nt av: "OmniOS-discuss" Datum: 2016-02-16 16:47 ?rende: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy I now its OmniOs forum,question about Nexenta v4.0.4FP02. Maybe issue is common to illumos, Getting below error when trying to rollback zvol snapshot,zvol unshared before rollback operation,system rebooted but result was same. ? any sugesttions? zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002 cannot rollback 'OPOOL/DATA': dataset is busy ? Nexenta log: Feb 16 15:35:47 xxx nms[966]: [ID 702911 local0.error] (:1.12) EXCEPTION: SystemCallError: SnapshotContainer::rollback(OPOOL/DATA at snap-hourly-1-2016-02-16-130002,-r): [zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002] cannot rollback 'OPOOL/DATA': dataset is busy My guess is that the volume you want to roll it back to is registred as an LU with stmf...is it? If so, you need to delete it first. But be aware, before you delete the LU you need to delete any view for that LU. Otherwise you get views "hanging in the air" which is difficult to get rid of. Johan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From stephan.budach at JVM.DE Wed Feb 17 07:52:27 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Wed, 17 Feb 2016 08:52:27 +0100 Subject: [OmniOS-discuss] Ang: Re: Ang: zvol snapshot rollback issue, dataset busy In-Reply-To: References: <56C351B4.4000505@jvm.de>, <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <56C426BB.6030207@jvm.de> Am 16.02.16 um 18:58 schrieb Johan Kragsterman: > Hi! > > > > -----"OmniOS-discuss" skrev: ----- > Till: > Fr?n: Stephan Budach > S?nt av: "OmniOS-discuss" > Datum: 2016-02-16 17:44 > ?rende: Re: [OmniOS-discuss] Ang: zvol snapshot rollback issue, dataset busy > > Am 16.02.16 um 17:11 schrieb Johan Kragsterman: >> Hi! >> >> >> -----"OmniOS-discuss" skrev: ----- >> Till: omnios-discuss >> Fr?n: Hafiz Rafiyev >> S?nt av: "OmniOS-discuss" >> Datum: 2016-02-16 16:47 >> ?rende: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy >> >> I now its OmniOs forum,question about Nexenta v4.0.4FP02. >> Maybe issue is common to illumos, >> >> Getting below error when trying to rollback zvol snapshot,zvol unshared before rollback operation,system rebooted but result was same. >> >> any sugesttions? >> >> zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002 >> >> cannot rollback 'OPOOL/DATA': dataset is busy >> >> >> Nexenta log: >> >> Feb 16 15:35:47 xxx nms[966]: [ID 702911 local0.error] (:1.12) EXCEPTION: SystemCallError: SnapshotContainer::rollback(OPOOL/DATA at snap-hourly-1-2016-02-16-130002,-r): >> >> [zfs rollback -r OPOOL/DATA at snap-hourly-1-2016-02-16-130002] cannot rollback 'OPOOL/DATA': dataset is busy >> >> >> >> >> My guess is that the volume you want to roll it back to is registred as an LU with stmf...is it? If so, you need to delete it first. But be aware, before you delete the LU you need to delete any view for that LU. Otherwise you get views "hanging in the air" which is difficult to get rid of. >> >> >> Johan >> > I'd say, it's the other way round… if you delete a LUN via stmfadm > delete-lu, that will also delete it's views, which can be annoying, if > you then want to re-import the LUN from the rolled back snapshot, no? > > If you want to keep the view, which is what I usually want to do, just > run stmfadm delete-lu -k to keep the view. That way, you can then > re-import the LUN on the rolled back dataset and won't have to re-create > the view for it. > > Cheers, > Stephan > > > > Is that so? I have been annoyed by this for a long time, that I needed to delete the view as well. But actually this was not the case some years ago when I discovered how I needed to do this. At this time I had views "hanging in the air" without connection to a LU, and difficulties to remove them. > Happy to see that this is working the way it should... > > But I am not familiar with this -k option, where is that one documented? Can't find it on Illumos man page for stmf, nor can I find it on Oracle. > > > /Johan > I concurr, as much as I had found it also very cumbersome having to delete all views manually in the old days? I think to remember, that this was on OpenSolaris in 2011, when I started playing with COMSTAR and I was creating/removing LUNs and targets quite frequently. However, on a production system, where everything has settled, I prefer it the other way round and I like to keep the vews in case I have to remove a LUN for the sake of a snapshot rollback. Actually, the -k option is not mentioned anywhere but it is supported up to any version I checked. I came across this option when I searched the net for any means of deleting a LUN, but keeping the view and on some random website, there it was... Cheers, Stephan From gordon at hafnia.dk Wed Feb 17 14:08:51 2016 From: gordon at hafnia.dk (Gordon Selisek) Date: Wed, 17 Feb 2016 15:08:51 +0100 Subject: [OmniOS-discuss] Modify or Delete a busy VNIC? Message-ID: <152ef8fe5a6.fb101e0c17643.9188063082698391779@hafnia.dk> dear all, i need to either delete a busy vnic, or modify the vnic "OVER" property from a script. the vnic is used by a KVM running on same box. dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID vnic0 e1000g0 1000 2:8:20:1b:41:3c random 0 delete: the link is busy and can not be deleted, even if i kill the qemu process that is using it. modify: the dladm modify-vnic is not implemented in OmniOs, alas in Solaris11 it's readily availabe (http://docs.oracle.com/cd/E26502_01/html/E28992/gmcdo.html) Any suggestions please? -------------- next part -------------- An HTML attachment was scrubbed... URL: From goktug.yildirim at gmail.com Wed Feb 17 15:49:53 2016 From: goktug.yildirim at gmail.com (Goktug Yildirim) Date: Wed, 17 Feb 2016 17:49:53 +0200 Subject: [OmniOS-discuss] Proliant gen9 In-Reply-To: References: Message-ID: Hello, I am trying to boot a Gen9 (DL380) server but have no success so far. The link you share doesn?t seem to be working. Could you please share your grub changes? Thanks in advance, -Goktug Yildirim > On 23 May 2015, at 02:09, Josh Barton wrote: > > An update to my previous message: > I am using only Legacy BIOS boot mode now and skipping UEFI entirely. Using the changes to the grub menu found in the link below I was able to get to the install screen using the r151014 image however I still get a no disk found error. The controller is : HP Smart Array P440ar Controller > > I have been trying to install OmniOS on a HP Proliant Gen9 server (r151014) but it will only boot in Legacy boot mode. R151012 will boot but no disks are found when I try to install. Has anyone experienced these issues? R151012 worked with our Proliant Gen8, is this a driver issue or something else? > > > > See: > http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c04633840 > > Thanks, > > Josh Barton > Utah Stage University Research Foundation > _______________________________________________ > 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 Feb 17 16:05:24 2016 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 17 Feb 2016 11:05:24 -0500 Subject: [OmniOS-discuss] Ang: Re: Ang: zvol snapshot rollback issue, dataset busy In-Reply-To: <56C426BB.6030207@jvm.de> References: <56C351B4.4000505@jvm.de> <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr> <56C426BB.6030207@jvm.de> Message-ID: > On Feb 17, 2016, at 2:52 AM, Stephan Budach wrote: > > > Actually, the -k option is not mentioned anywhere but it is supported up to any version I checked. I came across this option when I searched the net for any means of deleting a LUN, but keeping the view and on some random website, there it was... FYI, the man pages are open-source too! I checked the stmfadm source quickly, and the -k isn't commented with "TOP SECRET DO NOT DOCUMENT!" or anything like that. http://src.illumos.org/source/xref/illumos-gate/usr/src/man/man1m/stmfadm.1m Addressing -k would be a good way for someone to contribute. Dan From danmcd at omniti.com Wed Feb 17 16:12:21 2016 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 17 Feb 2016 11:12:21 -0500 Subject: [OmniOS-discuss] Modify or Delete a busy VNIC? In-Reply-To: <152ef8fe5a6.fb101e0c17643.9188063082698391779@hafnia.dk> References: <152ef8fe5a6.fb101e0c17643.9188063082698391779@hafnia.dk> Message-ID: > On Feb 17, 2016, at 9:08 AM, Gordon Selisek wrote: > > delete: the link is busy and can not be deleted, even if i kill the qemu process that is using it. > Then some other process is using it. Is this vnic assigned to a non-global zone? If so, you'll have to halt the non-global zone as well. Dan From gordon at hafnia.dk Wed Feb 17 16:29:30 2016 From: gordon at hafnia.dk (Gordon Selisek) Date: Wed, 17 Feb 2016 17:29:30 +0100 Subject: [OmniOS-discuss] Modify or Delete a busy VNIC? In-Reply-To: References: <152ef8fe5a6.fb101e0c17643.9188063082698391779@hafnia.dk> Message-ID: <152f010ab78.10896c8d223891.7030301832821266347@hafnia.dk> Dan, Thanks, how do i go about and find the offending process? The vnic is not assigned anything, and the qemu is running in the GZ. ---- On Wed, 17 Feb 2016 17:12:21 +0100 Dan McDonald <danmcd at omniti.com>wrote ---- > On Feb 17, 2016, at 9:08 AM, Gordon Selisek <gordon at hafnia.dk> wrote: > > delete: the link is busy and can not be deleted, even if i kill the qemu process that is using it. > Then some other process is using it. Is this vnic assigned to a non-global zone? If so, you'll have to halt the non-global zone as well. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.jochum at alcatel-lucent.com Wed Feb 17 21:24:14 2016 From: paul.jochum at alcatel-lucent.com (Paul Jochum) Date: Wed, 17 Feb 2016 15:24:14 -0600 Subject: [OmniOS-discuss] Question on puppet agent for OmniOS Message-ID: <56C4E4FE.90609@alcatel-lucent.com> Hi All: For those that run puppet as an agent on OmniOS, which version do you recommend using? I see that OpenCSW has a version, and Niksula also has one (and are there any others available?). Is one version better than others? I have tried installing the Niksula version, but I can't find any svcadm scripts to start it up (or am I missing them?). thanks, Paul From lotheac at iki.fi Wed Feb 17 21:30:04 2016 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 17 Feb 2016 23:30:04 +0200 Subject: [OmniOS-discuss] Question on puppet agent for OmniOS In-Reply-To: <56C4E4FE.90609@alcatel-lucent.com> References: <56C4E4FE.90609@alcatel-lucent.com> Message-ID: <20160217213004.GC3182@kekkonen.niksula.hut.fi> On Wed, Feb 17 2016 15:24:14 -0600, Paul Jochum wrote: > For those that run puppet as an agent on OmniOS, which version do you > recommend using? I see that OpenCSW has a version, and Niksula also has one > (and are there any others available?). Is one version better than others? > I have tried installing the Niksula version, but I can't find any svcadm > scripts to start it up (or am I missing them?). We don't ship any, because we run our agents from cron with --onetime. -- Lauri Tirkkonen | lotheac @ IRCnet From trey at mailchimp.com Wed Feb 17 21:37:28 2016 From: trey at mailchimp.com (Trey Palmer) Date: Wed, 17 Feb 2016 16:37:28 -0500 Subject: [OmniOS-discuss] Question on puppet agent for OmniOS In-Reply-To: <56C4E4FE.90609@alcatel-lucent.com> References: <56C4E4FE.90609@alcatel-lucent.com> Message-ID: Paul, We run the OpenCSW packages, puppet3 and facter2, and they work fine. They happen to line up with the versions we run on our primary platform. You need to install facter2 first, or puppet3 will install facter 1.7.6 to fulfill its dependency. I have set up an IPS repo and built puppet packages in the past, but I haven't taken the time to do so here given that the CSW packages work and OmniOS is a limited-use platform. -- Trey On Wed, Feb 17, 2016 at 4:24 PM, Paul Jochum wrote: > Hi All: > > For those that run puppet as an agent on OmniOS, which version do you > recommend using? I see that OpenCSW has a version, and Niksula also has > one (and are there any others available?). Is one version better than > others? I have tried installing the Niksula version, but I can't find any > svcadm scripts to start it up (or am I missing them?). > > thanks, > Paul > _______________________________________________ > 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 paul.jochum at alcatel-lucent.com Wed Feb 17 21:52:00 2016 From: paul.jochum at alcatel-lucent.com (Paul Jochum) Date: Wed, 17 Feb 2016 15:52:00 -0600 Subject: [OmniOS-discuss] Question on puppet agent for OmniOS In-Reply-To: <20160217213004.GC3182@kekkonen.niksula.hut.fi> References: <56C4E4FE.90609@alcatel-lucent.com> <20160217213004.GC3182@kekkonen.niksula.hut.fi> Message-ID: <56C4EB80.6050103@alcatel-lucent.com> Hi Lauri: Thanks for responding. I am new to puppet, and curious, why do you run it from cron, instead of in daemon mode? Is it more secure, or is there something else I am missing? thanks, Paul On 02/17/2016 03:30 PM, Lauri Tirkkonen wrote: > On Wed, Feb 17 2016 15:24:14 -0600, Paul Jochum wrote: >> For those that run puppet as an agent on OmniOS, which version do you >> recommend using? I see that OpenCSW has a version, and Niksula also has one >> (and are there any others available?). Is one version better than others? >> I have tried installing the Niksula version, but I can't find any svcadm >> scripts to start it up (or am I missing them?). > We don't ship any, because we run our agents from cron with --onetime. > From lotheac at iki.fi Wed Feb 17 21:59:10 2016 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 17 Feb 2016 23:59:10 +0200 Subject: [OmniOS-discuss] Question on puppet agent for OmniOS In-Reply-To: <56C4EB80.6050103@alcatel-lucent.com> References: <56C4E4FE.90609@alcatel-lucent.com> <20160217213004.GC3182@kekkonen.niksula.hut.fi> <56C4EB80.6050103@alcatel-lucent.com> Message-ID: <20160217215910.GD3182@kekkonen.niksula.hut.fi> On Wed, Feb 17 2016 15:52:00 -0600, Paul Jochum wrote: > Thanks for responding. I am new to puppet, and curious, why do you run > it from cron, instead of in daemon mode? Is it more secure, or is there > something else I am missing? It used to be that the agent was leaking memory in version 2.something when we first started using it. 'puppet kick' also existed then, to trigger an agent run from the master, but it doesn't anymore; we don't think there's any reason to run the agent as a daemon. -- Lauri Tirkkonen | lotheac @ IRCnet From trey at mailchimp.com Thu Feb 18 00:01:49 2016 From: trey at mailchimp.com (Trey Palmer) Date: Wed, 17 Feb 2016 19:01:49 -0500 Subject: [OmniOS-discuss] Question on puppet agent for OmniOS In-Reply-To: <20160217215910.GD3182@kekkonen.niksula.hut.fi> References: <56C4E4FE.90609@alcatel-lucent.com> <20160217213004.GC3182@kekkonen.niksula.hut.fi> <56C4EB80.6050103@alcatel-lucent.com> <20160217215910.GD3182@kekkonen.niksula.hut.fi> Message-ID: I should add, I'd use the niksula package over CSW if you can. I really appreciate their repo (and OmniOS). We only use the CSW package because at the time the available version happened to line up with what we were running everywhere else. As a general rule, the agents shouldn't be an earlier version than your masters. Now niksula has 3.8.5 which I might actually be able to change to. Using CSW packages intended for a diverging closed source Solaris is obviously gonna bite me sooner or later. As far as the manifest/method, if you run the daemon you can have puppet install them on the first run, and puppet's standard service resource has a "manifest" parameter that will "svccfg import" for you. But Lauri is right that there's no real reason to run the daemon vice from cron except to standardize with the rest of your org. -- Trey On Wed, Feb 17, 2016 at 4:59 PM, Lauri Tirkkonen wrote: > On Wed, Feb 17 2016 15:52:00 -0600, Paul Jochum wrote: > > Thanks for responding. I am new to puppet, and curious, why do you > run > > it from cron, instead of in daemon mode? Is it more secure, or is there > > something else I am missing? > > It used to be that the agent was leaking memory in version 2.something > when we first started using it. 'puppet kick' also existed then, to > trigger an agent run from the master, but it doesn't anymore; we don't > think there's any reason to run the agent as a daemon. > > -- > Lauri Tirkkonen | lotheac @ IRCnet > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.budach at JVM.DE Thu Feb 18 06:13:36 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Thu, 18 Feb 2016 07:13:36 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA Message-ID: <56C56110.50301@jvm.de> Hi, I have been test driving RSF-1 for the last week to accomplish the following: - cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box - export a nfs share from above zpool via a vip - have RSF-1 provide the fail-over and vip-moving - use the nfs share as a repository for my Oracle VM guests and vdisks The setup seems to work fine, but I do have one issue, I can't seem to get solved. Whenever I failover the zpool, any inflight nfs data, will be stalled for some unpredictable time. Sometimes it takes not much longer than the "move" time of the resources but sometimes it takes up to 5 mins. until the nfs client on my VM server becomes alive again. So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. I wonder, if there's anything, I could do about that. I have already played with several timeouts, nfs wise and tcp wise, but nothing seem to yield any effect on this issue. Anyone, who knows some tricks to speed up the inflight data? Thanks, Stephan From mtalbott at lji.org Thu Feb 18 07:17:11 2016 From: mtalbott at lji.org (Michael Talbott) Date: Wed, 17 Feb 2016 23:17:11 -0800 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <56C56110.50301@jvm.de> References: <56C56110.50301@jvm.de> Message-ID: <3E1C3D9B-ED47-4D99-8FD7-DDDE4368D3BB@lji.org> While I don't have a setup like you've described, I'm going to take a wild guess and say check your switches (and servers) ARP tables. Perhaps the switch isn't updating your VIP address with the other servers MAC address fast enough. Maybe as part of the failover script, throw a command to your switch to update the ARP entry or clear its ARP table. Another perhaps simpler solution / diagnostic you could do is record a ping output of the server to your router via the vip interface and address right after the failover process to try and tickle the switch to update its mac table. Also it's possible the clients might need an ARP flush too. If this is the case, another possibility is you could have both servers spoof the same MAC address and only ever have one up at a time and have them controlled by the failover script (or bad things will happen). Just a thought. Michael Sent from my iPhone > On Feb 17, 2016, at 10:13 PM, Stephan Budach wrote: > > Hi, > > I have been test driving RSF-1 for the last week to accomplish the following: > > - cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box > - export a nfs share from above zpool via a vip > - have RSF-1 provide the fail-over and vip-moving > - use the nfs share as a repository for my Oracle VM guests and vdisks > > The setup seems to work fine, but I do have one issue, I can't seem to get solved. Whenever I failover the zpool, any inflight nfs data, will be stalled for some unpredictable time. Sometimes it takes not much longer than the "move" time of the resources but sometimes it takes up to 5 mins. until the nfs client on my VM server becomes alive again. > > So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. > > I wonder, if there's anything, I could do about that. I have already played with several timeouts, nfs wise and tcp wise, but nothing seem to yield any effect on this issue. Anyone, who knows some tricks to speed up the inflight data? > > Thanks, > Stephan > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From stephan.budach at JVM.DE Thu Feb 18 07:30:17 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Thu, 18 Feb 2016 08:30:17 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <3E1C3D9B-ED47-4D99-8FD7-DDDE4368D3BB@lji.org> References: <56C56110.50301@jvm.de> <3E1C3D9B-ED47-4D99-8FD7-DDDE4368D3BB@lji.org> Message-ID: <56C57309.2070008@jvm.de> Hi Michael, Am 18.02.16 um 08:17 schrieb Michael Talbott: > While I don't have a setup like you've described, I'm going to take a wild guess and say check your switches (and servers) ARP tables. Perhaps the switch isn't updating your VIP address with the other servers MAC address fast enough. Maybe as part of the failover script, throw a command to your switch to update the ARP entry or clear its ARP table. Another perhaps simpler solution / diagnostic you could do is record a ping output of the server to your router via the vip interface and address right after the failover process to try and tickle the switch to update its mac table. Also it's possible the clients might need an ARP flush too. > > If this is the case, another possibility is you could have both servers spoof the same MAC address and only ever have one up at a time and have them controlled by the failover script (or bad things will happen). > > Just a thought. > > Michael > Sent from my iPhone > >> On Feb 17, 2016, at 10:13 PM, Stephan Budach wrote: >> >> Hi, >> >> I have been test driving RSF-1 for the last week to accomplish the following: >> >> - cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box >> - export a nfs share from above zpool via a vip >> - have RSF-1 provide the fail-over and vip-moving >> - use the nfs share as a repository for my Oracle VM guests and vdisks >> >> The setup seems to work fine, but I do have one issue, I can't seem to get solved. Whenever I failover the zpool, any inflight nfs data, will be stalled for some unpredictable time. Sometimes it takes not much longer than the "move" time of the resources but sometimes it takes up to 5 mins. until the nfs client on my VM server becomes alive again. >> >> So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. >> >> I wonder, if there's anything, I could do about that. I have already played with several timeouts, nfs wise and tcp wise, but nothing seem to yield any effect on this issue. Anyone, who knows some tricks to speed up the inflight data? >> >> Thanks, >> Stephan >> >> I don't think that the switches are the problem, since when I ping the vip from the VM host (OL6 based), then the ping only ceases for the time it takes RSF-1 to move the services and afterwards the pings continue just normally. The only thing I wonder is, if it's more of a NFS or a tcp-in-general thing. Maybe I should also test some other IP protocol to see, if that one stalls as well for that long of a time. Cheers, Stephan From daleg at omniti.com Thu Feb 18 07:59:05 2016 From: daleg at omniti.com (Dale Ghent) Date: Thu, 18 Feb 2016 02:59:05 -0500 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <56C56110.50301@jvm.de> References: <56C56110.50301@jvm.de> Message-ID: <83989321-B510-40A5-8C12-BBAB8E7A6E71@omniti.com> Are you using NFS over TCP or UDP? If using it over TCP, I would expect the TCP connection to get momentarily unhappy when its connection stalls and packets might need to be retransmitted after the floating IP's new MAC address is asserted. Have you tried UDP instead? /dale > On Feb 18, 2016, at 1:13 AM, Stephan Budach wrote: > > Hi, > > I have been test driving RSF-1 for the last week to accomplish the following: > > - cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box > - export a nfs share from above zpool via a vip > - have RSF-1 provide the fail-over and vip-moving > - use the nfs share as a repository for my Oracle VM guests and vdisks > > The setup seems to work fine, but I do have one issue, I can't seem to get solved. Whenever I failover the zpool, any inflight nfs data, will be stalled for some unpredictable time. Sometimes it takes not much longer than the "move" time of the resources but sometimes it takes up to 5 mins. until the nfs client on my VM server becomes alive again. > > So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. > > I wonder, if there's anything, I could do about that. I have already played with several timeouts, nfs wise and tcp wise, but nothing seem to yield any effect on this issue. Anyone, who knows some tricks to speed up the inflight data? > > Thanks, > Stephan > > > > _______________________________________________ > 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: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mtalbott at lji.org Thu Feb 18 08:01:12 2016 From: mtalbott at lji.org (Michael Talbott) Date: Thu, 18 Feb 2016 00:01:12 -0800 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <56C57309.2070008@jvm.de> References: <56C56110.50301@jvm.de> <3E1C3D9B-ED47-4D99-8FD7-DDDE4368D3BB@lji.org> <56C57309.2070008@jvm.de> Message-ID: If that's the case, perhaps you should check to see if the nfs ports are open upon failover. If they open just as quickly as the pings respond, then I would blame the nfs locking managers or nfs in general. The action to remedy that is beyond my scope other than to try force a remount clientside or try restarting the nfs server service, which I imagine rfs1 already does? I would be interested to know how rfs1 handles file locking during failover if at all. Michael > On Feb 17, 2016, at 11:30 PM, Stephan Budach wrote: > > Hi Michael, > >> Am 18.02.16 um 08:17 schrieb Michael Talbott: >> While I don't have a setup like you've described, I'm going to take a wild guess and say check your switches (and servers) ARP tables. Perhaps the switch isn't updating your VIP address with the other servers MAC address fast enough. Maybe as part of the failover script, throw a command to your switch to update the ARP entry or clear its ARP table. Another perhaps simpler solution / diagnostic you could do is record a ping output of the server to your router via the vip interface and address right after the failover process to try and tickle the switch to update its mac table. Also it's possible the clients might need an ARP flush too. >> >> If this is the case, another possibility is you could have both servers spoof the same MAC address and only ever have one up at a time and have them controlled by the failover script (or bad things will happen). >> >> Just a thought. >> >> Michael >> Sent from my iPhone >> >>> On Feb 17, 2016, at 10:13 PM, Stephan Budach wrote: >>> >>> Hi, >>> >>> I have been test driving RSF-1 for the last week to accomplish the following: >>> >>> - cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box >>> - export a nfs share from above zpool via a vip >>> - have RSF-1 provide the fail-over and vip-moving >>> - use the nfs share as a repository for my Oracle VM guests and vdisks >>> >>> The setup seems to work fine, but I do have one issue, I can't seem to get solved. Whenever I failover the zpool, any inflight nfs data, will be stalled for some unpredictable time. Sometimes it takes not much longer than the "move" time of the resources but sometimes it takes up to 5 mins. until the nfs client on my VM server becomes alive again. >>> >>> So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. >>> >>> I wonder, if there's anything, I could do about that. I have already played with several timeouts, nfs wise and tcp wise, but nothing seem to yield any effect on this issue. Anyone, who knows some tricks to speed up the inflight data? >>> >>> Thanks, >>> Stephan >>> >>> > I don't think that the switches are the problem, since when I ping the vip from the VM host (OL6 based), then the ping only ceases for the time it takes RSF-1 to move the services and afterwards the pings continue just normally. The only thing I wonder is, if it's more of a NFS or a tcp-in-general thing. Maybe I should also test some other IP protocol to see, if that one stalls as well for that long of a time. > > Cheers, > Stephan From illumos at cucumber.demon.co.uk Thu Feb 18 08:29:46 2016 From: illumos at cucumber.demon.co.uk (Andrew Gabriel) Date: Thu, 18 Feb 2016 08:29:46 +0000 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <56C56110.50301@jvm.de> References: <56C56110.50301@jvm.de> Message-ID: <56C580FA.7040104@cucumber.demon.co.uk> On 18/02/2016 06:13, Stephan Budach wrote: > Hi, > > I have been test driving RSF-1 for the last week to accomplish the > following: > > - cluster a zpool, that is made up from 8 mirrored vdevs, which are > based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box > - export a nfs share from above zpool via a vip > - have RSF-1 provide the fail-over and vip-moving > - use the nfs share as a repository for my Oracle VM guests and vdisks > > The setup seems to work fine, but I do have one issue, I can't seem to > get solved. Whenever I failover the zpool, any inflight nfs data, will > be stalled for some unpredictable time. Sometimes it takes not much > longer than the "move" time of the resources but sometimes it takes up > to 5 mins. until the nfs client on my VM server becomes alive again. > > So, when I issue a simple ls -l on the folder of the vdisks, while the > switchover is happening, the command somtimes comcludes in 18 to 20 > seconds, but sometime ls will just sit there for minutes. > > I wonder, if there's anything, I could do about that. I have already > played with several timeouts, nfs wise and tcp wise, but nothing seem > to yield any effect on this issue. Anyone, who knows some tricks to > speed up the inflight data? I would capture a snoop trace on both sides of the cluster, and see what's happening. In this case, I would run snoop in non-promiscuous mode at least initially, to avoid picking up any frames which the IP stack is going to discard. Can you look at the ARP cache on client during the stall? BTW, if you have 2 clustered heads both relying on another single system providing the iSCSI, that's a strange setup which may be giving you less availability (and less performance) than serving NFS directly from the SSD system without clustering. -- Andrew From stephan.budach at JVM.DE Thu Feb 18 08:58:39 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Thu, 18 Feb 2016 09:58:39 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <83989321-B510-40A5-8C12-BBAB8E7A6E71@omniti.com> References: <56C56110.50301@jvm.de> <83989321-B510-40A5-8C12-BBAB8E7A6E71@omniti.com> Message-ID: <56C587BF.9040508@jvm.de> Am 18.02.16 um 08:59 schrieb Dale Ghent: > Are you using NFS over TCP or UDP? > > If using it over TCP, I would expect the TCP connection to get momentarily unhappy when its connection stalls and packets might need to be retransmitted after the floating IP's new MAC address is asserted. Have you tried UDP instead? > > /dale > > >> On Feb 18, 2016, at 1:13 AM, Stephan Budach wrote: >> >> Hi, >> >> I have been test driving RSF-1 for the last week to accomplish the following: >> >> - cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box >> - export a nfs share from above zpool via a vip >> - have RSF-1 provide the fail-over and vip-moving >> - use the nfs share as a repository for my Oracle VM guests and vdisks >> >> The setup seems to work fine, but I do have one issue, I can't seem to get solved. Whenever I failover the zpool, any inflight nfs data, will be stalled for some unpredictable time. Sometimes it takes not much longer than the "move" time of the resources but sometimes it takes up to 5 mins. until the nfs client on my VM server becomes alive again. >> >> So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. >> >> I wonder, if there's anything, I could do about that. I have already played with several timeouts, nfs wise and tcp wise, but nothing seem to yield any effect on this issue. Anyone, who knows some tricks to speed up the inflight data? >> >> Thanks, >> Stephan Yes, NFS is using tcp for it's connection and naturally, this connection will hang as long as the connection is broken. However, when ping starts working again, all access to the NFS share as of that instance works. But? if I issue a ls on the NFS share, while the ping is not yet responding, the whole NFS connection hangs until it becomes working again and that seems can take a lot of time. I will try UDP instead of tcp and see, if I can get better results with that. Thanks, Stephan From stephan.budach at JVM.DE Thu Feb 18 10:57:20 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Thu, 18 Feb 2016 11:57:20 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <56C580FA.7040104@cucumber.demon.co.uk> References: <56C56110.50301@jvm.de> <56C580FA.7040104@cucumber.demon.co.uk> Message-ID: <56C5A390.4050701@jvm.de> Am 18.02.16 um 09:29 schrieb Andrew Gabriel: > On 18/02/2016 06:13, Stephan Budach wrote: >> Hi, >> >> I have been test driving RSF-1 for the last week to accomplish the >> following: >> >> - cluster a zpool, that is made up from 8 mirrored vdevs, which are >> based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box >> - export a nfs share from above zpool via a vip >> - have RSF-1 provide the fail-over and vip-moving >> - use the nfs share as a repository for my Oracle VM guests and vdisks >> >> The setup seems to work fine, but I do have one issue, I can't seem >> to get solved. Whenever I failover the zpool, any inflight nfs data, >> will be stalled for some unpredictable time. Sometimes it takes not >> much longer than the "move" time of the resources but sometimes it >> takes up to 5 mins. until the nfs client on my VM server becomes >> alive again. >> >> So, when I issue a simple ls -l on the folder of the vdisks, while >> the switchover is happening, the command somtimes comcludes in 18 to >> 20 seconds, but sometime ls will just sit there for minutes. >> >> I wonder, if there's anything, I could do about that. I have already >> played with several timeouts, nfs wise and tcp wise, but nothing seem >> to yield any effect on this issue. Anyone, who knows some tricks to >> speed up the inflight data? > > I would capture a snoop trace on both sides of the cluster, and see > what's happening. In this case, I would run snoop in non-promiscuous > mode at least initially, to avoid picking up any frames which the IP > stack is going to discard. Yes, I will do that and see what traffic is happening, but I have a gutt feeling that this happens, while the vip has been taken down and the next transmission to that, currently non-existent, but present in the arp-cache IP, will stall somewhere. > > Can you look at the ARP cache on client during the stall? I will, but the arp cache must be updated quite soon, as the ping start working again after 15 to 20 seconds and they need a proper arp cache as well. > > BTW, if you have 2 clustered heads both relying on another single > system providing the iSCSI, that's a strange setup which may be giving > you less availability (and less performance) than serving NFS directly > from the SSD system without clustering. > This is actually not the way, it's going to be implemented. The missing storage node is already on it's way. Once the new head is in place, one of the iSCSI targets will be moved over to the new host, such as that all components are redundant. Thanks, Stephan From mir at miras.org Thu Feb 18 11:14:15 2016 From: mir at miras.org (Michael Rasmussen) Date: Thu, 18 Feb 2016 12:14:15 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <56C56110.50301@jvm.de> References: <56C56110.50301@jvm.de> Message-ID: <20160218121415.493a6e76@sleipner.datanom.net> On Thu, 18 Feb 2016 07:13:36 +0100 Stephan Budach wrote: > > So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. > This is a known limitation in NFS. NFS was never intended to be clustered so what you experience is the NFS process on the client side keeps kernel locks for the now unavailable NFS server and any request to the process hangs waiting for these locks to be resolved. This can be compared to a situation where you hot-swap a drive in the pool without notifying the pool. Only way to resolve this is to forcefully kill all NFS client processes and the restart the NFS client. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: The founding fathers tried to set up a judicial system where the accused received a fair trial, not a system to insure an acquittal on technicalities. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From stephan.budach at JVM.DE Thu Feb 18 14:00:37 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Thu, 18 Feb 2016 15:00:37 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <20160218121415.493a6e76@sleipner.datanom.net> References: <56C56110.50301@jvm.de> <20160218121415.493a6e76@sleipner.datanom.net> Message-ID: <56C5CE85.5010100@jvm.de> Am 18.02.16 um 12:14 schrieb Michael Rasmussen: > On Thu, 18 Feb 2016 07:13:36 +0100 > Stephan Budach wrote: > >> So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. >> > This is a known limitation in NFS. NFS was never intended to be > clustered so what you experience is the NFS process on the client side > keeps kernel locks for the now unavailable NFS server and any request > to the process hangs waiting for these locks to be resolved. This can > be compared to a situation where you hot-swap a drive in the pool > without notifying the pool. > > Only way to resolve this is to forcefully kill all NFS client processes > and the restart the NFS client. > > > This is not the main issue, as this is not a clustered NFS, it's a failover one. Of course the client will have to reset it's connection, but it seems that the NFS client is just doing that, after the NFS share becomes available on the failover host. Looking at the tcpdump, I found that failing over from the primary NFS server to the secondary, will work straight on. The service stalls for some more seconds than RSF-1 needs to switch over the ZPOOL and the vip. In my tests it was always the switchback that caused these issue. Looking at the tcpdump, I noticed that when the switchback occured, the dump was swamped with DUP! acks. This indicated to me that the still running nfs server on the primary was still sending some outstanding ack to the now returned client, which vigorously denied them. I think the outcome is, that the server finally gave up sending those ack(s) and then the connection resumed. So, what helped in this case was to restart the nfs server on the primary after the ZPOOL had been switched over to the secondary? I have just tried to wait at least 5 minutes before failing back from the secondary to the primary node and this time it went as smoothly as it did, when I initially failed over from the primary to the secondary. However, I think for sanity the RSF-1 agent should also restart the nfs server on teh host, where it just moved the ZPOOL away from. So, as fas as I am concerned, this issue is resolved. Thanks everybody for chiming in on this. Cheers, Stephan From jdg117 at elvis.arl.psu.edu Thu Feb 18 19:32:42 2016 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Thu, 18 Feb 2016 14:32:42 -0500 Subject: [OmniOS-discuss] Illumos at 5 Message-ID: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu> Well done, Dan. Good presentation explaining where Omnios fits in the Illumos ecosystem. John groenveld at acm.org From danmcd at omniti.com Thu Feb 18 19:41:37 2016 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 18 Feb 2016 14:41:37 -0500 Subject: [OmniOS-discuss] Illumos at 5 In-Reply-To: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu> References: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu> Message-ID: > On Feb 18, 2016, at 2:32 PM, John D Groenveld wrote: > > > > Well done, Dan. Thanks > Good presentation explaining where Omnios fits in > the Illumos ecosystem. Slide are here: https://fosdem.org/2016/schedule/event/illumos_overview/attachments/audio/873/export/events/attachments/illumos_overview/audio/873/FOSDEM_2016.pdf I think I flubbed something to have them mislabelled as "audio", though. Dan From chip at innovates.com Thu Feb 18 20:57:56 2016 From: chip at innovates.com (Schweiss, Chip) Date: Thu, 18 Feb 2016 14:57:56 -0600 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <20160218121415.493a6e76@sleipner.datanom.net> References: <56C56110.50301@jvm.de> <20160218121415.493a6e76@sleipner.datanom.net> Message-ID: On Thu, Feb 18, 2016 at 5:14 AM, Michael Rasmussen wrote: > On Thu, 18 Feb 2016 07:13:36 +0100 > Stephan Budach wrote: > > > > > So, when I issue a simple ls -l on the folder of the vdisks, while the > switchover is happening, the command somtimes comcludes in 18 to 20 > seconds, but sometime ls will just sit there for minutes. > > > This is a known limitation in NFS. NFS was never intended to be > clustered so what you experience is the NFS process on the client side > keeps kernel locks for the now unavailable NFS server and any request > to the process hangs waiting for these locks to be resolved. This can > be compared to a situation where you hot-swap a drive in the pool > without notifying the pool. > > Only way to resolve this is to forcefully kill all NFS client processes > and the restart the NFS client. > > I've been running RSF-1 on OmniOS since about r151008. All my clients have always been NFSv3 and NFSv4. My memory is a bit fuzzy, but when I first started testing RSF-1, OmniOS still had the Sun lock manager which was later replaced with the BSD lock manager. This has had many difficulties. I do remember that fail overs when I first started with RSF-1 never had these stalls, I believe this was because the lock state was stored in the pool and the server taking over the pool would inherit that state too. That state is now lost when a pool is imported with the BSD lock manager. When I did testing I would do both full speed reading and writing to the pool and force fail overs, both by command line and by killing power on the active server. Never did I have a fail over take more than about 30 seconds for NFS to fully resume data flow. Others who know more about the BSD lock manager vs the old Sun lock manager may be able to tell us more. I'd also be curious if Nexenta has addressed this. -Chip > -- > Hilsen/Regards > Michael Rasmussen > > Get my public GnuPG keys: > michael rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -------------------------------------------------------------- > /usr/games/fortune -es says: > The founding fathers tried to set up a judicial system where the accused > received a fair trial, not a system to insure an acquittal on > technicalities. > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Thu Feb 18 21:12:13 2016 From: chip at innovates.com (Schweiss, Chip) Date: Thu, 18 Feb 2016 15:12:13 -0600 Subject: [OmniOS-discuss] Question on puppet agent for OmniOS In-Reply-To: References: <56C4E4FE.90609@alcatel-lucent.com> <20160217213004.GC3182@kekkonen.niksula.hut.fi> <56C4EB80.6050103@alcatel-lucent.com> <20160217215910.GD3182@kekkonen.niksula.hut.fi> Message-ID: The version in OpenCSW is quite old. If you're starting fresh with Puppet start with the newest version possible. Upgrades can be very painful. I run Puppet 4.3.2 installed from a gem. I use Ruby from OpenCSW to make this possible. It's still in early development, but is working very well. I've been running Puppet for 5 years on Linux, just recently on OmniOS. Soon the provision script will be on our public repo. If any would like to look at it now, email me and I'll send you a copy. I have to update ruby gems before installing puppet. The important snippets from my provision script: RUBYGEMS_VERSION="2.0.15"RUBYGEMS_UPDATE="rubygems-update-${RUBYGEMS_VERSION}.gem"RUBYGEMS_UPDATE_SOURCE="https://github.com/rubygems/rubygems/releases/download/v${RUBYGEMS_VERSION}" current_gems_version=`/opt/csw/bin/gem --version`if [ "$current_gems_version" != "${RUBYGEMS_VERSION}" ]; then wget ${RUBYGEMS_UPDATE_SOURCE}/${RUBYGEMS_UPDATE} /opt/csw/bin/gem install --local ${RUBYGEMS_UPDATE} && rm ${RUBYGEMS_UPDATE}fi /opt/csw/bin/gem install --no-rdoc --no-ri puppet -Chip On Wed, Feb 17, 2016 at 6:01 PM, Trey Palmer wrote: > I should add, I'd use the niksula package over CSW if you can. I really > appreciate their repo (and OmniOS). > > We only use the CSW package because at the time the available version > happened to line up with what we were running everywhere else. As a > general rule, the agents shouldn't be an earlier version than your masters. > > > Now niksula has 3.8.5 which I might actually be able to change to. Using > CSW packages intended for a diverging closed source Solaris is obviously > gonna bite me sooner or later. > > As far as the manifest/method, if you run the daemon you can have puppet > install them on the first run, and puppet's standard service resource has a > "manifest" parameter that will "svccfg import" for you. > > But Lauri is right that there's no real reason to run the daemon vice from > cron except to standardize with the rest of your org. > > -- Trey > > > > On Wed, Feb 17, 2016 at 4:59 PM, Lauri Tirkkonen wrote: > >> On Wed, Feb 17 2016 15:52:00 -0600, Paul Jochum wrote: >> > Thanks for responding. I am new to puppet, and curious, why do you >> run >> > it from cron, instead of in daemon mode? Is it more secure, or is there >> > something else I am missing? >> >> It used to be that the agent was leaking memory in version 2.something >> when we first started using it. 'puppet kick' also existed then, to >> trigger an agent run from the master, but it doesn't anymore; we don't >> think there's any reason to run the agent as a daemon. >> >> -- >> Lauri Tirkkonen | lotheac @ IRCnet >> _______________________________________________ >> 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 richard.elling at richardelling.com Thu Feb 18 21:56:31 2016 From: richard.elling at richardelling.com (Richard Elling) Date: Thu, 18 Feb 2016 13:56:31 -0800 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: References: <56C56110.50301@jvm.de> <20160218121415.493a6e76@sleipner.datanom.net> Message-ID: <2D7D9A5E-FFB1-4923-88A2-486FE66C3341@richardelling.com> comments below... > On Feb 18, 2016, at 12:57 PM, Schweiss, Chip wrote: > > > > On Thu, Feb 18, 2016 at 5:14 AM, Michael Rasmussen > wrote: > On Thu, 18 Feb 2016 07:13:36 +0100 > Stephan Budach > wrote: > > > > > So, when I issue a simple ls -l on the folder of the vdisks, while the switchover is happening, the command somtimes comcludes in 18 to 20 seconds, but sometime ls will just sit there for minutes. > > > This is a known limitation in NFS. NFS was never intended to be > clustered so what you experience is the NFS process on the client side > keeps kernel locks for the now unavailable NFS server and any request > to the process hangs waiting for these locks to be resolved. This can > be compared to a situation where you hot-swap a drive in the pool > without notifying the pool. > > Only way to resolve this is to forcefully kill all NFS client processes > and the restart the NFS client. ugh. No, something else is wrong. I've been running such clusters for almost 20 years, it isn't a problem with the NFS server code. > > > I've been running RSF-1 on OmniOS since about r151008. All my clients have always been NFSv3 and NFSv4. > > My memory is a bit fuzzy, but when I first started testing RSF-1, OmniOS still had the Sun lock manager which was later replaced with the BSD lock manager. This has had many difficulties. > > I do remember that fail overs when I first started with RSF-1 never had these stalls, I believe this was because the lock state was stored in the pool and the server taking over the pool would inherit that state too. That state is now lost when a pool is imported with the BSD lock manager. > > When I did testing I would do both full speed reading and writing to the pool and force fail overs, both by command line and by killing power on the active server. Never did I have a fail over take more than about 30 seconds for NFS to fully resume data flow. Clients will back-off, but the client's algorithm is not universal, so we do expect to see different client retry intervals for different clients. For example, the retries can exceed 30 seconds for Solaris clients after a minute or two (alas, I don't have the detailed data at my fingertips anymore :-(. Hence we work hard to make sure failovers occur as fast as feasible. > > Others who know more about the BSD lock manager vs the old Sun lock manager may be able to tell us more. I'd also be curious if Nexenta has addressed this. Lock manager itself is an issue and through we're currently testing the BSD lock manager in anger, we haven't seen this behaviour. Related to lock manager is name lookup. If you use name services, you add a latency dependency to failover for name lookups, which is why we often disable DNS or other network name services on high-availability services as a best practice. -- richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.tribble at gmail.com Thu Feb 18 22:15:02 2016 From: peter.tribble at gmail.com (Peter Tribble) Date: Thu, 18 Feb 2016 22:15:02 +0000 Subject: [OmniOS-discuss] Configuration sanity checking Message-ID: We're looking at some new boxes, and I would appreciate any comments on the components proposed. This would be in a 2U chassis with 24 2.5" disk slots at the front, although we're leaving a lot of those free for future growth. Motherboard - Supermicro X10DRi family CPUs - E5-2620 v3 HBA - LSI 9300-8i Network - Intel i350 or 540, depending on precise motherboard variant Disks (SSD) - Intel S3510 (boot), S3610 (application + data) Thanks! -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.landau at gmail.com Thu Feb 18 22:43:40 2016 From: daniil.landau at gmail.com (=?koi8-r?B?5MHOycnMIOzBzsTB1Q==?=) Date: Fri, 19 Feb 2016 01:43:40 +0300 Subject: [OmniOS-discuss] OmniOS and i386 hardware Message-ID: <04E027BA-B572-4EAF-A72E-3887AC2D50E8@gmail.com> Hi! This is my first letter to OmniOS mail list, so I?d like to start with many thanks to all people who creates OmniOS! OmniOS is a great project and I wish you and OmniOS all the best! I?m experimenting with OmniOS a lot and decided to create my own publisher with some packages including Samba. I had an idea to create packages including two platform builds with "isaexec switch" for binaries as all OmniOS packages. But 32-bit build has the meaning only if somebody could run OmniOS on 32-bit hardware. I know that Illumos codebase supports 32- and 64-bit architectures and found no information about OmniOS processor architecture limitations, so I decided to check how OmniOS works on 32-bit hardware myself. I used the latest stable release (r151016) ISO and 32-bit VBox VM. Installation was successfull (the only thing I had to change was GRUB config) and everything was great (including network configuration, zone configuration, etherstub and BE creation) except pkg command. The pkg command always failed with following message: root at ux32:/root# pkg Traceback (most recent call last): File "/usr/bin/pkg", line 104, in pkg_timer = pkg.misc.Timer("pkg client") File "/usr/lib/python2.6/vendor-packages/pkg/misc.py", line 2282, in __init__ self.__wtime = _prstart() File "/usr/lib/python2.6/vendor-packages/pkg/misc.py", line 876, in _prstart psinfo = ProcFS.psinfo() File "/usr/lib/python2.6/vendor-packages/pkg/misc.py", line 862, in psinfo return ProcFS._struct_unpack(psinfo_data, "psinfo_t") File "/usr/lib/python2.6/vendor-packages/pkg/misc.py", line 823, in _struct_unpack rv = list(struct.unpack(fmt, data)) struct.error: unpack requires a string argument of length 260 As I found the problem is in architecture-dependent python code. It?s so sad to have nearly working great system especially when architecture-dependent problem exists in script (which should be architecture-independent by it?s nature) and all other components works perfectly. I understand that i386-compability is not the main goal of OmniOS developers, but may I ask them (if they read this message and if they will have time for it) to fix this little problem, which makes OmniOS fully unusable on i386 hardware, and, as a result, makes meaningless all 32-bit OmniOS binaries which have 64-bit duplicates. Thanks for your attention! ?????????? ? iPhone From richard.elling at richardelling.com Thu Feb 18 23:06:40 2016 From: richard.elling at richardelling.com (Richard Elling) Date: Thu, 18 Feb 2016 15:06:40 -0800 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: References: Message-ID: Hi Peter! > On Feb 18, 2016, at 2:15 PM, Peter Tribble wrote: > > We're looking at some new boxes, and I would appreciate any comments on the > components proposed. This would be in a 2U chassis with 24 2.5" disk slots at > the front, although we're leaving a lot of those free for future growth. > > Motherboard - Supermicro X10DRi family > CPUs - E5-2620 v3 > HBA - LSI 9300-8i > Network - Intel i350 or 540, depending on precise motherboard variant > Disks (SSD) - Intel S3510 (boot), S3610 (application + data) The drives are SATA and there are quite a few SATA ports on the mobo, do you need the SAS HBA? The rest looks fairly common. -- richard From daleg at omniti.com Thu Feb 18 23:16:18 2016 From: daleg at omniti.com (Dale Ghent) Date: Thu, 18 Feb 2016 18:16:18 -0500 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: References: Message-ID: <18660578-D56F-4721-8A7E-3BBAEB47506F@omniti.com> > On Feb 18, 2016, at 5:15 PM, Peter Tribble wrote: > > We're looking at some new boxes, and I would appreciate any comments on the > components proposed. This would be in a 2U chassis with 24 2.5" disk slots at > the front, although we're leaving a lot of those free for future growth. > > Motherboard - Supermicro X10DRi family > CPUs - E5-2620 v3 > HBA - LSI 9300-8i > Network - Intel i350 or 540, depending on precise motherboard variant > Disks (SSD) - Intel S3510 (boot), S3610 (application + data) Looks fine to me: i350 (1Gb ethernet) works fine under igb. (I'm personally using those under OmniOS on Xeon-D boxes) X540 10Gb ethernet also is supported by ixgbe, of course. The LSI card operates on the LSI3008 SAS-3 chip, which is supported by mpt_sas. However you have SATA SSDs. Why not just use the motherboards's SATA3 controller? You've got 10 ports... and mixing SATA and SAS drives and controllers is asking for a headache later on. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mir at miras.org Thu Feb 18 23:28:48 2016 From: mir at miras.org (Michael Rasmussen) Date: Fri, 19 Feb 2016 00:28:48 +0100 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: <18660578-D56F-4721-8A7E-3BBAEB47506F@omniti.com> References: <18660578-D56F-4721-8A7E-3BBAEB47506F@omniti.com> Message-ID: <20160219002848.1a1fb598@sleipner.datanom.net> On Thu, 18 Feb 2016 18:16:18 -0500 Dale Ghent wrote: > > The LSI card operates on the LSI3008 SAS-3 chip, which is supported by mpt_sas. However you have SATA SSDs. Why not just use the motherboards's SATA3 controller? You've got 10 ports... and mixing SATA and SAS drives and controllers is asking for a headache later on. > He mentioned 24 2.5" disks so I guess that is the reason for the HBA. Using SFF-8087 to SATA works quiet well if that is the intension. -- 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: There are certain things men must do to remain men. -- Kirk, "The Ultimate Computer", stardate 4929.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From bfriesen at simple.dallas.tx.us Fri Feb 19 03:18:45 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Thu, 18 Feb 2016 21:18:45 -0600 (CST) Subject: [OmniOS-discuss] OmniOS and i386 hardware In-Reply-To: <04E027BA-B572-4EAF-A72E-3887AC2D50E8@gmail.com> References: <04E027BA-B572-4EAF-A72E-3887AC2D50E8@gmail.com> Message-ID: On Fri, 19 Feb 2016, ?????? ?????? wrote: > I?m experimenting with OmniOS a lot and decided to create my own > publisher with some packages including Samba. I had an idea to > create packages including two platform builds with "isaexec switch" > for binaries as all OmniOS packages. But 32-bit build has the > meaning only if somebody could run OmniOS on 32-bit hardware. Disregarding the intent of this email, I disagree that 32-bit builds have meaning only for 32-bit hardware. Solaris has traditionally mostly offered 32-bit applications and libraries. Packaged (or already-built) software may be 32-bits. Due to dependencies, it may be necessary to have 32-bit libraries installed in order to run 32-bit applications, and these typically come with 32-bit programs as well. Getting back on topic, Python does not seem to support multiple architectures in one install. However, the python binary itself seems to use the "isaexec switch" so the problem is likely that the 32-bit version is not built properly against all of the packages which are needed. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From stephan.budach at JVM.DE Fri Feb 19 06:09:18 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Fri, 19 Feb 2016 07:09:18 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: References: <56C56110.50301@jvm.de> <20160218121415.493a6e76@sleipner.datanom.net> Message-ID: <56C6B18E.4090303@jvm.de> Am 18.02.16 um 21:57 schrieb Schweiss, Chip: > > > On Thu, Feb 18, 2016 at 5:14 AM, Michael Rasmussen > wrote: > > On Thu, 18 Feb 2016 07:13:36 +0100 > Stephan Budach > wrote: > > > > > So, when I issue a simple ls -l on the folder of the vdisks, > while the switchover is happening, the command somtimes comcludes > in 18 to 20 seconds, but sometime ls will just sit there for minutes. > > > This is a known limitation in NFS. NFS was never intended to be > clustered so what you experience is the NFS process on the client side > keeps kernel locks for the now unavailable NFS server and any request > to the process hangs waiting for these locks to be resolved. This can > be compared to a situation where you hot-swap a drive in the pool > without notifying the pool. > > Only way to resolve this is to forcefully kill all NFS client > processes > and the restart the NFS client. > > > I've been running RSF-1 on OmniOS since about r151008. All my clients > have always been NFSv3 and NFSv4. > > My memory is a bit fuzzy, but when I first started testing RSF-1, > OmniOS still had the Sun lock manager which was later replaced with > the BSD lock manager. This has had many difficulties. > > I do remember that fail overs when I first started with RSF-1 never > had these stalls, I believe this was because the lock state was stored > in the pool and the server taking over the pool would inherit that > state too. That state is now lost when a pool is imported with the > BSD lock manager. > > When I did testing I would do both full speed reading and writing to > the pool and force fail overs, both by command line and by killing > power on the active server. Never did I have a fail over take more > than about 30 seconds for NFS to fully resume data flow. > > Others who know more about the BSD lock manager vs the old Sun lock > manager may be able to tell us more. I'd also be curious if Nexenta > has addressed this. > > -Chip I actually don't know, if it's the lock manager or the nfsd itself, that caused this, but as I bounced all of them after I failed the ZPOOL over while hammering it with reads and writes, lockd would also have been part of the processes that had been restarted. And remeber, this only happend when failing from to and back one host in a rather quick manner. Nevertheless, RSF-1 seems to be a solid solution and I will very likely implement it across several OmniOS boxes. Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.budach at JVM.DE Fri Feb 19 06:10:56 2016 From: stephan.budach at JVM.DE (Stephan Budach) Date: Fri, 19 Feb 2016 07:10:56 +0100 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <2D7D9A5E-FFB1-4923-88A2-486FE66C3341@richardelling.com> References: <56C56110.50301@jvm.de> <20160218121415.493a6e76@sleipner.datanom.net> <2D7D9A5E-FFB1-4923-88A2-486FE66C3341@richardelling.com> Message-ID: <56C6B1F0.1010104@jvm.de> Am 18.02.16 um 22:56 schrieb Richard Elling: > comments below... > >> On Feb 18, 2016, at 12:57 PM, Schweiss, Chip > > wrote: >> >> >> >> On Thu, Feb 18, 2016 at 5:14 AM, Michael Rasmussen> >wrote: >> >> On Thu, 18 Feb 2016 07:13:36 +0100 >> Stephan Budach > > wrote: >> >> > >> > So, when I issue a simple ls -l on the folder of the vdisks, >> while the switchover is happening, the command somtimes comcludes >> in 18 to 20 seconds, but sometime ls will just sit there for minutes. >> > >> This is a known limitation in NFS. NFS was never intended to be >> clustered so what you experience is the NFS process on the client >> side >> keeps kernel locks for the now unavailable NFS server and any request >> to the process hangs waiting for these locks to be resolved. This can >> be compared to a situation where you hot-swap a drive in the pool >> without notifying the pool. >> >> Only way to resolve this is to forcefully kill all NFS client >> processes >> and the restart the NFS client. >> > > ugh. No, something else is wrong. I've been running such clusters for > almost 20 years, > it isn't a problem with the NFS server code. > >> >> >> I've been running RSF-1 on OmniOS since about r151008. All my >> clients have always been NFSv3 and NFSv4. >> >> My memory is a bit fuzzy, but when I first started testing RSF-1, >> OmniOS still had the Sun lock manager which was later replaced with >> the BSD lock manager. This has had many difficulties. >> >> I do remember that fail overs when I first started with RSF-1 never >> had these stalls, I believe this was because the lock state was >> stored in the pool and the server taking over the pool would inherit >> that state too. That state is now lost when a pool is imported with >> the BSD lock manager. >> >> When I did testing I would do both full speed reading and writing to >> the pool and force fail overs, both by command line and by killing >> power on the active server. Never did I have a fail over take more >> than about 30 seconds for NFS to fully resume data flow. > > Clients will back-off, but the client's algorithm is not universal, so > we do expect to > see different client retry intervals for different clients. For > example, the retries can > exceed 30 seconds for Solaris clients after a minute or two (alas, I > don't have the > detailed data at my fingertips anymore :-(. Hence we work hard to make > sure failovers > occur as fast as feasible. > >> >> Others who know more about the BSD lock manager vs the old Sun lock >> manager may be able to tell us more. I'd also be curious if Nexenta >> has addressed this. > > Lock manager itself is an issue and through we're currently testing > the BSD lock > manager in anger, we haven't seen this behaviour. > > Related to lock manager is name lookup. If you use name services, you > add a latency > dependency to failover for name lookups, which is why we often disable > DNS or other > network name services on high-availability services as a best practice. > -- richard This is, why I always put each host name,involved in my cluster setups, into /etc/hosts on each node. Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Fri Feb 19 13:31:49 2016 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 19 Feb 2016 07:31:49 -0600 Subject: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA In-Reply-To: <2D7D9A5E-FFB1-4923-88A2-486FE66C3341@richardelling.com> References: <56C56110.50301@jvm.de> <20160218121415.493a6e76@sleipner.datanom.net> <2D7D9A5E-FFB1-4923-88A2-486FE66C3341@richardelling.com> Message-ID: On Thu, Feb 18, 2016 at 3:56 PM, Richard Elling < richard.elling at richardelling.com> wrote: > > > Related to lock manager is name lookup. If you use name services, you add > a latency > dependency to failover for name lookups, which is why we often disable DNS > or other > network name services on high-availability services as a best practice. > -- richard > > Interesting approach. Something I will definitely test in our environment. The biggest challenge I see is that I run Samba on a couple hosts that needs DNS. Hopefully I can find a work around for it. It would be nice if DNS could be disabled just for NFS. -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.tribble at gmail.com Fri Feb 19 14:00:27 2016 From: peter.tribble at gmail.com (Peter Tribble) Date: Fri, 19 Feb 2016 14:00:27 +0000 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: References: Message-ID: On Thu, Feb 18, 2016 at 11:06 PM, Richard Elling < richard.elling at richardelling.com> wrote: > Hi Peter! > > > On Feb 18, 2016, at 2:15 PM, Peter Tribble > wrote: > > > > We're looking at some new boxes, and I would appreciate any comments on > the > > components proposed. This would be in a 2U chassis with 24 2.5" disk > slots at > > the front, although we're leaving a lot of those free for future growth. > > > > Motherboard - Supermicro X10DRi family > > CPUs - E5-2620 v3 > > HBA - LSI 9300-8i > > Network - Intel i350 or 540, depending on precise motherboard variant > > Disks (SSD) - Intel S3510 (boot), S3610 (application + data) > > The drives are SATA and there are quite a few SATA ports on the mobo, do > you > need the SAS HBA? > So that was an interesting question, and I had to go away and investigate further. So the way this works is that the system has a 24-slot disk backplane. The disks plug into the backplane; you have to connect the backplane as a unit to something, which is where the HBA comes in. It doesn't look like there's a way to wire an individual drive to an onboard SATA port. (The boot drives are in a separate rear caddy and connect direct to the motherboard.) Aside from the drives, this is supposed to be a fairly standard Nexenta-compatible system. We're just running OmniOS rather than Nexenta on it. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Fri Feb 19 14:42:39 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 19 Feb 2016 08:42:39 -0600 (CST) Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: References: Message-ID: On Fri, 19 Feb 2016, Peter Tribble wrote: > > So that was an interesting question, and I had to go away and investigate further. > So the way this works is that the system has a 24-slot disk backplane. The disks plug > into the backplane; you have to connect the backplane as a unit to something, which > is where the HBA comes in. It doesn't look like there's a way to wire an individual drive > to an onboard SATA port. These really dense 2U systems are often a pre-packaged (or close to it) system from SuperMicro and you get what they (SuperMicro) are able to build. The product page usually makes note of that. Your integrator/builder is only able to make relatively small changes. Direct wiring 24 drives in a 2U system would be crazy. With SAS driving SATA, it seems like you would still need/want one SAS channel per drive and 24 channels is a lot. It sounds like you are getting only 8 SAS channels. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From trey at mailchimp.com Fri Feb 19 15:14:03 2016 From: trey at mailchimp.com (Trey Palmer) Date: Fri, 19 Feb 2016 10:14:03 -0500 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: References: Message-ID: I haven't checked the Supermicro models lately, but the HP DL380Gen9 has a model with 24 direct-wired 2.5" slots in 3 modular 8-disk bays. The SAS expander is an add-in card which you don't have to buy. It's really excellent for Intel DC s3X10's. Of course it's also more expensive than a Supermicro. Hopefully Supermicro has something similar now. Wiring anything SATA through a SAS expander is a risky practice. -- Trey On Friday, February 19, 2016, Bob Friesenhahn wrote: > On Fri, 19 Feb 2016, Peter Tribble wrote: > >> >> So that was an interesting question, and I had to go away and investigate >> further. >> So the way this works is that the system has a 24-slot disk backplane. >> The disks plug >> into the backplane; you have to connect the backplane as a unit to >> something, which >> is where the HBA comes in. It doesn't look like there's a way to wire an >> individual drive >> to an onboard SATA port. >> > > These really dense 2U systems are often a pre-packaged (or close to it) > system from SuperMicro and you get what they (SuperMicro) are able to > build. The product page usually makes note of that. Your > integrator/builder is only able to make relatively small changes. Direct > wiring 24 drives in a 2U system would be crazy. > > With SAS driving SATA, it seems like you would still need/want one SAS > channel per drive and 24 channels is a lot. It sounds like you are getting > only 8 SAS channels. > > Bob > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > _______________________________________________ > 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 Fri Feb 19 16:06:12 2016 From: richard.elling at richardelling.com (Richard Elling) Date: Fri, 19 Feb 2016 08:06:12 -0800 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: References: Message-ID: <0413A5CE-0816-43CA-B379-23DC574A6AC2@richardelling.com> > On Feb 19, 2016, at 7:14 AM, Trey Palmer wrote: > > I haven't checked the Supermicro models lately, but the HP DL380Gen9 has a model with 24 direct-wired 2.5" slots in 3 modular 8-disk bays. The SAS expander is an add-in card which you don't have to buy. > > It's really excellent for Intel DC s3X10's. Of course it's also more expensive than a Supermicro. > > Hopefully Supermicro has something similar now. Wiring anything SATA through a SAS expander is a risky practice. yes, Supermicro has almost every conceivable option for drive backplanes/centerplanes including straight through wiring (SATA and SAS use the same connector) -- richard > > -- Trey > > >> On Friday, February 19, 2016, Bob Friesenhahn wrote: >>> On Fri, 19 Feb 2016, Peter Tribble wrote: >>> >>> So that was an interesting question, and I had to go away and investigate further. >>> So the way this works is that the system has a 24-slot disk backplane. The disks plug >>> into the backplane; you have to connect the backplane as a unit to something, which >>> is where the HBA comes in. It doesn't look like there's a way to wire an individual drive >>> to an onboard SATA port. >> >> These really dense 2U systems are often a pre-packaged (or close to it) system from SuperMicro and you get what they (SuperMicro) are able to build. The product page usually makes note of that. Your integrator/builder is only able to make relatively small changes. Direct wiring 24 drives in a 2U system would be crazy. >> >> With SAS driving SATA, it seems like you would still need/want one SAS channel per drive and 24 channels is a lot. It sounds like you are getting only 8 SAS channels. >> >> Bob >> -- >> Bob Friesenhahn >> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> _______________________________________________ >> 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 cks at cs.toronto.edu Fri Feb 19 16:16:04 2016 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Fri, 19 Feb 2016 11:16:04 -0500 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: peter.tribble's message of Fri, 19 Feb 2016 14:00:27 +0000. Message-ID: <20160219161604.67B527A043B@apps0.cs.toronto.edu> > > > Motherboard - Supermicro X10DRi family > > > CPUs - E5-2620 v3 > > > HBA - LSI 9300-8i > > > Network - Intel i350 or 540, depending on precise motherboard variant > > > Disks (SSD) - Intel S3510 (boot), S3610 (application + data) > > > > The drives are SATA and there are quite a few SATA ports on the > > mobo, do you need the SAS HBA? > > So that was an interesting question, and I had to go away and > investigate further. So the way this works is that the system has a > 24-slot disk backplane. The disks plug into the backplane; you have > to connect the backplane as a unit to something, which is where the > HBA comes in. It doesn't look like there's a way to wire an individual > drive to an onboard SATA port. It may be possible to do this, especially if this is a SuperMicro case. SuperMicro (and probably other people) generally offers several backplane options. One of them passes each disk through the backplane as a separate connection, although connections will usually be aggregated together in IPASS/SFF 8087 connectors (which bundle 4 SAS ports into one cable and connector). Once you have IPASS connectors on your side of the backplane, I think that you can get IPASS-to-plain-SATA cables; these have an IPASS connector on one side that splits out to four SATA cables and connectors. I believe that this would allow you to use four motherboard SATA ports to talk to four drives on the other side of the backplane via plugging the IPASS side into one of the backplane's IPASS connectors. In the long run you are definitely going to need some HBAs to talk to all of those drives, though. Your motherboard probably does not have enough onboard ports. (We have a 24-disk SuperMicro chassis set up like this, although it doesn't run OmniOS. The disks are connected via an on-motherboard LSI SAS2308 and a LSI SAS2116 card; the former runs 8 drives via 2x IPASS connectors, the latter 16 via 4x IPASS.) Like other people, I feel that you probably don't want to run SATA drives through a SAS expander (ie, using fewer SAS ports than actual drives). Almost everything I've heard about this doesn't sound good, and I like the simplicity of 'one drive, one port'. - cks [This whole area is tangled and confusing. When I was digging into it several years ago I wound up writing down what I worked out about the whole situation here: https://utcc.utoronto.ca/~cks/space/blog/tech/SASWithSATAIntro ] From eric.sproul at circonus.com Fri Feb 19 16:22:10 2016 From: eric.sproul at circonus.com (Eric Sproul) Date: Fri, 19 Feb 2016 11:22:10 -0500 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: <20160219161604.67B527A043B@apps0.cs.toronto.edu> References: <20160219161604.67B527A043B@apps0.cs.toronto.edu> Message-ID: On Fri, Feb 19, 2016 at 11:16 AM, Chris Siebenmann wrote: > It may be possible to do this, especially if this is a SuperMicro > case. SuperMicro (and probably other people) generally offers several > backplane options. One of them passes each disk through the backplane as > a separate connection, although connections will usually be aggregated > together in IPASS/SFF 8087 connectors (which bundle 4 SAS ports into one > cable and connector). Hah, I was just typing up a similar reply, so I'll just add that if your Supermicro chassis model has "E1" or "E2" in it, that means an expander backplane, which you should avoid using with SATA devices. You can double-check the specific backplane that comes with your desired chassis by reviewing the Parts List at the bottom of the page, then googling the backplane part number to find Supermicro's manual for it. For instance, http://www.supermicro.com/products/chassis/2U/216/SC216BAC-R920LP.cfm is a non-expander chassis, and has BPN-SAS3-216A for which I found the manual at https://www.supermicro.com/manuals/other/BPN-SAS3-216A.pdf and confirmed that it has 6x IPASS connectors. Chris is right that you'll need enough HBA ports to accommodate all the drive bays you want to connect-- there is no "oversubscription" as there is in a SAS expander setup. Eric From peter.tribble at gmail.com Mon Feb 22 16:35:38 2016 From: peter.tribble at gmail.com (Peter Tribble) Date: Mon, 22 Feb 2016 16:35:38 +0000 Subject: [OmniOS-discuss] Configuration sanity checking In-Reply-To: References: <20160219161604.67B527A043B@apps0.cs.toronto.edu> Message-ID: On Fri, Feb 19, 2016 at 4:22 PM, Eric Sproul wrote: > On Fri, Feb 19, 2016 at 11:16 AM, Chris Siebenmann > wrote: > > It may be possible to do this, especially if this is a SuperMicro > > case. SuperMicro (and probably other people) generally offers several > > backplane options. One of them passes each disk through the backplane as > > a separate connection, although connections will usually be aggregated > > together in IPASS/SFF 8087 connectors (which bundle 4 SAS ports into one > > cable and connector). > > Hah, I was just typing up a similar reply, so I'll just add that if > your Supermicro chassis model has "E1" or "E2" in it, that means an > expander backplane, which you should avoid using with SATA devices. > You can double-check the specific backplane that comes with your > desired chassis by reviewing the Parts List at the bottom of the page, > then googling the backplane part number to find Supermicro's manual > for it. > Thanks. Having the part number decoder ring is very useful. It's slightly worrying that I need to go to a mailing list to get part numbers to quote at suppliers who still try and tell me that I'm talking nonsense and that expanders work just fine thankyou. :-( > For instance, > http://www.supermicro.com/products/chassis/2U/216/SC216BAC-R920LP.cfm > is a non-expander chassis, and has BPN-SAS3-216A for which I found the > manual at https://www.supermicro.com/manuals/other/BPN-SAS3-216A.pdf > and confirmed that it has 6x IPASS connectors. > > Chris is right that you'll need enough HBA ports to accommodate all > the drive bays you want to connect-- there is no "oversubscription" as > there is in a SAS expander setup. > Well yes, I get that bit. It's a shame there aren't 12-port HBAs to give a symmetric mirrored config. (Yes, there's a 16-port HBA, but it's too big to fit in the chassis.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Feb 23 03:08:35 2016 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 22 Feb 2016 22:08:35 -0500 Subject: [OmniOS-discuss] Fwd: [developer] Intel I219 support, e1000g, igb testing requests References: <56CBBC79.8000605@joyent.com> Message-ID: Robert has improvements for Intel GigE drivers. Any volunteers or folks with currently-unsupported I219 should check out below. Please use an r151014 or later OmniOS as your base, please, and create a distinct BE. The following sample steps are recommended for existing igb or e1000g users (I Use igb as an example here): 1.) Create an alternate be: "beadm create igbtest" 2.) Mount the alternate be: "beadm mount igbtest /mnt" 3.) Copy the new 64-bit igb binary over: "cp .../obj64/igb /mnt/kernel/drv/amd64/igb" 4.) Update the new BE's boot archive: "bootadm update-archive -R /mnt" 5.) Activate the new BE: "beadm activate igbtest" 6.) Reboot. 7.) Run your networking tests on your IGB devices. Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) Begin forwarded message: > From: "Robert Mustacchi" > Date: February 22, 2016 at 8:57:13 PM EST > To: illumos Developer > Subject: [developer] Intel I219 support, e1000g, igb testing requests > > Hi all, > > I've updated the igb and e1000g drivers for the most recent changes from > Intel. Most notably, this adds support for the I219 family of devices > which can be found on Skylake systems with the 100 series chipsets. > > If you have an I219, in particular, I'd appreciate if you could test > this, as this work is primarily for you. > > If you don't have an I219, but do have other Intel 1 gig cards, powered > by the e1000g and igb drivers, I'd appreciate it if you could also test > this. You can see what NICs you have by running dladm show-phys. > > Here are links to all of the different formats I have it in: > > SmartOS/SDC platform: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/platform-20160221T163907Z.tgz > SmartOS ISO: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/platform-20160221T163907Z.iso > SmartOS USB: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/platform-20160221T163907Z.usb.bz2 > > e1000g 64-bit x86: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv/amd64/e1000g > e1000g 64-bit x86 debug: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv-debug/amd64/e1000g > > e1000g 32-bit x86: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv/e1000g > e1000g 32-bit x86 debug: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv-debug/e1000g > > igb 64-bit x86: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv/amd64/igb > igb 64-bit x86 debug: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv-debug/amd64/igb > igb 32-bit x86: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv/igb > igb 32-bit x86 debug: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/drv-debug/igb > > > webrev: > http://us-east.manta.joyent.com/rmustacc/public/webrevs/6666/index.html > patch: > https://us-east.manta.joyent.com/rmustacc/public/preview/i219/i219.patch > > I will send separate mail to the list for review. Please do not reply to > this with any non-testing review feedback at this time. > > If you do end up testing this, I ask that you do the following: > > 1) For each entry in dladm show-phys that's e1000g or igb, run: > prtconf -d /dev/ > > Note if devices share the same description, then it's not important to > repeat this. e.g. you may have a card with multiple ports. > > 2) Make sure that everything that used to work, still works. e.g. basic > unicast and multicast traffic flows. VNICs and zones are still all > pingable, etc. > > 3) If you have an I219, I'd appreciate if you could run the following > test just to make sure that we're properly transitioning the NIC to > promiscuous mode. The test basically is to create sixteen VNICs in total. > > After each VNIC is created: > * Assign an IP address to that VNIC > * Ensure that you can ping that IP address from another host > * Create the next VNIC > * Stop after the 16th one > > 4) If you find yourselves wanting to do some basic stress tests, that'd > be great. I'll make sure that we do some for several of the devices as well. > > If you have any questions, please reach out to me and let me know. > > Thanks, > Robert > > > ------------------------------------------- > illumos-developer > Archives: https://www.listbox.com/member/archive/182179/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175029-813097db > Modify Your Subscription: https://www.listbox.com/member/?member_id=21175029&id_secret=21175029-471fe0d4 > Powered by Listbox: http://www.listbox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at cos.ru Tue Feb 23 10:02:22 2016 From: jim at cos.ru (Jim Klimov) Date: Tue, 23 Feb 2016 11:02:22 +0100 Subject: [OmniOS-discuss] Illumos at 5 In-Reply-To: References: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu> Message-ID: Nice presentation, thanks. And sorry I couldn't be there at FOSDEM - had no idea that illumos team(s) would participate. Otherwise I'd push more elbows at work to get there and meet some people I know remotely for years... ;) Maybe same time, next year? ;) Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at cos.ru Tue Feb 23 10:04:11 2016 From: jim at cos.ru (Jim Klimov) Date: Tue, 23 Feb 2016 11:04:11 +0100 Subject: [OmniOS-discuss] Illumos at 5 In-Reply-To: References: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu> Message-ID: Nice presentation, thanks. And sorry I couldn't be there at FOSDEM - had no idea that illumos team(s) would participate. Otherwise I'd push more elbows at work to get there and meet some people I know remotely for years... ;) Maybe same time, next year? ;) Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Feb 23 14:05:33 2016 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 23 Feb 2016 09:05:33 -0500 Subject: [OmniOS-discuss] Illumos at 5 In-Reply-To: References: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu> Message-ID: <4A3D085B-4C06-41CD-A760-1D5B270CCF49@omniti.com> > On Feb 23, 2016, at 5:04 AM, Jim Klimov wrote: > > Maybe same time, next year? ;) Only reason I got to go this year was because I presented. Either I'll have to generate a new talk, or my (limited) travel budget will have to increase. I'd like to return, but I can't promise that I can. Dan From danmcd at omniti.com Thu Feb 25 02:59:11 2016 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 24 Feb 2016 21:59:11 -0500 Subject: [OmniOS-discuss] NSS & NSPR now updated Message-ID: <05C1B000-1649-4143-BAE2-8C7DACF1E3A1@omniti.com> For r151014 (LTS) and r151016 (Stable) NSS is now v3.22, and NSPR is now v4.11. The "ca-bundle" derived from NSS is also updated. Dan From lotheac at iki.fi Fri Feb 26 14:55:49 2016 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Fri, 26 Feb 2016 16:55:49 +0200 Subject: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails Message-ID: <20160226145549.GB6521@kekkonen.niksula.hut.fi> Hi, I'm (finally) attempting to set up a local mirror for the omnios package repository, but getting this when attempting to pkgrecv --clone the r151016 repository, and a similar error for r151014, but bloody seemed to work fine: pkgrecv at pkg:/niksula/pkg-omnios$ pkgrecv -s http://pkg.omniti.com/omnios/r151016 -d /niksula/pkg-omnios/r151016 --clone -p omnios Processing packages for publisher omnios ... Retrieving and evaluating 1930 package(s)... DOWNLOAD PKGS FILES XFER (MB) SPEED locale/lt-extra 1930/1930 98719/98719 1510/1510 393k/s Verifying repository contents. Initiating repository verification. pkg://omnios/driver/audio/audiop16x 1/1931 -Traceback (most recent call last): File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2391, in verify trust_anchors, sig_required_names, use_crls): File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2288, in __gen_verify hashes, errors = self.__get_hashes(path, pfmri) File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2005, in __get_hashes fnames = fname.split() AttributeError: 'NoneType' object has no attribute 'split' Traceback (most recent call last): File "/usr/bin/pkgrepo", line 1689, in handle_errors __ret = func(*args, **kwargs) File "/usr/bin/pkgrepo", line 1665, in main_func return func(conf, pargs) File "/usr/bin/pkgrepo", line 1512, in subcmd_verify for verify_tuple in repo.verify(pub=xpub, progtrack=progtrack): File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line 2396, in verify raise apx._convert_error(e) AttributeError: 'NoneType' object has no attribute 'split' pkgrepo: This is an internal error in pkg(5) version 1427212657. Please log a Service Request about this issue including the information above and this message. pkgrecv: Pkgrepo verify found errors in the updated repository. The original package catalog has been restored. The clone operation can be retried; package content that has already been retrieved will not be downloaded again. Contrary to what the message at the end claims, running it again will proceed to redownload everything and takes forever, so this is a bit annoying to debug from my end. Has anyone else seen this? Given that it works for the bloody repository, maybe it's a problem in a package in the r151014/r151016 repositories? Or should I not be using --clone? -- Lauri Tirkkonen | lotheac @ IRCnet From danmcd at omniti.com Fri Feb 26 15:48:33 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 26 Feb 2016 10:48:33 -0500 Subject: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails In-Reply-To: <20160226145549.GB6521@kekkonen.niksula.hut.fi> References: <20160226145549.GB6521@kekkonen.niksula.hut.fi> Message-ID: Okay... you're not the first to report this, but when I saw this before I thought it was because of long-latency fubars. I'm going to try two things: 1.) Try this transfer in a more direct way. We have Apache Traffic Server on the front end for load and for protection. I will try this with ATS eliminated on an internal transfer. 2.) I'm then going to rebuild and refresh the r151016 index and try internally if #1 fails. Stay tuned, Dan From danmcd at omniti.com Fri Feb 26 15:58:54 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 26 Feb 2016 10:58:54 -0500 Subject: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails In-Reply-To: <20160226145549.GB6521@kekkonen.niksula.hut.fi> References: <20160226145549.GB6521@kekkonen.niksula.hut.fi> Message-ID: <7C3FEBD8-6D6D-45D4-B17D-E4AAD9E7C012@omniti.com> OH SHOOT! I put this into bloody: commit 8bf5878ac1d6e0430b1d728f9af14046484037b5 Author: Dan McDonald Date: Wed Jan 20 16:07:12 2016 -0500 From upstream: HG changeset patch User saurabh.vyas at oracle.com Date 1424670905 -19800 Node ID 21e62efb9dd74c468212aa8051114b8ab5af90f3 Parent 8bcb37ddf96d424d6e9e8b519579f1c0a23a0deb 19381136 signature consumers assume chain present causing traceback 19608043 pkgsign(1) should not add empty chain attribute in signature action And IIRC, the other person who reported this reported it on r151014. I think I need to backport this to '014 and '016. Lauri --> can you reproduce this problem on the very latest (Feb12) bloody? I'll bet a beer you can't. Dan From danmcd at omniti.com Fri Feb 26 16:03:08 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 26 Feb 2016 11:03:08 -0500 Subject: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails In-Reply-To: <7C3FEBD8-6D6D-45D4-B17D-E4AAD9E7C012@omniti.com> References: <20160226145549.GB6521@kekkonen.niksula.hut.fi> <7C3FEBD8-6D6D-45D4-B17D-E4AAD9E7C012@omniti.com> Message-ID: > On Feb 26, 2016, at 10:58 AM, Dan McDonald wrote: > > Lauri --> can you reproduce this problem on the very latest (Feb12) bloody? I'll bet a beer you can't. NOTE: The source repo must have SIGNED packages for this problem to manifest. Dan From lotheac at iki.fi Fri Feb 26 16:08:46 2016 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Fri, 26 Feb 2016 18:08:46 +0200 Subject: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails In-Reply-To: <7C3FEBD8-6D6D-45D4-B17D-E4AAD9E7C012@omniti.com> References: <20160226145549.GB6521@kekkonen.niksula.hut.fi> <7C3FEBD8-6D6D-45D4-B17D-E4AAD9E7C012@omniti.com> Message-ID: <20160226160845.GB14397@kekkonen.niksula.hut.fi> On Fri, Feb 26 2016 10:58:54 -0500, Dan McDonald wrote: > And IIRC, the other person who reported this reported it on r151014. I think I need to backport this to '014 and '016. Yeah, I'm trying on 151014 as well. > Lauri --> can you reproduce this problem on the very latest (Feb12) bloody? I'll bet a beer you can't. I'm running it on my bloody box now, will let you know. -- Lauri Tirkkonen | lotheac @ IRCnet From danmcd at omniti.com Fri Feb 26 18:51:44 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 26 Feb 2016 13:51:44 -0500 Subject: [OmniOS-discuss] Updated pkg(5) for r151014 and r151016 In-Reply-To: <20160226145549.GB6521@kekkonen.niksula.hut.fi> References: <20160226145549.GB6521@kekkonen.niksula.hut.fi> Message-ID: Thanks to Lauri, and Alexander P. of OpenIndiana: > On Feb 26, 2016, at 9:55 AM, Lauri Tirkkonen wrote: > > Hi, I'm (finally) attempting to set up a local mirror for the omnios > package repository, but getting this when attempting to pkgrecv --clone > the r151016 repository, and a similar error for r151014, but bloody > seemed to work fine: I've just updated the r15101[46] branches of pkg5, AND just pushed out updates for: pkg lipkg ipkg That cover the aforementioned signed-package pkgrecv problem, AND an additional problem with zone attach for newly created zones that was discovered & fixed in OpenIndiana: https://illumos.org/issues/6675 Thanks everyone! Dan From lotheac at iki.fi Fri Feb 26 19:16:32 2016 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Fri, 26 Feb 2016 21:16:32 +0200 Subject: [OmniOS-discuss] pkgrecv --clone of omnios package repositories fails In-Reply-To: <20160226160845.GB14397@kekkonen.niksula.hut.fi> References: <20160226145549.GB6521@kekkonen.niksula.hut.fi> <7C3FEBD8-6D6D-45D4-B17D-E4AAD9E7C012@omniti.com> <20160226160845.GB14397@kekkonen.niksula.hut.fi> Message-ID: <20160226191632.GC14397@kekkonen.niksula.hut.fi> On Fri, Feb 26 2016 18:08:45 +0200, Lauri Tirkkonen wrote: > On Fri, Feb 26 2016 10:58:54 -0500, Dan McDonald wrote: > > And IIRC, the other person who reported this reported it on r151014. I think I need to backport this to '014 and '016. > > Yeah, I'm trying on 151014 as well. > > > Lauri --> can you reproduce this problem on the very latest (Feb12) bloody? I'll bet a beer you can't. > > I'm running it on my bloody box now, will let you know. You're right, it works on bloody. I owe you a beer :) -- Lauri Tirkkonen | lotheac @ IRCnet From mir at miras.org Fri Feb 26 19:40:20 2016 From: mir at miras.org (Michael Rasmussen) Date: Fri, 26 Feb 2016 20:40:20 +0100 Subject: [OmniOS-discuss] Extending the installer Message-ID: <20160226204020.4c5994f2@sleipner.datanom.net> Hi all, I have thought about this for some time. I think it is silly that users are not guided through the process of the initial setup of network and this is also the biggest barrier for new users (IMHO). To fix this I would suggest that the installer is extended with a GUI for doing just this. I could be implemented in one of two ways: 1) Extend the current installer 2) Start a GUI after first boot provided that the system contains known nics (Ethernet). Known nics is found this way, or something similar: dladm show-phys |grep Ethernet I personally favor option 2 since changes in the installer requires upstream support from Illumos while option 2 can be an Omnios thing. What do you all think about this suggestion? PS. I will gladly volunteer to take this task and give it to the community as a small thank you;-) -- 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: Quidquid latine dictum sit, altum videtur. [Whatever is said in Latin sounds profound.] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Fri Feb 26 19:46:20 2016 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 26 Feb 2016 14:46:20 -0500 Subject: [OmniOS-discuss] extending the installer Message-ID: <3CF60614-1C7A-463A-BB3C-B72809A78E7A@omniti.com> This is from Michael. It got bounced for some reason, and I can't remember the de-bouncing procedure off the top of my head. So I'm just forwarding it. Dan From: Michael Rasmussen Subject: extending the installer Date: February 26, 2016 at 2:18:50 PM EST To: "OmniOS-discuss" Hi all, I have thought about this for some time. I think it is silly that users are not guided through the process of the initial setup of network and this is also the biggest barrier for new users (IMHO). To fix this I would suggest that the installer is extended with a GUI for doing just this. I could be implemented in one of two ways: 1) Extend the current installer 2) Start a GUI after first boot provided that the system contains known nics (Ethernet). Known nics is found this way, or something similar: dladm show-phys |grep Ethernet I personally favor option 2 since changes in the installer requires upstream support from Illumos while option 2 can be an Omnios thing. What do you all think about this suggestion? PS. I will gladly volunteer to take this task and give it to the community as a small thank you;-) -- 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: Do not stamp. From bfriesen at simple.dallas.tx.us Fri Feb 26 20:17:59 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 26 Feb 2016 14:17:59 -0600 (CST) Subject: [OmniOS-discuss] Extending the installer In-Reply-To: <20160226204020.4c5994f2@sleipner.datanom.net> References: <20160226204020.4c5994f2@sleipner.datanom.net> Message-ID: On Fri, 26 Feb 2016, Michael Rasmussen wrote: > > 1) Extend the current installer > 2) Start a GUI after first boot provided that the system contains known > nics (Ethernet). This is OmniOS so it is not possible to have a GUI. Given the existing many automated means that OmniOS is installed (which might also provide the configuration), it is not reasonable to automatically start something up, however, a useful message could be displayed after login on console (if no networking has been configured) which suggests to run a particular program. > > I personally favor option 2 since changes in the installer requires > upstream support from Illumos while option 2 can be an Omnios thing. > > What do you all think about this suggestion? It seems useful. It could be implemented via a Python script. Networking can be very complicated (or simple). What network configuration features would be supported? I think that the network features described on the OmniOS admin page would be a good start. What would your plan be for OmniOS zones, which are in many ways the same/similar to a full OmniOS install? Would you plan to include simple NTP configuration as well? 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 Fri Feb 26 21:14:15 2016 From: mir at miras.org (Michael Rasmussen) Date: Fri, 26 Feb 2016 22:14:15 +0100 Subject: [OmniOS-discuss] Extending the installer In-Reply-To: References: <20160226204020.4c5994f2@sleipner.datanom.net> Message-ID: <20160226221415.50d493bf@sleipner.datanom.net> On Fri, 26 Feb 2016 14:17:59 -0600 (CST) Bob Friesenhahn wrote: > > This is OmniOS so it is not possible to have a GUI. Given the existing many automated means that OmniOS is installed (which might also provide the configuration), it is not reasonable to automatically start something up, however, a useful message could be displayed after login on console (if no networking has been configured) which suggests to run a particular program. By GUI is was referring to something like the "GUI" in the installer - ncurses or something similar. > > It seems useful. It could be implemented via a Python script. > Python or Perl. Are bindings present in Omnios to ncurses, newt or something similar? > Networking can be very complicated (or simple). What network configuration features would be supported? I think that the network features described on the OmniOS admin page would be a good start. > Exactly. Support configuring a single nic, either static or via dhcp. Configure a working DNS. > What would your plan be for OmniOS zones, which are in many ways the same/similar to a full OmniOS install? > If this is suppose to run after initial install then there should be no conceptual difference in a zone - if nics is available you should be able to run the nic configuration. > Would you plan to include simple NTP configuration as well? > This should be possible. Idea: first screen: Configure nic and DNS or skip second screen: Configure ntp or skip -- 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: I loathe people who keep dogs. They are cowards who haven't got the guts to bite people themselves. -- August Strindberg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From bfriesen at simple.dallas.tx.us Fri Feb 26 21:53:18 2016 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 26 Feb 2016 15:53:18 -0600 (CST) Subject: [OmniOS-discuss] Extending the installer In-Reply-To: <20160226221415.50d493bf@sleipner.datanom.net> References: <20160226204020.4c5994f2@sleipner.datanom.net> <20160226221415.50d493bf@sleipner.datanom.net> Message-ID: On Fri, 26 Feb 2016, Michael Rasmussen wrote: >> >> It seems useful. It could be implemented via a Python script. >> > Python or Perl. Are bindings present in Omnios to ncurses, newt or > something similar? Python is definitely preferred since it is assured to be available. OmniOS uses IPS which requires Python. I just checked and OmniOS's Python has Curses module support as described at https://docs.python.org/2/howto/curses.html. 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 Fri Feb 26 22:04:08 2016 From: mir at miras.org (Michael Rasmussen) Date: Fri, 26 Feb 2016 23:04:08 +0100 Subject: [OmniOS-discuss] Extending the installer In-Reply-To: References: <20160226204020.4c5994f2@sleipner.datanom.net> <20160226221415.50d493bf@sleipner.datanom.net> Message-ID: <20160226230408.1fb7551a@sleipner.datanom.net> On Fri, 26 Feb 2016 15:53:18 -0600 (CST) Bob Friesenhahn wrote: > > Python is definitely preferred since it is assured to be available. OmniOS uses IPS which requires Python. > > I just checked and OmniOS's Python has Curses module support as described at https://docs.python.org/2/howto/curses.html. > Great. Python it is;-) -- 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 doctor told me to stop having intimate dinners for four. Unless there are three other people. -- Orson Welles -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From pasztor at sagv5.gyakg.u-szeged.hu Fri Feb 26 22:53:13 2016 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Fri, 26 Feb 2016 23:53:13 +0100 Subject: [OmniOS-discuss] Extending the installer In-Reply-To: <20160226204020.4c5994f2@sleipner.datanom.net> References: <20160226204020.4c5994f2@sleipner.datanom.net> Message-ID: <20160226225313.GA17232@linux.gyakg.u-szeged.hu> Hi, "Michael Rasmussen" ?rta 2016-02-26 20:40-kor: > I have thought about this for some time. I think it is silly that users > are not guided through the process of the initial setup of network and > this is also the biggest barrier for new users (IMHO). To fix this I > would suggest that the installer is extended with a GUI for doing just > this. I could be implemented in one of two ways: > > 1) Extend the current installer > 2) Start a GUI after first boot provided that the system contains known > nics (Ethernet). I am not against improving the system. But this is a server distro. If setting up the network following the docs is a barrier: Then the next step will be a barrier than. Than the next. Than the next, etc. If a network configuration / install improvement should be done, then I vote for some auto-configuration-like thing. It was a long time ago, when I installed omnios, but what I can imagine as a useful developement on this field: * If some pxe-based installer is provided * If it can be customized with some pre-written installer answers, like like debian's dai & debconf system, etc. Or if we could give a sysconfig-like file url as a kernel param, and the installer would gather that, and then it would done these presetups. That would be something useful. A "setup tool" with gui... Why on earth?! What is your opinion about this? Cheers, Gyu From ergi.thanasko at avsquad.com Fri Feb 26 23:08:14 2016 From: ergi.thanasko at avsquad.com (Ergi Thanasko) Date: Fri, 26 Feb 2016 23:08:14 +0000 Subject: [OmniOS-discuss] Beter controls that FLOWADM In-Reply-To: <482024B8-49A9-4EC9-B770-0C724AA852E0@avsquad.com> References: <482024B8-49A9-4EC9-B770-0C724AA852E0@avsquad.com> Message-ID: Hi guys, Is there any tools like flowadm that can control bandwidth usage on a per volume basis? instead of host ip. Also flowadm will use both in/out summary to limit bandwidth. We are looking for something deeper that we can seperate control on incoming or outgoing or even at a Volume level . Please let me know et From lotheac at iki.fi Sat Feb 27 10:26:45 2016 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Sat, 27 Feb 2016 12:26:45 +0200 Subject: [OmniOS-discuss] Extending the installer In-Reply-To: <20160226225313.GA17232@linux.gyakg.u-szeged.hu> References: <20160226204020.4c5994f2@sleipner.datanom.net> <20160226225313.GA17232@linux.gyakg.u-szeged.hu> Message-ID: <20160227102645.GD14397@kekkonen.niksula.hut.fi> On Fri, Feb 26 2016 23:53:13 +0100, P?SZTOR Gy?rgy wrote: > If a network configuration / install improvement should be done, then I > vote for some auto-configuration-like thing. > It was a long time ago, when I installed omnios, but what I can imagine as > a useful developement on this field: > * If some pxe-based installer is provided > * If it can be customized with some pre-written installer answers, like > like debian's dai & debconf system, etc. Or if we could give a > sysconfig-like file url as a kernel param, and the installer would gather > that, and then it would done these presetups. That would be something > useful. A "setup tool" with gui... Why on earth?! kayak already can be and is used for network configuration in PXE installs, often with a 'Postboot' line. http://omnios.omniti.com/wiki.php/KayakClientOptions I believe this thread is about improving the interactive installer. -- Lauri Tirkkonen | lotheac @ IRCnet From davide.poletto at gmail.com Sat Feb 27 10:45:36 2016 From: davide.poletto at gmail.com (Davide Poletto) Date: Sat, 27 Feb 2016 11:45:36 +0100 Subject: [OmniOS-discuss] Extending the installer In-Reply-To: <20160226204020.4c5994f2@sleipner.datanom.net> References: <20160226204020.4c5994f2@sleipner.datanom.net> Message-ID: Hello! I add my (2 cents) thoughts. What's about enhancing/extending OmniOS's installer (Caiman, right?) also by exposing rpool's basic customization at creation time? >From my point of view that's quite different from worrying about to configure networks/services *after* OmniOS is *yet* installed by pretending to include these sort of system configurations into/during the install phase...I mean rpool's basic customization is something - maybe I'm wrong here - "primordial" in the concept of an illumos based OS installation. Parameters I'm referring to are rpool's size, options (like compression), swap and dump sizes: those are basically hidden (for the sake of simplicity I think) to user during the install phase and Caiman configures those rpool parameters quite automatically (read this ) at installation time; to circumvent this behaviour/feature at install time user is required to follow this particular documented OmniOS's procedure manually. Well, nothing that can't be changed/adapted after OmniOS is installed (rpool's size apart?)...but IMHO would be interesting to let users to configure those parameters at install time. Kind regards, Davide. On Fri, Feb 26, 2016 at 8:40 PM, Michael Rasmussen wrote: > Hi all, > > I have thought about this for some time. I think it is silly that users > are not guided through the process of the initial setup of network and > this is also the biggest barrier for new users (IMHO). To fix this I > would suggest that the installer is extended with a GUI for doing just > this. I could be implemented in one of two ways: > > 1) Extend the current installer > 2) Start a GUI after first boot provided that the system contains known > nics (Ethernet). > > Known nics is found this way, or something similar: dladm show-phys > |grep Ethernet > > I personally favor option 2 since changes in the installer requires > upstream support from Illumos while option 2 can be an Omnios thing. > > What do you all think about this suggestion? > > PS. I will gladly volunteer to take this task and give it to the > community as a small thank you;-) > > -- > 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: > Quidquid latine dictum sit, altum videtur. > [Whatever is said in Latin sounds profound.] > > _______________________________________________ > 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 Sat Feb 27 15:50:38 2016 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 27 Feb 2016 10:50:38 -0500 Subject: [OmniOS-discuss] Extending the installer In-Reply-To: <20160227102645.GD14397@kekkonen.niksula.hut.fi> References: <20160226204020.4c5994f2@sleipner.datanom.net> <20160226225313.GA17232@linux.gyakg.u-szeged.hu> <20160227102645.GD14397@kekkonen.niksula.hut.fi> Message-ID: <1950CE78-ECD8-4715-991F-D8BB76C8A9E1@omniti.com> BTW folks, there is a contingent inside OmniTI that wants to get rid of Caiman altogether and replace it with Kayak, even on interactive installs. The reason kayak exists is to make installs (PXE currently) VERY quick. Having the boot-media install be equally quick has some appeal. As far as networking configuration at boot time goes, one reason we don't have it today is so that post-installation the machine boots without any attack surface. A sysadmin knows their environment, and an installer can't necessarily know a deployment's requirements. I need to re-read this thread when I can concentrate, as I suspect there are some common-case optimizations already mentioned we can extract for a better interactive installer experience. Thanks for this thread, folks! Dan Sent from my iPhone (typos, autocorrect, and all) From mailinglists at qutic.com Sat Feb 27 17:47:33 2016 From: mailinglists at qutic.com (qutic development) Date: Sat, 27 Feb 2016 18:47:33 +0100 Subject: [OmniOS-discuss] Extending the installer In-Reply-To: <20160226225313.GA17232@linux.gyakg.u-szeged.hu> References: <20160226204020.4c5994f2@sleipner.datanom.net> <20160226225313.GA17232@linux.gyakg.u-szeged.hu> Message-ID: <2B30BD4C-0FBE-48AB-8268-3877072465D8@qutic.com> > Am 26.02.2016 um 23:53 schrieb P?SZTOR Gy?rgy : > > I am not against improving the system. > But this is a server distro. I am so happy that there is no "gui" in any way (like in debian) to configure an omnios server on startup. If it is an extra script, which can be started manually, all would be fine. - Stefan From richard at netbsd.org Sat Feb 27 21:35:03 2016 From: richard at netbsd.org (Richard PALO) Date: Sat, 27 Feb 2016 22:35:03 +0100 Subject: [OmniOS-discuss] gcc4.8 Message-ID: Hey, it'd be nice to keep the 4.8 compiler around... Seems it was simply deleted. Is it possible to add it back? -- Richard PALO