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: <A6AF6659-23DB-485B-AAF9-10F5849DB977@omniti.com>

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: <alpine.GSO.2.01.1601291404510.2897@freddy.simplesystems.org>
References: <CACFEqhshr8bthunJ1Vo=dDA=ZxSGG9ATfcXWqzrQeP3ihhuUnw@mail.gmail.com>
	<alpine.GSO.2.01.1601272119300.28454@freddy.simplesystems.org>
	<CACFEqhvvBvF0hbTw64-HqzJENwnDy2DE1mjb4=-DLY+=z0d00A@mail.gmail.com>
	<CACFEqhu85o-iadqhVswz6ngm+0kGd9tj8a56mfzKJ7GuJRRx2A@mail.gmail.com>
	<CACFEqhvmcdq3mZQC_zAgV2fKYwWZPd1HUHSUPO2yeDU7tTHidA@mail.gmail.com>
	<CACFEqhtyHZXaJJCVbtXedn3ST_nmokd0JaXHhd4Lx=NA700KyA@mail.gmail.com>
	<2137BF9A-A40B-43D8-81D2-069C09CDB3AB@omniti.com>
	<CACFEqhurQwwf1G41yUrbacfqTr3BF7xDk5Pd_P7KgZbfctXUwg@mail.gmail.com>
	<56AA860B.8060506@hfg-gmuend.de>
	<E0014CFD-5130-4181-B396-3FFAC4DDE7BC@omniti.com>
	<56AB252F.5050302@hfg-gmuend.de>
	<alpine.GSO.2.01.1601291404510.2897@freddy.simplesystems.org>
Message-ID: <CACFEqhs13AL3OKX5-wFfWHkCQnA86bYVM8DGT6GYE14KJhu9dA@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160201/e1de1e34/attachment.html>

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: <C93133D8-3372-4B40-8F9D-8556E97D6620@omniti.com>
References: <alpine.GSO.2.01.1601200821360.28454@freddy.simplesystems.org>
	<F96A9050-5E12-437A-800A-D4A8056A8989@omniti.com>
	<C93133D8-3372-4B40-8F9D-8556E97D6620@omniti.com>
Message-ID: <alpine.UW2.2.11.1602042201220.8063@server01.int.multitalents.net>


Hi Dan,

On Wed, 20 Jan 2016, Dan McDonald wrote:

| 
| > On Jan 20, 2016, at 11:12 AM, Dan McDonald <danmcd at omniti.com> 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: <alpine.UW2.2.11.1602042201220.8063@server01.int.multitalents.net>
References: <alpine.GSO.2.01.1601200821360.28454@freddy.simplesystems.org>
	<F96A9050-5E12-437A-800A-D4A8056A8989@omniti.com>
	<C93133D8-3372-4B40-8F9D-8556E97D6620@omniti.com>
	<alpine.UW2.2.11.1602042201220.8063@server01.int.multitalents.net>
Message-ID: <alpine.GSO.2.01.1602050819160.28454@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602050819160.28454@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1601200821360.28454@freddy.simplesystems.org>
	<F96A9050-5E12-437A-800A-D4A8056A8989@omniti.com>
	<C93133D8-3372-4B40-8F9D-8556E97D6620@omniti.com>
	<alpine.UW2.2.11.1602042201220.8063@server01.int.multitalents.net>
	<alpine.GSO.2.01.1602050819160.28454@freddy.simplesystems.org>
Message-ID: <A469EA6C-DD70-4BDF-BDFE-6A74F2515D58@omniti.com>

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: <CADn4rJzRWVW89=t-1G-2h6=h=fRO=YU8uoKOyw3J45xpgb1Xxw@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160205/59ec16cc/attachment.html>

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: <CADn4rJzRWVW89=t-1G-2h6=h=fRO=YU8uoKOyw3J45xpgb1Xxw@mail.gmail.com>
References: <CADn4rJzRWVW89=t-1G-2h6=h=fRO=YU8uoKOyw3J45xpgb1Xxw@mail.gmail.com>
Message-ID: <14CFA298-5C66-4158-81E7-1457A7C39D61@omniti.com>


> On Feb 5, 2016, at 2:08 PM, cristian panci? <hazzino at gmail.com> 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>,
	<CADn4rJzRWVW89=t-1G-2h6=h=fRO=YU8uoKOyw3J45xpgb1Xxw@mail.gmail.com>
Message-ID: <OF5310EC80.3B3536C9-ONC1257F50.006C579E-C1257F50.006C579F@inse.com>


Hi!



-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: cristian panci? <hazzino at gmail.com>, Dan McDonald <danmcd at omniti.com>
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: <OF5310EC80.3B3536C9-ONC1257F50.006C579E-C1257F50.006C579F@inse.com>
References: <14CFA298-5C66-4158-81E7-1457A7C39D61@omniti.com>
	<CADn4rJzRWVW89=t-1G-2h6=h=fRO=YU8uoKOyw3J45xpgb1Xxw@mail.gmail.com>
	<OF5310EC80.3B3536C9-ONC1257F50.006C579E-C1257F50.006C579F@inse.com>
Message-ID: <BBCBC683-2C78-492D-8CB3-3DB42B1FE898@omniti.com>


> On Feb 5, 2016, at 2:43 PM, Johan Kragsterman <johan.kragsterman at capvert.se> 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: <A469EA6C-DD70-4BDF-BDFE-6A74F2515D58@omniti.com>
References: <alpine.GSO.2.01.1601200821360.28454@freddy.simplesystems.org>
	<F96A9050-5E12-437A-800A-D4A8056A8989@omniti.com>
	<C93133D8-3372-4B40-8F9D-8556E97D6620@omniti.com>
	<alpine.UW2.2.11.1602042201220.8063@server01.int.multitalents.net>
	<alpine.GSO.2.01.1602050819160.28454@freddy.simplesystems.org>
	<A469EA6C-DD70-4BDF-BDFE-6A74F2515D58@omniti.com>
Message-ID: <alpine.GSO.2.01.1602051358300.3195@freddy.simplesystems.org>

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: <A469EA6C-DD70-4BDF-BDFE-6A74F2515D58@omniti.com>
References: <alpine.GSO.2.01.1601200821360.28454@freddy.simplesystems.org>
	<F96A9050-5E12-437A-800A-D4A8056A8989@omniti.com>
	<C93133D8-3372-4B40-8F9D-8556E97D6620@omniti.com>
	<alpine.UW2.2.11.1602042201220.8063@server01.int.multitalents.net>
	<alpine.GSO.2.01.1602050819160.28454@freddy.simplesystems.org>
	<A469EA6C-DD70-4BDF-BDFE-6A74F2515D58@omniti.com>
Message-ID: <CAEgYsbHe1X16hgB57FeW0doGo4zats_gUpd+kesiPVUMRLa8Tw@mail.gmail.com>

On Fri, Feb 5, 2016 at 3:42 PM, Dan McDonald <danmcd at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160206/25008a93/attachment.html>

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: <CABT+cBCAYnMqNkyJ5sfxxQ9CJKvngpsrsRLkhvULTJ0rnbEJNA@mail.gmail.com>
References: <CABT+cBCAYnMqNkyJ5sfxxQ9CJKvngpsrsRLkhvULTJ0rnbEJNA@mail.gmail.com>
Message-ID: <20160206182505.GC4799@netmeister.org>

Marissa Murphy <mmurphyatomniti.com> 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: <alpine.GSO.2.01.1602071445060.12673@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602071445060.12673@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1602071445060.12673@freddy.simplesystems.org>
Message-ID: <69F44698-1505-4321-BF7F-B51508B26C64@omniti.com>


> On Feb 7, 2016, at 4:03 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160207/d82f9b7e/attachment.bin>

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: <alpine.GSO.2.01.1602071445060.12673@freddy.simplesystems.org>
	<69F44698-1505-4321-BF7F-B51508B26C64@omniti.com>
Message-ID: <alpine.GSO.2.01.1602071627210.12673@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602071445060.12673@freddy.simplesystems.org>
	<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: <alpine.GSO.2.01.1602071445060.12673@freddy.simplesystems.org>
	<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 <jdg117 at elvis.arl.psu.edu> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160207/f273ca74/attachment.bin>

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: <CAEgYsbHe1X16hgB57FeW0doGo4zats_gUpd+kesiPVUMRLa8Tw@mail.gmail.com>
References: <alpine.GSO.2.01.1601200821360.28454@freddy.simplesystems.org>
	<F96A9050-5E12-437A-800A-D4A8056A8989@omniti.com>
	<C93133D8-3372-4B40-8F9D-8556E97D6620@omniti.com>
	<alpine.UW2.2.11.1602042201220.8063@server01.int.multitalents.net>
	<alpine.GSO.2.01.1602050819160.28454@freddy.simplesystems.org>
	<A469EA6C-DD70-4BDF-BDFE-6A74F2515D58@omniti.com>
	<CAEgYsbHe1X16hgB57FeW0doGo4zats_gUpd+kesiPVUMRLa8Tw@mail.gmail.com>
Message-ID: <6F7B38A1-71ED-4E01-84DE-B1747AB5F4B3@omniti.com>


> On Feb 6, 2016, at 10:27 AM, Peter Tribble <peter.tribble at gmail.com> 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 <daleg at omniti.com>
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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160210/35711651/attachment.html>

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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
References: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
References: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
Message-ID: <C301AE49-8E80-4FCE-B4A2-672D611A3F04@omniti.com>


> On Feb 10, 2016, at 11:26 AM, Schweiss, Chip <chip at innovates.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160210/37686202/attachment.bin>

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: <C301AE49-8E80-4FCE-B4A2-672D611A3F04@omniti.com>
References: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
	<C301AE49-8E80-4FCE-B4A2-672D611A3F04@omniti.com>
Message-ID: <CALeZrrQmGUasOHmQGeq2R+kx93pnypA4rQdm_jGzoG_jq2CmuA@mail.gmail.com>

On Wed, Feb 10, 2016 at 11:19 AM, Dale Ghent <daleg at omniti.com> wrote:

>
> > On Feb 10, 2016, at 11:26 AM, Schweiss, Chip <chip at innovates.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160210/22a4f63c/attachment.html>

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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
References: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
Message-ID: <85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com>


> On Feb 10, 2016, at 11:26 AM, Schweiss, Chip <chip at innovates.com> 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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
References: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
	<85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com>
Message-ID: <CALeZrrRkkaX8Ph1_n2yAhhyhvRA_s2BU4wsngLoHq2vpSK83AA@mail.gmail.com>

On Wed, Feb 10, 2016 at 1:11 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Feb 10, 2016, at 11:26 AM, Schweiss, Chip <chip at innovates.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160210/48c1941e/attachment-0001.html>

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: <CALeZrrRkkaX8Ph1_n2yAhhyhvRA_s2BU4wsngLoHq2vpSK83AA@mail.gmail.com>
References: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
	<85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com>
	<CALeZrrRkkaX8Ph1_n2yAhhyhvRA_s2BU4wsngLoHq2vpSK83AA@mail.gmail.com>
Message-ID: <20160210212430.70e1a582@sleipner.datanom.net>

On Wed, 10 Feb 2016 14:12:16 -0600
"Schweiss, Chip" <chip at innovates.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160210/97a34305/attachment.bin>

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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
	<85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com>
	<CALeZrrRkkaX8Ph1_n2yAhhyhvRA_s2BU4wsngLoHq2vpSK83AA@mail.gmail.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 <mir at miras.org> wrote:
> 
> On Wed, 10 Feb 2016 14:12:16 -0600
> "Schweiss, Chip" <chip at innovates.com> 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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
	<85F6EAED-4ABD-49E8-A6F9-854F666DE94B@omniti.com>
	<CALeZrrRkkaX8Ph1_n2yAhhyhvRA_s2BU4wsngLoHq2vpSK83AA@mail.gmail.com>
	<20160210212430.70e1a582@sleipner.datanom.net>
Message-ID: <alpine.GSO.2.01.1602101505080.24119@freddy.simplesystems.org>

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: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
References: <CALeZrrQnJgxqd4-mKecGa03Y+Ta_1kLZqiuSugg5Dm9sMY9Kbw@mail.gmail.com>
Message-ID: <alpine.GSO.2.01.1602101518290.24119@freddy.simplesystems.org>

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: <CAD3ijn4xjxquxf+VaEpXBC=rSTp_6YQN3NSLrWLvtDJOpyGTOQ@mail.gmail.com>
Message-ID: <F58CD60A-8403-4C0B-8678-CF7D74C8BB77@omniti.com>

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" <jmc at joyent.com>
> 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 <danmcd at omniti.com>
> Cc: Robert Mustacchi <rm at joyent.com>
> 
> Hi Dan,

<snip!>

> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160212/f6f8dc7b/attachment.bin>

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 <mir at miras.org> 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 <danmcd at omniti.com> ha scritto:
>
>> On Feb 11, 2016, at 7:30 PM, Michael Rasmussen <mir at miras.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160212/d49bd199/attachment-0001.html>

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: <E7185951-3106-4E2D-A018-29FF465EED24@omniti.com>

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: <F58CD60A-8403-4C0B-8678-CF7D74C8BB77@omniti.com>
References: <CAD3ijn4xjxquxf+VaEpXBC=rSTp_6YQN3NSLrWLvtDJOpyGTOQ@mail.gmail.com>
	<F58CD60A-8403-4C0B-8678-CF7D74C8BB77@omniti.com>
Message-ID: <AE667E5C-ECBD-4158-B495-CF9774BF0BD5@qutic.com>

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: <E7185951-3106-4E2D-A018-29FF465EED24@omniti.com>
References: <E7185951-3106-4E2D-A018-29FF465EED24@omniti.com>
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 <mir at miras.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160213/f3c6e3f3/attachment.bin>

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: <alpine.GSO.2.01.1602131922450.9769@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602131922450.9769@freddy.simplesystems.org>
References: <alpine.GSO.2.01.1602131922450.9769@freddy.simplesystems.org>
Message-ID: <20160214153748.27c8fdf0@punda-mlia>

On Sat, 13 Feb 2016 19:51:32 -0600 (CST)
Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <alpine.GSO.2.01.1602131922450.9769@freddy.simplesystems.org>
	<20160214153748.27c8fdf0@punda-mlia>
Message-ID: <alpine.GSO.2.01.1602141030240.9769@freddy.simplesystems.org>

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: <A1726F9A-81F0-40B6-847C-D7485EE5174B@omniti.com>


> On Feb 13, 2016, at 8:13 PM, Dale Ghent <daleg at omniti.com> wrote:
> 
> 
>> On Feb 11, 2016, at 7:30 PM, Michael Rasmussen <mir at miras.org> 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: <alpine.GSO.2.01.1602141451430.9769@freddy.simplesystems.org>

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: <A1726F9A-81F0-40B6-847C-D7485EE5174B@omniti.com>
References: <20160212013036.75101f6c@sleipner.datanom.net>
	<3265585C-21B5-4260-84EE-FECCFF455F8A@omniti.com>
	<A1726F9A-81F0-40B6-847C-D7485EE5174B@omniti.com>
Message-ID: <1FA8419D-96F7-46DC-BD44-20DE54245879@omniti.com>


> On Feb 14, 2016, at 3:31 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Feb 13, 2016, at 8:13 PM, Dale Ghent <daleg at omniti.com> wrote:
>> 
>> 
>>> On Feb 11, 2016, at 7:30 PM, Michael Rasmussen <mir at miras.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160214/1ddcb135/attachment.bin>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160215/f5b75346/attachment.html>

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: <trinity-e9e97e6f-24ac-4cf5-90cb-ced300eeb8b9-1455540009741@3capp-gmx-bs11>

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: <OF2A17CBB6.F38F8286-ONC1257F5A.004BC234-C1257F5A.004BC236@inse.com>


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



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>
	<OF2A17CBB6.F38F8286-ONC1257F5A.004BC234-C1257F5A.004BC236@inse.com>
	<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 &lt;johan.kragsterman at capvert.se&gt;wrote ---- 





Hi! 









-----"OmniOS-discuss" &lt;omnios-discuss-bounces at lists.omniti.com&gt; skrev: ----- 

Till: "omnios-discuss at lists.omniti.com" &lt;omnios-discuss at lists.omniti.com&gt; 

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160215/b52ed4ef/attachment.html>

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>
	<OF2A17CBB6.F38F8286-ONC1257F5A.004BC234-C1257F5A.004BC236@inse.com>
	<152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>,
	<152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk>
Message-ID: <trinity-b5698db2-b1e7-4329-a165-d3ab27912436-1455545530624@3capp-gmx-bs34>

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]

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: <trinity-b5698db2-b1e7-4329-a165-d3ab27912436-1455545530624@3capp-gmx-bs34>
References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>,
	<152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk>
	<OF2A17CBB6.F38F8286-ONC1257F5A.004BC234-C1257F5A.004BC236@inse.com>
	<152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>,
	<152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk>
	<trinity-b5698db2-b1e7-4329-a165-d3ab27912436-1455545530624@3capp-gmx-bs34>
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 &lt;hasslerd at gmx.li&gt;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" &lt;gordon at hafnia.dk&gt; 

An: "omnios-discuss at lists.omniti.com" &lt;omnios-discuss at lists.omniti.com&gt; 

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 &lt;johan.kragsterman at capvert.se[johan.kragsterman at capvert.se]&gt;wrote ---- 

 

  

  

Hi! 

  

  

  

  

-----"OmniOS-discuss" &lt;omnios-discuss-bounces at lists.omniti.com[omnios-discuss-bounces at lists.omniti.com]&gt; skrev: ----- 

Till: "omnios-discuss at lists.omniti.com[omnios-discuss at lists.omniti.com]" &lt;omnios-discuss at lists.omniti.com[omnios-discuss at lists.omniti.com]&gt; 

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160215/1627b0dd/attachment.html>

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: <AFE18E10-D383-4A50-8856-B5C3BA29D573@omniti.com>


> On Feb 10, 2016, at 12:57 PM, Josef 'Jeff' Sipek <jeffpc at josefsipek.net> 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: <AFE18E10-D383-4A50-8856-B5C3BA29D573@omniti.com>
References: <20160210175754.GA1458@meili.valhalla.31bits.net>
	<AFE18E10-D383-4A50-8856-B5C3BA29D573@omniti.com>
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: <AFE18E10-D383-4A50-8856-B5C3BA29D573@omniti.com>
References: <20160210175754.GA1458@meili.valhalla.31bits.net>
	<AFE18E10-D383-4A50-8856-B5C3BA29D573@omniti.com>
Message-ID: <CF800C63-5E01-4CA1-9ECC-C66699FFA4E0@omniti.com>


> On Feb 15, 2016, at 10:50 AM, Dan McDonald <danmcd at omniti.com> 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: <trinity-e9e97e6f-24ac-4cf5-90cb-ced300eeb8b9-1455540009741@3capp-gmx-bs11>
References: <trinity-e9e97e6f-24ac-4cf5-90cb-ced300eeb8b9-1455540009741@3capp-gmx-bs11>
Message-ID: <EB4CFDD5-72A5-4FEA-A374-129F9236DCC9@RichardElling.com>


> On Feb 15, 2016, at 4:40 AM, Dominik Hassler <hasslerd at gmx.li> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160215/d7a43375/attachment-0001.html>

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>
	<OF2A17CBB6.F38F8286-ONC1257F5A.004BC234-C1257F5A.004BC236@inse.com>
	<152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>, 
	<152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk>
	<trinity-b5698db2-b1e7-4329-a165-d3ab27912436-1455545530624@3capp-gmx-bs34>
	<152e555cab6.f05c31c3110523.6316636820069675438@hafnia.dk>
Message-ID: <alpine.GSO.2.01.1602151803560.20156@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602151803560.20156@freddy.simplesystems.org>
References: <152e4e62461.124e1a1b3105672.8940470084502842530@hafnia.dk>,
	<152e4e371ae.c92805aa105551.2354914292311483707@hafnia.dk>
	<OF2A17CBB6.F38F8286-ONC1257F5A.004BC234-C1257F5A.004BC236@inse.com>
	<152e535ecd7.d5bd96bd109178.2295545963365004217@hafnia.dk>, 
	<152e536cc94.109bb399f109216.8832437935469852321@hafnia.dk>
	<trinity-b5698db2-b1e7-4329-a165-d3ab27912436-1455545530624@3capp-gmx-bs34>
	<152e555cab6.f05c31c3110523.6316636820069675438@hafnia.dk>
	<alpine.GSO.2.01.1602151803560.20156@freddy.simplesystems.org>
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 &lt;bfriesen at simple.dallas.tx.us&gt;wrote ---- 




On Mon, 15 Feb 2016, Gordon Selisek wrote: 

&gt; 

&gt; I read here that "By default, networking between the control domain and other domains in the system is disabled." 

&gt; 

&gt; https://docs.oracle.com/cd/E19608-01/html/821-1485/enablenetworkbtwncsdomainandotherdomains.html 

&gt; 

&gt; 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160216/4d300022/attachment.html>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160216/85030ed4/attachment.html>

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: <OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>


Hi!


-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: omnios-discuss <omnios-discuss at lists.omniti.com>
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: <OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>
References: <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr>
	<OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>
Message-ID: <56C351B4.4000505@jvm.de>

Am 16.02.16 um 17:11 schrieb Johan Kragsterman:
> Hi!
>
>
> -----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
> Till: omnios-discuss <omnios-discuss at lists.omniti.com>
> 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 <LU> 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>	<OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>
Message-ID: <OFA33B9873.598B9268-ONC1257F5B.0062B578-C1257F5B.0062B579@inse.com>


Hi!



-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: <omnios-discuss at lists.omniti.com>
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" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
> Till: omnios-discuss <omnios-discuss at lists.omniti.com>
> 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&#8230; 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 <LU> 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: <OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>
References: <907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr>
	<OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>
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" <johan.kragsterman at capvert.se>
Kime: "Hafiz Rafibeyli" <rafibeyli at gmail.com>
Kk: "omnios-discuss" <omnios-discuss at lists.omniti.com>
G?nderilenler: 16 ?ubat Sal? 2016 18:11:33
Konu: Ang: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy

Hi!


-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: omnios-discuss <omnios-discuss at lists.omniti.com>
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: <OFA33B9873.598B9268-ONC1257F5B.0062B578-C1257F5B.0062B579@inse.com>
References: <56C351B4.4000505@jvm.de>,
	<907082098.1299393.1455637514250.JavaMail.zimbra@cantekstil.com.tr>	<OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>
	<OFA33B9873.598B9268-ONC1257F5B.0062B578-C1257F5B.0062B579@inse.com>
Message-ID: <56C426BB.6030207@jvm.de>

Am 16.02.16 um 18:58 schrieb Johan Kragsterman:
> Hi!
>
>
>
> -----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
> Till: <omnios-discuss at lists.omniti.com>
> 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" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
>> Till: omnios-discuss <omnios-discuss at lists.omniti.com>
>> 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&#8230; 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 <LU> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160217/f9cc4003/attachment.html>

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: <ae377e07626648a592341c93f555c45b@Perses.usurf.usu.edu>
References: <ae377e07626648a592341c93f555c45b@Perses.usurf.usu.edu>
Message-ID: <BB1D2E90-9926-4BA9-B2F2-2085BDB00775@gmail.com>

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 <Josh.Barton at usurf.usu.edu> 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 <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 <mailto: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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160217/b1ae1f87/attachment.html>

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>
	<OF831A9A1F.38D9CA01-ONC1257F5B.0058F2E3-C1257F5B.0058F2E5@inse.com>
	<OFA33B9873.598B9268-ONC1257F5B.0062B578-C1257F5B.0062B579@inse.com>
	<56C426BB.6030207@jvm.de>
Message-ID: <FD29183F-CB69-4921-8D8C-7D7894EE6B0F@omniti.com>


> On Feb 17, 2016, at 2:52 AM, Stephan Budach <stephan.budach at JVM.DE> 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: <C4190046-2C36-41F0-9702-AF4CE416BC01@omniti.com>


> 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


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: <C4190046-2C36-41F0-9702-AF4CE416BC01@omniti.com>
References: <152ef8fe5a6.fb101e0c17643.9188063082698391779@hafnia.dk>
	<C4190046-2C36-41F0-9702-AF4CE416BC01@omniti.com>
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 &lt;danmcd at omniti.com&gt;wrote ---- 






&gt; On Feb 17, 2016, at 9:08 AM, Gordon Selisek &lt;gordon at hafnia.dk&gt; wrote: 

&gt; 

&gt; delete: the link is busy and can not be deleted, even if i kill the qemu process that is using it. 

&gt; 

 

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160217/b6cfb841/attachment.html>

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: <CADRROpXDsvqTJkO79mHUkrCFXt2PjCjAH3idz2wTy4D2=Qp2mg@mail.gmail.com>

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 <paul.jochum at alcatel-lucent.com
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160217/2bfd57d7/attachment.html>

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: <CADRROpV+DYBUjQHkyd4cH2i4XvoJFUw7mA1moPJQ2bKN1WidDw@mail.gmail.com>

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 <lotheac at iki.fi> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160217/9c6c76c0/attachment.html>

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 <stephan.budach at JVM.DE> 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 <stephan.budach at JVM.DE> 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 <stephan.budach at JVM.DE> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160218/13309d39/attachment.bin>

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: <E4438CC7-A2EB-4DA0-94A9-69708270518B@lji.org>

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 <stephan.budach at jvm.de> 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 <stephan.budach at JVM.DE> 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 <stephan.budach at JVM.DE> 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 <stephan.budach at JVM.DE> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160218/6b764924/attachment.bin>

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 <stephan.budach at JVM.DE> 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>

<URL:http://video.fosdem.org/2016/janson/illumos-at-5.mp4>

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: <FBA3C26E-A277-487E-B9CD-4D158C4863A4@omniti.com>


> On Feb 18, 2016, at 2:32 PM, John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
> 
> <URL:http://video.fosdem.org/2016/janson/illumos-at-5.mp4>
> 
> Well done, Dan.


<blushes>Thanks</blushes>

> 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: <CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com>

On Thu, Feb 18, 2016 at 5:14 AM, Michael Rasmussen <mir at miras.org> wrote:

> On Thu, 18 Feb 2016 07:13:36 +0100
> Stephan Budach <stephan.budach at JVM.DE> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160218/c506318e/attachment-0001.html>

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: <CADRROpV+DYBUjQHkyd4cH2i4XvoJFUw7mA1moPJQ2bKN1WidDw@mail.gmail.com>
References: <56C4E4FE.90609@alcatel-lucent.com>
	<20160217213004.GC3182@kekkonen.niksula.hut.fi>
	<56C4EB80.6050103@alcatel-lucent.com>
	<20160217215910.GD3182@kekkonen.niksula.hut.fi>
	<CADRROpV+DYBUjQHkyd4cH2i4XvoJFUw7mA1moPJQ2bKN1WidDw@mail.gmail.com>
Message-ID: <CALeZrrQm=Ysbo7pZjPq4_+Pt6vjy-g5xQ0UvHSA7jgoFnhHBtw@mail.gmail.com>

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 <trey at mailchimp.com> 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 <lotheac at iki.fi> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160218/7e75f65f/attachment.html>

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: <CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com>
References: <56C56110.50301@jvm.de>
	<20160218121415.493a6e76@sleipner.datanom.net>
	<CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com>
Message-ID: <2D7D9A5E-FFB1-4923-88A2-486FE66C3341@richardelling.com>

comments below...

> On Feb 18, 2016, at 12:57 PM, Schweiss, Chip <chip at innovates.com> wrote:
> 
> 
> 
> On Thu, Feb 18, 2016 at 5:14 AM, Michael Rasmussen <mir at miras.org <mailto:mir at miras.org>> wrote:
> On Thu, 18 Feb 2016 07:13:36 +0100
> Stephan Budach <stephan.budach at JVM.DE <mailto:stephan.budach at JVM.DE>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160218/5c8e934e/attachment.html>

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: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160218/763235a1/attachment-0001.html>

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 <module>
   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: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
References: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
Message-ID: <B428C787-5B94-466B-90E0-F5C4A8E98AF8@richardelling.com>

Hi Peter!

> On Feb 18, 2016, at 2:15 PM, Peter Tribble <peter.tribble at gmail.com> 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: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
References: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
Message-ID: <18660578-D56F-4721-8A7E-3BBAEB47506F@omniti.com>


> On Feb 18, 2016, at 5:15 PM, Peter Tribble <peter.tribble at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160218/1530eac8/attachment.bin>

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: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
	<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 <daleg at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160219/7f18af7c/attachment.bin>

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: <alpine.GSO.2.01.1602182111470.10065@freddy.simplesystems.org>

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: <CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com>
References: <56C56110.50301@jvm.de>	<20160218121415.493a6e76@sleipner.datanom.net>
	<CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com>
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 <mir at miras.org 
> <mailto:mir at miras.org>> wrote:
>
>     On Thu, 18 Feb 2016 07:13:36 +0100
>     Stephan Budach <stephan.budach at JVM.DE
>     <mailto:stephan.budach at JVM.DE>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160219/8c3b66a8/attachment-0001.html>

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>	<CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com>
	<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 <chip at innovates.com 
>> <mailto:chip at innovates.com>> wrote:
>>
>>
>>
>> On Thu, Feb 18, 2016 at 5:14 AM, Michael Rasmussen<mir at miras.org 
>> <mailto:mir at miras.org>>wrote:
>>
>>     On Thu, 18 Feb 2016 07:13:36 +0100
>>     Stephan Budach <stephan.budach at JVM.DE
>>     <mailto:stephan.budach at JVM.DE>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160219/beeccb9e/attachment.html>

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>
	<CALeZrrQXDkqSXvQcD_55R2dxypx3Wu5jMaa2+awERX5gHdBXjg@mail.gmail.com>
	<2D7D9A5E-FFB1-4923-88A2-486FE66C3341@richardelling.com>
Message-ID: <CALeZrrS5Hz0ZuBtGcJQiM4fOgBuZruC3nktcuhrfgBfUJjSxyA@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160219/d954eecf/attachment.html>

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: <B428C787-5B94-466B-90E0-F5C4A8E98AF8@richardelling.com>
References: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
	<B428C787-5B94-466B-90E0-F5C4A8E98AF8@richardelling.com>
Message-ID: <CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>

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 <peter.tribble at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160219/b3a9e5ec/attachment.html>

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: <CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>
References: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
	<B428C787-5B94-466B-90E0-F5C4A8E98AF8@richardelling.com>
	<CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>
Message-ID: <alpine.GSO.2.01.1602190829200.10065@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602190829200.10065@freddy.simplesystems.org>
References: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
	<B428C787-5B94-466B-90E0-F5C4A8E98AF8@richardelling.com>
	<CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>
	<alpine.GSO.2.01.1602190829200.10065@freddy.simplesystems.org>
Message-ID: <CADRROpV8bdeKmpGyjimKwVMYogozqZ7D5H_Ob-L55ygmfUaoxA@mail.gmail.com>

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 <bfriesen at simple.dallas.tx.us>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160219/f3b8ced7/attachment.html>

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: <CADRROpV8bdeKmpGyjimKwVMYogozqZ7D5H_Ob-L55ygmfUaoxA@mail.gmail.com>
References: <CAEgYsbGq=fwKUaypQYVUpr0f23yW3jX7SvWFXuF5x4xePbTRJA@mail.gmail.com>
	<B428C787-5B94-466B-90E0-F5C4A8E98AF8@richardelling.com>
	<CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>
	<alpine.GSO.2.01.1602190829200.10065@freddy.simplesystems.org>
	<CADRROpV8bdeKmpGyjimKwVMYogozqZ7D5H_Ob-L55ygmfUaoxA@mail.gmail.com>
Message-ID: <0413A5CE-0816-43CA-B379-23DC574A6AC2@richardelling.com>


> On Feb 19, 2016, at 7:14 AM, Trey Palmer <trey at mailchimp.com> 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 <bfriesen at simple.dallas.tx.us> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160219/e17f20f9/attachment.html>

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.
	<CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>
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: <CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>
	<20160219161604.67B527A043B@apps0.cs.toronto.edu>
Message-ID: <CAO8hXRCr2_0-5BDteSad0_wOMHHNBJqGrCCpOg9XNmqx7Kcytw@mail.gmail.com>

On Fri, Feb 19, 2016 at 11:16 AM, Chris Siebenmann <cks at cs.toronto.edu> 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: <CAO8hXRCr2_0-5BDteSad0_wOMHHNBJqGrCCpOg9XNmqx7Kcytw@mail.gmail.com>
References: <CAEgYsbGbkCKo19sNGZ2QZt4nt2usO9W4dwk=QJnvh--N_nkHzQ@mail.gmail.com>
	<20160219161604.67B527A043B@apps0.cs.toronto.edu>
	<CAO8hXRCr2_0-5BDteSad0_wOMHHNBJqGrCCpOg9XNmqx7Kcytw@mail.gmail.com>
Message-ID: <CAEgYsbHQkbP5joDo6tRd0T-u25z+PP=3qGDgS86v+uykx_Obdg@mail.gmail.com>

On Fri, Feb 19, 2016 at 4:22 PM, Eric Sproul <eric.sproul at circonus.com>
wrote:

> On Fri, Feb 19, 2016 at 11:16 AM, Chris Siebenmann <cks at cs.toronto.edu>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160222/20873d3c/attachment-0001.html>

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: <FD532E21-3DFC-40A5-895B-44EB30E90792@omniti.com>

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" <rm at joyent.com>
> Date: February 22, 2016 at 8:57:13 PM EST
> To: illumos Developer <developer at lists.illumos.org>
> 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/<dladm instance name>
> 
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160222/562b40ed/attachment.html>

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: <FBA3C26E-A277-487E-B9CD-4D158C4863A4@omniti.com>
References: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu>
	<FBA3C26E-A277-487E-B9CD-4D158C4863A4@omniti.com>
Message-ID: <fc78b2962b1c.56cc3c3e@cos.ru>


 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160223/d1568d8b/attachment.html>

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: <FBA3C26E-A277-487E-B9CD-4D158C4863A4@omniti.com>
References: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu>
	<FBA3C26E-A277-487E-B9CD-4D158C4863A4@omniti.com>
Message-ID: <fc789b0b7db2.56cc3cab@cos.ru>


 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160223/46249b9e/attachment.html>

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: <fc789b0b7db2.56cc3cab@cos.ru>
References: <201602181932.u1IJWgaV025245@elvis.arl.psu.edu>
	<FBA3C26E-A277-487E-B9CD-4D158C4863A4@omniti.com>
	<fc789b0b7db2.56cc3cab@cos.ru>
Message-ID: <4A3D085B-4C06-41CD-A760-1D5B270CCF49@omniti.com>


> On Feb 23, 2016, at 5:04 AM, Jim Klimov <jim at cos.ru> 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: <D14B280B-5EE5-4D56-B423-3528197FBEFD@omniti.com>

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 <danmcd at omniti.com>
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: <B3F9E4FD-1085-4219-A747-102B1FE494EA@omniti.com>


> On Feb 26, 2016, at 10:58 AM, Dan McDonald <danmcd at omniti.com> 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: <FC09B9A1-71F9-44CA-B42F-3E0599477148@omniti.com>

Thanks to Lauri, and Alexander P. of OpenIndiana:

> On Feb 26, 2016, at 9:55 AM, Lauri Tirkkonen <lotheac at iki.fi> 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:

<SNIP!>

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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160226/9e30a765/attachment-0001.bin>

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 <mir at miras.org>
Subject: extending the installer
Date: February 26, 2016 at 2:18:50 PM EST
To: "OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com>


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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <alpine.GSO.2.01.1602261409540.8550@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602261409540.8550@freddy.simplesystems.org>
References: <20160226204020.4c5994f2@sleipner.datanom.net>
	<alpine.GSO.2.01.1602261409540.8550@freddy.simplesystems.org>
Message-ID: <20160226221415.50d493bf@sleipner.datanom.net>

On Fri, 26 Feb 2016 14:17:59 -0600 (CST)
Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160226/65e860d4/attachment.bin>

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>
	<alpine.GSO.2.01.1602261409540.8550@freddy.simplesystems.org>
	<20160226221415.50d493bf@sleipner.datanom.net>
Message-ID: <alpine.GSO.2.01.1602261550580.8550@freddy.simplesystems.org>

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: <alpine.GSO.2.01.1602261550580.8550@freddy.simplesystems.org>
References: <20160226204020.4c5994f2@sleipner.datanom.net>
	<alpine.GSO.2.01.1602261409540.8550@freddy.simplesystems.org>
	<20160226221415.50d493bf@sleipner.datanom.net>
	<alpine.GSO.2.01.1602261550580.8550@freddy.simplesystems.org>
Message-ID: <20160226230408.1fb7551a@sleipner.datanom.net>

On Fri, 26 Feb 2016 15:53:18 -0600 (CST)
Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160226/651064d6/attachment.bin>

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" <mir at miras.org> ?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: <C269BFE7-5AE8-4B78-8CBB-0574831EE9EF@avsquad.com>

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: <CANKMAMZv8uf9HQJFPty+Vs+fne4R8My76+rc852EDW9un4VP5A@mail.gmail.com>

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
<https://utcc.utoronto.ca/~cks/space/blog/solaris/OmniOSDiskSizing>) at
installation time; to circumvent this behaviour/feature at install time
user is required to follow this
<http://omnios.omniti.com/wiki.php/ISOrpoolCustomize> 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 <mir at miras.org> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20160227/77623457/attachment.html>

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 <pasztor at sagv5.gyakg.u-szeged.hu>:
> 
> 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: <nat4r9$53m$1@ger.gmane.org>

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



